Proyecto

SISTEMA DE INFORMACIÓN PARA LA GESTIÓN DE DOMICILIOS WEB EN LA

EMPRESA FOOD COMPANY.
Desarrollado por:

INSTRUCTOR

Jennifer Andrea Fajardo Bolívar

SENA 2022

INTRODUCCIÓN
El presente proyecto tiene como finalidad desarrollar un sistema de información web que permita dar solución a las necesidades
de la empresa de comidas rápidas Food Company, en lo concerniente a la gestión de pedidos y despacho de domicilios, ya que
actualmente la empresa no cuenta con un proceso efectivo para controlar los pedidos realizados, así como los domicilios
efectuados
DESCRIPCIÓN DEL CASO (PROBLEMA)

La empresa “Food Company”, es una microempresa de comida rápida ubicada en la localidad de Chapinero que
comercializa diferentes productos como hamburguesas, perros calientes, pizza, mazorcadas entre otros. La tienda
cuenta con un administrador, que es quien se encuentra encargado de la caja, el personal que se encarga de la
preparación de alimentos, los meseros y domiciliarios.

En la actualidad, el administrador es quien lleva a cabo la solicitud de pedidos en el punto de venta, donde a través de
la caja se realiza directamente la solicitud de productos (se paga primero en la caja), la caja genera un tiquete y este
se pasa a la cocina para su preparación, posteriormente es servido a la mesa de los clientes y/o empacado para llevar.

También manejan la gestión de domicilios de forma tradicional por vía telefónica o por WhatsApp, donde los datos
del cliente como nombre, dirección, teléfono y el pedido son anotados en hojas de tacos de papel. Se solicita a la
cocina la preparación de los alimentos y posteriormente se entrega al domiciliario para que este entregue
directamente los productos al cliente. Aunque este método ha sido eficaz, en ocasiones se presentan casos en los que
se desaparecen los papeles con la información y no se despachan los domicilios, los clientes llaman nuevamente
porque sus pedidos se encuentran demorados o porque les llegó algo que no corresponde con lo pedido.

OBJETIVOS DEL PROYECTO

OBJETIVO GENERAL
Desarrollar un Sistema de Información para la gestión de domicilios web de la empresa “Food Company”.

OBJETIVOS ESPECÍFICOS (1 POR CADA FASE)

1. Interpretar los Requisitos Funcionales y los diagramas UML del proyecto de la empresa
2. Diseñar la interfaz gráfica acorde a los diagramas de casos de uso establecidos.
3. Desarrollar el sistema de información tomando como base la arquitectura MVC de acuerdo con lenguaje de
programación y al gestor de bases de datos indicado.
4. Realizar pruebas de funcionalidad para verificar el correcto funcionamiento del sistema, de acuerdo con los
RQF planteados.

ALCANCE DEL PROYECTO

El proyecto pretende desarrollar un sistema de información web mediante el uso del lenguaje PHP y el gestor de
base de datos MYSQL en un plazo máximo 18 meses, que cuente con los módulos que se detallan a continuación:

MÓDULO DE USUARIOS
• Nombre del módulo: Modulo Usuarios
• Descripción del módulo: Este módulo permite la gestión de usuarios donde están involucrados los actores
Administrador, Cliente y Domiciliario.
• Información del proceso (casos de uso involucrados con su respectiva función):
1. CU001 Validar Usuario: Se debe validar el acceso al sistema verificando por lo menos dos datos correo
electrónico y contraseña, solo se debe permitir el acceso a usuarios activos. La validación debe hacerse
con un procedimiento almacenado a la base de datos, se sugiere crear una tabla LOG para realizar un
 registro de acceso al sistema implementando disparadores en la base de datos, en cuanto al diseño
puede estar integrado en una página informativa sobre la empresa, enlazado como un link a otra vista,
en una ventana modal o simplemente como página inicial.
2. CU002 Gestionar Usuario: El sistema debe permitir a un usuario cliente, domiciliario o administrador
auto registrarse, ver y modificar sus propios datos de perfil. Un usuario puede darse de baja (inactivar
su usuario), para activarse nuevamente debe solicitar al administrador directamente. El administrador
puede registrar, modificar los datos de los usuarios, ver listado de los registros en estado activo, un
listado de los registros en estado. Puede consultar un registro individual por número de documento o
apellido del usuario y activar o inactivar un usuario según sea necesario.
MÓDULO DE PEDIDOS
• Nombre del módulo: Módulo Pedidos
• Descripción del módulo: Este módulo permite el registro de pedidos por parte del cliente o del
administrador.
• Información del proceso (casos de uso involucrados con su respectiva función):
1. CU001 Validar Usuario: Se debe validar el acceso al sistema verificando por lo menos dos datos
correo electrónico y contraseña, solo se debe permitir el acceso a usuarios activos. La validación
debe hacerse con un procedimiento almacenado a la base de datos, se sugiere crear una tabla
LOG para realizar un registro de acceso al sistema implementando disparadores en la base de
datos, en cuanto al diseño puede estar integrado en una página informativa sobre la empresa,
enlazado como un link a otra vista, en una ventana modal o simplemente como página inicial.
2. CU002 Gestionar Usuario: El sistema debe permitir a un usuario cliente, domiciliario o
administrador auto registrarse, ver y modificar sus propios datos de perfil. Un usuario puede darse
de baja (inactivar su usuario), para activarse nuevamente debe solicitar al administrador
directamente. El administrador puede registrar, modificar los datos de los usuarios, ver listado de
los registros en estado activo, un listado de los registros en estado. Puede consultar un registro
individual por número de documento o apellido del usuario y activar o inactivar un usuario según
sea necesario.
3. CU003 Gestión Productos: El sistema debe permitir al administrador registrar, modificar los datos
de los productos e inactivar un registro, además debe mostrar un listado de los productos
disponibles y una consulta de productos por nombre. El cliente podrá ver el listado de productos
disponibles.
4. CU004 Gestión de pedidos: El sistema debe permitir registrar, modificar y anular los pedidos
realizados por un cliente o un administrador, además debe permitir ver el listado de pedidos
pendientes por entrega y finalizados. Debe permitir generar una consulta de un registro individual
por número de pedido.
MÓDULO DE DOMICILIOS
• Nombre del módulo: Modulo Domicilios
• Descripción del módulo: Este módulo permite la gestión de usuarios donde están involucrados los actores
Administrador, y Domiciliario.
• Información del proceso (casos de uso involucrados con su respectiva función):
1. CU001 Validar Usuario: Se debe validar el acceso al sistema verificando por lo menos dos datos correo
electrónico y contraseña, solo se debe permitir el acceso a usuarios activos. La validación debe hacerse
con un procedimiento almacenado a la base de datos, se sugiere crear una tabla LOG para realizar un
registro de acceso al sistema implementando disparadores en la base de datos, en cuanto al diseño
puede estar integrado en una página informativa sobre la empresa, enlazado como un link a otra vista,
en una ventana modal o simplemente como página inicial.
2. CU002 Gestionar Usuario: El sistema debe permitir a un usuario cliente, domiciliario o administrador
auto registrarse, ver y modificar sus propios datos de perfil. Un usuario puede darse de baja (inactivar
su usuario), para activarse nuevamente debe solicitar al administrador directamente. El administrador
puede registrar, modificar los datos de los usuarios, ver listado de los registros en estado activo, un
listado de los registros en estado. Puede consultar un registro individual por número de documento o
apellido del usuario y activar o inactivar un usuario según sea necesario.
3. CU005 Gestionar Domicilios: El sistema generará de forma automática (puede ser mediante un
disparador) una solicitud de domicilio, al registrarse un pedido marcado para domicilio. El
administrador podrá modificar e inactivar un domicilio. El sistema debe permitir a el(los)
domiciliario(s) seleccionar máximo 2 pedidos a la vez para su despacho y el domiciliario deberá
registrar la entrega del domicilio al finalizar el mismo.

Reportes (reportes involucrados con su respectiva descripción)

