Repositorios

En esta sección se detalla cómo se organizaron los repositorios de código y

9.3.1. Software

Teniendo en cuenta las distintas decisiones previas a comenzar con el desarrollo fue posible determinar qué repositorios eran necesarios para gestionar el código del sistema. Estos son los siguientes:

Repositorio Descripción

tesis-app-back Repositorio utilizado para almacenar el código del backend y frontend del backofficeenRuby on Rails.

tesis-app-front Repositorio utilizado para almacenar el código del frontend para la aplicación móvil, tótem, cocina y caja. Esto está en el mismo proyecto programado en Flutter.

Tabla 33: Repositorios

En la siguiente imagen se pueden ver ambos repositorios creados en GitHub.

Figura 78: Repositorios, GitHub

9.3.2. Workflow

El equipo optó por utilizar el modelo de ramificación Gitflow como forma de trabajo con el repositorio. Implica el uso de ramas de funcionalidades y múltiples ramas primarias.

En este modelo los desarrolladores crean una ramafeaturedonde implementan una nueva funcionalidad, luego cuando está terminada se hace merge de la rama featurecon develop.

Una vez que develop cuenta con las suficientes funcionalidades para unrelease, se crea una nueva rama release partiendo de ese punto. No se puede agregar nuevas funcionalidades, solo arreglos de bugs. Cuando el release está pronto esta rama se debe hacer merge con main generando una nueva versión, también debe hacerse merge con la rama develop para actualizarla con los posibles arreglos hechos.

Figura 79: GitFlow [62]

Main

Rama que almacena todas las versiones de código testeadas y prontas para desplegar en producción.

Hotfix

Release

Rama que permite trabajar temporalmente sobre un nuevo lanzamiento de release en producción.

Develop

Rama a la cual los integrantes del equipo deben subir las funcionalidades que vayan desarrollando. Es importante que los desarrolladores prueben bien todo el sistema antes de subir un nuevo cambio para mantener la estabilidad de la rama develop.

Feature

Rama en la cual cada desarrollador trabaja para crear una nueva funcionalidad.

9.3.3. Documentación

Toda la documentación del proyecto fue guardada en carpetas en Google Drive compartidas entre los integrantes del equipo. A continuación, se muestra su estructura y que se puede encontrar en cada una de ellas.

Figura 80: Gestión de documentación

Gestión de tesis

En esta carpeta se incluyen todos los documentos relacionados a las formalidades necesarias para iniciar la tesis. Formularios de presentación, escolaridades, curriculums, entre otros.

Sprint 0

Carpeta en la que se encuentran todos los documentos obtenidos de la etapa de investigación inicial. También de esta surgen otros documentos que se incluyen en sus categorías correspondientes. Aquí están los análisis de tecnologías, documentos que nos dio el cliente, entre otras cosas.

Arquitectura

Se incluyen todos los diagramas que se hacen en las etapas de diseño arquitectónico. Las distintas versiones que se fueron generando y sus documentos relacionados.

Ingeniería de requerimientos

En esta carpeta se encuentran todos los archivos obtenidos del análisis, especificación y validación de requerimientos. Estos son encuestas, entrevistas, conclusiones de ingeniería inversa. Se guarda aquí lo generado de las distintas validaciones con el cliente y las pruebas con los usuarios. También se incluyen mockupshechos a lo largo de los distintos ciclos.

Gestión de proyecto

Se guardan los documentos necesarios para llevar adelante la gestión de proyecto, estos son análisis de riesgos, metodologías de trabajo, métricas de gestión.

Gestión de calidad

Aquí se incluye el plan de calidad, plan de aseguramiento de calidad y plan de pruebas.

Revisiones

De las distintas revisiones que se realizaron durante el proyecto debimos construir presentaciones, borradores de textos de la presentación, guiones. Todo esto está en

Documentación final

Se realizaron varios documentos en forma de borradores para construir la entrega final del proyecto. Además de imágenes, links a bibliografía y más. Esto se puede encontrar en esta carpeta.

9.3.4. Gestión de cambios

Fue necesario establecer un proceso para validar nuevos cambios que vayan surgiendo en el correr del proyecto. Desde el comienzo hasta las últimas instancias del desarrollo nuevos cambios pueden surgir por parte del cliente o mismo de los integrantes del equipo.

Esto puede derivarse de distintas razones: iniciativa propia donde a alguien se le ocurre una idea de mejora, después de realizar pruebas de usabilidad (estas se pueden ver en Anexo 12.9. Pruebas de usabilidad, pruebas sobremockups, mejoras detectadas por observación, entre otras.

Si estos cambios no son gestionados de la manera adecuada, pueden surgir problemas en la forma de trabajo del equipo. Es necesario que estos sean aprobados e incluidos de manera ordenada.

A continuación, se plantea el plan de gestión de un cambio.

1. Llega una solicitud de cambio

2. El Product Owner en conjunto con el resto del equipo deben evaluar si se debe hacer o no el cambio. Aquí se debe tener presente si el cambio aporta valor a la solución, si es adecuado según los objetivos del proyecto, si es viable su implementación según el impacto que genere.

3. Luego de evaluado, si se decide no seguir adelante con el cambio se descarta. Si fue propuesto por el cliente se le debe informar las razones de su descarte.

4. Por otro lado, si se decide incluir el cambio este se debe estimar en story pointsy priorizar dependiendo de su necesidad.

5. Por último, el cambio es agregado al Product Backlog para ser desarrollado en las siguientes iteraciones.

Figura 81: Gestión de cambios