Capitulo V

PLANIFICACIN
Todo proyecto est compuesto de tareas o de actividades. Para que el proyecto tenga xito, antes de todo es necesario planificar con cuidado las tareas y luego organizarlas en orden de prioridad. Figura 23. Procesos bsicos de planificaci

PLANEAR ES TAN IMPORTANTE COMO HACER, PORQUE:

Hace posible la utilizacin de actividades en forma ordenada y con un propsito. Todos los esfuerzos van dirigidos hacia los resultados que se desean y se obtiene con ello una eficiente sucesin de ellos. Se disminuye la condicin azarosa de enfocar y ejecutar el trabajo. Las actividades se coordinan d tal manera que se consigue la integracin de una gran fuerza, movindose armoniosamente hacia la meta predeterminada. Se reduce el trabajo improductivo y se reducen los costos se estabiliza la empresa. Todo plan tiende a ser econmico; desgraciadamente, no siempre lo parece, porque todo plan consume tiempo, que, por lo distante de su realizacin, puede parecer innecesario e infecundo.

5.2 Diagramas PERT/CPM.

ESTRUCTURA DE DESCOMPOSICIN DEL PROYECTO (EDP) O (WBS) Estructura de descomposicin del proyecto (EDP) o Work Breakdown Structure (WBS); es una divisin natural del proyecto para llegar al producto o productos finales con la finalidad de:

Identificar y definir el trabajo a desarrollar. Identificar los centros responsables de estos trabajos. Concretar la estructura que contempla desde los objetivos estratgicos hasta la base divisible de los mismos, mediante la integracin de la organizacin, planificacin y control de los trabajos que se desarrollan.

Por qu debemos desarrollar una estructura de descomposicin del proyecto (EDP)? Es el mtodo para definir las actividades del proyecto, el cul ha sido utilizado por muchos autores en forma extensa y que ha resistido la prueba del tiempo. sta implica, visualizar el proyecto jerrquicamente en metas, objetivos, actividades y paquetes de trabajo. La EDP facilita las actividades de planificacin, presupuesto, programacin y control al director de proyecto y su equipo. Cules son las caractersticas satisfactorias de una estructura de descomposicin del proyecto?

Tener la certeza que se han identificado todas las actividades necesarias para alcanzar de manera satisfactoria, los objetivos del proyecto. Es necesario examinar en primer lugar las caractersticas de las actividades que constituyen la EDP. Una actividad bien definida tiene las siguientes caractersticas: Su estado y su conclusin se miden con facilidad. Posee un evento inicial y uno final bien definido. Es familiar (pueden haberse realizado antes) y el tiempo para completarla, as como sus costes, pueden estimarse fcilmente a partir de experiencias previas. Comprende asignaciones de trabajo que son administrables, medibles, integrables e independientes de otras actividades. Deber constituir normalmente una corriente continua de principio a fin.

En el caso de otras actividades que podran incluirse en el proyecto, tmese en consideracin lo siguiente:

Programacin de la entrega de materiales. Actividades de subcontratistas que podran tener un impacto sobre las actividades del proyecto.

Disponibilidad de equipo. Entrenamiento y disponibilidad de personal.

Pasos para construir una estructura de descomposicin del proyecto (EDP) No existen reglas especficas para la creacin de la EDP, no obstante, es un proceso que se ha empleado con xito. Vase fig. 24. Los pasos para la creacin:

Divida el proyecto en sus objetivos principales de manera tal que el proyecto quede claramente definido por ellos. Fragmente cada objetivo en las actividades que son necesarios llevar a cabo para alcanzarlo. En el caso de las actividades que carezcan de una o ms caractersticas, divdalas en las sub-actividades que las componen. Repita el paso anterior hasta que todas las actividades posean las caractersticas deseadas. Las sub-actividades de ms bajo nivel en la jerarqua constituirn la base de los paquetes de trabajo que debern realizarse para completar el proyecto.

Caractersticas de la EDP

