Guía metodológica para la gestión de proyectos ágiles...
91
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
Transcript of Guía metodológica para la gestión de proyectos ágiles...
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
Tabla de contenido Tabla de ilustraciones .......................................................................................................................... 5
1. Aspectos generales...................................................................................................................... 7
1.1. Contexto .............................................................................................................................. 7
1.2. Objetivo de la guía............................................................................................................... 8
1.3. Alcance ................................................................................................................................ 8
1.4. ¿A quién va dirigida la guía? ................................................................................................ 8
2. Marco de referencia .................................................................................................................... 9
2.1. Metodologías ágiles ............................................................................................................ 9
2.1.1. Valores ......................................................................................................................... 9
2.1.2. Principios ................................................................................................................... 10
2.1.3. Tipos de metodologías agiles .................................................................................... 11
2.1.3.1. Scrum ................................................................................................................. 11
A. Equipo Scrum ............................................................................................................ 12
B. Eventos en Scrum ...................................................................................................... 13
2.1.3.2. Extreme Programming ...................................................................................... 14
A. Buenas prácticas ........................................................................................................ 14
2.1.3.3. Disciplined Agile Delivery .................................................................................. 18
A. Roles .......................................................................................................................... 18
B. Ciclo de vida .............................................................................................................. 19
2.1.3.4. AUP Ágil ............................................................................................................. 20
A. Ciclo de vida .................................................................................................................. 21
2.2. Integración Continua ......................................................................................................... 22
2.2.1. Prácticas para la integración continua ...................................................................... 23
2.2.2. Características generales ........................................................................................... 24
2.3. Control de versiones ......................................................................................................... 25
2.3.1 Conceptos básicos ..................................................................................................... 25
2.3.2 Control de versiones locales ..................................................................................... 26
2.3.3 Control de versiones centralizadas ........................................................................... 26
2.3.4 Control de versiones distribuidas .............................................................................. 27
2.4. Ambientes colaborativos ................................................................................................... 28
2.4.1. Facilidades ofrecidas por los ambientes colaborativos ............................................ 28
2.4.2. Manejo de actividades .............................................................................................. 29
3. Buenas prácticas y herramientas seleccionadas. ........................................................................ 9
3.1. Mejores prácticas de las metodologías agiles ................................................................... 31
3.1.1. Mejor metodología ágil ............................................................................................. 31
3.1.2. Mejor metodología para cada grupo de criterios .................................................... 31
3.1.3. Mejores criterios de las metodologías agiles para el desarrollo de la guía .............. 35
3.2. Herramientas seleccionadas y Plugins ............................................................................. 36
3.2.1. Jenkins ....................................................................................................................... 36
3.2.1.1. Características generales ................................................................................... 36
3.2.2. Mylyn ......................................................................................................................... 37
Características generales....................................................................................................... 37
3.2.3. Git .............................................................................................................................. 37
3.3. Descripción del entorno integrado Eclipse Indigo ............................................................ 38
4. Guía Metodología ...................................................................................................................... 39
4.1. Integración ........................................................................................................................ 39
4.1.1. Visión global del sistema .............................................................................................. 39
4.1.2. Arquitectura de Despliegue del sistema ....................................................................... 41
4.1.3. Instalación del Entorno Eclipse servidor y base de datos ......................................... 41
4.1.4. Instalación e integración de las herramientas .......................................................... 43
A. Ambiente colaborativo Mylyn ....................................................................................... 43
B. Repositorio de versiones distribuido Git ...................................................................... 48
C. Integración continua con Hudson ................................................................................. 50
1.1. Pruebas del ambiente integrado ....................................................................................... 53
4.2. Ejecución del proceso de gestión de proyecto de software basado en metodologías ágiles
56
4.2.1. Inicio .............................................................................................................................. 57
Configuración de tracker ........................................................................................................... 58
4.2.2. Elaboración .................................................................................................................... 61
4.2.2.1. Crear tareas ........................................................................................................... 61
4.2.3. Desarrollo ...................................................................................................................... 73
4.2.3.1. Proceso de desarrollo ............................................................................................ 74
4.2.3.2. Desarrollo de una tarea ......................................................................................... 74
4.2.4. Transición ...................................................................................................................... 85
Realizar pruebas ........................................................................................................................ 85
5. Referencias ................................................................................................................................ 87
6. Anexos ....................................................................................................................................... 90
6.1. Manual de instalación ....................................................................................................... 90
Tabla de ilustraciones
Ilustración 1: ciclo de vida con extensión de Scrum ......................................................................... 20
Ilustración 2: ciclo de vida y etapas Agil Unified Proces . Tomado de:
http://www.ambysoft.com/unifiedprocess/agileUP.html , “The Agile Unified Process (AUP)
lifecycle”, 2005 .................................................................................................................................. 22
Ilustración 3: Flujo integración continua, tomado de: http://blog.juliopari.com/integracion-
continua-en-proyectos-agiles-de-software/, “Integración Continua en Proyectos Ágiles de
Software”, 2013 ................................................................................................................................ 23
Ilustración 4: Proceso de ramificado. Tomado de:
http://vis.usal.es/rodrigo/documentos/aso/seminarios/controlVersiones.pdf, “Sistema de control
de versiones”, .................................................................................................................................... 26
Ilustración 5: Control de versiones distribuida. Tomado de: http://git-
scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones, “Sistemas de control de
versiones distribuidos”, ..................................................................................................................... 27
Ilustración 6: Git almacena la información como instantáneas. Tomado de: http://git-
scm.com/book/es/v1/Empezando-Fundamentos-de-Git, “Fundamentos de Git”, .......................... 38
Ilustración 7 visión global de la arquitectura ................................................................................... 40
Ilustración 8 Diagrama de despliegue datos ..................................................................................... 42
Ilustración 9 Pasos para instalación e integración ............................................................................ 43
Ilustración 10: Eclipse Marketplac .................................................................................................... 44
Ilustración 11: despliegue plugins ..................................................................................................... 45
Ilustración 12: Características plugin ................................................................................................ 45
Ilustración 13: Instalación Mylyn ...................................................................................................... 46
Ilustración 14: ventana de tareas ...................................................................................................... 47
Ilustración 15:task list ....................................................................................................................... 47
Ilustración 38: ingreso Eclipse Marketplace...................................................................................... 48
Ilustración 39: SELECCIONAR repositorio git ..................................................................................... 49
Ilustración 40: realizar commit sobre la tarea “agregar funcionalidad eliminar book” .................... 50
Ilustración 48: ADD BUILD SERVER .................................................................................................... 50
Ilustración 49: SERVIDOR HUDSON ................................................................................................... 51
Ilustración 50: PROPIEDADES DEL SERVIDOR .................................................................................... 52
Ilustración 51: MONITOREO DE PRUEBAS ......................................................................................... 52
Ilustración 52: NOTIFICAR PRUEBAS ................................................................................................. 53
Ilustración 53: COMMIT .................................................................................................................... 54
Ilustración 54:HISTORIAL DE CAMBIOS ............................................................................................. 55
Ilustración 55: EMPAQUETADO ......................................................................................................... 55
Ilustración 56: Fases Vs Roles ............................................................................................................ 57
Ilustración 57: crear nueva categoría ............................................................................................... 58
Ilustración 58: Asignar nombre categoría ......................................................................................... 59
Ilustración 59: nuevo query .............................................................................................................. 59
Ilustración 60: seleccionar repositorio .............................................................................................. 60
Ilustración 61: asignar nombre al tracker remoto ............................................................................ 60
Ilustración 16: categorías .................................................................................................................. 61
Ilustración 17: visualizar tareas ......................................................................................................... 61
Ilustración 18: new task .................................................................................................................... 62
Ilustración 19: tipo de tarea .............................................................................................................. 62
Ilustración 20: configuración de tareas ............................................................................................. 63
Ilustración 21: Servidor Bugzilla ........................................................................................................ 64
Ilustración 22: Crear cuenta .............................................................................................................. 64
Ilustración 23: Agregfar repositorio bugzilla ..................................................................................... 65
Ilustración 24: instalar bugzilla .......................................................................................................... 65
Ilustración 25: instalar repositorio .................................................................................................... 66
Ilustración 26: Eclipse org ................................................................................................................. 67
Ilustración 27: Creacion tarea ........................................................................................................... 68
Ilustración 28: Crear nuevo bug ........................................................................................................ 68
Ilustración 29: Nombre de una tarea ................................................................................................ 69
Ilustración 30: Product task............................................................................................................... 69
Ilustración 31: Prioridad y componente de la tarea.......................................................................... 70
Ilustración 32: ASOCIAR elementos a la tarea .................................................................................. 70
Ilustración 33: CRONOGRAMA de la tarea ........................................................................................ 70
Ilustración 34: descripcion tarea ....................................................................................................... 71
Ilustración 35: Asignar tarea ............................................................................................................. 71
Ilustración 36: propiedades bug ........................................................................................................ 72
Ilustración 37: parámetros query ...................................................................................................... 73
Ilustración 62: proceso de desarrollo ................................................................................................ 74
Ilustración 63: Notificar tarea ........................................................................................................... 75
Ilustración 64: identificar clases para realizar tarea ......................................................................... 75
Ilustración 65: Desarrollar método ................................................................................................... 76
Ilustración 66: Agregar método a la clase EJB ................................................................................... 77
Ilustración 67: identificar método ..................................................................................................... 77
Ilustración 68: realizar commit ......................................................................................................... 78
Ilustración 41: HISTORIAL código ...................................................................................................... 78
Ilustración 42: repositorio git .......................................................................................................... 79
Ilustración 43: página principal Github ............................................................................................. 80
Ilustración 44: Crear cuenta Github .................................................................................................. 80
Ilustración 45: Crear nuevo repositorio ............................................................................................ 81
Ilustración 46: creación repositorio Github ...................................................................................... 81
Ilustración 47: aplicación GITHUB .................................................................................................... 82
Ilustración 69: validar tarea .............................................................................................................. 82
Ilustración 70: cambiar estado .......................................................................................................... 83
Ilustración 71: Sincronizar ................................................................................................................. 83
Ilustración 72: sincronizar en git ....................................................................................................... 84
Ilustración 73: notificar errores......................................................................................................... 84
Ilustración 74: Agregar el servidor hudson y seleccionar la aplicación............................................. 86
Ilustración 75: ver resultado ............................................................................................................. 86
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.
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.
1.3. 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 y 20 personas, puesto que la
herramienta permitirá tener un máximo de 20 roles asignados.
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.
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]
2.1.1. 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.
2.1.2. 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.
2.1.3. Tipos de metodologías agiles
2.1.3.1. 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 Difícil de dominar.
o Fácil de entender.
o Equipos auto-dirigidos y auto- organizados.
o Iteraciones de 30 días.
o Comunicación directa entre el cliente y el equipo de trabajo.
o Desarrollo incremental.
o Flexibilidad y adaptación.
o Resultados anticipados.
o Fomenta la motivación del equipo de trabajo.
o El desarrollo del trabajo se centra en lo comprometido, transparencia y visibilidad.
o Equipos de trabajo multi- funcionales.
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.
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.
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?
2.1.3.2. 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.
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.
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.
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.
2.1.3.3. 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
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.
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.
2.1.3.4. 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]:
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.
ILUSTRACIÓN 2: CICLO DE VIDA Y ETAPAS AGIL UNIFIED PROCES . TOMADO DE:
HTTP://WWW.AMBYSOFT.COM/UNIFIEDPROCESS/AGILEUP.HTML , “THE AGILE UNIFIED PROCESS (AUP)
LIFECYCLE”, 2005
2.2. 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]
ILUSTRACIÓN 3: FLUJO INTEGRACIÓN CONTINUA, TOMADO DE: http://blog.juliopari.com/integracion-
continua-en-proyectos-agiles-de-software/, “INTEGRACIÓN CONTINUA EN PROYECTOS ÁGILES DE
SOFTWARE”, 2013
2.2.1. 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.
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.
2.2.2. 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.
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]
2.3.1 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]
ILUSTRACIÓN 4: PROCESO DE RAMIFICADO. TOMADO DE:
Http://vis.usal.es/rodrigo/documentos/aso/seminarios/controlVersiones.pdF, “SISTEMA DE
CONTROL DE VERSIONES”,
2.3.2 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]
2.3.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
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.
2.3.4 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: HTTP://GIT-
SCM.COM/BOOK/ES/V1/EMPEZANDO-ACERCA-DEL-CONTROL-DE-VERSIONES, “SISTEMAS DE CONTROL DE
VERSIONES DISTRIBUIDOS”,
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.
2.4.1. 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
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.
2.4.2. 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.
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
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].
3.1. 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:
3.1.1. 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.
3.1.2. 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
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 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.
o 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.
o 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.
o 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.
o 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.
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 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.
o 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.
o B.3 – Identificar los posibles riesgos del proyecto: se debe identificar los posibles
riesgos durante la ejecución del proyecto.
o 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.
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 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.
o 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.
o 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
o D.4 - Facilidad de elaboración de pruebas al finalizar cada desarrollo: es necesario
elaborar pruebas de aceptación para cada iteración.
o 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,
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.
o 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
3.1.3. 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
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.
3.2. Herramientas seleccionadas y Plugins
3.2.1. 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.
3.2.2. 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.
3.2.3. 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]
ILUSTRACIÓN 6: GIT ALMACENA LA INFORMACIÓN COMO INSTANTÁNEAS. TOMADO DE: HTTP://GIT-
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.
4. Guía Metodología
4.1. Integración
4.1.1. Visión global del sistema
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.
4.1.2. 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.
4.1.3. Instalación del Entorno Eclipse servidor y base de datos
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
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 7.1.1.final
Ampliar la aplicación Java EE 7
4.1.4. Instalación e integración de las herramientas
Las herramientas que se especificaron en la sección 4.2.1 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:
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.
•Instalar plugin
•Confugirar servidor Bugzilla
•Configurar servidor Gerrit
Mylyn•Instalar plugin
•Configurar repositorio Git
Git
•Instalar plugin
•Configurar servidor Hudson
Hudson
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
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
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.
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
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.
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.
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
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.
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
4.1.5. 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.
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.
ILUSTRACIÓN 25:HISTORIAL DE CAMBIOS
Debe ser empaquetado y agregado al servidor de aplicaciones el demo.
ILUSTRACIÓN 26: EMPAQUETADO
La aplicación se puede visualizar con los cambios realizados en el servidor de aplicaciones JBoss
que se había configurado previamente.
4.2. 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
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:
ILUSTRACIÓN 27: FASES VS ROLES
4.2.1. 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:
•Desarrollador•Probador
•Desarrollador
•Lider del proyecto
•Desarrollador
•Lider del proyecto
•Arquitecto
•Analista
Inicio Elaboración
DesarrolloTransición
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.
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
ILUSTRACIÓN 31: SELECCIONAR REPOSITORIO
ILUSTRACIÓN 32: ASIGNAR NOMBRE AL TRACKER REMOTO
4.2.2. 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 4.2.1.1 instalación e
integración de las herramientas, ambientes colaborativos.
4.2.2.1. 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
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
Si es una tarea local se debe configurar el nombre de la tarea, la fecha de entrega y la
descripción de la tarea.
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 https://bugs.eclipse.org/bugs/
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:
ILUSTRACIÓN 40: AGREGFAR REPOSITORIO BUGZILLA
ILUSTRACIÓN 41: INSTALAR BUGZILLA
En el buscador colocar Bugzilla e instalar el repositorio:
ILUSTRACIÓN 42: INSTALAR REPOSITORIO
Se debe asociar el repositorio de Bugzilla con la cuenta creada anteriormente.
ILUSTRACIÓN 43: ECLIPSE ORG
Luego de realizar la instalación, se debe seleccionar el repositorio Eclipse.org cuando se crea una
tarea:
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
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
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
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:
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.
ILUSTRACIÓN 54: PARÁMETROS QUERY
4.2.3. 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.
4.2.3.1. 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
4.2.3.2. Desarrollo de una tarea
Inicialmente se notifica al desarrollador la nueva tarea a través de correo electrónico
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
Se debe desarrollar el método en las clases necesarias.
ILUSTRACIÓN 58: DESARROLLAR MÉTODO
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
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
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 https://github.com/ 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
ILUSTRACIÓN 64: PÁGINA PRINCIPAL GITHUB
Crear cuenta en Github
ILUSTRACIÓN 65: CREAR CUENTA GITHUB
Crear repositorio GitHub
ILUSTRACIÓN 66: CREAR NUEVO REPOSITORIO
Asignar nombre al repositorio y crearlo.
ILUSTRACIÓN 67: CREACIÓN REPOSITORIO GITHUB
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
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
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
4.2.4. 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.
ILUSTRACIÓN 74: AGREGAR EL SERVIDOR HUDSON Y SELECCIONAR LA APLICACIÓN
ILUSTRACIÓN 75: VER RESULTADO
5. Referencias
[1] A. W. B. Grady Booch, «Collaborative Development,» pp. 1-27, 2002.
[2] M. Mann, «Ingeneria de software,» 2008, pp. 63-65.
[3] Git, « Empezando - Acerca del control de versiones,» 12 Mayo 2014. [En línea]. Available:
http://git-scm.com/book/es/Empezando-Acerca-del-control-de-versiones.
[4] M. Fowler, «Continuous Integration,» 1 Mayo 2006. [En línea]. Available:
http://martinfowler.com/articles/continuousIntegration.html.
[5] P. Letelier y M. C. Penadés, «Métodologías ágiles para el desarrollo de software: eXtreme
Programming (XP),» [En línea]. Available:
http://dialnet.unirioja.es/servlet/articulo?codigo=1983605. [Último acceso: 22
Septiembre 2014].
[6] F. E. M. A. A. N. E. R. A. G. Bioul, «Metodologías Ágiles, análisis de su implementación y
nuevas propuestas,» [En línea]. Available:
http://sedici.unlp.edu.ar/bitstream/handle/10915/19292/Documento_completo.pdf?seq
uence=1. [Último acceso: 22 Septiembre 2014].
[7] L. E. VALENCIA y E. H. URIBE, DEL MANIFIESTO ÁGIL SUS VALORES Y PRINCIPIOS, Pereira,
2007.
[8] M. C. Franky y V. M. T. C., Procesos Ágiles, Bogot{a, 2014.
[9] P. L. y. M. C. P. José H. Canós, «Métodologías Ágiles en el Desarrollo de Software,» [En
línea]. Available: http://noqualityinside.com/nqi/nqifiles/XP_Agil.pdf. [Último acceso: 22
0ctubre 2014].
[10] scrum.org, «What is Scrum?,» 22 Septiembre 2014. [En línea]. Available:
https://www.scrum.org/resources/what-is-scrum/.
[11] aplicandoscrum, «¿Qué es Scrum?,» 22 Septiembre 2014. [En línea]. Available:
http://www.aplicandoscrum.com/scrum/.
[12] J. C. Tello, «SCRUM Metodología de trabajo ágil,» 2014 Septiembre 2014. [En línea].
Available: www2.uah.es/jcaceres/docencia/doc/daw/Metodologia_SCRUM.ppt.
[13] K. Schwaber y J. Sutherland, «The Scrum Guide,» [En línea]. Available:
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf#zoom=100.
[14] xprogramming, «extreme programming,» [En línea]. Available:
http://xprogramming.com/what-is-extreme-programming/. [Último acceso: 23 Agosto
2014].
[15] P. Letelier y M. C. Penadés, «Métodologías ágiles para el desarrollo de software: eXtreme
Programming (XP),» [En línea]. Available: http://www.cyta.com.ar/ta0502/v5n2a1.htm.
[Último acceso: 23 Agosto 2014].
[16] CodeJobs, «¿Qué es la Programación Extrema (XP)?,» 09 Enero 2013. [En línea]. Available:
http://www.codejobs.biz/es/blog/2013/01/09/que-es-la-programacion-extrema-
xp#sthash.WEykAixO.dpbs. [Último acceso: 23 Agoto 2014].
[17] s. wambler, «Roles in Disciplined Agile Delivery,» 18 Diciembre 2012. [En línea]. Available:
http://disciplinedagiledelivery.wordpress.com/2012/12/18/roles-in-disciplined-agile-
delivery/.
[18] C. Edek, «Agile Unified Process,» 3 Septiembre 2013. [En línea]. Available:
http://www.ijcsma.com/publications/september2013/V1I304.pdf. [Último acceso: 30
Septiembre 2014].
[19] Scott Ambler +Associates, «The Agile Unified Process (AUP),» [En línea]. Available:
http://www.ambysoft.com/unifiedprocess/agileUP.html. [Último acceso: 24 Septiembr2
2014].
[20] M. Fowler, «Continuous Integration,» 01 Mayo 2006. [En línea]. Available:
http://martinfowler.com/articles/continuousIntegration.html.
[21] A. M. d. c. g. Carmen, «Ques es Jenkins,» 9 Mayo 2014. [En línea]. Available:
http://www.javiergarzas.com/2014/05/jenkins-en-menos-de-10-min.html.
[22] it- mentor, «IntegracionContinua,» 06 Septiembre 2014. [En línea]. Available:
http://materias.fi.uba.ar/7548/IntegracionContinua.pdf.
[23] J. Roldan, «Integración continua,» 28 Septiembre 2009. [En línea]. Available:
http://tratandodeentenderlo.blogspot.com/2009/09/integracion-continua.html.
[24] I. continua, «Yeray Darias Camacho,» [En línea]. Available:
http://emanchado.github.io/camino-mejor-programador/html/ch08.html. [Último
acceso: 30 Octubre 2014].
[25] E-CENTRO, «La integración continua, Teoría, Principios, Historia, Ventajas y desventajas,
Software,» [En línea]. Available: http://centrodeartigo.com/articulos-
educativos/article_11774.html. [Último acceso: 23 Octubre 2014].
[26] J. Pari, «Integración Continua en Proyectos Ágiles de Software,» 1 Mayo 2013. [En línea].
Available: http://blog.juliopari.com/integracion-continua-en-proyectos-agiles-de-
software/. [Último acceso: 25 Octubre 2014].
[27] Emmanuel, « Control de Versiones, que es y como usarlo,» 25 Octubre 2013. [En línea].
Available: http://efe13.com/2013/10/control-de-versiones-que-es-y-como-usarlo/.
[Último acceso: 13 Octubre 2014].
[28] R. Santamaría, «Sistemas Distribuidos Control de versiones,» [En línea]. Available:
http://vis.usal.es/rodrigo/documentos/aso/seminarios/controlVersiones.pdf. [Último
acceso: 20 Octubre 2014].
[29] M. Rubio, «Sistemas De Control De Versiones: ¿centralizados O Distribuidos?,» 12 Enero
2009. [En línea]. Available: http://altenwald.org/2009/01/12/sistemas-de-control-de-
versiones-%C2%BFcentralizados-o-distribuidos/. [Último acceso: 20 Octubre 2014].
[30] Product & Service advantage, «Solución ALM para productos diseñados,» 12 Octubre
2014. [En línea]. Available: http://es.ptc.com/solutions/enterprise/application-lifecycle-
management.
[31] M. C. Franky, Los ambientes colaborativos como entornos tecnológicos indispensables
para la Gerencia de los proyectos en la era de la automatización industrial del software,
Bogota, Cundinamarca, 2012.
[32] innovasys, «Gestión del ciclo de vida de las aplicaciones (ALM),» 12 Octubre 2014. [En
línea]. Available: http://www.innovasyscorp.com/gestion-ciclo-vida.html.
[33] D. CHAPPELL, «WHAT IS APPLICATION LIFECYCLE,» Diciembre 2008. [En línea]. Available:
http://www.davidchappell.com/WhatIsALM--Chappell.pdf.
[34] B. Phifer, «DAR Basics: Applying Decision Analysis and Resolution in the Real World,»
Marzo 2004. [En línea]. Available:
http://resources.sei.cmu.edu/asset_files/Presentation/2004_017_001_23862.pdf.
[35] K. Kawaguchi, «Meet Jenkins,» 19 Mayo 2014. [En línea]. Available: https://wiki.jenkins-
ci.org/display/JENKINS/Meet+Jenkins.
[36] D. D. P. Chico, Integración continua para open hardware, Madrid, 2012.
[37] Eclipse, «Mylyn,» 12 Octubre 2014. [En línea]. Available:
http://projects.eclipse.org/projects/mylyn.
[38] J. F. Fernández, «Gestiona tu repositorio de tareas sin salir de Eclipse con Mylyn,» 30
Noviembre 2012. [En línea]. Available: http://spartup.es/es/content/gestiona-tu-
repositorio-de-tareas-sin-salir-de-eclipse-con-mylyn.
[39] GIT, «Empezando - Fundamentos de Git,» [En línea]. Available: http://git-
scm.com/book/es/v1/Empezando-Fundamentos-de-Git. [Último acceso: 20 Octubre
2014].
[40] IBM, «Eclipse Indigo presentado,» [En línea]. Available:
http://www.ibm.com/developerworks/ssa/opensource/library/os-eclipse-indigo/.
[Último acceso: 22 Noviembre 2014].
[41] A. P. García, «Eclipse Indigo, la versión 3.7 de Eclipse,» [En línea]. Available:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=eclipse-indigo.
[Último acceso: 22 Noviembre 2014].
[42] GITHUB, «Develop with Git in Eclipse,Share and discuss on GitHub,» [En línea]. Available:
http://eclipse.github.io/. [Último acceso: 12 Octubre 2014].
[43] ECLIPSE, [En línea]. Available: https://wiki.eclipse.org/Mylyn/User_Guide. [Último acceso:
1 Noviembre 2014].
6. Anexos 6.1. Manual de instalación
