Software engineering

• Authors: B. W. Boehm
• Venue: Classics in software engineering
• Year: 1979

If someone said to me, "I have time to read only one of the papers in your collection," I would recommend this paper by Barry Boehm --- not because it is brilliant (although I think some of Boehm's insights border on brilliance) or because it revolutionized the field (the way some of Dijkstra's papers did), but simply because it is probably the best overall summary of the software field that I have yet seen published. If nothing else, Boehm's bibliography is stupendous, even outdoing the bibliography that Knuth provides in his "Structured Programming with go to Statements"! "Software Engineering" serves both as the title of Boehm's paper, and as a phrase used throughout his discussion. Like structured programming, it is a term that has been around for a few years, and now gradually is becoming accepted as the successor to the various phrases that incorporate the word "structured." As Boehm says in his introduction, "Software engineering is the means by which we attempt to produce all of this software in a way that is both costeffective and reliable enough to deserve our trust . . . . [It is] the practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate, and maintain them." Thus, the term clearly subsumes structured programming, structured design, and structured analysis, and it also includes some areas that largely have been ignored by other authors represented in this book. In essence, Boehm's paper is a survey of a wide range of topics, dealing with specific aspects of software development: requirements definition, software design, programming, testing and reliability, maintenance, and software management. Each section contains a short summary of current practice in the area, a survey of the frontier technology, and a summary of future trends. Boehm's treatment of frontier technology provides a barometer: For more information, the reader is directed to more than a hundred books and papers listed in the bibliography. As you read the survey, it will become evident that much of the EDP developmental work is being done either in the universities (where its real-world application always is suspect), or in the large aerospace/defense companies (where EDP problems are usually large, and where errors in systems analysis, design, or coding cannot be tolerated). Because such government/military projects may lead the industry by five to ten years in terms of technological development, we should see such frontier concepts as automated design systems appear in business applications in the mid-1980s. One of the most important aspects of Boehm's paper, in my opinion, is its emphasis on software testing and software maintenance. In the section on testing, there is a survey of software reliability models; software error data; half a dozen automated testing aids, such as test monitoring and output checking; test sufficiency; symbolic execution; and proofs of program correctness. In the maintenance area, Boehm provides statistics that should scare any responsible EDP manager to death: It is evident that by the mid-1980s, most organizations will spend more than sixty percent of their EDP budget on maintenance. Boehm devotes most of his attention to a discussion of how to do "good" maintenance on "good" programs; he largely ignores the issue of how to grapple with the maintenance of "bad" programs. Much of the EDP industry desperately needs help in this area, but there seems to be very little help to offer. Boehm concludes his paper with a review of software management, which he argues is in an even worse state than our programming and design technology. Once again, there are developments underway in this field, but they seem to be mostly restricted to large defense projects. Boehm closes with a note of concern: "What is rather surprising, and a bit disappointing, is the reluctance of the computer science field to address itself to the more difficult and diffuse problems . . . as compared to the more tractable . . . subjects of automata theory, parsing, computability, etc." Unfortunately, that concern, expressed in December 1976, still is valid today, and probably will be so for a number of years to come.