Post on 25-Aug-2020
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
Ingeniería del Software
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
Gestión de Proyectos:
Estimación
CURSO 2009‐2010
5
Ingeniería del Software
Puntos clave de la estimación
Ámbito del software
Estimación de recursos
Gestión de Proyectos:
Estimación
CURSO 2009‐2010
6
Ingeniería del Software
Á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
Gestión de Proyectos:
Estimación – Ámbito
CURSO 2009‐2010
7
Ingeniería del Software
Á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?
Gestión de Proyectos:
Estimación – Ámbito
CURSO 2009‐2010
8
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Ámbito
CURSO 2009‐2010
9
Ingeniería del Software
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.
Gestión de Proyectos:
Estimación – Ámbito
CURSO 2009‐2010
10
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Ámbito
CURSO 2009‐2010
11
Ingeniería del Software
Ejemplo. Software de un teléfono móvilRendimiento y restricciones
Habituales
FiabilidadHabitual
Interfaz con otros sistemasOperador de telefonía
Gestión de Proyectos:
Estimación – Ámbito
CURSO 2009‐2010
12
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Recursos
CURSO 2009‐2010
13
Ingeniería del Software
Especificación de recursos
Descripción del recurso
Informe de disponibilidad
Fecha cronológica en la que se requiere el recurso
Tiempo de aplicación del recurso
Gestión de Proyectos:
Estimación – Recursos
CURSO 2009‐2010
14
Ingeniería del Software
Recursos humanosÁmbito habilidades necesarias
Posición dentro del organigrama (experto, senior, junior)
Especialidad (bases de datos, programación, interfaces, telecomunicaciones)
Número de personas estimación del esfuerzo de desarrollo
Gestión de Proyectos:
Estimación – Recursos de desarrollo
CURSO 2009‐2010
15
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Recursos de desarrollo
CURSO 2009‐2010
16
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Recursos de desarrollo
CURSO 2009‐2010
17
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Recursos de desarrollo
CURSO 2009‐2010
18
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Recursos de desarrollo
CURSO 2009‐2010
19
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Recursos de desarrollo
CURSO 2009‐2010
20
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Recursos de desarrollo
CURSO 2009‐2010
21
Ingeniería del Software
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
Gestión de Proyectos:
Estimación – Recursos de desarrollo
CURSO 2009‐2010
22
Ingeniería del Software
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)
Gestión de Proyectos:
Estimación – Proceso de estimación
CURSO 2009‐2010
23
Ingeniería del Software
Técnicas de descomposición. Estimaciones de líneas de código (LDC)
La descomposición en subfunciones/componentes es esencial
Basado en la estimación de proyectos anteriores (experiencia)
Estimación basada en Puntos de Función (PF), Alan Albretch 1979 (IBM)
Gestión de Proyectos:
Estimación – Proceso de estimación
CURSO 2009‐2010
24
Ingeniería del Software
Técnicas de descomposición. Estimación basada en Puntos de Función (PF) Valores de ajuste de la complejidad:1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?2. ¿Se requiere comunicación de datos?3. ¿Existen funciones de procesamiento distribuido?4. ¿Es crítico el rendimiento?5. ¿Se ejecutaría el sistema en un entorno operativo existente y fuertemente utilizado?6. ¿Requiere el sistema entrada de datos interactiva?7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a
cabo sobre múltiples pantallas u operaciones?8. ¿Se actualizan los archivos maestros de forma interactiva?9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?10. ¿Es complejo el procesamiento interno?11. ¿Se ha diseñado el código para ser reutilizable?12. ¿Están incluidas en el diseño la conversi6n y la instalaci6n?13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes
organizaciones?14. ¿Se ha diseñado la aplicaci6n para facilitar los cambios y para ser fácilmente utilizada
por el usuario?
Gestión de Proyectos:
Estimación – Proceso de estimación
CURSO 2009‐2010
25
Ingeniería del Software
Técnicas de descomposición. Estimación basada en Puntos de Función (PF) Valores de ajuste de la complejidad:
Aplicación de los puntos de función:Productividad = PF / persona‐mes
Calidad = Errores / PF
Costo = Dólares / PF
Documentación = Pags. Doc / PF
Gestión de Proyectos:
Estimación – Proceso de estimación
CURSO 2009‐2010
26
Ingeniería del Software
FP = cuentaFP = cuenta‐‐total x [ 0,65 + 0,01 x total x [ 0,65 + 0,01 x ΣΣ (F(Fii ) ]) ]
Modelos empíricos: COCOMO II (COnstructive COst Model)Modelo algorítmico que trata de establecer una relación matemática que permite estimar el esfuerzo y tiempo requerido para desarrollar un producto
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
Gestión de Proyectos:
Estimación – Proceso de estimación
CURSO 2009‐2010
27
Ingeniería del Software
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.
Gestión de Proyectos:
Estimación – Proceso de estimación
CURSO 2009‐2010
28
Ingeniería del Software
http://www.enciclopedia.galeon.com/cocomo.html
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
Gestión de Proyectos:
Estimación – Proceso de estimación
CURSO 2009‐2010
29
Ingeniería del Software
http://www.enciclopedia.galeon.com/cocomo.html
30
Gestión de Proyectos:
Gestión de Riesgos ‐ Índice
CURSO 2009‐2010Ingeniería del Software
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
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
CURSO 2009‐2010Ingeniería del Software
¿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.
Gestión de Proyectos:
Gestión de Riesgos ‐ Introducción
33
CURSO 2009‐2010Ingeniería del Software
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
Gestión de Proyectos:
Gestión de Riesgos ‐ Introducción
34
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos ‐ Introducción
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
CURSO 2009‐2010Ingeniería del Software
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.
Gestión de Proyectos:
Gestión de Riesgos ‐ Introducción
36
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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 Riesgos2.1. Planificación de la gestión de riesgos2.2. Resolución de riesgos2.3. Monitorización
37
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
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.
Gestión de Proyectos:
Gestión de Riesgos – Estimación
46
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Estimación
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
CURSO 2009‐2010Ingeniería del Software
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
Gestión de Proyectos:
Gestión de Riesgos – Estimación
48
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
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 Riesgos2.1. Planificación de la gestión de riesgos2.2. Resolución de riesgos2.3. Monitorización
49
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Control
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Control
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
CURSO 2009‐2010Ingeniería del Software
Gestión de Proyectos:
Gestión de Riesgos – Control
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
Gestión de Proyectos:
Planificación temporal y seguimiento del proyecto
CURSO 2009‐2010
53
Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
54
Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
55
Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
56
Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
57
Ingeniería del Software
Desarrollo del plan de desarrollo (calendariocalendario). Fases1. Definición de los objetivos del proyecto
“Objetivo del proyecto”: enunciado que especifica los resultados que se deben conseguir
Características de un buen objetivo: asequible, definitivo, cuantificabley de duración específica
2. Descomposición de las actividadesDiagrama de descomposición de actividades
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
58
Ingeniería del Software
Desarrollo del plan de desarrollo (calendariocalendario). FasesDiagrama de descomposición de actividades
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
59
Ingeniería del Software
00
J.L. Fernández
Proyecto dedesarrollo X
10 20 30 40
J.L. Fernández
Gestión delProyecto
Ingeniería del Sistema
Desarrollo delSoftware
Pruebas de integración y del
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.
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
60
Ingeniería del Software
Desarrollo del plan de desarrollo (calendariocalendario). Fases5. Ajuste del calendario a las restricciones del proyecto. Objetivos
Determinar la duración total del proyecto cualquier técnica para la determinación del calendario Identificar las actividades que contribuyen a la duración total del proyecto (actividades críticas) Redes de 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
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
61
Ingeniería del Software
Técnicas Diagramas de hitos
Es un cuadro o tabla formada por dos columnas:
VentajasVentajas: facilidad de uso (es el método más simple) y mínimo coste de preparación (todo el mundo lo comprende inmediatamente)DesventajasDesventajas: incertidumbre existente sobre las fechas de comienzo de las actividades y la imposibilidad de reflejar las interrelaciones entre ellas.Se utiliza para resumir calendarios complejos
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
62
Ingeniería del Software
Tarea Fecha fin
Tarea 1.1 Marzo‐2006
Tarea 1.2 Mayo‐2006
Tarea 1.3 Junio‐2006
Tarea 2.1 Mayo‐2006
Tarea 2.2 Agosto‐2006
Tarea 2.3 Octubre‐2006
Técnicas Gráfico de tiempo (Diagrama de Gantt)
Diagrama de barras en forma de tabla donde se hace una referencia cruzada entre las tareas (filas) y los tiempos de duración (unidades de tiempo) de las mismas (columnas)
Muestra claramente la duración de las actividades y la precedencia de unas tareas con respecto a otras.
Se utiliza frecuentemente en proyectos pequeños (menos de 25 actividades)
InconvenienteInconveniente: NO permite representar las dependencias entre actividades.
VentajasVentajas: SÍ expresa claramente los solapamientos entre actividades.
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
63
Ingeniería del Software
Técnicas Gráfico de tiempo (Diagrama de Gantt)
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
64
Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
65
Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
66
Ingeniería del Software
Técnicas Redes de precedencia.
Técnica de evaluación y revisión de programa (PERT)
Centrado en los eventos o sucesos (como hitos)
Permite el tratamiento de la probabilidad para estimar el tiempo
Proyectos con alto grado de incertidumbre
Método del camino crítico (CPM)
Centrado en las actividades
Actividades bien definidas
Aplicación en proyectos industriales con bajo grado de incertidumbre
Gestión de Proyectos:
Planificación temporal
CURSO 2009‐2010
67
Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal – Diagramas PERT68
2
A
1
Suceso SucesoActividad
CURSO 2009‐2010Ingeniería del Software
Diagramas PERT. PrincipiosRelaciones de precedenciaRelaciones de precedencia: actividades que deben estar finalizadas justamente antes del comienzo de la actividad dada
Gestión de Proyectos:
Planificación temporal – Diagramas PERT69
RELACIONES DEPRECEDENCIA
LINEALES
RELACIONES DEPRECEDENCIADIVERGENTES
1 2 3
RELACIONES DEPRECEDENCIA
CONVERGENTES
A B
Para iniciar la actividad B esnecesario haber finalizado laactividad A. El suceso 2 es suceso final de A y suceso inicio de B.
1
2
3
4 5
A
B
C
D
Para iniciar la actividad D esnecesario haber finalizado lasactividades A, B y C.
1
3
2
5
4A
B
C
D
Para poder iniciar cualquierade las actividades B, C, o D, esnecesario que haya finalizado la actividad A.
CURSO 2009‐2010Ingeniería del Software
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.
Gestión de Proyectos:
Planificación temporal – Diagramas PERT70
A
B
C
D
E
No se cumple la regla 1: Es necesario que finalice C para que comience D
CURSO 2009‐2010Ingeniería del Software
Diagramas PERT. Conflictos entre actividades: SoluciónAñadir una actividad ficticia de duración cero
Gestión de Proyectos:
Planificación temporal – Diagramas PERT71
CURSO 2009‐2010Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal – Diagramas PERT72
CURSO 2009‐2010Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal – Diagramas PERT73
A B C D E F G HAB XC XD XE XF XG XH X X
Actividades precedentes
Act
ivid
ades
sigu
ient
es
CURSO 2009‐2010Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal – Diagramas PERT74
Actividades Actividades
Precedentes
A ‐
B A
C A
D A
E B
F C
G D
H E, F
CURSO 2009‐2010Ingeniería del Software
Diagramas PERT. RepresentaciónGrafo
Gestión de Proyectos:
Planificación temporal – Diagramas PERT75
CURSO 2009‐2010Ingeniería del Software
Actividades Actividades
Precedentes
A ‐
B A
C A
D A
E B
F C
G D
H E, F
Diagramas PERT. RepresentaciónGrafo
Gestión de Proyectos:
Planificación temporal – Diagramas PERT76
1 2
5
4
3
6
7
A
B
C
D
E
F
G
H
CURSO 2009‐2010Ingeniería del Software
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.
Gestión de Proyectos:
Planificación temporal – Diagramas PERT77
CURSO 2009‐2010Ingeniería del Software
ATEi TLi TEj TLj
suceso i suceso j
Tiempo más temprano para comenzar la actividad A (tiempo early de comienzo de A)
Tiempo más tardío paracomenzar la actividad A
Tiempo más temprano parafinalizar la actividad A
Tiempo más tardío parafinalizar la actividad A
Diagramas 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
Gestión de Proyectos:
Planificación temporal – Diagramas PERT78
CURSO 2009‐2010Ingeniería del Software
Diagramas PERTSupongamos calculados los tiempos PERT de cada actividad:
Gestión de Proyectos:
Planificación temporal – Diagramas PERT79
Actividad A B C D E F G H
Duración 8 5 6 5 6 7 9 3
3
4
5
6
7A1 2
B
C
D
E
FH
G
8
5
6
5
6
7
9
3
0 8
13
14
13
21
24
19
22
CURSO 2009‐2010Ingeniería del Software
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
Gestión de Proyectos:
Planificación temporal – Diagramas PERT80
CURSO 2009‐2010Ingeniería del Software
Diagramas PERT
Gestión de Proyectos:
Planificación temporal – Diagramas PERT81
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
CURSO 2009‐2010Ingeniería del Software
Holgura total de una actividad y camino crítico:Holgura de un suceso iHolgura de un suceso i:
Hi = TLi ‐ TEi
Indica el número de unidades de tiempo en que se puede retrasar su realización de forma que no se aumente la duración total del proyecto.
Se dice que un suceso es crsuceso es críítico tico si Hi = 0Hi = 0
Gestión de Proyectos:
Planificación temporal – Diagramas PERT82
CURSO 2009‐2010Ingeniería del Software
Holgura total de una actividad y camino crítico:Holgura total de una actividadHolgura total de una actividad:
HTij = TLj ‐ TEi ‐ Tij
Representa el número de unidades de tiempo que puede retrasarse la realización de la actividad con respecto al tiempo PERT previsto, sin que aumente la duración del proyecto.
Se dice que una actividad es cractividad es críítica tica si la holgura total = 0holgura total = 0
Gestión de Proyectos:
Planificación temporal – Diagramas PERT83
CURSO 2009‐2010Ingeniería del Software
Holgura total de una actividad y camino crítico:Camino crCamino crííticotico: camino que se forma uniendo todas las actividades críticas desde el suceso inicial al suceso final del proyecto
Cualquier retraso que sufra alguna de las actividades del caminocrítico, implicará un retraso del proyecto.
El jefe de proyecto no debe sólo prestar atención a las actividades críticas sino también a las que no lo son, ya que si una actividad no crítica consume el total de su holgura, se convierte en crítica, y aparecería un nuevo camino crítico.
Gestión de Proyectos:
Planificación temporal – Diagramas PERT84
CURSO 2009‐2010Ingeniería del Software
Ejercicio
Gestión de Proyectos:
Planificación temporal – Diagramas PERT85
CURSO 2009‐2010Ingeniería del Software
Actividad Actividades precedentes Duración
A B,D 3
B C 6
C J 4
D I, M 8
E I, M 9
F I, M 3
G H 5
H J 4
I J 2
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
Gestión de Proyectos:
Seguimiento y supervisión
CURSO 2009‐2010
86
Ingeniería del Software
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
Gestión de Proyectos:
Plan del Proyecto
CURSO 2009‐2010
87
Ingeniería del Software
Gestión de Proyectos:
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
CURSO 2009‐2010Ingeniería del Software
88
Resumen
CURSO 2009‐2010
89
Ingeniería del Software
Roger S. Pressman. Ingeniería del Software: Un enfoque práctico. Capítulo 3.Ed. McGraw Hill. 5ª edición.2002
M. Piattini et al. Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión. Ed. Ra‐Ma. 1996
IEEE Std 1058.1‐1987, IEEE Standard for Software Project Management Plans. http://ieeexplore.ieee.org/iel1/2591/955/00025325.pdf
Bibliografía
CURSO 2009‐2010
90
Ingeniería del Software