Calidad de Software · 3.8.2.21 · 2026-II

OLA

Observatorio Litoral de Anomalías térmicas

Hito 1: planificación, catálogo de requisitos, infraestructura y diseño de interfaces.

Universidad: La Salle · Arequipa
Docente: Maribel Molina Barriga
Semana del Hito 1: 12 al 17 de octubre de 2026

Equipo y orden de exposición

1
Piero Adrian Delgado ChipanaDevelopment Team · Tema y próximos pasos
2
Jorge Luis Ortiz CastañedaScrum Master y QA · Planificación
3
Miguel Angel Flores LeonProduct Owner · Catálogo de requisitos y calidad
4
Frederick Dicarlo Mares GraosDevelopment Team · Infraestructura y rendimiento
5
Jhordan Steven Octavio Huamani HuamaniDevelopment Team · Diseño de interfaces y avance

El problema

Un dato público que no llegaba a quien lo necesita

10

laboratorios costeros de IMARPE miden a diario la anomalía de la temperatura superficial del mar (ATSM).

125,701

filas desde 1970 en un CSV de datos abiertos: sin clasificar, con huecos y con retraso.

US$ 3,100 M

en pérdidas y 1.1 millones de personas afectadas por El Niño Costero de 2017.

Qué hace OLA

Traduce el dato al lenguaje de la costa, para el pescador artesanal que consulta desde el celular.

Cálido Neutro Frío Sin datos recientes

Clasifica cada zona: promedio de 5 días, umbral de ±0.5 °C.
Detecta anomalías sostenidas y avisa por correo y en la aplicación.
Mapa, histórico, comparación y proyección de 3 a 7 días.
App Android con lectura sin conexión; push desde la fase 4.

No reemplaza los boletines de IMARPE ni pronostica El Niño: esa función es del ENFEN.

Inicio de OLA en el celular: último dato de IMARPE, alertas, zonas por estado y mapa

Planificación · Cronograma

8 sprints, del 24 de agosto al 7 de diciembre

Cronograma de Jira por meses: las 11 épicas sobre los sprints 0 a 7, de agosto a diciembre — Línea de tiempo de Jira: cada épica abarca los sprints de sus historias; la línea azul marca el 11 de octubre, día de la captura.

Sprint	Fechas	Objetivo	Pts
S0	24–31 ago	Tema y repositorio	3
S1	1–14 sep	Web con los 8 RF, catálogo y plan de calidad	78
S2	15–28 sep	Despliegue en el VPS y fases 1 a 3 de la app	30
S3	29 sep–12 oct	Laboratorio 2 y entrega del Hito 1	15
	Hito 1 · Evidencia 2 · 12 oct
S4	13–26 oct	Exposición, integración a main y calidad	49
S5	27 oct–9 nov	Fase 4 de la app: push de extremo a extremo	52
S6	10–23 nov	Fase 5 de la app y revisión de pruebas	48
S7	24 nov–7 dic	Fase 6 de la app y entrega del Hito 2	36
	Hito 2 · Evidencia 4 · 7 dic

Planificación · Habemus QA

El plan vive en Jira, con tarjetas para todo el equipo

Tablero del Sprint 3 en Jira: cuatro tarjetas en curso y el Laboratorio 2 terminado — Tablero del Sprint 3 el 11 de octubre: la entrega del Hito 1 y las ceremonias en curso; el Laboratorio 2, terminado con sus 5 subtareas.

Backlog de Jira con los sprints 3 a 7, sus fechas, actividades y puntos, y el primer riesgo del backlog — Backlog: los sprints 4 a 7 ya tienen fechas, actividades y puntos; los 8 riesgos del plan de calidad viven como tarjetas.

377tarjetas

11épicas

8sprints

311puntos de historia

40 hpor integrante en cada sprint, del 4 al 7

Planificación · Del plan a la tarea

Cada historia baja a subtareas con un solo responsable

Historia SCRUM-132 Exponer el Hito 1: criterios de aceptación, ocho subtareas con responsable, Sprint 4 y 3 puntos

Subtareas terminadas por integrante, sprints 0 a 3 · más 1 de todo el equipo: la lluvia de ideas

Jhordan21

Frederick18

Jorge17

Piero17

Miguel15

Definición de listo

Criterios de aceptación que se pueden verificar
Puntos en historias y tareas; horas en cada subtarea
Un responsable por subtarea
Maqueta aprobada por el PO si es una pantalla nueva
Sin dependencias abiertas de otro sprint

Definición de hecho

Pasan las pruebas de las capas que toca
mypy, ruff, tsc y ESLint sin errores
Cobertura sobre el mínimo de cada capa
axe sin violaciones serias ni críticas
Sin defectos críticos abiertos
Sin secretos en el diff
SRS, trazabilidad, defectos y riesgos al día
Revisada por otra persona y aceptada por el PO

Catálogo de requisitos · SRS 1.8

9 requisitos funcionales, cada uno con su evidencia

ID	Requisito	Dificultad	Sprint	Estado
RF-01	Detección de anomalía térmica sostenida	Alta	Sprint 1	Verificado
RF-02	Proyección de tendencia a corto plazo	Alta	Sprint 1	Verificado
RF-03	Notificación automáticaPush en la app: SRS 1.7	Alta	Sprint 1push: Sprint 5	Verificadocorreo y aviso en la app
RF-04	Mapa interactivo de estado por zona	Media	Sprint 1	Verificado
RF-05	Gráficos históricos por laboratorio	Media	Sprint 1	Verificado
RF-06	Comparación entre laboratorios costeros	Media	Sprint 1	Verificado
RF-07	Registro y autenticación de usuariosRecuperación de contraseña: SRS 1.8	Baja	Sprint 1recuperación: Sprint 2	Verificado
RF-08	Importación y actualización del dataset ATSM	Baja	Sprint 1	Verificado
RF-09	Aplicación móvil AndroidNuevo en la SRS 1.7	Alta	Sprints 1 y 2fases 4 a 6: sprints 5 a 7	Fases 0 a 3 de 6

28requisitos no funcionalesRNF-01 a RNF-28

18reglas de negocioRN-01 a RN-18

14casos de usoUC-01 a UC-14

Atributos de cada requisito · ISO/IEC/IEEE 29148

IdentificadorEnunciadoJustificaciónFuentePrioridadDificultadRiesgoEstabilidadDependenciasMétodo de verificaciónCriterios de aceptaciónEstado

Criterio de aceptación de ejemplo

CA-01.1 Dado una serie con 5 registros cálidos consecutivos, cuando se evalúa, entonces se registra un episodio; con 4 registros, no.

CA-01.3 Dado una anomalía de exactamente +0.5 °C, entonces se clasifica como neutra.

Catálogo de requisitos · Modelo y cambios

Casos de uso y control de cambios del catálogo

Versiones de la SRS: cada cambio con fecha, motivo y responsable

1.010 sepLínea base del catálogo
1.110 sepSección de control de versiones
1.210 sepRF-08: solo carga manual; filas inválidas y reimportación
1.310 sepRF-01 y RF-04: rachas con huecos y fecha tomada del dato
1.410 sepRF-05 y RF-06: agrupado según el rango y hasta 4 zonas
1.510 sepRF-02: los dos modelos y su indicador de confianza
1.610 sepRF-03: sin SMS; aviso de fin de episodio y reintentos
1.714 sepRF-09 nuevo: app Android; push en RF-03
1.827 sepRF-07: recuperación de contraseña y duración de la sesión

Trazabilidad de punta a punta · ejemplo: RF-08

RF→código→pruebas→historia y sprint en Jira

Código: domain/csv_parser.py · services/import_service.py
Pruebas: 46 unitarias · 30 de integración · 9 de la web · 8 E2E
Jira: «RF-08: Importar y actualizar el dataset ATSM», Sprint 1
Resultado: 125,701 filas en 11.8 s; el límite es 2 min para un año de datos

Calidad · Al cerrar la fase 3 de la app (28 de septiembre)

1,302 pruebas automatizadas y ningún defecto en producción

Pruebas por suite

Backend · unitarias225 Backend · integración263 Paquete compartido165 Web · Vitest253 E2E · Playwright171 Rendimiento2 Herramientas de calidad8 App · Jest198 App · Maestro17

Total1,302

Cobertura de sentencias

Backend95 %

Paquete compartido97.7 %

Web90.4 %

App móvil95.9 %

mínimoobjetivodel plan SQA

Defectos encontrados y corregidos

33

en 14.2 KLOC: 2.32 por KLOC.
0 llegaron a un usuario.

Crítica 1Alta 12Media 16Baja 4

Dónde se detectaron

En pruebas E2E11 En revisión de capturas, configuración o código7 Al construir o desplegar6 En pruebas unitarias5 En pruebas de integración4

Cada uno queda en defectos.md con su etapa, RF, severidad, detección, corrección y horas.

Infraestructura · Producción

Un VPS con Dokploy y un solo dominio con HTTPS

Producción · compose.prod.yml

dbapiweb

Sin puertos publicados: Traefik enruta por dominio
Imágenes construidas en su etapa de producción
La API se niega a arrancar con un secreto débil o de plantilla

Desarrollo y pruebas · compose.yml

dbapiwebmailpite2euptime-kumacalidad

Mailpit recibe los correos sin enviarlos
Playwright prueba contra el stack completo
Mapa base: OpenStreetMap en la web y OpenFreeMap en la app

Arranque ordenado

La API espera a que PostgreSQL pase su chequeo, pg_isready, y los tres servicios se reinician solos

Un solo dominio, sin CORS

La web pide la API en su mismo dominio, bajo /api

Migraciones al arrancar

Un bloqueo de PostgreSQL evita que dos réplicas las apliquen a la vez

Infraestructura · Configuración en Dokploy

Dokploy despliega compose.prod.yml: un dominio, dos rutas

Dokploy, pestaña Domains: web y api con el host olachilindrina.wayrasimi.tech; web con Path / y puerto 80, api con Path /api y puerto 8000, ambos con HTTPS y certificado de Let's Encrypt — Domains: el mismo host para los dos; la web en /, puerto 80, y la API en /api, puerto 8000, con HTTPS de Let's Encrypt. Se configuran aquí y no con etiquetas en el compose (defecto D-22).

Dokploy, pestaña General: repositorio Proyecto_Calidad_de_Software, rama deploy, Compose Path ./compose.prod.yml y Trigger Type On Push — General: GitHub, rama deploy y ./compose.prod.yml. Con «On Push», cada push a esa rama se despliega solo.

Dokploy, historial de despliegues terminados; el 7 es «fix(deploy): servir la API bajo /api en el mismo dominio» — Deployments: cada despliegue queda con su commit; el n.º 7 llevó la API a /api en el mismo dominio.

# compose.prod.yml · extracto # Web y API comparten un mismo dominio y se separan por ruta: # - web -> Path /, puerto 80 # - api -> Path /api, puerto 8000, Internal Path / y Strip Path apagado services: db: image: postgres:17-alpine api: build: context: ./backend target: production depends_on: db: condition: service_healthy web: build: context: ./frontend target: production

Infraestructura · Rendimiento y disponibilidad

Lo medido usa menos de un tercio de lo que permite la SRS

RequisitoLímiteMedidoUso del límiteEstado

El mapa web muestra las 10 zonasSRS 3.3 · mediana de 3 cargas en frío con 4G simulado, en Playwright

≤ 3 s

0.88 s

29 % del límite

Cumple

La app muestra el estado de las 10 zonasSRS 3.3 · mediana de 5 arranques en frío en un Galaxy A56; el peor, 0.84 s

≤ 5 s

0.81 s

16 % del límite

Cumple

Importar el dataset de IMARPESRS 3.3 · el límite es para 1 año, unas 3,650 filas; medimos los 56 años

≤ 2 min

11.8 s125,701 filas

10 % del límite

Cumple

Disponibilidad del backend en el VPSSRS 3.5 · Uptime Kuma, 1,420 chequeos del 22 al 28 de septiembre

≥ 95 %

98.80 %

24 % de la caída permitida: 1.20 % de 5 %

Cumple

50 usuarios concurrentes sin degradaciónSRS 3.3 · referencial para el curso

50 usuarios

—

se mide con la prueba de carga del Sprint 4

Pendiente

Uptime Kuma corre en el equipo de desarrollo y consulta /api/health/ready cada minuto: con el equipo apagado no hay chequeos y ese tiempo no cuenta. Las caídas del periodo son del 22 y 23 de septiembre; parte fueron del propio equipo que mide, saturado por una compilación.

Diseño de interfaces · Guía de diseño

Móvil primero, lo urgente arriba y nunca solo color

Principios

Móvil primeroEl pescador entra desde el celular, a veces al sol: se diseña a 360–412 px y se amplía.
Lo urgente arribaPrimero, de cuándo es el dato y qué zonas están en alerta; después, el detalle.
Nunca solo colorCada estado se comunica con color, símbolo y nombre a la vez.
Lenguaje de la costa«Sobre lo normal», no «anomalía positiva».
Una sola vista a la vezTarjetas o tabla, hoja o panel: el lector de pantalla no lee nada dos veces.

Color · tema.css

abisal#0a2530

espuma#f3f7f5

dorado#e8b84b

marea#1f6f80

tinta tenue#465b62

borde#d3dfdd

Todo texto cumple 4.5:1 sobre su fondo; estados e iconos, 3:1. Un color fuera del sistema no compila.

Estados térmicos · paleta.ts

Cálidoflecha arriba#d4643a Neutroraya#9a8650 Fríoflecha abajo#2b94a8 Sin datoscírculo punteado#75878c

paleta.test.ts comprueba el contraste de cada estado.

Tipografía

Space Grotesktítulos

Intertexto

31/07/2026 · +5.91 °Ccifras y fechas

Forma y accesibilidad

Objetivos táctiles de 44 px como mínimo; las pestañas inferiores miden 56 px
Bordes antes que sombras: la sombra queda para lo que flota
WCAG 2.2 AA: axe corre en las pruebas unitarias y E2E, y una violación seria o crítica hace fallar la suite
«+1.58 °C» lleva espacio duro: nunca se parte en dos líneas

Diseño de interfaces · Pantallas web rediseñadas

El inicio se adapta: panel lateral o hoja inferior

Inicio en escritorio: banda con la navegación, resumen del estado, mapa y detalle de Callao en el panel lateral

Inicio en el celular con la barra inferior de navegación — Inicio en el celular

Detalle de Callao en una hoja inferior en el celular — Detalle de una zona

1La banda: el dorado marca la pantalla activa y «Entrar».
2Lo urgente arriba: fecha del dato, alertas y zonas por estado, que hacen de leyenda.
3Mapa en gris: el color queda solo para los estados.
4Desde 1024 px, el detalle va en un panel lateral.
5Bajo 768 px, barra inferior con pestañas de 56 px.
6Bajo 1024 px, el detalle sube en una hoja que se cierra con ✕, Escape o deslizando.

Diseño de interfaces · App Android y avance

La app Android sigue la misma guía y ya cerró las fases 0 a 3

App: pestaña Mapa con el resumen, las 8 zonas en alerta y el mapa — Pestaña Mapa: resumen, alertas con nombre y mapa de toda la costa.

App: aviso «Usa dos dedos para mover el mapa» — Un dedo desplaza la pantalla; el mapa se mueve con dos.

App: Mis zonas de interés con un interruptor por zona — Mis zonas: toda la fila, de 64 dp, es el interruptor.

App: Iniciar sesión con el teclado abierto — Entrar: con el teclado abierto, el campo y el botón siguen a la vista.

Qué funciona hoy

Web con los 8 RF, en producción con HTTPS
App: marco, pestaña Mapa con lectura sin conexión, cuenta, recuperación de contraseña y zonas de interés
La app muestra el estado en 0.81 s (límite: 5 s)
Web y app comparten la API, la paleta y los textos

Lo que falta para el Hito 2

Fase 4: avisos push de extremo a extremo
Fase 5: histórico, comparación y proyección en la app
Fase 6: APK de entrega

Próximos pasos

Del Hito 1 al Hito 2: sprints 4 a 7

Sprint 413–26 oct

Exponer el Hito 1, integrar las ramas a main y cerrar los pendientes de calidad

Integrar las ramas de la app y del despliegue a main
Respaldo y restauración de la base verificados
Integración continua con GitHub Actions
Prueba de carga con 50 usuarios concurrentes
SonarQube y OWASP ZAP

Sprint 527 oct–9 nov

Fase 4 de la app: notificaciones push de extremo a extremo

Registrar el dispositivo para recibir avisos push
Enviar el push al empezar y al terminar un episodio
Pruebas de usabilidad con usuarios
Pruebas de mutación del dominio con mutmut
Artículo IEEE: introducción y metodología

Sprint 610–23 nov

Fase 5 de la app y revisión de pruebas de todos los requisitos

Histórico, comparación y proyección en la app
Revisión de pruebas de todos los requisitos
Pruebas de contrato de la API con Schemathesis
Manuales de usuario de la web y de la app
Artículo IEEE: resultados y conclusiones

Sprint 724 nov–7 dic

Fase 6 de la app y entrega del Hito 2

APK de entrega
Artículo IEEE final
Presentación final y video demostrativo
Prototipo funcional y repositorio con README
Evidencia 4 del Hito 2: 7 de diciembre

Gracias. ¿Preguntas?

Jiraola-ulasalle.atlassian.net

Sistemaolachilindrina.wayrasimi.tech

Repositoriogithub.com/Miguel777-rgb/Proyecto_Calidad_de_Software