Estimación en Proyectos de SW

La estimación del costo y del esfuerzo del software nunca será una ciencia exacta. Son demasiadas las variables humanas, técnicas, de entorno, políticas que pueden afectar al costo final del software y al esfuerzo aplicado para desarrollarlo. Sin embargo, la estimación del proyecto de software puede dejar de ser un oscuro arte para convertirse en una serie de pasos sistemáticos que proporcionen estimaciones con un grado de riesgo aceptable.  

Para realizar estimaciones seguras de costos y esfuerzos tenemos varias opciones posibles: Utilizar “técnicas de descomposición” relativamente sencillas para generar las estimaciones de costo y de esfuerzo del proyecto. Desarrollar un modelo empírico para el cálculo de costos y esfuerzos. Adquirir una o varias herramientas automáticas de estimación. 

Dejar las estimaciones para más adelante o retrasarlas no es una opción ya que estas se necesitan de antemano. Las tres opciones restantes son métodos viables para la estimación del proyecto. Las técnicas de descomposición utilizan un enfoque divide y vencerás. Los modelos empíricos son utilizables como complemento de las técnicas de descomposición donde cada modelo se basa en la experiencia (datos históricos), por ultimo las herramientas automáticas de estimación ponen en ejecución una o varias técnicas de descomposición o modelos empíricos. 

5.1 Técnicas de Descomposición. 

Los proyectos son constantemente utilizados dentro de la organización, esto, porque constituyen el principal medio de crecimiento para ésta. Generalmente, los proyectos han sido utilizados como un instrumento de “acción” para manejar grandes inversiones en cualquier área de la organización. 

Por esto se busca una forma práctica para estimar su esfuerzo y tiempo de ejecución, para así minimizar la inversión. 

Dado que la estimación del esfuerzo de un proyecto de software no es una ciencia exacta, existen demasiadas variables humanas y técnicas influyendo y afectando al producto final. 

Se trabajará sobre la base de Técnicas de Descomposición, de esta manera se divide el problema en módulos pequeños más manejables que permitan definir una estimación de tiempo, de cantidad de personas necesarias para llevar a cabo el proyecto propuesto. La estimación de proyectos de software es una forma de resolución de problemas y en la mayoría de los casos, el problema a resolver (esto es desarrollar estimaciones de costo y de esfuerzo para un proyecto de software), es demasiado complejo, por ello se debe separar en un conjunto de pequeños problemas mas manejables. 

5.2 Estimación de Líneas de  Código (LDC) y Puntos de Función (PF). 

Las LDC y los PF se describen como medidas básicas desde donde se calculan métricas de productividad. Los datos de LDC y PF se utilizan de dos formas durante la estimación del proyecto de software:  

• Como una variable de estimación que se utiliza para “dimensionar”cada elemento del software.  
• Como métricas de línea base recopiladas de proyectos anteriores y utilizadas junto con variables de estimación para desarrollar proyecciones de costo y de esfuerzo.  

En un comienzo el proyecto se disgrega en pequeñas subfunciones que pueden ser estimadas individualmente , ya sea en LDC o PF para cada función. Cuando se utiliza LDC como variable de estimación, la descomposición funcional es absolutamente necesaria. 

También debe tenerse en cuenta que mientras las LDC se estiman directamente, los PF se determinan indirectamente mediante la estimación de numero de entradas, salidas, archivos de datos, consultas e interfaces, así como también de catorce  valores de ajuste de complejidad. Independientemente de la variable de estimación que  use el planificador del proyecto, normalmente proporciona un rango de valores para cada función descompuesta. 

¿Serán correctas las estimaciones? La única respuesta razonable a esta pregunta es “No podemos asegurarlo”. Cualquier técnica de estimación, no importa como sea de sofisticada, tiene que ser comprobada utilizando otro método. Incluso entonces, deberán prevalecer la experiencia y el sentido común. 

¿Qué ocurre cuando la concordancia entre las estimaciones es pobre? Para responder a esta pregunta se debe reevaluar la información que se ha utilizado para hacer las estimaciones. Muchas divergencias entre estimaciones se deben a menudo, a una de dos causas:  

• No se entiende adecuadamente el ámbito del proyecto o ha sido malinterpretado por el planificador.  
• Los datos de productividad utilizados en la técnica LDC, son inadecuados para esa aplicación, están obsoletos (no reflejan con precisión la organización de desarrollo de software) o se han aplicado mal. 

5.2.1 Líneas de Código (LDC) v/s Puntos de Función (PF). 

LDC y PF son técnicas de estimación distintas, a pesar de que ambas tienen varias características en común. La estimación comienza con un enfoque limitado para el ámbito del software y desde esta sentencia intenta descomponer el software en funciones que se pueden estimar, individualmente. 

Para cada función entonces se estima las LDC y el PF (la variable de estimación). De forma alternativa, se puede seleccionar otro componente para dimensionar clases u objetos, cambios, o procesos de gestión en los que puede tener impacto.  

