Atributos de Calidad

¿Qué son los Atributos de Calidad?

Los Arquitectos debemos participar en el entendimiento de las necesidades de los usuarios. Sí, esa es nuestra principal responsabilidad. 

En mi experiencia he debido iniciar con leer términos de referencia para aplicar a licitaciones públicas y privadas y luego acompañar al equipo de análisis en el levantamiento de requerimientos. Los usuarios finales, a excepción de algunos muy técnicos, hablarán en el lenguaje del negocio, de otros sistemas que conocen, de lo que hace la competencia, de lo que otro proveedor les contó, de lo que alguno de sus más influyentes operarios conoce o del patrón de trabajo que ejecutan a diario. Muy pocas veces nos dirán exactamente lo que quieren y por eso debemos estar presentes; debemos ayudar a traducir esos relatos prosaicos de necesidades a requerimientos técnicos. 

Los requerimientos técnicos se dividen principalmente en 2: los funcionales (functional requirements) y los no funcionales (Non-functional requirements) o atributos de calidad. Para ponerlo en términos relativamente sencillos, los requerimientos funcionales son todas las características o acciones que el sistema debe cumplir; mientras que los no funcionales corresponden a las características que incluirá para ejecutar estas acciones, con qué condiciones y cualidades que no afectan la función esperada pero sí la experiencia del usuario.

Veamos un ejemplo sencillo de transformación de una necesidad a requerimientos técnicos.

Un cliente nos comparte su necesidad durante la elicitación así: “Hemos tenido muchos problemas durante la auditoría a los proyectos que tenemos bajo control. Se nos pierden documentos importantes, varias veces desconocemos en dónde se encuentran hasta que recorremos cada uno de los directores que los han firmado. Adicionalmente, la oficina de proyectos nos impone métricas de desempeño asociadas al tiempo que tarda la ejecución de ciertas actividades”. 

Cabe aclarar que este es un posible extracto de una larga entrevista.

Los Analistas, con nuestra ayuda, podrían esbozar el siguiente listado - debatible, claro está - de requerimientos funcionales:

1. Registro de documentación 
2. Workflow de aprobación
3. Trazabilidad de cambios
4. Generación de reportes e indicadores

Durante estas sesiones participamos activamente, continuamos las entrevistas y detectamos, por ejemplo, las siguientes características explícitas y acordadas para el requerimiento de Registro de Documentación:

Registro de documentación:

• Se espera que los documentos cargados estén digitalizados en alta definición, generando un artefacto que ocupa más 300MB de de espacio en disco duro. 
• Al conversar con los técnicos de sistemas encargados de la red, se encuentra que el canal tiene una velocidad de transferencia interna de 100 Mbps y que se conectan 50 personas constantemente. La salida, hacia internet, está contratada con un proveedor que ofrece una velocidad de transferencia de 15 Mbps.
• Al comparar ciertas páginas, se encuentra que los usuarios consideran que 50 segundos es un tiempo adecuado para  cargar estos documentos. Manifiestan que no quieren quedarse esperando mientras el sistema sube el archivo sino que esta operación se haga en background mientras adelantan otras tareas.
• Se observa la operación actual y se cuentan aproximadamente 200 auditories trabajando con 30 proyectos a la vez.
• El promedio de edad se encuentra entre los 35 y 45 años. Existen algunas excepciones: 3 personas de más de 55 años. De estos usuarios el 35 % no usa un computador con regularidad.

Entre muchas otras características que podríamos detectar con la participación de los interesados, el listado nos debe servir de insumo para generar un diseño preliminar que pueda satisfacer las expectativas de los usuarios aparte de meramente cumplir sus requerimientos funcionales. 

Pasando a algo más formal, destaco la definición que otorga la IEEE a través  del estándar IEEE 1061 a los atributos de calidad: Es “Una característica del software o un término genérico que se aplica a los factores y subfactores de calidad o valores medibles”. Además complementa indicando que “La calidad del software es el grado en el que posee una combinación deseada de atributos. Esta combinación deseada debe estar claramente definida, de lo contrario, la evaluación de la calidad se deja a la intuición.”

En esta definición se resaltan los conceptos de calidad, evaluación y métrica que espero  ya vayan teniendo sentido para todos. También se introduce la noción de combinación de atributos; Veremos luego que existen requerimientos que son opuestos entre sí y que deben tratarse con cuidado, por ejemplo, la seguridad y el rendimiento pocas veces se llevan de la mano.

Para concluir la definición, Los atributos de calidad deben ser medibles. Es nuestra obligación registrarlos de esta manera y evitar plantear requerimientos subjetivos, por ejemplo: debe ser rápido, usable, agradable, altamente disponible, etc. Por medibles me refiero a números, a métricas que permitan generar indicadores. 

Registrar un requerimiento no funcional

Tomando como referencia el artículo acerca de la Importancia de los Datos, concluyo esta entrada con la siguiente información que nos debe servir de refuerzo para entender lo que debemos lograr al establecer los atributos de calidad:

"Es importante entender que se deben seleccionar con cuidado todos los atributos de calidad que se desean soportar, pues no existe software perfecto y no es posible satisfacer todos los requerimientos no funcionales sin que exista una pérdida de algún otro, el trade off o como alguna vez lo nombró Fred Brooks, no hay balas de plata."

"Como resultado de esta etapa, los atributos de calidad deben registrarse a través de métricas que permitan indicar si son o no satisfechos. Digamos que para este caso se encontró, apoyados en los datos recolectados, que los usuarios solo ingresan a la aplicación para comprar los tiquetes y se retiran luego de dar 2 o 3 clics más, lo que les toma aproximadamente de 3 a 5 segundos. Aunque a primera vista lo recolectado no dice mucho, es buen momento para convertir los datos en información. Podríamos suponer que el registro de feedback debe ser tan sencillo, tal que se pueda aprovechar el tiempo adicional que el usuario permanece en la página." (sic)

Ejemplo. Registro de métrica en Documento de Arquitectura de Software.

En el próximo artículo haré un resumen de atributos de calidad que nos sirva de catalogo al momento de enfrentarnos a nuevos requerimientos.

Referencias.

1. IEEE Standard for a Software Quality Metrics Methodology. IEEE 1061-1998.pdf - COW - Middle East Technical University.  Consultado el 29 de abril de 2015.