What is the spiral method of project management methodologies?

Question

What exactly is a spiral module in terms of projects management methods?

What does it entail? Is it a loosely formed term akin to agile as well (as there are various variants)?

Finally, In which criterion would it be ideal for it's application?

Answer 1

The spiral model was developed by Barry Boehm in the late 80's in order to introduce risk management and iterations for waterfall based projects. It tried to solve the problems they found with the waterfall approach.

The whole concept of iterations was missing from the early versions of waterfall, although it was clearly stated on the second page of the white paper that it wouldn't be successful without doing the steps iteratively. So Boehm tried to come up with a model where the iterations are explicitly in the model.

The other thing which was missing is the risk management. Even in a short iteration, it was important to know about the risks, therefore the spiral model suggested to have a prototyping phase, where prototypes had to be made and a risk analysis based on the prototypes.

The model in a nutshell:

1. determine objectives - figure out the requirements for the iteration
2. identify and resolve risks - prototypes and risk analysis
3. the classical waterfall steps - design, code, integration, test, release
4. plan the next iteration
5. goto step 1.

I'm not saying that the model is bad - the risk management is actually a good idea which is unfortunately missing from the new age models -, but it is obsolete. I think a good XP or Scrum based approach with a short risk management session can be a better choice.

Answer 2

The spiral method is one of the proposed solutions to the problems with the waterfall method. It arranges the steps of the waterfall method in a circle. During the first pass a small amount of the project is developed. As the project progresses each of the steps is revisited. Representing percentage complete as distance from the center of the circle results in a spiral graph.

Another term which may be applied in this case is progressive approximation. Agile practitioners tend to distance themselves from the waterfall methodology and may not approve of the the spiral method.

The spiral method is good for projects which require formal specification, but for which the specifications can not be fully defined in advance of development.

EDIT: What is traditionally understood as a the waterfall methodology was a straw-man methodology presented in a paper which built significantly on that waterfall. The traditional waterfall is only really applicable in cases where there is very little uncertainty in any of the steps and no need to feedback to any prior steps. (Few software projects meet this criteria.) The first improvement was to provide feedback to the previous step. This was then enhanced to allow feedback to any prior step. Finally a prototyping step (iterative approximation) was inserted which was intended to flesh out and develop those components with the most uncertainty (as much as a third of the project).

Compared to the fleshed out waterfall a simple spiral methodology would be a step back. I believe the agile methodology well follows the fleshed out methodology but ends at the prototyping stage. As the prototyping stage includes all the steps of the methodology, this is not so bad. If components are properly picked, value is gained immediately. Stopping a spiral or agile project early may help reduce creeping feature-itis.