2_ModeloRequistos

8/8/2019 2_ModeloRequistos

1/43

Utilizando la Metodologa RUP:: Desarrollo de un Sistema de Gest

MSc. Manuel Snchez Chero manuelsanchezchero@ya

Expositor

Introduccin Gestin del Proyecto Modelado del Negocio Requisitos Anlisis/Diseo Implementacin Prueba

MODELO DE REQUISITOS


2/43



Expositor


Tiene como objetivo delimitar el sistema y capturar la funcionalidad quedebe ofrecer desde la perspectiva del usuario. Este modelo puedefuncionar como un contrato entre el desarrollador y el cliente o usuariodel sistema, y por lo tanto proyecta lo que el cliente desea segn la

percepcin del desarrollador.

El propsito del modelo de requisito es comprender completamente elproblema y sus implicaciones.


3/43



Expositor

El propsito de ste documento esrecoger, analizar y definir lasnecesidades y las caractersticas delsistema.El documento se centra en lafuncionalidad requerida por losparticipantes en el proyecto y los

usuarios finales.


Visin Glosario Casos de Usos Gestin de Requisitos

IntroduccinPropsito AlcanceReferencias

PosicionamientoOportunidad del Negocio

Descripcin de los Participantes del ProyectoParticipantes en el ProyectoPerfiles de usuarios

Descripcin Global del ProductoPerspectivasCostos y precios

Restricciones

Precedencias y PrioridadesOtros Requisitos del ProductoRequisitos de Documentacin

Manual de UsuarioAyuda en Lnea


4/43



Expositor

Recoge todos y cada uno de los

trminos manejados a lo largo detodo el proyecto.



IntroduccinPropsito Alcance

ReferenciasOrganizacin del Glosario

DefinicionesLista de Trminos manejados a lo largo de todoel proyecto

Se trata de un diccionario informal de datos y definiciones de lanomenclatura que se maneja, de tal modo que se crea un estndar paratodo el proyecto.


5/43



Expositor



Gestin de Ventas, incluyendo:Procedimiento de venta de productos va operadoras de telfono.Procedimiento de venta mediante la atencin de comerciales a domicilio del cliente.Procedimiento de venta mediante el sistema online, va Web.

Gestin de Almacenes, incluyendo:

Gestin de nuevos pedidos.Reserva de stock para la preparacin de pedidos.Gestin de Envos.Gestin de Pedidos.Gestin de recibos.

Departamento de Recursos Humanos.Departamento de Marketing.Departamento de Logstica.Contabilidad y Facturacin.

La Empresa lleva a cabo la venta al por mayor de artculos deportivos a nivel internacional. Laentrada en un mercado competitivo como en el que encuentra inmersa este firma conllevar unaprevisible adaptacin a los nuevos sistemas de informacin y a la evolucin tecnolgica. Por ello,la empresa considera necesario el desarrollo de un nuevo sistema de gestin de los artculosdeportivos que forman parte de sus catlogos.El proyecto debe proporcionar una propuesta para el desarrollo de todos los subsistemas

implicados en la gestin de artculos deportivos. Estos subsistemas se pueden diferenciar ensiete grandes bloques:


6/43



Expositor



El modelo de casos de uso describe un sistema en trmino de sus distintasformas de utilizacin, cada uno de estas formas es conocida como un casode uso. Cada caso de uso o flujo se compone de una secuencia de eventosiniciada por el usuario.

Para comprender los casos de uso de un sistema primero es necesariosaber quienes son sus usuarios.

Por ejemplo, conducir un automvil es distinto a arreglarlo, donde losusuarios tambin son distintos, el dueo del automvil y el mecnico,respectivamente. Para ello se define el concepto de actor


7/43


MSc. Manuel Snchez Chero manuelsanchezchero@yaExpositor



Los actores son entidades distintas a los usuarios, en el sentido que losusuarios son las personas reales que utilizan el sistema, mientras que losactores representan un cierto papel que una persona real puede jugar.Utilizando terminologa orientada a objetos, se considera al actor como una

clase de usuario, mientras que los usuarios se consideran como objetos oinstancias de esa clase.

Los actores modelan cualquier entidad externa que necesite intercambiar informacin con el sistema. Los actores no estn restringidos a ser

personas fsicas, pudiendo representar otros sistemas externos al actual. Loesencial es que los actores representen entidades externas al sistema.Adems, cada uno de estos actores podr ejecutar una o ms tareas delsistema.


8/43





Para especificar los actores de un sistema, se dibuja un diagramacorrespondiente a la delimitacin del sistema, la cual representa al sistemacomo una caja negra y a los diferentes actores como entidades externas asta, como se muestra en la figura.


9/43





Volviendo a la distincin entre actor y persona, una misma persona puede jugar el papel del actor Usuario cuando hace reservas y adems puedetrabajar para el sistema de reservaciones, por ejemplo como Operador,correspondiente a otro actor no mostrado en nuestro ejemplo.

Delimitacin del sistema de reservaciones de vuelo.


10/43





El actor Usuario se considera un actor primario, ya que el sistema seconstruye pensando en sus usuarios, mientras que Base de Datos deReservas y Base de Datos de Registro son ambos actores secundarios, yaque si no existieran usuarios no habra necesidad del sistema.

Delimitacin del sistema de reservaciones de vuelo.

Actor Abstracto

Actor

Concreto


11/43





Caso de Uso, se define la funcionalidad propia del sistema por medio delos casos de uso. Utilizando terminologa orientada a objetos, cada caso deuso define una clase o forma particular de usar el sistema mientras quecada ejecucin del caso de uso se puede ver como una instancia del casode uso, o sea, un objeto, con estado y comportamiento. Cada caso de uso

constituye un flujo completo de eventos especificando la interaccin quetoma lugar entre el actor y el sistema.

El actor primario es encargado de dar inicio a esta interaccin, mientras quelos casos de uso son instanciados como respuesta al evento anterior .


12/43





En el sistema de reservaciones de vuelos utilizamos los actores yaidentificados como punto de partida. Dado que el Usuario es el actor primario se comienza con l. El sistema tiene que poder dar ciertosservicios al usuario, como consultas y reservas. De aqu podemos definir nuestros casos de uso principales, Consultar Informacin y Hacer

Reservacin.


13/43





Cuando diferentes actores juegan roles similares ellos pueden heredar deun actor abstracto comn, como se muestra mediante el actor abstractoBase de Datos en el ejemplo de la figura siguiente. El resto de los actoresse conoce como actores concretos, utilizando terminologa similar a aquellade herencia.


14/43





En la descripcin del problema se menciona que para poder utilizar elsistema el usuario debe estar registrado , por lo cual agregamos un caso deuso Registrar Usuario . Por otro lado, se debe incluir la Base de Datos deReservas, y la Base de Datos de Registro ya que son actores secundariosnecesarios. Estos tres casos de uso se muestran en la figura.


15/43





La extensin especifica cmo un caso de uso puede insertarse en otropara extender la funcionalidad del anterior. El caso de uso donde se va ainsertar la nueva funcionalidad debe ser un flujo completo, por lo cual stees independiente del caso de uso a ser insertado. De esta manera, el casode uso inicial no requiere consideraciones adicionales al caso de uso a ser

insertado, nicamente especificando su punto de insercin.


16/43





Inclusin. Es una relacin adicional entre casos de uso es la inclusin. Adiferencia de una extensin, la inclusin se define como una seccin de uncaso de uso que es parte obligatoria del caso de uso bsico. El caso de usodonde se va a insertar la funcionalidad depende del caso de uso a ser insertado. Se etiqueta la relacin con incluye (include). Por ejemplo, en el

Sistema de Reservaciones de Vuelos, el caso de uso de Consultar Informacin incluye el caso de uso Validar Usuario como se muestra en lafigura.


17/43





Generalizacin. Es una relacin adicional entre casos de uso es lageneralizacin la cual apoya la reutilizacin de los casos de uso. Mediantela relacin de generalizacin es necesario describir las partes similares unasola vez en lugar de repetirlas para todos los casos de uso concomportamiento comn.

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


18/43





Los casos de uso adicionales en este diagrama son la extensin de Registrar Tarjeta y Pagar Reservacin. Este ltimo caso de uso es interesante por que extiende Hacer Reservacin eincluye Registrar Tarjeta, ambos requisitos para poder comprar un boleto con el sistema.Adems de la inclusin anterior, tambin se incluyen los casos de uso de Validar Usuario yOfrecer Servicios en los casos de uso bsicos: Registrar Usuario, Consultar Informacin yHacer Reservacin.


19/43





Ventas Almacn Envos Logstica Marketing Contabilidad RR.HH

A continuacin se presentan los diagramas decasos de uso planteados para cada uno de lossubsistemas definidos para la empresa.


20/43







21/43






DescripcinEl Jefe de Ventas o el Ingeniero de Logstica inicia el caso de uso. Elsistema le muestra una pantalla donde puede crear diversas estadsticassobre conceptos relacionados con la empresa. Por ejemplo, ventas por seccin, ventas de los representantes, pedidos realizados a las operadoras,beneficio de la empresa, etc. Una vez creada una estadstica puede ser impresa o guardada en el sistema para su consulta posterior.

CU-CONTROL DE ESTADISTICA


22/43






Flujo de Eventos

1. La pantalla muestra una lista con las posibles estadsticas a crear.

2. El actor selecciona una de ellas y pulsa el botn crear.3. El sistema le muestra una pantalla donde puede asignar regiones,

almacenes o trabajadores afectados por la estadstica.4. Pulsando siguiente aparecer una ventana donde se mostrarn

parmetros de control y rangos de seleccin de forma que puedaamoldar la estadstica a sus preferencias.

5. Pulsando siguiente aparecern los resultados que podr guardar oimprimir.

a) Si pulsa el botn guardar el sistema le permitir grabar losresultados en el disco duro u otro soporte de almacenamiento.

b) Si pulsa el botn imprimir se enviar a la impresora los resultados.



23/43






Precondiciones

1. El actor ha realizado correctamente el registro en el sistema.2. El actor ha seleccionado el botn de Control Estadsticas de su interfaz

grfica.



24/43







25/43







26/43


27/43







28/43







29/43







30/43







31/43





stakeholders Actores Caractersticas del

Software

Caso de Usos Clase

Stakeholders: Los representantes de los usuarios y portavoces de las necesidadesde la empresa son los stakeholders. En este proyecto solamente se ha tratado con unstakeholder como representante de los usuarios y necesidades de la empresa, sinembargo se han dividido representativamente segn los distintos departamentos.La matriz de atributos de los stakeholders es la siguiente:


32/43






Software

Caso de Usos Clase

Stakeholders: La matriz de trazabilidad de los stakeholders relaciona a stos con lascaractersticas de software de tal manera que se puede conocer qu stakeholder propuso qu caracterstica.


33/43






Software

Caso de Usos Clase

Actores: Se define este requerimiento para listar los usuarios potenciales delsistema, en este proyecto se han definido los siguientes actores: Ingeniero deLogstica, Jefe de Almacn, Tcnico de Almacn, Jefe de Ventas, Representante deVentas, Contable, Empleado de Marketing, Cliente Online, Operadora, Encargado deTransporte, Jefe de Recursos Humanos y Empleado de Recursos Humanos .La Matriz de Atributos para los actores es la siguiente:

l d l d l ll d d


34/43






Software

Caso de Usos Clase

Actores: Lamatriz detrazabilidadde losactoresrelaciona astos con loscasos de usode tal manera

que se puedeconocer quactor utilizaqu caso deuso.

U ili d l M d l RUP D ll d Si d G


35/43






Software

Caso de Usos Clase

Caractersticas deSoftware: Lascaractersticas software sonlas necesidades de los

usuarios propuestas por losstakeholders de la empresa,son los requisitos que debecumplir el sistema parasatisfacer las necesidadesde los trabajadores y de laempresa.Las caractersticas definidasson las que aparecen en lamatriz de atributos, siendolas indicadas comosubcaractersticas lasderivadas segn unaclasificacin jerrquicas.

U ili d l M d l RUP D ll d Si d G


36/43






Software

Caso de Usos Clase

Caractersticas de Software: La matriz de trazabilidad de las caractersticas de software relaciona a stas con loscasos de uso de tal manera que se puede conocer qu caso de uso deriva de qu caracterstica.

Utili d l M t d l RUP D ll d Si t d G t


37/43






Software

Caso de Usos Clase

Utili d l M t d l RUP D ll d Si t d G t


38/43






Software

Caso de Usos Clase

Casos de Uso:

derivados de lascaractersticas

software, son elresultado del anlisisde las necesidadesde los usuarios,cuyasespecificacionesestn recogidas en elpaqueteEspecificaciones deCasos de Usodefinido en RequisitePro.

Utili d l M t d l g RUP D ll d Si t d G t


39/43






Software

Caso de Usos Clase

Casos de Uso:

derivados de lascaractersticassoftware, son elresultado del anlisisde las necesidadesde los usuarios, cyasespecificacionesestn recogidas en el

paqueteEspecificaciones deCasos de Usodefinido en RequisitePro.



40/43






Software

Caso de Usos Clase

Casos de Uso:

derivados de lascaractersticas

software, son elresultado del anlisisde las necesidadesde los usuarios,cuyasespecificacionesestn recogidas en el

paqueteEspecificaciones deCasos de Usodefinido en RequisitePro.



41/43






Software

Caso de Usos Clase



42/43






Software

Caso de Usos Clase

Clases: Las clases son requerimientos derivados de los casos de uso comonecesidad de representacin del modelo de datos.La matriz de atributos de las clases es la siguiente:



43/43


P r e g

u n t a

s

[---------- Expositor ----------]MSc. Manuel Snchez Chero
mailto:[email protected]

2_ModeloRequistos

Documents

Transcript of 2_ModeloRequistos