modelo requistos

Utilizando la Metodología RUP:: Desarrollo de un Sistema de Gestión::

MSc. Manuel Sánchez Chero [email protected]

Introducción Gestión del Proyecto Modelado del Negocio Requisitos Análisis/Diseño Implementación Prueba

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.

El propósito del modelo de requisito es comprender completamente el problema y sus implicaciones.



El propósito de éste documento es recoger, analizar y definir las necesidades y las características del sistema. El documento se centra en la funcionalidad requerida por los participantes en el proyecto y los usuarios finales.


Visión Glosario Casos de Usos Gestión de Requisitos

Introducción•Propósito•Alcance•Referencias

Posicionamiento•Oportunidad del Negocio

Descripción de los Participantes del Proyecto•Participantes en el Proyecto•Perfiles de usuarios

Descripción Global del Producto•Perspectivas•Costos y precios

RestriccionesPrecedencias y PrioridadesOtros Requisitos del ProductoRequisitos de Documentación Manual de Usuario Ayuda en Línea



Recoge todos y cada uno de los términos manejados a lo largo de todo el proyecto.



Introducción•Propósito•Alcance•Referencias•Organización del Glosario

Definiciones•Lista de Términos manejados a lo largo de todo el proyecto

Se trata de un diccionario informal de datos y definiciones de la nomenclatura que se maneja, de tal modo que se crea un estándar para todo el proyecto.





•Gestión de Ventas, incluyendo:•Procedimiento de venta de productos vía operadoras de teléfono.•Procedimiento de venta mediante la atención de comerciales a domicilio del cliente. •Procedimiento de venta mediante el sistema online, vía Web.

•Gestión de Almacenes, incluyendo:Gestión de nuevos pedidos.Reserva de stock para la preparación de pedidos.Gestión de Envíos.Gestión de Pedidos.Gestión de recibos.

•Departamento de Recursos Humanos. •Departamento de Marketing.•Departamento de Logística.•Contabilidad y Facturación.

La Empresa lleva a cabo la venta al por mayor de artículos deportivos a nivel internacional. La entrada en un mercado competitivo como en el que encuentra inmersa este firma conllevará una previsible adaptación a los nuevos sistemas de información y a la evolución tecnológica. Por ello, la empresa considera necesario el desarrollo de un nuevo sistema de gestión de los artículos deportivos que forman parte de sus catálogos.El proyecto debe proporcionar una propuesta para el desarrollo de todos los subsistemas implicados en la gestión de artículos deportivos. Estos subsistemas se pueden diferenciar en siete grandes bloques:





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.Para comprender los casos de uso de un sistema primero es necesario saber quienes son sus usuarios.

Por ejemplo, conducir un automóvil es distinto a arreglarlo, donde los usuarios también son distintos, el dueño del automóvil y el mecánico, respectivamente. Para ello se define el concepto de actor





Los actores son entidades distintas a los usuarios, en el sentido que los usuarios son las personas reales que utilizan el sistema, mientras que los actores representan un cierto papel que una persona real puede jugar. Utilizando terminología orientada a objetos, se considera al actor como una clase de usuario, mientras que los usuarios se consideran como objetos o instancias de esa clase.

Los actores modelan cualquier entidad externa que necesite intercambiar información con el sistema. Los actores no están restringidos a ser personas físicas, pudiendo representar otros sistemas externos al actual. Lo esencial es que los actores representen entidades externas al sistema. Además, cada uno de estos actores podrá ejecutar una o más tareas del sistema.





Para especificar los actores de un sistema, se dibuja un diagrama correspondiente a la delimitación del sistema, la cual representa al sistema como una “caja negra” y a los diferentes actores como entidades externas a ésta, como se muestra en la figura.





Volviendo a la distinción entre actor y persona, una misma persona puede jugar el papel del actor Usuario cuando hace reservas y además puede trabajar para el sistema de reservaciones, por ejemplo como Operador, correspondiente a otro actor no mostrado en nuestro ejemplo.

Delimitación del sistema de reservaciones de vuelo.





El actor Usuario se considera un actor primario, ya que el sistema se construye pensando en sus usuarios, mientras que Base de Datos de Reservas y Base de Datos de Registro son ambos actores secundarios, ya que si no existieran usuarios no habría necesidad del sistema.

Delimitación del sistema de reservaciones de vuelo.

Actor Abstracto

ActorConcreto





Caso de Uso, se define la funcionalidad propia del sistema por medio de los casos de uso. Utilizando terminología orientada a objetos, cada caso de uso define una clase o forma particular de usar el sistema mientras que cada ejecución del caso de uso se puede ver como una instancia del caso de uso, o sea, un objeto, con estado y comportamiento. Cada caso de uso constituye un flujo completo de eventos especificando la interacción que toma lugar entre el actor y el sistema.

El actor primario es encargado de dar inicio a esta interacción, mientras que los casos de uso son instanciados como respuesta al evento anterior.





En el sistema de reservaciones de vuelos utilizamos los actores ya identificados como punto de partida. Dado que el Usuario es el actor primario se comienza con él. El sistema tiene que poder dar ciertos servicios al usuario, como consultas y reservas. De aquí podemos definir nuestros casos de uso principales, Consultar Información y Hacer Reservación.





Cuando diferentes actores juegan roles similares ellos pueden heredar de un actor abstracto común, como se muestra mediante el actor abstracto Base de Datos en el ejemplo de la figura siguiente. El resto de los actores se conoce como actores concretos, utilizando terminología similar a aquella de herencia.





En la descripción del problema se menciona que para poder utilizar el sistema el usuario debe estar registrado, por lo cual agregamos un caso de uso Registrar Usuario. Por otro lado, se debe incluir la Base de Datos de Reservas, y la Base de Datos de Registro ya que son actores secundarios necesarios. Estos tres casos de uso se muestran en la figura.





La extensión especifica cómo un caso de uso puede insertarse en otro para extender la funcionalidad del anterior. El caso de uso donde se va a insertar la nueva funcionalidad debe ser un flujo completo, por lo cual éste es independiente del caso de uso a ser insertado. De esta manera, el caso de uso inicial no requiere consideraciones adicionales al caso de uso a ser insertado, únicamente especificando su punto de inserción.





Inclusión. Es una relación adicional entre casos de uso es la inclusión. A diferencia de una extensión, la inclusión se define como una sección de un caso de uso que es parte obligatoria del caso de uso básico. El caso de uso donde se va a insertar la funcionalidad depende del caso de uso a ser insertado. Se etiqueta la relación con “incluye” (“include”). Por ejemplo, en el Sistema de Reservaciones de Vuelos, el caso de uso de Consultar Información incluye el caso de uso Validar Usuario como se muestra en la figura.





Generalización. Es una relación adicional entre casos de uso es la generalización la cual apoya la reutilización de los casos de uso. Mediante la relación de generalización es necesario describir las partes similares una sola vez en lugar de repetirlas para todos los casos de uso con comportamiento común.

Se conoce a los casos de uso que se extraen como casos de uso abstractos, ya que no serán instanciados independientemente





Los casos de uso adicionales en este diagrama son la extensión de Registrar Tarjeta y Pagar Reservación. Este último caso de uso es interesante por que extiende Hacer Reservación e incluye Registrar Tarjeta, ambos requisitos para poder comprar un boleto con el sistema. Además de la inclusión anterior, también se incluyen los casos de uso de Validar Usuario y Ofrecer Servicios en los casos de uso básicos: Registrar Usuario, Consultar Información y Hacer Reservación.





Ventas Almacén Envíos Logística Marketing Contabilidad RR.HH

A continuación se presentan los diagramas de casos de uso planteados para cada uno de los subsistemas definidos para la empresa.






DescripciónEl Jefe de Ventas o el Ingeniero de Logística inicia el caso de uso. El sistema le muestra una pantalla donde puede crear diversas estadísticas sobre conceptos relacionados con la empresa. Por ejemplo, ventas por sección, ventas de los representantes, pedidos realizados a las operadoras, beneficio de la empresa, etc. Una vez creada una estadística puede ser impresa o guardada en el sistema para su consulta posterior.

