SDLC-Methodology
Spiral
Cost is represented in the model by the distance from center: the farther from the center the project is, the greater the cost because to get from the center to an outer ring the project must go through several stages over again. A key feature of this approach is the risk gate that is invoked between phases during which risk is assessed, mitigated, or otherwise dealt with, including curtailing or greatly modifying the project. At each stage, cost is incurred, and the costs continue to add up.
The advantage of this approach is that it focuses clearly on the objectives of the effort from several different viewpoints. These same viewpoints are employed in different contexts, and the context changes each time around the spiral. It encourages the reuse of code and exploration of alternatives. As we proceed from the center of the spiral toward the outer rim, we pass through a series of phases having a common title,
prototype. This lifecycle engages the concept of prototyping that starts simply with a conceptual view of operation and some risk analysis (that is, “1. Prototype”) and ends with an “Operational Prototype” that lies on the outermost rim and, although unnumbered, is actually stage 4 in this cyclic model. Compared with the slam dunk model discussed earlier, the spiral lifecycle model skips the internal cycles during which the team refines their model through design and analysis and jumps right into coding. This is one of the ways that this model is something of a composite of all software lifecycle models.
Notice that at each stage, the objectives to be achieved are stated. It is implicit that not achieving the stated objectives from a previous round can cause the project to be reevaluated or canceled. In this regard, the spiral lifecycle model bears some resemblance to the stage gate approach discussed later in this chapter. The spiral model is purported simply to represent what “really” happens in a software development project. It formalizes and documents the process. However, tracking status and communicating with stakeholders are made very complex in the spiral model, which might be why there are no significant testimonials as to the model’s effectiveness.
The advantage of this approach is that it focuses clearly on the objectives of the effort from several different viewpoints. These same viewpoints are employed in different contexts, and the context changes each time around the spiral. It encourages the reuse of code and exploration of alternatives. As we proceed from the center of the spiral toward the outer rim, we pass through a series of phases having a common title, prototype. This lifecycle engages the concept of prototyping that starts simply with a conceptual view of operation and some risk analysis (that is, “1. Prototype”) and ends with an “Operational Prototype” that lies on the outermost rim and, although unnumbered, is actually stage 4 in this cyclic model. Compared with the slam dunk model discussed earlier, the spiral lifecycle model skips the internal cycles during which the team refines their model through design and analysis and jumps right into coding. This is one of the ways that this model is something of a composite of all software lifecycle models.
Notice that at each stage, the objectives to be achieved are stated. It is implicit that not achieving the stated objectives from a previous round can cause the project to be reevaluated or canceled. In this regard, the spiral lifecycle model bears some resemblance to the stage gate approach discussed later in this chapter. The spiral model is purported simply to represent what “really” happens in a software development project. It formalizes and documents the process. However, tracking status and communicating with stakeholders are made very complex in the spiral model, which might be why there are no significant testimonials as to the model’s effectiveness.