Ciclo di sviluppo software a spirale

Il modello di sviluppo software a Spirale

Il modello a spirale per lo sviluppo del software

Un’attività molto importante che svolgiamo nel campo della consulenza informatica è la gestione di progetti software o il recupero di quelli andati fuori controllo. Per poterlo fare è necessario, però, conoscere molto bene i cicli di sviluppo del software (anche noti come SDLC, acronimo di Software Development Life Cycle).

Il modello a spirale è poco conosciuto in quanto può essere piuttosto complesso da gestire e non funziona bene per piccoli progetti.

È però un modello basato sulla gestione rischio, il che significa che minimizza il rischio di fallimento del progetto, aumentando enormemente le probabilità di successo. L’analisi del rischio, però, richiede competenze specifiche su ogni iterazione.

Ad un profano, potrà sembrare che questo modello sia inutilmente complesso e ridondante ma, se si viene dal mondo dello sviluppo per grandi progetti, si conosce molto bene il sapore del “fallimento”: è estremamente raro che un progetto venga consegnato in tempo e con tutte le funzionalità operative!

Breve analisi delle principali caratteristiche

In poche parole, il modello a spirale può essere caratterizzato dalla ripetizione di processi elementari di sviluppo e di gestione del rischio.

Un modello spirale consiste di quattro fasi principali che vengono ripetute ad ogni incremento (è infatti un modello incrementale). Ogni iterazione si chiama Spirale.

Le quattro fasi principali sono:

  • Determinare gli obiettivi della spirale
  • Valutare le possibili alternative e i rischi
  • Sviluppare il software
  • Pianificare i passi a seguire

Fase 1: Determinare gli obiettivi

Questa fase è quella con cui inizia la spirale.

I membri del team di sviluppo raccolgono gli obiettivi da raggiungere, ossia i requisiti.

Nella prima spirale, tale raccolta parte da zero ma, nelle spirali successive, si basa sui risultati delle spirali precedenti.

In ogni spirale dopo la prima, i requisiti sono, quindi, aggiornati in base ai feedback del Cliente derivanti dai rilasci delle spirali passate. E’ quindi essenziale un’eccellente comunicazione tra il Cliente e il team di sviluppo.

Fase 2: Valutare le alternative e i rischi

Questa fase consiste nel valutare le possibili alternative di progetto,  identificare i rischi potenziali di ognuna, mitigare tali rischi, scegliere l’alternativa migliore, progettare la parte da sviluppare.

Cosa sono i rischi? I rischi sono condizioni o eventi che potrebbero impedire al team di sviluppo di raggiungere gli obiettivi.

Il compito principale del team di sviluppo, in questa fase, è identificare tutti i possibili rischi e classificarli in base all’importanza. Il passo successivo è determinare le strategie di gestione dei vari rischi. Alla fine di questa fase, viene in genere prodotto un prototipo, come accade nella fase di Elaboration di RUP.

Fase 3: Sviluppare il software

In questa fase il software viene sviluppato, ossia progettato nel dettaglio, e poi implementato e testato.

Ovviamente non si tratta di tutto il software ma solo di una piccola parte: quella che sarà gestita nella spirale.

In genere si ha una prima spirale, ogni volta che i requisiti non sono sufficientemente dettagliati o stabili, in cui viene creata la cosiddetta Proof Of Concept (PoC), ossia una versione preliminare (e primitiva) del software.

La PoC serve a stimolare un feedback dal Cliente, ossia a “chiarirgli le idee” facendogli vedere una prima realizzazione concreta di quello che ha chiesto.

Nelle spirali successive, viene realizzata una versione “più” funzionante del software, versione chiamata in gergo “build“, anch’essa inviata al Cliente per ottenere un nuovo feedback.

L’ultima spirale consegna il build finale, ossia quella che sarà la versione completa del software.

La PoC può aversi anche durante il progetto, non solo all’inizio: in genere ciò accade quando viene introdotta una nuova area nel software o si affronta una parte che ha subito fortissimi cambiamenti nella spirale precedente o in quella corrente.

Fase 4: Pianificare i passi successivi

