Planificación y Gestión del Proyecto

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

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?

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)

Alcance y Expectativas

Recurso

s Tiempo

Alcance

Calidad

Balancear

Necesidades

Expectativas

Necesidades

ExpectativasTecn

ología

Personas

Proceso

Restricciones

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

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

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

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

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

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

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

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

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

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)

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

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

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?

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

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

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

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

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?

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!

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

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

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)

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

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

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

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

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

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

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)

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

“Chief Programmer team”Chief

programmer

Assistant chief programmer

Test teamAdministrationLibrarianSeniorprogrammers

Juniorprogrammers

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)

Comparación de EstructurasOrganizativas

Muy EstructuradasCertidumbreRepeticiónProyectos Grandes

Poco EstructuradasIncertidumbreNuevas Técnicas o TecnologíaProyectos PequeñosCreatividad

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

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

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

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?

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.

Evaluar un Riesgo

Evaluar los elementos:• Impacto o pérdida asociada si ocurre• Probabilidad de que suceda• Severidad o Exposición:

(Severidad= impacto * probabilidad

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.

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

“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

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

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

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

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

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

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

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

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?

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?

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?

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

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

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)