4) Metodo de Estimación de Costos de Construcción

ESTIMACIÓN DE COSTOS

INTRODUCCION

Todo proyecto de ingeniería de software debe partir con un buen plan, pero lamentablemente, la planificación es una tarea nada trivial. Uno de los aspectos que dificultan la labor de administradores y jefes de proyecto en torno a la planificación es la difícil tarea de realizar una estimación de costos y plazos realista.
La estimación es más arte que ciencia; también es parte de la etapa de la planificación y algunas actividades de la ingeniería. La diferencia en la estimación de costos entre ingeniería de software y otras disciplinas es que en ingeniería de software lo principal para las personas es el costo; y en otras disciplinas el costo de las cosas materiales depende de la actividad.
Existen técnicas para la estimación de costos, pero para ello se requiere experiencia, acceso a una buena información histórica y coraje para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.
El manejador de costo principal para un proyecto de desarrollo de software es sin duda el tamaño del producto. La medida del tamaño debe ser tal que esté en relación directa con el esfuerzo de desarrollo, por lo que las métricas de tamaño tratan de considerar todos los aspectos que influyen en el costo, como tecnología, tipos de recursos y complejidad.

MÉTRICAS PARA LA PRODUCTIVIDAD Y CALIDAD DEL SOFTWARE

La medición es esencial para cualquier disciplina de ingeniería y la ingeniería de software no es una excepción.
Las métricas de software se refieren aun amplio rango de medidas para el software de computadoras dentro del contexto de la planificación del proyecto de software, las métricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a la estimación de costos.
Las mediciones en el mundo físico pueden ser catalogadas en dos campos: medidas directas (por ej. La longitud de un tornillo), y medidas indirectas (por ej. Calidad de tornillos producidos, medida por la cuenta de los tornillos rechazados). Las métricas de software pueden ser catalogadas de forma parecida.
Se puede clasificar en:
Métricas de productividad, se centran en el rendimiento del proceso de la ingeniería de software.
Métricas de Calidad, proporcionan una indicación de cómo se ajusta el software, a los requerimientos implícitos y explícitos del cliente.
Métricas Técnicas, se centran en el carácter del software mas que en el proceso, a través del cual el software a sido desarrollado.
Métricas Orientadas al tamaño, son utilizadas para obtener medidas directas del resultado y la calidad de la ingeniería del software.
Métricas Orientadas a la Función, son medidas indirectas del software y del proceso por el cual se desarrollará; se centran en la funcionalidad o utilidad del programa (Puntos de Función)
Métricas Orientadas a la persona, consiguen información sobre la forma en que la gente desarrolla software de computadora y sobre el punto de vista humano de la efectividad de las herramientas y métodos.

ESTIMACION DEL PROYECTO DE SOFTWARE

Para realizar estimaciones seguras de coste y esfuerzo surge un numero de posible de opciones como:
Retrasar la estimación mas adelante en el proyecto (obviamente se puede hacer una estimación cien por ciento fiable después de completar el proyecto)
Utilizar "técnicas de descomposición " relativamente simples para generar las estimaciones del proyecto de software (por ej. Estimación LDC y PF)
Desarrollar un modelo empírico para el coste y el esfuerzo de software.
Adquirir una o más herramientas automáticas de estimación.
Desdichadamente la primera opción, aunque atractiva no es practica, porque las estimaciones del coste deben ser proporcionadas de antemano. Las tres opciones restantes son aproximaciones viables para la estimación del proyecto de software. Las técnicas de descomposición utilizan una aproximación de "divide y vencerás " para la estimación del proyecto de software. Los modelos de estimación empíricos pueden utilizarse para completar las técnicas de descomposición y ofrecer una aproximación de la estimación potencialmente evaluable por ella misma. Las herramientas automáticas de estimación implementan una o mas técnicas de descomposición o modelos empíricos.

MODELOS DE ESTIMACIÓN EMPÍRICA

Un modelo de estimación para el software por computadora utiliza formulas derivadas empíricamente para predecir los datos.
Los datos empíricos que soportan la mayoría de los modelos se obtienen de una muestra limitada de proyectos. Tomando en cuenta los recursos se tienen los modelos recursos y consisten en una o más ecuaciones obtenidas empíricamente que predicen el esfuerzo (personas-mes), la duración del proyecto (meses cronológicos) o otros datos pertinentes al proyecto. Según Basili describe cuatro modelos de recurso:
modelos simple-variable estáticos (ej. COCOMO), modelos multi-variables estáticos, modelos multi-dinámicos variables y modelos teóricos.

