Gestión de Proyectos.

Presentación del tema: "Gestión de Proyectos."— Transcripción de la presentación:

1 Gestión de Proyectos

2 Proyecto ?

3 Proyecto Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único A Guide to the Project Management Body of Knowledge 3ra edición, 2004

4 Temporal Posee fecha de inicio y término definida, es decir tiene duración finita El proyecto termina Se cumplieron los objetivos Es claro que no se puede cumplir los objetivos La necesidad ha dejado de existir La ventana de mercado ha sido sobrepasada La noción de temporal no se aplica al producto, servicio o resultado que se crea

5 Producto, Servicio o Resultado Único
Un proyecto crea entregables únicos, que son productos, servicios o resultados El proyecto crea Un producto o artefacto que es producido (completo o parte de otro producto) La capacidad de prestar un servicio Un resultado (documentos en una consultoría)

6 Proyecto vs. Trabajo Operativo
Las organizaciones trabajan para lograr objetivos. El trabajo se puede categorizar como proyecto u operaciones Los rasgos comunes Desarrollados por personas Restringido por la limitación de los recursos Planificados, ejecutados y controlados

7 Proyecto vs. Trabajo Operativo
La mayor diferencia es que los proyectos son temporales y únicos mientras que las operaciones son continuas y repetitivas Los objetivos de los proyectos y de las operaciones son diferentes El propósito de un proyecto es lograr los objetivos y terminar El propósito de las operaciones es sostener el negocio

8 Proyecto vs. Trabajo Operativo
Ejemplos de proyectos son Desarrollo de un nuevo producto o servicio Cambios en la estructura de una organización Diseñar un nuevo vehículo de transporte Desarrollar un sistema de información Construir un edificio Desarrollar una campaña política para un candidato Implementar un nuevo proceso

9 Proyectos y Planificación Estratégica
Los proyectos son formas de organizar actividades que no pueden ser tratadas dentro de los límites operacionales de la organización Los proyectos son en general utilizados para lograr la planificación estratégica de una empresa

10 Proyectos y Planificación Estratégica
Los proyectos son realizados como resultado de una o más de las siguientes consideraciones estratégicas Demanda del mercado Necesidad de la organización Solicitud de un cliente Avance tecnológico Requerimiento legal

11 Gestión de Proyectos (Project Management)
?

12 Gestión de Proyectos (Project Management)
Aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La gestión de proyectos se logra mediante la aplicación e integración de los procesos de gestión de inicio, planificación, ejecución, monitoreo y control, y cierre. A Guide to the Project Management Body of Knowledge 3ra edición, 2004

13 Responsabilidades del Jefe de Proyecto
Identificar los requerimientos Establecer objetivos claros y alcanzables Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costo Adaptar las especificaciones, los planes y el enfoque a las inquietudes y expectativas de los interesados

14 Triple Restricción Triple restricción
Alcance Tiempo Costo La calidad del proyecto depende del equilibrio entre estos factores Un proyecto de alta calidad es aquel que entrega el producto, servicio o resultado con el alcance requerido, puntualmente y dentro del presupuesto

15

16 Gestión de la Integración
Acta de constitución Alcance preliminar Plan de gestión Dirección y gestión de la ejecución Monitoreo y control del trabajo Control de cambios Cierre del proyecto

17 Gestión del Alcance Planificación del alcance Definición del alcance
Creación del WBS Verificación del alcance Control del alcance

18 Gestión del Tiempo Definición de actividades
Secuenciamiento de actividades Estimación de recursos de las actividades Estimación de duración de las actividades Desarrollo del cronograma Control del cronograma

19 Gestión del Costo Estimación del costo Preparación del presupuesto
Control del costo

20 Gestión de la Calidad Planificación de calidad
Realizar aseguramiento de calidad Realizar control de calidad

21 Gestión de los Recursos Humanos
Planificación de los recursos humanos Conseguir el equipo del proyecto Desarrollar el equipo del proyecto Administrar el equipo del proyecto

22 Gestión de las Comunicaciones
Planificación de las comunicaciones Distribución de la información Informes de rendimiento Administración de los interesados

23 Gestión de las Adquisiciones
Planificación de compras y adquisiciones Planificar la contratación Solicitar cotizaciones Selección de proveedores Administración de contratistas Cierre de contratos

24 Áreas de Expertise Gestión de proyectos
Conocimientos, normas y regulaciones del área de aplicación Comprensión del entorno del proyecto Conocimientos y habilidades de dirección general Habilidades interpersonales

25 Entorno del Proyecto Entorno cultural y social
Entorno internacional y político Entorno físico

26 Conocimientos y Habilidades de Dirección General
Gestión financiera y contabilidad Compras y adquisiciones Ventas y comercialización Contratos y derecho mercantil Manufactura y distribución Logística y cadena de suministro Planificación estratégica, planificación táctica y planificación operacional Estructuras y comportamiento de la organización, administración de personal, compensaciones, beneficios y planes de carrera

27 Habilidades Interpersonales
Comunicación efectiva Influencia en la organización Liderazgo Motivación Negociación y manejo de conflictos Resolución de problemas

28 ¿Por Qué Fallan los Proyectos?
Poca claridad del alcance 53% Bajo patrocinio a la gestión 43% Recursos inadecuados 37% Pobre definición de requerimientos 33% Pobre comunicación 23% Ausencia de una metodología estándar Pobre planeación 13 Fuente: Forrestete

29 7 Claves de Éxito en Gestión
Compromiso de los stakeholders (participantes) Comprensión de los beneficios del negocio Plan de trabajo y cronogramas predecibles Equipo de trabajo de alto desempeño Alcance es realista y manejable Riesgos son mitigados Comprensión de los beneficios de los entregables para la organización

30 Tipos de Riesgos Riesgos funcionales Riesgos de gestión
Riesgos de recursos Riesgos organizacionales Riesgos técnicos Riesgos de ejecución (compromiso, soporte, etc.)

31 Proceso de Desarrollo de Producto
Definición y Planificación Desarrollo Manufactura Distribución Post venta Marketing y ventas Técnico Producción Gestión de proyecto Calidad

32 Definición y Planificación
Define el producto de acuerdo a las necesidades del mercado Define lo que el producto debe hacer, no como se debe hacer Define el impacto comercial del producto (ingresos y costos) Define los equipos de trabajo necesarios para el desarrollo del producto

33 Definición y Planificación
Define las etapas del desarrollo Planifica el trabajo del equipo Define puntos de control (go / no go)

34 Desarrollo Especificación Diseño Implementación Integración Pruebas
Gestión de proyecto Calidad

35 Aseguramiento Calidad
Flujo de Desarrollo Especificación del sistema Co simulación Partición HW/SW Diseño e imp. HW Diseño e imp. SW Integración y pruebas Aseguramiento Calidad

36 Especificación del Sistema
Traduce la definición del sistema en requerimientos del sistema. Requerimientos del tipo Funcionales De testing De calidad De ambiente Interfaces De desarrollo De Post desarrollo

37 Especificación del Sistema
Define como el sistema será probado Define los casos de prueba que serán usados para probar el sistema Define los recursos necesarios al desarrollo y las pruebas del sistema Identifica los riesgos, supuestos, dependencias y restricciones Identifica los factores claves del éxito

38 Especificación del Sistema
Define el sistema en algún tipo de lenguaje de alto nivel Realiza verificaciones de funcionalidad a través de simulaciones Particiona el sistema en componentes de HW y SW

39 Entregables Documento de Requerimientos del Sistema
Documento de Pruebas del Sistema Documento de Especificación de la Componente hardware del Sistema Documento de Especificación de la Componente Software del Sistema

40 Partición Especificación del sistema Partición Evaluación Cumple
Requerimiento?

41 Especificación Componente Hardware
Define los requerimientos de HW del sistema Identifica riesgos. Define los supuestos, dependencias y restricciones de la componente HW Define como será probado el hardware y los casos de pruebas que se usarán Define los recursos necesarios al desarrollo de HW Realiza una revisión de pares del documento de requerimientos de HW

42 Entregables Documento de Requerimientos de HW Documento Pruebas del HW

43 Especificación Componente Software
Define los requerimientos de SW del sistema Identifica riesgos. Define los supuestos, dependencias y restricciones de la componente SW Define como será probado el software y los casos de pruebas que se usarán Define los recursos necesarios al desarrollo de SW

44 Especificación Componente Software
Especifica el ciclo de vida que se usará Especifica la arquitectura del SW Realiza una revisión de pares del documento de requerimientos de SW

45 Entregables Documento de Requerimientos de SW
Documento de Pruebas de SW Documento de Arquitectura de SW

46 Ciclos de Vida ?

47 Ciclos de Vida Waterfall (cascada) Incremental Evolutivo
Modelo espiral Modelo V Modelo V con prototipaje

48 Cascada Requirements Design Code and test Integration System test
Delivery Evolution

49 Cascada Defina lo que quiere Defina un método para lograrlo
Ejecute el método Pruebe los resultados Entregue Repita para otros requerimientos

50 Incremental Serie planificada de modelos cascada entregando más y más funcionalidad No util para productos en ROM, útil para familias de productos en ROM

51 Evolutivo Similar al incremental planificando solamente la próxima entrega Confunde desarrollo y evolución Ventajas: Puede ser usado en ambientes cambiantes Se cuenta con un sistema funcional despueés de cada entrega Se planifica solo lo que se puede predecir

52 Espiral Basado en la reducción de riesgos
Realiza varias iteraciones evaluando los riesgos En cada iteración se evalua el riesgo Si el riesgo es alto, se hace otro prototipo Sino se desarrolla el sistema final usando cascada

53 Espiral

54 Modelo V Los requerimientos sistema están completos y no son ambiguos
Simple de aplicar y gestionar Énfasis en la verificación y la validación Mala gestión de riesgos No hay ningún sistema usable hasta el final del ciclo de desarrollo.

55 Modelo V

56 Modelo V con Prototipaje

57 Eligiendo un Ciclo de Vida
Conocimiento/completitud de los requerimientos Certeza de los requerimientos detallados Volatilidad de requerimientos Tecnología / herramientas nuevas Tiempos de entrega Longevidad de la aplicación Complejidad de la aplicación Grado de reusabilidad

58 Matriz de Selección

59 Requerimientos Propósito: Tener un entendimiento común en que es el sistema y que hace Siempre se tienen requerimientos Pueden ser escritos o no Pueden estar bien o mal definidos Pueden ser estables o volátiles Proveen una base de evaluación La especificación de los requerimientos (Libro de Requerimientos) registra todos los requerimientos

60 Libro de Requerimientos
Información general y objetivos del sistema Requerimientos funcionales Requerimientos de prueba Matriz de requerimientos funcionales / prueba Requerimientos de calidad Requerimientos de interfaz Requerimientos de desarrollo Arquitectura del sistema Matriz componentes arquitecturales / requerimientos

61 Participación del Cliente
Un representante del cliente debe participar activamente Es como un arquitecto diseñando una casa Si el cliente no está involucrado, existe una alta probabilidad de fracaso En ausencia del cliente, marketing puede asumir este rol

62 Requerimientos son Objetivos del Sistema
Si los objetivos no están claros No se puede lograrlos No se puede probar que se lograron No pueden probar que no lo logramos No se pueden evaluar diferentes ideas de diseño Se termina especificando medios en vez del fin

63 Diseño Arquitectural Propósito: Crear un modelo del software del sistema La arquitectura es la decisión más crítica del diseño Incluye componentes principales y sus interacciones Es la base para el desarrollo evolutivo Son difíciles de diseñar de la nada, pero pueden ser tomadas de diseños previos o de libros

64 Estilos de Arquitectura
Layers Event-based implicit invocation Interpreters Pipes and filters Blackboard Model-view-controller Micro-kernels Software Architecture, Mary Shaw and David Garlan, Prentice-Hall, 1996.

65 Layers

66 Diseño Detallado Propósito: Hacer y registrar decisiones de diseño
algoritmos estructuras de datos variables y constantes locales y globales interfaces entre módulos y procedimientos otros Es mejor tomar las decisiones antes de codificar están documentadas no se encuentran ocultas por detalles del código Prototipos de código pueden ser hechos durante el diseño para verificar los algoritmos

67 Codificación Propósito: Transformar el diseño en código ejecutable
Si se tiene un diseño completo, la codificación es principalmente la traducción del diseño en el lenguaje de programación Solo se debe preocuparse del lenguaje y de las herramientas El problema ya se resolvió durante el diseño La codificación es también una oportunidad de encontrar errores en el diseño

68 Testing Propósito: Asegurarse que el código es consistente con los requerimientos y las necesidades del usuario Hay varias formas de probar, realícelas todas Test unitario Test de integración Test del sistema Test de aceptación / calificación

69 Test Unitario Propósito: Asegura que el código funciona de acuerdo al diseño Es realizado informalmente Para probar una función se debe Llamar la función Tener disponible las funciones que serán llamadas Si alguna no está disponible se debe hacer un mockup

70 Test Integración Propósito: Asegurar que no hay errores de interfaz. Encuentra defectos en el sistema Hay cierto nivel de formalidad ya que el código es normalmente hecho por varias personas

71 Test Sistema Propósito: Asegurar que se cumple los requerimientos
Proceso formal Planificada Casos de test especificados Registro de resultados Errores encontrados son documentados y clasificados

72 Test de aceptación / calificación
Propósito: Certificar que los requerimientos se cumplen satisfactoriamente y que la producción es posible Puede ser interna o por aprobación cliente La formalidad depende de cada caso

73 Entrega Propósito: Entregar al cliente una versión estable y aprobada del producto Los entregables deben estar definidos de antemano Se debe formalizar a través de una carta por ejemplo

74 Evolución y Gestión de Cambio
El cambio es inevitable Creamos ideas más rápido de lo que las implementamos El cambio puede venir de Cambios en el ambiente o regulaciones Competencia Nuevas necesidades de los clientes Mejor entendimiento del sistema y la tecnología No se oponga al cambio, manéjelo!