---
title: "Software runaways; waterfall and prototyping inside spiral"
subject: "Software Engineering"
chapter: 1
key: "semester_5/software_engineering:software-runaways-spiral"
source: https://www.bctengineer.com/q/semester_5/software_engineering/software-runaways-spiral
site: BCT Engineering
---

# Software runaways; waterfall and prototyping inside spiral

Software Engineering · Chapter 1: Software Process and requirements

- Asked in: year not given, 2+6 marks
- Video: [SE 9 : Spiral Model | Complete Explanation with Example | Software Engineering Full Course](https://www.youtube.com/watch?v=TLy72EoL-qA) — CS & IT Tutorials by Vrushali 👩‍🎓
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/software-runaways-spiral
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1

## Question

What are the reasons for software runaways? Explain how both waterfall model and prototyping model can be accommodated in spiral model.

## Short answer

Software runaways stem from unclear requirements, poor estimation, weak management, unmanaged risks, and new technology. In the spiral model, prototyping is used in early loops to clarify requirements and reduce risk, while the waterfall sequence is applied in later loops once risks are low, with each phase completed sequentially.

## Answer

#### 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:

```text
          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.

```text
 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**
| Dominant risk in a loop | Approach used in that loop |
|---|---|
| Requirements / user interface unclear | Prototyping |
| Requirements stable, integration risk | Waterfall |
| Safety-critical parts | Formal transformation |
| Large, partly known system | Incremental delivery |

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.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. What is a software runaway?
   A. A project that has gone out of control, far over budget and schedule with no end in sight
   B. A program that deletes itself on execution
   C. A project finished early and under budget
   D. A virus that spreads between programs
   Answer: A. A runaway is a project out of control: far over budget and schedule, often failing to deliver planned functionality. (Key point: Software runaway)

2. Which is a common reason for software runaways?
   A. Stable and complete requirements
   B. Unclear or changing requirements (scope creep) and poor estimation
   C. Strong early risk management
   D. Close user involvement
   Answer: B. Unstable requirements, poor estimation, weak management and unmanaged risk are typical causes. (Key point: Reasons for runaways)

3. Why can the spiral model accommodate other models like waterfall and prototyping?
   A. It forbids any fixed approach
   B. It only works for small projects
   C. It does not fix how the product is built in the develop-and-verify sector, so each loop chooses the approach that best reduces the dominant risk
   D. It replaces risk analysis with documents
   Answer: C. The spiral is a risk-driven meta-model; each loop selects the development approach best suited to the main risk. (Key point: Spiral as a meta-model)

4. How is prototyping used inside the spiral model?
   A. Only after final delivery
   B. As a documentation technique
   C. Instead of any risk analysis
   D. As a risk-reduction technique in early loops, where users evaluate prototypes and feedback sets the next loop's objectives
   Answer: D. Early loops face requirement and interface risks, so prototypes are built and evaluated to reduce them. (Key point: Prototyping inside spiral)

## Related in Software Engineering

- [Waterfall versus spiral; user participation](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Awaterfall-vs-spiral) — Software Engineering, chapter 1
- [Spiral model, advantages and disadvantages](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aspiral-model) — Software Engineering, chapter 1
- [Waterfall model: advantages and limitations](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Awaterfall-limitations) — Software Engineering, chapter 1
- [Current process models; why waterfall is not accurate](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Awaterfall-not-accurate) — Software Engineering, chapter 1
- [Alternative models to waterfall](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aalternative-to-waterfall) — Software Engineering, chapter 1

## Related in other subjects

- [Spiral model of software development](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Aspiral-model) — Instrumentation II, chapter 9, asked 3×
- [Software reliability; waterfall vs prototyping; embedded software](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-reliability-models-embedded) — Instrumentation II, chapter 9
- [Prototyping model of software](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Aprototype-model) — Instrumentation II, chapter 9, asked 3×
- [Spiral model of embedded software life cycle](https://www.bctengineer.com/question.md?key=semester_6%2Fembedded_system%3Aspiral-model-esdlc) — Embedded System, chapter 3