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 based on the resulting tion for the waterfall model. It is also basic scheme has encountered some more operational experience, and to reder- fundamental difficulties, and these have based on the often-unrealistic assumption ive, reoptimize, and exercise the led to the formulation of alternative pro- that the user’s operational system will be adjusted software product. cess models. flexible enough to accommodate A primary source of difficulty with the unplanned evolution paths. This assump- The transform model thus bypasses the waterfall model has been its emphasis on tion is unjustified in three primary circum- difficulty of having to modify code that fully elaborated documents as completion stances: has become poorly structured through criteria for early requirements and design (I) Circumstances in which several repeated reoptimizations, since the phases. For some classes of software, such independently evolved applications must modifications are made to the specifica- as compilers or secure operating systems, subsequently be closely integrated. tion. It also avoids the extra time and this is the most effective way to proceed. (2) “Information-sclerosis” cases, in expense involved in the intermediate However, it does not work well for many which temporary work-arounds for soft- design, code, and test activities. classes of software, particularly interactive ware deficiencies increasingly solidify into Still, the transform model has various

May 1988 63

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. A Cumulative cost f"

Progress through steps

Evaluate alternatives, Determine

Commitment Review ~- part it ion

Develop- Requirements

Plan next phases

Develop, verify next-level product

Figure 2. Spiral model of the software process.

