T9899 DCerrillo

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMTICA
Planificacin y Gestin de Sistemas de Informacin.
ESTIMACIN DEL SOFTWARE.
Autor: David Cerrillo

Profesor: Francisco Ruiz
Mayo de 1999
Estimacin del software. PGSI. 1
Abstract
En este documento se da una visin general del proceso de estimacin del software. Se
indican los fundamentos matemticos de la estimacin y se la encuadra dentro de la gestin de
proyectos software. Se divide la estimacin, en prediccin del tamao, del esfuerzo y del tiempo
empleado para realizar el proyecto. Se hace especial hincapi, en la estimacin del esfuerzo
como pieza central y fundamental de todo el proceso. Se propone un proceso general de
prediccin y un marco de trabajo para seleccionar mtricas y mtodos predictivos. El proceso de
prediccin y la seleccin del marco de trabajo, resaltan la importancia de las mtricas dentro del
contexto de desarrollo de sistemas, y la necesidad de guardar los resultados y utilizar la
experiencia adquirida para mejorar la precisin de futuras estimaciones de software.
Contenido.
Abstract .................................................................................................................................................... 1
Contenido................................................................................................................................................. 2
1. Introduccin. ........................................................................................................................................ 3
1. 1. Qu es una estimacin? .................................................................................................................. 3
1.2. Evaluacin de la precisin de la estimacin...................................................................................... 4
1.3. Regresin lineal................................................................................................................................. 6
1.4. Anlisis de regresin slido. ............................................................................................................. 8
1.5. Regresin multivariante. ................................................................................................................... 8
2. Gestin del Proyecto de Software. ....................................................................................................... 9
2.1. Establecer el mbito. ......................................................................................................................... 9
2.2. Medicin y mtricas........................................................................................................................ 10
2.3. Estimacin....................................................................................................................................... 10
2.4. Anlisis de riesgos. ......................................................................................................................... 11
2.5. Planificacin. .................................................................................................................................. 11
2.6. Seguimiento. ................................................................................................................................... 11
3. Introduccin al Proceso de Estimacin. ............................................................................................. 12
3.1. Estimacin del tamao. ................................................................................................................... 12
3.1.1. Metodologa de los Puntos de Funcin. ....................................................................................... 14
3.2. Estimacin del Esfuerzo.................................................................................................................. 20
3.2.1. Proceso de Prediccin. ................................................................................................................. 21
3.2.2. Marco de Trabajo. ........................................................................................................................ 24
3.2.3. Proceso de Estimacin del Coste del Software. ........................................................................... 29
3.2.4. Modelos de Estimacin del Coste. ............................................................................................... 35
3.3. Estimacin de la planificacin. ....................................................................................................... 50
3.3.1. Observaciones de Norden. ........................................................................................................... 52
3.3.1. Planificacin basada en compromiso. .......................................................................................... 53
3.3.2. Mtodo de estimacin de primer orden de Jones. ........................................................................ 54
4. Conclusin. ........................................................................................................................................ 55
Apndice A. ........................................................................................................................................... 56
Bibliografa. ........................................................................................................................................... 58
1. Introduccin.
Estimar consiste en determinar el valor de una variable desconocida a partir de otras
conocidas, o de una pequea cantidad de valores conocidos de esa misma variable. La
estimacin forma parte de la inferencia estadstica. El razonamiento por inferencia va de lo
particular a lo general, de lo conocido a lo desconocido, y puede decirse que es lo inverso a la
deduccin, que va de lo general a lo particular. Se da el nombre de poblacin a cualquier
conjunto o conglomerado numeroso de objetos a estudiar. Pero esta definicin es tan general
que prcticamente no dice nada y, de hecho, no adquiere verdadero significado sino se asocia a
la definicin de muestra, que es alguna parte o subconjunto de una poblacin ordinariamente
seleccionada, o de modo deliberado para que las propiedades de la poblacin, se pongan de
relieve. Los valores de las diversas medidas descriptivas de poblaciones se conocen como
parmetros, pero cuando se refieren a muestras se denominan estadsticos. As como el
parmetro define una poblacin, el estadstico describe una muestra.
Puede considerarse, el estadstico de una muestra, como una estimacin del parmetro
de una poblacin. Una medida de estimacin o estimador, es una funcin de las puntuaciones de
una muestra, que da lugar a un valor denominado estimacin, el cual suministra informacin
sobre el parmetro. Por ejemplo la media de la muestra es un estimador de las puntuaciones
promedio de la poblacin.
Si enfocamos todos estos conceptos estadsticos hacia nuestro caso particular de la

estimacin del software, tendremos que los parmetros a estimar son: el tamao del proyecto, el
esfuerzo para realizar el mismo, el coste y el tiempo que se tardar en desarrollarlo. La
poblacin seran los proyectos similares realizados. La muestra podran ser los proyectos
similares realizados en nuestra compaa, y los estimadores los valores de los estadsticos
correspondientes a los parmetros de la muestra. Un posible estimador para el tamao del
proyecto podra ser la media del tamao de los proyectos de la muestra.
1. 1. Qu es una estimacin?
Es importe pensar en una prediccin como en un rango mas que como un simple
nmero. Una estimacin o prediccin no es un objetivo, sino una valoracin probabilstica. El
valor que se obtiene de una estimacin es el centro del rango.
DeMarco fue uno de los primeros en explicar que una estimacin es una prediccin que
es igualmente probable que est por encima o por debajo del resultado real. Para comprender lo
que esto significa, consideremos una situacin en la cual queremos estimar (desde un conjunto
de requerimientos) el tiempo que nos llevar finalizar un proyecto. Imaginemos que pudiramos
registrar los valores reales de finalizacin de un gran nmero de proyectos, que hayan
implementado el mismo conjunto de requerimientos. Entonces podramos ser capaces de dibujar
la funcin de densidad del tiempo t necesario para finalizar el proyecto con los requerimientos
establecidos; tenemos un ejemplo en la figura 1. La funcin de densidad en la figura 1 es una
distribucin normal, pero no necesariamente ha de ser siempre as. Desde este grfico podemos
calcular la probabilidad de que cualquier proyecto basado en los requerimientos dados ser
finalizado en un intervalo de tiempo [t1,t2]; la probabilidad es simplemente el area bajo la
curva, entre t1 y t2. Por ejemplo, la probabilidad de que el proyecto se complete entre los meses
8 y 16 es aproximadamente 0,9, y la probabilidad de que el proyecto sea realizado en menos de
12 meses es de 0,5. Normalmente, estaremos interesados en que la probabilidad de que un
proyecto pueda ser finalizado en un tiempo t, es decir el intervalo ser [0,t].
Formalmente una estimacin se define como la mediana de una distribucin. De este

modo, la estimacin debe dividir el rea bajo la curva en dos partes iguales: parte A y parte B
(figura 1). En otras palabras, el valor real es la probabilidad de ser menor o mayor que la
estimacin.
Figura 1.
Los ingenieros de software frecuentemente entienden mal el concepto de estimacin,

considerndole, en nuestro ejemplo, como el nmero mas pequeo de meses en el cual el
proyecto puede ser completado. Esta interpretacin apunta al mnimo valor t para el cual un
intervalo [t,t+e] tiene una probabilidad distinta de cero ( esto es, el valor mas a la izquierda de la
curva, distinto de cero). Este valor mnimo es el tiempo mas corto en el cual se puede completar
el proyecto. En la figura este valor es aproximadamente cuatro.
Incluso cuando el significado de la estimacin se entiende correctamente, muchos

ingenieros de software crean estimaciones y las establecen como objetivos. Mediante la
designacin de la mediana de la distribucin de probabilidad como el objetivo, sabemos que hay
un 50% de probabilidad de que el proyecto dure mas tiempo. De este modo hay el 50% de
probabilidad de que no se alcance el objetivo. Un estudio realizado por Jeffery y Lawrence
encontr que la productividad era peor en proyectos donde fueron establecidos objetivos. Los
gestores de proyectos entienden que la estimacin es el centro del rango en el cual el proyecto
puede ser completado, y estudian la probabilidad de los casos en los que el proyecto puede
tomar menos o mas tiempo que el estimado.
De este modo, para indicar el rango, la estimacin se ha de presentar como una tripleta:
el valor mas probable (que es, la mediana de la distribucin), mas los lmites superior e inferior
del valor. En trminos estadsticos a estos lmites inferior y superior se les denomina intervalos
de confianza.
1.2. Evaluacin de la precisin de la estimacin.

Una vez que nuestro proyecto est terminado, tenemos la oportunidad de comparar los
valores reales con las estimaciones que hicimos anteriormente. Supongamos que Vf es nuestro
valor estimado y Va nuestro valor real: El error relativo en nuestra estimacin es:
V A VF (1)
MRE =
VA
Frecuentemente, necesitamos obtener el error relativo de un conjunto de estimadores.

Por ejemplo, nosotros usualmente queremos saber si nuestras predicciones de esfuerzo son
precisas para un grupo de proyectos desarrollado. Aqu tenemos el error relativo medio para n
proyectos:
____
1 n
RE = REi
n i =1 (2)
Tambin es posible calcular la magnitud del error relativo. Para n proyectos la magnitud del
error relativo ser:
______
1 n
MRE = MREi
n i =1 (3)
Si la media de la magnitud del error relativo es pequea, entonces nuestras predicciones son
buenas.
Esta nocin se usa para definir la mtrica calidad de prediccin. Para un conjunto de n
proyectos, i es el numero de ellos cuya magnitud media del error relativo es menor o igual que l.
i
pred (l ) = (4)
n
La mtrica pred proporciona una indicacin del grado de ajuste para un conjunto de datos,
basado en el valor de RE obtenido para cada dato.
A modo de ilustracin, si pred(0,25)=0,4, entonces nosotros podemos decir que el 40%

de los valores de ajuste caen dentro del 25% de sus correspondientes valores actuales. En
trminos de evaluacin del rendimiento de un modelo dado, se podra considerar un buen
modelo aquel que consiguiera que MMRE<=0,25 y pred(0,25)>=0,75.
DeMarco sugiere el uso de un mtodo denominado factor de calidad de la estimacin

(estimating quality factor EQF) para evaluar la precisin del proceso (DeMarco, 1982). Con
esta tcnica, las estimaciones se realizan repetidamente a lo largo de todo el proceso. La
estimacin va aproximndose al valor real segn avanza el proyecto. La figura 2 muestra varios
esfuerzos estimados que estn siendo comparados con el valor real. La regin sombreada de la
figura 2 representa la diferencia entre los valores estimados y los reales. Si dividimos el rea de
la regin sombreada por DxA, obtenemos una mtrica de la efectividad del proceso de
estimacin, en trminos del grado de convergencia del valor real.
EQF vara desde cero hasta infinito. Para una serie de estimaciones, DeMarco sugiere
un valor de 4 (el cual corresponde a una estimacin dentro del 25% del valor real del esfuerzo
de desarrollo), que debe ser relativamente fcil de retener, y los estimadores de coste deben
guardar valores de 8 o superior.
Figura 2
1.3. Regresin lineal.

A menudo deseamos estimar, basados en los datos de una muestra, el valor de una
variable y correspondiente a un valor dado de otra variable x. Ello se puede hacer estimando el
valor de y mediante la recta de mnimos cuadrados que ajuste los datos. La recta resultante se
llama recta de regresin de y sobre x, ya que y se estima a partir de x.
La regresin lineal es un conocido mtodo para expresar una asociacin como una
formula lineal. Cada par de atributos se expresa como un punto de datos(xi,yi), y entonces se
calcula la lnea que mejor se ajusta entre la nube de puntos. Nuestra meta es expresar el atributo
y en trminos del atributo x, en una ecuacin de la forma:
y = a + bx (5)
Tenemos en la figura 3 un ejemplo de una recta de regresin del esfuerzo de realizacin

de un proyecto sobre el tamao del mismo.
La teora detrs de la regresin lineal, es dibujar una linea desde cada punto verticalmente hacia
arriba o hacia debajo de la linea que denota la tendendia de los puntos. En cierto sentido la
longitud de estas lnea representa la discrepancia entre los datos y la lnea. Nuestra intencin es
conseguir que este discrepancia sea la mnima. De este modo la recta del mejor ajuste, es la
lnea que minimiza estas distancias.
Figura 3
Los clculos matemticos necesarios para determinar los coeficientes a y b, de esta lnea
del mejor ajuste son directos. La discrepancia de cada punto se denomina residual, y la
expresin para generar la lnea de regresin lineal minimiza la suma de los cuadrados de los
residuales. Podemos expresar el residual para un punto dado como:
ri = yi a bxi (6)
Minimizando la suma de los cuadrados de los residuales se obtienen las ecuaciones

siguientes para a y para b:
b=
( x m )( y m
i x i y )
(x m )
i x
2 (7)
a = m y bm x (8)
La tcnica de los mnimos cuadrados (least-squares LS), no hace suposiciones acerca de

la normalidad de cada atributo. Sin embargo para realizar cualquier test estadstico relacionando
los parmetros de regresin (por ejemplo, podemos querer determinar si el valor de b es
significativamente diferente de cero), si sera necesario asumir que los valores de los residuales
estn normalmente distribuidos. Esta tcnica se ha de utilizar con cuidado cuando existen
numerosos datos atpicos, pues estos datos pueden distorsionar la estimacin de a y b.
Es importante mantener en la mente que la naturaleza lineal de la regresin, nicamente

alude a la forma lineal de los coeficientes de los parmetros. Se pueden realizar
transformaciones sobre las variables, para permitir modelado lineal.
Una vez que se ha determinado la recta que mejor se ajusta, su consistencia y precisin
puede ser evaluada usando un conjunto de datos de validacin, en los cuales los valores de estos
datos se sustituyen en la ecuacin de regresin, y se determina la diferencia entre el valor
predicho y el actual. El uso de algunos conjuntos de datos que no ejercen ninguna influencia
sobre el modelo seleccionado es esencial para una estimacin no influyente de las propiedades
del modelo. Si se utiliza un conjunto de datos para estimar los parmetros del modelo para
diferentes modelos, y se emplea otro conjunto de datos para escoger el mejor modelo, entonces
es obligatorio que exista otro conjunto para determinar el funcionamiento del modelo sobre los
nuevos datos.
Se pueden emplear diferentes mtodos para estimar los errores del modelo. Estos
incluyen, las diferentes formas de correlacin. Comnmente se utiliza una pareja de indicadores
para determinar lo adecuado del modelo predictivo: La magnitud media del error relativo MRE
(ecuacin )y medida de calidad de prediccin (pred).
1.4. Anlisis de regresin slido.

Las limitaciones del mtodo de anlisis de regresin lineal, son debidas en parte a que el
mtodo asume una distribucin normal de los datos. Sin embargo muchos datos en ingeniera
del software no cumplen este requerimiento. Los datos estn frecuentemente sesgados hacia la
derecha y pueden contener una serie de valores aislados. Un ejemplo comn donde se puede ver
esta caracterstica, es el estudio de la frecuencia de errores en los mdulos de un programa,
creados por un equipo de desarrollo. Los valores estn concentrados cerca del cero, pero los
casos de mdulos con muchos errores generan valores aislados y hacen que la distribucin se
aleje del modelo normal. En estos casos el modelo de regresin lineal LS es ineficiente.
La idea general detrs de la regresin slida es que cambiando la medida del error
(anteriormente realizada mediante mnimos cuadrados) el modelo puede hacerse ms resistente
a valores aislados. Existen diferentes modelos de regresin slidos, frecuentemente con la
medida del error basada en la mediana, en lugar de en la media.
El uso de regresin slida es especialmente atractivo cuando el nmero de datos de que

disponemos es pequeo, y consecuentemente sensible a los datos aislados, y a contener errores
en la medida. La regresin basada en los mnimos cuadrados tomando la mediana como
referencia (least-median-squares) proporciona una estimacin que puede ser afectada por un
50% de contaminacin (puntos que se alejan de la distribucin normal). Se dice entonces que
tiene un punto de ruptura de 0,5, a diferencia de la regresin lineal LS que tena un punto de
ruptura de 0, pues se vea afectada por cualquier punto aislado.
En la figura 4 puede verse, como un simple punto aislado tiene un efecto dramtico
sobre la regresin lineal con mnimos cuadrados basados en la media. Esto hace que el modelo
de regresin lineal LS, no nos valga para predecir puntos nuevos como A.
1.5. Regresin multivariante.

Los mtodos de regresin que hemos considerado se han enfocado para determinar una
relacin lineal entre dos atributos. Cada uno implica el uso de la tcnica de los mnimos
cuadrados. Esta tcnica se puede extender para investigar una relacin lineal entre una variable
dependiente y dos o mas variables independientes. A esto se le llama regresin lineal
multivariante. No obstante, hemos de ser cautos cuando consideremos un numero elevado de
atributos, debido a lo siguiente:
No siempre es posible evaluar la relacin visualmente, puesto que hay valores atpicos
que no pueden ser detectados fcilmente.
Las relaciones entre variables dependientes pueden dar como resultado ecuaciones
inestables.
La regresin lineal slida multivariante puede ser bastante complicada.
Para la regresin lineal multivariante, se recomienda utilizar anlisis mediante mnimos

cuadrados LS, pero evitando el uso de muchas variables dependientes correlacionadas. Hay que
asegurarse de analizar los residuales, a fin de chequear datos atpicos, esto es puntos que tiene
residuales muy grandes.
Figura 4
2. Gestin del proyecto de software.

Una vez que hemos visto los aspectos fundamentales de la estimacin en general, y de
la estimacin del software en particular, vamos a ver en este punto, la estimacin del software
como una de las partes iniciales de la gestin de un proyecto. Veremos como est relacionada
con el resto de las partes y la importancia que tiene dentro del proceso de gestin.
Si queremos conseguir que un proyecto software se lleve a cabo con xito debemos
comprender el mbito del trabajo a realizar, los riegos en los que podemos incurrir, las tareas
que se han de llevar a cabo, las etapas que hemos de recorrer, el coste del proyecto, y el plan a
seguir. Este conocimiento nos lo proporciona la gestin del proyecto de software. Empieza antes
de que comience el trabajo tcnico, continua a medida que el software evoluciona desde un
nivel conceptual hasta la realidad y finaliza en el momento en que se abandona el software.
2.1. Establecer el mbito.

Antes de poder empezar a planificar un proyecto, se han de establecer el mbito y los
objetivos, deben considerarse soluciones alternativas y han de identificarse las restricciones
tcnicas y de gestin. Sin esta informacin no hay manera de realizar unas estimaciones de coste
razonables, una identificacin realista de las tareas del proyecto o un plan de trabajo adecuado
que proporcione una indicacin significativa del proyecto.
El desarrollador del software y el cliente deben ponerse de acuerdo para definir el

mbito y los objetivos del proyecto. Los objetivos identifican los fines globales del proyecto sin
considerar como se llegar a esos fines. El mbito identifica las funciones primordiales que debe
llevar a cabo el software y, lo que es ms importante, intenta limitar esas funciones de manera
cuantitativa.
Una vez entendidos los objetivos y el mbito del proyecto, se han de considerar
soluciones alternativas. Aunque se estudien con muy poco detalle, las alternativas han de
permitir a los gestores y a los desarrolladores seleccionar el mejor enfoque, dadas las
restricciones impuestas por las fechas tope de entrega, los lmites presupuestarios, la
disponibilidad de personal, las interfaces tcnicas y multitud de otros factores.
2.2. Medicin y mtricas.

Una de las formas de progresar en una organizacin software, a largo plazo, es recoger
datos mtricos para analizar la calidad y productividad del software. Prcticamente todos los
proyectos recogen datos sobre los costes y la planificacin. Pero estos datos son limitados y no
ayudan mucho a reducir los costes o a disminuir la planificacin.
Recoger ms datos puede suponer mucho tiempo. Si adems de datos de coste y

planificacin se obtienen datos histricos, como el tamao de los programas en lneas de
cdigo, o cualquier otra medida, se tendrn las bases para la planificacin de proyectos futuros.
Para realizar el desarrollo de forma eficiente, se necesita tener unos conocimientos

bsicos sobre las medidas o mtricas del software. Se necesita conocer los temas a los que
afecta la recogida de medidas, incluyendo qu cantidad o cunto tiempo se necesitara para
recogerlos y cmo hacerlo. Se deberan tener conocimientos sobre mtricas especficas y
utilizarlos para analizar el estado, la calidad y la productividad.
2.3. Estimacin.
Los proyectos bien ejecutados pasan por tres etapas bsicas para crear una planificacin
software. Primero se estima el tamao del producto, luego el esfuerzo necesario para construir
un producto con este tamao y por ltimo la duracin cronolgica del proyecto.
En muchos casos, las estimaciones se hacen valindose de la experiencia pasada como

nica gua. Si un nuevo proyecto es bastante similar en tamao y funcin a un proyecto pasado,
es probable que el nuevo proyecto requiera aproximadamente al misma cantidad de esfuerzo,
que dure aproximadamente el mismo tiempo y que cueste aproximadamente lo mismo que el
trabajo anterior. Pero si el proyecto es totalmente distinto, la experiencia no ser suficiente.
Se han desarrollado varias tcnicas de estimacin para el desarrollo de software.

Aunque cada una tiene sus puntos fuertes y dbiles, todas tienen en comn los siguientes
atributos:
Se ha de establecer de antemano el mbito del proyecto.

Como base para la realizacin de estimaciones, se usan las mtricas del software
(mediciones del pasado).
El proyecto se desglosa en partes ms pequeas que se estiman individualmente.
Muchos gestores aplican varias tcnicas diferentes de estimacin, utilizando unas para
verificar los resultados de las otras.
2.4. Anlisis de riesgos.

El anlisis de riesgos consiste realmente en una serie de pasos de control de los riesgos
que nos permiten combatirlos: identificacin de riesgos, clculo de riesgos, priorizacin de
riesgos, estrategias de control de riesgos, resolucin de riesgos y supervisin de riesgos.
2.5. Planificacin.
En realidad, la planificacin de un proyecto de software no difiere de la planificacin de
cualquier proyecto de ingeniera. Se identifica una serie de tareas del proyecto. Se establecen
interdependencias entre las tareas. Se estima el esfuerzo asociado con cada tarea. Se hace la
asignacin del personal y de otros recursos. Se crea una red de tareas. Se desarrolla una agenda
de fechas.
La planificacin temporal para proyectos de desarrollo de software puede verse desde

dos perspectivas bastante diferentes. En la primera, la fecha final de lanzamiento del sistema
basado en computadora ya ha sido (irrevocablemente) establecida. La organizacin del software
se ve forzada a distribuir el esfuerzo dentro del marco prescrito. El segundo enfoque de la
planificacin temporal del software asume que se han estudiado unos lmites cronolgicos
aproximados pero que la fecha final es fijada por la organizacin del software. El esfuerzo se
distribuye para hacer un mejor uso de los recursos y la fecha final se define despus de un
cuidadoso anlisis del elemento del software. Desafortunadamente al primera perspectiva se
encuentra bastante mas a menudo que la segunda.
2.6. Seguimiento.
Una vez que se haya planificado el proyecto, hay que seguir el proceso de desarrollo
para comprobar que se est cumpliendo el plan previsto: que satisface sus objetivos de
planificacin, coste y calidad. Normalmente el control del seguimiento en el nivel de gestin
incluye listas de tareas, reuniones e informes sobre el estado, revisiones de etapas, informes de
presupuesto y dems gestiones. El control de seguimiento en el nivel tcnico normalmente
incluye las intervenciones y revisiones tcnicas y las entradas de calidad, que controlan si las
etapas se consideran terminadas.
Figura 5
Como sugiere la figura 5, en un proyecto tpico la gestin del proyecto es casi una
funcin de caja negra. Difcilmente se conoce lo que se va a hacer durante el proyecto, y solo
hay que quedarse con el resultado final. En un proyecto ideal, en todo momento se tiene el 100
por 100 de visibilidad, siendo ms normal el tener una buena visibilidad que no tener ninguna.
El seguimiento es una actividad fundamental en el proceso de la planificacin software.

Si no se puede seguir un proyecto, no se puede gestionar. No hay forma de saber si el plan se
est llevando a cabo ni lo que se debera hacer despus. No hay forma de controlar los riesgos
en el proyecto. Un seguimiento efectivo permite detectar rpidamente los problemas de
planificacin, cuando an queda tiempo para poder resolverlos.
3. Introduccin al proceso de estimacin.

Ahora que hemos encuadrado el proceso de estimacin dentro de la gestin del
proyecto, pasamos a ver como se realiza realmente la estimacin. El proceso para crear una
planificacin de desarrollo exacta consta de tres pasos:
Estimar el tamao del producto (numero de lneas de cdigo o puntos de funcin).

Estimar el esfuerzo (personas-mes).
Estimar la planificacin (meses).
Estos tres pasos se pueden englobar dentro de un paso mas general, un metapaso:
Dar un intervalo de estimacin e ir refinando peridicamente ese intervalo, para ir

aumentando la precisin a medida que se avanza el proyecto.
Las secciones siguientes describen con detalle cada uno de estos pasos.
3.1. Estimacin del tamao.

Un concepto que se repetir numerosas veces a lo largo de este trabajo, es el de las
mtricas del software. Estas mtricas lo que intentan solucionar es el problema de determinar el
tamao de los programas. Este problema no es un mero ejercicio acadmico. La industria,
carente de buenos sistemas de calibracin de los programas, ha tenido dificultades para mejorar
la calidad de las aplicaciones informticas y el rendimiento de los programadores durante su
desarrollo. La verdad es que se tiene slo una idea nebulosa del calibre de los programas y de la
productividad de sus programadores. Por ello, la previsin de las inversiones en tiempo y en
dinero necesarias para la creacin de programas, ha llegado a ser tarea de tal dificultad, que los
retrasos y recargos constituyen no la excepcin, sino la regla. En opinin de Carpers Jones
(Jones, Carpers 1999) este problema fundamental (la medicin de los programas) supone uno de
los principales obstculos con que tropieza hoy la industria de los programas informticos.
La mtrica del software ms frecuentemente adoptada es la de las lneas de cdigo

(Low, Graham and Jeffery, Ross 1990). Aunque expresar el software en trminos de lneas de
cdigo tiene sus problemas como veremos a continuacin. El primer problema es saber
realmente que se entiende por lnea de cdigo. Existen 11 variantes de definiciones de este
concepto, separadas en dos grupos: a nivel de programa y a nivel de proyecto. Las variantes a
nivel de programas son:
Contar solo las lneas de cdigo ejecutable.

Lneas de cdigo ms definiciones de datos.

Lneas de cdigo, definiciones de datos y comentarios.
Lneas de cdigo, definiciones de datos, comentarios y lenguaje de control (Job Control
Languaje JCL).
Lneas de cdigo y lneas fsicas visualizadas en una pantalla.
Lneas de cdigo determinadas por delimitadores lgicos.
Las variantes a nivel de proyecto son:
Contar solo las lneas nuevas.

Contar lneas nuevas y lneas modificadas.
Contar lneas nuevas, lneas modificadas y lneas reutilizadas.
Contar todas las lneas del proyecto, mas cdigo temporal.
Contar todas las lneas del proyecto, cdigo temporal, y cdigo de soporte.
Las variantes a nivel de proyecto son importantes cuando no es nuevo todo el cdigo.
Un ejemplo sera el aadir funcionalidad extra a un programa existente.
La definicin de lneas de cdigo que se adopta en cualquier organizacin particular

depende de donde vaya a ser utilizado el software. Por ejemplo podra ser mas adecuado utilizar
la variante a nivel de proyecto Contar lneas nuevas en lugar de Contar todas las lneas del
proyecto, cdigo temporal, y cdigo de soporte en una estimacin a priori del esfuerzo de
aadir nueva funcionalidad al programa. Habiendo decidido que la variante a nivel de proyecto
se adoptar, el analista debe decidir tambin que variante a nivel de programa se ha de tener en
cuenta.
Figura 6
La estimacin a posteriori del tamao del sistema utilizando lneas de cdigo, debera
ser totalmente consistente, debido a que solo puede haber una respuesta, ya que la definicin de
lneas de cdigo no cambia. Sin embargo una estimacin a priori del esfuerzo necesario para el
desarrollo del sistema, requiere una estimacin del tamao del sistema, que se ha de realizar en
las etapas iniciales del ciclo de vida del proyecto: especificacin de requerimientos o
especificacin de diseo (figura 6). Esta estimacin a priori del tamao del sistema, est
normalmente basada en la experiencia pasada, con proyectos similares, de la persona que est
realizando la estimacin.
Otra dificultad con las lneas de cdigo como una mtrica del tamao del sistema es la
dependencia del lenguaje. Consecuentemente no es posible comparar directamente la
productividad de proyectos realizados en diferentes lenguajes, usando lneas de cdigo como
medida del tamao del sistema.
A.J. Albrecht (Albrecht, Allan and Gaffney, John 1983) introdujo el concepto de puntos
de funcin en 1979 para medir la funcionalidad proporcionada por el software. Los puntos de
funcin pueden ser determinados a partir de la especificacin de requerimientos y la
especificacin del diseo. Como los puntos de funcin son una medida de la funcionalidad,
deben ser independientes de la tecnologa y lenguaje utilizado para la implementacin de
software. La posibilidad de determinar los puntos de funcin a priori, y su independencia de la
tecnologa y el lenguaje, cubren dos de las principales objeciones inherentes a las lneas de
cdigo como medida del tamao del sistema.
3.1.1. Metodologa de los puntos de funcin.

Un punto de funcin es una medida sinttica cuyo valor se determina por medio de los
elementos siguientes:
Entradas: Pantallas, formularios, cuadros de dialogo, controles o mensajes, a travs

de los cuales un usuario final o cualquier otro programa pueda aadir, borrar o
cambiar datos de un programa.
Salidas: Pantallas, informes, grficos o mensajes que el programa genera para el
usuario final o cualquier otro programa. Esto incluye cualquier salida que tenga
formato diferente o requiera un procesamiento diferente a otros tipos de salida.
Consultas: Una consulta est definida como una entrada interactiva que resulta de la
generacin de algn tipo de respuesta en forma de salida interactiva.
Archivos lgicos internos: Los principales grupos lgicos de datos de usuarios
finales o informacin de control que estn completamente controlados por el
programa. Un archivo lgico podra constar de un nico archivo plano o de una sola
tabla en una base de datos relacional.
Archivos de interfaz externos: Archivos controlados por otros programas, con los
que el programa va a interactuar. Esto incluye cada uno de los principales grupos
de datos lgicos o informacin de control que entre o salga en el programa.
Archivo Externo:
1. Documento que se
ha de revisar
Entrada:
1. Nombre del documento
que se ha de revisar
Consulta:
1. Cuantas palabras
llevamos procesadas Comprobador
Usuario
Ortogrfico
Archivo Interno:
Salida: 1. Diccionario
1. Numero total de palabras revisadas
2. Numero total de errores detectados
3. Lista de palabras con errores ortogrficos
Figura 7.
En la Figura 7 tenemos una representacin de un sencillo programa de revisin

