Archivo de la categoría: Evaluación de arquitecturas de software

¿Por qué usar un modelo de calidad?

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.

El dominio de una evaluación de arquitectura de software

Entender el dominio de una evaluación de arquitectura es un asunto que, en mi experiencia, ha mostrado ser vital para poder convencer a quienes puedan verse interesados en este tipo de iniciativas. Para esta reflexión acerca del dominio he preparado un modelo de dominio que presento con un diagrama de clases UML. He utilizado la convención tradicional de describir las relaciones entre las entidades de tal manera que se lean en voz activa de izquierda a derecha y de arriba hacia abajo.

El modelo que propongo está lejos de ser una revisión exhaustiva del dominio de las evaluaciones de arquitectura de software. Mi objetivo ha sido capturar los elementos esenciales a la vez que este sea simple y útil para la discusión. En la búsqueda de la simplicidad, también he anotado la multiplicidad en los extremos de las entidades solo en aquellos casos me han parecido más importantes de destacar.

Los stakeholders (no confundir con usuarios de un sistema de software) muestran interés en el proyecto y producto. También tienen potencial poder de influir las decisiones que se tomen respecto de estos. El interés e influencia lo materializan por medio de preocupaciones. «En caso alguno podemos permitirnos que se filtren datos privados de los usuarios» es un ejemplo de una preocupación que puede venir de un abogado o una ingeniera en seguridad.

Las preocupaciones son reflejadas en escenarios, es decir, son los stakeholders quienes crean estos escenarios que luego serán registrados de alguna manera. A su vez, los escenarios dan soporte a los objetivos del negocio, o de la misión. Así, por ejemplo, el escenario «el tiempo de generación de las liquidaciones de sueldo para 2000 trabajadores debe ser menor a 10 minutos» soportará un objetivo como «aumentar participación en el mercado de nuestro sistema de remuneraciones».

Los escenarios también son operacionalizaciones para los atributos de calidad. Los atributos de calidad corresponden a conceptualizaciones, es decir, definiciones para conceptos que se han establecidos como factores de calidad en productos de software. La operacionalización es de vital importancia en las evaluaciones de arquitectura de software y también en la ingeniería de software porque son estas las que nos permiten verificar si se ha alcanzado el nivel esperado del atributo de calidad. El nivel esperado del atributo de calidad puede estar expresado en el escenario, como también por medio de un requisito de atributo de calidad. Podríamos argumentar con facilidad que los escenarios son una más de las posibles formas de expresar estos niveles esperados por lo que en la práctica podemos prescindir de la especificación formal como requisito si es que se nos permite.

Los atributos de calidad son impactados por las decisiones arquitecturales. Esta es una buena heurística para sospechar cuándo una decisión es arquitectural y cuándo no. Por ejemplo, usar colecciones en Java en reemplazo de arreglos será, probablemente en una gran mayoría de casos, una decisión de diseño que no tendrá mayor impacto en los atributos de calidad y puede, por tanto, ser considerada como decisión no arquitectural. Lo que es importante de reconocer de estos impactos es que no siempre son negativos y no siempre son positivos: de hecho, una decisión arquitectural podría afectar negativamente a un atributo (por ejemplo, usabilidad) a la vez que beneficia a otro (por ejemplo, confidencialidad). Así también, las decisiones arquitecturales las tomaremos con el objetivo de tratar de alcanzar requisitos de atributos de calidad. Definiciones y descripciones de atributos de calidad pueden ser encontrados en bibliotecas de atributos de calidad (sugiero revisar [1] y [2]).

Para evaluar una arquitectura necesitamos, ya sea con mayor o menor nivel de acabado, una representación de la arquitectura. Esta representación no solo va a describir la arquitectura sino también expresará de alguna manera las decisiones arquitecturales que componen a esta arquitectura y que impactan los atributos de calidad. Usemos UML, algún ADL o diagramas ad-hoc, lo importante para una evaluación es reconocer que la representación va a describir tanto la arquitectura como las decisiones ya que estas últimas son las que componen el producto de trabajo que llamaremos arquitectura de software.

He dejado para el final de esta columna la que es probablemente la relación más importante en este dominio: la arquitectura de software determina los atributos de calidad. Este consenso tanto de la academia como de la industria es el que sustenta la necesidad de las evaluaciones de arquitectura: evaluamos una arquitectura porque sabemos que una arquitectura no apropiada tendrá un efecto adverso no despreciable en los atributos de calidad.

Al llegar a este punto, comprender el beneficio de una evaluación de arquitectura debiera ser transparente y directo. Usaremos estas instancias para determinar qué tan probable es que nuestro sistema de software alcance los niveles de calidad esperados así como también usaremos el resultado de las evaluaciones para definir líneas de acción concretas que nos permitan corregir, tempranamente, asuntos que pueda dificultar o inhibir alcanzar los requisitos de nuestro sistema.

[1] «Software Architecture in Practice», Bass et al. Addison-Wesley, 3a edición, 2012.

[2] “Evaluating Software Architectures: Methods and Case Studies”, Clements et al. Addison-Wesley, 2002.

Sugerencias para escenarios en la arquitectura de software

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.

Evaluaciones de arquitectura: cuándo ejecutarlas

Las evaluaciones de arquitectura de software son instancias formales en las que, haciendo uso de algún método, se analiza si la arquitectura es adecuada para el propósito por el cual se concibe un sistema de software. No corresponde aquí discutir acerca de lo que es concretamente el propósito de un sistema de software, pero sepa el lector que este puede ser eventualmente caracterizado a nivel de escenarios o requisitos de atributos de calidad. Que las evaluaciones sean instancias formales no quiere decir que las arquitectura de software se pueden evaluar solo en iniciativas, sino más bien que al reconocer la instancia como tal dentro de un proceso y hacer uso de un método específico estamos apuntando a la sistematización de las evaluaciones.

Una pregunta que me han hecho en reiteradas ocasiones es: cuándo ejecutar una evaluación de arquitectura. La respuesta no es fácil y si agregamos el hecho de que algunos métodos como ATAM [1] presuponen contar con al menos una idea concreta de arquitectura y otros como ARID [2] se enorgullecen al decir que no requieren de una arquitectura completa, la discusión se torna un tanto más nebulosa.

Evaluar una arquitectura de software requiere reconocer todo el ciclo de diseño de estas. Analizar, por ejemplo, la decisión de tercerizar el sistema de pago en un producto requiere de caracterizar, y muchas veces levantar, los escenarios o requisitos, especialmente aquellos relacionados con atributos de calidad para determinar si las decisiones tomadas son adecuadas o no. Algunos métodos como ATAM [1] ponen énfasis en determinar también cómo estas decisiones se deben balancear con otras decisiones (tradeoffs o compromisos). Podemos decir que cada método hará énfasis en lo que promete atender con prioridad, como es el caso de DCAR [3] que se enfocará en decisiones concretas que deben ser desafiadas en el análisis.

Lo anterior pone de manifiesto que una evaluación de arquitectura puede comenzar tan tempranamente como el visionado mismo del producto de software en cuestión. El modelado de contexto que normalmente se realiza en etapas muy tempranas del desarrollo es una entrada importante para el diseño de una arquitectura de software. Los escenarios, especialmente aquellos que se levantan para propiedades cualitativas del sistema, son muy importantes a la hora de ejecutar una evaluación de arquitectura. Con mayor razón se justifica la inclusión de evaluaciones de arquitectura en etapas tempranas en el contexto del desarrollo ágil: no es de extrañar que ya en el primer Sprint Planning del primer Sprint en Scrum los ingenieros y desarrolladores comiencen a visualizar y diagramar una arquitectura de software (las evaluaciones normalmente se extienden por varios días por lo que es de esperar que en un primer Sprint la evaluación esté presente en una parte considerable de la extensión de este). Las evaluaciones también se pueden ejecutar en forma continua, es decir, a lo largo del desarrollo de un producto de software.

No solo desde un punto de vista temporal es posible discutir la inclusión de evaluaciones de arquitectura. También se puede discutir en términos del tipo de proyecto o iniciativa de desarrollo. Evaluaciones de arquitectura son bienvenidas en el desarrollo de productos [2], migraciones [4], adquisiciones [5] y mantenciones de software [2]. En el caso de las adquisiciones, las evaluaciones de arquitectura pueden incluso comenzar antes de la licitación, donde los resultados de la evaluación serán esenciales para explicitar concretamente los aspectos esperados de la propuesta de software que hagan los oferentes interesados en la licitación.

Finalmente, los resultados de las evaluaciones de arquitecturas de software no terminan en «sí» o «no». Por lo mismo, no corresponde asignar la responsabilidad de tomar decisiones a nivel de proyecto a las evaluaciones. Las evaluaciones terminarán con resultados que serán un input valiosísimo para la toma de decisiones a nivel de proyecto (por ejemplo, ¿continuamos con la migración?) y a nivel estratégico (por ejemplo, ¿estamos en condiciones de ofrecer un software mejor que la competencia?), pero la responsabilidad de tomar esas decisiones será siempre de los las personas que estén asumiendo esos roles.

[1] «ATAM: Method for Architecture Evaluation», Kazman et al. SEI, 2000.

[2] «Evaluating Software Architectures: Methods and Case Studies», Clements et al. Addison-Wesley, 2002.

[3] «Decision-Centric Architecture Reviews», van Heesch et al. IEEE Software, 2013.

[4] «Assessing Migration of a 20-Year-Old System to a Micro-Service Platform Using ATAM», Cruz et al. ICSA-C, 2019.

[5] «The Need for Software Architecture Evaluation in the Acquisition of Software-Intensive Systems», Zhu et al. Australian Government – Department of Decence, 2014.

De compromisos (tradeoffs) y sus resoluciones en la arquitectura de software

Tradeoffs o compromisos (traducción comúnmente aceptada) son aquellas situaciones en las que balanceamos, considerando beneficio y pérdida, atributos de calidad de un sistema software-intensivo. Wikipedia agrega la idea de «sacrificio» [1]. Sacrificio es el resultado de haber tratado el tradeoff entre dos o más propiedades cualitativas. Primero reconocemos la existencia de una situación en la que existe un compromiso entre una u otra alternativa y luego decidimos en beneficio de una de las alternativas sacrificando el beneficio de la otra (u otras).

Los tradeoffs o compromisos están siempre presentes en todo diseño de sistema software-intensivo. En mi opinión, difícilmente podríamos hablar de ingeniería de software si no existieran pues es aquí donde ponemos en marcha gran parte de las herramientas, técnicas y métodos de la ingeniería para decidir finalmente cuál será la estructura (arquitectura) del sistema de software en cuestión y que implica el haber tomado una determinación acerca de los compromisos existentes entre los varios atributos de calidad asociados.

Sin embargo, rara vez estas características cualitativas, y con mayor razón los compromisos entre estas, son evidentes en el desarrollo. En la práctica, la experiencia termina tomando un rol protagónico haciendo del diseño un asunto de satisfacción de problemas [2]. ¡De ahí la importancia de contar con miradas frescas y no solo experimentadas en el diseño de un sistema!

Un caso que he observado en varias ocasiones se da en el compromiso entre las propiedades «confidencialidad» y «disponibilidad». En concreto, para asegurar la confiabilidad parece del todo claro que la superficie de ataque debe ser reducida. Por otro lado, y para su aseguramiento, la disponibilidad va a requerir de una serie de registros, en su mayoría «logs» automáticos, que ineludiblemente van a terminar agrandando la potencial superficie de ataque. Un ejemplo concreto muy básico: los ingenieros de seguridad no quieren que un potencial atacante pueda determinar si el rechazo al ingreso en un sistema se debe a que el nombre de usuario o la contraseña estaban incorrectos; los ingenieros encargados de la disponibilidad quieren mantener un archivo de registro en el que se especifique si fue el nombre de usuario o la contraseña (o ambos) los que estaban incorrectos para determinar con precisión, y en el menor tiempo posible, el problema que eventualmente pueda ser reportado por un usuario. La siguiente figura muestra una simplificación de un análisis de tradeoffs haciendo uso de signo + y signo – para indicar si la operacionalización (logs exhaustivos) tiene incidencia positiva o negativa, respectivamente, sobre los atributos de calidad.

Simplificación de un árbol de «softgoals» para representar tradeoffs.

No todos los casos son sencillos de resolver como el mencionado. En el ejemplo, muy probablemente los ingenieros determinarán que el «costo» o sacrificio que implica perder datos para asegurar la disponibilidad puede ser pagado a cambio de mayor confidencialidad (¡aunque esto siempre depende de los objetivos del negocio!). Me ha tocado ver también casos en los que el debate es fervoroso, situaciones en las que la «confidencialidad» se enfrenta a asuntos mandados por normas institucionales o legales y que exigen de parte de la «disponibilidad» un acabado registro de los eventos y operaciones del sistema.

Las evaluaciones de arquitectura son instancias formales en las que se hacen evidentes estas propiedades cualitativas, sus compromisos y se discute la resolución de estos últimos. En las evaluaciones también se discuten objetivos e impulsores del negocio y escenarios de uso actuales y futuros, lo que permite aportar en la toma de decisiones de diseño para atender y manejar el compromiso.

[1] «Trade-off», https://es.wikipedia.org/wiki/Trade-off. Última revisión: enero de 2021.

[2] «Software Designers Satisfice», Antony Tang y Hans van Vliet, ECSA 2015.