En pocas palabras
Técnica del SEI para especificar atributos de calidad mediante escenarios de seis partes y priorizarlos en un árbol de utilidad, base de métodos de evaluación como ATAM.
Qué problema resuelve
Requisitos no funcionales ambiguos («debe ser rápido») que no permiten decidir entre opciones ni verificar el resultado.
Cuándo utilizarlo
Al iniciar un sistema, antes de una decisión estructural o en una revisión de arquitectura. Ejemplo: decidir si el scoring debe ser síncrono o asíncrono.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
Escenario en seis partes
| Parte | Pregunta | Ejemplo |
|---|---|---|
| Fuente | ¿Quién o qué genera el estímulo? | Clientes de la app móvil |
| Estímulo | ¿Qué ocurre? | 500 solicitudes de crédito por minuto |
| Artefacto | ¿Qué parte del sistema afecta? | API de solicitudes |
| Entorno | ¿En qué condiciones? | Campaña comercial, operación normal |
| Respuesta | ¿Qué debe hacer el sistema? | Aceptar y encolar todas las solicitudes |
| Medida de respuesta | ¿Cómo se verifica? | p95 de aceptación < 800 ms y 0 solicitudes perdidas |
Comparado con «el sistema debe ser escalable», el escenario permite decidir (encolar en lugar de evaluar en línea) y probar (prueba de carga con k6).
Atributos más habituales
Disponibilidad, rendimiento, seguridad, modificabilidad, escalabilidad, observabilidad, interoperabilidad, usabilidad, testabilidad y coste. ISO/IEC 25010 ofrece una taxonomía completa útil como lista de comprobación.
Árbol de utilidad
Agrupa los escenarios por atributo y puntúa cada uno en dos ejes:
| Escenario | Importancia para negocio | Dificultad técnica |
|---|---|---|
| Pico de 500 solicitudes/min en campaña | A | M |
| Recuperar el servicio en < 15 min tras caída regional | A | A |
| Añadir un nuevo país en < 4 semanas | A | A |
| Cambiar el proveedor de SMS en < 2 días | M | B |
Los escenarios (A, A) son los que deben guiar la arquitectura y las revisiones.
Del escenario a la decisión: tácticas
Para cada escenario prioritario identifica tácticas que lo satisfacen y su coste en otros atributos:
| Atributo | Tácticas | Tensión típica |
|---|---|---|
| Disponibilidad | Redundancia, health checks, failover, resiliencia | Coste, consistencia |
| Rendimiento | Caché, colas, paralelismo, réplicas de lectura | Consistencia, complejidad |
| Modificabilidad | Módulos cohesivos, interfaces estables, inversión de dependencias | Rendimiento |
| Seguridad | Autenticación fuerte, mínimo privilegio, cifrado, auditoría | Usabilidad, rendimiento |
Los puntos de sensibilidad (decisiones que afectan mucho a un atributo) y los trade-offs (decisiones que afectan a varios en sentidos opuestos) son el resultado más valioso de un ATAM.
Revisión ligera en una mañana
- Negocio presenta objetivos y restricciones (30 min).
- Arquitectura presenta el diseño con C4 (45 min).
- Construcción del árbol de utilidad en grupo (60 min).
- Análisis de los cinco escenarios prioritarios contra el diseño (90 min).
- Riesgos, no-riesgos, sensibilidades y trade-offs; acciones con dueño (15 min).
Más escenarios de ejemplo
| Atributo | Escenario |
|---|---|
| Seguridad | Un atacante con credenciales robadas de un asesor intenta descargar datos de clientes de otra sucursal; el sistema lo impide, registra el intento y alerta en < 5 min |
| Disponibilidad | Cae una zona de la región principal en horario pico; el servicio sigue aceptando solicitudes con p95 < 2 s y sin pérdida de datos |
| Modificabilidad | Cambia la tasa máxima legal; el cambio se configura y despliega en producción en menos de un día sin código nuevo |
| Interoperabilidad | Un nuevo socio comercial se integra a la API de originación en menos de dos semanas usando la documentación y el sandbox |
| Observabilidad | Ante una queja de un cliente, soporte localiza la traza completa de su solicitud en < 2 min |
| Coste | Duplicar el volumen de solicitudes no incrementa el coste de infraestructura más de un 40 % |
| Testabilidad | Un cambio en reglas de scoring puede validarse con 500 casos históricos en < 15 min |
Resultado de una evaluación (formato ATAM)
| Tipo | Ejemplo |
|---|---|
| Riesgo | La consulta síncrona al buró hace que la disponibilidad de originación dependa de un tercero sin SLA |
| No-riesgo | El uso de colas para notificaciones cumple el escenario de pico de campaña |
| Punto de sensibilidad | El tamaño del pool de conexiones determina la latencia en picos |
| Trade-off | Cifrar campos a nivel de aplicación mejora seguridad pero impide búsquedas por documento |
Los riesgos se agrupan en temas de riesgo («dependencia de terceros sin aislamiento») que se presentan a la dirección junto con los objetivos de negocio a los que amenazan.
Integrarlo en el ciclo de producto
- Al iniciar un sistema o una iniciativa grande: árbol de utilidad con negocio.
- En cada ADR relevante: indicar qué escenarios atiende o empeora.
- En CI y operación: los escenarios prioritarios se convierten en fitness functions, SLO y pruebas de carga.
- Una vez al año: revisar si las prioridades de negocio han cambiado.
Criterios de implementación
Escribe los escenarios con negocio y operaciones, no solo con el equipo técnico. Convierte los prioritarios en fitness functions o en SLO, y referencia el escenario en los ADR que lo atienden.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.