Guía 08. Medición de Software INTRODUCCIÓN

Transcripción

1 INTRODUCCIÓN "Lo que no se puede medir, no se puede controlar; lo que no se puede controlar no se puede gestionar; lo que no se puede gestionar, no se puede mejorar" (Peter Drucker) No se puede predecir lo que no se puede medir (Norman Fenton) Las métricas son un buen medio para entender, monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de mantenimiento (Briand et al., 1996) En general, la medición persigue tres objetivos fundamentales (Fenton y Pfleeger, 1997): entender qué ocurre durante el desarrollo y el mantenimiento controlar qué es lo que ocurre en nuestros proyectos mejorar nuestros procesos y nuestros productos 1

2 INTRODUCCIÓN Las métricas pueden ser utilizadas para que los profesionales e investigadores puedan tomar las mejores decisiones. (Pfleeger, 1997). MÉTRICAS COMO MEDIO PARA ASEGURAR LA CALIDAD EN LOS PRODUCTOS / PROCESOS / PROYECTOS SOFTWARE 2

3 ONTOLOGÍA DE LA MEDICIÓN Una ontología ha de comprenderse como un entendimiento común y compartido de un dominio La medición de software es una disciplina relativamente joven, y no existe consenso general sobre la definición exacta de los conceptos y terminología que maneja. 3

4 ONTOLOGÍA DE LA MEDICIÓN Sub-Ontología Caracterización y Objetivos de la Medición Software: Glosario de Conceptos 4

5 ONTOLOGÍA DE LA MEDICIÓN Sub-Ontología Caracterización y Objetivos de la Medición Software: Tabla de Interrelaciones 5

6 ONTOLOGÍA DE LA MEDICIÓN Concepto: MÉTRICA Definición. Una forma de medir y una escala, definidas para realizar mediciones de uno o varios atributos Relaciones: Una métrica está definida para uno o más atributos Una métrica puede expresarse en una unidad (sólo para métricas cuya escala sea de tipo intervalo o ratio) Ejemplos líneas de código para el tamaño de un módulo en C o de un programa en Python. 6

7 ONTOLOGÍA DE LA MEDICIÓN Concepto. MEDIDA Definición. Resultado de una medición. Relaciones: Una medida es el resultado de una medición Ejemplos líneas de código, 200 páginas, 50 clases. 5 meses desde el comienzo al fin del proyecto. 0,5 fallos por cada líneas de código. 7

8 8

9 ONTOLOGÍA DE LA MEDICIÓN ESCALAS NOMINAL. Escala más básica, que sitúa a las entidades en diferentes categorías asignando al atributo un nombre. Cuando un producto se rotula de acuerdo al cumplimiento de las especificaciones de diseño como "conforme y no conforme". o "crítico, grave, y menor". No se obtienen valores numéricos y no se puede realizar un orden de las observaciones con sentido. ORDINAL. Los atributos pueden ser ordenados en rangos, entre los mismos no es significativa. pero la distancia Suponga que a los clientes se les hace unas preguntas para valorar la calidad del producto. Los clientes valoran la calidad de acuerdo a las siguientes respuestas: 1 (excelente), 2 (bueno), 3 (regular), 3 (malo) 4 (pésimo). Estos datos son ordinales. Note que una valoración de 1 no indica que el servicio es dos veces mejor que cuando se da una valoración de 2. Sin embargo podemos decir que la valoración de 1 es preferiblemente mejor que 2, y así en los demás casos. 9

10 ONTOLOGÍA DE LA MEDICIÓN ESCALAS INTERVALO. Como la ordinal pero la distancia entre los atributos sí tiene sentido. Si se mide la temperatura en grados celsius, la distancia entre 30º y 40º es la misma que entre 60º y 70º. Sin embargo, hay que tener en cuenta que en esta escala el cero es arbitrario; por tanto no se puede decir que 50º es el doble de temperatura que 25º (aunque el valor si es el doble). RATIO. El mas útil en medición del software, ya que preserva el orden, el tamaño de los intervalos y también los ratios entre las entidades. Tiene un punto fijo de referencia: el cero (comienzo de la escala) y se incrementa en pasos iguales. Con estos valores de la escala se pueden hacer operaciones matemáticas de +, -, *, / 10

11 ONTOLOGÍA DE LA MEDICIÓN Todo proceso de medición tiene como objetivo fundamental satisfacer necesidades de medición detectadas en la empresa en la que se lleva a cabo. A partir de esta necesidad se identifican entidades y atributos a ser medidos. Luego se definen las métricas necesarias (unidad en la que se expresa, escala a la que pertenece, atributo o atributos para los que se define) Primero se definen métricas directas, luego indirectas, y finalmente criterios de decisión para satisfacer las necesidades de información planteadas inicialmente. 11

12 ESTÁNDARES Practical Software Measurement (PSM) (McGarry et al., 2002) se basa en la experiencia obtenida de organizaciones para saber cuál es la mejor manera de implementar un programa de medida software con garantías de éxito. ISO/IEC Este estándar internacional (2002) establece las actividades y tareas necesarias para identificar, definir, seleccionar, aplicar y mejorar de manera exitosa la medición de software dentro de un proyecto general o de la estructura de medición de una empresa. 12

13 ESTÁNDARES MEDICIÓN EN ISO/IEC Es el estándar para los procesos de ciclo de vida del software. Este estándar se concibió para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. El estándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software. 13

14 DEFINICIÓN DE MÉTRICAS Basili y Weiss (1984) y Rombach (1990). Autores y refinadores de GQM (Goal-Question- Metric), un paradigma para desarrollar y mantener un programa de métricas. Proporciona una manera útil para definir mediciones tanto del proceso como de los resultados de un proyecto. GQM se puede aplicar a todo el ciclo de vida del producto, procesos, y recursos y se pude alinear fácilmente con el ambiente organizacional. Tiene como principio básico que la medición debe ser realizada, siempre, orientada a un objetivo. Objetivo Objetivo Perseguido Preguntas Pregunta 1 Pregunta N Métricas M1... Mn M1... Mn 14

15 MÉTRICAS DE SOFTWARE PROCESO DE RECOPILACIÓN DE MÉTRICAS 15

16 MÉTRICAS DE SOFTWARE Clasificación de las métricas de software según criterios: 16

17 MÉTRICAS DE SOFTWARE Según el contexto: Proceso: Se recopilan de todos los proyectos, y durante un largo periodo de tiempo Caracterizadas por: Control y ejecución del proyecto. Medición de tiempos de las fases. Proyecto: Permiten evaluar el estado del proyecto. Permiten seguir la pista de los riesgos. Producto: Se centran en las características del software y no en cómo se fabricó. También son productos los artefactos, documentos, modelos y componentes que conforman el software. Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad y el esfuerzo. 17

18 EJEMPLO. Supongamos una organización que lleva a cabo un proyecto de desarrollo de un software X. En un determinado momento el responsable del proyecto necesita saber si la productividad es adecuada, es decir: La necesidad de información es conocer el nivel de productividad de los programadores del proyecto en comparación con lo habitual en otros proyectos en la organización. Las métricas a utilizar podrían ser: Directas: LCF (líneas de código fuente escritas). El método de medición es contar las líneas utilizando como instrumento una herramienta CASE. HPD (horas-programador diarias). El método de medición es que el responsable del proyecto anota cada día las horas dedicadas por los programadores al proyecto. CHP (coste por hora-programador, en unidades monetarias). El método de medición es consultar el plan del proyecto, donde se tuvo que indicar este valor, previa consulta a un responsable de personal. 18

