ADAPTE Method: Tool Catalog, Measures Definition, and Process Configuration

Transcripción

1 ADAPTE Method: Tool Catalog, Measures Definition, and Process Configuration Giovanni Giachetti 1, Pablo Cruz 1, Daniel Fredes 2, Hernán Astudillo 1 1 Universidad Técnica Federico Santa María, Av. España 1680, Valparaíso, Chile giovanni.giachetti@mail.usm.cl, pablo.cruz@gmail.com, hernan@inf.utfsm.cl 2 Pontificia Universidad Católica de Valparaíso cradle.deicide@gmail.com Abstract. En un proyecto de software es fundamental contar con herramientas adecuadas y configuradas correctamente para dar soporte a cada etapa del proceso de desarrollo. Facilitar y guiar la configuración de un entorno de desarrollo adecuado es uno de los objetivos clave del proyecto ADAPTE. Para este fin, la plataforma ADAPTE considera la construcción de un catalogo para administrar las herramientas que darán soporte a procesos de desarrollo concretos. Este catalogo además de incorporar características relevantes de las herramientas a utilizar, permite la definición de handlers específicos orientados a automatizar y guiar las tareas de configuración de las herramientas involucradas. El hilo conductor del método ADAPTE está dado por un proceso de desarrollo definido mediante un modelo SPEM (basado en el metamodelo UMA) adaptado al contexto de un proyecto específico. Por este motivo, para la elaboración de la suite de herramientas que conforman la plataforma ADAPTE se utilizará un paradigma basado en modelos (y metamodelos) que facilite la integración con los modelos de procesos. En este documento se muestra el método utilizado para la definición de los artefactos involucrados y el proceso necesario para instanciar dichos artefactos. Keywords: development, process, context-aware, tool, SPEM, UMA. 1 Introducción El proyecto ADAPTE busca definir una solución para obtener procesos de desarrollo instrumentados y adaptados al contexto de proyectos específicos de una PyME, a partir de modelos que describen su proceso organizacional. Este contexto está determinado por un modelo (de contexto) definido de acuerdo a las necesidades de cada proyecto de desarrollo utilizando la propuesta de Hurtado et al. [1]. Mediante un mecanismo de refinamiento o tailoring, el proceso organizacional se transforma en un proceso adaptado-al-contexto de un proyecto concreto. Este proceso es definido en un modelo que utiliza los conceptos del estándar SPEM (Software Process Engineering Metamodel) [2].

2 Para operacionalizar la definición de los modelos de procesos involucrados, se ha utilizado la herramienta EPF composer [3] que implementa el metamodelo Unified Method Architecture (UMA) [4]. A partir de este modelo dependiente-del-contexto de un proyecto de desarrollo concreto, se ha establecido la plataforma tecnológica ADAPTE (ver Figure 1) que dará apoyo a dos objetivos principales: 1) Configurar el ambiente de desarrollo mediante mecanismos automáticos o semiautomáticos, denominados handlers. 2) Medir la ejecución del proceso de desarrollo con medidas establecidas de acuerdo a las herramientas y tecnologías asociadas al proyecto. A lo largo de la historia del software, se ha demostrado que la definición y formalización de los procesos de desarrollo no tienen mayor impacto si no son materializados y aplicados correctamente dentro del contexto organizacional [5]. Por este motivo, los objetivos de ADAPTE buscan apoyar y facilitar la materialización de los procesos de desarrollo mediante mecanismos automáticos de instrumentación y medición adaptados al contexto de proyectos específicos. Figure 1. Plataforma ADAPTE Esquema General Para alcanzar estos objetivos, se ha utilizado una propuesta metodológica basada en la definición de metamodelos que formalicen la estructura y sintaxis abstracta de los principales conceptos involucrados. Es decir, herramientas, medidas, elementos del proceso, y mecanismos de configuración. En este documento se detalla cada uno 2

3 de estos elementos y como se ha materializado los metamodelos correspondientes. Además, se muestra el proceso que permite coordinar los distintos artefactos para configurar procesos de desarrollo concretos. El resto del documento está conformado por las siguientes secciones: la Sección 2 detalla los catálogos de herramientas que existen en la plataforma ADAPTE; la Sección 3 muestra cómo configurar un proceso de desarrollo específico; y la Sección 4 resume el trabajo realizado y los pasos a seguir en la ejecución del proyecto ADAPTE. 2. Catálogos de Herramientas ADAPTE Una pieza clave para alcanzar el primero de los objetivos propuestos para la plataforma adapte es la definición de catálogos de herramientas que cuenten con toda información necesaria para configurar procesos de desarrollo concretos. Existen dos tipos de catálogos en la plataforma ADAPTE: 1) Catálogo de Herramientas: En este catálogo se encuentra todo el detalle de las herramientas soportadas por la plataforma ADAPTE, incluyendo información de handlers para la posterior configuración del entorno de desarrollo. 2) Catálogo de Instalación de Herramientas: En este catálogo se indica las herramientas disponibles (o a ser instaladas) dentro de una organización particular y depende directamente de la información contenida en un catálogo de herramientas existente. De esta manera, el catálogo de instalación de herramientas sólo incorpora detalles de inicio de sesión, plataformas, y servidores donde se encuentra instaladas las herramientas referenciadas. La estructura de estos dos catálogos es descrita mediante metamodelos: un metamodelo para los catálogos de herramientas (catálogos globales) y otro para los catálogos instalación de herramientas (catálogos organizacionales). Ambos metamodelos han sido desarrollados considerando distintas características que pueden presentar las herramientas, el objetivo de la instalación en caso de que la herramienta no se encuentre instalada en el entorno de trabajo, y la configuración requerida por la herramienta. La división de los metamodelos en metamodelo de herramientas y de instalación permite manejar de manera centralizada toda la información genérica de herramientas (versiones, dependencias, mecanismos de instalación, etc.) que es independiente de una organización específica. Esta información puede ser mantenida por una o varias entidades centrales, tales como proveedores de herramientas. Mediante esta información centralizada, las organizaciones de acuerdo a las herramientas que poseen o desean adquirir, pueden hacer uso de toda la información común (Global) para configurar sus procesos de desarrollo, reduciendo el esfuerzo de mantener esta información y reutilizando la experiencia y tecnología adquirida en la aplicación de la plataforma ADAPTE en diversos proyectos de software. Es decir, el catálogo de instalación de herramientas utiliza los datos necesarios desde el catálogo 3

4 de herramientas (global) para indicar claramente las características que poseen las herramientas instaladas, y para identificar mecanismos que permitan la configuración de entornos de desarrollo ad-hoc. Esta visión también facilita la incorporación de nuevas herramientas al catálogo de herramientas que puedan ser rápidamente utilizadas por los catálogos de herramientas instaladas de las PyMES. Sin embargo, dependiendo del tipo de organización es posible utilizar uno o más catálogos de herramientas. Por ejemplo, una organización podría utilizar el catálogo de herramientas ADAPTE para recuperar la información de herramientas de dominio público, pero además, podría contar con otro catálogo de herramientas propietario para almacenar información de herramientas con carácter confidencial o específico a un dominio de aplicación. Figure 2 ejemplifica esta situación. ADAPTE Catalog Manager Organization X depends ADAPTE Tool Catalog Organization Y Catalog Manager depends Installation Tool Catalog Organization Y depends Proprietary Tool Catalog Installation Tool Catalog Figure 2. Relaciones entre catálogos de herramientas y de instalación A continuación se detalla la estructura definida para los metamodelos que describen los catálogos de herramientas y catálogos de instalación de herramientas de la plataforma ADAPTE Metamodelo Tool Catalog La Figure 3 muestra el metamodelo definido para el catálogo de herramientas. A continuación se describe los constructores más relevantes especificados en este metamodelo Metaclase Tool La metaclase Tool representa las herramientas que estarán disponibles en el catalogo de herramientas. El tipo de herramienta se especifica mediante el atributo kind que 4

5 toma valor a partir de la enumeración ToolKind. Existen dos componentes fundamentales para la metaclase Tool: ToolVersion y ToolHandler Metaclase ToolVersion ToolVersion representa las distintas versiones que existen para una herramienta. Por lo tanto, las propiedades principales de la metaclase ToolVersion son el número de versión y el tipo de licencia asociado a dicha versión. En la práctica, los proyectos de software estarán relacionados a instancias de ToolVersion para la configuración del entorno de desarrollo Metaclase ToolHandler La metaclase ToolHandler representa los mecanismos de configuración (handlers) que existen para una herramienta. El concepto de handler puede hacer referencia a un componente de software (scripts, instaladores, wizards, etc.) o a un conjunto de instrucciones de configuración que deben realizarse manualmente. Por este motivo, la metaclase ToolHandler es una clase abstracta que se especializa en AutomaticToolHandler y ManualToolHandler. El atributo toolhandlerkind definido en la clase ToolHandler indica si un handler es responsable de instalar o configurar una determinada herramienta. La metaclase ExecutionScript es un componente de la metaclase ToolHandler, y representa los pasos de ejecución (opcionales u obligatorios) requeridos por un handler Metaclase ToolDependency La metaclase ToolDependency representa las dependencias que pueden existir entre herramientas. Estas dependencias pueden ser de dos tipos: 1) una herramienta requiere de otra para su instalación; o 2) una herramienta requiere de otra para su correcta configuración en un entorno específico. El atributo tooldependencykind es utilizado para indicar si la dependencia es de tipo componente (herramienta stand-alone o similar) o plugin (herramienta complemento). El atributo optional indica si la dependencia es obligatoria u opcional. En el caso de que la dependencia sea opcional, la dependencia puede entenderse como una recomendación Metaclase InstallationRequirement InstallationRequirement es la metaclase que representa los requisitos en términos de hardware y plataforma para una herramienta particular de acuerdo a su versión. La información de plataformas es representada mediante la metaclase Platform, ya que esta información de plataformas es común para múltiples herramientas, por ejemplo, sistemas operativos o maquinas virtuales de ejecución. 5

6 Figure 3. Metamodelo del Catálogo de herramientas Metaclase ToolHandler Un Tool Handler representa cualquier elemento asociado a la configuración de una herramienta. Un handler puede un mecanismo de configuración de diversa naturaleza, tal como un plugin, un programa stand-alone, una serie de instrucciones manuales, o incluso, un modelo BPMN. La metaclase ToolHandler se especializa en dos clases: AutomaticToolHandler para describir aquellos mecanismos de configuración que se ejecutan automáticamente, y ManualToolHandler para aquellos mecanismos que requieren algún tipo de ejecución manual. 3.2 Metamodelo Tool Installation Catalog El metamodelo de instalación de herramientas, asociado al Installation Tool Catalog, es mucho más simple que el metamodelo Tool Catalog, ya que la información de herramientas instaladas proviene en su mayoría de un catálogo de herramientas existente..es decir, la información detallada de las herramientas que posee la organización (metaclase LocalTool) se indica mediante referencia a uno o más catálogos de herramientas. Por lo tanto, las herramientas que se encuentran instaladas 6

7 corresponden a un subconjunto de las herramientas definidas en los catálogos de herramientas de referencia. El diagrama del metamodelo InstallationCatalog se presenta en la Figure 4. En el metamodelo Installation Catalog, la referencia hacia una herramienta definida en el catalogo de herramientas se especifica mediante la propiedad LocalTool.toolversion, donde el valor asociado a la propiedad toolversion corresponde a una instancia de la metaclase ToolVersion del metamodelo Tool Catalog. Figure 4. Metamodelo Tool Installation Catalog De esta manera, toda la información de la herramienta instalada proviene del catálogo de herramientas referenciado. La metaclase LocalTool sólo incorpora información adicional relacionada con el sistema operativo y ubicación física (servidor) donde está instalada la herramienta. También permite especificar información de conexión (usuario y contraseña) cuando sea necesaria. 3.3 Proceso Para Instanciar Catálogos de Herramientas La Figure 5 muestra los pasos a seguir para instanciar ambos metamodelos y así obtener un catálogo de catálogo de herramientas de referencia y un catálogo de instalación de herramientas para una organización particular. La instanciación de estos metamodelos provee la base para la posterior configuración e instrumentalización de un proceso de desarrollo concreto. Es importante destacar que no es necesario crear un nuevo catálogo de herramientas cada vez que se crea un catálogo de herramientas instaladas, ya que la creación un catálogo de herramientas instaladas puede (y debe) hacer referencia a catálogos de herramientas existentes. 7

8 Figure 5. Proceso para la instanciación de los metamodelos de herramientas El proceso descrito en la Figure 5 muestra el caso más general, en el que no existen catálogos de herramientas previos. Los pasos presentados en Figure 5 son detallados a continuación Create Tool Catalog Model El primer paso en el proceso de instanciar los metamodelos de herramientas y de instalación consiste en la creación de un catálogo de herramientas que será utilizado posteriormente por uno o más catálogos de instalación de herramientas organizacionales. La herramienta TestLink será utilizada para ejemplificar la creación de un nuevo catálogo de herramientas. Esta herramienta es utilizada para desarrollo y gestión de pruebas de software. Se ha seleccionado esta herramienta a modo de ejemplo ya que su definición requiere instanciar gran parte de los constructores definidos en el metamodelo de herramientas. En particular, para caracterizar la herramienta TestLink los siguientes elementos serán especificados: Tipo de Herramienta: Software Testing Versión: 1.8 Licencia: OpenSource Dependencia de plugins: no Dependencia de componentes: sí, opcional: Jira 5.1 (herramienta de issue tracking) Requerimientos de software: Base de datos SQL, PHP, servidor web compatible Plataforma de ejecución: Linux, Windows XP/Vista/7 Capacidad en disco duro: 500 MB recomendados Capacidad en memoria principal: 1 GB de memoria RAM recomendados La herramienta TestLink puede utilizar de manera opcional una herramienta de gestión de incidencias (issue tracking). En nuestro ejemplo, hemos seleccionado la herramienta Jira en su versión 5.1 que es compatible con TestLink. Para agregar la información presentada a un nuevo modelo asociado a un catálogo de herramientas se utilizará un editor EMF generado a partir del metamodelo 8

9 ToolCatalog antes descrito. La Figure 6 muestra un catálogo de herramientas generado con este editor EMF. El modelo resultante es desplegado mediante una estructura de nodos similar a un árbol de directorios. Figure 6. Catálogo de herramientas definido mediante editor EMF La incorporación de nuevas herramientas en el catálogo puede verse como una inserción de nodos en un árbol donde la raíz es el modelo global (nodo GlobalToolCatalog). Figure 7. Creación de una nueva herramienta en el catálogo de herramientas 9

10 La Figure 7 muestra la incorporación de una nueva herramienta en el catálogo que corresponde a un nodo hijo de tipo Tool. En la imagen también se puede apreciar que las plataformas de ejecución para las herramientas se agregan de forma similar. En el catálogo de ejemplo presentado en la Figure 6, se puede observar que se han agregado como plataformas la máquina virtual de Java (Java VM), los sistemas operativos de Microsoft WindowsXP, Windows Vista y Windows 7, y el sistema operativo Linux. Para cada nodo existen una serie de propiedades que corresponden a los atributos y relaciones definidos en el metamodelo del catálogo de herramientas. Por ejemplo, la Figure 8 muestra las propiedades definidas para la herramienta TestLink. Figure 8. Propiedades de la herramienta TestLink Luego, para cada herramienta definida (nodos Tool), es posible especificar las versiones existentes (nodo Tool Version), y los handlers asociados (nodos Automatic Tool Handler y Manual Tool Handler). En la Figure 9 se puede apreciar que además de las versiones, también es posible insertar la información asociada a los Tool Handlers (nodos Automatic Tool Handler y Manual Tool Handler). Figure 9. Inserción de versiones y handlers asociados a una herramienta 10

11 Además, la Figure 10 muestra la información de la versión 1.8 asignada a la herramienta TestLink. Las propiedades asociadas a una versión se corresponden con la lista de propiedades mostrada inicialmente. En esta figura también se observa otras propiedades ligadas a la versión, tales como el tipo de licencia y los requisitos de software y hardware. Figure 10. Propiedades de versión asociadas a la herramienta TestLink Finalmente, por cada versión es posible especificar los requisitos de instalación (nodo Installation Requirement) y dependencias que pueden existir hacia otras herramientas del catálogo (nodo Tool Dependency). La imagen ejemplifica la definición de esta información mediante la creación de los nodos correspondientes como hijos del nodo Tool Version. Figure 11. Elementos de la versión

12 La incorporación de los elementos Tool Dependency e Installation Requirement se muestra en las Figure 12 y Figure 13, respectivamente. En ambas imágenes se aprecian las propiedades desplegadas de cada uno de estos elementos. La especificación de la asociación Tool Dependency indica dependencias de la herramienta TestLink hacia otras herramientas para su correcto funcionamiento. Estas dependencias pueden ser obligatorias u opcionales. En el ejemplo presentado en la Figure 12 las propiedades indican que la dependencia es hacia la herramienta Jira. Es decir, TestLink depende de Jira para su funcionamiento, pero sólo de manera opcional (atributo optional = true). Esto se corresponde con los requisitos establecidos para TestLink que indican que una herramienta de issue tracking como Jira es opcional, pero recomendada. Además, como es una dependencia que tiene comportamiento de componente, entonces el tipo de dependencia es marcado como componente (atributo kind = component). Figure 12. Tool Dependency con propiedades desplegadas. Figure 13. Installation Requirement con propiedades desplegadas En el caso de Installation Requirement, las propiedades que se ven en la Figure 13 reflejan la caracterización inicial de la herramienta. De estas propiedades es 12

13 interesante destacar la plataforma, ya que, tal como se ha mencionado anteriormente, el metamodelo considera una metaclase para definir la plataforma de ejecución para una herramienta. Para TestLink, la plataforma puede ser Linux o Microsoft Windows en sus versiones XP, Vista o 7. Ambas plataformas (Linux y Windows) soportan servidores web compatibles con PHP y bases de datos de tipo SQL. 4. Configuración del Proceso de Desarrollo La configuración de un proceso de desarrollo concreto estará guiado por un modelo SPEM de entrada asociado a un contexto específico. La información de herramientas que pueden ser asignadas a este proceso estará determinada por los metamodelos presentados anteriormente. De esta manera, la conexión entre elementos del proceso de desarrollo y herramientas destinadas a configurar el entorno de desarrollo puede ser definida mediante mappings (también llamados weavings) específicos. El mapping entre herramientas y elementos del proceso de desarrollo utiliza el metamodelo de las herramientas instaladas en la organización (Tool Installation Catalog) y el metamodelo UMA utilizado para especificar el proceso de desarrollo. El metamodelo Tool Catalog no se utiliza (al menos no directamente), ya que las herramientas que se pueden utilizar para configurar un proceso de desarrollo son aquellas disponibles en la organización. A continuación se detallan los distintos elementos del proceso de desarrollo (constructores del metamodelo UMA) que pueden ser configurados. 5.1 Elementos configurables del proceso de desarrollo El mapping entre herramientas y el proceso de desarrollo es definido mediante un modelo específico de configuración (Configuration Model) basado en el metamodelo presentado en la Figure 14. En este metamodelo se pueden apreciar dos tipos de link fundamentales: 1) links de herramientas con elementos del proceso de desarrollo; y 2) links de medidas con elementos del proceso de desarrollo. Estos dos tipos de links se especifican mediante las metaclases abstractas Tool2ProcessElementLink y Measure2ProcessElementLink. Estas metaclases abstractas son especializadas en los distintos elementos del metamodelo UMA que pueden ser referenciados por herramientas o medidas según corresponda. El conjunto de tipos de links definidos para herramientas y medidas puede variar de acuerdo a los resultados obtenidos en la aplicación de la plataforma ADAPTE y nuevas necesidades de configuración que aparezcan, o variaciones asociadas a la definición de procesos de desarrollo. Esta variación se puede expresar como nuevas clases hijas definidas a partir de las clases abstractas asociadas a links de herramientas y medidas, o en la eliminación de alguno de los links (clases hijas) ya definidos. 13

14 Figure 14. Metamodelo asociado al modelo de configuración La Table 1 resume qué elementos del metamodelo UMA pueden ser referenciados por herramientas y medidas de acuerdo a la estructura actual del metamodelo de configuración. Table 1. Elementos de UMA configurables con herramientas y medidas UMA Element Description Tool Measure Process Describe el desarrollo de un proyecto particular X X WorkProduct Describe la salida de una tarea, ya sea el uso, producto o modificación X X Domain Agrupa y jerarquizar work products X Discipline Subconjunto de componentes de un proceso, describe las diferentes disciplinas que trabajan X en un proyecto Task Unidades de trabajo asociadas a un proceso X X Role Representa el rol que realiza una actividad X RoleSet Representa un conjunto de roles X 14

