Comparing software process models: which to use and when

Process models are usually taught as a list to memorise. They are more useful read as answers to one question: how much do you know up front, and what does it cost to be wrong?

The models

Waterfall

Sequential phases with a sign-off gate between each. All requirements first, then all design, then implementation, then testing.

Works when requirements are externally fixed and iteration is expensive. Fails when requirements emerge from seeing the product, because validation happens at the end where fixing things costs the most.

V-model

Waterfall folded so each specification phase pairs with a verification phase — requirements with acceptance testing, architecture with integration testing, detailed design with unit testing.

Improvement: test planning happens alongside each phase, so ambiguous requirements surface while writing the acceptance criteria rather than months later. Standard in regulated and safety-critical work because it produces traceability naturally.

Incremental

The system is divided into pieces, each delivered fully. Requirements are largely known; delivery is staged.

Works when the scope is understood but the whole thing is too large to deliver at once, and partial delivery has value.

Spiral

Repeated cycles of objectives, risk analysis, development and planning, with each cycle explicitly driven by the largest remaining risk.

Distinctive property: risk is the scheduling principle. The riskiest unknown is attacked first, typically with a prototype built to answer one question. Heavyweight, and appropriate for large systems where an unexamined assumption could waste a year.

Agile

Short iterations producing working software, with requirements expected to change. Scrum and Kanban are the common implementations.

Works when iteration is cheap and a customer is available to give feedback. Requires automated tests and continuous integration — without them, "welcome changing requirements" accumulates defects rather than absorbing change.

Comparison on the dimensions that matter

• Requirements stability. Waterfall and V-model assume high stability. Agile assumes low. Incremental sits between. Spiral tolerates uncertainty by attacking it deliberately.
• When you find out you were wrong. Waterfall: at acceptance testing. V-model: at each verification stage. Agile: at the end of each iteration. Spiral: at the end of each risk cycle. This single dimension explains most of the difference in outcomes.
• Cost of change late. High in sequential models by construction; flat in agile if the technical practices are present, and steeply rising if they are not.
• Documentation produced. Sequential models produce it as a by-product. Agile produces it deliberately or not at all — which is a choice, not an exemption.
• Auditability. V-model wins outright. If a regulator must trace a requirement to the test that verified it, the process needs to produce that trail.
• Customer involvement. Minimal after sign-off in waterfall; continuous in agile. If the customer genuinely cannot commit time throughout, agile will not work as intended regardless of the ceremonies performed.

Choosing

1. Are the requirements fixed by something outside the project — a regulation, a protocol, a contract? If yes, sequential is defensible and often required.
2. What does one iteration cost? Deploying a web service costs minutes. Recertifying a medical device costs months. Cheap iteration favours agile; expensive iteration favours planning.
3. What is the largest unknown? If one technical assumption could invalidate the project, address it first — that is the spiral instinct, and it applies inside any model.
4. Is the customer available? Agile without feedback is iteration without learning.

The honest answer for most projects

Most real projects are hybrids, and that is not a compromise. A regulated core delivered sequentially with full traceability, surrounded by a user-facing layer developed iteratively, is a coherent design. The mistake is adopting a model as an identity rather than choosing it per component — and then applying its ceremonies to work it does not suit.