SDLC — waterfall, V-model, iterative, agile: Question bank

Recall What the four models each decide differently

The single question every model answers ::: "When do we lock decisions, and when do we get feedback?" — Waterfall locks early/feedback late; V-model adds a test twin per design step; iterative re-loops on a running whole; agile locks almost nothing and gets feedback constantly.

First, two pictures the whole page leans on

True or false — justify

Recall Each item is TRUE or FALSE — give the reason, never a bare verdict.

"Waterfall is always the wrong choice in modern software." ::: False. Waterfall is optimal when requirements are genuinely frozen and change is forbidden or regulated (medical-device certification, fixed-price contracts). The failure is using it on volatile requirements, not the model itself. See Requirements Engineering. "The V-model is a completely different philosophy from waterfall." ::: False. The V-model is waterfall bent into a V — same linear left arm — with the single addition of a paired test phase for every design phase. It inherits waterfall's rigidity to change. "In the V-model, testing only starts after all coding is finished." ::: False. The test running happens on the way up, but each test is designed on the way down, at the same moment its paired development phase is written. Designing the test early is the whole point. See Verification and Validation. "Agile means there is no documentation and no planning." ::: False. The Manifesto says prefer working software when forced to trade off — not abolish docs. Agile still does sprint planning, backlog grooming, and just-enough documentation. Skipping all design is "cowboy coding" mislabelled. "Iterative and incremental are the same word for the same thing." ::: False. Iterative refines the whole each loop (redo it better); incremental adds new pieces each loop — the two axes of Figure 2. Real projects blend both, but they are distinct. "Because a defect costs about $10 \times$ more per phase, the cost curve is a straight line." ::: False. Multiplying by $k \approx 10$ every phase gives $c_{p} \approx c_{0} k^{p}$ — an exponential curve (the wall in Figure 1), not linear. Each phase stacks new dependencies on the bug. See Cost of Change Curve. "In pure waterfall you can return to an earlier phase whenever you notice a mistake." ::: False. Pure waterfall flows strictly downhill with sign-off gates; going back is exactly what it forbids. That rigidity is why late-found defects are so expensive there. "Every agile team practises Scrum." ::: False. Agile is a family of methods sharing the Manifesto. Scrum, Kanban, and Extreme Programming are all agile but differ (Scrum uses fixed sprints; Kanban uses continuous flow with no fixed iteration). "You can perfectly verify a product and still have built the wrong thing." ::: True. Verification checks against the spec; validation checks against the user's real need. A flawless build of an unwanted feature passes verification but fails validation. "The Spiral model is just another name for waterfall." ::: False. The Spiral model is risk-driven iterative — each loop of the spiral does a mini requirements-design-build-evaluate cycle and explicitly assesses risk before committing to the next loop. It's closer to iterative than waterfall. See Risk Management. "CI/CD and DevOps are alternatives to agile that replace it." ::: False. CI/CD (continuous integration / continuous delivery) and DevOps are engineering practices that make agile's short feedback loops actually shippable — they automate build, test and deploy so an increment can go live in minutes. They complement agile, they don't replace the SDLC model.

Spot the error

Recall Each statement contains a mistake — name it and correct it.

"The V-model pairs Requirements with Unit testing." ::: Wrong pairing. Requirements pairs with Acceptance testing (does it meet the user's need?). Unit testing pairs with the lowest level — module/detailed design. The pairings mirror the two arms level-by-level. See Software Testing — Unit Integration System Acceptance. "Agile reduces the cost of late change by finding defects faster with a $k^{4}$ multiplier." ::: Wrong mechanism. Agile doesn't speed up a $k^{4}$ discovery — it never lets a defect reach phase 4. A changed requirement enters the next sprint's backlog at near- $1 \times$ (i.e. $c_{0}$ ), so the exponent $p$ stays small. "Iterative development tackles the easiest part first so the team builds momentum." ::: Backwards. Iterative tackles the scariest, most uncertain part first, so if it's impossible you learn cheaply in iteration 1 — that's risk-driven ordering, exactly what the Spiral model formalises. See Risk Management. "'Working software over comprehensive documentation' means documentation has no value." ::: Misreading. The right side still has value; the left has more when you must trade off. It's a priority ordering, not an abolition. "Waterfall shines because it gives you feedback early." ::: False premise. Waterfall gives feedback late (only after testing). It shines when requirements are stable enough that you don't need early feedback, not because it provides it. "Verification asks 'did we build the right thing?'" ::: Swapped. Verification = "did we build the thing right?" (against spec). Validation = "did we build the valid thing?" (against user need). The mnemonic: veRIfication → RIght/spec.

Why questions

Recall These test whether you can

explain, not just recall. Why is the cost-of-change curve exponential rather than linear? ::: Because each later phase builds new layers (design, code, tests, docs, user habits) on top of the defect. Fixing it means re-touching every stacked layer — multiplying by $k$ each phase gives $c_{0} k^{p}$ , an exponential (Figure 1). Why does the V-model force requirements to be testable? ::: Because you must design the acceptance test at the moment you write the requirement. A vague wish like "must be fast" immediately triggers "how would I test 'fast'?", exposing untestable requirements early. Why does agile pay a "tax" and what does it buy? ::: The tax is constant re-planning overhead and less up-front architecture. It buys cheap change: because nothing is locked far ahead, a new requirement costs about $c_{0}$ ( $1 \times$ ) instead of $c_{0} k^{4}$ . Why split the SDLC into phases at all? ::: Humans can't hold "everything" in mind at once. Phases are separation of concerns in time — one kind of thinking (what, then how, then build, then check) per stage. Why is showing users a running build early the key move in iterative development? ::: It collapses the cost-of-change curve: a wrong design is caught one iteration deep instead of four phases deep, turning "hope it's right on paper" into "measure it running." Why can't you meaningfully budget an agile project the way you budget a waterfall one? ::: Waterfall fixes scope up front, so cost/time follow. Agile keeps scope open and re-plans each sprint, so its strength (embracing change) is exactly what makes fixed scope-and-budget hard to promise. Why does the Spiral model put a risk-assessment step in every loop? ::: Because its whole premise is "do the riskiest thing next, cheaply." Evaluating risk before each loop lets you kill or re-scope a doomed idea after one small spiral instead of after a full waterfall. See Risk Management.

Edge cases

Recall The degenerate and boundary scenarios the models rarely advertise.

What happens to waterfall if requirements turn out to be volatile after sign-off? ::: Its early lock is repeatedly invalidated, forcing expensive rework at $c_{0} k^{4}$ cost — this is exactly the mismatch it's famous for. The fix is choosing a different model, not blaming the requirements. If an iterative project only ever runs ONE iteration, what is it? ::: Effectively waterfall — the "re-loop" that defines iterative never happens, so you lose the early feedback that justifies the model. Can a project be agile with a zero-length or missing customer feedback loop? ::: No — continuous customer collaboration is load-bearing. Remove the available customer and sprints deliver increments no one validates, collapsing agile into fast waterfall. What model fits a safety-critical firmware project where every requirement must be traceable to a test? ::: The V-model — its level-by-level design↔test pairings give exactly the traceability and up-front test design that certification demands. A team calls itself "agile" but skips all design and documentation — what is this really? ::: "Cowboy coding" wearing an agile label — the #1 abuse. Agile still plans and documents just enough; abolishing both is not a valid trade-off it endorses. Where does coding sit on the V, and does it have a testing twin? ::: Coding sits at the vertex (turning point from decomposition to integration). Its natural twin is unit testing — many V-model drawings pair unit tests directly with coding, while stricter versions pair unit tests with detailed design. Both readings are used; the key idea is unchanged: the lowest development activity is checked by the lowest test level, at the bottom of the V. Does DevOps / CI/CD change which SDLC model you pick? ::: Not directly — it's an automation layer that makes short iterations shippable. But by making deploy near-free it strongly favours iterative/agile models, since their whole payoff is frequent releases. Where does the Spiral model sit relative to the four classic models? ::: It's an iterative model with an extra explicit risk-analysis quadrant per loop — think "iterative, but every loop asks 'what's the biggest risk, and is it still worth continuing?'" before spending more.