SDLC — waterfall, V-model, iterative, agile: Worked examples

The scenario matrix

Think of choosing an SDLC as reading two "coordinates" of a project, exactly the way a point on a plane has an $x$ and a $y$ . Here the two coordinates are:

Requirement stability $R$ — from frozen (never changes) to volatile (changes weekly).
Cost of late change $C$ — from catastrophic (a shipped bug kills someone / breaks a contract) to cheap (push a fix in five minutes).

Every real project lands somewhere in that 2-D space. The matrix below enumerates every class of cell — including the weird edges (zeros, degenerate inputs, limits) that a naive "just use Agile" answer never covers.

Cell	Requirement stability $R$	Late-change cost $C$	This is the analogue of…	Covered by
A	Frozen	Catastrophic	quadrant I (both large)	Ex 1
B	Volatile	Cheap	quadrant III (both small)	Ex 2
C	Frozen	Cheap	mixed signs	Ex 3
D	Volatile	Catastrophic	the hard mixed quadrant	Ex 4
E	Medium, big & risky	Medium	interior point	Ex 5
F	$R = 0$ (no requirements exist yet)	undefined	zero input	Ex 6
G	Team size $= 1$	any	degenerate input	Ex 7
H	$C \to 0$ (deploy is instant & free)	limit	limiting value	Ex 8
I	Real-world word problem	—	applied	Ex 9
J	Exam twist (the trap)	—	adversarial	Ex 10

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

Let me also pin down the number we keep reusing.

Ex 1 — Cell A: frozen + catastrophic

Steps.

Read the coordinates. $R$ = frozen (standard-defined), $C$ = catastrophic (patient safety + certification). Why this step? Every choice starts by locating the project on the matrix — same as reading $(x, y)$ before you can plot a point.
Reject Agile. Agile buys cheap change by re-planning constantly. But here change is forbidden, so we'd pay Agile's re-planning tax for a benefit we can't use. Why this step? You only pay for a feature if you'll use it. Frozen requirements ⇒ the Agile benefit is worthless here.
Choose V-Model over plain Waterfall. We need traceability: each requirement paired with the exact test that proves it. The V-Model pairs every left-arm design phase with a right-arm test phase. Why this step? The regulator's demand ("prove requirement $i$ was tested") is exactly the requirement ⟷ acceptance-test pairing the V-Model is built to give.

Answer: V-Model.

Verify: Put a number on the alternative. Suppose iterative would have caught a spec bug at iteration cost $c_{0} \cdot k^{0}$ , but because certification cannot be re-opened mid-flight the realistic catch point is deployment, $p = 4$ . Cost ratio $k^{4} = 1 0^{4} = 10000 \times$ . The catastrophic late cost confirms we belong in the "design tests early, freeze hard" region. ✓

Ex 2 — Cell B: volatile + cheap

Steps.

Read coordinates. $R$ = volatile, $C$ = cheap (instant rollback). Why? Same first move: locate on the map.
Compute the Agile "tax vs benefit". Agile costs overhead (constant re-planning) but buys near- $1 \times$ change. Here requirements churn and change is already cheap — so we want the model that welcomes churn. Why? When change is both frequent and cheap, the model that "never locks far ahead" wins by default.
Pick Agile; then pick the flavour. Continuous flow of small items with no fixed batch → Kanban. Fixed 2-week batches with planning ceremonies → Scrum. Engineering-discipline heavy (pairing, TDD) → Extreme Programming. Why? "Agile" is a family; the sub-choice depends on whether work arrives in a steady stream (Kanban) or in planned batches (Scrum).

Answer: Agile (Kanban here, given the continuous stream).

Verify: A wrong feature enters the next pull/sprint at cost $\approx c_{0} \cdot k^{0} = c_{0}$ . Compare to waterfall's $c_{0} \cdot k^{4}$ . Ratio $= k^{4} = 10000$ . Agile is $10000 \times$ cheaper per late change — and there are many late changes here, so the saving compounds. ✓

Ex 3 — Cell C: frozen + cheap (the "either works" cell)

Steps.

Read coordinates. $R$ = frozen, $C$ = cheap. Why? Locate the point — it sits low (cheap) and right (frozen).
Notice both axes are "easy". Waterfall's weakness (late discovery) is defanged because late change is cheap. Agile's benefit (welcoming change) is unused because requirements are frozen. Why? When both risks are low, the models converge — the deciding factors that separate them are absent.
Choose by overhead, not by risk. With no risk to manage, pick the lowest-ceremony path: a single quick Waterfall pass (spec → build → ship). Adding sprint ceremonies would be pure overhead. Why? Among options that all "work", the tie-breaker is cost of running the process itself.

Answer: Waterfall (lightweight), chosen because it has the least overhead, not because it's safest.

Verify: Overhead-only comparison. If Scrum adds, say, 4 hours/week of ceremonies over a 1-week build, that's $4$ wasted hours buying protection worth $\approx 0$ (change is already cheap). Net value of ceremony $\leq 0 \Rightarrow$ skip it. ✓

Ex 4 — Cell D: volatile + catastrophic (the hard quadrant)

Steps.

Read coordinates. $R$ = volatile, $C$ = catastrophic. Both axes are "hard". This is the dangerous quadrant. Why? This is the analogue of a mixed-sign quadrant: the naive one-axis rule fails because the two axes pull opposite ways.
Refuse the false choice. Pure Agile drops the safety rigor; pure V-Model can't absorb weekly change. Neither pure model fits. Why? When both coordinates are extreme, no single pure model covers both needs — you must blend.
Blend: iterative core + gated release. Use short iterations to absorb changing requirements, but wrap every release in a V-Model-style verification gate (full regression + acceptance suite) before anything reaches a real car. This is "Agile inside, waterfall gate outside" — and it leans on Risk Management to sequence the scariest scenarios first. Why? Iterations answer volatility; the gate answers catastrophe. Each hard axis is handled by the tool built for it.

Answer: Iterative development behind a heavyweight verification gate (a hybrid).

Verify: Two ledgers. Requirement-churn cost stays near $c_{0}$ because it enters the next iteration ( $p = 0$ ). Safety-defect escape cost is bounded by the gate: a bug caught at the gate ( $p = 3$ , system test) costs $k^{3} = 1000 c_{0}$ , but a bug that reaches the road ( $p = 4$ ) costs $k^{4} = 10000 c_{0}$ . The gate saves $k^{4} - k^{3} = 9000 c_{0}$ per escaped safety bug — which justifies its overhead. ✓

Ex 5 — Cell E: interior point (big, risky, evolving)

Steps.

Read coordinates. $R$ = medium, $C$ = medium, plus a spike of technical risk in one component. Why? An interior point isn't at any extreme, so the deciding feature is the third dimension — risk concentration.
Identify the risk-first goal. We want to discover "does the rules engine scale?" cheaply, before 17 more months build on top of it. Why? If the risky part is impossible, finding out at $p = 0$ (iteration 1) beats finding out at $p = 4$ (deployed) by $k^{4} = 10000 \times$ .
Choose Iterative. Iteration 1 builds a thin end-to-end slice through the risky rules engine. If it works, keep looping; if not, we learned it in weeks. Why? Iterative's whole purpose is "do the scariest part first, on a running build." That maps exactly onto this interior-with-a-risk-spike point.

Answer: Iterative & incremental, sequencing the highest-risk slice into iteration 1.

Verify: Cost of learning the engine is unscalable: iterative $= c_{0} \cdot k^{0} = c_{0}$ ; waterfall $= c_{0} \cdot k^{4} = 10000 c_{0}$ . Doing the risky slice first is $10000 \times$ cheaper to fail. ✓

Ex 6 — Cell F: zero input (no requirements exist yet)

Steps.

Detect the degenerate input. Waterfall/V-Model both begin with "complete requirements." With zero requirements, that input is undefined — like dividing by zero, the classic models are undefined here. Why? You must catch the empty-input case before applying a formula that assumes non-empty input.
Reframe the goal as discovery. The real first task isn't "build" — it's generate requirements. See Requirements Engineering. Why? You can't verify or validate against a spec that doesn't exist; you must first create the spec.
Choose Agile / lean-startup iteration. Ship a tiny prototype, show users, let their reactions become the first requirements. Each sprint converts "we don't know" into "we now know a little more." Why? Agile is the only family that treats "requirements emerge from feedback" as normal rather than as failure.

Answer: Agile (build-measure-learn), because with the requirement set empty the sequential models are undefined and only feedback can populate it.

Verify: Consistency check: if $R = \emptyset$ , the number of testable requirements available to a V-Model at start $= 0$ , so its acceptance-test suite has $0$ tests — a V-Model with an empty right arm collapses to no process. Confirms the sequential models are unusable at $R = 0$ . ✓

Ex 7 — Cell G: degenerate input (a team of one)

Steps.

