Il modello Waterfall

Schema generale

Il modello Waterfall è il più noto modello di processo di produzione del software conosciuto. Esso è non solo largamente utilizzato ancora oggi, nonostante lo sviluppo di modelli alternativi, ovvero i cosiddetti processi “agili”. Anche per essi resta un riferimento (anche se da cambiare o migliorare) perché indica, con grande chiarezza, tutte le fasi principali dello sviluppo del software.

Questo modello si basa su un approccio che prevede uno sviluppo “a cascata” in cui definizione e produzione del software sono unite tra loro in un insieme di attività collegate^[2] per produrre una applicazione completa:

• Customer request (CR): si raccolgono i requisiti del prodotto, tramite interazione col committente;

• Analisi funzionale (AF): i requisiti vengono validati tecnicamente (fattibilità) e poi formalizzati in specifiche funzionali, che vengono apprrovate dal cliente; sono a tutti gli effetti il “contratto” che indica ciò che verrà effettivamente realizzato;

• Analisi tecnica (TA): si progetta il software e si definiscono le specifiche tecniche.

• Sviluppo (DEV): si sviluppa il software, corrisponde alle attività del paragrafo precedente.

• Test (TEST): il test (da non confondere col test in sviluppo) viene effettuato da un team di testers – QA (Quality Assurance – indipendente dal team di sviluppo) che riporta le anomalie al team di sviluppo. Test e sviluppo sono tra loro collegati ma indipendenti.

• Collaudo (V&D Validation&Delivery): il team di QA o più spesso un team gestito dal committente finale collauda il software verificando solo i requisiti iniziali. Prevede una approvazione finale, chiamata UAT (User Acceptance Test).

• Rilascio (DEPLOY): rilascio del software.

In questo specchietto vediamo meglio le figure professionali coinvolte.

	Functional analyst	Architect / technical lead	Developer	Tester / QA	Sistemista / IT
CR	x	x
AF	x
TA		x
DEV		x	x
TEST	x		x	x	x
V&D	x			x	x
DEPLOY		x	x		x

Esistono diverse varianti del Waterfall, dove alcune fasi sono eliminate o più spesso altre fasi sono aggiunte, quindi questo modello indicato va visto come un tipo di Waterfall generale. In qualsiasi caso Waterfall prevede tante fasi di lavorazione sequenziali e che prevedono in qualsiasi variante che il software, prima di essere rilasciato debba essere progettato, sviluppato, testato, e collaudato. 

Infrastruttura e ambienti

Waterfall per la sua complessità richiede una infrastruttura adeguata. Per infrastruttura si intende l’insieme di risorse, hw e sw, messe a disposizione per lo sviluppo, il test ed il rilascio e che permettano quindi a tutti i soggetti coinvolti di lavorare in modo efficace.

Essa comprende almeno le seguenti risorse:

– IDE di sviluppo integrato che consentano di sviluppare codice, eseguire code analysis, debugging, unit testing, ecc.;

– un sistema di gestione di sorgenti, configurazioni, asset e librerie che consenta di gestire ogni elemento del prodotto software;

– un numero di ambienti adeguato alle necessità delle varie fasi di sviluppo.

Gli ambienti e i set di dati sono strettamente correlati alle fasi di sviluppo. 

Di norma in un progetto waterfall sono presenti come minimo un ambiente di sviluppo ed uno di test, oltre all’ambiente finale di esecuzione, detto di produzione. E’ comunque quasi sempre presente anche un ambiente di collaudo.^[3]

L’ambiente di sviluppo è quello dove gli sviluppatori realizzano il software e lo testano internamente. In questo ambiente il runtime contiene si dati, variabili, immagini, input ed output che però non sono reali ma solo utili allo sviluppo. Ad esempio una applicazione che gestisce il registro elettronico conterrà classi ed alunni fittizi.

L’ambiente di test, dove i tester possono testare il software in modo indipendente dagli sviluppatori, prevede ancora dati fittizi ma molto più verosimili: alunni e classi devono assomigliare a quelli di una scuola vera. 

L’ambiente di collaudo, dove il team di collaudo testa il prodotto finale, prevede di norma una copia (ridotta) dei dati reali. In questo caso i dati di setup (gli alunni e le classi) sono presi da una scuola vera, ed elaborati in modo realistico da utenti che spesso sono anche utenti finali.

L’ambiente di produzione resta infine l’ambito finale verso cui il prodotto si rivolge, e che spiega il perché dell’esistenza di tutti gli ambienti precedenti, ovvero fare in modo di scoprire e correggere anomalie prima che queste si verifichino nell’ambiente di utilizzo effettivo.

I cicli di rilascio

Se è ovvio che i gli ambienti di base hanno differenti database, files, immagini ecc, è meno ovvio capire che in ogni ambiente girano versioni diverse del software.

Il software in sviluppo, oggetto delle ultime migliorie, è visibile al solo team di sviluppo fino a quando non è funzionante “abbastanza” (in gergo si dice “maturo“) per essere integrato nella versione di test. Il software di sviluppo viene chiamato in gergo “alpha” o “unstable“, quando viene rilasciato per il test, viene chiamato “stable” o “beta“. La beta viene testata da un team di test e vengono segnalati i bug agli sviluppatori che producono prima una nuova alpha, e quando pronta una nuova beta, in modo ciclico, fino a quando il team di QA non stabilisce che la qualità del prodotto è sufficiente rispetto ai requisiti richiesti. E’ bene specificare fin da subito che non esiste il software perfetto, ed anzi l’ingegneria del software ha ormai stabilito da tempo che non è nemmeno possibile avere un software perfetto a causa della sua complessità. Quello di cui ci si accontenta è quindi stabilire un numero di difetti sufficientemente piccolo da rendere il prodotto usabile in modo efficace (il cosiddetto “good enough“).

Una volta che il software è stato testato e ritenuto sufficientemente funzionante, esso diventa candidato per un rilascio. La beta viene promossa quindi a RC (“release candidate“) e sottoposta ad ambiente di collaudo, ovvero prima di essere rilasciata viene collegata ad una copia del database di produzione (o comunque un database con dati reali) e a configurazioni identiche a quelle di produzione, files analoghi, ecc. Viene quindi effettuato un test di collaudo (detto anche “smoke test”) per verificare che la nuova versione si adatti ai dati e che risponda ad un insieme di requisiti funzionali minimi. Ad esempio nel registro elettronico vengono fatti collaudi su presenze, voti, pagelle ecc. ma senza ripetere il test estensivo del gruppo di test, perché sarebbe una inutile (e costosa) ripetzione.

Se tutto ok, è pronta per l’installazione in ambiente di produzione, detta rilascio con una versione detta “di produzione”.

Ad ogni fase di solito corrisponde ad un ambiente dedicato.

Il supporto

Una volta che il software viene rilasciato, comincia la fase di supporto. Essa si compone di norma di tre attività: la prima è la verifica di eventuali anomalie (bug) che se riscontrate portano ad una eventuale loro correzione, test, collaudo e un nuovo rilascio. Questa operazione si chiama manutenzione correttiva, e comporta a nuove alpha, beta, RC e di produzione.

La seconda è lo sviluppo di nuove funzionalità, che anch’esse come visto richiedono analisi, progettazione, sviluppo, test, collaudo ed un nuovo rilascio. Essa è chiamata manutenzione evolutiva.

La terza è la manutenzione adattativa, che consiste nella modifica del software per adeguarsi a contesti ed ambienti che possono cambiare nel tempo. Ad esempio una nuova normativa potrebbe richiedere di adeguare il software a rispettarla.

Nella stragrande maggioranza dei progetti la fase di supporto è quella più lunga, costosa e onerosa. 

Note e considerazioni

Riprendiamo lo schema del modello Waterfall e proviamo ad rivederne alcune delle caratteristiche.

E’ un modello che si basa sulla certezza: si sa in anticipo che tempi ci saranno, chi fa cosa e quando, qual è il percorso critico, quali sono i rischi, quali le strategie per porvi rimedio. Ha inoltre altre peculiarità non sempre evidenti:

– Non si cambia idea. I requisiti del software devono essere noti a priori, ed una volta stabiliti all’inizio, non possono più cambiare in tutto il resto del progetto. 

– Non si fanno errori di stima. Le risorse sono preallocate, quindi un errore di calcolo, specie nelle fasi iniziali, ad esempio perchè è richiesto più tempo per l’analisi tecnica fa slittare le attività successive, e quindi questo può avere un enorme impatto sulle risorse coinvolte (che magari hanno altri progetti da fare). 

– Non si fanno errori di progettazione. I vincoli funzionali e soprattutto quelli tecnici, una volta stabiliti, diventano vincolanti. Un errore può far saltare l’intero progetto.

