UNIVERSIDAD LIBRE
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
UNIDAD 4:
Métricas Técnicas del Software
Docente
PATTY PEDROZA BARRIOS
Ingeniería del Software IV
[Link]@[Link]
Estructura para las métricas
técnicas del Software
• Para conseguir dar valores cuantitativos a las métricas,
es necesario establecer un modelo de medición.
• Según Fenton
– A medida que crece el número de mediciones de distintos
atributos, se tiene que satisfacer objetivos incompatibles.
• Según Sari Pfleeger
– Lo mismo que las medidas de temperatura comienzan con
un índice de referencia y evolucionan por sofisticadas
escalas, herramientas y técnicas, las medidas del software
están evolucionando.
Estructura para las métricas
técnicas del Software
• Los principios básicos de la medición, sugeridos por
Roche, pueden caracterizarse mediante cinco actividades:
– Formulación. Obtención de medidas y métricas del software
apropiadas para la representación del software en cuestión.
– Colección. Mecanismo empleado para acumular datos
necesarios para obtener las métricas formuladas.
– Análisis. Cálculo de las métricas y la aplicación de
herramientas matemáticas.
– Interpretación. Evaluación de los resultados de las métricas
en un esfuerzo por conseguir una visión interna de la
calidad de la representación.
– Realimentación. Recomendaciones obtenidas de la
interpretación de métricas técnicas transmitidas al equipo
software.
Estructura para las métricas
técnicas del Software
• La experiencia indica que una métrica
técnica se usa únicamente si es intuitiva y
fácil de calcular. Si se requiere docenas
de contadores y se han de utilizar
complejos cálculos, la métrica no será
ampliamente utilizada.
MÉTRICAS TÉCNICAS DEL SOFTWARE
• Principios de medición:
– Ayudan a la evaluación de los modelos de análisis
y diseño
– Proporcionan una indicación de la complejidad de
los diseños procedimentales y del código fuente.
– Ayudan en el diseño de pruebas mas efectivas
MÉTRICAS TÉCNICAS DEL SOFTWARE
• Principios asociados con las métricas técnicas:
– Siempre que sea posible, la recogida de datos y su
análisis deben automatizarse
– Se deberían aplicar técnicas estadísticas válidas para
establecer las relaciones entre los atributos internos
del producto y las características externas de la calidad
– Se deberían establecer unas directrices de
interpretación y recomendaciones para todas las
métricas.
MÉTRICAS TÉCNICAS DEL SOFTWARE
• Principios asociados con las actividades de medición:
– Los objetivos de la medición deberán establecerse antes
de empezar la recogida de datos
– Todas las técnicas sobre métricas deberían definirse sin
ambigüedades
– Las métricas deberían obtenerse basándose en una teoría
válida para el dominio de aplicación
– Hay que hacer las métricas a medida para acomodar
mejor los productos y procesos específicos
Características fundamentales de las
métricas técnicas del Software
• Ejiogu define un conjunto de atributos que deberían
acompañar a las métricas efectivas del software. La
métrica obtenida y las medidas que conducen a ello
deberían ser:
• Simple y fácil de calcular.
– Deberían ser relativamente fácil aprender a obtener la
métrica y su cálculo no debería demandar un esfuerzo o
cantidad de tiempo inusuales
• Empírica e intuitivamente persuasiva.
– Satisfacer las nociones intuitivas del ingeniero sobre el
atributo del producto en cuestión.
Características fundamentales de las
métricas técnicas del Software
• Consistente y objetiva.
– Deberían siempre producir resultados sin ambigüedad. Un tercer
equipo debería ser capaz de obtener el mismo valor de métrica
usando la misma información del software.
• Consistente en el empleo de unidades y tamaños.
– El cálculo matemático de la métrica debería emplear medidas que
eviten extrañas combinaciones de unidades
• Independiente del lenguaje de programación.
– Deberían basarse en el modelo de análisis, de diseño o en la
estructura del programa
• Un eficaz mecanismo para la realimentación de calidad.
– Proporcionar al desarrollador de software información que le
lleve un producto final de mayor calidad
MÉTRICAS DEL MODELO DE 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
relacionadas.
10
MÉTRICAS BASADAS EN LA FUNCIÓN
• La métrica del punto de función (PF) se puede utilizar
como medio para predecir el tamaño de un sistema
obtenido a partir de un modelo de análisis.
• Para visualizar esta métrica se utiliza un diagrama de
flujo de datos, el cual se evaluar para determinar las
siguientes medidas clave que son necesarias para el
cálculo de la métrica de punto de función:
– Número de entradas del usuario
– Número de salidas del usuario
– Número de consultas del usuario
– Número de archivos
– Número de interfaces externas
11
MÉTRICAS BASADAS EN LA FUNCIÓN
• La cuenta total debe ajustarse utilizando la siguiente
ecuación:
• PF = cuenta-total x (0,65 + 0,01 x Fi)
• Donde cuenta-total es la suma de todas las entradas PF
obtenidas y Fi (i=1 a 14) son los "valores de ajuste de
complejidad".
12
MÉTRICAS BASADAS EN LA FUNCIÓN
• Para un ejemplo dado, se asume que la Fi es 46 (un producto
moderadamente complejo), por consiguiente:
PF = 50 x (0,65 + 0,01 x 46) = 56
Factor de ponderación
Parámetro de medición Cuenta Simple Media Compl.
Número de entradas del usuario 3 X 3 4 6 = 9
Número de salidas del usuario 2 X 4 5 7 = 8
Número de consultas del usuario 2 X 3 4 6 = 6
Número de archivos 1 X 7 10 15 = 7
Número de interfaces externas 4 X 5 7 10 = 20
Cuenta total 50
Cálculo de puntos de función
13
MÉTRICAS BASADAS EN LA FUNCIÓN
• Basándose en el valor previsto del PF obtenido del
modelo de análisis, el equipo del proyecto puede estimar
el tamaño global de implementación de las funciones de
interacción.
• Se puede asumir que los datos de los que se dispone
indican que un PF supone 60 líneas de código (se utilizará
un lenguaje orientado a objetos) y que en un esfuerzo de
un mes-persona se producen 12 PF.
• Estos datos históricos proporcionan al gestor del proyecto
una importante información de planificación basada en el
modelo de análisis en lugar de estimaciones preliminares
14
Otras Métricas para el Modelo de Análisis
• La Métrica Bang [De Marco]
– Puede aplicarse para desarrollar una indicación del tamaño
del software a implementar como consecuencia del
modelo del análisis.
• Métricas de la calidad de la especificación:
– Davis y colegas proponen una lista de características que
pueden emplearse para valorar la calidad del modelo de
análisis y la correspondiente especificación de requisitos
PARA INVESTIGAR
15
MÉTRICAS DEL MODELO DE DISEÑO
• La gran ironía de las métricas de diseño para el software es
que las mismas están disponibles, pero la gran mayoría de los
desarrolladores de software continúan sin saber que existen.
• No son perfectas y continúa el debate sobre su eficacia y
como deberían aplicarse.
• Algunos expertos señalan que es necesario mayor
experimentación hasta que se puedan emplear
adecuadamente. Sin embargo el diseño sin medición es una
alternativa inaceptable.
• Se dividen en
– Métricas de diseño arquitectónico o alto nivel
– Métricas de diseño a nivel de componente
16
MÉTRICAS DE DISEÑO DE ALTO NIVEL
• Se concentran en las características de la
arquitectura del programa , con énfasis en la
estructura arquitectónica y en la eficiencia de
los módulos.
• Estas métricas son de caja negra en el sentido
que no requieren ningún conocimiento del
trabajo interno de un módulo en particular del
sistema.
• Métricas propuestas por Card y Glass en 1990
17
Card y Glass definen las siguientes tres medidas
de complejidad
• La complejidad estructural, S(i), de un módulo
i se define de la siguiente manera:
S(i) = f2out(i).
• Donde fout(i) es la expansión del módulo i. La
expansión indica el número de módulos que
son invocados directamente por el módulo i.
18
Card y Glass definen las siguientes tres medidas de complejidad
• La complejidad de datos, D(i), proporciona una
indicación de la complejidad en la interfaz
interna de un módulo i y se define como:
D(i)=v(i)/[fout(i) + 1].
• Donde v(i) es el número de variables de
entrada y salida que entran y salen del módulo
i.
19
Card y Glass definen las siguientes tres medidas de complejidad
• La complejidad del sistema, C(i), se define como la suma
de las complejidades estructural y de datos :
C(i)= S(i) + D(i)
• A medida que crecen los valores de complejidad , la
complejidad arquitectónica o global del sistema también
aumenta. Esto lleva a una mayor probabilidad de que
aumente el esfuerzo necesario para la integración y las
pruebas.
20
Ejemplo
Ejemplo
Muchas Gracias
Recorderis: La comunicación entre docente y estudiantes es únicamente a través del
correo electrónico: [Link]@[Link]
Igualmente se reciben desde el correo institucional del estudiantes
nombre-apellido@[Link]