Se detalla en forma jerarquizada todo el trabajo a realizar, hasta el nivel de tarea. Muestra la organizacin interna del proyecto (responsabilidades y dependencias) Muestra las fechas de inicio y finalizacin, los recursos y los responsables de cada tarea. El desglose a nivel de tarea facilita la estimacin, programacin y control del proyecto. Las actividades y recursos se codifican para facilitar el control y preparacin de reportes. La forma de dividir el trabajo depende del tipo de proyecto, pudiendo ser por etapas, disciplinas, funciones, componentes, zonas geogrficas, etc. La cantidad depende de la complejidad del proyecto (recomendable entre 4 y 6 niveles). Un elevado nmero de niveles da origen a la creacin de sub-proyectos. Un excesivo nmero de niveles dificulta el sistema de control. Idealmente, cada especialista programa en detalle no ms de 2 a 3 niveles.

Vase fig. 25

Fig. 24. Ejemplo de Estructura de Descomposicin del Proyecto. El uso de la estructura de descomposicin del proyecto EDP es valiosa en el proceso de planificacin y en la ejecucin inicial. Su mayor ventaja consiste en ofrecer una imagen global, aunque detallada, del proyecto. De esta manera, constituye el fundamento para la planificacin de plazos, costes y ejecucin, as como para el control y la elaboracin de informes. Conforme avanza el proyecto, la EDP se utilizar para generar una representacin de red del proyecto. Siendo esta red la principal herramienta de control que emplear el director de proyecto para comparar el avance planificado respecto al avance real y para decidir los cambios que se seguirn como resultado de esa evaluacin. Habr proyectos para los que una representacin de red de una EDP pueda parecer demasiado difcil de generar; en tales casos, el proyecto puede descomponerse, por ejemplo, por unidades funcionales de negocios, por localizacin geogrfica, por departamentos, de acuerdo a las habilidades requeridas o con base en la disponibilidad de equipo o material.

Fig. 25. Caracterstica de la EDP

Figura 26. EDP Base para Programar el Proyecto. Anexo 1. Ejemplo de Construccin y clculos del diagrama Pert

5.2.1 Tcnicas de programacin de tareas. Las tcnicas de programacin se ocupan de estructurar las tareas a realizar dentro del proyecto, definiendo la duracin y el orden de ejecucin de las mismas, mientras que las tcnicas de programacin tratan de ordenar las actividades de forma que se puedan Identificar las relaciones temporales lgicas entre ellas, determinando el calendario o los instantes de tiempo en que debe realizarse cada una. La programacin debe ser coherente con los objetivos perseguidos y respetar las restricciones existentes (recursos, costes, cargas de trabajo, etc...). La programacin consiste por lo tanto en fijar, de modo aproximado, los instantes de inicio y terminacin de cada actividad. Algunas actividades pueden tener holgura y otras son las actividades crticas (fijas en el tiempo). Los pasos a seguir para la programacin son los siguientes:
1. Construir un diagrama de tiempos (instantes de comienzo y holgura de las actividades). 2. Establecer los tiempos de cada actividad. 3. Analizar los costes del proyecto y ajustar las holguras (proyecto de costemnimo).

Como resultado de estas actividades se obtienen los siguientes datos:

1. Disponer de un diagrama de tiempos. 2. Conocer actividades crticas y determinar la necesidad de recursos.

La eleccin de una u otra herramienta depende de los resultados que deseemos conocer. Las distintas tcnicas pueden basarse en la escala temporal o en las dependencias entre tareas, en ninguna o en ambas, tal y como se muestra en la tabla siguiente:

Cuadro 3. Representacin temporal de Dependencias entre herramientas 5.2.2 Manejo de holguras. La holgura de una actividad es el margen suplementario de tiempo que tenemos para determinar esa actividad. Las actividades crticas no tiene holgura, como se ver despus. Existen diversos tipos de holgura: holgura del sucesos y holguras de la tarea.

La holgura del suceso se calcula como sigue: HS = MAC MIC Las holguras de las tareas pueden ser de tres tipos:

Fig.27. Ejemplo de una holgura.

Holgura total de una tarea. Es el margen suplementario de tiempo de esa actividad sin que se altere el MIC de ninguna actividad crtica.

HT (X) = MAC (B) MIC (A) DX

Holgura libre de una tarea: es el margen suplementario de tiempo para esa actividad sin que se altere el MIC de cualquier actividad.

HI (X) = MIC (B) MIC (A) DX

