Comprender los objetivos de la iteración
Objetivo:
|
Obtener una primera idea del ámbito y de los objetivos del plan de iteración.
|
Examine el plan de iteración e identifique el ámbito y los objetivos del plan.
Es útil complementar este análisis con charlas informales con el personal clave del proyecto, como por ejemplo el
gestor de proyectos, el arquitecto de software y el patrocinador del cliente; estas reuniones a menudo pondrán de
manifiesto los problemas de forma más explícita que en el plan documentado. Asistir a reuniones de comienzo también
proporciona información útil.
|
Investigar opciones para el ámbito del esfuerzo de valoración
Objetivo:
|
Comprender las expectativas de los interesados para el ámbito del esfuerzo de evaluación.
|
La misión es el objetivo principal que guía el esfuerzo de prueba durante un determinado período de tiempo. Los
recursos de prueba normalmente son limitados y, por tanto, el reto es encontrar un equilibrio entre las restricciones
de los recursos de prueba existentes y las necesidades de validación de calidad de la tarea de desarrollo de software.
Obtenga una primera idea a nivel estratégico de las expectativas del equipo de desarrollo de software. Debe centrarse
principalmente en las expectativas del gestor de proyectos, del arquitecto de software y de los principales analistas
de sistemas.
|
Presentar opciones a los interesados
Objetivo:
|
Obtener información y comentarios de los interesados para los objetivos y el ámbito del esfuerzo de
prueba.
|
No es una práctica muy útil considerar los objetivos y el ámbito de forma aislada del resto del equipo del proyecto.
RUP aboga por la propiedad de equipo de la calidad del producto y, como tal, se deben incluir los interesados
pertinentes del resto del equipo del proyecto a la hora de decidir qué prueba es importante. Debe considerar los
miembros del equipo que desempeñan los siguientes roles como interesados importantes: gestor de proyectos, arquitecto,
analista de sistemas, integrador.
En algunos casos, el formato de la presentación deberá ser formal, con los interesados convocados como comité de
revisión y habiendo realizado previamente una preparación significativa. En otros casos, un almuerzo informal puede ser
apropiado o una entrevista individual con cada interesado. Cada enfoque tiene sus puntos buenos y malos: elija el
formato que se mejor se adapte a sus necesidades en el contexto del entorno del proyecto actual.
|
Formular sentencias de misión
Objetivo:
|
Identificar claramente la esencia del enfoque de la prueba para la iteración actual.
|
Las sentencias de misión son útiles a la hora de proporcionar orientación a un equipo, especialmente en situaciones en
las que el equipo se encuentra delante de muchas opciones posibles. Los equipos de prueba sin una misión de evaluación
a menudo consideran que simplemente "realizan pruebas": esto proporciona poca orientación cuando deben tomarse
decisiones difíciles en relación con la mejor opción para las pruebas ante restricciones de tiempo o recursos. Una
sentencia de misión extrae la esencia del objetivo de trabajo actual y proporciona un "mantra" para mantener el equipo
dentro del camino correcto.
Formule una sentencia de misión que pueda utilizar el equipo de prueba. Procure que no sea demasiado compleja ni
incorpore demasiadas ideas conflictivas: las mejores sentencias de misión son simples, cortas y amables, y en la
mayoría de situaciones donde debe tomarse una decisión entre diferentes opciones posibles, la misión dejará claro qué
elección debe realizar el equipo.
A continuación se indican algunas ideas para las sentencias de misión que se pueden adoptar para una determinada
iteración:
-
buscar el máximo posible de errores
-
buscar rápidamente problemas importantes
-
valorar los riesgos de la calidad percibidos
-
aconsejar acerca de los riesgos de la calidad percibidos
-
aconsejar sobre la calidad percibida
-
certificar un estándar
-
verificar una especificación (requisitos, diseño o reclamaciones de producto)
-
satisfacer a los interesados
-
cumplir los mandatos del proceso
Al examinar esta lista, puede observar que muchas misiones se excluyen mutuamente. Por ejemplo, si mi misión es
"encontrar rápidamente problemas importantes", probablemente no podré "verificar una especificación": lograr una misión
con éxito a menudo excluye otras misiones posibles y requiere un enfoque distinto para las pruebas de soporte.
Los equipos de prueba que intentan llevar a cabo demasiadas misiones de evaluación a menudo se meten en un lío, ya que
encuentran conflictos continuos en su trabajo. Recuerde también que recomendamos elegir o reconsiderar la misión de
evaluación en cada iteración: es normal que la misión cambie con el tiempo en función del contexto del esfuerzo de
trabajo actual.
|
Identificar entregables de prueba
Objetivo:
|
Determinar el valor que se recibirá del esfuerzo del trabajo de prueba.
|
Algunos productos de trabajo son entregables importantes para uno o varios interesados: otros productos de trabajo son
componentes necesarios del esfuerzo de prueba y aunque son importantes para el equipo de prueba, tienen poco interés
para esos mismos interesados.
Identifique el conjunto mínimo de entregables útiles para el esfuerzo de prueba. No liste todos los productos de
trabajo; liste únicamente aquellos que proporcionan un beneficio directo y tangible a un interesado y aquellos mediante
los cuales desea medir el éxito del esfuerzo de prueba. Es posible que necesite ajustar la lista inicial para adaptarse
a las necesidades de los interesados, pero deberá adoptar un rol proactivo incentivando que los entregables se
mantengan útiles y manejables.
|
Obtener el acuerdo de los interesados
Objetivo:
|
Negociar con todos los interesados para obtener un acuerdo mutuo sobre la misión más apropiada para la
iteración.
|
De manera similar al paso descrito más arriba Presentar opciones a los interesados, debe
obtener el acuerdo de esos mismos interesados que la misión de evaluación y sus aspectos de soporte asociados son
apropiados para la iteración.
Una vez más, considere el formato apropiado para presentar la misión y obtener las aprobaciones necesarias. Elija el
formato que se mejor se adapte a sus necesidades en el contexto del entorno del proyecto actual.
|
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.
|
|