CAPÍTULO 2
ESTIMACIÓN DE LOS COSTE DEL PROYECTO SOFTWARE
La estimación de costes es una de las primeras tareas que deben realizarse en la planificación de un proyecto software y se trata de una difícil tarea puesto que no se posee información suficiente acerca del mismo.
Para intentar solventar este problema se realizan varias estimaciones a lo largo del desarrollo de un proyecto, acercándose cada vez más al coste final del mismo puesto que cada estimación se realiza sobre una etapa en la que éste está más refinado.
2.1. FACTORES QUE DETERMINAN EL COSTE DEL PROYECTO
Otro problema que se presenta en la estimación del coste de un proyecto software es la determinación del coste de los factores, generalmente no cuantitativos y por tanto difícil de medir.
2.1.1. CAPACIDAD DE LOS PROGRAMADORES
Tiene una relación directa con la duración y coste del proyecto. Es una medida del nivel de conocimientos y experiencia de las personas dedicadas a la programación de software así como la experiencia con el tema en concreto con el que se esté tratando.
Tras haber estudiado el rendimiento de grupos de desarrollo se llega a la conclusión de que un grupo ideal sería aquel lo más homogéneo y elevado en cuanto a su capacidad.
2.1.2. COMPLEJIDAD DEL PRODUCTO
En una primera aproximación se pueden considerar tres categorías principales de productos software:
1. Software de aplicación.
2. Software científico y de apoyo.
3. Software de sistemas.
Brook considera que el software de apoyo es tres veces más difícil de construir que el de aplicación, y que el de sistemas, a su vez, es tres veces mas difícil de construir que el de apoyo.
Boehm utiliza también tres niveles de complejidad que caracterizan el desarrollo de un producto software:
1. Productos desarrollados en modo orgánico (similar a software de aplicación).
2. Productos desarrollados en modo semiacoplado (similar a software de apoyo).
3. Productos desarrollados en modo empotrado (similar a software de sistemas).
Un error muy común es subestimar la cantidad de código no teniendo en cuenta el código relativo a entrada/salida, comunicación con el usuario, control de errores. . . siendo ´este, a veces, el 50% del total del código del programa.
2.1.3. TAMAÑO DEL PRODUCTO
Un proyecto será más costoso cuanto más grande sea. Se puede realizar una medición atendiendo al número de líneas de código que necesita un programa así como al número de personas al mes necesarias para llevarlo a cabo.
2.1.4. TIEMPO DISPONIBLE
Se busca calcular el tiempo nominal de desarrollo de un proyecto, bien mediante técnicas de programación lineal o bien mediante la proposición de expresiones matemáticas como la propuesta por Putnam:
Se ha estudiado el factor del tiempo ´optimo de desarrollo de un proyecto y se ha llegado a la conclusión de que los proyectos de programación requieren más esfuerzo si el tiempo de desarrollo se reduce o incrementa más de su valor óptimo.
Otro estudio ha demostrado también que no por asignarle más recursos a una tarea se va a reducir el tiempo de duración de la misma. Boehm lo describe así:
“Existe un límite más allá del cual un proyecto de programación no puede reducir su calendario mediante la adquisición de más personal o más equipo.”
2.1.5. NIVEL DE CONFIABILIDAD REQUERIDO
La confiabilidad de un producto de programación se define como:
La probabilidad de que un programa desempeñe una función requerida bajo ciertas condiciones específicas durante un cierto tiempo. La confiabilidad puede expresarse en términos de exactitud, firmeza, cobertura y consistencia del código fuente.
Boehm considera que hay cinco niveles de confiabilidad y que a cada uno se le puede asignar un factor multiplicador.
| NIVEL | CONSECUENCIA | FACTOR |
| Muy baja Baja Nominal Alta Muy alta | Alguna molestia menor Las pérdidas son fáciles de recuperar Dificultad relativa en a recuperación Gran pérdida financiera Riesgo de pérdida de vida | 0.75 0.88 1.00 1.15 1.40 |
2.1.6. NIVEL TECNOLÓGICO
El nivel tecnológico empleado en un proyecto de programación se refleja en el lenguaje utilizado, la máquina abstracta, las prácticas y las herramientas de programación.
El nivel tecnológico va a depender de cuatro factores:
§ Lenguaje de programación:
El uso de un lenguaje de alto nivel simplifica el número de líneas de código y aumenta la confiabilidad, capacidad de modificación y mantenimiento del mismo.
§ Máquina abstracta:
Hace referencia al software y al hardware.
§ Prácticas modernas de programación:
Afectarán al esfuerzo empleado en el desarrollo.
§ Aplicaciones de apoyo:
Editores, compiladores… y herramientas de manejo de configuración y verificación automática.
Boehm introduce tres factores más:
§ La experiencia en programación.
§ Cómo se utilizan las prácticas modernas de programación (si se utilizan mucho se produce una disminución considerable del esfuerzo).
§ Características de las aplicaciones de apoyo.
2.2. MÉTRICAS DE PRODUCTIVIDAD DEL SOFTWARE
El software se mide por varias razones:
1. Indicar la calidad del producto.
2. Evaluar la productividad de la gente que lo desarrolla.
3. Asegurar los beneficios en términos de productividad y calidad.
4. Ayudar a justificar el uso de nuevas herramientas de formación adicional.
Se pueden realizar dos tipos de mediciones:
1. Medidas directas:
Coste de producción, velocidad de cómputo, tamaño de memoria requerido…
2. Medidas indirectas:
Funcionalidad, eficiencia, calidad, fiabilidad, complejidad…
Se puede realizar una nueva clasificación en base a la productividad, calidad y medidas técnicas del producto software en la fase de desarrollo, son:
§ Métricas de productividad.
§ Métricas de calidad.
§ Métricas técnicas.
§ Métricas orientadas al tamaño.
§ Métricas orientadas a la función.
§ Métricas orientadas a las personas.
2.2.1. MÉTRICAS ORIENTADAS AL TAMAÑO
Se obtienen tras aplicar una serie de operaciones. No están demasiado aceptadas puesto que no es el mejor modo de medir un proyecto de desarrollo software debido a la relatividad de lo que estamos midiendo. Las operaciones aplicables son:
2.2.2. MÉTRICAS ORIENTADAS A LA FUNCIÓN
Se centran en la funcionalidad o utilidad del programa. Los puntos de función se obtienen utilizando una relación empírica basada en medidas contables del dominio de la información del software y valoraciones subjetivas de la complejidad del mismo.
Los puntos de función se pueden calcular atendiendo a cinco características de la información:
§ Número de entradas de usuario: Se cuenta cada entrada de usuario que proporciona al software diferentes datos orientados ala aplicación.
§ Número de salidas al usuario: Número de informes, pantallas, mensajes de error…
§ Número de peticiones de usuario: Es el número de entradas generadas por la interacción del usuario con el programa que se pueden producir.
§ Número de archivos: Se cuenta cada archivo maestro lógico.
§ Número de interfaces externas: Número de interfaces que son utilizadas para transmitir información a otro sistema.
| Elemento del dominio de la información | Valor | FP Simple | FP Medio | FP Complejo | CP |
| Entradas de usuario | | x3 | x4 | x6 | |
| Salidas de usuario | | x4 | x5 | x7 | |
| Peticiones de usuario | | x3 | x4 | x6 | |
| Número de archivos | | x7 | x10 | x15 | |
| Interfaces externas | | x5 | x7 | x10 | |
Cuando estos datos son calculados se asocia un valor de complejidad a cada cuenta y se calculan los puntos de función de la siguiente forma:
Las medidas de los puntos de función se diseñaron inicialmente para ser utilizadas en aplicaciones de sistemas de información de gestión pero Jones ha realizado una serie de ampliaciones en las que los denomina Puntos de Características del software, en las que se tiene en cuenta la complejidad algorítmica, que permiten realizar medidas en software de ingeniería y sistemas.
Para aplicaciones convencionales de cálculo de ingeniería de sistemas de información los PF y los PC dan valores muy similares. No ocurre lo mismo para sistemas más complejos, en los que el PC es del orden de entre un 20% y un 35% mayor que el PF.
2.2.3. RECONCILIACIÓN DE LAS DIFERENTES MÉTRICAS
La relación entre las LDC y los PF depende del lenguaje de programación utilizado y de la calidad del diseño, y dicha relación nos va a proporcionar una medida de productividad del software evaluado, medida que está sometida evidentemente a errores debidos a la subjetividad con que se realice además de otros factores que afectan directamente al software. Son los siguientes:
§ Factores humanos: tamaño y experiencia de la organización de desarrollo.
§ Factores del problema: complejidad del problema a resolver y el número de cambios en las restricciones o requisitos del diseño.
§ Factores del proceso: técnicas de análisis y diseño utilizadas.
§ Factores del producto: fiabilidad y rendimiento del sistema basado en la computadora.
§ Factores de los recursos: disponibilidad de herramientas CASE y recursos hardware y software.
Una estimación va a ser más precisa si tiene una base histórica lo más amplia y consolidada posible.
2.3. TÉCNICAS DE ESTIMACIÓN DE COSTES
Dentro de la mayoría de las organizaciones la estimación de costes se basa en experiencias pasadas. Estas estimaciones se pueden llevar acabo de forma jerárquica hacia abajo (top down) donde el punto de referencia es el coste del sistema, manejo de la configuración, control de calidad. . . o hacia arriba (bottom-up) donde se considera el coste de los distintos subsistemas para estimar el coste total de sistema.
2.3.1. JUICIO DEL EXPERTO
Técnica jerárquica hacia abajo. Es la más ampliamente utilizada y se basa en la experiencia, conocimiento anterior y sentido comercial de uno o más individuos dentro de la organización.
La experiencia, factor que en principio puede ser una ventaja, puede que se convierta en una desventaja debido a que el experto puede realizar una mala estimación debido a la generalización del caso.
2.3.2. TÉCNICA DELFI
Técnica jerárquica hacia abajo. Intenta eliminar reuniones entre grupos para conseguir efectividad. Forma de ejecución:
1. Un coordinador proporciona a cada experto anónimo una documentación.
2. Cada experto estudia la definición y estima costes.
3. El coordinador realiza un resumen de todas las estimaciones.
4. Si el coordinador ve algún razonamiento extraño, se envía a los expertos el resumen y se realiza una nueva estimación.
5. Se vuelve al paso 3 tantas veces como sea necesario.
TÉCNICA DELFI MODIFICADA
Similar a la anterior sólo que no evita reuniones de grupo, aunque sí se mantiene el anonimato. Si existe discrepancia en las estimaciones se discuten sobre ellas y si no se llega a una solución el coordinador deberá tomar una decisión.
2.3.3. ESTRUCTURAS DE DIVISIÓN DEL TRABAJO
Técnica jerárquica hacia arriba. Hace uso de un organigrama para reflejar las diferentes partes del sistema y las jerarquías de productos o procesos.
Estas técnicas son muy usadas. Pueden clasificarse en dos grupos según realicen división de trabajo por producto o por procesos.
2.4. MODELOS DE ESTIMACIÓN EMPÍRICA
Un modelo de estimación utiliza fórmulas empíricas para predecir los datos que se requieren en la etapa de planificación del proyecto software.
Existen varios modelos de estimación aplicables a unos u otros proyectos según sus características. Atendiendo a las mismas se pueden clasificar en:
1. Modelos univariable estáticos.
2. Modelos multivariable estáticos.
3. Modelos multivariable dinámicos.
4. Modelos teóricos.
Un modelo univariable estático toma la forma:
Un modelo multivariable dinámico toma la forma:
2.4.1. MODELO COCOMO
El Constructive Cost Model fue propuesto por Boem y es uno de los más ampliamente usados. Propone una serie de modelos con distintos grados de complejidad e información utilizada:
§ Modelo Básico:
Modelo estático que sólo tiene en cuenta el tamaño del programa y el coste de desarrollo. Ecuaciones:
Donde a, b, c y d vienen expresados en la siguiente tabla:
| CoCoMo Básico | a | b | c | d |
| Modo Orgánico Modo Semiacoplado Modo Empotrado | 2.4 3.0 3.6 | 1.05 1.12 1.20 | 2.5 2.5 2.5 | 0.38 0.35 0.32 |
§ Modelo Intermedio:
Donde a y b vienen expresados en la siguiente tabla:
| CoCoMo Básico | a | b |
| Modo Orgánico | 3.2 | 1.05 |
| Modo Semiacoplado | 3.0 | 1.12 |
| Modo Empotrado | 2.8 | 1.20 |
§ Modelo Avanzado:
Incorpora todas las características del modelo intermedio con una evaluación del impacto de las guías de coste en cada fase del proceso de la IS.
El modelo de CoCoMo está definido para tres tipos diferentes de proyectos:
§ Modo Orgánico: Proyectos pequeños y sencillos con equipos pequeños con buena experiencia que trabajan en un conjunto de requisitos poco rígidos.
§ Modo Semiacoplado: Proyecto software intermedio en el que trabajan equipos con distintos niveles de experiencia sobre requisitos poco y medio rígidos.
§ Modo Empotrado: Proyectos software que deben ser desarrollados dentro de un conjunto estricto de hardware, software y restricciones operativas.
2.4.2. MODELO DE PUTNAM
Modelo univariable dinámico que asume una distribución específica del esfuerzo a lo largo del ciclo de vida de un proyecto. Este modelo, aunque deriva de distribuciones de mano de obra de grandes proyectos es extrapolable pequeños y medianos proyectos.
Donde Ck es una constante de estado que puede los siguientes valores:
| Valor de Ck | Descripción |
| 2000 8000 11000 | Para entorno pobre de desarrollo, sin metodología, modo de ejecución no interactivo, documentación y revisiones pobres. Para un buen entorno de desarrollo. Para un entorno excelente. |
LDC es el número de líneas esperadas de código fuente, PA el esfuerzo de desarrollo y mantenimiento y TDA el tiempo de desarrollo.