Holgura independiente Hi: es el margen suplementario de tiempo que existe en una actividad si las actividades precedentes terminaran lo ms tarde posible, y las actividades posteriores empezaran lo antes posible.

Hi = MIC (B) MAC (A) DX Actividades crticas: Una actividad es crtica cuando no se pueden cambiar sus fechas de comienzo y finalizacin sin modificar la duracin total del proyecto. La concatenacin de actividades crticas es el camino crtico. En una actividad crtica la fecha early (temprana) coincide con la ms tarda de comienzo, y la fecha ms temprana de finalizacin coincide con la fecha last (ultima) de la actividad. La holgura total es 0. 5.2.3 La ruta crtica. Actualmente se tomo lo mejor de dos mtodos: PERT: Program Evaluation and Revies Technique. y CPM: Critical Path Method. Ahora llamado Mtodo de la Ruta Critica.

Este mtodo fue diseado para proporcionar diversos elementos tiles de informacin para los administradores de proyectos, esto es, las actividades que limitan la duracin de un proyecto. El objetivo general de este mtodo es: que se desee el costo de operacin de un proyecto mas bajo posible, dentro de un tiempo limite disponible. Dentro de las preguntas que la ruta critica responde a los tomadores de decisiones tenemos a las siguientes:
1. Cul es el tiempo total para terminar el proyecto? 2. Cules son las fechas programadas de inicio y de terminacin para cada una de las actividades especificas? 3. Qu actividades criticas y deben terminarse exactamente como se programaron para mantener el proyecto o tiempo? 4. Cuanto se pueden retardar las actividades no criticas antes de incrementar el tiempo de terminacin del proyecto?. Etc.

Para ilustrar los conceptos bsicos del mtodo de la ruta critica (CPM), considere el ejemplo dado en la figura 28; de la red AON de un proyecto, donde los nodos en forma de rombo representan eventos, los nodos en forma de circulo (con una letra o nombre como identificador) representan tareas y los arcos indican las relaciones de precedencia. Observe tambin que cada tarea (nodo) indica su duracin esperada; en este ejemplo, las duraciones esperadas estn dadas en meses. Es importante recordar que el calculo de la ruta critica supone que estas duraciones son deterministicas (es decir, conocidas y constantes).

Fig. 28. Ruta critica (CPM). En este pequeo ejemplo, es claro que existen dos rutas en la red desde el nodo INICIO hasta el nodo FIN: INICIO-A-B-FIN e INICIO-C-FIN. Dado que para terminar todo el proyecto deben estar terminadas todas las tareas, es claro que se necesitan once meses para completarlo, suponiendo que los eventos INICIO y FIN no requieran tiempo y que la duracin de las tareas sea justo la indicada. As el tiempo mnimo necesario para terminar un proyecto es igual a la longitud de la ruta mas larga a travs de la red. Esta ruta se conoce

como ruta critica y se indica con flechas mas gruesas. La duracin del proyecto, 11 meses, definida por la ruta critica, se conoce tambin como el tiempo de ejecucin del proyecto. Tambin muestran el concepto de tiempo holgura total o tiempo flotante. Como las tareas en la ruta INICIO-A-B-FIN solo requieren diez meses, para las tareas A y B pueden retrasarse hasta un mes sin demorar el tiempo de ejecucin del proyecto. As, la holgura asociada con las tareas A y B es un mes (a este tipo de holgura se le conoce como holgura total o flotante total). Debe notarse que esta holgura es una medida dependiente de la ruta; es decir, si la duracin de la tarea A aumenta un mes (a ocho meses), la holgura total de la tarea B, as como la holgura total de la tarea A, se reducir de un mes a cero. 5.2.4 Manejo de recursos Todas las fases de desarrollo de sistemas de informacin involucran muchos tipos de actividades diferentes que juntos forman un proyecto. El lder del proyecto debe administrar el proyecto cuidadosamente para que llegue a ser un proyecto exitoso. La administracin de proyectos involucra todas las tareas generales de planeacin y control. La planeacin incluye todas las actividades requeridas para seleccionar un equipo para analisis de sistemas, la asignacin de los miembros del equipo a los proyectos adecuados, la estimacin del tiempo requerido para completar cada tarea y la calendarizacin del proyecto para que las actividades sean terminadas en forma ordenada. Vamos a contemplar varias tcnicas que se pueden utilizar en la realizacin del calendario. Algunas son muy sencillas y no muestran la interrelacin entre las actividades, como son el diagrama de hitos, los diagramas de Gantt. Para mostrar dicha interrelacin, se hace necesario el anlisis de las redes de precedencia por medio de la tcnica PERT. Diagrama de hitos. Podemos determinar que "El diagrama de hitos es el mtodo mas simple para determinar el calendario. Es un cuadro o tabla formado por dos columnas; en la primera se sealan las actividades y en la segunda se indican sus fechas de finalizacin. Las ventajas de esta tcnica son la factibilidad de uso y el mnimo coste de preparacin. Las desventajas son la incertidumbre existente sobre las fechas de comienzo de las actividades y la imposibilidad de reflejar las interrelaciones entre ellas. Esta tcnica tambin se utiliza para resumir calendarios complejos que contienen muchas tareas".

