sábado, 19 de junio de 2010

ESTIMACION DE COSTOS DE PROYECTOS DE SISTEMAS DE INFORMACION

1.1. Estimación de costos de Proyecto

La estimación y al calendarización 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 calendarización 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 planeación y permite la utilización efectiva de los recursos. Si el gasto real es significativamente más 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 parámetros involucrados en el cálculo del costo total de un proyecto de desarrollo de software:

· Los costos del hardware y software, incluyendo mantenimiento;

· Los costos de viajes y capacitación;

· 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. Además el uso de correos electrónico, 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 términos de los costos de sobrecarga donde se toma en cuenta el costo total de hacer funcionar la organización y dividen este entre el número 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 técnicos.

c. Los costos de las redes y las comunicaciones.

d. Los costos de los recursos centralizados como las bibliotecas, los recursos recreativos, etcétera.

e. Los costos de seguridad social y de beneficio de empleados como las pensiones y los seguros de salud.

FACTOR

DESCRIPCION

Oportunidad de mercado

Una organización de desarrollo podría cotizar un bajo precio debido a que desea moverse a un nuevo mercado del software. Aceptar un bajo beneficio en un proyecto podría darle la oportunidad de obtener más beneficios posteriormente. La experiencia obtenida le permite desarrollar nuevos productos.

Incertidumbre en la estimación de costos

Si una organización esta insegura de su costo estimado por alguna contingencia puede incrementar su precio por encima del beneficio normal.

Términos contractuales

Un cliente puede estar dispuesto a permitir que el desarrollador retenga la propiedad del código fuente y que reutilice dicho código en otros proyecto. Por lo tanto, el precio cargado podría ser menor que si el código fuente del software se le entrega al cliente.

Volatilidad de los requerimientos

Si es probable que los requerimientos cambien, una organización puede reducir los precios para ganar un contrato. Después de que el contrato se asigna, se cargan precios altos a los cambios en los requerimientos.

Salud financiera

Los desarrolladores en dificultades financieras podrían bajar sus precios para obtener un contrato. Es mejo tener beneficios más bajos que los normales o incluso quebrar antes que quedar fuera de los negocios.

Cuadro 1: Los factores que afectan la asignación de precios al software.

Típicamente, este factor de sobrecarga es alrededor de dos veces el salario del ingeniero de software, dependiendo del tamaño de la organización y sus sobrecargas asociadas. Por lo tanto, si un ingeniero de software se le pagan $90 000 al año, el costo total de la organización es de $180 000 por año 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 decisión del precio que se le dará al cliente. Por lo general, el precio es simplemente el costo más el beneficio. Sin embargo, la relación 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, económica, políticas y de negocios. En el cuadro N°1 se muestran los factores que se deben tomar en cuenta. Por lo tanto, no existe una relación 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 organización, así como a los administradores del proyecto de software.

1.1.1. Productividad

La productividad en un sistema de manufactura se mide contando el número de unidades que se producen y dividiendo éste entre el número de personas-hora requeridas para producirlas. Sin embargo, para cualquier problema de software, existen muchas soluciones diferentes con distintos atributos. Una solución podría ejecutarse de forma más eficiente mientras que otra podría ser más legible y fácil de mantener. Cuando se producen soluciones con diferentes atributos, no tiene sentido comparar estas tasas de producción.

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 estimación del proyecto y para valorar si los procesos o las mejoras tecnológicas 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 tamaño

Estas se relacionan con el tamaño de alguna salida de una actividad. La medida más común relacionada con el tamaño son las líneas de código fuente entregadas. Otras medidas que se utilizan son el numero de instrucciones de código objeto entregado o el número de páginas de la documentación.

1.1.1.2. Medidas relacionadas con la función

Estas se relacionan con la funcionalidad total del software entregado. La productividad se expresa en términos de la cantidad de funcionalidad útil producida en un tiempo dado. Los puntos de función y los puntos de objeto son las medidas más conocidas de este tipo.

Las líneas de código fuente por programador-mes son una métrica ampliamente utilizada en la medida de la productividad. Esta se calcula contando de número total de líneas del código 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 análisis y diseño, codificación, pruebas y documentación.

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 instrucción en cada tarjeta. El número de líneas del código era fácil de calcular. Correspondía al número 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 líneas de código. Existe más de una instrucción por línea. Por lo tanto, no existe una relación sencilla entre las instrucciones del programa y las líneas de un listado.

Algunas técnicas de conteo de líneas consideran solo las instrucciones ejecutables; otras cuentan las instrucciones ejecutables y las de datos; algunas cuentan cada línea que no esté en blanco en el programa, independientemente de lo que esté en esa línea. Se han propuesto estándares para el conteo de líneas para varios lenguajes (Park, 1992) pero éstos no son ampliamente conocidos. Las comparaciones de productividad en las organizaciones son imposibles a menos que cada organización utilice el mismo método para contar las líneas de código.

Comparar la productividad de los diferentes lenguajes de programación también da impresiones engañosas de productividad del programador. Entre más expresivo sea un lenguaje de programación, más baja es la productividad aparente. Esta anomalía surge debido a que todas las actividades de desarrollo de software se consideran de forma conjunta cuando se calcula la productividad pero la métrica utilizada sólo aplica a los procesos de programación.

Análisis

Diseño

Codificación

Pruebas

Documentación

Código ensamblador

3 semanas

5 semanas

8 semanas

10 semanas

2 semanas

Lenguaje de alto nivel

3 semanas

5 semanas

8 semanas

6 semanas

2 semanas

Tamaño

Esfuerzo

Productividad

Cuadro 2. Tiempos de desarrollo del sistema.

Código ensamblador

5000 líneas

28 semanas

714

líneas/mes

Lenguaje de alto nivel

1500 líneas

20 semanas

300 líneas/mes

Por ejemplo, considere un sistema que podría codificarse con 5000 líneas de código ensamblador o 1500 líneas de código 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 líneas/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 utilización del tamaño del código como atributo estimado del producto es utilizar alguna medida de la funcionalidad del código. Esto evitara la anterior anomalía puesto que la funcionalidad del código. Esto evitará la anterior anomalía puesto que la funcionalidad es independiente de la implementación del lenguaje. MacDonell (1994) brevemente describe y compara varias medidas diferentes basadas en la función.

La más conocida de estas medidas es el conteo de puntos de función. Éste fue propuesto por Albrecht (1979) y refinado por Albretch y Gaffney (1983). Los puntos de función son independientes del lenguaje por lo que se puede comparar la productividad en los diversos lenguajes de programación. La productividad se expresa como puntos de función producidos por personas-mes. Los puntos de función son adecuados para sistemas de procesamiento de datos que están dominados por operaciones de entrada y salida. Un punto de función no es una característica simple sino que es una combinación de características del programa. El número total de puntos de función en un programa se calcula midiendo o estimando las siguientes características del programa:

· Entradas y salidas externas.

· Interacciones con el usuario.

· Interfaces externas.

· Archivos utilizados por el sistema.

Cada una de estas se evalúa de forma individual acorde a su complejidad y se le asigna un valor de peso que varía 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 función no ajustados (UFC) se calcula multiplicando los conteos llanos por el peso estimado y sumando todos los valores.

UFC =

Después, este conteo inicial de puntos de función 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 reutilización, el desempeño, etcétera. El conteo de puntos de función no ajustados se multiplica por los factores de complejidad del proyecto para producir un conteo de puntos función final.

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

Los puntos de objeto (Banker 1992) son una alternativa para los puntos de función cuando se utilizan 4GLs o lenguajes comparables para el desarrollo de software. Los puntos de objeto se utilizan en el modelo de estimación 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. Más bien, el número de puntos de objeto en un programa es una estimación con peso:

a. El número 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 difíciles de producir, cuentan como 8 puntos objeto.

c. El numero de módulos 3GL que deben desarrollarse para complementar el código 4GL- cada módulo 3GL cuenta como 10 puntos de objeto.

La ventaja de utilizar puntos de objeto en lugar de puntos de función es que son más fáciles de estimar a partir de la especificación del software de alto nivel. Los puntos de objeto solo se refieren a las pantallas, informes y módulos 3GL.

Si se utilizaran los puntos de función o los puntos de objeto, entonces se pueden estimar en las primeras etapas del proceso de desarrollo. Las estimaciones de estos parámetros se pueden hacer tan pronto como se diseñen las interacciones externas del sistema. En esta etapa, es muy difícil producir una estimación precisa del tamaño de un programa en líneas de código fuente. En efecto, tal vez el lenguaje de programación a utilizar aun no está decidido. Las primeras estimaciones son esenciales cuando se utilizan los modelos de estimación de costos algorítmicos.

Los conteos de los puntos de función se pueden utilizar junto con las técnicas de estimación de líneas de código. El número de puntos de función se utiliza para estimar el tamaño final del código, AVC, en un lenguaje particular requerido para implementar un punto de función. El tamaño estimado del código para una nueva aplicación se calcula como se muestra a continuación:

Tamaño del código = AVC x Número de puntos de función.

FACTOR

DESCRIPCION

Experiencia en el dominio de la aplicación

Conocer el dominio de la aplicación es esencial para el desarrollo efectivo de software. Los ingenieros que ya conocen un dominio son probablemente los más productivos.

Calidad del proceso

El proceso de desarrollo utilizado puede tener un efecto importante en la productividad.

Tamaño del proyecto

Entre más grande sea un proyecto, se requiere más tiempo para las comunicaciones del equipo. Se dispone de menos tiempo para el desarrollo por lo que la productividad individual se reduce.

Apoyo tecnológico

La productividad se puede mejorar si se tiene buen apoyo tecnológico como de la herramientas CASE, de sistemas de administración de la configuración, etcétera.

Ambiente de trabajo

Un entorno de trabajo silencioso con áreas de trabajo privado contribuye a mejorar la productividad.

Cuadro 3: Los factores que afectan la productividad de la ingeniería de software.

La productividad de los ingenieros que trabajan en una organización se ve afectada por varios factores. Algunos de los más importantes se resumen en el cuadro 3. Sin embargo, las diferencias individuales en la habilidad son más importantes que cualquiera de estos factores. En una primera valoración de la productividad encontraron que algunos programadores eran diez veces más productivos que otros. La experiencia señala que esto aún es cierto. Los equipos grandes tienen una mezcla de habilidades por lo que tiene una productividad “promedio”. Sin embargo, en los equipos pequeños 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 aplicación y a las organizaciones. Para sistemas incrustados, grandes y complejos, la productividad es tan baja como 900 líneas/mes. Cuando se mide en términos de de puntos de objeto. Bohem señala que la productividad varía 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 características no funcionales del software como la fiabilidad, el mantenimiento, etc.

1.1.2. Técnicas de estimación

No existe una forma simple de hacer una estimación precisa del esfuerzo requerido para desarrollar un sistema de software. Las estimaciones iniciales se hacen bajo la base de la definición de requerimientos de usuario de alto nivel. El software tiene que ejecutarse en computadoras poco familiares o utilizar nuevas tecnologías 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 difícil producir una estimación 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 estimación 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 revelaría la estimación del costo al administrador del proyecto. Los costos reales tendrían 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 más de las técnicas descritas en el siguiente cuadro.

FACTOR

DESCRIPCION

Modelado del algoritmo de costos

Se desarrolla un modelo utilizando información histórica de costos que relaciona alguna métrica de software (por lo general, su tamaño) con el costo del proyecto. Se hace una estimación de esa métrica y el modelo predice el esfuerzo requerido.

Opinión de expertos

Se consultan varios expertos en las técnicas de desarrollo de software propuestas y en el dominio de aplicación. Cada uno de ellos estima el costo del proyecto. Estas estimaciones se comparan y discute. El proceso de estimación se itera hasta que se acuerda una estimación.

Estimación por analogía

Esta técnica es aplicable cuando otros proyectos en el mismo dominio de aplicación se han completado. Se estima el costo de un nuevo proyecto por analogía con estos proyectos completados Myers (1989) da una descripción muy clara de este enfoque.

Ley de Parkinson

La ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles más 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-mes

Asignar precios para ganar

El 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: Técnicas de estimación 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 métodos y técnicas de desarrollo han aparecido en los últimos diez años. Muchos administradores tienen poca experiencia en estas técnicas o poco conocimiento de cómo 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.

Ø Utilización 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 utilización de herramientas CASE y generadores de programas en lugar de desarrollo de software sin ayuda.

Todos estos factores han difícil que los administradores produzcan estimaciones precisas de los costos de producción del software. Su experiencia previa no es relevante para ayudarles a estimar los costos del proyecto de software.

1.1.3. Modelado algorítmico de costos

El enfoque más sistemático, aunque no necesariamente el más preciso, para la estimación del software es la estimación algorítmica de costos. Un modelo algorítmico de costos se construye analizando los costos y atributos de los proyectos realizados. Se utiliza una fórmula matemática para predecir los costos basados en estimaciones del tamaño del proyecto, número de programadores y otros factores de los procesos y productos Kitchenham (1990) describe 13 modelos algorítmicos de costos desarrollados a partir de observaciones empíricas.

En su forma general, una estimación algorítmica de costos para el software se expresa como:

Esfuerzo = A x Tamaño B x M

Esta fórmula A es un factor constante que depende de las practicas organizacionales locales y del tipo de software que se desarrolla. Tamaño es una valoración del tamaño del código del software o una estimación de la funcionalidad expresada en puntos de función 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 algorítmicos padecen las mismas dificultades básicas.

a. A menudo es difícil estimar Tamaño en una primera etapa de un proyecto donde solamente está disponible la especificación. Las estimaciones de los putos de función y los puntos de objeto son los más fáciles de producir que las del tamaño del código pero puede ser imprecisas.

b. Las estimaciones de los factores B y M son subjetivas. Las estimaciones varían de una persona a otra, dependiendo de su conocimiento y experiencia.

1.1.3.1. El modelo COCOMO

Se han propuesto varios modelos algorítmicos como una base para estimar el esfuerzo, la calendarización y los costos de un proyecto de software. Éstos son similares conceptualmente pero utilizan diferentes valores en sus parámetros. El modelo especifico que se discute aquí es el modelo COCOMO. Éste es un modelo empírico. Se obtuvo recolectando datos de varios proyecto de software grandes y después 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 público y lo apoyan el dominio público y las herramientas comerciales.

b. Se ha utilizado y evaluado muy ampliamente.

c. Tienen una gran tradición desde su primera versión en 1981 (Bohem, 1981), pasando por un refinamiento para el desarrollo de software en ADA (Bohem y Royce 1989) gasta su versión más reciente publicada en 1995. (Bohem, 1995)

La primera versión del modelo COCOMO (conocida como COCOMO 81) fue un modelo de tres niveles donde estos reflejaban el detalle del análisis de la estimación del costo. El primer nivel (básico) provee una estimación inicial burda, el segundo nivel modifica utilizando varios multiplicadores del proyecto y el proceso, y el nivel más detallado produce estimaciones para las diferentes fases del proyecto. El siguiente cuadro muestra la formula básica de COCOMO para los diferentes tipos de proyectos.

Complejidad del proyecto

Fórmula

Descripción

SIMPLE

PM = 2.4 (KDSI)1.05 x M

Aplicaciones bien comprendidas desarrolladas por equipos pequeños.

MODERADA

PM = 3.0 (KDSI)1.12 x M

Proyectos más complejos donde los miembros del equipo tienen experiencia limitada en sistemas relacionados.

INCRUSTADA

PM = 3.6 (KDSI)1.20 x M

Proyectos complejos donde el software es parte de un complejo fuertemente acoplado de hardware, software, reglas y procedimientos operacionales.

Cuadro 5: El modelo básico de COCOMO 81

1.1.3.2. Modelo algorítmico de costos en la planeación del proyecto

Los administradores de proyectos pueden utilizar un modelo algorítmico 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 están sujetos a límites de peso rigurosos. El numero de chips es una tarjeta electrónica tiene que minimizarse. En términos del modelo COCOMO, los multiplicadores correspondientes a las restricciones y la fiabilidad de la computadora son más 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. Duración y personal del proyecto

Así como es necesario estimar el esfuerzo requerido para desarrollar un sistema de software y los costos totales del esfuerzo, los administradores de proyectos también estiman cuánto durara el desarrollo del software y cuanto personal se necesita para trabaje en el proyecto. El tiempo de desarrollo del proyecto se denomina duración del proyecto. Cada vez más, las organizaciones demandan tiempos de duración más cortos para que sus productos salgan al mercado antes que los de sus competidores.

La relación entre el número de personas que trabajan en un proyecto, el esfuerzo total requerido y el tiempo de desarrollo no es lineal. En cuanto crezca el número de personal, se necesitara más esfuerzo. Las personas deben invertir más tiempo en comunicarse. Se requiere más de un tiempo para definir las interfaces entre las partes del sistema. Doblar el número de personas (por ejemplo) no significa que la duración del proyecto se reducirá a la mitad.

1.2. Estimación De Costos De Proyecto

Cualquier tarea pasada por alto inadvertidamente durante el periodo de estimación, dará como resultado un menosprecio del proyecto en su totalidad, este hecho, a su vez podría comprometer la planificación 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 ejecución de proyectos software debe de elaborar unas listas de comprobación 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 sólo en la dimensión temporal del proyecto, sino en la calidad del producto a obtener o en el calendario del propio proyecto.

Existen muchos estudios sobre las técnicas de estimación de costes, el objetivo de la presente lección no es presentar al alumno una descripción de todas y cada una de ellas, pero sí de las más utilizadas, por eso presentamos la técnica de los puntos función de Albrecht (IBM), el COCOMO (Constructive Cost Method) de Boehm y la estimación de Putman.

El más utilizado es el de los puntos función de Albrecht cuya originalidad proviene de estimar los costes en función de la complejidad de los aspectos externos, o funciones, del propio programa. Por otra parte está bastante extendido el método COCOMO de Boehm que se describe en su libro 1 "Software Engineering Economics", y presenta una técnica del modelo a tres niveles según la complejidad de los proyectos aportando herramientas para controlar el coste, no sólo del diseño y desarrollo del sistema, sino que cubre todos los aspectos en la estimación 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 Empíricos

Una vez asentados sus conocimientos sobre las fases en que se divide un proyecto software desde las perspectivas de los distintos paradigmas de la Ingeniería del Software se considera, en líneas generales, que todo proceso de desarrollo de software está compuesto por tres fases genéricas que son: definición, desarrollo y mantenimiento, y en todos ellos tenemos que considerar los modelos de estimación de costes, que si bien en Informática no son relativamente novedosos, ya que los primeros esbozos en estudiar este problema comenzaron hace poco más de dos décadas, la implantación 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 más costoso de un sistema de información; es más: la desviación producida por los costes de software en el desarrollo de un proyecto tenía poca incidencia en el coste total, cosa que no ocurre hoy día ya que un error de estimación del tiempo de desarrollo puede colocar el proyecto entre el beneficio y la pérdida económica.

Los modelos de estimación tienen aplicación dentro de la fase de definición de un sistema software. En esta fase lo que se define es el qué, es decir, se intenta identificar en ella qué información va a ser procesada, qué función y rendimiento se desea, qué interfaces han de establecerse, qué ligaduras de diseño existen y, por último, qué criterios de validación se requieren para definir un sistema correcto. Dentro de la mayor parte de las organizaciones, la estimación de costes de un sistema software está basada en experiencias pasadas. Los datos históricos se usan para identificar los factores de coste y determinar la importancia relativa de los diversos factores dentro de la organización. 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 estimación de costes puede llevarse a cabo de forma jerárquica hacia abajo (Top-Down) o jerárquica hacia arriba (Bottom-Up).

La estimación jerárquica hacia abajo se enfoca primero a los costes a nivel del sistema, además de los costes del manejo de la configuración, del control de calidad, de la integración del sistema, del entrenamiento y de la documentación. Los costes del personal relacionado se estiman mediante el examen del coste de proyectos anteriores que resulten similares. En la estimación jerárquica hacia arriba, primero se estima el coste del desarrollo de cada módulo o subsistema, tales costes se integran para obtener un coste total. La técnica puede fallar al no considerar los costes del manejo de la configuración o del control de calidad, pero tiene la ventaja de enfocarse directamente a los costes del sistema. Podemos establecer una clasificación de los llamados modelos empíricos de estimación de costes basados en la experiencia:

1.2.1.1. Juicio de experto

En esta categoría un experto o grupo de expertos estudia las especificaciones y hace su estimación (jerárquica 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 método Delphi o juicio experto. Este método consiste en que el grupo se reúne para dar sus opiniones sobre la estimación. Las conclusiones individuales se envían al coordinador del grupo que las compara entre sí. Si los resultados son parecidos la estimación se da por buena, si no es así cada estimador recibe información sobre su estimación, y las ajenas pero de forma anónima. Cada uno revisa su propia estimación y la envía de nuevo al coordinador. Se repite el proceso hasta que la estimación converge de forma razonable. Es posible realizar nuevas reuniones del grupo si el coordinador lo considera oportuno según 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 crítico imprescindible.

1.2.1.2. Analogía

Consiste en comparar las especificaciones de un proyecto, con las de otros proyectos similares según el tamaño, complejidad, número y tipo de usuarios y otros factores como sistemas operativos, hardware, personal, etc.

1.2.1.3. Distribución de la utilización de los recursos durante el ciclo de vida.

Este método 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, análisis, diseño, construcción, prueba e implantación) 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. Método basado exclusivamente en los recursos.

En la estimación consiste en ver de cuanto personal disponemos para el proyecto y durante cuánto tiempo se dispone de él. Estos serán 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. Método basado exclusivamente en el mercado.

Parte de que lo más importante es conseguir el contrato. El precio se fija en función de lo que creemos que está dispuesto a pagar el cliente. La estimación de costes del proyecto será el precio a pagar por el cliente menos los beneficios económicos que se desea obtener.

1.2.2. Puntos Función

Las Métricas Orientadas a la Función se basan en estimar no el número de líneas fuente del programa (LDC) sino su "funcionalidad". Estas métricas, propuestas inicialmente por Albretch en 1979 y 1983, intentan buscar un factor de productividad del software mediante el método denominado de análisis de los puntos función 2. Los puntos de función se obtienen como consecuencia de haber estudiado distintos proyectos de software y haber aplicado sobre ellos una métrica basada en la complejidad y el tamaño de la función realizada.

La medida del punto función se ha aplicado con éxito en sistemas “no empotrados” y concretamente en sistemas comerciales y puede no ser relevante en otros sistemas de ingeniería.

Las métricas orientadas al tamaño son bastante polémicas y no están aceptadas universalmente como el mejor método para medir la productividad en el desarrollo del software ya que el número de líneas de código escrito no parece una buena medida. Sus defensores dicen que esta medida es fácil de aplicar y que puede ser calculada fácilmente en base a la experiencia y que existe una gran cantidad de información basada en las LDC. Sus detractores dicen que las LDC dependen del lenguaje de programación, que perjudica a los programas más cortos pero mejor diseñados y que su utilización requiere un nivel de detalle que puede ser difícil de conseguir.

El análisis de los puntos función se basa en establecer relaciones entre los componentes básicos de cada tarea y el esfuerzo requerido en desarrollarlos. El procedimiento a seguir para calcular los puntos función 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 número de entradas, el número de salidas, la cantidad de ficheros que trata la aplicación, el tamaño de los ficheros en número de campos, la cantidad de consultas que se pretenden efectuar, etc. Cada uno de estos valores se clasifica en tres categorías respecto a la complejidad que puede ser alta, media o baja. Igualmente se establece una segunda dimensión en cuanto al tamaño de cada elemento, clasificándolos en pequeño, medio y grande. En ambas clasificaciones siempre será más importante seguir criterios de consistencia sobre criterios de precisión; es decir deberá imperar el método de clasificar en grandes grupos todos los elementos de la configuración.

1.2.3. Distribución Porcentual Del Esfuerzo

Un método empleado por muchas compañías es el basado en la distribución porcentual del trabajo que se emplea en organizaciones donde el tipo de proyectos software que realizan son muy homogéneos y se basa en tener estadísticas muy actualizadas de los tiempos medios en satisfacer cada una de las fases del proyecto.

En nuestro caso, y según experiencias anteriores, se sabe que la media de nuestros últimos trabajos ha supuesto que la fase de diseño supone un porcentaje del tiempo total invertido en cada proyecto con independencia del tamaño, y cada una de las fases se distribuye según el porcentaje expuesto. Con estos criterios se puede estimar, por medio de la extrapolación, la duración total del proyecto cuando se ha ejecutado alguna de sus partes.

Este método tiene serios inconvenientes, sobre todo cuando los proyectos no son del mismo tamaño, 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 método de los Puntos Función de Albretch, sobre todo cuando se comparan los porcentajes de ambos métodos, ya que nos puede ayudar a estudiar dónde se producen las mayores desviaciones por si se trata de errores de cálculo o si se han omitido alguna de las fases.

Para efectuar esta comparación se tabulan sobre una hoja de cálculo los resultados de cada fase del ciclo de vida y se decide estudiar a detalle aquellos hitos que tengan una desviación superior al 15%.

1.2.4. Modelo Cocomo

Es un modelo de costes, descrito por Barry W. Boehm en 1981 de tipo algorítmico que proporciona estimaciones directas tanto de la duración como del esfuerzo que está basado en la cantidad de líneas de código fuente escritas en la totalidad. Se trata de un modelo de estimación empírico que está basado en el paradigma del ciclo de vida clásico 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 metodologías de desarrollos de sistemas informáticos clásicas. Las fases que cubre el modelo de Boehm son todas las descritas en el ciclo de vida de productos software con la excepción del estudio de la viabilidad y el análisis 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 empírico para la estimación de los costes de producción de software más utilizado por los equipos de desarrollo de sistemas informáticos de tamaño grande, sin embargo, se deben tener en cuenta los propios comentarios de Boehm sobre COCOMO y por extensión sobre todos los modelos: “Hoy en día, un modelo de estimación 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 quisiéramos, pero es lo suficientemente preciso para proporcionar una buena ayuda en el análisis económico de la ingeniería del software y en la toma de decisiones”.

Boehm como: considera que la función de distribución de Rayleight, definida

Donde td es el momento en el que se introduce un esfuerzo máximo, es un estimador exacto para los requisitos de personal para el ciclo de vida del desarrollo (desde el diseño arquitectónico hasta las pruebas del sistema siempre que usemos la porción 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 cálculo del coste primario está basado en el número de instrucciones fuentes desarrolladas en el proyecto sin incluir las líneas de comentarios, pruebas, documentación, 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 diseño y termina al finalizar la fase de integración 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 organización y documentación, pero excluye algunos esfuerzos tales como la planificación de la instalación, esfuerzo de conversión, etc.

Ø Las soluciones se expresan en criterios de la forma hombres-mes refiriéndose 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 análisis de requerimientos del producto.

Ø Considera que la especificación de requerimientos no tiene cambios sustanciales después de la fase de planificación 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 sólo 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 actualización del plan de integración y prueba y la aceptación completa de los planes de prueba están incluidos en la fase de diseño detallado.

Para que se cumplan los criterios de estimación del ciclo de vida desarrollo de software es necesario resaltar las siguientes características:

Ø Se debe de prestar especial cuidado a la definición y validación de la especificación de los requerimientos software por un grupo de personas relativamente pequeño con anterioridad a la entrada en la fase de diseño.

Ø Posteriormente se debe de someter la definición y validación del diseño del sistema software a un grupo de personas algo más grande como actividad anterior a la entrada en la fase de diseño detallado y de la codificación.

Ø El diseño detallado, la codificación y las pruebas de unidades serán desarrollados por un grupo grande de programadores trabajando en paralelo, y siguiendo una línea base sólida que suponga un desarrollo incremental de la planificación.

Ø La integración y prueba de cada incremento en el sistema está basada en una gran cantidad de planificación de pruebas tempranas y en la eliminación de casi todas las unidades defectuosas por medio de cuidadosos y completos recorridos de las unidades desarrolladas.

Ø Una parte importante del esfuerzo de documentación (por ejemplo los borradores de los manuales de usuario) se desarrollará en fases tempranas para proporcionar a los usuarios (y desarrolladores) información acerca de la naturaleza operacional del producto.

Para ajustar mejor sus estimaciones Boehm creó tres escenarios de estimación clasificando su modelo de forma jerárquica y en base a la complejidad y cantidad de información utilizada en la estimación; a los que denominó modelos COCOMO que son:

Ø Modelo básico

Ø Modelo intermedio

Ø Modelo avanzado

1.2.4.1. El modelo básico

Es un modelo estático, evaluado de forma única y que calcula el esfuerzo y el coste de desarrollo del software en función del tamaño del programa expresado en líneas de código estimadas (DSI o LDC). Tamaño

1.2.4.2. El modelo intermedio

Calcula el esfuerzo de desarrollo en función del programa y un conjunto de guías de coste que incluyen una evaluación subjetiva tanto del producto, como del hardware, del personal y de los atributos del proyecto.

1.2.4.3. El modelo avanzado

Incorpora todas las características de la versión intermedia con una evaluación del impacto de las guías de coste en cada fase (análisis, diseño, etc.) del proceso de ingeniería del software.

1.2.5. Método De Estimación De Putman

El modelo de estimación de Putman es un modelo multivariable dinámico que asume una distribución específica del esfuerzo a lo largo del ciclo de vida de un proyecto de desarrollo software. Las curvas mostradas en la figura toman la forma clásica descrita por Lord Rayleight en el año 1978 y los datos empíricos fueron recogidos por Norden.

La función es de la forma:

Donde C k es una constante de estado de la tecnología 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-año y td es el tiempo de desarrollo en años y L el número de miles de líneas fuente del proyecto.

Algunos valores típicos de C k pueden ser C k =2000 en entornos de desarrollo típicos o C k = 8000 en un buen entorno de desarrollo con buena metodología y herramientas.

El valor del esfuerzo se puede despejar de la ecuación anterior resultando, la ecuación de la forma:

1.2.6. Herramientas Automáticas De Estimación

Una vez estudiados los distintos modelos empíricos de estimación de costos vamos a señalar como está el estado del arte en la implementación en programas de usuario:

Existe un producto, denominado comercialmente ESTIMACS, que utiliza un modelo basado en los puntos función 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 aplicación directa del modelo COCOMO descrito por el Dr. Barry Boehm en su libro Software Engineering Economics en sus tres modos, y es, seguramente el más empleado en la industria, permite obtener información 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 compañía 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 ampliación del programa anterior que soporta una mayor cantidad de modelos de estimación, incluido el modelo COCOMO II, Para facilitar la planificación del proyecto, en esta versión del programa, Costar II facialita el supuesto de análisis de la forma ¿qué pasaría si? Además de comparar distintos planes de proyectos. La riqueza de informes y gráficos hacen que Costar II sea, actualmente, la “estrella” de los programas de estimación de esfuerzos.

La versión de evaluación permite estimar proyectos de hasta 5000 líneas de código fuente y permite efectuar supuestos sobre la duración 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 según unas especificaciones dadas.

En la versión evaluada (6.0) se ofrecen numerosas intercambiar la información con otros programas de Windows, obtener información gráfica para insertar o adjuntar dentro de ofimáticas como puede ser Microsoft Word.

Aspecto de Costar II

Otro producto interesante es el SLIM, basado en el modelo de Putnam que permite obtener unos estudios de programación lineal, la simulación estadística 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 NASA

Todos estos productos, hoy día disponible en computadoras personales, permiten calibrar el entorno local de desarrollo y crear un modelo de información del software desarrollado mediante sus características básicas, los atributos de personal y las consideraciones del entorno.

Si en su organización no se dispone de software de estimación de proyectos, se pueden buscar “sitios” de la red que disponga de software que esté más o menos calibrado a nuestro entorno de desarrollo y a los usos y costumbres del grupo de trabajo concertadas en forma de metodologías.

1.2.7. Discusión Final

La estimación es una tarea difícil y errática en la Ingeniería del Software que se fundamenta en “medir” experiencias pasadas. De todos los modelos de estimación resulta ser COCOMO el más universalmente aceptado si bien hay que hacer hincapié en que cualquier método de estimación se debe de ajustar a la organización. Por ello, podemos decir que: una estimación de costes es sólo 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 planificación ha sido correcta.

Debido a que la mayor parte de las estimaciones de costes están desarrolladas en función del número estimado de instrucciones del producto final, la estimación de costes del producto no será superior a nuestra capacidad de estimar el número de instrucciones finales existentes en él.

El modelo de Barry W. Boehm proporciona una base firme para desarrollar una estimación de costes en un sistema software, debido a su adaptabilidad a los distintos sistemas, a su fácil aplicación y a la consideración por parte del modelo de la influencia de los factores más importantes del desarrollo de software.

Aunque existen otros modelos de estimación de costes, como el modelo SLIM de Putnam, el modelo SDC (System Development Corporation) de Nelson, etc., se ha desarrollado el estudio más profundo del modelo COCOMO debido a que es uno de los más completos de los existentes, además de uno de los más utilizados por las organizaciones para la estimación de costes en la producción de grandes sistemas informáticos.

1.3. Estimación de costos de Proyecto

El costo de un proyecto es de interés continuo y vital para los coparticipes. Con el precio de producción equivocado, incluso el producto más fantástico puede ser un desastre. La estimación de costo más 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 común es que la organización haga todo lo posible para encontrar fondos para ese último 10%. Aun cuando el costo del proyecto seas rígido, es necesario estimar el costo de un conjunto dado de requisitos y/o del diseño para asegurar que cumple con el costo acordado y, si no lo hace, cambiarlos y después hacer la estimación de nuevo.

El proceso de estimar los costos (esto es, para capacidades, control de calidad y programación fijas) con frecuencia comienza desde la concepción del proyecto y continua aun después de iniciada la codificación. Cuando se inicia un proyecto, tal vez el equipo tenga sólo una idea vaga de su costo. Si la estimación 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 más se sepa de los requisitos para el producto y mas diseño se realice, más preciso será el costo.

El error de estimación tan grande que indica en la siguiente figura se debe a un estudio reportado por Bohem. Por ejemplo, para una aplicación que con el tiempo costara $100 000, las estimaciones hechas después de desarrollar el concepto de la aplicación pueden ser tan bajas como $25 000 y tan altas como $400 000. Para perfeccionar la estimación del costo de un proyecto se usan varias técnicas lo antes posible, lo que significa reducir la altura de las líneas 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 precisión es prácticamente 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 diseño y los requisitos detallados, pero ésta es una práctica común en otros campos. Se puede obtener una estimación burda del costo de construir una casa, por ejemplo, sin un diseño o los requisitos detallados. Se pueden usar reglas cortas como “las casas en esta área cuestan alrededor de $100 por pie cuadrado de construcción”, y así una casa de 100 pies cuadrados costara alrededor de $100 000.

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

Una máquina 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 aproximación de costos es poco probable que los resultados sean confiables. El uso preciso de estas herramientas se aprende con el tiempo, la retroalimentación y la comprobación.

1.3.1. Estimación de líneas de código sin el proceso de puntos de función

Esta sección presenta la estimación de líneas de código en la etapa inicial, mucho antes de iniciar el trabajo de diseño. Una vez realizado éste, los métodos se basan en las partes del diseño y se vuelven mucho más precisos.

Varios métodos de estimación, como modelo de COCOMO, dependen del número de líneas de código (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 codificación. Sin embargo, cuando un producto se puede comparar con otros, es factible estimar las líneas.

Las organizaciones que trabajan por encima del nivel 1 en los modelos de madurez de capacidades deben poder registrar las personas-hora y la duración de las partes de los trabajos. En ausencia de este tipo de datos, se tendría que comprar, por ejemplo, nuestro videojuego Encuentro con otros juegos. La obtención directa de los datos de otras compañías es entre difícil 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 públicos, que “BufEye Inc”. ha trabajado en sus nuevos juegos durante 3 años: tal vez incluso mencione un numero de programadores, pero debe sospecharse de estos datos, ya que algunas compañías consideran sus conocimientos sobre desarrollo como un activo corporativo y suelen exagerar estos números o publicar números menores, según 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 programación de juegos y alguna en la programación de simulaciones y Java. La estimación de líneas de código tal vez incluya algo como lo siguiente:

Una vez escribí una simulación no grafica de una cola sencilla en C++, que requirió entre 4 y 8 páginas de código, con alrededor de 30 a 50 líneas que no eran comentarios; esto es un total de 120 a 400 líneas. Suponga que Java requiere el mismo número de líneas. La primera versión comercial de Encuentro tiene de 4 a 15 colas de este tipo y de 30 a 90 componentes adicionales de tamaño comparable para hacerlo interesante, y esto da entre un mínimo de [(120 líneas) x (34 componentes)] y máximo de [(400 líneas) x (105 componentes)] para nuestro intervalo, o entre 5 000 y 42 000 líneas de código. El uso de gráficos multiplica el esfuerzo por 1.5 a 4 según la complejidad, lo que da un intervalo de 1.5 x 5 000 a 4 x 42 000 = 7.5 a 170 000 líneas de código.

1.4. Métricas

El proceso de planificación del desarrollo de cualquier sistema debe hacerse partiendo de una estimación del trabajo a realizar. Sólo a partir de ello es factible conocer los recursos necesarios y el tiempo necesario para su realización.

Una métrica es una medida efectuada sobre algún aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparación con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias. Con esta definición, la definición y aplicación de una métrica no es un objetivo en sí mismo sino un medio para controlar el desarrollo de un sistema de software.

1.4.1. Métricas sobre el producto

Las métricas sobre el producto están orientadas a estimar las características 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. Tamaño estimado del código.

La forma más obvia y la que se ha utilizado históricamente antes para estimar el tamaño es contar el número de líneas de código. Con ciertas normas para determinar qué es lo que se cuenta (líneas de comentario, código 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 históricos que es el fundamento para posteriores estimaciones.

Boehm desarrolló una técnica empleando el método Delphi para mejorar las estimaciones con múltiples opiniones de expertos. La idea de emplear el método 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 líneas de código. Una de las críticas se centra en que la complejidad del desarrollo no está directamente ligada al tamaño 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 proliferación de generadores de código es que no importa demasiado el número de líneas de código generadas (excepto por problemas derivados del tamaño de la memoria para sistemas embebidos) sino el número de líneas de especificación 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 tamaño de código, se ha prestado recientemente atención a medidas de complejidad no basadas en estimaciones de número de líneas.

Albrecht definió en 1979 un método conocido como de puntos de función que está teniendo cada vez más aceptación. Su método se basa en el empleo de factores normalizados para juzgar la importancia relativa de varios requisitos funcionales.

Parte de cinco funciones básicas 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 ejecución.

4) Ficheros de datos. Conjuntos lógicos de información empleados por una aplicación (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 básica del método 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, cuántos elementos de cada tipo van a ser necesarios.

El problema con los puntos de función es que no son realmente medidas sino valoraciones subjetivas y no tienen en cuenta diferencias en la implementación (al fin y al cabo, el esfuerzo del desarrollo depende también del lenguaje utilizado o del dominio de aplicación y eso no se tiene en cuenta). De nuevo, la comparación 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 ejecución con diferentes datos de entrada durante intervalos de tiempo predeterminados.

La robustez de un programa está ligada a la aparición de problemas durante su ejecución. Generalmente, el número 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 número 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 análisis.

Las medidas estadísticas de fiabilidad (tiempo medio entre fallos encontrados durante la ejecución, reducción del número de recopilaciones necesarias, etc.) sirven para alimentar el proceso de desarrollo.

1.4.2. Métricas sobre el proceso

Las métricas mencionadas en la sección anterior estaban orientadas a conocer la complejidad del producto (con algún valor indirecto como el tamaño) para poder estimar los recursos necesarios para su realización. Hemos mencionado también que, según se vayan acumulando datos y se analicen estadísticamente, las estimaciones serán 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 están ligados al producto sino a los procesos implicados. El análisis de cómo 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) Distribución del esfuerzo en cada una de las fases con objeto de poder estimar los recursos necesarios. Obsérvese que esta medida es complementaria al las de tamaño mencionado anteriormente; aquella nos permitía 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 número de líneas de código documentadas que es capaz de producir una persona en una unidad de tiempo. A título orientativo, podemos decir que los valores típicos de productividad por persona (empleando tecnologías de desarrollo convencional) están entre 30 y 50 líneas de código por día de trabajo.

1.5. Estimación de costos (concepto persona)

En el principio el costo del Software disponía un pequeño porcentaje del costo total de los sistemas basados en Computadoras. Hoy en día el Software es el elemento más costoso de la mayoría de los sistemas informáticos.

Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.

Muchas son las técnicas o métodos para realizar estimaciones.

Roger Pressman en su libro de Ingeniería de Software plantea que para lograr estimaciones del tamaño del proyecto confiables hay varias opciones:

Ø Retrasar la estimación para después.

Ø Basar la estimación en proyectos simulares ya terminados.

Ø Emplear técnicas de descomposición para generar estimaciones de costo y esfuerzo.

Ø Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo.

De ellas las más razonable es la de utilizar las técnicas y modelos empíricos, siendo la más recomendada pues es donde clasifican los métodos para estimar el tamaño del software planteados por Bhoem y Watts que son los más 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 relación directa entre ambos.