Download - Gestion de proyectos - Sommerville
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 1
Gestión de ProyectosIngeniería de Software
Ian SommervilleTraducido para Ciberplex.tk
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 2
Objetivos
Conocerá las tareas principales de los gestores de proyectos de software
Comprenderá por qué la naturaleza del software hace mas dificil la gestión de proyectos de software que la gestión de los proyectos de otras ingenierías.
Comprenderá por qué planificar proyectos es esencial en todos los proyectos de software.
Conocerá la forma en que las representaciones gráficas (gráficos de barras y redes de actividades) son utilizadas por los gestores de proyectos para representar las agendas del proyecto.
Conocerá el proceso de gestión de riesgos y algunos de los riesgos que surgen en los proyectos de software.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 3
Contenidos
Actividades de Gestión. Planificación del proyecto. Calendarización del proyecto. Gestión de riesgos.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 4
Se preocupa en las actividades implicadas en garantizar que el software se entregará a tiempo y según la calendarización prevista y de acuerdo con los requerimientos de los organismos internacionales de desarrollo y adquisición de software.
La Gestión de proyectos es necesaria porque el desarrollo de software está siempre sujeto a las limitaciones de presupuesto y el calendario que son fijados por la organización el desarrollo del software.
Administración de proyectos de software
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 5
El producto es intangible. El producto de software es único. La ingeniería de Software no es reconocida
como una disciplina de ingeniería con el mismo estatus de la mecánica, eléctrica.
El proceso de desarrollo de software no está estandarizado.
Distinciones de proyectos de software
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 6
Redacción de la propuesta. Planificación y calendarización del proyecto. Estimación de costes del proyecto. Supervisión y revisión del proyecto. Selección y evaluación del personal. Redacción y presentación de informes.
Actividades de gestión
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 7
Esta gestión de actividades no es exclusiva del software.
Muchas técnicas de proyectos de ingeniería son igualmente aplicables a la gestión de proyectos de software.
Los sistemas de ingenieríatécnicamente complejos tienede a sufrir los mismos problemas que los sistemas de software.
Similitudes de Gestión de Proyectos
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 8
Staff del Proyecto
Quizas no se podría determinar de manera idónea a la gente que trabajará en el proyecto.• El presupuesto del proyecto no podría permitir
la incorporación de personal altamente remunerado;• Podríamos no contar con personal con la
experiencia adecuada;• Una organización debería desarrollar las habilidades
de sus empleados en proyectos de software. Los administradores tienen que trabajar sin
restricciones especialmente cuando hay escasez de personal capacitado.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 9
Planificación del proyecto
Probablemente la actividad que mayor tiempo consume en la gestión de proyectos.
Actividades contínuas desde la concepción inicial hasta la entrega del sistema. Los planes deberían ser revisados periódicamente cuando se disponga de nueva información.
Distintos tipos de planes deben ser desarrollados para apoyar el plan de proyecto principal de software como calendarios y presupuestos.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 10
Tipos de planes de proyectos
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 11
Project planning process
Establecer las restricciones del proyectoHacer la valoración inicial de los parámetros del proyectoDefinir los hitos del proyecto y productos a entregarMientras el proyecto no se haya completado o cancelado repetirBosquejar la programación el tiempo del proyectoIniciar actividades acordes con la programación Esperar ( por un momento )Revisar el progreso del proyectoRevisar la estimaciones de los parámetros del proyectoActualizar la programación del proyectoRenegociar las restricciones del proyecto y los productos a entregarSi ( surgen problemas) entonces
Iniciar la revisión técnica y la posible revisiónfin de sifin de repetir
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 12
El plan de proyecto
El plan de proyecto fija:• Los recursos disponibles del proyecto;
• Divide el trabajo;
• Calendario de trabajo.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 13
Estructura del plan de proyecto
Introducción Organización del proyecto. Análisis del riesgo. Requerimientos de recursos de hardware y
software. División del trabajo. Programa del proyecto. Mecanismos de supervisión e informe.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 14
Organización de actividades
Las actividades en un proyectos deben ser organizadas para producir resultados tangibles para evaluar el progreso de la gestión.
Los hitos son los puntos finales de una actividad del proyecto..
Entregables son los resultados de los proyectos entregados a los clientes.
El proceso en cascada permite la sencilla definición de los hitos de progreso.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 15
Milestones in the RE process
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 16
Calendarización del proyecto
Split project into tasks and estimate time and resources required to complete each task.
Organize tasks concurrently to make optimal use of workforce.
Minimize task dependencies to avoid delays caused by one task waiting for another to complete.
Dependent on project managers intuition and experience.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 17
El proceso de calendarización del proyecto
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 18
Problemas de calendarización
La estimacion de la dificultad y por lo tanto el costo de desarrollo de la solución es dificil.
La productividad no es proporcional al número de gente trabajando en una tarea.
La incorporación tardía de gente al proyecto hace que se atrace mas por problemas de comunicación.
Lo inesperado siempre sucede. Se deben considerar planes de contingencia.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 19
Gráficos de Barras y Redes de actividades
Notaciones gráficas para ilustrar el calendario del proyecto.
Muestra los hitos en las tareas. Las tareas no deben ser demasiado pequeñas. Ellas deben tomar una o dos semanas.
Las redes de actividades muestran las dependencias de tareas y la ruta crítica.
Los gráficos de barras muestran la programación en el tiempo.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 20
Task durations and dependencies
A ctiv id a d D u ra c ió n (d ía s) D ep en d en c ia s
T1 8
T2 15
T3 15 T1 (M1)
T4 10
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)
T12 10 T11 (M8)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 21
Activity network
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/03
8 days
14/7/03 15 days
4/8/03
15 days
25/8/03
7 days
5/9/03
10 days
19/9/03
15 days
11/8/03
25 days
10 days
20 days
5 days25/7/03
15 days
25/7/03
18/7/03
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 22
Activity timeline4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11M8
T12
Start
Finish
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 23
Staff allocation
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 24
Gestión del riesgo
La gestión del riesgo se refiere a la identificación de riesgos y la elaboración de planes para reducir al mínimo su efecto sobre un proyecto.
El riesgo es la probabilidad de que algunas circunstancias adversas se produzcan• Riesgos del proyecto afectan a la programación y los
recursos;
• Riesgos del producto, afectan la calidad o rendimiento del software que se esta desarrollando;
• Riesgos del negocio estos afectan a la organización que desarrolla o suministra el software.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 25
Gestión del riesgo
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 26
El proceso de gestión de riesgos
● Identificación de riesgos• Identifica los riesgos del proyecto, producto y negocio;
● Análisis de riesgos• Valorar las probabilidades y consecuencias de estos
riesgos;
● Planificación de riesgos• Trazar planes para abordar los riesgos, ya sea para
evitarlos o minimizar sus efectos en el proyecto;
● Supervisión de riesgos• Valorar los riesgos de forma constante y revisar los planes
para la mitigación de riesgos tan pronto como la información de los riesgos esté disponible;
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 27
El proceso de gestión de riesgos
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 28
Identificación de riesgos
Riesgos tecnológicos. Riesgos de personal. Riesgos de herramientas. Riesgos de requerimientos. Riesgos de estimación.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 29
Riesgos y tipos de riesgos
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 30
Análisis de riesgos
Evaluar la probabilidad y gravedad de cada riesgo.
La probabilidad del riesgo se puede valorar como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%).
Los efectos del riesgo puden ser valorados como catastrófico, serio, tolerable o insignificante.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 31
Análisis de riesgos (i)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 32
Análisis de riesgos (ii)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 33
Planificación de riesgos
Considera cada riesgo y desarrolla una estrategia para gestionar ese riesgo.
Estrategias de prevención• La probabilidad de que el riesgo aparezca se
reduce; Estrategias de minimización
• Se reduce el impacto del riesgo en el proyecto o producto;
Planes de contingencia• Si se concreta el riesgo, los planes de contingencia
son necesarios para hacer frente a ese riesgo;
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 34
Estrategias de gestión de riesgos (i)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 35
Estrategias de gestión de riesgos (ii)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 36
Supervisión de riesgos
Valora cada uno de los riesgos identificados para decidir si éste es más o menos probable y si han cambiado sus efectos.
Cada factor de riesgo debe ser discutido en las reuniones de gestión de progreso del proyecto.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 37
Factores de riesgo
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 38
Puntos clave
Es esencial una buena gestión de proyectos de software para que los proyectos de ingeniería de software se desarrollen a tiempo y según presupuesto.
La gestión de proyectos de software es diferente a la gestión de otro tipo de ingenierías. El software es intangible. Los proyectos pueden ser nuevos o innovadores, por lo que no existe un conjunto de experiencias para guiar su gestión. El proceso del software no se comprende del todo.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 39
Los gestores de software tienen diversos papeles. Sus actividades más significativas son la planificación, estimación y calendarización de los proyectos. La planificación y la estimación son procesos interativos. Tienen continuidad a lo largo del proyecto. En cuanto se tenga mas información, se deben revisar los planes y calendarios.
Un hito de un proyecto es el resultado predecible de una actividad en el que se debe presentar un informe del progreso a la gestión. Los hitos ocurren de forma frecuente en un proyecto de software. Una entrega es un hito que se entrega al cliente del proyecto.
Puntos clave
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 40
Puntos clave
La calendarización de proyectos implica la creación de varias representaciones gráficas de partes del plan del proyecto. Estas incluyen redes de actividades que muestran las interrelaciones de las actividades del proyecto y gráficos de barras que muestran la duración de dichas actividades.
Se deben identificar y valorar los riesgos mayores del proyecto para establecer su probabilidad y consecuencias para éste. En cuanto a los riesgos más probables y potencialmente serios, se deben hacer planes para anularlos, gestionarlos y tratarlos. Estos riesgos se deben analizar de manera explícita en cada reunión del progreso del proyecto