Modello a cascata

Nella gestione dei progetti, si parla di approccio waterfall (a cascata in italiano) o predittivo quando i requisiti del progetto e del prodotto vengono definiti, raccolti e analizzati a priori, ovvero all’inizio del progetto ^[1]. È contrapposto agli approcci agili e adattivi ^[1].

Storicamente, è stato il primo approccio di project management a essere formalizzato: inizialmente nelle pratiche militari dell'esercito statunitense^[2], e, successivamente, in standard internazionali come il PMBOK. È stato largamente adottato in vari ambiti e settori fino agli anni 2000, quando l'avvento delle metodologie agili ne ha evidenziato i limiti per determinati contesti. Oggi, rimane l’approccio di riferimento per i grandi progetti di ingegneria edile, civile ed elettrica, mentre nel settore informatico si tendono a preferire approcci agili.

I primi riscontri ben documentati dell’uso di approcci predittivi risalgono agli anni 20-40. Cicli di progetto strutturati erano già impiegati, seppur in modo informale, in ambito militare e ingegneristico durante la Seconda guerra mondiale e la Guerra Fredda, soprattutto in progetti complessi e ad alto rischio, come quelli aerospaziali e di difesa. La prima formalizzazione esplicita di questo tipo di approccio risale al 1956, grazie al lavoro di Herbert D. Benington, presentato in occasione di un simposio dell'U.S. Navy sulla gestione del progetto SAGE (Semi-Automatic Ground Environment), un avanzato sistema di difesa aerea^[2]. Sebbene il termine "waterfall" non fosse ancora in uso, il modello da lui descritto rappresenta una delle prime descrizioni formali di un processo di sviluppo sequenziale a fasi.

Nell'ingegneria del software, il ciclo di vita a cascata fu il primo modello di ciclo di vita del software, sviluppato a seguito della software crisis. La sua teorizzazione rappresenta innanzitutto un importante mutamento di prospettiva nella pratica dello sviluppo del software, che viene per la prima volta concepita come processo industriale, cioè come una sequenza di sottoattività (tutte con relative documentazioni e controllo), anziché come attività "artigianale" (il cosiddetto approccio code and fix, che si potrebbe tradurre in italiano come programmazione per tentativi ed errori). Il ciclo di vita a cascata ebbe un enorme successo negli anni settanta ed è quello che ancora oggi viene più spesso associato alla programmazione procedurale e strutturata.

A partire almeno dagli anni ottanta il modello è stato soggetto a profonde critiche e revisioni, soprattutto dovute all'evoluzione del software stesso e dei linguaggi di programmazione. Benché gran parte delle critiche a questo modello siano oggi universalmente accettate, il ciclo di vita a cascata continua a rimanere un punto di riferimento importante, in sostanza un modello "canonico" rispetto al quale vengono spesso descritte le "variazioni" moderne; ed è spesso il primo modello di sviluppo software che si insegna agli studenti. Tra le nuove metodologie di sviluppo del software ci sono il modello a spirale e le metodologie agili.

I capisaldi sono:

• il processo di sviluppo è diviso in fasi sequenziali;
• ogni fase produce un output che è usato come input per la fase successiva;
• ogni fase del processo viene documentata.

Il modello a cascata tradizionale prevede le seguenti fasi:

• analisi dei requisiti: ha lo scopo di determinare cosa farà il sistema; essa comprende, o è preceduta da, uno studio di fattibilità, in cui si stabilisce se valga la pena (da un punto di vista tecnico ed economico) realizzare il sistema del quale si vanno definendo i requisiti;
• progettazione: ha lo scopo di determinare come il sistema farà quanto stabilito nella prima fase, e in particolare la sua suddivisione in moduli e le relazioni fra di essi;
• codifica o sviluppo: creazione dei moduli con un linguaggio di programmazione;
• collaudo: esecuzione di prove per verificare la correttezza dell'implementazione dei singoli moduli;
• integrazione (o ''test di integrazione''): esecuzione di prove per verificare la correttezza del funzionamento complessivo del sistema;
• manutenzione: segue la consegna o delivery del prodotto al cliente, e comprende tutte le attività volte a migliorare, estendere e correggere il sistema nel tempo.

Nel contesto di una specifica organizzazione, il modello a cascata può essere ridefinito con varianti specifiche. Inoltre, un'organizzazione può formalizzare ulteriormente il processo definendo standard e imponendo vincoli per quanto riguarda la natura, il formato, la struttura e/o i contenuti dei documenti prodotti nelle varie fasi (i cosiddetti deliverable, consegnabili), tipicamente allo scopo di consentire un controllo più rigoroso sullo stato di avanzamento del progetto e sulla qualità del lavoro svolto.

In ingegneria del software, il modello a cascata (waterfall model in inglese) o ciclo di vita a cascata (waterfall lifecycle) è il più tradizionale modello di ciclo di vita del software. Secondo questo modello, il processo di realizzazione del software è strutturato in una sequenza lineare di fasi o passi^[3], che comprende:

• analisi dei requisiti
• progettazione
• sviluppo
• collaudo
• manutenzione

Questo modello riprende la sequenza di passi tipica della produzione manifatturiera, e fu il primo a essere applicato quando lo sviluppo del software cominciò a essere concepito come attività industriale.^[4] Il modello è stato progressivamente abbandonato dall'industria del software, ma rimane un importante riferimento storico.

È la prima fase. Scopo

• Decidere se debba essere intrapreso un nuovo sviluppo.

Attori coinvolti

• Cliente/Committente
• Organizzazione aziendale

Output

• Un documento che presenti diversi scenari e soluzioni insieme a una discussione dei compromessi in termini di costi previsti e benefici.

Svolgimento

• Interazione tra gli attori
• Ricerca delle soluzioni esistenti

Problemi principali

• Analisi spesso svolta sotto pressione e in fretta
• Analisi dei costi a volte imperfetta con continui rifacimenti
• Decisioni premature che ostacolano lo sviluppo successivo

Input

• Il documento di studio di fattibilità

Scopo

• Identificazione e descrizione dei requisiti, ossia delle caratteristiche del sistema

Attori coinvolti

• Cliente/Committente
• Sviluppatori
• Organizzazione aziendale

Output

• Un documento che descrive le caratteristiche del sistema e che colga le esigenze dell'utente ma sia anche esaustivo per il progettista. Tale documento, per mettere d'accordo le parti, deve essere facilmente comprensibile, preciso, completo, coerente e non ambiguo, inoltre facilmente modificabile;
• Manuale utente: in alcuni casi può essere utile una versione preliminare in cui si spiega come l'utente interagirà con il sistema;
• Piano di test: non è indispensabile, ma si può decidere in questa fase insieme all'utente.

Svolgimento

• Interazione tra gli attori
• Più il sistema è innovativo più è necessario interagire
• La documentazione va descritta secondo degli standard e delle notazioni specifici

Problemi principali

• Assenza di linguaggio comune tra gli attori
• Requisiti spesso poco chiari
• Impossibilità di considerare tutti i requisiti e di produrre un lavoro completo

Input

• Il documento di specifica dei requisiti

Scopo

• Definire l'architettura del sistema

Attori

• Chief Software Architect/Software Architect

Output

• Definizione della struttura di massima (architettura di alto livello)
• Definizione delle caratteristiche dei singoli componenti (moduli)

Svolgimento

• Individuazione dei componenti necessari e delle loro caratteristiche

Problemi

• Si devono prendere molte decisioni
• Non tutte le strutture sono uguali
• Non sempre le scelte sono ben definite

Input

• I documenti di progetto

Scopo

• Implementare i moduli

Attori

• Sviluppatori

Output

• Moduli implementati

Svolgimento

• Scrittura del codice
• Test di modulo
• Controllo di aderenza agli standard

Problemi

• Scrittura del codice

Input

• I moduli codificati

Scopo

• Controllare che i moduli presi a uno a uno funzionino
• Controllare che una volta messi assieme i moduli continuino a funzionare

Attori

• Sviluppatori

Output

• Il sistema funzionante
• Tecniche di verifica e validazione (alpha test)

Problemi

• Diversi tipi di problemi soprattutto connessi a una cattiva analisi dei requisiti

• Tutto ciò che accade dal momento della consegna del sistema alla sua dismissione
• Verifica del software da parte degli utenti (beta test)
• È una fase molto lunga

Così semplificato, il ciclo di vita classico può essere rappresentato come:

• Analisi
• Design
• Codifica
• Integrazione
• Test
• Rilascio

da cui il richiamo alla cascata che si trova nel nome.

A titolo di esempio, si considera il ciclo di vita definito con le MIL-STD-2167 da parte dell'United States Department of Defense (DoD, il Ministero della Difesa statunitense) per il linguaggio Ada (altro prodotto del DoD).

Le MIL-STD-2167 dividono il ciclo di vita del software nelle seguenti 6 macro attività:

• ANALISI:
  • Analisi dei requisiti: definisce cosa viene richiesto in termine di funzioni, senza specificare come esse devono essere realizzate
  • Progetto preliminare: segue i requisiti, sviluppa un approccio al software che comprende anche modelli matematici, diagrammi di flusso funzionali e procedure di collaudo. In questa fase si definiscono la struttura generale e le operazioni del sistema, indicando anche le relazioni tra i principali blocchi funzionali (moduli)
• PROGETTAZIONE:
  • Progetto esecutivo: effettiva scomposizione gerarchica e dettagliata di tali moduli; questa scomposizione continua fino a che un'ulteriore scomposizione porterebbe al codice del programma
• IMPLEMENTAZIONE:
  • Codifica e verifica: scrittura e verifica dei programmi partendo dal progetto esecutivo e utilizzando le procedure di verifica
  • Computer Software Code (CSC): integrazione e verifica delle unità comprese nei singoli sottosistemi
  • Convalida dell'integrazione del CSC

Il modello ha giocato un ruolo importante nello sviluppo del software per superare i limiti del processo del “code and fix” e infine ha fissato due concetti:

• Il processo di sviluppo del software deve essere soggetto a disciplina e pianificazione;
• L'implementazione del prodotto deve essere rimandata fino a quando non sono perfettamente chiari gli obiettivi.

Il maggior pregio di questo metodo di lavoro è certamente la semplificazione del controllo dell'andamento del progetto tramite la suddivisione del ciclo di vita in fasi successive ben definite. Le diverse metodologie che adottano questo ciclo di vita si distinguono essenzialmente per la suddivisione e specificazione delle fasi in sottofasi più elementari, nella definizione di standard di documentazione e nella individuazione di momenti di verifica al termine di ciascuna attività (milestone). Per ottimizzare il ciclo di vita, la scomposizione delle fasi in sottofasi persegue due obiettivi:

• assegnare a ciascuna fase la soluzione di problematiche specifiche
• rendere, per quanto possibile, le fasi indipendenti allo scopo di poterne parallelizzare le attività

Benché l'adozione di questi principi appaia estremamente produttiva, la loro applicazione pratica ha come effetto collaterale, soprattutto per i progetti di grandi dimensioni, un pericoloso scollamento fra le diverse attività, sia per le difficoltà di coordinamento che per la difformità delle metodologie e dei formalismi specialistici adottati. Ad esempio, normalmente l'individuazione delle strutture dati e delle funzionalità del sistema sono affrontate con metodologie diverse e, soprattutto per i progetti di grandi dimensioni, contemporaneamente e separatamente da gruppi di lavoro differenti. Nel primo caso i risultati sono formalizzati con uno Schema Entità-Associazione (ER o Entity-Relationship diagram nella dizione anglosassone) nel secondo con un metodo di scomposizione funzionale. Solo quando queste due attività terminano viene avviata un'ulteriore attività di armonizzazione dei rispettivi risultati.

Un ulteriore problema di questa impostazione deriva dalla necessità di terminare completamente tutta la fase di analisi dei requisiti e progetto dell'applicazione per cominciare la programmazione e quindi verificarne sul campo le conclusioni.

Il modello, quindi, è una semplificazione della realtà che non trova piena applicazione in quanto vanno rispettati tre principi:

• Linearità: spesso si hanno cicli di feedback (il caso dell'alpha e del beta testing) per la correzione degli errori. Tale feedback deve essere lineare e, quindi, non si possono effettuare salti a ritroso ma vanno ripercorse tutte le fasi in maniera lineare;
• Rigidità: ogni fase viene congelata quando si passa alla fase successiva, per cui non è possibile un'interazione tra clienti e sviluppatori durante il ciclo di vita dopo la parte iniziale;
• Monoliticità: tutto il modello è orientato alla singola data di rilascio che spesso si pone a mesi o anni dopo l'inizio della prima fase, per cui se vengono commessi eventuali errori o cambiano i requisiti, questi verranno implementati dopo parecchio tempo e comunque alla fase di consegna seguirà subito un altro adattamento perché il software sarà già obsoleto.

I maggiori problemi sono i seguenti:

• È difficile stimare le risorse e i costi in maniera accurata finché non sia stata svolta almeno la prima fase di analisi;
• La specifica dei requisiti produce un documento scritto che vincola il prodotto da sviluppare: ciò non sempre soddisfa le esigenze del cliente, perché si tratta pur sempre di specifiche basate su un documento inanimato che non sempre aiuta nel definire le esigenze (che, invece, appaiono subito chiare dopo il primo rilascio del software). Inoltre, tale documento deve essere completo e chiaro prima di procedere allo sviluppo, ma non sempre ciò è possibile;
• L'utente spesso non conosce tutti i requisiti dell'applicazione perché non può conoscerli, motivo per cui non sempre il documento dei requisiti è completo e, quindi, si ha un passaggio alla fase successiva con documentazione poco chiara;
• Il modello obbliga a usare standard pesantemente basati sulla produzione di una data documentazione in determinati momenti, per cui il lavoro rischia di essere burocratizzato.

Si comprende come gli alti costi del software siano spesso dovuti al modello a cascata, proprio a causa delle specifiche poco complete e ai molti interventi successivi per introdurre funzionalità non previste in partenza. Capita, quindi, che le pecche del modello vadano a ricadere sulla manutenzione, causandone costi crescenti, o che, al contrario, si operi con una manutenzione sommaria producendo un software con un'implementazione che diverge dalle specifiche dei requisiti.

• SSADM
• V-Model
• Modello a spirale
• Metodologia agile

• Wikimedia Commons contiene immagini o altri file sul modello a cascata