This article relies too much on references to primary sources. (February 2017)
The spiral model is a risk-driven 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.
This model was first described by Barry Boehm in his 1986 paper, "A Spiral Model of Software Development and Enhancement". In 1989 Boehm published a similar paper 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 model's characteristic risk-driven blending of other process models' features is already present:
[R]isk-driven subsetting of the spiral model steps allows the model to accommodate any appropriate mixture of a specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or other approach to software development.
In later publications, Boehm describes the spiral model as a "process model generator", where choices based on a project's 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:
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 look-alikes", Boehm lists six characteristics common to all authentic applications of the spiral model.
Authentic applications of the spiral model are driven by cycles that always display six characteristics. Boehm illustrates each with an example of a "dangerous spiral look-alike" that violates the invariant.
Sequentially defining the key artifacts for a project often increases the possibility of developing a system that meets stakeholder "win conditions" (objectives and constraints).
This invariant excludes “hazardous spiral look-alike” 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:
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 risk-driven special case of the spiral model.
This invariant identifies the four activities that must occur in each cycle of the spiral model:
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 look-alike" 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.
For any project activity (e.g., 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 competitor's early market entry. From a spiral model perspective, testing should be performed until the total risk is minimized, and no further.
"Hazardous spiral look-alikes" 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.
For any project artifact (e.g., 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 (e.g., interfaces between hardware and software, interfaces between prime and sub-contractors). Conversely, the project should not precisely specify those features where precise specification increases the risk (e.g., graphical screen layouts, the behavior of off-the-shelf components).
Boehm's 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.
"Hazardous spiral look-alikes" that violate this invariant include evolutionary and incremental processes that commit significant resources to implementing a solution with a poorly defined architecture.[clarification needed]
The three anchor point milestones fit easily into the Rational Unified Process (RUP), with LCO marking the boundary between RUP's Inception and Elaboration phases, LCA marking the boundary between Elaboration and Construction phases, and IOC marking the boundary between Construction and Transition phases.
This invariant highlights the importance of the overall system and the long-term concerns spanning its entire life cycle. It excludes "hazardous spiral look-alikes" that focus too much on initial development of software code. These processes can result from following published approaches to object-oriented or structured software analysis and design, while neglecting other aspects of the project's process needs.
Edited: 2021-06-18 19:13:57