Determinar qué software se implementará
Objetivo:
|
Entender los principales entregables del equipo de desarrollo en la próxima planificación.
|
Utilizando el plan de iteración y otras fuentes disponibles, identifique los elementos de software individuales que el
equipo de desarrollo tiene la intención de producir para la próxima iteración. En los casos en que la tarea de
desarrollo se distribuye a equipos de diversas ubicaciones, es posible que deba analizar los planes de desarrollo
directamente con cada equipo. Compruebe si algún desarrollo está subcontratado y utilice cualquier canal que tenga a su
disposición para recopilar detalles sobre la tarea de desarrollo de los subcontratistas.
Además del software nuevo, observe también los cambios realizados en la infraestructura y en los componentes
compartidos. Estos cambios pueden afectar a otros elementos de software dependientes o asociados producidos en ciclos
de desarrollo anteriores, haciendo que sea necesario probar el efecto de estos cambios sobre dichos elementos. Por
motivos similares, debe identificar los cambios y adiciones en componentes de terceros que la tarea de desarrollo tiene
la intención de utilizar. Entre ellos se incluyen los componentes compartidos, las bibliotecas de códigos base o
comunes, objetos gráficos de la GUI, programas de utilidad de permanencia, etc. Revise la arquitectura de software para
determinar qué mecanismos están siendo utilizados y que pueden verse afectados por los cambios en los componentes de
terceros.
|
Identificar elementos del sistema candidatos que deben someterse a prueba
Objetivo:
|
Identificar elementos de destino en los que se debe ejercer el esfuerzo de prueba.
|
Para cada motivador de prueba identificado, examine la lista de elementos de software que deben entregarse como parte
de este ciclo de desarrollo. Confeccione una lista inicial que excluya los elementos que no pueden justificarse como
útiles en términos de satisfacer los motivadores de prueba. Recuerde incluir el software disponible comercialmente así
como el que debe desarrollar directamente el equipo de desarrollo del proyecto.
También deberá tener en cuenta el impacto que los diversos entornos de despliegue de destino tendrán sobre los
elementos que deben probarse. La lista de elementos del sistema candidatos debe ampliarse de modo que incluya tanto el
software que se está desarrollando como los elementos candidatos del entorno de destino. Estos elementos incluyen
dispositivos de hardware, software de controlador de dispositivo, sistemas operativos, software de red y
comunicaciones, componentes de software base de terceros (p.ej., software de cliente de correo electrónico, navegadores
de Internet, etc.). También incluyen varias configuraciones y valores relacionados con las posibles combinaciones de
todos estos elementos.
En los casos en los que haya identificado entornos de despliegue de destino importantes, debe considerar la posibilidad
de registrar esta información creando o actualizando una o varias configuraciones de entorno de prueba esquematizadas;
el esquema debe incluir un nombre, una descripción breve y enumerar los requisitos o características principales de la
configuración. No emplee mucho en estos esquemas; la lista de requisitos y características se detallará posteriormente
en la Tarea: Definir las configuraciones del entorno de prueba.
|
Perfeccionar la lista de candidatos de elementos de destino
Objetivo:
|
Eliminar destinos innecesarios del plan de trabajo del esfuerzo de prueba y añadir al mismo los elementos
que falten.
|
Teniendo en cuenta la misión de evaluación y el ámbito del esfuerzo de prueba que se han acordado con los interesados
de la evaluación, examine la lista de elementos de destino e identifique los elementos que no satisfacen la misión de
evaluación y que están claramente fuera del ámbito del esfuerzo de prueba.
Como comprobación inversa, examine de nuevo los elementos de manera crítica y pregúntese si la lista perfeccionada de
elementos de destino cumplirá la misión de evaluación y el ámbito del esfuerzo de prueba. Es posible que sea necesario
añadir elementos adicionales a la lista de elementos de destino para garantizar el ámbito apropiado y la capacidad de
cumplir la misión de evaluación.
|
Definir la lista de elementos de destino.
Objetivo:
|
Comunicar las decisiones tomadas acerca de los elementos del destino de la prueba para el próximo
trabajo.
|
Ahora que ha decidido los elementos del destino de la prueba, debe comunicar su elección al equipo de prueba y a otros
interesados en el esfuerzo de prueba. Posiblemente el método más habitual es documentar las decisiones sobre los
elementos de destino en el plan de prueba de iteración.
Una alternativa es simplemente registrar esta información en alguna forma de tabla u hoja de cálculo y utilizarla para
llevar a cabo la asignación de trabajos y responsabilidades. Durante la implementación y ejecución de la prueba,
verificadores individuales utilizarán esta información para tomar decisiones tácticas sobre las pruebas específicas que
deben implementarse y sobre qué resultados de la prueba deben capturarse en relación con estos elementos de destino.
|
Evaluar y verificar los resultados
Objetivo:
|
Verificar que la tarea se ha realizado correctamente y que los productos de trabajo resultantes son
aceptables.
|
Ahora que ha terminado el trabajo, se recomienda verificar que el trabajo tenía el valor suficiente y que no sólo ha
gastado una gran cantidad de papel. Debe evaluar si el trabajo tiene la calidad correcta y si es lo suficientemente
completo para que resulte útil a aquellos miembros del equipo que vayan a utilizarlo posteriormente como entrada de su
trabajo. Siempre que sea posible, utilice las listas de comprobación proporcionadas en RUP para verificar que la
calidad y la completitud son lo "suficientemente buenas".
Fomente la participación en la revisión del trabajo interno por parte de las personas que realizan tareas basadas en
los resultados de su trabajo. Hágalo mientras todavía tenga tiempo para realizar acciones para solucionar sus
problemas. También debe evaluar su trabajo en los productos de trabajo de entrada clave para asegurarse de que los ha
representado de forma precisa y suficiente. Para ello, es muy útil hacer que el autor del producto de trabajo de
entrada revise su trabajo.
Recuerde que RUP es un proceso de entrega iterativo y que en muchos casos los productos de trabajo evolucionan con el
tiempo. Como tal, no siempre es necesario (y a veces es contraproducente) formar completamente un producto de trabajo
que sólo se utilizará de forma parcial o que no se utilizará en absoluto en un trabajo inmediatamente posterior. Esto
se debe a que existe una alta probabilidad de que la situación alrededor del producto de trabajo cambie (y que las
suposiciones realizadas cuando se creó el producto de trabajo se demuestre que son incorrectas) antes de que se utilice
el producto, lo que da como resultado un esfuerzo inútil y una revisión costosa. Asimismo, evite la trampa de invertir
demasiados ciclos en la presentación en detrimento del valor del contenido. En entornos de proyecto en los que la
presentación tenga importancia y un gran valor económico como entregable del proyecto, puede utilizar un recurso
administrativo para ejecutar tareas de presentación.
|
|