Tarea: Definir la organización y el personal del proyecto
Esta tarea es una introducción a la necesidad de determinar las necesidades de personal de un proyecto y cómo se debe organizar el personal del proyecto.
Objetivo
  • Definir una estructura organizativa del proyecto
  • Según los cálculos de esfuerzo, definir los requisitos de personal (en términos de números, tipos y grados de experiencia) de la próxima iteración (con una gran seguridad) y las siguientes (con menos seguridad) para permitir el inicio de acciones de adquisición de personal, si esto constituye un riesgo
Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional: Externa:
  • Ninguno
Salidas
Pasos
Definir la organización del proyecto
Objetivo Definir la estructura organizativa del proyecto en términos de posiciones, equipos, responsabilidades y jerarquía.  

La elección de la estructura organizativa del proyecto depende de las características del mismo y de restricciones externas como, por ejemplo, una política de organización existente. Por lo tanto, es difícil ser prescriptivo sobre estas estructuras, ya que lo que es eficaz (o incluso factible) dependerá mucho de las circunstancias. Los problemas que se deben solucionar se examinan en profundidad en  Directriz: Plan de desarrollo de software, donde también se presenta una estructura de proyecto por omisión que se puede adaptar a las necesidades específicas de un proyecto. La estructura por omisión también sugiere una correlación de roles (Rational Unified Process) con los puestos de la organización. La forma y el tamaño de la organización del proyecto variará en cada fase, y el plan de desarrollo de software, un documento vivo, se actualizará para reflejar estos cambios.

Definir requisitos de personal
Objetivo Definir los números, el tipo (habilidades, dominio), la experiencia y el calibre de personal que se necesitan para el proyecto 

A partir de los cálculos de esfuerzo del proyecto, la planificación deseada, la estructura organizativa elegida y la correlación de roles, el gestor de proyectos determina el perfil de personal (número de miembros de personal con el tiempo y conjunto de habilidades) necesario para el proyecto. El cálculo de esfuerzo de un proyecto no es independiente del tamaño, la experiencia, las habilidades y el calibre del equipo; con toda probabilidad, el gestor de proyectos tendrá que hacer suposiciones sobre la capacidad del personal, entre otras, cuando realice el cálculo de esfuerzo. En el Modelo de cálculo COCOMO (consulte Tarea: Planear fases e iteraciones), la capacidad del personal y su experiencia son de los principales controladores de esfuerzo. Por lo tanto, la selección de un esfuerzo total aceptable (ajustando los distintos controladores de esfuerzo COCOMO) y una planificación factible determinará el perfil de personal.

En algunos casos, el gestor de proyectos puede conocer por adelantado el número de miembros y las habilidades de personal disponibles.  En estos casos, con el tamaño y las habilidades de personal establecidos, sólo la planificación variará, suponiendo que el ámbito del proyecto permanece constante.

El gestor de proyectos también debe conocer las interrupciones provocadas por el aumento acelerado de niveles de personal y el posible efecto catastrófico en la productividad si se intentan reducciones radicales en la planificación, a la vez que aumenta significativamente el número de miembros de personal.

Buscar personal para las fases inicial y de elaboración

En la fase inicial, el objetivo está en definir y limitar el ámbito, y desarrollar un caso de negocio para el proyecto. Por lo tanto, el tamaño del equipo es bastante pequeño: un gestor de proyectos, un arquitecto de software y quizás un desarrollador o dos, especialmente en aquellos casos en los que se necesite un prototipo de prueba de concepto, para aclarar los requisitos o crear soporte para el producto.

En la fase de elaboración, el objetivo está en la arquitectura y el prototipo de arquitectura. Por lo tanto, las tareas de diseño al principio de la elaboración se centran en los aspectos de la arquitectura; se presta poca atención a los detalles de las clases y sus atributos que, aunque sí se identifican, no son importantes para la arquitectura. Durante estas iteraciones, la mayoría del esfuerzo proviene del equipo de arquitectura y un equipo de prototipos designado. Normalmente, el equipo de prototipos lo conforman los programadores con más experiencia. En este punto, tendrá un equipo de diseño muy pequeño que se centrará en las tecnologías y los mecanismos genéricos. El grupo de prueba se centrará en crear el entorno de prueba y probar los primeros guiones de uso.

Elija con mucho cuidado los miembros del equipo de arquitectura: no sólo deben poseer excelentes habilidades de análisis y diseño, sino cualidades de liderazgo. Para poder comunicar la arquitectura al equipo (de mayor tamaño) durante la fase de construcción, se recomienda distribuir los miembros del equipo de arquitectura entre los equipos de construcción. Los miembros del equipo de arquitectura también deben abarcar un amplio espectro de experiencia en ingeniería de software: diseño e implementación de software, ajuste del rendimiento, gestión de bases de datos, gestión de redes y gestión de configuraciones son los principales conjuntos de habilidades que deben estar representados en el equipo de arquitectura.

Buscar personal para la fase de construcción

