Planificación y Gestión del Proyecto

Planificación y Gestión del Proyecto INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE CÓMPUTO M. En C. Eduardo Bustos Farías Sep-05 Ing. de Software 1

Planificación y Gestión del Proyecto Gestión de Proyectos Técnicas y Herramientas de Planificación Métricas de Tamaño Estimaciones de Tamaño, Esfuerzo, Costo y Duración Recursos Humanos y Organización Evaluación de Factibilidad Gestión de Riesgos Gestión de la Calidad Gestión de la Configuración Comunicaciones entre los involucrados Registro y Control de Avance Sep-05 Ing. de Software Planif. y Gestión 2

Proyecto Operaciones y Proyectos: llevados a cabo por personas sometidos a restricciones (recursos) se planifican, ejecutan, controlan Operación Continua<> Proyecto Proyecto inicio y fin (el proyecto) producto/servicio único (el resultado continua) Alcance? Sep-05 Ing. de Software Planif. y Gestión 3

Conceptos fundamentales Gestión de Proyectos: Aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto, para cubrir o superar las necesidades y expectativas para un proyecto Interesados (stakeholders): Involucrados (participan) Interesados afectados positiva o negativamente Alcance: del producto (final) sus características del proyecto trabajos incluidos (y no) Sep-05 Ing. de Software Planif. y Gestión 4

Alcance y Expectativas Necesidades Expectativas Balancear Recursos Calidad Alcance Tiempo Necesidades Expectativas Restricciones Tecnología Proceso Personas Sep-05 Ing. de Software Planif. y Gestión 5

Relación con otras disciplinas de la Administración Administración General planificar, organizar, asignar personal, ejecutar y controlar las operaciones de una empresa de operación continua Áreas de Aplicación (categorías de proyectos) Elementos Técnicos Elementos Administrativos Ramas de la Industria Gestión de Proyectos Administración Gral. Área de Aplicación Sep-05 Ing. de Software Planif. y Gestión 6

Relación con otros Emprendimientos Programa conjunto de proyectos relacionados a menudo incluyen elementos de Operación Continua Subproyecto parte de un proyecto a menudo contratada a un proveedor Sep-05 Ing. de Software Planif. y Gestión 7

Técnicas y Herramientas de Planificación WBS CPM Técnica Herramienta Esquema numerado Word Project (y otros) PERT Gantt Perfil de uso de Recursos Evolución de gastos Valor Ganado Planilla Electrónica Project, Planilla Electrónica Sep-05 Ing. de Software Planif. y Gestión 8

WBS Work Breakdown Structure ( descomposición jerárquica de actividades o desglose de actividades ) El proyecto se descompone teniendo en cuenta los productos intermedios a obtener y se repite el proceso mientras resulte necesario (y posible) para el control Modelo de Proceso implícito La jerarquía facilita análisis a distintos niveles Sólo representa relaciones composicióndescomposición No representa relaciones de precedencia Sep-05 Ing. de Software Planif. y Gestión 9

WBS - Ejemplo: Casa Casa Diseño Terreno Materiales Construcción Planos Delimitar Adquirir Cimientos Memoria Descript. Acondicionar Notas: 1. No se representan relaciones de precedencia. 2. Es usual presentarlo (en lo posible) en el orden de ejecución Muros Techos Sanitaria Electricidad Terminaciones Sep-05 Ing. de Software Planif. y Gestión 10

WBS - Contra-Ejemplo: Casa Casa Dormitorios Living Comedor Cocina Baño Principal Niños Huéspedes Notas: 1. En este caso hay una descomposición jerárquica del producto (no de las actividades), sin tener en cuenta los productos intermedios. 2. Considerado como WBS, qué opina de la técnica constructiva implícita? Sep-05 Ing. de Software Planif. y Gestión 11

Actividad e Hito Actividad es una parte de un proyecto que se lleva a cabo durante un período de tiempo. Un Hito es un punto en el tiempo que marca el inicio o el fin de una actividad. Describir cada actividad precedentes duración producto Sep-05 Ing. de Software Planif. y Gestión 12

Grafo de Actividades (CPM) Critical Path Method Se consideran: las hojas del WBS (actividades) las relaciones de precedencia entre ellas (una actividad no puede comenzar hasta que las precedentes hayan concluido) no se admiten circuitos de precedencia Hoy en día lo usual es representar: actividades por bloques (compatible con Diag. Gantt) Las relaciones de precedencia por flechas (intuitivo) Hay un nodo Inicio y otro Fin (no se precisan elementos ficticios) Modelo del proyecto (actividades, precedencias, duraciones) Sep-05 Ing. de Software Planif. y Gestión 13

