Estimación del esfuerzo de desarrollo de software - Software development effort estimation
En el desarrollo de software , la estimación del esfuerzo es el proceso de predecir la cantidad de esfuerzo más realista (expresada en términos de horas-persona o dinero) que se requiere para desarrollar o mantener un software basado en una entrada incompleta, incierta y ruidosa. Las estimaciones de esfuerzo se pueden utilizar como entrada para planes de proyectos, planes de iteración, presupuestos, análisis de inversiones, procesos de fijación de precios y rondas de licitación.
Estado de la práctica
Las encuestas publicadas sobre la práctica de la estimación sugieren que la estimación experta es la estrategia dominante al estimar el esfuerzo de desarrollo de software.
Por lo general, las estimaciones de esfuerzo son demasiado optimistas y existe una gran confianza en su precisión. El exceso de esfuerzo medio parece ser de aproximadamente un 30% y no disminuye con el tiempo. Para obtener una revisión de las encuestas de errores de estimación del esfuerzo, consulte. 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 precisión de las estimaciones de esfuerzo se ilustra con el hallazgo de que, en promedio, si un profesional del software tiene un 90% de confianza o "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%.
Actualmente el término “estimación de esfuerzo” se utiliza para denotar como diferentes conceptos tales como 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 ocurrir problemas de comunicación y porque los conceptos sirven para diferentes objetivos.
Historia
Los investigadores y profesionales del software han abordado los problemas de la 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 y Nelson.
La mayor parte de la investigación se ha centrado en la construcción de modelos formales de estimación de 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 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ísticas bayesianas , análisis léxico de especificaciones de requisitos, programación genética , programación lineal , producción económica. modelos, computación suave , 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 las décadas de 1970 y 1980 y desde entonces se actualizan con nuevos datos de calibración, siendo la última versión importante COCOMO II en el año 2000. Los enfoques de estimación se basan 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 vuelven a calibrar con medidas de tamaño modificadas y diferentes enfoques de conteo, como los puntos de casos de uso o los puntos de objeto en la década de 1990.
Enfoques de estimación
Hay muchas formas de categorizar los enfoques de estimación, ver por ejemplo. Las categorías de nivel superior son las siguientes:
- Estimación experta: El paso de cuantificación, es decir, el paso en el que se produce la estimación en base a procesos de juicio.
- Modelo de estimación formal: el paso de cuantificación se basa en procesos mecánicos, por ejemplo, el uso de una fórmula derivada de datos históricos.
- Estimación basada en combinaciones: el paso de cuantificación se basa en una combinación mecánica y de juicios de estimaciones de diferentes fuentes.
A continuación se muestran ejemplos de enfoques de estimación dentro de cada categoría.
| Enfoque de estimación | Categoría | Ejemplos de apoyo a la implementación del enfoque de estimación |
|---|---|---|
| Estimación basada en analogías | Modelo de estimación formal | ANGEL, puntos de micro función ponderados |
| Estimación basada en WBS (de abajo hacia arriba) | Estimación experta | Software de gestión de proyectos , plantillas de actividades específicas de la empresa. |
| Modelos paramétricos | Modelo de estimación formal | COCOMO , SLIM , SEER-SEM , TruePlanning para software |
| Modelos de estimación basados en tamaño | Modelo de estimación formal | Análisis de puntos de función , análisis de casos de uso , puntos de casos de uso , SSU (unidad de tamaño de software), estimación basada en puntos de historia en desarrollo de software ágil , puntos de objeto |
| Estimación de grupo | Estimación experta | Planificación de póquer , banda ancha delphi |
| Combinación mecánica | Estimación basada en combinaciones | Promedio de una estimación de esfuerzo basada en analogías y una estructura de desglose del Trabajo |
| Combinación de juicio | Estimación basada en combinaciones | Juicio de expertos basado en estimaciones de un modelo paramétrico y estimación grupal |
Selección de enfoques de estimación
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. Esto implica que diferentes organizaciones se benefician de diferentes enfoques de estimación. Los hallazgos que pueden respaldar la selección del enfoque de estimación basado en la precisión esperada de un enfoque incluyen:
- La estimación de expertos es, en promedio, al menos tan precisa como la estimación del esfuerzo basada en modelos. En particular, las situaciones con relaciones inestables e información de gran importancia no incluida en el modelo pueden sugerir el uso de una estimación experta. Esto supone, por supuesto, que se dispone de expertos con experiencia relevante.
- Los modelos de estimación formales que no se adaptan al contexto de una organización en particular pueden ser muy inexactos. En consecuencia, el uso de datos históricos propios es crucial si no se puede estar seguro de que las relaciones centrales del modelo de estimación (por ejemplo, los parámetros de la fórmula) se basan en contextos de proyectos similares.
- Los modelos de estimación formales pueden ser particularmente útiles en situaciones en las que el modelo se adapta al contexto de la organización (ya sea mediante el uso de datos históricos propios o que el modelo se deriva de proyectos y contextos similares), y es probable que las estimaciones de los expertos sean correctas. sujeto a un fuerte grado de ilusión.
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.
Es importante conocer las limitaciones de cada enfoque tradicional para medir la productividad del desarrollo de software.
Además, otros factores como la facilidad para comprender y comunicar los resultados de un enfoque, la facilidad de uso de un enfoque y el costo de la introducción de un enfoque deben considerarse en un proceso de selección.
Evaluación de la precisión de las estimaciones
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:
- MRE = | (esfuerzo real) - (esfuerzo estimado) |/(esfuerzo real)
Esta medida ha sido criticada y existen varias medidas alternativas, como medidas más simétricas, Media ponderada de los cuartiles de errores relativos (WMQ) y Variación media de la estimación (MVFE).
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 predichos 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 capacidad de estimación baja. Las razones alternativas, competitivas o complementarias incluyen el control de bajo costo del proyecto, la alta complejidad del trabajo de desarrollo y una mayor funcionalidad entregada de lo que se estimó originalmente. Se incluye un marco para mejorar el uso y la interpretación de la medición del error de estimación.
Problemas psicologicos
Hay muchos factores psicológicos que pueden explicar la fuerte tendencia hacia estimaciones de esfuerzo demasiado optimistas que deben tratarse para aumentar la precisión de las estimaciones de esfuerzo. Estos factores son esenciales incluso cuando se utilizan modelos de estimación formales, porque gran parte de la información de estos modelos se basa en juicios. Los factores que han demostrado ser importantes son: ilusiones , anclajes , falacia de planificación y disonancia cognitiva . Se puede encontrar una discusión sobre estos y otros factores en el trabajo de Jørgensen y Grimstad.
- Es fácil estimar lo que sabe.
- Es difícil estimar lo que sabes que no sabes. (incógnitas conocidas)
- Es muy difícil estimar cosas que no sabes que no sabes. (incógnitas desconocidas)
Humor
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 es probable que 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 90 por ciento restante del tiempo de desarrollo.
- Tom Cargill, Bell Labs
Ley de Hofstadter: siempre se tarda más de lo esperado, incluso si se tiene en cuenta la ley de Hofstadter.
Lo que un programador puede hacer en un mes, dos programadores pueden hacerlo en dos meses.
Además del hecho de que estimar los esfuerzos de desarrollo es difícil, vale la pena señalar que asignar más recursos no siempre ayuda.
Comparación de software de estimación de desarrollo
| Software | Presupuesto de horario | Costo estimado | Modelos de costos | Aporte | Formato de salida del informe | Lenguajes de programación admitidos | Plataformas | Costo | Licencia |
|---|---|---|---|---|---|---|---|---|---|
| AFCAA REVIC | sí | sí | REVIC | KLOC , factores de escala, impulsores de costos | propietario, texto | Ninguna | DOS | Libre | Propietario / Gratis para distribución pública |
| Vidente para el software | sí | sí | SEER-SEM | SLOC , puntos de función , casos de uso, ascendente, objeto, características | propietario, Excel, Microsoft Project, IBM Rational, Oracle Crystal Ball | Ninguna | Windows, Cualquiera ( basado en web ) | Comercial | Propiedad |
| DELGADO | sí | sí | DELGADO | Tamaño ( SLOC , puntos de función , casos de uso, etc.), limitaciones (tamaño, duración, esfuerzo, personal), factores de escala, proyectos históricos, tendencias históricas | propietario, Excel, Microsoft Project, Microsoft PowerPoint, IBM Rational, texto, HTML | Ninguna | Windows, Cualquiera ( basado en web ) | Comercial | Propiedad |
| TruePlanning | sí | sí | PRECIO | Componentes, estructuras, actividades, generadores de costos, procesos, tamaño de software funcional (líneas de código fuente (SLOC), puntos de función, puntos de conversión de casos de uso (UCCP), puntos de objetos predictivos (POP), etc.) | Excel, CAD | Ninguna | Ventanas | Comercial | Propiedad |