Approci derivanti dall'ingegneria tradizionale, nella quale l'attività creativa termina con il progetto mentre la fase esecutiva è sostanzialmente standard, applicati al mondo informatico non funzionano.
Una metodologia di sviluppo è un insieme integrato di metodi che specifica come i task del Ciclo di Vita debbano essere portati a termine al fine di pianificare e controllare un progetto.
In questa serie di articoli verrà presentata una breve panoramica delle diverse metodologie di sviluppo e si cercherà di delineare alcune criteri che aiutino a scegliere la metodologia opportuna a secondo della tipologia del progetto.
Inizialmente verranno presentate le metodologie cosiddette predittive che analizzano il sistema per capirne l'implementazione e le eventuali evoluzioni.

Metodologia di sviluppo a cascata (Waterfall)
Nella metodologia di sviluppo a cascata (waterfall) il progetto è organizzato in una sequenza di fasi, ciascuna delle quali produce un output che costituisce l'input per la fase successiva. Le fasi di pianificazione e di sviluppo sono quindi eseguite in modo prettamente sequenziale e ciascuna fase può iniziare solo dopo la conclusione della fase precedente (ad esempio, la fase di definizione dei requisiti produce un output, la "specifica dei requisiti", che entra in input alla fase di analisi così come quest'ultima produce la "specifica di analisi", che entra in input alla fase di design e così via…) ..
Questa strutturazione del ciclo di vita del software "mostra la corda" laddove si ha neccessità di "ciclare", cioè di ritornare su di una fase precedente (ad esempio in fase di sviluppo ci si potrebbe essere necessario tornare alla fase di analisi e/o di progettazione per chiarire meglio alcuni aspetti del progetto).

Figura 1 - Metodologia di sviluppo a cascata

Visto che difficilmente (mai !?) è possibile definire nella fase iniziale del processo i requisiti utente (e tantomeno "scriverli nella roccia" …) questo approcio risulta essere poco dinamico e poco flessibile ai cambiamenti progettuali.
Di fatto questo processo di sviluppo non prevede dei "checkpoint" che consentano di controllare se il processo sta procedendo nella giusta direzione.

Metodologia di sviluppo iterativa
La metodologia iterativa propone un modello in cui sono presenti le stesse fasi del modello a cascata ma queste invece di giacere su una linea retta, giacciono su una circonferenza e l'ultimo passo innesca uno nuovo riciclo (dalla fase di test si torna a quella di pianificazione e così via).

Figura 2 - Sviluppo iterativo

Il movente che porta a questa evoluzione è la necessità di avere controllo sul progetto: un Project Manager non può assumersi il rischio di sviluppare tutto un progetto software senza mai avere un riscontro (ad esempio con il committente) ed accorgersi solo alla fine di non avere "centrato il bersaglio".
Considerando che all'inizio di un progetto di sviluppo software i rischi sono tipicamente molto elevati (requisiti non ancora ben definiti, scelte architetturali e tecnologiche da consolidare, ….) ogni iterazione, in un progetto iterativo, ha lo scopo di ridurre i rischi di progetto.
Inizialmente, tramite la costruzione di prototipi e successivamente, quando i rischi principali sono stati messi sotto controllo, ogni iterazione ha lo scopo di costruire, in modo progressivo, nuove porzioni del sistema, via via integrate
con le precedenti, e di verificarle con il committente e le altre parti interessate.
Le singole iterazioni possono dunque servire, sia a segmentare lo sviluppo per i progetti molto grandi, sia a "correggere la mira" se qualcosa è andato "storto" nelle interazioni precedenti.
Di fatto nel modello iterativo sono presenti le stesse fasi del modello a cascata ma i tempi sono piu' ristretti ed inoltre mentre nel processo di sviluppo a cascata queste fasi sono considerate da svolgersi in sequenza rigida e in maniera definitiva, nel processo iterativo esse vengono ripercorse in ogni iterazione.
In questo modo il processo di sviluppo prevede dei "check point" ad ogni iterazione consentendo al gruppo di analisi/design/sviluppo di verificare se si sta dirigendo nella direzione corretta e, nel caso contrario di ritornare sui propri passi ed effettuare le dovute correzioni.
Una iterazione quindi comprende le attività di sviluppo che producono un rilascio di una versione del sistema o di una o più delle sue parti con funzionalità ridotte al fine di permettere un'evoluzione incrementale del sistema.

Figura 3: Confronto tra la durata delle fasi nella metodologia waterfall e quella iterativa

Quanto più il progetto software è critico tanto più è probabile che il processo di sviluppo da adottare abbia caratteristiche di natura iterativa.
La natura iterativa dei processi ha lo scopo di ridurre i rischi di progetto e costruire, in modo progressivo, nuove porzioni del sistema via via integrate con le precedenti per poi verificare la loro qualità con il team e con il committente.
I processi di sviluppo software come RUP (Rational Unified Process) e i processi cosiddetti agili" (XP, Scrum, Feature-Driven Development, ...) sono tutti di natura iterativa.

RUP (Rational Unified Process)
RUP è la versione commerciale di Rational-IBM dello Unified Process, la metodologia di sviluppo ideata dai Tres Amigos (Grady Booch, James Rambaugh, Ivar Jacobson, … gli stessi fondatori dell'UML) ed è uno dei processi iterativi più diffusi nel settore dello sviluppo software.
RUP è di fatto un framework, un template di processo e come tale può modellare (se opportunamente personalizzato/specializzato) una grande varietà di tipologie di processi diversi.
Ogni ciclo è costituito da quattro fasi (iniziale, elaborazione, costruzione e transizione)
ognuna delle quali è, a sua volta, suddivisa in iterazioni. La suddivisione in fasi ha il principale scopo di analizzare e gestire al più presto i possibili rischi legati al progetto e che quindi potrebbero causarne il fallimento.
La realizzazione del sistema avviene in modo incrementale attraverso cicli di iterazioni controllate, ognuna delle quali termina con la produzione di una nuova versione del sistema. In ogni iterazione si ripetono, le medesime tipologia di attività (es: gestione dei requisiti, design, implementazione, test, …) ma in misura e percentuali diverse.

Figura 4 - RUP

Vediamo ora una breve descrizione delle 4 fasi di RUP (per una spiegazione esauriente vedere [RUP]).
Nella fase iniziale (detta inception) si definiscono gli obiettivi del ciclo di vita del sistema da sviluppare, la fattibilità tecnica del progetto, si "censiscono i possibili rischi di business e quanto dovrebbe costare lo sviluppo del prodotto.
In questa fase di fatto si valuta lo scope del progetto, le opportunità di business, i ritorni economici attesi,ecc …; in base a tali valutazioni si decide per il go/no-go (andare avanti o giudicare non economicamente remunerativo affrontare l'impresa).
Nella seconda fase, nota come elaborativa (elaboration), prevede l'analisi dei requisiti significativi, la scelta dell'architettura del sistema eventualmente anche con un prototipo affrontando soprattutto i rischi dovuti alla definizione dell'architettura.
Al termine della fase elaborativa il capo progetto si trova nelle condizioni di poter pianificare le attività e di stimare le risorse necessarie per completare l'intero progetto se i rischi stimati garantiscono le condizione di procedere.
Terminata la seconda fase si passa a quella di costruzione (construction) il cui scopo è chiarire i requisiti rimanenti e completare lo sviluppo del sistema basato sull'architettura delineata nella fase successiva.
Si pone enfasi nella pianificazione e gestione del progetto sia per quanto riguarda le risorse che i costi e la qualità.
L'ultima fase, di transizione (transition) comprende il periodo necessario al prodotto per divenire una versione beta. Un ristretto numero di utenti prova la versione e compila un documento con l'elenco di difetti e deficienze. Questo documento viene quindi fornito a un gruppo di sviluppatori che ricontrolla il prodotto e provvede a risolvere i problemi
esposti. A questo punto il prodotto è pronto a essere somministrato a un gruppo di prova più ampio.
Alla fine di ogni fase si prevede il raggiungimento di una ben determinata milestone che permette di valutare lo stato di avanzamento ed evoluzione del progetto.
La milestone della fase di inception è quella di avere gli obiettivi di progetto consolidati e reputati fattibili. La milestone della fase di elaboration richiede che l'architettura e requisiti siano consolidati mentre quella della fase di construction prevede una versione Beta del prodotto per iniziare i test di accettazione. La milestone della fase di transizione è costutiita dal rilascio del prodotto e dal tracciamento dei possibili suggerimenti/affinamenti.
Successivamente alla fase di transizione dovrebbe prevedere attività quali la manutenzione del prodotto, addestrare il personale utente, fornire assistenza e accogliere eventuali suggerimenti
che tipicamente vengono suddivisi in urgenti (must) e quelli da demandare alle fasi successive (should, could, nice-to-have).
Essendo RUP una "meta-metodologia" sia il numero che la durata delle iterazioni che il numero degli elaborati da fare dipendendono dalla complessità del progetto e di conseguenza da come si è "personalizzato" RUP.
Gli artefatti che generalmente devono "accompagnare" la versione finale del sistema sono:

• il modello dei casi d'uso, che riporta le relazioni tra i diversi use case e i relativi attori e scenari
• il modello di analisi che indirizza un iniziale disegno della struttura e comportamento del sistema individuando gli oggetti basilari che lo caratterizzano
• il modello di disegno che definisce struttura statica del sistema in termini di sottosistemi, classi, interfacce
• il modello di implementazione che include i componenti e il mapping degli stessi con le relative classi e di conseguenza package
• il modello di deployment che definisce come i componenti software vadano allocati sui nodi fisici previsti dall'architettura tecnologica
• il modello di test il quale definisce i casi di test (Test Case) che verificano gli Use Case

Figura 5 - I modelli previsti dal Unified Process
(clicca per ingrandire)

Il passaggio dalle specifiche del cliente e/o modello di analisi alla realizzazione del modello del disegno del sistema è un passaggio delicato che deve essere affrontato con la necessaria cautela e rigore. Il passaggio dal disegno alla codifica è invece un passaggio abbastanza diretto al patto che il disegno sia fatto bene e che lo sviluppatore fornisca sufficienti indicazioni laddove l'implementazione discosti dal disegno al fine di rendere disegno e implementazione coerenti tra loro.

Figura 6 - I gap analisi-design e design-implementazione

Conclusioni
In questo primo articolo si è parlato della storica metodologia waterfall e delle metodologie iterative portando come esempio il processo di sviluppo RUP.
Nel prossimo articolo verranno descritte le principali metodologie agili come XP, Scrum e FDD analizzando le caratteristiche saliente dei processi di sviluppo agili.

Bibliografia
[RUP]The Rational Unified Process - http://www.rational.com
[UMLD] M. Fowler, Kendall Scott: UML Distilled (Addison Wesley)
[MKUML] Luca Vetti Tagliati: UML e ingegneria del software-Dalla teoria alla pratica
(HOPS)
[PRCSW] Processo di sviluppo SW
http://www.analisi-disegno.com/processo/processosvilupposw.htm