19 EJEMPLO Indirectas: HPT (horas-programador totales). La función de cálculo es una sumatoria de las HPD de cada día: [Métrica indirecta definida con base en sólo 1 métrica directa]. HPT = HPD LCFH (líneas de código fuente por hora de programador). La función de cálculo es una simple división: LCFH = LCF / HPD [Métrica indirecta definida con base en 2 métricas directas]. CTP (coste total actual del proyecto, en unidades monetarias). La función de cálculo establece que el CTP es el producto del coste unitario de cada hora por el total de horas empleadas: CTP = CHP * HPT [Métrica indirecta definida con base en 2 métricas, una directa y otra indirecta]. CLCF (coste por línea de código fuente). La función de cálculo establece que el CLCF es el resultado de dividir el coste total actual del proyecto -en unidades monetarias- entre la cantidad de líneas de código fuente escritas: CLCF = CTP/ LCF. [Métrica indirecta definida con base en 2 métricas, una indirecta y otra directa]. 19

20 EJEMPLO Indicadores: PROD (productividad de los programadores). El modelo de análisis utiliza los valores de las métricas LCF, HPT, LCFH y CTP para establecer un valor cualitativo de la productividad de los programadores en este proyecto. El modelo se basa en extraer de una base histórica de proyectos de la organización los valores medios de LCF, HPT, LCFH (LCFHvm valor medio de líneas de código fuente por hora de programador) y CTP del subconjunto de proyectos similares (aquellos que tienen LCF entre el 80% y el 120%). Y la organización establece el siguiente criterio de decisión: LCFH / LCFHvm < 0.70 se interpreta como PROD= muy baja <= LCFH / LCFHvm < 0.90 se interpreta como PROD= baja <= LCFH / LCFHvm < 1.10 se interpreta como PROD= normal <= LCFH / LCFHvm < 1.30 se interpreta como PROD= alta <= LCFH / LCFHvm se interpreta como PROD= muy alta. De modo que cuando se calcule el valor para el indicador (a partir de las métricas mencionadas) se podrá evaluar y entregar un concepto sobre la situación que dicho indicador pretende reflejar. 20

21 OTROS QUE SE PUEDEN UTILIZAR Número de defectos generados por desarrollador por hora Número de cambios a los requisitos Número de versiones con correcciones (patch) realizadas después de lanzar el producto Horas disponibles y ejecutadas por programador por semana Defectos descubiertos durante las pruebas Número de defectos introducidos al realizar una modificación. 21

22 MEDIDA DE LOS FACTORES DE CALIDAD Los factores que afectan a la calidad del software se pueden categorizar en dos amplios grupos: (1)Factores que se pueden medir directamente (por ejemplo, defectos por punto de función). (2)Factores que se pueden medir sólo indirectamente (por ejemplo, facilidad de uso o de mantenimiento). En todos los casos debe aparecer la medición. Debemos comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad. 22

23 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. 23

24 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Es difícil, y en algunos casos imposible, desarrollar medidas directas de los factores de calidad anteriores. Por tanto, se definen y emplean un conjunto de criterios para desarrollar expresiones para todos los factores, de acuerdo con la siguiente relación: QF = (c 1 * m 1 ) + (c 2 * m 2 ) + (c 3 * m 3 ) + + (c n * m n ) Donde: QF es un factor de calidad del software, c n son coeficientes de regresión ( c 1 + c c n = 1.0 ) m, son los valores de los criterios que afectan al factor de calidad. 24

25 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. El problema es que muchas de los criterios definidas por McCall pueden medirse solamente de manera subjetiva. Las métricas pueden ir en forma de lista de comprobación que se emplea para "puntuar" atributos específicos del software. El esquema de puntuación propuesto por McCall es una escala del 0 (bajo) al 10 (alto). Se emplean las siguientes criterios en el esquema de puntuación: 25

26 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Facilidad de auditoría. La facilidad con la que se puede comprobar el cumplimiento de los estándares. Exactitud. La exactitud de los cálculos y del control. Estandarización de comunicaciones. El grado de empleo de estándares de interfaces y protocolos. Compleción. El grado con que se ha logrado la implementación total de una función. Complejidad. Valoración del grado de complejidad del componente / función. Concisión. Lo compacto que es el programa en términos de líneas de código. Consistencia. El empleo de un diseño uniforme y de técnicas de documentación a lo largo del proyecto de desarrollo del software. Estandarización de datos. El empleo de estructuras y tipos de datos estándares a lo largo del programa. Tolerancia al error. El daño causado cuando un programa encuentra un error. Eficiencia de ejecución. El rendimiento del funcionamiento de un programa. Capacidad de expansión. El grado con que se pueden ampliar el diseño arquitectónico, de datos o procedimental. 26

27 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Generalidad. La amplitud de aplicación potencial de los componentes del programa. Independencia del hardware. El grado con que se desacopla el software del hardware donde opera. Instrumentación. El grado con que el programa vigila su propio funcionamiento e identifica los errores que ocurren. Modularidad. La independencia funcional de componentes de programa. Operatividad. La facilidad de operación de un programa. Seguridad. La disponibilidad de mecanismos que controlan o protegen los programas y los datos. Autodocumentación. El grado en que el código fuente proporciona documentación significativa. Simplicidad. El grado de facilidad con que se puede entender un programa. Independencia del sistema software. El grado de independencia de programa respecto a las características del lenguaje de programación no estándar, características del sistema operativo y otras restricciones del entorno. Trazabilidad. La capacidad de seguir una representación del diseño o un componente real del programa hasta los requisitos. Formación (Entrenamiento). El grado en que ayuda el software a manejar el sistema a los nuevos usuarios. 27

28 MEDIDA DE LOS FACTORES DE CALIDAD 28

29 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Las relaciones entre los factores de calidad y los criterios son las siguientes: A. Corrección = (C1 * CM) + (C2 * CS) + (C3 * TZ) B. Fiabilidad = (C1 * EX) + (C2 * CX) + (C3 * CS) + (C4 * TE) + (C5 * MD) + (C6 * SM) C. Eficiencia = (C1 * CN) + (C2 * EE) + (C3 * OP) D. Seguridad (Integridad) = (C1 * FA) + (C2 * IN) + (C3 * SG) E. Usabilidad (Facilidad de uso) = (C1 * OP) + (C2 * FM) F. Facilidad de mantenimiento = (C1 * CN) + (C2 * CS) + (C3 * IN) + (C4 * MD) + (C5 * AD) + (C6 * SM) G. Flexibilidad = (C1 * CX) + (C2 * CN) + (C3 * CS) + (C4 * CE) + (C5 * GE) + (C6 * MD) + (C7 * AD) + (C8 * SM) H. Facilidad de Pruebas = (C1 * FA) + (C2 * CX) + (C3 * IN) + (C4 * MD) + (C5 * AD) + (C6 * SM) I. Portabilidad = (C1 * GE) + (C2 * IH) + (C3 * MD) + (C4 * AD) + (C5 * SM) J. Reusabilidad = (C1 * GE) + (C2 * IH) + (C3 * MD) + (C4 * AD) + (C5 * IS) K. Interoperatividad = (C1 * EC) + (C2 * ED) + (C3 * GE) + (C4 * MD) 29

30 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Criterio: Generalidad (GE--Generality) Métrica 1. GE.1: UR Unit Referencing Métrica 2. GE.2: UI Unit Implementation Criterio: Independencia de la Aplicación (AP--Application Independence) Métrica 1. AP.3: AS Architecture Standardization Criterio: Modularidad (MO--Modularity) Métrica 1. MO.1: MI Modular Implementation Criterio: Auto Descriptividad (SD--Self-Descriptiveness) Métrica 1. SD.2: EC Effectiveness of Comments Tomadas del Reporte Técnico de la Federal Aviation Administration Technical Center. (página 246 del archivo digital). Indican cuáles son las métricas a tener en cuenta para valorar los atributos que conforman la reusabilidad. 30

31 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. A modo de guía se muestran las especificaciones de 2 métricas asociadas a 2 criterios diferentes: Criterio: Independencia de la Aplicación Métrica 1. AP.3: Estandarización de la Arquitectura (AS) AS cantidad de líneas de código no-hol en el módulo cantidad total de líneas de código fuente del módulo Para cada módulo de un CSCI (Computer Software Configuration Item), responda la pregunta: REGLA: "Cuántas líneas de código no-hol (High Order Language) hay en el módulo? (ejemplo de no-hol es el lenguaje ensamblador). "Divida la cantidad de líneas de código no-hol entre la cantidad total de líneas de código." (Bowen, Wigle y Tsai 1985). RANGO: INTERPRETACIÓN: Esta métrica genera un número real entre cero y uno. Los valores útiles para este atributo son los que se acerquen más a cero. 31

32 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Criterio: Independencia de la Aplicación Métrica 1. AP.3: Estandarización de la Arquitectura (AS) La razón de fijarse en lenguaje que no sea HOL es que esos lenguajes son dependientes de la máquina y en la medida que haya una menor cantidad de esas líneas, esto aumenta la valoración del atributo y por consiguiente podría incidir en un aumento de la reusabilidad. Aporte: para ratios como este cuyos valores buenos para la reusabilidad son los que se acercan a cero, habría necesidad de efectuar un cálculo como este: ASr = 1 AS. De modo que cuando el valor de AS se acerque más a cero, el valor de ASr será más cercano a 1 de modo que todas las métricas se puedan llevar a valores con sentido positivo (o creciente) y se puedan llevar todas a una expresión general para cuantificar la reusabilidad. 32

33 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Criterio: Auto Descriptividad Métrica 1. SD.2: Efectividad de los Comentarios (EC) EC cantidad de módulos con comentarios que cumplen estándar cantidad de módulos evaluados REGLA: Para cada módulo de un CSCI, responda la pregunta: " Tiene comentario de encabezado que contenga toda la información acorde con el estándar establecido? (Bowen, Wigle, and Tsai 1985). Divida el total de respuestas afirmativas entre el número de módulos que se estén evaluando. RANGO: Esta métrica genera un número real entre cero y uno. INTERPRETACIÓN: Los valores útiles para este atributo son los que se acerquen más a 1. 33

34 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Criterio: Auto Descriptividad Métrica 1. SD.2: Efectividad de los Comentarios (EC) La razón de fijarse en que los comentarios cumplan con un estándar establecido es que podrían facilitar la comprensión de lo que hace el módulo. Esto aumenta la valoración del atributo ya que si se puede comprender, se puede evaluar con menos dificultad si se podría re-usar, y por consiguiente podría incidir en un aumento de la reusabilidad. Aporte: para ratios como este cuyos valores buenos para la reusabilidad son los que se acercan a 1, no hay necesidad de calcular una expresión adicional como se hizo con la métrica anterior. 34

35 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Cuantificación de la Reusabilidad. Aún teniendo en cuenta lo expresado, ahora se plantea una primera aproximación para calcular un valor (o probabilidad) para la reusabilidad, a partir de las 2 métricas revisadas: REUSABILIDAD = (C 1 * ASr) + (C 2 * EC). De esta manera el rango de valores resultantes está entre 0 y 1. C i son coeficientes de regresión ( C 1 + C 2 = 1.0 ) que representan la ponderación o el peso que se le podría asignar a cada métrica si se cree que alguna de ellas podría tener una mayor incidencia en la cuantificación de la reusabilidad. De no ser así, en este ejemplo C 1 = C 2 =

36 MEDIDA DE LOS FACTORES DE CALIDAD Ejemplo. Modelo de McCall. Generalizando, se muestra una expresión que podría cuantificar una valoración para Reusabilidad : Por lo tanto, se muestran los símbolos originales, ya que no se tiene forma de saber cuáles de ellas tienen valores buenos cerca de cero. REUSABILIDAD = (C 1 * UR) + (C 2 * UI) + (C 3 * ASr) + (C 4 * MI) + (C 5 * EC) C i son coeficientes de regresión ( C 1 + C 2 + C 3 + C 4 + C 5 = 1.0 ) Si la ponderación es equitativa C i = FIN DEL DOCUMENTO 36