Archivo de la etiqueta: ingeniería 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.

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.