SDLC — waterfall, V-model, iterative, agile: Visual walkthrough

See the parent map first: SDLC — waterfall, V-model, iterative, agile. This page zooms into the engine underneath the Cost of Change Curve.

Step 1 — What is a "defect", and what is a "phase"?

WHAT we're doing: laying a numbered timeline of the project.

WHY: the whole claim is "cost depends on how late you catch the defect." "How late" needs a ruler. The phase number $p$ is that ruler — it counts how many phases have passed since the defect entered.

PICTURE: five boxes in a row, left to right. A defect is a red dot that enters at phase 0 and secretly rides forward until caught.

Figure — SDLC — waterfall, V-model, iterative, agile

Step 2 — What does it cost to fix a defect right where it was born?

WHAT: we name that cheapest cost $c_{0}$ .

WHY: every cost on the curve will be measured in units of this baseline. Calling it $c_{0}$ (not " $5") l e t s u s t a l k inm u l t i pl es l ik e "$ 10\times$" — which is how the curve is always quoted.

PICTURE: the red defect caught inside its own birth-box. Only ONE thing needs re-touching — the requirement itself. We draw exactly one repair arrow.

Step 3 — Why does catching it ONE phase later cost more? (The layer idea)

WHAT: we count "stuff to re-touch" as the number of layers built on top of the defect.

WHY: this is the insight the parent note asserted ("each later phase builds dependencies on top of the bug"). We make it literal: one phase later = one extra dependent layer to rip out and redo.

PICTURE: same red defect, but now caught at Design ( $p = 1$ ). Two repair arrows point back: one to Requirements, one to Design. The stack is taller.

Recall Why "on top of" and not "beside"?

A phase later doesn't just add unrelated work — it adds work that assumed the defect was fine. That assumption is the glue. Pull the defect out and everything glued to it comes loose. ::: Because later phases consume the output of earlier ones, dependencies point downstream, so a defect's blast radius grows every phase.

Step 4 — Why MULTIPLY (exponential), not ADD (straight line)?

WHAT: we replace "add a pile" with "multiply by $k$ " once per phase.

WHY THIS TOOL — why multiplication? A quantity that grows by the same factor every step is, by definition, exponential. We reach for exponentials (not addition) precisely because the rework scales with how much already exists, and how much exists is itself growing each phase. "Growth proportional to current size" is the fingerprint of exponential growth — the same reason money compounds instead of adding.

PICTURE: a branching tree. One defect at $p = 0$ ; at each phase every branch splits into $k$ branches. The count of leaves (things to fix) is $k^{p}$ , not $k \times p$ .

Step 5 — Assemble the curve

WHAT: we write the finished law.

WHY: this is the parent note's headline formula — now derived, not merely stated.

PICTURE: plot the cost against phase. On a normal (linear) vertical axis it looks like a rocket taking off; the same data on a log vertical axis becomes a straight line — the tell-tale signature of exponential growth.

Step 6 — The edge case: what if $k = 1$ ? (Degenerate curve)

WHAT: set $k = 1$ and see what the law becomes.

WHY: covering the degenerate case tells you when the curve flattens. It's not a math curiosity — it's literally what agile chases.

PICTURE: with $k = 1$ the exploding curve collapses into a flat horizontal line. Cost no longer depends on $p$ .

Step 7 — Reading each SDLC model OFF the curve

WHAT: mark each model's typical detection point on the curve.

WHY: this unifies the parent note. Waterfall, V-model, iterative, agile stop being four disconnected boxes and become four dots on one exponential.

PICTURE: the curve with four labelled dots — Waterfall far right (high $p$ , high cost), V-Model designs its tests early to pull detection left, Iterative resets $p$ each cycle, Agile lives near $p \approx 0$ .

Recall Where each model sits and why

Waterfall tests only after coding → detection at large $p$ → deep on the curve. ::: V-Model writes the tests early (pairing each design step with a test step per Verification and Validation and Software Testing — Unit Integration System Acceptance) so validation happens sooner. Iterative resets the clock each loop. Agile keeps $p$ smallest — see Risk Management and Requirements Engineering for why early feedback also kills requirement defects.

The one-picture summary

This final figure stacks the whole derivation: (left) the defect as a red dot riding forward through phases; (middle) each phase adding a dependent layer that fans out by $k$ ; (right) the resulting exponential $c_{p} = c_{0} k^{p}$ with the four SDLC models pinned to their detection points.

Recall Feynman retelling — explain it to a 12-year-old

Imagine you glue a wrong LEGO brick at the very bottom of a tower. If you notice right away, you just swap it — one move. But if you keep building, everything you stacked on top is now standing on that wrong brick. To fix it you must lift off every layer above, fix the brick, and rebuild each layer. And here's the sneaky part: each layer you rebuild forces you to re-check all the layers under it again. So the work doesn't just add up — it multiplies. Notice at level 0: cost is 1. Level 1: cost is 10. Level 2: cost is 100. That "times ten each level" is exactly $c_{0} \cdot k^{p}$ . Now the four ways teams build software are just four habits about how tall the tower gets before someone looks: Waterfall looks only at the very top (super expensive surprises), Agile looks after every single brick (tiny cheap fixes). Same curve — different place to stand on it. ::: The exponential comes from rework re-triggering the layers beneath it, and every SDLC model is a strategy to catch defects at a small phase number $p$ .