Waterfall

The Waterfall model organizes a software project as a series of phases, typically requirements, design, implementation, testing, deployment, and maintenance, where each phase is finished and signed off before the next one begins. The name comes from the way progress flows in one direction, like water falling down a series of steps. It is usually traced to a 1970 paper by Winston Royce, who, ironically, described the purely sequential version as risky and recommended adding feedback loops.

A Waterfall project front-loads planning. Requirements are gathered and written down in detail at the start, often in a specification the customer approves, and designers turn that document into an architecture before any code is written. Developers then build the whole system, testers verify it near the end, and it is delivered in one release. Changes after sign-off go through a formal change control process, because a new requirement can ripple back through every earlier phase.

Waterfall works like building a house: you finalize the blueprints before pouring the foundation, because moving a wall later is expensive. It still suits projects where requirements are stable and well understood, where change is costly, or where regulations demand thorough documentation, such as embedded software for medical devices, aerospace systems, and some fixed-price government contracts. Its main weakness is that users see working software only at the end, so misunderstandings surface late, when they are most expensive to fix.

Waterfall is usually contrasted with Agile. Agile repeats short cycles of planning, building, and reviewing, delivering working software every few weeks and welcoming changing requirements, while Waterfall performs each activity once in a long sequence. In practice many organizations use hybrids, such as a Waterfall-style overall plan with Agile sprints inside it, and the V-model is a well-known Waterfall variant that pairs each development phase with a matching level of testing.