Tarea: Desarrollar el plan de iteración
En esta tarea se describe cómo componer un plan de iteración mediante la definición de un ámbito, criterios de evaluación y actividades, y la asignación de responsabilidades a la iteración.
Objetivo

Desarrollar un plan de iteración formado por:

  • una estructura de desglose de trabajo detallada de la tarea y las asignaciones de responsabilidad
  • objetivos y entregables dentro de la iteración
  • criterios de evaluación de la iteración
Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional: Externa:
  • Ninguno
Salidas
Descripción principal

La iteración es un conjunto de tareas ajustadas en el tiempo que se centran estrechamente en producir un ejecutable. Para todas las iteraciones, excepto la última iteración de transición, es un producto intermedio, producido para centrar la atención en mitigar el riesgo y dirigir el proyecto a una entrega satisfactoria. Al centrarse en un entregable ejecutable, fuerza una integración prácticamente continua y permite al proyecto atender a los riesgos técnicos en la fase inicial, a la vez que se reducen los riesgos de los asistentes.

La iteración implica una determinada cantidad de revisión (de los productos de trabajo existentes), así como un cambio de actitud en la revisión. En resumen, se necesita una determinada cantidad de revisión para entregar un producto de calidad: mediante la creación de productos intermedios y la evaluación de la idoneidad de la arquitectura del producto al principio y regularmente, la calidad del producto final aumenta, a la vez que los cambios son menos costosos y más fáciles de realizar.

Pasos
Determinar el ámbito de iteración
Objetivo Seleccionar un conjunto de guiones de uso o casos de ejemplo que se deben tener en cuenta durante la iteración.
Seleccionar un conjunto de requisitos no funcionales que se deben manejar durante la iteración.  
Directrices: Plan de iteración 

El ámbito de una iteración se basa en cuatro factores:

  • los riesgos máximos del proyecto
  • la funcionalidad necesaria del sistema
  • el tiempo asignado a la iteración del plan de proyecto
  • la fase y sus objetivos específicos (Consulte Concepto: Fase)

En la planificación inicial de una iteración, se selecciona suficiente trabajo para cubrir el tiempo planificado previamente para la iteración; aunque el gestor de proyectos tiene permitida una mayor flexibilidad para responder a las restricciones de recursos y otras consideraciones tácticas durante el desarrollo del plan de iteración. Obviamente, el trabajo planificado para la iteración anterior que no se haya completado (porque el ámbito de la iteración anterior se ha reducido para cumplir la planificación) tendrá normalmente una mayor prioridad.

El ámbito del trabajo también debe basarse en un enfoque sensible al nivel de personal máximo que se puede aplicar para completarlo durante la iteración. Por ejemplo, normalmente no se puede duplicar el trabajo completado en una iteración duplicando el personal que se le aplica, aunque dichos recursos estén disponibles. La cantidad aproximada de personal que se puede aplicar de forma eficaz viene determinada por el tamaño de software y la arquitectura general, y se puede determinar mediante modelos de cálculo como, por ejemplo, COCOMO II (consulte [BOE00]).

A continuación, la ejecución de una iteración se gestiona mediante límites de tiempo; esto es, el ámbito y la calidad (en términos de defectos descubiertos no rectificados) se gestiona activamente para cumplir la fecha final.

En la fase de elaboración :

Existen tres controladores principales para definir los objetivos de una iteración en elaboración:

  • Riesgo
  • Gravedad
  • Cobertura

El principal controlador para definir los objetivos de iteración son los riesgos. Debe mitigar o retirar los riesgos tan pronto como pueda. Este es casi siempre el caso en la fase de elaboración, donde la mayoría de los riesgos se deben mitigar, pero puede continuar siendo un elemento clave en la construcción ya que algunos riesgos permanecen altos o se descubren nuevos riesgos. Como el objetivo de la fase de elaboración es crear una línea base de la arquitectura, se deben tener en cuenta otras consideraciones como, por ejemplo, asegurarse de que la arquitectura engloba todos los aspectos del software que se va a desplegar (cobertura). Esto es importante, ya que la arquitectura se utilizará en la planificación adicional: organización del equipo, cálculo del código que se va a desarrollar, etc.

