Concetto: UMA in confronto a RUP 2003 meta-model
Questo concetto descrive la differenza chiave tra Unified Method Architecture e Rational Unified Process / Rational Process Workbench 2003 meta-model.
Descrizione principale

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.

Figura dimostrativa dell'evoluzione di Unified Method Architecture

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