Planificacin y Control de Proyectos Informticos

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 hallan 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. c. 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. PLANIFICACIN SOFTWARE. I.1. INTRODUCCION.

DE

TRABAJOS

DE

PRODUCCIN

DE

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. I.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:
3

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 adi cionales 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
4

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: 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.
5

I.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. I.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. I.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 y Prueba 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 nuevas arquitecturas de proceso. o

- Un trabajo de proyecto relativamente pequeo. Muy pocos proyectos desarrollados de modo orgnico sobrepasan los 50 mf (50000 instrucciones fuente) - Proyectos en desarrollarse modo orgnico de mayor tamao pueden utilizando software ya existente.

I.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. I.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 son 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. I.3.2. ESTIMACIONES EN MODO ORGNICO. Con los supuestos anteriores y conocidas las etapas del proyecto que considera el modelo veamos 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 I.1. Supongamos 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. Si 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 ejemplo de desarrollo de software de modo orgnico, entonces: 1,05 1,05 Esfuerzo: esf = 2,4 (mf ) = 2,4(32) = 91 hombres-mes mf *1000 Productividad: p = esf = 91 32000 = 352 (mf/hombres-mes)

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 Pequeo Intermedio Medio Grande

Tamao 2000 instrucciones fuentes 8000 " " 32000 " " 128000 " "
9

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 de la figura I.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. I.3.3 DISTRIBUCIN DE TIEMPO Y ESFUERZO DE POR ETAPAS. La figura I.3 presenta los porcentajes de distribucin del esfuerzo y tiempo de desarrollo entre las distintas etapas del ciclo de desarrollo definido en la Tabla 5. 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 Tabla 5.- Estimaciones en proyectos estndares. FASES ESFUERZO Estudio preliminar Anlisis PEQUEO 2 mf 6% 16% Productividad Tiempo Personal mf/hombres-mes meses hombres 400 4,6 1,1 376 8,0 2,7 352 14,0 6,5 327 24,0 16,0 modo orgnico, nivel bsico para TIPOS INTERMEDIO 8 mf 6% 16%

MEDIO 32 mf 6% 16%

GRANDE 128 mf 6% 6%
10

Diseo y desarrollo 68% 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 orgnico, nivel bsico.

65% 25% 40% 19% 11% 19% 59% 22% y esfuerzo por

62% 24% 38% 22%

59% 23% 36% 25%

12% 13% 19% 19% 55% 51% 26% 30% etapas, modo

Ejemplo I.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

11

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 de software de mayor tamao. 6. Los grandes proyectos normalmente exigen mayor esfuerzo. I.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 I.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

% prog = 65 +

(12,8 - 8) (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. I.3.5..MODO 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
% DE CH POR FASE RESPECTO AL TOTAL DEL PROYECTO

PEQUEO INTERMEDIO 2 MF 8 MF 0,3 0,8 3,4 1,3 2,1 0,8 0,5 0,9 2,9 0,8 0,6 0,9 1,2 1,0 1,3 3,4 13,8 5,3 8,5 4,1 0,8 1,5 4,7 1,8 1,4 2,3 2,9 2,3

MEDIO 32 MF 5,0 15,0 56,0 22,0 34,0 20,0 1,7 2,7 7,7 3,6 2,9 5,6 7,3 5,6

GRANDE 128 MF 24,0 63,0 231,0 90,0 141,0 98,0 3,1 4,6 12,2 7,2 8,0 14,0 19,0 14,0

13

Estudio Preliminar 60% 55% 50% 46% Anlisis 84% 84% 84% 84% Diseo y desarrollo 108% 110% 113% 116% Prueba e implantacin 89% 87% 85% 83% Productividad En todo el proyecto 400 376 352 327 Tabla 7.- Indicadores en por cientos, modo orgnico, nivel bsico para proyectos estndares. I.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 8 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 I.4. Un grupo de trabajo va a desarrollar un proyecto que se estima tenga 20 mf. El proyecto se desarrollar bajo las sigui entes 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.
14

- 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 9. 1. 19 % de tdes 19(11,1) = 2,11

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

15

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 Esfuerzo por Etapas (hombres-mes):

Interpolando en la Tabla 9: 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 9: 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

16

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

MODO

TIEMPO DE DESARROLLO ORGNICO 1,05 0,38 esf = 2,4(MF) tdes = 2,5 (esf) SEMILIBRE 1,12 0,35 esf = 3,0(MF) tdes = 2,5 (esf) FUERTEMENTE 1,20 0,32 RESTRINGIDO esf = 3,6(MF) tdes = 2,5 (esf) Tabla 8.- Esfuerzo y tiempo de desarrollo, nivel bsico. 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. I.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:
17

ESFUERZO

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.

INDICADOR/ MODO

PEQUEO INTERMEDIO MEDIO GRANDE 2 MF 8 MF 32 MF 128 MF

MUY GRANDE 512 MF

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

18

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 ESFUERZO ORG-NICO

FASES

PEQUEO mf 6% 16% 68% 26% 42% 16% 7% 17% 64% 27% 37% 19% 8%

2 INTERMEDIO8 mf 6% 16% 65% 25% 40% 19% 7% 17% 61% 26% 35% 22% 8% 18% 57% 27% 30% 25%

MEDIO 32 mf 6% 16% 62% 24% 38% 22% 7% 17% 58% 25% 33% 25% 8% 18% 54% 26% 28% 28%

GRANDE 128 MUY mf GRANDE 512 mf 6% 16% 59% 23% 36% 25% 7% 17% 55% 24% 31% 28% 8% 18% 51% 25% 26% 31% 7% 17% 52% 23% 29% 31% 8% 18% 48% 24% 24% 34%

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 desarrollo Diseo Desarrollo Prueba implantacin

18% y 60% 28% 32% e 22%

TIEMPO DESARROLLO ORGNICO

DE 10% 19% 63% 18% 16% 24% 56% 20% 24% 11% 19% 59% 22% 18% 25% 52% 23% 28% 12% 19% 55% 26% 20% 26% 48% 26% 32% 13% 19% 51% 30% 22% 27% 44% 29% 36% 24% 28% 40% 32% 40%

Estudio Preliminar Anlisis Diseo y desarrollo Prueba e implantacin SEMILIBRE Estudio Preliminar Anlisis Diseo y desarrollo Prueba e implantacin FUERTEMENTE Estudio Preliminar RESTRINGIDO

19

Anlisis Diseo desarrollo Prueba implantacin

30% y 48% e 22%

32% 44% 24%

34% 40% 26%

36% 36% 28%

38% 32% 30%

Tabla 10.- Esfuerzo y tiempo por fases. Todos los modos.

ATRIBUTOS DEL PRODUCTO 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. Se detallar ahora cada uno de los indicadores y como se determina su nivel: I.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.

SIGLAS RSS TBD CPR

20

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. 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: humanas. El efecto de una falla puede significar prdidas de vidas

I.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) 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 archivo 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
21

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 archivo.ndx (Bytes) V.idx - Volumen de datos del archivo.idx (Bytes) V.ntx - Volumen de datos del archivo.ntx (Bytes) Para otros tipos de archivos, consultar la literatura especializada. I.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. I.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: (hr/da) TED - Tiempo consumido en la entrada de los datos 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 TSD = RS * 3600
22

VDS

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 VDE o VDS =Ij (caracteres) j=1 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. m CIj =Aij 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
23

TEA = 3600

(horas/da)

N MUY BAJO RSS TBD RTE SLO DEFECTOS KB/MF V E R -

V E BAJO

S NOMINAL PRDIDAS MODERADAS > 100 <= 100

ALTO

MUY ALTO

POCAS PRDIDAS >10<= 10

GRANDES PRDIDAS PRDIDAS HUMANAS FINANCIERAS KB/MF > 1000 <= 1000 < 70% < 85%

EXTRA ALTO MUCH AS PRDIDAS HUMANAS < 95%

F I G U R A 1.10 -

RMP

VMC

MAYOR 12m MENOS 1m TRC INTERACTIV O CAN 15 perc. 35 perc. EAN 4 meses 1 ao CPRO 15 perc. 35 perc. ESO 1 mes 4 meses ELP 1 mes 4 meses UTP NO SE USAN SE USAN EXPERIMENTALMENTE UHS HERRAM. HERR. BS. BSICAS MINICOMP. MICROCOMP| O FUERTES MICROCOMP . RPL 75% TDES 85% TDES NOMINAL NOMINAL

MENOS DEL 50% DEL USO DEL TIEMPO DISPONIBLE MENOS DEL 50% DEL USO DE LA MEMORIA DISPONIBLE MAYOR 6m MENOR 2s < 4 Horas 55 perc. 3 aos 55 perc. 1 ao 1 ao TIENEN ALGN USO

< 70%

< 85%

< 95%

MAYOR 2m MAYOR 2s MENOR 1s MENOR 2d 4 - 12 Horas | > 12 Horas 75 perc. 6 aos 75 perc. 3 aos 3 aos TIENEN BASTANTE USO -

90 perc. 12 aos 90 perc. SON DE USO RUTINARIO HERR. BS. UTILIT. TODOS LOS MAINFRAME MNIMOS DEL UTILIT. DEL O FUERTES MAINFRAME MAINFRAME MINICOMP.

100% TDES 130% TDES 160% TDES NOMINAL NOMINAL 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. I.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
24

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 MUY BAJO

OPERACIONES CONTROL

DE OPERACIONES MATEMTICAS

OPERACIONES ENTRADA/SALIDA

DE

BAJO

Cdigos lineales: DO IF-THEN-ELSE Predicados simples, pocas subrutinas. Subrutinas en secuencia la mayor parte en predicados simples. Programacin Estructurada (PE). Mayormente subrutinas simples. Tablas de decisin. Programa estructurado con muchas subrutinas. Considerables mdulos. Colas. Pilas. Cdigo reentrante y recursivo. Prioridad fija de interrupcin manual.

Evaluacin de Lecturas simples expresiones Escrituras con formatos matemticas simples: simples. C = A+B*(D-E). Evaluacin de No se necesitan procesos expresiones reiteradas. especiales de E/S. Slo Races y Potencias. toma y entrega de informacin. No hay solapamiento. Uso de subrutinas E/S comprende matemticas y selecciones, chequeos de estadsticas. estado y tratamiento de Operaciones con errores. matrices y vectores. Anlisis numrico. Optimizacin del Interpolacin solapamiento de E/S. multivariable. Operaciones de E/S a Ecuaciones nivel fisico. diferenciales. Ecuaciones con matrices singulares. Ecuaciones diferenciales parciales. Anlisis numrico difcil. Subrutinas para interrumpir el servicio. Manejo de lneas de comunicacin.

OPERACIONES DE MANEJO DE DATOS Arreglos simples en memoria RAM. Archivos simples sin cambios en la estructura de datos. Mltiples archivos de E/S. Cambios simples en la estructura de datos. Complejas reestructuracione s 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

NOMINAL

ALTO

MUY ALTO

EXTRA ALTO

Programacin mltiple. Cambios dinmicos de prioridad. Micro cdigo.

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

micro

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.

25

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 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 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 I.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.

26

* 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. I.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. I.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. I.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 I.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. I.3.6.11. Experiencia en el Sistema Operativo. (ESO)

27

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.

I.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. I.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. I.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
28

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. I.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 considerada imposible al igual que un alargamiento de ms de un 60%. I.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 figura I.6 esf nom = 91 hombres-mes De la figura I.8 CAN = 0,71

29

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 figura I.8 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 = i=1 donde FEi es el factor de esfuerzo para cada caracterstica o atributo i que se toma de la Tabla 11. Ejemplo I.7. Un proyecto de 32 mf desarrollado en un modo fuertemente restringido tiene las siguientes caractersticas: RSS- Bajo TBD- Nominal CPR- Alto RTE- Nominal RMP- Muy alto VMC- Nominal TRC- Bajo CAN- Nominal EAN- Alta CPRO- Nominal ESO- Alto ELP- Bajo UTP- Nominal UHS- Baja RPL- Muy alto FEi

Determine el valor del esfuerzo necesario. Solucin: De la figura I.8: RSSTBDCPRRTERMP0,88 1,0 1,15 1,0 1,21 VMC- 1,0 TRC- 0,87 CAN- 1,0 EAN- 0,91 CPRO- 1,0 ESO- 0,90 ELP- 1,07 UTP- 1,0 UHS- 1,10 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 de la figura I.6. esf nom = 230 hombres-mes

esf real = esf nom (FEC) = 230 (1,067) = 245,4 hombres-mes.

30

Ejemplo I.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 muchas 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 32 - 8 (ESF - esf ) 32 8

1/12 (230 - 44) Utilizando la Tabla 9.

esf = 60 Hombres-mes aprox. 10 b. Nivel de cada atributo:

31

RSS- Nominal (1,0) TBD- Bajo (0,94) CPR- Muy alto (1,30) RTE- Alto (1,11) RMP- Alto (1,06) C. Esfuerzo real.

VMC- Nominal (1,0) TRC- Nominal (1,0) CAN- Alto (0,86) EXP- Nominal (1,0) CPRO Alto (0,86)

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 8 040 pesos mientras el costo de la microcomputadora es de 8000. Es conveniente la inversin.

1.3.7. NIVEL DETALLADO.

32

En el nivel detallado se consideran los mismos factores o atributos que en el nivel intermedio pero no afectando a la totali dad del proyecto sino a cada etapa. En la tabla de 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 esta.

INDICADOR

N I V E L E S FASES MUY BAJO NOMINAL BAJO

ALTO

MUY ALTO

EXTRA ALTO
33

2 0,80 0,90 1,00 1,10 1,30 3 0,80 0,90 1,00 1,10 1,30 4 0,80 0,90 1,00 1,10 1,30 5+6 0,60 0,80 1,00 1,30 1,70 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 1,30 3 0,70 0,85 1,00 1,15 1,30 4 0,70 0,85 1,00 1,15 1,30 5+6 0,70 0,85 1,00 1,15 1,30 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 0,75 3 1,35 1,15 1,00 0,90 0,75 4 1,35 1,15 1,00 0,90 0,75 5+6 1,50 1,20 1,00 0,85 0,70 EAN 2 1,40 1,20 1,00 0,87 0,75 3 1,30 1,15 1,00 0,95 0,90 4 1,25 1,10 1,00 0,92 0,85 5+6 1,25 1,10 1,00 0,92 0,85 Tabla 15.- Indicadores de los factores para el nivel detallado.

RSS

1,65 1,65 1,65 1.65 -

34