Sep-05 Ing. de Software 1
Planificación y Gestión del Proyecto
INSTITUTO POLITÉCNICO NACIONALESCUELA SUPERIOR DE CÓMPUTO
M. En C. Eduardo Bustos Farías
Sep-05 Ing. de Software Planif. y Gestión … 2
Planificación y Gestión del Proyecto
• Gestión de Proyectos• Técnicas y Herramientas de Planificación• Métricas de Tamaño• Estimaciones de Tamaño, Esfuerzo, Costo y Duración• Recursos Humanos y Organización• Evaluación de Factibilidad• Gestión de Riesgos• Gestión de la Calidad• Gestión de la Configuración• Comunicaciones entre los involucrados• Registro y Control de Avance
Sep-05 Ing. de Software Planif. y Gestión … 3
Proyecto• Operaciones y Proyectos:
llevados a cabo por personassometidos a restricciones (recursos)se planifican, ejecutan, controlan
• Operación Continua<> Proyecto• Proyecto
inicio y fin (el proyecto)producto/servicio único (el resultado continua) ¿Alcance?
Sep-05 Ing. de Software Planif. y Gestión … 4
Conceptos fundamentalesGestión de Proyectos:• Aplicación de conocimientos, habilidades,
herramientas y técnicas a las actividades de un proyecto, para cubrir o superar las necesidades y expectativas para un proyecto
Interesados (stakeholders):• Involucrados (participan)• Interesados
afectados positiva o negativamenteAlcance:• del producto (final) – sus características• del proyecto – trabajos incluidos (y no)
Sep-05 Ing. de Software Planif. y Gestión … 5
Alcance y Expectativas
Recurso
s Tiempo
Alcance
Calidad
Balancear
Necesidades
Expectativas
Necesidades
ExpectativasTecn
ología
Personas
Proceso
Restricciones
Sep-05 Ing. de Software Planif. y Gestión … 6
Relación con otras disciplinas de la AdministraciónAdministración General• planificar, organizar, asignar personal, ejecutar y
controlar las operaciones de una empresa de operación continua
Áreas de Aplicación (categorías de proyectos)• Elementos Técnicos• Elementos Administrativos• Ramas de la Industria
Gestión deProyectos
Adminis-tración Gral.
Área deAplicación
Sep-05 Ing. de Software Planif. y Gestión … 7
Relación con otros EmprendimientosPrograma• conjunto de proyectos relacionados• a menudo incluyen elementos de Operación
Continua
Subproyecto• parte de un proyecto• a menudo contratada a un proveedor
Sep-05 Ing. de Software Planif. y Gestión … 8
Técnicas y Herramientas de Planificación
Técnica HerramientaWBS Esquema numerado Word
CPM Project (y otros)
PERT “
Gantt “
Perfil de uso de Recursos “
Evolución de gastos Planilla Electrónica
Valor Ganado Project, Planilla Electrónica
Sep-05 Ing. de Software Planif. y Gestión … 9
WBS
• Work Breakdown Structure (“descomposición jerárquica de actividades” o
“desglose de actividades”)• El proyecto se descompone teniendo en cuenta
los productos intermedios a obtener y se repite el proceso mientras resulte necesario (y posible) para el control
• Modelo de Proceso implícito• La jerarquía facilita análisis a distintos niveles• Sólo representa relaciones composición-
descomposición• No representa relaciones de precedencia
Sep-05 Ing. de Software Planif. y Gestión … 10
WBS - Ejemplo: Casa
Casa
Diseño Terreno Materiales Construcción
Planos CimientosDelimitar Adquirir
MurosMemoria Descript.
AcondicionarTechos
Sanitaria
Terminaciones
Notas: 1. No se representan relaciones de precedencia. 2. Es usual presentarlo (en lo posible) en el orden de ejecución Electricidad
Sep-05 Ing. de Software Planif. y Gestión … 11
WBS - Contra-Ejemplo: Casa
Casa
Dormitorios Living Comedor Cocina Baño
Notas: 1. En este caso hay una descomposición jerárquica del producto (no de las actividades), sin tener en cuenta los productos intermedios. 2. Considerado como WBS, ¿qué opina de la técnica constructiva implícita?
Principal
Niños
Huéspedes
Sep-05 Ing. de Software Planif. y Gestión … 12
Actividad e Hito
• Actividad es una parte de un proyecto que se lleva a cabo durante un período de tiempo.
• Un Hito es un punto en el tiempo que marca el inicio o el fin de una actividad.
• Describir cada actividadprecedentesduraciónproducto
Sep-05 Ing. de Software Planif. y Gestión … 13
Grafo de Actividades (CPM)• Se consideran:
las hojas del WBS (actividades)las relaciones de precedencia entre ellas (una actividad no puede comenzar hasta que las precedentes hayan concluido)no se admiten circuitos de precedencia
• Hoy en día lo usual es representar:actividades por bloques (compatible con Diag. Gantt)Las relaciones de precedencia por flechas (intuitivo)Hay un nodo Inicio y otro Fin (no se precisan elementos ficticios)
• Modelo del proyecto (actividades, precedencias, duraciones)
Critical Path Method
Sep-05 Ing. de Software Planif. y Gestión … 14
Grafo de Actividades
inicio fin
e.Cimientos
g.Muros
h.Techos
j.Sanitaria
i.Electricidadb.Memoria Descript.
a.Planos
c.Delimitar (Terreno)
f.Acondicionar (Terreno)
d.Adquirir (Materiales)
k.Terminaciones
Sep-05 Ing. de Software Planif. y Gestión … 15
Grafo de Actividades-conceptos básicos para las actividades
• Comienzo Temprano (lo antes que puede comenzar respetando las precedencias y las duraciones)
• Fin Temprano (la fecha de fin si la actividad comienza lo antes posible y dura lo previsto)
• Fin Tardío (lo más tarde que puede terminar la actividad sin afectar la duración del proyecto)
• Comienzo Tardío (lo más tarde que puede comenzar la actividad sin afectar la duración del proyecto)
• Holgura Total (cuanto se puede atrasar el comienzo de una actividad sin afectar la fecha de fin del proyecto
• Camino Crítico: integrado por actividades que si se atrasan, atrasan el proyecto (Holgura Total=0)
Sep-05 Ing. de Software Planif. y Gestión … 16
Grafo de Actividadescon duraciones
inicio fin
e (7)
g (5)
h (7)
j (2)
i (1)
a (3)
b (4)
d (5)
f (8)
c (5)
k (10)
0
Colores:
•Temprano
•Tardío
Sep-05 Ing. de Software Planif. y Gestión … 17
Grafo de Actividadescon duraciones
inicio fin
e (7)
g (5)
a (3)
b (4)
d (5)
f (8)
c (5)h (7)
j (2)
i (1)
k (10)
0 3
3 7
7 12
3 8
8 16 16 23
23 28
28 35
35 36
35 37
35 45
45
4535
35
4543
4544
28
2823
2316
1611
168
83
117
30
0
¿Cuál es el Camino Crítico?
Colores:
•Temprano
•Tardío
Sep-05 Ing. de Software Planif. y Gestión … 18
PERT• Como CPM pero la duraciones variables aleatorias• Estima la duración de cada actividad a partir de
estimar un valor mínimo “a” (optimista), más probable “m” y máximo “b”(pesimista)
• Le atribuye distribución Beta (no siempre simétrica) y aproxima el valor esperado por
E=(a+4m+b)/6• Aproxima σ por (b-a)/6 y considera las
duraciones como variables aleatorias independientes por lo que:
σ2camino crítico=Σ σ2
activ.camino crítico
• ¿Duraciones v.a. independientes? ¿Y los otros caminos?
Sep-05 Ing. de Software Planif. y Gestión … 19
Diagrama de GanttACTIVIDAD
WBS 1.0 PLANEAR SISTEMA
WBS 2.0 DISEÑAR SISTEMA
ENE FEB MAR ABR MAY JUN JUL AGO SEP OCT NOV DIC
1.1 Revisar especificación
1.2 Revisar presupuesto
1.3 Revisar calendario
1.4 Desarrollar plan
2.1 Diseño de alto nivel
2.2 Prototipar
2.3 Interfaz de usuario
2.4 Diseño detallado
Completada Duración Flotante Crítica Inicio TareaDeslizamiento Fin Ttarea
HOY
Especificación aprobada
Presupuesto aprobado
Calendario aprobado
Plan aprobado
Diseñoaprobado
Diseñoaprobado
Sep-05 Ing. de Software Planif. y Gestión … 20
Pertil de uso de Recursos• Un diagrama de Gantt tiene asociado (de forma explícita o no) una
utilización de recursos (personas, maquinaria, etc.)para cumplir las actividades
• El Perfil de Uso permite evaluar si el plan del diagrama es factible (no hay sobre-utilización) y si hay sobre-costos derivados de períodos de ocio
• El plan final resulta de revisar y ajustar Gantt y Recursos
t
RecursoOcioso
Sub-utilización Capacidad del Recurso
Sobre-utilización
Nivel de uso
Sep-05 Ing. de Software Planif. y Gestión … 21
Ajuste del plan - Técnicas
• Camino crítico (para identificar quéajustar)
• Compresión; en gral.>costo por agregarrecursos
• Paralelizar, en gral.:>riesgo (plazo, costo, calidad)>costo x retrabajo
• Nivelado y ajuste de los recursos
Sep-05 Ing. de Software Planif. y Gestión … 22
Niveles e instancias de Planificación
• ¿Cuándo se lleva a cabo la planificación?• ¿Qué nivel de detalle se puede obtener
antes de detallar los requerimientos?
• La planificación se maneja normalmente a dos niveles:
Macro, en donde se detallan fasesMicro, con detalle de actividades y componentes
Sep-05 Ing. de Software Planif. y Gestión … 23
Métricas de Tamaño
• Casa: Metros Cuadrados de Construcción• Carretera: Kilómetros/Kilómetros Cuadrados• Software: ¿?
• Líneas de CódigoVariabilidad Personal (Tamaño/Productividad)¿En qué lenguaje?¿Física? ¿Lógica? En un lenguaje, ¿qué es una línea lógica?¿Con o sin comentarios?¿Construidas o Libradas al uso?
Sep-05 Ing. de Software Planif. y Gestión … 24
Métricas de Tamaño - Líneas de Código
• Necesidad de definir criterios de mediciónEjemplo:
° Lenguaje° Criterios para contar líneas en ese lenguaje° Con/Sin Comentarios° Libradas al Uso° Discriminación de Líneas Reusadas
• Permite evaluar productividad en programación (productividad estable en LOC, independiente del lenguaje) - ¡OJO con medir productividad individual!
Sep-05 Ing. de Software Planif. y Gestión … 25
Métricas de Tamaño - Líneas de Código
• productividad en proyectos iguales, en lenguajes distintos - ¡Paradoja! ¿C más productico que C++?
• Proyecto A: 80.000 LOC C Análisis Requs. Dis.Sist.: 2 meses/personaDis.Det. Cod.PU-Int.: 4 meses/personaPrueba Sistema: 2 meses/personaEsfuerzo: 8 meses/pers. Productividad: 80.000/8= 10.000
• Proyecto A’: 42.000 LOC C++ Análisis Requs.Dis. Sist.: 2 meses/personaDis.Det. Cod.PU-Int.: 2 meses/personaPrueba Sistema: 2 meses/personaEsfuerzo: 6 meses/pers. Productividad: 42.000/6= 7.000
Sep-05 Ing. de Software Planif. y Gestión … 26
Métricas de Tamaño - Líneas de Código
• Ventajas:fácil de medir automáticamente a partir del código
• Desventajas:Para medir se precisa que el código esté construidoSujeto a variaciones personales/grupales y estilos de programaciónDepende del lenguaje:
° Dificultad para medir productos implementados en más de un lenguaje
° Difícil comparar proyectos en distinto lenguaje
Sep-05 Ing. de Software Planif. y Gestión … 27
Métricas de Tamaño - Puntos de Función
• Albrecht (IBM-1979)• Objetivo: traducir en un Número el tamaño de
la funcionalidad que brinda un producto de software
• Desde el Punto de vista del usuario• Suma ponderada de características del
producto:Nro. Entradas X 4 (3,4,6)Nro. Salidas X 5 (4,5,7)Nro. Consultas X 4 (3,4,6)Nro.Archivos X 10 (7,10,15)Nro.Interfaces externas X 7 (5,7,10)
Sep-05 Ing. de Software Planif. y Gestión … 28
Modelo para contar FP
EI
EQ
EO
Archivos Lógicos Internos (ILF)
Archivos de InterfazExternos (EIF)
Frontera de la aplicación
14 “Características Generales de la
Aplicación
Contiene datos derivados
PF = PFSA x Factor de Ajuste
Sep-05 Ing. de Software Planif. y Gestión … 29
Métricas de Tamaño - Puntos de Función• Normalizado por IFPUG
Ponderadores según complejidad de c/característica (A,M,B)Criterios definidos para asignar complejidad a c/uPuntos de Función sin ajustar+ 14 criterios de ajuste + -35%PFA=PFSA * (0,65+ 0,01*sumat( ponderadores)) Pond=1 a 5
• Ventajas:Se puede medir a partir de Requerimientos FuncionalesIndependiente del lenguaje
• Desventajas:Area de aplicación restringida (Sistemas de Información)Esfuerzo al medirVariabilidad en mediciones individuales-Medidores expertoscriticado por factores de ajuste
• Desarrollos más recientes: MK II – FFP1998 – Estándar ISO 14143-1 – Funct. Size Measurement
Sep-05 Ing. de Software Planif. y Gestión … 30
Estimación
• Para poder planificar se debe estimar:TamañoEsfuerzoCostoDuración
• Formas de Estimación:Jucio de ExpertosMétodos AlgorítmicosMétodos basados en Aprendizaje Automatizado
Sep-05 Ing. de Software Planif. y Gestión … 31
Estimación- Juicio de Expertos
• Aplicable a Tamaño, Esfuerzo, Costo, Duración• Analogía con antecedentes• Descomposición y estimación de c/componente (WBS)• pesimista, más probable, optimista
Media calculada como si fuera distribución Beta: (p+4m+o)/6σ como en Pert; ¿se pueden considerar v.a. independientes?
• Consulta a varios expertosTécnica Delphi (formal)
° c/experto estima por separado° valor medio se distribuye y se pide ajuste de estimación° variantes con discusión previa o justificaciones distribuidas° normalmente los resultados convergen rápidamente
Sep-05 Ing. de Software Planif. y Gestión … 32
Estimación -Juicio de Expertos
• Matriz de costos de Wolverton (TRW-1974)
DificultadTipo OE OM OD NE NM NDControl 21 27 30 33 40 49I/O 17 24 27 28 35 43Pre/post proces. 16 23 26 28 34 42Algoritmo 15 20 22 25 30 35Data Manag. 24 31 35 37 46 57Tiempo crítico 75 75 75 75 75 75
O=Old; N=New
E=Easy; M=Medium; D=Difficult
Sep-05 Ing. de Software Planif. y Gestión … 33
Estimación - Metodos Algoritmicos
de la forma: E=(a+b*Sc) m (X)donde a, b y c son constantesS es el tamaño estimado del productom es un multiplicador de ajuste que depende del vector X de factores de ajuste
• Walston-Felix (1977): E=5.25 S0.91
interés histórico, notar el valor del exponente menor que 1
Sep-05 Ing. de Software Planif. y Gestión … 34
Estimación - COCOMO II
E= b Sc(y) m(X)• Tamaño en SLOC (PFSA si se convierte)• y: Elementos de escala para ajustar el exponente• x: Multiplicadores de esfuerzo• 3 modelos con distinto nivel de complejidad
composición de aplicaciones (tamaño en Object Points)diseño tempranoPost-Arquitectura
• Herramientas que soportan los 2 últimos modelos• Estima Esfuerzo, Duración (y plantilla promedio) de
Desarrollo, SIN contar Requerimientos• Esfuerzo en Meses/Persona (160 horas/Persona)
Sep-05 Ing. de Software Planif. y Gestión … 35
Estimación - COCOMO II (cont.)
Ajustes de Escala:PREC -> PrecedentesFLEX -> Flexibilidad del Desarrollo
– Requerimientos pre-establecidos– Interfaces externas
RESL -> Arquitectura/Resolución de RiesgosTEAM -> Cohesión del equipoPMAT -> Madurez del Proceso de SW
Sep-05 Ing. de Software Planif. y Gestión … 36
Estimación - COCOMO II (cont.)
Multiplicadores de Esfuerzo (Post-Arquit.)RELY -> Confiabilidad requeridaDATA -> Tamaño BDCPLX -> ComplejidadRUSE -> Reuso de productos en pry y otrosDOCU -> Documentación requeridaTIME -> Carga de ProcedadoresSTOR -> Carga de MemoriaPVOL -> Volatilidad de la Plataforma
Sep-05 Ing. de Software Planif. y Gestión … 37
Estimación - COCOMO II (cont.)
Multiplicadores de Esfuerzo (Post-Arquit.)ACAP -> Capacidad de AnalistasAEXP -> Experiencia de AnalistasPCAP -> Capacidad de ProgramadoresPEXP -> Experiencia de ProgramadoresLTEX -> Experiencia en Lenguaje y Herrs.TOOL -> HerramientasSITE -> Dispersión/ComunicacionesSCED -> Compresión/Estiramiento de Plazo
Sep-05 Ing. de Software Planif. y Gestión … 38
Estimación - Aprendizaje Automático
• Aprender de proyectos pasados• predecir el costo (esfuerzo, duración)• Técnicas de Data Mining:
Construir un modelo (Redes Neuronales, Modelos Estadísticos) consistente con datoshistóricosusar el modelo para generar una predicción(estimación) del futuro
Sep-05 Ing. de Software Planif. y Gestión … 39
Recursos Humanos y Organización
• Para determinar el calendario del proyectoy estimar el esfuerzo y costo asociados, debemos saber:
cuánta gente va a estar trabajando en el proyecto,qué tareas van a desarrollar yqué habilidades y experiencia deben tener.
• Quién hace qué y cómo se va a organizarel personal.
Sep-05 Ing. de Software Planif. y Gestión … 40
Roles y Características del Personal
• Capacidad para desempeñar una tarea• interés en el trabajo• experiencia con aplicaciones similares,
herramientas, lenguajes, técnicas y ambiente de desarrollo
• entrenamiento (ajustar WBS)• capacidad para comunicarse con otros y
compartir la responsabilidad• capacidad de supervisión
Sep-05 Ing. de Software Planif. y Gestión … 41
Estilos de TrabajoINTUITIVO
INTUITIVOINTROVERTIDO:Pregunta al restoReconoce sentimientos
INTUITIVOEXTROVERTIDO:Informa al restoReconoce sentimientos
RACIONALINTROVERTIDO:Pregunta al restoDecide lógicamente
RACIONALEXTROVERTIDO:Informa al restoDecide lógicamente
EXTRO
VERTID
OIN
TRO
VER
TID
O
RACIONAL
Sep-05 Ing. de Software Planif. y Gestión … 42
ComunicacionesDos personas 1 linea de comunicación
3 lineas de comunicacióTres personas
Cuatro personas 6 lineas de comunicació
Cinco personas 10 lineas de comunicació:n personas
:n(n-1)/2 lineas de comunicación
Sep-05 Ing. de Software Planif. y Gestión … 43
Reuniones (problemas)• El propósito es poco claro.• Los participantes no están preparados.• Gente clave está ausente o llega tarde.• La conversación se aleja del propósito.• Los participantes discuten, dominan la
conversación, o no participan.• Las decisiones tomadas en la reunión luego
nunca se hacen efectivas.A una reunión de 8 personas durante 2 horas
significa un esfuerzo de 16 horas/persona
Sep-05 Ing. de Software Planif. y Gestión … 44
Reuniones (soluciones)
• Definir objetivo, agenda y duración• Los participantes deben conocerlos con
antelación suficiente• Definir quiénes deben (y no deben) participar• Asignar el rol de coordinador o moderador para
ceñirse a la agenda• Asginar el rol de secretario, responsible por el
acta, la que se debe distribuir a los participantes
Sep-05 Ing. de Software Planif. y Gestión … 45
Manejo de conflictos• ¿Qué opinar de un proyecto en el que no
aparece ningún conflicto?• Conflicto: no siempre es malo
Puede ser estimulantePromueven la creatividad
• A veces hay que “crearlos” (abogado del diablo) para evaluar riesgos
• El manejo de conflictos es clave para el éxito de un proyecto
Sep-05 Ing. de Software Planif. y Gestión … 46
Estilos de manejo de conflictosEstilo Nivel de Eficacia
Evitarlo No lo resuelve (reaparece)Suavizarlo Solución corto plazo, No lo
resuelveSolución de compromiso Solución, pero todos
pierden algoForzar la resolución Solución, pero daña las
relaciones entre las partesEnfrentarlo/buscar solución al problema
Se logra la mejor solución
Sep-05 Ing. de Software Planif. y Gestión … 47
Conflictos -Criterios generales• No responder a posibles agresiones• Oír y comunicarse efectivamente• Promover la apertura, expresión emocional y las nuevas
ideas• Expresar sentimientos como tales y no como hechos• Minimizar conflictos potenciales que entorpecen el
proyecto• Estimular conflictos cuando ello aumenta la creatividad y
la innovación• Elegir la estrategia para enfrentarlo teniendo en cuenta
la importancia, urgencia y consecuencias posibles• Conviene encontrar soluciones del tipo ganar-ganar
Sep-05 Ing. de Software Planif. y Gestión … 48
Organización del Equipo de Proyecto• Los miembros del equipo se organizan para
generar productos de calidad de maneraeficiente.
• La elección de una estructura apropiadadepende de:
la formación y estilos de trabajo de los miembros del equipola cantidad de integrantes del equipolos estilos de dirección de los clientes y desarrolladores
Sep-05 Ing. de Software Planif. y Gestión … 49
“Chief Programmer team”Chief
programmer
Assistant chief programmer
Test teamAdministrationLibrarianSeniorprogrammers
Juniorprogrammers
Sep-05 Ing. de Software Planif. y Gestión … 50
Enfoque no egoísta (egoless)
• Todos igualmente responsables• Las críticas se hacen al producto o
resultado, no a las personas• todos los miembros del equipo participan
en las decisiones (democrático)
Sep-05 Ing. de Software Planif. y Gestión … 51
Comparación de EstructurasOrganizativas
Muy EstructuradasCertidumbreRepeticiónProyectos Grandes
Poco EstructuradasIncertidumbreNuevas Técnicas o TecnologíaProyectos PequeñosCreatividad
Sep-05 Ing. de Software Planif. y Gestión … 52
Construcción del equipo
• Asignar el personal• Asignar/ajustar los roles (y responsabilidades• Definir/comunicar los objetivos• Motivar• Facilitar la comunicación entre los integrantes• Brindar retroalimentación respecto a los logros
Sep-05 Ing. de Software Planif. y Gestión … 53
Ciclo de vida de un equipo• Integración• Tormenta• Aceptación• Etapa productiva• Desintegración
Sep-05 Ing. de Software Planif. y Gestión … 54
Evaluación de FactibilidadResponder a la pregunta: ¿Vale la Pena?• Estudio de Alternativas• Factibilidad (para alguna o varias alternativas)
Técnica (¿es posible?¿qué se precisa para lograrlo?) => Recursos, PlazoEconómica (¿cuánto cuesta? ¿flujos financieros?)Operativa (¿habrá algo que haga que el sistema no funcione?). Ej.: cultura de la org.
• Análisis Costo/Beneficio
ClientesTécnicos
Sep-05 Ing. de Software Planif. y Gestión … 55
Eval. de Factibilidad (cont.)
• Frecuentemente el Estudio de Factibilidad es previo a un proyecto (ante-proyecto, pre-factibilidad)
• Puede ser la etapa inicial• A lo largo del proyecto, en puntos de
control preestablecidos, la pregunta se vuelve a formular como:
¿vale la pena seguir?
Sep-05 Ing. de Software Planif. y Gestión … 56
Gestión de Riesgos• Un riesgo es un evento no deseado que tiene
consecuencias negativas.• Gestión de Riesgos: entenderlos y controlarlosEn un proyecto de software:
genéricos: comunes a todo proyecto de softwareespecíficos: vulnerabilidades específicas de un proyecto dado.
Sep-05 Ing. de Software Planif. y Gestión … 57
Evaluar un Riesgo
Evaluar los elementos:• Impacto o pérdida asociada si ocurre• Probabilidad de que suceda• Severidad o Exposición:
(Severidad= impacto * probabilidad
Sep-05 Ing. de Software Planif. y Gestión … 58
Reducción del Riesgo
• Control de Riesgo: conjunto de accionestomadas para reducir o eliminar un riesgo
• Se justifica dependiendo de:Nivel de Reducción= (severidad antes de reducción-severidad después de reducción) / (costo de reducción)Si nivel de reducción<1 no valdrá la pena
• Registrar las decisiones en un plan de gestiónde riesgos.
Sep-05 Ing. de Software Planif. y Gestión … 59
Actividades en G.de Riesgos
Gestión de Riesgos
Evaluar Riesgos
Control de Riesgps
Identificar Riesgos
Analizar Riesgos
Priorizar Riesgos
Reducir Riesgos
Planear Solución de Riesgos
Lista de ComprobaciónDescomposiciónAnálisis de SupuestosAnálisis de Procs. de DecisiDinámica de SistemasModelos de DesempeñoModelos de CostoAnálisis de RedesAnálisis de DecisionesFactores deRiesgo en Calid
Severidad de RiesgosReducción Compuesta
Obtener InformaciónEvitar un RiesgoTransferirloEvaluar Nivel de ReduccióDesarrollar el ProcesoPlanear elemento de RiesgPlan integrado
Mitigar RiesgoMonitoreo e InformesReevaluar Riesgos
Resolver Riesgos
No se pueden atender todos
Una vez ocurrido
Impacto y/o Probabilidad Reducir
Incertidumbre
Qué hacer si ocurre
Periódicamente, o en hitos del proyecto
Según Rook, 1993
Sep-05 Ing. de Software Planif. y Gestión … 60
“Top 10 Risk Items” (Boehm)
19891. Limitaciones de Personal2. Calendario y Presupuesto3. Funciones equivocadas4. Interfaz de usuario no
adecuada5. “Gold plating” (preciosismo)6. Cambios en Requerims.
7. Suministros externos8. Tareas externas9. Desempeño de Tiempo Real10. Forzar ciencia de computación
19951. Limitaciones de Personal2. Calendario, Presupuesto,
Procesos3. COTS, componentes externos4. Requerimientos inadecuados5. Interfaz de usuario inadecuada6. Arquitectura,desempeño,calidad7. Cambios en Requerims.8. Software Heredado9. Tareas externas10. Forzar ciencia de computación.
Sep-05 Ing. de Software Planif. y Gestión … 61
Riesgos y el Plan
• Actividades de Reducción de Riesgos ->WBS• Considerarlas en plazo, esfuerzo, costo• Prever un colchón en el plazo
8% de duración para proyectos normales (no planificar con el enfoque “si todo sale bien”)más si el riesgo de pasarse de la fecha estipulada para el proyecto lo justifica
Sep-05 Ing. de Software Planif. y Gestión … 62
Gestión de la Calidad
Gestión de la Calidad
Planear la Calidad
Asegurar la Calidad
Controlar a Calidad
• Responsabilidades
• Estándares
• Procedimientos
• Puntos de Control
• Revisiones
• Auditorías
• Verificar
• Validar
WBS
Sep-05 Ing. de Software Planif. y Gestión … 63
Gestión de la Configuración
WBS
Gestión de los componentes de un producto:• Registro y control de los cambios de un
producto y de sus componentes• Coordinación fuente-ejecutableGestión de los entregables de un proyecto:• Registro y control de sus cambios• Asegurar su disponibilidad (respaldos)• Generación y Control de la Línea Base o de
Referencia
Sep-05 Ing. de Software Planif. y Gestión … 64
Comunicación entre los Involucrados
WBS
• Patrocinador, Cliente, Usuario, Desarrolladores, Otros Interesados-Involucrados
• Procedimientos de comunicaciónperiódicos, hitosformales, no formalesrevisiones conjuntas (con Cliente, Usuarios, etc.)
• Manejo de Expectativas de los interesados• Decisiones por personas autorizadas y con
conocimiento de causa
Sep-05 Ing. de Software Planif. y Gestión … 65
Plan del Proyecto
• Elaboramos un documento llamado Plan del Proyecto para:
comunicar el análisis de riesgos y la gestiónde riesgosestimaciones de costo y duracióncalendario de actividades e hitos del proyectoorganización
• al Cliente y al equipo de trabajo
Sep-05 Ing. de Software Planif. y Gestión … 66
Puntos de un buen plan de proyecto(1)
• Alcance• Descripción técnica del sistema propuesto• Estándares, procedimientos y técnicas y
herramientas propuestas• Calendario• Organización del equipo de proyecto• Plan de gestión de RRHH• Plan de entrenamiento
Sep-05 Ing. de Software Planif. y Gestión … 67
Puntos de un buen plan de proyecto(2)
• Plan de Aseguramiento de la Calidad• Plan de Gestión de la Configuración• Plan de Verificación y Validación• Plan de Gestión de Riesgos• Procedimientos para la gestión de
cambios• Plan de Comunicaciones a los interesados• Plan de Mantenimiento
Sep-05 Ing. de Software Planif. y Gestión … 68
Registro y Control de Avance
Registro del avance:Actividades cumplidas (entregables obtenidos)Actividades empezadas¿Cómo considerar actividades a medias?Riesgo del sindrome del 90%, granularidad del plan
Cuidado con los significados,ej. “programa terminado” = ¿terminada la codificación?¿revisado por un par?¿pasó la prueba unitaria?¿pronto para entrar en explotación?
Sep-05 Ing. de Software Planif. y Gestión … 69
Registro y Control de Avance(2) -Gantt
Actividad
A
B
C
D
A y B están atrasadas, C adelantada, ¿y el proyecto?
¿Está costando más o menos de lo previsto?
Sep-05 Ing. de Software Planif. y Gestión … 70
Registro y Control de Avance(3)
$Diagrama de
Evolución
de Gastos
Acumulados
Planificado
t
Real
Se lleva gastado más de lo previsto a la fecha, pero
¿cuál fue el avance logrado? ¿se va a gastar más o menos de lo previsto?
Sep-05 Ing. de Software Planif. y Gestión … 71
Enfoque del “Valor Ganado”• Modelo implícito en diagrama de Gantt nos dificulta
determinar si el proyecto está o no atrasado• Diagrama de evolución de gastos permite ver gastado
respecto a lo planificado gastar en el tiempo, pero sin relacionarlo con los logros planificados
• El enfoque del “valor ganado” corresponde a un modelo en el que se unifican todas las actividades planificadas llevándolas a $ por su costo planificado
Tenemos un plan de gastos que coincide con el plan de logros (lo que ganamos)A posteriori es posible controlar si se logró el avance previsto y si costó lo previstoSe pueden obtener: % de avance, días de atraso
Sep-05 Ing. de Software Planif. y Gestión … 72
Registro y Control de Avance(4) -Valor Ganado
$
t
Valor Ganado (Valor presupuestado del avance logrado)
Planificado
Fin Planificado(FP)
Costo Planificado Final (CPF)
t0 Fin de acuerdo a tendencia (FT)
Costo Real en t0
Costo Final de acuerdo
a tendencia(CT)
t1
Valor Ganado en t0es el previsto para t1 0
Sep-05 Ing. de Software Planif. y Gestión … 73
Registro y Control de Avance(5) -Valor Ganado
Costo Real: CR | Valor Ganado: VG | Valor Planificado: VP• Cost Performance Index
CPI = VG/CR CT=CPF/CPI• Schedule Performance Index
SPI = VG/VP FT=FP/SPI• Permiten detectar desviaciones en costo y plazo
en etapas tempranas del proyecto (15-20%)• Adecuado para proyectos grandes o limitados
por recursos (muchas actividades que podrían desarrollarse en paralelo)