Frases como: "'Resultados para ayer', 'Costos fuera del Presupuesto', se repiten año a año en el campo de la Ingeniería de Software y existiendo herramientas de estimación, todavía no superamos la mala fama de los informáticos...........¿Estaremos predestinados?".

Una de las mayores dificultades en la administración de proyectos de desarrollo de software, es el poder estimar los recursos necesarios requeridos, tales como, mano de obra (horas/hombre), tiempo, costos asociados al desarrollo, entre otros; en etapas tempranas del desarrollo, con el fin de anticipar resultados no esperados al desarrollo del proyecto.

Muchos modelos de estimación de costos y esfuerzos han sido desarrollados, entre los más conocidos se cuentan: COCOMO y puntos por función, los cuales son de gran utilidad para los administradores de proyectos siempre y cuando sean correctamente utilizados. El enfoque de puntos por función desarrollado por Albrecht y Gaffney sirvió de base a un nuevo método mejorado de estimación, llamado Mk-II, desarrollado por Symons.

Dentro de los elementos más débiles del desarrollo de software, están la estimación de esfuerzo y el costo. Es por esta razón que existe una alta motivación al desarrollo y utilización de métodos para tales estimaciones. A continuación se muestran cuatro enfoques para estimar el esfuerzo y costo en el desarrollo de software.

Este enfoque consiste en que los administradores de proyecto consultan a un experto, quien estudia el nuevo proyecto y sugiere sus mejores estimaciones. La desventaja del enfoque es que tiende a ser subjetivo debido a que considera la experiencia del experto y sus percepciones de él, con respecto al proyecto.

Una estimación inicial basada en la experiencia con proyectos similares previos es mejorada por considerar diferencias entre los viejos y nuevos proyectos. Las condiciones en que se dieron a lugar los antiguos proyectos, deberán ser tomadas en cuenta. Para este enfoque es necesario que las organizaciones de desarrollo de proyectos, mantengan una base de datos con información respecto a los proyectos desarrollados.

El proyecto es descompuesto en pequeños componentes, y el esfuerzo y costo de desarrollar cada componente es estimado por analogía. Este enfoque se basa en el punto anterior, y por ende las organizaciones de desarrollo mantienen guardados, esfuerzo y costo de los componentes estándares de desarrollo. Ellos debieran ajustarse de acuerdo a características específicas y complejidades relacionadas con componentes equivalentes del desarrollo de un nuevo proyecto.

Variados modelos de estimación cuantitativos han sido desarrollados, de acuerdo a análisis estadístico de datos actuales, en base al esfuerzo y tiempo de desarrollo de muchos proyectos de software. Por ejemplo, algunos modelos de costos, estiman el costo y duración de desarrollo, como una función del tamaño del software y factores de productividad específicos, tal como la experiencia del equipo de desarrollo y la complejidad de la aplicación. Uno de los más populares modelos de costo es COCOMO, desarrollado por Boehm, el cual define el esfuerzo del desarrollo como una función del tamaño del software:

donde el esfuerzo es medido en meses-hombre, y tamaño del software es dado en miles de líneas de código (LOC) entregados a los usuarios (sin contar líneas de comentarios). Los parámetros a y b son determinados por el tipo de proyecto (donde una distinción es hecha entre modelos 'orgánico', 'encajado' y 'semiseparados') y el nivel del modelo COCOMO (distinguiendo entre niveles 'básico', 'intermedio' y 'detallado').

Basado en el esfuerzo, la duración del proyecto ('lapso de tiempo') es estimado como sigue:

donde el parámetro c es determinado por el tipo de proyecto, y el parámetro d es determinado por ambos: el tipo de proyecto y el nivel del modelo.

A pesar de que ellos siendo basados sobre métodos cuantitativos, varios estudios han mostrado que estos modelos de estimación no han cosechado suficientes buenos resultados. Una mayor limitación esta en el uso de la cantidad de líneas de código (LOC) para estimación de otras estadísticas. Este número no es conocido tempranamente en las etapas de desarrollo y su estimación es problemática. Por consiguiente, no es posible obtener buenas estimaciones para el esfuerzo y duración, cuando ellas son necesitadas por la administración del proyecto.

• Hoy en día, el número de líneas de código (LOC) en el modelo COCOMO, no es un factor representativo, si se trabaja con un lenguaje 4GL o 3GL, ya que a modo de ejemplo una instrucción en un lenguaje de alto nivel, tal como Visual Basic, podría equivaler a 50 instrucciones en Lenguaje COBOL.

• En los lenguajes Orientados a Objetos, existe el concepto de Encapsulamiento, el cual traduce el código neto de la aplicación, a un mínimo de líneas de trabajo.

Cuándo y para que se debería usar el Modelo COCOMO?

La funcionalidad del sistema expresa la variedad de funciones que el sistema de software provee a sus usuarios. Los modelos de estimación de software se basan sobre la funcionalidad, y no dependen de las etapas de desarrollo, solo de la especificación del sistema. Por lo tanto, es posible hacer estimaciones una vez que el sistema es especificado en términos funcionales, en un etapa inicial del desarrollo. Enseguida se revisan dos métodos relacionados.

Este método, desarrollado por Albrecht y Gaffney, es ampliamente conocido en Estados Unidos y Europa. El método estima el tamaño del software, contando los 'puntos por función' del sistema. Esto es realizado en tres pasos.

Primero: Se calcula el 'conteo de función sin ajuste' (UFC). De acuerdo al modelo, un sistema de Software consiste de cinco tipos de componentes:

1. Entradas externas.
2. Salidas externas.
3. Consultas externas.
4. Archivos lógicos internos.
5. Archivos de interfaces externas.

Para cada uno de estos tipos de componentes, el número de itemes en el sistema es contabilizado, y el nivel de complejidad es determinado (distinguiendo entre 3 niveles: simple, mediano y complejo). Cada nivel tiene una importancia o peso (provisto por el modelo). El UFC es calculado como sigue:

Segundo: Se calcula el 'factor de complejidad técnica' (TFC). El factor de complejidad del sistema es determinado de acuerdo a 14 atributos técnicos (ver anexo A). Cada atributo le es asignado un peso entre 0 (como mínimo) hasta 5 (el valor más alto). El TCF es calculado como sigue:

donde Fi es el peso del atributo i.

Tercero: El tamaño del sistema es calculado en términos del número de 'puntos por función' (FP):

Para usar el método, el departamento de desarrollo de software tiene que mantener una base de datos de los proyectos, la cual debería incluir datos de su duración (lapso de tiempo), horas de trabajo, puntos por función (FPs), productividad (FPs por hora), etc. Basado en esta base de datos, el costo (en términos de tiempo y costo) de un FP puede ser calculado. Una vez realizado esto, el FP de cualquier proyecto nuevo, puede ser calculado de acuerdo a lo formulado anteriormente, y así los costos estimados son derivados.

Estudios empíricos sobre métodos de puntos por función revelan que existe una alta correlación entre el esfuerzo de desarrollo y la funcionalidad del sistema. Sin embargo, algunos estudios señalan ciertas limitaciones:

• El método no siempre define claramente como contar el número de puntos por función de cada componente. Sin un claro acuerdo de que o como contar, es difícil de obtener estimaciones exactas que permitan comparar proyectos diferentes.

• El peso de los componentes que han sido determinados por Albrecht y Gaffney son basados sobre el análisis de desarrollo de proyectos en un ambiente IBM; ellos no son necesariamente validos para desarrollo de proyectos en otros tipos de ambientes.

• El TCF (factor de complejidad técnica) es calculada según 14 atributos específicos. No es razonable pensar que un conjunto constante de atributos pueda determinar la complejidad de algún sistema.

Este método, desarrollado por Symons, es una versión mejorada del método de puntos por función de Albrecht y Gaffney. Este calcula los FPs multiplicando dos factores:

• Tamaño de la información procesada y
• Ajuste de complejidad técnica

• Tamaño de información procesada.

Según éste método, un sistema contiene transacciones lógicas. Una transacción realiza un proceso de negocio aislado. Según esto cada transacción consiste de:

1. una o más tipos de entradas.
2. un proceso.
3. uno o más tipos de salidas.

El factor 'tamaño de la información procesada' es medido por el número de puntos por función sin ajustar (UFPs), contados en todas las transacciones del sistema. Para cada transacción el UFP es calculado como:

donde WI, WE y WO son pesos calibrados. (El termino 'tipos de entidad' significa archivos de la base de datos o relaciones.) El método provee reglas para contar números de tipos de datos elementales y tipos de entidades en una transacción. El total UFPs de un sistema es la suma de UFPs de sus transacciones.

• Ajuste de complejidad técnica

El método FP Mk -II utiliza el enfoque de Albrecht y Gaffney con los siguientes ajustes:

• El número de atributos sobre el cual el factor de ajuste es basado es 19 (en vez de 14). Por otra parte, el usuario podría agregar más atributos que son específicos al proyecto en cuestión.

• El peso de cada atributo puede ser calibrado (a diferencia del método de puntos por función donde los pesos son fijos).

El factor TCA (Ajuste de complejidad técnica) es calculado como sigue:

donde C puede ser calibrado por el usuario. En el modelo de Symons el valor de C es 0.005, lo cual significa que las características de la aplicación tienen poca influencia.

El tamaño del sistema, expresado en puntos por función (FPs) es calculado como sigue:

Basado en el número de FPs, dos estimaciones mayores pueden ser obtenidas.

• Primero:

donde esfuerzo es medido en horas de trabajo, y Productividad es medido en FPs por hora. Productividad es la tasa normal del equipo de desarrollo; puede ser determinada de acuerdo a desempeños pasados del grupo de desarrollo en proyectos y ambientes de desarrollo similares (incluyendo el nivel de lenguaje de programación, ya sea en 3GL o 4gl), registrados en la base de datos de los proyectos. El coeficiente B depende del tipo de sistema: en el caso de sistemas en línea (o tiempo real) B=1 y en el caso de sistemas sea batch o por lote, B=1.5.

• Segundo:

donde la duración es medida en lapso de semanas y la entrega es medido en FPs por lapso de semana. El rango normal de entrega puede ser determinado de acuerdo a desempeños pasados, similar a la productividad.

Ambos, la Productividad y la Entrega, y ahora las estimaciones de Esfuerzo y Duración, pueden ser influenciadas y ajustadas según factores de riesgo asociados con los proyectos específicos en cuestión. El factor de riesgo incluye:

1. Tamaño del proyecto: existen más riesgos si el proyecto es grande y el equipo de desarrollo no tiene experiencia con esta clase de proyectos, contrario a pequeños proyectos y un experimentado equipo de desarrollo;
2. Problema de estructura: existen más riesgos si el proyecto trata con problemas no estructurados, contrario a los que tratan con problemas estructurados, o similares a los existentes y proyectos bien documentados.
3. Tecnología: existe más riesgos si el grupo de desarrollo utiliza nuevos métodos y herramientas, contrario a usar los ya existentes.

El método de estimación Mk -II ha sido implementado para un a conteo automático de FP en varias herramientas CASE, incluyendo 'Ingeniero de Sistemas' (de LBMS) y el 'Arquitecto de Sistemas' (de Bramco).

Una importante ventaja del método Mk-II es que la medición del tamaño es basado sobre las transacciones lógicas del sistema. El tamaño de cada transacción es determinado según el número de tipos de datos elementales incluyendo sus entradas y salidas, y el número de tipos de entidades (es decir, relaciones de la base de datos), que son accesadas. El problema, sin embargo, es que la administración del proyecto debe reconocer las transacciones del sistema y los componentes de cada transacción en una etapa inicial del desarrollo del sistema.

• El componente de entrada. Se asume que existen 6 tipos de datos elementales en el diseño de las pantallas de entrada para el flujos de dato 'transacción del cliente' desde E1 (cliente) a la función 2: cust-iD (identificación del cliente), acc.-number (número de acceso), name (nombre), acc.-type (tipo de acceso), type-of-trans (tipo de transacción), amount (cantidad).

• El componente de salida. Existen dos salidas en esta transacción: una es un mensaje de 'mala transacción' en pantalla (por ejemplo, si la cantidad excede el balance), y la otra es una copia impresa de la transacción. Se asume que el número total de tipos de datos elementales en las dos salidas es 14.

• El componente de proceso. En el DFD se observa, que la función 2 lee desde el almacén de datos D1, la función 3 lee desde D2 y la función 4 escribe en D2. Pero, según el método Mk-II, se debe mirar las relaciones de la base de datos que son accesadas por las transacciones, y no a los almacenes de datos. Se asume que como un resultado del proceso de diseño de la base de datos, que las siguientes tres relaciones primarias han sido obtenidas desde los almacenes de datos originales D1 y D2:

El método Puntos por Función, desarrollado por Albretch y Gaffney, hace énfasis en los puntos por función de un sistema. Este posee ciertas desventajas, tales como por ejemplo, que el factor de Complejidad Técnica es calculado de acuerdo a 14 atributos específicos, según esto, no es razonable pensar, que un conjunto constante de atributos, pueda determinar la complejidad de todo sistema. En base a lo anterior, el modelo tiende a ser muy rígido o poco flexible, imposibilitando al administrador, ajustar el enfoque a características específicas del sistema.

El método Mk-II es un enfoque mejorado, que se basa en el modelo anterior. Este incluye ahora 19 atributos (en vez de 14), además permite que el administrador incluya sus propios atributos para acomodar el modelo a la realidad del sistema. Otra característica importante del método, es que la medida del tamaño del procesamiento de la información, se basa en las transacciones lógicas del sistema.

• Information and Software Technology, Volumen 39, año 1997, págs. 855-865. Autores: Peretz Shoval, Opher Feldman.

• Ingeniería del Software, Tercera Edición. Autor: Roger Pressman

1. Comunicación de datos.
2. Funciones distribuidas.
3. Desempeño.
4. Compleja configuración usada.
5. Transacciones.
6. Entrada de datos en línea.
7. Eficiencia para el usuario final.
8. Actualización en línea.
9. Procesamiento complejo.
10. Reusabilidad.
11. Facilidad de instalación.
12. Facilidad de operación.
13. Múltiples lugares.
14. Facilidad de cambios.