Modello a cascata

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.

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.

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

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

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

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

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.

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:
o Analisi dei requisiti: definisce cosa viene richiesto in termine di funzioni, senza
specificare come esse devono essere realizzate
o 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:
o 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:
o Codifica e verifica: scrittura e verifica dei programmi partendo dal progetto
esecutivo e utilizzando le procedure di verifica
o Computer Software Code (CSC): integrazione e verifica delle unità comprese nei
singoli sottosistemi
o Convalida dell’integrazione del CSC
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à

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.

Analisi dei requisiti

Da Wikipedia, l'enciclopedia libera.

In ingegneria del software, l'analisi dei requisiti (talvolta detta semplicemente analisi) rappresenta
una delle prime fasi nel ciclo di vita di un prodotto software; scopo generale dell'analisi è stabilire
che cosa il sistema in questione deve fare (mentre le decisioni sul come sono rimandate alla
successiva fase di progettazione).

L'analisi dei requisiti avviene normalmente come negoziazione fra individui legati allo sviluppo
(analisti) e i clienti, oppure (nel caso di pacchetti software pensati per la grande distribuzione) fra
analisti e responsabili del marketing. Tale dialogo è tutt'altro che semplice: gli analisti possono
avere difficoltà a comprendere il linguaggio e il contesto culturale del cliente, e viceversa; e lo
stesso cliente potrebbe aver difficoltà a mettere a fuoco i propri reali bisogni e di conseguenza le
richieste o le proposte da mettere sul tavolo della discussione. Proprio a causa di queste difficoltà, i
modelli di ciclo di vita del software moderni hanno abbandonato l'assunzione che sia possibile
identificare i requisiti di un sistema software a priori, e tendono a privilegiare approcci iterativi in
cui i requisiti vengono esplicitati gradualmente, per esempio coinvolgendo l'utente nella prova di
prototipi e rilasci parziali del sistema in corso di sviluppo.

Il documento principale prodotto dall'analisi dei requisiti è la specifica dei requisiti; se la

metodologia e il modello di ciclo di vita del software utilizzati lo prevedono, essa può addirittura
portare già alla stesura del manuale d'uso del prodotto da sviluppare.
L'analisi dei requisiti è spesso accompagnata da altre attività di analisi come l'analisi del dominio o
l'analisi dei costi e benefici

Progettazione (ingegneria del software)

Da Wikipedia, l'enciclopedia libera.

(Reindirizzamento da Progetto (ingegneria del software))

In ingegneria del software, la progettazione (talvolta detta anche progetto o disegno, dall'inglese
design) è una fase del ciclo di vita del software. Sulla base della specifica dei requisiti prodotta
dall'analisi, il progetto definisce come tali requisiti saranno soddisfatti, entrando nel merito della
struttura che dovrà essere data al sistema software che deve essere realizzato.

La progettazione rimane comunque una fase distinta dalla programmazione o codifica, che
corrisponde alla traduzione in un particolare linguaggio di programmazione delle decisioni prese in
sede di progettazione.

Le distinzioni fra le attività fin qui menzionate non sono sempre chiare come vorrebbero le teorie
classiche dell'ingegneria del software. La progettazione, in particolare, può descrivere il
funzionamento interno di un sistema a diversi livelli di dettaglio, ciascuno dei quali si colloca in una
posizione intermedia fra analisi e codifica.

Normalmente si intende con progettazione dell'architettura (o progettazione architetturale) la

progettazione "ad altissimo livello", in cui si definisce solo la struttura complessiva del sistema in
termini dei principali moduli di cui esso è composto e delle relazioni macroscopiche fra di essi. A
questo livello di progettazione appartengono formule come client-server o three-tier, o più in
generale decisioni sull'uso di particolari architetture hardware, sistemi operativi, DBMS, protocolli
di rete, e così via.

Una livello intermedio di dettaglio definisce ancora la scomposizione del sistema in moduli, ma
questa volta con riferimento più o meno esplicito alle modalità di scomposizione offerte dal
particolare linguaggio di programmazione con cui avverrà lo sviluppo; per esempio, in un
progettazione condotta con tecnologie a oggetti, il progetto potrebbe descrivere il sistema in termini
delle principali classi e delle loro interrelazioni.

Il progetto di dettaglio, infine, rappresenta una descrizione del sistema molto vicina alla codifica,
ovvero che la vincola in maniera sostanziale (per esempio, descrivendo non solo le classi in astratto
ma anche i loro attributi e metodi, con relativi tipi e "firma".

A causa della natura "impalpabile" del software, e a seconda degli strumenti che si utilizzano nel
processo, il confine fra progettazione e codifica può essere anche praticamente impossibile da
identificare. Per esempio, alcuni strumenti CASE sono in grado di generare codice a partire da
diagrammi UML che descrivano graficamente la struttura di un sistema software.

Specifica dei requisiti

Le specifiche dei requisiti software possono essere un documento a se stante o parte di un
documento più ampio (es. contenente anche requisiti per hardware o servizi o contenente anche una
progettazione di massima). Il documento può essere:

1. Preparato in fase di negoziazione contrattuale per rispondere ad una richiesta di offerta in

cui sono stati forniti i Requisiti Utente, oppure fornito dal Cliente come parte di Capitolato
Tecnico che accompagna la richiesta di offerta.
2. Preparato in seguito alla stipula del contratto quando i requisiti contrattuali non sono
adeguatamente dettagliati. In questo caso bisogna prevedere nel contratto un'attività di
riesame congiunto con il committente e in caso di impatti economici rilevanti, di rinegoziare
il contratto. Se non è possibile rinegoziare è necessario prevedere meccanismi di gestione
dei rischi.

 Formato: Cartaceo / Digitale

 Supporto di Comunicazione: Cartaceo / Digitale
 Standard di Presentazione: Testuale
 Dimensioni: variabile

Analisi del dominio

In ingegneria del software, l'analisi del dominio (domain analysis nella letteratura di lingua
inglese) è una delle attività che costituiscono l'analisi e concorrono alla definizione delle specifiche
di un sistema o applicazione software o, più spesso, di una intera famiglia di applicazioni.