Cuadro 4. Diagrama de hitos.

5.3 Grficas de Gantt.

El Diagrama de Gantt consiste en una matriz de doble entrada en la que se anotan en las lneas, las diferentes actividades que componen un programa o un proyecto y en las columnas, el tiempo durante el cual se desarrollarn esas actividades. Una barra horizontal frente a cada actividad, representa el perodo de duracin de la misma. La longitud de la barra indica las unidades de tiempo, sealando la fecha de inicio y la fecha de finalizacin de la actividad. Proceso de construccin del Diagrama de Gantt Listado y ordenamiento de actividades. El primer paso consiste en establecer la lista de actividades ordenadas segn han de ser ejecutadas. Estimacin del tiempo de duracin de cada actividad. Deber estimarse el perodo que lleva cada actividad para su realizacin. Como la ejecucin de las actividades incluye dos variables estrechamente ligadas: tiempo y recursos, se debe tener presente la real disponibilidad de recursos humanos, materiales, financieros, etc. y la posibilidad de desarrollar la actividad en el tiempo previsto; por lo que se estara construyendo un calendario operativo. Construccin del grfico. En este tercer paso la tarea principal es la construccin del grfico teniendo presente el calendario operativo, construyendo barras horizontales cuya longitud representa la duracin en el tiempo de cada actividad indicada. Ventajas del diagrama de Gantt

Entre las ventajas del diagrama de Gantt, se encuentran:

Es muy sencillo de disear y fcil de entender. Da una representacin global del proyecto. Es posible generarlo y manejarlo con paquetes SW comerciales.

Desventajas del diagrama de Gantt. El diagrama de Gantt presenta una serie de inconvenientes, como son:

No muestra relaciones de precedencia entre actividades de un modo explcito. No permite optimizar el desarrollo de un proyecto (debido a la desventaja anterior). No muestra las actividades crticas o claves de un proyecto.

Anexo 2. Ejemplo de construccin de diagrama Gantt

5.4 Especificacin de tareas.

Mediante una tormenta de ideas del equipo de trabajo se puede elaborar una relacin de actividades especificas, detalladas, necesarias para realizar el proyecto global, en particular en proyectos pequeos. Sin embargo, para aquellos en los que se usa una estructura de divisin del trabajo, la persona o el equipo responsable de cada tarea puede definir las actividades individuales. Una actividad es una pieza de trabajo establecida que exige tiempo. No siempre requiere el esfuerzo de los participantes, por ejemplo, el esperar que se endurezca el concreto puede requerir de varios das pero no de esfuerzo humano alguno. Cuando se han definido todas las actividades para cada uno de los paquetes de trabajo, el paso siguiente es mostrarles en forma grfica en un diagrama de red que muestre el orden apropiado y las interrelaciones para lograr el alcance global del trabajo del proyecto.

5.5 Organizacin de tareas y definicin de responsabilidades.

Organizacin de tareas:

Dada la importancia que tiene la buena organizacin a la hora del desarrollo de proyectos, se muestra algunos recursos para organizar las tareas. Dyplanner, Plantillas para organizacin personal . Incluye agenda telefnica y directorio, ficha para organizar acciones coordinadas, cuadrante de acciones, ficha para tareas pendientes, miniagenda, lista rpida, planning de objetivos, matriz de prioridades

