MODELLI DI PROGETTAZIONE DEL SOFTWARE
4.2 Modello a cascata
Il modello a cascata (waterfall model) è un modello prescrittivo che prevede una sequenza di fasi definite per realizzare un prodotto software. Queste metodologie di sviluppo vengono chiamate prescrittive perché stabiliscono una serie di elementi del processo: attività strutturali, azioni di ingegneria, valutazione della qualità e meccanismi di controllo delle modifiche, definendo il modo in cui questi
diversi momenti vengono correlati fra loro (Alshamrani, Bahattab, 2015).
Il modello a cascata è stato adottato all’inizio degli anni ’70 come primo metodo di lavoro strutturato per diminuire i costi di sviluppo, rispetto alle metodologie precedenti. Il modello a cascata è il processo di sviluppo software più diffuso nel mondo e si rifà al processo della catena di montaggio tipica della produzione industriale. Il modello a cascata presenta un approccio sistematico e strettamente sequenziale allo sviluppo del software, in cui ciascuna fase produce un preciso output (deliverable) che diventa input per la fase successiva. L’elemento principale di questo modello è la sequenza rigida delle fasi, che comporta la completa assenza di sovrapposizioni e l’assenza di ricicli. Un’ulteriore caratteristica è la convinzione che sia possibile progettare correttamente l’applicazione sin da subito, confidando sulla stabilità dei requisiti. Il modello a cascata mette in evidenza quattro fasi (figura 4) che si ritrovano in tutte le metodologie successive. Figura 4. Rappresentazione delle fasi del modello a cascata (waterfall model)
requisiti che il software deve soddisfare. Vengono identificati i requisiti generali dell’intero sistema (hardware, software di base, fonti di informazioni, riferimenti funzionali) e i requisiti di dettaglio che dovranno essere realizzati nel prodotto software. Tutti questi elementi sono contenuti in un documento che deve contenere tutte le informazioni perché omettere qualche elemento potrebbe compromettere il risultato dell’intero progetto.
La fase successiva determina come verrà sviluppato il sistema secondo quanto stabilito nell’analisi dei requisiti, definendo l’architettura (hardware e software) del sistema e identificando tutti i componenti da realizzare o modificare. Completata questa seconda fase si passa all’implementazione del sistema.
Infine, si verifica la correttezza dell’implementazione del sistema e ci si pone la domanda se le specifiche sono state soddisfatte. Un ulteriore aspetto del collaudo è l’attività di integrazione e di testing di tutto quanto è stato sviluppato.
Il modello a cascata è una metodologia ben strutturato che offre il maggior vantaggio quando i requisiti sono definiti e ben chiari fin dall’inizio del progetto. Inoltre, è utilizzabile quando la tecnologia è ben nota, perché se utilizzata in contesti dinamici, destinati a cambiare rapidamente e di cui non si ha una buona conoscenza, si rischia di dover riscrivere alcune parti perché le fasi rigide non prevedono cambiamenti in corso di realizzazione.
Il modello a cascata ha contribuito a definire molti concetti fondamentali, e ha rappresentato un punto di partenza per l’evoluzione della metodologie di sviluppo software, che da quel momento viene considerata come un processo industriale (con le relative necessità di documentazione e controllo) e non più come un attività artigianale (il cosiddetto approccio code and fix).
La maggiore difficoltà di applicazione di questo modello è determinata dalla rigidità delle diverse fasi che rende complicato rispondere alle richieste di modifiche non programmate da parte del cliente. Per queste ragioni il modello a cascata può essere adottato solo se i requisiti sono definiti chiaramente all’inizio e non cambiano durante lo sviluppo. Infatti, qualsiasi modifica dei requisiti porta a ritardi nelle fasi di rilascio e a un aumento esponenziale dei costi di sviluppo.
Inoltre, il time‐to‐market è un ulteriore punto a sfavore nell’uso di questa metodologia perché il tempo che può passare dalla commissione del progetto alla consegna al cliente potrebbe durare anche anni, in questo caso non potendo apportare delle correzione in corso d’opera il prodotto realizzato risulterebbe tecnologicamente obsoleto.
4.3 Processo RUP (Rational Unified Process)
Il Rational Unified Process (RUP) è un processo di sviluppo, o meglio un framework di processo, di tipo iterativo ed incrementale. Il RUP si fonda su delle best practices di sviluppo, cioè utilizzando sistemi software di base largamente utilizzati nell’industria. Il processo viene controllato in tutte le sue fasi e pertanto incoraggia il controllo della qualità e la gestione del rischio. Il RUP appartiene al ciclo di vita del software iterativo e incrementale, in modo tale da assecondare la complessità dello sviluppo e permettere la flessibilità necessaria per gestire i cambiamenti nei requisiti (Kruchten, 2000).
Il RUP si compone di più fasi e prevede un iter incrementale. La prima fase è l’inception che permette la verifica della fattibilità tecnica ed economica dell’intervento. Inoltre, in questa prima fase vengono definiti i business case per individuare i criteri di successo, la gestione dei rischi, la stima delle risorse necessarie, la pianificazione e la schedulazione degli obiettivi del progetto.
La seconda fase è l’elaboration che definisce in dettaglio le caratteristiche funzionali, strutturali e tecniche del sistema. Tutte le decisioni architetturali devono essere prese avendo una conoscenza dell’intero sistema e questo implica che la descrizione della maggior parte dei requisiti sia contenuta e documentata all’interno del sistema.
La fase successiva è la construction, che produce una prima versione del sistema pronta per i test di accettazione. In questa fase vengono definiti i requisiti rimanenti e i criteri di accettazione e verifica del software.
La fase finale è la transition che produce una versione definitiva del sistema. In questa fase viene rilasciata una prima versione beta sulla quale vengono corretti