GESTIÓN DE PROYECTOS DE SOFTWARE

Transcripción

1 GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de personal, esfuerzo y costo que se requerirá para terminar todas las actividades y productos asociados con el proyecto. El tamaño del producto a desarrollar es una de las primeras tareas en la gestión del proyecto. El tamaño se define como la cantidad de código fuente, especificaciones, casos de prueba, documentación del usuario y otros productos tangibles que son salida del proyecto, éste se basa principalmente en experiencias anteriores. 1

2 GESTIÓN DE PROYECTOS DE SOFTWARE EL SEGUIMIENTO de proyectos es la recolección de datos y su acumulación sobre recursos consumidos y costos generados asociados con un proyecto. La medición en los proyectos de SW es fundamental para la mejora de la productividad, el costo y la calidad del producto final. ÁMBITO DEL SOFTWARE. El ámbito identifica las funciones primordiales que debe llevar a cabo el software y, lo que es más importante, intenta limitar esas funciones de manera cuantitativa. El ámbito describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad. 2

3 PLANIFICACIÓN TEMPORAL Y SEGUIMIENTO DEL PROYECTO CAUSAS DE LOS RETRASOS EN LOS PROYECTOS DE SOFTWARE Una fecha límite de entrega poco realista, establecida por alguien que no pertenece al grupo de ingeniería de software e impuesta a los gestores y profesionales del grupo. No se reflejan los cambios de los requisitos del cliente en la planificación temporal. Una subestimación honesta de la cantidad de esfuerzo y/o el número de recursos que serán necesarios para hacer el trabajo. Riesgos no considerados (de los reales) al comienzo del proyecto. Dificultades no previstas de orden técnico y/o humano. Falta de comunicación entre el equipo del proyecto. Falta de reconocimiento por parte de la gestión del proyecto de su retraso y falta de medidas para corregir el problema (p.e.: negociar entregas parciales, basarse en estadísticas). 3

4 PLANIFICACIÓN TEMPORAL Disciplina que incluye un conjunto de actividades que distribuye el esfuerzo estimado a lo largo de la duración prevista del proyecto, asignando el esfuerzo a las tareas específicas de la ingeniería de software. PRINCIPIOS BÁSICOS Compartimentación: Debe dividirse en un número de actividades y tareas manejables. Interdependencia: Algunas tareas deben ocurrir en una secuencia determinada (no pueden comenzar hasta que el resultado de otras no esté disponible), otras pueden darse en paralelo (pueden ocurrir independientemente). Asignación de tiempo: asignar unidades de trabajo (p.e: personas-día). Dar fecha de inicio y de final y si el trabajo se hará a tiempo total o parcial. Validación de esfuerzo: Verificar que el esfuerzo asignado esté acorde con la cantidad de gente disponible. Responsabilidades definidas: cada tarea debe tener un responsable concreto. Resultados definidos: Los resultados deben ser concretos (es decir, tangibles). Hitos definidos: un hito es el conjunto de uno o más productos cuya calidad se ha revisado y se ha aceptado. Superado ese hito, se considera al proyecto en una etapa siguiente de maduración hacia la meta. 4

5 WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo) Herramienta de Comunicación del Trabajo a realizar en un Proyecto. Una de las primeras tareas en el proceso de planeación de un proyecto es la definición de su alcance, en términos de la delimitación del trabajo a realizar para cumplir con los objetivos y desarrollar los entregables del proyecto. Una herramienta útil para hacer esta tarea es la WBS o Work Breakdown Structure. "La WBS corresponde a una división jerárquica y de multinivel del trabajo a realizar, que cubrirá los requerimientos del proyecto". PMBOK, Responde a la pregunta: Que va a ser desarrollado a través del proyecto? 5

6 WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo) Herramienta de Comunicación del Trabajo a realizar en un Proyecto. Esta técnica distribuye el trabajo en paquetes que deben ser definidos para facilitar la administración y el seguimiento del alcance del proyecto. Permite la representación gráfica del trabajo a ser realizado y por ende, una comprensión rápida de la distribución de este trabajo. Esto facilitará la presentación del proyecto a los diferentes stakeholders del proyecto, incluyendo el nivel ejecutivo. La WBS será también la base para la asignación de recursos del proyecto así como para el análisis de riesgos, costos y cronograma. 6

7 7

8 WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo) Herramienta de Comunicación del Trabajo a realizar en un Proyecto. Pasos para su creación 1. Identificar los entregables del trabajo a realizar 2. Establecer, opcionalmente, las cuentas de control 3. Organizar los paquetes de trabajo de alto nivel 4. Descomponer cada paquete en distintos niveles, cada uno de los cuales tiene un nivel mayor de detalle 5. Verificar que el grado de descomposición es el adecuado para realizar una gestión eficaz del Alcance 8

9 WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo) Herramienta de Comunicación del Trabajo a realizar en un Proyecto. Reglas 1. Regla del 100%: contemple todos los entregables, en términos de trabajo a realizarse, incluyendo la administración del proyecto. 2. No existen reglas que dicten que cada elemento WBS deba descomponerse al mismo nivel. 3. La estructura de la WBS se basa en los entregables del proyecto, NO en la temporización o la secuenciación del mismo. 4. La WBS define las relaciones lógicas entre todos los componentes del proyecto. 5. Todos los elementos de WBS están orientados a entregables. 6. Todos los elementos deben ser nombres. 9

10 WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo) Herramienta de Comunicación del Trabajo a realizar en un Proyecto. Errores en la creación de un WBS (*) ERROR #1: Utilizar la WBS como un listado de tareas. El propósito de la WBS es tener una visión clara del alcance global del proyecto que nos permita detectar las áreas relacionadas a cualquier cambio a lo largo del mismo. Si nuestra WBS es un simple listado de tareas, perderemos esta visión global del alcance. ERROR #2: Crearla según la estructura organizacional. Si elaboramos la WBS según la estructura de la empresa, estamos focalizando el análisis en los recursos que realizan el trabajo en vez de los entregables. Esto añade tareas que no son necesarias para alcanzar los requisitos de los entregables. La estrategia correcta es realizar la WBS desde el punto de vista de las salidas (entregables), no de las entradas. (*) Listado de los típicos errores en la creación de un WBS según Josh Nankivel 10

11 WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo) Herramienta de Comunicación del Trabajo a realizar en un Proyecto. Errores en la creación de un WBS (*) ERROR #3: Organizarla según la temporalidad del proyecto No es correcto organizar la WBS temporalmente, ya que no se enumeran entregables o servicios, sino simplemente periodos de tiempo. Realizarla según el cronograma lleva a imprevistos y vacíos en el alcance. En algunos sectores, especialmente en aquellos relacionados con las TIC, suele ser habitual pero organizada por fases. ERROR #4: Falta de trazabilidad de la WBS Debe ser la referencia de las relaciones entre todos los entregables del proyecto. Al no establecer esas relaciones se dificulta el seguimiento de los entregables. (*) Listado de los típicos errores en la creación de un WBS según Josh Nankivel 11

12 WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo) Herramienta de Comunicación del Trabajo a realizar en un Proyecto. Errores en la creación de un WBS (*) ERROR #5: No utilizarla como recurso del control de los cambios. Para cualquier propuesta de cambio la WBS debe ser la herramienta que nos permita ver el impacto que tiene en el proyecto. ERROR #6: El NO incluir las actividades de soporte. La WBS debe incluir todo el alcance del proyecto y no solamente las entregables tangibles. Por lo tanto no debemos olvidar tareas de soporte como podrían ser: gestión del proyecto, gestión administrativa y financiera, etc. ERROR #7: Darla por terminada (prematuramente) La WBS la creamos para que se mantenga viva durante todo lo largo del proyecto. Será útil en la medida que se le actualicen todos los cambios que surjan durante todo el ciclo de vida del proyecto. (*) Listado de los típicos errores en la creación de un WBS según Josh Nankivel 12

13 GRÁFICOS DE TIEMPO. Cuando se crea una planificación, el planificador empieza un conjunto de tareas (la estructura de descomposición del trabajo). Si se emplean herramientas automáticas, la descomposición del trabajo se maneja como una red de tareas o esquema de tareas. El esfuerzo, duración y fecha de inicio son las entradas de cada tarea. Además, se asignan las tareas a individuos específicos. Como consecuencia de esta entrada, se genera un gráfico de tiempo, también denominado Gráfico Gantt. Se puede desarrollar un gráfico de tiempo para todo el proyecto. Alternativamente, se pueden desarrollar diferentes gráficos para cada función del proyecto o para cada individuo que trabaje en el proyecto. La Figura ilustra el formato básico de un gráfico de tiempo. Todas las tareas del proyecto (para ámbito del concepto) se listan en la columna de la izquierda. Las barras horizontales indican la duración de cada tarea. Cuando aparecen múltiples barras al mismo tiempo en la planificación temporal, implican concurrencia de tareas. Los rombos indican hitos. 13

