En el desarrollo de software , la estimación del esfuerzo es el proceso de predecir la cantidad más realista de esfuerzo (expresada en términos de horas-persona o dinero) necesaria para desarrollar o mantener el software basándose en datos incompletos, inciertos y ruidosos. Las estimaciones de esfuerzo se pueden utilizar como información para planes de proyectos, planes de iteración, presupuestos, análisis de inversiones, procesos de fijación de precios y rondas de licitación. [1] [2]
Las encuestas publicadas sobre prácticas de estimación sugieren que la estimación realizada por expertos es la estrategia dominante a la hora de estimar el esfuerzo de desarrollo de software. [3]
Por lo general, las estimaciones de esfuerzo son demasiado optimistas y existe un exceso de confianza en su precisión. El exceso de esfuerzo medio parece ser de alrededor del 30 % y no disminuye con el tiempo. Para una revisión de las encuestas sobre el error de estimación de esfuerzo, consulte [4] . Sin embargo, la medición del error de estimación es problemática; consulte Evaluación de la precisión de las estimaciones. El exceso de confianza en la precisión de las estimaciones de esfuerzo se ilustra con el hallazgo de que, en promedio, si un profesional de software tiene un 90 % de confianza o está "casi seguro" de incluir el esfuerzo real en un intervalo mínimo-máximo, la frecuencia observada de incluir el esfuerzo real es solo del 60-70 %. [5]
En la actualidad, el término "estimación del esfuerzo" se utiliza para designar conceptos diferentes, como el uso más probable del esfuerzo (valor modal), el esfuerzo que corresponde a una probabilidad del 50% de no exceder (mediana), el esfuerzo planificado, el esfuerzo presupuestado o el esfuerzo utilizado para proponer una oferta o precio al cliente. Se cree que esto es desafortunado, porque pueden surgir problemas de comunicación y porque los conceptos sirven a objetivos diferentes. [6] [7]
Los investigadores y profesionales del software han estado abordando los problemas de estimación del esfuerzo para proyectos de desarrollo de software al menos desde la década de 1960; véase, por ejemplo, el trabajo de Farr [8] [9] y Nelson. [10]
La mayor parte de la investigación se ha centrado en la construcción de modelos formales de estimación del esfuerzo de software. Los primeros modelos se basaban típicamente en análisis de regresión o se derivaban matemáticamente de teorías de otros dominios. Desde entonces, se han evaluado un gran número de enfoques de construcción de modelos, como enfoques basados en razonamiento basado en casos , árboles de clasificación y regresión , simulación , redes neuronales , estadísticas bayesianas , análisis léxico de especificaciones de requisitos, programación genética , programación lineal , modelos de producción económica, computación blanda , modelado de lógica difusa , bootstrapping estadístico y combinaciones de dos o más de estos modelos. Los métodos de estimación quizás más comunes en la actualidad son los modelos de estimación paramétrica COCOMO , SEER-SEM y SLIM. Tienen su base en la investigación de estimación realizada en los años 1970 y 1980 y desde entonces se actualizan con nuevos datos de calibración, siendo el último lanzamiento importante COCOMO II en el año 2000. Los enfoques de estimación basados en medidas de tamaño basadas en la funcionalidad, por ejemplo, puntos de función , también se basan en la investigación realizada en los años 1970 y 1980, pero se recalibran con medidas de tamaño modificadas y diferentes enfoques de conteo, como los puntos de caso de uso [11] o los puntos de objeto y los puntos de función COSMIC en los años 1990.
Hay muchas formas de categorizar los enfoques de estimación, véase por ejemplo [12] [13] . Las categorías de nivel superior son las siguientes:
A continuación se presentan ejemplos de enfoques de estimación dentro de cada categoría.
La evidencia sobre las diferencias en la precisión de las estimaciones de los distintos enfoques y modelos de estimación sugiere que no existe un "mejor enfoque" y que la precisión relativa de un enfoque o modelo en comparación con otro depende en gran medida del contexto. [18] Esto implica que diferentes organizaciones se benefician de diferentes enfoques de estimación. Los hallazgos [19] que pueden respaldar la selección de un enfoque de estimación en función de la precisión esperada de un enfoque incluyen:
El hallazgo más sólido, en muchos dominios de previsión, es que la combinación de estimaciones de fuentes independientes, preferiblemente aplicando diferentes enfoques, mejorará en promedio la precisión de la estimación. [19] [20] [21]
Es importante ser consciente de las limitaciones de cada enfoque tradicional para medir la productividad del desarrollo de software. [22]
Además, en un proceso de selección se deben tener en cuenta otros factores como la facilidad de comprensión y comunicación de los resultados de un enfoque, la facilidad de uso de un enfoque y el costo de introducción de un enfoque.
La medida más común de la precisión de la estimación promedio es el MMRE (magnitud media del error relativo), donde el MRE de cada estimación se define como:
Esta medida ha sido criticada [23] [24] [25] y existen varias medidas alternativas, como medidas más simétricas, [26] la media ponderada de cuartiles de errores relativos (WMQ) [27] y la variación media de la estimación (MVFE). [28]
La MRE no es confiable si los elementos individuales están sesgados. Se prefiere PRED(25) como medida de precisión de estimación. PRED(25) mide el porcentaje de valores predichos que están dentro del 25 por ciento del valor real.
Un error de estimación elevado no puede interpretarse automáticamente como un indicador de una capacidad de estimación baja. Entre las razones alternativas, que compiten o complementan, se incluyen el bajo control de los costes del proyecto, la alta complejidad del trabajo de desarrollo y una mayor funcionalidad entregada de la estimada originalmente. En [29] se incluye un marco para mejorar el uso y la interpretación de la medición del error de estimación.
Existen muchos factores psicológicos que podrían explicar la marcada tendencia a realizar estimaciones de esfuerzo demasiado optimistas. Estos factores son esenciales para tenerlos en cuenta incluso cuando se utilizan modelos de estimación formales, porque gran parte de la información que se aporta a estos modelos se basa en juicios. Los factores que se ha demostrado que son importantes son las ilusiones , el anclaje , la falacia de planificación y la disonancia cognitiva . [30]
La subestimación crónica del esfuerzo de desarrollo ha llevado a la acuñación y popularidad de numerosos refranes humorísticos, como referirse irónicamente a una tarea como un " pequeño asunto de programación " (cuando probablemente se requiera mucho esfuerzo) y citar leyes sobre la subestimación:
El primer 90 por ciento del código representa el primer 90 por ciento del tiempo de desarrollo. El 10 por ciento restante del código representa el otro 90 por ciento del tiempo de desarrollo. [31]
— Tom Cargill, Laboratorios Bell
Ley de Hofstadter: Siempre lleva más tiempo del esperado, incluso cuando se tiene en cuenta la Ley de Hofstadter.
Lo que un programador puede hacer en un mes, dos programadores pueden hacerlo en dos meses.
— Fred Brooks , [ cita requerida ]
{{cite book}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite book}}: CS1 maint: varios nombres: lista de autores ( enlace ) ISBN 9783540002345 , 9783540362098 .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace )