Captulo II: Planificacin de proyectos de software.

Asignatura: Ingeniera de Software I.

Docente: Lic. Elizabeth Castro Figueroa.

CAPITULO II: PLANIFICACIN DE PROYECTOS DE SOFTWARE.

2.1. Introduccin.

Un proyecto de software es el proceso de gestin para la creacin de un sistema o software, encierra un conjunto de actividades, como ser:

Estimacin: Es echar una mirada al futuro y aceptar cierto grado de incertidumbre. La estimacin es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costos de tiempo y dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena Ingeniera de Sistemas y Software. Al estimar no solo se toma en cuenta el procedimiento tcnico a utilizar en el proyecto, sino tambin se toma en cuenta los recursos, costos y planificacin. El tamao del proyecto es otro factor importante que puede afectar la precisin de las estimaciones. A medida que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del Software.

La disponibilidad de informacin histrica es otro elemento que determina el riesgo de la estimacin.

La planeacin efectiva de un proyecto de software depende de la planeacin detallada de su avance, anticipando problemas que puedan surgir y preparando con anticipacin soluciones tentativas para resolverlos. El administrador del proyecto es responsable de la planeacin desde la definicin de requisitos hasta la entrega del sistema terminado.

La planificacin de un proyecto se basa en una buena estimacin del esfuerzo requerido para realizarlo, para apoyar esta difcil tarea, se han desarrollado varios mtodos que han encontrado aceptacin comercial en forma creciente en la planificacin del desarrollo de software. La mayora de estos mtodos incluyen modelos empricos de estimacin y poseen como variable manejadora del costo principal el tamao de la aplicacin a desarrollar, lo que es suficientemente difcil de estimar como para que se justifique pensar en automatizar o apoyar fuertemente esta tarea con la generacin de un mtodo fcil de usar.

Para el caso de los modelos basados en lneas de cdigo, se puede observar que en la actualidad, las herramientas de desarrollo proveen la capacidad de disminuir substancialmente el esfuerzo de codificacin, pues la tendencia actual ya no es codificar, sino generar cdigo. Por el lado de las tcnicas basadas en el enfoque de puntos de funcin, el problema radica en que la estimacin slo puede realizarse con un diseo externo acabado de la aplicacin, y si se considera la utilizacin de herramientas de generacin de cdigo (CASE) a la altura en que por fin se puede realizar la estimacin ya se ha consumido la mayor cantidad del esfuerzo del desarrollo (si antes el esfuerzo se centraba en la fase de construccin va codificacin en algn lenguaje de programacin, hoy el esfuerzo se centra en las fases de diseo, ya que la codificacin se ve fuertemente asistida por herramientas automatizadas), por lo que la estimacin ya no sera tan til.

El objetivo de la planificacin del proyecto de software, es proporcionar un marco de trabajo que permita al gestor de planificacin hacer estimaciones razonables de costos, tamao, esfuerzo y planificacin temporal.

Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software y deberan actualizarse regularmente a medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso y peor caso, de modo que los resultados del proyecto pueden limitarse. El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables.

2.2. Estimacin de proyectos de software: Tiempo.Para poder llevar a cabo la estimacin de un proyecto de software se tienen las siguientes alternativas:Dejar la estimacin para ms adelante (comenzar en la fase de construccin).

Utilizar tcnicas de descomposicin.

Utilizar un modelo emprico.Adquirir herramientas automticas de estimacin (Microsoft Project, GanttProject, Sisdel)2.3. Mtodos Gantt, Pert, Delphi.

2.3.1. Mtodo Gantt.Es unos de los primeros mtodos y el ms utilizado en la administracin de proyectos. Es un mtodo grfico de planeacin y control, en la que un proyecto se divide en distintas actividades y se realizan estimaciones acerca de cunto tiempo requiere cada una de ellas, as como el total de tiempo necesario para terminar el proyecto totalmente. Esta grfica muestra las relaciones de tiempo entre los eventos de un programa. Tiene como objetivo fundamental el cumplimiento de sus actividades y la culminacin del proyecto planeado de una forma ordenada y coherente.A continuacin se muestra un Cronograma de actividades utilizando un Diagrama de Gantt:

Observe que en este diagrama se muestran dos fases (fase de inicio y fase de elaboracin considerando RUP). A continuacin se muestra en detalle un diagrama de Gantt de la fase de inicio:

2.3.2. Mtodo Pert (Program Evaluation and Review Technique).Es una tcnica que le permite dirigir la programacin de su proyecto. El mtodo PERT consiste en la representacin grfica de una red de tareas, que cuando se colocan en una cadena, permiten alcanzar los objetivos de un proyecto.Un proyecto necesita organizacin a lo largo de un tiempo determinado. Sin embargo el desarrollo de un proyecto depende de la definicin correcta de las actividades, el mtodo utilizado para este fin se conoce como PERT y consiste en determinar las actividades centrales del proyecto, es decir las que van a permitir el xito o el fracaso del proyecto, para este fin se construye la red de proyectos, donde cada actividad es representada por un flujo con un direccin determinada y un suceso determina el inicio o el fin de una actividad.

Existen restricciones en la construccin de la RED de proyectos, tales como:a) Ninguna actividad debe ser cclica

b) El mtodo Pert exige la construccin de actividades ficticias representadas por un flujo discontinuo que solo muestre las relaciones y cuyo tiempo es igual a cero. Estas son utilizadas para dar solucin a la llegada de dos actividades a un mismo nodo.

La finalidad de este evento es la determinacin de la ruta critica o camino crtico y marca el tiempo total de duracin del proyecto y muestra las actividades clave que deben ser tomadas en cuenta para el xito del proyecto.Proceso de trabajo para la construccin de la red:1. Definicin de las actividades: La primera tarea consiste en identificar todas las actividades que se van a llevar a cabo en el proyecto.Cada actividad a lo largo del proyecto deber estar marcada por una base literal (dar un alias a cada actividad).

2. Identificacin de las relaciones de precedencia: Las relaciones de precedencia vienen a ser las actividades que pueden llevarse a cabo tras la culminacin de una actividad y generalmente estn conformadas por actividades que se pueden desarrollar en paralelo.3. Estimacin del tiempo promedio: Todo proyecto requiere la estimacin de tres tiempos claves que determinan la duracin de la actividad, para ello se debe establecer:a. Estimacin del tiempo ms probable (m). Este viene a ser estimado como el tiempo real en el cual una actividad puede ser llevada a cabo.

b. Estimacin del tiempo ms optimista(a): Es el tiempo que prev el retraso de una actividad.

c. Estimacin del tiempo ms pesimista (b): Es el tiempo que permite optimizar el tiempo de desarrollo de una determinada actividad tomando en cuenta la eficacia y eficiencia del equipo.

En base a esas tres estimaciones se establece el tiempo promedio de cada actividad, el cual se convierte en el tiempo preciso y necesario para cada actividad. Este tiempo es calculado a travs de la siguiente frmula:

4. Construccin de la red de proyectos: Para ello se toma en cuenta las restricciones de la construccin de proyectos y sobre todo las relaciones de precedencia.5. Determinacin del tiempo ms prximo haciendo una revisin hacia delante de la red. Se debe calcular el tiempo ms prximo para cada suceso ( i , j ).

i= tiempo ms prximo (mayor).j= tiempo ms lejano (menor).Se debe representar las diferentes sumas, de los posibles caminos a la actividad final.

6. Calcular el tiempo ms lejano: Para cada suceso y utilizando el tiempo encontrado se debe partir haciendo una revisin hacia atrs, con la finalidad de determinar el tiempo ms lejano.i= tiempo ms prximo (mayor). //(lo ms pronto que podra finalizar)

j= tiempo ms lejano (menor). //(lo ms tarde que podra finalizar)Nota: una vez encontrados los tiempos, se procede a enumerar cada suceso.

7. Clculo de la holgura de sucesos: Para esto es necesario aplicar la siguiente frmula:

Suceso = ( tiempo ms lejano tiempo ms prximo)Suceso= ( j i )

Nota: Todos los sucesos que sean igual a cero pueden formar parte de la ruta crtica, siempre y cuando sean afirmados por el clculo de la holgura de actividades.8. Clculo de la holgura de actividades: Para esto es necesario calcular lo siguiente:

Donde: Y2 : Tiempo ms lejano del suceso Z.

X1: Tiempo ms prximo del suceso Y.

T : Tiempo de duracin de cada actividad.

Nota: Todas las actividades que son igual a cero forman parte de la ruta crtica.2.4. Tcnicas de descomposicin.Para llevar a cabo la estimacin por descomposicin, se sugieren llevar a cabo los siguientes pasos:

2.4.1. Tamao del Software.Existen dos grandes orientaciones de medida del software:

Funcin: Tipo de problema que resuelve - Dentro de esta orientacin se sita la tcnica de los Puntos de Funcin (A. Albrecht -1979)

Tamao: Volumen del software Dentro de esta orientacin se sita modelo COCOMO (Barry Boehm -1981).2.4.2. Estimacin basada en LDC.La mtrica de tamao tradicional para estimar el esfuerzo de desarrollo y productividad ha sido LOC (Lines Of Code) o SLOC (Source Lines Of Code). Se han propuesto varios modelos de estimacin, la mayora de ellos son funciones de las lneas de cdigo (LDC) o de las miles de lneas de cdigo (KLDC) que tendr el software a desarrollar. Generalmente, el modelo de estimacin de esfuerzo consiste de dos partes.

La primera provee una base de estimacin como una funcin del tamao del software y es de la siguiente forma:

Donde:

E : Esfuerzo estimado en meses hombreA, B y C: Son constantes.

KLOC: Tamao estimado del sistema final en miles de lneas de cdigo. La segunda parte del modelo modifica esta estimacin en base a cuantificar la influencia de factores de ambiente, por ejemplo la utilizacin de diferentes metodologas, habilidad del equipo de desarrollo y restricciones de hardware.La definicin de KLDC es importante si se quiere comparar los distintos modelos que se han propuesto en la literatura. Algunos de ellos incluyen lneas de comentarios y otros no. Del mismo modo, la definicin del esfuerzo estimado E es tambin importante., ya que E puede representar slo el esfuerzo de codificacin, o en el otro extremo, el esfuerzo total del anlisis, diseo, codificacin, pruebas y mantencin. Por estas razones, comparar estos modelos se torna complejo. Los principales problemas de utilizar lneas de cdigo como mtrica para estimacin del esfuerzo son la falta de una definicin universal de lnea de cdigo, su dependencia con el lenguaje de desarrollo y la dificultad de estimar en fases tempranas del desarrollo la cantidad de lneas que tendr una aplicacin.2.4.3. Estimacin basada en PF.El anlisis por puntos de funcin es un mtodo para cuantificar el tamao y la complejidad de un sistema software en trminos de las funciones de usuario que este desarrolla (o desarrollar). Esto hace que la medida sea independiente del lenguaje o herramienta utilizada en el desarrollo del proyecto.

El anlisis por puntos de funcin est diseado para medir aplicaciones de negocios; no es apropiado para otro tipo de aplicaciones como aplicaciones tcnicas o cientficas (ya que generalmente median con algoritmos complejos). El enfoque de puntos de funcin tiene caractersticas que permiten superar los principales problemas de utilizar lneas de cdigo como mtrica del tamao del software. Primero, los puntos de funcin son independientes del lenguaje, herramientas o metodologas utilizadas en la implementacin. (no tienen que considerar lenguajes de programacin, sistemas de administracin de bases de datos, hardware, o cualquier otra tecnologa de procesamiento de datos.

Segundo, los puntos de funcin pueden ser estimados a partir de la especificacin de requisitos o especificaciones de diseo, haciendo posible de este modo la estimacin del esfuerzo de desarrollo en etapas tempranas del mismo. Como los puntos de funcin estn ntimamente relacionados con la declaracin de requisitos, cualquier modificacin a sta, puede ser reflejada sin mayor dificultad en una re-estimacin.

Tercero, como los puntos de funcin estn basados en una visin externa del usuario del sistema, los usuarios no tcnicos del software poseen un mejor entendimiento de lo que los puntos de funcin estn midiendo. El mtodo resuelve muchas de las inconsistencias que aparecen cuando se utiliza lneas de cdigo como mtrica del tamao del software.

Los puntos de funcin aparecen con ventajas substanciales por sobre las lneas de cdigo, para fines de estimacin temprana del tamao del software, y por ende, del esfuerzo de desarrollo. Adems es una medida ampliamente utilizada, y con xito, en muchas organizaciones que desarrollan software en forma masiva.

Esta tcnica est basada (orientada) en la teora de la "ciencia del software" desarrollada por Halstead, est orientada al anlisis del proceso de construccin de programas y se basa en la medida del nmero de "unidades sintcticas bsicas" (operadores y operandos).

No se fija en el nmero de LDC sino en su funcionalidad. La finalidad de la tcnica de los puntos funcin es estimar el tamao de un producto software y el esfuerzo asociado a su desarrollo, expresado ste en horas trabajadas por punto funcin, en las etapas previas a su desarrollo.

Los estudios realizados sobre la utilizacin de este mtodo reflejan la bondad del mismo y la existencia de un elevado grado de correlacin entre el nmero de lneas de cdigo (LDC) y la estimacin total de los puntos funcin.

Etapas del mtodo:

Etapa 1. Contar las funciones de usuario.

Etapa 2. Ajustar el modelo en funcin de la complejidad del proceso.

Etapa 1. Contar las funciones de usuario. Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la posicin apropiada de la tabla. Los valores del mbito de informacin estn definidos de la siguiente manera. Nmero de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicacin. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado.

Nmero de salida del usuario: se encuentra cada salida que proporciona al usuario informacin orientada a la aplicacin. En este contexto las salidas se refieren a informes, pantalla, mensajes de error. Los elementos de datos individuales dentro de un informe se encuentran por separado.

Nmero de peticiones al usuario: una peticin est definida como una entrada interactiva que resulta de la generacin de algn tipo de respuesta en forma de salida interactiva. Se cuenta cada peticin por separado.

Nmero de archivos: se cuenta cada archivo maestro lgico, o sea una agrupacin lgica de datos que puede ser una parte en una gran base de datos o un archivo independiente.

Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir informacin a otro sistema.Etapa 2. Ajustar el modelo en funcin de la complejidad del proceso. El recuento de las funciones de usuario se realiza tras una clasificacin previa de stas en tres niveles de complejidad:

Simple

Medio

ComplejoNo obstante la determinacin de la complejidad es algo subjetivo. Tras esta divisin de las funciones de usuario segn su tipo y complejidad se les aplica un peso, como se muestra en la siguiente tabla, obteniendo el total de los puntos funcin sin ajustar:

PARMETRO DE MEDICINCUENTAFACTOR DE PONDERACINSUBTOTAL

SIMPLEMEDIOCOMPLEJO

Entrada de usuario346

Salida de usuario457

Peticiones de usuario346

Archivos71015

Interfaces externas5710

CUENTA TOTAL

Valoracin segn el nivel de complejidad

Para calcular los Puntos de Funcin se utiliza la siguiente relacin.

Donde:

CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior.

fi : Donde i puede ser de uno hasta 14 los valores de ajuste de complejidad. (La SUM depender de los grados de influencia).Esta complejidad puede verse afectada segn este mtodo por catorce caractersticas, las cuales se evalan de conformidad a una escala de "grados de influencia" que toma valores enteros comprendidos entre 0 (sin influencia alguna) y 5 (grado de influencia ms elevado). Es decir:

Valores de Di

No presente o no influencia = 0

Influencia insignificante o incidental = 1

Influencia moderada = 2

Influencia promedio o medio = 3

Influencia significante = 4

Influencia esencial o fuerte, a travs de = 5Los valores constantes de la ecuacin anterior y los factores de peso aplicados en las encuestas de los mbitos de informacin han sido determinados empricamente. Una vez calculado los puntos de funcin se usan de forma analgica a las LDC como medida de la productividad, calidad y otros productos del software.

Productividad = PF / persona-mes

Calidad = Errores / PF

Costo = Dlares / PF

Documentacin = Pags. Doc / PF2.5. Modelos empricos de Estimacin.Un modelo emprico de estimacin para software puede utilizar frmulas derivadas empricamente para predecir el esfuerzo como una funcin de LDC (lneas de cdigo) y PF (Puntos de funcin). Los datos empricos que soportan la mayora de los modelos de estimacin se obtienen de una muestra limitada de proyectos. Es por eso que estos modelos de estimacin no son adecuados para todas las clases de software y en todos los entornos de desarrollo. Por consiguiente, los resultados obtenidos de dichos modelos se deben utilizar con prudencia.

Estructura de los modelos de estimacin: Un modelo comn de estimacin se despega utilizando anlisis de regresin sobre los datos compilados de proyectos anteriores de software. La estructura, global de tales modelos adquiere la siguiente forma propuesta por Len O. Ejiogo:

Donde:

A, B y C : son constantes conseguidas empricamente.

E : es el esfuerzo en meses/persona.

ev : es la variable de estimacin (LDC o PF)Adems de la dependencia sealada en la ecuacin, la mayora de los modelos de estimacin tienen algn componente de ajuste del proyecto que permite ajustar E debido a otras caractersticas del proyecto (ejemplo: complejidad del problema, experiencia del personal, entorno de desarrollo).

Existen muchos modelos de estimacin orientados a LDC entre los que se encuentran:E = 5.2 x (KLDC)0.91

Modelo de Walston-Felix.E = 5.5 + 0.73 x (KLDC)1.16

Modelo de Bailey-Basisli E = 3.2 x (KLDC) 1.05

Modelo simple de BoehmE= 5.288 x (KLDC)1.047

Modelo Doty para KLDC >9 Tambin se han propuesto los modelos de estimacin orientados a PF. Entre estos modelos se encuentran:

E = -13.39 + 0.054 PF

Modelo de Albretch y GaffneyE = 60.62 x 7.728 x 10 PF8

Modelo de Kemerer E = 585. 7 + 15.12 PF

Modelo de Matson, Barnett y MellichampDe los modelos que se indican cada uno traer un resultado diferente para el mismo valor de LDC y PF. Los modelos de estimacin se deben evaluar para necesidades particulares.2.6. Modelo constructivo de costos COCOMO.COCOMO (COnstructive COnst MOdel) es una herramienta utilizada para la estimacin de algunos parmetros (costos en personas, tiempo, ...) en el diseo y construccin de programas y de la documentacin asociada requerida para desarrollarlos, operarlos y mantenerlos (Segn Boehm), es decir, en la aplicacin prctica de la Ingeniera del Software.Debido a la "crisis del software", con problemas como:

Incremento de la complejidad de los sistemas (mecanizar reas ms amplias y complejas)

Los proyectos nunca terminan en el plazo previsto. Las estimaciones se realizan en un momento en el que no se tiene suficiente informacin o sta no se usa correctamente para poder determinar plazos.

Los problemas ms costosos se producen en las fases ms tempranas del desarrollo del software.

Los costes de mantenimiento actualmente son muy elevados debido a la continua evolucin de los sistemas y a los errores en su concepcin.

Distinto vocabulario incluso dentro de los integrantes del propio equipo de desarrollo informtico.

Cada diseador utiliza una "forma de hacer" diferente para definir un sistema de informacin.

Riesgo inherente a que la definicin de los sistemas la realicen tcnicos provisionales.

Escasa implicacin del usuario en las tareas de desarrollo de los nuevos sistemas.

Comienza una preocupacin por controlar los costos de desarrollo, as como la distorsin de este desarrollo respecto a la planificacin establecida.

"Para llevar a cabo un buen proyecto de desarrollo de software, debemos comprender el mbito del trabajo a realizar, los recursos requeridos, las tareas a ejecutar, las referencias a tener en cuenta, el esfuerzo (COSTO) a emplear y la agenda a seguir." (R. Pressman)Para intentar dar solucin a estos problemas se han introducido en la Ingeniera del Software una serie de tcnicas, utilizadas dentro de las tareas de planificacin, que ayudan a planificar y controlar el esfuerzo y el tiempo necesario de desarrollo:

Tcnicas de estimacin del esfuerzo (costo) de desarrollo. Dentro de las cuales se sita COCOMO.

Tcnicas de planificacin y seguimiento de proyectos.El problema de realizar estimaciones es que en el instante en que se requiere dicha estimacin no se tiene suficiente informacin para que sta tenga la exactitud requerida. No obstante, el desarrollo de software presenta un comportamiento caracterstico que puede ser analizado y empleado para planificar adecuadamente su desarrollo dentro de unos lmites de tiempo y costo razonables. Se necesita por tanto conocer:

cmo se comportan los trabajos de desarrollo.

qu factores pueden ser controlados.

cules de stos son determinantes para el proceso de desarrollo de un proyecto.

La utilizacin de LDC (lneas de cdigo) es discutida por algunos autores pues la consideran una medida poco consistente, la cual presenta variaciones difcilmente ponderables:

- longitud

- dificultad

- cantidad de informacin

- funcionalidad

- etc.

Ms an si se trata de lneas escritas en distintos lenguajes.

El modelo COCOMO (presentado por Barry Boehm en 1981), basndose en una estimacin de LDC, ha sido ampliamente aceptado por:

Ser un modelo pblico bien documentado.

Debido a que los datos de entrada que solicita el modelo y sus resultados son mucho ms claros y precisos que en otros modelos.

Admite la posibilidad de calibrarse para entornos especficos.Este modelo se convirti en el ms conocido y referenciado, adems del ms documentado de todos los modelos de estimacin de esfuerzo de las actividades de diseo, codificacin, pruebas y mantenimiento.

La versin inicial de COCOMO se obtuvo a partir de la revisin de los modelos de costos existentes, en la cual participaron varios expertos en direccin de proyectos, los cuales tenan experiencia en la utilizacin de diferentes modelos de estimacin.

Inicialmente se cre un modelo con un nico modo de desarrollo, pero posteriormente se vio que la aplicacin del modelo a una amplia variedad de entornos implicaba la creacin de los tres modos de desarrollo:

Orgnico. Proyectos de no ms de 50 KLDC (50.000 LDC), sobre reas muy especficas y bien conocidas por el equipo participante.

Semiempotrado (semilibre). El nivel de experiencia del equipo de desarrollo se sita en niveles intermedios y suelen ser sistemas con interfaces con otros sistemas, siendo su tamao menor a 300 KLDC. Empotrado (restringido). Proyectos de gran envergadura, con una exigencia de altos niveles de fiabilidad y en los que participan muchas personas.Por otra parte Boehm presenta una jerarqua de modelos de estimacin segn el nivel de detalle empleado en su utilizacin:

Bsico. Modelo que calcula el esfuerzo de desarrollo como funcin del tamao estimado del software en LDC. Adecuado para realizar estimaciones de forma rpida, aunque sin gran precisin.

Intermedio. En ste el esfuerzo se calcula como funcin del tamao del producto, modificado por la valoracin de los atributos directores del coste, los cuales incluyen una valoracin subjetiva del producto, hardware, personal, etc. Los valores de los diferentes atributos se consideran como trminos de impacto agregado al coste total del proyecto.

Detallado. En l la valoracin de los atributos tiene en cuenta su influencia en cada una de las fases de desarrollo del proyecto.

Las estimaciones relacionadas con el costo (esfuerzo) se expresan en meses/hombre (tiempo que requerira una sola persona para desarrollar el sistema), considerando que la dedicacin de una persona es de 152 horas al mes.

Modelo Bsico:

2.7. Herramientas CASE para administracin de proyectos de Software.Microsoft Project.2.8. Ejercicios.

EJERCICIO 1: PUNTOS FUNCIN.

Proporcione un valor que represente la funcionalidad de un sistema con 30 entradas de usuario (simples), 40 salidas de usuario (simples), 25 peticiones de usuario (simples), 5 archivos (medios) y 2 interfaces externas (medias). Adems la importancia de las copias de seguridad es media, la comunicacin de datos es incidental, no existen funciones de procesamiento distribuido, el rendimiento tiene una importancia moderada, es esencial que se ejecute en un SO existente, requiere una significativa entrada de datos interactiva, sobre una cantidad moderada de pantallas, los archivos se almacenan en memoria, los archivos entradas y salidas se pueden considerar como de moderada importancia, el procesamiento interno es moderadamente complejo, ha sido esencial la reusabilidad del cdigo durante su diseo, y tiene un importancia moderada el hecho de incluir en el diseo la conversin e instalacin, el soporte de mltiples organizaciones y la facilidad de uso por el usuario.

EJERCICIO 2: COCOMO.

Un estudio inicial determina que el tamao del producto estar alrededor de 32.000 LDC, a partir de las ecuaciones obtener las caractersticas del proyecto.

Aplicando el modelo bsico:

Por el tamao del producto a desarrollar vemos que debemos aplicar las ecuaciones asociadas al modo orgnico, obteniendo lo siguiente:

ED = 2,4 (32)1,05 = 91 hombre-mes

TD = 2,5 (91)0,38 = 14 meses

PR = 32.000 / 91 = 352 lneas/hombre-mes

PE = 91 / 14 = 6,5 hombresHa =Y2 (X1 + T)

1