ESTIMACIÓN DE COSTOS

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.

3.1.1 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

Modo básico utiliza el tamaño y el modo intermedio 15 manejadores de costo que son los siguientes:

Manejadores de Costo Very Low Low Nominal High Very High Extra High

ACAP Analyst Capability 1.46 1.19 1.00 0.86 0.71 -

AEXP Applications Experience 1.29 1.13 1.00 0.91 0.82 -

CPLX Product Complexity 0.70 0.85 1.00 1.15 1.30 1.65

DATA Database Size - 0.94 1.00 1.08 1.16 -

LEXP Language Experience 1.14 1.07 1.00 0.95 - -

MODP Modern Programming Practices 1.24 1.10 1.00 0.91 0.82 -

PCAP Programmer Capability 1.42 1.17 1.00 0.86 0.70 -

RELY Required Software Reliability 0.75 0.88 1.00 1.15 1.40 -

SCED Required Development Schedule 1.23 1.08 1.00 1.04 1.10 -

STOR Main Storage Constraint - - 1.00 1.06 1.21 1.56

TIME Execution Time Constraint - - 1.00 1.11 1.30 1.66

...