El concepto de calidad nos atraviesa en todo momento y también es considerada en el programa de estudios del iSAQB Foundation Level Software Architecture, específicamente en su capítulo 4. Arquitectura de software y calidad.
Te comparto los objetivos de este capítulo para que puedas analizar hasta que punto la calidad es preocupación no sólo de los profesionales sino además de organizaciones que están empeñadas en mejorar ciertas prácticas de la industria del software.
Objetivos
OA 4-1: Debatir sobre modelos de calidad y características de calidad (R1)
Los arquitectos de software pueden:
- Explicar el concepto de calidad (basado en la norma DIN/ISO 25010, anteriormente 9126) y las
características de calidad. - Explicar los modelos de calidad genéricos (como DIN/ISO 25010).
- Explicar las correlaciones y compromisos de las características de calidad, por ejemplo:
◦ Configurabilidad frente a fiabilidad.
◦ Requisitos de memoria frente a la eficiencia de desempeño.
◦ Seguridad frente a usabilidad.
◦ Flexibilidad en tiempo de ejecución frente a mantenibilidad.
OA 4-2: Precisar los requisitos de calidad de las arquitecturas de software (R1)
Los arquitectos de software pueden:
- Aclarar y formular requisitos de calidad específicos para el software que se va a desarrollar y
sus arquitecturas, por ejemplo, en forma de escenarios y árboles de calidad. - Explicar y aplicar escenarios y árboles de calidad.
OA 4-3: Llevar a cabo un análisis cualitativo y una evaluación de las arquitecturas de software (R2 R3)
Los arquitectos de software:
- Conocen los enfoques metódicos para el análisis cualitativo y la evaluación de las arquitecturas
de software (R2), por ejemplo, como se especifica en ATAM (R3). - Pueden analizar y evaluar cualitativamente sistemas más pequeños (R2).
- Saben que las siguientes fuentes de información pueden ayudar en el análisis cualitativo y la
evaluación de las arquitecturas (R2):
◦ Requisitos de calidad, por ejemplo, en forma de árboles y escenarios de calidad.
◦ Documentación de la arquitectura.
◦ Arquitectura y modelos de diseño.
◦ Código fuente.
◦ Métricas.
◦ Otra documentación del sistema, como los requisitos, la documentación operativa o de
prueba.
OA 4-4: Llevar a cabo una evaluación cuantitativa de las arquitecturas de software (R2)
Los arquitectos de software conocen los enfoques para el análisis cuantitativo y la evaluación
(medición) del software. Ellos saben que:
- La evaluación cuantitativa puede contribuir a identificar las partes críticas dentro de los
sistemas. - Información adicional puede ser útil para la evaluación de las arquitecturas, por ejemplo:
◦ Documentación de requisitos y arquitectura.
◦ Código fuente y métricas relacionadas como líneas de código, complejidad
(ciclomática), dependencias de entrada y salida.
◦ Defectos conocidos en el código fuente, especialmente en las agrupaciones de defectos.
◦ Casos de prueba y resultados de prueba.
Acerca de la ISO 25010
La tabla que aquí te comparto está publicada en el sitio de las normas ISO 25000, y me pareció importante que conocieras este dato para complementar todo lo que contiene el capítulo 4 del programa de estudios de Arquitectura de Software.
Te compartiré a continuación un análisis efectuando en el que además describe la relación entre un especialista en Arquitectura de Software y un Test Manager como para que puedas tener un visión más global del alcance que tiene todo ésto.
Este análisis profundiza en Adecuación funcional, Eficiencia de desempeño y Seguridad, sin descuidar las demás, incorporando ejemplos prácticos, responsabilidades cruzadas y herramientas de medición.iso25000.com
1. Introducción
La calidad de un producto no es accidental; se diseña. ISO/IEC 25010 establece un vocabulario común que relaciona el trabajo de arquitectos y agile testers, asegurando que los requisitos no funcionales (NFR) se concreten en decisiones de diseño y se verifiquen con evidencia objetiva.
2. Características priorizadas
2.1 Adecuación funcional
Sub‑características: completitud, corrección, pertinencia.
- Arquitecto de Software: modela casos de uso y define patrones (p. ej., Domain‑Driven Design) que garanticen cobertura funcional.
- Test Manager: diseña matrices de trazabilidad requisitos‑prueba y lidera validaciones de aceptación.
Ejemplo: en un módulo de pagos, el arquitecto introduce un Command Handler para cada transacción; el agile tester ejecuta pruebas de frontera y caminos alternos para confirmar que ningún escenario quede sin cubrir.
2.2 Eficiencia de desempeño
Sub‑características: comportamiento temporal, utilización de recursos, capacidad.
- Arquitecto: selecciona estrategias de caching, balanceo y dimensiona contenedores.
- Test Manager: planifica stress y load testing, define SLIs/SLOs (p. ej., p99 < 300 ms).
Ejemplo: en una API REST, el arquitecto introduce CQRS y caché Redis; el agile tester usa JMeter para simular 5 000 RPS y monitorea CPU/RAM con APM.
2.3 Seguridad
Sub‑características: confidencialidad, integridad, no repudio, autenticidad, responsabilidad, resistencia.
- Arquitecto: define segregación de contextos, cifrado en tránsito/reposo y políticas zero trust.
- Test Manager: coordina SAST, DAST y pruebas de penetración; verifica cumplimiento OWASP Top 10.
Ejemplo: se integra OIDC; el tester automatiza escaneos con ZAP y reporta vulnerabilidades críticas.
3. Características complementarias
| Característica | Rol del Arquitecto | Rol del Test Manager | Herramienta/Práctica |
|---|---|---|---|
| Compatibilidad | Define contratos API y versionado | Ejecuta pruebas de integración y backward‑compatibility | Postman |
| Usabilidad (Capacidad de interacción) | Propone patrones UX, accesibilidad WCAG | Organiza tests de usabilidad A/B y heurísticos | Figma, Screen Reader |
| Fiabilidad | Implementa circuit breakers, health checks | Pruebas de resiliencia y chaos engineering | Gremlin |
| Mantenibilidad | Promueve modularidad, clean code y CI/CD | Mide cobertura, complejidad ciclomática y MTTR | SonarQube |
| Portabilidad (Flexibilidad) | Orquesta contenedores, IaC, 12‑factor | Ejecuta smoke tests en plataformas destino | Docker Compose |
Nota: la columna “Flexibilidad” se alinea conceptualmente con Portabilidad del estándar; “Protección” integra aspectos ya cubiertos por Seguridad y Compatibilidad
4. Ejemplos transversales
- Historia de usuario NFR: “Como Arquitecto quiero que la API procese 1 000 peticiones/seg con p95 < 200 ms para soportar el pico de ventas del Black Friday”.
- Definición de hecho terminado: pruebas de carga superadas; alertas Prometheus al 80 % de umbral.
- Defecto de adecuación: un flujo de cancelación no contemplado. El arquitecto actualiza el modelo; el tester agrega casos de regresión.
- Incidente de seguridad: token mal configurado. Se aplica defence‑in‑depth: hardening de cabeceras y pruebas automatizadas de seguridad en la tubería CI.
5. Medición y verificación
- Métricas clave
- Tiempo medio entre fallos (MTBF) → Fiabilidad.
- Uso de CPU por transacción → Eficiencia.
- Tasa de falsos positivos en autenticación → Seguridad.
- Tablero de calidad: combinar SonarQube, Grafana y OWASP Dependency‑Check para visualizar el estado de cada característica por build.
- Revisión arquitectónica orientada a la calidad: checklist de NFRs, pruebas pasadas y deuda técnica antes de cada release.
6. Buenas prácticas conjuntas
- Shifting‑left: involucrar a testing en las decisiones de arquitectura tempranas.
- Definition of Ready con criterios de NFR explícitos.
- Gate de calidad en CI: build falla si métricas mínimas no se alcanzan.
- Documentación viva: ADRs y test specs versionadas junto al código.
- Capacitación cruzada: sesiones mensuales donde arquitectos muestran patrones y testers presentan hallazgos de calidad.
7. Conclusiones
La ISO / IEC 25010 es el puente que une la visión estructural del Arquitecto con la verificación sistemática del Test Manager. Dominar sus características permite diseñar software sólido, eficiente y seguro, facilitando la confianza de los stakeholders y reduciendo costes de retrabajo. Incorporar la calidad desde la arquitectura e instrumentarla con pruebas rigurosas asegura que el producto no solo funcione, sino que trascienda en valor y mantenibilidad.
Referencias
- ISO/IEC 25010 – Product Quality Model. iso25000.com. iso25000.com
- ISO/IEC 25010:2011 Standard Abstract. iso.org. iso.org
- “What Is ISO 25010?” Perforce Blog. perforce.com
- Codacy Blog – “ISO 25010 Software Quality Model”. blog.codacy.com
- Pacific Certifications – “ISO 25010 Software Product Quality Model”.
Fuentes de inspiración
- https://www.isaqb.org/
- https://iso25000.com/index.php/normas-iso-25000/iso-25010
