Barry Boehm Software Engineering Paper
Total Page:16
File Type:pdf, Size:1020Kb
1226 IEEE TRANSACTIONS ON COMPUTERS, VOL. C-25, NO. 12, DECEMBER 1976 Software Engineering BARRY W. BOEHM Abstract-This paper provides a definition of the term "software but also the associated documentation required to-develop, engineering" and a survey of the current state of the art and likely operate, and maintain the programs. By defining software future trends in the field. The survey covers the technology avail- able in the various phases of the software life cycle-requirements in this broader sense, we wish to emphasize the necessity engineering, design, coding, test, and maintenance-and in the of considering the generation oftimely documentation as overall area of software management and integrated technology- an integral portion of the software development process. management approaches. It is oriented primarily toward discussing We can then combine this with a definition of "engineer- the domain of applicability of techniques (where and when they ing" to produce the following definition. work), rather than how they work in detail. To cover the latter, an extensive set of 104 references is provided. Software Engineering: The practical application of scientific knowledge in the design and construction of Index Terms-Computer software, data systems, information computer programs and the associated documentation systems, research and development, software development, soft- required to develop, operate, and maintain them. ware engineering, software management. Three main points should be made about this definition. The first concerns the necessity of considering a broad I. INTRODUCTION enough interpretation of the word "design" to cover the r HE annual cost of software in the U.S. is extremely important activity of software requirements approximately 20 billion dollars. Its rate of growth is engineering. The second point is that the definition should considerably greater than that of the economy in general. cover the entire software life cycle, thus including those Compared to the cost of computer hardware, the cost of activities of redesign and modification often termed software is continuing to escalate along the lines predicted "software maintenance." (Fig. 2 indicates the overall set in Fig. 1 [1].1 A recent SHARE study [2] indicates further of activities thus encompassed in the definition.) The final that software demand over the years 1975-1985 will grow point is that our store of knowledge about software which considerably faster (about 21-23 percent per year) than can really be called "scientific knowledge" is a rather small the growth rate in software supply at current estimated base upon which to build an engineering discipline. But, growth rates ofthe software labor force and its productivity of course, that is what makes software engineering such a per individual, which produce a combined growth rate of fascinating challenge at this time. about 11.5-17 percent per year over the years 1975- The remainder of this paper will discuss the state of the 1985. art of software engineering along the lines ofthe software In addition, as we continue to automate many of the life cycle depicted in Fig. 2. Section III contains a discus- processes which control our life-style-our medical sion of software requirements engineering, with some equipment, air traffic control, defense system, personal mention of the problem of determining overall system records, bank accounts-we continue to trust more and requirements. Section IV discusses both preliminary de- more in the reliable functioning of this proliferating mass sign and detailed design technology trends. Section V of software. Software engineering is the means by which contains only a brief discussion of programming, as this we attempt to produce all of this software in a way that is topic is also covered in a companion article in this issue [3]. both cost-effective and reliable enough to deserve our trust. Section VI covers both software testing and the overall life Clearly, it is a discipline which is important to establish cycle concern with software reliability. Section VII dis- well and to perform well. cusses the highly important but largely neglected area of This paper will begin with a definition of "software en- software maintenance. Section VIII surveys software gineering." It will then survey the current state of the art management concepts and techniques, and discusses the of the discipline, and conclude with an assessment of likely status and trends of integrated technology-management future trends. approaches to software development. Finally, Section IX concludes with an assessment of the current state of the II. DEFINITIONS art of software engineering with respect to the definition above. Let us begin by defining "software engineering." We will Each section (sometimes after an introduction) contains define software to include not only computer programs, a short summary of current practice in the area, followed Manuscript received June 24, 1976; revised August 16, 1976. by a survey of current frontier technology, and concluding The author is with the TRW Systems and Energy Group, Redondo with a short summary of likely trends in the area. The Beach, CA 90278. 1 Another trend has been added to Fig. 1: the growth of software survey is oriented primarily toward discussing the domain maintenance, which will be discussed later. of applicability of techniques (where and when they work) BOEHM: SOFTWARE ENGINEERING 1227 Fig. 1. Hardware-software cost trends. Fig. 2. Software life cycle. rather than how they work in detail. An extensive set of [4], GTE [5], and TRW on the relative cost of correcting references is provided for readers wishing to pursue the software errors as a function of the phase in which they are latter. corrected. Clearly, it pays off to invest effort in finding requirements errors early and correcting them in, say, 1 III. SOFTWARE REQUIREMENTS ENGINEERING man-hour rather than waiting to find the error during operations and having to spend 100 man-hours correcting A. Critical Nature it. of Software Requirements Besides the cost-to-fix problems, there are other critical Engineering problems stemming from a lack of a good requirements is for specification. These include [6]: 1) top-down designing is Software requirements engineering the discipline for of developing a complete, consistent, unambiguous specifi- impossible, lack a well-specified "top"; 2) testing is cation-which can serve as a basis for common agreement impossible, because there is nothing to test against; 3) the among all parties concerned-describing what the soft- user is frozen out, because there is no clear statement of ware product will do (but not how it will do it; this is to be what is being produced for him; and 4) management is not done in the design specification). in control, as there is no clear statement ofwhat the project The extreme importance of such a specification is only team is producing. now becoming generally recognized. Its importance derives from two main characteristics: 1) it is easy to delay or avoid B. Current Practice doing thoroughly; and 2) deficiencies in it are very difficult Currently, software requirements specifications (when and expensive to correct later. they exist at all) are generally expressed in free-form En- Fig. 3 shows a summary of current experience at IBM glish. They abound with ambiguous terms ("suitable," 1228 IEEE TRANSACTIONS ON COMPUTERS, DECEMBER 1976 RELATIVE COST TO FIX ERROR 2 0.5 - 0.2 0. 1 REQUIREMENTS DESIGN CODE DEVELOPMENT ACCEPTANCE OPERATION TEST TEST PHASE IN WIHICH ERROR DETECTED Fig. 3. Software validatiorn: the price of procrastination. "sufficient," "real-time," "flexible") or precise-sounding aerospace, and government organizations have paid for it terms with unspecified definitions ("optimum," "99.9 and are successfully using it. The U.S. Air Force is cur- percent reliable") which are potential seeds of dissension rently using and sponsoring extensions to ISDOS under or lawsuits once the software is produced. They have nu- the Computer Aided Requirements Analysis (CARA) merous errors; one recent study [7] indicated that the first program. independent review of a fairly good software requirements ISDOS basically consists of a problem statement lan- specification will find from one to four nontrivial errors per guage (PSL) and a problem statement analyzer (PSA). page. PSL allows the analyst to specify his system in terms of The techniques used for determining software re- formalized entities (INPUTS, OUTPUTS, REAL WORLD quirements are generally an ad hoc manual blend of sys- ENTITIES), classes (SETS, GROUPS), relationships (USES, tems analysis principles [8] and common sense. (These are UPDATES, GENERATES), and other information on timing, the good ones; the poor ones are based on ad hoc manual data volume, synonyms, attributes, etc. PSA operates on blends of politics, preconceptions, and pure salesmanship.) the PSL statements to produce a number of useful sum- Some formalized manual techniques have been used suc- maries, such as: formated problem statements; directories cessfully for determining business system requirements, and keyword indices; hierarchical structure reports; such as accurately defined systems (ADS), and time au- graphical summaries of flows and relationships; and sta- tomated grid (TAG). The book edited by Couger and tistical summaries. Some of these capabilities are actually Knapp [9] has an excellent summary of such techniques. more suited to supporting system design activities; this is