Propuesta para Trabajo de Grado

III.2. Desarrollo del Proyecto

Con respecto a la realidad de la ejecución en la metodología planteada para el desarrollo del presente trabajo de grado, la cual se describió en la sección anterior, se tienen los siguientes detalles para cada una de sus fases:

• 
  Fase 1: Levantamiento de información
  

Al iniciar con la ejecución del trabajo de grado, primero se determinó que se debía corregir la propuesta en cuanto al soporte de la información bibliográfica que se tenía, para la cual se buscaron diferentes fuentes de información referentes a los temas de los ambientes de desarrollo colaborativo (CDEs) y el uso de las metodologías ágiles en la gestión de proyectos de software, corrigiendo sustancialmente la información suministrada en la comparación de los ambientes de desarrollo colaborativo evaluados por [So, Dingledine, Gordon, Minnihan, Reiniger, & Ryan, 2007].

Aparte de corregir la propuesta, se realizó una investigación relacionada con el manejo de GForge en la gestión de proyectos de software, y toda la información resultante se clasificó de dentro de un repositorio controlado por el sistema de control de versiones Subversion [Subversion Project, 2001], el cual se decidió que sería nuestro manejador para las versiones resultantes en cada documento desarrollado, a lo largo de la elaboración del proyecto de grado. Sin embargo, a pesar de que se había planeado realizar los documentos de soporte para los procesos estándares involucrados en la gestión de proyectos de software, y debido a la falta de tiempo necesario que se debía utilizar en la siguiente fase, se decidió continuar con la siguiente fase y elaborar los documentos de soporte al final del trabajo de grado.

• 
  Fase 2: Instalación de GForge
  

Al terminar la fase anterior: Levantamiento de información, se procedió a preparar la instalación de GForge en uno de los servidores del laboratorio de sistemas que posee la universidad, para lo cual se inició la fase con una jornada de investigación acerca del procedimiento de instalación, por medio de diferentes recursos digitales disponibles en Internet, entre los cuales también se encontraban los instaladores necesarios de GForge.

Una vez, se tenían los instaladores necesarios del software de GForge, y se había instalado la plataforma Linux CentOS 5.3 en los laboratorios de sistemas de la Pontificia Universidad Javeriana, se procedió a instalar a GForge. Dicha instalación se ejecutaba en tres fases, la primera consistía en descargar algunos paquetes necesarios que complementaban la instalación de GForge en el sistema, una vez superada esta fase, la siguiente consistía en la instalación y configuración de la base de datos con la que contaría el sistema, y finalmente se instalarían y se configurarían algunos sistemas complementarios que hacen parte del conjunto de herramientas que ofrece GForge, como lo es el Mailman.

Al haber instalado a GForge, se procedió finalmente a elaborar el manual de instalación y configuración de GForge AS 5.6.1, en donde se describe paso por paso, los procedimientos que se deben realizar para instalar y configurar esta herramienta, con lo que una vez finalizada esta tarea, se culminaba esta fase.

• 
  Fase 3: Elaboración de la Guía
  

Para comenzar esta fase, se decidió que se debían definir los trackers con sus correspondientes workflows que se utilizarían para la gestión de proyectos de software basados en metodologías ágiles, utilizando el ambiente de desarrollo colaborativo GForge.

Los trackers que se definieron con sus correspondientes workflows, son en total nueve (9), los cuales son alusivos a las fases de desarrollo que se tienen normalmente en un proyecto de software estándar, como son: planeación del desarrollo del proyecto, análisis de requerimientos, especificación de la arquitectura y diseño del sistema, implementación de los casos de uso, realización de los diferentes tipos de pruebas que se requieran (como por ejemplo las pruebas funcionales y las pruebas de integración), la instalación del sistema, la capacitación y el soporte.

Los trackers definidos en la guía metodológica de ConstruColectiva [Olaya Figueroa & Díaz Agudelo, 2009] serán explicados en la sección 3. Definición de trackers y sus workflows para la gestión de proyectos de software bajo metodologías ágiles en GForge. La lista de estos trackers es la siguiente:

• 
  Tracker 1: Análisis de requerimientos y casos de uso
  
• 
  Tracker 2: Planeación del desarrollo del proyecto
  
