A
AiTechWorlds
AiTechWorlds
In 1931, engineers finished the George Washington Bridge connecting New York and New Jersey. Every rivet, cable, and anchorage was specified before a single piece of steel was ordered. Changes mid-construction would have been catastrophically expensive — concrete does not undo itself.
In 2011, Instagram shipped version 1.0 of their iPhone app. They had not yet decided whether to include Android support. Their requirements changed weekly. Their architecture evolved in real time. Treating the app like a bridge — locking down every requirement before writing the first line — would have killed the product before it launched.
The question every software team faces: how much planning before you start, and how much can change once you have started? SDLC models are the answer — each represents a different bet on that question.
A Software Development Life Cycle (SDLC) model is a framework that prescribes:
Choosing the wrong model for your context is not a minor inconvenience. The Standish Group's CHAOS Report found that 45% of software features are never used — a failure that often traces back to waterfall-style lock-in of requirements that no one validated with real users.
Winston Royce described the waterfall model in his 1970 paper — and almost immediately warned that it was risky. His warning was largely ignored for two decades.
How it works: Each phase completes fully before the next begins. Requirements are frozen before design starts. Design is frozen before coding starts. Testing only begins after all coding is done.
Strengths:
Best for: Government contracts, defence systems, medical device firmware — domains where requirements are regulated, changes are expensive, and documentation is mandatory.
The critical problem: Research consistently shows that 45% of software projects discover wrong requirements during implementation — after requirements were "frozen." In waterfall, fixing a wrong requirement at the coding phase costs 10× more than fixing it at the requirements phase. At the maintenance phase, the multiplier is 100×.
The V-Model extends waterfall by pairing each development phase with a corresponding testing phase. It answers the question: "When do we plan our tests?"
Key insight: Acceptance tests are planned from requirements, before implementation begins. This means testers know what to test before developers write a single line.
Best for: Safety-critical systems (automotive, aerospace, medical) where traceability between requirements and tests is a regulatory requirement.
Barry Boehm's Spiral Model made risk management the central organising principle. Instead of one long waterfall, you make multiple passes through four quadrants — each pass called a spiral.
Key insight: Every iteration begins by explicitly identifying the highest-risk unknowns and addressing them before building. Early spirals produce prototypes; later spirals produce the real system.
Best for: Large, high-risk projects where requirements evolve over years — government defence systems, space mission software, enterprise platforms.
Weakness: Requires sophisticated risk expertise. Overkill for small teams.
In February 2001, 17 software practitioners met at a ski resort in Utah. Frustrated with the heavy documentation and planning of waterfall methods, they published the Agile Manifesto — four values and twelve principles.
The four core values:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Agile does not prescribe specific ceremonies — it is a philosophy. Scrum and Kanban are specific implementations of Agile values (covered in the next lesson).
Key principles relevant to delivery:
RAD, popularised in the 1990s, is prototype-heavy: build a rough working version fast, show it to users, refine it, repeat. Formal design is minimal.
Best for: Applications with fuzzy requirements where user feedback will shape the product — internal business tools, early-stage consumer apps.
Weakness: Can produce poor architecture when the prototype becomes the production system without proper refactoring.
| Model | Key Idea | Best For | Team Size | Change Tolerance | Documentation |
|---|---|---|---|---|---|
| Waterfall | Sequential phases, freeze requirements | Fixed, regulated requirements | Any | Very low | Very heavy |
| V-Model | Test planning mirrors development phases | Safety-critical, regulated | Medium–Large | Very low | Heavy |
| Spiral | Risk-driven iteration | Large, high-risk, long-horizon | Large | Medium | Medium–Heavy |
| Agile (Scrum) | Iterative delivery, embrace change | Evolving requirements, product work | 5–15 | Very high | Light |
| Kanban | Continuous flow, limit WIP | Operational/support work | Any | Very high | Minimal |
| RAD | Prototype → refine → deliver | Fuzzy requirements, user-driven | Small–Medium | High | Light |
The right model depends on three factors:
1. Requirements stability
2. Risk level
3. Customer involvement
In practice, most modern product companies use Agile. Waterfall survives in government contracting, embedded systems, and regulated industries. Spiral appears in defence and space. The industry has decisively moved toward iterative delivery for everything else.
Get this course's notes on Telegram!
Free cheat sheets, summaries & practice exercises