Lo scopo dell'analisi del dominio è quello di comprendere a fondo i concetti, le dinamiche, le regole
generali che definiscono il dominio applicativo in cui il sistema software dovrà essere impiegato,
ovvero il contesto in cui il software dovrà agire. Normalmente, l'analisi del dominio precede
l'analisi dei requisiti, poiché solo avendo compreso a fondo il contesto in cui il sistema software
dovrà operare è possibile stabilire quali siano le caratteristiche che il sistema deve esibire per
integrarsi in quel contesto nel modo più efficace. L'analisi del dominio, come le altre fasi
dell'analisi, deve quindi essere condotta congiuntamente da analisti ed esperti del dominio (per
esempio, i clienti stessi che commissionano lo sviluppo del sistema, o i probabili utenti del sistema
stesso).

L'analisi del dominio è spesso associata alla ingegnerizzazione del dominio (domain engineering):
l'introduzione di un sistema software in un certo contesto produttivo potrebbe infatti portare alla
ridefinizione o alla riorganizzazione di alcuni aspetti del contesto stesso, per cui lo stesso "dominio"
potrebbe essere modificato. Per esempio, una procedura d'ufficio strutturata in un certo modo per
essere applicabile da impiegati umani potrebbe essere ripensata in modo da sfruttare i punti di forza
dell'automazione impiegando dei software di produttività personale.

L'ingegneria del software moderna attribuisce una grande importanza all'analisi del dominio anche
rispetto all'obiettivo del massimo riuso del software. La comprensione del dominio può infatti
portare alla realizzazione di moduli software che incorporano la conoscenza acquisita durante
l'analisi, e che quindi potranno probabilmente essere riutilizzati in diverse applicazioni afferenti allo
stesso dominio applicativo. Essi potrebbero per esempio essere raccolti in un framework di
componenti riusabili.

Le tecniche di analisi orientata agli oggetti sono normalmente considerate fra le più adatte all'analisi
del dominio. Concetti come quello di classe, ereditarietà, metodo e attributo si prestano a essere
usati durante il dialogo fra analisti ed esperti del dominio (essendo comprensibili anche ai non
tecnici) e al contempo forniscono un modello già adatto a essere raffinato in un progetto. L'analisi a
oggetti del dominio utilizzerà quasi certamente la notazione standard UML o suoi derivati.

Modello evolutivo
Da Wikipedia, l'enciclopedia libera.

Il modello evolutivo è uno dei modelli del ciclo di vita del software che cerca di superare i limiti
principali del modello a cascata.

Con il fallimento della prima versione software, infatti, occorre rifare buona parte dell’applicazione.
In tal modo conviene considerare la prima versione come un throw-away (un prototipo
"cestinabile") che è valido finché non fornisce al progettista un feed-back sufficiente.

La versione iniziale o prototipo viene utilizzata temporaneamente dopo di che viene cestinata e si
procede a produrre l'applicazione vera e propria. La seconda versione può essere sviluppata
seguendo il modello cascata.

È un modello costituito, quindi, da poche fasi che si ripetono

 Costruisci qualcosa
 Consegnalo all’utente
 Ottieni delle valutazioni
 Modifica il progetto in funzione delle valutazioni

Questo approccio fornisce solo una soluzione parziale ai problemi del modello a cascata per cui
elimina gli errori nei requisiti ma non riduce la distanza temporale per il completamento del ciclo di
sviluppo.

Per tale motivo il modello si è evoluto nel modello incrementale perché alcune fasi possono essere
rimandate in modo da produrre comunque un insieme utile di funzionalità. In tal modo si forniscono
al cliente una serie di prototipi successivi e si integrano i feedback in maniera incrementale. Questa
fase viene detta modello di sviluppo e rilascio incrementale.

Il modello si può complicare ulteriormente per cui le fasi possono anche essere concorrenti, ad
esempio mentre si integra una versione, già si lavora sul design di quella successiva. I tempi si
riducono di parecchio ma i rischi sono tantissimi.

Il problema maggiore di questo modello è che si rischia di essere indisciplinati. E’ necessario far
uso di standard di processo e non perdere i punti migliori del modello a cascata. In tal modo
scompare la fase di manutenzione e si parla di evoluzione continua. A volte il modello throw-away
si può sostituire con un prototipo evolutivo che poco per volta si trasforma nell’applicazione
finale. Il modello comunque è molto utile per verificare alcune componenti del software come le
interfacce, infatti in questo modo si possono creare interfacce adatte all’utente e ben testate.