difficulties. Automatic transformation Additionally, it would face a formidable The spiral model capabilities are only available for small knowledge-base-maintenance problem in products in a few limited areas: spread- dealing with the rapidly increasing and sheets, small fourth-generation language evolving supply of reusable software com- The spiral model of the software process applications, and limited computer- ponents and commercial software (see Figure 2) has been evolving for several science domains. The transform model products. (Simply consider the problem of years, based on experience with various also shares some of the difficulties of the tracking the costs, performance, and fea- refinements of the waterfall model as evolutionary development model, such as tures of all commercial database manage- applied to large government software the assumption that users' operational sys- ment systems, and automatically choosing projects. As will be discussed, the spiral tems will always be flexible enough to sup- the best one to implement each new or model can accommodate most previous port unplanned evolution paths. changed specification .) models as special cases and further pro-

64 COMPUTER

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. vides guidance as to which combination of base for future product evolution, the sub- increments for successive development or previous models best fits agiven software sequent risk-driven steps would be the components to be developed by indicidual situation. Development of the TRW Soft- evolving series of evolutionary prototypes organizations or persons. For the latter ware Productivity System (TRW-SPS), going toward the right in Figure 2. In this case, visualize a series of parallel spiral described in the next section, is its most case, the option of writing specifications cycles, one for each component, adding a complete application to date. would be addressed but not exercised. third dimension to the concept presented The radial dimension in Figure 2 Thus, risk considerations can lead to a in Figure 2. For example, separate spirals represents the cumulative cost incurred in project implementing only a subset of all can be evolving for separate software com- accomplishing the steps to date; the angu- the potential steps in the model. ponents or increments. Thus, the review- lar dimension represents the progress On the other hand, if previous prototyp- and-commitment step may range from an made in completing each cycle of the spi- ing efforts have already resolved all of the indibidual walk-through of the design of ral. (The model reflects the underlying performance or user-interface risks, and a single programmer’s component to a concept that each cycle involves a progres- program development or interface-control major requirements review involving sion that addresses the same sequence of risks dominate, the next step follows the developer, customer, user, and main- steps, for each portion of the product and basic waterfall approach (concept of oper- tenance organizations. for each of its levels of elaboration, from ation, software requirements, preliminary an overall concept of operation document design, etc. in Figure 2), modified as Initiating and terminating the spiral. down to the coding of each individual pro- appropriate to incorporate incremental Four fundamental questions arise in con- gram.) Note that some artistic license has development. Each level of software spec- sidering this presentation of the spiral been taken with the increasing cumulative ification in the figure is then followed by model: cost dimension to enhance legibility of the a validation step and the preparation of (1) How does the spiral ever get steps in Figure 2. plans for the succeeding cycle. In this case, started? the options to prototype, simulate, model, (2) How do you get off the spiral when A typical cycle of the spiral. Each cycle etc. are addressed but not exercised, lead- it is appropriate to terminate a proj- of the spiral begins with the identification ing to the use of a different subset of steps. ect early? of This risk-driven subsetting of the spiral (3) Why does the spiral end so the objectives of the portion of the model steps allows the model to accommo- abruptly? product being elaborated (perfor- date any appropriate mixture of a (4) What happens to software enhance- mance, functionality, ability to specification-oriented, prototype- ment (or maintenance)? accommodate change, etc.); oriented, simulation-oriented, automatic The answer to these questions involves the alternative means of implement- transformation-oriented, or other an observation that the spiral model ing this portion of the product (design approach to software development. In applies equally well to development or A, design B, reuse, buy, etc.); and such cases, the appropriate mixed strategy enhancement efforts. In either case, the the constraints imposed on the appli- is chosen by considering the relative mag- spiral gets started by a hypothesis that a cation of the alternatives (cost, sched- nitude of the program risks and the rela- particular operational mission (or set of ule, interface, etc.). tive effectiveness of the various techniques missions) could be improved by a software The next step is to evaluate the alterna- in resolving the risks. In a similar way, effort. The spiral process then involves a tives relative to the objectives and con- risk-management considerations can test of this hypothesis: at any time, if the straints. Frequently, this process will determine the amount of time and effort hypothesis fails the test (for example, if identify areas of uncertainty that are sig- that should be devoted to such other proj- delays cause a software product to miss its nificant sources of project risk. If so, the ect activities as planning, configuration market window, or if a superior commer- next step should involve the formulation management, quality assurance, formal cial product becomes available), the spiral of a cost-effective strategy for resolving verification, and testing. In particular, is terminated. Otherwise, it terminates the sources of risk. This may involve pro- risk-driven specifications (as discussed in with the installation of new or modified totyping, simulation, benchmarking, the next section) can have varying degrees software, and the hypothesis is tested by reference checking, administering user of completeness, formality, and granular- observing the effect on the operational questionnaires, analytic modeling, or ity, depending on the relative risks of mission. Usually, experience with the combinations of these and other risk- doing too little or too much specification. operational mission leads to further resolution techniques. An important feature of the spiral hypotheses about software improvements, Once the risks are evaluated, the next model, as with most other models, is that and a new maintenance spiral is initiated step is determined by the relative remain- each cycle is completed by a review involv- to test the hypothesis. Initiation, termina- ing risks. If performance or user-interface ing the primary people or organizations tion, and iteration of the tasks and risks strongly dominate program develop- concerned with the product. This review products of previous cycles are thus ment or internal interface-control risks, covers all products developed during the implicitly defined in the spiral model the next step may be an evolutionary devel- previous cycle, including the plans for the (although they’re not included in Figure 2 opment one: a minimal effort to specify next cycle and the resources required to to simplify its presentation). the overall nature of the product, a plan carry them out. The review’s major objec- for the next level of prototyping, and the tive is to ensure that all concerned parties development of a more detailed prototype are mutually committed to the approach Using the spiral model to continue to resolve the major risk issues. for the next phase. If this prototype is operationally useful The plans for succeeding phases may ‘The various rounds and activities and robust enough to serve as a low-risk also include a partition of the product into involved in the spiral model are best under-

May 1988 65

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. stood through use of an example. The spi- discussed and are followed by some exam- potentially high-leverage improve- ral model was used in the definition and ples from later rounds, such as preliminary ments were not compatible with some development of the TRW Software Pro- and detailed design. aspects of the “TRW culture.” ductivity System (TRW-SPS), an inte- The risk-resolution activities under- grated software engineering environ- Round 0: Feasibility study. This study taken in Round 0 were primarily surveys ment.6 The initial mission opportunity involved five part-time participants over a and analyses, including structured inter- coincided with a corporate initiative to two- to three-month period. As indicated views of software developers and improve productivity in all appropriate in Table 1, the objectives and constraints managers, an initial analysis of productiv- corporate operations and an initial were expressed at a very high level and in ity leverage factors identified by the con- hypothesis that software engineering was qualitative terms like “significantly structive cost model (Cocomo)’; and an an attractive area to investigate. This led increase,” “at reasonable cost,” etc. analysis of previous projects at TRW to a small, extra “Round 0” circuit of the Some of the alternatives considered, exhibiting high levels of productivity. spiral to determine the feasibility of primarily those in the “technology” area, The risk analysis results indicated that increasing software productivity at a could lead to development of a software significant productivity gains could be reasonable corporate cost. (Very large or product, but the possible attractiveness of achieved at a reasonable cost by pursuing complex software projects will frequently a number of non-software alternatives in an integrated set of initiatives in the four precede the “concept of operation” round the management, personnel, and facilities major areas. However, some candidate of the spiral with one or more smaller areas could have led to a conclusion not to solutions, such as a software support envi- rounds to establish feasibility and to embark on a software development ronment based on a single, corporate, reduce the range of alternative solutions activity. maxicomputer-based time-sharing system, quickly and inexpensively.) The primary risk areas involved possi- were found to be in conflict with TRW Tables 1,2, and 3 summarize the appli- ble situations in which the company would constraints requiring support of different cation of the spiral model to the first three invest a good deal only to find that levels of security-classified projects. Thus, rounds of defining the SPS. The major resulting productivity gains were not even at a very high level of generality of features of each round are subsequently significant, or objectives and constraints, Round 0 was able to answer basic feasibility questions and eliminate significant classes of candidate solutions. The plan for Round 1 involved commitment of 12 man-months compared to the Table 1. Spiral model usage: TRW Software Productivity System, Round 0. two man-months invested in Round 0 (during these rounds, all participants were Objectives Significantly increase software productivity part-time). Round 1 here corresponded fairly well to the initial round of the spiral Constraints At reasonable cost model shown in Figure 2, in that its intent Within context of TRW culture was to produce a concept of operation and Government contracts, high tech., people oriented, a basic life-cycle plan for implementing security whatever preferred alternative emerged. Alternatives Management: Project organization, policies, planning, control Round 1: Concept of operations. Table Personnel: Staffing, incentives, training 2 summarizes Round 1 of the spiral along Technology: Tools, workstations, methods, reuse the lines given in Table 1 for Round 0. The Facilities: Offices, communications features of Round 1 compare to those of Round 0 as follows: Risks May be no high-leverage improvements The level of investment was greater Improvements may violate constraints (12 versus 2 man-months). Risk resolution lnternal surveys The objectives and constraints were Analyze cost model more specific (“double software produc- Analyze exceptional projects tivity in five years at a cost of $1O,OOO a Literature search person” versus “significantly increase productivity at a reasonable cost”). Risk resolution results Some alternatives infeasible Additional constraints surfaced, such Single time-sharing system: Security as the preference for TRW products (par- Mix of alternatives can produce significant gains ticularly, a TRW-developed local area net- Factor of two in five years work (LAN) system). Need further study to determine best mix The alternatives were more detailed Plan for next phase Six-person task force for six months (“SREM, PSL/PSA or SADT, as require- More extensive surveys and analysis ments tools etc.” versus “tools”; “pri- Internal, external, economic vate/shared” terminals, “smart/dumb” Develop concept of operation, economic rationale terminals versus “workstations”). Commitment Fund next Dhase The risk areas identified were more specific (“TRW LAN price-performance

66 COMPUTER

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. within a 510,000-per-person investment operation. ‘To keep these requirements in for requirements specification and constraint” versus “improvements may synchronization with the others, a special analysis. violate reasonable-cost constraint”). minispiral was initiated to address and The risk-resolution activities were resolve these issues. The resulting review It is also interesting to note that the form more extensive (including the benchmark- led to a commitment to a host-target oper- of Tables I, 2, and 3 was originally devel- ing and analysis of a prototype TRW LAN ation using Unix on the host system, at a oped for presentation purposes, but sub- being developed for another project). point early enough to work the OS- sequently became a standard “spiral The result was a fairly specific opera- dependent requirements in a timely model template” used on later projects. tional concept document, involving pri- fashion. These templates are useful not only for vate offices tailored to software work Addressing the risks of mismatches to organizing project activities, but also as a patterns and personal terminals connected the user-project’s needs and priorities residual design-rationale record. Design to VAX superminis via the TRW LAN. resulted in substantial participation of the rationale information is of paramount Some choices were specifically deferred to user-project personnel in the requirements importance in assessing the potential reus- the next round, such as the choice of oper- definition activity. This led to several sig- ability of software components on future ating system and specific tools. nificant redirections of the requirements, projects. Another important point to note The life-cycle plan and the plan for the particularly toward supporting the early is that the use of the template was indeed next phase involved a partitioning into sep- phases of the software life-cycle into which uniform across the three cycles, showing arate activities to address management the user project was embarking, such as an that the spiral steps can be and were uni- improvements, facilities development, and adaptation of the software requirements formly followed at successively detailed development of the first increment of a engineering methodology (SREM) tools levels of product definition. software development environment. The commitment step involved more than just an agreement with the plan. It committed to apply the environment to an upcoming 100-person testbed software project and to develop an environment Table 2. Spiral model usage: TRW Software Productivity System, Round 1. focusing on the testbed project’s needs. It also specified forming a representative Objectives Double software productivity in five years steering group to ensure that the separate Constraints 510,000 per person investment activities were well-coordinated and that Within context of TRW culture the environment would not be overly Government contracts, high tech., people oriented, optimized around the testbed project. security Although the plan recommended Preference for TRW products developing a prototype environment, it also recommended that the project employ Alternatives Office: Private/modular/. . . requirements specifications and design Communication: LAN/star/concentrators/. . . specifications in a risk-driven way. Thus, Terminals: Private/shared; smartldumb the development of the environment fol- Tools: SREM/PSL-PSA/. . .; PDL/SADT/. . . lowed the succeeding rounds of the spiral CPU: IBM/DEC/CDC/. . . model. Risks May miss high-leverage options TRW LAN price/performance Round 2: Top-level requirements spec- Workstation cost ification. Table 3 shows the corresponding Risk resolution Extensive external suneys, visits steps involved during Round 2 defining the TRW LAN benchmarking software productivity system. Round 2 Workstation price projections decisions and their rationale were covered in earlier work‘; here, we will summarize Risk resolution results Operations concept: Private offices, TRM’ LAN, personal the considerations dealing with risk terminals, VAX management and the use of the spiral Begin with primarily dumb terminals; experiment \\ith model: smart bvor k st a t ion s Defer operating system, tools selection The initial risk-identification activities during Round 2 showed that several sys- Plan for next phase Partition effort into software development environment tem requirements hinged on the decision (SDE), facilities, management between a host-target system or a fully Develop first-cut, prototype SDE portable tool set and the decision between Design-to-cost: 15-person team for one year VMS and Unix as the host operating sys- Plan for external usage tem. These requirements included the Commitment Develop prototype SDE functions needed to provide a user- Commit an upcoming project to use SDE friendly front-end, the operating system to Commit the SDE to support the project be used by the workstations, and the func- Form representative steering group tions necessary to support a host-target

May 1988 67

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. Succeeding rounds. It will be useful to the RTT specification is risk-driven. report-generation options, once the nature illustrate some examples of how the spiral In areas involving a high risk if the of these options was established in some model is used to handle situations arising design turned out to be wrong, the design example instances. in the preliminary design and detailed was carried down to the detailed design design of components of the SPS: the level, usually with the aid of rapid pro- A detailed design go-back. The UDF preliminary design specification for the totyping. These areas included working tool collects into an electronic “folder” all requirements traceability tool (RTT), and out the implications of “undo” options artifacts involved in the development of a a detailed design rework or go-back on the and dealing with the effects of control keys single-programmer software unit (typi- unit development folder (UDF) tool. used to escape from various program cally 500 to 1,000 instructions): unit levels. requirements, design, code, test cases, test The K TTpreliminary design specifica- In areas involving a moderate risk if the results, and documentation. It also tion. The RTT establishes the traceability design was wrong, the design was carried includes a management template for track- between itemized software requirements down to a preliminary-design level. These ing the programmer’s scheduled and specifications, design elements, code ele- areas included the basic command options actual completion of each artifact. ments, and test cases. It also supports var- for the tool and the schemata for the An alternative considered during ious associated query, analysis, and report requirements traceability database. Here detailed design of the UDF tool was reuse generation capabilities. The preliminary again, the ease of rapid prototyping with of portions of the RTT to provide pointers design specification for the RTT (and most Unix shell scripts supported agood deal of to the requirements and preliminary design of the other SPS tools) looks different user-interface prototyping. specifications of the unit being developed. from the usual preliminary design specifi- In areas involving a low risk if the design This turned out to be an extremely attrac- cation, which tends to show a uniform was wrong, very little design elaboration tive alternative, not only for avoiding level of elaboration of all components of was done. These areas included details of duplicate software development but also the design. Instead, the level of detail of all the help message options and all the for bringing to the surface several issues involving many-to-many mappings between requirements, design, and code that had not been considered in designing the UDF tool. These led to a rethinking of the UDF tool requirements and preliminary design, which avoided a great deal of Table 3. Spiral model usage: TRW Software Productivity System, Round 2. code rework that would have been necessary if the detailed design of the UDF tool 3bjectives User-friendly system had proceeded in a purely deductive, top- Integrated software, office-automation tools down fashion from the original UDF Support all project personnel requirements specification. The resulting Support all life-cycle phases go-back led to a significantly different, less costly, and more capable UDF tool, incor- Jonstraints Customer-deliverable SDE = Portability porating the RTT in its “uses-hierarchy.” Stable, reliable service Spiral model features. These two exam- \Iternatives OS: VMS/AT&T UnixIBerkeley Unix/lSC ples illustrate several features of the spiral Host-target/fully portable tool set approach. Workstations: Zenith/LSI-1 l/. . . It fosters the development of specifi- Cisks Mismatch to user-project needs, priorities cations that are not necessarily uniform, User-unfriendly system exhaustive, or formal, in that they defer 12-language syndrome; experts-only detailed elaboration of low-risk software Unix performance, support elements and avoid unnecessary breakage Workstation/mainframe compatibility in their design until the high-risk elements Risk resolution User-project surveys, requirements participation of the design are stabilized. Survey of Unix-using organizations It incorporates prototyping as a risk- Workstation study reduction option at any stage of development. In fact, prototyping and reuse risk Risk resolution results Top-level requirements specification analyses were often used in the process of Host-target with Unix host going from detailed design into code. Unix-based workstations It accorpmodates reworks or go-backs Build user-friendly front end for Unix to earlier stages as more attractive alterna- Initial focus on tools to support early phases tives are identified or as new risk issues Plan for next phase Overall development plan need resolution. for tools: SREM, RTT, PDL, office automation tools Overall, risk-driven documents, partic- for front end: Support tools ularly specifications and plans, are impor- for LAN: Equipment, facilities tant features of the spiral model. Great Commitment Proceed with olans amounts of detail are not necessary unless the absence of such detail jeopardizes the

68 COMPUTER

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. project. In some cases, such as with a It accornmodales preparation for life- product whose functionality may be deter- cycle evolution, growth, and changes of mined by a choice among commercial thesoftwareproduct. The major sources products, a set of weighted evaluation All of the projects of product change are included in the criteria for the products may be prefera- fuIIy using the system product’s objectives, and information- ble to a detailed pre-statement of func- hiding approaches are attractive architec- tional requirements. have increased their tural design alternatives in that they reduce productivity at least the risk of not being able to accommodate Results. The Software Productivity Sys- the product-charge objectives. tem developed and supported using the 50 percent. It provides a mechanism for incorporat- spiral model avoided the identified risks ing software quality objectives into soft- and achieved most of the system’s objec- wure product development. This tives. The SPS has grown to include over mechanism derives from the emphasis on as getting the wrong user interface or not 300 tools and over 1,300,000 instructions; identifying all types of objectives and con- meeting stringent performance require- 93 percent of the instructions were reused straints during each round of the spiral. ments, and if it has a high risk in budget from previous project-developed, TRW- For example, Table 3 shows user- and schedule predictability and control, developed, or external-software packages. friendliness, portability, and reliability as then these risk considerations drive the spi- Over 25 projects have used all or portions specific objectives and constraints to be ral model into an equivalence to the water- of the system. All of the projects fully addressed by the SPS. In Table I, security fall model. using the system have increased their pro- constraints were identified as a key risk If a software product’s requirements ductivity at least 50percent; indeed, most item for the SPS. are very stable (implying a low risk of have doubled their productivity (when It focuses on eliminating errors and expensive design and code breakage due to compared with cost-estimation model unattractive alternatives early. The risk- requirements changes during develop- predictions of their productivity using tra- analysis, validation, and commitment ment), and if the presence of errors in the ditional methods). steps cover these considerations. software product constitutes a high risk to However, one risk area-that projects For each of the sources of project the mission it serves, then these risk con- with non-Unix target systems would not activity and resvurce expenditure, it siderations drive the spiral model to resem- accept a Unix-based host system-was answers the key question, “How much is ble the two-leg model of precise underestimated. Some projects accepted enough?” Stated another way, “How specification and formal deductive pro- the host-target approach, but for various much of requirements analysis, planning, gram development. reasons (such as customer constraints and configuration management, quality assur- If a project has a low risk in such areas zero-cost target machines) a good many ance, testing, formal verification, etc. as losing budget and schedule predictabil- did not. As a result, the system was less should a project do?” Using the risk- ity and control, encountering large-system widely used on TRW projects than driven approach, one can see that the integration problems, or coping with expected. This and other lessons learned answer is not the same for all projects and information sclerosis, and if it has a high have been incorporated into the spiral that the appropriate level of effort is deter- risk in such areas as getting the wrong user model approach to developing TRW’s mined by the level of risk incurred by not interface or user decision support require- next-generation software development doing enough. ments, then these risk considerations drive environment. It does not involve separate approaches the spiral model into an equivalence to the for software development and software evolutionary development model. enhancement (or maintenance). This If automated software generation Evaluation aspect helps avoid the “second-class citi- capabilities are available, then the spiral zen” status frequently associated with model accommodates them either as Advantages. The primary advantage of software maintenance. It also helps avoid options for rapid prototyping or for appli- the spiral model is that its range of options many of the problems that currently ensue cation of the transform model, depending accommodates the good features of exist- when high-risk enhancement efforts are on the risk considerations involved. ing software process models, while its risk- approached in the same way as routine If the high-risk elements of a project driven approach avoids many of their dif- maintenance efforts. involve a mix of the risk items listed above, ficulties. In appropriate situations, the spi- Itprovides a viableframework for inte- then the spiral approach will reflect an ral model becomes equivalent to one of the grated hardware-soft ware system develop- appropriate mix of the process models existing process models. In other situa- ment. The focus on risk-management and above (as exemplified in the TRW-SPS tions, it provides guidance on the best mix on eliminating unattractive alternatives application). In doing so, its risk- of existing approaches to a given project; early and inexpensively is equally applica- avoidance features will generally avoid the for example, its application to the TRW- ble to hardware and software. SPS provided a risk-driven mix of specify- difficulties of the other models. ing, prototyping, and evolutionary devel- The spiral model has a number of addi- Difficulties. The full spiral model can be opment. tional advantages, summarized as follows: successfully applied in many situations, The primary conditions under which the It focuses early attention on options but some difficulties must be addressed spiral model becomes equivalent to other involving the reuse of existing software. before it can be called a mature, univer- main process models are summarized as The steps involving the identification and sally applicable model. The three primary follows: evaluation of alternatives encourage these challenges involve matching to contract If a project has a low risk in such areas options. software, relying on risk-assessment

May 1988 69

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. expertise, and the need for further elabo- software developments like the TRW- great deal of flexibility and freedom to ration of spiral model steps. SPS, but it needs further work to match it accommodate stage-by-stage commit- to the world of contract software acqui- ments, to defer commitments to specific Matching to contract software. The spi- sition. options, to establish minispirals to resolve ral model currently works well on internal internal software developments have a critical-path items, to adjust levels of effort, or to accommodate such practices as prototyping, evolutionary development, or design-to-cost. The world of contract software acquisition has a harder time achieving these degrees of flexibility Table 4. A prioritized top-ten list of software risk items. and freedom without losing accountabil- ity and control, and a harder time defin- Risk item Risk management techniques ing contracts whose deliverables are not 1. Personnel Staffing with top talent, job matching; teambuilding; well specified in advance. shortfalls morale building; cross-training; pre-scheduling key Recently, a good deal of progress has people been made in establishing more flexible contract mechanisms, such as the use of 2. Unrealistic Detailed, multisource cost and schedule estimation; competitive front-end contracts for con- design to cost; incremental development; software schedules and cept definition or prototype fly-offs, the budgets reuse; requirements scrubbing use of level-of-effort and award-fee con- 3. Developing the Organization analysis; mission analysis; ops-concept tracts for evolutionary development, and wrong software formulation; user surveys; prototyping; early users’ the use of design-to-cost contracts. functions manuals Although these have been generally suc- cessful, the procedures for using them still 4. Developing the Task analysis; prototyping; scenarios; user need to be worked out to the point that wrong user characterization (functionality, style, workload) acquisition managers feel fully comforta- interface ble using them. 5. Gold plating Requirements scrubbing; prototyping; cost-benefit analysis; design to cost Relying on risk-assessment expertise. 6. Continuing stream High change threshold; information hiding; incremental The spiral model places a great deal of reli- of requirement development (defer changes to later increments) ance on the ability of software developers changes to identify and manage sources of project risk. 7. Shortfalls in Benchmarking; inspections; reference checking; A good example of this is the spiral externally fur- compatibility analysis model’s risk-driven specification, which nished components carries high-risk elements down to a great 8. Shortfalls in Reference checking; pre-award audits; award-fee deal of detail and leaves low-risk elements externally contracts; competitive design or prototyping; to be elaborated in later stages; by this performed tasks teambuilding time, there is less risk of breakage. However, a team of inexperienced or 9. Real-time Simulation; benchmarking; modeling; prototyping; low-balling developers may also produce performance instrumentation; tuning a specification with a different pattern of shortfalls variation in levels of detail: a great elabo- 10. Straining Technical analysis; cost-benefit analysis; prototyping; ration of detail for the well-understood, computer-science reference checking low-risk elements, and little elaboration of capabilities the poorly understood, high-risk elements. Unless there is an insightful review of such a specification by experienced development or acquisition personnel, this type of project will give an illusion of progress during a period in which it is actually heading for disaster. Table 5. Software Risk Management Plan. Another concern is that a risk-driven specification will also be people- dependent. For example, a design 1. identify the project’s top 10 risk items. produced by an expert may be imple- 2. Present a plan for resolving each risk item. mented by non-experts. In this case, the 3. Update list of top risk items, plan, and results expert, who does not need a great deal of monthly. detailed documentation, must produce 4. Highlight risk-item status in monthly project reviews. enough additional documentation to keep Compare with previous month’s rankings, status. the non-experts from going astray. 5. Initiate appropriate corrective actions. Reviewers of the specification must also be

70 COMPUTER

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. NEW DOD sensitive to these concerns. Implications: The Risk Management SOFTWARE STANDARDS With a conventional, document-driven Plan. Even if an organization is not ready approach, the requirement to carry all to adopt the entire spiral approach, one DOD - STD =2167A I2168 aspects of the specification to a uniform characteristic technique that can easily be level of detail eliminates some potential adapted to any life-cycle model provides Denver, Colorado problems and permits adequate review of many of the benefits of the spiral DEFENSE SOFTWARE DEVELOPMENT some aspects by inexperienced reviewers. approach. This is the Risk Management (DOD-STD-2167A) But it also creates a large drain on the time Plan summarized in Table 5. This plan of the scarce experts, who must dig for the basically ensures that each project makes 11 -15 July critical issues within a large mass of non- an early identification of its top risk items critical detail. Furthermore, if the high- (the number 10 is not an absolute require- DEFENSE SOFTWARE CONFIGURATION risk elements have been glossed over by ment), develops a strategy for resolving the MANAGEMENT impressive-sounding references to poorly risk items, identifies and sets down an 18 - 22 July understood capabilities (such as a new syn- agenda to resolve new risk items as they chronization concept or a commercial surface, and highlights progress versus DBMS), there is an even greater risk that plans in monthly reviews. DEFENSE SOFTWARE QUALITY ASSURANCE (DOD-STD-2168) the conventional approach will give the The Risk Management Plan has been illusion of progress in situations that are used successfully at TRW and other 25 - 29 July actually heading for disaster. organizations. Its use has ensured appropriate focus on early prototyping, simula- DEFENSE SOFTWARE RELIABILITY tion, benchmarking, key-person staffing Need for further elaboration of spiral 1 - 4 August modelsteps. In general, the spiral model measures, and other early risk-resolution process steps need further elaboration to techniques that have helped avoid many 13th Annual Series - Summer 1988 ensure that all software development par- potential project “show-stoppers.” The Defense Software Management Courses ticipants are operating in a consistent recent US Department of Defense stan- context. dard on software management, DoD- INFO / FLIER / REGISTRATION Std-2167, requires that developers produce Some examples of this are the need for TREC Software Enterprises Corporation and use risk management plans, as does its more detailed definitions of the nature of Software Management Training Institute counterpart US Air Force regulation, AFR 31220 La Baya Drive. 110, Westlake Village, Ca. 91362 spiral model specifications and milestones, (818) 889-7814 800-14. the nature and objectives of spiral model Overall, the Risk Management Plan and reviews, techniques for estimating and Reader Service Number 3 the maturing set of techniques for software synchronizing schedules, and the nature of spiral model status indicators and cost- risk management provide a foundation for tailoring spiral model concepts into the versus-progress tracking procedures. An- more established software acquisition and other need is for guidelines and checklists development procedures. to identify the most likely sources of project risk and the most effective risk- e can draw four conclusions resolution techniques for each source of from the data presented: risk. W (1) The risk-driven nature Highly experienced people can success- of the spiral model is more adaptable to the fully use the spiral approach without these full range of software project situations elaborations. However, for large-scale use than are the primarily document-driven in situations where people bring widely approaches such as the waterfall model or differing experience bases to the project, the primarily code-driven approaches such added levels of elaboration-such as have as evolutionary development. It is partic- been accumulated over the years for ularly applicable to very large, complex, document-driven approaches-are impor- ambitious software systems. tant in ensuring consistent interpretation (2) The spiral model has been quite suc- and use of the spiral approach across the cessful in its largest application to date: the project. development and enhancement of the Efforts to apply and refine the spiral TRW-SPS. Overall, it achieved a high level model have focused on creating a dis- of software support environment capabil- cipline of software risk management, ity in a very short time and provided the including techniques for risk identifica- flexibility necessary to accommodate a tion, risk analysis, risk prioritization, risk- high dynamic range of technical alterna- management planning, and risk-element tives and user objectives. tracking. The prioritized top-ten list of (3) The spiral model is not yet as fully software risk items given in Table 4 is one elaborated as the more established models. result of this activity. Another example is Therefore, the spiral model can be applied the risk management plan discussed in the by experienced personnel, but it needs fur- next section. ther elaboration in such areas as contract-

May 1988

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply. ing, specifications, milestones, reviews, Overall process model issues and results Model,” Proc. Fourth Software Process scheduling, status monitoring, and risk- Workshop, IEEE, May 1988. Agresti’s tutorial volume provides a good over- area identification to be fully usable in all view and set of key articles. The three recent Iivari, J., “A Hierarchical Spiral Model situations. Software Process Workshop Proceedings pro- for the Software Process,” ACM Software (4) Partial implementations of the spi- vide access to much of the recent work in the Engineering Notes, Jan. 1987, pp. 35-37. ral model, such as the Risk Management area. Some similar cyclic spiral-type process models Plan, are compatible with most current Agresti, W.W., New Paradigms for Soft- from other fields are described in: process models and are very helpful in ware Development, IEEE Catalog No. overcoming major sources of project EH0245-1, 1986. Carlsson, B., P. Keane, and J.B. Martin, risk. 0 “R&D Organizations as Learning Sys- Dowson, M., ed., Proc. Third Int’lSoft- tems,” SIoan Management Review, Spring ware Process Workshop, IEEE Catalog 1976, pp. 1-15. NO. TH0184-2, NOV.1986. Fisher, R., and W. Ury, Getting to Yes, Acknowledgments Potts, C., ed., Proc. Software Process Houghton Mifflin, 1981; Penguin Books, Workshop, IEEE Catalog No. 1983, pp. 68-71. I would like to thank Frank Belz, Lolo 84CH2044-6, Feb. 1984. Penedo, George Spadaro, Bob Williams, Bob Kolb, D.A., “On Management and the Balzer, Gillian Frewin, Peter Hamer, Manny Wileden, J.C., and M. Dowson, eds., Learning Process,” MIT Sloan School Lehman, Lee Osterweil, Dave Parnas, Bill Rid- Proc. Int’l Workshop Software Process Working Article 652-73, Cambridge, dle, Steve Squires, and Dick Thayer, along with and Software Environments, ACM Soft- Mass., 1973. the Computer reviewers of this article, for their ware Engineering Notes, Aug. 1986. stimulating and insightful comments and discus- sions of earlier versions of the article, and Nancy Software risk management Donato for producing its several versions. Alternative process models The discipline of software risk management pro- More detailed information on waterfall-type vides a bridge between spiral model concepts approaches is given in: and currently established software acquisition and development procedures. References Evans, M.W., P. Piazza, and J.P. Dolkas, 1. F.P. Brookset al., DefenseScienceBoard Principles of Productive Software Boehm, B.W., “Software Risk Manage- Task Force Report on Military Software, Management, John Wiley & Sons, 1983. ment Tutorial,” Computer Society, Apr. Office of the Under Secretary of Defense 1988. for Acquisition, Washington, DC 20301, Hice, G.F., W.J. Turner, and L.F. Cash- Sept. 1987. well, System Development Methodology, Risk Assessment Techniques, Defense Sys- 2. H.D. Benington, “Production of Large North Holland, 1974 (2nd ed., 1981). tems Management College, Ft. Belvoir, Va. 22060, July 1983. Computer Programs,” Proc. ONR Symp. More detailed information on evolutionary Advanced Programming Methods for Dig- development is provided in: italComputers, June 1956, pp. 15-27. Also available in Annals of the History of Com- Gilb, T., Principles of Software Engineer- puting, Oct. 1983, pp. 350-361, and Proc. ing Management, Addison Wesley, 1988 Ninth Int’l Conf. Software Engineering, (currently in publication). Computer Society Press, 1987. 3. W.W. Royce, “Managing the Development Some additional process model approaches with of Large Software Systems: Concepts and useful features and insights may be found in: Techniques,” Proc. Wescon, Aug. 1970. Also available in Proc. ICSE 9, Computer Lehman, M.M., and L.A. Belady, Pro- Society Press, 1987. gram Evolution: Processes of Software 4. D.D. McCracken and M.A. Jackson, Change, Academic Press, 1985. “Life-Cycle Concept Considered Harm- ful,” ACM Software Engineering Notes, Osterweil, L., “Software Processes are Apr. 1982, pp. 29-32. Software, Too,” Proc. ICSE 9, IEEE 5. R. Balzer, T.E. Cheatham, and C. Green, Catalog No. 87CH2432-3, Mar. 1987, pp. “Software Technologyin the 1990s: Using 2-13. a New Paradigm,” Computer, Nov. 1983, Barry W. Boehm is the chief scientist of the pp. 39-45. Radice, R.A., et al., “A Programming TRW Defense Systems Group. Since 1973, he 6. B.W. Boehmet al., “ASoftwareDevelop- Process Architecture,” IBMSystems J., has been responsible for developing TRW’s ment Environment for Improving Produc- Vol. 24, No.2, 1985, pp. 79-90. software technology base. His current primary tivity,” Computer, June 1984, pp. 30-44. responsibilities are in the areas of software environments, process models, management Software Engineering Eco- 7. B.W. Boehm, Spiral and spiral-type models methods, Ada, and cost estimation. He is also nomics, Prentice-Hall, 1981, Chap. 33. an adjunct professor at UCLA. Some further treatments of spiral model issues Boehm received his BA degree in and practices are: mathematics from Harvard in 1957 and his MA and PhD from UCLA in 1961 and 1964, respec- Further reading Belz, F.C., “Applying the Spiral Model: tively. Observations on Developing System Soft- The software process model field has an interest- ware in Ada,” Proc. 1986 Annual Conf. ing history, and a great deal of stimulating work on Ada Technology, Atlanta, 1986, pp. has been produced recently in this specialized 57-66. area. Besides the references that appear at the Readers may write to Boehm at TRW end of the accompanying article, here are some Boehm, B. W., and F.C. Belz, “Applying Defense Systems Group, One Space Park, additional good sources of insight: Process Programming to the Spiral R2/2086, Redondo Beach, CA 90278.

12 COMPUTER

Authorized licensed use limited to: The University of Arizona. Downloaded on January 9, 2009 at 12:01 from IEEE Xplore. Restrictions apply.