FACULTAD DE INGENIERÍA SISTEMAS

ASIGNATURA:

Taller de Programación (C)

DOCENTE:

Ing. Omar Saavedra Salazar

NOMBRE DEL SISTEMA:

E-Delivery

GRUPO:

Maldonado Vásquez Alexis

Martinez Cancino Felipe
Zaldivar Risco Jaime
Zavala Bravo Alex
 1

ANALISIS DEL SISTEMA

E-DELIVERY

PROPUESTA DE LA EMPRESA:
 Se trata de realizar un sistema informático que se encargará de gestionar
el funcionamiento de delivery de la Empresa FASTFOOD, para ello se deberá
tratar una cierta información y ser capaz de realizar una serie de operaciones
sobre ésta. Consiste en construir un sistema informático llamado e-Delivery
que permite el registro de pedidos de los clientes así como el despacho de
los mismos, teniendo en consideración que los clientes pueden realizar sus
pedidos vía telefónica o por la web. Por ello, e-Delivery comprende la
construcción de un módulo de escritorio para el registro de pedidos vía
telefónica, y otro módulo web para el registro de pedidos de forma personal
por parte del cliente mismo que requiere del producto.

1. DESCRIPCIÓN DEL PROCESO DE NEGOCIO

Flujo del proceso

1. Un cliente podrá realizar un pedido en cualquiera de las dos

modalidades en el sistema proporcionando sus datos personales:
nombre completo, dirección, referencia de dónde vive y teléfono.

2. Existirán dos modalidades para registrar el pedido: vía telefónica,

donde el cliente será atendido por un vendedor que registrará su
pedido en el sistema con los datos proporcionados. O vía web donde
el cliente mismo registrará su pedido en el sistema completando un
formulario con sus datos personales, donde además elegirá la
sucursal dependiendo de dónde vive. En ambas modalidades deberá
indicar el monto de dinero con el que pagará, y también elegir la
pizza y cantidad que deseará.

3. El pedido registrado en el sistema es un “Pedido por confirmar” que

tendrá que ser confirmado por un vendedor para continuar con el
proceso. Para ello el vendedor tendrá que realizar una llamada al
número de teléfono que brindó el cliente al realizar su pedido en
cualquier modalidad.

4. El cliente podrá aceptar o cancelar la confirmación de su pedido

mediante la llamada telefónica hecha por el vendedor. En caso de
no confirmar, el estado del pedido será “Pedido no confirmado” y
termina el proceso de ese pedido; caso contrario será “Pedido
 confirmado” y se proseguirá con el proceso al despachador de
pedidos.

5. El despachador podrá anular el pedido en caso no pueda ser

despachado, y el estado será “Pedido anulado”, lo cual termina su
proceso y no será entregado. En caso de confirmarse su despacho
será “Pedido despachado”.

6. El pedido despachado tendrá un voucher impreso que será

entregado junto con el producto al cliente. El cliente pagará por el
pedido en el momento que lo reciba, y en caso de tener devolución
de dinero se le dará.

Políticas

1. El horario de atención de delivery será las 24 horas todos los días

del año para seguir liderando el sector de ventas de pizzas.

2. La empresa mejorará continuamente su calidad de servicio de

delivery, comprometiéndose a cumplir con la entrega de todos los
pedidos a los clientes.

3. Los empleados deberán asistir a un curso de capacitación al

momento de su contratación.

4. El operador de ventas deberá saludar, utilizar un vocabulario serio,

brindar trato justo y esmerado a todos los clientes en sus llamadas,
con el fin de lograr la satisfacción y atracción del cliente.

5. Todos los integrantes de la empresa deberán realizar su trabajo con

el mayor respeto y ética posibles.

6. Nuestro producto cumple con todos los estándares de calidad.

7. El dinero que se pagará por el pedido será en el momento de la

entrega del producto.

8. El producto llegará a las manos del cliente de 20 a 40 minutos

hábiles después de realizar el pedido, sino es así no se cobrará por
el pedido.
9. El empleado no se quedará con ningún dato personal de los clientes,
estos son sólo para uso de la empresa.

10. Ningún empleado podrá hacer llamadas personales.

11. Manejar precios accesibles para el consumidor.

12. La empresa cumple con todas las normas de legalidad.

Modelo de proceso

BD_EMPRESA
2. Requerimientos funcionales y no funcionales

2.1. Requerimientos funcionales

Nuestro objetivo comprende desarrollar un sistema de gestión de pedidos

de delivery basado en dos módulos que permita automatizar parte del
proceso generado por un cliente: registrar su pedido, confirmarla,
despacharla, etc.

El módulo web servirá para registrar los pedidos realizados por los clientes
por internet, en la base de datos. Dentro de cada pedido se sabrá que
producto se ha elegido y la cantidad.

El módulo de escritorio está diseñado para que el usuario administrador

pueda gestionar las sucursales, los usuarios y productos. También está
diseñado para los usuarios (vendedor y despachador) que actuarán
directamente con los pedidos de los clientes.

Existirán tres tipos de usuarios a saber:

 Administrador: Administración de sucursales, usuarios y productos.

 Vendedor: Recepción de pedidos por teléfono, y confirmación de los
mismos registrados en cualquier modalidad.
 Despachador: Despacho de los pedidos confirmados

2.1.1. Requerimientos funcionales de los usuarios

A continuación se presentan los requisitos funcionales de cada tipo de

usuario, con fin de detallar los roles o funcionalidades de cada uno de ellos
en el proyecto.

Usuario administrador.
Acciones que puede realizar:
o Crear, actualizar o eliminar sucursales.
-Crear nuevas sucursales con un nombre a la base de datos para
que pueda tener usuarios.
-Actualizar/modificar el nombre en caso de algún error o sea
requerido.
-Eliminarla de la base de datos.
 o Crear, actualizar o eliminar usuarios.
-Crear nuevos usuarios en la base de datos para que puedan
atender los pedidos.
-Actualizar/modificar los datos de los usuarios.
-Eliminar usuarios de la base de datos que ya no pertenezcan a
la empresa.

o Crear, actualizar o eliminar productos.

-Crear nuevos productos en la base de dato, en este caso
diferentes tipos de pizzas para que se puedan vender a los
clientes.
-Actualizar/modificar datos de los productos.
-Eliminar productos de la base de datos que ya no serán
vendidos.

Acciones que no puede realizar:

-El administrador no interviene en el proceso de los pedidos realizados
por los clientes.
o Recepcionar pedidos por teléfono.
o Confirmar pedidos.
o Despachar pedidos.

Usuario Vendedor.
Acciones que puede realizar:
o Recepcionar pedidos por teléfono.
-Registrará los pedidos recibidos vía telefónica.

o Confirmar pedidos.
-Confirmará los pedidos registrados en el sistema en cualquier
modalidad, para ello realiza una llamada de confirmación al
cliente.
Cambia el estado de los pedidos: “Pedido por confirmar”,
“Pedido confirmado” o “Pedido no confirmado”.

Acciones que no puede realizar:

o Administrar sucursales, usuarios y productos.
o Despachar pedidos.

Usuario Despachador.
Acciones que puede realizar:
 o Despachar pedidos.
-Despachará los pedidos confirmados.
Cambia el estado de los pedidos: “Pedido despachado” o
“Pedido anulado”.

Acciones que no puede realizar:

o Administrar sucursales, usuarios y productos.
o Recepcionar pedidos por teléfono.
2.2.2. Requerimientos funcionales de los clientes

Cliente.
Acciones que puede realizar:
o Registrar pedido por internet completando el formulario.

Acciones que no puede realizar:

o Modificar los detalles de los productos (nombre, precio)

2.1.3. Vistas de casos de uso

A. Vista de casos de uso para usuario administrador:

Crear Sucursal

Actualizar Sucursal

Eliminar Sucursal

Crear Usuario

Actualizar Usuario

Eliminar Usuario

Crear Producto

Administrador
Actualizar Producto

Eliminar Producto
 1. Caso de uso: Crear Sucursal

2. Caso de uso: Actualizar Sucursal

3. Caso de uso: Eliminar Sucursal

4. Caso de uso: Crear Usuario

5. Caso de uso: Actualizar Usuario

6. Caso de uso: Eliminar Usuario

7. Caso de uso: Crear Producto

8. Caso de uso: Actualizar Producto

9. Caso de uso: Eliminar Producto

B. Vista de casos de uso para usuario vendedor:

Registrar Pedido por

Teléfono

Vendedor

Confirmar Pedido

1. Caso de uso: Registrar Pedido por Teléfono

2. Caso de uso: Confirmar Pedido

C. Vista de caso de uso para usuario despachador:

Despachar Pedido

Despachador
 1. Caso de uso: Despachar Pedido

D. Vista de caso de uso para cliente:

Registrar Pedido
por Internet

Cliente

1. Caso de uso: Registrar Pedido por Internet

E. Vista de caso de uso para los pedidos.

2.2. Requerimientos no funcionales

Los siguientes requerimientos no funcionales no forman parte de la

funcionalidad del software, pero son importantes ya que son restricciones
que debe cumplir el sistema

A continuación se muestran los requerimientos no funcionales de este

software:

-Controlar todas las entradas realizadas por los usuarios.

-La interfaces deberán ser altamente intuitivas y de fácil manejo para
cualquier tipo de usuario.
-El sistema debe impedir el acceso a personas no autorizadas mediante
mecanismos de seguridad.

Sw mínimo
-Sistema operativo Windows XP, 7, 8, 8.1.
-Se utilizará PostgreSQL para la manipulación de la base de datos nuestro
sistema.

Hw mínimo
-Microprocesador Intel Core i3 o similar
-Memoria RAM de 50 MB.
-Módem de 128 Kbps
3. Modelo conceptual de base de datos

Diagrama Entidad/Relación NOTACION BARKER

4. Diseño de interfaces graficas de usuario

A continuación se mostraran las capturas de pantalla más importantes del

sistema correspondiente a los diferentes usuarios del sistema.

4.1. Interfaces

A. Usuario administrador
B. Usuario vendedor

C. Usuario despachador
5. Diseño de base de datos

A partir de las entidades y sus interrelaciones, la base de datos constará de

5 tablas. Estas tablas contendrán toda la información de las sucursales,
usuarios, pedidos, productos y detalle de los pedidos.

Se pasa a detallar el contenido principal de cada una de ellas, el motivo de

las relaciones y los tipos de datos más significativos. En la figura se muestran
las tablas gráficamente.
5.1. Contenido de las tablas de la base de datos

Tabla – “SUCURSAL”

-Sucursal es el nombre seleccionado para la tabla de las sucursales de la

empresa.

-Detalle de los campos de sucursal a continuación:

 Cod_Sucursal: Código único de la tabla. Es un char.
 Nombre_Sucursal: Nombre con la cual se identifica la sucursal. Es
un varchar.

Tabla – “USUARIO”

Tabla – “PEDIDO”

-Pedido es el nombre seleccionado para la tabla donde se registrarán los

pedidos realizados.

-Detalle de los campos de pedido a continuación:

 Id_Pedido: Identificador unico de la tabla auto-incremental. Es un
número.
 Cliente:
 Dirección:
 Referencia:
 Teléfono:

Tabla – “DETALLE”

Tabla – “PRODUCTO”
A continuación pasaremos a describir la estructura física necesaria para
representar y mantener la información, para ello utilizaremos PostgreSQL ya
que es un Sistema de Gestión de Base de Datos (SGBD) relacional orientado
a objetos y libre.

BD_SISTEMA

create table sucursal

(
cod_sucursal char(2) not null,
nombre_sucursal varchar(50) not null,
constraint pk_sucursal primary key(cod_sucursal),
constraint chk_sucursal check(cod_sucursal similar to '[0-9][0-9]')
);

create table usuario

(
cod_usuario char(2) not null,
nombre_usuario varchar(50) not null,
correo varchar(50) not null,
tipo varchar(50) not null,
user varchar(50) not null,
password varchar(50) not null,
cod_sucursal char(2) not null,
constraint pk_usuario primary key(cod_usuario),
constraint fk_sucursal foreign key(cod_sucursal) references sucursal(cod_sucursal),
constraint chk_usuario_cod check(cod_usuario similar to '[0-9][0-9]')
);

create table producto

(
cod_producto char(2) not null,
nombre_producto varchar(50) not null,
precio_producto decimal(10,2) not null,
constraint pk_producto primary key(cod_producto),
constraint chk_producto_cod check(cod_producto similar to '[0-9][0-9]'),
constraint chk_producto_precio check(precio_producto>0.00)
);

create table pedido

(
id_pedido int not null,
cliente varchar(50) not null,
direccion varchar(50) not null,
referencia varchar(50) not null,
telefono char(6) not null,
fecha datetime not null default getdate(),
importe decimal(10,2) not null,
pago decimal(10,2) not null,
vuelto decimal(10,2) not null,
estado char(1) not null,
modalidad char(1) not null,
cod_usuario char(2) null,
cod_sucursal char(2) null,
constraint pk_pedido primary key(id_pedido),
constraint fk_usuario foreign key(cod_usuario) references usuario(cod_usuario),
constraint fk_sucursal foreign key(cod_sucursal) references sucursal(cod_sucursal),
constraint chk_pedido_id_pedido check(id_pedido>0),
constraint chk_pedido_importe check(importe>0.00),
constraint chk_pedido_pago check(pago>0.00),
constraint chk_pedido_vuelto check(vuelto>0.00),
-- P: Pedido por confirmar, C: Pedido confirmado, N: Pedido no confirmado, D: Pedido
despachado, A: Pedido anulado
constraint chk_pedido_estado check(estado in (‘P’,’C’,’N’,’D’,’A’)),
-- T: Pedido recepcionado vía Telefónica, I: Pedido recepcionado vía Internet
constraint chk_pedido_modalidad check(modalidad in (‘P’,’I’))
);

create table detallepedido

(
id_detallepedido int not null,
cantidad int not null,
precio decimal(10,2) not null,
id_pedido int not null,
cod_producto char(2) not null,
constraint pk_detallepedido primary key(id_detallepedido),
constraint fk_pedido foreign key(id_pedido) references pedido(id_pedido),
constraint fk_producto foreign key(cod_producto) references producto(cod_producto),
constraint chk_detallepedido_id_detallepedido check(id_detallepedido>0),
constraint chk_detallepedido_cantidad check(detallepedido_cantidad > 0),
constraint chk_detallepedido_precio check(tdetallepedido_precio > 0.00)
)

6. Diccionario de base de datos