Planes del Proyecto
Lic. Rosemary Torrico
Planes de proyecto: (Calendarización)
La calendarización implica separar todo el trabajo de un proyecto en
actividades complementarias y considerar el tiempo requerido para
completar dichas actividades (algunas se realizaran en paralelo).
Identificar
Actividades
Identificar
Dependencias
Estimar recursos
Para la actividad
Especificación del
software
Redes de actividades
y gráficos de barra
Asignar personas
A la actividad
Crear Gráficos de
proyectos
Duración aconsejable de una actividad: entre 1 y 8 semanas
Importante tener en cuenta posibles problemas (personal, hardware,
software,...) que provocan retrasos:
•
Problemas previstos: incrementar un 30% la estimación inicial.
•
Problemas no previstos: incrementar un 20%.
Calendarización
• Descomponer el proyecto en tareas y
estimar el tiempo y los recursos
requeridos para completarlas
• Organizar las tareas para obtener un uso
óptimo de los recursos
• Minimizar la dependencia entre tareas
para disminuir la probabilidad de atrasos
• Depende fuertemente de la intuición y
experiencia
Calendarización
• Consideraciones
– Estimar la complejidad del problema y los costos de
desarrollo de la solución
– La productividad no es proporcional al número de
personas que trabaja en una tarea
– Agregar personas a un proyecto atrasado no soluciona los
problemas
– Lo inesperado siempre ocurre. Siempre debe considerarse
las contingencias en la planificación
– La calendarización se revisa cuando se refinan
estimaciones, cuando cambian restricciones o cuando se
reasignan recursos
Hitos y productos a entregar:
• Información a los gestores de proyectos.
• Establecimiento de hitos
– Puntos finales de una actividad o tarea del proceso.
– Documentación que se presenta al administrador: informes
cortos de los logros en una actividad.
– Representan el fin de una etapa lógica en el proyecto
•
Productos a entregar
– Resultado que se entrega al cliente al final de una actividad
principal del proceso (análisis, diseño,...).
– Los productos son hitos, pero los hitos no son
necesariamente productos a entregar.
Calendarización del Proyecto
RED DE ACTIVIDADES
14/9/06
M1
8 días
4/9/06
T1
T2
T3
Duració
n (días)
Dependencia
s
T3
4/10/06
INICIO
15 días
25/10/06
M6
20 dias
T2
T9
M4
T6
25/9/06
M3
7 días
T7
T11
8
hito
15
15
25/9/06
10 días
T4
M2
10 días
T5
T1 (M1)
11/10/06
5/11/06
M8
M7
15 días
M5
T4
15 días
5 días
T1
Tarea
15 días
10
18/9/06
25 días
T10
T12
10 días
T8
T5
10
T2,T4 (M2)
T6
5
T1,T2 (M3)
T7
20
T1 (M1)
T8
25
T4 (M5)
T9
15
T3, T6 (M4)
T10
15
T5, T7 (M7)
T11
7
T9 (M6)
FINAL
•
19/11/06
Camino crítico
– trayectoria más larga en la red de actividad
– el calendario completo depende de este
camino (los retrasos en estas actividades
afectan a todo el proyecto)
– los retrasos en las demás actividades no
afectan necesariamente al proyecto
– Al conocer cifras reales, se debe revisar la
red de actividades y reorganizar las
actividades posteriores para reducir la
longitud de la trayectoria crítica.
Planeación de proyectos
Calendarización del Proyecto
4/9
11/9
18/9
25/9
1/10
8/10
15/10
22/10 29/10
5/11
12/11
19/11
inicio
T4
T1
flexibilidad en la fecha de finalización
T2
M1
T7
T3
M5
T8
M3
M2
T6
La calendarización
inicial será, con
toda seguridad,
incorrecta.
M4
T9
M7
T10
M6
T11
M8
T12
final
Durante el
desarrollo se
deben comparar
las estimaciones
contra los datos
reales.
Planes de proyecto: (Gestión de
Riesgos)
¿Qué puede salir mal?
¿Cuál es la probabilidad?
¿Cuál sería el daño?
¿Qué hacer al respecto?
1.
2.
3.
4.
5.
Riesgo
Identificación
Análisis
Planificación
Monitoreo
Gestión de Riesgos
• Propósito
– Identificar riesgos
• Desarrollar planes para minimizar su impacto sobre el
proyecto
• Riesgo
– Posibilidad de pérdida o daño
– Tipos
• Del proyecto - afectan la calendarización y los recursos
• Del producto - afectan la calidad o el desempeño del
software desarrollado
• Del negocio - afectan la organización desarrolladora del
software
Riesgo
– Caracterización
• Impacto – pérdida asociada a un evento
• Probabilidad – probabilidad de ocurrencia de un
evento
– Control o Mitigación del riesgo
• Grado en que podemos cambiar el resultado de un
evento
Exposición del riesgo = (probabilidad del riesgo) * (impacto
del riesgo)
Estrategias para minimizar un
riesgo
– Evitar el riego – cambiar los requerimientos
– Transferir el riesgo – a otro sistema
– Asumir el riesgo – aceptarlo y controlarlo
Paradigma de Administración de
Riesgos
controlar
seguir
RIESGO
planear
analizar
identificar
Identificación de riesgos
• Identificación de riesgos
– Lista de riesgos específicos que pudiesen
comprometer el éxito del proyecto
– Categorías
•
•
•
•
•
Tecnológicos
Personas
Organizacional
Requerimientos
Estimación
Identificación de riesgos
– Tecnológicos
• La BD no puede procesar la cantidad de transacciones esperada por seg.
• Los componentes reusados contienen defectos que limitan su funcionalidad
– Personas
• Personal clave para el proyecto se encuentra enfermo durante etapas
críticas
• La capacitación requerida no está disponible
– Organizacional
• Reestructuración. Cambio en los responsables del proyecto.
• Problemas financieros fuerzan una disminución del presupuesto.
– Requerimientos
• Cambios con alto impacto sobre el diseño.
• El cliente no comprende el impacto de los cambios solicitados.
– Estimación
• Subestimación de la fecha de entrega/tamaño/ esfuerzo y tiempo.
Riesgos de software
R ies g o
T ip o d e R ies g o
D es c r ip c ió n
R ota c ión d e
P e rson a l
P roye c to
P e rson a l e xp e rt o a b a n d on a rá e l p roye c t o a n te s d e q u e e ste
te rm in e
M a n e jo d e l
C a m b io
P roye c to
H a b rá u n c a m b io d e g e re n c ia d e l c lie n te c on priorid a d e s
d ife re n te s
N o d isp on ib ilid a d
d e h a rd w a re
P roye c to
H a rd w a re e se n c ia l p a ra e l p roye c to n o s e rá e n via d o a tie m p o
C a m b ios e n
re q u e rim ie n tos
P roye c to y
p rod u c to
H a b rá u n n ú m e ro c on sid e ra b le d e c a m b ios e n los re q u e rim ie n to
in ic ia le s.
R e tra s o e n
e sp e c ific a c ion e s
P roye c to y
p rod u c to
E sp e c ific a c ión d e in te rfa c e s e se n c ia le s n o e sta rá n a tie m p o
Tam año
su b e stim a d o
P roye c to y
p rod u c to
E l ta m a ñ o d e l p roye c to h a sid o su b e stim a d o
H e rra m ie n ta
C A S E b a jo
d e se m p e ñ o
C a m b io
T e c n ol óg ic o
P rod u c to
H e rra m ie n ta C A S E q u e sop orta e l p roye c to n o tie n e e l
d e se m p e ñ o a n tic ip a d o
N e g oc io
La p la ta form a te c n ol óg ic a sob re la q u e e l siste m a e stá c on stru id
h a q u e d a d o ob sole ta
C om p e te n c ia d e
P rod u c to
N e g oc io
U n n u e vo p rod u c to e s c om e rc ia liza d o a n te s d e q u e te rm in e e l
p roye c t o
Planificación de Riesgos
• Considerar cada riesgo y desarrollar una
estrategia para manejarlo
• Estrategias de Evitabilidad
– Reducen la probabilidad de que el riesgo ocurra
• Estrategias de Minimización
– Reducen el impacto del riesgo en el proyecto o
producto
• Planes de Contingencia
– Si ocurre el riesgo, el plan de contingencia es un plan
para enfrentar ese riesgo
Estrategias de administración de
riesgo
Riesgo
Estrategia
Problemas financieros
organizacionales
Preparar un breve documento para la alta gerencia mostrando cómo el
proyecto está haciendo una contribución muy importante a las metas del
negocio.
Alertar a clientes sobre dificultades potenciales y la posibilidad de atrasos,
investigar compra de componentes.
Problemas de
contratación
Enfermedades
Reorganizar al equipo de modo que haya más superposición de trabajo y
así lograr que la gente entienda el trabajo de los otros.
Componentes
defectuosos
Reemplazar componentes potencialmente defectuosos con otros de
reconocida estabilidad.
Cambios en
requerimientos
Desempeño de la Base
de Datos
Derivar información de seguimiento para evaluar el impacto en el cambio
de requerimientos, maximizar la información de aspectos ocultos en el
diseño.
Preparar un documento ejecutivo para la alta gerencia mostrando cómo el
proyecto está haciendo una contribución muy importante a las metas del
negocio.
Investigar la posibilidad de adquirir una Base de Datos de mejor
desempeño.
Tiempo de desarrollo
subestimado
Investigar la compra de componentes, investigar el uso de generadores de
programas.
Reestructuración
organizacional
Descargar

Planes del Proyecto