Beyond the Straight Line

Waterfall and the V-Model share a fundamental assumption: you can define everything upfront and execute in a single pass. In practice, this assumption fails for most software projects. Requirements change. Users provide feedback that invalidates assumptions. Technology evolves. Competitors release features that shift priorities.

Iterative and incremental development models address this reality by breaking the project into smaller cycles, each of which produces working software that can be tested, demonstrated, and refined.

Iterative Development: Refine Through Repetition

Iterative development builds the entire product in rough form first, then refines it through repeated cycles. Each iteration produces a more complete and polished version of the whole system.

Think of a sculptor: they do not carve the left arm perfectly, then the right arm, then the head. They rough out the entire figure first, then add detail in successive passes. Each pass refines the entire sculpture.

How It Works

  1. Iteration 1: Build a basic version of the whole system — rough UI, core logic, minimal data handling
  2. Iteration 2: Refine the UI based on feedback, improve the logic, add error handling
  3. Iteration 3: Polish the UI, optimize performance, add edge case handling
  4. Iteration N: Final refinements until quality meets acceptance criteria

Each iteration includes all SDLC activities: planning, design, coding, testing, and review. The product evolves through each cycle.

graph LR I1[Iteration 1
Rough prototype] --> I2[Iteration 2
Refined version] I2 --> I3[Iteration 3
Polished version] I3 --> I4[Iteration N
Release-ready] I1 -.->|Feedback| I2 I2 -.->|Feedback| I3 I3 -.->|Feedback| I4 style I1 fill:#fca5a5 style I2 fill:#fcd34d style I3 fill:#86efac style I4 fill:#22c55e,color:#fff

Testing in Iterative Development

Testing happens in every iteration:

  • Iteration 1: Test the basic functionality — does the core flow work at all?
  • Iteration 2: Test the refinements — do the improvements work without breaking existing features?
  • Iteration 3: Test quality attributes — performance, security, usability
  • Every iteration: Regression testing to ensure previous functionality still works

The key benefit: defects are found within days or weeks, not months. When iteration 2 breaks something from iteration 1, the team fixes it immediately while the context is fresh.

Incremental Development: Build Piece by Piece

Incremental development builds the product in distinct pieces (increments), each of which adds new functionality. Unlike iterative development, each increment is meant to be complete and production-ready.

Think of building a house room by room: first the kitchen (fully finished, usable), then the bedroom, then the bathroom. Each room is complete when delivered.

How It Works

  1. Increment 1: Build and fully test the user registration and login module
  2. Increment 2: Build and fully test the product catalog and search
  3. Increment 3: Build and fully test the shopping cart and checkout
  4. Increment 4: Build and fully test the payment processing

Each increment produces a working, tested piece of software that adds value to the overall system.

graph LR Inc1[Increment 1
Login Module] --> Inc2[Increment 2
+ Product Catalog] Inc2 --> Inc3[Increment 3
+ Shopping Cart] Inc3 --> Inc4[Increment 4
+ Payments] style Inc1 fill:#3b82f6,color:#fff style Inc2 fill:#6366f1,color:#fff style Inc3 fill:#8b5cf6,color:#fff style Inc4 fill:#a855f7,color:#fff

Testing in Incremental Development

Each increment is tested thoroughly before moving to the next:

  • Increment testing: Full testing of the new increment — unit, integration, system
  • Integration testing: Verify the new increment works correctly with all previous increments
  • Regression testing: Ensure previous increments still work after the new one is added

The key benefit: each increment is stable before the next begins. If increment 3 (shopping cart) breaks increment 1 (login), the issue is caught immediately through integration testing.

Iterative + Incremental: The Combination

In practice, most modern development combines both approaches:

  • The product is built incrementally (feature by feature)
  • Each feature is refined iteratively (multiple passes within each increment)

This is exactly what Agile methodologies (Scrum, Kanban) do: each sprint delivers a working increment that has been iteratively refined during the sprint.

The Spiral Model

The Spiral Model, proposed by Barry Boehm in 1986, is a specific iterative model that adds explicit risk analysis to each cycle. It is important historically because it influenced all subsequent iterative approaches.

Each spiral cycle has four quadrants:

  1. Determine objectives: What are we trying to achieve in this cycle?
  2. Identify and resolve risks: What could go wrong? How do we mitigate?
  3. Develop and test: Build and verify the solution
  4. Plan next iteration: What did we learn? What comes next?
graph TD O[1. Determine
Objectives] --> R[2. Identify and
Resolve Risks] R --> D[3. Develop
and Test] D --> P[4. Plan Next
Iteration] P --> O style O fill:#3b82f6,color:#fff style R fill:#ef4444,color:#fff style D fill:#22c55e,color:#fff style P fill:#f59e0b,color:#fff

The Spiral Model’s key contribution: risk-driven development. The riskiest elements are built and tested first. If a critical technology choice is risky, the first spiral cycle builds a prototype to validate it before investing in full development.

Prototyping

Prototyping is an iterative technique used within any development model:

Throwaway prototyping: Build a quick, rough version to validate an idea, then discard it and build the real system. The prototype is not production code — it is a learning tool.

Evolutionary prototyping: Build a prototype and continuously refine it until it becomes the final product. The prototype evolves into production code.

For testing, prototyping is valuable because:

  • Users can provide feedback on a working prototype before full development
  • Technical risks can be validated early (can this database handle the expected load?)
  • The team learns about the problem domain by building and testing early

Comparison with Waterfall

AspectWaterfallIterative/Incremental
FeedbackAt the endAfter every iteration/increment
Working softwareLateEarly and continuously
RiskHigh (late discovery)Lower (early discovery)
Change handlingDifficult and expensiveExpected and manageable
TestingOne phase at the endContinuous throughout
Defect costHigh (found late)Lower (found early)
DocumentationComprehensive upfrontEvolving, lighter
Customer involvementBeginning and endThroughout
Best forStable requirementsEvolving requirements

Exercise: Choose the Right Approach

For each scenario, determine whether iterative, incremental, or Waterfall would be most appropriate, and explain your reasoning:

  1. A medical device company is building software for an insulin pump. The FDA requires complete documentation, traceability, and formal verification before the device can be approved.

  2. A startup is building a social media app for pet owners. They have funding for 6 months and need to find product-market fit quickly.

  3. A bank needs to replace its 20-year-old core banking system with a modern platform. The existing system processes $2 billion in transactions daily and cannot go offline.

  4. A game studio is developing a mobile puzzle game. They want to test different game mechanics with users to find the most engaging design.

HintConsider: How stable are the requirements? How critical is the system? How much feedback is needed? What are the regulatory constraints?
Solution
  1. Waterfall (or V-Model) — Medical device software requires extensive documentation, traceability from requirements to tests, and formal verification. Regulatory approval (FDA 510(k) or PMA) requires complete, auditable documentation. Iterative approaches make compliance documentation harder to maintain.

  2. Iterative — The startup does not know exactly what users want. They need to build, test with real users, learn, and refine quickly. An iterative approach (Agile/Scrum) allows them to validate assumptions every 2 weeks and pivot if needed.

  3. Incremental — Replacing a core banking system cannot happen all at once (big-bang risk). An incremental approach migrates one module at a time: first savings accounts, then checking accounts, then loans. Each increment is fully tested and integrated before the next begins. This minimizes risk to the $2B daily transaction volume.

  4. Iterative — Game mechanics need to be prototyped, tested with users, and refined based on engagement metrics. The team should build rough versions of different mechanics, test them, and iterate on the most promising ones.

Pro Tips

Tip 1: Regression testing is the price of iteration. Every time you change something in an iteration, you risk breaking something from a previous iteration. Automated regression testing is not optional in iterative development — it is the foundation. Invest in test automation early.

Tip 2: Define “done” for each increment. In incremental development, each increment must meet a clear definition of done — including testing. “The login module is done” should mean “the login module is coded, unit tested, integration tested, code reviewed, and documented.”

Tip 3: Use iterations to reduce risk, not just deliver features. If you are unsure whether a technology will work, dedicate the first iteration to building a proof of concept and testing it thoroughly. Do not wait until the final iteration to discover that your architecture cannot handle the load.

Key Takeaways

  • Iterative development refines the whole product through repeated cycles
  • Incremental development builds the product piece by piece, each piece fully tested
  • Modern development (Agile) combines both: incremental delivery with iterative refinement
  • The Spiral Model added risk analysis to iterative development, influencing all modern approaches
  • Testing happens in every iteration and increment, finding defects early when they are cheap to fix
  • Automated regression testing is essential in iterative/incremental development to prevent regressions
  • The choice of SDLC model depends on context: requirement stability, risk level, regulatory needs, and feedback requirements