TEMA III.

Planificacin y Control de
Proyectos Informticos

PRESENTACIN
Al igual que un proyecto constructivo, mecnico o de cualquier producto
nuevo, los de elaboracin de software, necesitan de una planificacin
detallada y de un control riguroso de su realizacin.
En numerosas ocasiones, se emprenden trabajos de esta naturaleza
obviando estas actividades y los ejecutores o jefes de proyectos, no tienen ni
siquiera una fecha de su terminacin, su costo, los beneficios econmicos
que aportar, etc.
Esto se debe a:
a. La poca conciencia que posee el personal de informtica de la importancia
de dichas tareas, debido en muchas ocasiones a que estas actividades no se
tratan en los cursos o carreras donde se forma a este personal.
b. La creencia del personal informtico, de que dichas tareas no debe
hacerlas l sino "otro"; olvidando que el deber elemental de todo
profesionista es saber, inclusive para satisfaccin propia, cual es su
productividad, los beneficios que aporta su trabajo, lo que ha costado, etc.
C. La creencia tambin arraigada de que es muy "difcil", que el trabajo
informtico es "distinto", que no se hayan valores "exactos" y otras
cuestiones completamente subjetivas, ya que la actividad informtica es
como otra cualquiera. Es menos difcil planificar un proyecto informtico que
cortar mil arrobas de caa en un da y no hay nada ms inexacto que saber si
uno va a estar vivo maana y mucha gente tiene su agenda llena de
actividades programadas para el mes prximo.
D. La inexistencia de un mtodo formalizado que sirva de gua para la
ejecucin de estas actividades.
Con este texto se quiere dar solucin a estas cuatro dificultades y se
pretende que adems sirva de base para cursos, seminarios o de estudio
para el personal informtico y a la vez como un mtodo formalizado para la
ejecucin de estas actividades. Por otra parte, se tratar de hacer ver que
estas tareas deben ser desarrolladas por el personal informtico, que no son
difciles ni distintas, que son tan exactas como se necesitan y que en muchos
casos su exactitud depende de uno mismo.

TEMA I. PLANIFICACIN DE TRABAJOS DE PRODUCCIN DE SOFTWARE.

1.1. INTRODUCCION.
Hacer un edificio sin planos, sin un cronograma de ejecucin de la obra y sin
un presupuesto, a nadie se le ocurre. Emprender una travesa transocenica
sin cartas de navegacin y sin rumbo preestablecido, es de una persona que
no esta bien psquicamente. Pero en el terreno de las aplicaciones de la
computacin, estas premisas, tan lgicas para todo proyecto son muchsimas
veces olvidadas y emprendemos una tarea sin saber, qu tiempo se va a
demorar, qu personal se necesita y cunto va a costar. Numerosos proyectos
de desarrollo de software comienzan con el personal que se tenga, no importa
lo que cueste y durara lo que tenga que durar. Hay quien piensa que eso no
importa, que lo importante es que se trabaje "duro" y "a conciencia"; sin
embargo esa misma persona es incapaz de mandar a hacer algn mueble a un
carpintero, sin decirle para que da lo quiere, de que madera lo prefiere y
cuanto esta dispuesto a pagar.
La excusa para esto es: que es muy difcil de estimar, que no existen datos,
que ninguna tarea es igual a otra, que no hay actividades repetitivas, que
depende del "arte" del analista, etc., etc. Pero lo cierto es que cuando se
quiere, cosas ms difciles se planifican y se le calculan los costos; como por
ejemplo predecir cuando va a haber una vacuna contra el SIDA o cuando va a
concluir y cuanto cuesta un proyecto de desarrollo espacial y ambas cosas se
hacen, porque ningn empresario en el mundo que lo sea de verdad y le
interese su dinero o el dinero que el Estado o su empresa pone bajo su
administracin, manda a ejecutar una tarea sin saber cuando se va a terminar,
cuanto le va a costar y que beneficios representar para l y/o la compaa.
Se ha dicho lo anterior porque la actividad de planificacin de proyectos de
desarrollo de software, no ha tiene la prioridad que debe tener.
Los mtodos de la Ruta Crtica, PERT, CPM, etc. que se aplican para planificar
los proyectos constructivos pueden ser utilizados para la planificacin de los
proyectos de software, al igual que los Mtodos Econmico-Matemticos o de
Investigacin de Operaciones, en especial la Programacin Lineal Discreta,
pero hay que estimar muchos parmetros de una forma muy subjetiva o tener
un sistema estadstico de control muy potente.
En las dos ltimas dcadas en el mundo se ha venido trabajando para
encontrar un mtodo especifico para planificar proyectos de desarrollo de
software y aunque se sigue trabajando en este sentido, una etapa fundamental
termin con la publicacin del libro Software Engineering de B.W.Bohem que
recoge su propia experiencia en muchos proyectos desarrollados en los
Estados Unidos y trabajos hechos por otros autores anteriores a l.

Dentro de los diferentes mtodos de estimacin de costos de productos de

software, el modelo COCOMO (COnstructive COst MOdel) desarrollado y
presentado en 1981 por Barry W. Bohem, se enmarca en el grupo de los
modelos algortmicos que tratan de establecer una figura de mrito o relacin
matemtica que
permita estimar el esfuerzo (hombres-mes) y tiempo
requerido
para desarrollar un proyecto, en trminos de nmero de
instrucciones fuente utilizadas en la codificacin del producto de software.
Puede ser que en las condiciones latinoamericanas, las formulaciones
descritas por l no se cumplan exactamente, pero desde el punto de vista
metodolgico y de la filosofa de estimacin de los parmetros, es de gran
utilidad. Ms adelante se detallar como se puede llegar a obtener indicadores
propios para lograr estos parmetros; pero lo que s es cierto es que nadie
puede planificar sin datos, y que cada organizacin debe poseer los
necesarios para poder planificar sus trabajos en el terreno de la computacin
y para ello, los trabajos de Bohem y otros autores pueden servir de punto de
partida.
Como antecedente del mtodo que se explicar se desarrollaron algunos
modelos de este mismo tipo, como fueron:
- Modelo SDC 1965 (Nelson 1966)
- Modelo TRW (Wolverton, 1974)
- Modelo SLIM Putman (Putman, 1978)
- Modelo Doty (Herd y otros, 1977)
- Modelo RCA PRICES (Putman Park, 1979)
- Modelo IBM-FDS (Walston-Felix, 1977)
- Modelo Boeing 1977 (Black y Otros, 1977)
- Modelo GRC 1979 (Carriere-Tribodeau, 1979)
- Meta-Modelo Bailey-Basill (Bailey-Basill, 1981)
En este tema se tratar la planificacin de proyectos de elaboracin de
software o sea, planificacin del trabajo de anlisis, diseo, programacin,
puesta a punto, prueba e implantacin de sistemas automatizados utilizando
los principios del COCOMO.
1.2.FORMA DE APLICACIN. DEFINICIONES Y SUPOSICIONES.
Este mtodo es aplicable en todo trabajo relacionado con los procesos de
produccin de un software nuevo, su mantenimiento o modificacin.
Existen tres niveles de profundidad en su aplicacin y a cada uno
corresponder un conjunto de ecuaciones. El nivel se escoger en
dependencia del grado de conocimiento que se posea del objeto de estudio.
Los niveles son:
a. bsico.

b. intermedio
c. detallado
Las ecuaciones del nivel bsico son adecuadas para realizar estimaciones de
forma rpida aunque sin gran precisin. Su precisin esta necesariamente
limitada dado que, en este nivel no se tienen en cuenta los diferentes
atributos que afectan la realizacin del proyecto como: calidad y experiencia
del personal, restricciones del hardware empleado, utilizacin de modernas
tcnicas y herramientas de produccin de software, etc. En el nivel
intermedio, estos factores se consideran como adicionales al costo total del
proyecto, mientras que en el nivel detallado, se toma en consideracin la
forma en que, cada uno de estos factores afecta la ejecucin en cada una las
diferentes etapas individuales en que se divide el proyecto.
El factor principal sobre el que se basan las estimaciones es el tamao del
producto, es decir el nmero de miles de instrucciones fuente desarrolladas
(mf).
El producto de todo proceso de elaboracin, mantenimiento y/o conversin de
un software son instrucciones, agrupadas en programas y en sistemas y a
partir de su conocimiento se debe planificar el trabajo. El anlisis de sistemas
y su diseo, no tiene objetivo si este no se programa, al igual que no tiene
objetivo la produccin de tres piezas de un equipo que debe tener cuatro.
En mf se incluyen todas las instrucciones creadas o por crear por el personal
asignado al proyecto, y procesadas en cdigo de mquina por alguna de las
combinaciones de preprocesadores, compiladores o ensambladores,
excluyendo las lneas de comentarios. Se consideran las instrucciones de
lenguaje de control de trabajos, las sentencias de formatos y las declaraciones
de datos.
Las instrucciones se definen como lneas de cdigo y por tanto toda lnea que
contenga dos o ms sentencias fuente, se considera como una sola
instruccin.
En el modelo COCOMO se planifican slo las fases del periodo de elaboracin
comprendidas desde el comienzo de la etapa de anlisis hasta el final de la
etapa de implantacin. Los parmetros correspondientes a la etapa anterior
(por ej. Estudio Preliminar) se deben estimar separadamente.
Los parmetros estimados mediante este modelo no incluyen los
relacionados con las actividades de formacin de los usuarios, planificacin
de las instalaciones y trabajos de conversin. S comprende los relativos a la
documentacin de todas y cada una de las etapas, tanto tcnica como
dirigida al usuario, etc.

Las estimaciones cubren todos los costos directos del proyecto, o sea de las
actividades individuales sealadas en el punto anterior. Es decir, incluye la
elaboracin del proyecto y los trabajos de documentacin pero excluye las
correspondientes al personal operador de las computadoras, secretarias,
dirigentes, etc. , a no ser que estos estn ligados directamente al desarrollo
del proyecto.
Los indicadores de planificacin que se pueden obtener a travs del mtodo
son se muestran en la siguiente tabla::
Indicador
Medida
esfuerzo (esf)
hombres-mes
tiempo de desarrollo (tdes)
meses
personal necesario (ch )
hombres
productividad (p)
miles de instrucciones/hombre-mes
costo (c)
pesos
Tabla 1.- Relacin de indicadores que se calculan en el COCOMO
La unidad de esfuerzo hombres-mes supone un total de 152 horas de trabajo
por persona, sobre la base de la experiencia prctica y a consideraciones
sobre vacaciones, permisos, enfermedad, etc.
Para convertir unidades consideradas como hombres-mes, a otras se utilizan
las equivalencias mostradas en la tabla siguiente:
Unidad
Conversin
hombres-mes x 152
hombres-hora
hombres-mes x 19
hombres-da
hombres-mes / 12
hombres-ao
Tabla 2.- Conversin a otras de la medida hombres-mes
En los parmetros por etapas se incluyen todos aquellos que se produzcan
durante el periodo de tiempo que dure sta. Es decir los costos relacionados
con los trabajos relativos a la etapa de programacin no son slo los costos
de codificacin sino tambin los de la documentacin y otros trabajos
directos de esa etapa.
El costo se puede estimar de manera tradicional, acumulando todos y cada
uno de sus componentes, pero tambin de una forma ms sencilla, a partir
del costo por hombres-mes.
Se supone que despus de la etapa donde se establezcan las
especificaciones,
estas
no
cambiarn
sustancialmente,
aunque
evidentemente esto ser inevitable. No obstante, si se producen
modificaciones significativas deben revisarse las estimaciones realizadas.

1.3. PROYECTOS DE PRODUCCIN DE SOFTWARE.

La base de clculo para la produccin de software es la cantidad, en miles de
instrucciones fuentes (ejecutables) que tendr su sistema. Cmo se puede
conocer esto?
Esto slo se puede estimar sobre la base de la experiencia que posea la
persona que vaya a planificar o a desarrollar el software, por analoga con
otros proyectos semejantes o por ciertos clculos que se pueden realizar
como se mostrar ms adelante. Esta experiencia se puede adquirir solamente sabiendo la cantidad de instrucciones que tienen gran cantidad de
proyectos desarrollados por uno o por otras personas. Si nunca ha contado
las instrucciones que tiene un sistema, nunca podr estimar esta cifra, del
mismo modo que si nunca ha tenido hijos no puede conocer el amor que se
siente hacia ellos.
Entonces lo principal es que desde ahora, que ya Ud. conoce la necesidad
que hay de estimar las instrucciones que puede tener su sistema, debe
contar las instrucciones de los sistemas por Ud. desarrollados o por otros.
Adems, como un deber elemental de una persona que realiza determinado
trabajo, se debe conocer lo que uno es capaz de producir. A cualquier obrero
agrcola o industrial que uno le pregunte, es capaz de decir lo que l es
puede de hacer en determinada actividad, cualquier proyectista de la rama de
la construccin o mecnica tambin lo hace; sin embargo, los especialistas
encargados de producir software en muchos casos ni se imaginan su
productividad (instrucciones/mes) y esto es debido a la poca costumbre de
tomar datos estadsticos o econmicos de los proyectos desarrollados.
1.3.1. MODOS DE DESARROLLO DE SOFTWARE.
Hay tres modos de desarrollo de software, que aunque matemticamente
pueden expresarse de forma similar, conducen a estimaciones diferentes en
los parmetros de planificacin, se denominan: orgnico o familiar, semilibre
y fuertemente restringido.
1.3.1.1 MODO ORGNICO.
En el modo orgnico, el equipo de desarrollo es relativamente pequeo y se
desenvuelven en un entorno altamente familiar: la gran mayora de la gente
relacionada con el proyecto tiene una amplia experiencia en otros proyectos
relacionados con la misma organizacin y tienen un buen conocimiento de
como, el sistema
bajo desarrollo contribuir a los objetivos de su
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 generar
grandes necesidades de comunicacin para determinar con precisin las
tareas que cada uno debe desarrollar en el proyecto. Existe por tanto una
gran facilidad para establecer los requisitos y las especificaciones de cada
una de las interfaces del proyecto.
Normalmente el equipo de trabajo puede negociar con facilidad la
modificacin de algunas de las especificaciones para hacer ms fcil este
desarrollo sin que sea demasiado difcil acomodarlo a las necesidades del
desarrollo.
Segn el contenido que establece Bohem para cada una de las etapas
podemos hacer un smil entre ellas y las que se usan normalmente como
sigue:
BOHEM
NORMAL
Planificacin y Requisitos
Estudio preliminar
Diseo
Anlisis
Diseo detallado
Diseo
Codificacin
Desarrollo
Integracin y Prueba
Prueba e implantacin
Tabla 3.- Ciclo de vida para el proyecto segn Bohem y comparacin con el
establecido ms comnmente.
Otros factores caractersticos del modo orgnico son:
- Entorno de desarrollo estable, con poco desarrollo concurrente de nuevo
hardware asociado.
- Mnimas necesidades de introducir algoritmos innovadores
arquitecturas de proceso.

o nuevas

- Un trabajo de proyecto relativamente pequeo. Muy pocos proyectos

desarrollados de modo orgnico sobrepasan los 50 mf (50000 instrucciones
fuente)
- Proyectos en modo orgnico de mayor tamao pueden desarrollarse
utilizando software ya existente.

1.3.1.2. MODO SEMILIBRE.

Este modo representa un estado intermedio entre el modo orgnico y el
modo fuertemente restringido. Este nivel intermedio puede referirse bien a
las caractersticas del proyecto, o bien que el proyecto presenta una mezcla

de caractersticas propias de modo orgnico y otras del modo fuertemente

restringido.
Con respecto a la "experiencia del equipo de trabajo", cualquiera de las
siguientes situaciones puede considerarse propia de un entorno de
desarrollo en modo semilibre:
- Todos los miembros del equipo de diseo tienen un nivel medio de
experiencia en sistemas relacionados con el proyecto.
-

El equipo de desarrollo esta formado por una mezcla de gente experta e

inexperta.

Los miembros del equipo tienen experiencia en algunos de los aspectos

del sistema que se pretende desarrollar pero no en todos.

Esta flexibilidad parcial explica el origen del trmino semidetached

(semidesligado, semimovido, semilibre).
El tamao del producto en este modo puede llegar a 300 mf.
1.3.1.3. MODO FUERTEMENTE RESTRINGIDO.
La caracterstica principal de un proyecto de software de este tipo, es que
debe desarrollarse sometido a fuertes restricciones. El producto debe operar
en entornos software y hardware fuertemente acoplados.
En general los costos de modificar parte del proyecto es tan alto que por sus
caractersticas se podran considera inmodificables. Como resultado, en
estos proyectos no se puede o no existe la posibilidad de negociar fcilmente
cambios en el software y en tal caso precisar un mayor tiempo para
acomodar o asegurar que los cambios cumplan las especificaciones (mayor
costo de verificacin y validacin) y asegurarse de que los cambios se hacen
correctamente (mayor coste de gestin de la configuracin).
Los proyectos en modo fuertemente restringido generalmente abarcan arreas
ms amplias y tambin menos conocidas que los casos anteriores.

1.3.2. ESTIMACIONES EN MODO ORGNICO.

Con los supuestos anteriores y conocidas las etapas del proyecto que
considera el modelo vese como se calcula el esfuerzo (esf) y el tiempo de
desarrollo (tdes).

El esfuerzo (hombres-mes) total necesario en un proyecto, desarrollado en

unas condiciones propias del modo orgnico viene dado por:
1,05
esf = 2,4 (mf)
Donde como ya se indic anteriormente mf es el nmero de instrucciones
fuente desarrolladas. El esfuerzo (esf) es la cantidad de hombres-mes
estimado para las etapas del ciclo de vida, representado en la Tabla 3.
El tiempo de desarrollo expresado en meses de un proyecto en modo
orgnico viene dado por:
0,38
tdes = 2,5 (esf)
Ejemplo 1. Supngase que una empresa cualquiera desea disear un
proyecto que gestione sus inventarios y decide desarrollarlo mediante su
propio equipo de analistas y programadores, que anteriormente y durante
muchos aos, viene desarrollando aplicaciones similares para la empresa. S
un estudio inicial determina que el tamao del producto en alrededor de
32000 lneas de programa fuente (32 mf, cules sern las caractersticas del
proyecto?.
Solucin:
Este es un buen
entonces:

ejemplo de desarrollo de software de modo orgnico,

1,05
1,05
Esfuerzo: esf = 2,4 (mf ) = 2,4(32) = 91 hombres-mes
mf *1000
Productividad: p =

32000
=

esf

= 352 (if/hombres-mes)
91

0,38
0,38
Tiempo de desarrollo: tdes = 2,5 (esf) = 2,5 (91) = 14 meses
Nmero de personas trabajando en el proyecto:
ch = esf/tdes = 91/14 = 6,5 hombres
La cantidad de hombres nos da la medida del nmero equivalente de
personas trabajando a tiempo completo en el proyecto.
La Tabla 4 nos da el tamao promedio de los proyectos informticos y la
Tabla 5 nos muestra los perfiles obtenidos de aplicar las anteriores
ecuaciones a proyectos de tamao promedio.

Tipo
Tamao
Pequeo
2000
instrucciones fuentes
Intermedio
8000
"
"
Medio
32000
"
"
Grande
128000
"
"
Tabla 4.- Proyectos de tamao estndar
Obsrvese que un proyecto "pequeo" es esencialmente el trabajo de una
persona, mientras que un proyecto considerado como "grande" requiere un
nivel medio de 16 personas. Adems, hay que hacer notar que en la tabla 2 la
estimacin de 5 hombres/mes para un proyecto pequeo se refiere al
desarrollo de 2000 instrucciones fuente de producto software, incluyendo por
tanto, el esfuerzo de documentacin, pruebas, correcciones, etc.
Por supuesto, muchos programadores han desarrollado 2 000 instrucciones
de software de uso personal en mucho menos tiempo, por lo que se pueden
recordar las estimaciones de W. Brooks (The Mythical Man-Month) segn las
cuales un producto software requiere tres veces ms esfuerzo que un
programa personal de tamao equivalente o las estimaciones que aparecen
en el libro de Carlos Daz Llorca.
1.3.3 DISTRIBUCIN DE TIEMPO Y ESFUERZO DE POR ETAPAS.
La Tabla 6 presenta los porcentajes de distribucin del esfuerzo y tiempo de
desarrollo entre las distintas etapas del ciclo de desarrollo definido en la
Tabla 3. Esta distribucin varia en funcin del tamao del producto. Los
proyectos de gran tamao precisan mayor tiempo y esfuerzo para desarrollar
las actividades de prueba e implantacin mientras que pueden reducir el
tiempo en la etapa de programacin, distribuyendo esta actividad entre mayor
nmero de programadores trabajando simultneamente. En los pequeos
programas hay que dedicar relativamente ms recursos a la etapa de diseo
y programacin que a las de prueba e implantacin. En modo orgnico todos
los proyectos presentan una distribucin relativamente plana, comparados
con otros modos de desarrollo de software ms restringidos como se ver
ms adelante.

Tamao

Esfuerzo
hombres-mes
Pequeo (2000)
5,0
Intermedio (8000)
21,3
Medio (32 000)
91,0
Grande (128 000)
392,0

Productividad
If/hombres-mes
400
376
352
327

Tiempo
meses
4,6
8,0
14,0
24,0

Personal
hombres
1,1
2,7
6,5
16,0

Tabla 5.- Estimaciones en modo orgnico, nivel bsico para proyectos

estndares.
FASES
PEQUEO
2 mf
6%
16%
68%

TIPOS
INTERMEDIO
8 mf
6%
16%
65%

MEDIO
32 mf
6%
16%
62%

GRANDE
128 mf
6%
6%
59%

25%
40%
19%

24%
38%
22%

23%
36%
25%

ESFUERZO
Estudio preliminar
Anlisis
Diseo y desarrollo
De ella:
Diseo
26%
Desarrollo
42%
Prueba e implantacin
16%
TIEMPO
Estudio Preliminar
10%
Anlisis
19%
Diseo y Desarrollo
63%
Prueba e implantacin
18%
Tabla 6.- Distribucin de tiempo y esfuerzo
bsico.

11%
12%
13%
19%
19%
19%
59%
55%
51%
22%
26%
30%
por etapas, modo orgnico, nivel

Ejemplo 2. Tmese de nuevo la situacin planteada en el ejemplo anterior en

el que se tenia un proyecto de 32 mf, 91 hombres/mes de esfuerzo y 14 meses
de tiempo de desarrollo, supngase que se desea conocer el esfuerzo, el
tiempo y el nmero medio equivalente de personas durante las etapas de
diseo y desarrollo (programacin) de este proyecto.
Solucin:
Utilizando la Tabla 6 se observa que las etapas de diseo y programacin
requieren el 62% del esfuerzo total y el 55% del tiempo total, por tanto:
Esfuerzo: esf = 0,62(91) = 56 hombres-mes
Tiempo: tdes = 0,56(14) = 7,7 meses
Personal: ch = 56/7,7 = 7,5 hombres
Los valores nominales obtenidos para cada tamao del proyecto estndar se
dan en la Tabla 7, junto con los valores relativos a la productividad del
proyecto total y el personal equivalente necesario en cada etapa.
En las Tablas 6 y 7 se expresan tambin los valores correspondientes a la
etapa de estudio preliminar aunque esta no es considerada dentro de las
estimaciones del modelo. Ntese que la suma de todos los por cientos
menos los de esta etapa suman 100%.

De la Tabla 7 se pueden extraer algunos datos comparativos, relativos al

esfuerzo y tiempo dedicados entre las diferentes etapas as como respecto a
la magnitud de algunos efectos que aparecen cuando incrementamos el
tamao del producto. As, con respecto a la productividad observamos que
se produce una disminucin casi proporcional segn va aumentando el
tamao del producto. Las principales razones por las cuales los grandes
productos software incurren en esta disminucin de productividad son las
siguientes:
1. Soportar las actividades paralelas de un gran nmero de programadores
exige un esfuerzo relativamente mayor para establecer minuciosamente las
especificaciones del diseo en el mbito de cada una de las unidades.
2. Se precisa mayor esfuerzo para verificar y validar, cuanto mayor sea el
nmero de especificaciones establecidas.
3. Incluso cuando las especificaciones del producto se establecen
minuciosamente, en un gran proyecto, los programadores consumen ms
tiempo comunicando y resolviendo interfaces tiles.
4. Se precisa un mayor esfuerzo de integracin entre las diferentes unidades
que componen el producto total.
5. En general se requieren unas pruebas ms amplias y detalladas para
verificar y validar un producto software de mayor tamao.
6. Los grandes proyectos normalmente exigen mayor esfuerzo.
1.3.4. PROYECTOS DE TAMAO NO ESTNDAR. INTERPOLACIN.
En el supuesto de que el tamao del producto no se ajuste a los tamaos
estndares de las Tablas 4 y 5 se puede obtener el perfil del proyecto por
interpolacin de los datos de los proyectos estndares de tamao inferior y
superior de las citadas Tablas.
Ejemplo 3. Supngase que se desea obtener el esfuerzo necesario en la etapa
de programacin (desarrollo) de un producto de software cuyo tamao se fija
en 12800 lneas fuente. Aplicando las ecuaciones ya conocidas se obtiene
fcilmente el esfuerzo total y el tiempo de desarrollo:
1,05
Esfuerzo: esf = 2,4(12,8) = 35 hombres-mes
0,38
Tiempo de desarrollo: tdes = 2,5(35) = 9,7 meses

Para obtener el esfuerzo necesario en la etapa de programacin, utilizamos

los datos de la Tabla 6 referidos a los proyectos de 8 mf y 32 mf. El
porcentaje sobre el esfuerzo total de nuestro proyecto estar comprendido
entre el 65% y el 62%.
(12,8 - 8)
% prog = 65 +

(62-65) = 64,4
(32 - 8)

y por tanto el esfuerzo dedicado a la fase de programacin seria:

esf prog = 0,644 x 35 = 22,5 hombres-mes
De la misma forma se obtiene el tiempo consumido en la etapa de desarrollo
que supone el 58,2 % del tiempo total (5,6 meses) y por tanto el valor medio
de personal equivalente en la fase de programacin seria de:
ch = 22,5 / 5,6 = 4 hombres.
1.3.5. MODOS SEMILIBRE Y FUERTEMENTE RESTRINGIDO. NIVEL BSICO
La Tabla 8 presenta las ecuaciones actuales para los tres modos de
desarrollo del nivel bsico.
Las estimaciones obtenidas para los diferentes proyectos estndares a los
que se le ha aadido uno nuevo de 512 mf (muy grande), se presentan en la
Tabla 9.

F A S E S
ESFUERZO
Estudio Preliminar
Anlisis
Diseo y desarrollo
De ella:
Diseo
Desarrollo
Prueba e implantacin
TIEMPO
Estudio Preliminar
Anlisis
Diseo y desarrollo
Prueba e implantacin
PERSONAL
Estudio Preliminar
Anlisis
Diseo y desarrollo
Prueba e implantacin

PEQUEO
2 MF

INTERMEDIO
8 MF

MEDIO
32 MF

GRANDE
128 MF

0,3
0,8
3,4

1,3
3,4
13,8

5,0
15,0
56,0

24,0
63,0
231,0

1,3
2,1
0,8

5,3
8,5
4,1

22,0
34,0
20,0

90,0
141,0
98,0

0,5
0,9
2,9
0,8

0,8
1,5
4,7
1,8

1,7
2,7
7,7
3,6

3,1
4,6
12,2
7,2

0,6
0,9
1,2
1,0

1,4
2,3
2,9
2,3

2,9
5,6
7,3
5,6

8,0
14,0
19,0
14,0

50%
84%
113%
85%

46%
84%
116%
83%

% DE CH POR FASE
RESPECTO
AL TOTAL DEL PROYECTO

Estudio Preliminar
60%
55%
Anlisis
84%
84%
Diseo y desarrollo
108%
110%
Prueba e implantacin
89%
87%
Productividad
En todo el proyecto
400
376
Tabla 7.- Indicadores en por cientos, modo orgnico,
proyectos estndares.

352
327
nivel bsico para

1.3.5.1. DISTRIBUCIN DE ESFUERZO Y TIEMPO POR ETAPAS.

Una vez presentados los tres modos de desarrollo y vistas las diferencias
entre ellos, es de esperar que las estimaciones para cada una de las etapas
del proyecto difieran considerablemente de un modo al otro.
La Tabla 10 da la distribucin del esfuerzo y tiempo para cada una de las
etapas en los tres modos de desarrollo. Su utilizacin es idntica al caso del
modo orgnico presentado anteriormente.
Se observa que un proyecto en modo fuertemente restringido consume
mucho ms esfuerzo en la etapa de implantacin como consecuencia de la

necesidad de realizar un seguimiento ms cuidadoso para comprobar y

verificar todas las unidades del producto.
Sin embargo, proporcionalmente, se precisa menos esfuerzo para la etapa de
desarrollo. No porque se le dedique menos esfuerzo a la codificacin, sino
porque, comparativamente, los otros modos consumen ms esfuerzo en las
otras etapas, en trabajos de modificacin y acomodacin de cambios en las
especificaciones.
Igualmente, un proyecto fuertemente restringido consume un porcentaje
menor de tiempo en la etapa de programacin, como resultado de la
necesidad de dedicar mayor cantidad de tiempo total de desarrollo.
Ejemplo 4. Un grupo de trabajo va a desarrollar un proyecto que se estima
tenga 20 mf. El proyecto se desarrollar bajo las siguientes condiciones:
- El grupo de trabajo tiene experiencia y es muy unido.
- El grupo de trabajo no pertenece a la organizacin.
- Las especificaciones del proyecto no pueden variarse bajo ningn
concepto
- No hay que introducir algoritmos innovadores.
- Proyecto pequeo.
- Esfera de trabajo poco conocida.
Estime para ese proyecto todos sus parmetros por etapas.
Solucin:
EL modo de desarrollo es evidentemente semilibre.
Para 20 mf en modo semilibre interpolando en la Tabla 9:
esf = 88,5 hombres-mes
tdes = 11.1 meses
Clculos:
ch = esf/tdes = 88,5/11,1 = 7,9 hombres.
p = mf/esf = 226 mf/hombres-mes

Esfuerzo por Etapas (hombres-mes):

Interpolando en la Tabla 10:
1. Etapa Estudio Preliminar:
7 % de esf =

7(88,5) = 6,19

2. Etapa Anlisis:
17 % de esf = 17(88,5)= 15,04
3+4. Etapas Diseo y Desarrollo:
59,5 % de esf = 59,5(88,5) = 52,66
5. Etapa Prueba e Implantacin:
23,5 % de esf = 23,5(88,5) = 20,8
Tiempo de desarrollo por etapas (meses):
Interpolando en la Tabla 10.
1. 19 % de tdes

19(11,1) = 2,11

2. 25,5 % de tdes 25,5(11,1) = 2,83

3+4. 50 % de tdes

50(11,1) = 5,55

5. 24,5 % de tdes 24,5(11,1) = 2,71

Personal (hombres) por etapas:
1. 6,19/2,11 = 2,9 hombres
2. 15,04/2,83 = 5,3 hombres
3+4. 52,66/5,55 = 9,5 hombres
5. 20,8 /2,71 = 7,7 hombres
Esfuerzo por Etapas (hombres-mes):
Interpolando en la Tabla 10:
1. Etapa Estudio Preliminar:

7 % de esf =

7(88,5) = 6,19

2. Etapa Anlisis:
17 % de esf = 17(88,5)= 15,04
3+4. Etapas Diseo y Desarrollo:
59,5 % de esf = 59,5(88,5) = 52,66
5. Etapa Prueba e Implantacacin:
23,5 % de esf = 23,5(88,5) = 20,8
Tiempo de desarrollo por etapas (meses):
Interpolando en la Tabla 10:
1. 19 % de tdes

19(11,1) = 2,11

2. 25,5 % de tdes 25,5(11,1) = 2,83

3+4. 50 % de tdes

50(11,1) = 5,55

5. 24,5 % de tdes 24,5(11,1) = 2,71

Hombres por etapas:
1. 6,19/2,11 = 2,9 hombres
2. 15,04/2,83 = 5,3 hombres
3+4. 52,66/5,55 = 9,5 hombres
5. 20,8 /2,71 = 7,7 hombres
Como se observa, la cantidad de hombres necesarios por etapas no es la misma ni
da un nmero entero. Esto puede llevarnos a la necesidad de ajustar el nmero
obtenido a una cantidad determinada y como se posee el esfuerzo necesario, volver
a calcular el tiempo de desarrollo y as establecer un balance entre las necesidades
del proyecto y las posibilidades de fuerza de trabajo que se puede asignar a ste
para una etapa determinada.
MODO
ESFUERZO
TIEMPO DE
DESARROLLO

ORGNICO

1,05
esf = 2,4(MF)
SEMILIBRE
1,12
esf = 3,0(MF)
FUERTEMENTE
1,20
RESTRINGIDO
esf = 3,6(MF)
Tabla 8.- Esfuerzo y tiempo de desarrollo, nivel bsico.

0,38
tdes = 2,5 (esf)
0,35
tdes = 2,5 (esf)
0,32
tdes = 2,5 (esf)

1.3.6. NIVEL INTERMEDIO.

En el nivel intermedio se toman en cuenta un conjunto de factores que
afectan el proyecto en su totalidad y no se toma la afectacin particular de
estos factores en las distintas etapas o fases.
Para el nivel intermedio los valores de esfuerzo y tiempo de desarrollo son
semejantes a los del nivel bsico aunque en estudios ms recientes se
plantea que en las ecuaciones del esfuerzo hay una ligera variacin con
respecto a las del nivel bsico estas son:
1,05
modo orgnico: esf = 3,2 (mf )
1,12
modo semilibre: esf = 3,0 (mf )
1,20
modo fuertemente restringido: esf = 2,8 (mf )
En el nivel intermedio este esfuerzo que se pudiera llamar "nominal", se ve
afectado por una serie de coeficientes que dependen de las caractersticas o
atributos del producto, de la computadora para la cual se esta haciendo el
proyecto, del personal y del propio proyecto.
En la Tabla 11 se muestran los factores que afectan el esfuerzo nominal y la
cuanta en que se afectan estos de acuerdo a los niveles que pose el proyecto
en cada uno de ellos: muy bajo, bajo, nominal, alto, muy alto y extra alto.
En la Tabla 13 se muestran las caractersticas que hacen que cada atributo sea
considerado en algunas de estas categoras, se hace una excepcin con el
atributo "Complejidad del Producto" (CPR) cuya valoracin se muestra en
Tabla 12. Este atributo depende a su vez de la complejidad de las operaciones
de control, aritmticas, de entrada y salida y de manejo en la base de datos.
Ntese en la Tabla 12 que algunos factores hacen que se aumente el esfuerzo
nominal y otros que disminuya.

INDICADOR/
MODO

PEQUEO INTERMEDIO MEDIO GRANDE

2 MF
8 MF
32 MF
128 MF

ESFUERZO
ORGNICO
5,0
21,3
91,0
392,0
SEMILIBRE
6,5
31,0
146,0
687,0
FUERTEMENTE
8,3
44,0
230,0
1216,0
RESTRINGIDO
PRODUCTIVIDAD
ORGNICO
400
376
352
327
SEMILIBRE
308
258
219
186
FUERTEMENTE
241
182
139
105
RESTRINGIDO
TIEMPO DE
DESARROLLO
ORGNICO
4,6
8,0
14,0
24,0
SEMILIBRE
4,8
8,3
14,0
24,0
FUERTEMENTE
4,9
8,4
14,0
24,0
RESTRINGIDO
PERSONAL
ORGNICO
1,1
2,7
6,5
16,0
SEMILIBRE
1,4
3,7
10,0
29,0
FUERTEMENTE
1,7
5,2
16,0
51,0
RESTRINGIDO
Tabla 9.- Estimaciones en nivel bsico para productos estndares.

MUY
GRANDE
512 MF
3250,0
6420,0

158
80

42,0
41,0

77,0
157,0

Los factores se muestran en la Tabla 11.

Se detallar ahora cada uno de los indicadores y cmo se determina su nivel.
1.3.6.1. Requerimientos de Seguridad del Software. (RSS)
Se consideran los siguientes niveles de este indicador:
Muy bajo: El efecto de una falla en el software diseado es simplemente un
defecto del sistema.
Bajo: El efecto de una falla en el software diseado es de bajo nivel con
prdidas fcilmente recuperables para los usuarios. Como ejemplo se
pueden citar los errores que surgen en una planificacin a largo plazo.

INDICADOR/MODO

ETAPAS

PEQUEO
2 mf

INTERMEDIO8
8 mf

MEDIO
32 mf

GRANDE
128 mf

MUY
GRANDE
512 mf

ESFUERZO
ORG-NICO

SEMILIBRE

FUERTEMENTE
RESTRINGIDO

TIEMPO DE
DESARROLLO
ORGNICO

SEMILIBRE

FUERTEMENTE
RESTRINGIDO

Estudio
Preliminar
Anlisis
Diseo y
desarrollo
Diseo
Desarrollo
Prueba e
implantacin
Estudio
Preliminar
Anlisis
Diseo y
desarrollo
Diseo
Desarrollo
Prueba e
implantacin
Estudio
Preliminar
Anlisis
Diseo y
desarrollo
Diseo
Desarrollo
Prueba e
implantacin

Estudio
Preliminar
Anlisis
Diseo y
desarrollo
Prueba e
implant
Estudio
Preliminar
Anlisis
Diseo y
desarrollo
Prueba e
implant
Estudio
Preliminar
Anlisis
Diseo y
desarrollo
Prueba e
implantacin

6%

6%

6%

6%

16%
68%

16%
65%

16%
62%

16%
59%

26%
42%
16%

25%
40%
19%

24%
38%
22%

23%
36%
25%

7%

7%

7%

7%

7%

17%
64%

17%
61%

17%
58%

17%
55%

17%
52%

27%
37%
19%

26%
35%
22%

25%
33%
25%

24%
31%
28%

23%
29%
31%

8%

8%

8%

8%

8%

18%
60%

18%
57%

18%
54%

18%
51%

18%
48%

28%
32%
22%

27%
30%
25%

26%
28%
28%

25%
26%
31%

24%
24%
34%

10%

11%

12%

13%

19%
63%

19%
59%

19%
55%

19%
51%

18%

22%

26%

30%

16%

18%

20%

22%

24%

24%
56%

25%
52%

26%
48%

27%
44%

28%
40%

20%

23%

26%

29%

32%

24%

28%

32%

36%

40%

30%
48%

32%
44%

34%
40%

36%
36%

38%
32%

22%

24%

26%

28%

30%

Tabla 10. Esfuerzo y tiempo de desarrollo por estapas. Todos los modos.
Nominal: El efecto de una falla es de prdidas moderadas para los usuarios
pero una situacin de la cual uno puede salir sin una penalizacin extrema.
Ejemplo de ello son los sistemas de Abastecimiento Tcnico Material.

SIGLAS

ATRIBUTOS DEL PRODUCTO

RSS
TBD
CPR

Requerimientos de Seguridad del Software

Tamao de la Base de Datos
Complejidad del Producto
ATRIBUTOS DE LA COMPUTADORA
RTE
Restricciones de Tiempo de Ejecucin
RMP
Restricciones de Memoria Principal
VMC
Velocidad con que cambian los Medios de Cmputo
TRC
Tiempo de Respuesta de la Computadora
ATRIBUTOS DEL PERSONAL
CAN
Capacidad de los Analistas
EAN
Experiencia de los Analistas
CPRO
Capacidad de los Programadores
ESO
Experiencia en el Sistema Operativo
ELP
Experiencia en el Lenguaje de Programacin
ATRIBUTOS DEL PROYECTO
UTP
Uso de Tcnicas modernas de Programacin
UHS
Utilizacin de las Herramientas de Software
RPL
Requisitos de Planificacin
Tabla 11.- Factores que se analizan en el modo intermedio.
Alto: El efecto de una falla implica grandes prdidas financieras o molestias a
un gran nmero de personas. Ejemplo de ello los sistemas de distribucin
elctrica.
Muy alto: El efecto de una falla puede significar prdidas de vidas humanas.
1.3.6.2. Tamao de la Base de Datos. (TBD)
Se toma el tamao de la base de datos en kbytes y se divide entre la cantidad
de instrucciones mf, en dependencia del valor obtenido se toma la complejidad
de este indicador. Es lgico que para poder obtener el tamao de la base de
datos, deban estar definidos, los archivos, los campos, la longitud de estos y
estimadas la cantidad de artculos. La fuente de informacin para ello es el
diccionario de datos del anlisis y el estudio del sistema actual realizado.
Para la familia dBase a los archivos de datos se le puede calcular su volumen
por la frmula:
Dbase II. V.dbf = 9 + (CC*16) + CA(LA + 1) (caracteres)
Dbase III. V.dbf = 34 + (CC*32) + CA(LA + 1) (caracteres)

N I V E L E S
FACTOR MUY BAJO BAJO NOMINAL ALTO MUY ALTO
RSS
0,75
1,00
1,15
1,40

EXTRA ALTO
-

TBD
CPR
RTE
RMP
VMC
TRC
CAN
EAN
CPRO
ESO
ELP
UTP
UHS
RPL

0.70
1,46
1,29
1,42
1,21
1,14
1,24
1,24
1,23

0,94
0,85
0,87
0,87
1,19
1,13
1,17
1,10
1,07
1,10
1,10
1,08

1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00

1,08
1,15
1,11
1,06
1,15
1,07
0,86
0,91
0,86
0,96
0,95
0,91
0,91
1,04

1,16
1,30
1,30
1,30
1,30
1,15
0,71
0,82
0,70
0,82
0,83
1,10

Tabla 12.- Valores de los factores que afectan el esfuerzo.

Donde: CC - Cantidad de campos del arch ivo de datos.
CA - Cantidades registros de datos estimada.
LA - Longitud del registro de datos (caracteres).
V.dbf- Volumen del arch ivo de datos (Bytes).
Para los archivos ndices:
dBase II
CK = 509/ (LK + 4)
dBase III
CK = 509/ (LK + 8)
dBase III+ CK = 507/ (LK + CBC)
FoxBase
CK = 509/ (LK + 8)
Clipper
CK = 1022/(LK + 8)
Donde: CBC = 8 si RESTO = 0
CBC = 9 si RESTO = 1
CBC = 10 si RESTO = 2
CBC = 11 si RESTO = 3
y:
RESTO = LK - {[Parte Entera(LK/4)]*4}
Para todos los dBase:
CB1 = CA/CK
B2 = CB1/CK
n
CBT =

CBi

I=1
CBn = 1
y:

V.ndx = 512 + 512 CBT

V.idx = 512 + 512 CBT

1.65
1.66
1,58
-

V.ntx = 1024 + 1024 CBT

Donde: CK - Cantidad de entradas de llave
LK - Longitud de la llave (caracteres)
CA - Cantidad de registros de datos
CBn- Cantidad de bloques de datos en el nivel n
CBT- Cantidad de bloques de datos total
V.ndx - Volumen de datos del arch ivo.ndx (Bytes)
V.idx - Volumen de datos del arch ivo.idx (Bytes)
V.ntx - Volumen de datos del arch ivo.ntx (Bytes)
Para otros tipos de archivos, consultar la literatura especializada
1.3.6.3. Complejidad del Producto.(CPR)
La complejidad del producto, subsistemas o tareas a desarrollar depende del
tipo de operaciones de control, aritmticas, de entrada y salida y de manejo de
la base de datos que contenga dicho producto. Se debe ver en la Tabla 14 que
nivel tiene en su producto estas operaciones y ponderando segn lo que
usted conoce del anlisis del sistema actual obtener un nivel nico general.
1.3.6.4. Restricciones de Tiempo de Ejecucin.
Se debe estimar el tiempo necesario para la ejecucin de este componente y
calcular el tiempo disponible de computacin, se divide uno entre otro y se
multiplica por 100 para hallar el por ciento, con este nmero se entra a la Tabla
13 para hallar el nivel de complejidad de este indicador.
El tiempo de ejecucin podr determinarse mediante la siguiente frmula:
TE = TED + TEA + TSD (Horas/da)
Donde:

TED - Tiempo consumido en la entrada de los datos (hr/da)

TEA - Tiempo de ejecucin y acceso a archivos (hr/da)
TSD - Tiempo consumido en la salida de los datos (hr/da)
VDE

TED =
RE * 3600

VDS
TSD =
RS * 3600
Donde: VDE - Volumen de datos de entrada (caracteres/da)

RE- Rapidez de la entrada de datos (cps)

VDS - Volumen de datos de salida (caracteres/da)
RS - Rapidez de salida de los datos (cps)
n

Ij

VDE o VDS =

(caracteres)

j=1
m

Aij

CIj =

i=1
Donde: Aij - Longitud del dato i en el flujo j. (caracteres)
CIj - Capacidad de informacin del flujo j (caracteres)
m - Cantidad de datos de un flujo
n - Cantidad de flujos de entrada o de salida.
El tiempo de ejecucin y acceso a archivo depende del tipo de proyecto
(gestin, inteligencia artificial, clculo cientfico, etc.), del tipo de mquina, del
sistema operativo, del sistema de gestin de base de datos, etc.
Este tiempo puede calcularse, a travs de programas realizados anteriormente
del mismo tipo o diseados para ello propiamente, que simulen la ejecucin de
las instrucciones y los accesos y a partir de ellos calcular "k11" (tiempo
promedio de ejecucin en segundos por cada mil instrucciones) y entonces se
puede calcular TEA as:
k11 * mf
TEA =

(horas/da)
3600

El tiempo de ejecucin y acceso a archivos, es despreciable frente a

(TED+TSD) en sistemas de gestin y es grande con respecto a (TED+TSD) en
procesos que contengan Mtodos Econmico-Matemticos, Estadsticos, de
Simulacin, etc.

MUY BAJO

BAJO

N I V
NOMINAL

RSS

SLO
DEFECTOS

POCAS
PRDIDAS

PRDIDAS
MODERADAS

TBD

KB/MF

>10<= 10

E S
ALTO

GRANDES
PRDIDAS
FINANCIERAS
KB/MF

MUY ALTO
PRDIDAS
HUMANAS
-

EXTRA
ALTO
MUCH AS
PRDIDAS
HUMANAS
-

RTE

RMP

VMC

TRC

MAYOR 12m
MENOS 1m
INTERACTIV
O
35 perc.
1 ao
35 perc.
4 meses
4 meses
SE USAN
EXPERIMENTALMENTE
HERR. BS.
MINICOMP.
O FUERTES
MICROCOMP
.
85% TDES
NOMINAL

CAN
15 perc.
EAN
4 meses
CPRO
15 perc.
ESO
1 mes
ELP
1 mes
UTP NO SE USAN

UHS

HERRAM.
BSICAS
MICROCOMP|

RPL

75% TDES
NOMINAL

> 100 <= 100

> 1000 <= 1000
V E R F I G U R A 1.10
MENOS DEL
< 70%
50% DEL
USO DEL
TIEMPO
DISPONIBLE
MENOS DEL
< 70%
50% DEL
USO DE LA
MEMORIA
DISPONIBLE
MAYOR 6m
MAYOR 2m
MENOR 2s
MENOR 1s
< 4 Horas
4 - 12 Horas

< 85%

< 95%

< 85%

< 95%

MAYOR 2s
MENOR 2d
| > 12 Horas

55 perc.
3 aos
55 perc.
1 ao
1 ao
TIENEN
ALGN USO

75 perc.
6 aos
75 perc.
3 aos
3 aos
TIENEN
BASTANTE USO

HERR. BS.
MAINFRAME
O FUERTES
MINICOMP.

UTILIT.
MNIMOS DEL
MAINFRAME

90 perc.
12 aos
90 perc.
SON DE
USO
RUTINARIO
TODOS LOS
UTILIT. DEL
MAINFRAME

100% TDES
NOMINAL

130% TDES
NOMINAL

160% TDES
NOMINAL

Tabla 13.- Forma de determinar el nivel del factor.

El tiempo de ejecucin y acceso a archivos, es despreciable frente a
(TED+TSD) en sistemas de gestin y es grande con respecto a (TED+TSD) en
procesos que contengan Mtodos Econmico-Matemticos, Estadsticos, de
Simulacin, etc.
1.3.6.5. Restricciones de Memoria Principal. (RMP)
Se estima la cantidad de memoria que se necesita para la ejecucin de este
componente, se divide entre la memoria disponible del computador y se
multiplica por 100 para hallar el por ciento, con este nmero se entra a la Tabla
12 para hallar el nivel de complejidad de este indicador.

NIVEL

OPERACIONES DE
CONTROL

OPERACIONES
MATEMTICAS

OPERACIONES DE
ENTRADA/SALIDA

MUY BAJO

Cdigos lineales:
DO
IF-THEN-ELSE

Evaluacin de
expresiones
matemticas simples:

Lecturas simples
Escrituras con formatos
simples.

OPERACIONES
DE MANEJO DE
DATOS
Arreglos
simples en
memoria RAM.

Predicados simples,
pocas subrutinas.
Subrutinas en
secuencia la mayor
parte en predicados
simples.

Evaluacin de
expresiones
reiteradas. Races y
Potencias.

NOMINAL

Programacin
Estructurada (PE).
Mayormente
subrutinas simples.
Tablas de decisin.

Uso de subrutinas
matemticas y
estadsticas.
Operaciones con
matrices y vectores.

ALTO

Programa
estructurado con
muchas subrutinas.
Considerables
mdulos. Colas.
Pilas.

Anlisis numrico.
Interpolacin
multivariable.
Ecuaciones
diferenciales.

Optimizacin del
solapamiento de E/S.
Operaciones de E/S a
nivel fisico.

MUY ALTO

Cdigo reentrante y
recursivo. Prioridad
fija de interrupcin
manual.

Ecuaciones con
matrices singulares.
Ecuaciones
diferenciales
parciales. Anlisis
numrico difcil.

Subrutinas para
interrumpir el servicio.
Manejo de lneas de
comunicacin.

EXTRA
ALTO

Programacin
mltiple. Cambios
dinmicos de
prioridad.
Microcdigo.

Anlisis numrico
difcil y no
estructurado. Anlisis
muy preciso. Mtodos
estocsticos.

Operaciones
microprogramables.

BAJO

C = A+B*(D-E).
No se necesitan
procesos especiales de
E/S. Slo toma y
entrega de informacin.
No hay solapamiento.
E/S comprende
selecciones, chequeos
de estado y tratamiento
de errores.

Arch ivos
simples sin
cambios en la
estructura de
datos.
Mltiples archivos de E/S.
Cambios
simples en la
estructura de
datos.
Complejas
reestructuracio
nes de los
datos.
Subrutinas
activadas por el
FD.
Uso
generalizado de
lo anterior.
Archivo
comando de
procesamiento.
Optimizacin de
bsqueda.
Direccin de
datos en
lenguaje
natural.
Estructuras
dinmicas
altamente
enlazadas

Tabla 14.- Evaluacin del factor complejidad del producto.

La cantidad de memoria principal ocupada se puede calcular mediante la
frmula:
MP = MOS + MOP + MOD
Donde: MOS - Memoria ocupada por el Software instalado.
MOP - Memoria ocupada por los programas.
MOD - Memoria ocupada por los datos.
La MOS debe conocerse con anticipacin y dominarse.
Por ejemplo:
COMMAND.COM (VER 3.2) 23612 COMMAND.COM (VER 2.1) 25276
FOXPLUS.EXE
240640 FOXPLUS.OVL
136592
BASICA.COM
25984 CLIPPER.LIB
307019

WS
ASSIGN.COM
SYS.COM
BACKUP.EXE
DISKCOMP.EXE
FORMAT.EXE

142388 APPEND.COM
1523 PARK.COM
4607 RESTORE.EXE
23404 DEBUG.EXE
3808 DISKCOPY.EXE
11015

1725
376
21750
15647
4096

La MOP se puede calcular a partir de las instrucciones fuente que tendr su

sistema y un indicador estadstico k4 que se posea de la siguiente forma:
MOP = k4 * mf
Donde: mf - miles de instrucciones fuente
k4 - kbytes de memoria por cada mil instrucciones
Este indicador k4 depender del lenguaje a utilizar y puede ser hallado a travs
de programas hechos por Ud. o por otras personas. Segn clculos
realizados:
PROLOG
BASIC.
Turbopascal
Wordstar

k4 = 34 bytes/ instruccin
k4 = 44 bytes/ instruccin
k4 = 31 bytes/ instruccin
k4 = 48 bytes/ lnea

La Memoria ocupada por los datos ser:

MOD = CBA * DB
CBA - Cantidad de buffers abiertos por la configuracin
DB - Dimensin del buffer
1.3.6.6 Velocidad con que cambian los Medios de Computo. (VMC)
La velocidad de cambio de los medios de cmputo es la frecuencia de cambio
del hardware y el software necesario para las tareas.
* Si el proyecto a desarrollar es un sistema operativo es la velocidad con que
cambia el hardware de la computadora.
* Si el proyecto a desarrollar es un Sistema de Gestin de Base de Datos
(SGBD) es la velocidad con que cambia el hardware de la computadora y el
sistema operativo.
* Si el subsistema a desarrollar es una aplicacin del Sistema de Base de
Datos es la velocidad del cambio del hardware de la computadora, el sistema
operativo y el sistema de base de datos.

De acuerdo con la frecuencia de cambio se entrar en la Tabla 12 y se hallar

el nivel de este indicador.
1.3.6.7. Tiempo de Respuesta del Computador. (TRC).
Al mandar a correr una tarea esta se demora determinado tiempo desde que se
entrega por el usuario hasta que esta se devuelve. Segn se estime que sea
este tiempo se entra en la Tabla 12 y se halla el nivel de este indicador.
Todos los trabajos que se realicen en forma interactiva tienen este indicador
"bajo". Para el trabajo en lote son los dems niveles.
1.3.6.8. Capacidad de los analistas. (CAN)
La capacidad de los analistas se mide en trminos de percentiles con respecto
a la poblacin total de analistas de sistemas. Los atributos que deben ser
considerados son: habilidad para el anlisis, eficiencia e integridad y habilidad
para la comunicacin y cooperacin. Este atributo es del conjunto de analistas
como un equipo ms que una suma de ellos individualmente. De acuerdo al
valor estimado por Usted se entra en la Tabla 12 para hallar el nivel de este
indicador.
1.3.6.9. Experiencia de los Analistas. (EAN)
Es el tiempo de trabajo promedio que lleva el grupo de analistas en la actividad
de anlisis dentro de la rama en que se esta haciendo el sistema esta. Con
este valor se entra en la Tabla 12 para hallar el nivel de este indicador.
1.3.6.10. Capacidad de los programadores. (CPRO)
De este indicador se puede decir lo mismo que de CAP salvo que lo principal
es la habilidad para programar en vez de la habilidad para el anlisis. El
percentil ser con respecto a la poblacin de programadores. Con el valor del
percentil se entra a la Tabla 12 y se halla el nivel de este indicador.
1.3.6.11. Experiencia en el Sistema Operativo. (ESO)
Es el tiempo promedio de experiencia en el sistema operativo de todo el grupo
de analistas y programadores. Con este valor se entra en la Tabla 12 para
hallar el nivel de este indicador.
1.3.6.12. Experiencia en el Lenguaje de Programacin. (ELP)
Es el tiempo promedio de experiencia en el lenguaje de programacin de
analistas y programadores. Con este valor se entra en la Tabla 12 para hallar el
nivel del indicador.

1.3.6.13. Uso de Tcnicas modernas de Programacin. (UTP)

En el uso de modernas tcnicas de programacin esta incluido:
- Anlisis y diseo TOP-DOWN.
- Uso de una notacin modular y jerrquica en el diseo.
- Hacer preplanes para revisar el diseo detallado y la codificacin
de cada unidad de software.
- Cdigo estructurado.
- Uso de programas de gestin de bibliotecas.
El nivel se determinar as:
- Muy bajo - No se usan estas herramientas.
- Bajo - Se usan experimentalmente.
- Nominal - Tienen algn uso.
- Alto - Tienen bastante uso.
- Muy alto - Se utilizan de forma rutinaria.
De acuerdo al uso que tengan estas tcnicas por el equipo de diseo se entra
en la Tabla 12 y se halla el nivel de este indicador.
1.3.6.14. Uso de modernas Herramientas de Software. (UHS)
Se considera el uso de:
Muy bajo: Ensamblador
Editor de enlaces bsico
Monitor bsico
Programas de auxilio para la eliminacin de errores de
programacin
Bajo:

Compilador lenguaje de alto nivel

Macroemsamblador
Editor de enlaces overlay
Monitor de lenguaje independiente
Editor de documentos en lote
Biblioteca bsica de ayuda
Sistema Base de Datos Bsico

Nominal: Sistema operativo tiempo real o compartido

Sistema de Direccin de Base de Datos (DBMS)
Biblioteca simple de programacin
Editor de documentos interactivo
Editor de enlaces overlay extendido
Programa de auxilio para la eliminacin de

errores interactivo
Alto:

Sistema operativo de memoria virtual

Sistema de ayuda al diseo de Base de Datos
Biblioteca de apoyo a la programacin con
ayuda para el manejo de la configuracin
Analizador de uso fijo
Analizador del flujo de programas y textos
Editor de textos bsico

Muy Alto: Sistema de documentacin integrado

Sistema de control de proyectos
Herramientas automatizadas de diseo
Sistema automtico de verificacin
Herramientas de propsito especifico
Simuladores de conjuntos de instrucciones
Formateador de display
Herramientas del proceso de comunicacin
de control de entrada de datos, ayuda a la
conversin, etc.
1.3.6.15. Requisitos de Planificacin. (RPL)
Segn el por ciento del TDES nominal que se quiera acelerar el proyecto o
desacelerar as ser el nivel de este indicador que se halla en la Tabla 12. La
aceleracin del proyecto por encima del 75 % del tiempo de desarrollo nominal
es considerado imposible al igual que un alargamiento de ms de un 60%.
1.3.6.16. Factor de Esfuerzo compuesto. (FEC)
Si un proyecto se desarrolla en modo orgnico con 32 mf en nivel intermedio y
la capacidad de los analistas es muy alta entonces el esfuerzo real ser:
De la Tabla 9: esf nom = 91 hombres-mes
De la Tabla 12: CAN = 0,71

Entonces:
esf real = 0,71 (91) = 64,6 hombres-mes
Para el mismo proyecto, si la capacidad de los analistas es muy baja entonces:
De la Tabla 12: CAN = 1,46

esf real = 1,46(91) = 132,9 hombres-mes

Claro esta que a un proyecto no lo afecta un solo factor sino muchos a la vez
por lo que el Factor de Esfuerzo Compuesto (FEC) ser:
15
FEC =

FEi
i=1

donde FEi es el factor de esfuerzo para cada caracterstica o atributo i que se

toma de la Tabla 11.
Ejemplo 7. Un proyecto de 32 mf desarrollado en un modo fuertemente
restringido tiene las siguientes caractersticas:
RSS- Bajo
VMC- Nominal
ESO- Alto
TBD- Nominal
TRC- Bajo
ELP- Bajo
CPR- Alto
CAN- Nominal
UTP- Nominal
RTE- Nominal
EAN- Alta
UHS- Baja
RMP- Muy alto
CPRO- Nominal
RPL- Muy alto
Determine el valor del esfuerzo necesario.
Solucin:
De la Tabla 12:
RSS- 0,88
VMC- 1,0
ESO- 0,90
TBD- 1,0
TRC- 0,87
ELP- 1,07
CPR- 1,15
CAN- 1,0
UTP- 1,0
RTE- 1,0
EAN- 0,91
UHS- 1,10
RMP- 1,21
CPRO- 1,0
RPL- 1,10
FEC = (0,88)(1,15)(1,21)(0,87)(0,91)(0,90)(1,07)(1,10)(1,10)
FEC = 1,067
De la Tabla 9: esf nom = 230 hombres-mes
esf real = esf nom (FEC) = 230 (1,067) = 245,4 hombres-mes.
Ejemplo 8. Suponga que usted desea determinar el esfuerzo de desarrollo de
un proyecto en modo fuertemente restringido que se estima en 10 mf y posee
las siguientes caractersticas:
a. Prdidas moderadas
b. Base de datos 20 000 bytes
c. La complejidad puede considerarse muy alta
D. Se usar el 70% del tiempo disponible de la computadora

e. Se usarn 450 K de memoria de las 640 K disponibles

f. Se usar una microcomputadora comercial
g. Tiempo de respuesta 2 horas
h. Muy buenos analistas con tres aos de experiencia promedio
i. Muy buenos programadores con seis meses de experiencia promedio en el
Sistema Operativo y doce en el lenguaje de programacin
j. Son utilizadas much as de las herramientas modernas de programacin
desde hace alrededor de un ao
k. Sern utilizadas las herramientas bsicas del software de un
microcomputador
l. Se debe desarrollar el sistema en nueve meses
m. El costo por hombres-mes de desarrollo del software es de $2000
Determine:
1. Esfuerzo nominal.
2. El nivel de cada atributo a aplicar y su valor correspondiente.
3. Esfuerzo real.
4. Si usted no contrata analistas y programadores muy buenos si no de una
capacidad nominal, el costo por Hombres-mes se reduce a $1500. Traera
eso algn beneficio?
5. Si se puede comprar por $8000 una computadora de 96 K de memoria
traera esto algn ahorro?
Solucin:
a. Interpolando para hallar el esfuerzo:
10 - 8
esf = esf +
10
8
esf = 44 +
10

(ESF - esf )
32 - 8
32
8
1/12 (230 - 44) Utilizando la Tabla 9.

esf = 60 Hombres-mes aprox

10

b. Nivel de cada atributo:

RSS- Nominal (1,0) VMC- Nominal (1,0)
TBD- Bajo (0,94)
TRC- Nominal (1,0)
CPR- Muy alto (1,30) CAN- Alto (0,86)
RTE- Alto (1,11)
EXP- Nominal (1,0)
RMP- Alto (1,06)
CPRO Alto (0,86)
c. Esfuerzo real.

ESO- Bajo (1,10)

ELP- Nominal (1,0)
UTP- Alto (0,91)
UHS- Bajo (1,10)
RPL- Nominal (1,0)

FEC = (0,94)(1,30)(1,11)(1,06)(0,86)(0,86)(1,10)(0,91)(1,10)
FEC = 1,17
esf real = esf nom (FEC) = 60(1,17) = 70,2 hombres-mes
costo = 70,2(2000) = $140 040
d. Con analistas y programadores muy buenos:
CAN y CPRO pasan del valor 0,86 a 1,00
Recalculando FEC FEC = 1,58
esf real = esf nom (FEC) = 60(1,58) = 94,8 hombres-mes
costo = 94,8(1500) = 142 200
Esta variable no implica ahorro sino todo lo contrario cuesta $2160 pesos ms.
e. Comprando una computadora:
Para esta variante RMP = 1,0 ya que Mem Disp = 450/960 antes RMP era igual a
1,06.
Recalculando FEC

FEC = 1,10

esf real = ESFnom (FEC) = 60 (1,10) = 66 hombres-mes

costo = 66 (2000) = $132 000
Se ahorran en el diseo del software 8040 pesos mientras el costo de la
microcomputadora es de 8000. Es conveniente la inversin.

INDICADOR FASES

N I V E L E S
BAJO NOMINAL ALTO

MUY
BAJO
RSS
2
0,80
0,90
1,00
1,10
3
0,80
0,90
1,00
1,10
4
0,80
0,90
1,00
1,10
5+6
0,60
0,80
1,00
1,30
TBD
2
0,95
1,00
1,10
1,20
3
0,95
1,00
1,05
1,10
4
0,95
1,00
1,05
1,10
5+6
0,90
1,00
1,15
1,30
CPR
2
0,70
0,85
1,00
1,15
3
0,70
0,85
1,00
1,15
4
0,70
0,85
1,00
1,15
5+6
0,70
0,85
1,00
1,15
RTE
2
1, 00
1,10
1,30
1,65
3
1,00
1,10
1,25
1,55
4
1,00
1,10
1,25
1,55
5+6
1,00
1,15
1,40
1,95
RMP
2
1,00
1,05
1,20
1,55
3
1,00
1,05
1,15
1,45
4
1,00
1,05
1,15
1,45
5+6
1,00
1,10
1,35
1,85
VMC
2
0,95
1,00
1,10
1,20
3
0,90
1,00
1,12
1,25
4
0,85
1,00
1,15
1,30
5+6
0,80
1,00
1,20
1,40
TRC
2
0,98
1,00
1,00
1,02
3
0,95
1,00
1,00
1,05
4
0,70
1,00
1,10
1,20
5+6
0,90
1,00
1,15
1,30
CAN
2
1,80
1,35
1,00
0,87
3
1,35
1,15
1,00
0,90
4
1,35
1,15
1,00
0,90
5+6
1,50
1,20
1,00
0,85
EAN
2
1,40
1,20
1,00
0,87
3
1,30
1,15
1,00
0,95
4
1,25
1,10
1,00
0,92
5+6
1,25
1,10
1,00
0,92
Tabla 15.- Indicadores de los fatores para el nivel detallado.

MUY
ALTO
1,30
1,30
1,30
1,70
1,30
1,30
1,30
1,30
0,75
0,75
0,75
0,70
0,75
0,90
0,85
0,85

EXTRA
ALTO
1,65
1,65
1,65
1.65
-

1.3.7. NIVEL DETALLADO.

En el nivel detallado se consideran los mismos factores o atributos que en el
nivel intermedio pero no afectando a la totalidad del proyecto sino a cada
etapa. En la Tabla 15 se muestran los valores de los factores para cada una de
ellas. Como puede verse hay factores que no afectan a determinada etapa.
El procedimiento para determinar el esfuerzo por fases es el siguiente:
a. Hallar el esfuerzo total nominal
b. Hallar el esfuerzo por etapas
c. Determinar el nivel de cada factor
d. Determinar el valor de cada factor por etapa
e. Determinar el valor del Factor de Esfuerzo Compuesto (FEC) para cada
etapa
f. Determinar el esfuerzo real por etapa
Todos estos clculos son el producto de estudios hechos por B. W. Bohem
para las condiciones de Estados Unidos. El procedimiento se puede
automatizar para hacerlo mucho ms rpido y ms exacto ya que se pudiera
trabajar con las ecuaciones exponenciales originales y no mediante la
interpolacin, muchas de las Tablas pueden pasar a formar parte de la Base de
Datos para los clculos. Este mtodo, como se dijo al principio del captulo ha
sido el producto de anlisis de ms de 60 proyectos de distintos tipos
realizados por el autor y de otros clculos y estimaciones. Se supone que los
valores a los que se arriba por medio de sus clculos sean una buena
estimacin y cuanto ms se alejen de ellos peor es.