15 5.2 Proceso para Configurar un Proceso de Desarrollo Para configurar un proceso de desarrollo es necesario tener como punto de partida un modelo del proceso basado en el metamodelo UMA. Este modelo del proceso es referenciado por el modelo de configuración, luego se indica el catálogo de herramientas y de medidas que se utilizarán para la configuración. El proceso de configuración es descrito en la Figure 15. Figure 15. Proceso para configurar un proceso de desarrollo A continuación nos centraremos en mostrar la configuración de un proceso de desarrollo a partir del catálogo de herramientas instaladas en la organización. Como se puede apreciar en la Figure 15, para crear los links entre herramientas y elementos del proceso de desarrollo el primer paso es crear un nuevo modelo de configuración y luego cargar el modelo del proceso y el catálogo de herramientas correspondiente. Como resultado, obtendremos un modelo de configuración vacío que hace referencia al proceso y catálogo de herramientas que utilizaremos en la definición de links. Es importante recordar que un proceso puede hacer referencia a múltiples catálogos de herramientas; para esto basta con cargar en el modelo todos los catálogos necesarios. La Figure 16 muestra un modelo de configuración inicial que hace referencia al proceso de prueba de la empresa Rhiscom y a un catálogo de herramientas definido previamente. Figure 16. Modelo de configuración con proceso y catálogos de herramientas cargados En el modelo vacío se observa un único nodo Process Configuration Model, que será la raíz del modelo de configuración. En el modelo presentado en Figure 16 también se puede observar la referencia hacia el catálogo de herramientas (global). Esta referencia se ha obtenido automáticamente al cargar el catálogo de instalación de herramientas (organizacional), ya que como se indicó al comienzo de la sección 3, el catálogo de herramientas instaladas depende directamente de uno o más catálogos de herramientas. 15

16 Una vez cargado el proceso y el catálogo de instalación de herramientas es posible definir nuevos links entre elementos del proceso y las herramientas correspondientes. Estos links son definidos como nodos hijos a partir del nodo raíz del modelo. En la La Figure 17 las distintas alternativas para la creación de nodos hijos que corresponden a los distintos tipos de links soportados por el modelo de configuración. Figure 17. Modelo de configuración con proceso y catálogos de herramientas cargados A modo de ejemplo, la Figure 18 muestra el nodo de tipo tool-to-task (tool2task) llamado development tool que enlaza la herramienta Eclipse Framework del catálogo de instalación con la tarea desarrollo del proceso de referencia. Figure 18. Creación de nodo tool-to-task para la configuración del proceso de Rhiscom 16

17 5. Conclusiones En este documento se han presentado los elementos fundamentales para elaborar los catálogos de herramientas que dan soporte a la plataforma ADAPTE. Estos catálogos han sido definidos utilizando una aproximación dirigida por modelos, que utiliza metamodelos para especificar la estructura y relaciones entre los distintos constructores involucrados. En particular, se han definido dos metamodelos: 1) el metamodelo Tool Catalog para generar catálogos con información global de las herramientas, disponible de manera centralizada; y 2) el metamodelo Tool Installation Catalog que utiliza la información global del catálogo de herramientas para especificar aquellas herramientas disponibles (instaladas) en la organización. Este catálogo de instalación de herramientas además cuenta con los detalles de acceso para poder hacer uso de las herramientas definidas. Este documento también ha presentado los procesos necesarios para poder instanciar los catálogos de herramientas y de instalación de herramientas y utilizarlos en la configuración de un proceso de desarrollo específico. Esta configuración es posible mediante un modelo de configuración basado en un metamodelo de mappings (o weavings). Los modelos los modelos involucrados en este mapping son son: modelo del proceso, catálogo de instalación de herramientas, y catálogo de medidas. Es importante señalar que los metamodelo planteados en este documento conforman la primera iteración en la construcción de la plataforma ADAPTE, y por lo tanto, su refinamiento y modificación en sucesivas iteraciones está considerado como parte del desarrollo y aplicación de los resultados del proyecto. El siguiente paso en el desarrollo del proyecto ADAPTE considera la inclusión de medidas para la configuración y monitoreo de los procesos y entornos de desarrollo. Por otra parte, se iniciará la generación de handlers para automatizar y guiar la configuración del entorno de desarrollo ligado al proceso configurado. Además, se especificarán las reglas de transformación para generar modelos BPMN a partir del proceso configurado que permita ejecutar este proceso mediante un motor de workflow. Agradecimientos: El proyecto ADAPTE es financiado por FONDEF (D09i1171) Referencias 1. Hurtado, J.A., et al., A Context Modeling Language to Support Tailoring of Software Processes, in Technical Report Universidad de Chile OMG, Software & Systems Process Engineering Metamodel (SPEM) Eclipse. Eclipse process framework (EPF). Last access: June 2012; Available from: 4. Nikulsins, V. and O. Nikiforova, Tool Integration to Support SPEM Model Transformations in Eclipse. Scientific Journal of Riga Technical University, Jacobson, I., P.W. Ng, and I. Spence, Enough Process - Let's Do Practices. Journal of Object Technology, (6): p