ESTIMACION DE COSTOS DE PROYECTOS DE SISTEMAS DE INFORMACIONhttp://ingenieroduqueescobar.blogspot.com/2010/06/estimacion-de-costos-de-proyectos-de_19.html

1.1. Estimacin de costos de ProyectoLa estimacin y al calendarizacin del proyecto se llevan a cabo de forma conjunta. Sin embargo. En las primeras etapas del proyecto se requieren algunas estimaciones de costos, antes de que se tenga la calendarizacin detallada. Estas estimaciones son necesarias para establecer un presupuesto para el proyecto o para asignar un precio para el software de un cliente.

Una vez que el proyecto se encamina, las estimaciones se actualizan de forma regular. Esto ayuda al proceso de planeacin y permite la utilizacin efectiva de los recursos. Si el gasto real es significativamente ms grande que las estimaciones, entonces el administrador del proyecto debe tomar algunas acciones. Estas pueden ser solicitar recursos adicionales para el proyecto o modificar el trabajo a realizar.

Existen tres parmetros involucrados en el clculo del costo total de un proyecto de desarrollo de software:

Los costos del hardware y software, incluyendo mantenimiento; Los costos de viajes y capacitacin; Los costos de esfuerzo (los costos de pago a los ingenieros de software)

Para muchos proyectos, el costo dominante es el costo de esfuerzo. Las computadoras que son suficientemente poderosas como para desarrollar el software son relativamente baratas. Aunque los costos de viajes pueden ser importantes si un proyecto se desarrolla en sitios distintos, son relativamente bajos para muchos proyectos. Adems el uso de correos electrnico, fax y teleconferencias reduce los viajes requeridos.

Los costos de esfuerzo no son simplemente los relacionados a los salarios de los ingenieros de software involucrados en el proyecto. Las organizaciones calculan los costos de esfuerzo en trminos de los costos de sobrecarga donde se toma en cuenta el costo total de hacer funcionar la organizacin y dividen este entre el nmero de personas productivas. Por lo tanto los siguientes costos son parte de los costos de esfuerzo totales:

a. Los costos de proveer, calentar e iluminar oficinas.b. Los costos del personal de apoyo como los contadores, secretarias, limpiadores y tcnicos.c. Los costos de las redes y las comunicaciones.d. Los costos de los recursos centralizados como las bibliotecas, los recursos recreativos, etctera.e. Los costos de seguridad social y de beneficio de empleados como las pensiones y los seguros de salud.

FACTORDESCRIPCIONOportunidad de mercadoUna organizacin de desarrollo podra cotizar un bajo precio debido a que desea moverse a un nuevo mercado del software. Aceptar un bajo beneficio en un proyecto podra darle la oportunidad de obtener ms beneficios posteriormente. La experiencia obtenida le permite desarrollar nuevos productos.Incertidumbre en la estimacin de costosSi una organizacin esta insegura de su costo estimado por alguna contingencia puede incrementar su precio por encima del beneficio normal.Trminos contractualesUn cliente puede estar dispuesto a permitir que el desarrollador retenga la propiedad del cdigo fuente y que reutilice dicho cdigo en otros proyecto. Por lo tanto, el precio cargado podra ser menor que si el cdigo fuente del software se le entrega al cliente.Volatilidad de los requerimientosSi es probable que los requerimientos cambien, una organizacin puede reducir los precios para ganar un contrato. Despus de que el contrato se asigna, se cargan precios altos a los cambios en los requerimientos.Salud financieraLos desarrolladores en dificultades financieras podran bajar sus precios para obtener un contrato. Es mejo tener beneficios ms bajos que los normales o incluso quebrar antes que quedar fuera de los negocios.Cuadro 1: Los factores que afectan la asignacin de precios al software.

Tpicamente, este factor de sobrecarga es alrededor de dos veces el salario del ingeniero de software, dependiendo del tamao de la organizacin y sus sobrecargas asociadas. Por lo tanto, si un ingeniero de software se le pagan $90 000 al ao, el costo total de la organizacin es de $180 000 por ao a $15 000 por mes.

Calcular los costos del software se debe llevar a cabo de forma objetiva con el fin de predecir de forma precisa cuanto le cotara al contratista desarrollar el software. Si los costos del proyecto se calculan como parte de una oferta a un cliente, entonces se tiene que tomar una decisin del precio que se le dar al cliente. Por lo general, el precio es simplemente el costo ms el beneficio. Sin embargo, la relacin entre el costo del proyecto y el precio al cliente por lo regular no es tan simple.

Asignar un precio al software debe tomar en cuenta consideraciones organizacionales, econmica, polticas y de negocios. En el cuadro N1 se muestran los factores que se deben tomar en cuenta. Por lo tanto, no existe una relacin sencilla entre el precio que se le da al cliente por el software y los costos de desarrollo. Debido a las consideraciones organizacionales involucradas, asignar el precio del proyecto por lo general le concierne al administrador principal de la organizacin, as como a los administradores del proyecto de software.

1.1.1. ProductividadLa productividad en un sistema de manufactura se mide contando el nmero de unidades que se producen y dividiendo ste entre el nmero de personas-hora requeridas para producirlas. Sin embargo, para cualquier problema de software, existen muchas soluciones diferentes con distintos atributos. Una solucin podra ejecutarse de forma ms eficiente mientras que otra podra ser ms legible y fcil de mantener. Cuando se producen soluciones con diferentes atributos, no tiene sentido comparar estas tasas de produccin.

Sin embargo, los administradores tienen que estimar la productividad de los ingenieros en el proceso de desarrollo de software. Estas estimaciones son necesarias para la estimacin del proyecto y para valorar si los procesos o las mejoras tecnolgicas son efectivas. Por lo general, estas estimaciones de productividad se basan en medir algunos atributos del software y dividir el resultado entre el esfuerzo total requerido para el desarrollo. Existen dos tipos de medidas utilizadas:

1.1.1.1. Medidas relacionadas con el tamaoEstas se relacionan con el tamao de alguna salida de una actividad. La medida ms comn relacionada con el tamao son las lneas de cdigo fuente entregadas. Otras medidas que se utilizan son el numero de instrucciones de cdigo objeto entregado o el nmero de pginas de la documentacin.

1.1.1.2. Medidas relacionadas con la funcinEstas se relacionan con la funcionalidad total del software entregado. La productividad se expresa en trminos de la cantidad de funcionalidad til producida en un tiempo dado. Los puntos de funcin y los puntos de objeto son las medidas ms conocidas de este tipo.

Las lneas de cdigo fuente por programador-mes son una mtrica ampliamente utilizada en la medida de la productividad. Esta se calcula contando de nmero total de lneas del cdigo fuente que se entrega. La cuenta se divide entre el tiempo total de programadores-mes requeridos para completar el proyecto. Por lo tanto, este tiempo incluye el tiempo requerido para el anlisis y diseo, codificacin, pruebas y documentacin.

Este enfoque se desarrollo cuando muchos de los programas estaban en FORTRAN, lenguaje ensamblador o COBOL. Entonces, los programas se tecleaban en tarjetas, con una instruccin en cada tarjeta. El nmero de lneas del cdigo era fcil de calcular. Corresponda al nmero de tarjetas en la cabina de tarjetas. Sin embargo, los programadores en lenguajes como JAVA o C++ consisten de declaraciones, instrucciones ejecutables; otras cuentan las instrucciones ejecutables y comentarios. Incluyen macroinstrucciones que ocupan varias lneas de cdigo. Existe ms de una instruccin por lnea. Por lo tanto, no existe una relacin sencilla entre las instrucciones del programa y las lneas de un listado.

