Gestión de Incidencias y Bugs

180 todo el sitio. Esto esta alineado con nuestro enfoque en cuanto a Eficiencia, pues no es costoso acceder a las funcionalidades del sistema. Aquellas funcionalidades que tienen una complejidad más alta fueron separadas en diferentes paginas para que el promedio (hasta la fecha) no fuese más de 2 clics. Ver ilustración 9.3.1-5

Ilustración 9.3.1-5

181 Actualmente tenemos 40 incidentes registrados a lo largo de toda la fase de construcción (Ver Ilustración 9.3.2-1), con 12 incidentes sin resolver, de los cuales 2 están en progreso.

De todos ellos, 7 fueron Bugs detectados.

Ilustración 9.3.2-1

El promedio de resolución de los incidentes es de casi 6 días, 5,8 para los incidentes en general, pero de 4,6 días para la resolución de los Bugs. Si bien se agrupó la información para simplificar, los defectos están catalogados en función de su criticidad, dato que puede ser relevante si consideramos en qué momento del proyecto es que surgen.

Ilustración 9.3.2-2

Se ha observado una aparición de más incidentes (sobre todo Bugs) sobre el final de la etapa de construcción, y esto puede ser explicado por la necesidad de integrar diferentes componentes.

182 Ilustración 9.3.2-3

De la ilustración 9.3.2-3 se puede ver que la cantidad de días acumulados totales en la resolución de los incidentes, los Bugs implican el 20% del esfuerzo, siendo este un factor muy importante a resolver para reducir los tiempos promedio de solución. Cabe destacar que una característica de nuestro proyecto fue el esfuerzo dedicado a otras etapas concurrentemente, sobre todo en las etapas finales. Se podría implementar una herramienta o planilla que permitiese registrar el esfuerzo real en horas, a efectos de contabilizar de manera más eficiente el esfuerzo dedicado al retrabajo.

9.3.2 Pruebas

Para lograr obtener un producto que cumpla con las expectativas funcionales del cliente, se definieron y realizaron distintos tipos de pruebas:

o Pruebas Unitarias o Pruebas Funcionales o Pruebas de Performance o Pruebas de Compatibilidad

El desarrollo de todas estas pruebas puede consultarse en el Capítulo 7

183

Conclusiones

En general, la prueba de concepto demostró con éxito la viabilidad de la idea del nuevo producto. Los requerimientos exigidos por el Cliente se cubren en su mayoría, y los que han sido observados son perfectamente ajustables en la infraestructura del banco. Por otro lado, los datos y la evidencia recabada en el análisis de los algoritmos/modelos utilizados evidencian que el mecanismo propuesto es válido. Ver resultados de pruebas en la Sección 6.2.3.

Sin embargo, para asegurar que el producto sea de calidad aceptable o de alta calidad, se hacen las siguientes recomendaciones:

- Recopilar continuamente los comentarios de los usuarios: Estos son fundamentales para identificar problemas de usabilidad en el producto. Para garantizar que el producto final satisfaga las necesidades de los usuarios, se recomienda que el equipo de desarrollo recopile continuamente estos comentarios y realice mejoras en el producto.

-

Establecer un proceso formal para control de calidad: si bien el equipo pudo probar con éxito el producto, el proceso fue algo ad hoc. Sabemos que los proyectos de Prueba de Concepto brindan ciertas libertades en cuanto a los niveles de exigencia en torno a QA, es por ello por lo que se debería establecer un proceso que garantice la calidad, con roles y responsabilidades claramente definidos, esto puede ayudar a garantizar que el producto sea de calidad y cumpla con todos los requerimientos.

184

10. Gestión de la configuración

La gestión de la configuración de software es un proceso clave en el desarrollo y mantenimiento de cualquier sistema de software. Se trata de un conjunto de prácticas y herramientas que permiten controlar y gestionar los cambios en el software a lo largo de todo su ciclo de vida, desde la planificación y diseño hasta el mantenimiento y actualización.

Es esencial para garantizar la calidad del software, asegurando que se cumplan los requisitos del cliente y que se mantengan los estándares de calidad y seguridad. Además, permite trabajar de manera colaborativa y eficiente, manteniendo un registro de todas las versiones del software y facilitando la identificación y resolución de problemas.

Para llevar un control de las versiones del software, utilizamos el repositorio en la nube GitHub, donde mantenemos sincronizados los repositorios locales de cada desarrollador con el repositorio remoto. También usamos SourceTree como herramienta de sincronización entre repositorio local y repositorio remoto.

Desde la perspectiva de Sourcetree podemos ver el registro de actividades, un detalle de la fecha y hora del upload, y el comentario del commit al respecto del cambio o los cambios realizados. (Ver Ilustración 9-1: Gestión de la Configuración, SourceTree)

Ilustración 10-1: Gestión de la Configuración, SourceTree

185 Es importante en este punto que los registros de los comentarios sean claros y

suficientes, de esa manera el equipo puede contar efectivamente con la versión adecuada a la hora de hacer el pull, o descarga. Al momento llevamos unos 70 commits, y ya hemos finalizado el sprint 4, habiendo llegado al hito del release 2.

Ilustración 10-2: Gestión de la Configuración, Status

La herramienta notifica de los cambios en el repositorio local que deben ser impactados en el repositorio remoto, pero también nos avisa de diferencias en el sentido inverso. Tiene una gestión de diferencias que permite seleccionar cuáles cambios son los que se deben mantener, permitiendo elegir las modificaciones más recientes o convenientes. (Ver Ilustración 9-3: Gestión de la Configuración, Aviso de desfase de repositorios)

186 Ilustración 10-3: Gestión de la Configuración, Aviso de desfase de repositorios

De esta manera, mediante una secuencia de pasos predefinidos, se resuelve el conflicto o conflictos, y se puede proceder a hacer la subida de la versión del repositorio local.

(Ver Ilustración 9-4: Gestión de la Configuración, Desfase o conflicto resuelto)

Ilustración 9-4: Gestión de la Configuración, Desfase o conflicto resuelto.

187

10.1 Gestión de Cambios

Durante la etapa de construcción se utilizó un proceso de control de cambios, sobre los elementos de configuración del software definidos anteriormente.

El procedimiento que utilizo fue simplificado, para poder responder rápidamente ante un cambio y lograr un consenso la conveniencia y oportunidad del mismo. Ver Ilustración 10.1-1 Proceso de Gestión de Cambios

Ilustración 10.1-1 Proceso de Gestión de Cambios

El proceso comienza cuando un miembro del equipo detecta un error, el mismo ya se registra en la planilla de control (Ver Ilustración 9.1.3-2: Control de Tareas) y queda registro del día de descubrimiento, detalle del error, módulos y función relacionada. En el caso de una solicitud de cambio o nueva funcionalidad se evalúa y en caso de aprobarse en el equipo, se registra, con su categoría correspondiente, dejando los mismos datos, fecha, detalle, módulos y función (actual o nuevo). Los motivos por los que no se aprobaría serian

188 por cuestiones de alcance o conveniencia y para aquellas que no entren en este ciclo pero que tengan valor para futuro, se agregaran en la lista de tareas a futuro. Ver Capitulo 12 – Próximos Pasos

Cuando se finaliza una tarea “x”, se deja registro de la fecha de resolución, se cambia el estado de “Iniciado” a “Terminado” y se agrega comentario pertinente. Luego se vuelve a revisar la lista de tareas por resolver en búsqueda de ítems que tengan alta

prioridad y que además estén relacionados con la instancia de construcción actual para estar alineados con los tiempos planificados de dicha etapa. En este caso, se notifica al equipo que se va a tomar la tarea, y se cambia el estado de “creado” a “iniciado”.

189

In document Shake Tool (página 180-189)