Gestion de Proyectos Parte II - kybele.etsii.urjc.esIS3_0910... · ÙTiempo, esfuerzo, recursos...

$: Gestion de Proyectos Parte II - kybele.etsii.urjc.esIS3_0910... · ÙTiempo, esfuerzo, recursos (HW, SW, humanos) y riesgo {Difícil, pero no imposible {No es una ciencia exacta,$
INGENIERÍA DEL SOFTWARE

CURSO 2009‐2010

Gestión de Proyectos II:Planificación de Proyectos

2

Introducción

CURSO 2009‐2010Ingeniería del Software

Duración Proyecto

Tiempo

90%

Planificación de proyectos. DefiniciónConjunto de actividades previas a la puesta en marcha del proyecto

ObjetivoObjetivoProporcionar 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 2009‐2010

3

Ingeniería del Software

EstimaciónAntes 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 2009‐2010

4


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

Complejidad del proyectoMedida 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 estructuralGrado de definición de requisitosFacilidad de subdivisión de funcionesInformación a procesar

Disponibilidad de información históricaRiesgoRiesgo = grado de incertidumbre de la fiabilidad de las estimaciones cuantitativasLa estimación es una utilidad, no un producto Puede (debe) revisarse periódicamente


Estimación

CURSO 2009‐2010

5


Puntos clave de la estimación

Ámbito del software

Estimación de recursos


Estimación

CURSO 2009‐2010

6


Ámbito del softwarePrimera 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


Estimación – Ámbito

CURSO 2009‐2010

7


Ámbito del softwareObtenció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ónPreguntas para entender el problema y que el cliente describa (esboce) la soluciónPreguntas sobre la efectividad del primer encuentro

Viabilidad: factibilidad del software Percepción de los riesgosTecnologí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?



CURSO 2009‐2010

8


Trabajo en ClaseDefinir el Ámbito del Software de un teléfono móvil

Control y datos a procesar. Funcionamiento habitual

Funciones principales/importantes

Rendimiento y restricciones

Fiabilidad

Interfaces con otros sistemas



CURSO 2009‐2010

9


Ejemplo. Software de un teléfono móvilControl 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.



CURSO 2009‐2010

10


Ejemplo. Software de un teléfono móvilFunciones 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



CURSO 2009‐2010

11


Ejemplo. Software de un teléfono móvilRendimiento y restricciones

Habituales

FiabilidadHabitual

Interfaz con otros sistemasOperador de telefonía



CURSO 2009‐2010

12


Segunda tarea en la planificación del desarrollo de SWEstimación de los recursos requeridos para acometer el esfuerzo de desarrollo de software

Recursos de desarrolloPersonal

Recurso primario

Componentes software reutilizablesBloques SW que reducen los costes de desarrollo y aceleran la entrega

Entorno de desarrolloHerramientas hardware/software

Infraestructura de soporte al esfuerzo de desarrollo


Estimación – Recursos

CURSO 2009‐2010

13


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


Estimación – Recursos

CURSO 2009‐2010

14


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


Estimación – Recursos de desarrollo

CURSO 2009‐2010

15


Ejemplo. Gestión de un videoclubRecursos humanos

Programadores

Registro de películas (junior)

Registro de socios (junior)

Gestión del alquiler (senior)

Listados (senior)

Especialista

Diseño de la BBDD



CURSO 2009‐2010

16


Recursos de software reutilizablesComponentes ya desarrolladosdesarrollados

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



CURSO 2009‐2010

17


Ejemplo . Gestión de un videoclubRecursos software reutilizables

Componentes ya desarrollados

No aplicable

Componentes ya experimentados

Gestión de una biblioteca

Componentes experimentados parcialmente

No recomendable

Componentes nuevos

Totalmente aplicable



CURSO 2009‐2010

18


Recursos del entornoEntorno de desarrollo

Hw y Sw donde se va a desarrollar

Entorno de producción/explotaciónHw y Sw donde se va a ejecutar



CURSO 2009‐2010

19


Ejemplo. Gestión de un videoclubRecursos de entorno

Entorno de desarrollo

PCs en Red + Impresora

Herramientas SW de Desarrollo + BBDD

Entorno de producción/explotación

PC + Impresora

Algún componente SW



CURSO 2009‐2010

20


Ejemplo. Gestión de un videoclubEstimaciones sobre proyectos similares

Gestión de una biblioteca

Registro de libros

Registro de clientes

Gestión del préstamo

Listados



CURSO 2009‐2010

21


Ejemplo. Gestión de un videoclubFunciones importantes

Registrar películas y socios

Gestión del Alquiler

Listados

Recursos HumanosProgramadores senior: 2

Programadores junior: 1

Especialista diseño BBDD: 1



CURSO 2009‐2010

22


Estimación de proyectos softwareImportancia: SW es el elemento más caro de un sistema informáticoError 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 similaresTécnicas de descomposición (LDC, PF)Modelos empíricos (COCOMO)Herramientas automáticas

Decisión desarrollar/comprarCriterios: fecha de entrega/coste+personalización/soporte externoSubcontratación (outsourcing)


Estimación – Proceso de estimación

CURSO 2009‐2010

23


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)



CURSO 2009‐2010

24


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?



CURSO 2009‐2010

25


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



CURSO 2009‐2010

26


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

KLDC: Miles de Líneas de Código

a y b: parámetros de ajuste (dependientes del Tipo de Proyecto)

Esfuerzo: personas‐mes

Esfuerzo = a * (KLDC)b



CURSO 2009‐2010

27


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

Define tres tipos de proyectos (COCOMO II):Orgánico: proyectos relativamente sencillos, menores de 50 KLDC 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 KLDC), 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.



CURSO 2009‐2010

28



Tipo de proyecto Personas‐mes Tiempo de Desarrollo

Orgánico PM = 3.2 * KLDC1.05 TD = 2.5 * PM0.38

Semi‐libre PM = 3.0 * KLDC1.12 TD = 2.5 * PM0.35

Empotrado PM = 2.8 * KLDC1.20 TD = 2.5 * PM0.32

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



CURSO 2009‐2010

29



30


Gestión de Riesgos ‐ Índice


1. Introducción a la Gestión de Riesgos

2. Estimación de Riesgos2.1. Identificación

2.2. Análisis

2.3. Priorización

3. Control de Riesgos3.1. Planificación de la gestión de riesgos3.2. Resolución de riesgos3.3. Monitorización

31



Gestión de Riesgos ‐ Introducción

¿QUÉ ES LA GESTIÓN DE RIESGOS?

El análisis y la gestión de riesgos son una serie de pasos que ayudan a un equipo de software a comprender y manejar la incertidumbre.

Un riesgo es un problema potencial: puede ocurrir o no.

Si ocurre sería bueno que previamente hayamos “perdido” un poco de tiempo en:

‐ Identificarlo

‐ Evaluar la probabilidad de que ocurra

‐ Estimar su impacto

‐ Establecer un plan de contingencia

32


¿QUIEN LO HACE?

Teoría: Todos los interesados en el proceso de software: gestores, jefes de proyecto, programadores y resto de participantes.

Práctica: El jefe de proyecto ha de potenciar esta actividad, que consumirá recursos y tiempo y que generalmente no es muy bien vista por el resto de integrantes del equipo.

¿CUAL ES EL PRODUCTO OBTENIDO?

Se produce un plan de reducción, supervisión y gestión del riesgo o un conjunto de hojas informativas de riesgo.



33


SIETE PRINCIPIOS DE LA GESTIÓN DE RIESGOS

El Software Ingineering Institute identifica siete principios que establecen un marco de trabajo para lograr una gestión de riesgos efectiva:

1. Mantenimiento de una perspectiva global

2. Tener una visión previsora

3. Alentar la comunicación abierta

4. Integración

5. Enfatizar un proceso continuo

6. Desarrollo de una visión conjunta del producto

7. Alentar el trabajo en equipo



34




ALGUNAS CONSIDERACIONES SOBRE LOS RIESGOS….

“La gestión de riesgos es la gestión de proyectos para adultos.”

Tim Lister

“Si no atacas activamente los riesgos, ellos te atacarán activamente.”

