Il modello a cascata

Il modello a cascata è un ciclo di vita sequenziale grazie al quale è possibile modellare gli sviluppi utilizzando fasi consecutive.

Il modello a cascata (in inglese waterfall model) è un ciclo di vita lineare, che suddivide il processo di sviluppo in fasi di progetto consecutive. A differenza dei modelli iterativi, ogni fase viene eseguita solo una volta. I risultati di ogni fase rappresentano le precondizioni per la fase successiva. Il modello a cascata viene utilizzato soprattutto nello sviluppo dei software.

Lo sviluppo del classico modello a cascata viene attribuito allo scienziato informatico Winston W. Royce. Royce, tuttavia, non è stato il suo vero inventore. Al contrario, il suo articolo pubblicato nel 1970 “Managing the Development of Large Software Systems” conteneva una critica aperta nei confronti dei cicli di vita lineari. Come alternativa Royce presentava un modello iterativo-incrementale, in cui ogni fase attinge a quella precedente e ne verifica i risultati.

Royce proponeva un modello con sette fasi eseguite in diversi passaggi (iterazioni):

1. Requisiti di sistema
2. Requisiti di software
3. Analisi
4. Progettazione
5. Implementazione
6. Test
7. Esecuzione

Il ciclo di vita conosciuto come modello a cascata si ispira alle fasi definite da Royce, ma prevede solo un’iterazione.

Infatti nell’articolo di Royce della parola “modello a cascata” non vi è nemmeno l’ombra.

Le estensioni del modello a cascata semplice completano il modello base con funzioni iterative, ad esempio confrontando e verificando i risultati di ciascuna fase con quelli della fase precedente.

Nel modello a cascata le singole fasi di un processo di sviluppo si susseguono una dopo l’altra come una cascata. Ogni fase si chiude con un risultato intermedio (milestone), ad esempio con un catalogo di requisiti sotto forma di disciplinare, con la specifica di un’architettura software o con l’utilizzo di una versione alpha o beta.

Ogni progetto di software inizia con una fase di analisi che consiste in uno studio della fattibilità e una definizione dei requisiti. Durante lo studio della fattibilità il progetto software viene valutato in base ai costi, ai profitti e alla realizzabilità. Dallo studio della fattibilità risultano un disciplinare (una descrizione generale dei requisiti), un piano di progetto e il calcolo di progetto come anche un’offerta per il committente.

Infine segue una dettagliata definizione dei requisiti, che comprende l’analisi della situazione effettiva e il progetto teorico. Mentre l’analisi della situazione effettiva delinea l’area problematica, nel progetto teorico si definiscono quali funzioni e caratteristiche deve offrire il software per poter soddisfare i requisiti. I risultati della definizione dei requisiti includono, ad esempio, delle specifiche tecniche, una descrizione dettagliata di come devono essere soddisfatti i requisiti del progetto e un piano per il test di accettazione.

La prima fase del modello a cascata si conclude con un’analisi della definizione dei requisiti, in cui i problemi complessi vengono scomposti in piccoli incarichi per i quali vengono elaborate le relative strategie di soluzione.

La fase di progettazione prevede la preparazione di un concreto piano di soluzione sulla base di requisiti, incarichi e strategie già individuati. In questa fase gli sviluppatori software elaborano l’architettura del software come anche un progetto di costruzione del software, concentrandosi su componenti concreti come interfaccia, framework e librerie. Il risultato della fase di progettazione sarà un documento di bozza con il progetto di costruzione del software e la pianificazione dei test per i singoli componenti.

L’architettura del software concepita nella fase di progettazione viene realizzata nella fase di implementazione, che comprende la programmazione del software, la ricerca degli errori e i test modulari. Durante la fase di implementazione il software viene tradotto nella lingua di programmazione desiderata. I singoli componenti vengono sviluppati separatamente, testati durante i test modulari e integrati passo dopo passo al prodotto. Il risultato della fase di implementazione è un prodotto software che nella fase successiva verrà testato per la prima volta come prodotto completo (test alpha).

