Rational Unified Process

Ing. R. Turco

Introduzione

Il Rational Unified Process (RUP) è un framework di processo per lo sviluppo del software, che
provvede a disciplinare:
 la tipologia di ciclo produttivo;
 le responsabilità nell’ambito dell’organizzazione;
 le attività necessarie;
 gli elaborati da ottenere;
 il workflow;
 la pianificazione.

Il RUP permette, inoltre, di concentrarsi su:

 rischi;
 criticità;
 priorità.

In altri termini il Rational Unified Process permette la gestione del processo relativamente allo
sviluppo del software.

Essendo il RUP un framework è, quindi, adattabile alle esigenze della propria organizzazione e
alla cultura esistente in essa.

RUP: una struttura a due dimensioni

Il RUP è essenzialmente una struttura a due dimensioni (fig. 1).

Figura 1

Le due dimensioni del RUP sono:

 il tempo (asse orizzontale);
 le attività (asse verticale).

Nel tempo abbiamo quattro fasi:

1
Copyright 2003 – R. Turco
  Ideazione o avvio (Inception);
 Elaborazione (Elaboration);
 Costruzione o sviluppo (Construction);
 Transizione o rilascio (Transition).

L’asse orizzontale (tempo) dà l’aspetto dinamico del processo e richiama ad una ovvia
pianificazione temporale; difatti si parla di fasi, iterazioni e milestone.

L’asse verticale rappresenta i principali workflow del processo RUP (ne potrebbero esistere
anche altri per esigenze organizzative particolari) ed i workflow di supporto.

I workflow principali sono quelli che permettono la realizzazione diretta del prodotto e sono:
 Business Modeling;
 Requisiti;
 Analisi e progettazione;
 Realizzazione e test;
 Rilascio

I principali workflow di supporto sono quelli che non partecipano direttamente alla creazione
del prodotto e sono ad esempio:
 Gestione della configurazione e modifiche
 Gestione del progetto
 Infrastruttura organizzativa

L’asse verticale richiama, in pratica, al carico di lavoro di una pianificazione e ad i suoi costi.

Nel workflow di supporto potrebbero essere comprese anche altre voci. Se su questo esiste
accordo col cliente, non si rischia di sottostimare i valori in gioco.

Le “Best Practice” del RUP

Il RUP considera come buona pratica le seguenti cose:
 Uno sviluppo iterativo
 La gestione dei requisiti
 Un’architettura a componenti
 UML e modellazione
 Qualità del processo e del prodotto
 Gestione della configurazione e delle modifiche
 Uno sviluppo guidato dai casi d’uso
 La configurazione del processo
 Gli strumenti di supporto

Sviluppo iterativo
Uno sviluppo iterativo ha molti vantaggi:
 Reagisce bene alle variazioni dei requisiti;
 Segue la filosofia che “una balena va mangiata a piccoli bocconi”;
 Le parti sviluppate vengono integrate progressivamente ad ogni iterazione;
 I rischi o le criticità vengono al pettine subito: se sono insormontabili il processo ha
“bruciato” poche risorse;
 Il management è in grado di prendere decisioni tattiche al momento giusto, nell’ambito
della strategia concordata col cliente;
 Facilita il riuso sia perché è più facile individuare parti piccole sviluppate da riusare, ma
anche perché piccole iterazioni portano a sviluppare poche cose e, quindi, a
documentarle;
 Le iterazioni permettono revisioni di progettazione e di refactoring, individuando pattern
e parti di codice da migliorare;
2
Copyright 2003 – R. Turco
  L’architettura ottenibile è più robusta: vengono individuati gli errori e rimossi nelle varie
fasi di test, ad ogni iterazione.
 Le iterazioni consentono agli sviluppatori di apprendere il dominio, le tecnologie, gli
strumenti e le metodologie. Piccole iterazioni comportano poche cose da produrre ma
anche poche cose da apprendere;
 Ad ogni iterazione può essere migliorato il proprio processo produttivo.

Gestione dei requisiti

La gestione dei requisiti è un processo importante per individuare, organizzare, tracciare,
comunicare, classificare (priorità, rischi, criticità) i requisiti del sistema in gioco.

I vantaggi principali sono:

 Informazioni disponibili a tutto il team;
 Miglior controllo del sistema e del progetto;
 Migliore qualità del software e soddisfazione del cliente.

Architettura e architettura a componenti

L’Architettura è la parte fondamentale del processo produttivo: un’architettura solida è una
delle premesse di successo!

Lo sforzo del RUP è di ottenere subito la giusta architettura e, poi, nelle varie iterazioni le
funzionalità del sistema; in ogni iterazione è da ottenere qualcosa che è funzionalmente utile
dal punto di vista del cliente.

L’architettura è, comunque, slegata dai requisiti funzionali e legata soprattutto ai requisiti non
funzionali: prestazioni, vincoli, etc.

L’architetto è, difatti, colui che ha la visione d’insieme di quello che vuole il cliente ma che
bada innanzitutto a far sì che l’architettura pensata sia da subito in grado di soddisfare i
requisiti non funzionali ed i vincoli in gioco.

Ambire ad avere una architettura a componenti è il massimo a cui tendere.

Un componente software è un elemento non banale, un package, un sotto-sistema oppure

addirittura un framework da riusare nel proprio dominio del problema.

Con le nuove Infrastrutture CORBA, Enterprice JavaBeans oggi è possibile farlo attraverso una
miriade di prodotti commerciali ed open source.

UML e modellazione
Il processo ha bisogno di un linguaggio che serva a comunicare, documentare, rappresentare e
specificare un business, un sistema, etc.

Il linguaggio è l’UML versione 1.4/2.0. Dispone di elementi sintattici, semantici e possibilità di

esprimere vincoli attraverso l’OCL.

Con l’UML il RUP tende a realizzare modelli del sistema da realizzare.

Qualità del processo e del prodotto

Il RUP, ma anche l’ISO 9000, insistono col NON individuare un ruolo responsabile della qualità:
la qualità deve essere responsabilità di tutti coloro che intervengono in un processo alla
realizzazione di un prodotto o di un servizio!!

3
Copyright 2003 – R. Turco
La qualità di un prodotto è rappresentata da tutti gli elementi che concorrono alla realizzazione
di un prodotto e al loro corretto utilizzo. La qualità di un prodotto è correlata a vari fattori
come il tempo, gli skill, gli strumenti, le metodologie, le teorie adottate etc.

La qualità di un processo dipende da come un processo produttivo è stato “configurato” ed

applicato. La qualità di un processo è correlata con la qualità degli elaborati sviluppati a
supporto della realizzazione del prodotto, ad esempio: piani di iterazioni, piani di test, i casi
d’uso, il modello di progettazione etc. Un processo configurato deve avere metriche e criteri
qualitativi. Solo avendo delle metriche si riesce a misurare e verificare la qualità del proprio
processo.

Gestione della configurazione e delle modifiche

In uno sviluppo iterativo le modifiche sono frequenti. In un progetto medio-grande il numero
degli oggetti sviluppati e modificati è elevato. Possono essere in sviluppo baseline diverse
contemporaneamente agenti su un’intersezione comune di oggetti e richiedere propagazioni di
modifiche da una release all’altra.

Senza un sistema di gestione della configurazione e delle modifiche (anomalie, richieste di

modifica, etc) la cosa diventa complicata.

La scelta di uno strumento efficiente ed efficace di gestione della configurazione condiziona

molto lo sviluppo, il test ed il rilascio.

Sviluppo guidato dai casi d’uso

Gli Use Case nell’Object oriented non sono necessari. Il RUP ha un approccio guidato dagli Use
case sia perché fanno parte dell’UML sia per il ruolo chiave d’immediatezza grafica nei requisiti
e nel Business Modeling.

Configurazione del processo

Il RUP propone un processo che va adattato alle proprie esigenze per:
 Responsabilità;
 Attività e workflow;
 Elaborati;

In qualunque modo si configura il processo, esso mantiene comunque le quattro fasi prima
viste.

Strumenti di supporto
Una volta deciso di usare il RUP, quindi, UML occorre scegliere degli strumenti che aiutano a
lavorare in tale senso.

Il Processo del RUP

Un processo risponde efficacemente alle domande:
 Chi? (i ruoli);
 Come? (le attività)
 Quando? (i workflow)
 Che cosa? (gli elaborati).

I ruoli
Un ruolo è il comportamento e la responsabilità di un individuo all’interno di un team. Un ruolo
non significa che l’individuo sia diventato più importante, ma solo che ha la responsabilità di
comportarsi in un modo ben definito dall’organizzazione e di effettuare determinate attività.

4
Copyright 2003 – R. Turco
Il mondo dell’Object Oriented insegna molto. Una persona con un ruolo è come una classe che
ha delle responsabilità (metodi). Ogni metodo fa delle attività e dà dei ritorni (feedback ed
elaborati), di propria iniziativa.

Il ruolo è affidato alla persona che è in grado (competente) di svolgere una determinata
attività nei tempi, nella qualità e nei risultati attesi.

I ruoli pensati dal RUP sono:

 Amministratore di sistema (System Administrator);
 Analista dei casi d’uso (Use-Case Specifier);
 Analista dei processi di business (Business-Process Analyst);
 Analista di sistema (System Analyst);
 Architetto (Architect);
 Configuratore degli strumenti di sviluppo (Toolsmith);
 Ingegnere di processo (Process Engineer);
 Integratore di sistema (System Integrator);
 Progettista (Designer);
 Progettista dei corsi (Course Developer);
 Progettista dei test (Test Designer);
 Progettista del database (Database Designer);
 Progettista delle interfacce utente (User-Interface Designer);
 Progettista di business (Business Designer);
 Redattore di documentazione tecnica (Technical Writer);
 Responsabile del rilascio (Deployment Mnager);
 Responsabile dell ageastione della configurazione (Configuration Manager);
 Responsabile di progetto (Project Manager);
 Revisore dei modelli di business (Business-Model Reviewer);
 Revisore dei requisiti (Requirements Reviewer);
 Revisore del codice (Code Reviewer);
 Revisore dell’architettura (Architecture Reviewer);
 Revisore di progettazione (Design Reviewer);
 Sviluppatore (Implementer);
 Tecnico dei test d’integrazione (Integration Tester);
 Tecnico dei test prestazionali (Performance Tester);
 Tecnico di test di sistema (System Tester).

Una stessa persona può rivestire più ruoli, in base alle proprie competenze.

Le attività
Ogni attività prevede due o al più tre step:
 studio del compito;
 esecuzione;
 revisione.

I workflow
Un workflow è una sequenza di attività che produce un risultato di valore osservabile.

In UML un workflow è schematizzabile con un diagramma di sequenza oppure un diagramma

delle attività.

Nel seguito esamineremo uno dei workflow più delicati, quello di gestione di un progetto.

Gli elaborati
Gli elaborati (“artifact”) sono gli output di ogni attività che possono essere input per l’attività
successiva e facente capo anche ad un ruolo diverso.

5
Copyright 2003 – R. Turco
Gli output possono essere documenti, modelli, codice, progettazione test, etc.

Il RUP cerca di minimizzare allo stretto necessario i documenti, nel senso che cerca di
mantenere la maggior parte della documentazione all’interno degli strumenti stessi usati per la
produzione. In altri termini il RUP favorisce soprattutto la generazione di documenti grazie agli
strumenti che si utilizzano.

In ogni caso la documentazione è necessaria sia essa cartacea, che nel software per facilitare
la comprensione ed il riuso, etc.

Il RUP non dice di eliminarla, ma cerca di alleggerire tale attività facendola produrre
automaticamente se possibile. In questo modo essa è facilmente allineabile dagli strumenti
stessi ad ogni iterazione per i test, per i modelli, etc. Questo alleggerimento di parte del
processo si riflette su una riduzione dei costi.

Elementi addizionali del processo

Un processo da solo non basta. Spesso occorrono elementi addizionali per rendere ripetibile e
usabile un processo da qualsiasi skill.

Gli elementi che, a seconda dei casi, si possono aggiungere in un processo possono essere:
 Linee guida;
 Modelli o Template;
 Guide all’uso degli strumenti (tool mentor);
 Teorie documentate;
 Checklist;
 Metriche.

L’Architettura
L’Architettura gioca un ruolo centrale nel RUP.

Il RUP cerca di dare risposta ad almeno tre delle seguenti domande:

 Perché è importante l’architettura?
 Come si rappresenta l’architettura?
 Quale deve essere il processo per creare e validare un’architettura?

In realtà la scelta di un’architettura coinvolge diversi elementi:

 organizzazione del software;
 scelta degli elementi strutturali del sistema, delle interfacce e del comportamento con
l’esterno;
 Prestazioni;
 Stabilità e robustezza;
 Scalabilità;
 Riuso;
 Comprensibilità;
 Usabilità;
 Vincoli tecnologici ed economici;
 Considerazioni di “stile architetturale” (Pattern, etc.);

