validacion rubrica semana 3 trazabilidad - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub Wiki

Validación Semana 3 vs. Rúbrica oficial (100 puntos) — Trazabilidad a la wiki

Fecha: 2026-08-23 Fuente de la rúbrica: files/Rúbricas Proyecto 1 v5.pdf, página 3, sección "SEMANA 3". Complementa (no reemplaza) files/validacion-SOLV_epics_HUs_semana-3.md, que valida en detalle el CSV de importación a Jira.

Nota importante: el texto de criterios que se compartió para esta validación (agrupado en 6 bloques con puntajes 30/40/6/4/10/10) no coincide literalmente con la rúbrica oficial del PDF. La oficial trae 6 bloques que suman 100 así: 20 + 50 + 6 + 4 + 10 + 10 = 100. La diferencia relevante es el ítem 2: el PDF lo abre en 4 sub-criterios (incluyendo uno explícito de 15 puntos por "detallar las historias de arquitectura", que el texto compartido no menciona) y vale 50 puntos en total, no 40. Esta validación usa el PDF como fuente de verdad y evalúa igual los 4 sub-criterios.


Resumen ejecutivo

# Ítem rúbrica Puntos Estado Observación
1 Hoja de trabajo — escenarios de calidad (≥2 por requisito) 20 ✅ Cumple 6 atributos, 42 escenarios, 2–11 por requisito
2a HU web y móvil 15 ✅ Cumple 89 HU con labels web/mobile
2b Detalle de historias de arquitectura 15 ✅ Cumple HA-01–HA-31 con escenario EC-* + plantilla COMO/CUANDO/DADO/QUIERO/PARA
2c Priorización según importancia 10 ✅ Cumple 5 olas, criterio ASR→recorrido→INVEST, mapeo a Jira Priority
2d Capacidad del grupo en puntos de historia/semana 10 ✅ Cumple Velocidad-Equipo.md: 12 pts/sprint (recién corregido de 132)
3a Componentes a probar 2 ✅ Cumple 7 capacidades de negocio → microservicios
3b Alcance de pruebas (unitarias/módulo/integrales) 2 ✅ Cumple Tabla TNT completa
3c Tipos de pruebas (manual/auto/rendimiento/usabilidad/seguridad/i18n) 2 ✅ Cumple Añadido PL-01 (internacionalización) en Sec. 3.6
4a Framework para pruebas 1 ✅ Cumple E2E, integración/contrato, rendimiento, VRT, i18n
4b Framework componente web (test + i18n) 1 ✅ Cumple Cucumber/Karma + @angular/localize/ngx-translate
4c Framework componente móvil (test + i18n) 1 ✅ Cumple JUnit/Compose + recursos por locale (strings.xml)
4d Ambiente cloud backend + herramientas de test 1 ✅ Cumple AWS + Terraform, ambiente acotado y destructible definido en Sec. 4.4
5 Plan de trabajo y tablero actualizado (Jira) 10 ✅ Cumple Boards SOLV y SA enlazados y activos
6 Video con evidencias 10 ❓ Pendiente No verificable desde el repo/wiki

Total verificable ya cubierto: ~90/90 puntos (todo salvo el video, que es evidencia externa). El vacío de internacionalización (i18n) señalado en la primera pasada ya se cerró: se agregó el experimento PL-01 (Sec. 3.6 de Estrategia-de-pruebas.md) con caso concreto de moneda/fecha/textos por locale, y se referenció el framework de i18n en 4.1, 4.2 y 4.3. El vacío de ambiente cloud (4d) también se cerró: se definió proveedor (AWS), cómputo, red, BD, aprovisionamiento IaC y herramienta de carga en Sec. 4.4. Pendiente de revisión y commit por el equipo antes de darlo por cerrado.


Detalle punto por punto

1. Hoja de trabajo — escenarios de calidad (20 pts)

"Se incluyen al menos dos escenarios de calidad por cada requisito definido"

Ubicación: Hoja-de-trabajo.md — sección "Requisitos de calidad" (6.1 a 6.6).

Verificado por atributo:

Atributo Sección Requisitos (sub-secciones) Escenarios
6.1 Latencia enlace 6 11 (EC-LAT-01…11)
6.2 Escalabilidad enlace 3 5 (EC-ESC-01…05)
6.3 Disponibilidad enlace 4 9 (EC-DISP-01…09)
6.4 Seguridad enlace 4 8 (EC-SEG-01…08)
6.5 Facilidad de modificación enlace 3 5 (EC-MOD-01…05)
6.6 Facilidad de integración enlace 3 4 (EC-INT-01…04)

