Planificacion y gestion de proyectos, Ingeniería de Software

1. Planificación y Gestión del
Proyecto

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

3. Proyecto
• Operaciones y Proyectos:
llevados a cabo por personas
sometidos a restricciones (recursos)
se planifican, ejecutan, controlan
• Operación Continua<> Proyecto
• Proyecto
inicio y fin (el proyecto)
producto/servicio único (el resultado
continua) ¿Alcance?

4. Conceptos fundamentales
Gestió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 negativamente
Alcance:
• del producto (final) – sus características
• del proyecto – trabajos incluidos (y no)

5. Alcance y Expectativas
os
Ti
s
em
Necesidades ur
ec
po
Expectativas R Calidad
Balancear
Alcance
Restricciones
Necesidades
ía
Pe
g
lo
rs
Expectativas no
on
ec
as
T
Proceso

6. Relación con otras disciplinas de la
Administración
Administració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 Gestión de
Proyectos
• Ramas de la Industria
Adminis- Área de
tración Gral. Aplicación

7. Relación con otros
Emprendimientos
Programa
• conjunto de proyectos relacionados
• a menudo incluyen elementos de Operación
Continua
Subproyecto
• parte de un proyecto
• a menudo contratada a un proveedor

8. Técnicas y Herramientas de
Planificación
Técnica Herramienta
WBS 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

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

10. WBS - Ejemplo: Casa
Casa
Diseño Terreno Materiales Construcción
Planos Delimitar Adquirir Cimientos
Memoria Acondicionar Muros
Descript.
Techos
Notas: 1. No se representan relaciones de
Sanitaria
precedencia. 2. Es usual presentarlo (en lo posible)
en el orden de ejecución Electricidad
Terminaciones

11. WBS - Contra-Ejemplo: Casa
Casa
Dormitorios Living Comedor Cocina Baño
Principal
Niños
Huéspedes
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?

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 actividad
precedentes
duración
producto

13. Grafo de Actividades (CPM)
• Se consideran: Critical Path Method
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)

14. Grafo de Actividades
i.Electricidad
b.Memoria
Descript. j.Sanitaria
a.Planos h.Techos
inicio fin
d.Adquirir
g.Muros
(Materiales)
c.Delimitar
k.Terminaciones
(Terreno)
e.Cimien
tos
f.Acondicionar
(Terreno)

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)

16. Grafo de Actividades
con duraciones
i (1)
b (4)
j (2)
0
a (3)
inicio fin
h (7)
c (5)
d (5)
g (5)
Colores: k (10)
•Temprano f (8)
e (7)
•Tardío

17. Grafo de Actividades
con duraciones 35 36
i (1)
3 7 44 45
b (4) 35 37
7 11 j (2)
0 0 3 43 45 45
a (3) 28 35
inicio 7 12 fin
0 3 h (7)
c (5) 28 35
3 8 11 16
d (5) 23 28
3 8 g (5) 35 45
23 28 k (10)
Colores: 8 16 16 23
•Temprano f (8) 35 45
e (7)
8 16
•Tardío 16 23 ¿Cuál es el Camino Crítico?

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=Σ σ2activ.camino crítico
• ¿Duraciones v.a. independientes? ¿Y los otros
caminos?

19. Diagrama de Gantt
HOY
ACTIVIDAD ENE FEB MAR ABR MAY JUN JUL AGO SEP OCT NOV DIC
WBS 1.0 PLANEAR SISTEMA
Especificación aprobada
1.1 Revisar especificación
1.2 Revisar presupuesto Presupuesto aprobado
1.3 Revisar calendario Calendario aprobado
1.4 Desarrollar plan Plan aprobado
WBS 2.0 DISEÑAR SISTEMA
2.1 Diseño de alto nivel Diseño
aprobado
2.2 Prototipar
2.3 Interfaz de usuario
2.4 Diseño detallado Diseño
aprobado
Completada Duración Flotante Crítica Deslizamiento Inicio Tarea Fin Ttarea

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
Sobre-
utilización Capacidad
Sub-utilización
Recurso del Recurso
Nivel Ocioso
de
uso
t

21. Ajuste del plan - Técnicas
• Camino crítico (para identificar qué
ajustar)
• Compresión; en gral.>costo por agregar
recursos
• Paralelizar, en gral.:
>riesgo (plazo, costo, calidad)
>costo x retrabajo
• Nivelado y ajuste de los recursos

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 fases
Micro, con detalle de actividades y
componentes

23. Métricas de Tamaño
• Casa: Metros Cuadrados de Construcción
• Carretera: Kilómetros/Kilómetros Cuadrados
• Software: ¿?
• Líneas de Código
Variabilidad 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?

24. Métricas de Tamaño - Líneas de Código
• Necesidad de definir criterios de medición
Ejemplo:
° 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!

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/persona
Dis.Det. Cod.PU-Int.: 4 meses/persona
Prueba Sistema: 2 meses/persona
Esfuerzo: 8 meses/pers. Productividad: 80.000/8= 10.000
• Proyecto A’: 42.000 LOC C++
Análisis Requs.Dis. Sist.: 2 meses/persona
Dis.Det. Cod.PU-Int.: 2 meses/persona
Prueba Sistema: 2 meses/persona
Esfuerzo: 6 meses/pers. Productividad: 42.000/6= 7.000

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é construido
Sujeto a variaciones personales/grupales y estilos de
programación
Depende del lenguaje:
° Dificultad para medir productos implementados en más de
un lenguaje
° Difícil comparar proyectos en distinto lenguaje

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)

28. Modelo para contar FP Frontera de
la aplicación
EI Archivos Lógicos 14
Internos (ILF) “Características
Generales de la
EQ Aplicación
Archivos de Interfaz
EO Externos (EIF)
Contiene datos
derivados
PF = PFSA x Factor de Ajuste

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/u
Puntos 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 Funcionales
Independiente del lenguaje
• Desventajas:
Area de aplicación restringida (Sistemas de Información)
Esfuerzo al medir
Variabilidad en mediciones individuales-Medidores expertos
criticado por factores de ajuste
• Desarrollos más recientes: MK II – FFP
1998 – Estándar ISO 14143-1 – Funct. Size Measurement

30. Estimación
• Para poder planificar se debe estimar:
Tamaño
Esfuerzo
Costo
Duración
• Formas de Estimación:
Jucio de Expertos
Métodos Algorítmicos
Métodos basados en Aprendizaje Automatizado

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 expertos
Té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

32. Estimación -Juicio de Expertos
• Matriz de costos de Wolverton (TRW-1974)
O=Old; N=New
E=Easy; M=Medium; D=Difficult
Dificultad
Tipo OE OM OD NE NM ND
Control 21 27 30 33 40 49
I/O 17 24 27 28 35 43
Pre/post proces. 16 23 26 28 34 42
Algoritmo 15 20 22 25 30 35
Data Manag. 24 31 35 37 46 57
Tiempo crítico 75 75 75 75 75 75

33. Estimación - Metodos Algoritmicos
de la forma: E=(a+b*Sc) m (X)
donde a, b y c son constantes
S es el tamaño estimado del producto
m 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

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 temprano
Post-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)

35. Estimación - COCOMO II (cont.)
Ajustes de Escala:
PREC -> Precedentes
FLEX -> Flexibilidad del Desarrollo
– Requerimientos pre-establecidos
– Interfaces externas
RESL -> Arquitectura/Resolución de Riesgos
TEAM -> Cohesión del equipo
PMAT -> Madurez del Proceso de SW

36. Estimación - COCOMO II (cont.)
Multiplicadores de Esfuerzo (Post-Arquit.)
RELY -> Confiabilidad requerida
DATA -> Tamaño BD
CPLX -> Complejidad
RUSE -> Reuso de productos en pry y otros
DOCU -> Documentación requerida
TIME -> Carga de Procedadores
STOR -> Carga de Memoria
PVOL -> Volatilidad de la Plataforma

37. Estimación - COCOMO II (cont.)
Multiplicadores de Esfuerzo (Post-Arquit.)
ACAP -> Capacidad de Analistas
AEXP -> Experiencia de Analistas
PCAP -> Capacidad de Programadores
PEXP -> Experiencia de Programadores
LTEX -> Experiencia en Lenguaje y Herrs.
TOOL -> Herramientas
SITE -> Dispersión/Comunicaciones
SCED -> Compresión/Estiramiento de Plazo

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 datos
históricos
usar el modelo para generar una predicción
(estimación) del futuro

39. Recursos Humanos y Organización
• Para determinar el calendario del proyecto
y estimar el esfuerzo y costo asociados,
debemos saber:
cuánta gente va a estar trabajando en el
proyecto,
qué tareas van a desarrollar y
qué habilidades y experiencia deben tener.
• Quién hace qué y cómo se va a organizar
el personal.

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

41. Estilos de Trabajo
INTUITIVO
INTUITIVO INTUITIVO
INTROVERTIDO: EXTROVERTIDO:
EXTROVERTIDO
INTROVERTIDO
Pregunta al resto Informa al resto
Reconoce sentimientos Reconoce sentimientos
RACIONAL RACIONAL
INTROVERTIDO: EXTROVERTIDO:
Pregunta al resto Informa al resto
Decide lógicamente Decide lógicamente
RACIONAL

42. Comunicaciones
Dos personas 1 linea de comunicación
Tres personas 3 lineas de comunicació
Cuatro personas 6 lineas de comunicació
Cinco personas 10 lineas de comunicació
:
:
n(n-1)/2 lineas de
n personas
comunicació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

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

45. Manejo de conflictos
• ¿Qué opinar de un proyecto en el que no
aparece ningún conflicto?
• Conflicto: no siempre es malo
Puede ser estimulante
Promueven 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

46. Estilos de manejo de conflictos
Estilo Nivel de Eficacia
Evitarlo No lo resuelve (reaparece)
Suavizarlo Solución corto plazo, No lo
resuelve
Solución de compromiso Solución, pero todos
pierden algo
Forzar la resolución Solución, pero daña las
relaciones entre las partes
Enfrentarlo/buscar Se logra la mejor solución
solución al problema

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

48. Organización del Equipo de
Proyecto
• Los miembros del equipo se organizan para
generar productos de calidad de manera
eficiente.
• La elección de una estructura apropiada
depende de:
la formación y estilos de trabajo de los miembros del
equipo
la cantidad de integrantes del equipo
los estilos de dirección de los clientes y
desarrolladores

49. “Chief Programmer team”
Chief
programmer
Assistant chief
programmer
Senior Librarian Administration Test team
programmers
Junior
programmers

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)

51. Comparación de Estructuras
Organizativas
Muy Estructuradas
Certidumbre
Repetición
Proyectos Grandes
Poco Estructuradas
Incertidumbre
Nuevas Técnicas o Tecnología
Proyectos Pequeños
Creatividad

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

53. Ciclo de vida de un equipo
• Integración
• Tormenta
• Aceptación
• Etapa productiva
• Desintegración

54. Evaluación de Factibilidad
Responder 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, Plazo
Econó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
Clientes
Técnicos

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?

56. Gestión de Riesgos
• Un riesgo es un evento no deseado que tiene
consecuencias negativas.
• Gestión de Riesgos: entenderlos y controlarlos
En un proyecto de software:
genéricos: comunes a todo proyecto de software
específicos: vulnerabilidades específicas de un
proyecto dado.

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

58. Reducción del Riesgo
• Control de Riesgo: conjunto de acciones
tomadas 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ón
de riesgos.

59. Actividades en G.de Riesgos
Según Rook, 1993 Lista de Comprobación
Descomposición
Identificar Riesgos Análisis de Supuestos
Análisis de Procs. de Decisi
Evaluar Riesgos Analizar Riesgos Dinámica de Sistemas
Modelos de Desempeño
Priorizar Riesgos Modelos de Costo
Análisis de Redes
No se pueden Análisis de Decisiones
atender todos Factores deRiesgo en Calid
Gestión de Riesgos
Severidad de Riesgos
Impacto y/o Reducción Compuesta
Reducir Obtener Información
Probabilidad
IncertidumbreEvitar un Riesgo
Reducir Riesgos Transferirlo
Evaluar Nivel de Reducció
Control de Riesgps
Planear Solución de Riesgos Desarrollar el Proceso
Planear elemento de Ries
Qué hacer si ocurre
Plan integrado
Periódicamente, o en Resolver Riesgos Mitigar Riesgo Una vez
hitos del proyecto Monitoreo e Informes ocurrido
Reevaluar Riesgos

60. “Top 10 Risk Items” (Boehm)
1989 1995
1. Limitaciones de Personal 1. Limitaciones de Personal
2. Calendario y Presupuesto 2. Calendario, Presupuesto,
3. Funciones equivocadas Procesos
4. Interfaz de usuario no 3. COTS, componentes externos
adecuada 4. Requerimientos inadecuados
5. “Gold plating” (preciosismo)
5. Interfaz de usuario inadecuada
6. Cambios en Requerims.
6. Arquitectura,desempeño,
7. Suministros externos calidad
8. Tareas externas 7. Cambios en Requerims.
9. Desempeño de Tiempo Real 8. Software Heredado
10. Forzar ciencia de computación 9. Tareas externas
10. Forzar ciencia de computació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

62. Gestión de la Calidad
Gestión de la
Calidad
Planear la Asegurar la Controlar a
Calidad Calidad Calidad
• Responsabilidades • Revisiones • Verificar
• Estándares • Auditorías • Validar
• Procedimientos
• Puntos de Control WBS

63. Gestión de la Configuración
Gestión de los componentes de un producto:
• Registro y control de los cambios de un
producto y de sus componentes
• Coordinación fuente-ejecutable
Gestió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 WBS

64. Comunicación entre los
Involucrados
• Patrocinador, Cliente, Usuario, Desarrolladores,
Otros Interesados-Involucrados
• Procedimientos de comunicación
periódicos, hitos
formales, no formales
revisiones conjuntas (con Cliente, Usuarios, etc.)
• Manejo de Expectativas de los interesados
• Decisiones por personas autorizadas y con
conocimiento de causa
WBS

65. Plan del Proyecto
• Elaboramos un documento llamado Plan
del Proyecto para:
comunicar el análisis de riesgos y la gestión
de riesgos
estimaciones de costo y duración
calendario de actividades e hitos del proyecto
organización
• al Cliente y al equipo de trabajo

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

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

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?

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?

70. Registro y Control de Avance(3)
$
Diagrama de
Planificado
Evolución
Real
de Gastos
Acumulados
t
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?

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 previsto
Se pueden obtener: % de avance, días de atraso

72. Registro y Control de Avance(4) -
Costo Final de
Valor Ganado
acuerdo
$ a tendencia(CT)
Planificado Costo Planificado
Final (CPF)
Valor Ganado (Valor
presupuestado del
avance logrado)
Costo Real en t0
Valor Ganado en t0
es el previsto para t1
0 t1 t0 t
Fin Planificado Fin de acuerdo
(FP) a tendencia (FT)

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)