Waterfall versus spiral; user participation

Waterfall model

The waterfall model (Royce, 1970) is a linear sequential model. Development passes through separate phases, and each phase must be completed and signed off before the next starts.

 Requirements definition
        |
        v
 System and software design
        |
        v
 Implementation and unit testing
        |
        v
 Integration and system testing
        |
        v
 Operation and maintenance

Spiral model

The spiral model (Boehm, 1988) is an iterative, risk-driven model. Each loop of the spiral is a phase with four sectors: objective setting, risk assessment and reduction, development and validation, and planning the next loop. Prototypes are built to reduce risks, and the product grows with each loop.

   Objectives, alternatives | Risk analysis,
   and constraints          | prototyping
   -------------------------+--------------------
   Review and plan          | Develop and test
   next loop                | next-level product
   (repeat, spiral outward with growing cost)

Comparison

In short, waterfall is simple and well controlled but rigid; spiral is flexible and safer for risky projects but costly and harder to manage. Spiral can even include waterfall as the last loop once the risks are removed.

Role of user participation in selecting a life cycle model

Users (customers) are the source of requirements and the judges of the final product. How much, and when, they can take part strongly affects which model is suitable:

1. Clarity of user requirements: if users can state complete, stable requirements at the start, a waterfall or V-model works. If users are not sure what they want, a prototyping or spiral model is better, because they learn by seeing.
2. Availability of users: models such as prototyping, evolutionary development, RAD and agile need users to be continuously available to review and give feedback. If users can only participate at the beginning (requirements) and end (acceptance), waterfall is more realistic.
3. User experience with computers and the domain: inexperienced users benefit from prototypes and incremental releases; experienced users can review written specifications.
4. Need for early delivery: if users want some functions quickly, incremental delivery is chosen, and users help prioritise increments.
5. User risk tolerance and contract type: users who need a fixed price and fixed date prefer waterfall; those who accept evolving scope can use spiral or agile.
6. Feedback and acceptance: high participation reduces the risk of building the wrong system and increases user acceptance and ownership.

Thus user participation is a key factor: the more uncertain the requirements, the more user participation is needed, and the more iterative the chosen life cycle model should be.