importancia-urgencia, detalles de proyectos, diario de viajes, planificacin de compras, hoja de gastos. Pocketmondd,Aplicacin para crear nuestro propio cuaderno personalizado en un Din A4. Po demos elegir las categoras, la informacin que queremos meter en cada pgina (portadas, lneas, pginas cuadriculadas, diarios, etc) y al imprimirlo y plegarlo segn sus instrucciones, tendremos un prctico planificador de bolsillo con la forma de una prctica libreta. DRL(Diagramas de Responsabilidad Lineal). El primer paso es determinar las tareas a realizar, luego es el turno de definir las responsabilidades de todas las personas en base a las tareas que se realizaran; tomando en cuenta las aptitudes, y dems caractersticas del personal para delegar responsabilidades, y al final se logre un buen trabajo. Todo esto permite que la planeacin funcione como un conjunto armnico, En momentos tan exigentes para los encargados del proyecto, normalmente la mente de los ejecutivos est concentrada en los esfuerzos tcticos y estratgicos de la supervivencia. Pareciera no quedar tiempo para las personas, los individuos que colaboran en el mismo, quienes normalmente estn viviendo estos momentos en una mezcla de angustia e incertidumbre. Existe una forma de que esta situacin se torne ms positiva, con beneficios para el proyecto y para los individuos. La clave consiste en "bajar" la estrategia a las responsabilidades de cada una de las personas. Si bien normalmente las sesiones de planeamiento estratgico son desarrolladas por un grupo compuesto por la direccin y la alta gerencia, en la mayora de las empresas existe un quiebre entre las acciones estratgicas definidas y las responsabilidades de los empleados en la organizacin; lo mismo pasa en la administracin de proyectos, En la mayora de los casos las personas (con responsabilidades definidas formalmente o informalmente) responden a iniciativas sectoriales y desconocen el aporte que pueden hacer con su trabajo a las iniciativas estratgicas de la empresa. El segundo paso es sincronizar los engranajes: Definir las responsabilidades bsicas de las personas, y despus hacer una " traduccin" de la estrategia a las responsabilidades, para adicionar stas a las responsabilidades tradicionales. La definicin de responsabilidades de las personas debe ser hecha con ciertos requisitos: no pueden ser muchas, deben estar consensuadas, y a su vez todo el proceso debe guardar una dosis de coherencia entre los sectores que darn forma al proyecto. Todo esto debe ser realizado en un proceso de comunicacin entre todos los miembros que se involucraran con el mismo. Resulta muy til el uso de todos los canales : la newsletter (boletn de noticias) de la empresa, los pizarrones, el mail, etc. Estos procesos de cambio,

que normalmente son dirigidos por el responsable del proyecto "capital humano" o su posicin equivalente, requieren de un apoyo fuerte de los directores y la alta gerencia. Estructura y filosofa del DRL (diagramas de responsabilidad lineal) Tpicamente, el DRL muestra estas caractersticas.

Informacin del ncleo de los diagramas de la organizacin convencionales y manuales asociados, expuestos en un formato matricial. Una serie de ttulos de puestos listados a lo largo de la parte superior de la tabla (columnas). Una lista de responsabilidades, autoridades, actividades, funciones y proyectos hacia abajo del lado del diagrama (hileras).

Una serie de smbolos que indican el grado o extensiones de autoridad y que explican la relacin entre las columnas y las hileras.

5.6 Estimacin de tiempos.

La posibilidad de especificar un calendario para cada proyecto, e incluso para cada recurso permite al usuario establecer con mayor exactitud la duracin real de cada actividad. Todas las aplicaciones incorporan esta caracterstica mediante la cul se pueden determinar los das laborables y los que no lo son, con la posibilidad de indicar, en este ltimo caso, sus causas (vacaciones, enfermedad). Estos datos repercuten directamente en los plazos de ejecucin, de forma que cuando el usuario indica para una determinada actividad, cierto nmero de das de duracin, el sistema calcula la fecha de finalizacin de la misma teniendo en cuenta los das festivos.

5.7 Estimacin de esfuerzos.

