Gestion De Proyectos

I. Conceptos Sobre la Gestión de Proyectos

La gestión de proyectos de software es una actividad protectora dentro de la ingeniería del software.

Inicia antes de hacer cualquier actividad técnica y continúa a lo largo de la definición, desarrollo y del mantenimiento del software

La gestión eficaz de un proyecto de software se centra en las cuatro P’s: Persona, Producto, Proceso y Proyecto. El orden no es arbitrario

I.1 Personal

La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los años 60.

De hecho, el «factor humano» es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software.

Los participantes que colaboran en el proceso del software y todos los proyectos de software se pueden clasificarse en una de estas cinco categorías:

1.- Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.

2.- Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.

3.- Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.

4.- Clientes, que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado.

5.- Usuarios finales, que interaccionan con el software una vez que se ha entregado para la producción.

Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Y este es el trabajo del jefe del equipo.

I.1.1 Los jefes de equipo

La gestión de un proyecto es una actividad intensamente humana, y por esta razón, los profesionales competentes del software a menudo no son buenos jefes de equipo. Simplemente no tienen la mezcla adecuada de capacidades del personal.

Jerry Weinberg sugiere el modelo de gestión MOI:

1.- Motivación. La habilidad para motivar al personal técnico para que produzca conforme a sus mejores capacidades.

2.- Organización. La habilidad para amoldar procesos existentes o crear unos nuevos que permita al concepto inicial transformarse en un producto final.

3.- Ideas o innovación. La habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los límites establecidos para un producto o aplicación de software particular.

Los gestores de proyecto se basan en aplicar un estilo de gestión resaltando cuatro apartados clave:

1.- Resolución del problema. Diagnostica los aspectos técnicos y de la organización más relevante, estructura una solución o motiva a otros para que desarrollen la solución.

2.- Dotes de gestión. Debe tomar las riendas, debe tener confianza para asumir el control cuando sea necesario y la garantía para permitir que los buenos técnicos sigan sus instintos.

3.- Incentivos por logros. Para optimizar la productividad de un equipo de proyecto, se debe recompensar la iniciativa y los logros.

4.- Influencia y construcción de espíritu de equipo. Debe ser capaz de entender señales verbales y no verbales y reaccionar ante las necesidades de las personas, además mantener el control en situaciones de estrés.

I.2 Producto

Antes de poder planificar un proyecto, se deberían establecer los objetivos y el ámbito del producto, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión.

Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida. Un análisis detallado de los requisitos del software proporcionaría la información necesaria para las estimaciones, pero el análisis a menudo lleva semanas o meses. Aún peor, los requisitos pueden ser fluidos, cambiando regularmente a medida que progresa el proyecto.

Se tiene actividades principales para detectar lo requisitos de la elaboración del producto:

I.2.1 Ámbito del software

Se define respondiendo a las siguientes preguntas:

• Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qué limitaciones se imponen como resultado del contexto?

• Objetivos de información. ¿Qué objetos de datos visibles al cliente se obtienen del software? ¿Qué objetos de datos son requeridos de entrada?

• Función y rendimiento. ¿Qué función realiza el software para transformar la información de entrada en una salida? ¿Hay características de rendimiento especiales que abordar?

I.2.2 Descomposición del problema

La descomposición del problema, denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software.

La descomposición se aplica en dos áreas principales:

o la funcionalidad que debe entregarse y

o el proceso que se empleará para entregarlo.

Entre las características peculiares del producto están:

• la introducción de información a través de la voz así como del teclado;

• características extremadamente sofisticadas de «edición automática de copia»;

• capacidad de diseño de página;

• indexación

...