grado en ingenierÍa en informÁtica - ruidera.uclm.es

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

Autor: Víctor Parrado López

Director: Félix Oscar García Rubio

Diciembre, 2014

©Permission is granted to copy, distribute and/or modify this document under the terms ofthe GNU Free Documentation License, Version 1.3 or any later version published by the FreeSoftware Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-CoverTexts. A copy of the license is included in the section entitled "GNU Free DocumentationLicense".

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.

xiii

Índice general

Agradecimientos xiii

Índice de figuras xviii

Índice de tablas xxi

Índice de listados xxiii

1 Introducción 11.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Estructura del Documento . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Objetivos del PFC 92.1 Objetivos derivados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Funcionalidad General de la Herramienta . . . . . . . . . . . . . . . . . . . 112.3 Destrezas a adquirir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Estado de la Cuestión 153.1 Procesos Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Ingeniería de Procesos Software . . . . . . . . . . . . . . . . . . . . . . . 183.3 SPEM y EPFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.1 Visión del metamodelo SPEM 2.0 . . . . . . . . . . . . . . . . . . 243.3.2 Eclipse Process Framework Composer (EPFC) . . . . . . . . . . . 28

3.4 Modelos de Referencia y Mejora de Procesos Software . . . . . . . . . . . . 313.4.1 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.2 ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.3 ISO/IEC 9000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.4 ISO 90003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 Armonización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.5.1 HFramework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5.2 ARMONÍAS-DGS . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.6 Conformidad de Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.7 Desarrollo de Software Dirigido por Modelos (DSDM) . . . . . . . . . . . 423.8 Herramientas relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 Método de Trabajo 514.1 OpenUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.1 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.1.2 Roles de OpenUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

xv

xvi ÍNDICE GENERAL

4.1.3 Proceso Iterativo e Incremental . . . . . . . . . . . . . . . . . . . . . 574.1.4 Flujos Fundamentales de Trabajo Obtenidos para el desarrollo de

COMPROMISE. . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2 Entorno Tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2.1 Herramientas de modelado y desarrollo y tecnologías utilizadas . . 604.2.2 Entorno tecnológico MDA . . . . . . . . . . . . . . . . . . . . . . . 674.2.3 Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.2.4 Lenguajes y Librerías utilizadas . . . . . . . . . . . . . . . . . . . 70

5 Resultados: Herramienta COMPROMISE 755.1 Fase de Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.1.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.1.2 Dominio de la Herramienta . . . . . . . . . . . . . . . . . . . . . . . 775.1.3 Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . 805.1.4 Plan de Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.2 Fase de Elaboración y Construcción . . . . . . . . . . . . . . . . . . . . . 885.2.1 Iteración 1: Generador de Modelos UMA a partir de la BBDD de

ARMONÍAS-DGS . . . . . . . . . . . . . . . . . . . . . . . . . . 895.2.2 Iteración 2: Carga del Contenido de Método de EPFC a partir de la

BBDD ARMONÍAS-DGS . . . . . . . . . . . . . . . . . . . . . . 925.2.3 Iteración 3: Implementación de las funciones para el Análisis de

Conformidad de Procesos . . . . . . . . . . . . . . . . . . . . . . 985.2.4 Iteración 4 : Implementación de Módulo de Representación gráfica

de estadísticas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.2.5 Iteración 5: Integración de la capa de Persistencia con COMPROMISE1105.2.6 Iteración 6: Definir transformación entre los metamodelos UMA y

BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.2.7 Iteración 7: Documentación de la herramienta . . . . . . . . . . . . 122

5.3 Fase de Transición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.4 Patrones de Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.4.1 Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . . . . . 1265.4.2 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275.4.3 DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

6 Conclusiones y Propuestas 1296.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.1.1 Propuestas de trabajos futuros . . . . . . . . . . . . . . . . . . . . . 1316.1.2 Opinión Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Bibliografía 134

A Manual de Instalación 143

B Manual de Usuario 145B.1 Registro de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145B.2 Selector de Idioma y Menú de COMPROMISE . . . . . . . . . . . . . . . 146B.3 Administración de la herramienta . . . . . . . . . . . . . . . . . . . . . . . . 147B.4 Cargar Procesos EPFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150B.5 Compliance Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

ÍNDICE GENERAL xvii

B.6 Generar archivo para MediniQVT . . . . . . . . . . . . . . . . . . . . . . . 157B.7 Abrir Medini-QVT y ejecutar transformación . . . . . . . . . . . . . . . . . 157B.8 Representación Proceso transformado (BPMN) en BPMN2 Modeler . . . . 158B.9 Ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

C Acrónimos 161

D Glosario 165

E Planificación del TFG 169E.1 Planificación Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169E.2 Equipo de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170E.3 Recursos Materiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170E.4 Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

F Código Fuente 173F.1 Ejemplo clase Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Índice de figuras

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

3.1 Etapas Clave de la Gestión del Proceso Software [57]. . . . . . . . . . . . . 173.2 Conceptos centrales de SPEM 2.0. [63] . . . . . . . . . . . . . . . . . . . . 213.3 Usos básicos SPEM 2.0. [63] . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Elementos de SPEM 2.0 [63]. . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 Estructura de paquetes de SPEM 2.0 [57]. . . . . . . . . . . . . . . . . . . 253.6 Ejemplo gráfico del contenido de método definido con EPFC. . . . . . . . . 293.7 Jerarquía de los elementos de SPEM 2.0 en la definición de Procesos [57]. 303.8 Definición del proceso con EPFC . . . . . . . . . . . . . . . . . . . . . . 303.9 Procesos ISO 12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.10 Esquema de HFramework [53]. . . . . . . . . . . . . . . . . . . . . . . . 383.11 Esquema de ARMONÍAS-DGS. [61] . . . . . . . . . . . . . . . . . . . . . 393.12 Arquitectura de distintos niveles de modelado[38]. . . . . . . . . . . . . . 443.13 Organización de MDE [38] . . . . . . . . . . . . . . . . . . . . . . . . . . 443.14 Transformaciones MDA[38] . . . . . . . . . . . . . . . . . . . . . . . . . 463.15 Arquitectura Conceptual de Transformaciones[38] . . . . . . . . . . . . . 48

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

BPMN2 Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.29 Ejemplo proceso BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.30 Iconos de Cambio de Idioma . . . . . . . . . . . . . . . . . . . . . . . . . 1235.31 Ventana de cambio de rutas de las distintas herramientas . . . . . . . . . . 1235.32 Esquema del Patrón MVC . . . . . . . . . . . . . . . . . . . . . . . . . . 126

B.1 Vista Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145B.2 Ejemplo del Menú en Español . . . . . . . . . . . . . . . . . . . . . . . . . 147B.3 Ejemplo del Menú en Inglés . . . . . . . . . . . . . . . . . . . . . . . . . . 147B.4 Acceso al menú de administración. . . . . . . . . . . . . . . . . . . . . . . 148B.5 Usuarios registrados en COMPROMISE . . . . . . . . . . . . . . . . . . . 148B.6 Administración de las organizaciones de COMPROMISE. . . . . . . . . . . 148B.7 Selector de Rutas de COMPROMISE . . . . . . . . . . . . . . . . . . . . . 149B.8 Definición de los márgenes de aceptación . . . . . . . . . . . . . . . . . . 149B.9 Selector de aceptación de Conformidad . . . . . . . . . . . . . . . . . . . 150B.10 Menú de Conformidad de Compromise. . . . . . . . . . . . . . . . . . . . 150B.11 Ejecutar EPFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151B.12 Composición de Procesos mediante EPFC . . . . . . . . . . . . . . . . . . . 151B.13 Crear Delivery Process EPFC . . . . . . . . . . . . . . . . . . . . . . . . 152B.14 Ejecución el Panel Principal de Compromise . . . . . . . . . . . . . . . . 153B.15 Gráfica de Histórico de la Conformidad de Procesos de una Organización . 154

ÍNDICE DE FIGURAS xxi

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-

niQVT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157B.22 Ejecución del Framework MediniQVT . . . . . . . . . . . . . . . . . . . . . 157B.23 Ejecución de la transformación MediniQVT . . . . . . . . . . . . . . . . . 158B.24 Ejecuta el Framework BPMN Modeler . . . . . . . . . . . . . . . . . . . . 158B.25 Presentación de Proceso mediante BPMN Modeler . . . . . . . . . . . . . 159B.26 Ejecución de la ayuda de Compromise . . . . . . . . . . . . . . . . . . . . 159

Índice de tablas

5.1 Roles de la herramienta con sus funcionalidades y componente al que pertenecen. 765.2 Iteración 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.3 Iteración 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.4 Iteración 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.5 Iteración 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.6 Iteración 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.7 Iteración 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.8 Iteración 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.9 Iteración 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

E.1 Planificación Temporal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170E.2 Recursos Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171E.3 Costes por contratación de empleados. . . . . . . . . . . . . . . . . . . . . . 171

xxiii

Índice de listados

5.1 Extracto “ActionCargarMethodContent.java” . . . . . . . . . . . . . . . . . 915.2 Ejemplo Marshall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.3 Test Composición XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.4 Ejemplo clase Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.5 Test Función Recomendador. . . . . . . . . . . . . . . . . . . . . . . . . . 1045.6 Código de generación de documentos PDF. . . . . . . . . . . . . . . . . . 1085.7 Test salida documento PDF. . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.8 Persistencia objeto Proceso. . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.9 Ejemplo Interceptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.10 Test Nuevo Rol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.11 Ejemplo de código de la Transformación. . . . . . . . . . . . . . . . . . . . 1215.12 Introducir el objeto usuario al validar la sesión (Login) . . . . . . . . . . . . 1215.13 Recuperar Objeto Usuario en una Acción para posteriormente evaluarlo. . . 1225.14 Test Validar Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225.15 Ejecución Medini-QVT. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245.16 Diccionario Español. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.17 Diccionario Inglés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.18 Extracto de código del Patrón Singleton . . . . . . . . . . . . . . . . . . . . 127F.1 Ejemplo clase Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173F.2 Ejemplo UnMarshall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

xxv

Capítulo 1

Introducción

Debido a la ingente oferta de producto en la actualidad, la demanda es muy selectiva y

como consecuencia las exigencias de los consumidores son muy elevadas. Es por eso que las

organizaciones han experimentado un cambio en cuanto al paradigma de mercado, ya que su

supervivencia está estrechamente relacionada con el producto que ofrecen y por tanto con su

calidad.

La calidad en el entorno Software no es una excepción, aunque en la mayoría de los casos

es cierto que no puede ser asegurada basándose en el producto final o desarrollando controles

de calidad estadísticos, sino que es conveniente fijarnos en el proceso por el cual éste se

obtiene. Según [36] existe una correlación directa entre la calidad del proceso y la calidad del

producto obtenido.

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]. La idea básica es que el

proceso defina quién hace qué, cuándo y cómo alcanzar un determinado objetivo.

Las organizaciones cada vez son más conscientes de que documentar, medir y comparar

sus procesos son premisas esenciales para ofrecer un producto de calidad. Cada organiza-

ción debe tener sus procesos definidos, propios e intransferibles, que deben satisfacer sus

propósitos de negocio. No obstante, es recomendable tener en cuenta una serie de estándares

y buenas prácticas en su definición para lograr un proceso de calidad. Estas guías toman el

nombre de modelo de referencia.

2

Básicamente, un modelo de referencia define un conjunto de procesos organizado de

forma coherente, que facilitan a una organización un mejor desempeño de los mismos y que

suele traducirse en una mayor calidad en los productos y servicios que ofrecen.

La idea de mejora de procesos por parte de las organizaciones con el objetivo de incre-

mentar la calidad de los mismos ha llevado a la aparición de muchos marcos de procesos y de

evaluación, hasta tal punto que se ha convertido en “una ciénaga en la que se empantanen los

esfuerzos de mejora de procesos si una organización no es cuidadosa” [65].

Figura 1.1: La ciénaga de los estándares y modelos de referencia de la madurez, evaluación y

mejora de procesos [57].

CAPÍTULO 1. INTRODUCCIÓN 3

Sin embargo y a pesar de la cantidad de estándares y modelos de referencia así como de la

heterogeneidad de sus propósitos, resultaría imprudente intentar adaptar los procesos de una

organización para con un marco de referencia particular, pues son metodologías generales y

no tienen por qué adaptarse fielmente a los propósitos de una organización. Es por eso que las

empresas pueden encontrarse ante la necesidad de la implementación de varios modelos de

referencia, echando en falta mecanismos que les faciliten el trabajo. Surge así el concepto de

Armonización de marcos de referencia.

Elementos de distintos marcos de referencia pueden coincidir con los propósitos de nego-

cio de las organizaciones, la armonización permite integrar estos elementos heterogéneos en

un único marco de referencia personalizado, tal como se aborda con más profundidad en el

siguiente apartado.

Una vez determinado el marco de referencia que vamos a utilizar (armonizado o no), las

organizaciones deberán definir sus procesos siguiendo las pautas del mismo. Para ello el

mercado dispone de algunas herramientas que darán soporte a esta tarea, entre estas herra-

mientas destacaremos EPF Composer. EPF Composer, en adelante EPFC, es una herramienta

que da soporte a la definición de los procesos de una organización utilizando para ello el

metamodelo UMA, compatible con SPEM 2.0 [42]. Tanto UMA como SPEM 2.0 permiten

a las organizaciones representar un proceso de forma sencilla utilizando como elementos

básicos roles, productos de trabajo y tareas. La idea subyacente es que el modelo del proceso

nos especifique quién hace (rol) qué tarea para, a partir de unas entradas productos de

trabajo obtener unas salidas productos de trabajo).

Mediante EPFC las empresas pueden crear sus Contenidos de Método (que contendrán

roles, tareas, productos de trabajo, etc.) y a partir de ella definir sus procesos de una forma

sistemática. No obstante si la organización decide alinear sus procesos con uno o más modelos

de referencia, no dispone de los mecanismos para evaluar si sus procesos son conformes a

éstos.

Por este motivo surge el concepto de “Compliance” o Conformidad con la definición del

proceso, que permite evaluar si el proceso cumple con el modelo de referencia y su grado de

4 1.1. ANTECEDENTES

cumplimiento en base a distintas ponderaciones. Cabe destacar que para facilitar la compren-

sión y lectura del documento se utilizará el término Conformidad en lo sucesivo, no obstante

es muy común encontrar en la bibliografía la expresión en su traducción inglesa (Compliance).

Este último concepto constituye la principal motivación del presente TFG y determina su

alcance, que comprende la representación de modelos y marcos de referencia de acuerdo al

metamodelo (UMA), el cálculo de conformidad de los procesos de la organización respecto a

procesos de referencia, la transformación de procesos para facilitar su procesamiento automá-

tico y la visualización de la conformidad como soporte para la toma de decisiones.

A continuación se presentan los antecedentes que dan soporte y motivan la herramienta

objeto del Trabajo de Fin de Grado.

1.1 Antecedentes

Los antecedentes que constituyen la motivación del desarrollo de esta herramienta son: HFra-

mework [53], tesis que propone mecanismos de armonización en ambientes multimarco

y la herramienta ARMONÍAS-DGS, la cual da soporte tecnológico al paradigma anterior,

soportando la armonización y evaluación de marcos de procesos heterogéneos [61].

La herramienta objeto del presente Trabajo de Fin de Grado está estrechamente relacio-

nada con el segundo antecedente, pues se nutrirá del conocimiento almacenado en la base

de datos de ARMONÍAS-DGS para definir la Librería de Método de la organización. De

esta manera, además de marcos de referencia estandarizados, COMPROMISE también podrá

analizar la conformidad de los procesos de ambientes multi-marco.

Para contextualizar el antecedente principal se debe considerar que la herramienta ARMONÍAS-

DGS está dividida en dos bloques, el componente de armonización y el componente de

evaluación:

• Componente de Armonización: Básicamente las tareas de este componente se dividen

en gestionar y analizar gráficamente los proyectos de armonización. Por un lado tiene


en cuenta los recursos que necesita y por otro gestiona la estrategia de armonización de

los marcos de procesos.

• Componente de Evaluación: Este componente se encarga de la gestión y configura-

ción de las evaluaciones que se llevarán a cabo sobre las fábricas, partiendo de los

cuestionarios hasta el soporte y análisis gráfico de los resultados.

A continuación, en la Figura 1.2 se presenta un esquema básico de la herramienta y su

interacción con ARMONÍAS-DGS. Como podemos ver, COMPROMISE provee al usuario

de funcionalidades de transformación de modelos entre Procesos Software y Procesos de

negocio y análisis de conformidad de los procesos de la organización respecto a los modelos

de referencia almacenados en la base de datos de ARMONÍAS-DGS.

COMPROMISE

BBDD Hibernate

ARMONÍAS - DGS

Modelos Armonizados

Modelos no Armonizados

BBDD

EPFC

PROCESOS DEFINIDOS

COMPLIANCE

GESTIÓN DE

ORGANIZACIÓN

TRANSFORMACIÓN

Figura 1.2: Relación entre ARMONIAS-DGS y COMPROMISE

6 1.2. ESTRUCTURA DEL DOCUMENTO

1.2 Estructura del Documento

Además de la Introducción el presente TFG está formado por los siguientes capítulos:

2. Objetivos: Se presentan los objetivos que se desean satisfacer con el desarrollo de la

presente herramienta, así como una breve explicación de los mismos.

3. Estado de la Cuestión: En este capítulo se presentan los distintos avances en las áreas

que tienen relación con el desarrollo del presente Trabajo de Fin de Grado.

4. Método de Trabajo: En este capítulo se presenta el método de trabajo seguido en

el proceso de desarrollo de COMPROMISE y el entorno tecnológico utilizado en el

mismo.

5. Resultados: Herramienta COMPROMISE En este capítulo se presentarán los prin-

cipales artefactos generados durante el desarrollo de la herramienta en sus distintas

iteraciones de acuerdo al método de trabajo seguido.

6. Conclusiones y Propuestas: En este capítulo se presentan las conclusiones obtenidas

al final del desarrollo, el grado del cumplimiento de los objetivos, propuestas para

trabajo futuro y la opinión personal del autor una vez finalizado el proceso de desarrollo

de COMPROMISE.

El presente documento incluye además los siguientes apéndices.

1. Manual de Instalación (Apéndice A): En este apéndice se detallarán los pasos nece-

sarios para la correcta instalación de COMPROMISE.

2. Manual de Usuario (Apéndice B): En este apéndice se describe el manual de usuario

de la herramienta y se ilustra su uso con ejemplos.

3. Acrónimos: (Apéndice C): En este apéndice se presentarán los acrónimos utilizados

para la elaboración del presente documento.

4. Glosario: (Apéndice D): En este apéndice se pueden encontrar los términos utilizados

en el presente TFG.


5. Planificación del TFG: (Apéndice E): En este apéndice se muestra una estimación

del esfuerzo y recursos utilizados. Además se expone una planificación temporal del

desarrollo.

6. Código Fuente: (Apéndice F): En este apéndice se presentan extractos de código

representativo del proceso de desarrollo.

Capítulo 2

Objetivos del PFC

A lo largo de este capítulo se describe el objetivo principal de este Trabajo de Fin de Grado,

junto con los objetivos parciales derivados del mismo.

La motivación del presente Trabajo de Fin de Grado viene determinada por la necesidad

de una herramienta que evalúe el nivel de conformidad de los procesos de una organización

respecto a un modelo de referencia, mostrar los resultados de su análisis de una manera

gráfica y proporcionar a las organizaciones un valor tangible por el cual determinar el grado

de conformidad de sus tareas implementadas.

Además aumentará el valor añadido de la herramienta ARMONIAS-DGS, antecedente de

la presente, pues lograremos una representación de los modelos de referencia de su base de

datos mediante el metamodelo UMA, las organizaciones dispondrán de este conocimiento a

la hora de definir sus procesos y será posible determinar su grado de conformidad.

Del mismo modo la herramienta dará soporte a la ejecución de transformaciones entre

modelos UMA y BPMN, siguiendo el paradigma de desarrollo dirigido por modelos (Model

Driven Development) con el objetivo de representar su resultado en la herramienta de modela-

do BPMN Modeler para facilitar la ejecución futura de los procesos.

10 2.1. OBJETIVOS DERIVADOS

A continuación descompondremos el objetivo principal en varios objetivos subyacentes:

2.1 Objetivos derivados

• Establecer la correspondencia de los procesos de la base de datos de la herramienta

ARMONÍAS-DGS [61] que provienen de los distintos estándares (armonizados o no)

con el metamodelo UMA.

• Proporcionar a la herramienta EPF Composer de una base de conocimiento en forma

de Librería de Método que contenga todos los elementos de los distintos marcos de

procesos que alberga la herramienta ARMONÍAS-DGS en su base de datos.

• Analizar la conformidad de los procesos que la organización haya definido para con los

marcos de referencia que sean seleccionados. Así la organización tendrá mecanismos

de visualización gráfica que proporcionen el estado y nivel de completitud en el que

se encuentran los procesos y de qué manera se podrían mejorar teniendo en cuenta los

recursos de la organización.

• La herramienta tendrá la capacidad de crear un perfil para las empresas con los recursos

que posee. Éstos se tendrán en cuenta a la hora de proponer soluciones a la organización.

Un ejemplo es la función de recomendador, que indica al usuario la certificación que

menos recursos necesitará para llevarse a cabo satisfactoriamente.

• Elaborar informes de conformidad de los distintos procesos de la organización que

incluya las propiedades de los mismos así como los componentes principales que lo

forman (tareas, roles y productos de trabajo).

• Dará soporte a la transformación entre modelos, pudiendo representar las tareas de la

organización conforme al metamodelo BPMN en alguna herramienta de modelado de

procesos de negocio (Bizagi, BPMN Modeler, Bonita, etc.)

CAPÍTULO 2. OBJETIVOS DEL PFC 11

2.2 Funcionalidad General de la Herramienta

Con el fin de cumplir los objetivos especificados en el apartado anterior, la herramienta estará

formada por cuatro bloques principales de funcionalidad:

1. En primera instancia se necesitará un bloque encargado de proveer a la herramienta EPF

Composer de una Librería de Método que contenga todos los elementos que componen

los distintos marcos de referencia almacenados en ARMONÍAS-DGS.

2. Será necesario incorporar a la base de datos el/los procesos que previamente hayamos

definido en la herramienta EPF Composer.

3. Dará soporte a la visualización gráfica de la conformidad de los procesos respecto de

los distintos marcos de referencia.

4. Un cuarto bloque que se encargará de las transformaciones entre procesos UMA y

BPMN y de su representación en algún framework de modelado de Procesos de Negocio

(Bonita, Bizagi, BPMN Modeler, etc.)

Además de las funcionalidades ya mencionadas la herramienta necesitará satisfacer unos

requisitos no funcionales:

• Portabilidad: La ejecución de la herramienta debe ser independiente de la plataforma,

es por eso que se ha escogido la opción de una aplicación Web; de esta manera la

posibilidad de la ejecución de la herramienta únicamente la limita la necesidad de una

conexión a Internet y la de un equipo con un navegador instalado.

• Usabilidad: Dada la complejidad de los conceptos tratados en la herramienta ésta debe

de ser intuitiva, automatizando los máximos procesos posibles y deberá ser acompañado

de un manual de usuario incluido en el presente documento con el objetivo de facilitar

en la medida de lo posible el trabajo a los usuarios.

• Disponibilidad La herramienta deberá estar disponible para su uso cuando se necesite,

es por eso que se desarrollará mediante una plataforma web, con acceso 24/7.

12 2.3. DESTREZAS A ADQUIRIR

• Accesibilidad: La herramienta deberá proporcionar un fácil acceso al servicio. Este es

otro de los motivos por los que se ha escogido el paradigma de una herramienta web.

El sistema estará accesible en cualquier posición geográfica, previa identificación del

usuario en el mismo.

• Escalabilidad: La herramienta deberá estar implementada teniendo en cuenta las

posibles necesidades que el crecimiento de la misma puedan ocasionar.

2.3 Destrezas a adquirir

1. Ser capaz de llevar a cabo un proyecto, desde la recogida de requisitos hasta la imple-

mentación de los mismos, pruebas y posterior mantenimiento.

2. Aplicación de Patrones de Diseño para que la arquitectura sea robusta y extensible [37].

3. Aprender la metodología de OpenUP aplicándola al desarrollo de la herramienta.

4. Adquirir destreza con el framework de desarrollo Struts2, suponiendo un nuevo para-

digma de implementación usando el patrón Modelo-Vista-Controlador.

5. Conocer herramientas CASE utilizadas para definir los procesos, así como para repre-

sentarlos gráficamente, conociendo de qué manera almacenan los datos.

6. Adquirir aptitudes en ramas transversales como es el caso de la tecnología Web. Lo que

conlleva al conocimiento de lenguajes y tecnologías asociadas como JSP, Strut2, XML,

HTML, Java Script, CSS3, etc.

7. Afianzar e incrementar conceptos de la rama de Ingeniería del Software, como pueden

ser los Procesos, Estándares, Gestión de Procesos, Metodologías de Desarrollo, etc.

8. Estudiar los modelos de referencia con sus respectivos modelos de evaluación del área

de Procesos Software.

9. Analizar el contexto real en el que se encuentran los procesos en las organizaciones y

los mecanismos para determinar un valor objetivo de correspondencia con los modelos

de referencia.

10. Estudiar mecanismos de intercambio de información entre herramientas heterogéneas.

CAPÍTULO 2. OBJETIVOS DEL PFC 13

11. Conocimientos de herramientas de Correspondencia Objeto-Relacional (ORM), en este

caso la herramienta Hibernate.

12. Conocimiento de los metamodelos SPEM v2.0 y BPMN así como de éste último los

metamodelos que le sirven como apoyo (BPMNDI, DC y DI).

13. Adquirir competencias en desarrollo software dirigido por modelos, en particular en

tecnologías MDA (modelos, metamodelos, transformaciones).

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


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


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


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


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.


– 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


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


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.


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.


• 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


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.


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.


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.


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:


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


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.


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,


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.


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]


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]


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.


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.


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


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


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.


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


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


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.


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


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.


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.


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.


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.


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


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.


• 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


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.


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


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



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 %


Implementación: 30 %

Pruebas: 15 %




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 %



Pruebas: 20 %



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 %



Pruebas: 30 %




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 %



Pruebas: 15 %




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 %



Pruebas: 10 %




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 %



Pruebas: 10 %


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



Pruebas: 60 %


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.


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.


• 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

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


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 ) ;

14 }

15 }

Listado 5.1: Extracto “ActionCargarMethodContent.java”


5.2.1.3 Pruebas

Para las pruebas en esta etapa temprana del desarrollo se realizaron distintas transformaciones

de elementos de la base de datos a modelos UMA en XML de modo que se fuera comprobando

de forma incremental (cada vez incluyendo más elementos de proceso) en la herramienta

EPFC.

En la presente etapa de la primera iteración únicamente se pudieron hacer pruebas de

serialización (Marshalling) y deserialización (UnMarshalling) de los distintos elementos en

el formato de intercambio seleccionado (XML), no obstante la importación del documento

elaborado mediante la serialización por parte de la herramienta EPFC requirió de pruebas

manuales para dar por finalizada esta etapa de Pruebas.

En el paquete “test” del proyecto desarrollado se encuentra una serie de pruebas en la que

un objeto es serializado y desserializado y se comprueba si los elementos antes y después

coinciden en número y en forma.

5.2.2 Iteración 2: Carga del Contenido de Método de EPFC a partir de

la BBDD ARMONÍAS-DGS

Al finalizar esta iteración podremos componer automáticamente un documento con todos y

cada uno de los elementos que recoge la base de datos de ARMONÍAS-DGS y su corres-

pondencia con el metamodelo UMA y obtendremos mediante la carga del fichero exportado

por EPFC los distintos procesos, junto con los elementos que lo definen para importarlos a

COMPROMISE.

A continuación se puede ver una imagen de la comparativa y cómo reconoce los procesos

definidos.


Figura 5.6: Comparativa de procesos COMPROMISE y EPFC

Cada proceso será un enlace a una página que nos proporcionará toda la información

acerca del mismo.


Como hemos mencionado, una parte fundamental para el desarrollo de esta iteración ha sido

el uso del Plug-in JAXB, descrito en el Capítulo 4.2.4.9.

En esta iteración corresponde integrar las funcionalidades de Marshalling y Unmarsha-

lling en la capa de dominio de la herramienta. Cabe destacar que para hacer uso de ambas

funcionalidades primero se deben tener todas las clases java que, con su serialización, com-

pondrán el documento XML. Hacer esto de manera artesanal sería muy tedioso y propenso

a errores, pues en la mayoría de los casos se trata de un número alto de clases con muchas

relaciones entre ellas, es por eso que el plugin dota a eclipse de mecanismos de generación

de código automático que modela las clases de dominio a partir del esquema (.xsd) y las

genera automáticamente, asegurando que la implementación de cada uno de los elementos es

conforme al metamodelo.


Figura 5.7: Generar Clases con JAXB

Una vez obtenidas las clases correspondientes a los distintos elementos del metamodelo

UMA, se hace necesario elaborar una estructura en forma de árbol que tendrá los componentes

y los procesos de la organización a tratar y que, por tanto, compondrán el documento en

cuestión. Hay que recordar que a pesar de hacer uso del metamodelo UMA, éste es compatible

con SPEM. Los elementos y su jerarquía se encuentran en la Figura 5.8:

Figura 5.8: Jerarquía de Elementos para la definición de Procesos en SPEM 2.0[10]


A continuación, en la Figura 5.9, se presenta el diagrama de clases de diseño corres-

pondiente a la funcionalidad de obtención de procesos de una organización por parte de

COMPROMISE. Una vez guardados los procesos de la organización que provienen del docu-

mento XML generado por EPFC (después de componer los procesos), éstos son cargados a la

base de datos de COMPROMISE, para posteriormente visualizarlos en la Web y poder operar

con ellos. Además de su obtención, el conocer los procesos de la organización será un paso

previo a operar con ellos en forma de gráficas, estadísticas, etc.

Figura 5.9: Diagrama de Diseño correspondiente a la obtención de Procesos de la Organización

Como enuncia la segunda iteración, además de la serialización y deserialización de ar-

chivos de intercambio (XML), corresponde a la presente iteración la integración de estas

funcionalidades en la arquitectura definida en la Fase de Inicio. En la Figura 5.10 podemos

observar un diagrama de la herramienta COMPROMISE integrada en el framework de Struts

2, haciendo uso del patrón Modelo-Vista-Controlador.


Figura 5.10: Diagrama General de la Herramienta con Struts2

A modo de esquema se presenta la Arquitectura definida integrada con el framework

Struts2, que permitirá desarrollar COMPROMISE de acuerdo a las políticas propias del patrón

MVC, proporcionando una serie de implementaciones (por ejemplo la clase ActionSupport)

que nos ayudan a hacer un uso correcto del paradigma en tres capas.


Figura 5.11: Estructura General Paquetes COMPROMISE


A continuación se representa un extracto de código representativo de la presente iteración.

En la Figura 5.2 se encuentra el código correspondiente a la función Marshaller (Sección

4.2.4.9) de JAXB a la que posteriormente dio lugar esta prueba de concepto, mientras que

en la Listado F.2 (en el apéndice de Código) se encuentra la implementación de la función

UnMarshaller (Sección 4.2.4.9).

1 JAXBContext c o n t e x t ;

2 t r y {

3 c o n t e x t = JAXBContext . n e w I n s t a n c e ( MethodLib ra ry . c l a s s ) ;

4 M a r s h a l l e r m a r s h a l l e r = c o n t e x t . c r e a t e M a r s h a l l e r ( ) ;

5 m a r s h a l l e r . s e t P r o p e r t y ( M a r s h a l l e r . JAXB_FORMATTED_OUTPUT, t r u e ) ;

67 F i l e W r i t e r f i l e = new F i l e W r i t e r ("./DB12.xml" ) ;

8 m a r s h a l l e r . s e t P r o p e r t y ( M a r s h a l l e r . JAXB_ENCODING,"ISO-8859-1" ) ;

910 m a r s h a l l e r . m a r s h a l ( method , f i l e ) ;

11 } c a t c h ( JAXBException e ) {

12 e . p r i n t S t a c k T r a c e ( ) ;

13 }

Listado 5.2: Ejemplo Marshall.


Como podemos observar en el código nos definimos un contexto JAXB (línea 3) con

la instancia que queremos que tenga como padre de las demás, en este caso es la clase

MethodLibrary. Después creamos un fichero, que será el que contendrá nuestro archivo XML

(línea 7) y por último, después de definir una serie de propiedades del objeto marshaller (línea

8), introducimos el contenido (method) en el fichero en la línea 10.

5.2.2.3 Pruebas

A continuación se presenta una prueba en la que el documento es compuesto y en el que es

creado bajo el nombre de fichero_test.xml. Se comprueba que una vez creado, éste existe y no

ha dado ningún problema. Será tarea de la herramienta EPFC encargarse de su validación, y

de esta manera comprobamos que es un fichero creado conforme al metamodelo UMA y que

todos sus elementos son pasados al contenido de método de la Librería de Método definida en

el documento.

1 MethodLib ra ry method = new MethodLib ra ry ( ) ;

2 JAXBContext c o n t e x t ;

3 t r y {

4 c o n t e x t = JAXBContext . n e w I n s t a n c e ( MethodLib ra ry . c l a s s ) ;

5 M a r s h a l l e r m a r s h a l l e r = c o n t e x t . c r e a t e M a r s h a l l e r ( ) ;

6 m a r s h a l l e r . s e t P r o p e r t y ( M a r s h a l l e r . JAXB_FORMATTED_OUTPUT, t r u e ) ;

78 F i l e f i l e = new F i l e ("./fichero_test.xml" ) ;

9 m a r s h a l l e r . s e t P r o p e r t y ( M a r s h a l l e r . JAXB_ENCODING,"ISO-8859-1" ) ;

10 m a r s h a l l e r . m a r s h a l ( method , f i l e ) ;

11 a s s e r t T r u e ( f i l e . e x i s t s ( ) ) ;

Listado 5.3: Test Composición XML.

5.2.3 Iteración 3: Implementación de las funciones para el Análisis de

Conformidad de Procesos

En esta iteración nos ocupará el establecimiento de un mecanismo que permita medir la

conformidad de los procesos de la organización respecto con un modelo de referencia. Se

pudo observar la cantidad de bibliografía que hay respecto al Compliance (Compromiso) en

los procesos de negocio, sin embargo observamos que no hay demasiada al respecto cuando a

procesos software nos referimos, tal como se ha descrito en el capítulo 3.

Es por eso que tras sucesivas reuniones, se determinó que uno o varios procesos tendrá

conformidad con un modelo si todas y cada una de las taras de éste último están correctamente


implementadas por la organización (o en su defecto un número alto previamente fijado antes

de la evaluación), además deberá disponer de todos los activos necesarios para su ejecución

satisfactoria (herramientas, roles que se ocupen de ciertas tareas, etc.).


A partir de aquí se planteó el problema de cómo lograr la correspondencia automática entre

tareas. Es por eso que se determinaron tres vías para resolverlo, presentadas a continuación:

• Mediante la comparación del nombre: El nombre de la tarea en el proceso de la

organización se debe corresponder íntegramente con el nombre de la tarea perteneciente

al modelo de referencia. Esta solución es idónea si se conservan los nombres (en nuestro

caso lo conservaría, pues la tarea con la que formamos el proceso en EPFC proviene del

modelo de referencia cargado a partir de la bbdd de ARMONÍAS-DGS.), no obstante

en el momento en que los nombres cambien no habrá correspondencia, aunque sea la

misma tarea.

• Comparación del id: Es una forma unívoca y muy útil, no obstante ocurrirá lo mismo

que con el anterior, si hay algún problema la detección de la correspondencia entre

ambas tareas fallará.

• Con un ratio definido del nombre y propiedades de la tarea: Proponer un ratio de

concordancia de nombre, de esta manera definiremos un umbral a partir del cual se

considera que una tarea corresponde con otra.

En un origen la herramienta da opción al uso de cualquiera de las tres posibilidades,

incluso a la selección de las tres (Figura 5.12). No obstante, conforme fue creciendo la

madurez del proyecto se determinó que estas funciones se reducirían a una sola en lo sucesivo,

únicamente comparandose el nombre en la continuación del desarrollo.


Figura 5.12: Prototipo de Interfaz para la visualización de la conformidad

A continuación se presentan dos diagramas correspondientes a la etapa de análisis y

diseño. Por un lado, en la Figura 5.13 corresponden a los pasos que sigue la herramienta para

obtener el análisis de conformidad de un proceso.

Figura 5.13: Diagrama clases de análisis para evaluar la Conformidad de Proceso

En la figura 5.14, se muestra el diseño de las clases que intervienen en la función de

Recomendador. Recordar que la función recomendador nos indica los elementos que nos

faltan para completar un marco de referencia (Tareas, Herramientas y Roles).


Figura 5.14: Diagrama Clases Recomendador

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.

Figura 5.15: Gráfica de Compliance total de la organizació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) ;

16 }

1718 }

Listado 5.4: Ejemplo clase Manager.


Para llevar a cabo la implementación de la función Recomendador es de vital importancia

haber hecho la de conformidad, pues en realidad se basa en ella. Es decir, para cada marco

de referencia extraemos las tareas que posee (de la BBDD de ARMONÍAS-DGS) y vamos

comparando todas y cada una de ellas con las de los procesos de la organización, de esta

forma se sabe en cada instante que porcentaje de tareas del marco de referencia están cubiertas

por la organización.

En la siguiente iteración, serán estas listas las que provean de datos a las gráficas para

representarlos.

5.2.3.3 Pruebas

En la etapa de pruebas correspondientes a la presente iteración elaboraremos casos de prueba

para la función recomendador. Como hemos enunciado con anterioridad, dicha función tiene

como objetivo proveer al usuario de aspectos por implementar para lograr la conformidad

con los marcos armonizados de procesos deseada. Estas pruebas han sido realizadas bajo

un entorno controlado y con procesos definidos previamente conociendo el resultado de los

valores analizados.

En el método setUp() que inicia el test de la Figura 5.5, se llama a funcion_recomendador(),

el cual debe retornar valores para las listas tareas_por_representar, roles_por_representar y

herramientas_por_representar. En la primera función de test llamada testCreacion() (líneas

8, 9 y 10) se comprueban que éstas hayan tomado los valores devueltos por la función

anterior. En el test denominado Insercion_correcta se comprueba que cumplen con los valores

establecidos de manera manual. Por último en el test generacion_reporte() se comprueba que

los métodos que devuelven en forma de cadena de caracteres los valores por implementar no

estén vacíos.


1 @Before

2 p u b l i c vo id se tUp ( ) {

3 f u n c i o n _ r e c o m e n d a d o r ( ) ;

4 }

56 @Test

7 p u b l i c vo id t e s t C r e a c i o n ( ) {

8 a s s e r t N o t N u l l ( t a r e a s _ p o r _ r e p r e s e n t a r ) ;

9 a s s e r t N o t N u l l ( r o l e s _ p o r _ r e p r e s e n t a r ) ;

10 a s s e r t N o t N u l l ( h e r r a m i e n t a s _ p o r _ r e p r e s e n t a r ) ;

11 }

1213 @Test

14 p u b l i c vo id I n s e r c i o n _ c o r r e c t a ( ) {

15 a s s e r t T r u e ( t a r e a s _ p o r _ r e p r e s e n t a r . s i z e ( ) ==25) ;

16 a s s e r t T r u e ( r o l e s _ p o r _ r e p r e s e n t a r . s i z e ( ) ==3) ;

17 a s s e r t T r u e ( h e r r a m i e n t a s _ p o r _ r e p r e s e n t a r . s i z e ( ) ==1) ;

18 }

1920 @Test

21 p u b l i c vo id g e n e r a c i o n _ r e p o r t e ( ) {

22 a s s e r t N o t E q u a l s ( T a r e a s _ p a r a _ I n f o r m e ( ) , "" ) ;

23 a s s e r t N o t E q u a l s ( H e r r a m i e n t a s _ p a r a _ I n f o r m e ( ) , "" ) ;

24 a s s e r t N o t E q u a l s ( R o l e s _ p a r a _ I n f o r m e ( ) , "" ) ;

25 }

Listado 5.5: Test Función Recomendador.

5.2.4 Iteración 4 : Implementación de Módulo de Representación gráfi-

ca de estadísticas.

En esta iteración se pretende dotar a la herramienta de mecanismos de representación de los

niveles de conformidad de los distintos procesos que posee la organización. Es por eso que se

hace necesario implementar gráficas dinámicas para la representación de dichos datos.

Para ello hemos hecho uso de la librería Chart de JavaScript. Esta librería, basada en

HTML 5, nos permite crear gráficos como los de las figuras 5.16 y 5.17.


Figura 5.16: Ejemplo gráfica Barras de Compliance

Figura 5.17: Ejemplo gráfica Área de Compliance

En las figuras anteriores, el color rojo representa el porcentaje de tareas del proceso que

forman parte del marco de referencia con el que se comparan (color azul). En el ejemplo po-

demos ver como el proceso “Preparar Documentación” no tiene ninguna tarea implementada

(del marco de referencia con el que comparamos), mientras que el proceso de “Pruebas” sí

que las tiene. Como hemos mencionado antes el color azul representa el ratio de aceptación

en el que se considera que un proceso cumple con el estándar. Dicho ratio será definido por el

usuario en un panel de selección implementado en una iteración posterior.


Por último se planteó la automatización de generación de documentos PDF con los

resultados de la función recomendador de la iteración anterior. En la parte de implementación

de esta iteración, en la Figura 5.6, podemos ver parte del código que se encarga de este

cometido. A modo de ejemplo se incluirá en el proyecto un archivo de ejemplo de esta función

que recogerá a modo de lista los elementos implementados y los que restan de implementar

para que la conformidad con el marco de procesos sea plena.


A continuación se presenta un diagrama de diseño, en la figura 5.18 en la que se puede ver

la nueva funcionalidad añadida de Generar Informe. Esta función hará uso de la función

Recomendador expuesta en la iteración anterior.

Figura 5.18: Diagrama de clases de Diseño Generar Informe


En la Figura 5.19 se incluye un diagrama de análisis que expresa la arquitectura de la

función recomendador, así como de la extracción de informes mencionada con anterioridad.

En la etapa de análisis de la presente iteración se determinó la extracción de dicho documento

con el fin de lograr el desacoplamiento entre la información proporcionada y COMPROMISE,

pues de esta forma ésta será portable, posibilitando la transmisión de conocimiento entre

los miembros de la organización y ofreciendo la posibilidad de la persistencia en distintos

momentos de evaluación de la conformidad de procesos.

Figura 5.19: Diagrama de clases de Análisis para generar PDF[10]



A continuación, en la figura 5.6 se presenta una simplificación, a modo ilustrativo, de la función

automática para la generación automática de informes PDF. Los datos que representaremos

en el informe real vendrán determinados por la salida de la función recomendador.

1 p u b l i c S t r i n g r e a l i z a r I n f o r m e ( ) {

23 t r y {

4 Outpu tS t r eam f i l e = new F i l e O u t p u t S t r e a m ( new F i l e ("C:\\Test.pdf" ) ) ;

5 Document document = new Document ( ) ;

6 P d f W r i t e r . g e t I n s t a n c e ( document , f i l e ) ;

7 document . open ( ) ;

8 S t r i n g t a r e a s = Log inAc t ion . T a r e a s _ p a r a _ I n f o r m e ( ) ;

9 document . add ( new P a r a g r a p h ( t a r e a s ) ) ;

10 document . c l o s e ( ) ;

11 f i l e . c l o s e ( ) ;

1213 } c a t c h ( E x c e p t i o n e )

Listado 5.6: Código de generación de documentos PDF.

Como hemos mencionado en el capítulo de Objetivos del presente TFG, COMPROMISE

también sirve de nexo entre distintas herramientas. A parte de ARMONÍAS-DGS, integrada

en la primera iteración, COMPROMISE necesita de otras tres para completar su funciona-

lidad, MediniQVT, EPFC y Eclipse BPMN Modeler. Parte de esa integración consiste en

la transmisión de los datos mediante archivos de intercambio (los mencionados XML), no

obstante se desea interactuar con las herramientas anteriormente nombradas y es por eso que

a partir de la presente podrán ejecutarse desde el menú principal de COMPROMISE.

Sin embargo se hace necesario conocer las rutas en las que éstas están ubicadas (las herra-

mientas estarán incluidas en el proyecto), en esta iteración corresponde la implementación

de esta funcionalidad, dejando los formularios de introducción en iteraciones posteriores.

Hay que tener en cuenta que las herramientas mencionadas deben mantener la jerarquía de

carpetas proporcionadas, pues las rutas de los espacios de trabajo (Workspace) de cada una de

ellas serán determinantes a la hora de lograr una ejecución satisfactoria. A pesar de que casi

la totalidad de la funcionalidad respecto a la invocación de las herramientas es completada en

esta iteración, corresponde a las últimas etapas elaborar el formulario correspondiente para la

introducción automática de las rutas.


5.2.4.3 Pruebas

En esta etapa de la iteración se probará la generación de documentos PDF. En la Figura 5.7 se

muestra una parte del código relativo a esta función.

1 p u b l i c vo id t e s t ( ) t h r ow s DocumentExcept ion , IOExcep t ion {

2 S t r i n g r u t a = n u l l ;

3 S t r i n g s S i s t e m a O p e r a t i v o = System . g e t P r o p e r t y ("os.name" ) ;

45 Document document = new Document ( ) ;

6 Outpu tS t r eam f i l e ;

78 f i l e = new F i l e O u t p u t S t r e a m ( new F i l e ("C:\\Test.pdf" ) ) ;

9 P d f W r i t e r . g e t I n s t a n c e ( document , f i l e ) ;

10 document . open ( ) ;

1112 S t r i n g t a r e a s = RecomendadorAct ion . T a r e a s _ p a r a _ I n f o r m e ( ) ;

13 S t r i n g h e r r a m i e n t a s =RecomendadorAct ion . H e r r a m i e n t a s _ p a r a _ I n f o r m e ( ) ;

14 S t r i n g r o l e s = RecomendadorAct ion . R o l e s _ p a r a _ I n f o r m e ( ) ;

1516 document . add ( new P a r a g r a p h ("Informe de Compliance del Modelo" ) ) ;

17 document . add ( new P a r a g r a p h ( t a r e a s ) ) ;

18 document . add ( new P a r a g r a p h ( h e r r a m i e n t a s ) ) ;

19 document . add ( new P a r a g r a p h ( r o l e s ) ) ;

2021 document . c l o s e ( ) ;

22 f i l e . c l o s e ( ) ;

2324 a s s e r t T r u e ( s S i s t e m a O p e r a t i v o . c o n t a i n s ("Windows" ) ) ;

25 a s s e r t F a l s e ( t a r e a s . e q u a l s I g n o r e C a s e ("" ) ) ;

26 a s s e r t F a l s e ( h e r r a m i e n t a s . e q u a l s I g n o r e C a s e ("" ) ) ;

27 a s s e r t F a l s e ( r o l e s . e q u a l s I g n o r e C a s e ("" ) ) ;

2829 }

Listado 5.7: Test salida documento PDF.


5.2.5 Iteración 5: Integración de la capa de Persistencia con COMPRO-

MISE

Los modelos de referencia (armonizados y no armonizados) se encuentran en la base de datos

de ARMONÍAS-DGS y mediante la función Cargar Contenido de Método, COMPROMISE

permite representar este conocimiento en lenguaje XML para que pueda ser procesado por

herramientas como EPFC. Un paso posterior será definir los procesos con el contenido impor-

tado y guardar dichos procesos en otro archivo de intercambio XML para cargar los procesos

en COMPROMISE. En el momento en el que esto ocurre poblaremos nuestra base de datos

con los procesos que no tengamos guardados de cargas de archivos anteriores. El diagrama

que se muestra en lo sucesivo a este apartado (Figura 5.23) pertenece a la base de datos de la

herramienta.

A continuación se muestra un ejemplo de la estructura de un proceso definido mediante

EPFC, ésta puede tener iteraciones, actividades, fases, etc. con relaciones entre ellas. Este

tipo de relaciones se ven plasmadas en el modelo de base de datos propuesta y son recogidas

en el momento de carga del documento intercambiado en COMPROMISE.

Figura 5.20: Ejemplo de Proceso definido con EPFC

En la siguiente imagen se puede ver la composición jerárquica de un proceso definido en

EPFC. Cabe destacar que la necesidad de la base de datos radica, además de almacenar los

datos relativos a las organizaciones, en dar cabida al nuevo tipo de definición de proceso, pues


por ejemplo un proceso puede estar definido por una fase, que a su vez contiene a otra, y ésta

una actividad que contiene a otra. Mediante la jerarquía definida en el diseño de la base de

datos de ARMONÍAS-DGS, almacenar el proceso con todos sus elementos en árbol no es

posible.

Figura 5.21: Descomposición Proceso

Otro objetivo a abordar dentro de esta iteración es la gestión de nuevos usuarios, nuevas

herramientas, nuevos roles a la hora de abordar tareas, etc. Esta problemática se soluciona

mediante una interfaz visible al administrador de la organización y al de la herramienta, en la

que es posible introducir roles, herramientas, activos, nuevos usuarios y nuevas organizaciones.

A continuación, en la figura 5.22, se muestra un ejemplo de alta de usuario:

Figura 5.22: Alta de Usuario

Una parte fundamental de esta iteración será la utilización del ORM Hibernate, que nos

permitirá abstraernos de la complejidad que supone el almacenamiento de cada uno de los


atributos de las clases utilizadas para representar los elementos de COMPROMISE (procesos,

iteraciones, hitos, etc.).

Por último al finalizar la presente iteración deberemos obtener las funcionalidades de

subida y bajada de archivos al servidor, para el posterior procesamiento de los mismos. El

usuario dispondrá de una ventana que permita la selección de archivos de subida así como de

rutas en las que se guardarán los archivos procesados que provienen del servidor.


Como podemos ver a continuación, la base de datos guarda todos los usuarios de la herra-

mienta, así como las organizaciones junto con todos sus activos (considerando los procesos y

todos sus elementos relacionados también como tal) e históricos de conformidad. Además, en

lo relativo a las funciones de conformidad, todos los procesos junto con sus elementos son

almacenados en ella. Cabe destacar que esta base de datos se usa para tareas de representación

de elementos en la herramienta, labores de análisis de conformidad con los marcos de procesos

persistentes en la base de datos de ARMONÍAS-DGS, obtención de procesos a la hora de

realizar transformaciones entre modelos mediante el paradigma de DSDM y elaboración de

informes.

CA

PÍTU

LO

5.R

ESU

LTAD

OS:H

ER

RA

MIE

NTA

CO

MPR

OM

ISE113

User

idUser INT

name VARCHAR(100)

Role VARCHAR(100)

Password VARCHAR(45)

Organization_name V…

Indexes

Organization

name VARCHAR(100)

address VARCHAR(200)

telephone VARCHAR(45)

logo_url VARCHAR(300)

IndexesProcess

idProcess INT

name VARCHAR(100)

description VARCHAR(…

purpose VARCHAR(600)

objectives VARCHAR(6…

Quality_model_name V…

Indexes

Organization_has_Process

Organization_name VARCHAR(100)

Process_idProcess INT

Indexes

Quality_model

name VARCHAR(200)

purpose VARCHAR(500)

approach VARCHAR(500)

Indexes

Task

idTask INT

name VARCHAR(300)

description VARCHAR(800)

Activity_idActividad INT

Fase_idFase INT

Iteracion_idIteracion INT

1 more...

Indexes

Work_Product

idWork_Product INT

name VARCHAR(200)


features INT

Task_idTask INT

Indexes

Role

idRole INT

name VARCHAR(200)


type VARCHAR(200)

skills VARCHAR(800)

capabilities VARCHAR(800)


Indexes

Tool

idTool INT

name VARCHAR(300)



Indexes

Activo

idActivo INT

name VARCHAR(300)


value INT


Indexes

Iteracion

idIteracion INT

name VARCHAR(250)




Indexes

Fase

idFase INT

name VARCHAR(200)



1 more...

Indexes

Activity

idActividad INT

nombre VARCHAR(45)

descripcion VARCHAR(45)



Fase_idFase INT


Indexes

historico_compliance

idhistorico_compliance INT

porcentaje VARCHAR(45)

observaciones VARCHAR(700)


Quality_model_name VARCHAR(200)

Indexes

Milestone

idMilestone INT




Fase_idFase INT


Indexes

Figura 5.23: Diagrama de base de datos de COMPROMISE


A continuación, en la Figura 5.24 se adjunta la parte de la definición de la base de datos de

la herramienta ARMONÍAS-DGS que utilizaremos. Como podemos ver, aunque hay algunas

similitudes, las diferencias son notables:

Figura 5.24: Simplificación BBDD Armonias-DGS

Otra parte importante del desarrollo que tiene cabida en la presente iteración es el menú

de administración. Éste, como hemos comentado, será oculto al rol de gestor de procesos y

permitirá introducir nuevos usuarios, activos, herramientas y roles, en caso de que el rol del

usuario sea el correcto permitirá añadir nuevas organizaciones a nuestro proyecto, cambiar las

rutas de las herramientas relacionadas con COMPROMISE, además de seleccionar el grado

de aceptación de cada proceso por separado para su posterior visualización en las gráficas del

panel principal. Esta última funcionalidad se ilustra con la Figura 5.25.


Figura 5.25: Selección márgen de aceptación para Proceso


Como hemos mencionado en el Capítulo 4, para lograr la persistencia de nuestros elementos

se ha optado por el ORM Hibernate. Esta herramienta permite insertar objetos directamente,

asumiendo éste las funciones del establecimiento de la correspondencia entre los atributos

del objeto en cuestión y de la base de datos. Para nuestra herramienta se han definido

previamente estos objetos como clases .java indicándole a hibernate los distintos atributos

que deseamos incluir mediante anotaciones presentes en la librería javax.persistence. A

continuación, en la Figura 5.8 se presenta una parte del código relativo la persistencia de un

Proceso. Todas las clases que necesitan de funciones de almacenamiento se encuentran en el

paquete hibernate.model.

1 @Id

2 @GeneratedValue

3 @Column ( name="idActivo" )

4 p u b l i c i n t g e t I d A c t i v o ( ) {

5 r e t u r n i d A c t i v o ;

6 }

7 @Column ( name="name" )

8 p u b l i c S t r i n g getName ( ) {

9 r e t u r n name ;

10 }

11 @Column ( name="description" )

12 p u b l i c S t r i n g g e t D e s c r i p t i o n ( ) {

13 r e t u r n d e s c r i p t i o n ;

14 }

15 @Column ( name="value" )

16 p u b l i c S t r i n g g e t V a l u e ( ) {

17 r e t u r n v a l u e ;

18 }

19 @Column ( name="Organization_name" )

20 p u b l i c S t r i n g g e t O r g a n i z a t i o n _ n a m e ( ) {

21 r e t u r n o r g a n i z a t i o n _ n a m e ;

22 }

Listado 5.8: Persistencia objeto Proceso.

Además, como mencionábamos en la sección anterior, al término de esta iteración se

tendrá una versión funcional de la herramienta con la funcionalidad de subida y bajada de

archivos al servidor. Para llevar a cabo esta función deberemos hacer usos de los mecanismos

que Struts2 nos ofrece. Para ello deberemos configurar un interceptor que se ejecutará antes

de la acción correspondiente, en el que definiremos las propiedades que el archivo deba tener.

El ejemplo de este interceptor se ilustra en el Listado 5.9.

1 < a c t i o n name="resultAction" c l a s s ="actions.FileUploadAction">

2 

3 

4 

5 <param name="allowedTypes"> t e x t / xml< / param>

6 <param name="maximumSize">102400< / param>

7 

8 

9 <param name="excludeMethods"> i n p u t < / param>

10 

11 < r e s u l t t y p e ="redirectAction"> c a r g a r _ n u e v o s P r o c e s o s < / r e s u l t >

12 < / a c t i o n >

Listado 5.9: Ejemplo Interceptor.

5.2.5.3 Pruebas

En la etapa de pruebas de esta iteración se han probado funcionalidades relativas a las bases

de datos de COMPROMISE y de la herramienta ARMONÍAS-DGS. Un extracto del código

de las pruebas (Listado 5.10) presenta la inserción de un nuevo Rol en nuestra herramienta.


1 p u b l i c c l a s s G e s t i o n A c t i v o s {

23 @Test

4 p u b l i c vo id NuevaHer ramien ta ( ) {

5 h i b e r n a t e . c o n t r o l l e r . ToolManager t o o l _ m a n a g e r = new ToolManager ( ) ;

6 h i b e r n a t e . model . Tool t o o l = new Tool ("prueba" , "prueba" , "CMMI-DEV 1.3" , "Organisoft" ) ;

7 t o o l _ m a n a g e r . add ( t o o l ) ;

8 a s s e r t T r u e ( t o o l _ m a n a g e r . e x i s t s _ b y _ n a m e ("prueba" ) ) ;

9 }

10 @Test

11 p u b l i c vo id NuevoRol ( ) {

12 h i b e r n a t e . c o n t r o l l e r . RoleManager r o l _ m a n a g e r = new RoleManager ( ) ;

13 h i b e r n a t e . model . Role r o l e _ a u x = new Role ("prueba" , "prueba" , "prueba" , "prueba" , "prueba" , "Organisoft

" ) ;

14 r o l _ m a n a g e r . add ( r o l e _ a u x ) ;

15 a s s e r t T r u e ( r o l _ m a n a g e r . e x i s t _ r o l e ( r o l e _ a u x ) ) ;

16 a s s e r t T r u e ( r o l _ m a n a g e r . e x i s t s _ b y _ n a m e ("prueba" ) ) ;

17 }

18 @Test

19 p u b l i c vo id NuevoUsuar io ( ) {

20 h i b e r n a t e . c o n t r o l l e r . UserManager use r_manage r = new UserManager ( ) ;

21 h i b e r n a t e . model . User u s e r = new User ("prueba" , "pruebas" , "pruebas" , "Organisoft" ) ;

22 use r_manage r . add ( u s e r ) ;

23 a s s e r t T r u e ( use r_manage r . g e t U s e r O r g a n i z a t i o n ("prueba" ) . e q u a l s ("Organisoft" ) ) ;

2425 }

26 }

Listado 5.10: Test Nuevo Rol.

5.2.6 Iteración 6: Definir transformación entre los metamodelos UMA

y BPMN

En esta iteración abordamos el componente de transformación entre los modelos UMA y

BPMN. Como hemos mencionado en capítulos anteriores, haremos uso del framework Medini

QVT para realizar la transformación. Se harán necesarios los metamodelos UMA y BPMN

con extensión .ecore. Este último metamodelo tiene una estrecha relación con otros tres, que

son DI.ecore (parte de los diagramas), DC.ecore (parte de propiedades) y BPMNDI.ecore

(recoge aspectos organizacionales de los anteriores).

Además se aborda el validador de sesión de usuario que, si éste no se ha identificado

no podrá ejecutar ninguna acción de la herramienta, remitiendo al usuario a la página de

inicio, en la que se tendrá que identificar para hacer uso de ella. Para el validador de usuario

es imprescindible haber logrado la completitud de la anterior iteración, pues será sobre la

persistencia que ofrece la tecnología Hibernate sobre la que se apoyará esta función.


Por último otro producto de trabajo importante será la introducción de un menú interactivo

[5] por el cual el usuario podrá seleccionar las distintas opciones que posee COMPROMISE

de forma intuitiva y atractiva, con efectos visuales que permiten una mejor experiencia para el

usuario. Los efectos del mismo están implementados bajo la tecnología de JQuery.

Figura 5.26: Menú de Selección COMPROMISE


En la Figura 5.27 podemos observar el flujo de clases y métodos que sigue el usuario de

COMPROMISE para lograr una transformación entre los modelos UMA y BPMN2.0. Para

ello, primero deberemos crear un documento (que obtendrá la herramienta MediniQVT)

que recoja todos los procesos de la organización. Una vez hecho esto, deberemos ejecutar

MediniQVT como ilustra el manual de instalación y ejecutar la transformación.


Figura 5.27: Diagrama de Análisis para la función de Transformación entre Modelos

Como salida de este procesamiento tenemos un fichero con extensión .bpmn cuyo objetivo

es la representación en el framework BPMN Modeler. Antes de lograr este fin deberemos

realizar un posprocesamiento (automatizado mediante COMPROMISE) del mismo, pues

aunque prácticamente la totalidad de los motores de procesos son conformes al metamodelo

BPMN, cada uno los representa con un formato distinto, es es por eso que se deberá definir una

estructura a partir del metamodelo BPMN mediante JAXB Este posprocesamiento convierte

un conjunto de tareas de un proceso software, en un proceso de negocio, con una precedencia

entre tareas y con un evento de principio y fin. A continuación se plantean dos vistas, la

primera con la estructura jerárquica tanto del proceso en cuestión como de su representación

gráfica.

Figura 5.28: Ejemplo de estructura deproceso definida con EPFC en la herramienta BPMN2

Modeler


En la siguiente Figura se presenta una imagen con las tareas del proceso de negocio a

modo de cascada y con un evento de inicio y otro de fin.

Figura 5.29: Ejemplo proceso BPMN


Un artefacto de salida de esta iteración es el código de la transformación, expuesto en lo

sucesivo. Hay que mencionar que se ha realizado una transformación únicamente de tareas,

pues determinar la correspondencia de elementos entre ambos metamodelos es una tarea que

escapa al alcance del presente Trabajo de Fin de Grado, proponiéndose como trabajo futuro.

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)

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

herramienta.


Figura 5.30: Iconos de Cambio de Idioma


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.


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

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

g e t ("user" ) ;

16 i f ( u s u a r i o == n u l l ) {

17 r e t o r n o =NONE;

18 } e l s e {

19 t r y

20 {

21 Runtime app = Runtime . ge tRun t ime ( ) ;

22 app . exec ("C:\\Users\\Victor\\Desktop\\mediniQVT\\mediniQVT.exe" ) ;

23 r e t o r n o = SUCCESS ;

24 }

25 }

26 r e t u r n r e t o r n o ;

27 }

28 }

Listado 5.15: Ejecución Medini-QVT.

Además, como hemos dicho antes, pertenece a esta iteración implementar la funcionalidad

relativa al cambio de idiomas. Struts2 provee al desarrollador de funciones que facilitan tal fin

mediante diccionarios. En las figuras 5.16 y 5.17 se puede ver como se definen las variables a

utilizar por toda la herramienta. Será una variable global la que considere el idioma a utilizar,

cambiando dicha variable mediante los botones de la Figura 5.30.


1 title=tip 11 - i18n

2 user = Usuario

3 pdw = Contraseña

4 login = Entrar

5 compliance = Conformidad

6 transformaciones = Transformaciones

Listado 5.16: Diccionario Español.

1 title=tip 11 - i18n

2 user = User

3 pdw = Password

4 login = Login

5 compliance = Compliance

6 transformaciones = Transformations

Listado 5.17: Diccionario Inglés.

5.2.7.3 Pruebas

Por su extensión de código y como teniendo como objetivo facilitar la lectura del documento

las pruebas pertenecientes a esta iteración se encuentran en el paquete test del código de la

herramienta proporcionado junto a la documentación. Cabe destacar que COMPROMISE se

ha probado en los navegadores Google Chrome, Firefox e IExplorer.

5.3 Fase de Transición

Como hemos comentado en esta sección, la fase de Transición tendrá como objetivo la entrega

de la herramienta operativa al usuario final y su despliegue en el entorno real. Es por eso que

en el presente trabajo no se tratará como ésta requeriría en el caso de que la aplicación fuese

probada en una organización.

126 5.4. PATRONES DE DISEÑO

5.4 Patrones de Diseño

A continuación se presentan una serie de patrones utilizados en el desarrollo de la herramienta

COMPROMISE:

5.4.1 Modelo-Vista-Controlador

El patrón Modelo-Vista-Controlador o Model-View-Controller [29] en inglés, permite separar

los datos y la lógica de negocio de la interfaz. Este desacoplamiento permite, por ejemplo,

cambiar aspectos de la vista sin que afecte a ninguna de las otras dos capas. Este patrón

de arquitectura software tiene como objetivos evitar la repetición de código y facilitar el

mantenimiento posterior.

A continuación se representa un esquema del patrón MVC:

Figura 5.32: Esquema del Patrón MVC


5.4.2 Singleton

El patrón Singleton está diseñado para impedir que en una clase exista más de un objeto

instanciado de un tipo determinado, de esta manera se asegura un punto de acceso único

y global. A continuación se proporciona un extracto del código que hace uso del patrón

Singleton:

1 public String[] getProcesos_nombre_compliance() {

2 if(procesos_nombre_compliance == null){

3 procesos_nombre_compliance = new String[procesos.size()];

4 }

5 return procesos_nombre_compliance;

6 }

Listado 5.18: Extracto de código del Patrón Singleton

En nuestro caso el ejemplo de la aplicación del patrón consiste en la creación de una lista

de procesos. Mediante el método getProcesos_nombre_compliance() accedemos a la variable

creada, si no está inicializada se inicializa y devuelve dicha variable, en caso de que ya esté

inicializada únicamente la devolverá sin otra acción previa. De esta manera nos aseguramos

que ésta sea única.

5.4.3 DAO

Es uno de los patrones más importantes de cara a la persistencia de datos. Se trata de una clase

intermedia entre la capa de modelo y la de persistencia, que en nuestro caso hemos llamado

Manager, que se encarga de proporcionar a cada objeto las operaciones CRUD Create, Read,

Update y Delete necesarias. Por tanto cada objeto que sea persistente en memoria deberá

implementar el patrón DAO.

Este patrón permite modelas las operaciones para administrar una entidad de información.

Permite al desarrollador aumentar la productividad, ya que aumenta el nivel de abstracción y

éste únicamente hace uso de las operaciones proporcionadas sin preocuparse de sentencias

SQL evitando así la repetición de trabajo y el sistema resultante será menos propenso a errores.

Un ejemplo de la aplicación del DAO se encuentra el apéndice correspondiente (F.1).

Capítulo 6

Conclusiones y Propuestas

En este capítulo se exponen las conclusiones tras el desarrollo de este Trabajo de Fin de Grado.

Se determina el grado de cumplimiento de los objetivos definidos en el inicio del proyecto

(Capítulo 2), se incluyen algunas propuestas de trabajo futuro que amplían los resultados del

presente y se proporciona la opinión personal del autor tras la realización del presente TFG.

6.1 Conclusiones

Como resultado de este desarrollo se han conseguido satisfacer todos los objetivos propuestos

en un origen, presentados en el Capítulo 2.

Entre los objetivos cumplidos destacan por su importancia; la dotación de contenido de

método a la herramienta EPFC desde la base de datos de ARMONÍAS-DGS, el cambio de pa-

radigma de un proceso contemplativo a uno productivo, el soporte al análisis de Conformidad

de Procesos Software así como la salida de informes, y la transformación model-to-model

para la representación y futura ejecución de Procesos Software en un motor de procesos.

El contenido de método proporcionado a la herramienta EPFC a partir de la BBDD de

ARMONÍAS-DGS supone el primer paso para la conversión de los procesos de la organiza-

ción a procesos productivos, permite a las empresas almacenar su conocimiento en forma de

contenido de método para reutilizarlo en la futura composición de procesos, aprovechando

la ventaja sustancial para la organización que supone la reutilización de los elementos del

proceso a la hora de componerlo, evitando el trabajo repetitivo que supondría la definición de

éstos cada vez que tiene lugar la etapa de modelado (Capítulo 3).

Además, siguiendo el paradigma de la transformación a procesos productivos, la trans-

130 6.1. CONCLUSIONES

formación model-to-model proporciona una ventaja competitiva a las organizaciones que la

implementen, pues tendrán la posibilidad de ejecutar sus procesos y simularlos, detectando

los fallos de éstos como puedan ser los cuellos de botella, permitiendo la experimentación

con el sistema simulado sin interrumpir la actividad el sistema real evitando los daños reales

resultantes de una mala implementación.

Por otro lado y centrados en el objetivo principal del presente TFG, la organización que

haga un correcto uso de la herramienta obtendrá valores cuantificados del estado de sus

procesos y los distintos elementos que conforman su implementación, de una manera clara e

intuitiva que son capaces de proporcionar las distintas gráficas de los informes que facilita

COMPROMISE. Además, cuando tenga lugar la evaluación, la organización no tendrá que

preocuparse de si está tratando un estándar reconocido por los organismos oficiales, como

pueda ser ISO, o uno resultante de la armonización de éstos, pues gracias al paradigma de

Pardo [53] y a la herramienta ARMONÍAS-DGS [61] estos aspectos son transparentes a la

organización.

Otra de las ventajas que provee COMPROMISE a las organizaciones es la visualización

de los procesos de la organización además de todos los componentes que los conforman y

la función de recomendador que provee a las organizaciones de una serie de sugerencias

que indicarán los recursos necesarios para implementar las mejoras para lograr las futuras

certificaciones. Además se reducirán en gran medida las labores de consultoría previas a la

certificación, pues una organización podrá conocer en tiempo real el estado de sus procesos y

en caso necesario, obtendrá un informe con los elementos por implementar necesarios para su

perfeccionamiento.

Por último mencionar que la metodología utilizada para el proceso de desarrollo de la

herramienta objeto de este trabajo de fin de grado, OpenUP se adapta perfectamente a este

tipo de desarrollos, pues está pensada para equipos de desarrollo pequeños y por tanto no se

centra en aspectos propios de metodologías que soportan la coordinación de un gran equipo

de desarrollo. La explicación de dicha metodología se encuentra en la Sección 4.1.

CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS 131

6.1.1 Propuestas de trabajos futuros

En esta sección se proponen posibles mejoras y ampliaciones de la herramienta. A continua-

ción se indican posibles propuestas de trabajo futuro.

• Estudio exhaustivo entre la correspondencia de Proceso Software y Proceso de

Negocio. Establecer la equivalencia entre los conceptos de los distintos tipos de proce-

sos no es tarea fácil. Es por eso que como trabajo futuro se propone la realización de

un estudio minucioso, como ejemplo se propone la lectura de [55], entre los distintos

metamodelos para establecer una transformación sin perder semántica, pues la trans-

formación propuesta en el presente TFG es una solución acotada por los margenes de

tiempo propios de la naturaleza del mismo y focalizar el esfuerzo en este cometido

habría supuesto la imposibilidad de la realización de otras funcionalidades.

• Menú de gráficas y resultados personalizable. Sería muy útil para las organizaciones

personalizar su cuadro de mando, las gráficas que representan el estado de sus procesos,

el nivel de detalle de presentación de los elementos de los mismos, así como cualquier

aspecto que se considere relevante y que influya en la presentación de los datos.

• Analizar y aplicar otros mecanismos avanzados para analizar la conformidad. En

nuestro caso de estudio se ha establecido una correspondencia Tarea a Tarea entre los

procesos de la organización y los procesos estandarizados de los marcos de trabajo.

Aunque es una aproximación válida, sería interesante establecer unas políticas mucho

más rigurosas de medición que ponderen ciertos aspectos de implementación, tales como

el orden de las tareas, tiempos, calidad de las herramientas, históricos de productividad

en distintas tareas, etc. Por ejemplo en [50] se propone una extensión del metamodelo

SPEM que recoge una serie de pautas que determinan la calidad del conocimiento

del Proceso Software mediante una serie de métricas, categorizando y ponderando las

tareas a partir del conocimiento que le aportan los elementos relacionados con la misma

(roles, herramientas, productos de trabajo, etc.). De esta manera se puede definir un

valor que puede determinar la concordancia entre dos o más tareas.

• Automatización de la Transformación propuesta entre UMA y BPMN. Actualmen-

te se realiza haciendo uso del Plug-in de Medini QVT. Aunque se han probado a realizar

132 6.1. CONCLUSIONES

en la herramienta labores de transformación internas utilizando librerías proporcionadas

por Medini-QVT, las restricciones temporales han impedido la automatización de dicha

transformación. Será interesante incorporar estos mecanismos en un trabajo futuro

6.1.2 Opinión Personal

Una vez desarrollado el presente TFG he de decir que las experiencias obtenidas han sido

satisfactorias. Claramente dos aspectos que en un origen consideraba muy distantes, el marco

teórico y la tecnología, a medida que el desarrollo iba avanzando se volvieron complemen-

tarios. Ha sido el tiempo, junto con el estudio de la materia, lo que me ha proporcionado la

mejor de las perspectivas para darme cuenta de que todo tiene relación y que el apoyo de las

distintas áreas de la Informática así como de los campos relacionados con la materia, son

vitales para lograr ser competitivos en el mundo laboral a la hora de desarrollar productos de

calidad.

Por una parte el trabajo desarrollado me ha servido tanto para adquirir nuevos conceptos

de Ingeniería del Software como para afianzar y profundizar en los que tenía. Conceptos como

metamodelo, transformación, metalenguaje o MDE eran extraños en un origen y difícilmente

pensaba en una aplicación de los mismos en el entorno empresarial. A su vez he podido

conocer un sinfín de herramientas en las que se apoyan y olvidar el hecho de que “cuando

tenemos un martillo, todo son clavos”, aceptar que hay varias soluciones para un mismo

problema y que el conocimiento de los aspectos relativos a la organización en un proyecto es

fundamental a la hora de cumplir los objetivos propuestos.

Uno de los conceptos adquiridos que me gustaría conocer en profundidad son las distintas

visiones de los procesos, pues a mi parecer creo que el paso de una visión puramente consulti-

va a una visión productiva que permita en gran medida la automatización de la gestión del

proceso es muy interesante.

Por otro lado se han afrontado una serie de competencias técnicas que nunca antes habían

tenido lugar, desarrollo web, lenguajes de transformación, cómo lograr la conformidad de pro-

cesos, paso de información entre herramientas, conocimiento de estándares. Han sido muchas

las tecnologías empleadas para la herramienta y aún más las que existen para proporcionar

CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS 133

soluciones seguramente mejores que las propuestas en el presente documento. Darme cuenta

de que, a pesar de los conocimientos adquiridos en estos últimos años, queda un abismo por

aprender y es eso lo que motiva el estudio continuo y alimenta las ganas de seguir avanzando.

Por último mencionar que, según mi criterio, la realización de un Trabajo de Fin de Grado

es fundamental para terminar satisfactoriamente la primera etapa de un Informático, pues

proporciona una visión de conjunto que únicamente ofrece un trabajo terminado. Permite

darse cuenta de que la palabra Ingeniería no aparece por casualidad en el título del diploma y

que tampoco consiste en sistematizar de una serie de pasos para resolver un problema, sino

que supone la responsabilidad de dar soluciones a cuestiones que aún no han sido resueltas y

es bajo esta premisa cuando el término tiene sentido.

Ciudad Real, a 1 de Diciembre del 2014

Fdo.: Víctor Parrado López

Bibliografía

[1] Apache foundation. http://apachefoundation.wikispaces.com/

Apache+Tomcat, Último acceso 20-12-2013.

[2] Bibtex. http://www.bibtex.org, Último acceso 04-04-2014.

[3] Bitbucket. https://bitbucket.org, Último acceso 29-05-2014.

[4] Bpmn modeler. http://eclipse.org/bpmn2-modeler/, Último acceso 27-

03-2014.

[5] Bubble navigation template. http://tympanus.net/Tutorials/

BubbleNavigation/, Último acceso 15-06-2014.

[6] Chart.js. http://www.chartjs.org/, Último acceso 24-09-2014.

[7] Eclipse ide. https://www.eclipse.org/home/index.php, Último acceso

25-06-2014.

[8] EMF Eclipse Modeling Framework. http://www.eclipse.org/modeling/

emf/, Último acceso 12-03-2014.

[9] Epf - eclipse process framework. http://www.eclipse.org/epf/, Último

acceso 04-10-2013.

[10] Flujo de petición con struts2. http://www.javatutoriales.com/2011/06/

struts-2-parte-1-configuracion.html, Último acceso 14-01-2014.

[11] Hibernate orm. http://hibernate.org/orm/, Último acceso 24-03-2014.

[12] ISO/IEC 12007:2008 (OBP). https://www.iso.org/obp/ui/#iso:std:

iso-iec:12207:ed-2:v1:en, Último acceso 09-09-2014.

http://apachefoundation.wikispaces.com/Apache+Tomcat

http://apachefoundation.wikispaces.com/Apache+Tomcat

http://www.bibtex.org

https://bitbucket.org

http://eclipse.org/bpmn2-modeler/

http://tympanus.net/Tutorials/BubbleNavigation/

http://tympanus.net/Tutorials/BubbleNavigation/

http://www.chartjs.org/

https://www.eclipse.org/home/index.php

http://www.eclipse.org/modeling/emf/

http://www.eclipse.org/modeling/emf/

http://www.eclipse.org/epf/

http://www.javatutoriales.com/2011/06/struts-2-parte-1-configuracion.html

http://www.javatutoriales.com/2011/06/struts-2-parte-1-configuracion.html

http://hibernate.org/orm/

https://www.iso.org/obp/ui/#iso:std:iso-iec:12207:ed-2:v1:en

https://www.iso.org/obp/ui/#iso:std:iso-iec:12207:ed-2:v1:en

136 BIBLIOGRAFÍA

[13] Java. https://www.java.com/es/download/faq/whatis_java.xml,

Último acceso 14-05-2014.

[14] Junit. http://junit.org/, Último acceso 14-05-2014.

[15] Latex. http://www.latex-project.org, Último acceso 04-04-2014.

[16] Medini qvt. http://projects.ikv.de/qvt, Último acceso 12-03-2014.

[17] Mysql workbench. http://www.mysql.com/products/workbench/, Úl-

timo acceso 12-05-2014.

[18] Project jaxb. https://jaxb.java.net/, Último acceso 12-07-2014.

[19] Qvt relations. http://projects.ikv.de/qvt/wiki/tutorial, Último ac-

ceso 12-03-2014.

[20] Struts2. http://struts.apache.org/development/2.x/, Último acceso

05-10-2013.

[21] Uml - unified modeling language. http://www.uml.org/, Último acceso 27-08-

2014.

[22] Visual paradigm. http://www.visual-paradigm.com/, Último acceso 09-03-

2014.

[23] Guía Rápida Proceso de Desarrollo OpenUP/OAS, 2013. http:

//www.udistrital.edu.co/files/dependencias/oas/

GuiaRapidaOpenUPOAS.pdf, Último acceso 18-06-2014.

[24] Gestión empresarial de los procesos, 29 de Julio de 2013. http://www.

excelencia-empresarial.com/Gestion_procesos.htm.

[25] Acuña, Silvia T. and De Antonio, A. and Ferre, X. and López, M. and Maté, L.: The

software process: Modelling, evaluation and improvement, 2000.

[26] Alarcos Research Group: QVT - Query/View/Transformation Meta Object Facility (MOF)

2.0. 2008.

https://www.java.com/es/download/faq/whatis_java.xml

http://junit.org/

http://www.latex-project.org

http://projects.ikv.de/qvt

http://www.mysql.com/products/workbench/

https://jaxb.java.net/

http://projects.ikv.de/qvt/wiki/tutorial

http://struts.apache.org/development/2.x/

http://www.uml.org/

http://www.visual-paradigm.com/

http://www.udistrital.edu.co/files/dependencias/oas/GuiaRapidaOpenUPOAS.pdf



http://www.excelencia-empresarial.com/Gestion_procesos.htm

http://www.excelencia-empresarial.com/Gestion_procesos.htm

BIBLIOGRAFÍA 137

[27] Awad, Ahmed and Mathias Weske: Visualization of compliance violation in busi-

ness process models. http://bpt.hpi.uni-potsdam.de/pub/Public/

AhmedAwad/21-Awad.pdf. Último acceso 14-11-2013.

[28] Brown, Donald E.: Struts 2. Anaya Editorial, 2008, ISBN 978-84-4152-498-9.

[29] Burbeck, S.: Applications programming in smalltaks-80(tm): How to use model-view-

controller(mvc). 1992. Último acceso 12-06-2014.

[30] Bézivin, J.: MDA: From Hype to Hope, and Reality. 2003. UML Conference.

[31] Clark, Tony, Paul Sammut, and James Willans: Superlanguages: Developing, Languages

and Applications with XMF. Ceteva, 2008.

[32] Cuevas, A., Jose A. Calvo-Manzano, and T. San Feliu: Análisis de estándares y modelos

de referencia de mejores prácticas. http://www.dlsiis.fi.upm.es/docto_

lsiis/Trabajos20062007/Munoz.pdf, 2007. Último acceso 09-03-2014.

[33] Derniame, Jean Claude, Badara Ali Kaba, and David Graham Wastell (editors): Software

Process: Principles, Methodology, Technology, volume 1500 of Lecture Notes in Com-

puter Science. Springer, 1999, ISBN 3-540-65516-6. http://dblp.uni-trier.

de/db/conf/ewspt/sp1999.html, Último acceso 09-04-2014.

[34] Florac, W. and A.D. Carleton: Measuring the Software Process. Statical Process Control

for Software Process Improvement. Addison Wesley, 1999.

[35] Foundation Eclipse: Metodología OpenUP, url = http://epf.eclipse.org/wikis/openup/,

2007. Último acceso 16-05-2014.

[36] Fuggetta, Alfonso: Software process: a roadmap. In Proceedings of the Conference

on The Future of Software Engineering, ICSE ’00, pages 25–34, New York, NY, USA,

2000. ACM, ISBN 1-58113-253-0. http://doi.acm.org/10.1145/336512.

336521, Último acceso 18-01-2014.

[37] Gamma, E. and Helm, R. and Johnson, R. and Vlissides, J.: Patrones de diseño. elemen-

tos de software orientado a objetos reutilizable, November 2003, ISBN 0-201-63361-2.

[38] García, Félix O.: Process management and model driven engineering. Grupo Alarcos -

(UCLM) - Escuela Superior de Informática de Ciudad Real.

http://bpt.hpi.uni-potsdam.de/pub/Public/AhmedAwad/21-Awad.pdf

http://bpt.hpi.uni-potsdam.de/pub/Public/AhmedAwad/21-Awad.pdf

http://www.dlsiis.fi.upm.es/docto_lsiis/Trabajos20062007/Munoz.pdf

http://www.dlsiis.fi.upm.es/docto_lsiis/Trabajos20062007/Munoz.pdf

http://dblp.uni-trier.de/db/conf/ewspt/sp1999.html

http://dblp.uni-trier.de/db/conf/ewspt/sp1999.html

http://doi.acm.org/10.1145/336512.336521

http://doi.acm.org/10.1145/336512.336521

138 BIBLIOGRAFÍA

[39] García, J. and García, F.O. and Pelechano, V. and Vallecillo, A. and Vara, J.M and

Vicente-Chicote, C.: Desarrollo de Software Dirigido por Modelos: Conceptos, Métodos

y Herramientas. RA-MA Editorial, 2013, ISBN 978-84-9964-215-4.

[40] Ghose, Aditya and George Koliadis: Auditing business process compliance. Springer-

Verlag, pages 169–180, 2007. Decision Systems Laboratory, School of Computer

Science and Engineering.

[41] Governatori, G. and A. Rotolo: An algorithm for business process compliance. Jurix

2008, IOS Press, 2008. NICTA, Queensland Research Laboratory.

[42] Group Object Management: Software & Systems Process Engineering Meta-Model

Specification (SPEM). Version 2.0. 2008. Último acceso 24-05-2014.

[43] Institute of Electrical and Electronics Engineers (IEEE): IEEE Recommended Prac-

tice for Software Requirements Specifications. http://www.math.uaa.alaska.

edu/~afkjm/cs401/IEEE830.pdf, 1998. Último acceso 24-02-2014.

[44] International Organization for Standardization: ISO/IEC 15939 Software engineering -

Software Measurement Process. Ginebra, Suiza, 2002.

[45] International Organization for Standardization: ISO/IEC 15504:2003 Information tech-

nology - Process assessment, SPICE (Software Process Improvement and Capability

Determination). 2003.

[46] International Organization for Standardization: Guidelines for the application of iso

9001:2000 to computer software. http://www.iso.org/iso/catalogue_

detail?csnumber=35867, 2004. Último acceso 12-02-2014.

[47] International Organization for Standardization: ISO/IEC 12207 - standard for informa-

tion technology - software life cycle processes. Standard, 2008.

[48] International Organization for Standardization (ISO): ISO IEC 15504 TR2: 1998, part

2: A reference model for processes and process capability., 1998. Ginebra, Suiza.

[49] Juran, J.M.: A History of Managing for Quality. McGraw-Hill, New York, 1988,

ISBN 978-0873893411.

http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf

http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf

http://www.iso.org/iso/catalogue_detail?csnumber=35867

http://www.iso.org/iso/catalogue_detail?csnumber=35867

BIBLIOGRAFÍA 139

[50] Kerazi, N., M Lavallée, and Pierre N. Robillard: A knowledge-based perspective for

software process modeling. Software Engineering Journal, Volume 7, 2013.

[51] McLeod, Raymond: Management information systems. Prentice-Hall Interna-

tional editions. Prentice Hall International, London [u.a.], 6. ed edition, 1995,

ISBN 0131809512. http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&

SRT=YOP&IKT=1016&TRM=ppn+184709016&sourceid=fbw_bibsonomy,


[52] Methodpark: Effectively managing process compliance. Último acceso 30-07-2014.

[53] Pardo, César: A framework to support the harmonization between multiple models and

standards. PhD thesis, Junio 2012. Institute of Information Technologies Systems,

University of Castilla-La Mancha.

[54] Paulk, M. C. and Weber, C. V. and Curtis, B. and Chrissis, M. B.: The Capability

Maturity Model: Guidelines for improving the software process. Addison-Wesley

Publishing Company, Massachusetts, 1995. The SEI Series in Software Engineering.

[55] Perez Cota, M. and Riesco, D. and Debnath, G. and Montejano, G.: Transformations

from SPEM Work Sequences to BPMN Sequence Flows for the Automation of Software

Development Process. Journal of Computational Methods in Science and Engineering

(JCMSE), 2010.

[56] Piattini, Mario G. and Félix O. García: Calidad en el desarrollo y mantenimiento del

Software. RA-MA, Madrid, 2003, ISBN 84-7897-544-6.

[57] Piattini, Mario G. and García, Félix, O. and García, I. and Pino, Francisco: Calidad de

Sistemas de Información. RA-MA, Madrid, 2011, ISBN 978-84-9964-070-9.

[58] Pérez, Juan D.: Notaciones y lenguajes de procesos. una visión global. https://www.

lsi.us.es/docs/doctorado/memorias/Perez,%20Juan%20D.pdf,

2007. Último acceso 03-02-2014.

[59] Reenskaug, T., P. Wold, and O. A. Lehne: Working with objects: the Ooram software

engineering method. Manning Publications, Greenwich, CT, 1996. Último acceso

10-06-2014.

http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&SRT=YOP&IKT=1016&TRM=ppn+184709016&sourceid=fbw_bibsonomy

http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&SRT=YOP&IKT=1016&TRM=ppn+184709016&sourceid=fbw_bibsonomy

https://www.lsi.us.es/docs/doctorado/memorias/Perez,%20Juan%20D.pdf

https://www.lsi.us.es/docs/doctorado/memorias/Perez,%20Juan%20D.pdf

140 BIBLIOGRAFÍA

[60] Rios, S., C. Hinojosa, and R. Delgado: Aplicación de la metodología OpenUP en el

desarrollo del sistema de difución de gestión del conocimiento de la ESPE. Escuela

Politécnica del Ejército.

[61] Romero, F.: ARMONÍAS-DGS, Herramienta para la Armonización y Evaluación de

Calidad de Procesos en Desarrollo Global de Software. Proyecto Fin de Carrera, Junio

2012. Castilla - La Mancha, España.

[62] Ruiz, F.: De una gestión de procesos contemplativa a una productiva. http://

alarcos.esi.uclm.es/ipsw/doc/SPE-IDEA.pdf, 2007. Último acceso

03-06-2014.

[63] Ruiz, Francisco and Javier Verdugo: Guía de uso de spem 2 con epf composer. 2008.

Universidad de Castilla-La Mancha Escuela Superior de Informática Departamento de

Tecnologías y Sistemas de Información.

[64] Satpathy, M. and R. Harrison: A Typed Generic Process Model for Product Focused

Process Improvement. Proceedings of the 26th Annual International Computer Software

and Applications Conference (COMPSAC’02). Oxford, England, 2002.

[65] Sheard, Sarah A.: Systems engineering standards and models compared. In Proceedings

of the 8th International Symposium on Systems Engineering (INCOSE, pages 589–605,

1998.

[66] Software Engineering Institute (SEI): CMMI ® for Acquisition, Version 1.3. November

2010. http://goo.gl/ngL1c.

[67] Software Engineering Institute (SEI): CMMI ® for Developement, Version 1.3. Novem-

ber 2010. http://goo.gl/oljH2.

[68] Software Engineering Institute (SEI): CMMI ® for Services, Version 1.3. November

2010. http://goo.gl/DGK8i.

[69] Software Engineering Institute (SEI): Standard CMMI ® appraisal Method for Process

Improvement (SCAMPI) A, Version 1.3: Method Definition Document. March 2010.

http://goo.gl/76z80.

http://alarcos.esi.uclm.es/ipsw/doc/SPE-IDEA.pdf

http://alarcos.esi.uclm.es/ipsw/doc/SPE-IDEA.pdf

http://goo.gl/ngL1c

http://goo.gl/oljH2

http://goo.gl/DGK8i

http://goo.gl/76z80

BIBLIOGRAFÍA 141

[70] Universidad Distrital Francisco José de Caldas: Guía openup. http://www.

udistrital.edu.co/dependencias/oas/documentos/, Último acceso

16-10-2014.

[71] Vallecillo, A.: Desarrollo de software dirigido por modelos. Último acceso 16-05-2014.

[72] Vicente Pelechano - Universidad Politécnica de Valencia: Model driven development.


[73] Vizcaino, A and J. Favela: Supporting Software Maintenance in Web Repositories

through a Multi-Agent System. First International Atlantic Web Intelligence Concerence

(AWIC’ 2003) LNAI 2663 Menasalvas, E. and Segovia, J. and Szczepaniak, P.S. P.S.

(Eds): 307-317, 2003.

[74] Wang, Y. and King G.: Software Engineering Processes: Principles and Applications.

CRC Press, 2000.

http://www.udistrital.edu.co/dependencias/oas/documentos/

http://www.udistrital.edu.co/dependencias/oas/documentos/

Apéndice A

Manual de Instalación

Este apéndice corresponde al manual de Instalación de la herramienta. Para su ejecución se

necesitará un servidor Apache Tomcat que aloje la herramienta mediante, por ejemplo, un

archivo con extensión .war, y del lado del cliente un navegador Web como Mozilla Firefox,

Internet Explorer, Safari, Google Chrome, Opera, etc. con la función JavaScript activada.

Compromise utiliza dos bases de datos, que serán proporcionadas junto a la documentación

de la herramienta (directorio BBDD), la primera será denominada compromise.sql (referente

a la presente herramienta) y la otra armonias.sql. Para llevar a cabo la instalación de ambas

bases de datos se deberá ejecutar las siguientes sentencias en la terminal del equipo utilizado:

mysql -u root -p <compromise.sql

mysql -u root -p <armonias.sql

Los parámetros de conexión de COMPROMISE con las bases de datos anteriormente

mencionadas están configurados para un servidor local, no obstante si se deseara desplegar la

herramienta en un servidor remoto se necesita cambiar las rutas de las conexiones a las bases

de datos éstas están presentes en la clase Persistence.Agente.java y resources.hibernate.cfg.xml

respectivamente.

Además del código de la aplicación, se proporcionarán los frameworks MediniQVT,

Eclipse BPMN Modeler, y Eclipse Process Framework Composer en una carpeta interna

llamada Frameworks. Dentro de cada una de estas se encuentra una subcarpeta denominada

Workspace, hay que respetar la jerarquía, pues COMPROMISE hará uso de esta carpeta para

guardar los archivos de intercambio que necesiten las herramientas.

Apéndice B

Manual de Usuario

En este apéndice se presenta el manual de usuario de la herramienta COMPROMISE. Estará

organizado por secciones que corresponderán a las distintas funcionalidades que ofrece la

misma.

B.1 Registro de Usuario

El primer paso para utilizar COMPROMISE será la identificación de Usuario. Haremos uso

de esta función mediante la página de login, presente en la Figura B.1. En ella introduciremos

el nombre del usuario y su password.

Figura B.1: Vista Login

146 B.2. SELECTOR DE IDIOMA Y MENÚ DE COMPROMISE

A continuación se presentan los identificadores que se han utilizado para las pruebas de la

herramienta:

• usuario - usuario

• adminHerramienta - adminHerramienta

• adminOrganizacion - adminOrganizacion

Dichos usuarios tendrán los privilegios mencionados en la Tabla 5.1. No obstante si los

usuarios introducidos no estuviesen contemplados en la base de datos y no se pudiera lograr

una identificación de usuario satisfactoria, la aplicación retornará de nuevo a esta ventana no

pudiendo implementar ninguna acción de la herramienta sin haber hecho uso de esta función

(validar.action).

B.2 Selector de Idioma y Menú de COMPROMISE

Mediante la utilización de los botones expuestos en la Figura 5.30 situados en cada una

de las páginas de la herramienta, el usuario podrá cambiar el idioma a Inglés o a Español,

convirtiendo la herramienta en multilenguaje. Además, en el caso en el que se quiera salir de

la misma únicamente tendrá que pulsar el botón situado en la esquina superior derecha del

panel o de la barra superior, según corresponda

A continuación se proporciona un ejemplo resultante del cambio de idioma en la página

del menú correspondiente a la herramienta. Mientras que la Figura B.2 presenta al usuario el

menú en Español, la Figura B.3 lo hace en inglés. Mencionar que una vez cambiado el idioma

será sustituido en todas las páginas de la herramienta, pudiendo volver al anterior en cualquier

momento.

APÉNDICE B. MANUAL DE USUARIO 147

Figura B.2: Ejemplo del Menú en Español

Figura B.3: Ejemplo del Menú en Inglés

B.3 Administración de la herramienta

Una vez identificado el usuario y que éste ha accedido al menú de COMPROMISE, en el caso

de que el usuario tenga los privilegios adecuados, podrá acceder al menú principal situándonos

en el botón que aparece en la Figura B.4.

148 B.3. ADMINISTRACIÓN DE LA HERRAMIENTA

Figura B.4: Acceso al menú de administración.

Una vez ejecutada la acción, se redigirá al usuario al panel de administración en el que

podremos observar distintas funcionalidades; una lista de usuarios de la organización a la que

pertenece el usuario autenticado (Figura B.5), la lista de organizaciones en el caso de que sea

el administrador de la herramienta (Figura B.6), un selector de rutas de la figura (Figura B.7)

y el selector de márgenes de aceptación que consideremos oportuno para nuestro proceso en

cuestión (Figura B.8).

Figura B.5: Usuarios registrados en COMPROMISE

En la Figura B.6 podemos observar cómo cada organización dispone de una serie de

botones que abren distintas ventanas modales para modificar, crear o eliminar cada uno de los

elementos de las mismas (activos, herramientas, roles y usuarios).

Figura B.6: Administración de las organizaciones de COMPROMISE.

En la Figura B.7 podemos observar el formulario en el que introduciremos todas las rutas

de las herramientas complementarias a COMPROMISE. Una vez introducidas todas ellas

pulsaremos el botón Guardar. A partir de este momento podremos ejecutar Medini QVT,


BPMN Modeler y EPFC desde el menú principal de la herramienta.

Figura B.7: Selector de Rutas de COMPROMISE

COMPROMISE permite a las organizaciones definir el margen de aceptación de cada

proceso, es decir, definimos a partir de qué umbral el proceso se considera satisfecho. Para

ello haremos uso del formulario de la Figura B.8. Cabe mencionar que el proceso aparecerá

una vez hecho uso del menú Cargar nuevos Procesos, inicializando el valor de su margen de

aceptación a cero.

Figura B.8: Definición de los márgenes de aceptación

Podremos hacer uso del cuadro de texto, introduciendo el valor oportuno, o bien un selector

presente en la Figura B.9. Una vez que se ha hecho uso del selector circular pulsaremos el

botón Guardar para que los cambios surtan efecto.

150 B.4. CARGAR PROCESOS EPFC

Figura B.9: Selector de aceptación de Conformidad

B.4 Cargar Procesos EPFC

Para proveer a la herramienta EPFC del contenido de método (Roles, Tareas, Disciplinas, etc.)

previamente tendremos que cargar los elementos en un documento XML que automáticamente

EPFC capturará al inicio. Para ello deberemos accionar el botón Cargar Contenido de Método

de la Figura B.10. Una vez accionado, COMPROMISE proveerá al usuario de una ventana

que le permita guardar el Contenido de Método, en forma de archivo, que necesitará EPFC en

el paso posterior.

Haremos uso de esta función mediante la siguiente ventana en el menú de COMPROMISE:

Figura B.10: Menú de Conformidad de Compromise.


Una vez realizado este paso procederemos a la visualización de la herramienta EPFC ha-

ciendo uso de la función del menú de la Figura B.11, la cual nos mostrará todos los elementos

cargados desde la base de datos de Armonías-DGS. Hay que mencionar que para cargar el

archivo proporcionado por COMPROMISE, antes deberemos importar el archivo guardado

en el instante anterior (MethodContent.xml. Lo realizaremos en el menú de EPFC mediante la

secuencia File 99K Import 99K XML.

Figura B.11: Ejecutar EPFC

En la siguiente figura, además de la carga de contenido de método, se muestra la com-

posición del proceso. Para ello crearemos un Delivery Process (Ilustrado en la Figura B.13)

que será el proceso de la organización que deseemos modelar y que posteriormente nuestra

herramienta incluirá en su base de datos y representará.

Figura B.12: Composición de Procesos mediante EPFC

Una vez realizado este paso restará exportar como XML la librería de método y cargar

el archivo exportado en COMPROMISE. Para ello haremos uso del botón Cargar Nuevos

Procesos en la pestaña Conformidad/Compliance del menú principal. Una vez accionado se

152 B.4. CARGAR PROCESOS EPFC

Figura B.13: Crear Delivery Process EPFC

dispondrá de un selector para ello.


B.5 Compliance Organización

Una vez seguido estos pasos volveremos al menú de la herramienta y seleccionaremos la

opción de Panel Principal dentro del submenú de Usuarios. Dicha selección la podemos ver

en la figura B.14.

Figura B.14: Ejecución el Panel Principal de Compromise

Realizada esta acción nos aparecerá un gestor de control que nos permite visualizar los

procesos de la organización, las tareas de la misma, así como unas gráficas que indican

aspectos que ahora explicaremos. Hay tres tipos de gráficas, el primer tipo (Figura B.15) es

de histórico de Conformidad, el cual muestra por años la conformidad de la organización para

con un marco de referencia concreto. El segundo tipo de gráfica (Figura B.16) muestra la

conformidad actual categorizada por procesos. Y por último, el tercer gráfico (Figura B.18)

muestra el estado de la organización respecto con los marcos de referencia de la base de datos

de Armonías-DGS.

154 B.5. COMPLIANCE ORGANIZACIÓN

Figura B.15: Gráfica de Histórico de la Conformidad de Procesos de una Organización

Figura B.16: Gráfico de barras correspondiente a la Conformidad de Proceso

Dentro de esta vista podremos observar los Roles que tiene asociados cada tarea seleccio-

nando la que consideremos oportuna (Figura B.17).


Figura B.17: Roles Relacionados con la Tarea Seleccionada

Además de proveer la función de visualización, la herramienta podrá utilizar la función de

recomendador anteriormente mencionada. Para ello haremos uso del menú desplegable que

tenemos en la Figura B.19 de la gráfica de la Figura B.18.

Figura B.18: Gráfica correspondiente al Compliance de la Organización por Marcos de Referen-

cia

156 B.5. COMPLIANCE ORGANIZACIÓN

Figura B.19: Menú desplegable para la función Recomendador

Una vez hecho uso de esta función aparecerá una pantalla similar a la anterior que nos

indicará en tres tablas las herramientas, las tareas y los roles por implementar. Si deseáramos

extraer esa documentación en formato PDF haremos uso del botón Extraer PDF, presente en

la Figura B.20.

Figura B.20: Función de generación de Informes PDF


B.6 Generar archivo para MediniQVT

Para realizar la transformación entre modelos UMA y BPMN2 antes deberemos componer

el documento XML que contenga los procesos de la organización a transformar por Medini.

Para ello necesitaremos hacer uso de la función Componer documento Medini en el submenú

Compliance/Compromise.

Figura B.21: Ejecución de la Composición del Documento .xmi para el Framework MediniQVT

Una vez que se han realizado los pasos anteriores se abrirá una ventana modal que

nos permitirá guardar nuestro archivo con extensión xmi, que posteriormente cargará la

herramienta Medini QVT.

B.7 Abrir Medini-QVT y ejecutar transformación

Una vez realizado el documento de la transformación ejecutaremos la herramienta MediniQVT

mediante el menú de la Figura B.22.

Figura B.22: Ejecución del Framework MediniQVT

158B.8. REPRESENTACIÓN PROCESO TRANSFORMADO (BPMN) EN BPMN2

MODELER

Cuando se nos ha cargado el Framework ejecutaremos la transformación como se presenta

en la Figura B.23

Figura B.23: Ejecución de la transformación MediniQVT

B.8 Representación Proceso transformado (BPMN) en BPMN2

Modeler

A continuación ejecutando el framework BMPN Modeler mediante el submenú de la Figura

B.24, lograremos ver el proceso transformado en las dos variantes presentadas en la Figura

B.25 y en la cascada de la Figura 5.29.

Figura B.24: Ejecuta el Framework BPMN Modeler


Una vez terminado el proceso interno de la herramienta, COMPROMISE activará una

ventana que permitirá al usuario guardar el archivo con extensión .bpmn, que posteriormente

cargaremos con BPMN Modeler.

Figura B.25: Presentación de Proceso mediante BPMN Modeler

B.9 Ayuda

Si hacemos uso de esta función se cargará el presente manual para su visualización.(Figura

B.26)

Figura B.26: Ejecución de la ayuda de Compromise

Apéndice C

Acrónimos

A continuación se presentan un conjunto de acrónimos utilizados en el presente Trabajo de

Fin de Grado:

API. Application Programming Interface.

ATL. Atlas Transformation Language

BBDD. Base de Datos

BPMN. Business Process Model and Notation

CASE. Computer Aided Software Engineering.

CIM. Colaborative Information Manager.

CMMI. Capability Maturity Model Integration.

CMMI-ADQ. Capability Maturity Model Integration for Acquisition.

CMMI-DEV. Capability Maturity Model Integration for Development.

CMMI-SVC. Capability Maturity Model Integration for Services.

CRUD. Create, Read, Update and Delete.

CSS. Cascading Style Sheets.

DGS. Desarrollo Global de Software.

DSDM. Desarrollo de Software Dirigido por Modelos.

162

DSL. Domain Specific Language.

DVI. DeVice Independent.

EMF. Eclipse Model Framework.

EPFC. Eclipse Process Framework Composer.

GMP. Graphical Modeling Project.

GNOME. GNU Network Object Model Environment.

GPL. General Public License.

HTML. HyperText Markup Language.

HTTP. Hypertext Transfer Protocol.

IDE. Integrated Development Environment.

IDM. Ingeniería Dirigida por Modelos.

IEEE. Institute of Electrical and Electronics Engineers.

ISO. International Organization for Standardization.

JSP. JavaServer Pages.

MDA. Model Driven Architecture.

MDD. Model Driven Development.

MDE. Model Driven Engineering.

MDSD. Model-Driven Software Development.

MVC. Modelo-Vista-Controlador.

OMG. Object Management Group.

OpenUP. Open Unified Process.

APÉNDICE C. ACRÓNIMOS 163

ORM. Object Relational Mapper.

PDF. Portable Document Format.

PIM. Platform-Independent Model.

POO. Programación Orientada a Objetos.

PS. PostScript.

PSEE. Process-centered Software Engineering Environments.

PSM. Platform-Specific Model.

QVT. Query/View/Transformation.

SGBDR. Sistema de Gestión de Bases de Datos Relacionales.

SPEM. Software & Systems Process Engineering Metamodel.

SQL. Structured Query Language.

TFG. Trabajo de Fin de Grado.

UMA. Unified Method Architecture.

UML. Unified Modeling Language.

URI. Uniform Resource Identifier.

UML. Unified Modeling Language.

W3C. World Wide Web Consortium.

WWW. World Wide Web.

WYSIWYG. What-You-See-Is-What-You-Get.

XML. Extensible Markup Language.

XSD. XML Schema Definition

Apéndice D

Glosario

A continuación se presenta la definición de algunos términos utilizados en el trabajo:

1. Actividad. Definiremos la Actividad como un conjunto de tareas relacionadas con un

fin común. Un conjunto de Actividades compondrán un proceso.

2. Ambientes Multimarco: Haciendo mención a los marcos de referencia como están-

dares de la Industria, diremos que se da un Ambiente Multimarco cuando éstos son

utilizados de manera conjunta, componiendo un nuevo estándar con características de

dos o más de ellos.

3. Armonías-DGS: Es la herramienta desarrollada por Francisco Romero [61] y tiene

como propósito dotar a HFramework del soporte tecnológico necesario para cubrir los

aspectos automatizados, así como la presentación de los datos resultantes en forma de

gráficas e informes.

4. Ciclo de vida: Según la norma ISO/IEC Standard 12207:2008:Software life-Cycle

processes [47], se define el ciclo de vida es “un marco de referencia que contiene

los procesos, las actividades y las tareas involucradas en el desarrollo, explotación

y mantenimiento de un producto software, abarcando la vida del sistema desde la

definición de requisitos hasta que se deja de utilizar.”

5. Conformidad: Cuando nos referimos en el documento a conformidad nos referimos al

cumplimiento de nuestro proceso para con un marco de referencia determinado. Además

éste puede ser armonizado o no, ya que gracias al paradigma que nos proporciona la

herramienta Armonías-DGS nos es transparente.

166

6. Eclipse: Es un programa informático de código abierto compuesto por múltiples

herramienas de programación que permiten desarrollar software. Es muy utilizado por

su potencia y porque ofrece la posibilidad de extender funcionalidades específicas a

través de plugins.

7. Esquema xml o xsd: Se trata de un lenguaje para describir y definir la estructura de los

documentos XML. Una de las características más importantes es que ofrece funciones

de verificación, muy útil cuando se trata de un archivo de intercambio de información.

Fue desarrollado por el W3C en 2001.

8. Framework: Su transcripción literal es “marco de trabajo” y define en términos

generales un conjunto de conceptos, prácticas y herramientas que permiten enfocar

una problemática específica y darles solución mediante la estructura conceptual y

tecnológicas que éste proporciona.

9. HFramework: Es una tesis desarrollada por César Pardo en la Escuela Superior de

Informática de Ciudad Real que da un soporte teórico a la armonización de marcos de

referencia adoptados por la industria.

10. JAXB: Es un API que proporciona al programador facilidades a la hora elaborar

documentos XML y proporciona métodos de acceso a la información contenida en

éstos una vez creados. Además, se utiliza como Plug-in del IDE Eclipse y permite la

creación automática de las clases Java que componen un esquema XML, con todos los

elementos definidos junto con sus interrelaciones.

11. Librería de Método: Se trata de un contenedor definido en el metamodelo UMA

que recoge todos los Elementos de Método, entendiéndose éstos como un conjunto de

Contenidos de Método, Contenidos de Proceso, etc.

12. Marshall: El Marshall es un término que hace referencia a la composición de docu-

mentos XML a partir de un árbol de objetos Java mediante la API JAXB. El concepto

opuesto es el UnMarshall, que permite obtener los datos de un documento XML bien

definido y transformarlo en un árbol Java de Objetos definidos en el esquema.

13. Metamodelo: Es un modelo del lenguaje que captura las propiedades y características

esenciales. Esto incluye los conceptos de lenguaje que lo apoya y/o la sintaxis gráfica

junto con la semántica.

APÉNDICE D. GLOSARIO 167

14. Modelo de Referencia: Es un conjunto de buenas prácticas estandarizadas, están

definidos por organizaciones o un conjunto de ellas y son aceptadas por la industria.

Algunos ejemplos son CMMI, ISO/IEC 12007, etc.

15. Patrón de Diseño: Son un conjunto de soluciones a problemas de diseño estandari-

zadas con una serie de características. Se debe haber comprobado su efectividad de

resolución de problemas similares y debe ser reutilizable, lo que conlleva a aplicarse en

soluciones a diseños similares.

16. Plugin: Un plugin es un complemento utilizado para extender las funcionalidades de

ciertos programas informáticos. Son soluciones específicas a problemas determina-

dos, permitiéndonos configurar el entorno sobre el que estemos trabajando de forma

personalizada.

17. Proceso Software: Un proceso 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”.

18. Profiling: O análisis de rendimiento es la investigación del comportamiento de un

programa. El objetivo del mismo es averiguar el tiempo de ejecución dedicado a

cada ejecución para efectuar mejoras, detectando puntos de ejecución problemáticos,

optimización del rendimiento, etc.

19. Requisitos: El concepto de requisitos comprende cada uno de los aspectos y caracterís-

ticas que el cliente desea tener presentes en su sistema software. Así, la recogida de

requisitos se realiza en la primera fase del desarrollo mediante una serie de técnicas

comprendidas en el área de la Ingeniería de Requisitos.

20. Rol: Define un conjunto de habilidades, competencias y responsabilidades de una

persona o un conjunto de personas. Una persona puede desempeñar varios roles. [57].

21. Servlet: Es una clase en el lenguaje Java que permite extender la funcionalidad de un

servidor. Usualmente son utilizados en aplicaciones web.

22. Test suite: Es un conjunto de Test tratados como una unidad que se definen en la

etapa de pruebas. Cada Suite estará compuesta por una serie de test unitarios con la

posibilidad de tener relación entre ellos.

Apéndice E

Planificación del TFG

En este apéndice se presenta la planificación realizada que determina la posibilidad del

desarrollo del presente TFG en el tiempo previsto. Se presentarán las planificaciones realizadas

tanto temporales como económicas, los recursos necesarios para su realización y el equipo de

personal disponible. Además destacaremos algunos cambios realizados en el planteamiento

original que en un origen imposibilitaban el desarrollo satisfactorio del mismo.

E.1 Planificación Temporal

En un origen se definió el trabajo para la presentación en Septiembre. No obstante, la com-

plejidad que supuso la adquisición de determinados conceptos tratados en el desarrollo, la

inexperiencia inicial en la tecnología utilizada y la ampliación del alcance que suponía el tra-

tamiento de transformaciones entre modelos, determinaron la presentación en la convocatoria

de Diciembre.

A continuación se presenta una tabla con la cantidad de horas dedicadas al proyecto

separadas por iteraciones:

170 E.2. EQUIPO DE TRABAJO

Iteración Horas

Iteración 0 31 horas








Cuadro E.1: Planificación Temporal.

Lo que supone un total de 997 horas trabajadas. En dicha media se han tenido en cuenta

las horas de realización de la herramienta así como las necesarias para el aprendizaje de

los aspectos técnicos y teóricos necesarios para abordar satisfactoriamente el desarrollo del

presente TFG.

Hay que destacar que, según la guía docente del trabajo de Fin de Grado, se han empleado

más horas de las estimadas. En gran medida ha sido debido a la inexperiencia en los distintos

aspectos técnicos presentados en el documento así como en el aprendizaje previo a la utiliza-

ción de las herramientas necesarias para la elaboración de COMPROMISE y adquisición de

conocimientos necesarios.

E.2 Equipo de Trabajo

En el desarrollo el autor asume los roles de Ingeniero de Requisitos, Analista, Diseñador,

Desarrollador y Tester. El Rol de Director de Proyecto ha sido asumido por el Director del

Trabajo de Fin de Grado. Por lo que únicamente contaremos con dos personas involucradas

activamente en la realización del Trabajo.

E.3 Recursos Materiales

Durante el desarrollo se han utilizado dos equipos, expuestos a continuación E.2:

APÉNDICE E. PLANIFICACIÓN DEL TFG 171

Equipo Características

Equipo Portátil Intel(R) Core(TM) i5 CPU M450 2.40 GHz

Equipo

SobremesaAMD Phenom(tm) II X4 945 Processor 3.0 GHz

Cuadro E.2: Recursos Hardware.

En cuanto al Software utilizado mencionar que todos los programas informáticos utilizados

han sido de Software libre, exceptuando la herramienta Visual Paradigm, sin embargo se

cuenta con la licencia de Estudiante proporcionada por la Escuela Superior de Informática de

Ciudad Real. Respecto al Sistema Operativo utilizado ha sido necesario el desarrollo bajo

Windows 7 por la incompatibilidad de algunas herramientas con GNU/Linux, no obstante

también ambos equipos contaban con sus respectivas licencias.

E.4 Presupuesto

En esta sección se estimarán los recursos económicos necesarios para la realización de la

herramienta. Por la fluctuación propia de los gastos variables, como pueden ser la luz, el agua,

la electricidad, etc. éstos no se tendrán en cuenta, cuantificándose únicamente los gastos fijos

relativos al salario de los recursos humanos. A continuación se presentarán en la tabla E.3:

Número horas Coste de la hora Bruto Régimen social Total

997 12,00 ¤ Empleado 11.964 ¤

Cuadro E.3: Costes por contratación de empleados.

Apéndice F

Código Fuente

F.1 Ejemplo clase Manager

1 package hibernate.controller;

2

3

4 import java.util.List;

5 import org.hibernate.HibernateException;

6 import org.hibernate.classic.Session;

7 import hibernate.model.Actividad;

8 import hibernate.model.Iteracion;

9 import hibernate.model.Role;

10 import hibernate.model.Task;

11 import hibernate.util.HibernateUtil;

12

13 public class TaskManager extends HibernateUtil {

14

15

16 public Task add(Task task){

17 if(!this.exists(task)){

18 Session session = HibernateUtil.getSessionFactory().

getCurrentSession();

19 session.beginTransaction();

20 session.save(task);

21 session.getTransaction().commit();

22 }

23

24

25 return task;

174 F.1. EJEMPLO CLASE MANAGER

26 }

27

28 public Task delete(int id){




31 Task task= (Task) session.load(Task.class, id);

32 if(null != task){

33 session.delete(task);

34 }


36

37 return task;

38 }

39

40 @SuppressWarnings("unchecked")

41 public List <Task> list(){

42




45 List<Task> task = null;

46

47 try {

48

49 task = ((List<Task>)session.createQuery("from Task").list

());

50

51 } catch (HibernateException e) {

52 e.printStackTrace();

53 session.getTransaction().rollback();

54 }


56

57 return task;

58

59

60 }

61

APÉNDICE F. CÓDIGO FUENTE 175

62 private boolean exists(hibernate.model.Task task){

63 boolean exist = false;

64 List <hibernate.model.Task> lista_actividades = this.list();

65

66 for(int i=0;i<lista_actividades.size();i++){

67 if(task.getName().equalsIgnoreCase(lista_actividades.get(i

).getName()) && task.getDescription().equalsIgnoreCase

(lista_actividades.get(i).getDescription())){

68 exist = true;

69 }

70 }

71 return exist;

72 }

73

74 public List<hibernate.model.Task> getTaskbyProcess(String

process_name){

75




78 List<hibernate.model.Task> tareas = null;

79

80 try {

81 tareas = ((List<hibernate.model.Task>)session.createQuery(

"from Task WHERE Process_name=’"+process_name+"’").

list());

82

83 } catch (HibernateException e) {


85 session.getTransaction().rollback();

86 }


88

89 return tareas;

90

91

92 }

93

94 }

176 F.1. EJEMPLO CLASE MANAGER

Listado F.1: Ejemplo clase Manager.

1 public static void getElementsUnmarshaller( ){

2

3 try {

4

5 JAXBContext jaxbContext = JAXBContext.newInstance(

BPMN20_unmarshall.TDefinitions.class);

6 Unmarshaller jaxbUnmarshaller = jaxbContext.

createUnmarshaller();

7

8 empsd = jaxbUnmarshaller.unmarshal(new StreamSource(new File

("./saliente.xmi")),BPMN20_unmarshall.TDefinitions.class

);

9

10 /*Obtenemos los procesos*/

11

12 setProcesos(getprocesos(empsd));

13 setElementos_procesos(getFlowElements(procesos));

14

15 } catch (JAXBException e) {

16 // TODO Auto-generated catch block


18 }

19

20 }

Listado F.2: Ejemplo UnMarshall

grado en ingenierÍa en informÁtica - ruidera.uclm.es

Documents