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
Roles | Principal:
| Adicional:
| Asistencia:
|
Entradas | Obligatoria:
| Opcional:
| Externa:
|
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.
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
-
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.
-
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.
-
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.
-
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.
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
-
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.
-
Completar todas las características del operador telefónico, excepto el servicio nocturno.
Otro conjunto de características.
-
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)
-
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.
-
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.
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
-
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.
-
Eliminar todos los bloqueos de arranque debidos a datos que no coinciden.
Otro objetivo expresado en términos de calidad.
-
Alcanzar 2.000 transacciones por minuto.
Ajuste de rendimiento, incluida alguna optimización: cambio de estructura de datos, antememoria y
algoritmos más inteligentes.
-
Reducir el número de recuadros de diálogo diferentes en un 30%.
Mejorar la utilización mediante la reducción del desorden visual
-
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
Instrucciones de la herramienta |
|
© Copyright IBM Corp. 1987, 2006. Reservados todos los derechos.
|
|