02 - Waterfall Model: Classic Sequential Approach

The Waterfall Model: Classic Sequential Approach

The Waterfall model is one of the oldest and most traditional software development methodologies. Characterized by a sequential and linear approach, it divides the project into distinct phases that must be completed before moving to the next one.

History and Origins

The Waterfall model has origins in the 1950s-1960s, inspired by traditional engineering practices (construction, mechanical). The term "Waterfall" was coined in 1970 by Winston W. Royce in his famous paper "Managing the Development of Large Software Systems".

The 5 Phases of Waterfall

The classic model consists of 5 sequential phases. Each phase produces specific deliverables and must be completed before moving to the next:

┌─────────────────────────────────────────────────┐
│ 1. REQUIREMENTS ANALYSIS                        │
├─────────────────────────────────────────────────┤
│ Input:  Business needs, stakeholders            │
│ Output: Requirements Specification Document     │
│         (SRS - Software Requirements Spec)      │
│ Duration: 2-4 weeks (typical)                   │
└─────────────────────────────────────────────────┘
              ↓ (Phase Gate Review)
┌─────────────────────────────────────────────────┐
│ 2. SYSTEM DESIGN                                │
├─────────────────────────────────────────────────┤
│ Input:  SRS Document                            │
│ Output: Design Document (HLD, LLD)              │
│         - High-Level Design (architecture)      │
│         - Low-Level Design (components)         │
│         - Database schema, API specs            │
│ Duration: 3-6 weeks                             │
└─────────────────────────────────────────────────┘
              ↓ (Design Review)
┌─────────────────────────────────────────────────┐
│ 3. IMPLEMENTATION                               │
├─────────────────────────────────────────────────┤
│ Input:  Design Documents                        │
│ Output: Working Code, Unit Tests                │
│ Duration: 60-70% of total time                  │
└─────────────────────────────────────────────────┘
              ↓ (Code Review)
┌─────────────────────────────────────────────────┐
│ 4. TESTING & VERIFICATION                       │
├─────────────────────────────────────────────────┤
│ Input:  Compiled Code                           │
│ Output: Test Reports, Bug Fixes                 │
│ Levels: Unit → Integration → System → UAT       │
│ Duration: 15-25% of total time                  │
└─────────────────────────────────────────────────┘
              ↓ (QA Gate)
┌─────────────────────────────────────────────────┐
│ 5. DEPLOYMENT & MAINTENANCE                     │
├─────────────────────────────────────────────────┤
│ Input:  Tested Software                         │
│ Output: Production System, User Documentation   │
│ Activities: Release, Training, Bug fixing       │
│ Duration: Ongoing (product lifecycle)           │
└─────────────────────────────────────────────────┘

Phase 1: Requirements Analysis

The most critical phase of Waterfall. Here all system requirements are collected and documented before starting design.

Phase 2: System Design

Transforms requirements into a detailed technical blueprint. Divided into High-Level Design (architecture) and Low-Level Design (implementation details).

📐 HIGH-LEVEL DESIGN (HLD)
├─ System architecture (e.g.: 3-tier, microservices)
├─ UML diagrams (Class, Component, Deployment)
├─ Technology choices (languages, frameworks, database)
├─ Integrations and external APIs
└─ Security architecture

🔧 LOW-LEVEL DESIGN (LLD)
├─ Details of each module/component
├─ Algorithms and data structures
├─ Detailed database schema (ERD)
├─ API specifications (REST, GraphQL)
└─ Interface design (mockups, wireframes)

Phase 3: Implementation

The actual coding phase. Developers translate design documents into working code following defined standards.

// ✅ Naming Conventions
class UserService {{ '{' }} {{ '}' }}        // PascalCase for classes
function getUserById() {{ '{' }} {{ '}' }}    // camelCase for functions
const MAX_RETRY = 3;          // UPPER_CASE for constants

// ✅ File Organization
src/
├── components/
├── services/
├── models/
├── utils/
└── tests/

