Propuesta para Trabajo de Grado

II.2. Marco Conceptual

En los ambientes de desarrollo colaborativo (CDE), como GForge, se tienen a disposición diferentes tipos de herramientas para todo el equipo de trabajo que tiene un proyecto de software determinado, entre las cuales se destacan las siguientes: Trackers, Workflows, Ítems, Foros, Wikis, Reportes de gestión, manejadores de documentos y repositorios de versiones, sin omitir las notificaciones que reciben los usuarios vía correo electrónico, cuando se presentan nuevos acontecimientos que son relevantes para sus correspondientes usuarios de la herramienta [Booch & Brown, 2002].

Sin embargo, además de las herramientas que nos brindan los CDEs, también es importante conocer las metodologías de trabajo que se promueven dentro de las organizaciones, con el fin de manejar adecuadamente todas herramientas que nos brindan los CDEs de forma controlada y supervisada, lo cual se convierte a la vez, en los mecanismos que se utilizan para recolectar métricas de trabajo sobre el proyecto por sus encargados.

A continuación, se definen algunas herramientas, conceptos características que son importantes a la hora de utilizar cualquier ambiente de desarrollo colaborativo.

II.2.1. Equipos virtuales

Se utiliza el término equipo para referirse a una colección de más de cuatro personas que trabajan en colaboración en una tarea común o meta. El objetivo es a menudo conseguir una solución para algún problema. Los elementos de las tareas y objetivos comunes junto con dependencia mutua son parte integrante de la definición de un equipo, al menos en respecto a una necesidad impuesta para llegar a una posición colectiva sobre un asunto.

Además cuando los integrantes del equipo están geográficamente dispersos se distinguen por el factor de la virtualidad debido a que los colaboradores trabajan en un proyecto común a través de la comunicación y las tecnologías de información es llamado un equipo virtual.

Los equipos virtuales se caracterizan por llevar a cabo la totalidad o la mayor parte de sus interacciones a través de medios electrónicos y los miembros del equipo pueden estar ampliamente dispersos geográficamente en diferentes países o en diferentes continentes. Ellos pueden ser miembros de diferentes organizaciones, se reunieron debido a su experiencia o intereses, para encontrar una solución común a un problema [Godar & Ferris, 2004].

II.2.2. Workflow

Se puede definir a un workflow, como el modelo de la gestión de todas las actividades que se van a llevar a cabo dentro de un proceso de negocio, teniendo en cuenta sus distintos protagonistas involucrados [García, 2007].

Este modelo también se aplica a un proyecto de software y establece una secuencia de actividades, la cual en algunos casos puede ser iterativa, en donde se pretende definir los diferentes estados por los que podrán atravesar sus procesos involucrados.

Por otra parte, de acuerdo a [Bruegge & Dutoit, 2004], un workflow se define en el Unified Software Development Process (UP) como una secuencia de actividades que producen artefactos de software.

II.2.3. Tracker

Un tracker se considera como una herramienta de software que permite registrar y rastrear las actividades que se han definido dentro de un workflow, como son sus eventos generados y el estado de dichas actividades con sus correspondientes componentes [Notable Solutions Inc.].

Para la gestión de proyectos de software, GForge propone dos tipos de trackers: “Issue Trackers” y “Task Trackers” [GForge 3.0], los cuales se emplean para dar seguimiento a las diferentes actividades que se requieran en el desarrollo de un proyecto de software, contribuyendo en el control y gestión de las diferentes etapas de desarrollo que este necesite.

Los “Issue Trackers”, hacen referencia a un tipo de tracker que se utiliza para controlar los problemas como bugs y los diferentes tipos de defectos que puede sufrir un componente de software cuando se desarrolla y se entrega al cliente. Mientras que, el tipo de tracker, “Task Trackers”, se emplea para la asignación de recursos, la definición y el control de las actividades que requieren los componentes de software, desde que se planean hasta que se entregan dentro de un proyecto de software.

GForge es flexible en cuanto a la definición de trackers, ya que el administrador del proyecto de software puede definir sus propios trackers personalizados que se acoplen al modelo del workflow que utiliza la organización para el desarrollo de un proyecto de software, en donde se debe indicar el tipo de tracker que se desea crear, el cual puede ser un “Issue Tracker” o un “Task Tracker”.

II.2.4. Ítem

Una vez creado un tracker, se pueden ir definiendo los ítems que se van a utilizar durante todo su ciclo de vida, o de acuerdo al tiempo que se necesite.

Un ítem se puede definir como una tarea, un caso de uso, un riesgo o un bug, entre otros elementos que se utilizan dentro de la gestión de un proyecto de software [Semeniuk, 2005]. En GForge se les puede considerar como los elementos que son controlados por los trackers.

II.2.5. Sistema de control de versiones

Un sistema de control de versiones hace referencia a una herramienta de software que permite la administración de archivos de un proyecto, los cuales se publican en un almacén de datos de forma efectiva y eficaz a través del tiempo [Collins-Sussman, Fitzpatrick, & Pilato, 2008].

Estas herramientas utilizan un componente denominado repositorio (Repository), el cual es el almacén de datos central, desde el cual los clientes se conectan para obtener las versiones más actualizadas de los archivos publicados, publicar archivos nuevos, y actualizar el contenido de los archivos existentes, de acuerdo a sus necesidades [Collins-Sussman, Fitzpatrick, & Pilato, 2008].

El sistema de control de versiones registra los cambios realizados a los archivos que se mantienen dentro del repositorio, de tal manera que los clientes puedan obtener y revisar las versiones anteriores de un archivo específico, y si lo desean, también pueden restaurar los archivos eliminados del repositorio. Además, esta herramienta también permite observar las estadísticas de trabajo por parte de cada uno de los participantes en el desarrollo de los archivos que se encuentran dentro del repositorio.

Uno de los sistemas de control de versiones más utilizado es SVN (Subversion) [Subversion Project, 2001], el cual clasifica los archivos del repositorio en tres componentes principales: los archivos que forman parte del tronco (Trunk), las ramas (Branches) y las etiquetas (Tags).

Generalmente, en el desarrollo de un proyecto de software basado en metodologías ágiles, el tronco del repositorio de un sistema de control de versiones, se utiliza para mantener los archivos fuente que forman parte del sistema desarrollado. Es decir, todos aquellos archivos del código fuente, que al ser ejecutados, funcionan a pesar de que el sistema continúe en desarrollo, por lo tanto; el tronco del repositorio siempre mantendrá la parte estable desarrollada del proyecto.

Las ramas se utilizan para aislar el desarrollo de cada uno de los casos de uso que necesita el proyecto, de tal manera que se puedan desarrollar en paralelo, optimizando el desarrollo del proyecto. Cada rama mantiene el historial de cambios realizados a los archivos de forma independiente; una vez finalice el desarrollo de un caso de uso dentro de una rama, el contenido de ésta se debe fusionar con el tronco del repositorio, de tal manera que se mantenga la integridad del sistema desarrollado. Claro está, que antes de fusionar el caso de uso al tronco del repositorio, el caso de uso debe aprobar las pruebas que se determinen para el proyecto.

Finalmente, las etiquetas se utilizan para mantener (marcar) copias del tronco del repositorio en un instante dado, y en donde también se publican en algunos casos, las entregas (releases) al cliente [Centraldev, 2009]. Sin embargo, los archivos que formen parte de las etiquetas del repositorio, no pueden ser modificados, ya que su función es la de mantener la consistencia de los datos para el momento en que se necesiten.

II.2.6. Administración de la configuración del software (SCM)

De acuerdo a [Bruegge & Dutoit, 2004], la administración de la configuración del software (Software Configuration Management, SCM) se define como el proceso que monitorea y controla los cambios en los productos de trabajo.

Sin embargo, [Berczuk & Appleton, 2002] enfatiza que el proceso de SCM sirve para dos propósitos distintos: el soporte a la gestión y el soporte al desarrollo, los cuales se requieren en un proyecto de software. Además, menciona lo siguiente:

“Un buen proceso de SCM permite a los desarrolladores trabajar en conjunto dentro de un proyecto de manera eficaz, tanto como individuos como miembros de un equipo. Si bien existen diversas herramientas que pueden hacer el proceso más simple, las herramientas por sí solas no son suficientes.”

Además, [Berczuk & Appleton, 2002] también recomienda que se deben tener en cuenta las interacciones que existen en los equipos de trabajo, para lo cual identifica las siguientes características que se deben cumplir en el proceso de SCM:

• 
  Permitir a los desarrolladores trabajar juntos en un proyecto de software, compartiendo el código fuente común.
  
• 
  Compartir el desarrollo de los módulos del proyecto. Esto permitirá que alguien corrija un error en el módulo de otra persona, si la otra persona no está disponible.
  
• 
  Permitir a los desarrolladores tener acceso a la versión estable (la que se ha probado) del proyecto, para que se pueda comprobar si un código adicional al repositorio funciona en conjunto, cuando alguien más intenta integrarlo dentro del repositorio del proyecto.
  
• 
  La capacidad de realizar backups a versiones estables del repositorio de versiones del proyecto. Para lo cual es importante permitir a un desarrollador probar su código contra la versión más consistente del proyecto, para que en caso de presentarse problemas se facilite su identificación y rastreo.
  
• 
  Permitir a un desarrollador utilizar checkpoints (marcas) a los cambios efectuados en un modulo y poder regresar a una versión anterior. Esto hace más seguro experimentar con cambios importantes dentro de un modulo que básicamente esté funcionando.
  

Finalmente, también hay que mencionar que para SCM también es importante tener en cuenta el control de versiones que se le realizará al código fuente, en donde [Berczuk & Appleton, 2002] asegura que el control de versiones es un aspecto importante al implementar software en equipo de manera eficiente, ya que ayuda a las personas trabajar sobre los mismos componentes en paralelo sin interferir con el trabajo de los demás. Las buenas prácticas tanto de SCM como de control de versiones, permiten hacer cosas como:

• 
  Desarrollar la próxima versión de una pieza de software mientras se solucionan los problemas de la versión actual.
  
• 
  Compartir el código con los miembros de otro equipo de una manera controlada, permitiendo desarrollar código en paralelo con otros y unirse con el estado actual de la línea base del repositorio.
  
• 
  Identificar que versiones de código están dentro de un componente en particular.
  
• 
  Analizar donde ocurrió un cambio en el historial de desarrollo de un componente.
  

II.2.7. Bug

Un bug se puede definir como un mal funcionamiento de un elemento de software, que hace que un programa funcione incorrectamente [Millán, 1998], el cual ha sido identificado en el ambiente de destino. Es decir, un bug aparece una vez un proyecto de software ha sido desarrollado y entregado al cliente.

II.2.8. GForge

GForge es un ambiente de desarrollo colaborativo con una interfaz intuitiva que integra un conjunto de herramientas asociadas al desarrollo de proyectos de software, desde la gestión del código fuente, hasta el manejo de trackers personalizados, gestores de tareas, gestores de documentos y listas de correo. Todas estas herramientas son controladas por un sistema centralizado con autorización que es mantenido por la plataforma web de GForge [GForge Group, 2007].

II.2.9. Mailman

Según [Free Software Foundation Inc.], Mailman es un software libre que se utiliza para la administración de las discusiones por correo electrónico y listas de noticias electrónicas. Además, este software está integrado con la web, de tal manera que resulta fácil para los usuarios manejar sus cuentas y para los propietarios de las listas, administrarlas de acuerdo a sus necesidades.

II.2.10. Stakeholders

De acuerdo a [Post, Preston, & Sachs, 2002], se definen a los stakeholders en una organización, a los individuos y grupos que contribuyen, ya sea de forma voluntaria o involuntaria, a la capacidad y a las actividades de la organización para generar capital.

Además, los stakeholders también se pueden ver como los beneficiarios potenciales, y como los portadores del riesgo en la organización. Por lo tanto, dentro de los stakeholders más importantes, se destacan los que se nombran en la Ilustración 9.

Ilustración 9 - Stakeholders de una organización