Verónica A. Bollati
Ingeniería del Software de Gestión
Tema IX:
Gestión de Proyectos:
Planificación.
Índice
Introducción
Ámbito del Software
Recursos
Introducción
Planificación de proyectos. Definición:
◦
Conjunto de actividades previas a la puesta en
marcha del proyecto
Incluye:
◦
Estimación
◦
Análisis y gestión del riesgo
◦
Planificación temporal y seguimiento del
proyecto
◦
Definición de la calidad del producto
Introducción
Objetivo de la planificación
◦
Proporcionar un marco de trabajo que
permita al gestor hacer estimaciones
razonables de recursos, coste y planificación
temporal
Estimación
◦
Antes de comenzar 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
[Pressman, 2010]
Gestión de Proyectos:
Observaciones sobre la estimación
◦
Estimación Riesgo Incertidumbre ……
Error!
◦
Factores que influyen en la estimación:
Complejidad del proyecto
Tamaño del proyecto experiencia en proyectos similaresMedida relativa que depende de la
+ tamaño + interdependencia + complejidad de la descomposición + variabilidad de los valores que toman
los factores de estimación
Gestión de Proyectos:
Observaciones sobre la estimación
◦
Incertidumbre estructural
Grado de definición de requisitos Facilidad de subdivisión de funciones Información a procesar
Disponibilidad de información histórica
◦
Riesgo
= grado de incertidumbre de la fiabilidad de
las estimaciones cuantitativas
◦
La estimación es una utilidad, no un producto
Puede (debe) revisarse periódicamente
Gestión de Proyectos:
Recordar la ley de Murphy:
Lo que puede ir mal irá
mal, y si hay más cosas
que puedan fallar, más
cosas fallarán
.
Gestión de Proyectos:
Agenda
Introducción
Ámbito del Software
Recursos
Primera actividad de la planificación del proyecto
Objetivo:
delimitar
Describe:
◦
Control y datos a procesar. Funcionamiento habitual
◦
Funciones principales/importantes
◦
Rendimiento y restricciones
◦
Fiabilidad
◦
Interfaces con otros sistemas
[Pressman, 2010]Gestión de Proyectos:
Obtención de la información necesaria para
el ámbito:
◦
Reunión preliminar cliente-ingeniero de
software (analista)
◦
Preguntas de contexto libre (analista)
◦
Personas interesadas en la solución
◦
Preguntas para entender el problema y que el
cliente describa (esboce) la solución
◦
Preguntas sobre la efectividad del primer
encuentro
Gestión de Proyectos:
Viabilidad:
factibilidad
del software
◦
Tecnología:
¿es factible el proyecto técnicamente?
◦
Financiación:
¿puede realizarse a un coste asumible?
◦
Tiempo:
¿pueden los proyectos adelantarse a los de la
competencia?
◦
Recursos:
¿la organización cuenta con recursos suficientes
para tener éxito? Gestión de Proyectos:
Ejemplo.
Software de un teléfono móvil
◦
Control y datos a procesar. Funcionamiento habitual
Se enciende el móvil y se introduce el PIN.
A partir de ese momento pueden realizarse llamadas marcando directamente un número o seleccionándolo de la agenda. También se pueden recibir llamadas.
Si el número de la persona que llama está almacenado en la
agenda, en pantalla aparece el nombre de la persona que llama. En caso contrario aparece el número de la persona que llama.
También se pueden enviar y recibir mensajes.
Cuando se recibe una llamada, suena una melodía o tono.
Cuando se recibe un mensaje suena una melodía o tono, que puede ser diferente al de la llamada.
Gestión de Proyectos:
Ejemplo.
Software de un teléfono móvil
◦
Funciones principales/importantes
Introducir PIN
Realizar llamadas
Enviar mensajes
Almacenar teléfonos en la agenda
Seleccionar melodía o tono para llamada
Seleccionar melodía o tono para mensaje
Gestión de Proyectos:
Ejemplo.
Software de un teléfono móvil
◦
Rendimiento y restricciones
Habituales
◦
Fiabilidad
Habitual
◦
Interfaz con otros sistemas
Operador de telefonía
Gestión de Proyectos:
Estimación – Ámbito del Software
Índice
Introducción
Ámbito del Software
Recursos
Segunda tarea en la planificación del
desarrollo de SW
◦
Estimación de los recursos requeridos para
acometer el esfuerzo de desarrollo de
software
Gestión de Proyectos:
Recursos del Proyecto
Personal
Componentes
software reutilizables
Entorno de desarrollo
[Pressman, 2010] Gestión de Proyectos:Estimación – Recursos
Especificación de recursos
◦
Descripción del recurso
◦
Informe de disponibilidad
◦
Fecha cronológica en la que se requiere el recurso
◦
Tiempo de aplicación del recurso
Gestión de Proyectos:
La definición del Ámbito nos permitirá
definir las habilidades necesarias
Posición dentro del organigrama de los recursos
a incorporar (experto, senior, junior)
Especialidades necesarias (bases de datos,
programación, interfaces, telecomunicaciones)
Número de personas para ello necesitaremos
una estimación del esfuerzo de desarrollo
Gestión de Proyectos:
Ejemplo.
Gestión de un videoclub
◦
Recursos humanos
Programadores
Registro de películas (junior) Registro de socios (junior) Gestión del alquiler (senior) Listados (senior)
Especialista
Diseño de la BBDD
Gestión de Proyectos:
Componentes ya desarrollados
◦
(COTS, Commercial Off-The-Self)
Componentes ya experimentados
◦
(riesgo menor)
Componentes con experiencia parcial
◦
(riesgo más alto) No recomendable !!
Componentes nuevos
Reutilización eficiente = catalogación, estandarización y validación [Hooper, 1991]
Gestión de Proyectos:
Estimación – Recursos: Componentes
Reutilizables
Ejemplo.
Gestión de un videoclub
◦
Recursos software reutilizables
Componentes ya desarrollados
No aplicable
Componentes ya experimentados
Gestión de una biblioteca
Componentes experimentados parcialmente
No recomendable
Componentes nuevos
Totalmente aplicable Gestión de Proyectos:
Estimación – Recursos: Componentes
Reutilizables
Entorno de desarrollo
◦
HW y SW donde se va a desarrollar
Entorno de destino
◦
HW y SW donde se va a ejecutar
Gestión de Proyectos:
Estimación – Recursos: Entorno de
Desarrollo
Ejemplo.
Gestión de un videoclub
◦
Recursos de entorno
Entorno de desarrollo PCs en Red + Impresora Herramientas Sw de Desarrollo + BBDD Entorno de destino PC + Impresora Algún componente SW Gestión de Proyectos:Estimación – Recursos: Entorno de
Desarrollo
Ejemplo.
Gestión de un videoclub
◦
Estimaciones sobre proyectos similares
Gestión de una biblioteca Registro de libros
Registro de clientes Gestión del préstamo Listados
Gestión de Proyectos:
Estimación – Recursos: Entorno de
Desarrollo
Ejemplo.
Gestión de un videoclub
◦
Funciones importantes
Registrar películas y socios Gestión del Alquiler
Listados
◦
Recursos Humanos
Programadores senior: 2 Programadores junior: 1 Especialista diseño BBDD: 1 Gestión de Proyectos:Estimación – Recursos: Entorno de
Desarrollo
Importancia: SW es el elemento más caro de un sistema
informático
Error en la estimación de coste desequilibrio del
balance beneficios/pérdidas
Ciencia no exacta!!
Variables humanas, técnicas, de entorno, políticas… Opciones seguras
Estimaciones sobre proyectos similares
Técnicas de descomposición (LDC, PF)
Modelos empíricos (COCOMO) Herramientas automáticas
Decisión desarrollar/comprar
Criterios: fecha de entrega/coste+personalización/soporte externo
Subcontratación (outsourcing) Gestión de Proyectos:
Técnicas de descomposición.
◦
Estimaciones de líneas de código (LDC)
La descomposición en subfunciones es esencial Basado en la estimación de proyectos anteriores
◦
Estimación basada en Puntos de Función (PF),
AlanAlbretch1979 (IBM)
Gestión de Proyectos:
Técnicas de descomposición.
◦
Estimación de Puntos de Función (PF) : Clasificación de
Componentes:
Para Archivos Internos e Interfaces Externas
Gestión de Proyectos:
Estimación – Proceso de Estimación
No. De tipos de archivos ref.
No. Tipos de datos contenidos
1-19 20-50 51+
1 Bajo Bajo Promedio
2-5 Bajo Promedio Alto
Técnicas de descomposición.
◦ Estimación de Puntos de Función (PF) : Clasificación de Componentes:
Para salidas
y consultas
Para entradas
Gestión de Proyectos:
Estimación – Proceso de Estimación
No. De tipos de archivos ref.
No. Tipos de datos contenidos
1-5 6-19 20+
0 ó 1 Alto Alto Promedio 2-5 Bajo Promedio Alto
6+ Promedio Alto Alto
No. De tipos de archivos ref.
No. Tipos de datos contenidos
1-4 5-14 16+
0 ó 1 Bajo Bajo Promedio 2-5 Bajo Promedio Alto
Técnicas de descomposición.
◦ Estimación basada en Puntos de Función (PF) Valores de ajuste de la complejidad:
1. ¿Requiere el sistema copias de seguridad y de recuperación fiables? 2. ¿Se requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido? 4. ¿Es crítico el rendimiento?
5. ¿Se ejecutaría el sistema en un entorno operativo existente y fuertemente utilizado? 6. ¿Requiere el sistema entrada de datos interactiva?
7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de forma interactiva?
9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 10. ¿Es complejo el procesamiento interno?
11. ¿Se ha diseñado el código para ser reutilizable?
12. ¿Están incluidas en el diseño la conversi6n y la instalaci6n?
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? 14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el
usuario?
Gestión de Proyectos:
Técnicas de descomposición.
◦
Estimación basada en Puntos de Función (PF)
Valores de ajuste de la complejidad:
FP = cuenta-total x [ 0,65 + 0,01 x Σ (Fi) ]
◦
Aplicación de los puntos de función:
Productividad = PF / persona-mes Calidad = Errores / PF
Costo = Dólares / PF
Documentación = Pags. Doc / PF
Gestión de Proyectos:
Estimación – Proceso de Estimación
0 1 2 3 4 5
Modelos empíricos: COCOMO II (COnstructive COst
Model)
◦ Modelo algorítmico que trata de establecer una relación
matemática que permite estimar el esfuerzo y tiempo requerido para desarrollar un producto
◦ Define tres modos de desarrollo o tipos de proyectos:
Orgánico: proyectos relativamente sencillos, menores de 50 KDLC líneas de código, en los cuales se tiene experiencia de proyectos similares y se
encuentran en entornos estables.
Semi-acoplado: proyectos intermedios en complejidad y tamaño (menores de 300 KDLC), donde la experiencia en este tipo de proyectos es variable, y las restricciones intermedias.
Empotrado: proyectos bastante complejos, en los que apenas se tiene
experiencia y se engloban en un entorno de gran innovación técnica. Además se trabaja con unos requisitos muy restrictivos y de gran volatilidad.
Gestión de Proyectos:
Estimación – Proceso de Estimación
Modelos empíricos: COCOMO II
◦
Modelos definidos por COCOMO:
Modelo básico: Se basa exclusivamente en el tamaño
expresado en LDC.
Modelo intermedio: Además del tamaño del
programa incluye un conjunto de medidas subjetivas llamadas conductores de costes.
Modelo avanzado: Incluye todo lo del modelo
intermedio además del impacto de cada conductor de coste en las distintas fases de desarrollo
Gestión de Proyectos:
Estimación – Proceso de Estimación
http://www.enciclopedia.galeon.com/cocomo.html
Índice
Introducción
Ámbito del Software
Recursos
Definición:
◦
Actividad 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 del software
Objetivo principal
◦
Configuración del calendario del
proyecto
Gestión de Proyectos:
Objetivos
◦
Definir todas las
tareas del proyecto
+
red de
interdependencia
. Influencias:
Tipo de proyecto: nuevo concepto, nueva aplicación,
mejora, mantenimiento, reingeniería
Grado de rigor: informal, estructurado, estricto,
esencial
◦
Definir las tareas críticas + seguimiento
camino crítico
◦
Asignar responsabilidades a los miembros del
equipo encargados de realizar cada tarea
◦
Seguimiento
tareas Detectar retraso
Gestión de Proyectos:
Plan del proyecto
◦
Definición
Documento breve con un conjunto de actividades y el
conjunto de tareas de la planificación que será empleado a lo largo del proceso de ingeniería
◦
Objetivos
Comunicar el ámbito y recursos a gestores, técnicos y clientes
Definir riesgos y sugerir soluciones Definir costes y planificación temporal
Enfoque general del proyecto
Cómo se garantiza la calidad y gestión de los cambios
Gestión de Proyectos:
Gestión de compromisos:
◦
Objetivo: negociar, establecer y gestionar los
compromisos adquiridos por todas las partes
implicadas en el desarrollo de un proyecto.
◦
El compromiso más fuerte se establece entre los
suministradores del software y los usuarios.
◦
Los errores en gestionar este compromiso son la
fuente de muchos de los problemas de los
proyectos.
[Piattini et al. 2004]
Gestión de Proyectos:
¡Retrasos!
. ¿Razones?
◦
Fechas de entrega no realistas.
◦
Cambio de los requisitos del cliente.
◦
Subestimación esfuerzo y/o recursos.
◦
Errores predecibles y no predecibles.
◦
Dificultades técnicas.
◦
Dificultades humanas.
◦
Falta de comunicación en la plantilla.
◦
Falta de reconocimiento del retraso por el
gestor y ausencia de medidas.
Gestión de Proyectos:
Principios de la planificación (I)
◦
Segmentación
Descomposición. Tareas y actividades manejables
◦
Interdependencia
Secuenciación y paralelismo de tareas/actividades
◦
Asignación de tiempo
Nº de unidades de trabajo (personas/mes) Fechas de inicio/terminación
Interdependencia marca el camino crítico
Gestión de Proyectos:
Principios de la planificación (II)
◦
Validación del esfuerzo
Esfuerzo (personas/día) ≤ personas disponibles
◦
Definición de responsabilidades
Tarea miembro
◦
Resultados definidos
Entregas, productos, etc.
◦
Hitos
Revisión y aceptación de la calidad de un
producto/resultado Gestión de Proyectos:
Desarrollo del plan de desarrollo
(
calendario
). Fases
1.
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
2.
Descomposición de las actividades
Diagrama de descomposición de actividades
Gestión de Proyectos:
Calendario. Fases
◦
Diagrama de descomposición de actividades
00 J.L. Fernández Proyecto de desarrollo X 10 20 30 40 J.L. Fernández Gestión del Proyecto Ingeniería del Sistema Desarrollo del Software Pruebas de integración y del sistema S. Alonso S. Alonso J.L. Fernández T. Diez J. Gómez V. Pérez
A. Ramirez P. Redondo S. Sánchez G. Alfonso Gestión del
Proyecto
Gestión de Configuración
Diseño del
Sistema Análisis yDiseño Programación Pruebas Pruebas deIntegración Pruebas deAceptación G. Fuentes Nivel de Proyecto
Nivel de paquete de trabajo
Plan de Proyecto UT. 111 11 12 21 31 32 33 41 42 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 Arquitectura UT. 214 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
[Piattini et al. 2004]
Gestión de Proyectos:
Desarrollo del plan de desarrollo
(
calendario
). Fases
3.
Relación entre actividades
Técnicas para proyectos cortos: diagramas de hitos,
diagramas de Gantt.
Técnicas para proyectos grandes: PERT y CPM
4.
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.
Gestión de Proyectos:
Desarrollo del plan de desarrollo (
calendario
).
Fases
5. 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
6. 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
7. Revisión del calendario
¿Es realista?
Efectos de la vida laboral en el calendario (vacaciones, enfermedad, etc.) Asegurar que es flexible
Gestión de Proyectos:
Técnicas:
◦
Diagramas de hitos
◦
Gráfico de tiempo (Diagrama de Gantt)
◦
Redes de precedencia.
Técnica de evaluación y revisión de programa (PERT) Método del camino crítico (CPM)
[Piattini et al. 2004]
Gestión de Proyectos:
Técnicas
◦ Diagramas de hitos: cuadro o tabla formada por dos columnas.
Ventajas: facilidad de uso y mínimo coste de preparación. Desventajas: incertidumbre existente sobre las fechas de
comienzo de las actividades y la imposibilidad de reflejar las interrelaciones entre ellas.
Tarea Fecha fin Tarea 1.1 Marzo-2006 Tarea 1.2 Mayo-2006 Tarea 1.3 Junio-2006 Tarea 2.1 Mayo-2006 Tarea 2.2 Agosto-2006 Tarea 2.3 Octubre-2006 [Piattini et al. 2004] Gestión de Proyectos:
Planificación temporal
Técnicas:
◦ Gráfico de tiempo (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.
◦ Se utiliza frecuentemente en proyectos pequeños (< 25 actividades)
Ventajas: SÍ expresa claramente los solapamientos entre
actividades.
Desventajas: NO permite representar las dependencias entre actividades.
[Piattini et al. 2004]
Gestión de Proyectos:
Técnicas:
◦
Gráfico de tiempo (Diagrama de Gantt)
Ejemplo: Unidades de tiempo 1 2 3 4 5 6 7 8 9 10 Tarea 1.1 Tarea 1.2 Tarea 1.3 Tarea 2.1 Tarea 2.2 Tarea 2.3 Gestión de Proyectos:
Planificación temporal
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 300
Gestión de Proyectos:
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
Gestión de Proyectos:
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
2 A
1
Suceso Actividad Suceso
[Piattini et al. 2004]
Gestión de Proyectos:
Diagramas PERT. Principios
◦ Relaciones de precedencia: actividades que deben estar finalizadas justamente antes del comienzo de la actividad dada RELACIONES DE PRECEDENCIA LINEALES RELACIONES DE PRECEDENCIA DIVERGENTES 1 2 3 RELACIONES DE PRECEDENCIA CONVERGENTES 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. 1 2 3 4 5 A B C D
Para iniciar la actividad D es necesario haber finalizado las actividades A, B y C. 1 3 2 5 4 A B C D
Para poder iniciar cualquiera de las actividades B, C, o D, es necesario que haya finalizado la actividad A.
Gestión de Proyectos:
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 B C D E No se cumple la regla 1:
Es necesario que finalice C para que comience D
Gestión de Proyectos:
Diagramas PERT. Conflictos entre
actividades: Solución
◦
Añadir una actividad ficticia de duración cero
A B C D E F Gestión de Proyectos:
Planificación temporal
Planificación temporal
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 precedea E
C precede a F
D precede a G
E, F preceden a H
◦
Dos modos de representar estas relaciones:
Matriz de encadenamientos
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 A B C D E F G H A B X C X D X E X F X G X H X X Actividades precedentes Activida des si gui ent es Gestión de Proyectos:
Planificación temporal
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 C G D H E, F Gestión de Proyectos:
Planificación temporal
Diagramas PERT. Representación
◦
Grafo
1 2 5 4 3 6 7 A B C D E F G H Gestión de Proyectos:Planificación temporal
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.
A
TEi TLi TEj TLj
suceso i suceso j
Tiempo más temprano para comenzar la actividad A (tiempo early de comienzo de A)
Tiempo más tardío para comenzar la actividad A
Tiempo más temprano para finalizar la actividad A
Tiempo más tardío para finalizar la actividad A
Gestión de Proyectos:
Diagramas 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
Gestión de Proyectos:
Diagramas PERT
◦
Supongamos calculados los tiempos PERT de cada
actividad:
Actividad A B C D E F G H Duración 8 5 6 5 6 7 9 3 3 4 5 6 7 A 1 2 B C D E F H G 8 5 6 5 6 7 9 3 0 8 13 14 13 21 24 19 22 [Piattini et al. 2004] Gestión de Proyectos:Planificación temporal
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
Gestión de Proyectos:
Diagramas PERT
◦
Ejemplo
3 4 5 6 7 A 1 2 B C D E F H G 8 5 6 5 6 7 9 3 0 8 13 14 13 21 24 19 22 24 21 15 15 14 8 0 10 21 24 8 Gestión de Proyectos:Planificación temporal
Holgura total de una actividad y camino
crítico:
◦
Holgura
de un suceso i:
H
i= TL
i- TE
i◦
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
Gestión de Proyectos:
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
Gestión de Proyectos:
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.
Gestión de Proyectos:
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:
HL
ij= TE
j- TE
i- T
ij◦
La holgura libre representa la parte de la holgura
total que puede consumirse sin que por ello, afecte
a las siguientes actividades.
Gestión de Proyectos:
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.
HI
ij= TE
j- TL
i- T
ij◦
Este dato indica la cantidad de holgura disponible si
todas las actividades han comenzado en sus
tiempos late.
Gestión de Proyectos:
Estrategia genérica
1.
Representar un grafo de PERT
2.
Identificar el camino crítico
3.
Identificar la holgura de las otras
actividades
4.
Representar una planificación temporal
de Gantt
Gestión de Proyectos:
Estrategia genérica. Diagrama de Gantt con MS
Project
Gestión de Proyectos:
Dados los siguientes cuadros de relaciones de
precedencia realizar el diagrama de PERT
correspondiente, indicando:
◦
Tiempo Temprano (Early)
◦
Tiempo Tardío (Late)
◦
Camino Crítico
Gestión de Proyectos:
Gestión de Proyectos:
Planificación temporal: Ejercicios
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
Actividad Actividades Predecesoras Duración 1 2 3 2 3, 4 2 3 5 3 4 10, 11 5 5 8 0 6 9 7 7 15 10 8 6, 7 17 9 14 1 10 12, 16 4 11 13, 17 6 12 14 8 13 15 10 14 15 2 15 18 2 16 18 4 17 18 4 18 19 2 19 - 0 Gestión de Proyectos:
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
Gestión de Proyectos:
Seguimiento de la planificación
◦
Tareas:
Reuniones periódicas evaluar progreso Determinar hitos cumplidos
Comparar fecha real y prevista de inicio Evaluar los resultados de las revisiones
Gestión de Proyectos:
Hooper, J. W. E., y R. O. Chester, Software Reuse:
Guidelines and Merhods, Plenum Press, 1991.
Calvo-Manzano, J.A., Cervera, J., Fernández, L., Piattini, M.
Aplicaciones Informáticas de Gestión. Una perspectiva
de Ingeniería del Software Editorial: RA-MA (2004)
Pressman, R. S. Ingeniería del Software. Un Enfoque
Práctico (7ª Edición) Editorial : McGraw-Hill (2010)
IEEE Std 1058.1-1987, IEEE Standard for Software
Project Management Plans.
http://ieeexplore.ieee.org/iel1/2591/955/00025325.pdf
AIS - 79
Gestión de Proyectos:
