Autores: Mónica Fernanda Cortés Querales Diana Milena Blanco Moreno. Dirección: María Consuelo Franky

Transcripción

1 Guía metodológica para la gestión de proyectos ágiles de software integrando herramientas de seguimiento de actividades, integración continua y repositorio distribuido de versiones. Autores: Mónica Fernanda Cortés Querales Diana Milena Blanco Moreno Dirección: María Consuelo Franky PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2014

2 Tabla de contenido Tabla de ilustraciones Aspectos generales Contexto Objetivo de la guía Alcance A quién va dirigida la guía? Marco de referencia Metodologías ágiles Valores Principios Tipos de metodologías agiles Scrum A. Equipo Scrum B. Eventos en Scrum Extreme Programming A. Buenas prácticas Disciplined Agile Delivery A. Roles B. Ciclo de vida AUP Ágil A. Ciclo de vida Integración Continua Prácticas para la integración continua Características generales Control de versiones Conceptos básicos Control de versiones locales Control de versiones centralizadas Control de versiones distribuidas Ambientes colaborativos Facilidades ofrecidas por los ambientes colaborativos Manejo de actividades... 29

3 3. Buenas prácticas y herramientas seleccionadas Mejores prácticas de las metodologías agiles Mejor metodología ágil Mejor metodología para cada grupo de criterios Mejores criterios de las metodologías agiles para el desarrollo de la guía Herramientas seleccionadas y Plugins Jenkins Características generales Mylyn Características generales Git Descripción del entorno integrado Eclipse Indigo Guía Metodología Integración Visión global del sistema Arquitectura de Despliegue del sistema Instalación del Entorno Eclipse servidor y base de datos Instalación e integración de las herramientas A. Ambiente colaborativo Mylyn B. Repositorio de versiones distribuido Git C. Integración continua con Hudson Pruebas del ambiente integrado Ejecución del proceso de gestión de proyecto de software basado en metodologías ágiles Inicio Configuración de tracker Elaboración Crear tareas Desarrollo Proceso de desarrollo Desarrollo de una tarea Transición Realizar pruebas... 85

4 5. Referencias Anexos Manual de instalación... 90

5 Tabla de ilustraciones Ilustración 1: ciclo de vida con extensión de Scrum Ilustración 2: ciclo de vida y etapas Agil Unified Proces. Tomado de: The Agile Unified Process (AUP) lifecycle, Ilustración 3: Flujo integración continua, tomado de: Integración Continua en Proyectos Ágiles de Software, Ilustración 4: Proceso de ramificado. Tomado de: Sistema de control de versiones, Ilustración 5: Control de versiones distribuida. Tomado de: Sistemas de control de versiones distribuidos, Ilustración 6: Git almacena la información como instantáneas. Tomado de: Fundamentos de Git, Ilustración 7 visión global de la arquitectura Ilustración 8 Diagrama de despliegue datos Ilustración 9 Pasos para instalación e integración Ilustración 10: Eclipse Marketplac Ilustración 11: despliegue plugins Ilustración 12: Características plugin Ilustración 13: Instalación Mylyn Ilustración 14: ventana de tareas Ilustración 15:task list Ilustración 38: ingreso Eclipse Marketplace Ilustración 39: SELECCIONAR repositorio git Ilustración 40: realizar commit sobre la tarea agregar funcionalidad eliminar book Ilustración 48: ADD BUILD SERVER Ilustración 49: SERVIDOR HUDSON Ilustración 50: PROPIEDADES DEL SERVIDOR Ilustración 51: MONITOREO DE PRUEBAS Ilustración 52: NOTIFICAR PRUEBAS Ilustración 53: COMMIT Ilustración 54:HISTORIAL DE CAMBIOS Ilustración 55: EMPAQUETADO Ilustración 56: Fases Vs Roles Ilustración 57: crear nueva categoría Ilustración 58: Asignar nombre categoría Ilustración 59: nuevo query Ilustración 60: seleccionar repositorio Ilustración 61: asignar nombre al tracker remoto... 60

6 Ilustración 16: categorías Ilustración 17: visualizar tareas Ilustración 18: new task Ilustración 19: tipo de tarea Ilustración 20: configuración de tareas Ilustración 21: Servidor Bugzilla Ilustración 22: Crear cuenta Ilustración 23: Agregfar repositorio bugzilla Ilustración 24: instalar bugzilla Ilustración 25: instalar repositorio Ilustración 26: Eclipse org Ilustración 27: Creacion tarea Ilustración 28: Crear nuevo bug Ilustración 29: Nombre de una tarea Ilustración 30: Product task Ilustración 31: Prioridad y componente de la tarea Ilustración 32: ASOCIAR elementos a la tarea Ilustración 33: CRONOGRAMA de la tarea Ilustración 34: descripcion tarea Ilustración 35: Asignar tarea Ilustración 36: propiedades bug Ilustración 37: parámetros query Ilustración 62: proceso de desarrollo Ilustración 63: Notificar tarea Ilustración 64: identificar clases para realizar tarea Ilustración 65: Desarrollar método Ilustración 66: Agregar método a la clase EJB Ilustración 67: identificar método Ilustración 68: realizar commit Ilustración 41: HISTORIAL código Ilustración 42: repositorio git Ilustración 43: página principal Github Ilustración 44: Crear cuenta Github Ilustración 45: Crear nuevo repositorio Ilustración 46: creación repositorio Github Ilustración 47: aplicación GITHUB Ilustración 69: validar tarea Ilustración 70: cambiar estado Ilustración 71: Sincronizar Ilustración 72: sincronizar en git Ilustración 73: notificar errores Ilustración 74: Agregar el servidor hudson y seleccionar la aplicación Ilustración 75: ver resultado... 86

7 1. Aspectos generales 1.1. Contexto Los ambientes de desarrollo colaborativo han sido utilizados con el fin de automatizar y facilitar la gestión de los proyectos de software de las empresas. [1]. Estos ambientes son principalmente aplicaciones en línea que permiten la gestión de un proyecto de software por medio del control de tareas, la puesta a disposición de los diferentes documentos del proyecto a los interesados, y los mecanismos de comunicación entre ellos. Sin embargo las empresas y en especial los gerentes o líderes técnicos no saben utilizar estas herramientas de desarrollo colaborativo, de tal manera que no sacan provecho a todas sus funcionalidades. Por otro lado para la gestión de proyectos de software no se cuenta con metodologías definidas para seguir cada uno de los procesos del desarrollo del software, lo cual genera retrasos en ejecución de actividades, inconsistencia en los entregables, falta de comunicación con los interesados, entre otros. No obstante se están utilizando con mayor frecuencia metodologías de desarrollo ágil, ya que éstas se basan en valores de simplicidad, comunicación, realimentación y coraje [2] De esta manera se debe tener en cuenta diferentes aspectos para la gestión de proyectos de software, como los nombrados anteriormente; sin embargo existen otras funcionalidades importantes para la ejecución de los proyectos, como por ejemplo la ubicación de la información que será accedida por los miembros del equipo de desarrollo, ya que en muchas ocasiones ésta se encuentra dispersa y en constante cambio. Por tal motivo es necesario utilizar herramientas de control de versiones distribuido, la cual permite que las personas interesadas no solo descarguen la última versión de los archivos, sino que también repliquen completamente el repositorio [3]. Así mismo otro de los aspectos importantes es la integración continua, que es una práctica para el desarrollo de software, que permite a los miembros del equipo de desarrollo integrar su trabajo frecuentemente, con el fin de detectar errores de integración y ejecución [4]. En la presente guía se desea integrar estas funcionalidades en un solo ambiente (mediante plugins para el IDE Eclipse), a través del uso de software libre, para permitir la gestión de proyectos de software que tengan como base las buenas prácticas de las metodologías agiles.

8 1.2. Objetivo de la guía El objetivo de esta guía, es mostrar paso a paso la instalación, configuración y uso de diferentes herramientas de software libre, para le gestión de proyectos de software, a través del uso de plugins en el IDE eclipse. Así mismo esta guía tiene como objetivo utilizar las buenas prácticas de las metodologías áiles para el desarrollo de un proyecto de software, así como también aclarar conceptos de funcionalidades como gestores de tareas, ambientes colaborativos, integración continua y el control de versiones distribuido Alcance El alcance de esta guía metodológica, consiste en todo aquel grupo de personas, (desarrolladores, líder de proyectos, probador, analista, entre otros) interesadas en crear y utilizar un entorno para la gestión de proyectos de software en base a las metodologías ágiles. Así mismo la implementación de esta guía metodológica ayudará a las organizaciones a gestionar proyectos, en donde su equipo de trabajo este entre las 15 herramienta permitirá tener un máximo de 20 roles asignados. y 20 personas, puesto que la 1.4. A quién va dirigida la guía? Esta guía metodológica está dirigida a estudiantes y grupos de personas que desean desarrollar un proyecto de software bajo las buenas prácticas de las metodologías ágiles. De esta manera estas personas podrán gestionar proyectos de software, a través de la asignación de tareas al equipo de trabajo, unión y ejecución de pruebas sobre el código fuente y por ultimo contar con un repositorio distribuido de versiones.

