Actividad: Gestionar cambios de requisitos |
|
Objetivo
La finalidad de esta actividad es evaluar el impacto de los cambios solicitados en los requisitos, y gestionar el impacto
en sentido descendente de los cambios cuya implementación se ha aprobado. |
Relaciones
Descripción
Esta actividad aborda los aspectos siguientes:
Los cambios en los requisitos tienen un impacto natural en los artefactos en sentido descendente (por ejemplo, los
productos de trabajo de análisis y diseño, los productos de trabajo de prueba, los artefactos de despliegue, etc.). La
rastreabilidad identificada y documentada durante la gestión las dependencias define explícitamente las relaciones
entre los requisitos y los otros productos de trabajo. Estas relaciones son la clave para comprender el impacto de los
cambios de requisitos.
|
Propiedades
Condicionado por sucesos |  |
Varias apariciones |  |
Continuo |  |
Opcional |  |
Planeado |  |
Se puede repetir |  |
Personal
Implique a todo el equipo
(interesados:
representantes de los clientes, expertos en el dominio y otros).
Incluya como
revisor
técnico a cualquier miembro del equipo del proyecto de software cuyo trabajo se
vea afectado por el cambio. Gestione los recursos de revisión con eficacia. No incluya a la totalidad del equipo a menos que pueda garantizar que añade valor
al proyecto.
El equipo completo debe incorporar un buen conocimiento del dominio del problema, las
dificultades técnicas del proyecto, así como habilidades en la gestión de requisitos y en
el modelo
de caso de uso .
|
Utilización
Instrucciones de utilización |
Esta actividad debe efectuarse siempre que se perfeccionen los requisitos.
Deben realizarse revisiones regulares, junto con actualizaciones a los atributos y dependencias de requisitos, siempre
que se actualicen los requisitos.
Es recomendable que organice una revisión del Modelo de
caso de uso por iteración en las fases inicial y de elaboración, donde revise el trabajo en curso.
Inicialmente, esto lo efectúan y lo aprueban los usuarios antes de desarrollar cualquiera de los Casos de uso de forma detallada, y es un objetivo muy importante para
que los recursos no se utilicen para desarrollar casos de uso incorrectos. Al final de la fase de elaboración, debería
organizar una revisión detallada del modelo de caso de uso . Recuerde que al final de la fase de elaboración, debería
tener un modelo de caso de uso , y posiblemente un modelo de dominio que represente el Glosario, que está completado al 80 %. También debería organizar una
revisión del modelo de caso de uso por iteración en las fases de construcción y de transición cuando se perfeccione el
modelo de caso de uso . La revisión debe concentrarse en la parte del modelo de caso de uso que se está desarrollando
para la iteración.
|
Factores clave
El equipo de desarrollo principal debe llevar a cabo varias rondas de revisión interna: ensayos para eliminar las
incoherencias innecesarias antes de que su trabajo reciba una inspección y una revisión más formal por parte de todo el
equipo.
Debe dividir el material de forma que el equipo no revise todo a la vez. Una reunión de revisión no debe llevar más de
un día. Por ejemplo, puede llevar a cabo revisiones por separado de la interfaz de usuario y de los casos de ejemplo de
comportamiento, o podría revisar todos los artefactos de requisitos relacionados con un subsistema determinado.
Otra consideración importante es el seguimiento del historial de requisitos. Al capturar la naturaleza y los
fundamentos de los cambios de requisitos, los revisores reciben
la información necesaria para responder a los cambios de forma adecuada.
|
© Copyright IBM Corp. 1987, 2006. Reservados todos los derechos.
|
|