TEMA 17-..Metricas-Tecnicas-de-Software

5/13/2018 TEMA 17-..Metricas-Tecnicas-de-Software - slidepdf.com

http://slidepdf.com/reader/full/tema-17-metricas-tecnicas-de-software 1/18

Se aplica las métricas para valorar la calidadde los productos de ingeniería o los sistemas

que se construyen.

Proporcionan una manera sistemática de

valorar la calidad basándose en un conjunto dereglas claramente definidas.

Se aplican a todo el ciclo de vida permitiendo

descubrir y corregir problemas potenciales.

1

Métricas técnicas del software



Los requisitos del Software son la base de las medidasde calidad. La falta de concordancia con los requisitoses una falta de calidad.

Unos estándares específicos definen un conjunto decriterios de desarrollo que guían la manera en que sehace la ingeniería del Software. Si no se siguen loscriterios , habrá seguramente poca calidad.

Existe un conjunto de requisitos implícitos que ha

menudo no se nombran. Si el software cumple con susrequisitos explícitos pero falla en los implícitos , lacalidad del software no será fiable.

2

Calidad del Software



La medición del software se refiere a derivar a unvalor numérico para algún atributo de un productode software o un proceso de software.

Comparando estos valores entre ellos y con losestándares aplicados en la organización, esposible sacar conclusiones de la calidad delsoftware o de los procesos del software.

Sin embargo , aún es poco común la utilizaciónde medidas y métricas sistemáticas de software.La reticencia al uso es debido a que losbeneficios no son claros.

3



Por otra parte no existen estándares para lasmétricas y, por lo tanto existe ayuda limitada parala recolección y análisis de datos.

Las métricas son de control o de predicción:

Control: por lo general se asocian con losprocesos del software. Ejemplo, el esfuerzo y eltiempo promedio requerido para reparar los

defectos reportados. Predicción : se asocian con los productos del

software. Ejemplo, la complejidad ciclomática deun módulo, la longitud promedio de losindicadores en un programa y el número deatributos y operaciones asociadas con losobjetos de un diseño.

4



La medición asigna números o símbolos a atributos deentidades en el mundo real. Para conseguirlo es necesarioun modelo de medición que comprenda un conjuntoconsistente de reglas.

Existe la necesidad de medir y controlar la complejidad delsoftware, es bastante difícil obtener un solo valor pararepresentar una "métrica de calidad", sin embargo esposible desarrollar medidas de diferentes atributos internosdel programa como ser: modularidad efectiva,

independencia funcional y otros atributos. Estas métricas ymedidas obtenidas pueden utilizarse como indicadoresindependientes de la calidad de los modelos de análisis ydiseño.

5

Estructura para las métricas del Software



Los principios básicos de la medición, sugeridospor Roche, pueden caracterizarse mediante cinco

actividades: Formulación. Obtención de medidas y métricasdel software apropiadas para la representacióndel software en cuestión.

Colección. Mecanismo empleado para acumular

datos necesarios para obtener las métricasformuladas.

Análisis. Cálculo de las métricas y la aplicaciónde herramientas matemáticas.

Interpretación. Evaluación de los resultados delas métricas en un esfuerzo por conseguir unavisión interna de la calidad de la representación.

Realimentación. Recomendaciones obtenidasde la interpretación de métricas técnicas

transmitidas al equipo software.6



Ejiogu define un conjunto de atributos quedeberían acompañar a las métricas efectivas del

software. La métrica obtenida y las medidas queconducen a ello deberían ser:

Simple y fácil de calcular.

Empírica e intuitivamente persuasiva.

Consistente y objetiva.

Consistente en el empleo de unidades ytamaños.

Independiente del lenguaje de programación.

Un eficaz mecanismo para la realimentación decalidad.

7



La experiencia indica que una métrica

técnica se usa únicamente si es

intuitiva y fácil de calcular. Si serequiere docenas de contadores y se

