Atributos de Calidad
y Tácticas Arquitectónicas
Ingeniería de Software
Arquitectura de Software · 7.º ciclo
Logro de Aprendizaje
Al finalizar la sesión, el estudiante identifica, especifica y prioriza atributos de
calidad mediante escenarios medibles, seleccionando tácticas arquitectónicas
justificadas y analizando sus trade-offs.
Temario
• Calidad en arquitectura: atributo, requisito, escenario y táctica
• Quality Attribute Scenarios y drivers arquitectónicos
• Rendimiento, disponibilidad, confiabilidad y seguridad
• Modificabilidad, testabilidad, escalabilidad e interoperabilidad
• Trade-offs, Utility Tree y método de razonamiento arquitectónico
1. ¿Por qué importan los atributos de calidad?
•Las funcionalidades indican qué hace el sistema; la
calidad indica qué tan bien lo hace.
•Muchas decisiones arquitectónicas nacen de
necesidades de rendimiento, seguridad,
disponibilidad o cambio.
•Dos sistemas con la misma funcionalidad pueden
requerir arquitecturas completamente distintas.
Sistema A
Tienda pequeña
100 operaciones/día
Sistema B
Marketplace
Miles TPS · 24/7
Misma función:
“registrar venta”
Arquitecturas diferentes
por drivers de calidad
4
2. Conceptos que no son equivalentes
Concepto
Pregunta clave
Ejemplo
Requisito funcional
¿Qué hace?
Consultar calificaciones
Atributo de calidad
¿Qué tan bien?
95% de respuestas < 2 s
Restricción
¿Qué límite se impone?
Usar PostgreSQL
Táctica
¿Qué decisión ayuda?
Caché, replicación, cifrado
Error frecuente: escribir “el sistema debe ser rápido” no basta; debe transformarse en un
escenario medible.
5
3. Drivers arquitectónicos
Funcionalidades críticas
Ej. procesar pagos
Atributos de calidad
Rendimiento, seguridad...
Restricciones
Costo, tecnología, leyes
Influyen directamente en la arquitectura
•Los drivers son requisitos o restricciones con impacto estructural significativo.
•Ayudan a justificar por qué se elige una arquitectura y no otra.
6
4. Modelo ISO/IEC 25010:2023
Adecuación funcional
Eficiencia de desempeño
Compatibilidad
Capacidad de interacción
Fiabilidad
Seguridad
Mantenibilidad
Flexibilidad
Safety
En arquitectura se suelen analizar atributos más concretos: disponibilidad, modificabilidad, escalabilidad,
testabilidad e interoperabilidad.
7
5. Escenarios de atributos de calidad (QAS)
Fuente
Estímulo
Artefacto
Entorno
Respuesta
Medida
Un QAS evita ambigüedades: define quién provoca el evento, sobre qué parte del sistema, en qué
contexto y cómo se medirá la respuesta.
•Ejemplo: “95% de consultas de cursos en menos de 2 segundos con 8 000 usuarios concurrentes”.
8
6. De la necesidad a la arquitectura
Necesidad
de negocio
Driver
Atributo
Escenario
Táctica
Patrón /
Tecnología
Medición
No se parte de la tecnología. Se parte de una necesidad verificable y se justifican las
decisiones.
9
7. Rendimiento: qué medir
Métrica
Qué expresa
Ejemplo
Latencia
Tiempo por operación
350 ms
Throughput
Operaciones por tiempo 2 000 req/s
Concurrencia
Usuarios simultáneos
Utilización
Uso de recursos
Rendimiento no es una
sensación: debe expresarse con
métricas y contexto de carga.
10 000 usuarios
CPU < 70%
Ejemplo QAS
95% < 2 s
con 10 000 usuarios
10
8. Tácticas de rendimiento
Controlar demanda
•reducir procesamiento
•limitar frecuencia
•priorizar eventos
•cachear resultados
•procesamiento diferido
Administrar recursos
•aumentar recursos
•concurrencia
•replicar recursos
•balanceo de carga
•pools y distribución
Táctica ≠ herramienta: Redis no es “rendimiento”; Redis puede implementar una táctica de caché.
11
9. Ejemplo: caché para consultas frecuentes
Usuario
API
Si el dato está en caché, se evita consultar la
base de datos.
Redis
Cache
Base de
datos
Trade-off: invalidación, consistencia, memoria y
complejidad.
12
10. Disponibilidad: estar operativo cuando se necesita
•Se relaciona con continuidad del servicio y
recuperación ante fallos.
•Puede aproximarse con MTBF y MTTR.
•Mejorar disponibilidad suele requerir
redundancia y operación automatizada.
Disponibilidad =
MTBF / (MTBF + MTTR)
Nivel
Caída anual aprox.
99 %
3 días 15 h
99.9 %
8 h 46 min
99.99 %
52 min
99.999 %
5 min
13
11. Tácticas de disponibilidad
Detectar fallos
•ping
•heartbeat
•health check
•timeouts
•monitoreo
Recuperarse
•retry
•restart
•rollback
•failover
•checkpoint
Evitar propagación
•aislamiento
•circuit breaker
•límites
•transacciones
•nodos sanos
Disponibilidad no significa que nunca falle; significa detectar, aislar y recuperarse dentro de un tiempo
aceptable.
14
12. Ejemplo: redundancia + balanceador
Servidor 1
Usuarios
Load
Balancer
Servidor 2
Base de datos
Servidor 3
Si un nodo falla, el balanceador redirige tráfico a los nodos sanos.
15
13. Confiabilidad e idempotencia
•Disponibilidad y confiabilidad no son lo mismo.
•Un sistema disponible puede responder con
resultados incorrectos.
•La confiabilidad exige evitar errores, detectar
inconsistencias y recuperar operaciones.
Pago S/100
Primer intento
Respuesta perdida
Reintento
Sin idempotencia: puede cobrarse dos veces.
Con Idempotency-Key: el sistema reconoce la
operación ya procesada.
16
14. Seguridad: proteger datos y operaciones
Confidencialidad
solo entidades autorizadas ven información
Integridad
datos no alterados indebidamente
Autenticidad
identidad verificable
Trazabilidad
se sabe quién hizo qué
No repudio
no negar acciones realizadas
La seguridad no es solo login: incluye protección, detección, reacción y recuperación.
17
15. Tácticas de seguridad
Resistir
•autenticación
•autorización
•cifrado
•mínimo privilegio
Detectar
•auditoría
•IDS
•logs
•monitoreo
Reaccionar
Recuperar
•bloquear cuentas
•revocar tokens
•aislar servicios
•rate limiting
•restaurar
•rotar credenciales
•parchar
•reconstruir
Trade-off típico: más controles de seguridad pueden aumentar latencia, costo y complejidad.
18
16. Modificabilidad: costo de cambiar
•Evalúa cuánto software debe modificarse ante un
cambio.
•Cambios frecuentes: reglas de negocio,
proveedores, regulaciones, tecnología e
integraciones.
•Se favorece con alta cohesión y bajo acoplamiento.
Stripe API
directa
OrderService
Cambio a PayPal = modificar lógica de negocio
PaymentGateway
<<interface>>
Mejor: encapsular proveedores mediante
interfaces y adapters.
19
17. Tácticas de modificabilidad
Aumentar cohesión
Reducir acoplamiento
Encapsular cambios
Separar responsabilidades
Usar interfaces
Diferir decisiones
Introducir intermediarios
Una arquitectura modificable localiza el impacto del cambio y evita que una modificación se
propague por todo el sistema.
20
18. Testabilidad: controlar y observar
Controlabilidad
•dependency injection
•mocks / stubs
•configuración externa
•datos de prueba
Observabilidad
•logs
•métricas
•tracing
•eventos de diagnóstico
Una decisión como inyección de dependencias mejora testabilidad y también modificabilidad.
21
19. Escalabilidad: crecer sin colapsar
•No es igual a rendimiento: un sistema puede ser
rápido con 100 usuarios y fallar con 5 000.
•Se evalúa ante aumento de usuarios, datos,
solicitudes y transacciones.
•Puede lograrse vertical u horizontalmente.
Vertical
Más CPU/RAM
Horizontal
Más nodos
Servicios stateless facilitan balanceo y
escalamiento horizontal.
Costos: consistencia, coordinación, monitoreo y
complejidad distribuida.
22
20. Tácticas de escalabilidad
Escalamiento horizontal
Balanceo de carga
Particionamiento
Sharding
Caché
Procesamiento asíncrono
Replicación
Colas
Auto-scaling
La escalabilidad debe diseñarse alrededor de cuellos de botella reales, no por moda tecnológica.
23
21. Interoperabilidad
•Capacidad de intercambiar información y utilizarla
correctamente.
•Requiere acuerdo en protocolo, formato,
semántica, seguridad y errores.
•Es clave cuando el sistema se integra con bancos,
laboratorios, pasarelas de pago o sistemas públicos.
Sistema A
Sistema B
Adapter / API
Tácticas: estándares abiertos, contratos,
versionado, adapters y modelos canónicos.
24
22. Usabilidad, flexibilidad y safety
Atributo
Preocupación
Tácticas
Capacidad de interacción
uso correcto y aprendizaje
feedback, prevención de errores
Flexibilidad
adaptación a contextos y recursos
configuración, reemplazo, portabilidad
Safety
evitar daños inaceptables
fail-safe, alarmas, estados seguros
Security evita accesos o acciones maliciosas. Safety evita que el sistema cause daños a personas,
infraestructura o entorno.
25
23. Trade-offs: ninguna táctica es gratis
Replicación
Mejora:
disponibilidad
rendimiento de lectura
escalabilidad
Puede perjudicar:
consistencia
costo
operación
El arquitecto no busca una táctica perfecta; busca un equilibrio justificable.
26
24. Matriz resumida de impacto
Táctica
Rend.
Disp.
Seg.
Modif.
Escal.
Caché
++
+
0/-
-
+
Replicación
+
++
0
-
++
Balanceo
+
++
0
0
++
Cifrado
-
0
++
0
0
Modularización
0
+
0
++
+
Mensajería asíncrona
+
+
0
+
++
Circuit Breaker
+
++
0
0
+
La matriz orienta la discusión, pero el impacto real depende del contexto y la implementación.
27
25. Utility Tree: priorizar calidad
CALIDAD
Rendimiento
Disponibilidad
Seguridad
Modificabilidad
Consulta < 2 s
5 000 matrículas/min
99.95% mensual
recuperación < 30 s
cifrar datos
rechazar accesos ajenos
nuevo proveedor pago < 3
días
Los escenarios de alta importancia y alto riesgo se atienden primero.
28
26. Caso CampusPlus: decisiones justificadas
•Plataforma universitaria con matrícula, cursos,
pagos, notas, asistencia y notificaciones.
•Drivers: alta concurrencia en matrícula,
seguridad de notas y pagos, integración con
servicios externos.
•Cada decisión debe vincularse a un atributo y
una táctica.
API Gateway
seguridad
Redis
rendimiento
Broker
desacoplamiento
Servicios
modificabilidad
Arquitectura resultante = combinación de
tácticas para cumplir escenarios de calidad.
29
27. Caso MediFast: ejercicio de análisis
•Sistema para clínicas: pacientes, citas, historias
clínicas, teleconsultas, pagos y recetas.
•Escala esperada: 50 000 usuarios, 3 000
concurrentes, operación 24/7.
•Datos clínicos altamente sensibles e integración
con laboratorios externos.
Atributo
Justificación
Seguridad
datos médicos sensibles
Disponibilidad
servicio 24/7
Interoperabilidad
laboratorios externos
Escalabilidad
nuevas clínicas
Modificabilidad
nuevas funciones
Actividad sugerida: redactar 4 QAS y proponer 2 tácticas por escenario.
30
28. Errores frecuentes de razonamiento
Razonamiento débil
Razonamiento arquitectónico
“Necesitamos microservicios”
¿Qué drivers lo justifican?
“Redis hará rápido el sistema”
¿Qué dato, carga y latencia medimos?
“Kubernetes es moderno”
¿Necesitamos HA, autoescalado y despliegues frecuentes?
“Debe ser seguro”
¿Contra qué amenaza y con qué medida?
La arquitectura debe evitar decisiones por moda y justificar cada tecnología con un escenario de
calidad.
31
29. Método de trabajo para el arquitecto
1. Identificar requisitos
2. Detectar drivers
3. Redactar QAS
4. Priorizar
5. Seleccionar tácticas
6. Diseñar estructuras
7. Evaluar trade-offs
8. Medir y refinar
El proceso es iterativo: las mediciones pueden obligar a cambiar tácticas o replantear escenarios.
32
30. Ideas clave para recordar
Funcionalidad ≠ calidad
Atributo → escenario medible
Escenario → tácticas
Tácticas → decisiones arquitectónicas
Toda táctica tiene trade-offs
No existe “la mejor arquitectura”, sino la más
apropiada para los drivers
33
31. Cierre
Cadena de razonamiento arquitectónico
Negocio
Requisitos
Drivers
Atributos
Tácticas
Patrones
Tecnologías
Medición
QAS
Una arquitectura madura no se justifica por herramientas, sino por decisiones trazables, medibles
y evaluadas.
34