Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
Summary 401 In the short-term future, it seems likely that we will continue to see enormous effort spent in developing tools and in ensuring that a set of tools fits together in an integrated manner. At the same time we can expect that end users will carry out their own system development using software packages that require them to know little about the computer. Coupled with the availability of inexpensive applications packages, the applications programmer seems (as ever) doomed. In the long term, the nature of programming itself could be transformed by a declarative style of programming in which the programmer describes a solution to a problem rather than having to specify explicitly how that solution is to be obtained. While the applications programmer may vanish, the role of the systems programmers may be enhanced. Their mission will be to develop products of high quality – reliable, powerful and easy to use. The skills involved in their development may be considerable – not least in the requirement to create demonstrably reliable software, perhaps using formal, mathematical approaches. At the other end of the spectrum, the analyst will not become extinct. Their role will be to guide users and an organization in making best use of the available packages. The general trend seems to be: ■ the increasing scrutiny of the software development task ■ systematization of software development ■ the division of labor amongst specialists ■ the automation of tasks using tools ■ software reuse. Summary Software development methods have changed dramatically in the past and look set to do so in the future. The trend is towards the increased use of packages, program generators and automated tools. Long-term, traditional procedural programming languages may vanish to be replaced by declarative languages (functional and or logic languages) – at least for application programming. There is sometimes a tension between the desire to exercise control during project management and the individual programmer’s desire for autonomy. One thing is certain: software engineering will continue to be supremely challenging, creative and enjoyable.
402 Chapter 32 ■ Conclusion • Exercises 32.1 Compare and contrast the following two approaches to software development: 1. placing trust in individual skills 2. relying on systematic methods. 32.2 Compare and contrast the following approaches to software reuse: ■ Unix filters ■ object-oriented classes. 32.3 “Programming is easy.” Discuss. 32.4 “Software engineering is just programming, and programming is just hacking.” Discuss. 32.5 “The scrutiny of software development methods, together with the imposition of standards and procedures for quality assurance has taken all the fun out of it.” Discuss. 32.6 “The tasks involved in software engineering are going to dramatically change over the next five to ten years. In particular, conventional programming will no longer exist.” Discuss. 32.7 Predict the future of software engineering. Further reading •Ed Yourdon is one of the gurus of software development. In this book he gives a very readable account of the problems with software development today. The book continues by giving a survey of the possible remedies for the problems. It’s altogether a very readable book, free of technicalities and free with opinions. The title reflects the author’s opinion that American programmers are under threat from competition from programmers in Asia – who are paid less, but are better! Edward Yourdon, Decline and Fall of the American Programmer, PTR Prentice Hall, 1993. The sequel to Decline and Fall, which is much more optimistic about the future of the American programmer, provided that they take the initiative and learn about new technologies, like Java: Edward Yourdon, Rise and Resurrection of the American Programmer, PTR Prentice Hall, 1995. A possible future for software development is described in the following reference. Have the predictions turned out to be correct? A.J. Wassermann, The future of programming, Communications of the ACM, 25(3) (March 1982).
- Page 373 and 374: 350 Chapter 28 ■ Teams Level of s
- Page 375 and 376: 352 Chapter 28 ■ Teams A chief pr
- Page 377 and 378: 354 Chapter 28 ■ Teams benefits o
- Page 379 and 380: 356 Chapter 28 ■ Teams • Furthe
- Page 381 and 382: 358 Chapter 29 ■ Software metrics
- Page 383 and 384: 360 Chapter 29 ■ Software metrics
- Page 385 and 386: 362 Chapter 29 ■ Software metrics
- Page 387 and 388: 364 Chapter 29 ■ Software metrics
- Page 389 and 390: 366 Chapter 29 ■ Software metrics
- Page 391 and 392: 368 Chapter 29 ■ Software metrics
- Page 393 and 394: CHAPTER 30 This chapter: 30.1 ● I
- Page 395 and 396: 372 Chapter 30 ■ Project manageme
- Page 397 and 398: 374 Chapter 30 ■ Project manageme
- Page 399 and 400: 376 Chapter 30 ■ Project manageme
- Page 401 and 402: 378 Chapter 30 ■ Project manageme
- Page 403 and 404: 380 Chapter 30 ■ Project manageme
- Page 405 and 406: 382 Chapter 30 ■ Project manageme
- Page 408 and 409: CHAPTER 31 This chapter: 31.1 ● I
- Page 410 and 411: 31.3 Case study - assessing verific
- Page 412 and 413: 31.5 A single development method? 3
- Page 414 and 415: Further reading 391 31.2 Draw up a
- Page 416 and 417: 32.3 ● The world of programming l
- Page 418 and 419: 32.5 ● The real world of software
- Page 420 and 421: 32.6 Control versus skill 397 Final
- Page 422 and 423: Formal methods 32.7 Future methods
- Page 426: Further reading 403 An extensive tr
- Page 430 and 431: APPENDIX A Case studies are used th
- Page 432 and 433: Figure A.1 Cyberspace invaders A.4
- Page 434 and 435: APPENDIX B Glossary Within the fiel
- Page 436 and 437: C.2 ● Class diagrams C.2 Class di
- Page 438 and 439: util Figure C.6 A package diagram S
- Page 440 and 441: References to books and websites ar
- Page 442 and 443: abstraction 99, 107 acceptance test
- Page 444 and 445: fork 324 formal methods 276, 388, 3
- Page 446 and 447: quality 18, 362 quality assurance 1
Summary 401<br />
In the short-term future, it seems likely that we will continue to see enormous ef<strong>for</strong>t<br />
spent in developing tools and in ensuring that a set of tools fits together in an integrated<br />
manner. At the same time we can expect that end users will carry out their own system<br />
development using software packages that require them to know little about the<br />
computer. Coupled with the availability of inexpensive applications packages, the applications<br />
programmer seems (as ever) doomed.<br />
In the long term, the nature of programming itself could be trans<strong>for</strong>med by a declarative<br />
style of programming in which the programmer describes a solution to a problem<br />
rather than having to specify explicitly how that solution is to be obtained.<br />
While the applications programmer may vanish, the role of the systems programmers<br />
may be enhanced. Their mission will be to develop products of high quality – reliable,<br />
powerful and easy to use. The skills involved in their development may be considerable –<br />
not least in the requirement to create demonstrably reliable software, perhaps using <strong>for</strong>mal,<br />
mathematical approaches. At the other end of the spectrum, the analyst will not<br />
become extinct. Their role will be to guide users and an organization in making best use<br />
of the available packages.<br />
The general trend seems to be:<br />
■ the increasing scrutiny of the software development task<br />
■ systematization of software development<br />
■ the division of labor amongst specialists<br />
■ the automation of tasks using tools<br />
■ software reuse.<br />
Summary<br />
<strong>Software</strong> development methods have changed dramatically in the past and look set<br />
to do so in the future. The trend is towards the increased use of packages, program<br />
generators and automated tools.<br />
Long-term, traditional procedural programming languages may vanish to be<br />
replaced by declarative languages (functional and or logic languages) – at least <strong>for</strong><br />
application programming.<br />
There is sometimes a tension between the desire to exercise control during project<br />
management and the individual programmer’s desire <strong>for</strong> autonomy.<br />
One thing is certain: software engineering will continue to be supremely challenging,<br />
creative and enjoyable.
Change language