Uno de los desafíos que enfrentan los arquitectos de software, tanto en el diseño como en la evaluación, es cómo poder expresar de manera concreta los atributos de calidad. Lo cierto es que los atributos de calidad se mueven conceptualmente en otro nivel, por lo que teóricamente nunca será posible describirlos en forma operacional. Lo que sí podemos hacer es escribir escenarios que describan las respuestas del sistema y estos pueden ser asociados a atributos de calidad.

En mi experiencia, la escritura de escenarios en la arquitectura de software no es muy común y por ello muchas veces los arquitectos terminan estableciendo muchos supuestos que se motivan desde los requisitos funcionales que, paradójicamente, muchas veces están descritos como escenarios (por ejemplo, casos de uso e historias de usuario).

Los comentarios de los stakeholders en las reuniones de diseño, incluidas las evaluaciones de arquitectura, son siempre origen para escenarios. Estos deben describir, al menos, un estímulo al sistema y una respuesta de este. El estímulo al sistema implica reconocer algún actor (humano o no) o un factor que motiva al sistema a reaccionar de alguna manera (respuesta). En algunos casos conviene también describir el ambiente para el escenario: por ejemplo, indicar si el escenario refiere a casos de alta concurrencia de usuarios o no (en caso de que aplique).

Además, la respuesta del sistema debe ser descrita de tal manera que sea verificable. Para poder verificar la respuesta necesitamos que esta contenga una medida concreta que sea evaluable para poder llevar a cabo la verificación. A modo de ejemplo, en vez de hablar de «interfaz usable», preferimos decir «interfaz con la limitación de que todos los formularios deben tener un máximo de 5 campos para ser llenados». En este ejemplo, 5 campos por formulario es algo observable, evaluable y, por tanto, verificable (es decir, podemos decir si el escenario ha sido alcanzado o no).

Veamos un ejemplo de escenario originado por un actor (humano u otro sistema):

«La solicitud de generación de reportes completos (estímulo) debe ser atendida en no más de 24 horas desde que se ingresa la solicitud (respuesta)».

Notar que el escenario anterior inmediatamente comienza a dar luces del diseño que tendrá la arquitectura: un reporte completo que puede tomar tiempo en su generación, pero que es aceptable hasta 24 horas después de la solicitud, nos lleva a pensar en que la API del reporte puede ser diseñada de en forma asincrónica siguiendo un estilo REST.

Ahora un ejemplo de escenario originado por un factor:

«La incorporación de un componente ‘logger’ en el sistema (estímulo) permite estandarizar el mecanismo de registro de eventos (respuesta)»

El lector debe notar que, como se ha discutido en una publicación anterior de este blog, en el contexto de la evaluación de una arquitectura es posible que stakeholders relacionados con la seguridad insistan en escenarios como el siguiente, lo cual claramente pone de manifiesto un tradeoff o compromiso entre atributos de calidad:

«Los eventos del sistema (estímulo) deben ser registrados en formato y con mecanismo propios de la organización».

Finalmente, algunas palabras respecto de la «clasificación» de escenarios en atributos de calidad. El escenario anterior puede ser visto desde el punto de vista de la confidencialidad, así como también desde la integridad. En la práctica, a veces se dan discusiones acerca de a qué atributo de calidad pertenece un escenario. Esta discusión es interesante, pero no aporta más información para la arquitectura de un sistema de software ni tampoco para las evaluaciones de las mismas.