Tema IX: Gestión de Proyectos: Planificación.

(1)

Diana M. Sánchez Fúquene

Ingeniería del Software de Gestión

Tema IX:

Gestión de Proyectos:

Planificación.

(2)

www.kybele.urjc.es

Índice

Ingeniería del Software de Gestión 2



Introducción



Estimación:

Ámbito del Software Recursos

Procesos de Estimación de Software Procesos de Planificación Temporal

(3)



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

Gestión de la configuración

(4)



Objetivo de la planificación

Proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal

(5)

Gestión de Proyectos: 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

(6)



Observaciones sobre la estimación

Estimación  Riesgo  Incertidumbre …… Error! Factores que influyen en la estimación:

 Complejidad del proyecto  Tamaño del proyecto

6 Ingeniería del Software de Gestión

Medida relativa que depende de la experiencia en proyectos similares + tamaño  + interdependencia 

+ complejidad de la descomposición  + variabilidad de los valores que toman

los factores de estimación

(7)



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

(8)



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

.

(9)

Agenda



Introducción



Estimación:

(10)



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:

(11)



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

(12)



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?

(13)



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.

(14)



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

(15)



Ejemplo. Software de un teléfono móvil

Rendimiento y restricciones

 Habituales

Fiabilidad

 Habitual

Interfaz con otros sistemas

 Operador de telefonía

Ejercicio de Análisis 2

(16)

Índice



Introducción



Estimación:

(17)



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: Estimación – Recursos

(18)

Recursos del Proyecto

Personal Componentes

software reutilizables

Entorno de desarrollo

[Pressman, 2010]

(19)



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

(20)



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

(21)



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

(22)



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)

(23)



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)

(24)

www.kybele.urjc.es 

Entorno de desarrollo

HW y SW donde se va a desarrollar 

Entorno de destino

HW y SW donde se va a ejecutar 24 Ingeniería del Software de Gestión

Gestión de Proyectos: Estimación – Recursos Entornos de Desarrollo

(25)



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

(26)



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

(27)



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 Ejercicio de Análisis 1

(28)

Índice



Introducción



Estimación:

(29)

Gestión de Proyectos: Estimación Procesos de Estimación



Objetivo:

Apoyar la estimación de los recursos que necesita un proyecto

Elementos a estimar:

 No. de personas a involucrar en el proyecto  Costo de un proyecto

 Tiempo de realización de un proyecto.

Los resultados pueden ser utilizados para:

 Guía del proyecto  Proyecto viable o no

 Decisión desarrollar/comprar

• Criterios: fecha de entrega / coste + personalización / soporte externo • Subcontratación (outsourcing)

(30)



Importancia

SW es el elemento más caro de un sistema informático

Ejemplo: Error en la estimación de coste  desequilibrio del balance beneficios/pérdidas

 Ciencia no exacta!!

Variables humanas, técnicas, de entorno, políticas…



Técnicas de estimación:

Estimaciones sobre proyectos similares Técnicas de descomposición (LDC, PF) Modelos empíricos (COCOMO)

Herramientas automáticas

(31)



Los métodos actuales están basados en el tamaño

del software

Líneas de código Requerimientos



Estimaciones de líneas de código (LDC)

Difícil de estimar al inicio del ciclo de vida del sw La descomposición en subfunciones es esencial Basado en la estimación de proyectos anteriores

(32)

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

http://www.enciclopedia.galeon.com/cocomo.html

Gestión de Proyectos: Estimación – Procesos de Estimación

(33)



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

(34)

 Modelo COCOMO II

El método se basa en el cálculo del esfuerzo de acuerdo al número de líneas de código

Esfuerzo = a * (KLDC)b

El esfuerzo se ajusta a través del análisis los factores de costo

 Las ecuaciones de esfuerzo y tiempo de COCOMO son:

Modelo de desarrollo Personas-mes (nominal) Tiempo de desarrollo (nominal)

Orgánico PM = 3.2 * KLDC 1.05 _{TD = 2.5 * PM}0.38 Semi-libre PM = 3.0 * KLDC 1.12 _{TD = 2.5 * PM}0.35 Empotrado PM = 2.8 * KLDC 1.20 _{TD = 2.5 * PM}0.32

(35)

Factores (cost-drivers)

Valor de los factores

Muy bajo Bajo Medio Alto Muy alto Extra Fiabilidad requerida 0.75 0.88 1 1.15 1.40

Tamaño de la base de datos 0.94 1 1.08 1.16

Complejidad del software 0.70 0.85 1 1.15 1.30 1.65 Restricciones de tiempo de ejecución 1 1.11 1.30 1.66 Restricciones de memoria 1 1.06 1.21 1.56 Volatilidad del hardware 0.87 1 1.15 1.30

Restricciones de tiempo de respuesta 0.87 1 1.07 1.15 Calidad de los analistas 1.46 1.19 1 0.86 0.71 Experiencia con el tipo de aplicación 1.29 1.13 1 0.91 0.82 Experiencia con el hardware 1.21 1.10 1 0.90

Experiencia con el lenguaje de programación 1.14 1.07 1 0.95

Calidad de los programadores 1.42 1.17 1 0.86 0.70 Técnicas modernas de programación 1.24 1.10 1 0.91 0.82 Empleo de herramientas 1.24 1.10 1 0.91 0.83

(36)



Modelos empíricos: COCOMO II

Estimación de esfuerzo ajustado = esfuerzo nominal * factores de costo (personas – mes)



A partir del esfuerzo se calculan el resto de variables:

Estimación de costos mensuales = Esfuerzo ajustado * Promedio salario mensual

Estimación de tiempo ajustado = Cálculo de tiempo con esfuerzo ajustado

No medio de recursos humanos por mes = Esfuerzo ajustado / Tiempo ajustado

http://www.enciclopedia.galeon.com/cocomo.html

(37)



Estimación basada en Puntos de Función (PF),

Alan Albretch 1979 (IBM)

Puntos de función: Medir el tamaño funcional del sw

(38)



Estimación de PF

Elementos para el cálculo de puntos de función

Elementos Funciones de datos Ficheros lógicos internos Ficheros lógicos externos (interfaces) Funciones de transacciones Entradas de Usuario Salidas al Usuario Consultas (Peticiones de Usuario)

(39)

(40)

 Estimación de PF  Ficheros Internos

Archivos maestros.

Aplicaciones de seguridad de datos. Datos de auditoría.

Mensajes help.

Mensajes de error.

Archivos internos lógicos mantenidos por más de una aplicación

 Interfaces Externas

Representan un grupo de datos relacionados lógicamente

identificables por el usuario o información de control utilizada por la aplicación, pero mantenida por otra aplicación.

(41)



Estimación de Puntos de Función (PF)

Clasificación de Componentes:



Para Archivos Internos e Interfaces Externas

:

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

6+ Promedio Alto Alto

(42)

 Entradas Externas:

Las transacciones para mantener Archivos lógicos internos.

Las pantallas de entrada (una entrada por cada función de pantalla) Las entradas por lotes (una entrada por cada función)

Archivos físicos de entrada (si un archivo es usado por mas de un proceso se debe contar independiente)

 Salidas:

Transferencia de datos a otras aplicaciones

 Un archivo una salida, un archivo varias salidas, varios archivos una salida.

Los informes

 Dos informes con el mismo formato pero origen de datos de distintos son dos salidas.  Dos informes idénticos, producidos en diferentes soportes son dos salidas distintas.  Informes on-line

Los gráficos. Datos estadísticos en distintos formatos se cuentan cada uno una salida. Archivos lógicos que se crean y graban

No se deben contar como salidas:

 Las ayudas.

 Formas de invocación de salidas.  Mensajes de error/confirmación

 Los informes múltiples/valores únicos de datos  Las totalizaciones

 Los informes ad hoc

(43)



Consultas Externas:

La búsqueda inmediata de datos. Las consultas no explícitas

Los menús con consultas implícitas Pantallas de conexión (login)

Las ayudas

Las salidas duplicadas Las salidas gráficas Tutoriales



No se consideran como consultas:

Los mensajes de error/confirmación.

(44)



Estimación de Puntos de Función (PF)

Clasificación de Componentes:

 Para salidas

y consultas

 Para entradas

1-5 6-19 20+

0 ó 1 Alto Alto Promedio 2-5 Bajo Promedio Alto

1-4 5-14 16+

0 ó 1 Bajo Bajo Promedio 2-5 Bajo Promedio Alto

(45)



Estimación de Puntos de Función (PF)

Cálculo de los puntos de función sin ajustar

Parámetros de

Medición Cuenta

Factor de Ponderación

Total

Simple Medio Complejo

No. de entradas X 3 4 6 =

No de salidas X 4 5 7 =

No. Consultas X 3 4 6 =

No. Ficheros internos X 7 10 15 = No. Interfaces

externas

X 6 7 10 =

(46)

 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?

(47)



Estimación basada en Puntos de Función (PF)

Valores de ajuste de la complejidad: = cuenta-total x [

0,65 + 0,01 x Σ (Fi) ]

Cálculo de los Puntos de función

Puntos Función = [PFSA] * [0.65 + 0.01 * TCG] PFSA: Puntos de función sin ajustar

TCG: Total Características Generales

0 1 2 3 4 5

(48)



Estimación basada en puntos de Función (PF)

Correspondencia entre líneas de código y puntos de función

Lenguaje Promedio LDC/PF Lenguaje Promedio LDC/PF

Ensamblador (Assembler) 320 Basic ANSI/Quick/Turbo 64 Macroensamblador 213 Java 53 C 150 Visual C++ 34 Fortran 106 FoxPro 34 Cobol 106 Visual Basic 32 Pascal 91 Delphi 29 Cobol ANSI 85 91 C++ 29 Basic 91 Visual Cobol 20

RPG 80 Clipper 19

PL/I 80 PowerBuilder 16 Ada 71 Hoja de Cálculo 6

(49)



Estimación basada en Puntos de Función (PF)

Aplicación de los puntos de función:

 Productividad = PF / persona-mes  Calidad = Errores / PF

 Costo = Dólares / PF

 Documentación = Pags. Doc / PF

(50)

Índice



Introducción



Estimación:

(51)



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: Planificación temporal

(52)



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

(53)



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

(54)



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]

(55)



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

(56)



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

(57)



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

(58)



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

(59)



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 y_Diseño Programación Pruebas Pruebas de_Integración Pruebas de_Aceptació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 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 [Piattini et al. 2004] Gestión de Proyectos: Planificación temporal

(60)



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.

(61)



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

(62)



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)

(63)



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

(64)

www.kybele.urjc.es 64 Ingeniería del Software de Gestión



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.

(65)



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

(66)



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

(67)



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

(68)



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

(69)



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.

(70)



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

(71)



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

(72)

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

(73)



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 Actividades precedentes ivi da de s s igu ien te s Gestión de Proyectos: Planificación temporal

(74)

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

(75)



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

(76)



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

TE_i TL_i TE_j TL_j 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

(77)



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

TE_j = máx [ TE_i + T_ij ]

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

(78)



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

(79)



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.

TL_i = min [ TL_j - T_ij ]

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

(80)

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

(81)



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

(82)



Holgura total de una actividad y camino crítico:

Holgura total de una actividad:

HT_ij = TL_j - TE_i - T_ij

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

(83)



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.

(84)



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.

(85)



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.

(86)



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

(87)



Estrategia genérica. Diagrama de Gantt con MS

Project

(88)



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

(89)

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 Gestión de Proyectos:

(90)

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

Planificación temporal (Ejercicios)

(91)



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

(92)



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

(93)

 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