Modelos de Estimacin de Costos de Proyectos Informticos

Ing. Jos Luis Cerrn Prez

Mtrica
Una mtrica es, pues, una asignacin de valor a un atributo de una entidad propia del software, ya sea un producto o un proceso.

Mtrica
Cuando hablamos de un atributo nos referimos a una determinada caracterstica que pretendemos medir y cuantificar. Cuando hablamos de un producto nos referimos, por ejemplo, a un cdigo, un diseo, una especificacin, etc. Cuando se habla de un proceso se hace referencia a una etapa de la construccin del software y a la manera de llevarlo a cabo: un diseo, unas pruebas, etc.

Mtrica
En general, se puede decir que las diferentes mtricas intentan evaluar tres grandes magnitudes generales: La calidad y el tamao (a menudo del producto) y la productividad (frecuentemente del proceso de construccin del producto), aunque lo hacen desde muchos puntos de vista diferentes.

Mtricas del producto y del proceso

Las mtricas del producto, que miden diferentes aspectos del software obtenido, a menudo a partir de cdigo fuente expresado en un lenguaje informtico determinado.

Las mtricas del proceso, que intentan medir determinados atributos que hacen referencia al entorno de desarrollo del software y tienen en cuenta la manera de construirlo.

Mtricas de calidad y de productividad

La calidad de un producto, segn la definicin del estndar ISO 8402, es el conjunto de funcionalidades y caractersticas de un producto o ser- vicio que se centran en su capacidad de satisfacer las necesidades, ya sea implcitas o bien explicitadas claramente, de un cliente o usuario.

Mtricas de calidad y de productividad

Las mtricas de calidad se asocian a unos determinados atributos medibles, no siempre evidentes, para reconocer la presencia o ausencia de calidad.

Las mtricas de productividad recogen la eficiencia del proceso de produccin de software y relacionan el software que se ha construido con el esfuerzo que ha costado elaborarlo.

Mtricas de calidad y de productividad

A menudo las diferentes unidades de medida se combinan en indicadores resumidos, como ejemplos podemos encontrar, entre otros, los siguientes:
Lneas de cdigo por persona y da (indicador de productividad). Horas para implementar un punto de funcin (indicador de productividad). Nmero de errores por cada mil lneas de cdigo (indicador de calidad). Importe monetario por cada millar de lneas de cdigo (indicador de coste). Pginas de documentacin por cada mil lneas de cdigo (indicador de documentacin).

El esfuerzo y la medida de la productividad

La medida habitual del costo es, evidentemente, la cantidad de dinero que cuesta producir un software determinado; mientras que las medidas habituales del esfuerzo se reducen siempre al trabajo que lleva a cabo un profesional en una determinada unidad de tiempo: un da (personada), un mes (persona-mes) o un ao (personaao).

Problemas terminolgicos del hombre-mes

En primer lugar, se habl de hombre-mes como la tarea que llevaba a cabo un hombre durante un mes de trabajo. sta es la denominacin habitual, que se puede encontrar a menudo abreviada con la sigla MM, proveniente de la de nominacin inglesa man-month.

Problemas terminolgicos del hombre-mes

Ms adelante, pareci que la denominacin era claramente sexista y se buscaron otros nombres como stos:
Persona-mes: un mes de trabajo de una persona del equipo con independencia del gnero. Staff-month: un mes de trabajo de una persona del equipo de proyecto. Engineering-month: un mes de trabajo en la actividad de ingeniera del software, que incluye, como ya sabemos, el anlisis, el diseo, la programacin y las pruebas para producir una determinada aplicacin o un sistema de informacin.

El mito del hombre-mes

En resumidas cuentas, llegamos a la conclusin de que los meses y los hombres (o las mujeres) no son intercambiables.

Mtricas orientadas al tamao y a la funcin

Con el objetivo de medir la productividad del proceso de construccin de software de aplicacin, debe darse la posibilidad de determinar las salidas que sean tiles para relacionarlas despus con el volumen del trabajo o el esfuerzo que representa desarrollar un producto de software determinado

Mtricas orientadas al tamao y a la funcin

se han propuesto tambin otras unidades de medida que, en lugar del tamao, intentan tener en cuenta la dificultad intrnseca de construir un software determinado; es decir, mtricas que se refieren no al tamao del producto final obtenido, sino a las funcionalidades que ste incorpora.

Las lneas de cdigo

La medida ms utilizada para determinar el tamao de un proyecto informtico ha sido, durante mucho tiempo, la de las lneas de cdigo del software final obtenido.

Algunas definiciones:
LOC: lneas de cdigo. Es la ms habitual y antigua. KLOC: miles de lneas de cdigo. DSI: instrucciones de cdigo fuente realmente entregadas, y su mltiplo KDSI.

Las lneas de cdigo

La medida ms utilizada para determinar el tamao de un proyecto informtico ha sido, durante mucho tiempo, la de las lneas de cdigo del software final obtenido. Algunas definiciones:
NCSS: lneas de cdigo fuente sin tener en cuenta los comentarios, y su mltiplo KNCSS NSLOC: nuevas lneas de cdigo fuente, tal como se realiza en el modelo COCOMO 2 para que se tenga en cuenta que slo deben contarse las lneas de cdigo nuevas sin contar las que incorpore automticamente el entorno de programacin

Lneas de cdigo, productividad y lenguajes de programacin

Las ratios de productividad tambin proceden de los aos setenta y ochenta (de la informtica y de los lenguajes que existan entonces). Es- tas ratios, que actan como estndares de la profesin y que han sido mencionadas de paso, son las siguientes:

a) 10 LOC por da y persona ocupada en el proyecto, segn Barry W. Boehm a principios de los aos ochenta.
b) 350 NCSS por persona y mes, segn datos de comienzos de los aos noventa en los proyectos de la empresa Hewlett Packard recogidos por Robert O. Grady.

Lneas de cdigo, productividad y lenguajes de programacin

Caper T. Jones

Lneas de cdigo, productividad y lenguajes de programacin

Caper T. Jones

Mtricas basadas en la Funcin

La mtrica del punto de funcin (PF) se puede utilizar como medio para predecir el tamao de un sistema obtenido a partir de un modelo de anlisis. Para visualizar esta mtrica se utiliza un modelo funcional, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el clculo de la mtrica de punto de funcin:
Nmero de entradas del usuario Nmero de salidas del usuario Nmero de consultas del usuario Nmero de archivos Nmero de interfaces externas
20

Mtricas basadas en la Funcin

La cuenta total debe ajustarse utilizando la siguiente ecuacin: PF = cuenta-total x (0,65 + 0,01 x Fi) Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura y Fi (i=1 a 14) son los "valores de ajuste de complejidad".

21

 Para el ejemplo descrito en la figura se asume que la Fi es 44 (un producto moderadamente complejo), por consiguiente:

PF = 50 x (0,65 + 0,01 x 44) = 54.5

Factor de ponderacin Parmetro de medicin Nmero usuario de entradas del
Cuenta 3 2 2 1 4 X X X X X Simple 3 4 3 7 5 Media 4 5 4 10 7 Compl. 6 7 6 15 10 = = = = = 9 8 6 7 20 50 Clculo de puntos de funcin

Nmero de salidas del usuario Nmero usuario de consultas del

Nmero de archivos Nmero de interfaces externas Cuenta total

Mtricas basadas en la Funcin

Basndose en el valor previsto del PF obtenido del modelo de anlisis, el equipo del proyecto puede estimar el tamao global de implementacin de las funciones de interaccin. Asuma que los datos de los que se dispone indican que un PF supone 60 lneas de cdigo (se utilizar un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF.

Los puntos de funcin y la productividad

Relacin entre puntos de funcin y lneas de cdigo

.?
La nica manera segura de poder tener unos estndares de productividad buenos y dignos de ser utilizados es no depender de lo que dicen libros y artculos (con datos obtenidos en condiciones a menudo bien diferentes) y disponer de los datos de productividad propios, datos que pueden haber sido obtenidos en proyectos anteriores del mismo tipo (en cuanto a aplicacin y tecnologa) y con equipos de desarrollo de calificaciones y caractersticas personales conocidos.

Modelos de Estimacin de Costos de Proyectos Informticos

Ing. Jos Luis Cerrn Prez

Estimacin de costos
La gestin de un proyecto informtico de gestin empieza con la calificacin del proyecto, que pretende, en primer lugar, obtener una idea del volumen de trabajo que costar construir la aplicacin (estimacin) y, en segundo lugar, planificar en el tiempo las diferentes actividades que es necesario llevar a cabo (planificacin).

Estimacin de costos
La primera de estas etapas se conoce tambin con el nombre de estimacin de costos de un proyecto informtico, ya que a partir del esfuerzo de trabajo estimado se obtendr el presupuesto. Del mismo modo, despus de la planificacin y el reparto en el calendario de las tareas que se deben a realizar, se obtienen los plazos, etapa que tambin se conoce con el nombre de tiempo de desarrollo del proyecto.

Estimacin de costos
La mayor parte del costo del software se encuentra hoy en el costo de las horas de anlisis, diseo, programacin y prueba que se deben utilizar para obtenerlo. Por ello, cuando aqu se habla de estimacin de costos se hace referencia, exclusivamente, al esfuerzo humano que ha sido necesario, es decir, a las horas de trabajo requeridas para construir el software.

Estimacin de costos
En palabras de de Marco: No hay modelos de costo transportables. Si esperas que alguien en otro lugar desarrolle un conjunto de frmulas que puedas utilizar para prever el coste en tu propia instalacin, probablemente tendrs que esperar para siempre.
T. de Marco (1982, pg. 155).

Estimacin de costos
De Marco propone dos definiciones sucesivas muy realistas de lo que es una estimacin:
Definicin implcita de estimacin: una estimacin es la prediccin ms optimista que tiene una probabilidad no nula de llegar a ser cierta. Definicin propuesta por de Marco: una estimacin es una prediccin que tiene la misma probabilidad de estar por encima que de estar por debajo del resultado real.

Estimacin de costos
En resumidas cuentas, estimar la carga de trabajo que es necesario llevar a cabo para la construccin de software de aplicacin es una tarea que normalmente debe fracasar.

Momento de la estimacin y grado de exactitud

Fuente: Grfico adaptado de Cost Models for Future Life Cycle Process: COCOMO 2.0 de B.W. Boehm

Modelos de estimacin
La idea de los modelos de estimacin es la de proporcionar sistemas y mtodos generales para proceder a realizar la estimacin de costos en la construccin de software de aplicacin.

Modelos de estimacin
Los diferentes modelos de estimacin de costes y/o esfuerzos en la construccin de software se pueden dividir en cinco grandes grupos principales:
1. 2. 3. 4. 5. Modelos con base histrica. Modelos con base estadstica. Tericos. Compuestos. Basados en estndares.

Modelos de estimacin
Modelos con base histrica.
Los modelos de base histrica son los ms antiguos y, en cierta manera, primitivos. A menudo se basan en la analoga con otros proyectos parecidos y se fundamentan casi exclusivamente en la experiencia profesional (la historia) de los que efectan la estimacin.

Modelos de estimacin
Modelos con base estadstica.
A partir del estudio estadstico de los datos reales disponibles tomados de un conjunto ms o menos numeroso de proyectos ya acabados, obtienen frmulas que relacionan las diferentes unidades de medida del software, a menudo las lneas de cdigo (LOC) y el esfuerzo (generalmente medido en hombre-mes).

Modelos de estimacin
Tericos.
Estos modelos, ms que basarse en datos estadsticos disponibles, lo que hacen es partir de una serie de ideas generales sobre el proceso de construccin de software y, sobre esta teora, elaboran frmulas que relacionan diferentes mtricas de software.

Modelos de estimacin
Compuestos.
Estos modelos intentan obtener las ventajas de los dos sistemas anteriores: estadsticos y tericos. Es decir, se parte de una serie de planteamientos tericos y se complementan o corrigen con datos estadsticos obtenidos de proyectos reales ya acabados.

Los modelos COCOMO

COCOMO es el modelo de construccin de costes ms conocido y utilizado de los modelos algortmicos compuestos que se basan sobre todo en datos estadsticos, pero tambin en ecuaciones analticas y en un ajuste fruto de la opinin de expertos.

El COCOMO clsico de 1981

El COCOMO clsico lo forman, en realidad, tres modelos diferentes, que tienen en cuenta diferentes grados de complejidad:
El COCOMO bsico es un modelo esttico vlido para obtener una estimacin rpida del esfuerzo (meses-hombre) en funcin del tamao (KLOC) al inicio del ciclo de vida.

El COCOMO clsico de 1981

El COCOMO clsico lo forman, en realidad, tres modelos diferentes, que tienen en cuenta diferentes grados de complejidad:
El COCOMO intermedio aade al clculo del esfuerzo en funcin del tamao, el efecto de unos atributos que influyen en el coste (CDA), con los cuales se quiere tener en cuenta el tipo de aplicacin y tecnologa, las calificaciones y la experiencia del personal, el entorno de diseo y programacin y las herramientas de las que dispone, etc.

El COCOMO clsico de 1981

El COCOMO clsico lo forman, en realidad, tres modelos diferentes, que tienen en cuenta diferentes grados de complejidad:
El COCOMO adelantado incorpora todas las caractersticas de la versin intermedia, pero en lugar de evaluar los CDA con un nico valor para todo el ciclo de vida, tiene en cuenta diferentes CDA para cada fase* de la construccin del software.

El COCOMO clsico de 1981

Las ecuaciones del modelo COCOMO tienen siempre la forma general que mostramos a continuacin:
E = a Lb CDA T = c Ed E es el esfuerzo (en personas-mes). L son las lneas de cdigo (en KLOC) T es el tiempo de desarrollo del proyecto (en meses) CDA los cost driven attributes. Finalmente a, b, c y d son coeficientes que el modelo proporciona como resultado del anlisis de los datos de sesenta y tres proyectos realizados entre 1965 y 1980.

El COCOMO clsico de 1981

Adems de los tres modelos, COCOMO tiene en cuenta varios tipos de proyecto, ya que no se obtienen los mismos datos de productividad en todos los casos.
a) Orgnico. b) Semiacoplado. c) Encajado.

El COCOMO clsico de 1981

Los coeficientes que corresponden al modelo bsico.

El COCOMO clsico de 1981

Los coeficientes que corresponden al modelo intermedio.

El COCOMO clsico de 1981

Atributos que influyen en el costo.

El COCOMO clsico de 1981

El COCOMO clsico de 1981

En resumidas cuentas, el modelo COCOMO es el ms serio y completo de los que existen, aunque los resultados que se obtienen pueden haber quedado obsoletos por la evolucin y los cambios que ha sufrido la informtica en los ltimos veinte aos.

El COCOMO II de los aos noventa y a partir del 2000

El nuevo modelo COCOMO II tiene como objetivo principal desarrollar un modelo de estimacin de costos y planificacin del software especialmente adecuado para los ciclos de vida. el COCOMO II incluye tres modelos que corresponden a diferentes fases y modalidades del futuro ciclo de vida.

El COCOMO II de los aos noventa y a partir del 2000

Modelo de composicin de aplicaciones:
incluye el uso de prototipos para disminuir los riesgos potenciales que surgen con las interfaces grficas de usuario tpicas de herramientas RAD y otras herramientas actuales de productividad y de la orientacin a objetos. En este modelo se definen unos puntos objeto que vendran a ser una adaptacin y modernizacin de los puntos de funcin

El COCOMO II de los aos noventa y a partir del 2000

Modelo de diseo primerizo :
intenta obtener una primera aproximacin en las fases iniciales del ciclo de vida, cuando todava se conocen pocas de las caractersticas y datos definitivos del proyecto. Utiliza como primitivas de salida tanto las lneas de cdigo como los clsicos puntos de funcin.

El COCOMO II de los aos noventa y a partir del 2000

Modelo de postarquitectura:
Se aplica cuando se considera que el proyecto dispone ya de requerimientos estables. Por otra parte, tambin utiliza como primitivas de salida las lneas de cdigo y los puntos de funcin. Adems, tiene en cuenta indicadores de la reutilizacin de software, cinco factores de escala y hasta diecisiete factores especficos diferentes

Uso de estndares de productividad

No es fcil, en la prctica, encontrar cul es el modelo que ms se ajusta a la realidad del proyecto informtico que todava est por empezar y que preocupa al jefe de proyecto que debe llevar a cabo la estimacin de las cargas y los costos.

Uso de estndares de productividad

En lugar de cuantificar cada actividad o conjunto de estas caractersticas funcionales en lneas de cdigo o puntos de funcin y buscar modelos que conviertan estas mtricas en esfuerzo (meses-hombre), es suficiente disponer directamente, para cada actividad, del esfuerzo estndar que ha requerido en otros proyectos anteriores.

Uso de estndares de productividad

Segn la opinin de un experto como Jones, se dan las equivalencias prcticas siguientes:
1 FP = 100 LOC. FP elevado a 0,4 = meses de desarrollo. FP/150 = nmero de personas que son necesarias para el desarrollo. FP/500 = nmero de personas necesarias para el mantenimiento futuro.

Uso de estndares de productividad

Segn la opinin de un experto como Jones, se dan las equivalencias prcticas siguientes:
FP elevado a 1,15 = nmero de pginas de documentacin. FP elevado a 1,2 = nmero de casos de prueba que se realizan. FP elevado en 1,25 = potencial de errores (en proyectos nuevos). FP elevado a 0,25 = nmero de aos que seguir en uso la aplicacin.

Tengamos una noche maravillosa!