De los procesos de desarrollo a la definición de procesos

workflow

Daniel Romero1, Marcelo Uva1

1
Universidad Nacional de Río Cuarto
Ruta 36 – Km 601 CP X5804BYA - Tel/Fax: 54+358+4676235
{dromero, uva}@dc.exa.unrc.edu.ar

Abstract. El modelado de los procesos de negocio es de vital importancia en el

desarrollo de toda industria, en particular, en la industria del software. La
ingeniería y re-ingeniería de los procesos de negocio apuntan principalmente a
elevar la calidad de los procesos de producción y consecuentemente, la de los
productos desarrollados. Una de las formas de optimizar la producción es
mediante la automatización de los procesos de negocio, lo que implica definir
reglas de transición, recursos involucrados, responsables para cada actividad,
etc. En el siguiente trabajo se propone una alternativa para el logro de la
automatización de los procesos de desarrollo de software. Esta automatización,
se obtiene luego de sucesivas transformaciones. Los procesos son modelados en
SPEM (Software Process Engineering Metamodel) y luego de una secuencia de
pasos, son transformados en procesos workflow.

Introducción

Un proceso de negocio es un conjunto de tareas lógicamente relacionadas, ejecutadas

para obtener un cierto resultado de negocio. El modelado, análisis y administración de
estos procesos, ha cobrado gran importancia ante la necesidad de una industria
competitiva, dinámica, que se adapte rápidamente a los cambios, y donde se
aprovechen al máximo los recursos disponibles. Toda esta situación ha provocado que
uno de los objetivos principales de la industria actual sea la automatización de los
procesos de producción.
Para el logro de este fin, se han venido utilizado tecnologías “Workflow”.
Se denomina workflow a la automatización parcial o total de un proceso de negocio.
La WfMC (Workflow Management Coalition), es un conjunto de instituciones que se
encarga de identificar áreas comunes de funcionalidad y de desarrollar
especificaciones apropiadas para la implementación en productos workflow. Se
pretende que esas especificaciones permitan la interoperabilidad entre productos
heterogéneos y mejoren la integración de aplicaciones workflow con otros servicios
IT tales como correo electrónico y administración de documentos.
Dentro de los estándares definidos por la WfMC, se encuentra la Interfaz 1 de
definición de procesos workflow. Ésta define un formato de intercambio común para
la transferencia de definiciones de procesos entre productos diferentes. Esto es
realizado a través de un esquema XML (Extensible Markup Language) denominado
Lenguaje de Definición de Procesos XML (XML Process Definition Language -
XPDL) [WFMC1025-2002].
La incorporación de tecnologías workflows permite automatizar los flujos de
información que circulan a través de una determinada industria, posibilitando el
secuenciamiento de las actividades y la optimización de los recursos.
El caso particular de la industria del desarrollo de software, no es diferente al del resto
de las industrias. Dentro de ella, se encuentran los procesos de negocios tendientes a
la construcción o generación de un producto (software) de calidad en un tiempo
determinado. Actualmente, ingenieros de software trabajan para optimizar los
procesos de desarrollo. Los procesos de negocios, dentro de la industria de desarrollo
de software son conocidos como “metodologías de desarrollo”, encargadas de guiar la
producción.
En este trabajo se propone la optimización del proceso de producción de software
mediante la automatización de las metodologías de desarrollo. Para lograr este
objetivo se realizaron los siguientes pasos:
Primero: Fue seleccionada una metodología de desarrollo de software para ser
utilizada como caso de estudio en este trabajo. La metodología en cuestión es una
instancia de la metodología RUP (Rational Unified Process) denominada SmallRUP,
definida por Gary Pillice en su artículo “Using the RUP for small projects”
[Pollice2003].

Segundo: Se utilizó el Metamodelo para la Ingeniería de Procesos de Software SPEM

(Software Process Engineering Metamodel) definido por la OMG (Object
Management Group) para el modelado de procesos de desarrollo.
Tercero: Una vez especificado el proceso de desarrollo SmallRUP en SPEM, el paso
siguiente fue la definición de un conjunto de reglas de transformación para convertir
la especificación SPEM en una especificación XPDL (XML Process Definition
Language). Esta última, ya es una definición estándar de un proceso Workflow, por lo
que podrá ser ejecutada, como cualquier proceso automatizado, por un sistema
workflow. Las reglas de transformación fueron definidas utilizando el lenguaje XSLT
(XSL Transformations).
Este trabajo está organizado de la siguiente manera. En la sección 1 es presentado el
caso de estudio SmallRUP. En la sección 2, se explican algunas características del
metamodelo SPEM, y se muestra cómo es realizada la especificación de SmallRUP.
La sección 3 muestra como es el proceso de transformación de una especificación
SPEM a una definición de proceso workflow. Finalmente en la sección 4, las
conclusiones.

1 Caso de estudio – SmallRUP

El caso de estudio utilizado es una instanciación particular del RUP (Rational Unified
Process - RUP) definida para pequeños proyectos [Pollice2003] denominada
SmallRUP. La elección del RUP se debió a que es una metodología que presenta
buenas prácticas en el desarrollo de software moderno para una amplia gama de
proyectos y organizaciones, está embebido en técnicas orientadas a objetos, utiliza
UML como notación principal, permite a organizaciones del software ajustar el
proceso a su necesidad específica y cubre diferentes dominios particulares
[Kruchten2002].

1.1 Ajustando el RUP para pequeños proyectos – SmallRUP

El Proceso Unificado Rational (Rational Unified Process - RUP) es una metodología

de desarrollo de software orientada a objetos. El RUP mantiene pautas, plantillas, y
ejemplos para todos los aspectos y fases de desarrollo del software. Además,
establece cuatro fases de desarrollo, cada una de las cuales está organizada en
iteraciones separadas que se van secuenciando a medida que se satisfacen
determinados criterios.
Al ser el RUP un framework de procesos de desarrollo de software existen diversas
formas en las que se lo puede instanciar, dependiendo de las características del
proyecto. Una de estas variantes es “SmallRUP”.

1.2 Las cuatro fases del SmallRUP

SmallRUP posee cuatro fases de desarrollo. Fase de “Inicio”, ”Elaboración”,

“Construcción” y “Transición”. Cada etapa determina un conjunto de actividades a
desarrollar por un grupo de personas con determinados roles dentro del proyecto, por
ej. Programador, Jefe de Programadores, etc. Como resultado, cada fase produce
artefactos que serán utilizados por las fases subsecuentes.
En las Tablas 1, 2 3 y 4 se muestran las actividades de cada etapa con sus respectivos
roles.

Tabla 1. Fase de Inicio, se identifican las características del proyecto, y su factibilidad.

Roles Actividades Artefacto

Administrador Visión
Formular el alcance del proyecto
del Proyecto Plan de aceptación
Modelo de Casos de Uso de
Negocio
Administrador Planificar y preparar los Casos de
Lista de Riesgos
del Proyecto Uso de Negocio (CUN)
Modelo inicial de Casos de
Uso de Sistema (CUS)
Jefe de Síntesis de la arquitectura Bosquejo de la Arquitectura
Programadores candidate candidata
Plan de proyecto preliminar
Administrador Preparar las condiciones del
Plan para empezar fase de
del Proyecto proyecto
elaboración

Tabla 2. Fase de Elaboración, se obtiene un delineamiento de la arquitectura del sistema.

Roles Actividades Artefacto

 Jefe de Documentación de la
Definir, validar y delinear la
Programadore arquitectura del software
arquitectura
s (SAD)
Administrador CUS y Lista de Riesgos
Refinar la visión
del Proyecto (Actualizados)
Crear y delinear el plan de
Administrador Plan de iteración para la fase
iteración para la fase de
del Proyecto de construcción
construcción
Programador Iniciar el desarrollo Código Fuente V1.0
Jefe de
Programadore Crear el entorno de testeo Código de Testeo V1.0
s

Tabla 3. Fase de Construcción, el objetivo principal de esta etapa es completar el desarrollo del
sistema.

Roles Actividades Artefacto

Administrador Administrar los recursos y los
Planificación
del Proyecto procesos de control
Desarrollar y testear los
Programador Componentes
componentes
Administrador Plan de Iteración para la fase
Evaluar la iteración
del Proyecto de Transición

Tabla 4. Fase de Transición, se asegura que el software este disponible para el usuario final.

Roles Actividades Artefacto

Finalizar los materiales de Plan de Despliegue
Programador
soporte para el usuario Manual del Usuario
Testear el producto entregado en
Cliente Lista de Issues
el entorno del cliente
Ajustar el producto sobre el
Programador Producto final
feedback del cliente
Administrador
Entregar el producto final
del Proyecto

2 Especificación de los procesos de desarrollo

Para especificar las actividades propuestas por un proceso de desarrollo utilizamos el

metamodelo definido por la OMG para la descripción de procesos de desarrollo
denominado SPEM. En el SPEM se especifica cómo manipular los modelos
utilizando XMI (XML Metadata Interchange). Se pretende con esto, obtener la
especificación de nuestro proceso de desarrollo en un formato que sea posible de
manipular.
2.1 Metamodelo para la Ingeniería de Procesos de Software - SPEM

El nacimiento del Proceso Unificado (Unified Process - UP) y del Lenguaje

Unificado de Modelado (Unified Modeling Language -UML) a finales de 1990
produjo un cambio fundamental en la industria del desarrollo de software. Existen
actualmente muchas variantes del UP que son utilizadas por todo el mundo. Esto
provocó la necesidad de un estándar unificado en esta área, debido a que al existir
diferentes técnicas de modelado de procesos, se utilizaban diferentes terminologías e
incluso diferentes significados para las mismas palabras.
En reconocimiento a esta necesidad, la OMG definió el Metamodelo para la
Ingeniería de Procesos de Software SPEM (Software Process Engineering
Metamodel).
SPEM es un metamodelo utilizado para describir procesos de desarrollo de software
concretos o una familia de procesos de desarrollo de software relacionados.
El metamodelo SPEM permite abstraerse de las características particulares de cada
proceso de desarrollo, dando la posibilidad de definir distintos procesos de desarrollo
de software.
SPEM ofrece un framework para el modelado de procesos de desarrollo de software y
sus componentes, dando una sintaxis y una estructura común para cada aspecto del
proceso de desarrollo, incluyendo: roles, tareas, artefactos, lista de chequeo. El SPEM
usa UML como notación [SPEMv1.0].

Estructura de Paquetes de SPEM

El metamodelo SPEM es construido extendiendo un subconjunto del metamodelo
UML 1.4 el cual, es encapsulado en un paquete denominado SPEM_Foundation
(figura 1).
El paquete SPEM_Foundation describe la estructura estática del modelo y hereda de
los siguientes paquetes de UML 1.4: Data_Types, Core, Actions, State_Machines,
Activities_Graphs, Model_Managements [UML1.4].

SPEM_Foundation

SPEM_Extensions

Fig. 1. Paquetes SPEM_Foundation y SPEM_Extensions

El paquete SPEM_Extensions incorpora los constructores y la semántica propia para

la ingeniería de procesos de desarrollo de software. El paquete SPEM_Extensions está
compuesto por los siguientes subpaquetes: BasicElements, Dependencies,
ProcessStructure, ProcessComponents y ProcessLifecycle.
BasicElements: Define los elementos básicos para la descripción de los procesos.
Dependencies: Define las dependencias entre los componentes. Se definen como
subclases de las clases del paquete SPEM_Foundation.
ProcessStructure: Define la estructura de los elementos.
ProcessComponents: Permite la división de una o más descripciones de procesos en
partes autocontenidas.
ProcessLifecycle: Incorpora los elementos de definición de procesos que ayudan a
definir la ejecución de los procesos.

