Processo di sviluppo software incrementale
Non è certo chi sia stato il vero ideatore, ma una delle prime presentazioni è quella di Barry Boehm, nel 1981 ("Software Engineering Economics", editore Prentice Hall).
La figura riportata sotto (un activity diagram UML) non rappresenta la versione originale del processo, ma una delle sue derivazioni più diffuse.
E' una derivazione del processo di sviluppo a cascata (Waterfall).
Completata la fase di analisi, viene effettuata una attività di design dell'architettura del sistema. Vengono, cioè, effettuate le scelte "di alto livello" relative alla strutturazione del sistema in (macro)parti distinte (sottosistemi), definite le responsabilità di ciascun sottosistema, le modalità di dialogo (interfacce) tra i diversi sottosistemi.
A questo punto vengono definite delle priorità di realizzazione, sulla base di due aspetti:
- priorità di natura funzionale (relativa alle esigenze dei committenti e delle parti interessate)
- priorità di natura architetturale (se un sottosistema A necessita del sottosistema B per funzionare, B ha una priorità superiore)
Sulla base delle priorità definite, il progetto viene articolato in una serie di sottoprogetti realizzativi, ciascuno dei quali produrrà uno o più sottosistemi (parti del sistema complessivo).
I sottoprogetti realizzativi potranno essere condotti in sequenza rigida (uno dopo l'altro), oppure essere condotti parzialmente in parallelo (con sovrapposizioni temporali).
Diffusione del processo incrementale
Viene spesso utilizzato, in progetti di complessità medio-grande, come variante di un processo a cascata, in quanto costituisce un modo di ridurne i rischi.
Vantaggi
Rispetto al processo a cascata, permette di arrivare a consegnare qualcosa di concreto prima di aver completato l'intero sistema. In questo modo si ottengono feedback (riscontri) concreti, con indicazioni utilizzabili anche nei sottoprogetti realizzativi ancora in corso o successivi. E si riducono i rischi di insuccesso.
L'articolazione del piano di progetto è più complessa (rispetto al processo di sviluppo a cascata), ma permette una maggiore flessibilità nell'assegnazione delle persone ai compiti progettuali, quando i sottoprogetti vengono pianificati con una parziale sovrapposizione temporale.
Svantaggi
Condivide con il processo a cascata le due assunzioni - erronee - che:
- sia possibile definire tutti i requisiti alla partenza del progetto, senza entrare con i committenti e le altre parti interessate nel merito delle soluzioni concrete
- i requisiti non cambino dopo che sono stati concordati
Torna a pagina introduttiva processo