Gestión de proyectos

Gestión de proyectos

1. Objetivos

   • El objetivo de este capítulo es dar un panorama de la gestión de proyectos de software.
     • - Conocerá las tareas principales de los gestores de proyectos de software.
     • -Comprenderá por qué la naturaleza del software hace más difícil la gestión de proyectos 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.

2. ¿Que es?

   • La gestión de proyectos de software es una parte esencial de la ingeniería del software. El software es entregado tarde, los costes son mayores que los estimados y los requerimientos no se cumplen. Los gestores de software son responsables de la planificación y temporalización del desarrollo de los proyectos. La administración de proyectos de software es necesaria debido a que la ingeniería de software profesional siempre está sujeta a restricciones organizacionales de tiempo y presupuesto. El trabajo del gestor de proyectos de software es asegurar que éstos cumplan dichas restricciones y entregar software que contribuya a las metas de la compañía de desarrollo software.
     • Los gestores de software hacen el mismo tipo de trabajo que otros gestores. Sin embargo, la ingeniería del software es diferente en varios aspectos a otros tipos, lo que hace a la gestión de software particularmente difícil. Algunas de estas diferencias son las siguientes:
       • El producto es intangible: El software es intangible. No se puede ver ni tocar. Los gestores de proyectos de software no pueden ver el progreso. Confían en otros para elaborar la documentación necesaria para revisar el progreso.
       • No existen procesos del software estándar: Los procesos de software varían notablemente de una organización a otra. A pesar de que la comprensión del proceso del software se ha desarrollado de forma significativa en los últimos años, aún no se puede predecir con certeza cuándo un proceso particular tiende a desarrollar problemas.
       • A menudo los proyectos grandes son únicos: Por lo general, los proyectos grandes de software son diferentes de proyectos previos. En consecuencia, los gestores, aun cuando cuenten con una amplia experiencia, ésta no es suficiente para anticipar los problemas. Más aún, los rápidos cambios tecnológicos en las computadoras y las comunicaciones hacen parecer obsoleta la experiencia previa.

3. Actividades de gestión

   • Es imposible redactar una descripción estándar del trabajo de un gestor de software. El trabajo difiere enormemente dependiendo de la organización y del producto de software a desarrollar. Sin embargo, en algún momento, muchos gestores son responsables de algunas o de la totalidad de las siguientes actividades: • 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 La primera etapa de un proyecto de software implica redactar una propuesta para realizar ese proyecto. La redacción de la propuesta es una tarea crítica, ya que la existencia de muchas organizaciones de software depende de las propuestas aceptadas y los contratos asignados. la redacción de propuestas es una habilidad que se adquiere con la práctica y la experiencia. La planificación de proyectos se refiere a la identificación de actividades,

4. Planificación del proyecto

   • La gestión efectiva de un proyecto de software depende de planificar completamente el progreso del proyecto. Después de algún tiempo (por lo general 2 o 3 semanas), se revisa el proyecto y se señalan las discrepancias. Debido a que las estimaciones inicíales de los parámetros del proyecto son aproximaciones. el plan siempre deberá actualizarse. Cuando se dispone de más información, los gestores del proyecto revisan las suposiciones del proyecto y la agenda. El objetivo de esta revisión es encontrar un enfoque alternativo que se ajuste a las restricciones del proyecto y cumpla con las metas del calendario. Por supuesto, los gestores de proyectos inteligentes no suponen que todo irá bien.
     • 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. Los detalles de este plan varían dependiendo del tipo de proyecto y de la organización. Describe la forma en que el equipo de desarrollo está organizado, la gente involucrada y sus roles en el equipo. Describe los posibles riesgos del proyecto, la probabilidad de que surjan estos riesgos y las estrategias de reducción de riesgos propuestas. Describe la gestión de informes y cuándo deben producirse, así como los mecanismos de supervisión del proyecto a utilizar. El plan del proyecto debe revisarse regularmente durante el proyecto.
     • Hitos y entregas
       • Sin esta información, es imposible juzgar el progreso y no se pueden actualizar los costes y calendarios. Cuando se planifica un proyecto, se debe establecer una serie de hitos —puntos finales de una actividad del proceso del software— . Los hitos indefinidos como «80 % del código completo» son imposibles de validar y carecen de utilidad para la gestión del proyecto. No podemos validar si se ha llegado a esta etapa debido a que la cantidad de código que se tiene que desarrollar no es precisa. Una entrega es el resultado del proyecto que se entrega al cliente. Dichos hitos pueden ser resultados internos del proyecto que son utilizados por el gestor del proyecto para verificar el progreso del mismo pero que no se entregan al cliente. Para establecer los hitos, el proceso del software debe dividirse en actividades básicas con sus salidas asociadas.

5. Calendarización del proyecto

   • Ésta es una de las tareas más difíciles para los gestores de proyectos. La estimación del calendario se complica más por el hecho de que proyectos diferentes pueden utilizar métodos de diseño y lenguajes de implementación diferentes. Si el proyecto es técnicamente complejo, las estimaciones iniciales casi siempre son optimistas aun cuando los gestores traten de considerar las eventualidades. Este factor extra de contingencia depende del tipo de proyecto, de los parámetros del proceso (fecha de entrega, estándares, etcétera) y de la calidad y experiencia de los ingenieros de software que trabajen en el proyecto. Como regla, para los problemas previstos siempre debe agregarse un 30 % a la estimación original y otro 20 % para cubrir algunas cosas no previstas. Por lo general, el calendario del proyecto se representa como un conjunto de gráficos que muestran la división del trabajo, las dependencias de las actividades y la asignación del personal.
     • Gráficos de barras y redes de actividades
       • Los gráficos de barras y las redes de actividades son notaciones gráficas que se utilizan para ilustrar la calendarización del proyecto. Los gráficos de barras y las redes de actividades se generan automáticamente a partir de una base de datos de la información del proyecto utilizando una herramienta de gestión de proyectos. Considere el conjunto de actividades que se muestra en la Figura 5.5. Antes de que se inicie la implementación, el diseño debe estar terminado. Dadas la dependencia y la duración estimada de las actividades, una red de actividades muestra la sucesión de actividades que deben generarse (véase la Figura 5.6). rror y se distinguen por no tener asociada una barra sombreada. Además de considerar la calendarización, los gestores de proyectos también deben tener en cuenta la asignación de recursos y, en particular, la asignación de personal a las actividades del proyecto.

6. Gestión de riesgos

   • Una tarea importante del gestor de proyectos es anticipar los riesgos que podrían afectar a la programación del proyecto o a la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. Estas incertidumbres son el resultado de los requerimientos ambiguamente definidos, las dificultades en la estimación de tiempos y los recursos para el desarrollo del software, la dependencia en las habilidades individuales, y los cambios en los requerimientos debidos a los cambios en las necesidades del cliente. 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. El proceso de gestión de riesgos, como otros de planificación de proyectos, es un proceso iterativo que se aplica a lo largo de todo el proyecto. La prevención de riesgos y los planes de contingencia se deben modificar tan pronto como surja nueva información de los riesgos.
     • Identificación de riesgos
       • Ésta es la primera etapa de la gestión de riesgos. En principio, no hay que valorarlos o darles prioridad en esta etapa aunque, en la práctica, por lo general no se consideran los riesgos con consecuencias menores o con baja probabilidad. Esta identificación se puede llevar a cabo a través de un proceso de grupo utilizando un enfoque de tormenta de ideas o simplemente puede basarse en la experiencia. Se derivan de los estimados administrativos de las características del sistema y los recursos requeridos para construir dicho sistema. El resultado de este proceso debe ser una larga lista de riesgos que podrían presentarse y afectar al producto, al proceso o al negocio.
     • Análisis de riesgos
       • No se hace una valoración con números precisos sino en intervalos: • La probabilidad del riesgo se puede valorar como muy bajo (< 10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75% ). • Los efectos del riesgo pueden ser valorados como catastrófico, serio, tolerable o insignificante. El resultado de este proceso de análisis se debe colocar en una tabla, la cual debe estar ordenada según la seriedad del riesgo. Este discernimiento debe depender de una combinación de la probabilidad de aparición del riesgo y de los efectos del mismo. En general, siempre se deben tener en cuenta todos los riesgos catastróficos, así como todos los riesgos serios que tienen más que una moderada probabilidad de ocurrir. Boehm (Boehm, 1988) recomienda identificar y supervisar los «10 riesgos más altos», pero este número parece demasiado arbitrario.
     • Supervisión de riesgos
       • La supervisión de riesgos normalmente valora cada uno de los riesgos identificados para decidir si éste es más o menos probable y si han cambiado sus efectos. Por supuesto, esto no se puede observar de forma directa, por lo que se tienen que buscar otros factores para dar indicios de la probabilidad del riesgo y sus efectos. Obviamente, estos factores dependen de los tipos de riesgo. La supervisión de riesgos debe ser un proceso continuo y, en cada revisión del progreso de gestión, cada uno de los riesgos clave debe ser considerado y analizado por separado.