Universidad Tecnolgica Nacional

Facultad Regional Tucumn Carrera: Ingeniera en Sistemas de Informacin Asignatura: Anlisis de Sistemas Unidad n4
Comisin: 2K1 Profesor: Lic. Jorge Sueldo Grupo N: 3 Integrantes: Carrizo, Miguel Antonio Fassola, Jos Daniel Monteros, Alejandro Lucas Vera, Hctor Ao: 2009

Prefactibilidad

En este estudio se depuran con un alto grado de detalle los aspectos de consumo, tcnicos, financieros, institucionales, administrativos y ambientales. Acudiendo si es preciso a informacin primaria del proyecto ante alteraciones de las variables relevantes. Al terminar el estudio de prefactibilidad se espera, entonces, o mejorar el nivel de informacin para tomar una decisin mas ponderada y pasar al estudio de factibilidad, o proceder al diseo definitivo para ejecutarlo, o abandonar el proyecto de manera temporal o definitiva al no presentar ventajas comparativas que ameriten su ejecucin. Cabe anotar que el estudio de prefactibilidad conduce a seleccionar o escoger una nica alternativa que ser estudiada si se considera necesario, con mayor rigor en el nivel de factibilidad.

Estudio de la Prefactibilidad
En esta fase se examinan en detalles las alternativas consideradas ms convenientes, las que fueron determinadas en general en la fase anterior. Para la elaboracin del informe de prefactibilidad del proyecto deben analizarse en detalle los aspectos identificados en la fase de perfil, especialmente los que inciden en la factibilidad y rentabilidad de las posibles alternativas. Entre estos aspectos sobresalen: El mercado. La tecnologa. El tamao y la localizacin. Las condiciones de orden institucional y legal. Conviene plantear primero el anlisis en trminos puramente tcnica, para despus seguir con los econmicos. Ambos analizas permiten calificar las alternativas u opciones de proyectos y como consecuencia de ello, elegir la que resulte mas conveniente con relacin a las condiciones existentes.

Estudio de la Factibilidad
Esta ultima fase de aproximaciones sucesivas iniciadas en la preinversin, se bordan los mismos puntos de la prefactibilidad. Adems de profundizar el anlisis el estudio de las variables que inciden en el proyecto, se minimiza la variacin esperada de sus costos y beneficios. Para ello es primordial la participacin de especialistas, adems de disponer de informacin confiable. Sobre la base de las recomendaciones hechas en el informe de prefactibilidad, y que han sido incluidas en los trminos e referencia para el estudio de factibilidad, se deben definir aspectos tcnicos del proyecto, tales como localizacin, tamao, tecnologa, calendario de ejecucin y fecha de puesta en marcha. El estudio de factibilidad debe orientarse hacia el examen detallado y preciso de la alternativa que se ha considerado viable en la etapa anterior. Adems, debe afinar todos aquellos aspectos y variables que puedan mejorar el proyecto, de acuerdo con sus objetivos, sean sociables o de rentabilidad. Una vez que el proyecto ha sido caracterizado y definido deben ser optimizados. Por optimizacin se entiende la inclusin de todos los aspectos relacionados con la obra fsica, el programa de desembolsos de inversin, la organizacin por crear, puesta en marcha y operacin del proyecto. El analizas de la organizacin por crear para la implementacin del proyecto debe considerar el tamao de la obra fsica, la capacidad empresarial y financiera del inversionista, el nivel tcnico y administrativo que su operacin requiere las fuentes y los plazos para el financiamiento. Con la etapa de factibilidad finaliza el proceso de aproximaciones sucesivas en la formulacin y preparacin de proyectos, proceso en el cual tiene importancia significativa la secuencia de afinamiento y anlisis de la informacin. El informe de factibilidad es la

culminacin de la formulacin de un proyecto, y constituye la base de la decisin respecto de su ejecucin. Sirve a quienes promueven el proyecto, a las instituciones financieras, a los responsables de la implementacin econmica global, regional y sectorial.

Determinacin de la factibilidad.
Una vez que la cantidad de proyectos se ha acortado es necesario determinar si son factibles. Para los proyectos la factibilidad es valorada en tres formas principales: operacional, tcnica y econmicamente. El estudio de factibilidad no es un estudio de sistemas completos. Se usa para recopilar datos burdos para la administracin, para que a su vez les permitan tomar una decisin sobre si deben continuar con el estudio de sistema. Los datos para el estudio pueden ser recolectados por medios de entrevistas. El tipo de entrevista est directamente relacionada con el problema u oportunidad que est siendo sugerida. El analista de sistemas entreviste a aquellos que requieran ayuda y a los que estn directamente involucrados con el proceso de toma de decisiones. Aunque es importante atacar el problema adecuado no se debe estar mucho tiempo haciendo estudios de factibilidad, debido a que muchos proyectos sern solicitados y solamente unos cuantos debern ejecutados

Definicin de objetivos
La determinacin de factibilidad en general de un proyecto solicitado significa el encontrar cuales son los objetivos organizacionales y luego determinar si el proyecto sirve para mover el negocio hacia sus objetivos. Los objetivos del proyecto deben ser calificados por medio de entrevistas con la persona, grupo o departamento. Tambin es til una revisin de los trabajos escritos Hay varios objetivos para los proyectos pero no estn limitados a: -reducir errores y mejorar la precisin de la entrada de datos. -reducir el costo de la salida del sistema mediante la agilizacin y eliminacin de reportes duplicados o innecesarios. -integrar los subsistemas del negocio. -mejorar los servicios al cliente para ganar una posicin competitiva. - acelerar la entrada - acortar el tiempo de procesamiento de datos- automatizar los procedimientos manuales para mejorarlos en alguna forma. Tambin existen algunos objetivos inaceptables. Incluyen probar la destreza del equipo de analistas de sistemas, o simplemente afirmar la superioridad de un departamento. Tambin es inaceptable automatizar procedimientos manuales o invertir en tecnologa nueva debido al encaprichamiento, sin tomar en consideracin su contribucin verdadera. Los objetivos del proyecto necesitan ser puestos en claro formalmente en papel, as como informalmente platicando con las personas del negocio.

Determinacin de recursos

La determinacin de recursos para el estudio de factibilidad sigue el mismo patrn. Los recursos sern tratados en relacin con tres reas de factibilidad: tcnicas, econmicas y operacional.

Tcnicas de determinacin de factibilidad

Factibilidad Tcnica Es una medida del xito de la puesta en prctica de la solucin tcnica especfica y de la disponibilidad de los recursos y los conocimientos tcnicos necesarios. Es el anlisis tecnolgico de todos aquellos factores que justificaran la mejor combinacin de estos para determinar la viabilidad del proyecto Una gran parte de la determinacin de recursos tiene que ver con la valoracin de la factibilidad tcnica. El analista debe encontrar si los recursos tcnicos actuales pueden ser mejorados o aadidos en forma tal que satisfagan la peticin bajo consideracin. Algunas veces las adiciones a los sistemas existentes son costosas y no valen la pena, debido a que son ineficientes. Si los sistemas existentes no pueden ser aadidos, puede que la tecnologa en existencia satisfaga las especificaciones. Aqu es donde es benfica la experiencia del analista, debido a su propia experiencia y del contacto con los vendedores ser capaz de responder la pregunta de la factibilidad tcnica. Por lo general, si la respuesta sobre si una tecnologa particular se encuentra disponible y es capaz de satisfacer las peticiones del usuario es si entonces la pregunta se convierte en econmica. 1. 2. 3. 4. Eleccin del hardware Eleccin del software Eleccin del sistema de comunicaciones Eleccin de los recursos humanos Estrategia del hardware Establecer requerimientos globales Establecer la filosofa de procesamiento Definir arquitectura Pautar crecimiento para el mediano y largo plazo Pautar envergadura de procesamiento Definir grado de sofisticacin tcnica

Estrategia del software

 Definir disyuntiva: Desarrollo interno de sistemas vs. Adquisicin de paquetes Establecer criterios para fijar prioridades en el desarrollo e instalacin de sistemas Pautar desarrollo interno de sistemas Establecer pautas para el desarrollo de metodologas Pautar compra de software de base Establecer pautas para determinar dotacin afectada al desarrollo, instalacin y mantenimiento de sistemas Establecer requerimientos bsicos de documentacin de sistema Establecer requerimientos legales Estrategia de las Comunicaciones Establecer alcance del sistema Establecer los sistemas afectados Establecer los requerimientos globales Fijar pautas para la arquitectura de la red Estrategia de los RRHH Eleccin de los recursos Sus conocimientos La capitacin Su personalidad Equipos de trabajo de la organizacin Equipos de trabajo externos Trabajo en conjunto

Factibilidad Operativa Es una medida del correcto funcionamiento de una posible solucin a los problemas dentro de una organizacin. Tambin es una medida de los sentimientos que despierta un sistema o un proyecto en las personas que en l participan, o sea es la evaluacin del impacto del proyecto sobre la organizacin Miden la urgencia del problema Aceptabilidad de la solucin

Supongamos que se juzguen adecuados los recursos tcnicos y econmicos. El analista de sistemas deber considerar la factibilidad operacional del proyecto solicitado. La factibilidad operacional depende de los recursos humanos e involucra proyectar si el sistema operara y ser usado una vez que est instalado. Si los usuarios no ven problemas con el sistema presente, y no estn involucrados en la peticin de un nuevo sistema, la resistencia ante la implementacin del nuevo sistema ser fuerte. Las oportunidades de que alguna vez llegue a ser operacional son escasas.

Mucho del arte de la determinacin de la factibilidad operacional se encuentra en las interfaces de usuarios que se escogen. La determinacin de la factibilidad operacional requiere imaginacin creativa por parte del analista de sistema. As como su poder de persuasin, que permita que los usuarios sepan cuales interfaces son posibles y cuales satisfacern sus necesidades. Sin embargo con mucha frecuencia hay que practicar el arte de adivinar. Estudio de fact. Operativa Establecer el alcance de los cambios organizacionales Evaluar las normas, mtodos y funciones organizacionales vigentes. Evaluar el desarrollo organizativo alcanzado. Analizar las relaciones de poder actuales y futuras y su efecto sobre el proyecto. Trazar una hiptesis de conflictos potenciales. Definir roles y funciones. Establecer criterios para planificar la capacitacin del personal afectado. Estimar costos y beneficios operativos (Tangibles e intangibles)

Factibilidad Econmica Es una medida de la eficacia de los costos asociados a un proyecto o una solucin a menudo recibe el nombre de anlisis costo-beneficio El estudio de Factibilidad econmico-financiero es la herramienta imprescindible para conocer la totalidad de los gastos en que incurrir la Empresa al incorporar el nuevo sistema, como as tambin el incremento de los costos por cargas de estructura que demandar su funcionamiento luego de la implementacin. Los recursos bsicos a considerar son: el tiempo propio y el del equipo de sistema, el costo de hacer un estudio de sistema completo, el costo del tiempo de los empleados, el costo estimado del hardware y el costo estimado del software. El negocio de que se trate deber ser capaz de hacer ver el valor de la inversin en su ponderacin. Si los costos a corto plazo no son sobrepasados por las ganancias a largo plazo, o no producen una reduccin inmediata en los costos de operacin el sistema no es factible econmicamente y el proyecto ya no debe continuar. Estudio de fact. econmica

Costos complementarios al sistema Dotacin Mobiliario Instalacin elctrica Suministros Layout Sistema de Seguridad (fsica) Cursos de Capacitacin Seguro Fletes

etc. Costos incurridos en el estudio tcnico + Costos incurridos en el estudio operativo _________________________________ Costo total del proyecto Finalmente deberemos:

Analizar la inversin frente a la posicin financiera de la Empresa Establecer los beneficios totales (Incluyendo los intangibles) Analizar el retorno de la inversin (VAN Valor actualizado Neto, TIR Tasa Interna de Retorno)

Actividades de gestin de software

- Redaccin de la propuesta: la primera etapa implica redactar una propuesta para realizar ese proyecto. Esta describe los objetivos del proyecto y como se llevara a cabo. Incluye estimaciones de coste y tiempo y justifica por que el contrato del proyecto se le debe dar una organizacin o a un equipo en particular. - Planificacin y calendarizacin del proyecto: la planificacin refiere a la identificacin de actividades, hitos y entregas de un proyecto. Se debe bosquejar un plan para guiar el desarrollo hacia las metas del proyecto. La calendarizacin implica la creacin de varias representaciones graficas de partes del plan del proyecto, que constituyen una estimacin del tiempo de las actividades y de las dependencias entre ellas para llegar al objetivo final. - Estimacin de costes del proyecto: es una actividad relacionada con la estimacin e los recursos requeridos para llevar a cabo el plan del proyecto. - Supervisin y revisin del proyecto: la supervisin es una actividad continua. El gestor debe tener conocimiento del progreso del proyecto y comprar el progreso con los costes actuales y los planificados. Es normal tener varias revisiones formales de su gestin. Se hace la revisin completa del progreso y de los desarrollos tcnicos de proyecto, y se tiene en cuenta el estado de proyecto junto con los propsitos de la organizacin. La supervisin informal predice problemas importantes de proyecto y revela dificultades que pueden aparecer. Por ejemplo: las entrevistas diarias con el personal del proyecto pueden exteriorizar un problema en un fallo del software. - Seleccin y evaluacin del personal: los gestores tienen que seleccionar a las personas para trabajar en su proyecto, para establecer un equipo ideal

mnimo para el proyecto, dado que se pueden presentar las siguientes restricciones: 1- El presupuesto del proyecto no cubre la contratacin de personal con sueldos altos. Se tiene que contratar personal con menos experiencia y menor sueldo. 2- El personal con experiencia apropiada no esta disponible dentro o fuera de la organizacin. 3- La organizacin desea desarrollar las habilidades de sus empleados. - Redaccin y presentacin de informes: los gestores de proyecto son responsables de informar a los clientes y contratistas sobre el proyecto. Deben redactar documentos concisos y coherentes que resuman la informacin durante las revisiones de progreso. En consecuencia, comunicarse efectivamente de forma oral y escrita.

Planificacin del proyecto

La gestin efectiva depende de planificar completamente el progreso del proyecto. El gestor del proyecto debe anticiparse a los problemas que pueden surgir. Este plan inicial debe ser el mejor posible de acuerdo con la informacin disponible. Este evolucionara conforme el proyecto progrese y la informacin sea mejor. Adems de un plan de proyecto, los gestores tienen que preparar otros tipos de planes:
Plan Plan de calidad Plan de validacin Plan de gestin de configuraciones Plan de mantenimiento Plan de desarrollo del personal Descripcin Describe los procedimientos y los estndares de calidad que se utilizaran en un proyecto. Describe el enfoque, los recursos y la programacin utilizados para la validacin del sistema. Describe los procedimientos para la gestin de configuraciones y las estructuras a utilizar. Predice los requerimientos de mantenimiento del sistema, los costes del mantenimiento y el esfuerzo requerido. Describe como se desarrollan las habilidades y experiencia de los miembros del equipo del proyecto.

Pseudocdigo de proceso de planificacin del proyecto para el desarrollo de software: Establecer las restricciones del proyecto Hacer la valoracin inicial de los parmetros del proyecto Definir los hitos del proyecto y productos a entregar Mientras el proyecto no se haya completado o cancelado repetir

Bosquejar la programacin en el tiempo del proyecto Iniciar actividades acordes con la programacin Esperar (por un momento) Revisar el progreso del proyecto Revisar las estimaciones de los parmetros del proyecto Actualizar la programacin del proyecto Renegociar las restricciones del proyecto y los productos a entregar Si (surgen problemas) entonces Iniciar la revisin tcnica y la posible revisin fin de si fin de repetir Muestra que la planificacin es un proceso iterativo que solamente se completa cuando el proyecto mismo se termina. Las metas globales del negocio son un factor importante que debe considerarse cuando se formula el plan del proyecto. Conforme estas cambien, sern necesarios cambios en el proyecto. El proceso de planificacin inicia con una valoracin de las restricciones que afectan el proyecto (fecha de entrega, personal, presupuesto, etc.), junto con una estimacin de los parmetros del proyecto, como su estructura, tamao y distribucin de funciones. Luego se definen los hitos de progreso y productos a entregar. En ese momento el proceso entra en un ciclo. Se prepara un calendario para el proyecto y las actividades definidas en el calendario se inician o se continan. Despus de un tiempo de 2 o 3 semanas, se revisa el proyecto y se sealan las discrepancias. Dado que las estimaciones iniciales de los parmetros del proyecto son aproximaciones, el plan siempre deber actualizarse. Si el proyecto se retrasa, tienen que renegociar con el cliente las restricciones del mismo. Si no tiene xito y no se puede cumplir el calendario, se debe llevar a cabo una revisin tcnica. El objetivo de esta revisin es entrar un enfoque alternativo que se ajuste a las restricciones.

El plan del proyecto

El plan del proyecto fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo. Usualmente incluye las siguientes secciones: 1- Introduccin: Describe los objetivos y expone las restricciones. 2- Organizacin del proyecto: Describe la forma en que el equipo de desarrollo esta organizado, la gente involucrada y sus roles en el equipo.

3- Anlisis de riesgo: Describe los posibles riesgos del proyecto, la probabilidad de que surjan estos riesgos y las estrategias de reduccin de riesgos propuestas. 4- Requerimientos de recursos de hardware y software: Describe el hardware y el software de ayuda requeridos. Se deben incluir las estimaciones de los precios y las fechas de entrega. 5- Divisin del trabajo: Describe la divisin del proyecto en actividades e identifica los hitos y productos a entregar asociados con cada actividad. 6- Programa del proyecto: Describe las dependencias entre actividades, el tiempo estimado requerido para alcanzar cada hito y la asignacin de la gente a las actividades. 7- Mecanismos de supervisin e informe: Describe la gestin de informes y cuando deben producirse, as como los mecanismos de supervisin del proyecto a utilizar. El plan del proyecto debe revisarse regularmente durante el proyecto. Algunas partes, como el calendario del proyecto, cambiaran frecuentemente, otras sern mas estables.

Hitos y entregas
Cuando se planifica un proyecto se deben establecer una serie de hitos puntos finales de una actividad del proceso de software -. En cada uno, debe existir una salida formal, como un informe. Los informes deben ser cortos de los logros de una actividad del proyecto. Los hitos deben representar el fin de una etapa lgica en el proyecto. Una entrega es el resultado del proyecto que se entrega al cliente. Se entrega al final de una fase principal del proyecto como la especificacin, el diseo, etc. Como regla general, las entregas son hitos, pero estos no son necesariamente entregas, dado que pueden ser resultados internos del proyecto que son utilizados por el gestor del proyecto para verificar el progreso del mismo pero que no se entregan al cliente. Para establecer los hitos, el proceso del software debe dividirse en actividades bsicas con sus salidas asociadas.

Gestin de riesgos
Una tarea importante es anticipar los riesgos que podran afectar a la programacin del proyecto o la calidad del software a desarrollar y emprender las acciones para evitar esos riesgos. Los resultados del anlisis se deben documentar a lo largo del plan del proyecto junto con el anlisis de consecuencias cuando el riesgo ocurra. Se puede concebir riesgo como una probabilidad de que una circunstancia adversa ocurra. Los riesgos son una amenaza para el proyecto. Estas categoras de riesgos de definen como: 1- Riesgos de proyecto: afectan la calendarizacin o los recurso del proyecto (ej: la prdida de un diseador experimentado). 2- Riesgos del producto: afectan la calidad o rendimiento del software que se esta desarrollando (Ej.: el rendimiento en un componente que hemos comprado sea menor que el esperado). 3- Riesgos de negocio: afectan a la organizacin que desarrolla o suministra el software (ej: un competidor introduce un nuevo producto es un riesgo de negocio). Estos tipos de riesgo no son exclusivos entre si, Si un programador experto abandona el proyecto, esto es un riesgo para el proyecto (debido a que la entrega del sistema se puede retrasar), para el producto (debido a que un sustituto puede no ser tan experto y cometer muchos errores) y para el negocio (debido a que esa experiencia puede no contribuir a negocios futuros). Los riesgos dependen del proyecto en si y del entorno. Sin embargo muchos riesgos son universales como:

Riesgo Rotacin de personal Cambio de gestin No disponibilidad del hardware Cambio de requerimientos Retrasos en la especificacin Subestimacin del tamao Bajo rendimiento de la herramienta CASE Cambio de tecnologa Competencia del producto

Tipo Proyecto Proyecto Proyecto Proyecto y producto Proyecto y producto Proyecto y producto Producto Negocio Negocio

Descripcin Personal con experiencia abandona el proyecto antes de que finalice Habr un cambio de gestin organizacional con diferentes prioridades. El hardware esencial para el proyecto no ser entregado a tiempo. Habr ms cambios en los requerimientos de lo esperado. Las especificaciones de las interfaces esenciales no estarn a tiempo. El tamao del sistema se ha subestimado. Las herramientas CASE que ayudan al proyecto no tienen el rendimiento esperando. Un producto competitivo se pone en venta antes de que el sistema se complete. La tecnologa fundamental sobre la que se construir el sistema se sustituye por nueva tecnologa.

Es preciso anticiparse a los riesgos: comprender el impacto de estos en el proyecto, en el producto y en el negocio, y considerar los pasos para evitarlos. Se deben crear planes de contingencia para que sea posible aplicar acciones de recuperacin.

Calendarizacin del proyecto

Los gestores deben estimar el tiempo y los recursos requeridos para completar las actividades y organizarlas en una sucesin coherente. Las estimaciones previas son una base incierta para la calendarizacin del proyecto. La estimacin se complica aun ms por el hecho de que proyectos diferentes pueden utilizar mtodos de diseo y lenguajes de implementacin diferentes. Si el proyecto es tcnicamente complejo, las estimaciones iniciales casi siempre son optimistas aun cuando los gestores traten de considerar eventualidades. Por lo tanto, los calendarios se deben actualizar continuamente en la medida que se disponga de mejor informacin acerca del progreso. La calendarizacin implica todo el trabajo de un proyecto en actividades complementarias y considerar el tiempo requerido para completar dichas actividades. Por lo general, algunas de estas se llevan a cabo en paralelo.

Debemos coordinar y organizar el trabajo para que la mano de obra se utilice de forma optima. Normalmente las actividades deben durar por lo menos una semana. Tambin es til asignar una cantidad de tiempo mxima de 8 a 10 semanas APRA realizar cualquier actividad. Si lleva ms tiempo, se deben hacer subdivisiones. Al estimar la calendarizacin los gestores deben suponer que cada etapa no estar libre de problemas. Las personas que trabajan en el pueden enfermarse o renunciar, el hardware puede fallar y el software o hardware de soporte puede llegar tarde. Se debe estimar los recursos necesarios para completar cada tarea como el esfuerzo humano, el espacio en disco requerido en un servidor, el tiempo requerido de hardware especializado, un simulador o el presupuesto para viajes del personal, etc. Como regla para los problemas previstos siempre debe agregarse un 30% a la estimacin original y otro 20% para cubrir algunas cosas no previstas. El calendario del proyecto se representa como un conjunto de grficos que muestran la divisin del trabajo, las dependencias de las actividades y la asignacin del personal. Grficos de barras y redes de actividades:

Los grficos de barras y redes de actividades son notaciones graficas que se utilizan para ilustrar la calendarizacin del proyecto. Los grficos de barras muestran quien es responsable de cada actividad y cuando debe comenzar y finalizar sta. Las redes de actividades muestran las dependencias entre las diferentes actividades que conforman un proyecto. Estos se generan automticamente a partir de una base de datos de la informacin del proyecto utilizando una herramienta de gestin de proyectos.

Duracin y dependencias de las tareas

Tareas T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duracin (das) 8 15 15 10 10 5 20 25 15 15 7 10 Dependencias

T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)

Esta tabla recoge las tareas, la duracin e interdependencias de estas. En ella se observa que T3 depende de la tarea T1. Esto significa que T1 debe completarse antes de que comience T3. Por ejemplo T1 podra ser la preparacin de un diseo de un componente y T3 la implementacin de ese diseo. Antes de que se inicie la implementacin, el diseo debe estar terminado. Todas las actividades deben terminar en hitos. Una comienza cuando su hito precedente se ha alcanzado. Por lo tanto en la tercera columna se muestra que el hito correspondiente (M5), que se alcanza cuando las tareas en esa columna terminan.

Red de actividades

Una red de actividades muestra la sucesin de actividades que deben generarse. Muestra que actividades se llevan a cabo en paralelo y cuales deben ejecutarse en secuencia debido a la dependencia con una actividad previa. Las actividades se representan como rectngulos; los hitos y las entregas se muestran con esquinas redondeadas. Las fechas, muestra la fecha de inicio de las actividades. La red se debe leer de izquierda a derecha y de arriba abajo. Antes de que se pueda pasar de un hito a otro, todas las trayectorias deben completarse. Por ejemplo T9, no se puede iniciar hasta que las tareas T3 y T6 se terminen. El tiempo mnimo requerido para finalizar el proyecto se estima teniendo en cuenta la trayectoria ms larga en la red de actividades (el camino crtico). En este caso es 55 das laborales de tiempo transcurrido. El camino crtico se muestra como una sucesin de rectngulos mas resaltados. El calendario del proyecto depende de dicho camino. Cualquier aplazamiento al completar una actividad crtica provoca retraso en el proyecto, ya que las actividades siguientes no pueden comenzar hasta que se finalice la actividad retrasada. Los retrasos de las actividades que no estn ligadas al camino critico no provocan necesariamente un aplazamiento en todo el calendario, mientras estos no se propaguen a estas actividades. Tambin se utilizan estas redes para asignar los trabajos en el proyecto ya que pueden dar una percepcin de la dependencia de las actividades que de forma intuitiva no son obvias. A medida que el proyecto se desarrolla, las estimaciones deben ser comparadas con los tiempos reales. Esta comparacin puede ser utilizada como base para una revisin de la agenda de las siguientes partes del proyecto.

Grafico de barras

El grafico de barras es una forma alternativa de representar la informacin del calendario del proyecto. Es un grafico de barras (grafo de Gantt) que muestra el calendario de un proyecto y las fechas iniciales y finales de las actividades. Algunas de las actividades son seguidas por una barra sombreada cuya longitud es calculada por una herramienta de calendarizacin. Esto muestra que existe alguna flexibilidad en las fechas de terminacin de estas actividades. Si alguna de estas no se completa a tiempo, el camino critico no se vera afectado hasta el final del periodo marcado por la barra sombreada. Las actividades que caen sobre dicho camino no tienen margen de error y se distinguen por no tener asociada una barra sombreada.

Bibliografa Cap. 5 Ingeniera del Software de Ian SommervilleCap. 2 Anlisis y diseo de sistemas de Kendall y Kendall. Cap. 1 Gestin de Proyecto de Juan Jos Miranda. Monografas.com