Las métricas de productividad (p. ej.: LDC/pm o PF/pm) se aplican entonces para la variable de estimación adecuada y se extrae el costo o el esfuerzo de la función. Las estimaciones de función se combinan para producir una estimación global del proyecto entero. En general, el dominio del proyecto debería calcular las medias de LDC/pm o PF/pm. Es decir, los proyectos se deberían agrupar por tamaño de equipo, área de aplicación, complejidad y otros parámetros relevantes. Entonces se deberían calcular las medias del dominio local. Cuando se estima un proyecto nuevo, primero se debería asignar aun dominio, y a continuación utilizar la media del dominio adecuado para la productividad al generar la estimación. 

Las técnicas de estimación de LDC y PF difieren en el nivel de detalle que se requiere para la descomposición y el objetivo de la partición. Cuando se utiliza LDC como variable de estimación, la descomposición es absolutamente esencial y a menudo se toman para considerables niveles de detalle. Cuanto más grande sea el grado de particionamiento, más probable será que pueda desarrollar estimaciones más exactas.  

Para estimaciones de PF, la descomposición funciona de diferente manera. En lugar de centrarse en la función, se estiman cada una de las características del dominio de información entradas, salidas, archivos de datos, peticiones, e interfaces extremas y los catorce valores de ajuste de la complejidad. Las estimaciones resultantes se utilizan para derivar un valor de PF que se pueda unir a datos pasados y utilizar para generar una estimación.  

Las métricas usadas para estimar el tamaño del producto de software deben ser razonablemente fáciles de usar en etapas tempranas del proyecto y fácilmente mensurables una vez que el trabajo ha finalizado. 

Las comparaciones subsecuentes de las estimaciones iniciales con el tamaño del producto de software actual, proveen retroalimentación a los planificadores acerca de cómo hacer estimaciones más precisas en futuros proyectos. 

En la actualidad las métricas más usadas para dimensionar un producto de software son las Líneas de Código (LDC) y los Puntos de Función (PF).  Ambos poseen ventajas y desventajas que serán discutidas a continuación. 

Las LDC miden en forma directa el tamaño del producto de software.  Se calculan simplemente contando las instrucciones de código fuente de cada componente del producto de software excluyendo, generalmente, los comentarios y blancos.  Antes de adoptar esta métrica como estándar, la organización debe definirla en forma exhaustiva.  Esta definición debe respetarse, ya que podría atentarse contra la integridad de los datos de la base de datos de los proyectos de la organización. Las ventajas y desventajas de las LDC se sintetiza en la Tabla 5.1: 

5.3 Modelos para las Estimaciones. 

5.3.1 Modelo COCOMO. (COCOMO 81) 

COCOMO, el Modelo Constructivo de Costos, fue desarrollado por Barry Boehm en  1981.  

El modelo asume que los requerimientos son relativamente estables y que el proyecto será administrado por el cliente y el desarrollador. El modelo entrega un orden de magnitud de los costos del Software. Utiliza como datos el tamaño estimado del proyecto y el tipo de producto a desarrollar. 

Tipos de proyectos 

Los modelos COCOMO están definidos para tres modos de desarrollo:  

Proyectos Orgánicos: El equipo de desarrollo es pequeño y experimentado, en un ambiente familiar y con aplicaciones conocidas. En general considera proyectos de no más de 50.000 LDC.

 Proyectos Semiconectados (Semilibres): El equipo de desarrollo está formado por personal experimentado y novato con algo de experiencia en la tecnología y la aplicación. Suelen tener interacciones con otros sistemas, y presentan un tamaño de no más de 300.000 LDC.  

Proyectos Integrados (Empotrados): Tiene un gran equipo de desarrollo, pero en general es poco experimentado en el tema dado que se trata de proyectos casi únicos. Corresponden a proyectos que presentan un fuerte acoplamiento entre el Hardware, Software y los procedimientos operacionales. La modificación a los requerimientos no es práctica y los costos de validación son altos.  

Jerarquía de Modelos COCOMO 

La jerarquía de modelos COCOMO viene dada por el nivel de detalle empleado en su utilización:  

Modelo COCOMO básico: es un modelo univariable estático que calcula el esfuerzo y el tiempo del desarrollo de software en función del tamaño del programa, expresado en Líneas de Código (LDC) estimadas. Adecuado para hacer estimaciones de forma rápida, aunque sin gran precisión.  

Modelo COCOMO intermedio: es un modelo univariable estático que calcula el esfuerzo del desarrollo de software en función del tamaño del programa y un conjunto de “conductores de coste”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto. Estos conductores del coste se consideran como términos de impacto agregado al esfuerzo total del proyecto.  

Modelo COCOMO avanzado (o detallado): es un modelo que incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de coste en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software. 

Cabe destacar que las estimaciones relacionadas con el esfuerzo se expresan en hombre-mes (tiempo que requeriría una sola persona para desarrollar el sistema), considerando que la dedicación de una persona es de 152 horas al mes. 

5.3.2 Modelo COCOMO Básico 

Las ecuaciones básicas del modelo se muestran en la Tabla 5.2.

La Tabla 5.3 muestra los perfiles de proyectos estándares para Modo Orgánico: 

Donde el tamaño viene dado el KS, que corresponde a miles de líneas de código fuente.

Cabe mencionar que el número de personas empleadas en el proyecto a lo largo de su desarrollo no es uniforme, el número medio de personas obtenido no representa una cifra muy significativa, es decir, debe considerarse sólo como una aproximación. Putnam (1978) establece que la forma óptima para asignar personal en el proyecto es siguiendo una curva Rayleigh, ver Figura 5.1. La experiencia demuestra que no es conveniente partir con mucha gente al inicio de éste.  

De cualquier modo sería más conveniente analizar el personal requerido, en cada etapa de desarrollo del proyecto, el cual también se comporta como una curva Rayleigh para cada etapa como lo muestra la Figura 5.1 [13]:

En general el modelo de estimación nos entrega un orden de magnitud de la cantidad de personal requerido para el desarrollo del proyecto, para esto, utiliza en forma implícita la productividad estimada supuestamente obtenida de datos de proyectos existentes. En el caso de proyectos orgánicos, la productividad es de 352 [LDC / h-m], lo que resulta en 16 [instrucciones / hd]. Para los proyectos integrados la productividad implícita es de 105 [LDC / h-m], lo que resulta en cerca de 4 [instrucciones / h-d]. 

5.3.3 Modelo COCOMO Intermedio. 

Este modelo es una versión ampliada del modelo Básico, en la que se presenta una mayor precisión en las estimaciones, manteniendo prácticamente la misma sencillez del anterior modelo. Esta mayor precisión viene dada por la incorporación de 15 factores que reflejan la influencia de ciertos elementos sobre el coste del software. Estos 15 factores se agruparon en cuatro grandes grupos: Atributos del Producto, del Computador, del Personal y del Proyecto. Cada uno de estos 15 atributos tiene asociado un factor multiplicador para estimar el efecto de éste sobre el esfuerzo nominal. En la Tabla 5.4 se muestran las ecuaciones del Esfuerzo Nominal.

Una vez obtenido el esfuerzo nominal, este debe multiplicarse por el producto de la ponderación de los 15 atributos, ver Tabla 5.5. 

La descripción de cada uno de ellos se muestra a continuación: Atributos del Producto • Fiabilidad del Software: Indica las posibles consecuencias para el usuario en el caso que todavía existan defectos en el producto. Una puntuación Muy Baja indica que solamente hace falta eliminar los defectos sin ninguna otra consecuencia mientras que una puntuación Muy Alta implica pérdidas de vidas humanas. • Tamaño de la Base de Datos: Un valor Bajo para este atributo significa que el tamaño de la base de datos (en Bytes) es menor que 10*LDC. El valor Nominal indica un tamaño entre 10 y 100 veces las LDC; un valor Muy Alto significa que la base de datos es mayor que 1000 veces las LDC. • Complejidad: El código de complejidad Baja usa operaciones de E/S, estructuras de datos simples y codificación fácil. La complejidad Nominal implica algún procesamiento de E/S, E/S de múltiples archivos, uso de rutinas de biblioteca y comunicación ínter módulos. Complejidad Muy Alta implica el uso de código recursivo, manejo de archivos complejos, procesamiento paralelo y administración de datos complicada. 

Atributos del Computador • Restricciones de tiempo de ejecución: Siempre será más exigente para un programador escribir un programa que tiene una restricción en el tiempo de ejecución. Esta puntuación se expresa en el porcentaje de tiempo de ejecución disponible. Es Nominal cuando el porcentaje es el 50%, y Extremadamente Alto cuando la restricción es del 95%. • Restricciones de memoria virtual: Se espera que un cierto porcentaje del almacenamiento principal sea utilizado por el programa. El esfuerzo de programación se incrementa si el programa tiene que correr en un volumen menor del almacenamiento principal. El esfuerzo extra de Nominal se presenta cuando la reducción del almacenamiento principal es del 50% y Extremadamente Alto indica una reducción del 95%. • Volatilidad de la máquina virtual: Durante el desarrollo del software la máquina virtual (combinación de hardware y software) en la que el programa se va a desarrollar puede sufrir algunos cambios. • Tiempo de respuesta: Cuanto menor sea el tiempo de respuesta requerido, más alto será el esfuerzo humano. 

Atributos del Personal 

• Capacidad de análisis: La capacidad del grupo de analistas, en términos de habilidad de análisis, eficiencia y capacidad para cooperar tiene un impacto significativo en el esfuerzo humano. Cuanto más capaz sea el grupo, menos esfuerzo será necesario.  • Experiencia en aplicación: La experiencia del grupo en una aplicación similar tiene una gran influencia en el esfuerzo. Los tiempos de experiencia para los distintos niveles se muestran en la Tabla 5.6.