Calidad E Learning Cap4

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 – Presentación de la Quinta Clase 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.

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”
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.
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
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
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.

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
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”

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.
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.”

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
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]

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
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

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

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.

_________________________________________________________
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.
_________________________________________________________
 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.
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.

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.
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).

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 )

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
represen- tar 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

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)

_________________________________________________________
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)

_________________________________________________________
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)

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)

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

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


Calidad E Learning Cap4

Cargado por

Información del documento

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

Calidad E Learning Cap4

Cargado por

Copyright:

Formatos disponibles

Capítulo 4

Métricas del Producto para el SW

Una estructura para las métricas técnicas

Facultad de Ciencias y Tecnología – Departamento de Informatica

Aunque no son absolutas, proporcionan una manera

Permiten al ingeniero, descubrir y corregir

Mediciones para evaluar la calidad del

Facultad de Ciencias y Tecnología – Departamento de Informatica

Todos los desarrolladores estamos de acuerdo con que

Pero a que llamamos calidad?

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

OPERACIÓN DEL PRODUCTO

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

Flexibilidad: esfuerzo para modificar/cambiar un programa

Facilidad Reutilizacion: uso en otras aplicaciones o funciones

Eficiencia: cantidad de codigo y recursos necesarios para que un

Los factores de calidad de McCall fueron

Facultad de Ciencias y Tecnología – Departamento de Informatica

Intento por identificar los atributos de calidad para el SW

Hasta ahora solo hemos analizado factores

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

Facultad de Ciencias y Tecnología – Departamento de Informatica

Facultad de Ciencias y Tecnología – Departamento de Informatica

 Formulación: definición de metricas

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

Facultad de Ciencias y Tecnología – Departamento de Informatica

Facultad de Ciencias y Tecnología – Departamento de Informatica

Facultad de Ciencias y Tecnología – Departamento de Informatica

Atienden varios aspectos del modelo

Facultad de Ciencias y Tecnología – Departamento de Informatica

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

Cuantifican los atributos del diseño de manera

Facultad de Ciencias y Tecnología – Departamento de Informatica

 Métricas de Diseño de Arquitectura:

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

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

Facultad de Ciencias y Tecnología – Departamento de Informatica

Disposición apropiada: proporciona una indicacion

Facultad de Ciencias y Tecnología – Departamento de Informatica

Facultad de Ciencias y Tecnología – Departamento de Informatica

 Arbol de Profundidad de Herencia (APH)

 Número de Descendientes o hijos (NDD)

 Emparejamiento entre Clases de Objetos(AECO)

 Respuesta Para una Clase (RPC)

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

Facultad de Ciencias y Tecnología – Departamento de Informatica

 Factor de Acoplamiento (FA)

Facultad de Ciencias y Tecnología – Departamento de Informatica

Propuestas por Lorenz y Kidd [LOR94]:

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

 Número de Operaciones Añadidas por

Facultad de Ciencias y Tecnología – Departamento de Informatica

Propuestas por Lorenz y Kidd [LOR94]:

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

 Complejidad de la Operación (CO)

 Número promedio de parámetros por

Facultad de Ciencias y Tecnología – Departamento de Informatica

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

Facultad de Ciencias y Tecnología – Departamento de Informatica

También podría gustarte