Médición del Software - us

1

MEDICIÓN DEL SOFTWARE

2

MEDICIÓN DEL SOFTWARE

1. Introducción

2. Conceptos básicos

3. Alcance de las métricas

4. Clasificación de las métricas

Procesos

Productos

Recursos

5. Clasificación de los atributos

6. Medición de atributos internos del producto

Longitud

Funcionalidad

Puntos de caso de uso

Código OO

Modelos conceptuales OO

7. Medición de atributos de los recursos

8. Resumen de las métricas

9. GQM

10. Caso práctico

3

1. Introducción: El informe CHAOS (1)

•Éxito: Proyectos terminados dentro del plazo y presupuesto. •Problemas: Proyectos terminados pero sin cumplir plazos o presupuesto. •Cancelados: Proyectos suspendidos durante el desarrollo.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

31%40%

28% 23% 19%

53% 33%46%

49%46%

16%27% 26% 28%

35%

Éxito

Problemas

Cancelados

4


Hay un porcentaje de proyectos de desarrollo muy alto que fracasan no por falta de presupuesto o tecnología sino por falta de gestión.

0%

10%

20%

30%

40%

50%

60%

CHAOS'94 CHAOS'96 CHAOS'98 CHAOS'00 CHAOS'06

Cancelados

Problemas

Éxito

5


http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf

6


Métrica

Evaluación del grado en el cual un producto o proceso posee un atributo determinado (extensión, cantidad, dimensiones, capacidad o tamaño) (IEEE, 1993).

Medición

Proceso objetivo y empírico por el que se asignan números o símbolos a atributos de entidades del mundo real con objeto de describirlas (Fenton y Kitchenham, 1991)

Métrica directa e indirecta

Una métrica es directa si se puede medir directamente del atributo y su valor no depende de la medida de otros atributos (longitud del código fuente, duración del proceso de prueba, número de defectos...). Una métrica es indirecta si comprende la medición de varios atributos, es decir, si deriva de otros atributos (productividad, estabilidad de requisitos, densidad de defectos en un módulo, etc.) (Wohlin et al. 2000).

Métrica objetiva y subjetiva

Una métrica es objetiva si su valor no depende del observador y es subjetiva en caso contrario.

7


La medición contribuye a superar algunos problemas habituales en el desarrollo del software:

Problema Medir ayuda a

Requisitos incorrectos

Desarrollar requisitos verificables expresados en términos medibles.

Toma de decisiones

Proporciona evidencia cuantificable para apoyar las decisiones.

Falta de control

Hacer más visible el desarrollo e identificar problemas anticipadamente.

Exceso de gasto

Realizar predicciones de coste y plazo justificables.

Costes de mantenimiento

Recomendar determinadas estrategias de prueba e identificar los módulos problemáticos.

Evaluación de nuevos métodos

Valorar los efectos en la productividad y la calidad .

8


La posibilidad de medir es el fundamento de las disciplinas científicas y de ingeniería.

Sin poder medir es muy difícil evaluar y experimentar las técnicas y los métodos de ingeniería del software.

No se puede controlar lo que no se puede medir y no se puede predecir lo que no se puede medir.

Objetivos del proceso de medición:

Gestión durante el proceso de Ingeniería del Software, más concretamente:

Predicción: estimación de los atributos que tendrá una entidad que no existe aún (coste de un proyecto, esfuerzo necesario).

Evaluación: comprobación del cumplimiento de ciertas características por una entidad que ya existe (calidad del diseño, fiabilidad del software, etc.).

Experimentación en Ingeniería del Software.

9


FORMULACIÓN

COLECCIÓN

ANÁLISIS

INTERPRETACIÓN

REALIMENTACIÓN

Definición de medidas y métricas

Obtención de datos

Cálculo de métricas

Evaluación de los resultados

Recomendaciones obtenidas

Proceso de medición de Roche

10


Las métricas del software abarcan muchas actividades y son múltiples las razones que justifican su uso :

