Tema 4: Introducción a la Gestión de Proyectos. Departamento de Lenguajes y Sistemas Informáticos II

Transcripción

1 Tema 4: Introducción a la Gestión de Proyectos Departamento de Lenguajes y Sistemas Informáticos II

2 Introducción He visitado docenas de tiendas comerciales, tanto buenas como malas, y he observado registros de gerentes de procesamiento de datos, de nuevo, tanto buenos como malos. Con mucha frecuencia he visto con horror cómo dichos gerentes luchaban inútilmente con proyectos de pesadilla, sufriendo por fechas límites imposibles o por sistemas ya entregados que indignaron a sus usuarios y devoraron enormes cantidades de tiempo de mantenimiento (Meilir Page-Jones) 2

3 Qué es un proyecto? Definición 1: Es un conjunto de actividades planificadas, ejecutadas y supervisadas que, con recursos finitos, tiene como objetivo crear un producto o servicio único. Definición 2: Un proyecto es una actividad que tiene un inicio, que se lleva a cabo para conseguir unos objetivos definidos y tiene un final previsto. Objetivo El objetivo principal es obtener un resultado en forma de bien o producto para un cliente que da una especificaciones y marca unos objetivos a cumplir para que el proyecto se lleve a cabo. 3

4 Definición Qué es?: La GP involucra la planificación, supervisión y control del personal, el proceso y los eventos que ocurren mientras el sw evoluciona desde una idea preliminar hasta una implementación operativa. Quién la hace?: Todos gestionan (a su escala). IS: Gestiona sus actividades diarias; planifica, supervisa y controla labores técnicas. Gestores de Proyecto: Planifican, supervisan y controlan el trabajo del equipo de IS. Gestores Ejecutivos: Coordinan la relación entre el negocio y los profesionales del software. Por qué es importante?: La construcción de software involucra a mucha gente que trabaja durante mucho tiempo Actividad compleja que necesita ser gestionada. 4

5 Diferencias con otras ingenierías Diferencias entre la gestión de Proyectos Software y otros tipos de proyectos El producto es intangible Un proyecto de ingeniería Civil puede verse mientras se está desarrollando. Si hay un desfase en el calendario se puede ver relativamente fácil (partes de la estructura del puente no están terminadas cuando deberían) en software no es tan fácil ver el progreso. No existen procesos del software estándar Proceso de construcción de un rascacielos se comprende bien. Ej. Mínimas diferencias en los tiempos de construcción de las 4 Torres de Madrid. En software no siempre se puede asegurar que un determinado proceso va a funcionar mejor que otro. A menudo los proyectos grandes son únicos Generalmente los proyectos suelen ser diferentes. Pocas compañías desarrollan siempre el mismo tipo de proyectos No existe experiencia previa incertidumbre 5

6 Gestión de Proyectos La gestión eficaz de un proyecto software se centra en lo que denominamos las 4P : Personal.- Organizado para el trabajo con efectividad Producto.- La comunicación entre el cliente y el equipo debe permitir comprender el ámbito y los requisitos del producto Proceso.- Se debe seleccionar un proceso adecuado para el personal y para el producto. Proyecto.- Se debe: estimar el tiempo y el esfuerzo para cumplir los objetivos; definir productos de trabajo; establecer puntos de control de calidad; identificar mecanismos de supervisión y control del trabajo planificado. 6

7 Cómo Comienza un Proyecto: Necesidad Interna Orígenes en la decisión de emprender un proyecto: Variación en los requisitos del software (cambios en la legislación, estándares ) Petición cliente o usuario Propuesta generada dentro de la organización de desarrollo Necesidad detectada por el departamento de marketing Recomendación del personal de mantenimiento de aplicaciones existentes Necesidad detectada por el personal informático (quejas, sugerencias...) Priorización por plan estratégico de Sistemas de Información (si existe) Se recomienda: Obtener una idea clara de lo que se pretende hacer Evaluar la viabilidad del proyecto analizando beneficios/gastos 7

