MÉTRICAS DE CALIDAD

DE SOFTWARE MIS TAREAS

1.
 Métricas de Calidad Mis Tareas

1. CLASIFICACIÓN DE MÉTRICAS

1.2. Métricas De Funcionalidad

En este grupo se conjunta una serie de atributos que permiten calificar si un

producto de software maneja en forma adecuada el conjunto de funciones que
satisfagan las necesidades para las cuales fue diseñado. Para este propósito se
establecen los siguientes atributos:

• Adecuación: Se enfoca a evaluar si el software cuenta con un conju nto de

funciones apropiadas para efectuar las tareas que fueron especificadas en
su definición.
• Exactitud: Este atributo permite evaluar si el software presenta resultados o
efectos acordes a las necesidades para las cuales fue creado.
• Interoperabilidad: Permite evaluar la habilidad del software de interactuar
con otros sistemas previamente especificados.
• Conformidad: Evalúa si el software se adhiere a estándares, convenciones
o regulaciones en leyes y prescripciones similares.
• Seguridad: Se refiere a la habilidad de prevenir el acceso no autorizado, ya
sea accidental o premeditado, a los programas y datos.

1.1.1. Puntos De Función

Descripción
Se puede utilizar como medio para predecir el tamaño de un sistema
obteniendo a partir de un modelo de análisis.
• Miden la funcionalidad del software
• No se pueden medir directamente
• Evalúa la complejidad del software
Para la utilización de esta métrica se utiliza un diagrama de flujo de datos, el
cual se evaluar para determinar las medidas claves necesarias para el cálculo
de la métrica
Tabla de cálculos

2
 Métricas de Calidad Mis Tareas

PARAMETROS CUENTA FACTOR DE PONDERACIÓN SUBOTAL

LOGUIN 1 MEDIO 3
CREAR CUENTA 2 SIMPLE 2
ACTAS 5 COMPLEJO 4
TAREAS 7 COMPLEJO 5

3
 Métricas de Calidad Mis Tareas

Parámetros Descripción
Entradas de Existen varias entradas de usuarios en los formularios de
usuario tareas, actas, registro y login donde el usuario llenara los
campos correspondientes
Salen varios reportes de errores y mensajes de
Salidas de transacciones exitosas según sea el caso de las acciones
usuario
que este realizando el cliente
Cuando se crea correctamente un usuario, acta o tarea se
Peticiones generan mensajes al cliente para indicar el proceso éxito de
de usuario
la creación de la acción realizada
La aplicación permite la carga y descarga de archivos
Archivos
cargados por el usuario
Interfaces No aplica.
externas
Descripción De los 14 ítems señalados abajo se escogerán los que
de cuenta aplican para nuestro proyecto.
Descripción
Se le va a dar el peso del 1 al 5 donde 5 es la mayor y 1 la
de factor de
menor.
ponderación
Descripción Es el resultado de la multiplicación entre el valor de cuenta y
de subtotal factor de ponderación que se escoja para el parámetro.
Variable Descripción
Cuenta-total Es la suma de todos los subtotales.
Indica un valor de ajuste de complejidad, generado por la
suma del peso(1-5) dado a las siguientes preguntas

Fórmula

𝑃𝐹 = 𝑐𝑢𝑒𝑛𝑡𝑎 − 𝑡𝑜𝑡𝑎𝑙 ∗ [0.65 + 0.01 ∗ Σ(𝐹)

PF=35-20*[0.65 + 0.01 ∗ 35)]=3.48

4
 Métricas de Calidad Mis Tareas

1.1.2. Métrica De Precisión y Exhaustividad

Descripción de Precisión
La precisión es el ratio entre el número de documentos relevantes
recuperados entre el número de documentos recuperados.
Cuanto más se acerque el valor de la precisión al valor nulo, mayor será el
número de documentos recuperados que no consideren relevantes. Si por el
contrario, el valor de la precisión es igual a uno, se entenderá que todos los
documentos recuperados son relevantes. Esta forma de entender la precisión
introduce el concepto de ruido informativo y de silencio informativo.
Variables Descripción
Documentos Numero de documentos que fueron recuperados y son
relevantes positivos para el proyecto
Documentos Numero de documentos recuperados en total referentes al
recuperados proyecto
Fórmula

|{𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠=15 } ∩ { 𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠=11 } |

𝑝𝑟𝑒𝑐𝑖𝑠𝑖ó𝑛 =
|{𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠=11 }| = 1

Descripción de Exhaustividad
La exhaustividad se emplea en menor medida que la precisión. Este ratio
viene a expresar la proporción de documentos relevantes recuperados,
comparado con el total de los documentos que son relevantes existentes en
la base de datos, con total independencia de que éstos, se recuperen o no.
Si el resultado de esta fórmula arroja como valor 1, se tendrá la exhaustividad
máxima posible, y esto viene a indicar que se ha encontrado todo documento
relevante que residía en la base de datos, por lo tanto no se tendrá ni ruido,
ni silencio informativo: siendo la recuperación de documentos entendida como
perfecta. Por el contrario en el caso que el valor de la exhaustividad sea igual
a cero, se tiene que los documentos obtenidos no poseen relevancia alguna.
Fórmula

