Un'iterazione racchiude tutti i compiti di sviluppo che portano ad una versione eseguibile release-a stabile del
prodotto, insieme agli altri elementi periferici necessari per utilizzare questo rilascio. Quindi un'iterazione di
sviluppo è in alcuni casi un passo completo verso tutte le discipline: Requisiti, Analisi & progettazione,
Implementazione, e Verifica almeno. E' come un piccolo progetto a cascata. Notare che i criteri di valutazione sono
stabiliti quando viene pianificata ogni iterazione. Il rilascio avrà una capacità pianificata che è dimostrabile. La
durata di un'iterazione varia in base alla dimensione e alla natura del progetto, ma è probabile che verranno costruiti
più build in ogni iterazione, come specificato nella Pianificazione del build di integrazione per l'iterazione. Questa è
una conseguenza del continuo approccio di integrazione consigliati in RUP (Rational Unified Process): quando i
componenti testati a livello di unità diventano disponibili, questi sono integrati, quindi viene prodotto un build
soggetto poi a verifica di integrazione. In questo modo, la capacità del software integrato cresce a mano a mano che
l'iterazione procede verso gli obiettivi impostati quando è stata pianificata l'iterazione. Si può dimostrare che ogni
build in se stesso rappresenta una mini iterazione richiesta e la formalità della valutazione eseguita. Potrebbe essere
appropriato e conveniente, in alcuni progetti, costruire build su basi giornaliere, ma queste non rappresenterebbero
iterazioni come RUP le definisce - fatta eccezione, forse, per un progetto molto piccolo per una singola persona. Anche
per progetti piccoli per più persone (ad esempio, coinvolgere cinque persone che creano 10,000 righe di codice),
sarebbe molto difficile raggiungere una durata di iterazione di meno di una settimana. Per ulteriori spiegazioni,
consultare Linea
guida: Piano di sviluppo software.
Tradizionalmente, i progetti sono stati organizzati per passare attraverso tutte le discipline in sequenza solo per una
volta. Questo porta al ciclo di vita a cascata:
Questo spesso risulta in un accumulo di integrazione tardi all'interno dell'implementazione quando, per la prima volta,
il prodotto viene creato e la verifica ha inizio. I problemi che restano nascosti nell'Analisi, progetto e
implementazione risalgono a galla e il progetto si blocca quando inizia un ciclo di correzione del problema.
Un modo più flessibile (e meno rischioso) di procedere è di attraversare diverse volte le varie discipline di sviluppo,
creando una conoscenza migliore dei requisiti, costruendo una solida architettura, costruendo l'organizzazione di
sviluppo e infine consegnando una serie di implementazioni gradualmente più complete. Questo viene chiamato ciclo di
vita interattivo. Ogni passo nella sequenza delle discipline di processo, viene chiamato iterazione.
Quindi, da una prospettiva di sviluppo il ciclo di vita del software è una successione di iterazioni, tramite le
quali il software si sviluppa in modo incrementale. Ogni iterazione si conclude con il rilascio di un prodotto
eseguibile. Questo prodotto potrebbe essere un sottoinsieme della visione completa, ma utile da una prospettiva di
costruzione o dell'utente. Ogni rilascio viene accompagnato dai prodotti di lavoro di supporto: descrizione del
rilascio, documentazione utente, piani, e così via, e modelli aggiornati del sistema.
La conseguenza principale di questo approccio iterativo è che i prodotti di
lavoro, descritti precedentemente, crescono e si sviluppano nel tempo, come mostrato nel seguente diagramma.
Evoluzione insieme di informazioni nelle fasi di sviluppo.
Punti cardine secondari
Ogni iterazione è conclusa da un punto cardine secondario, dove il risultato dell'iterazione viene valutato in base ai
criteri di successo dell'obiettivo di quella particolare iterazione.
|