Processo di sviluppo software a cascata (Waterfall)
Ideato da Walker Royce nel 1970.
Testo originale: "Managing the Development of Large Software Systems", pubblicato in Proceedings of IEEE Wescon (August 1970), e in "International Conference on Software Engineering - Proceedings of the 9th Conference - 1987, Monterey". Vale la pena leggerlo, perché ha molti spunti interessanti, e evidenzia la consapevolezza di Royce sui limiti del modello waterfall puro.
La figura riportata sotto (un activity diagram UML) non rappresenta la versione originale del processo, ma una delle sue derivazioni più diffuse.
Il progetto è organizzato in una sequenza di fasi, ciascuna delle quali produce un output che costituisce l'input per la fase successiva. Ad esempio, la fase di definizione dei requisiti produce un output, la "specifica dei requisiti", che entra in input alla fase di analisi. L'analisi produce la "specifica di analisi", che entra in input alla fase di design. E così via.
Naturalmente, all'inizio di ciascuna fase si verifica la qualità del lavoro effettuato nella fase precedente, con possibilità di ricicli per modifica.
Diffusione del processo a cascata
E' probabilmente il processo di sviluppo software più diffuso al mondo, anche perché segue il modello della catena di montaggio tipico della produzione industriale della prima metà del novecento. Ma è considerato irrimediabilmente obsoleto, ed è raro trovare esperti che lo raccomandino ancora. I settori economici per i quali la qualità e produttività dei progetti di sviluppo software sono più critici hanno da tempo abolito la pratica dello sviluppo a cascata, in quanto troppo rischioso.
Vantaggi
E' molto semplice da capire, quasi intuitivo (anche per chi non ha mai sviluppato software): prima si raccolgono tutti i requisiti, poi si fa tutta l'analisi, poi tutto il design, poi tutta la codifica, ...
E' semplicissimo organizzare il piano di progetto (non che sia facile pianificare le date di conclusione delle fasi, ma non ci sono dubbi sulla sequenza delle fasi stesse).
Si adatta perfettamente a logiche organizzative e politiche del personale basate su una divisione del lavoro accentuata.
Svantaggi
E' altamente rischioso. Le prime verifiche concrete, in termini di risultati visibili e comprensibili da committenti e utenti, arrivano verso la fine del progetto, nel periodo finale della fase di test. E se ci si accorge che qualcosa non funziona (accade...), ossia che il sistema realizzato non corrisponde ai requisiti, impliciti ed espliciti, i tempi ed i costi del progetto possono crescere in misura notevole.
Si basa su alcune assunzioni, il più delle volte sbagliate:
- Che sia possibile, nella fase iniziale del progetto, chiarire tutti i requisiti del sistema. E che sia possibile farlo senza discutere con il committente e le parti interessate nel merito delle soluzioni concrete, senza verificare l'accordo con la presentazione di prototipi utilizzabili. Questa assunzione sbagliata può provocare due effetti:
- che si raggiunga un accordo sulla carta, ma che non ci sia un accordo effettivo sul merito dei problemi (e che non ci si renda conto della cosa fino alla verifica finale)
- che si raggiunga la "paralisi dell'analisi", con il progetto che non riesce a chiarire alcune aree di ambiguità e l'impossibilità per il committente e le parti interessate di fornire i chiarimenti richiesti
- Che una volta ottenuto l'accordo sui requisiti (tipicamente, con la produzione di alcuni documenti testuali che specificano, in termini astratti, le funzionalità del sistema), i requisiti stessi non cambino più fino alla fine del progetto. Può essere vero, per progetti molto, molto brevi. Ma non è certamente vero per progetti di complessità media o elevata.
- Che sia possibile definire i requisiti, e stimare tempi e costi del progetto, senza possedere la competenza necessaria sugli aspetti tecnici ed implementativi. Questo non è in sé un limite del processo di sviluppo a cascata, ma della sua attuazione concreta in organizzazioni nelle quali esiste una forte divisione del lavoro. In molte realtà, la definizione dei requisiti viene effettuata da persone, nel ruolo di analisti, che non hanno le competenze tecniche necessarie allo sviluppo software. Oppure che avevano, anni addietro, competenze tecniche, ma basate sull'utilizzo di tecnologie diverse da quelle utilizzate nel progetto. E che non sono quindi in grado, da sole, di produrre stime attendibili.
Nota: E' opportuno ripetere che Winston Royce era consapevole dei limiti del modello a cascata, e che il suo articolo originale proponeva dei correttivi, purtroppo raramente applicati.
Torna a pagina introduttiva processo