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.