8 Cómo Comienza un Proyecto: Solicitud Externa Orígenes en la decisión de emprender un proyecto: Respuesta a la demanda de un cliente como resultado de una labor comercial concreta. Respuesta a la demanda de un cliente como consecuencia de una solicitud de propuestas (RFP) (p.e. una oferta pública) Se recomienda : Obtener una idea clara de las necesidades del cliente Valorar la viabilidad del proyecto Criterios para tomar la decisión de emprender o no un proyecto: Relacionados con el negocio (beneficios, objetivos ): Relacionados con los riesgos (complejidad, esfuerzo, relación con otros proyectos, ) 8

9 Personal Jefes de proyecto Selección del jefe de proyecto Decisión posterior a la de emprender el proyecto, pero recomendable que intervenga desde el principio del proceso. Es el elemento más crítico para el éxito del proyecto. Cada proyecto requiere un jefe de proyecto con una cualificación diferente. Es importante un buen nivel en: Relación con el negocio Competencias personales Competencias interpersonales Dotes de gestión (competencias técnicas de gestión), liderazgo Resolución del problema Incentivos por logros Motivación del espíritu de equipo. Control en cada situación. 9

10 Personal Jefes de proyecto Buen técnico Buen jefe En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia. Lawrence J. Peter Un excelente programador puede ser un pésimo analista y un excelente analista puede llegar a ser un pésimo Jefe de Proyecto. Las capacidades y habilidades de cada una de estos roles son distintos. Desafortunadamente, en muchas ocasiones las personas acaban desempeñando funciones de gestión de proyecto porque toca, sin la necesaria formación para desempeñar sus funciones. 10

11 Gestión de Proyectos Gestión de proyectos Planificación Estimación Seguimiento y supervisión Análisis y gestión del riesgo Definición de la calidad del producto Gestión de la configuración 11

12 Planificación Planificación de proyectos. Definición Conjunto de actividades previas a la puesta en marcha del proyecto Objetivo Proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal 12

13 Planificación Objetivos del plan de proyecto Proporcionar un resumen del proyecto a los directivos que les ayude a tomar las decisiones de aprobación que afecten al proyecto. Permitir tanto al jefe de proyecto como a los clientes supervisar el progreso del proyecto, desde el inicio hasta el final. Presentarse como un documento orientado al cliente. Constituir un documento base del proyecto con la aprobación del cliente y actualizable, a medida que avanza el proyecto 13

14 Planificación Contenido del plan de proyecto Resumen del proyecto Entregables de forma que se pueda comprobar que se ajustan al plan Lista de hitos Procedimientos y estándares a aplicar. Una especificación del proceso de revisión que determine quién, cómo y cuándo se puede revisar la planificación del proyecto y con qué objetivo Plan de comunicación entre la organización y el cliente. Diagrama de descomposición del trabajo (WBS) Lista del personal del proyecto y su asignación en relación con la WBS. Red de actividades que muestre la secuencia de tareas en el tiempo y su relación entre ellas Responsables de todas las actividades Estimaciones de esfuerzo y dinero, así como calendarios y plazos 14

15 Planificación: Std IEEE Página de título Hoja de revisión Prefacio Tabla de contenidos Lista de figuras Lista de tablas Introducción Visión General del proyecto Productos finales Evolución del Plan de Proyecto Documentos de referencia Definiciones y acrónimos Organización del Proyecto Modelo de procesos Estructura organizativa Fronteras y interfaces organizativas Responsabilidades Proceso de Gestión Objetivos y prioridades de gestión Suposiciones, dependencias y restricciones Gestión de riesgos Mecanismos de supervisión y control Plan de personal Proceso Técnico Metodología, técnicas y herramientas Documentación software Funciones de apoyo al proyecto Plan de Desarrollo Paquetes de trabajo Dependencias Recursos Presupuesto y distribución de recursos Calendario Secciones adicionales Índice Apéndices 15

16 Planificación En secciones adicionales: Planes de subcontratación: procedimientos de selección y control de las tareas y de las personas o empresas que se van a subcontratar Aseguramiento de calidad. Recursos para realizar el aseguramiento de calidad, estándares y normativas aplicables al proyecto, las revisiones y auditorias que se van a llevar a cabo, etc. También puede incluir la planificación de las pruebas o referenciar a un Plan de Pruebas como documento aparte Gestión de configuración: cómo se van a identificar los elementos de configuración, cómo se controlarán sus cambios y sus versiones, y cómo se informará de su estado. Estructura de integración hardware/software Planes de seguridad 16

17 Planificación Pasos en el desarrollo de un calendario Definición de los objetivos del proyecto Descomposición de las actividades Relación entre actividades Estimación de tiempos y costes de las actividades Ajuste del calendario a las restricciones del proyecto Asignación de recursos. Organización del equipo Revisión del calendario 17

18 Planificación Pasos en el desarrollo de un calendario Definición de los objetivos del proyecto Objetivo del proyecto : enunciado que especifica los resultados que se deben conseguir Características de un buen objetivo: asequible, definitivo, cuantificable y de duración específica Descomposición de las actividades Diagrama de descomposición de actividades 18

19 Planificación Pasos en el desarrollo de un calendario Descomposición de las actividades 00 Proyecto de desarrollo X Nivel de Proyecto J.L. Fernández Nivel de paquete de trabajo Gestión del Proyecto J.L. Fernández Ingeniería del Sistema S. Alonso Desarrollo del Software Pruebas de integración y del sistema J. Gómez V. Pérez Gestión del Proyecto Gestión de Configuración Diseño del Sistema Análisis y Diseño Programación Pruebas Pruebas de Integración Pruebas de Aceptación J.L. Fernández T. Diez S. Alonso A. Ramirez P. Redondo S. Sánchez G. Alfonso G. Fuentes Plan de Proyecto UT. 111 Control de Configuración UT. 121 Construcción de Software UT. 122 Comunicaciones UT. 211 Análisis de Requisitos UT. 212 Gestión de la Base de Datos UT. 213 Diseño Funcional UT. 311 Diseño de Algoritmos UT. 312 Diseño de la Base de Datos UT. 313 Programación UT. 321 Documentación UT. 322 Soporte a las Pruebas UT. 323 Procedimientos de Pruebas UT. 331 Pruebas Unitarias UT. 332 Análisis de las Pruebas UT. 333 Procedimientos de Pruebas UT. 411 Integración del Sistema UT. 412 Formación UT. 413 Procedimientos de Pruebas UT. 421 Satisfacción de Requisitos UT. 422 Nivel de Unidad de Trabajo Arquitectura UT

20 Planificación Pasos en el desarrollo de un calendario Relación entre actividades Técnicas para proyectos cortos: diagramas de hitos, diagramas de Gantt. Técnicas para proyectos grandes: PERT (Program Evaluation and Review Tecnique) y CPM (Critical Path Method) Estimación de tiempos y costes de las actividades Suelen estar basadas en la experiencia del planificador en proyectos similares y deben incluir los retrasos normales. Es una buena estrategia para el jefe de proyecto contrastar y negociar sus cálculos de tiempos y esfuerzos con los responsables de cada actividad, que suelen contar con buena precisión a la hora de estimar los costes reales en tiempo y esfuerzo. 20

21 Planificación Pasos en el desarrollo de un calendario Ajuste del calendario a las restricciones del proyecto. Objetivos Determinar la duración total del proyecto cualquier técnica para la determinación del calendario Identificar las actividades que contribuyen a la duración total del proyecto (actividades críticas) Redes de precedencia Calcular las holguras de las actividades que no son críticas Redes de precedencia Asignación de recursos. Organización del equipo Ajustar el calendario en función de los recursos disponibles Importancia de las holguras Ajuste de las actividades no críticas en función de los solapamientos de actividades críticas Revisión del calendario Es realista? Efectos de la vida laboral en el calendario (vacaciones, enfermedad, etc.) Asegurar que es flexible 21

22 Técnicas Diagrama de hitos Diagrama de Gantt Gestión de Proyectos: Técnicas de planificación Redes de precedencia: PERT 22

23 Técnicas de planificación: Diagramas de hitos Técnicas Diagramas de hitos Es un cuadro o tabla formada por dos columnas: Tarea Tarea 1.1 Tarea 1.2 Tarea 1.3 Tarea 2.1 Tarea 2.2 Tarea 2.3 Fecha fin Marzo-2006 Mayo-2006 Junio-2006 Mayo-2006 Agosto-2006 Octubre-2006 Ventajas: facilidad de uso (es el método más simple) y mínimo coste de preparación (todo el mundo lo comprende inmediatamente) Desventajas: incertidumbre existente sobre las fechas de comienzo de las actividades y la imposibilidad de reflejar las interrelaciones entre ellas. Se utiliza para resumir calendarios complejos 23

24 Técnicas de planificación: Gantt Técnicas Diagrama de Gantt Diagrama de barras en forma de tabla donde se hace una referencia cruzada entre las tareas (filas) y los tiempos de duración (unidades de tiempo) de las mismas (columnas) Muestra claramente la duración de las actividades y la precedencia de unas tareas con respecto a otras. Inconveniente: NO permite representar las dependencias entre actividades. Ventajas: SÍ expresa claramente los solapamientos entre actividades. 24

25 Técnicas Diagrama de Gantt Gestión de Proyectos: Técnicas de planificación: Gantt Tarea 1.1 Tarea 1.2 Tarea 1.3 Tarea 2.1 Tarea 2.2 Tarea 2.3 Unidades de tiempo

26 Técnicas de planificación: Redes de precedencia Técnicas Redes de precedencia. Modelo gráfico que señala las relaciones secuenciales entre los sucesos claves en un proyecto. Permiten tratar la relación coste/duración de las actividades. Concepto de coste mínimo como principio de la planificación de proyectos Camino crítico: secuencia más larga de actividades conectadas a través de la red y que determina la duración total del proyecto. Objetivos: detectar el camino crítico y limitaciones de tiempo Cuándo utilizar estas técnicas: Actividades bien definidas Actividades como entidades atómicas independientes Las actividades pueden relacionarse entre sí y ser ordenadas Existe una ejecución secuencial de las actividades La red debería tener más de 20 eventos y menos de

27 Técnicas de planificación: redes de precedencia Técnicas Redes de precedencia. Técnica de evaluación y revisión de programa (PERT) Centrado en los eventos o sucesos (como hitos) Permite el tratamiento de la probabilidad para estimar el tiempo Proyectos con alto grado de incertidumbre Método del camino crítico (CPM) Centrado en las actividades Actividades bien definidas Aplicación en proyectos industriales con bajo grado de incertidumbre 27

28 Técnicas de planificación: PERT Diagramas PERT. Principios Parte de la descomposición de un proyecto en actividades: Las actividades consumen recursos Ocurren entre dos sucesos (suceso inicial y suceso final). Suceso: acontecimiento o punto temporal (una fecha) que no consume recursos Representación por medio de un grafo Suceso 1 Actividad A 2 Suceso 28

29 Técnicas de planificación: PERT Diagramas PERT. Principios Relaciones de precedencia: actividades que deben estar finalizadas justamente antes del comienzo de la actividad dada RELACIONES DE PRECEDENCIA LINEALES A B Para iniciar la actividad B es necesario haber finalizado la actividad A. El suceso 2 es suceso final de A y suceso inicio de B. RELACIONES DE PRECEDENCIA CONVERGENTES 1 2 B C A D 4 5 Para iniciar la actividad D es necesario haber finalizado las actividades A, B y C. 3 RELACIONES DE PRECEDENCIA DIVERGENTES 1 A 2 B C D Para poder iniciar cualquiera de las actividades B, C, o D, es necesario que haya finalizado la actividad A. 29

30 Técnicas de planificación: PERT Diagramas PERT. Conflictos entre actividades Por ejemplo: Las actividades A y B preceden a la actividad D. Las actividades A, B y C preceden a la actividad E. A D B C E No se cumple la regla 1: Es necesario que finalice C para que comience D 30

31 Técnicas de planificación: PERT Diagramas PERT. Conflictos entre actividades: Solución Añadir una actividad ficticia de duración cero A D B F C E 31

32 Técnicas de planificación: PERT Diagramas PERT. Representación Supongamos que tenemos que realizar un proyecto que tiene las actividades A, B, C, D, E, F y G. Las relaciones son: A precede a B, C y D B precede a E C precede a F D precede a G E, F preceden a H Dos modos de representar estas relaciones: Matriz de encadenamientos Cuadro de relaciones de precedencia 32

33 Actividades siguientes Gestión de Proyectos: Técnicas de planificación: PERT Diagramas PERT. Representación Matriz de encadenamientos: Matriz cuyas dimensiones coinciden con el número de actividades en que se descompone el proyecto Sea Mij un elemento de la matriz, si Mij = X, entonces para poder iniciar la actividad i es necesario que haya finalizado la actividad j Actividades precedentes A B C D E F G A B C D E F G H X X X X X X H X X 33

34 Técnicas de planificación: PERT Diagramas PERT. Representación Cuadro de relaciones de precedencia: tabla de dos columnas: Actividades en que se descompone un proyecto Sus actividades precedentes Actividades Actividades Precedentes A - B A C A D A E B F G H C D E, F 34

35 Técnicas de planificación: PERT Diagramas PERT. Representación Grafo 3 E A 1 2 B C 4 F 6 H D G

36 Técnicas de planificación: PERT Diagramas PERT. Asignación de tiempos a actividades El siguiente paso es el cálculo de los tiempos early (tiempo más temprano posible) y last (tiempo más tardío posible) de cada suceso descrito en el grafo. Tiempo más temprano para comenzar la actividad A (tiempo early de comienzo de A) Tiempo más temprano para finalizar la actividad A Tiempo más tardío para comenzar la actividad A Tiempo más tardío para finalizar la actividad A TE i TL i A TE j TL j suceso i suceso j 36

37 Diagramas PERT Gestión de Proyectos: Técnicas de planificación: PERT Cálculo de los tiempos más tempranos (early) El tiempo early del suceso j, que representamos por TEj, se calcula sumando los tiempos early de los sucesos en los que nace una actividad que finaliza en el suceso j, la duración de la actividad (Tij) y cogiendo el mayor de todos ellos TEj = máx [ TEi + Tij ] Siendo: TEi el tiempo early del suceso i Tij la duración de la actividad que comienza en el suceso i y finaliza en el suceso j 37

38 Técnicas de planificación: PERT Diagramas PERT Supongamos calculados los tiempos PERT de cada actividad: Actividad A B C D E F G H Duración A 2 5 B 6 C E 7 F H D 5 9 G

39 Técnicas de planificación: PERT Diagramas PERT Cálculo de los tiempos más tardíos (late) El tiempo late del último suceso, coincide con su tiempo early El resto de los tiempos late se calculan restando a los tiempos late de los sucesos en los que finalizan actividades que nacen en el suceso i, la duración de las actividades y escogiendo el menor de ellos TLi = min [ TLj - Tij ] Siendo: TLj el tiempo late del suceso j Tij la duración de la actividad que comienza por el suceso i y finaliza en el suceso j 39

40 Diagramas PERT Gestión de Proyectos: Técnicas de planificación: PERT A B 6 C E 7 F H D G 5 40

41 Técnicas de planificación: PERT Holgura total de una actividad y camino crítico: Holgura de un suceso i: Hi = TLi Tei Indica el número de unidades de tiempo en que se puede retrasar su realización de forma que no se aumente la duración total del proyecto. Se dice que un suceso es crítico si Hi = 0 41

42 Técnicas de planificación: PERT Holgura total de una actividad y camino crítico: Holgura total de una actividad: HTij = TLj - TEi - Tij Representa el número de unidades de tiempo que puede retrasarse la realización de la actividad con respecto al tiempo PERT previsto, sin que aumente la duración del proyecto. Se dice que una actividad es crítica si la holgura total = 0 42

43 Técnicas de planificación: PERT Holgura total de una actividad y camino crítico: Camino crítico: camino que se forma uniendo todas las actividades críticas desde el suceso inicial al suceso final del proyecto Cualquier retraso que sufra alguna de las actividades del camino crítico, implicará un retraso del proyecto. El jefe de proyecto no debe sólo prestar atención a las actividades críticas sino también a las que no lo son, ya que si una actividad no crítica consume el total de su holgura, se convierte en crítica, y aparecería un nuevo camino crítico. 43

44 Técnicas de planificación: PERT Holgura libre y holgura independiente de la actividad Holgura libre de una actividad ij: tiempo que resulta de restar al tiempo early del suceso final el tiempo early del suceso inicial y la duración de la actividad: HLij = TEj - TEi Tij La holgura libre representa la parte de la holgura total que puede consumirse sin que por ello, afecte a las siguientes actividades. 44

45 Técnicas de planificación: PERT Holgura libre y holgura independiente de la actividad Holgura independiente de una actividad ij: tiempo que resulta de restar al tiempo early del suceso final el tiempo late del suceso inicial y la duración de la actividad HIij = TEj - TLi Tij Este dato indica la cantidad de holgura disponible si todas las actividades han comenzado en sus tiempos late 45

46 Técnicas de planificación: PERT Ejercicio Actividad Actividades precedentes Duración A B,D 3 B C 6 C J 4 D I, M 8 E I, M 9 F I, M 3 G H 5 H J 4 I J 2 K F, G 6 L A, E, P 4 M H 3 P F, G 7 46

47 Técnicas de planificación: PERT Ejercicio J C H G K 4 I M B D P F 9 E A L 47

48 Técnicas de Planificación: PERT Actividad Sucesores Duración , , , , , Final 0 48

49 Estimación Estimación Antes de que comience el proyecto Parámetros estimados: Tiempo, esfuerzo, recursos (HW, SW, humanos) y riesgo Difícil, pero no imposible No es una ciencia exacta, aunque no debe descuidarse La experiencia es un elemento importante en la estimación Se utilizan métricas para dar una estimación cuantitativa del esfuerzo y del tiempo 49

50 Estimación Métodos de estimación de costes Opinión de expertos Estimación por analogía Descomposición Modelos de estimación 50

51 Estimación Métodos de estimación de costes Opinión de expertos Adivinación basada en la experiencia personal Técnicas para sistematizar y mejorar la opinión de las distintas personas involucradas en la estimación Varias opiniones Consensos Otras (Delphi) Estimación por analogía Descomposición Modelos de estimación 51

52 Estimación Métodos de estimación de costes Opinión de expertos Estimación por analogía Complemento a la opinión de expertos Comparación con proyectos similares terminados Ventajas: Basado en experiencia real, no subjetiva Inconvenientes: Dificultad de saber el grado de similitud Básico contar con buena colección de datos Descomposición Modelos de estimación 52

53 Estimación Métodos de estimación de costes Opinión de expertos Estimación por analogía Descomposición La estimación para el proyecto completo se calcula mediante la suma de las cantidades parciales Inconveniente: Actividades que no suelen incluirse en la definición (hasta 40%) Actividades no relacionadas con el proyecto Modelos de estimación 53

54 Estimación Métodos de estimación de costes Opinión de expertos Estimación por analogía Descomposición Modelos de estimación Utilizan fórmulas derivadas empíricamente para predecir los datos Datos empíricos a partir de una muestra de proyectos limitada Por ello, un mismo modelo no es adecuado para todas las clases de software ni para todos los entornos de desarrollo Ejemplo: SLIM, COCOMO, PF 54

55 Seguimiento y supervisión Seguimiento de la planificación Definición Seguir, revisar y comparar los logros y los resultados obtenidos, frente a las estimaciones, los compromisos y los planes del proyecto, actualizándolos en función de estos resultados Responsable: jefe del proyecto Objetivos: Comparar resultados con los planes previstos Realizar acciones correctivas cuando existan desviaciones significativas Acordar compromisos con el personal afectado Tareas: Reuniones periódicas evaluar progreso Determinar hitos cumplidos Comparar fecha real y prevista de inicio Evaluar los resultados de las revisiones 55

56 Gestión de Riesgos Riesgo: Cualquier elemento potencial que provoca resultados insatisfactorios en un proyecto Necesidad de comprender y controlar el riesgo en aquellas áreas que puedan tener influencia en el proyecto Áreas típicas de riesgo: Riesgos estratégicos Riesgos comerciales Riesgos contractuales y financieros Riesgos de gestión Riesgos de proyecto Riesgos de explotación Riesgos de mantenimiento Una vez identificados, es necesario realizar un seguimiento y control de estos 56

57 Bibliografía Roger S. Pressman. Ingeniería del Software: Un enfoque práctico. Capítulo 3. Ed. McGraw Hill. 5ª edición.2002 M. Piattini et al. Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión. Ed. Ra-Ma IEEE Std , IEEE Standard for Software Project Management Plans. pdf 57