11
2015
Resultados del Estudio sobre Medición del Tamaño del Software 2014
Léelo aprox. en 10:21 minutos.
Durante los meses de octubre y noviembre del año pasado, realizamos un estudio sobre la Medición del Tamaño del Software. La participación fue notable y es hora de analizar los resultados de las preguntas que lanzamos.
Durante los dos meses de duración del estudio, hemos recibido un total de 348 respuestas. Estas respuestas han venido de todas partes del mundo, agrupándolas en las siguientes zonas: Europa, América del Norte, América Central, América del Sur y Asia.
El desglose por zona es el siguiente:
- América Central: 20
- América del Norte: 57
- América del Sur: 193
- Asia: 1
- Europa: 77
En este artículo voy a presentar los resultados totales sin diferenciar por zonas para tener una idea de las prácticas generales a nivel global.
Voy a empezar por el final porque creo que es interesante ver lo que se extrae y luego que veamos los datos de los cuales se obtienen estos resultados, si no nos perdemos en un mare magnum de cifras.
Las principales conclusiones que podemos extraer de este estudio son:
- Se confia demasiado en la experiencia para medir. Se deja demasiado a la experiencia, no se utiliza un método reglado con lo que aparecen todos los problemas derivados de ello: las estimaciones no coinciden, cuando nos piden justificación no podemos argumentar con datos de un método, si nos presionan cambiamos la valoración, etc.
Incluso nos evita mejorar ya que al no seguir un método los mediciones pueden no ser consistentes ni para la misma persona, ya que su experiencia va cambiando. - Las mediciones no son homogéneas. No existe un método común de medición / estimación. La experiencia es el más usado y ya de por sí no es un método homogéneo: nadie tiene la misma experiencia que otro.
El resto de métodos están muy segmentados lo que dificulta la posibilidad de compararnos con el resto para ver si realmente lo estamos haciendo bien o para buscar quién es el que lo hace mejor. - No se comprueban los datos de las mediciones. No se realizan auditorías de las mediciones lo que unido a que se mide por la experiencia da lugar a que exista una incertidumbre en lo que se mide / estima. No podemos confiar en datos que surgen por nuestra intuición y que además nadie los puede corroborar.
- La línea base no está automatizada. No se gestiona de manera automatizada el resultado de las mediciones por lo que el aprovechamiento de la información obtenida es pobre o inexistente.
- Falta de lecciones aprendidas dentro del proceso. Cómo corolario del punto anterior, como la información que obtenemos no se procesa adecuadamente la mejora del proceso es deficiente (cuando existe un proceso).
- Se entiende la aplicabilidad y beneficios de las mediciones. La respuesta más repartida ha sido la correspondiente al objetivo de las estimaciones / mediciones. Se tiene clara la importancia y aplicabilidad de la medición pero no se tiene tan claro un método a usar.
- No se mide lo suficiente. Dada la importancia que se le da al objetivo de las mediciones el número de personas que afirman realizar mediciones actualmente es muy pobre. Un dato a reflexionar por todos.
Veamos las cuestiones relevantes una a una y los resultados obtenidos.
APRENDE A MEDIR Y ESTIMAR PROYECTOS DE SOFTWARE
- ¿Por qué? Aprende a justificar porque se deben medir los proyectos de software
- ¿Para qué? Aprende para que sirve una medición y los beneficios que obtienes con ellas.
- ¿Cómo? Aprende métodos de estimación y medición como: COCOMO 81 y COCOMO 2000, Putnam, Estimación de 3 puntos, Puntos Función IFPUG, NESMA, MKII, COSMIC, SiFP, Puntos de Casos de Uso, SNAP, T-Shirt y un largo etc.
Uno de los datos más interesantes a obtener en nuestro estudio, es cúal es el método más utilizado para medir el software y creo que no nos va a sorprender a nadie: La Experiencia.
Como puedes ver a continuación, la experiencia (o a ojo) obtiene más del 46% de los votos. Desde mi punto de vista este resultado explica la sensación general de que las estimaciones no son correctas, siempre están hinchadas y no se acierta: la experiencia no es un criterio objetivo y depende de cada individuo.
La utilización de un método homogeniza los resultados y permite realizar formaciones/capacitaciones para que la gente sepa medir de la misma forma y con las mismas condiciones. Además, permite justificar el resultado y evita la necesidad de “un colchón de seguridad”.
El Gráfico es interactivo. Sitúa el cursor encima para ver los datos.
El segundo método más usado con más de un 13% es el método de Puntos de Casos de Uso demostrando la difusión de este método cuando se elabora el diseño funcional a través de casos de uso.
Destacable también las métodos ágiles de estimación como son los Puntos de Historia y el Planning Poker sumando entre los dos métodos más de un 12%.
El primer método de puntos función es el método de IFPUG con casi un 6% de los votos, dando un idea de la implantación de esta métrica.
También a destacar la aparición en la muestra del método SNAP de IFPUG que forma junto con el método de IFPUG la medición TOTAL del Software, aunque sólo con un 2,4% pero al ser un método reciente es bastante destacable.
Otra de las cuestiones importantes que preguntábamos era para qué se utilizaban las mediciones, qué objetivo tenían dentro de la empresa y el resultado no puede ser más repartido.
Más del 24% de los votos indican que el objetivo principal de las mediciones es la estimación de proyectos de desarrollo, es decir cuanto costará desarrollar un proyecto y/o cuanto tiempo durará.
Siguiéndole de cerca están Planificación con casi un 20%, Presupuestación con casi un 16% y Evaluación de la productividad interna con un 13,5% .
El Gráfico es interactivo. Sitúa el cursor encima para ver los datos.
Aqui no hay duda más de 61% de los encuestados responde que el propio equipo de desarrollo (personal interno) es el que realiza la medición del proyecto.
También importante destacar que con un 22% de los votos está la realización de las mediciones por un equipo centralizado (personal interno) es decir tener un equipo de especialista en la empresa que se encargan de realizar las mediciones, esto nos permite homogeneizar las mediciones.
El Gráfico es interactivo. Sitúa el cursor encima para ver los datos.
Una de las mejores prácticas para asegurar la calidad de las mediciones es la auditoría de las mismas.
Aquí vemos que aunque es lo recomendado el 58% no audita las mediciones que realiza pese a utilizar los valores obtenidos para presupuestación, planificación, etc.
Eso sí, dentro de los que realizan auditorías tienen a un equipo centralizado que se encarga de ello, en la mayor parte de los casos (35% del total).
El Gráfico es interactivo. Sitúa el cursor encima para ver los datos.
Otra deficiencia que vemos es la gestión de la información obtenida de las valoraciones. Una vez medimos, gestionar esa información es importante ya que es lo que nos permite mejorar.
Casi el 55% de los encuestados indica que utiliza hojas excel completadas manualmente, un 33,7% indica que tiene un sistema de gestión interno de la empresa para gestionarlas y sólo el 9,9% utiliza una herramienta comercial específica para ello.
Si no automatizamos esa información es más dificil mejorar el proceso.
El Gráfico es interactivo. Sitúa el cursor encima para ver los datos.
Este dato es de los más sorprendentes, sobre todo si tenemos en cuenta el objetivo que se le asigna a las mediciones: sólo en el 51% de los encuestados realiza mediciones actualmente.
El resto o no está haciendo mediciones, sólo a veces o lo que es más preocupante, no lo sabe (5%).
El Gráfico es interactivo. Sitúa el cursor encima para ver los datos.
Y hasta aquí los resultados de nuestro estudio.
¿Te han sorprendido? ¡Déjanos un comentario!
Consigue Más de 100 Libros gratis
Suscríbete a nuestro newsletter por email y conseguirás Más de 100 Libros Gratis sobre Gestión de Proyectos, Innovación, Emprendimiento, Empresa, etc. directamente en tu correo
Últimos artículos de Julián Gómez (ver todos)
- El Último vídeo del viernes del año: Vuela como un dragón - hace 4 meses
- Ultimo video del viernes del año: Sé diferente - hace 1 año
- Vídeo del viernes: Kadenko, una luz en la navidad - hace 1 año
Otros artículos que te pueden interesar
4 Comentarios+ Escribir Comentario
¿Te ha gustado? Pues sólo cuesta un Comentario. ¡Gracias por adelantado!
Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.
Hola,
me alegra que ya se hagan disponibles los resultados de la encuesta.
Tengo un comentario al respecto. Aunque era de esperar que COCOMO II pierda fuerza, sobretodo con la moda ágil, creo que los malos resultados que recibe pueden ser debidos también a que se ha incluido COCOMO II en una encuesta de medición del tamaño, cuando esta herramienta realmente tiene como objetivo la estimación del esfuerzo (a partir del tamaño)…
un saludo,
pablo.
Si como bien indicas Pablo puede que haya algo de solapamiento con Líneas de código e incluso con Puntos Función (ambos se pueden utilizar de entrada) pero creo que hay más de lo que apuntas al principio : la Agilidad comiendo el terreno y otros métodos más basados en nuestro caso particular.
Gracias por tu comentario!
Interesantes resultados; existen algún estudio sobre métodos de medición para proyectos diferentes de sofware?
Winston, he estado buscando información al respecto y no hay nada disponible.
¿En que disciplina estarías interesado?
Gracias.