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