Premessa
UMA (Unified Method Architecture) è stato sviluppato con l'intento di unificare lo schema di rappresentazione e la
terminologia di tutti gli approcci di progettazione di metodi e processi della IBM nonché di supportare i più
importanti standard industriali. Quindi, come illustrato nella figura successiva, UMA è stato sviluppato con uno
sforzo di collaborazione dei progettisti di IBM Rational Unified Process (RUP), IBM Global Services Method (GS Method)
e di IBM Rational Summit Ascendant. Oltre a questo gruppo principale di progettisti, hanno apportato il loro
contributo anche portatori d'interesse di molte altre iniziative di processi di sviluppo all'interno e all'esterno
della IBM. La specifica stessa è stata sottoposta a OMG come proposta per gli standard SPEM 2.0. Poiché il metamodello RUP 2003 è stato sviluppato in base allo standard
corrente SPEM 1.1, questa
proposta di bozza SPEM 2.0 può essere vista come una continua e significativa evoluzione di quello standard.
Lo scopo principale di questa unificazione era quello di giungere ad un insieme di termini e di strutture di dati che
consentissero a metodi e processi di essere espressi senza perdere le caratteristiche chiave. Ad esempio,
UMA fu sviluppato per supportare molti e differenti modelli di cicli di vita: il ciclo di vita di sviluppo iterativo di
RUP, cicli di vita incrementali di GS Method e cicli di vita iterativi di Summit Ascendant. Inoltre, c'era
bisogno di risolvere il problema delle differenze terminologiche: quello che in RUP era chiamato Attività, nel GS
Method era chiamato Operazione, RUP parlava di Artefatti laddove Summit Ascendant li definiva componenti distribuibili
e così via.
Modifiche apportate in UMA per gli utenti RUP 2003
Per poter definire un'unica struttura di dati e, cosa ancora più importante, per poter definire un'unica terminologia
per tutti questi approcci, è stato necessario che i portatori di interessi accettassero modifiche e compromessi.
Sebbene queste modifiche possano essere di disturbo agli utenti correnti di RUP, a lungo termine potranno trarne
benefici dall'uso di una terminologia unificata e ampiamente usata e da un modo standardizzato di esprimere il
contenuto del metodo e dei processi, migliorando le comunicazioni su di questi e facilitandone il riutilizzo.
L'elenco che segue riepiloga le modifiche più importanti apportate a RUP 2003 meta-model. La tabella alla fine di
questa pagina fornisce un confronto completo della terminologia di tutte i sorgenti chiave per UMA.
-
Le attività sono state ridenominate in operazioni: Per fornire un collegamento stretto alle regole
del processo e alla gestione del progetto, sono state ridenominate le più basse unità di lavoro assegnabili in
Operazione perché questo è il termine usato più comunemente.
-
I dettagli del flusso di lavoro sono stati ridenominati in Attività: I flussi di lavoro vengono
comunemente espressi in gerarchie di diagrammi di attività (ad es., i diagrammi di attività definiti in UML
2.0). Anche se RUP fornisce solo un livello di suddivisione del flusso di lavoro, UMA è progettato per
fornire livelli multipli di una suddivisione di questo tipo. Poiché il termine Attività è stato più comunemente
usato per esprimere gli elementi dei diagrammi dell'attività nonché i diagrammi di attività stessi, è stato deciso
di sostituire il termine Dettaglio del flusso di lavoro in RUP con il termine Attività. Comprendiamo che la
variazione nell'utilizzo del termine Attività possa causare confusione agli utenti RUP. Tuttavia, un
obiettivo importante di UMA è stato quello di usare termini nel modo usato più comunemente negli standard e
nell'industria.
-
I Compiti (precedentemente chiamate Attività in RUP) possono essere eseguiti da molti ruoli:
In RUP 2003 un'attività è stata modellata come operazione del ruolo. I feedback del cliente, un'analisi
degli altri approcci di modellazione del processo nonché le modifiche introdotte in UML 2.0 hanno indicato che
questo era un sistema troppo restrittivo per modellare i comportamenti umani. Questo approccio non consente
di esprimere che un lavoro è stato eseguito come collaborazione di ruoli differenti. UMA affronta questo
problema rendendo il Compito un elemento indipendente del modello a cui i ruoli esecutivi possono essere
assegnati come risorse. UMA pertanto non consente che ad un compito vengano assegnati ruoli diversi.
Per motivi di compatibilità con le versioni precedenti, consente ancora un ruolo di esecuzione principale da
identificare (l'essere responsabile di un compito) nonché di svariati esecutori aggiuntivi.
-
Miglioramento del concetto di Artefatto: RUP usava solo il concetto di artefatto per definire
quanto utilizzato e prodotto in un progetto di sviluppo. UMA definisce una tassonomia estesa per questi
concetti. Definisce il concetto di prodotto di lavoro, che ha tre differenti specializzazioni (tipi
specifici di prodotti di lavoro): Artefatti (prodotti di lavoro gestiti), Componenti distribuibili (prodotti di
lavoro impacchettati che verranno distribuiti ai portatori di interesse per l'analisi) e il Risultato (non gestito,
prodotti di lavoro intangibili).
-
Categorizzazioni differenti per prodotti di lavoro e ruoli: In RUP, gli artefatti ed i ruoli erano
tutti categorizzati per disciplina. Tuttavia, a volte gli artefatti venivano usati tra discipline e una
categorizzazione verso una sola disciplina causava confusione. In UMA, sono state definite categorie
differenti per le definizioni del lavoro (disciplina per operazioni ed attività), prodotti di lavoro (tipo prodotto
di lavoro e dominio) e ruoli (insiemi di ruoli).
-
Componenti del processo ridenominati in Pacchetto metodo: Il concetto di componente viene
comunemente utilizzato in molti standard e in molte tecnologie. La maggior parte delle applicazioni di un
componente lo collegano all'astrazione di incapsulamento, definendo un un componente come una scatola nera che può
essere utilizzata tramite interfacce ben definite. I componenti RUP non adempiono a questo criterio di scatola
nera. Anche lo standard SPEM ha definito i pacchetti nonché i componenti. Per essere compatibili con SPEM e con
l'uso industriale del termine componente, il Componente del processo è stato ridenominato in Pacchetto del metodo
(tecnicamente è un 'metodo' poiché può contenere elementi di metodo o elementi del processo).
-
Separazione degli elementi del contenuto del metodo dagli elementi del processo: In RUP
2003 era stato creato un nuovo processo tramite la definizione di una nuova configurazione e documentando
manualmente in un artefatto del caso di sviluppo le modifiche allo standard RUP. UMA fornisce concetti estesi
in aggiunta al concetto di configurazione per la personalizzazione dei processi. Consente di modellare
concretamente un processo che è definito nel contenuto del metodo che si vuole realmente eseguire in ogni fase,
poiché è facilmente possibile aggiungere, rimuovere e riordinare gli elementi nella struttura del processo,
riutilizzando o meno qualunque cosa si desideri dal contenuto del metodo. Ottiene queste funzioni con una più
chiara separazione del contenuto del metodo (ad es., i compiti definiti per discipline) e con l'applicazione del
contenuto del metodo nel processo (espresso con diagrammi di attività e/o strutture di partizionamento) nonché con
la modellazione di processi (ad es., creando diagrammi di attività nuovi o adattati oppure strutture di
partizionamento lavoro nuove o adattate). Introduce alcuni nuovi concetti come il descrittore che supporta
questa separazione e che raggiunge nuove capacità per la manutenzione e l'utilizzo di molte diverse famiglie di
processi alternativi e di parti di processo all'interno della stessa configurazione.
Terminologia a confronto
La seguente tabella mostra la mappa della terminologia UMA utilizzata in altri approcci di progettazione del processo.
|
UMA/RMC
|
RUP 2003
|
SUMMIT
|
IGSM
|
SPEM 1.1
|
Elementi metodo base
|
|
|
|
|
|
Ruolo
|
Ruolo
|
Ruolo
|
Ruolo
|
Ruolo del processo
|
Prodotto di lavoro
|
|
Componente distribuibile
|
|
|
Prodotto di lavoro/Artefatto
|
Artefatto
|
|
Descrizione del prodotto di lavoro
|
Prodotto di lavoro
|
Prodotto di lavoro/Risultato
|
|
|
Risultato operazione
|
|
Prodotto di lavoro/Componente distribuibile
|
|
|
Descrizione Componente distribuibile
|
|
Operazione
|
Attività
|
Attività
|
Operazione
|
Attività
|
Passo
|
Passo
|
Passo
|
Sotto-operazione
|
Passo
|
|
|
|
|
|
Processi correlati
|
|
|
|
|
|
Attività
|
Dettaglio flusso di lavoro
|
Operazione
|
Attività
|
Definizione lavoro
|
Iterazione
|
Iterazione
|
|
|
Iterazione
|
Fase
|
Fase
|
Fase
|
Fase
|
Fase
|
Pattern di capacità
|
|
|
Pattern di capacità
|
(Componente del processo)
|
Processo di produzione
|
Ciclo di vita/Configurazione
|
Mappa di instradamento
|
Modello impegni
|
(Processo)
|
|
|
|
|
|
Classificazione in categorie
|
|
|
|
|
|
Disciplina
|
Disciplina
|
Modulo
|
|
Disciplina
|
Dominio
|
(Serie di artefatti)
|
|
Dominio
|
Tipo di prodotto di lavoro
|
Set di ruoli
|
(Serie di ruoli)
|
|
|
|
Tool
|
Tool
|
|
|
|
|
|
|
|
|
Creazione pacchetti metodo
|
|
|
|
|
|
Metodo Plugin
|
Plugin modello di elaborazione
|
|
|
Processo
|
Pacchetto metodi
|
Componente processo
|
|
|
Pacchetto
|
Pacchetto metodo/ Pacchetto contenuto
|
|
|
|
Pacchetto
|
Pacchetto metodo/Pacchetto processo
|
|
|
|
Pacchetto
|
Pacchetto processo/Componente processo
|
|
|
|
Componente processo
|
|
|
|
|
|
Tipi di guida
|
|
|
|
|
|
Guida
|
Guida
|
documento di riferimento
|
Documento tecnico
|
Guida
|
Concetto
|
Concetto
|
documento di riferimento
|
|
|
Whitepaper
|
Whitepaper
|
documento di riferimento
|
|
|
Elenco di controllo
|
Elenco di controllo
|
|
Documento tecnico (V&V)
|
Elenco di controllo
|
Guida ai tool
|
Guida ai tool
|
|
Guida ai tool
|
Guida ai tool
|
Modello
|
Modelli
|
Modello
|
Modello
|
Modello
|
Report
|
Report
|
|
|
|
Stima
|
|
Stima
|
Valutazioni di stima
|
Stima
|
Esempio
|
Esempio
|
|
Elemento di riferimento/Esempio
|
|
Roadmap
|
Roadmap
|
Descrizione mappa di instradamento
|
|
|
Definizione termine
|
(Glossario)
|
(Glossario)
|
|
|
Procedura
|
|
|
|
|
|