Generar reporte de pedidos por domiciliario: Posterior a la asignación de pedidos a un domiciliario el
sistema permitirá generar un reporte que muestre los pedidos que han sido asignados a un
domiciliario en un periodo de tiempo específico.
DESCRIPCIÓN DE TAREAS
Las necesidades que presenta la empresa se sintetizan en el ESTUDIO DE CASO “Sistema de información para la gestión
de domicilios web en la empresa Food Company ”, la información relevante frente al proceso que lleva actualmente
la empresa se complementa con el material de apoyo que incluye los anexos necesarios para su desarrollo, este se
encuentra en la carpeta denominada MATERIAL DE APOYO DEL PROYECTO.

TAREA 1. LECTURA Y ANÁLISIS DEL DOCUMENTO

TAREA 2. CONSTRUCCIÓNDE LA INTERFAZ GRÁFICA

TAREA 3. MAQUETACIÓN WEB DEL PROYECTO

TAREA 4. CONSTRUCCIÓN DE LA BASE DE DATOS

TAREA 5. INTEGRACIÓN DE LA BASE DE DATOS CON LA INTERFAZ GRÁFICA

TAREA 6. REPORTES GENERALES Y ESPECÍFICOS (GRÁFICOS Y PLANOS)

TAREA 7. IMPLANTACIÓN DEL PROYECTO

TAREA 8. PRUEBAS DE FUNCIONALIDAD (TESTING)

ANEXO 1. REQUISITOS FUNCIONALES

CÓDIGO REQUISITOS FUNCIONALES

Nombre: Validar Usuario
Descripción: El sistema permitirá el acceso a los usuarios registrados y activos
RQF001 mediante la autenticación por correo electrónico y contraseña.
Usuarios: administrador, cliente, domiciliario

CÓDIGO REQUISITOS FUNCIONALES

Nombre: Gestión de Usuarios
Descripción: El sistema debe permitir a un usuario cliente, domiciliario o
administrador auto registrarse, ver y modificar sus propios datos de perfil. Un
usuario puede darse de baja (inactivar su usuario), para activarse nuevamente debe
solicitar al administrador directamente. El administrador puede registrar, modificar
RQF002 los datos de los usuarios, ver listado de los registros en estado activo, un listado de
los registros en estado inactivo. Puede consultar un registro individual por número
de documento o apellido de usuario y activar o inactivar un usuario según sea
necesario.
Usuarios: administrador, cliente, domiciliario

CÓDIGO REQUISITOS FUNCIONALES

Nombre: Gestión de Productos
Descripción: El sistema permitirá al administrador realizar las acciones de registro,
consulta, modificación e inactivación de productos, El usuario cliente podrá ver los
RQF003 productos disponibles

Usuarios: administrador, cliente

CÓDIGO REQUISITOS FUNCIONALES

Nombre: Gestión de Pedidos
Descripción: El sistema permitirá al administrador y al cliente realizar las acciones
de registro, consulta, modificación y anulación de pedidos.
RQF004

Usuarios: administrador, cliente

CÓDIGO REQUISITOS FUNCIONALES
Nombre: Gestión de domicilios
Descripción: El sistema generará automáticamente una solicitud de domicilio para
los pedidos que hayan sido marcados para domicilio, el administrador podrá
modificar e inactivar una solicitud de domicilio. El sistema debe permitir a el(los)
RQF005 domiciliario(s) seleccionar el pedido para su despacho, el domiciliario deberá
registrar la entrega del domicilio al finalizar el mismo. El sistema debe mostrar un
listado de los domicilios pendientes de entrega y entregados.
Usuarios: administrador, domiciliario

CÓDIGO REQUISITOS FUNCIONALES

Nombre: Reporte de pedidos por domiciliario
Descripción: El sistema generará automáticamente una solicitud de domicilio para
los pedidos que hayan sido marcados para domicilio, el administrador podrá
modificar e inactivar una solicitud de domicilio, asignar un domiciliario para la
RQF006 entrega. El sistema debe permitir al(los) domiciliario(s) seleccionar un pedido para
su despacho, el domiciliario deberá registrar la entrega del domicilio al finalizar el
mismo.
Usuarios: administrador, domiciliario
ANEXO 2. REQUISITOS NO FUNCIONALES

