Software Development Life Cycle
A model is just a way of saying "here is the order in which we'll think about the work." Pick the one that matches how often your requirements change and how often you can afford to ship.
Why we model the build process
Software is invisible. Without a shared model of who does what next, work fragments: someone writes code while no one has agreed on the requirements, QA tests features that are about to be redesigned, ops gets handed a deploy at 7 pm on a Friday. A lifecycle is a contract about the order of activities — requirements → design → build → test → deploy → operate — and about which of those steps happen once versus continuously.
The classical models
Waterfall runs each phase to completion before the next begins. It only works when requirements are truly fixed and the cost of late discovery is acceptable. Real-world domains where it fits: regulated medical devices, embedded firmware, hardware co-development.
V-model is Waterfall folded in half — each build phase has a matching verification phase. Unit tests verify implementation; integration tests verify design; acceptance tests verify requirements.
Iterative & Incremental models break the system into slices and repeat the cycle (requirements → ship) per slice. Each iteration produces working, demonstrable software. Risk drops because problems surface during integration of slice 2, not at the final big-bang test six months in.
Spiral wraps iterations in a risk-assessment loop. Each spin asks: what is most likely to kill the project right now? Whatever it is, the next iteration attacks that risk first. Useful for greenfield systems where no two people agree on what "successful" looks like.
Agile (XP, Scrum, Kanban) takes iterative to its limit: small slices, short cycles, continuous customer feedback. It assumes requirements will change and structures the work to absorb that.
How to choose
The decision turns on two variables: requirement volatility (how often will the spec change?) and release cadence (how often can we ship?).
- Fixed requirements + slow release → Waterfall or V.
- Fixed requirements + fast release → V with CI.
- Volatile requirements + slow release → Iterative (every 6–8 weeks).
- Volatile requirements + fast release → Agile + CD.
"Plans are worthless, but planning is everything." A lifecycle is the planning, not the plan. Don't confuse the diagram with the discipline.
What to remember at exam time
- Name the phases in order: requirements, design, implementation, verification, deployment, maintenance.
- Be able to draw the V-model and label which test maps to which phase.
- Justify a choice of model against the two variables above. "Agile because…" is not enough; you need which volatility and which cadence.
- Don't confuse SDLC (the abstract order of activities) with Scrum (one concrete way of running an iterative SDLC).