Está en la página 1de 34

Capítulo 4

Métricas del Producto para el SW

Una estructura para las métricas técnicas


del software

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 1
Metricas del Producto para el Software
_________________________________________________________

Aunque no son absolutas, proporcionan una manera


sistematica para evaluar la calidad a partir de un
conjunto de reglas.

Permiten al ingeniero, descubrir y corregir


problemas potenciales antes que se conviertan en
defectos catastróficos.

Mediciones para evaluar la calidad del


producto mientras se diseña o construye.

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 2
Calidad General
_________________________________________________________

Todos los desarrolladores estamos de acuerdo con que


es importante crear Software de ALTA CALIDAD.

Pero a que llamamos calidad?


“es el cumplimiento de los requisitos de funcionalidad y
desempeño explicitamente establecidos, de los
estándares de desarrollo explicitamente documentados
y de las características implicitas que se esperan de
todo software desarrollado profesionalmente”
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 3
Calidad General
_________________________________________________________
Podemos extraer tres ideas importantes:

1. Los requisitos de Sw.son la base de las


medidas de calidad. La falta de concordancia
con los mismos es falta de calidad.
2. Los STD especificados definen un conjunto
de criterios de desarrollo. Si no se siguen los
criterios el resultado será la falta de calidad.
3. Si el Sw.cumple objetivos explicitos pero no
los implicitos, esta en duda la calidad. Ej.
Deseo de alcanzar la facilidad de uso.
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 4
El Triángulo de Calidad de McCall
_________________________________________________________
• Mantenibilidad • Portabilidad
• Flexibilidad • Reusabilidad
• Pruebabilidad • Interoperabilidad
REVISIÓN DEL TRANSICIÓN DEL
PRODUCTO PRODUCTO
(Capac.Experimentar Cambios) (Capac. Adaptarse a Nuevos Entornos)

OPERACIÓN DEL PRODUCTO


(Características Operativas)
• Corrección
• Usabilidad
• Eficiencia
• Confiabilidad
• Integridad
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 5
Factores de Calidad de McCall
_________________________________________________________
REVISIÓN DEL

Facilidad de Mant.: esfuerzo para localizar/corregir un error


DEL PRODUCTO PRODUCTO

Flexibilidad: esfuerzo para modificar/cambiar un programa


Facilidad Prueba: esfuerzo de prueba para asegurar correccion
Portabilidad: esfuerzo para transferir de entorno Sw. o Hw.
TRANSICION

Facilidad Reutilizacion: uso en otras aplicaciones o funciones


Interoperabilidad: esfuerzo para acoplar un sistema con otro
Correccion: grado que el prog.cumple con su especificación
Confiabilidad: grado que se espera que desempeñe con precision
DEL PRODUCTO
OPERACION

Eficiencia: cantidad de codigo y recursos necesarios para que un


programa cumpla con su función.
Integridad: control de acceso a personas no autorizadas
Facilidad de Uso: esfuerzo para aprender, operar e interactuar
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 6
Un Comentario
_________________________________________________________

Los factores de calidad de McCall fueron


propuestos a inicios de los 70. Son válidos en el
presente como lo fueron en aquel tiempo. Es
probable que el software realizado conforme
estos factores mostrará una alta calidad aún en
el presente siglo, aún si aparecieran cambios
dramáticos en la tecnología.

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 7
Factores de Calidad del Std. ISO 9126
_________________________________________________________

Intento por identificar los atributos de calidad para el SW


 Funcionalidad: grado de cumplimiento de idoneidad,
exactitud, interoperabilidad, cumplimiento y seguridad.
 Confiabilidad: tiempo que el SW está disponible según
atributos de madurez, tolerancia a fallos y facilidad de
recuperación.
 Facilidad de Uso: comprension, aprendizaje y operabilidad
 Eficiencia: empleo optimo de recursos del sistema
 Facilidad Mant.: facilidad con que se repara el SW según
criterios de analisis, cambio, estabilidad, prueba
 Portabilidad: cambio de entorno de software según
criterios de adaptabilidad, facil de instalar, cumplimiento y
facilidad de reemplazo
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 8
Transición a un Concepto Cuantitativo
_________________________________________________________

Hasta ahora solo hemos analizado factores


CUALITATIVOS, en un intento de “medición” de la
calidad del Software. El esfuerzo por desarrollar
medidas precisas de la calidad del Sw en ocasiones
se frustra por la naturaleza subjetiva de la actividad.
Por ello, se deben aplicar evaluaciones
CUANTITATIVAS para medir la calidad del SW.

“Son medidas indirectas, pues nunca se mide realmente la calidad”

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 9
Medidas, Metricas e Indicadores
_________________________________________________________
 Medición: acto de determinar una medida.
 Medida: indicacion cuantitativa de la extension,
cantidad, dimension, capacidad o tamaño de
algún atributo, producto o proceso. Recopilación
de un solo tipo de datos. Ej. Nro.errores
descubiertos.
 Metrica: medida cuantitativa del grado en que un
sistema, componente o proceso posee un atributo
determinado. Relaciona de alguna manera las
medidas individuales. Ej. Nro.Promedio de errores
encontrados en cada revision o prueba de unidad.
 Indicador: metrica o combinacion de metricas que
proporcionan conocimientos acerca del proceso
de Sw., un proyecto o el propio producto.
Permiten al Jefe de Proyectos, ajustar el proceso
o el producto para que las cosas mejoren.
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 10
El Reto de las Metricas del Producto
_________________________________________________________
 En las últimas tres decadas, muchos investigadores han tratado de
desarrollar una sola metrica que proporcione una medida completa
de la complejidad del software;
 Aunque se han propuesto docenas de medidas de complejidad,
todas tienen conceptos diferentes sobre la complejidad y los
atributos de un sistema;
 Pero existe la necesidad de medir y controlar la complejidad del
software;
 Dado que es dificil derivar un solo valor de metricas de calidad,
debe considerarse la adopcion de medidas de diferentes atributos
internos del programa, los cuales serán utilizados como indicadores
independientes de la calidad de los modelos de analisis y diseño.
 El peligro de encontrar medidas que caractericen tantos atributos
diferentes es que inevitablemente las medidas deben satisfacer
objetivos que entran en conflicto entre sí, al variar sus espectativas
sobre el producto;
“La medicion es esencial si se desea alcanzar la calidad.”

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 11
Proceso de Medicion según Roche
_________________________________________________________

 Formulación: definición de metricas


adecuadas
 Recolección: mecanismo para acumular
datos a fin de derivar métricas
 Análisis: calculo de métricas y uso
herramientas matemáticas
 Interpretación: evaluación de las metricas
 Realimentación: recomendaciones
derivadas de la interpretación de
metricas
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 12
Principios de Formulación según Roche
_________________________________________________________

 Los objetivos de medición deberían establecerse antes que


comience la toma de datos;
 Cada métrica técnica debe ser definida de una manera que
no sea ambigua;
 Las métricas deberían estar derivadas basadas en una teoría
que sea válida para el dominio de la aplicación (por ej. Las
métricas para diseño deberían redactarse sobre principios y
conceptos básicos de diseño e intentar proveer una
indicación de la presencia de un atributo que es juzgado
como deseable);
 Las métricas deberían ser personalizadas para acomodarse
mejor a productos y procesos específicos [BAS84]

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 13
Principios de Recolección y Análisis s/ Roche
__________________________________________________________
 Cuando sea posible, la recolección de datos y el
análisis deberían ser automatizados
 Se deberían aplicar técnicas estadísticas válidas
para establecer las relaciones entre los atributos
del producto interno y las características
externas de calidad. Ej. hay relacion entre el
nivel de complejidad arquitectónico con el
numero
de defectos descubiertos en la produccion?
 Deberían establecerse guías interpretativas
y recomendaciones para cada métrica
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 14
Atributos Deseables de Metricas Efectivas SW
__________________________________________________________
 Simples y calculables. Debería ser relativamente fácil de aprender como
derivar una métrica, y su calculo no debería demandar un esfuerzo o tiempo
muy grandes
 Persuasivas empíricamente e intuitivamente. La métrica debería satisfacer las
nociones intuitivas de un ingeniero acerca del atributo del producto bajo
consideración. Ej. Valor aumenta cuando la cohesion en un modulo aumenta.
 Consistentes y objetivas. La métrica debería siempre producir resultados que
no sean ambiguos
 Consistentes en el uso de unidades y dimensiones. El calculo matematico de
la metrica debería emplear medidas sin conducir a combinac. raras de unid.
 Indep. del lenguaje de programación. Las métricas deberían estar basadas en
el modelo de análisis, o diseño, o en la estructura del programa mismo.
 Un mecanismo efectivo para la retroalimentación de la calidad. La métrica
debería proveer al ing. software, información que lo lleve a un prod. final de
mayor calidad

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 15
Tipos de Metricas
_________________________________________________________

 de Análisis;
 de Diseño;
 de Código Fuente
 para Pruebas
 del Mantenimiento

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 16
Métricas de Análisis
_________________________________________________________

Atienden varios aspectos del modelo


de análisis e incluyen:
 Funcionalidad Entregada: proporciona una
medida indirecta de la funcionalidad que se
empaqueta con el software.
 Tamaño del Sistema: mide el tamaño
general del sistema, definido desde el punto
de vista de la información disponible como
parte del modelo de análisis.
 Calidad de la Especificación: proporciona
una indicación de la especificidad o el grado
en que se ha completado la especificación
de los requisitos.

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 17
Métricas de Análisis
_________________________________________________________
Métricas Basadas en Puntos de Función: utilizan el punto de
función (PF) como un factor de normalización o como una medida
del “tamaño” de la especificación o del sistema a obtener.
El diagrama de flujo de datos se evalua para determinar las medidas
clave necesarias para calcular la metrica de punto de funcion (PF):
. Numero de entradas del usuario
. Numero de salidas al usuario
. Numero de consultas del usuario
. Numero de archivos lógicos internos
. Numero de archivos de interfaces externas
Cada valor se multiplica por el Factor de Ponderacion, segun el grado
de complejidad de cada caso. Luego se aplica la formula:
PF=cuenta total x (0,65 + 0,01 x ٤[Fi]) donde ٤[Fi] es un prod.simple o complejo
(s/14 preguntas o criterios de clasificación)
Basado en el valor del PF obtenido, el equipo de proyecto puede
estimar el tamaño global de implementacion de las funciones.
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 18
Métricas de Análisis
_________________________________________________________

 Métricas de Calidad de la Especificación: se


proponen una lista de caracteristicas con las
cuales puede evaluarse la calidad del modelo
de analisis y la corresp. especificacion de
requisitos, midiendo el número de req.por tipo:
Claridad, grado de avance, correccion,
facilidad de comprension, facilidad de
verificacion, consistencia interna y externa,
facilidad para evaluar objetivos, concision,
facilidad para dar seguimiento, facilidad para
modificarse, precision y facilidad de reutiliz.
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 19
Métricas para el Modelo de Diseño
_________________________________________________________

Cuantifican los atributos del diseño de manera


tal que permiten al Ing. Sw. evaluar su calidad:
 Métricas Arquitectónicas: proporcionan un
indicio de la calidad del diseño arquitectónico.
 Métricas al Nivel de Componente: miden la
complejidad de los componentes del Sw. y otras
características que impactan la calidad.
 Métricas de Diseño de la Interfaz: se concentran
principalmente en la facilidad de uso.
 Métricas Especializadas en Diseño O.O.: miden
características de las clases, además de las
correspondientes a comunicación y
colaboración.

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 20
Métricas para el Modelo de Diseño
_________________________________________________________

 Métricas de Diseño de Arquitectura:


 Complejidad Estructural = dependencia hacia afuera
del módulo (Numero de modulos llamados por el modulo)
 Complejidad de Datos = número de variables de
entrada y salida que se pasan al modulo o se reciben
de este. (Complejidad en la interfaz interna de un modulo)
 Complejidad del Sistema = Suma complejidades
Estructural y de Datos

 Métricas de Morfología: una función


del Nro. de módulos + Nro.de interfases
entre módulos; o Profundidad + Anchura.

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 21
Métricas de Diseño a Nivel de Componentes
_________________________________________________________

 Métricas de Cohesión: una función de objetos de datos y


el lugar de su definición. Relacion que existe entre los
elementos de un modulo. Intenta que el modelo haga una
sola cosa. Este valor se debe maximizar.
 Métricas de Acoplamiento: una función de parámetros de
entrada y salida, variables globales, y módulos llamados.
Se debe buscar que los modulos sean lo mas
independiente posible uno de otro. Este valor se debe
minimizar.
 Métricas de Complejidad: se intenta determinar la
complejidad del flujo de control del programa. Cientos han
sido propuestos (por ej. Complejidad ciclomática).

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 22
Métricas de Diseño de Interfase
_________________________________________________________

Disposición apropiada: proporciona una indicacion


de conveniencia de representacion de GUI. Una
función de entidades de disposición, la posición
geográfica y el “costo” de hacer transiciones entre
entidades.
(Si los datos exhibidos pertenecen a un solo objeto de datos, cohesión es ALTA –”mejor”
Si pertenecen a varios objetos de datos, cohesión es BAJA )

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 23
Métricas para Diseño OO
_________________________________________________________
Whitmire [WHI97] describe nueve caracteristicas distintivas y
mensurables de un diseño OO:
 Tamaño – se define a partir de los conceptos de poblacion,
volumen, longitud y funcionalidad
 Complejidad – la manera en que se interrelacionan las clases
 Acoplamiento – el numero de colaboraciones entre clases
 Suficiencia - grado en que la clase posee las caract.que debe
tener
 Grado de Avance – cuales propiedades se requieren para
representar plenamente el objeto dominio del problema
 Cohesion – modo en que todas las operaciones trabajan en
combinacion para alcanzar un solo proposito bien definido
 Primitivismo – grado en que una operacion es atomica
 Similitud – grado en que dos o mas clases son similares
 Volatilidad – mide la probabilidad de que ocurra un cambio

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 24
Métricas Orientadas a la Clase
_________________________________________________________
Propuestas por Chidamber y Kemerer (CK):
 Métodos Ponderados por Clase (MPC)
Contar Métodos (mantener BAJO, si aumenta, disminuye la posibilidad de reutilizacion)

 Arbol de Profundidad de Herencia (APH)


(mantener BAJO, a medida que crece, las clases de nivel inferior heredan muchos métodos)

 Número de Descendientes o hijos (NDD)


Solo nivel inmediato inferior (mantener BAJO, a medida que crece, aumentan las pruebas)

 Emparejamiento entre Clases de Objetos(AECO)


Colaboracion e/clases (mantener BAJO, si aumenta disminuye la posibilidad de reutiliz.)

 Respuesta Para una Clase (RPC)


Resp. a Msg.de otras clases (mantener BAJO, a medida que crece, aumentan las pruebas)

 Falta de Cohesión en los Métodos (FCM)


Varios métodos acceden a mismos atributos (mantener ALTO, equivale a Buen Diseño)

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 25
Métricas Orientadas a la Clase
_________________________________________________________
Propuestas Harrison, Counsell y Nithi [HAR98]:
 Metodo del Factor de Herencia (MFH)
(Impacto de la Herencia. Mantener ALTO)

 Factor de Acoplamiento (FA)


(Conexiones entre clases e instancias. Mantener BAJO)

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 26
Métricas Orientadas a la Clase
_________________________________________________________

Propuestas por Lorenz y Kidd [LOR94]:

 Tamaño de la Clase (TC) - Valor alto= Alta Responsab.


(Nro.Operaciones + Nro.Atributos. Mantener BAJO )

 Número de Operaciones Añadidas por


una Subclase (NOA)
(A mayor Nro.de Operaciones añadidas, mas se aparta de la abstracción de
SuperClase)

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 27
Métricas Orientadas a la Operación
_________________________________________________________

