Ricerca per:

LA NOSTRA METODOLOGIA

Le nostre soluzioni nascono da un’analisi di fattibilità mirata alla comprensione delle specificità di ogni singolo contesto aziendale.

Ecco perché seguiamo il modello a spirale, un modello basato sulla gestione rischio per minimizzare il rischio di fallimento del progetto e aumentarne le probabilità di successo.

Il modello a spirale per lo sviluppo del software

Le nostre soluzioni nascono da un’analisi di fattibilità mirata alla comprensione delle specificità di ogni singolo contesto aziendale.

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.

È però un modello basato sulla gestione rischio, il che significa che minimizza il rischio di fallimento del progetto, aumentando enormemente le probabilità di successo. 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!

lo sviluppo è incrementale, ma vengono sfruttati uno o più cicli basati su prototipi per dirimere il rischio e poi passare, solo successivamente, allo sviluppo vero e proprio che avviene in chiave waterfall. In pratica è come se avessimo una fase di Inception (rif. RUP e DAD) molto lunga che però, una volta completata, viene completamente congelata

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

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 primai 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.

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.

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.

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.