Métricas e Indicadores Objetivos para el Control de Proyectos de Desarrollo de Software EL PROBLEMA Es común que los proyectos de desarrollo de software terminen con importantes desvíos en costos y calendario. ¿Cual ¿En es el grado de Avance? que fecha terminaremos? ¿Cuánto gastaremos realmente? Evidencia Física Los líderes de proyectos tenemos que evitar tomar decisiones subjetivas o “a ojo”. Para esto tenemos que tomar decisiones usando diferentes herramienta basadas en evidencia física Evidencia Física Una posible evidencia física que sirve como base para la registración de avance puede ser una porción de software construida ¿Cuál es la evidencia? El producto desarrollado, probado... y estabilizado (sin defectos críticos) De esta manera estamos utilizando el resultado de Control de Calidad ¿Cual es el grado de avance? Avance por calendario: se mide avance sólo por paso del tiempo. Avance por código completo: se mide avance cuando una porción del código está completa, pero sin saber el grado de estabilidad que tiene. El Indicador de Funcionalidad Completa El indicador de Funcionalidad Completa mide avance cuando una funcionalidad está completa, pero... No hay avance si la funcionalidad no está completa, No está completa la funcionalidad si no está desarrollada, probada y estabilizada El Indicador de Funcionalidad Completa Paso 1 - Determinar las Funcionalidades. Paso 2 - Asignar un Peso a cada funcionalidad. Paso 3 - Estimar la fecha en que la funcionalidad estará completa. Paso 4 - A medida que avanza el proyecto registrar las fechas reales de funcionalidad completa El Indicador de Funcionalidad Completa. Consideraciones: Validez: este indicador sólo es valido en etapa de construcción. 2. Proceso: este indicador no generará avance si el equipo no se focaliza en cerrar temas. 3. Síndrome del 0%: si se considera completa a una funcionalidad cuándo no tiene ningún defecto, evitaremos el síndrome del 90%, pero caeremos en el síndrome del 0%. 4. Funcionalidad = código: es su forma más pura, este indicador sólo considera funcionalidad al producto final para el usuario. 1. El Indicador de Nivel de Calidad El indicador de funcionalidad completa divide al producto en dos estados: funcionalidad completa o no completa. Algunas veces necesitamos utilizar estados intermedios. El Indicador de Nivel de Calidad ¿En que Fecha Terminaremos? Con el indicador de funcionalidad completa podemos obtener una tendencia. En la etapa de estabilización comienza cuando el indicador de funcionalidad completa deja de tener validez. sólo resta corregir los defectos remanentes y encontrar los que no encontramos aún. Indicador de Evolución de Prueba Indicador de Cobertura de Prueba El Indicador de Evolución de Prueba Se utiliza para obtener una tendencia y poder predecir la fecha de finalización. Mide los defectos, cuantos aparecen y cuantos se cierran. (por día, semana, etc…) Proceso: Registrar defectos encontrados. Registrar los cambios de estados. El Indicador de Evolución de Prueba Semana1 Semana2 Semana3 Semana4 Semana5 Cerrados Pendientes suspendidos 10 20 5 30 15 5 40 10 3 60 5 2 80 4 0 Total 35 50 53 67 84 90 80 70 60 Cerrados 50 Pendientes 40 suspendidos Total 30 20 10 0 Semana1 Semana2 Semana3 Semana4 Semana5 El Indicador de Evolución de Prueba Semana1 Semana2 Semana3 Semana4 Semana5 Cerrados Pendientes suspendidos 20 10 5 15 30 5 10 40 3 5 60 2 4 80 0 Total 35 50 53 67 84 90 80 70 60 Cerrados 50 Pendientes 40 suspendidos Total 30 20 10 0 Semana1 Semana2 Semana3 Semana4 Semana5 El Indicador de Evolución de Prueba Semana1 Semana2 Semana3 Semana4 Semana5 Cerrados Pendientes suspendidos 20 5 10 15 5 30 10 3 40 5 2 60 4 0 80 Total 35 50 53 67 84 90 80 70 60 Cerrados 50 Pendientes 40 suspendidos Total 30 20 10 0 Semana1 Semana2 Semana3 Semana4 Semana5 El Indicador de Evolución de Prueba Consideraciones: 1. Validez: este indicador es válido durante todo el proyecto cuando hay prueba en paralelo al desarrollo. 2. Proceso: el indicador es muy útil para detectar el síndrome del 90 %. El Indicador de Cobertura de Prueba Muestra cuanto habría que probar, cuanto se puedo probar y cuanto funciona bien. Se realiza a partir de los estados de los casos de prueba: Planificados Disponibles Ejecutados Ejecutados OK. El Indicador de Cobertura de Prueba Planificados Disponibles Ejecutados Ejecutados OK 20 20 20 20 30 25 25 25 40 35 30 25 60 55 48 40 80 75 70 66 Semana1 Semana2 Semana3 Semana4 Semana5 90 80 70 60 Planificados 50 Disponibles 40 Ejecutados Ejecutados OK 30 20 10 0 Semana1 Semana2 Semana3 Semana4 Semana5 El Indicador de Cobertura de Prueba Semana1 Semana2 Semana3 Semana4 Semana5 Planificados Disponibles Ejecutados Ejecutados OK 20 10 5 5 30 15 10 5 40 29 15 10 60 30 30 25 80 35 30 25 90 80 70 60 Planificados 50 Disponibles 40 Ejecutados Ejecutados OK 30 20 10 0 Semana1 Semana2 Semana3 Semana4 Semana5 El Indicador de Cobertura de Prueba Semana1 Semana2 Semana3 Semana4 Semana5 Semana6 Semana7 Semana8 Planificados Disponibles Ejecutados Ejecutados OK 20 10 5 5 30 15 10 5 40 29 15 10 60 30 30 25 80 35 30 25 90 50 45 35 100 90 86 80 135 130 126 126 160 140 120 100 Planificados Disponibles 80 Ejecutados 60 Ejecutados OK 40 20 0 Semana1 Semana2 Semana3 Semana4 Semana5 Semana6 Semana7 Semana8 ¿Cuánto gastaremos realmente? Ya conocemos el grado de avance (indicador de funcionalidad completa y el indicador de nivel de calidad) y tenemos menos incertidumbre sobre la fecha de fin (indicador de evolución de la prueba y el indicador de cobertura de la prueba) Ahora queremos saber cuanto costará realmente y usamos el indicador de valor agregado (Earned Value). El Indicador de Earned Value El Indicador de Earned Value La idea es usar el avance calculado por funcionalidad completa para calcular el valor agregado. 1. Alcance: es necesario separar los costos que no están asociados directamente a la construcción de software. 2. Validez: al igual que el indicador de Funcionalidad Completa, sólo aplica a la construcción, no a la estabilización. 3. Existe Margen de error: los pesos generan informacion inexacta, etc. Métricas Pruebas Unitarias Ofrece una medida de los componentes que se han probado individualmente antes de la integración con respecto al total de componentes que han sido implementados. Exhaustividad de la prueba Amplitud de cobertura de prueba: indicador de cuantos requisitos se han probado del número total de estos. Exhaustividad de la prueba Profundidad de la prueba: porcentaje de los caminos básicos independientes probados. Enlaces http://vinculando.org/articulos/socieda d_america_latina/propuesta_guia_de_m edidas_para_evaluacion_sistemas_inform acion.html Referencias McConnell, S. (1996). Rapid Develoment. Durrenberger, M. (2003). An Earned Value Tutorial. Retrieved 20/Jul/2004, from http://www.oakinc.com/pdf/EVTutorial.pdf FIN