// ✅ Error Handling
try {{ '{' }}
  await fetchUser(id);
{{ '}' }} catch (error) {{ '{' }}
  logger.error('User fetch failed', {{ '{' }} id, error {{ '}' }});
  throw new UserNotFoundError(id);
{{ '}' }}

Phase 4: Testing & Verification

Systematic testing at multiple levels to verify that the software meets requirements. In Waterfall, testing occurs after implementation completion.

🧪 1. UNIT TESTING
   ├─ Tests individual functions/methods
   ├─ Executed by: Developers
   ├─ Tools: JUnit, Jest, pytest
   └─ Coverage: 80-90%

🔗 2. INTEGRATION TESTING
   ├─ Tests interaction between modules
   ├─ Executed by: QA Team
   ├─ Focus: API, Database, Services
   └─ Approaches: Big Bang, Top-Down, Bottom-Up

🖥️ 3. SYSTEM TESTING
   ├─ Tests complete system end-to-end
   ├─ Executed by: QA Team
   ├─ Types: Functional, Performance, Security
   └─ Environment: Staging (simulates production)

👤 4. USER ACCEPTANCE TESTING (UAT)
   ├─ Customer verification
   ├─ Executed by: End users, Business analysts
   ├─ Criteria: SRS requirements satisfaction
   └─ Output: Sign-off for Go-Live

Phase 5: Deployment & Maintenance

Software release to production and ongoing support. Includes user training, bug fixing, and updates.

Phase Gate Reviews

Phase gates are critical checkpoints between phases. Each phase must be formally approved before proceeding to the next.

📋 PHASE COMPLETED
    ↓
🔍 REVIEW MEETING
├─ Participants: Project Manager, Tech Lead, Stakeholder
├─ Agenda: Deliverable presentation, Q&A
└─ Duration: 1-3 hours
    ↓
✅ EVALUATION
├─ Deliverables complete?
├─ Acceptable quality?
├─ Risks identified?
└─ Budget and timeline respected?
    ↓
⚖️ DECISION
├─ ✅ GO: Proceed to next phase
├─ ⚠️ CONDITIONAL GO: Proceed with reservations
└─ ❌ NO-GO: Return and fix

Waterfall Variants

V-Model (Verification & Validation)

Waterfall extension that emphasizes testing. Each development phase has a corresponding testing phase.

Requirements ←─────────→ User Acceptance Testing
      ↓                              ↑
System Design ←─────────→ System Testing
      ↓                              ↑
Architecture  ←─────────→ Integration Testing
      ↓                              ↑
Module Design ←─────────→ Unit Testing
      ↓                              ↑
    Implementation (Vertex of V)

Sashimi Model

Variant that allows partial overlap between adjacent phases, like overlapping sashimi slices. More flexible than pure Waterfall.

Waterfall Advantages

Disadvantages and Limitations

When to Use Waterfall

✈️ AEROSPACE SECTOR
├─ Avionics control software
├─ Fixed requirements and rigorous certifications
└─ Change after deployment = catastrophe

🏥 MEDICAL SECTOR
├─ Medical device software (FDA approval)
├─ Exhaustive documentation mandatory
└─ Requirements → test traceability

🏗️ INFRASTRUCTURE PROJECTS
├─ Legacy database migration
├─ Detailed data migration plan
└─ Complex rollback, planning required

When to Avoid Waterfall

Common Anti-Patterns

Typical errors in Waterfall application that lead to project failure:

Waterfall vs Agile: Direct Comparison

Best Practices for Modern Waterfall

How to apply Waterfall effectively in the modern context:

Case Study: Successful Waterfall Project

Evolution: From Waterfall to Hybrid Methods

Many modern organizations adopt hybrid approaches that take the best from Waterfall and Agile:

Conclusions

The Waterfall model, despite criticism in the Agile era, remains valid and necessary in specific contexts. The key is not "Waterfall vs Agile" but when to use each.