Algunas tcnicas de conteo de lneas consideran solo las instrucciones ejecutables; otras cuentan las instrucciones ejecutables y las de datos; algunas cuentan cada lnea que no est en blanco en el programa, independientemente de lo que est en esa lnea. Se han propuesto estndares para el conteo de lneas para varios lenguajes (Park, 1992) pero stos no son ampliamente conocidos. Las comparaciones de productividad en las organizaciones son imposibles a menos que cada organizacin utilice el mismo mtodo para contar las lneas de cdigo.

Comparar la productividad de los diferentes lenguajes de programacin tambin da impresiones engaosas de productividad del programador. Entre ms expresivo sea un lenguaje de programacin, ms baja es la productividad aparente. Esta anomala surge debido a que todas las actividades de desarrollo de software se consideran de forma conjunta cuando se calcula la productividad pero la mtrica utilizada slo aplica a los procesos de programacin.

AnlisisDiseoCodificacinPruebasDocumentacinCdigo ensamblador3 semanas5 semanas8 semanas10 semanas2 semanasLenguaje de alto nivel3 semanas5 semanas8 semanas6 semanas2 semanasTamaoEsfuerzoProductividadCuadro 2. Tiempos de desarrollo del sistema.Cdigo ensamblador5000 lneas28 semanas714lneas/mesLenguaje de alto nivel1500 lneas20 semanas300 lneas/mes

Por ejemplo, considere un sistema que podra codificarse con 5000 lneas de cdigo ensamblador o 1500 lneas de cdigo en un lenguaje de alto nivel. En el cuadro 2 se muestra el tiempo de desarrollo para las diversas fases. El programador en lenguaje de alto nivel menos de la mitad de estas, 300 lneas/mes. As los costos de desarrollo para el sistema en lenguajes de alto nivel son menores y se producen en menor tiempo.

Una alternativa a la utilizacin del tamao del cdigo como atributo estimado del producto es utilizar alguna medida de la funcionalidad del cdigo. Esto evitara la anterior anomala puesto que la funcionalidad del cdigo. Esto evitar la anterior anomala puesto que la funcionalidad es independiente de la implementacin del lenguaje. MacDonell (1994) brevemente describe y compara varias medidas diferentes basadas en la funcin.

La ms conocida de estas medidas es el conteo de puntos de funcin. ste fue propuesto por Albrecht (1979) y refinado por Albretch y Gaffney (1983). Los puntos de funcin son independientes del lenguaje por lo que se puede comparar la productividad en los diversos lenguajes de programacin. La productividad se expresa como puntos de funcin producidos por personas-mes. Los puntos de funcin son adecuados para sistemas de procesamiento de datos que estn dominados por operaciones de entrada y salida. Un punto de funcin no es una caracterstica simple sino que es una combinacin de caractersticas del programa. El nmero total de puntos de funcin en un programa se calcula midiendo o estimando las siguientes caractersticas del programa:

Entradas y salidas externas. Interacciones con el usuario. Interfaces externas. Archivos utilizados por el sistema.

Cada una de estas se evala de forma individual acorde a su complejidad y se le asigna un valor de peso que vara desde 3 (para las entradas externas sencillas) hasta 15 (para los archivos internos complejos). Se pueden utilizar los valores de peso propuestos por Albretch o valores basados en la experiencia local.

El conteo de los puntos de funcin no ajustados (UFC) se calcula multiplicando los conteos llanos por el peso estimado y sumando todos los valores.

UFC =

Despus, este conteo inicial de puntos de funcin es modificado por factores cuyo valor se basa en la complejidad total del proyecto. Esto toma en cuenta el grado de procesamiento distribuido, la cantidad de reutilizacin, el desempeo, etctera. El conteo de puntos de funcin no ajustados se multiplica por los factores de complejidad del proyecto para producir un conteo de puntos funcin final.

Symons (1988) observo que la naturaleza subjetiva de la complejidad de las estimaciones implicaba que el conteo de puntos de funcin en un programa depende de la persona que hace la estimacin. Varias personas tienen nociones diferentes de complejidad. Existe una amplia variedad de conteos de puntos de funcin, dependiendo del juicio del estimador. Por esta razn, existen versiones que difieren acerca del valor de los puntos de funcin (Furey y Kitchenham, 1997). Sin embargo, los usuarios argumentan que, a pesar de estos defectos, son efectivos en situaciones prcticas (Kemerer, 1993)

Los puntos de objeto (Banker 1992) son una alternativa para los puntos de funcin cuando se utilizan 4GLs o lenguajes comparables para el desarrollo de software. Los puntos de objeto se utilizan en el modelo de estimacin COCOMO.

Los puntos de objeto no son clases de objetos que se producen cuando se considera un enfoque orientado a objetos para el desarrollo de software. Ms bien, el nmero de puntos de objeto en un programa es una estimacin con peso:

a. El nmero de pantallas independientes que se despliegan. Las pantallas sencillas cuentan como 1 punto de objeto, las pantallas moderadamente complejas cuentan como 2 y las pantallas muy complejas cuentan como 3 puntos de objeto.b. El numero de informes que se producen. Para informes simples, cuentan como 2 puntos objeto, para informes moderadamente complejos, cuentan como 5 y para informes que son difciles de producir, cuentan como 8 puntos objeto.c. El numero de mdulos 3GL que deben desarrollarse para complementar el cdigo 4GL- cada mdulo 3GL cuenta como 10 puntos de objeto.

La ventaja de utilizar puntos de objeto en lugar de puntos de funcin es que son ms fciles de estimar a partir de la especificacin del software de alto nivel. Los puntos de objeto solo se refieren a las pantallas, informes y mdulos 3GL.

Si se utilizaran los puntos de funcin o los puntos de objeto, entonces se pueden estimar en las primeras etapas del proceso de desarrollo. Las estimaciones de estos parmetros se pueden hacer tan pronto como se diseen las interacciones externas del sistema. En esta etapa, es muy difcil producir una estimacin precisa del tamao de un programa en lneas de cdigo fuente. En efecto, tal vez el lenguaje de programacin a utilizar aun no est decidido. Las primeras estimaciones son esenciales cuando se utilizan los modelos de estimacin de costos algortmicos.

Los conteos de los puntos de funcin se pueden utilizar junto con las tcnicas de estimacin de lneas de cdigo. El nmero de puntos de funcin se utiliza para estimar el tamao final del cdigo, AVC, en un lenguaje particular requerido para implementar un punto de funcin. El tamao estimado del cdigo para una nueva aplicacin se calcula como se muestra a continuacin:

Tamao del cdigo = AVC x Nmero de puntos de funcin.

FACTORDESCRIPCIONExperiencia en el dominio de la aplicacinConocer el dominio de la aplicacin es esencial para el desarrollo efectivo de software. Los ingenieros que ya conocen un dominio son probablemente los ms productivos.Calidad del procesoEl proceso de desarrollo utilizado puede tener un efecto importante en la productividad.Tamao del proyectoEntre ms grande sea un proyecto, se requiere ms tiempo para las comunicaciones del equipo. Se dispone de menos tiempo para el desarrollo por lo que la productividad individual se reduce.Apoyo tecnolgicoLa productividad se puede mejorar si se tiene buen apoyo tecnolgico como de la herramientas CASE, de sistemas de administracin de la configuracin, etctera.Ambiente de trabajoUn entorno de trabajo silencioso con reas de trabajo privado contribuye a mejorar la productividad.Cuadro 3: Los factores que afectan la productividad de la ingeniera de software.

La productividad de los ingenieros que trabajan en una organizacin se ve afectada por varios factores. Algunos de los ms importantes se resumen en el cuadro 3. Sin embargo, las diferencias individuales en la habilidad son ms importantes que cualquiera de estos factores. En una primera valoracin de la productividad encontraron que algunos programadores eran diez veces ms productivos que otros. La experiencia seala que esto an es cierto. Los equipos grandes tienen una mezcla de habilidades por lo que tiene una productividad promedio. Sin embargo, en los equipos pequeos la productividad total depende en gran medida de las aptitudes y habilidades individuales.

No existe algo similar a un valor Promedio para la productividad que aplique a los dominios de aplicacin y a las organizaciones. Para sistemas incrustados, grandes y complejos, la productividad es tan baja como 900 lneas/mes. Cuando se mide en trminos de de puntos de objeto. Bohem seala que la productividad vara desde cuatro puntos de objeto por mes hasta 50 puntos de objeto/mes dependiendo de la herramienta de apoyo y de la capacidad del desarrollador.

El problema cuando estas medidas se expresan como volumen/tiempo es que no toman en cuenta las caractersticas no funcionales del software como la fiabilidad, el mantenimiento, etc.

1.1.2. Tcnicas de estimacinNo existe una forma simple de hacer una estimacin precisa del esfuerzo requerido para desarrollar un sistema de software. Las estimaciones iniciales se hacen bajo la base de la definicin de requerimientos de usuario de alto nivel. El software tiene que ejecutarse en computadoras poco familiares o utilizar nuevas tecnologas de desarrollo. Probablemente no se conozcan las personas involucradas en el proyecto y sus habilidades. Todos estos factores significan que en una primera etapa del proyecto es difcil producir una estimacin precisa de los costos de desarrollo del sistema.

Por lo general, las estimaciones de los costos del proyecto se cumplen por su propia naturaleza. La estimacin se utiliza para definir el presupuesto del proyecto y el producto se ajusta par que las cifras del presupuesto se cumplan. No se conocen informes de experimentos controlados sobre los costos de los proyectos donde los costos estimados no se utilicen para ajustar el experimento. Un experimento controlado no revelara la estimacin del costo al administrador del proyecto. Los costos reales tendran que compararse con los estimados del proyecto.

A pesar de esto, las organizaciones necesitan hacer esfuerzos de software y estimaciones de los costos. Para hacerlo, se utilizan una o ms de las tcnicas descritas en el siguiente cuadro.

FACTORDESCRIPCIONModelado del algoritmo de costosSe desarrolla un modelo utilizando informacin histrica de costos que relaciona alguna mtrica de software (por lo general, su tamao) con el costo del proyecto. Se hace una estimacin de esa mtrica y el modelo predice el esfuerzo requerido.Opinin de expertosSe consultan varios expertos en las tcnicas de desarrollo de software propuestas y en el dominio de aplicacin. Cada uno de ellos estima el costo del proyecto. Estas estimaciones se comparan y discute. El proceso de estimacin se itera hasta que se acuerda una estimacin.Estimacin por analogaEsta tcnica es aplicable cuando otros proyectos en el mismo dominio de aplicacin se han completado. Se estima el costo de un nuevo proyecto por analoga con estos proyectos completados Myers (1989) da una descripcin muy clara de este enfoque.Ley de ParkinsonLa ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles ms que por los objetivos logrados. Si el software se tiene que entregar en 12 meses t se dispone de cinco personas el esfuerzo requerido se estima en 60 personas-mesAsignar precios para ganarEl costo del software se estima independientemente de lo que el cliente est dispuesto a pagar por el proyecto. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software.Cuadro 4: Tcnicas de estimacin de costos.

Cuando se estiman costos de software, los administradores deben tomar en cuenta que existen diferencias importantes entre los proyectos anteriores y los futuros. Una gran variedad de nuevos mtodos y tcnicas de desarrollo han aparecido en los ltimos diez aos. Muchos administradores tienen poca experiencia en estas tcnicas o poco conocimiento de cmo estas afectan los costos de los proyectos. Algunos ejemplos de los cambios que afectan las estimaciones de acuerdo con la experiencia son:

Desarrollo orientado a objetos en lugar de desarrollo orientado a funciones. Sistemas cliente-servidor en lugar de sistemas basados en mainframes. Utilizacin de componentes de software comerciales en lugar de desarrollo de componentes. Desarrollar y reutilizar en lugar de desarrollar todas las partes de un sistema. La utilizacin de herramientas CASE y generadores de programas en lugar de desarrollo de software sin ayuda.

Todos estos factores han difcil que los administradores produzcan estimaciones precisas de los costos de produccin del software. Su experiencia previa no es relevante para ayudarles a estimar los costos del proyecto de software.

1.1.3. Modelado algortmico de costosEl enfoque ms sistemtico, aunque no necesariamente el ms preciso, para la estimacin del software es la estimacin algortmica de costos. Un modelo algortmico de costos se construye analizando los costos y atributos de los proyectos realizados. Se utiliza una frmula matemtica para predecir los costos basados en estimaciones del tamao del proyecto, nmero de programadores y otros factores de los procesos y productos Kitchenham (1990) describe 13 modelos algortmicos de costos desarrollados a partir de observaciones empricas.

En su forma general, una estimacin algortmica de costos para el software se expresa como:

Esfuerzo = A x Tamao B x M

Esta frmula A es un factor constante que depende de las practicas organizacionales locales y del tipo de software que se desarrolla. Tamao es una valoracin del tamao del cdigo del software o una estimacin de la funcionalidad expresada en puntos de funcin o de objetos. El valor de exponente B por lo general se encuentra entre 1 y 1.5. Refleja el esfuerzo requerido para proyectos grandes. M es un multiplicador generado al combinar diferentes procesos, atributos del producto y del desarrollo.

Todos los modelos algortmicos padecen las mismas dificultades bsicas.

a. A menudo es difcil estimar Tamao en una primera etapa de un proyecto donde solamente est disponible la especificacin. Las estimaciones de los putos de funcin y los puntos de objeto son los ms fciles de producir que las del tamao del cdigo pero puede ser imprecisas.b. Las estimaciones de los factores B y M son subjetivas. Las estimaciones varan de una persona a otra, dependiendo de su conocimiento y experiencia.

1.1.3.1. El modelo COCOMOSe han propuesto varios modelos algortmicos como una base para estimar el esfuerzo, la calendarizacin y los costos de un proyecto de software. stos son similares conceptualmente pero utilizan diferentes valores en sus parmetros. El modelo especifico que se discute aqu es el modelo COCOMO. ste es un modelo emprico. Se obtuvo recolectando datos de varios proyecto de software grandes y despus analizando esos datos para descubrir formulas que se ajustaran mejor a las observaciones. Eleg COCOMO por las siguientes razones.

a. Est bien documentado, es de dominio pblico y lo apoyan el dominio pblico y las herramientas comerciales.b. Se ha utilizado y evaluado muy ampliamente.c. Tienen una gran tradicin desde su primera versin en 1981 (Bohem, 1981), pasando por un refinamiento para el desarrollo de software en ADA (Bohem y Royce 1989) gasta su versin ms reciente publicada en 1995. (Bohem, 1995)

La primera versin del modelo COCOMO (conocida como COCOMO 81) fue un modelo de tres niveles donde estos reflejaban el detalle del anlisis de la estimacin del costo. El primer nivel (bsico) provee una estimacin inicial burda, el segundo nivel modifica utilizando varios multiplicadores del proyecto y el proceso, y el nivel ms detallado produce estimaciones para las diferentes fases del proyecto. El siguiente cuadro muestra la formula bsica de COCOMO para los diferentes tipos de proyectos.

Complejidad del proyectoFrmulaDescripcinSIMPLEPM = 2.4 (KDSI)1.05 x MAplicaciones bien comprendidas desarrolladas por equipos pequeos.MODERADAPM = 3.0 (KDSI)1.12 x MProyectos ms complejos donde los miembros del equipo tienen experiencia limitada en sistemas relacionados.INCRUSTADAPM = 3.6 (KDSI)1.20 x MProyectos complejos donde el software es parte de un complejo fuertemente acoplado de hardware, software, reglas y procedimientos operacionales.Cuadro 5: El modelo bsico de COCOMO 81

1.1.3.2. Modelo algortmico de costos en la planeacin del proyectoLos administradores de proyectos pueden utilizar un modelo algortmico de costos para comparar las diferentes formas de invertir dinero para reducir los costos del proyecto. Esto es particularmente importante donde existen costos e hardware/software comerciales y donde se necesita reclutar nuevo persona con habilidades especificas para el proyecto.

Considere un sistema incrustado para controlar un experimento que se lanzar al espacio. Los experimentos espaciales tienen que ser muy fiables y estn sujetos a lmites de peso rigurosos. El numero de chips es una tarjeta electrnica tiene que minimizarse. En trminos del modelo COCOMO, los multiplicadores correspondientes a las restricciones y la fiabilidad de la computadora son ms grandes que 1.

Existen tres componentes a ser tomados en cuenta en el costo de este proyecto:

a. El costo del hardware objetivo que ejecuta el sistema.b. El costo de la plataforma (computadora mas hardware) para desarrollar el sistema.c. El costo del esfuerzo requerido para desarrollar el software.

1.1.4. Duracin y personal del proyectoAs como es necesario estimar el esfuerzo requerido para desarrollar un sistema de software y los costos totales del esfuerzo, los administradores de proyectos tambin estiman cunto durara el desarrollo del software y cuanto personal se necesita para trabaje en el proyecto. El tiempo de desarrollo del proyecto se denomina duracin del proyecto. Cada vez ms, las organizaciones demandan tiempos de duracin ms cortos para que sus productos salgan al mercado antes que los de sus competidores.

La relacin entre el nmero de personas que trabajan en un proyecto, el esfuerzo total requerido y el tiempo de desarrollo no es lineal. En cuanto crezca el nmero de personal, se necesitara ms esfuerzo. Las personas deben invertir ms tiempo en comunicarse. Se requiere ms de un tiempo para definir las interfaces entre las partes del sistema. Doblar el nmero de personas (por ejemplo) no significa que la duracin del proyecto se reducir a la mitad.

1.2. Estimacin De Costos De ProyectoCualquier tarea pasada por alto inadvertidamente durante el periodo de estimacin, dar como resultado un menosprecio del proyecto en su totalidad, este hecho, a su vez podra comprometer la planificacin del factor tiempo y de los recursos que se deben utilizar y, lo que es peor, habr que pagar un trabajo omitido, no en base al presupuesto, sino en base a los beneficios esperados.Toda empresa con experiencia en la ejecucin de proyectos software debe de elaborar unas listas de comprobacin para cotejar con las listas de trabajo del propio proyecto para salvaguardar omisiones. Repetimos que cualquier detalle pasado por alto en la fase del estudio del esfuerzo a aplicar puede tener consecuencias importantes, no slo en la dimensin temporal del proyecto, sino en la calidad del producto a obtener o en el calendario del propio proyecto.Existen muchos estudios sobre las tcnicas de estimacin de costes, el objetivo de la presente leccin no es presentar al alumno una descripcin de todas y cada una de ellas, pero s de las ms utilizadas, por eso presentamos la tcnica de los puntos funcin de Albrecht (IBM), el COCOMO (Constructive Cost Method) de Boehm y la estimacin de Putman.El ms utilizado es el de los puntos funcin de Albrecht cuya originalidad proviene de estimar los costes en funcin de la complejidad de los aspectos externos, o funciones, del propio programa. Por otra parte est bastante extendido el mtodo COCOMO de Boehm que se describe en su libro 1 "Software Engineering Economics", y presenta una tcnica del modelo a tres niveles segn la complejidad de los proyectos aportando herramientas para controlar el coste, no slo del diseo y desarrollo del sistema, sino que cubre todos los aspectos en la estimacin de todo el proyecto a lo largo de su ciclo de vida, excepto el estudio de viabilidad, puesta en marcha y mantenimiento.1.2.1. Modelos EmpricosUna vez asentados sus conocimientos sobre las fases en que se divide un proyecto software desde las perspectivas de los distintos paradigmas de la Ingeniera del Software se considera, en lneas generales, que todo proceso de desarrollo de software est compuesto por tres fases genricas que son: definicin, desarrollo y mantenimiento, y en todos ellos tenemos que considerar los modelos de estimacin de costes, que si bien en Informtica no son relativamente novedosos, ya que los primeros esbozos en estudiar este problema comenzaron hace poco ms de dos dcadas, la implantacin real en la industria no se ha realizado de forma masiva hasta que se ha dado el hecho de que el software se ha convertido en el factor ms costoso de un sistema de informacin; es ms: la desviacin producida por los costes de software en el desarrollo de un proyecto tena poca incidencia en el coste total, cosa que no ocurre hoy da ya que un error de estimacin del tiempo de desarrollo puede colocar el proyecto entre el beneficio y la prdida econmica.Los modelos de estimacin tienen aplicacin dentro de la fase de definicin de un sistema software. En esta fase lo que se define es el qu, es decir, se intenta identificar en ella qu informacin va a ser procesada, qu funcin y rendimiento se desea, qu interfaces han de establecerse, qu ligaduras de diseo existen y, por ltimo, qu criterios de validacin se requieren para definir un sistema correcto. Dentro de la mayor parte de las organizaciones, la estimacin de costes de un sistema software est basada en experiencias pasadas. Los datos histricos se usan para identificar los factores de coste y determinar la importancia relativa de los diversos factores dentro de la organizacin. Lo anteriormente expuesto implica que los datos de coste y productividad de los proyectos actuales deben de ser centralizados y almacenados para su empleo posterior. La estimacin de costes puede llevarse a cabo de forma jerrquica hacia abajo (Top-Down) o jerrquica hacia arriba (Bottom-Up).La estimacin jerrquica hacia abajo se enfoca primero a los costes a nivel del sistema, adems de los costes del manejo de la configuracin, del control de calidad, de la integracin del sistema, del entrenamiento y de la documentacin. Los costes del personal relacionado se estiman mediante el examen del coste de proyectos anteriores que resulten similares. En la estimacin jerrquica hacia arriba, primero se estima el coste del desarrollo de cada mdulo o subsistema, tales costes se integran para obtener un coste total. La tcnica puede fallar al no considerar los costes del manejo de la configuracin o del control de calidad, pero tiene la ventaja de enfocarse directamente a los costes del sistema. Podemos establecer una clasificacin de los llamados modelos empricos de estimacin de costes basados en la experiencia:1.2.1.1. Juicio de expertoEn esta categora un experto o grupo de expertos estudia las especificaciones y hace su estimacin (jerrquica hacia arriba o hacia abajo) en base a sus conocimientos previos. Cuando hay un nico experto se denomina juicio experto puro y la empresa corre el riesgo de confiar una tarea tan importante a una nica persona. Si desaparece el experto se deja de estimar. Si es un grupo de expertos el que estima se suele utilizar el mtodo Delphi o juicio experto. Este mtodo consiste en que el grupo se rene para dar sus opiniones sobre la estimacin. Las conclusiones individuales se envan al coordinador del grupo que las compara entre s. Si los resultados son parecidos la estimacin se da por buena, si no es as cada estimador recibe informacin sobre su estimacin, y las ajenas pero de forma annima. Cada uno revisa su propia estimacin y la enva de nuevo al coordinador. Se repite el proceso hasta que la estimacin converge de forma razonable. Es posible realizar nuevas reuniones del grupo si el coordinador lo considera oportuno segn la divergencia de las estimaciones recibidas Tiene la ventaja de que las estimaciones de un grupo suelen ser mejores que las individuales y que el experto nico no se convierte en un recurso crtico imprescindible.1.2.1.2. AnalogaConsiste en comparar las especificaciones de un proyecto, con las de otros proyectos similares segn el tamao, complejidad, nmero y tipo de usuarios y otros factores como sistemas operativos, hardware, personal, etc.1.2.1.3. Distribucin de la utilizacin de los recursos durante el ciclo de vida.Este mtodo solo se puede aplicar cuando el proyecto ya ha comenzado y se ha desarrollado alguna de sus fases. Usualmente las organizaciones tienen una estructura de costes similar entre las distintas fases del ciclo de vida (especificaciones, anlisis, diseo, construccin, prueba e implantacin) de sus proyectos. Si en un proyecto ya hemos realizado algunas fases, es de esperar que los costes se distribuyan de manera proporcional en las fases siguientes.1.2.1.4. Mtodo basado exclusivamente en los recursos.En la estimacin consiste en ver de cuanto personal disponemos para el proyecto y durante cunto tiempo se dispone de l. Estos sern los recursos a utilizar. Se basa en la siguiente premisa El trabajo se expande hasta consumir todos los recursos disponibles (Ley de Parkinson).1.2.1.5. Mtodo basado exclusivamente en el mercado.Parte de que lo ms importante es conseguir el contrato. El precio se fija en funcin de lo que creemos que est dispuesto a pagar el cliente. La estimacin de costes del proyecto ser el precio a pagar por el cliente menos los beneficios econmicos que se desea obtener.1.2.2. Puntos FuncinLas Mtricas Orientadas a la Funcin se basan en estimar no el nmero de lneas fuente del programa (LDC) sino su "funcionalidad". Estas mtricas, propuestas inicialmente por Albretch en 1979 y 1983, intentan buscar un factor de productividad del software mediante el mtodo denominado de anlisis de los puntos funcin 2. Los puntos de funcin se obtienen como consecuencia de haber estudiado distintos proyectos de software y haber aplicado sobre ellos una mtrica basada en la complejidad y el tamao de la funcin realizada.La medida del punto funcin se ha aplicado con xito en sistemas no empotrados y concretamente en sistemas comerciales y puede no ser relevante en otros sistemas de ingeniera.Las mtricas orientadas al tamao son bastante polmicas y no estn aceptadas universalmente como el mejor mtodo para medir la productividad en el desarrollo del software ya que el nmero de lneas de cdigo escrito no parece una buena medida. Sus defensores dicen que esta medida es fcil de aplicar y que puede ser calculada fcilmente en base a la experiencia y que existe una gran cantidad de informacin basada en las LDC. Sus detractores dicen que las LDC dependen del lenguaje de programacin, que perjudica a los programas ms cortos pero mejor diseados y que su utilizacin requiere un nivel de detalle que puede ser difcil de conseguir.El anlisis de los puntos funcin se basa en establecer relaciones entre los componentes bsicos de cada tarea y el esfuerzo requerido en desarrollarlos. El procedimiento a seguir para calcular los puntos funcin consiste en ir rellenando los datos de una serie de tabla, basada en la experiencia, en las que se introducen algunos datos respecto a variables del proyecto como pudieran ser el nmero de entradas, el nmero de salidas, la cantidad de ficheros que trata la aplicacin, el tamao de los ficheros en nmero de campos, la cantidad de consultas que se pretenden efectuar, etc. Cada uno de estos valores se clasifica en tres categoras respecto a la complejidad que puede ser alta, media o baja. Igualmente se establece una segunda dimensin en cuanto al tamao de cada elemento, clasificndolos en pequeo, medio y grande. En ambas clasificaciones siempre ser ms importante seguir criterios de consistencia sobre criterios de precisin; es decir deber imperar el mtodo de clasificar en grandes grupos todos los elementos de la configuracin.1.2.3. Distribucin Porcentual Del EsfuerzoUn mtodo empleado por muchas compaas es el basado en la distribucin porcentual del trabajo que se emplea en organizaciones donde el tipo de proyectos software que realizan son muy homogneos y se basa en tener estadsticas muy actualizadas de los tiempos medios en satisfacer cada una de las fases del proyecto.En nuestro caso, y segn experiencias anteriores, se sabe que la media de nuestros ltimos trabajos ha supuesto que la fase de diseo supone un porcentaje del tiempo total invertido en cada proyecto con independencia del tamao, y cada una de las fases se distribuye segn el porcentaje expuesto. Con estos criterios se puede estimar, por medio de la extrapolacin, la duracin total del proyecto cuando se ha ejecutado alguna de sus partes.Este mtodo tiene serios inconvenientes, sobre todo cuando los proyectos no son del mismo tamao, ya que no es normal que se disponga de tablas adecuadas para cada tipo de proyectos suficientemente actualizados. No obstante se utiliza bastante como control de validez del mtodo de los Puntos Funcin de Albretch, sobre todo cuando se comparan los porcentajes de ambos mtodos, ya que nos puede ayudar a estudiar dnde se producen las mayores desviaciones por si se trata de errores de clculo o si se han omitido alguna de las fases.Para efectuar esta comparacin se tabulan sobre una hoja de clculo los resultados de cada fase del ciclo de vida y se decide estudiar a detalle aquellos hitos que tengan una desviacin superior al 15%.1.2.4. Modelo CocomoEs un modelo de costes, descrito por Barry W. Boehm en 1981 de tipo algortmico que proporciona estimaciones directas tanto de la duracin como del esfuerzo que est basado en la cantidad de lneas de cdigo fuente escritas en la totalidad. Se trata de un modelo de estimacin emprico que est basado en el paradigma del ciclo de vida clsico o modelo en cascada. Boehm se basa para el desarrollo de su modelo en los diagramas de procesos establecidos en la mayor parte de las metodologas de desarrollos de sistemas informticos clsicas. Las fases que cubre el modelo de Boehm son todas las descritas en el ciclo de vida de productos software con la excepcin del estudio de la viabilidad y el anlisis de requerimientos, los cuales se estiman como un apartado cuantitativo del software de desarrollo. Sin embargo si se incluyen todos los costes incurridos en cada fase.COCOMO es el modelo emprico para la estimacin de los costes de produccin de software ms utilizado por los equipos de desarrollo de sistemas informticos de tamao grande, sin embargo, se deben tener en cuenta los propios comentarios de Boehm sobre COCOMO y por extensin sobre todos los modelos: Hoy en da, un modelo de estimacin de costes est bien realizado si puede estimar los costes de desarrollo de software dentro del 20% de los costes reales, del 70% del tiempo y en su propio campo (o sea dentro de los tipos de proyectos en los que ha sido calibrado). Esto no es tan preciso como quisiramos, pero es lo suficientemente preciso para proporcionar una buena ayuda en el anlisis econmico de la ingeniera del software y en la toma de decisiones.Boehm como: considera que la funcin de distribucin de Rayleight, definida

Donde td es el momento en el que se introduce un esfuerzo mximo, es un estimador exacto para los requisitos de personal para el ciclo de vida del desarrollo (desde el diseo arquitectnico hasta las pruebas del sistema siempre que usemos la porcin de curva entre 0,3t y 1,7 t ). El estimador de Rayleight

