Backlog refinado semana 3 - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub Wiki
Esquema de épicas o features para a Jira en la semana 3. Jerarquía Épico → Historia de usuario. El canal (web, móvil, API, núcleo, DevOps) va en labels.
Caso: files/MISW4501-202614-Proyecto.pdf §§2.3, 2.4, 5.1–5.2. Inventario histórico (E1–E8 por canal): Backlog Jira.
El MVP cubre los seis recorridos críticos del PDF §5.1 (extremo a extremo; pueden ser delgados). Lo que no es un recorrido §5.1 (mapa, biometría, offline, tableros, SAST…) queda post-mvp (§5.2 u operación). La cola de implementación no es 1→6: el equipo decidió trabajar con los ASR de latencia y escalabilidad; la priorización (olas 1–5) ordena por esos ASR y relaciona cada HA con las HU del slice.
Terceros en stub: Open Finance / Open Data, pasarela, firma, KYC, eventos paramétricos, mapas, push y reportes a regulador/reaseguradora se simulan detrás de un adaptador (PDF §4). Las HU describen el contrato de Solventa (qué hace el recorrido), no el JSON, los campos ni los códigos de respuesta del proveedor. Un stub con ok / fallo / lento basta para estimar y probar.
| Dónde | Formato | Ejemplo |
|---|---|---|
| Épico · ID estable | E#-{Name} |
E1-Cotizacion-embebida |
| Épico · Summary en Jira | E# · {Name} |
E1 · Cotización embebida |
| Historia · ID estable | HU-# |
HU-4 |
| Historia · Summary en Jira | HU - #. {Name} |
HU - 4. Calcular prima con reglas |
| Historia de arquitectura · ID | HA-## |
HA-01 |
| Historia de arquitectura · Summary en Jira | HA-## - {Name} |
HA-01 - Presupuesto de latencia de la cotización embebida en operación normal |
| Clave Jira (después del import) |
SOLV-# / SBA-#
|
La asigna Jira; no se usa como ID de catálogo |
Un épico puede tener historias en varios canales. Cada historia lleva al menos un label de plataforma y un label de alcance.
| Grupo | Label | Uso |
|---|---|---|
| Plataforma | web |
Cliente escritorio (asesor, operaciones, socio) — PDF §5.2 |
| Plataforma | mobile |
App del asegurado — PDF §5.2 |
| Plataforma | api |
Contrato embebido / BFF / gateway — PDF §2.3 Distribución y socios; §5.2 implicación BFF |
| Plataforma | core |
Motor de rating, suscripción, póliza, siniestro (sin UI) |
| Plataforma | devops |
Repos, nube, evidencia de carga, harness y ambientes de prueba |
| Alcance | mvp |
Los seis recorridos PDF §5.1 (y enablers que los sostienen) |
| Alcance | post-mvp |
Fuera de §5.1: extras de canal §5.2, calidad posterior, panel de socios |
Columna SP = campo Jira Story point estimate. Fibonacci 1 · 2 · 3 · 5 · 8 (se evita 13: partir la historia). No son horas; son esfuerzo relativo para este equipo.
| Integrante | Fortalezas |
|---|---|
| Mauricio | Backend Java y Python, testing, cloud, Terraform, AWS |
| Juan | Full stack Python y React, cloud, Terraform, AWS |
| Martin | Backend Python, frontend, cloud, Terraform, AWS |
| John | Backend Python, frontend AngularJS, móvil Android (Kotlin/Jetpack) e iOS (Swift), cloud engineering, GCP, testing móvil/Python/web |
Cuatro seniors sobre el stack principal. Cobertura fuerte en Python, cloud IaC y testing; el canal móvil nativo tiene bus factor 1 (John).
| SP | Qué significa aquí |
|---|---|
| 1 | Trivial (≤ medio día): contrato mínimo, clone de un patrón ya hecho |
| 2 | Pequeño (~1 día): CRUD o stub acotado, harness conocido |
| 3 | Mediano (1–2 días): dominio + persistencia o una pantalla de canal |
| 5 | Grande (2–3 días): motor, BFF, IaC, carga, o UI móvil no trivial |
| 8 | Complejo o cuello de especialidad: E2E dual, 50k cot/min, 1M eventos, biometría/offline, multi-AZ |
Las HA no se implementan como producto; su SP es diseño del experimento, corrida, análisis y nota de arquitectura. No sumar HU+HA a la velocidad de producto.
El MVP son los seis recorridos PDF §5.1 (olas 1–4, label mvp). Total HU MVP: 218 SP. Ola 5 es post-mvp y no entra en este total.
| Corte | SP |
|---|---|
| HU ola 1 (cotización embebida + lab) | 52 |
| HU ola 2 (suscripción/emisión + perfilamiento) | 44 |
| HU ola 3 (siniestros, paramétrico, canales e identidad) | 104 |
| HU ola 4 (ciclo de vida de póliza) | 18 |
| HU MVP (olas 1–4) | 218 |
HU ola 5 (post-mvp, fuera del MVP) |
95 |
| HU catálogo completo | 313 |
| HA-01–HA-12 (spikes LAT/ESC que ordenan el MVP) | 50 |
| HA-13–HA-31 (fuera del corte de implementación actual) | 70 |
Siete épicos alineados a recorridos (§5.1) y capacidades (§2.3), no a canales. Los labels van en las historias; la columna Labels es el conjunto permitido en ese épico (plataforma + alcance).
| ID estable | Summary en Jira | Recorrido PDF §5.1 | Capacidades PDF §2.3 (y §2.4 si aplica) | Canal PDF §5.2 | Labels | Notas |
|---|---|---|---|---|---|---|
| E1-Cotizacion-embebida | E1 · Cotización embebida | 1. Cotización embebida: el socio pide precio desde su app; Solventa combina rating y señales y devuelve precio en tiempo real | Cotización y precio (rating); Distribución y socios (embedded) | API del socio + web (venta asistida) + móvil (ver precio) |
core api web mobile · mvp; factor OF en stub
|
Un núcleo; UIs son adaptadores |
| E2-Suscripcion-y-emision | E2 · Suscripción y emisión | 2. El cliente acepta; suscripción automática, cobro de prima, firma y emisión de póliza | Suscripción (underwriting); Emisión y gestión de pólizas (alta); Cobros, pagos y recaudo | Web (asesor) y móvil (cliente) sobre el mismo núcleo |
core web mobile · mvp (cobro y firma stub); pasarela real post-mvp
|
No se exige payload PCI ni firma legal del prestador |
| E3-Siniestro-asistido | E3 · Siniestro asistido | 3. El cliente reporta; se evalúa, se aprueba y se paga o se enruta a perito. 4. Evento externo dispara el pago sin intervención humana | Siniestros (claims) | Móvil (aviso, evidencia, paramétrico); web (operador) |
mobile web core · mvp (#3 y #4); evento, pago y aviso en stub; post-mvp (mapa stub, escaneo) |
Recorridos 3 y 4 |
| E4-Identidad-del-cliente | E4 · Identidad del cliente | Enabler de los recorridos móviles; consulta de póliza en 2 y 6 | Identidad, consentimiento y KYC | Móvil (onboarding, wallet) |
mobile web · mvp (alta mínima + consentimiento + ver póliza); post-mvp (biometría, offline) |
|
| E5-Perfilamiento-vida-hipotecario | E5 · Perfilamiento vida hipotecario | 5. Al originar un crédito de vivienda, perfil Open Data / Open Finance y oferta de vida hipotecario en el mismo flujo | Perfilamiento y personalización (Open Data); caso insignia §2.4 | API / núcleo; UI originador |
api core web mobile · mvp (consentimiento, stubs, perfil interno, degradación, UI) |
No se usa el API real del banco |
| E6-Ciclo-de-vida-de-poliza | E6 · Ciclo de vida de póliza | 6. Renovaciones, modificaciones, cancelaciones, reportes a regulador y reaseguradoras | Emisión y gestión de pólizas; Analítica y cumplimiento | Web (comandos); móvil (avisos) |
web mobile api · mvp (una HU por verbo); reportes y avisos en stub; post-mvp (autoservicio, orquestador, tableros) |
Extractos internos, no ACORD/SFC |
| E7-Plataforma-y-fundaciones | E7 · Plataforma y fundaciones | Enabler de 1–6 | Distribución y socios; autorización | BFF web y móvil — §5.2 |
api devops web core mobile · mvp (repos, Docker, BFF, JWT, RBAC, nube, carga, harness PyTest/Karma/JUnit, dobles, ambiente de experimentos, framework E2E); post-mvp (panel, aislamiento, monitores, SAST) |
Catálogo HA-01–HA-31 importado a Jira como Historia de Arquitectura. Escenario de calidad asociado abre con la subtabla del escenario EC-* y, debajo, la Descripción (COMO / CUANDO / DADO QUE / QUIERO QUE / PARA / ESTO DEBE SUCEDER).
El equipo decidió trabajar con los ASR de latencia y escalabilidad (HA-01–HA-13). El resto del catálogo se conserva; no ordena el tablero SOLV (priorización).
- Latencia (HA-01–HA-08)
- Escalabilidad (HA-09–HA-13)
- Disponibilidad (HA-14–HA-20)
- Seguridad (HA-21–HA-24)
- Modificabilidad (HA-25–HA-28)
- Integrabilidad (HA-29–HA-31)
Etiqueta Jira: Latencia. En alcance.
| ID | Summary | SP | Escenario de calidad asociado | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HA-01 | HA-01 - Presupuesto de latencia de la cotización embebida en operación normal | 3 |
Descripción COMO socio de distribución que ofrece seguros embebidos en mi propio canal digital,CUANDO solicito una cotización a través de la API pública de Solventa, DADO QUE la plataforma opera en producción a carga nominal y la cotización es el primer punto de contacto del cliente con el producto, QUIERO QUE la capacidad de cotización y el motor de rating resuelvan el cálculo dentro de un presupuesto de latencia explícito, sin dependencias sincrónicas no acotadas, PARA sostener la conversión del canal embebido y evitar el abandono del cliente en la entrada del journey de venta, ESTO DEBE SUCEDER: el p95 extremo a extremo de la operación de cotización se mantiene en 250 ms o menos, medido en producción a carga nominal |
||||||||||||||||||||
| HA-02 | HA-02 - Control de la latencia de cola de la cotización en horario pico | 2 |
Descripción COMO socio de distribución que ofrece seguros embebidos en mi propio canal digital,CUANDO solicito una cotización durante el horario pico de mi canal, DADO QUE en producción concurren varios socios con alta concurrencia y la contención de recursos amplifica la cola de la distribución de latencia, QUIERO QUE la arquitectura acote la latencia de cola mediante aislamiento de recursos, límites de concurrencia y elasticidad de la capacidad de cotización, PARA que la experiencia del canal no se degrade precisamente en la franja de mayor volumen comercial, ESTO DEBE SUCEDER: el p99 extremo a extremo de la operación de cotización se mantiene en 500 ms o menos durante el horario pico |
||||||||||||||||||||
| HA-03 | HA-03 - Presupuesto de latencia del perfilamiento en línea de vida hipotecario | 3 |
Descripción COMO proceso de originación de un banco aliado que ofrece vida hipotecario dentro de su flujo de crédito,CUANDO solicito el perfilamiento de un cliente que cuenta con consentimiento Open Finance vigente, DADO QUE la plataforma opera en producción a carga nominal y el perfil se construye con datos de fuentes externas, QUIERO QUE la capacidad de perfilamiento y la capa de integración externa construyan el perfil de riesgo y generen la oferta personalizada dentro de un presupuesto de latencia acotado, PARA presentar la oferta de seguro dentro del flujo de originación del crédito sin interrumpir la experiencia del banco aliado, ESTO DEBE SUCEDER: el p95 de la operación de perfilamiento se mantiene en 400 ms o menos |
||||||||||||||||||||
| HA-04 | HA-04 - Preservación del presupuesto de perfilamiento en el pico de cierre de mes | 2 |
Descripción COMO proceso de originación de un banco aliado que ofrece vida hipotecario dentro de su flujo de crédito,CUANDO solicito el perfilamiento durante el pico de cierres de fin de mes, DADO QUE la originación del aliado concentra su volumen en los últimos días del mes y la demanda sobre las fuentes externas se multiplica, QUIERO QUE la plataforma preserve el presupuesto de latencia del perfilamiento bajo demanda concentrada, acotando la cola de la distribución, PARA que el pico comercial del aliado no se traduzca en ofertas que llegan tarde o que no llegan, ESTO DEBE SUCEDER: el p99 de la operación de perfilamiento se mantiene en 800 ms o menos durante el pico de cierre de mes |
||||||||||||||||||||
| HA-05 | HA-05 - Presupuesto de latencia del journey de suscripción y emisión automática | 5 |
Descripción COMO cliente asegurado que acaba de recibir una oferta de seguro,CUANDO acepto la oferta recibida, DADO QUE la plataforma opera en producción a carga nominal y la aceptación encadena decisión de suscripción, cobro, firma y emisión, QUIERO QUE las capacidades de suscripción, cobro, firma y emisión se orquesten con un presupuesto de latencia repartido por etapa, evitando pasos sincronicos innecesarios, PARA recibir mi póliza en el mismo momento de la compra y cerrar la venta sin fricción, ESTO DEBE SUCEDER: el p95 del recorrido desde la aceptación hasta la póliza emitida se mantiene en 1,5 s o menos |
||||||||||||||||||||
| HA-06 | HA-06 - Sostenimiento de la emisión inmediata en horario pico de transacciones | 3 |
Descripción COMO cliente asegurado que acaba de recibir una oferta de seguro,CUANDO acepto la oferta durante el horario pico de transacciones, DADO QUE la plataforma atiende concurrentemente el volumen máximo de aceptaciones y las etapas de cobro dependen de pasarelas externas, QUIERO QUE la orquestación conserve el presupuesto de latencia del journey completo bajo concurrencia máxima, con control explícito de la cola de la distribución, PARA que la promesa de emisión inmediata se sostenga también en la franja de mayor demanda, ESTO DEBE SUCEDER: el p99 del recorrido desde la aceptación hasta la póliza emitida se mantiene en 3 s o menos |
||||||||||||||||||||
| HA-07 | HA-07 - Degradación controlada de la cotización ante dependencia externa lenta | 3 |
Descripción COMO socio de distribución que ofrece seguros embebidos en mi propio canal digital,CUANDO solicito una cotización y un proveedor externo no responde dentro de su presupuesto de tiempo, DADO QUE en producción los proveedores externos se degradan de forma intermitente y el journey de cotización no puede quedar bloqueado por ellos, QUIERO QUE la capacidad de cotización complete el cálculo con un valor de respaldo tomado del caché de perfil, degradando la precisión pero nunca la respuesta, PARA seguir cotizando y vendiendo aun cuando una dependencia externa esté degradada, ESTO DEBE SUCEDER: el p95 del journey de cotización se mantiene en 250 ms o menos incluso con el proveedor externo fuera de su presupuesto |
||||||||||||||||||||
| HA-08 | HA-08 - Modelo de lectura de baja latencia para el estado de siniestro | 3 |
Descripción COMO cliente asegurado con un siniestro en curso,CUANDO consulto el estado de mi siniestro, DADO QUE la plataforma opera en producción en condiciones regulares y el estado del siniestro cambia por eventos del proceso de evaluación, QUIERO QUE exista un modelo de lectura de siniestros optimizado para consulta y desacoplado del modelo de escritura del proceso, PARA conocer el avance de mi siniestro de forma inmediata, en el momento de mayor sensibilidad de la relación con la aseguradora, ESTO DEBE SUCEDER: el p95 de la consulta de estado de siniestro se mantiene en 150 ms o menos |
Etiqueta Jira: Escalabilidad. En alcance (HA-13 ordena un spike SBA; el producto HU-81 queda ola 5).
| ID | Summary | SP | Escenario de calidad asociado | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HA-09 | HA-09 - Sostenimiento del caudal de cotización ante campaña masiva de socio | 8 |
Descripción COMO socio de distribución que lanza una campaña comercial masiva,CUANDO mi campaña multiplica por 100 el tráfico de cotización sobre la plataforma, DADO QUE el pico comercial es inducido y previsible, y la infraestructura de cotización es elastica, QUIERO QUE la capacidad de cotización escale horizontalmente y sostenga el caudal completo sin rechazar solicitudes, PARA aprovechar comercialmente la campaña en lugar de perder la demanda que ella misma genera, ESTO DEBE SUCEDER: la plataforma sostiene el crecimiento de 500 a 50.000 cotizaciones por minuto durante 30 minutos consecutivos sin degradar el servicio |
||||||||||||||||||||
| HA-10 | HA-10 - Tiempo de reacción del autoescalado de la capacidad de cotización | 5 |
Descripción COMO responsable de la capacidad elastica de la plataforma,CUANDO el caudal de solicitudes supera el umbral de escalado configurado, DADO QUE la rampa inicial de una campaña puede agotar la capacidad disponible en pocos segundos, QUIERO QUE el controlador de autoescalado aprovisione e incorpore capacidad adicional al balanceo con un tiempo de arranque acotado (imágenes livianas, warm pool y readiness rápido), PARA que la elasticidad reaccione antes de que la rampa agote la capacidad existente y se pierdan cotizaciones, ESTO DEBE SUCEDER: la capacidad ampliada queda disponible y recibiendo tráfico en 60 s o menos desde el disparo del escalado |
||||||||||||||||||||
| HA-11 | HA-11 - Absorción con contrapresión de una ráfaga masiva de eventos paramétricos | 8 |
Descripción COMO responsable de la capacidad de siniestros paramétricos,CUANDO un proveedor externo de telemetría genera una ráfaga masiva de eventos ante un evento externo, DADO QUE la plataforma no controla el ritmo de emisión del proveedor y su capacidad de procesamiento es finita, QUIERO QUE el canal de eventos reciba y persista el flujo aplicando contrapresión y acumulando el rezago en almacenamiento duradero, PARA no perder eventos que representan obligaciones de pago ciertas de la aseguradora, ESTO DEBE SUCEDER: la plataforma absorbe y persiste al menos 1.000.000 de eventos en 10 minutos sin pérdida |
||||||||||||||||||||
| HA-12 | HA-12 - Procesamiento exactamente una vez del rezago de eventos paramétricos | 5 |
Descripción COMO responsable de la capacidad de siniestros paramétricos,CUANDO el canal de eventos entrega el rezago acumulado durante el pico, DADO QUE la recuperación posterior al pico reentrega eventos y cada evento dispara un pago automático real, QUIERO QUE la capacidad de siniestros paramétricos procese cada evento encolado con semántica idempotente y control de deduplicación, PARA pagar todas las indemnizaciones que corresponden, sin pagar ninguna dos veces, ESTO DEBE SUCEDER: el 100 % de los eventos encolados se procesa exactamente una vez, sin pérdidas ni pagos duplicados |
||||||||||||||||||||
| HA-13 | HA-13 - Aislamiento de carga y cuotas entre socios de distribución | 5 |
Descripción COMO socio de distribución que opera dentro de la cuota que contrate,CUANDO otro socio genera un volumen de solicitudes por encima de lo que tiene contratado, DADO QUE en producción operan 50 socios de forma concurrente sobre la misma capa de exposición de APIs, QUIERO QUE la capa de exposición aplique control de cuotas y aislamiento de carga por socio (bulkhead), conteniendo el exceso en el socio que lo genera, PARA que el comportamiento de un tercero no deteriore el servicio que recibo ni el de los demás socios, ESTO DEBE SUCEDER: el 100 % de los socios no infractores conserva su p95 mientras el socio infractor queda limitado a su cuota |
Etiqueta Jira: Disponibilidad. Fuera del alcance LAT/ESC: no suben una HU de ola.
| ID | Summary | SP | Escenario de calidad asociado | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HA-14 | HA-14 - Redundancia del journey de venta con disponibilidad de 99,97 % | 5 |
Descripción COMO socio de distribución,CUANDO ejecuto el recorrido completo de cotización, suscripción y emisión, DADO QUE la plataforma opera en producción 24/7 y la venta es la fuente de ingresos del negocio, QUIERO QUE las capacidades de cotización, suscripción y emisión estén desplegadas de forma redundante, sin punto único de falla y con degradación controlada, PARA poder vender en cualquier momento, sin ventanas en las que mi canal quede fuera de servicio, ESTO DEBE SUCEDER: la disponibilidad mensual medida sobre el journey de venta es mayor o igual a 99,97 % |
||||||||||||||||||||
| HA-15 | HA-15 - Redundancia y aislamiento del journey de siniestros con 99,97 % | 5 |
Descripción COMO cliente asegurado,CUANDO reporto un siniestro y consulto su avance, DADO QUE la plataforma opera en producción 24/7 y el siniestro es el momento de verdad de la promesa del seguro, QUIERO QUE las capacidades de reporte, evaluación y pago de siniestros estén desplegadas de forma redundante y aisladas de fallos del resto de la plataforma, PARA recibir respuesta de la aseguradora justo cuando ocurre el evento que cubre mi póliza, ESTO DEBE SUCEDER: la disponibilidad mensual medida sobre el journey de siniestros es mayor o igual a 99,97 % |
||||||||||||||||||||
| HA-16 | HA-16 - Alta disponibilidad del recaudo de prima con conmutación de pasarela | 3 |
Descripción COMO cliente asegurado,CUANDO pago la prima de mi póliza, DADO QUE el recaudo es el flujo de entrada de dinero del negocio y depende de pasarelas de cobro externas, QUIERO QUE la capacidad de recaudo opere con redundancia y con conmutación entre pasarelas ante la falla de una de ellas, PARA que mi póliza no quede en riesgo de perder vigencia por una falla técnica del cobro, ESTO DEBE SUCEDER: la disponibilidad mensual del recaudo de prima es mayor o igual a 99,99 % |
||||||||||||||||||||
| HA-17 | HA-17 - Alta disponibilidad del pago de indemnizaciones | 3 |
Descripción COMO proceso de indemnización de Solventa,CUANDO ordeno el desembolso de una indemnización ya aprobada, DADO QUE el pago es el flujo de salida de dinero y su interrupción tiene impacto reputacional y regulatorio directo, QUIERO QUE la capacidad de pagos y dispersión de fondos opere con redundancia y reintento seguro ante la falla de una ruta de dispersión, PARA cumplir la promesa de indemnización dentro de los tiempos comprometidos con el asegurado y con el regulador, ESTO DEBE SUCEDER: la disponibilidad mensual del pago de indemnizaciones es mayor o igual a 99,99 % |
||||||||||||||||||||
| HA-18 | HA-18 - Idempotencia de los movimientos monetarios confirmados | 2 |
Descripción COMO responsable de la integridad financiera de la plataforma,CUANDO una pasarela de pagos reintenta una operación ya confirmada tras un corte de comunicación, DADO QUE la recuperación de fallas de comunicación produce reintentos y respuestas duplicadas sobre operaciones monetarias, QUIERO QUE las capacidades de cobros, pagos y conciliación reconozcan la operación mediante una clave de idempotencia y conserven un único movimiento, PARA evitar el doble cobro al cliente o el doble pago de una indemnización y mantener exacta la conciliación contable, ESTO DEBE SUCEDER: el 100 % de las transacciones confirmadas se aplica exactamente una vez, sin importar cuántos reintentos se reciban |
||||||||||||||||||||
| HA-19 | HA-19 - Continuidad del servicio ante la caída de una zona de disponibilidad | 8 |
Descripción COMO responsable de la continuidad operativa de la plataforma,CUANDO falla una zona de disponibilidad de la nube, DADO QUE los journeys críticos están desplegados en varias zonas de una misma región, QUIERO QUE el tráfico se redirija automáticamente a las zonas sanas, con detección de salud y conmutación sin intervención manual, PARA que una falla de infraestructura del proveedor de nube no se traduzca en una interrupción visible del negocio, ESTO DEBE SUCEDER: la operación de los journeys críticos se restablece desde las zonas sanas con un RTO menor o igual a 10 minutos |
||||||||||||||||||||
| HA-20 | HA-20 - Continuidad del estado con replicación multizona | 5 |
Descripción COMO responsable de la continuidad operativa de la plataforma,CUANDO falla una zona de disponibilidad y debo recuperar el estado del sistema, DADO QUE los datos de pólizas, cobros y siniestros se replican entre las zonas de la región, QUIERO QUE el estado se recupere desde las réplicas de las zonas sanas con una ventana de pérdida acotada por la estrategia de replicación, PARA no perder pólizas emitidas, cobros confirmados ni siniestros reportados durante la falla, ESTO DEBE SUCEDER: la recuperación del estado se realiza con un RPO menor o igual a 30 segundos |
Etiqueta Jira: Seguridad. Después del slice LAT/ESC del mismo recorrido.
| ID | Summary | SP | Escenario de calidad asociado | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HA-21 | HA-21 - Propagación efectiva de la revocación del consentimiento Open Finance | 3 |
Descripción COMO cliente titular de los datos financieros compartidos vía Open Finance,CUANDO revoco el consentimiento que habia otorgado para el uso de mis datos, DADO QUE la plataforma opera en producción con consentimientos y accesos activos, y varias capacidades consumen esos datos, QUIERO QUE la gestión de consentimiento registre la revocación y propague la restricción de acceso a todas las capacidades que usaban esos datos, PARA ejercer efectivamente el derecho sobre mis datos y que Solventa cumpla el Decreto 1297/2022 y la CE 004/2024 de la SFC, ESTO DEBE SUCEDER: la revocación queda efectiva en todas las capacidades consumidoras en 5 minutos o menos desde su registro |
||||||||||||||||||||
| HA-22 | HA-22 - Trazabilidad y reconstrucción de las decisiones de suscripción | 3 |
Descripción COMO actuaría responsable de la técnica del portafolio,CUANDO debo justificar el precio de una póliza emitida en el pasado, DADO QUE las reglas de rating y las fuentes de datos ya cambiaron desde el momento de la emisión, QUIERO QUE el motor de rating y suscripción registre cada decisión con su linaje completo (versión de reglas, señales de entrada y resultado) de forma inmutable, PARA poder reconstruir y defender técnicamente cualquier precio emitido ante una auditoría, ESTO DEBE SUCEDER: el 100 % de las decisiones de suscripción es reconstruible con las reglas y señales vigentes al momento de la decisión |
||||||||||||||||||||
| HA-23 | HA-23 - Detección y bloqueo de patrones anómalos de tráfico sobre las APIs | 5 |
Descripción COMO responsable de la operación de seguridad de la plataforma,CUANDO un actor malicioso externo genera un patron anómalo de solicitudes sobre las APIs públicas, DADO QUE la plataforma está expuesta a socios por internet y el tráfico legítimo circula de forma concurrente durante el ataque, QUIERO QUE la capa de exposición detecte la anomalía de tráfico y bloquee el origen infractor de forma automática, PARA sostener el servicio para los socios legítimos y evitar el abuso de las APIs de cotización, ESTO DEBE SUCEDER: el bloqueo del origen infractor ocurre en 1 segundo o menos desde el inicio del patron anómalo, sin afectar el tráfico legítimo |
||||||||||||||||||||
| HA-24 | HA-24 - Retención con traza completa de los siniestros marcados por fraude | 3 |
Descripción COMO responsable de prevención de fraude,CUANDO un actor malicioso con una cuenta comprometida reporta un siniestro simulado, DADO QUE la plataforma paga siniestros de forma automática y el fraude ingresa por el mismo canal que los casos legítimos, QUIERO QUE el motor de detección de fraude retenga el caso para revisión manual antes de cualquier pago y conserve el registro completo del intento, PARA evitar el pago de siniestros fraudulentos y conservar la evidencia necesaria para la investigación, ESTO DEBE SUCEDER: el 100 % de los casos marcados por el motor de fraude queda retenido con traza completa del intento |
Etiqueta Jira: Modificabilidad.
| ID | Summary | SP | Escenario de calidad asociado | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HA-25 | HA-25 - Puntos de extensión para la incorporación de un nuevo ramo de seguro | 2 |
Descripción COMO equipo de desarrollo de Solventa,CUANDO implemento un nuevo ramo de seguro sobre la plataforma en producción, DADO QUE la evolución del portafolio es planificada y el cambio ocurre en tiempo de desarrollo sobre un sistema en operación, QUIERO QUE la plataforma exponga puntos de extensión explicitos para producto, rating y suscripción, de modo que el nuevo ramo se implemente sin tocar el resto del sistema, PARA que el lanzamiento de nuevos ramos no requiera intervenir capacidades transversales ni introduzca riesgo de regresión, ESTO DEBE SUCEDER: el 100 % de los archivos modificados para incorporar el nuevo ramo pertenece a los módulos de producto y rating |
||||||||||||||||||||
| HA-26 | HA-26 - Externalización y versionamiento de las reglas de precio del motor de rating | 2 |
Descripción COMO actuaría responsable de la tarifa de los productos,CUANDO ajusto la fórmula de precio de un producto, DADO QUE existen pólizas vigentes emitidas bajo las reglas anteriores y la plataforma opera con normalidad, QUIERO QUE el motor de rating externalice las reglas de precio de manera que el cambio se aplique de forma contenida y versionada, PARA responder a la competencia y a la siniestralidad con la velocidad que exige el negocio, ESTO DEBE SUCEDER: el 100 % del cambio se despliega sin redesplegar componentes ajenos al motor de rating |
||||||||||||||||||||
| HA-27 | HA-27 - Contención del cambio de la política de aceptación de riesgo | 2 |
Descripción COMO actuaría responsable de la política de aceptación de riesgo,CUANDO ajusto la política de aceptación de riesgo del portafolio, DADO QUE existen pólizas vigentes emitidas bajo las reglas anteriores y la plataforma opera con normalidad, QUIERO QUE el motor de decisión de suscripción externalice la política de aceptación de modo que el cambio quede contenido y versionado, PARA ajustar el apetito de riesgo sin depender de un ciclo completo de desarrollo y despliegue de la plataforma, ESTO DEBE SUCEDER: el 100 % del cambio se despliega sin redesplegar componentes ajenos al motor de suscripción |
||||||||||||||||||||
| HA-28 | HA-28 - Encapsulamiento de proveedores externos tras adaptadores sustituibles | 3 |
Descripción COMO equipo de arquitectura e integraciones,CUANDO sustituyo un proveedor externo por otro, DADO QUE el sistema está en producción y varias capacidades internas consumen la información de ese proveedor, QUIERO QUE la integración esté encapsulada tras una interfaz publicada estable (adaptador y capa anticorrupción), de modo que solo se reimplemente el adaptador, PARA negociar y rotar proveedores sin que ello implique un cambio estructural de la plataforma, ESTO DEBE SUCEDER: el 100 % del cambio queda contenido en el módulo de integración, sin modificar los consumidores internos |
Etiqueta Jira: Integrabilidad.
| ID | Summary | SP | Escenario de calidad asociado | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HA-29 | HA-29 - Alta de socios embebidos por configuración declarativa | 3 |
Descripción COMO equipo de plataforma,CUANDO ejecuto el alta de un socio de distribución nuevo, DADO QUE hay socios existentes ya operando en producción y la expansión comercial exige altas frecuentes, QUIERO QUE el alta se resuelva mediante un catálogo declarativo de configuración de socios sobre contratos públicos de API estables, PARA que la incorporación de socios escale sin quedar limitada por la capacidad del equipo de desarrollo, ESTO DEBE SUCEDER: el 100 % del alta de un socio nuevo se resuelve por configuración, sin modificar código ni desplegar la plataforma |
||||||||||||||||||||
| HA-30 | HA-30 - Modelo canónico y adaptadores para nuevas fuentes de Open Data/Open Finance | 3 |
Descripción COMO equipo de plataforma que incorpora un nuevo proveedor de datos externo,CUANDO incorporo una nueva fuente de datos al perfilamiento, DADO QUE existen consumidores del perfil ya en producción y cada fuente trae su propio esquema y semántica, QUIERO QUE un adaptador traduzca la fuente al modelo canónico interno, aislando a los consumidores del formato del proveedor, PARA enriquecer el perfilamiento con nuevas fuentes sin propagar el costo del cambio a toda la plataforma, ESTO DEBE SUCEDER: el 100 % de los consumidores existentes del perfil continua operando sin modificación |
||||||||||||||||||||
| HA-31 | HA-31 - Versionamiento compatible de los contratos de API multicanal | 5 |
Descripción COMO equipo de plataforma,CUANDO publico una evolución de los contratos de API consumidos por web, móvil y socios, DADO QUE en producción coexisten versiones distintas de clientes desplegadas simultáneamente y las apps moviles no se actualizan al mismo ritmo, QUIERO QUE exista una política de versionamiento y compatibilidad hacia atrás que permita publicar la nueva versión manteniendo operativa la anterior, PARA evolucionar la plataforma sin tener que coordinar despliegues simultaneos con todos los canales y socios, ESTO DEBE SUCEDER: el 100 % de los clientes no modificados continua operando sin requerir redespliegue |
-
ASR en alcance: latencia y escalabilidad. El equipo decidió trabajar con los escenarios ASR de Hoja de trabajo §§6.1–6.2 (
EC-LAT-*ASR yEC-ESC-*). Esas medidas son HA-01–HA-13. Disponibilidad (HA-14–HA-20) queda fuera de ese alcance: no sube una HU de ola. Seguridad, modificación e integración (HA-21–HA-31) entran cuando el slice LAT/ESC del mismo recorrido ya está en el tablero. - Recorridos críticos PDF §5.1. El MVP sigue siendo un recorrido delgado de los seis. La cola de implementación no es 1→6: primero los recorridos donde hay ASR de latencia o escalabilidad (cotización, emisión, perfilamiento), después siniestros (#3 y #4) y al final ciclo de vida (#6, sin ASR LAT/ESC).
- Dependencias INVEST. Lab (repos, Docker, nube, dobles, K6) antes del experimento; catálogo y prima antes de la oferta; oferta vigente antes de aceptar.
post-mvp = ola 5 (Lowest), aunque el HA asociado sea ASR (p. ej. HA-13 → HU-81).
En Jira: ola 1 = Highest, 2 = High, 3 = Medium, 4 = Low, 5 = Lowest.
| Ola | Jira | Recorridos §5.1 | HA que ordenan la ola | HU | SP HU |
|---|---|---|---|---|---|
| 1 | Highest | #1 cotización embebida + lab para medir |
HA-01, HA-02, HA-07, HA-09, HA-10 (EC-LAT-01/02/09, EC-ESC-01/02) |
HU-70, HU-71, HU-78, HU-85, HU-88, HU-89, HU-83, HU-1…HU-6, HU-79 | 52 |
| 2 | High | #2 suscripción y emisión; #5 perfilamiento vida hipotecario |
HA-05, HA-06, HA-03, HA-04 (EC-LAT-05/06/03/04) |
HU-7, HU-12, HU-13, HU-15…HU-17, HU-53…HU-56, HU-72, HU-73, HU-86, HU-87 | 44 |
| 3 | Medium | #3 siniestro asistido; #4 paramétrico (slice, no el millón de eventos); canales e identidad que cierran el MVP |
HA-08, HA-11, HA-12 (EC-LAT-11, EC-ESC-03/04) |
HU-8…HU-11, HU-14, HU-18…HU-20, HU-22…HU-37, HU-44…HU-47, HU-57, HU-58, HU-74…HU-77 | 104 |
| 4 | Low | #6 ciclo de vida | Ningún ASR LAT/ESC | HU-59…HU-65 | 18 |
| 5 | Lowest | Fuera de §5.1 (post-mvp) |
No ordenan el tablero; HA-13 queda como spike SBA si hay cupo | HU-21, HU-38…HU-43, HU-48…HU-52, HU-66…HU-69, HU-80…HU-82, HU-84 | 95 |
Ola 1 y 2 son el corte con el que se evidencian los ASR de latencia y escalabilidad que el equipo tomó. Ola 3 completa los seis recorridos. Ola 4 cierra §5.1. Ola 5 queda fuera del corte de implementación actual.
Fuente: Historias de arquitectura (SBA) y files/historias-arquitectura-solventa-jira-v2.csv. Una HA no se “implementa” como HU de producto: el spike o el experimento de SBA mide el ASR sobre las HU listadas.
| HA | Eje | Escenario | SP | HUs que habilitan el slice | Cómo se evidencia |
|---|---|---|---|---|---|
| HA-01 | Latencia | EC-LAT-01 · p95 cotización ≤ 250 ms | 3 | HU-1…HU-6, HU-79, HU-89 | Experimento de carga a caudal nominal |
| HA-02 | Latencia | EC-LAT-02 · p99 cotización ≤ 500 ms (pico) | 2 | HU-1…HU-6, HU-79, HU-89 | Mismo experimento en horario pico |
| HA-03 | Latencia | EC-LAT-03 · p95 perfilamiento ≤ 400 ms | 3 | HU-53…HU-56, HU-57, HU-58 | Medición sobre el stub OF/OD |
| HA-04 | Latencia | EC-LAT-04 · p99 perfilamiento ≤ 800 ms (cierre de mes) | 2 | HU-53…HU-56, HU-89 | Pico sobre el mismo slice, después de HA-03 |
| HA-05 | Latencia | EC-LAT-05 · p95 aceptación→póliza ≤ 1,5 s | 5 | HU-12, HU-13, HU-15…HU-17 | Reloj de extremo a extremo del recorrido #2 |
| HA-06 | Latencia | EC-LAT-06 · p99 emisión ≤ 3 s (pico) | 3 | HU-12, HU-13, HU-15…HU-17, HU-89 | Pico sobre el recorrido #2 |
| HA-07 | Latencia | EC-LAT-09 · cotización con tercero lento, p95 ≤ 250 ms | 3 | HU-5, HU-88 | Stub lento / fallo; valor de respaldo |
| HA-08 | Latencia | EC-LAT-11 · p95 estado de siniestro ≤ 150 ms | 3 | HU-26, HU-30, HU-31 | Modelo de lectura, no el comando de aviso |
| HA-09 | Escalabilidad | EC-ESC-01 · 500 → 50.000 cot/min × 30 min | 8 | HU-3…HU-6, HU-79, HU-89 | SPIKE de campaña (PR-01) |
| HA-10 | Escalabilidad | EC-ESC-02 · capacidad extra ≤ 60 s | 5 | HU-78, HU-79, HU-89 | Autoescalado en el ambiente de experimentos |
| HA-11 | Escalabilidad | EC-ESC-03 · ≥ 1.000.000 eventos / 10 min | 8 | HU-32 | Slice = ingesta stub (ola 3); el millón es spike SBA, no otra HU |
| HA-12 | Escalabilidad | EC-ESC-04 · rezago exactamente una vez | 5 | HU-32…HU-34 | Idempotencia en aceptación de HU-34 |
| HA-13 | Escalabilidad | EC-ESC-05 · aislamiento de cuota entre socios | 5 | HU-81 | Producto ola 5; spike SBA si hay cupo |
| HA-14 | Disponibilidad | EC-DISP-01 · venta ≥ 99,97 % | 5 | HU-78, HU-82 | No ordena SOLV (fuera del alcance LAT/ESC) |
| HA-15 | Disponibilidad | EC-DISP-02 · siniestros ≥ 99,97 % | 5 | HU-22…HU-31, HU-82 | Idem |
| HA-16 | Disponibilidad | EC-DISP-03 · recaudo ≥ 99,99 % | 3 | HU-15, HU-21 | Idempotencia del cobro es AC de HU-15 |
| HA-17 | Disponibilidad | EC-DISP-04 · pago indemnización ≥ 99,99 % | 3 | HU-29, HU-34 | Stub de pago; pasarela real es HU-21 |
| HA-18 | Disponibilidad | EC-DISP-05 · movimiento exactamente una vez | 2 | HU-15, HU-29, HU-34 | Aceptación, no HU extra |
| HA-19 | Disponibilidad | EC-DISP-06 · RTO zona ≤ 10 min | 8 | HU-78 | Multi-zona fuera del alcance LAT/ESC |
| HA-20 | Disponibilidad | EC-DISP-07 · RPO ≤ 30 s | 5 | HU-78 | Idem |
| HA-21 | Seguridad | Revocación OF ≤ 5 min | 3 | HU-46, HU-53 | Después del slice #5 |
| HA-22 | Seguridad | Reconstrucción de la decisión de suscripción | 3 | HU-14 | Ola 3 (no bloquea p95 de emisión) |
| HA-23 | Seguridad | Bloqueo de patrón anómalo ≤ 1 s | 5 | HU-74…HU-77, HU-81 | Gateway; cuota es ola 5 |
| HA-24 | Seguridad | Traza de siniestros marcados por fraude | 3 | HU-26…HU-30 | Auditoría en aceptación de HU-27 |
| HA-25 | Modificación | Nuevo ramo sin tocar el núcleo ajeno | 2 | HU-1 | Un ramo en MVP; extensión después |
| HA-26 | Modificación | Reglas de precio versionadas | 2 | HU-4 | Motor de rating |
| HA-27 | Modificación | Política de aceptación contenida | 2 | HU-13 | Decisión automática |
| HA-28 | Modificación | Proveedores tras adaptadores | 3 | HU-5, HU-54, HU-88 | Política de stubs |
| HA-29 | Integración | Alta de socio por configuración | 3 | HU-2 | Catálogo embebido |
| HA-30 | Integración | Nueva fuente OF/OD sin retocar consumidores | 3 | HU-54, HU-55 | Modelo interno, no el API del banco |
| HA-31 | Integración | Versionado compatible BFF / API | 5 | HU-72, HU-73, HU-88 | Pact en aceptación de HU-88 |
INVEST: una HU = un incremento que un actor puede terminar y el equipo estimar en un refinement. Independiente en lo posible (orden de dependencias abajo, no un “combo”). Valiosa para socio, cliente, operador o el propio recorrido §5.1. Testeable con un hecho cuando claro. No se parte en tabla/DTO/endpoint.
Texto Como …, quiero …, para … alineado al PDF. El p95 / caudal viven en SBA. Las HU no fijan el esquema que devolvería un banco, una pasarela o un proveedor de clima: eso queda en el stub.
ID = HU-#. Summary = HU - #. {Name}. Columna Ola = prioridad de entrega (priorización). Columna SP = Story point estimate (Story point estimate).
- 📋 Backlog refinado · Semana 3
PDF §5.1 #1 · §2.3 rating y distribución embebida. Orden: HU-1 → HU-2 → HU-3 → HU-4 → HU-5 → HU-6; UIs HU-10 / HU-11 consumen HU-6.
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-1 | HU - 1. Catálogo mínimo (1 ramo) | Como producto, quiero un ramo con coberturas fijas, para cotizar sin un modelo multi-ramo. | 1 | 1 |
core mvp
|
2 |
| HU-2 | HU - 2. Publicar catálogo al socio | Como socio, quiero consultar el catálogo embebido, para elegir qué producto cotizar. | 1 | 1 |
api mvp
|
2 |
| HU-3 | HU - 3. Recibir solicitud de cotización | Como socio, quiero enviar producto y datos mínimos del riesgo y obtener un cotizacionId, para seguir el flujo en mi canal. |
1 | 1 |
core api mvp
|
3 |
| HU-4 | HU - 4. Calcular prima con reglas | Como motor de rating, quiero calcular una prima repetible con reglas simples, para obtener un precio base (mismos insumos → misma prima). | 1 | 1 |
core mvp
|
5 |
| HU-5 | HU - 5. Combinar factor de riesgo (stub) | Como plataforma, quiero ajustar la prima con un factor simulado del adaptador (o un valor de respaldo si el stub falla o llega tarde), para devolver precio sin depender del esquema real de Open Finance. | 1 | 1 |
core api mvp
|
3 |
| HU-6 | HU - 6. Devolver oferta en firme | Como socio o asesor, quiero una oferta (prima, moneda, venceEn) en el mismo flujo de compra, para decidir sin salir del recorrido. |
1 | 1 |
core api mvp
|
2 |
| HU-7 | HU - 7. Reconsultar oferta por id | Como cliente o asesor, quiero recuperar la oferta por id sin recálculo, para aceptar el mismo precio. | 1 | 2 |
core api mvp
|
2 |
| HU-8 | HU - 8. Shell UI Web | Como asesor o socio en escritorio, quiero navegar cotizar / emitir / consultar / siniestros, para operar desde un portal. | 1 | 3 |
web mvp
|
3 |
| HU-9 | HU - 9. Mockup Web | Como stakeholder de negocio, quiero un mockup web conectado al BFF, para validar cotizar → emitir → siniestro antes del desarrollo completo. | 1 | 3 |
web mvp
|
3 |
| HU-10 | HU - 10. UI web cotización | Como asesor, quiero pedir y ver la oferta en el portal, para vender en escritorio. | 1 | 3 |
web mvp
|
3 |
| HU-11 | HU - 11. UI móvil cotización | Como cliente en la app del socio, quiero ver el precio en el flujo de compra, para decidir sin salir. | 1 | 3 |
mobile mvp
|
5 |
PDF §5.1 #2. Orden: HU-7 → HU-12 → HU-13 → HU-15 → HU-16 → HU-17; HU-14 puede ir en paralelo a HU-13. UIs HU-19 / HU-20.
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-12 | HU - 12. Aceptar oferta vigente | Como cliente o asesor, quiero aceptar una oferta vigente y no usada, para disparar la suscripción. | 2 | 2 |
core mvp
|
2 |
| HU-13 | HU - 13. Decisión automática de suscripción | Como plataforma, quiero aceptar o rechazar el riesgo en automático con motivo, para no depender de un underwriter en el MVP. | 2 | 2 |
core mvp
|
3 |
| HU-14 | HU - 14. Reconstruir decisión de suscripción | Como actuaría, quiero reconstruir los insumos y reglas que Solventa persistió, para justificar un precio (sin exigir el extracto original del banco u otro tercero). | 2 | 3 |
core mvp
|
3 |
| HU-15 | HU - 15. Cobro de prima (stub idempotente) | Como cliente, quiero un cobro simulado que no se duplique en un reintento, para seguir el recorrido §5.1 #2 sin una pasarela real ni su conciliación. | 2 | 2 |
core mvp
|
3 |
| HU-16 | HU - 16. Emitir póliza | Como cliente, quiero una póliza con número, vigencia, coberturas y estado vigente, para quedar cubierto en el mismo flujo. |
2 | 2 |
core mvp
|
3 |
| HU-17 | HU - 17. Firma electrónica (stub) | Como plataforma, quiero dejar constancia simulada de firma (ok / no), para emitir sin el protocolo ni el documento del prestador de firma. | 2 | 2 |
core mvp
|
2 |
| HU-18 | HU - 18. Consultar póliza emitida | Como cliente, quiero ver coberturas y vigencia, para acreditar cobertura (mismo estado en web y móvil). | 2 | 3 |
core web mobile mvp
|
2 |
| HU-19 | HU - 19. UI web suscripción y emisión | Como asesor, quiero aceptar, firmar y emitir en una pantalla con estados reales del núcleo, para no inventar el estado en la UI. | 2 | 3 |
web mvp
|
3 |
| HU-20 | HU - 20. UI móvil aceptar y póliza | Como cliente en la app, quiero aceptar y ver la póliza emitida, para cerrar el recorrido en movilidad. | 2 | 3 |
mobile mvp
|
5 |
| HU-21 | HU - 21. Pasarela de pago (adaptador) | Como cliente, quiero pagar vía adaptador de pasarela, para un débito real cuando se sustituya el stub. El contrato mínimo es cobro ok/fallo/idempotente; no se fija el payload PCI del proveedor. | 2 | 5 |
mobile post-mvp
|
5 |
PDF §5.1 #3 (reportar, evaluar, aprobar, pagar o enrutar) y #4 (evento → pago). §5.2 cámara, geo, push.
Recorrido #3:
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-22 | HU - 22. Aviso de siniestro guiado | Como cliente, quiero reportar con un formulario mínimo y póliza vigente, para iniciar la atención. | 3 | 3 |
mobile mvp
|
5 |
| HU-23 | HU - 23. Una foto del siniestro | Como cliente, quiero adjuntar una foto al aviso, para evidenciar el hecho. | 3 | 3 |
mobile mvp
|
3 |
| HU-24 | HU - 24. Geoetiquetar evidencia | Como cliente, quiero que la foto lleve ubicación si hay GPS, para que operaciones sepa dónde ocurrió. | 3 | 3 |
mobile mvp
|
3 |
| HU-25 | HU - 25. Conservar evidencia sin red | Como cliente, quiero que la foto quede en cola si cae la red, para no recapturar. | 3 | 3 |
mobile mvp
|
5 |
| HU-26 | HU - 26. Ver aviso en back-office | Como operador, quiero ver evidencia, póliza y estado en una pantalla, para evaluar el caso. | 3 | 3 |
web mvp
|
3 |
| HU-27 | HU - 27. Aprobar o rechazar aviso | Como operador, quiero decidir con auditoría (quién, cuándo, por qué), para cerrar o continuar el caso. | 3 | 3 |
web mvp
|
2 |
| HU-28 | HU - 28. Enrutar aviso a perito | Como operador, quiero marcar el caso enrutado a perito, para cumplir el recorrido §5.1 #3 (sin red de talleres). |
3 | 3 |
web mvp
|
2 |
| HU-29 | HU - 29. Pagar siniestro de bajo monto (stub) | Como operador, quiero autorizar un desembolso simulado de bajo monto una sola vez, para cerrar el recorrido sin conciliar con una red de pagos real. | 3 | 3 |
core web mvp
|
3 |
| HU-30 | HU - 30. Estados del siniestro | Como plataforma, quiero persistir recibido / en evaluación / decidido / enrutado / pagado, para que canales y avisos usen el mismo modelo. | 3 | 3 |
core mvp
|
3 |
| HU-31 | HU - 31. Aviso in-app de cambio de estado | Como cliente, quiero ver que mi caso cambió de estado, para no llamar a soporte. | 3 | 3 |
mobile mvp
|
3 |
Recorrido #4:
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-32 | HU - 32. Recibir evento paramétrico (stub) | Como plataforma, quiero ingestir un evento simulado (id + un valor comparable), para disparar el recorrido #4 sin el feed real de vuelos o clima. | 4 | 3 |
core mvp
|
3 |
| HU-33 | HU - 33. Evaluar umbral paramétrico | Como plataforma, quiero comparar el valor del stub con un umbral de la póliza, para decidir si corresponde pagar. | 4 | 3 |
core mvp
|
2 |
| HU-34 | HU - 34. Disparar pago paramétrico (stub) | Como asegurado, quiero un pago simulado sin intervención humana cuando el umbral se cumple, para cerrar #4 sin la red de desembolsos. | 4 | 3 |
core mvp
|
3 |
| HU-35 | HU - 35. Aviso de pago paramétrico | Como cliente, quiero enterarme cuando Solventa confirma el pago simulado, para ver la indemnización (in-app o canal stub; no FCM ni su payload). | 4 | 3 |
mobile mvp
|
2 |
| HU-36 | HU - 36. Vista móvil paramétrico | Como cliente, quiero ver el resumen que persistió Solventa (póliza, umbral, monto), para entender el disparo sin el mensaje crudo del tercero. | 4 | 3 |
mobile mvp
|
3 |
| HU-37 | HU - 37. Vista web paramétrico | Como cliente en escritorio, quiero la trazabilidad que Solventa guardó del disparo, para conservar evidencia interna. | 4 | 3 |
web mvp
|
2 |
Extras §5.2:
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-38 | HU - 38. Recibo / daño extra | Como cliente, quiero adjuntar recibo o daño además de la foto, para completar la evaluación. | — | 5 |
mobile post-mvp
|
3 |
| HU-39 | HU - 39. Mapa de prestadores (stub) | Como cliente, quiero ver prestadores de un catálogo simulado en mapa, para elegir atención sin un proveedor cartográfico real. | — | 5 |
mobile post-mvp
|
5 |
| HU-40 | HU - 40. Prestadores cercanos | Como cliente, quiero ordenar ese catálogo stub por distancia, para ir al más conveniente. | — | 5 |
mobile post-mvp
|
3 |
| HU-41 | HU - 41. Asistencia en sitio (stub) | Como cliente, quiero registrar un pedido de asistencia con mi ubicación, para que operaciones lo vea (sin despacho real a un taller). | — | 5 |
mobile post-mvp
|
3 |
| HU-42 | HU - 42. Escaneo de documentos | Como cliente, quiero digitalizar un soporte con la cámara, para el trámite. | — | 5 |
mobile post-mvp
|
5 |
| HU-43 | HU - 43. Carga de soporte digitalizado | Como cliente, quiero adjuntar un archivo ya digitalizado, para completar documentación. | — | 5 |
mobile post-mvp
|
2 |
PDF §2.3 KYC · §5.2 onboarding / biometría / billetera.
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-44 | HU - 44. Mockup Móvil | Como producto, quiero un mockup de aviso, billetera y onboarding, para validar los momentos de verdad. | — | 3 |
mobile mvp
|
3 |
| HU-45 | HU - 45. Onboarding con datos y documento | Como nuevo cliente, quiero registrarme con datos y documento, para asociar una póliza sin ir a una oficina. | — | 3 |
mobile mvp
|
5 |
| HU-46 | HU - 46. Consentimiento de datos | Como cliente, quiero otorgar o revocar consentimiento de forma auditable, para cumplir habeas data. | — | 3 |
mobile mvp
|
3 |
| HU-47 | HU - 47. Consulta de póliza (payload ligero) | Como cliente, quiero ver pólizas y coberturas con payload ligero, para acreditar cobertura en movilidad. | 2, 6 | 3 |
mobile mvp
|
3 |
| HU-48 | HU - 48. Onboarding con prueba de vida (stub) | Como nuevo cliente, quiero un resultado simulado de verificación (ok / no) tras selfie, para un KYC más estricto sin el informe del proveedor de identidad. | — | 5 |
mobile post-mvp
|
5 |
| HU-49 | HU - 49. Autenticación biométrica | Como cliente, quiero entrar con huella o rostro, para acceder rápido y seguro. | — | 5 |
mobile post-mvp
|
8 |
| HU-50 | HU - 50. Fallback de biometría | Como cliente, quiero un acceso alterno si la biometría falla, para no quedar bloqueado. | — | 5 |
mobile post-mvp
|
3 |
| HU-51 | HU - 51. Billetera offline | Como cliente, quiero ver coberturas sin red, para acreditar el seguro en el momento. | — | 5 |
mobile post-mvp
|
8 |
| HU-52 | HU - 52. Sincronizar billetera al recuperar red | Como cliente, quiero que la app sincronice al volver la red, para no gestionar el conflicto a mano. | — | 5 |
mobile post-mvp
|
5 |
PDF §5.1 #5 · §2.4. Orden: HU-53 → HU-54 → HU-55; HU-56 puede probarse con HU-54/55; UIs HU-57 / HU-58.
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-53 | HU - 53. Consentimiento de perfilamiento | Como cliente en originación, quiero registrar consentimiento para usar datos de perfil, para poder llamar al adaptador (sin el flujo real de Finanzas Abiertas). | 5 | 2 |
core api mvp
|
2 |
| HU-54 | HU - 54. Adaptadores stub Open Finance / Open Data | Como plataforma, quiero fuentes simuladas detrás de adaptadores sustituibles, para perfilar sin banco ni catálogo Open Data reales (el stub define 2–3 atributos propios, no el API del tercero). | 5 | 2 |
core api mvp
|
3 |
| HU-55 | HU - 55. Perfil y oferta explicable | Como cliente o asesor, quiero un perfil y una oferta armados por Solventa a partir del stub, para ver precio y unos factores internos en el mismo flujo. | 5 | 2 |
core mvp
|
5 |
| HU-56 | HU - 56. Degradar perfilamiento lento | Como plataforma, quiero completar la oferta con valor de respaldo si el stub llega tarde o falla, para no perder la originación (simula el timeout de §4). | 5 | 2 |
core api mvp
|
3 |
| HU-57 | HU - 57. UI móvil oferta vida hipotecario | Como cliente en el flujo de crédito, quiero ver la oferta que armó Solventa, para decidir en originación. | 5 | 3 |
mobile mvp
|
3 |
| HU-58 | HU - 58. UI web perfil y oferta | Como asesor hipotecario, quiero ver esa misma oferta interna en el portal, para explicarla sin salir del flujo. | 5 | 3 |
web mvp
|
3 |
PDF §5.1 #6: un verbo = una HU.
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-59 | HU - 59. Renovar póliza | Como operador, quiero renovar una póliza vigente, para que el cliente no pierda cobertura. | 6 | 4 |
web core mvp
|
3 |
| HU-60 | HU - 60. Modificar póliza | Como operador, quiero cambiar datos o coberturas, para ajustar la póliza sin reemitir desde cero. | 6 | 4 |
web core mvp
|
3 |
| HU-61 | HU - 61. Cancelar póliza | Como operador, quiero cancelar y ver el estado en consulta, para cumplir el retiro de cobertura. | 6 | 4 |
web core mvp
|
2 |
| HU-62 | HU - 62. Reporte al regulador (stub) | Como cumplimiento, quiero exportar un extracto interno de pólizas/siniestros, para demostrar el paso §5.1 #6 sin el formato real de la Superintendencia. | 6 | 4 |
web api mvp
|
3 |
| HU-63 | HU - 63. Reporte a reaseguradora (stub) | Como operaciones, quiero generar un extracto de cartera/siniestralidad por adaptador, para no acoplar el núcleo a ACORD u otro esquema de la reaseguradora. | 6 | 4 |
web api mvp
|
3 |
| HU-64 | HU - 64. Aviso de vencimiento | Como cliente, quiero enterarme antes del vencimiento (in-app o canal stub), para no perder cobertura por olvido. | 6 | 4 |
mobile mvp
|
2 |
| HU-65 | HU - 65. Aviso de renovación efectiva | Como cliente, quiero confirmación cuando la renovación queda vigente, para saber que sigo cubierto (sin el payload de un proveedor de push). | 6 | 4 |
mobile mvp
|
2 |
| HU-66 | HU - 66. Autoservicio web | Como cliente en escritorio, quiero consultar y gestionar lo básico sin asesor. | — | 5 |
web post-mvp
|
5 |
| HU-67 | HU - 67. Orquestador maestro web | Como operador, quiero que cada capacidad en alcance tenga entrada de UI, para no dejar APIs huérfanas. | — | 5 |
web post-mvp
|
8 |
| HU-68 | HU - 68. Eventos para analítica | Como analítica, quiero consumir eventos de negocio sin leer la BD transaccional, para no mover el p95 de venta. | — | 5 |
api post-mvp
|
5 |
| HU-69 | HU - 69. Tableros y SLAs | Como operaciones, quiero volúmenes, SLAs y anomalías, para monitorear sin acoplarme al camino transaccional. | — | 5 |
web post-mvp
|
5 |
PDF §5.2: dos clientes + socios → BFF versionado. Enabler de §5.1.
Harness y ambientes (estrategia de pruebas §§2.2, 4.1–4.4): el lab es HU de E7 (mvp en S3). Una prueba que demuestra un recorrido §5.1 es aceptación de esa HU de journey, no otra historia. BackstopJS/VRT, exploratorias y los experimentos PR/PD/PS (salvo el ambiente que los sostiene) no son HU de producto.
Orden: HU-70 → HU-71; BFF HU-72/73 → JWT/RBAC HU-74…77; HU-78 → HU-89; harness HU-85 → HU-86 / HU-87 en paralelo; HU-88 (dobles + Pact) antes de integración; HU-83 usa HU-86/87; HU-79 corre sobre HU-89.
| ID | Summary | Como, quiero, para | §5.1 | Ola | Labels | SP |
|---|---|---|---|---|---|---|
| HU-70 | HU - 70. Repositorios del equipo | Como equipo, quiero repos de web, móvil y backend, para trabajar con el mismo origen de código. | — | 1 |
devops mvp
|
2 |
| HU-71 | HU - 71. Imágenes Docker base | Como equipo, quiero una imagen base documentada, para que local y CI arranquen igual. | — | 1 |
devops mvp
|
3 |
| HU-72 | HU - 72. Contrato BFF Web | Como dev web, quiero un BFF versionado para cotizar, emitir, gestionar y siniestros, para no hablar con el núcleo a pelo. | — | 2 |
api mvp
|
5 |
| HU-73 | HU - 73. Contrato BFF Móvil | Como dev móvil, quiero un BFF con payloads acotados, para aviso, billetera y cotización sin el contrato web. | — | 2 |
api mvp
|
5 |
| HU-74 | HU - 74. Validar JWT Web | Como admin, quiero que el gateway web valide firma, expiración y alcances, para no confiar en el cliente. | — | 3 |
api mvp
|
3 |
| HU-75 | HU - 75. Autorizar roles Web | Como admin, quiero denegar en servidor acciones fuera de rol (asesor, operador, socio), para evitar elevation of privilege. | — | 3 |
api mvp
|
3 |
| HU-76 | HU - 76. Validar JWT Móvil | Como seguridad, quiero el mismo control de token en el BFF móvil, para no duplicar una autenticación débil. | — | 3 |
api mvp
|
2 |
| HU-77 | HU - 77. Autorizar roles Móvil | Como seguridad, quiero ignorar roles mandados en el cuerpo de la app, para que solo el servidor autorice. | — | 3 |
api mvp
|
2 |
| HU-78 | HU - 78. Red y clúster cloud (mínimo) | Como arquitectura, quiero un despliegue IaC destruible, para evidenciar ambientes iguales. | — | 1 |
devops mvp
|
5 |
| HU-79 | HU - 79. Pruebas de carga de cotización | Como arquitectura, quiero un experimento de pico sobre §5.1 #1, para ver si se sostiene el presupuesto de latencia (la meta está en SBA; corre sobre HU-89). | 1 | 1 |
devops mvp
|
5 |
| HU-80 | HU - 80. Panel de socios | Como socio, quiero ver ventas, consumo de API e integraciones, para operar sin pedir cada dato a Solventa. | — | 5 |
web post-mvp
|
5 |
| HU-81 | HU - 81. Aislamiento de cuota por socio | Como plataforma, quiero limitar al socio a su cuota, para que uno no degrade a los demás. | — | 5 |
api post-mvp
|
5 |
| HU-82 | HU - 82. Monitores en vivo | Como SRE, quiero alertas de latencia y error en venta y siniestros, para detectar fallas. | — | 5 |
devops post-mvp
|
5 |
| HU-83 | HU - 83. Framework E2E | Como calidad, quiero el runner de un recorrido feliz §5.1 #1 o #3 (Cucumber/Gherkin en web, JUnit Compose en móvil), para instalar el framework en S3; ejecutar los seis recorridos es aceptación de las HU de journey. | — | 1 |
devops web mobile mvp
|
8 |
| HU-84 | HU - 84. SAST en CI/CD | Como seguridad, quiero SAST que falle el pipeline en hallazgo bloqueante, para no promover vulnerabilidades base. | — | 5 |
devops post-mvp
|
2 |
| HU-85 | HU - 85. Harness unitario del núcleo (PyTest) | Como equipo, quiero PyTest en CI sobre el dominio Python, para verificar reglas y cálculos una sola vez (estrategia §4.1). | — | 1 |
core devops mvp
|
2 |
| HU-86 | HU - 86. Harness unitario web (Karma) | Como equipo, quiero Karma sobre AngularJS/TypeScript en CI, para cubrir presentación del canal web aislada del núcleo (estrategia §4.2). | — | 2 |
web devops mvp
|
3 |
| HU-87 | HU - 87. Harness unitario móvil (JUnit) | Como equipo, quiero JUnit de Kotlin (sin emulador cuando no hay UI), para cubrir presentación, cola local e idempotencia del canal móvil (estrategia §4.3). | — | 2 |
mobile devops mvp
|
3 |
| HU-88 | HU - 88. Ambiente de integración con dobles | Como calidad, quiero un ambiente donde OF, Open Data, KYC y pagos sean dobles detrás de adaptadores, y Pact (CDC) verifique contratos BFF/API socios, para ensamblar sin terceros reales (estrategia §§2.1, 4.1; PI-01). | — | 1 |
api devops mvp
|
5 |
| HU-89 | HU - 89. Ambiente cloud de experimentos | Como arquitectura, quiero un ambiente de prueba en nube, distinto del despliegue mínimo de HU-78, con K6 o JMeter apuntando a cotización, para correr PR-01 (y luego PR-02/PR-03) y cerrar el pendiente de estrategia §4.4. | 1 | 1 |
devops mvp
|
5 |