Archivo de la categoría: Ingeniería de software (general)

¿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?»).