Part 2: Classical SDLC Models — Waterfall, V-Model, Spiral & More

Introduction — The Software Crisis

In 1968, NATO convened a conference in Garmisch, Germany to address a growing problem: software projects were failing at alarming rates. Budgets exploded, deadlines slipped by years, and delivered systems routinely didn't work as intended. The attendees gave this phenomenon a name — the "software crisis".

The problem wasn't bad programmers. The problem was that software had grown from small utility programs into massive systems — air traffic control, banking networks, military command systems — without any corresponding evolution in how those systems were planned, built, and delivered. Hardware engineers had blueprints, manufacturing processes, and quality standards. Software engineers had… improvisation.

The response to this crisis was the birth of Software Development Lifecycle (SDLC) models — structured frameworks that defined the stages software should pass through from conception to retirement. Each model represented a different philosophy about how to manage complexity, risk, and change.

Why Understanding These Models Matters Today

You might think: "We're Agile now, why study Waterfall?" Three reasons:

1. Context — Agile was a reaction against these models. You can't understand the reaction without understanding what it was reacting to.
2. Regulated industries — Healthcare, aerospace, defence, nuclear, and financial systems still mandate structured lifecycle documentation. If you work in these sectors, you'll use variants of these models.
3. Hybrid reality — Most real-world teams use a hybrid. Understanding the pure forms lets you recognise the tradeoffs in your own process.

The Waterfall Model

The Waterfall model is the granddaddy of all SDLC models and perhaps the most misunderstood. It was first formally described by Winston Royce in his 1970 paper "Managing the Development of Large Software Systems" — though, ironically, Royce presented it as an example of a flawed process that needed feedback loops.

Despite Royce's warnings, the industry latched onto the sequential diagram and adopted it wholesale. The US Department of Defence codified it in DOD-STD-2167 (1985), making it the mandatory standard for defence contracts for decades.

The Five Stages

flowchart TD
    A[Requirements Analysis] --> B[System Design]
    B --> C[Implementation / Coding]
    C --> D[Verification / Testing]
    D --> E[Deployment & Maintenance]

    style A fill:#132440,color:#fff
    style B fill:#16476A,color:#fff
    style C fill:#3B9797,color:#fff
    style D fill:#16476A,color:#fff
    style E fill:#132440,color:#fff
                            

Strengths and Weaknesses

Strengths:

• Simplicity — Easy to understand and manage. Each phase has clear entry/exit criteria.
• Documentation — Produces comprehensive documentation at every stage, critical for regulated industries.
• Milestone clarity — Progress is easy to measure: "We're in Phase 3" tells everyone exactly where the project stands.
• Works for stable requirements — When requirements truly don't change (missile firmware, regulatory compliance systems), sequential works fine.

Weaknesses:

• No feedback until late — Users don't see working software until after the Verification phase. By then, fixing requirements errors is catastrophically expensive.
• Assumes perfect knowledge — The model assumes you can fully specify requirements upfront. For most software, this is fiction.
• Late testing — Defects found during Verification may require redesign, creating costly rework loops the model doesn't account for.
• Change resistance — Any requirement change after Phase 1 triggers cascading updates through Design, Implementation, and Testing.

When Waterfall Still Makes Sense

• Defence contracts — Fixed requirements from government RFPs; extensive documentation required for audits
• Embedded systems with hardware dependencies — When the software interfaces with physical hardware that cannot be changed after manufacturing
• Regulatory compliance projects — SOX compliance, HIPAA implementations where requirements are defined by law
• Migration/replacement projects — Replacing System A with System B where all requirements are inherited from the existing system

The V-Model (Verification & Validation)

The V-Model emerged in the late 1980s as an extension of Waterfall that addressed one of its critical flaws: late testing. Instead of treating testing as a single phase after implementation, the V-Model maps every development phase to a corresponding testing phase, creating a "V" shape where the left side represents development and the right side represents validation.

The V Shape — Development Mirrors Testing

The key insight of the V-Model is that test planning begins at the same time as the corresponding development activity. When you write requirements, you simultaneously write acceptance test criteria. When you design architecture, you plan system tests. This eliminates the "Oh no, how do we test this?" surprise at the end.

flowchart LR
    subgraph Development ["Development (Left Side)"]
        direction TB
        R[Requirements Analysis] --> AD[Architecture Design]
        AD --> DD[Detailed Design]
        DD --> C[Coding]
    end

    subgraph Testing ["Testing (Right Side)"]
        direction TB
        UT[Unit Testing] --> IT[Integration Testing]
        IT --> ST[System Testing]
        ST --> AT[Acceptance Testing]
    end

    R -.->|"Validates"| AT
    AD -.->|"Validates"| ST
    DD -.->|"Validates"| IT
    C -.->|"Validates"| UT
                            

Strengths:

• Early test planning — Test cases are written alongside development, catching ambiguities early
• Traceability — Every requirement links to a test. Nothing is untested.
• Higher quality — Defects caught at the right abstraction level (integration bugs in integration testing, not acceptance testing)

Weaknesses:

• Still sequential — You can't go back and change requirements without cascading through both sides of the V
• Rigid — Like Waterfall, it assumes stable requirements
• No working software until coding is complete — Stakeholders still wait until the right side of the V to see anything

The V-Model dominates in industries like automotive (ISO 26262), medical devices (IEC 62304), and avionics (DO-178C) where traceability between requirements and test evidence is legally mandated.

The Sashimi Model (Overlapping Waterfall)

Named after the Japanese presentation of sliced fish where each piece slightly overlaps the next, the Sashimi Model (also called the "Waterfall with Overlapping Phases" model) was described by Peter DeGrace in 1990. It acknowledges that in practice, phases don't have clean boundaries — design starts before requirements are fully finalised, coding begins before design is complete, and testing starts before all code is written.

Think of it as pragmatic Waterfall. Instead of strict phase gates, phases overlap by 10-30%, allowing:

• Early feedback — Designers can flag requirement ambiguities while requirements are still being finalised
• Parallelism — Teams aren't idle waiting for the previous phase to complete
• Smoother knowledge transfer — The handoff between phases is gradual, not abrupt

When it's useful:

• Teams in regulated industries who want some flexibility without fully abandoning sequential governance
• Projects with mostly-stable requirements but a few areas of uncertainty
• Organisations transitioning from strict Waterfall toward more iterative approaches

Risks:

• Overlap boundaries become ambiguous — when does "requirements" end and "design" begin?
• Milestone tracking becomes harder since phases don't have clean start/end dates
• Can degenerate into uncontrolled scope creep if overlap isn't managed

The Incremental Model

The Incremental Model delivers the system in a series of increments, each of which adds new functionality to the previous delivery. Think of it as building a house room by room — each room is fully complete and usable when delivered, and you keep adding rooms until the house is finished.

The key characteristic is that each increment is a fully functional subset of the final system. Users can start using the system after the first increment, even though it doesn't have all features yet.

Example: E-Commerce Platform Built Incrementally

Strengths:

• Early value delivery — Users get working software from Increment 1, not after 10 months
• Reduced risk — Each increment is smaller and therefore easier to estimate, develop, and test
• Prioritisation — Highest-value features are delivered first; lower-priority features can be cut if budget runs out
• Feedback incorporation — User feedback from Increment 1 can influence Increment 3's design

Weaknesses:

• Architecture must support extension — The initial architecture must accommodate future increments without major refactoring
• Integration complexity — Each increment must integrate cleanly with previous ones
• Total cost may be higher — The overhead of multiple deliveries (testing, deployment, documentation updates) adds up

The Iterative Model

The Iterative Model builds the entire system in rough form first, then refines it through successive iterations. Each iteration passes through all development phases (requirements, design, code, test) but produces a progressively more complete and polished version of the whole system.

The crucial difference from incremental: in the iterative model, you have a complete but rough version of the whole system early on. In the incremental model, you have a polished but partial version early on.

The Mona Lisa Analogy

This is the most intuitive way to understand the distinction:

Strengths of Iterative:

• Handles uncertainty — Perfect when you don't fully understand the requirements upfront
• Architecture validation — Technical risks are surfaced early because you build the whole skeleton first
• User feedback on the whole — Users can react to the complete system concept, not just isolated features

Weaknesses of Iterative:

• Requires disciplined scope management — Without clear iteration goals, refinement can go on forever
• Early versions may disappoint users — A rough prototype can undermine confidence if stakeholders expect polished output
• Architecture changes between iterations are costly — If the skeleton was wrong, rebuilding it affects everything

The Spiral Model

Proposed by Barry Boehm in 1986, the Spiral Model is fundamentally risk-driven. Unlike other models that are driven by phases or features, the Spiral Model's core question at every loop is: "What is the biggest risk right now, and how do we mitigate it?"

The model is represented as a spiral starting from the centre and working outward. Each loop through the spiral represents one iteration of the project, and each loop passes through four quadrants:

The Four Quadrants

flowchart TD
    A["1. Determine Objectives\n(Requirements, constraints,\nalternatives)"] --> B["2. Identify & Resolve Risks\n(Risk analysis, prototyping,\nsimulation)"]
    B --> C["3. Develop & Test\n(Design, code, test,\nintegrate)"]
    C --> D["4. Plan Next Iteration\n(Review, commitment,\npartitioning)"]
    D --> A

    style A fill:#132440,color:#fff
    style B fill:#BF092F,color:#fff
    style C fill:#3B9797,color:#fff
    style D fill:#16476A,color:#fff
                            

Key characteristics:

• Each loop increases in scope and detail — Loop 1 might be a feasibility study, Loop 2 a prototype, Loop 3 an MVP, Loop 4 the production system
• Risk analysis is mandatory every loop — If risk analysis reveals a "show-stopper", the project can be cancelled early with minimal loss
• Meta-model quality — Quadrant 3 can use any other model for its development. You might use Waterfall within one loop and iterative within another

Strengths:

• Excellent risk management — Risks are identified and mitigated before they become expensive problems
• Flexible — Can incorporate elements of any other model within its loops
• Kill-switch built in — At the end of each loop, stakeholders can decide to stop if risk/reward isn't favourable
• Progressive commitment — Investment increases only as confidence increases

Weaknesses:

• Complex to manage — Requires experienced project managers who understand risk modelling
• Expensive — Risk analysis, prototyping, and formal reviews add overhead
• Not suitable for small projects — The overhead isn't justified for a 3-person, 3-month project
• Risk assessment requires expertise — If risks are misidentified, the entire model breaks down

The Unified Process (RUP)

The Rational Unified Process (RUP), developed by Rational Software (later acquired by IBM) in the late 1990s, attempted to combine the best of all previous models into a comprehensive, configurable framework. It is both iterative and incremental, organised into four sequential phases with multiple iterations within each.

The Four Phases

Key characteristics:

• Iterative within each phase — Elaboration might have 2-3 iterations; Construction might have 4-6
• Architecture-centric — The architecture is validated in Elaboration before Construction begins at scale
• Use-case driven — Requirements are captured as use cases; development is prioritised by critical use cases
• Risk-focused — Like Spiral, highest risks are tackled earliest (in Inception and Elaboration)

Strengths:

• Combines iterative benefits with structured phase gates
• Architecture is proven before major investment in Construction
• Well-documented with extensive tooling support (IBM Rational tools)

Weaknesses:

• Heavyweight — extensive documentation and ceremony
• Expensive tooling and training costs
• Often over-applied (using the full RUP for small projects is like using a crane to hang a picture)

Comprehensive Model Comparison

The following table compares all seven models across the dimensions that matter most when choosing an approach:

How to Choose a Model — Decision Framework

Choosing an SDLC model isn't about fashion or preference — it's about matching the model's characteristics to your project's constraints. Here's a decision framework:

flowchart TD
    A{"Are requirements\nwell-understood\nand stable?"} -->|Yes| B{"Is regulatory\ndocumentation\nmandated?"}
    A -->|No| C{"Is the project\nhigh-risk or\nlarge-budget?"}

    B -->|Yes| D{"Is traceability\nbetween requirements\nand tests required?"}
    B -->|No| E["Incremental Model"]

    D -->|Yes| F["V-Model"]
    D -->|No| G["Waterfall"]

    C -->|Yes| H["Spiral Model"]
    C -->|No| I{"Do you need\nearly working\nsoftware?"}

    I -->|Yes| J{"Are features\nwell-defined\nin priority order?"}
    I -->|No| K["Iterative Model"]

    J -->|Yes| L["Incremental Model"]
    J -->|No| M["Iterative Model"]

    style F fill:#3B9797,color:#fff
    style G fill:#132440,color:#fff
    style H fill:#BF092F,color:#fff
    style E fill:#3B9797,color:#fff
    style K fill:#16476A,color:#fff
    style L fill:#3B9797,color:#fff
    style M fill:#16476A,color:#fff
                            

Decision Factors to Consider

1. Requirements stability — How likely are requirements to change? Higher volatility → more iterative models.
2. Risk level — Is this a novel system with unknown technical risks? → Spiral or Iterative.
3. Regulatory requirements — Must you produce traceability matrices, test evidence, design rationale? → V-Model or Waterfall.
4. Time to first delivery — Do stakeholders need working software quickly? → Incremental or Iterative.
5. Team experience — Is the team experienced with the domain and technology? Less experience → more structure.
6. Project size — Spiral and RUP overhead is only justified for large projects (>20 developers, >12 months).
7. Budget certainty — Fixed-price contracts favour Waterfall/V-Model; time-and-materials favour iterative approaches.

Exercises

Conclusion & Next Steps

Classical SDLC models represent humanity's first systematic attempts to bring engineering rigour to software development. Each model was a response to the failures of its predecessor:

• Waterfall brought order to chaos but was too rigid
• V-Model fixed the testing gap but remained sequential
• Sashimi added practical flexibility to Waterfall
• Incremental delivered value earlier but needed stable requirements
• Iterative handled uncertainty but needed discipline
• Spiral managed risk brilliantly but was complex and expensive
• RUP combined everything but was often too heavyweight

The common thread across this evolution is the increasing ability to handle change and provide faster feedback. Each model relaxed one more constraint of its predecessor, trading documentation and predictability for adaptability and speed.

But even the most flexible classical model — the Spiral — was designed for large teams with formal processes. By the late 1990s, a group of practitioners felt that software development needed something fundamentally different: a philosophy that embraced change rather than merely tolerating it.