Una distribucin recomendada de esfuerzo en las fases de definicin y desarrollo se conoce normalmente como la regla 40-20-40. El cuarenta por ciento de todo el esfuerzo o mas se asigna a las tareas de anlisis y diseo. Un porcentaje similar se aplica a las pruebas. Se puede deducir correctamente que no se insiste mucho en la creacin de cdigo (un 20 por 100 del esfuerzo). Esta distribucin de esfuerzo debera usarse como una directriz solamente. Las caractersticas de cada proyecto dictan la distribucin del esfuerzo. El esfuerzo gastado en la planificacin de un proyecto raramente supera mas del 2 o el 3 por 100, a no ser que el plan comprometa a una organizacin a grandes gastos por el gran riesgo. El anlisis de los requisitos pueden comprender de un 10 a un 25 por 100 del esfuerzo del proyecto. El esfuerzo invertido en anlisis o creacin de prototipos debera crecer proporcionalmente con el tamao y la complejidad del proyecto. Entre un 20 y un 25 por 100 del esfuerzo se

aplica normalmente al diseo del software. Tambin debe considerarse el tiempo empleado en la revisin del diseo y la repeticin subsiguiente. Debido al esfuerzo aplicado de software, el cdigo debera realizarse con relativa poca dificultad. Se puede alcanzar un rango del 15 al 20 por 100 del esfuerzo global. Las pruebas y las subsiguientes depuraciones de error pueden dar cuenta de entre un 30 y un 40 por 100 restante del esfuerzo de desarrollo del software. La importancia del software dicta a menudo la cantidad de pruebas que se requieren. Si el software se ve desde el punto de vista humano (es decir, el fallo del software puede generar perdidas de vidas humanas), se pueden considerar incluso porcentajes mas altos.

5.8 Clculo de costos.

El costo de un proyecto es de inters continuo y vital para los coparticipantes. Con el precio de produccin equivocado, incluso el producto mas fantstico puede ser un desastre. La estimacin de costo mas sencilla es la que proporciona un costo fijo desde el principio, sin permitir desviaciones en ninguna circunstancia. Aunque las organizaciones muy competentes tienen suficientes aptitudes para cambiar las variables restantes (capacidad, programa de tiempos y calidad) para cumplir con un costo predeterminado, la rigidez absoluta en el costo no siempre se adopta. Suponga, por ejemplo, que un proyecto que desarrolla un producto que se vende muy bien se queda sin fondos cuando lleva el 90%. En lugar de abandonar todo el proyecto, lo comn es que la organizacin haga todo lo posible para encontrar fondos para ese ultimo 10%. Aun cuando el costo del proyecto sea rgido, es necesario estimar el costo de un conjunto dado de requerimientos y/o del diseo para asegurar que cumple con el costo acordado y, si no lo hace, cambiarlos y despus hacer la estimacin de nuevo. El proceso de estimar los costos (esto es, para capacidades, control de calidad y programacin fijas) con frecuencia comienza desde la concepcin del proyecto y continua aun despus de iniciada la codificacin. Cuando se inicia un proyecto, tal vez el equipo tenga solo una idea vaga de su costo. Si la estimacin del costo se puede posponer hasta que el proyecto tome forma, sin duda deben esperar, pero siempre existe la necesidad de estimar por lo menos un intervalo burdo a partir de un resumen de requerimientos. MODELOS DE ESTIMACION. El Modelo COCOMO. Boehm, introduce una jerarqua de modelos de estimacin de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos . La jerarqua de modelos de Boehm esta constituida por los siguientes: Modelo I. El Modelo COCOMO bsico calcula el esfuerzo y el costo del desarrollo de Sistema en funcin del tamao del sistema, expresado en las lneas estimadas.

Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de sistema en funcin del tamao del programa y de un conjunto de conductores de costos que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto. Modelo III. El modelo COCOMO avanzado incorpora todas las caractersticas de la versin intermedia y lleva a cabo una evaluacin del impacto de los conductores de costos en cada caso (anlisis, diseo, etc.) del proceso de ingeniera de Software.

5.9 Plan general del proyecto y planes de trabajo individuales.

Definir una red de tareas.

