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. EL SEGUIMIENTO de proyectos es la recolección de datos y su acumulación sobre recursos consumidos, 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. 1

2 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). 2

3 PLANIFICACIÓN TEMPORAL Y SEGUIMIENTO DEL PROYECTO La planificación temporal de un proyecto de software se refiere a una 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 (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 (claramente identificables, 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. 3

4 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. 4

5 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 5

6 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 6

7 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? Esta técnica distribuye el trabajo en paquetes que deben ser definidos para facilitar la administración y el seguimiento del alcance del proyecto. Adicionalmente, 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 del proyecto. 7

8 8

9 9

10 10

11 Concepto de la EDT Según la publicación Practice Standard for Work Breakdown Structures, editada por el PMI, el concepto de la EDT se utiliza en la gestión de proyectos para: 1. Definir el alcance del proyecto en términos de los entregables y la descomposición de tales entregables en paquetes de trabajo. 2. Dependiendo del método de descomposición del trabajo utilizado, la EDT puede también definir el ciclo de procesos y los entregables de cada fase. Esta descomposición del alcance del proyecto permite balancear la necesidad de la gestión del proyecto de controlar el proyecto con un nivel adecuado de detalle. 3. Dotar al equipo de dirección del proyecto con un marco de referencia adecuado para la toma de decisiones sobre el avance del proyecto. 4. Facilitar la comunicación entre el director de proyecto y los interesados a lo largo de la vida del proyecto. LA EDT permite comunicar el alcance del proyecto, las relaciones de dependencias entre las diferentes fases y trabajos y el nivel de riesgos, a la vez que facilita el control del presupuesto y el avance del cronograma. 5. La EDT es un elemento clave en los demás procesos del proyecto. 11

12 Características de la Estructura de Desglose de Trabajo (EDT) 1. La EDT define y organiza la estructura de trabajo total del proyecto. 2. Cada actividad de la EDT tiene un entregable tangible 3. La EDT subdivide el trabajo del proyecto en porciones más pequeñas y fáciles de manejar. 4. Cada nivel descendente representa una definición cada vez más detallada del trabajo del proyecto, tales componentes de más bajo nivel se denominan paquetes de trabajo. 5. El trabajo planificado comprendido en los paquetes de trabajo puede ser programado, supervisado, controlado y sus costos estimados. 6. La EDT es la representación de una estructura jerárquica. La EDT puede ser estructurada de varias maneras. Las más comunes son: Orientada a los productos entregables: Productos, Área física Orientada a la programación: Tarea o actividad Secuencial (Fases) Orientada a los recursos: Disciplinas, Unidades administrativas 12

13 Pautas para desarrollar una EDT: Según la publicación Practice Standard for Work Breakdown Structures Second Edition, 2001, los siguientes pasos describen el proceso general para definir la EDT Paso 1: Identificar el producto(s) final del proyecto, que debe entregarse para alcanzar el éxito del proyecto. Se recomienda una revisión completa de alcance del proyecto para asegurar la consistencia entre los EDT y los requerimientos del proyecto. Paso 2: Definir los entregables principales del producto; los entregables predecesores necesarios para el proyecto pero que por sí mismos no satisfacen una necesidad comercial (por ejemplo, una especificación de diseño). Paso 3: Descomponer los entregables principales a un nivel de detalle apropiado que permita gestionar con eficacia y eficiencia. Paso 4: Revisar y refinar la EDT hasta que los involucrados con el proyecto estén de acuerdo que el proyecto planificado pueda completarse satisfactoriamente y que la ejecución y el control producirán los resultados deseados. 13

14 Por tanto, surge otra pregunta: Hasta cuándo seguir subdividiendo? Las divisiones del trabajo en diferentes niveles, dependerán de varios factores como: La complejidad del Trabajo. En este caso es favorable subdividir las tareas hasta un nivel de detalle que identifique la secuencia, paralelismo y demás relaciones de precedencia entre las actividades que componen un flujo lógico de ejecución. El equipo de trabajo asociado al proyecto. El caso en el que es necesario obtener una salida o producto, asignada a un contratista o una parte del equipo, que tiene un costo especifico, es una buena razón para agrupar sus actividades en un paquete de trabajo. 14

15 La criticidad de una tarea. En la medida en que una tarea sea crítica para el proyecto, porque es la entrada a otras tareas o porque de su salida, depende la continuación de la ejecución del proyecto, debería ser una tarea definida en términos de un paquete de trabajo. En el PMBOK se recomienda que un paquete de trabajo tenga un único punto de responsabilidad. La estructura de los productos, entregables o servicios creados por el proyecto. Los diferentes niveles de la WBS deberán incluir los componentes requeridos para conformar el producto, entregable o salida final. En síntesis, la WBS por sus características, facilita el entendimiento del trabajo a realizar en un proyecto y permite a los diferentes stakeholders, tener una visión global de trabajo que se va a realizar. De una buena definición del WBS dependerá el entendimiento de Cuál es el alcance del proyecto, de parte de todos los implicados. 15

16 Consideraciones importantes sobre WBS El WBS es la definición más clara del alcance del proyecto: lo que está en el WBS se construirá en el proyecto, lo que no está en el WBS no es parte del alcance. Lo que se consigue con el WBS es que cualquier tarea o paquete de trabajo estén relacionados a un entregable del proyecto. Esto tiene que ver con la productividad en el proyecto, de tal manera que al ejecutar una tarea, construimos un entregable y para ello es que la realizamos. Aún más: los proyectos se miden por el avance de los entregables. Qué cosas no tiene el WBS en su forma pura? No tiene nombres (propios): el WBS no es el cronograma, todavía no tiene nombres asignados a los entregables, subentregables o actividades. No tiene fechas: de la misma forma, todavía no tiene ninguna fecha para lo que hay que construir. El WBS es el qué del proyecto, no es el quién ni el cuándo. No tiene dependencias: no es el diagrama de red del proyecto, no se define todavía la secuencia de tareas en el WBS. 16

17 GRÁFICOS DE TIEMPO. Cuando se crea una planificación temporal de un proyecto de software, el planificador empieza un conjunto de tareas (la estructura de descomposición del trabajo o Work Breakdown Structure). 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 de un gráfico de tiempo. Muestra una parte de la planificación temporal de un proyecto de software que enfatiza la tarea de ámbito del concepto para un nuevo producto de software de procesador de textos. 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. 17

18 18

19 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 (los rombos mostrados en la Figura) en la fecha programada; 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. 19

20 EL PLAN DE PROYECTO. El plan de proyecto de software se produce a la culminación de las tareas de planificación. Proporciona información básica de costes y planificación temporal que será empleada a lo largo del proceso de software. El plan del proyecto 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 FIN DEL DOCUMENTO 20