COMBINACION DE ALTERNATIVAS PARA LAESTIMACION DE PROYECTOS SOFTWARE

Gramajo, E., García-Martínez, R., Rossi, B., Claverie, E. y Britos, P.

CAPIS - CENTRO DE ACTUALIZACION PERMANENTE EN INGENIERIA DE SOFTWARE

RESUMEN

La utilización de metodologías tradicionales para la estimación de proyectos softwareha resuelto correctamente la necesidad de conocer la duración de un proyecto comouna variable dependiente de los recursos a emplear. Se propone en este trabajo lacombinación de las técnicas de Puntos de Función y COCOMO para establecer unaestimación dependiente de un conjunto de variables consideradas en un proyecto paraestablecer una estimación mas precisa del mismo. Se plantean en el trabajo aspectoscríticos que necesitan ser profundizados a fin de obtener un aprovechamiento mayor delos métodos descriptos.

Palabras Clave

Puntos de Función – Estimación de proyectos – COCOMO – Duración proyecto –Orientado a Objetos

1. INTRODUCCIÓN

Actualmente se dispone de técnicas para estimación de proyectos que permiten larealización de evaluaciones más precisas que las obtenidas a través de métodostradicionales (orientadas a calcular individualmente el esfuerzo correspondiente a cadauna de las actividades del mismo).

Se analizarán dos de ellas, Puntos de Función (International Function Point usersGroup. Function Point Counting Practices Manual) y COCOMO (Londeix B, CostEstimation for Software Development) a fin de examinar no solo sus ventajas sinotambién sus aspectos críticos con el propósito de mostrar que mediante la interacciónde ambas pueden subsanarse algunos de ellos.

Por último se presentará como caso de estudio un análisis comparativo de laestimación de un proyecto en función de diferentes lenguajes de programación autilizar, para la implementación del diseño, con la finalidad de comparar su variaciónrespecto de las variables mencionadas.

2. MÉTODO TRADICIONAL

Las distintas metodologías tradicionales de estimación de (Böem B.W.,SoftwareEngineering Economics) proporcionan un dato básico (horas hombre) a aplicar alproyecto, entendiéndose por ésta a cantidad de horas a utilizar, a partir de lo cual ymediante la utilización de diversos ratios tales como pesos/hora u horas/personapueden deducirse otros valores de estimación como el costo, personal involucrado, etc.

Basándonos en la experiencia recogida en la actividad profesional (ITBA-CAPIS.Carpetas de la Carrera de Posgrado en Ingeniería del Software) se planteanbasicamente dos situaciones (que son ejemplificadas en la figura 1, en la cual semuestra el proceso de estimación de acuerdo al enfoque tradicional que determina lashoras hombre necesarias a partir de las que se calculan los costos y en función de losplazos de entrega acordados, se llega finalmente a establecer la cantidad de personala utilizar).

Primera Situación: Tiene que ver con el costo estimado del proyecto (a partir deestimar horas hombre) el cual está directamente relacionado alratio utilizado y considerando los plazos de entrega se converge aun valor que satisfaga a las partes involucradas.

Figura 1: Enfoque tradicional para estimación de proyectos

Segunda Situación: Está íntimamente relacionado con la estimación del tiempo total delproyecto ya que es determinado por dos criterios que normalmentese oponen según nos refiramos al punto de vista del usuario o deldesarrollador.

Para explicar mejor la idea y simplificándola podemos sintetizar que el desarrolladortratará de extender el proyecto lo máximo posible a fin de asegurar su cumplimiento yel usuario, por el contrario pretenderá reducirlo.

Dado que los métodos tradicionales proporcionan una medida de las horas hombrenecesarias para aplicar al proyecto, la discusión se centra en la asignación de personalde manera de acortar proporcionalmente el tiempo total en función de aumentar aquellavariable.

Si bien para los desarrolladores es claro que ello no es así (normalmente se recurre aanalogías del estilo de “... si una persona puede pintar una habitación en diez días nopuede pensarse que diez personas pudieran hacerlo en un día ...”), éstos no disponende argumentos con base científica que puedan explicar esta situación cuando se tratade proyectos de desarrollo de software.

Esto lleva invariablemente a la utilización de explicaciones que tienen mas que ver conel sentido común y la experiencia que con justificaciones elaboradas con fundamento.