Las tareas y sub tareas individuales tienen interdependencias basadas en su secuencia. Adems, cuando hay ms de una persona implicada en un proyecto de ingeniera del software, es probable que las actividades de desarrollo y tareas se realicen en paralelo. Cuando ocurre esto, las tareas concurrentes deben coordinarse de manera que estn finalizadas cuando tareas posteriores requieran sus resultados. Una red de tareas, tambin llamada red de actividades, es una representacin grfica del flujo de tareas de un proyecto. Se emplea a veces como el mecanismo a travs del cual se introduce la secuencia de tareas y las dependencias en una herramienta de programacin automtica de la planificacin temporal de un proyecto. En su forma mas sencilla (la que se emplea en una planificacin temporal macroscpica), la red de tareas muestra las tareas principales de ingeniera del software. La siguiente figura muestra una red de tareas esquemticas para un proyecto de desarrollo de concepto.

Fig. 29. Una red de tareas para un proyecto de desarrollo de concepto.

5.10 Uso de herramientas de software para la planificacin.

Uso de herramientas CASE en los sistemas de informacin. Como sabemos una herramienta es cualquier dispositivo que nos ayuda a realizar una actividad o tarea en forma rpida y con menos esfuerzo usndola de la manera apropiada; imagnese lo difcil que seria clavar un clavo sin un martillo, o que un carpintero quisiera cortar una madera sin un serrucho. Al igual que pasa con el carpintero, en el desarrollo de proyectos de sistemas de informacin se necesita de herramientas para hacer las cosas de una forma rpida pero con la misma eficiencia, las herramientas CASE son "sistemas paquetes de software extensos y sofisticados con herramientas que ayudan a disear, desarrollar, administrar y mantener los proyectos de software". el termino CASE es por sus siglas en ingles, que significan herramientas para ingeniera de software asistido por computadora.

Las ventajas del uso de las herramientas CASE son demasiadas entre estas tenemos :

Aumento de la productividad.-Las herramientas CASE facilitan la interaccin entre los miembros del equipo al hacer la diagramacin un proceso dinmico e interactivo en vez de ser uno de los mas tediosos y en donde los cambios son problemticos y que, por lo tanto, tienden a convertirse en una perdida de productividad. Mejora de la comunicacin del analista-usuario.- Para que el sistema sea desarrollado con calidad es necesario una fuerte comunicacin entre los usuarios y el analista de sistemas durante el ciclo de vida de desarrollo de sistemas de informacin. El xito de una eventual implementacin del sistema depende de la comunicacin en forma significativa entre el usuario y el analista. Ahora los analistas que actualmente usan las nuevas herramientas CASE han experimentado que su uso promueve una mayor comunicacin entre el usuario y el analista de sistemas. Proporciona un medio de comunicacin.-Tanto los analistas como los usuarios han reportado que le uso de herramientas CASE proporciona un medio de comunicacin acerca del sistema durante su conceptualizacin. Integracin de las actividades del ciclo de vida.- La tercer razn del por que usar las herramientas CASE es la integracin de las actividades y la continuidad entre una fase y otra del ciclo de vida del desarrollo de sistemas de informacin. Evaluacin precisa de los cambios del mantenimiento.- La cuarta razn y sin duda la mas importante es la poder ver los cambios que se quisieran hacer al sistema de informacin y el impacto que esto causara, con esto los usuarios analizan y valoran el mantenimiento del sistema de informacin pudiendo ver los resultados de los cambios en el sistema antes de realizarlos.

Las herramientas CASE son clasificadas como CASE de nivel superior y CASE de nivel inferior. CASE de nivel superior.-Las herramientas CASE de nivel superior ayudan principalmente a analistas y diseadores. Una herramienta CASE de nivel superior permite que el analista cree y modifique el diseo del sistema. Toda la informacin acerca del proyecto es guardada en una enciclopedia llamada el deposito CASE. CASE de nivel inferior.- Estas herramientas ayudan principalmente a programadores. Las herramientas CASE de nivel inferior son usadas para generar cdigo fuente de la computadora, eliminando la necesidad de programar el sistema. La generacin de cdigo por medio de herramientas CASE inferior tiene ventajas:

El sistema se produce ms rpido. La cantidad de tiempo empleada en el mantenimiento disminuye con la generacin de cdigo. No hay necesidad de depurar, probar y modificar. El cdigo puede ser generado en ms de un lenguaje de computadora por lo que es mas fcil cambiar de sistema de plataforma usando el mismo depsito CASE. El cdigo generado esta libre de errores de programacin.