issue0

[Alfredofigueroasilvas]

GUÍA DE FLUJO DE GIT La propuesta de guía de flujo de trabajo para BuzBot se basa en el modelo GitFlow, que organiza el desarrollo del software mediante un sistema de ramas claramente definidas. La guía establece nomenclaturas y estándares para los nombres de las ramas y los mensajes de commit, asegurando que todos los cambios se gestionen de manera estructurada y coherente.

El flujo de trabajo incluye ramas para el desarrollo de nuevas funcionalidades, preparación de lanzamientos, y corrección de errores críticos, garantizando un ciclo de desarrollo ordenado y eficiente. También se definen estándares de mensajes de commit para mantener un historial claro y comprensible de los cambios realizados.

Nomenclaturas Ramas Principales

• master: Contiene el código listo para la producción.
• develop: Rama donde se fusionan todas las características completadas para la siguiente versión.

Ramas de Características

• feature/nombre: Utilizada el desarrollo de nuevas características. Ejemplo: feature/rutas, feature/recorridos, etc.

Ramas de Publicación

• release/version: Utilizada para preparar una nueva versión de lanzamiento. Ejemplo: release/v1.0.

Ramas de Corrección

• hotfix/nombre: Utilizada para corregir los errores en producción. Ejemplo: hotfix/fix-rutas, hotfix/fix-recorridos

Ramas de Prueba

• testing/feature: Utilizada para realizar pruebas adicionales. Ejemplo: testing/all-features

Estándares Formato de Mensajes de Commit Estructura: (<área>):

Tipos comunes:

• feat: Nueva característica.
• fix: Corrección de un error.
• docs: Cambios en la documentación.
• style: Cambios que no afectan la lógica del código (formato, espacios, etc.).
• refactor: Cambios en el código que no corrigen errores ni añaden características.
• test: Añadir o corregir pruebas.
• chore: Actualizaciones menores y tareas generales.

Ejemplos feat(rutas): añadir la funcionalidad de rutas favoritas/concurrentes. fix(notificaciones): corregir error que causa crash en notificaciones.

Convenciones de Naming

• Utilizar nombres descriptivos y claros.
• Utilizar guiones en lugar de espacios para separar palabras.
• Mantener los nombres en minúsculas.
• Ejemplo: feature/rutas, hotfix/fix-rutas

Estructura del Proyecto Organización de carpetas y archivos

• Seguir una estructura de carpetas clara y coherente para separar la lógica del backend, frontend, configuraciones, etc.

Ejemplo BuzBot

• backend/: controllers/, models/, routes/, services/, tests/.
• frontend/: components/, pages/, services/, tests/.
• config/
• scripts/

Convenios Flujo de trabajo de ramas

• Crear desde develop.
• Trabajar en la característica.
• Crear commits regularmente.
• Al completar, fusionar de vuelta a develop.

Ramas de publicación

• Crear desde develop cuando se está listo para una nueva versión.
• Realizar pruebas y correcciones finales.
• Fusionar en master y etiquetar la versión.
• Fusionar de vuelta en develop si hay cambios.

Ramas de corrección

• Crear desde master cuando se descubre un error crítico.
• Corregir el error.
• Fusionar de vuelta a master y etiquetar la versión.
• Fusionar en develop para mantener la corrección en el desarrollo continuo.

Revisión de código

• Todas las ramas deben pasar por una revisión de código antes de ser fusionadas.
• Al menos un miembro del equipo debe revisar y aprobar los cambios.

Integración continua

• Utilizar herramientas de integración continua (CI) para ejecutar pruebas automáticas en cada commit.
• Asegurarse de que todas las pruebas pasen antes de fusionar las ramas.

Documentación y comunicación

• Mantener documentación clara y actualizada sobre el flujo de trabajo y las convenciones.
• Comunicarse frecuentemente con el equipo sobre el estado de las características y correcciones.

Diagrama de flujo de datos BuzBot

Diagrama de flujo de datos de Usuario

Diagrama de arquitectura de tablas

Diagrama de clases

Diagrama de secuencia

Este Proyecto busca resolver el problema de usuarios que no cuentan con información acerca la llegada y salida de los autobuses, en la cual le afecta al usuario en tiempo de espera para poder utilizar ese servicio. Act.1.- Definición del proceso de desarrollo Web.docx

[ivanchenoweth]

Muy bien. Solo tengo dudas sobre el DFD ... sugiero hagan uno solo. Pueden consultarme en sesion de clase

[ivanchenoweth]

No localizo este issue dentro del proyecto @carcub @a19311044 @Alfredofigueroasilvas

[ivanchenoweth]

Sugiero colocarle etiquetas y fechas