Il modello a cascata
La redazione di IONOS9 mins
Il modello a cascata è un ciclo di vita sequenziale grazie al quale è possibile modellare gli sviluppi utilizzando fasi consecutive.
- Certificato SSL Wildcard incluso
- Registrazione di dominio sicura
- Indirizzo e-mail professionale da 2 GB
Cos’è il modello a cascata?
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.
Come funziona il modello a cascata?
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):
- Requisiti di sistema
- Requisiti di software
- Analisi
- Progettazione
- Implementazione
- Test
- 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.
Il modello a cascata è diventato famoso grazie allo standard USA DoD-STD-2167. Quest’ultimo si basa su una forma molto semplificata del ciclo di vita sviluppato da Royce, che gli autori sembravano non aver capito del tutto: le difficoltà sorgevano nella comprensione del modello iterativo-incrementale, come David Maibor, un autore dello standard, ammise più tardi.
Nella pratica vengono utilizzate diverse versioni del modello a cascata. Attualmente sono in uso modelli che suddividono i processi di sviluppo in cinque fasi. Le fasi 1, 2 e 3, definite da Royce, sono riunite in un’unica fase di progetto, chiamata analisi dei requisiti.
- Analisi: pianificazione, analisi e specificazione dei requisiti
- Progettazione: progettazione e specificazione del sistema
- Implementazione: programmazione e test di modulo
- Test: integrazione di sistema, test di sistema e test di integrazione
- Esecuzione: rilascio, manutenzione, miglioramento
La seguente immagine dimostra il motivo per cui il ciclo di vita lineare viene chiamato “modello a cascata”.
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.
Le fasi del modello a cascata
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.
Analisi
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.
Progettazione
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.
Implementazione
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).
Test
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.
Esecuzione
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.
Valutazione del modello a cascata
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.
Panoramica dei vantaggi e degli svantaggi del modello a cascata
| Vantaggi | Svantaggi |
|---|---|
| Una struttura semplice attraverso fasi di progetto chiaramente distinte. | I progetti complessi o a più livelli si possono suddividere raramente in fasi di progetto chiaramente distinte. |
| Una buona documentazione del processo di sviluppo attraverso traguardi ben definiti. | Poca possibilità di modifica in fase di progetto a causa dei requisiti. |
| Già all’inizio del progetto è possibile stimare il dispendio di denaro e la quantità di lavoro. | L’utente finale è coinvolto solo dopo la programmazione nel processo di produzione. |
| I progetti strutturati in base al modello a cascata si possono ben rappresentare su un'asse temporale. | Gli errori si individuano solo alla fine del processo di sviluppo. |
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:
Verifica dopo ogni fase di progetto
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.
Almeno due iterazioni
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.
Test che coinvolgono il cliente finale
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.
Alternative al modello a cascata
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.