CU-CONTROL DE ESTADISTICA






Flujo de Eventos

1. La pantalla muestra una lista con las posibles estadísticas a crear.2. El actor selecciona una de ellas y pulsa el botón crear.3. El sistema le muestra una pantalla donde puede asignar regiones,

almacenes o trabajadores afectados por la estadística.4. Pulsando siguiente aparecerá una ventana donde se mostrarán

parámetros de control y rangos de selección de forma que pueda amoldar la estadística a sus preferencias.

5. Pulsando siguiente aparecerán los resultados que podrá guardar o imprimir.a) Si pulsa el botón guardar el sistema le permitirá grabar los

resultados en el disco duro u otro soporte de almacenamiento.b) Si pulsa el botón imprimir se enviará a la impresora los resultados.







Precondiciones

1. El actor ha realizado correctamente el registro en el sistema.2. El actor ha seleccionado el botón de “Control Estadísticas” de su interfaz

gráfica.






stakeholders Actores Características del Software

Caso de Usos

Clase

Stakeholders: Los representantes de los usuarios y portavoces de las necesidades de la empresa son los stakeholders. En este proyecto solamente se ha tratado con un stakeholder como representante de los usuarios y necesidades de la empresa, sin embargo se han dividido representativamente según los distintos departamentos. La matriz de atributos de los stakeholders es la siguiente:






Caso de Usos

Clase

Stakeholders: La matriz de trazabilidad de los stakeholders relaciona a éstos con las características de software de tal manera que se puede conocer qué stakeholder propuso qué característica.






Caso de Usos

Clase

Actores: Se define este requerimiento para listar los usuarios potenciales del sistema, en este proyecto se han definido los siguientes actores: Ingeniero de Logística, Jefe de Almacén, Técnico de Almacén, Jefe de Ventas, Representante de Ventas, Contable, Empleado de Marketing, Cliente Online, Operadora, Encargado de Transporte, Jefe de Recursos Humanos y Empleado de Recursos Humanos.La Matriz de Atributos para los actores es la siguiente:






Caso de Usos

Clase

Actores: La matriz de trazabilidad de los actores relaciona a éstos con los casos de uso de tal manera que se puede conocer qué actor utiliza qué caso de uso.






Caso de Usos

Clase

Características de Software: Las características software son las necesidades de los usuarios propuestas por los stakeholders de la empresa, son los requisitos que debe cumplir el sistema para satisfacer las necesidades de los trabajadores y de la empresa.Las características definidas son las que aparecen en la matriz de atributos, siendo las indicadas como subcaracterísticas las derivadas según una clasificación jerárquicas.






Caso de Usos

Clase

Características de Software: La matriz de trazabilidad de las características de software relaciona a éstas con los casos de uso de tal manera que se puede conocer qué caso de uso deriva de qué característica.






Caso de Usos

Clase






Caso de Usos

Clase

Casos de Uso: derivados de las características software, son el resultado del análisis de las necesidades de los usuarios, cuyas especificaciones están recogidas en el paquete Especificaciones de Casos de Uso definido en Requisite Pro.






Caso de Usos

Clase

Casos de Uso: derivados de las características software, son el resultado del análisis de las necesidades de los usuarios, cyas especificaciones están recogidas en el paquete Especificaciones de Casos de Uso definido en Requisite Pro.






Caso de Usos

Clase

Casos de Uso: derivados de las características software, son el resultado del análisis de las necesidades de los usuarios, cuyas especificaciones están recogidas en el paquete Especificaciones de Casos de Uso definido en Requisite Pro.






Caso de Usos

Clase






Caso de Usos

Clase

Clases: Las clases son requerimientos derivados de los casos de uso como necesidad de representación del modelo de datos.La matriz de atributos de las clases es la siguiente:



Pre

gunt

as

[---------- Expositor ----------]MSc. Manuel Sánchez Chero

[email protected]

modelo requistos

Business