Antes de abordar el modelo propiamente dicho, es preciso enumerar una serie de definiciones y consideraciones en las que se basa Boehm para el desarrollo del modelo, como son: El clculo del coste primario est basado en el nmero de instrucciones fuentes desarrolladas en el proyecto sin incluir las lneas de comentarios, pruebas, documentacin, etc., a no ser que se escriban con un fin expreso y cuidado. El periodo de desarrollo cubierto por el modelo comienza al iniciarse la fase de diseo y termina al finalizar la fase de integracin y prueba. El coste y calendario de otras fases se estiman por separado. El modelo cubre nicamente las actividades indicadas dentro del equipo de desarrollo de actividades o procesos del ciclo de vida. Por ello, incluye el esfuerzo de organizacin y documentacin, pero excluye algunos esfuerzos tales como la planificacin de la instalacin, esfuerzo de conversin, etc. Las soluciones se expresan en criterios de la forma hombres-mes refirindose a 152 horas de tiempo de trabajo al mes desarrollado por las personas del equipo de desarrollo. Este factor se ha calculado teniendo en cuenta la experiencia en los distintos proyectos desarrollados y considerando el tiempo de vacaciones. El modelo considera que el proyecto es bien dirigido tanto por el desarrollador del mismo como por el cliente, existiendo por ello muy pocos tiempos perdidos en el anlisis de requerimientos del producto. Considera que la especificacin de requerimientos no tiene cambios sustanciales despus de la fase de planificacin y requerimientos del producto. El modelo avanzado considera que la influencia de los factores conductores de coste del software dependen de cada fase. Los otros modelos slo hacen diferencias entre la etapa de desarrollo y la etapa de mantenimiento. El coste de cada fase incluye todos los costes incurridos durante la fase. Los costes de actualizacin del plan de integracin y prueba y la aceptacin completa de los planes de prueba estn incluidos en la fase de diseo detallado.Para que se cumplan los criterios de estimacin del ciclo de vida desarrollo de software es necesario resaltar las siguientes caractersticas: Se debe de prestar especial cuidado a la definicin y validacin de la especificacin de los requerimientos software por un grupo de personas relativamente pequeo con anterioridad a la entrada en la fase de diseo. Posteriormente se debe de someter la definicin y validacin del diseo del sistema software a un grupo de personas algo ms grande como actividad anterior a la entrada en la fase de diseo detallado y de la codificacin. El diseo detallado, la codificacin y las pruebas de unidades sern desarrollados por un grupo grande de programadores trabajando en paralelo, y siguiendo una lnea base slida que suponga un desarrollo incremental de la planificacin. La integracin y prueba de cada incremento en el sistema est basada en una gran cantidad de planificacin de pruebas tempranas y en la eliminacin de casi todas las unidades defectuosas por medio de cuidadosos y completos recorridos de las unidades desarrolladas. Una parte importante del esfuerzo de documentacin (por ejemplo los borradores de los manuales de usuario) se desarrollar en fases tempranas para proporcionar a los usuarios (y desarrolladores) informacin acerca de la naturaleza operacional del producto.Para ajustar mejor sus estimaciones Boehm cre tres escenarios de estimacin clasificando su modelo de forma jerrquica y en base a la complejidad y cantidad de informacin utilizada en la estimacin; a los que denomin modelos COCOMO que son: Modelo bsico Modelo intermedio Modelo avanzado1.2.4.1. El modelo bsicoEs un modelo esttico, evaluado de forma nica y que calcula el esfuerzo y el coste de desarrollo del software en funcin del tamao del programa expresado en lneas de cdigo estimadas (DSI o LDC). Tamao1.2.4.2. El modelo intermedioCalcula el esfuerzo de desarrollo en funcin del programa y un conjunto de guas de coste que incluyen una evaluacin subjetiva tanto del producto, como del hardware, del personal y de los atributos del proyecto.1.2.4.3. El modelo avanzadoIncorpora todas las caractersticas de la versin intermedia con una evaluacin del impacto de las guas de coste en cada fase (anlisis, diseo, etc.) del proceso de ingeniera del software.1.2.5. Mtodo De Estimacin De PutmanEl modelo de estimacin de Putman es un modelo multivariable dinmico que asume una distribucin especfica del esfuerzo a lo largo del ciclo de vida de un proyecto de desarrollo software. Las curvas mostradas en la figura toman la forma clsica descrita por Lord Rayleight en el ao 1978 y los datos empricos fueron recogidos por Norden.La funcin es de la forma:

Donde C k es una constante de estado de la tecnologa y refleja las restricciones directas que frenan el progreso del programador, K es el esfuerzo necesario medido en personas-hombre durante todo el ciclo de vida, K es el esfuerzo total del desarrollo en personas-ao y td es el tiempo de desarrollo en aos y L el nmero de miles de lneas fuente del proyecto.Algunos valores tpicos de C k pueden ser C k =2000 en entornos de desarrollo tpicos o C k = 8000 en un buen entorno de desarrollo con buena metodologa y herramientas.El valor del esfuerzo se puede despejar de la ecuacin anterior resultando, la ecuacin de la forma:

1.2.6. Herramientas Automticas De Estimacin

Una vez estudiados los distintos modelos empricos de estimacin de costos vamos a sealar como est el estado del arte en la implementacin en programas de usuario:Existe un producto, denominado comercialmente ESTIMACS, que utiliza un modelo basado en los puntos funcin de Albretch mejorado que permiten al planificador ajustarse a distintos factores de personal a la vez que permite llevar varios proyectos en paralelo .El programa COSTAR es una aplicacin directa del modelo COCOMO descrito por el Dr. Barry Boehm en su libro Software Engineering Economics en sus tres modos, y es, seguramente el ms empleado en la industria, permite obtener informacin estimada del esfuerzo del desarrollo del sistema, de los costes y del personal necesario.De este programa existen numerosas versiones, tanto para UNIX, MSDOS y Windows; que la compaa Sunsets actualiza constantemente.

Aspecto del programa COSTAR para MS-DOS.

Algunos avances sobre el modelo se pueden ver aplicados en el programa COSTAR II, que es una ampliacin del programa anterior que soporta una mayor cantidad de modelos de estimacin, incluido el modelo COCOMO II, Para facilitar la planificacin del proyecto, en esta versin del programa, Costar II facialita el supuesto de anlisis de la forma qu pasara si? Adems de comparar distintos planes de proyectos. La riqueza de informes y grficos hacen que Costar II sea, actualmente, la estrella de los programas de estimacin de esfuerzos.La versin de evaluacin permite estimar proyectos de hasta 5000 lneas de cdigo fuente y permite efectuar supuestos sobre la duracin partiendo de personal dedicado al proyecto y su inversa, es decir, qu personal se debe de dedicar en cada una de las fases de desarrollo para satisfacer un calendario previsto segn unas especificaciones dadas.En la versin evaluada (6.0) se ofrecen numerosas intercambiar la informacin con otros programas de Windows, obtener informacin grfica para insertar o adjuntar dentro de ofimticas como puede ser Microsoft Word. Aspecto de Costar IIOtro producto interesante es el SLIM, basado en el modelo de Putnam que permite obtener unos estudios de programacin lineal, la simulacin estadstica y los diagramas PERT en el mismo paquete.Muchas instituciones y casa comerciales tienen herramientas en la red, alguna de ellas como puede ser el caso de la NASA, que presenta el aspecto de la siguiente figura.

Pagina COCOMO de la NASATodos estos productos, hoy da disponible en computadoras personales, permiten calibrar el entorno local de desarrollo y crear un modelo de informacin del software desarrollado mediante sus caractersticas bsicas, los atributos de personal y las consideraciones del entorno.Si en su organizacin no se dispone de software de estimacin de proyectos, se pueden buscar sitios de la red que disponga de software que est ms o menos calibrado a nuestro entorno de desarrollo y a los usos y costumbres del grupo de trabajo concertadas en forma de metodologas.1.2.7. Discusin FinalLa estimacin es una tarea difcil y errtica en la Ingeniera del Software que se fundamenta en medir experiencias pasadas. De todos los modelos de estimacin resulta ser COCOMO el ms universalmente aceptado si bien hay que hacer hincapi en que cualquier mtodo de estimacin se debe de ajustar a la organizacin. Por ello, podemos decir que: una estimacin de costes es slo tan buena como nuestra capacidad de extrapolar al futuro las experiencias pasadas.Una norma de buena costumbre que se suele utilizar en muchas ocasiones es la de comparar los resultados de ambas estimaciones en busca de desviaciones superiores al 15% para poder analizar las diferencias entre los componentes y as decidir si la planificacin ha sido correcta.Debido a que la mayor parte de las estimaciones de costes estn desarrolladas en funcin del nmero estimado de instrucciones del producto final, la estimacin de costes del producto no ser superior a nuestra capacidad de estimar el nmero de instrucciones finales existentes en l.El modelo de Barry W. Boehm proporciona una base firme para desarrollar una estimacin de costes en un sistema software, debido a su adaptabilidad a los distintos sistemas, a su fcil aplicacin y a la consideracin por parte del modelo de la influencia de los factores ms importantes del desarrollo de software.Aunque existen otros modelos de estimacin de costes, como el modelo SLIM de Putnam, el modelo SDC (System Development Corporation) de Nelson, etc., se ha desarrollado el estudio ms profundo del modelo COCOMO debido a que es uno de los ms completos de los existentes, adems de uno de los ms utilizados por las organizaciones para la estimacin de costes en la produccin de grandes sistemas informticos.1.3. Estimacin de costos de ProyectoEl costo de un proyecto es de inters continuo y vital para los coparticipes. Con el precio de produccin equivocado, incluso el producto ms fantstico puede ser un desastre. La estimacin de costo ms sencilla es la que proporciona un costo fijo desde el principio, sin permitir desviaciones en ninguna circunstancia. Aunque las organizaciones muy competentes tienen suficientes aptitudes para cambiar las variables restantes (capacidad, programa de tiempos y calidad) para cumplir con un costo predeterminado, la rigidez absoluta en el costo no siempre se adopta. Suponga, por ejemplo, que un proyecto que desarrolla un producto que se vende muy bien se queda sin fondos cuando lleva el 90%. En lugar de abandonar todo el proyecto, lo comn es que la organizacin haga todo lo posible para encontrar fondos para ese ltimo 10%. Aun cuando el costo del proyecto seas rgido, es necesario estimar el costo de un conjunto dado de requisitos y/o del diseo para asegurar que cumple con el costo acordado y, si no lo hace, cambiarlos y despus hacer la estimacin de nuevo.

El proceso de estimar los costos (esto es, para capacidades, control de calidad y programacin fijas) con frecuencia comienza desde la concepcin del proyecto y continua aun despus de iniciada la codificacin. Cuando se inicia un proyecto, tal vez el equipo tenga slo una idea vaga de su costo. Si la estimacin del costo se puede posponer hasta que el proyecto tome forma, sin duda deben esperar, pero siempre existe la necesidad de estimar por lo menos un intervalo burdo a partir de un resumen de requisitos. Cuando ms se sepa de los requisitos para el producto y mas diseo se realice, ms preciso ser el costo.

El error de estimacin tan grande que indica en la siguiente figura se debe a un estudio reportado por Bohem. Por ejemplo, para una aplicacin que con el tiempo costara $100 000, las estimaciones hechas despus de desarrollar el concepto de la aplicacin pueden ser tan bajas como $25 000 y tan altas como $400 000. Para perfeccionar la estimacin del costo de un proyecto se usan varias tcnicas lo antes posible, lo que significa reducir la altura de las lneas verticales de la figura.

Solo hasta el final del desarrollo se puede tener confianza completa en las estimaciones. (Sin embargo, las estimaciones son menos tiles en ese momento, ya que la mayor parte del dinero est gastado!) Como la precisin es prcticamente imposible, un intervalo es una buena manera de proyectar los costos y esto se aplica al ejemplo anterior.

Sorprende a muchas personas que podamos siquiera pensar en los costos sin un diseo y los requisitos detallados, pero sta es una prctica comn en otros campos. Se puede obtener una estimacin burda del costo de construir una casa, por ejemplo, sin un diseo o los requisitos detallados. Se pueden usar reglas cortas como las casas en esta rea cuestan alrededor de $100 por pie cuadrado de construccin, y as una casa de 100 pies cuadrados costara alrededor de $100 000.

Una buena manera de enfocar la estimacin de costos del proyecto durante las primeras etapas es desarrollar estimaciones de varias maneras independientes y despus combinar resultados. Incluso se pueden ponderar las estimaciones obtenidas de acuerdo con el nivel de confianza personal en cada una de ellas.

Una mquina de coser o un torno es una herramienta compleja que no sirve sin un usuario capacitado. De igual manera la primera vez se usan las medidas de aproximacin de costos es poco probable que los resultados sean confiables. El uso preciso de estas herramientas se aprende con el tiempo, la retroalimentacin y la comprobacin.

1.3.1. Estimacin de lneas de cdigo sin el proceso de puntos de funcinEsta seccin presenta la estimacin de lneas de cdigo en la etapa inicial, mucho antes de iniciar el trabajo de diseo. Una vez realizado ste, los mtodos se basan en las partes del diseo y se vuelven mucho ms precisos.

Varios mtodos de estimacin, como modelo de COCOMO, dependen del nmero de lneas de cdigo (LoC).COCOMO son las siglas abreviadas de modelo de costos constructivo en ingles (CONSTRUCTIVE COST MODELO) de Boehm. En las primeras etapas de un proyecto es posible que COCOMO no parezca muy til debido a que falta mucho para llegar a la codificacin. Sin embargo, cuando un producto se puede comparar con otros, es factible estimar las lneas.

Las organizaciones que trabajan por encima del nivel 1 en los modelos de madurez de capacidades deben poder registrar las personas-hora y la duracin de las partes de los trabajos. En ausencia de este tipo de datos, se tendra que comprar, por ejemplo, nuestro videojuego Encuentro con otros juegos. La obtencin directa de los datos de otras compaas es entre difcil e imposible. Las publicaciones comerciales y de negocios, y los anuncios generales de la industria, en ocasiones proporcionan datos parciales. Por ejemplo, quiz se tenga conocimiento, por los informes pblicos, que BufEye Inc. ha trabajado en sus nuevos juegos durante 3 aos: tal vez incluso mencione un numero de programadores, pero debe sospecharse de estos datos, ya que algunas compaas consideran sus conocimientos sobre desarrollo como un activo corporativo y suelen exagerar estos nmeros o publicar nmeros menores, segn sea el caso.

Cuando se dispone de un historial, tal vez sea necesario comparar el proyecto con proyectos relacionados (para el videojuego pueden ser simulaciones). Digamos que se tiene poca experiencia en la programacin de juegos y alguna en la programacin de simulaciones y Java. La estimacin de lneas de cdigo tal vez incluya algo como lo siguiente:

Una vez escrib una simulacin no grafica de una cola sencilla en C++, que requiri entre 4 y 8 pginas de cdigo, con alrededor de 30 a 50 lneas que no eran comentarios; esto es un total de 120 a 400 lneas. Suponga que Java requiere el mismo nmero de lneas. La primera versin comercial de Encuentro tiene de 4 a 15 colas de este tipo y de 30 a 90 componentes adicionales de tamao comparable para hacerlo interesante, y esto da entre un mnimo de [(120 lneas) x (34 componentes)] y mximo de [(400 lneas) x (105 componentes)] para nuestro intervalo, o entre 5 000 y 42 000 lneas de cdigo. El uso de grficos multiplica el esfuerzo por 1.5 a 4 segn la complejidad, lo que da un intervalo de 1.5 x 5 000 a 4 x 42 000 = 7.5 a 170 000 lneas de cdigo.

1.4. MtricasEl proceso de planificacin del desarrollo de cualquier sistema debe hacerse partiendo de una estimacin del trabajo a realizar. Slo a partir de ello es factible conocer los recursos necesarios y el tiempo necesario para su realizacin.Una mtrica es una medida efectuada sobre algn aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparacin con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias. Con esta definicin, la definicin y aplicacin de una mtrica no es un objetivo en s mismo sino un medio para controlar el desarrollo de un sistema de software.1.4.1. Mtricas sobre el productoLas mtricas sobre el producto estn orientadas a estimar las caractersticas del mismo antes de su desarrollo. Estas estimaciones se basan en el conocimiento que los desarrolladores adquieren a partir de datos obtenidos de proyectos anteriores.1.4.1.1. Tamao estimado del cdigo.La forma ms obvia y la que se ha utilizado histricamente antes para estimar el tamao es contar el nmero de lneas de cdigo. Con ciertas normas para determinar qu es lo que se cuenta (lneas de comentario, cdigo incluido, etc.) y siempre referido a un lenguaje concreto, lo que los valores nos dan es un valor para, comparando con otros casos, poder estimar el esfuerzo necesario en futuros desarrollos.Los resultados obtenidos (estimaciones y valores reales) alimentan la base de datos histricos que es el fundamento para posteriores estimaciones.Boehm desarroll una tcnica empleando el mtodo Delphi para mejorar las estimaciones con mltiples opiniones de expertos. La idea de emplear el mtodo Delphi es asegurar en dos o tres pasos de convergencia que las estimaciones son aceptadas por los expertos.Ha sido muy criticada la tendencia en estimar el esfuerzo en base a las lneas de cdigo. Una de las crticas se centra en que la complejidad del desarrollo no est directamente ligada al tamao cuando nos movemos hacia el dominio de los sistemas concurrentes, distribuidos o de tiempo real. En ellos, las medidas deben referirse a estimaciones del mismo tipo de productos.Otro problema surgido recientemente con la proliferacin de generadores de cdigo es que no importa demasiado el nmero de lneas de cdigo generadas (excepto por problemas derivados del tamao de la memoria para sistemas embebidos) sino el nmero de lneas de especificacin que las han generado, porque la complejidad del problema de mantenimiento depende de ello.1.4.1.2. Complejidad estimada.Con el fin de superar el problema de las estimaciones del tamao de cdigo, se ha prestado recientemente atencin a medidas de complejidad no basadas en estimaciones de nmero de lneas.Albrecht defini en 1979 un mtodo conocido como de puntos de funcin que est teniendo cada vez ms aceptacin. Su mtodo se basa en el empleo de factores normalizados para juzgar la importancia relativa de varios requisitos funcionales.Parte de cinco funciones bsicas que suelen aparecer en muchos sistemas:1) Entradas. Pantallas o formatos empleados para introducir datos a un programa.2) Salidas. Pantallas o informes empleados para utilizarlos con otros programas o para lectura directa.3) Consultas. Mecanismos para pedir ayuda o dar rdenes de ejecucin.4) Ficheros de datos. Conjuntos lgicos de informacin empleados por una aplicacin (ya sean tablas en memoria como ficheros de disco) junto con los procedimientos de acceso a los mismos.5) Interfaces. Ficheros compartidos con otras aplicaciones. La idea bsica del mtodo consiste en definir unas estimaciones de complejidad para cada una de estas funciones (en forma de pesos relativos) y estimar, dadas las especificaciones del sistema, cuntos elementos de cada tipo van a ser necesarios.El problema con los puntos de funcin es que no son realmente medidas sino valoraciones subjetivas y no tienen en cuenta diferencias en la implementacin (al fin y al cabo, el esfuerzo del desarrollo depende tambin del lenguaje utilizado o del dominio de aplicacin y eso no se tiene en cuenta). De nuevo, la comparacin con sistemas similares permite calibrar las decisiones tomadas.1.4.1.3. Robustez.Por robustez de un programa se entiende la ausencia de fallos en su ejecucin con diferentes datos de entrada durante intervalos de tiempo predeterminados.La robustez de un programa est ligada a la aparicin de problemas durante su ejecucin. Generalmente, el nmero de fallos encontrados durante la fase de prueba y, posteriormente, durante el mantenimiento del sistema constituye una medida de la calidad del producto de software e, indirectamente, de la calidad del proceso de desarrollo.La importancia de conocer el nmero de fallos encontrados en un intervalo de tiempo no reside nicamente en obtener un valor global de la calidad del producto sino en los beneficios derivados de su anlisis.Las medidas estadsticas de fiabilidad (tiempo medio entre fallos encontrados durante la ejecucin, reduccin del nmero de recopilaciones necesarias, etc.) sirven para alimentar el proceso de desarrollo.1.4.2. Mtricas sobre el procesoLas mtricas mencionadas en la seccin anterior estaban orientadas a conocer la complejidad del producto (con algn valor indirecto como el tamao) para poder estimar los recursos necesarios para su realizacin. Hemos mencionado tambin que, segn se vayan acumulando datos y se analicen estadsticamente, las estimaciones sern cada vez mejores. Esto nos servir para planificar mejor futuros desarrollos.Existen otros tipos de datos que se pueden tomar durante el desarrollo de un producto de software y que no estn ligados al producto sino a los procesos implicados. El anlisis de cmo estos procesos se realizan a partir de medidas tomadas en el desarrollo es la base para su ulterior mejora.Algunos de los elementos a medir son:A) Distribucin del esfuerzo en cada una de las fases con objeto de poder estimar los recursos necesarios. Obsrvese que esta medida es complementaria al las de tamao mencionado anteriormente; aquella nos permita conocer los recursos globales necesarios; de lo que se trata aqu es de obtener medidas reales y extrapolarlas a futuros proyectos.B) Productividad medida en nmero de lneas de cdigo documentadas que es capaz de producir una persona en una unidad de tiempo. A ttulo orientativo, podemos decir que los valores tpicos de productividad por persona (empleando tecnologas de desarrollo convencional) estn entre 30 y 50 lneas de cdigo por da de trabajo.1.5. Estimacin de costos (concepto persona)En el principio el costo del Software dispona un pequeo porcentaje del costo total de los sistemas basados en Computadoras. Hoy en da el Software es el elemento ms costoso de la mayora de los sistemas informticos.

Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimacin del costo y del esfuerzo del software nunca ser una ciencia exacta, son demasiadas las variables: humanas, tcnicas, de entorno, polticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.

Muchas son las tcnicas o mtodos para realizar estimaciones.

Roger Pressman en su libro de Ingeniera de Software plantea que para lograr estimaciones del tamao del proyecto confiables hay varias opciones:

Retrasar la estimacin para despus.

Basar la estimacin en proyectos simulares ya terminados.

Emplear tcnicas de descomposicin para generar estimaciones de costo y esfuerzo.

Utilizar uno o ms modelos empricos en la estimacin de costo y esfuerzo.

De ellas las ms razonable es la de utilizar las tcnicas y modelos empricos, siendo la ms recomendada pues es donde clasifican los mtodos para estimar el tamao del software planteados por Bhoem y Watts que son los ms utilizados.

Por otra parte el esfuerzo es un indicador de la cantidad de trabajo necesario para realizar un proyecto. En productos de software se debe considerar equivalente estimar el esfuerzo y el coste ya que existe una relacin directa entre ambos.