2.2 Re-escribiendo SmallRUP con SPEM

El objetivo de esta sección es mostrar como se puede especificar un proceso de

desarrollo utilizando el SPEM. Esto implica dar una instanciación de las clases de este
metamodelo que se correspondan con el proceso de desarrollo que se quiere
especificar.
Con las clases del SPEM definiremos nuestro modelo de objetos del proceso de
desarrollo, y lo representaremos mediante la utilización de XMI, es decir,
obtendremos un documento XMI que contiene el modelo de objetos que representa al
SmallRUP en el SPEM.
Daremos primero un maping y un ejemplo entre las terminologías del SmallRUP y el
SPEM para detectar que clases del SPEM corresponde con cada componente del
SmallRUP, y luego como se definieron las dependencias entre actividades mediante la
utilización de un diagrama de actividades como un caso particular del un diagrama de
estados.

Tabla 5. Maping entre las terminologías del SmallRUP y el SPEM.

SmallRUP SPEM Ejemplo

Roles ProcessRoles Chief Programmer
Actividad Activity Síntesis de la arquitectura candidata
Artefacto WorkProduct Arquitectura preliminar
Disciplina Discipline Captura de requisitos
Fase Phase Fase de Inicio
Iteración Iteration Primera Iteración

En la figura 2 se muestra como se define en el SPEM para una actividad, quienes

participan, el artefacto que se produce y el tipo de este artefacto.
Por último, la figura 3 muestra la forma en la cual se construye el diagrama de objetos
que corresponde a la dependencia entre actividades. Para ello se define un diagrama
de actividad mediante un diagrama de estados, en donde se tienen estados de acción
(ActionState) asociados a una actividad (Activity) por medio de la operación de la
acción de entrada (CallAction) de ese estado.
De esta manera se pueden obtener todos los objetos que formarán nuestro modelo de
objetos del SmallRUP. El paso siguiente es serializar este modelo utilizando XMI
(XML Metadata Interchange).
 Summary of Candidate Architecture : Activity activity Chief Programmer : ProcessRole
assistant
subWork behaviorallFeacture responsibleRole

workProduct
parameters
type Draf Architecture : WorkProduct
: ActivityParameter

parentWork kind
Iteration 1, Inception Phase : Iteration UML Diagram : WorkProductKind

Fig. 2. Diagrama de Objeto: Actividades, roles y artefactos

outgoing : Transition incoming

source target
: ActionState : ActionState

entry entry
: CallAction : CallAction

operation operation
To refine the vision : To create, and to delineate the iteration
Activity plan for the construction phase : Activity

Figura 3. Dependencia de Actividades y Diagrama de Objeto

2.3 Serialización

El SPEM especifica cómo manipular los modelos utilizando XMI (XML Metadata
Interchange). Con esto se pretende obtener la especificación de nuestro proceso de
desarrollo en un formato que sea factible de manipular para luego transformarlo en la
entrada de un motor workflow.
El principal propósito de la norma XMI propuesta por el OMG, es facilitar el
intercambio de metadatos en entornos distribuidos heterogéneos, entre diferentes tipos
de herramientas software y, en especial, entre herramientas de modelado basadas en
UML y repositorios de metadatos basados en la propuesta MOF (Meta-Object
Facility). XMI permite que los metadatos puedan ser intercambiados como flujos o
archivos con un formato estándar basado en XML.
El proceso de producción de documentos XMI está definido como un conjunto de
reglas, donde estas reglas son aplicadas a un modelo y se obtiene como resultado un
documento XML. La inversa de estas reglas pueden ser aplicadas para reconstruir el
modelo original. En ambos casos, las reglas son empleadas en el contexto del
metamodelo para el metadato que está siendo intercambiado. La producción de XML
esta representada en la forma Backus-Naur extendida EBNF (Extended Backus Naur
Form) [XMIv2.0].

3 Automatización de los procesos de desarrollo

La producción del software se realiza a través de la ejecución de un proyecto de

desarrollo de software guiado por una metodología de desarrollo. Para su
automatización se deberá definir, dentro de un proceso workflow, las actividades
propuestas por la metodología.
Para poder intercambiar la definición de las actividades al motor workflow es preciso
re-escribirlas en el lenguaje XPDL, y como la especificación de procesos de
desarrollo de software está definida en XMI, bastará con definir las reglas de
transformación necesarias para convertir un documento XMI en uno XPDL.

3.1 Workflow

Un workflow se define como la automatización total o parcial de un proceso de

negocio, durante la cual documentos, información o tareas son intercambiadas entre
los participantes conforme a un conjunto de reglas procedimentales preestablecidas
[Allen2001].
Un workflow comprende un número de pasos lógicos, conocidos como actividades.
Una actividad puede involucrar la interacción manual o automática con el usuario.
Un motor workflow es un sistema de software que controla la ejecución de las
actividades definidas en el workflow. La WfMC ha definido un Modelo de Referencia
Workflow (Workflow Reference Model) [WFMC1003-1995]. Este modelo define 5
interfases para la interoperabilidad de diferentes productos con un motor workflow.
La interfaz 1 especifica el formato de intercambio común para soportar la
transferencia de definiciones de procesos entre productos diferentes, utilizando un
Lenguaje de definición de Procesos (XML Process Definition Language - XPDL)
[WFMC1025-2002].
El Lenguaje XPDL permite escribir especificaciones de procesos workflow de manera
estandarizada. Esto significa que cualquier definición de proceso que cumpla con
todos los requisitos establecidos en la interfaz 1 podrá ser tomada como entrada por
cualquier motor workflow que respete el estándar establecido por la WfMC.
El metamodelo workflow está compuesto por entidades y relaciones. Las entidades
principales del metamodelo Workflow son las siguientes:
Workflow Process Activity: Representa una actividad dentro de un proceso.
Transition Information: Describe las transiciones entre actividades y las condiciones
que la habilitan o inhabilitan, durante la ejecución del workflow.
Workflow Participant Specification: Representa los participantes intervinientes en una
actividad. Puede ser un “rol”, un “humano”, u “otro sistema”.
Workflow Application Declaration: Es representada como una lista de las aplicaciones
o herramientas requeridas por el proceso workflow.
Workflow Relevant Data: Representa a la información que circula dentro de un
proceso workflow.

3.2 Workflow aplicado al Proceso de desarrollo

Workflow es una tecnología de información que puede contribuir al logro de los

objetivos del proceso de desarrollo y al mejoramiento de sus resultados mediante la
administración efectiva de las actividades que componen sus diferentes procesos por
parte de los propios participantes. Un proceso de software consiste en un conjunto de
actividades concurrentes y cooperativas, que tienen que ver con el desarrollo y
mantenimiento de software, así como con la gestión del proyecto y la calidad del
producto. Por lo tanto, un proceso de software puede verse como un caso particular de
proceso, y puede aplicarse la tecnología de workflow para dar soporte al proceso de
desarrollo de software [Acuña2000].

3.3 Definición de reglas de transformación

En la sección 2 se mostró como un proceso de desarrollo puede ser instanciado en

