El modelo de requisitos tiene como objetivo delimitar el
sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del
usuario. Este modelo puede funcionar como un contrato entre el desarrollador y
el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente
desea según la percepción del desarrollador. Por lo tanto, es esencial que los
clientes puedan comprender este modelo.
El modelo de requisitos es el primer modelo a
desarrollarse, sirviendo de base para la formación de todos los demás modelos
en el desarrollo de software. En general, el cualquier cambio en la
funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a
este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa
en la metodología Objectory (Jacobson et al. 1992), basada
principalmente en el modelo de casos de uso.
Actualmente esta metodología es parte del Proceso
Unificado de Rational (RUP). El modelo de casos de uso y el propio modelo
de requisitos son la base para los demás modelos.
·
Requisitos: El modelo de casos de uso sirve para expresar el modelo
de requisitos, el cual se desarrolla en cooperación con otros modelos como se
verá más adelante.
·
Análisis: La funcionalidad especificada por el modelo de casos de
uso se estructura en el modelo de análisis, que es estable con respecto a
cambios, siendo un modelo lógico independiente del ambiente de implementación.
·
Diseño: La funcionalidad de los casos de uso ya estructurada
por el análisis es realizada por el modelo de diseño, adaptándose al ambiente
de implementación real y refinándose aún más.
·
Implementación: Los casos de uso son implementados mediante el código
fuente en el modelo de implementación.
·
Pruebas: Los casos de uso son probados a través de las pruebas
de componentes y pruebas de integración.
·
Documentación: El modelo de casos de uso debe ser documentado a lo
largo de las diversas actividades, dando lugar a distintos documentos como los
manuales de usuario, manuales de administración, etc.
El propósito del modelo de requisitos es comprender
completamente el problema y sus implicaciones. Todos los modelos no solamente
se verifican contra el modelo de requisitos, sino que también se desarrollan
directamente de él. El modelo de requisitos sirve también como base para el
desarrollo de las instrucciones operacionales y los manuales ya que todo lo que
el sistema deba hacer se describe aquí desde la perspectiva del usuario. El modelo
de requisitos no es un proceso mecánico, el analista debe interactuar
constantemente con el cliente para completar la información faltante, y así
clarificar ambigüedades e inconsistencias. El analista debe separar entre los
requisitos verdaderos y las decisiones relacionadas con el diseño e
implementación. Se debe indicar cuales aspectos son obligatorios y cuales son
opcionales para evitar restringir la flexibilidad de la implementación. Durante
el diseño se debe extender el modelo de requisitos con especificaciones de
rendimiento y protocolos de interacción con sistemas externos, al igual que
provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se
puede incluir aspectos de diseño, como el uso de lenguajes de programación
particulares.
En la metodología de Objectory, el modelo de
requisitos consiste de tres modelos principales.
·
El modelo de comportamiento, basado directamente en el modelo de casos de uso,
especifica la funcionalidad que ofrece el
sistema desde el punto de vista del usuario. Este modelo utiliza dos conceptos
claves: actores para representar los
distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso para representar qué pueden hacer los actores con respecto al sistema
·
El modelo de presentación o modelo de interfaces, especifica
cómo interactúa el sistema con actores externos al ejecutar los casos de uso,
en particular, en los sistemas de información ricos en interacción con el usuario,
especifica cómo se verán visualmente las interfaces gráficas y que funcionalidad
ofrecerá cada una de ellas.
·
El modelo de información o modelo del dominio
del problema especifica los aspectos estructurales del sistema.
Este modelo conceptualiza el sistema según los
objetos que representan las entidades básicas de la aplicación.
Aunque en muchas metodologías se permite especificar la
funcionalidad completa del sistema utilizando el modelo del dominio del
problema, incluyendo operaciones formales sobre los objetos correspondientes a
un modelo de requisitos expresado sin casos de uso, el modelo del dominio del problema
será de mucha más ayuda como apoyo al modelo de casos de uso y no como una
entidad totalmente independiente.
Es importante resaltar que esta separación en tres ejes
de modelado independientes es la base para una mayor estabilidad en el
desarrollo del sistema, permitiendo minimizar los efectos de cada uno sobre los
otros dos.
Para ilustrar el modelo de requisitos y el desarrollo de
los modelos posteriores, utilizaremos el ejemplo del “Sistema de Reservaciones
de Vuelo” como se mencionó anteriormente. Para tal meta, mostraremos
inicialmente una descripción del problema. A partir de esta descripción
inicial se describirán los tres modelos básicos del modelo de requisitos.
No hay comentarios:
Publicar un comentario