Spiral model

From Dr. Joey Paquet Web Site
Jump to: navigation, search

The spiral model was defined by Barry Boehm in his article A Spiral Model of Software Development and Enhancement from 1986. This model was not the first model to discuss iteration, 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. The spiral model (Boehm, 1988) aims at risk reduction by any means in any phase. The spiral model is often referred to as a risk-driven model.

Spiral model.gif

Introducing prototyping in a Software Process aims at risk reduction at the requirements level. There is always an element of risk involved in the other phases of development. A spiral phase begins in the top left quadrant (quadrant 1), by determining objectives of that phase, alternatives and constraints. This is a way to define a strategy for achieving the goals of this iteration. Next (quadrant 2), the strategy is analyzed form the viewpoint of risk, and solutions to minimize these risks are investigated, often using prototyping. Then (quadrant 3), in light of the investigations made in quadrant 2, a solution is put into practice to produce the artifacts necessary to reach the goals identified in quadrant 1. This quadrant (3) corresponds to where the traditional waterfall model phases are put into practice. Finally (quadrant4), the results of the risk-reduction strategies are assessed, and if all risks are resolved, the next phase is planned and started. If some risks are left unsolved, another iteration can be made to continue to work on the uneliminated risks. If certain risks can not be resolved, the project might be terminated immediately (under some circumstances project might be continued but in a smaller scale).

Advantages 
  • Emphasis on alternatives and constraints supports the reuse of existing solutions.
  • Targets testing by treating it as a risk, which has to be addressed.
  • Maintenance is just another phase of the spiral model. It is treated in the same way as development.
  • Estimates (budget and schedule) 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.
Disadvantages 
  • Only intended for internal projects (inside a company), because risk is assessed as the project is developed. Hardly suitable for contractual software development.
  • In case of contractual software development, all risk analysis must be performed by both client and developers before the contract is signed and not as in the spiral model.
  • Spiral model is risk driven. Therefore it requires knowledgeable staff.
  • Suitable for only large scale software development. Does not make sense if the cost of risk analysis is a major part of the overall project cost.

References