Modello a Cascata - P.M. Consulting

Cerca
Vai ai contenuti

Menu principale:

Spazio P.M. > Pratiche di Project Mgmt > Metodi di Sviluppo SW


Sviluppo SW - Modello a Cascata



È il modello più tradizionale di sviluppo del Software, che prevede una sequenza di fasi, ciascuna delle quali produce un ben preciso output che viene utilizzato come input per la fase successiva (da cui la metafora della cascata).

Pur essendo stato soggetto a profonde critiche revisioni negli ultimi decenni, rimane il metodo di riferimento universalmente accettato, rispetto al quale tutti gli altri risultano delle varianti piuttosto che delle vere alternative.

Il modello a cascata prevede le seguenti fasi:

1. Studio di fattibilità
Consente di decidere se intraprendere o no lo sviluppo del sistema, da un punto di vista sia tecnico che economico; Questa fase si conclude con l'autorizzazione (o il diniego) del Management alla realizzazione del Progetto.

2. Analisi dei Requisiti
Determina in dettaglio cosa farà il sistema, documentando in forma chiara e precisa i requisiti delle funzionalità richieste.

3. Disegno
Ha lo scopo di definire le specifiche dei requisiti, l'architettura del sistema, la sua suddivisione in moduli e le relazioni fra di essi;

4. Sviluppo
Costruzione dei moduli del sistema con un linguaggio di programmazione;

5. Collaudo

  • Test funzionale: Prove eseguite dai programmatori per verificare la correttezza dell'implementazione dei singoli moduli;

  • Test di Integrazione: Prove eseguite dagli analisti funzionali per verificare la correttezza del funzionamento complessivo del Sistema;

  • Test di Accettazione:Prove finali del funzionamento del sistema eseguite dagli utenti finali allo scopo di verificare l'aderenza ai requisiti e, quindi, di accettarne l'implementazione.


6. Implementazione
Attività di consegna del Sistema e sua installazione nell'ambiente di produzione. Comprende tutte le azioni necessarie a consentire l'utilizzo del nuovo sistema, dalla predisposizione dell'ambiente infrastrutturale sino alla formazione degli utenti finali

7.      Manutenzione
La fase successiva alla consegna del Sistema al cliente, comprende tutte le attività volte a migliorare, estendere e correggere il Sistema nel tempo.




Con il modello di sviluppo a cascata, la produzione del Software è stata sottoposta per la prima volta ad una disciplina ben definita, assumendo i connotati del processo industriale. La suddivisione del processo in fasi correlate ha consentito di assegnare a ciascuna fase compiti specifici, rendendo più ordinato l'indirizzamento delle varie problematiche.
Uno dei limiti maggiori di questo approccio è che il livello di parallelizzazione delle attività è piuttosto basso e questo provoca, specialmente nei progetti di grandi dimensioni, un allungamento dei tempi che può risultare inaccettabile per le esigenze del business. Il modello, infatti, richiede il rispetto di alcuni principi:

Linearità
la segnalazione degli errori durante le fasi di test e la loro correzione devono svolgersi nella giusta sequenza, secondo un processo lineare. Questo impone un allungamento dei tempi

Rigidità
Ogni fase viene congelata quando si passa alla fase successiva. Questo approccio non consente ripensamenti, se non su base eccezionale e sopportandone il costo, sia in termini di tempo che di budget. Ad esempio non è quindi possibile un'interazione tra clienti e sviluppatori durante la fase di sviluppo, perché i requisiti sono ormai definiti e non possono essere più modificati.

Monoliticità
Il modello è tutto orientato alla data di rilascio che spesso è piuttosto lontana dalla data di inizio del progetto. A causa di questo, le correzioni ad eventuali errori commessi nelle fasi iniziali (requisiti errati o inadeguati) non potranno essere implementate se non dopo parecchio tempo, facendo seguire alla prima consegna un successivo progetto che recepisca tutte le correzioni maturate nel frattempo.

I maggiori problemi connessi con il modello a cascata sono i seguenti:

  • Difficoltà a stimare in modo accurato i costi e le risorse necessarie nella fase iniziale del progetto, quando ancora mancano sufficienti elementi di dettaglio   ma è già necessario definire budget e piano di lavoro.


  • Necessità di aderire a precisi standard nella produzione dei documenti di progetto, con il rischio di introdurre una eccessiva burocratizzazione delle attività.


  • Il documento che specifica i requisiti non sempre soddisfa le effettive esigenze degli utenti perché spesso gli utenti stessi non sono in grado di conoscere e quindi di descrivere con efficacia tutti i requisiti dell'applicazione. Considerando che questo documento vincola il prodotto da sviluppare, la sua rigidità sin all'inizio del processo rappresenta un limite piuttosto significativo per la qualità del prodotto finale.


In conclusione, il modello a cascata favorisce un incremento complessivo dei costi di produzione del software a causa dei molti interventi successivi che si rendono necessari per adeguare le funzionalità del sistema alle effettive esigenze degli utenti, che le specifiche di progetto non sono state in grado di intercettare a causa della rigidità con cui il modello le gestisce. Così, quello che si è evitato di spendere durante il progetto accettando una variazione dei requisiti lo si ritrova, ad un costo superiore, come integrazione da sviluppare nel periodo successivo all'implementazione.


P.M. Consulting s.a.s. di Donato Dolini & C. | chi siamo | dove siamo | contattaci

 
Torna ai contenuti | Torna al menu