Resolver la solicitud de cambio
El rol Asignado efectúa el conjunto de tareas definidas en la sección adecuada del proceso de entrega,
como requisitos, análisis y diseño, implementación, producir materiales de soporte al usuario y prueba de diseño.Estas
tareas incluirán todas las tareas de prueba de unidad y revisión normal que se describen en el proceso de entrega
normal. Entonces, la CR se marcará como Resuelta. Esto significa que la resolución de esta CR se ha
completado y que está preparada para su verificación.
|
Verificar cambios en la compilación de prueba
Cuando el rol asignado (analista, desarrollador, verificador, escritor técnico, etc.) haya resuelto los
cambios, éstos se colocarán en una cola de prueba que se asignará a un verificador y se verificará en una
compilación de prueba del producto. Una CR que se haya verificado en una compilación de prueba está
preparada para incluirse en un release. Una CR que falla la prueba en una compilación de prueba o en una compilación
del release se pondrá en el estado La prueba ha fallado. El propietario se cambia automáticamente por el
rol que ha resuelto la CR.
|
Verificar cambios en la compilación del release
Una vez que los cambios resueltos se hayan verificado en una compilación de prueba del producto, la CR se
coloca en una cola del release para verificarse con una compilación del release del producto, producir notas del
release, etc. y cerrar la CR.
Una CR cerrada ya no requiere atención. Es el último estado que se puede asignar a una CR. El
administrador de revisión del CCB es el único que tiene la autoridad para cerrar una CR. Cuando se cierra
una CR, el emisor recibe una notificación por correo electrónico con la disposición final de la CR. Una CR puede estar
Cerrada: 1) después de que la resolución Verificada se haya validado en una compilación del
release, 2) cuando se confirme su estado de Rechazada o 3) cuando se confirme que es un
Duplicado de una CR existente. En el último caso, se informará al emisor de la CR duplicada y se añadirá
a dicha CR para notificaciones futuras (consulte las definiciones de los estados "Rechazada" y
"Duplicada" para obtener más detalles). Si el emisor desea rebatir un cierre, debe actualizar la CR y
volver a enviarla para que el CCB la revise.
Los estados típicos que puede pasar una solicitud de cambio se muestran en Gestión de
solicitudes de cambio.
|
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, le recomendamos 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 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.
|
|