9 2. Marco de referencia 2.1. Metodologías ágiles Existen diferentes procesos para el desarrollo de software, inicialmente se encuentran las propuestas tradicionales, las cuales se centran en el control del proceso de una manera rigurosa, de tal manera que se establecen los artefactos y herramientas que se van a utilizar, [5] así pues si existe algún cambio en los requerimientos o en el desarrollo del producto estos marcos pueden presentar algunos inconvenientes, por tanto surgieron las metodologías ágiles para satisfacer los posibles variantes en el proyecto pero manteniendo siempre la calidad del producto resultante [6] Valores Las metodologías ágiles cuentan con valores principales que deben soportar el desarrollo de software, enunciados a continuación [7] [8]: 1. Las personas y su interacción son más importantes que los procesos y las herramientas: las metodologías ágiles valoran el recurso humano, teniendo en cuenta las capacidades que tiene cada miembro del equipo de trabajo. 2. Es más importante el software (soluciones) funcionando que la documentación excesiva: se debe reconocer la importancia de la documentación de la aplicación o proyecto, no obstante se debe hacer una documentación excesiva si no la necesaria 3. Es mejor crear un ambiente de colaboración y confianza por encima de negociación del contrato: es necesaria la continua participación del cliente y de los interesados para definir qué es lo que se espera del proyecto. 4. Es preferible responder al cambio que seguir un plan: en el transcurso de la creación de software es posible se den algunos cambios, por tal motivo no se debe tener una planificación estricta, sino que el proceso de desarrollo debe ser flexible, adecuándose a los cambios que se presenten.

10 Principios El manifiesto ágil cuenta con doce principios, los cuales son características que diferencian un proceso tradicional a uno ágil, enunciados a continuación [9]: 1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de Software que le aporte un valor. 2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. 6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. 7. El software que funciona es la medida principal de progreso. 8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. 9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. 12. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.

11 Tipos de metodologías agiles Scrum Scrum es una metodología para que los equipos trabajen juntos para el desarrollo de un producto, en donde su desarrollo se realiza a través de pequeñas piezas, en donde ésta estrategia aumenta la creatividad y permite al equipo tener retroalimentación y construir un proyecto exactamente como se espera [10]. De esta manera Scrum estructura el trabajo en ciclos llamados sprints, los cuales son iteraciones de trabajo con una duración típica de dos a cuatro semana, en donde en cada sprint se desarrollan requerimientos del cliente, llamados historias de usuario. Al final de cada sprint, se entrega un producto potencialmente comerciable. [11] Características generales A continuación se enunciaran las características generales de la metodología ágil Scrum [12] [13] o o o o o o o o o o o Difícil de dominar. Fácil de entender. Equipos auto-dirigidos y auto- organizados. Iteraciones de 30 días. Comunicación directa entre el cliente y el equipo de trabajo. Desarrollo incremental. Flexibilidad y adaptación. Resultados anticipados. Fomenta la motivación del equipo de trabajo. El desarrollo del trabajo se centra en lo comprometido, transparencia y visibilidad. Equipos de trabajo multi- funcionales.

12 A. EQUIPO SCRUM El equipo de trabajo está conformado por el equipo de desarrollo, el dueño del producto y un Scrum Master, en donde los miembros del proyecto están encargados de organizarse ellos mismos, en donde cada persona tiene todas las competencias para ejecutar una tarea o actividad. [13]. Propietario del producto (The product owner) Es el responsable de maximizar el valor del producto y trabaja en conjunto al equipo de desarrollo, de tal manera que es el encargado de asegurar que el equipo trabaje de acuerdo a las necesidades del negocio. Así mismo el propietario del producto escribe historias de usuario, las prioriza, y las coloca en el Product Backlog (Documento de alto nivel del proyecto). Equipo de desarrollo (The Development Team) Está formado por profesionales que se encargan de desarrollar cada una de las piezas de trabajo de cada sprint, de tal manera que trabajan de manera incremental. Los equipos de trabajo tienen las siguientes características: Auto- organizados: el mismo equipo de trabajo define la forma y ejecución del proyecto Multi-funcional: todos los miembros del equipo tienen las mismas habilidades necesarias para cumplir con las exigencias del cliente. No se reconocen sub-equipos, es decir que todo el equipo de trabajo, se desenvuelve conjuntamente. Los miembros del equipo pueden tener habilidades especializadas o áreas de enfoque, sin embargo su trabajo pertenece a todo el equipo de desarrollo. Scrum Master El Scrum Master es el responsable de orientar, entrenar, enseñar y ayudar a al equipo y hacer que estos tengan una comprensión del entorno y de la metodología de manera adecuada.

13 B. EVENTOS EN SCRUM Los eventos son utilizados para crear regularidad y reducir reuniones, en donde cada uno de los eventos tiene una duración y cada vez que comienza un sprint esta no puede cambiar. Los eventos están diseñados para permitir transparencia en la ejecución del proyecto, así como una rigurosa inspección del código. [13] Sprint Los ciclos de trabajo son llamados sprint, en donde se lleva a cabo de desarrollo de proyecto, y tiene una duración máxima de 4 semanas, de tal manera que un nuevo sprint se inicia inmediatamente el sprint anterior termina sin dejar espacios intermedios En cada Sprint contiene planificación del siguiente sprint, trabajo de los desarrolladores, revisión y retrospectiva, de esta manera durante cada sprint [13]: No se realizan cambios que podría poner en peligro el objetivo del Sprint. Los objetivos de calidad no disminuyen. El ámbito de aplicación puede ser aclarado y re-negocia entre el propietario del producto y el Desarrollo Cada Sprint tiene una definición de lo que se va a construir, un diseño y plan flexible que guiará la construcción de ésta, el trabajo, y el producto resultante. Cancelación de un Sprint Un Sprint puede ser cancelado antes de su fecha de terminación, en donde el propietario del producto es el único que puede cancelar un Sprint. De tal manera que un sprint puede ser cancelado si el objetivo del mismo es obsoleto, lo cual puede darse si se cambia la dirección o si las condiciones cambiar. Planificación del Sprint Todo el equipo Scrum es el encargado de definir el Sprint, para definir lo que se hará en el Sprint se tiene un máximo de ocho horas, en donde el Scrum Master se asegura de que el evento se lleve a cabo y los asistentes tengan entiendan el propósito.

14 De esta manera la planificación de un Sprint debe contestar a las siguientes preguntas: A. Qué se puede entregar en el incremento resultante del próximo Sprint? B. Cómo va a ser el trabajo necesario para entregar un incremento? Extreme Programming Consiste en una disciplina de desarrollo de software, que se basa en los valores de la simplicidad, comunicación, retroalimentación, coraje y respeto [14]. En donde busca promover el trabajo en equipo, aprendizaje de los desarrolladores, relación continúa entre el cliente y el equipo de desarrollo para facilitar la comunicación entre las personas interesadas en el proyecto de software, así mismo fomenta la simplicidad en las soluciones implementadas y coraje para enfrentar los cambios [15]. Buenas prácticas Según los creadores de esta metodología Kent Beck y Cynthia Andres es necesario seguir un conjunto de prácticas las cuales facilitan el desarrollo de un proyecto de software [16] que serán mencionadas a continuación [14]: Todo el equipo Todos los miembros del equipo de trabajo deben sentarse juntos, en donde se debe incluir un representante del negocio, ya que este será el encargado de proporcionar los requerimientos, establecer las prioridades del proyecto y dirigirlo. El equipo también debe incluir a los programadores encargados de implementar la solución, así mismo en esta reunión pueden asistir los testers, los cuales ayudaran al cliente a definir las pruebas de aceptación del proyecto. Los analistas pueden ayudar al cliente a definir los requerimientos. Existe un entrenador el cual es encargado de ayudar al equipo a mantener el rumbo y facilitar el proceso. Ninguno de los roles son propiedad exclusiva de una sola persona, puesto que todos los miembros de extreme programming contribuyen de alguna manera al desarrollo del proyecto.

15 Los mejores equipos son aquellos que no tienen especialistas, solamente contribuyentes generales con habilidades especiales. El juego de la planificación La planificación tiene dos aspectos fundamentales, el primero consiste en la predicción de lo que va a llevarse a cabo hasta un fecha prevista y la segunda determina que se va a hacer a continuación. Existen dos tipos de planificación en XP una de ellas es la planificación de lanzamiento, la cual consiste en que el cliente presenta las características deseadas de la solución a los programadores, en donde cada uno de ellos estima su dificultad, teniendo en cuenta estimaciones de costo y prioridad asignada. Otro tipo de planificación es la de iteración, que consiste en la construcción de software cada dos semanas, ofreciendo soluciones útiles en cada iteración, así mismo el cliente presenta las características deseadas en las próximas dos semanas; de esta manera los programadores toman los requerimientos dados por el cliente y los descomponen en tareas, estimando su costo. Pruebas de los clientes El cliente define una o más pruebas de aceptación para cada uno de los requerimientos. El equipo de trabajo construye las pruebas definidas por el cliente, para mostrar y verificar que cada uno de los requerimientos o soluciones terminadas son implementadas correctamente. Entregas pequeñas Al final de cada iteración es necesario entregarle al cliente software implementado y probado. En XP se debe producir versiones de la solución que sean operativas y que cuenten con algunas funcionalidades por cada iteración. Diseño simple Los equipos de XP construyen software para un diseño simple pero adecuado.

16 Se mantiene el diseño tan simple como sea posible, en donde se debe eliminar complejidad en el diseño como sea posible El diseño se debe tener en cuenta para cada una de las iteraciones del proyecto, de tal manera que es un proceso incremental. Programación en parejas Cada parte del software construido en XP, será realizado por dos programadores, los cuales trabajaran en la misma máquina, lo cual asegura que todo el código generado es revisado por al menos por otro programado. El trabajo en parejas proporciona un mejor código, pruebas y facilita la comunicación de conocimiento con todo el equipo. El cambio de pares se realiza para que todos los programadores posean los mismos conocimientos, ya que existen diferentes habilidades especiales en el equipo de trabajo, así mismo se fomenta el aprendizaje y mejoras en las capacidades del equipo. Desarrollo basado en pruebas Es necesario la ejecución de pruebas sobre el código, de tal manera que existen pruebas del programador a medida que se entrega código al repositorio. Cada una de las pruebas del programador debe funcionar al 100 por ciento del tiempo, lo que facilita la retroalimentación del proyecto. Las pruebas ofrecen apoyo a otros procesos como lo es el diseño del software. Mejoramiento del diseño En cada iteración el software debe estar bien diseñado, para esto se utiliza una técnica llamada refactorización, la cual consiste en la eliminación de la duplicación, aumento de la cohesión del código y reducción del acoplamiento. Así mismo en la refactorización es una actividad constante en la reestructuración del código, para mejorar la legibilidad, simplicidad y flexibilidad. El diseño evoluciona a medida que se implementa funcionalidades de la solución o del sistema.

17 Integración continúa En XP se mantiene el sistema totalmente integrado en todo momento. Cada pieza de código es integrada en el sistema una vez que esté lista, lo cual hace que el sistema se integre varias veces al día. La integración es fundamental para él envió de buen código de trabajo. Propiedad colectiva del código Cualquier par de programadores puede mejorar cualquier código en cualquier momento, lo cual genera que el código puede ser modificado por cualquier miembro del equipo de trabajo. Los beneficios de la propiedad del código sea colectiva es que se aumente la calidad del código, eliminando duplicaciones y baja cohesión. Estándares de programación El quipo debe seguir estándares de codificaciones comunes, de tal manera que el código parece escrito por una sola persona. El código parece familiar en apoyo a la propiedad colectiva. Metáfora Se debe desarrollar una visión común de cómo funciona el programa. Los equipos de XP nombres comunes en asignados al código y a la descripción del sistema, para así asegurase que todos entiendan el funcionamiento de este y lograr encontrar las funcionalidades que se están buscando. La arquitectura del sistema se asume evolutivamente, de tal manera que es necesario la metáfora para describir cómo debe funcionar el sistema. 40 horas por semana Cada persona de trabajar un máximo de 40 horas por semana, en donde no se trabajan horas extras en dos semanas seguidas. El trabajo extra desmotiva al equipo, así mismo los equipos que necesitan demasiadas horas extras normalmente entregan con retraso el proyecto.

18 Disciplined Agile Delivery La entrega ágil disciplinada es un marco que permite la toma de decisiones de procesos simplificados, alrededor de entregas graduales e iterativas, así mismo es considerado como un proceso de decisión hibrido de enfoque ágil con aprendizaje orientado a considerar a las personas primero y asegurando las entrega de soluciones a TI. De esta manera esta metodología combina diferentes funcionalidades de los métodos agiles, tomando las mejores prácticas de Scrum, Xp, OpenUp, entre otros que serán mostradas a continuación: A. ROLES El equipo de trabajo de esta metodología se encuentra dividido en dos grupos, los cuales serán enunciados a continuación: [17] Roles principales Son aquellos miembros del equipo de trabajo que son definidos sin importar la escala del proyecto, de esta manera existen 5 roles principales: Interesados: es alguien que se ve afectado materialmente por el resultado de la solución Miembro del equipo: son los encargados de la realización de pruebas, análisis, arquitectura, diseño, programación y otras actividades que afectan la ejecución del proyecto. Líder del equipo: Es un entrenador ágil, lo cual permite mantener el equipo enfocado en los elementos de trabajo, para así lograr el cumplimiento de las metas de cada iteración. Dueño del producto: consiste en el miembro del equipo, que participa con una voz del cliente, es decir que es el encargado de representar las necesidades de los interesados en el proyecto. Propietario de la arquitectura: es el encargado de realizar las decisiones de la arquitectura para el equipo. Roles secundarios

19 Los roles secundarios son aquellos que son definidos en forma temporal, los cuales son utilizados para abordad actividades de proyectos de gran escala: Especialista: en la mayoría d equipos agiles no existe especialistas, sin embargo en proyectos a gran escala es necesario de conocimientos específicos. Experto de dominio: es parte del equipo de trabajo del propietario del producto, el cual ayudara a definir los requerimientos del sistema. Expertos técnicos: Son parte del equipo de manera temporal, los cuales ayudan a superar problemas con altas dificultades, así mismo transfieren parte de sus habilidades a los desarrolladores. Tester independiente: En algunas ocasiones se utilizan equipos de pruebas independientes, para ayudar a validar el trabajo realizado a lo largo del ciclo de vida. Integrador: es en el cargado de adaptar y construir todo el sistema desde los diversos subsistemas. B. CICLO DE VIDA El ciclo de vida de entrega, consiste en una extensión del ciclo de vida de Scrum, en donde se toma los aspectos más relevantes que son mostrados a continuación: [17] Basados en iteraciones: la solución del proyecto es construida de forma incremental, de tal manera que se entregan funcionalidades listasen cada iteración. No se utiliza terminología Scrum: no se utiliza términos como sprint para definir una interacción, de tal manera que no se hace relevancia a la terminología. Lista de elementos de trabajo: el alcance de la entrega agil disciplinada (DAD) es mayor que el de otras metodologías, de tal manera que los elementos de trabajo incluye son priorizados y almacenados en una lista.

20 ILUSTRACIÓN 1: CICLO DE VIDA CON EXTENSIÓN DE SCRUM Profesionales en metodologías agiles Los profesionales en metodologías agiles disciplinados deben contar con las siguientes características: [17] Los miembros del equipo deben tener una relación estrecha con los profesionales de la empresa, como por ejemplo los gestores de la cartera. Se debe seguir las directrices de la empresa. Mejorar el ecosistema organizacional a través de la refactorización de los activos de la empresa. Compartir aprendizajes con otros equipos AUP Ágil Esta metodología se desarrolla de manera iterativa, en donde se definen las actividades que van a desarrollar los miembros del equipo, las cuales se van a validar y desplegar, estos flujos se efectúan cada dos semanas y contienen las siguientes fases [18] [19]:

21 Modelo: esta fase tiene como objetivo entender la organización del negocio, de tal manera que se identifique un posible solución de manera viable y que concuerde con el dominio del negocio. Implementación: su objetivo es transformar el modelo en código ejecutable, de tal manera que se puedan ejecutar pruebas. Test: consiste es llevar a cabo una evaluación objetiva para garantizar la calidad, en donde se puedan e encontrar defectos, validar y verificar el cumplimiento de los requisitos. Despliegue: consiste en la ejecución el plan de despliegue para que el sistema esté disponible para los usuarios finales. Gestión de la Configuración: se debe administrar el acceso a los artefactos desarrollados, de tal manera que se haga un seguimiento de versiones, control y la gestión de los cambios. Gestión de proyectos: se debe dirigir las actividades que lleva a cabo el proyecto, teniendo en cuenta la gestión de los riesgos, asignación de tareas, seguimiento del progreso, y la coordinación con las personas y los sistemas fuera del alcance del proyecto para asegurarse de que está entregado a tiempo y dentro del presupuesto. Medio Ambiente: el objetivo de esta fase es apoyar el desarrollo del proyecto con el fin de garantizar que ejecuten los procesos de manera adecuada, teniendo en cuenta las normas, directrices y herramientas normas, directrices y herramientas. A. Ciclo de vida El ciclo de vida de AUP contiene las siguientes etapas para el desarrollo de software [19]: Inicio: consiste en identificar un posible alcance del proyecto, así como también una arquitectura potencial, financiación y aceptación por parte de los interesados. Elaboración: consiste en elaborar el diseño del proyecto. Construcción: el objetivo es construir un software de manera incremental, que cumpla los requerimientos de las partes interesadas. Transición: en esta etapa se debe validar y desplegar el sistema en el entorno solicitado por el cliente.

22 ILUSTRACIÓN 2: CICLO DE VIDA Y ETAPAS AGIL UNIFIED PROCES. TOMADO DE: THE AGILE UNIFIED PROCESS (AUP) LIFECYCLE, Integración Continua Es una práctica de desarrollo de software en la cual los miembros de un equipo integran su trabajo frecuentemente, como mínimo de forma diaria. En donde cada integración se verifica mediante una herramienta de construcción automática para detectar errores de integración tan pronto como sea posible. [20] Según la definición realizada por Martin Fowler la integración continua es una herramienta la cual facilita la validación e integración de código, en donde cada integración se verifica compilando el código fuente y obteniendo un ejecutable (llamado build) [21] el cual es el encargado de situar el código todo junto en un ambiente donde funciona de una manera cohesiva [22]

23 ILUSTRACIÓN 3: FLUJO INTEGRACIÓN CONTINUA, TOMADO DE: INTEGRACIÓN CONTINUA EN PROYECTOS ÁGILES DE SOFTWARE, Prácticas para la integración continua Existen prácticas para la integración continua, que ayudan al desarrollo de pruebas e integración del código, enunciadas a continuación: [23] [24] [25] Mantener único de repositorio de código fuente: el repositorio es una herramienta totalmente necesaria, puesto que permite al equipo trabajar de una manera sincronizada, de tal manera que cada desarrollador realiza una tarea, una vez esté finalizada y probada esta es unida al código central. Automatizar la construcción del proyecto: se debe poder construir el proyecto en cualquier máquina, para implementar y compilar el código. La construcción del proyecto ejecuta sus propios test: comprobar si el código funciona correctamente.

24 Obtención por parte del equipo de trabajo de la última versión de forma fácil: es necesario realizar la integración continua de una manera correcta, en donde se integre el código a través de herramientas como Jenkins o Cruise Control. Todo el mundo se compromete a la línea de base todos los días: se debe notificar al menos una vez al día los cambios realizados en el código original Cada compromiso debe ser construido: El sistema debe adecuarse a la versión actual sobre la que se está, en donde se verifica que los componentes o nuevas funcionalidades se integren correctamente trabajando. Mantenga la rápida construcción: La construcción debe realizarse de una manera rápida, puesto que si existe errores en el momento de comprobar el código, este se pueda arreglar de una manera fácil y eficaz. Prueba en un clon del entorno de producción: En algunas ocasiones al tener un entorno de pruebas se puede producir errores o fallas, por tal motivo es aconsejable construir una réplica del entorno de pre- producción Características generales Las características más relevantes de la integración continua serán enunciadas a continuación [26]: Permite que el equipo de trabajo siempre esté informado del estado del avance del mismo. La integración continua surge de las metodologías agiles de programación, específicamente programación extrema. Permite reducir el tiempo de integración. Permite detener los errores lo más pronto posible. Cada vez que se realice un cambio en el código, es necesaria realizar pruebas sobre el mismo. El código debe estar disponible para haber pruebas o entregar demos al cliente.

25 2.3. Control de versiones Consiste en el control de los cambios realizados en un archivo o condigo fuente, de tal manera de que si existe alguna variación en el archivo este debe registrarse en un repositorio, con el fin de recuperar versiones anteriores. [3] Conceptos básicos Tronco (trunk): es el lugar donde se pone el código original, de tal manera que las personas participantes en el proyecto podrán obtener las actualizaciones requeridas, así mismo en el momento que se desarrolle una nueva funcionalidad, se debe copiar el código al tronco. [27] Ramas (branch): cuando se crea una nueva funcionalidad o característica del código es llamado rama, de tal manera que se copia todo el código del tronco para formar la rama y se agrega la nueva funcionalidad (merge). [27] [28] Etiquetas (tags): es la manera de cómo se marca el pondrán código en diferentes intervalos del desarrollo del proyecto, de tal manera que se copiará el tronco y se le asignará una etiqueta, sin embargo no se podrán utilizar las etiquetas en el momento que se desee editar el código. [27] [28]

26 ILUSTRACIÓN 4: PROCESO DE RAMIFICADO. TOMADO DE: SISTEMA DE CONTROL DE VERSIONES, Control de versiones locales Es un sistema de control de versiones que consiste en tener un control de cambios de archivos o código fuente a través de la numeración o asignación de fecha y hora en la modificación del documento sobre el cual se está trabajando, de tal manera que se pueden almacenar en bases de datos locales o directorios. [3] Control de versiones centralizadas Consiste en un esquema cliente- servidor, en donde el único servidor tiene todos los archivos versionados y los clientes descargan la información que se encuentra en el repositorio [3], manteniendo una copia local y actualizándose d manera síncrona con el repositorio central, de tal manera que se puedan realizar cambios y corrección de conflictos [29], no obstante pueden surgir

27 algunos problemas con este sistema de control de versiones, los cuales se enunciaran a continuación: Fallos en el servidor: si el servidor presenta algún fallo ninguno de los clientes pueden descargar una copia local sobre este ni realizar cambios. Repositorio corrupto: si el repositorio presenta fallas de seguridad y no existe un control de cambios riguroso, puede existir una pérdida total de la información de las últimas variaciones realizadas por los clientes Control de versiones distribuidas Consiste en un sistema de control de versiones, en donde los clientes descargan una copia local del repositorio, de tal manera que si el servidor falla por algún motivo alguno de los repositorios de los clientes puede copiarse en el servidor para restaurarlo [3] ILUSTRACIÓN 5: CONTROL DE VERSIONES DISTRIBUIDA. TOMADO DE: SCM.COM/BOOK/ES/V1/EMPEZANDO-ACERCA-DEL-CONTROL-DE-VERSIONES, SISTEMAS DE CONTROL DE VERSIONES DISTRIBUIDOS,

28 2.4. Ambientes colaborativos Gestión del ciclo de vida de aplicaciones (ALM) consiste en un proceso continuo para gestionar la vida de una aplicación de software [30] altamente colaborativa, que se realiza a través de técnicas de gobernabilidad, técnicas de ingeniería de software y herramientas para el desarrollo dl proyecto. [31] De esta manera la gestión del ciclo de vida de las aplicaciones permite a los desarrolladores, arquitectos y personas interesadas definir, gestionar y comunicar cambios en los requisitos del proyecto durante su desarrollo [32] Por otro lado ALM es dividida en tres maneras distintas que serán anunciadas a continuación: [33] Gobernanza: consiste en la toma de decisiones para la gestión de la aplicación, en donde su propósito es el aseguramiento de que la aplicación siempre provea lo que el negocio necesita. Desarrollo: es el proceso para la creación de las aplicaciones, en donde inicia desde la idea hasta el despliegue. Operaciones: consiste en los trabajos necesarios para ejecutar y gestionar las aplicaciones, normalmente estos procesos comienzan antes de la implementación y se desarrollan de forma continua Facilidades ofrecidas por los ambientes colaborativos Un ambiente colaborativo permite el uso de diferentes funcionalidades para la gestión de proyectos de software, de tal manera que permita al equipo de trabajo tener una constante comunicación, notificaciones de cambios en los requerimientos, versiones, ente otras. De esta manera se enunciaran algunas de las facilidades que permiten el uso de ambientes colaborativos: [31] Documentos de un proyecto: los ambientes colaborativos permiten gestionar, planificar y desarrollar documentos de la aplicación, tales como descripción de requerimientos, casos de uso, guías y estándares

29 Wikis: permite la edición o modificaciones de documentos, guías, entre otros de un proyecto. Noticias y avisos: un ambiente colaborativo debe informar al gerente el estado del proyecto, de tal manera que se realice a través de avisos o notificaciones. Lista de versiones: el ambiente colaborativo debe contener las listas de versiones liberada por el software. Forums: permiten a los miembros del equipo una comunicación directa, en donde estas facilidades son usadas para la solución de problemas por parte de los desarrolladores, gestión de reportes para el cliente, solicitud del cliente para realizar cambios, entre otros. Acople del ambiente colaborativo con un repositorio de versiones: permite configurar los permisos sobre el repositorio de versiones de cada uno de los participantes, obtener historial de versiones y adquirir historial de trabajo de los participantes por cada actividad. Acople del ambiente colaborativo con herramientas para la integración continua: permite definir pruebas y obtener historial de las mismas a través de herramientas para la integración continúa de código. Seguridad: el ambiente colaborativo debe permitir definir los roles para cada proyecto, gestionar los derechos asociados a cada rol e inscribir uno o varios miembros en los roles del proyecto Manejo de actividades Un proyecto de software es desarrollado a través de actividades, las cuales son gestionadas por los interesados en la aplicación, de esta manera existen diferentes elementos además de las actividades, que hacen parte del ambiente, los cuales serán enunciados a continuación: [31] Tracker: son un conjunto de actividades similares, así mismo es considerada como una herramienta configurable para el seguimiento de elementos, que pueden representar casos de usos, requerimientos, historiales, entre otros. Item: son elementos asociados a las actividades, en donde tienen un estado de desarrollo, miembros que participan en la actividad, estimación en tiempo de su desarrollo y commits sobre el repositorio de versiones asociado a la actividad.

30 Workflow: permite la automatización del flujo de trabajo de las actividades de cada tracker, en donde se definen el estado de desarrollo de los ítems, roles de los participantes de cada ítem y configuración de notificaciones a los participantes 3. Buenas prácticas y herramientas seleccionadas. Para la selección de las herramientas de software libre y las buenas prácticas que se utilizaron en el desarrollo de la guía metodológica se tuvo en cuenta el proceso para la toma de decisiones Decision Analisys and Resolution (DAR), ya que este tiene como propósito analizar las posibles

31 alternativas de decisión, a través de un proceso de evaluación formal, que evalúa las alternativas respecto a un conjunto de criterios establecidos [34] Mejores prácticas de las metodologías agiles De acuerdo a los resultados generados por el DAR de las metodologías ágiles realizados por personas con conocimientos en esta área, se escogieron las mejores prácticas que se adecuan al desarrollo de la guía metodológica para la gestión de proyecto, en donde se obtuvieron los siguientes resultados: Mejor metodología ágil Según los resultados obtenidos del Dar de la metodología ágil, se puede observar que la metodología Extreme Programming obtuvo el mayor puntaje, contando con una calificación de 4.60, de tal manera que en los siguientes criterios se les dio la nota máxima por los tres evaluadores: La metodología indica que se debe hacer análisis y diseño de las funcionalidades en cada iteración Facilidad para mantener el diseño tan simple como sea posible. Facilidad de elaboración de pruebas al finalizar cada desarrollo. Facilidad para ajustar errores y realizar correcciones Mejor metodología para cada grupo de criterios Los grupos de evaluación para la elección de las mejores prácticas de las metodologías ágiles están basados en las principales fases de desarrollo de la metodología RUP [51] y son: Inicio Elaboración

32 Desarrollo Transición Adicional a estas fases, agregamos un grupo de características generales, en donde se incluyen los criterios principales de un proyecto de desarrollo de software, de esta manera se enunciaran por cada grupo de criterios la mejor metodología: Características generales: resalta las características principales de las metodologías ágiles enunciadas a continuación : o o o o o A.1 - Facilidad para gestionar el alcance del proyecto en cada una de las iteraciones: es necesario determinar lo que se hará en cada una de las iteraciones del proyecto, en la cual se especificara que requerimientos se debe desarrollar. A.2 - Mantener comunicación directa con los interesados del proyecto: es necesario tener una buena comunicación con los interesados del proyecto, ya que estos son los que definen lo que se espera del producto así como también los cambios necesarios durante su desarrollo. A.3 Permite que el cliente defina las pruebas de aceptación cada uno de los requerimientos: el cliente es un miembro importante durante el desarrollo del proyecto, ya que este valida si los requerimientos de implementaron adecuadamente, a través de pruebas de aceptación. A.4 - Mantener el producto totalmente integrado al finalizar cada iteración: el código de cada iteración debe estar completamente añadido a la totalidad del proyecto. A.5 Facilitar la elaboración pruebas por cada iteración del proyecto: el equipo de desarrollo del proyecto, debe realizar pruebas de aceptación para cada una de las iteraciones. De esta manera las metodologías que obtuvieron mayor calificación por este grupo de criterios fue Discipline agile delivery y The Agile Unified Process.

33 Inicio: En esta fase el gerente del proyecto se encarga de definir el alcance, la dimensión del proyecto, se realiza la identificación de las funcionalidades, y el analista realiza la especificación de los requerimientos apoyándose en las historias de usuario [52] o o o o B.1 - Facilidad para definir el alcance y objetivo del proyecto: se debe tener claro que es lo que se espera con el desarrollo del proyecto, así como también hasta donde se quiere llegar. B.2 - La metodología indica que se deben definir los roles del grupo en la fase de inicio del proyecto: es necesario definir qué responsabilidad tendrá cada uno de los miembros del equipo de trabajo. B.3 Identificar los posibles riesgos del proyecto: se debe identificar los posibles riesgos durante la ejecución del proyecto. B.4 La metodología indica que se debe planear con el cliente las iteraciones del proyecto: es necesario tener una comunicación directa con el cliente del proyecto, ya que una de sus funcionalidades es planificar lo que se hará en cada una de las iteraciones. De esta manera la metodología que obtuvo una mayor calificación fue Scrum. Elaboración: En esta fase, se realiza la definición de las tareas y asignación a los desarrolladores. o C.1 - Facilidad para la recolección y priorización de requerimientos: se debe definir cada uno de los requerimientos del sistema, los cuales serán utilizados para organizar la creación del producto en cada una de las iteraciones. o C.2 La metodología indica que se debe hacer análisis y diseño de las funcionalidades en cada iteración: para cada una de las iteraciones, se debe realizar un diseño del sistema. o C.3 - Facilidad para mantener el diseño tan simple como sea posible: el diseño se debe mantener muy simple, ya que esta es una parte importante de las metodologías agiles pero no fundamental.

34 o C.4 La metodología promueve elaborar estándares de desarrollo de software: se debe utilizar los estándares para la creación de software, ya que permite un mayor entendimiento del código para los miembros del equipo de trabajo. o C.5 La metodología promueve elaborar historias de usuario: se debe utilizar historias de usuario. La metodología que obtuvo un mejor resultado fue Discipline agile delivery. Desarrollo: En esta fase se lleva a cabo el desarrollo de las tareas en el tiempo asignado para cada una así se realiza la priorización de los requerimientos. o o o o o D.1 - Facilidad para adaptarse al cambio de requerimientos: los requerimientos pueden cambiar de acuerdo a las necesidades del cliente o del proyecto, por tanto cada iteración se debe adaptar a estos cambios. D.2 - Comunicación eficiente entre el equipo de desarrollo: el equipo de desarrollo debe estar en contante comunicación, puesto que eso depende un producto más eficiente y adecuado para las necesidades del cliente. D.3 La metodología promueve definir grupos de desarrollo pequeños y centralizados: al trabajar por pares o equipos de desarrollo pequeños, permite apoyo a la creación de código de calidad de una manera más rápida y optima D.4 - Facilidad de elaboración de pruebas al finalizar cada desarrollo: es necesario elaborar pruebas de aceptación para cada iteración. D.5 - La metodología promueve elaborar el desarrollo basado en las historias de usuario: se debe basar el desarrollo del proyecto en las historias de usuario. La metodología que obtuvo un mejor resultado fue Scrum Transición: En esta fase dese ejecutan las pruebas y se realiza la revisión del código.. o E.1 - Realizar entregas de software tempranas y continuas a los usuarios: se debe realizar entregas de software al cliente en cada una de las iteraciones, para así realizar las pruebas de aceptación por parte del cliente,

35 o o E.2 - Facilidad para ajustar errores y realizar correcciones: en cada una de las iteraciones se debe realizar las correcciones correspondientes a cada error. E.3 Preparación los datos para la carga inicial del sistema: se deben preparar los datos necesarios para cargar el sistema. La metodología que obtuvo un mejor resultado fue Discipline agile delivery Mejores criterios de las metodologías agiles para el desarrollo de la guía De acuerdo a los resultados generados por el Dar de las metodologías ágiles se escogieron las mejores prácticas que se adecuan al desarrollo de la guía metodológica para la gestión de proyectos, los cuales se enunciarán a continuación: Características generales o Facilidad para gestionar el alcance del proyecto en cada una de las iteraciones. o Mantener comunicación directa con los interesados del proyecto. o Definición de pruebas de aceptación entregadas por el cliente para cada uno de los requerimientos. o Mantener el producto totalmente integrado al finalizar cada iteración. o Facilitar la elaboración pruebas por cada iteración del proyecto. Inicio o La metodología indica que se deben definir los roles del grupo en la fase de inicio del proyecto. o La metodología indica que se debe planear con el cliente las iteraciones del proyecto Elaboración o Facilidad para la recolección y priorización de requerimientos. o La metodología promueve elaborar historias de usuario. Desarrollo

36 o Facilidad para adaptarse al cambio de requerimientos. o Facilidad de elaboración de pruebas al finalizar cada desarrollo. o La metodología promueve elaborar el desarrollo basado en las historias de usuario. Transición o Facilidad para ajustar errores y realizar correcciones Herramientas seleccionadas y Plugins Jenkins Es una aplicación de integración continua que supervisa las ejecuciones de trabajos, la cual es utilizada para integrar cambios en el proyecto de software, para aumentar la productividad del equipo de trabajo. [35] Características generales A continuación se enunciaran las características generales de la herramienta Jenkins, abarcando desde su precio hasta sus funcionalidades que soporta: [35] [36] Gratuito y de código abierto. Multiplataforma. Soporta herramientas como CVS, Subversión, Git, entre otras. Permite variar la manera de notificar errores. Integración con bases de datos. Personalizar interfaz Permite la creación de extensiones a través de Java Fácil de instalar y configurar: puesto que permite configurar completamente desde su interfaz gráfica de usuario Huellas digitales de archivos: se realiza seguimiento a los archivos del proyecto Computación externa bajo api XML y aplicaciones móviles Android y IOS Permite compilaciones y pruebas distribuidas. Comunidad de soporte Integración de correo electrónico, generando reportes o notificaciones a través del correo electrónico.

37 Mylyn Es un framework utilizado para la gestión de tareas y ciclos de vida de aplicaciones para Eclipse, la misión de Mylyn es proporcionar a un proyecto [37] [38]: La revolucionaria interfaz orientada a tareas. Reordena el IDE entorno a tareas para que sólo se vea el código que es relevante Una herramienta de gestión de tareas para desarrolladores Un amplio ecosistema de integraciones de herramientas para Agile y ALM Decenas de extensiones integran Mylyn con ALM y herramientas de colaboración para desarrolladores. Características generales A continuación se enunciaran las características más importantes de la herramienta Mylyn [37] Aplicación centrada en tareas. Código abierto Subsistema de eclipse para la gestión de tareas. Provee interface de programación para aplicaciones Git Git es una herramienta para el control de versiones diseñado por Linus Torvalds, el cual modela sus datos como un mini sistema de archivos, puesto que cada vez que se confirma un cambio, se guarda la referencia instantánea, así mismo maneja la eficiencia de manera que si los archivos no se han modificado, no se almacena el archivo de nuevo, solamente un enlace al anterior archivo que es idéntico. [39]

38 ILUSTRACIÓN 6: GIT ALMACENA LA INFORMACIÓN COMO INSTANTÁNEAS. TOMADO DE: SCM.COM/BOOK/ES/V1/EMPEZANDO-FUNDAMENTOS-DE-GIT, FUNDAMENTOS DE GIT, Así mismo Git cuenta con varios repositorios, uno central donde se encuentra el código original y una copia local para cada desarrollador, sobre la cual se podre crear ramas y etiquetas; al finalizar cambios o creaciones de nuevas funcionalidades, se debe unir los cambios al repositorio central y actualizar los repositorios locales de los desarrolladores. [27] 3.3. Descripción del entorno integrado Eclipse Indigo Eclipse Indigo es una versión de eclipse que incluye 62 nuevos proyectos [40], de los cuales se pueden destacar los siguientes [41] Mejor integración con Maven. EGit para integrarnos con él, sistema de control de versiones GIt. Jubula, que proporciona test funcionales automático del GUI de nuestras aplicaciones, ya sean Java o HTML. WindowBuilder, es una herramienta de Google para construir GUI (Interfaces Gráficas de Usuario). La cual es open source y parte de Indigo.

39 4. Guía Metodología 4.1. Integración Visión global del sistema

40 Para realizar el proceso de integración de las herramientas en un entorno de desarrollo, es necesario realizar el análisis de la arquitectura a nivel de infraestructura y aplicaciones con el fin de reconocer las herramientas necesarias (software) y los recursos físicos como servidores y repositorios requeridos; para esto vimos necesario definir la siguiente ilustración que representa el visión global del sistema: ILUSTRACIÓN 7 VISIÓN GLOBAL DE LA ARQUITECTURA En la visión global del sistema se puede identificar cada uno de los artefactos que son requeridos para el desarrollo, de esta manera en el IDE eclipse se encuentra los plugins necesarios para la integración continua, control de versiones distribuidos y ambientes colaborativos, así mismo el diagrama muestra los servidores que interactúan con cada una de las herramientas, por tal motivo se ilustra los servidores de JBoss, Gerrit, Git, Bugzilla y Hudson, finalmente en el momento de desarrollo de una aplicación se encuentran los participantes del entrono integrado, los cuales se encargan de asignar trackers y tareas y ejecutarlas.

41 Arquitectura de Despliegue del sistema En la arquitectura del entorno de desarrollo existen diferentes servidores remotos que permiten la comunicación entre capas y funcionalidades, en donde el principal nodo es el PC del cliente, en este caso es Eclipse en donde se desarrolla la aplicación y se integran los servidores, la base de datos y los plugins necesarios, los cuales actúan como clientes de servidores remotos. Para este caso, en el IDE eclipse se integran los siguientes artefactos: Base de datos Postgresql: contiene los datos que maneja la aplicación en sus funcionalidades, sin embargo esta es una base de datos utilizada para la ejecución del demo, no obstante se puede utilizar otra de acuerdo a las necesidades del proyecto en que se esté trabajando. Mylyn: para integrar el ambiente colaborativo Mylyn se utiliza el plugin Mylyn Builds Connector: Hudson/Jenkins, el cual permite integrar las funcionalidades de Mylyn y Jenkins. Para definir las tareas y asignarlas se utiliza el servidor de Bugzilla que permite crear los Bugs (que son actividades) y asociarlos a los desarrolladores en un tiempo estimado. Además, se conecta con el servidor Gerrit, el cual permite realizar las revisiones de código. Git: para integrar las funcionalidades del repositorio distribuido Git, se integró a Eclipse el plugin Eclipse Github Extensions, el cual permite realizar la conexión con el servidor, almacenar y administrar las versiones de la aplicación. Revisiones de código: Al realizar las revisiones de código por medio de Gerrit, el sistema permite la integración con el servidor Hudson, el cual realiza las pruebas definidas para el proyecto de software e informa al desarrollador de los fallos encontrados, además de realizar el empaquetamiento y despliegue en el servidor de aplicaciones JBoss, no obstante se podría utilizar otro servidor de aplicaciones, de acuerdo a las necesidades del proyecto Instalación del Entorno Eclipse servidor y base de datos

42 Para comenzar el proceso de integración de las herramientas de software libre, es importante realizar la instalación y configuración de la base de datos y el servidor de aplicaciones en el que se va a desplegar la aplicación desarrollada por el proyecto de software. En este caso, se decidió usar la base de datos Postgresql y el servidor JBoss, los cuales son herramientas de adquisición gratuita y permiten integrarse en eclipse. Como se muestra en el siguiente diagrama de despliegue, la aplicación Demo maneja los datos almacenados en la base de datos Postgresql; en el desarrollo del proyecto se implementó la base de datos local, pero se puede usar un servidor o cualquier base de datos relacional. ILUSTRACIÓN 8 DIAGRAMA DE DESPLIEGUE DATOS En esta sección se realiza el resumen del manual de instalación y configuración del servidor de aplicaciones Jboss7 y la base de datos Postgresql en el IDE Eclipse. El documento completo se encuentra en el anexo: Tutorial-JEE7-JBoss7-Eclipse, el cual fue desarrollado por la ingeniera Maria Consuelo Franky. Este manual contiene el paso a paso de la configuración de las herramientas que el grupo de trabajo siguió para la integración de los plugins. Dentro del documento se detalla la siguiente información: Pasos para construir un demo Java EE 7 maven en Eclipse y publicarlo en Jboss 7

43 Configurar el IDE trabajando con Eclipse Indigo Generar un proyecto Maven en Eclipse sin base de datos Publicar el proyecto Maven en JBoss 7 Configuración adicional de Jboss final Ampliar la aplicación Java EE Instalación e integración de las herramientas Las herramientas que se especificaron en la sección de este documento, se integran en el framework de desarrollo Eclipse por medio de plugins de software libre que se pueden descargar e instalar para el desarrollo de proyectos de software. El proceso de instalación se realiza de la siguiente forma: Mylyn Instalar plugin Confugirar servidor Bugzilla Configurar servidor Gerrit Git Instalar plugin Configurar repositorio Git Hudson Instalar plugin Configurar servidor Hudson ILUSTRACIÓN 9 PASOS PARA INSTALACIÓN E INTEGRACIÓN A. Ambiente colaborativo Mylyn Para realizar la instalación del ambiente colaborativo Mylyn, se deben seguir los siguientes pasos especificados en cada ilustración.

44 Instalación del plugin Mylyn Builds Connector: Hudson/Jenkins En la herramienta Eclipse ir a la ruta: Menu Help Eclipse MarketPlace ILUSTRACIÓN 10: ECLIPSE MARKETPLAC Buscar el plugin Hudson/Jenkins Mylyn Builds Connector a través de la herramienta find e instalar. Buscar entre la lista de posibilidades del plugin Mylyn e instalar

45 ILUSTRACIÓN 11: DESPLIEGUE PLUGINS Indetificar las características del plugin ILUSTRACIÓN 12: CARACTERÍSTICAS PLUGIN Seleccionar todas las características del plugin Mylyn e instalar

46 ILUSTRACIÓN 13: INSTALACIÓN MYLYN Visualizador de tareas Abrir la ventana de tareas, seleccionado la ruta: Window > Show view > Task List y ver las lista de tareas que vienen por defecto en Mylyn.

47 ILUSTRACIÓN 14: VENTANA DE TAREAS Observar en la parte derecha de IDE la herramienta para ver y crear tareas. ILUSTRACIÓN 15:TASK LIST

48 Crear nuevas tareas Visualizar las tareas ya creadas: B. Repositorio de versiones distribuido Git Para realizar la configuración del plugin de Eclipse se deben realizar los siguientes pasos: Instalación del plugin Eclipse Github Extensions, en la herramienta Eclipse ir a la ruta: Menu > Help > Eclipse MarketPlace ILUSTRACIÓN 16: INGRESO ECLIPSE MARKETPLACE Buscar el plugin Eclipse Github Extensions a través de la herramienta find e instalar. Luego, se selecciona el proyecto que se está desarrollando, Clic derecho > Team > Share Project, seleccionar el tipo de repositorio Git, luego seleccionar Next y crear el repositorio.

49 ILUSTRACIÓN 17: SELECCIONAR REPOSITORIO GIT Para agregar el proyecto desarrollado en la rama del repositorio es necesario dar clic derecho > Team > add, si se agregan cambios al proyecto es necesario realizar clic derecho > Team > commit, como se muestra en la siguiente imagen, así mismo se debe asociar el número de tarea o nombre de la tarea a la que se le hará commit, para esto es necesario agregar en commit message el nombre de la tarea.

50 ILUSTRACIÓN 18: REALIZAR COMMIT SOBRE LA TAREA AGREGAR FUNCIONALIDAD ELIMINAR BOOK C. Integración continua con Hudson Para realizar la instalación de la herramienta Hudson/Jenkins, se puede utilizar el plugin Mylyn Builds Connector: Hudson/Jenkins instalado previamente. En este caso es necesario realizar la configuración del servidor Hudson en Eclipse. En la pestaña de Build se crea un nuevo servidor. ILUSTRACIÓN 19: ADD BUILD SERVER

51 Seleccionar el servidor Hudson que viene por defecto: ILUSTRACIÓN 20: SERVIDOR HUDSON En la configuración del servidor Hudson, se debe agregar la url donde está localizado el servidor de Hudson las credenciales y buscar el nombre de la aplicación que se está desarrollando en la lista.

52 ILUSTRACIÓN 21: PROPIEDADES DEL SERVIDOR Por último, se puede evidenciar el monitoreo de las pruebas realizadas a la aplicación demo1, para ver la configuración del demo ver Anexo 1: manual de instalación realizado por Maria Consuelo Franky ILUSTRACIÓN 22: MONITOREO DE PRUEBAS

53 Pruebas del ambiente integrado Después de realizar la integración de las herramientas, se realizan las respectivas pruebas que validen los siguientes aspectos. Las tareas creadas y asignadas a un desarrollador son notificadas por medio de correo electrónico: En la siguiente imagen se puede evidenciar que la tarea fue asignada al desarrollador Diana Blanco y se realiza la notificación por medio de correo electrónico: ILUSTRACIÓN 23: NOTIFICAR PRUEBAS Cuando se realiza una modificación al código y se realiza commit, se asocia el número de la tarea para evidenciar el cambio y avance en la solución de dicha tarea.

54 ILUSTRACIÓN 24: COMMIT En la clase BookController.java fue agregada la funcionalidad de eliminar libro, cuando se realiza commit se asocia el nombre de la tarea para que se pueda registrar el cambio en el repositorio Bugzilla. En el repositorio deben quedar agregados los cambios realizados en la aplicación.

55 ILUSTRACIÓN 25:HISTORIAL DE CAMBIOS Debe ser empaquetado y agregado al servidor de aplicaciones el demo. ILUSTRACIÓN 26: EMPAQUETADO

56 La aplicación se puede visualizar con los cambios realizados en el servidor de aplicaciones JBoss que se había configurado previamente Ejecución del proceso de gestión de proyecto de software basado en metodologías ágiles Luego de realizar la integración de las herramientas, es necesario realizar las pruebas unitarias que certifiquen el correcto funcionamiento y demuestren el alcance esperado. Para iniciar las pruebas, es necesario especificar los roles que intervienen en la ejecución del proyecto, basado en la definición dada por Bogue [50]: Administrador: Es el encargado de gestionar la herramienta Eclipse, crear el ambiente de desarrollo, crear los roles del proyecto, otorgar permisos y gestionar lo requerido por los usuarios. Líder del proyecto: Es el líder del proyecto que se encarga de gestionarlo, comunicarse con el cliente, definir el cronograma, realizar las asignaciones de trabajo a los otros miembros del proyecto, realizar seguimiento a las actividades y tareas asignadas. Arquitecto: Es el líder técnico encargado de definir la arquitectura que se va a realizar en el proyecto, toma decisiones técnicas importantes en el desarrollo, soporta a los desarrolladores en cualquier inquietud y se encarga de mantener la arquitectura del negocio estable y consistente. Analista: El analista conoce las necesidades del proyecto a nivel funcional, identifica los requerimientos, los casos de uso, realiza el modelo del sistema, ayuda a definir los objetivos y tareas de los desarrolladores y brinda al equipo de desarrollo soporte en la definición y entendimiento de los requerimientos. Desarrollador: Es el encargado de llevar a cabo el desarrollo de las funcionalidades del proyecto basándose en la especificación de los requerimientos, los casos de uso y la arquitectura, cumplir con las tareas asignadas y brindar soporte en las fallas encontradas en las pruebas. Probador: Se encarga de llevar a cabo las pruebas del correcto funcionamiento de los requerimientos desarrollados, realizar las pruebas de integración luego de validar el

57 correcto funcionamiento de cada caso de uso. Definir los jobs que va a ejecutar Jenkins en cada tarea y notificar al integrador los casos de uso que se pueden integrar en el tronco del repositorio. Las fases definidas en el desarrollo de un proyecto de software fueron basadas en la metodología RUP [51], en el entorno integrado se evidencian de la siguiente manera: Lider del proyecto Arquitecto Analista Lider del proyecto Desarrollador Inicio Elaboración Transición Desarrollo Probador Desarrollador Desarrollador ILUSTRACIÓN 27: FASES VS ROLES Inicio En la fase de inicio el líder del proyecto se encarga de definir el alcance, la dimensión del proyecto y el presupuesto del cliente; el arquitecto realiza la propuesta de la arquitectura, se realiza la identificación de las funcionalidades, y el analista realiza la especificación de los requerimientos [52]. De esta manera según las buenas prácticas de las metodologías agiles, en esta fase:

58 Se deben definir los roles del grupo en la fase de inicio del proyecto. Se debe planear con el cliente las iteraciones del proyecto. Se deben Configurar los trackers del proyecto. Configuración de tracker Son un conjunto de actividades similares, así mismo es considerada como una herramienta configurable para el seguimiento de elementos, que pueden representar casos de usos, requerimientos, historiales, entre otros. Configuración de trackers locales: para la creación de estos trackers se utiliza en el entorno integrado el plugin de Mylyn, en donde se crean categorías que representan cada tracker. ILUSTRACIÓN 28: CREAR NUEVA CATEGORÍA Seguidamente se debe asignar un nombre representativo al tracker, ya sea desarrollo, requerimientos, documentos, entre otros.

59 ILUSTRACIÓN 29: ASIGNAR NOMBRE CATEGORÍA Creación de trackers remotos: se debe crear un nuevo tracker, en donde este tracker es asociado con un repositorio, que podrá ser accedido por los miembros de trabajo. ILUSTRACIÓN 30: NUEVO QUERY

60 ILUSTRACIÓN 31: SELECCIONAR REPOSITORIO ILUSTRACIÓN 32: ASIGNAR NOMBRE AL TRACKER REMOTO

61 Elaboración En esta fase, se realiza la definición de las tareas y asignación a los desarrolladores. En el ambiente integrado, el gerente o líder se encarga de asignar las tareas a los desarrolladores por medio del plugin de Mylyn [43]. De esta manera según las buenas prácticas de las metodologías agiles, en esta fase se emplea: Facilidad para la recolección y priorización de requerimientos. De esta manera en este paso se deben crear cada una de las tareas y asociarlas con un tracker y a los desarrolladores encargados en ejecutar las tareas, para esto ver sección instalación e integración de las herramientas, ambientes colaborativos Crear tareas La lista de tareas se puede configurar de acuerdo a categorías definidas: ILUSTRACIÓN 33: CATEGORÍAS Se pueden visualizar las tareas de acuerdo a la fecha que se han asignado: ILUSTRACIÓN 34: VISUALIZAR TAREAS

