Spiral model: Difference between revisions
| Line 9: | Line 9: | ||
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. |
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. |
||
okol |
|||
== The model == |
== The model == |
||
Revision as of 13:03, 9 July 2011
.svg)
| Part of a series on |
| Software development |
|---|
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. Also known as the spiral lifecycle model (or spiral development), it 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 intended for large, expensive and complicated projects.
This should not be confused with the Helical model of modern systems architecture that uses a dynamic programming (mathematical not software type programming!) approach in order to optimise the system's architecture before design decisions are made by coders that would cause problems.
History
The spiral model was defined by Barry Boehm in his 1986 article "A Spiral Model of Software Development and Enhancement".[1] This model was not the first model to discuss iterative development.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the 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.
okol
The model
The spiral model combines the idea of iterative development (prototyping) with the systematic, controlled aspects of the waterfall model. It allows for incremental releases of the product, or incremental refinement through each time around the spiral. The spiral model also explicitly includes risk management within software development. Identifying major risks, both technical and managerial, and determining how to lessen the risk helps keep the software development process under control [2].
The spiral model is based on continuous refinement of key products for requirements definition and analysis, system and software design, and implementation (the code). At each iteration around the cycle, the products are extensions of an earlier product. This model uses many of the same phases as the waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations [2].
Documents are produced when they are required, and the content reflects the information necessary at that point in the process. All documents will not be created at the beginning of the process, nor all at the end (hopefully). Like the product they define, the documents are works in progress. The idea is to have a continuous stream of products produced and available for user review [2].
The spiral lifecycle model allows for elements of the product to be added in when they become available or known. This assures that there is no conflict with previous requirements and design. This method is consistent with approaches that have multiple software builds and releases and allows for making an orderly transition to a maintenance activity. Another positive aspect is that the spiral model forces early user involvement in the system development effort. For projects with heavy user interfacing, such as user application programs or instrument interface applications, such involvement is helpful [2].
Starting at the center, each turn around the spiral goes through several task regions [2]:
- Determine the objectives, alternatives, and constraints on the new iteration.
- Evaluate alternatives and identify and resolve risk issues.
- Develop and verify the product for this iteration.
- Plan the next iteration.
Note that the requirements activity takes place in multiple sections and in multiple iterations, just as planning and risk analysis occur in multiple places. Final design, implementation, integration, and test occur in iteration 4. The spiral can be repeated multiple times for multiple builds. Using this method of development, some functionality can be delivered to the user faster than the waterfall method. The spiral method also helps manage risk and uncertainty by allowing multiple decision points and by explicitly admitting that all of anything cannot be known before the subsequent activity starts [2].
Applications
The spiral model is mostly used in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military had adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003–2009), it had a two year iteration (spiral). The FCS should have resulted in three consecutive prototypes (one prototype per spiral—every two years). It was canceled in May 2009. The spiral model thus may suit small (up to $3 million) software applications and not a complicated ($3 billion) distributed, interoperable, system of systems.
Also it is reasonable to use the spiral model in projects where business goals are unstable but the architecture must be realized well enough to provide high loading and stress ability. For example, the Spiral Architecture Driven Development is the spiral based Software Development Life Cycle (SDLC) which shows one possible way how to reduce the risk of non-effective architecture with the help of a spiral model in conjunction with the best practices from other models.
References
