Está en la página 1de 73

Esquema Metodológico

En la fase previa de “Estado del Arte” se determinaron las siguientes


metodologías para el desarrollo del software:

 RUP (Rational Unified Process)


 XP (Xtreme Programing)
 Scrum
 CMMI
 MSF

Para comparar los modelos encontrados se procede a establecer los criterios


adecuados, los cuales son los que se muestran a continuación:

- Facilidad de uso: Permite determinar el esfuerzo del grupo de trabajo


encargado del desarrollo del software para seguir las fases que
involucra seguir la metodología.
- Costo: Define el valor monetario que implica aplicar la metodología ya
que se tiene que contar con un equipo especializado en dicha
metodología
- Grupo de trabajo: Define la cantidad de personas involucradas en el
desarrollo del software.
- Cantidad de entregables: Contempla la cantidad tanto de artefactos
como documentación a entregar en cada fase que comprende una
metodología.
- Tiempo a emplearse: Indica el tiempo que demorara desarrollar todas
las fases que posee la metodología para el desarrollo del software.
- Flexibilidad: Permite determinar la capacidad de adaptar la
metodología al problema presentado en la empresa, además de la
capacidad de adaptarse a los cambios que puedan surgir más
adelante.
- Calidad del producto final: Este criterio hace referencia a la calidad
que poseerá el producto final luego de haber utilizado una determinada
metodología.
- Documentación de sustento: Hace referencia a la facilidad de
acceder a manuales o guías que permitan servir de ayuda para el uso
de la metodología.
- Personal de la empresa involucrada: Se refiere a los trabajadores,
ajenos al grupo especializado, involucrado en el desarrollo del
software.
Los valores de cada criterio identificado para su comparación están en la
escala de 0 y 3.

Criterio Valor Descripción Puntaje


La metodología resulta fácil de
Si 1
Facilidad de utilizar
uso La metodología resulta
No 0
compleja para su uso
El costo para desarrollar la
Alto 1
metodología resultan ser altos.
Costo
Requiere un bajo costo para sí
Bajo 2
desarrollo
Requiere contar con una gran
Grande 3
equipo de trabajo
Grupo de Requiere un grupo medio de
Medio 2
trabajo trabajo.
Requiere contar con un
Pequeño 1
pequeño grupo de trabajo
La metodología genera gran
Bastante 2
Cantidad de cantidad de entregables
entregables La metodología genera pocos
Poco 1
entregables
La metodología emplear una
Bastante gran cantidad de tiempo 2
Tiempo a
(horas, días, meses)
emplearse
La metodología requiere un
Poco 1
corto periodo de tiempo
Permite adaptarse al problema
Si de la empresa y a los cambios 1
Flexibilidad
a futuro
No Difícil adaptación 0
El producto final resulta de alta
Alta 2
Calidad del calidad
producto final El producto final posee calidad
Media 1
pero no es optima
Existe gran cantidad de guías
Bastante para la orientación del 2
Documentació
personal
n de sustento
Escasa información acerca de
Poca 1
la metodología
Esta avocado más a las
Cliente 1
Orientación relaciones con el cliente
Producto Relacionado más al producto 2
La metodología requiere la
Personal de la Si participación de algunos 1
empresa trabajadores.
involucrada La metodología no requiere la
No 0
participación de trabajadores

A continuación se muestra el cuadro comparativo de las metodologías


investigadas las cuales has sido evaluada de acuerdo a los criterios y
valores establecidos anteriormente. Para el caso de en los que no se
tiene información se ha considerado casilleros en blanco los cuales tienen
una puntuación de 0.

Criterio/Modelo RUP Scrum XP MSF CMMI


Facilidad de uso Si Si Si Si No
Costo Alto
Grupo de trabajo Medio Grande
Cantidad de
Bastante Poca Poca Bastante
entregables
Tiempo a
Bastante Poco Poco Bastante Bastante
emplearse
Flexibilidad Si Si Si Si
Calidad del
Alta Media Media Alta Alta
producto final
Documentación
Bastante Bastante Bastante Poca Poca
de sustento
Orientación Producto Cliente Cliente Product Producto
o
Personal de la
empresa Si Si Si Si Si
involucrada
Total de Puntaje 15 9 9 10 14

Según este cuadro comparativo la metodología RUP es la que resulta con


mejores atributos para su aplicación en el Sistema de Control planteado
cubriendo casi en su totalidad con los criterios establecidos.

2.2. Descripción de la Metodología RUP

El desarrollo de un buen software depende de varias actividades y etapas,


debido a ello es que se debe de elegir una adecuada metodología para poder
lograr el éxito de un proyecto.

Existen dos grandes enfoques para las metodologías de desarrollo por un lado
tenemos las metodologías tradicionales que básicamente han sido pensadas
para la documentación de todo el ciclo del proyecto, y por otro lado tenemos a
las metodologías agiles que centran su objetivo en mantener buenas relaciones
con los clientes y se centra más en el equipo que en el proyecto en si [CITATION
GFi \l 1033 ].

Dentro de las metodologías tradicionales podemos encontrar dos grandes


metodologías como son RUP (Proceso de Desarrollo Unificado) y MSF
(Microsoft Solution Framework), de entre los cuales el más utilizado es la
metodología RUP que cuenta con las siguientes fases:

Inicio, permite definir y acordar los alcances del proyecto con los
patrocinadores.

Elaboración, se proceden a selecciones los casos de uso que definen la


arquitectura base del sistema.

Construcción, el propósito de esta fase es completar la funcionalidad del


sistema, para ello se deben terminar de clarificar los requisitos pendientes.

Transición, aquí se asegura que el software esté disponible para los usuarios
finales, ajustar los errores y defectos encontrados.
Dentro de la metodología RUP encontramos las siguientes disciplinas:

Modelado de Negocios

Los propósitos que tiene el Modelo de Negocios son:

- Entender los problemas que la organización desea solucionar e


identificar mejoras potenciales.
- Medir el impacto del cambio organizacional.
- Asegurar que clientes, usuarios finales, desarrolladores y los otros
participantes tengan un entendimiento compartido del problema.
- Entender como el sistema a ser desarrollado entra dentro de la
organización.

Requerimientos

Esta disciplina tiene el propósito de:

- Establecer y mantener un acuerdo con los clientes y los otros


interesados acerca de que debe hacer el sistema.
- Proveer a los desarrolladores del sistema de un mejor entendimiento de
los requerimientos del sistema.
- Definir los alcances del sistema.
- Proveer una base para la planeación de los contenidos técnicos de las
iteraciones.
- Proveer una base para la estimación de costo y tiempo necesarios para
desarrollar el sistema.
- Definir una interfaz de usuario para el sistema, enfocada en las
necesidades y objetivos del usuario.

Análisis y Diseño

El propósito del Análisis y Diseño es:

- Transformar los requerimientos a diseños del sistema.


- Desarrollar una arquitectura robusta para el sistema.
- Adaptar el diseño para hacerlo corresponder con el ambiente de
implementación y ajustarla para un desempeño esperado.

Implementación

El propósito de la implementación es:

- Definir la organización del código, en términos de la implementación de


los subsistemas organizados en capas.
- Implementar el diseño de elementos en términos de los elementos
(archivos fuente, binarios, ejecutables y otros)
- Probar los componentes desarrollados como unidades.
- Integrar los resultados individuales en un sistema ejecutable.

Pruebas

Actúa como un proveedor de servicios a las otras disciplinas en muchos


aspectos. Se enfoca principalmente en la evaluación y aseguramiento de la
calidad del producto, desarrollado a través de las siguientes prácticas:

- Encontrar fallas de calidad en el software y documentarlas.


- Recomendar sobre la calidad percibida en el software.
- Validar que el software trabaja como fue diseñado.
- Validar que los requerimientos son implementados apropiadamente.

Transición

Esta disciplina describe las actividades asociadas con el aseguramiento de la


entrega y disponibilidad del producto de software hacia el usuario final.

Administración y Configuración del Cambio

Consiste en controlar los cambios y mantener la integridad de los productos


que incluye el proyecto.

Incluye:

- Identificar los elementos configurables.


- Restringir los cambios en los elementos configurables.
Administración de Proyectos

El propósito de la Administración de Proyectos es:

- Proveer un marco de trabajo para administrar los proyectos intensivos


de software.
- Proveer guías prácticas para la planeación, soporte, ejecución y
monitoreo de proyectos.
- Proveer un marco de trabajo para la administración del riesgo.

Ambiente

- Se enfoca en las actividades necesarias para configurar el proceso al


proyecto.
- Describe las actividades requeridas para desarrollar las líneas guías de
apoyo al proyecto.
- El propósito de las actividades de ambiente es proveer a las
organizaciones de desarrollo de software del ambiente necesario
(herramientas y procesos) que den soporte al equipo de desarrollo.
2.3. Adaptación de la Metodología RUP al problema de la Empresa
Para las 4 fases correspondientes a la metodología se desarrollaran los
siguientes entregables:

- Iteración I1 (Inicio) y E1 (Elaboración): Se procederá a desarrollar las


siguientes disciplinas:
 Modelado del Negocio.- Para lo cual se desarrollaran los
siguientes entregables:
 Un modelo inicial de casos de uso del negocio.
 Descripción de los actores y trabajadores del negocio
 Descripción de cada caso de uso del negocio
 Requerimientos.- Se realizaran los siguientes entregables:
 Identificación de requerimientos.
 Diagrama de paquetes.
 Análisis y Diseño: Se realizaran los siguientes entregables
 Modelo de Clases
 Prototipos de interfaces del sistema.

- Iteración C1 (Construcción):
 En esta iteración nos centramos en el análisis, diseño e
implementación del logueo del sistema, además del módulo de
Administración (mantenimiento de tablas) y de Registro de buses.
Se entregara lo siguiente:
 Diagrama de casos de uso
 Especificación de casos de uso
 Diagrama de colaboración
 Versión operativa del módulo.
- Iteración C2 (Construcción):
 En esta iteración nos centramos en el análisis, diseño e
implementación del módulo de ventas de pasajes. Se entregara lo
siguiente:
 Diagrama de Casos de uso
 Especificación de casos de uso
 Diagrama de colaboración
 Versión operativa del modulo
- Iteración C3 (Construcción):
 En esta última iteración de la fase de construcción nos centramos
en el análisis, diseño e implementación del módulo de
encomiendas. Se entregara lo siguiente:
 Diagrama de casos de uso
 Especificación de casos de uso
 Diagrama de colaboración
 Versión Operativa del modulo
- Iteración T1 (Transición)
 En esta iteración nos centraremos en realizar las pruebas
correspondientes para verificar si cumple o no con las
expectativas del usuario. Se entregara lo siguiente:
 Pruebas

2.4. Aplicación de la metodología RUP al problema de la empresa

 Iteración I1 (Inicio) y E1 (Elaboración)


 Modelado del Negocio
 Diagrama de Casos de uso del Negocio

Venta de Boleto
(from Casos de Uso del Negocio) Encargado de Ventas Encargado de encomiendas
(f rom Actores)
(f rom Actores)

Envio de Encomienda
(from Casos de Uso del Negocio)

Cliente
Control Administrativo (f rom Actores)
(from Casos de Uso del Negocio)

Registro de Buses
(from Casos de Uso del Negocio) Encargado de buses
Adm inistrador (f rom Actores)

(f rom Actores)
 Descripción de actores y trabajadores del Negocio

Actor del
Código Descripción
Negocio
El presente actor es quien solicita el
servicio de la empresa, para este caso
AC001 Cliente podría ser el servicio de la adquision de un
boleto de viaje o el servicio de envío de
encomiendas.

Trabajador del
Código Descripción
Negocio
TN001 Encargado de Es la persona que se encarga de la
Ventas venta de los boletos de viajes a los
diferentes destinos que ofrece la
empresa.
TN002 Encargado de Es la persona que se encarga de
encomiendas atender a los clientes que soliciten un
envío de encomienda, son los
encargados de realizar todo el proceso
que implica el envío de encomiendas.
TN003 Encargado de Es la persona que se encarga de
buses registrar y controlar los buses que la
empresa adquiere, registrándolos y
asignándoles una fecha para su
mantenimiento.
TN004 Administrador Es la persona que tiene una visión de
todo el negocio y el encargado de
establecer las rutas y otras tarifas más
para que el negocio marche bien.
 Descripción de cada caso de uso del negocio

Código Caso de Uso del Descripción


Negocio
CUN001 Venta de boletos. El caso de uso empieza cuando el cliente
solicita los servicios de adquisición de un
boleto de viaje.
La venta de los boletos lo realizan los
encargados de ventas quienes de
acuerdo al tipo de servicio y el destino
elegido por el cliente le brindan
información y posterior venta del boleto
de viaje. En el pasaje se especifica los
datos principales del cliente como:
nombre, DNI destino, además de la tarifa
asignada.
Una vez llenado el boleto de viaje se
procede a entregar al cliente para realizar
el viaje al destino elegido.
El caso de uso termina cuando el cliente
recibe el boleto de viaje correctamente
llenado para proceder a abordar el bus
que lo llevara hasta su destino.
CUN002 Envío de El caso de uso se inicia cuando el cliente
Encomiendas solicita un servicio de envío de
encomiendas hacia un destino.
El cliente se acerca a la oficina de
atención y solicita información del precio
de envío de acuerdo al tipo de objeto o
documento que se desea enviar. El
responsable del servicio es el encargado
de encomienda quien procede a brindar
la información necesaria al cliente.
Después de la previa aceptación de
cliente, el encargado de encomiendas
procede a asignar determinado código al
paquete a enviar, el código asignado es
el DNI del destinatario.
Luego de esto el encargado de
encomiendas procede a indicar la hora
de salida del paquete.
El caso de uso finaliza cuando el cliente
posee todos los datos necesarios para el
envío de su encomienda, como la hora
de salida y la entrega de su comprobante
de pago.
CUN003 Registro de buses El caso de uso se inicia cuando la
empresa adquiere nuevos buses, o se
requiere hacer mantenimiento a una
unidad.
El encargado del proceso es el
encargado de buses quien de acuerdo al
proceso que se requiera se realiza las
actividades.
En el caso de que se requiera el registro
de una nueva unidad, el encargado de
buses procede a registrar las
características principales como la
marca, el modelo, la capacidad y
asignarle una fecha aproximada en el
que se tiene que realizar un
mantenimiento.
En el caso de que se requiera hacer un
mantenimiento se requiere registrar el
tipo de mantenimiento que se ha
realizado y que fecha, además de
tambien asignarle una próxima fecha en
el que se tiene que realizar el próximo
mantenimiento.
El caso de uso finaliza cuando se registró
correctamente el bus o cuando se
registra correctamente su mantenimiento.
CUN004 Control El caso de uso se inicia cuando se
Administrativo requiere realizar un determinado proceso
que afecta a toda la empresa, como por
ejemplo la asignación de una nueva tarifa
de viaje, o la incorporación de un nuevo
servicio , etc.
El responsable de realizar este tipo de
procesos es el administrador del negocio.
El caso de uso termina cuando se ha
realizado correctamente un determinado
proceso principal y se ha implementado a
toda la empresa.

 Requerimientos
 Identificación de requerimientos
funcionales(Administración)

Código Descripción
RF001 Permitir una adecuada gestión de trabajadores
RF002 Permitir la gestión de perfiles
RF003 Permitir la gestión de usuarios
RF004 Permitir el registro de ciudades (origen y destino).
RF005 Permitir el registro de horarios de salida de buses
Permitir el registro de productos autorizados para el envío
RF006
de encomiendas.
Permitir el adecuado registro de cargos de los trabajadores
RF007
que laboran en la empresa.
RF008 Registrar los tipos de servicios que ofrece la empresa.
Se debe permitir el registro de las rutas a cubrir con la
RF009 información de las ciudades que se hayan registrado y los
tipos de servicios.
RF010 Se debe considerar un registro especial para el igv
Se debe contar con interfaces principales de los perfiles
RF011 que se encuentran disponibles (Administrador, Boletero,
Encomiendas, Registro de Buses).
El sistema permitirá asignar una ruta a un determinado
RF012
chofer.
Se deberá contar con un registro de todos los intentos de
RF013 ingreso al sistema, así como la fecha de inserción o
modificación de algún dato.
Proporcionar un reporte donde se muestre el listado de
RF014
trabajadores con los que cuenta la empresa.
Emitir un reporte semanal con los buses y los choferes que
RF015 le son asignados a los mismos, así como la ruta a cubrir y
el horario de salida.
Emitir un reporte en donde se muestre las ganancias que
RF016 se obtienen tanto por venta de boletos así como por el
envío de encomiendas.
RF017 Proporcionar un reporte acerca del estado de los buses,
así como los mantenimientos que se les realizan.
Permitir el adecuado registro de los buses que son
RF018
adquiridos por la empresa.
Permitir registrar los mantenimientos que se realizan a las
RF019
diferentes unidades que posee el sistema.
El sistema deberá contar con un historial de los buses que
RF020
ya han sido dados de baja por la empresa.
El sistema deberá emitir un reporte sobre las unidades con
RF021
las que la empresa ya no cuenta.
El sistema deberá permitir el registro de clientes tanto en
RF022 el área de venta de boletos así como en el de envío de
encomiendas.
El sistema será capaz de mostrar todas las rutas y
RF023
servicios disponibles en el día.
Se deberá mostrar automáticamente las rutas disponibles
RF024 así como sus precios, de acuerdo al tipo de servicio
seleccionado
El sistema será deberá mostrar un panel con todos los
RF025
asientos con los que el bus cuenta.
Se deberá cambiar el color de los asientos cuando este ya
RF026
no se encuentre disponible.
Se deberá contar con una opción de vaciado de bus
RF027
cuando el mismo se encuentre lleno.
Se deberá emitir un reporte de todos los pasajeros que
RF028
viajan en una determinada ruta y un determinado horario.
Se deberá registrar todos los datos solicitados para poder
RF029
emitir el boleto de viaje.
Se debe emitir el boleto de viaje con todos los datos que
RF030
se hayan registrado.
El sistema debe mostrar un listado con todos los productos
RF031
autorizados para ser enviados por encomiendas.
Se debe de mostrar el precio correspondiente de acuerdo
RF032
al producto seleccionado.
En caso el precio se encuentre en función al precio se
RF033 deberá contar con una casilla especial para ingresar el
peso del producto.
RF034 En caso el producto no se encuentre en la lista se podrá
habilitar una casilla para registrar el producto a enviar,
previa verificación de la normativa establecida por el
Ministerio de Transportes.
Se debe de asignar una determinada contraseña al
RF035 paquete enviado para que no existan confusiones en su
entrega.
Se deberá registrar de manera adecuada los datos tanto
RF036
del remitente como del destinatario.
Se debe de mostrar el listado correspondiente de ciudad
RF037
de origen y destino de la encomienda.
Se deberá asignar una hora de salida del paquete a
RF038
enviar.
Se debe emitir una factura donde se muestren los datos
RF039 previamente registrados por el encargado de
encomiendas.
Se debe emitir un reporte de todos los objetos que se van
a enviar en un determinado horario a los diferentes
RF040
destinos, así como en la unidad de transporte en el que
van a ser enviados.
Se debe mostrar un listado con las encomiendas que aún
RF041
están pendiente o por enviar.
Se debe contar con un botón que permita cambiar de
RF042 estado a la encomienda que ya ha sido enviada y
entregada.

 Identificación de requerimientos no funcionales

Código Descripción

Se deberá mostrar un mensaje al momento de


RNF01 finalizar una determinada acción (registro,
modificación, eliminación y acceso al sistema).
Los cálculos de los precios en lo que
RNF02 corresponden al envío de encomiendas se deben
de realizar considerando dos decimales.
Cada trabajador debidamente autorizado deberá
RNF03 poseer un determinado acceso al sistema,
asignándole un usuario y una contraseña.
RNF04 La interfaz deberá contar con botones de acceso
rápido a las principales acciones que se realicen
en el área correspondiente.
El sistema no debe eliminar por completo la
RNF05 información relevante para la empresa como los
trabajadores.
Matriz de procesos vs Requerimientos

Proceso Requerimiento CUS Actor


Control Permitir una adecuada gestión de
RF001 CUS05 AS01
Administrativo trabajadores
RF002 Permitir la gestión de perfiles CUS09 AS01
RF003 Permitir la gestión de usuarios CUS08 AS01
Permitir el registro de ciudades
RF004 CUS06 AS01
(origen y destino).
Permitir el registro de horarios de
RF005 CUS05 AS01
salida de buses
Permitir el registro de productos
RF006 autorizados para el envío de CUS07 AS01
encomiendas.
Permitir el adecuado registro de
RF007 cargos de los trabajadores que CUS10 AS01
laboran en la empresa.
Registrar los tipos de servicios que
RF008 CUS04 AS01
ofrece la empresa.
Se debe permitir el registro de las
rutas a cubrir con la información de
RF009 CUS01 AS01
las ciudades que se hayan registrado
y los tipos de servicios.
Se debe considerar un registro
RF010 AS01
especial para el igv
Se debe contar con interfaces
principales de los perfiles que se
RF011 encuentran disponibles CUS11 AS01
(Administrador, Boletero,
Encomiendas, Registro de Buses).
El sistema permitirá asignar una ruta
RF012 CUS02 AS01
a un determinado chofer.
Se deberá contar con un registro de
todos los intentos de ingreso al
RF013 sistema, así como la fecha de CUS11 AS01
inserción o modificación de algún
dato.
RF014 Proporcionar un reporte donde se AS01
muestre el listado de trabajadores
con los que cuenta la empresa.
Emitir un reporte semanal con los
buses y los choferes que le son
RF015 AS01
asignados a los mismos, así como la
ruta a cubrir y el horario de salida.
Emitir un reporte en donde se
muestre las ganancias que se
RF016 obtienen tanto por venta de boletos AS01
así como por el envío de
encomiendas.
Proporcionar un reporte acerca del
RF017 estado de los buses, así como los AS01
mantenimientos que se les realizan.
Permitir el adecuado registro de los
RF018 buses que son adquiridos por la CUS12 AS02
empresa.
Permitir registrar los mantenimientos
RF019 que se realizan a las diferentes CUS13 AS02
Registro de unidades que posee el sistema.
Buses El sistema deberá contar con un
RF020 historial de los buses que ya han sido CUS12 AS02
dados de baja por la empresa.
El sistema deberá emitir un reporte
RF021 sobre las unidades con las que la AS02
empresa ya no cuenta.
Venta de El sistema deberá permitir el registro
Pasajes de clientes tanto en el área de venta
RF022 CUS15 AS03
de boletos así como en el de envío
de encomiendas.
El sistema será capaz de mostrar
RF023 todas las rutas y servicios disponibles CUS18 AS03
en el día.
RF024 Se deberá mostrar automáticamente CUS18 AS03
las rutas disponibles así como sus
precios, de acuerdo al tipo de
servicio seleccionado
El sistema será deberá mostrar un
RF025 panel con todos los asientos con los CUS16 AS03
que el bus cuenta.
Se deberá cambiar el color de los
RF026 asientos cuando este ya no se CUS16 AS03
encuentre disponible.
Se deberá contar con una opción de
RF027 vaciado de bus cuando el mismo se CUS16 AS03
encuentre lleno.
Se deberá emitir un reporte de todos
los pasajeros que viajan en una
RF028 AS03
determinada ruta y un determinado
horario.
Se deberá registrar todos los datos
RF029 solicitados para poder emitir el boleto CUS16 AS03
de viaje.
Se debe emitir el boleto de viaje con
RF030 todos los datos que se hayan CUS16 AS03
registrado.
Envío de El sistema debe mostrar un listado
Encomiendas RF031 con todos los productos autorizados CUS07 AS04
para ser enviados por encomiendas.
Se debe de mostrar el precio
RF032 correspondiente de acuerdo al CUS07 AS04
producto seleccionado.
En caso el precio se encuentre en
función al precio se deberá contar
RF033 AS04
con una casilla especial para
ingresar el peso del producto.
En caso el producto no se encuentre
en la lista se podrá habilitar una
casilla para registrar el producto a
RF034 AS04
enviar, previa verificación de la
normativa establecida por el
Ministerio de Transportes.
RF035 Se debe de asignar una determinada AS04
contraseña al paquete enviado para
que no existan confusiones en su
entrega.
Se deberá registrar de manera
RF036 adecuada los datos tanto del AS04
remitente como del destinatario.
Se debe de mostrar el listado
RF037 correspondiente de ciudad de origen AS04
y destino de la encomienda.
Se deberá asignar una hora de salida
RF038 AS04
del paquete a enviar.
Se debe emitir una factura donde se
muestren los datos previamente
RF039 AS04
registrados por el encargado de
encomiendas.
Se debe emitir un reporte de todos
los objetos que se van a enviar en un
determinado horario a los diferentes
RF040 AS04
destinos, así como en la unidad de
transporte en el que van a ser
enviados.
Se debe mostrar un listado con las
RF041 encomiendas que aún están
pendiente o por enviar.
Se debe contar con un botón que
permita cambiar de estado a la
RF042
encomienda que ya ha sido enviada
y entregada.
Listado de Casos de Uso del sistema

Código Nombre del Caso de Uso

CUS01 Gestionar Ruta

CUS02 Asignar Ruta

CUS03 Gestionar hora de salida

CUS04 Gestionar Servicio

CUS05 Gestionar Trabajador

CUS06 Gestionar Ciudad

CUS07 Gestionar Producto

CUS08 Gestionar Usuarios

CUS09 Gestionar Perfiles

CUS10 Gestionar Cargos

CUS11 Login

CUS12 Gestionar Buses

CUS13 Registrar Mantenimiento

CUS14 Buscar Buses

CUS15 Gestionar Cliente

CUS16 Gestionar Pasaje

CUS17 Buscar Cliente

CUS18 Buscar Ruta

CUS19
Listado de Actores del Sistema
Nombre del Actor de
Código Descripción
sistema
Se usa este rol para poder
generalizar a aquel trabajador
que tiene acceso a todo el
sistema y sus diferentes
AS01 Administrador funcionalidades, como es el caso
de los mantenimientos que se
hacen a las principales tablas
para el funcionamiento de los
demás procesos del sistema.

Se usa este rol para especificar a


los trabajadores que solamente
realizan la función del registro de
AS02 Encargado de Buses buses y sus diferentes
mantenimientos, no teniendo
acceso a las demás
funcionalidades del sistema.

Se usa este rol con la finalidad de


especificar a los trabajadores que
cumplen con la función específica
AS03 Encargado de ventas de la venta de boletos de viaje,
constituyendo una de las
funciones primordiales de la
empresa.

Se usa este rol para especificar a


Encargado de los trabajadores que realizan las
AS04
encomiendas operaciones de envío y recepción
de encomiendas.
Especificación de alto nivel de casos de uso

CUS01 – Gestionar Ruta


Actor(es) Administrador
Propósito Gestionar las diferentes rutas que se realizan de
manera cotidiana.
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción registrar
rutas.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrado
corrobora que se ha registrado correctamente la
nueva ruta a través de un mensaje de
confirmación por parte del sistema.
Requerimiento RF008,RF012,RF011

CUS02 – Asignar Ruta


Actor(es) Administrador
Propósito Asignación de las rutas disponibles a los
choferes.
Resumen El caso de uso empieza cuando se cargan las
diferentes rutas existentes.
Se procede a seleccionar una ruta disponible, y
posteriormente se selecciona un chofer
disponible.
Se selecciona la opción asignar y se procede a
guardar dicha asignación para su posterior
publicación.
Requerimiento RF012,RF011,RF004,RF015
CUS03 – Gestionar Horario
Actor(es) Administrador
Propósito Establecer un adecuado registro de las diferentes
horas de salidas de los buses.
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción
“Gestionar horario”.
A continuación procede a rellenar el campo
solicitado por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrador
corrobora que se ha registrado correctamente el
nuevo horario a través de un mensaje de
confirmación por parte del sistema.
Requerimiento RF005

CUS04 – Gestionar Servicio


Actor(es) Administrador
Propósito Gestionar de manera eficiente los diferentes
servicios que brinda la empresa a sus clientes.
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción “Tipos de
Servicios”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrador
corrobora que se ha registrado correctamente el
nuevo servicio a través de un mensaje de
confirmación por parte del sistema.
Requerimiento RF007,RF011
CUS05 – Gestionar Trabajador
Actor(es) Administrador
Propósito Registrar correctamente a los trabajadores que
laboran dentro de la empresa.
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción
“Trabajadores”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrador
corrobora que se ha registrado correctamente el
nuevo trabajador a través de un mensaje de
confirmación por parte del sistema.
Requerimiento RF001, RF009,RF011,RF014

CUS06 – Gestionar Ciudad


Actor(es) Administrador
Propósito Establecer correctamente el registro de las
distintas ciudades correspondientes a las rutas.
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción
“Ciudades”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrador
corrobora que se ha registrado correctamente
una ciudad a través de un mensaje de
confirmación por parte del sistema.
Requerimiento RF003,RF011

CUS07 – Gestionar Productos


Actor(es) Administrador
Propósito Registrar los productos disponibles para poder
enviarlos a través de una encomienda.
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción
“Productos de Encomiendas”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrador
corrobora que se ha registrado correctamente el
producto a través de un mensaje de confirmación
por parte del sistema.
Requerimiento RF005, RF032,RF011

CUS08 – Gestionar Usuarios


Actor(es) Administrador
Propósito Realizar un adecuado mantenimiento a los
usuarios que tengan acceso al sistema.
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción
“Usuarios”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrador
corrobora que se ha registrado correctamente el
usuario a través de un mensaje de confirmación
por parte del sistema.
Requerimiento RF002,RF011

CUS09 – Gestionar Perfiles


Actor(es) Administrador
Propósito Realizar un adecuado mantenimiento los perfiles
de acceso al sistema de acuerdo a las
necesidades de la empresa
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción
“Perfiles”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrador
corrobora que se ha registrado correctamente el
perfil a través de un mensaje de confirmación por
parte del sistema.
Requerimiento RF002,RF011

CUS10 – Gestionar Cargos


Actor(es) Administrador
Propósito Realizar un adecuado mantenimiento de los
cargos correspondientes al momento de registrar
a los trabajadores.
Resumen El caso de uso comienza cuando el administrador
ingresa al sistema, selecciona la opción
“Gestionar Cargos”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el administrador
corrobora que se ha registrado correctamente el
cargo a través de un mensaje de confirmación
por parte del sistema.
Requerimiento RF006,RF011

CUS11 – Login
Actor(es) Usuario
Propósito Ingresar al sistema de acuerdo al perfil asignado.
Resumen El caso de uso comienza cuando el usuario
ingresa al sistema y aparece el Formulario de
Logueo al sistema.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción Ingresar.
El caso de uso termina cuando el usuario ingresa
de manera correcta al sistema.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción Ingresar.
El caso de uso termina cuando el usuario ingresa
de manera correcta al sistema.
Requerimiento RF013

CUS12 – Gestionar Buses


Actor(es) Encargado de Buses
Propósito Realizar un adecuado registro de los buses con
los que cuenta la empresa de transportes.
Resumen El caso de uso comienza cuando el encargado
de buses ingresa al sistema, selecciona la opción
“Registrar buses”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el encargado de
buses corrobora que se ha registrado
correctamente el bus a través de un mensaje de
confirmación por parte del sistema.
Requerimiento RF018,RF011,RF017

CUS13 – Registrar Mantenimiento


Actor(es) Encargado de Buses
Propósito Realizar un adecuado registro de los diversos
mantenimientos que se realizan a las unidades
que pertenecen a la empresa.
Resumen El caso de uso comienza cuando el encargado
de buses ingresa al sistema, selecciona la opción
“Registrar Mantenimiento”.
A continuación procede a rellenar los campos
solicitados por el sistema y a continuación
selecciona la opción de grabar.
El caso de uso termina cuando el encargado de
buses corrobora que se ha registrado
correctamente el mantenimiento de un bus a
través de un mensaje de confirmación por parte
del sistema.
Requerimiento RF019,RF011,RF017

CUS14 – Buscar Buses


Actor(es) Encargado de Buses
Propósito Realizar una adecuada búsqueda de buses para
cargarlos en alas interfaces que lo requieran.
Caso de Uso Asociado -
Resumen El caso de uso comienza cuando el encargado
de buses necesita buscar un determinado bus.
Procede a seleccionar el objeto que contiene
dicha información.
Selecciona un bus de la lista cargada.
Requerimiento RF020,RF011, RF021

CUS15 – Gestionar Cliente


Actor(es) Encargado de Ventas
Propósito Realizar un adecuado registro de clientes que
van a utilizar el servicio.
Caso de Uso Asociado CUS015 – Buscar cliente
Resumen El caso de uso inicia cuando el encargado de
ventas procederá a selecciona la opción “Nuevo
cliente”.
Se llenara los campos que se soliciten y se
procederá a guardar el cliente, y se podrá
continuar con la venta del boleto.
Requerimiento RF022

CUS16 – Gestionar Pasaje


Actor(es) Encargado de Ventas
Propósito Registrar correctamente una venta del boleto de
viaje.
Caso de Uso Asociado CUS016 – Buscar Ruta
Resumen El caso de uso inicia cuando el encargado de
venta selecciona la opción Pasajes.
A continuación el encargado de ventas procederá
a ingresar y seleccionar los datos
correspondientes
Se procederá a seleccionar la opción guardar y a
continuación se procederá con la impresión del
boleto.
Requerimiento RF023, RF024, RF025, RF026, RF027
 Diagrama de paquetes

Seguridad Administrador del


Sistema

Pasajes Encomiendas Buses


Perfil
codigo_perfil : String
descripcion_perfil : String

Bus
Usuario 1 codigo_bus : String
codigo_usuario : String marca_bus : String Mantenimiento_bus
DNI_trabajador : String 1 capacidad_bus : Integer codigo_mantenimiento_bus : String
nombre_usuario : String Trabajador placa_bus : String 1..* codigo_bus : String
clave_usuario : String 1..* fecha_mantenimiento_bus : Date
codigo_perfil : String DNI_trabajador : String
1 observacion_mantenimiento_bus : String

nombre_trabajador : String
1..*
1 apellido_paterno_trabajador : String
apellido_materno_trabajador : String
celular_trabajador : String
foto_trabajador : String
1..* codigo_cargo : String

Cargo_trabajador
1..* 1..*
codigo_cargo_trabajador : String
descripcion_cargo_trabajador : String
1..* 1..* Tipo_servicio_rutas
 Análisis y Diseño

codigo_tipo_servicios_rutas : String
Rutina_viaje_bus
descripcion_tipo_servicio_rutas : String
codigo_rutina_viaje_bus : String Ruta tarifa_tipo_servicio_rutas : Double
codigo_ruta : String
codigo_ruta : String 1..*
codigo_bus : String
codigo_horario_salidas : String
DNI_trabajador : String 1..* 1..*
Diagrama de clases

codigo_tipo_servicios_rutas : String
* 1..*
origen_ruta : String
destino_ruta : String
Cliente
DNI_cliente : String 1..*
nombre_cliente : String *
Detalle_rutina 1..*
apellido_paterno_cliente : String
apellido_materno_cliente : String DNI_cliente : String
codigo_rutina_viaje_bus : String Horario_salida_buses
codigo_horario_salida_buses : String
1..*
hora_salida_buses : Time

1..*

Encomiendas
codigo_encomienda : String Objetos_encomiendas
DNI_cliente : String codigo_objeto_encomienda : String
codigo_objeto_encomienda : String descripcion_objeto_escomienda : String
origen_encomienda : String 1..* precio_objeto_encomienda : Double
1..*
destino_encomienda : String
datos_destinatario : String
 Prototipos de interfaces del Sistema
 Iteración C1 (Construcción)
 Diagrama de casos de uso del sistema (Modulo de
Administración)

<<extend>>

Asignar ruta
(from Use-Case Model)
Gestionar ruta Gestionar Servicio
(from Use-Case Model)
(from Use-Case Model)

Gestionar trabajador
(from Use-Case Model)

Administrador
(f rom Use-Case Model)

Gestionar ciudad
(from Use-Case Model)

Gestionar Horario

Gestionar Perfiles
(from Use-Case Model)
Gestionar productos
(from Use-Case Model)
Gestionar Cargo
(from Use-Case Model)
Gestionar Usuario
(from Use-Case Model)

 Especificación de Casos de Uso del Sistema

a. CUS01 - Gestionar Ruta

CUS01 – Gestionar Ruta


Administrador
1. Actor(es)
Establecer un adecuado registro de las principales
2. Propósito
rutas diarias de los buses.
El caso de uso comienza cuando el administrador
3. Resumen
ingresa al sistema, selecciona la opción registrar rutas.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el administrado


corrobora que se ha registrado correctamente la nueva
ruta a través de un mensaje de confirmación por parte
del sistema.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.
5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona la opción “Registrar Rutas” de la interfaz
principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: Tipo de servicio, precio, origen y destino.
3. El administrador procede a llenar los campos solicitados y selecciona
la opción guardar
4. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
5. El administrador acepta el mensaje y procede a cerrar la interfaz.

5.2. Subflujos
A. Subflujo “Eliminar ruta”
1. El caso de uso comienza cuando el Administrador selecciona una ruta
precargada en una tabla (Ir al caso de uso incluido “Buscar ruta”).
2. El sistema procede a cargar los datos.
3. El Administrador selecciona la opción “Eliminar”
4. El sistema procede a eliminar los datos correspondientes a la ruta
seleccionada.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
1. El administrador procede a corregir los errores correspondientes
2. Se regresa al punto 4 del flujo básico
Ruta registrada correctamente
6. Poscondición

Diagrama de colaboración
Se validan los datos ingresados

1: Se selecciona la opcion ruta 4: Se envian datos

2: Se muestra la interfaz ruta con los siguientes campos 5: Datos validados


: Administrador : I_Rutas : C_validar_rutas
3: Se ingresan los datos:

Horario
Origen 6: Datos guardados correctamente
destino
Tipo de servicio

: E_ruta
b. CUS02 - Extendido Asignar Ruta
Administrador
1. Actor(es)
Realizar una correcta asignación de rutas a los
2. Propósito
trabajadores que ocupan el cargo de chofer.
El caso de uso empieza cuando se cargan las
3. Resumen
diferentes rutas existentes.

Se procede a seleccionar una ruta disponible, y


posteriormente se selecciona un chofer disponible.

Se selecciona la opción asignar y se procede a


guardar dicha asignación para su posterior
publicación.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona la opción “Asignación semanal de
choferes” de la interfaz principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos a seleccionar por defecto: Chofer, placa del bus, ruta,
horario de salida y fecha.
3. El administrador selecciona las diferentes opciones que se muestran y
selecciona la opción “Asignar”.
4. El sistema procede a validar la información seleccionada y a
continuación muestra un mensaje de confirmación.
5. El administrador acepta el mensaje y procede a cerrar la interfaz.

5.2. Flujos Alternativos


Línea 3, del Flujo Básico
El mensaje que aparece es de error
1. El administrador procede a seleccionar las opciones faltantes.
2. Se regresa al punto 3 del flujo básico.
Se asignó correctamente las rutas
6. Poscondición
semanales.

Diagrama de Colaboracion

Se validan datos ingresados

1: Se selecciona la opcion "Asignacion Semanal de Choferes" 4: Se envian datos

2: Se muestra la interfaz correspondiente 5: Datos Validados


: Administrador : Asignar_rutas : C_as ignar_rutas
3: Se ingresan los siguientes datos

Chofer
6: Se guardan datos
Placa de Bus
Ruta
Horario de Salida
Fecha

: E_rutina
c. CUS03 Gestionar horario
Administrador
1. Actor(es)
Establecer un adecuado registro de las diferentes
2. Propósito
horas de salidas de los buses.
El caso de uso comienza cuando el administrador
3. Resumen
ingresa al sistema, selecciona la opción “Gestionar
horario”.

A continuación procede a rellenar el campo solicitado


por el sistema y a continuación selecciona la opción
de grabar.

El caso de uso termina cuando el administrador


corrobora que se ha registrado correctamente el
nuevo horario a través de un mensaje de confirmación
por parte del sistema.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


6. El administrador selecciona la opción “Gestionar horario” de la interfaz
principal.
7. El sistema procede a mostrar la interfaz correspondiente con el
siguiente campo por defecto: Hora de salida.
8. El administrador procede a llenar el campo solicitado y selecciona la
opción guardar
9. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
10. El administrador acepta el mensaje y procede a cerrar la
interfaz.
5.2. Subflujos
A. Subflujo “Eliminar Hora de salida”
1. El caso de uso comienza cuando el Administrador selecciona una
hora de salida precargada en una tabla.
2. El sistema procede a cargar los datos correspondientes
3. El Administrador selecciona la opción “Eliminar”
4. El sistema procede a eliminar los datos correspondientes de la hora
seleccionada.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
3. El administrador procede a corregir los errores correspondientes
4. Se regresa al punto 4 del flujo básico
Horario registrado correctamente
6. Poscondición

Diagrama de colaboración

Se validan datos

1: Se selecciona la opcion Gestionar Horario 4: Se envian datos

2: Se muestra la interfaz 5: Datos validados


: Administrador : I_horario : C_horario

3: Se ingresan los siguientes datos

Horario de salida
6: Datos guardados
Flujo alternativo
Mensaje de error

: E_horario
d. CUS04 Gestionar Servicio
Administrador
7. Actor(es)
Establecer un adecuado registro de los diferentes
8. Propósito
tipos de servicios que ofrece la empresa de
transporte.
El caso de uso comienza cuando el administrador
9. Resumen
ingresa al sistema, selecciona la opción “Tipos de
Servicios”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el administrador


corrobora que se ha registrado correctamente el
nuevo servicio a través de un mensaje de
confirmación por parte del sistema.
El administrador debe haberse logueado
10. Precondició
correctamente al sistema.
n

11. Flujo de Eventos

11.1. Flujo básico de eventos


11. El administrador selecciona la opción “Tipo de Servicio” de la interfaz
principal.
12. El sistema procede a mostrar la interfaz correspondiente con el
siguiente campo por defecto: Descripción de tipo de servicio.
13. El administrador procede a llenar el campo solicitado y
selecciona la opción guardar
14. El sistema procede a validar la información ingresada y a
continuación muestra un mensaje de confirmación.
15. El administrador acepta el mensaje y procede a cerrar la
interfaz.
11.2. Subflujos
B. Subflujo “Eliminar Servicio”
5. El caso de uso comienza cuando el Administrador selecciona un tipo
de servicio precargado en una tabla.
6. El sistema procede a cargar los datos correspondientes
7. El Administrador selecciona la opción “Eliminar”
8. El sistema procede a eliminar los datos correspondientes del servicio
seleccionado.
11.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
5. El administrador procede a corregir los errores correspondientes
6. Se regresa al punto 4 del flujo básico
Servicio registrado correctamente
12. Poscondición

Diagrama de Colaboracion

se validan datos

1: Se selecciona la opcion Tipo d Servicio 4: se envian datos

5: datos validados
2: Se muestra la interfaz servicio : I_servicio : C_servicio
: Administrador
3: Se ingresa

Tipo de servicio
6: se guardan los datos
Tarifa

: E_servicio
e. CUS05 - Gestionar Trabajador
Administrador
1. Actor(es)
Registrar correctamente a trabajadores que laboran en
2. Propósito
la empresa.
El caso de uso comienza cuando el administrador
3. Resumen
ingresa al sistema, selecciona la opción
“Trabajadores”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el administrador


corrobora que se ha registrado correctamente el nuevo
trabajador a través de un mensaje de confirmación por
parte del sistema.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona la opción “Trabajadores” de la interfaz
principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: DNI, Nombre, Apellido Paterno, Apellido
Materno, Cargo y Celular.
3. El administrador procede a llenar los campos solicitados y selecciona
la opción guardar
4. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
5. El administrador acepta el mensaje y procede a cerrar la interfaz.

5.2. Subflujos
B. Subflujo “Modificar Trabajador”
A. El caso de uso comienza cuando el Administrador selecciona un
Trabajador precargado en una tabla.
B. El sistema procede a cargar la información del trabajador
seleccionado
C. El administrador procede a modificar los datos correspondientes y
selecciona la opción modificar
D. Se regresa al punto 4 del flujo básico.
C. Subflujo “Eliminar Trabajador”
1. El caso de uso comienza cuando el Administrador selecciona un
trabajador precargado en una tabla.
2. El sistema procede a cargar los datos correspondientes
3. El Administrador selecciona la opción “Eliminar”
4. El sistema procede a eliminar los datos correspondientes del
trabajador seleccionado.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
1. El administrador procede a corregir los errores correspondientes
2. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
1. El administrador procede a ingresar los datos faltantes
2. Se regresa al punto 4 del flujo básico
Trabajador registrado correctamente
6. Poscondición

Diagrama de colaboración

Se validan datos ingresados

1: Se selecciona la opcion Trabajador 4: Se envian datos

2: Se muestra la interfaz correspondiente 5: Datos correctos


: Administrador : I_trabajador : C_trabajadores
3: Se ingresan los siguientes datos

DNI
Nombre
Apellido Paterno 6: Se guardan datos
Apellido Materno
Cargo
Celular
Foto

f. CUS06 - Gestionar ciudad : E_trabajador


Administrador
1. Actor(es)
Establecer correctamente el registro de las distintas
2. Propósito
ciudades correspondientes a las rutas.
El caso de uso comienza cuando el administrador
3. Resumen
ingresa al sistema, selecciona la opción “Ciudades”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el administrador


corrobora que se ha registrado correctamente una
ciudad a través de un mensaje de confirmación por
parte del sistema.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona la opción “Ciudades” de la interfaz
principal.
2. El sistema procede a mostrar la interfaz correspondiente con el
siguiente campo por defecto: Nombre de ciudad.
3. El administrador procede a llenar el campo solicitado y selecciona la
opción guardar
4. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
5. El administrador acepta el mensaje y procede a cerrar la interfaz.

5.2. Flujos Alternativos


Línea 4, del Flujo Básico
Dato no ingresado
1. El administrador procede a llenar el formulario
2. Se regresa al punto 4 del flujo básico
Ciudad registrada correctamente
6. Poscondición

Diagrama de Colaboracion
Se validan datos ingresados

1: Se selecciona la opcion "Ciudades" 4: Se envian datos

2: Se muestra la interfaz seleccionada 5: Datos correctos


: Administrador : I_ciudad : C_ciudad
3: Se ingresa :

Nombre de Ciudad 6: Datos guardados

g. CUS07 - Gestionar productos


: E_ciudad
Administrador
1. Actor(es)
Registrar los productos disponibles para poder
2. Propósito
enviarlos a través de una encomienda.
El caso de uso comienza cuando el administrador
3. Resumen
ingresa al sistema, selecciona la opción “Productos de
Encomiendas”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el administrador


corrobora que se ha registrado correctamente el
producto a través de un mensaje de confirmación por
parte del sistema.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona la opción “Productos de Encomiendas” de
la interfaz principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: Descripción de producto y precio.
3. El administrador procede a llenar los campos solicitados y selecciona
la opción guardar
4. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
5. El administrador acepta el mensaje y procede a cerrar la interfaz.

5.2. Subflujos
A. Subflujo “Eliminar Producto”
2. El caso de uso comienza cuando el Administrador selecciona un
producto precargado en una tabla.
5. El sistema procede a cargar los datos correspondientes
6. El Administrador selecciona la opción “Eliminar”
7. El sistema procede a eliminar los datos correspondientes del producto
seleccionado.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
3. El administrador procede a corregir los errores correspondientes
4. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
3. El administrador procede a ingresar los datos faltantes
4. Se regresa al punto 4 del flujo básico
Producto registrado correctamente
6. Poscondición

Diagrama de colaboración
Se validan datos ingresados

1: Se selecciona la opcion Producto de Encomiendas


4: Se envian datos

5: Datos correctos
: Administrador 2: Se muestra la interfaz correspondiente : I_producto : C_producto
3: Se ingresa

Descripcion del producto


Precio
6: Datos guardados

: E_producto
h. CUS08 Gestionar Usuarios

Administrador
1. Actor(es)
Realizar un adecuado mantenimiento a los usuarios
2. Propósito
que tengan acceso al sistema.
El caso de uso comienza cuando el administrador
3. Resumen
ingresa al sistema, selecciona la opción “Usuarios”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el administrador


corrobora que se ha registrado correctamente el
usuario a través de un mensaje de confirmación por
parte del sistema.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona la opción “Usuarios” de la interfaz
principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: Nombre de Usuario, Clave de usuario,
Perfil de Usuario y DNI del Trabajador.
3. El administrador procede a llenar los campos solicitados y selecciona
la opción guardar
4. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
5. El administrador acepta el mensaje y procede a cerrar la interfaz.

5.2. Subflujos
D. Subflujo “Modificar Usuario”
1. El caso de uso comienza cuando el Administrador selecciona un
usuario precargado en una tabla.
2. El sistema procede a cargar la información del usuario seleccionado
3. El administrador procede a modificar los datos correspondientes y
selecciona la opción modificar
4. Se regresa al punto 4 del flujo básico.
E. Subflujo “Eliminar Usuario”
1. El caso de uso comienza cuando el Administrador selecciona un
usuario precargado en una tabla.
2. El sistema procede a cargar los datos correspondientes
3. El Administrador selecciona la opción “Eliminar”
4. El sistema procede a eliminar los datos correspondientes del usuario
seleccionado.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
1. El administrador procede a corregir los errores correspondientes
2. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
1. El administrador procede a ingresar los datos faltantes
2. Se regresa al punto 4 del flujo básico
Usuario registrado correctamente
6. Poscondición

Diagrama de Colaboracion

Se validan datos ingresados

1: Se selecciona la opcion "Usuarios" 4: Se envian datos

2: Se muestra la interfaz seleccionada 5: Datos validados


: Administrador : I_usuario : C_usuario
3: Se ingresan datos

Nombre de Usuario
Clave de Usuario 6: Se guardan datos ingresados

Perfil
DNI Trabajador

: E_usuario
i. CUS09 - Gestionar Perfiles
Administrador
1. Actor(es)
Realizar un adecuado mantenimiento los perfiles de
2. Propósito
acceso al sistema de acuerdo a las necesidades de la
empresa
El caso de uso comienza cuando el administrador
3. Resumen
ingresa al sistema, selecciona la opción “Perfiles”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el administrador


corrobora que se ha registrado correctamente el perfil
a través de un mensaje de confirmación por parte del
sistema.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona la opción “Perfiles” de la interfaz principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: Descripción de Perfil.
3. El administrador procede a llenar el campo solicitado y selecciona la
opción guardar
4. El sistema procede a validar la información ingresada y a
continuación muestra un mensaje de confirmación.
5. El administrador acepta el mensaje y procede a cerrar la interfaz.

5.2. Subflujos
F. Subflujo “Eliminar Perfil”
1. El caso de uso comienza cuando el Administrador selecciona un perfil
precargado en una tabla.
2. El sistema procede a cargar el dato correspondiente.
3. El Administrador selecciona la opción “Eliminar”
4. El sistema procede a eliminar el dato correspondiente del perfil
seleccionado.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
1. El administrador procede a corregir los errores correspondientes
2. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
1. El administrador procede a ingresar los datos faltantes
2. Se regresa al punto 4 del flujo básico
Perfil registrado correctamente
6. Poscondición

Diagrama de Colaboracion

Se validan datos ingresados

1: Se selecciona la opcion "Perfiles" 4: Se envian datos

2: Se muestra la interfaz correspondiente 5: Datos validados


: Administrador : I_perfil : C_perfil
3: Se ingresan datos

Descripcion del Perfil


6: Se guardan datos

: E_perfil
j. CUS10 - Gestionar Cargos
Administrador
1. Actor(es)
Realizar un adecuado mantenimiento de los cargos
2. Propósito
correspondientes al momento de registrar a los
trabajadores.
El caso de uso comienza cuando el administrador
3. Resumen
ingresa al sistema, selecciona la opción “Gestionar
Cargos”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el administrador


corrobora que se ha registrado correctamente el cargo
a través de un mensaje de confirmación por parte del
sistema.
El administrador debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona la opción “Gestionar Cargos” de la
interfaz principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: Descripción de Cargos.
3. El administrador procede a llenar el campo solicitado y selecciona la
opción guardar
4. El sistema procede a validar la información ingresada y a
continuación muestra un mensaje de confirmación.
5. El administrador acepta el mensaje y procede a cerrar la interfaz.

5.2. Subflujos
G. Subflujo “Eliminar Cargo”
1. El caso de uso comienza cuando el Administrador selecciona un
cargo precargado en una tabla.
2. El sistema procede a cargar el dato correspondiente.
3. El Administrador selecciona la opción “Eliminar”
4. El sistema procede a eliminar el dato correspondiente del cargo
seleccionado.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
1. El administrador procede a corregir los errores correspondientes
2. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
1. El administrador procede a ingresar los datos faltantes
2. Se regresa al punto 4 del flujo básico
Cargo registrado correctamente
6. Poscondición

Diagrama de Colaboracion

Se validan datos ingresados

1: Se selecciona la opcion "Gestionar Cargo"


4: Se envian datos

2: Se muestra la interfaz correspondiente 5: Datos validados


: Administrador : I_cargo : C_cargo
3: Se ingresan datos

Descripcion del cargo

6: Se guardan datos

: E_cargo
 Diagrama de casos de uso del sistema (Modulo de Seguridad)

Login
Usuario
(from Use-Case Model)
(f rom Use-Case Model)

 Especificación de Casos de Uso del Sistema

a. CUS11 - Login
Usuario
1. Actor(es)
Ingresar al sistema de acuerdo al perfil asignado.
2. Propósito
El caso de uso comienza cuando el usuario ingresa al
3. Resumen
sistema y aparece el Formulario de Logueo al sistema.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción Ingresar.

El caso de uso termina cuando el usuario ingresa de


manera correcta al sistema.

4. Precondición El usuario debe estar registrado en el sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El administrador selecciona el icono del sistema.
2. El sistema procede a mostrar la interfaz de ingreso al sistema con los
siguientes campos: Perfil, Usuario y Contraseña.
3. El administrador procede a llenar el campo solicitado y selecciona la
opción Ingresar
4. El sistema procede a validar la información ingresada y a
continuación procede a cargar la interfaz principal del sistema
5.2. Flujos Alternativos
Línea 4, del Flujo Básico
Usuario o Contraseña incorrectos
1. El usuario procede a corregir los datos correspondientes
2. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
1. El usuario procede a ingresar los datos faltantes
2. Se regresa al punto 4 del flujo básico
Usuario logueado correctamente.
6. Poscondición

Diagrama de Colaboracion
Se validan datos

1: Se selecciona el icono del sistema 4: Se envian datos

2: Se carga el sistem a y aparece la interfaz de logueo 5: Datos validados


: Usuario : I_login : C_login
3: Se ingresan datos:

Perfil 6: Se carga la interfaz principal


Usuario
Conrtraseña

: I_principal
 Diagrama de casos de uso del sistema (Modulo de Registro de
Buses)

<<include>>

Gestionar buses
(from Use-Case Model)

Encargado de
buses
(f rom Use-Case Model)
Buscar Bus
(from Use-Case Model)
<<include>>

Registrar Mantenimiento
(from Use-Case Model)

 Especificación de Casos de Uso del Sistema

a. CUS12 - Gestionar Buses


Encargado de Buses
1. Actor(es)
Realizar un adecuado registro de los buses con los
2. Propósito
que cuenta la empresa de transportes.
El caso de uso comienza cuando el encargado de
3. Resumen
buses ingresa al sistema, selecciona la opción
“Registrar buses”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el encargado de buses


corrobora que se ha registrado correctamente el bus a
través de un mensaje de confirmación por parte del
sistema.
El encargado de buses debe haberse logueado
4. Precondición
correctamente al sistema.
5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El encargado de buses selecciona la opción “Registrar buses” de la
interfaz principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: Marca de bus, modelo de bus, placa
del bus, capacidad de bus y año de fabricación.
3. El encargado de buses procede a llenar los campos solicitados y
selecciona la opción guardar
4. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
5. El encargado de buses acepta el mensaje y procede a cerrar la
interfaz.
5.2. Subflujos
H. Subflujo “Modificar Bus”
1. El caso de uso comienza cuando el Encargado de bus selecciona un
bus precargado en una tabla. (Ir al caso de uso Incluido Buscar Bus).
2. El sistema procede a cargar la información del bus seleccionado
3. El encargado de buses procede a modificar los datos
correspondientes y selecciona la opción modificar
4. Se regresa al punto 4 del flujo básico.
I. Subflujo “Eliminar Bus”
1. El caso de uso comienza cuando el encargado de buses selecciona
un bus precargado en una tabla.
2. El sistema procede a cargar los datos correspondientes
3. El encargado de buses selecciona la opción “Eliminar”
4. El sistema procede a eliminar los datos correspondientes del bus
seleccionado.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
1. El encargado de buses procede a corregir los errores
correspondientes
2. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
1. El encargado de buses procede a ingresar los datos faltantes
2. Se regresa al punto 4 del flujo básico
Bus registrado correctamente
6. Poscondición

Diagrama de colaboración

Se validan datos ingresados

1: Se selecciona la opcion Bus de la interfaz principal


4: Se envian datos

2: Se muestra la interfaz correspondiente


: Encargado de buses : I_bus 5: Datos validados : C_bus
3: Se ingresan datos

Modelo de Bus
6: Datos guardados
Placa de Bus
Capacidad

: E_bus

b. CUS13 - Registrar Mantenimiento


Encargado de Buses
1. Actor(es)
Realizar un adecuado registro de los diversos
2. Propósito
mantenimientos que se realizan a las unidades que
pertenecen a la empresa.
El caso de uso comienza cuando el encargado de
3. Resumen
buses ingresa al sistema, selecciona la opción
“Registrar Mantenimiento”.

A continuación procede a rellenar los campos


solicitados por el sistema y a continuación selecciona
la opción de grabar.

El caso de uso termina cuando el encargado de buses


corrobora que se ha registrado correctamente el
mantenimiento de un bus a través de un mensaje de
confirmación por parte del sistema.
El encargado de buses debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El encargado de buses selecciona la opción “Registrar
mantenimiento” de la interfaz principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: Fecha de Mantenimiento, Bus,
Observación.
3. El encargado de buses procede a llenar los campos solicitados y
selecciona la opción guardar (Ir al caso de uso incluido Buscar Bus)
4. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
5. El encargado de buses acepta el mensaje y procede a cerrar la
interfaz.
5.2. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
3. El encargado de buses procede a corregir los errores
correspondientes
4. Se regresa al punto 4 del flujo básico
Mantenimiento registrado
6. Poscondición
correctamente

Diagrama de Colaboracion
Se validan datos

1: Se selecciona la opcion "Registrar Mantenimiento" 4: Se envian datos

2: Se muestra la interfaz correspondiente 5: Datos validados


: Encargado de buses : I_mantenimiento_bus : C_mantenimiento_buses
3: Se ingresan Datos

Fecha de Mantenimiento
Bus 6: Mantenimiento Registrado
Observacion caso de uso
incluido
Buscar Bus

: E_mantenimiento_buses
c. CUS14 - Caso de Uso Incluido “Buscar Bus”

Encargado de Buses
1. Actor(es)
Realizar una adecuada búsqueda de buses para
2. Propósito
cargarlos en alas interfaces que lo requieran.
El caso de uso comienza cuando el encargado de
3. Resumen
buses necesita buscar un determinado bus.

Procede a seleccionar el objeto que contiene dicha


información.

Selecciona un bus de la lista cargada.


El encargado de buses debe requerir un determinado
4. Precondición
bus

5. Flujo de Eventos

5.1. Flujo básico de eventos


6. El encargado de buses selecciona el objeto que contiene el listado de
buses
7. El sistema procede a precargar el listado de buses en el objeto
8. El encargado de buses procede a selecciona un bus precargado
Bus encontrado correctamente
6. Poscondición

Diagrama de colaboración

Se valida peticion

1: Se requiere un bus y se selecciona el objeto que lo contiene


2: Se envia peticion

6: Se muestran datos 5: Se cargan datos al objeto


: Encargado de buses : I_objeto : C_bus
7: Se selecciona un bus

3: Se consultan datos

4: Datos consultados

: E_bus
 Diagrama de casos de uso del sistema (Modulo de Venta de
Boletos)

Buscar ciudad
<<extend>> <<include>>
Buscar ruta
(from Use-Case Model)
(from Use-Case Model)

<<include>>

Encargado de Gestionar pasaje


Ventas
(f rom Use-Case Model) (from Use-Case Model) <<include>>
Buscar Bus
(from Use-Case Model)

<<include>>

Gestionar cliente
Buscar Cliente
(from Use-Case Model)
(from Use-Case Model)
 Especificación de Casos de Uso del Sistema

a. CUS15 - Caso de Uso Gestionar Cliente

1. Actor(es) Encargado de Ventas


Realizar un adecuado registro de clientes que van a
2. Propósito
utilizar el servicio.
El caso de uso inicia cuando el encargado de ventas
3. Resumen
procederá a selecciona la opción “Nuevo cliente”.

Se llenara los campos que se soliciten y se procederá


a guardar el cliente, y se podrá continuar con la venta
del boleto.
El encargado de ventas debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El encargado de ventas selecciona la opción “Nuevo cliente” de la
interfaz principal.(Ir al caso de uso incluido “Buscar cliente”)
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: DNI, Nombre del cliente, Apellido
Paterno y Apellido Materno.
3. El encargado de ventas procede a llenar los campos solicitados y
selecciona la opción guardar
4. El sistema procede a validar la información ingresada y a continuación
muestra un mensaje de confirmación.
5. El encargado de ventas acepta el mensaje y procede a cerrar la
interfaz.
5.2. Subflujos
A. Subflujo “Eliminar Cliente”
5. El caso de uso comienza cuando el encargado de ventas selecciona
un cliente previamente cargado en una tabla.
6. El sistema procede a cargar los datos correspondientes
7. El encargado de ventas selecciona la opción “Eliminar”
8. El sistema procede a eliminar los datos correspondientes del cliente
seleccionado.
5.3. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
5. El encargado de buses procede a corregir los errores
correspondientes
6. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
3. El encargado de buses procede a ingresar los datos faltantes
4. Se regresa al punto 4 del flujo básico
Cliente registrado correctamente
6. Poscondición

Diagrama de Colaboracion

Se validan datos ingresados

1: El encargado de ventas selecciona la opcion "Nuevo Cliente" 4: Se envian datos

2: Se carga la interfaz correspondiente 5: Datos validados


: Encargado de Ventas : I_clientes : C_clientes
3: Se ingresan los siguientes datos

DNI
6: Datos guardados
Nombre del cliente
Apellido Paterno
Apellido Materno

: E_clientes
b. CUS16 - Caso de Uso Gestionar Pasaje

1. Actor(es) Encargado de Ventas


Registrar correctamente una venta del boleto de viaje.
2. Propósito
El caso de uso inicia cuando el encargado de venta
3. Resumen
selecciona la opción Pasajes.

A continuación el encargado de ventas procederá a


ingresar y seleccionar los datos correspondientes

Se procederá a seleccionar la opción guardar y a


continuación se procederá con la impresión del boleto.
El encargado de ventas debe haberse logueado
4. Precondición
correctamente al sistema.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El encargado de ventas selecciona la opción “Pasajes” de la interfaz
principal.
2. El sistema procede a mostrar la interfaz correspondiente con los
siguientes campos por defecto: DNI del cliente, RUC, Razón Social,
Tipo de Servicio, Ruta, Precio, Nro. De Asiento, Ubicación, Hora de
salida, Total.
3. El encargado de ventas procede a llenar los campos solicitados
4. Posteriormente se selecciona un asiento del panel derecho de la
interfaz.
5. El sistema procede a cargar el número de asiento y su ubicación
correspondiente.
6. El encargado de ventas procede a seleccionar la opción Guardar
7. El sistema valida los datos ingresados
8. El sistema procede a guardar y posteriormente a imprimir el boleto de
viaje.
5.2. Flujos Alternativos
Línea 4, del Flujo Básico
El mensaje que aparece es de error
1. El encargado de buses procede a corregir los errores
correspondientes
2. Se regresa al punto 4 del flujo básico
Línea 2, del Flujo Básico
Datos no ingresados
1. El encargado de buses procede a ingresar los datos faltantes
2. Se regresa al punto 4 del flujo básico
Boleto de viaje guardado y emitido
6. Poscondición
correctamente

Diagrama de Colaboracion

Se validan datos ingresados

1: El encargado de ventas selecciona la opcion "Pasajes" 4: Se envian datos

2: Se procede a cargar la inerfaz correspondiente 5: Datos validados


: Encargado de Ventas : I_boleto : C_boleto
3: Se ingresan los siguientes datos

DNI del Cliente


RUC
Razon social
7: Se guardan datos
Tipo de Servicio
Ruta
Precio
Nro. de asiento
Ubicacion
Hora de salida

6: Mensaje de Confirmacion

c. CUS017 - Caso
: E_boleto
de Uso Incluido Buscar Cliente

1. Actor(es) Encargado de Ventas


Realizar la búsqueda de clientes antes de vender un
2. Propósito
boleto de viaje.
El caso de uso inicia cuando el encargado de venta
3. Resumen
selecciona la opción buscar.
El encargado de ventas debe haberse logueado
4. Precondición
correctamente al sistema.

Debe haber ingresado la interfaz “Pasajes”.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El encargado de ventas se encuentra en la ventana “Pasajes” de la
interfaz principal.
2. El encargado de ventas ingresa el DNI o ruc del cliente y selecciona la
opción buscar
3. El sistema procede a consultar en la base de datos los datos
ingresados
4. Posteriormente se muestra la información requerida por el encargado
de ventas para proseguir con la venta
5.2. Flujos Alternativos
Línea 4, del Flujo Básico
No se encuentra registrado el cliente
1. El sistema procederá a mostrar un mensaje de error: “Cliente no
registrado”
2. Se regresa al punto 3 del flujo básico del caso de Uso Gestionar
Cliente.
Se han cargado exitosamente los
6. Poscondición
datos del cliente buscado
Diagrama de Colaboracion

Se validan datos

1: Se selecciona la opcion "Buscar cliente" 2: Se envian datos

6: Se muestran los datos solicitados 5: Datos validados


: Encargado de Ventas : I_boleto : C_clientes

Flujo Alternativo:
Mensaje de error:
Cliente no registrado
3: Se consultan datos

4: Se envian resultados

: E_clientes

d. CUS018 - Caso de uso incluido Buscar Ruta

1. Actor(es) Encargado de Ventas


Realizar la búsqueda de rutas antes de vender un
2. Propósito
boleto de viaje.
El caso de uso inicia cuando se carga la interfaz de
3. Resumen
Pasajes.
El encargado de ventas debe haberse logueado
4. Precondición
correctamente al sistema.

Debe haber ingresado la interfaz “Pasajes”.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El encargado de ventas se encuentra en la ventana “Pasajes” de la
interfaz principal.
2. El encargado de ventas hace clic sobre el combo donde se
encuentran los tipos de servicios.
3. El sistema procede a cargar el combo de rutas de acuerdo al tipo de
servicio que se haya elegido
4. El encargado de ventas hace clic sobre el combo
5. El sistema procede a mostrar todas las rutas que se han encontrado.
Se han cargado exitosamente los datos de las rutas
6. Poscondición
buscadas.

Diagrama de Colaboracion

Se validan datos ingresados

1: Se selecciona un tipo de servicio 2: Se envian datos

6: Se muestran las rutas disponibles 5: Datos validados


: Encargado de Ventas : I_boleto : C_validar_rutas

3: Se consultan datos

4: Se obtiene una respuesta

: E_ruta

 Diagrama de Casos de Uso del Sistema (Modulo de Envio de


Encomiendas)

Gestionar Clave
(from Use-Case Model)

Encargado de <<extend>> Calcular Pago


Encomiendas
(f rom Use-Case Model)
Gestionar encomienda
<<extend>>

Buscar ciudad
Emitir factura Listar encomiendas
(from Use-Case Model)
(from Use-Case M odel)
 Especificacion de Casos de Uso

a. CUS19 – Caso de Uso Gestionar Encomienda

1. Actor(es) Encargado de Encomiendas


Realizar el adecuado mantenimiento de las
2. Propósito
encomiendas que se envían y recepcionan en el
terminal.
El caso de uso comienza cuando el encargado de
3. Resumen
encomiendas selecciona la opción “Envio de
Encomiendas”.

A continuación el encargado de encomiendas procede


a ingresar los datos correspondientes y se procede a
registrar el envio de la encomienda.
El encargado de encomiendas debe haberse logueado
4. Precondición
correctamente al sistema.

Debe haber ingresado la interfaz “Encomiendas”.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El encargado de encomiendas selecciona la opción “Envio de
Encomiendas” de la interfaz principal.
2. El sistema procede a mostrar la interfaz principal con los siguientes
campos: DNI/RUC, remitente, destinatario, Tipo de objeto, peso, hora
de salida, clave, origen, destino, subtotal, igv y total.
3. El encargado de encomiendas procede a llenar los campos solicitados
(ir a los casos de uso extendido calcular pago y listar encomienda).
4. El sistema procede a validar los datos ingresados
5. El sistema procede a mostrar un mensaje de confirmación
6. El encargado de encomiendas procede a aceptar el mensaje.
5.2. Flujo alternativo
En la línea 3 del flujo básico
Mensaje de error
- El encargado de encomiendas procede a corregir los datos erróneos.
- Se regresa al punto 4 del flujo básico
En la línea 3 del flujo básico
Datos no ingresados
- Se muestra un mensaje de error.
- El encargado de encomiendas procede a ingresar los datos faltantes.
Se regresa al punto 4 del flujo básico.
-
Se ha registrado correctamente la encomienda a
6. Poscondición
enviar.

Diagrama de Colaboracion

Se validan datos ingresados

1: Se selecciona la opcion "Envio de encomiendas"


4: Se envian datos

2: Se muestra la interfaz correspondiente 5: Datos validados


: Encargado de : I_encomienda : C_encomienda
3: Se ingresan datos
Encomiendas

DNI/RUC
Remitente
6: Se guardan datos
Destinatario
Tipo de objeto
Peso
Hora de Salida
Clave
Origen
Destino

: E_encomienda
b. CUS20 - Caso de Uso extendido Listar Encomienda

1. Actor(es) Encargado de Encomiendas


Listar de manera correcta todas la encomiendas que
2. Propósito
están por enviarse a su destino.
El caso de uso inicia cuando se carga la interfaz de
3. Resumen
Envio de Encomiendas y se selecciona la pestaña de
recepción de encomiendas.

Al seleccionar esta etiqueta se procede a listar las


encomiendas que aun no han sido enviadas y/o
recogidas por el destinatario.
El encargado de ventas debe haberse logueado
4. Precondición
correctamente al sistema.

Debe haber ingresado la interfaz “Envio de


Encomiendas”.

5. Flujo de Eventos

5.1. Flujo básico de eventos


1. El encargado de ventas se encuentra en la ventana “Pasajes” de la
interfaz principal.
2. El encargado de ventas hace clic sobre el combo donde se
encuentran los tipos de servicios.
3. El sistema procede a cargar el combo de rutas de acuerdo al tipo de
servicio que se haya elegido
4. El encargado de ventas hace clic sobre el combo
5. El sistema procede a mostrar todas las rutas que se han encontrado.
Se han cargado exitosamente los datos de las
6. Poscondición
encomiendas.

También podría gustarte