Estimación del esfuerzo del software

La estimación del esfuerzo y en consecuencia del costo, así como el tiempo, que se empleará en el desarrollo de un producto software es un aspecto directamente relacionado con el éxito del proyecto. Según Leung y Fan, en el artículo publicado el año 2002 titulado “Estimación del costo software”, la estimación del costo de desarrollo software, y por tanto la exactitud de esta, se ha convertido en un aspecto crucial tanto para la compañía desarrolladora del proyecto como para el cliente, el cual espera que el costo del software coincida lo más posible con la estimación. Una infravaloración en la estimación del costo del software puede suponer que la planificación del proyecto acordado acabe sufriendo más problemas de los esperados inicialmente y una disminución de la calidad o retrasos en la fecha de entrega. Por el contrario, una sobrevaloración puede suponer un exceso de recursos reservados al proyecto, lo que conlleva un presupuesto excesivo del proyecto y, por tanto, una reducción de la competitividad de la compañía ante la asignación de nuevos proyectos. Una estimación adecuada permite a la compañía desarrolladora del software una mejor planificación de los proyectos que administra, así como una mejor asignación de los recursos necesarios para cada proyecto. Además permite valorar el impacto ante cambios en el plan de desarrollo del proyecto. En consecuencia, la exactitud de las estimaciones toma un cariz bastante importante al interior de la ingeniería del software.

Mendes, en el artículo publicado el año 2007 titulado “Uso de una red bayesiana para la estimación del esfuerzo Web”, menciona que los modelos de estimación del costo de desarrollo software se basan en un conjunto de variables. Estas variables se denominan factores, como el costo, el esfuerzo o el tamaño entre otros. Cada modelo basa sus estimaciones en un conjunto propio de factores que pueden estar relacionados entre sí. La naturaleza de las relaciones causales entre los factores implica cierta incertidumbre, es decir no son deterministas. Esto quiere decir que, suponiendo que exista una relación entre el esfuerzo de desarrollo y la calidad del software, no es necesariamente cierto que aumentando el esfuerzo se consiga una mejoría en la calidad, aunque si es probable que suceda. En palabras de Morasca, en el artículo escrito el año 2001 titulado “Medidas del software”, para la gestión eficiente y efectiva de los proyectos de desarrollo o mantenimiento de software es necesario disponer de una medida confiable del tamaño de los artefactos de software en cada fase y especialmente de aquéllos producidos en las primeras etapas del desarrollo. El Centro de Soporte a la tecnología del Software, en el documento publicado el año 2000 titulado “Líneas guía para la exitosa adquisición y administración de sistemas intensivos de software”, complementa mencionando que el tamaño es un factor clave para la estimación de esfuerzo, personal, cronograma y costo de un proyecto; la deficiente estimación de tamaño es una de las causas de los desfasajes en el costo y el cronograma de un proyecto.

El año 1979 Albrecht, en el artículo titulado “Aplicación de medidas para el desarrollo de la productividad”, introdujo el “Análisis de Puntos Función” con el objetivo de medir la productividad en el desarrollo de software para sistemas de información de gestión. Según el Grupo Internacional de Usuarios de Puntos Función, en el “Manual para la medición de puntos de función” publicado el año 2000, el análisis de puntos función es un método estándar para medir el desarrollo de software desde el punto de vista del usuario, es independiente del lenguaje de programación, metodología de desarrollo y tecnología usados para desarrollar la aplicación. Esta técnica, ampliamente usada en la industria, puede ser aplicada desde la fase de especificación de requerimientos y durante las siguientes fases del desarrollo. En palabras de Meli y Santillo, en el artículo escrito el año 1999 titulado “Métodos de estimación de puntos de función: Una vista comparativa”, existen dos situaciones en las que no es posible el conteo de puntos función: La primera ocurre en las fases más tempranas, antes de la definición de los requerimientos, en las cuales no se puede aplicar el método estándar; la segunda, cuando la documentación, el tiempo o los recursos requeridos no están disponibles. En ambos casos se debe utilizar un método de estimación de los puntos de función.

Peters, en el documento publicado el año 1999 titulado “Estimación de proyectos software”, resalta que en las etapas más tempranas de un proyecto, a veces, lo único disponible es una descripción verbal o un bosquejo. Sin embargo, la falta de una especificación formal no debería ser un obstáculo para la estimación inicial de un proyecto. Ahora bien, para determinar el mínimo de información necesaria para hacer una estimación de tamaño, la experiencia demuestra que las estimaciones muy tempranas son propensas a errores debido al escaso conocimiento disponible sobre el software a construir, pero, ¿cuál es el error aceptable para una estimación temprana? ¿Es suficiente con esa estimación inicial? En el contexto de las estimaciones, las buenas prácticas indican que, aún cuando el error de una estimación estuviera dentro del rango admisible, es esencial comunicar el grado de incertidumbre de la estimación y repetir la estimación del proyecto en cuanto se disponga de más información. Existen múltiples propuestas para estimar los puntos de función, sin embargo, se han observado los siguientes problemas: Las técnicas basadas en especificaciones de requerimientos requieren un nivel de detalle en la documentación que frecuentemente no está disponible en las fases más tempranas de un proyecto de software. Algunas técnicas basadas en modelos estadísticos formulados a partir de datos históricos de proyectos requieren, como mínimo, el modelo de datos del sistema. Algunas propuestas no especifican la exactitud de las estimaciones; en otros casos, el error de las estimaciones es significativo. Existen escasos enfoques aplicables a los artefactos producidos en la elicitación de requerimientos.