Il modello Waterfall ha molte similitudini col modello industriale “fordista“, ovvero basato sulla “catena di montaggio”, perchè parte dal presupposto di avere i team disponibili e dedicati a svolgere la parte di loro competenza e poi fare altro. Ogni team che lavora su ogni fase lavora su un progetto alla volta, e una volta terminato, passa al progetto successivo, quindi i programmatori nel Waterfall sono coinvolti solo nella fase di sviluppo e parzialmente nei rilasci, ma poi passano alla fase di sviluppo di un altro progetto Waterfall. Il modello è efficace soprattutto quando i requisiti richiesti sono stabili, quando si conosce perfettamente la tipologia di software che si vuole produrre e quindi si sa bene quanto tempo ci si metterà, quanto costerà, che problemi potrà dare, ecc.

Il rischio maggiore nel Waterfall sta nella definizione dei requisiti. Un errore in questa fase impatta tutte le altre fasi.

Siccome la definizione dei requisiti può spesso portare ad una incomprensione tra committente e cliente, in alcune situazioni per evitare il rischio che le specifiche siano sbagliate, il Waterfall introduce un “mini-waterfall”, ovvero viene prodotto in tempi brevi un prototipo funzionante che viene mostrato al committente, secondo un modello chiamato “prototipazione rapida“. Il prototipo non è realizzato con criteri di qualità ma solo per far vedere al committente se è quello che desiderava. In genere questa variante richiede costi maggiori ma riduce i rischi specie per prodotti nuovi. E’ utilizzato ad esempio per nuovi sistemi operativi, nuove app, e in industrie dove la tecnologia è ancora nuova.

Un’altra soluzione Un modello alternativo è quello incrementale. In questo modello il software viene scomposto in moduli mentre viene prevista solo una fase iniziale di definizione dell’architettura generale di prodotto. A questo punto per ogni modulo si ripete il metodo waterfall, dove il cliente viene coinvolto nella definizione dei requisiti, la produzione ed infine nell’approvazione del rilascio. Dopodichè si ricomincia col modulo successivo. Questo modello richiede un coinvolgimento maggiore del cliente ed ha costi superiori perchè è necessario non solo ripetere tutte le fasi ma anche perchè necessaria una fase ulteriore di integrazione con il software già prodotto. 

In generale Waterfall è un modello che favorisce la grande industria. Una grande società di software si basa su enomi investimenti di conoscenza, sia sotto forma di competenze, sia sotto forma di software e brevetti sviluppati. Deve quindi minimizzare il rischio che il software non sia ben progettato, Questo significa che la grande industria sfrutta le proprie competenze, anche a livello di marketing, per convincere i propri clienti nelle proprie scelte su “cosa sarà fatto” e proporre un proprio prodotto generale, e non un prodotto specifico per quel cliente.

L’obiettivo, che minimizza i rischi di Waterfall, è cioè quello di realizzare un software valido per diverse tipologie di clienti, e sostituendosi a loro nella definizione di quali requisiti e quali bisogni abbiano. Con requisiti predeterminati e validi per diversi clienti, una società di software è in grado infatti di stabilire tutte le altre fasi di sviluppo del software e quindi di avere tempi e costi certi con rischi minimi perchè il prodotto va bene per clienti diversi e mette a fattor comune più funzionalità. Poco importa se uno specifico cliente ne userà solo alcune.  Inoltre siccome il software prodotto non dipende dal singolo cliente, è possibile venderlo al maggior numero possibile di clienti e quindi ridurre il prezzo di vendita del software stesso. Questo significa essere molto competitivo verso piccoli concorrenti, che non possono ammortizzare i costi su un gran numero di copie vendute. 

E’ da qui che nasce la critica posta dai sostenitori dell’approccio Agile.

---

^[1] fino al 2000 Waterfall (e le sue varianti) era praticamente l’unico in cui erano organizzati i progetti software. Oggi è stato affiancato dalle metodologie agile, che offrono modelli di processo alternativi ma che comunque prevedono internamente fasi molto simili a waterfall. 

^[2] Questo modello di Waterfall è un modello che si adatta ad applicazioni “standalone” che non prevedono componenti da integrare o che hanno fasi di integrazione limitate. Il modello del Waterfall che invece si basa sull’integrazione estesa di progetti differenti è il modello a V.

^[3] Naturalmente questo avviene nei progetti più grandi. Nelle realtà più piccole questi ambienti vengono accorpati, ma resta comunque necessaria la distinzione almeno tra un ambiente di sviluppo/test ed uno di produzione.