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

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

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

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

Ingenieria del Software Ingenieria del Software UMGUMG

Capítulo 3. Gestión de Proyectos de Capítulo 3. Gestión de Proyectos de SoftwareSoftware

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

““Caminar sobre las aguas y desarrollar Caminar sobre las aguas y desarrollar programas a partir de las programas a partir de las

especificaciones es fácil, si ambas especificaciones es fácil, si ambas están congeladas”están congeladas”

Edward V. BerardEdward V. Berard

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

El proceso del software. El proceso del software. EstructuraEstructura

Estándares en ingeniería del softwareEstándares en ingeniería del software Utilidad de los estándaresUtilidad de los estándares Tipos de estándaresTipos de estándares

Estándares relacionados con el proceso softwareEstándares relacionados con el proceso software De evaluación del proceso software: SEI(software De evaluación del proceso software: SEI(software

Engineering Institute) CMM (Modelo de capacidad de Engineering Institute) CMM (Modelo de capacidad de Madurez)Madurez)

De procesos estándar del ciclo de vidaDe procesos estándar del ciclo de vida ISO 9000 ISO 9000

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

Proceso softwareProceso software

Distintos procesos de software organizan Distintos procesos de software organizan las actividades de diferentes formas, y las las actividades de diferentes formas, y las describen con diferente nivel de detalledescriben con diferente nivel de detalle El tiempo de cada actividad varía, así como los El tiempo de cada actividad varía, así como los

resultadosresultados Organizaciones diferentes usan procesos Organizaciones diferentes usan procesos

diferentes para producir el mismo productodiferentes para producir el mismo producto Sin embargo, para algunos tipos de Sin embargo, para algunos tipos de

aplicación, algunos procesos son más aplicación, algunos procesos son más convenientes que otrosconvenientes que otros

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

Ciclo de vidaCiclo de vida

Alternativamente, a veces se Alternativamente, a veces se usan los términos 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 Sucesión de etapas por las que atraviesa un producto software a lo atraviesa un producto software a lo largo de su existencia (durante su largo de su existencia (durante su desarrollo y explotación)desarrollo y explotación)

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

Ciclo de vida (II)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

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

Estándares en ingeniería del Estándares en ingeniería del softwaresoftware

EstándarEstándar: conjunto de criterios : conjunto de criterios aprobados, documentados y aprobados, documentados y disponibles para determinar la disponibles para determinar la adecuación de una acción (adecuación de una acción (estándar estándar de procesode proceso) o de un objeto () o de un objeto (estándar estándar de productode producto) )

GuíaGuía: conjunto de criterios bien : conjunto de criterios bien definidos y documentados que definidos y documentados que encaminan una actividad o tareaencaminan una actividad o tarea

es más flexible que un estándares más flexible que un estándar

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

¿Porqué usar estándares en ¿Porqué usar estándares en ingeniería del software?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 agrupan lo mejor y más apropiado de las

buenas prácticas y usos del desarrollo de buenas prácticas y usos del desarrollo de softwaresoftware

engloban los “conocimientos” que son engloban los “conocimientos” que son patrimonio de una organizaciónpatrimonio de una organización

proporcionan un marco para implementar proporcionan un marco para implementar procedimientos de aseguramiento de la calidadprocedimientos de aseguramiento de la calidad

proporcionan continuidad entre el trabajo de proporcionan continuidad entre el trabajo de distintas personasdistintas personas

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

Tipos de estándares en Tipos de estándares en ingeniería del softwareingeniería del software

Estándares para datos:Estándares para datos:desde asignar nombres a los datos y especificar longitud desde asignar nombres a los datos y especificar longitud

y tipo hasta los relacionados con BBDDy tipo hasta los relacionados con BBDDp.ej., Ansi SQLp.ej., Ansi SQL

Estándares de codificación:Estándares de codificación:abreviaturas y designaciones formales para describir abreviaturas y designaciones formales para describir

actividades dentro de la organización p.ej., Notacion actividades dentro de la organización p.ej., Notacion Hungara.Hungara.

Estándares estructurales:Estándares estructurales:políticas de división del software en módulospolíticas de división del software en módulos

Estándares de documentaciónEstándares de documentación Estándares de proceso softwareEstándares de proceso software Estándares para otras actividadesEstándares para otras actividades

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

Métodos de evaluaciónMétodos de evaluaciónSEI’s CMM (SEI’s CMM (Capability Maturity ModelCapability Maturity Model))

Tiempo

Nivel5

4

3

2

1 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

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

CMM - Madurez del procesoCMM - Madurez del proceso

1. Inicial: 1. Inicial: el éxito depende el éxito depende de esfuerzos heroicos y de esfuerzos heroicos y personales más que de personales más que de procesos adecuadamente procesos adecuadamente definidos. No hay proceso definidos. No hay proceso definido implícita o definido implícita o explícitamente.explícitamente.

2. Repetible: 2. Repetible: se establecen se establecen políticas y procedimientos para políticas y procedimientos para llevar a cabo un proyecto. Una llevar a cabo un proyecto. Una función de calidad asegura que función de calidad asegura que se cumplen dichos se cumplen dichos procedimientos. Se obtienen procedimientos. Se obtienen niveles de calidad parecidos a niveles de calidad parecidos a proyectos anteriores.proyectos anteriores.

3. Definido: 3. Definido: se adopta un se adopta un proceso sw. estándar, y se proceso sw. estándar, y se adapta a cada proyecto.adapta a cada proyecto.

4. Gestionado: 4. Gestionado: la calidad la calidad del producto y del proceso es del producto y del proceso es medida, predecible y medida, predecible y cuantificable. Se pueden usar cuantificable. Se pueden usar dichas medidas (“métricas del dichas medidas (“métricas del software”) para detectar software”) para detectar situaciones excepcionales y situaciones excepcionales y corregirlas.corregirlas.

5. Optimizado: 5. Optimizado: el el proceso es continuamente proceso es continuamente mejorado usando las medidas mejorado usando las medidas obtenidas de procesos obtenidas de procesos anteriores.anteriores.

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

CMM - Madurez del procesoCMM - Madurez del proceso

1.Representa una 1.Representa una situacion sin ningun situacion sin ningun esfuerzo en la garantia de esfuerzo en la garantia de calidad y gestion del calidad y gestion del proyecto, donde cada proyecto, donde cada equipo puede desarrollar equipo puede desarrollar software de cualquier software de cualquier forma eligiendo los forma eligiendo los metodos, estandares y metodos, estandares y procedimientos a utilizar procedimientos a utilizar que podrian variar desde que podrian variar desde lo mejor hasta lo peor.lo mejor hasta lo peor.

2. Ha definido ciertas 2. Ha definido ciertas actividades tales como el actividades tales como el informe del esfuerzo y del informe del esfuerzo y del tiempo empleado, y el tiempo empleado, y el informe de tareas informe de tareas realizadasrealizadas

3. Ha definido procesos 3. Ha definido procesos tecnicos como de tecnicos como de gestion por ejemplo un gestion por ejemplo un estandar en la estandar en la programacion y se hace programacion y se hace cumplir por medio de cumplir por medio de procedimientos como procedimientos como auditorias. Pretenden auditorias. Pretenden conseguir el estandar conseguir el estandar ISO 9000ISO 9000..

4.Concepto de 4.Concepto de medicion y el uso de medicion y el uso de metricasmetricas. .

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

CMM - Madurez del procesoCMM - Madurez del proceso

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

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

Nivel 2: Gestion de requisitos, planificacion Nivel 2: Gestion de requisitos, planificacion del proyecto de software, seguimiento y del proyecto de software, seguimiento y supervision, garantia de calidad.supervision, garantia de calidad.

Nivel 3: Revisiones periodicas, coordinacion Nivel 3: Revisiones periodicas, coordinacion entre grupos, gestion de integracion del entre grupos, gestion de integracion del software, definicion del proceso de la software, definicion del proceso de la organización, enfoque del proceso de la organización, enfoque del proceso de la organización.organización.

Nivel 4: Gestion de la calidad del software, Nivel 4: Gestion de la calidad del software, Gestion Cuantitativa del proceso.Gestion Cuantitativa del proceso.

Nivel 5: Gestion de cambios del proceso, Nivel 5: Gestion de cambios del proceso, Gestion de cambios de tecnologia, Gestion de cambios de tecnologia, prevencion de defectos.prevencion de defectos.

Page 15: Ingenieria del Software UMG Capítulo 3. Gestión de Proyectos de Software.
Page 16: Ingenieria del Software UMG Capítulo 3. Gestión de Proyectos de Software.
Page 17: Ingenieria del Software UMG Capítulo 3. Gestión de Proyectos de Software.

Procesos estándarProcesos 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

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

Procesos estándarProcesos estándar

Necesario conseguir un Necesario conseguir un marco comúnmarco común para “hablar el mismo lenguaje” en el para “hablar el mismo lenguaje” en el desarrollo y gestión de softwaredesarrollo y gestión de software

ObjetivoObjetivo: definir los procesos de desarrollo : definir los procesos de desarrollo

y mantenimiento del software, y de gestión y mantenimiento del software, y de gestión

del mismo, de forma genérica y abstractadel mismo, de forma genérica y abstracta Marco común Marco común Estándares del ciclo deEstándares del ciclo de

vida vida

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

Procesos estándarProcesos estándarEstándar de calidad: ISO 9000Estándar de calidad: ISO 9000

Familia de estándares para la gestión de la Familia de estándares para la gestión de la calidad de cualquier proceso de producción.calidad de cualquier proceso de producción.

La organización debe tener un La organización debe tener un sistema de sistema de calidad calidad que supervise todas las fases de la que supervise todas las fases de la producción y entrega del producto:producción y entrega del producto: audita los proyectos para asegurar que se audita los proyectos para asegurar que se

cumplen los controles de calidad.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 proporciona entradas al grupo de desarrollo (como

nuevas notaciones, procedimientos, estándares).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 Para cada proyecto se define un plan de calidad.calidad.

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

ISO 9000 para producción de ISO 9000 para producción de software software (Pressman 2002) p.146(Pressman 2002) p.146

ISO 9001. ISO 9001. Quality Systems - Model for Quality Systems - Model for Quality Assurance in Design, Development, Quality Assurance in Design, Development, Production, Installation and Servicing. Production, Installation and Servicing. Describe el sistema de calidad utilizado para mantener el Describe el sistema de calidad utilizado para mantener el

desarrollo de un producto que implique diseñodesarrollo de un producto que implique diseño Aplicable a cualquier proceso de producción: cojinetes, Aplicable a cualquier proceso de producción: cojinetes,

automóviles, TVs, equipamientos deportivos, etc.automóviles, TVs, equipamientos deportivos, etc. Se está convirtiendo en el ppal. medio con el que los Se está convirtiendo en el ppal. medio con el que los

clientes pueden juzgar la competencia de un desarrollador clientes pueden juzgar la competencia de un desarrollador de software (aceptado en más de 130 países).de software (aceptado en más de 130 países).

Se han desarrollado varios documentos que relacionan el Se han desarrollado varios documentos que relacionan el estándar con la industria del software, pero no entran en estándar con la industria del software, pero no entran en muchos detalles.muchos detalles.

No impone ciclo de vida.No impone ciclo de vida. Puede adoptarse por contrato o voluntariamente.Puede adoptarse por contrato o voluntariamente.

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

ISO 9000 para producción de ISO 9000 para producción de softwaresoftware

ISO 9001. ISO 9001. Quality Systems - Model for Quality Quality Systems - Model for Quality Assurance in Design, Development, Production, Assurance in Design, Development, Production, Installation and Servicing.Installation and Servicing. El control de calidad se debe realizar en todas El control de calidad se debe realizar en todas

las fases del desarrollo, adquisición y las fases del desarrollo, adquisición y mantenimiento del software.mantenimiento del software.

El comprador debe cooperar estrechamente El comprador debe cooperar estrechamente con el suministrador del software.con el suministrador del software.

El suministrador debe definir su sistema de El suministrador debe definir su sistema de calidad, y asegurar que todo el sistema calidad, y asegurar que todo el sistema comprende e implementa dicho sistema de comprende e implementa dicho sistema de calidad.calidad.

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

ISO 9000 para producción de ISO 9000 para producción de software (II)software (II)

Responsabilidad de la Responsabilidad de la gestióngestión

Inspección, medición y Inspección, medición y equipo de pruebasequipo de pruebas

Sistema de calidadSistema de calidad Inspección y estado de las Inspección y estado de las

pruebaspruebas Revisión de contratoRevisión de contrato Acción correctivaAcción correctiva Control de producto no Control de producto no

aceptadoaceptado Control de documentoControl de documento Tratamiento, Tratamiento,

almacenamiento, almacenamiento, empaquetamiento y empaquetamiento y entregaentrega

ComprasCompras Producto proporcionado al Producto proporcionado al

compradorcomprador Registros de calidadRegistros de calidad Identificación y posibilidad Identificación y posibilidad

de seguimiento del de seguimiento del productoproducto

Auditorías internas de Auditorías internas de calidadcalidad

FormaciónFormación Control del procesoControl del proceso ServiciosServicios Inspección y estado de Inspección y estado de

pruebaprueba Técnicas estadísticasTécnicas estadísticas

ISO 9001. Impone 20 requisitos:

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

ISO 9000 para producción de ISO 9000 para producción de software (III)software (III)

ISO 9000-3. ISO 9000-3. Guidelines for Application of ISO 9001 Guidelines for Application of ISO 9001 to the Development, Supply and Maintenance of to the Development, Supply and Maintenance of Software Software Contiene directrices que interpretan ISO 9001 para el Contiene directrices que interpretan ISO 9001 para el

desarrollador de softwaredesarrollador de software ISO 9004-2. ISO 9004-2. Quality Management and Quality Quality Management and Quality

Systems Elements - Part 2.Systems Elements - Part 2. Contiene guías para proporcionar servicios de Contiene guías para proporcionar servicios de

software, como por ejemplo el soporte de usuario.software, como por ejemplo el soporte de usuario.

http://iso25000.comhttp://iso25000.com

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

Efecto “bola de nieve”Efecto “bola de nieve”

ANÁLISIS

DISEÑO

IMPLEMENTACIÓN

PRUEBAS

MANTENIMIENTO

COSTE DE ELIMINACIÓN DE ERRORES

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

Gestión de ProyectosGestión de Proyectos La gestión de proyectos es el proceso por el cual se La gestión de proyectos es el proceso por el cual se

planifica, dirige y controla el desarrollo de un planifica, dirige y controla el desarrollo de un sistema aceptable con un costo mínimo y dentro de sistema aceptable con un costo mínimo y dentro de un período de tiempo especifico. un período de tiempo especifico.

Causas de proyectos fallidos por la gestión de Causas de proyectos fallidos por la gestión de proyectos. proyectos. Dentro de las principales causas por las Dentro de las principales causas por las que puede fallar un proyecto, se encuentra el hecho que puede fallar un proyecto, se encuentra el hecho de que los analistas no respetan o no conocen bien de que los analistas no respetan o no conocen bien las herramientas y las técnicas del análisis y diseño las herramientas y las técnicas del análisis y diseño de sistemas, además de esto puede haber una mala de sistemas, además de esto puede haber una mala gestión y dirección del proyecto. Además existen gestión y dirección del proyecto. Además existen una serie de factores que pueden hacer que el una serie de factores que pueden hacer que el sistema sea mal evaluado, entre estas están: sistema sea mal evaluado, entre estas están: ·Necesidades no satisfechas o no identificadas ·Necesidades no satisfechas o no identificadas · · Cambio no controlado del ámbito del proyecto Cambio no controlado del ámbito del proyecto ··Exceso de costo Exceso de costo ··Retrasos en la entrega.Retrasos en la entrega.

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

Gestión de ProyectosGestión de Proyectos La gestión de proyectos de software La gestión de proyectos de software

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

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

Gestión de ProyectosGestión de Proyectos Por esta razón, estamos hablando de una rama de la Por esta razón, estamos hablando de una rama de la

ingeniería que: Emplea metodologías bien definidas. ingeniería que: Emplea metodologías bien definidas. Realiza medidas repetibles y confiables. Estima Realiza medidas repetibles y confiables. Estima costos y tiempos. Da elementos para la gestión de costos y tiempos. Da elementos para la gestión de los proyectos. Replantea resultados para ajustar la los proyectos. Replantea resultados para ajustar la información disponible.información disponible.

Diferentes tipos de proyectosDiferentes tipos de proyectos Debemos Debemos diferenciar tres tipos de proyectos desde el punto de diferenciar tres tipos de proyectos desde el punto de vista de su gestión: · vista de su gestión: · Proyectos nuevos: Proyectos nuevos: se busca se busca analizar costos, tiempos y cantidad de personas. Es el analizar costos, tiempos y cantidad de personas. Es el caso más difícil de todos. · caso más difícil de todos. · Replanteo de proyectos Replanteo de proyectos viejos: viejos: se busca afinar la metodologías de se busca afinar la metodologías de estimación. Es la principal fuente de información · estimación. Es la principal fuente de información · Extensiones: Extensiones: o ampliaciones de un proyecto o ampliaciones de un proyecto existente: Es un caso intermedio donde se desea existente: Es un caso intermedio donde se desea tener buena precisión en plazos y costos tener buena precisión en plazos y costos

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

Gestion de ProyectosGestion de Proyectos El tamaño de los proyectosEl tamaño de los proyectos Los proyectos de Los proyectos de

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

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

Gestión de ProyectosGestión de Proyectos PersonalPersonal Sin duda alguna en todas las empresas el Sin duda alguna en todas las empresas el

elemento más importante es el recurso humano o elemento más importante es el recurso humano o personal. personal.

El equipo de dirección del proyecto debe identificar a El equipo de dirección del proyecto debe identificar a los interesados, determinar sus requisitos y los interesados, determinar sus requisitos y expectativas y, gestionar su influencia en relación con expectativas y, gestionar su influencia en relación con los requisitos para asegurar un proyecto exitoso. los requisitos para asegurar un proyecto exitoso.

¿Qué tomar en cuenta?¿Qué tomar en cuenta? • Reclutamiento, selección, • Reclutamiento, selección, entrenamiento, diseño de la organización. entrenamiento, diseño de la organización. Participantes:Participantes: Se proponen las siguientes categorías: Se proponen las siguientes categorías: Gestores Ejecutivos.-Gestores Ejecutivos.- definen aspectos del negocio definen aspectos del negocio Gestores del proyecto.- Gestores del proyecto.- planifican, motivan, planifican, motivan, organizan controlan a los profesionales que realizan organizan controlan a los profesionales que realizan trabajo de sw. trabajo de sw. Profesionales.- Profesionales.- dan habilidades para dan habilidades para la ingeniería de una aplicación. la ingeniería de una aplicación.

Clientes.-Clientes.-especifican requisitos y necesidades especifican requisitos y necesidades Usuarios Finales.- Usuarios Finales.- quienes interactúan con el quienes interactúan con el sistema. sistema.

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

Gestión de ProyectosGestión de Proyectos-- Director del proyectoDirector del proyecto. Dirige el proyecto. . Dirige el proyecto.

Cliente/usuario.Cliente/usuario. Persona u organización que utilizará el Persona u organización que utilizará el producto del proyecto. producto del proyecto.

- Organización ejecutante.Organización ejecutante. Empresa cuyos empleados Empresa cuyos empleados participan más directamente en el trabajo del proyecto. participan más directamente en el trabajo del proyecto. Miembros del equipo del proyecto. El grupo que realiza el Miembros del equipo del proyecto. El grupo que realiza el trabajo del proyecto. trabajo del proyecto.

- Equipo de dirección del proyecto.Equipo de dirección del proyecto. Miembros del Miembros del equipo del proyecto que participan directamente en las equipo del proyecto que participan directamente en las actividades de dirección del proyecto. actividades de dirección del proyecto.

- Patrocinador. Patrocinador. Persona o grupo que proporciona los Persona o grupo que proporciona los recursos financieros, monetarios o en especie, para el recursos financieros, monetarios o en especie, para el proyecto. proyecto. Influyentes. Influyentes. Personas o grupos que no están Personas o grupos que no están directamente relacionados con la adquisición o el uso del directamente relacionados con la adquisición o el uso del producto del proyecto, pero que, debido a su posición en producto del proyecto, pero que, debido a su posición en la organización del cliente u organización ejecutante, la organización del cliente u organización ejecutante, pueden ejercer una influencia positiva o negativa sobre el pueden ejercer una influencia positiva o negativa sobre el curso del proyecto. curso del proyecto.

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

Gestión de ProyectosGestió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. • La calidad y confiabilidad requeridasrequeridas del sistema que se construirá. • La rigidez de la fecha de entrega. • El grado de comunicación que requiere el proyecto

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

Gestión de ProyectosGestió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.

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

Gestión de ProyectosGestión de ProyectosProyecto 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

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

Gestión de ProyectosGestió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.

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

Gestión de ProyectosGestión de ProyectosPlanificació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?

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

Gestión de ProyectosGestión de ProyectosPlanificació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

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

Gestión de ProyectosGestió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.

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

Gestión de ProyectosGestión de ProyectosOrganizació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.

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

Gestión de ProyectosGestión de ProyectosDirecció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.

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

Gestión de ProyectosGestión de ProyectosDirecció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.