ortogrfica. El sistema tiene una entrada (el nombre del archivo que ha de revisarse), tres salidas
(el nmero total de palabras revisadas, el nmero total de errores y una lista de las palabras
errneamente escritas), una consulta (el usuario puede obtener interactivamente el nmero de
palabras procesadas hasta el momento), un archivo externo (el documento a inspeccionar y un
archivo interno (el diccionario). Para este sencillo programa, el nmero de elementos es
1+3+1+1+1=7.
En la prctica el anlisis mediante puntos funcionales resulta ser mucho ms

complicado que el mero recuento de los cinco tipos de atributos. Al aplicar este mtodo se han
de introducir diversas ponderaciones que toman en cuenta la complejidad (reducida, normal o
elevada) de cada elemento. En la tabla 1 puede observarse como afecta la complejidad al valor
de los atributos. En ella se indica el factor multiplicativo que hay que aplicar al valor obtenido
de cada atributo.
Atributo Complejidad Complejidad Complejidad

Reducida Media Alta
Entradas 3 4 6
Salidas 4 5 7
Consultas 3 6 6
Archivos Internos 7 10 15
Archivos Externos 5 7 10
Tabla 1
A fin de hacer menos subjetiva la evaluacin de la complejidad, Albrecht desarroll una

matriz para cada tipo de atributo, que determina el grado de complejidad en funcin de los datos
del software a desarrollar y de los archivos referenciados por el mismo. Por ejemplo la Tabla 2
muestra una matriz con la complejidad de las entradas externas.
Archivos Datos
referenciados
1-4 5-15 >=16
0-1 Reducida Reducida Normal
2 Reducida Media Elevada
>=3 Normal Elevada Elevada
Tabla 2
Albrecht y Gaffney (Albretcht, Allan and Gaffney,John 1983) describen los tipos de
complejidad para entradas externas como sigue:
Reducida: Se incluyen pocos tipos de elementos de datos, en las entradas externas, y se

referencian pocos archivos lgicos internos.
Normal: Cuando las entradas externas no son ni simples ni complejas.
Elevada: Se incluyen muchos tipos de elementos de datos, en las entradas externas, y se
referencian muchos archivos lgicos internos.
Archivos Datos
referenciados
1-4 5-15 >=16
Tabla 3
El factor de ajuste de complejidad para salidas externas se muestra en la Tabla 3 y es
bastante similar a la Tabla 2. La descripcin de los tipos de complejidad para salidas es
exactamente igual que para entradas. A excepcin de cuando tratamos como informes (reports)
que se han de aadir las siguientes definiciones:
Reducida: Informes de una o dos columnas. Pocas transformaciones entre datos.
Normal: Informes con mltiples de columnas con subtotales. Mltiples
transformaciones de datos.
Elevada: Intrincadas transformaciones de datos. Se hacen referencias a archivos
mltiples y complejos.
En la tabla 4 tenemos representado el factor de ajuste de complejidad para archivos

internos.
Archivos Datos
referenciados
1-4 6-19 >=20
2-3 Reducida Media Elevada
Tabla 4
La definicin de los tres tipos de complejidad se muestra a continuacin:
Reducida: Pocos registros y pocos elementos de datos.

Normal: Simplemente cuando no es reducida ni compleja.
Elevada: Muchos registros y muchos elementos de datos.
Archivos Datos
referenciados
1-4 5-15 >=16
Tabla 5
La Tabla 5 muestra los factores de ajuste para interfaces externas:
La definicin de los tipos de complejidad es, en este caso, igual que en el anterior
(archivos lgicos internos).
Archivos Datos
referenciados
1-4 5-15 >=16
Tabla 6
El ltimo atributo que se ha de ajustar son las consultas. Este atributos es similar a los
dems pero lo hemos dividido en dos subelementos (Tabla 6 y Tabla7) las consultas de entrada
y las consultas de salida.
Archivos Datos
referenciados
1-4 5-15 >=16
Tabla 7
La definicin de complejidades, para consultas de entrada es similar a la que se haca

con las entradas, lo mismo sucede con las consultas de salidas con las salidas.
Los 14 factores de influencia.

Por ltimo, el total de puntos funcionales se incrementa o decrece mediante un

coeficiente multiplicador, comprendido en el intervalo [0,65-1,35], a fin de ajustar la evaluacin
subjetiva de la dificultad del sistema. Este ajuste se fundamenta en 14 factores denominados
factores de influencia para ajuste de la complejidad. Los factores de influencia son evaluados
del 0 al 5, de tal modo que una puntuacin de 0, indica que el factor no tiene influencia en
absoluto en la aplicacin y una puntuacin de 5 indica que la influencia en el sistema es total.
Tambin esta permitido el uso de valores decimales como 2,5. A continuacin se enumeran los
14 factores y se indica un ejemplo de alta puntuacin en cada caso:
1. Comunicaciones de datos: Este factor es concerniente a la transmisin de datos o

informacin de control, enviados o recibidos mediante algn sistema de comunicaciones.
Ejemplo: Un programa para un banco multinacional que ha de gestionar transferencias
monetarias electrnicas desde instituciones financieras de todo el mundo.
2. Procesamiento distribuido: El procesamiento distribuido es concerniente a si una
aplicacin es monoltica y se ejecuta en un nico procesador, o si la aplicacin consiste en
cdigo independiente ejecutndose en procesadores distintos y persiguiendo un fin comn.
Ejemplo: Un motor de bsqueda en el Web, donde el procesamiento corre a cargo de ms de
una docena de ordenadores servidores que operan en grupo.
3. Objetivos de rendimiento: Los objetivos de rendimiento tendrn una puntuacin de 0 si el
rendimiento de la aplicacin no es relevante, por el contrario la puntuacin ser 5 si es un
factor crtico. Ejemplo: Un sistema de trfico areo encargado de facilitar en todo instante
las posiciones exactas de los aviones a partir de datos obtenidos por radar.
4. Configuracin de uso intensivo: Indica si el sistema se va a utilizar en un entorno
operativo que est siendo utilizado de manera intensa. Ejemplo: Un sistema para un campus
universitario, en el que centenares de estudiantes realizan consultas simultneamente.
5. Tasas de transaccin rpidas: Tendr una puntuacin de 5 si el volumen de transacciones
es suficientemente alto como para requerir un esfuerzo de desarrollo especial, para
conseguir la productividad deseada. Ejemplo: Un programa bancario que ha de realizar
millones de transacciones en horario nocturno para cerrar todos los libros del da laborable
siguiente.
6. Entrada de datos en lnea: Este factor tendra una puntuacin de 0 si son interactivas
menos del 15 por ciento de las transacciones, y tendr una puntuacin de 5 si ms del 50 por
ciento de las transacciones son interactivas. Ejemplo: Un programa de aceptacin de
prstamos hipotecarios, en el que los funcionarios introducen interactivamente en un
sistema informtico datos extrados de formularios impresos cubiertos por los solicitantes
de prstamos.
7. Amigabilidad en el diseo: Determina si las entradas de datos interactivas requieren que
las transacciones de entrada se lleven a cabo sobre mltiples pantallas o variadas
operaciones. Ejemplo: Programas para puntos de informacin y venta de billetes de metro
dotados de pantalla tctil; en ellos los viajeros abonan el importe con tarjetas de crdito.
8. Actualizacin de datos en lnea: Este factor tendr puntuacin mxima si las
actualizaciones en lnea son obligatorias y especialmente dificultosas, quiz debido a la
necesidad de realizar copias de seguridad, o de proteger los datos contra cambios
accidentales. Ejemplo: Sistema para lneas areas, en el cual las agencias de viajes pueden
efectuar reservas de plaza o adquirir billetes. El programa ha de poder bloquear y despus
modificar ciertos registros, para evitar que una misma plaza se venda dos veces.
9. Procesamiento complejo: Este factor se puntuar con 5 si se requieren gran cantidad de
decisiones lgicas, complicados procedimientos matemticos o difcil manejo de
excepciones. Ejemplo: Programas de uso mdico, que a partir de un conjunto de sntomas
de un paciente efectan una amplia serie de decisiones lgicas para llegar a un diagnstico
preliminar.
10. Reusabilidad: Indica si gran parte de la funcionalidad del proyecto, est pensada para un
uso intensivo por otras aplicaciones. Ejemplo: un procesador de textos diseado de modo
que las barras de herramientas de sus mens puedan incorporarse en otras aplicaciones,
como hojas de clculo o generadores de informes.
11. Facilidad de instalacin: Un valor de 5 denota que la instalacin del sistema es tan
importante, que requiere un esfuerzo especial el desarrollar el software necesario para
realizarla. Ejemplo: Una aplicacin para control de equipos, que pueda ser instalada por
personal no especializado en una plataforma petrolfera en el mar.
12. Facilidad operacional: Un valor de 5 indica que el sistema realiza pocas operaciones.
Ejemplo: Un programa para el anlisis de enormes nmeros de registros financieros que ha
de procesar la informacin de modo que se minimice el nmero de veces que los operadores
de los computadores deban descargar y recargar las cintas donde se guardan los datos.
13. Multiplicidad de emplazamientos: Una puntuacin mxima indicara que el sistema se ha
diseado para soportar mltiples instalaciones en diferentes organizaciones. Ejemplo:
Programa de nminas para una empresa multinacional, que ha de tomar en cuenta las
diferentes caractersticas de los pases, con diversidad de monedas y normativas en el
impuesto sobre la renta.
14. Versatilidad: Determina si la aplicacin se ha realizado para facilitar los cambios y para ser
utilizada por el usuario. Ejemplo: Un programa de previsin financiera capaz de efectuar
pronsticos mensuales, trimestrales o anuales a la medida de un determinado gestor, quien
podra necesitar que la informacin estuviera dividida segn regiones geogrficas o lneas
de productos.
Uso de los 14 factores de influencia.

Cuando se han considerado los 14 factores de influencia, y se les han asignado
puntuaciones individualmente, la suma de estos factores es convertida en un ajuste de la
complejidad final siguiendo el procedimiento siguiente:
Multiplicar la suma de los factores por 0,01, para convertir la suma en un valor decimal.
Sumar la constante 0,65 al valor decimal para crear un factor multiplicador de la
complejidad.
Multiplicar el valor no ajustado del total de los puntos de funcin por el multiplicador
de la complejidad, para conseguir un valor de puntos de funcin ajustado.
Se puede observar que los 14 factores de influencia producen un multiplicador que tiene un
rango de 0,65 a 1,35. Si ninguno de los factores tiene influencia sobre el sistema, la suma de sus
puntuaciones ser 0, y solo se usar la constante 0,65 como multiplicador. Si los 14 factores
tienen la mxima influencia sobre el sistema, su suma ha de ser 70. Usando el procedimiento
anterior tenemos 70*0,01+0,65=1,35, luego el valor mximo del multiplicador es 1,35.
A continuacin veremos un ejemplo de esta secuencia de clculo. Suponemos un proyecto

medio con 10 entradas, 10 salidas, 10 consultas, 1 archivo de datos y 1 interface. Asumimos una
complejidad media para estos factores. En la tabla 8 tenemos representado el numero total de
puntos de funcin desajustado, y en la tabla 9 los factores de influencia.
Conteo Elementos Peso Resultado

10 Entradas x 4 = 40
10 Salidas x 5 = 50
10 Consultas x 4 = 40
1 Archivos Lgicos x 10 = 10
1 Archivos de Interfaz x 7 = 7
Total 147
Tabla 8.
Factor de Influencia Puntuacin

Comunicaciones de datos 0
Procesamiento distribuido 0
Objetivos de rendimiento 4
Configuracin de uso intensivo 3
Tasas de transaccin rpidas 3
Entrada de datos en lnea 4
Amigabilidad en el diseo 4
Actualizacin de datos en lnea 2
Procesamiento complejo 3
Reusabilidad 0
Facilidad de instalacin 4
Facilidad operacional 4
Multiplicidad de emplazamientos 5
Versatilidad 4
Tabla 9
La suma de los factores de influencia es 40, tendremos entonces un valor para el factor
de ajuste de la complejidad de:
40*0,01=0,40+0,65=1,05
y el valor final de los puntos de funcin ajustados ser:
147*1,05=154
3.2. Estimacin del esfuerzo.

Hablar de estimacin de esfuerzo viene a ser lo mismo que hablar de estimacin de
coste, pues este ltimo est ntimamente relacionado con el esfuerzo necesario para realizar el
proyecto. El esfuerzo es la magnitud de coste de elaboracin de un proyecto, y se expresa
mediante unidades tales como personas-mes o personas-ao.
Al principio, el coste del software constitua un pequeo porcentaje del coste total de los
sistemas informticos basados en computador. Un error considerable en las estimaciones del
coste del software tena relativamente poco impacto. Hoy en da, el software es el elemento ms
caro de la mayora de los sistemas informticos. Un gran error en la estimacin del coste puede
ser lo que marque la diferencia entre beneficios y prdidas. Por ejemplo si el esfuerzo es
subestimado, un coste superior al previsto puede hacer que los beneficios obtenidos sean nulos
o negativos, y una prolongacin excesiva en el tiempo de entrega puede hacer que se pierdan
futuros clientes. Sobrestimar el esfuerzo puede tambin afectar a la competitividad de la
compaa as como provocar perdida de beneficios, por ejemplo podra contratarse personal en
exceso para la realizacin del proyecto.
Lo comn de las imprecisiones en la estimacin de esfuerzo y las consecuencias de

estas imprecisiones, son las que motivan los continuos trabajos de investigacin en mtodos y
modelos para el software de estimacin de costes.
Fiona Walkerden y Ross Jeffery (Walkerden, Fiona and Jeffery, Ross 1996) destacan
tres puntos principales a tratar dentro de la estimacin del esfuerzo: proceso de prediccin,
marco de trabajo para seleccionar magnitudes de prediccin, y mtodos.
El proceso de prediccin y el marco de trabajo de seleccin, destacan la importancia de

las mtricas, puesto que ellas proporcionan los datos en los cuales se fundamentan las
predicciones. El proceso de prediccin y el marco de trabajo de seleccin tambin enfatizan la
necesidad de empaquetar o reutilizar experiencia a fin de mejorar la precisin de la estimacin.
3.2.1. Proceso de prediccin.

Un proceso para realizar predicciones y mejorar su precisin debe incluir tres
actividades: seleccionar y modelar las magnitudes a predecir, realizar las predicciones y evaluar
la precisin de estas predicciones. La inclusin de las dos primeras actividades es evidente. La
evaluacin es necesaria a fin de mejorar el ajuste de las predicciones realizadas. La evaluacin
proporciona una realimentacin dentro del proceso. Sin realimentacin, no sera posible
aprender de la experiencia, y no se estableceran las bases para mejorar futuras predicciones.
Se puede establecer un paralelismo entre el proceso de prediccin y el paradigma de

mejora de calidad QIP(Quality Improvement Paradigm). Ambos seleccionan mtricas, realizan
medidas, analizan los datos obtenidos y aprenden de la experiencia. El proceso de prediccin se
puede ver como una especializacin de QIP, el cual se centra en la realizacin de predicciones
acerca de procesos y productos, para posteriormente ajustarlas todo lo posible. La Tabla 10
muestra los seis pasos del QIP, junto a sus equivalentes en el proceso de prediccin.
QIP Proceso de Prediccin

1. Caracterizar el proyecto en curso y su Caracterizar el proyecto en curso y su entorno
entorno, con respecto a modelos y mtricas con respecto a las restricciones y metas
establecidas para el.
2. Establecer metas cuantificables para Seleccionar la mtricas predictivas y mtodos
conseguir un rendimiento ptimo y por los que evaluar si el proyecto puede
perfeccionamiento conseguir satisfacer restricciones y metas
3. Elegir los modelos de procesos adecuados y Planificar la cantidad de datos necesarios para
soportar los mtodos y herramientas para este soportar el proceso de prediccin.
proyecto.
4. Ejecutar el proceso, construir el producto, Realizar las predicciones y documentar la
recolectar y validar datos prescritos, y suposicin en la cual est basado. Valorar la
analizarlos para proporcionar realimentacin precisin de las predicciones, para
en tiempo real para corregir la accin. proporcionar una realimentacin en tiempo
real para acciones correctivas, y para realizar
nuevas predicciones basadas en ello.
4. Analizar los datos para evaluar el proyecto, Evaluar las mtricas predictivas, analizando los
determinar problemas, registrarlos y realizar datos recolectados. Determinar las causas de la
recomendaciones para mejoras a futuros imprecisiones y realizar recomendaciones para
proyectos el futuro.
5. Almacenar la experiencia en el formulario Almacenar la experiencia como en QIP.
de modelos modificados y mejorados, y otros
formularios de conocimientos estructurados,
obtenidos de este y de proyectos previos, y
guardarlos en una base de datos.
Tabla 10
El proceso de prediccin se indicar mas adelante, paso a paso. Se utiliza un escenario

de un sistema de desarrollo, a fin de proporcionar ejemplos en cada paso. Los ejemplos
utilizados son representativos de las clases de predicciones y mtricas utilizadas en un escenario
real.
Nuestro escenario es el siguiente: reemplazar y modificar el sistema de una

organizacin que proporciona un servicio pblico de informacin. El sistema ha de ser
reemplazado debido al aumento del nmero usuarios que solicitan este servicio. Se ha
pronosticado que dentro de 18 meses no ser posible cubrir la demanda. El nuevo sistema debe
soportar las funciones del servicio existente, mas algunas mejoras.
Caracterizar el proyecto.
El primer paso en el proceso de prediccin consiste en obtener informacin acerca del
proyecto y de su entorno, la cual es relevante para determinar las restricciones y objetivos del
proyecto. El tipo de informacin obtenida es la misma que se obtendra en el primer paso de
QIP.
Mientras que se oferta el contrato, la compaa que realizar el proyecto en nuestro

escenario, debe comprender las necesidades de su cliente, y convertirlas en objetivos del nuevo
sistema. Tanto el rendimiento del sistema nuevo, como las fechas de entrega son importantes
desde el punto de vista del cliente. Establecer el importe econmico del proyecto correctamente,
es importante desde el punto de vista de la compaa.
Seleccionar las mtricas y mtodos.

El segundo paso en el proceso de prediccin es seleccionar las mtricas a predecir para
el proyecto y los mtodos mediante los que realizaremos esa prediccin. Este paso es similar al
segundo paso de QIP, el cual consiste en seleccionar las mtricas mediante las que evaluar si se
ha encontrado el modo de perfeccionar el proyecto. Las mtricas a predecir deben reflejar las
restricciones y objetivos del proyecto, a fin de evaluar si pueden ser satisfechas.
En nuestro escenario del nuevo sistema debe ser operativo antes que el sistema viejo sea
incapaz de cubrir la demanda de los usuarios. Los pronsticos referentes a la demanda de
usuarios establecen la fecha de entrega del proyecto. Desde la perspectiva del cliente es mas
importante reemplazar del sistema viejo que aadir mejoras. En esta situacin, una mtrica
apropiada para predecir sera aquella que indicara cuanta funcionalidad puede estar realizada y
testeada para una fecha particular. Esta prediccin puede ser utilizada para negociar con el
cliente acerca de un subconjunto de funcionalidad en la que concentrarse para una entrega
inicial, si es que el sistema completo no puede ser realizado en la fecha de entrega.
Los puntos de funcin han sido utilizados como mtricas de funcionalidad, y se han
desarrollado modelos que relacionan el esfuerzo de desarrollo con los puntos de funcin
(Albrecht, Allan and Gaffney, John 1983). Es posible predecir el numero de puntos de funcin
que se pueden desarrollar hasta la fecha de entrega. Los puntos de funcin para el sistema
completo pueden ser contados a partir de las especificaciones del sistema.
El mtodo mediante el que predecir la mtrica tambin ha de ser seleccionado. Un

modelo de regresin que relacione el esfuerzo con los puntos de funcin se puede usar en modo
inverso para predecir los puntos de funcin, siempre que se tengan suficientes datos disponibles
acerca de proyectos similares previamente realizados. No obstante la compaa de nuestro
escenario ha desarrollado nicamente un sistema similar al sistema nuevo. En esta situacin, la
prediccin se basara en una analoga con este sistema.
Planificar la magnitud y recoleccin de datos.

El tercer paso en el proceso de prediccin planifica como medir y recolectar los datos
necesarios para analizar la precisin de las predicciones y los datos necesarios para construir
nuevas predicciones o revisar las ya realizadas. El plan desarrollado en este paso no difiere con
el que se realizara en un proceso QIP. Este plan se ejecuta durante el desarrollo del sistema.
En nuestro escenario, esfuerzo y puntos de funcin son ejemplos de los datos a ser
medidos y recolectados durante el desarrollo del sistema. El esfuerzo realizado en el desarrollo
necesitara ser medido a fin de evaluar se la suposicin original acerca de la mano de obra fue
valida. Es necesario que sean medidos los puntos de funcin regularmente durante el desarrollo
de sistema a fin de detectar incrementos de los mismos, lo cual podra retrasar sensiblemente la
fecha de entrega.
Si una prediccin puede venir condicionada por una decisin no procedente del
desarrollo del sistema, tal como sera un estudio de factibilidad, este paso ha de ser aplazado
hasta despus de que la prediccin sea realizada y la consecuente decisin sea tomada.
Realizar las predicciones y evaluar su precisin.

En el cuarto paso del proceso, se realizan las predicciones. Segn los datos van estando
disponibles, las predicciones son analizadas para evaluar si estn siendo cumplidas o no. Los
resultados de este anlisis son realimentados tanto al desarrollo del sistema como a la
realizacin de las predicciones. Esta realimentacin proporciona a los desarrolladores la
oportunidad de tomar acciones correctivas, si ello es procedente, y permite la revisin de las
predicciones basndose en los datos nuevos.
El cuarto paso del proceso de prediccin es anlogo al el cuarto paso de QIP, donde los
datos son recolectados y analizados para evaluar y proporcionar una realimentacin sobre si el
perfeccionamiento de metas esta siendo cumplido o no durante el desarrollo del sistema.
En nuestro escenario de prediccin, si se observa que el nmero de puntos de funcin se

est incrementando en cada medida, se pueden investigar las razones y controlar el crecimiento.
La fecha de entrega puede ser tambin revisada, y nuevamente predicha, en base a las nuevas
medidas.
Algunas predicciones pueden requerir datos que aun no estn disponibles antes del
desarrollo del sistema, por esto se harn nuevas predicciones como si fueran estimaciones
revisadas durante el desarrollo del proyecto. Por ejemplo, el esfuerzo requerido para testear la
integracin del sistema, puede ser predicho basndonos en medidas de los atributos de diseo
del sistema, cuando la documentacin del diseo est disponible.
Analizar las medidas y mtodos.
El quinto paso del proceso de prediccin consiste en la evaluacin de mtricas y

mtodos usados para hacer las predicciones. Este paso es necesario para aprender de la
experiencia. Las razones por las que las predicciones son imprecisas, han de ser comprendidas y
buscadas las soluciones. Estas soluciones deberan acompaarse de sugerencias para mejorar la
precisin de la seguridad de predicciones futuras.
Para nuestro escenario ejemplo, se han de explorar las razones de la imprecisin en la

fecha de entrega. Si una de las razones de la imprecisin en al prediccin de la fecha de entrega
era el crecimiento de los requerimientos durante el desarrollo, se podra hacer una
recomendacin para que en futuros proyectos se tuviera en cuenta el crecimiento de los
requerimientos. Este paso es equivalente al quinto paso de QIP, donde la experiencia es
adquirida analizando los datos recolectados durante el desarrollo del sistema.
Almacenar la experiencia.
El sexto y ltimo paso implica el guardar la experiencia adquirida a fin de que sea usado
por la organizacin en el futuro. Este paso es el mismo que el paso final de QIP. Esto es
especialmente pertinente en un proceso de prediccin, ya que las predicciones precisas solo
pueden ser esperadas cuando hay experiencia previa. Las predicciones hechas sin referencia a
experiencia previa sern poco menos que conjeturadas.
3.2.2. Marco de trabajo.

El segundo paso en el proceso de prediccin es un subproceso, que selecciona que
predecir y como. El marco de trabajo para seleccionar mtricas predictivas y mtodos,
proporciona un modelo para usar en este proceso de seleccin. Las mtricas definen que es lo
que se va a predecir y los mtodos definen como una mtrica es predicha.
El marco de trabajo ocupa un lugar equivalente en el proceso de prediccin, al que

ocupa el paradigma Objetivo/Cuestin/Mtrica (Goal/Question/Metric GQM) en QIP. GQM
puede usarse cuando se inicia un programa de mtricas dentro de una organizacin. GQM
captura objetivos de organizacin y proyectos, y desarrolla medidas mediante las que el
progreso con respecto a esos objetivos puede ser evaluado.
Donde GQM proporciona un detallado proceso para definir objetivos medibles, el

marco de trabajo para seleccin de mtricas predictivas y mtodos es descriptivo. El marco de
trabajo caracteriza mtricas predictivas y mtodos, y describe los factores que influyen en la
seleccin y por que. El marco de trabajo no describe el proceso por el cual hacer la seleccin.
Figura 8
Los factores que influyen en la seleccin de medidas predictivas y mtodos son:
El propsito de la prediccin.
El punto de vista de quienes usan la prediccin.
El tiempo en el cual la prediccin es realizada.
El entorno dentro del que se realiza la prediccin.
La experiencia mediante la que podemos hacer la prediccin (Figura 8).
Medidas predictivas.
Una medida es una representacin numrica de un atributo especfico o entidad. Las
medidas para el desarrollo de un sistema representa atributos de entradas de un proceso, de
salidas o del proceso en si. Por ejemplo, el numero de requerimientos es una medida de la
longitud de entrada al proceso de desarrollo del sistema, el numero de lneas de cdigo es una
medida de la longitud de salida y del numero de horas gastadas desarrollando el cdigo, es una
medida del esfuerzo en el proceso de implementacin.
Las medidas pueden ser clasificadas como directas o indirectas. El numero de lneas de
cdigo producidas es un ejemplo de medida directa. Su valor puede ser determinado aplicando
las mtricas directamente al producto de inters. Las medidas indirectas consisten en medir uno
o varios atributos. Medidas de productividad, tales como las lneas de cdigo por persona al da,
son ejemplos de medidas indirectas. Una medida del esfuerzo de desarrollo que se calcula desde
una medida del tamao, tal como las lneas de cdigo, es otro ejemplo de medidas indirectas.
Esta mtrica est basada en una relacin emprica entre dos atributos: esfuerzo y tamao del
software producido. Esta relacin numrica se formaliza mediante un modelo numrico.
La produccin esta normalmente basada en medidas indirectas, pues el atributo de

inters no es mensurable directamente en el tiempo en que la prediccin est siendo realizada.
Por ejemplo, el esfuerzo para implementar el software puede ser predicho usando un modelo
que relacione este esfuerzo con un atributo de diseo del sistema, tal como las lneas de cdigo
o los puntos de funcin. El numero de horas empleadas hasta el momento actual del desarrollo
pueden ser medidas directamente. Esto nos permite que la prediccin del esfuerzo realizada
indirectamente, sea comparada con la realizada directamente y de este modo valoremos la
precisin de la prediccin.
Cuando se definen medidas indirectas predictivas, es preferible utilizar modelos que

dependan de atributos medidos directamente, a modelos en los que los atributos de partida sean
tambin predichos. Por ejemplo, si el esfuerzo para implementar el software es predicho a partir
del tamao del software, se har necesaria tambin una prediccin del tamao. Es preferible ser
capaz de medir directamente todas la entradas al modelo de prediccin ya que algunos modelos
amplifican la incertidumbre en sus valores de entrada. Los modelos de regresin de esfuerzo y
lneas de cdigo muestran tpicamente altas correlaciones.
Mtodos predictivos.
El marco de trabajo identifica cuatro clases de mtodos de prediccin:
Empricos.
Analgicos.
Tericos.
Heursticos.
Cualquier prediccin se debe basar en un modelo emprico, que relacione el atributo de

inters con otros atributos mensurables. Este modelo emprico es el punto de partida para cada
mtodo de prediccin.
Los mtodos empricos analizan datos para establecer un modelo numrico del
relacionante entre medidas de los atributos dentro del modelo emprico. El anlisis de regresin
es un ejemplo de mtodo emprico.
Los mtodos de prediccin analgicos, o por analoga, utilizan medidas de los atributos
del modelo emprico a fin de caracterizar el caso actual, para el que se realiza la prediccin. Las
medidas conocidas para el caso actual son usadas para buscar un conjunto de datos que
identifiquen casos anlogos. La prediccin se hace interpolando desde uno o varios casos
anlogos al caso actual.
Los mtodos de prediccin tericos proponen un modelo numrico basado en el modelo

emprico. Los modelos tericos deben ser validados empricamente, por comparacin con los
datos actuales de las medidas.
Los mtodos heursticos suelen usarse como extensiones de otros mtodos. Las
heursticas son reglas empricas, desarrolladas mediante experiencia, que obtienen conocimiento
acerca de relacionantes entre atributos del modelo emprico. Las heursticas se pueden utilizar
para ajustar predicciones realizadas con otros mtodos.
Las opiniones de los expertos se reconocen tambin como mtodos de prediccin (por
ejemplo Boehm,1981). Las opiniones de los expertos no se incluyen dentro del marco de trabajo
para seleccionar mtodos de prediccin, ya que estos mtodos no se pueden caracterizar
fcilmente.
Propsito de la prediccin.
El propsito para el que se requiere una prediccin es el principal motivo por el que se
predicen las medidas. Algunos ejemplos de estos propsitos son:
Investigacin de la factibilidad del desarrollo o compra de un sistema nuevo.

Investigacin del impacto del cambio en la funcionalidad de un sistema existente.
Determinacin del personal de soporte necesario, para del desarrollo del proyecto.
Cuantificar el coste econmico del sistema nuevo.
El propsito de una prediccin tiene la mayor influencia sobre las decisiones tomadas
en base a los atributos del sistema, que determinan los tipos de medidas apropiadas. Las
medidas a predecir se pueden evidenciar a partir del propsito. En el escenario del sistema, del
que hablamos en la seccin anterior, la compaa ha de preparar un presupuesto. La mtrica
obvia es el coste del sistema. Este coste puede ser dividido entre software y hardware. El coste
hardware incluye el coste del servidor sobre el que reside la base de datos necesaria para el
servicio de informacin, y el coste del hardware cliente mas perifricos. Antes de solicitar un
presupuesto para el servidor, el equipo contable de la compaa, ha de predecir la capacidad del
almacenamiento requerida, el ancho de banda de los interfaces de comunicaciones, y la
capacidad de procesamiento requerida para manejar la demanda de los usuarios. Partiendo de
una mtrica inicial del coste total, el nmero de medidas que han de ser predichas crece segn se
descompone el problema.
El propsito puede tambin indicar lo rpidamente que es necesario tener una

prediccin, y el grado de certeza necesario en esta. Este factor de tiempo de obtencin de la
prediccin influye en la eleccin del mtodo de prediccin. Por ejemplo, puede ser necesario
preparar rpidamente un presupuesto. Si el equipo contable tiene acceso a un modelo numrico

desarrollado para sistemas similares, podra ser usado rpidamente para elaborar la oferta. Si no
existen estos modelos, la prediccin se realizar por analoga con sistemas similares, de este
modo se consume menos tiempo que desarrollando modelos numricos.
En nuestro escenario, el equipo contable elige predecir la potencia de procesamiento en

proporcin a la potencia de procesamiento de sistemas similares. Se conocen los picos de carga
en transacciones por segundo que es capaz de manejar el sistema similar. A partir de las
especificaciones del cliente se estima el numero de transacciones por segundo, las cuales deben
ser manejadas por el nuevo sistema, y se ha de aplicar una heurstica para convertir estas
transacciones en transacciones sobre la base de datos. Se calcula que la proporcin de estas
transacciones es 1,5. Con estos datos se podra solicitar al vendedor de hardware que preparase
un presupuesto para una mquina que sea un 50% ms potente en procesamiento que la mquina
usada en el sistema similar.
La necesidad de cuantificar la incertidumbre en una prediccin tambin influye en la

eleccin del mtodo de prediccin. La incertidumbre que puede tolerarse en el coste puede ser
determinado por la poltica de la compaa sobre mrgenes de contingencia y si el coste ha de
ser competitivo o no. La estimacin de la incertidumbre en una prediccin puede ser dificultosa,
si la prediccin se hace por analoga. En el ejemplo, la incertidumbre en la prediccin de la
capacidad de procesamiento requerida dependera de una estimacin de la incertidumbre en la
prediccin de las transacciones requeridas sobre la base de datos. De este modo una
cuantificacin a partir de las especificaciones preliminares, dependiendo de una heurstica,
resulta dificultosa. Si se ha desarrollado un modelo numrico a partir de las mtricas
disponibles, puede ser utilizado para estimar el valor lmite de transacciones requeridas.
Punto de vista.
El punto de vista de la persona o las personas que usarn la prediccin, tambin influye
en las medidas que han de ser predichas. A continuacin se indican las personas que podran
usar las predicciones para desarrollar el sistema:
Clientes.
Equipo contable.
Gestores del proyecto.
Desarrolladores de software.
El punto de vista, tal como el propsito, contribuye a las decisiones acerca de los
atributos del sistema susceptibles de ser medidos. Por ejemplo, el cliente que ha solicitado un
nuevo sistema y el gestor del proyecto, estn ambos interesados en cuanto tiempo tardar en
estar disponible el sistema completo para su utilizacin. El gestor del proyecto y los
desarrolladores de software estn ambos interesados en cuanto tiempo llevar la realizacin de
las tareas individuales del sistema.
El punto de vista tambin influye en la precisin con la cual una precisin necesita ser
realizada. La necesidad de una gran precisin puede influir en la seleccin de tanto la mtrica
como del mtodo. Por ejemplo, el equipo de contabilidad y los desarrolladores ven la seleccin
del sistema hardware de modo distinto. El equipo de contabilidad est interesado en realizar una
prediccin rpida de la capacidad del sistema, en orden de seleccionar el sistema hardware y
conocer su coste. Una vez que el contrato ha sido adjudicado, los desarrolladores estarn
restringidos por el coste del hardware, y por los requerimientos del sistema. Antes de realizar la
adquisicin del hardware, los desarrolladores necesitan establecer con certeza que el hardware
seleccionado es adecuado para satisfacer la demanda de los usuarios.
Para la preparacin del presupuesto, la capacidad del sistema se estim por analoga con
otro sistema similar, y las mtricas as obtenidas eran una aproximacin proporcional a la
capacidad de los dos sistemas. Los desarrolladores han de estimar tambin la capacidad del
sistema, pero usando un mtodo y unas mtricas que permitan una valoracin algo mas precisa
de si el hardware seleccionado satisface los requerimientos. Los desarrolladores construyen una
nueva prediccin de la capacidad de procesamiento requerida basada en un anlisis detallado de
los requerimientos del sistema. Esto les permite desarrollar un modelo de carga del nuevo
sistema, basndose en las medidas tomadas sobre un conjunto de usuarios que realizan
transacciones durante un periodo de tiempo. Usando estadsticas de utilizacin de la CPU para
la nueva plataforma hardware obtenidas de la base de datos del vendedor, los desarrolladores
son capaces de estimar el total de utilizacin de la CPU para un conjunto de transacciones, y
entonces comparar esto con la capacidad de CPU necesaria para las transacciones de usuario
durante un pico de utilizacin del sistema.
Tiempo.
Lo que representa el tiempo cuando se realiza una prediccin es el punto en el cual la
prediccin es realizada con respecto a los mtodos de desarrollo del sistema. El tiempo en el
cual la prediccin es hecha determina que datos estn disponibles como entradas al proceso de
prediccin.
La disponibilidad de los datos determina que mtricas pueden ser predichas y los
mtodos mediante los que se pueden predecir. Por ejemplo en nuestro escenario, los
desarrolladores necesitan hacer una precisin mas precisa de la capacidad de procesamiento
requerida. Esta prediccin puede ser hecha solamente cuando un anlisis detallado del sistema
ha sido documentado.
El tiempo en el cual la prediccin es realizada, tambin influye en los atributos de

inters y consecuentemente en las mtricas. Por ejemplo, inicialmente el gestor del proyecto
est interesado en una prediccin completa del esfuerzo. Una vez que se han realizado las
predicciones de la capacidad de procesamiento, el gestor del proyecto est interesado en una
prediccin del esfuerzo requerido para realizar las pruebas de rendimiento y ajuste, pues existen
riesgos de que el sistema no satisfaga los requerimientos de rendimiento.
Entorno.
El entorno para el desarrollo de un sistema incluye objetivos y restricciones basados en
las metas del proyecto y de organizacin, entradas al proceso de desarrollo y planificacin del
proyecto. Esta visin del entorno para desarrollo del sistema est basada en la descripcin del
entorno usado en el proceso GQM.
Los objetivos y las restricciones son medidos en el proceso de prediccin, para valorar
si pueden ser cumplidos. En nuestro escenario, la primera razn del cliente para adquirir el
sistema nuevo es que el sistema existente no puede satisfacer los pronsticos de demanda de
usuario. En consecuencia, dos de las restricciones mas importantes del proyecto son el
rendimiento del sistema solicitado por el cliente, y la fecha en la que el sistema ha de estar
modificado, para satisfacer la demanda de los usuarios. Rendimiento y fecha de entrega son de
este modo atributos de gran importancia para el cliente. Esto motiva las predicciones de la
capacidad del sistema requerida para satisfacer los objetivos de rendimiento durante el
desarrollo y las predicciones de la fecha de entrega.
El entorno incluye los medios sobre los que pueden ser realizadas los medidas. La
disponibilidad de estos medios limita las medidas que pueden ser utilizadas para una prediccin.
Un ejemplo de medios disponibles en el inicio del ciclo de vida es la especificacin del cliente.
En nuestro escenario, esta es la principal informacin para que el contrato sea adjudicado. El
equipo contable ha de estimar el numero de transacciones por segundo, que el sistema ha de
manejar.
El entorno tambin incluye atributos mediante los que caracterizar el sistema y el
proceso de desarrollo, tales como domino de la aplicacin, y el personal de soporte disponible.
Medidas de atributos del sistema y del proceso de desarrollo, como estos son entradas en el
proceso de prediccin.
Los atributos del sistema y del proceso de desarrollo tambin determinan las diferencias
y similitudes entre el desarrollo del sistema nuevo y la experiencia previa dentro de una
organizacin. En nuestro escenario, la compaa ha desarrollado nicamente un sistema similar,
y la experiencia adquirida por este sistema llega a ser la base de una serie de predicciones para
el sistema nuevo.
Experiencia.
La experiencia influye en la seleccin tanto de la mtrica a predecir como en los
mtodos por los cuales realizar la prediccin, porque contribuye con datos, modelos y habilidad.
En nuestro escenario, algunas medidas del sistema similar estn disponibles. No obstante la
compaa no dispone de modelos sobre los que basar las predicciones mientras se prepara el
presupuesto. Como el presupuesto se necesita rpidamente la prediccin se hace menos exacta
por analoga con los datos que se conocen de un sistema similar. Las medidas y mtodos
seleccionados en este caso, debido a las restricciones de tiempo y a la informacin limitada,
hacen dificultoso para el equipo contable cuantificar la no certeza de sus predicciones.
3.2.3. Proceso de estimacin del coste del software.

Esta seccin describe el proceso de estimacin del software, el cual ha venido siendo
propuesto durante los pasados 15 aos. La mayora de los procesos describen como aplicar un
mtodo simple de prediccin, el cual est basado en uno o ms modelos algortmicos. Boehm
(1981) proporciona una amplia visin del proceso de estimacin de costes de software. Boehm
incluye el establecimiento de los objetivos de la estimacin, la planificacin de la estimacin ,
la recopilacin de estimaciones realizadas mediante varios mtodos.
En contraste con la mayora del software de estimacin de costes hay dos ejemplos de
procesos para grupos de estimacin: Wide-band Delphi y Estimeeting. Esos grupos de
estimacin, son adjuntados a los otros, mas que reemplazarlos. Ellos sugieren dos
aproximaciones distintas para implicar un numero de gente en el proceso de estimacin.
Como conclusin a esta seccin, el proceso de estimacin de costes es comparado con

el proceso de prediccin que se presento en la seccin 2.
Proceso de Bailey y Basili.

Bailey y Basili propusieron el meta modelo de Bailey-Basili como un proceso para
estimar el esfuerzo. El proceso tiene tres pasos principales.
Calibrar el modelo de esfuerzo: El modelo de esfuerzo se calibra usando una

regresin por mnimos cuadrados, sobre un conjunto de datos locales para calcular
los coeficientes del modelo.
Estimar los lmites superior o inferior del modelo de prediccin: Se trata de calcular
el error estndar de estimacin (standard error of the estimate SEE). El SEE se
puede utilizar para calcular los lmites superior e inferior del intervalo de confianza
construido para el modelo, asumiendo una distribucin normal.
Ajustar las predicciones del modelo para tener en cuenta la significancia de los
atributos conductores del coste: El efecto de los conductores del coste sobre el
esfuerzo se estima calculando un factor de ajuste de esfuerzo y aplicndolo a la
estimacin de esfuerzo inicial. El factor de ajuste para un punto de la regresin
original es el nmero mediante el que el valor efectivo ha de ser multiplicado para
obtener el valor predicho. Un modelo de ajuste de esfuerzo se calibra utilizando
regresin lineal mltiple para determinar los coeficientes conductores del coste,
para tres atributos conductores del coste.
La estimacin final se realiza utilizando ambos modelos: el primero para realizar

una estimacin inicial del esfuerzo, y el segundo para ajustar la estimacin, teniendo en cuenta
los controladores del coste.
Proceso de Boehm.
Bohem (1981) propuso un proceso de siete pasos para estimar el coste del software:
Establecer objetivos: El primer paso es determinar nuestros objetivos en la

estimacin del coste. Para ello hemos de evitar gastar tiempo en recopilar
informacin y realizar estimaciones que no sean relevantes para las decisiones que
tenemos que tomar.
Planificar recursos y datos requeridos: En el paso siguiente, debemos planificar
nuestra actividad de estimacin, a fin de evitar la tentacin de preparar una
estimacin demasiado rpidamente.
Fijar los requerimientos software: En este tercer paso determinaremos si las
especificaciones en las que estn basadas nuestra estimacin son econmicamente
viables. Necesitamos saber que estamos intentando construir a fin de estimarlo todo
con precisin.
Detallar tanto como sea posible: El cuarto paso nos indica que hacer una estimacin
con mucho detalle mejora su precisin.
Utilizar varias tcnicas y fuentes independientes: Bohem clasifica las tcnicas de
estimacin como modelos algortmicos, opiniones de los expertos, analoga,
Parkinson, price-to-win, top-down y botton-up. Este paso nos indica que hemos de
usar mas de una tcnica para realizar una estimacin del coste. El uso de una
combinacin de tcnicas nos permite evitar los puntos dbiles de cada tcnica, as
como tomar lo mejor de cada una.
Comparar e iterar estimaciones: Una vez realizada nuestra estimacin utilizando dos
o mas tcnicas, debemos comparar los resultados. Si son inconsistentes, nuestro
siguiente paso es investigar las diferencias. El objetivo es converger en una
estimacin lo mas realista posible, mas que establecer un compromiso arbitrario
entre las estimaciones iniciales.
Continuacin: El paso final en el proceso de estimacin del coste contina la
estimacin realizada en paso anteriores. Debemos usar los resultados de la
comparacin entre la estimacin y el valor real para mejorar nuestra tcnica de
estimacin y nuestros modelos. Deberamos re-estimar el coste cuando el alcance
del proyecto cambia.
Proceso de DeMarco.
DeMarco (1982) propone un proceso para desarrollar y aplicar modelos de coste
basados en datos recolectados localmente. El defenda el uso de modelos de coste de factores
simples derivados de la regresin lineal (ver apartado 1.3.). Un modelo de coste de factores
simples predice el esfuerzo para todo o parte del proyecto basndose en una variable
independiente. El esfuerzo estimado obtenido desde un modelo de coste de factores simples se
ha de ajustar aplicando un factor de correccin. Los factores de correccin, se derivan en el
mismo modo propuesto por Bailey y Basili.
El modelo de DeMarco soporta estimacin botton-up y top-down. El sugiere dividir el

proyecto en componentes de coste, tales como: esfuerzo de diseo, esfuerzo de implementacin
y esfuerzo de integracin. Cada componente de coste es estimado mediante uno o mas modelos
basados en la medida, los cuales estn disponibles en el momento de realizar la estimacin.
DeMarco tambin defenda el uso de modelos sensibles al tiempo, los cuales relacionan
el esfuerzo total del proyecto con la duracin. El sugiere que se use el modelo COCOMO de
planificacin, para este propsito. A continuacin se indican las actividades llevadas a cabo para
utilizar este modelo.
Seleccionar el coste del componente a modelar: El primer paso en el proceso

implica seleccionar los componentes sobre los que se va a realizar una estimacin
de coste. El coste de los componentes est basado en una descomposicin del
sistema de desarrollo en actividades como especificacin, diseo, implementacin y
test.
Seleccionar las medidas desde las cuales predecir los componentes y el coste total:
Una vez que los componentes han sido seleccionados, el siguiente paso es
seleccionar las medidas desde la cual el esfuerzo para completar esos componentes
pueda ser predicho. Por ejemplo, las medidas de cdigo pueden ser utilizadas para
predecir los test por un partido comun.
Desarrollar los modelos de coste basados en un simple valor, basndose en los datos
existentes: Una vez que se han seleccionado las mtricas, los modelos de regresin,
mediante los que se predice el esfuerzo, deben ser desarrollados.
Estimar el coste y el error estndar de la estimacin para cada componente del
modelo: Cuando el valor de las mtricas utilizadas en el modelo de coste basado en
un factor simple puede ser estimado o medido, el modelo se utiliza para predecir el
esfuerzo de los componentes. Si se utiliza una estimacin del valor de las mtricas
de entrada, el esfuerzo debera ser reestimado cuando el valor real de estas mtricas
ha sido calculado.
Ajustar las estimaciones basadas en diferencias entre el proyecto actual y proyectos
pasados: DeMarco indica que la estimacin del esfuerzo debe ser ajustada mediante
una evaluacin subjetiva de las diferencias entre el proyecto en curso y los
proyectos pasados.
Calcular el coste total a partir de los costes de los componentes: Una vez estimado
el coste de todos los componentes, se calcula el coste total como suma de estos.
Calcular el error de estimacin global: El error en la estimacin total se calcula
sumando el error estndar de la estimacin de cada componente aislado.
Utilizar un modelo de coste sensible al tiempo para restringir la estimacin total del
esfuerzo del proyecto: El paso final en el proceso de DeMarco utiliza la estimacin
del esfuerzo como entrada a un modelo sensible al tiempo, tal como COCOMO de
planificacin, para estimar la duracin del proyecto.
Proceso de Heemstra.
Heemstra describe un proceso general de estimacin de costes. Su proceso asume el uso
de modelos de esfuerzo dependientes del tamao, y el uso de atributos conductores del coste,
unidos a estos modelos para realizar ajustes de productividad. Este proceso se divide en siete
pasos:
Crear una base de datos de proyectos finalizados: El paso inicial en el proceso de

estimacin es la recoleccin de datos locales para validar y calibrar un modelo.
Validar el modelo de estimacin: El entorno en el que ha sido desarrollado el
modelo del coste y los proyectos finalizados en los que est basado, pueden diferir
del entorno en el que el modelo es usado. Heemstra advierte, por consiguiente, que
antes de utilizar un modelo precalibrado por primera vez en una organizacin, este
debera ser validado, evaluando su precisin sobre datos de proyectos ya finalizados
en la organizacin.
Calibrar el modelo de estimacin: Si en el paso previo se indica que el modelo no es
vlido para el entorno en el cual va a ser utilizado, el modelo necesita ser
recalibrado usando datos de proyectos finalizados en el entorno actual.
Estimar el tamao: En este paso, se calcula el tamao del software partiendo de las
caractersticas propias del software a desarrollar.
Estimar el esfuerzo y la productividad: Una vez realizada la estimacin del tamao,
el siguiente paso convierte la estimacin del tamao en estimacin de esfuerzo. Los
atributos conductores del coste con influencia en el esfuerzo del desarrollo del
software son evaluados y utilizados para ajustar la estimacin del esfuerzo.
Distribuir el esfuerzo a lo largo de las fases de realizacin del proyecto: En este
paso del esfuerzo total y la duracin del proyecto son distribuidas a lo largo de las
fases de desarrollo del software.
Analizar la sensibilidad de la estimacin y los riesgos asociados: En este paso se
evala la sensibilidad del coste estimado para valores de los atributos conductores
del software, y se determinan los riesgos asociado con la estimacin de costes del
proyecto.
Proceso de Arifoglu.
El proceso de estimacin de Arifoglu consta de cuatro pasos:
Estimacin del tamao: Este paso es equivalente a la estimacin de tamao del

proceso de Heemstra.
Estimacin del esfuerzo y duracin: Este paso convierte la estimacin del tamao
en estimacin del esfuerzo y estimacin de la duracin. Arifoglu sugiere el uso del
modelo COCOMO en este paso.
Distribucin del esfuerzo y la duracin durante el ciclo de vida: Una vez que el
esfuerzo total y la duracin del proyecto ha sido estimado, han de ser distribuidos a
lo largo del ciclo de vida.
Reflejar el esfuerzo en el calendario: El paso final del proceso de Arifoglu es
convertir el numero de das de trabajo requeridos para completar el proyecto en
nmero de das transcurridos en el calendario. Arifoglu es partidario del uso del
modelo de Esterling, para realizar esta conversin. Esterling propone un modelo
para estimar el porcentaje de da gastado trabajando directamente en una tarea Este
paso realiza la prediccin de la duracin del proyecto usando el modelo COCOMO
u otro similar. La duracin predicha por COCOMO es ya un tiempo estimado de
calendario (incluyendo fines de semana, y tiempo medio de vacaciones y bajas por
enfermedad).
PROBE.
Humphrey (1995) describe un proceso de estimacin basada en proxys (proxy-based
estimation PROBE) como parte de su proceso de software personal (PSP). El mtodo PROBE
defiende el uso de medidas seleccionadas personalmente y modelos de regresin basadas en
datos personales para estimar el tamao de un producto software. Un proxy es una medida de
tamao que puede ser utilizada para estimar la longitud de un proyecto medida en lneas de
cdigo. Por ejemplo PROBE utilizar una cuenta de objetos como un proxy de medida de
tamao. La estimacin de lneas de cdigo se utiliza para predecir el esfuerzo individual para
desarrollar el esfuerzo. Los lmites superior e inferior del intervalo de prediccin deben ser
tambin estimados.
Se utilizan modelos de regresin simples para estimar las lneas de cdigo desde las
medidas de tamao basadas en proxys y las horas de trabajo desde las lneas de cdigo. Se
realiza una vuelta atrs desde cada estimacin, comparando el valor estimado con el real. La
vuelta atrs se introduce para mejorar el rendimiento de la estimacin individual. La filosofa
del proceso personal del software es mejorar las facultades de los individuos. Esto limita la
aplicabilidad de PROBE a equipos de trabajo.
Wideband Delphi.
Es posible que la precisin de un mtodo de estimacin pueda ser mejorado mediante la
opinin y la estimacin de un grupo de personas. Boehm (1981) describe la tcnica Wideband
Delphi para combinar las opiniones de los expertos y realizar una estimacin de tamao.
A cada experto se le proporciona una especificacin y un formulario de estimacin. En

una reunin los expertos discuten los asuntos de la estimacin. Cada experto rellena su
formulario de forma annima. En esta ronda, se proporciona a los expertos un sumario de las
estimaciones realizadas, posteriormente se mantiene otra reunin para discutir las estimaciones
de la ronda anterior. Se celebrarn mas rodas hasta que las estimaciones converjan
satisfactoriamente.
Wideband Delphi es similar al Delphi original, desarrollado por RAND Corporation. No

obstante, antes de hacer cada ronda de estimaciones annimas, los expertos discuten sobre las
estimaciones anteriores. En la tcnica original no haba interaccin entre los expertos.
Estimeeting.
Taff describe otro proceso para estimacin en grupo, Estimeeting, la cual ha sido
usada por AT&T Bell Laboratorios. Se mantiene una reunin conocida como estimeeting para
producir una estimacin del esfuerzo para desarrollar una caracterizacin del sistema.
Antes de la reunin, un grupo de estimadores revisan los requerimientos y una

caracterizacin de alto nivel. Los estimadores no son parte del equipo que est desarrollando la
caracterstica, pero son expertos en subsistemas y sern cambiados cuando la caracterstica sea
establecida.
El equipo que establece la caracterstica presenta los requerimientos y el diseo de los

atributos de estimacin. A la presentacin le sigue un periodo de preguntas y respuestas.
Entonces los estimadores realizan estimaciones para los subsistemas en los que son expertos.
Los estimadores consultan entre ellos y con el equipo que establece la caracterstica. El equipo
que determina la caracterstica es responsable de sumarizar los resultados de la reunin y
calcular la estimacin total.
A diferencia de Wideband Delphi que determinaba la estimacin final por consenso, los
resultados de Estimeeting son la suma de todas las estimaciones individuales. Estimeeting
permite estimaciones en mayor detalle, pero requiere un diseo de alto nivel, en el que se
conozcan los requerimientos de los subsistemas. Wideband Delphi tiene la ventaja del consenso
en cada estimacin, pero el detalle de la estimacin es menor, y cada estimador duplica el

trabajo de los otros.
Relacin con el proceso de prediccin general.

Caracterizar el proyecto.
El primer paso del proceso de prediccin y el proceso de Bohem caracterizan el

proyecto para el que se realiza la prediccin, y su entorno. Los otros modelos de estimacin del
coste descritos mas arriba no incluyen este paso de forma explcita. No obstante, esta
caracterizacin est implcita de cualquier proceso que contenga una evaluacin de la influencia
de los atributos conductores del software en la estimacin del esfuerzo. Una posible ventaja de
acarrear el paso de la caracterizacin explcitamente, es que las restricciones y objetivos
establecidos para el proyecto, sern claramente definidos antes que la estimacin sea realizada.
Esto permite que los valores de restriccin sean utilizados como entradas a las predicciones.
Seleccionar las mtricas y mtodos.
Los procesos de Bohem (1981) y de DeMarco (1982) incluyen pasos que implican la
seleccin de mtricas a predecir, cumpliendo de este modo el segundo paso del proceso de
prediccin. En contraste los procesos de Bailey y Basili, Hemstra y Arifoglu asumen que una
mtrica sencilla, tal como las lneas de cdigo o los puntos de funcin, se usara para generar una
prediccin completa del esfuerzo. No obstante en un escenario realista de desarrollo de
sistemas, son necesarias mas de una nica estimacin del esfuerzo y la duracin. La inclusin de
una paso que seleccione las mtricas a predecir permite que el proceso sea utilizada de manera
mas general, que el proceso que asume que las mtricas son las mismas para todos los
proyectos.
Planificar la magnitud y recoleccin de datos.
Bohem (1981) incluye, de manera anloga al proceso de prediccin, un paso para

planificar los datos y recursos requeridos en la estimacin. La actividad de recoleccin de datos
para realizar la calibracin del modelo de estimacin, se realiza explcitamente en el proceso de
Heemstra. Los proceso de Bailey y Basili y de DeMarco (1992) incluyen tambin recoleccin
de datos, al igual que los procesos anteriores incluyen tambin pasos para estima y calibrar los
modelos. La recoleccin de datos es tambin parte del proceso PROBE (Humphrey, 1995). Una
recoleccin de datos fiables requiere un esfuerzo considerable para el personal de soporte, por
ello es importante planificar la cantidad y tipos de datos a obtener en cada paso del proceso de
estimacin.
Realizar las predicciones y evaluar su precisin.
El cuarto paso en el proceso de prediccin implica evaluar la precisin de las

predicciones, para proporcionar realimentacin al proceso de desarrollo. La realimentacin es
necesaria para mejorar los ajustes de la estimacin, as como para la planificacin y el control.
La realimentacin es parte del proceso de Bohem(1981), DeMarco (1982) y Humphrey(1995),
pero no existe en el resto de los procesos.
Analizar las medidas y mtodos.
El quinto paso del proceso de prediccin analiza y evala las mtricas y los mtodos
usados para la prediccin. Mejorar las tcnicas y modelos de estimacin es uno de los objetivos
de los siguientes paso en el proceso de Bohem (1981).
Almacenar la experiencia.
El paso final del proceso de prediccin almacena lo que se ha aprendido, de manera que
estos conocimientos puedan ser reutilizados cuando se hagan predicciones futuras. Almacenar lo
que se ha aprendido con la estimacin actual, no es explcitamente una parte del proceso
descrito. Al incluir esta actividad en el proceso, lo que se hace es contribuir a facilitar la tarea en
procesos futuros.
3.2.4. Modelos de estimacin del coste.

Esta seccin revisa una variedad de modelos de estimacin del software. El marco de
trabajo de seleccin clasifica los modelos en empricos, analgicos, tericos y heursticos. En
esta seccin se clasificara cada modelo de acuerdo con el mtodo de prediccin en el que est
basado fundamentalmente, ya que un modelo puede estar basado en mas de uno de estos
mtodos.
Se realiza aqu una subclasificacin de los modelos empricos en paramtricos y no

paramtricos. Un modelo paramtrico tiene una formula funcional explcita, relacionando una
variable dependiente con una o ms variables independientes., por ejemplo el modelo
COCOMO. Un modelo no paramtrico no tiene una formula funcional explcita, por ejemplo,
un modelo desarrollado usando la tcnica de aprendizaje mquina como una red neuronal.
Las subsecciones basadas en esta clasificacin son:
Modelos empricos paramtricos.

Modelos empricos no paramtricos.
Modelos analgicos.
Modelos tericos.
Heursticos.
No hay modelos que estn basados solamente en heursticas, de este modo discutiremos
brevemente, como se usan las heursticas conjuntamente con otros modelos de estimacin. Para
el resto de los modelos, de discuten las tcnicas de calibracin de modelos.
Los modelos de estimacin mas comunes son modelos paramtricos empricos. Donde
es esfuerzo es predicho basndose en una o mas medidas simples, estos modelos han sido
extendidos, en algunos casos mediante el uso de atributos conductores del coste. Las ventajas y
desventajas de los atributos conductores del coste se discuten en este contexto.
En contraste con la mayora de los modelos presentados, se muestran un par de

modelos desarrollados para predecir el tiempo transcurrido para la realizacin del proyecto.
Estos se presentan en una subseccin como modelos como modelos paramtricos empricos.
En una breve seccin discutiremos los diferentes mtodos y modelos presentados desde
la perspectiva del marco de trabajo de seleccin.
Modelos empricos paramtricos.

Modelos de esfuerzo.
La forma ms simple de un modelo paramtrico emprico es una funcin que relaciona

el esfuerzo de desarrollar un sistema o programa con la medida del tamao. En este contexto, la
medida del tamao se tiene en cuenta alguna caracterstica del producto que se va a desarrollar,
por ejemplo el conteo de lneas de cdigo del programa. El esfuerzo se mide normalmente en
personas-mes o personas-ao.
Los modelos de datos se desarrollan creando una funcin ajustando el conjunto de pares
(tamao, esfuerzo) mediante tcnicas de regresin. Los modelos ms comunes son los que
tienen funciones lineales y exponenciales. El modelo de Albrecht y Gaffney (1983) se basa en
una relacin lineal entre el esfuerzo y los puntos de funcin. El modelo COCOMO (Bohem,
1981) se basa en una relacin exponencial entre esfuerzo y lneas de cdigo.
Se podra pensar que el desarrollo de modelos empricos paramtricos, son un ejercicio

de ajuste de curvas. Esta visin enfatiza alguna de las trampas inherentes en el desarrollo de los
modelos. Courtney y Gustafson manda un aviso a los investigadores de software, que pretenden
descubrir relaciones empricas probando diferentes combinaciones de medidas y formulas
funcionales: la posibilidad de descubrir un buen modelo de esta manera es alta utilizando un
conjunto pequeo de datos.
Existen tambin otras trampas menos notables en el desarrollo de modelo empricos

paramtricos. Una vez que un modelo ha sido propuesto, el numero de observaciones en el
conjunto de datos utilizados para ajustar el modelo debe ser suficientemente grande, para
justificar el nmero de parmetros independientes que aparecen en el modelo. El modelo
debera ser rechazado si los parmetros de entrada no son mutuamente independientes, de este
modo las suposiciones sobre su independencia necesita ser testeado. Las tcnicas estadsticas
que son utilizadas para derivar estos modelos tambin asumen ciertas propiedades del conjunto
de datos, y de los datos que consisten en ejemplo de la poblacin subyacente. Esta ltima
suposicin puede ser difcil de justificar donde se toman las observaciones de un nmero de
diferente organizaciones, porque el modo en que los sistemas son montados y la manera en la
que las medidas como el esfuerzo son recolectadas puede variar considerablemente.
Modelos basados en lneas de cdigo.
Uno de los modelos de esfuerzo ms conocido tiene la forma:
EFFORT = a LOC b (10)
Donde EFFORT es el esfuerzo para realizar el sistema medido en personas-mes y LOC

es el nmero de lneas de cdigo a desarrollar, medido en miles de lneas de cdigo.
Este modelo ha sido investigado por Walston y Felix, Bailey y Basili, y Bohem (1981),
este ltimo como la versin bsica del modelo COCOMO. El valor del exponente b, indica la
escala en que vara el coste segn aumenta el nmero de lneas de cdigo.
Kitchenham examina diez conjuntos de datos, incluidos los conjuntos de datos de
Bailey y Basili, y Bohem, y determina que no hay soporte estadstico para suponer que el valor
del exponente es distinto de uno. En este caso la posibilidad de que la relacin sea lineal no
puede ser descartada. No obstante el modelo no tiene en cuenta el grado en que vara el coste
(por ejemplo la escala de variacin del coste segn las lneas de cdigo), dentro de un conjunto
de datos. Para investigar la posibilidad de error de estas conclusiones, Banker, Chang y Kemerer
(1994) usan un modelo de la forma:
EFFORT = a + b LOC + c LOC 2 (11)
Examinando once conjuntos de datos, encontraron que el valor del coeficiente del
trmino cuadrtico c, era considerablemente distinto de cero en seis de ellos. Estos seis incluan
los conjuntos de datos de Bailey y Basili y Bohem. Esto implicaba que algunos conjuntos de
datos no eran lineales.
La forma cuadrtica del modelo, debera ser considerada vlida sobre un rango de
valores de LOC, los cuales aparecen en el conjunto de datos, en el cual el modelo se ha
ajustado. Banker, Chang y Kemerer indican un valor negativo para el coeficiente cuadrtico en
cuatro de seis casos significativos. Esto es desalentador, porque en los casos en los que el
coeficiente cuadrtico es negativo, el esfuerzo tambin es negativo. Es mas razonable el esperar
que el esfuerzo puede realizarse de manera montona, incrementando la funcin de las lneas de
cdigo.
Los modelos basados en lneas de cdigo tienen xito explicando las variaciones del
esfuerzo, donde la formula funcional puede ser lineal o no. Conte, Dunsmore y Shen, (1986)
dan un ejemplo de modelo lineal con un coeficiente de correlacin del 82% y un error medio
absoluto relativo del 37%. Miyazaki y Mori dan un ejemplo de un modelo COCOMO calibrado
con un error medio absoluto del 20%. La dificultad de usar modelo predictivos basados en
lneas de cdigo es que las lneas de cdigo no pueden medirse hasta que el sistema est
completo.
Modelos basados en lneas de cdigo y otras mtricas.
Los puntos de funcin fueron desarrollados por Albretch en 1979, como una alternativa
a las lneas de cdigo para medir el tamao del software. Algunos investigadores (como
Albretch y Gaffney, Kemerer, Matson, Barrett y Mellichamp) investigaron modelos de la forma:
EFFORT = a + b FP (12)
Donde EFFORT es el esfuerzo para desarrollar el sistema en personas-mes, y FP es el valor de

los puntos de funcin. La mtrica de los puntos de funcin fue explicada en el punto anterior.
Van der Poel y Schach suman a la vez, numero de ficheros, flujo de datos y procesos
para derivar el tamao del cdigo. COCOMO 2.0 (Boehm et al.,1995) introduce una mtrica de
puntos de objeto (Object-Point), que realiza la suma ponderada de pantallas, informes y
mdulos 3GL de un sistema. Se utilizan diferentes ponderaciones para graduar la cuenta de
objetos, de acuerdo con su tipo, adems se establece un grado de complejidad para los objetos:
complejidad simple, media o alta.
Aunque es difcil construir una mtrica compuesta fiable, el motivo principal por el que
tales mtricas existen, es que permiten comparar sistemas mediante un simple nmero, y los
modelos para estimar esfuerzo necesitan incluir nicamente una variable independiente. Una
alternativa es tratar cada componente de la mtrica compuesta como una variable independiente
en el modelo. Donde hay mas de un par de componentes esto incrementa la dificultad de le
anlisis estadstico. Matson, Barret y Mellichamp demostraron que era posible desarrollar un
modelo mas fiable tratando los componentes de los puntos de funcin por separado.
Puede no ser necesario recurrir a modelos complicados. Jeffery y Stathis comparan un

modelo de esfuerzo basado nicamente en ficheros lgicos internos y un modelo de esfuerzo
basado en el total de los puntos de funcin desajustados. Para su conjunto de datos, el modelo
simple resulto mejor para explicar la variacin del esfuerzo que el modelo de los puntos de
funcin.
Modelos basados en otras medidas del tamao.
DeMarco (1982) propone varias mtricas, que pueden ser utilizadas para predecir el
esfuerzo para unas actividades particulares o en su totalidad. Las mtricas basadas en la
especificacin del sistema se llaman Function Bang y Data Bang,. Estas mtricas son
designadas para ser calculadas mediante diagramas de flujo de datos y diagramas entidad
relacin respectivamente. Una desventaja de estas mtricas es que no hay conteo simple.
Dependen de la ponderacin de la complejidad para modificar el conteo, antes de que la suma
total se calculada. A este respecto se comparte algunas de las desventajas de las mtricas.
Basili y Panlilio-Yap investigaron un modelo del esfuerzo basado en el nmero de

pginas de la documentacin.
EFFORT = a + b DocPags (13)
Donde se cuentan las pginas escritas de material que describe el sistema, excluyendo
del cdigo fuente. Este modelo tiene xito en explicar el 85 % de la variacin total del esfuerzo,
para el conjunto de datos de 23 proyectos.
Mukhopadyay y Kekre investigan modelos para estimar el esfuerzo basados en las

medidas de las caractersticas del sistema. Est es contraste con tpicas mtricas basadas en la
caracterstica del dominio del sistema, como las lneas de cdigo. En este caso el dominio es el
proceso de control de manufacturacin, y se encarga de realizar el conteo de las caractersticas
del sistema, as el proceso de manufacturacin necesita comunicarse con flujos de entrada y
salida, y conocer su posicin y capacidad de mecanismo de control. Basndose en los datos de
34 proyectos, ellos son capaces de demostrar que el esfuerzo estimado basado en su medida es
similar a la estimacin realizada mediante la actual medida de lneas de cdigo. La tcnica de
buscar medidas ajustables externas al dominio del desarrollo del sistema es particularmente
interesante, permite a los investigadores echar una ojeada en busca de buenos estimadores del
esfuerzo.
Brownlow investiga un modelo de esfuerzo el cual puede ser aplicado al desarrollo de un

sistema usando anlisis y diseo orientado a objetos. Est basado en el nmero de objetos y en
el nmero de servicios en el sistema. La forma del modelo investigado es:
EFFORT = a + b OBJECTS + c SERVICES (14)
Lo, Webby y Jeffery investigan modelos para predecir el esfuerzo de desarrollo de

interfaces de usuario grficas (GUIs). El modelo est basado en contar las carecteristicas del
GUI:
EFFORT = a + b ACTIONWIDGETS+ c DATAWIDGETS (15)
Un control de acciones (Action Widgets) se utiliza para iniciar comandos o funciones,

por ejemplo un botn de aceptacin. Un control de datos (Data Widgets) visualiza o acepta
datos, por ejemplo una caja de texto. EFFORT es el nmero de personas-hora necesarias para
desarrollar el cdigo asociado a una ventana que contiene un nmero conocido de controles de
accin y de datos. Este modelo es capaz de explicar aproximadamente el 75% de la variacin
del esfuerzo con un conjunto de datos asociado a 35 ventanas.
Modelos dependientes del equipo de desarrollo.
Uno de los argumentos de aquellos que soportan la existencia de la disminucin de la

economa, durante el desarrollo del sistema, es que si el sistema crece, lo hace tambin el equipo
de desarrollo. Un incremento del equipo de desarrollo conlleva un incremento de las rutas de
comunicacin entre los miembros del equipo, implicando un mayor gasto de tiempo en
comunicar desarrollo y tomar decisiones. Jeffery en 1987 explora la relacin entre
productividad, lneas de cdigo y Mximo, Tamao del equipo. El modelo tiene la forma:
PRODUCTIVI TY = a LOC b MAX STAFF c (16)
La productividad es equivalente al nmero de lneas de cdigo dividido por el esfuerzo de

desarrollo medido en persona-mes. Este modelo es capaz de explicar ente un 60% y un 80% de
la variabilidad en la productividad para el conjunto de datos investigados, y denota que la el
aumento productividad disminuye el aumento del equipo de desarrollo.
Conte, Dunsmore y Shen (1986) describen el modelo COPMO, el cual relaciona el

esfuerzo total con el tamao y el equipo de desarrollo. El modelo COPMO est basado en la
suposicin de que el esfuerzo para desarrollar un sistema de un tamao dado, puede ser
modelado mediante el esfuerzo de desarrollo del sistema, donde el personal trabajo
independientemente, mas el esfuerzo requerido para coordinar el proceso de desarrollo con un
equipo interactivo. El modelo as derivado es de la forma:
EFFORT = a + b LOC + c STAFF d

(17)
Donde EFFORT se mide en personas-mes, LOC en lneas de cdigo, y STAFF es el numero

medio de personal. El nmero medio de personal es equivalente al esfuerzo total dividido por la
duracin del proyecto medida en meses.
Modelos de tiempo transcurrido.
Los gestores de proyecto, los clientes y los desarrolladores de sistemas, estn

normalmente muy interesados en estimar cuanto tiempo llevar desarrollar un sistema desde el
inicio al fin, o si este puede ser terminado en un plazo determinado. Normalmente lo que se
quiere es estimar el mnimo tiempo en el cual el sistema puede ser terminado.
La duracin del desarrollo del sistema est claramente relacionada con el nmero de
personas que componen el equipo de desarrollo. Lo que estos modelos plantean, es como se
puede optimizar la productividad si se aumenta o disminuye l numero de personas que estn
trabajando en el sistema.
Algunos investigadores han establecido relaciones entre el esfuerzo de desarrollo y la

duracin. Putnam (1978) propone un modelo relacionando el tiempo para desarrollar el sistema
con el esfuerzo total y el tamao del sistema:
LOC = C k K 1 / 3 t d4 / 3 (18)
Esta ecuacin es la denominada ecuacin del software y en ella LOC es el tamao en lneas de
cdigo, K es el esfuerzo total durante el ciclo de vida del proyecto y td es el tiempo en el que el
sistema ha de ser entregado el esfuerzo total durante el ciclo de vida. Ck es el factor
tecnolgico, su valor depende de las caractersticas del proyecto.
Parr en 1980 propone una variacin del modelo de Putnam, reemplazando la

distribucin de Rayleigh con una similar pero que no es cero en el origen. El cambio fue
propuesto para proyectos donde parte del personal estaba ya trabajando desde el inicio del
proyecto. El modelo de Putnam no incluye las fases de anlisis del sistema y especificacin.
COCOMO (Bohem, 1981) incluye un modelo que relaciona el tiempo con el esfuerzo
de desarrollo:
Tnom = a EFFORT
b (19)
Donde Tnom, es el valor nominal del tiempo de desarrollo en meses y el esfuerzo en personal-
mes. Basndose en una observacin emprica, Bohem teoriza con que hay una zona imposible
para desarrollo. Esta zona est definida aproximadamente por:
Tdev < 0,75 Tnom (20)
Donde Tdev es el tiempo comprimido de desarrollo. Donde el tiempo de desarrollo deseado es

el 75% del tiempo nominal, el modelo COCOMO intermedio recomienda un valor multiplicador
del 1,23, o un incremento de un 23% en el esfuerzo actual, sobre el valor nominal debido a la
compresin de la planificacin.
Se han llevado a cabo intentos de validar estos modelos, con resultados variados. Basili
y Beane en 1981 intentaron adaptar los modelos de Putnam y Parr a datos de siete proyectos,
con una media de personal inferior a 10 personas,y una duracin menor que 18 meses. Ellos
vieron que los modelos no se adecuaban bien. Los proyectos con el conjunto de datos de
Putnam eran mas largos que los que hemos planteado. Basili y Beane especularon con que poda
resultar que la distribucin del esfuerzo no era normal para proyectos con pocos datos, lo cual
entra en conflicto con la teora en la que estn basados los modelos de Putnam y Parr.
Kitchenham y Taylor en 1984 llevaron a cabo un estudio detallado de ambos modelos.

Ningn modelo produjo predicciones exactas para sus conjuntos de datos. No obstante, ellos
researon que los modelos se usaron sin calibracin, y que los proyectos y sus datos eran
bastante pequeos, en lugar de los proyectos grandes o de tamao medio que Putnam sugiere.
Kitchenham y Taylor comentaron lo dificultoso que resultaba seleccionar la tecnologa
adecuada para un proyecto y recoger datos del esfuerzo satisfaciendo las restricciones del
modelo.
Los modelos de Putnam y COCOMO implican que reduciendo la duracin del proyecto
por debajo de lo que podra ser esperado para un proyecto de un tamao dado, se incrementar
el esfuerzo total. Un estudio de Jeffery explora la relacin existente entre el valor de esfuerzo
actual y el esperado y el tiempo transcurrido para un total de 47 proyectos. Este estudio revela
una relacin compleja entre esos valores. Mientras algunos proyectos con duracin ms corta a
la esperada, muestran un considerable incremento en el esfuerzo, son posibles otras
combinaciones: menor duracin implica menor esfuerzo , mayor duracion implica mayor
esfuerzo y mayor duracion implica menor esfuerzo. Kitchenham en 1992 confirma la existencia
de esta relacin dentro de un conjunto separado de datos.
Es posible hacer especulaciones acerca de las circunstancias que pueden llevar a uno de
los cuatro resultados anteriores. Por ejemplo, un proyecto que tarda mucho tiempo en
completarse y ms esfuerzo del esperado por su tamao, puede que est pobremente organizado,
o puede que el equipo de desarrollo sea inexperto o que el trabajo se halla expandido
intencionadamente para rellenar todo el tiempo disponible. Un proyecto que toma ms tiempo
para completarse, pero menos esfuerzo del esperado por su tamao puede haber mejorado la
productividad, empleando un equipo de desarrollo con menos personal, y tambin se mejorar el

gasto. Un proyecto que cost menos esfuerzo y llev menos tiempo para completarse, que el
esperado por su tamao, puede tener una inusual mente alta productividad, o se puede estar
trabajando tiempo extra no contabilizado.
Claramente hay factores a los cuales se puede recurrir en orden de explicar las
variaciones en la productividad, la cual puede ser observada regularmente. Jeffery en 1987, re-
examina sus datos, establece y encuentra que la relacin entre el tamao del proyecto y el
personal se estima en un 70% de la variacin de la productividad. Muchos modelos empricos
paramtricos usan parmetros conductores del coste para tener en cuenta los factores que
influyen en la productividad.
Controladores del coste.
Los modelos discutidos en los puntos anteriores no tienen en cuenta una variedad de
factores, como la experiencia de los desarrolladores del sistema, con los que esperamos mejorar
la productividad. Estos factores de productividad son denominados habitualmente conductores o
controladores del coste. Estos parmetros son valorados en una escala ordinal, por ejemplo, baja
media o alta experiencia, o en una escala nominal, por ejemplo una clasificacin del dominio de
aplicacin del sistema.
En el modelo COCOMO Intermedio se tienen en cuenta 15 controladores del coste. Un

controlador del coste en el esfuerzo es un multiplicador, que incrementa o decrementa el valor
nominal. Una vez que un controlador del coste ha sido evaluado, el valor del multiplicador se
determina mediante una tabla que asocia el controlador del coste al valor del multiplicador. Por
ejemplo, un alto nivel de experiencia en la aplicacin reduce el esfuerzo en un 9%.
La mtrica de los puntos de funcin incorpora tambin la influencia de los controladores

del coste. Esto permite que el valor de los puntos de funcin para un sistema puede ser usado
como base para realizar comparaciones de productividad entre proyectos. Los puntos de funcin
no ajustados se multiplican por el factores de complejidad, que son calculados evaluando el
grado de influencia de 14 factores de productividad independientes.
No siempre es necesario modelar la influencia de un factor de productividad, como un

multiplicador de esfuerzo. COCOMO 2.0 (Bohem et al. 1995) modela la influencia con cinco
factores multiplicadores exponenciales del valor de las lneas de cdigo, dentro de su ecuacin
del esfuerzo.
Un dificultad implcita al uso de un numero elevado de controladores del coste en la

estimacin del software, es que estos controladores pueden no ser independientes. Kitchenham
en 1990, demostr que hay una relacin entre dos controladores del coste del modelo
COCOMO, y apunta que las relaciones entre parmetros de entrada pueden hacer el modelo
inestable.
Una manera de cubrir la necesidad de considerar un gran nmero de controladores del

coste es considerar solo aquellos que son significativos en una organizacin o entorno
particular. Subramanian y Breslawski en 1993 exponen tcnicas que pueden ser utilizadas para
elegir un subconjunto de controladores relevantes del coste para una organizacin o entorno
especfico, dentro de un conjunto mas grande como puede se el usado por el modelo COCOMO
intermedio. Estas tcnicas han sido demostradas sobre la base de datos de COCOMO y reducen
el nmero de controladores del coste de 15 a 4, sin sacrificar la precisin. Kitchenham llega a
una conclusin similar, reduciendo los controladores del coste de 21 a 7 con una variacin de la
productividad del 75%.
Hay ms evidencias de que un modelo puede ser ms satisfactorio cuanto ms simple

sea. Jeffery y Stathis (1996) estudiaron que en el caso de los puntos de funcin, los factores de
complejidad tcnica no mejoran significativamente la precisin del modelo para su conjunto de
datos. Simplificar los modelos es interesante porque hace que los modelos sean ms sencillos de
aplicar, y ms fciles de calibrar.
Calibracin.
Cuando se usan modelos empricos fuera de la organizacin o entorno en el que sus

datos estn basados, las predicciones realizadas por el modelo probablemente sern imprecisas,
aunque el modelo sea recalibrado utilizando datos locales. Incluso modelos genricos como
COCOMO falla a la hora de realizar ajustes de la prediccin sin calibracin. La necesidad de la
calibracin ha sido confirmada en estudios de Kemerer en 1987, Kitchenham y Taylor en 1984
y Jeffery y Low(1990).
Para calibrar modelos empricos paramtricos uno ha de retornar a la forma funcional

bsica y ajustar la funcin al conjunto de datos locales. El numero de datos necesarios depende
del numero de parmetros independientes en el modelo y de sus rangos posibles. Esto restringe
la complejidad del modelo y permite que sea calibrado con precisin.
No obstante, los modelos que incluyen un gran nmero de controladores del coste son
difciles de calibrar. La dificultad inmediata, es que el conjunto de datos requeridos para calibrar
puede ser mucho mas grande que el tpicamente disponible en la organizacin. Esta dificultad
puede ser aliviada considerando nicamente los controladores del coste para los que el sistema
vara significativamente, dentro del entorno en el que el modelo est siendo calibrado.
Cuando intentamos calibrar un modelo con controladores del coste, es crucial que las
definiciones de los propios controladores del coste sean aplicadas consistentemente. Cuelenaere,
van Genuchten y Heemstra en 1987, observan que el cuando un usuario intenta por primera vez
calibrar el modelo, es probablemente la primera experiencia del usuario con el modelo, por
ejemplo cuando el sistema est siendo introducido por primera vez en la organizacin. Ellos han
desarrollado un sistema experto para ayudar a los usuarios a aplicar las definiciones de los
controladores del coste correctamente y consistentemente, cuando se calibra el modelo PRICE
SP.
Un tema mas relacionado con los controladores del coste es como calibrar los valores de
los multiplicadores de esfuerzo que se corresponden con estos. Por ejemplo si una alto nivel de
experiencia en una aplicacin, decrementa el esfuerzo esperado en un 9% en el modelo no
calibrado, la cuestin que porcentaje de decremento habra que aplicar al modelo calibrado.
Miyazaki y Mori en 1985 proponen un mtodo por el que los multiplicadores de esfuerzo del
modelo COCOMO pueden ser ajustados a su entorno particular.
Estimacion de la incertidumbre.
Un simple valor no puede ofrecer ninguna pista acerca del grado de certeza de una
estimacin. Cuando estimamos por medio de un modelo, se introduce incertidumbre adicional
porque ningn modelo ser capaz de explicar todo acerca de la variacin de una variable
dependiente, y porque los valores que aportamos como parmetros de entrada son inciertos en s
mismos.
Conte, Dunsmore y Shen sugieren que un modelo es aceptable si su error absoluto

medio es menor o igual que 25%, y si al menos el 75% de los valore predichos estn dentro del
25% de sus correspondiente valores actuales. Estas mtricas de aceptabilidad son ampliamente
usadas cuando se evala la precisin de un modelo. Incluso para modelos que satisfacen estos
criterios, el 25% de los valores predichos pueden diferir de los reales en mas del 25%. La
incertidumbre de los modelos de estimacin no puede ser pasada por alto. Los parmetros de
entrada son inciertos cuando son incapaces de medir sus valores directamente. Por ejemplo,
cuando usamos un modelo como COCOMO intermedio, para estimar el esfuerzo al inicio del
proyecto, el numero de lneas de cdigo debe ser estimado y se deben tomar decisiones sobre
los valores de los controladores del coste.
La incertidumbre asociada con los valores de los parmetros de entrada puede ser
eliminada si es posible medirlos directamente. No obstante, los estimadores pueden no ser
capaces de desarrollar o calibrar un modelo basado en medidas directas, porque no se disponga
de datos histricos adecuados. Los modelos de esfuerzo basados en lneas de cdigo son
frecuentemente utilizados, ya que las lneas de cdigo pueden ser estimadas indirectamente, y se
puede realizar de este modo una prediccin de esfuerzo, al principio del ciclo de vida. Las
medidas del esfuerzo total realizado y del numero total de lneas de cdigo producidas en un
proyecto son dos de las mtricas ms sencillas a realizar, esto justifica sin duda la popularidad
de estos modelos.
La reduccin en incertidumbre ganada usando un modelo basado en medidas directas

puede ser compensada si el modelo mismo es poco preciso. Por ejemplo los modelos de
esfuerzo basados en lneas de cdigo explican mejor las variaciones de esfuerzo que los
modelos basados en puntos de funcin.
Low y Jeffery (1990) demuestran que los puntos de funcin pueden ser estimados de
manera mas consistente que las lneas de cdigo, esto implica que las estimaciones basadas en
puntos de funcin introducen menos incertidumbre que las basadas en lneas de cdigo. La
incertidumbre de una estimacin depende tanto de la del modelo como de la de las entradas al
modelo.
La desviacin estndar del error en la estimacin se suele utilizar para evaluar el grado
de certeza en los modelos empricos y estimar el rango de posibles valores. Por ejemplo
COCOMO 2.0 (Bohem et al., 1995) sugiere usar un rango de aproximadamente el valor de la
desviacin estndar, entorno al valor ms probable.
La desviacin estndar en este contexto, es una medida de la variacin dentro del

conjunto histrico de datos. Desafortunadamente no es una medida vlida para estimaciones
nuevas. El modelo en el que se basa la estimacin es incompleto. Solo tiene en cuenta alguno
de los factores que afectan al valor actual. Supongamos que hacemos una estimacin para un
proyecto afectado por un factor, que ya influy en proyectos anteriores, en los cuales est
basado. El modelo no ser capaz de predecir la influencia de este factor, y no habr garantas de
que el valor actual para el nuevo proyecto caiga dentro del rango de los valores predichos. Por
ejemplo, una estimacin de esfuerzo para un proyecto nuevo que tiene una arquitectura cliente-
servidor , puede estar basada en el esfuerzo para desarrollar sistemas similares con una
arquitectura basada en un nico host. Si el cambio en las arquitecturas de los sistemas no se
considera un controlador del coste o un factor de riesgo, su influencia no ser tenida en cuenta
por la estimacin. Si el cambio tiene un efecto significativo sobre la productividad, la
estimacin puede ser poco fiable.
La incertidumbre asociada con un parmetro de entrada se puede incorporar dentro de

un modelo, estimando el valor mas bajo, el mas alto y el mas probable de dicho parmetro. De
este modo el valor esperado para la variable de estimacin y su desviacin estndar vendran
determinados por las siguientes expresiones:
Valor esperado = ( L + 4 M + H ) / 6 (21)

Desviacion estndar = ( H L ) / 6 (22)
Donde L es el valor mas bajo, M es el valor mas probable y H es el valor mas alto para el
parmetro de entrada.
Esta tcnica fue empleada por Putnam (1978) para obtener una estimacin del tamao
del sistema, aadiendo los valores esperados de tamao a cada componente del sistema, y
estimando la desviacin estndar total como la raz cuadrada de la suma de los cuadrados de las
desviaciones estndar de cada componente. La tcnica puede ser utilizada para estimar el rango
de un valor de entrada al modelo.
Los conjuntos difusos son una alternativa para evaluar la incertidumbre de los valores
de los parmetros de entrada. Fei y Liu en 1992 propusieron f-COCOMO, la versin difusa del
modelo COCOMO. En este modelo se representan los multiplicadores asociados a los
controladores del coste, como intervalos difusos en lugar de como valores simples, a fin de
modelar la incertidumbre asociada con la influencia de los controladores del coste sobre el
esfuerzo. De esta manera se estiman los lmites superior e inferior del esfuerzo.
Cuando un modelo tiene muchos parmetros de entrada, cada uno con un rango de
posibles valores, el rango de la estimacin generada por el modelo se incrementa. Este rango se
incrementa an mas cuando la incertidumbre asociada a los valores de entrada se combina con
la incertidumbre asociada con el modelo. Por ejemplo, tomando como referencia el modelo
COCOMO Intermedio, se determina que es posible una variacin en el esfuerzo superior al
800%, cuando el rango de valor mas alto a mas bajo para cada controlador de coste es
combinado.
Podemos ser capaces de evaluar la probabilidad de que el valor actual est dentro de un
rango estimado. Esto es un poco ms difcil que estimar un posible rango de valores. Basarse
para este tipo de estimaciones en la desviacin estndar del error es cuestionable por los mismos
motivos que la desviacin estndar no es adecuada para medir la incertidumbre de un modelo.
Estimar la incertidumbre asociada a una estimacin es una tarea difcil. No obstante

estimar un rango para los valores de entrada es til, al menos para investigar la sensibilidad del
modelo con sus entradas.
Modelos empricos no paramtricos.

Brian, Basili y Thomas describieron la tcnica de reduccin del conjunto optimizado

(optimized set reduction OSR) la cual emplea tcnicas de reconocimiento de patrones para
analizar conjuntos de datos. OSR est basada en parte en arboles de decisin.
OSR ha sido aplicado a una combinacin de los conjuntos de datos de los modelos
COCOMO y Kemerer, para predecir la productividad. Cada proyecto dentro del conjunto de
datos se representa mediante sus controladores de coste COCOMO y su valores de esfuerzo. La
tcnica OSR selecciona un subconjunto de proyectos en los que est basada la prediccin de la
productividad del nuevo. La productividad est medida en personas-mes/lneas de cdigo.
Los proyectos seleccionados para el subconjunto ptimo, comparten todos algunos

controladores del coste comunes, con el nuevo proyecto, por ejemplo todos los proyectos con
complejidad nominal, baja fiabilidad de requerimientos y gran tamao de la base de datos. OSR
selecciona los valores de estos controladores del coste, de tal modo que los valores de
distribucin de productividad dentro del subconjunto seleccionado son medidos como buenos,
de acuerdo con un criterio estadstico establecido.
Una distribucin de probabilidad se deriva de la frecuencia de distribucin de los

proyectos seleccionados, para un rango de intervalos de productividad. La productividad para
nuevos proyectos es predicha. La productividad para el nuevo proyecto puede ser predicha
calculando el valor esperado basado, en la derivada de la densidad de distribucin.
Briand, Basili y Thomas comparan la precisin de la tcnica OSR para un modelo

COCOMO calibrado para el conjunto de datos combinado de COCOMO y Kemerer y un
modelo de regresin. La tcnica OSR tiene una media de error absoluto mas pequea que los
dos modelos paramtricos.
Una ventaja de OSR es que puede ser aplicado con entradas de datos incompletas. Es
posible realizar una estimacin para un proyecto donde solo un subconjunto de controladores de
coste es conocido. Otra ventaja es que los valores nominales u ordinales de los controladores del
coste, se pueden usar como entradas sin ser convertidos en valores numricos multiplicadores.
Srinivasan y Fisher en 1995 describen dos mtodos no paramtricos mas para generar
modelos de esfuerzo. El primero de ellos utiliza un algoritmo de aprendizaje para generar un
rbol de decisin. El segundo mtodo utiliza propagacin de retorno para entrenar una red
neuronal. Estos mtodos son tambin testeados utilizando un conuunto de datos combinado de
COCOMO y Kemerer. Los valores de los controladores de coste COCOMO y las lneas de
cdigo estimadas son entradas a los modelos de esfuerzo.
El esfuerzo estimado mediante la red neuronal tiene una menor media de error absoluto
que el rbol de decisin. La precisin de ambos modelos es comparable con la de OSR.
Calibracin.
Cada una de las tcnicas descritas anteriormente, requiere un gran numero de datos,
debido al gran nmero de variables independientes y rangos de valores cubiertas por los
modelos. Los autores que trabajan en este tema, destacan la necesidad de un pequeo conjunto
de datos COCOMO (63 proyectos) para aplicar sus tcnicas, as como que el entorno de los
proyectos de conjunto de datos sea el mismo.
Aunque sea pequeo el conjunto de datos COCOMO, es significativamente mayor que

el que muchas organizaciones puede recolectar. Donde un conjunto de datos lo suficientemente
grande est disponible, puede ser dificultoso conseguir que todos los proyectos sean del mismo
entorno.
Los rboles de decisin, las redes neuronales y las tcnicas OSR pueden ser aplicados
donde el nmero de variables independiente sea reducido para completar el tamao del conjunto
de datos disponible, por ejemplo lneas de cdigo con una simple variable independiente. No
obstante, no est claro si estas tcnicas son superiores a la regresin simple bajo esas
circunstancias.
Estimacin de la incertidumbre.
La incertidumbre de un modelo puede ser evaluada por medio del error relativo. Brian,
Basili y Thomas sugieren que la incertidumbre de una estimacin OSR puede ser evaluada por
medio de la entropa de la distribucin de probabilidad. El valor de esta medida de entropa, es
la que es minimizada cuando se selecciona el subconjunto de proyectos optimo. Ellos
observaron que este valor correlaciona bien con la media del error relativo.
Un rango de estimacin puede generarse tambin calculando la estimacin basada en un

rango posible de datos de entrada. Cuando un rango de datos de entrada se utiliza con un
modelo paramtrico, el rango de estimacin producido puede ser entendido por inspeccin de
sus formas funcionales. Cuando un rango de valores de entrada se utiliza con un modelo no
paramtrico el rango de estimacin producido puede ser menos fcil de entender.
Los modelos no paramtricos basados en un rbol de decisin o OSR, tienen en comn

la divisin del conjunto de datos para generar una estimacin. Diferentes valores de entrada
pueden, en general, seleccionar diferentes subconjuntos. Existe el riesgo de seleccionar un
subconjunto no representativo, en el sentido de que aunque contenga proyectos similares, el
esfuerzo real puede variar significativamente debido a factores no considerados por el modelo.
Esto puede provocar que una estimacin basada en un rango de los valores de entrada vare de
manera discontinua.
Modelos analgicos.
El modelo analgico de estimacin de costes, se basa en comparar uno o mas proyectos

finalizados en un dominio similar al nuestro como medio para producir una nueva estimacin.
La estimacin se lleva a cabo analizando los datos recolectados de estos proyectos finalizados y
contrastndolos con el nuevo proyecto, evaluando similitudes. Como el esfuerzo de desarrollo
se conoce de antemano, se utiliza como base de la estimacin del nuevo proyecto. La estimacin
por analoga parece sencilla y directa, sin embargo hay una serie de problemas que han de ser
determinados. La manera de establecer las caractersticas del proyecto es uno de estos
problemas, puesto que al principio del proceso de estimacin hay restricciones en cuanto a la
informacin disponible. Ejemplos de esto pueden ser el dominio de la aplicacin, el proceso de
desarrollo del software, etc. Otro problema comn es la manera de contrastar varios proyectos a
la vez. Siempre puede haber proyectos disidentes que nos hagan desviar la estimacin.
El proceso para predecir la estimacin del software, se puede dividir en los siguientes
pasos:
Seleccin de analogas.
Evaluacin de similitudes y diferencias.
Evaluacin de la calidad de la analoga.
Consideracin de casos especiales.
Creacin de la estimacin.
Seleccin de analogas: La primera etapa en el proceso es recopilar los proyectos

adecuados que pueden se comparados con nuestro proyecto, en una base de datos. Este proceso
implica la seleccin de proyectos anlogos que reflejen tanto el entorno de desarrollo como las
caractersticas del proyecto nuevo.
Evaluacin de similitudes y diferencias: Una vez que tenemos la base de datos de

proyectos anlogos, la siguiente etapa es evaluar las similitudes con el proyecto nuevo. Estas
similitudes se determinan en trminos de caractersticas del proyecto, el numero de
caractersticas dependen de los datos disponibles para caracterizar el proyecto.
Figura 9
El proceso de seleccin de analogas puede verse como un espacio n-dimensional,

donde cada dimensin se corresponde con una caracterstica del proyecto. Los proyectos mas
similares sern aquellos cuyas representaciones estn mas cerca unas de otras. En la figura
tenemos una representacin de un espacio tridimensional. Esta figura es un ejemplo de cmo se
realiza el proceso de seleccin. Supongamos que queremos medir el esfuerzo de un nuevo
proyecto, analizando las caractersticas siguientes de proyectos pasados: experiencia, puntos de
funcin y esfuerzo de desarrollo. Visualizando el espacio tridimensional se ve claramente que el
proyecto B est mas cerca del nuevo proyecto. En este caso el proyecto A podra ser rechazado
debido a la considerable distancia que le separa del nuevo proyecto. Este ejemplo es bastante
trivial, pero en esencia esto es lo que ocurre. Una aproximacin mas realista, implicara mas
proyectos y dimensiones o caractersticas de proyectos.
Evaluacin de la calidad de la analoga: Las medidas que determinan la calidad son las
siguientes:
- Error absoluto.
- Porcentaje de error y media del porcentaje de error.
- Magnitud del error relativo (MRE) y media de la magnitud del error relativo
(MMRE).
- Mtrica de calidad de prediccin dentro de un 25% pred(0,25).
Los resultados de este punto, pueden ser utilizado por el proceso de analoga para
examinar los resultados obtenidos con otras estimaciones, y de este modo realizar un proceso de
realimentacin.
Consideracin de casos especiales: En algunos casos puede ser necesario no considerar

algunos proyectos. Incluso para proyectos seleccionados en la etapa segunda, puede ser que
tenga caractersticas que deseemos ignorar. Por ejemplo, si el proyecto en consideracin utiliza
una metodologa de diseo inusual.
ESTOR es un modelo de razonamiento basado en casos (case-base reasoning) CBR,

desarrollado por Mukhopadhyay, Vicinanza y Prietula para estimar el esfuerzo de desarrollo del
software. El razonamiento basado en casos es una forma de razonamiento analgico que emplea
cinco procesos bsicos:
Construccin de una representacin del problema objetivo.

Recuperacin de un caso adecuado para actuar como caso fuente de analoga.
Transferir la solucin desde el caso fuente al destino.
Establecer las diferencias entre los casos fuente y destino.
Ajustar la solucin inicial para tener en cuenta esas diferencias.
En ESTOR los casos son proyectos software y cada uno se representa mediante los
valores de este conjunto de medidas. Las mtricas utilizadas por ESTOR son puntos de funcin
y entradas al modelo COCOMO intermedio. ESTOR recupera un caso para actuar como fuente
de la analoga, basndose en el valor de los puntos de funcin del proyecto a estimar. Se calcula
un vector distancia para encontrar el proyecto vecino mas cercano. La solucin inicial es el
valor de esfuerzo para el proyecto anlogo. Las diferencias entre el proyecto anlogo y el nuevo
se determinan comparando los valores de sus medidas. El valor del esfuerzo correspondiente al
proyecto anlogo se ajusta teniendo en cuanta esas diferencias, aplicando un conjunto de reglas.
Las reglas utilizadas por ESTOR se derivan de las opiniones de un experto, cuya estimacin era
precisa para el conjunto de datos usado. Las reglas ajustan el esfuerzo mediante un
multiplicador, si las precondiciones particulares de los proyectos fuente y destino se conocen
previamente.
El conjunto de datos utilizado para desarrolla ESTOR es un subconjunto de 10 proyecto

tomados del conjunto de datos de Kemerer (Apendice A). ESTOR fue testeado con los 15
proyectos de este conjunto de datos, obtenindose un error relativo del 53%.
ANGEL es otro modelo de estimacin por analoga. Los proyectos se representan

mediante componentes de puntos de funcin. Los proyectos anlogos son vecinos de los
proyectos nuevos, y se identifican calculando un vector distancia desde el proyecto nuevo a
otros proyectos en el conjunto de datos. El esfuerzo para el proyecto nuevo se predice mediante
una media ponderada del valor de esfuerzo de sus proyectos vecinos.
En ANGEL, el usuario puede especificar las mtricas en las que se basa la bsqueda de
proyectos anlogos. ANGEL puede determinar automticamente un subconjunto ptimo de
medidas para un conjunto de datos particular.
La precisin de ANGEL es mejor que la de los modelos de regresin lineal. Los

modelos de regresin estn basados en las mediadas del conjunto de datos, que presentan la ms
alta correlacin con el esfuerzo. En el conjunto de datos Kermerer el error relativo para ANGEL
es del 62%, el cual puede ser comparado con el 100% de los modelos de regresin y el 53%
para ESTOR. Mientras que ESTOR parece ser mejor que ANGEL en este conjunto de datos, las
reglas de ajuste para ESTOR estaban desarrolladas solo con 10 de los 15 proyectos del conjunto
de datos (Apendice A), y estas reglas pueden no tener xito cuando se aplica a proyectos con
distinto conjunto de datos.
Calibracin.
El conjunto de datos que se explora para encontrar casos anlogos, deben ser
representativos del caso para el que se quiere hacer la estimacin. Las diferencias entre el caso
fuente y el caso objetivo han de ser tan pocas como sea posible.
Para soportar la estimacin para una gran variedad de proyectos, son necesarios muchos
puntos de datos y un rango de valores muy elevados. No obstante la estimacin basada en
analoga puede ser aplicada con xito con pequeos conjuntos de datos que estn dentro del
mismo entorno. En realidad particionar los conjuntos de datos de manera acorde con los
atributos del entorno mejora la precisin de modelos de estimacin como ANGEL.
La incertidumbre de un modelo puede ser evaluada por medio del error relativo y un
rango de estimacin puede ser generado calculando valores de estimacin basados en el rango
de entrada. No obstante, como suceda en los modelos empricos no paramtricos, la estimacin
basada en un rango de entrada muestra una entrada que vara de modo discontinuo, debido a las
diferentes analogas seleccionadas.
Es tambin posible que los casos fuente seleccionados puedan compartir los mismos
valores que el caso objetivo, pero no ser representativo del caso objetivo debido a factores que
no se consideran en la representacin de los casos. Esto puede cuantificar la precisin de
estimaciones basadas en conjuntos de datos particionados.
Modelos tericos.
Un modelo de esfuerzo.
En este seccin se hablar fundamentalmente de un modelo terico realizado en 1991

por Abdel-Hamid, cuyas caractersticas principales se exponen a continuacin. La
realimentacin dinmica de la relacin entre equipo de produccin, desarrollo del software,
planificacin y control, se modela mediante un lenguaje de simulacin. Los escenarios de
simulacin de gestin de proyectos, pueden ser ejecutados para investigar los efectos de los
decisiones y polticas de gestin. El modelo trabaja partiendo de una estimacin inicial para el
esfuerzo total y luego explora que influencia tienen sobre el esfuerzo total, suposiciones acerca
de iteraciones y realimentacin entre decisiones y proyectos.
Un escenario explorado por Abdel-Hamind y Madnick considera las circucunstacias en

las que se aade mas gente al al final del proyecto para permitir una finalizacin mas rpida de
este. La ley de Brooks establece que Aadir mas personal al final del proyecto hace que este
se retrase mas. El modelo de Abdel-Hamid y Madnick indica que aadir mas personal al final
del proyecto hace que este sea mas costoso, pero no necesariamente mas lento. El punto de
desarrollo en en cual se aade personal extra y la experiencia del personal aadir son factores
clave para el avance o retraso del proyecto. Abdel-Hamind y Madnick demostraron mediante su
modelo como subestimaciones y sobrestimaciones del esfuerzo pueden ser determinantes para
disminuir la productividad e incrementar el esfuerzo total. Como las estimaciones para
proyectos nuevos se basan en proyectos pasados, ellos afirman que su modelo puede ser
utilizado para explorar si para un proyecto finalizado se realizo el mnimo esfuerzo o no, y esto
utilizarse como factor de correccin para estimaciones futuras.
Calibracin.
Cuando este modelo se aplica a un nuevo entorno, las suposiciones de modelo han de
ser examinadas para ver si son vlidas. Por ejemplo, si el modelo depende de suposiciones
acerca de las polticas de gestin, y estas son imprecisas en un entorno nuevo el modelo ser
invlido.
El modelo tambin depende de un nmero de parmetros, los cuales pueden

determinarse de modo especfico para cada entorno en el que se aplica, por ejemplo la
distribucin del esfuerzo en cada fase de desarrollo.
Este modelo se ajusta a la generacin de rangos de estimacin, basados en condiciones

iniciales, que se utilizan para explorar la estimacin. Como el modelo se utiliza inicialmente
para exploracin en lugar de para prediccin, el material publicado incluye solo un pequeo
nmero de ejemplos para entornos similares. Esto dificulta la evaluacin de lo preciso que
puede ser el modelo para un rango amplio de entornos.
Heursticas.
Los controladores del coste son un ejemplo de cmo las heursticas son incorporadas
dentro de los modelos paramtricos de estimacin de esfuerzo. La influencia de los
controladores del coste puede ser explorada estadsticamente, la evaluacin inicial de los
factores con mas probabilidad de influir en el coste es un ejemplo de heurstica. Los esfuerzos
multiplicadores correspondientes a los controladores del coste pueden ser determinados de
manera heurstica, si los datos disponibles para cuantificar el efecto de los controladores del
coste estadsticamente son insuficientes.
Las reglas usadas en el modelo de razonamiento basado en casos de ESTOR son

tambin ejemplos de heursticas. Las reglas ajustan el esfuerzo para un proyecto anlogo
basndose en la opinin de un experto sobre como ciertas circunstancias influyen en el esfuerzo.
De este modo, las heursticas pueden utilizarse en dominios tales como la estimacin del
coste del software, donde existen unos cuantos modelos tericos de relaciones causales y donde
interactuan muchos facotres de modo que resulta dificultosa la aplicacin de modelos empricos.
3.3. Estimacin de la planificacin.

Cuando gestionamos el desarrollo de un nuevo sistema software, hemos de establecer
un compromiso entre el coste, la planificacin y el tamao. Por ejemplo, si queremos un coste
menor hemos de reducir el tamao del producto. Planificar el periodo de tiempo para el
desarrollo del software, es un factor clave para el desarrollo del proyecto. Las modificaciones en
los requerimientos de calidad tienen su impacto en la planificicacin y en el coste. Para asegurar
una calidad mayor, se necesita testear mas veces el sistema finalizado. Frecuentemente esto
puede incrementar el esfuerzo de desarrollo y el tiempo de desarrollo. En este apartado
estudiaremos algunos de los mtodos utilizados para realizar la estimacin de la planificacin.
Segn McConnell (1996), una vez que se han estimado el tamao y el esfuerzo, estimar
la planificacin resulta casi trivial. Una regla es calcular la planificacin a partir de la
estimacin del esfuerzo:
TDEV = 3 , 0 ( EFFORT ) 1 / 3 (23)
Donde TDEV es el tiempo de desarrollo en meses y EFFORT es el esfuerzo en personas-mes.
A diferencia de lo que pasaba con el tamao y con el esfuerzo, con la estimacin de la

planificacin se han publicado resultados extraordinariamente similares. Las opiniones varan
sobre si el 3,0 de la ecuacin debiese ser 3,0 o 4,0 o 2,5, y sobre lo que sucedera si se intentara
desarrollar ms rpido de lo que se indica en la ecuacin; pero si no se poseen datos mas
precisos de la propia organizacin la ecuacin anterior es ptima para empezar.
Los investigadores han descubierto que las estimaciones entran dentro de precisiones
previsibles en varios estados del proyecto. El grfico de convergencia de la figura 10 muestra
como la estimacin se hace mas precisa segn avanza el proyecto. En la tabla 11 tenemos
representados numricamente los rasgos de estimacin implicados en la figura 10.
La ecuacin 23 es la razn de que el rango de estimacin de la tabla 11 sea ms amplio

para el esfuerzo que para la planificacin. Los proyectos ms grandes tienen un rango mayor,
pero tambin tienen los equipos ms grandes; y las ineficiencias asociadas a los equipos grandes
implican que el esfuerzo aumenta desproporcionadamente ms rpido que la planificacin. El
rango de planificacin que se muestra en la tabla 11, supone que se aadirn o quitarn
miembros del equipo conforme se vaya aprendiendo sobre el alcance del proyecto. Si se
mantiene constante el tamao del equipo, el rango de planificacin tendra la misma amplitud
que el del esfuerzo.
Figura 10
Esfuerzo y tamao Planificacin

Fase Optimista Pesimista Optimista Pesimista
Concepto inicial del 0,25 4,0 0,60 0,60
producto
Concepto del producto 0,50 2,0 0,80 1,25
aprobado
Especificacin de 0,67 1,5 0,85 1,15
requerimientos
Especificacin del diseo 0,80 1,25 0,90 1,10
del producto
Especificacin del diseo 0,90 1,10 0,95 1,05
detallado
Tabla 11
A continuacin se muestran algunos mtodos alternativos para calcular la planificacin

del software a partir de la estimacin del esfuerzo:
Utilizacin de software de estimacin para calcular la planificacin, a partir de la

estimacin del tamao y del esfuerzo.
Utilizacin de los datos anteriores de la organizacin.
Utilizacin del paso de estimacin de la planificacin a partir de uno de los
enfoques algortmicos (por ejemplo COCOMO), para proporcionar una estimacin
ms afinada de la que se obtendra con la ecuacin.
Uno de los problemas comunes con los que se encuentra la estimacin de la

planificacin es que generalmente se realiza tan framente que se completa asignndole un
margen de error, al que denominaremos relleno. A veces se completa lo suficiente, a veces no.
La ecuacin y los refinamientos peridicos aproximados permiten no utilizar el relleno.

El relleno no es una buena opcin por que les da a los clientes unas nociones equivocadas sobre
por qu las planificaciones son imprecisas. El relleno dice: No creo que nuestras estimaciones
sean buenas. Un rango de estimacin con refinamientos peridicos dice: Las estimaciones son
buenas, pero no es posible que en este estado del proyecto una estimacin sea precisa. Ser mas
conforme vaya avanzando.
La utilizacin de herramientas de estimacin de software, mtodos algortmicos y tablas

con datos de proyectos anteriores, combinados con la utilizacin de estimaciones con rangos,
eliminan la necesidad de relleno.
3.3.1. Observaciones de Norden.
En los aos 50 Peter V. Norden de IBM encontro una relacin entre el personal que est
desarrollando un proyecto y el tiempo necesario para realizar este trabajo. Esta relacin puede
representarse mediante la curva de la figura 11. A esta curva se le denomina curva de Rayleigh-
Norden, pues la forma que toma esta curva fue descrita analticamente por Lord Rayleigh.
Figura 11
Esta curva tiene una ecuacin, que permite manejar la relacin entre tiempo y esfuerzo
mediante mtodos algebraicos.
y (t ) = 2 K a t e at
2
(24)
Donde a = (1/ 2td ) , td es el tiempo para el que y es mximo, K es el area bajo la curva
2
desde t=0 hasta infinito y representa el esfuerzo nomianl en personas-ao, y(t) representa el
esfuerzo realizado en un tiempo t en personas-ao.
Basndose en este patrn Putnam desarrollo la ecuacin del software (ec. 18) (Putnam,
Lawrence 1978). Partiendo de esta ecuacin se puede estimar el tiempo necesario para
desarrollar un poryecto del siguiente modo:
3/ 4
LOC
td =
1/ 3 (25)
Ck K
Donde LOC es el tamao en lneas de cdigo, K es el esfuerzo total durante el ciclo de vida del
proyecto y td es el tiempo en el que el sistema ha de ser entregado el esfuerzo total durante el
ciclo de vida. Ck es el factor tecnolgico, su valor depende de las caractersticas del proyecto.
3.3.1. Planificacin basada en compromiso.

Algunas organizaciones se saltan el paso intermedio que consiste en estimar el esfuerzo,
pasando directamente de los requerimientos a la planificacin. Normalmente lo hacen basndose
en el compromiso, en donde se conversa con los desarrolladores para realizar ms bien un
compromiso de planificacin que una estimacin. Este mtodo asigna a los desarrolladores la
responsabilidad de crear las estimaciones de tamao y esfuerzo. Tiene la ventaja de incrementar
la implicacin de los desarrolladores en la planificacin, tiende a aumentar la moral en el
periodo inmediato al compromiso y ayuda a que los desarrolladores hagan bastantes horas
extras totalmente voluntarias.
Este mtodo tambin tiene varios inconvenientes. En lo que a la estimacin se refiere,

los estudios de la estimacin en relacin con la planificacin real han demostrada que la
estimacin de los desarrolladores tiende a tener un factor de optimismo de un 20 a un 30%.
Dentro de este tipo de planificacin, este optimismo se fomenta y no se le somete a ninguna
prueba para ver si est en consonancia con la realidad. En conjunto, el efecto que causa es que
da lugar a grandes errores de estimacin.
El compromiso tiene su sitio en el desarrollo rpido, pero tal y como se lleva a cabo este
tipo de planificacin, no sirve de gran ayuda en las planificaciones pequeas. Es esencial que el
compromiso sea realista y factible, de forma que el equipo pueda conseguir grandes xitos en
lugar de fracasar.
3.3.2. Mtodo de estimacin de primer orden de Jones.

Si tiene la suma total de todos los puntos de funcin, puede realizar a partir de ellos un
clculo aproximado de la planificacin, utilizando un mtodo que Carpers Jones ha denominado
estimacin de primer orden. Para utilizarlo, simplemente hay que tomar el total de los puntos
de funcin y elevarlo a la potencia apropiada, seleccionndola en la Tabla 12. Los exponentes
de la tabla se han derivado del anlisis de Jones de su base de datos de miles de proyectos.
Clase de Software Mejor caso Media Peor caso

Sistemas 0,43 0,45 0,48
Gestin 0,41 0,43 0,46
Prt--porter 0,39 0,42 0,45
Tabla 12.
En esta tabla se clasifica el software en tres tipos: de sistemas, de gestin y prt--
porter. El software de sistemas incluye el sistema operativo, controladores de dispositivos,
compiladores y bibliotecas de cdigo. El software de gestin se refiere a sistemas internos, que
se utilizan en un nica empresa. Funciona sobre un hardware limitado, quizs un nico
computador. Los ejemplos tpicos son sistemas de control de nminas, contabilidad o control de
almacn. El software prt--porter es software empaquetado y que se vende comercialmente.
Incluye tanto productos para el mercado horizontal (como tratamiento de texto y hojas de
clculo), como productos para el mercado vertical (como programas de anlisis finaciero,
escritura de guiones y gestin de informacin legal).
Si estima que el nmero total de puntos de funcin en el proyecto es de 350 y est

trabajando en una organizacin media de software prt--porter elevara 350 a 0,42,
obteniendo una planificacin aproximada a 12 meses. Si est trabajando en una empresa de
software prt--porter muy organizada, elevara 350 a 0,39, obteniendo una planificacin de
10 meses.
Este no es el mejor mtodo de estimacin de la planificacin, pero ayuda a obtener una

aproximacin, lo cual es mejor que hacerlo a ojo. Tambin proporciona una comprobacin
rpida en realidad. Si se desea desarrollar u producto prt--porter con 350 puntos de funcin
en 8 meses, tendra que pensarlo bien antes. La planificacin con el mejor caso sera de 10
meses, y la mayora de las organizaciones no son un modelo a seguir. El mtodo de estimacin
de primer orden de Jones permite saber pronto si es necesario ajustar el conjunto de prestaciones
de la planificacin o ambas.
4. Conclusin.
Como hemos podido observar en este trabajo, la estimacin de los parmetros del
software es una tarea fundamental en la gestin del proyecto. Sobre todo la estimacin de los
parmetros econmicamente sensibles, tales como el tamao del cdigo, el numero de personas
que componen el equipo de desarrollo y el tiempo necesario para finalizar el proyecto.
Esta tarea ha de abordarse al principio del proceso de desarrollo, y no puede hacerse de

manera vaga, pues una estimacin imprecisa por exceso hace que se utilicen recursos de ms,
con las consiguientes perdidas econmicas, y una estimacin imprecisa por defecto, har que en
las ltimas etapas de desarrollo del proyecto nos veamos obligados a utilizar mas recursos, que
tendremos que adaptar sobre la marcha a nuestro proyecto, con la consiguiente perdida de
tiempo, y el posible incumplimiento de plazos.
Los mtodos de estimacin estn evolucionando continuamente. Aqu se han abordado

los mas conocidos, que son los mtodos algortmicos, sin embargo se est trabajando mucho
actualmente en los mtodos del tipo no-algortmicos, basados en tcnicas de inteligencia
artificial y ms concretamente de aprendizaje mquina. De este modo aparecen mtodos que
emplean lgica difusa, razonamiento basado en casos o redes neuronales, por citar algunos. Y
todos persiguen un nico fin comn: la calidad de la estimacin.
Podramos decir que este trabajo, no es mas que una ventana sobre los mtodos y el
proceso de estimacin, y si la desplazamos un poco nos proporcionar material suficiente como
para realizar otro trabajo sobre este mismo tema.
Apndice A.
Conjuntos de datos.
En la tabla 13 tenemos un resumen del conjunto de datos de COCOMO. El conjunto de
datos completo se puede encontrar en (Bohem 1981).
Numero de puntos de Rango de productividad

datos (DSI/PM)
Total de proyectos 63 20-1250
Modo
Orgnico 23 82-1250
Semiacoplado 12 41-583
Embebido 28 20-667
Tipo
Gestin 7 55-862
Control 10 20-304
Hombre-Mquina 13 28-336
Cientfico 17 47-1250
Soporte 8 82-583
Systemas 8 28-667
Ao de desarrollo
1964-69 3 113-775
1970-74 14 20-485
1975-79 46 41-1250
Tipo de computador
Maxi 31 28-1250
Medio 7 114-583
Mini 21 20-723
Micro 4 41-3379
Leguajes de programacin
FORTRAN 24 28-883
COBOL 5 55-862
Jovial 5 45-583
PL/1 4 93-1250
Pascal 2 336-560
Otros 3 124-300
Ensamblador 20 20-667
Tabla 13
DSI: Instrucciones fuente subministradas (Delivered source instruction). Es una medida de

tamao.
PM: Personas-mes. Es una medida de esfuerzo.
En la tabla 14 tenemos el conjunto de datos Kemerer.
Proyecto Estado Esfuerzo real Duracin KSLOC FP UA_FP

(meses)
1 Finalizado 287 17 253,6 1217,1 1010
2 Finalizado 82,5 7 40,5 507,3 457
3 Finalizado 1107,31 15 450 2306,8 2284
4 Finalizado 86,9 18 214,4 788,5 881
5 Finalizado 336,3 13 449,9 1337,6 1583
6 Finalizado 84 5 50 421,3 411
7 Finalizado 23,2 5 43 99,9 97
8 Finalizado 130,3 11 200 993 998
9 Finalizado 116 14 289 1592,9 1554
10 Finalizado 72 5 39 240 250
11 Finalizado 258,7 13 254,2 1611 1603
12 Finalizado 230,7 31 128,6 789 724
13 Finalizado 157 20 161,4 690,9 705
14 Finalizado 246,9 26 164,8 1347,5 1375
15 Finalizado 69,9 14 60,2 1044,3 976
Tabla 14
Esfuerzo real: Medido en Personas-Mes.

Duracin: Medido en meses.
KSLOC: Miles de lneas de cdigo fuente.
UA_FP: Puntos de funcin sin ajustar.
FP: Puntos de funcin ajustados.
Bibliografa.
- Albrecht, Allan and Gaffney, John 1983 Software Funtion, Source Lines of Code,
and Effort Prediction: A Software Science Validation IEEE Transactions on
Software Engineering vol. SE-9 no. 6 pp. 639-648.
- Boehm, Barry W. 1981 Software Engineering Economics Prentice-Hall, Inc.

Englewood Cliffs, New Jersey.
- Boehm, Barry W. et al. 1995a Cost Models for Future Software Life Cycle
Processes: COCOMO 2.0 [Online] Disponible en:
http://sunset.usc.edu/COCOMOII/Docs/C2ASE_submitted.ps
- Boehm, Barry W. et al. 1995b The COCOMO 2.0 software Cost Estimation Model
[Online] Disponible en:
http://sunset.usc.edu/COCOMOII/Docs/ispa95.ps
- Boehm, Barry W. et al. 1995c An Overview of the COCOMO 2.0 Software Cost
Model. [Online] Disponible en:
http://sunset.usc.edu/COCOMOII/Docs/stc.ps
- Briand, Lionel C. 1997 COBRA: A Hybrid Method for Software Cost Estimation,
Benchmarking, and Risk Assessment [Online] Disponible en:
http://www.iese.fhg.de/ISERN/pub/technical_reports/isern-97-24.ps
- DeMarco, Tom 1982 Controlling Software Projects. Yourdon Press, Prentice-Hall.

Englewood Cliffs, New Jersey.
- Fenton, Norman E. and Pfleeger, Shari Lawrence 1997 Software Metrics: A

Rigorous & Practical Approach 2nd Edition. PWS Publishing company. Boston.
- Gilb, Tom 1988. Principles of Software Engineering Management. Addison-

Wesley. Wokingham.
- Gray, Andrew and MacDonell, Stephen 1997a GQM++ A Full Life Cycle
Framework for the Development and Implementationof Software Metric Programs.
http://divcom.otago.ac.nz:800/COM/INFOSCI/SMRTL/pub/papers/gray97b.ps
- Gray, Andrew and MacDonell, Stephen 1997b A Comparison of Techniques for

Developing Predictive Models of Software Metrics.[Online] Disponible en:
http://divcom.otago.ac.nz:800/COM/INFOSCI/SMRTL/pub/papers/gray97c.ps
- Gresse Christiane et al 1995. A Process Model for GQM-Based Measurement.

http://www.iese.fhg.de/Services/Projects/Public-Projects/Cemp/GQM/STTI-95-04-
E_1page_ps.ps.
- Humphrey, Watts S. 1995 A Discipline for Software Engineering Addison-Wesley.

Reading, Massachusetts.
- Jones, Carper 1996 Applied Software Measurement 2nd Edition. McGraw-Hill. New
York.
- Jones, Carper 1999 Evaluacin del tamao de los programas Investigacin y

Ciencia, no. 269 pp. 78-83.
- Juste, Ramon P. 1990 Estadstica Descriptiva. 2 Edicin. U.N.E.D. Madrid.
- Low, Grahan and Jeffery, Ross 1990 Function Points in the Estimation and
Evaluation of the Software Process IEEE Transactions on Software Engineering
vol. 16 no. 1 pp. 64-71.
- McConnell, Steve 1997 Desarrollo y Gestin de Proyectos Informticos.McGraw-

Hill. Madrid.
- MacDonell, Stephen 1994 Comparative Review of Functional Complexity

Assessment Methods for Effort Estimation.[Online] Disponible en:
http://divcom.otago.ac.nz:800/COM/INFOSCI/SMRTL/pub/papers/macd94c.ps
- MacDonell, Stephen and Gray, Andrew 1996 Alternatives to Regression Models for
Estimating Software Projects.[Online] Disponible en:
http://divcom.otago.ac.nz:800/COM/INFOSCI/SMRTL/pub/papers/macd96b.ps
- Pressman Roger S. 1993 Ingeniera del Software: Un Enfoque Prctico 3 Edicin.

McGraw-Hill. Madrid.
- Putnam, Lawrence H. 1978 A General Empirical Solution to the Macro Software

Sizing and Estimating Problem IEEE Transactions on Software Engineering vol.
SE-4 no. 4 pp. 345-361.
- Schofield Chris 1998 Non-Algorithmic Effort Estimation Techniques. [Online]

Disponible en:
http://dec.bournemouth.ac.uk/ESERG/Technical_Reports/TR98_01/TR98_01.ps.
- Sunita Devnani-Chulani et al. 1998 Calibration Approach and Results of the

COCOMO II Post-Architecture Model. [Online]
Disponible en: http://sunset.usc.edu/TechRepts/ISPA98.ps
- Spiegel, Murray R. 1993 Estadstica 2 Edicin. McGraw-Hill. Madrid.
- Troconiz, Antonio Fz. 1993 Probabilidades Estadstica y Muestreo.2 Edicin.

Tebar Flores. Madrid.
- Walkerden, Fiona and Jeffery, Ross 1996 Software Cost Estimation: A Review of
Models Process and Practice. [Online] Disponible en:
http://infosys7.infosys.unsw.edu.au/caesar/tech/zips/ctr96-1.zip
- Walkerden, Fiona and Jeffery, Ross 1998 An Empirical Study of Analogy-based

Software Effort Estimation. [Online] Disponible en:
http://infosys7.infosys.unsw.edu.au/caesar/tech/zips/ctr98-8.zip

T9899 DCerrillo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T9899 DCerrillo

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMTICA

Planificacin y Gestin de Sistemas de Informacin.

ESTIMACIN DEL SOFTWARE.

Autor: David Cerrillo

Si enfocamos todos estos conceptos estadsticos hacia nuestro caso particular de la

Formalmente una estimacin se define como la mediana de una distribucin. De este

Los ingenieros de software frecuentemente entienden mal el concepto de estimacin,

Incluso cuando el significado de la estimacin se entiende correctamente, muchos

1.2. Evaluacin de la precisin de la estimacin.

Frecuentemente, necesitamos obtener el error relativo de un conjunto de estimadores.

A modo de ilustracin, si pred(0,25)=0,4, entonces nosotros podemos decir que el 40%

DeMarco sugiere el uso de un mtodo denominado factor de calidad de la estimacin

1.3. Regresin lineal.

Tenemos en la figura 3 un ejemplo de una recta de regresin del esfuerzo de realizacin

Minimizando la suma de los cuadrados de los residuales se obtienen las ecuaciones

La tcnica de los mnimos cuadrados (least-squares LS), no hace suposiciones acerca de

Es importante mantener en la mente que la naturaleza lineal de la regresin, nicamente

1.4. Anlisis de regresin slido.

El uso de regresin slida es especialmente atractivo cuando el nmero de datos de que

1.5. Regresin multivariante.

Para la regresin lineal multivariante, se recomienda utilizar anlisis mediante mnimos

2. Gestin del proyecto de software.

2.1. Establecer el mbito.

El desarrollador del software y el cliente deben ponerse de acuerdo para definir el

2.2. Medicin y mtricas.

Recoger ms datos puede suponer mucho tiempo. Si adems de datos de coste y

Para realizar el desarrollo de forma eficiente, se necesita tener unos conocimientos

En muchos casos, las estimaciones se hacen valindose de la experiencia pasada como

Se han desarrollado varias tcnicas de estimacin para el desarrollo de software.

Se ha de establecer de antemano el mbito del proyecto.

2.4. Anlisis de riesgos.

La planificacin temporal para proyectos de desarrollo de software puede verse desde

El seguimiento es una actividad fundamental en el proceso de la planificacin software.

3. Introduccin al proceso de estimacin.

Estimar el tamao del producto (numero de lneas de cdigo o puntos de funcin).

Dar un intervalo de estimacin e ir refinando peridicamente ese intervalo, para ir

3.1. Estimacin del tamao.

La mtrica del software ms frecuentemente adoptada es la de las lneas de cdigo

Contar solo las lneas de cdigo ejecutable.

Lneas de cdigo ms definiciones de datos.

Las variantes a nivel de proyecto son:

Contar solo las lneas nuevas.

La definicin de lneas de cdigo que se adopta en cualquier organizacin particular

3.1.1. Metodologa de los puntos de funcin.

Entradas: Pantallas, formularios, cuadros de dialogo, controles o mensajes, a travs

En la Figura 7 tenemos una representacin de un sencillo programa de revisin

En la prctica el anlisis mediante puntos funcionales resulta ser mucho ms

Atributo Complejidad Complejidad Complejidad

A fin de hacer menos subjetiva la evaluacin de la complejidad, Albrecht desarroll una

Reducida: Se incluyen pocos tipos de elementos de datos, en las entradas externas, y se

En la tabla 4 tenemos representado el factor de ajuste de complejidad para archivos

La definicin de los tres tipos de complejidad se muestra a continuacin:

Reducida: Pocos registros y pocos elementos de datos.

La definicin de complejidades, para consultas de entrada es similar a la que se haca

Los 14 factores de influencia.

Por ltimo, el total de puntos funcionales se incrementa o decrece mediante un

1. Comunicaciones de datos: Este factor es concerniente a la transmisin de datos o

Uso de los 14 factores de influencia.

A continuacin veremos un ejemplo de esta secuencia de clculo. Suponemos un proyecto

Conteo Elementos Peso Resultado

Factor de Influencia Puntuacin

y el valor final de los puntos de funcin ajustados ser: