Negociación de Requisitos
En un contexto de la ingeniería de requisitos, las tareas de
inicio, obtención y elaboración determinan los requisitos con el suficiente
detalle como para emprender los pasos subsecuentes de la ingeniería del
software. Desgraciadamente, esto sucede muy rara vez. En realidad, el cliente y
el desarrollador entran en un proceso de negociación, en el cual se le debe de
pedir al cliente un balance de la funcionalidad el rendimiento y otras
características del sistema o producto frente al costo y el tiempo de
colocación en el mercado. El objetivo de esta negociación es desarrollar un
plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que
refleja las restricciones del mundo real (por ejemplo, tiempo, gente, presupuesto)
a las que está sometido el equipo de software.
Las mejores negociaciones son aquellas que buscan un
resultado del tipo “ganar-ganar” Esto es, el cliente ganar obtener el sistema o
producto que satisface la mayoría de sus necesidades, y el equipo de software
gana al trabajo con presupuestos y límites de tiempo realistas y alcanzables.
Bohen define un conjunto de actividades de negociación en el inicio de cada
iteración del proceso del software. En el lugar de la actividad sencilla de
comunicación con el cliente, se definen las siguientes actividades:
1.- identificación de los interesados clave en el sistema de subsistema.
2.- Determinación de las “Condiciones ganadoras” de los interesados.
3.- Negociación de las condiciones ganadoras de los interesados para reconciliarlas en conjunto de condiciones del tipo ganar-ganar para todos los involucrados (incluido el equipo de software).
La conclusión exitosa de estos pasos iniciales asegura un
resultado del tipo ganar-ganar, el cual se convierte en el criterio clave para
continuar con las actividades subsecuentes de la ingeniería de software.
Validación de Requisitos
Al crear cada elemento del modelo de análisis, a este se
examina para conocer su consistencia, sus omisiones y ambigüedades, A los
requisitos que representa el modelo del cliente les da jerarquía y se aseguran
en paquetes de requisitos que se implementan como incrementos de software y se
le entregan. Una revisión del modelo de análisis se enfoca en las siguientes
preguntas:¿Cada requisito es consistente con el objetivo general del sistema/Producto?
¿Todos los requisitos han sido específicos con el grado apropiado de abstracción? Esto es, ¿Algunos requisitos proporcionan un grado de detalle técnico que sea inapropiado en esta etapa?
¿Cada requisito tiene una atribución? Esto es, ¿Existe una fuente (por lo general, especifica, individual) determinada para cada requisito?
¿Algunos requisitos entran en conflicto con otros?
¿Cada requisito se puede probar una vez que este haya sido implementado?
¿El modelo de requisitos refleja de manera apropiada la información, la función y el comportamiento del sistema que será construido?
¿El modelo de requisitos se ha sometido a “Participación” para que exponga en forma progresiva información más detallada acerca del sistema?
Estas y otras preguntas deben realizarse y contestarse para asegurar que el modelo de requisitos es un reflejo exacto de las necesidades del cliente y que proporciona una base sólida para el diseño.
Resumen
Antes de que el diseño y la construcción de un sistema
basado en computadora puedan comenzar, es necesario entender los requisitos,
Esto se logra realizando una seria de tareas de ingeniería de requisitos, la
cual se lleva a cabo durante las actividades de comunicación con el cliente y
modelado que han sido definidas para el proceso genérico del software. Los
miembros del equipo de software realizan siete funciones distintas dentro de la
ingeniería de requisitos: inicio, obtención, elaboración, negociación, especificación,
validación y gestión.
Al inicio del proyecto el desarrollador y el cliente (Así
como otros interesados) establecen los requisitos básicos del problema, definen
las restricciones predominantes del proyecto y especifican las características
y funciones más importantes que deben estar presentes en el sistema para que
este alcance sus objetivos. Esta información es expandida y refinada durante la
obtención, una actividad para la recopilación de requisitos que emplea
reuniones que encabeza un moderador facilitadas, que QFG y el desarrollo de
escenarios de uso.
La elaboración posteríos expande los requisitos hacia un modelo
de análisis; es decir, una colección de elementos del modelo basados en
escenarios, en actividades y en clases, de comportamiento y orientados al
flujo. En la creación de estos elementos se puede utilizar una variedad de
notificaciones de modelado. El modelo puede referirse a patrones de análisis,
características del dominio del problema que son recurrentes a traces de
diferentes aplicaciones.
Cuando se identifican los requisitos y se crea el modelo de
análisis, el equipo de software el cliente y otros interesados en el proyecto negocia
la prioridad, disponibilidad y costo relativo de cada requisito. El objetivo de
esta negociación es desarrollar un plan de proyecto realista. Además, casa de requisito
y el modelo de análisis como un todo se validan contrastándolos con las
necesidades del cliente para asegurar que se construirá el sistema correcto.
No hay comentarios.:
Publicar un comentario