¿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.

Desafíos de Empleabilidad: Atracción de Talento y Elección de Lenguaje y Framework

La empleabilidad se define típicamente desde el punto de vista de quien busca activamente un trabajo. En esta columna quiero concentrarme en la empleabilidad desde el punto de vista de la persona que ofrece un puesto de trabajo: por ejemplo, una empresa que desarrolla y mantiene software.

¿Qué relación tiene el lenguaje y framework usados para el desarrollo con la empleabilidad desde el punto de vista del empleador?

A mi saber y en mi experiencia este es un asunto que pocas veces es tratado, pero que en la práctica sí se observa en muchas ocasiones: la problemática de llenar vacantes de trabajo cuando el lenguaje y framework que utiliza la organización que desarrolla y mantiene software no son atractivos.

He observado en varias ocasiones que cuando el lenguaje y framework no son atractivos, la contratación de personal técnicamente capacitado para el desarrollo y mantención de software se dificulta. Las personas tienden a considerar estos puestos de trabajo como riesgosos: desarrollar habilidades en un lenguaje y framework que pocas empresas más los han adoptado no es una estrategia segura para el desarrollo profesional de quien busca empleo, especialmente cuando el lenguaje y framework son antiguos y con poco uso en la actualidad.

Mi invitación en esta columna es a analizar adecuadamente la situación y decidir razonadamente la elección de un lenguaje y framework y así aliviar el problema de la empleabilidad en el futuro cercano (o lejano). En el caso de sistemas legado donde el lenguaje y framework ya fueron escogidos, la empleabilidad debiera ser considerada al momento de evaluar una eventual migración.

¿Por qué las decisiones de diseño de software se expresan como sintagmas nominales?

Vamos con lo primero: ¿qué es un sintagma nominal? Un sintagma nominal es una secuencia de palabras (constituyente sintáctico) en el que un nombre (sustantivo, en nuestro caso) es la interpretación central. Los sintagmas nominales son el equivalente a las noun phrases del inglés. En la práctica, y para nuestros efectos, un sintagma nominal refleja un sustantivo y no una acción.

Ahora bien, ¿qué es una decisión? Una decisión es una determinación. Es decir, no es el acto de determinar, sino que es el resultado, como producto, del acto de tomar una determinación frente a un problema de diseño de software (ver Nota 1 al pie). Cómo llegamos a estas determinaciones queda fuera del alcance de este artículo, pero en publicaciones anteriores he dedicado algunas líneas a este tema.

Dadas las definiciones anteriores, me parece que ya es claro por qué una decisión de diseño, sea arquitectónica o no, se expresa como un sintagma nominal: estas corresponden a entidades (y de primera clase, en palabras de Bosch [1]) y las entidades o clases de estas son mejor expresadas como sintagmas nominales o, en otras palabras, como una frase que sea interpretable como un sustantivo (ver Nota 2 al pie).

La expresión de decisiones de diseño como sintagmas nominales no se queda en un mero juego reflexivo: el nombre de la decisión en un ADR (architecture decision record [2]) está prescrito como un sintagma nominal, haciendo de los sintagmas nominales un «estándar» para la expresión de decisiones de diseño.

Nota 1: en el modelo de objetos es posible tener una entidad (clase o abstracción) representando la acción de tomar una decisión. Sin embargo, esto ocurre así para el software, cuyos componentes son análogos a abstracciones de un espacio que corresponde a una realidad de diseño. Fuera del software, los verbos representan acciones y los sustantivos entidades o clases de estas y por esta razón evitamos el uso de verbos para representar una decisión.

Nota 2: se prefiere un sintagma nominal a un sustantivo singular por razones prácticas: una decisión de diseño se asocia a demasiada información como para ser expresada con una sola palabra.

[1] «Software Architecture: The Next Step,» Bosch, Springer, 2004.

[2] «Documenting Architecture Decisions,» Nygard, https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions, 2011. Última revisión: octubre de 2023.

Modelar o diagramar ¿cuál es la mejor opción?

Los ingenieros trabajamos con modelos, no con diagramas. La aseveración es claramente una exageración, pero lo cierto es que cuando los sistemas de software se vuelven lo suficientemente grandes y complejos, los diagramas disminuyen su utilidad y debemos considerar el trabajo con modelos.

¿Cuál es la diferencia entre un modelo y un diagrama? Me gusta la definición dada por Delligatti [1] en la que se enfatiza que los elementos de un modelo capturan decisiones de diseño (si estas decisiones de diseño están a un nivel de la estructura del sistema, hablaremos de decisiones arquitectónicas del software o sistema). Según el diccionario Cambridge [2] un diagrama es “un plano simple dibujado para representar algo, como una máquina, usualmente para explicar cómo funciona o cómo se ensambla.”

El diagrama emerge como una representación gráfica del modelo (o sus elementos) [3][4]. El modelo incluye decisiones de diseño que definen con mayor o menor precisión al sistema en un espacio análogo a los componentes del sistema de software. La mayor o menor precisión del modelo para definir un sistema de software está dada por diversos factores tales como el nivel de abstracción deseado (según el objetivo que se tenga con el modelo, siendo modelos creados para la generación de código uno de los tipos que menos abstracción permite), el lenguaje utilizado (por ejemplo, UML permite mayor precisión que el lenguaje natural en la mayoría de los casos), entre otros. La diferencia entre diagramas y modelos se observa también en la existencia de software con especialización en el diagramado y software especializado en modelado.

Este artículo no es un llamado a abandonar los diagramas. Por el contrario, es un llamado a hacer uso operacionalmente adecuado de diagramas y modelos: cuando trabajamos con stakeholders para analizar y diseñar un sistema preferiremos el diagramado en pizarra. Luego en forma “offline” procedemos a “almacenar” las decisiones de diseño en un software de modelado. Y este almacenamiento lo haremos por medio del diagramado en el software de modelado. Por ejemplo, si queremos expresar un conjunto de conceptos relacionados que describen el dominio explicado por un stakeholder, preferiremos el diagrama de clases de UML, independiente de si estos conceptos corresponden directamente a clases del software.

La forma descrita de trabajo es frecuentemente usada ya que el software de modelado se experimenta especialmente resistido para el modelado en la práctica de la ingeniería ya que la representación de los modelos o elementos de este por medio de un software de modelado requiere poner atención a asuntos que son ajenos al modelo tales como colores de los elementos del diagrama, nombres de archivos, versionamiento, entre otros.

¿Cuáles son las ventajas de trabajar con un modelo? Una de las principales ventajas de trabajar con modelos es que podemos usar software de modelado (como Visual Paradigm o Enterprise Architect) que facilita mantener la consistencia entre los elementos de un modelo. Aquí volvemos a la discusión inicial: cuando los sistemas de software se vuelven grandes y complejos, pretender mantener manualmente la consistencia entre componentes del sistema se vuelve difícil y propenso a errores. Basta un simple cambio de nombre en alguno de los elementos para ver el beneficio de un modelo en software de modelado: el cambio se replicará en todos los modelos que usen este elemento. También podremos generar diagramas equivalentes en términos de sus pares evitando esfuerzo innecesario.

[1] “SysML Distilled: A Brief Guide to the Systems Modeling Language,” Delligatti, Addison-Wesley, 2014.

[2] “Diagram,” https://dictionary.cambridge.org/es/diccionario/ingles/diagram (rev: 02-05-2022)

[3] “Unified Modeling Language (UML),” version 2.5.1, OMG, 2017.

[4] “OMG Systems Modeling Language (SysML),” versión 1.6, OMG, 2019.

NOTA: Por software de modelado intento hacer referencia al software que incluyendo diagramado permite almacenar modelos, es decir, los diagramas se entienden como una más de las representaciones posibles para un modelo o elementos de este.

¿Qué es la Arquitectura de Software en Scrum?

Una cuestión recurrente en el contexto del uso de Scrum es ¿cuándo se crea la arquitectura del software? ¿Será en el primer Sprint? ¿En el Sprint final?

Esta cuestión parece ser más compleja de resolver aún si consideramos que Scrum es estricto en esto: al final de cada Sprint, tenemos que entregar una pieza de software funcionando, eventualmente integrada con piezas anteriores (esta es la razón por la que se prefiere el término “incremento”), de acuerdo con una Definición de Listo. ¿Cómo puede la arquitectura de software tener un espacio aquí’ ¿Qué es la arquitectura de software en Scrum? ¿Es realmente necesaria? ¿Son Scrum y la arquitectura de software realmente compatibles?

Vamos a las raíces: ¿Qué es Arquitectura de Software?

Responder esta pregunta claramente nos puede llevar a un conflicto de argumentos. No hay una única definición debido a diferentes puntos de vista, así como también a la evolución del concepto. Algunos arquitectos ven la arquitectura como un producto de trabajo lejos de la implementación, preocupada solo de las “grandes cosas en grandes sistemas.” A estos arquitectos normalmente los escucharemos decir cosas como “en este sistema no hay arquitectura.” Otros, no obstante, ven la arquitectura como algo que se posiciona más cerca de la implementación.

¿Qué tienen en común estas visiones? Decisiones. Por supuesto, a diferentes niveles, pero tienen en común «decisiones de diseño». Jan Bosch [1] argumenta que la arquitectura de software es la composición de un conjunto de decisiones llamadas “arquitecturales”. Taylor et al. [2] comentan que la arquitectura de software es el conjunto de las principales decisiones de diseño realizadas acerca de un sistema. Es decir, podemos tomar muchas decisiones, pero no todas ellas son arquitecturales. Bosch también agrega que las decisiones arquitecturales tienen las siguientes características:

Tienen influencia en la estructura del sistema. Por ejemplo, usar una base de datos SQL implica agregar un componente de administración de datos.
Pueden definir una o más reglas de diseño. Por ejemplo, cuando se decide usar MVC, hay algunas reglas concretas que especifican una forma particular de responder a los eventos originados por el usuario a través de una interfaz gráfica.
Pueden imponer restricciones de diseño. Por ejemplo, cuando se decide usar un modelo de datos relacional, emergen una serie de restricciones acerca de cómo las clases se van a organizar y los componentes que pueden ser seleccionados.
Tienen asociado un “rationale”, es decir, una razón fundamental. Las decisiones, por tanto, se asumen como realizadas después de algún razonamiento. Por ejemplo, cuando se decide usar una base de datos para grafo porque será más fácil administrar las relaciones entre los clientes de un sistema.

A modo de ejemplo, usar un patrón particular para describir métodos en nuestro código Java es claramente una decisión de diseño, pero no es arquitectural. Por otro lado, la selección de un grupo de patrones de diseño para estructurar el sistema en capas sí es una decisión arquitectural. Seleccionar un motor NoSQL particular por sobre un motor SQL también es una decisión arquitectural.

Arquitectura de Software en Scrum

La idea clave aquí es que cuando hablamos de arquitectura de software, estamos hablando de tomar decisiones. Scrum indica que debemos tener incrementos de software funcionando al final de cada Sprint. Se llaman incrementos y no módulos o partes porque se asumen que pueden estar integrados con las entregas anteriores. Además, los incrementos de producen de acuerdo con una “Definición de Listo.”
Las decisiones de diseño que se van tomando durante el Sprint van constituyendo lo que llamaremos arquitectura de software. De esta forma, entenderemos que la arquitectura emerge y se encuentra inmersa en la pieza de software funcionando o incremento. Esto nos lleva al principal argumento de este artículo: no hay un momento especial para el diseño de la arquitectura de software en Scrum. No hay un “Sprint de arquitectura de software”. En Scrum, la arquitectura de software emerge, no es creada en alguna instancia o momento específico.

Hasta ahora, el lector podría haber notado que estoy considerando a las decisiones de diseño como si fueran historias de usuario. ¿Es así? Sí. Si bien las decisiones de diseño claramente no son historias de usuario, tienen una propiedad común: las consideramos entidades de primera clase. Esto significa que las podemos gestionar y manipular como si fueran cualquier otro objeto. En este contexto, una decisión de diseño puede ser caracterizada por muchos atributos. Los atributos más comunes son: un identificador, el nombre de la decisión, la descripción de una decisión, el identificador de las decisiones que implicaron o afectaron esta decisión, el identificador de las decisiones que se ven afectadas por esta decisión, un timestamp, las personas involucradas en la decisión, y un “rationale” para la decisión. Las decisiones de diseño pueden ser trabajadas en un Sprint como cualquier otro elemento del Sprint Backlog.

Dependiendo del tipo de decisión, esta podría estar presente como un elemento separado en el Backlog o bien ser una “nota” que especifique algún detalle en un elemento del Backlog. Esto es algo que finalmente el equipo de desarrollo va a decidir.

Lo importante es que, al final del Sprint, cuando el equipo de desarrollo ha terminado suficientes ítems del Sprint Backlog para alcanzar el Objetivo del Sprint, tendremos, de acuerdo con la Definición de Listo, un incremento que comprende varias decisiones de diseño arquitecturales. La Definición de Listo es muy importante para la toma de decisiones de diseño dado que está más relacionada con atributos de calidad que con requisitos funcionales. Es perfectamente válido tener una Definición de Listo como “el software debe mantener una estructura modular que facilite la integración continua.” El lector notará que una Definición de Listo como esta va a restringir el conjunto potencial de decisiones de diseño arquitecturales que se puedan tomar, lo cual es consistente con la restricción que emerge desde los atributos de calidad.
Para resumir, la arquitectura de software en Scrum es el conjunto de decisiones de diseño arquitecturales que están comprendidas en el “incremento”, ya sea que estas se encuentren documentadas o no. Por supuesto, soy un defensor de la idea de que se deben documentar. Pero me interesa que el lector note que la documentación es una representación y que esta aparece a consecuencia de las decisiones tomadas.

El “gran diagrama” en Scrum

Muchos arquitectos disfrutan elaborar diagramas con componentes, conectores y muchas otras cosas que impresionan, tanto en pizarras como directamente en algún software para UML o Archi. No hay problema con esto, incluso si se realiza en las primeras horas del primer Sprint. Usualmente, estos artefactos son también muy valiosos para que el equipo de desarrollo pueda reflexionar y discutir acerca de los ítems prioritarios en el Product Backlog.

Lo importante es recordar que un diagrama será siempre un diagrama y no son una arquitectura, al menos no en Scrum.

Documentar la Arquitectura de Software en Scrum

Este es otro asunto controversial en Scrum. Primero, Scrum no es una metodología. Es un framework. Por tanto, no manda ni más ni menos documentación. La idea clave aquí es entender que, dependiendo de lo que el Product Owner haya considerado como valorable, también podemos terminar con documentación para la arquitectura de software. EL equipo de desarrollo podrá también explicar al Product Owner la importancia, es decir, el por qué y el cómo, de la documentación de la arquitectura.

[1] «Software Architecture: The Next Step», Bosch, Springer, 2004.

[2] «Software Architecture: Foundations, Theory, and Practice», Taylor et al. Wiley, 2010.

NOTA: Este escrito es una actualización de un artículo que escribí hace algunos años para DZone (versión original en inglés: «What Is Software Architecture in Scrum?»).

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.