• 
  Tracker 3: Arquitectura y diseño
  
• 
  Tracker 4: Desarrollo
  
• 
  Tracker 5: Pruebas y proceso de integración
  
• 
  Tracker 6: Entrega al cliente y pruebas por parte del cliente
  
• 
  Tracker 7: Bugs
  
• 
  Tracker 8: Extensiones
  
• 
  Tracker 9: Puesta en operación
  

Roles en un proyecto: Para cada uno de los trackers, intervienen distintos tipos de roles propuestos por [Bogue, 2009], los cuales se explican a continuación:

• 
  Administrador (Admin)
  

El administrador es el encargado de aprobar los proyectos que creen los demás usuarios, también administra los permisos de los roles que se han creado, y tiene la potestad de eliminar y crear nuevos roles dentro del sistema. Se le considera como el líder de la configuración de los proyectos que se estén desarrollando en GForge.

• 
  Arquitecto (Architect)
  

El arquitecto es el encargado de definir la arquitectura del sistema que se pretende desarrollar [IEEE, 2000]. Por lo tanto, asegura la consistencia en las decisiones del diseño y en los estilos de la interfaz [Bruegge & Dutoit, 2004], de tal forma que participa en la definición de cada uno de los componentes del sistema, apoyando el desarrollo de los documentos del sistema como son: el modelo del dominio, los diagramas de casos de uso, de clases, de secuencia, de componentes y de despliegue.

• 
  Analista (Analyst)
  

El analista es el experto del dominio de la aplicación, quien modela el sistema actual y genera información acerca del sistema futuro. Cada analista inicia con la responsabilidad de detallar uno o más casos de uso, para que luego sobre un conjunto de estos, identifique un número de objetos, sus asociaciones y sus atributos. [Bruegge & Dutoit, 2004]

• 
  Diseñador (Object Designer)
  

Es el encargado en definir y especificar las interfaces de los objetos y casos de uso a desarrollar de acuerdo a las metas del diseño que debe cumplir la arquitectura establecida, cumpliendo los requerimientos establecidos y teniendo en cuenta la plataforma tecnológica que se vaya a emplear [Bruegge & Dutoit, 2004]. También define los documentos referentes a las técnicas de pruebas que se necesitan ejecutar para cada uno de los componentes que se hayan diseñado.

• 
  Desarrollador (Developer)
  

Los desarrolladores se encargan de la implementación de los requerimientos y casos de uso que se definan en un proyecto de software. Ellos transforman los datos definidos en los documentos de especificación de requerimientos y de casos de uso, a código fuente legible documentado, para dar como resultado los componentes de software implementados.

En relación al repositorio de versiones y siguiendo las recomendaciones que hace [VTT Technical Research Centre of Finland, 2004] para la Administración de la Configuración del software (SCM) en las metodologías ágiles; se recomienda utilizar herramientas de SCM que permitan utilizar ramas, en donde cada caso de uso debe trabajarse un una rama distinta del repositorio, con el fin de aislar su desarrollo del resto de proyectos. Además, los desarrolladores realizan las pruebas unitarias con las herramientas de software definidas por la organización.

Finalmente, los desarrolladores se encargan de eliminar los bugs, y reparar los defectos y deficiencias, que se hayan reportado durante la ejecución de las pruebas a los casos de uso [Bentley, 2005].

• 
  Probador (Tester)
  

Es el responsable en evaluar que cada caso de uso funcione de acuerdo con lo especificado por el diseñador, por medio de pruebas funcionales [Bruegge & Dutoit, 2004].

Una vez que los casos de uso funcionen de forma independiente, el probador ejecutará las pruebas de integración a un conjunto determinado, para corroborar que el funcionamiento de un caso de uso no altere el de los demás, de tal manera que al finalizar, entregará los reportes de los resultados obtenidos al ejecutar todas las pruebas necesarias.

Cada caso de uso es probado en su correspondiente rama dentro del repositorio de versiones. En caso de ser exitoso, se notificará al integrador para que actualice el tronco del repositorio de versiones del proyecto, integrando los casos de uso que ya se hayan probado; en caso contrario, le notificará a los desarrolladores los resultados de las pruebas, advirtiendo los defectos encontrados para que sean solucionados.

• 
  Integrador (Integrator)
  

El integrador es el encargado de actualizar el tronco del repositorio de versiones que usa el proyecto de software en desarrollo, con el conjunto de casos de uso previamente tratados por el probador, quién además de ejecutar las pruebas funcionales, también ejecutó las pruebas de integración, de tal forma que el integrador al actualizar el repositorio de versiones, registre los resultados obtenidos [Humphrey, 2000] [Jacobson, Booch, & Rumbaugh, 1999]. Adicionalmente, debe notificar a todos los desarrolladores del proyecto para que actualicen sus ramas respecto al tronco del repositorio de versiones.

• 
  Gerente del proyecto (Project Manager)
  

Es el encargado de definir el cronograma, los planes de gestión del proyecto de software, supervisar las tareas realizadas por todos los miembros del proyecto e interactuar con ellos con el fin de avanzar y evaluar el progreso en el desarrollo del proyecto. Por otra parte, también es el encargado de definir las entregas del proyecto con el cliente, en los contratos que se estipulen, y delega las funciones principales a cada uno de los equipos establecidos para que coordinen y cumplan con los objetivos del proyecto. [Bruegge & Dutoit, 2004]

• 
  Capacitador (Trainer)
  

Es el encargado de planear y realizar las capacitaciones del uso de los productos resultantes, del proyecto de software que se haya desarrollado, en el ambiente de destino del cliente. Por lo tanto, define el plan de capacitación, desarrolla los materiales de entrenamiento, valida el programa de entrenamiento y finalmente lo ejecuta. [Bruegge & Dutoit, 2004]

• 
  Cliente (Customer)
  

Su función es la de retroalimentar el desarrollo del proyecto de software por medio de la formulación de los escenarios y los requerimientos del sistema [Bruegge & Dutoit, 2004]. Además, es el encargado de realizar las pruebas parciales y finales a los productos desarrollados, por medio de las pruebas funcionales y de aceptación. También acuerda desde el principio con el gerente del proyecto los términos y las condiciones del desarrollo del proyecto de software por medio de los contratos que se necesiten.

• 
  Soporte (Tech support)
  

Es el encargado en realizar la instalación y configuración del sistema desarrollado en el ambiente de destino. Además, de brindar el correspondiente soporte técnico que sea requerido por parte del cliente.

La relación que se fijó en GForge para los roles y los trackers anteriormente definidos de acuerdo a la guía metodológica de ConstruColectiva, se ilustra en la siguiente tabla, la cual se obtuvo a partir de los Core Workflows que define [Jacobson, Booch, & Rumbaugh, 1999].

	Proceso 1	Proceso 2	Proceso 3	Proceso 4	Proceso 5	Proceso 6	Proceso 7	Proceso 8	Proceso 9
Gerente	X	X	X			X	X		X
Arquitecto	X		X
Analista	X
Diseñador			X	X
Desarrollador				X			X
Probador				X	X
Integrador					X
Capacitador									X
Soporte									X
Cliente	X	X	X			X	X	X	X

Tabla 5 - Relación de los procesos con los roles definidos en la guía metodológica

De acuerdo a las metodologías ágiles, el ciclo de vida que utiliza el desarrollo de proyectos de software mediante estas metodologías está basado en iteraciones, las cuales tienen como objetivo desarrollar de forma incremental el sistema final.

Los riesgos asociados al cambio en los requerimientos del sistema durante su desarrollo ocurren frecuentemente, pero gracias a las iteraciones que nos brinda las metodologías ágiles, esta incertidumbre se puede reducir drásticamente al estar refinando y expandiendo los requerimientos constantemente dentro de cada iteración [Larman, 2004], como se puede observar en la Ilustración 10.

Ilustración 10 - Requerimientos evolutivos e iterativos⁹

Además, para las primeras iteraciones se tienen en cuenta los requerimientos más importantes de la arquitectura del sistema o los que más valor tienen para el negocio, facilitando de esta manera la gestión de riesgos que necesita un proyecto de software [Larman, 2004].

