Le fasi i i cardini di un progetto
Da una prospettiva di gestione, il ciclo di vita software di un processo Rational unificato (RUP) si scompone nel tempo
in fasi sequenziali, ciascuna conclusa da un cardine principale. Ogni fase è essenzialmente uno spazio di tempo tra due
cardini principali. Ad ogni fine fase viene effettuata una valutazione per determinare se gli obiettivi di una fase
sono stati raggiunti. Una valutazione soddisfacente consente al progetto di avanzare alla fase successiva.
Fasi di pianificazione
Le fasi non sono identiche in termini di pianificazione ed impegno. Nonostante questo vari notevolmente a seconda del
progetto, un tipico ciclo di sviluppo iniziale per un progetto di medie dimensioni dovrebbe anticipare la seguente
distribuzione tra impegno e tempi:
che possono essere rappresentati graficamente come
Questa distribuzione può variare. Ad esempio, gli strumenti che generano scenari di test e codice possono abbreviare la
fase di costruzione. Inoltre, per un ciclo di evoluzione, le fasi di elaborazione e di inizio saranno notevolmente
ridotte, poiché sono già stabilite un'architettura e una visione di base.
Strategie di pianificazione
In questa sezione, verranno introdotti un numero di modelli di ciclo di vita corrispondenti ai comuni profili di
progetto.
Modello di ciclo di vita:Incrementale
"La strategia incrementale determina le necessità dell'utente, definisce i requisiti di sistema e poi esegue il resto
dello sviluppo in una sequenza di build. Il primo build incorpora parti di capacità pianificate, quella successiva
aggiunge altre capacità e così via finché il sistema è completo. [DOD94]
Quelle che seguono sono iterazioni caratteristiche:
-
una breve iterazione di Inizio per stabilire l'ambito e la vista e per definire lo scenario di business
-
una singola iterazione di Elaborazione, durante la quale vengono definiti i requisiti e stabilita
l'architettura
-
svariate iterazioni di Costruzione durante le quali vengono realizzati i casi d'uso e messe in mostra le
architetture.
-
svariate iterazioni di Transizione per migrare il prodotto nella comunità dell'utente
Questa strategia è appropriata quando:
-
Il dominio del problema è ben noto.
-
Si conoscono bene i rischi.
-
Il team del progetto è esperto.
Modello di ciclo di vita: Evolutivo
"La strategia evolutiva differisce da quella incrementale in quanto riconosce che le necessità dell'utente non sono
completamente comprese e perché non è possibile definire tutti i requisiti nella parte iniziale; questi vengono
perfezionati in ciascuna versione successivo." [DOD94]
Quelle che seguono sono iterazioni caratteristiche:
-
una breve iterazione di Inizio per stabilire l'ambito e la vista e per definire lo scenario di business
-
svariate iterazioni di Elaborazione durante le quali i requisiti vengono perfezionati ad ogni iterazione.
-
una singola iterazione di Costruzione, durante la quale vengono realizzati i casi d'uso e viene messa in mostra
l'architettura
-
svariate iterazioni di Transizione per migrare il prodotto nella comunità dell'utente
Questa strategia è appropriata quando:
-
Il dominio del problema è nuovo o poco familiare
-
Il team del progetto non è esperto
Alcuni autori hanno anche diviso in fasi le produzioni di funzionalità incrementale rivolte al cliente [GIL88]. Ciò può essere richiesto dove sono presenti le serrate pressioni del
tempo-sul-mercato, dove la produzione di talune funzioni chiave può produrre vantaggi significativi di business.
In termini di approccio dell'iterazione della fase, la fase di transizione inizia presto e ha le maggiori iterazioni.
Questa strategia richiede un'architettura molto stabile, che è difficile da raggiungere in un ciclo di sviluppo per un
sistema "senza precedenti".
Quelle che seguono sono iterazioni caratteristiche:
-
una breve iterazione di Inizio per stabilire l'ambito e la vista e per definire lo scenario di business
-
una singola iterazione di Elaborazione, durante la quale un'architettura stabile viene confrontata con la linea
di base
-
una singola iterazione di Costruzione, durante la quale vengono realizzati i casi d'uso e l'architettura viene
espansa
-
svariate iterazioni di Transizione per migrare il prodotto nella comunità dell'utente
Questa strategia è appropriata quando:
Modello di ciclo di vita: "Grand Design"
L'approccio tradizionale a cascata (waterfall) può essere visto come un caso degenere in cui esiste solo una iterazione
nella fase di costruzione. Viene definito "grand design" in [DOD94]. In pratica, è
difficile evitare iterazioni aggiuntive nella fase di transizione.
Quelle che seguono sono iterazioni caratteristiche:
-
una breve iterazione di Inizio per stabilire l'ambito e la vista e per definire lo scenario di business
-
una singola iterazione di Costruzione, molto lunga, durante la quale vengono realizzati i casi d'uso e
l'architettura viene messa in mostra
-
svariate iterazioni di Transizione per migrare il prodotto nella comunità dell'utente
Questa strategia è appropriata quando:
-
un piccolo incremento di funzionalità ben definite viene aggiunta ad un prodotto molto stabile
-
la nuova funzionalità è ben definita e compresa
-
il team ha esperienza, sia nel dominio del problema che con il prodotto esistente
Nella pratica, alcuni progetti seguono strettamente una strategia. Spesso si finisce con un ibrido, un pò di
evoluzione all'inizio, un pò di costruzione incrementale e produzioni multiple. Tra i vantaggi del modello di
iterazione della fase è da considerare che questa consente di utilizzare un approccio ibrido, semplicemente
incrementando la lunghezza ed il numero delle iterazioni in fasi particolari:
-
Per il complesso o i domini di problemi non noti, dove c'è un alto grado di esplorazione: aumentare il numero
di iterazioni nella fase di elaborazione e la sua lunghezza.
-
Per i problemi di sviluppo più complessi, dove c'è complessità nel convertire il progetto in codifica:
aumentare il numero di iterazioni nella fase di costruzione e la sua lunghezza.
-
Per produrre un software in una serie di rilasci incrementali: aumentare il numero di iterazioni nella fase di
transizione e la sua lunghezza.
Spostamento da un ciclo all'altro
Un passaggio tra le quattro fasi è un ciclo di sviluppo; ogni passaggio produce una generazione del
software. A meno che il prodotto non "muoia," questo evolverà nella sua successiva generazione, ripetendo la stessa
sequenza di fasi di inizio, elaborazione, costruzione e transizione ma questa volta con un'enfasi differente nelle
varie fasi. I cicli che ne seguono vengono denominati cicli di evoluzione. Man mano che il prodotto avanza
attraverso i cicli, vengono prodotte nuove generazioni.
I cicli di evoluzione possono essere attivati da miglioramenti suggeriti dall'utente, modifiche nel contesto
dell'utente, modifiche nella tecnologia sottostante, reazione alla competizione e così via. I cicli di evoluzione di
solito hanno fasi di Inizio e di Elaborazione molto più brevi poiché la definizione del prodotto base e l'architettura
sono determinati dai precedenti cicli di sviluppo. Eccezioni a questa regola sono i cicli di evoluzione in
cui si verifica una significativa ridefinizione del prodotto o dell'architettura.
|