Scribd Logo
Upload

Welcome to Scribd!

  • Spiral Model Boehm

    Uploaded by

    Jhon
    4 views12 pages
    Modelo en espiral lectura en ingles

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    Modelo en espiral lectura en ingles

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    4 views12 pages

    Spiral Model Boehm

    Uploaded by

    Jhon
    Modelo en espiral lectura en ingles

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 12
    A Spiral Model of Software Development and Enhancement Barry W. Bohm, TRW Defense Systems Group “Stop the life cycle—1 want fo get off!" “Lifecycle Concept Considered Harmful." “The waterfall mode is dead.” “No, eet, but it shoul be,” hese statements exemplify the I Vcore debate about soltware Tie-ycle process models. The topics cently received great deal of The Defense Science Board Task Force Report on Miltary Software’ issued in 1987 highlighted the concern that tradi- tional software proces models were dis: ‘ouraging more effective approaches t0 Software development such s prototyping and software eeuse. The Computer Sok ey as sponsored morals and workshops fon software process models that have helped clarify many of the issues and stimulated advances inthe field (see “Fur ther reading”) “The spiral model presented in this at leis one candidate for improving thesott- ware process mode! situation, The major distinguishing Feature ofthe spiral modet isthatit creates risk driven approach to the software process rather than a primar- ity document-driven or codedriven ro: ‘ee Iincorporates many of the strengths ‘of other madels and resoives many of thei sificlis, Thisarticle opens with a short descrip tion of software process models andthe issues they address, Subsequent sections outline the proces steps involved in the May 1988, seaseee see eseeeeeeseeeseeeeeeay This evolving risk- driven approach provides a new framework for guiding the software process. spiral model illustrate the application of the spiral model co a sofbwate project, tsing the TRW Software Productivity Project san example; summarize the pi mary advantages and_ implications inyolved in using the spiral model and the primary dificulesin using tat iseurreat incomplete level af elaboration: and pre sent resulting conclusions. Background on software process models The primary functions of a software process model are to determine the order ff the stagesinvolvedin soliware develop: tment and evolution and to establish the transition criteria or progressing fromone stagetothe next. These include completion criteria For the current stage plus choice sriteria and entrance erteria fo the next stage. Thus, process model addresssthe Following software project questions (0) What shal we do nest? (2) How long shall wecontinueto doit? ‘Consequently, a process model differs from a software method (often called a methodology) in:hata method's primary focus son how to navigate through & phase (determining data, control, or "uses" hirarchies: patton funtion allocating requirements) and how to rep resent phase products (structure chats Stimulus-tesponse threads tate transition diagrams). Why ate software process. models important? Primarily because they pro ‘ide guidance on the order (phases, ncre- ‘ments, prototypes, validation asks, et.) in which a project should earry out its major tasks, Many software projets as tenet section shows, havecometo grief because they pursued their various devel ‘opment and evolution phassin the wrong order. Evolution of process models. Before concentrating in dep onthe spiral model, wwe should take a look at a number of bothers: the cade and-fix model, the stage: ‘wie model andthe waterfall model, the evolutionary development model, and the transform mode The code-and:fix model. The basic ‘model wed inthe earles days of software 6 requirement = [oc [eh ze ‘Operations and maintenar Figure 1. The waterfall model ofthe software life cycle. development contained two steps: () Write some code (2) Fix the problems in the code. ‘Ths, the order ofthe steps was to-do some cong first and to think about the requirements, design, test, and main tenance later. This model has three pi e sary difficulties: (@) Alter a number of fixes, the code ‘became so poorly structured that subse quent fixes were very expensive. This Lunderscored the need for a design phase prior to coding. () Frequently, even well-designed soft ware was sucha poor match touses' needs that it was either rejected outright or ‘expensively redeveloped, This made the need for a requirements phase prior (0 design evident. (@) Code was expensiveto fix because of oor preparation for esting and moditi- ‘COMPUTER tation. This made it clear that explicit recognition of these phases, as wells test- fnd-volution planning and preparation tasks in the early phases, were needed. The stageise and waterfall models. AS carly a 196, experience onlargesofiware Systems such as the Semi-Aucomated Ground Eaviconment (SAGE) had led 0 the recognition of these problems and to the development of a stagenise mode! 10 address them. This model stipulated that Software be developedin successive stages (operational plan, operational specifica ‘ions, coding. specications, coding, parameter testing, assembly testing, shakedown, system evaluation), The waterfall mode, ustrated in Fie- ture 1, was highly influential 1970 refine tent of the stagenise model. It provided to primary enhancements fo the stage ‘vise mode! (a) Recognition ofthe feedback loops between stags, anda guideline 0 ‘ontine the feedback loops 10 suc fessve stages 10 minimize the expensive rework involved infeed back across many stages [An initial incorporation of pro totyping in the software ie ele sina ‘ep running in parallel with requiements anal ysis and design ° ‘The waterfall model's approach helped eliminate many dificulties previously encountered on software projees. The ‘waterfall mode has become the bass for ‘most softvare aquisition standards in government and industry. Some ofits ini Ual difficulties have been addressed by adding extensions to cover incremental ‘evelopment, parallel developments, pr: am families, accommodation of evolu tionary changes, formal software development and verification, and stage ‘vise validation and risk analysis However, even with extensive revisions and refinements, the waterfall mode's basic scheme has encountered some more fundamental ditficules, and these have Jed tothe formulation of alternative pr cess models, ‘A primary source of dificulty with the ‘waterfall mage has been its emphasis on Tully elaborated documents as competion criteria for early requirements and design phases. For some clases of software, such as compilers or secure operating systems, "hiss the most effective way to proceed. However, it doesnot work well for many lasses of software, particularly interastive May 1988 ‘The waterfall model has become the basi for most software acquisition standards. end-user applications. Document-driven standards have pushed many projets to write elaborate specifications of poorly ‘understood use interfaces and decision- Support functions, followed by the design and development of large quantities oF ‘unusable code. “These projects are examples of how \waterfallmodel projects have come 10 avief by pursuing stages in the wrong ‘order, Furthermore, in teas supported by ‘ourth-generation languages spreadsheet ‘orsmall businessapplicatons), its clearly tunnecesary to write elaborate specifica: tions for one’s application before imple- menting it The evolutionary development model “Theabove concern edo the formulation ‘of the evoluionary development model, ‘whose stages consist of expanding incre ‘ments ofan operational sofware produit, with the directions of evolution being determined by operational experience. “Theevolutionary development models ideally matched to & fourth-gencration language aplication and well matched 19 siluations i which users say, “Lane tell youwhat! want, but know i when Esce it" lgives users rapid inital operational capability and provides a realistic opera tional bass-fr determining subsequent product improvements Nonetheless, evolutionary development also has its difficulties. ts generally dif ficult 10 distinguish it from the old code and-fix model, whose spaghetti code and lack of planning were te intil motiva: tion for the waterfall model, Ie is also ‘based onthe often-untealistic assumption ‘that the user's operational sytem wll Flexible enough to accommodate ‘unplanned evolution paths. This assump. ‘ions unjustified thre primary ieum: (1) Circumstances in which several independently evolved applications must subsequently be closely integrated. (2) “Information-sclerosis™ cases, in hich temporary work-arounds fr soft- ware deficiencies increasingly solidify into ‘unchangeable constraints on evolution ‘The following comments atypical exam e:"W'snice that you could change those ‘equipment codes to make them more ite ligible for us, but the Codes Committee just met and established the current codes as company standards.” (@) Bridging situations, in which the new software incrementally eeplacing & large exiting system. Ifthe existing ster {spoorly modularized, tis diticl 10 pro vide a good sequence of “bridges” ‘beeen the old software and the expand: ing increments of new software. ‘Under such conditions, evolutionary development projects have come to grief by pursuing stages im the wrong order: ‘evolving a lot of hard-to-change code before addressing long-range architectural and usage considerations. The transform model. The “spaghetti code” difficulties of the evolutionary ‘evelopment and codeand-fix models can also becomea dificult in various lasses of waterfall-mode aplication, in which code is optimized for performance and becomes increasingly hard to modify. The transform model has been proposed as 8 solution to this dilemma ‘Thetransform model assumes the exis tence ofacapabiity automatically eon vert a formal specification ofa software produetintoa program satisfying the spe IMication. The steps then prescribed by the transform model are + formal specification ofthe est in tial understanding of the desired product fautomatic transformation of the specification into code: an iterative loop, if necessary, t0 Improve the performance of the resulting code by giving optimization guidance t0 the transformation system: exercise ofthe resulting product and an outer iterative lop to adjust the Specification based nthe resulting ‘operational experience and toreder- Wwe, reoptimize, and exercise the Adjusted software produit. ‘Thetransform model thus bypasses the Aitticuly of having to modify code that hhas become poorly sietured through repeated reoptimizations, since the ‘modifications are made to the spcifica- tion, I also avoids the extra time and expense involved in the intermediate design, code, and vst activities, Sul, the transform model has various 6 4 Cumulative cost Progress through stops Evaluate alternative, isentily, resolve risks Determine objectives, alternatives, constraints Risk analysis isk analysis isk analysis Commitment Review partition Requirements plan le-cycle pian Sofware product design Develop- | Requirements mentpian} validation Integration ‘and test plan Design validation and vertication Implementatio| Plan next phases I Develop, verity noxt-avel product Figure 2. Spieal model ofthe software process. ditticues. Automatic transformation Additionally, it would face formidable capabilites are only availabe for small Knowledge-ase maintenance probe in TH Spiral model products ina few limited areas: spread- dealing with the rapidly increasing and sheets, small fourth-generation language evolving supply of resablesoftware com Thespiral modelo the softwar proces applications, and limited. computer- ponents and commercial software (se igure 2)has ben evolving fr several science domains. The transform model products. (Simpy consider he problem of years based on experience with various aso shares some ofthe difficulties of the tracking thecoss, performance, and fea- refinements of the waterfall model as evolutionary development mode, suchas tures of allommercal database manage. applied to large government software ‘he assumption that users operationalsys- ment systems, and automaticaly choosing. projets. As will be discussed, the spiral {ems illalwaysbe esibleenoughtosup- the best one to implement each new or model can accommodate most previous Port unplanned evolution paths. changed specification.) ‘models as special cases and futher pro: o COMPUTER des guidanceasto which combination of previous models best Fitsagivensoftvare Situation, Development ofthe TRW Soft ware Productivity Sytem (TRW-SPS), described in the next section, i is most complete application to date "The radial dimension in Figure 2 represents the cumulative cos ineutred in ‘scuomplishing the steps to date; heangu: Jar dimension represents the progress ‘madein completing each eyce ofthe spi ral, (The model reflects the underiying ‘oncep that each cle involves Sion that addresses the same seque! steps foreach portion of he product and foreach ofits levels of elaboration, from sn overall concept of operation document downto thecoding ofeach individual pr fram.) Not that some artistic lizense has ‘been taken with heincreasing cumulative cost dimension to enhance legibility ofthe Steps in Figure 2 Apical eel of the spiral Each cycle ofthe spiral bens withthe identification of + the objectives of the potion of the product being elaborated (perfor ‘mance, functionality, ability to accommodate change, et): ‘= thealternative means oF implement Jing this portion of the produc (design A, design B, reuse, buy, et. and + the constraints imposed onthe appli ‘ation of the ateratives (os, sched le, imerface, ee), ‘The nest step isto evaluate theater tives relative 10 the objectives and eon: strains, Frequently, this proces. will deny areas of uncertainty that are sig: nificant sources of project isk. If 0, the ‘nex ste should involve the Formulation of a costetfectve stratepy for resolsing ‘the soutees of rsh. Thismay involve pro toryping, simulation, benchmarking, reference checking, administering user ‘Questionnaires, analstic- modeling, of ombinations of these and other Fisk: Fesoluton techniques ‘Once the risks are evaluated, the next steps determined by the relative remain ing sks If performance or user-interface risks strongly dominate program develop: tment of internal interface-control risks, ‘he new stepmay bean evolutionary devel ‘opment one: minimal effort to specify the overall nature of the product, a plan forthe nex level of prototyping, and the development of amore detailed prototype {ocontinueto resolve themajorrskises i his prototype is operationally useful and robust enough to serve asa low-risk May 1988, base for future product evolution, the sub- sequent isk-drven steps would be the ‘evolving series of evolutionary prototypes going toward the ht in Figure 2 n sis ‘ase, the option of writing specifications would be addresed but not exercised. Thus, risk considerations ean lead to @ project implementing onlya subset ofall the potential steps in the model ‘Onithe other hand, if previous provotsp- ingefforishavealready resolved all ofthe performance or user-imerface risks, and Program development orinterface-

    You might also like