La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Ingenieria del Software UMG Capítulo 3. Gestión de Proyectos de Software.

Presentaciones similares


Presentación del tema: "Ingenieria del Software UMG Capítulo 3. Gestión de Proyectos de Software."— Transcripción de la presentación:

1 Ingenieria del Software UMG Capítulo 3. Gestión de Proyectos de Software

2 Caminar sobre las aguas y desarrollar programas a partir de las especificaciones es fácil, si ambas están congeladas Edward V. Berard

3 El proceso del software. Estructura El proceso del software. Estructura Estándares en ingeniería del software Estándares en ingeniería del software Utilidad de los estándares Utilidad de los estándares Tipos de estándares Tipos de estándares Estándares relacionados con el proceso software Estándares relacionados con el proceso software De evaluación del proceso software: SEI(software Engineering Institute) CMM (Modelo de capacidad de Madurez) De evaluación del proceso software: SEI(software Engineering Institute) CMM (Modelo de capacidad de Madurez) De procesos estándar del ciclo de vida De procesos estándar del ciclo de vida ISO 9000 ISO 9000

4 Proceso software Distintos procesos de software organizan las actividades de diferentes formas, y las describen con diferente nivel de detalle Distintos procesos de software organizan las actividades de diferentes formas, y las describen con diferente nivel de detalle El tiempo de cada actividad varía, así como los resultados El tiempo de cada actividad varía, así como los resultados Organizaciones diferentes usan procesos diferentes para producir el mismo producto Organizaciones diferentes usan procesos diferentes para producir el mismo producto Sin embargo, para algunos tipos de aplicación, algunos procesos son más convenientes que otros Sin embargo, para algunos tipos de aplicación, algunos procesos son más convenientes que otros

5 Ciclo de vida Alternativamente, a veces se usan los términos Alternativamente, a veces se usan los términos Ciclo de vida, y Ciclo de vida, y Modelo de ciclo de vida Modelo de ciclo de vida Sucesión de etapas por las que atraviesa un producto software a lo largo de su existencia (durante su desarrollo y explotación) Sucesión de etapas por las que atraviesa un producto software a lo largo de su existencia (durante su desarrollo y explotación)

6 Ciclo de vida (II) Ciclo de vida Ciclo de desarrollo Desde el análisis hasta la entrega al usuario Toda la vida del sistema: desde la concepción hasta el fin de uso

7 Estándares en ingeniería del software Estándar: conjunto de criterios aprobados, documentados y disponibles para determinar la adecuación de una acción (estándar de proceso) o de un objeto (estándar de producto) Estándar: conjunto de criterios aprobados, documentados y disponibles para determinar la adecuación de una acción (estándar de proceso) o de un objeto (estándar de producto) Guía: conjunto de criterios bien definidos y documentados que encaminan una actividad o tarea Guía: conjunto de criterios bien definidos y documentados que encaminan una actividad o tarea es más flexible que un estándar es más flexible que un estándar

8 ¿Porqué usar estándares en ingeniería del software? Los estándares son útiles porque: Los estándares son útiles porque: agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de software agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de software engloban los conocimientos que son patrimonio de una organización engloban los conocimientos que son patrimonio de una organización proporcionan un marco para implementar procedimientos de aseguramiento de la calidad proporcionan un marco para implementar procedimientos de aseguramiento de la calidad proporcionan continuidad entre el trabajo de distintas personas proporcionan continuidad entre el trabajo de distintas personas

9 Tipos de estándares en ingeniería del software Estándares para datos: Estándares para datos: desde asignar nombres a los datos y especificar longitud y tipo hasta los relacionados con BBDD p.ej., Ansi SQL Estándares de codificación: Estándares de codificación: abreviaturas y designaciones formales para describir actividades dentro de la organización p.ej., Notacion Hungara. Estándares estructurales: Estándares estructurales: políticas de división del software en módulos Estándares de documentación Estándares de documentación Estándares de proceso software Estándares de proceso software Estándares para otras actividades Estándares para otras actividades

10 Métodos de evaluación SEIs CMM (Capability Maturity Model) Tiempo Nivel Inicial Repetible Gestionado Definido Optimizado El primer paso para consolidar y mejorar un proceso es valorarlo Requerido por el DoD Amplio uso en EEUU ( Pressman 2002) pp.16-18

11 CMM - Madurez del proceso 1. Inicial: el éxito depende de esfuerzos heroicos y personales más que de procesos adecuadamente definidos. No hay proceso definido implícita o explícitamente. 1. Inicial: el éxito depende de esfuerzos heroicos y personales más que de procesos adecuadamente definidos. No hay proceso definido implícita o explícitamente. 2. Repetible: se establecen políticas y procedimientos para llevar a cabo un proyecto. Una función de calidad asegura que se cumplen dichos procedimientos. Se obtienen niveles de calidad parecidos a proyectos anteriores. 2. Repetible: se establecen políticas y procedimientos para llevar a cabo un proyecto. Una función de calidad asegura que se cumplen dichos procedimientos. Se obtienen niveles de calidad parecidos a proyectos anteriores. 3. Definido: se adopta un proceso sw. estándar, y se adapta a cada proyecto. 3. Definido: se adopta un proceso sw. estándar, y se adapta a cada proyecto. 4. Gestionado: la calidad del producto y del proceso es medida, predecible y cuantificable. Se pueden usar dichas medidas (métricas del software) para detectar situaciones excepcionales y corregirlas. 4. Gestionado: la calidad del producto y del proceso es medida, predecible y cuantificable. Se pueden usar dichas medidas (métricas del software) para detectar situaciones excepcionales y corregirlas. 5. Optimizado: el proceso es continuamente mejorado usando las medidas obtenidas de procesos anteriores. 5. Optimizado: el proceso es continuamente mejorado usando las medidas obtenidas de procesos anteriores.

12 CMM - Madurez del proceso 1.Representa una situacion sin ningun esfuerzo en la garantia de calidad y gestion del proyecto, donde cada equipo puede desarrollar software de cualquier forma eligiendo los metodos, estandares y procedimientos a utilizar que podrian variar desde lo mejor hasta lo peor. 1.Representa una situacion sin ningun esfuerzo en la garantia de calidad y gestion del proyecto, donde cada equipo puede desarrollar software de cualquier forma eligiendo los metodos, estandares y procedimientos a utilizar que podrian variar desde lo mejor hasta lo peor. 2. Ha definido ciertas actividades tales como el informe del esfuerzo y del tiempo empleado, y el informe de tareas realizadas 2. Ha definido ciertas actividades tales como el informe del esfuerzo y del tiempo empleado, y el informe de tareas realizadas 3. Ha definido procesos tecnicos como de gestion por ejemplo un estandar en la programacion y se hace cumplir por medio de procedimientos como auditorias. Pretenden conseguir el estandar ISO Ha definido procesos tecnicos como de gestion por ejemplo un estandar en la programacion y se hace cumplir por medio de procedimientos como auditorias. Pretenden conseguir el estandar ISO Concepto de medicion y el uso de metricas. 4.Concepto de medicion y el uso de metricas.

13 CMM - Madurez del proceso 5- Es el nivel mas alto de alcanzar, hasta ahora muy pocos han alcanzado esta fase, representa la analogia del software con los mecanismos de control de calidad que existen en otras industrias de mayor madurez. Para que se alcance el nivel 5 tiene que tener cada proceso bien definido rigurosamente y seguirlo al pie de la letra 5- Es el nivel mas alto de alcanzar, hasta ahora muy pocos han alcanzado esta fase, representa la analogia del software con los mecanismos de control de calidad que existen en otras industrias de mayor madurez. Para que se alcance el nivel 5 tiene que tener cada proceso bien definido rigurosamente y seguirlo al pie de la letra

14 Nivel 2: Gestion de requisitos, planificacion del proyecto de software, seguimiento y supervision, garantia de calidad. Nivel 2: Gestion de requisitos, planificacion del proyecto de software, seguimiento y supervision, garantia de calidad. Nivel 3: Revisiones periodicas, coordinacion entre grupos, gestion de integracion del software, definicion del proceso de la organización, enfoque del proceso de la organización. Nivel 3: Revisiones periodicas, coordinacion entre grupos, gestion de integracion del software, definicion del proceso de la organización, enfoque del proceso de la organización. Nivel 4: Gestion de la calidad del software, Gestion Cuantitativa del proceso. Nivel 4: Gestion de la calidad del software, Gestion Cuantitativa del proceso. Nivel 5: Gestion de cambios del proceso, Gestion de cambios de tecnologia, prevencion de defectos. Nivel 5: Gestion de cambios del proceso, Gestion de cambios de tecnologia, prevencion de defectos.

15

16

17 Procesos estándar Multitud de estándares, métodos, técnicas, y entornos para desarrollar y gestionar software Software usado en multitud de sistemas diferentes: militar, finanzas, medicina, etc. Dificultades para gestionar la producción de software, integrando productos y servicios

18 Procesos estándar Necesario conseguir un marco común para hablar el mismo lenguaje en el desarrollo y gestión de software Necesario conseguir un marco común para hablar el mismo lenguaje en el desarrollo y gestión de software Objetivo: definir los procesos de desarrollo y mantenimiento del software, y de gestión del mismo, de forma genérica y abstracta Objetivo: definir los procesos de desarrollo y mantenimiento del software, y de gestión del mismo, de forma genérica y abstracta Marco común Estándares del ciclo de vida Marco común Estándares del ciclo de vida

19 Procesos estándar Estándar de calidad: ISO 9000 Familia de estándares para la gestión de la calidad de cualquier proceso de producción. Familia de estándares para la gestión de la calidad de cualquier proceso de producción. La organización debe tener un sistema de calidad que supervise todas las fases de la producción y entrega del producto: La organización debe tener un sistema de calidad que supervise todas las fases de la producción y entrega del producto: audita los proyectos para asegurar que se cumplen los controles de calidad. audita los proyectos para asegurar que se cumplen los controles de calidad. mejora la calidad del propio sistema de calidad. mejora la calidad del propio sistema de calidad. proporciona entradas al grupo de desarrollo (como nuevas notaciones, procedimientos, estándares). proporciona entradas al grupo de desarrollo (como nuevas notaciones, procedimientos, estándares). produce informes para la dirección. produce informes para la dirección. Para cada proyecto se define un plan de calidad. Para cada proyecto se define un plan de calidad.

20 ISO 9000 para producción de software (Pressman 2002) p.146 ISO Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation and Servicing. ISO Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation and Servicing. Describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño Describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño Aplicable a cualquier proceso de producción: cojinetes, automóviles, TVs, equipamientos deportivos, etc. Aplicable a cualquier proceso de producción: cojinetes, automóviles, TVs, equipamientos deportivos, etc. Se está convirtiendo en el ppal. medio con el que los clientes pueden juzgar la competencia de un desarrollador de software (aceptado en más de 130 países). Se está convirtiendo en el ppal. medio con el que los clientes pueden juzgar la competencia de un desarrollador de software (aceptado en más de 130 países). Se han desarrollado varios documentos que relacionan el estándar con la industria del software, pero no entran en muchos detalles. Se han desarrollado varios documentos que relacionan el estándar con la industria del software, pero no entran en muchos detalles. No impone ciclo de vida. No impone ciclo de vida. Puede adoptarse por contrato o voluntariamente. Puede adoptarse por contrato o voluntariamente.

21 ISO 9000 para producción de software ISO Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation and Servicing. ISO Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation and Servicing. El control de calidad se debe realizar en todas las fases del desarrollo, adquisición y mantenimiento del software. El control de calidad se debe realizar en todas las fases del desarrollo, adquisición y mantenimiento del software. El comprador debe cooperar estrechamente con el suministrador del software. El comprador debe cooperar estrechamente con el suministrador del software. El suministrador debe definir su sistema de calidad, y asegurar que todo el sistema comprende e implementa dicho sistema de calidad. El suministrador debe definir su sistema de calidad, y asegurar que todo el sistema comprende e implementa dicho sistema de calidad.

22 ISO 9000 para producción de software (II) Responsabilidad de la gestión Responsabilidad de la gestión Inspección, medición y equipo de pruebas Inspección, medición y equipo de pruebas Sistema de calidad Sistema de calidad Inspección y estado de las pruebas Inspección y estado de las pruebas Revisión de contrato Revisión de contrato Acción correctiva Acción correctiva Control de producto no aceptado Control de producto no aceptado Control de documento Control de documento Tratamiento, almacenamiento, empaquetamiento y entrega Tratamiento, almacenamiento, empaquetamiento y entrega Compras Producto proporcionado al comprador Registros de calidad Identificación y posibilidad de seguimiento del producto Auditorías internas de calidad Formación Control del proceso Servicios Inspección y estado de prueba Técnicas estadísticas ISO Impone 20 requisitos:

23 ISO 9000 para producción de software (III) ISO Guidelines for Application of ISO 9001 to the Development, Supply and Maintenance of Software ISO Guidelines for Application of ISO 9001 to the Development, Supply and Maintenance of Software Contiene directrices que interpretan ISO 9001 para el desarrollador de software Contiene directrices que interpretan ISO 9001 para el desarrollador de software ISO Quality Management and Quality Systems Elements - Part 2. ISO Quality Management and Quality Systems Elements - Part 2. Contiene guías para proporcionar servicios de software, como por ejemplo el soporte de usuario. Contiene guías para proporcionar servicios de software, como por ejemplo el soporte de usuario.

24 Efecto bola de nieve

25 Gestión de Proyectos La gestión de proyectos es el proceso por el cual se planifica, dirige y controla el desarrollo de un sistema aceptable con un costo mínimo y dentro de un período de tiempo especifico. La gestión de proyectos es el proceso por el cual se planifica, dirige y controla el desarrollo de un sistema aceptable con un costo mínimo y dentro de un período de tiempo especifico. Causas de proyectos fallidos por la gestión de proyectos. Dentro de las principales causas por las que puede fallar un proyecto, se encuentra el hecho de que los analistas no respetan o no conocen bien las herramientas y las técnicas del análisis y diseño de sistemas, además de esto puede haber una mala gestión y dirección del proyecto. Además existen una serie de factores que pueden hacer que el sistema sea mal evaluado, entre estas están: ·Necesidades no satisfechas o no identificadas · Cambio no controlado del ámbito del proyecto ·Exceso de costo ·Retrasos en la entrega. Causas de proyectos fallidos por la gestión de proyectos. Dentro de las principales causas por las que puede fallar un proyecto, se encuentra el hecho de que los analistas no respetan o no conocen bien las herramientas y las técnicas del análisis y diseño de sistemas, además de esto puede haber una mala gestión y dirección del proyecto. Además existen una serie de factores que pueden hacer que el sistema sea mal evaluado, entre estas están: ·Necesidades no satisfechas o no identificadas · Cambio no controlado del ámbito del proyecto ·Exceso de costo ·Retrasos en la entrega.

26 Gestión de Proyectos La gestión de proyectos de software persigue la misma finalidad que todas las gestiones de proyectos de ingeniería · Estimar que sucederá con un proyecto nuevo · Analizar qué sucedió con un proyecto ya finalizado En todos los casos se tratará de dar respuestas cuantitativas a preguntas precisas tales como: · ¿Cuál será el plazo de entrega? · ¿Cuántas personas necesito? · ¿Cuánto costará el proyecto? La gestión de proyectos de software es una rama especializada de la Ing. de software. La gestión de proyectos de software persigue la misma finalidad que todas las gestiones de proyectos de ingeniería · Estimar que sucederá con un proyecto nuevo · Analizar qué sucedió con un proyecto ya finalizado En todos los casos se tratará de dar respuestas cuantitativas a preguntas precisas tales como: · ¿Cuál será el plazo de entrega? · ¿Cuántas personas necesito? · ¿Cuánto costará el proyecto? La gestión de proyectos de software es una rama especializada de la Ing. de software.

27 Gestión de Proyectos Por esta razón, estamos hablando de una rama de la ingeniería que: Emplea metodologías bien definidas. Realiza medidas repetibles y confiables. Estima costos y tiempos. Da elementos para la gestión de los proyectos. Replantea resultados para ajustar la información disponible. Por esta razón, estamos hablando de una rama de la ingeniería que: Emplea metodologías bien definidas. Realiza medidas repetibles y confiables. Estima costos y tiempos. Da elementos para la gestión de los proyectos. Replantea resultados para ajustar la información disponible. Diferentes tipos de proyectos Debemos diferenciar tres tipos de proyectos desde el punto de vista de su gestión: · Proyectos nuevos: se busca analizar costos, tiempos y cantidad de personas. Es el caso más difícil de todos. · Replanteo de proyectos viejos: se busca afinar la metodologías de estimación. Es la principal fuente de información · Extensiones: o ampliaciones de un proyecto existente: Es un caso intermedio donde se desea tener buena precisión en plazos y costos Diferentes tipos de proyectos Debemos diferenciar tres tipos de proyectos desde el punto de vista de su gestión: · Proyectos nuevos: se busca analizar costos, tiempos y cantidad de personas. Es el caso más difícil de todos. · Replanteo de proyectos viejos: se busca afinar la metodologías de estimación. Es la principal fuente de información · Extensiones: o ampliaciones de un proyecto existente: Es un caso intermedio donde se desea tener buena precisión en plazos y costos

28 Gestion de Proyectos El tamaño de los proyectos Los proyectos de software son diferentes por la sola razón de su tamaño. Proyectos pequeños: consisten solamente en implementación. No tienen costos indirectos importantes Proyectos medianos: es un caso intermedio entre los dos. Proyectos grandes: poseen implementación, pero hay más cosas. Poseen gerencia de proyecto, control de calidad, capacitación de personal, hay un plan de mantenimiento, hay documentación importante para uso interno y externo. Se genera información para mercadeo. Un error clásico en la historia de la gestión de proyectos fue no advertir la existencia de éstas tres categorías y es un error pensar que la experiencia adquirida en proyectos pequeños nos pueda servir en proyectos medianos o grandes. El tamaño de los proyectos Los proyectos de software son diferentes por la sola razón de su tamaño. Proyectos pequeños: consisten solamente en implementación. No tienen costos indirectos importantes Proyectos medianos: es un caso intermedio entre los dos. Proyectos grandes: poseen implementación, pero hay más cosas. Poseen gerencia de proyecto, control de calidad, capacitación de personal, hay un plan de mantenimiento, hay documentación importante para uso interno y externo. Se genera información para mercadeo. Un error clásico en la historia de la gestión de proyectos fue no advertir la existencia de éstas tres categorías y es un error pensar que la experiencia adquirida en proyectos pequeños nos pueda servir en proyectos medianos o grandes.

29 Gestión de Proyectos Personal Sin duda alguna en todas las empresas el elemento más importante es el recurso humano o personal. Personal Sin duda alguna en todas las empresas el elemento más importante es el recurso humano o personal. El equipo de dirección del proyecto debe identificar a los interesados, determinar sus requisitos y expectativas y, gestionar su influencia en relación con los requisitos para asegurar un proyecto exitoso. El equipo de dirección del proyecto debe identificar a los interesados, determinar sus requisitos y expectativas y, gestionar su influencia en relación con los requisitos para asegurar un proyecto exitoso. ¿Qué tomar en cuenta? Reclutamiento, selección, entrenamiento, diseño de la organización. Participantes: Se proponen las siguientes categorías: Gestores Ejecutivos.- definen aspectos del negocio Gestores del proyecto.- planifican, motivan, organizan controlan a los profesionales que realizan trabajo de sw. Profesionales.- dan habilidades para la ingeniería de una aplicación. ¿Qué tomar en cuenta? Reclutamiento, selección, entrenamiento, diseño de la organización. Participantes: Se proponen las siguientes categorías: Gestores Ejecutivos.- definen aspectos del negocio Gestores del proyecto.- planifican, motivan, organizan controlan a los profesionales que realizan trabajo de sw. Profesionales.- dan habilidades para la ingeniería de una aplicación. Clientes.-especifican requisitos y necesidades Usuarios Finales.- quienes interactúan con el sistema. Clientes.-especifican requisitos y necesidades Usuarios Finales.- quienes interactúan con el sistema.

30 Gestión de Proyectos -Director del proyecto. Dirige el proyecto. Cliente/usuario. Persona u organización que utilizará el producto del proyecto. - Organización ejecutante. Empresa cuyos empleados participan más directamente en el trabajo del proyecto. Miembros del equipo del proyecto. El grupo que realiza el trabajo del proyecto. - Equipo de dirección del proyecto. Miembros del equipo del proyecto que participan directamente en las actividades de dirección del proyecto. - Patrocinador. Persona o grupo que proporciona los recursos financieros, monetarios o en especie, para el proyecto. Influyentes. Personas o grupos que no están directamente relacionados con la adquisición o el uso del producto del proyecto, pero que, debido a su posición en la organización del cliente u organización ejecutante, pueden ejercer una influencia positiva o negativa sobre el curso del proyecto.

31 Gestión de Proyectos ¿Cómo estructurar un equipo? Se debe tener en cuenta las siguientes consideraciones: La dificultad del problema que se resolverá. El tamaño del programa resultante en líneas de código. Vida del equipo (trabajo en conjunto) El grado en el que el problema puede separarse en módulos. requeridas La calidad y confiabilidad requeridas del sistema que se construirá. La rigidez de la fecha de entrega. El grado de comunicación que requiere el proyecto

32 Gestión de Proyectos Factores que inciden negativamente en un ambiente de trabajo en equipo: 1. Una atmósfera de trabajo frenética 2. Alta frustración que provoca fricción entre los miembros del equipo 3. Proceso de software pobremente coordinado 4. Una definición poco clara de los papeles del equipo de sw. 5. Continuas y repetidas exposiciones al fracaso.

33 Gestión de Proyectos Proyecto La gestión de un proyecto de software exitoso requiere entender qué puede salir mal. A continuación se indican 10 señales de que un proyecto esté en peligro. 1. El personal de software no entiende las necesidades de sus clientes. 2. El ámbito del producto está mas definido 3. Los cambios se gestionan mal 4-La tecnología elegida cambia 5. Las necesidades comerciales cambian 6. Los plazos de entrega no son realistas 7. Los usuarios se resisten 8. Se pierde el patrocinio 9. El equipo de proyecto carece de personal con las habilidades apropiadas 10. Los gestores evitan las mejores practicas y las lecciones aprendidas

34 Gestión de Proyectos Funciones básicas del director de proyectos: Un director de proyectos debe aplicar un conjunto de técnicas y conocimientos diferentes de los que aplica un analista. Las funciones básicas de un director o un jefe de proyectos han sido analizadas y diseccionadas por teóricos de la gestión durante muchos años. Entre estas funciones, se incluyen la planificación, la selección de personal, la organización, la definición de calendarios, la dirección y el control.

35 Gestión de Proyectos Planificación de las tareas de proyecto y selección del equipo de proyectos El director evalúa las necesidades de recursos y formula un plan para llegar al sistema objeto. Ello se basa en el conocimiento que tiene el director de los requisitos del sistema objeto en cada momento del desarrollo. Un plan básico para el desarrollo de un sistema de información es el suministrado por el ciclo de vida del desarrollo de sistemas. Muchas empresas tienen su propio ciclo de vida estándar, y algunas de ellas tienen también normas sobre métodos y herramientas que han de usarse. Así ha de planificarse cada una de las tareas requeridas para completar el proyecto: ¿Cuánto tiempo se requerirá? ¿Cuántas personas serán necesarias? ¿Cuánto costara la tarea? ¿Qué tareas deben terminarse antes de empezar otras? ¿Pueden solaparse algunas de ellas?

36 Gestión de Proyectos Planificación de las tareas de proyecto y selección del equipo de proyectos Los directores de los proyectos son, frecuentemente, los encargados de seleccionar a los analistas y los programadores de un equipo de proyecto. El director de proyectos debería tener muy en cuenta los conocimientos técnicos y de empresa que pueden ser necesarios para terminar un proyecto con éxito. La clave de esta misión es saber elegir adecuadamente a las personas que habrían de desarrollar las tareas requeridas e identificada como parte de la planificación de proyecto

37 Gestión de Proyectos Organización y definición de calendarios para el proyecto Dados el plan y el equipo de proyecto, el director de proyecto es el responsable de la organización y la definición del calendario del mismo. Los miembros del equipo de proyecto deberán conocer su cometido y sus responsabilidades concretas, así como su relación de dependencia con el respecto al director de proyecto.

38 Gestión de Proyectos Organización y definición de calendarios para el proyecto El calendario de proyecto debería desarrollarse con un conocimiento preciso de los requisitos de tiempo, las asignaciones de personal y las dependencias de unas tareas con otras. Muchos proyectos tienen un límite a la fecha de entrega solicitada. El director del proyecto debe determinar si puede elaborarse un calendario factible basado en dicha fecha. Si ni fuera así, debería retrasarse el limite o reajustarse el, ámbito del proyecto.

39 Gestión de Proyectos Dirección y control del proyecto Una vez iniciado el proyecto, el director del proyecto se convierte en su máximo responsable. Como tal, dirige las actividades del equipo y hace evaluaciones del avance del proyecto. Por consiguiente, todo director de proyectos debe demostrar ante su equipo cualidades de dirección, como son saber motivar, recompensar, asesorar, coordinar, delegar funciones y reconocer el trabajo de los miembros de su equipo. Además, el director debe informar frecuentemente del avance del proyecto ante sus superiores. Tal vez, la función más difícil e importante del director sea controlar el proyecto.

40 Gestión de Proyectos Dirección y control del proyecto Pocos planes hay que puedan llevarse a la practica sin problemas y retrasos. La labor del director de proyectos es hacer un seguimiento de las tareas, los plazos, los costes y las expectativas, con el fin de controlar todos los estos elementos. Si el ámbito del proyecto tiende a crecer, el director del mismo debe tomar una decisión: ¿habría que reducir el ámbito del proyecto para respetar el presupuesto y los plazos, o revisar dicho presupuesto y dichos plazos? El director del proyecto debería ser capaz de presentar alternativas, y sus implicaciones, a los plazos y presupuestos para saber responder a las expectativas.


Descargar ppt "Ingenieria del Software UMG Capítulo 3. Gestión de Proyectos de Software."

Presentaciones similares


Anuncios Google