Ciclo di vita RUP
Questa pagina descrive le fasi e i cardini di un tipico ciclo di vita di un progetto RUP.
Relazioni
Descrizione principale

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:

  inizio elaborazione costruzione transizione
Impegno ~5 % 20 % 65 % 10%
Tempi 10 % 30 % 50 % 10%

che possono essere rappresentati graficamente come

Transizione Costruzione Elaborazione Inizio Fare clic su una fase per ulteriori informazioni

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

Diagramma descritto in accompanying text.

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

Diagramma descritto in accompanying text.

Questa strategia è appropriata quando:

  • Il dominio del problema è nuovo o poco familiare
  • Il team del progetto non è esperto

Modello di ciclo di vita: Produzione incrementale 

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

Diagramma descritto in accompanying text.

Questa strategia è appropriata quando:

  • Il dominio del problema è ben noto:

    • l'architettura e i requisiti possono essere stabilizzati presto nel ciclo di sviluppo
    • è presente un basso livello di novità nel problema
  • Il team è esperto.
  • I rilasci incrementali della funzionalità sono di grande importanza per il cliente.

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

Diagramma descritto in accompanying text.

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

Modello di ciclo di vita: Strategie ibride

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.

Grafico del diagramma di sviluppo iniziale

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.