Home - LadyCD/Gestion-Estres GitHub Wiki

Gestión del nivel de estrés laboral

Aplicación que integra un dispositivo wearable comercial con una app móvil de autorreporte, orientada a identificar patrones e indicadores asociados a niveles elevados de estrés laboral, generando alertas preventivas para el usuario y reportes agregados y anónimos para el equipo de SST/RRHH de la organización.

Proyecto desarrollado como parte de la línea de Prácticas de Ingeniería de Sistemas de la Universidad Central (Práctica de Ingeniería III — Diseño).

Equipo

Integrante Correo Rol
Lady Carolina Duque Delgado [email protected] Desarrolladora
Sandra Carolina Bohórquez Díaz [email protected] Desarrolladora
Fabián Daniel Hernández Prieto [email protected] Desarrollador
Andrés Germán Pedraza Manrique [email protected] Docente Director

Metodología de trabajo

Este proyecto se desarrolla bajo un enfoque ágil (Scrum), mapeado a las herramientas de GitHub de la siguiente forma:

Concepto Scrum Herramienta GitHub
Sprint Cronograma (ver página Cronograma)
Historia de Usuario Página de la Wiki (HU001, HU002...)
Tarea / Subtarea Issue
Tablero de seguimiento Project (Kanban)

Flujo de trabajo en Git

Estructura del repositorio

Gestion-Estres/
├── src/          ← backend Spring Boot (IntelliJ)
├── pom.xml
└── app-movil/    ← app Android en Java (Android Studio)

Ramas

Rama Uso
main Solo versiones entregables (por ejemplo, la entrega interna del 6 de noviembre)
develop Integración de todo lo terminado y revisado
estructura001 Esqueleto inicial del backend y de la app
HU###-nombre Una rama por historia de usuario, con backend y app juntos. Ejemplos: HU001-registro-usuario, HU020-inicio-sesion, HU021-cuestionario, HU002-vincular-wearable, HU003-deteccion-estres

Paso a paso para cada historia

  1. Definir el contrato: antes de programar, agregar en la página de la historia una sección Endpoints con la ruta, los datos que recibe y lo que responde (por ejemplo, POST /api/usuarios → 201 creado / 409 correo existente).
  2. Crear la rama desde develop con el nombre HU###-nombre.
  3. Backend: entidad, repository, service y controller, con las validaciones de los criterios de aceptación. Probar en Swagger.
  4. App: pantalla que consume el endpoint. Desde el emulador, el backend local se llama con http://10.0.2.2:8080.
  5. Prueba de punta a punta: desde la app hasta MySQL.
  6. Pull Request a develop: lo revisa otro integrante contra los criterios de aceptación de la wiki y hace el merge.
  7. Cierre de semana: develop → main con una versión etiquetada (v0.1, v0.2...).

No se hace push directo a main ni a develop: todo entra por Pull Request.

Contenido de la Wiki

Generalidades

Análisis

Diseño

Marco Legal y Ético

Planeación