Desarrollo de un código de métricas para empresas desarrolladoras de software pequeñas AUTORES: Raúl V. González Carrión. Henry X. Hernández Rendón. Guayaquil, 2006

2 Agenda Introducción Desarrollo Proceso Resultados Conclusiones, recomendaciones y otros

3 INTRODUCCIÓN Antecedentes Estudios realizados en el Ecuador: Primer estudio exploratorio y la AESOFT. Segundo estudio, Vlir-ESPOL Tercer estudio, Vlir-ESPOL “Las empresas desarrolladoras de software estiman la mayoría de los datos” Plan piloto. ¿Por qué es importante la aplicación de este proyecto?

4 INTRODUCCIÓN Hipótesis “Cuanto mejor es el tiempo empleado en la planificación, menor es el error en la estimación del tiempo” “Cuanto mayor es el número de inspecciones en las etapas de diseño y de implementación, más pequeño es el número de los errores en el producto final entregado a los clientes”

5 INTRODUCCIÓN Población objetivo Empresas tuvieran similares características: Líneas de negocios tengan el desarrollo de software y/o la provisión de servicios vinculados al desarrollo del mismo y su operación. Magnitud de las empresas:  Pequeñas: 10 empleados o menos.  Medianas: entre 10 y 50 empleados.  Grandes: 50 empleados o más. Duración de sus proyectos:  Pequeños: 1 y 6 meses.  Medianos: 7 y 15 meses.  Grandes: más de 15 meses. Proceso siga la metodología denominada “cascada”. “Guía estudios anteriores del Proyecto VLIR-ESPOL realizados en los años 2003 y 2005”

6 INTRODUCCIÓN Muestra seleccionada Datos facilitados por el VLIR - ESPOL 200 empresas.  Quito, Guayaquil y Cuenca. En el mes de mayo se tomó un muestra de 20 empresas (principio estadístico). Se llamó y/o visitó 73 empresas. Número de empresas Resultado de la indagación 1No desarrolla. 3Manifestaron interés, pero al final nunca participaron 4Quedaron pendientes de confirmar (nunca confirmaron) 7No tienen proyecto para aplicar 7Aplicando otros proyecto de investigación 13No aceptaron participar (rechazo explícito) 18Nunca se pudo localizar a la persona encargada 20Aceptaron participar

7 DESARROLLO Instrumento de medición

8 Se define como instrumento de medición a la herramienta de la que nos servimos para lograr el objetivo fundamental de la presente tesis que es obtener métricas de empresas desarrolladoras de software, cuyo mecanismo de funcionamiento se apoya en el levantamiento de información, cálculo, y evaluación de los resultados obtenidos a fin de inferir acciones y recomendaciones tendentes a optimizar los resultados en esta parte de la industria informática.

9 El Instrumento de Medición con el cual se inició el presente estudio, fue propuesto por una tesis anterior (Plan piloto). El fundamento teórico de dicho instrumento es el “Proceso de medición dirigido a objetivo” (Proceso GQIM). Se ha desarrollado un diagrama GQIM que consta de 7 niveles: NivelDescripción 1Objetivo del negocio. 2Sub. Objetivo del negocio. 3Objetivo de medición. 4Preguntas. 5Indicadores. 6Datos. 7Plantillas. DESARROLLO Instrumento de medición

10 A mediados de junio existió un corte a la información generada por el “Plan Piloto”. Nos fue proporcionado el “Plan de Métricas” con las respectivas plantillas para el levantamiento de información. (ver figuras) DESARROLLO Información proporcionada

11 DESARROLLO Indicadores de medición Indicador 1 Satisfacci ó n del Cliente y Satisfacci ó n del Usuario V.S. Esfuerzo del cliente y esfuerzo del usuario Indicador 2Porcentaje de error en la estimaci ó n del esfuerzo Indicador 3 Porcentaje del esfuerzo por persona en las diferentes fases Indicador 4 Porcentaje de esfuerzo empleado en documentación Indicador 5Complejidad del Negocio y Complejidad T é cnica Indicador 6Porcentaje de error en la estimaci ó n del costo Indicador 7Costo promedio hora real Indicador 8 Porcentaje de inspecciones realizadas por fases y Porcentaje de inspecciones realizadas en el proyecto Indicador 9Porcentaje de variaci ó n de los requerimientos

12 DESARROLLO Indicadores de medición Indicador 10Complejidad del C ó digo Fuente Indicador 11 Indicador ponderado de la complejidad y demora del aprendizaje Indicador 12Tama ñ o de los componentes de software Indicador 13Ocurrencia de defectos y fallas por fases Indicador 14 Tipo de defectos y fallas m á s ocurrentes identificados por su severidad Indicador 15 Porcentaje del tiempo utilizado en correcci ó n de defectos y fallas Indicador 16Eficiencia en atenci ó n de defectos y fallas Indicador 17Promedio de defectos por hora de programaci ó n

13 Proceso de aplicación Ciudades de Quito y Guayaquil, de Junio a Septiembre. Este proceso demandó:  Desarrollo de una herramienta que optimice la recopilación de datos;  Creación y validación del plan de capacitación; y,  El diagrama resumen del proceso GQIM. Sesiones  Sesión 1: “Presentación y explicación del proyecto”  Sesión 2: “Explicación de las plantillas de recolección de datos”.  Sesión 3: “Verificación de datos recolectados y recepción de sugerencias”  Sesión 4: “Monitoreo”

