Plano de fundo

A UMA (Unified Method Architecture) foi desenvolvida com o objetivo de unificar o esquema e a termonologia de representação de todas as abordagens de engenharia do processo dentro da IBM, bem como suportar os padrões mais importantes na indústria.  Por isso, conforme mostrado na figura a seguir, a UMA foi desenvolvida em um esforço colaborativo entre os arquitetos do IBM RUP (Rational Unified Process), IBM GS Method (Global Services Method) e IBM Rational Summit Ascendant.  Além desse grupo principal de arquitetos, investidores de muitas outras iniciativas do processo de desenvolvimento dentro e fora da IBM, revisaram e contribuíram para a especificação.   A própria especificação foi enviada para o OMG como uma proposta para o SPEM 2.0 padrão.  Por que, o metamodelo do RUP 2003 foi desenvolvido baseado no SPEM 1.1 padrão atual, essa proposta de rascunho do SPEM 2.0 pode ser vista como significativa mas contínua evolução desse padrão.

A Meta principal dessa unificação surgiu com um conjunto de termos e estruturas de dados que permite que todos esses métodos e processos sejam expressos sem perder as características principais.   Por exemplo, a UMA precisa ser projetada para suportar vários modelos de ciclo de vida diferentes: o ciclo de vida de desenvolvimento repetitivo do RUP, os ciclos de vida do GS Method incrementais e os ciclos de vida em cascata e repetitivos do Summit Ascendant.   Além disso, as diferenças de terminologia necessárias a serem resolvidas: Qual RUP chamaria uma Atividade que foi chamada Tarefa em um GS Method, o RUP falaria de Artefatos onde o Summit Ascendant definiria Distribuíveis e assim por diante.

Alterações na UMA para Usuários do RUP 2003

Como resultado da definição de apenas uma estrutura de dados e, com mais importância, de uma terminologia para todas essas abordagens, acordos e alterações precisam ser aceitos por todos os investidores. Embora essas alterações possam estar incomodando o usuário RUP atual, na execução longa elas se beneficiarão de uma terminologia unificada amplamente utilizada e de uma forma padronizada de expressar o conteúdo do método e processos que aprimoram a comunicação sobre os processos e facilitam a reutilização.  A lista a seguir resume as alterações mais importantes para o metamodelo do RUP 2003.  A tabela no final dessa página fornece uma comparação de terminologia completa de todas as origens principais da UMA.

• Atividades que foram renomeadas para a tarefa: Para fornecer um link mais rígido para execução do processo e gerenciamento do projeto, foram renomeadas as unidades de trabalho mais inferiores designáveis para a Tarefa, porque esse é o termo geralmente mais utilizado.
• Detalhes do fluxo de trabalho renomeados para atividade: Os fluxos de trabalho geralmente são expressos em hierarquias de diagramas de atividades (por ex., diagramas de atividades definidos no UML 2.0).  Embora o RUP forneceu apenas um nível de interrupção de fluxo de trabalho, a UMA é projetada para fornecer múltiplos níveis de tal interrupção. Como a palavra Atividade foi geralmente mais utilizada para expressar os elementos de diagramas de atividades, e também o próprio diagrama de atividade, foi decidido substituir o nome Detalhe do Fluxo de Trabalho utilizado no RUP pelo nome Atividade.   Entende-se que o deslocamento no uso da palavra Atividade pode causar confusão com usuários do RUP existentes.   No entanto, uma meta importante o trabalho da UMA era utilizar os termos de forma que eles fossem geralmente mais utilizados em padrões e indústria. 
• Tarefas (Atividades do RUP antigo) podem ser desempenhadas por muitas funções:  No RUP 2003, uma atividade foi modelada como uma operação de uma função.   Feedback do cliente, uma olhada em outras abordagens de modelagem do processo, bem como alterações apresentadas no UML 2.0 indicaram que essa era uma forma muito restrita de comportamento humano de modelagem.   Essa abordagem não permitia expressar que algum trabalho fosse desempenhado como uma colaboração de funções diferentes.   A UMA emite esse problema ao tornar a Tarefa um elemento de modelo independente, para o qual o desempenho de funções pode ser designado como recursos.  Conseqüentemente, a UMA permite agora que várias funções sejam designadas para uma tarefa.  Para retrocompatibilidade, ela ainda permite que uma função de desempenho principal seja identificada (sendo responsável para a tarefa), bem como vários executores adicionais.
• Refinamento do conceito de artefato: O RUP utilizou apenas o conceito de artefato, para definir itens que são utilizados e produzidos em um projeto de desenvolvimento.   A UMA define uma taxonomia estendida para estes conceitos.  Define o conceito geral do produto de trabalho, o qual possui três especializações diferentes (tipos de produtos de trabalho específicos): Artefatos (produtos de trabalho gerenciados), Distribuíveis (produtos de trabalho empacotados que serão entregues para um investigador para revisão) e Resultado (produtos de trabalho não gerenciados e intangíveis).
• Categorizações diferentes para produtos de trabalho e funções: No RUP, os artefatos e as funções foram todos categorizados por disciplina.  Porém, às vezes, os artefatos foram utilizados através de disciplinas e uma categorização apenas para uma disciplina que causou confusão.  Na UMA, categorias diferentes foram estabelecidas para definições de trabalho (disciplina para tarefas e atividades), produtos de trabalho (tipo de domínio e produto de trabalho) e funções (conjuntos de funções). 
• Componentes do Processo renomeados para o Pacote de Métodos: Geralmente, o conceito de componente é utilizado em muitos padrões e tecnologias. A maioria dos aplicativos de componentes vinculam isso à abstração de encapsulamento, definindo um componente como uma caixa preta que pode ser utilizada através de interfaces bem definidas. Os componentes do RUP não preenchem esse critério de caixa preta. Além disso, o SPEM padrão definiu pacotes e também componentes. Para estar em conformidade com o SPEM e com o uso e segmento de mercado do componente de palavra, o Componente do Processo foi renomeado para Pacote do Método. (Tecnicamente, ele é um 'método' porque pode conter elementos de métodos ou de processos).
• Separação de elementos de conteúdo do método dos elementos do processo: No RUP 2003 foi criado um novo processo, definindo uma nova configuração e documentando manualmente em alterações de um artefato de caso de desenvolvimento para o RUP padrão.  A UMA fornece conceitos estendidos, além do conceito de configuração para adaptar os processos.  Permite modelar concretamente para um processo que trabalha definido no conteúdo do método que você realmente deseja realizar em cada fase, porque você facilmente, inclui, remove e reordena elementos na estrutura de processos, reutilizando ou não o que quer que se deseja a partir do conteúdo do método. Realiza esses recursos através de uma separação mais nítida de conteúdo do método (por ex., tarefas definidas para disciplinas) e do aplicativo de conteúdo do método em processo (expresso com os diagramas de atividades e/ou estruturas de interrupção de trabalho), bem como a modelagem de processos (isto é, a criação de diagramas de atividades novos e adaptados ou de estruturas de interrupção novas ou adaptadas).  Apresenta alguns novos conceitos, como por exemplo o descritor que suporta essa separação e atinge novas capacidades para manutenção e reutilização de várias famílias diferentes de processos alternativos e processa partes de tudo dentro a mesma configuração.

Comparação de Terminologia