Estimación de coste y esfuerzo (o al menos reducción de estos)

Modelos y medidas de productividad

Recolección de datos

Modelos y evaluación de la calidad (AENOR, ISO, etc.)

Modelos de fiabilidad

Están incluidos en la mayoría de los modelos de calidad.

La especialización de los modelos de fiabilidad permite aumentar el entendimiento y control de los productos.

Evaluación del rendimiento (Puede ser cualitativo)

Aunque es otro aspecto de la calidad, la valoración del rendimiento incluye características observables como tiempos de respuesta y características internas como eficiencia de los algoritmos.

Métricas estructurales y de complejidad

Para realizar predicciones sobre atributos de calidad (fiabilidad, facilidad de mantenimiento,...) se pueden medir atributos estructurales sobre representaciones del software que están disponibles antes que el código.

Gestión mediante métricas

La realización de gráficos basados en diferentes medidas a lo largo del proyecto permite conocer el estado del mismo.

Evaluación y comparación de métodos y herramientas

Las investigaciones cuidadosas, con análisis y mediciones controladas sobre una herramienta o método permiten hacerlos más productivos para situaciones particulares.

11

1. ¿En cuánto podría ser mejorada la productividad si no tuviese que gastar tiempo en mantenimiento?

2. ¿Cuánto tiempo le costó el último año adaptar su presupuesto en trabajar con nuevas versiones de compiladores, bases de datos o sistemas operativos?

3. ¿Cuáles de las aplicaciones que desarrolla su empresa demanda el mayor tiempo de soporte al usuario?

4. ¿Cuánto tiempo se gasta realmente en testing?

5. ¿Crée que sus desarrolladores dedican suficiente tiempo a actividades de diseño?

6. ¿Su proceso de desarrollo ha madurado en los últimos años?

7. ¿El esfuerzo dedicado a mejorar la calidad del software está reduciendo el tiempo que se dedica a corregir errores ?

8. ¿Con qué precisión es usted capaz de estimar proyectos futuros?

9. ¿En cuántos proyectos han trabajado cada uno de sus desarrolladores en el último año?

10. ¿Cuál es el número medio de horas por semana que sus desarrolladores dedican a un proyecto?


Fuente: Karl E. Wiegers, Process Impact, www.processimpact.com

12

4. Clasificación de las métricas

El primer paso de la medición es identificar los atributos o entidades a medir. Estos pueden ser de tres tipos:

Productos: componentes, entregas o documentos resultantes de una actividad de proceso.

Procesos: atributos de actividades relacionadas con el software.

Recursos: entidades requeridas por una actividad de proceso

Dentro de cada clase anterior se puede distinguir:

Atributos internos: Son aquellos que pueden ser medidos examinando el proceso, producto o recurso mismo.

Atributos externos: se miden con respecto a como el proceso, producto o recurso se relaciona con su entorno.

13

5. Clasificación de atributos

Atributos internos del producto:

Medidas de tamaño (longitud del código, funcionalidad...)

Medidas de diseño Acoplamiento: grado de interdependencia entre módulos

Cohesión: grado en el los componentes locales de un módulo colaboran para realizar una tarea concreta

Modularidad

.................

Medidas de complejidad (estructuras de datos, estructura lógica...)

...

Atributos externos, que dependen del comportamiento del producto en un entorno determinado:

Portabilidad

Fiabilidad

Usabilidad

Facilidad de mantenimiento

Escalabilidad

14

5. Clasificación de atributos

Generalmente, el interés de conocer el valor de un atributo interno es que pueda dar información sobre algún atributo externo de interés para el observador.

Atributos internos del producto

Atributos externos

influyen en

Ejemplo: el número de requisitos de una especificación de requisitos de sistema puede ayudarnos a predecir el esfuerzo asociado al proyecto.

15

6. Medición de atributos internos del producto

Los atributos internos describen los productos de software de forma que dependen únicamente del producto mismo.

El producto puede ser descrito en función de su tamaño. Se pueden definir un conjunto de atributos para medir el tamaño del software:

Longitud: tamaño físico del producto.

Funcionalidad: funciones que proporciona el producto al usuario.

Complejidad (de tiempo o espacio): recursos necesarios (de tiempo o memoria de ordenador) para implementar una solución particular.

Las propiedades estructurales del software son atributos internos relacionados con la calidad del producto. Los tipos de medidas estructurales son:

Flujo de control: secuencia en que se ejecutan las instrucciones.

Flujo de datos: seguimiento de cómo los datos se crean y se manejan por un programa.

Estructura de los datos: organización de los datos independiente del programa.

Los principales productos que resulta útil medir son la especificación, el diseño y el código.

16

6. Medición de atributos internos del producto:

Longitud

Código

El numero de líneas de código (LOC) es la medida más usada para medir la longitud del código fuente.

Se han realizado muchas propuestas para contarlas. La más extendida es la de HP que no contabiliza las líneas comentadas ni en blanco. La abreviatura que se usa para estas líneas es NCLOC o ELOC (effective lines of code).

Es útil medir por separado las líneas comentadas (CLOC) para calcular esfuerzo, productividad, etc. La longitud total será:

LOC = NCLOC + CLOC

También puede se útil calcular la densidad de comentarios:

CLOC/LOC

Para propósitos tales como la prueba es importante conocer cuanto código ejecutable se produce, para ello se mide el número de sentencias ejecutables (ES), ignorando los comentarios, declaraciones de datos y cabeceras.

Otra propuesta consiste en contabilizar únicamente el código entregado al cliente. Se cuenta el número de DSI (delivered source instruction) que incluye las declaraciones de datos, las cabeceras y las instrucciones fuente.

17


funcionalidad

Puntos de función (PF) Medida de la funcionalidad propuesta por Albrecht. Es una

medida del producto y del proceso que se sigue para desarrollarlo. Está centrado en la “funcionalidad” o “utilidad” del producto.

Los PF se obtienen utilizando una relación empírica basada en items del producto y valoraciones subjetivas de la complejidad del mismo.

El paso previo al cálculo de los PF, es el cálculo de PFS (unadjusted function point count), puntos de función sin ajustar: Se determinan los siguientes elementos de alguna

representación del software: Entradas externas: entradas de usuario que

proporcionan datos a la aplicación. Salidas externas: Salidas que proporcionan

información al usuario. Consultas externas: peticiones interactivas que

requieren una respuesta. Ficheros externos: interfaces con otros

sistemas legibles por la máquina. Ficheros internos: ficheros maestros lógicos del

sistema. A cada elemento se le asigna un índice de

complejidad entre tres: simple, media o complejo. A cada índice le corresponde un factor de ponderación.

18


funcionalidad

Factor de peso

Item Simple Medio Complejo

Entradas externas 3 4 6

Salidas externas 4 5 7

Consultas externas 3 4 6

Ficheros externos 7 10 15

Ficheros internos 5 7 10

15 PFS = ((número de items de la clase i) pesoi) i=1

Para completar el cálculo de los PF es necesario conocer el factor de complejidad técnica (FCT) que engloba los 14 factores.

Componentes del factor de complejidad técnica F1 Copias de seguridad y

recuperación fiables

F6 Entrada interactiva de

datos F11 Reusabilidad

F2 Comunicación de datos F7 Facilidad operativa F12 Facilidad de instalación

F3 Funciones distribuidas F8 Actualización interactiva F13 Múltiples sitios

F4 Rendimiento F9 Interfaces complejas F14 Facilidad de cambios

F5 Configuración muy

cargada F10 Procesamiento complejo

Items y factores de peso para calcular los PFS

19


funcionalidad

Cada componente de la tabla anterior se sitúa en una escala entre 0 y 5 según su influencia:

Ninguna influencia 0

Incidental 1

Moderado 2

Medio 3

Significativo 4

Esencial 5

La siguiente fórmula combina los 14 factores:

14

