The Waterfall Model, and What Royce Actually Said
Chapter Fourteen
Syllabus topic Module 1, "Software Development Life Cycle (SDLC): Overview of SDLC"
Pages 77 to 81 of 622
In one line
The waterfall model builds software in a fixed sequence of phases, requirements, then design, then code, then test, then operation, each finished before the next begins, like water falling from one step to the next.
In the wording a student can write in an examination: the waterfall model is a "model of the software development process in which the constituent activities, typically a concept phase, requirements phase, design phase, implementation phase, test phase, and installation and checkout phase, are performed in that order, possibly with overlap but with little or no iteration" (ISO/IEC/IEEE 24765:2017). It is the classic sequential model, usually traced to Winston Royce's 1970 paper, which in fact argued that the simple sequence is risky and must be supplemented.
Why a sequence was attractive
In the 1960s large software was new, and it was being built for customers like governments and space programmes who paid by contract. A fixed sequence of phases, each ending in an approved document, suited them. Each phase had a clear deliverable to sign off, progress could be measured by which phase was finished, and a customer could be held to requirements agreed at the start. The same logic still suits some projects today: where requirements are stable and well understood, planning the whole job once is efficient.
What Royce drew
Royce's paper, "Managing the Development of Large Software Systems", was given at the IEEE WESCON conference in August 1970. He begins with the simplest possible development, just analysis followed by coding, which is enough for a small program used by the people who wrote it. For a large system delivered to a customer he draws seven steps:
- System requirements
- Software requirements
- Analysis
- Program design
- Coding
- Testing
- Operations
That staircase, his Figure 2, is the diagram every textbook reproduces. What the textbooks usually drop is what he said next.
Figure 14.1 Royce 1970: the seven steps (Figure 2), iteration between successive steps (Figure 3), and testing sending the work back to design (Figure 4)
What Royce actually said about it
Straight after the staircase, Royce writes: "I believe in this concept, but the implementation described above is risky and invites failure." The problem, he explains, is where testing sits. "The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed." If those real behaviours fail to meet the constraints, the fix is not a small patch but a redesign, and the redesign can violate the requirements on which the whole design rested. The project is back at the start, with, in his estimate, up to a 100 per cent overrun in schedule or cost.
The Waterfall Model, and What Royce Actually Said
He does not throw the sequence away: "However, I believe the illustrated approach to be fundamentally sound." Instead he adds five features to reduce the risk, and every one of them is still good advice.
| Royce's step | What he meant | Where it lives in this book |
|---|---|---|
| 1. Program design comes first | Do a preliminary program design before analysis, so that storage, timing and interfaces are considered early | Design reviews (Chapter Twenty-Eight, on software reviews) |
| 2. Document the design | "quite a lot" of documentation; he calls "ruthless enforcement of documentation requirements" the first rule of managing software development | The test documents (Chapter Twelve) |
| 3. Do it twice | Build a pilot version first, a simulation of the whole process in miniature, so the delivered version is really the second | Prototyping (Chapter Sixteen, on iterative, incremental and spiral models) |
| 4. Plan, control and monitor testing | Testing is the biggest user of resources and the phase of greatest risk; plan it, use specialists, inspect every line, test every path | The test process, plan and levels (Chapters Five, Eleven and Thirty-Two) |
| 5. Involve the customer | Commit the customer formally at points after the requirements are defined, not only at the end | Validation and acceptance testing (Chapters Forty-One and Forty-Two) |
Royce on testing, fifty years early
Step 4 is worth reading in full, because it anticipates half of this syllabus. Royce writes: "Without question the biggest user of project resources, whether it be manpower, computer time, or management judgment, is the test phase. It is the phase of greatest risk in terms of dollars and schedule." He then recommends four things:
- Independent testers. Many parts of testing are best done by specialists who did not contribute to the design; if only the designer can test the design, the documentation has failed. This is the independent test group of Chapter Thirty-One, on the strategic approach to testing.
- Visual inspection by a second person. Most errors are obvious and can be spotted by a second party scanning the analysis and the code, "dropped minus signs, missing factors of two, jumps to wrong addresses". This is the review and inspection of Chapters Twenty-Eight and Twenty-Nine, six years before Fagan published inspections.
- Every logic path, at least once. "Test every logic path in the computer program at least once with some kind of numerical check." This is path and branch coverage (Chapters Fifty-Nine to Sixty and Seventy-Two).
- The computer last. Only after the simple errors are removed should the software go to formal checkout on the machine.
The paper that gave the world the sequential model also argued for early reviews, independent testing, coverage and a pilot version. The model that took its name kept the staircase and dropped the advice.
The Waterfall Model, and What Royce Actually Said
The waterfall model as it is taught
The textbook waterfall keeps Royce's staircase in its simplest form. Its properties follow directly from the sequence.
| Strengths | Weaknesses |
|---|---|
| Simple to understand and manage; progress is visible by phase | Working software appears only at the end, so users see nothing until late |
| Each phase ends in a reviewed document, useful for contracts and audits | Requirements are frozen early, but users often discover what they need only when they see the system |
| Suits stable, well-understood requirements and fixed-price contracts | Defects in requirements and design are found late, in testing, when they are most expensive (Chapter Three, on why software must be tested) |
| Easy to assign people to phases | Testing is squeezed when earlier phases overrun, because the deadline does not move |
| Works where regulation demands documented phase gates | Poor at absorbing change; going back a phase is costly |
Where testing sits in the waterfall
In the pure waterfall, testing is a phase near the end: the code is complete, then it is tested. That is exactly the placement Royce warned about. The ISTQB syllabus describes the consequence for any sequential model: "in the initial phases testers typically participate in requirement reviews, test analysis, and test design. The executable code is usually created in the later phases, so typically dynamic testing cannot be performed early in the SDLC."
The sentence contains the remedy. Even in a strict waterfall, testers need not wait: they can review the requirements and designs as they are written (static testing) and design their tests while the code is being built. The V-model, the next chapter, is essentially the waterfall with that remedy drawn into it.
Worked example: ExamReg in a pure waterfall
Suppose ExamReg release 2.0 were run as a pure waterfall over sixteen weeks: requirements weeks 1 to 3, design 4 to 6, coding 7 to 12, testing 13 to 15, deployment week 16. Coding overruns by two weeks, as coding often does. The deadline cannot move, because the examination form opens on a fixed date. Testing shrinks from three weeks to one.
In that one week, testing finds that the portal slows to a crawl above 300 simultaneous users, far short of the 500 expected on the last day. The cause is the design of the fee service, fixed in week 5. This is Royce's Figure 4 exactly: a real behaviour, "experienced as distinguished from analyzed", met for the first time in the test phase, and the fix is a redesign, not a patch. The team now chooses between releasing a portal that will fail on the last day and missing the date.
Every remedy in this book is a way of moving that discovery earlier: a design review in week 5 asking how the fee service handles 500 users; a small load test of a pilot version, Royce's "do it twice"; or an iterative model in which a working fee service exists by week 6.
The Waterfall Model, and What Royce Actually Said
What it does not mean
Royce did not recommend the simple waterfall. He called it "risky" and said it "invites failure", then added five steps to fix it.
The word "waterfall" is not in Royce's paper. It does not occur anywhere in the text; the name was attached to his staircase later.
Waterfall does not forbid going back. The standard definition allows "overlap" and "little" iteration, and Royce drew iteration between successive steps; what the model resists is going back more than a step.
Sequential does not mean testers wait until coding ends. Reviews and test design run alongside the early phases even in a waterfall.
Quick revision
- Waterfall model: phases performed in order, possibly with overlap, "with little or no iteration" (ISO/IEC/IEEE 24765:2017); the classic sequential model.
- Royce 1970 (IEEE WESCON): seven steps: system requirements, software requirements, analysis, program design, coding, testing, operations.
- Royce: "risky and invites failure", because testing is the first time real behaviour is met; up to 100 per cent overrun.
- His five fixes: program design comes first; document the design; do it twice; plan, control and monitor testing; involve the customer.
- His testing advice: independent specialists, visual inspection by a second person, every logic path tested at least once, the computer last.
- Strengths: simple, documented, good for stable requirements and contracts. Weaknesses: late working software, late defects, poor with change, testing squeezed.
Test yourself
1. Explain the waterfall model with its phases. A sequential model in which each phase is completed before the next begins: in Royce's form, system requirements, software requirements, analysis, program design, coding, testing and operations. Each phase ends in a document that becomes the input to the next, with little or no iteration.
2. What did Royce say was wrong with the simple sequence? That it is risky and invites failure, because testing at the end is the first time timing, storage and input/output are experienced rather than analysed. A failure then usually demands a redesign that can break the requirements, sending the project back to the start with up to a 100 per cent overrun.
3. State Royce's five recommended steps. Program design comes first; document the design; do it twice (build a pilot version); plan, control and monitor testing; involve the customer.
4. Give three advantages and three disadvantages of the waterfall model. Advantages: simple to manage, with progress visible by phase; documented phase outputs useful for contracts and audits; efficient when requirements are stable. Disadvantages: working software only at the end; requirement and design defects found late and expensively; poor at absorbing change, with testing squeezed when earlier phases overrun.
The Waterfall Model, and What Royce Actually Said
5. Where does testing sit in the waterfall, and how can testers still start early? Dynamic testing is a late phase, after coding. Testers can still start early by reviewing the requirements and designs as they are written and by designing their tests during the earlier phases.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself, or the past papers, for the same subject.