El Objetivo del presente documento es explicar que es el Modelo de Calidad de Productos de Software QSAT.

Resumen ejecutivo

Esquema del modelo

Contexto

    Características Básicas

    Sub – características

    … (Pueden haber de 0 a varios niveles de Subcaracterísticas)

    Atributos En Uso: métricas en Uso

    Atributos Externos: métricas Externas

    Atributos Internos: métricas Internas

Los principios que guiaron su creación

1. 1. 1. Para asegurar la objetividad del modelo, NO se basará en ningún documento producido en el proceso de desarrollo.
         • El documento de “Requerimientos No Funcionales” del sistema. Se podrá tomar en cuenta para evaluar los distintos pesos que tengan las distintas características fundamentales y las sub-características.
         • El documento de “Requerimientos Funcionales” del sistema podrá ser usado como herramienta en la evaluación de la característica “Satisfacción de los stakeholders/Considerado apropiado”
      2.  Cuando no hay posibilidad de (o no tiene lugar la) evaluación objetiva, nos conformamos con evaluaciones subjetivas bajo las características fundamentales de “Confortabilidad del usuario” y “Satisfacción de los stakeholders que no son usuarios”
      3. El concepto de “Stakeholder” incluye normas, estándares y como cualquier otro documento que imponga restricciones y requerimientos al sistema.

Para asegurar que la elegida sea una Característica Fundamental del producto, se deben cumplir dos condiciones:

• 1. No se podrá derivar de otra característica.

  2. Se podrá explicar usando uno de los siguientes esquemas (lo definido entre corchetes [] es opcional):

     1. 1. Cumplir con los requisitos de <Característica Fundamental> significa que el sistema <provee X> (o <tiene X>) [en el contexto de <C>] [de modo que <M>]. Evaluable en términos de <T>

O,

• • 1. Evaluar la/el <Característica Fundamental> de un sistema es evaluar en que medida [en el contexto de <C>], el sistema <hace X> (o <tiene X>) [de modo que <M>]. Evaluable en términos de <T>

Ejemplo 1: Adaptabilidad

Cumplir con los requisitos de Adaptabilidad significa que en el contexto de su uso en diferentes entornos y por diferentes actores, el sistema se instala y funciona de modo que no son necesarios recursos adicionales a los pre-establecidos. Evaluable en términos de los recursos necesarios para la instalación y adaptación a diferentes entornos y diferentes actores.

Ejemplo 2: Calidad de los artefactos

Evaluar la Calidad de los artefactos es evaluar en que medida tienen sus artefactos grados de calidad que están por sobre grados predeterminados.

Evaluable en términos de de los grados de calidad obtenidos por los artefactos.

A un nivel debajo de las Características Fundamentales, hay cero o más niveles. Empezando por el nivel más alto (0) que es el nivel de las Características Fundamentales y siguiendo por niveles 1,2, etc. de las Subcaracterísticas que de ellas se derivan. Es decir que para evaluar una Característica Fundamental tenemos que evaluar sus Subcaracterísticas a nivel 1. Cada Subcaracterística a su vez deberá ser evaluada evaluando las Subcaracterísticas debajo de ella (obsérvese que los niveles más “bajos” llevan numeración más alta) hasta llegar a los Atributos. Siendo los Atributos propiedades medibles, que se evalúan midiendo sus Métricas.

El modelo solo distingue las categorías “Interno”, “externo” y “en uso” a nivel de los atributos. Es decir que una característica puede ser evaluada por atributos de una o más de estas categorías.

Se podría decir que una característica que es totalmente evaluada por atributos de tipo “en uso” es en si misma de tipo “en uso”, pero nosotros vislumbramos las posibilidad que en la evaluación de una característica se puedan usar atributos de dos o de las tres categorías.

Como posiblemente haya varios atributos con los que se puedan evaluar la misma característica/Subcaracterística, no siempre será necesario evaluarlas todas, pudiendo elegirse la métricas más “a mano” para hacerlo.

La elección de una de Subcaracterística para una Característica Fundamental (o de una Subcaracterística para otra a nivel más alto) se justifica si (asumiendo nivel 0 para la Característica Fundamental):

• 1. Si se puede construir la frase compuesta por “<Característica nivel_n> <Característica nivel_n+1>”,

O,

• 1. Si se puede decir que la “<Característica nivel_n+1> hace a la <Característica nivel_n> (sin la primera no se puede dar la segunda)

Ejemplo 3: en el Aprendizaje

Ya que se puede construir la frase compuesta: “Conformidad del usuario en el Aprendizaje”, “en el Aprendizaje” es una Subcaracterística válida de “Conformidad del usuario”.

Ejemplo 4: Coherencia de la IU

Ya que se puede decir que la “Coherencia de la IU” hace a la “Conformidad del usuario en el Aprendizaje”, “Coherencia de la IU” es una Subcaracterística válida de “Conformidad del usuario en el Aprendizaje”.

La elección de un Atributo para una Subcaracterística se justifica si se puede evaluar la Subcaracterística midiendo el Atributo.

Ejemplo 5: “Porcentaje de los posibles casos de prueba que fueron automatizados”

Es un “atributo externo” para evaluar la subcaracterísticas “Testabilidad/ Madurez en la cobertura/Automática” ya que midiendo este atributo externo podemos evaluar la subcaracterísticas.

La elección de las Métricas para medir un Atributo se justifica si no cabe ninguna duda que efectivamente las métricas miden el valor del atributo.

Ejemplo 6: “Ritmo de reducción de los errores en uso”

Es una métrica usable para medir el atributo en uso: “Numero de errores no detectados en uso” (atributo necesario para evaluar la Subcaracterística “Validez informática de los datos”) ya que midiendo la métrica se mide (indirectamente) el atributo.

• Presentar a N desarrolladores y otros stakeholders dos conjuntos de cuestionarios a llenar y preguntar por:
• Claridad de los conceptos usados
• Facilidad (fluidez) de completar
• Refleja mejor su punto de vista en la valoración de un sistema

En el nivel más alto de la evaluación de un sistema están las Características Fundamentales y para evaluar un sistema tenemos que evaluar sus Características Fundamentales, que en orden alfabético son:

• Adaptabilidad
• Calidad de los artefactos
• Coexistencia con otros sistemas
• Confortabilidad del usuario
• Cobertura de contexto
• Constancia
• Cumplimiento de los requerimientos
• Cumplimiento legal
• Efectividad
• Eficiencia
• Estandarizado
• Manejo de fallas
• Mantenimiento
• Recuperabilidad de fallas
• Reemplazable
• Satisfacción de los stakeholders
• Seguridad de no causar daños
• Seguridad Informática
• Testabilidad
• Tiempo Real
• Tolerancia a fallas
• Validez Informática

A continuación se da una breve descripción de cada característica:

Adaptabilidad

Cumplir con los requisitos de Adaptabilidad significa que en el contexto de su uso en diferentes entornos y por diferentes actores, el sistema se instala y funciona de modo que no son necesarios recursos adicionales a los pre-establecidos.

Evaluable en términos de los recursos necesarios para la instalación y adaptación a diferentes entornos y diferentes actores.

Calidad de los artefactos

Evaluar la Calidad de los artefactos de un sistema es evaluar en que medida tienen sus artefactos grados de calidad que están por sobre grados de calidad predeterminados.

Evaluable en términos de de los grados de calidad obtenidos por los artefactos.

Cobertura de contextos de entorno

Cumplir con los requisitos de Cobertura de contexto de entorno significa que el sistema funciona con el mismo grado de calidad en todos los contextos de uso (en todos los entornos creados por otros sistemas) ya sean éstos entornos previsibles (explícitos en los requerimientos o entornos que se suponen implícitamente).

Evaluable en términos de la reducción en los grados de calidad de del sistema por cambios de contexto.

Constancia

Cumplir con los requisitos de Constancia significa que el sistema cumple sus funciones con calidad ininterrumpida de modo que la calidad no se degrada con los cambios que él mismo genera en el entorno.

Evaluable en términos de la reducción en los grados de calidad de del sistema como reacción a cambios del entorno.

Cumplimiento legal

Cumplir con los requisitos de Cumplimiento legal significa que el sistema cumple con todos los requisitos legales en el contexto de las exigencias legales vigentes, aplicables al sistema.

Evaluable en términos de validar que el sistema no viola las exigencias legales.

Efectividad

Cumplir con los requisitos de Efectividad significa que el sistema suministra todas/el máximo posible de las funciones en el contexto de las necesitadas/deseos de todos los stakeholders.

Evaluable en términos de encuestas a los stakeholders.

Eficiencia

Cumplir con los requisitos de Eficiencia significa que el sistema realizas sus funciones con mínimo uso de recursos.

Evaluable en términos de la medición de los usos de los recursos.

Estandarizado

Cumplir con los requisitos de Estandarizado significa que el sistema suministra interfaces siguiendo estándares reconocidos en el contexto de su uso por usuarios y otros actores de modo que pueda ser usado en lugar de (o ser reemplazado por) otros sistemas que suministren funciones similares en el mismo dominio, sin que se necesiten invertir recursos por encima de los pre-establecidos.

Evaluable en términos la validación de las interfaces estándar y medida de los recursos necesario para su remplazo.

Mantenimiento

Cumplir con los requisitos de Mantenimiento significa que el sistema en el contexto de ampliaciones, mejoras y correcciones de errores de modo que éstas sólo requieran un esfuerzo determinado.

Evaluable en términos la medición de los esfuerzos requeridos en su mantenimiento.

Recuperabilidad de fallas

Cumplir con los requisitos de Recuperabilidad de fallas significa que el sistema no pierde (o recupera fácilmente) su último estado coherente en el contexto de alguna falla, sea ésta causada por una falla en algún componente del software, o por su mal uso de modo que la recuperación esté dentro de en un predeterminado intervalo de tiempo.

Evaluable en términos la medición de los tiempos y extensión de recuperación de fallas.

Satisfacción subjetiva de los stakeholders

Cumplir con los requisitos de Satisfacción de los stakeholders significa que el sistema se desempeña de modo que los stakeholders tienen una subjetiva percepción de satisfacción del uso del sistema.

Evaluable en términos de las opiniones subjetivas de los stakeholders.

Satisfacción de los usuarios

Cumplir con los requisitos de Satisfacción de los usuarios significa que el sistema hace sentir confortable al usuario en el contexto de su uso.

Evaluable en términos de las opiniones subjetivas de los usuarios.

Seguridad de no causar daños

Cumplir con los requisitos de Seguridad de daños significa que el sistema no es causante de de daños indirectos que puedan ser causados en el contexto de su uso.

Daños Indirectos: Cambios en el estado del entorno del sistema a causa de los cuales una o mas personas se ven negativamente afectadas. No incluye daños causados por falta de seguridad informática (ver “Seguridad informática”).

Evaluable en términos de las opiniones subjetivas de los usuarios.

Seguridad informática

Cumplir con los requisitos de Seguridad informática significa que el sistema no permite el acceso a los datos que manipula ni a las funciones que ejecuta en el contexto de alguien que no esté autorizado a ello.

Testabilidad

Cumplir con los requisitos de Testabilidad significa que el sistema puede ser testeado en el contexto de sus revisiones de modo que el grado de calidad del proceso de testing no esté por debajo de un grado determinado sin necesidad de recursos que excedan niveles determinados.

Evaluable en términos de Evaluable en términos de grado de calidad del proceso de testing y los recursos necesarios para el testing.

Tiempo Real

Cumplir con los requisitos de Tiempo Real significa que el sistema no produce salidas tardías en el contexto de los tiempos en que se estos outputs necesitan ser usados.

Manejo de fallas

Cumplir con los requisitos de Manejo de fallas significa que el sistema en el contexto de una posible falla, la previene o mantiene un nivel de funcionamiento predeterminado, sea ésta por culpa del software, o por su mal uso de modo que el daño causado por la falla no supere un límite determinado.

Usabilidad (objetiva)

Cumplir con los requisitos de Usabilidad (objetiva) significa que el sistema se desempeña en el contexto de su uso de modo que los usuarios desempeñan su rol con una eficiencia mayor a una pre-establecida.

Evaluable en términos de las mediciones de eficiencia de los usuarios.

Validez informática

Cumplir con los requisitos de Validez informática significa que el sistema produce como output datos y procesos válidos en el contexto de la utilización posterior de esos datos y de los resultados de los procesos.

Si bien a la fecha este modelo fue probado a través de 3 proyectos de Evaluación de software, se agradece cualquier aporte referido a su facilidad de comprensión, y completitud.