Facultad de Ingeniera Civil de Sistemas y de Arquitectura

Escuela Profesional de Ingeniera de Sistemas

Curso: Taller de Programacin

Web Application - Spring MVC 4 MyBatis 3

Caso de Estudio FastFood

FastFood es una cadena de establecimientos que opera en el pas desde hace 10 aos
liderando el sector de venta de pizzas en general, y bajo su lema El cliente siempre tiene una
pizza FastFood cuando gusta de ella, iniciando sus operaciones como un negocio familiar de
los Gonzles Konde en donde cada uno de los miembros ha venido desempeando alguna
funcin dentro de la misma tal como es el caso de Jorge Gonzles Konde quien ha venido
asumiendo el rol de la administracin global de la empresa.
En meses recientes, debido al auge y crecimiento de la empresa y teniendo en consideracin la
presencia de importantes competidores en el mercado como Pizzato y PizzaFood, es que se
hace necesario disear nuevas estrategias empresariales que le permitan seguir creciendo
como lo han venido haciendo manteniendo su condicin de liderazgo en el mercado nacional;
por ello, la familia consider necesario incorporar un profesional con la experiencia suficiente en
el sector que les asistiera en este proceso de cambio, participando de forma activa en la gestin
de la empresa, habindose establecido contacto con Juan Prez.
Juan Prez, recientemente designado como administrador general de la empresa, en su primer
contacto con la misma ha identificado oportunidades de mejora y ha formulado una serie de
iniciativas que le ayudaran a la empresa a continuar con su ritmo de crecimiento, entre las
cuales cabe destacar la implementacin del servicio de delivery para atender a un sector
importante del mercado de una forma ms eficiente y oportuna. As mismo, considera que el
uso de tecnologas y sistemas de informacin es un aspecto de especial importancia para las
organizaciones y por consiguiente en este caso particular; es por ello, que en coordinacin con
el rea de sistemas ha decidido emprender proyectos de TI/SI con el propsito mejorar la
eficiencia de los procesos que se desarrollan como parte del negocio, principalmente en las
reas en donde se han identificado oportunidades de mejora.
En este sentido, Carlos Daz responsable del rea de sistemas ha formulado una serie de
iniciativas en materia de TI/SI con el propsito de apoyar la estrategia empresarial formulada
por la administracin de la empresa; por ello, atendiendo a la iniciativa de implementar el
servicio de delivery en la empresa se ha formulado un proyecto para la construccin de una
sistema informtico de soporte que contribuya a brindar un servicio eficiente y oportuno a los
clientes y que se integre al sistema de informacin que viene operando en la empresa,
habiendo sido denominado e-Delivery.
La propuesta formulada de e-Delivery consiste en un sistema de informtico va web que
permite el registro de pedidos de los clientes as como el despacho de los mismos..

El usuario puede interactuar con el sistema con un rol determinado: administrador del sistema,
operador de recepcin de pedido, operador de despacho de pedido o administrador del negocio.
-

Administrador del sistema

El usuario puede registrar la alta de un nuevo usuario, indicando los acceso que tiene
permitido.

Operador de recepcin de pedido

El usuario puede registrar la recepcin de un pedido, consultar los pedidos por confirmar, y
registrar la confirmacin, modificacin o anulacin de un pedido previamente seleccionado.

Operador de despacho de pedido

El usuario puede consultar los pedidos por despachar, y registrar el despacho de un pedido
previamente seleccionado.

Administrador del negocio

El usuario puede consultar el nivel de ventas, en forma tabular y grfica.

Para efectos de inicio de operacin del sistema, se tiene registrado de forma determinada un
usuario con acceso permitido como Administrador del sistema; con la cual se podr dar de
alta otros usuarios del sistema.

create table tb_usuario

(
tb_usuario_id serial not null,
tb_usuario_cod character(4) not null,
tb_usuario_apepat character varying(50) not null,
tb_usuario_apemat character varying(50) not null,
tb_usuario_nom character varying(50) not null,
tb_usuario_corele character varying(50) not null,
tb_usuario_usenam character varying(50) not null,
tb_usuario_pas character varying(50) not null,
constraint pk_usuario primary key(tb_usuario_id),
constraint unq_usuario_cod unique(tb_usuario_cod),
constraint unq_usuario_apepatapematnom unique(tb_usuario_apepat,tb_usuario_apemat,tb_usuario_nom),
constraint unq_usuario_corele unique(tb_usuario_corele),
constraint unq_usuario_usenampas unique(tb_usuario_usenam,tb_usuario_pas),
constraint chk_usuario_id check(tb_usuario_id > 0),
constraint chk_usuario_cod check(tb_usuario_cod similar to '[0-9][0-9][0-9][0-9]')
);
create table tb_acceso
(
tb_acceso_id serial not null,
tb_acceso_fecini date not null,
tb_acceso_fecter date not null,
tb_acceso_rol character(1) not null, -- Puede ser: R(Operador de recepcin de pedidos), D(Operador de
despacho de pedidos), A(Administrador del negocio)
constraint pk_acceso primary key(tb_acceso_id),
constraint chk_acceso_fecini check(tb_acceso_fecini <= cast(now() as date)),
constraint chk_acceso_fecter check(tb_acceso_fecter <= cast(now() as date)),
constraint chk_acceso_fecinifecter check(tb_acceso_fecini <= tb_acceso_fecter),
constraint chk_acceso_rol check(tb_acceso_rol in ('R','D','A'))
);

create table tb_producto

(
tb_producto_id serial not null,
tb_producto_cod character(4) not null,
tb_producto_nom character varying(50) not null,
tb_producto_preuni decimal(10,2) not null,
constraint pk_producto primary key(tb_producto_id),
constraint unq_producto_cod unique(tb_producto_cod),
constraint unq_producto_nom unique(tb_producto_nom),
constraint chk_producto_id check(tb_producto_id > 0),
constraint chk_producto_cod check(tb_producto_cod similar to '[0-9][0-9][0-9][0-9]'),
constraint chk_producto_preuni check(tb_producto_preuni > 0.00)
);
create table tb_ciudad
(
tb_ciudad_id serial not null,
tb_ciudad_cod character(4) not null,
tb_ciudad_nom character varying(50) not null,
tb_ciudad_pretel character(2) not null,
constraint pk_ciudad primary key(tb_ciudad_id),
constraint unq_ciudad_cod unique(tb_ciudad_cod),
constraint unq_ciudad_nom unique(tb_ciudad_nom),
constraint unq_ciudad_pretel unique(tb_ciudad_pretel),
constraint chk_ciudad_id check(tb_ciudad_id > 0),
constraint chk_ciudad_cod check(tb_ciudad_cod similar to '[0-9][0-9][0-9][0-9]'),
constraint chk_ciudad_pretel check(tb_ciudad_pretel similar to '[0-9][0-9]')
);
create table tb_pedido
(
tb_pedido_id serial not null,
tb_pedido_fechor timestamp not null default now(),
tb_pedido_cli character varying(50) not null,
tb_pedido_dir character varying(50) not null,
tb_pedido_telfij character(6) not null,
tb_pedido_imp decimal(10,2) not null,
tb_pedido_pag decimal(10,2) not null,
tb_pedido_vue decimal(10,2) not null,
tb_pedido_est character(1) not null default 'P',
tb_ciudad_id integer not null,
tb_usuario_id integer not null,
constraint pk_pedido primary key(tb_pedido_id),
constraint fk_ciudad_pedido foreign key(tb_ciudad_id) references tb_ciudad(tb_ciudad_id),
constraint fk_usuario_pedido foreign key(tb_usuario_id) references tb_usuario(tb_usuario_id),
constraint chk_pedido_id check(tb_pedido_id > 0),
constraint chk_pedido_fechor check(tb_pedido_fechor <= now()),
constraint chk_pedido_telfij check(tb_pedido_telfij similar to '[0-9][0-9][0-9][0-9][0-9][0-9]'),
constraint chk_pedido_imp check(tb_pedido_imp > 0.00),
constraint chk_pedido_pag check(tb_pedido_pag > 0.00),
constraint chk_pedido_vue check(tb_pedido_vue >= 0.00),
constraint chk_pedido_est check(tb_pedido_est in ('P','C','D'))-- P: Pedido por confirmar, C: Pedido
confirmado, D: Pedido despachado
);
create table tb_detallepedido
(
tb_detallepedido_id serial not null,
tb_detallepedido_can decimal(10,2) not null,
tb_detallepedido_preuni decimal(10,2) not null,
tb_detallepedido_subtot decimal(10,2) not null,
tb_pedido_id integer not null,
tb_producto_id integer not null,
constraint pk_detallepedido primary key(tb_detallepedido_id),
constraint fk_pedido_detallepedido foreign key(tb_pedido_id) references tb_pedido(tb_pedido_id),
constraint fk_producto_detallepedido foreign key(tb_producto_id) references tb_producto(tb_producto_id),
constraint chk_detallepedido_id check(tb_detallepedido_id > 0),
constraint chk_detallepedido_can check(tb_detallepedido_can > 0.00),
constraint chk_detallepedido_preuni check(tb_detallepedido_preuni > 0.00),
constraint
chk_detallepedido_subtot
check(tb_detallepedido_subtot
=
(tb_detallepedido_can
tb_detallepedido_preuni))
);

Requerimientos Funcionales
Se requiere que el sistema tenga una pgina principal de bienvenida, en donde los usuarios
puedan acceder al formulario de inicio de sesin.
Inicio de Sesin
El formulario de inicio de sesin debe permitir al usuario ingresar su nombre de usuario,
contrasea y el rol con el que desea iniciar sesin (Operador de recepcin de pedido, operador
de despacho de pedido o administrador del negocio), en base a lo cual el sistema debe validar
si el usuario tiene el acceso autorizado en la fecha en la que se quiere acceder.
Si el usuario tiene el acceso permitido, entonces el sistema segn sea el rol con que est
accediendo le permitir utilizar determinada funcionalidad al usuario, segn se detalla luego:
En este mismo formulario debe existir la opcin para recuperar la contrasea, en caso el
usuario la haya olvidado. Para ello, el sistema le solicitar al usuario que ingrese su correo
electrnico, luego de lo cual el sistema determinar a que usuario corresponde dicho correo y
obtendr del mismo la contrasea que ser remitida al correo electrnico indicado.

Alta de Usuario
Rol: Administrador del sistema

El formulario de alta de usuario, debe permitir al usuario ingresar los apellidos y nombres,
correo electrnico, y la lista de accesos en donde para cada acceso se debe indicar el periodo
(intervalo de fechas) y el rol con el cual puede acceder el nuevo usuario en el periodo de tiempo
indicado por el intervalo de fechas. Luego de registrado el nuevo usuario, el sistema debe
generar un nombre de usuario y una contrasea que debern ser remitidos al correo electrnico
del nuevo usuario. Es necesario precisar que la contrasea debe quedar registrada en modo no
legible.
Recepcin de Pedido
Rol: Operador de recepcin de pedido

El formulario de recepcin de pedido, debe permitir al usuario ingresar el nombre completo del
cliente, la ciudad donde se va a entregar el pedido, la direccin a donde se va a entregar el
pedido, el telfono fijo del domicilio indicado (que permitir confirmar el pedido), la lista de
productos y cantidades de los mismos, la cantidad de dinero con la que el cliente va a pagar el
importe total del pedido.
Para cada producto, el sistema debe mostrar el precio unitario, as como tambin debe calcular
automticamente el subtotal por cada producto en base a la cantidad ingresada y el precio
unitario de los mismos; debiendo tambin calcular el importe total del pedido y en base a ello el
vuelto que deber entregar al cliente a la entrega del pedido en el domicilio consignado.
En lo que respecta a la ciudad donde se va a entregar el pedido, sta debe ser seleccionada de
una lista desplegable que muestra las ciudades que se tienen registradas. No se requiere
implementar una opcin para registrar nuevas ciudades.
As mismo, en lo que respecta a los productos, stos se deben seleccionar de un catlogo que
muestra los productos que se tienen registrados. No se requiere implementar una opcin para
registrar nuevos productos.

Confirmacin de Pedido
Rol: Operador de recepcin de pedido

El formulario de confirmacin de pedido, debe permitir al usuario consultar la lista de los

pedidos que han sido recepcionados y estn pendientes de ser confirmados, segn el periodo
(intervalo de fechas) ingresado por el usuario; debiendo presentarse ordenados por la fecha y
hora en que han sido registrados.
As mismo, el mismo formulario debe tener un botn cuya seleccin permita cambiar el estado
de un pedido previamente seleccionado, de P: Pedido por confirmar a C: Pedido confirmado.
En caso de que el pedido no se confirme, se debe tener un botn para anular un pedido
cambiando su estado a A: Pedido anulado.
En caso el cliente decida modificar su pedido, el usuario debe tener un botn cuya seleccin
permita editar un pedido previamente seleccionado.
Despacho de Pedido
Rol: Operador de despacho de pedido

El formulario de despacho de pedido, debe permitir al usuario consultar la lista de los pedidos
que han sido confirmados y estn pendientes de ser despachados, segn el periodo (intervalo
de fechas) y la ciudad ingresados por el usuario; debiendo presentarse ordenados por la fecha y
hora en que han sido registrados.
As mismo, el mismo formulario debe tener un botn cuya seleccin permita cambiar el estado
de un pedido previamente seleccionado, de C: Pedido confirmado a D: Pedido despachado.
Finalmente, el usuario debe tener una opcin para imprimir un ticket respecto de un pedido
previamente seleccionado, que se entregar al cliente al momento de la entrega del pedido,
como un comprobante por la venta. En el ticket se presentar los datos detallados del pedido.
Monitoreo de Ventas
Rol: Administrador del negocio

El formulario de monitoreo de ventas, debe permitir consultar en forma tabular y grfica los
niveles de venta por ciudad y/o producto en el tiempo. Para ello el usuario debe tener la
posibilidad de seleccionar el modo de consulta: por ciudad, por producto, por ciudad y producto;
as como tambin debe tener la posibilidad de seleccionar el nivel de detalle respecto del tiempo
(ao, trimestre o mes).
Teniendo en consideracin vuestras competencias como profesional en tecnologas y sistemas
de informacin, el rea de sistemas lo requiere a usted para implementar el proyecto descrito.