Software runaways; waterfall and prototyping inside spiral

Reasons for software runaways

A software runaway is a project that has gone out of control: it is far over its budget and schedule, its end is not in sight, and it often fails to deliver the planned functionality. Common reasons are:

1. Unclear or unstable requirements: requirements are incomplete at the start and keep changing (scope creep).
2. Poor estimation: unrealistic, often politically fixed, cost and schedule targets.
3. Weak planning and project management: no milestones, poor tracking, problems noticed too late.
4. Unmanaged risk: technical and business risks are not identified or reduced early.
5. New or unproven technology that the team does not understand well.
6. Poor user involvement and communication between customers and developers.
7. Staffing problems: lack of skills, high turnover, adding people late (Brooks's law).

Accommodating waterfall and prototyping in the spiral model

Boehm's spiral model is a risk-driven meta-model. The process is a spiral; each loop is one phase and has four sectors:

          Determine           |   Evaluate alternatives,
     objectives, alternatives |   identify and resolve
          and constraints     |   risks (prototypes)
   ---------------------------+----------------------------
          Plan the next       |   Develop and verify
          phase (review)      |   the next-level product

Because the model does not fix how the product is built in the "develop and verify" sector, the team chooses, in each loop, the development approach that best reduces the dominant risk. This is how other models fit inside it.

Prototyping inside the spiral

• In the early loops the main risks are usually unclear requirements and an uncertain user interface or technical approach.
• So in the risk-analysis sector the team builds prototypes (Boehm's spiral shows Prototype 1, 2, 3 and an operational prototype in successive loops).
• Users evaluate each prototype, and the feedback is used to set the objectives of the next loop.
• Thus prototyping is used as a risk-reduction technique inside the spiral; it can be throwaway (only to learn requirements) or evolutionary (grown into the system).

Waterfall inside the spiral

• Once prototyping has removed the requirement and interface risks, the remaining risk is mainly in program development and integration.
• The final loop(s) then follow the waterfall sequence: requirements validation, detailed design, code, unit test, integration and test, acceptance test, implementation.
• Each step is completed and verified before the next, exactly as in the waterfall model.
• If requirements are well understood from the start (low requirement risk), the spiral can even reduce almost entirely to a waterfall.

 Loop 1: concept of operation  -> Prototype 1
 Loop 2: requirements          -> Prototype 2
 Loop 3: design                -> Operational prototype
 Loop 4: detailed design -> code -> test -> deploy
         (waterfall steps, risk now low)

Choice by risk

So the spiral model contains the waterfall and prototyping models as special cases: prototyping is used where uncertainty is high, and waterfall where the product is well understood. The decision is made explicitly at each loop on the basis of risk analysis.