PDF de programación - CAPÍTULO 4 Métricas en el desarrollo del Software

CAPÍTULO 4

Métricas en el desarrollo del Software



4.1 Las Métricas y la Calidad de Software

El objetivo primordial de la ingeniería del software es producir un sistema,

aplicación o producto de alta calidad. Para lograr este objetivo, los ingenieros de

software deben emplear métodos efectivos junto con herramientas modernas

dentro del contexto de un proceso maduro de desarrollo del software. Al mismo

tiempo, un buen ingeniero del software y buenos administradores de la ingeniería

del software deben medir si la alta calidad se va a llevar a cabo. A continuación se

verá un conjunto de métricas del software que pueden emplearse a la valoración

cuantitativa de la calidad de software

El punto de vista de ¿Qué es calidad? Es diverso, y por lo tanto existen distintas

respuestas, tales como se muestra a continuación:

El American Heritage Dictionary [Pressman ´98] define la calidad como

“Una característica o atributo de algo.”

La definición estándar de calidad en ISO-8402 es “La totalidad de rasgos y

características de un producto, proceso o servicio que sostiene la habilidad

de satisfacer estados o necesidades implícitas” [Mcdermid ’91].

“Concordar explícitamente al estado funcional y a los requerimientos del

funcionamiento, explícitamente a los estándares de documentación de



60

desarrollo, e implícitamente características que son expectativas de todos

los desarrolladores profesionales de software” [Pressman ’93].

La calidad de un sistema, aplicación o producto es tan buena como los

requisitos que detallan el problema, el diseño que modela la solución, el código

que transfiere a un programa ejecutable y las pruebas que ejercita el software para

detectar errores. Un buen ingeniero del software emplea mediciones que evalúan

la calidad del análisis y los modelos de diseño, así como el código fuente y los

casos de prueba que se han establecido al aplicar la ingeniería del software. Para

obtener esta evaluación de calidad, el ingeniero debe utilizar medidas técnicas,

que evalúan la calidad con objetividad, no con subjetividad. Asimismo, un buen

administrador de proyectos debe evaluar

la calidad objetivamente y no

subjetivamente. A medida que el proyecto progresa el administrador del proyecto

siempre debe valorar la calidad. Aunque se pueden recopilar muchas medidas de

calidad, el primer objetivo en el proyecto es medir errores y defectos. Las métricas

que provienen de estas medidas proporcionan una indicación de la efectividad de

las actividades de control y de la garantía de calidad en grupos o en particulares.

Por ejemplo los errores detectados por hora de revisión y los errores detectados

por hora de prueba suministran una visión profunda de la eficacia de cada una de

las actividades envueltas en la métrica. Así los datos de errores se pueden utilizar

también para calcular la eficiencia de eliminación de defectos en cada una de las

actividades del marco de trabajo del proceso.



61

4.1.1 Visión General de los Factores que Afectan a la Calidad



McCall y Cavano [John A. McDermid ‘91] definieron un juego de factores de

calidad como los primeros pasos hacia el desarrollo de métricas de la calidad del

software. Estos factores evalúan el software desde tres puntos de vista distintos:

(1) operación del producto (utilizándolo), (2) revisión del producto (cambiándolo) y

(3) transición del producto (modificándolo para que funcione en un entorno

diferente, por ejemplo: “portándolo”) Los autores describen la relación entre estos

factores de calidad (lo que llaman un ‘marco de trabajo’) y otros aspectos del

proceso de ingeniería del software:

En primer lugar el marco de trabajo proporciona al administrador identificar

en el proyecto lo que considera importante, como: facilidad de mantenimiento y

transportabilidad, atributos del software, además de su corrección y rendimiento

funcional teniendo un impacto significativo en el costo del ciclo de vida. En

segundo lugar, proporciona un medio de evaluar cuantitativamente el progreso en

el desarrollo de software

teniendo relación con

los objetivos de calidad

establecidos. En tercer lugar, proporciona más interacción del personal de calidad,

en el esfuerzo de desarrollo. Por último, el personal de calidad puede utilizar

indicaciones de calidad que se establecieron como ”pobres” para ayudar a

identificar estándares “mejores” para verificar en el futuro.



Es importante destacar que casi todos los aspectos del cálculo han sufrido

cambios radicales con el paso de los años desde que McCall y Cavano hicieron su

trabajo, teniendo gran influencia, en 1978. Pero los atributos que proporcionan una

indicación de la calidad del software siguen siendo los mismos. Si una



62

organización de software adopta un juego de factores de calidad como una “lista

de comprobación” para evaluar la calidad del software, es probable que el

software construido hoy siga exhibiendo la buena calidad dentro de las primeras

décadas del siglo XXI. Incluso, cuando las arquitecturas del cálculo sufrán

cambios radicales (como seguramente ocurrirá), el software que exhibe alta

calidad en operación, transición y revisión continuará sirviendo a sus usuarios.



4.1.2 Medida de la calidad



Aunque hay muchas medidas de la calidad de software, la corrección,

facilidad de mantenimiento, integridad y facilidad de uso suministran indicadores

útiles para el equipo del proyecto. Gilb [Len O. Ejiogo ‘90] sugiere definiciones y

medidas para cada uno de ellos, tales como:



Corrección: A un programa le corresponde operar correctamente o suministrará

poco valor a sus usuarios. La corrección es el grado en el que el software lleva a

cabo una función requerida. La medida más común de corrección son los defectos

por KLDC, en donde un defecto se define como una falla verificada de

conformidad con los requisitos.

Facilidad de mantenimiento. El mantenimiento del software cuenta con más

esfuerzo que cualquier otra actividad de ingeniería del software. La facilidad de

mantenimiento es la habilidad con la que se puede corregir un programa si se

encuentra un error, se puede adaptar si su entorno cambia o optimizar si el cliente

desea un cambio de requisitos. No hay forma de medir directamente la facilidad de



63

mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una

métrica orientada al tiempo simple es el tiempo medio de cambio (TMC), es decir,

el tiempo que se tarda en analizar la petición de cambio, en diseñar una

modificación apropiada, en efectuar el cambio, en probarlo y en distribuir el cambio

a todos los usuarios. En promedio, los programas que son más fáciles de

mantener tendrán un TMC más bajo (para tipos equivalentes de cambios) que los

programas que son más difíciles de mantener.

Hitachi ha empleado una métrica orientada al costo (precio) para la

capacidad de mantenimiento, llamada “desperdicios”. El costo estará en corregir

defectos hallados después de haber distribuido el software a sus usuarios finales.

Cuando la proporción de desperdicios en el costo global del proyecto se simboliza

como una función del tiempo, es aquí donde el administrador logra determinar si la

facilidad de mantenimiento del software producido por una organización de

desarrollo está mejorando y asimismo se pueden emprender acciones a partir de

las conclusiones obtenidas de esa información.

Integridad. En esta época de intrusos informáticos y de virus, la integridad del

software ha llegado a tener mucha importancia. Este atributo mide la habilidad de

un sistema para soportar ataques (tanto accidentales como intencionados) contra

su seguridad. El ataque se puede ejecutar en cualquiera de los tres componentes

del software, ya sea en los programas, datos o documentos.

Para medir la integridad, se tienen que definir dos atributos adicionales:

amenaza y seguridad. La amenaza es la probabilidad (que se logra evaluar o

concluir de la evidencia empírica) de que un ataque de un tipo establecido ocurra

en un tiempo establecido. La seguridad es la probabilidad (que se puede estimar o



64

deducir de la evidencia empírica) de que se pueda repeler el ataque de un tipo

establecido, en donde la integridad del sistema se puede especificar como:

integridad = Ó[1- amenaza x (1- seguridad)]



(4.1)

donde se suman la amenaza y la seguridad para cada tipo de ataque.

Facilidad de uso. El calificativo “amigable con el usuario” se ha transformado

universalmente en disputas sobre productos de software. Si un programa no es

“amigable con el usuario”, prácticamente está próximo al fracaso, incluso aunque

las funciones que realice sean valiosas. La facilidad de uso es un intento de

cuantificar “lo amigable que pude ser con el usuario” y se consigue medir en

función de cuatro características: (1) destreza intelectual y/o física solicitada para

aprender el sistema; (2) el tiempo requerido para alcanzar a ser moderadamente

eficiente en el uso del sistema; (3) aumento neto en productividad (sobre el

enfoque que el sistema reemplaza) medida cuando alguien emplea el sistema

moderadamente y eficientemente, y (4) valoración subjetiva (a veces