Gestión y Administración de proyectos

Transcripción

1 Gestión y Administración de proyectos Proyecto: esfuerzo temporal que se lleva a cabo para crear un producto, un servicio o una obra. 1. Cada proyecto tiene un comienzo definido y un final definido 2. La duración de un proyecto es limitada aunque sea de años 3. Temporal NO es aplicable generalmente al producto, servicio o resultado creado por el proyecto Un proyecto crea entregables únicos 1. Servicio consultoría 2. Producto sistema 3. Resultado mejora / eficiencia de procesos La singularidad es una característica importante de los productos entregables de un proyecto. La presencia de elementos repetitivos NO cambia la condición fundamental de único del trabajo de un proyecto. Proyectos vs Trabajos Operativos Proyectos Operaciones Similitudes Realizados por personas Limitación de Recursos Planificados Ejecutados - Controlados Diferencias Temporales Continuas Únicos Repetitivas Graduales Finalidad Alcanzar el objetivo Respaldo al negocio Finalización Concluye al alcanzar Adoptan nuevos su objetivo objetivos No concluyen Cuándo un Proyecto es Exitoso? 1. Cuándo cumplimos en tiempo, sin pasar el presupuesto y entregando lo pedido? 2. Cuándo el cliente nos llama nuevamente? 3. Cuándo el próximo proyecto lo hacemos mejor? 4. Cuándo el cliente está satisfecho? 5. Cuándo el cliente paga? 6. Cuándo hay brindis final? 7. Cuándo? Por qué no terminan bien los Proyectos? 1. Falta de sponsor 2. "Reinventamos la rueda" en cada proyecto 3. Objetivos poco claros o contradictorios 4. Planificación defectuosa, estimaciones incorrectas 5. Contar con muchas expectativas y pocas necesidades 6. Comunicaciones deficientes, comunicadores inexpertos 7. Cambios permanentes en las especificaciones Analisis y Diseño I APU 2008 Página 1

2 8. Pobre administración de los recursos y de los proveedores 9. Nuevas tecnologías 10. Cultura de la organización 11. Dificultades para cerrar los proyectos Qué tiene un proyecto exitoso? En Teoría Un proyecto se considera exitoso los plazos estipulados, dentro de especificaciones requeridas. En la Práctica 1. Excelente comunicación 2. Liderazgo, conocimiento y poder 3. Sigue una metodología probada 4. Mostrar resultados, dar calidad 5. Validar las estimaciones 6. Más y mejor conocimientos y experiencias 7. Hace ganar dinero Stakeholders: Son los individuos y organizaciones activamente involucrados en el proyecto; o cuyos intereses pueden ser positiva o negativamente afectados como resultado de la ejecución del proyecto. Analisis y Diseño I APU 2008 Página 2

3 Gestión de proyectos: organización y administración de los recursos que intervienen en un proyecto de manera tal que éste se pueda culminar dentro del alcance, del tiempo y del coste definido. Analisis y Diseño I APU 2008 Página 3

4 Entendamos Gestión de Proyectos como la planificación, el seguimiento y el control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de cualquier proyecto (realizar un sitio web, organizar un evento, crear una biblioteca, etc.) Conceptos relacionados con gestión de proyectos EDT (Estructura de descomposición del trabajo) Work Breakdown Structure o WBS, es una estructura exhaustiva, jerárquica y descendente formada por las diferentes tareas (unidades de trabajo) a realizar en un proyecto. El diagrama de Gantt, gráfica de Gantt o carta Gantt es una herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. Analisis y Diseño I APU 2008 Página 4

5 Flujo de trabajo Workflow, es el estudio de los aspectos de desarrollo de un proyecto: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas. Se pueden distinguir tres tipos de actividad: 1. Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado común. Tiene entidad el trabajo de cada uno de ellos en sí mismo. 2. Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto particular, estableciendo los mecanismos de cooperación entre ellos. No tiene entidad el trabajo de ninguno de ellos si no es visto desde el punto de vista global del resultado final. 3. Actividades de coordinación. Analisis y Diseño I APU 2008 Página 5

6 Program Evaluation and Review Technique, PERT, es básicamente un método para analizar las tareas involucradas en completar un proyecto dado, especialmente el tiempo para completar cada tarea, e identificar el tiempo mínimo necesario para completar el proyecto total. Método de la ruta crítica, Critical Path Method, CPM. Una ruta crítica es la secuencia de las tareas de un proyecto con la mayor duración entre ellos, lo cual determina el tiempo más corto en el que es posible completar el proyecto. La duración de la ruta crítica determina la duración del proyecto entero. Cualquier retraso en un elemento de la ruta crítica afecta a la fecha de término planeada del proyecto, y se dice que no hay holgura en la ruta crítica. A diferencia del método PERT, el método de la ruta crítica usa tiempos ciertos (reales o determinísticos). Sin embargo, la elaboración de un proyecto en base a redes CPM y PERT son similares y consisten en: 1. Identificar todas las actividades que involucra el proyecto, lo que significa, determinar relaciones de precedencia, tiempos técnicos para cada una de las actividades. 2. Construir una red con base en nodos y actividades (o arcos, según el método más usado), que implican el proyecto. 3. Analizar los cálculos específicos, identificando las rutas críticas y las holguras de los proyectos. Diagrama de Gantt Los cronogramas de barras o gráficos de Gantt fueron concebidos por el ingeniero norteamericano Henry L. Gantt, uno de los precursores de la ingeniería industrial contemporánea de Taylor. Gantt procuro resolver el problema de la programación de actividades, es decir, su distribución conforme a un calendario, de manera tal que se pudiese visualizar el periodo de duración de cada actividad, sus fechas de iniciación y terminación e igualmente el tiempo total requerido para la ejecución de un trabajo. El instrumento que desarrolló permite también que se siga el curso de cada actividad, al proporcionar información del porcentaje ejecutado de cada una de ellas, así como el grado de adelanto o atraso con respecto al plazo previsto. Este gráfico consiste simplemente en un sistema de coordenadas en que se indica: En el eje Horizontal: un calendario, o escala de tiempo definido en términos de la unidad más adecuada al trabajo que se va a ejecutar: hora, día, semana, mes, etc. En el eje Vertical: Las actividades que constituyen el trabajo a ejecutar. A cada actividad se hace corresponder una línea horizontal cuya longitud es proporcional a su duración en la cual la medición efectúa con relación a la escala definida en el eje horizontal conforme se ilustra. Símbolos Convencionales: En la elaboración del gráfico de Gantt se acostumbra utilizar determinados símbolos, aunque pueden diseñarse muchos otros para atender las necesidades específicas del usuario. Los símbolos básicos son los siguientes: 1. Iniciación de una actividad. 2. Término de una actividad 3. Línea fina que conecta las dos L invertidas. Indica la duración prevista de la actividad. Analisis y Diseño I APU 2008 Página 6

7 4. Línea gruesa. Indica la fracción ya realizada de la actividad, en términos de porcentaje. Debe trazarse debajo de la línea fina que representa el plazo previsto. 5. Plazo durante el cual no puede realizarse la actividad. Corresponde al tiempo improductivo puede anotarse encima del símbolo utilizando una abreviatura. 6. Indica la fecha en que se procedió a la última actualización del gráfico, es decir, en que se hizo la comparación entre las actividades previstas y las efectivamente realizadas. Contenido El diagrama de Gantt consiste en una representación gráfica sobre dos ejes; en el vertical se disponen las tareas del proyecto y en el horizontal se representa el tiempo. Características 1. Cada actividad se representa mediante un bloque rectangular cuya longitud indica su duración; la altura carece de significado. 2. La posición de cada bloque en el diagrama indica los instantes de inicio y finalización de las tareas a que corresponden. 3. Los bloques correspondientes a tareas del camino crítico acostumbran a rellenarse en otro color (en el caso del ejemplo, en rojo). Construir un diagrama de Gantt: 1. Dibujar los ejes horizontal y vertical. 2. Escribir los nombres de las tareas sobre el eje vertical. 3. En primer lugar se dibujan los bloques correspondientes a las tareas que no tienen predecesoras. 4. Se sitúan de manera que el lado izquierdo de los bloques coincida con el instante cero del proyecto (su inicio). 5. A continuación, se dibujan el bloque correspondiente a las tareas que sólo dependen de las tareas ya introducidas en el diagrama. Se repite este punto hasta haber dibujado todas las tareas. En este proceso se han de tener en cuenta las consideraciones siguientes: 6. Las dependencias fin-inicio se representan alineando el final del bloque de la tarea predecesora con el inicio del bloque de la tarea dependiente. 7. Las dependencias final-final se representan alineando los finales de los bloques de las tareas predecesora y dependiente. 8. Las dependencias inicio-inicio se representan alineando los inicios de los bloques de las tareas predecesora y dependiente. Analisis y Diseño I APU 2008 Página 7

8 9. Los retardos se representan desplazando la tarea dependiente hacia la derecha en el caso de retardos positivos y hacia la izquierda en el caso de retardos negativos. Ejemplo Finalmente, una vez realizados los cálculos del proyecto utilizando un sistema adecuado, como el diagrama PERT o el Roy, resulta conveniente destacar con un color distinto las tareas con margen total 0, para poder identificar con facilidad los caminos críticos. VENTAJAS Y DESVENTAJAS DE LOS GRÁFICOS DE GANTT. La ventaja principal del gráfico de Gantt radica en que su trazado requiere un nivel mínimo de planificación. Los gráficos de Gantt se revelan muy eficaces en las etapas iniciales de la planificación. Sin embargo, después de iniciada la ejecución de la actividad y cuando comienza a efectuarse modificaciones, el gráfico tiende a volverse confuso. Por eso se utiliza mucho la representación gráfica del plan, en tanto que los ajustes (re planificación) requieren por lo general de la formulación de un nuevo gráfico. Para superar esa deficiencia se crearon dispositivos mecánicos, tales como cuadros magnéticos, fichas, cuerdas, etc., que permite una mayor flexibilidad en las actualizaciones. Aún en términos de planificación, existe todavía una limitación bastante grande en lo que se refiere a la representación de planes de cierta complejidad. El Gráfico de Gantt no ofrece condiciones para el análisis de opciones, ni toma en cuenta factores como el costo. Es fundamentalmente una técnica de pruebas y errores. No permite, tampoco, la visualización de la relación entre las actividades cuando el número de éstas es grande. En resumen, para la planificación de actividades relativamente simples, el gráfico de Gantt representa un instrumento de bajo costo y extrema simplicidad en su utilización. Para proyectos complejos, sus limitaciones son bastantes serias, y fueron éstas las que llevaron a ensayos que dieron como resultado el desarrollo del CPM, el PERT y otras técnicas conexas. Estas técnicas introdujeron nuevos conceptos que, asociados más tarde a los de los gráficos de Gantt, dieron origen a las denominadas redes-cronogramas. Gráfico de Gantt para seguir la marcha de las actividades: En este tipo de gráfico se usa el eje vertical para representar actividades, en tanto que los recursos aplicados a cada uno indican, por medio de claves, sobre la línea que representan la duración de la actividad. Consiste, por lo tanto, en una inversión del caso anterior. El eje horizontal permanece como registro de escala de tiempo. Gráfico de Gantt para el control de la carga de trabajo: Este gráfico es semejante al de la distribución de actividad que tiene por objeto proporcionar el administrador una posición de carga total de trabajo aplicada a cada recurso. Indica Analisis y Diseño I APU 2008 Página 8

9 el periodo durante el cual el recurso estará disponible para el trabajo (representado por una línea fina) y la carga total de trabajo asignada a este recurso (representado por una línea gruesa). PERT Y CPM Un diagrama de red es cualquiera de las representaciones que vinculan las actividades y los eventos de un proyecto entre sí para reflejar las interdependencias entre las mismas. Una actividad o evento puede presentar interdependencias con actividades o eventos sucesores, predecesores, o en paralelo. Los más importantes son: PERT (Program Evaluation and Review Technique). Desarrollado por la Special Projects Office de la Armada de EE.UU. a finales de los 50s para el programa de I+D que condujo a la construcción de los misiles balísticos Polaris. Está orientada a los sucesos o eventos, y se ha utilizado típicamente en proyectos de I+D en los que el tiempo de duración de las actividades es una incertidumbre. Dado que las estimaciones de duración comportan incertidumbre se estudian las distribuciones de probabilidad de las duraciones. Con un diagrama PERT se obtiene un conocimiento preciso de la secuencia necesaria, o planificada para la ejecución de cada actividad y utilización de diagramas de red. Se trata de un método muy orientado al plazo de ejecución, con poca consideración hacia al coste. Se suponen tres duraciones para cada suceso, la optimista a, la pesimista b y la normal m; suponiendo una distribución beta, la duración más probable: t = (a + 4m + b) / 6. Generalmente se denominan técnicas PERT al conjunto de modelos abstractos para la programación y análisis de proyectos de ingeniería. Estas técnicas nos ayudan a programar un proyecto con el coste mínimo y la duración más adecuada. Están especialmente difundidas el PERT y el CPM. Aplicación de las técnicas PERT: 1. Determinar las actividades necesarias y cuando lo son. 2. Buscar el plazo mínimo de ejecución del proyecto. 3. Buscar las ligaduras temporales entre actividades del proyecto. 4. Identificar las actividades críticas, es decir, aquellas cuyo retraso en la ejecución supone un retraso del proyecto completo. 5. Identificar el camino crítico, que es aquel formado por la secuencia de actividades críticas del proyecto. 6. Detectar y cuantificar las holguras de las actividades no críticas, es decir, el tiempo que pueden retrasarse (en su comienzo o finalización) sin que el proyecto se vea retrasado por ello. 7. Si se está fuera de tiempo durante la ejecución del proyecto, señala las actividades que hay que forzar. 8. Nos da un proyecto de coste mínimo. Camino crítico El camino crítico en un proyecto es la sucesión de actividades que dan lugar al máximo tiempo acumulativo. Analisis y Diseño I APU 2008 Página 9

10 Determina el tiempo más corto que podemos tardar en hacer el proyecto si se dispone de todos los recursos necesarios. Es necesario conocer la duración de las actividades. Este concepto es utilizado por dos métodos: Método del tiempo estimado (CPM) La duración de una actividad es la más probable de duración. Tiempo que se emplearía en condiciones normales (m). Situación determinista. Método del tiempo esperado (PERT) Determinación probabilística de los tiempos esperados (Te), en función de los siguientes tiempos: 1. Duración más corta (a) 2. Duración más larga (b) 3. Duración más probable (m) (el mismo que en CPM) 4. Duración esperada: Te = (a + 4m + b) / 6. Principios Estos tres principios deben respetarse siempre a la hora de dibujar una malla PERT: 1. Principio de designación sucesiva: se nombra a los vértices según los números naturales, de manera que no se les asigna número hasta que han sido nombrados todos aquellos de los que parten aristas que van a parar a ellos. 2. Principio de unicidad del estado inicial y el final: se prohíbe la existencia de más de un vértice inicial o final. Sólo existe una situación de inicio y otra de terminación del proyecto. 3. Principio de designación unívoca: no pueden existir dos aristas que tengan los mismos nodos de origen y de destino. Normalmente, se nombran las actividades mediante el par de vértices que unen. Si no se respetara este principio, puede que dos aristas recibieran la misma denominación Dibujo de una malla PERT Existen dos metodologías aceptadas para dibujar una malla PERT, la de Actividad en el Arco y las de Actividad en el Nodo, siendo ésta última la más utilizada en la actualidad en atención a que es la que usan la mayoría de las aplicaciones computacionales especialistas en este tema. Red PERT. Cada nodo contiene la siguiente información sobre la actividad: Nombre de la actividad Duración esperada de la actividad (t) Tiempo de inicio más temprano (ES = Earliest Start) Tiempo de término más temprano (EF = Earliest Finish) Tiempo de inicio más tardío (LS = Latest Start) Tiempo de término más tardío (LF = Latest Finish) Holgura de la Actividad (H) Analisis y Diseño I APU 2008 Página 10

11 Por convención los arcos se dibujan siempre con orientación hacia la derecha, hacia el nodo de término del proyecto, nunca retrocediendo. El dibujo de una malla PERT se comienza en el nodo de inicio del proyecto. A partir de él se dibujan las actividades que no tienen actividades precedentes, o sea, aquellas que no tienen que esperar que otras actividades terminen para poder ellas iniciarse. A continuación, se dibujan las restantes actividades cuidando de respetar la precedencia entre ellas. Al terminar el dibujo de la malla preliminar, existirán varios nodos ciegos, nodos terminales a los que llegan aquellas actividades que no son predecesoras de ninguna otra, es decir aquellas que no influyen en la fecha de inicio de ninguna otra, éstas son las actividades terminales y concurren por lo tanto al nodo de término del proyecto. para esto no es necesario utilizarlo Cálculo de los tiempos de inicio y término más tardíos El tiempo de inicio más tardío LS (Latest Start) y de término más tardío LF (Latest finish) para cada actividad del proyecto, se calculan desde el nodo de término retrocediendo hacia el nodo de inicio del proyecto según la siguiente relación: Donde (t) es el tiempo esperado de duración de la actividad y donde LF queda definida según la siguiente regla: Regla del tiempo de término más tardío: El tiempo de término más tardío, LF, de una actividad específica, es igual al menor de los tiempos LS de todas las actividades que comienzan exactamente después de ella. El tiempo de término más tardío de las actividades que terminan en el nodo de término del proyecto es igual a la duración esperada del proyecto (T). Holguras, actividades críticas y rutas críticas La Holgura de una actividad, es el tiempo que tiene ésta disponible para, ya sea, atrasarse en su fecha de inicio, o bien alargarse en su tiempo esperado de ejecución, sin que ello provoque retraso alguno en la fecha de término del proyecto. La holgura de una actividad se calcula de la siguiente forma: Analisis y Diseño I APU 2008 Página 11

12 H = LF EF o bien H = LS ES Actividades críticas Se denomina actividades críticas a aquellas actividades cuya holgura es nula y que por lo tanto, si se retrasan en su fecha de inicio o se alargan en su ejecución más allá de su duración esperada, provocarán un retraso exactamente igual en tiempo en la fecha de término del proyecto. Rutas críticas Se denomina rutas críticas a los caminos continuos entre el nodo de inicio y el nodo de término del proyecto, cuyos arcos componentes son todas actividades críticas. Las rutas críticas se nombran por la secuencia de actividades críticas que la componen o bien por la secuencia de nodos por los que atraviesa. Nótese que un proyecto puede tener más de una ruta crítica pero a lo menos tendrá siempre una. Otras consideraciones: Se llama evento al momento de iniciación o terminación de una actividad. Se determina en un tiempo variable entre el más temprano y el más tardío posible, de iniciación o de terminación. A los eventos se les conoce también con los nombres de nodos. i j El evento inicial se llama i y el evento final se denomina j. El evento final de una actividad será el evento inicial de la actividad siguiente. Las flechas no son vectores, escalares ni representan medida alguna. No interesa la forma de las flechas, ya que se dibujarán de acuerdo con las necesidades y comodidad de presentación de la red. Pueden ser horizontales, verticales, ascendentes, descendentes curvas, rectas, quebradas, etc. En los casos en que haya necesidad de indicar que una actividad tiene una interrelación o continuación con otra se dibujará entre ambas una línea punteada, llamada liga, que tiene una duración de cero La liga puede representar en algunas ocasiones un tiempo de espera para poder iniciar la actividad siguiente Varias actividades pueden terminar en un evento o partir de un mismo evento. Al construir la red, debe evitarse lo siguiente: 1. Dos actividades que parten de un mismo evento y llegan a un mismo evento. Esto produce confusión de tiempo y de continuidad. Debe abrirse el evento inicial o el evento final en dos eventos y unirlos con una liga. 2. Partir una actividad de una parte intermedia de otra actividad. Toda actividad debe empezar invariablemente en un evento y terminar en otro. Cuando se presenta este caso, a la actividad base o inicial se le divide en eventos basándose en porcentajes y se derivan de ellos las actividades secundadas. 3. Dejar eventos sueltos al terminar la red. Todos ellos deben relacionarse con el evento inicial o con el evento final. Analisis y Diseño I APU 2008 Página 12

13 Introducción La gestión de un proyecto informático Lo que ahora queda por ver de la gestión de un proyecto informático no es en absoluto tan diferente de lo que es habitual en la gestión de cualquier otro proyecto de ingeniería, sobre todo si se recuerda, a la hora detonar las decisiones imprescindibles de gestión del proyecto, que cuando se habla de personas mes para considerar el esfuerzo, no se puede en absoluto pensar en intercambiar los dos factores. Una vez se ha llevado a cabo la primera estimación de costes, a menudo, a partir de una primera especificación genérica del alcance del proyecto muy precaria, es necesario finalizar la etapa de calificación y planificar en el tiempo las diferentes tareas pendientes y, cuando ya se ha iniciado el proceso de desarrollo del proyecto, sólo se debe realizar el seguimiento y el control. En este módulo, repasamos brevemente los problemas generales de la planificación temporal de actividades, con la mención de temas clásicos como los diagramas PERT o el método del camino crítico (CPM), sin olvidar hacer una referencia inevitable a las diferentes herramientas informáticas disponibles que pueden ayudar en esta actividad de planificación. A partir de la planificación de actividades, es mucho más sencillo ordenar el proceso de control del proyecto y el seguimiento de su desarrollo para llegar a finalizar con éxito la actividad de construir un Software de aplicación en la informática de gestión. Una vez revisadas brevemente las actividades típicas de gestión de proyectos (planificación, seguimiento y control), al final de este módulo planteamos, de manera básica e introductoria, el problema del aseguramiento de la calidad del software ( software quality assurance), que ha llegado a alcanzar una gran importancia en los últimos años, posiblemente por la falta de calidad y fiabilidad de la mayoría del software construido. Objetivos Se cierra el estudio de la gestión de un proyecto informático de construcción de software de aplicación en la informática de gestión. Se tratan los temas de la planificación temporal de actividades y, a partir de esta planificación, del seguimiento y el control del desarrollo del proyecto. Termina con una referencia breve al problema del aseguramiento de la calidad del software. Con el estudio de este módulo y de los materiales didácticos asociados, el estudiante debe alcanzar los objetivos siguientes: 1. Conocer la problemática general de la planificación temporal de proyectos, el uso de diagramas de Gantt, la técnica del PERT y el método del camino crítico (CPM). 2. Saber planificar en el tiempo las actividades de un proyecto informático, teniendo en cuenta los recursos disponibles y las limitaciones de uso. 3. Conocer los problemas que se plantean y los documentos que se suelen utilizar para controlar el desarrollo de un proyecto y realizar un seguimiento completo y exhaustivo. Analisis y Diseño I APU 2008 Página 13

14 4. Saber cuáles son las decisiones más habituales que se han de tomar en el proceso de control de un proyecto informático y los aspectos que más las condicionan. 5. Conocer las herramientas informáticas que ayudan tanto en el proceso de planificación del proyecto, como en el de seguimiento y control de una planificación ya efectuada. 6. Obtener una visión inicial de los problemas de aseguramiento de la calidad del Software (software quality assurance ) y, en definitiva, de la dificultad de obtener Software seguro, fiable y de calidad Planificación en el tiempo de los proyectos informáticos Una vez determinada la voluntad de iniciar un proyecto informático, las etapas que caracterizan la gestión son dos: la primera es la calificación inicial (estimación de costes y planificación temporal) y la segunda es el desarrollo (seguimiento y control del proyecto, tal vez acompañados de nuevas estimaciones y planificaciones) para llegar, de una manera o de otra, con éxito o sin él, al final o cierre definitivo del proyecto. Una vez conocida la amplia problemática de la estimación de costes, ahora planificaremos en el tiempo las diferentes tareas o actividades de las que consta el proyecto. Cabe mencionar que la planificación temporal de proyectos a partir de su descomposición en tareas (WBS) y la estimación de la duración de cada una es un proceso suficientemente conocido y que los proyectos informáticos de construcción de software comparten con muchos otros proyectos de ingeniería. Por otra parte, como veremos, salvo una particular manera de tener en cuenta los recursos (las personas que forman el equipo del proyecto), no se dan diferencias esenciales con otros proyectos de ingeniería. Comenzamos con la exposición breve y sintética de conceptos tradicionales de la planificación temporal de actividades como la técnica del PERT y el método del camino crítico (CPM) y después analizamos el caso general de la planificación temporal de proyectos informáticos. La técnica del PERT y el método del camino crítico El fundamento central de las técnicas del PERT es la representación gráfica del proyecto en un diagrama que muestre las relaciones y, sobre todo, las precedencias entre las tareas que constituyen el proyecto. Este diagrama, que algunos denominan diagrama PERT, en el fondo no es más que un grafo de precedencias de actividades que a menudo se llama red de actividades (activity network) o, también, diagrama de precedencias A menudo, los dos métodos se pueden tratar conjuntamente, tal como haremos en esta exposición simplificada. Conviene advertir que, aunque aquí se habla de tareas o actividades indistintamente, a menudo la nomenclatura más habitual utiliza el término actividades cuando se refiere a PERT, aunque actualmente la elección suele depender de la manera como se haya traducido el concepto en la herramienta informática de la que nos ayudamos a la hora de llevar a cabo la planificación de un proyecto. El conjunto de las técnicas PERT y el método del camino crítico (CPM) proporcionan herramientas cuantitativas que permiten determinar lo siguiente: 1. El camino crítico del proyecto, que es la secuencia o cadena de actividades que determina la duración total del proyecto. Analisis y Diseño I APU 2008 Página 14

15 2. Las estimaciones de tiempos más probables, tanto para la totalidad del proyecto como para el inicio y el final de cada una de las tareas o actividades individuales. 3. Los márgenes de tiempo que se dan para cada tarea o actividad individual y que no impliquen un retraso del proyecto. Pongamos un ejemplo, que es la manera más clara de verlo. Para no tener que realizar un diagrama complejo, imaginamos un pequeño proyecto del cual hemos efectuado una descomposición en diez actividades, como las que se indican en la tabla siguiente Actividades, duración y precedencia de un proyecto ficticio Núm. Nombre de la Actividad Duración estimada Precedencias 1 Inicio 0-2 Establecer los requerimientos Seleccionar los drivers Realizar el diseño Recoger los datos 2 2 y 3 6 Probar los drivers Codificar Elaborar la documentación Probar el producto 4 5, 6 y 7 10 Final 0 Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de inicio y final, puramente ficticias y con duración cero. La tabla nos ofrece para cada actividad un nombre, una identificación numérica (de uno a diez), la duración estimada de la actividad (en unidades arbitrarias; por ejemplo, en semanas) y las tareas que son inmediatamente anteriores e imprescindibles para poder empezar cada actividad en concreto (precedencias).si se quiere, se puede imaginar que se trata de construir un sistema informático determinado que utiliza datos que ya tenemos (recogidos en la actividad 5) y que utiliza una serie de drivers diferentes (que se seleccionan en la actividad 3 y se prueban en la actividad 6) para acceder a periféricos o a aquello que sea necesario. De hecho, el proyecto en sí no es importante, ya que se trata de un ejemplo ficticio para ilustrar el PERT y el CPM. Si se dispone de estos datos (actividades, duración estimada y precedencias) se puede dibujar un grafo como el de la figura de la página siguiente. Como se puede ver en el diagrama, las flechas marcan las relaciones de precedencia que existen entre las actividades, mientras que los nudos son las actividades, de las cuales se han recogido también una serie de datos: el número identificador, el nombre de la actividad y la duración estimada (puesta entre paréntesis dentro del nudo).sobre cada nudo se ha añadido también la información que sale directamente de la explotación del diagrama de precedencias: las semanas de inicio y final de cada actividad. Conviene darse cuenta de que la actividad final tiene como precedentes todos los arcos pendientes del diagrama. Por ejemplo, la actividad 1 (inicio) empieza en la semana cero y, al tener una duración nula, termina también en la semana cero. Pero la actividad 2 (establecer los requerimientos) comienza en la semana cero (justo después de la actividad precedente, inicio) y finaliza al final de la semana tres, ya que dura precisamente tres semanas. Del mismo modo, la actividad 4 (realizar el diseño no puede iniciarse hasta que no termine la precedente (la 2, establecer los requerimientos), es decir, no puede empezar hasta que Analisis y Diseño I APU 2008 Página 15

16 no ha acabado la semana tres. Además, al durar cuatro semanas, no finalizará hasta el final de la semana siete. Y así sucesivamente En el caso de la actividad 9 (probar el producto) se dan tres precedentes directos: la actividad 7 (codificar), que finaliza en la semana once; la actividad 5 (re-coger datos), que finaliza en la semana cinco; y la actividad 6 (probar los drivers ), que finaliza en la semana ocho. Evidentemente, como se debe esperar a que las tres hayan terminado, la actividad 9 (probar el producto) no puede empezar hasta que no haya acabado la actividad 7 (codificar) en la semana once, que es la que finaliza más tarde de todas. Una vez se ha realizado el diagrama completo, se puede ver que el proyecto dura un total de quince semanas. Y no sólo eso; el diagrama PERT, gracias al método del camino crítico, nos permite saber algo de gran importancia para el futuro de la gestión del proyecto. Una observación sencilla del diagrama nos muestra que las actividades 1 (inicio), 2 (establecer los requerimientos), 4 (realizar el diseño), 7 (codificar), 9(probar el producto) y 10 (final) no tienen ningún margen. Es decir, si alguna de estas actividades tardara más de lo que se ha estimado, todo el proyecto se alargaría más de las quince semanas previstas. En el diagrama, el camino crítico está marcado por flechas continuas. Por otra parte, el diagrama PERT nos permite ver que existen actividades que no son tan decisivas en la vida del proyecto. Por ejemplo, la actividad 6 (probar los drivers) tiene marcados un inicio y un final (2, 8). Es decir, se Analisis y Diseño I APU 2008 Página 16

17 puede comenzar a efectuar una vez finalizada la segunda semana del proyecto (justo cuando acabala actividad precedente 3, Seleccionar los drivers) y, si se cumplen las estimaciones de duración, terminará al final de la semana ocho. Ahora bien, la actividad 9 (probar el producto), de la cual la 6 es precedente, tiene también como precedente la actividad 7 (codificar); y ello provoca que no pueda empezar hasta que no haya finalizado la semana once y que la actividad 6 tenga un margen de tres semanas (11 8=3), de manera que no será nada crítica. Es decir, si la actividad 6 (probar los Drivers) tardara siete semanas en lugar de las seis semanas estimadas, el proyecto duraría también quince semanas, ya que la actividad 6 no forma parte del camino crítico y, como se ve en el diagrama, tiene un margen de tres semanas (podría empezar más tarde o durar más de lo que se había estimado).con vistas a la gestión de un proyecto es muy importante saber qué actividades son críticas (es decir, qué actividades forman parte del camino crítico) y cuáles no. Por otra parte, conviene remarcar que las actividades no críticas disponen de un margen que permite que el planificador acomode mejor los recursos y, sobre todo, que la buena gestión del proyecto pase por el control estricto de las actividades que forman parte del camino crítico. Evidentemente, las cosas son más complicadas en el caso de proyectos con muchas más actividades. Pero, afortunadamente, en estos proyectos es fácil poder disponer de una herramienta informatizada que, de manera automática, nos da el camino crítico y con todas las ventajas que esto representa. Cabe mencionar que en este ejemplo se ha utilizado lo que se llama una planificación Temprana, que sitúa cada actividad lo antes posible y es el procedimiento habitual cuando se parte de la fecha de inicio del proyecto y se quiere encontrar el momento en el que se finalizará. En otros casos, generalmente cuando se parte del día en el que el proyecto debe estar acabado, se utiliza un proceso contrario, a partir de la fecha de fin del proyecto, hecho que se conoce como una planificación Tardia Herramientas informatizadas para la planificación Cuando se habla de herramientas informatizadas para la planificación. Ya hemos mencionado que la parte de la planificación temporal de proyectos informáticos es prácticamente igual a la planificación de cualquier otro proyecto de ingeniería. Esto provoca que las herramientas informáticas disponibles, por el hecho de tener un mercado mucho más amplio, tengan un coste más accesible y su uso se convierta en muy habitual. El problema que se plantea a menudo es decidir cuál de las muchas herramientas disponibles en el mercado se debe escoger. Pero se trata de un problema falso. Como la mayoría de las herramientas informáticas de utilización muy extendida, los sistemas de ayuda a la planificación de proyectos (y también, como veremos, al seguimiento y control) proponen una gran cantidad de funcionalidades que en general no se utilizan. Lo mismo ocurre, por ejemplo, con los procesadores de textos o las hojas de cálculo. Ahora bien, actualmente, para la planificación de proyectos, las herramientas informáticas más habituales en nuestro entorno geográfico se reducen al MS-PROJECT, SUPERPROJECT, PLANER, PHP PROJEKT, GANTT PROJECT, MEMORANDA, OPENPRO. Elegir una de las herramientas es en cierta manera inútil. Cuando una de las herramientas ofrece una funcionalidad nueva no disponible en la otra, sólo se debe esperar unos meses y la nueva versión de esta otra herramienta incorporará también la misma funcionalidad. Además, cabe recordar que la mayoría de estas funcionalidades no siempre se utilizan. Como ocurre con los procesadores de texto, a menudo es mejor lo Analisis y Diseño I APU 2008 Página 17

18 que se utiliza desde hace más tiempo, ya que es lo más conocido y familiar. Una vez explicado esto, debería quedar claro que si los ejemplos de este módulo se presentan en MS-PROJECT es únicamente porque esta herramienta ha estado disponible, pero no porque exista alguna preferencia que se pueda generalizar a otros usuarios. Lo que importa de las herramientas informatizadas para la ayuda a la planificación de proyectos es que todas ofrecen la posibilidad de mostrar el diagrama PERT (o red de actividades) y marcar, además, el camino crítico de manera automática. También ofrecen una gestión de recursos completa y un montón de diagramas y listas (que aumentan día a día) que permiten incluso realizar una presentación brillante y muy profesional de la planificación de un proyecto. La planificación de un proyecto informático En la planificación de un proyecto informático, además del diagrama PERT, se suele utilizar una especie de diagrama temporal llamado diagrama de Gantt. En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el CPM, el diagrama de Gantt sería el que se muestra en la figura siguiente En realidad, la mayoría de herramientas informatizadas de ayuda a la planificación utilizan el diagrama de Gantt como marco de referencia para introducirlos datos de las diferentes tareas o actividades que forman la WBS del proyecto. Previamente, sin embargo, debe establecerse el calendario del proyecto para marcar las fechas que no son laborables o cualquier incidencia laboral. Las herramientas informatizadas ofrecen también diagramas basados en el calendario para marcar los días de inicio y final de cada tarea, aunque el diagrama de Gantt es suficientemente completo en este aspecto. El resumen de lo que se debe llevar a cabo para planificar un proyecto en el tiempo es el siguiente: 1. Establecer el calendario de días laborables de todo el proyecto y, si es necesario, de cada persona del equipo (recurso). 2. Establecer la descomposición del proyecto en tareas (WBS). 3. Estimar la duración (o esfuerzo) de cada tarea o actividad. 4. Establecer las precedencias entre las tareas. Analisis y Diseño I APU 2008 Página 18

19 Realizar el diagrama de Gantt o PERT (red de actividades), preferentemente con una herramienta informatizada para la ayuda a la planificación de proyectos. Para finalizar, es importante saber que, tal como se ha llevado a cabo con las actividades Inicio y Final, de duración nula, conviene añadir siempre algunas actividades ficticias con duración nula como hitos de control para establecer momentos concretos en los que es necesario recopilar los datos y efectuar un balance de la gestión del proyecto. Cuando el proyecto dispone de fases y etapas diferentes, añadir un hito de control al final de cada fase sería lo más correcto, aunque muchas veces se ponen hitos temporales de control: uno cada dos semanas, uno cada mes, etc., según la duración total del proyecto. La consideración de los recursos: añadir nuevas precedencias Conviene señalar que a la hora de establecer precedencias, las hay que son lógicas y las hay que surgen, en el caso concreto de los proyectos informáticos, de la gestión de los recursos. Por ejemplo, en el diagrama de Gantt de la figura anterior hemos imaginado que es posible efectuar simultáneamente las tareas 2 (establecer los requerimientos) y 3 (seleccionar los drivers). Sin embargo, si las dos las debe realizar la misma persona, este diagrama de Gantt nos dice que esta persona tiene una jornada de dieciséis horas y no de ocho como es habitual. No parece, pues, posible. En el caso de los proyectos informáticos de construcción de software, los recursos son las personas, los profesionales informáticos que forman el equipo del proyecto. Se ha de procurar que nadie deba trabajar más de una jornada por culpa de una planificación incompleta que no ha tenido en cuenta los recursos. De hecho, el diagrama de Gantt de la figura anterior sería realista si imaginamos que disponemos de tres personas en el equipo del proyecto: 1. Una primera persona podría llevar a cabo las tareas 2 (establecer los requerimientos), 4 2. (realizar el diseño), 7 (codificar) y 9 (probar el producto). 3. Un segundo miembro del equipo se podría encargar de las tareas 3 (seleccionar los drivers ) y 6 (probar los drivers ) y, tal vez, participar también en la actividad 9 (probar el producto). 4. Para no tener problemas de jornada doble, una tercera persona del equipo debería encargarse de las actividades 5 (recoger datos) y 8 (elaborar la documentación).la figura siguiente muestra una modificación sencilla en el caso de que el equipo del proyecto estuviera formado por dos miembros. Para evitar jornadas dobles de los miembros del equipo, se han tenido que introducir nuevas precedencias: provocar que la actividad 5 (recoger datos) dependa de la 6 (pro-bar los drivers) y, también, que la actividad 8 (Elaborar la documentación) dependa de la 5 (recoger datos), para conseguir que las realice la misma persona Actividades, duración y precedencia de un proyecto ficticio Núm. Nombre de la Actividad Duración estimada Precedencias 1 Inicio 0-2 Establecer los requerimientos 3 1 A 3 Seleccionar los drivers 2 1 B 4 Realizar el diseño 4 2 A 5 Recoger los datos 2 2, 3 y 6 B Analisis y Diseño I APU 2008 Página 19

20 6 Probar los drivers 6 3 B 7 Codificar 4 4 A 8 Elaborar la documentación 2 4 y 5 B 9 Probar el producto 4 5, 6 y 7 A 10 Final 0 La tabla muestra, en negrita, las precedencias adicionales introducidas para evitar la jornada doble de un miembro del equipo. También indica el recurso (la persona miembro del equipo) que realizará cada actividad Cabe decir que, aunque en este ejemplo no ha ocurrido, estas precedencias adicionales suelen cambiar a menudo el camino crítico e incluso la duración global del proyecto. De hecho, a la hora de planificar un proyecto se juega con los recursos disponibles (teniendo en cuenta el coste) y las precedencias de actividades hasta que se encuentra un resultado aceptable. Una vez terminada la planificación, finaliza la calificación y ya se dispone de los objetivos del proyecto informático: un primer boceto de las funcionalidades, los plazos de todo el proyecto y de cada actividad de la WBS y el presupuesto, obtenido básicamente del precio por hora de cada uno de los profesionales que forman parte del equipo del proyecto y del número de horas de trabajo que les han sido asignadas. Seguimiento y control de un proyecto informático Una vez iniciado el proyecto informático, la tarea de gestión consiste en conseguir que las previsiones se cumplan y, en caso de que no sea así, poder detectar lo antes posible las desviaciones que se deben producir para poder encontrarles una solución. Para conseguir Analisis y Diseño I APU 2008 Página 20

21 todo esto, es imprescindible comparar periódicamente la realidad del desarrollo del proyecto con la previsión disponible, ya sea la inicial o cualquiera de las nuevas previsiones que se hayan debido realizar al detectar errores en la estimación o la planificación iniciales. El objetivo declarado del proyecto es alcanzar unas funcionalidades en unos plazos determinados y habiéndolas presupuestado. La actividad de seguimiento y control del proyecto debe conseguir detectar los problemas con la máxima antelación posible para poder reajustar la estimación y la planificación y, en definitiva, cambiar el proyecto modificando los objetivos. El seguimiento pretende una anticipación, no una constatación. Con el seguimiento de un proyecto informático no se trata de constatar si en un momento determinado del proyecto se llevan dos meses de retraso, porque entonces ya sería demasiado tarde. Lo que importa es poder decir, por ejemplo, que aunque actualmente vamos suficientemente bien, si continuamos así de aquí a tres meses se podrá constatar un mes de retraso en el desarrollo del proyecto. Sólo con una previsión anticipada de este tipo se pueden tomar las decisiones adecuadas para tratar de salvar las previsiones del proyecto. En los hitos de control introducidos en la planificación (bien sea al final de fases o etapas de proyecto, o bien de manera periódica) es cuando debemos plantearnos, entre otras cosas, lo siguiente: 1. Si conviene rehacer la descomposición del proyecto en tareas (WBS) o no, posiblemente con la intención de incluir algunas no previstas en el momento inicial, pero que son totalmente necesarias e imprescindibles a medida que avanza el proyecto 2. Si conviene volver a efectuar la estimación del esfuerzo o no, en caso de que se constate que la productividad que se obtiene es diferente de la prevista. 3. Si conviene cambiar algunos de los objetivos del proyecto o no, para tratar de mantener los otros. 4. Si conviene llevar a cabo una nueva calificación del proyecto o no, para tener en cuenta los datos de nuevas tareas o de una productividad diferente de la prevista que la realidad nos aporte. Como se dice en otro módulo, los problemas de una deficiente calificación inicial se intentan resolver demasiadas veces de puertas afuera, haciendo todo lo posible para cumplir con los plazos y el presupuesto a fuerza de reducir las funcionalidades del proyecto, sobre todo las funcionalidades de calidad. Ésta es, evidentemente, una solución totalmente falsa que simplemente aplaza los problemas hasta la fase de mantenimiento, al mismo tiempo que consigue a menudo que los problemas se conviertan en mucho más graves y que tengan una solución mucho más difícil. Las hojas de actividad y el informe de situación Para poder llevar a cabo una comparación correcta entre la realidad y la previsión, es necesario saber cómo va el proyecto y, con esta finalidad, se deben recoger datos de su desarrollo. Con estos datos del seguimiento será posible tener elementos para tomar decisiones de cambio de los objetivos del proyecto y, en definitiva, controlar el desarrollo. La práctica habitual es recoger estos datos del seguimiento en unas hojas de actividad. Analisis y Diseño I APU 2008 Página 21

22 Conviene recoger de manera individual por cada tarea y cada persona involucrada estos datos de seguimiento, a partir de los cuales el jefe de proyecto debe elaborar los datos globales que permiten construir un informe de situación del proyecto. Este informe se suele llevar a cabo para cada uno de los hitos de control establecidos Cuando una tarea finaliza, el jefe de proyecto puede saber el esfuerzo real que ha supuesto realizarla y lo puede comparar con el esfuerzo previsto, para ver si las estimaciones de productividad eran optimistas, pesimistas o realistas. El hecho de disponer de esta productividad real es precisamente lo que debe permitir anticipar los problemas. Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto realiza el seguimiento, a menudo mediante herramientas informatizadas que permiten, para cada actividad del proyecto, introducir las fechas reales del trabajo acabado o el porcentaje del trabajo hecho en cada momento. Estas herramientas ofrecen también una gran cantidad de listas y gráficos que, una vez escogidos los que son útiles, ayudan a las tareas de seguimiento y control del proyecto La ley de Brook s La Ley de Brooks es un principio utilizado en el desarrollo de software que afirma que "añadir más efectivos a un proyecto de software en retraso, lo retrasará más" Según el propio libro de Brooks, la ley es una "frívola sobre simplificación", pero se hace eco de la idea. Brooks destaca dos factores principales que explican el porqué de la ley: 1. Nuevas personas en un proyecto necesitan tiempo para ser productivos. Brooks denomina este lapso el tiempo de rampa de subida ("ramp up time"). Los proyectos de software son complejos esfuerzos de ingeniería, y a los nuevos trabajadores en el proyecto hay que enseñarles primero sobre el trabajo que se realizó anteriormente; esta formación requiere tiempo entre aquellos que ya estaban trabajando en el proyecto, disminuyendo su productividad de forma temporal hasta que los nuevos trabajadores tengan una contribución neta. Cada nuevo trabajador también tiene que integrarse en un equipo compuesto por numerosos ingenieros, que han de ayudar en la formación en sus áreas de conocimiento, día a día. Además, es posible que los nuevos miembros del proyecto de por sí tengan una productividad incluso negativa; por ejemplo, si introducen errores en el software por desconocimiento. 2. Aumento de los costes generales (en tiempo) a medida que aumenta el tamaño del proyecto. El número de canales de comunicación diferentes aumenta con el número de personas de forma exponencial; si se dobla el número de personas en el proyecto, el resultado es 4 veces más conversaciones. Todos aquellos que trabajan en un tema necesitan estar sincronizados entre ellos, de forma que si crece el número de personas, también crecerá el tiempo invertido en tratar de averiguar lo que hace el resto. Excepciones y posibles soluciones Analisis y Diseño I APU 2008 Página 22

23 La ley de Brooks se cita a menudo para justificar que los proyectos no se terminan a tiempo, a pesar de los esfuerzos gestores. Sin embargo, hay algunos puntos clave de la ley de Brooks que permiten excepciones y abren la puerta a posibles soluciones. El primer punto es que la ley de Brooks se suele aplicar a proyectos que tienen retraso. Se puede volver a controlar (o mantener bajo control) si se refuerza el equipo en fases previas. También es importante determinar si un proyecto se encuentra realmente en retraso o si las estimaciones iniciales fueron demasiado optimistas, algo frecuente. Corregir la planificación es la mejor manera de disponer de una ventana de tiempo fiable y útil para finalizar el proyecto. La cantidad, calidad y papel de la gente que se incorpora al proyecto son factores a tener en cuenta. Una vía simple de evitar la ley en un proyecto en retraso es añadir más gente de la necesaria, de forma que la capacidad extra compensa el overhead en comunicación y formación. Los buenos programadores o especialistas se pueden incorporar con menos necesidad de tiempo para su formación. También se puede incorporar personal para realizar otras tareas relacionadas con el proyecto, por ejemplo documentación o garantía de calidad en caso de que la tarea esté disponible, así se disminuye el tiempo de la rampa de subida. Una buena labor de gestión y desarrollo también ayuda a reducir el impacto de la ley de Brooks. Las prácticas modernas de integración continua, desarrollo guiado por pruebas, y desarrollo iterativo reducen significativamente el overhead de comunicación entre los desarrolladores, permitiendo mejor escalabilidad. También nuevas herramientas para el desarrollo de software y su documentación son de ayuda a minimizar el tiempo de rampa de subida, haciendo más sencilla la incorporación al proyecto. Los patrones de diseño simplifican la distribución del trabajo, dado que el equipo completo puede realizar el trabajo dentro del patrón que se le asignó. Los patrones de diseño definen las reglas que han de seguir los programadores, simplifica la comunicación por medio del uso de un lenguaje estándar y proporciona consistencia y escalabilidad. Finalmente, una buena segmentación ayuda minimizando el overhead entre los miembros del proyecto. Los problemas menores se resuelven en equipos pequeños y un equipo superior es responsable de la integración del sistema. Para poder trabajar así es necesario segmentar el problema de forma correcta; en caso contrario, puede empeorar el problema, impidiendo la comunicación entre los programadores que trabajan en diferentes partes del problema que están directamente relacionados, aunque el plan del proyecto afirme que no los están. Algunos autores véase, por ejemplo, Creating a Software Engineering Culture de Karl E. Wiegers han recalcado la importancia de los aspectos sociales y políticos del clima de trabajo como determinantes de la efectividad de los programadores individuales y del equipo del proyecto como un todo. En lugar de depender de "héroes" para llevar a cabo la tarea con esfuerzos extraordinarios, Wiegers afirma que un equipo de individuales de cualidades ordinarias pueden proveer resultados a tiempo de forma periódica con el ambiente de trabajo correcto. Los esfuerzos para mejorar la efectividad de los equipos puede mitigar sino eliminar, las consecuencias de la ley de Brooks. Una teoría que proviene de la experiencia del autor de la obra The Mythical Man-Month (1975) como director del proceso de construcción del sistema operativo de IBM 360. Es necesario entender esta advertencia en el sentido de que no se pueden intercambiar hombres y meses. Y también se debe entender que la ley no es algo matemático, sino sólo una advertencia para los que todavía no han captado el mito del hombre-mes. Analisis y Diseño I APU 2008 Página 23