Propuesta para Trabajo de Grado

III.3. Definición de trackers y sus workflows para la gestión de un proyecto de software bajo metodologías ágiles en GForge

Durante el desarrollo de la guía metodológica de ConstruColectiva, se les definieron a las etapas relacionadas con el desarrollo de proyectos de software, sus correspondientes trackers y workflows, los cuales están orientados a los principios propuestos por las metodologías ágiles, y fueron configurados en el ambiente de desarrollo colaborativo GForge.

La configuración de los workflows, los trackers y los ítems que se definieron en la guía metodológica ConstruColectiva han sido compartidos en la página Web del trabajo de grado [Olaya Figueroa & Díaz Agudelo, 2009], al que hace referencia esta memoria, por medio de una copia de respaldo (backup) denominada TiggerRummy, la cual se puede restaurar en GForge, de tal manera que se obtiene una copia exacta de las configuraciones de los roles, trackers e ítems que se pueden utilizar en nuevos proyectos definidos en GForge. Esta copia de respaldo corresponde al proyecto de demostración que se menciona en la guía metodológica de ConstruColectiva.

Esto permite flexibilidad a las organizaciones que utilicen el modelo de procesos de ConstruColectiva, ya que a partir de la restauración de la copia de seguridad se puede obtener un clon de un proceso con su respectivo workflow desde TiggerRummy, el cual es un proyecto realizado en la Pontificia Universidad Javeriana durante el segundo semestre del año 2008 en la asigantura de Ingeniería de Software [ALBINE, 2008], y de esta manera se busca adaptar el clon en cualquier otro proyecto de GForge con las respectivos cambios necesarios de los workflows e ítems.

A continuación, se detallan las funciones de cada uno de los trackers propuestos junto con el diseño de sus correspondientes workflows.

III.3.1. Tracker 1: Análisis de requerimientos y casos de uso

El primer tracker se denominó: Análisis de requerimientos y casos de uso, el cual resume las actividades en GForge de un proyecto de software basado en metodologías ágiles, en lo referente a la fase de análisis, en donde se busca registrar y brindar la trazabilidad a cada uno de los requerimientos y casos de uso del proyecto. Durante esta fase, se recomienda elaborar el contrato pertinente a la fase de levantamiento de requerimientos y casos de uso que necesite el proyecto de software que se pretende desarrollar, tal como lo recomiendan el uso de las metodologías ágiles [Larman, 2004], de tal forma, que en el caso de que la organización continúe con la implementación de los requerimientos y de los casos de uso especificados, en el siguiente proceso se elabore un segundo contrato que estipule los costos de implementación y gestión del proyecto durante las siguientes fases de su desarrollo.

Además, en el tracker de Análisis de requerimientos y casos de uso, cada ítem corresponde a la tarea de elaborar un documento que hace parte del proceso de levantamiento y definición tanto de los requerimientos, como de los casos de uso que tendrá el proyecto. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseño para este tracker:

Ilustración 14 - Workflow del tracker: Análisis de requerimientos y casos de uso

A continuación se definen los estados estipulados para el tracker: Análisis de requerimientos y casos de uso.

NOMBRE DEL ESTADO	DEFINICIÓN
Abierto	Este estado indica que el ítem hasta el momento ha sido creado, con sus correspondientes roles asignados, como también sus encargados y responsables.
Elaboración	Indica que el ítem se encuentra en proceso de desarrollo.
Evaluación interna	Indica que el ítem está siendo evaluado por el equipo de trabajo y los encargados de realizar sus pruebas dentro de la organización.
Evaluación externa	Indica que se están evaluando todas las funcionalidades del ítem por parte de un cliente u otro agente externo a la organización.
Aprobado	Indica que el ítem ha sido aprobado por sus evaluadores, y si es el caso, pasará al siguiente tracker o se publicará en las versiones liberadas del proyecto en GForge, denominada Ficheros (Files). Este estado cierra el ítem.

Tabla 6 - Estados del workflow del tracker: Análisis de requerimientos y casos de uso

III.3.2. Tracker 2: Planeación del desarrollo del proyecto

El segundo tracker se denominó: Planeación del desarrollo del proyecto, en la cual se buscan definir los planes y presupuestos que se deben tener en cuenta desde las actividades relacionadas con la definición de la arquitectura con la que contará el sistema, hasta las de instalación y capacitación del proyecto en el ambiente de destino, satisfaciendo los requerimientos y atributos de calidad que fueron definidos para el proyecto desde la fase anterior.

En el tracker de Planeación del desarrollo del proyecto, cada ítem corresponde a la tarea de elaborar un documento que brinde el soporte a la planeación de la Fase de Producción del proyecto, en los cuales se definen los planes de gestión y los presupuestos que se deben tener en cuenta para cada una de las actividades definidas en lo que resta del desarrollo del proyecto. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseño para este tracker.

Ilustración 15 - Workflow del tracker: Planeación del desarrollo del proyecto

A continuación se definen los estados estipulados para el tracker: Planeación del desarrollo del proyecto.

NOMBRE DEL ESTADO	DEFINICIÓN
Abierto	Este estado indica que el ítem hasta el momento ha sido creado, con sus correspondientes roles asignados, como también sus encargados y responsables.
Elaboración	Indica que el ítem se encuentra en proceso de desarrollo.
Evaluación	Indica que el ítem está siendo evaluado por el equipo de trabajo y los encargados de realizar sus pruebas dentro de la organización.
Aprobado	Indica que el ítem ha sido aprobado por sus evaluadores, y si es el caso, pasará al siguiente tracker o se publicará en las versiones liberadas del proyecto en GForge, denominada Ficheros (Files). Este estado cierra el ítem.

Tabla 7 - Estados del workflow del tracker: Planeación del desarrollo del proyecto

III.3.3. Tracker 3: Arquitectura y diseño

El tercer tracker se denominó: Arquitectura y diseño, en el cual se pretende brindar el apoyo en GForge a un proyecto de software basado en metodologías ágiles, para el cual se le debe definir su arquitectura y la especificación del diseño para cada uno de sus componentes.

En el tracker de Arquitectura y diseño, cada ítem corresponde a la tarea de elaborar un documento que hace parte del proceso de la definición y especificación de la arquitectura y del diseño con el que contará cada componente de software que incluirá el proyecto. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseño para este tracker.

Ilustración 16 - Workflow del tracker: Arqitectura y diseño

A continuación se definen los estados estipulados para el tracker: Arquitectura y diseño.

NOMBRE DEL ESTADO	DEFINICIÓN
Abierto	Este estado indica que el ítem hasta el momento ha sido creado, con sus correspondientes roles asignados, como también sus encargados y responsables.
Elaboración	Indica que el ítem se encuentra en proceso de desarrollo.
Evaluación interna	Indica que el ítem está siendo evaluado por el equipo de trabajo y los encargados de realizar sus pruebas dentro de la organización.
Evaluación externa	Indica que se están evaluando todas las funcionalidades del ítem por parte de un cliente u otro agente externo a la organización.
Aprobado	Indica que el ítem ha sido aprobado por sus evaluadores, y si es el caso, pasará al siguiente tracker o se publicará en las versiones liberadas del proyecto en GForge, denominada Ficheros (Files). Este estado cierra el ítem.

Tabla 8 - Estados del workflow del tracker: Arquitectura y diseño

III.3.4. Tracker 4: Desarrollo

El cuarto tracker se denominó: Desarrollo, en el cual se pretende configurar en GForge la documentación y el código fuente de todos los casos de uso definidos en un proyecto de software basado en metodologías ágiles, teniendo en cuenta que para cada caso de uso se debe trabajar en una rama independiente dentro del repositorio de versiones para su correspondiente administración por parte de los desarrolladores que tenga el proyecto.

En el tracker de Desarrollo, cada ítem corresponde a cada caso de uso del sistema que se está desarrollando, de tal manera que se pueda implementar de manera independiente, sin dejar de lado la especificación de su diseño y de las pruebas que debe satisfacer. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseño para este tracker.

Ilustración 17 - Workflow del tracker: Desarrollo

A continuación se definen los estados estipulados para el tracker: Desarrollo.

NOMBRE DEL ESTADO	DEFINICIÓN
Abierto	Este estado indica que el ítem hasta el momento ha sido creado, con sus correspondientes roles asignados, como también sus encargados y responsables.
Diseño	Indica que el caso de uso se está diseñando de acuerdo a los requerimientos establecidos.
Implementación y pruebas unitarias	Indica que el caso de uso se encuentra en proceso de desarrollo y una vez se termine, se ejecutarán las pruebas unitarias, las cuales se ejecutan con una herramienta de software como JUnit [MichaelMinella.com, 2008].
Pruebas funcionales	Este estado indica que al caso de uso se le están realizando las pruebas funcionales que determinarán si cumple con todos los requerimientos funcionales para los que fue diseñado.
Tracker: Pruebas y proceso de integración	Una vez se termine el desarrollo y se efectúen las pruebas funcionales sobre cada caso de uso, se deberá invocar el tracker de pruebas y proceso de integración, el cual realizará el proceso de integración al repositorio de versiones del proyecto con sus correspondientes pruebas

Tabla 9 - Estados del workflow del tracker: Desarrollo

III.3.5. Tracker 5: Pruebas y proceso de integración

El quinto tracker se denominó: Pruebas y proceso de integración, en donde se pretende lograr identificar y brindar el seguimiento por medio de GForge a los defectos que se generen en los componentes de software implementados, una vez estos sean probados por medio de pruebas de integración, las cuales se ejecutan a medida que se van integrando los casos de uso desarrollados al tronco del repositorio de versiones que utiliza el proyecto, para garantizar su correcto funcionamiento con los demás componentes del sistema.

En el tracker de Pruebas y proceso de integración, cada ítem corresponde a un conjunto de casos de uso del sistema para que se integren de forma exitosa al repositorio de versiones del proyecto, realizando sus correspondientes pruebas de integración. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseño para este tracker.

Ilustración 18 - Workflow del tracker: Pruebas y proceso de integración

A continuación se definen los estados estipulados para el tracker: Pruebas y proceso de integración.

NOMBRE DEL ESTADO	DEFINICIÓN
Abierto	Este estado indica que el ítem hasta el momento ha sido creado, con sus correspondientes roles asignados, como también sus encargados y responsables.
Integración	Indica que el caso de uso se está integrando al repositorio de versiones del proyecto proporcionado por GForge.
Pruebas de integración	Una vez el proceso de integración termine, se realizan pruebas de integración, las cuales pretenden evidenciar problemas en las interfaces que tiene el caso de uso recién integrado con los que ya han sido integrados con anterioridad.
Tracker: Desarrollo	En caso de presentarse alguna falla en las pruebas de integración, el caso de uso se rediseñará y se re-implementará para corregir tales defectos. Para esto, se debe clonar el ítem dentro del tracker de desarrollo para realizar su correspondiente corrección.
Aprobado	Indica que el ítem ha sido aprobado por sus evaluadores, y si es el caso, pasará al siguiente tracker o se publicará en las versiones liberadas del proyecto en GForge, denominada Ficheros (Files). Este estado cierra el ítem.

Tabla 10 - Estados del workflow del tracker: Pruebas y proceso de integración

III.3.6. Tracker 6: Entrega al cliente y pruebas por parte del cliente

El sexto tracker se denominó: Entrega al cliente y pruebas por parte del cliente, el cual tiene como objetivo rastrear las actividades relacionadas con las entregas parciales del proyecto de software que se está desarrollando, por medio de la entrega de un conjunto de casos de uso implementados, de tal forma que el cliente ejecute sus pruebas personalizadas sobre cada uno, y determine si se cumplen con todos los requerimientos asociados a cada caso de uso probado.

En el tracker Entrega al cliente y pruebas por parte del cliente, cada ítem corresponde a un conjunto de casos de uso del sistema, los cuales serán probados en el ambiente de destino mediante pruebas personalizadas diseñadas por el cliente, y quién a su vez, reportará los defectos que se detecten durante las sesiones de pruebas. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseño para este tracker.

Ilustración 19 - Workflow del tracker: Entrega al cliente y pruebas por parte del cliente

A continuación se definen los estados estipulados para el tracker: Entrega al cliente y pruebas por parte del cliente.

NOMBRE DEL ESTADO	DEFINICIÓN
Abierto	Este estado indica que el ítem hasta el momento ha sido creado, con sus correspondientes roles asignados, como también sus encargados y responsables.
Pruebas personalizadas	Este estado indica que al conjunto de casos de uso se les están realizando diferentes tipos de pruebas que determinarán si cumplen con todos los requerimientos para los que fueron diseñados y las características de los casos de uso asociados.
Tracker: Desarrollo	Si se detectan defectos durante la ejecución de las pruebas personalizadas al conjunto de casos de uso, se deben clonar los casos de uso defectuosos dentro del tracker de desarrollo para realizar sus correspondientes correcciones.
Aprobado	Indica que el ítem ha sido aprobado por sus evaluadores, y si es el caso, pasará al siguiente tracker o se publicará en las versiones liberadas del proyecto en GForge, denominada Ficheros (Files). Este estado cierra el ítem.

