metodo de estimacion de costos cocomo construtive cost model.pdf
TRANSCRIPT
TEMA III. Planificación y Control de Proyectos Informáticos
PRESENTACIÓN
Al igual que un proyecto constructivo, mecánico o de cualquier producto
nuevo, los de elaboración de software, necesitan de una planificación
detallada y de un control riguroso de su realización.
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 terminación, su costo, los beneficios económicos
que aportará, etc.
Esto se debe a:
a. La poca conciencia que posee el personal de informática 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 informático, de que dichas tareas no debe
hacerlas él sino "otro"; olvidando que el deber elemental de todo
profesionista es saber, inclusive para satisfacción propia, cual es su
productividad, los beneficios que aporta su trabajo, lo que ha costado, etc.
C. La creencia también arraigada de que es muy "difícil", que el trabajo
informático es "distinto", que no se hayan valores "exactos" y otras
cuestiones completamente subjetivas, ya que la actividad informática es
como otra cualquiera. Es menos difícil planificar un proyecto informático que
cortar mil arrobas de caña en un día y no hay nada más inexacto que saber si
uno va a estar vivo mañana y mucha gente tiene su agenda llena de
actividades programadas para el mes próximo.
D. La inexistencia de un método formalizado que sirva de guía para la
ejecución de estas actividades.
Con este texto se quiere dar solución a estas cuatro dificultades y se
pretende que además sirva de base para cursos, seminarios o de estudio
para el personal informático y a la vez como un método formalizado para la
ejecución de estas actividades. Por otra parte, se tratará de hacer ver que
estas tareas deben ser desarrolladas por el personal informático, que no son
difíciles ni distintas, que son tan exactas como se necesitan y que en muchos
casos su exactitud depende de uno mismo.
TEMA I. PLANIFICACIÓN DE TRABAJOS DE PRODUCCIÓN DE SOFTWARE.
1.1. INTRODUCCION.
Hacer un edificio sin planos, sin un cronograma de ejecución de la obra y sin
un presupuesto, a nadie se le ocurre. Emprender una travesía transoceánica
sin cartas de navegación y sin rumbo preestablecido, es de una persona que
no esta bien psíquicamente. Pero en el terreno de las aplicaciones de la
computación, estas premisas, tan lógicas para todo proyecto son muchísimas
veces olvidadas y emprendemos una tarea sin saber, qué tiempo se va a
demorar, qué personal se necesita y cuánto 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 algún mueble a un
carpintero, sin decirle para que día lo quiere, de que madera lo prefiere y
cuanto esta dispuesto a pagar.
La excusa para esto es: que es muy difícil 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 más difíciles 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 ningún 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
administración, 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 compañía.
Se ha dicho lo anterior porque la actividad de planificación de proyectos de
desarrollo de software, no ha tiene la prioridad que debe tener.
Los métodos de la Ruta Crítica, PERT, CPM, etc. que se aplican para planificar
los proyectos constructivos pueden ser utilizados para la planificación de los
proyectos de software, al igual que los Métodos Económico-Matemáticos o de
Investigación de Operaciones, en especial la Programación Lineal Discreta,
pero hay que estimar muchos parámetros de una forma muy subjetiva o tener
un sistema estadístico de control muy potente.
En las dos últimas décadas en el mundo se ha venido trabajando para
encontrar un método especifico para planificar proyectos de desarrollo de
software y aunque se sigue trabajando en este sentido, una etapa fundamental
terminó con la publicación 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 métodos de estimación 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 algorítmicos que tratan de establecer una figura de mérito o relación
matemática que permita estimar el esfuerzo (hombres-mes) y tiempo
requerido para desarrollar un proyecto, en términos de número de
instrucciones fuente utilizadas en la codificación 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
metodológico y de la filosofía de estimación de los parámetros, es de gran
utilidad. Más adelante se detallará como se puede llegar a obtener indicadores
propios para lograr estos parámetros; pero lo que sí es cierto es que nadie
puede planificar sin datos, y que cada organización debe poseer los
necesarios para poder planificar sus trabajos en el terreno de la computación
y para ello, los trabajos de Bohem y otros autores pueden servir de punto de
partida.
Como antecedente del método 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 planificación de proyectos de elaboración de
software o sea, planificación del trabajo de análisis, diseño, programación,
puesta a punto, prueba e implantación de sistemas automatizados utilizando
los principios del COCOMO.
1.2.FORMA DE APLICACIÓN. DEFINICIONES Y SUPOSICIONES.
Este método es aplicable en todo trabajo relacionado con los procesos de
producción de un software nuevo, su mantenimiento o modificación.
Existen tres niveles de profundidad en su aplicación 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. básico.
b. intermedio
c. detallado
Las ecuaciones del nivel básico son adecuadas para realizar estimaciones de
forma rápida aunque sin gran precisión. Su precisión esta necesariamente
limitada dado que, en este nivel no se tienen en cuenta los diferentes
atributos que afectan la realización del proyecto como: calidad y experiencia
del personal, restricciones del hardware empleado, utilización de modernas
técnicas y herramientas de producción 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 consideración la
forma en que, cada uno de estos factores afecta la ejecución 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 tamaño del
producto, es decir el número de miles de instrucciones fuente desarrolladas
(mf).
El producto de todo proceso de elaboración, mantenimiento y/o conversión de
un software son instrucciones, agrupadas en programas y en sistemas y a
partir de su conocimiento se debe planificar el trabajo. El análisis de sistemas
y su diseño, no tiene objetivo si este no se programa, al igual que no tiene
objetivo la producción 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 código de máquina por alguna de las
combinaciones de preprocesadores, compiladores o ensambladores,
excluyendo las líneas 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 líneas de código y por tanto toda línea que
contenga dos o más sentencias fuente, se considera como una sola
instrucción.
En el modelo COCOMO se planifican sólo las fases del periodo de elaboración
comprendidas desde el comienzo de la etapa de análisis hasta el final de la
etapa de implantación. Los parámetros correspondientes a la etapa anterior
(por ej. Estudio Preliminar) se deben estimar separadamente.
Los parámetros estimados mediante este modelo no incluyen los
relacionados con las actividades de formación de los usuarios, planificación
de las instalaciones y trabajos de conversión. Sí comprende los relativos a la
documentación de todas y cada una de las etapas, tanto técnica como
dirigida al usuario, etc.
Las estimaciones cubren todos los costos directos del proyecto, o sea de las
actividades individuales señaladas en el punto anterior. Es decir, incluye la
elaboración del proyecto y los trabajos de documentación pero excluye las
correspondientes al personal operador de las computadoras, secretarias,
dirigentes, etc. , a no ser que estos estén ligados directamente al desarrollo
del proyecto.
Los indicadores de planificación que se pueden obtener a través del método
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.- Relación 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 práctica 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 Conversión
hombres-mes x 152 hombres-hora
hombres-mes x 19 hombres-día
hombres-mes / 12 hombres-año
Tabla 2.- Conversión a otras de la medida hombres-mes
En los parámetros 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 programación no son sólo los costos
de codificación sino también los de la documentación y otros trabajos
directos de esa etapa.
El costo se puede estimar de manera tradicional, acumulando todos y cada
uno de sus componentes, pero también de una forma más sencilla, a partir
del costo por hombres-mes.
Se supone que después de la etapa donde se establezcan las
especificaciones, estas no cambiarán sustancialmente, aunque
evidentemente esto será inevitable. No obstante, si se producen
modificaciones significativas deben revisarse las estimaciones realizadas.
1.3. PROYECTOS DE PRODUCCIÓN DE SOFTWARE.
La base de cálculo para la producción de software es la cantidad, en miles de
instrucciones fuentes (ejecutables) que tendrá su sistema. ¿Cómo se puede
conocer esto?
Esto sólo se puede estimar sobre la base de la experiencia que posea la
persona que vaya a planificar o a desarrollar el software, por analogía con
otros proyectos semejantes o por ciertos cálculos que se pueden realizar
como se mostrará más adelante. Esta experiencia se puede adquirir sola-
mente 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.
Además, como un deber elemental de una persona que realiza determinado
trabajo, se debe conocer lo que uno es capaz de producir. A cualquier obrero
agrícola 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 construcción o mecánica también 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 estadísticos o económicos de los proyectos desarrollados.
1.3.1. MODOS DE DESARROLLO DE SOFTWARE.
Hay tres modos de desarrollo de software, que aunque matemáticamente
pueden expresarse de forma similar, conducen a estimaciones diferentes en
los parámetros de planificación, se denominan: orgánico o familiar, semilibre
y fuertemente restringido.
1.3.1.1 MODO ORGÁNICO.
En el modo orgánico, el equipo de desarrollo es relativamente pequeño y se
desenvuelven en un entorno altamente familiar: la gran mayoría de la gente
relacionada con el proyecto tiene una amplia experiencia en otros proyectos
relacionados con la misma organización y tienen un buen conocimiento de
como, el sistema bajo desarrollo contribuirá a los objetivos de su
organización.
Esto significa que la mayoría de las personas pueden contribuir de forma
efectiva a la terminación puntual de cada una de las etapas sin generar
grandes necesidades de comunicación para determinar con precisión 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
modificación de algunas de las especificaciones para hacer más fácil este
desarrollo sin que sea demasiado difícil acomodarlo a las necesidades del
desarrollo.
Según el contenido que establece Bohem para cada una de las etapas
podemos hacer un símil entre ellas y las que se usan normalmente como
sigue:
BOHEM NORMAL
Planificación y Requisitos Estudio preliminar
Diseño Análisis
Diseño detallado Diseño
Codificación Desarrollo
Integración y Prueba Prueba e implantación
Tabla 3.- Ciclo de vida para el proyecto según Bohem y comparación con el
establecido más comúnmente.
Otros factores característicos del modo orgánico son:
- Entorno de desarrollo estable, con poco desarrollo concurrente de nuevo
hardware asociado.
- Mínimas necesidades de introducir algoritmos innovadores o nuevas
arquitecturas de proceso.
- Un trabajo de proyecto relativamente pequeño. Muy pocos proyectos
desarrollados de modo orgánico sobrepasan los 50 mf (50000 instrucciones
fuente)
- Proyectos en modo orgánico de mayor tamaño pueden desarrollarse
utilizando software ya existente.
1.3.1.2. MODO SEMILIBRE.
Este modo representa un estado intermedio entre el modo orgánico y el
modo fuertemente restringido. Este nivel intermedio puede referirse bien a
las características del proyecto, o bien que el proyecto presenta una mezcla
de características propias de modo orgánico 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 diseño 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 término semidetached
(semidesligado, semimovido, semilibre).
El tamaño del producto en este modo puede llegar a 300 mf.
1.3.1.3. MODO FUERTEMENTE RESTRINGIDO.
La característica 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
características se podrían considera inmodificables. Como resultado, en
estos proyectos no se puede o no existe la posibilidad de negociar fácilmente
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 verificación y validación) y asegurarse de que los cambios se hacen
correctamente (mayor coste de gestión de la configuración).
Los proyectos en modo fuertemente restringido generalmente abarcan arreas
más amplias y también menos conocidas que los casos anteriores.
1.3.2. ESTIMACIONES EN MODO ORGÁNICO.
Con los supuestos anteriores y conocidas las etapas del proyecto que
considera el modelo veáse 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 orgánico viene dado por:
1,05
esf = 2,4 (mf)
Donde como ya se indicó anteriormente mf es el número 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
orgánico viene dado por:
0,38
tdes = 2,5 (esf)
Ejemplo 1. Supóngase que una empresa cualquiera desea diseñar un
proyecto que gestione sus inventarios y decide desarrollarlo mediante su
propio equipo de analistas y programadores, que anteriormente y durante
muchos años, viene desarrollando aplicaciones similares para la empresa. Sí
un estudio inicial determina que el tamaño del producto en alrededor de
32000 líneas de programa fuente (32 mf, ¿cuáles serán las características del
proyecto?.
Solución:
Este es un buen ejemplo de desarrollo de software de modo orgánico,
entonces:
1,05 1,05
Esfuerzo: esf = 2,4 (mf ) = 2,4(32) = 91 hombres-mes
mf *1000 32000
Productividad: p = = = 352 (if/hombres-mes)
esf 91
0,38 0,38
Tiempo de desarrollo: tdes = 2,5 (esf) = 2,5 (91) = 14 meses
Número de personas trabajando en el proyecto:
ch = esf/tdes = 91/14 = 6,5 hombres
La cantidad de hombres nos da la medida del número equivalente de
personas trabajando a tiempo completo en el proyecto.
La Tabla 4 nos da el tamaño promedio de los proyectos informáticos y la
Tabla 5 nos muestra los perfiles obtenidos de aplicar las anteriores
ecuaciones a proyectos de tamaño promedio.
Tipo Tamaño
Pequeño 2000 instrucciones fuentes
Intermedio 8000 " "
Medio 32000 " "
Grande 128000 " "
Tabla 4.- Proyectos de tamaño estándar
Obsérvese que un proyecto "pequeño" es esencialmente el trabajo de una
persona, mientras que un proyecto considerado como "grande" requiere un
nivel medio de 16 personas. Además, hay que hacer notar que en la tabla 2 la
estimación de 5 hombres/mes para un proyecto pequeño se refiere al
desarrollo de 2000 instrucciones fuente de producto software, incluyendo por
tanto, el esfuerzo de documentación, 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) según las
cuales un producto software requiere tres veces más esfuerzo que un
programa personal de tamaño equivalente o las estimaciones que aparecen
en el libro de Carlos Díaz Llorca.
1.3.3 DISTRIBUCIÓN DE TIEMPO Y ESFUERZO DE POR ETAPAS.
La Tabla 6 presenta los porcentajes de distribución del esfuerzo y tiempo de
desarrollo entre las distintas etapas del ciclo de desarrollo definido en la
Tabla 3. Esta distribución varia en función del tamaño del producto. Los
proyectos de gran tamaño precisan mayor tiempo y esfuerzo para desarrollar
las actividades de prueba e implantación mientras que pueden reducir el
tiempo en la etapa de programación, distribuyendo esta actividad entre mayor
número de programadores trabajando simultáneamente. En los pequeños
programas hay que dedicar relativamente más recursos a la etapa de diseño
y programación que a las de prueba e implantación. En modo orgánico todos
los proyectos presentan una distribución relativamente plana, comparados
con otros modos de desarrollo de software más restringidos como se verá
más adelante.
Tamaño Esfuerzo Productividad Tiempo Personal
hombres-mes If/hombres-mes meses hombres
Pequeño (2000) 5,0 400 4,6 1,1
Intermedio (8000) 21,3 376 8,0 2,7
Medio (32 000) 91,0 352 14,0 6,5
Grande (128 000) 392,0 327 24,0 16,0
Tabla 5.- Estimaciones en modo orgánico, nivel básico para proyectos
estándares.
FASES TIPOS
PEQUEÑO INTERMEDIO MEDIO GRANDE
ESFUERZO 2 mf 8 mf 32 mf 128 mf
Estudio preliminar 6% 6% 6% 6%
Análisis 16% 16% 16% 6%
Diseño y desarrollo 68% 65% 62% 59%
De ella:
Diseño 26% 25% 24% 23%
Desarrollo 42% 40% 38% 36%
Prueba e implantación 16% 19% 22% 25%
TIEMPO
Estudio Preliminar 10% 11% 12% 13%
Análisis 19% 19% 19% 19%
Diseño y Desarrollo 63% 59% 55% 51%
Prueba e implantación 18% 22% 26% 30%
Tabla 6.- Distribución de tiempo y esfuerzo por etapas, modo orgánico, nivel
básico.
Ejemplo 2. Tómese de nuevo la situación 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, supóngase que se desea conocer el esfuerzo, el
tiempo y el número medio equivalente de personas durante las etapas de
diseño y desarrollo (programación) de este proyecto.
Solución:
Utilizando la Tabla 6 se observa que las etapas de diseño y programación
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 tamaño del proyecto estándar 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 también los valores correspondientes a la
etapa de estudio preliminar aunque esta no es considerada dentro de las
estimaciones del modelo. Nótese 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
tamaño del producto. Así, con respecto a la productividad observamos que
se produce una disminución casi proporcional según va aumentando el
tamaño del producto. Las principales razones por las cuales los grandes
productos software incurren en esta disminución de productividad son las
siguientes:
1. Soportar las actividades paralelas de un gran número de programadores
exige un esfuerzo relativamente mayor para establecer minuciosamente las
especificaciones del diseño en el ámbito de cada una de las unidades.
2. Se precisa mayor esfuerzo para verificar y validar, cuanto mayor sea el
número de especificaciones establecidas.
3. Incluso cuando las especificaciones del producto se establecen
minuciosamente, en un gran proyecto, los programadores consumen más
tiempo comunicando y resolviendo interfaces útiles.
4. Se precisa un mayor esfuerzo de integración entre las diferentes unidades
que componen el producto total.
5. En general se requieren unas pruebas más amplias y detalladas para
verificar y validar un producto software de mayor tamaño.
6. Los grandes proyectos normalmente exigen mayor esfuerzo.
1.3.4. PROYECTOS DE TAMAÑO NO ESTÁNDAR. INTERPOLACIÓN.
En el supuesto de que el tamaño del producto no se ajuste a los tamaños
estándares de las Tablas 4 y 5 se puede obtener el perfil del proyecto por
interpolación de los datos de los proyectos estándares de tamaño inferior y
superior de las citadas Tablas.
Ejemplo 3. Supóngase que se desea obtener el esfuerzo necesario en la etapa
de programación (desarrollo) de un producto de software cuyo tamaño se fija
en 12800 líneas fuente. Aplicando las ecuaciones ya conocidas se obtiene
fácilmente 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 programación, 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 programación 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 programación seria de:
ch = 22,5 / 5,6 = 4 hombres.
1.3.5. MODOS SEMILIBRE Y FUERTEMENTE RESTRINGIDO. NIVEL BÁSICO
La Tabla 8 presenta las ecuaciones actuales para los tres modos de
desarrollo del nivel básico.
Las estimaciones obtenidas para los diferentes proyectos estándares a los
que se le ha añadido uno nuevo de 512 mf (muy grande), se presentan en la
Tabla 9.
F A S E S PEQUEÑO INTERMEDIO MEDIO GRANDE
2 MF 8 MF 32 MF 128 MF
ESFUERZO
Estudio Preliminar 0,3 1,3 5,0 24,0
Análisis 0,8 3,4 15,0 63,0
Diseño y desarrollo 3,4 13,8 56,0 231,0
De ella:
Diseño 1,3 5,3 22,0 90,0
Desarrollo 2,1 8,5 34,0 141,0
Prueba e implantación 0,8 4,1 20,0 98,0
TIEMPO
Estudio Preliminar 0,5 0,8 1,7 3,1
Análisis 0,9 1,5 2,7 4,6
Diseño y desarrollo 2,9 4,7 7,7 12,2
Prueba e implantación 0,8 1,8 3,6 7,2
PERSONAL
Estudio Preliminar 0,6 1,4 2,9 8,0
Análisis 0,9 2,3 5,6 14,0
Diseño y desarrollo 1,2 2,9 7,3 19,0
Prueba e implantación 1,0 2,3 5,6 14,0 % DE CH POR FASE
RESPECTO
AL TOTAL DEL PROYECTO
Estudio Preliminar 60% 55% 50% 46%
Análisis 84% 84% 84% 84%
Diseño y desarrollo 108% 110% 113% 116%
Prueba e implantación 89% 87% 85% 83%
Productividad
En todo el proyecto 400 376 352 327
Tabla 7.- Indicadores en por cientos, modo orgánico, nivel básico para
proyectos estándares.
1.3.5.1. DISTRIBUCIÓN 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 distribución del esfuerzo y tiempo para cada una de las
etapas en los tres modos de desarrollo. Su utilización es idéntica al caso del
modo orgánico presentado anteriormente.
Se observa que un proyecto en modo fuertemente restringido consume
mucho más esfuerzo en la etapa de implantación como consecuencia de la
necesidad de realizar un seguimiento más 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 codificación, sino
porque, comparativamente, los otros modos consumen más esfuerzo en las
otras etapas, en trabajos de modificación y acomodación de cambios en las
especificaciones.
Igualmente, un proyecto fuertemente restringido consume un porcentaje
menor de tiempo en la etapa de programación, 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 organización.
- Las especificaciones del proyecto no pueden variarse bajo ningún
concepto
- No hay que introducir algoritmos innovadores.
- Proyecto pequeño.
- Esfera de trabajo poco conocida.
Estime para ese proyecto todos sus parámetros por etapas.
Solución:
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
Cálculos:
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 Análisis:
17 % de esf = 17(88,5)= 15,04
3+4. Etapas Diseño y Desarrollo:
59,5 % de esf = 59,5(88,5) = 52,66
5. Etapa Prueba e Implantación:
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 Análisis:
17 % de esf = 17(88,5)= 15,04
3+4. Etapas Diseño y Desarrollo:
59,5 % de esf = 59,5(88,5) = 52,66
5. Etapa Prueba e Implantacación:
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 número entero. Esto puede llevarnos a la necesidad de ajustar el número
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
ORGÁNICO 1,05
esf = 2,4(MF)
0,38
tdes = 2,5 (esf)
SEMILIBRE 1,12
esf = 3,0(MF)
0,35
tdes = 2,5 (esf)
FUERTEMENTE
RESTRINGIDO
1,20
esf = 3,6(MF)
0,32
tdes = 2,5 (esf)
Tabla 8.- Esfuerzo y tiempo de desarrollo, nivel básico.
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 afectación 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 básico aunque en estudios más recientes se
plantea que en las ecuaciones del esfuerzo hay una ligera variación con
respecto a las del nivel básico estas son:
1,05
modo orgánico: 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 características 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
cuantía 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 características que hacen que cada atributo sea
considerado en algunas de estas categorías, se hace una excepción con el
atributo "Complejidad del Producto" (CPR) cuya valoración se muestra en
Tabla 12. Este atributo depende a su vez de la complejidad de las operaciones
de control, aritméticas, de entrada y salida y de manejo en la base de datos.
Nótese en la Tabla 12 que algunos factores hacen que se aumente el esfuerzo
nominal y otros que disminuya.
INDICADOR/
MODO
PEQUEÑO
2 MF
INTERMEDIO
8 MF
MEDIO
32 MF
GRANDE
128 MF
MUY
GRANDE
512 MF
ESFUERZO
ORGÁNICO 5,0 21,3 91,0 392,0 -
SEMILIBRE 6,5 31,0 146,0 687,0 3250,0
FUERTEMENTE
RESTRINGIDO
8,3 44,0 230,0 1216,0 6420,0
PRODUCTIVIDAD
ORGÁNICO 400 376 352 327 -
SEMILIBRE 308 258 219 186 158
FUERTEMENTE
RESTRINGIDO
241 182 139 105 80
TIEMPO DE
DESARROLLO
ORGÁNICO 4,6 8,0 14,0 24,0 -
SEMILIBRE 4,8 8,3 14,0 24,0 42,0
FUERTEMENTE
RESTRINGIDO
4,9 8,4 14,0 24,0 41,0
PERSONAL
ORGÁNICO 1,1 2,7 6,5 16,0 -
SEMILIBRE 1,4 3,7 10,0 29,0 77,0
FUERTEMENTE
RESTRINGIDO
1,7 5,2 16,0 51,0 157,0
Tabla 9.- Estimaciones en nivel básico para productos estándares.
Los factores se muestran en la Tabla 11.
Se detallará ahora cada uno de los indicadores y cómo 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 diseñado es simplemente un
defecto del sistema.
Bajo: El efecto de una falla en el software diseñado es de bajo nivel con
pérdidas fácilmente recuperables para los usuarios. Como ejemplo se
pueden citar los errores que surgen en una planificación a largo plazo.
INDICADOR/MODO ETAPAS PEQUEÑO
2 mf
INTERMEDIO8
8 mf
MEDIO
32 mf
GRANDE
128 mf
MUY
GRANDE
512 mf
ESFUERZO
ORGÁ-NICO Estudio
Preliminar
6% 6% 6% 6% -
Análisis 16% 16% 16% 16% -
Diseño y
desarrollo
68% 65% 62% 59% -
Diseño 26% 25% 24% 23% -
Desarrollo 42% 40% 38% 36% -
Prueba e
implantación
16% 19% 22% 25% -
SEMILIBRE Estudio
Preliminar
7% 7% 7% 7% 7%
Análisis 17% 17% 17% 17% 17%
Diseño y
desarrollo
64% 61% 58% 55% 52%
Diseño 27% 26% 25% 24% 23%
Desarrollo 37% 35% 33% 31% 29%
Prueba e
implantación
19% 22% 25% 28% 31%
FUERTEMENTE
RESTRINGIDO
Estudio
Preliminar
8% 8% 8% 8% 8%
Análisis 18% 18% 18% 18% 18%
Diseño y
desarrollo
60% 57% 54% 51% 48%
Diseño 28% 27% 26% 25% 24%
Desarrollo 32% 30% 28% 26% 24%
Prueba e
implantación
22% 25% 28% 31% 34%
TIEMPO DE
DESARROLLO
ORGÁNICO Estudio
Preliminar
10% 11% 12% 13% -
Análisis 19% 19% 19% 19% -
Diseño y
desarrollo
63% 59% 55% 51% -
Prueba e
implant
18% 22% 26% 30% -
SEMILIBRE Estudio
Preliminar
16% 18% 20% 22% 24%
Análisis 24% 25% 26% 27% 28%
Diseño y
desarrollo
56% 52% 48% 44% 40%
Prueba e
implant
20% 23% 26% 29% 32%
FUERTEMENTE
RESTRINGIDO
Estudio
Preliminar
24% 28% 32% 36% 40%
Análisis 30% 32% 34% 36% 38%
Diseño y
desarrollo
48% 44% 40% 36% 32%
Prueba e
implantación
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 pérdidas moderadas para los usuarios
pero una situación de la cual uno puede salir sin una penalización extrema.
Ejemplo de ello son los sistemas de Abastecimiento Técnico Material.
SIGLAS ATRIBUTOS DEL PRODUCTO
RSS Requerimientos de Seguridad del Software
TBD Tamaño de la Base de Datos
CPR Complejidad del Producto
ATRIBUTOS DE LA COMPUTADORA
RTE Restricciones de Tiempo de Ejecución
RMP Restricciones de Memoria Principal
VMC Velocidad con que cambian los Medios de Cómputo
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 Programación
ATRIBUTOS DEL PROYECTO
UTP Uso de Técnicas modernas de Programación
UHS Utilización de las Herramientas de Software
RPL Requisitos de Planificación
Tabla 11.- Factores que se analizan en el modo intermedio.
Alto: El efecto de una falla implica grandes pérdidas financieras o molestias a
un gran número de personas. Ejemplo de ello los sistemas de distribución
eléctrica.
Muy alto: El efecto de una falla puede significar pérdidas de vidas humanas.
1.3.6.2. Tamaño de la Base de Datos. (TBD)
Se toma el tamaño 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 lógico que para poder obtener el tamaño de la base de
datos, deban estar definidos, los archivos, los campos, la longitud de estos y
estimadas la cantidad de artículos. La fuente de información para ello es el
diccionario de datos del análisis y el estudio del sistema actual realizado.
Para la familia dBase a los archivos de datos se le puede calcular su volumen
por la fórmula:
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 EXTRA ALTO
RSS 0,75 1,00 1,15 1,40 -
TBD - 0,94 1,00 1,08 1,16 -
CPR 0.70 0,85 1,00 1,15 1,30 1.65
RTE - - 1,00 1,11 1,30 1.66
RMP - - 1,00 1,06 1,30 1,58
VMC - 0,87 1,00 1,15 1,30 -
TRC - 0,87 1,00 1,07 1,15 -
CAN 1,46 1,19 1,00 0,86 0,71 -
EAN 1,29 1,13 1,00 0,91 0,82 -
CPRO 1,42 1,17 1,00 0,86 0,70 -
ESO 1,21 1,10 1,00 0,96 - -
ELP 1,14 1,07 1,00 0,95 - -
UTP 1,24 1,10 1,00 0,91 0,82 -
UHS 1,24 1,10 1,00 0,91 0,83 -
RPL 1,23 1,08 1,00 1,04 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
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, aritméticas, 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 según lo que
usted conoce del análisis del sistema actual obtener un nivel único general.
1.3.6.4. Restricciones de Tiempo de Ejecución.
Se debe estimar el tiempo necesario para la ejecución de este componente y
calcular el tiempo disponible de computación, se divide uno entre otro y se
multiplica por 100 para hallar el por ciento, con este número se entra a la Tabla
13 para hallar el nivel de complejidad de este indicador.
El tiempo de ejecución podrá determinarse mediante la siguiente fórmula:
TE = TED + TEA + TSD (Horas/día)
Donde: TED - Tiempo consumido en la entrada de los datos (hr/día)
TEA - Tiempo de ejecución y acceso a archivos (hr/día)
TSD - Tiempo consumido en la salida de los datos (hr/día)
VDE
TED =
RE * 3600
VDS
TSD =
RS * 3600
Donde: VDE - Volumen de datos de entrada (caracteres/día)
RE- Rapidez de la entrada de datos (cps)
VDS - Volumen de datos de salida (caracteres/día)
RS - Rapidez de salida de los datos (cps)
n
VDE o VDS = Ij (caracteres)
j=1
m
CIj = Aij
i=1
Donde: Aij - Longitud del dato i en el flujo j. (caracteres)
CIj - Capacidad de información del flujo j (caracteres)
m - Cantidad de datos de un flujo
n - Cantidad de flujos de entrada o de salida.
El tiempo de ejecución y acceso a archivo depende del tipo de proyecto
(gestión, inteligencia artificial, cálculo científico, etc.), del tipo de máquina, del
sistema operativo, del sistema de gestión de base de datos, etc.
Este tiempo puede calcularse, a través de programas realizados anteriormente
del mismo tipo o diseñados para ello propiamente, que simulen la ejecución de
las instrucciones y los accesos y a partir de ellos calcular "k11" (tiempo
promedio de ejecución en segundos por cada mil instrucciones) y entonces se
puede calcular TEA así:
k11 * mf
TEA = (horas/día)
3600
El tiempo de ejecución y acceso a archivos, es despreciable frente a
(TED+TSD) en sistemas de gestión y es grande con respecto a (TED+TSD) en
procesos que contengan Métodos Económico-Matemáticos, Estadísticos, de
Simulación, etc.
N I V E L E S
MUY BAJO BAJO NOMINAL ALTO MUY ALTO EXTRA
ALTO
RSS SÓLO
DEFECTOS
POCAS
PÉRDIDAS
PÉRDIDAS
MODERADAS
GRANDES
PÉRDIDAS
FINANCIERAS
PÉRDIDAS
HUMANAS
MUCH AS
PÉRDIDAS
HUMANAS
TBD KB/MF >10<= 10 KB/MF - -
> 100 <= 100 > 1000 <= 1000
V E R F I G U R A 1.10
RTE - - MENOS DEL
50% DEL
USO DEL
TIEMPO
DISPONIBLE
< 70% < 85% < 95%
RMP - - MENOS DEL
50% DEL
USO DE LA
MEMORIA
DISPONIBLE
< 70% < 85% < 95%
VMC - MAYOR 12m
MENOS 1m
MAYOR 6m
MENOR 2s
MAYOR 2m
MENOR 1s
MAYOR 2s
MENOR 2d
-
TRC - INTERACTIV
O
< 4 Horas 4 - 12 Horas | > 12 Horas -
CAN 15 perc. 35 perc. 55 perc. 75 perc. 90 perc. -
EAN 4 meses 1 año 3 años 6 años 12 años -
CPRO 15 perc. 35 perc. 55 perc. 75 perc. 90 perc. -
ESO 1 mes 4 meses 1 año 3 años - -
ELP 1 mes 4 meses 1 año 3 años - -
UTP NO SE USAN SE USAN
EXPERIMEN-
TALMENTE
TIENEN
ALGÚN USO
TIENEN
BASTANTE USO
SON DE
USO
RUTINARIO
-
UHS HERRAM.
BÁSICAS
MICROCOMP|
HERR. BÁS.
MINICOMP.
O FUERTES
MICROCOMP
.
HERR. BÁS.
MAINFRAME
O FUERTES
MINICOMP.
UTILIT.
MÍNIMOS DEL
MAINFRAME
TODOS LOS
UTILIT. DEL
MAINFRAME
-
RPL 75% TDES
NOMINAL
85% TDES
NOMINAL
100% TDES
NOMINAL
130% TDES
NOMINAL
160% TDES
NOMINAL
-
Tabla 13.- Forma de determinar el nivel del factor.
El tiempo de ejecución y acceso a archivos, es despreciable frente a
(TED+TSD) en sistemas de gestión y es grande con respecto a (TED+TSD) en
procesos que contengan Métodos Económico-Matemáticos, Estadísticos, de
Simulación, etc.
1.3.6.5. Restricciones de Memoria Principal. (RMP)
Se estima la cantidad de memoria que se necesita para la ejecución de este
componente, se divide entre la memoria disponible del computador y se
multiplica por 100 para hallar el por ciento, con este número se entra a la Tabla
12 para hallar el nivel de complejidad de este indicador.
NIVEL OPERACIONES DE
CONTROL
OPERACIONES
MATEMÁTICAS
OPERACIONES DE
ENTRADA/SALIDA
OPERACIONES
DE MANEJO DE
DATOS
MUY BAJO Códigos lineales:
DO
IF-THEN-ELSE
Evaluación de
expresiones
matemáticas simples:
Lecturas simples
Escrituras con formatos
simples.
Arreglos
simples en
memoria RAM.
Predicados simples,
pocas subrutinas.
C = A+B*(D-E).
BAJO Subrutinas en
secuencia la mayor
parte en predicados
simples.
Evaluación de
expresiones
reiteradas. Raíces y
Potencias.
No se necesitan
procesos especiales de
E/S. Sólo toma y
entrega de información.
No hay solapamiento.
Arch ivos
simples sin
cambios en la
estructura de
datos.
NOMINAL Programación
Estructurada (PE).
Mayormente
subrutinas simples.
Tablas de decisión.
Uso de subrutinas
matemáticas y
estadísticas.
Operaciones con
matrices y vectores.
E/S comprende
selecciones, chequeos
de estado y tratamiento
de errores.
Múltiples archi-
vos de E/S.
Cambios
simples en la
estructura de
datos.
ALTO Programa
estructurado con
muchas subrutinas.
Considerables
módulos. Colas.
Pilas.
Análisis numérico.
Interpolación
multivariable.
Ecuaciones
diferenciales.
Optimización del
solapamiento de E/S.
Operaciones de E/S a
nivel fisico.
Complejas
reestructuracio
nes de los
datos.
Subrutinas
activadas por el
FD.
MUY ALTO Código reentrante y
recursivo. Prioridad
fija de interrupción
manual.
Ecuaciones con
matrices singulares.
Ecuaciones
diferenciales
parciales. Análisis
numérico difícil.
Subrutinas para
interrumpir el servicio.
Manejo de líneas de
comunicación.
Uso
generalizado de
lo anterior.
Archivo
comando de
procesamiento.
Optimización de
búsqueda.
EXTRA
ALTO
Programación
múltiple. Cambios
dinámicos de
prioridad.
Microcódigo.
Análisis numérico
difícil y no
estructurado. Análisis
muy preciso. Métodos
estocásticos.
Operaciones
microprogramables.
Dirección de
datos en
lenguaje
natural.
Estructuras
dinámicas
altamente
enlazadas
Tabla 14.- Evaluación del factor complejidad del producto.
La cantidad de memoria principal ocupada se puede calcular mediante la
fórmula:
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 anticipación 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 142388 APPEND.COM 1725
ASSIGN.COM 1523 PARK.COM 376
SYS.COM 4607 RESTORE.EXE 21750
BACKUP.EXE 23404 DEBUG.EXE 15647
DISKCOMP.EXE 3808 DISKCOPY.EXE 4096
FORMAT.EXE 11015
La MOP se puede calcular a partir de las instrucciones fuente que tendrá su
sistema y un indicador estadístico 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 través
de programas hechos por Ud. o por otras personas. Según cálculos
realizados:
PROLOG k4 = 34 bytes/ instrucción
BASIC. k4 = 44 bytes/ instrucción
Turbopascal k4 = 31 bytes/ instrucción
Wordstar k4 = 48 bytes/ línea
La Memoria ocupada por los datos será:
MOD = CBA * DB
CBA - Cantidad de buffers abiertos por la configuración
DB - Dimensión del buffer
1.3.6.6 Velocidad con que cambian los Medios de Computo. (VMC)
La velocidad de cambio de los medios de cómputo 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 Gestión 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 aplicación 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. Según 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 demás niveles.
1.3.6.8. Capacidad de los analistas. (CAN)
La capacidad de los analistas se mide en términos de percentiles con respecto
a la población total de analistas de sistemas. Los atributos que deben ser
considerados son: habilidad para el análisis, eficiencia e integridad y habilidad
para la comunicación y cooperación. Este atributo es del conjunto de analistas
como un equipo más 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 análisis 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 análisis. El
percentil será con respecto a la población 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 Programación. (ELP)
Es el tiempo promedio de experiencia en el lenguaje de programación 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 Técnicas modernas de Programación. (UTP)
En el uso de modernas técnicas de programación esta incluido:
- Análisis y diseño TOP-DOWN.
- Uso de una notación modular y jerárquica en el diseño.
- Hacer preplanes para revisar el diseño detallado y la codificación
de cada unidad de software.
- Código estructurado.
- Uso de programas de gestión de bibliotecas.
El nivel se determinará así:
- Muy bajo - No se usan estas herramientas.
- Bajo - Se usan experimentalmente.
- Nominal - Tienen algún uso.
- Alto - Tienen bastante uso.
- Muy alto - Se utilizan de forma rutinaria.
De acuerdo al uso que tengan estas técnicas por el equipo de diseño 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 básico
Monitor básico
Programas de auxilio para la eliminación de errores de
programación
Bajo: Compilador lenguaje de alto nivel
Macroemsamblador
Editor de enlaces overlay
Monitor de lenguaje independiente
Editor de documentos en lote
Biblioteca básica de ayuda
Sistema Base de Datos Básico
Nominal: Sistema operativo tiempo real o compartido
Sistema de Dirección de Base de Datos (DBMS)
Biblioteca simple de programación
Editor de documentos interactivo
Editor de enlaces overlay extendido
Programa de auxilio para la eliminación de
errores interactivo
Alto: Sistema operativo de memoria virtual
Sistema de ayuda al diseño de Base de Datos
Biblioteca de apoyo a la programación con
ayuda para el manejo de la configuración
Analizador de uso fijo
Analizador del flujo de programas y textos
Editor de textos básico
Muy Alto: Sistema de documentación integrado
Sistema de control de proyectos
Herramientas automatizadas de diseño
Sistema automático de verificación
Herramientas de propósito especifico
Simuladores de conjuntos de instrucciones
Formateador de display
Herramientas del proceso de comunicación
de control de entrada de datos, ayuda a la
conversión, etc.
1.3.6.15. Requisitos de Planificación. (RPL)
Según 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
aceleración del proyecto por encima del 75 % del tiempo de desarrollo nominal
es considerado imposible al igual que un alargamiento de más de un 60%.
1.3.6.16. Factor de Esfuerzo compuesto. (FEC)
Si un proyecto se desarrolla en modo orgánico 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 característica 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 características:
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.
Solución:
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 características:
a. Pérdidas 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 usarán 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 años de experiencia promedio
i. Muy buenos programadores con seis meses de experiencia promedio en el
Sistema Operativo y doce en el lenguaje de programación
j. Son utilizadas much as de las herramientas modernas de programación
desde hace alrededor de un año
k. Serán utilizadas las herramientas básicas 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. ¿Traería
eso algún beneficio?
5. Si se puede comprar por $8000 una computadora de 96 K de memoria
¿traería esto algún ahorro?
Solución:
a. Interpolando para hallar el esfuerzo:
10 - 8
esf = esf + (ESF - esf )
10 8 32 - 8 32 8
esf = 44 + 1/12 (230 - 44) Utilizando la Tabla 9.
10
esf = 60 Hombres-mes aprox
10
b. Nivel de cada atributo:
RSS- Nominal (1,0) VMC- Nominal (1,0) ESO- Bajo (1,10)
TBD- Bajo (0,94) TRC- Nominal (1,0) ELP- Nominal (1,0)
CPR- Muy alto (1,30) CAN- Alto (0,86) UTP- Alto (0,91)
RTE- Alto (1,11) EXP- Nominal (1,0) UHS- Bajo (1,10)
RMP- Alto (1,06) CPRO Alto (0,86) RPL- Nominal (1,0)
c. Esfuerzo real.
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 más.
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 diseño del software 8040 pesos mientras el costo de la
microcomputadora es de 8000. Es conveniente la inversión.
Tabla 15.- Indicadores de los fatores para el nivel detallado.
N I V E L E S
INDICADOR FASES MUY
BAJO
BAJO NOMINAL ALTO MUY
ALTO
EXTRA
ALTO
RSS 2
3
4
5+6
0,80
0,80
0,80
0,60
0,90
0,90
0,90
0,80
1,00
1,00
1,00
1,00
1,10
1,10
1,10
1,30
1,30
1,30
1,30
1,70
-
-
-
-
TBD
2
3
4
5+6
0,95
0,95
0,95
0,90
1,00
1,00
1,00
1,00
1,10
1,05
1,05
1,15
1,20
1,10
1,10
1,30
-
-
-
-
-
-
-
-
CPR
2
3
4
5+6
0,70
0,70
0,70
0,70
0,85
0,85
0,85
0,85
1,00
1,00
1,00
1,00
1,15
1,15
1,15
1,15
1,30
1,30
1,30
1,30
1,65
1,65
1,65
1.65
RTE
2
3
4
5+6
1, 00
1,00
1,00
1,00
1,10
1,10
1,10
1,15
1,30
1,25
1,25
1,40
1,65
1,55
1,55
1,95
-
-
-
-
-
-
-
-
RMP
2
3
4
5+6
1,00
1,00
1,00
1,00
1,05
1,05
1,05
1,10
1,20
1,15
1,15
1,35
1,55
1,45
1,45
1,85
-
-
-
-
-
-
-
-
VMC
2
3
4
5+6
0,95
0,90
0,85
0,80
1,00
1,00
1,00
1,00
1,10
1,12
1,15
1,20
1,20
1,25
1,30
1,40
-
-
-
-
-
-
-
-
TRC
2
3
4
5+6
0,98
0,95
0,70
0,90
1,00
1,00
1,00
1,00
1,00
1,00
1,10
1,15
1,02
1,05
1,20
1,30
-
-
-
-
-
-
-
-
CAN
2
3
4
5+6
1,80
1,35
1,35
1,50
1,35
1,15
1,15
1,20
1,00
1,00
1,00
1,00
0,87
0,90
0,90
0,85
0,75
0,75
0,75
0,70
-
-
-
-
EAN
2
3
4
5+6
1,40
1,30
1,25
1,25
1,20
1,15
1,10
1,10
1,00
1,00
1,00
1,00
0,87
0,95
0,92
0,92
0,75
0,90
0,85
0,85
-
-
-
-
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 cálculos son el producto de estudios hechos por B. W. Bohem
para las condiciones de Estados Unidos. El procedimiento se puede
automatizar para hacerlo mucho más rápido y más exacto ya que se pudiera
trabajar con las ecuaciones exponenciales originales y no mediante la
interpolación, muchas de las Tablas pueden pasar a formar parte de la Base de
Datos para los cálculos. Este método, como se dijo al principio del capítulo ha
sido el producto de análisis de más de 60 proyectos de distintos tipos
realizados por el autor y de otros cálculos y estimaciones. Se supone que los
valores a los que se arriba por medio de sus cálculos sean una buena
estimación y cuanto más se alejen de ellos peor es.