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.
En la metodología de Objectory, el modelo de requisitos
consiste de tres modelos principales, visualmenterepresentado por un diagrama
de tres dimensiones .
Los tres ejes de modelado del modelo de requisitos.
· El
modelo de comportamiento, basado directamente en el modelo de casos
de uso, especifica la funcionalidadque ofrece el sistema desde el punto de
vista del usuario. Este modelo utiliza dos conceptos claves: actores pararepresentar
los distintos papeles que los usuarios pueden jugar con el sistema, ycasos
de uso para representarqué pueden hacer los actores con respecto al
sistema
· El
modelo de presentación o modelo de interfaces o borde 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.
Descripción
del Problema
La descripción del problema es una descripción muy preliminar de
necesidades que sirve únicamente como punto de inicio para comprender los
requisitos del sistema. Se trata aquí de simular una descripción preparada por
un cliente la cual debe evolucionar por medio del modelo de requisitos para
lograr la especificación final del sistema a desarrollarse. La descripción del
problema debe ser una descripción de necesidades y no una propuesta para una
solución. La descripción inicial puede ser incompleta e informal. No hay razón
para esperar que la descripción inicial del problema, preparada sin un análisis
completo, sea correcta.
Modelo de
Casos de Uso
El modelo de casos de uso describe un sistema en
término de sus distintas formas de utilización, cada uno de estas formas es
conocida como un caso de uso. Cada caso de uso o flujo se compone
de una secuencia de eventos iniciada por el usuario. Dado que los casos de uso
describen el sistema a desarrollarse, cambios en los requisitos significarán
cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un
automóvil sería la secuencia de eventos desde que el conductor entra en el
coche encendiendo el motor hasta llegar a su destino final. Por lo tanto, para
comprender los casos de uso de un sistema primero es necesario saber quiénes
son sus usuarios
 |
| Mapa 2.3 |
No hay comentarios:
Publicar un comentario