Desarrollo de una aplicación para la gestión de calidad de los procesos en el entorno JIRA

UNIVERIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INFORMÁTICA APLICADA PROYECTO FINAL DE CARRERA Desarrollo de una aplicación para la gestión de calidad de los procesos en el entorno JIRA. Alumno: Francesc Codina Navarro Tutor: Felix Buendía García La elaboración de este proyecto final de carrera no habría sido posible sin la ayuda de David Domínguez Tortajada, Eduardo Montón Sánchez y Ricardo Serafín. Índice de contenido 1. INTRODUCCIÓN............................................................................................................................5 1.1 DESCRIPCIÓN DEL PROYECTO..........................................................................................5 1.2 OBJETIVOS DEL PROYECTO..............................................................................................6 1.3 ESTRUCTURA.......................................................................................................................6 2. MARCO TEORICO.........................................................................................................................8 2.1 CMMI.......................................................................................................................................8 3. ESPECIFICACIÓN DE REQUISITOS.........................................................................................17 3.1 INTRODUCCIÓN..................................................................................................................17 3.1.1 Propósito...................................................................................................................17 3.1.2 Ámbito......................................................................................................................17 3.1.3 Visión global.............................................................................................................18 3.1.4 Definiciones siglas y abreviaturas.............................................................................18 3.2. DESCRIPCION GENERAL..................................................................................................21 3.2.1 Perspectiva del producto...........................................................................................21 3.2.2 Funciones del producto.............................................................................................22 3.2.3 Características del usuario........................................................................................23 3.2.4 Reestriciones generales.............................................................................................24 3.2.5 Supuestos y dependencias.........................................................................................24 3.3 REQUISITOS ESPECIFICOS...............................................................................................24 4. ANÁLISIS Y DISEÑO...................................................................................................................29 4.1 CASOS DE USO....................................................................................................................29 4.2 DIAGRAMAS DE CLASES.................................................................................................31 5. IMPLEMENTACION....................................................................................................................37 5.1 ENTORNO DE DESARROLLO............................................................................................37 5.3 DIAGRAMAS DE ESTRUCTURAS....................................................................................38 5.2 ESTRUCTURA DEL PLUGIN..............................................................................................44 5.4 ARQUITECTURA POR CAPAS...........................................................................................48 6. RESULTADOS Y PRUEBAS.......................................................................................................53 6.1 PRUEBAS.............................................................................................................................53 6.2 RESULTADOS.......................................................................................................................56 7. CONCLUSIONES.........................................................................................................................68 8. REFERENCIAS............................................................................................................................69 9. ANEXOS........................................................................................................................................70 8.1 INDICADORES....................................................................................................................70 8.2 CMMI METAS Y PRACTICAS............................................................................................73 8.3 LOS PROCESOS EN LA EMPRESA....................................................................................75 8.4 ACERCA DE JIRA.................................................................................................................77 8.5 CASOS DE USO....................................................................................................................85 Índice de ilustraciones Figura 1: Evolución del modelo CMMI ..............................................................................................................................9 Figura 2: Metas y practicas ................................................................................................................................................16 Figura 3: Casos de uso del jefe de proyecto ......................................................................................................................29 Figura 4: Casos de uso del administrador de JIRA ............................................................................................................30 Figura 5: Casos de uso de los usuarios de JIRA ................................................................................................................31 Figura 6: Diagrama de clases de la aplicación JIRA .........................................................................................................33 Figura 7: Diagrama de clases de la parte de los informes del plugin ................................................................................34 Figura 8: Detalle del espacio de trabajo del entorno de desarrollo ...................................................................................37 Figura 9: Diagrama de estructuras de la aplicación JIRA .................................................................................................39 Figura 10: Componentes del sistema .................................................................................................................................43 Figura 11: Detalle de la estructura del proyecto ................................................................................................................45 Figura 12: Detalle de la carpeta donde se encuentran los recursos ...................................................................................45 Figura 13: Estructura del sistema desde la perspectiva de capas ......................................................................................48 Figura 14: Estructura de la tabla maestro de indicadores de la base de datos ...................................................................50 Figura 15: Estructura de la tabla objetivos de la base de datos .........................................................................................51 Figura 16: Estructura de la tabla medidas de la base de datos ..........................................................................................52 Figura 17: Plantilla con datos para el cálculo de los indicadores de avance ............................................................53 Figura 18: Plantilla con el cálculo de los indicadores de estado .......................................................................................54 Figura 19: Plantilla con los cálculos de los indicadores de estado ....................................................................................54 Figura 20: Plantilla con las desviaciones y los pesos de las fases .....................................................................................55 Figura 21: Plantilla con el calculo de las velocidades de desarrollo .................................................................................55 Figura 22: Vista de la pantalla de administración de workflows en JIRA .........................................................................56 Figura 23: Detalle del workflow de pruebas donde se ven los pasos y las transiciones ...................................................57 Figura 24: Pantalla para añadir una condición a la transición ...........................................................................................58 Figura 25: Pantalla para añadir un validador a la condición .............................................................................................58 Figura 26: Pantalla de configuración del validador de incidencia enlazada ......................................................................59 Figura 27: Vista de los validadores de la transición ..........................................................................................................59 Figura 28: Mensaje de error que se produce cuando no se cumple la condición impuesta por el validador .....................59 Figura 29: Detalle del Issue del proyecto ..........................................................................................................................59 Figura 30: Detalle de la incidencia del proyecto con la información de los pesos de las fases ........................................60 Figura 31: Informe de avance, estado de las tareas ...........................................................................................................61 Figura 32: Informe de avance, estado del comienzo de las tareas .....................................................................................61 Figura 33: Informe de avance, Gráfico del informe de avance .........................................................................................62 Figura 34: Informe de avance, estado de finalización de las tareas ..................................................................................62 Figura 35: Informe de avance, plan de medición ..............................................................................................................63 Figura 36: Detalle de la incidencia del informe de estado ................................................................................................63 Figura 37: Informe de estado, identificación del proyecto ................................................................................................64 Figura 38: Informe de estado, avance del proyecto ...........................................................................................................64 Figura 39: Informe de estado, estado de desarrollo ...........................................................................................................65 Figura 40: Informe de estado, Aseguramiento de la calidad del proyecto ........................................................................66 Figura 41: Informe de estado, Informe de riesgos .............................................................................................................66 Figura 42: Informe de estado, plan de seguimiento ...........................................................................................................67 Figura 43: Plan de medición ..............................................................................................................................................67 Figura 44: JIRA de la fundación Apache ...........................................................................................................................77 Figura 45: Incidencia en el JIRA de la compañia Atlassian ..............................................................................................80 Figura 46: Detalle de un Bug en el JIRA de la compañia TSB .........................................................................................81 Figura 47: Flujo de trabajo de las incidencias en JIRA .....................................................................................................82 Figura 48: Descripción del plugin en la pantalla de administración de plugins ...............................................................84 1. INTRODUCCIÓN Esta memoria describe el trabajo realizado durante el proyecto final de carrera. En este apartado se va a hacer una breve introducción sobre el proyecto, la empresa para la cual se realiza, y de las motivaciones y objetivos que han llevado al desarrollo del mismo. 1.1 DESCRIPCIÓN DEL PROYECTO El trabajo realizado consiste en la elaboración de una extensión (plugin) a una aplicación de gestión de proyectos. Dicha aplicación se basa en un conocido software denominado JIRA (Atlassian, 2010) que se encarga de gestionar y mantener información relacionada con las tareas involucradas en el desarrollo de productos software. En nuestro caso, la aplicación JIRA se ha utilizado para la gestión de proyectos en la empresa TSB. TSB Tecnologías para la Salud y el Bienestar, es una empresa dedicada a la implantación y desarrollo de las nuevas tecnologías para el cuidado personalizado de la salud y el bienestar, mejorando la calidad de vida de las personas, y creando nuevas oportunidades de negocio a partir de sus capacidades tecnológicas y de investigación. TSB fue fundada en enero de 2008 como empresa spin-off del Instituto ITACA de la Universidad Politécnica de Valencia. Partiendo de la experiencia de más de diez años de investigación para el sector socio-sanitario. La empresa TSB, Tecnologías para la salud y el bienestar desea obtener la certificación del nivel 2 de CMMI, CMMI (Capability Maturity Model Integration) es un modelo para la mejora y evaluación del rendimiento de los procesos de una organización, que fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Universidad CarnegieMellon para el SEI (Software Engineering Institute). Para la obtención de la certificación, la empresa TSB ha adquirido la herramienta JIRA. JIRA es un producto software desarrollado por la compañía Atlassian para la gestión de proyectos, seguimiento de errores e incidencias (bug tracker, issue tracker), gestión de flujos de trabajo (workflows), gestión de metodologías ágiles de desarrollo. JIRA es altamente adaptable y configurable, permitiendo adaptar la mayoría de los aspectos, tipos de incidencias propios, campos, estados, resoluciones y flujos de trabajos. JIRA esta escrito en java. Incorpora además un sistema de extensiones (plugins) y un interfaz de programación de aplicaciones que permite extender y adaptar JIRA según las necesidades. La empresa TSB desea poder llevar a cabo la planificación, seguimiento, control y gestión de los proyectos software de manera ágil. 1.2 OBJETIVOS DEL PROYECTO Los objetivos del proyecto son: •El desarrollo de extensiones personalizadas sobre la herramienta JIRA. •Se desarrollaran módulos de flujo de trabajo (Workflow) (validadores y condiciones) •Se desarrollarán módulos de informes •Se almacenará la información relativa al control de los proyectos a modo de histórico en una base de datos para su posterior recuperación. Para la realización del proyecto se hará uso de diversas tecnologías dentro del marco del desarrollo web como Java EE, XML, HTML, CSS, C#, SQL, JavaScript así como el propio API de JIRA y otras tecnologías como PicoContainer, Apache velocity, Lucene, Apache maven, ASP .NET. 1.3 ESTRUCTURA La estructura de este documento se compone de nueve secciones. En la segunda sección, marco teórico, se trata de describir la base teórica sobre la que se va a sustentar el proyecto. El proyecto consiste en el desarrollo de una aplicación para la mejora de procesos. En el marco teórico se describe el modelo CMMI para la mejora de procesos. En la especificación de requisitos se describen las características que debe cumplir la aplicación desarrollada durante el proyecto. En análisis y diseño se describe el funcionamiento y el contenido de la aplicación. Esta sección contiene una descripción de los casos de uso y los diagramas de clase de la aplicación JIRA y de las extensiones desarrolladas. En la sección de implementación se describe el proceso de desarrollo del proyecto. Una pequeña descripción de como se desarrollan extensiones para la aplicación JIRA, las tecnologías utilizadas, la estructura de la aplicación y la arquitectura utilizada. En la sección resultados y pruebas se describe de forma breve el proceso de pruebas, y se muestran los resultados producidos por la aplicación. En comentarios se exponen las impresiones obtenidas una vez concluido el proyecto sobre la realización del mismo. En la sección de anexos se exponen documentos de interés para la comprensión del proyecto. En el anexo de Indicadores se describe la función de los indicadores en los informes. En el anexo de metas y practicas se expone un ejemplo de metas y practicas genéricas, útil para la comprensión del estándar CMMI. En el anexo de los procesos en la empresa se definen como están estructurados los procesos en la empresa. El anexo acerca de JIRA trata de explicar de manera sencilla la funcionalidad de la aplicación JIRA. En el anexo casos de uso se muestran las tablas con los casos de uso del proyecto de manera mas extendida. 2. MARCO TEORICO 2.1 CMMI Introducción. Ahora, más que nunca, las compañías desean entregar mejores productos y servicios en menos tiempo y más baratos. Sin embargo, al mismo tiempo en el entorno de alta tecnología del siglo veintiuno, casi todas las organizaciones se han encontrado construyendo productos y servicios cada vez más complejos. Hoy en día es raro que las compañías desarrollen por sí mismas todos los componentes que forman parte de un producto o servicio. Frecuentemente, algunos se construyen en la compañía y otros se adquieren, después todos los componentes se integran en el producto o servicio final. Por ello, las organizaciones deben ser capaces de gestionar y controlar este complejo proceso de desarrollo y de mantenimiento. Los problemas que estas organizaciones encuentran implican soluciones que conciernen a toda la empresa y que requieren una aproximación integrada. La gestión eficaz de los activos de la organización es crítica para el éxito de su actividad. Los CMM (Modelo de Capacidad y Madurez) se concentran en la mejora de los procesos de una organización. Contienen los elementos esenciales de eficacia de los procesos en una o más disciplinas y describen un camino de mejora evolutivo que permite pasar desde procesos inmaduros ad hoc a procesos disciplinados y maduros de mejor calidad y más eficaces. En el mercado actual, existen modelos de madurez, estándares, metodologías y guías que pueden ayudar a una organización a mejorar su modo de operar. Sin embargo, la mayoría de las aproximaciones de mejora disponibles se centran en una parte específica de su actividad, concentrándose en mejorar un área de negocio. El CMMI (Capability Maturity Model Integration) proporciona una oportunidad para evitar o eliminar estos canales y barreras, apoyándose en los modelos integrados que trascienden disciplinas. CMMI para el desarrollo El modelo CMMI para el Desarrollo contempla las buenas prácticas relativas a las actividades de desarrollo y mantenimiento aplicadas a productos y servicios. Trata las prácticas que cubren el ciclo de vida del producto desde la concepción hasta la entrega y el mantenimiento. El énfasis lo pone en el trabajo necesario para construir y mantener el producto completo. Las organizaciones de numerosas industrias, incluyendo la aeroespacial, los bancos, la construcción de ordenadores, el software, la defensa, la fabricación del automóvil y las telecomunicaciones, utilizan el modelo CMMI para el desarrollo. CMMI para el desarrollo contiene prácticas que cubren la gestión de proyectos, la gestión de procesos, la ingeniería de sistemas, la ingeniería del hardware, la ingeniería de software y otros procesos de soporte utilizados en el desarrollo y el mantenimiento. Figura 1: Evolución del modelo CMMI Historia de los CMMs. A partir de noviembre de 1986 el SEI (Software Engineering Institute), a requerimiento del Gobierno Federal de los Estados Unidos de América (en particular del Departamento de Defensa), desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de Figura 2: Metas y practicas 3. ESPECIFICACIÓN DE REQUISITOS 3.1 INTRODUCCIÓN 3.1.1 Propósito El propósito de la especificación de requisitos expuesta a continuación es mostrar al usuario final cual va a ser la funcionalidad del proyecto. Es útil para comprender lo que el cliente quiere, analizar sus necesidades, negociar una solución razonable y que no quede ambigua. A través de esta especificación se determina lo que el sistema va a hacer y las restricciones que va a tener. Además, reducirá el esfuerzo en el desarrollo, servirá como base para la estimación de costes y planificación a la hora de desarrollar la aplicación y será un punto de referencia para procesos de verificación y validación En esta ERS se realizará una descripción general del proyecto, así como una especificación de los requisitos que debe cumplir. 3.1.2 Ámbito El proyecto consiste en el desarrollo de una aplicación de uso interno para la empresa TSB. TSB Tecnologías para la Salud y el Bienestar, es una empresa dedicada a la implantación y desarrollo de las nuevas tecnologías para el cuidado personalizado de la salud y el bienestar. TSB fue fundada en enero de 2008 como empresa spin-off del Instituto ITACA de la Universidad Politécnica de Valencia. Partiendo de la experiencia de más de diez años de investigación para el sector socio-sanitario. La empresa TSB, Tecnologías para la salud y el bienestar desea obtener la certificación del nivel 2 de CMMI. CMMI (Capability Maturity Model Integration) es un modelo para la mejora y evaluación del rendimiento de los procesos de una organización. La aplicación es una extensión de la herramienta JIRA utilizada por lo trabajadores de la empresa para controlar los procesos relativos a los proyectos software. JIRA: Es un producto software desarrollado por la compañía Atlassian con capacidad para la gestión de proyectos, seguimiento de errores e incidencias (bug tracker, Issue tracker), gestión de flujos de trabajo (workflows), gestión de metodologías ágiles de desarrollo. 3.1.3 Visión global A partir de este momento, la especificación de requisitos se centrará en describir la funcionalidad del servicio, características del usuario, restricciones generales y requisitos detectados. 3.1.4 Definiciones siglas y abreviaturas Acción correctiva: Acción tomada para eliminar la causa de una no conformidad detectada u otra situación no deseable NC ISO 9000: 2005 (3.6.2) . La auditoría informática: Es el proceso de recoger, agrupar y evaluar evidencias para determinar si un sistema de información salvaguarda el activo empresarial, mantiene la integridad de los datos, lleva a cabo eficazmente los fines de la organización, utiliza eficientemente los recursos, y cumple con las leyes y regulaciones establecidas. También permiten detectar de forma sistemática el uso de los recursos y los flujos de información dentro de una organización y determinar qué información es critica para el cumplimiento de su misión y objetivos, identificando necesidades, duplicidades, costes, valor y barreras, que obstaculizan flujos de información eficientes. CMMI (Capability Maturity Model Integration) es un modelo para la mejora y evaluación del rendimiento de los procesos de una organización. La gestión de proyectos: Es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. JIRA: Es un producto software desarrollado por la compañía Atlassian con capacidad para la gestión de proyectos, seguimiento de errores e incidencias (bug tracker, Issue tracker), gestión de flujos de trabajo (workflows), gestión de metodologías ágiles de desarrollo. La matriz de la asignación de responsabilidades (RACI por sus siglas en inglés): Se utiliza generalmente para relacionar actividades con recursos (individuos o equipos de trabajo). De esta manera se logra asegurar que cada uno de los componentes del alcance esté asignado a un individuo o a un equipo. No conformidad: De acuerdo a la definición en la norma NC ISO 9000: 2005 (3.1.2), una no conformidad es el incumplimiento de un requisito. Proceso: es un conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa o simultáneamente) con un fin determinado. Un proyecto: Es una planificación que consiste en un conjunto de actividades que se encuentran interrelacionadas y coordinadas, la razón de un proyecto es alcanzar objetivos específicos dentro de los límites que imponen un presupuesto y un lapso de tiempo previamente definidos. Riesgo: La incertidumbre o probabilidad de que ocurra o se realice una eventualidad, la cual puede estar prevista, en este sentido podemos decir que el riesgo es la contingencia de un daño. En funcion de lo anterior podemos afirmar que los riesgos informáticos se refieren a la incertidumbre existente por la posible realización de un suceso relacionado con la amenaza de daño respecto a los bienes o servicios informáticos. Una estructura de descomposición del trabajo también conocido por su nombre en inglés Work Breakdown Structure o WBS, es una estructura exhaustiva, jerárquica y descendente formada por los entregables a realizar en un proyecto. La EDT es una herramienta muy común y crítica en la gestión de proyectos. Una EDT es una presentación simple y organizada del trabajo requerido para completar el proyecto. Existen muchas maneras de organizar la presentación de este trabajo. Por ejemplo, se puede organizar de acuerdo a los Grupos de Proceso del ciclo de vida del proyecto o de las fases (Inicio, Planificación, Ejecución, Control y Cierre), mostrando cada fase como un elemento del nivel más alto. Otra forma de organizarla es teniendo en cuenta las responsabilidades funcionales. Algo importante de recordar es que la EDT documenta el alcance del proyecto, no su plan de ejecución. Un servicio web (en inglés, Web service) es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. La razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada. Flujo de trabajo (workflow): Es una secuencia de pasos conectados, Es una representación de una secuencia de operaciones, cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas. El flujo de trabajo puede considerarse como una vista del trabajo real bajo un cierto aspecto, sirviendo así como una representación virtual de trabajo real. 3.2. DESCRIPCION GENERAL 3.2.1 Perspectiva del producto Mediante la aplicación JIRA los jefes de proyecto establecen: •El calendario del proyecto. •El calendario de las diferentes fases en que se compone el proyecto. •La estimación de la duración de las tareas. •La asignanción de las diferentes tareas y casos de uso, a los desarrolladores. •Control de los plazos del proyecto. •Control de los costos del proyecto. •Control y gestión de las auditorias realizadas sobre el proyecto. •Identificación y gestión de los riesgos surgidos durante el proyecto. •Identificación y control de las no conformidades que puedan surgir durante el proyecto. •Gestión de las acciones correctivas sobre los riesgos y no conformidades encontrados. •Gestión de la asignación de responsabilidades a terceras partes. La aplicación se encargará de generar informes donde se muestra información relativa a los procesos anteriores, además guardará la información recogida en una base de datos para su posterior recuperación. Los administradores son los encargados de adaptar la herramienta JIRA a las necesidades de la empresa mediante: •Gestión de los proyectos, usuarios, roles, etc. •Control de las politicas de seguridad de la herramienta. •Creación de diferentes tipos de indicencias, estados, resoluciones, campos, etc. •Creación de workflows personalizados para las diferentes incidencias. La aplicación contendra modulos con funciones de workflow con objetivo de ayudar a los administradores de JIRA en la labor de personalización de la herramienta. 3.2.2 Funciones del producto Las funciones que llevará a cabo la aplicación son las siguientes: Funciones de flujo de trabajo ("workflow"): ◦Condición de archivo adjunto. Crear una condición del flujo de trabajo que permita una transición de una incidencia solo si esta contiene al menos un archivo adjunto. Asignar la condición a un flujo de trabajo. Editar la condición perteneciente a un flujo de trabajo. ◦Condición de incidencia enlazada. Crear una condición del flujo de trabajo que verifique que la incidencia a realizar la transición contiene cierto número de enlaces a otras incidencias de un tipo dado. Asignar la condición a un flujo de trabajo. Editar la condición perteneciente a un flujo de trabajo. ◦Validador de incidencia enlazada. Actúa de manera similar al módulo de condición pero esta vez es un validador. Consiste en crear un validador de flujo de trabajo que verifique que la incidencia a realizar la transición contiene cierto número de enlaces a otras incidencias de un tipo dado. Asignar la condición a un flujo de trabajo. Editar la condición perteneciente a un flujo de trabajo. ◦Validador de campo especificado. Crear un validador que verifique que al menos un cierto campo de una determinada lista de campos de la incidencia a realizar la transición contiene algún valor. Asignar la condición a un flujo de trabajo. Editar la condición perteneciente a un flujo de trabajo. Informes: ◦Informe de estado. Generar el informe de estado. Generar el informe de estado y evaluar los indicadores. Generar el informe de estado y almacenar los indicadores. ◦Informe de avance Generar el informe de avance. Generar el informe de avance y evaluar los indicadores. Generar el informe de avance y almacenar los indicadores. 3.2.3 Características del usuario Los jefes de proyecto son los encargados de gestionar el proyecto al cual han sido asignados, son los encargados de generar los informes de avance y estado del proyecto. Los administradores se encargan de la creación de los flujos de trabajo, para ello pueden contar con la ayuda de los modulos desarrollados. 3.2.4 Reestriciones generales Para la realización de los informes se tomarán como referencia una serie de plantillas y esquemas proporcionados por la empresa. 3.2.5 Supuestos y dependencias La version de JIRA utilizada es la v3.13. El web service funcionará sobre un servidor web IIS. La base de datos utilizada será SQL Server 2005. Las paginas web mostradas se deberán poder visualizar correctamente en los navegadores web firefox y safari. 3.3 REQUISITOS ESPECIFICOS. Condición de archivo adjunto. Crear una condición del flujo de trabajo que permita una transición de una incidencia solo si esta contiene al menos un archivo adjunto. Condicion de incidencia enlazada. Crear una condición del flujo de trabajo que verifique que la incidencia a realizar la transición contiene cierto número de enlaces a otras incidencias de un tipo dado. Entradas: ◦El número de enlaces. ◦El tipo de enlace. ◦El tipo de condición. Salidas: Se produce una salida para visulización y edición que muestra los datos de configuración. ◦El número de enlaces. ◦El tipo de enlace ◦El tipo de condició Validador de incidencia enlazada. Actúa de manera similar al módulo de condición pero esta vez es un validador. Consiste en crear un validador de flujo de trabajo que verifique que la incidencia a realizar la transición contiene cierto número de enlaces a otras incidencias de un tipo dado. Entradas : ◦El número de enlaces. ◦El tipo de enlace. ◦El tipo de condición. Salidas: Se produce una salida para visulización y edición que muestra los datos de configuración. ◦El número de enlaces. ◦El tipo de enlace. ◦El tipo de condición. Cuando no se cumple la condición del validador se muestra un mensage de error. Validador de campo especificado. Los esquemas de flujo de trabajo, Workflow Scheme, asocian flujos de trabajo con tipos de incidencias. Los flujos de trabajo están representados por la clase Workflow. Los flujos de trabajo contienen una serie de pasos. Los pasos representan a un estado de la incidencia y contienen una serie de transiciones a otros estados. La clase Screen, representa vistas, las vistas pueden contener pestañas, Tab, que contienen campos definidos por los usuarios Custom Field o campos propios de JIRA. Las vistas se pueden asociar a operaciones, como por ejemplo las operaciones que se producen sobre las incidencias, Issue Operation. De esta forma cada vez que se realiza una operación como por ejemplo crear una incidencia, editar una incidencia, ver la pantalla de una incidencia, realizar una transición de un flujo de trabajo etc.. se puede definir una serie de vistas que se mostraran. Un proyecto tiene asociado un esquema de configuración de campos que define un campo para un cierto tipo de incidencia, estos campos pueden ser requeridos, mandatory, cuando un campo tiene la propiedad mandatory el campo no puede estar vacío, Los campos también pueden estar ocultos o visibles. Figura 6: Diagrama de clases de la aplicación JIRA Figura 7: Diagrama de clases de la parte de los informes del plugin La aplicación cuenta con dos clases encargadas de gestionar la configuración del plugin. Esta clases se encargan de identificar las personalizaciones propias (tipos de incidencias propias, campos propios, estados del flujo de trabajo propios, resoluciones de las incidencias propias), de la instancia de JIRA en la que el plugin se está ejecutando. La clase Propiedades de Configuración contiene las funciones asociadas a la configuración, como por ejemplo leer el archivo de propiedades, mientras que la clase Configuración del Plugin contiene constantes utilizadas en el plugin. Las clases Informe de estado e Informe de avance son las encargadas de modelizar los dos informes, ambas clases extienden la clase Informe. La clase Informe contiene ciertas funciones y parámetros comunes a todos los informes del plugin, como por ejemplo la referencia a la clase Service Proxi, encargada de la comunicación con el servicio web y la base de datos, o los parámetros enviados a la capa de presentación, Parámetros de vista. La clase Informe implementa la clase Abstract Report. Que es una clase perteneciente al API de JIRA y que le indica a JIRA que la clase ejecutada es un informe. La clase Abstract Report contiene el método generateReportHTML que debe ser implementado por todas las clases que modelan los informes, en este caso las clases Informe de estado e Informe de Avance. Los informes contienen una clase Indicadores que se encarga de calcular los distintos indicadores. La clase Indicadores devuelve un objeto de la clase Medidas que es un conjunto de objetos de la clase Indicador. Los indicadores contienen una serie de campos: •Un identificador de indicador, cada indicador contiene un identificador que lo define tal como se muestra en el maestro de indicadores. •Un identificador de proyecto que define el proyecto de donde se ha tomado la medida. •Un identificador de informe, que identifica el tipo de informe, estado o avance, y si el informe es de estado y el modo es iteración I2, es decir el informe pertenece a una iteración del proceso I2, identifica la iteración a la que pertenece el indicador. •Valor es la medida tomada por el indicador. •Fecha indica la fecha en la que se ha tomado la medida. •Integridad indica si se ha podido tomar la medida de forma correcta o no se ha podido tomar, debido a la falta de datos o por si se ha producido un error o excepción. Los informes contienen una serie de Items, estas clases envuelven a la clase Issue (Incidencia) del API de JIRA son las encargadas de formatear la información referente a las incidencias. Estas clases son enviadas a la capa de presentación y contienen funciones como getFormatDate. 5. IMPLEMENTACION 5.1 ENTORNO DE DESARROLLO En este apartado se va a presentar el proceso de desarrollo de la aplicación. Para el desarrollo del plugin de JIRA se ha utilizado el JIRA Plugin Developement Kit. JIRA Plugin Developement Kit es una herramienta proporcionada por Atlassian, se puede integrar con un IDE (Eclipse, IDEA, Netbeans) de forma que se crea un proyecto para el IDE escogido con todos los elementos necesarios para desarrollar el plugin. Para el desarrollo del plugin se ha elegido Eclipse como entorno de desarrollo. JIRA Plugin Developement Kit utiliza Apache Maven, el cual se encarga del proceso de compilado del plugin y de obtener las dependencias necesarias. Maven es una herramienta de software para la gestión y construcción de proyectos Java. Maven utiliza un Project Object Model (POM), El Project Object Model es un archivo XML utilizado para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Figura 8: Detalle del espacio de trabajo del entorno de desarrollo La carpeta src contiene el código del plugin. En la carpeta debug se encuentra una instancia de JIRA lista para ser ejecutada como servidor de pruebas. 5.3 DIAGRAMAS DE ESTRUCTURAS Un diagrama de estructura compuesta es un tipo de diagrama de estructura estática en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración. La figura 9 muestra el diagrama de estructuras de la aplicación JIRA, es importante conocer el diagrama de estructuras para comprender el funcionamiento de JIRA, como interactúan sus partes y conocer las tecnologías asociadas. Figura 9: Diagrama de estructuras de la aplicación JIRA Webwork. JIRA es una aplicación WEB, los usuarios interactuan con la aplicación a través de un navegador. JIRA utiliza el marco de trabajo (Framework), WebWork del proyecto OpenSymphony para procesar las peticiones WEB enviadas por los usuarios. Cada petición es manejada por una acción de WebWork que normalmente usará otras clases, como utilidades y manejadores para cumplir su tarea. JIRA utiliza JSP para la capa de presentación. Así que la mayoría de las páginas que se sirven al usuarios en respuesta a sus peticiones son generadas por un JSP. Por lo tanto, para generar una respuesta la acción de WebWork (WebWork Action) utiliza JSP. El desarrollo de los plugins se simplifica, dado que JIRA se encarga de manejar las peticiones WEB. El plugin solo tiene que recoger los parámetros de entrada, y salida. Seraph. Toda la autenticación en JIRA se realiza a través de Seraph, Seraph es un marco de trabajo (Framework) que se encarga de la autenticación a través de la WEB. Seraph es implementado como un filtro, su único trabajo es dada una petición WEB, asociar esta con un usuario particular. Dentro de la aplicación se puede hacer uso de la clase JiraAuthenticationContext, que se encarga del seguimiento de la sesión del usuario y del manejo de todos los parámetros personalizados como los archivos de localización i18n. OSUser. OSUser es un marco de trabajo (Framework) del proyecto OpenSymphony para la gestión de usuarios y grupos. OSUser utiliza PropertySet. PropertySet. PropertySet es un marco de trabajo (Framework) del proyecto OpenSymphony para almacenar un conjunto de propiedades (pares clave/valor) en una particular entidad con un ID único. Una entidad puede modelizar cualquier objeto. Por ejemplo OSUser utiliza PropertySet para almacenar el correo electrónico, el nombre completo y las preferencias de los usuarios. Por lo tanto en el caso de OSUser la entidad representa a un usuario. Utilidades de JIRA y los manejadores de clases. Mucha de la lógica de negocio en JIRA está implementada en cientos de clases de java, estas clases pueden ser simples clases con utilidades o manejadores de objetos. Los manejadores de objetos en JIRA son clases que suelen tener un objetivo especifico, por ejemplo la clase com.atlassian.jira.project.version.VersionManager se utiliza para trabajar con las versiones de los proyectos, com.atlassian.jira.issue.CustomFieldManager se utiliza para trabajar con los campos personalizados de las incidencias. La clase ComponentManager es la responsable de inicializar una gran cantidad de componentes de JIRA, ComponentManager utiliza PicoContainer para resolver todas las dependencias entre componentes, además posee varios métodos estáticos para los objetos que no se pueden instancia a través de PicoContainer. PicoContainer. JIRA utiliza PicoContainer como una factoría central de objetos. PicoContainer es el responsable de instanciar los objetos así como resolver sus dependencias, de esta forma cada objeto instanciado por PicoContainer puede instanciar otro objeto simplemente añadiéndolo como parámetro en su constructor. PicoContainer se encargara de instanciar el objeto, junto con los objetos que pudiera necesitar y devolvérselo al objeto que lo pidió en el constructor. Public StatusReport(SearchProvider searchProvider, JiraAuthenticationContext authenticationContext, CustomFieldManager customFieldManager) En el ejemplo se puede ver la cabecera del constructor de la clase StatusReport que modeliza el informe de estado. Cuando se crea un objeto de la clase StatusReport, PicoContainer se encarga de instanciar los objetos necesarios junto con sus dependencias. En este caso son SearchProvider que provee métodos para realizar búsquedas de incidencias indexadas a través de Lucene, JiraAuthenticationContext 5.4 ARQUITECTURA POR CAPAS Los plugin desarrollados para JIRA, al contener una estructura muy marcada por la propia aplicación se integran perfectamente dentro de la arquitectura por capas. Figura 13: Estructura del sistema desde la perspectiva de capas La capa de presentación esta formada por las plantillas de velocity junto con otros recursos como archivos CSS o javascript, como se ha comentado anteriormente. La lógica de la aplicación esta implementada en las clases java del plugin y las clases de JIRA y del Servicio WEB. Para el acceso a la base de datos JIRA utiliza el marco de trabajo OfBiz como se ha visto anteriormente. El servicio web ha sido implementado con la tecnología .NET de Microsoft. El servicio WEB proporciona una serie de funciones accesibles a través de la red, estas funciones se comunican a través del protocolo SOAP por lo que pueden ser llamadas por cualquier aplicación que entienda dicho protocolo. SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP fue creado por Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web. Dentro del plugin de JIRA se ha implementado un cliente del servicio WEB para acceder a dichas clases. El servicio WEB interactúa con la base de datos mediante DataSets pertenecientes al marco de trabajo ADO .Net de Microsoft. El DataSet de ADO.NET es una representación de datos residente en memoria que proporciona un modelo de programación relacional coherente independientemente del origen de datos que contiene. Un DataSet representa un conjunto completo de datos, incluyendo las tablas que contienen, ordenan y restringen los datos, así como las relaciones entre las tablas. La base de datos se compone de tres tablas. El maestro de indicadores contiene la información relativa a cada uno de los indicadores que se calculan en los informes de los proyectos. La tabla del maestro de indicadores contiene los siguientes campos: ◦Un id del indicador, que identifica a cada indicador de forma única. ◦El nombre del indicador. ◦La fórmula del indicador. ◦El formato del resultado del indicador, si es de tipo numérico o es un porcentaje. ◦Las unidades del resultado. ◦El ámbito en el que se encuentra el indicador. ◦El rango dentro del que se encuentra el resultado producido. ◦El responsable encargado de supervisar el resultado producido por el indicador en el proyecto. El responsable puede ser el jefe de proyecto, el director técnico, el responsable de calidad, el gerente. ◦Frecuencia con la que se calculan las medidas relativas al indicador. ◦Método. ◦Origen de datos, indica de donde se obtienen los datos necesarios para el calculo del indicador. ◦Canal de comunicación. ◦Comentarios. Figura 14: Estructura de la tabla maestro de indicadores de la base de datos De tabla de los objetivos de los indicadores se obtiene la información necesaria para calcular las evaluaciones de los indicadores, las evaluaciones de los indicadores se calculan a partir de una condición y unos objetivos, estos objetivos pueden cambiar con el tiempo, los objetivos se almacenan a modo de histórico de objetivos. Figura 15: Estructura de la tabla objetivos de la base de datos Cada indicador tiene un tipo de condición, esta condición puede ser; mayor que, mayor o igual que, menor que, menor o igual que, entre. Además cada indicador tiene unos objetivos mayores y menores y unos objetivos de referencia, a partir de estos objetivos se calculan las evaluaciones de los indicadores. La tabla de medidas almacena las medidas obtenidas para cada indicador para cada proyecto en un punto dado de tiempo. La tabla de medidas contiene los siguientes campos: ◦Identificador de proyecto, identifica el proyecto al que pertenece la medida. ◦Identificador de indicador, indica de que tipo de indicador es la medida almacenada. ◦Identificador de informe, indica el tipo de informe en el que se ha tomado la medida, informe de estado o de avance, si el informe es de estado y de iteración, entonces en este campo se almacena la clave de la iteración a la que pertenece el informe. ◦Evaluación, la evaluación que obtuvo la medida cuando fue tomada, este valor se almacena puesto que las evaluaciones para una medida pueden cambiar en el tiempo conforme cambian los objetivos. ◦El valor obtenido en el cálculo del indicador. ◦La fecha en la que se tomo la medida. ◦El campo válido indica que la medición obtenida es válida para el cálculo de los indicadores generales de la organización. Figura 16: Estructura de la tabla medidas de la base de datos 6. RESULTADOS Y PRUEBAS 6.1 PRUEBAS La instancia de JIRA de la empresa se ejecuta en un servidor de producción. Como se ha mencionado anteriormente JIRA Development Kit permite ejecutar en local un servidor junto con una instancia de JIRA integrado para la realización de las pruebas. Con el Servicio Web y la base de datos se ha actuado de la misma forma, por una parte se ejecuta la instancia de producción y las pruebas se realizan en una instancia replicada en local. Para las pruebas se ha creado un proyecto de pruebas. Sobre dicho proyecto se han ido efectuando las pruebas. También se ha comprobado que los resultados eran correctos en el servidor de producción sobre proyectos reales. Para la comprobación de los resultados se han utilizado plantillas de excel. Las siguientes figuras muestran ejemplos de las plantillas utilizadas en el proceso de verificación de los indicadores. Figura 17: Plantilla con datos para el cálculo de los indicadores de avance Figura 18: Plantilla con el cálculo de los indicadores de estado Figura 19: Plantilla con los cálculos de los indicadores de estado Figura 20: Plantilla con las desviaciones y los pesos de las fases Figura 21: Plantilla con el calculo de las velocidades de desarrollo 6.2 RESULTADOS Figura 22: Vista de la pantalla de administración de workflows en JIRA En la sección de administración (figura 17) se accede a la sección de administración de flujos de trabajo donde se muestran todos los flujos de trabajo, la descripción de estos, el estado que puede ser activo, inactivo o draft (copia de trabajo de un flujo de trabajo existente). Los flujos de trabajo activos no se pueden editar por lo que se puede hacer una copia de trabajo de un flujo de trabajo para editar y luego publicar. Los esquemas asignan un flujo de trabajo a un proyecto y a un tipo de incidencia determinado. Por ultimo se muestran las operaciones disponibles sobre cada flujo de trabajo. La vista de pasos de un flujo (figura 18) de trabajo muestra los pasos del flujo de trabajo y las transiciones disponibles, donde se puede añadir una transición a un flujo de trabajo, eliminar una transición o editar una transición disponible. Figura 23: Detalle del workflow de pruebas donde se ven los pasos y las transiciones Como se ha visto anteriormente una transición de un flujo de trabajo puede contener condiciones validadores y postfunciones. Finalmente se muestra el informe de estado. En la primera sección del informe se muestra información general del proyecto. Figura 37: Informe de estado, identificación del proyecto La segunda sección del informe de estado muestra una serie de gráficos con la evolución los indicadores de avance del proyecto durante la duración del mismo. Figura 38: Informe de estado, avance del proyecto De forma similar en la tercera sección del informe de estado se muestran gráficos del estado de desarrollo del proyecto. Figura 39: Informe de estado, estado de desarrollo La cuarta sección del informe de estado muestra el estado de las auditorias del proyecto, un resumen de las no conformidades surgidas y las acciones correctivas para cada no conformidad. Figura 40: Informe de estado, Aseguramiento de la calidad del proyecto figura 36 muestra los riesgos identificados en el proyecto junto con las acciones correctivas tomadas para cada riesgo. Figura 41: Informe de estado, Informe de riesgos La figura 37 muestra el plan de seguimiento. Se muestra la matriz de asignación de responsabilidad. Figura 42: Informe de estado, plan de seguimiento Por ultimo en el plan de medición se muestran los indicadores calculados durante el informe de estado junto con la evaluación de estos. Figura 43: Plan de medición 7. CONCLUSIONES Durante la realización del proyecto he obtenido una gran experiencia laboral, como acercamiento al desarrollo de aplicaciones profesionales. He aprendido una gran cantidad de nuevas tecnologías, entornos de desarrollo, herramientas de construcción de aplicaciones. He aprendido a manejarme y saber adaptarme ante nuevas tecnologías. La experiencia también me ha servido como un acercamiento a la gestión de proyectos, desde la propia terminología utilizada hasta las metodológias y estandares propios de la gestión de proyectos. JIRA se desvela como una herramienta muy potente para la gestión de proyectos, especialmente para la gestión de proyectos software por su gran capacidad de integración con otros componentes y la facilidad de personalización y de desarrollo que ofrece. Ha sido muy importante el factor humano durante la realización del proyecto, trabajar con un equipo de personas. Por último no quisiera dejar la oportunidad de agradecer al equipo humano de TSB por la experiencia vivida junto a ellos. Ampliaciones futuras. El desarrollo de la plicación, continua. Entre los planes de futuro se encuentran, la mejora de la localización, la posibilidad de generar los informes en distintos idiomas, creación de nuevos informes, la mejora de las busquedas en JIRA, mediante algún modulo buscador. Se están estudiando nuevas mejoras en el sistema. También se esta estudiando la creación de una aplicación para la gestión del maestro de indicadores que realice el cálculo de los indicadores organizativos de la empresa etc... 8. REFERENCIAS •http://java.sun.com/javaee/reference/ •http://www.atlassian.com/software/jira/ •http://confluence.atlassian.com/display/JIRA03x/JIRA+Development+Hub •http://jira.atlassian.com/secure/Dashboard.jspa •http://maven.apache.org/ •http://velocity.apache.org/ •http://www.picocontainer.org/ •http://www.w3c.es/ •http://www.sei.cmu.edu/cmmi/ •http://lucene.apache.org/java/docs/ •https://issues.apache.org/jira/secure/Dashboard.jspa •http://www.tsbtecnologias.es/inicio/index.php •http://msdn.microsoft.com/es-es/default.aspx •http://en.wikipedia.org/ •http://www.bibliojuridica.org/libros/2/909/5.pdf •http://www.monografias.com/trabajos55/organizaciones-con-controlcalidad/organizaciones-con-control-calidad.shtml 9. ANEXOS 8.1 INDICADORES Un proceso efectivo de medición y análisis (MA) proporciona una base adecuada de entendimiento de las capacidades de desarrollo, lo que permite definir planes viables para el desarrollo de productos y la prestación de servicios de calidad. Las medidas permiten detectar tendencias y anticipar problemas y, por lo tanto, permite establecer un mejor control de los costes, una reducción de los riesgos, mejorar la calidad y asegurar la consecución de los objetivos de negocio. La política de Medición y Análisis especifica las particularidades del proceso S2 de medición y análisis de TSB Tecnologías, determinando como se deben especificar los indicadores, como se deben realizar las medidas y cuales son los criterios para analizar y comunicar los indicadores. Toda esta información será recogida en el Maestro de Indicadores, que se mantendrá actualizado en cada ciclo de Medición y Análisis de la empresa. El responsable de la recogida de los indicadores de proyecto será el Jefe de Proyecto dentro de sus tareas de seguimiento del mismo. Para ello, cada vez que un indicador deba ser calculado según su frecuencia, el Jefe de Proyecto rellena una columna nueva en el Cuadro de Mando de Indicadores del Proyecto. Estos valores deben ser incorporados a los informes de seguimiento del proyecto en cuestión. Maestro de indicadores: ID Nombre Unidades COPP Cobertura del plan de pruebas % COST1 Desviación del coste de las tareas de análisis inicial % COST2 Desviación del coste de las tareas de estimación, viabilidad y oferta comercial % COST3 Desviación del coste de las tareas de planificación % COST4 Desviación del coste de las tareas de análisis % COST5 Desviación del coste de las tareas de construcción % COST6 Desviación del coste de las tareas de verificación % COST7 Desviación del coste de las tareas de seguimiento % COST8 Desviación del coste de las tareas de implantación % COST9 Desviación del coste de las tareas de cierre % COST10 Desviación del coste de las tareas de calidad % COST11 Desviación del coste de las tareas de gestión del cambio % COST12 Desviación del coste de las tareas de gestión de la configuración % CPTP Esfuerzo estimado del trabajo planificado horas CPTR Esfuerzo estimado del trabajo realizado horas CRTR Esfuerzo real del trabajo realizado horas DESIA Desviación de las tareas de análisis de la iteración % DESIC Desviación de las tareas de construcción de la iteración % DESIV Desviación de las tareas de verificación de la iteración % DESV1 Desviación de las tareas de análisis inicial % DESV2 Desviación de las tareas de estimación, viabilidad y oferta comercial % DESV3 Desviación de las tareas de planificación % DESV4 Desviación de las tareas de análisis % DESV5 Desviación de las tareas de construcción % DESV6 Desviación de las tareas de verificación % DESV7 Desviación de las tareas de seguimiento % DESV8 Desviación de las tareas de implantación % DESV9 Desviación de las tareas de cierre % DESV10 Desviación de las tareas de calidad % DESV11 Desviación de las tareas de gestión del cambio % DESV12 Desviación de las tareas de gestión de la configuración % DWBS Desviación de las tareas % ECEE Eficacia de corrección de errores % EEDF Eficacia de eliminación de defectos % EFG1 Efectividad de las fases de concepción del proyecto N / A EFRI Efectividad de eliminación de riesgos AC / riesgos EFTI Efectividad test interno defectos / PCUs ENG1 Eficiencia de las fases de concepción del proyecto % EOFR Coste de la oferta por proyecto € / h FRCI Fallos en la recogida o cálculo de indicadores NC ICE Índice de variación del coste N / A IEP Índice de variación de la planificación N / A OHG1 Overhead de las fases de concepción del proyecto % PPCM Porcentaje de cumplimiento del proceso de CM NC PPCU Pantallas por punto de caso de uso analizado pantallas / PCUs PRFA Progreso de la fase de análisis % PRFC Progreso de la fase de construcción % PRFGC Progreso de la fase de gestión del cambio % PRFV Progreso de la fase de verificación % RIES Número de riesgos del proyecto riesgos / PUR RIPO Riesgos identificados tras la fase de planificación riesgos / PUR SGCA Adherencia a los procesos del SGC NC TMCA Tiempo medio de cambio horas / cambio TPCU Casos de test por punto de caso de uso analizados casos test / PCUs TVDA Tiempo de vida medio de las desviaciones abiertas por indicador días / desviación VELA Velocidad de desarrollo de las tareas de análisis horas / PCUs VELC Velocidad de desarrollo de las tareas de construcción horas / PCUs VELD Velocidad de desarrollo horas / PCUs VELGC Velocidad de desarrollo de las tareas de gestión del cambio horas / PCUs VELV Velocidad de desarrollo de las tareas de verificación horas / PCUs VELIA Velocidad de desarrollo de las tareas de análisis de la iteración horas / PCUs VELIC Velocidad de desarrollo de las tareas de construcción de la iteración horas / PCUs VELIGC Velocidad de desarrollo de las tareas de gestión del cambio de la iteración horas / PCUs VELIV Velocidad de desarrollo de las tareas de verificación de la iteración horas / PCUs WEIG1 Peso de las tareas de análisis inicial % WEIG2 Peso de las tareas de estimación viabilidad y oferta % WEIG3 Peso de las tareas de planificación % WEIG4 Peso de las tareas de análisis % WEIG5 Peso de las tareas de construcción % WEIG6 Peso de las tareas de verificación % WEIG7 Peso de las tareas de seguimiento % WEIG8 Peso de las tareas de implantación % WEIG9 Peso de las tareas de cierre % WEIG10 Peso de las tareas de calidad % WEIG11 Peso de las tareas de gestión del cambio % WEIG12 Peso de las tareas de gestión de la configuración % 8.2 CMMI METAS Y PRACTICAS En este apendice se muestra un ejemplo de practica y meta generica para la mejora de procesos propuesta por CMMI. Un ejemplo de meta generica sería: G G 2 INSTITUCION A LIZ A R UN PR O C E S O G E S TION A D O El proceso está institucionalizado como un proceso gestionado. Un ejemplo de practica generica para esta meta sería: GP 2.8 MONITORIZAR Y CONTROLAR EL PROCESO Monitorizar y controlar el proceso frente al plan para realizar el proceso y tomar las acciones correctivas apropiadas. El propósito de esta práctica genérica es realizar la monitorización y el control directo del proceso día a día. Se mantiene una visibilidad apropiada del proceso, por lo que se pueden tomar acciones correctivas apropiadas cuando sea necesario. Monitorizar y controlar el proceso involucra medir los atributos apropiados del proceso o de los productos de trabajo producidos por el proceso. Para más información sobre la monitorización y el control del proyecto y la toma de acciones correctivas, consúltese el área de proceso de Monitorización y control de proyecto. Para más información sobre la medición consúltese el área de proceso de Medición y análisis. Subprácticas 1. Medir el rendimiento real frente al plan de realización del proceso. Las medidas son del proceso, de sus productos de trabajo y de sus servicios. 2. Revisar los logros y los resultados del proceso frente al plan de realización del proceso. 3. Revisar las actividades, el estado y los resultados del proceso con el nivel de gerencia inmediato responsable del proceso e identificar los problemas. Las revisiones pretenden proporcionar al nivel de gerencia inmediato la visibilidad apropiada del proceso. Las revisiones pueden ser periódicas o por eventos. 4. Identificar y evaluar los efectos de las desviaciones significativas del plan de realización del proceso. 5. Identificar los problemas en el plan de realización del proceso y en la ejecución del mismo. 6. Tomar acciones correctivas cuando los requerimientos y los objetivos no se satisfacen, cuando se identifican problemas o cuando el progreso difiere significativamente del plan de realización del Figura 45: Incidencia en el JIRA de la compañia Atlassian Las versiones son puntos en el tiempo de un proyecto. Los issues pueden estar asociados a diferentes versiones de un proyecto, esto puede ser útil en proyectos que evolucionan a través de versiones, como por ejemplo los proyectos software. Para estos casos lo issues contienen dos campos que los relacionan con la versión de un proyecto. Affects version(s), la versión, versiones de un proyecto en las que se manifiesta un issue (por ejemplo un bug software). Fix version(s), la versión en la que un issue se resuelve. Las versiones pueden estar en el estado Released, Unreleased o Achieved. Figura 46: Detalle de un Bug en el JIRA de la compañia TSB Usuarios en JIRA. Representan a las personas que usarán la aplicación, los usuarios son quienes han de asignar incidencias y trabajar en ellas. Los administradores se encargan del adecuado funcionamiento de la aplicación. Permisos en JIRA. JIRA posee un sistema de permisos que permite configurar quien acede a los recursos de JIRA y que acciones pueden llevar a cabo. Los permisos son gestionados por los esquemas de permisos, los esquemas de permisos permiten definir permisos para usuarios, grupos y roles en cierto contexto, permisos globales, permisos para un proyecto o niveles de seguridad de los issues. Workflows en JIRA. El workflow (flujo de trabajo) Es un conjunto de pasos y transiciones que atraviesa una incidencia durante su ciclo de vida. Los workflows normalmente representan “procesos de negocio”. Un estado representa una etapa en el flujo de trabajo para una incidencia. Una incidencia solo puede estar en un único paso en un instante de tiempo. Cada paso tiene asociado un estado. El workflow por defecto de JIRA tiene la siguiente forma, los recuadros representan los pasos del workflow mientras que las lineas representan las transiciones. Figura 47: Flujo de trabajo de las incidencias en JIRA Las transiciones llevan a una incidencia de un estado al siguiente, las incidencias cambian de estado mediante transiciones. Las transiciones pueden tener una serie de propiedades: Conditions, Determinan si un issue puede empezar la transición desde un paso al siguiente, se debe de cumplir con la condición definida para poder realizar la transición. Validator, Los validadores son parecidos a los Conditions, se diferencian en que en los validadores se permite comenzar la transición. Se suelen usar para una vez cumplidas las condiciones, comprobar que cualquier campo requerido es introducido durante la transición. Post Functions, son eventos automáticamente lanzados inmediatamente después de la transición. Cada proyecto tiene asociado un worflow scheme, los workflow schemes a su vez asocian tipos de issues y workflows. Un proyecto por lo tanto podrá tener diferentes workflows para diferentes tipos de issues. O dicho de otra forma las incidencias de diferentes tipos pueden estar asociadas a diferentes workflows y por lo tanto tener estados y transiciones diferentes. Plugins en JIRA. Como se ha comentado anteriormente JIRA incorpora un sistema de plugins propio. Además incorpora un API propio. Los plugins son archivos .jar que contienen el código, recursos (principalmente plantillas de velocity, aunque puede contener otros recursos) y un archivo descriptor XML, sirven para añadir nueva funcionalidad o extender una funcionalidad existente. Cada plugin está compuesto de módulos, existen distintos tipos de módulos en JIRA dependiendo de la funcionalidad que se desea añadir. Figura 48: Descripción del plugin en la pantalla de administración de plugins 8.5 CASOS DE USO Caso de Uso Generar el informe. Descripción Generar las secciones del informe que no precisan evaluación. Actor Jefe de proyecto. Resumen El jefe de proyecto accede a la pantalla del informe a través del proyecto. Introduce los datos del informe. La aplicación muestra un informe con la información referente al progreso del proyecto. Precondiciones Estar dado de alta en la aplicación JIRA y pertenecer al grupo jefes de proyecto del proyecto especificado. El proyecto modelado en JIRA debe cumplir con ciertas especificaciones: Debe estar modelado conforme a una estructura de descomposición del trabajo (WBS) en árbol, grupos de tareas que representan fases del proyecto y que agrupan a otros grupos de tareas y tareas. Debe contener una incidencia con la información del proyecto, con los campos requeridos. Postcondiciones Flujo de eventos En la aplicación JIRA: Seleccionar el proyecto. Entrar en la pantalla de proyecto. Seleccionar el informe (Informe de avance, informe de estado). En la pantalla del informe: Seleccionar el Modo “generar el informe”. Seleccionar el tipo de informe a generar (Informe de iteración / release, final del proyecto, final de la fase G1, final de la fase G2). Seleccionar la incidencia de la iteración o release. Excepciones La selección del modo de informe como del tipo de informe solo se realiza si se ha seleccionado el informe de estado. La selección de la iteración release solo se realiza si el tipo de informe es de iteración / release Caso de Uso Generar el informe y obtener las evaluaciones. Descripción Generar todas las secciones del informe junto con los indicadores y obtiene la evaluación de los indicadores teniendo en cuenta las condiciones que obtiene del maestro de indicadores almacenado en la base de datos. Actor Jefe de proyecto. Resumen El jefe de proyecto accede a la pantalla del informe a través del proyecto. Introduce los datos del informe. La aplicación muestra un informe con la información referente al progreso del proyecto y muestra la evaluación de los indicadores del proyecto. Precondiciones Estar dado de alta en la aplicación JIRA y pertenecer al grupo jefes de proyecto del proyecto especificado. El proyecto modelado en JIRA debe cumplir con ciertas especificaciones: Debe estar modelado conforme a una estructura de descomposición del trabajo (WBS) en árbol, grupos de tareas que representan fases del proyecto y que agrupan a otros grupos de tareas y tareas. Debe contener una incidencia del proyecto, con los campos requeridos. Postcondiciones Flujo de eventos En la aplicación JIRA: Seleccionar el proyecto. Entrar en la pantalla de proyecto. Seleccionar el informe (Informe de estado, Informe de avance). En la pantalla del informe: Seleccionar el Modo “generar el informe y almacenar indicadores”. Seleccionar el tipo de informe a generar (Informe de iteración / release, final del proyecto). Seleccionar la incidencia de la iteración o release. Excepciones La selección del modo de informe como del tipo de informe solo se realiza si se ha seleccionado el informe de estado. La selección de la iteración release solo se realiza si el tipo de informe es de iteración / release Caso de Uso Generar el informe y almacenar los indicadores. Descripción Generar todas las secciones del informe, además almacena los indicadores generados en una base de datos para su posterior uso. Actor Jefe de proyecto. Resumen El jefe de proyecto accede a la pantalla del informe a través del proyecto. Introduce los datos del informe. La aplicación muestra un informe con la información referente al progreso del proyecto y muestra la evaluación de los indicadores del proyecto. Precondiciones Estar dado de alta en la aplicación JIRA y pertenecer al grupo jefes de proyecto del proyecto especificado. El proyecto modelado en JIRA debe cumplir con ciertas especificaciones: Debe estar modelado conforme a una estructura de descomposición del trabajo (WBS) en árbol, grupos de tareas que representan fases del proyecto y que agrupan a otros grupos de tareas y tareas. Debe contener una incidencia del proyecto, con los campos requeridos. Postcondiciones Los indicadores generados por el informe se almacenan en la base de datos. Flujo de eventos En la aplicación JIRA: Seleccionar el proyecto. Entrar en la pantalla de proyecto. Seleccionar el informe (Informe de estado, Informe de avance). En la pantalla del informe: Seleccionar el Modo “generar el informe y almacenar indicadores”. Seleccionar el tipo de informe a generar (Informe de iteración / release, final del proyecto). Seleccionar la incidencia de la iteración o release. Excepciones La selección del modo de informe como del tipo de informe solo se realiza si se ha seleccionado el informe de estado. La selección de la iteración release solo se realiza si el tipo de informe es de iteración / release Caso de Uso Añadir condición / validador Descripción Añade una condición o validador entre los disponibles a un paso de un flujo de trabajo concreto. Actor Administrador Resumen El administrador accede a la pantalla de edición del flujo de trabajo. Añade una condición o validador. Introduce los datos de configuración. Precondiciones Estar dado de alta en la aplicación JIRA y poseer permisos globales de administración de JIRA. Solo se pueden editar los flujos de trabajo inactivos, se pueden crear borradores de los flujos de trabajo activos para ser editados. Postcondiciones Se crea una nueva condición o validador en un paso de un flujo de trabajo concreto. Flujo de eventos El administrador accede a la pantalla de edición del paso del flujo de trabajo. Añade una condición o validador. La aplicación muestra la pantalla de configuración de la condición o validador junto con los campos de configuración. El administrador introduce los datos de configuración. La aplicación muestra la pantalla del paso del flujo de trabajo con la nueva condición o validador en la lista de condiciones y validadores del paso de flujo de trabajo. Excepciones Algunas condiciones o validadores pueden no necesitar parámetros de configuración, como por ejemplo la condición de archivo adjunto.