Un modelo de calidad provee un framework para la especificación de requisitos de calidad y su evaluación en términos de un conjunto de características o atributos de calidad y sus relaciones. Estas características emergen desde el razonamiento acerca de la “esencia de la calidad” para un producto y contexto específicos. Por ejemplo, el modelo de calidad ISO 25010:2023 [1] se enfoca en sistemas y software.

La definición de un modelo de calidad sigue típicamente la vía de la estandarización. La estandarización no es una condición necesaria para la creación de un modelo de calidad; sin embargo, la estandarización sí es una característica importante que considerar cuando se evalúa adoptar un modelo de calidad: las organizaciones generalmente prefieren modelos publicados y estandarizados porque se tiene la razonable esperanza de que al usarlos también se alinearán con el estándar y otros relacionados.

Quiero compartir tres beneficios de usar un modelo de calidad en la producción de software:

• Evitar la sobre representación de atributos de calidad: el modelo de calidad nos ayuda a no olvidar “otras” características de calidad. Por ejemplo, el modelo de calidad ISO 25010:2023 nos ayuda a recordar que la ejecución de chequeo de “issues” de calidad en el código (típicamente en pipelines de integración continua) se tiende a relacionar con propiedades como la mantenibilidad y que por tanto también debemos atender otras propiedades como la confianza en el sistema y la flexibilidad del uso con técnicas y herramientas apropiadas.
• Evaluaciones de calidad más objetivas: el uso de un conjunto predefinido y eventualmente estandarizado de características de calidad promueve el foco en operacionalizaciones que permiten evaluar concreta y objetivamente la calidad de un sistema de software.
• Razonamiento respecto de decisiones de diseño (especialmente del pasado): la operacionalización de los atributos de calidad obliga al equipo a razonar acerca de muchas decisiones de diseño, especialmente del pasado. Los equipos se ven agradados al compartir información respecto de estas decisiones ya que les permite comprender la razón de ser de muchas de estas decisiones que típicamente se ven como «dudosas.»

Finalmente, me gustaría destacar cuatro asuntos en relación con el uso de modelos de calidad:

• Queda fuera del ámbito de un modelo de calidad definir la importancia relativa de los atributos de calidad: esto lo define el negocio en conjunto con sus objetivos, misión y visión. No obstante, sí es importante que esta priorización sea justificada y documentada, especialmente cuando algunas de estas características de calidad quedan con una prioridad muy baja (e.g., usabilidad vs. confidencialidad).
• En la práctica he observado muchas veces que se genera discusión respecto de si una operacionalización (e.g., un escenario) pertenece a una u otra característica de calidad. Si bien esta discusión fomenta el razonamiento en el equipo, mi sugerencia es mantener esta conversación acotada y acordar rápidamente en cuál de las características será considerada la operacionalización.
• Siempre recordar que si un modelo de calidad es un estándar, este no se obliga a ser un instrumento para la certificación: en otras palabras, que adoptemos un modelo de calidad no quiere decir que estemos obligados a certificarnos ni que exista una certificación asociada.
• Los modelos de calidad, especialmente aquellos que se encuentran estandarizados, son típicamente complementables con otros modelos de calidad.

[1] «ISO 25010:2023: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model,» ISO/IEC 25010:2023.