Modello a cascata
Da Wikipedia, l'enciclopedia libera.
Indice |
[modifica] Introduzione
Il modello a cascata o ciclo di vita a cascata (waterfall model o waterfall lifecycle in inglese) è un modello di ciclo di vita del software (ovvero di processo software) secondo cui la realizzazione di un prodotto software consta di una sequenza di fasi strutturata in analisi dei requisiti, progetto, implementazione, testing (validazione), integrazione e manutenzione. Ciascuna di queste fasi produce un ben preciso output che viene utilizzato come input per la fase successiva (da cui la metafora della cascata).
Il ciclo di vita a cascata fu il primo modello di ciclo di vita del software. La sua teorizzazione rappresenta innanzitutto un importante mutamento di prospettiva nella pratica dello sviluppo del software, che viene per la prima volta concepita come processo industriale (con le relative necessità di documentazione e controllo) anziché come attività "artigianale" (il cosiddetto approccio code and fix, che si potrebbe tradurre in italiano come programmazione per tentativi ed errori). Il ciclo di vita a cascata ebbe un enorme successo negli anni '70 ed è quello che ancora oggi viene più spesso associato alla programmazione procedurale e strutturata.
A partire almeno dagli anni '80 il modello è stato soggetto a profonde critiche e revisioni, soprattutto dovute all'evoluzione del software stesso e dei linguaggi di programmazione. Benché gran parte delle critiche a questo modello siano oggi universalmente accettate, il ciclo di vita a cascata continua a rimanere un punto di riferimento importante, in sostanza un modello "canonico" rispetto al quale vengono spesso descritte le "variazioni" moderne; ed è spesso il primo modello di sviluppo software che si insegna agli studenti.
[modifica] Definizione
I caposaldi sono:
- il processo di sviluppo è diviso in fasi sequenziali;
- ogni fase produce un output che è usato come input per la fase successiva;
- ogni fase del processo viene documentata.
Il modello a cascata tradizionale prevede le seguenti fasi:
- studio di fattibilità: ha lo scopo di determinare se intraprendere lo sviluppo del sistema;
- analisi dei requisiti: ha lo scopo di determinare cosa farà il sistema; essa comprende, o è preceduta da, una analisi di fattibilità, in cui si stabilisce se vale la pena (da un punto di vista tecnico ed economico) realizzare il sistema del quale si vanno definendo i requisiti;
- progetto: ha lo scopo di determinare come il sistema farà quanto stabilito nella prima fase, e in particolare la sua suddivisione in moduli e le relazioni fra di essi;
- implementazione, o codifica, o sviluppo: creazione dei moduli con un linguaggio di programmazione;
- testing (o test di modulo): esecuzione di prove per verificare la correttezza dell'implementazione dei singoli moduli;
- integrazione (o test di integrazione): esecuzione di prove per verificare la correttezza del funzionamento complessivo del sistema;
- manutenzione: segue la consegna o delivery del prodotto al cliente, e comprende tutte le attività volte a migliorare, estendere e correggere il sistema nel tempo.
Nel contesto di una specifica organizzazione, il modello a cascata può essere ridefinito con varianti specifiche. Inoltre, un'organizzazione può formalizzare ulteriormente il processo definendo standard e imponendo vincoli per quanto riguarda la natura, il formato, la struttura e/o i contenuti dei documenti prodotti nelle varie fasi (i cosiddetti deliverable, consegnabili), tipicamente allo scopo di consentire un controllo più rigoroso sullo stato di avanzamento del progetto e sulla qualità del lavoro svolto.
[modifica] Studio di fattibilità
E’ la prima fase. Scopo
- Decidere se debba essere intrapreso un nuovo sviluppo.
Attori coinvolti
- Cliente/Committente
- Organizzazione aziendale
Output
- Un documento che presenti diversi scenari e soluzioni insieme ad una discussione dei compromessi in termini di costi previsti e benefici.
Svolgimento
- Interazione tra gli attori
- Ricerca delle soluzioni esistenti
Problemi principali
- Analisi spesso svolta sotto pressione e in fretta
- Analisi dei costi a volte imperfetta con continui rifacimenti
- Decisioni premature che ostacolano lo sviluppo successivo
[modifica] Analisi dei requisiti
Input
- Il documento di studio di fattibilità
Scopo
- Identificazione e descrizione dei requisiti, ossia delle caratteristiche del sistema
Attori coinvolti
- Cliente/Committente
- Sviluppatori
- Organizzazione aziendale
Output
- Un documento che descrive le caratteristiche del sistema e che colga le esigenze dell’utente ma sia anche esaustivo per il progettista. Tale documento, per mettere d’accordo le parti, deve essere facilmente comprensibile, preciso, completo, coerente e non ambiguo, inoltre facilmente modificabile;
- Manuale utente: in alcuni casi può essere utile una versione preliminare in cui si spiega come l’utente interagirà con il sistema;
- Piano di test: non è indispensabile, ma si può decidere in questa fase insieme all’utente.
Svolgimento
- Interazione tra gli attori
- Più il sistema è innovativo più è necessario interagire
- La documentazione va descritta secondo degli standard e delle notazioni specifici
Problemi principali
- Assenza di linguaggio comune tra gli attori
- Requisiti spesso poco chiari
- Impossibilità di considerare tutti i requisiti e di produrre un lavoro completo
[modifica] Progettazione
Input
- Il documento di specifica dei requisiti
Scopo
- Definire l’architettura del sistema
Attori
- Sviluppatori
Output
- Definizione della struttura di massima (architettura di alto livello)
- Definizione delle caratteristiche dei singoli componenti (moduli)
Svolgimento
- Individuazione dei componenti necessari e delle loro caratteristiche
Problemi
- Si devono prendere molte decisioni
- Non tutte le strutture sono uguali
- Non sempre le scelte sono ben definite
[modifica] Codifica e test di modulo
Input
- I documenti di progetto
Scopo
- Implementare i moduli
Attori
- Sviluppatori
Output
- Moduli implementati
Svolgimento
- Scrittura del codice
- Test di modulo
- Controllo di aderenza agli standard
Problemi
- Scrittura del codice
[modifica] Integrazione e test di sistema
Input
- I moduli codificati
Scopo
- Controllare che i moduli presi uno a uno funzionino
- Controllare che una volta messi assieme i moduli continuino a funzionare
Attori
- Sviluppatori
Output
- Il sistema funzionante
- Tecniche di verifica e validazione (alpha test)
Problemi
- Diversi tipi di problemi soprattutto connessi ad una cattiva analisi dei requisiti
[modifica] Manutenzione
- Tutto ciò che accade dal momento della consegna del sistema alla sua dismissione
- Si verifica il software da parte degli utenti (beta test)
- E’ una fase molto lunga
Così semplificato, il ciclo di vita classico può essere rappresentato come:
- Analisi
- Design
- Codifica
- Integrazione
- Test
- Rilascio
da cui il richiamo alla cascata che troviamo nel nome.
[modifica] Esempio
A titolo di esempio, consideriamo il ciclo di vita definito con le MIL-STD-2167 da parte dell’autorevole DoD (Department of Defense, il Ministero della Difesa Americano) per il linguaggio ADA (altro prodotto del DoD).
Le MIL-STD-2167 dividono il ciclo di vita del software nelle seguenti 6 macro attività:
- ANALISI:
- Analisi dei requisiti: definisce cosa viene richiesto in termine di funzioni, senza specificare come esse devono essere realizzate
- Progetto preliminare: segue i requisiti, sviluppa un approccio al software che comprende anche modelli matematici, diagrammi di flusso funzionali e procedure di collaudo. In questa fase si definiscono la struttura generale e le operazioni del sistema, indicando anche le relazioni tra i principali blocchi funzionali (moduli)
- PROGETTAZIONE:
- Progetto esecutivo: effettiva scomposizione gerarchica e dettagliata di tali moduli; questa scomposizione continua fino a che un’ulteriore scomposizione porterebbe al codice del programma
- IMPLEMENTAZIONE:
- Codifica e verifica: scrittura e verifica dei programmi partendo dal progetto esecutivo e utilizzando le procedure di verifica
- Computer Software Code (CSC): integrazione e verifica delle unità comprese nei singoli sottosistemi
- Convalida dell’integrazione del CSC
[modifica] Pregi
Il modello ha giocato un ruolo importante nello sviluppo del software per superare i limiti del processo del “code and fix” e infine ha fissato due concetti:
- Il processo di sviluppo del software deve essere soggetto a disciplina e pianificazione;
- L’implementazione del prodotto deve essere rimandata fino a quando non sono perfettamente chiari gli obiettivi.
Il maggior pregio di questo metodo di lavoro è certamente la semplificazione del controllo dell’andamento del progetto tramite la suddivisione del ciclo di vita in fasi successive ben definite. Le diverse metodologie che adottano questo ciclo di vita si distinguono essenzialmente per la suddivisione e specificazione delle fasi in sottofasi più elementari, nella definizione di standard di documentazione e nella individuazione di momenti di verifica al termine di ciascuna attività (milestone). Per ottimizzare il ciclo di vita, la scomposizione delle fasi in sottofasi persegue due obiettivi:
- assegnare a ciascuna fase la soluzione di problematiche specifiche
- rendere, per quanto possibile, le fasi indipendenti allo scopo di poterne parallelizzare le attività
[modifica] Difetti
Benché l’adozione di questi principi appaia estremamente produttiva, la loro applicazione pratica ha come effetto collaterale, soprattutto per i progetti di grandi dimensioni, un pericoloso scollamento fra le diverse attività, sia per le difficoltà di coordinamento che per la difformità delle metodologie e dei formalismi specialistici adottati. Ad esempio, normalmente l’individuazione delle strutture dati e delle funzionalità del sistema sono affrontate con metodologie diverse e, soprattutto per i progetti di grandi dimensioni, contemporaneamente e separatamente da gruppi di lavoro differenti. Nel primo caso i risultati sono formalizzati con uno Schema Entità-Relazione (ER o Entity-Relationship diagram nella dizione anglosassone) nel secondo con un metodo di scomposizione funzionale. Solo quando queste due attività terminano viene avviata una ulteriore attività di armonizzazione dei rispettivi risultati.
Un ulteriore problema di questa impostazione deriva dalla necessità di terminare completamente tutta la fase di analisi dei requisiti e progetto dell’applicazione per cominciare la programmazione e quindi verificarne sul campo le conclusioni.
Il modello, quindi, è una semplificazione della realtà che non trova piena applicazione in quanto vanno rispettati tre principi:
- Linearità: spesso si hanno cicli di feedback (il caso dell’alpha e del beta testing) per la correzione degli errori. Tale feedback, purtroppo, deve essere lineare e, quindi, non si possono effettuare salti a ritroso ma vanno ripercorse tutte le fasi in maniera lineare;
- Rigidità: ogni fase viene congelata quando si passa alla fase successiva per cui non è possibile un’interazione tra clienti e sviluppatori durante il ciclo di vita dopo la parte iniziale;
- Monoliticità: tutto il modello è orientato alla singola data di rilascio che spesso si pone a mesi o anni dopo l’inizio della prima fase per cui se vengono commessi eventuali errori o cambiano i requisiti, questi verranno implementati dopo parecchio tempo e comunque alla fase di consegna seguirà subito un altro adattamento perché il software sarà già obsoleto.
I maggiori problemi sono i seguenti:
- È difficile stimare le risorse e i costi in maniera accurata finché non sia stata svolta almeno la prima fase di analisi;
- La specifica dei requisiti produce un documento scritto che vincola il prodotto da sviluppare e ciò non sempre soddisfa le esigenze del cliente perché si tratta pur sempre di specifiche basate su un documento inanimato che non sempre aiuta nel definire le esigenze, che, invece, appaiono subito chiare dopo il primo rilascio del software, inoltre tale documento deve essere completo e chiaro prima di procedere allo sviluppo, ma non sempre ciò è possibile;
- L’utente spesso non conosce tutti i requisiti dell’applicazione perché non può conoscerli, motivo per cui non sempre il documento dei requisiti è completo e, quindi, si ha un passaggio alla fase successiva con documentazione poco chiara;
- Il modello obbliga a usare standard pesantemente basati sulla produzione di una data documentazione in determinati momenti per cui il lavoro rischia di essere burocratizzato.
Si comprende come gli alti costi del software siano proprio dovuti al modello a cascata a causa proprio delle specifiche poco complete e ai molti interventi successivi per introdurre funzionalità non previste in partenza. Capita, quindi, che le pecche del modello vadano a ricadere sulla manutenzione che, quindi fa lievitare i prezzi o, al contrario, si opera con una manutenzione sommaria che produce un software con un’implementazione che diverge dalle specifiche dei requisiti.
