Directriz: Plan de desarrollo de software
Esta directriz proporciona ayuda para crear un plan de desarrollo de software para un ciclo de desarrollo iterativo. También discute como una secuencia de revisión de cascada tradicional se alinea con el enfoque iterativo.
Relaciones
Descripción principal

Determinación de la longitud de cada iteración

Hemos definido una iteración como un miniproyecto bastante completo, que pasa por todas las disciplinas principales y resulta en la mayoría de casos en un sistema ejecutable, aunque incompleto: un release. Aunque el ciclo [editar, compilar, probar, depurar] suena como una iteración, no es lo que queremos decir aquí. Las compilaciones diarias o semanales que integran cada vez más, y prueban más y más elementos del sistema, también pueden parecer una iteración, pero sólo es una porción de una iteración, tal como se utiliza aquí este término.

Una iteración empieza con la planificación y los requisitos, y acaba con un release, interno o externo.

La rapidez de la iteración depende principalmente del tamaño de la organización de desarrollo.

Por ejemplo:

  • Cinco personas pueden realizar la planificación el lunes por la mañana, comer juntos cada día para supervisar el progreso, reasignar las tareas, empezar una compilación el jueves, y completar la iteración el viernes por la tarde.
  • Pero esto será difícil de alcanzar con 20 personas. Se tardará más tiempo distribuyendo el trabajo, sincronizando los subgrupos, integrando, etc. Una iteración puede tardar tres o cuatro semanas.
  • Con 40 personas, ya se tarda una semana para que el "influjo nervioso vaya del cerebro a las extremidades". Tiene niveles intermediarios de gestión, la comprensión común del objetivo requerirá documentación más formal, más ceremonia. Tres meses es una duración de iteración más razonable.

Otros factores entran en juego: el grado de familiaridad de la organización con el enfoque iterativo, incluyendo el hecho de disponer de una organización estable y madura, el nivel de automatización que utiliza el equipo para gestionar el código (por ejemplo, CM distribuida), distribuir información (por ejemplo, web interna), pruebas automatizadas, etc.

Tenga en cuenta que también hay unos ciertos gastos generales fijados en una iteración, en la planificación, sincronización, análisis de los resultados, etc.

Así que, por un lado, convencido de las tremendas ventajas del enfoque repetitivo, puede que esté tentado de repetir furiosamente, aunque los límites humanos de la organización ralentizarán su fervor.

Algunos datos empíricos:

SLOC Número de desarrolladores Duración de una iteración
10.000 5 1 semana
50.000 15 1 mes
500.000 45 6 meses
1.000.000 100 1 año

  • Iteraciones de más de 6 meses probablemente necesitan tener hitos intermedios incorporados para mantener el proyecto al día. Considere reducir el ámbito de la iteración para reducir la longitud y garantizar un enfoque claro.
  • Iteraciones de más de 12 meses crean su propio riesgo, ya que la iteración expande el ciclo económico anual. Un proyecto que no ha producido nada visible en los últimos 12 meses corre el riesgo de perder sus fondos.
  • Iteraciones de menos de 1 mes deben tener un ámbito definido cuidadosamente. Habitualmente, las iteraciones breves son más adecuadas para la fase de construcción, donde el grado de nueva funcionalidad que se debe incluir y el grado de novedad son bajos. Las iteraciones breves pueden tener poco o no tener análisis formal, y pueden simplemente mejorar incrementalmente una funcionalidad bien comprendida.
  • Todas las iteraciones no deben tener la misma longitud: su longitud variará de acuerdo con sus objetivos. Habitualmente, las iteraciones de elaboración serán más largas que las iteraciones de construcción. Dentro de una fase, las iteraciones tienen generalmente la misma longitud (simplifica la planificación).

Una vez que tenga una idea del número de iteraciones del plan sin detallar, deberá definir el contenido de cada iteración. También es una buena idea encontrar un nombre o un título para calificar el producto que tiene al final de cada iteración, para ayudar a obtener un enfoque más claro.

Ejemplo Iteraciones para una conmutación de teléfono privado

  • Iteración 1: llamada local.
  • Iteración 2: añadir llamadas externas y gestión del suscriptor.
  • Iteración 3: añadir correo por voz y teleconferencias.

Determinación del número de iteraciones

Un proyecto muy simple puede tener sólo una iteración por fase:

  • Una iteración en la fase inicial, produce quizás un prototipo de prueba de concepto o una maqueta de la interfaz de usuario o ninguna iteración, en los casos para el ejemplo de un ciclo de evolución.
  • Una iteración en la fase de elaboración para producir un prototipo arquitectónico.
  • Una iteración en la fase de construcción para compilar el producto (a un release "beta").
  • Una iteración en transición para finalizar el producto (release completo del producto).

Para un proyecto más sustancial, en el ciclo de desarrollo inicial la norma sería:

  • Una iteración en la fase inicial (posiblemente produciendo un prototipo).
  • Dos iteraciones en la fase de elaboración; una para un prototipo arquitectónico, y uno para la línea base de la arquitectura.
  • Dos iteraciones en la fase de construcción para exponer un sistema parcial y madurarlo.
  • Una iteración en la fase de transición para ir de las capacidades operativas iniciales al release completo del producto.

Para un proyecto grande, con muchos aspectos desconocidos, nuevas tecnologías, etc., se puede producir:

  • una iteración adicional en la fase inicial, para permitir la creación de más prototipos.
  • una iteración adicional en la fase de elaboración, para permitir la exploración de diferentes tecnologías.
  • una iteración adicional en la fase de construcción debido al tamaño total del producto.
  • una iteración adicional en la fase de transición, para permitir la información de retorno operativo.

Durante el ciclo de desarrollo, tenemos:

  • Baja: 3 iteraciones [0,1,1,1]
  • Típica: 6 [1, 2, 2, 1]
  • Alta: 9 [1, 3, 3, 2]
  • Muy alta: 10 [2, 3, 3, 2]

Así pues, en general, planee tener entre tres y diez iteraciones. Tenga en cuenta, sin embargo, que los límites superior e inferior connotan circunstancias inusuales, así que la mayoría de desarrollos utilizarán entre seis y ocho iteraciones.

Son posibles muchas variaciones dependiendo de los riesgos, el tamaño y la complejidad:

  • Si el producto está previsto para un dominio totalmente nuevo, puede ser necesario añadir algunas iteraciones en la fase inicial para consolidar los conceptos, mostrar varias maquetas a una sección cruzada de clientes o usuarios, o construir una respuesta sólida para solicitar una propuesta.
  • Si se debe desarrollar una nueva arquitectura, o hay una gran cantidad de modelado de caso de uso, o aparecen riesgos apremiantes, debe planear tener dos o tres iteraciones en la fase de elaboración.
  • Si el producto es grande y complejo, y se desarrolla durante un largo periodo, debe planear tener tres o más iteraciones en la fase de construcción.
  • Debe planear tener varias iteraciones en la fase de transición si, al tener que minimizar el tiempo de comercialización, debe proporcionar el producto con un conjunto reducido de funcionalidades, o si considera que necesitará más adaptaciones pequeñas para la base del usuario final tras un periodo de uso.

Alineación de la secuencia de revisión de cascada tradicional con el enfoque iterativo

La secuencia de revisión por omisión para un proyecto de ciclo de vida en cascada tiene una revisión única principal de productos de trabajo importantes, por ejemplo:

  • Revisión de requisitos del sistema (SRR), a la terminación de la especificación del sistema;
  • Revisión de especificación de software (SSR), a la terminación de la especificación de requisitos de software;
  • revisión de diseño preliminar (PDR), a la terminación de las secciones de diseño arquitectónico de la descripción de diseño de software;
  • Revisión de diseño importante (CDR), a la terminación de las secciones de diseño detalladas de la descripción de diseño de software.

En Rational Unified Process, las partes de los productos de trabajo equivalentes se revisan a medida que se completan en cada iteración, pero los hitos principales (y, por lo tanto, las revisiones) se alinean con la terminación de las fases, el inicio, la elaboración, la construcción y la transición. Un gestor de proyectos que desee adoptar RUP tendrá que encontrar un modo de reconciliar este conflicto aparente, debido a obligaciones contractuales. Idealmente, el gestor de proyectos debe convencer al cliente de que el enfoque basado en fases e iteración en realidad proporciona una visibilidad real superior en el progreso del proyecto, reduce riesgos, para que no exista necesidad de SRR, SSR, etc. Sin embargo, esto no siempre es posible, y el gestor de proyectos debe planificar estas revisiones en los puntos apropiados. Es posible, en RUP, ubicar los puntos en que estos productos de trabajo importantes (en realidad, sus equivalentes en RUP) están prácticamente completados, aunque esto no siempre se alinea a la perfección con fases o iteraciones.

Esto se realiza considerando que el esfuerzo relativo que se gastará en requisitos, diseño, y similares será aproximadamente el mismo en RUP que en el ciclo de vida de cascada (ideal) - pero que el esfuerzo se distribuirá diferentemente. El resultado es el siguiente:

Para eficacia, el gestor de proyectos, consultando con el cliente, debe intentar combinar estas tres revisiones con las revisiones RUP prescritas. Esto es claramente posible para SRR y PDR, se pueden combinar con Objetivos del ciclo de vida Revisar y Arquitectura del ciclo de vida Revisar, respectivamente.

Organización de proyecto

Al igual que el proceso de software recibe influencias de las características del proyecto, la organización del proyecto también las recibe. La estructura por omisión presentada aquí (consulte la figura siguiente) tiene que adaptarse para que refleje los efectos o factores como los que se listan:

  • El contexto empresarial
  • El tamaño de la tarea de desarrollo de software
  • El grado de novedad
  • Tipo de aplicación
  • El proceso de desarrollo actual
  • Factores organizativos
  • Complejidad técnica y de gestión

Estos son factores distintivos clave al analizar cómo, en conjunto, la organización debe adoptar un nuevo proceso de desarrollo. Aquí examinaremos su efecto en la elección de la estructura del proyecto. La figura siguiente presenta una organización de proyecto por omisión, mostrando como se asignan las responsabilidades a la estructura del equipo.

Diagrama sensible al contexto que muestra como se asignan las responsabilidades a los miembros del equipo.

Figura que muestra la organización por omisión del proyecto. Tenga en cuenta que la antigüedad o la autoridad no son significativas en la ordenación de los roles.

Esta figura es un punto de partida para considerar cómo se deben correlacionar los roles de nivel de proyecto y las responsabilidades con una estructura de equipos. La figura también sirve para enfatizar qué roles (mostrados en los recuadros amarillos) no son personas, sino "sombreros" que una persona (o equipo) se puede poner en el proyecto. Por este motivo, varios roles (el gestor de proyectos, por ejemplo) aparecen más de una vez. Esto indica que, en algún momento, el comportamiento del gestor de proyectos, tal como se define en RUP, puede aparecer en más de un equipo. Por ejemplo, en un proyecto más grande, la tarea de preparar un informe de estado basado en una estructura detallada de trabajo se puede delegar a una persona del equipo de administración. Sin embargo, esta es una responsabilidad que RUP asigna al rol denominado gestor de proyectos.

En un proyecto pequeño, es probable que una persona nombrada gestor de proyectos efectúe todas las tareas del rol denominado gestor de proyectos, en cuyo caso el equipo de administración se combina con el equipo de gestión de software. La selección de la estructura del equipo estará influenciada por la naturaleza y el tamaño del proyecto, pero debería matizarse con algunas normas de sentido común:

  • los equipos pequeños suelen ser más productivos; sin embargo, en grandes proyectos, esto debe equilibrarse contra la cantidad de interacción cruzada dentro del equipo
  • Las jerarquías profundas deben evitarse
  • el intervalo del control de cualquier gestor o líder de equipo debe limitarse a siete más o menos dos
  • la estructura de equipo del desarrollo de software debe dirigirla la arquitectura de software; una buena arquitectura, con cohesión elevada y bajo acoplamiento entre subsistemas, permitirá que los equipos trabajen con más eficacia en paralelo
  • las pruebas, diferentes de las pruebas de unidad, debe efectuarlas de forma ideal un equipo aparte del equipo de desarrollo. Tenga en cuenta, sin embargo, que esto no tendrá sentido económicamente en proyectos muy pequeños
  • la estructura debe permitir que todos los equipos y personas reciban autorizaciones y responsabilidades claramente definidas. Esto es especialmente importante si la jerarquía supera tres niveles. Los gestores y líderes de equipo en el medio de tales estructuras deben comprender qué se requiere de ellos para equilibrar las tareas técnicas y de gestión.
  • la estructura debe dar soporte a las capacidades, experiencia y motivaciones del personal: por ejemplo, si un único equipo debe efectuar el análisis, diseño e implementación, sin intermediarios, necesitarán todas las competencias necesarias. Los analistas capacitados no son necesariamente buenos implementadores;
  • las estructuras del equipo no deben ser rígidas: las personas migrarán entre equipos durante el tiempo del vida del proyecto y las responsabilidades de los equipos cambiarán a medida que el énfasis del proyecto cambie de fase a fase.

Los fundamentos de la organización por omisión se discuten largamente en [ROY98]. Concretamente, la asignación de todas las responsabilidades de despliegue para el equipo de valoración de software reconoce que, de todos los equipos del proyecto de desarrollo, el equipo de valoración de software está más expuesto al software tal como lo verá el usuario.

Durante la vida de un proyecto, la organización evolucionará para proporcionar soporte a la estructura detallada de trabajo en el plan del proyecto. Esto se muestra en la figura siguiente, que se toma de [ROY98].

Diagrama que muestra la evolución del equipo durante el ciclo de vida del proyecto.

Esta evolución enfatiza un conjunto diferente de tareas en cada fase:

  • el equipo inicial: una organización centrada en la planificación, con soporte suficiente de los otros equipos para garantizar que los planes representan un consenso de todas las perspectivas;
  • el equipo de elaboración: una organización centrada en la arquitectura en que la orientación fuerza que el proyecto resida en el equipo de arquitectura de software y reciben soporte de los equipos de desarrollo de software y de valoración de software según sea necesario para alcanzar una línea base de arquitectura estable;
  • el equipo de construcción: una organización equilibrada en que la mayoría de tareas residen en los equipos de desarrollo de software y de valoración de software;
  • el equipo de transición: una organización centrada en el cliente en que la información de retorno de utilización orienta las tareas de despliegue.

La migración entre equipos durante esta evolución garantizará que el conocimiento y las capacidades se mantienen durante el proyecto. Por ejemplo, cuando la elaboración se ha completado, algunos miembros del equipo de arquitectura pueden dispersarse en los equipos de desarrollo, quizás para actuar como líderes de los equipos, o para desarrollar la 'visión' arquitectónica en el desarrollo. Más adelante, hacia el final de la fase de construcción, el enfoque cambia al equipo de valoración, y se desplaza personal del equipo de desarrollo al equipo de valoración. También es importante en este estadio, para evitar la pérdida de integridad arquitectónica en la base de la construcción, que la influencia del equipo de arquitectura no decaiga cuando se mueva el "centro de gravedad" de proyecto. Mover algunos miembros del equipo de arquitectura al equipo de valoración es un modo de hacerlo.