Detect the degeneracy. Team size $= 1$ . Many process artifacts exist to synchronise multiple people (standups, reviews, contracts). Why? When the count of a thing (people) hits its degenerate value (1), machinery built for coordination between many becomes empty.
Strip coordination overhead. A daily standup "with yourself" carries zero information. Formal handoff documents between phases have no recipient. Why? A process step whose only purpose is inter-person communication is pure cost when there's one person.
Keep the value-carrying parts only. Retain iterative build-and-test loops (feedback from the running program is still real) but drop team ceremonies. This is Agile's mindset without its team ritual. Why? The feedback loop's value survives (the computer still tells you when you're wrong); the coordination rituals' value vanishes.

Answer: Lightweight iterative loop — Agile's feedback core, none of its multi-person ceremony.

Verify: Ceremony value scales with coordination pairs. With $n$ people, the number of communication links is $(2 n) = \frac{n ( n - 1 )}{2}$ . At $n = 1$ that is $0$ , so coordination-ceremony value $= 0$ . Degenerate case confirmed. ✓

Ex 8 — Cell H: the limiting case ( $C \to 0$ )

Steps.

Take the limit in the cost model. The whole SDLC debate is about $c_{p} \approx c_{0} k^{p}$ : late defects cost more. Drive the penalty toward zero — i.e. imagine catching-late is no longer expensive. Why? Every model choice was a strategy against the $k^{p}$ penalty. Remove the penalty and re-examine what survives.
Observe the exponential flattens. As the effective per-phase multiplier felt by the team $k_{eff} \to 1$ (automation neutralises the escalation), $c_{p} \to c_{0}$ for all $p$ . Late == early in cost. Why? $k^{p} \to 1^{p} = 1$ : the curve that used to soar becomes flat, so "where you catch the bug" stops mattering.
Read off the consequence. With no late penalty, there is no reason to lock decisions early and no penalty for changing constantly → push the loop length to its minimum. This is the theoretical limit Agile → continuous deployment heads toward. Why? When the reason for structure (late-change cost) vanishes, the optimal structure is the one with the shortest possible feedback loop.

Answer: In the limit $C \to 0$ , all four models' costs converge, and the optimum is the shortest loop — continuous deployment (Agile taken to its edge).

Verify: Numeric limit. Take $k_{eff} = 1 + ε$ and let $ε \to 0$ . Then $c_{4} / c_{0} = (1 + ε)^{4} \to 1$ . So the phase-4 penalty (normally $1 0^{4}$ ) collapses to $1$ : catching late costs the same as catching early. ✓

Ex 9 — Cell I: real-world word problem

Steps.

Extract coordinates from the words. "Legally frozen" ⇒ $R$ = frozen. "Contract amendment for change" ⇒ $C$ = high. "Audit trail" ⇒ traceability required. Why? Word problems hide the coordinates in prose; the skill is translating phrases into $R$ , $C$ , and constraints.
Map to a cell. Frozen + costly + traceability = Cell A territory (like Ex 1). Why? Recognising this is Cell A lets us reuse the reasoning instead of starting over.
Choose V-Model. Frozen requirements make sequential viable; the 240-requirement audit trail demands the requirement ⟷ acceptance-test pairing. Contract negotiation over collaboration is literally the opposite of Agile's value — Agile would fight the contract shape. Why? The contract's own structure (fixed scope, audit) matches the V-Model's structure; forcing Agile here fights the paperwork it's legally bound by.

Answer: V-Model.

Verify: Traceability count. V-Model produces one acceptance test per requirement ⇒ $240$ requirements map to $\geq 240$ acceptance tests, giving a complete audit matrix. Any requirement with $0$ paired tests would fail the audit; the pairing guarantees the count is $\geq 240 > 0$ . ✓

Ex 10 — Cell J: the exam twist (spot the trap)

Steps.

Read coordinates, ignore the buzzword. $R$ = frozen (regulator-locked), $C$ = catastrophic (aircraft). The team's self-description ("modern") is not a coordinate. Why? The trap injects an irrelevant variable (fashion). Always solve from $R$ and $C$ , never from vibes.
Test Agile against the axes. Agile's core benefit — cheap, frequent change — is (a) unusable (change is forbidden) and (b) actively dangerous (each change re-opens certification). Agile's "working software over documentation" clashes with mandatory certification docs. Why? A model is wrong when its central benefit is unusable and its central trade-off violates a hard constraint.
State the correct answer with the steel-man. The right model is V-Model (frozen + catastrophic + traceable, Cell A). The team's error is choosing by fashion, not by requirement-stability — exactly the mistake the parent note's steel-man warns against. Why? Naming the meta-mistake ("match the model to requirement-stability, not to fashion") is what an examiner is really testing.

Answer: The team is wrong; use the V-Model. Agile here is an anti-pattern.

Verify: Cost check. If an Agile mid-project change forces re-certification, and re-certification is a $p = 4$ -level event, its cost $\approx c_{0} \cdot k^{4} = 10000 c_{0}$ per change — and Agile invites many changes. The multiplied cost confirms Agile is disqualified. ✓

Recall Self-test (cover the answers)

Which cell has frozen requirements but cheap late change, and which model wins? ::: Cell C; lightweight Waterfall, chosen for lowest overhead (both risks are low). Why is Cell D (volatile + catastrophic) impossible to solve with a single pure model? ::: Volatility demands Agile's cheap change; catastrophe demands the V-Model's rigor — opposite pulls, so you blend (iterations behind a verification gate). At $R = 0$ (no requirements yet), why are Waterfall and V-Model undefined? ::: Their first phase needs a complete requirement set as input; an empty set gives the acceptance suite $0$ tests, collapsing the process. As late-change cost $C \to 0$ , what happens to the model choice? ::: The $k^{p}$ penalty flattens to $1$ , all models' costs converge, and the shortest loop (continuous deployment) wins. What's the exam trap in Ex 10? ::: Choosing by "modern = Agile" instead of by requirement-stability; frozen + catastrophic ⇒ V-Model.