Con respecto a la planeación del proyecto, se tiene que las estimaciones y los cronogramas no pueden ser delimitados con exactitud, y por lo tanto en un proyecto de software siempre hay una fase inicial de alta incertidumbre, el cual es denominado como “Cono de incertidumbre”, ver la Ilustración 11. Por lo tanto, es frecuente observar que las metodologías ágiles utilizan una fase inicial de exploración, en donde se busca una planeación adaptativa en vez de una planeación predictiva [Larman, 2004].

Ilustración 11 - Cono de incertidumbre¹⁰

De acuerdo al desarrollo iterativo e incremental (por sus siglas en inglés, IID), como el Agile Rational Unified Process [Lines, Barnes, Holmes, & Ambler, 2008], se recomienda ejecutar los proyectos de software en dos fases con sus correspondientes contratos (dos contratos en total).

En la primera fase se busca realizar un análisis de requerimientos global (levantamiento de requerimientos y definición de los casos de uso). Mientras que la segunda fase inicia a partir de los resultados obtenidos en la primera fase, en donde el cliente y el gerente del proyecto definen un nuevo contrato, incluyendo tiempos y recursos requeridos para realizar los procesos de implementación, pruebas y entrega del proyecto [Larman, 2004].

Los requerimientos obtenidos en la primera fase proveen mayor información de calidad para los estimadores de la segunda fase y los avances de software que necesita el proyecto [Larman, 2004], tal como se muestra en la Ilustración 12.

Ilustración 12 - Los contratos del proyecto¹¹

Una vez se tenían definidos los roles que se necesitarían para brindar el apoyo a la gestión de proyectos de software basados en metodologías ágiles por medio del ambiente de desarrollo colaborativo GForge, y sus correspondientes asociaciones a los trackers anteriormente mencionados, se procedió a diseñar la iteración principal que sería parte del proceso que utilizan las metodologías ágiles. Dicha iteración, se utilizaría para realizar la fase de producción que describe [Lines, Barnes, Holmes, & Ambler, 2008], en donde se desea implementar los casos de uso que se hayan definido en el proyecto, de tal manera que durante su desarrollo se obtenga la mayor retroalimentación posible del cliente por medio de distintas entregas parciales incrementales.

Para la guía metodológica de ConstruColectiva, la primera fase del proyecto iniciará a partir de un contrato previo con el cliente, el cual establece como resultado la realización de los procesos: Análisis de requerimientos y casos de uso y el de Planeación del desarrollo del proyecto; esta fase es denominada dentro de este documento como Fase de Ingeniería, tomando como referencia de este concepto el que se propone en [Lines, Barnes, Holmes, & Ambler, 2008].

La segunda fase se inicia cuando el cliente aprueba por medio de un contrato los resultados obtenidos en la primera fase, en donde quedan definidos formalmente los costos del proyecto, los tiempos de ejecución de las iteraciones y sus correspondientes entregas. Por consiguiente, en esta fase se ejecutan los siguientes procesos: Arquitectura y diseño, Desarrollo, Pruebas y proceso de integración, Entregas al cliente y pruebas por parte del cliente, Bugs, Extensiones y Puesta en operación; esta fase es denominada dentro de este documento como Fase de Producción, tomando como referencia de este concepto el que se propone en [Lines, Barnes, Holmes, & Ambler, 2008].

Conforme al modelo de gestión que define la guía metodológica de ConstruColectiva para los proyectos de software basados en metodologías ágiles, cada iteración de “Elaboración y entrega” consistirá en un conjunto de casos de uso desarrollados, probados, integrados y entregados al cliente (ver la Ilustración 13). En consecuencia los siguientes procesos participarán en las iteraciones: Desarrollo, Pruebas y proceso de integración, Entregas al cliente y pruebas por parte del cliente y Bugs.

Al repetir la ejecución de la iteración Elaboración y entrega hasta que se implementen todos los conjuntos de casos de uso, se tendrá el sistema final desarrollado y funcionando en el ambiente de destino.

Continuando con la definición de la segunda fase, una vez se tenga el sistema final implementado y funcionando en el ambiente de destino, se dará inicio al proceso Puesta en operación. Sin embargo, cuando el cliente lo solicite, se podrán acordar el desarrollo de nuevas funcionalidades del sistema, los cuales serán gestionados por medio del proceso Extensiones.

Ilustración 13 - Iteraciones de la metodología propuesta

• 
  Fase 4: Pruebas de la guía
  

De a cuerdo a la propuesta elaborada para el trabajo de grado de ConstruColectiva, la guía metodológica se iba a probar por medio de expertos de una casa de software reconocida en Colombia, para la cual se escogió a la empresa de desarrollo de software Heinsohn Business Technology S.A. [Heinsohn Business Technology S.A., 2008].

Heinsohn Business Technology S.A. es una de las desarrolladoras de software más importantes de Colombia, la cual ha participado en grandes proyectos de software a nivel nacional, por lo menos así lo confirma el ranking generado por el diario La República [DIARIO LA REPUBLICA, 2010] en el articulo [Diario La República], en donde Heinsohn obtuvo el lugar número 16 dentro del ranking generado a 5.000 empresas que trabajan por Colombia, demostrando su liderazgo dentro de la industria y el mercado colombiano. Además, según [ChannelPlanet, Inc., 2010], Heinsohn se convirtió en la segunda empresa colombiana en recibir la certificación de nivel 4 del CMMI [Software Engineering Institute, 2010], destacando principalmente su trabajo en equipo que ha adquirido durante los últimos años.

Por medio de Heinsohn, se logró contactar al Ing. Diego Marín quien es uno de sus representantes del equipo de calidad, para que evaluara la guía metodológica de ConstruColectiva, a quién se le realizó la encuesta que se detalla en el Anexo 3. Los resultados de dicha encuesta se examinan en la sección IV.1. Resultados, donde se presenta un completo análisis de la retroalimentación brindada por el Ing, Diego Marín acerca de la guía metodológica, y de la cual se logró corregir aquellos aspectos negativos detectados en la encuesta, con el fin de optimizar la guía metodológica, la cual es el producto principal de ConstruColectiva.

• 
  Fase 5: Elaboración de la memoria
  

De acuerdo a lo planteado en la propuesta del trabajo de grado de ConstruColectiva, la memoria se iba a realizar de forma secuencial al terminar la fase de la implementación de la Guía metodológica. Sin embargo, a pesar del esfuerzo y tiempo invertido en dicha fase, las correcciones a realizar en la guía aumentaban al igual que en los documentos que la soportaban. Por tal motivo, se decidió empezar la elaboración de la memoria, a pesar de no haber finalizado completamente la guía metodológica, sin importar lo poco que faltaba para lograrlo.

En la memoria se incluyeron temas tratados en los documentos de la guía metodológica y la propuesta del trabajo de grado de ConstruColectiva como son la descripción de las metodologías ágiles, la comparación de los ambientes de desarrollo colaborativo, y se analizó la información recolectada al realizar las pruebas de la guía metodológica. A partir de estos temas, realizaron nuevas investigaciones acerca del estado en la adopción de las metodologías ágiles por parte de las empresas que desarrollan software, y de los factores críticos en la gestión de proyectos de software.

• 
  Fase 6: Elaboración de la página web
  

La página web se realizó de forma paralela al comenzar con la elaboración de la memoria, todo esto con el fin de ahorrar tiempo, el cual es el recurso más importante al final del trabajo de grado. Sin embargo, su realización fue todo un éxito, ya que su duración fue mucho menos de lo planeada, lo cual nos permitió continuar la culminación de la memoria y de los demás documentos pendientes del trabajo de grado de ConstruColectiva para entonces.

• 
  Fase 7: Control de calidad
  

A pesar de sólo haber realizado una sesión de pruebas con la presencia de Heinsohn, se contó con la ayuda incondicional de la Ing, Maria Consuelo Franky directora del trabajo de grado de ConstruColectiva, quién estuvo revisando de forma constante la elaboración de la guía metodológica y de los demás documentos que la soportan, por medio de entregas parciales. De tal manera, que se obtenía su correspondiente retroalimentación en las reuniones realizadas en la Pontificia Universidad Javeriana, a partir de la cual se podía corregir los productos y documentos del trabajo de grado.

Adicionalmente, también se contó con la ayuda del Ing. Miguel Eduardo Torres, asesor del trabajo de grado de ConstruColectiva, con respecto a la guía metodológica, quién aportó diversas sugerencias y observaciones acerca de la implementación de la guía que se le presentó en un momento determinado.