Waterfall delivers the finished product in one go, at the end. The incremental model hands over working parts one at a time, starting with the first usable one. Waterfall tends to suit projects where requirements are fixed by contract. Incremental suits projects where the scope will probably shift, or where users gain something from early releases.
Both models use the same phases, from requirements through maintenance. What changes is how often a team goes through them.
Formal standards moved the same way. In December 1994 the US Department of Defense replaced DoD-STD-2167A, which many read as favoring waterfall, with MIL-STD-498. The newer standard describes development in one or more incremental builds (Larman and Basili, IEEE Computer, 2003).
What is the difference between the waterfall and incremental models?
With waterfall, nobody outside the team sees anything until the whole product is built and released together.
With incremental, the first working part goes out early and the rest follow as they get finished.
Requirements are gathered upfront in both, and the phase names match. The gap is the number of trips through those phases before a customer sees something.
| Criterion | Waterfall | Incremental |
|---|---|---|
| Delivery | One release at the end | One release per increment |
| Phase sequence | Each phase is signed off before the next starts | Every increment runs its own design, build and test cycle |
| Requirements | Frozen early for the whole system | Defined up front, then prioritized per increment |
| Testing and feedback | After full implementation, one acceptance point | After each increment, with user feedback |
| Change handling | Change requests reopen signed-off phases | Changes land in a later increment |
Neither is a safe default. Both are among the lifecycle models teams choose between on any software project.
Quick comparison sheets often rate the two the same on cost and project size. That’s about where they stop being useful, since both ratings hinge on how stable the requirements are.
How does the waterfall model work?
Each phase finishes and gets signed off before the next one starts. Nothing overlaps, and the customer sees working software once, at the end.
Under a strict waterfall methodology, a project usually runs in this order:
- Requirements get gathered and written down for the full scope
- Design, covering the architecture and the detailed design that follows from the requirements
- Implementation, where developers build the whole system
- Verification, which is when testing starts, on the finished build
- Deployment as a single release to users
- Maintenance, meaning fixes and changes after launch
The first phase ends in a signed-off requirements specification, and every later phase treats it as fixed.
Documentation does the controlling here. Every sign-off hands the next team a document to work from, and that makes handovers and audits easier.
Testing waits until implementation is done, so the first full test of the system lands late, close to release.
The model fits when requirements are fixed and the technology is familiar. A small or contractually locked scope helps too.
The upsides are about control. Milestones and sign-off points are clear, and the heavy documentation supports handovers and audits. A fixed-scope contract is also simple to plan and price.
The downsides are about timing. There’s no working software until the final phase, so design and requirement errors only surface at testing. Change requests after sign-off reopen earlier phases. Customer feedback arrives once, at delivery.
Where the waterfall model comes from
Winston Royce described the sequence in his 1970 WESCON paper, “Managing the Development of Large Software Systems.” The paper never uses the word waterfall. Royce also called the implementation he described “risky and invites failure”.
He recommended building a pilot model first. In his example, a 30-month project carries a 10-month pilot, so the version delivered is effectively the second one (Larman and Basili, IEEE Computer, 2003).
That same IEEE Computer history traces iterative and incremental development back to the mid-1950s. The earliest published description the authors found is a 1968 IBM report by Randell and Zurcher.
Which means the strict single-pass sequence in many textbooks isn’t what Royce actually recommended.
How does the incremental model work?
The product gets split into parts, and the parts are built one after another. Each one goes through its own design and implementation work, then testing, before release. The first increment carries the core functionality, and later ones add scope on top of it.
Every increment reuses the waterfall phase order on a smaller slice. Read that way, the incremental model is a short waterfall pass repeated across the system.
IBM’s Federal Systems Division built the Space Shuttle’s primary avionics software in 17 iterations over 31 months, about eight weeks each, because the program’s requirements kept changing (Larman and Basili, 2003).
The same division ran the first Trident submarine’s command and control system in four time-boxed iterations of about six months, after a large upfront specification effort.
Incremental delivery doesn’t remove upfront specification. It only sequences what gets built from it.
| Strengths | Limits |
|---|---|
| Working software after the first increment | Architecture must be planned before increment one |
| Faults isolated to the latest increment | Integration and regression testing repeat every cycle |
| User feedback shapes later increments | Requirements must be clear enough to divide into increments |
| Scope changes land in a later increment | Later increments can force rework on finished ones |
How do testing, feedback and defect discovery differ between the two models?
Waterfall runs one big test of the whole system after implementation. Incremental teams test and gather feedback after every increment, which changes when design and requirement errors become visible.
In waterfall, the tests that check how modules work together can only start once all the code exists. Incremental builds integrate each new increment with the earlier ones, so integration problems show up in small batches.
That repeat has a price. Each new increment triggers a round of regression tests on what already worked, and the workload grows with the system.
Feedback follows the same split. Waterfall gets one acceptance point at delivery, and incremental gets one after every release. Risk behaves similarly: waterfall concentrates it at the final test, while incremental spreads it across releases and isolates faults to the latest increment.
NASA Johnson Space Center research (2004) on large hardware and software systems such as spacecraft and military aircraft puts the cost of a requirements error caught at integration and test at 21 to 78 times its cost in the requirements phase.
Waterfall puts its first full test at exactly that expensive point. Incremental runs a smaller version of the same test much earlier.
The advantage depends on what the first increment contains. If it skips the hardest integration work, the costly discovery just moves to a later increment.
Which model costs more when requirements change?
Neither is cheaper across the board. Waterfall wins on cost as long as the scope stays put. Once it starts moving, incremental usually comes out ahead.
In waterfall, a change after sign-off reopens the requirements, the design and any code already built, and then verification has to be repeated. In an incremental project the change goes into a later increment, unless it touches one that has already shipped.
Waterfall sends every request through a formal change request process. That gate exists because sign-offs are expensive to reopen. In incremental work the same request is just a priority call made before the next increment starts.
Where sources split is on how big the penalty really is. Boehm and Basili (IEEE Computer, 2001) report that fixing a problem after delivery often costs 100 times more than fixing it during requirements and design, but only about 5:1 for small, noncritical systems.
The NASA multiplier from the testing section above belongs to the same family of cost-escalation claims. It came from spacecraft-type systems, which sit at the large, critical end of that range.
Laurent Bossavit challenges the whole curve in The Leprechauns of Software Engineering. He traced its evidence and found it short of research standards, with one cited study showing a 2:1 ratio in the opposite direction (as reported by TechWell, 2013).
Both positions hold up as published. The large studies do show late fixes costing more. The general curve just rests on thinner evidence than its reputation suggests.
Comparison pages muddy this further. Some rate incremental as low cost, same as waterfall, and others rate it costlier. Both can be right. Waterfall stays cheap when scope never changes, and incremental carries integration and regression overhead in every cycle.
On a small internal tool I’d assume change is cheaper than the textbook curve says. A large system with hardware dependencies or formal sign-offs is a different story, and there I’d assume it isn’t.
How do you choose between the waterfall and incremental model for a project?
Start with requirement stability, then ask whether a partial release is worth anything. Project size on its own settles nothing.
PMI’s 2024 Pulse of the Profession found that teams perform equally well under predictive, hybrid and agile approaches. Neither model wins on its own, so fit does the work.
Will the requirements hold? If they’re fixed and contractually locked, that points to waterfall. If they’re likely to move, go incremental.
Does a partial release earn anything? If users or a sponsor benefit before the final date, build in increments. If nothing is usable until the whole system exists, a single release costs nothing extra.
Can the system be split into modules with stable interfaces? If it can’t, increments end up depending on each other and the incremental model loses its point.
Customer review matters too. Without feedback on each release, increments are just a slower waterfall.
A contract that demands full sign-offs and documentation rarely decides anything alone, since both models can produce them. And if the scope is small and well understood, take the simpler option and skip the integration overhead.
Regulated and contract-driven work
In medical device software, IEC 62304 (the lifecycle standard for the field) does not prescribe a lifecycle model, according to RAPS guidance on software as a medical device. Regulation doesn’t force the waterfall model.
On the US defense side, DoD Instruction 5000.87 (October 2, 2020) requires programs on the Software Acquisition Pathway to demonstrate a viable, effective capability for operational use within one year after funds are first obligated, and to deliver new capabilities at least annually after that. The instruction also keeps safety-critical software standards in force.
Either way, the compliance obligations attached to the product stay the same, so the model only changes how the evidence gets produced.
When do the waterfall and incremental models break down?
Waterfall falls apart once requirements keep moving after sign-off. Incremental has a different weak spot, which is skipping the architecture decisions before the first increment.
| Model | Wrong-fit case | Symptom |
|---|---|---|
| Waterfall | Requirements still forming | Change requests pile up after sign-off |
| Waterfall | New or unproven technology | Design assumptions fail at integration |
| Incremental | System cannot be split into modules | Increments depend on each other, nothing ships alone |
| Incremental | Architecture left open | Each increment rewrites earlier ones |
Where the waterfall model fails
A 1999 review of earlier US Department of Defense projects found that 75% of a $37 billion sample failed or were never used, and only 2% were used without extensive modification (Jarzombek, as quoted in the 2003 IEEE Computer history by Larman and Basili).
A Defense Science Board task force chaired by Frederick Brooks recommended replacing the waterfall approach on large projects in 1987. DoD changed its standards at the end of that year to allow iterative development.
Parnas and Clements (1986) explained why the strict sequence breaks in practice. Users seldom know exactly what they want. Implementation exposes details nobody could state up front, and one person can’t master the full complexity of a large system. External forces also change requirements and invalidate earlier decisions.
Every one of those hits a model that freezes its requirements specification first.
Where the incremental model fails
Incremental development tends to erode its own design.
Sommerville’s Software Engineering textbook lists two management problems. The process is hard to see from outside, and system structure degrades as increments pile up. Regular change corrupts the design unless the team spends time refactoring the code between increments.
The same textbook says these problems get severe on large systems, where there are more modules and more places for structure to drift. Long-lived systems have the same trouble after years of accumulated increments, and so do projects with several teams, since nobody owns the whole design.
The fix is to settle the architecture before the first increment and to budget refactoring time inside every increment after it.
Waterfall vs Incremental Model FAQ
Is the incremental model the same as the iterative model?
Not quite. Incremental development grows the product by adding parts. Iterative development works the other way, improving parts through repeated passes.
Work that refines a part through repeated passes is often blended with incremental delivery, which is why the literature usually writes iterative and incremental development as one term.
Can the waterfall and incremental models be combined?
Yes. A common pattern fixes requirements and architecture up front, then builds and releases in increments, each run as a short waterfall pass.
The V-model, a waterfall variant that pairs each development phase with a matching test level, can be applied per increment when verification rules are strict.
How do the two models differ from the spiral model and RAD?
Both add something waterfall and incremental lack. The spiral model, published by Barry Boehm in the mid-1980s, makes a formal risk assessment step part of every iteration.
Rapid application development (RAD) takes another route and shortens the cycle through component-based construction.
Is the incremental model agile?
Not by itself. Incremental delivery is a practice agile methods rely on, but an incremental project can be fully plan-driven, with every increment defined in advance.
In the agile version, only the early increments are fixed, and later ones follow progress and customer priorities (Sommerville, Software Engineering).
Is the waterfall model still used today?
Yes, mainly where scope is fixed or contracts demand formal sign-offs, and increasingly as one part of a hybrid setup.
PMI reported hybrid adoption rising from 20% in 2020 to 31.5% in 2023 (Pulse of the Profession, 2024).
When Is Switching Models Mid-Project Worth It?
Switching from waterfall to incremental mid-project pays off when completed phases stay valid and the remaining scope can be split into releasable slices.
Timing depends on system size. Read together, Boehm and Basili’s 5:1 ratio for small noncritical systems and 100:1 for large ones put the cutoff late for small projects and before implementation ends for large ones.
Start by auditing the signed-off phases for work that still holds, so finished work doesn’t get rebuilt. Then slice the remaining scope, riskiest integration first. Re-baselining the plan and contract terms comes last, since the new plan needs real increments to schedule.
What you give up is schedule certainty. One final date becomes a series of release dates, each tied to a smaller scope. A revised software development plan should record the slice order and the release dates, plus what each increment covers.
- VS Code Extensions That Are Actually Worth Installing - October 13, 2026
- Google Play App Signing Explained - October 11, 2026
- 5 Best NinjaOne Alternatives for Focused Endpoint Management - October 10, 2026
