Boehm Barry W. A Spiral Model of Software Development and Enhancement

These statements exemplify the current debate about software life-cycle process models. The topic has recently received a great deal of attention.
The Defense Science Board Task Force Report on Military Software issued in 1987 highlighted the concern that traditional software process models were discouraging more effective approaches to software development such as prototyping and software reuse. The Computer Society has sponsored tutorials and workshops on software process models that have helped clarify many of the issues and stimulated advances in the field (see “Further Reading”).
The spiral model presented in this article is one candidate for improving the software process model situation. The major distinguishing feature of the spiral model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties.
This article opens with a short description of software process models and the issues they address. Subsequent sections outline the process steps involved in the spiral model; illustrate the application of the spiral model to a software project, using the TRW Software Productivity Project as an example; summarize the primary advantages and implications involved in using the spiral model and the primary difficulties in using it at its current incomplete level of elaboration; and present resulting conclusions.
Background on software process models
The primary functions of a software process model are to determine the order of the stages involved in software development and evolution and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus, a process model addresses the following software project questions:
(1) What shall we do next?
(2) How long shall we continue to do it’?
Consequently, a process model differs from a software method (often called a methodology) in that a method’s primary focus is on how to navigate through each phase (determining data, control, or “uses” hierarchies; partitioning functions; allocating requirements) and how to represent phase products (structure charts; stimulus — response threads; state transition diagrams).
Why are software process models important? Primarily because they provide guidance on the order (phases, increments, prototypes, validation tasks, etc.) in which a project should carry out its major tasks. Many software projects, as the next section shows, have come to grief because they pursued their various development and evolution phases in the wrong order.
Evolution of process models. Before concentrating in depth on the spiral model, we should take a look at a number of others: the code-and-fix model, the stage-wise model, the waterfall model, the evolutionary development model, and the transform model.
The code-and-fix model. The basic model used in the earliest days of software development contained two steps:
(1) Write some code.
(2) Fix the problems in the code.
Thus, the order of the steps was to do some coding first and to think about the requirements, design, test, and maintenance later. This model has three primary difficulties:
(a) After a number of fixes, the code became so poorly structured that subsequent fixes were very expensive. This underscored the need for a design phase prior to coding.
(b) Frequently, even well-designed software was such a poor match to users’ needs that it was either rejected outright or expensively redeveloped. This made the need for a requirements phase prior to design evident.
(c) Code was expensive to fix because of poor preparation for testing and modification. This made it clear that explicit recognition of these phases, as well as test and evolution planning and preparation tasks in the early phases, were needed.
The stagewise and waterfall models. As early as 1956, experience on large software systems such as the Semi-Automated Ground Environment (SAGE) had led to the recognition of these problems and to the development of a stagewise model2 to address them. This model stipulated that software be developed in successive stages (operational plan, operational specifications, coding specifications, coding, parameter testing, assembly testing, shakedown, and system evaluation).
The waterfall model,3 illustrated in Figure 1, was a highly influential 1970 refinement of the stagewise model. It provided two primary enhancements to the stagewise model:
(1) Recognition of the feedback loops between stages, and a guideline to confine the feedback loops to successive stages to minimize the expensive rework involved in feedback across many stages.
(2) An initial incorporation of prototyping in the software life cycle, via a “build it twice” step running in parallel with requirements analysis and design.1. F.P. Brooks et al., Defense Science Board Task Force Report on Military Software, Office of the Under Secretary of Defense for Acquisition, Washington, DC 20301, Sept. 1987.2. H.D. Benington, “Production of Large Computer Programs,” Proc. ONR Symp. Advanced Programming Methods for Digital Computers, June 1956, pp. 15–27. Also available in Annals of the History of Computing, Oct. 1983, pp. 350–361, and Proc. Ninth Int’l Conf Software Engineering, Computer Society Press, 1987.3. W.W. Royce, “Managing the Development of Large Software Systems: Concepts and Techniques,” Proc. Wescon, Aug. 1970. Also available in Proc. ICSE 9, Computer Society Press, 1987.4. D.D. McCracken and M.A. Jackson, “Life-Cycle Concept Considered Harmful,” ACM Software Engineering Notes, Apr. 1982, pp. 29–32.5. R. Balzer, T.E. Cheatham, and C. Green, “Software Technology in the I990s: Using a New Paradigm,” Computer, Nov. 1983, pp. 39–45.6. B.W. Boehm et al., “A Software Development Environment for Improving Productivity,” Computer, June 1984, pp. 30–44.7. B.W. Boehm, Software Engineering Economics, Prentice-Hall, 1981, Chap. 33.
Further reading
The software process model field has an interesting history, and a great deal of stimulating work has been produced recently in this specialized area. Besides the references to this article, here are some additional good sources of insight:
Overall process model issues and results
Agresti’s tutorial volume provides a good overview and set of key articles. The three recent Software Process Workshop Proceedings provide access to much of the recent work in the area.
Agresti, W.W., New Paradigms for Software Development, IEEE Catalog No. EH0245-1, 1986.
Dowson, M., ed., Proc. Third Int’l Software Process Workshop, IEEE Catalog No. TH0184-2, Nov. 1986.
Potts, C., ed., Proc. Software Process Workshop, IEEE Catalog No. 84CH2044-6, Feb. 1984.
Wileden, J.C., and M. Dowson, eds., Proc. Int’l Workshop Software Process and Software Environments, ACM Software Engineering Notes, Aug. 1986.
Alternative process models
More detailed information on waterfall-type approaches is given in:
Evans, M.W., P. Piazza, and J.P. Dolkas, Principles of Productive Software Management, John Wiley & Sons, 1983.
Hice, G.F., W.J. Turner, and L.F. Cashwell, System Development Methodology, North Holland, 1974 (2nd ed., 1981).
More detailed information on evolutionary development is provided in:
Gilb, T., Principles of Software Engineering Management, Addison-Wesley, 1988 (currently in publication).
Some additional process model approaches with useful features and insights may be found in:
Lehman, M.M., and L.A. Belady, Program Evolution: Processes of Software Change, Academic Press, 1985.
Osterweil, L., “Software Processes are Software, Too,” Proc. ICSE 9, IEEE Catalog No. 87CH2432-3, Mar. 1987, pp. 2–13.
Radice, R.A., et al., “A Programming Process Architecture,” IBM Systems J., Vol. 24, No. 2, 1985, pp. 79–90.
Spiral and spiral-type models
Some further treatments of spiral model issues and practices are:
Belz, F.C., “Applying the Spiral Model: Observations on Developing System Software in Ada,” Proc. 1986 Annual Conf. on Ada Technology, Atlanta, 1986, pp. 57–66.
Boehm, B.W., and F.C. Belz, “Applying Process Programming to the Spiral Model,” Proc. Fourth Software Process Workshop, IEEE, May 1988.
Iivari, J., “A Hierarchical Spiral Model for the Software Process,” ACM Software Engineering Notes, Jan. 1987, pp. 33–37.
Some similar cyclic spinal-type process models from other fields are described in:
Carlsson, B., P. Keane, and J.B. Martin, “R&D Organizations as Learning Systems,” Sloan Management Review, Spring 1976, pp. 1–15.
Fisher, R., and W. Ury, Getting to Yes, Houghton Mifflin, 1981; Penguin Books, 1983, pp. 68–71.
Kolb, D.A., “On Management and the Learning Process,” MIT Sloan School Working Article 652-73, Cambridge, Mass., 1973.
Software risk management
The discipline of software risk management provides a bridge between spiral model concepts and currently established software acquisition and development procedures.
Boehm, B.W., “Software Risk Management Tutorial,” Computer Society, Apr. 1988.
Risk Assessment Techniques, Defense Systems Management College, Ft. Belvoir, Va. 22060, July 1983.
Barry W. Boehm is the chief scientist of the TRW Defense Systems Group. Since 1973, he has been responsible for developing TRW’s software technology base. His current primary responsibilities are in the areas of software environments, process models, management methods, Ada, and cost estimation. He is also an adjunct professor at UCLA.
Boehm received his BA degree in mathematics from Harvard in 1957 and his MA and Ph.D. from UCLA in 1961 and 1964, respectively.