validacion rubrica semana 3 trazabilidad - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub 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.
| # | Í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.
"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.
Ubicación: Backlog-refinado-semana-3.md — sección "Historias de usuario (SOLV)", épicas E1–E7.
- 89 HU (HU-1…HU-89), cada una con label de plataforma (
web/mobile/api/core/devops) y de alcance (mvp/post-mvp). - 30 ocurrencias del label
web, 39 demobileen el documento. - Tabla de recorridos críticos con HU específica por canal en
Estrategia-de-pruebas.md(ej. HU-10 web / HU-11 móvil para cotización). - Importación formal a Jira validada estructuralmente en
files/validacion-SOLV_epics_HUs_semana-3.md. - Tablero Jira (épicas + HU): https://uniandes-team-proyecto.atlassian.net/jira/software/projects/SOLV/boards/1/backlog?epics=visible
Cumple.
Ubicación: Backlog-refinado-semana-3.md — sección "Historias de arquitectura (SBA)".
- Catálogo HA-01–HA-31, agrupado por atributo: Latencia, Escalabilidad, Disponibilidad, Seguridad, Modificabilidad, Integrabilidad.
- Cada HA trae: Summary, Story Points, y el escenario
EC-*completo (fuente, estímulo, artefacto, ambiente, respuesta, medida, prioridad) más la narrativa arquitectónica en plantilla COMO/CUANDO/DADO QUE/QUIERO QUE/PARA/ESTO DEBE SUCEDER. - Tabla de trazabilidad HA → HU que ancla cada HA a las HU de producto que habilita.
- Importadas a Jira como tipo "Historia de Arquitectura": https://uniandes-team-proyecto.atlassian.net/jira/software/projects/SOLV/list/VRpONxy?jql=project%20%3D%20SOLV%20AND%20labels%20%3D%20ha%20ORDER%20BY%20cf%5B10019%5D%20ASC
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.
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 yPriorityen Jira.
Cumple.
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.
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.
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-translatecomo 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 forzandoLocalConfigurationen 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.mediumautoescalado 1→4 nodos, VPC dedicada, RDSdb.t3.microo BD efímera, 100 % IaC destructible, créditos académicos como fuente de costo, y K6/JMeter contrams-cotizacioncomo 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.
- Tablero de producto (SOLV — épicas + HU + HA): https://uniandes-team-proyecto.atlassian.net/jira/software/projects/SOLV/boards/1/backlog?epics=visible
- Tablero de entregables (SA — sprint del curso): https://uniandes-team-proyecto.atlassian.net/jira/software/projects/SA/boards/2?filter=Sprint%20%3D%204&groupBy=none
- Enlazado en
_Sidebar.mdbajo "Semana 3 → Plan de trabajo y tablero".
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).
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.
-
Internacionalización como tipo de prueba (3c, 4b, 4c)— Cerrado. Se agregó el experimento PL-01 enEstrategia-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). -
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. -
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.
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.mediumautoescalado 1→4), red (VPC dedicada vía Terraform), BD (RDSdb.t3.microo efímera), aprovisionamiento 100 % IaC destructible, costo en créditos académicos, y herramienta de carga K6/JMeter apuntando ams-cotizacionpara 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).