Spiral Software Development

What is Spiral Model?

The spiral model is a systems development life cycle (SDLC) model used in software development. The SDLC model can be found in other software development models such as the Waterfall model, the RAD, the Iterative and the Incremental model etc.

The SDLC is the framework, used since the 1970s, to describe the progress of a software development project from the planning stage to deployment. The SDLC stages are:-

1. Business requirement data gathering and analysis
2. System and software design
3. Implementation and coding
4. Testing
5. Delivery
6. Maintenance

The spiral model

The spiral model uses a similar profile to that of the SDLC. It is an incremental risk-oriented model that has four phases.

The four phases of the spiral model are:

a) Planning undertaken and requirements identified
b) Risk analysis and alternative solutions identified
c) Design of first software prototype, and software tested
d) Evaluation of output and next iteration planed

 

This sequence of phases is then repeated in an iterative way, each iteration being one turn of the spiral, developing the next prototype as it goes, and each spiral building on the previous spiral, narrowing down to a final release.

By repeating the process the software is continually refined, tested and evaluated. As the process proceeds more is learned about the software, more is learned about the risks, and more is learned about the final product until the point is reached where it is ready for final release.

The spiral model relies heavily on the incremental model so that the product is built up piece by piece, and a little more added each time, until the product satisfies all the requirements demanded of it. In the spiral model heavy emphasis is placed on risk analysis. The risk analysis also includes analysing the technical feasibility of the product at this point, and considering any implications that have a bearing on the time and cost factors.

The phases in more detail

a) The Planning Phase: is the beginning of the process and the business requirements are identified together with the system requirements. After the initial planning all subsequent spiral planning utilises the feedback from the customer as well as lessons learned from the first spiral.
b) In the Risk Analysis Phase: all risks are evaluated, even the seemingly trivial ones. Anything which has a bearing on the project is taken into account and prioritised accordingly. These risks are then addressed and strategies to combat them are identified and implemented.

c) In the Design and Testing phase: a prototype is first constructed and customer feedback sought in order to ensure that the concept is correct. In subsequent spirals working builds are sent to the customer in order to refine the build.
d) In the Evaluation Phase: the whole of the previous spiral’s output is evaluated before starting the next spiral.

Barry Boehm

The spiral model was first devised by Barry Boehm (born 1935). He is a distinguished American software engineer and professor of Software Engineering at the University of Southern California. In 1986 he published a paper called ‘A Spiral Model of Software Development and Enhancement’ in which he set out the case for the spiral model being a refinement of the waterfall model.

In another paper, published in 2000 ‘Spiral Development; Experience, Principles, and Refinements’, he describes the spiral model as a ‘process model generator’ meaning that the risks which are identified should generate the choices of processes to be adopted; such as the waterfall model, incremental model etc. Therefore the spiral model is, in effect, a meta-model because it uses other models as part of its development process.

However the spiral model shouldn’t be seen as just a sequence of waterfall increments and iterations. Boehm himself warns of this oversimplification, and also warns against the dangers in over simplifying the spiral model diagram. It may appear that the model follows a single spiral sequence, but, in reality, it is more complex than this, often adopting an agile approach and resulting in the process being more flexible. For example the riskier parts of the project can be tackled earlier than a strict sequence would demand, if this makes the later parts of the development easier to manage.

Advantages and disadvantages of the spiral model

Spiral model advantages

• The continual risk analysis reduces the chance of the project failing
• The continual risk analysis makes it attractive for large and expensive projects
• The software continues to be adapted right up into the late phases of the project, because of the iterative process, so that further functionality can be added towards the end of the project
• Software is produced early in the development and continues to be produced through each iteration so that there is always a product available to show for the work done
• Close communication with the customer. The customer can see the development in progress and can comment on and feed into the requirements of the prototype at each iteration
• The spiral method is very flexible
• The spiral method is transparent because each spiral iteration is reviewed and evaluated
• Close control and full documentation

Spiral model disadvantages

• The process is more complex than some other models such as the waterfall model
• The risk analysis phase is crucial to the success of the model. If the risk analysis is not correct a whole iteration may be compromised resulting in costly time-wasting
• The risk analysis can be expensive because of the resources which may need to be applied to it
• A lot of documentation
• Difficult to be able to ascribe an end date to the project because the number of spirals, through which the software may have to go, are not known from the outset. This may also make it expensive

When to use the spiral model

• When cost is not one of the foremost concerns
• For medium or high risk scenarios
• When risk analysis can be confidently dealt with
• When the customer is not sure of what they want in the finished product
• When the customer has complex needs
• When changes to the software can be expected during its development
• When the customer can commit to long term involvement