CÓDIGO REQUISITOS NO FUNCIONALES

Nombre: Especificaciones Mínimas de Hardware y Software
Descripción:
Tener acceso a uno o más computadores:
Mínimo 2 GB RAM
RQNF001 Sistema Operativo Windows 7 o superior
Disco duro de 500 GB
Que tenga las herramientas y programas necesarios para llevar a cabo el aplicativo,
base de datos (MYSQL) y servidor (APACHE).

CÓDIGO REQUISITOS NO FUNCIONALES

Nombre: Conexión internet
Descripción:
RQNF002 La empresa debe contar con una red LAN que le permitirá
conectar sus terminales de trabajo al servidor de una forma
más adecuada para hacer uso del aplicativo

CÓDIGO REQUISITOS NO FUNCIONALES

Nombre: Diseño de Interfaz grafica
Descripción:
RQNF003 El aplicativo debe hacer uso de colores y fuentes que faciliten
la adecuada visualización por parte del usuario y sean
Acordes con la imagen corporativa de la empresa.
ANEXO 3. DIAGRAMAS Y DOCUMENTACIÓN DE CASOS USO

Desarrollar diagramas de casos de uso por actor en DIA, teniendo en cuenta el siguiente ejemplo (nomenclatura, actor, CU,
acciones), incluir imágenes exportadas desde DIA.
EJEMPLO PARA UN CASO DE USO:

1. IDENTIFICACIÓN DE CASO DE USO

1.1 Id Caso CUD 001 1.2 Nombre Validar Usuario
2. HISTORICO DE CASO DE USO
2.1 Autor Nombres Aprendices
2.2 Fecha Creación 30/04/2022 3. Última Actualización
2.4 Actualizado por Nombres Aprendices 2.5 Versión 1.0
3. DEFINICION DE UN CASO DE USO
3.1 DESCRIPCIÓN: Incluir aquí la descripción del caso de uso
3.2 ACTORES: Actores que participan en el caso de uso
3.3 PRECONDICIONES
1. El usuario debe estar autenticado en el sistema CU 001
3.4 FLUJO NORMAL
Contando con las precondiciones el flujo normal será el siguiente:
Paso Actor Sistema
1 Pasos que realiza el actor Pasos que realiza el sistema
2
3
4
5
3.5 FLUJO ALTERNATIVO
Si existe otra forma de acceder al caso de uso, describir los pasos.
Paso Actor Sistema

3.5 FLUJO EXCEPCIONAL

Paso Actor Sistema

xx
xx
3.7 POS CONDICIONES
Sistema
3.8 FRECUENCIA
Que frecuencia tiene el CU Alta Media Baja
ANEXO 4. DIAGRAMA DE CLASES

Desarrollar diagrama de clases en DIA, teniendo en cuenta nomenclatura, atributos y métodos con tipo, visibilidad.
Multiplicidad. Exportar como imagen desde DIA.
ANEXO 5. MODELO RELACIONAL (DIA)
ANEXO 6. DICCIONARIOS DE DATOS

Incluir por cada tabla el diccionario de datos correspondiente, tener en cuenta tipos de dato y restricciones MYSQL

Nombre Tabla: rolUsuario

Fecha: 11/02/20XX
Descripción: Tabla que contiene los campos del rol de Usuario

Campo Tipo de Dato Tamaño Restricción Descripción

Primary key -
idRolUsuario int Llave primaria del rol del Usuario
AUTOINCREMENT
Nombre del rol de usuario Administrador,
descripRolUsuario Varchar 30 NOT NULL
Cliente, Domiciliario
Estado del rol de Usuario puede ser Activo /
estadoRolUsuario Varchar 30 NOT NULL
Inactivo

Nombre Tabla: Usuario

Fecha: 11/02/20XX
Descripción: Tabla que contiene los campos del Usuario

Campo Tipo de Dato Tamaño Restricción Descripción

Primary key -
idUsuario int Llave primaria del Usuario
AUTOINCREMENT
tipoDocUsuario Varchar 30 NOT NULL Tipo de documento del usuario
numdocUsuario Varchar 20 NOT NULL Numero de documento del usuario
nombreUsuario Varchar 50 NOT NULL Nombre del Usuario
apellidoUsuario Varchar 50 NOT NULL Apellido del usuario
direccionUsuario Varchar 80 NOT NULL Dirección del usuario
telefonoUsuario Varchar 20 NOT NULL Teléfono del usuario
NOT NULL
correoUsuario Varchar 70 Correo del usuario
UNIQUE
passwordUsuario Varchar 20 NOT NULL Contraseña del usuario
fotoUsuario blob NULL Foto del usuario
estadoUsuario Varchar 30 NOT NULL Estado del Usuario puede ser Activo / Inactivo
Llave foránea que determina el rol que tendrá
idUsuarioFK int Foreign Key
el usuario

Nombre Tabla: Producto

Fecha: 11/02/20XX
Descripción: Tabla que contiene los campos del Producto

Campo Tipo de Dato Tamaño Restricción Descripción

Primary key -
idProducto int Llave primaria del Producto
AUTOINCREMENT
descripProducto Varchar 100 NOT NULL Descripción del producto
precioProducto Double NOT NULL Precio unitario del producto
Categoría del producto bebidas, comidas,
categoriaProducto Varchar 40 NOT NULL
entradas, etc.
estadoProducto Varchar 30 NOT NULL Estado del Usuario puede ser Activo / Inactivo
Nombre Tabla: Pedido
Fecha: 11/02/20XX
Descripción: Tabla que contiene los campos del Pedido

Campo Tipo de Dato Tamaño Restricción Descripción

Primary key -
idPedido int Llave primaria del Pedido
AUTOINCREMENT
fechaPedido date NOT NULL Fecha de emisión del pedido
horaPedido time NOT NULL Hora de emisión del pedido
totalPedido Double NOT NULL Valor a pagar por el pedido
Estado del Usuario puede ser Activo / Anulado
estadoPedido Varchar 30 NOT NULL
/ Entregado
Se define si el pedido se requiere a domicilio, si
pedidoaDomicilio Char 3 NULL se marca sí, se genera automáticamente la
solicitud de domicilio por un disparador.
idUsuarioFK Int Foreign Key Llave foránea del usuario que realiza el pedido

Nombre Tabla: detallePedido

Fecha: 11/02/20XX
Descripción: Tabla que contiene los campos del Detalle de pedido

Campo Tipo de Dato Tamaño Restricción Descripción

Primary key -
idDetallePedido int Llave primaria del detalle de Pedido
AUTOINCREMENT
Llave foránea del producto que se requiere en
idProductoFK Int Foreign Key
el pedido
cantidadProducto Int NOT NULL Unidades que se van a pedir del producto
Precio unitario del producto agregado al
precioProducto Double NOT NULL
pedido
subtotalProducto Double NOT NULL Subtotal de cada producto agregado al pedido
Llave foránea del pedido al que pertenece el
idPedidoFK Int Foreign Key
detalle que se está agregando.

Nombre Tabla: Domicilio

Fecha: 11/02/20XX
Descripción: Tabla que contiene los campos del Domicilio

Campo Tipo de Dato Tamaño Restricción Descripción

Primary key -
idDomicilio int Llave primaria del detalle de Pedido
AUTOINCREMENT
Hora Generación del domicilio. Se llena
horaDomicilio Time NOT NULL
automática por disparador
Estado del domicilio puede ser Activo /
estadoDomicilio Varchar 30 NOT NULL
Asignado / Entregado.
Llave foránea del pedido al que pertenece el
idPedidoFK Int Foreign Key
domicilio. Se llena automática por disparador.
Llave foránea del domiciliario asignado para la
idDomiciliarioFK Int Foreign Key
entrega del pedido.