Il Rational Unified Process (RUP) (che è una estensione dello Unified Process) è un modello di sviluppo del software di tipo 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 è prodotto in formato di guida ipertestuale, ed è incluso nel prodotto IBM Rational Method Composer (RMC), che permette anche la personalizzazione del processo.

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 buone pratiche 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.

Nel RUP, il ciclo di vita del software viene suddiviso in cicli di sviluppo, a loro volta scomposti in fasi. 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 un deliverable (prodotto) di qualche genere. Le fasi sono ulteriormente scomposte in iterazioni, che sono associate a periodi temporali e hanno scadenze precise.

La fase iniziale 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.

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.

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.

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.

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 responsabile di progetto può affidarsi per amministrare le iterazioni.

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?)

• 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

• Rational Software, su rational.com. URL consultato il 29 marzo 2006 (archiviato dall'url originale il 10 dicembre 1997).
• Rational Unified Process presso "IBM" (PDF)
• "Understanding the Unified Process" ^{[collegamento interrotto]}, su methodsandtools.com.
• Rational Unified Process