SDLC — waterfall, V-model, iterative, agile: Exercises

Before we start, one symbol we will reuse. In the parent note Boehm's rule of thumb said the cost to fix a defect grows by a factor $k$ for every phase you delay:

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

Level 1 — Recognition

You should be able to name and match. No calculation.

L1.1 Match each SDLC model to its one-line signature: (a) "Locks everything early, feedback comes late." (b) "Waterfall bent into a shape, with a test phase paired to every design phase." (c) "Builds a crude version of the whole product, then re-loops to refine it." (d) "Never locks far ahead; re-plans every 1–4 weeks."

Options: Waterfall · V-Model · Iterative · Agile.

Recall Solution

(a) → Waterfall — the strict downhill flow, sign-off before the next phase.
(b) → V-Model — the left arm (decompose) mirrored by the right arm (test).
(c) → Iterative — each cycle returns a working, initially crude, whole.
(d) → Agile — short sprints, continuous customer feedback.

L1.2 In the V-Model, which test phase is paired with the Requirements phase?

Recall Solution

Acceptance testing. Requirements sit at the top-left of the V; its mirror at the top-right is acceptance testing, which asks "does it meet the user's real need?" — i.e. validation. See Software Testing — Unit Integration System Acceptance.

L1.3 Fill the blank with verification or validation: "Checking the product against the written specification is ______; checking it against the user's real need is ______."

Recall Solution

First blank = verification ("did we build the thing right?"). Second = validation ("did we build the right thing?"). You can perfectly verify something nobody wanted. See Verification and Validation.

Level 2 — Application

Apply a rule to a fresh scenario.

L2.1 A defect in a requirement is caught during testing instead of during requirements. Using $c_{p} = c_{0} k^{p}$ with $c_{0} = 1$ and $k = 10$ , how many times more expensive is this than catching it at requirements?

Recall Solution

Testing is phase 3 (requirements 0, design 1, coding 2, testing 3). So $c_{3} = 1 \cdot 1 0^{3} = 1000.$ Catching it at requirements costs $c_{0} = 1$ . Ratio $= 1000/1 = 1000 \times$ more expensive. Why this number: three phases were built on top of the wrong requirement (design, code, test), so three layers must be re-touched — three factors of ten.

L2.2 Your project's requirements change on average twice a month, and your customer sits in the same building and answers questions daily. Which model fits, and state the single deciding factor.

Recall Solution

Agile. The deciding factor is requirement volatility (plus a readily-available customer). Frequent change destroys any model that locks decisions early: waterfall would re-do locked phases at high $k^{p}$ cost each time. Agile never locks far ahead, so a new requirement just joins the next sprint's backlog at near- $1 \times$ cost. See Scrum.

L2.3 A team building certified pacemaker firmware must produce a full audit trail linking every requirement to the test that proves it. Which model, and why is its rigidity acceptable here?

Recall Solution

V-Model (or waterfall). Two reasons:

It builds traceability in by design — each requirement is paired with a named test phase, exactly the audit link regulators demand.
Its rigidity (hard to change mid-stream) is not a cost here because requirements are frozen by regulation anyway. When change is forbidden, the model that punishes change loses nothing. See Risk Management.

Level 3 — Analysis

Compare, diagnose, take apart an argument.

L3.1 Compute the cost of catching a requirements defect at each phase for $c_{0} = 1, k = 10$ , and explain in one sentence why the curve is exponential, not linear.

Recall Solution

Caught at	$p$	$c_{p} = 1 0^{p}$
Requirements	0	1
Design	1	10
Coding	2	100
Testing	3	1000
After release	4	10000

Why exponential: each phase builds new work on top of the previous, so a later fix forces you to re-touch every layer stacked above the bug. Stacking layers = multiplying by $k$ each time, and repeated multiplication is exponential growth, not additive (linear) growth. See Cost of Change Curve.

L3.2 A manager says: "Waterfall is just outdated and always worse than Agile." Steel-man the claim (why it sounds true), then refute it precisely.

Recall Solution

Why it sounds true: most real projects have volatile requirements, and for those Agile genuinely wins — its constant re-planning keeps change near $1 \times$ . Waterfall's early lock gets invalidated repeatedly, causing expensive $k^{p}$ rework. Empirically Agile wins most of the time, which feels like all of the time. Refutation: "always worse" is a claim about every case, and it is false at the extremes. When requirements are genuinely frozen and change is forbidden (medical certification, fixed-price government contract), Agile's re-planning overhead buys nothing (there is no change to absorb) while costing coordination tax and weaker up-front architecture and traceability. There Waterfall/V-Model is optimal. The correct rule is: match the model to requirement-stability, not to fashion.

