The Spiral Model as a Tool for Evolutionary Acquisition, Exercises of Software Engineering

Download The Spiral Model as a Tool for Evolutionary Acquisition and more Exercises Software Engineering in PDF only on Docsity! The Spiral Model as a Tool for Evolutionary Acquisition Dr. Barry Boehm Wilfred J. Hansen University of Southern California Software Engineering Institute Center for Software Engineering Best Practices Dr. Barry Boehm will speak at STC luncheon B on April 30 Since its original publication [1], the spiral development model diagrammed in Figure 1 has been used successfully in many defense and commercial projects. To extend this base of success, the Department of Defense (DoD) has recent- ly rewritten the defense acquisition regula- tions to incorporate “evolutionary acquisi- tion,” an acquisition strategy designed to mesh well with spiral development. In par- ticular, DoD Instruction 5000.2 subdi- vides acquisition [2]: “There are two ... approaches, evolu- tionary and single step to full capability. An evolutionary approach is preferred. … [In this] approach, the ultimate capa- bility delivered to the user is divided into two or more blocks, with increasing increments of capability.” (p. 20) Here, a block corresponds to a single product release. The text goes on to speci- fy the use of spiral development within blocks: “For both the evolutionary and single- step approaches, software develop- ment shall follow an iterative spiral development process in which contin- ually expanding software versions are based on learning from earlier devel- opment.” (p. 20) Given this reliance on the spiral develop- ment model, an in-depth definition is appropriate. Two recent workshops pro- vided one. The University of Southern California (USC) Center for Software Engineering and the Carnegie Mellon University Software Engineering Institute held two workshops last year to study spiral devel- opment and identify a set of critical suc- cess factors and recommended approaches. Their results appear in two reports, [3, 4] and are available on the workshop Web site www.sei.emu.edu/cbs/spiral2000 The first author’s presentations at these workshops defined spiral develop- ment and are followed below. The defini- tion was first converted to a report [5], where details, suggestions, and further ref- erences can be found. Additionally, a fol- low-on article appearing in a later !" # $ $ %& ' ( issue, will address the rela- tionships among spiral development, evo- lutionary acquisition, and the Integrated Capability Maturity Model. Spiral Development Definition and Context We can begin with a high-level definition of the spiral development model: The spiral development model is a risk- driven process model generator that is used to guide multi-stakeholder concur- rent engineering of software-intensive systems. It has two main distinguishing features. One is a cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk. The other is a set of anchor point milestones for ensur- ing stakeholder commitment to feasible and mutually satisfactory system solu- tions. The highlighted terms deserve further explanation: • Risks are situations or possible events that can cause a project to fail to meet its goals. They range in impact from trivial to fatal and in likelihood from certain to improbable. Since risk consid- erations dictate the path a development must take, it is important that those risks be cataloged candidly and com- pletely. See the references for taxonomy of risks [6] and a method for identifying them [7]. • A process model answers two main ques- tions: What should be done next? How long should it continue? Under the spi- ral model the answers to these questions are driven by risk considerations and Recent Department of Defence policy embodied in the new 5000.1 and 5000.2 series of acquisition regulations strong- ly emphasizes evolutionary acquisition and the use of spiral development for software. Spiral development has been used successfully in many commercial systems and in a good number of defense systems. But some ambiguities in pre- vious spiral model definitions has also led to a good number of unsuccessful projects adopting “hazardous spiral look- alikes.” This paper provides clearer definitions of a set of six Spiral Model Essentials or critical success factors for spiral development. It illustrates each with examples, identifies the hazardous look-alikes to avoid, and provides guidelines for using the spiral model in support of evolutionary acquisition. 4 !" # $ $ %& ' ( The Journal of Defense Software Engineering May 2001 Figure 1: Original Spiral Development Diagram vary from project to project and some- times from one spiral cycle to the next. Each choice of answers generates a dif- ferent process model. • The cyclic nature of the spiral model is illustrated in Figure 1. Rather than develop the completed product in one step, multiple cycles are performed with each taking steps calculated to reduce the most significant remaining risks. • Each anchor point milestone is a specific combination of artifacts and conditions that must be attained at some point. The sequence of three anchor point milestones — “LCO,” “LCA,” and “ICO” — is defined in Spiral Essential 5 (to be discussed). These milestones impel the project toward completion and offer a means to compare progress between one project and another. Many aspects of spiral development are omitted in the above definition. The remainder of this paper expands the defi- nition by describing six essential aspects that every proper spiral process must exhibit. The essentials are sketched in Figure 2. Each subsequent section describes a Spiral Essential, the critical suc- cess factor, reasons why it is necessary, and the variant process models it allows. Examples are given. Other process models that are precluded by the Spiral Essential are described. Because these may seem to be instances of the spiral model, but lack necessary essentials and thus risk failure, they are called “hazardous spiral look- alikes.” Spiral Essential 1: Concurrent Determination of Key Artifacts (Operational Concept, Requirements, Plans, Design, Code) For a successful spiral effort, it is vital to determine balanced portions of certain key artifacts concurrently and not sequentially. These key artifacts are the operational concept, the system and software require- ments, the plans, the system and software architecture and design, and the code components, including COTS, reused components, prototypes, success-critical components, and algorithms. Ignoring this Essential by sequentially determining the key artifacts will prematurely overcon- strain the project, and often extinguish the possibility of developing a product satis- factory to the stakeholders. Variants: Within the constraints of this Essential, variation is possible in the prod- uct and process internals of the concurrent engineering activity. For a low technology, interoperability-critical system, the initial spiral products will be requirements-inten- sive. For a high technology, more stand- alone system, the initial spiral products will be prototype-code intensive. Also, the Essential does not dictate the number of mini-cycles (e.g., individual prototypes for COTS, algorithms, or user-interface risks) within a given spiral cycle. Example: One-Second Response Time Examples of failure due to omission of this Essential include premature commitments to hardware platforms, incompatible com- binations of COTS components, and requirements whose achievability has not been validated. For instance, in the early 1980s, a large government organization contracted with TRW to develop an ambi- tious information system for more than a thousand users. This system was to be dis- tributed across a campus and offer power- ful query and analysis access to a large and dynamic database. Based largely on user need surveys and an oversimplified high- level performance analysis, TRW and the customer fixed into the contract a require- ment for a system response time of less than one second. Two thousand pages of requirements later, the software architects found that subsecond performance could only be pro- vided via a highly customized design that attempted to cache data and anticipate query patterns to be able to respond to each user within one second. The resulting hardware architecture had more than 25 super-minicomputers caching data accord- ing to algorithms whose actual perform- ance defied easy analysis. The estimated cost was $100 million; see the upper arc in Figure 3 (See page 6). Faced with this exorbitant cost, the customer and developer decided to devel- op and user-test a prototype. The results showed a four-second response time with 90 percent user satisfaction. This lower performance could be achieved with a modified client-server architecture, cut- ting development costs to $30 million as shown by the lower arc in the Figure 3 [8]. Concurrent prototyping would have saved two years’ time and large-project effort. Hazardous Spiral Look-Alike: Violation of Waterfall Assumptions Essential 1 excludes the use of an incre- mental sequence of waterfall develop- ments in the common case where there is a high risk of violating the assumptions underlying the waterfall model. These assumptions are that the requirements are pre-specifiable, slowly changing, and satis- factory to all stakeholders, and that a well understood architecture can meet these requirements. These assumptions must be met by a project if the waterfall model is to succeed. If all are true, then it is a project risk not to specify the requirements: the spiral-dictated risk analysis results in a waterfall approach for this project. If any assumption is false, then a waterfall approach will commit the project to trou- blesome assumptions and requirements May 2001 www.stsc.hill.af.mil 5 Figure 2: Pictorial Sketch of the Six Spiral Essentials The Spiral Model as a Tool for Evolutionary Acquisition commit to support building architecture; at LCA they commit to support initial deployment; at IOC they commit to sup- port operations. Together the anchor point milestones avoid analysis paralysis, unreal- istic expectations, requirements creep, architectural drift, COTS shortfalls and incompatibilities, unsustainable architec- tures, traumatic cutovers, and useless sys- tems. Variants: One appropriate variant of Essential 5 is the number of spiral cycles between anchor points. Another possible variant is to merge anchor points. In par- ticular, a project using a mature and appropriately scalable fourth generation language (4GL) or product line frame- work will have already determined its architecture by its LCO milestone, enabling the LCO and LCA milestones to be merged. Example: Stud Poker Analogy A valuable aspect of the spiral model is its ability to support incremental commit- ment of corporate resources rather than requiring a large outlay of resources to the project before its success prospects are well understood. Funding a spiral development can thus be likened to the game of stud poker. In that game, you put a couple of chips in the pot and receive two cards, one hidden and one exposed. If your cards don’t promise a winning outcome, you can drop out without a great loss. This corre- sponds to cancelling a project at or before LCO. If your two cards are both aces, you will probably bet on your prospects aggres- sively (or less so if you see aces among other players’ exposed cards). Dropping out of the second or third round of betting corresponds to cancelling at or before LCA. In any case, based on information available, you can decide during each round whether it’s worth putting more chips in the pot to buy more information or whether it’s better not to pursue this particular deal or project. Hazardous Look-Alike: Evolutionary Development Without Life Cycle Architecture The LCO and LCA milestones’ pass-fail criteria emphasize that the system’s archi- tecture must support not just the initial increment’s requirements, but also the sys- tem’s evolutionary life-cycle requirements. This avoids the hazardous spiral look-alike of an initial increment optimized to pro- vide an impressive early system demon- stration or limited release, but without the architecture to support full-system requirements for security, fault-tolerance, or scalability to large workloads. Other important considerations for LCA are that the initial release ensure continued key stakeholder participation, that the user organizations are flexible enough to adapt to the pace of system evolution, and that legacy-system replacement be well thought out. Ignoring these aspects lead to other hazardous spiral look-alike processes. Spiral Essential 6: Emphasis on System and Life Cycle Activities and Artifacts Spiral Essential 6 emphasizes that spiral development of software-intensive systems needs to focus not just on software con- struction aspects, but also on overall sys- tem and life-cycle concerns. Will the product satisfy stakeholders? Will it meet cost and performance goals? Will it inte- grate with existing business practices? Will it adapt to organizational changes? Software developers are apt to fall into the oft-cited trap: “If your best tool is a hammer, the world you see is a collection of nails.” Writing code may be a devel- oper’s forte, but it is as important to the project as are nails to a house. Variants: The model’s use of risk con- siderations to drive solutions makes it possible to tailor each spiral cycle to whatever mix of software and hardware, choice of capabilities, or degree of pro- ductization is appropriate. Example: Order Processing An example of failure to consider the whole system occurred with the Scientific American order processing system in Figure 5 [11]. Scientific American had hoped that computerizing the functions being performed on tabulator machines would reduce its subscription processing costs, errors, and delays. Rather than ana- lyze the sources of these problems, the software house focused on the part of the problem having a software solution. The result was a batch-processing computer system whose long delays put extra strain on the clerical portion of the system that had been the major source of costs, errors, and delays in the first place. The software people looked for the part of the problem with a software solution (their “nail”), pounded it in with their software hammer, and left Scientific American worse off than when they started. This kind of outcome would have resulted even if the software automating the tabulator-machine functions had been developed in a risk-driven cyclic approach. However, its Life Cycle Objectives mile- stone package would have failed its feasi- bility review, as it had no system-level business case demonstrating that the development of the software would lead to the desired reduction in costs, errors, and delays. Had a thorough business case analysis been done, it would have identi- fied the need to reengineer the clerical business processes as well as to automate the manual tab runs. Hazardous Spiral Look-Alikes: Logic-Only OO Designs Models excluded by Essential 6 include most published object-oriented analysis and design (OOA&D) methods, which are usually presented as abstract logical Best Practices 8 !" # $ $ %& ' ( The Journal of Defense Software Engineering May 2001 Figure 5: Scientific American Order Processing exercises independent of system perform- ance or economic concerns. For example, in a recent survey of 16 OOA&D books, only six listed the word “performance” in their index, and only two listed “cost.” Using the Spiral Model for Evolutionary Acquisition Both the February and September work- shops had working groups on the relation- ships between spiral development and evo- lutionary acquisition. A primary conclu- sion was that the relationships differ across two major DoD acquisition sectors: • Information systems, such as C4ISR sys- tems, logistics systems, and manage- ment systems, in which spiral and evo- lutionary models coincide well. • Software-intensive embedded hard- ware/software systems, in which the software aspects best follow a spiral approach, but the hardware aspects need to follow a more sequential approach to accommodate lead times for production facilities, production subcontracts, and long-lead critical component orders. Even for embedded systems, however, spiral approaches can be helpful for syn- chronizing hardware and software process- es, and for determining when to apply an evolutionary, incremental, or single-step acquisition strategy. For example, Xerox’s time-to-market process uses the spiral anchor point milestones as hardware/soft- ware synchronization points for its printer business line [12]. Rechtin and Maier adopt a similar approach in their book, the Art of Systems Architecting [13]. A good example of the use of a risk- driven spiral approach to determine a pre- ferred software/system acquisition strategy was originally developed for DoD’s MIL- STD-498, and subsequently incorporated in IEEE/EIA 12207 [14]. This approach distinguishes among single-step (once- through or waterfall), incremental, and evolutionary acquisition processes as shown in Table 1. Thus, evolutionary acquisition avoids defining all require- ments first, and proceeds in multiple development cycles, some of which involve distribution and usage of initial and intermediate operational capabilities. Table 2 shows how a spiral risk analy- sis can be performed during early integrat- ed product and process definition cycles to select the most appropriate acquisition process for a system. The example shown in Table 2 is for a fairly large, high-tech- nology C4ISR system. For such a system, the high risks of poorly-understood requirements and rapid technology changes push the decision away from once-through or incremental acquisition, while the needs for an early capability and for user feedback on full requirements push the decision toward evolutionary acquisition. If the system had been a small, lower-technology embedded system where all capabilities are needed at first delivery, the risk and opportunity factors would push the decision away from evolutionary and incremental acquisition toward once- through or single-step acquisition. Conclusion This paper has defined the spiral develop- ment model as a risk-driven process model generator with cyclic process execution and a set of three anchor point milestones. The definition was sharpened by present- ing a set of six “essential” attributes; that is, six attributes which every spiral devel- opment process must incorporate. These essentials are summarized in Table 3 (See page 10). Omission of each of these gives rise to process models that are cyclic or iterative, but are not examples of spiral development. These are called “hazardous spiral look-alikes.” Each was described and pilloried as part of describing the Essential it violates. Spiral development works fairly seam- lessly with evolutionary acquisition of information systems. For evolutionary acquisition of software-intensive embed- ded hardware-software systems, a mix of spiral and sequential processes is often needed. Even here, however, the spiral anchor points and risk-driven process selection approach are useful for determin- ing how best to synchronize the hardware and software processes.! References 1.Boehm, B., A Spiral Model of Software Development and Enhancement, Computer, May 1988, pp. 61-72. 2.Department of Defense Instruction 5000.2, Operation of the Defense May 2001 www.stsc.hill.af.mil 9 Table 1: Evolutionary Acquisition Distinctions [14] Development strategy Define all requirements first? Multiple develop- ment cycles? Distribute interim software? Once-Through (Waterfall) Yes No No Incremental (Preplanned Product Improvement) Yes Yes Maybe Evolutionary No Yes Yes The Spiral Model as a Tool for Evolutionary Acquisition Table 2: Spiral Risk Analysis for Process Selection [14] Acquisition System, September 2000, www.acq.osd.mil/ap/i50002p.doc 3.Hansen, W.; Foreman, J.; Carney, D; Forrester, E.; Graettinger, C.; Peterson, W.; and Place, P., Spiral Development Building the Culture: A Report on the CSE-SEI Workshop, February 2000, Software Engineering Institute, Carnegie Mellon University, Special Report CMU/SEI-2000-SR-006, July 2000, www/cbs/spiral2000/ february2000/finalreport.html 4.Hansen, W.; Foreman, J.; Albert, C.; Axelband, E.; Brownsword, L.; Forrester, E. ; and Place, P., Spiral Development and Evolutionary Acquisition: The SEI-CSE Workshop, September, 2000, Software Engineering Institute, Carnegie Mellon University, Special Report, in preparation. 5.Boehm, Barry, edited by Hansen, Wilfred J., Spiral Development: Experience, Principles, and Refinements, Software Engineering Institute, Carnegie Mellon University, Special Report CMU/SEI-00-SR-08, ESC-SR-00- 08, June, 2000, www/cbs/ spiral2000/febru ary2000/BoehmSR.html. 6.Carr, M. J.; Konda, S. L.; Monarch, I.; Ulrich, F. C., and Walker, C. F., Taxonomy-Based Risk Identification, Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-93-TR-6, ESC-TR-93-183, June,1993,www.sei.cmu.edu/legacy/ risk/kit/tr06.93.pdf 7. Williams, R. C.; Pandelios, G. J.; and Behrens, S.G., Software Risk Evaluation (SRE) Method Description (Version 2.0), Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-99-TR- 029, ESC-TR-99-029, December, 1999, www.sei.cmu.edu/pub/docu ments/99.reports/pdf/99tr029 body.pdf 8. Boehm, B., Unifying Software Engineering and Systems Engineering, IEEE Computer, March 2000, pp. 114-116. 9. Boehm, B., Software Risk Management, IEEE Computer Society Press, 1989. 10.Mehta, N., MBASE Electronic Process Guide, USC-CSE, Los Angeles, Calif., October 1999, sunset.usc.edu/research/ MBASE/EPG 11.Boehm, B., Software Engineering Economics, New York, N.Y., Prentice Hall, 1981. 12.Hantos, P., From Spiral to Anchored Processes: A Wild Ride in Lifecycle Building architecture, Proceedings, USC-SEI Spiral Experience Workshop, Los Angeles, Calif., Febuary 2000, www.sei.cmu.edu/cbs/spi ral2000/Hantos 13.Rechtin, E., and Maier, M., The Art of Systems Architecting, CRC Press, 1997. 14.IEEE and EIA, Industry Implementation of ISO/IEC 12207: Software Life Cycle Processes-Implementation Considerations, IEEE/EIA 12207.2 - 1997, April 1998. Article Web Site Location http://www.se i .cmu.edu/pub/docu ments/00.reports/pdf/00sr008.pdf 10 C R O S STA L K The Journal of Defense Software Engineering May 2001 Best Practices Table 3: Summary “It is impossible to make a program foolproof because fools are so ingenious.” Anonymous JAMO Pur MALADL JAPPOIYEIS "Z sauopsaqum yuyod. AOyIUE pe MEY g auojsayiu SAoppoyayeys SIIEWE Aay pO Woy ~OIAAP PALIN IIOS * 7 fo \Y, “Cover > [moueae aay 1 [feqap Jo aaasap SPIRPTLE AYIA ayy] PUT wmaysds wo siseyduy “9 Trap yo asap AUP STF aw cot .. SAM AE aul asucdsay € é BurdAjojo1g sayy gadg jeulbug = JaAIag-qUual|D PayIPoW sJOSS8901q ayoea Auew :woysny LR OD UU) Sad po TO oo —— sassoy poagaCq om (s80T) / ™ oe (ssorp) apy tan pas aunsod gy STH SassO] QUEYs JOYLEPY / == (en ~~  spsuraginbas [fy PU ysaopun op popaau si saucy ARopouyooy po Rees PEIUOLEUoUY og pa Tuyen TU py papoou st Aupiqudns <pnq SIUAUISU OLE SPE SYA WTR AS at ASAIO Is4yp TE soupides pe sraposd 328 q won sinbay sannennyoag PRLUaLOaIouT ag pj TU QUES, STU SUEMUSIOUY OH Alpena syn wis Papaou sr Apri Apr SHSSINbos sayy STE IN H won sbay PED Fy Aone 18 [7B taosAs ppo ine oseyd op seqgoud a8 9, AISA]/9P Id) TE saypqedes ype seagsud sa8q TY AAC TQE]IBAR EPG ao |e Ts pH W Aa JE IPE op oy aman] oo msTEAS H H POOISISPUN [Jak OU ane srsirog boy Ops bay YToay | -aouey (ABoymys sup osn oy sucsmogy sy Ayumediley 12a] (AR ops sayy sunita suosay } 4Srat tuo, ASO ce “deue-yuUYs ‘E169 “Eydje) UOMEZONpOsd —w SySU S00 vO ‘aoUEULaped Aquqedes + aucerade Yj spauye BIEMYOS “BA CUBPUE& SUOTRIOpISUES USUdORADp ID suRAYoS PaqAVO-aekIO /BAES| Aang 10 2) (Ee UL MOLE AA Bay “RUBE BO UID DEZIaRIOQNS BUTE Spy SIME PUE SAN ARIE A943 ay) pur WapsAs Uo Ssrseydurg “gp BLUBTSAB SS0)/08N PUB HIeNaTa SYAWNEW ‘SeuNl SSUCTSERLI Rod JO4joU po Guafivaus syrseds-Loy ens sraeuieeancue ssetnlighoduiooiy poe sienbus BINQOANIYIIE SIIAT-a stud SLOD ‘gu eee “dee! SueWANINbe OU Yin USUdopaKeD AEUOQNOAS JOYoUe HeaNeg SqUSWEIILE Oo saps jeids yO equ ‘suoE}edee ays jeauun ‘Sestjeued seAjeue spony S01 WOT 'OD7 :seuojsay)w yo JoYysueE yo aang ALONETWS WOKMYOSey HEU PaYESg 1G pUEND Spy WO) SIBP-PeMWEyeD JO ‘eoRpEYLT ada yee JEN ‘S109 10 suogeayoeds (ae ‘saBenGue) GumumuBoad soads puny SsyveM ui (sung ‘B2OD ‘Ered ‘syuaWeNbay 'q90) BS/CRUOS LD SHUBLSIS “TWIN OSG) SLCIBTUSSEuden ELE jo SO) eYLE Une jo AIGNOUE 6] YON MOY, SSUULEEaC] SUOPMAPISUOS YSU Aq UAALp [elap jo aashag “p YB}! BurGeuei oy PaaS Gu Ulin Lei peas a) gersaeeinl AS Yobe Ui PaSrpoud Soepye po [Meyp jo eebSP] LOOSE YEU PAYEdy 10 je Spidey meude/onep EMUeUALOUE 8 GSS dO ‘cwe aH RUONEY “UUIAVSSWeIN 208 yd ‘Bu Jo LRUOq KOR a aM SUaSL-ery SSATIAQIRE @NSUNC 0) PASN POLI jo AaIjOYS) -AYAN Ie user JO $1 YON OY, SAUIARAC) SUS e1apIEUO Ys] Aq UBALIp Heys Jo jaAaT oe apo Lome UIA AIAISe Yea wo yoya jo aT] SOA RUE “ya ‘Giuneays AJOL] SIMSUIN GURUOCEIa Ut O|Re PSIBEM SPINY SESE UO) PAPNIOKE BISNPOLSETS SoUsJa)6 “BUR PEUSus ‘Buyspow ‘LOEWE BRANELUATIE ASL AUEAD 20 fas yive Saseyd jeuids efWANbeg “Gucyoqod senbuyIe; UONNOSE Yeu po 89)04D — SAJEWGaIDeundEn/oyeNsLS Of VALID SpIOMY PEROT OF JUPWYWWUOS PUR MALAGU SYS) SOA EWUAYE “S]UJEISUGD ‘SeAIalQo Saop aps yORA Z sysu ABQ uyse] 40 ‘BORE TUL BRS LOG UF SS)AS-AUPLL LUELINSLIOS jo Seg, aot fainpayse /1809 49 488 S109 MeoyUbeS Wyn ep UO PEUIqUIOS “SOc “ub)sep ‘squewasmbas weysks sSgeyaqem jequanbes pyuaWwao) ote UI! PadopaAeP Oe LE Yoe yO JUNOLWE BAN eyY 0] SJURIELUWUOD RIWNboS SUT Spo Syey We Key Jo UoeUlUUayep jUOLINIUOD “| Saye yoo) Shope saeER eqaSEsS aM qweuiely |eHUess3 fePOW [ess