Il modello a cascata

Il modello a cascata è un ciclo di vita se­quen­zia­le grazie al quale è possibile modellare gli sviluppi uti­liz­zan­do fasi con­se­cu­ti­ve.

Il modello a cascata (in inglese waterfall model) è un ciclo di vita lineare, che suddivide il processo di sviluppo in fasi di progetto con­se­cu­ti­ve. A dif­fe­ren­za dei modelli iterativi, ogni fase viene eseguita solo una volta. I risultati di ogni fase rap­pre­sen­ta­no le pre­con­di­zio­ni per la fase suc­ces­si­va. Il modello a cascata viene uti­liz­za­to so­prat­tut­to nello sviluppo dei software.

Lo sviluppo del classico modello a cascata viene at­tri­bui­to allo scien­zia­to in­for­ma­ti­co Winston W. Royce. Royce, tuttavia, non è stato il suo vero inventore. Al contrario, il suo articolo pub­bli­ca­to nel 1970 “Managing the De­ve­lo­p­ment of Large Software Systems” conteneva una critica aperta nei confronti dei cicli di vita lineari. Come al­ter­na­ti­va Royce pre­sen­ta­va un modello iterativo-in­cre­men­ta­le, in cui ogni fase attinge a quella pre­ce­den­te e ne verifica i risultati.

Royce proponeva un modello con sette fasi eseguite in diversi passaggi (ite­ra­zio­ni):

1. Requisiti di sistema
2. Requisiti di software
3. Analisi
4. Pro­get­ta­zio­ne
5. Im­ple­men­ta­zio­ne
6. Test
7. Ese­cu­zio­ne

Il ciclo di vita co­no­sciu­to come modello a cascata si ispira alle fasi definite da Royce, ma prevede solo un’ite­ra­zio­ne.

Infatti nell’articolo di Royce della parola “modello a cascata” non vi è nemmeno l’ombra.

Le esten­sio­ni del modello a cascata semplice com­ple­ta­no il modello base con funzioni iterative, ad esempio con­fron­tan­do e ve­ri­fi­can­do i risultati di ciascuna fase con quelli della fase pre­ce­den­te.

Nel modello a cascata le singole fasi di un processo di sviluppo si sus­se­guo­no una dopo l’altra come una cascata. Ogni fase si chiude con un risultato in­ter­me­dio (milestone), ad esempio con un catalogo di requisiti sotto forma di di­sci­pli­na­re, con la specifica di un’ar­chi­tet­tu­ra software o con l’utilizzo di una versione alpha o beta.

Ogni progetto di software inizia con una fase di analisi che consiste in uno studio della fat­ti­bi­li­tà e una de­fi­ni­zio­ne dei requisiti. Durante lo studio della fat­ti­bi­li­tà il progetto software viene valutato in base ai costi, ai profitti e alla rea­liz­za­bi­li­tà. Dallo studio della fat­ti­bi­li­tà risultano un di­sci­pli­na­re (una de­scri­zio­ne generale dei requisiti), un piano di progetto e il calcolo di progetto come anche un’offerta per il com­mit­ten­te.

Infine segue una det­ta­glia­ta de­fi­ni­zio­ne dei requisiti, che comprende l’analisi della si­tua­zio­ne effettiva e il progetto teorico. Mentre l’analisi della si­tua­zio­ne effettiva delinea l’area pro­ble­ma­ti­ca, nel progetto teorico si de­fi­ni­sco­no quali funzioni e ca­rat­te­ri­sti­che deve offrire il software per poter sod­di­sfa­re i requisiti. I risultati della de­fi­ni­zio­ne dei requisiti includono, ad esempio, delle spe­ci­fi­che tecniche, una de­scri­zio­ne det­ta­glia­ta di come devono essere sod­di­sfat­ti i requisiti del progetto e un piano per il test di ac­cet­ta­zio­ne.

La prima fase del modello a cascata si conclude con un’analisi della de­fi­ni­zio­ne dei requisiti, in cui i problemi complessi vengono scomposti in piccoli incarichi per i quali vengono elaborate le relative strategie di soluzione.

La fase di pro­get­ta­zio­ne prevede la pre­pa­ra­zio­ne di un concreto piano di soluzione sulla base di requisiti, incarichi e strategie già in­di­vi­dua­ti. In questa fase gli svi­lup­pa­to­ri software elaborano l’ar­chi­tet­tu­ra del software come anche un progetto di co­stru­zio­ne del software, con­cen­tran­do­si su com­po­nen­ti concreti come in­ter­fac­cia, framework e librerie. Il risultato della fase di pro­get­ta­zio­ne sarà un documento di bozza con il progetto di co­stru­zio­ne del software e la pia­ni­fi­ca­zio­ne dei test per i singoli com­po­nen­ti.

L’ar­chi­tet­tu­ra del software concepita nella fase di pro­get­ta­zio­ne viene rea­liz­za­ta nella fase di im­ple­men­ta­zio­ne, che comprende la pro­gram­ma­zio­ne del software, la ricerca degli errori e i test modulari. Durante la fase di im­ple­men­ta­zio­ne il software viene tradotto nella lingua di pro­gram­ma­zio­ne de­si­de­ra­ta. I singoli com­po­nen­ti vengono svi­lup­pa­ti se­pa­ra­ta­men­te, testati durante i test modulari e integrati passo dopo passo al prodotto. Il risultato della fase di im­ple­men­ta­zio­ne è un prodotto software che nella fase suc­ces­si­va verrà testato per la prima volta come prodotto completo (test alpha).

