tema ix: gestión de proyectos: planificación.is... · reunión preliminar cliente-ingeniero de...

www.kybele.urjc.es

Diana M. Sánchez Fúquene Ingeniería del Software de Gestión

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

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

www.kybele.urjc.es

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

[Pressman, 2010]


Introducción

www.kybele.urjc.es

Objetivo de la planificación

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


Introducción

www.kybele.urjc.es

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

5 Ingeniería del Software de Gestión

[Pressman, 2010]

www.kybele.urjc.es

Observaciones sobre la estimación

Estimación Riesgo Incertidumbre …… Error!

Factores que influyen en la estimación:

Complejidad del proyecto

Tamaño del proyecto


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


www.kybele.urjc.es

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



www.kybele.urjc.es

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.



www.kybele.urjc.es

Agenda


Introducción

Estimación:


Recursos



www.kybele.urjc.es

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: Estimación – Ámbito del Software

www.kybele.urjc.es

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



www.kybele.urjc.es

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?



www.kybele.urjc.es

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.



www.kybele.urjc.es


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



www.kybele.urjc.es


Rendimiento y restricciones Habituales

Fiabilidad Habitual

Interfaz con otros sistemas Operador de telefonía


Ejercicio de Análisis 2


www.kybele.urjc.es

Índice


Introducción

Estimación:


Recursos



www.kybele.urjc.es

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

www.kybele.urjc.es

Recursos del Proyecto

Personal Componentes software reutilizables

Entorno de desarrollo

[Pressman, 2010]



www.kybele.urjc.es

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



www.kybele.urjc.es

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

www.kybele.urjc.es

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

www.kybele.urjc.es

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)

www.kybele.urjc.es


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)

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


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

www.kybele.urjc.es


Recursos de entorno

Entorno de desarrollo • PCs en Red + Impresora

• Herramientas Sw de Desarrollo + BBDD

Entorno de destino • PC + Impresora

• Algún componente SW



www.kybele.urjc.es


Estimaciones sobre proyectos similares

Gestión de una biblioteca

Registro de libros

Registro de clientes

Gestión del préstamo

Listados



www.kybele.urjc.es


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




www.kybele.urjc.es

Índice


Introducción

Estimación:


Recursos



www.kybele.urjc.es

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)

Estimación ≠ Oferta


www.kybele.urjc.es

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



www.kybele.urjc.es


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


www.kybele.urjc.es

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

www.kybele.urjc.es


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


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

www.kybele.urjc.es


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 * PM0.38

Semi-libre PM = 3.0 * KLDC 1.12 TD = 2.5 * PM0.35

Empotrado PM = 2.8 * KLDC 1.20 TD = 2.5 * PM0.32

www.kybele.urjc.es


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

Restricciones a la duración del proyecto 1.23 1.08 1 1.04 1.10


www.kybele.urjc.es


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

www.kybele.urjc.es

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

Albretch 1979 (IBM)

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



www.kybele.urjc.es


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)

www.kybele.urjc.es



www.kybele.urjc.es


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.


www.kybele.urjc.es

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


www.kybele.urjc.es


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


www.kybele.urjc.es


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. Métodos de llamada a la misma consulta.


www.kybele.urjc.es


Clasificación de Componentes:

Para salidas

y consultas

Para entradas




1-5 6-19 20+

0 ó 1 Alto Alto Promedio





1-4 5-14 16+

0 ó 1 Bajo Bajo Promedio




www.kybele.urjc.es



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 =

Cuenta Total

www.kybele.urjc.es

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?



www.kybele.urjc.es



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

Sin Influencia Incidental Moderado Medio Significativo Esencial

www.kybele.urjc.es


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

www.kybele.urjc.es



Aplicación de los puntos de función:

Productividad = PF / persona-mes

Calidad = Errores / PF

Costo = Dólares / PF

Documentación = Pags. Doc / PF



www.kybele.urjc.es

Índice


Introducción

Estimación:


Recursos



www.kybele.urjc.es

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

www.kybele.urjc.es

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



www.kybele.urjc.es

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



www.kybele.urjc.es

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]


www.kybele.urjc.es

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



www.kybele.urjc.es

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



www.kybele.urjc.es

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



www.kybele.urjc.es

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



www.kybele.urjc.es

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

SistemaAnálisis y

DiseñoProgramación Pruebas

Pruebas de

IntegraciónPruebas 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

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



www.kybele.urjc.es


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.



www.kybele.urjc.es



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


www.kybele.urjc.es

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)




www.kybele.urjc.es

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



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.

www.kybele.urjc.es

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


www.kybele.urjc.es

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



www.kybele.urjc.es

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



www.kybele.urjc.es

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



www.kybele.urjc.es

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

4A

B

C

D

Para poder iniciar cualquiera

de las actividades B, C, o D, es

necesario que haya finalizado

la actividad A.


www.kybele.urjc.es

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



www.kybele.urjc.es

Diagramas PERT. Conflictos entre actividades: Solución

Añadir una actividad ficticia de duración cero

A

B

C

D

E

F



www.kybele.urjc.es

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


www.kybele.urjc.es

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 XC XD XE XF XG XH X X

Actividades precedentes

Act

ivid

ades

sig

uie

nte

s


www.kybele.urjc.es

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


www.kybele.urjc.es

Diagramas PERT. Representación

Grafo

1 2

5

4

3

6

7

A

B

C

D

E

F

G

H



www.kybele.urjc.es

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.


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 para

comenzar la actividad A

Tiempo más temprano para

finalizar la actividad A

Tiempo más tardío para

finalizar la actividad A


www.kybele.urjc.es

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



www.kybele.urjc.es

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

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



www.kybele.urjc.es Ingeniería del Software de Gestión 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.

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


www.kybele.urjc.es

Diagramas PERT

Ejemplo

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



www.kybele.urjc.es

Holgura total de una actividad y camino crítico:

Holgura 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 crítico si Hi = 0



www.kybele.urjc.es

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



www.kybele.urjc.es

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.



www.kybele.urjc.es

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:

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.



www.kybele.urjc.es

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.

HIij = TEj - TLi - Tij

Este dato indica la cantidad de holgura disponible si todas las actividades han comenzado en sus tiempos late.



www.kybele.urjc.es

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



www.kybele.urjc.es

Estrategia genérica. Diagrama de Gantt con MS Project



www.kybele.urjc.es

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

www.kybele.urjc.es Ingeniería del Software de Gestión 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

P F, G 7


www.kybele.urjc.es

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




www.kybele.urjc.es

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



www.kybele.urjc.es

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



www.kybele.urjc.es

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


Bibliografía

tema ix: gestión de proyectos: planificación.is... · reunión preliminar cliente-ingeniero de...

Documents