Atributos de Calidad, Tácticas y Evaluación del Software - Introducción

Retomando mi blog y luego de un par de años bastante ajetreado, intentaré continuar con una serie de artículos que resumirán - a mi parecer - las principal preocupaciones de un Arquitecto de Software: Qué son los atributos de calidad, cómo diseñar un sistema soportando estos requerimientos no funcionales a través de cientos de tácticas y, finalmente, cómo evaluar que realmente el resultado del diseño y la construcción satisface estas necesidades. Intentaré organizarlo de tal forma que sirva de guía para consulta para cualquier momento.

Cuando inicié mi carrera como Ingeniero de Sistemas ignoraba la existencia de la Arquitectura de Software. Aún hoy me es difícil ubicar un mapa de ruta que nos indique cuáles pasos deberíamos seguir para ser buenos Arquitectos. Parte de este problema es el desconocimiento de qué artefactos producimos en nuestro trabajo; Sabemos que debemos diligenciar un Documento de Arquitectura de Software, realizar algunos diagramas y seleccionar uno que otro framework de desarrollo. ¿Es realmente eso todo lo que debemos hacer? ¿Es lo que espera el equipo de desarrollo y los usuarios finales?

No sé si han lidiado alguna vez con no tener la certeza de que un diseño propuesto cumplirá exactamente el rendimiento requerido, se ajustará a los acuerdos de nivel de servicio necesario (Disponibilidad, por ejemplo), tendrá la usabilidad (Que para mí solía ser el atributo más difícil de medir) correcta, y ese largo etcetera que durante el día a día nos preocupa y hace que, a opinión de terceros, algunos de nosotros no sean más que Arquitectos Power Point.

Me gustaría resaltar una frase que encontré mientras estudiaba para la OCM JEE 6. "El diseñador se preocupa por lo que sucede cuando un usuario presiona un botón y el Arquitecto se preocupa en lo que sucede cuando 10 mil usuarios presionan un botón" ([1] Pág. 22).

Así, el primer mensaje que quiero dejar con este artículo es que siempre debemos verificar y validar que el diseño propuesto no es únicamente un conjunto de patrones que resuelven un requerimiento funcional. No es un diseño para un componente o sistema que simplemente ejecuta una función que expone un servicio a través de un protocolo sofisticado, por ejemplo. Es, entre muchas cosas, una propuesta de Arquitectura, de diseño de alto nivel, que muestra los elementos y las relaciones arquitecturales, producto de decisiones y racionalización, para soportar los atributos de calidad seleccionados.

De esto se pueden desprender muchas charlas ¿Cuántos y cuáles atributos de calidad debería soportar el sistema?

Tal vez conocen la norma ISO/IEC 9126. Esta es, a mi parecer, un arma de doble filo. Como Arquitecto no puedo asegurar que todo sistema web es capaz de soportar tantas cualidades y lastimosamente así lo mal interpretan los usuarios.

Pero bueno, entrando en materia, dividí esta serie de artículos en 4 partes, que pueden variar a medida que vaya alimentando el contenido:

1. ¿Qué son los atributos de Calidad?
2. Catálogo de Atributos de Calidad.
3. Tácticas de Arquitectura y su relación con los requerimientos funcionales que soporta.
4. Métodos de evaluación de  la Arquitectura, en tiempo de diseño y en construcción.

Este es realmente el tema más importante y atractivo. Repasaremos cientos de tácticas, patrones de diseño a nivel de arquitectura, aplicaremos simulaciones y cálculos de dependencia y revisaremos herramientas útiles para generar indicadores que permitan validar objetivamente la correctitud del sistema. Debido a que la tecnología avanza, estos elementos no son ajenos a la evolución, trataré de adaptar el contenido a las estrategias que vaya aprendiendo.

Referencias

1. Sun Certified Enterprise Architect for Java EE Study Guide. Mark Cade and Humphrey Sheil. Second Edition. 2010.