Propuesta para Trabajo de Grado

I.2. Descripción del Proyecto

I.2.1. Visión global

Este trabajo de grado se realizó con el fin de automatizar los procesos en la gestión de proyectos de software basados en metodologías ágiles, gestión apoyada en un ambiente de desarrollo colaborativo, en este caso GForge. El trabajo elaboró una Guía metodológica, de manera que se pueda: definir un flujo de trabajo con sus respectivos estados y responsables para cada etapa del proyecto de software, dar seguimiento al avance del proyecto visualizando el estado de las entregas parciales con el progreso de sus correspondientes actividades, conocer el desempeño que obtienen los integrantes con sus respectivas tareas asignadas por medio de reportes que muestran las horas invertidas en el desarrollo de una actividad o un proceso específico.

I.2.2. Justificación

Debido a la centralización de la información obtenida en la gestión de un proyecto de software al utilizar un ambiente desarrollo colaborativo, en este caso GForge, se logra la consolidación de la información referente al estado de un proyecto, apoyando a la toma de decisiones que se requiere durante su gestión. El modelo de gestión que se propone en este trabajo de grado está basado en metodologías ágiles, teniendo en cuenta sus ventajas sobre las metodologías tradicionales [Ambysoft Inc., 2008], en donde se destacan las siguientes: el aumento en la productividad, aumento en la calidad y mayor satisfacción a los involucrados en el proyecto.

Por lo tanto, se encontró la necesidad de elaborar una guía metodológica que automatizara los procesos para la gestión de proyectos de software basados en metodologías ágiles utilizando ambientes de desarrollo colaborativo.

I.2.3. Objetivo general

Definir una guía metodológica que explique el manejo de una herramienta de software basada en ambientes colaborativos para la gestión de proyectos de software que utiliza metodologías ágiles, logrando su validación por medio de personas expertas de una casa de software reconocida en Colombia, en un plazo máximo de 192 horas por integrante del semestre 2009-III.

I.2.4. Objetivos específicos

• 
  Realizar el levantamiento de información en cuanto a la manera de realizar guías metodológicas, uso de metodologías ágiles, herramientas de software basadas en ambientes de desarrollo colaborativo, trackers y workflows en GForge.
  
• 
  Elaborar una comparación entre las diferentes herramientas de software basadas en ambientes de desarrollo colaborativo.
  
• 
  Instalar GForge con los plugins de Microsoft Project y el IDE Eclipse.
  
• 
  Definir un proyecto de software basado en metodologías ágiles utilizado como demostración dentro de la guía metodológica a realizar.
  
• 
  Definir los workflows y trackers para un proyecto de software que utilice metodologías ágiles en cada una de sus etapas.
  
• 
  Acoplar cada uno de los trackers y workflows basados en metodologías ágiles al proyecto de demostración dentro de GForge.
  
• 
  Documentar en una guía metodológica cómo usar GForge con las características que se necesitan para aplicar las metodologías ágiles.
  

I.2.5. Impacto

Para lograr una mayor difusión de los productos principales de este trabajo de grado y un uso libre por parte de la empresa privada y las universidades, se ha decidido que la Guía metodológica para la gestión de proyectos de software 
basados en metodologías ágiles, utilizando a GForge como ambiente de desarrollo colaborativo y el Manual de instalación y configuración de GForge AS 5.6.1 se liberen por medio de la licencia de Creative Commons [Creative Commons Corp., 2010] Reconocimiento-Compartir bajo la misma licencia 2.5 Colombia, la cual permite: copiar, distribuir, comunicar públicamente la obra, hacer obras de derivadas y utilizar los contenidos para fines comerciales, bajo las condiciones de reconocer los autores y de compartir el contenido de los documentos bajo la misma licencia como se puede observar el siguiente link: http://creativecommons.org/licenses/by-sa/2.5/co/.

Gracias a la licencia Reconocimiento-Compartir que poseen la Guía metodológica para la gestión de proyectos de software basados en metodologías ágiles, utilizando a GForge como ambiente de desarrollo colaborativo y el Manual de instalación y configuración de GForge AS 5.6.1 se utilizarán estos documentos en la maestría de Ingeniería de Sistemas y Computación en la Pontificia Universidad Javeriana para el curso Tópicos Avanzados en Ingeniería de Software en donde se enseña la gestión de proyectos de software por medio de las metodologías ágiles y se desarrolla un proyecto de software utilizando GForge y la automatización de los procesos de la gestión por medio de la guía elaborada como principal producto de este trabajo de grado.

II - MARCO TEÓRICO

II.1. Marco Contextual

II.1.1. Ambiente de desarrollo colaborativo (CDE)

Un entorno de desarrollo colaborativo es un espacio virtual donde todas las
las partes interesadas de un proyecto, incluso si se están en diferente tiempo o lugar, puede negociar, hacer una lluvia de ideas, debatir, compartir conocimientos y en general trabajar en conjunto para llevar a cabo algunas tarea, la mayoría de las veces para crear un ejecutable de aplicación y sus artefactos.

La colaboración es esencial para cada rama de la ingeniería pero concretamente, se va hablar de ingenieros de software en sus tareas de diseñar la aplicación, implementación y mantenimiento de software de alta calidad haciendo uso de la Internet como base para sus interacciones sin importar que estén físicamente separados [Booch & Brown, 2002].

II.1.2. Metodologías ágiles

Las metodologías ágiles son un subconjunto de las metodologías iterativas e incrementales, en el cual el ciclo de vida de un proyecto de software está compuesto de varias iteraciones de forma secuencial [Larman, 2004].

Durante la ejecución de cada una de las iteraciones, se llevan a cabo diferentes actividades de desarrollo de software de forma secuencial como son: el diseño, la implementación y las pruebas; al finalizar se obtiene su correspondiente entrega (iteration release), tal como se puede apreciar en la Ilustración 1.

La entrega de una iteración (iteration release), consiste de un módulo funcional (conjunto de casos de uso) del sistema final, junto con sus respectivos documentos que se obtuvieron durante la realización de sus correspondientes actividades de desarrollo. También es necesario mencionar, que al iniciar una iteración, se trabaja a partir del resultado obtenido en la entrega de la iteración anterior, de tal forma que en la entrega de la iteración final, se obtiene el sistema final, tal como se puede apreciar en la Ilustración 2.

Las metodologías ágiles utilizan los fundamentos del desarrollo iterativo evolutivo y del desarrollo adaptativo. El primero implica que los requerimientos, los planes, las estimaciones y las soluciones evolucionan o son refinados a través de las iteraciones. De forma similar, el desarrollo adaptativo implica que los elementos se adaptan de acuerdo a la retroalimentación brindada por los usuarios, probadores, desarrolladores, y demás stakeholders. De tal manera que el concepto del desarrollo adaptativo es similar al del desarrollo iterativo evolutivo, con la excepción de que el término retroalimentación tiene mayor peso en la evolución [Larman, 2004].

Ilustración 1 - Agile software development¹

Ilustración 2 - Iteration release²

II.1.2.1. Manifiesto ágil

En febrero de 2001 se creó el manifiesto ágil aplicado al desarrollo de software [Beedle, y otros, 2001]. Su objetivo fue definir los valores y principios para el desarrollo de software de manera ágil, teniendo en cuenta los cambios que se puedan presentar a lo largo del desarrollo del proyecto [Letelier & Penadés, 2003]. A continuación se presenta el manifiesto ágil en detalle [Beedle, y otros, 2001]:

Estamos descubriendo mejores métodos de desarrollo de software al hacerlo y ayudando a otros a hacerlo. A través de este trabajo, hemos llegado a valorar:

Los individuos e interacciones SOBRE los procesos y herramientas.

El trabajo en software SOBRE la documentación completa.

La colaboración de los clientes SOBRE la negociación en los contratos.

La respuesta al cambio SOBRE el seguimiento de un plan.

Es decir, mientras hay valor en los elementos de la derecha, nosotros valoramos más los elementos de la izquierda.

II.1.2.2. Principios del manifiesto ágil

En el manifiesto ágil se fundamenta en los siguientes principios [Beedle, y otros, 2001], en donde de acuerdo a [Letelier & Penadés, 2003], se comienza por describir el espíritu ágil (principios número 1 y 2), luego se describen algunos detalles de los procesos en el desarrollo de software (principios: 3 - 8) y se finaliza con la descripción del equipo de desarrollo (principios 9 - 12). A continuación se presentan los principios del manifiesto ágil, tomando literalmente las conclusiones expuestas en el documento de [Letelier & Penadés, 2003]:

1. 
   La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Un proceso es ágil si a las pocas semanas de empezar ya entrega software que funcione aunque sea rudimentario. El cliente decide si pone en marcha dicho software con la funcionalidad que ahora le proporciona o simplemente lo revisa e informa de posibles cambios a realizar.
   
