What is a Software Process? Waterfall and Spiral

What Is a Software Process?

A software process is a structured set of activities required to develop a software system. Every process, however formal or informal, includes four fundamental activities:

1. Specification — define what the system should do.
2. Design and Implementation — organise the system and build it.
3. Validation — verify that the system does what the customer wants.
4. Evolution — change the system in response to changing needs.

“Code-and-fix” — the absence of process — works fine for one person and 500 lines. It is catastrophic at scale: developers overwrite each other’s work, duplicate effort, test inconsistently, miss deadlines, and produce unmaintainable systems. A process formalises who does what, when, and how the work is verified.

The Waterfall Model

Origin: Winston Royce (1970), borrowing heavily from civil and manufacturing engineering. You do not build the roof before the foundation is inspected.

The five sequential phases:

1. Requirements Definition — write an exhaustive specification document. Every feature, every constraint, every edge case, documented upfront.
2. System and Software Design — produce exhaustive architecture diagrams, UML schemas, data models, and interface specifications.
3. Implementation and Unit Testing — programmers write code according to the design, testing individual units against the spec.
4. Integration and System Testing — assemble all components and test the complete system against the requirements document.
5. Operation and Maintenance — deploy to the customer and maintain.

The defining rule: no going back. Each phase must be 100% complete and signed off before moving to the next. Changes discovered later are either ignored (to preserve the schedule) or trigger an expensive formal change-request process.

Why Management Loved Waterfall

• It looks beautiful on a Gantt chart: clear milestones, predictable schedules, a linear pipeline.
• The paper trail shifts accountability: the developers built exactly what was in the specification. If the specification was wrong, that is the requirements team’s fault.
• It mirrors construction: you pour foundations, erect the frame, install the plumbing, paint the walls — in order, each phase inspected before the next begins.

The Fatal Flaw

Software is not a bridge. If you realise halfway through building a bridge that it needs to move 10 miles left, you restart. In software, clients change their minds constantly because they do not know what they want until they see it.

The core problem with Waterfall is the time gap between requirements and delivery. In Phase 1, the team writes an exhaustive specification. Years later, in Phase 5, the customer sees working software for the first time. In the intervening years:

• The market has changed; competitors have shipped; business priorities have shifted.
• The customer, on seeing the actual software, realises what they actually needed — which is different from what they thought they needed back in Phase 1.
• Any fundamental architectural flaw, undetected because integration testing happens only in Phase 4, now requires a near-total rewrite.

The result: software that is obsolete on arrival, or software that is technically correct against the spec but solves the wrong problem.

The Spiral Model

Barry Boehm (1986) proposed an early fix for Waterfall’s rigidity. The Spiral Model is risk-driven: instead of doing everything once in a single pass, development happens in a series of loops (spirals), each incorporating risk evaluation and prototyping before committing to full development.

The four quadrants of each loop:

1. Objective Setting — define the objectives, constraints, and alternatives for this iteration.
2. Risk Assessment and Reduction — identify the biggest remaining risks. Build prototypes, run simulations, gather data. Do NOT commit resources to full development until the key risks for this iteration are understood and mitigated.
3. Development and Test — design, code, unit test, and verify. The nature of this work depends on the iteration: early spirals may produce only a prototype or proof-of-concept; later spirals produce production code.
4. Planning the Next Phase — review the results with stakeholders. Commit to the next iteration (or decide to stop). Plan what the next spiral will address.

Distance from the centre of the spiral represents cumulative cost expended. Early loops are cheap (prototypes); later loops are expensive (production code). This visual mapping makes explicit the relationship between investment and risk reduction: you spend a little to reduce risk, then you spend more to build.

When to Use Waterfall vs Spiral

Scenario	Recommended process	Reasoning
Flight control software	Waterfall (or heavily gated Spiral)	Requirements are stable and well-understood (physics of flight); the cost of a late-discovered defect is catastrophic (loss of life, cf. 737 MAX); extensive upfront verification and certification is mandated by law
A lecture-notes sharing app for students	Agile / Spiral	Requirements are unstable and best discovered by shipping to real students and iterating; the cost of a bug is low (inconvenience, not danger)
A new government tax-calculation system	Spiral with formal checkpoints	Requirements (tax law) change annually by legislation, so Waterfall’s frozen spec is impossible; but the financial and legal stakes demand formal sign-off gates between spirals

Expected Learning

• Define a software process and list its four fundamental activities.
• Describe the five Waterfall phases and explain why the model fails for most software projects, using the time-gap argument.
• Describe the four Spiral quadrants and explain how risk-driven iteration addresses Waterfall’s rigidity.
• For a given scenario, recommend an appropriate process (Waterfall, Spiral, or Agile) and justify the choice with reference to the specific risks and constraints in the scenario.

---

Past Paper Questions

Example Sheet 1, Question 5 asks you to choose an appropriate process for two contrasting scenarios (flight-control software vs a lecture-notes app) and to explain how a Sprint reduces the Translation Gap. You must be able to justify process choices with specific, scenario-relevant arguments — not generic textbook descriptions.