Entrega semana 1

Estado: En curso. Fecha de corte: 11 de octubre de 2026.

1. Identificación de la entrega

Campo	Valor
Grupo	Grupo 17
Estudiante y único integrante	Luis Felipe Navarro Julio
Institución	Universidad de los Andes
Programa académico	Maestría en Ingeniería de Software
Modalidad	Desarrollo individual
Periodo	5 al 11 de octubre de 2026
Sprint o fase	Sprint 1, primera semana
Hito asociado	Versión v0.1.0 en preparación
Objetivo semanal	Configurar la línea base DevOps, organizar el backlog e iniciar HU001 y HU003
Repositorio integrador	sport-app-platform
Tablero	SportApp Platform

2. Trazabilidad de la rúbrica

Esta página sigue exactamente el orden de los criterios de revisión. Los puntos de la segunda columna son el valor máximo definido por la rúbrica, no una autoevaluación ni una calificación obtenida.

Estados utilizados:

• Verificado: existe evidencia directa consultable en GitHub Project, un pull request o una ejecución de GitHub Actions.
• Derivado: el resultado se calcula con datos verificados y se muestra la fórmula.
• Documentado: existe una política o diseño, pero todavía no se ha ejecutado el recorrido completo.
• Parcial: existe evidencia para una parte del alcance y se declaran las brechas.
• Pendiente: no existe aún una evidencia entregable; no se afirma cumplimiento.
• No demostrado: no existe la evidencia independiente requerida y no se reclama el criterio opcional.

Criterio de revisión	Puntos máximos	Estado al corte	Evidencia en esta entrega
Parametrización de integración continua / despliegue continuo	10	Parcial: CI verificada en backend y frontend; móvil, release integrada y despliegue productivo pendientes	3.1
Sprint Backlog y asignación por integrante	10	Verificado: 10 HU, 27 PHU y 32 puntos de valor en Sprint 1; las 40 HU tienen responsable	3.2
Commits / pull requests	15	Verificado: PR fusionados y trazables en backend, frontend y plataforma	3.3
Flujo de trabajo y estrategia de versionamiento	10	Parcial: flujo feature/* → develop demostrado; cierre release/* → main → tag aún no ejecutado	3.4
Ejecución de pruebas	10	Parcial: pruebas verificadas en backend y frontend; recorrido móvil y aceptación E2E vertical pendientes	3.5
Peer review	Opcional	No demostrado: no hay revisión registrada por una persona distinta del autor	3.6
Revisión automática de código	Opcional	Verificado: controles automáticos verdes en backend y frontend	3.7
Burndown chart	5	Derivado: desarrollo atrasado 8,5 PHU-eq; producción en fecha sobre el backlog completo de 100 PHU	4.1
Velocity chart	5	Derivado: 5 PHU equivalentes como avance interno; velocidad oficial provisional de 0 PHU terminados	4.2
Value chart	5	Derivado: 6,5 puntos de valor desarrollados; 0 entregados a producción	4.3
Tablero del Proyecto	15	Verificado: 52 elementos, incluidos 40 HU con responsable, PHU, valor y planeación	5
Video con evidencias	15	Disponible: enlaces de YouTube y VoiceThread publicados y comprobados	6
Total obligatorio	100	Entrega en curso; no se calcula una nota propia	—

Regla de veracidad: una política documentada no se presenta como ejecución; un PR fusionado no implica por sí mismo que la HU esté aceptada; el avance ponderado no se presenta como entrega productiva; y todo elemento pendiente permanece visible.

3. Configuración del ambiente de trabajo DevOps — 55 puntos

3.1 Parametrización de integración y despliegue continuo — 10 puntos

Evidencia esperada	Resultado verificable	Estado	Referencias documentales y técnicas
CI activada por push y pull_request	Backend y frontend ejecutan calidad, pruebas, cobertura, seguridad y construcción de artefactos/imágenes en GitHub Actions	Demostrado en ambos repositorios	Qué ocurre con un push · PR backend #8 · PR frontend #7
Política de despliegue	Un push o merge a develop no despliega GCP; desarrollo se ejecuta localmente	Documentada	Eventos de integración y despliegue · Vista de despliegue · Arquitectura local
Release por componente	Backend, frontend y móvil conservan versiones independientes	Documentada; automatización pendiente	Flujo Git por repositorio · Desde dónde se libera · Repositorios y versiones
Release integrada	sport-app-platform debe seleccionar tags, commits y digests compatibles	Diseño terminado; workflow pendiente	Release completa · Versiones visibles y verificables · Infraestructura Terraform: ubicación y alcance
Infraestructura como código	El PR de plataforma declara ejecución local de terraform validate y terraform test; GitHub no registra checks automáticos asociados a ese PR	Evidencia manual declarada; automatización y aplicación productiva pendientes	Flujo de validación Terraform · Ambientes vigentes · PR plataforma #41

Referencias complementarias:

• Integración continua y releases.
• PR backend #1 y ejecución CI.
• PR plataforma #41, Terraform fusionado el 10 de octubre.
• Vista de infraestructura Terraform.

Brecha declarada: backend y frontend web ya tienen evidencia CI; móvil aún no. La release coordinada y el despliegue de producción siguen pendientes.

Evidencias gráficas de integración y despliegue

Las capturas siguientes presentan el estado observado de los workflows durante la semana 1. La presencia histórica de deliver-development.yml no autoriza un despliegue a GCP: la política vigente exige desarrollo local, publicación solo durante una release y promoción de producción con aprobación.

Figura S1-01. Workflows ci.yml y deliver-development.yml presentes en la rama develop del backend. El segundo se conserva aquí como evidencia histórica del corte y debe retirarse o transformarse para no desplegar desarrollo en GCP.

Figura S1-02. Configuración de ci.yml: ejecución ante pushes de ramas de trabajo y pull requests hacia develop o main, permisos de solo lectura y control de concurrencia.

Figura S1-03. Captura almacenada como figura_3_deliver.png; su contenido muestra nuevamente el encabezado de ci.yml y sus disparadores, no la definición de un despliegue.

Figura S1-04. Historial de ejecuciones del backend con resultados satisfactorios sobre ramas feature/* y sobre develop después de fusionar pull requests.

Figura S1-05. Ejecución de deliver-development: el control gate finaliza correctamente, mientras los jobs de publicación y despliegue permanecen omitidos. La evidencia confirma que el merge no produjo un despliegue a GCP.

Figura S1-06. Pipeline de CI del pull request backend con calidad, pruebas unitarias, secretos, integración y cobertura, seguridad y construcción de imágenes en estado satisfactorio.

Figura S1-07. Registro del job de pruebas unitarias del backend ejecutado con uv run python scripts/task.py test unit, con los casos mostrados en estado correcto.

Figura S1-09. Historial de GitHub Actions del frontend con ejecuciones satisfactorias de ci-web para cambios y pull requests de HU001, HU003 y estilo visual.

Figura S1-10. Workflows ci-web.yml y release-web.yml versionados en la rama develop del frontend.

3.2 Sprint Backlog y asignación por integrante — 10 puntos

Elemento	Resultado al corte	Evidencia
HU del Sprint 1	10	Planeación y sprints
PHU comprometidos actuales	27	Métricas y gráficos
HU activas	2: HU001 en revisión y HU003 en curso	Avance de historias
HU aceptadas	0	SportApp Platform y revisión del sprint
Responsable de las HU	Luis Felipe Navarro Julio (lfnavarroj1) en las 40 HU	SportApp Platform

Backlog vigente del Sprint 1:

HU	Descripción resumida	PHU	Valor	Estado
HU001	Registrar usuario	5	5	En revisión, 80 % verificable
HU003	Iniciar sesión web y móvil	2	5	En curso, 50 % verificable
HU010	Crear plan de entrenamiento	5	5	Backlog
HU011	Ver historial de entrenamiento	2	2	Backlog
HU020	Visualizar disponibilidad de servicios	2	3	Backlog
HU021	Crear evento masivo	3	4	Backlog
HU023	Consultar calendario de eventos	2	3	Backlog
HU032	Iniciar o finalizar entrenamiento	2	3	Backlog
HU034	Calcular FTP y VO₂max	2	1	Backlog
HU035	Ver calendario deportivo	2	1	Backlog
Total	10 HU	27	32	—

3.3 Commits y pull requests — 15 puntos

Repositorio	PR	Alcance	Resultado al corte
Backend	#1	HU001: registro de usuario	CI aprobada e integrado en develop
Backend	#2	CORS para BFF web	CI aprobada e integrado en develop
Backend	#3	HU003: sesión y renovación en backend/BFF	CI aprobada e integrado en develop
Backend	#6	HU003: refresh token web en cookie HttpOnly (bff-web 0.4.0)	CI aprobada e integrado en develop
Backend	#7	HU001: catálogo, afiliación automática FREE y evento	CI aprobada e integrado en develop
Backend	#8	HU003: capacidades por actor y plan en ambos BFF	CI aprobada e integrado en develop
Frontend	#3	HU001: registro integrado con BFF web	CI aprobada e integrado en develop
Frontend	#7	HU003: inicio y menú lateral por actor	CI aprobada e integrado en develop
Plataforma	#41	Terraform local y GCP	Fusionado el 10 de octubre

Los PR demuestran integración técnica, pero no convierten por sí solos una HU en aceptada. Los commits, la ejecución CI y la evidencia funcional deben conservar trazabilidad con su HU padre.

3.4 Flujo de trabajo y estrategia de versionamiento — 10 puntos

El flujo acordado usa GitFlow adaptado:

flowchart LR
    I[Issue o tarea de HU] --> F[feature/HUxxx-descripcion]
    F --> CI[Push y CI]
    CI --> PR[Pull request a develop]
    PR --> R[Revisión y checks]
    R --> D[Merge a develop]
    D --> RL[release/vX.Y.Z]
    RL --> M[PR a main]
    M --> T[Tag y artefacto inmutable]
    M --> H[hotfix si aplica]

Reglas acordadas:

• main representa versiones liberadas; develop, integración del siguiente incremento.
• Cada HU se implementa mediante tareas técnicas por repositorio sin duplicar sus PHU o valor.
• Las ramas usan feature/HUxxx-*, fix/*, release/* o hotfix/* según su propósito.
• Todo cambio hacia develop o main se integra mediante pull request y CI.
• Cada componente conserva su SemVer; la plataforma registra la combinación compatible.
• El tag se crea desde main después de aceptar la release, no desde una rama de trabajo.

Evidencia: Integración continua y releases y los PR de la sección anterior. Los PR demuestran el recorrido de ramas de trabajo hacia develop; al 11 de octubre todavía no existe evidencia de una rama release/*, un merge de release a main ni el tag v0.1.0.

3.5 Ejecución de pruebas — 10 puntos

Evidencia	Resultado
Última ejecución CI backend	PR #8, ejecución 38177070246
Pruebas backend aprobadas	328 de 328 en integration-coverage
Cobertura backend	96 % combinado
Última ejecución CI frontend	PR #7, ejecución 38175510224
Pruebas frontend aprobadas	167 de 167
Cobertura frontend	98,07 % sentencias; 92,67 % ramas
Umbral de cobertura	Backend: 80 % ratificado; frontend: umbral formal pendiente de ratificar
Controles de seguridad	Jobs security y secrets del backend, y security del frontend, terminados correctamente en las ejecuciones enlazadas
E2E vertical de HU001	Pendiente; 0 de 1 recorrido crítico aceptado
Evidencia web y móvil	Web verificada en CI; móvil pendiente

La evidencia ampliada y el gráfico de cobertura están en Calidad, pruebas y cobertura.

3.6 Peer review — opcional

El Grupo 17 tiene un solo integrante, Luis Felipe Navarro Julio; por ello no existe otro miembro interno que pueda realizar peer review. No se declara cumplimiento sin una aprobación de una persona distinta al autor. Si un docente o revisor externo participa, la evidencia válida será su revisión registrada en el PR, con comentarios resueltos y aprobación previa al merge. Al corte no se enlaza una evidencia independiente.

3.7 Revisión automática de código — opcional

El backend ejecuta automáticamente Ruff, mypy estricto, Bandit, pip-audit, Gitleaks, pruebas y cobertura. La ejecución del PR #8 terminó sin hallazgos bloqueantes. El frontend ejecuta formato, lint, tipos, auditoría, pruebas, E2E y contenedor en el PR #7. Esta evidencia complementa, pero no reemplaza, la revisión humana.

Nota — controles citados: Gitleaks busca secretos y credenciales expuestos en archivos e historial Git; Bandit busca patrones de código Python potencialmente inseguros mediante análisis estático; pip-audit identifica dependencias Python con vulnerabilidades conocidas. Un resultado limpio solo confirma que esas herramientas no encontraron hallazgos bajo sus reglas y fuentes disponibles.

4. Evidencias de avance semanal — 15 puntos

4.1 Burndown chart — 5 puntos

Se presentan dos alcances distintos: desarrollo mide el Sprint 1 completo, mientras producción mide las entregas acumuladas de todo el proyecto.

Desarrollo — Sprint 1 completo, dos semanas

El alcance verificable es de 27 PHU. La trayectoria esperada para las dos semanas es 27 → 13,5 → 0. Al cierre de la semana 1 quedan realmente 22 PHU-eq.

Corte	Esperado restante	Real restante	Desviación	Estado
Inicio	27	27	0	En fecha
Fin semana 1	13,5	22	+8,5	Atrasado
Fin semana 2	0	N/D	N/D	Corte futuro

Trayectoria esperada y avance real

Figura. La curva azul muestra el avance esperado de las dos semanas (27 → 13,5 → 0) y la curva roja el avance real disponible (27 → 22). La curva real termina en semana 1 porque todavía no existe un resultado de semana 2.

Como la curva real conserva 8,5 PHU-eq más que la esperada, el desarrollo está atrasado. Se conserva una sola gráfica y no se inventa el valor real futuro.

Producción — proyecto completo, entrega por sprint

Producción parte del backlog completo de 100 PHU. El saldo permanece plano durante cada sprint y disminuye al liberar su versión; por eso la curva esperada tiene forma de escalera.

Hito	Entrega prevista	Esperado restante	Real restante
Inicio	0	100	100
Corte semana 1	0	100	100
Fin Sprint 1 · v0.1.0	27	73	N/D
Corte semana 3 · Sprint 2	0	73	N/D
Fin Sprint 2 · v0.2.0	20	53	N/D
Corte semana 5 · Sprint 3	0	53	N/D
Corte semana 6 · Sprint 3	0	53	N/D
Fin Sprint 3 · v0.3.0	34	19	N/D

Escalera esperada y avance real

Figura. La curva azul representa el plan de producción durante las siete semanas: Sprint 1 tiene dos cortes, Sprint 2 tiene dos y Sprint 3 tiene tres. La curva roja discontinua representa el avance real y termina en la semana 1 porque los demás cortes aún no existen.

Las curvas coinciden en 100 PHU al corte, por lo que producción está en fecha. La escalera esperada disminuye a 73, 53 y 19 PHU al liberar v0.1.0, v0.2.0 y v0.3.0. Los 19 PHU posteriores al Sprint 3 siguen sin sprint y no se eliminan artificialmente. Consulte Métricas y gráficos — burndown.

4.2 Velocity chart — 5 puntos

La velocidad oficial cuenta PHU de historias terminadas conforme a la definición de terminado. Como el sprint continúa abierto, el resultado es provisional. Para mostrar el trabajo semanal sin inflar esa métrica se publica por separado el avance técnico equivalente.

Indicador del Sprint 1	Resultado al corte
PHU comprometidos	27
Avance técnico de la semana 1	5 PHU equivalentes
Avance técnico acumulado	5 de 27 PHU equivalentes; 18,5 %
Velocidad oficial provisional	0 PHU terminados
Velocidad liberada a producción	0 PHU
Predictibilidad de entrega	N/D hasta cerrar el sprint

El cálculo pondera HU001 (5 PHU × 80 % = 4) y HU003 (2 PHU × 50 % = 1). Los otros 20 PHU comprometidos permanecen en backlog.

Perfil de desarrollo — indicador interno

Corte	Esperado acumulado	Real acumulado	Desviación	Estado
Inicio	0 PHU-eq	0 PHU-eq	0	En fecha
Fin de la semana 1	13,5 PHU-eq	5 PHU-eq	-8,5 PHU-eq	Atrasado
Fin de la semana 2	27 PHU-eq	N/D	N/D	Corte futuro

Figura. La curva azul representa el avance técnico esperado completo (0 → 13,5 → 27 PHU-eq). La curva roja representa el avance real disponible (0 → 5 PHU-eq) y termina en el corte de la semana 1.

Perfil de producción — velocidad liberada

Corte	Esperado acumulado	Real acumulado	Estado del dato real
Inicio	0 PHU	0 PHU	Disponible
Sprint 1 · semana 1	0 PHU	0 PHU	Disponible
Sprint 1 · semana 2 / v0.1.0	27 PHU	N/D	Corte futuro
Sprint 2 · semana 3	27 PHU	N/D	Corte futuro
Sprint 2 · semana 4 / v0.2.0	47 PHU	N/D	Corte futuro
Sprint 3 · semana 5	47 PHU	N/D	Corte futuro
Sprint 3 · semana 6	47 PHU	N/D	Corte futuro
Sprint 3 · semana 7 / v0.3.0	81 PHU	N/D	Corte futuro

Figura. La curva azul representa la escalera esperada de PHU liberados durante los siete cortes (0 → 27 → 47 → 81). La curva roja discontinua muestra el avance real y termina en la semana 1 con 0 PHU liberados.

Los 5 PHU equivalentes permiten observar desarrollo, pero no se reportan como velocidad Scrum. El desarrollo está atrasado en 8,5 PHU-eq frente a la referencia semanal. La velocidad oficial permanece en cero hasta que una HU cumpla la definición de terminado; producción está en fecha porque la primera liberación está prevista al final del Sprint 1. Los 19 PHU todavía sin sprint no se presentan como entregados. Consulte Métricas y gráficos — Velocity chart.

4.3 Value chart — 5 puntos

Indicador	Resultado al corte
Valor total del backlog	100 puntos
Valor planificado en Sprint 1	32 puntos
Valor desarrollado en la semana 1	6,5 puntos
Avance de valor desarrollado del sprint	20,3 %
Valor entregado a producción	0 puntos

HU001 aporta 5 × 80 % = 4 puntos desarrollados y HU003 aporta 5 × 50 % = 2,5. Esta ponderación permite observar progreso semanal sin declarar prematuramente la aceptación o la entrega productiva.

Desarrollo — valor esperado y valor real construido

Corte	Esperado acumulado	Real desarrollado	Desviación	Estado
Inicio	0	0	0	En fecha
Fin de la semana 1	16	6,5	-9,5	Atrasado
Fin de la semana 2	32	N/D	N/D	Corte futuro

Figura. La curva azul representa el valor desarrollado esperado (0 → 16 → 32). La curva roja representa el valor real equivalente (0 → 6,5) y termina en la semana 1.

Producción — valor esperado y valor real entregado

Corte	Esperado entregado	Real entregado	Estado
Inicio	0	0	En fecha
Sprint 1 · semana 1	0	0	En fecha
Sprint 1 · semana 2 / v0.1.0	32	N/D	Corte futuro
Sprint 2 · semana 3	32	N/D	Corte futuro
Sprint 2 · semana 4 / v0.2.0	61	N/D	Corte futuro
Sprint 3 · semana 5	61	N/D	Corte futuro
Sprint 3 · semana 6	61	N/D	Corte futuro
Sprint 3 · semana 7 / v0.3.0	87	N/D	Corte futuro

Figura. La curva azul representa la escalera esperada del proyecto (0 → 32 → 61 → 87 puntos) durante siete semanas: dos cortes para Sprint 1, dos para Sprint 2 y tres para Sprint 3. La curva roja discontinua representa el valor realmente entregado y termina en la semana 1 con 0 puntos.

El desarrollo está atrasado en 9,5 puntos de valor frente a la referencia semanal. Producción está en fecha porque antes del primer cierre se esperaban 0 puntos entregados y el resultado real también es 0. Los 13 puntos todavía sin sprint no se presentan como entregados. El valor proporcional es un indicador interno; únicamente las HU aceptadas y liberadas cuentan como valor entregado. Consulte Métricas y gráficos — Value chart.

4.4 Criterio metodológico y bibliografía

• Burndown and burnup guidance — Microsoft Learn: el burndown mide trabajo restante.
• Agile burndown chart tutorial — Atlassian: el esfuerzo restante se representa a través del tiempo y el alcance debe mantenerse visible.
• Scrum Guide 2020: solo el trabajo que cumple la definición de terminado forma parte del incremento.
• Moving Beyond Velocity — Scrum.org: la velocidad se usa para previsión y no representa por sí sola valor o productividad.

5. Tablero del proyecto — 15 puntos

El seguimiento operativo se realiza en SportApp Platform.

Evidencia del tablero	Estado
40 HU cargadas	Disponible
Responsable	Luis Felipe Navarro Julio (lfnavarroj1) en las 40 HU
Sprint	33 HU asignadas; 7 pendientes de planeación
PHU	100 puntos distribuidos
Valor de negocio	100 puntos distribuidos
Estado y avance verificable	HU001 en revisión al 80 %; HU003 en curso al 50 %; las demás en backlog
Evidencia técnica	PR vinculados sin crear PHU ni valor adicionales; los equivalentes se calculan únicamente desde las HU padre
Lectura del Sprint 1	27 PHU pendientes y ninguna HU aceptada; es un cálculo del corte, no un campo denominado AT_RISK en Project

Campos mínimos que debe mostrar la grabación del tablero: HU, título, responsable, estado, sprint, PHU, valor, avance verificable, fechas, repositorios afectados y evidencia.

6. Video con evidencias — 15 puntos

Elemento	Estado
Enlace del video VoiceThread	Ver evidencia en VoiceThread
Enlace del video YouTube	Ver evidencia en YouTube
Fecha de grabación	11/10/2026
Duración	17:00
Acceso verificado	YouTube público; VoiceThread mediante Uniandes; ambos enlaces responden correctamente

Los enlaces fueron comprobados antes de publicar esta entrega. Su disponibilidad deberá conservarse durante el periodo de evaluación.

7. Resultado funcional y métricas del corte

Métrica	Resultado
HU comprometidas en Sprint 1	10
HU activas	2: HU001 en revisión y HU003 en curso
HU aceptadas	0
PHU comprometidos vigentes	27
PHU equivalentes desarrollados	5 de 27
PHU aceptados	0
Valor desarrollado	6,5 de 32 puntos del Sprint 1
Valor aceptado	0 de 100
Pruebas backend de la última CI	328 aprobadas
Cobertura backend	96 % combinado
Pruebas frontend de la última CI	167 aprobadas
Cobertura frontend	98,07 % sentencias; 92,67 % ramas
Versión objetivo	v0.1.0, todavía sin tag

8. Riesgos, decisiones y pendientes de cierre

• HU001 tiene el backend de afiliación gratuita integrado; faltan plataforma, estado web PROVISIONING/FREE, E2E y aceptación.
• HU003 tiene backend y navegación web integrados; faltan adoptar bff-web 0.5.0 en Angular, cliente móvil, E2E y aceptación.
• La cookie web de producción requiere que web y BFF compartan sitio.
• Frontend ya presenta evidencia CI; móvil todavía no.
• El workflow de release integrada de plataforma sigue pendiente.
• Los videos ya están publicados y enlazados; deben mantenerse accesibles durante el periodo de evaluación.

9. Enlaces oficiales del proyecto

Recurso	Enlace
Repositorio integrador y de infraestructura	sport-app-platform
Repositorio backend	sport-app-backend
Repositorio frontend web	sport-app-frontend
Repositorio móvil	sport-app-movil
Tablero de actividades	SportApp Platform — GitHub Project
Wiki del proyecto	SportApp Platform Wiki
Versión web de esta entrega	Entrega de la semana 1

Volver a Entregas semanales