Definizione
Il Waterfall Model è un approccio sequenziale allo sviluppo software in cui il progetto procede attraverso fasi discrete (Requirements, Design, Implementation, Verification, Maintenance), ognuna completata prima di iniziare la successiva. Il flusso è unidirezionale come una cascata, da cui il nome.
Ironicamente, il paper originale di Winston Royce (1970) che descrive questo modello lo faceva come esempio di approccio rischioso, non come best practice. Royce raccomandava iterazioni e prototyping. Successivamente, il modello fu semplificato e adottato ampiamente negli anni ‘80-‘90, diventando sinonimo di “approccio tradizionale”.
Le fasi del Waterfall
1. Requirements Analysis
- Raccogliere e documentare tutti i requisiti upfront
- Output: documento di specifica dei requisiti (SRS)
- Tipicamente richiede mesi di analisi e approvazioni
2. System Design
- Progettare architettura software e database
- Output: design documents, diagrammi UML, specifiche tecniche
- Architettura “carved in stone” prima di scrivere codice
3. Implementation
- Scrivere codice secondo design
- Spesso suddiviso in moduli sviluppati da team separati
- Output: codice sorgente, unit tests
4. Integration and Testing
- Integrare moduli e testare sistema completo
- Questa è la prima volta che componenti diversi vengono assemblati
- Output: test reports, bug lists
5. Deployment
- Rilascio del software agli utenti finali
- Training e documentazione utente
- Output: deployed system, manuals
6. Maintenance
- Bug fixes, aggiornamenti, nuove feature
- Spesso gestito da team separato da quello di sviluppo
Caratteristiche distintive
Documentazione pesante: ogni fase produce documenti formali che devono essere approvati prima di procedere. Requirements document, design specs, test plans.
Handoff tra fasi: diversi specialisti gestiscono fasi diverse (business analysts per requirements, architects per design, developers per implementation, QA per testing). Ogni handoff introduce rischio di miscommunication.
Late feedback: gli stakeholders vedono software funzionante solo dopo mesi/anni, nella fase di testing. Se i requisiti erano sbagliati, il costo di correzione è altissimo.
Change resistance: cambiare requisiti dopo la fase di design è costoso e scoraggiato. Formal change request processes.
Quando Waterfall funziona
Requisiti stabili e ben compresi: progetti in domini maturi dove requisiti non cambiano (es. compilatori, driver hardware, migrazioni di database).
Regulatory compliance: industrie regolamentate (aerospace, medical devices, finance) richiedono documentazione pesante e audit trail. Waterfall produce questa documentazione naturalmente.
Fixed-price contracts: quando scope, timeline, e budget sono fissati contrattualmente, Waterfall fornisce prevedibilità (almeno in teoria).
Progetti piccoli e semplici: per progetti di poche settimane con scope limitato, overhead di Waterfall è accettabile.
Quando Waterfall fallisce
Requisiti incerti: quando non si sa esattamente cosa costruire, specificare tutto upfront è impossibile. Waterfall assume falsamente che si possono conoscere tutti i requisiti all’inizio.
Fast-changing markets: in contesti competitivi, aspettare 12-18 mesi per delivery significa essere superati da competitor più agili.
User experience critical: UX richiede iterazione rapida su feedback utente. Waterfall consegna UI solo alla fine, troppo tardi per iterare.
Innovation projects: innovazione richiede sperimentazione e failure. Waterfall penalizza cambi di direzione.
Confronto con Agile
Feedback loop: Waterfall ha un unico feedback loop alla fine. Agile ha feedback continuo ogni 1-2 settimane.
Risk management: Waterfall sposta rischio alla fine (integration hell). Agile mitiga rischio continuamente con working software incrementale.
Adaptability: Waterfall assume requisiti stabili. Agile abbraccia cambiamento come inevitabile e positivo.
Team structure: Waterfall favorisce specializzazione e silos. Agile favorisce cross-functional teams.
Evoluzione e varianti
V-Model: estensione che associa ogni fase di sviluppo a corrispondente fase di testing. Migliora quality assurance ma mantiene natura sequenziale.
Spiral Model: Barry Boehm (1986) introduce iterazioni e risk analysis in ogni ciclo. Ibrido tra Waterfall e iterativo.
Waterfall con prototyping: approccio ibrido che mantiene fasi Waterfall ma include prototyping iniziale per validare requisiti.
Fraintendimenti comuni
”Royce ha inventato e raccomandato Waterfall”
No. Il paper di Royce (1970) descriveva il modello sequenziale come “risky and invites failure”. Raccomandava di fare almeno due iterazioni. Il modello fu adottato da altri che ignorarono le sue riserve.
”Waterfall è sempre obsoleto e sbagliato”
Falso. Per progetti con requisiti stabili, regulatory constraints, e bassa incertezza tecnica, Waterfall può essere appropriato. Il problema è applicarlo indiscriminatamente.
”Waterfall non fa testing”
Non vero. Waterfall ha fase di testing esplicita. Il problema è che testing arriva tardi (dopo implementation completa), rendendo bug fixes molto costosi.
”Agile ha ucciso Waterfall”
Parzialmente falso. In settori regolamentati (aerospace, medical, government), Waterfall è ancora prevalente per compliance reasons. Molte org usano ibridi (“Water-Scrum-Fall”).
Termini correlati
- Agile Software Development: approccio iterativo che contrasta con Waterfall
- Scrum: framework agile specifico, antitesi di Waterfall
- DevOps: estende agilità a operations, incompatibile con Waterfall puro
- CRISP-DM: metodologia data science con elementi iterativi, non waterfall
Fonti
- Royce, W. (1970). “Managing the Development of Large Software Systems”
- Boehm, B. (1986). “A Spiral Model of Software Development and Enhancement”
- Sommerville, I. (2015). Software Engineering, 10th Edition
- Brooks, F. (1975). The Mythical Man-Month