Concepto: UMA contra el metamodelo RUP 2003
Este concepto describe las diferencias clave entre la arquitectura unificada de método y el metamodelo Rational Unified Process / Área de trabajo de proceso de Rational 2003.
Descripción principal

Un poco de historia

La arquitectura unificada de método (UMA) se ha desarrollado con la idea de unificar el esquema de representación y la terminología de todos los enfoques de ingeniería de procesos y métodos de IBM, así como dar soporte a los principales estándares del sector.   Por ello, como se muestra en la figura siguiente, UMA se ha desarrollado como un proyecto de colaboración entre los arquitectos de IBM Rational Unified Process (RUP), método IBM Global Services (método GS) e IBM Rational Summit Ascendant.  Además de este grupo central de arquitectos, los interesados de muchas otras iniciativas de proceso de desarrollo dentro y fuera de IBM revisaron y contribuyeron a la especificación.  La misma especificación se ha enviado a OMG como propuesta para el estándar SPEM 2.0. Como el metamodelo RUP 2003 se ha desarrollado basándose en el estándar SPEM 1.1 actual, esta propuesta de borrador de SPEM 2.0 puede entenderse como una evolución significativa pero continua de ese estándar.

Imagen que muestra la evolución de la arquitectura unificada de método

El objetivo principal de esta unificación era dar con un conjunto de términos y estructuras de datos que permitiera expresarse a todos esos métodos y procesos sin perder sus características esenciales.  Por ejemplo, UMA debía diseñarse para dar soporte a muchos ciclos vitales distintos: el ciclo vital de desarrollo iterativo de RUP, los ciclos vitales incrementales del método GS y los ciclos vitales iterativos y de cascada de Summit Ascendant.  Además, las diferencias de terminología debían resolverse: lo que RUP denominaba actividad se denominaba tarea en el método GS, RUP hablaba de artefactos donde Summit Ascendant definía entregables, etc.

Cambios en UMA para los usuarios de RUP 2003

Como resultado de definir una única estructura de datos y, lo que es más importante, todos los interesados debían aceptar una misma terminología para todos estos enfoques, compromisos y cambios. Aunque estos cambios pueden resultar incómodos para el usuario actual de RUP, a la larga, se beneficiarán de una terminología unificada y muy utilizada y de una forma estandarizada de expresar el contenido del método y los procesos con lo que mejorará la comunicación acerca de los procesos y se facilitará la reutilización.  En la lista siguiente se ofrece un resumen de los cambios principales del metamodelo RUP 2003.  En la tabla siguiente se proporciona un completa comparativa terminológica de todas las fuentes principales de UMA.

  • Actividad se denomina ahora tarea: para proporcionar un enlace más ajustado con la actuación de proceso y la gestión de proyectos, se ha renombrado las unidades de trabajo asignables más pequeñas como tarea, por ser el término usado más habitualmente.
  • Detalles de flujo de trabajo se denomina ahora actividad: los flujos de trabajo se suelen expresar en jerarquías de diagramas de actividad (por ejemplo, diagramas de actividad definidas en UML 2.0).  Aunque RUP sólo ha proporcionado un nivel de desglose del flujo de trabajo, UMA se ha diseñado para proporcionar varios niveles de desglose similares. Como el término actividad era más utilizado para expresar los elementos de los diagramas de actividad así como el propio diagrama de actividad, se decidió sustituir el término detalle de flujo de trabajo utilizado en RUP por el de actividad.  Nos dimos cuenta de que el cambio en el uso de la palabra actividad podría causar confusión entre los usuarios de RUP existentes.  Sin embargo, un objetivo importante del trabajo de UMA era utilizar los términos de la forma en que se utilizaban habitualmente en los estándares y en el sector.  
  • Muchos roles pueden realizar las tareas (anteriormente denominadas actividades RUP): en RUP 2003, una actividad se ha modelado como operación de un rol.  La información de retorno de los clientes, una mirada a otros enfoques de modelado de procesos, así como los cambios introducidos en UML 2.0 indicaron que era una forma excesivamente restrictiva de modelar el comportamiento humano.  Este enfoque no permitía expresar que una parte del trabajo se realizó en colaboración entre distintos roles.  UMA aborda esta cuestión haciendo de la tarea un elemento de modelo independiente al que pueden asignarse roles de realización como recursos.  Por lo tanto, ahora UMA admite que a una tarea se le asignen varios roles.  Para la compatibilidad con versiones anteriores, sigue admitiendo que se identifique un rol de realización principal (responsable de la tarea), así como varios realizadores adicionales.
  • Perfeccionamiento del concepto de artefacto: RUP sólo utiliza el concepto de artefacto para definir lo que se utiliza y se produce en un proyecto de desarrollo.   UMA define una taxonomía ampliada para estos conceptos.   Define el concepto general de producto de trabajo, que tiene tres especializaciones diferentes (tipos de producto de trabajo específicos): artefactos (productos de trabajo gestionados), entregables (productos de trabajo empaquetado que se entregan al interesado para su revisión) y resultado (productos de trabajo intangibles, no gestionados).
  • Distintas categorizaciones de productos de trabajo y reglas: en RUP, los artefactos y las reglas se categorizan por disciplina.   Sin embargo, a veces los artefactos se utilizan en varias disciplinas y una categorización para sólo una disciplina provocó confusión.   En UMA se han definido diferentes categoría para las definiciones de trabajo (disciplina para tareas y actividades), productos de trabajo (dominio y tipo de producto de trabajo) y roles (conjuntos de roles). 
  • Componentes del proceso se denomina ahora paquete del método: el concepto de componentes suele utilizarse en muchos estándares y tecnologías. La mayoría de las aplicaciones del componente los enlazan con la abstracción de la encapsulación que define un componente como una caja negra que puede utilizarse mediante interfaces bien definidas. Los componentes de RUP no cumplían este criterio de caja negra. Asimismo, en el estándar SPEM se definían paquetes además de componentes. Para ser compatible con SPEM y con el uso del término componente en el sector, se ha cambiado su nombre de componente del proceso por el de paquete del método. (Técnicamente, se trata de un 'método' porque contiene elementos de método o elementos de proceso).
  • Separación de los elementos de contenido del método de los elementos de proceso: en RUP 2003, se creó un nuevo proceso al definir una nueva configuración y documentar manualmente en un guión de desarrollo los cambios de los artefactos en RUP estándar. UMA proporciona conceptos que se suman al concepto de configuración para los procesos de personalización.  Le permite modelar específicamente para un proceso qué trabajo definido en el contenido del método desea realizar en cada fase, porque puede añadir, eliminar y reorganizar con facilidad los elementos de la estructura del proceso, pudiendo decidir qué elementos reutiliza del contenido del método. Ofrece estas características mediante una separación más clara del contenido del método (por ejemplo, la tareas definidas para las disciplinas) y la aplicación del contenido del método en los procesos (expresados mediante diagramas de actividad o estructuras de desglose de trabajo), así como el modelado de procesos (por ejemplo, creando diagramas de actividad nuevos o adaptados, o estructuras de desglose de trabajo nuevas o adaptadas).  Presenta algunos conceptos nuevos como el descriptor que da soporte a esta separación y alcanza nuevas posibilidades de mantener y reutilizar muchas familias diferentes de procesos y partes de procesos alternativos en la misma configuración.

Comparación de términos

En la tabla siguiente se muestra cómo se correlaciona la terminología UMA con los términos utilizados por otros enfoques de ingeniería de procesos.

  UMA/RMC RUP 2003 SUMMIT IGSM SPEM 1.1
Elementos de método básicos        
  Rol Rol Rol Rol Rol de proceso
Producto de trabajo   Entregable    
Producto de trabajo/Artefacto Artefacto   Descripción del producto de trabajo Producto de trabajo
Producto de trabajo/Resultado     Resultado de la tarea  
Producto de trabajo/Entregable     Descripción del contenido del entregable  
Tarea Actividad Actividad Tarea Actividad
Paso Paso Paso Subtarea Paso
         
Relacionado con el proceso        
  Actividad Detalle del flujo de trabajo Tarea Actividad Definición del trabajo
Iteración Iteración     Iteración
Fase Fase Fase Fase Fase
Patrón de posibilidad     Patrón de posibilidad (Componente del proceso)
Proceso de entrega Ciclo vital/Configuración Mapa Modelo de compromiso (Proceso)
         
Categorización        
  Disciplina Disciplina Módulo   Disciplina
Dominio (Conjunto del artefacto)   Dominio Tipo de producto de trabajo
Conjunto de roles (Conjunto de roles)      
Herramienta Herramienta      
         
Método de empaquetado        
  Plug-in de método Plug-in del modelo de proceso     Proceso
Paquete del método Componente de proceso     Paquete
Paquete del método/Paquete del contenido        Paquete
Paquete del método/Paquete del proceso       Paquete
Paquete del proceso/Componente de proceso       Componente de proceso
         
Tipos de guía        
  Directriz Directriz Documento de referencia Documento técnico Directriz
Concepto Concepto Documento de referencia    
Documento técnico Documento técnico Documento de referencia    
Lista de comprobación Lista de comprobación   Documento técnico (V&V) Lista de comprobación
Guía de la herramienta Guía de la herramienta   Guía de la herramienta Guía de la herramienta
Plantilla Plantillas Plantilla Plantilla Plantilla
Informe Informe      
Cálculo   Cálculo Consideraciones sobre el cálculo Cálculo
Ejemplo Ejemplo   Elemento de referencia/Ejemplo  
Mapa  Mapa Descripción del mapa    
Definición de términos (Glosario) (Glosario)    
Práctica