Planeación de la Calidad

Planeación de la Calidad Rubby Casallas Departamento de Ingeniería de Sistemas y Computación Uniandes

Referencias • Software Metrics. • Normal E. Fenton and Shari Lawrence Pfleeger. Second Edition. PWS publishing Company. ISBN: 0-534-95425-1 1999 • Metrics and Modals in Software Quality Engineering. • Stephen H. Kan Addison Wesley ISBN 0-201-6339-6 2001 • Introduction to the Team Software ProcessSM. Capítulo 5. • Watts Humphrey. Addison Wesley. 2000 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Ejercicio • 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?” Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

“Las métricas de Software son una obscura y esotérica especialidad” Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Agenda • Métricas de producto y de proceso de software • GQM: Objetivos, Preguntas,Métricas • Plan de Calidad Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Propósito • 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Definiciones Básicas • 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 Software Process CMM level level 3 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Definiciones Básicas(2) Y ahora: Entidades Atributos Mediciones • Software Calidad ? • Programa tamaño ? • Programa Complejidad ? • Software Confiabilidad ? Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Definiciones Básicas (3) “Lo que no es medible, hágalo medible” Galileo • 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. Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Proceso Alcance de las métricas de Software • Métricas para entender, controlar y mejorar Recursos Producto • 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Alcance de las métricas de Software(2) • 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 Internos • Pueden ser medidos en términos puramente de las entidades en si mismas. • Por ejemplo, líneas de código Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Componentes de las métricas de software • Proceso • Producto • Recursos • Atributos internos y externos Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Ejemplos: Productos Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Ejemplos: Proceso Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Ejemplos: Recursos Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Escalas de medición: Ejercicio • “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? Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

GQM • 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

GQM • 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

GQM Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Ejemplo • 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? Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Ejemplo cont. • Métricas: • Quién usó el estándar? • Proporción de codificadores usando el estándar • Experiencia de los codificadotes 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Definición de Objetivos • 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Objetivos: Ejemplo • Propósito • Caracterizar el proceso de inspección de software para poder evaluarlo • Evaluar la calidad del producto para mejorarla Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Objetivos: Ejemplo • 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? Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Objetivos: Ejemplo • 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

GQM • Cuál es la relación entre métricas y madurez del proceso? Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

CMM Focus on continuous process improvement Optimizing Continuously (5) improving process Process measured and controlled Managed Predictable (4) process Process characterized, fairly well understood Defined Standard, consistent (3) process Repeatable Can repeat previously mastered tasks Disciplined (2) process Initial Unpredictable and poorly controlled (1) Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad • 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad • 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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. Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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. Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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. Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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. Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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). Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Defectos/KLOC Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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 !! Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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. Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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 pseudo código por hora • Código: < 200 líneas de código por hora Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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 Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Plan de Calidad 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% Rubby Casallas G. Departamento de Ingeniería de Sistemas Universidad de los Andes

Planeación de la Calidad