Spiral Model

The spiral model is based on the need to iterate. It contains as many iterations as are necessary to bring a product to fruition. Each iteration requires that the participants plan, define their life-cycle, prototype, analyze risks, write requirements, build models, detailed designs, code, unit, and system tests, and install.
Fig - Spiral Model

The spiral model has a number of advantages:
• It is flexible and allows for multiple iterations.
• It employs prototyping extensively.
• It allows for the coexistence of other models (indeed it expects candidate models to be proposed and adopted if useful).
• It makes risk evaluation explicit.
• It acknowledges the need to validate requirements and design.
• It was originally designed with a particular need to accommodate COTS, and is therefore more amenable to software reuse.

Its dangers are:
• It is less easy to allocate phases to groups and responsibilities than other models.
• It requires that staff are well-versed in software engineering.
• It requires much team self-discipline in the capture of emerging requirements.
• It does not acknowledge the need to have test input from the start of the project.
• It allocates particular phases to requirements definition and high- and low-level design.
• It doesn’t make the baselines explicit.
• It doesn’t allow for process decomposition.
• Much prototype code may eventually be used in the final version.
• It must be very tool-supported to work or it will either decay or become enmeshed in  the bureaucracy it was intended to minimize.
 
The implications of this for the system testing team are that:
• The status of emerging requirements must be constantly reviewed.
• The team is committed to validating both the requirements and the design.
• Any use of prototype code in the production version will require much more rigorous unit testing than is normal.