est imac ion de costes de un proyecto informatico

8/6/2019 Est Imac Ion de Costes de Un Proyecto Informatico

1/60

Estimacin

de costes deun proyecto

informticoMtricas de productividad y modelosde estimacin de costes

Miquel Barcel Garca

P03/75069/02142


2/60

FUOC P03/75069/02142 Estimacin de costes de un proyecto informtico


3/60


ndice

Introduccin .............................................................................................. 5

Objetivos ..................................................................................................... 7

1. Mtricas del software.......................................................................... 91.1. Mtricas del producto y del proceso ................................................. 10

1.2. Mtricas de calidad y de productividad ............................................ 11

1.3. El esfuerzo y la medida de la productividad .................................... 13

1.3.1. Los problemas terminolgicos del hombre-mes ...................13

1.3.2. El mito del hombre-mes ........................................................14

1.4. Mtricas orientadas al tamao y a la funcin .................................. 151.4.1. Las lneas de cdigo .............................................................. 16

1.4.2. Los puntos de funcin .......................................................... 21

1.4.3. Relacin entre puntos de funcin y lneas de cdigo ........... 26

1.4.4. Una perplejidad final ............................................................28

2. Estimacin de costes de un proyecto informtico ..................... 292.1. Momento de la estimacin y grado de exactitud ............................. 30

2.2. Los mtodos de estimacin posibles segn Barry W. Boehm ..........31

2.3. Modelos de estimacin ..................................................................... 33

2.3.1. Modelos histricos ................................................................ 352.3.2. Modelos empricos o estadsticos .......................................... 36

2.3.3. Modelos tericos: el modelo de Putman ............................... 38

2.3.4. Modelos compuestos: los modelos COCOMO

de Barry W. Boehm ............................................................... 40

2.3.5. El uso de estndares de productividad .................................. 44

2.4. Prctica real de la estimacin ........................................................... 47

2.4.1. Un ejemplo: contabilidad sencilla en un PC ........................ 49

Resumen ...................................................................................................... 53

Actividades ................................................................................................. 55

Ejercicios de autoevaluacin ................................................................. 55

Solucionario ............................................................................................... 56

Glosario ....................................................................................................... 56

Bibliografa ................................................................................................ 58


4/60



5/60

FUOC P03/75069/02142 5 Estimacin de costes de un proyecto informtico

Introduccin

Cuando se inicia un proyecto informtico se conocen muy pocas de las funcio-nalidades que se deben implementar. A pesar de todo, a veces debe realizarse

una estimacin de los costes necesarios para construir un software de aplicacin,

del cual, al empezar, no se conoce ni siquiera el alcance que pueda llegar a tener.

De hecho, un software se especifica a medida que se construye (o, dicho de otra

manera, la especificacin o el anlisis es una de las primeras etapas de las que

consta el complejo proceso de construccin de software de aplicacin en la in-

formtica de gestin). Sin embargo, aunque esto sea as, a menudo antes de

empezar se debe llevar a cabo una primera estimacin de costes que, simple-

mente, sea objetiva y que tenga unas mnimas posibilidades de convertirse en

realidad.

Por tanto, debemos disponer, en primer lugar, de diferentes unidades de medida

que nos puedan ser tiles para caracterizar y medir varias funcionalidades del

software que se quiere implentar: el tamao del proyecto, la evaluacin de la ca-

lidad y la fiabilidad, etc. Y, adems, necesitamos unidades de medida que nos

permitan asociar estas funcionalidades con el esfuerzo que cuesta implementar-

las; es decir, debemos tener referencias sobre la productividad en la construc-

cin de software.

En este mdulo didctico analizamos algunas de las muchas mtricas del

software, con atencin especial a las mtricas de tamao (LOC), funcionali-

dades (puntos de funcin) y productividad (esfuerzo), que son las ms ade-

cuadas para llevar a cabo una buena estimacin de los costes de construccin

de un software de aplicacin determinado.

En la construccin de software interviene un conjunto de costes muy variado,

sin embargo, tal como se menciona en el mdulo El proyecto informtico de

construccin de software, dominan los costes del personal tcnico que inter-viene en la construccin del software, a menudo caracterizados como jefes de

proyecto, analistas y programadores. Por tanto, estimar el trabajo de los dife-

rentes profesionales involucrados en un proyecto en horas o das es la manera

habitual de considerar los costes ms relevantes en el proceso de construccin

de software de aplicacin.

Sin embargo, el hecho de disponer de unidades de medida no es suficiente. Es

necesario tambin conocer los diferentes modelos que, desde hace unos trein-

ta aos, se utilizan para estimar los costes de un proyecto informtico.

Cabe mencionar que algunos de estos modelos estn prcticamente obsoletos

y no son nada adecuados para la informtica de nuestros das. De hecho, du-


6/60


rante la ltima dcada, los cambios en la construccin del software han sido

tantos y tan rpidos que, a menudo, los modelos de estimacin disponibles no

parecen los ms adecuados para la compleja y difcil tarea de estimar los cos-

tes. Es cierto que se revisan los modelos ms importantes, pero la falta de datos

concretos y generalizables provoca que todava no se hayan sustituido del

todo los modelos tradicionales.

En este mdulo, adems de exponer las mtricas o las unidades de medida ms

habituales, presentamos de manera crtica los diferentes modelos de estima-

cin que existen y que forman el mbito de conocimiento que debe tener un

buen jefe de proyecto sobre el tema de la estimacin de costes.

El mdulo termina con un ejemplo prctico y concreto sobre el proyecto de

construir una pequea aplicacin de contabilidad.


7/60


Objetivos

En este mdulo presentamos la primera de las etapas de la gestin de un pro-yecto informtico: la estimacin previa de los posibles costes en la construc-

cin de software de aplicacin en la informtica de gestin. Con el estudio de

los materiales asociados a este mdulo didctico, el estudiante debe poder al-

canzar los siguientes objetivos:

1. Conocer el problema de las mtricas de software, sobre todo las quesirven

para medir el tamao de un proyecto, las funcionalidades que se quieren

implementar y, especialmente, la productividad que se puede alcanzar.

2. Comprender lo que se denomina el mito del hombre-mes, es decir, las difi-

cultades asociadas a la unidad ms habitual utilizada para medir el esfuerzo

humano en la construccin de software (por ejemplo, la persona-mes).

Aunque se trata del producto de personas por meses, es necesario saber que

no son factores intercambiables, ya que no se pueden efectuar todo tipo de

combinaciones y debe darse un reparto concreto y especfico del esfuerzo

a lo largo de los meses del proyecto.

3. Conocer las caractersticas, las ventajas y los inconvenientes de las mtricas

de tamao (lneas de cdigo) y funcionalidad (puntos de funcin) y su po-sible interrelacin.

4. Conocer la orden de magnitud de las ratios habituales de productividad en

la construccin de software de aplicacin en la informtica de gestin.

5. Comprender que el grado de incertidumbre en la estimacin de costes de

un proyecto informtico es francamente elevado cuando empieza el pro-

yecto, pero a medida que ste avanza se puede reducir del todo.

6. Conocer de manera crtica los diferentes modelos de estimacin de costesen la construccin de software que se han utilizado en los ltimos aos, las

caractersticas y los puntos fuertes y dbiles que tienen.

7. Entender un posible proceso prctico de estimacin de costes con un siste-

ma ascendente (bottom-up) a partir de una descomposicin del proyecto en

varias tareas y la estimacin directa de cada tarea por separado.


8/60



9/60


1. Mtricas del software

Para efectuar una estimacin correcta de los costes de un proyecto informticode construccin de software, se debe disponer de unidades de medida que nos

permitan relacionar las diferentes actividades de la construccin del software

con el esfuerzo en horas de trabajo o con el coste monetario que representa

tener su construccin. sta es una cuestin que se intenta resolver a partir de

las diferentes mtricas de productividad o, si se quiere, de las diversas unidades

con las que se puede medir la construccin del software.

De hecho, medir el software no es en absoluto una actividad sencilla. Se puede

decir que toda magnitud fsica se puede medir, pero el software es, sobre todo,el resultado de una actividad bsicamente intelectual, tanto en el origen como

en el resultado final. De hecho, la dificultad de medir el software ha provocado

el nacimiento de varias mtricas o unidades de medida que intentan cuantifi-

car diferentes aspectos que pueden ser relevantes en el software.

En esta definicin de mtrica se incluyen tres conceptos que conviene especi-

ficar de manera diferenciada:

Cuando hablamos de un atributo nos referimos a una determinada carac-

terstica que pretendemos medir y cuantificar*.

Cuando hablamos de un producto nos referimos, por ejemplo, a un cdi-

go, un diseo, una especificacin, etc.

Cuando se habla de un proceso se hace referencia a una etapa de la cons-

truccin del software y a la manera de llevarlo a cabo: un diseo, unas prue-

bas, etc.

Reproducimos a continuacin una definicin estricta de lo que es una mtrica de

software y que podis encontrar en el Standard Glossary of Software Engineering Terms

del IEEE.

Una mtrica es, pues, una asignacin de valor a un atributo de una en-

tidad propia del software, ya sea un producto o un proceso.

Una mtrica de softwarees una medida cuantitativa del grado en el

que un sistema, un componente o un proceso posee un determinado

atributo.

* Como podran ser el esfuerzo,la fiabilidad, la mantenibilidad,

la calidad o el tamao.


10/60


Existe una variedad impresionante de mtricas de software y, de hecho, mu-

chos autores han ido sugiriendo diferentes unidades de medida para evaluar y

cuantificar diversos aspectos considerados importantes en el software.

A menudo las mtricas se utilizan para evaluar un determinado aspecto del

software que ya existe, pero tambin para estimar a priori determinadas magni-

tudes de un software que an est por elaborar. Cabe decir, de entrada, que no

se puede llevar a cabo una estimacin posible de proyectos informticos futu-ros si no se dispone, desde el inicio, de los datos obtenidos en la evaluacin de

proyectos anteriores.

En el momento de realizar la estimacin de costes, las mtricas de productivi-

dad son las que tienen ms relevancia en la calificacin de un proyecto infor-

mtico.Por ello, aqu nos centraremos muy especialmente en dichas mtricas.

Como veremos, se dan diversos modelos para efectuar esta estimacin, pero,

evidentemente, todos se basan, de una manera o de otra, en los datos obteni-

dos en la evaluacin de proyectos anteriores. La eleccin de una mtrica enconcreto suele ser un aspecto primordial en los diferentes modelos de estima-

cin.

Cabe mencionar que, a pesar de disponer de mtricas bien escogidas e incorpora-

das a un proceso de construccin de software, contina habiendo problemas.

En definitiva, se debe tener un criterio para adoptar y utilizar una mtrica

de software. Como siempre que se mide, el hecho de disponer de unidades

de medida e, incluso, de estndares, no aleja, ms bien al contrario, la in-evitable necesidad de pensar. Disponer de mtricas puede ser una ayuda,

pero no lo es todo.

1.1. Mtricas del producto y del proceso

Una primera subdivisin de las muchas mtricas que existen las clasifica en los

dos tipos siguientes:

1) Las mtricas del producto, que miden diferentes aspectos del software ob-tenido, a menudo a partir de cdigo fuente expresado en un lenguaje inform-

tico determinado*.

En general, se puede decir que las diferentes mtricas intentan evaluartres grandes magnitudes generales: la calidad y el tamao (a menudo

del producto) y la productividad (frecuentemente del proceso de cons-

truccin del producto), aunque lo hacen desde muchos puntos de vista

diferentes.

Podis ver diferentes modelos deestimacin de costes en el apartado2 de este mdulo didctico.

La falibilidadde las mtricas

La aceptacin, que es muy fre-cuente, de las lneas de cdigocomo unidad de medida deltamao de un proyecto infor-mtico no evita errores deapreciacin (considerar o no

los comentarios o las lneas enblanco), de recuento (cada vezhay ms lneas de cdigo ge-neradas de manera automticapor las herramientas de desa-rrollo), de generalizacin (paraun mismo tratamiento, se ne-cesita un nmero diferente delneas de cdigo en funcin dellenguaje de programacin uti-lizado), etc.

* Lenguajes de programacin,de diseo, de especificacin, etc.


11/60


2) 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.

A menudo, las mtricas se pueden utilizar solas o combinadas, es decir, como

indicadores que permiten proporcionar una visin resumida del producto desoftware o del proceso de su construccin:

1) Los indicadores de producto referidos, evidentemente, al software obteni-

dopueden servir para evaluar la calidad del proceso de construccin de soft-

ware, siempre de manera comparativa con estndares de mercado o con

niveles alcanzados en otros productos.

Cabe mencionar que los indicadores de producto a menudo no estn realmen-

te disponibles hasta que no lo est el producto en s, es decir, a posteriori, cuan-

do el software de aplicacin ya se encuentra en disposicin de entrar en la

etapa de explotacin.

2) Los indicadores de proceso han de permitir conocer la eficacia de una ins-

talacinsimplemente por comparacin con los indicadores que es capaz de

conseguir respecto de los que la literatura tcnica publica.

En la ltima dcada se ha puesto de moda crear, en el marco de lo que se deno-

mina la madurez del proceso del software*, al menos en las grandes instalaciones, el

programa de mtricas de software**, que, una vez decididas unas determinadas uni-dades de medida, intenta introducir en el proceso de desarrollo y construccin de

software la buena prctica de medir diferentes aspectos y cuantificar al mximo

posible buena parte de los aspectos de la gestin de la construccin de software de

aplicacin. El hecho de disponer de estas informaciones objetivas es de gran ayu-

da en la calificacin de proyectos informticos futuros.

1.2. Mtricas de calidad y de productividad

Las diferentes unidades de medida para cuantificar el software intentan deter-

minar sus caractersticas, que se pueden resumir en calidad del producto y pro-

ductividad del proceso.

En el caso de la informtica de gestin, a menudo estas necesidades provienen

de un contrato entre el cliente y el proveedor de software, aunque, como se

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.

Como indicadorde producto...

... se puede utilizar, por ejem-plo, el nmero de errores deun software, aunque es tam-bin un indicador claro de lacalidad del proceso de cons-truccin utilizado para obtenereste software.

Como indicadorde proceso...

... si se utiliza, por ejemplo, elnmero de lneas de cdigopor persona y mes, como la ci-fra ms o menos estndar pu-blicada en los aos noventasera de 350 lneas de cdigopor persona y mes en un pro-yecto medio, una instalacinque slo consiguiera 200 sa-bra que est todava lejos de loque debera ser factible en elestado actual del arte.

* En ingls, Software ProcessMaturity.

** En ingls, Software MetricsProgram.


12/60


dice en otro mdulo, es muy difcil que todas las necesidades queden explici-

tadas convenientemente en los requerimientos.

A menudo, las mtricas de calidad forman parte de lo que se denominan medi-

dasindirectas del producto, junto con las mtricas de funcionalidad, complejidad,

eficiencia, fiabilidad, facilidad de mantenimiento y tantas otras capacidades en

cierta manera difciles de medir objetivamente.

En el caso de la productividad, es mucho ms fcil encontrar medidas directas,

como las diferentes maneras de determinar el tamao del producto obtenido

(las lneas de cdigo o los puntos de funcin, por ejemplo) relacionndolo con

el tiempo y/o el esfuerzo que ha costado obtenerlo.

Las unidades de medida como indicadores

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). Pesetas por cada millar de lneas de cdigo (indicador de coste). Pginas de documentacin por cada mil lneas de cdigo (indicador de documentacin).

En la terminologa del estndar de mtricas de productividad de software del

Instituto de Ingenieros Elctricos y Electrnicos (IEEE Standard for Software Pro-

ductivity Metrics) de 1993, se habla de primitiva para hacer referencia al nivel

msbajo en el que se recogen los datos. Evidentemente, podemos encontrar

primitivas de dos tipos:

De salida*, que recogen las caractersticas finales del software.

De entrada**, que miden lo que ha sido necesario tener y utilizar para

construirel software.

Las mtricas de calidad se asocian a unos determinados atributos

medibles, no siempre evidentes, para reconocer la presencia o ausen-

cia de calidad.

Las mtricas de productividad recogen la eficiencia del proceso de

produccin de software y relacionan el software que se ha construido conel esfuerzo que ha costado elaborarlo.

Una ratio de productividad es una relacin que se suele establecer para

tener en cuenta la productividad entre las primitivas de salida, es decir,

las unidades que miden la salida del proceso de construccin de software

y las primitivas de entrada, que miden las entradas en el proceso de

construccin de software.

Algunas medidasdirectas...

... seran las lneas de cdigo, elcoste, el esfuerzo, el nmerode errores, la velocidad de eje-cucin, la memoria ocupadapor un programa, los puntosde funcin de Albrecht, etc.

* En ingls, output primitives.

** En ingls, input primitives.

Primitivas de entraday de salida

Algunos ejemplos de primiti-vas de salida son las lneas decdigo, el nmero de errores,los puntos de funcin, el n-mero de pginas de docu-mentacin, etc.

Por otra parte, ejemplos de pri-mitivas de entrada son el esfuer-zo en horas de trabajo de unapersona, el coste en pesetas, etc.


13/60


1.3. El esfuerzo y la medida de la productividad

Con vistas a tratar la productividad en el proceso de construccin de software

de aplicacin, independientemente de cules sean las primitivas de salida uti-

lizadas (generalmente, las lneas de cdigo o los puntos de funcin que estu-

diaremos ms adelante), las primitivas de entrada intentan a menudo medirel esfuerzo o el coste que representa el hecho de construirlo. La productividad

se expresa finalmente en una ratio que relaciona las primitivas de entrada y de

salida.

Como se explica en otro mdulo, casi siempre el coste se asocia o es propor-

cional al esfuerzo que supone el trabajo, ya que los recursos humanos que in-

tervienen en un proyecto informtico son, hoy en da, los ms importantes.

Aunque conviene no olvidar que pueden darse otros costes para el hardware,

el software de desarrollo, etc., a menudo se hace la simplificacin de asociar

coste y esfuerzo en un proyecto informtico, aunque se expresen en unidades

diferentes.

Cabe mencionar que, como siempre que se efectan generalizaciones de

este tipo, se piensa en un profesional de cualificacin media, con una bue-

na formacin o una experiencia adecuada para la tarea que debe realizar y

una capacidad de trabajo media. Es evidente que en un equipo de proyecto

intervienen todo tipo de profesionales, algunos ms eficientes o ms moti-

vados que otros. El jefe de proyecto ha de tener muy en cuenta estas parti-

cularidades concretas, sobre todo a la hora de repartir las tareas que se

deben llevar a cabo. Sin embargo, en el tratamiento general de las mtricas

de productividad se piensa en un profesional genrico con capacidades,motivacin y dedicacin medias.

1.3.1. Los problemas terminolgicos del hombre-mes

En los proyectos informticos se han utilizado diferentes denominaciones de

la unidad de esfuerzo, como las siguientes:

1) En primer lugar, se habl de hombre-mes como la tarea que llevaba a cabo

un hombre duranteun 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.

La medida habitual del coste 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 (persona-

da), un mes (persona-mes) o un ao (persona-ao).

Podis ver las lneas de cdigo y lospuntos de funcin en el subapartado1.4 de este mdulo didctico.

Podis ver los recursos de unproyecto informtico en elsubapartado 1.4 del mdulo Elproyecto informtico de construccin desoftware de esta asignatura.

La denominacinhombre-mes...

... se utiliza en libros del todoclsicos, como el de Brooks(The Mythical Man-Month), apartir de la experiencia de unode los primeros grandes pro-

yectos informticos de cons-truccin de software: el sistemaoperativo 360 de IBM en losaos sesenta.


14/60


2) Ms adelante, pareci que la denominacin era claramente sexista y sebus-

caron otros nombres como stos:

Persona-mes: un mes de trabajo de una persona del equipo con indepen-

denciadel 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 programa-

cin y las pruebas para producir una determinada aplicacin o un sistema

de informacin.

Desgraciadamente, la tradicin se mantiene y es muy habitual or hablar todava

de un proyecto informtico de, por ejemplo, 50 hombres-mes, trmino que laprctica profesional parece haber estabilizado en nuestro entorno. En este texto,

hechas estas aclaraciones previas, seremos ms bien eclcticos en la denomina-

cin de esta unidad de medida del esfuerzo en un proyecto informtico.

1.3.2. El mito del hombre-mes

Los problemas que plantea la unidad persona-mes no proceden slo de querer

usar un lenguaje polticamente correcto. Inconscientemente, una unidad que

es el producto de dos (nmero de personas y meses) sugiere que debe ser po-

sible intercambiar personas y meses. Esto no es cierto, y no saberlo es uno de

los errores en los que puede incurrir el jefe de un proyecto informtico.

Por ejemplo, la figura anterior muestra diferentes maneras de imaginar un es-

fuerzo de 15 hombres-mes. Este esfuerzo se puede alcanzar tanto con una per-

* En ingls, staff.

Podis ver las etapas de la actividadde ingeniera de softwareen elsubapartado 1.8 del mdulo El proyectoinformtico de construccin de software.


15/60


sona que trabaje durante quince meses, como con quince personas que trabajen

conjuntamente durante un mes. O, tambin, por ejemplo, con tres personas

que trabajen durante cinco meses.

Matemticamente es cierto y, en los tres casos, el producto es el mismo:

1 15 =15 1 =3 5 =15.

Pero en la prctica de la construccin de software este intercambio no es

cierto. Posiblemente la tercera opcin est ms prxima a la realidad que

las otras dos.

ste es el posible error de interpretacin que quiere ayudar a corregir el artcu-

lo ms importante de los que Brooks recoge en la obra ya histrica The Mythi-

cal Man-Month.

En determinados trabajos se da una distribucin del esfuerzo a lo largo del

tiempo que les es, en cierta manera, caracterstica. Esto ocurre en la construc-

cin de software y es necesario saberlo.

Ejemplo de distribucin caracterstica del esfuerzo a lo largo del tiempo

La distribucin del esfuerzo de construccin de software se puede comparar con la tareade traer a un ser humano al mundo, proceso que, habitualmente, requiere el esfuerzo de9 meses- mujer y admite slo una distribucin temporal muy clara: una mujer con unembarazo de nueve meses. No se concibe que alguna vez se haya dado a luz a un ser hu-

mano a partir del esfuerzo conjunto de nueve mujeres durante un mes, o de tres mujeresdurante tres meses, a pesar de que el producto final parece, matemticamente, el mismo:

9 1 =1 9 =3 3 =9 meses-mujer.

Cabe decir que, en este ejemplo tan claro, no se tienen en cuenta excepciones como lossietemesinos (7 meses-mujer de esfuerzo), o los gemelos (4,5 meses-mujer de esfuerzo).

En el caso del esfuerzo para construir software, aunque puedan darse pequeas

desviaciones, tambin se tiene un tipo caracterstico de distribucin del esfuer-

zo a lo largo del tiempo que ya se muestra en otro mdulo.

1.4. Mtricas orientadas al tamao y a la funcin

Con el objetivo de medir la productividad del proceso de construccin desoft-

ware de aplicacin, debe darse la posibilidad de determinar primitivas de sali-

da que sean tiles para relacionarlas despus con el volumen del trabajo o elesfuerzo (primitiva de entrada) que representa desarrollar un producto de soft-

ware determinado.Y eso es francamente difcil.

En resumidas cuentas, llegamos a la conclusin de que los meses y los

hombres (o las mujeres) no son intercambiables.

Lectura recomendada

Podis consultar el trabajo

de Brooks sobre el mito delhombre-mes en la obrasiguiente:

F. Brooks (1975). TheMythical Man-Month.Reading (Massachusetts):Addison-Wesley.

Podis ver la figura Ciclo de vida encascada del subapartado 1.8 delmdulo El proyecto informtico deconstruccin de software de estaasignatura.


16/60


El tamao del software, construido a partir de las lneas de cdigo que ste

incluye, es una medida tradicional para evaluar el volumen de trabajo.

Pero debe conocerse, de entrada, que el tamao es una medida que, a veces,

no es lo suficientemente indicativa de lo que realmente cuesta construir un

software.

Las lneas de cdigo no siempre son una medida indicativa del esfuerzo

A veces, algoritmos laboriosos y difciles de encontrar se concretan en muy pocas lneasde cdigo (pongamos treinta o cuarenta lneas), que provocan la imposibilidad de hacer-se una idea del volumen de trabajo que representa pensar, disear y disponer finalmentede un algoritmo determinado a partir del disminuido resultado final. En este caso, recu-rrir a una medida del tamao como las lneas de cdigo puede ser poco correcto.

Por ello se han propuesto tambin otras unidades de medida que, en lugar del

tamao, intentan tener en cuenta la dificultad intrnseca de construir un soft-

ware determinado; es decir, mtricas que se refieren no al tamao del producto

final obtenido, sino a las funcionalidades que ste incorpora. Un ejemplo su-

ficientemente conocido es el de los puntos de funcin de Albrecht que des-

pus estudiaremos con detalle.

En la prctica, a pesar de los problemas y defectos que estudiaremos a conti-

nuacin, la medida de lneas de cdigo y/o de puntos de funcin es la ms ha-

bitual para determinar el volumen de un proyecto informtico, es decir, son

las principales primitivas de salida que se utilizan para calcular ratios de pro-ductividad.

1.4.1. Las lneas de cdigo

La medida ms utilizada para determinar el tamao de un proyecto inform-

tico ha sido, durante mucho tiempo, la de las lneas de cdigo del software fi-

nal obtenido. A menudo, en la literatura especializada se utilizan diversas

denominaciones segn las interpretaciones de cada uno respecto de la defini-

cin de stas. A continuacin presentamos algunas de stas:

a) LOC: lneas de cdigo. Es la ms habitual y antigua.

Es necesario decir, sin embargo, que el problema de optar por una m-

trica orientada al tamao o a la funcin no es tan grave si se tiene en

cuenta que, al menos en el caso de la informtica de gestin, se da una

especie de estndar de complejidad sencilla que no hace muy difciles

los algoritmos y que, en cierta manera, permite relacionar mtricas

orientadas al tamao, como las lneas de cdigo, con mtricas orienta-

das a la funcin, como los puntos de funcin, como veremos tambin

ms adelante. Podis ver los puntos de funcin deAlbrecht en el subapartado 1.4.2de este mdulo didctico.

LOC es la sigla de la expresininglesa Lines of Code.


17/60


b) KLOC: miles de lneas de cdigo. Es la unidad de medida que adoptan la

mayora de modelos clsicos de estimacin de costes en la calificacin de un

proyecto informtico.

c) DSI: instrucciones de cdigo fuente realmente entregadas, y su mltiplo

KDSI, quesurgieronpara que se tuviera en cuenta que, en los nuevos entornosde desarrollo y construccin de software, buena parte de las lneas de cdigo

no siempre las ha escrito el equipo del proyecto, sino que las han generado las

herramientas de productividad del entorno de programacin.

d) NCSS: lneas de cdigo fuente sin tener en cuenta los comentarios, y su

mltiplo KNCSS, por el hecho de considerar que en un buen proceso de cons-

truccin los programas incluyen lneas de comentario o que una lnea de tra-

tamiento se puede escribir en diferentes lneas de cdigo para aumentar la

legibilidad y mejorar la mantenibilidad del software.

e) NSLOC: nuevas lneas de cdigo fuente, tal como se realiza en el modelo

COCOMO 2 paraque se tenga en cuenta que slo deben contarse las lneas de

cdigo nuevas sin contar las que incorpore automticamente el entorno de

programacin, o, lo ms importante en este caso, el hecho de que parte del c-

digo final puede proceder de la reutilizacin de rutinas u objetos ya disponi-

bles que no se han de volver a escribir, pero que se incorporan al proyecto

informtico en curso.

Las diferentes denominaciones de la medida de las lneas de cdigo

Las diferentes denominaciones que existen cuando se habla de las lneas de cdigo reco-gen el hecho de que tenemos bastantes dificultades y dudas a la hora de medirlas. stosson algunos de los planteamientos que hacen difcil la valoracin:

Debemos contar o no las lneas de comentario?

Qu ocurre cuando una nica instruccin se escribe, por legibilidad, en dos o ms l-neas de cdigo fuente?

Se deben tener en cuenta las lneas que haya generado automticamente el entornode programacin (formateador de pantallas, gestor de formularios de pantalla, gestorde acceso a la base de datos, etc.)?

Se deben tener en cuenta las lneas de cdigo de rutinas o los objetos reutilizados pro-cedentes de otras aplicaciones?

Es la medida basada en las lneas de cdigo indiferente al lenguaje de programacinutilizado?

Qu pasa con las ratios de productividad establecidas cuando cambian los lenguajesde programacin utilizados?

Cada modelo de estimacin o cada programa de mtricas de software elige cul

de las muchas interpretaciones posibles se debe tener en cuenta.

De manera simplificada, aqu consideraremos que las LOC (que a menudo secuentan de mil en mil, en KLOC) son las nuevas lneas de cdigo fuente que

incluyen las directivas de compilacin*, las declaraciones de las estructuras de

DSI es la sigla de la expresininglesa Delivered Source Instructions.

NCSS es la sigla de la expresininglesa Non Comment Source

Statements.

NSLOC es la siglade la expresin inglesa New

Source Lines of Code.

* Por ejemplo, las COPY del COBOL.


18/60


datos y el cdigo ejecutable excluyendo los comentarios y las lneas genera-

das automticamente por el entorno de programacin o fruto de reutilizacin.

Cada lnea fsica de cdigo se cuenta una sola vez y cada fichero incluido au-

tomticamente** se cuenta tambin una sola vez.

Lneas de cdigo, productividad y lenguajes de programacin

Las lneas de cdigo se empezaron a utilizar como unidad de medida durante

los aos setenta y ochenta. A menudo se asocian a ratios de productividad re-

lacionndolas con el esfuerzo medido casi siempre como el trabajo que realiza

un profesional en una unidad de tiempo determinada: un da (persona-da),

un mes (persona-mes) o un ao (persona-ao).

El problema principal de las lneas de cdigo con vistas al estudio de la pro-

ductividad es que los lenguajes de programacin han ido cambiando con el

tiempo y que, evidentemente, el nmero de lneas de cdigo que es necesario

para implementar una misma funcionalidad depende del lenguaje de progra-

macin utilizado.

En su libro de 1986, el especialista Caper T. Jones ofreca datos que ilustran varios

aspectos de la productividad asociada a los diferentes 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 losaos

noventa en los proyectos de la empresa Hewlett Packard recogidos por

Robert O. Grady.

Esfuerzo para desarrollar la misma cantidad de lneas de cdigoen diferentes lenguajes

Lenguajes Tamao (LOC) Esfuerzo (persona-mes) LOC por persona-ao

Ensamblador 10.000 40 3.000

Macroensamblador 10.000 42 2.857

C 10.000 44 2.727

COBOL 10.000 48 2.500

Pascal 10.000 51 2.354

Ada 10.000 52 2.308

BASIC 10.000 53 2.264

Fuente: C.T. Jones, 1986.

** Como en el caso del COPYdel COBOL.

Podis ver las ratios deproductividad en el subapartado2.1.2 del mdulo El proyectoinformtico de construccin de softwarey en el subapartado 1.2 de estemdulo didctico.

Lectura complementaria

Encontraris datos sobre la

productividad asociadaa los diferentes lenguajesde programacin en la obrasiguiente:C. T. Jones (1986).Programming Productivity.Nueva York: McGraw-Hill.


19/60


Est claro que con lenguajes de alto nivel habr que escribir menos para obte-

ner la misma funcionalidad y, por tanto, la superior productividad aparente

(ms LOC por persona-ao) de los lenguajes de bajo nivel desaparece.

Por tanto, posiblemente es ms adecuada la tabla siguiente, tambin extrada

del libro de Jones, que ofrece resultados parecidos, pero que parte del esfuerzoque es necesario para desarrollar, en diferentes lenguajes, unos programas que

implementen una misma funcionalidad.

Los datos de Jones son suficientemente compatibles con los otros estndares

de productividad que hemos ido mencionando. Si tenemos en cuenta el CO-

BOL, e imaginamos unos 225 das de trabajo al ao exceptuando las fiestas, lasvacaciones y los fines de semana (365 14 22 52 2 =225), la productividad

de la que habla Jones es de 11,11 LOC por persona-da, que est prximo a las

10 que deca Boehm en la misma poca y es un poco inferior a las casi 16 LOC

por persona-da que representan las 350 NCSS de Grady establecidas unos

cuantos aos despus.

Cabe mencionar que estos datos provienen, como ya hemos dicho, de los aos

setenta y ochenta y no recogen lo que se puede conseguir con lenguajes de

programacin de productividad ms elevada o con las facilidades de los nue-

vos entornos de programacin y sus ayudas.

En los ltimos aos han aparecido una serie de lenguajes muy fciles de utili-

zar que unen, poco a poco, las ventajas de la orientacin a objetos con los de

la llamadaprogramacin visual. Nacidos en el mundo de la microinformtica

para ayudar a la realizacin de programas con interfaz visual bajo el paradigma

Esfuerzo y lneas de cdigo para desarrollar la misma funcionalidaden diferentes lenguajes

Lenguajes Tamao (LOC) Esfuerzo (persona-mes) LOC por persona-ao

Ensamblador 10.000 40 3.000

Macroensamblador 6.666 28 2.856

C 5.000 22 2.727

COBOL 3.333 26 2.500

Pascal 2.500 13 2.307

Ada 2.222 12 2.222

BASIC 2.000 11 2.181


Por tanto, la idea de una productividad media entre 10 y 16 LOC por

persona-da con lenguajes como, por ejemplo, el COBOL es la conclu-

sin final que se puede extraer de los datos disponibles a mitad de losaos ochenta.

El COBOL es con mucho el lenguajems usado en las aplicaciones

de gestin.

Ejemplos de programascon interfaz visual

Entre los muchos ejemplos dis-ponibles de programas bajo elparadigma WIMP, debemos

destacar PowerBuilder, VisualBasic o Delphi, que son posi-blemente los ms utilizadosactualmente.


20/60


WIMP (windows, icons, mouse ypop-up menu; es decir, ventanas, iconos, ratn

y mens desplegables), constituyen la manera ms moderna y ms evolucio-

nada de lo que se ha llamado RAD (rapid application development, es decir, el

desarrollo rpido de aplicaciones).

El problema es que todava no existen datos suficientes para tener en cuenta

estos nuevos lenguajes, que, eso s, parecen haber aumentado mucho la pro-

ductividad en la construccin de software de aplicacin.

Lneas de cdigo y el conjunto del proyecto informtico

En cualquier caso, incluso pensando en lenguajes clsicos en la informtica de

gestin como el COBOL, es evidente que si nos hablan de un programador que

es capaz de codificar slo entre 10 y 16 LOC en un da (es decir, en ocho horas

de trabajo), la primera idea es que se trata de un profesional poco eficiente.Ahora bien, cuando se habla de las lneas de cdigo como mtrica de tamao

de un proyecto informtico, no se piensa nicamente en la actividad de codi-

ficacin que lleva a cabo el programador.

Otra vez son los datos que ofrece Caper T. Jones en uno de sus libros (1986)

los que nos pueden ayudar a aclarar el significado de las LOC. Jones habla de

laproductividad aparente de una persona a partir de las LOC que se pueden im-

plementar por persona y ao. Pero debemos saber cul es el trabajo que incor-

pora cada una de las medidas o estndares.

La productividad aparente del COBOL

En el caso concreto del COBOL o en el de un lenguaje parecido, la productividad aparen-te vara mucho en funcin de las actividades que tengamos en cuenta, como vemos acontinuacin:

Si slo se tiene en cuenta la codificacin y, adems, medida en slo un da de trabajo(y convenientemente pasada a su equivalente anual), se obtienen 25.000 LOC por per-sona-ao.

Si se tienen en cuenta el diseo, la codificacin y las pruebas de slo un mdulo o ru-tina y se realiza la medida durante un mes (y despus, como antes, se pasa a su equi-valente anual), se obtiene una medida de 12.000 LOC por persona-ao.

Si se trata del diseo, la codificacin y las pruebas de un programa completo que constade diferentes mdulos o rutinas, se obtienen 6.000 LOC por persona-ao.

Cuando se tiene en cuenta la actividad de un programador durante todo un ao en lacual, evidentemente, se incluyen las interrupciones entre proyectos y, tambin, otrasactividades no directamente relacionadas con la programacin, se obtienen 4.000 LOCpor persona-ao.

Las LOC de las que se habla aqu, adems de coincidir fsicamente con

las lneas de cdigo fuente de los programas construidos, incorporan, a

los efectos de la medida de la productividad, todos los otros trabajos que

ha sido necesario realizar para llegar a la codificacin.


21/60


Si se incluyen tambin todas las actividades previas a la programacin y las pruebas (elestudio de oportunidades, el anlisis de requerimientos, el diseo, la codificacin, laintegracin, todo tipo de pruebas, las actividades de control y gestin de la calidad, ladocumentacin externa e interna y el mantenimiento de un proyecto), se obtiene unamedida de 2.500 LOC por persona-ao.

Si a las actividades anteriores se aade tambin el apoyo para un centenar de usuarios

y su formacin, la medida que se obtiene es de 750 LOC por persona-ao.

Finalmente, cuando se tiene en cuenta el esfuerzo total en software de una organiza-cin o empresa durante todo un ao, incluyendo los proyectos cancelados o fracasa-dos, los desarrollos nuevos y el mantenimiento y las ampliaciones de sistemas viejosde informacin, se obtienen 250 LOC por persona-ao.

Destacamos, entre stas, la medida de las 2.500 LOC por persona-ao, que es la ms ade-cuada porque tiene en cuenta todas las actividades que corresponden al proyecto deconstruccin de software de aplicacin que nos ocupa. El dato coincide, en orden de mag-nitud, con el intervalo entre 10 y 16 LOC por persona-da que la informtica tradicionalconsidera el estndar de productividad habitual en grandes proyectos de informtica degestin con lenguajes tradicionales como el COBOL.

1.4.2. Los puntos de funcin

Como veremos, existen diferentes modelos de estimacin de las cargas de un

proyecto informtico. La mayora utilizan como medida de las primitivas de sa-

lida las lneas de cdigo en cualquiera de las versiones posibles. Otra alternativa,

cada da ms utilizada, es la medida de los puntos de funcin que defini Albrecht

en un primer artculo del ao 1979 y que fue revisado (y relacionado tambin con

la mtrica de las lneas de cdigo) en el ao 1983 por el mismo Albrecht, ayudado

por Gaffney.

El recuento de los puntos de funcin, como veremos, deja algunos aspectos a

la interpretacin de quien lleva a cabo la medida y ello ha generado diferentes

artculos y trabajos que, manteniendo la idea central de Albrecht, intentan

ayudar a adaptar el recuento de puntos de funcin a la realidad cambiando la

informtica de gestin: bases de datos relacionales, nuevos lenguajes y entor-

nos de programacin, nuevas herramientas de programacin visual, orienta-

cin a objetos, etc.

Desde el ao 1984, el denominadogrupo internacional de usuarios de los puntosde funcin, IFPUG (de la denominacin inglesa International Function Points

User Group) publica peridicamente la manera correcta de evaluar los diferen-

tes aspectos discrecionales del recuento de puntos de funcin de Albrecht. La

versin 3.0, fechada en el ao 1990, y la 4.0, que es de 1994, son las ms uti-

lizadas hoy y la diversa literatura tcnica actual sobre puntos de funcin hace

referencia a ellas a menudo.

Actualmente, la mayora de especialistas estaran de acuerdo en afirmar que la

mtrica de los puntos de funcin es la ms utilizada. El trabajo del IFPUG la

pone en cierta manera al da, mientras que las mtricas basadas en las lneasde cdigo no siempre se han adaptado bien a los nuevos lenguajes de progra-

macin o a las herramientas RAD.

Podis ver diferentes modelos deestimacin de costes en elsubapartado 2.3 y las diferentesversiones de medidas de lneas de cdigoen el subapartado 1.4.1 de este mdulodidctico.


Podis consultar la obrasiguiente:

A.J. Albrecht; J.E.Gaffney Jr. (1983). SoftwareFunction, Source Linesof Code, and DevelopmentEffort Prediction: A SoftwareScience Validation.IEEE Transactions on SoftwareEngineering(vol. SE-9,nm.6, noviembre,pg. 639-648).

En la direccin electrnicawww.ifpug.org podisencontrar informacin de laversin ms actual del IFPUG en Internet,

aunque para obtener determinadosdatos o manuales se ha de ser socio.


22/60


A pesar de todo, contina vivo el problema de que la mtrica fue pensada du-

rante los aos setenta, cuando la informtica era bastante diferente de lo que

es hoy en lenguajes, tipo de aplicaciones, importancia de las bases de datos,

en el papel decisivo de las comunicaciones y de la distribucin de sistemas,

etc. EL IFPUG ha decidido mantener inalterada la estructura de la mtrica, lo

que no facilita su utilizacin actual. En concreto, el IFPUG recomienda, si-guiendo las directrices que establece, construir procedimientos normalizados

y uniformes en cada instalacin para proceder al recuento de los puntos de

funcin siempre de una misma manera homognea.

Como veremos, tambin ser necesario establecer para cada instalacin cul

es la ratio de productividad (puntos de funcin por persona-mes o por hora de

trabajo) que son imprescindibles para una estimacin y calificacin correctas

de proyectos informticos futuros.

Determinacin de los puntos de funcin

El recuento de los puntos de funcin se elabora a partir de determinadas ca-

ractersticas funcionales, que pueden ser de datos o de transaccin:

1) Las caractersticas funcionales de datos son las que presentamos a

continuacin:

a) Ficheros lgicos internos (LIF): grupo de datos interrelacionados lgicamen-

te yque pueden ser identificados claramente incluso por los usuarios, o a vecesinformacin de control pero que, en cualquier caso, siempre se mantienen dentro

de los lmites de la aplicacin, es decir, son internos y propios de la aplicacin.

Son los ficheros de la aplicacin (o, si se quiere, las tablas de la base de datos).

b) Ficheros de interfaces externas (EIF): grupo de datos interrelacionados l-

gicamentey que pueden ser identificados por los usuarios, o a veces informa-

cin de control pero, en este caso, proceden de fuera de los lmites de la

aplicacin y se mantienen al margen de sta. Representan los ficheros o las ta-

blas que la aplicacin utiliza pero que no crea ni mantiene.

2) Las caractersticas funcionales de transaccin son las siguientes:

a) Entradas externas (EI): hacen referencia a los tratamientos que procesan

datoso informacin de control introducidos en la aplicacin desde fuera de

sus lmites. Son, evidentemente, las entradas a la aplicacin.

b) Salidas externas (EO): cualquier proceso elemental que genere datos o in-

formacin de control que salga de los lmites de la aplicacin. Equivale a las

salidas que genera la aplicacin.

c) Consultas externas (EQ): proceso elemental formado por una combina-

cin de entrada y salida que permite la recuperacin de datos. La salida no

LIF es la sigla de la expresininglesa Logical Internal File.

EIF es la sigla de la expresininglesa External Interface File.

EI es la sigla de la expresin inglesaExternal Input.

EO es la sigla de la expresininglesa External Output.

EQ es la sigla de la expresininglesa External Query.


23/60


debe contener datos derivados y se pueden utilizar los ficheros lgicos inter-

nos. Son las consultas internas de la aplicacin, que a menudo se resuelven

con consultas en los ficheros o tablas propias.

Siguiendo una serie de directrices ms o menos objetivas que hoy elabora y man-

tiene el IFPUG, cada una de estas caractersticas funcionales queda definida comosi fuera de complejidad simple, media o compleja. En la tabla siguiente se muestra

la ponderacin de cada caracterstica funcional y la disposicin de los clculos

para obtener, gracias a pesos de ponderacin fijados por Albrecht a finales de los

aos setenta, lo que se denomina total de puntos de funcin sin ajustar(TUFP):

El mismo Albrecht ya pens que las caractersticas funcionales indicadas no

agotaban todas las posibilidades de definir funcionalmente un software de

aplicacin. Por ello, aadi que se deban considerar tambin las caractersti-

cas generales del sistema. En la formulacin establecida en el ao 1979 (y

mantenida todava por el IFPUG sin modificaciones) se dan catorce caracters-

ticas funcionales y se evala cada una de 0 a 5 (el valor medio es, pues, 2,5).

La tabla siguiente detalla las caractersticas generales del sistema y una dispo-

sicin adecuada a su clculo:

Puntos de funcin sin ajustar (TUFP)

Tipo DescripcinComplejidad

TotalSimple Media Compleja

EI Entradas externas 3 ----- 4 ----- 6 -----

EO Salidas externas 4 ----- 5 ----- 7 -----

LIF Ficheros lgicos internos 7 ----- 10 ----- 15 -----

EIF Interfaces lgicas externas 5 ----- 7 ----- 10 -----

EQ Consultas externas 3 ----- 4 ----- 6 -----

Total de puntos de funcin sin ajustar (TUFP) -----

Caractersticas generales del sistema: grado total de influencia (TDI)

ID Caracterstica del sistema Total

C1 Comunicacin de datos -----

C2 Funciones distribuidas -----

C3 Rendimiento -----

C4 Configuracin muy utilizada -----

C5 Frecuencia de transacciones -----

C6 Entrada on-linede datos -----

C7 Eficiencia de usuario final -----

C8 Actualizacin on-line -----

C9 Procesos complejos -----

C10 Reusabilidad -----

TUFP es la sigla de la expresininglesa Total Unadjusted

Function Points.

Los pesos de ponderacin

La ponderacin de las caracte-rsticas funcionales de la tablarefleja claramente las preocu-paciones de finales de los aossetenta, cuando, por ejemplo,se pensaba que el tratamientode un fichero complejo dabaprcticamente cinco veces mstrabajo que resolver el trata-miento de una entrada sencilla(eso es lo que, de hecho, quie-ren decir, comparativamente,los factores 15 para el LIF com-plejo y 3 para la EI sencilla).


24/60


Estas caractersticas generales afectan al resultado de los puntos de funcin de

manera que la suma de los valores de stas (que se encuentra siempre entre 0

y 70) se denomina grado total de influencia (TDI).

Con el valor del grado total de influencia se determina el ajuste por la com-

plejidad del proceso (PCA) segn la frmula siguiente:

PCA= 0,65 + (0,01 TDI).

Finalmente, los puntos de funcin (FP) se obtienen ajustados y definitivos se-

gn el clculo siguiente:

FP=TUFPPCA,

dondePCA es el valor de la expresin anterior.

Contina vigente un debate general sobre la idoneidad tanto de las caracters-

ticas funcionales (EI, EO, EQ, LIF, EIF), como de las caractersticas generales,

que, de hecho, se establecieron a finales de los aos setenta y, muy posible-

mente, podran no ser las ms adecuadas para reflejar las funcionalidades de

las aplicaciones de hoy da.

Aunque el IFPUG ha decidido mantener las mismas caractersticas y pondera-

ciones que escogi Albrecht sin modificar los pesos de ponderacin, peridi-

camente va publicando guas para ayudar a la determinacin de los valores de

las caractersticas generales y, tambin, del grado de complejidad de las carac-tersticas funcionales.

Por falta de espacio, no podemos incluir aqu las recomendaciones completas

del IFPUG, pero s indicaremos algunas a modo de ejemplo, extradas de la ver-

sin 4.0 (1994) del manual del IFPUG:

1) La complejidad funcional sobre los ficheros (tanto los LIF como los EIF)

sedetermina a partir de dos conceptos:

El nmero de elementos, o campos de datos, de un fichero (DET).

El nmero de registros elementales diferentes (RET).

Caractersticas generales del sistema: grado total de influencia (TDI)

ID Caracterstica del sistema Total

C11 Facilidad de instalacin -----

C12 Facilidad de operacin -----

C13 Instalacin mltiple -----

C14 Facilidad de cambios -----

Grado total de influencia (TDI) -----

TDI es la sigla de la expresininglesa Total Degree of Influence.

PCA es la sigla de la expresininglesa Processing Complexity

Adjustement.

FP es la sigla de la expresin inglesaFunction Points.

DET es la sigla de la expresininglesa Data Element Type.

RET es la sigla de la expresininglesa Record Element Type.


25/60


La complejidad de las caractersticas funcionales sale, en este caso, de una

tabla como la que presentamos a continuacin:

2) De manera similar, la complejidad de las caractersticas generales se

puedeevaluar a partir de las guas que publica el IFPUG. Por ejemplo, en la

versin 4.0, la primera caracterstica funcional (comunicacin de datos) se

determina con los valores siguientes:

Los puntos de funcin y la productividad

Para tener datos de la productividad a partir de los puntos de funcin, se

suele utilizar una ratio de productividad que indica el nmero de horas de

trabajo (siempre de un profesional medio) necesarias para implementar un

punto de funcin.

Evidentemente, como ya hemos dicho antes en el caso de las lneas de c-

digo, en este trabajo se reflejan todas las tareas necesarias, desde el estudio

de oportunidad hasta la puesta en marcha, pasando por el anlisis de los

requerimientos, el diseo de la solucin tcnica, la programacin y las

pruebas.

Aunque siempre se deben tener los datos de productividad habituales en

una determinada instalacin, Jones nos ofrece como patrn de referencialos resultados en su empresa Software Productivity Research (SPR), donde

se descompone un proyecto informtico en diferentes actividades (hasta

Medida de la complejidad de los LIF y los EIF

1 a 19 DET 20 a 50 DET 51 DET o ms

1 RET Baja Baja Media

2 a 5 RET Baja Media Alta

6 RET o ms Media Alta Alta

Caracterstica funcional: comunicacin de datos

0 La aplicacin es puramente batch o se ejecuta en un nico PC

1 La aplicacin es batch, pero tiene entrada de datos o impresin remota

2 La aplicacin es batch, pero tiene entrada de datos e impresin remotas

3La aplicacin incluye entrada de datos on-lineo TP (teleproceso) front-endpara un proceso batch o un sistema de consulta

4La aplicacin es ms que un front-end, sin embargo, soporta slo un tipo

de protocolo de comunicaciones de TP

5La aplicacin es ms que un front-endy soporta ms de un tipo de protocolode comunicaciones de TP

Lectura recomendada

Encontraris los datos queofrece Jones sobre su empresaen la obra siguiente:

C.T. Jones (1996).SoftwareEstimating Rules of Thumb.IEEE computer(marzo,pg. 116-118).


26/60


un mximo de 25 para todo tipo de proyectos). Los datos se resumen en la

tabla que presentamos a continuacin:

Teniendo en cuenta slo las actividades tpicas de los proyectos informticos

en la informtica de gestin, las horas por punto de funcin que marcan la

productividad en cada caso y una ponderacin de su importancia final en el

conjunto del proyecto, Jones obtiene una media de 1,65 horas por punto de

funcin, hecho que no deja de ser un valor muy optimista, conseguido por

una empresa que hace mucho tiempo que observa con detalle todos los pro-

cesos de mejora de la productividad.

A todos los efectos, una productividad que tenga entre dos o tres horas por

punto de funcin podra ser la ms habitual en la mayora de las instala-

ciones modernas.

1.4.3. Relacin entre puntos de funcin y lneas de cdigo

Aunque los puntos de funcin y las lneas de cdigo sean diferentes, es posible

encontrar una especie de equivalencia entre los unos y las otras. De hecho, ya

existen miles de proyectos informticos que se han medido utilizando puntosde funcin y, tambin, lneas de cdigo, hecho que ha permitido obtener ra-

tios de conversin de una unidad a la otra.

Productividad en horas por punto de funcin

Actividad Descripcin Horas/FP Ponderacin (%) Total horas/FP

01 Requerimientos 0,75 5 3,75

04 Plan del proyecto 0,26 2 0,52

05 Diseo inicial 0,75 8 6,00

06 Diseo detallado 0,88 10 8,80

08 Codificacin 2,64 40 105,60

15Documentacin deusuario

1,89 10 18,90

16 Prueba unitaria 0,88 10 8,80

17 Prueba funcional 0,88 4 3,52

18 Prueba de integracin 0,75 4 3,00

19 Prueba del sistema 0,66 4 2,64

25 Gestin del proyecto 1,32 3 3,96

Media 1,6549



27/60


Se han publicado diferentes equivalencias entre FP y LOC; la que propona

Caper T. Jones es la siguiente:

Otros autores pretenden incluso encontrar frmulas de equivalencia, como

hace Bernard Londeix, que en el caso concreto del lenguaje COBOL propone

la frmula de conversin siguiente:

LOC =118,7 FP6,490.

Sin embargo, a pesar del inters por la exactitud, cabe mencionar que las im-

precisiones en la determinacin de las LOC y, sobre todo, de los FP (a pesar de

los estndares y las recomendaciones del IFPUG), convierten en muy razona-

ble la propuesta del mismo Caper T. Jones.

La propuesta de Caper T. Jones en su columna mensual en la revistaIEEE Computer, en elao 1996, concretamente en el mes de marzo, estableca la equivalencia siguiente:

Regla 1: un punto de funcin =100 sentencias de cdigo fuente lgico.

En aquel mismo artculo, este experto justificaba la equivalencia de esta manera:El ratio entre sentencias de cdigo fuente lgico sin comentarios al punto de funcin vadesde ms de 300 sentencias por punto de funcin para los lenguajes bsicos de ensam-blador, hasta menos de 20 para los lenguajes orientados a objetos y la mayora de los ge-neradores de programas. Como los lenguajes de procedimientos (procedural) como C,COBOL, Fortran y Pascal estn prximos a una relacin de 100 en 1, este valor puede ser-vir como factor de conversin basto.

Esta regla tiene un gran margen de error y son necesarias correcciones significativascuando se trata de lenguajes de programacin orientados a objetos, generadores deaplicaciones o aplicaciones donde se utilice una cantidad significativa como cdigoreutilizado.

C.T. Jones (1996, pg. 116).

Cabe mencionar que, en este contexto, Jones considera ms bien las lneas de

cdigo lgicas que las fsicas (que dependen del estilo de cada programador)

LOC por punto de funcin

Lenguaje LOC/FP

Ensamblador 320

Macroensamblador 213

C 150

COBOL 106

Fortran 106

Pascal 91

RPG 80

PL/I 80

Ada 71

BASIC 64



Podis consultar la obrasiguiente:

B. Londeix (1987). Costestimation for softwaredevelopment. Reading(Massachusetts):Addison- Wesley.

Conversin de LOC en FP

Para lenguajes de procedi-miento, como C, COBOL,Fortran o Pascal: 100 LOCpor FP.

Para lenguajes orientados aobjeto y generadores deaplicaciones: 20 LOCpor FP.


28/60


y, sobre todo, que los puntos de funcin hacen referencia a la versin 3.0 del

recuento de puntos de funcin segn el IFPUG.

1.4.4. Una perplejidad final

Aunque parezca mentira, no existe un acuerdo total entre los datos que Jones

ofrece y los otros disponibles que hemos comentado, procedentes de Boehm

y Grady. Es ms, la diferencia es muy acusada.

Si, de manera general, un punto de funcin son 100 LOC de COBOL y, segn

hemos visto, hoy en da se implementa en dos o tres horas, en una jornada de

trabajo de ocho horas se deberan implementar entre 260 y 400 LOC, cantidad

que se encuentra muy por encima de lo que dicen Boehm y Grady (entre 10 y

15 LOC por persona-da).

En cualquier caso, no hay nada que hacer. Este tipo de contradicciones sobre

los datos de productividad son habituales en las mtricas de productividad del

software, que, evidentemente, acusan el paso de los aos y, sobre todo, las ca-

ractersticas propias (no siempre iguales) de las instalaciones y los proyectos

informticos de donde se han tomado los datos.

Como ya se ha dicho, 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 biendiferentes) y disponer de los datos de productividad propios*, datos que pue-

den haber sido obtenidos en proyectos anteriores del mismo tipo (en cuanto

a aplicacin y tecnologa) y con equipos de desarrollo de calificaciones y ca-

ractersticas personales conocidos. Por este motivo, como ya se ha dicho en

otro mdulo, es tan importante disponer de la documentacin de gestin y de

los datos de proyectos informticos anteriores.

Podis ver los datos de Boehm yGrady con relacin a las lneas decdigo en el subapartado 1.4.1de este mdulo didctico.

Podis ver la relacin que se daentre los puntos de funcin y laproductividad en el subapartado 1.4.2de este mdulo didctico.

* A partir de KLOC o de los puntosde funcin.

Podis ver el subapartado 1.6 delmdulo El proyecto informtico deconstruccin de software de estaasignatura.


29/60


2. Estimacin de costes de un proyecto informtico

Ya sabis que la gestin de un proyecto informtico de gestin empieza con lacalificacin del proyecto, que pretende, en primer lugar, obtener una idea del

volumen de trabajo que costar construir la aplicacin (estimacin) y, en se-

gundo lugar, planificar en el tiempo las diferentes actividades que es necesario

llevar a cabo (planificacin).

La primera de estas etapas se conoce tambin con el nombre de estimacin de

costes de un proyecto informtico, ya que a partir del esfuerzo de trabajo esti-

mado 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 losplazos, etapa que tambin se conoce con el nombre de tiempo de desarrollo del

proyecto. Y es necesario recordar que las funcionalidades, los plazos y el presu-

puesto definen un proyecto informtico de construccin de software.

Como ya conocis de otro mdulo, los costes que intervienen en un proyecto

informtico son variados y complejos, pero la tendencia a la disminucin del

coste del hardware y al aumento del coste del software provoca que aqu nos

podamos centrar en los costes de personal para la construccin del software de

aplicacin. La mayor parte del coste del software se encuentra hoy en el coste

de las horas de anlisis, diseo, programacin y prueba que se deben utilizarpara obtenerlo. Por ello, cuando aqu se habla de estimacin de costes se hace

referencia, exclusivamente, al esfuerzo humano que ha sido necesario, es de-

cir, a las horas de trabajo requeridas para construir el software.

De las dos etapas de la calificacin, la de la estimacin de costes y determina-

cin del volumen de trabajo que se debe llevar a cabo es claramente la ms di-

fcil y compleja. Existe mucha bibliografa sobre el tema, pero, en cierta

manera, sirve de poco. Cuando el jefe de proyecto se plantea por primera vez

evaluar el trabajo necesario para construir un software determinado slo dis-pone de unos pocos datos de lo que ha de ser la aplicacin futura y la realidad

es que no sabe en absoluto lo suficiente como para llegar a una estimacin co-

rrecta. Y este problema, simplemente, no tiene solucin.

Ya hace muchos aos que Tom de Marco dej claro este punto. En un libro

lleno de disquisiciones interesantes y con mucho sentido comn, de Marco

considera que el hecho de esperar obtener de la bibliografa tcnica datos lo

bastante fiables como para llevar a cabo una buena estimacin es una actitud

comparable a la que toman los personajes de la obra de teatro Esperando a Go-

dotdel premio Nobel Samuel Beckett. En la obra, un clsico del teatro moder-no, dos personajes pasan todo el tiempo esperando a alguien, un tal Godot,

que, simplemente, no llega nunca.

Podis ver las etapas de un proyectoinformtico en el subapartado 1.2del mdulo El proyecto informtico deconstruccin de software de estaasignatura.

Podis ver el apartado 1 del mduloEl proyecto informtico deconstruccin de software de estaasignatura.

Lectura recomendada

Os recomendamos que leisel captulo El dilema de laestimacin de la obrasiguiente:

T. de Marco (1982).

Controlling Software Projects(vol. 2, pg. 9-17).Englewood Cliffs: YourdonPress (Prentice Hall).


30/60


En palabras de de Marco:

No hay modelos de coste transportables. Si esperas que alguien en otro lugar desarrolleun 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).

Como ya se ha dicho sobradamente, es imprescindible disponer de datos con-

cretos sobre proyectos anteriores realizados en una instalacin determinada.

Si no se tienen estos datos, se deben utilizar los de la bibliografa tcnica*, aun-

que no es siempre razonable fiarse demasiado. Quiz por ello, el propio de

Marco propone las dos definiciones sucesivas muy realistas de lo que es una

estimacin, aunque parezcan ms bien cnicas:

1) Definicin implcita de estimacin: una estimacin es la prediccin ms

optimista que tiene una probabilidad no nula de llegar a ser cierta.

2) 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.

A pesar de todo, para empezar, se debe realizar una estimacin y, dejando

bien claro que en estos aspectos vale ms la experiencia que las frmulas,

aqu intentaremos comentar cmo se puede estimar a priori el trabajo ne-

cesario para construir un software de aplicacin determinado en la inform-

tica de gestin.

2.1. Momento de la estimacin y grado de exactitud

El problema, evidentemente, es que cuando se ha de llevar a cabo la primera es-

timacin todava no se dispone de las especificaciones completas de la aplica-

cin que es necesario construir. Se ignora la mayor parte del detalle de las

funcionalidades que caracterizan el proyecto. Precisamente, es en la etapa de

anlisis y diseo cuando estas especificaciones quedarn totalmente determina-

das y se podr conocer el alcance real del proyecto informtico.

Se ha intentado calcular cul es la desviacin que se presenta entre la esti-macin del volumen de trabajo que se debe realizar y el volumen que se

debe llevar a cabo realmente al final. El grfico de la pgina siguiente mues-

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.

* Por ejemplo, la productividadde 10 a 16 LOC por persona-da

o 2 horas para implementarun punto de funcin.

Lectura recomendada

Encontraris las definicionesde estimacin propuestas porde Marco en la obrasiguiente:

T. de Marco (1982).Controlling Software Projects(pg. 14). EnglewoodCliffs: Yourdon Press(Prentice- Hall).

En cuantoa la experiencia...

... el jefe de proyecto deberaser como el demonio, de quiense dice que sabe ms por viejoque por demonio.


31/60


tra cmo, a medida que avanza el proyecto informtico y se conocen con

ms detalle las especificaciones, el margen de error va disminuyendo:

Fuente: Grfico adaptado de Cost Models for Future Life Cycle Process: COCOMO 2.0 de B.W. Boehm y otros (1995).

Cabe destacar (visible en la escala de ordenadas de la izquierda) cmo la pri-

mera estimacin, realizada en el momento de la definicin inicial del produc-

to, puede tener errores de estimacin hasta cuatro veces por encima o por

debajo de lo que despus ser la carga real de trabajo.

De manera similar, tal como se ve en la escala de ordenadas de la derecha, la

duracin estimada del proyecto (es decir, el tiempo de desarrollo que marca

los plazos que caracterizan al proyecto) tiene un margen de error que va entre

el 160% y el 60% de la duracin real, siempre comparando la realidad final

con esta primera estimacin tan precaria realizada slo a partir de la definicin

inicial del producto.

2.2. Los mtodos de estimacin posibles segn Barry W. Boehm

En el libro de Barry W. Boehm (1981), que se ha convertido en un clsico sobre

el tema, se exponen siete maneras diferentes de proceder a la estimacin ini-

cial de costes de un proyecto informtico. Algunas pueden parecer extraas e

incluso poco serias, sin embargo, si se tiene en cuenta la realidad de mercadoy la prctica real, los siete procedimientos que menciona Boehm (evidente-

mente, no todos recomendables) son bastante esclarecedores.


32/60


A continuacin se exponen los siete mtodos que menciona Boehm, con co-

mentarios complementarios, tal vez ajenos a la voluntad inicial del autor:

1) Utilizacin de modelos: Boehm los denomina modelos algortmicos y

proporcionan uno o ms algoritmos que dan una estimacin del coste delsoft-

ware como funcin de un nmero de variables determinado que se consideraninfluyentes en este coste. Estos modelos, como veremos, pueden ser tambin

de base estadstica, terica o compuestos.

2) Juicio de expertos en el tipo de proyecto: mtodo que supone basarse

fundamentalmente en la experiencia de uno o ms profesionales expertos que

ya hayan actuado en diferentes ocasiones como jefes en proyectos bastante

parecidos al que nos preocupa.

3) Analoga con otro proyecto parecido: estrategia que pretende ampararseen los datos disponibles obtenidos en otro proyecto de construccin de soft-

ware que sea en cierta manera anlogo al que nos ocupa en aspectos clave

como la tecnologa, el tipo de aplicacin, el personal que interviene, etc.

4) Utilizar todos los recursos disponibles: caso habitual que se da cuando

no segestiona un proyecto informtico y se destinan los recursos que pa-

recen necesarios en cada momento del desarrollo. Con respecto a este pun-

to, Boehm hace una referencia explcita a lo que se conoce como la ley de

Parkinson, segn la cual el trabajo siempre se expande hasta ocupar todos

los recursos disponibles. Esta ley es fruto de la observacin y el ingenio de

Cyril Northcote Parkinson.

5) Precio ganador: estrategia que propone simplemente una estimacin de

cargas (esfuerzo, coste y/o tiempo de desarrollo) que provoque que la oferta

sea irresistible, con independencia de si despus se puede cumplir o no. O se

iguala automticamente el coste al valor ms bajo para conseguir un contrato,

o se escoge automticamente un tiempo de desarrollo y unos plazos que, con

independencia del trabajo se deba llevar a cabo, permitan al producto ser el

primero en llegar al mercado.

Una estrategia habitual

Desgraciadamente, la estrategia del precio ganador es en demasiadas ocasiones la reali-dad del mundo mercantilizado en el que nos movemos: si dos o tres empresas proveedo-ras deben realizar una oferta de lo que puede costar (en tiempo y dinero) construir unaaplicacin informtica determinada, es casi seguro que se llevar el contrato la que reali-ce una oferta ms barata o la que ofrezca un tiempo de desarrollo inferior. El hecho deque despus puedan surgir problemas para cumplir lo que se ha prometido es, simple-mente, consecuencia de la estrategia con la que se ha conseguido el contrato.

6) Estimacin global descendente*: mtodo que intenta obtener un dato

nicoy global para todo el proyecto informtico a partir de diferentes propie-dades globales del producto final (tamao, complejidad, dificultad tcnica, ni-

vel de calidad y fiabilidad, etc.) que, despus, se va descomponiendo.

Lectura recomendada

La idea de que el trabajo,si no se controla, ocupasiempre todos los recursosdisponibles, se expone demanera muy divertida en laobra siguiente:Cyril Northcote Parkinson(1962).Al patrimonio por elmatrimonio (tercera ley deParkinson). Bilbao: Deusto.

* En ingls, top-down.


33/60


7) Descomposicin en actividades (WBS) y estimacin ascendente*: mto-

do quedescompone el conjunto del proyecto en diferentes actividades** y,

una vez estimado el esfuerzo para cada una de stas, obtiene por agregacin el

esfuerzo total del proyecto.

Cabe destacar que, al margen del realismo de algunos de los mtodos mencio-nados por Boehm, los seis primeros representan mtodos estratgicos y tcti-

cos que, a menudo, dan lugar a una estimacin nica de la totalidad del

proyecto. Como veremos ms adelante, el mtodo ms operativo es el spti-

mo, que permite, adems, obtener un desglose del proyecto informtico en ac-

tividades, hecho que nos ser muy til tanto en la planificacin, como en el

seguimiento y control del proyecto.

A pesar de todo, la mayora de los mtodos que recogen los libros (y ste no

ser en absoluto una excepcin) tratan la estimacin de costes por mtodos y

modelos algortmicos o con base estadstica. En este caso, como veremos en-

seguida, se ofrecen frmulas que suelen ofrecer como resultado de la estima-

cin una nica cifra global para todo el proyecto informtico.

2.3. Modelos de estimacin

Antes de disponer de modelos, lo que se haca era recurrir a la apreciacin per-

sonal del jefe de proyecto, que a menudo basaba sus estimaciones en una ex-

periencia propia no siempre objetiva o reflejada en datos concretos.

A medida que se introducen los programas de mtricas de software,se empieza a

disponer de datos reales de proyectos ya elaborados. Ello permite escapar de la

subjetividad personal e intentar expresar en modelos y frmulas todo aquelloque el estudio estadstico o terico de los datos disponibles nos permite deducir

con respecto a la productividad en la construccin de software de aplicacin.

Los diferentes modelos de estimacin de costes y/o esfuerzos en la cons-

truccin de software* se pueden dividir en cinco grandes grupos principales:

modelos conbase histrica, con base estadstica, tericos, compuestos y basa-

dos en estndares. A continuacin los presentamos brevemente:

1) 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 histo-

ria) de los que efectan la estimacin.

La idea de los modelos de estimacin es la de proporcionar sistemas y

mtodos generales para proceder a realizar la estimacin de costes en la

construccin de software de aplicacin.

* En ingls, bottom-up.

** En ingls, Work BreakdownStructure.

Podis ver la operatividad delmtodo de descomposicin enactividades y estimacin ascendenteen el subapartado 2.4 de este mdulodidctico. Podis ver tambin laplanificacin, el seguimiento y el controlen el mdulo La gestin de un proyectoinformtico de esta asignatura.

Podis ver los modelos deestimacin en el subapartado 2.3 deeste mdulo didctico.

Podis ver los programas demtricas de softwareen elsubapartado 1.1 de este mdulodidctico.

* En la denominacin inglesa,Cost Estimating Models.


34/60


2) Los modelos de base estadstica intentan superar la experiencia histrica

concreta de unos cuantos profesionales y, 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 unida-

des de medida del software, a menudo las lneas de cdigo (LOC) y el esfuerzo

(generalmente medido en hombre-mes).

3) Los modelos de base terica proporcionan otro enfoque. Estosmodelos,

ms que basarse en datos estadsticos disponibles no siempre suficientemente

abundantes y/o generalizables, lo que hacen es partir de una serie de ideas ge-

nerales sobre el proceso de construccin de software y, sobre esta teora, elabo-

ran frmulas que relacionan diferentes mtricas de software.

4) Los modelos compuestos han arraigado a partir de los trabajos de Barry

W. Boehm.Estos modelos intentan obtener las ventajas de los dos sistemasanteriores: estadsticos y tericos. Es decir, se parte de una serie de plantea-

mientos tericos y se complementan o corrigen con datos estadsticos obteni-

dos de proyectos reales ya acabados.

Dado que a menudo los modelos mencionados anteriormente son poco fia-

bles y ofrecen un grado de error nada despreciable, la prctica profesional ha

provocado que muchas instalaciones* hayan adoptado un sistema ms simple

y menos complicado: la elaboracin de estndares de productividad obte-

nidos en proyectos anteriores de la misma instalacin. Para llevar a cabo la es-

timacin de nuevos proyectos se parte de estos estndares.

Tambin al margen de los estndares propios de cada instalacin, en la biblio-

grafa tcnica se encuentran las que podramos denominar recomendaciones

prcticas a primera vista*, que han sido elaboradas por especialistas prestigiosos

y que puedenactuar como referencia general futura para los estndares pro-

pios de una instalacin que empieza a desarrollarse.

Cabe sealar que la mayora de los modelos disponibles se han elaborado du-

rante los aos setenta y ochenta y, evidentemente, responden a una informticabastante diferente de la que se lleva a cabo en la actualidad, que ha mejorado

bastante la productividad por medio de nuevos entornos de programacin, nue-

vos lenguajes visuales y orientados a objetos, nuevas herramientas de ayuda,

etc. Pero, en cualquier caso, los resultados que ofrecen los modelos de estima-

cin ms algortmicos pueden actuar siempre como hito superior de la estima-

cin que se quiere realizar.

Tambin cabe mencionar que la mayora de modelos disponibles suelen

utilizar las lneas de cdigo (LOC) como base para obtener otras medidas:

el esfuerzo medido en personas-mes, los meses de construccin del proyec-to, el nmero de profesionales que deberan estar involucrados, el nmero

de errores que se puede esperar tener, el nmero de pginas de documen-

* Generalmente, las instalacionesmayores y con ms experiencia.

* Rules of thumb,en la denominacin inglesa.

Podis ver las LOC con relacin allenguaje de programacin utilizadoen el subapartado 1.4.3 de este mdulodidctico. Podis ver tambin lasherramientas RAD en el subapartado1.4.1 de este mdulo didctico.


35/60


tacin que es necesario realizar, etc. En la mayora de modelos todo parte

de las LOC, que, como ya hemos visto, son una mtrica que depende de-

masiado de los lenguajes de programacin (y stos han cambiado mucho

en los ltimos aos) y que hoy en da a menudo son difciles de medir, so-

bre todo con las actuales herramientas RAD, que generan gran parte de l-

neas del cdigo final.

2.3.1. Modelos histricos

Tal vez el mtodo ms utilizado todava para realizar la estimacin de costes

es el que se basa en la experiencia personal de quien la lleva a cabo (por ejem-

plo, el jefe de proyecto). Como podis suponer, se trata de un mtodo marca-

damente subjetivo y muy propenso a errores. Puede ocurrir que quien realicela estimacin no tenga en cuenta de manera adecuada todos los aspectos que

pueden intervenir en el proyecto y tambin puede suceder que la experiencia

disponible no se corresponda en absoluto con el tipo de proyecto o de aplica-

cin que se debe efectuar.

Este sistema se puede aplicar tanto a mtodos descendentes, como a mtodos

ascendentes. En el segundo caso, se realizan estimaciones independientes de

cada uno de los subproyectos o de las fases (e incluso de las actividades con-

cretas, si ya se tiene claro cules sern) para obtener la estimacin del proyectocompleto sumando las estimaciones de las diferentes partes.

Combinacin de estimaciones individuales

Puede ocurrir que, cuando el proyecto tiene una cierta envergadura, se pida la

opinin de ms de un experto y se tenga que combinar dos o tres estimaciones.

En este caso, existen diferentes tcnicas para intentar encontrar una combina-

cin adecuada, sobre todo para evitar que, en reuniones conjuntas, el estimador

con ms personalidad imponga su criterio sobre el resto. A continuacin men-cionamos tres de estas tcnicas:

a) Media. La manera ms sencilla de llegar a una combinacin adecuada es,

simplemente, calcular la media entre las diferentes estimaciones obtenidas

por separado.

b) Media ponderada. Otro procedimiento consiste en tener en cuenta que

puedendarse estimaciones pesimistas y optimistas y que se deben tener en

cuenta de una manera diferente a otras estimaciones intermedias. Lo quese hace, pues, en lugar de calcular la media habitual, es establecer una me-

dia ponderada, que podra ser, por ejemplo, en el caso de tres estimaciones,


36/60


la que recomendaba Pressman en las primeras ediciones de su libroIngenie-

ra del Software:

est imac ion de costes de un proyecto informatico

Documents