1 PLANEACIÓN DE LA CALIDAD Rubby Casallas Departamento de Ingeniería de Sistemas y Computación Universidad de Los Andes Referencias 2 Software Metrics Metrics and Modals in Software Quality Engineering Normal E. Fenton and Shari Lawrence Pfleeger. Second Edition. PWS publishing Company. ISBN: 0-534-95425-1 1999 Stephen H. Kan Addison Wesley ISBN 0-201-6339-6 2001 Introduction to the Team Software Process SM. Capítulo 5 Watts Humphrey. Addison Wesley. 2000 Ejercicio 3 ¿Cuál información Ud. debe tener para poder responder a estas preguntas? “¿Cuánto ha costado el proceso de pruebas en el proyecto?” “¿Qué tan bueno es el código que se ha desarrollado? “ “¿Están los clientes satisfechos con el producto hasta ahora desarrollado?” “¿Se han encontrado todas las fallas?” “¿Cómo se puede mejorar el proceso?” Métricas de Software 4 “Las métricas de Software son una obscura y esotérica especialidad” Agenda 5 Métricas de producto y de proceso de software GQM: Objetivos, Preguntas, Métricas Plan de Calidad Agenda 6 Métricas de producto y de proceso de software GQM: Objetivos, Preguntas, Métricas Plan de Calidad Propósito 7 Las métricas de Software ayudan a una organización en dos frentes: Evaluación de la calidad del producto Evaluación de la calidad del proceso para producir productos de software Definiciones Básicas 8 La acción de medir es el proceso por el cual números o símbolos son asignados a atributos de entidades en el mundo real, de tal forma que los describen de acuerdo a reglas claramente definidas Ejemplos: Entidades Atributos Mediciones Cuarto área 20x30 metros Fase de pruebas tiempo invertido 2 horas Aire temperatura 20C Proceso de SW nivel CMM nivel 3 Definiciones Básicas (2) 9 Y ahora: Entidades Atributos Mediciones Software Calidad ? Programa Tamaño ? Programa Complejidad ? Software Confiabilidad ? Definiciones Básicas (3) 10 “Lo que no es medible, hágalo medible” Galileo Galilei Sugiere que uno de los objetivos de la ciencia es encontrar formas para medir atributos de las cosas en las que estamos interesados Las métricas hacen los conceptos más visibles y por lo tanto más entendibles y controlables Alcance de las métricas de Software 11 Métricas para entender, controlar y mejorar Recursos Producto Proceso • Proceso: cualquier actividad relacionada con la producción de software • Diseño, codificación, pruebas, administración de configuraciones • Producto: un artefacto resultado de una actividad del proceso • Especificación, plan, código, caso de prueba • Recurso: un elemento que es necesario para realizar el proceso • Gente, tiempo, hardware, software, método Alcance de las métricas de Software (2) 12 Para un Producto, Proceso o Recurso tenemos: Atributos externos Pueden ser medidos únicamente con respecto a su interacción con el ambiente Por ejemplo: Confiabilidad Atributos Pueden Internos ser medidos en términos puramente de las entidades en si mismas. Por ejemplo, líneas de código Componentes de las métricas de software 13 Proceso Producto Recursos Atributos internos y externos Ejemplos: Productos 14 Entidad Interno Externo Especificaciones tamaño, reutilización, modularidad, corrección sintáctica entendible, mantenibilidad Diseños tamaño, reuse, modularidad, acoplamiento, funcionalidad calidad, complejidad mantenibilidad Código tamaño, reuse, complejidad algorítmica, flujo de control estructuración confiabilidad, mantenibilidad Ejemplos: Proceso 15 Entidad Interno Externo Especificar tiempo, esfuerzo, número de calidad, costo, estabilidad cambios en los efectividad requerimientos Pruebas tiempo, esfuerzo, número de costo, costo-efectividad defectos encontrados Planeación tiempo, esfuerzo, error de estimación precisión, costo Ejemplos: Recursos 16 Entidad Interno Externo Personal edad, salario productividad, experiencia Software precio, tamaño uso (usability), confiabilidad Oficinas temperatura, tamaño, luz confort, calidad Escalas de medición: Ejercicio 17 En un estudio reciente sobre calidad de los procesos en las organizaciones, se encontró que: 15 organizaciones fueron nivel 1 20 organizaciones fueron nivel 2 9 organizaciones fueron nivel 3 6 organizaciones fueron nivel 4 y 1 organización fue nivel 5 Entonces ¿Podemos decir que el nivel de CMM promedio es: 2.17? Tipo de escala Relaciones Ejemplo de estadísticas Nominal Equivalencia Moda Frecuencia Ordinal Equivalencia Más grande que Media Percentil Equivalencia Más grande que Conoce la diferencia en cualquier intervalo Media Desviación estándar Intervalo Proporción Equivalencia Más grande que Conoce la diferencia en cualquier intervalo Conoce la diferencia en cualquier intervalo y escala Media geométrica Coeficiente de variación Agenda 19 Métricas de producto y de proceso de software GQM: Objetivos, Preguntas, Métricas Plan de Calidad GQM 20 Hechos: Una métrica es útil sólo si ésta ayudad a entender o el proceso o el producto producido Reconocer mejoramiento del proceso o del producto de software solo puede ocurrir cuando los objetivos (del proceso y del producto) fueron claramente definidos GQM 21 El método GQM ayuda en la definición de objetivos de una organización Una vez establecidos los objetivos, se pueden refinar a través de preguntas cuya respuesta permitirá concluir si los objetivos se cumplieron o no Asociado a las preguntas se definen métricas cuyos valores ayudaran a contestar las preguntas GQM 22 Ejemplo 23 Objetivos: Evaluar la efectividad de usar un estándar de codificación Preguntas: ¿Quién usó el estándar? ¿Cuál es la productividad de codificación? ¿Cuál es la calidad del código? Ejemplo cont. 24 Métricas: Quién usó el estándar? Proporción de codificadores usando el estándar Experiencia de los codificadores con el estándar, el lenguaje, la plataforma Cuál es la productividad de codificación? Tamaño • del código, esfuerzo Cuál es la calidad del código? • Defectos/LOC Definición de Objetivos 25 Propósito: Para (caracterizar, evaluar, predecir, motivar, etc.) el (proceso, producto, métrica, etc.) para poder (entender, evaluar, controlar, administra, aprender, mejorar, etc.) Perspectiva: Examinar el (costo, efectividad, defectos, cambios, etc.) desde el punto de vista del (desarrollador, gerente, cliente, usuario, etc.) Ambiente (dentro de ciertas características de): Factores de proceso, la gente, los métodos, las herramientas, las restricciones Objetivos: Ejemplo 26 Propósito Caracterizar el proceso de inspección de software para poder evaluarlo Evaluar la calidad del producto para mejorarla Objetivos: Ejemplo 27 Preguntas ¿Cuánto cuesta el proceso de inspección? ¿Cuánto tiempo calendario toma el proceso de inspección? ¿Cuál es la calidad del software inspeccionado? ¿Cuál es el grado de conformidad de la gente con el proceso de inspección? ¿Cuál es la productividad del proceso de inspección? Objetivos: Ejemplo 28 Métricas Promedio de esfuerzo por KLOC Porcentaje de reinspecciones Promedio de fallas detectadas por KLOC Total KLOC inspeccionadas Promedio de líneas de código inspeccionadas Eficiencia de los defectos removidos Promedio de esfuerzo por defecto detectado GQM 29 ¿Cuál es la relación entre métricas y madurez del proceso? CMM 30 Continuously improving process Managed (4) Predictable process Standard, consistent process Repeatable (2) Disciplined process Initial (1) Defined (3) Optimizing (5) Focus on continuous process improvement Process measured and controlled Process characterized, fairly well understood Can repeat previously mastered tasks Unpredictable and poorly controlled Agenda 31 Métricas de producto y de proceso de software GQM: Objetivos, Preguntas, Métricas Plan de Calidad Plan de Calidad 32 Construir un plan de calidad basado en ciertos índices de desempeño Contenido del Plan 1. Resumen de Porcentajes 2. Porcentaje libre de defectos (PDF) 3. Defectos por Página 4. Defectos por KLOC 5. Proporción de defectos (Ratio) 6. Proporción de tiempos de desarrollo Plan de Calidad (2) 33 Contenido del Plan 7. A/FR 8. Porcentaje de revisión e inspección 9. Porcentaje de inyección de defectos 10. Porcentaje de eliminación de defectos 11. Rendimiento (yield) de fase 12. Rendimiento (yield) de proceso Plan de Calidad (3) 34 1. Resumen de Porcentajes Las tres medidas del resumen dan una perspectiva global de la calidad del Proceso: LOC/Horas: mide la productividad global del grupo. Un número grande indica gran productividad y bajos costos % Reutilización: mide el porcentaje global de este producto que fue reutilizado de proyectos anteriores % Reutilización nuevo: mide la contribución de este ciclo al mejoramiento de la productividad en ciclos posteriores o proyectos Plan de Calidad (4) 35 2. Porcentaje libre de defectos (PDF) Mide el porcentaje de los componentes de un producto que no tiene defectos en una fase dada. Ejemplo: Un componente con 5 partes y cuatro tenían defectos en la fase de compilación, el PDF del componente en la fase de compilación es del 20% (no se tiene en cuenta el número de defectos) Entre mayor el número de partes, mayor la precisión del PDF para medir la calidad del componente. Datos de PDF en todas las fases de eliminación de defectos permite ver el mejoramiento de la calidad a través del proceso de desarrollo. Plan de Calidad (5) 36 3. Defectos por página Muestra el número de defectos removidos de cada página del documento de requerimientos y del diseño de alto nivel Plan de Calidad (6) 37 4. Defectos por KLOC Un defecto es cualquier elemento asociado con los requerimientos, el diseño o la implementación que de no ser cambiado puede causar un diseño, implementación, prueba, uso o mantenimiento del producto no adecuados Un defecto mayor es cualquier problema que cuando se arregla cambia el código ejecutable Defectos en formatos o comentarios son considerados menores Plan de Calidad (7) 38 4. Defectos por KLOC (cont...) El número de defectos encontrados en una fase de pruebas indica la calidad del producto entrando y saliendo de esa fase Cuando un producto tiene muchos defectos, una fase de pruebas encontrará muchos de ellos poro también dejará sin encontrar muchos Si hay muchos defectos en pruebas unitarias, probablemente habrá todavía muchos terminada esa fase Plan de Calidad (8) 39 4. Defectos por KLOC (cont...) La experiencia muestra que cuando un producto tiene menos de 0.5 defectos/KLOC en construcción y pruebas de integración y menos de 0.2 defectos/KLOC en pruebas de sistema, generalmente no habrá defectos para que encuentre el usuario (producto de alta calidad) Pruebas de Sistema Integración Pruebas Unitarias Compilación Revisión Código 4. Revision DD Plan de Calidad (9) Defectos por KLOC (cont...) 70 60 50 40 30 A B 20 10 0 40 Plan de Calidad (10) 41 5. Proporción de defectos (Ratio) Provee un mayor detalle de la calidad de las revisiones de diseño y de código La experiencia muestra que cuando se encuentra el doble de defectos en revisión de código que en compilación, la revisión de código fue realizada a conciencia. En este caso la proporción de defectos es 2.0 Número de defectos encontrados en revisión de diseño contra número de defectos encontrados en pruebas unitarias. Esta proporción debería ser más de 2.0 Plan de Calidad (11) 42 6. Proporción de tiempos de desarrollo Según la experiencia, las siguientes proporciones dan una idea de la buena calidad del producto (no es una garantía poro la probabilidad es alta): 25% del tiempo de requerimientos debe ser en inspección de requerimientos 50% del tiempo de diseño de alto nivel debe ser en revisiones e inspecciones >100% del tiempo de diseño detallado debería ser en revisiones e inspecciones Plan de Calidad (12) 43 7. A/FR (Appraisal to Failure Ratio) (Revisión/Pruebas) Para programas pequeños debería ser alrededor de 2.0 Para programas grandes debería ser alrededor de 1.0 porque aun si los programas tienen pocos defectos en pruebas, probarlos es dispendioso Plan de Calidad (13) 44 8. Porcentaje de revisión e inspección Requerimientos: <2.0 páginas de texto a espacio simple por hora Diseño de alto nivel: <5.0 páginas de diseño por hora Diseño detallado: <100 líneas de pseudocódigo por hora Código: <200 líneas de código por hora Plan de Calidad (14) 45 9. Porcentaje de inyección de defectos De acuerdo con datos de varios cientos de programas escritos por estudiantes y por ingenieros experimentados en un curso de PSP, se tiene que: La proporción de inyección de defectos durante diseño detallado es de 2 defectos por hora Y es de 6 defectos por hora en codificación Plan de Calidad (15) 46 10. Porcentaje de eliminación de defectos Tomando la misma muestra, los datos fueron más variados: En revisión de código va de 0 a 20 defectos por hora, el resultado fue de 6 defectos por hora para el 61.5% de los ingenieros En revisión de diseño, 2 o más defectos por hora para el 57.9% de los ingenieros Plan de Calidad (16) 47 11. Rendimiento (yield) de fase Porcentaje de defectos en un programa que fueron removidos durante una fase dada Ejemplo: 19 defectos en el programa a la entrada de la revisión de código Se inyectó un defecto durante la revisión de código Se encontraron 15 durante la revisión yield = 100 * (defectos encontrados)/(defectos en el producto) = 100* 15/(19+1) = 75% Se puede calcular sólo cuando se ha terminado el programa y se sabe el número total de defectos Plan de Calidad (17) 48 12. Rendimiento (yield) de proceso El porcentaje de defectos removidos antes de una fase dada Ejemplo: antes de pruebas de sistema debería ser de 99%