Questa fase consente di valutare il risultato corrente del progetto e lo confronta con l’analisi del rischio e con altri aspetti (divergenza del design, carico sulle risorse umane, questioni tecnologiche, …) prima che il progetto prosegua nella spirale successiva.

Il modello a spirale è definito come un metamodello  perché usa sia il modello a cascata sia quello di prototipazione. E’ però fondamentale capire che il modello a spirale non è una semplice sequenza di incrementi a cascata o di prototipi evolutivi: è una modalità di sviluppo che si basa sulla gestione  del rischio.

Pregi e difetti del modello a spirale

Nessun modello di sviluppo è perfetto. Ogni ciclo di vita del software ha i suoi punti deboli e quelli forti.

I principali pro e contro dell’approccio a spirale sono descritti di seguito.

Vantaggi

  • La gestione del rischio è il principale vantaggio ed è la caratteristica che lo rende più interessante di altri, soprattutto quando si gestiscono progetti grandi e complessi o finiti fuori controllo. Inoltre, tale approccio rende il progetto più trasparente perché ogni spirale deve essere sempre riesaminata e analizzata.
  • Le stime del progetto sia in termini di tempistiche che di costi, diventano sempre più vicine alla realtà man mano che il progetto avanza. Lo stesso vale per i requisiti, che diventano sempre più precisi, spirale dopo spirale
  • Il progetto viene naturalmente suddiviso in più parti, consentendo di affrontare un problema alla volta, magari anticipando quelle più rischiose
  • Il Cliente può vedere il prodotto funzionante sin dalle prime fasi del ciclo di vita dello sviluppo del software
  • Cambiamenti anche pesanti nei requisiti o nel design possono essere assorbiti persino nelle fasi finali del ciclo di sviluppo
  • Esiste un forte controllo della documentazione (per cui è sempre necessario uno strumento CASE)

Svantaggi

Il modello a spirale può essere piuttosto costoso da utilizzare, viste le risorse aggiuntive e le competenze specialistiche che richiede.

Inoltre ogni spirale richiedere competenze specifiche, il che rende il processo di gestione più complesso (sebbene la suddivisione in progetti più piccoli, le spirali, aiuta in parte a mitigare il problema).

Questi sono i motivi per cui non ha senso usare un ciclo di sviluppo a spirale per piccoli progetti.

Inoltre un progetto a spirale contiene un gran numero di fasi intermedie, con relativa proliferazione di documenti (per questo, come detto prima, è necessario un CASE piuttosto potente).

La gestione della pianificazione può essere difficile, data la frammentazione evolutiva delle spirali e, spesso, la data di completamento del progetto non può essere ben definita sin dalle prime spirali ma solo dopo aver raggiunto una maturità (ossia solo dopo svariate spirali) sufficiente.

Conclusioni

La nostra azienda utilizza il ciclo di sviluppo a spirale principalmente in due casi specifici.

Il primo è quando si deve realizzare un software molto complesso e non ben definito, in cui si ha, all’inizio, una certa elasticità nella definizione della data di consegna ma questa, una volta fissata, deve essere rispettata.

Il secondo caso è nel recupero di progetti software finiti fuori controllo. Quando un progetto “fallito”, ossia intollerabilmente fuori tempo e budget, deve essere recuperato, è necessario garantire:

  • immediata visibilità al Cliente che la deriva del progetto è finita e si sta convergendo
  • gestione severissima del rischio allo scopo di minimizzare la probabilità di una nuova deriva
  • gestione delle necessità di cambiamenti pesanti anche in fase avanzata

In sintesi estrema: usiamo il modello a spirale solo per progetti ad elevato rischio.

Se avete bisogno di una consulenza informatica nella gestione di progetti di sviluppo software, con ciclo a spirale o meno, non importa, potete rivolgervi a noi tramite i nostri contatti o con l’apposito modulo.

Se avete bisogno di recuperare un progetto fuori controllo, i nostri consulenti informatici sono a vostra disposizione.

 

0 commenti

Lascia un Commento

Vuoi partecipare alla discussione?
Fornisci il tuo contributo!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.