2. 
   Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Este principio es una actitud que deben adoptar los miembros del equipo de desarrollo. Los cambios en los requisitos deben verse como algo positivo. Les va a permitir aprender más, a la vez que logran una mayor satisfacción del cliente. Este principio implica además que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste añadido. El paradigma orientado a objetos puede ayudar a conseguir esta flexibilidad.
   
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. Las entregas al cliente se insiste en que sean software, no planificaciones, ni documentación de análisis o de diseño.
   
4. 
   La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que la interacción con el equipo es muy frecuente.
   
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. La gente es el principal factor de éxito, todo los demás (proceso, entorno, gestión, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado.
   
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. Los miembros de equipo deben hablar entre ellos, éste es el principal modo de comunicación. Se pueden crear documentos pero no todo estará en ellos, no es lo que el equipo espera.
   
7. 
   El software que funciona es la medida principal de progreso. El estado de un proyecto no viene dado por la documentación generada o la fase en la que se encuentre, sino por el código generado y en funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el 50% de los requisitos ya están en funcionamiento.
   
8. 
   Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. No se trata de desarrollar lo más rápido posible, sino de mantener el ritmo de desarrollo durante toda la duración del proyecto, asegurando en todo momento que la calidad de lo producido es máxima.
   
9. 
   La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto.
   
10. 
    La simplicidad es esencial. Tomar los caminos más simples que sean consistentes con los objetivos perseguidos. Si el código producido es simple y de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir.
    
11. 
    Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. Todo el equipo es informado de las responsabilidades y éstas recaen sobre todos sus miembros. Es el propio equipo el que decide la mejor forma de organizarse, de acuerdo a los objetivos que se persigan.
    
12. 
    En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. Puesto que el entorno está cambiando continuamente, el equipo también debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organización, sus reglas, sus convenciones, sus relaciones, etc., para seguir siendo ágil.
    

II.1.3. Resultados de la encuesta Agile Adoption Rate Survey Results: February 2008

De acuerdo a la encuesta Agile Adoption Rate Survey Results: February 2008 realizada por el Dr. Dobb’s [Ambysoft Inc., 2008], la cual pretendía explorar el estado en el año 2008 en la adopción y las tasas de éxito en las técnicas de desarrollo de software con metodologías ágiles, se encontró que la tasa de adopción fue la misma del año 2007 en 69%, la mayoría de los equipos ágiles tenían iteraciones de 4 o menos semanas de duración y que los equipos ágiles tenían altos niveles de éxito. También se encontró que la gente cree en promedio que los equipos ágiles están produciendo mayores niveles de calidad, son más productivos y logran mayor satisfacción de los stakeholders, todo esto a un menor costo que en las metodologías tradicionales.

A continuación se presentan las gráficas de los resultados obtenidos en la encuesta realizada por el Dr. Dobb’s:

Ilustración 3 - Productividad con las metodologías ágiles³



Ilustración 4 - Calidad con las metodologías ágiles⁴



Ilustración 5 - Satisfacción de los stakeholders con las metodologías ágiles⁵



Ilustración 6 - Tasas de éxito en las metodologías ágiles por el nivel de distribución en los miembros del equipo⁶



Ilustración 7 - Costo en el desarrollo del sistema con las metodologías ágiles⁷

De acuerdo a [Ambysoft Inc., 2008], se pudo concluir lo siguiente, con respecto a la encuesta que se nombró anteriormente:

• 
  El 69% de los encuestados indicaron que en sus organizaciones, uno o más proyectos están basados en metodologías ágiles. De los que todavía no habían comenzado, el 15% cree que sus compañías lo harán en el próximo año.
  
• 
  El 82% de las organizaciones que utilizan las metodologías ágiles en el desarrollo de software, se encontraban más allá de la fase del proyecto piloto.
  
• 
  Aunque en promedio los costos son más bajos en los equipos ágiles, el 23% de los encuestados creen que están experimentando los mayores costos que el promedio. 40% dijo que los costos se mantuvieron sin cambios, y el 37% que los costos eran menores.
  

A continuación se ilustran las razones más importantes para adoptar las metodologías ágiles en la gestión de proyectos de software, de acuerdo a [VersionOne, Inc., 2009].



Ilustración 8 - Razones por adoptar las metodologías ágiles⁸

II.1.4. Comparación de los ambientes de desarrollo colaborativo (CDE)

A continuación vamos a presentar una breve comparación entre los ambientes de desarrollo colaborativo (CDE): Asynchrony [Asynchrony Solutions, Inc., 2009], Freepository [Freepository, Inc., 2010], GBorg [PgFoundry Group, 2010], GForge [GForge Group, 2007], Savannah [Free Software Foundation, Inc., 2010], SEUL [SEUL Project, 2004] y SourceForge [Geeknet, Inc., 2010], los cuales fueron escogidos debido a que algunos de estos son los más populares en el mercado, y además; cuentan con características adicionales que actualmente son importantes para la gestión de proyectos de software, como lo son: las listas de correos, los foros, los repositorios del código fuente y los gestores de trackers, los cuales permiten dar seguimiento y apoyan la evolución del proyecto.

Para esta comparación se tomo como fuente principal el trabajo doctoral: “Construction of an Evaluation Model for Free/Open Source Project Hosting Sites” [Heng So, 2005] [So, Dingledine, Gordon, Minnihan, Reiniger, & Ryan, 2007] y el website del Wiki: “Comparison of open source software hosting facilities” [Wapedia Mobile Encyclopedia, 2010], debido a que estos comparan y prueban diferentes ambientes de desarrollo colaborativo (CDE), entre los cuales, los que se han escogido para esta comparación son los que se han mencionado anteriormente.

Información general
	Asynchrony	Freepository	GBorg	GForge	Savannah	SEUL	SourceForge
Descripción breve	Alojamiento web de código abierto y cerrado, además de la venta de proyectos en curso.	Repositorio seguro con Subversion, con un plan básico gratis (sólo con acceso web) y las versiones que cuentan con más características son de pago.	Un sitio específico para los proyectos relacionados con PostgreSQL. Impulsado por GForge.	Una herramienta abierta colaborativa de desarrollo de software, que permite gestionar cualquier número de proyectos de desarrollo de software.	Es el ambiente de desarrollo colaborativo más popular para el desarrollo de software GNU.	Almacena un conjunto completo de aplicaciones de alta calidad disponible para la plataforma Linux.	La herramienta de desarrollo colaborativa de software más conocida y con amplias utilidades.
Dirección	Asynchrony.com Inc.	Dirigido por John Minnihan	Dirigido por el equipo de de desarrollo de GBorg.	Dirigido por un equipo encabezado por el exlíder de SourceForge: Tim Perdue	Free Software Foundation	Grupo de voluntarios "Simple End-User Linux"	VA Software Corporation
Número de proyectos	1,848	540	330	65	3,074	Más de 50	230,000
Número de miembros	33,309	783	9,475	1,046	62,453	Con acceso Shell 300 y con CVS 225.	2’000,000
Costos	Indeterminado	SVN Básico Gratis. SVN + US$39 /año. SVN Extremo US$189 /año.	Gratis	Gratis para proyectos con menos de 15 usuarios.	Gratis	Gratis	Gratis y la versión que se puede descargar (Collabnet - TeamForge) cuesta US$4,995 la licencia
Tipo de licencia	Propietaria	GPL	GPL	GPL	GPL	GPL	GPL

Tabla 1 - Información general de los CDEs

Herramientas para el público o desarrolladores
	Asynchrony	Freepository	GBorg	GForge	Savannah	SEUL	SourceForge
Formato HTML libre	Si	No	No	Si	Si	Si	Si
Asignación de roles del proyecto	Si	Basados en los permisos que ofrece CVS	Si	Si	Si	Manual	Si
Noticias del proyecto	Si	No	Si	Si	Si	Manual	Si
Servicio de descarga	HTTP	HTTPS	FTP	File Release	FTP	HTTP, FTP	File Release
Administración de la documentación	Manual	No	FAQ, páginas generadas	DocManager	FAQ	Manual	DocManager
Estadísticas	Número de descargas de las versiones beta y número de versiones creadas.	No determinado	No	Actividad en el proyecto, tráfico en la red, estadísticas comparativas.	No determinado	Estadísticas disponibles en Internet: http://stats.seul.org/	Actividad en el proyecto, tráfico en la red, estadísticas comparativas.
Repositorio del código fuente	Servidor CVS	Servidor CVS, CVSweb, y plugin de Eclipse	Servidor CVS y ViewCVS	Servidor CVS y CVSweb	Servidor CVS y ViewCVS	Servidor CVS, ViewCVS y CVSweb	Servidor CVS y ViewCVS
Lista de mensajes	Si	No	Mailman	Mailman	Mailman	Majordomo y MHonArc	Mailman
Tracker	Petición o tarea en los cambios dentro del proyecto	No	Tareas, características y bugs.	Definido por GForge y por el usuario	Bug, soporte, parches, tarea	Jitterbug y Manual	Bugs, soporte, parches, características, tareas y sus dependencias
Foro	Si	No	No	Si	Si	Manual	Si
Wiki	No determinado	No	No	Manual	No	Manual	Manual
Encuestas	Rating definido a partir de los atributos del proyecto	No	No	Si	No determinado	Manual	Manual
Otras herramientas			Administrador de parches	Gestor de tareas y gráfico de Gantt

Tabla 2 - Herramientas para el público o desarrolladores de los CDEs

Herramientas del proyecto – Herramientas para los administradores del proyecto
	Asynchrony	Freepository	GBorg	GForge	Savannah	SEUL	SourceForge
Administrador de herramientas para los desarrolladores y el público	Si	No	Si	Si	Si	Manual	Si
Historial de actividades	Desconocido	No	No	Si	Si	Manual	Si
Soporte de scripts por parte del servidor web	Desconocido	No	No	Depende de la disponibilidad de cada uno de los sitios	No	SSI, PHP3, PHP4,CGI, Embperl	PHP3, PHP4
Base de datos	Desconocido	No	No	Si	No	MySQL and PostgreSQL	MySQL
Shell	Desconocido	No	No	Si	Sólo algunas personas lo tienen.	A disposición de los desarrolladores seleccionados.	Si
Alojamiento Virtual	Si	No	No	Si	No	Si	Si
Carga de datos	FTP	CVS vía SSL	Formulario HTTP y FTP.	Formulario HTTPS	CVS vía SSH	SCP, SFTP y rsync	SCP, SFTP y FTP
Seguridad	SSH y SSL	SSL		Depende de la política de cada uno de los sitios	SSH1, SSL en web	SSH1, SSH2	SSH1, SSH2, SSL en web
Política en las copias de seguridad	Política desconocida	Política desconocida	Política desconocida	Depende de la política de cada uno de los sitios	Política desconocida	Los usuarios hacen copia de seguridad	Política de copia de seguridad (5 tipos de copia, al día)

Tabla 3 – Herramientas para los administradores del proyecto en los CDEs

Herramientas personales para los desarrolladores
	Asynchrony	Freepository	GBorg	GForge	Savannah	SEUL	SourceForge
Monitoreo de Trackers/Foros/archivos	No determinado	No	Sólo para trackers	Si	Si	No	Si
Proyectos implicados	Si	No	Si	Si	Si	No	Si
Problemas desde los trackers Asignado/Enviado	No determinado	No	No, pero se puede enviar notificación a través del sistema de monitoreo	Si	Si	No	Si
Inspección de las opiniones de los usuarios	No	No	No	Si	No	No	No
Correo electrónico	Redirigido	No	No	Redirigido	Redirigido	Manual	Redirigido
Calendario	No	No	No	Si	No	No	Si
Marcadores	No	No	No	Si	Si	No	Si

Tabla 4 - Herramientas personales para los desarrolladores que hay en los CDEs

De acuerdo a los resultados obtenidos en la comparación anterior entre los CDEs mencionados, se observa la gran importancia que hay en los servicios que buscan la privacidad y seguridad en el acceso a los documentos y demás información vital para los proyectos que se estén desarrollando, como también un bajo costo al que hay que incurrir para contar con los servicios que estos ofrecen. Además, se observa que la mayoría de los CDEs que existen actualmente, ofrecen todos sus servicios desde una plataformas web, lo que brinda una mayor accesibilidad para los stakeholders del proyecto, los cuales se conectan a los repositorios de forma remota o local, y la mayoría de proyectos que se están desarrollando por medio de esta tecnología, resultan ser en su gran mayoría, aplicaciones de software libre.

Por consiguiente, después de haber observado y analizado las funcionalidades para los CDEs anteriormente mencionados, se define para este proyecto, que después de las funcionalidades tales como la privacidad y la seguridad en los repositorios internos y las diferentes herramientas de gestión de proyectos de software anteriormente mencionadas, también es necesario tener en cuenta el precio como uno de los criterios más relevantes a la hora de escoger el CDE que se ajuste a las necesidades para una casa de software que no quiera incurrir en gastos relacionados a los costos de las licencias.

Finalmente, se puede concluir que GForge se ajusta a los criterios para este proyecto, ya que además de incluir algunas de las herramientas importantes para la gestión de proyectos de software, incorpora gestores de tareas y los diagramas de Gantt para la toma de decisiones, y además, este CDE se puede descargar como una aplicación independiente brindando la posibilidad de alojar los repositorios de forma interna con políticas de seguridad privadas, logrando mayor confidencialidad de la información.

II.1.5. Unified Software Development Process (UP)

De acuerdo a [Bruegge & Dutoit, 2004], el Unified Software Development Process, es un modelo de ciclo de vida de software iterativo caracterizado por ciclos de cuatro fases llamados: Inicio, elaboración, construcción y transición.