waterfall model

The waterfall model is a software development process that runs through a fixed sequence of phases, where each phase is finished and signed off before the next one starts. It’s the strict single-pass reading of the software development life cycle, with requirements settled up front and working software arriving near the end.

A waterfall plan for a payroll system reads as a calendar of phase gates rather than a list of tasks:

Text 
Phase              Weeks    Exit gate
Requirements        1-6      Signed requirements specification
Design              7-14     Approved architecture document
Implementation     15-30     Code complete, all modules built
Verification       31-38     Test report, open defects closed
Deployment         39-40     Customer acceptance sign-off
Maintenance          41+     Support contract in effect

Each row starts only once the row above it has cleared its gate, which is where the name comes from. Water falls downhill and doesn’t flow back up.

Drag the slider below to move today through that schedule and watch each gate clear in turn:

Interactive diagram — enable JavaScript to view.

How It Shows Up in Practice

A Python developer usually meets the waterfall model as a contrast rather than as a daily routine, since most teams now describe themselves as agile. Job postings, onboarding docs, and retrospective conversations use waterfall as shorthand for long planning cycles and big-bang releases.

The phased shape survives in organizations that need an auditable paper trail, such as medical devices, aviation, defense, and finance. Fixed-bid contract work often keeps it too, because a client who signs for a fixed price needs a fixed scope to sign against.

Waterfall thinking also reappears at a smaller scale on teams that don’t think of themselves as running it. A ticket parked in a design column, waiting on an approval before anyone writes code, is a miniature waterfall inside a sprint.

Origins in Royce’s 1970 Paper

The model traces to Winston W. Royce’s 1970 paper “Managing the Development of Large Software Systems”, which diagrams seven steps: system requirements, software requirements, analysis, program design, coding, testing, and operations. The paper never uses the word waterfall. That label came later and is often credited to a 1976 paper by Bell and Thayer.

Royce drew the sequence to criticize it. Immediately below the diagram he writes, “I believe in this concept, but the implementation described above is risky and invites failure.” His objection is that the testing phase is the first point at which timing, storage, and input/output behavior are experienced rather than analyzed.

His proposed fixes pulled the process back toward iteration: document heavily, involve the customer throughout, and “do it twice” so the first build is a throwaway simulation of the final product. The industry adopted the diagram and skipped the advice. Later methods such as Scrum and the minimum viable product put the feedback loop back.

Continuous Integration with Python: An Introduction

Tutorial

Continuous Integration With Python: An Introduction

In this Python tutorial, you'll learn the core concepts behind Continuous Integration (CI) and why they are essential for modern software engineering teams. Find out how to how set up Continuous Integration for your Python project to automatically create environments, install dependencies, and run tests.

intermediate best-practices devops testing

For additional information on related topics, take a look at the following resources:

Have a question about this? Mentor AI can show you examples, compare related terms, and point you to tutorials.

  • Ask Mentor AI
  • Pick a question and Mentor AI takes it from here.
By Martin Breuss • Updated Oct. 19, 2026
Software Engineering Glossary Share Feedback