Spiral model: Difference between revisions

Revision as of 00:57, 19 February 2007

Latest revision as of 16:21, 19 November 2024

(564 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Software development process model}}

{{Expand|date=January 2007}}

{{primary sources|date=February 2017}}

[[Image:Spiral model (Boehm, 1988).svg|thumb|333px|Spiral model (Boehm, 1988). A number of misconceptions stem from oversimplifications in this widely circulated diagram (there are some errors in this diagram).<ref name=":0">{{cite journal |last=Boehm |first=B |url=https://resources.sei.cmu.edu/asset_files/SpecialReport/2000_003_001_13655.pdf |title=Spiral Development: Experience, Principles, and Refinements |journal=Special Report |id=CMU/SEI-2000-SR-008 |publisher=Software Engineering Institute |date=July 2000}}</ref>]]{{Software development process}}

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 [[Iterative and incremental development|incremental]], [[Waterfall model|waterfall]], or [[Software_prototyping#Evolutionary_prototyping|evolutionary prototyping]].

== History ==

{{Software-development-process}}

This model was first described by [[Barry Boehm]] in his 1986 paper, "A Spiral Model of Software Development and Enhancement."<ref>{{cite journal |last=Boehm |first=B |doi=10.1145/12944.12948 |title=A Spiral Model of Software Development and Enhancement |journal=ACM SIGSOFT Software Engineering Notes |volume=11 |issue=4 |pages=14–24 |date=August 1986|s2cid=207165409 }}</ref> In 1988 Boehm published a similar paper<ref name=":1">{{cite journal |last=Boehm |first=B |url=http://www-scf.usc.edu/~csci201/lectures/Lecture11/boehm1988.pdf |title=A Spiral Model of Software Development and Enhancement |journal=IEEE Computer |volume=21 |issue=5 |pages=61–72 |date=May 1988 |doi=10.1109/2.59|s2cid=1781829 }} {{webarchive |url=https://web.archive.org/web/20230306211634/http://www-scf.usc.edu/~csci201/lectures/Lecture11/boehm1988.pdf |date=March 6, 2023 }}</ref> 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:

The '''spiral model''' is a [[software development process]] combining elements of both [[design]] and [[prototyping]]-in-stages, in an effort to combine advantages of [[top-down]] and [[bottom-up]] concepts.

{{quotation|[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.<ref name=":1"/>}}

In later publications,<ref name=":0"/> 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:

* that the spiral is simply a sequence of waterfall increments;

* that all project activities follow a single spiral sequence;

* 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<ref>{{cite book |editor-last=Pew |editor-first=R.W. |editor2-last=Mavor |editor2-first=A.S. |date=2007 |url=http://books.nap.edu/catalog.php?record_id=11893 |title=Human-system integration in the system development process: A new look |___location=Washington, D.C. |publisher=National Academy Press |doi=10.17226/11893 |isbn=978-0-309-10720-4}}</ref> 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.{{fact|date=August 2014}}

== History ==

== The six invariants of spiral model==

The spiral model was defined by [[Barry Boehm]] in his 1988 article ''A Spiral Model of Software Development and Enhancement''. This model was not the first model to discuss [[iterative development]], but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design [[Objective (goal)|goal]] and ends with the [[consumer|client]] (who may be internal) reviewing the progress thus far. Analysis and [[engineering]] efforts are applied at each phase of the project, with an eye toward the end goal of the project.

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.<ref name=":0" />

===Define artifacts concurrently===

==The Spiral Model==

Sequentially defining the key artifacts for a project often increases the possibility of developing a system that meets stakeholder "win conditions" (objectives and constraints).

DEFINITION - The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.

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:

{| class="wikitable"

# The requirements are known in advance of implementation.

|-

# The requirements have no unresolved, high-risk implications, such as risks due to cost, schedule, performance, safety, user interfaces, organizational impacts, etc.

! header 1

# The nature of the requirements will not change very much during development or evolution.

! header 2

# The requirements are compatible with all the key system stakeholders’ expectations, including users, customer, developers, maintainers, and investors.

! header 3

# The right architecture for implementing the requirements is well understood.

|-

# There is enough calendar time to proceed sequentially.

| row 1, cell 1

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.

| row 1, cell 2

#

| row 1, cell 3

|-

| row 2, cell 1

| row 2, cell 2

| row 2, cell 3

|}

The steps in the spiral model can be generalized as follows:

===Perform four basic activities in every cycle===

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

This invariant identifies the four activities that must occur in each cycle of the spiral model:

2. A preliminary design is created for the new system.

# Consider the win conditions of all success-critical stakeholders.

3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

# Identify and evaluate alternative approaches for satisfying the win conditions.

4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.

# Identify and resolve risks that stem from the selected approach(es).

5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.

# Obtain approval from all success-critical stakeholders, plus commitment to pursue the next cycle.

6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.

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.

7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

8. The final system is constructed, based on the refined prototype.

9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

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.

===Risk determines level of effort===

==Applications==

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 a typical [[shrink-wrap]] application, the spiral model might mean that you have a rough-cut of user elements (without the polished / pretty [[graphics]]) as an operable application, add features in phases, and, at some point, add the final graphics.

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. {{Citation needed|date=March 2017}}

The spiral model is used most often in large projects. For smaller projects, the concept of [[agile software development]] is becoming a viable alternative. The [[US military]] has adopted the spiral model for its [[Future Combat Systems]] program.

"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.

==Advantages==

*Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because important issues are discovered earlier.

*It is more able to cope with the (nearly inevitable) changes that software development generally entails.

*Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

===Risk determines degree of details===

==See also==

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.

*[[Barry Boehm]]

*[[Software engineering]]

*[[List of software engineering topics]]

*[[Waterfall model]]

*[[Chaos model]]

*[[MBASE]]

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).

==External links==

*[http://www.sce.carleton.ca/faculty/ajila/4106-5006/Spiral%20Model%20Boehm.pdf A Spiral Model of Software Development and Enhancement] - Barry Boehm's original article

*[http://www.elanman.org/teaching/gmu/swe620-infs622/Graphics/spiral_model.gif A graphical representation]

===Use anchor point milestones===

__NOTOC__

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.

# Life Cycle Objectives. Is there a sufficient definition of a technical and management approach to satisfying everyone's 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 everyone's 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 everyone's 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 look-alikes" that violate this invariant include evolutionary and incremental processes that commit significant resources to implementing a solution with a poorly defined architecture.{{huh|date=August 2014}} <!-- What is meant by "architecture"? -->

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.

[[de:Spiralmodell]]

[[es:Espiral de Boehm]]

===Focus on the system and its life cycle===

[[it:Modello a spirale]]

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 the 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.

[[ja:スパイラルモデル]]

[[nl:Spiraal model]]

== References ==

[[pt:Modelo em espiral]]

{{reflist}}

{{Software engineering}}

[[Category:Software development process]]

[[Category:Spirals|model]]