Requerimientos – Arquitectura de Software

(Entrega Individual)

Casos, Enunciados, Preguntas y Responsables

Plazo: 24 de mayo 2023

En la Plataforma

Página 1
 Requerimientos – Arquitectura de Software

Contenido

1. Caso Nro. 1: Sistema de Gestió n Comercial – Autoservicio Las Palmas 3

1.1 Enunciado del Caso 3
1.2 Caso de Uso del Sistema 3
2. Caso Nro. 2: Sistema de Administració n de Venta de Boletos 4
2.1 Enunciado del Caso 4
2.2 Propuesta de Caso de Uso del Sistema 5
3. Caso Nro. 3: Sistema de Hostelería 6
3.1 Enunciado del Caso 6
3.2 Propuesta del Caso de Uso del Sistema 6
4. Caso Nro. 4: Sistema de Clínica “Salud.com” 8
4.1 Enunciado del Caso 8
4.2 Propuesta de Caso de Uso del Sistema 8
5. Caso Nro. 5: Sistema de RRHH EMAPE 10
5.1 Enunciado del Caso 10
5.2 Propuesta de Caso de Uso del Sistema 10
6. Caso Nro. 6: Sistema de Biblioteca 11
6.1 Enunciado del Caso 11
6.2 Propuesta de Caso de Uso del Sistema 11
7. Caso Nro. 7: Campo Fe Asociados 12
1.1 Enunciado del Caso 12
1.2 Propuesta de Caso de Uso del Sistema 12
8. Caso Nro. 8: Control de Asistencia de la Universidad UNFV 13
8.1 Enunciado del Caso 13
9. Caso Nro. 9: Control de Inventario 13
9.1 Enunciado del Caso 13
10. Caso Nro.10: Sistema de Gestió n Académica para Instituto 14
10.1 Enunciado del Caso 14
10.2 Propuesta de Caso de Uso del Sistema 14
11. Supuestos 14

Página 2
 Requerimientos – Arquitectura de Software

1. Caso Nro. 1: Sistema de Gestión Comercial – Autoservicio Las Palmas

1.1 Enunciado del Caso

La empresa “Auto Servicios Las Palmas” viene manejando principalmente los procesos de ventas y
Facturació n de una manera ordenada, pero Manual; esto quiere decir que no cuenta con sistema
que ayude y agilice dicho proceso (Manejo de Ventas, Facturació n, productos, Clientes, etc.); y por
otro lado no se lleva un registro sistematizado con los proveedores que proporcionan los
productos.

El Sistema propone ejecutar los procesos operativos relacionados con el Proceso de Ventas y
facturació n de repuestos para automó viles antes mencionados; mejorando la atenció n al cliente y
agilizando el acceso a la informació n a los empleados y dueñ o de la empresa, en la interacció n
diaria y con los proveedores.

En su levantamiento de informació n, ha identificado el Caso de Uso del Sistema.

1.2 Caso de Uso del Sistema

Gestionar Ventas Almacenero

Cajero
Gestionar Producto
<<include>> (f rom Act...
(f rom Act...
<<include>>

<<include>>

<<include>>
Gestionar Cliente Buscar Producto

<<include>>

Buscar Ventas

Buscar Cliente

Tener en consideración lo siguiente:

 Capa de Presentación: Desde el cual se activará la aplicació n, a través de un browser
(pá ginas HTML, JSP) sobre una direcció n URL asignada al Sistema.
 Capa de Negocios (Servidor Web): Se utilizará un servidor de aplicaciones donde se
implementará n las pá ginas, a través de la ló gica de datos, DAO, Servlets, Interfaz y Beans.
 Capa de Data: En la cual residirá la Base de Datos y los diferentes objetos creados para el
Sistema (tablas, índices, procedimientos almacenados, funciones, vistas). Se utilizará el
soporte brindado por el Administrador de Base de Datos SQL Server 20160 y un servidor
Web TOMCAT.

Página 3
 Requerimientos – Arquitectura de Software

2. Caso Nro. 2: Sistema de Administración de Venta de Boletos

1.1 Enunciado del Caso

El presente proyecto toma en consideració n el Sistema Administrativo de Venta de Boletos y

Recepció n de Encomiendas para la empresa Mega Bus tomando como base los procesos de
dichos requerimientos de la empresa, con el fin de que pueda servir de referencia para
desarrollar las actividades requeridas.

Así mismo se espera incorporar mó dulos que lleven el control de dichos procesos y que sean
de ayuda para la agilizació n de los mismos.

Cabe mencionar algunos puntos para el desarrollo del sistema:

 Se buscará implementar los procesos de ventas de boletos, recepció n y entrega

de encomiendas de modo que se evalú e de una manera apropiada y ahorrando el mayor
tiempo posible para el mejor control de los mismos.
 Se implementará una base de datos de modo que contendrá la informació n
necesaria para los buses y furgones para el control institucional de modo que se tenga
una informació n clara y detallada de los buses existentes en la empresa y a la vez tener
informació n de los furgones para el envío de encomiendas.
 Se hará n pruebas funcionales antes de la entrega del sistema, para ello se
requerirá la participació n de los usuarios del sistema, en este caso los gerentes de Mega
Bus.
 Una vez concluido el sistema, se dará una asesoría a los futuros usuarios del
mismo, de modo que estén aptos para usar el sistema.

Descripción del Sistema

El presente Sistema a desarrollar contará con 6 mó dulos; los cuales será n:

 Mó dulo de Usuario
 Mó dulo de Reportes
 Mó dulo de Encomiendas
 Mó dulo de Ventas
 Mó dulo de Itinerarios
 Mó dulo de Mantenimiento

Con la finalidad de soportar los requerimientos de los usuarios y asegurar el afinamiento y

crecimiento del sistema, se recomienda la construcció n de un sistema web cliente/servidor,
en tres capas y tres niveles, usando herramientas y tecnologías de componentes.

En una aplicació n de estas características la interfaz visual, la ló gica de negocios y los datos
son elementos conceptualmente separados. Se utilizará el soporte brindado por el
Administrador de Base de Datos SQL Server

Página 4
 Requerimientos – Arquitectura de Software

1.2 Propuesta de Caso de Uso del Sistema

Generar Reporte de Pasajes

Mantener Usuario (f rom Casos de Uso)
(f rom Casos de Uso)

Generar Reporte de Encomienda

(f rom Casos de Uso) Registrar Entrega de Encomienda
(f rom Casos de Uso)

MantenerFurgon
Mantener Buses (f rom Casos de Uso)
Administrador
(f rom Casos de Uso)
(f rom Actores)

Asignar Itinerario de Buses

(f rom Casos de Uso)

Mantener Ruta
Almacenero
Registrar Venta de Boletos (f rom Casos de Uso)
via_Web (f rom Actores)
(f rom Casos de Uso)

Asignar Itinerario de Furgones

Cliente (f rom Casos de Uso)
(f rom Actores)

Registro Via Web

Registrar Entrega de encomienda
(f rom Casos de Uso)
(f rom Casos de Uso)

Registrar Venta de boletos por Vendedor

Ventanilla Loguear Usuario
(f rom Actores)
Usuario
(f rom Casos de Uso) (f rom Casos de Uso)
(f rom Actores)

Página 5
 Requerimientos – Arquitectura de Software

3. Caso Nro. 3: Sistema de Hostelería

1.3 Enunciado del Caso

Se desea implementar un sistema para la administració n de una hostería. Esta posee

habitaciones individuales, dobles o grupales (de hasta 8 personas). Un cliente debe poder
hacer una reserva vía internet a cualquiera de estas habitaciones por un periodo de tiempo
determinado. Se deberá poder ver una foto ilustrativa de la habitació n al momento de hacer
la reserva. Al efectuar la misma se deberá obviamente ingresar los datos personales del
interesado incluyendo indefectiblemente algú n teléfono para ubicarlo. Si 4 horas después de
la supuesta fecha de check-in el cliente no se ha presentado, el sistema deberá informar de
esta situació n al empleado de recepció n del hotel junto al teléfono de la persona que no se
presentó . Las reservas también pueden hacerse telefó nica o personalmente con un empleado
de recepció n, quien puede cancelarlas una vez pasadas las 4 horas mencionadas
anteriormente. Al efectuar una cancelació n el sistema deberá enviar un mail al cliente que no
se presentó para notificar de la situació n (só lo si lo incluyo en sus datos personales).

Ademá s de reservas, evidentemente el sistema debe de poder llevar el control de las

habitaciones ocupadas (en cualquier momento se puede consultar quién está hospedado en
qué habitació n junto a todos sus datos), junto a las bebidas y/o snacks que hayan consumido
del minibar de la habitació n en cuestió n (só lo en el caso de las habitaciones simples o dobles.
Las grupales no cuentan con minibar). Para ello el personal de limpieza se ocupa de darle
una lista detallada al empleado de recepció n sobre el consumo del huésped en el día
(artículos faltantes), para que este las ingrese en el sistema. El sistema también deberá llevar
el control de que habitaciones fueron hechas en el día y cuales aú n faltan por preparar. Esta
informació n la carga cada empleado de limpieza (só lo para las habitaciones a las que fue
asignado) de cada turno (mañ ana, tarde o noche) para que su reemplazo sepa que
habitaciones visitar. La asignació n de turnos y habitaciones por empleado las efectú a el jefe
de personal.

Al terminar la estadía (o en cualquier otro momento anterior) el huésped puede efectuar el

check-out a través del control remoto de su televisor (nuevamente só lo para habitaciones
individuales o dobles) donde se le notificará del monto a pagar luego en la recepció n del
hotel. El empleado del mismo obtiene inmediatamente una factura impresa con el detalle de
lo consumido en la estadía, junto al total a pagar por parte del huésped.

El cliente también puede optar por ir directamente a la recepció n y que el empleado sea
quién liquide su cuenta. Debe de reflejarse en el sistema de reservas de habitaciones si un
huésped decide dar por terminada su estadía antes de lo pactado, ofreciéndose su habitació n
(o lugar en una grupal) como disponible.

Página 6
 Requerimientos – Arquitectura de Software

1.4 Propuesta del Caso de Uso del Sistema

<<communicate>> <<communicate>>

<<communicate>>
Gestionar Habitación
Empleado
recepción

<<include>>
<<communicate>>
<<communicate>>
Login
<<communicate>>

<<communicate>>

<<include>>
Consultar Habitación

<<communicate>>

Gestionar Reserva
Cliente <<include>>
(from <Use Case Name>)
(f rom Actors) <<include>>

<<include>>

Consultar Cliente Control de habitaciones

<<include>>
Registrar Pago

Gestionar Cliente

Página 7
 Requerimientos – Arquitectura de Software

4. Caso Nro. 4: Sistema de Clínica “Salud.com”

1.5 Enunciado del Caso

La Clínica “Salud.com”, se realizan examen clínico, el propó sito es controlar el proceso de

aná lisis clínico del paciente, el cual surge a raíz de los problemas encontrados. Este control
implica llevar el registro de los aná lisis realizados a los pacientes.

El Sistema SIGACLI permitirá realizar lo siguiente:

 Consultar resultados vía web

 Buscar paciente
 Entrega de resultados
 Generar reporte
 Ingresar resultados
 Mantener historia clínica
 Mantener cita
 Login

1.6 Propuesta de Caso de Uso del Sistema

<<communicate>>

Ingresar Resultados
Laboratorista <<communicate>>
(from Ingresar Resultados)
(f rom Act...

Entregar Resultados
Asistente
(from Entregar Resultados)
(f rom Act...

<<communicate>>

<<include>>
Mantener Cita
Recepcionista
(from Mantener Cita)
(f rom Act...

<<include>>
Buscar Paciente
(from Buscar Paciente)
<<communicate>>

Mantener Historia Clinica

Enfermera
(from Mantener Historia Clinica)
(f rom Act...

Consultar Resultados Web

Paciente
(from Consultar Resultados Web)
(f rom Act...

<<communicate>>

Jefe de Laboratorio Generar Reportes

(f rom Actors) (from Generar Reportes)

<<communicate>>

Logueo
Usuario
(from Logueo)
(f rom Actors)

Página 8
 Requerimientos – Arquitectura de Software

5. Caso Nro. 5: Sistema de RRHH EMAPE

1.1 Enunciado del Caso
La Empresa EMAPE en la actualidad no cuenta con sistema de RRHH, el cual realiza todos sus
procesos de negocio de forma manual, guardando sus datos en archivadores y hojas de Excel,
lo que muchas veces lleva a duplicació n de informació n, así como a perdida de informació n y
demoras en la atenció n a sus clientes por no contar con documentos a la mano.

Es por esta razó n, por la cual se desea implementar un sistema que permita a la empresa
EMAPE la automatizació n de sus procesos má s importantes, y que actualmente representa un
inconveniente para la oficina de RRHH. Permitirá también un mejor y má s eficiente control de
los diferentes procesos que se realizan, brindando una mayor rapidez en el manejo de la
informació n, así como una mejor calidad de la misma.

El Sistema de RRHH será desarrollado bajo una arquitectura que corresponde a Sistemas
Centralizado (Aplicaciones Web) segú n el está ndar J2EE.

Para desarrollar esta aplicació n se ha propuesto trabajar con el servidor web TOMCAT y
DBMS: MySQL Server 12.0, lo que significa que la aplicació n debe correr con este motor y estar
abierta a trabajar con “3 Capas” DBMS a futuro. En la cual residirá la Base de Datos y los
diferentes objetos creados para el Sistema (tablas, índices, procedimientos almacenados,
funciones, vistas).

1.2 Propuesta de Caso de Uso del Sistema

Login <<include>>
(from Caso de Uso)

Evaluar Curriculum Vitae

GerenteGeneral
(from Caso de Uso)
(f rom Actors)
Usuario
(f rom Actors) <<include>>

Generar Trabajador Buscar Postulante

AsistenteRRHH
(from Caso de Uso) (from Included Use Cases)
(f rom Actors)

<<include>>

Redactar Contrato Legalizado

Abogado_
(from Caso de Uso)
(f rom Actors)

Página 9
 Requerimientos – Arquitectura de Software

6. Caso Nro. 6: Sistema de Biblioteca

6.1 Enunciado del Caso

La Universidad XYZ va desarrollar un sistema de gestió n de préstamos de libros, dicho sistema
tiene los procesos de reserva, préstamo y devolució n de libros.

Para desarrollar esta aplicació n se ha propuesto trabajar con el servidor web TOMCAT y
DBMS: MySQL Server 12.0, lo que significa que la aplicació n debe correr con este motor y estar
abierta a trabajar con “3 Capas” DBMS a futuro. En la cual residirá la Base de Datos y los
diferentes objetos creados para el Sistema (tablas, índices, procedimientos almacenados,
funciones, vistas).

6.2 Propuesta de Caso de Uso del Sistema

Página 10
 Requerimientos – Arquitectura de Software

7. Caso Nro. 7: Campo Fe Asociados

1.1 Enunciado del Caso

La empresa de Campo Fe, tiene 10,000 asociados y pretende desarrollar un sistema donde los
socios interactú en con diferentes servicios, se realicen pagos en línea, reservas de alojamiento
y ofrece diferentes productos.

Para desarrollar esta aplicació n se ha propuesto trabajar con el servidor web TOMCAT y
DBMS: MySQL Server 12.0, lo que significa que la aplicació n debe correr con este motor y estar
abierta a trabajar con “3 Capas” DBMS a futuro. En la cual residirá la Base de Datos y los
diferentes objetos creados para el Sistema (tablas, índices, procedimientos almacenados,
funciones, vistas).

1.2 Propuesta de Caso de Uso del Sistema

Página 11
 Requerimientos – Arquitectura de Software

8. Caso Nro. 8: Control de Asistencia de la Universidad UNFV

8.1 Enunciado del Caso
La universidad UNFV tiene que desarrollar un sistema de control de asistencias, este sistema
maneja el registro de personal, asistencia y reportes.

Para desarrollar esta aplicació n se ha propuesto trabajar con el servidor web TOMCAT y
DBMS: MySQL Server 12.0, lo que significa que la aplicació n debe correr con este motor y estar
abierta a trabajar con “3 Capas” DBMS a futuro. En la cual residirá la Base de Datos y los
diferentes objetos creados para el Sistema (tablas, índices, procedimientos almacenados,
funciones, vistas).

8.2 Propuesta de Caso de Uso del Sistema

9. Caso Nro. 9: Control de Inventario

9.1 Enunciado del Caso
La empresa XYZ, necesita gestionar el inventario de los productos y gestionar sus proveedores, por
lo tanto, está desarrollando un sistema de informació n que debe manerar diferentes procesos
asociados al inventario.

Para desarrollar esta aplicació n se ha propuesto trabajar con el servidor web TOMCAT y DBMS:
MySQL Server 12.0, lo que significa que la aplicació n debe correr con este motor y estar abierta a
trabajar con “3 Capas” DBMS a futuro. En la cual residirá la Base de Datos y los diferentes objetos
creados para el Sistema (tablas, índices, procedimientos almacenados, funciones, vistas).

9.2 Propuesta de Caso de Uso del Sistema

Página 12
 Requerimientos – Arquitectura de Software

10. Caso Nro.10: Sistema de Gestión Académica para Instituto

10.1 Enunciado del Caso
El instituto Federico, necesita implementar un sistema de gestió n de académica, que presente
diferentes mó dulos desde admisió n, matricula, asistencia, notas y monitoreo.

Para desarrollar esta aplicació n se ha propuesto trabajar con el servidor web TOMCAT y DBMS:
MySQL Server 12.0, lo que significa que la aplicació n debe correr con este motor y estar abierta a
trabajar con “3 Capas” DBMS a futuro. En la cual residirá la Base de Datos y los diferentes objetos
creados para el Sistema (tablas, índices, procedimientos almacenados, funciones, vistas).

10.2 Propuesta de Caso de Uso del Sistema

Página 13
 Requerimientos – Arquitectura de Software

11. Supuestos
- La informació n proporcionada, fue recogida de un levantamiento de informació n,
entrevistas y relevamiento.
- Los casos de uso propuestos, es el resultado del aná lisis del levamiento de informació n e
identificació n de actores y requerimientos, de su Analista de Sistema.
- Se asume que los sistemas tendrá n estos mó dulos transversales, reportes, mantenimiento,
seguridad, administració n
- Se asume que todos los sistemas será n webs
- Se asume que la propuesta de los casos de uso, es el resultado del aná lisis TO-BE, es decir
que ya se hizo el AS-IS y aná lisis GAP.
- Se asume que tiene que realizar ingeniería reversa para todos los casos planteados
- Se asume que tiene conocimiento en la lectura de Casos de Uso de Sistema

Página 14