Priorización de Atributos de Calidad en Sistemas Modulares Integrados

La priorización de atributos de calidad es una práctica que contribuye a la reafirmación y consenso de las expectativas de calidad de los involucrados en la creación de un software, las cuales son fundamentales para construir y evaluar la arquitectura que lo soporta.

La tendencia actual del desarrollo de software gira en torno a varias corrientes arquitectónicas, dentro de las cuales ha tomado fuerza la construcción de sistemas modulares. Esta arquitectura favorece el mantenimiento y el futuro crecimiento de las aplicaciones. Un software modular permite desarrollar por partes un mismo sistema e integrar los módulos en la medida en que lo impongan las reglas de negocio.

En todo caso, cuando se quiere lograr que un software posea los índices de calidad exigidos por el cliente y sea de la aceptación de este, es fundamental prestarle mucha atención a la definición y priorización de atributos de calidad. Aunque la funcionalidad y otras cualidades están estrechamente relacionadas, lo que sucede en ocasiones es que en lograr la funcionalidad se centran todos los esfuerzos en el esquema de desarrollo.

Como muestra la Figura 1, la calidad integral de un sistema modular es difícil de determinar una vez que se integren módulos. Aunque un sistema posee un conjunto de requisitos no funcionales de atributos de calidad de manera general (que afectan a todo el sistema), también posee un conjunto de requisitos no funcionales a nivel de módulos, que hacen que la calidad integral del sistema varíe en la medida en que este vaya integrando sus partes.

Materiales y Métodos

Para la realización del presente trabajo se utilizaron los métodos científicos histórico-lógico, hipotético-deductivo y la observación. Se emplearon la Media aritmética y la Desviación estándar como métodos estadísticos para las bases teóricas de la propuesta. Además se contaron con materiales las metodologías y métodos asociados a la evaluación de la arquitectura del software que se describen a continuación.

Modelo ISO/IEC 9126

El estándar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software. Este estándar es una simplificación del Modelo de McCall e identifica seis características básicas de calidad que pueden estar presentes en cualquier producto de software. La Norma de calidad ISO/IEC 9126-1 tiene como puntos a favor que:

• Es una normativa respaldada por una organización reconocida internacionalmente en la temática de estandarización de calidad de productos y con un alto prestigio en ese campo.
• Ha sido acogida por Cuba como norma regulatoria en cuanto a calidad de productos de software.
• Cuenta con una amplia y detallada definición de los elementos de calidad de un producto de software y además trae descrita una métrica en correspondencia para la determinación final de niveles de calidad.

Evaluación de arquitectura de software

A la arquitectura de un software se le atribuye la responsabilidad de lograr el cumplimiento de cualidades o características de calidad, más allá de lo meramente funcional. Las decisiones arquitectónicas que se tomen estarán entonces dirigidas a la complacencia de los requisitos funcionales y no funcionales que establezca cada cliente. Evaluar la arquitectura de un software es un medio para la obtención de indicadores de calidad del producto que bien pueden servir para:

1. Determinar si el software que se está construyendo respalda los requisitos funcionales y no funcionales que le fueron atribuidos.
2. Decidir la mejor opción entre arquitecturas candidatas.
3. Decidir cuál software, de varios posibles, respalda mejor los requisitos de un cliente.

Priorización de atributos de calidad

En la construcción y evaluación de la arquitectura es muy importante conocer las prioridades a las que debe responder la línea base del software. Cada decisión arquitectónica tomada en beneficio de algún requisito o atributo de calidad puede simultáneamente incidir positiva o negativamente en cualquier otro, de ahí que establecer prioridades contribuya a la obtención de aplicaciones con calidad. Para los efectos de la presente investigación se señalan tres corrientes fundamentales:

1. La determinación cualitativa de prioridades, tal como propone el método ATAM mediante la creación de un árbol de utilidad.
   Los atributos de calidad que componen el sistema de “utilidad” son sacados, especificados hasta el nivel de los escenarios, anotados con el estímulo y la respuesta, y priorizados. En este paso se propone presentar a las partes interesadas un árbol de atributos, teniendo en cuenta su priorización), y en base a los resultados que se vayan obteniendo (inclusión o eliminación de atributos, cambio en priorización) entonces el equipo de arquitectos elabora el árbol de utilidad al nivel de escenarios.
2. La determinación cualitativa de prioridades enfocada a la arquitectura orientada a componentes, tal como propone el método MECABIC.
   Este método proporciona un árbol de utilidad inicial específico para la arquitectura de software basada en componentes a partir del cual seleccionan un conjunto de escenarios de interés, el cual está basado en el modelo de calidad ISO 9126-1 para arquitecturas de software propuesto por Losavio.
3. La determinación cuantitativa de prioridades.
   Asignaciones de valores numéricos y porcientos de cumplimiento para cálculos de índices arquitectónicos que permitan conocer el cubrimiento de la arquitectura respecto a sus atributos de calidad asociados.

Figura 1. Comportamiento de la calidad de un sistema y su descomposición en subsistemas (módulos).

Resultados y discusión

El primer paso en la búsqueda de un equilibrio de los atributos de calidad potenciados con las decisiones arquitectónicas, lo constituye la priorización de dichos atributos de manera que:

1. Posibilite la toma de decisiones arquitectónicas, para el logro del equilibrio de los factores de calidad, según su orden de prioridad.
2. Establezca un posible orden de prueba del cumplimiento de los atributos de calidad durante la evaluación, en función de prioridades.

Teniendo en cuenta estos elementos, se propone establecer un mecanismo cuantitativo para la priorización que combine los criterios de arquitectos e interesados.

Priorización de atributos por subsistemas

Para los efectos de esta investigación, la Importancia de lograr el requisito, es un concepto que va a estar sujeto a la posición de cada votante con respecto a la aplicación, la cual genera intereses diversos. Es por esta razón que, los criterios subjetivos de cada persona involucrada en la priorización, no son manejados sino el interés final de los mismos en el logro de cada requisito, en una escala sujeta a su nivel de importancia. El rango de valores admisibles para este criterio es:
5: Muy importante
4: Importante
3: Medianamente importante
2: Poco importante
1: No importante

Del desglose anterior se deduce que: a mayor valor, mayor importancia.

Una vez obtenidos los votos de cada uno de los interesados y los arquitectos, se tendría una priorización de lo que se pudiera denominar “hojas” en el contexto de un árbol de calidad tal y como lo representa la ISO/IEC 9126-1, dicho árbol estaría compuesto (en orden descendente) por: atributos, sub-atributos y RNF (Requisitos No Funcionales) de atributos de calidad con sus respectivas priorizaciones. Esto quedaría:

1. Funcionalidad
1.1. Seguridad
(5) El sistema concederá acceso a cada usuario autenticado solo a las funciones que le estén permitidas, de acuerdo a la configuración del sistema.
(5) El sistema manejará mecanismos de encriptación para las contraseñas de los usuarios. Interoperabilidad
(3) El sistema almacenará información proveniente del Sistema Mantenimiento Vehicular, al mismo tiempo que enviará información a este, todo de manera automática y transparente para el usuario final.
(4) El sistema permitirá importar información en los formatos Word y Excel.

Luego, se hace necesario conocer las prioridades, que se irán derivando de las atribuidas mediante votación, para el resto de los niveles del árbol. Para ello, en el caso del cálculo de prioridad de los sub-atributos se emplea el criterio de la media aritmética, expresado mediante la fórmula:
= (ΣXi * fi ) / fi
Siendo:
Xi: Valores de importancia.
fi: Cantidad de requisitos asociados a cada valor.

Siguiendo el ejemplo del árbol anterior, el cálculo quedaría como se muestra en la Tabla 1.

Tabla 1. Uso de la media aritmética para el cálculo de prioridad del sub-atributo Seguridad.

Tomando como Rango de Priorización los posibles valores que se encuentran en la priorización de todos los requisitos. Para el ejemplo mostrado en la Tabla 1 el cálculo de la prioridad del sub-atributo Seguridad quedaría:
= (ΣXi * fi ) / fi
= 10,00 / 2
= 5,00

Análogamente se calcula la media para el sub-atributo Interoperabilidad. Completando el árbol se tendría:
1. Funcionalidad
(5.00) Seguridad
(5) El sistema concederá acceso a cada usuario autenticado solo a las funciones que le estén permitidas, de acuerdo a la configuración del sistema.
(5) El sistema manejará mecanismos de encriptación para las contraseñas de los usuarios.
(3.50) Interoperabilidad
(3) El sistema permite importar información proveniente de sistemas externos para operar con ella, al mismo tiempo que permite exportar datos a sistemas externos.
(4) El sistema permitirá importar información en los formatos Word y Excel.

Para el cálculo de la prioridad de los atributos, como máximo nivel del árbol, se hace uso de la media aritmética, esta vez teniendo en cuenta las prioridades de todos los requisitos asociados a sus sub-atributos. Siguiendo la ejemplificación del árbol anterior, quedaría como en la Tabla 2.

Tabla 2. Uso de la media aritmética para el cálculo de prioridad del atributo Funcionalidad.

Tomando los datos de la Tabla 2, el cálculo de la prioridad del atributo Funcionalidad quedaría:= (ΣXi * fi ) / fi
= 17,00 / 4
= 4,25

Priorización a nivel de sistema

Una vez establecida la prioridad de los atributos de calidad por cada subsistema, es posible determinar la prioridad general del sistema, tomando para el cálculo de esta dos grupos de valores:

1. Los valores de prioridad calculados para cada subsistema.
2. Los valores de prioridad de atributos y sub-atributos en base a los requisitos no funcionales generales del sistema.

El segundo grupo de valores se calcula análogamente al proceso de cálculo de prioridades por subsistema, o sea, haciendo uso de la media aritmética.

Una vez calculados ambos grupos, los valores se agrupan como en la Tabla 3.

Tabla 3. Agrupación de valores para atributos.


La Tabla 3 muestra un ejemplo de la agrupación de valores para atributos, pero de esta misma manera habrá de hacerse para los sub-atributos. Para determinar la prioridad final del sistema, tanto de atributos y sub-atributos se emplea igualmente la media aritmética, teniéndose siempre en cuenta que, a mayor valor de media obtenido, mayor será la prioridad.

En aquellos casos en que los valores obtenidos coincidan para más de un indicador, se propone emplear la Desviación estándar, como criterio estadístico que permite acortar la brecha de variaciones entre los valores de prioridad para un mismo atributo a calcular. Haciendo uso de este criterio, será posible distinguir cuál de los indicadores con igual valor de media debe tener mayor prioridad, en este caso sería el de menor desviación de sus valores de origen.

La desviación estándar se utiliza cuando hay varios resultados posibles y estos están dispersos, lo cual acarrea inseguridad en el resultado final. Mientras más concentrados estén los resultados, habrá más confianza en el resultado.

Lo anterior se traduce: a menor valor calculado entre una serie de elementos con valores dispersos, mayor será la probabilidad de ocurrencia de ese elemento. Siendo la Desviación estándar igual a la raíz cuadrada positiva de la varianza, se calcula entonces el valor de la última mediante la fórmula:
S2 = Σn (Xi - Ẋ)2 / n, donde:
S2 = Varianza
Xi = Valor del atributo en cada caso.
Ẋ = Valor de la media del conjunto de valores asociados al sub-atributo/atributo.
n = cantidad total de valores analizados.

Si se toman los valores de muestra de la Tabla 3 y se calcula la Varianza para los atributos confiabilidad y usabilidad, quedaría:

Confiabilidad

S2 = ((3.3 – 3.7)2 + (3.9 – 3.7)2 + (3.9 – 3.7)2 + (3.7 – 3.7)2) / 4
S2 = (0.16 + 0.04 + 0.04 + 0) / 4 = 0.06
S = √ S2 = √ 0.06 = 0.24

Usabilidad

S2 = ((3.9 – 3.7)2 + (3.8 – 3.7)2 + (3.6 – 3.7)2 + (3.5 – 3.7)2) / 4
S2 = (0.04 + 0.01 + 0.01 + 0.04) / 4 = 0.025
S = √ S2 = √ 0.025 = 0.16

Los cálculos realizados arrojan un menor valor para el atributo Usabilidad, por lo cual la prioridad mayor en este caso deberá ser para ese indicador. La priorización entonces quedaría (recuérdese que a mayor valor, mayor prioridad):

6. Funcionalidad
5. Usabilidad
4. Confiabilidad
3. Eficiencia
2. Portabilidad
1. Mantenibilidad

Con esta propuesta, se armonizan las solicitudes y expectativas de calidad de arquitectos e interesados, con características de los grandes sistemas de software: modulares e integrados.

Sin embargo, no basta con eliminar los conflictos entre intereses y características de sistema, pues siguen quedando fuera de análisis los conflictos propios que se generan entre atributos.

Conclusiones

Los atributos de calidad son elementos claves a tener en cuenta para el desarrollo de una arquitectura sólida, por lo cual conocer sus prioridades es un elemento fundamental que permitirá discernir en el medio de los conflictos que generan las decisiones tomadas por los arquitectos para alcanzarlos. El empleo de criterios estadísticos en la priorización de atributos permite valorar todas las expectativas de calidad de los involucrados en la creación de un software, de manera que se tengan en cuenta todas las opiniones y las variaciones entre estas.

Referencias:
[1] Ambe, Mildred N. y Vizeacoumar, Frederick. Evaluation of two architectures using the Architecture Tradeoff Analysis Method (ATAM). [pdf] 29 de abril de 2002.
[2] Billy Reynoso, Carlos. (Marzo de 2004). Introducción a la Arquitectura de Software. Buenos Aires.
[3] Camacho, Erika, Cardeso, Fabio y Nuñez, Gabriel. Arquitecturas de software. Guía de estudio. abril de 2004.
[4] Collabera, V. Gnanasekaran. Evaluating Application Architecture, Quantitatively. [html] s.l. : The Architecture Journal, Marzo de 2010. Journal 24.
[5] Gómez, O. Evaluando la Arquitectura de Software. Parte 1. Panorama General. 40-41. México: Brainworx S.A. de C.V. Enero-febrero de 2007.
[6] González, Aleksander, y otros, y otros. Método de Evaluación de Arquitecturas de Software Basadas en Componentes (MECABIC). [pdf] Caracas : Laboratorio de Investigación en Sistemas de Información (LISI). Universidad Simón Bolívar, 2005.
[7] González Alvarez, Larisa y Leyet Hernández, Osmar. (2010). Modelo de evaluación de arquitectura de software del Proyecto ERP-Cuba. V Conferencia científica UCIENCIA. Febrero de 2010.
[8] Panovski, G. Product Software Quality. Master’s Thesis.Eindhoven. Febrero de 2008.