MODELO COCOMO

Barry Boehm en su libro "economía de la ingeniería de software" detalla un modelo amplio de estimación de costos llamado COCOMO (Constructive Cost Model). La palabra "constructive" se refiere a el hecho que el modelo ayuda a un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de variable simple estático y es usado por miles de administradores de proyecto de software .
COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo, equipamiento y mantenimiento).
El modelo provee tres "niveles" de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.
Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).
Intermedio, calcula el esfuerzo del desarrollo del software como función del tamaño del programa y un conjunto de "guías de costo" que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.
Avanzado, incorpora todas las características de la versión intermedia con una evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.
El modelo básico se extiende para considerar un conjunto de atributos de guías de costo que pueden agruparse en cuatro categorías principales:
Producto ( por ej. Requerimientos de software, confiabilidad, tamaño de la base de datos, y complejidad del producto).
Computadora (por ej. Restricciones en el tiempo de ejecución y almacenamiento).
Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en lenguajes de programación y capacidad del programador)
Proyecto (por ej. Uso de practicas modernas de programación, uso de herramientas de software y requerimiento de un plan de desarrollo).
En cada nivel de aplicación están definidos para tres tipos de proyectos de software:
Modo orgánico, proyectos de software relativamente pequeños y sencillos en los que pequeños equipos con buena experiencia en la aplicación trabajan en un conjunto de requerimiento poco rígidos.
Modo semi-acoplado(semi-detached), un proyecto de software intermedio en tamaño y complejidad en el cual equipos con distintos niveles de experiencia debe satisfacer requerimientos poco y medio rígidos
Modo acoplado(detached), un proyecto de software que debe ser desarrollado dentro un conjunto estricto de hardware, software y de restricciones operativas.
Modos que están basados en la complejidad de la aplicación y el desarrollo del ambiente. El modelo de esfuerzo general aplicable a todos los niveles de aplicación y modos está dado por :
Donde:
E = es el esfuerzo estimado expresado en hombres-mes
EDSI es el número estimado de líneas de código distribuidas en miles para el proyecto
a, h son constantes determinadas por el modo del desarrollo, ambos incrementados por la complejidad de la aplicación.
EAF es el factor de ajuste de esfuerzo, es igual a 1 para la modelo básica e igual al producto de 15 factores de costo para la modelo intermedia y avanzada. Cada factor de costo multiplicativo es reflexivo de un incremento proporcional (> 1) o decremento (<1) en costo.
A continuación veremos los coeficientes para el modelo intermedio que depende de modo de desarrollo:

MODO DE DESARROLLO	A	b	c	d
Organic	3.2	1.05	2.5	0.38
Semi-detached	3.0	1.12	2.5	0.35
Embedded	2.8	1.20	2.5	0.32

 Estimacion de Proyecto




EVALUACIÓN DE MODELOS DE ESTIMACIÓN

DE COSTOS DE SOFTWARE

(SLIM,COCOMO,PUNTOS DE FUNCIÓN)

A continuación se presenta un relato de una evaluación de modelos que estiman costos para el desarrollo software. Para esta evaluación se preciso los datos(información) de 15 empresas (proyectos), información que ayudaron a evaluar cuatro de los más populares modelos algoritmicos usados para estimar costos. Estos son: SLIM, COCOMO, PUNTOS DE FUNCIÓN y ESTIMACS.

INTRODUCCIÓN

Los investigadores han expresado su interés en la estimación de costos para el desarrollo de software, esta preocupación se ha hecho presente a medida que avanza el desarrollo de proyectos de software. Principalmente, el interés de comparar resultados usando diferentes métricas para cálculos de productividad.
Para ello se presentan tres preguntas a responder:

• ¿Son los modelos de estimación de costo dl software realmente generalizables para ambientes diferentes, para los cuales fueron desarrollados?. Si no, ¿pueden ser fácilmente moldeables para el ambiente típico de procesamiento de datos para los negocios?

• ¿Los modelos que no usan líneas de código(SLOC) son tan exactos como las que si? Si es así, ¿Se podría eliminar las necesidad de estimar las líneas de código del proyecto?

Para un mejor entendimiento, primeramente se presenta una explicación de cómo se seleccionó los cuatro modelos para la evaluación, seguidamente se procederá a con una breve descripción de los modelos, para continuar con la descripción del ambiente en el cual los datos se originaron. Luego se describirá los métodos de recolección-datos y análisis-datos, para entrar directamente a explicar los resultados y finalmente dar conclusiones.




ACERCA DE LOS MODELOS.

Selección de los Modelos.

Un repaso de la literatura revela una interesante diferencia entre modelos de estimación, esta se refiere a modelos que usan SLOC(líneas de código) como principal entrada y aquellos que no las utilizan. SLOC fue seleccionado rápidamente, como métrica por los investigadores sin ninguna duda, por su cuantificabilidad y objetividad.
El siguiente paso para escoger modelos fue el de buscar en la literatura actual, modelos que se centren en SLOC, de esta búsqueda se selecciono dos: modelo COCOMO y Algoritmo SLIM. Igualmente se procedió a la búsqueda de modelos no-SLOC, solo se encontraron dos: Método de Puntos de Función, desarrollado por Alan Albrecht y el modelo ESTIMACS, desarrollado por Howard Rubin.

Descripción de los MODELOS

Continuando, se presenta una breve descripción de los cuatro modelos mencionados anteriormente.

• Algoritmo SLIM.

Software Lipe Cycle Management, SLIM fue desarrollado en el año 1970 por Larry Putman. Depende de una estimación SLOC para el tamaño general del proyecto, se modifica a través del uso de la curva de Raleigh para producir la estimación del esfuerzo.
El usuario puede influenciar la forma de la curva a través de dos parámetros, la pendiente inicial de la curva y el factor de productividad. Puesto que estos son números dimensionales el usuario tiene dos maneras de ingresar los datos, en la primera el usuario puede calibrar el modelo de ingreso de datos o bien respondes a las 22 preguntas que el SLIM puede proporcionar recomendando un PF y MBL, el segundo método fue el escogido para esta investigación debido a la ausencia de un banco de datos que pueda calibrarse, lo que reflejaría con precisión la experiencia de los usuarios.

• Modelo COCOMO.

Constructive Cost Model, fué desarrollado por Barry Boehm de TRW, publicado en 1981. Basado en el análisis de 63 proyectos de software desarrollados. Boehm desarrollo un modelo (de tres niveles: básico, intermedio y avanzado) fácil de entender que predice la duración del proyecto, así como el esfuerzo para la realización de este.
El modelo detallado COCOMO(utilizado en esta evaluación) es muy similar al modelo intermedio excepto que el proyecto es dividido en cuatro fases: diseño del producto, diseño detallado, codificación de pruebas, integración-pruebas.

• Modelo PUNTOS de FUNCIÓN.

El modelo Puntos de función fue realizado por Alam Albrecht y fue publicado en 1979. Albrecht estaba interesado en el problema general de medición de productividad en sistemas y creo un método como alternativa a la estimación SLOC. Este método captura los el numero de transacciones de entrada y el numero de reportes.
El modelo Puntos de Función tiene ventajas sobre la cuantificación de las linees de código (SLOC) como: es posible estimarlas en el ciclo de vida, alrededor del tiempo de definición de requerimientos para el documento y pueden ser estimadas por un miembro del proyecto relativamente no técnico.
Existen dos pasos que involucrados para el conteo de puntos de función:

• el primero contar las funciones de usuario (tipos de entradas externas e internas, archivos lógicos internos, de interface externos y tipos externos de encuesta)
• el segundo, ajustar la complejidad de los procesos.

• Modelo ESTIMACS.

El modelo Estimacs fue desarrollado por Howard Rubin. Este modelo no requiere como entrada el numero de SLOC, tiene 25 preguntas, cuyas respuestas le sirven de datos de entrada.

ACERCA DE LOS DATOS.

Base de Datos del Proyecto, los proyectos seleccionados para la evaluación poseían dos atributos en común: eran de un tamaño mediano y el estaban disponibles para completar la recolección de datos.



METODOLOGÍA.

Procedimiento para Recolectar los datos. Para cada proyecto hubo una junta con el manejador de proyectos que tenia que llenar las formas especificas. Los propósitos eran:

Discutir cada pregunta para asegurarse que se entendiera el concepto y se respondiera consistentemente
Resaltar la importancia de la participación del manejador del proyecto en el trabajo.

Procedimiento para Analizar los datos, Una vez llenadas las Formas se revisó la consistencia del contenido. Se presento redundancia de muchas preguntas en los modelos, a excepción de las preguntas del modelo Punto de Función con relación a las del modelo ESTIMACS. Lo que significo que era posible asegurar una respuesta acerca del conocimiento del personal del proyecto para el modelo COCOMO, ya que presento consistencia con preguntas similares del modelo SLIM.

Análisis del error, Para tener un margen de error entre una estimación, se cálculo el error relativo relacionando el esfuerzo estimado con el esfuerzo verdadero realizado en el proyecto. Usando dos exámenes para evaluar el proyecto:

• El de cálculo de error relativo(MRE).
• El método de regresión.

RESULTADOS.

Los resultados que se presentan, son los encontrados después de que cada modelo fue corrido en los 15 proyectos seleccionados.

Resultados de SLIM, fue corrido usando los parámetros por defecto del modelo, los usuarios respondieron a las 22 preguntas del SLIM.

Este modelo no tiene una vía buena para el cálculo del error relativo(MRE), obteniendo un porcentaje de error promedio de 772%, con el pequeño error de 21%.

Resultados de COCOMO, los resultados para las tres versiones COCOMO en el cálculo del MRE fueron pobres, obteniéndose un promedio de 601% con el error más bajo de 83%.

Resultados de Puntos de Función, el promedio MRE es de 102,74%.

Resultados ESTIMACS, presento un promedio del 85%.      

CONCLUSIONES.

Después de examinar cada modelo independientemente, se procedió a responder las tres preguntas formuladas al comenzar con esta evaluación:¿Son los modelos de estimación de costo del software realmente generalizables para ambientes diferentes, para los cuales fueron desarrollados?. Si no, ¿pueden ser fácilmente moldeables para el ambiente típico de procesamiento de datos para los negocios?
Los modelos desarrollados en ambientes diferentes no trabajan muy bien, cuando se desea acoplarlos. Los porcentajes de error calculados usando la formula de error relativo están en el rango de 85 a 775%. Esta variación se debe la diferencia de ambientes.
¿Los modelos que no usan líneas de código(SLOC) son tan exactos como las que si? Si es así, ¿Se podría eliminar las necesidad de estimar las líneas de código del proyecto?
En términos de los resultados de error relativo los modelos que no usan líneas de código como entrada fueron mejores. Pero en términos de los resultados de regresión están altamente correlacionados.
En conclusión: los modelos, a pesar de su perfeccionamiento sobre diferentes entradas para la estimación de esfuerzo, no modelan de manera adecuada los factores que afectan la productividad. Es necesario hacer mas investigaciones acerca de cómo medir todos los factores que afectan los sistemas de productividad profesional, si la profesión es encontrarse con los cambios del futuro.
Resolución del ejemplo 3
Sistema Colaborativo, para calcular el esfuerzo requerido se tiene:
E = 3.6 * ( EDSI ) ^ 1.20
Donde 3.6 y 1.20 son constantes para lo que son programas de sistema y EDSI son las líneas de código
De donde en el caso del sistema colaborativo el esfuerzo será:
E = 3.6 * ( 11.038 ) ^ 1.20
E = 64
Donde (11.038) significa 11038 líneas de código fuente, y esto se conoce por la notación KDSI
Nota.- Los estimadores de esfuerzo excluyen los costos de planeación, instalación y entrenamiento, así como los costos de secretarias, personal de limpieza y operadores del equipo de computo.
El tiempo de desarrollo para un programa, según lo sugiere Boehm, es de:
TDEV = 2.5 * ( E ) ^ 0.32
En el caso del sistema colaborativo el tiempo necesario se calculara de la siguiente manera:
TDEV = 2.5 * ( 64 ) ^ 0.32
TDEV = 9.5
Dado el numero total de meses programador de un proyecto y el tiempo nominal de desarrollo requeridos, el nivel promedio de contratación puede obtenerse mediante una simple división:
PG = E / TDEV
Donde PG son el numero de programadores requeridos.
De donde para el sistema colaborativo el numero de programadores requeridos será:
PG = 64 / 9.5
PG = 6.73
PG = 7
Ahora para la distribución del tiempo total de desarrollo del sistema colaborativo, para cada fase se tiene que:
40 % Análisis y Diseño
20% Codificación
40% Pruebas
De donde se tendrá que el tiempo para cada fase será:
4 Meses Análisis y Diseño
5 Meses Pruebas
3 Meses Codificación
Ahora se verá lo que son los costos, estos serán:

Costos de Desarrollo,

Costos de Equipamiento,

Costos de Mantenimiento.

Costo de Desarrollo

Personal: Analistas y Programadores 20900$

Analistas ( 400$ / mes, durante 9.5 meses): 2 analistas
Programadores (200$/mes, durante 9.5 meses): 7 programadores

Pruebas ( 500 $ / mes, durante 5 meses ) 2500 $

Alquiler Equipo ( 100 $ / mes, durante 9.5 meses ) 6650 $

Material: 200$

Suministros de Computadora

Material de Escritorio

TOTAL COSTO DESARROLLO: 30250 $

Costo Equipamiento

25 Maquinas Terminales 23750 $

Características:

Tarjeta madre QDI Brillant I BX AGP ATX

Procesador Intel Pentium II 350 Mhz (Original)

Cache en tarjeta de 512 Kb

32 Mb. DIMM de memoria RAM PC-100

Disco duro de 6.4 Gb. (Western Digital)

Monitor de 14” SVGA (Samsung SyncMaster 400b)

Tarjeta de Video de alta velocidad de 4 Mb.

Tarjeta de Red FAST 100Mb. PCI PnP

Precio Unitario de 950 $

1 Maquina Servidora 1300 $

Características:

Tarjeta madre marca SOYO - 5BT

Procesador Intel Pentium II 400 Mhz (Original)

Cache en tarjeta de 512 Kb

64 Mb. DIMM de memoria RAM PC-100

Disco duro de 8.4 Gb. (Western Digital)

Monitor de 14” SVGA (Samsung SyncMaster 400b)

Tarjeta de Video de alta velocidad de 4 Mb.

Tarjeta de Red FAST 100Mb. PCI PnP

Conexión Red: 2600 $

Topología Estrella

Cable UTP (200 mts., 5$/metro)

2 HUB's ( 450 $ precio unitario )

Accesorios de Red

TOTAL COSTO EQUIPAMIENTO 27650 $

Costo de Mantenimiento (Anual) 500 $

TOTAL COSTO MANTENIMIENTO 500 $

TOTAL COSTO SISTEMA COLABORATIVO 58400 $

RESULTADOS DEL MODELO DE IMPLEMENTACION INTERMEDIO COCOMO 81

Los resultados obtenidos con el calculador MODELO INTERMEDIO COCOMO 81 son los siguientes:
Esfuerzo = 64 personas / mes
Tiempo = 9.5 meses
Cantidad de líneas de código en ambos casos es:
11038 líneas
Este número de líneas fueron determinadas en el anterior trabajo.
COCOMO
Haciendo comparaciones con el COCOMO realizado manualmente se tiene las siguientes observaciones:

En cuanto al esfuerzo se tiene una variación aceptable de 2.16 personas/mes

Tiempo se tiene una discrepancia de 0.98 meses

Nuestra opinión sería que los resultados obtenidos no están muy lejos; y que son aceptables y también si se alteraría algún parámetro del Calculador entonces se llegaría a una aproximación todavía mas aceptable; pero esto sería ya forzando el resultado.
En su libro: Model and Metrics for Software Management and Engineering
18
" ESTIMACIÓN DE COSTOS "

E = a (EDSI)h * (EAF)

TDEV = c E d

PG = E / TDEV



 

COCOMO II     Teoría y ejercicio práctico. Método de estimación de costos de Software.

 

Humor: Hitler se entera que no usaron un modelo cocomo de estimación de costos en su proyecto

Bibliografia  

http://ingenieriasoftware1.blogspot.es/

http://html.rincondelvago.com/estimacion-de-costos.html