Descritto per la prima volta 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 leggere il testo di Royce, perché evidenzia il fatto che lui, a differenza di molti seguaci dei decenni successivi, era consapevole dei limiti del modello e proponeva dei correttivi, purtroppo raramente applicati.

La figura riportata sotto (un activity diagram UML) non rappresenta la versione originale del processo, ma una delle sue possibili derivazioni.

Nel modello a cascata, 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.

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

È 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 obsoleto, ed è raro trovare esperti che lo raccomandino ancora.
I settori economici competitivi e le organizzazioni attente ai costi, per cui 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

È semplice da spiegare e 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, …

Diventa facile organizzare il piano di progetto (non ci sono dubbi sulla sequenza delle fasi).

Si adatta bene a logiche organizzative e politiche del personale basate su una divisione del lavoro accentuata.

Svantaggi

È altamente rischioso. Le prime verifiche concrete, in termini di risultati visibili e comprensibili da committenti e utenti, arrivano verso la fine del progetto, al termine della fase di test. E quando ci si accorge che qualcosa non funziona , ossia che il sistema realizzato non corrisponde ai requisiti, impliciti ed espliciti, i tempi ed i costi del progetto aumentano in misura notevole.

Si basa su alcune assunzioni:

• 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:
  1. che si raggiunga un accordo sulla carta, ma non  sul merito dei problemi (e che non ci si renda conto della cosa fino alla verifica finale)
  2. 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 brevi. Ma non è certamente vero per progetti di complessità media o elevata.