U NIVERSIDAD DE C ASTILLA -L A M ANCHA E SCUELA S UPERIOR DE I NFORMÁTICA G RADO EN I NGENIERÍA EN I NFORMÁTICA T ECNOLOGÍA ESPECÍFICA DE I NGENIERÍA DEL S OFTWARE T RABAJO DE F IN DE G RADO COMPROMISE Herramienta de Análisis de Conformidad para Procesos Software Víctor Parrado López Diciembre, 2014
202
Embed
GRADO EN INGENIERÍA EN INFORMÁTICA - ruidera.uclm.es
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDAD DE CASTILLA-LA MANCHAESCUELA SUPERIOR DE INFORMÁTICA
GRADO EN INGENIERÍA EN INFORMÁTICA
TECNOLOGÍA ESPECÍFICA DE INGENIERÍA DEL
SOFTWARE
TRABAJO DE FIN DE GRADO
COMPROMISE
Herramienta de Análisis de Conformidad para ProcesosSoftware
Víctor Parrado López
Diciembre, 2014
UNIVERSIDAD DE CASTILLA-LA MANCHAESCUELA SUPERIOR DE INFORMÁTICA
DEPARTAMENTO DE TECNOLOGÍAS YSISTEMAS DE INFORMACIÓN
TECNOLOGÍA ESPECÍFICA DE
INGENIERÍA DEL SOFTWARE
TRABAJO DE FIN DE GRADO
COMPROMISE
Herramienta de Análisis de Conformidad para ProcesosSoftware
Se permite la copia, distribución y/o modificación de este documento bajo los términos dela Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicadapor la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia estaincluida en el apéndice titulado «GNU Free Documentation License».
Muchos de los nombres usados por las compañías para diferenciar sus productos yservicios son reclamados como marcas registradas. Allí donde estos nombres aparezcanen este documento, y cuando el autor haya sido informado de esas marcas registradas, losnombres estarán escritos en mayúsculas o como nombres propios.
Víctor Parrado López, 2014
TRIBUNAL:
Presidente:
Vocal :
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL SECRETARIO
Fdo.: Fdo.: Fdo.:
Resumen
Actualmente las organizaciones se encuentran en un momento en el que, dada la compe-tencia actual, necesitan desarrollar productos de calidad y a un precio razonable. El ámbitode la Ingeniería Software no es una excepción y es por eso que la gestión de los procesos dedesarrollo de los productos ha cobrado una importancia notable en los últimos años, dadoque la calidad del producto final depende directamente de la calidad de los procesos de unaorganización.
La definición de estos procesos es una tarea imprescindible antes de realizar la gestiónde los mismos y éstos han de cubrir todos los objetivos de negocio de la organización. Noobstante, en el estado globalizado en el que se ve sumida la industria del software y ante lacomplejidad y necesidad de homogeneidad en el desarrollo software, es vital que los procesosestén alineados con los estándares y modelos de referencia de procesos.
Con el fin de facilitar el alineamiento de las organizaciones con los procesos de refe-rencia y asistir de forma automática en su procesamiento, en el presente TFG se desarrollala herramienta COMPROMISE. Esta herramienta permite cuantificar el cumplimiento oconformidad de los procesos de la organización con los estándares de la industria, la realiza-ción de transformaciones entre modelos con el fin de proporcionar a los procesos softwarela posibilidad de la ejecución y simulación y el análisis de la conformidad para recomendaraspectos de mejora necesarios para lograr el cumplimiento deseado. Para ello se aplican losparadigmas de Ingeniería de Procesos y Desarrollo de Software Dirigido por Modelos.
vii
Abstract
Nowadays, organizations stands in a situation in which need to develop quality productswith a reasonable prize due to the current competence. Software engineering field is not anexception and, therefore the management of develop products have had a remarkable impor-tance in the last years. So, it is determinated that final products are a direct consecuence of itsdevelopment process and the final quality of the product depend on the organization processes.
Before managing the processes, it’s essential to define them in order to meet the busi-ness organization goals. Nevertheless, in the globalization field, where currently Softwareengineering stands, it is essential that processes are fit with industry standards and referencemodels of processes. This is important to cover the complexity and the homogeneity neededin software development.
This TFG has developed the tool COMPROMISE so as to facilitate the alignment ofthe organizations with reference processes and provide assistance in automatic processing.COMPROMISE lets us to quantify the acceptance of the organization processes with indus-try standards and also, to perform transformations between models. The goal is to provide tothe software processes the execution and simulation possibility and the compliance analysein order to recommend us features that still need to improve to get the desired compliance.For this purpose the models of Model Driven Engineering and Software Process Engineeringpararadigms are applied.
ix
A mis padres, Antonio y Eloísa.Porque siempre han creído en mi.
A mi hermana Inma.Porque siempre saca una sonrisa.
A Fátima .Por sus ánimos continuos e incondicionales,
así todo es más fácil.
A todos, gracias.Sin vosotros no hubiera sido posible.
“Caballeros, ¿debo recordarles que, mis probabilidades de éxito,aumentan en cada nuevo intento?”
xi
Agradecimientos
Es muy poco el espacio para expresar mi gratitud a tantas personas que me han acompañadoen este largo camino, que ahora se ve demasiado corto.
Gracias a mis compañeros de clase durante todos estos años, Juanjo, Carlos, Laguna, Alex,Antonio, Sergio, Rubén, Eloy, Fran. Han sido demasiados los buenos momentos como paraolvidarlos.
Gracias a todos los integrantes del Grupo Alarcos, las cosas aprendidas y las horas com-partidas os hacen imprescindibles en estas líneas.
Gracias Félix, director de este trabajo, por su ayuda constante y por darme la oportunidadde aprender junto a él.
Gracias mis amigos de Manzanares; a Luisma, Arturo, Rincón, Valver, Carlos y Dani.Decían en Martín Hache que “uno se siente parte de muy poca gente; tu país son tus amigosy eso sí se extraña” y es en esta etapa que termina cuando me doy cuenta de las verdadesque esta frase encierra. Echando la vista atrás únicamente me acuerdo de buenos momentos.Gracias por hacer posible este país.
A Fátima, que ha escuchado todos los desvelos de este trabajo y donde únicamente heencontrado apoyo.
A Inma, mi hermana, que inicia su camino. No dejes que nadie te diga lo que tienes quehacer.
A mis padres, por todos estos años de apoyo y por enseñar con el ejemplo que la perseve-rancia nos hace crecer como personas.
A mis abuelos, los que están y los que no.
Gracias a todos. Sin vosotros estas líneas no habrían encontrado la tinta para escribirse.
4.1.3 Proceso Iterativo e Incremental . . . . . . . . . . . . . . . . . . . . . 574.1.4 Flujos Fundamentales de Trabajo Obtenidos para el desarrollo de
1.1 La ciénaga de los estándares y modelos de referencia de la madurez, evalua-ción y mejora de procesos [57]. . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Relación entre ARMONIAS-DGS y COMPROMISE . . . . . . . . . . . . . 5
4.1 Ciclo de vida de OpenUP [35] . . . . . . . . . . . . . . . . . . . . . . . . 534.2 Relaciones del Rol Analista en OpenUP[35] . . . . . . . . . . . . . . . . . 544.3 Relaciones del Rol Comodín en OpenUP[35] . . . . . . . . . . . . . . . . 544.4 Relaciones del Rol Arquitecto en OpenUP[35] . . . . . . . . . . . . . . . . 554.5 Relaciones del Rol Desarrollador en OpenUP[35] . . . . . . . . . . . . . . 564.6 Relaciones del Rol Project Manager en OpenUP[35] . . . . . . . . . . . . 564.7 Relaciones del Rol Stakeholder en OpenUP[57] . . . . . . . . . . . . . . . 564.8 Relaciones del Rol Tester en OpenUP[57] . . . . . . . . . . . . . . . . . . . 574.9 Ciclo de Vida de OpenUP[57] . . . . . . . . . . . . . . . . . . . . . . . . 584.10 Pantalla Principal Herramienta EPFC . . . . . . . . . . . . . . . . . . . . . 614.11 Atención de una Petición Struts2[10] . . . . . . . . . . . . . . . . . . . . . 634.12 Ejemplo Aplicación MySQLWorkbench[10] . . . . . . . . . . . . . . . . . 644.13 Pantalla principal de la Herramienta BPMN Modeler . . . . . . . . . . . . 654.14 Pantalla principal Eclipse Modelling Framework (EMF) . . . . . . . . . . . 674.15 Vista de ejemplo de la aplicación Medini QVT[10] . . . . . . . . . . . . . 684.16 Ejemplo de la herramienta TexMaker[10] . . . . . . . . . . . . . . . . . . 69
5.1 Diagrama general de COMPROMISE . . . . . . . . . . . . . . . . . . . . 795.2 Diagrama de Casos de Uso de Administrador de la Herramienta . . . . . . 80
xix
xx ÍNDICE DE FIGURAS
5.3 Diagrama de casos de uso Gestor de Procesos . . . . . . . . . . . . . . . . . 815.4 Correspondencias ARMONÍAS-DGS y UMA . . . . . . . . . . . . . . . . . 905.5 Diseño de Clases Prueba de Concepto . . . . . . . . . . . . . . . . . . . . . 915.6 Comparativa de procesos COMPROMISE y EPFC . . . . . . . . . . . . . 935.7 Generar Clases con JAXB . . . . . . . . . . . . . . . . . . . . . . . . . . 945.8 Jerarquía de Elementos para la definición de Procesos en SPEM 2.0[10] . . 945.9 Diagrama de Diseño correspondiente a la obtención de Procesos de la Orga-
nización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.10 Diagrama General de la Herramienta con Struts2 . . . . . . . . . . . . . . 965.11 Estructura General Paquetes COMPROMISE . . . . . . . . . . . . . . . . . 975.12 Prototipo de Interfaz para la visualización de la conformidad . . . . . . . . 1005.13 Diagrama clases de análisis para evaluar la Conformidad de Proceso . . . 1005.14 Diagrama Clases Recomendador . . . . . . . . . . . . . . . . . . . . . . . . 1015.15 Gráfica de Compliance total de la organización. . . . . . . . . . . . . . . . 1025.16 Ejemplo gráfica Barras de Compliance . . . . . . . . . . . . . . . . . . . 1055.17 Ejemplo gráfica Área de Compliance . . . . . . . . . . . . . . . . . . . . . 1055.18 Diagrama de clases de Diseño Generar Informe . . . . . . . . . . . . . . . 1065.19 Diagrama de clases de Análisis para generar PDF[10] . . . . . . . . . . . . 1075.20 Ejemplo de Proceso definido con EPFC . . . . . . . . . . . . . . . . . . . 1105.21 Descomposición Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.22 Alta de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.23 Diagrama de base de datos de COMPROMISE . . . . . . . . . . . . . . . 1135.24 Simplificación BBDD Armonias-DGS . . . . . . . . . . . . . . . . . . . . 1145.25 Selección márgen de aceptación para Proceso . . . . . . . . . . . . . . . . 1155.26 Menú de Selección COMPROMISE . . . . . . . . . . . . . . . . . . . . . 1185.27 Diagrama de Análisis para la función de Transformación entre Modelos . . 1195.28 Ejemplo de estructura deproceso definida con EPFC en la herramienta
B.16 Gráfico de barras correspondiente a la Conformidad de Proceso . . . . . . 154B.17 Roles Relacionados con la Tarea Seleccionada . . . . . . . . . . . . . . . 155B.18 Gráfica correspondiente al Compliance de la Organización por Marcos de
Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155B.19 Menú desplegable para la función Recomendador . . . . . . . . . . . . . . 156B.20 Función de generación de Informes PDF . . . . . . . . . . . . . . . . . . 156B.21 Ejecución de la Composición del Documento .xmi para el Framework Medi-
14. Adquirir la destreza para llevar a cabo el control de versiones, realizando la gestión de
la configuración mediante un repositorio remoto GIT.
Capítulo 3
Estado de la Cuestión
En este capítulo se presentan los conocimientos derivados de la construcción de la herramienta.
En primer lugar se profundizará en el concepto de proceso software, el cual constituye una
base fundamental para el presente TFG, siendo el dominio sobre el cual el sistema tendrá
cabida.
Después se tratarán varios conceptos, como la relación del presente TFG con la Ingeniería
de Procesos Software, con los metamodelos SPEM, UMA y la herramienta EPFC, se realizará
una breve introducción en los modelos de referencia y mejora de procesos software más
importantes en la industria, el paradigma de la armonización y conformidad de procesos así
como el desarrollo de software dirigido por modelos y las herramientas existentes relacionadas
con la conformidad de procesos software.
16 3.1. PROCESOS SOFTWARE
3.1 Procesos Software
La Ingeniería del Software, desde un origen, se ha centrado principalmente en las metodolo-
gías de desarrollo, en los lenguajes de programación, en los modelos de desarrollo y en las
herramientas que la apoyan. No obstante su complejidad, ha hecho necesario tener en cuenta
aspectos organizacionales y de gestión en la elaboración del producto, es por eso que surge la
denominada Ingeniería del Software Basada en el Proceso [74].
Básicamente un Proceso Software es un conjunto coherente de políticas, estructuras
organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir,
desarrollar, empaquetar y mantener un producto software [36].
Como podemos observar en la definición anterior, un proceso se compone de varios
elementos muy próximos a la organización, y es por eso que se hace necesaria una gestión de
todos ellos denominada Gestión de Procesos.
La Gestión de Procesos [57] es vital para las organizaciones, pues éstas son tan eficientes
como lo sean sus procesos. Para lograr una buena Gestión de Procesos una organización debe
asumir cuatro responsabilidades sobre los mismos: Definir, Medir, Controlar y Mejorar el
Proceso. (Figura 3.1)
• Definición del Proceso: El primer paso es la definición del mismo. Para ello deberemos
modelarlos, representando los elementos oportunos.
• Ejecución y Control del Proceso: Los proyectos software de una organización se
llevan a cabo de acuerdo a los modelos de procesos definidos. Por eso es importante
poder controlar en todo momento la ejecución de los proyectos. Para esta labor se han
desarrollado los Entornos de Ingeniería del Software orientado a Procesos (PSEE).
• Medición y Mejora: Es clara la correlación entre estos dos términos. Antes de poder
mejorar un proceso es necesario llevar a cabo una evaluación, la cual necesita de una
medición. Con los resultados de ésta es posible disponer de una información objetiva
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 17
que permita planificar, identificar y llevar a cabo de una manera eficiente las acciones
de mejora.
A continuación se presenta una imagen que ilustra las etapas clave en la gestión del
proceso anteriormente nombradas, junto con sus interrelaciones.
Figura 3.1: Etapas Clave de la Gestión del Proceso Software [57].
Para modelar los procesos de una organización, decidiremos qué elementos forman parte
del proceso y sus interrelaciones. Con el fin de sistematizar el procedimiento de definición el
proceso será conveniente utilizar unos patrones bien formados, denominados metamodelos.
Aunque trataremos el término en más profundidad en la Sección 3.7, básicamente un
metamodelo es un modelo del lenguaje que captura las propiedades y características esencia-
les. Esto incluye los conceptos de lenguaje que lo apoya y/o la sintaxis gráfica junto con la
semántica [31].
El término anterior unido a la creciente complejidad de los sistemas actuales hacen nece-
sarias un conjunto de reglas y herramientas con las que visualizar el sistema a construir. Este
paradigma es conocido como Modelado de Sistemas Software.
El modelado de Sistemas Software trajo consigo una cantidad notable de Lenguajes de
Modelado, no obstante el más conocido en la actualidad y respaldado por el OMG es el
18 3.2. INGENIERÍA DE PROCESOS SOFTWARE
Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Lan-
guage), dicho lenguaje se explica con más profundidad en la sección del método de trabajo
correspondiente (Sección 4.2.4.1).
El paradigma del modelado influyó de manera notable también en el área de los Procesos
Software. El aprovechamiento de este concepto por parte de las organizaciones puede dotarla
de una posición privilegiada respecto al resto. Por ejemplo, una organización, a partir de los
modelos de Procesos definidos puede realizar una simulación de la ejecución de éstos que
evaluará el impacto de la toma de decisiones en un periodo de tiempo sensiblemente menor
que si se ejecutaran de manera real. De esta manera se abre un mayor número de alternativas,
pues en unos pocos minutos podremos obtener resultados que de otra manera nos llevarían
semanas, meses o años. Esta opción, además de rápida, ofrece unas ventajas significativas en
cuanto a costes se refiere, comparado por ejemplo, con el tratamiento de “prueba y error”.
No obstante, hay algunas desventajas que pueden dificultar la labor del modelado. La
dificultad intrínseca del mismo puede no capturar todos los elementos del proceso así como
sus relaciones y dependencias. Es por eso que el encargado del modelado de procesos de una
organización deberá tener un alto grado de preparación y experiencia para elaborar nuevos
modelos e interpretar las salidas de éstos.
3.2 Ingeniería de Procesos Software
Según lo expuesto en la sección anterior, modelando los procesos de la organización obte-
nemos una visión con un nivel de abstracción que nos permitirá controlar cada uno de los
aspectos de la misma en cuanto a procesos se refiere, redundando en una mejora de la calidad
de los productos. Además el modelado supone la apertura de nuevas perspectivas que se
derivan de que los procesos se manejan (representan, definen, publican, etc) de una manera
mucho más eficiente, suponiendo una ventaja a la hora de la certificación de los modelos [62].
Hay varias maneras de expresar los procesos de una organización, no obstante la forma
en la que se publican determina en gran medida el uso posterior que podrán recibir. En el
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 19
caso de que el/los procesos se presenten en forma de documento de texto con una descripción
detallada de los mismos, únicamente podremos hacer uso de esta presentación para apoyarnos
en la gestión de los mismos.
Por el contrario, si la información del proceso está soportada por un metamodelo y re-
presentada mediante un formato de intercambio estándar, como por ejemplo XML (siglas de
eXtensible Markyp Language), será posible realizar cualquier tipo de procesamiento automá-
tico, y el intercambio de esta información entre las distintas herramientas del mercado propias
de este paradigma será mucho más accesible.
Es decir, la forma en la que el Proceso se presenta puede determinar la transformación
de una visión Contemplativa a una Productiva, lo que genera múltiples posibilidades a la
Ingeniería de Procesos Software, de las cuales la organización puede obtener sustanciosas
ventajas. Algunas de ellas son [62]:
• Poder integrar varios Procesos Software , cada uno con su modelo.
• Dar soporte a la mejora de Procesos Software.
• Facilitar la evolución del modelo de un Proceso Software.
• Gestionar de forma integrada el proceso y su ciclo de vida (diseño, despliegue, ejecución,
automatización, mejora, etc.)
• Facilitar la construcción de plataformas más potentes de cara a la gestión de procesos y
la gestión de proyectos.
• Permitir que el repositorio de procesos sea más genérico y tenga más capacidad semán-
tica. Esto significa facilitar técnicamente la gestión del conocimiento relacionado con
los procesos.
• Permitir que todas las herramientas (CASE, gestión de proyectos, etc.) compartan los
modelos.
• Generar la plantilla del plan de un proyecto.
• Realizar procesamiento y transformaciones directamente sobre los modelos.
20 3.3. SPEM Y EPFC
• Reutilizar mediante diferentes mecanismos de herencia fragmentos de métodos y
procesos.
• Disponer de distintas vistas de un proceso y diferentes versiones de una familia de
procesos.
• Facilitar la generación de información on-line para formación de recursos humanos
Un ejemplo de la aplicación de este paradigma es el caso de la herramienta EPFC, men-
cionada con anterioridad, que da soporte a la representación de procesos software conforme al
metamodelo UMA (compatible con SPEM 2.0). Ello permite, por ejemplo, a la herramienta
EPFC procesar la información de los modelos y publicar automáticamente en formato Web la
información necesaria sobre los procesos de la Organización, favoreciendo así la transmisión
de conocimiento entre los involucrados. En la siguiente sección se describe con mayor detalle
SPEM 2.0 (junto con el Metamodelo UMA) y EPFC.
3.3 SPEM y EPFC
UMA es el lenguaje de modelado que soportará la definición de procesos en la herramienta
de modelado EPFC. La Arquitectura de Método Unificado o Unified Method Architecture
(UMA) , es un metamodelo basado en SPEM 2.0 que permite generar modelos compatibles
con éste. UMA surgió de la necesidad de simplificar SPEM 2.0 para aquellas labores en las
que no se necesitaba de tanta granularidad a la hora de definir los procesos. No obstante
hablaremos de SPEM 2.0 en esta sección, pues comparten la mayoría de los componentes y
es el metamodelo original.
SPEM 2.0, siglas de (Software & Systems Process Engineering Metamodel Specification),
es un metamodelo utilizado para definir modelos (instancias de los metamodelos) de procesos
software. Dota al estado de la cuestión con una guía con la que homogeneizar la terminología
existente entre los lenguajes de modelado de procesos software en los conceptos tratados con
nombres diferentes.
El metamodelo SPEM 2.0 propone unos elementos mínimos sobre los cuales cabe la
posibilidad de definir los procesos, estos son: los roles, los productos de trabajo y las tareas. A
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 21
continuación, en la Figura 3.2, se ilustra con una imagen los elementos nombrados, así como
las interrelaciones entre los mismos.
Figura 3.2: Conceptos centrales de SPEM 2.0. [63]
Además de un metamodelo que apoya la ingeniería de procesos, SPEM 2.0 es un marco de
trabajo que proporciona la estructura para modelar, documentar, presentar, publicar, gestionar,
intercambiar y realizar métodos y procesos software.
22 3.3. SPEM Y EPFC
La Figura 3.3 representa el marco de trabajo anteriormente mencionado. A continuación
enunciaremos los usos principales de SPEM 2.0.
Figura 3.3: Usos básicos SPEM 2.0. [63]
A continuación se explicarán de manera detallada los usos de la figura anterior [57]:
• Proporcionar un repositorio de conocimiento en forma de “Contenido de método”, en-
tendiéndose éstos como un conjunto de unidades de trabajo reutilizables (una colección
organizada de roles, tareas, productos de trabajo, guías, etc). Así, el Ingeniero de Proce-
sos se apoyará en este conocimiento para componer los procesos de la organización.
• Una guía para todo el equipo que servirá como pauta para soportar el desarrollo, la
gestión y el conocimiento de los procesos software. A medida que el proyecto software
avanza, los distintos grupos de trabajo que forman parte del desarrollo del proyecto
deben conocer y saber aplicar los métodos de desarrollo y el conjunto de prácticas
óptimo a adquirir a lo largo del ciclo de vida. SPEM 2.0 nos proporciona un marco de
trabajo idóneo para la compartición de conocimiento, presentándolo de una manera
organizada y ofreciendo frameworks que soporten este paradigma (por ejemplo el
utilizado en este desarrollo, EPFC).
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 23
• SPEM 2.0 nos permite definir distintas configuraciones del contenido de método de-
pendiendo de las características del proyecto. Teniendo en cuenta que exactamente el
mismo proceso no se ejecuta dos veces de manera idéntica, es útil definir el despliegue
del contenido de método y proceso que se necesita en cada caso.
• Dar soporte a la realización de un proceso para llevar a cabo los proyectos de desa-
rrollo concretos [57]. Lo cual permite a los jefes de proyecto contar con información
del mismo y abstraerse de la complejidad del mismo para definir los planes del proyecto.
Una vez tratados los propósitos del mismo, nos centraremos en la estructura interna del
metamodelo para comprender los elementos que lo conforman y su interrelación. En SPEM
2.0 se distinguen dos grupos conceptuales claramente diferenciados, una parte denominada
contenido de Método o “Method Content”, que albergará los elementos que componen sus
procesos, como pueden ser las tareas, los roles que llevan a cabo éstas, las herramientas que
intervienen para su correcta realización, etc. Y por otro lado un componente denominado
“Procesos” o Process, que se apoyará en el anterior, definiendo los procesos de la organiza-
ción a partir de la combinación de elementos del contenido de método. Los elementos que
componen los procesos se dice que están en uso, por tanto este apartado está formado por
Tareas en uso, Roles en uso, etc.
En la Figura 3.4 se muestran los dos conceptos anteriores. Además se puede ver que ambos
están unidos por elemento común denominado guía o Guidance en inglés, cuyo cometido
será proporcionar información adicional a cualquiera de los dos grupos mencionados con
anterioridad, asumiendo una función contemplativa.
24 3.3. SPEM Y EPFC
Figura 3.4: Elementos de SPEM 2.0 [63].
3.3.1 Visión del metamodelo SPEM 2.0
SPEM 2.0 utiliza UML como notación gráfica para describir su metamodelo, adoptando un
enfoque orientado a objetos, y definiendose en términos de paquetes, con fines de reutilización
y organización [57]. SPEM 2.0 se organiza en una jerarquía de 7 paquetes, en los que los
hijos extienden la funcionalidad del padre, aportando algunas funcionalidades adicionales.
Dependiendo de las intenciones del modelado y el nivel de completitud deseado, puede
hacerse uso de todos los paquetes o del subconjunto necesario en cada caso. A contiuación
se presentan las funcionalidades básicas de cada paquete así como la Figura 3.5 en la que
podremos observar su jerarquía.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 25
Figura 3.5: Estructura de paquetes de SPEM 2.0 [57].
A continuación pasaremos a detallar cada uno de los paquetes:
• Core: Contiene las clases y abstracciones que sirven de base para las clases de los
demás paquetes del metamodelo.
• Process Structure: Contiene las clases necesarias para la creación de modelos de
procesos.
• Managed Content: Nos va a permitir dotar a nuestros procesos o sistemas de anota-
ciones y descripciones que no pueden ser expresadas como modelos y que por tanto
deben ser documentadas y gestionadas como descripciones en lenguaje natural.
• Method Content: Contiene los conceptos de SPEM 2.0 relacionados con los usuarios y
su organización. Estos conceptos son necesarios para construir la base de conocimiento
sobre desarrollo que pueda ser utilizada independientemente del proceso o proyecto
específico.
26 3.3. SPEM Y EPFC
• Process With Methods: Contiene los elementos necesarios para integrar los conceptos
del paquete “Process Structure” con los conceptos y elementos del paquete “Method
Content”.
• Method Plug-In: Introduce los conceptos para diseñar, gestionar y mantener reposito-
rios y librerías de “Methods Content” y Procesos.
Como hemos enunciado en el Capítulo 2 uno de los objetivos de COMPROMISE es
proporcionar al ingeniero de procesos una fuente de conocimiento almacenable y disponible
en todo momento. Es por eso que nos centraremos en el paquete del contenido de método, el
cual dispone de los siguientes constructores básicos [57]:
• Tarea (Task Definition): Es el nivel atómico de descomposición de los procesos. Está
relacionado con:
– Uno o más Roles que realizan la tarea
– Uno o más Productos de Trabajo que pueden ser definidos como entradas obliga-
torias, opcionales o salidas.
– Cero o más Herramientas que se recomiendan usar para la realización de la tarea.
– Cero o más Pasos que describen de forma secuencial el trabajo a realizar.
– Cero o más Habilidades que se requieren para llevar a cabo la tarea.
• Paso (Step): Descompone la tarea en unidades más pequeñas en caso de que se necesite
una granularidad mayor a la hora de elaborar dicha tarea, aunque por sí mismas no
tienen valor dentro del proceso. Cabe destacar que a la hora de definir los pasos de una
tarea, estos no tienen por qué ejecutarse cada vez que se lleve a cabo, pues se podrá
implementar siguiendo diferentes combinaciones de los mismos. Es por eso que los
datos se pueden expresar como flujos de trabajo alternativos. Hay varios tipos de pasos
que se pueden considerar dentro de una tarea.
– Pensamiento o Thinking steps, en los que la finalidad es que el rol comprenda la
tarea y examine todos los artefactos de entrada y formula un resultado (outcome).
– Realización (Performing steps), en los que el usuario crea o modifica algunos
artefactos.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 27
– Revisión (Reviewing steps), en los que los roles inspeccionan los resultados
respectos a unos criterios.
• Producto de trabajo (Work Product Definition): Son los elementos del contenido de
método de los cuales hacen uso, modifican y producen las tareas. A su vez los productos
de trabajo pueden estar relacionados con otros. Existen los siguientes tipos:
– Artefacto (artifact): Define un producto de trabajo tangible, como puede ser un
modelo, documento, código fuente, etc. Éste a su vez puede estar compuesto por
otros artefactos.
– Entregable (deliverable): Representa un entregable de valor para el usuario o
cliente.
– Resultado (outcome): Se utilizan para representar productos de trabajo que no
están formalmente definidos. Los resultados de éstos no son reutilizables.
• Rol (Role Definition): Define un elemento con un cojunto de habilidades, competencias
y responsabilidades de una persona o un conjunto de personas. Una persona no es un
rol, un individuo puede desempeñar varios roles dependiendo de sus competencias o un
rol puede estar desempeñados por varias personas.
• Cualificación(Qualification): Documenta las aptitudes, habilidades y competencias por
parte de los roles para la realización de las tareas. En el presente TFG no haremos uso
de este elemento.
• Herramienta (Tool): Describe las capacidades de una herramienta CASE, o de propó-
sito general, o de cualquier otra unidad automatizada de apoyo para realizar las tareas
por parte de los roles.
• Categoría (Category): Permite agrupar cualquier número de elementos describibles de
cualquier subtipo en base a unos criterios. Una categoría puede anidarse estableciéndose
jerarquías. Las categorías estándar son:
– Disciplina (Discipline): Permite categorizar el trabajo (tareas). Una disciplina es
una colección de tareas que están relacionadas dentro de una determinada área de
interés de un proyecto.
28 3.3. SPEM Y EPFC
– Conjunto de Roles (Rol Set): Agrupa roles que tienen algo en común como el
hecho de usar técnicas similares, requerir habilidades parecidas, etc.
• Guía (Guidance) proporciona información adicional a cualquier elemento describible.
Existen diversos tipos de guías:
– Guías (guidelines)
– Listas de comprobación (checklist)
– Plantillas (templates)
– Informes (reports)
– Estimaciones (estimates)
• Métrica (Metric), define una medición estándar para las instancias de cualquier ele-
mento descriptible en SPEM 2.0, como por ejemplo las horas de esfuerzo para una
tarea.
3.3.2 Eclipse Process Framework Composer (EPFC)
SPEM 2.0 proporciona un contexto en el que definir nuestro proceso junto con todos sus
elementos y componentes. No obstante, sería precipitado pensar en una definición de procesos
software complejos y a su vez abordables de manera manual siguiendo dicho metamodelo,
pues su dificultad seguramente lo impediría. Es por eso que se hace necesario el uso de
herramientas que permitan la visualización, almacenamiento y composición de los procesos
de una organización, así como de sus elementos más importantes. Con tal fin se creó Eclipse
Process Framework Composer, cuyas siglas EPFC dan nombre al Framework en la mayoría
de los casos.
EPFC es una herramienta gratuita, desarrollada en el entorno Eclipse y que sirve para
editar fragmentos de método, procesos o metodología y generar automáticamente la docu-
mentación pertinente en formato Web, entre otras funcionalidades.
La completitud y granularidad del metamodelo SPEM 2.0 no era necesaria para la gestión
de los procesos en la herramienta, es por eso que ésta utiliza como lenguaje de modelado
la Arquitectura de Método Unificado (Unified Method Architecture, UMA), basada en el
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 29
metamodelo SPEM 2.0, motivo por el cual EPFC es capaz de generar modelos compatibles
con SPEM 2.0.
El primer paso con EPFC es definir el contenido de método con todos los elementos
disponibles para su posterior utilización en la definición de los procesos. Aunque para
el funcionamiento de nuestro TFG es un paso fundamental, que la herramienta realizará
automáticamente, poblar el contenido de método no es estrictamente obligatorio para las
organizaciones, aunque si nos permite tener la base de conocimiento mencionada en la
Sección 3.3.1 con todos los elementos definidos por la organización. Además nos facilitará la
definición de nuestros procesos basándonos en una continua reutilización del Contenido de
Método propio de cada organización, de esta manera también será menos propenso a errores,
pues se utilizarán tareas predefinidas (en la mayoría de los casos probadas con anterioridad)
que incluiremos en el proceso a definir.
Figura 3.6: Ejemplo gráfico del contenido de método definido con EPFC.
Además, como vemos en la Figura 3.6, los elementos del contenido de método se engloba-
rán dentro de subcategorías según su naturaleza, separando así entre tareas, disciplinas, guías,
etc; tal y como enunciábamos en la sección anterior.
30 3.3. SPEM Y EPFC
Un paso posterior a determinar el contenido de método del que dispondrá la organización,
será la definición del proceso con todos los componentes que intervienen en el mismo, así
como sus interrelaciones. A continuación, en la Figura 3.7 se ilustra la jerarquía de elementos
de un proceso definidos en SPEM 2.0:
Figura 3.7: Jerarquía de los elementos de SPEM 2.0 en la definición de Procesos [57].
EPFC cuenta con una interfaz sencilla e intuitiva que permite al ingeniero de procesos
estructurar un proyecto mediante una estructura de descomposición de trabajo (EDT), tal
como se ilustra en el ejemplo de la Figura 3.8.
Figura 3.8: Definición del proceso con EPFC
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 31
Este paso es muy importante a la hora de controlar nuestro proceso y medirlo, y es eso
por lo que cada vez este tipo de herramientas están cobrando mayor importancia, pues juegan
un papel fundamental a la hora de la certificación en los distintos marcos de referencia del
mercado [57]. En la siguiente sección se presentan algunos modelos de referencia.
3.4 Modelos de Referencia y Mejora de Procesos Software
En este apartado se presentan los modelos de referencia más importantes por su implicación
en el presente TFG. En COMPROMISE, es objetivo que estos modelos pueblen el contenido
de método de EPFC, aunque como ya hemos comentado anteriormente no es estrictamente
necesario para las organizaciones, pues podrán crear tareas que no estén sujetas a ningún mo-
delo de referencia. No obstante sí que es recomendable, pues de este modo las organizaciones
tendrán sus tareas completamente alineadas con los estándares del mundo empresarial.
3.4.1 CMMI
CMMI es un modelo desarrollado por el SEI (siglas de Software Engineering Institute) o
Instituto de Ingeniería de Software, para la mejora y evaluación de los procesos basándose en
que la calidad de los productos es consecuencia directa de la calidad de los procesos que lo
desarrollan [57].
Para ello, el framework CMMI provee a las organizaciones de un conjunto de Áreas Clave
de Proceso (KPA - Key Process Area). Dichas áreas a su vez se agrupan en cinco niveles de
madurez, de modo que una organización que posea un nivel de madurez determinado, con
todas las áreas clave del proceso satisfechas además de ese nivel, también se considera que
cumple los anteriores.
La disposición de las organizaciones según su nivel de madurez, como hemos dicho, se
basa en la calidad de sus procesos y como consecuencia en la calidad que es capaz de ofrecer
con sus productos resultantes.
CMMI define cinco niveles de madurez [67]:
• Inicial: En un origen todas las organizaciones están en este nivel. En él no disponen de
32 3.4. MODELOS DE REFERENCIA Y MEJORA DE PROCESOS SOFTWARE
un ambiente estable para el desarrollo y mantenimiento Software.
• Repetible: En este nivel las organizaciones disponen de unas prácticas institucionaliza-
das de gestión de proyectos además de unas métricas estándar con un nivel básico de
seguimiento de la calidad.
• Definido: A este nivel las organizaciones poseen procedimientos funcionales de coor-
dinación entre grupos, formación del personal y son capaces de medir sus procesos.
• Gestionado: En este nivel las organizaciones poseen un conjunto de métricas signifi-
cativas de la calidad y productividad que se usan de modo sistemático en la toma de
decisiones.
• Optimizado: Se hace uso intensivo de las métricas y se persigue la innovación del
proceso mediante la continua mejora de sus procesos. Son muy pocas las organizaciones
que se encuentran en este nivel de madurez.
Debido a la aceptación del modelo y a la heterogeneidad de las posibles aplicaciones,
el SEI propone tres especializaciones de CMMI para soportar las diferentes prácticas. Los
diferentes ámbitos (adquisición, desarrollo y servicios) se resumen brevemente a continuación
nombrados por sus siglas:
• CMMI-ACQ: Proporciona un conjunto de buenas prácticas para el cliente con el fin
de controlar la adquisición de productos y servicios.
• CMMI-DEV: Cubre actividades de desarrollo y mantenimiento respecto de productos
y servicios.
• CMMI-SVC: Provee a las organizaciones de una guía para proveer servicios tanto a
clientes externos como dentro de la propia organización.
3.4.2 ISO/IEC 12207
Este estándar internacional establece un marco común para los procesos del ciclo del software
con una terminología bien definida y conocida que puede ser referenciada por la Industria del
Software.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 33
La norma ISO/IEC 12207 fue publicada en Agosto de 1995 por el International Organi-
zation for Standardization (ISO) y por el International Electrotechnical Commision (IEC).
Establece la arquitectura que da cabida a los procesos y a sus interrelaciones. Abarca todo el
ciclo de vida y aboga por una descomposición del proceso en actividades, implementadas a
partir de un conjunto de tareas, siendo éstas un elemento atómico [12].
Dichos procesos, actividades y tareas se aplican durante el suministro, desarrollo, ope-
ración y mantenimiento de productos software. Además la norma deja cierta libertad a las
organizaciones para definir cómo ejecutar el proceso, de esta manera la norma proporciona la
flexibilidad necesaria para que los países o las organizaciones la implementen de acuerdo a
los recursos disponibles y a las prácticas propias de cada posición geográfica en caso de que
se necesite.
Este Estándar Internacional puede ser usado para los siguientes propósitos:
• Por una Organización: Para ayudar a establecer los procesos deseados. Estos procesos
pueden ser soportados por una infraestructura de métodos, procedimientos, técnicas,
herramientas y personal entrenado.
• Por un Proyecto: Para ayudar a seleccionar, estructurar y emplear los elementos de un
ciclo de vida establecido con el fin de proveer productos y servicios. En este modo, el
estándar es usado para asegurar la conformidad del proyecto.
• Por un Proveedor o Cliente : Para ayudar a desarrollar los procesos y actividades
acordados previamente entre ambos. Mediante este acuerdo, los procesos y actividades
son seleccionados, negociados, aprobados y realizados. En este propósito el estándar es
usado como guía en el desarrollo de dicho acuerdo.
• Por Organizaciones y Asesores: En este propósito el estándar es usado para realizar
evaluaciones de los procesos de la organización.
A continuación, en la Figura 3.9 se encuentran todos los procesos que conforman la norma
ISO/IEC 12007:2008 categorizados y agrupados:
34 3.4. MODELOS DE REFERENCIA Y MEJORA DE PROCESOS SOFTWARE
Agreement
Process
Acquisition Process
(Clause 6.1.1)
Supply Process
(Clause 6.1.2)
Organizational
Project-Enabling
Processes
Life Cycle Model
Management Process
(Clause 6.2.1)
Infraestructure
Management Process
(Clause 6.2.2)
Project Portfolio
Management Process
(Clause 6.2.3)
Human Resource
Management Process
(Clause 6.2.4)
Quality Management
Process
(Clause 6.2.5)
Project
Processes
Project Planning Proceses
(Clause 6.3.1)
Project Assesment and
Control Process
(Clause 6.3.2)
Decision Management
Process
(Clause 6.3.3)
Risk Management
Process
(Clause 6.3.4)
Information Management
Process(Clause 6.3.6)
Configuration Management
Process(Clause 6.3.5)
Measurement Process
(Clause 6.3.7)
Technical
Processes
Stakeholder
Requirements Definition
Process
(Clause 6.4.1)
System Requirements
Analysis Process
(Clause 6.4.2)
System Architectural
Design Process
(Clause 6.4.3)
Implementation
Process
(Clause 6.4.4)
System Qualification
Testing Process
(Clause 6.4.6)
System Integration
Process
(Clause 6.4.5)
System Instalation Process
(Clause 6.4.7)
Software Acceptance
Support Process
(Clause 6.4.8)
Software Operation Process
(Clause 6.4.9)
Software Mantenace
Process
(Clause 6.4.10)
Software Disposal
Process
(Clause 6.4.11)
SW Implementation
Process
Software Implementation
Process
(Clause 7.1.1)
Software Requirements
Analysis Process
(Clause 7.1.2)
Software Architectural
Design Process
(Clause 7.1.3)
SoftwareDetailed Design
Process
(Clause 7.1.4)
Software Integration
Process
(Clause 7.1.6)
Software Construction
Process
(Clause 7.1.5)
Software Qualification
Testing Process
(Clause 7.1.7)
SW Support
Process
Software Documentation
Management Process
(Clause 7.2.1)
Software Configuration
Management Process
(Clause 7.2.2)
Software Quality
Assurance Process
(Clause 7.2.3)
Software Verification
Process
(Clause 7.2.4)
Software Audit Process
(Clause 7.2.6)
Software Validation
Process
(Clause 7.2.5)
Software Problem
Resolution Process
(Clause 7.2.7)
Software Reuse Processes
Domain Engineering
Process
(Clause 7.3.1)
Reuse Asset
Management Process
(Clause 7.3.2)
Reuse Program
Management Process
(Clause 7.3.3)
SYSTEM CONTEXT PROCESSES SOFTWARE SPECIFIC PROCESSES
Figura 3.9: Procesos ISO 12207
3.4.3 ISO/IEC 9000
Es un conjunto de buenas prácticas que se ocupa de la gestión de la calidad en las organizacio-
nes. Su primera publicación tuvo lugar en 1987 y cumpliendo con la norma ISO, que obliga a
que todas las normas sean revisadas al menos cada cinco años, tendrá su próxima revisión en
2015. Actualmente, la familia ISO 9000 se compone de cuatro normas [57]:
• UNE-EN ISO 9000 - Sistemas de gestión de la calidad. Funcionamientos y vocabulario
• UNE-EN ISO 9001 - Sistemas de gestión de la calidad. Requisitos
• UNE-EN ISO 9004 - Gestión para el éxito sostenido de una organización. Enfoque de
gestión de la calidad.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 35
• UNE-EN ISO 19011 - Directrices para la auditoría de sistemas de gestión de la calidad
y/o medioambiental.
Básicamente especifica los requisitos para un sistema de gestión de la calidad cuando
necesita demostrar su capacidad para proporcionar regularmente productos con requisitos
que satisfagan al cliente o aumentar la satisfacción del cliente aplicando los procesos para la
mejora continua del sistema.
3.4.4 ISO 90003
Proporciona una guía a las organizaciones para la aplicación de la norma ISO 9001 para la
adquisición, apoyo, desarrollo, operaciones y mantenimiento de los procesos software y los
servicios necesarios. Dicha norma no añade o cambia nada de los requisitos de la norma ISO
9001 [57].
Las guías de la norma ISO/IEC 90003:2004 no están destinadas a ser utilizados como
criterios de evaluación en el sistema de gestión de calidad.
Para cumplir la norma, las organizaciones no tienen por qué implementar todas las
actividades, sino que pueden centrarse en algún área a mejorar. La norma aborda las cuestiones
que deben tratarse y es independiente de la tecnología, los modelos de ciclo de vida, los
procesos de desarrollo, la secuencia de actividades y la estructura de la organización.
3.5 Armonización
Como hemos comentado en el capítulo de Introducción existen numerosos marcos de referen-
cia, los cuales proveen a las organizaciones de un conjunto de buenas prácticas que permiten
a las mismas disponer de un conocimiento adicional a la hora de elaborar sus procesos.
Dada la gran cantidad de modelos de referencia (Figura 1.1), algunos de ellos expuestos
en la sección anterior, y los propósitos tan diversos de los mismos puede ocurrir que elegir
adecuadamente el modelo que agrupe todos los requisitos necesarios sea una tarea ardua.
Es por eso que muchas organizaciones encuentran la solución al problema mediante la
Armonización de procesos de distintos marcos de referencia, surgiendo así el paradigma
de los Ambientes Multimarco. Según [53] los ambientes multimarco surgen cuando una
organización decide o necesita integrar a sus procesos diversas prácticas o características no
36 3.5. ARMONIZACIÓN
presentes en uno, sino en varios marcos.
Dado el estado de la cuestión actual en este área unido al desconocimiento de la manera
de proceder de las organizaciones, es común que las prácticas que utilicen para lograr la
armonización de distintos marcos de procesos no sea la adecuada, imposibilitando la tarea y
convirtiéndose en una práctica poco menos que intratable.
Es por eso que desde el grupo de investigación Alarcos de la Escuela Superior de Informá-
tica de Ciudad Real, César Pardo ha llevado a cabo una tesis doctoral [53] con el nombre de
A Famework to Support the Harmonization between Multiple Models and Standards,
que da soporte a la resolución de esta problemática y que describiremos a continuación,
nombrando los componentes más significativos de la misma.
3.5.1 HFramework
La tesis HFramework, llevada a cabo por César Pardo en el Grupo de Investigación Alarcos
de la Escuela Superior de Informática de Ciudad Real, trata la problemática existente en el
proceso de armonización de distintos marcos de referencia.
Según [53] “la gran diversidad y heterogeneidad de los modelos y estándares disponibles
proporcionan a las organizaciones un ambiente positivo que les permite elegir entre diferentes
soluciones para diferentes problemas y necesidades.”
No obstante, las organizaciones tienen serias dudas a la hora de elegir el modelo o los
modelos adecuados y lo que en origen parece una ventaja para éstas se puede convertir en un
hándicap.
Es por eso que dada la problemática, dentro su tesis, Pardo propone un Framework cuyo
fin es la armonización e integración de modelos de referencia heterogéneos así como distintos
modelos de calidad y seguridad.
Para desarrollar el marco que permite esta armonizazión, HFramework se divide en tres
bloques fundamentales, los cuales proveen al marco de trabajo de todo lo necesario para
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 37
realizar la armonización. Estos bloques son los siguientes:
• Conceptual Framework: Define dos ontologías donde se almacena todo el cono-
cimiento relacionado con la armonización de múltiples modelos. Es necesario para
comprender la complejidad derivada de alineación de éstos.
• Metodological Framework: Permite un control sistemático sobre las actividades, las
tareas y los roles que soportan el esfuerzo de la gestión y la configuración de la estrategia
de armonización de modelos heterogéneos. La parte de la metodología establece un
conjunto de Actividades englobadas en un conjunto de cuatro fases.
• Technological Environment: Está compuesta por una herramienta web que permite
al proyecto de armonización ser soportado, gestionado, controlado y monitorizado.
Ésta parte del proyecto corresponde al PFC de Francisco Romero [61], herramienta
antecedente de la presente, que será tratada en la siguiente sección.
A modo de pequeño resumen y para facilitar la comprensión al lector, los tres bloques
necesarios proveen a la organización el conocimiento (Conceptual Framework), la metodo-
logía (Metodological Framework) y el soporte (Technological Enviroment) necesarios para
la armonización de marcos de trabajo heterogéneos.
3.5.2 ARMONÍAS-DGS
Después de tratar el marco teórico se vio necesario implementar el entorno tecnológico que
diese soporte a la tesis. Ese framework, objeto del Proyecto de Fin de Carrera de Francisco
Romero [61], titulada ARMONÍAS-DGS, “Herramienta para la Armonización y Evaluación
de Calidad de Procesos en Desarrollo Global de Software” tiene como objetivo principal
“Elaborar una herramienta que de soporte a la armonización de marcos de calidad
de procesos y a la evaluación de los mismos, todo ello bajo el contexto del Desarrollo
Global de Software”[61].
Aunque en el presente Trabajo de Fin de Grado únicamente usaremos la base de datos
que provee de conocimiento a la herramienta, expondremos brevemente los aspectos más
importantes de la misma en la presente sección.
38 3.5. ARMONIZACIÓN
Figura 3.10: Esquema de HFramework [53].
ADMONÍAS-DGS posee dos componentes que dotan de funcionalidad a la herramienta
(además del componente de Administración, el cual no trataremos). Dichos componentes se
resumen brevemente a continuación:
• Componente de Armonización: Este componente se encarga de la gestión y análisis
gráfico de los proyectos de armonización y de crear una estrategia para ello. Ésta
será la parte de la cual se nutrirá nuestra herramienta, pues su base de datos posee el
conocimiento de los distintos modelos de referencia (armonizados o no) y de todos los
elementos que intervienen en los mismos. Esto nos servirá como punto de partida para
la elaboración de COMPROMISE.
• Componente de Evaluación: Por otro lado la herramienta ARMONÍAS-DGS provee
a las organizaciones de un componente de evaluación encargado de la configuración y
la gestión de las evaluaciones que llevarán a cabo.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 39
Figura 3.11: Esquema de ARMONÍAS-DGS. [61]
ARMONÍAS-DGS está englobada en el proyecto ORIGIN, cuyo objetivo es “desarrollar
un conjunto de herramientas conceptuales, metodológicas y sistemas que permitan optimizar
la fabricación de software en este tipo de escenarios, paliando los problemas de comunicación
y gestión de conocimiento y asegurando la calidad del software producido”.
Para satisfacer el objetivo anterior se desarrolla ARMONÍAS-DGS, cuya funcionalidad,
englobada en el componente tecnológico de HFramework, completa el framework de Pardo.
ARMONÍAS-DGS permite tanto la creación como la gestión de proyectos de armoniza-
ción. Para ello define estrategias compuestas por tres fases relacionadas: Homogeneización,
Comparación e Integración. A partir de cuestionarios ARMONÍAS-DGS es capaz de evaluar
la calidad de los procesos Software de la organización.
Por último la herramienta posee funciones de representación de los datos, mostrando
gráficas e informes de los aspectos anteriormente comentados.
Una vez que definimos los modelos de referencia se hace saber si los procesos definidos
por una organización son implementados correctamente y conforme a dichos modelos. En
siguiente sección se exponen mecanismos para determinar la correlación entre el marco de
40 3.6. CONFORMIDAD DE PROCESOS
referencia y la definición del proceso de manera cuantificable.
3.6 Conformidad de Procesos
Las organizaciones deben definir sus procesos adecuadamente para cumplir sus objetivos
de negocio. Sin embargo, en la constante batalla de éstas por ser más competitivas y lograr
un producto de calidad, las certificaciones en distintos estándares aceptados por la industria
juegan un papel fundamental en el mercado actual.
La aplicación de los estándares determinan una serie de características del proceso que
hacen que éstos no puedan ser definidos libremente por las organizaciones, sino que es de
obligado cumplimiento la satisfacción de una serie de normas y pautas para que los procesos
de la organización sean acreditados por los organismos oficiales correspondientes.
La obtención de certificaciones suponen a las organizaciones una ventaja competitiva
notable [40], pues sus productos serán sinónimo de calidad, además permitirán el desarrollo
colaborativo entre distintas organizaciones heterogéneas y podrán expandir su mercado gra-
cias a la estandarización.
Es por eso que a la hora de la certificación, las organizaciones deberán alinear sus procesos
tanto con sus objetivos de negocio como con los distintos estándares o modelos (CMMI,
ISO/IEC 12207, ISO/IEC 9000, etc.). Es aquí cuando tiene cabida el paradigma de la vis-
ta productiva del proceso, más concretamente la evaluación de conformidad de los procesos.
La conformidad tiene como fin cuantificar el grado de alineamiento de los procesos de la
organización para con los modelos de referencia. Es decir, provee mecanismos a las organiza-
ciones para ponderar sus procesos en función del cumplimiento de los estándares. De esta
manera, es sencillo para las organizaciones determinar en qué grado satisfacen sus procesos
los distintos aspectos considerados por los estándares para que la calidad del producto sea
óptima.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 41
Para que esto sea posible, es necesario establecer una correspondencia entre los distintos
elementos que conforman los procesos de las organizaciones y los que componen el marco
de referencia. Constituir esta correspondencia no es una tarea sencilla puesto que requiere el
conocimiento en profundidad de ambos procesos, tanto el definido por la organización como
el del modelo de calidad. Habitualmente esta tarea no es trivial y la deben realizar personas
con una amplia experiencia en la gestión de procesos.
El concepto de conformidad es mucho más extendido en la gestión de los procesos de
negocio, no obstante en la mayoría de la bibliografía se refieren a él como Compliance,
por su traducción en inglés. Para establecer la conformidad en los procesos de negocio es
necesario establecer un conjunto de especificaciones particulares del negocio en cuestión.
Dichas especificaciones establecen las normas de ejecución que el proceso debe seguir [41].
Es por eso que la evaluación de la conformidad de los procesos de negocio y la evaluación de
los procesos software difieren significativamente.
Los procesos software son una especialización de los procesos de negocio, por lo que
comparten características comunes. Básicamente un proceso de negocio es un conjunto de
tareas interrelacionadas y que mediante la realización de las mismas en un orden determinado
se genera un producto o un servicio.
No obstante comparar ambos procesos sin los mecanismos apropiados sería imprudente,
pues a pesar de que comparten ciertos elementos, es en la ejecución del mismo cuando se
pueden ver algunas diferencias notables.
Para lograr una certificación en los modelos aceptados por por la industria, son nece-
sarias auditorías periódicas que controlen que las directrices expuestas en los mismos son
aplicadas a la hora de que la organización mejore sus procesos. Si una organización no tiene
bien definidos sus procesos, la preparación para afrontar con éxito esa auditoría requiere un
esfuerzo adicional de todos los participantes en la organización, con el consecuente sobrecoste
para la misma. Es por eso que para reducir este umbral, usualmente traducido en labores de
consultoría, es necesario que las organizaciones definan sus procesos de una manera correcta
en un origen y tal y como los marcos de referencia exponen para cada uno de los casos.
42 3.7. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS (DSDM)
Con el fin de evitar este problema, COMPROMISE junto con las herramientas relacionadas
en el proyecto, basan su funcionalidad en una serie de objetivos a cumplir desde el inicio de
la definición de los procesos [52]:
• Dotar a todos los integrantes de la organización con el conocimiento relacionado con
los procesos y propósitos de la misma.
• Proveer un acceso fácil al conjunto de buenas prácticas establecido.
• Proveer a los stakeholders mecanismos automáticos que apoyen la promulgación de los
procesos y sus directrices.
• Proveer mecanismos para la monitorización continua del proceso.
• Automatizar las distintas vistas del proyecto ofreciendo soluciones a los distintos
stakeholders, además de proveer a los mismos de evidencias del cumplimiento del
mismo para con el modelo en cuestión.
• Dar soporte a la preparación de la evaluación y medición del rendimiento con evidencias
recogidas automáticamente.
3.7 Desarrollo de Software Dirigido por Modelos (DSDM)
La herramienta objeto de este trabajo de Fin de Grado provee mecanismos de transformación
de modelos siguiendo el paradigma de la visión productiva del proceso mediante Ingeniería
Dirigida Por Modelos.
Los procedimientos de Desarrollo Software han ido cambiando desde los inicios de la
Ingeniería del Software hasta la actualidad. En la década de los años 1990 se popularizó el
uso de la programación orientada a objetos (POO), con las consecuentes técnicas que ésta
incluía; herencia, abstracción, polimosfismo, encapsulamiento, etc. Además, el alto nivel de
abstracción proporcionado permitía al programador obviar aspectos propios de los lenguajes
de bajo nivel, que impedían un desarrollo fluido y eran propensos a errores.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 43
Aunque el paradigma anterior sigue vigente, la complejidad del software, la cantidad
ingente de tecnologías y plataformas existentes, además de la poca expresividad que pro-
porcionaba a la hora de la interpretación para algunos de los involucrados en el proyecto,
hizo necesario elevar notablemente el nivel de abstracción [71]. Es por eso que un nuevo
paradigma surge intentando evitar todas las desventajas anteriores, la Ingeniería dirigida por
modelos o MDE.
La Ingeniería Dirigida por Modelos es una metodología de desarrollo motivada en sus
inicios por el aumento de productividad, además de otros factores, que supone la utilización
de modelos que representan el conocimiento desde el punto de vista que proporciona un alto
nivel de abstracción.
Aunque son varias las definiciones, diremos que un modelo es la descripción de un siste-
ma, o una parte de él, escrita en un lenguaje bien definido [72].
Según la definición anterior de modelo es necesario especificar el lenguaje en el que éste
será expresado, ese lenguaje bien definido se conoce como metamodelo. Aunque anterior-
mente hemos proporcionado una definición genérica del mismo, a continuación se definirá de
nuevo para contextualizar el presente apartado.
Un metamodelo es un modelo que define un lenguaje para expresar los modelos. Así
para expresar los metamodelos se utilizan meta-metamodelos. La relación entre meta-
metamodelos y metamodelos es análoga a la relación entre metamodelos y modelos.
En la Figura 3.12 se presenta una relación gráfica entre los conceptos mencionados en el
párrafo anterior:
44 3.7. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS (DSDM)
Figura 3.12: Arquitectura de distintos niveles de modelado[38].
Apoyadas en estos conceptos surgen una serie de técnicas englobadas dentro del MDE
(Figura 3.13), una de ellas es el Desarrollo Dirigido por modelos, que podremos encontrar en
la bibliografía con las siglas MDD o DSDM (por sus siglas en castellano).
Figura 3.13: Organización de MDE [38]
El Desarrollo de Software Dirigido por Modelos (DSDM) es un nuevo paradigma para el
desarrollo Software englobado dentro de la Ingeniería dirigida por modelos (MDE o IDM,
por sus siglas en castellano).
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 45
Una buena implementación del paradigma DSDM puede suponer una serie de beneficios
a las organizaciones. Algunos de ellos se presentan a continuación: [38]
• Mejora de la productividad. Se pasa de la idea de “Escribir una vez y ejecutar en cual-
quier sitio” (dependiente de la plataforma) a “Modela una vez y genera en cualquier
lugar”.
• Aumenta la calidad. Los esfuerzos del desarrollo están centrados en el dominio del
problema en lugar del dominio de la solución.
• Mejor Comprensión del sistema a desarrollar. El nivel de abstracción que proporciona
el modelado permite el mejor entendimiento a los stakeholders. “Legible para los
humanos y compatible para las máquinas” [30].
• Facilita la evolución y el mantenimiento.
Como podemos ver en la figura 3.13 el MDE está compuesta por varias iniciativas en las
que se apoya. Una de ellas es la Arquitectura Dirigida por Modelos o MDA. Lanzada por
la OMG en 2001, se trata de una arquitectura que proporciona un enfoque para desarrollar
Sistemas Software basándose en una serie de guías para estructurar sus especificaciones como
modelos.
El MDA está motivados por unos principios que se exponen a continuación [38]:
• Modelos expresados en una notación bien definida.
• La construcción de sistemas puede ser organizada en torno a un conjunto de modelos
sobre los que se han definido unas transformaciones.
• La organización de la arquitectura en capas y transformaciones facilita la integración y
transformación entre modelos, que es la base para lograr la automatización mediante
herramientas.
• La aceptación de este paradigma requiere estándars implementados por la industria.
Como podemos ver en la Figura 3.14, en las transformaciones hay cuatro pasos funda-
mentales, descendientes sucesivamente en nivel de abstracción, cuyo último hito es el código
generado.
46 3.7. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS (DSDM)
Figura 3.14: Transformaciones MDA[38]
A continuación explicaremos los modelos que intervienen en el mecanismo del Framework
MDA [39]:
• CIM: Siglas de Computing Independent Model es un modelo independiente de los
detalles relacionados con la computación que se refieren a aspectos de negocio, un
ejemplo de modelo CIM es un modelo BPMN.
• PIM: Siglas de Platform Independent Model es un modelo independiente de la herra-
mienta. El paso automatizado entre los modelos CIM y PIM es un proceso complicado
pues hay un gran salto semántico entre ellos.
• PSM: Siglas de Platform Specific Model como se puede apreciar en la Figura 3.14 es el
último modelo involucrado y es dependiente de la plataforma. Finalmente se obtiene
código de aplicación mediante transformaciones M2M, acrónimo de Model-To-Text.
Además del MDA, la Ingeniería Dirigida por Modelos se apoya en una serie de herramien-
tas que proporcionan al estado de la cuestión un soporte tecnológico para tareas de modelado,
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 47
transformaciones, etc.
Ejemplos de estas herramientas son Eclipse Modeling Framework (EMF) o Graphical
Modeling Project (GMP, la cual nos permite desarrollar editores gráficos basados en EMF y
GEF.
Como hemos dicho en el inicio de este capítulo, COMPROMISE ofrece mecanismos de
transformación entre modelos. Básicamente hay dos tipos de transformaciones en MDE:
• Transformaciones Model-To-Model, que permiten transformaciones entre modelos,
forman parte de las tres primeras transformaciones en la Figura 3.14. Se pueden
destacar dos lenguajes, por un lado QVT Core Language (utilizando la parte del
lenguaje relacional en este proyecto) y por otro ATL, siglas de Atlas Transformation
Language. Una de las diferencias más notable entre ambos es que QVT sigue el estándar
de la OMG y ATL no. No obstante el segundo es mucho más utilizado que el primero y
posee más soporte.
• Transformaciones denominadas Model-to-Text, las cuales transforman los modelos a
código, este tipo de transformación es la que tiene lugar en el último paso de la Figura
3.14
Aunque las diferencias son muchas, el desarrollo a partir del modelado es un concepto
también presente en las ingenierías tradicionales antes de construir sus artefactos. Los mo-
delos sirven para especificar el sistema de una manera comprensible para los stakeholders,
establecer analogías del sistema en el caso de que exista, razonar y validar el sistema por
medio de la detección temprana de errores y prototipados y guiar la implementación.
El cambio de visión, como hemos mencionado, se basa en el entendimiento del problema
por todos los roles involucrados en el desarrollo mediante la visión del mismo con un nivel de
abstracción superior.
La sintaxis proporcionada por la definición de los metamodelos junto con el conjunto de
reglas permiten formar ficheros ECORE. Este tipo de ficheros contendrán una implementa-
ción válida del metamodelo con la que podremos trabajar en distintas herramientas que den
soporte al paradigma MDE. Podremos generar este formato a partir de una implementación
48 3.8. HERRAMIENTAS RELACIONADAS
del metamodelo o mediante la transformación de ficheros que lo contengan (XSD es un
ejemplo) utilizando para ello frameworks específicos, en nuestro caso EMF [8].
Por último, una vez obtenidos los metamodelos sobre los que realizar la transformación
(origen y destino), utilizando frameworks de transformación (Medini QVT en nuestro caso)
podremos realizar transformaciones entre modelos definiendo su correspondencia entre los
distintos elementos de ambos. Dicho proceso se encuentra ilustrado en la Figura 3.15
Figura 3.15: Arquitectura Conceptual de Transformaciones[38]
3.8 Herramientas relacionadas
Actualmente en el mercado existen algunas herramientas que dan soporte a la gestión de la
conformidad de los procesos. Aunque la mayoría pertenecen al ámbito de los procesos de
negocio, hay algunas que si dan soporte a la gestión de conformidad de procesos software
tanto con marcos de referencia de procesos como con otros de carácter legislativo.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN 49
A continuación se presentan algunas de las más importantes junto con una breve descrip-
ción de las mismas:
• SAI GLOBAL COMPLIANCE 360º SUITE: Se trata de un conjunto de herramientas
y aplicaciones que permiten a las organizaciones controlar tanto aspectos de conformi-
dad como de gestión de riesgos, aspectos financieros, etc.
• Sepia Solutions ofrece la suite PAWS, siglas de Audit & Risk Management Software.
Permite definir Planes de auditoría, ofrece gestión de riesgos, así como una serie de
recomendaciones y acciones para afrontarlas con ésito. Da soporte a los procesos y a la
metodología utilizada a las organizaciones en sus actividades diarias. Es utilizada por
una gran variedad de industrias, destacando entre ellas bancos, gobiernos, empresas del
sector energético, etc.
Principalmente estas herramientas se centran en la gestión de los distintos cumplimientos
legales que una organización ha de realizar.
Una de las principales razones del desarrollo de COMPROMISE es la incapacidad de las
herramientas existentes en el mercado para definir marcos de trabajo aplicados al desarrollo
Software. Un ejemplo son los modelos armonizados que permite definir la herramienta
ARMONÍAS-DGS para los cuales realizamos análisis de conformidad.
Capítulo 4
Método de Trabajo
El presente capítulo está compuesto por dos secciones. La primera presenta el método
de trabajo que se ha seguido para el desarrollo de la herramienta del presente TFG. La
metodología utilizada en nuestro desarrollo será OpenUP, idónea para desarrollos con un
equipo de trabajo pequeño y que se basa en un modelo iterativo e incremental.
La segunda sección corresponde al entorno tecnológico, describiendo las herramientas
utilizadas para el modelado y el desarrollo, las empleadas para la documentación y los
lenguajes y librerías utilizados en la implementación.
4.1 OpenUP
OpenUP es una metodología utilizada para el desarrollo software propuesta por un conjunto
de empresas y posteriormente donada a la Eclipse Software Fundation, quienes la publicaron
bajo licencia Pública de Eclipse [35].
Está diseñada para pequeños grupos de personas autorganizados, tomando una aproxima-
ción de desarrollo Ágil. Además, esta metodología está basada en un desarrollo iterativo e
incremental, pudiendo realizar pequeños microincrementos dentro de las distintas iteraciones
del proyecto dotando al proceso de desarrollo de una granularidad muy alta, lo cual se adapta
perfectamente al tipo de desarrollo que pretendemos abordar.
La organización en la que OpenUP se basa recoge cuatro principios fundamentales
soportados entre sí:
• Colaboración: Se deben desarrollar prácticas colaborativas para alinear los intereses,
facilitar la comunicación y difundir el conocimiento sobre el proyecto y generar un
entorno de trabajo saludable.
52 4.1. OPENUP
• Balance: Lograr el equilibrio entre las necesidades y costos técnicos del proyecto y la
maximización del valor para los stakeholders.
• Enfoque: Hace especial hincapié en facilitar la colaboración técnica para así reducir
los riesgos y el coste en la medida de lo posible.
• Evolución: Una continua evolución del proyecto basada en entrega de funcionalidades
tempranas reduce los errores y obtiene un feedback del cliente.
Siguiendo el paradigma de EPFC, OpenUP se organiza en dos dimensiones. Por un lado
se encuentra el contenido metodológico, que es el que define los elementos como disciplinas,
roles, tareas, artefactos y procesos para su posterior reutilización. Esta dimensión no se ocupa
de la combinación de los mismos o de su uso.
Por otro lado, el contenido procedimental, donde tendrá lugar la aplicación de los elemen-
tos anteriormente mencionados a la hora de elaborar los procesos de la organización.
Los elementos que forman el contenido metodológico se enuncian a continuación [60]:
• Disciplinas: Se centra en los requisitos, arquitecturas, desarrollo, pruebas, gestión de
proyecto, gestión de la configuración y del cambio.
• Tareas: Se define tarea como la unidad de trabajo que debe ser realizada por algún rol.
• Artefactos: Un artefacto se considera a todo aquello que una tarea necesita para
realizar su función, o bien la produce o modifica.
• Procesos: Los procesos toman los elementos metodológicos y definen las relaciones
entre ellos.
4.1.1 Ciclo de Vida
Según la metodología de OpenUP, el ciclo de vida permitirá a los integrantes del equipo de
desarrollo ir completando el proyecto con pequeños incrementos, esfuerzos comprendidos
entre horas y días, que irán dotando al proyecto de funcionalidad adicional.
La idea subyacente de OpenUP es que a partir de las iteraciones, el proyecto vaya incre-
mentando valor y que éste se vea reflejado en los entregables a los clientes, ya que cada vez
CAPÍTULO 4. MÉTODO DE TRABAJO 53
que una iteración termina el cliente debería obtener software operativo y funcional. Este tipo
de desarrollo incremental, centrado en añadir valor al producto en cada iteración permite
controlar aspectos como el riesgo, la financiación o el cumplimiento de expectativas de una
forma continuada.
El ciclo de vida de OpenUP comprende cuatro fases: inicio, elaboración, construcción y
transición.
Figura 4.1: Ciclo de vida de OpenUP [35]
A continuación se proporciona la descripción de cada una de las fases [70]:
• Inicio: Una vez terminada esta fase se deberán haber completado cuatro objetivos
principales. Primero se entenderá qué queremos construir determinando la visión
general del proyecto, el alcance del mismo, sus límites y una identificación de los
interesados en el proyecto y por qué, con el objetivo de satisfacer las necesidades
entendiendo los requisitos para cumplir las expectativas del cliente cuanto antes.
• Elaboración: Se realiza el análisis del problema y se define la arquitectura del sistema.
Se debe elaborar un plan de proyecto, plasmando los requisitos y determinando una
arquitectura estable acorde con las necesidades. Además se especifican las herramientas,
la infraestructura a utilizar y el entorno de desarrollo. Al final de esta fase se tendrá la
definición de los casos de uso, los actores, la arquitectura del sistema y un prototipo
ejecutable de la herramienta.
• Construcción: En esta fase se realizarán e implementarán todos los componentes
que falten por completar, serán probados e integrados. Los incrementos deben ser
desarrollados de la forma más rápida sin repercutir en la calidad del producto.
54 4.1. OPENUP
• Transición: Se enfoca el producto software a la plataforma tecnológica del cliente
logrando que los interesados convengan que el desarrollo del producto cumple con los
requisitos planteados. El propósito de esta fase es asegurar que el producto de software
está listo para ser distribuido a los usuarios.
4.1.2 Roles de OpenUP
En la elaboración del Software el factor humano es determinante. Las personas que intervienen
cuentan unas habilidades e intereses distintos, es por eso que dependiendo de la tarea a
realizar puede ocurrir que una persona tenga más aptitudes que otra para llevarla a cabo
satisfactoriamente. Debido a la naturaleza del presente trabajo, los roles serán ostentados por
dos personas:
4.1.2.0.1 Analista Este rol representa la parte del cliente y de los usuarios finales, obte-
niendo los requisitos de los stakeholders y encargado de ajustar prioridades.
Figura 4.2: Relaciones del Rol Analista en OpenUP[35]
4.1.2.0.2 Cualquier Rol Se trata de un rol que lleva a cabo tareas sin carga técnica, en
términos generales se puede decír que es un “peón”.
Figura 4.3: Relaciones del Rol Comodín en OpenUP[35]
CAPÍTULO 4. MÉTODO DE TRABAJO 55
4.1.2.0.3 Arquitecto Este rol es el encargado de diseñar la arquitectura que soportará la
herramienta. Entre sus funciones están la toma de decsiones técnicas sobre el diseño y la
implementación del proyecto. Normalmente se ocupa de identificar y documentar los aspectos
arquitecturales del sistema.
Este rol es un pilar fundamental de un proyecto, y además está estrechamente relacionado
con el rol de Director de Proyecto.
Figura 4.4: Relaciones del Rol Arquitecto en OpenUP[35]
4.1.2.0.4 Desarrollador Este rol tendrá un perfil técnico y a grandes rasgos se ocupará
de las siguientes tareas:
• Ofrecer soluciones técnicas en la parte de desarrollo.
• Aceptación de la arquitectura y desarrollo del proyecto según los paradigmas de la
misma.
• Identificar y construir los casos de prueba necesarios.
• Comunicar las decisiones de modo que otros miembros del grupo las entiendan.
56 4.1. OPENUP
Figura 4.5: Relaciones del Rol Desarrollador en OpenUP[35]
4.1.2.0.5 Project Manager Lidera el planteamiento del proyecto. Además será un nexo
entre el equipo de desarrollo y los clientes. Este rol debe tener conocimientos de gestión,
herramientas, técnicas de negociación, etc. Es responsable directo del resultado del proyecto y
se ocupará de la evaluación de los riesgos del proyecto y de proponer planes de contingencia
para contenerlos en el caso de que ocurran.
Figura 4.6: Relaciones del Rol Project Manager en OpenUP[35]
Aunque no es requisito fundamental, este rol es frecuentemente asumido por una única
persona.
4.1.2.0.6 Stakeholder Representan grupos de interés relacionados con el proyecto. El
único requisito de este rol es estar relacionado (en un presente o en un futuro) con el resultado
del proyecto.
Figura 4.7: Relaciones del Rol Stakeholder en OpenUP[57]
CAPÍTULO 4. MÉTODO DE TRABAJO 57
4.1.2.0.7 Tester Es el rol responsable de las actividades de pruebas. Debe identificar,
definir, implementar y dirigir los casos de pruebas.
Figura 4.8: Relaciones del Rol Tester en OpenUP[57]
A pesar de que la metodología defina los roles anteriormente mencionados con el fin de
repartir el esfuerzo entre el personal involucrado en el proyecto, dado el carácter de este TFG
no es posible, pues el autor asumirá todos los roles anteriormente mencionados (exceptuando
el de Project Manager que lo asumirá el director del TFG), por lo que guiar el método de
trabajo a partir de los mismos no sería correcto.
Es por eso que el proceso de desarrollo se guiará a través de las distintas iteraciones
definidas en la fase de inicio de la metodología [60]. En la siguiente iteración veremos en qué
consisten las distintas etapas llevadas a cabo en las distintas iteraciones.
4.1.3 Proceso Iterativo e Incremental
A continuación se presenta un esquema de ejemplo de los subprocesos llevados a cabo en el
desarrollo, así como el esfuerzo repartido por las distintas iteraciones y fases del desarrollo.
En estos subprocesos intervienen un conjunto de actividades, roles, prácticas y artefactos que
guían el proceso de desarrollo a través de las cuatro fases descritas en el apartado 4.1.1.
58 4.1. OPENUP
Figura 4.9: Ciclo de Vida de OpenUP[57]
Como podemos observar en el gráfico de la Figura 4.9, las diferentes iteraciones se dis-
tribuyen a través de las cuatro fases y cada fase puede tener tantas iteraciones como ésta
necesite, normalmente vendrá determinado por la complejidad, el conocimiento del dominio
y la tecnología, etc. En nuestro caso las iteraciones serán definidas en base a los casos de uso
de la herramienta, es decir, teniendo en cuenta su funcionalidad.
La duración de las iteraciones pueden depender de muchos factores. No obstante al
finalizar cada iteración se tienen que generar una serie de informes que:
• Indiquen el incremento funcional realizado.
• Sirvan de conocimiento al resto de los involucrados en el proyecto.
• Minimicen los riesgos y problemas debido a la pronta aparición de los mismos y
consecuentemente a la rápida mitigación de estos.
En nuestro desarrollo, estos informes estarán recogidos en las distintas iteraciones que
están presentes en el Capítulo de Resultados.
CAPÍTULO 4. MÉTODO DE TRABAJO 59
4.1.4 Flujos Fundamentales de Trabajo Obtenidos para el desarrollo
de COMPROMISE.
En este apartado se exponen a modo de resumen los distintos flujos de trabajo que podemos
encontrar en las distintas iteraciones presentes en el ciclo de vida propuesto para la elaboración
de COMPROMISE.
4.1.4.1 Captura de Requisitos
Este flujo fundamental de trabajo tiene como objetivo establecer todos los aspectos que
el cliente desea tener presentes en el sistema desarrollado. El contexto del problema será
comprendido por el analista y posteriormente se catalogarán dependiendo de la prioridad
de los mismos, separando a su vez la naturaleza de los mismos en funcionales y no funcionales.
Cabe destacar que estos requisitos no son estáticos y pueden ser cambiados a medida que
el desarrollo va avanzando, en nuestro caso no ha sido una excepción y se han añadido algunos
que en un origen no habían sido contemplados. Esto es debido a que, durante el tiempo de
desarrollo, los objetivos de negocio del cliente están abiertos a cambios. Un buen desarrollo
ha de ser flexible e integrar estos nuevos objetivos de forma dinámica con el mínimo coste de
desarrollo posible.
4.1.4.2 Análisis y diseño
En la etapa de análisis tendrá lugar el entendimiento y comprensión del problema a resolver.
Se analizará el entorno sobre el que el problema es definido y se obtendrá la información
necesaria a partir de los requisitos para lograr una solución satisfactoria.
Una vez recogida la información en la etapa de análisis, se determinará la estrategia a
seguir para dar una buena solución al problema. En esta etapa se generan artefactos en forma
de diagramas, los cuales pueden proveer a todos los stakeholders de una idea generalizada de
la solución del mismo y modificarlo si es necesario. Una vez validado el diseño tendrá lugar
la etapa de implementación, expuesta a continuación.
60 4.2. ENTORNO TECNOLÓGICO
4.1.4.3 Implementación
Partiendo de la solución proporcionada por las etapas anteriores, en esta etapa se desarrollará
el software que de solución al problema. Es en la fase de construcción cuando esta etapa cobra
mayor importancia aunque en la fase anterior podemos haber construido algunas pruebas de
concepto que han sido necesarias para comprender la tecnología.
Al finalizar esta etapa obtendremos como artefacto el código de la iteración correspon-
diente.
4.1.4.4 Etapa de Pruebas
En esta etapa se verifica la funcionalidad de la herramienta, primero con pruebas unitarias y
posteriormente con pruebas de integración.
Para la elaboración de los mismos se tendrán en cuenta valores extremos del dominio y la
utilización de valores propensos a error.
Es de vital importancia la correcta elaboración de esta etapa, pues salvo labores de
mantenimiento, será la última antes de que el producto final esté listo para la entrega al
usuario final. Únicamente después de haber concluido esta etapa se considerará válida la
funcionalidad de la iteración salvo cambios por parte del cliente.
4.2 Entorno Tecnológico
A continuación se mencionarán las herramientas utilizadas para el desarrollo de COMPRO-
MISE, la documentación así como las librerías, lenguajes y tecnologías utilizadas.
4.2.1 Herramientas de modelado y desarrollo y tecnologías utilizadas
En esta sección se presentarán las herramientas utilizadas para el desarrollo y modelado de la
herramienta objeto del presente TFG.
CAPÍTULO 4. MÉTODO DE TRABAJO 61
4.2.1.1 EPFC
Tal y como se ha mencionado en los capítulos anteriores, el presente TFG genera modelos
compatibles con EPFC a partir de la base de datos de ARMONÍAS. EPFC [9] (Eclipse Process
Framework Composer) es una herramienta desarrollada dentro del entorno Eclipse y que como
lenguaje de modelado utiliza UMA (siglas de Unified Method Architecture), a su vez basado
en el metamodelo SPEM 2.0. Es un editor de procesos SPEM 2 que incluye metodologías
importables y que con ella las organizaciones pueden diseñar sus procesos de una manera
fácil y dinámica, favoreciendo el conocimiento con mecanismos de compartición tales como
la publicación Web de un proceso.
Figura 4.10: Pantalla Principal Herramienta EPFC
62 4.2. ENTORNO TECNOLÓGICO
Como referencia esencial para el aprendizaje de la herramienta se ha seguido el manual
elaborado por Francisco Ruiz y Javier Verdugo del Grupo Alarcos [63].
4.2.1.2 Struts2
Struts2 [20] es un framework de código abierto de la Apache Software Foundation que permite
el desarrollo de aplicaciones web mediante el patrón MVC (Modelo-Vista-Controlador o
Model-View-Controller). Struts2 provee al desarrollador de mecanismos para que la imple-
mentación de las aplicaciones sean más sencillas, rápidas y robustas. Además soluciona el
problema de la persistencia mediante una buena integración con Hibernate, el cual será tratado
más adelante en esta sección.
Básicamente Struts2 procesa las peticiones por parte del cliente utilizando tres elementos:
• Interceptores: Son clases que siguen el patrón interceptor y están estrechamente
relacionadas con las acciones, ejecutándose antes y después de éstas. Se pueden utilizar
para muchas labores, tales como el login de usuarios de la aplicación, manejar sesiones
HTTP, etc.
• Acciones: Son las clases encargadas de la lógica de la aplicación, cada URL es mapeada
a una acción concreta que provee a la herramienta de la lógica necesaria para cumplir
un objetivo concreto. Estos únicamente devuelven una cadena de caracteres (String)
denominado Result, que determinará el resultado que el cliente visualizará.
• Resultados: Indica cómo debe ser tratado el resultado que se entregará al cliente. Un
action puede tener más de un result asociado. De esta manera la ejecución puede tomar
varias direcciones dependiendo del cómputo realizado por los Actions.
A continuación, en la Figura 4.11, se ofrece el flujo natural de una petición atendida por
el famework.
4.2.1.3 Eclipse
Eclipse [7] es un entorno de trabajo Integrado o IDE (Integrated Development Environment)
de código abierto que dota al desarrollador de los mecanismos necesarios para implementar
un sistema software. Es además extensible mediante plugins y facilita editores para otro tipo
CAPÍTULO 4. MÉTODO DE TRABAJO 63
Figura 4.11: Atención de una Petición Struts2[10]
de lenguajes como JSP, HTML, XML, CSS, etc.
Un ejemplo de plugin utilizado en nuestro desarrollo es JAXB (Sección 4.2.4.9), el
cual permite crear clases de manera automática a partir de su esquema XSD y facilita
al desarrollador de una API (Application Programming Interface) que da soporte a las
operaciones de Marshalling y Unmarshalling de documentos XML.
4.2.1.4 Apache Tomcat
Apache Tomcat es un servidor que nos permite alojar servlets y JavaServer Pages (JSP). Se
utilizará para desplegar nuestra herramienta Web, además presenta una buena integración con
el IDE Eclipse.
Esta herramienta ha sido utilizada en su versión Apache-Tomcat-7.0.52. A partir de la
versión 7 de Apache, la herramienta incorpora [1]:
• Implementaciones de Servlet 3.0, JSP 2.2 y EL 2.2.
• Mejoras para detectar y prevenir “fugas de memoria” en las aplicaciones Web.
• Limpieza interna de código.
• Soporte para la inclusión de contenidos externos directamente en una aplicación Web.
64 4.2. ENTORNO TECNOLÓGICO
4.2.1.5 MySQLWorkbench
Se trata de una herramienta que da soporte a todas las fases propias del desarrollo de una base
de datos, facilitando al desarrollador una interfaz amigable e intuitiva [17].
Esta herramienta permitirá desarrollar código SQL a partir de un diagrama E/R (Entidad/-
Relación) generado, presente en la Figura 4.12, que ejecutaremos en la propia herramienta.
La versión utilizada en la elaboración de nuestro TFG es MySQL Workbench 6.0
Figura 4.12: Ejemplo Aplicación MySQLWorkbench[10]
4.2.1.6 Visual Paradigm
Es una herramienta CASE que permite el diseño y modelado de diagramas UML que soportan
el desarrollo de nuestra herramienta. Destaca su potencia, pues prácticamente todos los
diagramas necesarios para desarrollar un proyecto es posible realizarlos con esta herramienta.
Además posee herramientas de generación de código automático y recogida de requisitos a
partir de documentos previamente configurados.
Para el desarrollo de la herramienta se ha utilizado la versión Visual Paradigm for UML
11.0 [22].
CAPÍTULO 4. MÉTODO DE TRABAJO 65
4.2.1.7 JUnit
JUnit es un Plug-in de Eclipse que permite a los desarrolladores realizar labores de Testing de
las distintas funcionalidades de un Software.
Se implementa bajo una serie de librerías disponibles en la página de descarga del
Framework. Su integración con el IDE Eclipse facilita las labores de testing, ofreciendo
también funciones de Profiling.
4.2.1.8 BPMN Modeler
BPMN Modeler [4] es una herramienta gráfica que permite definir procesos de negocio acor-
des al metamodelo BPMN (Business Process Modeling Notation). Se trata de una herramienta
perteneciente a la Eclipse Foundation y desarrollada bajo el proyecto de Model Development
Tools (MDT).
Su metamodelo es compatible con la especificación de BPMN 2.0 propuesto por la OMG,
no obstante su especificación no es idéntica y han sido necesarias labores transformación para
la representación de modelos BPMN 2.0 de manera gráfica.
Figura 4.13: Pantalla principal de la Herramienta BPMN Modeler
66 4.2. ENTORNO TECNOLÓGICO
4.2.1.9 Bootstrap
Bootstrap es un framework desarrollado por la compañía Twitter y liberado bajo licencia
Apache Basado en CSS3 y HTML5 para crear diseños de interfaces Web de una manera
eficaz e intuitiva. Sus principales características son que sus funciones están soportadas por la
mayoría de los navegadores Web actuales y su particular diseño con rejillas (grid) permiten
el uso de aplicaciones web prácticamente en la totalidad de dispositivos haciendo que la
visualización sea independiente de la resolución del dispositivo utilizado.
4.2.1.10 GIT
Es un software de control de versiones que ayuda en el desarrollo y la gestión de aplicaciones
complejas. Aunque en el presente desarrollo se ha utilizado únicamente por una persona
permite gestionar aplicaciones teniendo en cuenta las necesidades de grupos de trabajo
numerosos. Además ofrece mecanismos para la gestión de repositorios remotos, desacoplando
el desarrollo de un puesto de trabajo convencional.
CAPÍTULO 4. MÉTODO DE TRABAJO 67
4.2.2 Entorno tecnológico MDA
A continuación se presentan un conjunto de herramientas relacionadas con el paradigma
MDA. Estas herramientas han sido utilizadas para realizar el componente de transformación
de la herramienta objeto del TFG.
4.2.2.1 EMF
Se trata de una herramienta de modelado de la fundación Eclipse cuyo acrónimo viene
determinado por las siglas en inglés de Eclipse Modeling Framework [8] . Permite manipular
y generar modelos software para posteriormente construir herramientas basadas en modelos
de datos estructurados. Son muchas sus funcionalidades; producir código java a partir del
modelado, da soporte a la especificación de modelos mediante anotaciones java, documentos
XML, etc. En nuestro desarrollo lo utilizaremos para representar los metamodelos .ecore y
generarlos a partir de esquemas XML.
Figura 4.14: Pantalla principal Eclipse Modelling Framework (EMF)
4.2.2.2 Medini-QVT
Es un framework implementado por la OMG (Object Management Group) que permite la
transformación model-to-model [16]. Dado que sigue el estándar de la OMG será el utilizado
68 4.2. ENTORNO TECNOLÓGICO
junto con su lenguaje de transformaciones QVT Relations, encargado de implementar los
detalles de la transformación.
Figura 4.15: Vista de ejemplo de la aplicación Medini QVT[10]
4.2.3 Documentación
4.2.3.1 LATEX
LATEXes un sistema que facilita la documentación, especialmente diseñado para la producción
de textos técnicos y científicos. Ha supuesto un estándar de facto para la comunicación y la
publicación de este tipo de documentos, en parte por su rápida curva de aprendizaje y por su
carácter gratuito.
Para la elaboración del presente documento se utilizará el compliador MikTex en su
versión 2.9.
4.2.3.2 Texmaker
Es un editor para documentos LATEX, que provee al usuario de mecanismos de visualización
de la estructura, inserción de elementos, tales como figuras o tablas, y la definición de snippets
para la introducción repetitiva de código en listas, enumeraciones etc.
Además facilita la compilación del texto y la bibliografía de una manera cómoda para el
programador, así como la visualización de documentos finales en formatos PDF, PS o DVI.
CAPÍTULO 4. MÉTODO DE TRABAJO 69
Figura 4.16: Ejemplo de la herramienta TexMaker[10]
4.2.3.3 BIBTEX
Es una herramienta de LATEXutilizada para dar formato a listas de referencias, destaca por su
completitud y su facilidad de uso junto a LATEX.
En la elaboración de la bibliografía del presente documento ha sido utilizada la herramienta
BIBTEX.
4.2.3.4 GIMP
Se trata de una herramienta de edición de imágenes, posee un gran número de funcionalidades
y por ser una herramienta de Software Libre. Además tiene la posibilidad de ser ampliada
mediante Plug-ins, lo cual la dota de una alta capacidad de personalización.
La versión de la herramienta utilizada en el presente TFG es GIMP 2.8.10
4.2.3.5 Dia
Dia es una herramienta utilizada para construir diagramas y se desarrolla como parte del
proyecto GNOME. Se puede utilizar para dibujar diferentes tipos de diagramas tales como
UML, esquema Entidad/Relación, esquemas eléctricos, etc.
70 4.2. ENTORNO TECNOLÓGICO
Una de las ventajas más importantes radica en la exportación de sus archivos como
imágenes vectoriales, lo cual nos permite redimensionar la misma sin que la calidad se vea
afectada. Además Dia es capaz de exportar a muchos más formatos, como pueden ser EPS,
PNG, PDF, etc.
4.2.4 Lenguajes y Librerías utilizadas
4.2.4.1 UML
UML 2.0, siglas de Unified Modeling Language es un lenguaje de modelado propuesto por la
OMG. Ofrece un alto nivel de abstracción a la hora de construir la herramienta que permite
al diseñador centrarse en la complejidad del problema, ofreciando varios tipos de diagramas
útiles durante el proceso de desarrollo del proyecto, tales como los diagramas de análisis, los
diagramas de diseño o los de despliegue [21].
4.2.4.2 Java
Java es el lenguaje utilizado para desarrollar la herramienta COMPROMISE. Se trata de un
lenguaje de alto nivel y portable a la mayoría de las herramientas actuales del mercado, de ahí
su gran aceptación. Se ejecuta sobre una máquina virtual denominada JRE, siglas de Java
Runtime Environment [13].
4.2.4.3 QVT Relations
Se trata de un lenguaje declarativo utilizado para escribir transformaciones entre modelos,
tanto unidireccionales como bidireccionales [19].
4.2.4.4 JavaScript
Es un lenguaje interpretado, ejecutado normalmente en el lado del cliente y que dota a la
página de dinamismo y le confiere gran cantidad de mejoras en el aspecto de la misma.
Además puede operar con algunos elementos y ejecutar algunas funciones, como por ejemplo
restricciones.
CAPÍTULO 4. MÉTODO DE TRABAJO 71
4.2.4.5 HTML
Siglas de HyperText Markup Language, es un lenguaje utilizado en la generación de páginas
web en el lado del cliente. Se trata de un estándar de la W3C (World Wide Web Consortium).
Basa su funcionalidad en el uso de etiquetas para definir las distintas partes que componen la
página.
4.2.4.6 JSP
Es una tecnología que permite la construcción de páginas web dinámicas basadas en el
lenguaje HTML. Para su despliegue es necesario un servidor compatible, en nuestro caso
Apache Tomcat. Lo que hace particular a esta tecnología es la utilización del lenguaje java,
pudiendo hacer uso del mismo dentro del archivo .jsp mediante la definición de etiquetas.
4.2.4.7 IText
IText proporciona al desarrollador mecanismos de tratamiento para ficheros con formato PDF.
En el presente Trabajo de fin de Grado la utilizaremos para generar informes de Compliance
para las organizaciones.
4.2.4.8 Hibernate
Hibernate es una tecnología ORM (Object-Relational Mapping o en español “Mapeo Objeto-
Relacional”) que facilita a los desarrolladores la construcción de aplicaciones en las que los
datos son externos a las mismas y se hace necesaria una persistencia de los mismos [11].
Mediante la definición de la estructura mediante documentos XML o mediante anotaciones
en el código, es posible introducir directamente los objetos en la misma sin preocuparnos
de extraer sus valores. Además es independiente de la base de datos que usemos, lo que
reduce la acoplabilidad del sistema definiendo el driver junto con los datos necesarios para la
conexión en un fichero XML. Si surge la necesidad de cambiar la tecnología de la persistencia
únicamente se modificará ese fichero.
72 4.2. ENTORNO TECNOLÓGICO
4.2.4.9 JAXB
JAXB [18] es un plug-in que dota al IDE Eclipse de capacidades de gestión de documentos
XML. Con este plugin es posible generar las clases de dominio de un sistema a partir de la
especificación de su esquema, componer o leer de ficheros XML a partir de las clases de
dominio de un sistema, etc.
El plugin proporciona una API, con dos funcionalidades principales, Marshalling y
UnMarshalling, términos utilizados en el documento y que procederemos a su explicación:
• Marshalling: Esta función es la encargada de la composición del archivo XML con
los datos de las clases de dominio que queramos incluir en el mismo. Para establecer la
jerarquía de árbol, que unos elementos contengan a otros y que a la hora de la inclusión
mediante la función arrastre todos los elementos relacionados, es necesario realizar
anotaciones en las clases de dominio que deseemos que formen parte del documento.
• UnMarshalling: Dada la funcionalidad anterior, el UnMarshalling es totalmente lo
opuesto. A partir de un fichero XML permite seleccionar los elementos que queramos
permitiéndonos el acceso de los datos de éste y de los relacionados con él.
4.2.4.10 XML
XML es un lenguaje de marcas desarrollado por la W3C utilizado para almacenar datos y que
permite definir la gramática de lenguajes específicos. Es muy útil cuando, como es nuestro
caso, varias aplicaciones necesitan comunicarse intercambiando datos.
Las ventajas radican en que es un lenguaje extensible, pudiendo añadir las etiquetas que
consideremos necearias en cada momento. Además cabe la posibilidad de validarlo mediante
su esquema, el cual contiene la definición bajo la que se debe implementar el documento,
siendo así idóneo para el intercambio entre herramientas.
4.2.4.11 MySQL
Es un Sistema de Gestión de Base de Datos (SGBD) multihilo y multiusuario. Se desarrolla
como un sistema de software libre con doble licencia. Por un lado se ofrece bajo licencia
CAPÍTULO 4. MÉTODO DE TRABAJO 73
GPL para usuarios normales, para aquellas empresas que quieran incorporarlo en productos
privativos deberán comprar la licencia correspondiente que autorice su uso.
Capítulo 5
Resultados: Herramienta
COMPROMISE
En este capítulo se presentan los resultados obtenidos durante el desarrollo de la herramienta
COMPROMISE, guiada por la metodología de desarrollo presentada en el Capítulo 4.
El desarrollo se ha establecido bajo un único ciclo dividido en las cuatro etapas propias de
la metodología, Fase de Inicio, Fase de Elaboración, Fase de Construcción, Fase de Transición.
No obstante esta última fase no tendrá cabida en el presente desarrollo, pues es la fase de
entrega al cliente, la cual no forma parte del alcance del presente TFG. Además cada una
las etapas estarán divididas en iteraciones, con sus respectivos incrementos expresados en
las mismas, elaboradas en la fase de Inicio. Con el fin de facilitar el seguimiento del pro-
yecto y encuadrar los artefactos siguiendo el desarrollo natural del mismo, se presentarán
los artefactos más importantes, si el lector quisiera profundizar en algún aspecto concreto se
le mostrará el resto de detalles en los apéndices oportunos o en la bibliografía correspondiente.
La herramienta consta de dos bloques de funcionalidad. Por un lado, el componente de
análisis de conformidad de los procesos definidos en EPF Composer para con un modelo de
referencia concreto y por otro el bloque de transformación de un proceso software representa-
do como proceso de negocio.
Finalmente se incluye un módulo de Administración de la herramienta que permitirá
al administrador de la misma soluciones como la inclusión de Usuarios, Organizaciones y
activos pertenecientes a la misma.
76 5.1. FASE DE INICIO
5.1 Fase de Inicio
En la primera fase se han llevado a cabo un número considerable de tareas, tales como las
reuniones con el director de proyecto para comprender la dimensión de la solución requerida
para solventar el problema, preparación bibliográfica que nos permita tener una visión global
del proyecto, elaboración de un plan general del mismo en cuanto a funcionalidades se refiere,
captura de requisitos que la herramienta debe cumplir para satisfacer los objetivos propuestos,
el plan de iteraciones junto con los incrementos que las completarán, la elaboración de diagra-
mas de casos de uso que el sistema debe implementar, además de determinar la arquitectura
del sistema a construir.
En la siguiente tabla se presentan los roles que interactúan con la herramienta:
Funcionalidad Rol Bloque
Gestor de Usuarios Administrador de la Herramienta Administración
Gestión de Compañías Administrador de la Herramienta Administración
Gestión de herramientas, roles, Activos Administrador de la Organización Administración
Gestión de Conformidad de una Organización TodosAnálisis
Conformidad
Gestión de Procesos de la Organización TodosAnálisis
Conformidad
Gestión de Resultados TodosAnálisis
Conformidad
Gestión de Transformaciones Todos Transformación
Tabla 5.1: Roles de la herramienta con sus funcionalidades y componente al que pertenecen.
5.1.1 Requisitos
Como hemos mencionado, la captura de requisitos dio lugar a los tres roles mencionados en
la parte anterior:
• Gestor de Procesos
• Administrador de la Organización
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE 77
• Administrador de la Herramienta.
Además se propuso un mecanismo para medir la Conformidad del proceso respecto de
un marco de referencia. Se determinó que la mejor estrategia sería comprobar si la tarea
implementada en el proceso de la organización está o no en el modelo de referencia, constitu-
yendo así un “sistema bivalente” menos propenso a errores de algoritmia, dejando la parte de
constitución de un algoritmo en la sección de trabajo futuro del presente documento. (Sección
6.1.1)
Posteriormente, en sucesivas reuniones se planteó el requisito de que la herramienta posea
mecanismos de visualización del proceso software en un motor de procesos de negocio con su
consecuente transformación y tratar dicho proceso software como si de un proceso de negocio
se tratase, pues el primero es una especialización del segundo. Así surgió la necesidad de una
transformación entre modelos.
5.1.2 Dominio de la Herramienta
A continuación se explicarán algunos términos del dominio sobre el cual tiene cabida el siste-
ma desarrollado, las razones de las decisiones tomadas, así como una relación de conceptos
que serán útiles al lector para comprender el alcance de la herramienta.
Dependiendo del tipo de relación con COMPROMISE hay varios roles que pueden
interactuar con la misma. Básicamente se distinguen tres tipos:
• Gestor de Procesos: Normalmente este rol lo obstentará el ingeniero de procesos y
tendrá la posibilidad de controlar los procesos, evaluarlos, inspeccionarlos, además
de ejecutar transformaciones para la visualización en otras herramientas y medir el
compromiso de los mismos con los estándares. No obstante no podrá gestionar los
activos de la empresa.
• Administrador de la organización: Es el encargado de gestionar todos los activos de
la empresa, teniendo capacidad de modificación, creación, actualización y eliminación
de los mismos.
78 5.1. FASE DE INICIO
• Administrador de la herramienta: Será el encargado de la Gestión de los Usuarios
de la herramienta. Sus funcionalidades se expresan en el modelo de casos de Uso de la
fase de inicio.(Sección 5.2).
Además, debido a la complejidad del dominio con el que trabajamos, se creyó conveniente
que en la Fase de Inicio se debe elaborar una visión global del proyecto, así como las relacio-
nes entre las herramientas. Esta relación se podrá observar de manera gráfica en el diagrama
general de la herramienta, presente en la Figura 5.1
La aplicación se nutrirá de la herramienta ARMONÍAS-DGS, concretamente de la Base de
Datos que almacena los procesos convirtiéndolos al metamodelo UMA. Dicho conocimiento
será recogido por la herramienta EPF Composer, poblando su contenido de método para que
después a partir de la reutilización de los elementos cargados formar su proceso.
Una vez modelado el/los procesos con EPFC, a partir del contenido de método cargado
con anterioridad, se deberá cargar el archivo que contiene los procesos en COMPROMISE,
guardará todos sus elementos en su base de datos para su reutilización a la hora de elaborar
informes o gráficos y por último dará soporte al análisis de la conformidad respecto de los
modelos de referencia de la herramienta ARMONÍAS-DGS. Además tendrá un componente
de transformación que nos permitirá representar el proceso software como un proceso de
negocio acorde al metamodelo BPMN 2.0 y visualizar dicho proceso en la herramienta BPMN
Modeler mediante el postprocesamiento del archivo resultante de la tarea anterior.
A continuación, en la figura de la siguiente página (Figura 5.1), se presenta un esque-
ma general de la herramienta en la que podemos observar como COMPROMISE sirve de
“puente” entre ARMONÍAS-DGS y EPFC, Medini-QVT y BPMN Modeler; dotándola de
funcionalidades que no poseía tales como la gestión de los procesos, así como de todos los
elementos comprendidos en los mismos, funciones de transformación Model-to-Model que
tendrán como objetivo representar procesos mediante BPMN, y funcionalidades de análisis
de Conformidad de los mismos respecto con Modelos de Referencia utilizados en la industria.
CA
PÍTU
LO
5.R
ESU
LTAD
OS:H
ER
RA
MIE
NTA
CO
MPR
OM
ISE79
COMPRIMISE
BBDDFHibernate
ARMONÍASF-FDGS
ModelosFArmonizados
ModelosFnoFArmonizados
BBDD
GENERACIÓNFDEFGRÁFICASFDEFCOMPLIANCE
GENERACIÓNFDEFPDF
DESCOMPOSICIÓNFPROCESOS
RECOMENDADOR
DETERMINARFESTADODEFPROCESOS
CERTIFICACION CON MENOSRECURSOS POSIBLES
COMPLIANCE
GESTIÓN DEORGANIZACIÓN
TRANSFORMACIÓN
GESTIÓN DE ACTIVOS
METAMODELOS
MODELOS
UMA BPMN
DIRECCIÓN
CONOCIMIENTOFGLOBALPUBLICARFPROCESOF
EXPORTAR
G.P.S
ARTEFACTOS
EPFC
PROCESOS
METHODFLIBRARY
PROCESOSFDEFINIDOS
ELEMENTOS
PROCESOSFYFACTIVOSFDEFLAFORGANIZACIÓN
EJECUCIÓNFDEFPROCESOSFBPMN Task 1
Task 2
Task 3
Task 4
Figura 5.1: Diagrama general de COMPROMISE
80 5.1. FASE DE INICIO
5.1.3 Modelo de Casos de Uso
A continuación se presentan los casos de uso del rol de Administrador y del Gestor de Proce-
sos.
Este es el diagrama del Administrador de la herramienta. Podemos ver las funciones
anteriormente comentadas en la figura:
Figura 5.2: Diagrama de Casos de Uso de Administrador de la Herramienta
A continuación se presenta el diagrama de casos de Uso del Gestor de Procesos o respon-
sable de medir la conformidad de los procesos de la organización.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE 81
Figura 5.3: Diagrama de casos de uso Gestor de Procesos
5.1.4 Plan de Iteraciones
Corresponde a la Fase de Inicio del ciclo de vida elaborar el plan de Iteraciones. Dicho plan
se ha determinado a partir de los diagramas de casos de uso presentados con anterioridad. A
continuación se presentan a modo de tabla, incluyendo un dígito que determina el orden de las
mismas, la fase a la que pertenecen, los objetivos que se pretenden satisfacer, los artefactos
obtenidos conformando éstos los incrementos y el grado de importancia que adquieren en las
mismas los flujos de trabajo fundamentales en forma de porcentaje (Captura de Requisitos,
Análisis, Diseño, Implementación y Pruebas).
82 5.1. FASE DE INICIO
Número Iteración 0
Fase Inicio
• Identificar Requisitos
Objetivos • Visión general de la herramienta
• Especificación de Requisitos Software
• Estimación de tiempo y complejidad
• Anteproyecto (Visión general del proyecto)
• Estimación y Planificación del TFG (Apéndice E)
Productos de Trabajo • Modelo de Casos de Uso
• Plan de Iteraciones
Requisitos: 50 %
Análisis: 35 %
Esfuerzo flujo de Trabajo Diseño: 15 %
Implementación: -
Pruebas: -
Tabla 5.2: Iteración 0
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE 83
Número Iteración 1
Fase Elaboración
• Establecer correspondencia entre la base de datos de
ARMONÍAS-DGS y metamodelo UMA
Objetivos • Composición XML prueba de Concepto.
• Integración Plugin JAXB
• Despliegue en el servidor Arquitectura Struts2
• Corespondencia entre los elementos de la BBDD de
ARMONÍAS-DGS y UMA
Productos de Trabajo • Documento XML desechable
• Estructura de la Aplicación en el servidor Apache
Requisitos: 15 %
Análisis: 30 %
Esfuerzo flujo de Trabajo Diseño: 10 %
Implementación: 30 %
Pruebas: 15 %
Tabla 5.3: Iteración 1
84 5.1. FASE DE INICIO
Número Iteración 2
Fase Elaboración
• Implementación Marshalling y UnMarshalling automático de
Contenido de Método
Objetivos • Carga de Procesos definidos en EPFC en la herramienta
• Integración con Struts2
• Visualización de los procesos de la organización
Productos de Trabajo • Funcionalides básicas para Marshalling y Unmarshalling
• Herramienta Funcional integrada en el servidor Apache
Requisitos: 0 %
Análisis: 30 %
Esfuerzo flujo de Trabajo Diseño: 20 %
Implementación: 30 %
Pruebas: 20 %
Tabla 5.4: Iteración 2
Número Iteración 3
Fase Elaboración
• Implementar función Recomendador
Objetivos
• Implementar funciones de Conformidad
Productos de Trabajo • Análisis de Conformidad de Procesos
Requisitos: 0 %
Análisis: 10 %
Esfuerzo flujo de Trabajo Diseño: 20 %
Implementación: 40 %
Pruebas: 30 %
Tabla 5.5: Iteración 3
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE 85
Número Iteración 4
Fase Construcción
• Dar soporte a la representación gráfica
Objetivos • Carga de archivos XML externos
• Visualización de estadísticas
• Salida de documentos PDF, presentación de Informes
Productos de Trabajo • Componente de carga de ficheros con Interfaz
• Componente de visualización de Estadísticas
Requisitos: 0 %
Análisis: 10 %
Esfuerzo flujo de Trabajo Diseño: 15 %
Implementación: 60 %
Pruebas: 15 %
Tabla 5.6: Iteración 4
86 5.1. FASE DE INICIO
Número Iteración 5
Fase Construcción
• Definición del esquema de Base de Datos
• Implementar componente de Administración.
Objetivos • Integración de Hibernate con Struts2
• Persistencia de los procesos de la organización definidos en EPF
en la BBDD
• Integración de COMPROMISE con Medini QVT, EPFC, BPMN
Modeler.
• Subida y bajada al servidor de archivos a procesar necesarios.
• Gestión de ficheros en el servidor.
Productos de Trabajo • Esquema de Base de Datos
• Componente de Administración.
Requisitos: 0 %
Análisis: 5 %
Esfuerzo flujo de Trabajo Diseño: 15 %
Implementación: 70 %
Pruebas: 10 %
Tabla 5.7: Iteración 5
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE 87
Número Iteración 6
Fase Construcción
• Conversión entre básica entre modelos UMA Y BPMN
• Menú de la herramienta
Objetivos • Validador de sesiones de Usuario.
• Representación gráfica de modelos BPMN
• Plan de conversión entre modelos
Productos de Trabajo • Fichero qvt de transformación
• Software adicional para la representación gráfica en BPMN
Modeler
Requisitos: -
Análisis: 10 %
Esfuerzo flujo de Trabajo Diseño: 10 %
Implementación: 70 %
Pruebas: 10 %
Tabla 5.8: Iteración 6
Número 7
Fase Construcción
• Integración con otras heramientas (EPFC, MediniQVT,
BPMN2Modeler )
Objetivos Selector de Idiomas
• TestSuite
Productos de Trabajo • Herramienta con todas las Funcionalidades
• Manual de Instalación y Usuario
Requisitos: -
Análisis: -
Esfuerzo flujo de Trabajo Diseño: 10 %
Implementación: 30 %
Pruebas: 60 %
Tabla 5.9: Iteración 7
88 5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
5.2 Fase de Elaboración y Construcción
A continuación se presentarán en detalle las iteraciones definidas en la fase anterior, prestando
especial interés al análisis y diseño de la herramienta.
Como hemos dicho en capítulos anteriores, COMPROMISE se diseñará bajo el framework
Struts2, el cual provee al desarrollador de mecanismos necesarios para implementar su
solución bajo una arquitectura en tres capas conocida como Modelo-Vista-Controlador (MVC
por sus siglas), éste es explicado a continuación [59]:
• Modelo: En el modelo se encuentra la lógica de negocio y la información a representar.
Se comunica con la vista para proporcionarle los datos solicitados. No obstante el cliente
no interactúa directamente con este componente, sino que le envía las peticiones a un
controlador y éste es el encargado de acceder al modelo. De esta manera se mantiene la
independencia ambos.
• Controlador: Interactúa con la vista y es el que envía las peticiones al modelo para
operar sobre los datos que el cliente ha solicitado. Podemos decir que su función es un
filtro que impide al cliente operar directamente en el modelo, en el framework Struts2
al controlador se le conoce como “FilterDispatcher”.
• La vista es la encargada de interaccionar con el cliente, presentándole la información,
siendo por tanto es la salida del modelo.
La definición de esta arquitectura será determinante a lo largo del proyecto y se establece
en las primeras reuniones de la fase de elaboración, ya que desde un origen se buscaba una
estructura sólida y extensible.
Por otro lado la fase de Construcción estuvo orientada prácticamente a la elaboración del
código necesario para implementar la herramienta.
A continuación se dividirá esta sección en las siete iteraciones , exponiendo individual-
mente los artefactos obtenidos así como los diagramas más representativos que dan soporte a
la elaboración de la herramienta.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE 89
5.2.1 Iteración 1: Generador de Modelos UMA a partir de la BBDD de
ARMONÍAS-DGS
5.2.1.1 Análisis y Diseño
Corresponde a esta iteración elaborar una prueba de concepto que serialice elementos del
metamodelo UMA para su posterior carga en la herramienta EPFC. No obstante esta función
se detallará en la siguiente iteración, pues en la presente cobra más importancia la correspon-
dencia de los distintos elementos de la base de datos de ARMONÍAS-DGS a UMA.
Como mencionábamos, la base de datos de ARMONÍAS-DGS es la que proporciona el
conocimiento necesario para poblar el Contenido de Método de nuestra herramienta. Además,
será necesaria dicha base de datos origen con el fin de lograr una correcta correspondencia
entre los elementos de la misma y los generados adscritos al metamodelo UMA. Para compa-
rar los procesos de la organización con los modelos de referencia es necesario establecer una
correspondencia, pues no todos los elementos de ARMONÍAS-DGS tienen una correspon-
dencia clara en UMA.
Pertenecerá a la etapa de análisis dar una solución a la problemática expuesta con la
siguiente propuesta de transformación:
• Las tareas (Task) de la BBDD de ARMONÍAS-DGS se corresponderán con las tareas
Task por las similitudes entre ambas. No obstante, para no perder semántica, en algunas
de ellas será necesario englobar sus propiedades en los Task Descriptor, siendo éstos
una ampliación del nivel semántico de las anteriores.
• Las actividades (Activities) de ARMONÍAS-DGS no tendrán una correspondencia
clara. Pues en EPFC únicamente tendremos actividades en el momento de componer el
proceso, y lo que hacemos en un origen es poblar el contenido de método. Es por eso
que se convertirán en Disciplinas. Como hemos comentado en capítulos anteriores una
disciplina es una colección de Tareas relacionadas dentro de un área de interés y por
tanto, permite categorizar el trabajo.
90 5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
• Los roles de la BBDD de ARMONÍAS-DGS si tendrán una clara correspondencia
con los roles de UMA, es por eso que su transformación es directa, aunque ajustando
algunas propiedades entre los mismos.
• Los procesos (Process) no tendrán una correspondencia directa, pues es obvio que
en EPFC es lo que estamos modelando, pasando éstos a la categoría de guías en el
metamodelo UMA. Dicho elemento está definido en el capítulo anterior.
• Por último los productos de trabajo (Work Products) si que tendrán una correspondencia
directa, pues abordan el mismo concepto, son consumidos y/o producidas por las tareas.
Una particularidad de este elemento a la hora de exportarlo desde la base de datos de
ARMONÍAS-DGS es que, primero, deberemos introducir el tipo de Producto de trabajo,
distinguiendo entre “Artifact”, “Deliverable” y “Outcome”.
Además deberemos indicar en el mismo campo la naturaleza de los mismos, siendo
ésta “MandatoryInput”, “OptionalInput” y “Output” . Por tanto el campo “type” de la
base de datos de ARMONÍAS-DGS quedaría (como ejemplo) de la siguiente forma
“Artifact;MandatoryInput”. De esta menera, enriqueceremos la base de datos origen ya
que ARMONÍAS-DGS no contempla esta posibilidad.
PROCESO GUÍA
ARMONÍAS-DGS COMPROMISE
CORRESPONDE
TAREA TAREA
ROL ROL
PROD.TRABAJO PROD.TRABAJO
Figura 5.4: Correspondencias ARMONÍAS-DGS y UMA
En esta sección se presentan algunos artefactos resultantes de completar la primera itera-
ción.
El primero (Figura 5.5) corresponde a la prueba de concepto que fue necesaria para
componer el documento XML que cargará la herramienta EPFC. Por su sencillez, este primer
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE 91
documento no se incluirá en el presente proyecto, no obstante se incluirá el archivo en su
versión completa con el fin de que sirva como ejemplo de estructura para futuros desarrollos.
Figura 5.5: Diseño de Clases Prueba de Concepto
5.2.1.2 Implementación
A continuación, en el listado 5.1, se representa un extracto de código en el que se puede
observar la correspondencia entre tareas comentadas anteriormente. Hay que decir que dicho
extracto es un ejemplo representativo y que su madurez será completa al terminar la segunda
iteración, completando así la automatización de la carga del Contenido de Método.
Después de establecer dicha correspondencia, la herramienta EPFC cargará este archivo
(XML) para poblar su librería de método y así la organización podrá componer sus procesos
usando los elementos incluidos automáticamente en el Contenido de Método.
1 p u b l i c s t a t i c vo id load_Task ( MethodPlug in method , Ve c t o r d a t a _ t a s k ) {
23 S t r i n g name= n u l l , i d = n u l l , d e s c r i p t i o n = n u l l , id_compare = n u l l , n o d e i c o n = n u l l ;
45 f o r ( i n t z =0; z< d a t a _ t a s k . s i z e ( ) ; z ++) {
6 /*A continuación rellenaremos los campos de la tarea declarados anteriormente*/
78 name = u t i l . g e t _ p a r t _ t a s k ( d a t a _ t a s k . g e t ( z ) . t o S t r i n g ( ) , "name" ) ;
9 i d = u t i l . g e t _ p a r t _ t a s k ( d a t a _ t a s k . g e t ( z ) . t o S t r i n g ( ) , "id" ) ;
10 d e s c r i p t i o n = u t i l . g e t _ p a r t _ t a s k ( d a t a _ t a s k . g e t ( z ) . t o S t r i n g ( ) , "description" ) ;
11 id_compare = u t i l . g e t _ p a r t _ t a s k ( d a t a _ t a s k . g e t ( z ) . t o S t r i n g ( ) , "activity" ) ;
1213 u t i l . i n s e r t _ C o n t e n t E l e m e n t ( method , name , "Task" , i d . r e p l a c e (" " , "" ) , d e s c r i p t i o n , id_compare ) ;
Por último, otra funcionalidad a completar al término de esta iteración fue la de recomen-
dador. Esta función indica cuánto nos falta por implementar y lo que tenemos implementado
(elementos del marco de referencia) además de apoyarnos en el gráfico de barras 5.12 que nos
indica el tanto por ciento de tareas que reunimos para cada uno de los marcos de referencia.
102 5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Figura 5.15: Gráfica de Compliance total de la organización.
5.2.3.2 Implementación
A continuación, en el Listado 5.4, podemos observar la implementación de los aspectos
mencionados. Las listas “porcentaje_compliance_g1” y “nombre_compliance_g1” contienen
los nombres de los procesos y el tanto por ciento de la concordancia de las tareas del proceso
con las del modelo de calidad examinado. Haremos esta función para cada una de las gráficas
presentes en la herramienta.
Como podemos ver en la línea 11, las tareas con las que comparamos están en la base de
datos de ARMONÍAS-DGS.
1 p u b l i c vo id r e a l i z a _ c o m p l i a n c e ( ) {
23 f o r ( i n t i =0 ; i < p r o c e s o s . s i z e ( ) ; i ++) {
4 //metemos el proceso en el array que representaremos
5 nombre_compl iance_g1 [ i ] = p r o c e s o s . g e t ( i ) . getName ( ) ;
6 //sacamos todas las tareas y comparamos el nombre con la bbdd de armonías.
7 V ec to r t a s k s _ a r m o n i a s = u t i l . g e t A l l _ T a s k _ b y _ P r o c e s s _ V e c t o r ( s e l e c c i o n _ h i s t o r i c o ) ;
89 a u x _ t a r e a s _ o r g = t a s k _ m a n a g e r . g e t T a s k b y P r o c e s s ( p r o c e s o s . g e t ( i ) . getName ( ) ) ;
10 f o r ( i n t j =0 ; j < a u x _ t a r e a s _ o r g . s i z e ( ) ; j ++) {
11 i f ( u t i l . e x i s t T a s k ( s e l e c c i o n _ h i s t o r i c o , a u x _ t a r e a s _ o r g . g e t ( j ) . getName ( ) ) ) {
12 p e r c e n t ++;
13 }
14 }
15 p o r c e n t a j e _ c o m p l i a n c e s _ g 1 [ i ] = ( i n t ) ( ( ( do ub l e ) p e r c e n t / ( d oub l e ) t a s k s _ a r m o n i a s . s i z e ( ) ) *100) ;
1 t r a n s f o r m a t i o n uma2bpmn (UMA: uma , BPMN2: bpmn2 ) {
23 key d e f i n i t i o n s { id , name } ;
4 key P r o c e s s { id , name } ;
56 t o p r e l a t i o n TaskToBPMNTask{
78 name_process : S t r i n g ;
9 e l e m e n t : S t r i n g ;
10 i d : S t r i n g ;
1112 c h e c k o n l y domain UMA p r o c e s o : uma : : D e l i v e r y P r o c e s s {
13 name = name_process ,
14 i d = i d
15 } ;
1617 c h e c k o n l y domain UMA e l e m e n t o s : uma : : BreakdownElement {
18 name = e l e m e n t
19 } ;
2021 e n f o r c e domain BPMN2 d e f i n i c i o n : bpmn2 : : d e f i n i t i o n s {
22 i d =’Definition’ ,
23 name = name_process ,
24 t a r g e t N a m e s p a c e =’Mi_ejemplo_de_proceso’ ,
25 t ypeLanguage =’http://www.java.com/javaTypes’ ,
26 e x p r e s s i o n L a n g u a g e =’http://www.mvel.org/2.0’ ,
27 r o o t E l e m e n t s = f : bpmn2 : : P r o c e s s {
28 name = name ,
29 i d = id ,
30 f l o w E l e m e n t s = e l : bpmn2 : : Task {
31 name = e l e m e n t
32 }
33 }
34 } ;
3536 }
37 }
Listado 5.11: Ejemplo de código de la Transformación.
El otro aspecto importante de esta iteración es el código que representa la validación de
usuario. Esta implementación la utilizaremos en las acciones en las que las funcionalidades
estén restringidas a determinados roles, o simplemente para comprobar que hay un usuario
registrado y que no se ha saltado la fase de login (si es así se le remitirá a la página de
identificación). Estos codigos están representados en los Listados 5.12 y 5.13 respectivamente
1 S t r i n g c o n f i r m a c i o n = A c t i o n S u p p o r t .ERROR;
23 L i s t < h i b e r n a t e . model . User > u s u a r i o _ a _ v a l i d a r = userman . V a l i d a t e U s e r ( u s u a r i o , pwd ) ;
4 i f ( u s u a r i o _ a _ v a l i d a r . s i z e ( ) ! = 0 ) {
5 c o n f i r m a c i o n = A c t i o n S u p p o r t . SUCCESS ;
6 s e s s i o n . p u t ("user" , u s u a r i o _ a _ v a l i d a r ) ;
7 }
Listado 5.12: Introducir el objeto usuario al validar la sesión (Login)
122 5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
1 A r r a y L i s t < h i b e r n a t e . model . User > u s u a r i o = ( A r r a y L i s t <User >) A c t i o n C o n t e x t . g e t C o n t e x t ( ) . g e t S e s s i o n ( ) . g e t ("
user" ) ;
Listado 5.13: Recuperar Objeto Usuario en una Acción para posteriormente
evaluarlo.
5.2.6.3 Pruebas
En esta etapa de la iteración realizaremos test de validación de usurios. La Figura 5.14
es un ejemplo de ello. Podemos ver como en la función setUp() creamos un usuario y
lo introducimos en la sesión para posteriormente recuperarlo en el método testCreacion(),
correspondiente al test, y ver que hay un usuario con nombre Matias. Cabe destacar que
para realizar los test es necesario tener el servidor funcionando y haber llamado a la acción
correspondiente.
1 @Before
2 p u b l i c vo id se tUp ( ) {
3 Map s e s s i o n = A c t i o n C o n t e x t . g e t C o n t e x t ( ) . g e t S e s s i o n ( ) ;
4 h i b e r n a t e . c o n t r o l l e r . UserManager userman = new h i b e r n a t e . c o n t r o l l e r . UserManager ( ) ;
5 L i s t < h i b e r n a t e . model . User > u s u a r i o _ a _ v a l i d a r = userman . V a l i d a t e U s e r ("matias" , "a" ) ;
6 s e s s i o n . p u t ("usuario" , u s u a r i o _ a _ v a l i d a r ) ;
7 }
89 @Test
10 p u b l i c vo id t e s t C r e a c i o n ( ) {
1112 A r r a y L i s t < h i b e r n a t e . model . User > u s u a r i o = ( A r r a y L i s t <User >) A c t i o n C o n t e x t . g e t C o n t e x t ( ) . g e t S e s s i o n ( ) .
g e t ("usuario" ) ;
13 a s s e r t T r u e ( u s u a r i o . s i z e ( ) ==1) ;
14 a s s e r t T r u e ( u s u a r i o . g e t ( 0 ) . getName ( ) . e q u a l s ("matias" ) ) ;
Listado 5.14: Test Validar Sesión
5.2.7 Iteración 7: Documentación de la herramienta
En esta iteración tendrá como objetivos la integración de COMPROMISE con las herra-
mientas de modelado y desarrollo que la complementan. Para ello deberemos proponer los
mecanismos necesarios para su ejecución desde nuestra herramienta.
Otro componente importante y que es vital para las herramientas actuales es la posibilidad
de cambio de idioma. COMPROMISE está disponible en Inglés y Español, pudiendo cambiar
en cualquier momento de idioma y manteniendo la selección durante la navegación en la
Por la simplicidad de su diseño y el poco aporte de los diagramas de análisis con respecto
a los anteriormente presentados, en esta iteración no se han plasmado en el documento los
diagramas correspondientes a estas fases, pues la integración con las demás herramientas
únicamente supone el cambio de ruta antes de la llamada a ejecución, implementado con la
llamada a una acción en la clase RutasAction junto con su formulario correspondiente situado
en el menú de administración de la herramienta, y para la funcionalidad de cambio de idiomas
también supone la llamada de una acción proporcionada por el framework Struts2.
5.2.7.2 Implementación
A continuación se dispone de un formulario proporcionado por COMPROMISE para pro-
porcionar las rutas de los ejecutables a las tres aplicaciones relacionadas con la herramienta
(Figura 5.31).
Figura 5.31: Ventana de cambio de rutas de las distintas herramientas
124 5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
El cambio de rutas proporcionado consiste en una cadena de caracteres que será enviada
a la acción de ejecución de las herramientas, Execute_Medini.java, Execute_EPFC.java y
Execute_BPMN2Modeler.java. A continuación, en el Listado 5.15 se puede observar un
extracto del código que permite llamar al ejecutable e iniciar la sesión en la herramienta
Medini-QVT.
1 package a c t i o n s ;
23 p u b l i c c l a s s Execu te_Medin i e x t e n d s A c t i o n S u p p o r t {
45 p r i v a t e s t a t i c S t r i n g p a t h ="" ;
67 p u b l i c s t a t i c S t r i n g g e t P a t h ( ) {
8 r e t u r n p a t h ;
9 }
10 p u b l i c s t a t i c vo id s e t P a t h ( S t r i n g p a t h ) {
11 Execu te_Medin i . p a t h = p a t h ;
12 }
13 p u b l i c S t r i n g e x e c u t e _ m e d i n i ( ) {
14 S t r i n g r e t o r n o = "" ;
15 A r r a y L i s t < h i b e r n a t e . model . User > u s u a r i o = ( A r r a y L i s t <User >) A c t i o n C o n t e x t . g e t C o n t e x t ( ) . g e t S e s s i o n ( ) .