Breves notas sobre la Medición de los Atributos Externos del Software

En esta lección estamos interesados en medir características del software que dependen de la visión externa del producto. El objetivo principal y más importante de la ingeniería del software es la mejora de la calidad de los productos software.

Calidad.

El término calidad del software se interpreta de diferentes maneras. Una de las definiciones más difundidas de calidad es la debida a McCall (1977), que especifica una serie de factores. Cada uno de esos factores los subdivide en criterios, teniendo asociado cada uno de ellos una métrica. La tabla siguiente muestra algunos factores generales de calidad.

FACTOR	DEFINICIÓN
Corrección	Grado en el que un programa satisface las especificaciones y cumple los objetivos del usuario.
Fiabilidad	Grado en el que un programa se espera que realice su función con una precisión requerida.
Eficiencia	Cantidad de recursos y código requeridos por un programa para realizar una función.
Integridad	Grado en el que se controla el acceso al programa o los datos por usuarios no autorizados.
Usabilidad	Esfuerzo necesario para aprender, operar, preparar entradas e interpretar la salida de un programa.
Mantenibilidad	Esfuerzo requerido para localizar y corregir un error en un programa en funcionamiento.
Facilidad de prueba	Esfuerzo requerido para probar un programa (para garantizar que realiza la función deseada).
Flexibilidad	Esfuerzo requerido para modificar un programa en funcionamiento.
Portabilidad	Esfuerzo requerido para trasferir un programa de una configuración hardware o entorno software a otro.
Reusabilidad	Grado en el que un programa se puede utilizar en otras aplicaciones
Interoperatividad	Esfuerzo requerido para acoplar un sistema con otro.

Algunos Factores de Calidad del Software

Así, la calidad del software se puede medir a través de estos atributos (aunque puede haber algunos internos), que representan diferentes visiones de la misma. Los más importantes son la fiabilidad, mantenibilidad y usabiliad. El estándar IEEE Software Quality Metrics también establece una descomposición de factores de calidad. Existe otro punto de vista en la definición de calidad: es el llamado subjetivo, en el que no se toma un modelo de calidad prefijado, sino que para un producto dado se definen atributos de calidad conjuntamente con el usuario. Una visión más restrictiva, pero habitual, de la calidad consiste en asociarla exclusivamente con la ausencia de "defectos".

Fiabilidad

Una definición ampliamente aceptada de fiabilidad del software es: "la probabilidad de que un programa realice su objetivo satisfactoriamente (sin fallos) en un determinado periodo de tiempo y en un entorno concreto (denominado perfil operacional)". Se supone que los fallos ocurren probabilísticamente en el tiempo de acuerdo con una "tasa de intensidad de fallos". Una clase importante de modelos de fiabilidad, es la de considerar el número de fallos observados en el intervalo de tiempo (0, t) generados por un proceso de Poisson. Si se satisfacen esas condiciones, un proceso de Poisson homogéneo -modelo de intensidad de fallos constante- caracteriza el comportamiento de los fallos de un programa en la fase de operación y entre diferentes versiones, provocado por la ausencia de depuración y corrección de fallos. Un modelo de proceso de Poisson no homogéneo con una función de intensidad de fallos decreciente -modelo de fiabilidad creciente- es aplicable cuando se efectúan correcciones a los fallos observados, por ejemplo en la prueba del sistema.

Ejemplos.

En un modelo de fiabilidad creciente -Poisson exponencial no homogéneo-, la intensidad de fallos l(t) se expresa como un decrecimiento exponencial en el tiempo

y así la media de fallos acumulados µ(t) se acerca exponencialmente a una asíntota

.

En otro modelo de fiabilidad creciente -Poisson logarítmico no homogéneo-, la intensidad de fallos es una familia de funciones lineales inversas con respecto al tiempo

de tal modo que el número de fallos acumulados esperados es una función logarítmica del tiempo

La figura A presenta un ejemplo del primer caso. La figura B indica cómo aplicar el enfoque de medición de la fiabilidad durante las pruebas del sistema.

Usabilidad.

La usabilidad de un producto es el grado en el que el producto es práctico y fácil de utilizar. Esta característica debe subdividirse en atributos más fundamentales para que sea posible algún tipo de medición; algunos a considerar pueden ser

• nivel requerido: medido en años de experiencia con aplicaciones similares

• aprendizaje: medido en horas de adiestramiento requeridas antes de la utilización independiente

• capacidad de manipulación: medida en velocidad de trabajo después del adiestramiento y/o errores cometidos a velocidad normal de trabajo.

Atributos internos de usabilidad.

Se puede considerar el número de pantallas de ayuda y opciones de menú.

Mantenibilidad.

Una definición amplia de mantenibilidad es la de "facilidad de comprender, corregir, adaptar y mejorar el software.

Existen tres tipos de mantenimiento:

• mantenimiento correctivo: corregir errores

• mantenimiento adaptivo: modificar el software de acuerdo con el entorno

• mantenimiento perfectivo: añadir nueva funcionalidad

El mantenimiento preventivo no están tan extendido y consiste en cambiar el producto pensando en mejoras futuras.

Visión externa de la mantenibilidad.

La medida más común dependiente del entorno es el tiempo medio para realizar un cambio (MTTR). Otras medidas son

• cociente del tiempo total empleado en corregir errores entre el número total de errores corregidos

• número de problemas no resueltos

• tiempo empleado en problemas no resueltos

• porcentaje de cambios que introducen fallos

• número de módulos modificados para realizar un cambio.

Atributos internos de mantenibilidad.

Existe una clara conexión entre productos poco estructurados y documentados y su mantenimiento, y por tanto serían aquí pertinentes las métricas correspondientes a esas características. También es conocida la regla de McCabe: "un módulo no debe tener una complejidad ciclomática mayor de 10". Complementariamente a esto se ha propuesto que la medida VINAP no debe ser mayor que 100.

La legibilidad de un texto se puede medir con la medida F (índice Fog)

.

Esta medida se supone corresponde burdamente con el número de años de colegio que una persona requeriría para leer un texto con facilidad.

Ver libro.

Defectos

Un defecto, en su sentido más amplio, es un anomalía en la especificación, diseño o implementación de un producto. Una mejora no es un defecto. Se entiende por mejora un cambio que no hubiera sido detectado, o, en caso afirmativo, no hubiera sido corregido. A continuación se presenta una posible clasificación de los defectos en el desarrollo de software (según R.B. Grady).

Defectos en Especificaciones/Requerimientos.

Es una incorrección en la definición de las necesidades del usuario para el sistema o componente del mismo.

Requerimientos o especificaciones: no describen adecuadamente las necesidades de los usuarios. Se incluyen los efectos de la estrategia de redirección del producto y los casos donde se incrementa la funcionalidad para aumentar el valor de mercado

Funcionalidad: características de producto incorrectas o incompatibles

Interfaces de usuario, de software y de hardware: especificaciones incorrectas sobre cómo el producto interaccionará con su entorno.

Descripción funcional: descripciones incorrectas sobre qué hace el producto.

Defectos de Diseño.

Una equivocación en el diseño del sistema o de un componente. Tales errores pueden ocurrir en algoritmos, lógica de control, estructuras de datos, acceso a bases de datos, formatos entrada/salida, descripciones de interface. Los defectos pueden estar causados por una pobre especificación de los requerimientos. Este puede dar lugar a un diseño incorrecto que provocará código incorrecto. Se pueden detectar los defectos verificando si el diseño satisface las especificaciones.

Hardware, software e interfaces de usuario: problemas con diseño incorrecto sobre cómo el producto interacciona con el entorno y usuarios. Por ejemplo: uso incorrecto de librerías, diseños que no implementan los requerimientos, diseños que no cumplen los requisitos de usabilidad.

Descripción funcional: el diseño no hace lo que el módulo/producto debiera. Son defectos encontrados durante la inspección del diseño o durante la implementación.

Comunicaciones entre procesos: comunicaciones e interfaces incorrectos entre procesos del producto.

Definición de datos: diseño incorrecto de las estructuras de datos a utilizar en el módulo/producto.

Diseño del módulo: problemas con el flujo de control y ejecución entre procesos.

Descripción de la lógica: el diseño es incorrecto en la lógica. Es un defecto encontrado durante la inspección o la implementación.

Chequeo de errores: incorrecta verificación de las condiciones de error.

Estándares: el diseño no se adhiere a los estándares locales.

Defectos de código.

Errores o equivocaciones en la implementación de un programa: Pueden estar en el producto, en el código de pruebas, ficheros, etc. Los defectos se pueden causar por una pobre comprensión del diseño o mala elección de las estructuras de datos y algoritmos, o errores de lógica o sintaxis. Los defectos se corrigen usualmente modificando el código, y, ocasionalmente, modificando el diseño para adecuarlo al código ya escrito (que es lo que inicialmente se pretendía). Algunos defectos pueden no ser detectados a menos que se utilicen datos de prueba adecuados o algún método de verificación de código. Los defectos pueden ser causados por correcciones y otros defectos. En la fase de pruebas se corrigen los defectos modificando el código.

Lógica: pasos olvidados, lógica duplicada, funciones innecesarias, etc.

Problemas de computación: pérdida de precisión, ecuaciones incorrectas, etc.

Problemas de manipulación de datos: inicialización incorrecta, acceso o almacenamiento de datos incorrectos, unidades o escalas incorrectas, incorrecto dimensionamiento de los datos, etc.

Implementación/interface del módulo: problemas relacionados con llamadas, paso de parámetros, terminación de subprocesos, etc.

Estándares: el código no se adhiere a estándares locales.

Defectos de Documentación

Errores en manuales, instrucciones de instalación, demostraciones, todos ellos entregados al cliente.

Defectos del entorno de apoyo

Son los que resultan del entorno de desarrollo y de pruebas, como errores de configuración, de integración de herramientas, etc.

Software de pruebas: problemas de software utilizado para probar las capacidades del producto

Hardware de pruebas: problemas del hardware de pruebas, no del hardware en el que corre el producto

Herramientas de desarrollo: si no se comportan adecuadamente

Software de integración: problemas de integración software/herramientas.

Modos

Olvidado ("missing"): la información no aparecía en el producto intermedio.

Confuso ("unclear"): la información es engañosa, ambigua o difícil de entender.

Incorrecto ("wrong"): la información es claramente incorrecta.

Cambiado ("changed"): cambios en el producto intermedio provocaron cambios en otros productos intermedios.

Manera mejor ("better way"): existía otra manera mejor de realizar ese producto intermedio, por motivos de eficiencia, rendimiento, legibilidad, mantenibilidad u otros.