Propuesta para Trabajo de Grado

IV - RESULTADOS Y RECOMENDACIONES

IV.1. Resultados

Dentro de este trabajo de grado se elaboró una Guía metodológica ConstruColectiva para la gestión de proyectos de software basados en metodologías ágiles, utilizando a GForge como ambiente de desarrollo colaborativo.

De ésta se desprenden los demás documentos que apoyan a la guía: se elaboró un Manual de instalación y configuración de GForge para que las personas que vayan a utilizar la guía metodológica puedan tener la herramienta en su propio equipo.

Además se crearon plantillas de los siguientes documentos que deben ser elaborados para seguir la metodología dentro de la guía metodológica, para cada uno de sus nueve (9) procesos.



Ilustración 23 - ConstruColectiva Work Breakdown Structure

A continuación se especifican los documentos que soportan a la guía metodológica de ConstruColectiva en lo referente a cada uno de sus procesos:

PROCESO	DOCUMENTO	DESCRIPCIÓN
Proceso 1: Análisis de Requerimientos y casos de uso	Diagrama de casos de uso	Se muestran como ejemplo los casos de uso con sus correspondientes relaciones entre sí y sus actores involucrados, de acuerdo a las reglas definidas por UML.
	Plantilla HACER&USOS [Grupo de investigación ISTAR]	Define la documentación para cada uno de los casos de uso y los requerimientos del proyecto, especificando también su correspondiente relación y modelo de trazabilidad, junto con la descripción de los actores involucrados.
Proceso 2: Planeación del desarrollo del proyecto	Contrato segunda fase del proyecto	Se especifican los costos, los tiempos y los recursos que se necesitarán durante la ejecución de la segunda fase del proyecto, el cual debe ser firmado tanto por el cliente como por el gerente del proyecto.
	Software Project Management Plans – SPMP (Versión modificada por ConstruColectiva) [IEEE, 1998]	Se especifican los planes que se llevarán a cabo durante la ejecución de la segunda fase del proyecto, teniendo en cuenta, los procesos de gestión necesarios para el proyecto, sus responsables y el cronograma general para esta fase del proyecto.
Proceso 3: Arquitectura y diseño	Software Architecture Description – SAD (Versión modificada por ConstruColectiva) [Bustacara]	Con este documento, se describe desde un punto de vista general, la arquitectura de software que se va a utilizar en el sistema que se va a desarrollar, haciendo énfasis en todas las vistas arquitectónicas para describir los diferentes aspectos del sistema, como lo son los subsistemas, las interfaces, las capas y sus clases esenciales. Para este documento se seguirá la plantilla que propone el profesor Cesar Bustacara de la Pontificia Universidad Javeriana.
Proceso 4: Desarrollo	Especificación del caso de uso	Documento que define el diseño y la descripción del funcionamiento en detalle del caso de uso que se está implementando. Para este documento, sólo se tiene disponible la plantilla, la cual se debe utilizar para cada caso de uso que tenga el proyecto.
	Entrega para pruebas	Formato que resume los resultados obtenidos en el desarrollo de un caso de uso, para que sean tenidos en cuenta en el momento de realizar los diferentes tipos de pruebas que se requieran.
	Plan de pruebas funcionales	Documento que registra los procedimientos que se deben realizar durante la sesión de pruebas funcionales, las cuales se ejecutan sobre las clases involucradas que tiene cada caso de uso. Durante esta sesión, el gerente del proyecto define los mecanismos de pruebas que serán utilizados para cada caso de uso, con respecto a sus funcionalidades descritas en el documento de especificación del caso de uso.
	Reporte de defectos e incidentes en las pruebas funcionales	Este documento también se utiliza en el Proceso 5: Pruebas y proceso de integración, el cual se trata de un formato que describe los defectos que se han detectado, al someter cada caso de uso a las pruebas unitarias o a las pruebas de integración, con el fin de registrar los resultados obtenidos.
Proceso 5: Pruebas y proceso de integración	Plan de pruebas de integración [Golazeski, Miller, Olsen, Rockstroh, & Smith, 2009]	Documento que describe el plan que se llevará a cabo para ejecutar las pruebas de integración sobre cada conjunto de casos de uso desarrollados.
Proceso 6: Entrega al cliente y pruebas por parte del cliente	Formato de los requerimientos asociados a los casos de uso entregados	Formato que evalúa si cada uno de los casos de uso entregados, cumple con sus requerimientos asociados, registrando sus correspondientes observaciones realizadas por el cliente.
Proceso 7: Bugs	Formato de descripción del bug	Este documento se trata de un formato que tiene el objetivo de registrar las descripciones referentes a un bug en específico, de tal manera que se pueda llevar a cabo su gestión, con el fin de solucionarlo lo más pronto posible.
Proceso 8: Extensiones	Formato de descripción de la extensión	Este documento se trata de un formato que tiene el objetivo de registrar las descripciones referentes a una extensión en específico, de tal manera que se pueda llevar a cabo su gestión, con el fin de implementarla lo más pronto posible.
Proceso 9: Puesta en operación	Plan de capacitación	Documento que detalla los pasos y procedimientos a tener en cuenta para realizar la capacitación del uso del producto de software desarrollado a sus usuarios finales.
	Manual de instalación	Documento que explica los procedimientos que se deben realizar para instalar el producto de software desarrollado, en el ambiente de destino.
	Manual técnico	Documento que contiene todos los documentos de las especificaciones de los casos de uso desarrollados e implementados en el proyecto.
	Manual de usuario	Documento que explica los procedimientos que se deben realizar para utilizar el producto de software desarrollado en el ambiente de destino por los usuarios finales.

Tabla 14 - Resultados de los documentos que soportan la guía metodológica

IV.1.1. Evaluación de la guía metodológica

Con el fin de poner a prueba el principal producto de este trabajo de grado, la guía metodológica, con una persona experta de una casa de software importante en Colombia, se contactó al ingeniero Diego Marín quien es el líder del grupo de calidad de la empresa Heinsohn Business Technology S.A. [Heinsohn Business Technology S.A., 2008].

Para aplicar la prueba se ha utilizado un formato de encuesta con el fin de obtener retroalimentación del avance la guía metodológica que se llevaba el día 14 de octubre de 2009, el cual se encuentra en el Anexo 2 – Formato de encuesta, la cual consta de preguntas cerradas con su correspondiente comentario opcional y se divide en cuatro grupos, preguntas generales, preguntas relativas a procesos, roles y metodologías ágiles, preguntas relativas al ambiente de desarrollo colaborativo, preguntas relativas al impacto práctico de la guía metodológica.

Los resultados obtenidos en la encuesta resuelta por el Ing. Diego Marín consignada en el Anexo 3 – Encuesta diligenciada en la cual de 22 preguntas que posee la guía metodológica el encuestado está en desacuerdo solo en 3 preguntas.

Esto se debe a que no se encontró la manera de cómo generar reportes de métricas en la aplicación, ya que el estado en el que se encontraba en esa fecha la guía no ofrecía tal servicio, puesto que esta funcionalidad estaba programa para realizar dicha documentación pero aún no se había elaborado esta actividad.

También surgió un desacierto en el momento de presentar las notificaciones vía correo electrónico, debido a que no se pudieron comprobar las alertas generadas por GForge dado que por motivos logísticos no se pudo acceder a las cuentas asociadas con dichas alertas.