02 - Modello Waterfall: Approccio Sequenziale Classico

Il Modello Waterfall: Approccio Sequenziale Classico

Il modello Waterfall (o a cascata) è una delle più antiche e tradizionali metodologie di sviluppo software. Caratterizzato da un approccio sequenziale e lineare, divide il progetto in fasi distinte che devono essere completate prima di procedere alla successiva.

Storia e Origini

Il modello Waterfall ha origini negli anni '50-'60, ispirandosi alle pratiche di ingegneria tradizionale (edile, meccanica). Il termine "Waterfall" fu coniato nel 1970 da Winston W. Royce nel suo famoso paper "Managing the Development of Large Software Systems".

Le 5 Fasi del Waterfall

Il modello classico si articola in 5 fasi sequenziali. Ogni fase produce deliverable specifici e deve essere completata prima di passare alla successiva:

┌─────────────────────────────────────────────────┐
│ 1. REQUIREMENTS ANALYSIS (Analisi Requisiti)   │
├─────────────────────────────────────────────────┤
│ Input:  Esigenze business, stakeholder         │
│ Output: Requirements Specification Document     │
│         (SRS - Software Requirements Spec)      │
│ Durata: 2-4 settimane (tipico)                  │
└─────────────────────────────────────────────────┘
              ↓ (Phase Gate Review)
┌─────────────────────────────────────────────────┐
│ 2. SYSTEM DESIGN (Progettazione)               │
├─────────────────────────────────────────────────┤
│ Input:  SRS Document                            │
│ Output: Design Document (HLD, LLD)              │
│         - High-Level Design (architettura)      │
│         - Low-Level Design (componenti)         │
│         - Database schema, API specs            │
│ Durata: 3-6 settimane                           │
└─────────────────────────────────────────────────┘
              ↓ (Design Review)
┌─────────────────────────────────────────────────┐
│ 3. IMPLEMENTATION (Implementazione)             │
├─────────────────────────────────────────────────┤
│ Input:  Design Documents                        │
│ Output: Working Code, Unit Tests                │
│ Durata: 60-70% del tempo totale                 │
└─────────────────────────────────────────────────┘
              ↓ (Code Review)
┌─────────────────────────────────────────────────┐
│ 4. TESTING & VERIFICATION (Collaudo)           │
├─────────────────────────────────────────────────┤
│ Input:  Compiled Code                           │
│ Output: Test Reports, Bug Fixes                 │
│ Livelli: Unit → Integration → System → UAT      │
│ Durata: 15-25% del tempo totale                 │
└─────────────────────────────────────────────────┘
              ↓ (QA Gate)
┌─────────────────────────────────────────────────┐
│ 5. DEPLOYMENT & MAINTENANCE (Deploy/Supporto)  │
├─────────────────────────────────────────────────┤
│ Input:  Tested Software                         │
│ Output: Production System, User Documentation   │
│ Attività: Rilascio, Training, Bug fixing        │
│ Durata: Ongoing (lifecycle del prodotto)        │
└─────────────────────────────────────────────────┘

Fase 1: Requirements Analysis (Analisi Requisiti)

La fase più critica del Waterfall. Qui vengono raccolti e documentati tutti i requisiti del sistema prima di iniziare il design.

Fase 2: System Design (Progettazione)

Trasforma i requisiti in un blueprint tecnico dettagliato. Si divide in High-Level Design (architettura) e Low-Level Design (dettagli implementativi).

📐 HIGH-LEVEL DESIGN (HLD)
├─ Architettura di sistema (es: 3-tier, microservices)
├─ Diagrammi UML (Class, Component, Deployment)
├─ Scelta tecnologie (linguaggi, framework, database)
├─ Integrations e API esterne
└─ Security architecture

🔧 LOW-LEVEL DESIGN (LLD)
├─ Dettagli di ogni modulo/componente
├─ Algoritmi e data structures
├─ Database schema dettagliato (ERD)
├─ API specifications (REST, GraphQL)
└─ Interface design (mockup, wireframe)

Fase 3: Implementation (Implementazione)

La fase di coding vera e propria. Gli sviluppatori traducono i design documents in codice funzionante seguendo gli standard definiti.