L3.3 Diagnose the flaw: a team runs "iterations," but each iteration only produces design documents — no running software until the very end. Why is this not truly iterative, and what benefit did they lose?

Recall Solution

True iterative development requires each cycle to return a working (if crude) version of the whole product. Producing only documents means there is nothing to run, nothing to show users, nothing to measure — so defects are still discovered only at the end (phase ~3+), exactly like waterfall. Benefit lost: the whole point of iteration is to collapse the cost-of-change curve by catching a wrong design one iteration deep ( $\approx 1 \times$ ) instead of four phases deep ( $1 0^{4} \times$ ). Without running software, the curve is not collapsed at all. They got the ritual of iteration without its mechanism.

Level 4 — Synthesis

Build something new: a plan, a hybrid, a re-design.

L4.1 Design a hybrid: a bank must satisfy a regulator (audit trail, frozen compliance rules) and wants a modern, changeable customer-facing app. Propose a split and justify each half with the deciding factor.

Recall Solution

Split by requirement stability, applying the D-note's own 80/20 rule:

Compliance / core-ledger subsystem → V-Model. Rules are frozen by regulation and change is forbidden; the V-Model's requirement-to-test pairing is the audit trail. Rigidity costs nothing here.
Customer-facing app → Agile (Scrum). Requirements churn with the market; the customer/product owner is available; fast feedback wins. Re-plan every sprint so change stays near $1 \times$ . See Scrum.

Why a hybrid beats picking one: the deciding factor (how stable are the requirements?) has two different answers in the same project, so no single model is optimal for both halves. Match each subsystem to its own stability.

L4.2 You are told to "do the scariest, most uncertain part in iteration 1." Explain, using the cost equation, why front-loading risk is the smart ordering — and connect it to Risk Management.

Recall Solution

If the scary part turns out impossible or far harder than assumed, you want to learn that when the fewest layers are built on top of it — i.e. at small $p$ , where a fix costs $c_{0} k^{p}$ with $p$ near 0 (≈ $1 \times$ ). Discovering it in the last iteration means all other work already depends on it → large $p$ → up to $k^{4} = 10000 \times$ rework, plus the sunk cost of everything built on a false assumption. So front-loading risk maximises the chance that your most-expensive-to-fix uncertainty is caught at the cheapest possible phase. That is exactly the goal of Risk Management: resolve high-uncertainty items early, while options are still cheap.

Level 5 — Mastery

Defend a decision with numbers.

L5.1 Two plans deliver the same product.

Plan W (waterfall): one wrong requirement is guaranteed, caught at testing ( $p = 3$ ).
Plan A (agile): the same wrong requirement is caught one iteration deep ( $p = 1$ , treat "design-level"), but Agile adds a fixed re-planning overhead of 50 units across the project.

With $c_{0} = 1, k = 10$ , compute the defect-fix cost for each plan, add the overhead to Plan A, and state which plan is cheaper for this single defect.

Recall Solution

Plan W: $c_{3} = 1 \cdot 1 0^{3} = 1000$ units. Total $= 1000$ . Plan A: defect fix $c_{1} = 1 \cdot 1 0^{1} = 10$ units, plus overhead $50$ . Total $= 10 + 50 = 60$ units. Comparison: $60 < 1000$ , so Plan A is cheaper, by $1000 - 60 = 940$ units, even after paying the re-planning tax. Interpretation: Agile pays a tax (the 50-unit overhead) to buy cheap change. Here the tax (50) is tiny next to the $k^{p}$ blow-up it prevents ( $1000$ ). This is precisely why Agile wins when defects/changes are frequent.

L5.2 Find the break-even overhead $O$ : the value of the Agile re-planning tax at which Plan W and Plan A cost exactly the same (same setup as L5.1, one defect). Then state what it means for $O$ larger than break-even.

Recall Solution

Set Plan A total = Plan W total: $c_{1} + O = c_{3} \Rightarrow 10 + O = 1000 \Rightarrow O = 990.$ Break-even overhead $= 990$ units (per defect prevented from reaching testing). Meaning: as long as Agile's re-planning tax stays below 990 units, catching this defect early is the cheaper choice. If the overhead exceeded 990 (e.g. a tiny project with only one rare defect but heavy ceremony), the tax would outweigh the saving and the rigid plan would win — the honest failure mode of over-applying Agile to a small, stable project.

Recall Self-check: the one sentence that unlocks the whole chapter

Every SDLC model is a different answer to :::- "When do we lock decisions, and when do we get feedback?" — and the right answer depends on how stable the requirements are and how costly late change is.