métricas - uniandesisis2701/dokuwiki/lib/exe… · mediciones del producto de software y el...
Post on 01-May-2020
11 Views
Preview:
TRANSCRIPT
1
�
Métricas
Juan Pablo Quiroga GonzálezDpto. de Ingeniería de Sistemas y ComputaciónUniversidad de los Andes - 2004
�
ReferenciasLibros� Humphrey, Watts. A discipline for
software Engineering. Addison-Wesley, 1995. Capítulo 7.
� Pressman, Roger. Software Engineering. A practitioner’s approach. McGrawHill. 2001. 5ta Edición. Cáps. 19 y 24
2
�
ReferenciasOtros � Software Metrics. Mill, Everald.
www.sei.cmu.edu/publications/documents/cms/cm.012.html
� Métricas de calidad de la NASA para Sistemas Orientado a Objetos.� http://satc.gsfc.nasa.gov/metrics/index.html� http://satc.gsfc.nasa.gov/support/index.html
�
Métricas - ¿Para qué sirven?� Obtener una comprensión cuantitativa
del proceso. � Evaluar un producto, un proceso o una
organización. � Controlar un producto o un proceso. � Producir un estimado o un plan. � Mejorar la productividad y la calidad del
software� Comprender la efectividad del proceso
3
�
Necesidad� El problema es la crisis del software
�Mejorar el plan de trabajo�Mejorar la estimación de los costos�Mejorar la calidad de los productos�Mejorar la productividad
� No hay forma de evaluar el proceso� Mejoramiento de la administración de
los proyectos se basa en lograr medir aspectos primordiales para el desarrollo.
�
Necesidad
� Lo importante de las métricas de software es la identificación y la medición de parámetros esenciales que afectan el desarrollo del software.
4
�
Definición
� Métricas de software trata de las mediciones del producto de software y el proceso mediante el cual son desarrollados.
�
Características de una buena métrica� Es simple y es definida precisamente� Objetiva� Fácilmente obtenible� Válida� Robusta� Además es importante que tenga una escala
de medición apropiada.� En especial se preocupa por evaluar la
funcionalidad y el presupuesto de un proyecto.
5
Escala de mediciones� Es importante determinar la escala y
para eso debe evaluar para qué se estámidiendo.
� Tipos de datos�Nominal ( Igual, diferente )
� Categorías� Ej. Categorías de los objetos
�Ordinal ( mayor o menor )� Rangos� Ej. Experiencia del programador (alta, baja,
media)
�
Escala de mediciones� Intervalo ( más o menos )
� Diferencias� Ej. Complejidad
�Radio ( Proporciones )� Cero absoluto� Ej. LOC
6
��
Clasificación de las medidas� Objetiva
�Cuenta o determina magnitudes numéricas�Ej. Líneas de código (Producto)� Tiempo de desarrollo (Proceso)
� Subjetiva � Implica un juicio humano�Ej. Clasificación de los objetos (Producto)
� Nivel de experiencia de un programador(Proceso)
��
Clasificación de las medidas� Absoluta
�Es independiente de las medidas de otros elementos en una muestra
�Ej. Tamaño de un programa
� Relativa �Es dependiente de las medidas de otros
elementos en una muestra�Ej. Tamaño promedio de las categorías de
objetos
7
��
Clasificación de las medidas� Explícita (Primitiva)
�Se toma directamente�Ej. LOC � Número de defectos en pruebas
� Derivada ( Calculada )�Se calcula a partir de otras medidas �Ej. LOC/Hora
� Porcentaje de tiempo por fase
��
Clasificación de las medidas� Dinámica
�Depende del tiempo y cambia con el transcurso de éste
�Ej. Rangos de predicción
� Estática�Una vez tomada permanece invariante�Ej. Tiempo de desarrollo
8
��
Clasificación de las medidas� Predictiva
�Puede obtenerse o generarse con anticipación al evento medido
�Ej. Tiempo estimados� Número de defectos estimados por fase
� Explicativa �Se calcula después de ocurrido el evento�Ej. Tiempo real� Número de defectos reales
��
Las métricas y el proceso definido� El proceso definido sirve como modelo
mental para entender el proceso y preguntarse sobre él.
� Igualmente ayuda a recolectar información útil sobre el proceso
� Al medir actividades complejas, conviene hacer una división de las mismas. Una definición inicial del proceso puede ayudar mucho.
� Ejemplo: pruebas
9
��
Métricas del proceso de software� Las métricas del proceso de software se
dividen en: �Métricas del producto �Métricas del proceso �Métricas de los recursos
��
Métricas de producto� Miden el tamaño o cantidad de un
producto que se produjo o se piensa producir�Desde los requerimientos�Hasta el sistema instalado
� Métricas del producto deben medir:�Complejidad del diseño del software�El tamaño del programa final�Número de páginas producidas por
documentación
10
�
Métricas de producto� Ejemplos:
�LOC �Páginas de documentación �Número de formularios diseñados
(interfaz)�Número de clases escritas �etc.
�
Métricas de producto� Pueden aplicarse a diversos tipos de
productos: �Módulos �Manuales �Componentes �etc.
� Pueden restringirse a fases específicas (i. e. LOC modificadas durante pruebas).
11
��
Métricas de productoimportantes� Tamaño
�Líneas de código� No se pueden medir antes directamente� Depende de la definición del estándar de
conteo (líneas físicas, líneas lógicas)
�Puntos de función� Medir con anterioridad el programa� No son medibles al final directamente
��
Métricas de productoimportantes� Tamaño
�Bang� Mide las funciones como indicativo del tamaño
del software� Algorítmos
�PROBE� Es medible bastante bien desde la fase de
diseño al utilizar programación orientada a objetos, aunque depende del Proxy.
12
��
Métricas de productoimportantes� Complejidad
�Ciclomática v(G) (Cyclomatic) McCabe� Flujo de control� Grafos
� V(G) = e – n + 2� E = número de límites� N = número de nodos
� Esta relacionado con el esfuerzo de programa, el desempeño de debug y el esfuerzo de mantenimiento.
��
Métricas de productoimportantes� Complejidad
�Extensiones de v(G) - Myers� Normalmente McCabe no diferencia
condiciones sencillas y complejas� V(G)´=v(g)[l,u]� L y u son los límites superior e inferior de
complejidad
�Extensiones de v(g) - Stetter� Añadir las declaraciones de datos y referencias
de datos
13
��
Métricas de productoimportantes� Complejidad
�Nodos� Describir el grafo del flujo de control de un
programa con un nodo por cada instrucción o un bloque de instrucciones secuenciales.
�Flujo de información� C = [longitud del procedimiento] *
� [fanin * fanout]^2
� Fanin = Información que entra� Fanout = información que sale
��
Métricas de productoimportantes� Halstead
�Medir varias cosas de un programa�Vocabulario del programa
� Medir los tokens diferentes
�Longitud del programa� Medir el número total de operadores y
operandos de un programa
�Volumen del programa� Tamaño que ocupa
14
��
Métricas de productoimportantes� Calidad
�Métricas de errores� Número de cambios de requerimientos� Número de cambios de diseño� Número de errores detectados en inspecciones� Número de errores detectados en pruebas� Número de cambios de código requeridos.
��
Métricas de productoimportantes� Calidad
�Métricas de confiabilidad� MTTF – Mean time to failure
�Métricas de mantenibilidad� Complejidad de las actividades de
mantenimiento v(g)
15
�
Métricas de proceso� Cuantifican el comportamiento del proceso. � Usualmente son objetivas, absolutas,
explícitas y dinámicas. � Son típicas las métricas que cuentan
eventos: � Número de defectos detectados en inspección � Número de requisitos modificados � Número de defectos de diseño detectados
durante las pruebas
�
Métricas de proceso� También son usuales las métricas
relativas al tiempo: �Tiempo total de desarrollo (tiempo de ciclo) �Porcentaje del tiempo total de desarrollo
dedicado a las pruebas �Tiempo promedio de corrección de un
defecto en pruebas
16
��
Métricas de recursos� Se refieren a los recursos utilizados en el
proyecto, usualmente tiempo de trabajo. � Es importante usar unidades adecuadas. En
medidas personales usualmente minutos. � Medir el tiempo en minutos puede parecer
excesivo, pero es sencillo: Una vez se hace las unidades son poco importantes.
� La información detallada puede ayudar a detectar y eliminar fuentes de distracción y otras causas de baja productividad
��
Métricas de recursos� Empíricas
� Wolverton – Indicar los recursos en una matriz de vida del producto
� Categorizan los elementos del software� Se compara con algo similar para indicar el costo.
� Modelos estadísticos� Medir el esfuerzo en personas por mes� E = a L^b, L=LOC� a y b se calculan haciendo una regresión con
información histórica
17
��
Métricas de recursos� Basadas en teoría
�Rayleigh Model� Medir el número de personas que debe existir
en un proyecto en cualquier momento
�Modelo de Halstead� Medir el tiempo requerido para desarrollar un
programa basado en discriminaciones mentales elementarias (basadas en el vocabulario) y el código requerido
��
Métricas de recursos� Modelos compuestos
�COCOMO – Boehm� Mide el esfuerzo para medir el costo del
programa� Depende de la forma de desarrollo (orgánica,
semisuelta y embebida) y del nivel del modelo (básico, intermedio y detallado)
� Se miden atributos de costo
18
��
Métricas de recursos� Modelos compuestos
�SOFTCOST – Tausworthe� Incluye factores de calidad� Depende de un conjunto de preguntas
�SPQR – Jones� Software Productivity, Quality and Reliability� Factores bien definidos y no definidos que
miran los tres aspectos anteriores
��
Métricas de recursos� Modelos compuestos
�COPMO - Thebaut� Contar esfuerzo adicional requerido cuando se
desarrolla en equipo� Número de personas que hay durante la vida
del proyecto
19
��
Métricas de recursos� Modelos compuestos
�ESTIMACS – Robin� Estimador del esfuerzo de desarrollo del
sistema� Estimador del costo y staff� Estimador de configuración de hardware� Estimador de riesgos� Analizador de portafolio ( Incluir información de
otros proyectos )
��
El paradigma Objetivo-Pregunta-Métrica (OPM)� Desarrollado por Basili para guiar los
esfuerzos de medición. � Consiste en:
� Definir los objetivos principales (con respecto a recolección de datos) en la actividad que se va a realizar.
� Construir un conjunto de preguntas que ayude a alcanzar dichos objetivos.
� Definir y recolectar la información necesaria para responder dichas preguntas.
20
�
OPM aplicado al PSP� Objetivos fundamentales:
�Entender como funciona el proceso personal de desarrollo de software.
�Determinar los pasos que podrían tomarse para mejorar la calidad de los productos.
�Determinar el impacto de los cambios del proceso en la productividad.
�Establecer mecanismos para evaluar el mejoramiento del proceso.
�Facilitar la producción de planes más precisos.
�
OPM aplicado al PSP� Preguntas de apoyo:
�¿Cuáles aspectos de mi desempeño son importantes?
�¿Cómo pueden medirse dichos aspectos? �¿Cuál es el mejor desempeño que he
alcanzado? �¿Qué puedo aprender de dicho logro? �¿Qué han alcanzado otras personas? �¿Cuáles métodos de otras personas
podrían ayudarme?
21
��
Recolección de datos� La recolección de información es una
actividad fundamental para el análisis y mejoramiento del proceso de software.
� Típicamente, la recolección se hace manualmente: �El computador no puede saber que
estamos haciendo. �La información de defectos no se puede
obtener del análisis automático del código
��
Recolección de datos
�Es difícil saber determinar de manera automática la fase del proceso en que se originó un defecto
�La información recolectada manualmente puede, sin embargo, tratarse con herramientas automatizadas.
22
��
Formularios� Los formularios pueden resultar muy útiles
para desarrollar planes y estimados. � También son útiles como depósitos de
información. � En algunos casos los formularios cerrados
son mejores, en otros sirven más los formularios abiertos y expansibles.
� Al diseñar formularios, conviene probarlos primero. Esto puede hacerse con datos de proyectos anteriores.
��
Otras herramientas� La base de datos de errores
�Mantiene un registro de los errores detectados y corregidos en los diversos proyectos a lo largo del tiempo.
� La hoja de cálculo �Permite adelantar muchos de los cálculos
y conteos propios del PSP de manera automática.
23
��
Otras herramientas� El cuaderno de ingeniería
�Permite documentar las decisiones de trabajo y esbozar soluciones de problemas. Sirve como vehículo de documentación para el análisis posterior.
��
Posibles problemas con la medición del proceso� La recolección de datos es compleja y
demanda tiempo y esfuerzo. � Si no se tiene una clara motivación,
fácilmente puede convertirse en una labor tediosa.
� Aunque el PSP define en primera instancia el proceso, es importante entenderlo y determinar el valor personal de la información recolectada.
24
��
Posibles problemas con la medición del proceso� La información personal debe
analizarse con objetividad. El no hacerlo puede traer consecuencias negativas.
� El compartir la información personal requiere cuidado y prudencia. Una vez más el actuar descuidadamente pueden causar problemas.
��
Métricas para sistemas orientado a objetos� Características
�Localización� Característica del software que indica la
manera en que la información estáconcentrada en el programa
�Encapsulamiento� El empaquetamiento de una colección de
items.
25
�
Métricas para sistemas orientado a objetos� Características
�Ocultamiento de información� Suprimir los detalles operacionales de un
componente de un programa
�Herencia� El mecanismo que permite que las
responsabilidades de un objeto puedan ser propagadas a otros objetos
�
Métricas para sistemas orientado a objetos� Características
�Abstracción� Mecanismo que permite a los diseñadores
enfocarse en los detalles esenciales de un componente del programa con un poco conocimiento de los detalles de bajo nivel.
26
��
Métricas OO – Orientada a clases� Suite de Métricas CK
�Creada por S.R. Chidamber y C.F. Kemereren 1.991
�Revisada por Basili en 1.996
��
Métricas OO – Orientada a clases – Suite de métricas CK� WMC - Pesado de métodos por clase *
�WMC – Weighted methods per class�WMC = SUM( ci )�Donde ci es la complejidad del método i�Puede ser la complejidad ciclomática�La complejidad está relacionado con el
esfuerzo requerido para implementar y probar una clase.
27
��
Métricas OO – Orientada a clases – Suite de métricas CK� DIT – Profundidad del árbol de herencia
� DIT – Depth of the inheritance tree� Máxima longitud de un nodo del árbol a la raíz de
este.� Indica dificultades potenciales cuando se intenta
predecir el comporamiento de una clase.� Un DIT alto implica una alta complejidad del
diseño� También indica un alto nivel de reutilización
��
Métricas OO – Orientada a clases – Suite de métricas CK� NOC - Número de hijos
�NOC – Number of children�Las subclases que estan inmediatamente
subordinadas a una clase se denominan hijas
�Un alto NOC aumenta el esfuerzo para realizar las pruebas también aumenta
28
��
Métricas OO – Orientada a clases – Suite de métricas CK� CBO - Acoplamiento entre objetos de la
clase *�CBO - Coupling between object classes�Número de clases directamente
relacionadas para lograr responder a un servicio (cualquier tipo de asociación)
�Altos valores de CBO complican las modificaciones y las pruebas
�Normalmente CBO debe mantenerse bajo
��
Métricas OO – Orientada a clases – Suite de métricas CK� RFC – Respuesta de una clase *
� RFC – Response for a class� Es el conjunto de métodos que potencialmente se
ejecutan en respuesta de un mensaje recibido por un objeto de esa clase
� Se suman los métodos públicos de la clase más los métodos que son llamados dentro del código interno de la clase
� Aumenta la dificultad de las pruebas� Aumenta la complejidad del diseño
29
��
Métricas OO – Orientada a clases – Suite de métricas CK� LCOM – Falta de cohesión de los
métodos�LCOM – Lack of cohesion in methods�Cuando un método de una clases accede
a uno o más atributos de la clase.�LCOM es el número de métodos que
acceden uno o más atributos iguales.� Por ej. El analizador y el modificador por
atributo, si hay cuatro atributos, el LCOM mínimo sería de 8
�LCOM muy altos indican fallas en el diseño
��
Métricas OO – Orientada a clases – Otras suites� Lorenz y Kidd
�Class size – CS�Number of operatiosn overriden by a
subclass – NOO�Number of operations added by a subclass
– NOA�Specialization Index – SI
� SI = ( NOO x level ) / Mtotal� Mtotal número de métodos totales de la clase
30
�
Métricas OO – Orientada a clases – Otras suites� MOOD
�Metrics for Object-oriented design�Harrison, Counsell y Nithi�Method inheritance factor – MIF�Coupling Factor – CF�Polymorphism factor - PF
�
Métricas OO – Orientada a operaciones� Propuesta por Lorenz y Kidd 1994� Tamaño promedio de una operación
�Osavg Average operation size�Líneas de código de cada método�También se puede contar por el número de
mensajes asociados al método�Si es muy alto puede indica que las
responsabilidades no están bien dadas y hay que hacer subdivisión de ellas
31
��
Métricas OO – Orientada a operaciones� OC - Complejidad de la operación
�OC – Operation complexity�Utilizando para medir la complejidad
ciclomática�Se debe mantener baja
��
Métricas OO – Orientada a operaciones� NPavg -Número promedio de
parámetros por operación�Npavg – average number of parameters
per operation�Aumenta la complejidad de colaboración
entre objetos�Más complejas las pruebas�Se debe mantener bajo
32
��
Métricas OO – Pruebas� Encapsulamiento
�LCOM - Lack of cohesion in methods�PAP - Percent public and protected�PAD – Public access to data members
� Herencia�NOR – Number of root classes�FIN – Fan in , múltiple herencia�NOC – Number of children�DIT – Depth of the inheritance tree
��
Métricas OO – Proyecto� Creadas por Lorenz y Kidd 1994� Número de casos de uso o escenarios
�NSS – Number of scenario scripts�La cantidad de casos de uso es
proporcional al número de clases requeridas para cumplir los requerimientos
�Es un indicador fuerte del tamaño del programa
33
��
Métricas OO – Proyecto� Número de clases llave *
�NKC – Number of key classes�Clases que directamente están
relacionadas con la lógica del negocio�Altos valores de NKC indican un trabajo
substancial de desarrollo�Se espera que entre el 20 y el 40% de las
clases sean de este estilo, las demás corresponden a interfaz, comunicaciones, bases de datos, etc.
��
Métricas OO – Proyecto� NSUB - Número de subsistemas
�NSUB – Number of subsystems�Provee una buena forma de saber :
� Las necesidad de recursos� Planeación ( desarrollo paralelo )� Esfuerzo de integración
34
��
Métricas OO – Proyecto� Otras métricas utilizadas relacionadas
con la productividad�Número de clases promedio por
desarrollador�Número promedio de métodos por mes-
persona� Otra forma de estimar el esfuerzo, duracción,
necesidades de personal
��
Metrics� Basado en dos conjuntos de métricas� Object Oriented Metrics, measures of
complexity. Brian Henderson. PrenticesHall. 1996
� OO Design Quality Metrics. An Analysisof Dependencies. Robert Martin. �Agile Software Development, Principles,
Patterns and Practices
35
�
Metrics
�
Metrics� Number of classes
� Cantidad de clases� Problemas:
� Difícil de mantener� Bajo desempeño
36
��
Metrics� Number of children
� Número de subclases de una clase� Problemas:
� Difícil de mantener dado que un cambio en una clase padre afecta las hijas
��
Metrics� Number of interfaces
�Número de interfaces�Problemas:
� Muy poco indica mucho acoplamiento entre las clases aunque es una medida un poco subjetiva
37
��
Metrics� Depth of inheritance tree (DIT)
� Profundidad del árbol de herencia� Problemas:
� Grande implica poca mantenibilidad� Difícil de probar
��
Metrics� Number of Overriden Methods (NORM)
� Número de métodos redefinidos de una clase ancestro
� Problemas:� Difícil de probar� Difícil de mantener� Fallas en el diseño
38
��
Metrics� Number of Methods (NOM)
�Número de métodos de una clase�Problemas:
� Difícil de mantener� Fallas en el diseño, demasiadas
responsabilidades
��
Metrics� Number of attributes
� Número de atributos de una clase� Problemas:
� Fallas en el diseño, demasiadas responsabilidades
39
��
Metrics� LOC
�Líneas de código� Total / Promedio / Desviación Estándar� Por clase / Por Método
�Problemas:� Entre más grande más difícil de mantener� Fallas en el diseño� Problemas de cohesión en el método y en la
clase
��
Metrics� Specialization Index (SI)
� NORM*DIT/NOM� Problemas:
� Entre más grande más difícil de mantener� Difícil de probar
40
�
Metrics� McCabe Cyclomatic Complexity
� Realiza un conteo del número de posibles camino en un método ( ver el código como un grafo)
� Por cada opción posible se suma uno ( if,switch, ?, for, while, &&, || )
� Problemas:� Entre más grande más difícil de mantener� Muy difícil de probar
�
Metrics� Weighted methods per class (WMC)
� Suma de la complejidad de McCabe para todos los métodos de una clase.
� Problemas:� Entre más grande más difícil de mantener� Muy difícil de probar
41
��
Metrics� Lack of cohesion of methods (LCOM)
� Es el número promedio de métodos que acceden a cada uno de los atributos de la clase, menos el número de métodos de la clase diividido por 1-m
� En java el uso de get y set puedo aumentarlo aunque realmente no es importante por lo que metrics no los tiene en cuenta.
� Problemas:� Cercano a 1 indica una clase poco cohesiva que debe
ser divida en varias otras clases
��
Metrics
� Afferent Coupling (Ca)�Número de clases fuera del paquete que
dependen de clases dentro del paquete�Problemas:
� Alto acoplamiento
42
��
Metrics
� Efferent Coupling (Ce)�Número de clases del paquete que dependen
de clases de fuera del paquete�Problemas:
� Alto acoplamiento
��
Metrics
� Instability (I)�Ce/(Ca+Ce)�Problemas:
� Alto acoplamiento
43
��
Metrics� Abstractness (A)
� Número de clases abstractas e interfaces divido por el número total de tipos (incluyendo clases concretas) en un paquete
� Problemas:� Dificil de probar
��
Metrics
� Normalized distance from main sequence(Dn)� |A+I-1|, debe ser cercano a 0 para un buen
diseño de paquete�Problemas:
� Mal diseño del paquete
44
��
Metrics� Number of static methods
� Número de métodos de clase� Problemas
� Problemas en el diseño al combinarse con métodos de instancia
��
Metrics� Number of static attributes
�Número de atributos de clase�Problemas
� Problemas en el diseño al combinarse con atributos de instancia
� Es realmente una clase?
45
�
Metrics� Number of parámetros
� Número de parámetros de un método� Sensible al cambio, es mejor el uso de un objeto
que contenga los parámetros� Problemas
� Más casos para probar el método
Metrics� Nested block depth
� Cantidad de bloques en un método� Partir el método en otros métodos privados� Problemas
� Demasiada complejidad por lo tanto difícil de mantener
top related