Il modello a cascata, in inglese “Waterfall Model”, rappresentato di seguito, è il modello di processo di sviluppo del software più tradizionale, uno dei primi utilizzati nell’ingegneria del software.
Prevede una serie di fasi, svolte in maniera sequenziale, e ognuna di essi produce un output intermedio (detto milestone) utilizzato come input per la fase successiva, (da qui l’origine del termine “a cascata”). Inoltre, ogni fase del processo viene eseguita solo una volta. Nel dettaglio abbiamo:
Analisi: il cliente e il fornitore si riuniscono per identificare i requisiti che il software deve possedere. La fase si conclude con la redazione di un documento, chiamato specifica dei requisiti software contenente le funzionalità e le caratteristiche che il software deve avere per soddisfare le esigenze espresse dal cliente. Il documento, solitamente redatto da un analista funzionale, descrive “cosa” il software deve fare e non “come” debba essere realizzato.
Design: partendo dal documento delle specifiche, si definisce l’intera architettura del progetto software, definendo i vari componenti e le relazioni tra essi. Il professionista maggiormente coinvolto in questa fase è l’architetto del software (Software Architect) affiancato, a seconda del tipo di soluzione da realizzare, anche da esperti di architetture di rete, di database, di sistemi.
Sviluppo: in questa fase viene realizzato concretamente il software, attraverso la scrittura di codice, tramite i vari linguaggi di programmazione, da parte di uno o più programmatori software (Software Developer).
Testing: anche conosciuta come collaudo, vengono eseguite varie prove per verificare la correttezza dell’implementazione dei singoli moduli. Nello specifico si ha:
- Test di unità: prove eseguite dai programmatori per verificare la correttezza dell’implementazione dei singoli moduli.
- Test di integrazione: prove eseguite dagli analisti funzionali per verificare la correttezza del funzionamento complessivo del sistema.
- Test di accettazione: prove finali del funzionamento del sistema eseguite dal cliente allo scopo di verificare che i requisiti, espressi nelle specifiche, siano state implementate correttamente.
Rilascio: attività di consegna del sistema e la sua installazione nell’ambiente di produzione. Questa fase è conosciuta anche come deployment. Comprende tutte le azioni necessarie che consentono di utilizzare il nuovo sistema, dalla predisposizione dell’ambiente infrastrutturale sino all’utilizzo da parte degli utenti finali;
Manutenzione:
dopo il rilascio, vengono eseguite delle attività al fine di correggere eventuali presenti nel software, sfuggiti al Collaudo o introdotti successivamente dagli utenti; queste fase è detta manutenzione correttiva. Sono invece detti interventi di manutenzione evolutiva quelli che hanno lo scopo di aggiungere funzionalità al software. Infine abbiamo gli interventi di manutenzione adattiva che hanno lo scopo di adeguare il software ai cambiamenti dell’ambiente nel quale risiede.
In teoria il modello a cascata dovrebbe creare le condizioni migliori per una realizzazione rapida ed economica dei progetti, attraverso una precisa pianificazione preparata in anticipo.
Nella realtà, tuttavia è raro che le varie fasi del progetto siano chiaramente distinte solo in rari casi, soprattutto nei progetti complessi. Ad esempio, si passa alla fase di implementazione solo dopo che i requisiti sono stati tutti definiti. Ma questo difficilmente capita. Spesso due fasi vengono svolte nello stesso tempo.
Inoltre, secondo il modello a cascata, non si possono fare modifiche durante il progetto. Tutti i dettagli di sviluppo devono essere già stati stabiliti all’inizio, e tante volte ci si accorge degli errori solo quando si è arrivati alla fase finale del progetto, con un enorme spreco di tempo e di soldi.
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. Questo accade soprattutto a progetti di software piccoli.
Prevede una serie di fasi, svolte in maniera sequenziale, e ognuna di essi produce un output intermedio (detto milestone) utilizzato come input per la fase successiva, (da qui l’origine del termine “a cascata”). Inoltre, ogni fase del processo viene eseguita solo una volta. Nel dettaglio abbiamo:
Analisi: il cliente e il fornitore si riuniscono per identificare i requisiti che il software deve possedere. La fase si conclude con la redazione di un documento, chiamato specifica dei requisiti software contenente le funzionalità e le caratteristiche che il software deve avere per soddisfare le esigenze espresse dal cliente. Il documento, solitamente redatto da un analista funzionale, descrive “cosa” il software deve fare e non “come” debba essere realizzato.
Design: partendo dal documento delle specifiche, si definisce l’intera architettura del progetto software, definendo i vari componenti e le relazioni tra essi. Il professionista maggiormente coinvolto in questa fase è l’architetto del software (Software Architect) affiancato, a seconda del tipo di soluzione da realizzare, anche da esperti di architetture di rete, di database, di sistemi.
Sviluppo: in questa fase viene realizzato concretamente il software, attraverso la scrittura di codice, tramite i vari linguaggi di programmazione, da parte di uno o più programmatori software (Software Developer).
Testing: anche conosciuta come collaudo, vengono eseguite varie prove per verificare la correttezza dell’implementazione dei singoli moduli. Nello specifico si ha:
- Test di unità: prove eseguite dai programmatori per verificare la correttezza dell’implementazione dei singoli moduli.
- Test di integrazione: prove eseguite dagli analisti funzionali per verificare la correttezza del funzionamento complessivo del sistema.
- Test di accettazione: prove finali del funzionamento del sistema eseguite dal cliente allo scopo di verificare che i requisiti, espressi nelle specifiche, siano state implementate correttamente.
Rilascio: attività di consegna del sistema e la sua installazione nell’ambiente di produzione. Questa fase è conosciuta anche come deployment. Comprende tutte le azioni necessarie che consentono di utilizzare il nuovo sistema, dalla predisposizione dell’ambiente infrastrutturale sino all’utilizzo da parte degli utenti finali;
Manutenzione:
dopo il rilascio, vengono eseguite delle attività al fine di correggere eventuali presenti nel software, sfuggiti al Collaudo o introdotti successivamente dagli utenti; queste fase è detta manutenzione correttiva. Sono invece detti interventi di manutenzione evolutiva quelli che hanno lo scopo di aggiungere funzionalità al software. Infine abbiamo gli interventi di manutenzione adattiva che hanno lo scopo di adeguare il software ai cambiamenti dell’ambiente nel quale risiede.
In teoria il modello a cascata dovrebbe creare le condizioni migliori per una realizzazione rapida ed economica dei progetti, attraverso una precisa pianificazione preparata in anticipo.
Nella realtà, tuttavia è raro che le varie fasi del progetto siano chiaramente distinte solo in rari casi, soprattutto nei progetti complessi. Ad esempio, si passa alla fase di implementazione solo dopo che i requisiti sono stati tutti definiti. Ma questo difficilmente capita. Spesso due fasi vengono svolte nello stesso tempo.
Inoltre, secondo il modello a cascata, non si possono fare modifiche durante il progetto. Tutti i dettagli di sviluppo devono essere già stati stabiliti all’inizio, e tante volte ci si accorge degli errori solo quando si è arrivati alla fase finale del progetto, con un enorme spreco di tempo e di soldi.
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. Questo accade soprattutto a progetti di software piccoli.