Tabla 11 - Estados del workflow del tracker: Entrega al cliente y pruebas por parte del cliente

III.3.7. Tracker 7: Bugs

El séptimo tracker se denominó: Bugs, pretende solucionar los diferentes tipos de bugs que hayan sido reportados por el cliente una vez el sistema esté operando, o al ser evaluadas sus entregas parciales durante las sesiones de pruebas reportadas en el sexto tracker: Entrega al cliente y pruebas por parte de cliente, con el fin de realizar sus correspondientes correcciones junto con los procesos de pruebas establecidos.

En el tracker de Bugs, cada ítem corresponde a un bug reportado, ya sea por parte del cliente o de los desarrolladores del proyecto, de tal manera que se les puedan brindar su oportuna solución. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseño para este tracker.

Ilustración 20 - Workflow del tracker: Bugs

A continuación se definen los estados estipulados para el tracker: Bugs.

NOMBRE DEL ESTADO	DEFINICIÓN
Abierto	Este estado indica que el ítem hasta el momento ha sido creado, con sus correspondientes roles asignados, como también sus encargados y responsables.
Especificación	Indica que al bug se le está determinando la severidad que implica en el funcionamiento correcto del sistema, al igual que la elaboración de toda su documentación que le permita dar su correspondiente seguimiento, con el objetivo de lograr su pronta solución.
Tracker: Desarrollo	Una vez la definición del bug haya concluido, se deben clonar los casos de uso defectuosos implicados en el bug, dentro del tracker de desarrollo para realizar sus correspondientes correcciones

Tabla 12 - Estados del workflow del tracker: Bugs

III.3.8. Tracker 8: Extensiones

El octavo tracker fue denominado: Extensiones, el cual pretende pretende crear el workflow para la generación de funcionalidades extras propuestas por el cliente para el mejoramiento del proyecto, después de haberse cumplido con la finalización de lo pactado desde un principio como el alcance del proyecto.

En el tracker de Extensiones, cada ítem corresponde a la descripción de una extensión solicitada por parte del cliente, para llevar a cabo su correspondiente seguimiento desde que se planea hasta que se entrega. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseño para este tracker.

Ilustración 21 - Workflow del tracker: Extensiones

La definición de cada uno de los estados del workflow del tracker Extensiones, se encuentran en las descripciones de sus correspondientes procesos que se han explicado en las descripciones de los trackers anteriores.

III.3.9. Tracker 9: Puesta en operación

Finalmente se tiene el noveno tracker denominado: Puesta en operación, en el cual se busca definir las actividades que se llevarán a cabo para dar el cierre del proyecto de software que se está desarrollando, en las cuales se podrían incluir: la entrega final del producto de software y las pruebas de aceptación e instalación. Con esto, se busca cerrar el proceso de desarrollo del proyecto, validando cada requerimiento y cada caso de uso acordado contra el entregado, de tal forma que realicen los registros necesarios de las entregas satisfactorias. Por otra parte, también dentro de este proceso se debe especificar los mecanismos de soporte y capacitación que se les dará a los productos de software desarrollados, una vez estos salgan de su ambiente de desarrollo.

En el tracker de Puesta en operación, cada ítem corresponde a la tarea de elaborar un documento que hace parte del proceso de instalación, capacitación y soporte de la aplicación que se ha desarrollado en el proyecto. A continuación se presenta la imagen correspondiente al modelo del workflow que se diseñó para este tracker.

Ilustración 22 - Workflow del tracker: Puesta en operación

A continuación se definen los estados estipulados para el tracker: Puesta en operación.

NOMBRE DEL ESTADO	DEFINICIÓN
Abierto	Este estado indica que el ítem hasta el momento ha sido creado, con sus correspondientes roles asignados, como también sus encargados y responsables.
Instalación	Indica que el producto de software se está instalando en el ambiente de destino.
Pruebas de aceptación e instalación	Indica que al producto de software se le están realizando las pruebas de aceptación e instalación en el ambiente de destino.
Capacitación	Indica que el producto de software ha sido aprobado por sus evaluadores, por lo que se iniciarán las jornadas de capacitación a los usuarios finales. Dicho estado cierra el ítem.

Tabla 13 - Estados del workflow del tracker: Puesta en operación