Cascata - Modello Cascata

Dispositivo modello in cascata

Il modello a cascata, noto anche come Waterfall, è uno degli approcci più noti allo sviluppo del software. L'autore del modello è Winston Royce. Nel 1970 descrisse l'essenza della sua innovazione in un articolo che ne dettagliava vantaggi e svantaggi. Nello stesso luogo, ha spiegato come questo modello può essere perfezionato in un modello iterativo. Inizialmente, nel modello a cascata, le fasi di sviluppo vanno nel seguente ordine:

• Definizione e coordinamento dei requisiti;
• Approvazione del progetto;
• codifica;
• Creazione di una versione funzionante del prodotto software;
• Test e debug;
• Installazione software;
• Supporto.

Secondo il modello a cascata, l'esecuzione delle azioni da parte dello sviluppatore avviene in sequenza, punto per punto. Per cominciare, il lavoro è in fase di completamento per determinare e concordare i requisiti software sotto forma di un elenco da completare.

Successivamente, si passa alla creazione e all'approvazione del progetto, a seguito della quale viene scritta la documentazione che descrive come implementare i requisiti software precedentemente concordati.

Se il progetto è completato, gli sviluppatori si occupano dell'implementazione. Segue la fusione del codice: l'integrazione delle singole parti del progetto, su cui hanno lavorato vari membri del team.

Il passaggio successivo è il test e il debug del prodotto. Gli errori trovati in precedenza vengono corretti qui.

Infine, il programma è installato e supportato. Si tratta di apportare, se necessario, modifiche alla funzionalità ed eliminare gli errori riscontrati.

Il modello a cascata presuppone che sia possibile passare alla fase successiva dello sviluppo in modo strettamente sequenziale, solo dopo il completamento dell'attività precedente. Non è prevista la possibilità di rollback o incoerenza nelle fasi.

Vantaggi e svantaggi

Di tanto in tanto, il modello a cascata viene criticato per la sua mancanza di flessibilità. A molti non piace perché in esso prevale l'obiettivo della gestione del progetto, mentre il rispetto delle scadenze, i costi e la qualità dello sviluppo sono molto più importanti.

Tuttavia, quando si tratta di progetti di grandi dimensioni, la gestione è spesso più importante in essi, poiché ciò riduce i rischi del progetto e migliora la trasparenza nel lavoro.

Nonostante le carenze, la terza versione del PMBOK specifica formalmente solo la metodologia del "modello a cascata". Altre opzioni, inclusa la gestione iterativa del progetto, non sono offerte.

Vantaggi del modello a cascata:

• Lo sviluppo del team è più facile da controllare. Il cliente ha familiarità con ciò su cui stanno attualmente lavorando i programmatori, può modificare le scadenze e il budget del progetto.
• Il costo di sviluppo è approvato nella prima fase. Dopo aver concordato tutte le fasi di implementazione, il prodotto software viene scritto continuamente.
• Non sono necessari tester esperti. Per la fase di test è possibile utilizzare la documentazione del programma.

Svantaggi del modello a cascata:

• Poiché il test inizia nella fase di completamento dello sviluppo, se viene scoperto un bug, risolverlo costerà di più rispetto alla fase iniziale. Dopotutto, i tester troveranno un errore solo quando lo sviluppatore ha già finito di scrivere il codice e i copywriter: la documentazione.
• Il cliente conosce il prodotto finito dopo che lo sviluppo è stato completato. Di conseguenza, può valutare il prodotto solo quando è quasi completamente pronto. Se non gli piace il risultato, il costo del budget del progetto aumenterà notevolmente a causa della necessità di correzione.
• Maggiore è la documentazione tecnica, maggiore è il tempo necessario per completare il lavoro. Tale documentazione richiede ulteriori modifiche e approvazioni.

"Waterfall" è spesso utilizzato in progetti nel settore medico e aerospaziale, dove esiste già un'ampia base di documenti, sulla base dei quali è possibile elaborare i requisiti per il nuovo software.

Quando si utilizza il modello a cascata, la cosa principale è scrivere requisiti dettagliati. Durante il test, non dovrebbe risultare che c'è un bug da qualche parte che ha un effetto dannoso sull'intero progetto.