guia practica software.sesion04

10
Modelo de Requerimiento de Sistemas 2014 OBJETIVO ESPECÍFICO: Entender los modelos de caso de uso para detallar los requerimientos funcionales del Sistema. INDICADOR.- Identifica los requerimientos y caso de uso para el desarrollo y construcción de software orientada a objeto (OO). PROPOSITO.- El propósito primario del modelo caso de uso es comunicar las funciones y el comportamiento del sistema al cliente o usuario final. El modelo de casos… Es usado para identificar Quien interactuará con el sistema y que deberá hacer el sistema. Que los desarrolladores hayan entendido los requisitos. Se capturan todos los requisitos. CONCEPTO MODELO DE CASO DE USOS LOS ACTORE S Ing. CAMAVILCA VEGA, Dámaris Martha 1

Upload: deisy-jakelin-celis-trinidad

Post on 28-Dec-2015

90 views

Category:

Documents


1 download

TRANSCRIPT

2014

OBJETIVO ESPECÍFICO: Entender los modelos de caso de uso para detallar los requerimientos funcionales del Sistema.

INDICADOR.- Identifica los requerimientos y caso de uso para el desarrollo y construcción de software orientada a objeto (OO).

PROPOSITO.-

El propósito primario del modelo caso de uso es comunicar las funciones y el comportamiento del sistema al cliente o usuario final.

El modelo de casos…

Es usado para identificar

Quien interactuará con el sistema y que deberá hacer el sistema.Que los desarrolladores hayan entendido los requisitos.Se capturan todos los requisitos.

Un actor es un agente, alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo.

CONCEPTO

MODELO DE CASO

DE USOS

LOS ACTORE

SIn

g. C

AMAV

ILCA

VEG

A, D

ámar

is

Mar

tha

1

2014

Los actores…

Los actores no son parte del sistema, ellos representan roles que un usuario del sistema puede desempeñar.Un actor puede representar a un humano, una máquina u otro sistema.

Identificando actores.-

Los actores se determinan observando:

Usuarios directos del sistema.Responsables del uso o mantenimiento del sistema.Otros sistemas que interactúan con el sistema.

PREGUNTAS USADAS PARA AYUDAR A IDENTIFICAR ACTORES

¿Quién usará la funcionalidad principal del sistema? ¿Quién está interesado en cierto requerimiento? · ¿Donde en la organización

será usado el sistema? · ¿Quién se beneficiará con el uso del sistema? ·

¿Quién administrará, soportará y mantendrá el sistema? · ¿El sistema usa un

recurso externo? ¿Alguna persona juega varios roles diferentes? · ¿El sistema

interactúa con otro sistema?

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

2

2014

Los casos de uso modela un diálogo entre los actores y el sistema. Y un caso de uso es iniciado por un actor para invocar una cierta funcionalidad en el sistema. Un caso de uso puede participar en varias relaciones con otros casos de usos, además de asociarse con los actores.

Sistema de Registro:

Al comienzo de cada semestre, los estudiantes pueden requerir información de un catálogo de cursos, el cual contiene una lista de los cursos ofrecidos para el semestre, indicando para cada curso profesor, departamento y pre-requisitos. Información que es incluida para ayudar a los estudiantes a tomar decisiones.

LOS CASOS DE USO

Encontrando Casos de uso: ¿Cuáles son las tareas y responsabilidades de cada actor? ¿El actor, creará, guardará, cambiará, eliminará o leerá la información en el sistema? ¿Qué casos de uso crearán, almacenarán, cambiarán, borrarán o leerán esta información? ¿Qué casos de uso darán soporte y mantendrán el sistema?

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

3

2014

El nuevo sistema permitirá a los estudiantes seleccionar cuatro cursos para el siguiente semestre. Además, cada estudiante podrá indicar dos cursos alternativos en caso de no poder ser asignado en su primera selección. El curso tendrá un máximo de diez estudiantes y un mínimo de tres. Un curso con menos de tres estudiantes será cancelado. Una vez que el proceso de registro es completado, el sistema de registro envía la información al sistema de cuenta, para que al estudiante le puedan cobrar por el semestre.

Los profesores deben ser capaces de acceder al sistema on-line para indicar qué cursos estarán enseñando. También necesitarán ver qué estudiantes se inscribieron para sus cursos.

Para cada semestre, existe un período de tiempo en el que los estudiantes pueden modificar sus horarios. Los estudiantes deben ser capaces de acceder el sistema durante este tiempo para agregar o retirarse de cursos.

Diagrama de Caso de Uso Identificado

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

4

2014

Cajero automático portátilEl banco UniBank necesita ayuda para modelar el sistema que hará funcionar sus nuevos cajeros automáticos portátiles. Éstos, del porte de un teléfono público, le permitirán al usuario realizar sólo las operaciones más simples: retirar, depositar y consultar saldo (no soportaran movimientos entre cuentas de otros bancos o compras de tarjetas de prepago telefónico). Para ello ten en consideración que:

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

5

2014

Se pide ingresar la clave del usuario posteriormente al paso de la tarjeta por la ranura. No se puede retirar más fondos de los que realmente hay, notificando de esta

situación al usuario. Al 3er ingreso de clave no valida se queda decomisada la tarjeta en la ranura Si al hacer el retiro el saldo no alcanza, se notifica a la central y se cancela la

operación.

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

6

2014

Un supermercado necesita automatizar la gestión de “pedidos a proveedores”, para cada una de sus sucursales. Para esto, se debe tener en cuenta lo siguiente:

El supermercado, tiene establecido un contrato de aprovisionamiento con varios proveedores. Un proveedor puede suministrar varios productos al supermercado, cada uno de ellos en exclusiva. A cambio, se negocia la frecuencia de distribución (cada día a las 8 de la mañana, cada martes, etc.), el “valor mínimo de pedido especial” y el precio de venta. Estos valores pueden volver a ser negociados posteriormente.

El sistema deberá realizar la solicitud automática de productos, según el nivel mínimo establecido para cada tipo de producto, para conseguir un aprovisionamiento a nivel normal, y sujetos a las restricciones temporales establecidas por los proveedores. Los valores mínimo y normal son definidos por el responsable de abastecimiento.

Un operario también puede realizar un pedido a proveedor. El sistema deberá evitar la duplicidad de pedidos. No deben existir dos pedidos a proveedor para un mismo producto.

El pedido es enviado al responsable de abastecimiento para su evaluación. Éste podrá decidir modificarlo o no. Independientemente de lo que haga, deberá decidir si aprueba el pedido. Si lo aprueba, enviará la solicitud de pedido al proveedor. Éste tramitará el pedido y lo entregará en el plazo establecido en la solicitud. Cuando llegue al centro de distribución, un operario se encargará de registrar la llegada del pedido.

El responsable de abastecimiento es el encargado de solucionar los conflictos que puedan aparecer, como por ejemplo, que una sucursal necesite un pedido lo antes posible y el proveedor no lo entregue hasta dentro de una semana. En este caso, deberá decidir si tramitar un pedido especial, consultando, si es necesario, al gerente de la sucursal.

Por último, el sistema deberá permitir registrar las variaciones extraordinarias del stock, como por ejemplo, por roturas, robos, incendios, etc.

Ejemplo: Descripción de la aplicación “Gestión de pedidos a proveedores”

Actor Solicitante de pedido a proveedor.

Ejemplo: Identificación de los actores y los procesos en que participan en un sistema de gestión de pedido

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

7

2014

Actor Solicitante de pedido a proveedor.

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

8

2014

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

9