Un progetto che utilizza lo sviluppo iterativo ha un ciclo di vita composto da varie iterazioni. Un'iterazione
comprende una serie sequenziale di compiti relativi alla modellazione del business, ai requisiti, all'analisi e alla
progettazione, all'implementazione, alla verifica e alla distribuzione, presenti in proporzioni diverse in base alla
posizione dell'iterazione all'interno del ciclo di sviluppo. Le iterazioni comprese nella fase di inizio e in quella di
elaborazione sono concentrate sulle attività di progettazione, gestione e requisiti; le iterazioni della fase di
costruzione sono concentrate sulla progettazione, sull'implementazione e sulla verifica; le iterazioni della fase di
transizione sono concentrate sulla verifica e sulla distribuzione. Le iterazioni devono essere gestite in un modo che
rispetti i limiti di tempo, ossia la pianificazione dell'iterazione deve essere
considerata fissa e l'ambito del contenuto dell'iterazione deve essere effettivamente gestito in modo da rispettare la
pianificazione.
È probabile che in una progettazione iniziale si producano degli errori rispetto ai requisiti chiave. Un'individuazione
tardiva degli errori di progettazione determina superamento dei costi e, in alcuni casi, persino l'annullamento del
progetto.
Tutti i progetti implicano una serie di rischi. Maggiore è l'anticipo con cui è possibile verificare in un ciclo di
vita che un rischio è stato evitato, maggiore sarà l'accuratezza dei piani. Molti rischi possono addirittura non essere
scoperti fino a quando non si tenta di integrare il sistema. Non sarà mai possibile predeterminare tutti i rischi a
prescindere dall'esperienza del team di sviluppo.
In un ciclo di vita waterfall non è possibile verificare se un rischio è stato evitato se non nella fase finale del
ciclo di vita.
In un ciclo di vita iterativo, si seleziona l'incremento con cui sviluppare in un'iterazione in base ad un elenco di
rischi chiave. Poiché l'iterazione produce un eseguibile verificato, è possibile controllare se i rischi sono stati
ridotti.
Un approccio iterativo è generalmente superiore all'approccio lineare o waterfall per numerosi motivi.
-
I rischi vengono ridotti in anticipo, poiché gli elementi vengono integrati in modo progressivo.
-
Viene favorita la modifica di requisiti e di tattiche.
-
Viene agevolato il miglioramento e il perfezionamento del prodotto, determinando, in tal modo la creazione di un
prodotto più solido.
-
Le organizzazioni possono apprendere da questo approccio e migliorare il proprio processo.
-
La riutilizzabilità è stata aumentata.
Un cliente ha detto una volta: "Con l'approccio waterfall, tutto funziona correttamente fino alla fine del progetto e
talvolta anche durante l'integrazione. Poi, tutto diventa distante. Con l'approccio iterativo, è molto difficile
nascondere a lungo la verità.
Spesso i responsabili di progetto respingono l'approccio iterativo, considerandolo una suddivisione senza fine. In
Rational Unified Process l'approccio iterativo è ben controllato; le iterazioni sono pianificate nel numero, nella
durata e negli obiettivi. Le attività e le responsabilità dei partecipanti sono definite. Vengono raccolte misurazioni
obiettive dell'avanzamento. Talvolta viene effettuata la rilavorazione da un'iterazione ad un'altra, ma anche questo
viene accuratamente controllato.
Un approccio iterativo consente di ridurre in anticipo i rischi, che spesso possono essere rilevati solo durante
l'integrazione. Appena si esegue un'iterazione, si passa attraverso tutte le discipline, facendo pratica con i
molti aspetti del progetto: tool, software già pronto, skill delle persone e così via. I rischi percepiti possono
rivelarsi come non rischi, mentre possono presentarsi nuovi rischi non previsti.
L'integrazione non è un "big bang" poiché gli elementi finali vengono incorporati in modo progressivo. In realtà
l'approccio iterativo è un'integrazione quasi continua. Ciò che solitamente era un lungo, incerto e difficile impiego
di tempo fino al 40% dell'impegno totale alla fine di un progetto e ciò che era difficile pianificare accuratamente è
stato suddiviso in una serie di integrazioni (da sei a nove) più piccole che iniziano con pochissimi elementi da
integrare.
L'approccio iterativo consente di raccogliere le richieste di modifiche man mano che verranno prodotte durante
il percorso.
Le modifiche dei requisiti sono sempre state la fonte principale dei problemi di un progetto, determinando
ritardo nella consegna, mancato rispetto dei tempi, insoddisfazione del cliente e frustrazione degli sviluppatori.
Venticinque anni fa, Fred Brooks scrisse: "Plan to throw one away, you will anyhow (pianifica di buttarne via uno,
raggiungerai comunque l'obiettivo". Gli utenti hanno cambiato il modo di pensare lungo la strada. Questa è la natura
umana. Costringere gli utenti ad accettare il sistema così come lo hanno immaginato originariamente è sbagliato. Essi
cambiano il loro modo di pensare perché cambia il contesto, acquisiscono maggiori informazioni sull'ambiente e sulla
tecnologia e vedono dimostrazioni intermedie del prodotto in fase di sviluppo.
Un ciclo di vita iterativo consente di apportare modifiche tattiche al prodotto. Ad esempio, per competere con i
prodotti esistenti, si può decidere di rilasciare un prodotto con funzioni ridotte per contrastare uno spostamento da
parte di un concorrente oppure adottare un altro fornitore per una certa tecnologia.
L'iterazione consente anche modifiche tecnologiche durante il percorso. Se la tecnologia viene modificata o diviene uno
standard con l'arrivo di una nuova tecnologia, il progetto può trarne profitto. Questo è specialmente il caso di
modifiche di piattaforma e modifiche di infrastruttura di basso livello.
L'approccio iterativo determina una struttura più solida poiché gli errori vengono corretti in varie iterazioni. Gli
errori iniziali vengono rilevati durante la creazione del prodotto nelle iterazioni iniziali. I colli di bottiglia
nelle prestazioni vengono individuati e possono essere ridotti, al contrario di quanto accade se vengono individuati
alla vigilia della consegna.
Lo sviluppo in modo iterativo, al contrario di quanto accade con l'esecuzione di test solo verso la fine del progetto,
determina un prodotto interamente verificato. Le funzioni critiche sono state verificate più volte in varie iterazioni
e gli stessi test ed il software di test sono stati potenziati.
Gli sviluppatori possono imparare durante il percorso e le varie competenze e specializzazioni vengono impiegate più
pienamente durante l'intero ciclo di vita.
Anziché attendere a lungo eseguendo pianificazioni e affinando i propri skill, i tester iniziano presto ad eseguire i
test, la programmazione inizia presto e così via. La necessità di ulteriore formazione tecnica o di guida esterna viene
rilevata nelle analisi di valutazione iniziale delle iterazioni.
Lo stesso progetto può essere migliorato e perfezionato durante lo sviluppo. La valutazione al termine di un'iterazione
non riguarda solo lo stato del progetto in termini di tempi, ma analizza anche le esigenze di modifica
nell'organizzazione e i processi da migliorare nell'iterazione successiva.
Un ciclo di vita iterativo facilita il riutilizzo. È più facile identificare parti comuni quando vengono parzialmente
progettate o implementate che doverle identificare tutte in anticipo.
L'identificazione e lo sviluppo di parti riutilizzabili è difficile. Le revisioni di progettazione nelle iterazioni
iniziali consentono agli architetti di software di identificare un riutilizzo potenziale non previsto e le iterazioni
successive consentono di sviluppare ulteriormente le parti comuni.
L'approccio iterativo consente di trarre profitto dai prodotti commerciali esterni. Esistono diverse iterazioni per
selezionarli, integrarli e adattarli all'architettura.
|