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.
LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual.
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.
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).
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.
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, 2004.
Responde a la pregunta: ¿Que va a ser desarrollado a través del proyecto?
WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo)
Herramienta de Comunicación del Trabajo a realizar en un Proyecto.
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.
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
WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo)
Herramienta de Comunicación del Trabajo a realizar en un Proyecto.
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.
Errores en la creación de un WBS (*)
WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo)
Herramienta de Comunicación del Trabajo a realizar en un Proyecto.
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”.
Errores en la creación de un WBS (*)
WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo)
Herramienta de Comunicación del Trabajo a realizar en un Proyecto.
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.
Errores en la creación de un WBS (*)
WBS: Work Breakdown Structure (EDT: Estructura de Desglose de Trabajo)
Herramienta de Comunicación del Trabajo a realizar en un Proyecto.
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.
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.
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.
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.
ANALISIS DE VALOR GANADO
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 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
EP 12.0 15.0 13.0 8.0 9.5 18.0 10.0 4.0 12.0 6.0 5.0 14.0 16.0 6.0 8.0
ER 12.5 11.0 17.0 9.5 9.0 19.0 10.0 4.5 10.0 6.5 4.0 14.5 - -
-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
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.
Presupuesto a la terminación PAT 582personas-día Coste Presupuestado del Trabajo Planificado CPTP 156,5personas-día Coste Presupuestado del Trabajo Realizado CPTR 126,5personas-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 -30personas-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,5personas-día
Índice de Desempeño (eficiencia) del coste IDC = CPTR/CRTR 0,9922 Está recibiendo 0,99 por cada [dólar]
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) CPTR / CRTR
Está recibiendo _____ [dólar] por cada [dólar]
Varianza del coste CPTR - CRTR
NEGATIVO está por encima del presupuesto, POSITIVO está dentro del presupuesto