La fase de construcción se centra en mantener la integridad de la arquitectura del sistema a la vez que se aumenta la funcionalidad del mismo. Para ello se necesita un perfeccionamiento de la arquitectura (de aquí, la "creación de líneas base" y no la "congelación" de la arquitectura después de la fase de elaboración) y un equipo de arquitectura que supervise a los diseñadores y sus diseños.

El equipo de arquitectura tendirá a distribuirse entre los equipos de desarrollo, actuando como líderes técnicos y coordinando los problemas entre grupos con los otros líderes técnicos. Los equipos de construcción deben ser equipos de funciones cruzadas, con experiencia en diseño y desarrollo, ya que son responsables del diseño y la implementación de la funcionalidad asignada. Normalmente, un equipo de construcción es responsable de uno o varios subsistemas con interfaces bien definidas; los cambios en estas interfaces o la adición de nuevos subsistemas provocarán cambios en la arquitectura, por lo que se deben considerar atentamente. Dentro del subsistema, el equipo tiene libertad relativa para crear diseños y realizar implementaciones según considere oportuno, pero es necesaria la comunicación entre equipos para garantizar que éstos no estén creando el mismo mecanismo en paralelo.

Normalmente, los equipos de construcción se organizan horizontalmente, del mismo modo que las capas. Un equipo debe ser responsable de las interfaces de bases de datos, o la infraestructura de comunicaciones, mientras que otros se centran en la funcionalidad de la aplicación. Según esto, los equipos de las capas "superiores" necesitan más experiencia en el dominio de problemas, el diseño de interfaces de usuario y la interacción con sistemas externos. Los equipos de las capas "inferiores" están más familiarizados con la tecnología de implementación. La composición de estos equipos debe reflejar las distintas demandas de habilidades.

Buscar personal para las tareas de prueba

La primera pregunta en una prueba es cuántas pruebas formales debe realizar. Y, a continuación, cuántas puede permitirse para cumplir los objetivos de calidad y mantener unos límites razonables de coste y planificación. Es excepcional que los proyectos dispongan de presupuesto para realizar todo tipo de pruebas. Normalmente, los proyectos deben seleccionar el nivel de prueba que pueden permitirse. Recuerde que cada especificación de prueba debe inspeccionarse y mantenerse. Es contraproducente para la moral del equipo del proyecto tener planes de creación de muchas especificaciones de prueba, pero no poder implementarlos por falta de tiempo.

Cree un equipo de prueba específico. Al menos una persona del equipo de prueba debe provenir del equipo de captura de requisitos. El equipo de prueba es responsable de la

  • Prueba de caja negra. Prueba de los guiones de uso desde fuera del sistema, basándose en el flujo de suceso del guión de uso (consulte Producto de trabajo: Guión de uso).
  • Prueba de caja blanca. Prueba del envío real de mensajes en el guión de uso basándose en las vistas de secuencia de los casos de ejemplo.
  • Prueba del sistema. Prueba de tensión del sistema para revelar su verdadera naturaleza.

Recuerde que realizar una prueba no es sólo ejecutarla; también incluye la preparación del entorno de prueba y la escritura e inspección de las especificaciones de la prueba.

Un grupo independiente debe probar los guiones de uso y el sistema completo. Deben ejecutar las pruebas y escribir también los informes de las pruebas. El trabajo de probar los guiones de uso se debe organizar de forma que haya una persona responsable de probar cada guión de uso.

Si no es posible que un grupo independiente pruebe los guiones de uso, por ejemplo, en un proyecto pequeño, asegúrese al menos de que la persona responsable del diseño del guión de uso no sea la encargada de probarlo.

En los proyectos medianos y grandes, se deben utilizar pruebas de regresión automatizadas. El equipo de prueba necesitará algunos programadores para dar soporte a esta posibilidad. Esto es incluso más importante durante un desarrollo iterativo, donde no desea invertir demasiado esfuerzo en volver a ejecutar los mismos conjuntos de aplicaciones de prueba una y otra vez.

Buscar personal para la fase de transición

En la fase de transición, el trabajo de desarrollo ha finalizado. Se ha realizado la prueba de versión beta y se ha preparado un release final. Si se ha realizado un buen trabajo en la construcción, el equipo del proyecto puede empezar a reducir de nuevo su tamaño, disminuyendo el número de desarrolladores y verificadores. La composición del equipo cambiará a favor de formadores y expertos en logística de infraestructura, que son los responsables de desplegar el producto en la comunidad de usuarios.

El arquitecto de software, o el equipo de arquitectura, trabaja en "modalidad de seguimiento": ayudan a clasificar los informes de problemas, priorizan las propuestas de cambio y modifican los pedidos, para asegurarse de que los problemas no se solucionan por conveniencia utilizando un método que dañe la arquitectura. Las tareas de diseño disminuyen durante la fase de transición y están limitadas a la corrección de problemas o a la introducción de mejoras de última hora.



Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir