36
INSTITUTO TECNOLÓGICO DE PARRAL MARTÍNEZ CANO JORGE. BARRAZA LUNA VÍCTOR. MARTÍNEZ CARRILLO CESAR. VALDEZ SEAÑEZ EDWIN. QUIÑONES GARNICA OSCAR. GESTION DE PROYECTOS 1

Gestión de Proyectos

Embed Size (px)

DESCRIPTION

Esta presentacion de la clase de Fundamentos de desarrollo de sistemas, nos habla sobre como gestionar un proyecto de software en su primer etapa y la relacion que existe entre Tiempo/personal.

Citation preview

Page 1: Gestión de Proyectos

1

INSTITUTO TECNOLÓGICO DE PARRAL

MARTÍNEZ CANO JORGE.BARRAZA LUNA VÍCTOR.MARTÍNEZ CARRILLO CESAR.VALDEZ SEAÑEZ EDWIN.QUIÑONES GARNICA OSCAR.

GESTION DE PROYECTOS

Page 2: Gestión de Proyectos

2

GESTIÓN DE PROYECTOS

Page 3: Gestión de Proyectos

3

AGENDA

• OBJETIVOS………………………………………………4

• GESTIÓN DE PROYECTOS…………………….…..6– Diferencias de los gestores de software a otros gestores……………………………………………... 8

• ACTIVIDADES DE GESTIÓN………………………. 9• PLANIFICACIÓN DE PROYECTOS…………….. 10– El plan del proyecto……………………………………. 14

• Hitos y entregas…………………………………………………. 16

• CALENDARIZACIÓN DEL PROYECTO………… 20– Gráficos de barras y redes de actividades……. 25

Page 4: Gestión de Proyectos

4

OBJETIVOS

• Conocer las tareas principales de los gestores de software.

• Comprender por que la naturaleza del software que la gestión de los proyectos de otras ingenierías.

• Comprender por que planificar proyectos es esencial en todos los proyectos de software.

Page 5: Gestión de Proyectos

5

• Conocer la forma en que las representaciones graficas (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 os riesgos que surgen en los proyectos de software.

Page 6: Gestión de Proyectos

6

Gestión de proyectos.

• Es una parte esencial de la ingeniería de software. La buena gestión no puede garantizar el éxito del proyecto. Sin embargo, la mala gestión usualmente te lleva al fracaso del proyecto. El software es entregado tarde, los costos son mayores que los estimados y los requerimientos no se cumplen.

• Los gestores de software son responsables de la planificación y temporalizacion del desarrollo de los proyectos.

Page 7: Gestión de Proyectos

7

• La administración de proyectos de software es necesaria debido a que la ingeniería de software profesional esta sujeto a restricciones organizacionales de tiempo y presupuesto.

• El trabajo del gestor de proyectos de software es asegurar que estos cumplan dichas restricciones y entregar software que contribuya a las metas de la compañía de desarrollo de software.

Page 8: Gestión de Proyectos

8

Diferencias de los gestores de software a otros gestores.

• El producto es intangible.

• No existen procesos del software estándar.

• A menudo los proyectos grandes son únicos.

Page 9: Gestión de Proyectos

9

Actividades de Gestión

•Redacción de la propuesta.

•Planificación y calendarización del proyecto.

•Estimación de coste del proyecto.

•Supervisión y revisión del proyecto.

•Selección y evaluación del personal.

•Redacción y presentación de informe.

Page 10: Gestión de Proyectos

10

Planificación del proyecto

Page 11: Gestión de Proyectos

11

• La gestión efectiva de un proyecto de software depende de planificar el progreso del proyecto.

• El gestor del proyecto debe anticiparse a los problemas que puedan surgir, así como preparar soluciones a esos problemas.

• Un plan, preparado al inicio de un proyecto, debe utilizarse como un conductor para el proyecto. Este plan inicialdebe ser el mejor posible de acuerdo con la informacion disponible.

• Este plan evolucionara conforme el proyecto progrese y la información sea mejor.

Page 12: Gestión de Proyectos

12

Plan de desarrollo de software

Page 13: Gestión de Proyectos

13

Además de un plan de proyecto, los gestores tienen que preparar otros tipos de planes

Page 14: Gestión de Proyectos

14

El plan del proyecto

• El plan del proyecto fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo. En algunas organizaciones , el plan del proyecto es un único documento que incluye todos los diferentes tipos de planes.

• En otros casos, este plan solo se refiere al proceso del desarrollo

Page 15: Gestión de Proyectos

15

Los detalles de este plan varían dependiendo del proyecto y de la organización. Sin embargo muchos

planes incluyen las siguientes secciones:

1. Introducción.2. Organización del proyecto.3. Análisis de riesgo.4. Requerimientos de recursos de HW. y SW.5. División del trabajo.6. Programa del proyecto.7. Mecanismos de supervisión e informe.

Page 16: Gestión de Proyectos

16

Hitos y entregas.Los gestores del proyecto necesitan información para hacer su trabajo. Como el software es intangible, esta información se provee como documentos que describen el estado del software que esta en desarrollo.

Cuando se planifica un proyecto, se debe establecer una serie de hitos.

Page 17: Gestión de Proyectos

17

Hitos.

• Hitos.- Puntos finales de una actividad del proceso del software.

– Debe existir una salida formal.– No deben de ser documentos amplios.– Deben representar el fin de una etapa lógica en el

proyecto.

Page 18: Gestión de Proyectos

18

Entregas.

• Entrega.- Es el resultado del proyecto que se entrega al cliente.

– Se entrega al final de una fase principal del proyecto como la especificación, el diseño, etc.

– Las entregas son hitos.

Page 19: Gestión de Proyectos

19

Hitos del proceso de especificación de requerimientos.

Page 20: Gestión de Proyectos

20

Calendarización del proyecto.

Page 21: Gestión de Proyectos

21

• Esta es una de las tareas mas difíciles para los gestores de proyectos. Los gestores estiman el tiempo y los recursos requeridos para completar las actividades y organizarlas en una sucesión coherente.

• La calendarización del proyecto implica separar todo el trabajo de un proyecto en actividades complementarias y considerar el tiempo requerido para completar dichas actividades.

Page 22: Gestión de Proyectos

22

El proceso de calendarización del proyecto.

Page 23: Gestión de Proyectos

23

• Debemos coordinar estas actividades paralelas y organizar el trabajo para que la mano de obra se utilice de forma optima.

• Deben evitarse situaciones en que el proyecto entero se retrase debido a que no se ha terminado una actividad critica.

• Los gestores no deben suponer que cada etapa del proyecto estará libre de problemas.

Page 24: Gestión de Proyectos

24

• Los gestores deben estimar los recursos necesarios para completar cada tarea.

• Para los problemas previstos siempre debe agregarse un 30% a la estimación original y otro 20% para cubrir algunas cosas no previstas.

• El calendario del proyecto se puede representar como un conjunto de gráficos que muestran la división del trabajo, las dependencias de las actividades y la asignación del personal.

Page 25: Gestión de Proyectos

25

GRÁFICOS DE BARRAS Y REDES DE ACTIVIDADES

Page 26: Gestión de Proyectos

26

• Los gráficos de barras y las redes de actividades son notaciones graficas que se utilizan para ilustrar la calendarización del proyecto.

• Las redes de actividades muestran la dependencia entre las diferentes actividades que conforman un proyecto.

Page 27: Gestión de Proyectos

27

Duración y dependencia de las tareas

Tarea Duración Tarea anterior

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)

Page 28: Gestión de Proyectos

28

Red de actividades

Page 29: Gestión de Proyectos

29

• El tiempo mínimo requerido para finalizar el proyecto se estima teniendo en cuenta la trayectoria más larga en la red de actividades (el camino crítico).

• Cualquier aplazamiento al contemplar una actividad crítica provoca retraso en el proyecto, ya que las actividades siguientes no pueden comenzarse.

Page 30: Gestión de Proyectos

30

• Los retrasos que no están ligados al camino crítico no provocan un aplazamiento en todo el calendario, por lo tanto el proyecto no se verá afectado.

• Los gestores también utilizan las redes de actividades para asignar los trabajos en el proyecto.

Page 31: Gestión de Proyectos

31

• Es posible modificar el diseño del sistema de tal forma que se acorte el camino crítico.

• Inevitablemente, las agendas del proyecto iniciales serán incorrectas.

Page 32: Gestión de Proyectos

32

• A medida que el proyecto se desarrolla, las estimaciones deben ser comparadas con los tiempos reales.

• Cuando se muestran los tiempos reales, debemos revisar el gráfico de actividades.

Page 33: Gestión de Proyectos

33

Gráfico de barras de actividades.

Page 34: Gestión de Proyectos

34

• También llamado gráfico de Gantt que muestra el calendario de un proyecto y las fechas iniciales y finales de actividades.

• Las actividades seguidas por una barra sombreada significan que existe flexibilidad en las fechas de terminación.

• Las actividades que no son seguidas de dichas barras, NO tienen margen de error.

Page 35: Gestión de Proyectos

35

• Además de la calendarización, los gestores de proyectos deben tener en cuenta la asignación de recursos y personal a las actividades del proyecto.

• Las personas no tienen porqué estar asignadas al proyecto en todo momento.

Page 36: Gestión de Proyectos

36

CONCLUSIÓN.

La gestión de proyectos es una planeación de cómo, cuándo, qué recursos y qué personal es necesario para elaborar un proyecto y lograr un objetivo.

Los gestores de proyectos son los encargados de la planeación y se ayudan con gráficos de Gantt y redes de actividades para organizar el tiempo de cada actividad del proyecto.