14 Indicador: Satisfacción del Cliente y Satisfacción del Usuario versus Esfuerzo del cliente y esfuerzo del usuario 6.5% al 10%, mayor participación mayor satisfacción 1.5% menor participación menor satisfacción 5% al 6%, mayor participación mayor satisfacción Más del 6.5% baja la satisfacción 2% al 5%, menor participación menor satisfacción

15 Indicador: Porcentaje de error en la estimación del esfuerzo Promedio = - 5.5% Estimaron menos tiempo = 16 proyectos Sesgos = Proyecto 15 (Subestimó) y Proyecto 3 y 11 (Sobrestimaron) Proyecto 7 y 19

16 Indicador: Porcentaje de esfuerzo empleado en documentación Promedio = 7.9% Sesgos altos = proyectos 3 con 13.1%, 6 con 12.7%, 15 con 12.1% y 4 con 11.1% Sesgos bajos = proyectos 9 con 2.5%, 11 con 1.9% y 8 con 1.4%

17 Indicador: Complejidad del Negocio y Complejidad Técnica Negocios complejos = mayor parte Técnicamente complejos = menor proporción Alta complejidad = solo 1 Muy simples = ninguno

18 Indicador: Costo promedio hora real Promedio = $ 4.12 Sesgos altos = Proyecto 3 con $ 9.20 Sesgos bajos = Proyecto 11 con $ CORPEI encuesta salarial por Price Waterhouse:  Ingeniero / Analista de Sistemas Senior = $6.18 (calculado de 160 horas).  Ingeniero / Analista de Sistemas Junior = $3.80 (calculado de 160 horas). Promedio CORPEI = $ 4.99 guarda relación con el obtenido.

19 Indicador: Porcentaje de inspecciones realizadas por fases Porcentaje consolidado de las inspecciones en las fases

20 Indicador: Porcentaje de variación de los requerimientos. Promedio: 91% de los requerimientos iniciales fueron ejecutados. 4% fueron modificados 5% fueron nuevos requerimientos.

21 Indicador: Tipo de defectos y fallas más ocurrentes (Identificados por severidad) Porcentaje consolidado de defectos respecto a las tareas, identificados por su severidad Porcentaje consolidado de fallas respecto a las tareas, identificadas por su severidad

22 Indicador: Porcentaje de tiempo utilizado en corrección de defectos y fallas. Promedio = 0.7% Sesgo alto = 1 proyecto, este es: 8 con 5.6% Sesgos bajos = 12 proyectos, estos son: 3, 4, 6, 9, 10, 12, 16, 17, 18, 19 y 20 que no registraron defecto alguno Porcentaje de tiempo utilizado en corrección de defectos otro gráfico

23 Indicador: Porcentaje de tiempo utilizado en corrección de defectos y fallas. Promedio = 3.7% Sesgos altos = 4 proyectos, estos son: 5 con 10.2%, 10 con 9.3%, 8 con 9.1% y 4 con 7.8% Sesgos bajos = 3 proyectos, estos son: 2 con 1.1%, 18 con 1.8% y 9 con 1.9% Porcentaje de tiempo utilizado en corrección de fallas

24 Indicador: Eficiencia en atención de defectos y fallas. Promedio = 0.2 días, aprox. 5 horas 16 proyectos no presentan tiempo de respuesta, mencionando que 12 no presentaron defectos. Eficiencia en atención de defectos otro gráfico

25 Indicador: Eficiencia en atención de defectos y fallas. Promedio = 1 día 5 proyectos están por arriba 7 proyectos están por abajo 8 son iguales Eficiencia en atención de fallas

26 Hipótesis 1 “Cuanto mejor es el tiempo empleado en la planificación, menor es el error en la estimación del tiempo” Análisis de Correlación r = 0.68 Conclusión: Cuanto mejor es el tiempo empleado en la planificación, menor es el error en la estimación del tiempo, con un coeficiente de correlación igual a 0,68 HIPÓTESIS 1

27 Hipótesis 2 “Cuanto mayor es el número de inspecciones en las etapas de diseño y de implementación, más pequeño es el número de los errores en el producto final entregado a los clientes” Análisis de Correlación r = Conclusión: Cuanto mayor es el porcentaje de esfuerzo en inspecciones en fases iniciales, más pequeño es el porcentaje de esfuerzo empleado en solucionar las fallas, con un coeficiente de correlación igual a -0,85.

28 Conclusiones Sobre los indicadores  Menor participación del usuario menor satisfacción.  Mayor participación cliente la satisfacción decrece.  Mala estimación del costo y tiempo se debe a escaso esfuerzo en planificación.  No existe cultura de documentación.  La realidad del mercado salarial ha evidenciado buenos desarrolladores a un costo hora relativamente bajo, particularmente en empresas pequeñas.  Costo promedio hora varia según la categoría de recursos participantes en los proyectos.  La variación porcentual en los requerimientos proporciona información de alta utilidad práctica para futuros proyectos.

29 Conclusiones  Que para realizar este tipo de estudios es necesario además de un mesurado análisis, una prudente investigación, unido a una actitud perseverante y persistente, ya que las empresas ecuatorianas si bien están interesadas en este tipo de proyectos, desafortunadamente no disponen de tiempo ni recursos para coadyuvar a dichos estudios.

30 Recomendaciones Sobre aspectos generales  Diferenciar al cliente y al usuario.  Dedicar una considerable cantidad de tiempo a la documentación de los procesos.  Realizar una buena planificación de los proyectos.  Realizar un adecuado levantamiento de información, una correcta coordinación con los clientes y/o usuarios.

31 Fotos

32 Fotos

33 Fotos

34 Fotos

35 Preguntas

36 Muchas Gracias!!!