Grafo de Actividades b.memoria Descript. i.electricidad j.sanitaria inicio a.planos c.delimitar (Terreno) f.acondicionar (Terreno) d.adquirir (Materiales) e.cimien tos h.techos g.muros k.terminaciones fin Sep-05 Ing. de Software Planif. y Gestión 14

Grafo de Actividadesconceptos básicos para las actividades Comienzo Temprano (lo antes que puede comenzar respetando las precedencias y las duraciones) Fin Temprano (la fecha de fin si la actividad comienza lo antes posible y dura lo previsto) Fin Tardío (lo más tarde que puede terminar la actividad sin afectar la duración del proyecto) Comienzo Tardío (lo más tarde que puede comenzar la actividad sin afectar la duración del proyecto) Holgura Total (cuanto se puede atrasar el comienzo de una actividad sin afectar la fecha de fin del proyecto Camino Crítico: integrado por actividades que si se atrasan, atrasan el proyecto (Holgura Total=0) Sep-05 Ing. de Software Planif. y Gestión 15

Grafo de Actividades con duraciones i (1) b (4) 0 inicio a (3) c (5) h (7) j (2) fin d (5) g (5) Colores: Temprano f (8) e (7) k (10) Tardío Sep-05 Ing. de Software Planif. y Gestión 16

Grafo de Actividades con duraciones 0 inicio Colores: Temprano Tardío 0 3 a (3) 0 3 8 3 3 d (5) 8 16 8 8 f (8) 3 7 7 b (4) 16 11 7 12 c (5) 11 16 e (7) g (5) 23 16 23 16 h (7) 28 23 28 28 35 35 36 i (1) 44 45 35 37 j (2) 35 45 k (10) Sep-05 Ing. de Software Planif. y Gestión 17 23 28 35 43 35 45 45 45 fin Cuál es el Camino Crítico?

PERT Como CPM pero la duraciones variables aleatorias Estima la duración de cada actividad a partir de estimar un valor mínimo a (optimista), más probable m y máximo b (pesimista) Le atribuye distribución Beta (no siempre simétrica) y aproxima el valor esperado por E=(a+4m+b)/6 Aproxima σ por (b-a)/6 y considera las duraciones como variables aleatorias independientes por lo que: σ 2 camino crítico=σ σ 2 activ.camino crítico Duraciones v.a. independientes? Y los otros caminos? Sep-05 Ing. de Software Planif. y Gestión 18

ACTIVIDAD Diagrama de Gantt HOY ENE FEB MAR ABR MAY JUN JUL AGO SEP OCT NOV DIC WBS 1.0 PLANEAR SISTEMA 1.1 Revisar especificación 1.2 Revisar presupuesto 1.3 Revisar calendario 1.4 Desarrollar plan WBS 2.0 DISEÑAR SISTEMA 2.1 Diseño de alto nivel 2.2 Prototipar Especificación aprobada Presupuesto aprobado Calendario aprobado Plan aprobado Diseño aprobado 2.3 Interfaz de usuario 2.4 Diseño detallado Completada Duración Flotante Crítica Deslizamiento Inicio Tarea Diseño aprobado Fin Ttarea Sep-05 Ing. de Software Planif. y Gestión 19

Pertil de uso de Recursos Un diagrama de Gantt tiene asociado (de forma explícita o no) una utilización de recursos (personas, maquinaria, etc.)para cumplir las actividades El Perfil de Uso permite evaluar si el plan del diagrama es factible (no hay sobre-utilización) y si hay sobre-costos derivados de períodos de ocio El plan final resulta de revisar y ajustar Gantt y Recursos Nivel de uso Sub-utilización Sobreutilización Recurso Ocioso Capacidad del Recurso t Sep-05 Ing. de Software Planif. y Gestión 20

Ajuste del plan - Técnicas Camino crítico (para identificar qué ajustar) Compresión; en gral.>costo por agregar recursos Paralelizar, en gral.: >riesgo (plazo, costo, calidad) >costo x retrabajo Nivelado y ajuste de los recursos Sep-05 Ing. de Software Planif. y Gestión 21

Niveles e instancias de Planificación Cuándo se lleva a cabo la planificación? Qué nivel de detalle se puede obtener antes de detallar los requerimientos? La planificación se maneja normalmente a dos niveles: Macro, en donde se detallan fases Micro, con detalle de actividades y componentes Sep-05 Ing. de Software Planif. y Gestión 22

Métricas de Tamaño Casa: Metros Cuadrados de Construcción Carretera: Kilómetros/Kilómetros Cuadrados Software:? Líneas de Código Variabilidad Personal (Tamaño/Productividad) En qué lenguaje? Física? Lógica? En un lenguaje, qué es una línea lógica? Con o sin comentarios? Construidas o Libradas al uso? Sep-05 Ing. de Software Planif. y Gestión 23

Métricas de Tamaño - Líneas de Código Necesidad de definir criterios de medición Ejemplo: Lenguaje Criterios para contar líneas en ese lenguaje Con/Sin Comentarios Libradas al Uso Discriminación de Líneas Reusadas Permite evaluar productividad en programación (productividad estable en LOC, independiente del lenguaje) - OJO con medir productividad individual! Sep-05 Ing. de Software Planif. y Gestión 24

Métricas de Tamaño - Líneas de Código productividad en proyectos iguales, en lenguajes distintos - Paradoja! C más productico que C++? Proyecto A: 80.000 LOC C Análisis Requs. Dis.Sist.: 2 meses/persona Dis.Det. Cod.PU-Int.: Prueba Sistema: 4 meses/persona 2 meses/persona Esfuerzo: 8 meses/pers. Productividad: 80.000/8= 10.000 Proyecto A : 42.000 LOC C++ Análisis Requs.Dis. Sist.: 2 meses/persona Dis.Det. Cod.PU-Int.: Prueba Sistema: 2 meses/persona 2 meses/persona Esfuerzo: 6 meses/pers. Productividad: 42.000/6= 7.000 Sep-05 Ing. de Software Planif. y Gestión 25

Métricas de Tamaño - Líneas de Código Ventajas: fácil de medir automáticamente a partir del código Desventajas: Para medir se precisa que el código esté construido Sujeto a variaciones personales/grupales y estilos de programación Depende del lenguaje: Dificultad para medir productos implementados en más de un lenguaje Difícil comparar proyectos en distinto lenguaje Sep-05 Ing. de Software Planif. y Gestión 26

Métricas de Tamaño - Puntos de Función Albrecht (IBM-1979) Objetivo: traducir en un Número el tamaño de la funcionalidad que brinda un producto de software Desde el Punto de vista del usuario Suma ponderada de características del producto: Nro. Entradas X 4 (3,4,6) Nro. Salidas X 5 (4,5,7) Nro. Consultas X 4 (3,4,6) Nro.Archivos X 10 (7,10,15) Nro.Interfaces externas X 7 (5,7,10) Sep-05 Ing. de Software Planif. y Gestión 27

Modelo para contar FP Frontera de la aplicación Contiene datos derivados EI EQ EO Archivos Lógicos Internos (ILF) Archivos de Interfaz Externos (EIF) 14 Características Generales de la Aplicación PF = PFSA x Factor de Ajuste Sep-05 Ing. de Software Planif. y Gestión 28

Métricas de Tamaño - Puntos de Función Normalizado por IFPUG Ponderadores según complejidad de c/característica (A,M,B) Criterios definidos para asignar complejidad a c/u Puntos de Función sin ajustar+ 14 criterios de ajuste + -35% PFA=PFSA * (0,65+ 0,01*sumat( ponderadores)) Pond=1 a 5 Ventajas: Se puede medir a partir de Requerimientos Funcionales Independiente del lenguaje Desventajas: Area de aplicación restringida (Sistemas de Información) Esfuerzo al medir Variabilidad en mediciones individuales-medidores expertos criticado por factores de ajuste Desarrollos más recientes: MK II FFP 1998 Estándar ISO 14143-1 Funct. Size Measurement Sep-05 Ing. de Software Planif. y Gestión 29

Estimación Para poder planificar se debe estimar: Tamaño Esfuerzo Costo Duración Formas de Estimación: Jucio de Expertos Métodos Algorítmicos Métodos basados en Aprendizaje Automatizado Sep-05 Ing. de Software Planif. y Gestión 30

Estimación- Juicio de Expertos Aplicable a Tamaño, Esfuerzo, Costo, Duración Analogía con antecedentes Descomposición y estimación de c/componente (WBS) pesimista, más probable, optimista Media calculada como si fuera distribución Beta: (p+4m+o)/6 σ como en Pert; se pueden considerar v.a. independientes? Consulta a varios expertos Técnica Delphi (formal) c/experto estima por separado valor medio se distribuye y se pide ajuste de estimación variantes con discusión previa o justificaciones distribuidas normalmente los resultados convergen rápidamente Sep-05 Ing. de Software Planif. y Gestión 31

Estimación -Juicio de Expertos Matriz de costos de Wolverton (TRW-1974) O=Old; N=New E=Easy; M=Medium; D=Difficult Dificultad Tipo OE OM OD NE NM ND Control 21 27 30 33 40 49 I/O 17 24 27 28 35 43 Pre/post proces. 16 23 26 28 34 42 Algoritmo 15 20 22 25 30 35 Data Manag. 24 31 35 37 46 57 Tiempo crítico 75 75 75 75 75 75 Sep-05 Ing. de Software Planif. y Gestión 32

Estimación - Metodos Algoritmicos de la forma: E=(a+b*S c ) m (X) donde a, b y c son constantes S es el tamaño estimado del producto m es un multiplicador de ajuste que depende del vector X de factores de ajuste Walston-Felix (1977): E=5.25 S 0.91 interés histórico, notar el valor del exponente menor que 1 Sep-05 Ing. de Software Planif. y Gestión 33

Estimación - COCOMO II E= b S c(y) m(x) Tamaño en SLOC (PFSA si se convierte) y: Elementos de escala para ajustar el exponente x: Multiplicadores de esfuerzo 3 modelos con distinto nivel de complejidad composición de aplicaciones (tamaño en Object Points) diseño temprano Post-Arquitectura Herramientas que soportan los 2 últimos modelos Estima Esfuerzo, Duración (y plantilla promedio) de Desarrollo, SIN contar Requerimientos Esfuerzo en Meses/Persona (160 horas/persona) Sep-05 Ing. de Software Planif. y Gestión 34

Estimación - COCOMO II (cont.) Ajustes de Escala: PREC -> Precedentes FLEX -> Flexibilidad del Desarrollo Requerimientos pre-establecidos Interfaces externas RESL -> Arquitectura/Resolución de Riesgos TEAM -> Cohesión del equipo PMAT -> Madurez del Proceso de SW Sep-05 Ing. de Software Planif. y Gestión 35

Estimación - COCOMO II (cont.) Multiplicadores de Esfuerzo (Post-Arquit.) RELY -> Confiabilidad requerida DATA -> Tamaño BD CPLX -> Complejidad RUSE -> Reuso de productos en pry y otros DOCU -> Documentación requerida TIME -> Carga de Procedadores STOR -> Carga de Memoria PVOL -> Volatilidad de la Plataforma Sep-05 Ing. de Software Planif. y Gestión 36

Estimación - COCOMO II (cont.) Multiplicadores de Esfuerzo (Post-Arquit.) ACAP -> Capacidad de Analistas AEXP -> Experiencia de Analistas PCAP -> Capacidad de Programadores PEXP -> Experiencia de Programadores LTEX -> Experiencia en Lenguaje y Herrs. TOOL -> Herramientas SITE -> Dispersión/Comunicaciones SCED -> Compresión/Estiramiento de Plazo Sep-05 Ing. de Software Planif. y Gestión 37

Estimación - Aprendizaje Automático Aprender de proyectos pasados predecir el costo (esfuerzo, duración) Técnicas de Data Mining: Construir un modelo (Redes Neuronales, Modelos Estadísticos) consistente con datos históricos usar el modelo para generar una predicción (estimación) del futuro Sep-05 Ing. de Software Planif. y Gestión 38

Recursos Humanos y Organización Para determinar el calendario del proyecto y estimar el esfuerzo y costo asociados, debemos saber: cuánta gente va a estar trabajando en el proyecto, qué tareas van a desarrollar y qué habilidades y experiencia deben tener. Quién hace qué y cómo se va a organizar el personal. Sep-05 Ing. de Software Planif. y Gestión 39

Roles y Características del Personal Capacidad para desempeñar una tarea interés en el trabajo experiencia con aplicaciones similares, herramientas, lenguajes, técnicas y ambiente de desarrollo entrenamiento (ajustar WBS) capacidad para comunicarse con otros y compartir la responsabilidad capacidad de supervisión Sep-05 Ing. de Software Planif. y Gestión 40

Estilos de Trabajo INTUITIVO INTROVERTIDO INTUITIVO INTROVERTIDO: Pregunta al resto Reconoce sentimientos RACIONAL INTROVERTIDO: Pregunta al resto Decide lógicamente INTUITIVO EXTROVERTIDO: Informa al resto Reconoce sentimientos RACIONAL EXTROVERTIDO: Informa al resto Decide lógicamente EXTROVERTIDO RACIONAL Sep-05 Ing. de Software Planif. y Gestión 41

Comunicaciones Dos personas 1 linea de comunicación Tres personas 3 lineas de comunicació Cuatro personas 6 lineas de comunicació Cinco personas : n personas 10 lineas de comunicació : n(n-1)/2 lineas de comunicación Sep-05 Ing. de Software Planif. y Gestión 42

Reuniones (problemas) El propósito es poco claro. Los participantes no están preparados. Gente clave está ausente o llega tarde. La conversación se aleja del propósito. Los participantes discuten, dominan la conversación, o no participan. Las decisiones tomadas en la reunión luego nunca se hacen efectivas. A una reunión de 8 personas durante 2 horas significa un esfuerzo de 16 horas/persona Sep-05 Ing. de Software Planif. y Gestión 43

Reuniones (soluciones) Definir objetivo, agenda y duración Los participantes deben conocerlos con antelación suficiente Definir quiénes deben (y no deben) participar Asignar el rol de coordinador o moderador para ceñirse a la agenda Asginar el rol de secretario, responsible por el acta, la que se debe distribuir a los participantes Sep-05 Ing. de Software Planif. y Gestión 44

Manejo de conflictos Qué opinar de un proyecto en el que no aparece ningún conflicto? Conflicto: no siempre es malo Puede ser estimulante Promueven la creatividad A veces hay que crearlos (abogado del diablo) para evaluar riesgos El manejo de conflictos es clave para el éxito de un proyecto Sep-05 Ing. de Software Planif. y Gestión 45

Estilos de manejo de conflictos Evitarlo Estilo Nivel de Eficacia No lo resuelve (reaparece) Suavizarlo Solución de compromiso Forzar la resolución Enfrentarlo/buscar solución al problema Solución corto plazo, No lo resuelve Solución, pero todos pierden algo Solución, pero daña las relaciones entre las partes Se logra la mejor solución Sep-05 Ing. de Software Planif. y Gestión 46

Conflictos -Criterios generales No responder a posibles agresiones Oír y comunicarse efectivamente Promover la apertura, expresión emocional y las nuevas ideas Expresar sentimientos como tales y no como hechos Minimizar conflictos potenciales que entorpecen el proyecto Estimular conflictos cuando ello aumenta la creatividad y la innovación Elegir la estrategia para enfrentarlo teniendo en cuenta la importancia, urgencia y consecuencias posibles Conviene encontrar soluciones del tipo ganar-ganar Sep-05 Ing. de Software Planif. y Gestión 47

Organización del Equipo de Proyecto Los miembros del equipo se organizan para generar productos de calidad de manera eficiente. La elección de una estructura apropiada depende de: la formación y estilos de trabajo de los miembros del equipo la cantidad de integrantes del equipo los estilos de dirección de los clientes y desarrolladores Sep-05 Ing. de Software Planif. y Gestión 48

Chief Programmer team Chief programmer Assistant chief programmer Senior rogrammers Librarian Administration Test team Junior rogrammers Sep-05 Ing. de Software Planif. y Gestión 49

Enfoque no egoísta (egoless) Todos igualmente responsables Las críticas se hacen al producto o resultado, no a las personas todos los miembros del equipo participan en las decisiones (democrático) Sep-05 Ing. de Software Planif. y Gestión 50

Comparación de Estructuras Organizativas Muy Estructuradas Certidumbre Repetición Proyectos Grandes Poco Estructuradas Incertidumbre Nuevas Técnicas o Tecnología Proyectos Pequeños Creatividad Sep-05 Ing. de Software Planif. y Gestión 51

Construcción del equipo Asignar el personal Asignar/ajustar los roles (y responsabilidades Definir/comunicar los objetivos Motivar Facilitar la comunicación entre los integrantes Brindar retroalimentación respecto a los logros Sep-05 Ing. de Software Planif. y Gestión 52

Ciclo de vida de un equipo Integración Tormenta Aceptación Etapa productiva Desintegración Sep-05 Ing. de Software Planif. y Gestión 53

Evaluación de Factibilidad Responder a la pregunta: Vale la Pena? Estudio de Alternativas Factibilidad (para alguna o varias alternativas) Técnica ( es posible? qué se precisa para lograrlo?) => Recursos, Plazo Económica ( cuánto cuesta? flujos financieros?) Operativa ( habrá algo que haga que el sistema no funcione?). Ej.: cultura de la org. Análisis Costo/Beneficio Técnicos Clientes Sep-05 Ing. de Software Planif. y Gestión 54

Eval. de Factibilidad (cont.) Frecuentemente el Estudio de Factibilidad es previo a un proyecto (ante-proyecto, pre-factibilidad) Puede ser la etapa inicial A lo largo del proyecto, en puntos de control preestablecidos, la pregunta se vuelve a formular como: vale la pena seguir? Sep-05 Ing. de Software Planif. y Gestión 55

Gestión de Riesgos Un riesgo es un evento no deseado que tiene consecuencias negativas. Gestión de Riesgos: entenderlos y controlarlos En un proyecto de software: genéricos: comunes a todo proyecto de software específicos: vulnerabilidades específicas de un proyecto dado. Sep-05 Ing. de Software Planif. y Gestión 56

Evaluar un Riesgo Evaluar los elementos: Impacto o pérdida asociada si ocurre Probabilidad de que suceda Severidad o Exposición: (Severidad= impacto * probabilidad Sep-05 Ing. de Software Planif. y Gestión 57

Reducción del Riesgo Control de Riesgo: conjunto de acciones tomadas para reducir o eliminar un riesgo Se justifica dependiendo de: Nivel de Reducción= (severidad antes de reducciónseveridad después de reducción) / (costo de reducción) Si nivel de reducción<1 no valdrá la pena Registrar las decisiones en un plan de gestión de riesgos. Sep-05 Ing. de Software Planif. y Gestión 58

Actividades en G.de Riesgos Según Rook, 1993 Evaluar Riesgos Gestión de Riesgos Control de Riesgps Periódicamente, o en hitos del proyecto Identificar Riesgos Analizar Riesgos Priorizar Riesgos No se pueden atender todos Impacto y/o Reducir Probabilidad Incertidumbre Reducir Riesgos Planear Solución de Riesgos Qué hacer si ocurre Resolver Riesgos Lista de Comprobación Descomposición Análisis de Supuestos Análisis de Procs. de Decisi Dinámica de Sistemas Modelos de Desempeño Modelos de Costo Análisis de Redes Análisis de Decisiones Factores deriesgo en Calid Severidad de Riesgos Reducción Compuesta Obtener Información Evitar un Riesgo Transferirlo Evaluar Nivel de Reducció Desarrollar el Proceso Planear elemento de Ries Plan integrado Una vez ocurrido Mitigar Riesgo Monitoreo e Informes Reevaluar Riesgos Sep-05 Ing. de Software Planif. y Gestión 59

Top 10 Risk Items (Boehm) 1989 1. Limitaciones de Personal 2. Calendario y Presupuesto 3. Funciones equivocadas 4. Interfaz de usuario no adecuada 5. Gold plating (preciosismo) 6. Cambios en Requerims. 7. Suministros externos 8. Tareas externas 9. Desempeño de Tiempo Real 10. Forzar ciencia de computación 1995 1. Limitaciones de Personal 2. Calendario, Presupuesto, Procesos 3. COTS, componentes externos 4. Requerimientos inadecuados 5. Interfaz de usuario inadecuada 6. Arquitectura,desempeño, calidad 7. Cambios en Requerims. 8. Software Heredado 9. Tareas externas 10. Forzar ciencia de computación Sep-05 Ing. de Software Planif. y Gestión 60.

Riesgos y el Plan Actividades de Reducción de Riesgos ->WBS Considerarlas en plazo, esfuerzo, costo Prever un colchón en el plazo 8% de duración para proyectos normales (no planificar con el enfoque si todo sale bien ) más si el riesgo de pasarse de la fecha estipulada para el proyecto lo justifica Sep-05 Ing. de Software Planif. y Gestión 61

Gestión de la Calidad Gestión de la Calidad Planear la Calidad Responsabilidades Estándares Procedimientos Puntos de Control Asegurar la Calidad Revisiones Auditorías Controlar a Calidad Verificar Validar WBS Sep-05 Ing. de Software Planif. y Gestión 62

Gestión de la Configuración Gestión de los componentes de un producto: Registro y control de los cambios de un producto y de sus componentes Coordinación fuente-ejecutable Gestión de los entregables de un proyecto: Registro y control de sus cambios Asegurar su disponibilidad (respaldos) Generación y Control de la Línea Base o de Referencia WBS Sep-05 Ing. de Software Planif. y Gestión 63

Comunicación entre los Involucrados Patrocinador, Cliente, Usuario, Desarrolladores, Otros Interesados-Involucrados Procedimientos de comunicación periódicos, hitos formales, no formales revisiones conjuntas (con Cliente, Usuarios, etc.) Manejo de Expectativas de los interesados Decisiones por personas autorizadas y con conocimiento de causa WBS Sep-05 Ing. de Software Planif. y Gestión 64

Plan del Proyecto Elaboramos un documento llamado Plan del Proyecto para: comunicar el análisis de riesgos y la gestión de riesgos estimaciones de costo y duración calendario de actividades e hitos del proyecto organización al Cliente y al equipo de trabajo Sep-05 Ing. de Software Planif. y Gestión 65

Puntos de un buen plan de proyecto (1) Alcance Descripción técnica del sistema propuesto Estándares, procedimientos y técnicas y herramientas propuestas Calendario Organización del equipo de proyecto Plan de gestión de RRHH Plan de entrenamiento Sep-05 Ing. de Software Planif. y Gestión 66

Puntos de un buen plan de proyecto (2) Plan de Aseguramiento de la Calidad Plan de Gestión de la Configuración Plan de Verificación y Validación Plan de Gestión de Riesgos Procedimientos para la gestión de cambios Plan de Comunicaciones a los interesados Plan de Mantenimiento Sep-05 Ing. de Software Planif. y Gestión 67

Registro y Control de Avance Registro del avance: Actividades cumplidas (entregables obtenidos) Actividades empezadas Cómo considerar actividades a medias? Riesgo del sindrome del 90%, granularidad del plan Cuidado con los significados,ej. programa terminado = terminada la codificación? revisado por un par? pasó la prueba unitaria? pronto para entrar en explotación? Sep-05 Ing. de Software Planif. y Gestión 68

Actividad A B C D Registro y Control de Avance(2) - Gantt A y B están atrasadas, C adelantada, y el proyecto? Está costando más o menos de lo previsto? Sep-05 Ing. de Software Planif. y Gestión 69

Registro y Control de Avance(3) Diagrama de Evolución de Gastos Acumulados $ Planificado Real Se lleva gastado más de lo previsto a la fecha, pero cuál fue el avance logrado? se va a gastar más o menos de lo previsto? Sep-05 Ing. de Software Planif. y Gestión 70 t

Enfoque del Valor Ganado Modelo implícito en diagrama de Gantt nos dificulta determinar si el proyecto está o no atrasado Diagrama de evolución de gastos permite ver gastado respecto a lo planificado gastar en el tiempo, pero sin relacionarlo con los logros planificados El enfoque del valor ganado corresponde a un modelo en el que se unifican todas las actividades planificadas llevándolas a $ por su costo planificado Tenemos un plan de gastos que coincide con el plan de logros (lo que ganamos) A posteriori es posible controlar si se logró el avance previsto y si costó lo previsto Se pueden obtener: % de avance, días de atraso Sep-05 Ing. de Software Planif. y Gestión 71

Planificado Registro y Control de Avance(4) - Valor Ganado Valor Ganado (Valor presupuestado del avance logrado) Costo Real en t 0 $ Costo Planificado Final (CPF) Costo Final de acuerdo a tendencia(ct) Valor Ganado en t 0 es el previsto para t 1 0 t 1 t 0 Fin Planificado (FP) Fin de acuerdo a tendencia (FT) t Sep-05 Ing. de Software Planif. y Gestión 72

Registro y Control de Avance(5) - Valor Ganado Costo Real: CR Valor Ganado: VG Valor Planificado: VP Cost Performance Index CPI = VG/CR Schedule Performance Index SPI = VG/VP CT=CPF/CPI FT=FP/SPI Permiten detectar desviaciones en costo y plazo en etapas tempranas del proyecto (15-20%) Adecuado para proyectos grandes o limitados por recursos (muchas actividades que podrían desarrollarse en paralelo) Sep-05 Ing. de Software Planif. y Gestión 73