La fase di test comprende l’integrazione del software nell’ambiente di destinazione desiderato. Di regola i software vengono prima consegnati al consumatore finale nella versione beta (test beta). È possibile verificare se il software soddisfa i requisiti definiti in precedenza attraverso i test di accettazione sviluppati durante la fase dell’analisi. Un software che supera i test beta è pronto per il rilascio.

Nel momento in cui termina la fase di test, il software passa alla fase di esecuzione per l’uso produttivo. L’ultima fase del modello a cascata prevede rilascio, manutenzione e miglioramento del software.

Il modello a cascata offre una struttura organizzativa chiara per i progetti di sviluppo, nella quale le singole fasi del progetto sono chiaramente distinte. Poiché ogni fase si chiude al raggiungimento di un traguardo, il processo di sviluppo è facile da comprendere. Il fulcro del modello è rappresentato dalla documentazione delle fasi del processo. Le conoscenze acquisite sono registrate nei documenti di requisiti e progettazione.

In teoria il modello a cascata dovrebbe creare le condizioni per una realizzazione rapida ed economica dei progetti attraverso una pianificazione attentamente elaborata in anticipo. Tuttavia l’utilizzo del modello a cascata per l’uso pratico è controverso. Da una parte, le fasi del progetto per lo sviluppo del software sono chiaramente distinte solo in rari casi. Soprattutto nei complessi progetti di software gli sviluppatori spesso trovano diverse componenti di un’applicazione presenti allo stesso tempo in diverse fasi dello sviluppo. Dall’altra parte, il decorso lineare del modello a cascata spesso non corrisponde alle condizioni reali.

Secondo il modello a cascata le modifiche non sono previste nel corso del progetto. In tal caso un progetto di software, i cui dettagli di sviluppo sono già stati stabiliti all’inizio, si porta a termine senza problemi solo se già nella fase iniziale si investe tempo e denaro nell’analisi e nella progettazione. Inoltre i grandi progetti di software possono durare anche diversi anni senza che siano adeguati regolarmente ai più recenti risultati di sviluppo, obsoleti già al momento della loro introduzione.

I modelli a cascata sono utilizzati principalmente in progetti i cui requisiti e processi possono essere descritti con precisione già nella fase di pianificazione e dove si presume che cambieranno solo in minima parte nel corso del progetto. I cicli di vita estremamente lineari sono adatti soprattutto a progetti di software piccoli, semplici e chiaramente strutturati. Questo è quello che affermava Royce già negli anni ’70. L’alternativa al ciclo di vita lineare da lui proposto, che è stato in seguito denominato modello a cascata, conteneva quindi due estensioni essenziali:

Secondo Royce i risultati di ogni fase di progetto dovevano essere confrontati e verificati con i documenti elaborati in precedenza: ad esempio, bisognava assicurarsi che un modulo rispecchiasse i requisiti predefiniti già dopo il suo sviluppo e non alla fine del processo di sviluppo.

Il modello a cascata secondo Royce doveva essere seguito per almeno due volte: prima per lo sviluppo di un prototipo e poi per lo sviluppo del prodotto software vero e proprio.

Come terza estensione del modello a cascata, l’articolo di Royce richiedeva una misura ormai standard nello sviluppo del prodotto: l’inclusione dell’utente finale nel processo di produzione. Royce proponeva di includere l’utente in tre occasioni nel processo di sviluppo del software: durante la pianificazione del software nella fase dell’analisi, tra la progettazione del software e l’implementazione e durante la fase di test prima del rilascio del software.

A causa del decorso lineare delle sue fasi di progetto sequenzialmente consecutive, il modello a cascata è adatto solo per i piccoli progetti di software. Processi complessi e a più livelli, al contrario, sono difficili da adattare a tale modello. Nel corso del tempo, quindi, sono state sviluppate diverse alternative.

Mentre modelli come il modello a spirale e il modello a V rappresentano evoluzioni del classico modello a cascata, quelli successivi come l’extreme programming, lo sviluppo agile dei software o la prototipazione iterativa hanno un approccio totalmente diverso e consentono l’adattamento più flessibile agli attuali cambiamenti e ai nuovi requisiti.