A Spiral Model of Software Development and Enhancement
Total Page：16
File Type：pdf, Size：1020Kb
A Spiral Model of Software Development and Enhancement Barry W. Boehm, TRW Defense Systems Group “Stop the life cycle-I want to get off!’’ criteria for the current stage plus choice “Life-cycle Concept Considered criteria and entrance criteria for the next Harmful. ” stage. Thus, a process model addresses the “The waterfall model is dead.” This evolving- risk- following software project questions: “No, it isn’t, but it should be.” (1) What shall we do next? driven approach (2) How long shall we continue to do it? hese statements exemplify the provides a new Consequently, a process model differs current debate about software from a software method (often called a Iife-cycle process models. The framework for guiding T methodology) in that a method’s primary topic has recently received a great deal of the software process. focus is on how to navigate through each attention. phase (determining data, control, or The Defense Science Board Task Force ‘‘uses” hierarchies; partitioning functions; Report on Military Software‘ issued in allocating requirements) and how to rep- 1987 highlighted the concern that tradi- resent phase products (structure charts; tional software process models were dis- stimulus-response threads; state transition couraging more effective approaches to diagrams). software development such as prototyping Why are software process models and software reuse. The Computer Soci- spiral model; illustrate the application of the spiral model to a software project, important? Primarily because they pro- ety has sponsored tutorials and workshops vide guidance on the order (phases, incre- on software process models that have using the TRW Software Productivity Project as an example; summarize the pri- ments, prototypes, validation tasks, etc.) helped clarify many of the issues and in which a project should carry out its stimulated advances in the field (see “Fur- mary advantages and implications involved in using the spiral model and the major tasks. Many software projects, as ther reading”). the next section shows, have come to grief The spiral model presented in this arti- primary difficulties in using it at its current incomplete level of elaboration; and pre- because they pursued their various devel- cle is one candidate for improving the soft- opment and evolution phases in the wrong ware process model situation. The major sent resulting conclusions. order. distinguishing feature of the spiral model is that it creates a risk-driven approach to Evolution of process models. Before the software process rather than a primar- Background on software concentrating in depth on the spiral model, ily document-driven or code-driven pro- process models we should take a look at a number of cess. It incorporates many of the strengths others: the code-and-fix model, the stage- of other models and resolves many of their The primary functions of a software wise model and the waterfall model, the difficulties. process model are to determine the order evolutionary development model, and the This article opens with a short descrip- of the stages involved in software develop- transform model. tion of software process models and the ment and evolution and to establish the issues they address. Subsequent sections transition criteria for progressing from one The code-and-fix model. The basic outline the process steps involved in the stage to the next. These include completion model used in the earliest days of software May 1988 0018 9162/8X/0500-0061$01 00 1YX8 IEEE 61 Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. Figure 1. The waterfall model of the software life cycle. development contained two steps: mary difficulties: ware was such a poor match to users’ needs (1) Write some code. (a) After a number of fixes, the code that it was either rejected outright or (2) Fix the problems in the code. became so poorly structured that subse- expensively redeveloped. This made the Thus, the order of the steps was to do quent fixes were very expensive. This need for a requirements phase prior to some coding first and to think about the underscored the need for a design phase design evident. requirements, design, test, and main- prior to coding. (c) Code was expensive to fix because of tenance later. This model has three pri- (b) Frequently, even well-designed soft- poor preparation for testing and modifi- 62 COMPUTER Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. cation. This made it clear that explicit unchangeable constraints on evolution. recognition of these phases, as well as test- The following comment is a typical exam- and-evolution planning and preparation ple: “It’s nice that you could change those tasks in the early phases, were needed. The waterfall model equipment codes to make them more intel- has become the basis ligible for us, but the Codes Committee The stagewise and waterfall models. As just met and established the current codes early as 1956, experience on large software for most software as company standards.” systems such as the Semi-Automated acquisition standards. (3) Bridging situations, in which the Ground Environment (SAGE) had led to new software is incrementally replacing a the recognition of these problems and to large existing system. If the existing system the development of a stagewise model’ to is poorly modularized, it is difficult to pro- address them. This model stipulated that end-user applications. Document-driven vide a good sequence of “bridges” software be developed in successive stages standards have pushed many projects to between the old software and the expand- (operational plan, operational specifica- write elaborate specifications of poorly ing increments of new software. tions, coding specifications, coding, understood user interfaces and decision- Under such conditions, evolutionary parameter testing, assembly testing, support functions, followed by the design development projects have come to grief shakedown, system evaluation). and development of large quantities of by pursuing stages in the wrong order: The waterfall model,3illustrated in Fig- unusable code. evolving a lot of hard-to-change code ure 1, was a highly influential 1970 refine- These projects are examples of how before addressing long-range architectural ment of the stagewise model. It provided waterfall-model projects have come to and usage considerations. two primary enhancements to the stage- grief by pursuing stages in the wrong wise model: order. Furthermore, in areas supported by The transform model. The “spaghetti Recognition of the feedback loops fourth-generation languages (spreadsheet code” difficulties of the evolutionary between stages, and a guideline to or small business applications), it is clearly development and code-and-fix models can confine the feedback loops to suc- unnecessary to write elaborate specifica- also become a difficulty in various classes cessive stages to minimize the tions for one’s application before imple- of waterfall-model applications, in which expensive rework involved in feed- menting it. code is optimized for performance and back across many stages. becomes increasingly hard to modify. The The evolutionary development model. An initial incorporation of pro- transform model’ has been proposed as a The above concerns led to the formulation totyping in the software life cycle, solution to this dilemma. of the evolutionary development model,4 via a “build it twice” step running The transform model assumes the exis- whose stages consist of expanding incre- in parallel with requirements anal- tence of a capability to automatically con- ments of an operational software product, ysis and design. vert a formal specification of a software with the directions of evolution being product into a program satisfying the spec- The waterfall model’s approach helped determined by operational experience. ification. The steps then prescribed by the eliminate many difficulties previously The evolutionary development model is transform model are encountered on software projects. The ideally matched to a fourth-generation a formal specification of the best ini- waterfall model has become the basis for language application and well matched to tial understanding of the desired most software acquisition standards in situations in which users say, “I can’t tell product; government and industry. Some of its ini- you what 1 want, but 1’11 know it when I see automatic transformation of the it.” It gives users a rapid initial operational tial difficulties have been addressed by specification into code; adding extensions to cover incremental capability and provides a realistic opera- an iterative loop, if necessary, to development, parallel developments, pro- tional basis .for determining subsequent improve the performance of the gram families, accommodation of evolu- product improvements. resulting code by giving optimization tionary changes, formal software Nonetheless, evolutionary development guidance to the transformation also has its difficulties. It is generally dif- development and verification, and stage- system; ficult to distinguish it from the old code- wise validation and risk analysis. exercise of the resulting product; and and-fix model, whose spaghetti code and However, even with extensive revisions an outer iterative loop to adjust the and refinements, the waterfall model’s lack of planning were the initial motiva- specification