Rational Unified Process

Da Wikipedia, l'enciclopedia libera.

Il Rational Unified Process (RUP) (che è una estensione dello Unified Process) è un modello di processo software iterativo sviluppato da Rational Software (oggi parte di IBM). Il RUP non definisce un singolo, specifico processo, bensì un framework adattabile che può dar luogo a diversi processi in diversi contesti (per esempio in diverse organizzazioni o nel contesto di progetti con diverse caratteristiche). È pensato soprattutto per progetti di grandi dimensioni. RUP è rilasciato in formato di guida ipertestuale, ed è incluso nel prodotto IBM Rational Method Composer (RMC), che permette anche la personalizzazione del processo.

Contesto[modifica | modifica wikitesto]

I creatori del RUP partirono dalla diagnosi di un campione di progetti software falliti, allo scopo di identificare cause tipiche o generali di fallimento. Quindi confrontarono questa informazione con la struttura dei processi software descritti in letteratura e applicati nella pratica, cercando di identificare le soluzioni proposte precedentemente. L'elenco dei motivi di fallimento identificati comprende per esempio:

  • Gestione ad hoc (non standard) dei requisiti
  • Comunicazione ambigua e non precisa
  • Architettura fragile (incapace di sopportare situazioni di particolare criticità)
  • Incapacità di gestire la complessità
  • Inconsistenze nei requisiti, nel progetto o nelle implementazioni
  • Collaudo insufficiente
  • Valutazione soggettiva dello stato del processo
  • Incapacità di affrontare il rischio
  • Propagazione non controllata delle modifiche
  • Insufficiente automazione

Il RUP si può descrivere come una collezione di best practice mirate a evitare questi e altri problemi, e come un ambiente di gestione dei processi che facilita l'applicazione di tali pratiche. Il processo fu progettato utilizzando strumenti tipici della progettazione del software; in particolare, esso fu descritto in termini di un metamodello object-oriented, espresso in UML.

Concetti fondamentali[modifica | modifica wikitesto]

Nel RUP, il ciclo di vita di un processo software viene suddiviso in cicli di sviluppo, a loro volta scomposti in fasi. Le fasi previste sono:

  • Inception Phase (fase iniziale)
  • Elaboration Phase (fase di elaborazione)
  • Construction Phase (fase di costruzione)
  • Transition Phase (fase di transizione)

Ogni fase ha un certo insieme di obiettivi e si conclude con la realizzazione di un deliverable (prodotto) di qualche genere. Le fasi sono ulteriormente scomposte in iterazioni, che sono associate a periodi temporali e hanno scadenze precise.

Fase iniziale[modifica | modifica wikitesto]

L'Inception Phase si può considerare come una particolare elaborazione e precisazione del concetto generale di analisi di fattibilità. Lo scopo principale è quello di delineare nel modo più accurato possibile il business case, ovvero comprendere il tipo di mercato al quale il progetto afferisce e identificare gli elementi importanti affinché esso conduca a un successo commerciale. Fra gli strumenti utilizzati ci sono un modello dei casi d'uso, la pianificazione iniziale del progetto, la valutazione dei rischi, una definizione grossolana dei requisiti e così via. Se il progetto non supera questa milestone, detta "Lifecycle Objective Milestone", esso dovrà essere abbandonato o ridefinito.

Fase di elaborazione[modifica | modifica wikitesto]

La fase di elaborazione definisce la struttura complessiva del sistema. Questa fase comprende l'analisi di dominio e una prima fase di progettazione dell'architettura. Questa fase deve concludersi con il superamento di una milestone detta "Lifecycle Architecture Milestone". A questo scopo devono essere soddisfatti i seguenti criteri:

  • deve essere stato sviluppato un modello dei casi d'uso completo all'80%
  • dev'essere fornita la descrizione dell'architettura del sistema
  • dev'essere stata sviluppata un'"architettura eseguibile" che dimostri il completamento degli use case significativi
  • dev'essere eseguita una revisione del business case e dei rischi
  • dev'essere completata una pianificazione del progetto complessivo

Se il progetto non passa questa milestone, potrebbe ancora essere abbandonato, oppure dovrà essere rivisitato. Al termine di questa fase si transita infatti in una situazione di rischio più elevato, in cui le modifiche all'impostazione del progetto saranno più difficili e dannose.

Fase di costruzione[modifica | modifica wikitesto]

In questa fase viene portato a termine il grosso degli sviluppi. Viene prodotta la prima release del sistema. La milestone di questa fase si chiama "Initial Operational Capability" e rappresenta la prima disponibilità delle funzionalità del sistema in termini di implementazione.

Fase di transizione[modifica | modifica wikitesto]

Nella fase di transizione, il sistema passa dall'ambiente dello sviluppo a quello del cliente finale. Vengono condotte le attività di training degli utenti e il beta testing del sistema a scopo di verifica e validazione. Si deve in particolare verificare che il prodotto sia conforme alle aspettative descritte nella fase di Inception. Se questo non è vero si procede a ripetere l'intero ciclo; altrimenti, si raggiunge la milestone detta "Product Release" e lo sviluppo termina.

Iterazioni[modifica | modifica wikitesto]

Tipicamente, un progetto gestito usando il RUP viene suddiviso in iterazioni. Questa scomposizione presenta numerosi vantaggi (in particolare rispetto alla valutazione dell'avanzamento del progetto e alla gestione dei fattori di rischio) ma implica un overhead specifico. Il RUP definisce una "Project Management Discipline" (disciplina di gestione dei progetti) a cui il project manager può affidarsi per amministrare le iterazioni.

Aspetti statici del RUP[modifica | modifica wikitesto]

Il metamodello applicato dal RUP per descrivere e controllare un processo utilizza quattro concetti cosiddetti "statici", ovvero che sono definiti nello stesso modo per tutti i processi:

  • Ruoli. Un ruolo identifica un certo insieme di responsabilità attribuite a un certo insieme di partecipanti al progetto. (I ruoli rispondono alla domanda chi?)
  • Artefatti (artifacts). Gli artefatti sono il prodotto delle attività del processo; includono documenti, modelli, componenti software e via dicendo. (Gli artefatti rispondono alla domanda cosa?)
  • Workflow. Un workflow è una sequenza di attività. (I workflow rispondono alla domanda quando?)
  • Attività. Le attività sono i compiti specifici portati a termine dai partecipanti del progetto. (Le attività rispondono alla domanda come?)


Voci correlate[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]