han de utilizar complejos cálculos, la

métrica no será ampliamente utilizada.

8



A menudo es imposible medir los atributos decalidad del software en forma directa.

Los atributos como la complejidad , la mantenibilidad

y la comprensión se ven afectados por diversosfactores y no existen métricas directas para ellos.

Más bien es necesario medir un atributo interno delsoftware ( como el tamaño) y suponer que existeuna relación entre lo que se puede medir y lo que

se quiere saber. De forma ideal , existe una relación clara válidaentre los atributos de software internos y externos.

9

Métricas para predecir la calidad



Relación entre los atributos externos e

internos

Mantenibilidad

Fiabilidad

Portabilidad

Usabilidad

Número de parámetros

del procedimiento

Complejidad ciclomática

Tamaño del programa en

líneas de código

Número de mensajes deerror

Extensión del manual de

usuarioNo dice qué relación es



La Métrica Bang [De Marco]

Puede aplicarse para desarrollar una indicación del

tamaño del software a implementar comoconsecuencia 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 delmodelo de análisis y la correspondiente especificación

de requisitos

Métricas para el 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.

12



La gran ironía de las métricas de diseño para elsoftware 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 sinmedición es una alternativa inaceptable.

13

Métricas del modelo de Diseño



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.

14

Métricas de diseño de alto nivel



La mayoría de las métricas para pruebas se concentran enel proceso de prueba, no en las características técnicas de

las pruebas mismas. En general, los responsables de laspruebas deben fiarse en las métricas de análisis, diseño ycódigo para que sirvan de guía en el diseño y ejecución de

los casos de prueba. El esfuerzo de las pruebas también se puede estimar utilizando métricas obtenidas de las medidas de Halstead.Usando la definición del volumen de un programa, V, y nivelde programa, NP, el esfuerzo de la ciencia del software

puede calcularse como: NP = 1/[(n1/2) x (N2/n2)] (Ec. 9.1)

e = V/NP (Ec. 9.2)

15

Métricas para las Pruebas



El porcentaje del esfuerzo global de pruebas aasignar a un módulo k se puede estimar utilizandola siguiente relación:

Porcentaje de esfuerzo de pruebas(k) =

e(k)/§e(i) (Ec. 9.3) Donde e(k) se calcula para el módulo k utilizando

las ecuaciones (Ec. 9.1) y (Ec. 9.2), la suma en eldenominador de la ecuación (Ec. 9.3) es la suma

del esfuerzo de la ciencia del software a lo largode todos los módulos del sistema.

16



A medida que se van haciendo las pruebas, tres medidasdiferentes proporcionan una indicación de la compleción delas pruebas:

Medida de amplitud de las pruebas. Proporciona unaindicación de cuantos requisitos se han probado delnumero total de ellos. Indica la compleción del plan depruebas.

Profundidad de las pruebas. Medida del porcentaje de loscaminos básicos independientes probados con relación alnúmero total de estos caminos en el programa. Se puedecalcular una estimación razonablemente exacta delnúmero de caminos básicos sumando la complejidadciclomática de todos los módulos del programa.

Perfiles de fallos. Se emplean para dar prioridad ycategorizar los errores. La prioridad indica la severidaddel problema. Las categorías de los fallos proporcionanuna descripción de un error, de manera que se puedanllevar a cabo análisis estadístico de errores.

17



Todas las métricas descritas pueden utilizarse para eldesarrollo de nuevo software y para el mantenimiento del

existente.

El estándar IEEE 982.1-1988 sugiere el índice de madurezdel software (IMS) que proporciona una indicación de la

estabilidad de un producto software basada en los cambiosque ocurren con cada versión del producto. Con el IMS sedetermina la siguiente información:

MT= Número de módulos en la versión

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

Fe= Número de módulos en la versión actual que se haneliminado

18

Métricas del mantenimiento

Documents

TEMA 17-..Metricas-Tecnicas-de-Software