62 Crear nueva tarea local Para crear una nueva tarea se deben seleccionar la siguiente opción: ILUSTRACIÓN 35: NEW TASK Seleccionar el tipo de tarea que se quiere crear, en este caso la tarea creada es local: ILUSTRACIÓN 36: TIPO DE TAREA

63 Si es una tarea local se debe configurar el nombre de la tarea, la fecha de entrega y descripción de la tarea. la ILUSTRACIÓN 37: CONFIGURACIÓN DE TAREAS Creación de una tarea remota Crear cuenta en el servidor: inicialmente se debe crear una cuenta en el repositorio de Bugzilla, en donde se almacenaran las tareas, para eso visitar el siguiente link

64 ILUSTRACIÓN 38: SERVIDOR BUGZILLA Crear Cuenta: se debe crear una cuenta en el servidor de Bugzilla ILUSTRACIÓN 39: CREAR CUENTA Si se desea crear una tarea que pueda compartirse con el equipo de desarrollo se debe configurar el repositorio Bugzilla de la siguiente forma:

65 ILUSTRACIÓN 40: AGREGFAR REPOSITORIO BUGZILLA ILUSTRACIÓN 41: INSTALAR BUGZILLA En el buscador colocar Bugzilla e instalar el repositorio:

66 ILUSTRACIÓN 42: INSTALAR REPOSITORIO Se debe asociar el repositorio de Bugzilla con la cuenta creada anteriormente.

67 ILUSTRACIÓN 43: ECLIPSE ORG Luego de realizar la instalación, se debe seleccionar el repositorio Eclipse.org cuando se crea una tarea:

68 ILUSTRACIÓN 44: CREACION TAREA Seleccionar siguiente y crear un nuevo Bug que representa una nueva tarea. ILUSTRACIÓN 45: CREAR NUEVO BUG Partes de una tarea remota A una tarea se le puede asociar un nombre y un número de tarea

69 ILUSTRACIÓN 46: NOMBRE DE UNA TAREA Se debe asociar un tipo de producto al que está relacionada la tarea ILUSTRACIÓN 47: PRODUCT TASK

70 Se asocia una prioridad y componente a la tarea ILUSTRACIÓN 48: PRIORIDAD Y COMPONENTE DE LA TAREA Si es necesario se pueden agregar elementos a la tarea, como imágenes o documentos ILUSTRACIÓN 49: ASOCIAR ELEMENTOS A LA TAREA Asignar una fecha y hora a la tarea: ILUSTRACIÓN 50: CRONOGRAMA DE LA TAREA

71 Se debe realizar una descripción de lo que consiste la tarea a realizar ILUSTRACIÓN 51: DESCRIPCION TAREA Asignar la tarea a una o varias personas del equipo de trabajo. ILUSTRACIÓN 52: ASIGNAR TAREA Ingresando un nombre a la tarea, los atributos que el líder técnico del proyecto defina, la fecha de entrega, la descripción de la tarea, adjuntar archivos o fotos, seleccionar la persona asignada a la tarea y el revisor como por ejemplo:

72 ILUSTRACIÓN 53: PROPIEDADES BUG Si se tiene configurado el equipo de desarrollo para las tareas en Eclipse, se pueden crear Queries que realizan la configuración para un número de tareas que tienen las mismas características, en este caso se puede configurar el producto, el componente, la versión, la prioridad, entre otros, para un mejor detalle ver sección 4.4, Ejecución del proceso de gestión de proyecto de software basado en metodologías ágiles.

73 ILUSTRACIÓN 54: PARÁMETROS QUERY Desarrollo Se lleva a cabo la ejecución de la tarea, el revisor se encarga de actualizar los cambios en el repositorio, en donde se realiza commit, en este se especifica la tarea que se está desarrollando y la clase java que va a ser almacenada en la rama del repositorio. De esta manera según las buenas prácticas de las metodologías agiles, en esta fase: Facilidad para adaptarse al cambio de requerimientos. Facilidad de elaboración de pruebas al finalizar cada desarrollo.

74 Proceso de desarrollo El proceso de desarrollo tiene como participe dos roles, el del desarrollador y el revisor, en donde todo comienza cuando al desarrollador se le notifica una nueva tarea asignada, después de esto esté implementa el desarrollo y realiza Commit, de tal manera que se debe asociar al commit una la tarea asignada y cambiar el estado de la misma; después de esto el revisor realiza la revisión del código y valida si existen errores, a través del uso de Jenkins, si no existen errores se sincroniza con el repositorio, de lo contrario se notifica al desarrollador los lugares en donde existieron errores. ILUSTRACIÓN 55: PROCESO DE DESARROLLO Desarrollo de una tarea Inicialmente se notifica al desarrollador la nueva tarea a través de correo electrónico

75 ILUSTRACIÓN 56: NOTIFICAR TAREA Después el desarrollador se encarga de identificar en el proyecto, el lugar en donde debe crear la nueva funcionalidad. ILUSTRACIÓN 57: IDENTIFICAR CLASES PARA REALIZAR TAREA

76 Se debe desarrollar el método en las clases necesarias. ILUSTRACIÓN 58: DESARROLLAR MÉTODO

77 ILUSTRACIÓN 59: AGREGAR MÉTODO A LA CLASE EJB Después se debe identificar la creación del método en las clases del proyecto. ILUSTRACIÓN 60: IDENTIFICAR MÉTODO

78 Seguidamente el desarrollador debe asociar la tarea y realizar commit sobre los cambios realizados. ILUSTRACIÓN 61: REALIZAR COMMIT Para realizar la inspección del código por medio del repositorio, es posible ir a la pestaña de historial y ver las diferencias en el código. ILUSTRACIÓN 62: HISTORIAL CÓDIGO

79 En la pestaña de repositorio Git se encuentra el repositorio creado con la aplicación que fue agregada, se puede verificar que se ha añadido a la rama cuando aparece como Master ILUSTRACIÓN 63: REPOSITORIO GIT Se debe crear un repositorio Git local y otro Github remoto, puesto que cuando un miembro del equipo desea realizar o crear nuevas funcionalidades sobre el proyecto, es necesario que se trabaje sobre el repositorio local, en donde se añaden los cambios y se realiza el commit, de tal manera que después de realizar cambios sobre el código, esta nueva rama es añadida al repositorio remoto. De esta manera para crear el repositorio Git en un servidor remoto, una opción es utilizar GitHub [42], el cual permite conectarse a un repositorio distribuido Git e ir actualizando las versiones de la aplicación. En la página se crea una cuenta nueva y se selecciona la opción de crear un repositorio, que se mostrara a continuación: Página principal de GitHub

80 ILUSTRACIÓN 64: PÁGINA PRINCIPAL GITHUB Crear cuenta en Github ILUSTRACIÓN 65: CREAR CUENTA GITHUB

81 Crear repositorio GitHub ILUSTRACIÓN 66: CREAR NUEVO REPOSITORIO Asignar nombre al repositorio y crearlo. ILUSTRACIÓN 67: CREACIÓN REPOSITORIO GITHUB

82 Luego de haber realizado la instalación de GitHub y haber creado un repositorio en el servidor, se puede visualizar en la aplicación el commit realizado anteriormente: ILUSTRACIÓN 68: APLICACIÓN GITHUB El revisor realiza la revisión de la tarea: ILUSTRACIÓN 69: VALIDAR TAREA

83 Se cambia el estado de la tarea, de tal manera que esta quede terminada ILUSTRACIÓN 70: CAMBIAR ESTADO Después de la revisión de errores, si el código se encuentra correcto se realiza la sincronización con el repositorio. ILUSTRACIÓN 71: SINCRONIZAR

84 ILUSTRACIÓN 72: SINCRONIZAR EN GIT Si se encuentran errores el código se debe notificar los errores al desarrollador ILUSTRACIÓN 73: NOTIFICAR ERRORES

85 Transición En la fase de transición se ejecutan las pruebas y se realiza la revisión del código, permitiendo informar al desarrollador y al revisor las fallas que se encuentren en cada prueba, para este caso se utilizó Jenkins. Cuando las funcionalidades no presentan fallas, el servidor Hudson permite realizar el empaquetamiento y despliegue de la funcionalidad en el servidor de aplicaciones. De esta manera según las buenas prácticas de las metodologías agiles, en esta fase se implementa: Facilidad para ajustar errores y realizar correcciones Realizar pruebas Para realizar las pruebas de las funcionalidades que tiene el proyecto, se ejecuta a través de del servidor Hudson, en donde se selecciona el proyecto al que se le quiere aplicar las pruebas, después de esto se genera un informa de validación del proyecto.