Rational Unified Process

IlRational Unified Process(RUP) (che è una estensione delloUnified Process) è unmodello di sviluppo del softwaredi tipo iterativo, sviluppato daRational Software(oggi parte diIBM). Il RUP non definisce un singolo, specifico processo, bensì unframeworkadattabile 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 è prodotto in formato di guida ipertestuale, ed è incluso nel prodotto IBM Rational Method Composer (RMC), che permette anche la personalizzazione del processo.

Contesto

I creatori del RUP partirono dalladiagnosidi 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:

• Gestionead hoc(non standard) dei requisiti
• Comunicazione ambigua e non precisa
• Architetturafragile(incapace di sopportare situazioni di particolare criticità)
• Incapacità di gestire la complessità
• Inconsistenze neirequisiti,nelprogettoo nelleimplementazioni
• Collaudoinsufficiente
• Valutazione soggettiva dello stato del processo
• Incapacità di affrontare il rischio
• Propagazione non controllata delle modifiche
• Insufficienteautomazione

Il RUP si può descrivere come una collezione dibuone pratichemirate 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 dellaprogettazione del software;in particolare, esso fu descritto in termini di unmetamodelloobject-oriented,espresso inUML.

Concetti fondamentali

Nel RUP, ilciclo di vita del softwareviene suddiviso incicli di sviluppo,a loro volta scomposti infasi.Le fasi previste sono:

• Fase iniziale(inception phase)
• Fase di elaborazione(elaboration phase)
• Fase di costruzione(construction phase)
• Fase di transizione(transition phase)

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

Fase iniziale

La fase iniziale si può considerare come una particolare elaborazione e precisazione del concetto generale dianalisi di fattibilità.Lo scopo principale è quello di delineare nel modo più accurato possibile ilbusiness 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 deicasi d'uso,la pianificazione iniziale del progetto, la valutazione dei rischi, una definizione grossolana dei requisiti e così via. Se il progetto non supera questamilestone,detta "Lifecycle Objective Milestone", esso dovrà essere abbandonato o ridefinito.

Fase di elaborazione

La fase di elaborazione definisce la struttura complessiva del sistema. Questa fase comprende l'analisi di dominioe una prima fase diprogettazionedell'architettura. Questa fase deve concludersi con il superamento di unamilestonedetta "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

In questa fase viene portato a termine il grosso degli sviluppi. Viene prodotta la primareleasedel 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

Nella fase di transizione, il sistema passa dall'ambiente dello sviluppo a quello delcliente finale.Vengono condotte le attività ditrainingdegli utenti e ilbeta testingdel sistema a scopo di verifica e validazione. Si deve in particolare verificare che il prodotto sia conforme alle aspettative descritte nella fase diInception.Se questo non è vero si procede a ripetere l'intero ciclo; altrimenti, si raggiunge lamilestonedetta "Product Release" e lo sviluppo termina.

Iterazioni

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 unoverheadspecifico. Il RUP definisce una "Project Management Discipline" (disciplina di gestione dei progetti) a cui ilresponsabile di progettopuò affidarsi per amministrare le iterazioni.

Aspetti statici del RUP

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 domandachi?)
• Artefatti(artifacts). Gli artefatti sono il prodotto delle attività del processo; includono documenti, modelli, componenti software e via dicendo. (Gli artefatti rispondono alla domandacosa?)
• Workflow.Unworkflowè una sequenza di attività. (I workflow rispondono alla domandaquando?)
• Attività.Le attività sono i compiti specifici portati a termine dai partecipanti del progetto. (Le attività rispondono alla domandacome?)

Voci correlate

• Ingegneria del software
• Sviluppo software
• Componente software
• Ciclo di vita del software
• Architettura software
• Qualità del software
• Extreme Programming
• Agile Unified Process
• Enterprise Unified Process
• Metodologia agile
• Open Unified Process
• Project management

Collegamenti esterni

• Rational Software,surational.com.URL consultato il 29 marzo 2006(archiviato dall'url originaleil 10 dicembre 1997).
• Rational Unified Processpresso "IBM" (PDF)
• "Understanding the Unified Process",sumethodsandtools.com.
• Rational Unified Process

Controllo di autorità	GND(DE)4560513-0