Cada requisito (p. ej. "Cotización embebida", "Journeys críticos") tiene mínimo 2 escenarios con fuente/estímulo/artefacto/ambiente/respuesta/medida/prioridad. Cumple con holgura.


2a. HU web y móvil (15 pts)

Ubicación: Backlog-refinado-semana-3.md — sección "Historias de usuario (SOLV)", épicas E1–E7.

Cumple.


2b. Detalle de historias de arquitectura (15 pts)

Ubicación: Backlog-refinado-semana-3.md — sección "Historias de arquitectura (SBA)".

Cumple. Este sub-criterio (15 pts, el más pesado del bloque 2) no estaba cubierto por la validación previa del CSV (que lo marcó explícitamente fuera de alcance) ni mencionado en el texto de criterios que se compartió — pero sí existe y está completo en la wiki.


2c. Priorización según importancia (10 pts)

Ubicación: Backlog-refinado-semana-3.md — sección "Priorización".

  • Criterios en cascada: (1) ASR de latencia/escalabilidad en alcance, (2) recorridos críticos §5.1, (3) dependencias INVEST.
  • Tabla de 5 olas con mapeo directo a prioridad Jira (Highest…Lowest) y story points por ola.
  • Verificado al 100% contra el CSV importado en files/validacion-SOLV_epics_HUs_semana-3.md (sección 5): 0 desviaciones entre ola documentada y Priority en Jira.

Cumple.


2d. Capacidad del grupo en puntos de historia por semana (10 pts)

Ubicación: Velocidad-Equipo.md y files/Jira_import_23_ago_26_semana_3/historia-base-y-velocidad-equipo.md.

  • HU base (HU-6, 5 pts, 12 h) calibra horas/punto = 2.4.
  • Velocidad del sprint calculada con capacidad real del equipo (4 desarrolladores × 12 h/semana × 1 semana − 18 h transversales) = 12 puntos de historia por sprint.
  • El archivo de feedback documenta la corrección de un error previo (132 pts, calculado sobre 7 semanas en vez de 1) y la reconciliación con el total del backlog (89 HU, ~218 SP de MVP, 7 sprints × ~12 pts ≈ 84 pts — señal de que el alcance del MVP puede exceder la capacidad y debe revisarse).

Cumple.


3. Documento de estrategia de pruebas (6 pts)

Ubicación: Estrategia-de-pruebas.md.

  • 3a. Componentes a probar (2 pts): sección 1.4 — 7 capacidades de negocio mapeadas a microservicios (ms-cotizacion, ms-suscripcion, ms-polizas, etc.). ✅
  • 3b. Alcance de pruebas — unitarias/módulo/integrales (2 pts): sección 2, tabla TNT en 2.4. ✅
  • 3c. Tipos de pruebas — manuales/automáticas/rendimiento/usabilidad/seguridad/internacionalización (2 pts): sección 3. Cubre manuales (exploratorias), automáticas, rendimiento (PR-01…03), usabilidad (PD-03, GUI), seguridad (PS-01/02) e internacionalización (PL-01, Sec. 3.6). ✅ Cerrado — pendiente de revisión del equipo.

4. Definición de frameworks y ambientes (4 pts)

Ubicación: Estrategia-de-pruebas.md — sección 4.

  • 4a. Framework para pruebas (1 pt): 4.1 — Cucumber/Gherkin (web E2E), JUnit Compose (móvil E2E), PyTest+Pact (contrato), K6/JMeter (rendimiento), Resemble.js/BackstopJS (VRT). ✅
  • 4b. Framework componente web, alineado con test e i18n (1 pt): 4.2 — Cucumber + Karma sobre AngularJS/TypeScript, más @angular/localize/ngx-translate como framework de i18n verificado con Karma. ✅ Cerrado — pendiente de revisión del equipo.
  • 4c. Framework componente móvil, alineado con test e i18n (1 pt): 4.3 — JUnit + Compose UI Test sobre Kotlin, más recursos por locale (strings.xml/plurals.xml) verificados forzando LocalConfiguration en Compose UI Test. ✅ Cerrado — pendiente de revisión del equipo.
  • 4d. Ambiente cloud backend + herramientas de test (1 pt): 4.4 — proveedor AWS (coherente con la fortaleza Terraform/AWS del equipo y con HU-78), ambiente de HU-89 definido como ECS Fargate/EC2 t3.medium autoescalado 1→4 nodos, VPC dedicada, RDS db.t3.micro o BD efímera, 100 % IaC destructible, créditos académicos como fuente de costo, y K6/JMeter contra ms-cotizacion como herramienta de carga. ✅ Cerrado — pendiente de revisión del equipo.

Recomendación restante: ninguna sobre el diseño; queda ejecutar y capturar la evidencia real (autoescalado, resultados de K6) en HU-89 en el tablero SOLV antes del showcase.


5. Plan de trabajo y tablero actualizado (10 pts)

Cumple, sujeto a que ambos tableros reflejen el estado real al momento de la entrega (verificación fuera del alcance de este análisis de archivos).


6. Video con evidencias (10 pts)

No hay forma de verificar esto desde el repositorio/wiki. El _Sidebar.md tiene un placeholder ("🎥 Showcase — Video con evidencias") sin enlace. Pendiente de entrega y de enlazar en la wiki.


Brechas priorizadas para cerrar antes de entregar

  1. Internacionalización como tipo de prueba (3c, 4b, 4c) — Cerrado. Se agregó el experimento PL-01 en Estrategia-de-pruebas.md (nueva Sec. 3.6, entrada en la tabla de la Sec. 3, referencia en 2.1 Objetivos y en 4.1/4.2/4.3).
  2. Ambiente cloud backend (4d) — Cerrado. Sec. 4.4 ahora define AWS + Terraform, ECS Fargate/EC2 autoescalado, VPC dedicada, RDS/BD efímera, IaC destructible y K6/JMeter, coherente con HU-89 y HU-78.
  3. Video con evidencias (6 — 10 pts): grabar y enlazar en _Sidebar.md. Único punto que sigue pendiente.

Falta que el equipo revise el diff completo y lo comitee/pushee.

Todo lo demás (escenarios de calidad, HU web/móvil, historias de arquitectura, priorización, capacidad del equipo, componentes/alcance de pruebas, framework de pruebas, tablero) está cubierto con evidencia trazable en la wiki.


Cambios aplicados en esta pasada (sin commitear)

Archivo modificado: Estrategia-de-pruebas.md. Resumen del diff:

  • Sec. 1.4 (tabla de componentes/experimentos): nueva fila para el cliente web/móvil → PL-01.

  • Sec. 2.1 (Objetivos): nuevo bullet sobre localización de texto/moneda/fecha, ligado al Objetivo 3 de expansión regional.

  • Sec. 3 (tabla de tipos de prueba): nueva fila PL-01 | Internacionalización | ... | Automáticas (i18n).

  • Sec. 3.6 (nueva) "Pruebas de internacionalización (i18n / l10n)": experimento PL-01 completo (historias asociadas, objetivo, precondiciones, estímulo, respuesta esperada/medida, tecnologías, interpretación, esfuerzo — 3 h, John Guerrero).

  • Sec. 4.1 (Framework para pruebas): nuevo bloque "5. Pruebas de Internacionalización (i18n / l10n)".

  • Sec. 4.2 (Framework web): nueva línea "Internacionalización" con @angular/localize/ngx-translate.

  • Sec. 4.3 (Framework móvil): nueva línea "Internacionalización" con recursos por locale de Android.

  • Sec. 2.5 (distribución de esfuerzo): la fila "Pruebas de GUI (web; paridad móvil si hay consulta de oferta)" de John Guerrero se recortó de 6 h a 3 h, y se agregó una fila nueva "Experimento PL-01 (internacionalización)" con 3 h. Se eligió recortar GUI porque es la única tarea condicionada ("si aplica") de su fila y porque Martin Romero ya tiene su propia línea de GUI (6 h, "paridad core web/móvil + nativas + back-office") que cubre ese mismo criterio de rúbrica de forma redundante.

  • Sec. 4.4 (Ambiente cloud para backend, herramientas de test): reemplazado el texto "pendiente de implementación" por una definición cerrada — proveedor AWS, cómputo (ECS Fargate/EC2 t3.medium autoescalado 1→4), red (VPC dedicada vía Terraform), BD (RDS db.t3.micro o efímera), aprovisionamiento 100 % IaC destructible, costo en créditos académicos, y herramienta de carga K6/JMeter apuntando a ms-cotizacion para PR-01/PR-02/PR-03. Referencia cruzada a HU-78, HU-89 y HA-10.

El total de John Guerrero se mantiene en 64 h y el gran total en 256 h (18.116.864 COP) — el presupuesto de la Sec. 2.3.1 no cambió porque no varió ni el total de horas ni el recurso. La Sec. 4.4 no tiene impacto en el presupuesto de horas (es una decisión de diseño de ambiente, no una tarea nueva de esfuerzo).

⚠️ **GitHub.com Fallback** ⚠️