Propuestas por Lorenz y Kidd [LOR94]:

 Tamaño de Operación promedio (TO prom)


Nro.Mensajes que envia la operacion (Mantener BAJO )

 Complejidad de la Operación (CO)


Operacion debe limitarse a una sola responsabilidad (Mantener BAJO )

 Número promedio de parámetros por


operación (NPO prom)
Si sube, hay mayor acoplamiento (A mayor numero de parametros de operacion,
mayor colaboracion entre objetos, Mantener BAJO)

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 28
Métricas para el Código Fuente
_________________________________________________________

Miden el código fuente y se usan para evaluar


su complejidad, facilidad de mantenim., etc.:

 Métricas de Halstead: proporcionan medidas


únicas de un programa de cómputo, todas
basadas en el número (cuenta y ocurrencia).
 Métricas de Complejidad: miden la complejidad
lógica del código fuente.
 Métricas de Longitud: proporcionan un indicio
del tamaño del software.

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 29
Métricas para el Código Fuente
_________________________________________________________

 Ciencia del Software de


Halstead: una extensa colección
de métricas, todas predicadas en
el número (cuenta y ocurrencia)
de operadores y operandos dentro
de un componente o programa.
Ej. Longitud global del programa,
nivel del programa (medida de la
complejidad del Sw.), nivel del
lenguaje, esfuerzo de desarrollo,
tiempo de desarrollo y numero
esperado de fallos.
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 30
Métricas para Pruebas
_________________________________________________________
 El esfuerzo de las pruebas tambien se puede estimar
usando metricas obtenidas de medidas de Halsted. A
medida que se van haciendo pruebas, tres medidas
diferentes proporcionan una indicacion de la complecion
de las pruebas:
Amplitud de Pruebas: indicacion de cuantos requisitos
(del numero total de ellos) se han probado.
Profundidad de Pruebas: medida del pórcentaje de los
caminos basicos independientes probados en relacion al
numero total de estos caminos en el programa.
Perfiles de Fallos: a medida que se recogen los datos de
los errores, son utilizados para priorizar y categorizar los
mismos. Prioridad indica la severidad del problema. Las
categorias de los fallos proporcionan una descripcion de
un error, a fin de poder llevar a cabo analisis estadisticos
de errores.
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 31
Métricas para Pruebas OO
_________________________________________________________

Propuestas por Binder [BIN94]:


 Relacionadas al Encapsulamiento
 Falta de Cohesión en Métodos (FCM) (↓)
 Porcentaje Público y Protegido (PYP) (↓) % Atrib.Uso Publico

 Acceso Público a Datos (APD) (↓) #Metodo Accedido x Otro Atrib.

 Relacionadas a la herencia
 Número de Clases de Raíz (NCR) (↓) Cant.Raices (Ult.Nivel)
 Dependencias Hacia Dentro (FIN) (<1) Herencia Múltiple

 Número de Descendientes (NDD) y Arbol de


Profundidad de Herencia (APH) (↓)
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 32
Métricas del Mantenimiento
_________________________________________________________
Todas las metricas desarrolladas hasta ahora pueden ser
utilizadas para el desarrollo de nuevo software y para el
mantenimiento del existente. Adicionalmente se sugiere
un Indice de Madurez del Software (IMS), que
proporciona una indicacion de la estabilidad de un
producto software (basado en los cambios que ocurren
con cada version del producto).
IMS = [Mt – (Fa + Fc +Fd)] / Mt ... donde
Mt= numero de modulos de la version actual
Fa= numero de modulos añadidos en version actual
Fc= numero de modulos modificadós en version actual
Fd= numero de modulos de version anterior borrados
en version actual
“A medida que el IMS se aproxima a 1,0
el producto se empieza a estabilizar”
Facultad de Ciencias y Tecnología – Departamento de Informatica
Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 33
Bibliografía

PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico.


Sexta Edición
MC GRAW HILL. 2006. Capitulo 15.

Facultad de Ciencias y Tecnología – Departamento de Informatica


Material Elaborado por el Prof. Lic. Julio César Alsina Arevalos
Calidad del Software 34