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.
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.
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.
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.
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.
|