Planificación y Gestión del Proyecto - angelfire.com · de una actividad sin afectar la fecha de...

73
Sep-05 Ing. de Software 1 Planificación y Gestión del Proyecto INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE CÓMPUTO M. En C. Eduardo Bustos Farías

Transcript of Planificación y Gestión del Proyecto - angelfire.com · de una actividad sin afectar la fecha de...

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)