Los modelos de calidad: ISO/IEC 25010 y cómo usarla

Para qué sirve un modelo de calidad

La Sección 2.1 argumentó que los atributos de calidad deciden la mayor parte de una arquitectura. La siguiente pregunta obvia es: ¿qué cualidades? Si se las deja a su aire, las partes interesadas mencionan las dos o tres que les hicieron daño la última vez, normalmente la velocidad y el tiempo de actividad, y se olvidan del resto hasta que es demasiado tarde. Un modelo de calidad es una lista estructurada de características de calidad, cada una dividida en subcaracterísticas más concretas, con nombres y definiciones acordados. Cumple dos funciones. Da a las personas un vocabulario compartido, para que 'fiabilidad' signifique lo mismo para el product owner, el tester y el proveedor. Y actúa como lista de comprobación, que te lleva a considerar cualidades que nadie ha planteado todavía.

Un modelo no te dice qué cualidades importan para tu sistema ni cuánto necesitas de cada una. Eso sale de las partes interesadas y de los objetivos de negocio (Sección 2.8). Tampoco te dice cómo lograrlas; esa es la tarea de las tácticas, los patrones y el resto de este curso. Es un mapa del territorio, no una ruta a través de él.

ISO/IEC 25010:2023: el modelo de calidad del producto

El modelo más citado es ISO/IEC 25010, que forma parte de la familia de normas SQuaRE (Systems and software Quality Requirements and Evaluation). La segunda edición, publicada en noviembre de 2023, define un modelo de calidad del producto con nueve características. Se aplica a los productos de software y a los productos TIC en general, y la norma enumera sus usos: especificar requisitos, comprobar que los requisitos están completos, fijar objetivos de diseño y de prueba, definir criterios de aceptación y establecer medidas de calidad. Otras normas de la familia definen cómo medir cada subcaracterística (ISO/IEC 25023) y cómo evaluar un producto.

Las nueve características son adecuación funcional, eficiencia de rendimiento, compatibilidad, capacidad de interacción, fiabilidad, seguridad, mantenibilidad, flexibilidad y seguridad (safety). La primera describe si el sistema hace lo correcto y lo hace bien; las otras ocho describen con qué calidad lo hace y lo bien que puede operarse, protegerse y cambiarse. El diagrama siguiente muestra la estructura; la tabla posterior enumera todas las subcaracterísticas con una pregunta de ejemplo que podría hacerse un arquitecto.

Conviene conocer con precisión algunas definiciones, porque difieren del uso cotidiano. En ISO/IEC 25010, la disponibilidad es una subcaracterística de la fiabilidad: el grado en que un sistema está operativo y accesible cuando se necesita. La ausencia de defectos es el grado en que un sistema realiza sus funciones sin defectos en funcionamiento normal. La capacidad, dentro de la eficiencia de rendimiento, es el límite máximo de un parámetro, como los usuarios simultáneos o las transacciones por segundo, que todavía cumple los requisitos. La escalabilidad se sitúa dentro de la flexibilidad, lo que refleja una visión del escalado como la capacidad de adaptarse a una carga cambiante más que como una cuestión de velocidad bruta. La resistencia, nueva dentro de la seguridad, es la capacidad de mantener las operaciones mientras se sufre un ataque. Las Secciones 2.4 a 2.7 vuelven a estas cualidades en profundidad; la Sección 2.5 muestra cómo calcular la disponibilidad.

Qué cambió respecto a la edición de 2011

La primera edición, ISO/IEC 25010:2011, sustituyó al antiguo modelo ISO/IEC 9126 y fue la referencia estándar durante una década. Muchos libros de texto, pliegos de licitación y plantillas todavía usan sus ocho características, así que merece la pena saber qué cambió.

Los cambios de nombre son más que cosméticos. 'Capacidad de interacción' amplía el enfoque de la facilidad de uso a todo el intercambio de información entre los usuarios y el producto en distintos contextos de uso, y la nueva subcaracterística de inclusividad sitúa la accesibilidad para personas de distintas edades y capacidades en el centro y no en los márgenes. 'Flexibilidad' agrupa las cualidades que permiten a un producto hacer frente a los cambios en su entorno: nuevas plataformas, nuevos destinos de instalación y más o menos carga. Añadir la seguridad (safety) como característica del producto refleja cuánto controla hoy el software cosas físicas, desde automóviles hasta dispositivos médicos.

El segundo cambio estructural es que la calidad en uso, la calidad que experimentan las personas que usan el producto en un contexto real, tiene ahora su propia norma, ISO/IEC 25019:2023. Sus tres características son el beneficio (usabilidad, accesibilidad e idoneidad en el uso), la ausencia de riesgos (riesgo económico, para la salud, para la vida humana, y riesgo ambiental y social) y la aceptabilidad (experiencia, confiabilidad y cumplimiento). La separación aclara una distinción útil para los arquitectos: la calidad del producto es lo que construyes y puedes probar en el producto; la calidad en uso es el resultado para personas reales, que también depende de la formación, el contexto y cómo se despliega el producto.

Otras listas que encontrarás

ISO/IEC 25010 no es la única taxonomía, y los profesionales usan a menudo listas más sencillas o divididas de otra forma. FURPS+ surgió de FURPS, una clasificación desarrollada en Hewlett-Packard y expuesta por Robert Grady y Deborah Caswell en Software Metrics: Establishing a Company-Wide Program (1987). FURPS agrupa los requisitos en funcionalidad, usabilidad, fiabilidad, rendimiento y soportabilidad; la extensión '+' posterior añade restricciones: de diseño, de implementación, de interfaz y físicas y, en algunas versiones, reglas de negocio. FURPS+ se popularizó a través del Rational Unified Process y sus sucesores. Su punto fuerte es la brevedad; su punto débil es que la 'soportabilidad' mete en el mismo saco la mantenibilidad, la capacidad de prueba, la configurabilidad, la instalabilidad y la localización.

Bass, Clements y Kazman, en la cuarta edición de Software Architecture in Practice (2021), no intentan ser exhaustivos. Dedican un capítulo a cada una de las cualidades que con más frecuencia guían las arquitecturas: disponibilidad, desplegabilidad, eficiencia energética, integrabilidad, modificabilidad, rendimiento, seguridad (safety), seguridad, capacidad de prueba y usabilidad, seguidos de un capítulo sobre cómo trabajar con otras cualidades. Para cada una, ofrecen un escenario general y un catálogo de tácticas. Su lista está organizada en torno al diseño y no a la evaluación, lo que la hace especialmente útil para los arquitectos.

Mark Richards y Neal Ford, en Fundamentals of Software Architecture, usan el término características de la arquitectura y las ordenan en grupos como el operativo (disponibilidad, rendimiento, escalabilidad), el estructural (modificabilidad, extensibilidad, portabilidad) y el transversal (seguridad, accesibilidad, aspectos legales). El modelo abierto Q42 de Gernot Starke, mantenido junto a la plantilla arc42, adopta otro enfoque más: etiqueta mucho más de un centenar de cualidades con nombre con nueve dimensiones (eficiente, flexible, mantenible, operable, fiable, seguro ante daños, seguro ante ataques, adecuado, usable) y ofrece requisitos de ejemplo para cada una.

Estas listas discrepan en los detalles, pero se solapan en gran medida. La propia discrepancia es instructiva: no existe una única descomposición correcta de la 'calidad', solo descomposiciones más o menos útiles para un fin. Usar un modelo estándar ayuda cuando necesitas comunicarte con compras, auditores u otras organizaciones; una lista más ligera puede servirle mejor a un equipo de producto en el día a día.

Usar un modelo como lista de comprobación sin crear burocracia

El gran riesgo de un modelo de calidad es que se convierta en un formulario. Una plantilla de requisitos con un apartado para cada una de las 40 subcaracterísticas invita a rellenar todas las casillas, y el resultado es un documento lleno de afirmaciones como 'el sistema será mantenible' que nadie lee y nadie prueba. El esfuerzo se reparte por igual entre cualidades que importan de forma muy desigual, y las dos o tres cualidades que de verdad decidirán la arquitectura se pierden entre las demás.

Un enfoque mejor trata el modelo como punto de partida para una conversación. Recorre las características con las partes interesadas una vez, rápidamente, preguntando para cada una: ¿importa esto para nuestro sistema y, si es así, cómo sería un fallo? Descarta explícitamente las que no sean pertinentes (escribir 'seguridad (safety): no aplicable, la app no puede causar daños físicos' es útil, porque registra una decisión). Convierte las pertinentes en un pequeño número de escenarios concretos y medibles (Sección 2.3). Ordénalos (Sección 2.8). Después guarda el modelo hasta la próxima revisión.