// ✅ Naming Conventions
class UserService {{ '{' }} {{ '}' }}        // PascalCase per classi
function getUserById() {{ '{' }} {{ '}' }}    // camelCase per funzioni
const MAX_RETRY = 3;          // UPPER_CASE per costanti

// ✅ 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);
{{ '}' }}

Fase 4: Testing & Verification (Collaudo)

Testing sistematico a più livelli per verificare che il software soddisfi i requisiti. Nel Waterfall, il testing avviene dopo il completamento dell'implementazione.

🧪 1. UNIT TESTING
   ├─ Testa singole funzioni/metodi
   ├─ Eseguito da: Sviluppatori
   ├─ Tools: JUnit, Jest, pytest
   └─ Coverage: 80-90%

🔗 2. INTEGRATION TESTING
   ├─ Testa interazione tra moduli
   ├─ Eseguito da: QA Team
   ├─ Focus: API, Database, Services
   └─ Approcci: Big Bang, Top-Down, Bottom-Up

🖥️ 3. SYSTEM TESTING
   ├─ Testa il sistema completo end-to-end
   ├─ Eseguito da: QA Team
   ├─ Tipi: Functional, Performance, Security
   └─ Environment: Staging (simula produzione)

👤 4. USER ACCEPTANCE TESTING (UAT)
   ├─ Verifica da parte del cliente
   ├─ Eseguito da: End users, Business analysts
   ├─ Criteri: Soddisfazione requisiti SRS
   └─ Output: Sign-off per Go-Live

Fase 5: Deployment & Maintenance

Rilascio del software in produzione e supporto continuo. Include training utenti, bug fixing e aggiornamenti.

Phase Gate Reviews

I phase gates sono checkpoint critici tra le fasi. Ogni fase deve essere formalmente approvata prima di procedere alla successiva.

📋 FASE COMPLETATA
    ↓
🔍 REVIEW MEETING
├─ Partecipanti: Project Manager, Tech Lead, Stakeholder
├─ Agenda: Presentazione deliverable, Q&A
└─ Durata: 1-3 ore
    ↓
✅ VALUTAZIONE
├─ Deliverable completi?
├─ Qualità accettabile?
├─ Rischi identificati?
└─ Budget e timeline rispettati?
    ↓
⚖️ DECISIONE
├─ ✅ GO: Procedi alla fase successiva
├─ ⚠️ CONDITIONAL GO: Procedi con riserve
└─ ❌ NO-GO: Ritorna e correggi

Varianti del Waterfall

V-Model (Verification & Validation)

Estensione del Waterfall che enfatizza il testing. Ogni fase di development ha una corrispondente fase di testing.

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

Sashimi Model

Variante che permette overlap parziale tra fasi adiacenti, come fette di sashimi sovrapposte. Più flessibile del Waterfall puro.

Vantaggi del Waterfall

Svantaggi e Limiti

Quando Usare il Waterfall

✈️ SETTORE AEROSPAZIALE
├─ Software di controllo avionica
├─ Requisiti fissi e certificazioni rigorose
└─ Change dopo il deploy = catastrofe

🏥 SETTORE MEDICALE
├─ Software per dispositivi medici (FDA approval)
├─ Documentazione esaustiva obbligatoria
└─ Tracciabilità requisiti → test

🏗️ PROGETTI INFRASTRUTTURALI
├─ Migrazione database legacy
├─ Piano dettagliato di migrazione dati
└─ Rollback complesso, occorre pianificazione

Quando Evitare il Waterfall

Anti-Pattern Comuni

Errori tipici nell'applicazione del Waterfall che portano al fallimento del progetto:

Waterfall vs Agile: Confronto Diretto

Best Practices per Waterfall Moderno

Come applicare Waterfall in modo efficace nel contesto moderno:

Case Study: Progetto Waterfall di Successo

Evoluzione: Da Waterfall a Metodi Ibridi

Molte organizzazioni moderne adottano approcci ibridi che prendono il meglio da Waterfall e Agile:

Conclusioni

Il modello Waterfall, nonostante le critiche nell'era Agile, rimane valido e necessario in specifici contesti. La chiave non è "Waterfall vs Agile" ma quando usare ciascuno.