FCT = 0.65 + 0.01 Fi i=1

Los valores constantes de la ecuación y los factores de

ponderación se obtienen empíricamente.

Cálculo final de los puntos de función:

PF= PFS* FCT

La técnica de puntos de función presenta problemas debido a

la subjetividad de la aplicación de los factores y a la

inexactitud de las medidas.

¿Puntos de función o líneas de código?

Existen factores de conversión (Albrecht/Jones) que permiten relacionar el número medio de LOC requerido para construir un PF en diferentes lenguajes.

20


funcionalidad

Lenguaje de Programación LOC/PF

Ensamblador 320 C 128 COBOL 106 FORTRAN 106 Pascal 90 C++ 64 Ada95 53 Visual Basic 32 SmallTalk 22 SQL 12 Java 58

http://irb.cs.uni-magdeburg.de/sw-eng/us/java/fp/

Fuente: Pressman, 5ª edición, pág. 62

21


funcionalidad

Ejemplo de puntos de función

Una representación de un sencillo programa de revisión ortográfica. El sistema tiene una entrada (el nombre del archivo que ha de revisarse), tres salidas (el número total de palabras revisadas, el número total de errores y una lista de las palabras erróneamente escritas), una consulta (el usuario puede obtener interactivamente el número de palabras procesadas hasta el momento), un archivo externo (el documento a inspeccionar y un archivo interno (el diccionario). Para este sencillo programa, el número de elementos es 1+3+1+1+1=7.

Corrector ortográfico

Usuario

Salida:

1. Numero de palabras revisadas 2. Número total de faltas de ortografía 3. Lista de palabras con errores ortográficos

Consulta:

1. ¿cuántas palabras llevamos procesadas?

Entrada:

1. Nombre del documento a revisar

Archivo externo:

1. Documento que se va a revisar

Archivo interno:

Diccionario

22


funcionalidad

Puntos objeto

Utiliza una medida del tamaño que puede ser aplicada al comienzo del desarrollo. Para realizar el cálculo de los puntos objeto se realiza una medida inicial contando el número de pantallas, informes y componentes de 3GL de la aplicación. A cada objeto se le asigna un factor de peso según su grado de dificultad. Los pesos reflejan el esfuerzo relativo requerido para implementar un objeto de un determinado nivel.

Tipo de objeto Simple Medio Difícil

Pantalla 1 2 3

Informe 2 5 8

Componente 3GL - - 10

Tipos de objeto y factores de peso

Puntos de característica

Sistemas en tiempo real , control de procesos, sistemas empotrados,…

23

6. Medición de atributos internos del producto: Puntos de casos de uso

Puntos de caso de uso

Los casos de uso son la base para estimar el esfuerzo (en técnicos– hora) de un proyecto software tomando de partida la especificación de requisitos del proyecto en cuestión.

La métrica punto de caso de uso, que se denota UCP, es:

UCP= UUCP * TCF * EF

UUCP representa los puntos de casos de uso no ajustados, que es una suma ponderada del número de actores y del número de casos de uso de la especificación.

Peso de los actores:

Peso de los casos de uso:

Tipo de actor Peso

Interfaz de programa 1

Interfaz interactiva 2

Interfaz gráfica 3

Número de pasos/Número de clases de

análisis Peso

Menos de 4 pasos ó 5 clases de análisis 5

Entre 4 y 7 pasos ó entre 6 y 10 clases de

análisis

10

Otro caso 15

24


Puntos de caso de uso (continuación)

TCF representa algunos aspectos no funcionales del sistema y se conoce como factor de complejidad técnica. Para calcular el valor de TCF se toma de la siguiente tabla y cada factor se multiplica por un valor entre 0 y 5 según la incidencia de dicho factor en el proyecto.

13

TCF= 0.6 + 0.01 Wi * FIi i=1:

Peso de los casos de uso:

Descripción del factor técnico Peso

Sistema distribuido 2

Rendimiento 1

Eficiencia 1

Procesamiento interno complejo 1

Reusabilidad 1

Facilidad de instalación 0.5

Facilidad de uso 0.5

Portabilidad 2

Facilidad de cambio 1

Concurrencia 1

Seguridad (condiciones especiales) 1

Otorgue acceso directo a terceras personas 1

Facilidad de enseñarlo a los usuarios finales 1

25


Puntos de caso de uso (continuación)

EF representa el nivel de experiencia del personal técnico del proyecto y la estabilidad de los requisitos. Para calcular el valor de EF se aplica la siguiente ecuación:

8

EF= 1.4 + (-0.03) Wi * FIi i=1

Varios estudios empíricos basados en proyectos reales han dado como resultado que el esfuerzo para desarrollar un Punto de caso de uso es aproximadamente de 18 técnico– hora. Esto permite calcular el esfuerzo de desarrollo

Descripción del factor de entorno (Wi) Peso

Familiarizados con las metodologías a usar 1.5

Trabajadores a tiempo parcial -1

Capacidad de análisis 0.5

Experiencia en el dominio de la aplicación 0.5

Experiencia en OO 1

Motivación 1

Dificultades para programar -1

Requisitos estables 2

26


Código OO

La mayoría de las métricas orientadas a objetos se basan en las características distintivas del software orientado a objetos respecto al software convencional:

Localización: forma en que se concentra la información dentro de un programa

Encapsulamiento: empaquetamiento de una colección de elementos.

Ocultamiento de la información: supresión de los detalles operativos de un componente.

Herencia: mecanismo que permite la propagación de responsabilidades de un objeto a otro.

Abstracción: mecanismo que permite concentrarse en los detalles esenciales de un componente sin considerar los de nivel inferior.

27


Código OO

Código orientado a objeto:

Número de métodos estáticos.

Afferent Coupling: Número de clases fuera del paquete que dependen de clases dentro del paquete.

Efferent Coupling: Número de clases dentro del paquete que dependen de clases fuera del paquete.

Nested Block Depth: profundidad en bloques anidados.

Lack of Cohesion in Methods (LCOM), Falta de cohesión en métodos: Si es cerca de 1 quiere decir que se nos aconseja que dividamos la clase en varias subclases.

28



Métricas orientadas a clases CK (Chidamber/Kemerer)

Métodos ponderados por clase (MPC): recoge la noción de complejidad.

Para una clase C con M1, M2, ...,Mn métodos con un peso de complejidad c1, c2, ..., cn respectivamente,

MPC = ci

Profundidad del árbol de herencia (PAH): longitud del camino máximo entre un nodo y la raíz del árbol.

Número de hijos (NH): es el número de descendientes inmediatos de una clase (nodo).

Acoplamiento entre clases (AC): número de clases que se acoplan con una clase dada.

Respuesta para una clase (RPC): es el número de métodos locales de una clase más el número de métodos llamados por dichos métodos locales.

Métrica de falta de cohesión (MFC): número de métodos locales que no acceden a atributos comunes.

29



Métricas orientadas a clases CK (Chidamber/Kemerer)

Ejemplo:

Profundidad del árbol de herencia (PAH): longitud del camino máximo entre un nodo y la raíz del árbol.

Animal

Invertebrados Vertebrados

Sangre fría Sangre calienteSin esqueleto Con esqueleto externo

PAH(dg)=3

31

7. Medición de atributos de los recursos

Los recursos incluyen cualquier entrada en la producción de software. Las medidas de recursos ayudan a controlar el proceso indicando cómo el proceso está usando y transformando las entradas en salidas.

Los recursos internos que se pueden medir directamente son:

Personal

Materiales

Herramientas

Métodos

...

Los recursos externos pueden obtenerse a partir de los anteriores:

Coste

Productividad

productividad = cantidad de salida / cantidad de entrada

33

8. Resumen de métricas

ATRIBUTOS ENTIDADES

Internos Externos

Productos Especificaciones,

diseño, código...

Tamaño, reusabilidad,

modularidad, funcionalidad,

acoplamiento, complejidad...

Comprensión, mantenibilidad,

calidad, fiabilidad ...

Procesos Realización de la

especificación, del

diseño, del código...

Tiempo, esfuerzo, cambios en

requisitos, fallos en la

especificación

Calidad, coste, estabilidad

Recursos Personal, equipos,

hardware, software...

Edad, precio, tamaño del equipo,

velocidad, tamaño de memoria

Productividad, experiencia,

calidad, usabilidad, fiabilidad

34

9. GQM (Goal Question Metric)

El enfoque GQM puede utilizarse para seleccionar e implementar métricas de una manera efectiva (http:www.gqm.nl). Se aplican varios pasos:

Lista de los objetivos y agentes. Áreas de medición. Definición de términos. Para cada objetivo obtener las preguntas que deben

contestarse para saber si se están cumpliendo los objetivos.

Decidir qué medir para poder contestar las preguntas de forma adecuada.

MEDIDAS INTERMEDIAS:

OBJETIVO: Evaluar la efectividad del estándar de codificación

PREGUNTAS: ¿Quien está usando

el estándar?

¿Cual es la

productividad del

codificador?

¿Cual es la calidad

del código?

Técnicos usando

el estándar

Cantidad de código

Errores Esfuerzo en codificación con y sin estándar

Ejemplo de métricas derivadas con el método GQM

Total técnicos

MÉTRICAS

¿?...... ¿?... ¿?.....

35

9. GQM (Goal Question Metric)

OBJETIVOS

Mejorar la planificación del proyecto.

Incrementar la contención de defectos.

Incrementar la Fiabilidad.

AREAS DE MEDICIÓN

Defectos entregados y defectos entregados por tamaño.

...

DEFINICIÓN DE TÉRMINOS

PROBLEMA SOFTWARE.

ERROR, DEFECTO, FALLO, AVERÍA..

MÉTODOS GQM: Objetivo: mejorar la planificación del proyecto.

Pregunta: ¿Cuál es la precisión en la estimación del valor real del plazo del proyecto?

Métrica: Precisión en la estimación del plazo (PEP) PEP=Duración real /Duración estimada

36

Referencias

Binder, R., Testing Object-Oriented Systems, American Programmer, 7(4), 22-29, 1994.

Clemons RK, Project Estimation with Use Case Points Disponible en http://www.stsc.hill.af.mil/CrossTalk/2006/02/0602Clemmons.pdf

Chidamber, S.R. y Kemerer, C.F., A metrics suite for object-oriented design ,IEEE Trans. Software Engineering, 20(6), 476-493, 1994.

Churcher, N.I. and Shepperd, M.J., Towards Conceptual Framework for Object-Oriented Metrics, ACM Software Engineering Notes, 20 (2), 67-76, 1995.

Dolado, J.J. y Fernández, L. (coordinadores). “Medición para la Gestión en la Ingeniería del Software”. Ra-ma, 2000.

Fenton, N.E. y Pfleeger, S.L., Software metrics. A rigorous & practical approach , 1997.

Fenton, N.E. Y Kitchenham B., Validating Software Meaures, Journal of Software Testing, Verification and Reliability 1(2): 27-42, 1991

Genero M., Piattini M., Calero C. (coordinadores), Metrics for Software Conceptual Models, Imperial College Press, 2005.

IEEE Software Engineering Standards,. Standard 610.12-1990, 1993.

Lorenz, M. and Kidd, J., Object_oriented Software Metrics, Prentice Hall 1994.

McConnell, S., Desarrollo y gestión de proyectos informáticos, Mc Graw Hill 1997.

Putnam, Lawrence H and Myers W., Five Core Metrics, DH Publishing, 2003

Pressman, R.S., Ingeniería del Software. Un enfoque práctico, Mc Graw Hill, 2005.

Wohlin C. Et al. Experimentation in Software Engineering: An Introduction. Kluwer Academic Publisher, 2000

Documents

Médición del Software - us