Por último, aunque centrarse en los riesgos es importante, debe recordar siempre cuáles son las principales misiones del sistema; la solución de todos los problemas graves es buena, pero no se debe hacer en detrimento de la funcionalidad central: asegúrese de que las funciones y los servicios críticos del sistema estén cubiertos (gravedad), aunque no se perciba ningún riesgo asociado con ellos.

En la lista de riesgos, para los riesgos más graves, identifique algún caso de ejemplo en un guión de uso que obligue al equipo de desarrollo a "confrontar" el riesgo.

Ejemplos

  • si existe un riesgo de integración como, por ejemplo, "el trabajo correcto de la base de datos D con OS Y", asegúrese de incluir un caso de ejemplo que implique alguna interacción de la base de datos, aunque sea muy modesta.
  • si existe un riesgo de rendimiento como, por ejemplo, "el tiempo para calcular la trayectoria del avión", asegúrese de tener un caso de ejemplo que incluya este cálculo, al menos para el guión más obvio y frecuente.

En cuanto a la gravedad, asegúrese de que se incluyan las funciones o servicios fundamentales proporcionados por el sistema. Seleccione un caso de ejemplo del guión de uso que represente la forma más común y frecuente del servicio o la característica que ofrece el sistema. El Documento de arquitectura de software se utiliza para dirigir este esfuerzo y proporciona un conjunto priorizado de guiones de uso o subflujos de guiones de uso, seleccionados por el Arquitecto de software para reflejar los guiones de uso o los casos de ejemplo significativos para la arquitectura.

Ejemplo

  • para un conmutador telefónico, la llamada normal de estación a estación es el requisito obvio para una de las primeras iteraciones. Es mucho más importante que solucione esto que las modalidades de anomalías complejas en la configuración del operador del subsistema de manejo de errores.

En cuanto a la cobertura, al final de la fase de elaboración, incluya casos de ejemplo dedicados a áreas que sabe que van a necesitar desarrollo, aunque no sean graves ni arriesgadas.

A menudo, resulta económico crear casos de ejemplo largos, de extremo a extremo, que engloben varios problemas a la vez.

El riesgo es crear casos de ejemplo demasiado "gruesos", es decir, intentar cubrir demasiados aspectos y variantes diferentes, y demasiados casos de error (consulte Plan de iteración)

Asimismo, en la fase de elaboración, recuerde que algunos de los riesgos pueden ser de naturaleza más humana o programática (cultura del equipo, formación, selección de herramientas, nuevas técnicas, etc.) y que pasar por la iteración permite mitigar estos riesgos.

Ejemplos

  1. Crear un registro de subscriptores en una estación de trabajo cliente para almacenarlo en la base de datos del servidor, que incluya un diálogo de usuario, pero sin incluir todos los campos, suponiendo que no se ha detectado ningún error.
    Combina funciones críticas con riesgos de integración (base de datos y software de comunicación) y problemas de integración (tratar con dos plataformas diferentes). Asimismo obliga a los diseñadores a familiarizarse con la nueva herramienta de diseño de GUI. Por último, produce un prototipo que se puede demostrar al usuario para obtener información de retorno.
  2. Asegurarse de que se pueden crear 20.000 suscriptores, y que el acceso a uno no tarda más de 200 milisegundos.
    Soluciona algunas necesidades clave de rendimiento (volumen o datos, y tiempo de respuesta) que pueden afectar gravemente a la arquitectura si no se cumplen.
  3. Deshacer un cambio de dirección de suscriptor.
    Una característica sencilla que obliga a los diseñadores a pensar un diseño de todas las funciones "deshacer". Por su parte, esto puede provocar alguna retrotracción en los usuarios sobre qué se puede deshacer con un coste razonable.
  4. Completar todos los guiones de uso relativos a la gestión de la cadena de suministros.
    El objetivo de la fase de elaboración es completar la captura de requisitos, quizás también conjunto a conjunto.

En la fase de construcción :

Cuando el proyecto pasa a la fase de construcción, los riesgos continúan siendo un controlador clave, sobre todo cuando se descubren nuevos riesgos inesperados. Pero la completitud del guión de uso también empieza a ser un controlador. Las iteraciones se pueden planificar característica a característica, intentando completar algunas de las más importantes al principio para que se puedan probar ampliamente durante más de una iteración. Al final de la construcción, el principal objetivo será la solidez de los guiones de uso completos.

Ejemplo

  1. Implementar todas las variantes de envío de llamada, incluidas las erróneas.
    Este es un conjunto de características relacionadas. Puede que una de ellas ya se haya implementado durante la fase de elaboración y que sirva como prototipo para el resto del desarrollo.
  2. Completar todas las características del operador telefónico, excepto el servicio nocturno.
    Otro conjunto de características.
  3. Alcanzar 5.000 transacciones por hora en una configuración de 2 sistemas.
    Esto puede configurar el rendimiento necesario relativo a lo que se ha alcanzado realmente en la iteración anterior (sólo 2.357/hora)
  4. Integrar la nueva versión del Sistema de información geográfica.
    Este puede ser un cambio arquitectónico modesto necesario para un problema descubierto previamente.
  5. Solucionar todos los defectos de nivel 1 y nivel 2
    Soluciona los defectos descubiertos durante la prueba en la iteración anterior que no se han resuelto inmediatamente, sino que se han diferido.

En la fase de transición :

El principal objetivo es finalizar la generación del producto. Los objetivos de una iteración se establecen en términos de qué errores se solucionan, y qué mejoras de rendimiento o utilización se incluyen. Si se tienen que eliminar (o inhabilitar) características para llegar a tiempo al final de la construcción (objetivo de IOC o "beta"), pueden quedar sin completar o activar si no ponen en peligro lo que se ha conseguido hasta ahora.

Ejemplos

  1. Solucionar todos los problemas de gravedad 1 descubiertos en los sitios de cliente beta.
    Un objetivo en términos de calidad; puede estar relacionado con la credibilidad en el mercado.
  2. Eliminar todos los bloqueos de arranque debidos a datos que no coinciden.
    Otro objetivo expresado en términos de calidad.
  3. Alcanzar 2.000 transacciones por minuto.
    Ajuste de rendimiento, incluida alguna optimización: cambio de estructura de datos, antememoria y algoritmos más inteligentes.
  4. Reducir el número de recuadros de diálogo diferentes en un 30%.
    Mejorar la utilización mediante la reducción del desorden visual
  5. Producir versiones en alemán y japonés.
    La versión beta sólo se ha producido para los clientes en inglés debido a la falta de tiempo y para reducir la revisión.
Definir criterios de evaluación de iteraciones

Cada iteración resulta en un release ejecutable. El release no es generalmente de calidad de producción (excepto en la iteración de transición final), pero se puede evaluar.

Evaluación de iteraciones iniciales

La iteración de la fase inicial generalmente se centra en proporcionar el concepto del producto y crear el soporte necesario para aprobar los fondos del proyecto. Como resultado, el release de iteración generalmente es un prototipo funcional de prueba de concepto que no incluye el código de implementación real debajo de una fina capa de interfaz de usuario. Los criterios de evaluación están orientados a la aceptación del usuario y a medidas cualitativas.

En algunas circunstancias, se deben superar obstáculos técnicos clave en la fase inicial antes de que se proporcionen los fondos del producto; si es así, los criterios de evaluación deben reflejarlo.

Evaluación de iteraciones de elaboración

Las iteraciones de elaboración se centran en la creación de una arquitectura estable. Como resultado, los criterios de evaluación de elaboración se deben centrar en la valoración de la estabilidad de la arquitectura. Las medidas que se pueden utilizar son:

  • Estabilidad de la interfaz (o ruptura)
  • El índice de cambio en la arquitectura (comparado con una línea base de arquitectura)
  • rendimiento de la funcionalidad clave

El objetivo clave es garantizar que los cambios realizados durante la fase de construcción no se extiendan por el sistema, provocando un exceso de revisiones.

Evaluación de iteraciones de construcción y transición

Las iteraciones de construcción y transición se miden con dimensiones de gestión de cambios y pruebas de software tradicionales como, por ejemplo, la ruptura, la densidad de defectos y los índices de descubrimiento de anomalías. El objetivo en estas iteraciones es encontrar errores para poder solucionarlos.

Los errores se descubren de varias formas: inspecciones y revisiones de código, pruebas funcionales, pruebas de rendimiento y pruebas de carga. Cada técnica está orientada al descubrimiento de un determinado conjunto de defectos, y cada una tiene su sitio. Los detalles de estas técnicas se describen en la disciplina Prueba de Rational Unified Process.



Definir actividades de iteración

Según los objetivos de la iteración, se debe seleccionar el conjunto de tareas a realizar durante la iteración. Normalmente, cada iteración realizará un pase parcial por todas las tareas del ciclo vital de software:

  • Se seleccionan guiones de uso y casos de ejemplo que ejecutan la funcionalidad necesaria
  • Se investiga y se documenta el comportamiento del guión de uso (o el caso de ejemplo)
  • Se analiza el comportamiento y se asigna entre los subsistemas y las clases que proporcionan el comportamiento necesario
  • Se diseñan las clases y los subsistemas, implementados y de unidad probada
  • El sistema se integra y se prueba en conjunto
  • Para los releases externos (alfa, beta y disponibilidad general), el producto se empaqueta en un formato con capacidad de release y se realiza la transición a este entorno de usuario.

El grado con el que se ejecutan estas tareas varía con la iteración y la fase del proyecto. Las disciplinas individuales (Requisitos, Análisis y Diseño, Prueba, etc.) definen las tareas genéricas, que a su vez se adaptan a la organización durante la configuración del proceso.

Identificar los productos de trabajo afectados y las tareas implicadas

Una vez seleccionados y esbozados brevemente los casos de ejemplo o los guiones de uso avanzados que se van a desarrollar (más los defectos que se van a solucionar), debe averiguar cuáles son los productos de trabajo que se verán afectados:

  • ¿Qué clases se tienen que revisar?
  • ¿Qué subsistemas se ven afectados o cuáles se han creado?
  • ¿Qué interfaces se van a modificar probablemente?
  • ¿Qué documentos se tienen que actualizar?

A continuación, extraiga de las disciplinas de proceso las tareas implicadas y colóquelas en la planificación. Algunas tareas se ejecutan una vez por iteración (incluir ejemplo) y otras se tienen que ejecutar una vez por clase, por guión de uso o por subsistema (ejemplo). Conecte las tareas con sus dependencias obvias y asígneles un esfuerzo estimado. La mayoría de las tareas descritas para el proceso son lo suficientemente pequeñas para que las ejecute una persona, o un grupo muy pequeño de personas, en pocas horas o en pocos días.

Es probable que descubra que no tiene tiempo suficiente en la iteración para lograr todos los objetivos. En lugar de ampliar la iteración (ampliando el tiempo de entrega final o reduciendo el número de iteraciones), reduzca las ambiciones de la iteración. Dependiendo de la fase en la que se encuentre, simplifique los casos de ejemplo, elimine o inhabilite características, etc.

Asignar responsabilidades

Una vez definido el conjunto de tareas para la iteración, se deben asignar a los miembros de los equipos del proyecto. Dependiendo de los recursos de personal disponibles y del ámbito de la iteración, la tarea la puede realizar una única persona o un equipo. Las revisiones y las inspecciones son, de manera inherente, tareas de equipo. Otra tareas, como la autoría de los guiones de uso o el diseño y la implementación de las clases, son inherentemente solitarias (excepto en el caso de que un miembro joven del equipo trabaje en equipo con un miembro con experiencia que actúe como mentor).

En general, cada producto de trabajo debe ser responsabilidad de una única persona, aunque el trabajo lo realice un equipo:

  • Guiones de uso
  • Subsistemas
  • Clases
  • Pruebas y planes de prueba
  • etc.

Sin un único punto de contacto, garantizar la coherencia es una tarea prácticamente imposible.



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

La planificación de proyectos es donde el gestor de proyectos crea una instancia (y posteriormente gestiona la ejecución) de un proceso de entrega específico (consulte Producto de trabajo: Proceso de desarrollo) para el proyecto. A menudo se denomina actuación logística.

Un proceso del que se ha "creado una instancia" es un plan de proyecto/iteración/actividad que se puede aplicar (incluye actividades reales y productos de trabajo para un proyecto real.  Para crear una instancia de un proceso de entrega, se importa un Proceso de entrega desde Rational Method Composer a Rational Portfolio Manager (RPM) y, a continuación, se realiza el trabajo de creación de la instancia duplicando las actividades y las tareas que están establecidas en isRepeatable o hasMultipleOccurences, creando productos de trabajo reales, asignando recursos reales a los roles, etc. 

Más información