METRICAS PARA CADA FASE DE CICLO

DE VIDA DEL DESARROLLO DE

SISTEMAS
Ing. Vinicio Ramos Valencia
vi_ramos@espoch.edu.ec
0984421066
MÉTRICAS PARA ANÁLISIS
En esta fase es deseable que las métricas técnicas proporcionen una
visión interna a la calidad del modelo de análisis. Estas métricas examinan
el modelo de análisis con la intención de predecir el “tamaño” del sistema
resultante; es probable que el tamaño y la complejidad del diseño estén
directamente relacionados.
Entre las Métricas para el modelo de análisis tenemos:

 LA MÉTRICA BANG puede aplicarse para desarrollar una indicación

del tamaño del software a implementar como consecuencia del modelo
del análisis.
 MÉTRICAS PARA CALIDAD DE LA ESPECIFICACIÓN: En estas
métricas se emplea una lista de características que pueden emplearse
para valorar la calidad del modelo de análisis y la correspondiente
especificación de requerimientos: especificidad (falta de ambigüedad),
completitud, corrección, comprensibilidad, verificabilidad, consistencia
interna y externa, factibilidad, concisión, rastreabilidad, modificabilidad,
precisión y reusabilidad.
MÉTRICAS PARA ANÁLISIS (Cont…)

MÉTRICAS BASADAS EN LA FUNCIÓN

 La métrica de punto de función (PF) puede usarse de manera
efectiva como medio para medir la funcionalidad que entra a un
sistema. Esta métrica puede usarse para: 1) estimar el costo o
esfuerzo requerido para diseñar, codificar y probar el software;
2) predecir el número de errores que se encontrarán durante
las pruebas, y 3) prever el número de componentes y/o de
líneas fuente proyectadas en el sistema implementado.
MÉTRICAS PARA EL MODELO DE DISEÑO

En este se genera la definición de la arquitectura del sistema y del

entorno tecnológico que le va a dar soporte, junto con la especificación
detallada de los componentes del Sistema de Información.
 METRICAS DE ALTO NIVEL:
Las métricas de alto nivel nos ayudan a localizar los módulos más
complejos y, por lo tanto, aquellos en los que debemos poner especial
atención. También es utilizada para saber el número de módulos
asignados a cada trabajador.
 METRICAS DE BAJO NIVEL:
Las métricas de bajo nivel también llamadas métricas de caja
blanca son las que nos ayudan a conocer las interioridades del sistema.
Hay tres tipos de métricas de bajo nivel:
• De cohesión
• De acoplamiento
• De complejidad
MÉTRICAS PARA EL MODELO DE
DISEÑO (Cont…)
MÉTRICAS DEL DISEÑO ARQUITECTÓNICO.
 Se enfocan en características de la arquitectura del programa
con énfasis en la estructura arquitectónica y en la efectividad de
los módulos o componentes dentro de la arquitectura. Dichas
métricas son caja negra en tanto no requieren conocimiento
alguno del funcionamiento interior de un componente de software
particular.
 Card y Glass definen tres medidas de complejidad del diseño de
software: complejidad estructural, complejidad de datos y
complejidad del sistema.
MÉTRICAS PARA EL MODELO DE
DISEÑO (Cont…)

MÉTRICAS PARA DISEÑO ORIENTADO A OBJETOS

Whitmire describe nueve características distintas y mensurables de un diseño OO:

• Tamaño. El tamaño se define en función de población, volumen, longitud y funcionalidad.

• Complejidad. Whitmire ve la complejidad en términos de características estructurales al
examinar cómo se relacionan mutuamente las clases de un diseño OO.
• Acoplamiento. Las conexiones físicas entre elementos del diseño OO representan el
acoplamiento dentro de un sistema OO.
• Suficiencia. Whitmire define suficiencia como el grado en el que una abstracción posee las
características requeridas de él o en el que un componente de diseño posee
características en su abstracción, desde el punto de vista de la aplicación actual.
• Completitud. La única diferencia entre completitud y suficiencia es el conjunto de
características contra las cuales se compara la abstracción o el componente de diseño.
MÉTRICAS PARA EL MODELO DE DISEÑO
(Cont…)

• Cohesión. La cohesividad de una clase se determina al examinar

el grado en el que el conjunto de propiedades que posee es parte
del problema o dominio de diseño.
• Primitivismo. Una característica que es similar a la simplicidad, es
el grado en el que una operación es atómica, es decir, la operación
no puede construirse a partir de una secuencia de otras
operaciones contenidas dentro de una clase. Una clase que
muestra un grado de primitivismo encapsula sólo operaciones
primitivas.
• Similitud. El grado en el que dos o más clases son similares en
términos de su estructura, función, comportamiento o propósito se
indica mediante esta medida.
• Volatilidad. La volatilidad de un componente de diseño OO mide la
probabilidad de que ocurrirá un cambio.
 MÉTRICAS PARA EL MODELO DE
DISEÑO (Cont…)
MÉTRICAS ORIENTADAS A LA CLASE.
Las medidas y métricas para una clase individual, la jerarquía de clase y las
colaboraciones de clase serán invaluables cuando se requiera valorar la
calidad del diseño OO.
Chidamber y Kemerer propusieron uno de los conjuntos de métricas de
software OO, en ocasiones llamada suite de métricas CK que incluyen 6
métricas de diseño basadas en clase para sistemas OO:

1. Métodos ponderados por clase (MPC)

2. Profundidad del árbol de herencia (PAH)
3. Número de hijos (NDH)
4. Acoplamiento entre clases de objetos (ACO)
5. Respuesta para una clase (RPC)
6. Falta de cohesión en métodos (FCOM)
MÉTRICAS PARA CÓDIGO FUENTE

La teoría de Halstead de la ciencia del software, propuso las

primeras leyes analíticas para el software de computadora.
Utiliza un conjunto de medidas primitivas que pueden obtenerse
una vez que se han generado o estimado el código después de
completar el diseño. Las medidas son:
• n1: número de operadores diferentes que aparecen en el
programa.
• n2: número de operandos diferentes que aparecen en el
programa.
• N1: número total de veces que aparece el operador.
• N2: número total de veces que aparece el operando.
MÉTRICAS PARA PRUEBAS

La mayoría de las métricas para pruebas se concentran en el proceso de

prueba, no en las características técnicas de las pruebas mismas. En
general, los responsables de las pruebas deben fiarse en las métricas de
análisis, diseño y código para que sirvan de guía en el diseño y
ejecución de los casos de prueba.

El esfuerzo de las pruebas también se puede estimar utilizando métricas

obtenidas de las medidas de Halstead. Usando la definición del volumen
de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del
software puede calcularse como:
NP = 1/ [(n1/2) x (N2/n2)]
 n1: no de operadores diferentes
 n2: no de operandos diferentes
 N2: no total de Operandos
MÉTRICAS PARA MANTENIMIENTO.

IEEE Std. Sugiere un índice de madurez de software (IMS) que proporcione

un indicio de la estabilidad de un producto de software (con base en cambios que
ocurran para cada liberación del producto). Para ello, se determina la siguiente
información:
 MT= número de módulos en la liberación actual
 Fc= número de módulos en la liberación actual que cambiaron
 Fa = número de módulos en la liberación actual que se agregaron
 Fd = número de módulos de la liberación anterior que se borraron en la liberación
actual.

El índice de madurez del software se calcula de la forma siguiente:

 IMS = MT – (Fa + Fc+ Fd ) / MT

Conforme el IMS tiende a 1.0, el producto comienza a estabilizarse. El IMS también

puede usarse como una métrica para planificar actividades de mantenimiento de
software.
GRACIAS !!!