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.
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
|
|
|
|
|
|