Gestion de proyectos - Sommerville
Gestión de Proyectos Ingeniería de Software Ian Sommerville Traducido para Ciberplex.tk ©Ian Sommerville 2004 Software
Views 241 Downloads 3 File size 404KB
Recommend stories
Citation preview
Gestión de Proyectos Ingeniería de Software Ian Sommerville Traducido para Ciberplex.tk
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 1
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 2
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 3
Administración de proyectos de software ●
●
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.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 4
Distinciones de proyectos de software ● ● ●
●
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.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 5
Actividades de gestión ● ● ● ● ● ●
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.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 6
Similitudes de Gestión de Proyectos ●
●
●
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ía técnicamente complejos tienede a sufrir los mismos problemas que los sistemas de software.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 7
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 8
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 9
Tipos de planes de proyectos
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 10
Project planning process Establecer las restricciones del proyecto Hacer la valoración inicial de los parámetros del proyecto Definir los hitos del proyecto y productos a entregar Mientras el proyecto no se haya completado o cancelado repetir Bosquejar la programación el tiempo del proyecto Iniciar actividades acordes con la programación Esperar ( por un momento ) Revisar el progreso del proyecto Revisar la estimaciones de los parámetros del proyecto Actualizar la programación del proyecto Renegociar las restricciones del proyecto y los productos a entregar Si ( surgen problemas) entonces Iniciar la revisión técnica y la posible revisión fin de si fin de repetir
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 11
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 12
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 13
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 14
Milestones in the RE process
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 15
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 16
El proceso de calendarización del proyecto
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 17
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 inesperadosiempre sucede. Se deben considerar planes de contingencia.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 18
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 19
Task durations and dependencies
A c tv i id T1 ©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 20
Activity network 14/7/03
15 days
M1
T3
8 days
T9
T1
25/7/03
4/7/03 start
15 days
5 days
4/8/03
T6
M4
M3
25/8/03 M6 7 days
20 days
15 days
T7
T2 25/7/03
10 days
M2
T4
T11
10 days
M7
T5
5/9/03
11/8/03
T10
18/7/03
M8
15 days
10 days T12
M5 25 days
Finish
T8 19/9/03 ©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 21
Activity timeline 4/7
11/7
18/7
25/7
1/8
8/8
15/8
22/8
29/8
5/9
12/9
19/9
Start T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Finish
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 22
Staff allocation 4/7 Fred
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
Jane
T1 T3 T9
Anne
T2 T6
Jim Mary
©Ian Sommerville 2004
T10
T7 T5
Software Engineering, 7th edition. Chapter 5
Slide 23
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 24
Gestión del riesgo
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 25
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 26
El proceso de gestión de riesgos
Risk identification
Risk analysis
Risk planning
Risk monitoring
List of potential risks
Prioritised risk list
Risk avoidance and contingency plans
Risk assessment
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 27
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 28
Riesgos y tipos de riesgos
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 29
Análisis de riesgos ●
●
●
Evaluar la probabilidad y gravedad de cada riesgo. La probabilidad del riesgo se puede valorar como muy bajo (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 30
Análisis de riesgos (i)
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 31
Análisis de riesgos (ii)
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 32
Planificación de riesgos ●
●
Considera cada riesgo y desarrolla una estrategia para gestionar ese riesgo. Estrategias de prevención •
●
Estrategias de minimización •
●
La probabilidad de que el riesgo aparezca se reduce; 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 33
Estrategias de gestión de riesgos (i)
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 34
Estrategias de gestión de riesgos (ii)
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 35
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 lasreuniones de gestión de progreso del proyecto.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 36
Factores de riesgo
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 37
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 38
Puntos clave ●
●
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.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 39
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
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 5
Slide 40