Atributos de Calidad del Software

La arquitectura de software es un pilar fundamental para el desarrollo de sistemas robustos y eficientes. Más allá de la funcionalidad visible, un arquitecto debe dominar los requisitos no funcionales que determinan la calidad del software a largo plazo. Comprender la diferencia entre lo que el sistema debe hacer y cómo debe hacerlo es esencial para crear soluciones que no solo funcionen, sino que perduren y evolucionen con el tiempo.

¿Cómo determinar la calidad de un sistema de software?

La calidad de un sistema no se mide únicamente por lo que hace, sino también por cómo lo hace. Como arquitecto de software, es fundamental que domines dos tipos de requisitos: los funcionales y los no funcionales. Aunque los primeros establecen el marco de lo que debe resolver el sistema, son los requisitos no funcionales los que realmente definen la arquitectura de calidad.

Estos atributos de calidad son los que permiten que un sistema:

• Sobreviva en el tiempo
• Mantenga su integridad
• Evolucione y mejore continuamente

El dominio de estos requisitos te permitirá identificar posibles riesgos que puedan afectar al sistema y las restricciones que puedan limitar tu dominio de solución.

¿Qué comprenden los requisitos funcionales?

Los requisitos funcionales definen lo que el sistema debe hacer para resolver las necesidades específicas de los usuarios. Para establecerlos correctamente, necesitas responder preguntas como:

• ¿Quién tiene la necesidad?
• ¿Qué problema específico debemos resolver?
• ¿Qué se espera como resultado de la solución?
• ¿Cómo verificamos que la solución cumple con los criterios de aceptación?
• ¿Cuáles son los límites generales de la solución?
• ¿Qué fallas potenciales debe manejar el sistema?

Estos requisitos se pueden categorizar en:

1. Capacidades visibles para el usuario: funcionalidades con las que el usuario interactúa directamente.
2. Procesos en background: operaciones que se ejecutan sin intervención directa del usuario pero que entregan resultados visibles.
3. Control de acceso y compliance: requisitos relacionados con la seguridad y el cumplimiento normativo.
4. Manejo de excepciones: mecanismos para gestionar situaciones anómalas conocidas en el negocio.

Un enfoque interesante para definir requisitos es el "método Amazon" de trabajar desde atrás. En lugar de empezar enumerando requisitos, se proponen soluciones iniciales para que los usuarios proporcionen feedback. Este feedback se convierte luego en la especificación del producto, basándose en necesidades reales y no en presunciones iniciales.

¿Por qué los requisitos no funcionales son el centro de atención del arquitecto?

Los requisitos no funcionales determinan la calidad del software y se pueden entender de tres maneras:

1. Cualidades o atributos del software: son aquellas características que terminan en "idad" - usabilidad, mantenibilidad, extensibilidad, seguridad, etc. Como arquitecto, debes dominar estos requisitos y entender el espectro en el que puedes moverte, sus restricciones y el margen de negociación que ofrecen.

2. Consideraciones de costo: el costo es un criterio fundamental para la toma de decisiones arquitectónicas. Este aspecto debe ser analizado cuidadosamente en cada elección que realices.

3. Impacto de las decisiones: cada decisión arquitectónica conlleva consecuencias. No hay "balas de plata" ni "almuerzos gratis". Es crucial entender que cada elección implica compromisos y equilibrios que se manifestarán a lo largo del tiempo.

El impacto puede medirse mediante funciones de pérdida, que permiten cuantificar el costo incurrido cuando ocurren errores en el sistema. Estos costos no son únicamente económicos, también pueden ser reputacionales o regulatorios.

¿Cómo gestionar los riesgos en la arquitectura de software?

Cuando tienes claridad sobre tus requisitos funcionales y no funcionales, así como sobre el impacto potencial de los errores, puedes desarrollar una tabla de riesgos utilizando frameworks especializados. Estos frameworks te permiten:

1. Clasificar los riesgos según su criticidad y probabilidad de ocurrencia
2. Priorizar los riesgos para determinar cuáles deben abordarse durante el diseño y cuáles pueden gestionarse posteriormente
3. Desarrollar planes de mitigación para aquellos riesgos que no pueden resolverse directamente
4. Establecer controles para riesgos que solo pueden manejarse cuando se materializan

Este proceso requiere colaboración con otras áreas para delimitar hasta dónde puede y debe actuar el sistema frente a un riesgo materializado.

¿Qué papel juegan las restricciones en el diseño de soluciones?

Las restricciones son límites impuestos al diseño de tu solución. Es importante entender que:

• No todas las restricciones se conocen desde el principio
• Algunas restricciones surgen de tus propias decisiones arquitectónicas

Por ejemplo, si eliges un sistema de bases de datos relacional, estás limitando tu solución a esquemas que deben planificarse con anticipación. Si optas por bases de datos no relacionales u orientadas a documentos, ganas flexibilidad en el esquema pero pierdes capacidad analítica directa mediante lenguajes como SQL.

Estas decisiones generan un equilibrio dinámico de restricciones que debes manejar como arquitecto de software.

La arquitectura de software va más allá de la funcionalidad básica, centrándose en atributos que determinan la calidad y longevidad de los sistemas. Identificar, priorizar y gestionar los requisitos no funcionales, los riesgos y las restricciones te permitirá diseñar soluciones que no solo funcionen hoy, sino que también sean sostenibles y adaptables en el futuro. ¿Has identificado los riesgos críticos en tu proyecto actual? Comparte tus experiencias y estrategias en los comentarios.