SPEM, y como se puede representar en un documento XMI, el paso siguiente es
transformar este documento en un documento XPDL. Para realizar esta
transformación se utilizó XSLT (Transformaciones XSL - XSL Transformations)
[XSLTv1.0], un lenguaje para transformar documentos XML en otros documentos
XML, mediante definiciones de reglas de transformación.
Para la construcción de las reglas de transformación se establecieron asociaciones
entre las clases del metamodelo SPEM y las entidades de la especificación XPDL.
Las reglas de transformación definidas son independientes del proceso o instancia
utilizada, dando así una forma general de transformación entre objetos del SPEM y
entidades del XPDL.
Las reglas de transformación generadas, fueron aplicadas al caso de estudio
SmallRUP.
A continuación se mostrarán algunas de las correspondencias entre entidades del
metamodelo Workflow (XPDL) y clases de SPEM.
XPDL.TypeDeclaration: Los tipos de datos utilizados son los tipos que pueden tener
los artefactos producidos, SPEM:WorkProductKind. Ejemplo: “UML Diagram”.
XPDL.Application: A cada tipo de artefacto producido (SPEM:WorkProductKind), se
asoció un tipo de aplicación. Ejemplo: a un “UML Diagram” se asoció un “UML
CASE Tool”.
XPDL.Activity: SPEM:Activity definen las actividades de tipo implementación del
XPDL, las actividades de tipo JOIN o FORK son definidas mediante
SPEM.PseudoState.
XPDL.DataField: Son los artefactos producidos, SPEM:WorkProduct. Ejemplo: el
artefacto “Model of business use case”.
XPDL.WorkFlowProcess: SPEM:Process, El “SmallRUP” define el
WorkFlowProcess del XPDL.
XPDL.Transition: SPEM:Transition, cada transición definida en nuestro diagrama de
actividad se corresponde con las transiciones de las actividades en el XPDL.
XPDL.Participant: Los distintos roles que participan en el RUP, SPEM:Role.
Ejemplo: “Project Manager”.

Código de ejemplo correspondiente a la regla de transformación XSLT de la clase

SPEM:ProcessRole.
<xsl:template name="xpdl_participants">
<xsl:text disable-output-escaping="yes">
&lt;Participants&gt;</xsl:text>
<xsl:for-each select="//SPEM.ProcessRole">
<xsl:text disable-output-escaping="yes">
&lt;Participant Id="</xsl:text>
<xsl:value-of select="@xmi.id"/>
<xsl:text disable-output-escaping="yes">
" Name="</xsl:text>
<xsl:value-of select="@name"/>
<xsl:text disable-output-escaping="yes">"&gt;
&lt;ParticipantType Type="ROLE" /&gt;
&lt;Description&gt;
</xsl:text>
<xsl:value-of select="@name"/>
<xsl:text disable-output-escaping="yes">
&lt;/Description&gt;
&lt;/Participant&gt;
</xsl:text>

</xsl:for-each>
<xsl:text disable-output-escaping="yes">
&lt;/Participants&gt;</xsl:text>
</xsl:template>

De esta manera se construyeron las reglas de transformación que se aplican a un

modelo de objetos correspondiente a un proceso de desarrollo especificado en el
SPEM en formato XMI.
3.4 Generando el documento XPDL

Una vez definidas las reglas de transformación, el paso siguiente es aplicar a la

especificación del proceso de desarrollo en SPEM–XMI de éstas, reglas para generar
la definición de procesos workflow en XPDL.
En la figura 4 se muestra la secuencia completa de los pasos de transformación.

Figura 4. Secuencia de transformaciones

4 Conclusión

Ante la competencia, eficiencia y velocidad que requiere actualmente el mercado

globalizado, la automatización de los procesos de negocio dentro de la industria ocupa
un lugar fundamental. El correcto desarrollo de las actividades, buen uso de los
recursos, exigencias en cuanto a la producción y al control son puntos vitales para
toda industria. El desarrollo del software no es ajeno a estos conceptos, y es por ello
que existen varias líneas de investigación estudiando como colaborar en su
automatización.
A la necesidad de automatización también se debe sumar la necesidad de la
utilización de estándares para lograr un mejor entendimiento e integración con las
demás tecnologías. Dos grandes estándares se utilizaron en este trabajo; el
metamodelo para la descripción de procesos de software definido por la OMG
denominado SPEM, y la especificación workflow definida por la WfMC.
En este trabajo lo que se presentó una alternativa que permite la automatización de un
proceso de desarrollo de software (SmallRUP). Las ventajas que conllevan la
automatización de un proceso de desarrollo de software son las siguientes:
Con respecto a la construcción del software: Se considera que el proceso de
transformación optimiza la construcción del software debido a que se dispone de un
sistema automatizado (motor workflow) que administrará los recursos y organizará a
un equipo de ingenieros de software en el transcurso del desarrollo de un proyecto en
particular. El proceso de desarrollo adopta todas las ventajas propias de un proceso
workflow, como son la ejecución y simulación del proceso, el rediseño buscando un
modelo más óptimo, entre otras.
Con respecto a la independencia de las reglas de transformación: La utilización de un
caso de estudio para este trabajo nos permitió aplicar las reglas de transformación en
un caso concreto, lo que no limita la extrapolación de éstas reglas a otras
metodologías de desarrollo, debido a que las reglas no hacen referencia a las
particularidades de un proceso, sino que trabajan con las clases del metamodelo
SPEM. La definición de las reglas de transformación de documentos XMI a XPDL
fue construida de manera independiente al proceso de desarrollo sobre el cual puede
aplicarse.
Con respecto a la interacción de diferentes herramientas: La utilización de estándares
SPEM, XMI, XSLT, XPDL adoptados por organizaciones como OMG, WfMC, W3C
y a escala mundial, por la comunidad informática, ofrece una mejor comprensión del
trabajo y flexibilidad para futuras extensiones.

Referencias

[Acuña2000] Silvia Teresita Acuña, “La tecnología de workflow como soporte para la
formalización de proceso software integral”, Anales de las Jornadas Universitarias sobre
Computación de Santiago del Estero (JUCSE 2000); 5-6 de Octubre de 2000. Santiago del
Estero, Argentina.
[Allen2001] Rob Allen, Open Image Systems Inc., United Kingdom Chair, WfMC External
Relations Committee; “The Workflow Handbook 2001”; Workflow Management Coalition;
Octubre de 2001.
[Kruchten2002] Philippe Kruchten; “Introduction to the Rational Unified Process”; 24th
International Conference on Software Engineering; IEEE; 19 al 25 de Mayo de 2002;
Orlando, Florida.
[Pollice2003] Gary Pollice – “Using the RUP for small projects: Expanding upon Extreme
Programming”, A Rational Software White Paper – 17 de junio 2003.
[SPEMv1.0] Object Management Group; “Software Process Engineering Metamodel
Specification”; An Adopted Specification of the Object Management Group, Inc; Version
1.0 formal/02-11-14; Noviembre de 2002.
[UMLv1.4] Object Management Group; “OMG Unified Modeling Language Specification”;
An Adopted Specification of the Object Management Group, Inc; Version 1.5 formal/03-03-
01; Marzo de 2003.
[WFMC1003-1995] Workflow Management Coalition; “The Workflow Reference Modelo”.
The Workflow Management Coalition Specification; WFMC-TC-1003 Version 1.1 Issue;
Enero de 1995.
[WFMC1025-2002] Workflow Management Coalition; “Workflow Process Definition
Interface, XML Process Definition Language”. The Workflow Management Coalition
Specification; WFMC-TC-1025 Version 1.0 Final Draft; Octubre de 2002.
[XMIv2.0] Object Management Group; “XML Metadata Interchange (XMI) Specification”; An
Adopted Specification of the Object Management Group, Inc; Versión 2.0; Mayo 2003.
[XSLTv1.0] Word Wide Web Consortiun; “XSL Transformations (XSLT)”; Version 1.0; 19 de
noviembre de 1999. http: //www.w3.org/TR/xslt.