A la hora de planificar el desarrollo de un proyecto informático, una de las tareas fundamentales que ha de hacer todo gestor de proyectos es estimar los recursos y esfuerzos necesarios para llevarlo a cabo.
Pero ¿qué es una estimación? En el caso que nos atañe, una estimación es el proceso por el cual se predice el personal, coste, tiempo y esfuerzo que será necesario para llevar a cabo el proyecto, incluyendo todas sus actividades y que dará lugar a los resultados esperamos en el mismo.
Como puedes pensar, esta no es una tarea sencilla. Por muy bien que estén definidas los pasos que vamos a dar, la metodología que se usará o cual debería ser el resultado final, estimar siempre es uno de los aspectos más complicados al inicio del proyecto y esta estimación mucha veces está determinada por la capacidad del «estimador», normalmente el jefe de proyecto, aunque no tiene por qué. Los factores tradicionalmente más determinantes y que causan más desviaciones respecto a la estimación son:
- Complejidad y tamaño del proyecto.
- Falta de experiencia del personal.
- Falta o fallos en la documentación.
También es importante determinar el momento en el que se hará la estimación. El momento ideal es una vez que se hayan definido los requisitos del sistema y, por tanto, se conoce, o al menos tenemos una primera aproximación, del alcance del proyecto. No obstante, también es conveniente re-estimar el proyecto periódicamente.
Para llevar a cabo esta estimación, en planificación software se utilizan las denominadas «métricas», que son medidas para conseguir estimar el coste de llevar a cabo un componente (entendido en el sentido amplio de la palabra).
Algunas de estas métricas son:
Métricas de complejidad (textuales)
Están Orientadas en evaluar la facilidad de mantenimiento de un software. También se denominan de caja blanca.
- Técnica de Halstead: Utiliza el número de operadores y operandos distintos y sus ocurrencias que aparecen en el programa para hacer cálculos.
- Técnica de McCabe (utiliza el concepto de complejidad ciclomática): Se basa en la teoría de grafos, utilizando el número de regiones (áreas cerradas) de un grafo.
Complejidad ciclomática = E(Aristas) – N(Nodos)+2
Métricas de fiabilidad
- Tiempo medio de fallos
- Tiempo medio de reparación
- Tiempo medio entre fallos
Métricas de proyecto o productividad
Este tipo de métricas se basan en calcular el número de horas por persona necesarias para llevar a cabo el proyecto. Se dividen en orientadas al tamaño, teoricos y orientadas a funcionalidad.
Métricas Orientadas al tamaño
Se basan en calcular el esfuerzo en base a la longitud del software, tienen la ventaja de ser algo más sencillos de
- Métodos empíricos o estadísticos. Deducen el esfuerzo a partir de KLOC (Miles de líneas de código) y coeficientes empíricos.Ejemplos:
- Modelo de Bailey y Basili. Utiliza lineas de código sin contar los comentarios.
- Modelo de Walston y Felix. Utiliza esfuerzo, duración, personas, documentación.
- COCOMO (Constructive Cost Model de Bohem). Utiliza una fórmula para obtener el tiempo de desarrollo y el esfuerzo en hombres/mes.Dependiendo del tipo de proyecto se modifican unos valores de la fórmula:
- Orgánico: Proyectos pequeños y sencillos con equipo estable. Buena experiencia y con requerimientos poco rígidos.
- Semiacoplado: Proyectos de complejidad media, equipos con distintos niveles de experiencia.
- Empotrado: Proyectos con fuertes restricciones. Problema único y muy difícil basarse en la experiencia.
Además tiene 3 modelos: Básico (estimación rápida en base a las lineas de código), Intermedio (en base a atributos en todo el ciclo de vida) y Avanzado (en base a atributos en todo el ciclo de vida)
- Modelos teóricos. Este tipo de estimaciones no utilizan datos históricos, un ejemplo puede ser SLIM (Software LifeCycle Model) de PUTNAM.
Métricas Orientadas a funcionalidad
Ejemplos:
- Puntos de Función (Albretch)
- Mark II (Symmons). También es de puntos función.
- Bang de De Marco
Deja una respuesta