|{ 𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠=15 } ∩ {𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠=11 }|

𝑒𝑥ℎ𝑢𝑠𝑡𝑖𝑣𝑖𝑑𝑎𝑑 =
|{ 𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠=11 }| =1

5
 Métricas de Calidad Mis Tareas

1.1.3. Eficiencia De La Eliminación De Defectos (EDD)

Descripción
Es una métrica que permite medir la habilidad de filtrar las actividades de la
garantía de calidad y de control, ya que es aplicable a todas las actividades
del marco de trabajo del proceso.
El valor ideal de EED es 1. Esto quiere decir que no han encontrado defectos
en el software.
Variables Descripción
EDD Eficiencia de la eliminación de defectos
EDDi Eficiencia de la eliminación de defectos i
Numero de errores (fallas detectadas antes de la entrega del
E
sistema al usuario por primera vez)
Numero de defectos (fallas detectadas después de entregado el
D
sistema al usuario por primera vez)
Ei Numero de errores encontrados durante la actividad i del proceso
Ei+1 Numero de errores encontrados durante la actividad i+1
Fórmula

𝐸=3
𝐸𝐸𝐷 =
(𝐸=3 + 𝐷=1)
EED=0.75
Descripción
También se pueden medir aquellos errores que no se encuentran durante la
revisión del modelo del análisis pasaran al diseño (donde se pueden o no
encontrar)
Fórmula

𝐸𝑖=1
𝐸𝐸𝐷𝑖 =
(𝐸𝑖=1 + 𝐸𝑖=1 + 1)
EEDI=0.33

1.1.4. Mejora De Eliminación De Defectos

Descripción
La mejora en la eliminación de defectos mide la efectividad de varios métodos
de eliminación de defectos.
Ofrece la razón de defectos eliminados por versión liberada.
Variables Descripción

6
 Métricas de Calidad Mis Tareas

MED Mejora de eliminación de defectos

7
 Métricas de Calidad Mis Tareas

TA Tiempo que se toma en arreglar defectos del producto

TD Tiempo que se demora en desarrollar el producto
Fórmula

0.2
𝑀𝐸𝐷 =
4
MED=0.05

1.1.5. Mejora En La Productividad

Descripción
Estudia la exactitud de la estimación de esfuerzo comparada con la
estimación real
Variables Descripción
MP Mejora en la productividad
TED Tiempo empleado desarrollando el producto
TEE Tiempo empleado de esfuerzo en el producto
Fórmula

240
𝑀𝑃 =
200
MP=1.2

8
 Métricas de Calidad Mis Tareas

1.2. Métricas De Fiabilidad

Aquí se agrupan un conjunto de atributos que se refieren a la capacidad del

software de mantener su nivel de ejecución bajo condiciones normales en un
periodo de tiempo establecido. Las subcaracterísticas que el estándar sugiere
son:
• Nivel de Madurez: Permite medir la frecuencia de falla por errores en el
software.
• Tolerancia a fallas: Se refiere a la habilidad de mantener un nivel
específico de funcionamiento en caso de fallas del software o de cometer
infracciones de su interfaz específica.
• Recuperación: Se refiere a la capacidad de restablecer el nivel de
operación y recobrar los datos que hayan sido afectados directamente por
una falla, así como al tiempo y el esfuerzo necesarios para lograrlo.

1.2.1. Métricas Índice de Madurez del Software

Descripción
El estándar del IEEE 982.1-1988 sugiere un índice de madurez del software
(IMS) como métrica específica de mantenimiento. Esta métrica proporciona
una indicación de la estabilidad de un producto software. A medida que el
IMS se aproxima a 1, el producto comienza a estabilizarse, y por lo tanto,
menos esfuerzo de mantenimiento requerirá.
Variables Descripción
IMS Índice de Madurez del Software
Mt Número de módulos en la versión actual.
Número de módulos en la versión actual que han sido
Fm
modificados.
Fa Número de módulos en la versión actual que han sido añadidos
Número de módulos de la versión anterior que se han eliminado
Fe en la versión actual.
Fórmula

[𝑀𝑡=5 − (𝐹𝑎=1 + 𝐹𝑚=1 + 𝐹𝑒=0)]

𝐼𝑀𝑆 =
𝑀𝑡=5
IMS=0.6

9
 Métricas de Calidad Mis Tareas

1.2.2. Medidas De Fiabilidad y De Disponibilidad

Descripción
Los trabajos iniciales sobre fiabilidad buscaron extrapolar las matemáticas de
la teoría de fiabilidad del hardware a la predicción de la fiabilidad del software.
La mayoría de los modelos de fiabilidad relativos al hardware van más
orientados a los fallos debidos al desajuste, que a los fallos debidos a
defectos de diseño, ya que son más probables debido al desgaste físico (p.
ej.: el efecto de la temperatura, del deterioro, y los golpes) que los fallos
relativos al diseño.
Desgraciadamente, para el software lo que ocurre es lo contrario. De hecho,
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].
Variables Descripción
TMEF Tiempo medio entre fallos
TMDF Tiempo medido de fallo
TMDR Tiempo medido de reparación
Fórmula

𝑇𝑀𝐸𝐹 = 𝑇𝑀𝐷𝐹=8 + 𝑇𝑀𝐷𝑅=24

TMEF=32
Descripción

10
 Métricas de Calidad Mis Tareas

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. Como cada error de un
programa no tiene la misma tasa de fallo, la cuenta total de errores no es una
buena indicación de la fiabilidad de un sistema.

Muchos de los errores del programa pueden pasar desapercibidos durante

décadas antes de que se detecten. El TMEF de esos errores puede ser de 50
e incluso de 100 años. Otros errores, aunque no se hayan descubierto aún,
pueden tener una tasa de fallo de 18 ó 24 meses, incluso aunque se eliminen
todos los errores de la primera categoría (los que tienen un gran TMEF), el
impacto sobre la fiabilidad del software será muy escaso.
Además de una medida de la fiabilidad debemos obtener una medida de la
disponibilidad. La disponibilidad del software es la probabilidad de que un
programa funcione de acuerdo con los requisitos en un momento dado.

11
 Métricas de Calidad Mis Tareas

Fórmula

𝑇𝑀𝐷𝐹=8
=0.25=𝑑𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑖𝑙𝑖𝑑𝑎𝑑 =
(𝑇𝑀𝐷𝐹=8 + 𝑇𝑀𝐷𝑅=24) ∗ 100%

1.2.3. Medida De Amplitud o Cobertura De Las Pruebas

Descripción
Proporciona un indicador de cuantos requerimientos se han probado del
número total de ellos. Indica la complexión de plan de pruebas.
La cobertura de las pruebas indica cómo se van a cumpliendo los casos de
pruebas especificados, por lo tanto una mayor cobertura de las pruebas
indica un buen desarrollo de las pruebas
Variables Descripción
CP Valor de la cobertura de las pruebas
CPE Número de casos de pruebas que han sido ejecutados
Número de casos de pruebas a ejecutar requeridos para cubrir
CPR
todos los requerimientos
Fórmula

CPE =50
𝐶𝑃 =
CPR=13
CP=3.84

1.2.4. Profundidad De Las Pruebas

Descripción
Porcentaje de los caminos básicos independientes probados en relación al
total de ellos sumando la complejidad ciclomática de todos los módulos del
programa.
Si el valor de PCB no está cerca del 100%, entonces el número de pruebas
diseñadas no es suficiente para asegurar que se ejecutan todas las
sentencias del programa.
Variables Descripción
PBC Porcentaje de caminos básicos.
P Número de pruebas diseñadas.
V(G) Complejidad ciclomática calculada anteriormente.

12
 Métricas de Calidad Mis Tareas

Fórmula

13
 Métricas de Calidad Mis Tareas

𝑃=20
𝑃𝐵𝐶 = ∗ 100%
𝑣(𝐺)=3.84
PBC 52%

1.2.5. Madurez De Las Pruebas

Descripción
Indicador del buen desempeño del flujo de trabajo de pruebas, no sólo se
enfoca en la completitud de los casos de prueba según los definidos para
cubrir los requerimientos, sino que también comprende los casos de pruebas
que han obtenido resultados satisfactorios. Para obtener esta métrica es
preciso registrar los casos de prueba que obtuvieron resultados satisfactorios
y el total de los casos de prueba definidos para el cumplimiento de los
requerimientos.
El valor de esta métrica debe estar entre 0 y 1. Mientras mayor sea el número
de casos de prueba que han obtenido un resultado satisfactorio de los casos
realmente ejecutados y que se requieren para cubrir los requerimientos,
mayor será la madurez alcanzada por el equipo de probadores del software,
lo ideal es un valor tan cercano a 1 como sea posible.
Variables Descripción
MP Valor de la madurez de las pruebas.
Número de casos de prueba que han dado resultados
CPS
satisfactorios.
Número de casos de prueba diseñados para cubrir todos los
CPR
requerimientos.
Fórmula

𝐶𝑃𝑆=25
1=𝑀𝑃 = 𝐶𝑃𝑅=25

1.2.6. Perfiles De Fallos

Descripción

14
 Métricas de Calidad Mis Tareas

Se emplean para categorizar y priorizar los errores. La prioridad indica la

severidad del problema. Las categorías de fallos proporcionan una
descripción del error para realizar análisis estadísticos de errores. El
porcentaje de defectos por tipo permite categorizar los fallos porque identifica

15
 Métricas de Calidad Mis Tareas

los tipos de defectos más comunes que puedan presentarse en cualquier

etapa del desarrollo del software.
Variables Descripción
%DT Porcentaje de defectos por tipo.
NDT Es el número de defectos por tipo.
Número total de defectos identificados en una etapa del
TDI
proyecto.
Fórmula

𝑁𝐷𝑇=0
%𝐷𝑇 = ( ) ∗ 100
𝑇𝐷𝐼=0
%DT=0%
Observación
El valor del %DT indica la frecuencia de aparición del error analizado, por
tanto mientras mayor sea su valor más frecuente será la aparición de ese error
específico.

1.2.7. Densidad De Defectos

Descripción
La densidad de defectos ofrece una medida sobre la proporción de defectos
con respecto a la cantidad de elementos de especificación. Esta métrica
permite realizar análisis estadísticos al finalizar las pruebas para valorar la
integridad y madurez del software analizado.
Variables Descripción
DD Densidad de defectos.
número total de defectos encontrados durante las
TD
pruebas
CER Número de elementos de especificación revisados.
Fórmula

𝑇𝐷=0
𝐷𝐷 =
𝐶𝐸𝑅 =20
DD=0
Observación
Es recomendable para una alta calidad del software que la densidad de
defectos tenga un valor mínimo.

16
 Métricas de Calidad Mis Tareas

1.2.8. Métrica Para El Control De Pruebas De Unidad

Descripción
Las pruebas de unidad son aquellas pruebas individuales, que se realizan
durante la implementación, en las cuales se prueban los componentes antes
de enviarlos para integrarlos, compilarlos, enlazarlos con uno o más
ejecutables y realizar las comprobaciones del sistema.
La métrica para el control de pruebas de unidad ofrece una medida de los
componentes que se han probado individualmente antes de la integración
con respecto al total de componentes que fueron implementados.
Variables Descripción
Valor de la métrica para el control de pruebas de
CPU
unidad.
Número de componentes probados individualmente
NCP
antes de integrarlos.
CImp Número de componentes implementados.
Fórmula

𝑁𝐶𝑃=5
𝐶𝑃𝑈 =
𝐶𝐼𝑚𝑝=5
CPU=1
Observación
Esta métrica ofrece valores entre 0 y 1. Si CPU = 1 significa que todos los
componentes implementados fueron probados individualmente antes de la
integración

1.2.9. Tasa De Propagación De Defectos

Descripción
La corrección de defectos en el software puede originar nuevos defectos,
este fenómeno es conocido como propagación de defectos. La tasa de
propagación de defectos indica el comportamiento de la propagación de
defectos en la realización de las pruebas.
Variables Descripción
TDP Tasa de programación de defectos
Dn Número de defectos ocasionados al corregir defectos anteriores.
Dc Número de defectos corregidos.
Fórmula

17
Métricas de Calidad Mis Tareas

18
 Métricas de Calidad Mis Tareas

1
𝑇𝐷𝑃 = 1 −
4
TDP=0.25
Observación
El valor de TPD ofrece mejores resultados cuando está más cerca de 1. Al
calcular esta métrica pueden obtenerse valores negativos, cuando el número
de defectos ocasionados al corregir defectos es mayor que el número de
defectos corregidos, en este caso dichos valores no se tendrán en cuenta al
trabajar con el resultado de la métrica, sino que se considerarán como cero.

19
 Métricas de Calidad Mis Tareas

1.3. Métricas De Usabilidad

Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario

que deberá invertir el usuario para utilizar el sistema Comprensibilidad. Se
refiere al esfuerzo requerido por los usuarios para reconocer la estructura lógica
del sistema y los conceptos relativos a la aplicación del software.
• Facilidad de Aprender: Establece atributos del software relativos al
esfuerzo que los usuarios deben hacer para aprender a usar la aplicación.
• Operabilidad: Agrupa los conceptos que evalúan la operación y el control
del sistema.

1.3.1. Métricas De Éxito

Descripción
La métrica más simple para medir la usabilidad es la medida del éxito, al lograr
una tarea específica: Registre el porcentaje de usuarios de la prueba capaces
de lograr lo que se pidió. Es una métrica fácil de recolectar y constituye una
estadística reveladora.
Variables Descripción
TTF Total tareas finalizadas
TM Total tareas medias
T Total tareas
Fórmula

𝑇𝑇𝐹=27 + ( 𝑇𝑀=5 ∗ 0.5)

exito = ( ∗ 100)
𝑇𝑇=27
ÉXITO= 109%

1.4. Métricas De Eficiencia

Esta característica permite evaluar la relación entre el nivel de funcionamiento

del software y la cantidad de recursos usados. Los aspectos a evaluar son:
• Comportamiento con respecto al Tiempo: Atributos del software relativos
a los tiempos de respuesta y de procesamiento de los datos.
• Comportamiento con respecto a Recursos: Atributos del software
relativos a la cantidad de recursos usados y la duración de su uso en la
realización de sus funciones.
20
 Métricas de Calidad Mis Tareas

1.4.1. Eficiencia En La Productividad

Descripción
Estudia el tiempo que se puede tardar un grupo de trabajo desarrollar un
producto que ya está listo para salir a producción
Variables Descripción
ED Esfuerzo en desarrollo
EE Esfuerzo estimado
ER Esfuerzo real
Fórmula

𝐸𝐷=240 – 𝐸𝐸=200
productividad = ( ∗ 100)
𝐸𝑅=180
PRODUCTIVIDAD =22,2 %

1.5. Métricas De Mantenibilidad

Se refiere a los atributos que permiten medir el esfuerzo necesario para realizar
modificaciones al software, ya sea por la corrección de errores o por el
incremento de funcionalidad. En este caso, se tienen los siguientes factores:

• Capacidad de análisis: Relativo al esfuerzo necesario para diagnosticar

las deficiencias o causas de fallas, o para identificar las partes que deberán
ser modificadas.
• Capacidad de modificación: Mide el esfuerzo necesario para modificar
aspectos del software, remover fallas o adaptar el software para que
funcione en un ambiente diferente.
• Estabilidad: Permite evaluar los riesgos de efectos inesperados debidos a
las modificaciones realizadas al software.
• Facilidad de Prueba: Se refiere al esfuerzo necesario para validar el
software una vez que fue modificado.

1.5.1. Técnica Del Índice De Mantenibilidad

Descripción

21
 Métricas de Calidad Mis Tareas

El Índice de Mantenibilidad (IM) mide la facilidad de mantenimiento del

producto considerado.
Toda acción de mantenimiento puede dividirse en 3 tareas:

22
 Métricas de Calidad Mis Tareas

• Comprensión de los cambios que deben hacerse

• Realización de las modificaciones necesarias
• Pruebas de los cambios realizados
Cuanto mayor sea el IM, mayor mantenibilidad tendrá el sistema.
Variables Descripción
IM Índice de mantenibilidad
aveV Medida del volumen V
aveLOC Media del número de líneas de código por modulo
perCM Medida porcentual de líneas de código comentadas
Fórmula

IM = 171 − 5.2 ∗ ln (aveV=10) − 0.23 ∗ aveV=10 (g′) − 16.2 ∗ ln

(aveLOC=120) + 50 ∗ sin (sqrt (2.4 ∗ perCM=10))
IM=-68.48

1.6. Métricas De Portabilidad

En este caso, se refiere a la habilidad del software de ser transferido de un

ambiente a otro, y considera los siguientes aspectos:

• Adaptabilidad: Evalúa la oportunidad para adaptar el software a

diferentes ambientes sin necesidad de aplicarle modificaciones.
• Facilidad de Instalación: Es el esfuerzo necesario para instalar el
software en un ambiente determinado.
• Conformidad: Permite evaluar si el software se adhiere a estándares o
convenciones relativas a portabilidad.
• Capacidad de reemplazo: Se refiere a la oportunidad y el esfuerzo usado
en sustituir el software por otro producto con funciones similares.

1.6.1. Comportamiento De La Portabilidad

Descripción
Que tan conforme es la transporabilidad del producto con regulaciones,
estándares y convenciones aplicables.
Contar los artículos encontrados que requieren conformidad y comprar con el
¿número de artículos en la especificación que requieren conformidad
Variables Descripción
X Portabilidad
A Numero de articulo implementados de conformidad
23
 Métricas de Calidad Mis Tareas

B Total de artículos que requieren conformidad

24
 Métricas de Calidad

Fórmula

15
𝑋=
12
X=1.25

1.7. Métricas Orientadas Al Tamaño

Descripción
Estás métricas asignadas como cuantitativas, se derivan después de que se
ha generado el código o se estima una vez que el diseño esté completo. Un
programa está compuesto de tokens, las instrucciones del lenguaje, los
identificadores, constantes, operadores delimitadores de comentario y
signos especiales del mismo. De esta forma se obtiene una medida más
realista de la cantidad de información contenida en el código fuente.
Variables Descripción
Número de operadores diferentes que aparecen en el
n1
programa.
Número de operandos diferentes que aparecen en el
n2
programa.
N1 Número total de ocurrencias de operadores
N2 Número total de ocurrencias de operandos
• Los operadores son las palabras reservadas del
lenguaje, tales como (IF-THEN, READ, FOR,...;) los
operadores aritméticos (+, -, *,......) los de asignación
Aclaraciones: y los operadores lógicos (AND, EQUAL TO, ..... )
• Los operandos son las variables, literales y las
constantes del programa.
Fórmula de Longitud (N)

𝑁 = 𝑁1=8 + 𝑁2=12
N=20
• Es una simple medida del tamaño de un programa.
• Cuanto más grande sea el tamaño de N, mayor será
Observances:
la dificultad para comprender el programa y mayor el
esfuerzo para mantenerlo.
Fórmula de Volumen (V)

𝑉 =𝑁=20𝑥
L𝑜𝑔2(𝑛=5)
V=27.95

25
 Métricas de Calidad

Da un peso extra al número de operadores y operandos

únicos. Por ejemplo, si dos programas tienen la misma
longitud N pero uno tiene mayor número de operadores
Observaciones:
y operandos únicos, que naturalmente lo hacen más
difícil de entender y mantener, este tendrá un mayor
volumen.
Fórmula de Dificultad (D)

(𝑛1=3 ∗ 𝑁2=28)
𝐷=
(𝑛2=4 ∗ 2)
D=10.5
Fórmula de Esfuerzo (E)
Volumen mínimo

2 𝑛2=4
(𝐿): 𝐿 = ∗
𝑛1=3 𝑁2=28
L=0.09523

𝐸 = 𝐷=10.5 ∗ 𝑉=27.95
𝑉=27.95
𝐿=0.09523
E=0.999
El esfuerzo es otra medida estudiada por Halstead que
ofrece una medida del trabajo requerido para desarrollar
un programa. Desde el punto de vista del
Observaciones:
mantenimiento, el esfuerzo se puede interpretar como
una medida del trabajo requerido para comprender un
software ya desarrollado.

1.7.1. Métricas De Líneas De Código

Descripción
Proceden de la normalización de medidas de calidad y productividad
considerando el tamaño de la aplicación
Tabla de Lista

# # #
Proyecto LDC Esfuerzo Costo económico Documentos Errores Personas

Variables Descripción
Proyecto Nombre del proyecto a evaluar
LDC Líneas de código
Esfuerzo Días trabajados

26
 Métricas de Calidad

Costo económico Valor en pesos

# Documentos Número de páginas asociadas
# Errores Número de errores encontrados en ejecución
# Personas Número de personas en el proyecto
Fórmulas

𝐿𝐷𝐶=5000
Productividad
# 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠=1
=5000

# 𝑒𝑟𝑟𝑜𝑟𝑒𝑠=100
Calidad
𝐿𝐷𝐶=5000
0.02

𝑐𝑜𝑠𝑡𝑜
Costo 𝑒𝑐𝑜𝑛𝑜𝑚𝑖𝑐𝑜=105
00000
𝐿𝐷𝐶=5000
0.42

#
Documentación
𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠=5
𝐿𝐷𝐶 =5000
0.0010

1.8. Métricas De Complejidad

Son todas las métricas de software que definen de una u otra forma la medición
de la complejidad; Tales como volumen, tamaño, anidaciones, costo
(estimación), agregación, configuración, y flujo. Estas son los puntos críticos de
la concepción, viabilidad, análisis, y diseño de software.

1.8.1. Complejidad ciclomática de McCabe

Descripción
Dado el grafo de control de flujo (G) de cualquier programa, cada nodo
corresponde a un bloque de código secuencial y cada arco a una bifurcación
o punto de decisión en el programa.
Variables Descripción
V(G) Control de flujo
27
 Métricas de Calidad

a Número de aristas del grafo G

n Número de nodos del grafo G.

28
 Métricas de Calidad

Fórmula

𝑣(𝐺) = 𝑎=50 – 𝑛=25 + 2

V(G)=27
La complejidad ciclomática de un programa con múltiples salidas se define
como:
Variables Descripción
Número de declaraciones “return” o nodos terminados del
r
programa.
Fórmula

𝑣(𝐺) = 𝑎 − 𝑛 + 𝑝 + 𝑟
=50-25+30=55
Esta complejidad también puede calcularse como:
Fórmula
𝑣(𝐺) = 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑐𝑖𝑐𝑙𝑜𝑠 𝑐𝑒𝑟𝑟𝑎𝑑𝑜𝑠 + 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑢𝑛𝑡𝑜𝑠 𝑑𝑒 𝑠𝑎𝑙𝑖𝑑𝑎
V(G)=65+25=90
Observación
La complejidad ciclomática del software debe ser siempre menor que 10. El
valor de esta métrica es el límite superior del número de casos de prueba
necesarios para cubrir todas las bifurcaciones del programa y el límite inferior
del número de caminos básicos. Los módulos que tienen una mayor
complejidad tienden a ser los menos confiables en el programa.

1.8.2. Flujo De Información

Descripción
Permite valorar programas basados en datos y ofrece la ventaja de
calcularse antes de realizar la implementación. Aunque puede dar valores de
complejidad cero cuando el programa no tiene interacciones externas, lo cual
sería incorrecto porque la complejidad siempre es mayor que 1, por esta
razón es aconsejable combinar esta métrica con la de complejidad
ciclomática de McCabe y los puntos de función.
Variables Descripción
Número de flujos hacia un procedimiento + número de estructuras
𝑓𝑎𝑛𝑖𝑛 de datos globales de las cuales el procedimiento obtiene
información.
Número de flujos desde un procedimiento + número de
𝑓𝑎𝑛𝑜𝑢𝑡
estructuras de datos globales que el procedimiento actualiza.

29
 Métricas de Calidad

Fórmula

𝑐𝑜𝑚𝑝𝑙𝑒𝑗𝑖𝑑𝑎𝑑 = [𝑓𝑎𝑛𝑖𝑛?25 ∗ 𝑓𝑎𝑛𝑜𝑢𝑡=62]2

=148500000

Observación
Los módulos del programa que tienen un alto valor de 𝑓𝑎𝑛𝑖𝑛 son
relativamente pequeños y simples; al contrario de aquellos cuyo valor de
𝑓𝑎𝑛𝑖𝑛 es bajo que tienden a ser grandes y complejos.

1.9. Métricas De Calidad De Especificación

• Principal objetivo de los ingenieros de software es producir sistemas,

aplicaciones o productos de alta calidad.
• Para las evaluaciones que se quieran obtener es necesario la utilización de
medidas técnicas, que evalúan la calidad de manera objetiva.

Descripción
La finalidad de estas métricas es valorar la correcta especificación de los
requerimientos, que no haya ambigüedades en la interpretación y
comprensión, además que se pueda lograr una exactitud lo más alta
posible.
Aunque muchas de las características anteriores pueden ser de naturaleza
cuantitativa, se sugiere que todas puedan representarse usando una o
más métricas.
Variables Descripción
nr Número de requerimientos
nf Número de requisitos funcionales
nnf Número de requisitos no funcionales
Fórmula

𝒏𝒓 = 𝑛𝑓=18 + 𝑛𝑛𝑓=3
NR=21
Variables Descripción
Cuanto más cerca de uno este el valor de Q1 menor será la
Q1
ambigüedad de la especificación.
Número de requisitos para los que todos los revisores tuvieron
nui
interpretaciones idénticas
nr Número de requisitos
Fórmula

30
 Métricas de Calidad

𝑛𝑢𝑖
𝑄1 =
𝑛𝑟
Variables Descripción
Mide porcentaje de funciones necesarias que se han
Q2 especificado para un sistema, sin embargo, no trata los
requisitos no funcionales.
nu Número de requisitos de función únicos
Número de entradas (estímulos) definidos o implicados por la
ni
especificación
ns Número de estados especificados
Fórmula

𝑛𝑢=4
𝑄2 =
(𝑛𝑖=6 ∗ 𝑛𝑠=3)
Q2=0.22
Variables Descripción
Q3 Grado de validación de los requisitos
nc Número de requisitos que se han validados como correctos
nnv Número de requisitos que no se han validado todavía
Fórmula

𝑛𝑐=15
𝑄3 =
(𝑛𝑐=15 ∗ 𝑛𝑛𝑣=1)
Q3=1

1.9.1. Métricas de Integridad

Descripción
Para la medición de la integridad se tienen que definir dos atributos
adicionales: amenaza y seguridad.
Variables Descripción
Es la posibilidad que se logra evaluar o concluir de la evidencia
Amenaza empírica de un ataque de un tipo establecido ocurra en un
tiempo establecido
Es la probabilidad que se puede estimar o deducir de la
Seguridad evidencia empírica, de que se pueda repeler el ataque de un
tipo establecido, en donde la integridad del sistema.
Fórmula

𝑖𝑛𝑡𝑒𝑔𝑟𝑖𝑑𝑎𝑑 = 𝜎 [1 – 𝑎𝑚𝑒𝑛𝑎𝑧𝑎=48 ∗ (1 –
𝑠𝑒𝑔𝑢𝑟𝑖𝑑𝑎𝑑=24)]
INTEGRIDAD=105

31
 Métricas de Calidad

1.10. Métricas De Diseño De Alto Nivel

Descripción
Éstas se concentran en las características de la estructura del programa
dándole énfasis a la estructura arquitectónica y en la eficiencia de los
módulos.
Estas métricas son de caja negra, en el sentido de que no se requiere ningún
conocimiento del trabajo interno de ningún modo en particular del sistema.
Card y Glass [Pressman ’98] proponen tres medidas de complejidad del
software: complejidad estructural, complejidad de datos y complejidad del
sistema.
Variables Descripción
f out (i) Es la expansión del módulo i
Fórmula Complejidad Estructural

𝑆(𝑖) = 𝑓2 𝑜𝑢𝑡
= 7 (𝑖)
S(I)=7

Fórmula Complejidad De Datos

Proporciona una indicación de la complejidad en la interfaz interna de un
módulo
Variable Descripción
V(i) Número de variables de entrada y salida del módulo i.

𝑣(𝑖)=24
𝐷(𝑖) =
[𝑓𝑜𝑢𝑡(𝑖)=7 + 1]
D(I)=8.51
Fórmula Complejidad Del Sistema
Se define como la suma de las complejidades estructural y de datos

𝐶 (𝑖) = 𝑆(𝑖) + 𝐷(𝑖)

C(I)=15.51

1.11. Métricas Para Requerimientos

El objetivo del flujo de trabajo requerimientos es establecer y mantener un

acuerdo con los clientes acerca de lo que el software debe hacer.
Los requerimientos son condiciones o capacidades que debe alcanzar o poseer
un sistema o componente para satisfacer un contrato, estándar u otro
documento impuesto formalmente. Los requerimientos deben estar
correctamente estructurados, completos y deben ser fáciles de aplicar.

32
 Métricas de Calidad

1.11.1. Estabilidad De Los Requerimientos

Descripción
Es necesario lograr una estabilidad en los requerimientos para el correcto
funcionamiento de los demás flujos de trabajo. El objetivo de esta métrica es
medir la estabilidad de los requerimientos para asegurar su adecuación antes
de pasar al próximo flujo de trabajo. Se considera que los requerimientos son
estables cuando no existen adiciones o supresiones en ellos que impliquen
modificaciones en las funcionalidades principales de la aplicación.
Variables Descripción
ETR Valor de la estabilidad de los requerimientos.
RT Total de requerimientos definidos.
Número de requerimientos modificados, que se obtienen como
RM la sumatoria de los requerimientos insertados, modificados y
eliminados.
Fórmula

𝑅𝑇=28 – 𝑅𝑀=2
𝐸𝑇𝑅 = [ ] ∗ 100
𝑅𝑇=28
ETR=200
Observación
Esta métrica ofrece valores entre 0 y 100. El mejor valor de ETR es el más
cercano a 100 porque mostrará que no se están realizando cambios sobre los
requerimientos, son estables y por tanto es confiable trabajar el análisis y
diseño sobre ellos.

1.11.2. Especificidad De Los Requerimientos

Descripción
La comprensibilidad de los requerimientos depende en gran medida de la
ausencia de ambigüedades en su especificación, facilitando los procesos de
captura y procesamiento de requerimientos. El objetivo de esta métrica es
cuantificar la especificidad o falta de ambigüedad en la definición de los
requerimientos. Para calcular esta métrica deben contarse los
requerimientos que tuvieron igual interpretación por los revisores y
compararlos con el total de requerimientos definidos.
Variables Descripción
ER grado de especificidad de los requerimientos

33
 Métricas de Calidad

Número de requerimientos para los que todos los revisores

𝒆𝒖𝒊
tuvieron interpretaciones idénticas.
Cantidad de requerimientos en una especificación y comprende
𝒏𝒓
la suma de los requisitos funcionales y no funcionales.
Fórmula

𝑒𝑢𝑖=28
𝐸𝑅 =
𝑛𝑟=28
ER=1

Observaciones
El valor de esta métrica debe estar siempre entre 0 y 1. Mientras más cerca
de 1 esté el valor de ER mayor será la consistencia de la interpretación de los
revisores para cada requerimiento y menor será la ambigüedad en la
especificación de los requerimientos.

1.11.3. Grado De Validación De Los Requerimientos

Descripción
Los requerimientos deben ser posibles de validar. La validación de los
requerimientos se realiza en consenso del equipo de desarrollo al contrastar
lo que desea el cliente con la posibilidad real de implementarlo. El grado de
validación de los requerimientos mide la corrección en la definición de los
requerimientos
Variables Descripción
VR Grado de validación de los requerimientos.
𝒏𝒄 Número de requerimientos que se han validado como correctos.
𝒏𝒏𝒗 Número de requisitos no validados aún.
Fórmula

𝑛𝑐=28
𝑉𝑅 =
(𝑛𝑐=28 + 𝑛𝑛𝑣=0)
VR=1
Observaciones
El resultado de esta métrica está siempre entre 0 y 1. El valor óptimo de esta
métrica es el más cercano a 1 e indica un alto nivel de corrección en la
definición de los requerimientos.

34
 Métricas de Calidad

2. BIBLIOGRAFIA

➢ https://www.youtube.com/watch?v=kh7tIcXOB1E
➢ https://www.youtube.com/watch?v=F-cQpgp5Ics
➢ http://vinculando.org/articulos/sociedad_america_latina/propuesta_guia_de_
medidas_para_evaluacion_sistemas_informacion.html
➢ Norma ISO/IEC 9126
➢ https://es.wikipedia.org/wiki/Precisión_y_exhaustividad
➢ https://es.slideshare.net/sophialara123/metricas-de-software-16491149

35