spiral model spiral model boehm 2000 a number of misconceptions stem from oversimplifications in this widely circulated diagram there are some errors in this diagramsoftware development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte the spiral model is a riskdriven software development process model based on the unique risk patterns of a given project the spiral model guides a team to adopt elements of one or more process models such as incremental waterfall or evolutionary prototyping history this model was first described by barry boehm in his 1986 paper a spiral model of software development and enhancement to a wider audience these papers introduce a diagram that has been reproduced in many subsequent publications discussing the spiral model these early papers use the term process model to refer to the spiral model as well as to incremental waterfall prototyping and other approaches however the spiral models characteristic riskdriven blending of other process models features is already present in later publications boehm describes the spiral model as a process model generator where choices based on a projects risks generate an appropriate process model for the project thus the incremental waterfall prototyping and other process models are special cases of the spiral model that fit the risk patterns of certain projects boehm also identifies a number of misconceptions arising from oversimplifications in the original spiral model diagram he says the most dangerous of these misconceptions are that the spiral is simply a sequence of waterfall increments that all project activities follow a single spiral sequence and that every activity in the diagram must be performed and in the order shown while these misconceptions may fit the risk patterns of a few projects they are not true for most projects in a national research council report this model was extended to include risks related to human users to better distinguish them from hazardous spiral lookalikes boehm lists six characteristics common to all authentic applications of the spiral model the six invariants authentic applications of the spiral model are driven by cycles that always display six characteristics boehm illustrates each with an example of a hazardous spiral lookalike that violates the invariant define artifacts concurrently sequentially defining the key artifacts for a project often lowers the possibility of developing a system that meets stakeholder win conditions objectives and constraints this invariant excludes hazardous spiral lookalike processes that use a sequence of incremental waterfall passes in settings where the underlying assumptions of the waterfall model do not apply boehm lists these assumptions as follows the requirements are known in advance of implementation the requirements have no unresolved highrisk implications such as risks due to cost schedule performance safety security user interfaces organizational impacts etc the nature of the requirements will not change very much during development or evolution the requirements are compatible with all the key system stakeholders expectations including users customer developers maintainers and investors the right architecture for implementing the requirements is well understood there is enough calendar time to proceed sequentially in situations where these assumptions do apply it is a project risk not to specify the requirements and proceed sequentially the waterfall model thus becomes a riskdriven special case of the spiral model perform four basic activities in every cycle this invariant identifies the four activities that must occur in each cycle of the spiral model consider the win conditions of all successcritical stakeholders identify and evaluate alternative approaches for satisfying the win conditions identify and resolve risks that stem from the selected approaches obtain approval from all successcritical stakeholders plus commitment to pursue the next cycle project cycles that omit or shortchange any of these activities risk wasting effort by pursuing options that are unacceptable to key stakeholders or are too risky some hazardous spiral lookalike processes violate this invariant by excluding key stakeholders from certain sequential phases or cycles for example system maintainers and administrators might not be invited to participate in definition and development of the system as a result the system is at risk of failing to satisfy their win conditions risk determines level of effort for any project activity eg requirements analysis design prototyping testing the project team must decide how much effort is enough in authentic spiral process cycles these decisions are made by minimizing overall risk for example investing additional time testing a software product often reduces the risk due to the marketplace rejecting a shoddy product however additional testing time might increase the risk due to a competitors early market entry from a spiral model perspective testing should be performed until the total risk is minimized and no further hazardous spiral lookalikes that violate this invariant include evolutionary processes that ignore risk due to scalability issues and incremental processes that invest heavily in a technical architecture that must be redesigned or replaced to accommodate future increments of the product risk determines degree of details for any project artifact eg requirements specification design document test plan the project team must decide how much detail is enough in authentic spiral process cycles these decisions are made by minimizing overall risk considering requirements specification as an example the project should precisely specify those features where risk is reduced through precise specification eg interfaces between hardware and software interfaces between prime and sub contractors conversely the project should not precisely specify those features where precise specification increases risk eg graphical screen layouts behavior of offtheshelf components use anchor point milestones boehms original description of the spiral model did not include any process milestones in later refinements he introduces three anchor point milestones that serve as progress indicators and points of commitment these anchor point milestones can be characterized by key questions life cycle objectives is there a sufficient definition of a technical and management approach to satisfying everyones win conditions if the stakeholders agree that the answer is yes then the project has cleared this lco milestone otherwise the project can be abandoned or the stakeholders can commit to another cycle to try to get to yes life cycle architecture is there a sufficient definition of the preferred approach to satisfying everyones win conditions and are all significant risks eliminated or mitigated if the stakeholders agree that the answer is yes then the project has cleared this lca milestone otherwise the project can be abandoned or the stakeholders can commit to another cycle to try to get to yes initial operational capability is there sufficient preparation of the software site users operators and maintainers to satisfy everyones win conditions by launching the system if the stakeholders agree that the answer is yes then the project has cleared the ioc milestone and is launched otherwise the project can be abandoned or the stakeholders can commit to another cycle to try to get to yes hazardous spiral lookalikes that violate this invariant include evolutionary and incremental processes that commit significant resources to implementing a solution with a poorly defined architecture the three anchor point milestones fit easily into the rational unified process rup with lco marking the boundary between rups inception and elaboration phases lca marking the boundary between elaboration and construction phases and ioc marking the boundary between construction and transition phases focus on the system and its life cycle this invariant highlights the importance of the overall system and the longterm concerns spanning its entire life cycle it excludes hazardous spiral lookalikes that focus too much on initial development of software code these processes can result from following published approaches to objectoriented or structured software analysis and design while neglecting other aspects of the projects process needs vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons 