Modelos de estimación de costo y esfuerzo en proyectos de software

~
o~
't
\
if
:lIl
MODELOS DE ESTIMACION DE COSTO

Y ESFUERZO EN PROYECTOS DE SOFTWARE
11
,1
lItt
~1;;-f
:1
RAFAEL ANTONIO GORDILLO

ALBERTO NOE GIRALDO
LUIS BALDOMERO DAVILA
Alumnos del curso de Investigacin de VIII Semestre de Ingeniera de Sistemas del ICES!.
INTRODUCCION
En todo p~ecto de desarrollo de
~oftwar~_est!:'_.incluidosfacto~ que
afectan L de una u otra...torrna...eI cago
_fjD.~I~tproducto,a~ como.!m!?i~I'l.. IQ~
requerimientos de p-~.rsonal. El factor
iiellpo-tambi-- ha-de ters en cuenta a la hora de evaluar las caractersticas finales del producto. Es necesario,
por lo tanto, contarcon herramlentas-y
tc~i.~as~.~.p(ijj1!~Q:.~~1l.~_L~i.c~.~t~,
el esfuerzo y el tiempo in~El.mlJtll$ al desarrollo geiinpraQ'Q~~_~~.~!,:~
Este documento presenta una descripcin de los principales modelos utilizados en la estimacin de costo, esfuerzo y tiempo de desarrollo, as como los
parmetros y variables en que se basan estos modelos.
El principal modelo que se trata en
este documento es el Modelo COCOMO, propuesto por Barry Boehm,
puesto que, en la actualidad, es el ms
utilizado y referenciado. Este modelo no
s610 aporta un conjunto de ecuaciones
sino que, adems, permite presentar
razonadamente el porqu de sus resultados, comprobar las diferentes valo-
",1:
raciones que aportan sus tablas e identilicar claramente los factores de mayor
influencia en el proceso de desarrollo.
Ya que los modelos basan sus estimaciones en la determinacin previa del
tamao del producto, se tratar la metodologa de los Puntos de Funcin (PF)
desarrollada por A. Albrecht, que permite valorar el tamao de una aplicacin,
en las etapas previas de su desarrollo.
OBJETIVO GENERAL
Elaborar un documento sobre los diferentes modelos y herramientas que
existen para la estimacin de costo, esfuerzo y tiempo en el desarrollo de software, el cual sirva de gua, para su aplicacin, a quienes desarrollan productos
de software.
OBJETIVOS ESPECIFICOS
1. Identificar los diferentes modelos

existentes para la estimacin de costos y esfuerzos para el desarrollo de
software.
2. Identificar los principales parmetros
y variables utilizados por los modelos de estimacin.
3. Determinar las condiciones bsicas

que permitan realizar estimaciones
ms confiables.
4. Definir en qu etapas del desarrollo
de un proyecto de software son aplicables las estimaciones de los modelos.
1. ESTIMACION EN LOS
PROYECTOS DE SOFTWARE
Aunque la estimacin es ms un arte
que una ciencia, es una actividad importante que no debe llevarse a cabo
de forma descuidada. Existen tcnicas
tiles para la estimacin de costos y
tiempos. Y dado que la estimacin es la
base de tod"aSlas'demSactividadesde'
hlpfanificac6n y que la plnifi.9-clndel.
proyecto sirve .como gua pra una b.u!r
na in~geniera del software, no es ~nab
solUto a()nsejable embarcar$e.J~jn.eUa..
Un proyecto de software generalmente comienza con la produccin de un
plan de desarrollo, donde se identifica
el trabajo por ser realizado, el presupuesto y el itinerario. La efectividad de
la planeacin depende de una estimacin correcta.
Una importante faceta en el desarrollo de software es la capacidad de estimar el costo asociado con las primeras
etapas del ciclo de vida. La estimacin
de recursos, costos e itinerarios requiere experiencia y acceso a una buena
informacin histrica. Adems, esta estimacin conlleva un riesgo inherente, y
los factores que lo aumentan son:
-
La complejidad del proyecto: es

una medida relativa que se ve afectada por la familiaridad con anteriores esfuerzos.
El tamao del proyecto: es el factor ms importante que afecta la precisin y la eficacia de las estimaciones. A medida que crece el tamao,
la interdependencia entre los distintos elementos del software crece
rpidamente. Sin embargo, estimar
la fase de desarrollo del software y sus

perifricos asociados; la mquina objetivo, que es el equipo donde se ejecutar el software desarrollado, y los
dems elementos de hardware del nuevo sistema.
El grado de estructuracin del

proyecto: en este contexto, la estructuracin se refiere a la facilidad
con que las funciones pueden ser
modularizadas y a la natUraleza jerrquica de la informacin que debe
ser procesada. A medida que aumenta el grado de estructuracin, la
posibilidad de estimar con precisin
mejora y el riesgo disminuye.
Al igual que utilizamos el hardware

como herramienta para construir nuevo
hardware. utilizamos el software como
ayuda en el desarrollo de nuevo software. La primera aplicacin que se le
dio al software en el desarrollo de software fue lo que se denominaba reconstruccin. Se comenz por escribir un
primitivo traductor de lenguaje ensamblador a lenguaje mquina, y se us
para desarrollar un ensamblador ms
sofisticado. Aumentando las posibilidades de cada versin previa, los equipos
tie desarrollo fueron reconstruyendo
eventualmente el software, hasta llegar
a construir compiladores de lenguajes
de alto nivel y otras herramientas.
1.3. Recursos del software
La disponibilidad de informacin histrica tambin determina el riesgo de la

estimaciri. Cuando se dispone de una
amplia mtrica del software de proyectos pasados se pueden' hacer las estimaciones con gran seguridad, se pueden establecer mtodos para evitar anteriores dificultades y se puede reducir
el riesgo globaL
1.4. Software reutilizable

Cualquier estudio sobre recursos de
software no estar completo sino se
c.Qnsidera la reusabilidad, esto es, la
creacin y reutilizacin de mdulos
constructivos de software. Estos mdulos. constructivos deben ser catalogados
para una fcil referencia, estandarizados para una fcil aplicacin y validados para una fcil integracin.
1.1 . Recursos humanos

Es necesario evaluar el entorno de
desarrollo y seleccionar las habilidades
tcnicas que se requieren para llevar a
cabo el desarrollo. Hay que especificar
tanto la posicin dentro de la organizacin como la especialidad.
El nmero de personas requerido
para un proyecto de software slo puede ser determinado despus de hacer
una estimacin del esfuerzo del desarrollo (por ejemplo, personas-mes o personas-ao).
La mayora de los observadores de

la industria del software estn de acuerdo en que la mejora de la productividad
del desarrollo del software y de la calidad de los productos minimizar el nivel de mantenimiento. En un mundo as,
abundara el software reutilizable. los
mdulos constructivos de software estaran disponibles para la construccin
de grandes programas, con un mfnlmo
esfuerzo de desarrollo, partiendo "de la
nada".
1.2. Categoras del hardware

Durante la planificacin del proyecto
de software se deben considerar tres
categoras de hardware: el sistema de
desarrollo, que est compuesto por la
computadora que se utilizar durante
~=========================
ICESI
26
el tamao del software es un problema complicado que requiere conocimiento especfico de las fUnciones
del sistema en trminos del entorno, complejidad e interacciones. Las
medidas ms frecuentes utilizadas
son Lneas de Cdigo (LDC) y Anlisis de puntos de funcin (PF).
-- 'i,
1.5. Formas de estimacin

La estimacin del costo y del esfuerzo del software nunca ser una ciencia
exacta. Son demasiadas las variables
(humanas, tcnicas, de entorno, polticas)gue pueden afectar el costo final
del software y el esfuerzo aplicado para
desarrollarlo. Sin embargo, fa estimacin
del proyecto de software puede dejar de
ser un oscuro arte para convertirse en
una serie de pasos sistemticos que
proporcionen estimaciones con un grado de riesgo aceptable.
Para realizar estimaciones seguras
de costos y esfuerzos tenemos varias
opciones posibles:
1. Dejar la estimacin para ms adelante (obviamente, podemos realizar
una estimacin del 100% fiable, tras
haber terminado el proyecto).
2. Utilizar tcnicas de descomposicin
relativamente sencillas, para generar las estimaciones de costo y esfuerzo del proyecto.
3. Desarrollar un modelo emprico, para
el clculo de costos y esfuerzos del
software.
4. Adquirir una o varias herramientas
automticas de estimacin.
Infortunadamente la primera opcin,
aunque atractiva, no es prctica. Las
estimaciones de costos han de ser proporcionadas de antemano. Sin embargo, hay que reconocer que cuanto ms
tiempo esperemos ms cosas sabremos, y cuanto ms sepamos menor ser
. la probabilidad de cometer serios errores en nuestras estimaciones.
Las tcnicas de descomposicin utilizan un enfoque de "divide y vencers",
para la estimacin del proyecto de software. Mediante la descomposicin del
proyecto en sus funciones principales y
en las tareas de ingeniera de software
que le corresponden, la estimacin del
costo y del esfuerzo pueden realizarse
de una forma escalonada e idnea.
:::======:=:::=:=:=========~
ICES/27
f
Igualmente, se pueden utilizar los modelos empricos de estimacin como
complemento de las tcnicas de descomposicin. Cada modelo se basa en
la experienC~(datos histricos) y toma
como base: =f(vl) donde:
que requiere la descomposicin del

problema. Los datos de LDC y PF se
emplean de dos formas en el proceso
de estimacin: como variables de estimacin y como mtricas de base, recogidas de anteriores proyectos.
d: es uno de los valores estimados

(por ejemplo: esfuerzo, costo, duracin
del proyecto).
Debe tenerse en cuenta que mientras el LOC se estima directamente, 105

PF se determinan indirectamente, mediante la estimacin del nmero de entradas, salidas, archivos de datos, peticiones e interfaces externas.
VI: son determinados parmetros independientes (por ejemplo: Lneas de

cdigo o Puntos de funcin estimados).
Las herramientas automticas de

estimacin implementan una o varias
tcnicas de descomposicin o modelos
empricos. Cuando se combinan con una
interfaz atractiva hombre-mquina, las
herramientas automticas resultan muy
atractivas para la estimacin.
Cada una de las opciones viables
para la estimacin de costos y esfuerzo
del software slo ser buena si 105 datos histricos que se utilizan como base
de la estimacin son buenos. Si no existen datos histricos, la estimacin del
costo descansar sobre una base muy
inestable.
1.6. Parmetros y variables

utilizados en la estimacin
Las estimaciones que suelen realizarse para el software involucran variables
y constantes, adems de datos histricps. Se suele utilizar el supuesto volumen del software (lneas de cdigoLOC), con otras entradas que caracterizan los factores de riesgos principales
en el desarrollo.
Debido a que las estimaciones
de costo y esfuerzo para un proyecto
de software son demasiado complejas si se consideran como un solo problema, se hace necesario descomponerlo en problemas ms pequeos.
Las tcnicas de estimacin, las lineas
de cdigo LDC y los puntos de funcin PF difieren en el nivel de detalle
1.6.1. Lneas de cdigo (LOe)

La mtrica de tamao tradicional para
est~raftO:esf~e~'y-paraml!ldirproductividad ha sido' el de las lne~
de cdigo. Un gran nmero de modelos
d Elsffm'don de costo ha sido propuesto muchos de los cuales estn fundam~ntados en las lneas de cdigo (o
miles de lneas de cdigo - KLDC). Generalmente, los modelos de estimacin
de esfuerzo se componen de dos partes; la primera ofrece una base de estimacin en funcin del tamao del software y es de la forma:
E=A+B (KLDC)C
---~_._-
Oonde E es el esfuerzo estimado en

hombres-mes; A, B Y C son constantes
y KLDC es el nmero estimado en miles de lneas de cdigo en el sistema
final.
En la segunda parte, se ajusta la base
de estimacin para responder a la influencia de factores ambientales. Entre
estos factores ambientales se incluyen
el uso de tcnicas, tales como el cdigo
estructurado, el diseo Top-Oown, la
revisin estructurada y los equipos de
programadores especializados; la capacidad de personal; los requerimientos de
hardware. Por ejemplo, el Modelo
COCOMO usa lneas de cdigo elevadas a una potencia entre 1.05 y 1.20,
para determinar la base de estimacin.
ICES,-=========================
28
I
l
I
I
"'r'
El exponente especficamente depende

de la simplicidad promedio o de la complejidad del proyecto,
Todava se cuenta con un problema

ms y es el de estimar el nmero del-
Los siguientes son ejemplos de modelos tpicos:
tema, c9n!a!lQ,Q.s1oconJaIDfonll-ci9n
proveniente .ele laJase de rG'I' lerimien':.c
to;> o diseiio...$i los modelos para cost'os, basados en el tamao, son utilizados, es necesario tener la capacidad de
predecir el tamao del producto final tan
pronto como sea posible. Es aqu donde entra en juego la recoleccin de datos. Inlortunadamente la estimacin del
tamao, usando las mtricas LOC, depende de experiencias previas con proyectos similares, ms especficamente
de datos histricos.
=5.2(KLDC)O.91.
Modelo Wlaston-Flix
E=5.S+0.73(KLDC)'16 Modelo Bailey-Basili

E=3.2(KLDC)1.05
Modelo COCOMO
Bsico
E=3.0(KLDC)"2
Modelo COCOMO
Intermedio
.E=2.8(KLDC)'2
Modelo COCOMO
Avanzado
ne~s req~e!.!~liBta.~~rronill:.illis
UrmJo:ma Ele estimar el tamao dQj..

