Estimación de costos

Juicios expertos

OLP (optimis, likely, pesimist)

Bibliografía.

Text

Gestión de costos en Ingeniería de Sistemas Software

Julio Rafael Contreras Díaz

Ingeniería de Sistemas

Gestión de costos en Ingeniería de Sistemas Software

¿Cuánto cuesta desarrollar software?

¿Qué costos hay asociados al desarrollo de un producto de software?

ESTIMACIÓN DE COSTOS

“El tiempo disponible para desarrollar el proyecto está directamente relacionado con la urgencia del cliente de tener el producto  y del dinero disponible”.

 

En términos de estimaciones de proyectos de software, Magne Jørgensen ha realizado grandes aportes en esta área con sus innumerables publicaciones.

Estimación del tamaño.

 

• Estimación del costo y del esfuerzo.
• Estimación de la programación temporal.
• Estimación de la cantidad de recursos computacionales.
• Asunción de riesgos. - Inspección y aprobación.
• Redacción de informes de estimación.

JUICIOS EXPERTOS

Dicho autor se ha interesado en la estrategia de estimación basada en el juicio de expertos, realizando una revisión de estudios detallada en su artículo “A review of studies on expert e stimation of software development effort”. Los resultados arrojados por dicho proceso de revisión sugieren que las estimaciones basadas en juicio de expertos es la modalidad más utilizada para proyectos de software.

Descripción del método:

Para poder categorizar una estimación como “experta” debe darse que dicha estimación sea realizada por una persona reconocida como experta en dicha tarea y que gran parte del proceso que se siguió para llegar a esa estimación esté basado en un proceso de razonamiento no explícito ni recuperable, es decir está basado en la “intuición”. Tal como se reportó en un estudio de predicciones de negocios, la mayoría de los métodos de estimación tienen ambos elementos: la intuición y el razonamiento explícito. De hecho, aún los métodos formales de estimación de esfuerzo en el desarrollo de sistemas de software necesitan del juicio de expertos como parámetro de entrada.

Work Breakdown Structure

Un enfoque usado ampliamente para dar soporte a los procesos de estimación es la WBS (Work Breakdown Structure ) que consiste en dividir el proyecto en paquetes discretos más pequeños que resultan más fáciles de estimar. Nos permite ver el trabajo requerido para completar el proyecto. Según el PMBOK® (Project Management Body of Knowledge) la WBS se puede usar para descomponer efectivamente el alcance del proyecto, para mejorar las estimaciones, para controlar mejor la ejecución del proyecto y para verificar más precisamente la finalización del proyecto.

Estimación Top-Down

Esta estrategia de estimación experta es usada durante la fase de iniciación/planificación de los proyectos. Al comienzo del proyecto, cuando aún no se conoce mucho sobre los requerimientos del mismo, se puede utilizar la WBS a muy alto nivel. Esta estrategia también suele llamarse Top-Down Analogy-based ya que se usa información histórica de proyectos anteriores similares que se pueden usar como punto de partida para las estimaciones de esfuerzo.

Estimación Bottom-Up

Esta estrategia de estimación experta es también conocida como descomposición aditiva. Aquí se aplica mucho mejor el enfoque de WBS a bajo nivel, descomponiendo el proyecto en paquetes lo más pequeños posible. Este enfoque lleva mucho más tiempo pero también resulta ser más preciso que el Top-Down.

Los 12 principios de la Estimación Experta

1. Evaluar la precisión en las estimaciones pero a la vez evitar la alta presión de evaluación.

 

Jørgensen sostiene que la precisión en las estimaciones tienen que formar parte de los criterios de evaluación de los proyectos pero aconseja que las fuertes presiones sobre la responsabilidad que los estimadores tiene sobre la precisión de las estimaciones así como también el sistema beneficio/castigo sean evitados.

2. Evitar metas de estimación en conflicto

Las metas en conflicto se dan cuando el proceso de estimación se ve impactado por otras metas (o evaluaciones) diferentes de la meta de precisión en sí. Jørgensen recomienda que los profesionales de software aprendan a identificar cuando una persona tiene un profundo interés por los resultados en cuyo caso no se puede esperar a que la persona produzca estimaciones realistas, aun cuando esta persona sea la que más experiencia tenga.

3. Pedir a los estimadores que justifiquen y critiquen sus estimaciones

 

La confianza que los estimadores tengan sobre sus estimaciones depende más de la cantidad de tiempo que hayan pasado trabajando en las mismas que en la precisión de las estimaciones.

4. Evitar información de estimación irrelevante y poco confiable

Este parece ser un punto de fácil entendimiento pero según Jørgensen ha habido numerosos estudios que sugieren que no siempre es el caso, que las estimaciones expertas se vean fuertemente impactadas por información irrelevante, aún cuando el estimador sabe que la información es irrelevante. En este caso, se recomienda cambiar de estimador.

5. Usar datos documentados de tareas de desarrollo

Según Jørgensen, el uso de documentación previa significa que los estimadores expertos tienen la oportunidad de aplicar una estrategia de estimación más analítica y consecuentemente menos propensa a influencias humanas y situacionales.

6. Buscar estimadores expertos con conocimientos relevantes del dominio y buenos antecedentes de estimaciones.

Existe un supuesto subyacente sobre la selección de los estimadores expertos que dice que las personas más competentes para resolver la tarea son quienes deberían estimarlas.

7. Estimar usando la estrategia de descomposición Top-Down y la de descomposición aditiva Bottom-Up independientemente

Jørgensen recomienda en su estudio, que el enfoque Bottom-up (donde obtenemos las estimaciones de las actividades de la WBS a bajo nivel) se combine con el enfoque Top-Down (donde se estima el proyecto a alto nivel, comparándolo con otros proyectos históricos similares). Considera que estos enfoques se tienen que implementar de manera independiente para evitar el efecto de anclaje, es decir, que unas estimaciones se vean altamente influenciadas por las otras , especialmente por las de proyectos anteriores.

8. Usar checklists de estimaciones

Según Jørgensen, los beneficios de usar check-lists están basados en cuatro observaciones:

- Los expertos usualmente olvidan actividades y subestiman el esfuerzo requerido para resolver eventos inesperados.

- Las estimaciones de expertos son inconsistentes, es decir, que para la misma entrada pueden resultar distintas estimaciones. Los checklists pueden incrementar la consistencia y por ende la precisión de las estimaciones expertas.

- La gente tiende a usar estrategias de estimación que requieren un mínimo de esfuerzo computacional a expensas de la precisión. Los checklists pueden llevar a los expertos a usar una estrategia de estimación más precisa.

- La gente tiene la tendencia a considerar solo las opciones que fueron presentadas y a subestimar la probabilidad de otras opciones.

 

9. Combinar estimaciones de diferentes expertos y estrategias de estimación

Según Jørgensen, hay muchas alternativas para combinar las estimaciones. El líder de proyecto puede, por ejemplo, recolectar las estimaciones de una misma tarea de diferentes expertos y luego ponderar dichas estimaciones de acuerdo con el nivel de competencia de los expertos.

 

Otra opción es que el líder de proyecto pida a los diferentes expertos que discutan sus estimaciones y se pongan de acuerdo en un valor final de estimación.

10. Evaluar la incertidumbre en las estimaciones

Una evaluación de la incertidumbre es importante para aprender de las estimaciones ya que una precisión baja en las estimaciones no es necesariamente un indicador de una baja habilidad en las estimaciones cuando el proyecto presenta un alto grado de incertidumbre. Jørgensen recomienda que la incertidumbre de una estimación sea evaluada a través de un intervalo de predicción.

Por ejemplo: el líder de proyecto puede estimar que el esfuerzo de desarrollo será de 10000 horas persona y que hay un 90% de certeza (nivel de confianza) de que el esfuerzo real caerá entre 5000 y 20000 horas persona. Luego el intervalo de horas persona [5000, 20000] es el intervalo de predicción del 90% de la estimación del esfuerzo de 10000 horas hombre.

11. Proveer feedback sobre la precisión en las estimaciones y las relaciones entre tareas

El problema con la mayor parte del feedback que se da sobre las estimaciones del esfuerzo de desarrollo de software es que toma mucho tiempo entre el punto de estimación hasta el punto en el que se brinda el feedback. Esto es desafortunado ya que se ha demostrado que el feedback inmediato mejora fuertemente el aprendizaje sobre las estimaciones y la precisión. Este principio es fácilmente aplicable en el caso de proyectos pequeños dado que no debería haber pasado más de 6 meses entre el “punto de estimación” y el “punto de feedback” del que hablaremos más abajo

12. Proveer oportunidades de entrenamiento en estimaciones

Jørgensen sugiere que las compañías de software provean oportunidades de entrenamiento a través de sus bases de proyectos completos. Una sesión de entrenamiento debería incluir estimaciones de proyectos completos basados en la información disponible al momento de la estimación (“punto de estimación”) aplicando diferentes procesos de estimación.

ANÁLISIS DE SENSIBILIDAD

En el momento de tomar decisiones sobre la herramienta financiera en la que debemos invertir nuestros ahorros, es necesario conocer algunos métodos para obtener el grado de riesgo que representa esa inversión. Existe una forma de análisis de uso frecuente en la administración financiera llamada Sensibilidad, que permite visualizar de forma inmediata las ventajas y desventajas económicas de un proyecto

 

El análisis de sensibilidad de un proyecto de inversión es una de las herramientas más sencillas de aplicar y que nos puede proporcionar la información básica para tomar una decisión acorde al grado de riesgo que decidamos asumir.

Análisis de Sensibilidad

La base para aplicar este método es identificar los posibles escenarios del proyecto de inversión, los cuales se clasifican en los siguientes:

pesimista: Es el peor panorama de la inversión, es decir, es el resultado en caso del fracaso total del proyecto.

probable: Éste sería el resultado más probable que supondríamos en el análisis de la inversión, debe ser objetivo y basado en la mayor información posible.

Optimista: Siempre existe la posibilidad de lograr más de lo que proyectamos, el escenario optimista normalmente es el que se presenta para motivar a los inversionistas a correr el riesgo.

Ejemplo:

Inversión A Inversión B Inversión Inicial $ 100,000 $ 100,000

Posibles ganancias en el periodo de Inversión

Resultado Posible:

Pesimista 2,500 0.00

Probable 50,000 50,000

Optimista 60,000 100,000

Resultados incluyendo la inversión:

Pesimista (­97,500) (­100,000)

Probable 150,000 150,000

Optimista 160,000 200,000

Bibliografía

M. Jorgensen, “A review of studies on Expert estimation of software development effort,” Journal on System and Software, Vol. 70, No. 1-2, 2004, pp. 37-60. [2]

 

M. Jorgensen, and Shepperd, “A systematic review of software development cost estimation studies,” IEEE Transactions on Software Engineering, Vol. 33, No. 1, January 2007, 2007, pp. 3-53. [3] M. Cohn, Agile Estimating and Planning. AddisonWesley, 2005. [4]

 

M. Jørgensen, U. Indahl, and D. Sjøberg, “Software effort estimation by analogy and regression toward the mean,” Journal of Systems and Software, 68(3), 2003, pp. 253-262. [5]