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 software basándose en datos incompletos, inciertos y ruidosos. Las estimaciones de esfuerzo pueden utilizarse como insumos para los 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 la práctica de la estimación sugieren que la estimación de expertos es la estrategia dominante al estimar el esfuerzo de desarrollo de software. [3]
Normalmente, las estimaciones del esfuerzo son demasiado optimistas y existe un exceso de confianza en su precisión. El esfuerzo medio superado parece ser de alrededor del 30% y no disminuye con el tiempo. Para una revisión de las encuestas de errores de estimación del 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 fuerte exceso de confianza en la exactitud de las estimaciones del 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 sólo del 60-70%. [5]
Actualmente el término “estimación del esfuerzo” se utiliza para denotar diferentes conceptos como el uso más probable del esfuerzo (valor modal), el esfuerzo que corresponde a una probabilidad del 50% de no superarse (mediana), el esfuerzo planeado, 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 para 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 desde al menos 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 del 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 ha 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ística bayesiana , análisis léxico de especificaciones de requisitos, programación genética , programación lineal , producción económica. modelos, informática suave , modelado de lógica difusa , arranque 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étricos 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 la última publicación 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, función puntos , también se basa en investigaciones realizadas en las décadas de 1970 y 1980, pero se recalibran con medidas de tamaño modificadas y diferentes enfoques de conteo, como los puntos de casos de uso [11] o puntos de objeto y puntos de función COSMIC en la década de 1990.
Hay muchas formas de categorizar los enfoques de estimación; consulte, por ejemplo. [12] [13] Las categorías de nivel superior son las siguientes:
A continuación se muestran ejemplos de enfoques de estimación dentro de cada categoría.
La evidencia sobre las diferencias en la precisión de la estimación de diferentes 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 basado en la precisión esperada de un enfoque incluyen:
El hallazgo más sólido, en muchos dominios de pronóstico, 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 el proceso de selección se deben considerar 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 su introducción.
La medida más común de la precisión promedio de la estimación 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] Media ponderada de cuartiles de errores relativos (WMQ) [27] y variación media de la estimación (MVFE). ). [28]
MRE no es confiable si los elementos individuales están sesgados. Se prefiere PRED(25) como medida de precisión de la estimación. PRED(25) mide el porcentaje de valores previstos que están dentro del 25 por ciento del valor real.
Un error de estimación alto no puede interpretarse automáticamente como un indicador de una capacidad de estimación baja. Las razones alternativas, competitivas o complementarias incluyen el bajo control de costos del proyecto, la alta complejidad del trabajo de desarrollo y una mayor funcionalidad entregada de lo estimado originalmente. Se incluye un marco para mejorar el uso y la interpretación de la medición del error de estimación. [29]
Hay muchos factores psicológicos que podrían explicar la fuerte tendencia hacia estimaciones de esfuerzo excesivamente optimistas. Es esencial considerar estos factores incluso cuando se utilizan modelos de estimación formales, porque gran parte de los datos de entrada de estos modelos se basan 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 adagios humorísticos, como referirse irónicamente a una tarea como una " pequeña cuestión 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 si se tiene en cuenta la Ley de Hofstadter.
Lo que un programador puede hacer en un mes, dos programadores lo pueden hacer en dos meses.
—Fred Brooks
{{cite book}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite web}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite web}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite book}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ) ISBN 9783540002345 , 9783540362098 .{{cite web}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite web}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite web}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite web}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )