Skip to content

Waterfall Model Described (and Critiqued)

August 1970.Software.Paradigm shift.Date precision, month.Evidence grade, primary.2 primary sources

Drivers:

StandardisationCost reduction

The software crisis of the 1960s demanded structured approaches. Large projects needed predictable processes. Defence and government contracts required documented methodologies.

The waterfall model is a way of building software in steps: first gather requirements, then design, then code, then test, then release. Each step flows into the next like a waterfall. While it seems logical, in practice requirements often change, and waiting until the end to test can mean discovering problems too late.

Waterfall Model Described (and Critiqued) event plate

Structured atlas record showing date, domain, evidence grade, source count, and predecessor and successor links.

Event plate: Waterfall Model Described (and Critiqued) Convergence-divergence layout. The central hero card carries the event year, type, title, evidence grade, domain and era band. 0 predecessor cards on the left feed in with red arrows labelled "absorbs". 0 successor cards on the right derive with red arrows labelled "spawns". Key terms below the hero pin the vocabulary the event introduced. EVENT PLATE Source: https://dl.acm.org/doi/10.5555/41765.41801 1970 - PARADIGM SHIFT Waterfall Model Described(and Critiqued) primary evidence Domain: AI and machine learning Era band: E6 AI-scale systems KEY TERMS - VOCABULARY THE EVENT INTRODUCED waterfall software methodology SDLC sequential development Convergence-divergence: predecessors absorbed, successors spawned Hero card carries year, evidence and domain. 0 predecessors flow in from the left; 0 successors flow out to the right. Key termsbelow pin the vocabulary the event introduced.

Forecasts and counterfactuals stay labelled as opinion in the event data. Source: Computer History Museum.

Before

Large software projects frequently failed or exceeded budgets. There was no widely accepted methodology for managing software development. Ad hoc approaches could not scale to complex systems.

What changed

Winston Royce's paper described and critiqued the sequential 'waterfall' approach. Ironically, while arguing against a pure waterfall, his diagram became the model for decades of software development. The paper actually advocated for iteration and prototyping.

How it happened

Royce presented 'Managing the Development of Large Software Systems' at IEEE WESCON in August 1970. The paper included a diagram showing sequential phases (requirements, design, implementation, verification, maintenance). This diagram was widely adopted as the 'waterfall model', despite Royce's warnings about its risks.

Outcomes

  • Established first widely-known software methodology
  • Provided vocabulary for software phases
  • Influenced government and defence contracting standards
  • Created target for later agile critiques

Limitations

  • Sequential approach delays feedback
  • Changes late in process are expensive
  • Requirements rarely fully known upfront
  • Royce's iterative advice often ignored

Lessons learnt

  • Methodologies can be misinterpreted
  • Sequential development has fundamental risks
  • Iteration and feedback are essential
  • Visual diagrams become canonical beyond intent

Stakeholders and artefacts

Organisations

  • TRWvendorRoyce's employer

Individuals

  • Winston W. RoyceAuthor, TRWDescribed (and critiqued) waterfall model

Artefacts

  • Waterfall ModelmethodologySequential software development phases

Key terms

waterfallsoftware methodologySDLCsequential development

Causality

Made possible: Design Patterns Book Published (Gang of Four).

On this course

Read in the path Software Development: Waterfall to DevOps.

Sources

1Winston W. Royce. "Managing the Development of Large Software Systems". Proceedings of IEEE WESCON, 1970-08.peer revieweddl.acm.org/doi/10.5555/41765.41801
2Frederick P. Brooks Jr.. "The Mythical Man-Month: Essays on Software Engineering". Addison-Wesley, 1975.peer reviewed