La fase di test comprende l’in­te­gra­zio­ne del software nell’ambiente di de­sti­na­zio­ne de­si­de­ra­to. Di regola i software vengono prima con­se­gna­ti al con­su­ma­to­re finale nella versione beta (test beta). È possibile ve­ri­fi­ca­re se il software soddisfa i requisiti definiti in pre­ce­den­za at­tra­ver­so i test di ac­cet­ta­zio­ne svi­lup­pa­ti durante la fase dell’analisi. Un software che supera i test beta è pronto per il rilascio.

Nel momento in cui termina la fase di test, il software passa alla fase di ese­cu­zio­ne per l’uso pro­dut­ti­vo. L’ultima fase del modello a cascata prevede rilascio, ma­nu­ten­zio­ne e mi­glio­ra­men­to del software.

Il modello a cascata offre una struttura or­ga­niz­za­ti­va chiara per i progetti di sviluppo, nella quale le singole fasi del progetto sono chia­ra­men­te distinte. Poiché ogni fase si chiude al rag­giun­gi­men­to di un traguardo, il processo di sviluppo è facile da com­pren­de­re. Il fulcro del modello è rap­pre­sen­ta­to dalla do­cu­men­ta­zio­ne delle fasi del processo. Le co­no­scen­ze acquisite sono re­gi­stra­te nei documenti di requisiti e pro­get­ta­zio­ne.

In teoria il modello a cascata dovrebbe creare le con­di­zio­ni per una rea­liz­za­zio­ne rapida ed economica dei progetti at­tra­ver­so una pia­ni­fi­ca­zio­ne at­ten­ta­men­te elaborata in anticipo. Tuttavia l’utilizzo del modello a cascata per l’uso pratico è con­tro­ver­so. Da una parte, le fasi del progetto per lo sviluppo del software sono chia­ra­men­te distinte solo in rari casi. So­prat­tut­to nei complessi progetti di software gli svi­lup­pa­to­ri spesso trovano diverse com­po­nen­ti di un’ap­pli­ca­zio­ne presenti allo stesso tempo in diverse fasi dello sviluppo. Dall’altra parte, il decorso lineare del modello a cascata spesso non cor­ri­spon­de alle con­di­zio­ni reali.

Secondo il modello a cascata le modifiche non sono previste nel corso del progetto. In tal caso un progetto di software, i cui dettagli di sviluppo sono già stati stabiliti all’inizio, si porta a termine senza problemi solo se già nella fase iniziale si investe tempo e denaro nell’analisi e nella pro­get­ta­zio­ne. Inoltre i grandi progetti di software possono durare anche diversi anni senza che siano adeguati re­go­lar­men­te ai più recenti risultati di sviluppo, obsoleti già al momento della loro in­tro­du­zio­ne.

I modelli a cascata sono uti­liz­za­ti prin­ci­pal­men­te in progetti i cui requisiti e processi possono essere descritti con pre­ci­sio­ne già nella fase di pia­ni­fi­ca­zio­ne e dove si presume che cam­bie­ran­no solo in minima parte nel corso del progetto. I cicli di vita estre­ma­men­te lineari sono adatti so­prat­tut­to a progetti di software piccoli, semplici e chia­ra­men­te strut­tu­ra­ti. Questo è quello che affermava Royce già negli anni ’70. L’al­ter­na­ti­va al ciclo di vita lineare da lui proposto, che è stato in seguito de­no­mi­na­to modello a cascata, conteneva quindi due esten­sio­ni es­sen­zia­li:

Secondo Royce i risultati di ogni fase di progetto dovevano essere con­fron­ta­ti e ve­ri­fi­ca­ti con i documenti elaborati in pre­ce­den­za: ad esempio, bisognava as­si­cu­rar­si che un modulo ri­spec­chias­se i requisiti pre­de­fi­ni­ti già dopo il suo sviluppo e non alla fine del processo di sviluppo.

Il modello a cascata secondo Royce doveva essere seguito per almeno due volte: prima per lo sviluppo di un prototipo e poi per lo sviluppo del prodotto software vero e proprio.

Come terza esten­sio­ne del modello a cascata, l’articolo di Royce ri­chie­de­va una misura ormai standard nello sviluppo del prodotto: l’in­clu­sio­ne dell’utente finale nel processo di pro­du­zio­ne. Royce proponeva di includere l’utente in tre occasioni nel processo di sviluppo del software: durante la pia­ni­fi­ca­zio­ne del software nella fase dell’analisi, tra la pro­get­ta­zio­ne del software e l’im­ple­men­ta­zio­ne e durante la fase di test prima del rilascio del software.

A causa del decorso lineare delle sue fasi di progetto se­quen­zial­men­te con­se­cu­ti­ve, il modello a cascata è adatto solo per i piccoli progetti di software. Processi complessi e a più livelli, al contrario, sono difficili da adattare a tale modello. Nel corso del tempo, quindi, sono state svi­lup­pa­te diverse al­ter­na­ti­ve.

Mentre modelli come il modello a spirale e il modello a V rap­pre­sen­ta­no evo­lu­zio­ni del classico modello a cascata, quelli suc­ces­si­vi come l’extreme pro­gram­ming, lo sviluppo agile dei software o la pro­to­ti­pa­zio­ne iterativa hanno un approccio to­tal­men­te diverso e con­sen­to­no l’adat­ta­men­to più fles­si­bi­le agli attuali cam­bia­men­ti e ai nuovi requisiti.