Alumno: Gilces Zambrano Alex F. Tema: Modelos de estimacin de costo para proyectos informticos.

Fecha: 15 de noviembre de 2012

Modelos histricos
Tal vez el mtodo ms utilizado todava para realizar la estimacin de costes es el que se basa en la experiencia personal de quien la lleva a cabo (por ejemplo, el jefe de proyecto). Como podis suponer, se trata de un mtodo marcadamente subjetivo y muy propenso a errores. Puede ocurrir que quien realice la estimacin no tenga en cuenta de manera adecuada todos los aspectos que pueden intervenir en el proyecto y tambin puede suceder que la experiencia disponible no se corresponda en absoluto con el tipo de proyecto o de aplicacin que se debe efectuar. Este sistema se puede aplicar tanto a mtodos descendentes, como a mtodos ascendentes. En el segundo caso, se realizan estimaciones independientes de cada uno de los subproyectos o de las fases (e incluso de las actividades concretas, si ya se tiene claro cules sern) para obtener la estimacin del proyecto completo sumando las estimaciones de las diferentes partes.

Combinacin de estimaciones individuales

Puede ocurrir que, cuando el proyecto tiene una cierta envergadura, se pida la opinin de ms de un experto y se tenga que combinar dos o tres estimaciones. En este caso, existen diferentes tcnicas para intentar encontrar una combinacin adecuada, sobre todo para evitar que, en reuniones conjuntas, el estimador con ms personalidad imponga su criterio sobre el resto. A continuacin mencionamos tres de estas tcnicas: a) Media. La manera ms sencilla de llegar a una combinacin adecuada es, simplemente, calcular la media entre las diferentes estimaciones obtenidas por separado. b) Media ponderada. Otro procedimiento consiste en tener en cuenta que pueden darse estimaciones pesimistas y optimistas y que se deben tener en cuenta de una manera diferente a otras estimaciones intermedias. Lo que se hace, pues, en lugar de calcular la media habitual, es establecer una media ponderada, que podra ser, por ejemplo, en el caso de tres estimaciones, la que recomendaba Pressman en las primeras ediciones de su libro Ingeniera del Software:

Donde e es la estimacin final, o es la estimacin ms optimista, p la ms pesimista y n la que ha quedado en el medio. c) Tcnicas de Delphi. ste es el procedimiento ms serio y complejo. Fue elaborado por la Rand Corporation en 1948 para evitar las reuniones de grupo entre estimadores, debido a la peligrosa dinmica que tenan. La idea es que diferentes estimadores den

por separado su estimacin despus de haber estudiado el proyecto. Estos resultados se trasladan annimamente a los otros estimadores, que, de esta manera, pueden matizar y rehacer la propia estimacin considerando lo que han propuesto los dems. El proceso se repite tantas veces como sea necesario hasta conseguir una cierta convergencia que sea al menos satisfactoria a los ojos del coordinador del proceso. Si as no se llega a la convergencia deseada, el coordinador discute personalmente con cada estimador las diferencias encontradas con el fin tratar de forzar una solucin aceptable para todo el mundo.

Modelos empricos o estadsticos

La idea de los modelos empricos es aprovechar el estudio estadstico de los datos reales disponibles medidos en un conjunto ms o menos numeroso de proyectos ya acabados. Se intenta buscar frmulas que relacionen el esfuerzo con las diferentes variables que puedan incidir en ste. En primer lugar, en los aos sesenta, se intent aproximar los datos estadsticos disponibles con expresiones lineales del tipo siguiente:

En esta expresin, E es el esfuerzo, a menudo medido en personas-mes, xi son las diferentes variables o los atributos que se cree que inciden en el coste, a menudo denominadas CDA, mientras que ci son los coeficientes que resultan de la aproximacin estadstica a partir de los datos disponibles procedentes de proyectos anteriores ya acabados y bien medidos.

De hecho, bien pronto se observ que los modelos lineales no eran correctos y rpidamente se abandon este planteamiento para intentar encontrar frmulas de tipo exponencial de la manera siguiente:

Donde E es el esfuerzo medido en personas-mes, L es el tamao estimado del proyecto en KLOC, mientras que a, b y c son los coeficientes que resultan de la aproximacin estadstica de los datos disponibles. El trmino adicional m(x), que no todos los modelos utilizan, es un elemento de ajuste para tener en cuenta ms datos que simplemente el tamao del proyecto expresado en KLOC. De hecho, el trmino m(x) es aqu el equivalente a las caractersticas generales

que completaban y permitan ajustar los puntos de funcin de Albrecht deducidos de las caractersticas funcionales. La idea bsica es que el esfuerzo tal vez no depende slo del tamao (las lneas de cdigo) y que se dan otros factores que influyen en este proceso. La mayora de modelos empricos se obtuvieron durante los aos setenta, dato que se debe tener en cuenta, ya que se utilizaban datos de proyectos que no se parecen a los proyectos de ahora. Muy a menudo los datos de esfuerzo que ofrecen los modelos empricos son exagerados, ya que hoy la productividad en la construccin de software es bastante ms alta. Siempre se debe tener en cuenta recordar la base de datos de gestin de los proyectos que se utilizaron para establecer los coeficientes del modelo. Presentamos, a continuacin, un par de ejemplos de modelos estadsticos que ya se han convertido en clsicos.

1) El modelo de Walston y Felix

El primer ejemplo de modelo estadstico es el estudio, publicado en el ao 1977, que Walston y Felix realizaron tomando como base sesenta proyectos acabados entre 1973 y 1977. Se trataba, posiblemente, de los primeros proyectos disponibles, no eran homogneos (aparecan diferentes lenguajes de programacin, diferentes ordenadores y aplicaciones diversas) y, adems, eran de varios tamaos (de 12 a 11.758 meseshombre y de 460 a 467.000 LOC). Los coeficientes eran a = 0, b = 5,2 y c = 0,91 y la frmula en este caso es la siguiente:

Tambin se obtenan otras informaciones, como la duracin en meses del proyecto (D), el nmero de personas implicadas (P) y el nmero de pginas de documentacin (DOCK), gracias a las frmulas siguientes:

2) El modelo de Bailey y Basili

Otro ejemplo clsico es el de Bailey y Basili, publicado en el ao 1981, recogiendo datos de dieciocho proyectos ms homogneos, todos del Goddard Space Center de la NASA y programados en Fortran. En este caso, los coeficientes son a = 5,5, b = 0,73 y c = 1,16; es decir, se obtiene la expresin siguiente:

Debera sorprender el hecho de que el exponente de las KLOC sea inferior a la unidad en el caso de Walston y Felix, mientras que es claramente superior a la unidad en el caso de Bailey y Basili. La razn es que, en el estudio de Walston y Felix, entre las LOC se contaba hasta un mximo del 50% de comentarios, mientras que en el estudio de Bailey y Basili, como en la gran mayora de los modelos estadsticos, no se incluyen los comentarios en el recuento de las LOC. Tambin se da una gran variedad de frmulas obtenidas a partir de datos procedentes de diferentes proyectos, entre ellas algunas que relacionan el esfuerzo con los puntos de funcin de Albrecht. Cabe tener en cuenta que los resultados de esfuerzo que se obtienen en los diferentes modelos no tienen en absoluto por qu coincidir, ya que reflejan datos extrados de proyectos diferentes y no siempre comparables ni homogneos. De hecho, los modelos estadsticos mencionados se consideran ahora obsoletos del todo y proporcionan slo un margen altsimo para una estimacin razonable. Modelos posteriores, como el COCOMO de Boehm, han mejorado y han actualizado los datos y las frmulas.

Modelos tericos: el modelo de Putman

En un artculo de 1978, Lawrence H. Putman comenz a plantear la necesidad de modelos tericos que, prescindiendo de la posibilidad de disponer o no de datos de proyectos ya acabados, tuvieran en cuenta la manera de distribuir el esfuerzo en el desarrollo de un proyecto de construccin de software. Putman adopt la distribucin de esfuerzos en el tiempo que marca la forma de la curva de Rayleigh/Norden que se muestra en la figura siguiente:

El estudio de la curva permite, entre otras cosas, relacionar el esfuerzo (K, en personas-ao), las lneas de cdigo (L, en KLOC) y el tiempo total de desarrollo del proyecto ( , en meses) segn la frmula:

La idea es que, a partir de un esfuerzo (K) y un tiempo de desarrollo ( ), la frmula indica la productividad en la construccin de software y nos da el nmero de KLOC que se obtienen. La frmula incluye una constante denominada constante tecnolgica ( ), que, en palabras de Putman, es en cierta manera una medida del estado de la tecnologa que se aplica al proyecto. La constante refleja el efecto en la productividad de una multitud de factores como el hardware y sus limitaciones, la complejidad de los programas, la experiencia del personal (tanto tcnicos como usuarios), el entorno de desarrollo y programacin, etc. Esto es lo que provoca que el mtodo terico de Putman no se convierta nunca en obsoleto. Se trata de ir cambiando los valores de la constante tecnolgica a medida que cambian los entornos de desarrollo y programacin. El problema es que conocer el valor correcto de no es en absoluto sencillo. Al principio, Putman indicaba una serie discreta de veinte valores de que podan situarse entre 610 y 57.314. La , pues, poda moverse desde un valor bastante bajo, 610, hasta otro que es casi cien veces ms alto. Es decir, el papel de esta constante es totalmente fundamental en el modelo. En el ao 1981, Putman presentaba por primera vez su modelo insertado en una herramienta automatizada denominada SLIM, que, a partir de diferentes preguntas, determina la constante tecnolgica correspondiente. El modelo de Putman, en su ltima versin, identifica la frmula anterior como la denominada ecuacin del software y, adems, descompone la constante tecnolgica en dos nuevas constantes:

Donde P es el parmetro de productividad (que sera de 28.000 en el caso de aplicaciones de la informtica de gestin) y B es un factor especial de habilidad que se incrementa lentamente a medida que crecen la necesidad de integracin, las pruebas, la garanta de calidad, la documentacin y otras exigencias que disminuyen la productividad. En la prctica, hoy el modelo de Putman slo puede ser bien utilizado por aquellos que adquieren el SLIM, la herramienta informtica que implementa el modelo completo.

Esta herramienta se actualiza constantemente con las sucesivas adaptaciones de las nuevas tecnologas de desarrollo de software. El SLIM es capaz, despus de una larga batera de preguntas, de determinar Ck y el resto de datos que interesan para la estimacin de un proyecto. Pero la manera de llevarlo a cabo se encuentra en el interior de la herramienta informatizada. En cualquier caso, es bueno saber que el modelo de Putman se prob y valid con una serie homognea de proyectos del Departamento de Defensa de EE.UU. Las conclusiones a las que se lleg mostraban que el modelo es bastante correcto para proyectos muy grandes y que el resultado es mucho ms impreciso y dudoso en el caso de proyectos pequeos y medios. Por otra parte, sin disponer de la herramienta informtica SLIM, el estimador que quiera utilizar el modelo de Putman ha de intentar determinar por su cuenta una constante tecnolgica (Ck) de gran efecto en el resultado final: un trabajo que es prcticamente imposible sin el SLIM.

Modelos compuestos: los modelos COCOMO de Barry W. Boehm

COCOMO es el modelo de construccin de costes ms conocido y utilizado de los modelos algortmicos compuestos que se basan sobre todo en datos estadsticos, pero tambin en ecuaciones analticas y en un ajuste fruto de la opinin de expertos. El modelo es obra de Barry W. Boehm y se public por primera vez en el libro de 1981 Software Engineering Economics. Despus ha tenido varias versiones, como Ada COCOMO, desarrollado a mitad de los aos ochenta para proyectos programados con Ada, y, sobre todo, el actual proyecto COCOMO II, en el que Boehm colabora en su esarrollo, en el Center for Software Engineering (CSE) de la Universidad del Sur de California (University of Southern California, USC). Cabe mencionar que las diversas versiones del software tienen objetivos diferentes y que la ltima versin (COCOMO II) no sustituye en absoluto a las anteriores (COCOMO 81 y Ada COCOMO), que son vlidas siempre que se utilicen los paradigmas de construccin de software y el ciclo de vida y las herramientas para los cuales se definieron. Al ser el modelo ms aceptado, famoso y utilizado, es fcil encontrar muchas implementaciones informatizadas como, por ejemplo, el COSTAR (Software Cost Estimation Tool), una herramienta ya clsica de la empresa Softstar Systems, que, a partir del COSTAR 5.0, implementa ya el COCOMO II. El COCOMO clsico de 1981 El COCOMO clsico lo forman, en realidad, tres modelos diferentes, que tienen en cuenta diferentes grados de complejidad:

1) El COCOMO bsico es un modelo esttico vlido para obtener una estimacin rpida del esfuerzo (meses-hombre) en funcin del tamao (KLOC) al inicio del ciclo de vida. 2) El COCOMO intermedio aade al clculo del esfuerzo en funcin del tamao, el efecto de unos atributos que influyen en el coste (CDA), con los cuales se quiere tener en cuenta el tipo de aplicacin y tecnologa, las calificaciones y la experiencia del personal, el entorno de diseo y programacin y las herramientas de las que dispone, etc. 3) El COCOMO adelantado incorpora todas las caractersticas de la versin intermedia, pero en lugar de evaluar los CDA con un nico valor para todo el ciclo de vida, tiene en cuenta diferentes CDA para cada fase de la construccin del software. Las ecuaciones del modelo COCOMO tienen siempre la forma general que mostramos a continuacin:

Donde E es el esfuerzo (en personas-mes), L son las lneas de cdigo (en KLOC), T es el tiempo de desarrollo del proyecto (en meses) y CDA los cost driven attributes que, recordmoslo, no se utilizan en el modelo bsico. Finalmente, a, b, c y d son coeficientes que el modelo proporciona como resultado del anlisis de los datos de sesenta y tres proyectos realizados entre 1965 y 1980, escritos en cinco lenguajes diferentes, de tamaos que varan de 2 a 1.000 KLOC y con una productividad que se sita entre 28 y 250 LOC por persona-mes. Adems de los tres modelos, COCOMO tiene en cuenta varios tipos de proyecto, ya que no se obtienen los mismos datos de productividad en todos los casos. En la nomenclatura que utiliza Boehm, los tres tipos de proyecto son los que presentamos a continuacin: a) Orgnico. Proyectos relativamente pequeos y sencillos, con poca innovacin tecnolgica, donde trabaja un pequeo equipo formado por gente que tiene suficiente experiencia en el tipo de aplicacin concreto y que, adems, debe tener requerimientos poco rgidos. b) Semiacoplado. Proyectos de nivel intermedio en tamao, complejidad y sofisticacin tcnica, donde varios equipos diferentes colaboran para construir una aplicacin con requerimientos medianamente rgidos. c) Encajado. Proyectos de un tamao y complejidad francamente elevados, donde intervienen varios equipos diferentes y los requerimientos, tanto de hardware como de software, son muy rgidos. Se debe tener en cuenta que, en la informtica de gestin, posiblemente slo tengan sentido los proyectos orgnicos o semiacoplados y que, tal como dice Pressman, los

proyectos encajados sugieren otro tipo de sistemas informticos con requerimientos muy rgidos. Los coeficientes que corresponden al modelo bsico, a menudo ms que suficiente para una primera estimacin de pequeas aplicaciones en la informtica de gestin, se recogen en la tabla siguiente:

En el modelo intermedio los coeficientes son los de esta otra tabla:

En este modelo, adems de no cambiar la relacin entre esfuerzo y tiempo (coeficientes c y d, respectivamente), puede ser sorprendente la tendencia descendente del coeficiente a. Sera como si el esfuerzo disminuyera al ser ms complejo el proyecto. Realmente no es as, ya que el modelo intermedio utiliza, adems, los atributos que influyen en el coste (CDA). En el modelo intermedio, los atributos que influyen en el coste (CDA) son quince parmetros que recogen caractersticas del producto que se va a realizar, del ordenador en el que se trabaja y que ejecutar la aplicacin, del personal que forma el equipo del proyecto y del proyecto mismo. Cada uno de estos quince parmetros puede tomar diferentes valores: muy bajo, bajo, nominal, alto, muy alto y extra alto que varan en torno a la unidad. La tabla siguiente muestra los valores de los CDA.

Bibliografa Barcel, M. Estimacin de costes de un proyecto informtico (pag. 35-44).