In altri termini l’architettura si concentra su aspetti:

 Strutturali;
 Organizzativi;
 non funzionali;
 economici;
 sociologici;
 estetici.

6
Copyright 2003 – R. Turco
Perché l’architettura è importante? Il RUP risponde alla domanda nel seguente modo:
 L’architettura rappresenta come il sistema verrà realizzato e fornisce al sistema gli
aspetti qualitativi, la flessibilità ai cambiamenti, il riuso, le sue prestazioni.

Come si rappresenta un’architettura? Un’architettura ha almeno 4+1 viste in gioco e ruoli

diversi interessati per ogni vista (fig. 2).
Programmatori
Utente finale Gestione
Funzionalità Configurazione

Vista logica Vista

Vista dei d’implementazione
casi d’uso
Analisti/Tester
Comportamento Vista di processo Vista di rilascio

Integratori Ingegneri di sistema

Prestazioni Consegna
Scalabilità Installazione
Throughput

Figura 2

Vista logica
La vista logica si occupa dei requisiti funzionali. Qui di un’architettura vengono individuati i
package, i sottosistemi e le classi principali.

Vista d’implementazione
Questa vista per un’architettura descrive l’organizzazione dei moduli software (sorgenti, file
dati, librerie, componenti, alberature, etc), livelli di astrazione, gestione della configurazione.
Questa vista esige la “facilità di sviluppo”, la gestione del software, il riuso, la gestione dei
fornitori, l’utilizzo di componenti di mercato.

Vista di processo
Qui ci si occupa dei requisiti non funzionali: concorrenza, parallelismo, deadlock, thread,
prestazioni, scalabilità, throughput, isolamento dei guasti, “single point of failure”, etc.

Vista di rilascio
Qui vengono affrontate problematiche di rilascio, installazione, gestione.

Vista dei casi d’uso

Alcuni casi d’uso possono essere importanti ai fini chiarificatrici di un’architettura.

Inoltre ad ogni vista corrispondono modelli UML diversi, come nella tabella seguente.

Modello Vista
Modello di progettazione Vista logica
Vista di processo
Modello di implementazione Vista di implementazione
Modello di rilascio Vista di rilascio
Modello dei casi d’uso Vista dei casi d’uso

Come si valida un’architettura?

7
Copyright 2003 – R. Turco
Ci si basa sui seguenti step:
 Si descrive in documento di Descrizione di Architettura Software o Descrizione Tecnica
di prodotto;
 Si fa un primo prototipo o un modello funzionante, badando solo alle parti architetturali.
Il modello può essere sia a soli fini interni o anche fatto vedere al cliente. Il modello,
tramite refactoring, viene raffinato iterativamente e quello validato farà da baseline
giuda per il resto dello sviluppo.

Qui l’esperienza di una persona con ruolo di architetto è fondamentale.

Workflow di gestione del progetto

8
Copyright 2003 – R. Turco
INDICE
RATIONAL UNIFIED PROCESS .................................................................................... 1
INTRODUZIONE .......................................................................................................... 1
RUP: UNA STRUTTURA A DUE DIMENSIONI ................................................................ 1
LE “BEST PRACTICE” DEL RUP .................................................................................... 2
SVILUPPO ITERATIVO ........................................................................................................................ 2
GESTIONE DEI REQUISITI ................................................................................................................... 3
ARCHITETTURA A COMPONENTI ........................................................................................................ 3
UML E MODELLAZIONE .................................................................................................................... 3
QUALITÀ DEL PROCESSO E DEL PRODOTTO ........................................................................................ 3
GESTIONE DELLA CONFIGURAZIONE E DELLE MODIFICHE .................................................................. 4
SVILUPPO GUIDATO DAI CASI D’USO .................................................................................................. 4
CONFIGURAZIONE DEL PROCESSO ..................................................................................................... 4
STRUMENTI DI SUPPORTO .................................................................................................................. 4
IL PROCESSO DEL RUP ............................................................................................... 4
I RUOLI .............................................................................................................................................. 4
LE ATTIVITÀ ...................................................................................................................................... 5
I WORKFLOW ..................................................................................................................................... 5
GLI ELABORATI ................................................................................................................................. 5
ELEMENTI ADDIZIONALI DEL PROCESSO ................................................................... 6
WORKFLOW DI GESTIONE DEL PROGETTO ................................................................. 6

9
Copyright 2003 – R. Turco