14 EL PLAN DE PROYECTO. Proporciona información básica de costes y planificación temporal que será empleada a lo largo del proceso de software. Es un documento relativamente breve dirigido a una audiencia diversa. Debe: 1. Comunicar el ámbito y recursos a los gestores del software, personal técnico y al cliente. 2. Definir los riesgos y sugerir técnicas para evitarlos. 3. Definir los costes y la planificación temporal para la revisión de la gestión. 4. Proporcionar un enfoque general del desarrollo del software para todo el personal relacionado con el proyecto. 5. Describir cómo se garantizará la calidad y se gestionan los cambios. No es un documento estático. El equipo del proyecto consulta el Plan repetidamente (para actualizar riesgos, estimaciones, planificaciones e información relacionada) a la vez que el proyecto avanza y se le conoce más. 14

15 Seguimiento de la planificación temporal. La planificación temporal del proyecto le proporciona al gestor un mapa de carreteras. Si se ha desarrollado apropiadamente, define las tareas e hitos que deben seguirse y controlarse a medida que progresa el proyecto. El seguimiento se puede hacer de diferentes maneras: 1. Realizando reuniones periódicas del estado del proyecto en las que todos los miembros del equipo informan del progreso y de los problemas; 2. Evaluando los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniería del software; 3. Determinando si se han conseguido los hitos formales del proyecto en la fecha programada (Hitos: son los rombos mostrados en la Figura de la diapositiva 13); 4. Comparando la fecha real de inicio con las previstas para cada tarea del proyecto listada en la tabla del proyecto; 5. Reuniéndose informalmente con los profesionales del software para obtener sus valoraciones subjetivas del progreso hasta la fecha y los problemas que se avecinan. 15

16 ANALISIS DE VALOR GANADO El valor ganado es una medida del progreso. Nos permite evaluar el porcentaje de realización de un proyecto utilizando el análisis cuantitativo más que la opinión particular que de ello tengamos. EJEMPLO. Ud. es un gestor de proyectos de software y se le ha pedido que calcule estadísticas del valor ganado para un proyecto de software sencillo. El proyecto tiene 56 tareas planificadas que se estima que necesiten 582 personas-día para realizarlas (Presupuesto a la terminación). Al tiempo que ha sido solicitado para realizar el análisis del valor ganado, se han completado 12 tareas. Sin embargo, la planificación temporal del proyecto indica que se deberían haber completado 15 tareas. Están disponibles los siguientes datos de planificación (en personas-día): Tarea EP ER Calcule: Índice de Desempeño (eficiencia) de Planificación (IDP) La varianza de la planificación. El porcentaje planificado para terminación. El porcentaje completado. Índice de Desempeño (eficiencia) del coste, IDC La varianza de coste para el proyecto. 16

17 Presupuesto a la terminación PAT 582 personas-día Coste Presupuestado del Trabajo Planificado CPTP 156,5 personas-día Coste Presupuestado del Trabajo Realizado CPTR 126,5 personas-día Índice de Desempeño (eficiencia) de Planificación IDP (CPTR/CPTP) 0,8083 Progreso del 80.83% respecto de lo planeado Varianza de la planificación VP = CPTR CPTP -30 personas-día Negativo. Está por debajo de lo planeado (RETRASADO) Porcentaje planificado para terminar CPTP/PAT 0,2689 (lo que debería estar) Porcentaje completado CPTR/PAT 0,2174 (lo que realmente está) DIFERENCIA -0,0515 retrasado Coste real de trabajo realizado CRTR 127,5 personas-día Índice de Desempeño (eficiencia) del coste IDC = CPTR/CRTR 0,9922 Varianza del coste VC = CPTR - CRTR -1 Está recibiendo 0,99 por cada [dólar] ESTÁ EXCEDIDO EN PRESUPUESTO 17

18 NOMBRE FÓRMULA INTERPRETACIÓN Índice de Desempeño (eficiencia) de Planificación (IDP) CPTR / CPTP Progreso del % respecto de lo planeado Varianza de la planificación CPTR CPTP NEGATIVO está retrasado, POSITIVO está adelantado Índice de Desempeño (eficiencia) del coste (IDC) Varianza del coste CPTR / CRTR CPTR - CRTR Está recibiendo [dólar] por cada [dólar] NEGATIVO está por encima del presupuesto, POSITIVO está dentro del presupuesto FIN DEL DOCUMENTO 18