Tom Gilb

“[En la actualidad] nadie tiene el lujo de llegar a conocer una tarea tan bien que no se

lleve sorpresas, y las sorpresas significan riesgo.”

Stephen Grey

“Si tomo demasiadas precauciones, es porque no dejo nada al azar.”

Napoleón

35


NIVELES DE GESTIÓN DE RIESGOS

La función de la gestión de riesgos es identificar, estudiar y eliminar las fuentes de riesgo antes de que empiecen a amenazar la finalización satisfactoria de un proyecto software.

1. Control de Crisis: apagar el fuego. Controlar los riesgos sólo cuando se han convertido en problemas

2. Arreglar cada error: Reaccionar rápidamente ante cualquier riesgo, pero sólo después de que se haya producido.

3. Mitigar los riesgos: Planificar con antelación el tiempo que me llevaría solucionarlos pero no hacer nada más.

4. Prevención: Crear y llevar a cabo un plan como parte del proyecto software para identificar riesgos y evitar que se conviertan en problemas

5. Eliminación de las causas principales: Identificar y eliminar los factores que puedan hacer posible la presencia de algún tipo de riesgo.



36



Gestión de Riesgos – Estimación



2.2. Análisis

2.3. Priorización


37




IDENTIFICACIÓN DE RIESGOS

El primer paso de la gestión de riesgos es identificar los factores que introducen un riesgo en nuestro proyecto. Al comenzar un proyecto existen 3 riesgos generales:

- Cometer uno de los errores clásicos del desarrollo del software.- Ignorar las bases del desarrollo.- Fallar en la gestión activa de Riesgos.

38




RIESGOS MÁS COMUNES

• Cambio de requisitos

• Meticulosidad en requerimientos o desarrolladores

• Escatimar en la Calidad

• Planificaciones demasiados optimistas

• Diseño inadecuado

• Síndrome de la panacea

• Desarrollo orientado a la investigación

• Personal mediocre

• Error en la contratación

• Diferencias entre el personal de desarrollo y los clientes

39




LISTA COMPLETA DE RIESGOS

Partimos de una lista exhaustiva de los riesgos que pueden afectar a la planificación de un proyecto. Clasificados por categorías sin un orden concreto:

• Creación de la planificación

• Organización y Gestión

• Entorno de Desarrollo

• Usuarios Finales

• Cliente

• Personal Contratado

• Requisitos

• Diseño e implementación

• Fuerzas mayores

• Riesgos específicos de nuestro producto (son los más importantes)

40




ANÁLISIS DE RIESGOS: EXPOSICIÓN A RIESGOS

Una vez que haya identificado los riesgos de su proyecto, el paso siguiente es analizar cada uno de ellos para evaluar su impacto.

Un método útil en este análisis es determinar “la exposición a riesgos” de cada uno de los riesgos identificados en el punto anterior.

Exposición de Riesgos = Probabilidad de que ocurra x Magnitud de la pérdida

Ejemplo: Probabilidad de tener que implementar una nueva funcionalidad = 25%

Tiempo de desarrollo de la funcionalidad = 4 semanas

Exposición al riesgo = 1 semana.

41




TABLA DE ESTIMACIÓN DE RIESGOS

Riesgo Probabilidad Magnitud(semanas)

Exposición(semanas)

Retraso del sistema de Gestión de Usuarios

75% 4 3

Problemas con la integración del componente de terceros de Edición de Texto.

25% 8 2

Retraso en la Licencia del componente 10% 2 0,2

Baja productividad debido al nuevo entorno de desarrollo

50% 3 1,5

Problemas en la definición de consultas sobre el sistema contable externo

50% 2 1

¿Probabilidad y magnitud? Estimación, no se puede pretender que sean exactos

42




ESTIMACIÓN DE LA MAGNITUD

Suele ser más fácil de estimar que la probabilidad de que ocurra un riesgo.

Si nos es difícil la estimación se puede utilizar la técnica de dividir las magnitudes, estimarlas, y recomponer la estimación de una forma más sencilla que la global.

Si no nos es posible subdividir la magnitud: optar por una estimación apoyándonos en nuestra experiencia y anotar los resultados de nuestra estimación para futuros análisis.

43




ESTIMACIÓN DE LA PROBABILIDAD

“¿Qué probabilidad hay que de este posible problema se convierta en realidad?”

La respuesta es más subjetiva que la estimación de la magnitud.

Técnicas de ayuda:

‐ Apoyarse en alguna persona familiarizada con el sistema u otros sistemas desarrollados anteriormente.

‐ Usar técnicas Delphi.

‐ Utilizar la “calibración mediante adjetivos”. Cada persona del equipo puede valorar el nivel de riesgo como: muy probable, bastante probable, improbable, muy improbable.

Después convertir: estimación verbal estimación cuantitativa

44




RETRASO TOTAL DEL PROYECTO

Sumando todas las exposiciones de riesgos calculadas en la tabla anterior obtendremos el retraso total del Proyecto.

La magnitud de este retraso total esperado permite intuir el nivel global de riesgo del proyecto.

El ejemplo anterior muestra un retraso esperado 7,7 semanas si no realizamos ninguna gestión de riesgos.

Se puede utilizar este valor para cambiar nuestra planificación en lugar de la regla generalmente utilizada: “20‐30% por los imprevistos”

45


PRIORIZACIÓN DE RIESGOS: INTRODUCCIÓN

Una vez identificados y analizados los riesgos del proyecto el siguiente paso es la priorización de los mismos:

¿Dónde debo centrar mi esfuerzo en la gestión de riesgos?

Los proyectos gastan el 80% del presupuesto en arreglar el 20% de sus problemas.

Claramente nos interesa enfocarnos sobre este 20% más importante.

Es IMPOSIBLE gestionar todos los riesgos: no haríamos nada más…y el proyecto se estancaría.



46




TABLA DE ESTIMACIÓN DE RIESGOS PRIORIZADA

Riesgo Probabilidad Magnitud(semanas)

Exposición(semanas)

Retraso del Sistema de Gestión de Usuarios

75% 4 3

Problemas en la definición de consultas sobre el sistema contable externo

50% 2 1

Baja productividad debido al nuevo entorno de desarrollo

50% 3 1,5

Problemas con la integración del componente de terceros de Edición de Texto.

25% 8 2

Retraso en la Licencia del componente 10% 2 0,2

47


Si conseguimos controlar los 3 primeros riesgos, podríamos reducir en 5,5 semanas el retraso total esperado.

Si nos centráramos en los 3 últimos reduciríamos 3,7 semanas.

Casos especiales: es posible que interese controlar un riesgo que con poca probabilidad tenga una magnitud muy grande.

Ej: consideremos un riesgo con un 10% probabilidad y 20 semanas de magnitud ¿deberíamos tenerlo en cuenta o dejarlo al final de la lista?

La ordenación de prioridades es aproximada: los números que utilizados para crear la tabla es pura estimación, por lo que el orden de la lista puede ser modificado.

La capacidad de valoración del JP es imprescindible para cada uno de los aspectos de la gestión de riesgos



48



Gestión de Riesgos – Índice



2.2. Análisis

2.3. Priorización


49



Gestión de Riesgos – Control

CONTROL DE RIESGOS: EL PLAN

El objetivo: desarrollar un plan que controle cada uno de los riesgos de prioridad alta identificados en las fases anteriores.

¿En qué consiste?

• Puede ser tan sencillo como un párrafo para cada riesgo, indicando quién, qué, cuándo y cómo se gestiona cada riesgo.

• Además de previsiones para la monitorización: descartando los riesgos resueltos e identificando los nuevos.

50




MONITORIZACIÓN

Nuestro trabajo sería más fácil si los riesgos apareciesen después de que hayamos desarrollado planes para tratarlos.

Los riesgos aparecen y desaparecen a lo largo de la vida del proyecto.

La monitorización es una actividad clave y constante desde el inicio a la finalización del proyecto de modo que podamos saber en cada momento si los riesgos identificados están “bajo control” y si en el estado actual del proyecto hay riesgos nuevos.

Métodos de monitorización:

‐ Lista de los 10 riesgos principales

‐ Comprobaciones intermedias

‐ Encargado de riesgos

51




LISTA DE LOS 10 RIESGOS PRINCIPALES

Lista de los 10 riesgos creada por nosotros mismos:

‐ Posición del riesgo en la lista

‐ Posición anterior

‐ Número de veces que ha aparecido en la lista

‐ Resumen de las actuaciones realizadas

Revisión Semanal de la lista fuerza a la revisión periódica…a volver a pensar en ello…

52




COMPROBACIONES INTERMEDIAS

No se debe esperar al final para hacer la comprobaciones, esto nos ayudará en el próximo proyecto, no en el ACTUAL.

Marcar en la planificación revisiones intermedias, por ejemplo, después de alcanzar determinados hitos del proyecto

ENCARGADO DE RIESGOS

Responsabilizar a una persona del equipo de que se realice una gestión de riesgos.

No debería ser el gestor del proyecto, puesto que una de sus misiones es obligar al responsable a no pasar por alto la gestión de riesgos.

DefiniciónActividad 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 principalConfiguración del calendario del proyecto

OrigenModelo de proceso, tareas de ingeniería, estimación de la cantidad de trabajo, número de personas, fechas de entrega, riesgos…

ResultadoPlanificación del proyecto e información asociada para su seguimiento

Documento estándar: IEEE Std 1058.1‐1987Elementos

Definición de la red de tareas (completa)Esfuerzo y tiempo asignado a cada tareaRelaciones entre las tareasRecursos asignados a las tareasEspaciado de los “hitos” para poder hacer un seguimiento del progreso


Planificación temporal y seguimiento del proyecto

CURSO 2009‐2010

53


ObjetivosDefinir 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


Planificación temporal

CURSO 2009‐2010

54


RetrasosRetrasos. RazonesFechas 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



CURSO 2009‐2010

55


Principios de la planificación Segmentación

Descomposición. Tareas y actividades manejables

InterdependenciaSecuenciación y paralelismo de tareas/actividades

Asignación de tiempoNº de unidades de trabajo (personas/mes)

Fechas de inicio/terminación

Interdependencia marca el camino crítico



CURSO 2009‐2010

56


Principios de la planificación Validación del esfuerzo

Esfuerzo (personas/día) ≤ personas disponibles

Definición de responsabilidadesTarea miembro

Resultados definidosEntregas, productos, etc.

HitosRevisión y aceptación de la calidad de un producto/resultado



CURSO 2009‐2010

57


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 actividadesDiagrama de descomposición de actividades



CURSO 2009‐2010

58


Desarrollo del plan de desarrollo (calendariocalendario). FasesDiagrama de descomposición de actividades



CURSO 2009‐2010

59


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

sistemaS. 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 Pruebas

Pruebas 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. 121Construcción deSoftwareUT. 122

ComunicacionesUT. 211

Análisis de RequisitosUT. 212

Gestión de la Base de DatosUT. 213ArquitecturaUT. 214

Diseño FuncionalUT. 311

Diseño deAlgoritmosUT. 312Diseño de laBase de DatosUT. 313

ProgramaciónUT. 321

DocumentaciónUT. 322

Soporte a lasPruebasUT. 323

Procedimientosde PruebasUT. 331Pruebas UnitariasUT. 332

Análisis de lasPruebasUT. 333

Procedimientosde PruebasUT. 411Integración delSistemaUT. 412FormaciónUT. 413

Procedimientosde PruebasUT. 421Satisfacció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 actividadesSuelen 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.



CURSO 2009‐2010

60


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 precedenciaCalcular las holguras de las actividades que no son críticas Redes de precedencia

6. Asignación de recursos. Organización del equipoAjustar el calendario en función de los recursos disponiblesImportancia 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



CURSO 2009‐2010

61


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



CURSO 2009‐2010

62


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.



CURSO 2009‐2010

63


Técnicas Gráfico de tiempo (Diagrama de Gantt)



CURSO 2009‐2010

64


Unidades de tiempo

1 2 3 4 5 6 7 8 9 10Tarea 1.1

Tarea 1.2

Tarea 1.3

Tarea 2.1

Tarea 2.2

Tarea 2.3

Diagrama de Gantt con MS Project



CURSO 2009‐2010

65


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 tiempoCuándo utilizar estas técnicas:

Actividades bien definidasActividades son entidades atómicas e independientesLas actividades pueden relacionarse entre sí y ser ordenadasExiste una ejecución secuencial de las actividadesLa red debería tener más de 20 eventos y menos de 300



CURSO 2009‐2010

66


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



CURSO 2009‐2010

67


Diagramas PERT. PrincipiosParte 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


Planificación temporal – Diagramas PERT68

2

A

1

Suceso SucesoActividad


Diagramas PERT. PrincipiosRelaciones de precedenciaRelaciones de precedencia: actividades que deben estar finalizadas justamente antes del comienzo de la actividad dada



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.


Diagramas PERT. Conflictos entre actividadesPor 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


Diagramas PERT. Conflictos entre actividades: SoluciónAñadir una actividad ficticia de duración cero




A

B

C

D

E

F

Diagramas PERT. RepresentaciónSupongamos 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




Diagramas PERT. RepresentaciónMatriz 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



A B C D E F G HAB XC XD XE XF XG XH X X

Actividades precedentes

Act

ivid

ades

sigu

ient

es


Diagramas PERT. RepresentaciónCuadro de relaciones de precedenciaCuadro 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


Diagramas PERT. RepresentaciónGrafo




Actividades Actividades

Precedentes

A ‐

B A

C A

D A

E B

F C

G D

H E, F

Diagramas PERT. RepresentaciónGrafo



1 2

5

4

3

6

7

A

B

C

D

E

F

G

H


Diagramas PERT. Asignación de tiempos a actividadesEl 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.




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




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

FH

G

8

5

6

5

6

7

9

3

0 8

13

14

13

21

24

19

22


Diagramas PERTCá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




Diagramas PERT



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

24

21

15

15

1480

10

21

248


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




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




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.




Ejercicio




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

J ‐ 0

K F, G 6

L A, E, P 4

M H 3

P F, G 7

Seguimiento de la planificaciónDefinició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 previstosRealizar acciones correctivas cuando existan desviaciones significativasAcordar compromisos con el personal afectado

Tareas:Reuniones periódicas evaluar progresoDeterminar hitos cumplidosComparar fecha real y prevista de inicioEvaluar los resultados de las revisiones


Seguimiento y supervisión

CURSO 2009‐2010

86


Plan del proyectoDefinició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

ObjetivosComunicar 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


Plan del Proyecto

CURSO 2009‐2010

87



Planificación temporal – IEEE Std 1058.1‐1987

TítuloHoja de control de cambiosPrefacioTabla de ContenidosLista de figurasLista de tablas1. Introducción

1.1 Visión General1.2 Productos finales1.3 Evolución del Plan1.4 Documentos de apoyo1.5 Definiciones y acrónimos

2. Organización del Proyecto2.1 Modelo de Proceso2.2 Estructura organizativa2.3 Fronteras e interfaces organizativas2.4 Responsabilidades

3. Procesos de gestión3.1 Objetivos y prioridades3.2 Suposiciones, dependencias y restricciones3.3 Gestión de Riesgos3.4 Mecanismos de supervisión y control3.5 Plan de Personal

4. Procesos técnicos4.1 Métodos, herramientas y técnicas4.2 Documentación del software4.3 Funciones de soporte a proyectos

5. Paquetes de trabajo, calendario y presupuesto5.1 Paquetes de trabajo5.2 Dependencias5.3 Requerimientos de recursos5.4 Presupuesto y distribución de recursos5.5 Calendario y agenda

Componentes adicionalesÍndiceApéndices


88

Resumen

CURSO 2009‐2010

89


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 2009‐2010

90


Gestion de Proyectos Parte II - kybele.etsii.urjc.esIS3_0910... · ÙTiempo, esfuerzo, recursos...

Documents

Transcript of Gestion de Proyectos Parte II - kybele.etsii.urjc.esIS3_0910... · ÙTiempo, esfuerzo, recursos...