proyecto, en lneas de cdigo LOC, conLa definicin de KLDC es importante siste en descomponer el proyecto en su.
a la hora de comparar estos modelos.
fu~nes principales y se estiman la~
Algunos modelos incluyen lneas de coLOC para cada una de stas. Las estimentarios y otros no. Ja definicin de
macones de las funciones se combinan
qu tipo de esfuerzo se h~ es.!L~9_~ para producir una estimacin global del
iguatmenteimportante, ya .qua.eLes1uer.proyecto. A partir de 105 <:!~.!.~~ .b!~~!i
2Ose'puede asumir corno la soJa codifiCO$, .seesfuna-taiiiO::l"aor optimista,
caCiri' como el anlisis total (el dise:- m~~"p.r.o.~l~~.~Eomo el ~jst~
o, la codificacin y la fase da pruebas
Loc. Si no se cuenta con datos histricOiijiamente). Esto nos indica que la COS queda ms remedio que recurrir
'.comparaCin de modelos que usan cria la intuicin para los valores antes menterios distintos; en cuanto a los mismos
cionados. Luego, se calcula el valor
. parmetros, es relativamente difcil.
agregado del LDC, el cual ser una
Hay numerosos problemas con e~
media ponderada de las estimaciones
uso de .IJneas..aecdlgQ como lIoi$d
pesimistas (a), ms probable (m) yoptia-i.8l:Ma para el tamaijo !l~;>~.
mista (b), as:
Erprimero consiste en. esta~!~~
cmfinicin exacta de.l?q~~J~. lJOa Ioea
E=(a+4m+b)/6
'(f"cdigo y, a la v.f3z,9.u.!l~~.~~l!1i:.
CI6n's~~~~~ta~jY.msalmente~
Por ejemplo, consideremos un pa~ctcon las lneas de cdigo es sQ. quete de software por desarrollar, para
dependencia respecto d~Uenguaje utiuna aplicacin de diseo asistido por
iiiado. No es posible comparar directacomputador (CAD). Supongamos que
ietej:>foyectos desarrollad.~s-~nJeD=_
las funciones principales para este proguajes diferel'l!~~:p6i"ejTlplo, el tiemyecto son:
po por lnea para un lenguaje d~ alto
Interfaz de usuario y facilidad de conivel pueaesermayor que para uno de
trol.
bafnfverPedeqnlo sea posible
lglartrrrmnimo de lneas de cdigo en
Anlisis geomtrico bidimensional.
un lenguaje de alto nivel para una funAnlisis geomtrico tridimensional.
cin de un lenguaje de bajo nivel.
E=5.288(KLDCt044
Modelo Doty.
:::=::::==:=::::::========~/CE'i,
control de perifricos, para el cual se tiene un valor optimista de 2.000 LDC, un

valor probable de 2.100 LDC y un valor
pesimista de 2.450 LOC. Aplicamos entonces la funcin del valor esperado y
obtenemos el siguiente resultado:
Control de perifricos.
Mdulos de anlisis de diseo.
El paso siguiente consiste en establecer los valores optimista, probable y
pesimista para cada una de las funciones anteriores. Tomemos por ejemplo el
Funcin
Optimista
Probable
Pesimista
Esperado
2.000
2.100
2.450
2.140
Control de perifricos
ses del desarrollo. Ya que los puntos de

funcin estn directamente relacionados
con la especificacin de requerimientos,
cualquier cambio en stos puede ser
seguido fcilmente por una nueva estimacin. ~ro, los usuarios no especializados en el sistema tienen una m~
jfcliipfnSiOriaejStn mi.diimdo..
Yos_p~!i~~_~J~~
1.7. Estimacin del costo
del software
Bsicamente, la estimacin del costo se hace multiplicando las unidades
del tamao del software para factores
apropia.dos de productividad. Muchas
ecuaciones del costo tienen la forma:
Realizamos el mismo proceso con las

dems funciones Y construimos una tabla como la siguiente:
Funcin
Optimista
Probable
Pesimista
Esperado
1.800
4.100
2.400
5.200
2.650
7.400
4.600
2.000
6.600
6.900
2.100
8.500
6.600
2.450
9.800
2.340
5.360
6.800
2.140
8.400
Interfaz de usuario y facilidad de control

Anlisis geomtrico bidimensional
Anlisis geomtrico tridimensional
Control de perifricos
Mdulos de anlisis de diseo
25.060
Total
Sumando verticalmente, en la columna del valor esperado, se establece una
estimacin de 25.060 LOC.
1.6.2. Anlisis del punto de funcin

El ~nalisi~el.Qunto.Ee funcin ~
mtodo de cuantificacin del ram~?_1_
comPlejidad deI.i9.!!'I!~.~~-~~J.r"!J!.!lQ.
O's-nmCo~._q!!~J~t!~te~
ai-usuarlo. La funcin entregada no est

refacionada con el lenguaje o herramientas utilizadas en el desarrollo del proyecto. Este anl~~~~seado para _
aplicacio~~..9~!!!~~~;J]o es apropIado p'ara aplicaciones de tipo tcnico o
cientfico, ya que stas tratan con
algoritmos compiejos, que los puntos de
funcin no estn diseados para manejar.
En este mtodo se contabilizan los
varios tipos de funcin de usuarios, los
El enfoque de puntos de funcin (PF)

tiene caractersticas que se sobreponen
a las deficiencias en el uso de las lneas
de cdigo, mencionadas anteriormente.
Primero, los puntos de funcin so!l.!n:. __
dependientes de la metodologa~
herramie-ntaS'
-lenguajes utilizados
en el desarrollo del proyecto. Segunao;::
~yntos de 1unci6n .p~de~;e-atimar::__
se con base en la especlhcaclon~_c1!'!.!Q~
reqerimientos o en ~! cj!~eo; a<!~ms)
hacen posible la estimacin del esfuerzo para el proyecto en las primeras fa-
y'los
~=========================
ICESI
30
cuales se dividen en datos y transacciones. Los tipos de funcin de datos

corresponden a Archivos lgicos internos yArchivos externos de interfase. Los
tipos de funcin de transacciones corresponden a entradas, salidas y consultas externas. Todos estos trminos
sern tratados ms adelante.
ware. En la resolucin de cada tarea del

proyecto se aplica un nmero determinado de personas/da,personas/mes o
personas/ao. Se asocia un costo a
cada unidad de esfuerzo y se deriva el
costo total estimado.
Al igual que las tcnicas lOC y PF, la
estimacin del esfuerzo comienza con
una delimitacin de las funciones del
software, obtenidas del mbito del software. Para cada funcin debe realizarse una serie de tareas de ingeniera del
software, tales como anlisis de requisitos, diseo, implementacin y pruebas.
. Se aplican las tarifas laborales (costo/
unidad de esfuerzo) a cada una de las
tareas de ingeniera del software.
E=pLe donde:
En el ltimo paso se calculan los costos y el esfuerzo para cada funcin y se

deriva el costo total del proyecto.
E=esfuerzo
p=aJuste de productividad
L;"tamao en lneas de cdigo
c>1, una constante.
El ajuste de productividad puede ser
un factor simple o compuesto de factores, tal como ap!rece en el Mtodo
CCCOMO.
<::kas principales fa~.~!es para determinar la productividad son, en su orden
del persade importancla,la
ni,la:corpejidad de la aplicacin, el
s.~ftw,ereutiliZabieYktecaaloga apli-
caeacldaa
~d.a-
1.9. Modelos empricos

de estimacin
Un modelo de estimacin utiliza frmulasderi,idas l"!!pjricarn.rm.te p~tra_
preaecrl05diiti$- gue s~JegLJi~_~~fl.l-l~n
eT paso- pJ~llficaddeLproye.ctQd.e
softWare. Los datos empricos que somayora de los modelos se
obtienen de una muestra de proyectos
limitada. Se identifican cuatro clases de
modelos: mdefos:~r.taDJej=ii.~
de
prtlmia--
tlcos;mode1o:~-:m:ulvariabJes
esbili-
cos, mocielos muJtivariables'dinml-
cosymodelos tericos.
La productividad se ve muy influenUn modelo univariable esttico toma

ciada por el tipo de personal escogido
la forma:
para realizar el trabajo; luego est el tipo
Recurso =c 1 x(caracterstica estimada)c 2
de trabajo ejecutado. Por ejemplo,
CCCOMO prefiere el ajuste de la esti- (donde el recurso podra ser el esfuermacin del tamao (OSI) para contabiJi,
zo, la duracin del proyecto, la cantidad
zar la reutilizacin antes de aplicar cualde personal o las lneas requeridas de
quier factor de productividad.
documentacin del software. las cons
antes c l y c 2 se deriVan de los datos
1.8 Estimacin del esfuerzo
apilados de los anteriores proyectos_
La estimacin del esfuerzo es la tca caracterstica estimada puede ser la
antidad de lneas del cdigo fuente, el
nica mas utilizada ?!_<2.l'!IE.~lar el costo_
ce un proyecto de ingeniera del soft
sfuerzo (si ya est estimado) u otra
...
--
-.".
-~---
--------
Icesl
:::::::::::::::::==========~
31
caracterstica del software. Un ejemplo

de este tipo de modelo es la versin
bsica del modelo de costo constructivooCOCOMO..
(
/Los modelos multivariables esttico~ emplean los datos histricos para

btener relaciones empricas. Un modede esta categora toma la forma:
Recurso=clle. + c.2e2+...
onde el es la caracterstica isima del
software y cll + c.2 con constantes obtenidas para el'
{Los modelos multivariables dinmicos proyectan los requisitos de recur\..sos como una funcin del tiempo. Los
recursos se definen en una serie de pasos consecutivos en el tiempo, que asignan cierto porcentaje de esfuerzo(o de
otro recurso) a cada etapa del proceso
de ingeniera del software. Este modelo
incluye una "curva continua de utilizacin del recurso" como hiptesis, y a
partir de ella obtiene ecuaciones que
modelizan el comportamiento del recurso.
El modelo terico de recurso examina el software desde un punto de vista microscpico; es decir, las caractersticas del cdigo-fuente (por ejemplo:
el nmero de operadores y operandos).
2. MODELO COCOMO
Es el modelo ms completo existente hasta el momento y ha sido propuesto por Barry Boehm en su libro Software
Engineering Economics. En este libro,
Boehm trata el ciclo de vida del software
desde una perspectiva econmica, en
trminos del tiempo y el esfuerzo requeridos para completar cada fase del ciclo
de vida del software. Establece una relacin matemtica que permite estimar
el esfuerzo y el tiempo requerido para
desarrollar un proyecto, en funcin del
nmero de instrucciones-fuente desarrolladas.
2. COCOMO considera slo las fases

del perodo de desarrollo, comprendidas desde el comienzo de la
fase de diseo del producto hasta
el final de la fase de integracin y
prueba.
Sin embargo, la aplicacin del modelo

a otros proyectos, en una amplia variedad de entornos, indicaron que un nico modo de desarrollo no era suficiente
para explicar las variaciones pbservadas, lo que indujo a introducir en el modelo actual tres modos de desarrollo, de
forma que sus predicciones pudiesen
aplicarse, con un buen grado de precisin, en cualquier entorno de desarrollo.
.
Los costos, esfuerzo y tiempo de las

otras fases (planificacin, especificaciones, mantenimiento, etc.) deben
estimarse por separado.
3. Los costos estimados mediante este
Boehm propuso entonces una jerarqua de modelos de estimacin para el

software denominada COCOMO, por
Constructive COst MOdel, o Modelo
Constructivo de Costo; dicha jerarqua
de modelos est constituida as:
Modelo bsico
Modelo intermedio
Modelo avanzado o detallado.
Para poder aplicar adecuadamente
estos modelos se deben tener en cuen-
ta las siguientes consideraciones:
1. El factor principal sobre el que s
basan las estimaciones de costos es
el tamao del producto, es decir, el.
nmero de instrucciones-fuente entregadas DSI (Delivered Source
Instructions).
Este trmino incluye todas las instrucciones creadas por el personal
asignado al proyecto, y procesadas
en cdigo mquina,-~xcluyendo las
lneas de comentarios.
Igualmente, deben considerarse las
sentencias de Lenguaje de Control
de Trabajos (JCL), las sentencias de
formatos y las declaraciones de datos.
~==========================
ICESI
32
Las instrucciones se definen como

lneas de cdigo y, por tanto, toda
lnea que contenga dos o tres sentencias se considerar como una
soja instruccin.
El modelo inicial, que tena un nico

modo de desarrollo, se ajust utilizando
los datos correspondientes a doce proyectos completos. El modelo obtenido
fue evaluado contrastando sus resultados frente a los obtenidos en otros 36
proyectos.
.(
~
I
I
I
I
r
i
modelo no incluyen los correspondientes a las actividades de formacin del usuario, la instalacin y los
trabajos de conversin, aunque estas actividades se realicen durante
la etapa de desarrollo. Se cubren
todos los costos directos del proyecto; es decir, la gestin del proyecto,los trabajos de documentacin y
librera, pero se excluyen los correspondientes al personal del centro de
cmputo, las secretarias, los subalternos y los altos directivos que no
estn directamente involucrados en
el desarrollo del proyecto.
4. La unidad de esfuerzo HM (HombreMes) supone un total de 152 horas
de trabajo por persona, valor tomado basndose en la experiencia
prctica, que considera aspectos
tales como vacaciones, permisos,
festivos, licencias, etc.
Para convertir las unidades HM a
otras unidades empleamos las siguientes equivalencias:
1 HM= 152 MH
1 HM = 19 MD
(MH: hombre-hora)
(MD: hombre-da)
1 HM = 1 MY/12
(MY-Hombre-ao).
5. Se supone que despus de la fase

de especificacin de requerimientps,
stas no cambiarn substancialmente, aunque evidentemente esto

ser inevitable. En el caso que se
produzcan modificaciones significativas, se estara obligado a revisar
las estimaciones anteriores.
6. El modelo avanzado del COCOMO

asume que los factores que influyen
sobre los costos de desarrollo dependen de la fase en que aparecen.
El COCOMO bsico y el intermedio
no consideran los factores que afectan el costo, excepto para distinguir
entre desarrollo y mantenimiento.
7. En los costos por fase se incluyen
todos aquellos que se produzcan
durante ese espacio de tiempo. Es
decir que los costos relativos a los
trabajos de actualizacin del plan de
integracin y prueba, la terminacin
del plan de pruebas de aceptacin,
la actualizacin de la documentacin, etc., se incluyen dentro de los
costos de la fase de diseo detallado.
8. Para convertir las estimaciones obtenidas de hombres-mes (HM) a unidades monetarias, la mejor forma es
aplicar un valor medio de unidades
monetarias, por unidad de esfuerzo,
para cada una de las fases en el
desarrollo.
2.1. Modos de desarrollo
Como se mencion anteriormente,
eOCOMO comprende tres modos de
desarrollo que de algn modo reflejan
las diferentes condiciones o entornos de
desarrollo, y aunque matemticamente
pueden expresarse en forma similar,
conducen a estimaciones diferentes;
estos modos son los siguientes:
2.1.1. Modo orgnico

Este modo abarca slo los proyectos relativamente pequeos y sencillos;
en stos trabajan pequeos equipos,
con buena experiencia en otros proyectos relacionados con la misma organi-
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : - : 33
ICESI
zacin y con pleno conocimiento de

cmo el sistema en desarrollo contribuir
con los objetivos de la organizacin.
Esto significa que la mayora de las
personas pueden contribuir de forma
efectiva a la terminacin puntual de cada
una de las etapas, sin necesidad de
mucha comunicacin, para determinar
con precisin las tareas que cada uno
debe desarrollar en el proyecto. Existe,
por lo tanto, facilidad para establecer los
requisitos y las especificaciones de cada
una de las fases del proyecto.
Otros factores catactersticos de este
modo son:
-
Un ambiente generalmente estable

de desarrollo, con muy poca ocurrencia de nuevo hardware y procedimientos operacionales.
Mnima necesidad para innovar arquitectura de procesamiento de datos o algoritmos.
Muy pocos proyectos, en este modo,
han desarrollado productos con ms
de cincuenta KLDC.
2.1.2. Modo semilibre

Representa un estado intermedio
entre el modo orgnico y el modo restringido. Son proyectos intermedios en
tamao y complejidad en los que equipos de trabajo, con variados niveles de
experiencia, deben satisfacer requisitos
poco o medio rgidos.
Con respecto a la experiencia del
equipo de trabajo, se consideran las siguientes situaciones:
Todos los miembros del equipo tienen un nivel intermedio de experiencia en sistemas relacionados con el
proyeCto.
El equipo de desarrollo est formado por una mezcla de gente experta
e inexperta.
Los miembros del equipo tienen experiencia en algunos de los aspec-
tos del sistema que se pretende desarrollar, pero no en todos.

Un tpico proyecto, en modo semilibre, puede ser un sistema de proceso de transacciones con pocas interfaces rigurosas (por ejemplo con la
terminal hardware) y algunas otras
interfaces muy flexibles (naturaleza y
formatos de presentacin de mensajes).
El trmino semilibre hace referencia a
la flexibilidad parcial que presenta un
proyecto de este tipo, el cual generalmente sobrepasa las 300 KLDC.
2.1 .3. Modo restringido
La principal caracterstica de un proyecto, en este modo, es la necesidad
de operar dentro de fuertes restricciones. El trmino incorporado se refiere
bsicamente al hecho que el producto
debe operar dentro de un complejo ,altamente interconectado de hardware,
software, reglas y procedimientos
operacionales, como es el caso, por
ejemplo, de un sistema de control de trfico areo.
En condiciones de modo de desarrollo restringido, el costo de modificar parte del complejo sistema es tan alto, que
sus caractersticas se podran considerar inmodificables. Como resultado, este
modo de proyecto no siempre tiene la
opcin de realizar fcilmente cambios de
software, por ms sencillos que sean,
debido a la modificacin de los requerimientos y la especificacin de las
interfaces. Por lo tanto, el proyecto debe
emplear ms esfuerzo en realizar y adecuar los cambios y correcciones, y en
asegurar que el software actualmente
satisfaga las especificaciones. Tambin
se debe emplear ms esfuerzo en verificar que los cambios se realicen correctamente.
Los proyectos, en este modo, generalmente abarcan reas ms amplias y
menos conocidas que en los casos anteriores.
~==========================
ICESI
34
Los modelos COCOMO calculan

esencialmente el costo a la entrega, que
puede ser una pequea proporcin del
costo total de la vida del software.
2.2. Modelo COCOMO bsico
Es un modelo univariable, esttico,
que calcula el costo y el esfuerzo de un
proyecto de software, exclusivamente en
funcin de su tamao, expresado en lneas de cdigo (KLDC) estimadas. Este
modelo es apropiado para una pronta y
rpida estimacin del costo del software,
pero su precisin es necesariamente limitada, porque carece de factores que
involucren los aspectos del hardware, la
calidad del personal, la experiencia, el
uso de modernas herramientas y tcnicas y otros tributos del proyecto que tienen una significativa influencia en los
costos
del software.
,
La siguiente tabla presenta las
ecuaciones para los tres modos de desarrollo del modelo COCOMO bsico:
Modo
Esfuerzo
Orgnico
E=2.4(KLDC)105 T=2.5(E)038
Semilibre
E=3.0(KLDC)1.12 T=2.5(E)o.35
Tiempo estimado
Restringido E=3.6(KLDC)120 T=2.5(E)o.32

La ecuacin E=2.4(KLDC)1.05 es utilizada para la estimacin de hombresmes (HM) requeridos para desarrollar el
tipo ms comn de productos de software, en trminos de miles de instrucciones-fuente entregadas KLDC.
Se obtiene tambin que T=2.5
(HM)o.38 es una ecuacin para estimar
el tiempo de desarrollo, en meses.
Estas ecuaciones son aplicables a la
mayora de los proyectos de software,
de tamao mediano/pequeo, desarro- .
liados en un ambiente de software familiar. Ejemplo:
Du Bridge Chemical lnc. es una importante compaa de productos qumicos, que planea desarrollar una aplica-
cin para mantener la informacin sobre materias primas. Se desarrollar una

aplicacin por un equipo propio de programadores y analistas, quienes han
desarrollado aplicaciones similares durante varios aos. Adems, es un buen
ejemplo de un software de modo orgnico. Un estudio inicial ha determinado
que el tamao del programa ser aproximadamente de 32.000 lneas de cdigo
(32 KLDC). De las ecuaciones bsicas
obtenemos las caractersticas del proyecto, que son:
esfuerzo:
E=2.4(32)'05
=91 hombres-mes
productividad:
32.000 LDC191 HM=352

LOC/HM
tiempo de
desarrollo:
T=2.5 (91)38= 14 meses,
y el valor medio del nmero de personas que, de tiempo completo, seran

necesarias para desarrollar el proyecto
es:
PE= 91 HM14 meses = 65 FSP
FSP: Ful/-time-equivalent Personnel:

personal de tiempo completo para el
software.
E=91 HM es el esfuerzo total en hombres-mes necesario en el proyecto.
T=14 meses es el tiempo de desarrollo, expresado en meses.
El Modelo COCOMO ofrece perfiles
obtenidos de aplicar las anteriores
ecuaciones a proyectos de tamao
estndar. Los tamaos estndares, utilizados por el modelo, son los siguien- .
tes:
Pequeo 2.000 lneas de cdigo
Intermedio 8.000 lneas de cdigo
Medio 32.000 lneas de cdigo
Grande 128.000 lneas de cdigo.
En la siguiente tabla puede observarse que un proyecto pequeo es esencialmente un trabajo de una persona,
=========================~
ICESI
35
mientras que un proyecto considerado

grande requiere un nivel medio de 16
personas. Cabe anotar que para un proyecto pequeo el esfuerzo estimado de
5 HM hace referencia al desarrollo de
Tamao
Pequeo 2 KlDC
Intermedio 8 KlDC
Medio 32 KlDC
Grande 132 KlDC
Esfuerzo (HM)
yendo, por lo tanto, el esfuerzo de documentacin, las pruebas, las correcciones, etc.
Productividad (lnealHM)
400
376
352
327
5.0
21.3
91.0
392.0
Obviamente, el tiempo para desarrollar

un programa, por ejemplo de 2000 instrucciones para uso personal, ser menor, ya que ste no requerir de muchas
exigencias, mientras que si el mismo se
desarrolla como un producto profesional, entonces requerir un poco ms de
tiempo y esfuerzo.
2.2.1. Distribucin del esfuerzo
y tiempos por fases
Es de esperar qiJe las estimaciones
para cada una de las fases del proyecto
difieran considerablemente de un modo
de desarrollo a otro. La distribucin por
fases vara en funcin del tamao; los
proyectos de gran tamao precisan
Distribucin del esfuerzo estimado (%). Modo semlllbre
2.000 instrucciones del producto, inclu-
T1empo(meses)
PE
4.6
8.0
14.0
24.0
1.1
2.7
6.5
16.0
mayor tiempo y esfuerzo para desarrollar actividades, tales como la integracin y la prueba, mientras que pueden
reducir el tiempo durante la fase de programacin, distribuyendo esta actividad
entre un nmero mayor de programadores. Los pequeos proyectos presentan una distribucin ms uniforme y tienen que dedicar, relativamente, ms recursos a las fases de diseo y programacin que a las de prueba e integracin.
Las siguientes tres tablas presentan
los porcentajes de distribucin del esfuerzo de desarrollo, entre las distintas
fases, en los tres modos de desarrollo.
FASE
TAMAO (KLDC)
Planificacin y especificaciones
Diseo del producto
Programacin
Pequeo
Interm.
Medio
Grande
Muy grande
(2)
(8)
(32)
(128)
(512)
7
17
17
17
61
26
35
58
25
33
25
7
17
55
24
31
28
7
17
52
23
29
31
64
Diseo detallado
Codificacin y pruebas de unidades
Integracin y pruebas
27
37
19
22
Distribucin del esfuerzo estimado ('Yo). Modo restringido

Fase
Tamao (KLDC)
Pequeo
Interm.
Medio
Grande
Muy grande
(2)
(8)
(32)
(128)
(512)
8
18
57
27
30
25
18
54
26
28
28
8
18
51
25
26
31
8
18
48
24
24
34
Diseo del producto
18
Programacin
60
Diseo detallado
28
32
22
Codificacin y prueba de unidades

Las siguientes tres tablas presentan los

porcentajes de tiempo de desarrollo,
para cada una de las fases, en los tres

modos de desarrollo.
Distribucin del esfuerzo estimado (%). Modo orgnico

Distribucin del tiempo (%). Modo orgnico
FASE
Pequeo
(2)
Diseo del producto
Programacin
Diseo detallado
Codificacin y prueba de unidades
6
16
68
26
42
16
TAMAO (KLDC)
Grande
Interm.
Medio
(8)
6
16
65
25
40
19
(32)
6
16
62
24
38
22
(128)
6
16
59
23
36
25
Muy grande
Tamao (KLDC)
Fase
(512)
Pequeo
Interm.
Medio
Grande
Muy grande
(2)
(8)
(32)
(128)
(512)
10
11
12
13
19
Diseo del producto
19
19
19
Programacin
51
59
22
55
63
18
26
30
~ES:/~========================:
ICESI
:=========:::::::==========~
37
Distribucin del tiempo (%). Modo semlllbre

Conceptos
Fase
Fases
Tamao (KLDC)
Pequeo
(2)
Interm.
(8)
Medio
(32)
Grande
(128)
Muy grande
(512)
16
18
20
22
24
Diseo del producto
24
25
26
27
28
Programacin
56
52
48
44
40
20
23
26
29
32
Esfuerzo
(HM)
Tiempo
(Meses)
Distribucin del tiempo (%). Modo restringido

Tamao (KLDC)
Fase
Pequeo
(2)
Interm.
(8)
Medio
(32)
Grande
(128)
Muy grande
(512)
24
28
32
36
40
Diseo del producto
30
32
34
36
38
Personal
8.0
Equiv.
(Pe)
Programacin
48
44
40
36
32
22
24
26
28
30
Pequeo
Intermedio
Medio
Grande
(2 KLDC)
(8 KLDC)
(32 KLDC)
(128 KLDC)
Planificacin y requisitos
Diseo del producto
Programacin
Diseo detallado
Codificacin y prueba
de unidades .
0.3
0.8
3.4
1.3
2.1
1.3
3.4
13.8
5.3
8.5
5
15
56
22
34
24
63
231
90
141
0.8
4.1
20
98
Esfuerzo total
5.0
21.3
91
392
(Planificacin y requisitos
Diseo del producto
Programacin
0.5
0.9
2.9
0.8
0.9
1.5
4.7
1.8
1.7
2.7
7.7
3.6
Tiempo total estimado
4.6
8.0
Planificacin y requisitos
0.6
1.4
2.9
Diseo del producto

Programacin
1ntegracin y pruebas
0.9
1.2
1.0
2.3
2.9
2.3
5.6
7.3
5.6
Productividad (LDC/HM)
Pero cmo usar estas tablas?

Retomando el ejemplo anterior, vamos
a calcular el esfuerzo y el tiempo durante la fase de programacin. Recordemos
que en este proyecto se consideran 32
KLDC estimadas; por lo tanto, de acuerdo con la tabla para el esfuerzo en el
modo orgnico, tenemos que el porcentaje para el esfuerzo estimado, en programacin para 32 KLDC, es del 62%;
entonces:
Eprog=(O.62)(E)
Eprog=(O.62)(91 HM)=56 HM
De la misma manera, el porcentaje
de tiempo destinado a la fase de programacin, para 32 KLDC, en el modo
orgnico, es del 55%; por lo tanto:
Tprog=(O.55)(T)
Tprog=(O.55)(14 meses)=7.7 meses
El nivel medio de personal equivalente sera de:

Pe=(56 HM)/(717 meses)
=7.3 hombres.
Un proceso similar se puede realizar
con las otras tablas, para los otros modos de desarrollo, de acuerdo con el tamao estimado del producto cuando
ste se ajusta a los tamaos estndares.
La siguiente tabla muestra los valores nominales obtenidos de aplicar los
porcentajes de las tablas de esfuerzo y
tiempo de desarrollo, en el modo orgnico, a los proyectos de tamao estndar. Adems, se muestran los valores relativos a la productividad del proyecto y el personal medio equivalente
necesario en cada fase.
~=========================
ICESI
38
400
De igual manera, aplicando 105 porcentajes y ecuaciones adecuados para los

modos semilibre y restringidos, obtenemos tablas similares a la anterior
para proyectos de tamao estndar.
Pequeo
(2 KLDC)
352
24
14
19
14
327
donde se totalizan los valores de esfuerzo, tiempo, productividad y personal equivalente, para todos los modos
de desarrollo, en proyectos de tamao estndar. Por lo tanto, no se discrimina por fases.
A continuacin se presenta una tabla
Esfuerzo (HM)
376
14
3.1
4.6
12.2
7.2
Intermedio
Medio
(8 KLDC) (32 KLDC)
Grande Muy grande

(128 KLDC) (512 KLDC)
Orgnico
5.0
21.3
91
Semilibre
6.5
31
146
687
3.250
Restringido
8.3
44
230
1.216
6.420
Productividad (KLDCIHM)
Pequeo
(2 KLDC)
Intermedio
Medio
(8 KLDC) (32 KLDC)
392
Grande Muy grande

(128 KLDC) (512 KLDC)
Orgnico
400
376
352
327
Semilibre
308
241
258
182
219
186
158
139
105
80
Restringido
;bE~
Ttempo (meses)
Pequeo
(2 KLDC)
Intermedio
Medio
(8 KLDC) (32 KLDC)
4.6
4.8
4.9
Orgnico
Semilibre
Restringido
Personal equivalente -PE
(Hombres)
Pequeo
(2 KLDC)
Orgnico
Semilibre
Restringido
8.0
8.3
8.4
24
24
24
Intermedio
Medio
(8 KLDC) (32 KLDC)
1.1
1.4
1.7
2.7
3.7
5.2
2.2.2. Distribucin del esfuerzo

por actividades
Por ltimo, una vez determinada la

distribucin del esfuerzo entre las fases
principales del ciclo de vida de un producto software, es necesario conocer
cmo se distribuye entre las diferentes
actividades, de forma que sirva de refprencia para:
-
14
14
14
preparar planes de distribucin de

los recursos y
6.5
10
16
Distribucin del esfuerzo por actividades. Modo orgnico
Grande Muy grande

(128 KLDC) (512 KLDC)
FASE
PlaniflC8cin
y requisitos
42
41
Tamao
77
157
adecuar la estructura de la organizacin al tamao de los equipos dedicados a cada una de las actividades que, en proyectos de gran tamao, ser necesario modificar a
medida que avanza el proyecto, en
funcin de los cambios de actividanes y segn la fase en que se encuentre el proyecto.
Programacin
Integracin
y prueba
PIMGMG PIMGMG PIMGMG PIMGMG PI MG MG
('Yo) fase completa
8 8 8 8 8
P I M G PI M G P
69 65 62 25 16 19 22 25
M G
46
15
Diseo del producto
20
40
10
14
Programacin
14
58
34
48474645
Plan de pruebas
Verificacin yvalidacin
34
10111213
Oficina de proyectos
15
11
GClCC
Manuales
FAse
Planificacin y
requisitos
Diseo del
producto
Programacin
Tamao
MG
G MG
G MG
(%) Fase completa
17
t7
17
17
17
64
61
58
51
52
Anlisis de requisitos
48 47
46
45
44
12.5 12.5 12.5 12.5 12.5
Diseo del producto
16 16.5 17 17.5 18
41
Programacin
2.5 3.5
4.5
5.5
6.5
12 12.5 13 13.5 14 56.5 56.5 56.5 56.5 56.5
Plan de pruebas
2.5 3
3.5
4.5
4.5
5.5
6.5
4.5
5.5
Verificacin yvalidacin 6 6.5
7.5
6.5
7.5
7.5
a5
13
12
11
10
7.5
6.5
5.5
2.5 2.5
2.5
6.5
6.5 6.5
5.5
ACTIVIDAD
18181818 18 60 57 54 5148 22 252831 34
ACTIVIDAD
4 4 4 4 4
50 48 46 44 42
10 10101010
33333
2 222
Diseo del producto
12 13 14 15 16 42 424242 42
66666
4 4 4 4 4 12 1212 1212
Programacin
2 4 6 810 10 11121314 55 55 55 55 55
3236l44 48 42 43 43 4445
Plan de pruebas
2 3 4 5 6
4 5 678
45678
3 344 5
4 4 5 6 7
Verificacin yvalidacin
6 7 8 910
6 7 8 910
8 910 11 12
30 28 25 23 20
12 1314 1414
16
Desarrollo
Distribucin del esfuerzo por actividades. Modo semllibre
Desarrollo
'Tamao
Integracin
y prueb
Las siguientes tablas muestran la distribucin por actividades, dentro de cada

una de las fases principales.
FASE
Diseo del
producto
P r MG
Programacin
ACTIVIDAD
Distribucin del esfuerzo por actividades. Modo restringido
Planificacin y
requisitos
MG
(%) Fase completa
Grande Muy grande

(128 KLDC) (512 KLDC)
16
29
51
P I
Diseo del
producto
16 14 12 10 8 15 1311 9 7
9 8 7 6 5
10 9 8 7 6 10 9 8 7 6
15.514.5 13.5 12.5 11.5

3.5 3
GC'CC
5 4 4 4 3
4 3 3 3 2
87776
10 9 9 9 8
8 7 7 7 6
GCICC
MarJJales
7 7 6 5 5
9 9 8 5 5
77655
9 9 8 7 7
8 8 7 7 6
Manuales
~ES:/~========================:
2.5
5.5
41
41
7.5
41
41
=========================~.ICESI
41
Distribucin del esfuerzo por actividades. Modo semilibre

(Continuacin)
Eprog=(O.644){E)
Eprog=(O.644)(35)=22.5 HM
FASE
De la misma forma podemos obtener

el porcentaje de tiempo de programacin, interpolando los porcentajes de
tiempo, del 59% para 8 KLDC y del 55%
para 32 KLDC.
Integracin
y pruebas
Tamao
(0/0) Fase completa
19
22
M
25
Desarrollo
28
GM
31
MG
GC/CC
Manuales
2.5
5
33
2.5
32
8.5
8.5
2.5
5
33
2.5
31
8
8
2.5
2.5
5
39
2.5
5
41
32=8
8
7.5
2.2.3. Proyectos de tamao no

estndar (InterpolacI6n)
En el caso que el tamao estimado
del producto no se ajuste a los tamaos
estndares, podemos obtener el perfil
del proyecto por interpolacin de los
datos de los proyectos estndares de
tamao inferior y superior.
3.5
27
6.5
7.5
5
13
45
4
11
8.5
6.5
5
13
45
4
12
8
6
5
5
5
13
13
13
44.5 44.5 44.5
4.5
5.5
5
13 13.5 14
7.5
7
6.5
6
5.5
6
6.6
37
3
3
29.5 28.5
7.5
7
Por ejemplo, supongamos que deseamos obtener el esfuerzo de desarrollo en la fase de programacin de un
producto de software, cuyo tamao fijamos en 12.800 Ifneas fuente en el modo
orgnico.
Aplicando las ecuaciones de estimacin del esfuerzo total y el tiempo de
desarrollo, tenemos:
Esfuerzo total E=2.4(12.8),05=35 HM
Tiempo de desarrollo T=2.5(35)38
=9.7 meses
Para obtener el esfuerzo en la fase
de programacin, tenemos que referirnos a los proyectos de 8 KLDC y 32
KLDC. El porcentaje sobre el esfuerzo
total de nuestro proyecto estar comprendido entre el 65% del proyecto de

8 KLDC y el 62% del proyecto de
32 KLDC.
El porcentaje buscado, empleando
interpolacin lineal, ser:
y=yo+[x~-~~o) (y1-yo)
donde: y es el porcentaje que se desea calcular
x es el tamao del proyecto en
KLDC
yo y y1 corresponden al 65%
y 62%, respectivamente.
xo y x1 corresponden a 8 KLDC
y 32 KLDC, respectivamente.
y=65+ 12.8-8 (62-65)=64.4
32-8
El porcentaje de esfuerzo, para el
tamao no estndar, es del 64.4% y, por
lo tanto, el esfuerzo dedicado, en la fase
de programacin, ser:
ICESI.,.==========================
42
Atributos del personal:

Capacidad de anlisis
Experiencia en aplicaciones
Capacidad de los programadores
Experiencia en el sistema operativo
utilizado
Experiencia con el lenguaje de programacin
Atributos del proyecto:

Aplicacin de mtodos
de ingeniera del software
Utilizacin de herramientas
de software
Restriccin del tiempo
de desarrollo.
y.=59+ 12.8-8(55-59)=58.2
ACTIVIDAD
Anlisis de requis~os
Diseo del producto
Programacin
Plan de pruebas
Verificacin y validacin
Entonces, el tiempo en la fase de programacin corresponde al 58.2% del

tiempo total, es decir:
Tprog=(O.582){9.7 meses)=5.6 meses
El valor medio de personal, equivalente en la fase de programacin, ser
de:
Pe=22.5HM/5.6 meses=4.01 hombres
2.3. Modelo COCOMO intennedio
En este modelo se calcula el esfuerzo de desarrollo de software en funcin
del tamao del programa y de un conjunto de atributos conductores del costo, que incluyen la evaluacin subjetiva
del producto, del hardware, del personal y de los atributos del proyecto.
El COCOMO intermedio es una versin ampliada del COCOMO bsico,
pues presenta un mayor nivel de detalle
y de seguridad, pero conservando la
misma sencillez.
Los atributos conductores de costos
son 15 factores, compuestos por cuatro
categoras y que no se tienen en cuenta
en el modelo bsico. Dichos atributos
son:
- Atributos del producto:
Confiabilidad requerida del software.
Tamao de la base de datos.
Complejidad del producto.
-
Atributos del hardware:
Restricciones de tiempo
de ejecucin.
Restricciones de memoria.
Volatilidad de mquina virtual
Tiempo de respuesta del equipo
Cada uno de estos atributos tiene

asociado un factor multiplicativo, el cual
estima el efecto del atributo en el esfuerzo del desarrollo del software; este
factor se denomina multpllcador de
esfuerzo. Estos multiplicadores se aplican a un estimativo-base del esfuerzo,
para obtener un estimativo refinado
(ajustado) del esfuerzo del desarrollo.
Este modelo inicia la estimacin, con la
generacin de un estimativo nominal o
bsico del esfuerzo, usando funciones
escalares similares a las del modelo
bsico. Este estimativo nominal es, entonces, ajustado, aplicando los multiplicadores de esfuerzo, derivados de la
clasificacin del proyecto respecto de
los 15 atributos del costo.
La siguiente tabla presenta las
ecuaciones del esfuerzo nominal, para
los tres modos de desarrollo, utilizados
en el COCOMO, intermedio.
Modo de desarrollo Ecuacin nominal de esfuerzo
Orgnico
Enom=3.2(KLDC)'05
Semilibre
Enom =3.0(KLDC) 1.12
Restringido
Enom =2.8(KSDI) 1.2
El modelo intermedio presenta una
tabla de multiplicadores de esfuerzo,
donde cada atributo conductor de costo
tiene asociado un conjunto de multiplicadores. Estos, a su vez, estn relacionados con un conjunto de clasificaciones de proyectos.
:=========================~'CE':,
VALOR
Atributos
Muy bajo
Bajo
Nomil\lll
Alto
Muy alto
Extra alto
0.75
0.70
0.88
0.94
0.85
1.0
1.0
1.0
1.15
1.08
1.15
1.40
1.16
1.30
0.87
0.87
1.0
1.0
1.0
1.0
1.11
1.06
1.15
1.07
1.30
1.21
1.30
1.15
1.66
1.56
-
1.46
1.29
1.42
1.21
1.14
1.19
1.13
1.17
1.10
1.07
1.0
1.0
1.0
1.0
1.0
0.86
0.91
0.86
0.90
0.95
0.71
0.82
0.70
Atribu10s del proyecto

Aplicadn de la ingeniera del software 1.24
Utilizacin de herramientas del software 1.24
Restricdn del tiempo de desarrollo
1.23
1.10
1.10
1.08
1.0
1.0
1.0
0.91
0.91
1.04
0.82
0.83
1.10
Atributos del prodcto

Confiabilidad del software requerida
Tamallo de la base de datos
Comple;dad del producto
Atributos del hardware
Restricciones de tiempo de ejecucin
Restricciones de memoria
Volatilidad de la mquina virtual
Tiempo de respuesta del equipo
Atributos del personal
ExperienCia en aplicadones
Capacidad de programadores
Experienda en el S.O. utilizado
Experiencia con e/lenguaje
Como ayuda para seleccionar el factor aplicable en cada caso, la siguiente

tabla establece los criterios que sirven
para elegir el factor adecuado.
'"
~i1!
Por ejemplo. si consideramos el desarrollo de una aplicacin del modo

semilibre, con 32 KLDC, que presenta
diferentes requerimientos de confiabilidad debido a la naturaleza de su ambiente de trabajo, el esfuerzo nominal
se calcular as:
~'"
. _ CI)
E 15.
Si
e
5l
o
z
Enom =3.0(32)1.12=146 hombres-mes.

Indica un esfuerzo total de 146 hombres-mes que son requeridos para desarrollar un producto de 32 KLDC, en
modo semilibre, independiente de cualquier consideracin de los requerimientos de confiabilidad.
I
ti
:E:S~'==========================
A partir de aqu, los ajustes en el estimativo final deben hacerse de acuerdo con el tipo de producto final. Por
ejemplo. si el sistema por desarrollar es
un modelo de prediccin del clima, podra tener un relativo nivel bajo de cali-
1.65
dad, puesto que su impacto operacional

es generalmente a largo plazo y muchas
fallas podran ocasionar prdidas para
los usuarios, fcilmente recuperables.
Estas caractersticas le dan un peso, en
la tabla mencionada, de 0.88 (bajo) para
un ajuste de:
E=(Enom)(Factor multiplicativo)
E=(146 HM)(0.88)-128 hombres-mes
Pero si el sistema por desarrollar es,
por ejemplo, un sistema de control de
reactor nuclear, podra tener un muy alto
requerimiento de confiabilidad. Aqu el
efecto de fallas del software podra provocar la prdida de vidas humanas; por
lo tanto, tiene un factor multiplicativo
mayor que el anterior. La estimacin del
esfuerzo ser, de acuerdo con el nivel
de confiabilidad 1.40 (muy alto), la siguiente:
E=(Enom)(Factor multiplicativo)
E=(146 HM)(1.40)=204 hombres-mes
:::::=====================~I~CE~
Por lo tanto, para ajustar la estimacin del esfuerzo usamos la siguiente

ecuacin, empleando los factores
multiplicativos:
la ecuacin nominal del esfuerzo para

este modo, obtenemos el siguiente esfuerzo nominal:
Atributo
2.8(10)12=44 HM
E=(KLDC)S 1t1 5j=1 FJ
Donde S es el exponente correspondiente al modo de desarrollo y F el factor multiplicativo.
Veamos ahora un ejemplo sobre
cmo aplicar los factores multiplicativos
en el modelo de COCOMO intermedio.
Supongamos que estamos negociando
con la compaa Megabit Comunicaciones el precio de desarrollar un producto
de software para el procesamiento de
funciones de comunicacin, en un
microprocesador comercial, cuyo tamao se estima en 10 KLDC y se desarrolla en modo restringido. De acuerdo con
Atributo
Confiabilidad del software
requerida
Deseamos ahora determinar el efecto de varias caractersticas del proyecto, en el esfuerzo y costo de desarrollo. Por ejemplo, el software para el
procesamiento de comunicaciones generalmente tiene una valoracin muy
alta, en la escala de complejidad, pero
se planea usar personal analista y programador con alta capacidad, lo cual
balancea la tendencia a incrementar los
costos, debido a la complejidad. El costo del personal ser de $6.000 por mes.
En la siguiente tabla tenemos las caractersticas presentes para el desarrollo del producto:
Situacin
Uso local del sistema
No hay problemas serios
de recuperacin
Clasificacin
Multiplicador
de esfuerzo
Nominal
1.00
Tamao de la base de datos 20.000 bytes
Baja
0.94
Complejidad del producto
Procesamiento
de comunicaciones
Muy alta
1.30
Restricciones de tiempo
de ejecucin
Se usar el 70% del

tiempo disponible
Alta
1.11
Restricciones de memoria
45K de 64K disponible
Alta
1.06
Volatilidad
de la mquina virtual
Basado en
microprocesador
comercial
Nominal
1.00
Tiempo de respuesta
del equipo
2 horas
promedio
Nominal
1.00
Analistas
con experiencia
Alto
0.86
Experiencia
en aplicaciones
3 aos
Nominal
1.00
Programadores
con experiencia
Alta
0.86
Experiencia en el
6 meses
Baja
1.10
Experiencia
con el lenguaje
12 meses
Nominal
1.00
Aplicacin de la
ingeniera del
software
Muchas tcnicas
por ms de
un ao
Alta
0.91
Utilizacin
de herramientas
del sotfware
Herramientas
Baja
1.10
Restriccin del
tiempo de desarrollo
9 meses
Nominal
1.00
s.a. utilizado
I
!
Multiplicador
de esfuerzo
Capacidad
de programadores
Factor de esfuerzo ajustado (producto de multiplicadores de esfuerzo)
Ntese que el factor de ajuste se incrementa en 1.30, debido a la complejidad muy alta, pero ms adelante se reduce el valor a 0.86, debido a la alta capacidad de analistas y programadores.
El factor de ajuste final, de 1.17, representa un incremento del 17% en el esfuerzo nominal; entonces, el costo y el
esfuerzo estimados finalmente son:
Esfuerzo: (44 HM)(1.17)=51 HM
Costo: (51 HM)($6.000/HM)=$306.000
~ES:':-:=========================:
Clasificacin
Situacin
2.3.1. Anlisis de sensibilidad

El modelo COCOMO intermedio permite realizar un anlisis de sensibilidad
con respecto a los atributos directores
del costo, logrando as estimar el efecto
sobre el costo de desarrollo, debido a
los cambios en los niveles de clasificacin de los atributos.
Por ejemplo, supongamos que tenemos la opcin de realizar el proyecto del
ejercicio anterior con personal de me-
1.17
nor capacidad y menos costoso. Para

este caso, el costo por persona-mes
podra ser de $5.000 en lugar de los
$6.000 anteriores, y la capacidad de
anlisis y programacin la podramos
clasificar como Nominal. De acuerdo con
la tabla anterior, este nivel de capacidad del personal resulta en un factor
multiplicador de 1.00, en lugar del 0.86
obtenido anteriormente. Esto significa
que el estimativo de COCOMO debe ser
ajustado de acuerdo con las consideraciones anteriores:
Nuevo factor de ajuste
de esfuerzo =1.58
Esfuerzo=(44 HM)(1.58)=70 HM
Costo: (70 HM)($5.000/HM)=$350.000
Segn lo anterior podemos notar que
resulta ms ventajoso usar personal de
mayor capacidad, segn el anlisis realizado con el factor de ajuste del esfuerzo, porque el estimativo de costo es
menor.
:::::::=::::=====:=========:~
ICESf
47
Veamos otro ejemplo para el factor

de ajuste de restriccin del almacenamiento. Supongamos que por $10.000,
Megabit podra comprar 96K palabras
de memoria para el microprocesador por
usar, en lugar de usar 64K. Esto podra
cambiar las restricciones del almacenamiento principal del 70% al 47%. El resultado en el multiplicador del esfuerzo
sera de 1.00, que corresponde a una
clasificacin Nominal, en lugar de 1.06
(alta), que era el anterior caso. Con lo
anterior se tiene que:
Factor de ajuste del esfuerzo=1.1 O
Esfuerzo=(44 HM)(1.10)=48HM
Costo=(48 MM)($6.000/HM)=$288.000
Lo anterior nos indica que se logra
un ahorro de $18.000, lo cual compensa la inversin de $10.000 en costos de
hardware. Adems, al negociar con la
compaa Megabit, se puede proponer
esta opcin como forma para reducir el
costo del software.
2.3.2. Estimacin de los efectos

de software reutilizable
Hasta ahora todas las estimaciones
se haban basado en el supuesto que la
totalidad del producto estaba siendo
especificado, diseado y desarrollado
por completo, sin considerar que alguno de sus componentes hubieran sido
. desarrollados para otros proyectos previamente y que pudiesen utilizarse directamente o por adaptacin en el nuevo producto.
Obviamente, las lneas-fuente de un
programa adaptado no pueden tener la
misma consideracin que la del nuevo
software, para efectos de la estimacin.
Por ejemplo, supongamos que utilizamos, como parte de nuestro nuevo producto, una rutina simple de entrada/salida, que ya forma parte de la librera de
utilidades de otros proyectos, con lo cual
se incrementa el nmero de IIneas-fuen-
,
te de nuestro nuevo producto, pero a la
vez no incrementa la cantidad de esfuerzo requerido para el desarrollo del nuevo producto.
Por otra parte, en muchas ocasiones
no se necesita adaptar completamente
un paquete, sino que slo se precisa
realizar un esfuerzo adicional, para redisear el software adaptado, para
ajustarlo a los objetivos del nuevo producto, el cual consiste en rehacer algunas porciones para acomodarlas a los
cambios del entamo del nuevo producto.
Los efectos de la adaptacin de productos existentes son tratados por el
Modelo COCOMO, a travs del clculo
del nmero equivalente de instrucciones
fuente-lE, que se emplean en sustitucin de las lneas de cdigo-fuente LDC.
El nmero de lneas lE de un producto adaptado se calcula a partir de la estimacin de las siguientes cantidades:
Nmero de lneas-fuente adaptadas

al nuevo producto, lA.
Porcentaje de rediseo del software

MD. Es el porcentaje de diseo del
software que ha sido modificado
para adaptarlo al nuevo entamo. Necesariamente sta es una estimacin subjetiva.
Porcentaje de cdigo modificado. Es

aqul que es modificado con el fin
de adaptarlo al nuevo entamo.
Porcentaje del esfuerzo de integracin del software adaptado MI. Es el
porcentaje de esfuerzo requerido
para integrar el software adaptado
al nuevo producto, el cual se obtiene por comparacin con el esfuerzo
de integracin necesario para un
producto de tamao similar.
El total de lneas equivalentes se calcula a travs de un factor de adaptacin

definido como FA:
FA=0.40 MD+0.30MC+0.30MI
~ES:/~=======================:
~.
A partir del cual el nmero de lneas

equivalentes vendra dado por:
ficacin e integracin y pruebas dadas

por el modelo:
IE=IA*FA Uneas equivalentes.

Este valor puede aadirse a las estimaciones de nuestro producto y tratarlas como hemos estado haciendo hasta
ahora, de forma que el tamao final del
producto ser:
2.4. Modelo COCOMO detallado

Este modelo incorpora todas las caractersticas del modelo intermedio y lleva a cabo una evaluacin del impacto
de los atributos conductores del costo,
en cada fase del proceso de la ingeniera del software.
MD=O (es decir, no hay cambios en el

diseo del programa).
El modelo intermedio es altamente

efectivo para muchos propsitos de estimacin del software. Sin embargo, tiene dos Iimitantes principales que pueden ser significativas en estimaciones
de costo ms detalladas para proyectos extensos:
FA=0.40(0)+0.30(15)+0.30(5)=6
La estimacin distribuida de esfuerzo, por fases, puede ser inexacta.
y parlo tanto, el nmero de lneas equivalentes sera:
Puede ser muy engorroso para usarlo en productos con muchos componentes.
IE=50.000 LDC0.06=3.000 lneas equivalentes.
El madelo detallado provee dos principales facultades que consignan las

Iimltantes del modelo intermedio.
Utilizando las estimaciones del modelo bsico, se obtiene un esfuerzo de

adaptacin de:
E=2.4(3)1.05=7.6 HM
Los coeficientes de la ecuacin del
factor de adaptacin se determinan a
partir del valor medio de los porcentajes
dedicados a las tareas de diseo, cadi-
30%
Los multiplicadores de esfuerzo, en

este modelo, pueden aplicarse a la fase
de mantenimiento, del mismo modo que
se realizan en la fase de desarrollo.
Para esta situacin podramos considerar que:
Los resultados de la adaptacin seran:
Integracin y prueba:
En cuanto a la distribucin del esfuerzo por fase, el modelo intermedio utiliza

las mismas tablas empleadas en el modelo bsico.
Como ejemplo, supongamos que

deseamos convertir un programa de
anlisis de circuitos, escrito en FORTRAN, de 50.000 Ifneas, desarrollado en
modo orgnico desde un entorno hardware-software determinado en otro diferente.
MI=5 (se precisa una pequea cantidad

de esfuerzo para integrar estos cambios).
40%
30%
Para estimar el tiempo de desarrollo

se emplean las mismas ecuaciones utilizadas en el Modelo COCOMO bsico.
LDC.-=LDC+IE.
MC=15 (posiblemente el 15% de las lneas de cdigo deban cambiarse para

adaptarlo a las caractersticas propias
del nuevo sistema operativo, del lenguaje de control, etc.)..
Diseo:
Codificacin:
Multiplicadores de esfuerzo de fase

sensitiva: en la R!'"ctica, factores tales como confiablli d, experiencia
y desarrollo interactivo ectan a algunas fases mucho ms
otras.
El modelo detallado ofrece u"",con-
:::::::===:==::==:::::::::::~ICESI
49
junto de multiplicadores de esfue~

zo, de fase sensitiva, para cada atrIbuto del costo. Estos son usados
para determinar la cantidad de esfuerzo requerido para completar
cada fase.
Los multiplicadores se usan de acuerdo con la precisin que refleje el efecto
de los conductores de costo, en la distribucin de fase del esfuerzo. Por ejemplo, un nivel bajo en experiencia de aplicaciones puede significar esfuerzo adicional en las primeras fases. En las ltimas fases el equipo podr familiarizarse con la aplicacin y, as, no se requerir mucho esfuerzo adicional.
De otra parte, un tiempo de respuesta alto en el computador tendr muy
poco efecto en las fases de diseo y
requerimientos, pero ciertamente consumir ms tiempo del equipo durante
la codificacin y las pruebas.
-
Jerarqua de producto de tres niveles: en el modelo intermedio la clasi- .

ficacin separada de los conductores de costo puede ser suministrada por diferentes componentes del
producto. Este proceso puede ser
tedioso e innecesariamente repetitivo si un nmero de componentes se agrupa en un subsistema, con
prcticamente todas las mismas clasificaciones. El modelo detallado
excluye este problema, ofreciendo la
jerarqua de producto de tres niveles, para lo cual:
Algunos efectos, que tienden a variar con cada mdulo de nivel interno, son' tratados en el nivel de mdulo.
Algunos efectos, que varan menos
frecuentemente, son atados en el
nivel de subsistema.
Algunos efectos, tales como el efecto de tamao total del producto, son
tratados en el nivel del sistema.
El nivel ms bajo, el nivel de mdulo,

se describe por el nmero de lneas de
cdigo-fuente en el mdulo, y por aquellos atributos de costo que tienden a
variar al ms mnimo nivel. Por ejemplo, la complejidad del mdulo y su
adaptacin al software existente; la capacidad de los programadores y la experiencia en el manejo del lenguaje en
el que se desarrolla el software.
El segundo nivel, nivel de subsistema, se caracteriza por el resto de
los conductores de costo (tiempo, condiciones de almacenamiento, capacidad
de analistas, herramientas, etc.), los
cuales tienden a variar de un subsistema
a otro, por lo cual tiende a ser lo mismo
para tocios los mdulos del subsistema.
3.1.1. Archivo Lgico 1n1ecrJ.":~~I2l![1

conjunto de datos del usuario que estn
lgicamente' reiaci9!JC1o.S.y q~'e son
mantemas:Y utilizados, por la aplicacin! dentro de S~SJKQpiosJfmi.te.$:
tener los datos se refiere a la capacidad
de adicionar, modificar o borrar datos a
En este mtodo se evala la fun- i travs de procesos estandarizados de
cionabilidad de una aplicacin en trmi- . la aplicacin. Tambin entra en este grupo la informacin de control, es decir,
nos de qu se le entrega al usuario en
la aplicacin y no cmo se le entrega.
105 datos usados por la aplicacin para
Unicamente los componentes visibles y
asegurar que se cumplan los requerilos requerimientos del usuario son conmientos de funcionamiento especificatabilizados. Estos componentes son trados por el usuario.
tados como Tipos de Funcin, los cuaPara identificar estos archivos se
les estn divididos en Datos y Transacidentifican todos los datos o grupos de
ciones:
datos que:
Tipos de Funcin Datos: Archivos
Son almacenados dentro del alcanLgicos Internos (AL!) y Archivos Exterce de la aplicacin.
nos de Interface (AEI).
Son mantenidos a travs de proceTIpos de Funcin Transacciones:
sos
estandarizados de la aplicacin.
Funciones de Entrada (Entradas Exter-
roducto de trabajo, tales como

fuerzo e esarro o y o mantenimiento
delSoftware. Una componente o f~
.e.l!..'!'lQr:QQeso nico o reQperimiento de
datos de la aplicacin por ejemplo l/Da
l2flotalla donde se adicionan datos o '10_
~.QQrte impre&o
Man-='
nas), Funciones de Salida (Salidas Externas), Consultas Externas (CE).
Son definidos como requerimientos

de la aplicacin por el usuario.
Los objetivos principales de esta

metodologa son:
Tambin se identifican estos archivos

agrupando los datos lgicamente, desde el punto de vista del usuario:
El nivel ms alto, el nivel del sistema, se usa para aplicar las principales
relaciones del proyecto, tales como las
ecuaciones de esfuerzo y tiempo, y para
aplicar, durante las interrupciones, en el
esfuerzo y 105 tiempos del proyecto.
Medir lo que el usuario requiere y lo

que se le entrega.
3. METODOS DE LOS PUNTOS

DE FUNCION
La mtrica de 105 puntos de funcin
Medir la aplicacin, independientemente de la tecnologa usada para la

implementacin.
Agrupar los datos hasta un nivel de

detalle, en el cual el usuario pueda identificar los datos como satisfaccin a sus
requerimientos.
~rmit~~aritmcar una,ap~c~~.~~- .
Proveer una mtrica de tamao que

soporte anlisis de calidad y productividad.
Tratar los datos lgicamente; no deben tomarse en cuenta los archivos fsicos.
Proveer un vehculo para la estimacin del software.
Los siguientes son los tipos de datos

que pueden relacionarse con uno o ms
Archivos Lgicos Internos, dependiendo de la visin de usuario.
sndose en aosreaSde evaJ"uaclon: La

consiste' ' El cicJTf~,~~ji:
tosdeiC,-simples.LSgunda rea
onssle'e-justar el 'model, el1 flJ.6::
cin de la complejidaq y~el aml?l~r!tl3~,
de desarrollo de la aplicacin., ..._
priira
L~'fi~alidad de esta metodologa es,

en primer lugar, estimar el tamao de
un producto de software en las etapas
previas de su desarrollo y, por otra parte, estimar el esfuerio de desarrollo,
expresado en este caso en horas trabajadas. 'por el punto de funcin desarrollado. Un ~:: ~~cin es una
mtrica
"dad-deL
...._""'y_., .. .w..e-i
Este ltimo aspecto es el que se trata en este documento.

3.1. Tipos de funcin
Los puntos de funcin sin ajuste tratan exclusivamente del conteo de las
funciones del usuario y se realiza tras
una previa clasificacin de las funciones,
basndose en aquellos componentes de
una aplicacin que son requeridos y son
visibles al usuario.
Datos de la aplicacin (archivos

maestros, tales como informacin de
personal o informacin consolidada).
Datos de seguridad de la aplicacin.
Datos de auditora.
Mensajes de ayuda.
Mensajes de error.
~,.,-
~=========================
ICES;
50
La jerarqua mdulo-subsistema-sistema se da por la descomposicin jerrquica del producto, del cual se va a

estimar el costo.
==========================~
ICESI
51
Ejemplos de Archivos Lgicos Internos son:

Datos de respaldo (Backup), los cuales se cuentan nicamente si son especficamente requeridos por el usuario, ya
sea por requerimientos legales o algo
similar.
Archivos Lgicos Intemos que sean
utilizados y mantenidos por ms de una
aplicacin, es decir, archivos compartidos.
Los siguientes archivos no se consi
deran Archivos Lgfcos Internos:
Mensajes de ayuda.
Mensajes de error.
Los siguientes no se consideran

como Archivos Externos de Interface:
Datos que son mantenidos por la

aplicacin, pero a los que se tiene
acceso y son utilizados por otra aplicacin.
Datos formateados y procesados,

para ser utilizados por otra aplicacin.
Archivos de trabajo.
3.1.2. Archivos Externos de interface. Son grupos de datos lgicamente relacionados o informacin de
,control utilizados por la aplicacin, pero
" que no son mantenidos por sta sino por
. otras aplicaciones. En este tipo se cuentan archivos transferidos o distribuidos
entre aplicaciones.
Para identificar estos archivos es
necesario:
Identificar todos los datos que estn

almacenados fuera del alcance de
la aplicacin.
Que no sean mantenidos por la aplicacin propia.
Que estn dentro de los requerimientos del usuario.

Tambin se identifican estos archivos agrupando los datos lgicamente, desde el punto de vista del usuario, para lo cual se debe:
Agrupar los datos hasta un nivel de

detalle, en el cual el usuario pueda
identificar los datos como satisfaccin a sus requerimientos.
Tratar los datos lgicamente; no deben tomarse en cuenta los archivos
fsicos.
Datos de referencia (datos externos

utilizados por la aplicacin, pero que
no hacen parte de sus Archivos Lgicos Internos).
Archivos temporales.
Archivos de ordenamiento.
LosArchivos Externos de Interface no

se atribuyen a la aplicacin fuente, es
decir, a la aplicacin donde se originan
estos archivos. Esto significa que se atribuyen estos archivos a las aplicaciones,
bsandose en la direccin del flujo y el
uso de los datos, por la aplicacin.
El tipo de archivo se determina basndose en cmo los utiliza la aplicacin que recibe los datos. Si los datos
son usados para actualizar los Archivos
Lgicos Internos, se considera como
una Entrada Externa o una Salida Externa, dependiendo del flujo. Silos datos no se usan para el mantenimiento
de un Archivo Lgico lntemo, se consideran como un Archivo Externo de
Interface, de acuerdo con el flujo de datos.
El clculo de los puntos de funcin
debe ser actualizado si, despus del
clculo, el acceso a un Archivo Lgico
Interno se le permite a otra aplicacin.
No siempre se puede determinar
cmo otra aplicacin est utilizando los
datos y varios mtodos no han involucrado esta situacin, lo cual ha dado
ICESI~=========================
52
como resultado clculos inconsistentes.

Para resolver este problema, nicamente la aplicacin que recibe los datos puede tenerArchivos Externos de Interface
es decir, que el clculo se asume desd~
el punto de vista de la aplicacin que se
analiza. Como resultado, el clculo de
los puntos de funcin depende nicamente del sistema, como existe actualmente, y no de futuros eventos o de la
utilizacin de los datos.
Los siguientes son tipos de datos que

pueden relacionarse con uno o msArchivos Lgicos Internos, dependiendo
de la visin del usuario:
Las siguientes son Entradas Externas, tomando en cuenta las anteriores

consideraciones:
Datos de transacciones: Datos extemos usados para mantener 10sArchivos Lgicos Internos.
Pantallas de entrada: Se cuenta una

Entrada Extema para cada una de
las funciones de mantenimiento. Si
adiciona, modifica y borra, la pantalla debe contarse como tres Entradas Externas.
~3. F.unE!pn~ de Entrada (Entra

das Externas - E.ttJ'Se hace refere=--
cia a lasfuncion~ de enirndi"d;d~l~

'Sic6sidera'Emtonces los ci;fo;('Qic~~ .<:l~~ntrada o de CQ1l1[Q!.QUe deben
-suministra:se,'I~plcacincon..!tlJin
d aadirlos aU11ArciiiVoL6gico..1ntel:no demodificarlo. Se deben contar las
itrocfucidas"drectamente por el usuario y las obtenidas como resultado de
una transaccin, desde otra aplicacin.
Dos o ms archivos fsicos pueden

corresponder a una sola Entrada Externa, si el procesamiento lgico y el formato para cada uno de estos archivos
es idntico.
Una Funcin de Entrada (Entrada

Extema) se considera nica si tiene di
,ferente formato o si, por su diseo in!temo, requiere un proceso lgico, dife\rente de otra funcin de entrada, con el
'mismo formato.
El formato puede ser un conjunto de
datos nicos o un arreglo nico de datos o un orden nico de datos.
Para identificar las Entradas Extemas
se debe:
Identificar todos los procesos.Jue

actualizan los .!'.~h!y--~).gicos In-
_A.
temos~~----
'por elprcesOPUden's~;recibidQ
en ms de un, formaio';sjgna,:-~na'
Entrada Extema por cada una de las
actividades de mantenimiento desempeadas; esto es, adicionar, modificar y borrar.
Entradas Externas duplicadas: Se

hace referencia a aquellos procesos
que presentan la misma Entrada Extema, pero por diferentes medios.
Por ejemplo, en un sistema bancario que acepta idnticas transacciones de depsito, a travs de un proceso automtico (cajero automtico)
y a travs de procesos manuales.
Por lo tanto, ambos procesos se
cuentan cada uno como Entrada
Extema.
Las siguientes no se consideran

como Entradas Externas:
Datos suministrados a la aplicacin,

por razones de tecnologa empleada.
Datos externos utilizados por la aplicacin, pero no mantenidos en Archivos Lgicos Internos.
Datos de entrada, usados para seleccionar la recuperacin de datos.
Pantallas de men que nicamente

permiten viajar por las pantallas de
la aplicacin y no contribuyen di-
"
Por cada proceso identificado, con

siderar cada-faFmetoC'6ril6n"proceso separado; si tos'dl:tl"9s..Li&adQs
Por cada proceso nico que mantiene un Archivo Lgico Interno, contar
una Entrada Externa por cada adicin, modificacin y borrado.
:========================~/CE~
rectamente en el mantenimiento de
los Archivos Lgicos.
,Reportes .Qada reporte producido

la aplicacin se cuenta como
Salida Externa. Dos reportes idnticamente formateados se cuentan
cada uno como Salida Externa si tienen procesamiento lgico diferente.
Pantallas que facilitan la entrada a

una aplicacin; por ejemplo, pantallas de logon.
Mltiples formas de invocar la misma entrada. Por ejemplo, digitar A o
Add como un comando o como una
tecla de funcin, para seleccionar la
opcin de adicionar; slo se cuenta
una Entrada Externa.
Cualquier tipo de consulta no se

cuenta, puesto que pertenece a un
tipo de funcin diferente.
;Reportes idnticos, pero producidos

pOI Illedios dilel elites; por ejemplo,
un reporte originado por una impresora y por tarjetas perforadas.
Una Salida Externa debe asignarse

por cada Entrada Externa que origina mensajes de error o confirmacin.
N? s~ consl.deran Sallda~ Externas

Tos siguientes tipOS de datos.
~.!:1.!~I!~~.9,E!I.9.9..(),r:!...qi!..E:l proveen funciones de seguridad, se cuentan

como Consultas Externas.
aplica~~~~~~~~
Para identificar las Entradas Externas

es preciso:
Identificar todos los procesos que
suministran datos, fuera de los lmites de la aplicacin.
\
\ Por cada proceso identificado, con siderar cada formato como un pro. ceso separado si los datos usados
por el proceso pueden ser suministrados en ms de un formato; asignar una Salida Externa por cada proceso identificado.
Las siguientes son Salidas Externas,
tomando en cuenta las anteriores consideraciones:
Mltiples formas de invocar la misma salida. Por ejemplo, para seleccionar un reporte, si se necesita
digitar R o Report o una tecla de funcin, slo se cuenta una Salida Ex-
usuario o d-econfrol: los suministradQ,

- por la aplicaCion.Se ic~n dentro d~
.' este tipo, salidas tales' comO"i~
'mensaie.~ILlSlJari.,mensajQS a otras
terna.
Mensajes de confirmacin o error,
originados por una consulta.
Datos transferidos hacia otras aplicaciones.
ICESI
Tres categorl:ls~e aYlldas son consideradas como Consultas Externas:

. ' - Pantallas totales de ayuda, que son
aqullas que musrra:n'~TTxfo'ae
ayuda relacionado ~on l'a pimfana
que le llam.
3.1.5. Consultas Externas - CE.

EstasconstHuyeCOr'binaciones "IolGas-Entrada/Salida, donde una entrada
causana:'saidainmeai"ata. La consulta
consj(::le~anlca Sfti';e un formato diferente de otra funcin del misrno
tipo (para la entrada y la salida), o si su
diseo externo requiere un proceso lgico diferente.
-as
se
Identificar todos los procesos en los

que una entrada dispara una recuperacin inmediata de datos.
Por cada proceso identificado, verificar que cada combinacin de Entrada/Salida es nica y considerar
cada combinacin como un proceso
diferente y acreditar una Consulta
Externa por cada proceso.
Ayuda sensitiva del campo, que es

aCj'ettadepelldiente de. ~ p9.l>~in
del cursor o ele algn mtodo de
identificacin. que muestra la documentacin de ayuda para ese campQ,~e cuenta una Consulta Externa
por cada pantalla.
Subsistema de ayuda, qlJe eSUDa
faC!lbdad i!.~~~i.a. J. .ql;Je...~~~'p,u,e
de acceder y qL!~ ,py.~g!'lseueC.9rri-
da'!l1dpendiente de la aplicacin
asociada. Si el texto recuperado es
idntico al de una ayuda total, no se
cuenta.
Para identificar las Salidas Externas

se debe tener en cuenta:
l
54 ~======:===:U:=:===========:2:21:2
.'
3.2. Clculo de los Puntos

de FunCiOi'<si' ajuste)
El ca.lcUo de los
Pu~t~;d;F~ncin
const~de tres pallaS:
ObtenEl~ Pl,Jl1tos~e Funcin.sin.aLLJ:.
"te.
Obte-"-~~.E.t<?E.~~_Ajuste.
-_....,-...
~~star los Puntos de Funcin, usando el.Fa.:cJr~

Io.s PunlosdeEuncinIeaWs.
AIyti)i'r-Qbtener'-
Pantallas de Modificacin/Borrado,
en las que se prVoc~rtct recuperacin de datos, antes de ejecutar la
funcin de Modificacin/Borrado.
Si las entradas y salidas de la con-SLilfsoi1Tclemlcas eh am6as TCiones de Modificacin y Borrado, se
cuenta nicamente una Consulta
Externa. Si se dispone de idnticas
funciones de consulta en pantallas
de Modificacin/Borrado y en una
pantalla aparte de consulta, se cuenta slo una Consulta Externa.
consiaeranentons~9!~;~~
Una Funcin de Salida (Salida Externa) se considera nica si tiene diferente

formato o si, por su diseo interno, requiere un proceso lgico diferente de
otra funcin de salida, con el mismo formato.
'salidas en lnea de datos que no se

originan por una Entrada Externa.
3.1.4. Funciones de Salida (Sal;~

Extemas - SE). Se hac referen~la a
lasflJn-clones de sarraa de datos. Se
Los siguientes son ejemplos de Consultas Externas:
pur
Para cada tipo de funcin se determina la complejidad de forma diferente,

as:
(
Para los Tipos de Funcin de Datos,
~a complejidad funcional se identifica de

!acuerdo con el nmero de Elementos
~e Tipo Registro (ETR) y con el nmero
~e Elementos de Tipo Datos (ETD).
I Los ETR son formatos nicos de restros, dentro de un ALI o un AEI.
Los ETD son ocurrencias nicas de

d tos, tambin tratados como elemento de datos, variables o campos.
.por cadaAU y A~I identificado, se le

Igna una complejidad funcional, bandose en los ETD y los ETR.
Cmo identificar ETR's: Son subgrupos de 10sALI's, vistos desde la perspectiva lgica que el usuario tenga de
los datos, es decir, de acuerdo con sus
requerimientos. AU's que no puedan ser
categorizados, se considera que tienen
un solo ETR.
Cmo identificar ETD's: Son campos
reconocibles por el usuario y no recursivos, que residen en un ALI.
Cada campo en un AU debe identificarse como un ETD, tomando en cuenta las siguientes consideraciones:
Campos que deberan ser vistos

desde un nivel reconocible por el
usuario. Por ejemplo, un nmero de
cuenta o una fecha que es fsicamente almacenada en mltiples
campos se cuenta como un ETD.
Campos que aparecen ms de una

vez en un AU, debido a la tecnologa o a las tcnicas de implementacin, deben contarse como un ETD,
slo una vez. Por ejemplo, si un AL!
se compone de ms de una tabla en
una base de datos relacional, la clave usada para relacionar las tablas
se cuenta una sola vez.
==========================~
ICESI
55
,
.
Campos repetitivos que son idnticos en formato y existen para permitir mltiples ocurrencias de un valor de un dato, se cuentan una sola
vez. Por ejemplo, unAL! que contiene 12 campos de presupuestos mensuales y un campo con un presupuesto anual (la suma de los men-
(1 )
(2a5)
(6 o ms)
ETR
ETR
ETR
suales) deberan contarse como dos

DTE, uno para el campo mensual y
otro para el campo anual.
Por cada AL! y AEI se identifican sus
ETR y ETD; luego se le asigna un grado de complejidad, de acuerdo con la
siguiente tabla:
(1 a 19)
(20 aSO)
(510 ms)
ETO
ETD
ETO
Baja
Baja
Media
Baja
Media
Alta
Media
Alta
Alta
Para las EE, los ETD son tratados de

igual forma que en los casos anteriores
y, adicionalmente, un ETD se cuenta,
para una EE, con las siguientes consideraciones:
Lneas de comando o teclas de funcin que proveen la capacidad para

especificar la accin que se tomar
por la EE. Un ETD adicional por EE,
no por tecla de comando.
Campos que no son suministrados
por el usuario, pero a travs de EE
son mantenidos en unAL!, deberan
ser contados. Por ejemplo, un siste-
(1 a 4)
El peso para cada grado de complejidad es el siguiente:
Baja
Media
Alta
AL!
AEI
5
7
10
15
10
Para calcular el total de Puntos de

Funcin, para los AL! y AEI, se usa una
tabla como la siguiente:
Sumando la columna de complejidad

total, tenemos un total de puntos de funcin sin ajuste de 96.
De igual forma, tomemos el caso de
tres AEI con complejidad baja, tres con
complejidad media y tres con complejidad alta:
l1po de
funcin
Complejidad
fu"ncional
AEI
-Baja x 5 =
-Mediax 7
l1po de
funcin
AL!
Complejidad
funcional
Complejidad
total
-Baja x 7=
-Media x 10=
-Alta
x 15=
Por ejemplo, supongamos que se tienen tres AL! con complejidad baja, tres
con complejidad media y tres con complejidad alta:
Complejidad
total
l1po de
funcin
Complejidad
funcional
AL!
-Baja x 7 =
a,.Media x 10 =
-Alta
Total de puntos
de funcin
x 15 =
21
30
12
a6.
~Alta
Complejidad
total
x 10 =
Total de puntos
de funcin
Sumando la columna de complejidad
total, obtenemos un total de puntos de
funcin sin ajuste de 66.
El siguiente paso consiste en calcular la complejidad funcional de las funciones de entrada EE (Entradas Externas), y SE (Salidas Externas) basndose en el nmero de Tipos de Archivo
Referenciados TAR yel nmero de ETD.
Un Tipo de Archivo Referenciado se
cuenta por cada AL! y por cada AEI
referenciado, durante el procesamiento
de una Entrada Externa, EE, o una SE,
segn el caso.
~==========================
ICESI
56
ETO
ma de clave secuencial, mantenido

en un AL!, pero no suministrado por
el usuario, debera contarse como un
ETD.
Para las SE se tratan inicialmente de
igual forma los EDT, con las siguientes
excepciones: No se incluyen literales
como ETD.
No se cuentan las variables de pginas <> los sistemas generados por rtulos por el sistema.
La complejidad funcional, para las
funciones de entrada EE, se basa en la
tabla siguiente:
(5 a 15)
ETD
(16 o ms)
ETO
(O a 1)
FTR
Baja
Baja
Media
(2)
FTR
Baja
Media
Alta
(3 o ms
FTR
Media
Alta
Alta
La complejidad funcional para las funciones de salida, SE, se basa en la tabla siguiente:
(1 a 5) (6 a 19) (20
a ms)
ETD
ETD
ETD
(O a 1) FTR Baja
Baja Media
(2 a 3) FTR Baja
Media Alta
(4'0 ms)FTR Media
Alta
Alta
EE
SE
Baja
Media
Alta
Para las funciones de consulta, Consultas Externas, se siguen. los siguientes pasos para determinar el valor de
los puntos de funcin sin ajuste:
Calcular la complejidad funcional

para la parte de entrada de la Consulta
Externa.
Calcular la complejidad funcional
para la parte de salida de la Consulta
Externa.
Seleccionar el valor ms alto de las
dos complejidades funcionales. Usando
una tabla adecuada para los Puntos de
Funcin sin Ajuste, se transcribe la clasificacin de la complejidad a Puntos de
Funcin sin Ajuste.
Se cuenta un Tipo de Archivo Referenciado por cada AL! y AEI, referenciados durante el proceso de la consulta.
Un ETD se cuenta por aquellos campos suministrados que especifican la
Consulta por ejecutar o que especifican
los criterios de seleccin de los datos.
Un ETD se cuenta por cada campo
no recursivo que aparece en la parte de
salida de la consulta.
57
ICESI
:========:=================~I
La complejidad funcional para las Consultas Externas, CE, se basa en las tablas
siguientes:
Complejidad de entrada
(1 a 4)
(5 a 15)
(16 o ms)
ETD
ETD
ETD
Baja
Baja
Media
(O a 1)
FTR
(2)
FTR
Baja
Media
Alta
(3 o ms)
FTR
Media
Alta
Alta
Tipo de
funcin
Complejidad
funcional
EE
a
a
Media x 4=
2
12.
Alta
x6=
la
;} Baja
x4=
12
SE
(O a 1)
FTR
a
a
Alta
x7=
Baja
x3=
Media x 4=
Alta
21
1a
..9
12.
la
(1 a 5)
(6 a 19)
(20 o ms)
~m
ETD
Ero
Baja
Baja
Media
CE
(2 a 3)
FTR
Baja
Media
Alta
(4 o ms)
FTR
Media
Alta
Alta
x3=
Media x 5 =
a
a
Complejidad de salida
Baja
x6=
a2
del sistema
La funcionalidad del modelo puede
varIar dependiendo del entorno etetfe=sarr_Qll.__eoH~staJ:aZn....e! modelo ia
troduce la}{alaracinde 14 caractersti-
CE
3
4
6
Baja
Baja
Alta'
cas_q,q;:influyeo.sabre.~
del proceso.
Una vez obtenidos los puntos de funcin sin ajuste para cada tipo de funcin,
podremos obtener el total de puntos de funcin sin ajuste, mediante la siguiente
tabla:
Tipo de
funcin
Complejidad
funcional
AL!
~ Baja
x 7=
Media x 10 =
x 15 =
~ Alta
Complejidad
total
Total de puntos
defuncin
Estas caractersticas se evalan de

conformidad con una escala de grado
de influencia que toma valores enteros
entre O y 5, para ajustar la complejidad
del proceso.
Las caractersticas generales del sistema son:
Transmisin de datos.
21
aQ
Proceso distribuido.
Rendimiento, respuesta.
\
AEI
a
a
J
Baja x 5 =
Media x 7 =
Alta x 10 =
21
JO
~=========================
ICESI
58
Total de puntos
de funcin
Total de puntos de funcin sin ajuste
3.3. Caractersticas generales

Complejidad
total
Configuracin.
'\ Indice de transacciones.

Entrada de los datos en lnea.
Eficiencia del usuario.
Actualizacin en lnea.
Complejidad del proceso.
Reutilizacin.
Facilidad de instalacin.
Sencillez de operacin.
Adaptabilidad.
Flexibilidad de cambio.
Los grados de influencia se clasifican
as:
o: No incluye.
1: Influencia insignificante.
2: Influencia moderada.
3: Influencia media.
4: Influencia significativa.
5: Influencia fuerte.
3.3.1. Transmisin de.-5!.l!1os _

Los datos e informacin de contr~
uSWSelrtapr~9l).J.S.9neffiliadus-o
rC1b~medio.. de facilidadGs--de
comunicaci6n.-...-.
=========================~
ICESI
59
Puntaje:
o: La aplicacin ocurre nicamente
en el procesamiento por lotes o en un
computador aislado.
5: Las funciones de procesamiento

son dinmicamente ejecutadas en ms
de un componente del sistema asociado.
1: La aplicacin se hace por lotes,

pero se tiene una entrada remota de
datos o una salida remota hacia la
impresora.
3.3.3. Rendimiento, respuesta
2: La aplicacin se hace por lotes,

pero se tiene una entrada remota de
datos y una salida remota hacia la
impresora remota.
3: Recoleccin de datos "on line" o

por teleprocesamiento frontal a un proceso por lotes o un sistema de consulta.
4: Ms de un proceso frontal, pero la

aplicacin soporta nicamente un protocolo de teleprocesamiento de comunicaciones.
5: Ms de un proceso frontal, pero la

aplicacin soporta ms de un protocolo
de teleprocesamiento de comunicacior;les.
3.3.2. Proceso distribuido

Son caractersticas de la aplicacin.
Puntaje:
O: La aplicacin no se preocupa por
la transferencia de los datos o el procesamiento entre los componentes del sistema.
1: La aplicacin prepara datos para

procesamiento del usuario final sobre
otros componentes del sistema, tales
como micras.
2: Los datos son preparados para ser
transferidos y procesados en otros componentes del sistema (no son para el
usuario final).
3: El procesamiento distribuido y la
transferencia de datos estn en lnea y
en una sola direccin.
4: El procesamiento distribuido est
en lnea y entre direcciones.
1: Existen restricciones en la operacin, pero son menos restrictivas que en

una aplicacin tpica. No se necesita
esfuerzo especial para responder ante
las restricciones.
2: Algunas consideraciones de segu-
3.3.6. Entrada de datos en lnea

La entrada de datos en lnea (on-line)
y las funciones de control son provistas
en la aplicacin.
Puntaje:
Los objetivos del desempeo de la

aplicacin son aprobados por el usuario, como respuesta o por la influencia
del diseo, el desarrollo, la instalacin o
el soporte de la aplicacin.
ridad o tiempo.
O: Todas las transacciones son pro"

cesadas en lotes.
3: Los requerimientos especficos del

procesador son necesarios para una
parte de la aplicacin.
1: Del 1% a17% de las transacciones

son interactivas.
O: No hay requerimientos especiales
4: Las limitaciones establecidas para
2: Del 8% al 15% de las transacciones son interactivas.
de desempeo por parte del usuario.
1: Los requerimientos del desempeo y del diseo fueron establecidos y

revisados sin ninguna accin requerida.
2: Tiempos de respuesta "on line" crticas durante las horas pico. Ningn diseo especial se ha requerido para el
uso de la CPU.
3: Tiempos de respuesta crticos durante todas las horas de trabajo. Ningn
diseo especial se ha requerido para el
uso de la CPU.
4: Los requerimientos establecidos

, por el usuario, para el desempeo, son
estrictos; lo suficiente para implementar anlisis de desem'peo en la fase de
diseo.
5: Adicionalmente, las herramientas
del anlisis del desempeo han sido
usadas en el diseo, desarrollo y/o implementacin, para conocer los requerimientos del usuario.
3.3.4. Configuracin
Un uso pesado de la configuracin
operacional que requiere consideraciones especiales de diseo, es una caracterstica de la aplicacin (por ejemplo,
el usuario quiere correr la aplicacin
sobre un equipo que ser altamente
usado).
Puntaje:
o: No estn explcitas o implcitas las

restricciones de la operacin.
~ES:/~========================:
la operacin requieren restricciones especiales sobre la aplicacin, en el

procesador central o en un procesador
dedicado.
5: Adicionalmente, hay restricciones
espeCiales para la aplicacin en, los

componentes distribuidos del sistema.
5: Ms del 30% de las transacciones

son interactivas.
3.3.5. Indice de transacciones
3.3.7 Eficiencia del usuario
El ndice o promedio de transacciones es alto y afecta el diseo, el desarrollo, la instalaciqn y el soporte de la

aplicacin.
Puntaje:
o: No se adelantan los perodos crticos de la transaccin.

1: Se anticipan los perodos crticos
de transaccin mensual.
Las funciones en W,ea provistas

enfatizan un diseo para la eficiencia del
usuario final. Esto incluye: '
Mens.
Documentacin y ayudas en lneas.
Movimiento del cursor automatizado.
. Desplazamiento de imgenes ("scroIIing").
Impresin remota.
Teclas de funcin preasignadas.
3: Se. anticipan los perodos crticos

de transacin diaria.
Seleccin de datos en pantalla por

medio del cursor.
4: Altos promedios de transaccin son

planteados por el usuario en los requerimientos o acuerdos de la aplicacin, y
son lo suficientemente altos como para
requerir tareas de anlisis de desempeo en la fase de diseo.
Uso constante de video inverso,

resaltamiento, delineado en color y
otros indicadores.
Copia permanente de la documentacin del usuario sobre transaccio

nes en lnea.
5: Al igual que en el punto anterior,

pero adicionalmente se requiere el uso
de herramientas de anlisis de desempeo en las fases de diseo, desarrollo
y/o instalacin.
Interfases con el "mouse".
Ventanas "Pop-Pup".
Fcil navegacin entre las pantallas.
Soportar dos o ms lenguajes.
2: Se anticipan' los perodos crticos

de transaccin semanal.
==========================~ICESI
61
Puntaje:
o:
No se presenta nada de lo ante-
rior.
1: De una a tres de las anteriores.
Procedimientos altamente automatizados de recuperacin, con un mnimo

de intervencin de operadores.
3.3.9. Complejidad del proceso
2: De cuatro a cinco de las anterio
no hay requerimientos especficos de los

usuarios con respecto a la eficiencia.
4: Seis o ms de las anteriores, pero

se establecen requerimientos sobre la
eficiencia de los usuarios, hasta un nivel en el que se requieren tareas de diseo para los factores humanos por incluirse.
El control sensible (por ejemplo, un

procedimiento especial de auditora)
y/o un procesamiento especfico de
seguridad de una aplicacin.
El procesamiento lgico extenso.
El procesamiento matemtico extenso.
Mucho procesamiento de excepcin,

que resulta en transacciones incompletas, las cuales deben ser procesadas de nuevo.
5: Seis o ms de los anteriores y se

establecen requerimientos para la eficiencia del usuario, a un nivel en el que
se requieren herramientas y procesos
especiales para verificar que se cumplan
los objetivos planteados.
3.3.8. Actualizacin en lnea
Puntaje:
La aplicacin provee actualizacin en

lnea para los archivos lgicos internos.
O: Ninguno de los anteriores.
Puntaje:
O: Ninguna.
1:Actualizacin en lnea de uno a tres
archivos de control. La. cantidad de actualizacin es baja y de fcil recuperacin.
, 2: Actualizacin en lnea de cuatro o
ms archivos de control. La cantidad de
actualizacin es baja y de fcil recuperacin.
3: Actualizacin en lnea de los principales archivos lgicos inlernos.
4: Adicionalmente, la proteccin contra prdida de datos es esencial y ha
. sido especialmente diseada y programada en el sistema.
5: Adicionalmente, altas cantidades
involucran consideraciones de costos en
el proceso de recuperacin.
62
Un procesamiento complejo para

manipular mltiples posibilidades de
entrada-salida; por ejemplo, multimedia, dispositivos independientes.
3.3.11. Facilidad de instalacin
O: No se tuvieron consideraciones
especiales, por parte del usuario, para
la instalacin.
1: No se tienen consideraciones especiales, por parte del usuario, pero s
se requiere configuracin especial para
la instalacin.
2: Los requerimientos de instalacin
y conversin son requeridos por el usuario. El impacto de la conversin en el
proyecto no es importante.
3: Los requerimientos de instalacin
2: Dos cualquiera de los anteriores.

3: Tres cualquiera de los anteriores.
rio. El impacto de la conversin, en el

proyecto, se considera importante.
5: Cualquiera de los anteriores.
3.3.10. Reutilizacin
Se refiere al grado de volver a utilizarla aplicacin Qn otros proyectos.
Puntaje:
O: Sin cdigo reutilizable.

1: El cdigo reutilizable se usa dentro de la aplicacin.
2: Menos del 10% de los mdulos
producidos consideran ms de una necesidad del usuario.
3: El 10% o ms de los mdulos producidos consideran ms de una de las
necesidades de los usuarios.
O: No hay consideraciones especiales diferentes de los de procesos de

"backup" normal.
4: Adicionalmente al puntaje 2, las

herramientas automatizadas de conversin e instalacin fueron provistas y probadas.
5: Adicionalmente al puntaje 3, las
herramientas automatizadas de conversin e instalacin fueron provistas y probadas.
3.3.12. Sencillez de operacin

En esta caracterstica se tiene en
cuenta la efectividad del arranque, el
respaldo y el procedimiento de recuperacin, durante la fase de prueba. La
aplicacin minimiza la necesidad de actividades manuales, tales como montajes de cintas, manipulacin del papel.
1 - 4: Se seleccionan los siguientes

tems, de acuerdo con la aplicacin.
Cada tem tiene un valor de un puntO,si no se especfica lo contrario.
Procesos efectivos de arranque, respaldo y recuperacin, pero se requiere la intervencin del operador.
Igual que el tem anterior, pero no

se requiere la intervencin del operador (2 tems).
La aplicacin minimiza la necesidad

del montaje de la cinta.
La aplicacin minimiza la necesidad

de la manipulacin del papel.
Puntaje:
y conversin son requeridos por el usua-
4: Cuatro cualquiera de los anteriores.
Puntaje:
compactada y/o documentada, para fcil reutilizacin, y la aplicacin est diseada para usarse por medio de los .
parmetros de mantenimiento del usuario.
1: Alguno de los anteriores.
~==========================
ICESI
5: La aplicacin fue especficamente
La complejidad se categoriza as:
res.
3: Seis o ms de las anteriores, pero
4: La aplicacin fue especficamente

compactada y/o documentada, para
fcil reutilizacin, y la aplicacin est
diseada para los usuarios, a nivel del
cdigo-fuente.
5: La aplicacin no requiere la intervencin directa del operador, salvo en

los procesos de arranque y apagado.
3.3.13. Adaptabilidad
Esta caracterstica se refiere a la capacidad que tiene la aplicacin de ser
instalada en mltiples sitios, para mltiples organizaciones.
Pntaje:
o:
No se consideran requerimientos
necesarios para ms de un sitio de instalacin.
1: Se consideran mltiples sitios necesarlos. La aplicacin es diseada para
operar nicamente en ldnticas condiciones de software y hardware.
2: La aplicacin est diseada para
operar nicamente en condiciones similares de hardware y/o software.
3: La aplicacin est diseada para
operar en condiciones diferentes de
hardware y/o software.
4: La documentacin y el plan de soporte son provistos y probados para que
la aplicacin soporte mltiples sitios. Tal
como en los puntajes 1 y 2.
==========================~
ICESI
63
5: La documentacin y el plan de soporte son provistos y probados para que

la aplicacin soporte mltiples sitios. Tal
como en el puntaje 3.
3.3.14. Facilidad de cambio

La aplicacin ha sido especficamente diseada, de forma tal que pueda
soportar cambios fcilmente.
Puntaje:
o: No hay requerimientos especiales
del usuario, con respecto al diseo de
la aplicacin, para minimizar o facilitar
el cambio.
1-5: Seleccionar cualquiera de los
sig~i~ntes tems, de acuerdo con la aplicaclon.
Flexibilidad y consultas sencillas (un
tem).
Flexibilidad en las consultas, de forma que puedan manipular consultas
. simples o medianamentE! complejas
(dos tems).
Flexibilidad en las consultas, de forma que se manejen consultas fciles y complejas (tres tems).
El control de los datos se guarda en
tabla~ que son mantenidas por el
usuario con procesos interactivos,
pero los cambios se efectan nicamente pasado un tiempo.
I~ual que en el anterior, pero los cambiOS se efectan inmediatamente

(dos tems).
I
~
3.4. Clculo del valor del factor

de ajuste
El factor de ajuste se calcula sobre
la base de. las 14 caractersticas generales del sistema. Este valor ms adelante servir para ajustar los puntos de
funcin sin ajuste. El proceso para obtener este valor de ajuste es el siguiente:
Evaluar las 14 caractersticas generales del sistema, de acuerdo con el grado de influencia de cada uno.
Sumar los 14 grados de influencia
para producir un grado de influencia total.
Introducir el grado de influencia en
la siguiente ecuacin, para producir el
factor de ajuste.
(TGI'O.01 )+0.65=VFA
Donde TGI es el total de los 14 grados de influencia y VFA es el valor del
factor de ajuste. Tomemos el siguiente
ejemplo, en el cual se han evaluado las
14 caracteristicas generales de un sistema, obteniendo, para cada una su
grado de influencia:
'
Caractersticas generales del sistema

Transmisin de datos
Procesamiento distribuido
Desempeo
Configuracin
lndice de transacciones
Entrada de datos en lnea
Eficiencia de usuario
Actualizacin en lnea
Complejidad del proceso
Reutilizacin
Facilidad de instalacin
Sencillez de operacin
Adaptabilidad
Flexibilidad
Total de los grados de influencia (TGI)
Valor del Factor de Ajuste (VAF) (42 * 0.01 )+0.65 =
Grados de influencia
3
4
4
2
3
3
4
3
3
2
3
3
2
3
42
1.07
~ES:/~=========================:
Ahora estamos en capacidad de calcular los puntos de funcin, ajustados

de acuerdo con la siguiente ecuacin:
Puntos de Funcin sin Ajuste * VFA =

Puntos de Funcin Ajustados
Supongamos ahora que el ejemplo
de los puntos de funcin sin ajuste anterior, cuyo resultado fue de 288, corresponde a la misma aplicacin a la que se
le calcul el VAF anterior de 1.07. Aplicando la ecuacin anterior, obtenemos
los puntos de funcin, as:
288'1.07=308.16; es decir, obtenemos

un valor aproximado de 308 puntos de
funcin. Finalmente, la estimacin del
nmero de intrucciones-fuente se obtiene a partir de la relacin siguiente:
LDC=66PF.
Para el ejemplo anterior, entonces,
tenemos 20.328 LDC.
Existen relaciones empricas entre
las lneas de cdigo y los puntos de funcin para los lenguajes conocidos, as:
Assembler
320
LDC/PF
150
LDC/PF
Cobol
107
LDC/PF
Fortran
106
LDC/PF
ADA
71
LDC/PF
Lenguajes de bases de datos
40
LDC/PF
Generadores de lenguajes
32
LDC/PF
Orientado a objetos
29
LDC/PF
Lenguaje de consulta
25
LDC/PF
Pascal
85
LDC/PF
LDC/PF
Hoja de clculo
De la tabla anterior se debe tener claro que, por ejemplo, para lenguaje C,
150 lneas de cdigo equivalen a un
punto de funcin.
CONCLUSIONES
1. Son muchos los modelos existentes
para la estimacin y que ofrecen diversas formas de obtener esti
mativos de costos y esfuerzo.
2. Cualquiera que sea el mtodo escogido para la estimacin del costoesfuerzo, es importante que la organizacin que desee realizar estimaciones recolecte y mantenga un con
junto de datos histricos de estimaciones y mtricas de proyectos anteriores, de forma que las estimacio-
nes futuras sean mucho ms confiables.
3. Todo proyecto de desarrollo de software tiene asociado un conjunto de

atributos, ya sean tecnolgicos, econmicos y de mano de obra, los cuales afectan directamente el proceso
de estimacin.
4. Uno de los principales factores que

influyen en el costo y esfuerzo de un
proyecto de software es la complejidad misma del proyecto y el grado
de confiabilidad requerida.
5. Es posible realizar estimaciones en
los proyectos de software, desde ~us
primeras etapas de vida. Para ello,
quienes llevan a cabo la estimacin,
:========================~ ICESI
65
deben conocer a fondo el sistema

por desarrollar, la tecnologa por
emplear y la capacidad humana con
que contar, puesto que con estos
factores se logra un ptimo desarrollo del producto.
6. El estudio de los modelos de estimacin requiere de buen tiempo de
dedicacin, ya que involucra muchos
factores que son difciles de evaluar,
tales como tecnologa, personal, herramientas de desarrollo, etc.
BIBLlOGRAFIA
-
BOEHM, Barry W. Software Engineering

Economics. Prenlice-Hall 1981.
CARO, David N. wilh GLASS, R. Measuring

Software Design Quality. Mc-Graw Hill.
FRANCISCO, Gisbert Cant. Evaluacin de
Costes de Desarrollo - Modelos Algortmicos. Facultad de Informtica. Univer-
PROPUESTA DE INTERCONEXION A INTERNET
sidad Politcnica de Madrid.

-
IEEE. Transactions on software engineering.
Software devrJlopment cost estimation

using functions points. Vol. 20 No. 24 April
1994, pg. 275.
-
IEEE. Transactions on software engineering
Function point analysis: Dificulties and

improvements. Vol. 14 No. 1.January 1988.
PRESSMAN, Rogger S. Ingeniera del software: Un enfoque prctico. Cap. 2 y 3.

Segunda edicin.
JUAN CARLOS MACHADO

ANDRES FELIPE MILLA
JOHN FREDDY VALENCIA
Alumnos del curso de Investigacin de VIII Semestre de Ingeniera de Sistemas del ICESI
INTRODUCCION
De las tres partes en las que ha sido
dividido el proyecto de investigacin
(propuesta de Interconexin a Internet)
presentamos la primera, que constituye
la presentacin terica, la que permite
ubicar un poco el contexto en el que se
va a trabajar.
Con esto pretendemos empezar a
tratar de una forma cronolgica todo lo
necesario para llegar a entender, de
manera clara, lo que es el trabajo en
Internet, lo cual permitir, posteriormente, realizar un estudio de carcter tcnico.
1. DEFINICION
La pregunta que ms frecuentemente se hace es, "qu es Internet?".

La razn por la cual se hace tan a
menudo esta pregunta es que no ha
habido un acuerdo sobre una respuesta que ingeniosamente recapitule a
Internet.
Internet puede ser considerada, a
travs de la relaci6n con sus protocolos
ms comunes, como una coleccin fsi-
~ES:/~=========================:
ca de emutadores (routers) y circuitos,

como un conjunto de recursos compartidos o simplemente como una actitud
de interconexin e intercomunicacin.
Algunas de las definiciones ms comunes dadas en el pasado son:
Una red de redes, basada en los protocolos del TCP/IP.
Una comunidad de gente que usa y
desarrolla las mencionadas redes.
-
Una coleccin de recursos que pueden ser alcanzados, a travs de estas redes.
Hoy en da, Internet es un recurso

global que interconecta a millones de
usuarios, los cuales empezaron como
un experimento (veinte aos atrs) del
Departamento de Defensa de los Estados Unidos de Amrica.
Mientras que las redes que "inventaron" a Internet estn basadas en un conjunto estndar de protocolos (un acuerdo mutuo de mtodos de comunicacin
entre los interesados), Internet cuenta
con pasarelas (gateways), hacia redes
y servicios que estn basados en otros
protocolos.
ICESI
:====::====:==::=:===:==:===~67

Modelos de estimación de costo y esfuerzo en proyectos de software

Uploaded by

Document Information

Original Description:

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

Modelos de estimación de costo y esfuerzo en proyectos de software

Uploaded by

Copyright:

Available Formats

~

MODELOS DE ESTIMACION DE COSTO

RAFAEL ANTONIO GORDILLO

1. Identificar los diferentes modelos

3. Determinar las condiciones bsicas

La complejidad del proyecto: es

la fase de desarrollo del software y sus

El grado de estructuracin del

Al igual que utilizamos el hardware

1.3. Recursos del software

La disponibilidad de informacin histrica tambin determina el riesgo de la

1.4. Software reutilizable

1.1 . Recursos humanos

La mayora de los observadores de

1.2. Categoras del hardware

1.5. Formas de estimacin

que requiere la descomposicin del

d: es uno de los valores estimados

Debe tenerse en cuenta que mientras el LOC se estima directamente, 105

VI: son determinados parmetros independientes (por ejemplo: Lneas de

Las herramientas automticas de

1.6. Parmetros y variables

1.6.1. Lneas de cdigo (LOe)

Oonde E es el esfuerzo estimado en

El exponente especficamente depende

Todava se cuenta con un problema

Los siguientes son ejemplos de modelos tpicos:

E=5.S+0.73(KLDC)'16 Modelo Bailey-Basili

UrmJo:ma Ele estimar el tamao dQj..

control de perifricos, para el cual se tiene un valor optimista de 2.000 LDC, un

ses del desarrollo. Ya que los puntos de

Realizamos el mismo proceso con las

Interfaz de usuario y facilidad de control

1.6.2. Anlisis del punto de funcin

ai-usuarlo. La funcin entregada no est

El enfoque de puntos de funcin (PF)

cuales se dividen en datos y transacciones. Los tipos de funcin de datos

ware. En la resolucin de cada tarea del

En el ltimo paso se calculan los costos y el esfuerzo para cada funcin y se

1.9. Modelos empricos

cos, mocielos muJtivariables'dinml-

La productividad se ve muy influenUn modelo univariable esttico toma

caracterstica del software. Un ejemplo

/Los modelos multivariables esttico~ emplean los datos histricos para

2. COCOMO considera slo las fases

Sin embargo, la aplicacin del modelo

Los costos, esfuerzo y tiempo de las

3. Los costos estimados mediante este

Boehm propuso entonces una jerarqua de modelos de estimacin para el

Las instrucciones se definen como

El modelo inicial, que tena un nico

5. Se supone que despus de la fase

stas no cambiarn substancialmente, aunque evidentemente esto

6. El modelo avanzado del COCOMO

2.1.1. Modo orgnico

zacin y con pleno conocimiento de

Un ambiente generalmente estable

2.1.2. Modo semilibre

tos del sistema que se pretende desarrollar, pero no en todos.

Los modelos COCOMO calculan

Restringido E=3.6(KLDC)120 T=2.5(E)o.32

cin para mantener la informacin sobre materias primas. Se desarrollar una