Dicha situación acarrea un inconveniente adicional producido por el establecimiento defechas de entrega que pueden resultar imposibles de cumplir cuando se acuerdan bajola presión del usuario o bien por la necesidad del desarrollador de cumpliranticipadamente un proyecto.

Como síntesis de lo expresado sería deseable utilizar técnicas que no solamenteposibilitaran calcular las horas hombre a aplicar al desarrollo de un proyecto sino

ESTIMAR

HORAS

HOMBRE

ESTIMAR

EL

COSTO

DETERMINAR

PLAZOS

DE ENTREGA

DETERMINAR

EL PERSONAL

INVOLUCRADO

también estimar un valor de la duración del mismo dado por sus característicasintrínsecas independientemente de los recursos a emplear.

3. MÉTODOS ALTERNATIVOS

La utilización de dos métodos, Puntos de Función (Park R.E, Checklist and Criteria forEvaluating the Cost and Schedule Estimating Capabilities of Software organizations) yCOCOMO (Burril C.W, Modern Project Management) en forma conjunta permitiríamejorar la situación descripta en la sección precedente.

El método COCOMO permite determinar los valores de las siguientes dos variables:

• meses/hombre a aplicar al proyecto

• meses totales del proyecto (dependiendo de factores tales como losatributos de fiabilidad requerida del software, tamaño de la base de datos,complejidad del producto, limitaciones en el tiempo de ejecución, limitaciones dememoria principal, volatilidad de la máquina virtual, frecuencia de cambio en elmodelo de explotación del ordenador, capacitación de los analistas, experienciaen aplicaciones, capacitación de los programadores, experiencia en la máquinavirtual, experiencia en el lenguaje de programación, prácticas modernas deprogramación, uso de herramientas para el desarrollo del software y limitacionesen la planificación).

En la figura 2 se presenta un esquema de estimación que proporciona además de lashoras hombre a emplear el tiempo total del proyecto (basándose para ello en elconocimiento previo de la cantidad de sentencias de código del proyecto) lo quepermite determinar el plazo de entrega. Mostrándose, además, como a partir de estosdos valores (horas hombre y tiempo total) y simplemente por el cociente de ambos seobtiene la cantidad de recursos (personas) para llevarlo a cabo. A partir de allí sepuede elaborar el costo mediante la aplicación de ratios, de igual forma que en lasmetodologías tradicionales.

Figura 2: Estimación de proyectos por método COCOMO

Debe tenerse en cuenta que la duración total del proyecto es un valor teórico y quepuede disminuirse incrementando los recursos (personas) a emplear aunque el

ESTIMAR

HORAS

HOMBRE

ESTIMAR

EL

COSTO

ESTABLECER

PLAZO DE

ENTREGA

DETERMINAR

EL PERSONAL

INVOLUCRADO

ESTIMAR

TIEMPO

TOTAL

Determinarlíneas de

código

impacto, en razón de lo expresado anteriormente, será menor (puede alcanzar a un20% menos) que el esfuerzo aplicado a tal efecto.

Esta técnica requiere de un dato elemental determinado por la cantidad de sentenciasde código del proyecto a la que posteriormente se aplican diferentes algoritmos quevarían de acuerdo al modelo de desarrollo elegido (Orgánico, Semilibre o Libre) (ITBA-CAPIS. Carpetas de la Carrera de Posgrado en Ingeniería del Software. Imprenta delITBA) para entallarlo finalmente de acuerdo a factores de ajuste seleccionados a partirde las características específicas del proyecto.

Esta información se convierte en el aspecto crítico del método ya que ese valor es unparámetro difícil de determinar con exactitud y puede variar considerablemente segúnlas metodologías de desarrollo utilizadas (Burril C.W, Modern Project Management).

El camino para resolver este aspecto crítico es mediante la aplicación de otra técnica,la de Puntos de Función (Böem B.W.,Software Engineering Economics).

Según se puede observar en la Figura 3 correspondiente a la metodología deestimación por el método de Puntos de Función, se obtienen los Puntos de Función delsistema que son ajustados de acuerdo a factores predefinidos (Böem B.W.,SoftwareEngineering Economics) tales como atributos de comunicación de datos, frecuenciasdistribuidas, rendimiento, configuraciones fuertemente utilizadas, frecuencia detransacciones, entrada on-line de datos, diseño para la eficiencia del usuario final,actualización on-line, procesos complejos, utilización en otros sistemas, facilidad deinstalación, facilidad de operación, instalación de múltiples sitios y facilidad de cambio,posibilitando a partir de allí el establecimiento, de acuerdo a ratios específicos, de lacantidad de sentencias de código del sistema software.

Este método calcula los puntos de función de un sistema descomponiendo al mismo encinco funciones principales (entradas, salidas, consultas, ficheros internos y externos),asignándoles valores de acuerdo a su complejidad y en función de la cantidad de cadauno de ellos se llega a determinar, mediante su sumatoria, los puntos de función, queson posteriormente ajustados de acuerdo a las características específicas del proyecto(International Function Point users Group).

PUNTOS DE

FUNCIÓN SIN

AJUSTAR

PUNTOS DE

FUNCIÓN

AJUSTADOS

RATIO

LÍNEAS DE CÓDIGO

POR PUNTO DE FUNCIÓN

LÍNEAS DE CÓDIGO

DEL SOFTWARE

Figura 3: Estimación de Proyectos por el método de Puntos de Función

Sobre la base de este valor calculado se obtiene mediante la aplicación de ratiosasociados a las características del lenguaje a utilizar (Cobol, 4GL, etc.) medidos encantidad de sentencias de código por punto de función los valores totales.

Estos ratios permiten establecer la cantidad de instrucciones del software posibilitandode esta forma obtener el dato que es punto de partida para el método COCOMOpreviamente descripto.

En opinión de los autores el método de Puntos de Función presenta un aspecto críticoen lo referido a la reutilización de módulos preexistentes (por ejemplo varias salidassimilares que poseen una misma estructura con variaciones propias de cada una deellas).

En este caso el método las considera a todas diferentes y se miden de la formadescripta anteriormente con lo que se considera que la cantidad de puntos de funcióndaría una cifra superior a la real deformando el número final con la consabidaincidencia (número de sentencias de código del software) en la aplicación del métodoCOCOMO.

A título ilustrativo se muestra en la Tabla 1 la estimación de un proyecto por losmétodos de Puntos de Función y COCOMO analizando la incidencia de los diferenteslenguajes de programación.

Tabla 1: Estudio Comparativo de la estimaciónpara diferentes lenguajes de codificación

Para este ejemplo se seleccionó un proyecto de software referido a un sistema cuyoobjetivo es mejorar el servicio de reclamaciones de clientes de una empresa de saludque dio como resultado un valor de 810 Puntos de Función, analizando la variación delíneas de código de acuerdo al lenguaje utilizado (Pressman R.S, Ingeniería delSoftware) y su incidencia en los diferentes valores de la estimación (meses hombre,tiempo total y costo).

FORTRAN CODE

IDENT. I N D I C A D O R E S FORMULA ASEMBLER COBOL PASCAL ADA 4GL GENERATOR

1 2 3 4 5 6

PUNTOS DE FUNCION

FP Puntos de Función sin ajustar 810 810 810 810 810 810

TDI Grado de influencia 40 40 40 40 40 40

AF Factor de ajuste ( TDI * 0,01) + 0,65 1.05 1.05 1.05 1.05 1.05 1.05

FPA Puntos de Función ajustados FP * AF 851 851 851 851 851 851

LCO Líneas de código por FP 300 100 90 70 20 15

LCOT Líneas de código totales LCO * FPA 255,150 85,050 76,545 59,535 17,010 12,758

KDSI Miles de líneas de código LCOT / 1000 255 85 77 60 17 13

COCOMO

CO1 Modelo MM coeficiente 3.00 3.00 3.00 3.00 3.00 3.00PO1 Modelo MM exponente 1.12 1.12 1.12 1.12 1.12 1.12CO2 Modelo TDEV coeficiente 2.50 2.50 2.50 2.50 2.50 2.50PO2 Modelo TDEV exponenete 0.35 0.35 0.35 0.35 0.35 0.35

MM Esfuerzo C01 * (KDSI ** P01) 1488 435 386 292 72 52

FA Coeficiente esfuerzo 1.06 1.06 1.06 1.06 1.06 1.06

MMF Esfuerzo final MM * FA 1,578 461 410 309 76 55

TDEV Tiempo de desarrollo C02 * (MMF ** P02) 33 21 21 19 11 10

NPER Cantidad de personas MMF / TDEV 48 22 20 17 7 5

CPRO Costo mensual por persona 2,500 2,500 2,500 2,500 2,500 2,500

CTOT Costo final CPRO * NPER 3,944,375 1,152,398 1,024,127 772,880 190,001 137,665

Por otra parte se utilizó para la estimación por COCOMO un modo Semilibre modelointermedio (ITBA-CAPIS. Carpetas de la Carrera de Posgrado en Ingeniería delSoftware) y cabe hacer notar que en los valores obtenidos no se consideró la incidenciaproducida por la reutilización de módulos preexistentes lo que hubiera significado unadisminución considerable de los valores resultantes.

Del análisis de la referida tabla y tomando como referencia los valores extremos, esdecir considerando la implementación sobre un lenguaje ensamblador (columna 1) y ungenerador de código (columna 6) surgen algunas consideraciones importantes dedestacar:

• Las sentencias de código por punto de función (LCO) se reducen a la treinta avaparte.

• El esfuerzo final (MMF) correspondiente a la cantidad de meses hombre aemplear en el proyecto mantiene una relación aproximada a la descriptaanteriormente.

• El costo final (CTOT) también se reduce en la misma proporción.

• El Tiempo (TDEV) correspondiente al tiempo total del Proyecto solamente sereduce a la tercera parte.

Este análisis podría extenderse a cualquier combinación de los diferentes lenguajes deimplementación del diseño con resultados similares.

Puede concluirse, entonces, que el tiempo total de duración de un proyecto estárelacionado con las características propias del mismo y no depende directamente de ellenguaje de implementación del diseño como así tampoco de la cantidad de personal autilizar, sino que esta última es una consecuencia directa de los dos valores estimadospor el metodo (Meses Hombre Totales MMF y Tiempo Total del Proyecto TDEV).

A fin de complementar el análisis se han determinado valores estimativos del costo porpersona para obtener una estimación económica del proyecto en cuestión.

4. CONCLUSIONES

Si bien existen dos factores fundamentales a examinar en la estimación de un proyectosoftware, su duración y costo, la importancia cada vez mayor que toma la informacióncomo factor estratégico ha determinado que sea la duración de un proyecto uno de losaspectos mas prioritarios en su realización.

Como síntesis de lo expresado anteriormente puede decirse que el aspecto crítico delos métodos tradicionales de estimación de proyectos software radica en laimposibilidad de establecer una unidad de medida para la estimación de la duracióntotal del proyecto como un valor dependiente de las características del mismo y no soloen función de los recursos humanos a emplear.

Como alternativa se propuso en este trabajo la utilización combinada de dos métodos(Puntos de Función y COCOMO) tendientes a proporcionar una estimación mas precisatratándolos de la siguiente forma:

Primero la aplicación del método de Puntos de Función para determinar las sentenciasde código del proyecto software, la cual mantiene una distorsión, producida por noconsiderar esta técnica la reutilización de módulos preexistentes.

En segundo lugar la aplicación del método COCOMO partiendo de la informaciónproducida por el anterior (sentencias de código) para llegar a una estimación precisa delas horas hombre a aplicar y fundamentalmente a la estimación de la duración total delproyecto.

Finalmente y basándonos en que el paradigma de objetos considera la reusabilidadcomo un factor básico y entendiendo que el método descripto (PUNTOS DE FUNCIÓN)pareciera no tomar en cuenta estas características, queda planteado a partir delpresente trabajo, una línea de investigación tendiente a analizar la incidencia de lasmetodologías orientadas a objetos en esta técnica de estimación a fin de elaborar losfactores de ajuste necesarios para reducir la distorsión provocada.

5. REFERENCIAS

Böem B.W.,Software Engineering Economics, Prentice Hal. 1981

Burril C.W, Modern Project Management, Burril-Ellsworth Associates. 1980.

International Function Point users Group. Function Point Counting Practices Manual.Release 4.0. 1994.

ITBA-CAPIS. Carpetas de la Carrera de Posgrado en Ingeniería del Software. Imprentadel ITBA. Edición 1996.

Londeix B, Cost Estimation for Software Development, Addison-Wesley PublishersCompany. 1997.

Park R.E, Checklist and Criteria for Evaluating the Cost and Schedule EstimatingCapabilities of Software organizations. CMU/SEI-95-SR-005. Enero 1995.

Pressman R.S, Ingeniería del Software. Un enfoque práctico. Mc Grow Hill. 1994