gestión de proyectos ii - kybele · 2011-01-13 · planificación de proyectos. definición...
TRANSCRIPT
INGENIERÍA DEL SOFTWARE
CURSO 2010-2011
MARCOS LÓPEZ SANZ
Gestión de Proyectos II:Planificación de Proyectos
2
Introducción
Curso 2010-2011Ingeniería del Software
Duración Proyecto
Tiempo
90%
Planificación de proyectos. Definición Conjunto de actividades previas a la puesta en marcha del proyecto
ObjetivoObjetivo
Proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal
Incluye:
Estimación
Análisis y gestión del riesgo
Planificación temporal y seguimiento del proyecto
Definición de la calidad del producto
Gestión de la configuración
Introducción
Curso 2010-2011
3
Ingeniería del Software
Estimación Antes de que comience el proyecto
Parámetros estimados:
Tiempo, esfuerzo, recursos (HW, SW, humanos) y riesgo
Difícil, pero no imposible
NoNo es una ciencia exactaciencia 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
Gestión de Proyectos:
Estimación
Curso 2010-2011
4
Ingeniería del Software
Observaciones Estimación Riesgo Incertidumbre …… Error! Factores que influyen en la estimación:
Complejidad del proyecto Medida relativa que depende de la experiencia en proyectos similares
Tamaño del proyecto ↑ tamaño ↑ interdependencia ↑ complejidad de la descomposición ↑
variabilidad de los valores que toman los factores de 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
RiesgoRiesgo = 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:
Estimación
Curso 2010-2011
5
Ingeniería del Software
Puntos clave de la estimación
Ámbito del software
Estimación de recursos
Gestión de Proyectos:
Estimación
Curso 2010-2011
6
Ingeniería del Software
Ámbito del software Primera actividad de la planificación del proyecto
Objetivo: delimitardelimitar
Describe:
Control y datos a procesar. Funcionamiento habitual
Funciones principales/importantes
Rendimiento y restricciones
Fiabilidad
Interfaces con otros sistemas
Gestión de Proyectos:
Estimación – Ámbito
Curso 2010-2011
7
Ingeniería del Software
Ámbito del software 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
Viabilidad: factibilidad del software Percepción de los riesgos
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:
Estimación – Ámbito
Curso 2010-2011
8
Ingeniería del Software
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:
Estimación – Ámbito
Curso 2010-2011
9
Ingeniería del Software
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:
Estimación – Ámbito
Curso 2010-2011
10
Ingeniería del Software
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
Curso 2010-2011
11
Ingeniería del Software
Segunda tarea en la planificación del desarrollo de SW Estimación de los recursos requeridos para acometer el esfuerzo de
desarrollo de software
Recursos de desarrollo Personal
Recurso primario
Componentes software reutilizables
Bloques SW que reducen los costes de desarrollo y aceleran la entrega
Entorno de desarrollo
Herramientas hardware/software
Infraestructura de soporte al esfuerzo de desarrollo
Gestión de Proyectos:
Estimación – Recursos
Curso 2010-2011
12
Ingeniería del Software
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:
Estimación – Recursos
Curso 2010-2011
13
Ingeniería del Software
Recursos humanos Ámbito habilidades necesarias
Posición dentro del organigrama (experto, senior, junior)
Especialidad (bases de datos, programación, interfaces, telecomunicaciones)
Número de personas estimación del esfuerzo de desarrollo
Gestión de Proyectos:
Estimación – Recursos de desarrollo
Curso 2010-2011
14
Ingeniería del Software
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:
Estimación – Recursos de desarrollo
Curso 2010-2011
15
Ingeniería del Software
Recursos de software reutilizables Componentes ya desarrolladosdesarrollados (COTS, Commercial Off-The-Self)
Componentes ya experimentadosexperimentados (riesgo menor)
Componentes con experienciaexperiencia parcialparcial (riesgo más alto) No recomendable !!
Componentes nuevosnuevos
Reutilización eficiente = catalogación, estandarización y validación
Gestión de Proyectos:
Estimación – Recursos de desarrollo
Curso 2010-2011
16
Ingeniería del Software
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 de desarrollo
Curso 2010-2011
17
Ingeniería del Software
Recursos del entorno 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 de desarrollo
Curso 2010-2011
18
Ingeniería del Software
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 de desarrollo
Curso 2010-2011
19
Ingeniería del Software
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 de desarrollo
Curso 2010-2011
20
Ingeniería del Software
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 de desarrollo
Curso 2010-2011
21
Ingeniería del Software
Estimación de proyectos software 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:
Estimación – Proceso de estimación
Curso 2010-2011
22
Ingeniería del Software
Técnicas de descomposición. Estimaciones de líneas de código (LDC)
La descomposición en subfunciones/componentes es esencial
Basado en la estimación de proyectos anteriores (experiencia)
Estimación basada en Puntos de Función (PF), Alan Albretch 1979 (IBM)
Gestión de Proyectos:
Estimación – Proceso de estimación
Curso 2010-2011
23
Ingeniería del Software
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 aplicaci6n para facilitar los cambios y para ser fácilmente utilizada
por el usuario?
Gestión de Proyectos:
Estimación – Proceso de estimación
Curso 2010-2011
24
Ingeniería del Software
Técnicas de descomposición. Estimación basada en Puntos de Función (PF) Valores de ajuste
de la complejidad:
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
Curso 2010-2011
25
Ingeniería del Software
FP = cuentaFP = cuenta--total x [ 0,65 + 0,01 x total x [ 0,65 + 0,01 x ΣΣ (F(Fii ) ]) ]
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
Curso 2010-2011
26
Ingeniería del Software
http://www.enciclopedia.galeon.com/cocomo.html
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 dedesarrollo
Gestión de Proyectos:
Estimación – Proceso de estimación
Curso 2010-2011
27
Ingeniería del Software
http://www.enciclopedia.galeon.com/cocomo.html
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
Origen Modelo de proceso, tareas de ingeniería, estimación de la cantidad de trabajo, número
de personas, fechas de entrega, riesgos…
Resultado Planificación del proyecto e información asociada para su seguimiento
Documento estándar: IEEE Std 1058.1-1987
Elementos Definición de la red de tareas (completa) Esfuerzo y tiempo asignado a cada tarea Relaciones entre las tareas Recursos asignados a las tareas Espaciado de los “hitos” para poder hacer un seguimiento del progreso
Gestión de Proyectos:
Planificación temporal y seguimiento del proyecto
Curso 2010-2011
28
Ingeniería del Software
Objetivos Definir todas las tareas del proyecto + red de interdependencia.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 crcamino crííticotico
Asignar responsabilidades a los miembros del equipo encargados de realizar cada tarea
Planificación macroscópica Detallada
SeguimientoSeguimiento tareas Detectar retraso
Gestión de Proyectos:
Planificación temporal
Curso 2010-2011
29
Ingeniería del Software
RetrasosRetrasos. Razones Fechas de entrega no realistas
Cambio de los requisitos del cliente no reflejados en la planificación
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:
Planificación temporal
Curso 2010-2011
30
Ingeniería del Software
Principios de la planificación 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:
Planificación temporal
Curso 2010-2011
31
Ingeniería del Software
Principios de la planificación 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:
Planificación temporal
Curso 2010-2011
32
Ingeniería del Software
Desarrollo del plan de desarrollo (calendariocalendario). Fases1. 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, cuantificabley de duración específica
2. Descomposición de las actividades
Diagrama de descomposición de actividades
Gestión de Proyectos:
Planificación temporal
Curso 2010-2011
33
Ingeniería del Software
Desarrollo del plan de desarrollo (calendariocalendario). Fases Diagrama de descomposición de actividades
Gestión de Proyectos:
Planificación temporal
Curso 2010-2011
34
Ingeniería del Software
00
J.L. Fernández
Proyecto dedesarrollo X
10 20 30 40
J.L. Fernández
Gestión delProyecto
Ingeniería del Sistema
Desarrollo delSoftware
Pruebas de integración y del
sistema
S. Alonso
S. AlonsoJ.L. Fernández T. Diez
J. Gómez V. Pérez
A. Ramirez P. Redondo S. Sánchez G. Alfonso
Gestión delProyecto
Gestión deConfiguración
Diseño delSistema
Análisis yDiseño
Programación PruebasPruebas deIntegración
Pruebas deAceptación
G. Fuentes
Nivel de Proyecto
Nivel de paquete de trabajo
Plan de ProyectoUT. 111
11 12 21 31 32 33 41 42
Control de ConfiguraciónUT. 121
Construcción deSoftwareUT. 122
ComunicacionesUT. 211
Análisis de RequisitosUT. 212
Gestión de la Base de DatosUT. 213
ArquitecturaUT. 214
Diseño FuncionalUT. 311
Diseño deAlgoritmosUT. 312
Diseño de laBase de DatosUT. 313
ProgramaciónUT. 321
DocumentaciónUT. 322
Soporte a lasPruebasUT. 323
Procedimientosde PruebasUT. 331
Pruebas UnitariasUT. 332
Análisis de lasPruebasUT. 333
Procedimientosde PruebasUT. 411
Integración delSistemaUT. 412
FormaciónUT. 413
Procedimientosde PruebasUT. 421
Satisfacciónde RequisitosUT. 422
Nivel de Unidad de Trabajo
Desarrollo del plan de desarrollo (calendariocalendario). Fases3. Relación entre actividades
Técnicas para proyectos cortos: diagramas de hitos, diagramas de Gantt, diagramas “full wall”
Técnicas para proyectos grandes: PERT (Program Evaluation and Review Tecnique) y CPM (Critical Path Method)
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.
Es una buena estrategia para el jefe de proyecto contrastar y negociar sus cálculos de tiempos y esfuerzos con los responsables de cada actividad, que suelen contar con buena precisión a la hora de estimar los costes reales en tiempo y esfuerzo.
Gestión de Proyectos:
Planificación temporal
Curso 2010-2011
35
Ingeniería del Software
Desarrollo del plan de desarrollo (calendariocalendario). Fases5. 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:
Planificación temporal
Curso 2010-2011
36
Ingeniería del Software
Técnicas Diagramas de hitos
Es un cuadro o tabla formada por dos columnas:
VentajasVentajas: facilidad de uso (es el método más simple) y mínimo coste de preparación (todo el mundo lo comprende inmediatamente)
DesventajasDesventajas: incertidumbre existente sobre las fechas de comienzo de las actividades y la imposibilidad de reflejar las interrelaciones entre ellas.
Se utiliza para resumir calendarios complejos
Gestión de Proyectos:
Planificación temporal
Curso 2010-2011
37
Ingeniería del Software
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
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 (menos de 25
actividades)
InconvenienteInconveniente: NO permite representar las dependencias entre
actividades.
VentajasVentajas: SÍ expresa claramente los solapamientos entre actividades.
Gestión de Proyectos:
Planificación temporal
Curso 2010-2011
38
Ingeniería del Software
Técnicas Gráfico de tiempo (Diagrama de Gantt)
Gestión de Proyectos:
Planificación temporal
Curso 2010-2011
39
Ingeniería del Software
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
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 crCamino crííticotico: 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:
Planificación temporal
Curso 2010-2011
40
Ingeniería del Software
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:
Planificación temporal
Curso 2010-2011
41
Ingeniería del Software
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).
SucesoSuceso: acontecimiento o punto temporal (una fecha) que no consume recursos
Representación por medio de un grafo
Gestión de Proyectos:
Planificación temporal – Diagramas PERT42
2
A
1
Suceso SucesoActividad
Curso 2010-2011Ingeniería del Software
Diagramas PERT. Principios Relaciones de precedenciaRelaciones de precedencia: actividades que deben estar finalizadas
justamente antes del comienzo de la actividad dada
Gestión de Proyectos:
Planificación temporal – Diagramas PERT43
RELACIONES DEPRECEDENCIA
LINEALES
RELACIONES DEPRECEDENCIADIVERGENTES
1 2 3
RELACIONES DEPRECEDENCIA
CONVERGENTES
A B
Para iniciar la actividad B esnecesario haber finalizado laactividad 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 esnecesario haber finalizado lasactividades A, B y C.
1
3
2
5
4A
B
C
D
Para poder iniciar cualquierade las actividades B, C, o D, esnecesario que haya finalizado la actividad A.
Curso 2010-2011Ingeniería del Software
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.
Gestión de Proyectos:
Planificación temporal – Diagramas PERT44
A
B
C
D
E
No se cumple la regla 1: Es necesario que finalice C para que comience D
Curso 2010-2011Ingeniería del Software
Diagramas PERT. Conflictos entre actividades: Solución Añadir una actividad ficticia de duración cero
Gestión de Proyectos:
Planificación temporal – Diagramas PERT45
Curso 2010-2011Ingeniería del Software
A
B
C
D
E
F
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 precede a E
C precede a F
D precede a G
E, F preceden a H
Dos modos de representar estas relaciones:
Matriz de encadenamientos
Cuadro de relaciones de precedencia
Gestión de Proyectos:
Planificación temporal – Diagramas PERT46
Curso 2010-2011Ingeniería del Software
Diagramas PERT. Representación Matriz de encadenamientosMatriz 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
Gestión de Proyectos:
Planificación temporal – Diagramas PERT47
A B C D E F G HAB XC XD XE XF XG XH X X
Actividades precedentes
Act
ivid
ades
sig
uien
tes
Curso 2010-2011Ingeniería del Software
Diagramas PERT. Representación Cuadro de relaciones de precedenciaCuadro de relaciones de precedencia: tabla de dos columnas:
Actividades en que se descompone un proyecto
Sus actividades precedentes
Gestión de Proyectos:
Planificación temporal – Diagramas PERT48
Actividades Actividades
Precedentes
A -
B A
C A
D A
E B
F C
G D
H E, F
Curso 2010-2011Ingeniería del Software
Diagramas PERT. Representación Grafo
Gestión de Proyectos:
Planificación temporal – Diagramas PERT49
1 2
5
4
3
6
7
A
B
C
D
E
F
G
H
Curso 2010-2011Ingeniería del Software
Diagramas PERT. Asignación de tiempos a actividades El siguiente paso es el cálculo de los tiempos earlyearly (tiempo más
temprano posible) y lastlast (tiempo más tardío posible) de cada suceso descrito en el grafo.
Gestión de Proyectos:
Planificación temporal – Diagramas PERT50
Curso 2010-2011Ingeniería del Software
ATEi 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 paracomenzar la actividad A
Tiempo más temprano parafinalizar la actividad A
Tiempo más tardío parafinalizar la actividad A
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:
Planificación temporal – Diagramas PERT51
Curso 2010-2011Ingeniería del Software
Diagramas PERT Supongamos calculados los tiempos PERT de cada actividad:
Gestión de Proyectos:
Planificación temporal – Diagramas PERT52
Actividad A B C D E F G H
Duración 8 5 6 5 6 7 9 3
3
4
5
6
7A1 2
B
C
D
E
FH
G
8
5
6
5
6
7
9
3
0 8
13
14
13
21
24
19
22
Curso 2010-2011Ingeniería del Software
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:
Planificación temporal – Diagramas PERT53
Curso 2010-2011Ingeniería del Software
Diagramas PERT
Gestión de Proyectos:
Planificación temporal – Diagramas PERT54
3
4
5
6
7A1 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
1480
10
21
248
Curso 2010-2011Ingeniería del Software
Holgura total de una actividad y camino crítico: Holgura de un suceso iHolgura de un suceso i:
Hi = TLi - TEi
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 crsuceso es críítico tico si Hi = 0Hi = 0
Gestión de Proyectos:
Planificación temporal – Diagramas PERT55
Curso 2010-2011Ingeniería del Software
Holgura total de una actividad y camino crítico: Holgura total de una actividadHolgura 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 cractividad es críítica tica si la holgura total = 0holgura total = 0
Gestión de Proyectos:
Planificación temporal – Diagramas PERT56
Curso 2010-2011Ingeniería del Software
Holgura total de una actividad y camino crítico: Camino crCamino crííticotico: 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 caminocrí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:
Planificación temporal – Diagramas PERT57
Curso 2010-2011Ingeniería del Software
Holgura libre y holgura independiente de la actividad Holgura libre de una actividad ij: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:
HLij = TEj - TEi - Tij
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:
Planificación temporal – Diagramas PERT58
Curso 2010-2011Ingeniería del Software
Holgura libre y holgura independiente de la actividad Holgura independiente de una actividad ij: 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.
HIij = TEj - TLi - Tij
Este dato indica la cantidad de holgura disponible si todas las actividades han comenzado en sus tiempos late.
Gestión de Proyectos:
Planificación temporal – Diagramas PERT59
Curso 2010-2011Ingeniería del Software
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:
Planificación temporal
Curso 2010-2011
60
Ingeniería del Software
Estrategia genérica. Diagrama de Gantt con MS Project
Gestión de Proyectos:
Planificación temporal
Curso 2010-2011
61
Ingeniería del Software
Ejercicio
Gestión de Proyectos:
Planificación temporal – Diagramas PERT62
Curso 2010-2011Ingeniería del Software
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
Ejercicio
Gestión de Proyectos:
Planificación temporal – Diagramas PERT63
Curso 2010-2011Ingeniería del Software
0 0 0 0 4 4 22 22
7 7
4 9
10 11
18 18
15 15
P
J
C
I
M
H G
3
E
D
B
K
4
3
0 4 5 6
L7
F
32
4
6
8
9
A
Gestión de Proyectos:
Planificación temporal – Diagramas PERT64
Curso 2010-2011Ingeniería del Software
Actividad Sucesores 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 Final 0
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
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:
Seguimiento y supervisión
Curso 2010-2011
65
Ingeniería del Software
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:
Planificación temporal
Curso 2010-2011
66
Ingeniería del Software
Gestión de Proyectos:
Planificación temporal – IEEE Std 1058.1-1987
Title PageRevision ChartPrefaceTable of ContentsList of FiguresList of Tables1. Introduction
1.1 Project Overview1.2 Project Deliverables1.3 Evolution of the SPMP1.4 Reference Materials1.5 Definitions and Acronyms
2. Project Organization2.1 Process Model2.2 Organizational Structure2.3 Organizational Boundaries and Interfaces2.4 Project Responsibilities
3. Managerial Process3.1 Management Objectives and Priorities3.2 Assumptions, Dependencies, and Constraints3.3 Risk Management3.4 Monitoring and Controlling Mechanisms3.5 Staffing Plan
4. Technical Process4.1 Methods, Tools, and Techniques4.2 Software Documentation4.3 Project Support Functions
5. Work Packages, Schedule, and Budget5.1 Work Packages5.2 Dependencies5.3 Resource Requirements5.4 Budget and Resource Allocation5.5 Schedule
Additional ComponentsIndexAppendices
Curso 2010-2011Ingeniería del Software
67
Resumen
Curso 2010-2011
68
Ingeniería del Software
Roger S. Pressman. Ingeniería del Software: Un enfoque práctico. Capítulo 3.Ed. McGraw Hill. 5ª edición.2002
M. Piattini et al. Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión. Ed. Ra-Ma. 1996
IEEE Std 1058.1-1987, IEEE Standard for Software Project Management Plans. http://ieeexplore.ieee.org/iel1/2591/955/00025325.pdf
Bibliografía
Curso 2010-2011
69
Ingeniería del Software