MÉTRICAS DE SOFTWARE




Taller Métricas (Clase)

Nombre: Martha Alejandra Chacin Mora                         Código: 1151401
Nombre: Daniel José Caballero Sánchez                         Código:1151267

Se debe escoger 4 tipos de métricas que sirvan para el proyecto que estamos ejecutando.


1.-        Meyer sugiere en el mismo artículo cinco reglas básicas para la evaluación cuantitativa del software.

  1. La primera regla dice “Si recogemos o calculamos números debemos tener una intención específica relacionada con la compresión, el control o el mejoramiento del software y su producción”.

  1. La segunda regla plantea Las métricas internas y de producto deberían ser diseñadas para reflejar métricas externas tan exactamente como sea posible. Entiende las métricas externas como las que abarcan las propiedades visibles a los usuarios de los productos y las internas como las que abarcan las propiedades visibles sólo al grupo de los desarrolladores. El conjunto de métricas planteadas pretende describir la solidez del producto, o sea entender los fundamentos sobre los cuales se están tomando las mediciones internas y externas.

  1. La tercera regla dice que cualquier métrica aplicada a un producto o proyecto debe ser justificada por un teoría clara sobre la propiedad que la métrica tiene la intención de ayudar a estimar. Se busca una convergencia en ciertos criterios que se estiman esenciales, como ser contratos, herencia, polimorfismo, tipos. Las mediciones se hacen sobre tres productos desarrollados en Java. Se aplican las métricas al lenguaje Java. Para la medición se usa un programa desarrollado en Java.

  1. La cuarta regla dice que la mayoría de las métricas son comprensibles después de la calibración y comparación con resultados tempranos. Las métricas planteadas han sido probadas en tres casos de estudio, donde se ve la utilidad de contar con información histórica de mediciones para lograr una mayor comprensión de los resultados. Se realizan las mediciones en dos casos de estudio. En los casos de estudio se llega a percibir que el framework básico es útil para la caracterización de productos desarrollados en Java.

  1. La quinta regla afirma que los beneficios de un plan de métricas se apoyan en el proceso de medición tanto como en sus resultados. La definición de un plan de métricas está más allá del alcance de este trabajo, pero se comparte la observación del autor
.



2.-          Métricas de diseño en los componentes

Las métricas de diseño a nivel de componentes se concentran en las características internas de los componentes del software e incluyen medidas de las «3Cs» la cohesión, acoplamiento y complejidad del módulo. Estas tres medidas pueden ayudar al desarrollador de software a juzgar la calidad de un diseño a nivel de los componentes.




3. Métricas de acoplamiento


El acoplamiento de módulo proporciona una indicación de la conectividad» de un módulo con otros módulos, datos globales y el entorno exterior.

Dhama ha propuesto una métrica para el acoplamiento del módulo que combina el acoplamiento de flujo de datos y de control, acoplamiento global y acoplamiento de entorno. Las medidas necesarias para calcular el acoplamiento de módulo se definen en términos de cada uno de los tres tipos de acoplamiento apuntados anteriormente.

Para el acoplamiento de flujo de datos y de control:
di = número de parámetros de datos de entrada
ci = número de parámetros de control de entrada
do = número de parámetros de datos de salida
co = número de parámetros de control de salida

Para el acoplamiento global:
g, = número de variables globales usadas como datos
g, = número de variables globales usadas como control

Para el acoplamiento de entorno:
w = número de módulos llamados (expansión)
r = número de módulos que llaman al módulo en cuestión


4.- Métricas de mantenimiento

Se han propuesto métricas diseñadas explícitamente para actividades de mantenimiento. El estándar IEEE 982.1-1988 [Pressman ‘98] sugiere un índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un 101 producto de software (basada en los cambios que ocurren con cada versión del producto) Se determina la siguiente información:
                        Mr = número de módulos en la versión actual
Fc = número de módulos en la versión actual que se han cambiado
Fa = número de módulos en la versión actual que se han añadido
Fd = número de módulos de la versión anterior que se han borrado en la versión actual

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

IMS = [Mr – (Fa + Fc + Fd)]/ Mr

A medida que el IMS se aproxima a 1.0 el producto se empieza a estabilizar. El IMS puede emplearse también como métrica para la planificación de las actividades de mantenimiento del software. El tiempo medio para producir una versión de un producto software puede correlacionarse con el IMS desarrollándose modelos empíricos para el mantenimiento.

5.-        La métrica de punto de función PF

se usa para medir la funcionalidad que entrega un sistema , empleando datos históricos el PF se usa para estimar el costo o el esfuerzo requerido para diseñar codificar y probar el software Predecir el número de errores que se encontraran durante la prueba Pronosticar el número de componentes, de líneas de código proyectadas o ambas en el sistema implementado.





6.  Métricas de diseño de alto nivel

Éstas se concentran en las características de la estructura del programa dándole énfasis a la estructura arquitectónica y en la eficiencia de los módulos. 83 Estas métricas son de caja negra, en el sentido de que no se requiere ningún conocimiento del trabajo interno de ningún modo en particular del sistema.
Card y Glass [Pressman ’98] proponen tres medidas de complejidad del software: complejidad estructural, complejidad de datos y complejidad del sistema.
      La complejidad estructural. S(i), de un módulo i se define de la siguientes manera.

 S(i) = f2 out (i)

 Donde f out (i) es la expansión del módulo i.

     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] (4.13)

 Donde v(i) es el número de variables de entrada y salida del módulo i.

     La complejidad del sistema. C(i), se define como la suma de las complejidades estructural y de datos, y se define como:

C(i)=S(i)+D(i)


Comentarios