Métricas en El Desarrollo Del Software

MÉTRICAS EN EL DESARROLLO
DEL SOFTWARE
19 DE JUNIO DE 2020
ALONSO CUELLAR MIGUEL AGEL
1620IS
Las Métricas y la Calidad de Software
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.
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
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.
• Corrección: A un programa le corresponde operar correctamente o

suministrará poco valor a sus usuarios.
• Facilidad de mantenimiento. El mantenimiento del software cuenta con más
esfuerzo que cualquier otra actividad de ingeniería del software.
• Integridad. En esta época de intrusos informáticos y de virus, la integridad
del software ha llegado a tener mucha importancia.
• 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.
Medidas de fiabilidad y de disponibilidad.
Todos los fallos del software, se producen por problemas de diseño o de

implementación.
Considerando un sistema basado en computadora, una medida sencilla de la

fiabilidad es el tiempo medio entre fallos (TMEF) [Mayrhauser ́91], donde:
TMEF = TMDF+TMDR
(TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparación)).
Muchos investigadores argumentan que el TMDF es con mucho, una medida más
útil que los defectos/KLDC, simplemente porque el usuario final se enfrenta a los
fallos, no al número total de errores.
Eficacia de la Eliminación de Defectos
Una métrica de la calidad que proporciona beneficios tanto a nivel del proyecto
como del proceso, es la eficacia de la eliminación de defectos (EED) En particular
el EED es una medida de la habilidad de filtrar las actividades de la garantía de
calidad y de control al aplicarse a todas las actividades del marco de trabajo del
proceso.
Cuando se toma en consideración globalmente para un proyecto, EED se define

de la forma siguiente:
EED = E / (E + D)
donde E= es el número de errores encontrados antes de la entrega del software al

usuario final y D= es el número de defectos encontrados después de la entrega.
Factores de Calidad de McCall
Los factores que perturban la calidad del software se pueden categorizar en
dos grandes grupos:
1. Factores que se pueden medir directamente (por ejemplo: defectos por

puntos de función)
2. Factores que se pueden medir sólo indirectamente (por ejemplo: facilidad
de uso o de mantenimiento).
McCall y sus colegas plantearon una categorización de factores que afectan a la

calidad de software, en donde se centralizan con tres aspectos importantes de un
producto de software: sus características operativas, su capacidad de cambio y su
adaptabilidad a nuevos entornos.
• Corrección: Hasta dónde satisface un programa su especificación y

consigue los objetivos de la misión del cliente.
• Fiabilidad: Hasta dónde puede quedarse un programa que lleve a cabo su
función pretendida con la exactitud solicitada. Cabe hacer notar que se han
propuesto otras definiciones de fiabilidad más completas.
• Eficiencia: El conjunto de recursos informáticos y de código necesarios para
que un programa realice su función.
• Integridad: Hasta dónde se puede controlar el acceso al software o a los
datos por individuos no autorizados.
• Usabilidad (facilidad de manejo): El esfuerzo necesario para aprender,
operar, y preparar datos de entrada e interpretar las salidas (resultados) de
un programa.
• Facilidad de mantenimiento: El esfuerzo necesario para localizar y arreglar
un error en un programa.
• Flexibilidad: El esfuerzo necesario para modificar un programa operativo.
• Facilidad de prueba: El esfuerzo necesario para aprobar un programa para
asegurarse de que realiza su función pretendida.
• Portabilidad: El esfuerzo necesario para trasladar el programa de un
entorno de sistema hardware y/o software a otro.
• Reusabilidad: (capacidad de reutilización): Hasta dónde se puede volver a
utilizar un programa (o partes) en otras aplicaciones con relación al
empaquetamiento y alcance de las funciones que ejecuta el programa.
• Inter operatividad: El esfuerzo necesario para acoplar un sistema con otro.
Métricas del modelo de análisis
En esta fase se obtendrán los requisitos y se establecerá el fundamento para el

diseño. Y es por eso que se desea una visión interna a la calidad del modelo de
análisis.
Métricas basadas en la función
En donde se representa un diagrama de flujo de datos, de una función de una

aplicación de software llamada Hogar Seguro. La función administra la interacción
con el usurario, aceptando una contraseña de usuario para activar/ desactivar el
sistema y permitiendo consultas sobre el estado de las zonas de seguridad y
varios censores de seguridad. La función muestra una serie de mensajes de
petición y envía señales apropiadas de control a varios componentes del sistema
de seguridad.
El diagrama de flujo de datos se evalúa para determinar las medidas clave

necesarias para el cálculo de la métrica de PF.:
• número de entradas de usuario

• número de salidas de usuario
• número de consultas del usuario
• número de archivos
• número de interfaces externas
La métrica Bang
Puede emplearse para desarrollar una indicación del tamaño del software a
implementar como consecuencia del modelo de análisis.
Para calcular la métrica bang, el desarrollador de software debe evaluar primero

un conjunto de primitivas (elementos del modelo de análisis que no se subdividen
más en el nivel de análisis) Las primitivas se determinan evaluando el modelo de
análisis y desarrollando cuentas para los siguientes elementos:
• Primitivas funcionales (Pfu) Transformaciones (burbujas) que aparecen en

el nivel inferior de un diagrama de flujo de datos.
• Elementos de datos (ED) Los atributos de un objeto de datos, los elementos
de datos no compuestos y aparecen en el diccionario de datos.
• Objetos (OB) Objetos de datos.
• Relaciones (RE) Las conexiones entre objetos de datos.
• Transiciones (TR) El número de transacciones de estado en el diagrama de
transición de estado.
Además de las seis primitivas nombradas arriba, se determinan medidas

adicionales para:
• Primitivas modificadas de función manual (PMFu) Funciones que caen

fuera del límite del sistema y que deben modificarse para acomodarse al
nuevo sistema.
• Elementos de datos de entrada (EDE) Aquellos elementos de datos que se
introducen en el sistema.
• Elementos de datos de salida (EDS) Aquellos elementos de datos que se
sacan en el sistema.
• Elementos de datos retenidos (EDR) Aquellos elementos de datos que son
retenidos (almacenados) por el sistema.
• Muestras (tokens) de datos (TCi) Las muestras de datos (elementos de
datos que no se subdividen dentro de una primitiva funcional) que existen
en el l’imite de la i-ésima primitiva funcional (evaluada para cada primitiva).
Métricas de diseño en los componentes
Las métricas de diseño a nivel de componentes se concentran en las

características internas de los componentes del software e incluyen medidas de la
cohesión, acoplamiento y complejidad del módulo. Estas tres medidas pueden
ayudar al desarrollador de software a juzgar la calidad de un diseño a nivel de
componentes.
Las métricas presentadas son de “caja blanca” en el sentido de que requieren

conocimiento del trabajo interno del módulo en cuestión. Las métricas de diseño
en los componentes se pueden aplicar una vez que se ha desarrollado un diseño
procedimental. También se pueden retrasar hasta tener disponible el código
fuente.
Métricas de cohesión.
Bieman y Ott [Hamdi ‘99] definen una colección de métricas que proporcionan una
indicación de la cohesión de un módulo. Las métricas se definen con cinco
conceptos y medidas:
• Porción de datos. Dicho simplemente, una porción de datos es una marcha

atrás a través de un módulo que busca valores de datos que afectan a la
localización del módulo en el que empezó la marcha atrás. Debería
resaltarse que se pueden definir tanto porciones de programas (que se
centran en enunciados y condiciones) como porciones de datos.
• Símbolos léxicos (tokens) de datos. Las variables definidas para un módulo
pueden definirse como señales de datos para el módulo.
• Señales de unión. El conjunto de señales de datos que se encuentran en
uno o más porciones de datos.
• Señales de super-unión. Las señales de datos comunes a todas las
porciones de datos de un módulo.
• Cohesión. La cohesión relativa de una señal de unión es directamente
proporcional al número de porciones de datos que liga.
Métricas de acoplamiento.
El acoplamiento de módulo proporciona una indicación de la “conectividad” de un

módulo con otros módulos, datos globales y entorno exterior.
Las medidas necesarias para calcular el acoplamiento de módulo se definen en

términos de cada uno de los tres tipos de acoplamiento apuntados anteriormente.
Para el acoplamiento de flujo de datos y de control:
• di = número de parámetros de datos de entrada

• ci = número de parámetros de control de entrada
• do = número de parámetros de datos de salida
• co = número de parámetros de control de salida
Para el acoplamiento global:
• gd = número de variables globales usadas como datos

• gc = número de variables globales usadas como control
Para el acoplamiento de entorno:
• w = número de módulos llamados (expansión)

• r = número de módulos que llaman al módulo en cuestión (concentración)
Métricas de complejidad.
Se pueden calcular una variedad de métricas del software para determinar la

complejidad del flujo de control del programa. Muchas de éstas se basan en una
representación denominada grafo de flujo, un grafo es una representación
compuesta de nodos y enlaces (también denominados filos) Cuando se dirigen los
enlaces (aristas), el grafo de flujo es un grafo dirigido.

Métricas en El Desarrollo Del Software

Cargado por

Copyright:

Formatos disponibles

Métricas en El Desarrollo Del Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Métricas en El Desarrollo Del Software

Cargado por

Copyright:

Formatos disponibles

MÉTRICAS EN EL DESARROLLO

ingeniería del software es producir un sistema, aplicación o producto de alta calidad.

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

1. Operación del producto (utilizándolo)

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

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

Medidas de fiabilidad y de disponibilidad.

Todos los fallos del software, se producen por problemas de diseño o de

Considerando un sistema basado en computadora, una medida sencilla de la

(TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparación)).

Eficacia de la Eliminación de Defectos

Cuando se toma en consideración globalmente para un proyecto, EED se define

donde E= es el número de errores encontrados antes de la entrega del software al

Los factores que perturban la calidad del software se pueden categorizar en

dos grandes grupos:

1. Factores que se pueden medir directamente (por ejemplo: defectos por

McCall y sus colegas plantearon una categorización de factores que afectan a la

• Corrección: Hasta dónde satisface un programa su especificación y

Métricas del modelo de análisis

En esta fase se obtendrán los requisitos y se establecerá el fundamento para el

Métricas basadas en la función

En donde se representa un diagrama de flujo de datos, de una función de una

El diagrama de flujo de datos se evalúa para determinar las medidas clave

• número de entradas de usuario

Para calcular la métrica bang, el desarrollador de software debe evaluar primero

• Primitivas funcionales (Pfu) Transformaciones (burbujas) que aparecen en

Además de las seis primitivas nombradas arriba, se determinan medidas

• Primitivas modificadas de función manual (PMFu) Funciones que caen

Las métricas de diseño a nivel de componentes se concentran en las

Las métricas presentadas son de “caja blanca” en el sentido de que requieren

• Porción de datos. Dicho simplemente, una porción de datos es una marcha

El acoplamiento de módulo proporciona una indicación de la “conectividad” de un

Las medidas necesarias para calcular el acoplamiento de módulo se definen en

Para el acoplamiento de flujo de datos y de control:

• di = número de parámetros de datos de entrada

Para el acoplamiento global:

• gd = número de variables globales usadas como datos

Para el acoplamiento de entorno:

• w = número de módulos llamados (expansión)

Se pueden calcular una variedad de métricas del software para determinar la

También podría gustarte