Oñate Mena, Sebastián Andrés

Universidad del Bío-Bío.
Red de Bibliotecas - Chile
SISTEMA DE PEDIDOS DE COMIDA

ONLINE
SEBASTIAN ANDRES OÑATE MENA

JUAN LEONARDO ZAPATA FUENTES
Docente guía
Profesora Marcela Pinto
MEMORIA PARA OPTAR AL TÍTULO DE

INGENIERO CIVIL EN INFORMÁTICA
02 de agosto de 2019
Chillán - Chile
1
Universidad del Bío-Bío. Red de Bibliotecas - Chile
Resumen
Este proyecto se presenta para dar conformidad a los requisitos exigidos por la Universidad
de Bío-Bío en el proceso de titulación de la carrera de Ingeniería Civil en Informática.
El proyecto lleva como título “Sistema de Pedidos de Comida Online.”.
Este proyecto tiene como objetivo desarrollar un Servicio Web para optimizar los procesos
administrativos que permiten realizar pedidos a un determinado local de comida rápida, por lo
tanto, se propone desarrollar un Software que facilite a las empresas del rubro de comidas rápidas,
la creación de Productos, Categorías y Repartos a través de un sitio web, además el sistema
otorgará la generación de informes.
En cuanto al desarrollo, se optó por utilizar la metodología iterativa e incremental, usando el

enfoque POO (Programación Orientada a Objetos), mediante el modelo de tres capas MVC (Modelo,
Vista y Controlador).
Al implementar este Sistema se mejorará el proceso de gestión de pedidos de las empresas

de comida rápida, que actualmente tienen una desorganización en la información que administran,
brindando la posibilidad de llevar un registro de los clientes y las ordenes generadas para los
clientes. Con esto, podrán determinar cuan necesario es el reparto y el uso de las redes sociales
para expandir su negocio. Por otro lado, se podrá imprimir un informe que facilitarán la toma de
decisiones de estas empresas, mejorando la atención a los clientes.
2
Abstract
This project is presented to conform to the requirements demanded by the University of Bio-
Bio in the process of titling of Civil Engineering in Computer Science.
The project is entitled " Online Food Order System.".
This project aims to develop a Web Service to optimize the administrative processes that
allow orders to a specific fast food place, therefore, it is proposed to develop a Software that
will facilitate companies in the fast food category, the creation of Products, Categories and
Distributions through a website. Also, the system will provide the generation of reports.
In terms of development, it was decided to use the iterative and incremental methodology,
using the POO (Object Oriented Programming) approach, using the three layer MVC model
(Model, View and Controller).
Implementing this system will improve the order management process of fast food
companies, which currently have a disorganization in the information they manage,
providing the possibility of keeping a record of customers and orders generated for the
customers. With this, they will be able to determine how necessary is the distribution and
use of social networks to expand their business. On the other hand, it will be possible to print
a report that will facilitate the decision making of these companies, improving the attention
to the customers.
3
Índice General
1 INTRODUCCIÓN................................................................................................................................................ 10
2 DEFINICIÓN DE LA EMPRESA O INSTITUCIÓN.................................................................................................. 11
2.1 DESCRIPCIÓN DE LA EMPRESA ................................................................................................................................ 12
2.2 DESCRIPCIÓN DEL ÁREA DE ESTUDIO........................................................................................................................ 13
2.3 DESCRIPCIÓN DE LA PROBLEMÁTICA ........................................................................................................................ 13
3 DEFINICIÓN DEL PROYECTO ............................................................................................................................. 15
3.1 OBJETIVOS DEL PROYECTO ..................................................................................................................................... 16
3.2 AMBIENTE DE INGENIERÍA DE SOFTWARE................................................................................................................. 16
3.3 DEFINICIONES, SIGLAS Y ABREVIACIONES ................................................................................................................. 18
4 ESPECIFICACIÓN DE REQUERIEMIENTOS DE SOFTWARE ................................................................................ 19
4.1 ALCANCES .......................................................................................................................................................... 20
4.2 OBJETIVO DEL SOFTWARE...................................................................................................................................... 20
4.3 DESCRIPCIÓN GLOBAL DEL PRODUCTO. .................................................................................................................... 21
4.3.1 Interfaz de usuario. .................................................................................................................................... 21
4.3.2 Interfaz de hardware. ................................................................................................................................ 21
4.3.3 Interfaz de software. ................................................................................................................................. 21
4.4 REQUERIMIENTOS ESPECÍFICOS .............................................................................................................................. 22
4.4.1 Requerimientos Funcionales del Módulo de Usuario. ............................................................................. 22
4.4.2 Requerimientos Funcionales del Módulo de Administrador. .................................................................. 24
4.4.3 Requerimientos Funcionales del Módulo de Repartidor.......................................................................... 28
4.4.4 Interfaces externas de entrada ................................................................................................................. 29
4.4.5 Interfaces externas de Salida .................................................................................................................... 29
4.4.6 Atributos del producto............................................................................................................................... 30
5 FACTIBILIDAD ................................................................................................................................................... 31
5.1 FACTIBILIDAD TÉCNICA.......................................................................................................................................... 32
5.2 REQUERIMIENTOS TÉCNICOS PARA EL DESARROLLO ................................................................................................... 32
5.3 FACTIBILIDAD OPERACIONAL .................................................................................................................................. 32
5.4 FACTIBILIDAD ECONÓMICA .................................................................................................................................... 33
5.4.1 Costos de desarrollo .................................................................................................................................. 33
5.4.2 Costos de operación .................................................................................................................................. 33
5.4.3 Costos de mantención ............................................................................................................................... 34
5.5 BENEFICIOS......................................................................................................................................................... 34
5.6 FLUJO DE CAJA..................................................................................................................................................... 35
5.6.1 Calculo del VAN.......................................................................................................................................... 35
5.7 CONCLUSIÓN DE LA FACTIBILIDAD ........................................................................................................................... 36
6 PROPUESTA DE SOLUCIÓN............................................................................................................................... 37
6.1 SOLUCIÓN A LA PROBLEMÁTICA ............................................................................................................................. 38
7 INCREMENTOS ................................................................................................................................................. 39
7.1 PRIMER INCREMENTO .......................................................................................................................................... 40
7.1.1 Análisis........................................................................................................................................................ 40
7.1.1.1 Diagrama de casos de uso.................................................................................................................................. 40
7.1.1.1.1 Actores .......................................................................................................................................................... 40
7.1.1.1.2 Casos de Uso y descripción ........................................................................................................................ 40
4
7.1.1.1.3 Especificación de los Casos de Uso............................................................................................................ 42

7.1.1.1.3.1 Especificación caso de uso módulo Usuario. .................................................................................... 43
7.1.1.1.3.2 Especificación caso de uso módulo Administrador. ........................................................................ 45
7.1.2 Diseño......................................................................................................................................................... 49
7.1.2.1 Diseño de Físico de la Base de datos ................................................................................................................. 49
7.1.2.2 Diseño interfaz y navegación ............................................................................................................................. 50
7.1.2.2.1 Diseño de la interfaz.................................................................................................................................... 50
7.1.2.2.1.1 Módulo de Usuario ............................................................................................................................... 50
7.1.2.2.1.2 Módulo de Administrador................................................................................................................... 52
7.1.3 Pruebas....................................................................................................................................................... 54
7.1.3.1 Elementos de prueba ......................................................................................................................................... 54
7.1.3.2 Especificación de las pruebas............................................................................................................................. 54
7.1.3.2.1 Pruebas de sistema...................................................................................................................................... 54
7.1.3.3 Responsable de las pruebas............................................................................................................................... 55
7.1.3.4 Detalle de las pruebas. ....................................................................................................................................... 55
7.1.3.4.1 Plan de pruebas de sistema. ....................................................................................................................... 55
7.1.3.4.1.1 Pruebas de sistema para el módulo Usuario..................................................................................... 55
7.1.3.4.1.2 Pruebas de sistema para el modulo Administrador. ....................................................................... 56
7.2 SEGUNDO INCREMENTO ....................................................................................................................................... 57
7.2.1 Análisis........................................................................................................................................................ 57
7.2.1.1 Diagrama de casos de uso.................................................................................................................................. 57
7.2.1.1.1 Actores .......................................................................................................................................................... 57
7.2.1.1.2 Casos de Uso y descripción ........................................................................................................................ 58
7.2.1.1.3 Especificación de los Casos de Uso............................................................................................................ 61
7.2.1.1.3.1 Especificación caso de uso módulo Usuario. .................................................................................... 61
7.2.1.1.3.2 Especificación caso de uso módulo Administrador. ........................................................................ 63
7.2.1.1.3.3 Especificación caso de uso módulo Repartidor................................................................................ 68
7.2.1.2 Modelamiento de datos general ....................................................................................................................... 69
7.2.1.2.1 Descripción del modelamiento de datos .................................................................................................. 70
7.2.2 Diseño......................................................................................................................................................... 71
7.2.2.1 Diseño de Físico de la Base de datos ................................................................................................................. 71
7.2.2.2 Diseño interfaz y navegación ............................................................................................................................. 72
7.2.2.2.1 Diseño de la interfaz.................................................................................................................................... 72
7.2.2.2.1.1 Módulo de Usuario ............................................................................................................................... 72
7.2.2.2.1.2 Módulo de Administrador................................................................................................................... 73
7.2.2.2.1.3 Módulo de Repartidor.......................................................................................................................... 74
7.2.3 Pruebas....................................................................................................................................................... 75
7.2.3.1 Elementos de prueba ......................................................................................................................................... 75
7.2.3.2 Especificación de las pruebas............................................................................................................................. 75
7.2.3.2.1 Pruebas de sistema...................................................................................................................................... 75
7.2.3.2.2 Pruebas de seguridad ................................................................................................................................. 76
7.2.3.2.3 Pruebas de usabilidad. ................................................................................................................................ 76
7.2.3.3 Responsable de las pruebas............................................................................................................................... 77
7.2.3.4 Detalle de las pruebas. ....................................................................................................................................... 77
7.2.3.4.1 Plan de pruebas de sistema. ....................................................................................................................... 77
7.2.3.4.1.1 Pruebas de sistema para el modulo Usuario..................................................................................... 77
7.2.3.4.1.2 Pruebas de sistema para el modulo Administrador. ....................................................................... 80
7.2.3.4.1.3 Pruebas de sistema para el modulo Repartidor. .............................................................................. 82
7.2.3.4.2 Plan de pruebas de seguridad. ................................................................................................................... 83
7.2.3.4.2.1 Prueba de seguridad. ........................................................................................................................... 83
7.2.3.4.3 Plan de pruebas de usabilidad. .................................................................................................................. 84
7.2.3.4.3.1 Prueba de usabilidad............................................................................................................................ 84
8 SEGURIDAD ...................................................................................................................................................... 88
9 CONCLUSIONES ................................................................................................................................................ 90
10 BIBLIOGRAFÍA................................................................................................................................................... 93
5
ANEXOS ..................................................................................................................................................................... 94
4.2.1.1.3.1. Anexo Especificación caso de uso módulo Usuario Segundo Incremento. ...................................... 95
4.1.1.1.3.2. Anexo Especificación caso de uso módulo Administrador Primer Incremento. ............................. 98
4.2.1.1.3.2. Anexo Especificación caso de uso módulo Administrador Segundo Incremento. ........................ 102
4.2.1.1.3.3. Anexo Especificación caso de uso módulo Repartidor Segundo Incremento................................ 107
4.2.3.4.1.1. Anexo Pruebas de sistema para el módulo Usuario Segundo Incremento. ................................... 109
4.2.3.4.1.2. Anexo Pruebas de sistema para el módulo Administrador Segundo Incremento. ....................... 112
4.2.3.4.1.3. Anexo Pruebas de sistema para el módulo Repartidor Segundo Incremento. .............................. 116
6
Índice Tablas
Tabla 1. Requerimientos funcionales del módulo Usuario. ..................................................................................... 22

Tabla 2. Requerimientos funcionales del módulo Usuario. ..................................................................................... 23
Tabla 3. Requerimientos funcionales del módulo Administrador. ...................................................................... 24
Tabla 7. Requerimientos funcionales del módulo Repartidor. .............................................................................. 28
Tabla 8. Interfaces externas de entrada. ............................................................................................................................29
Tabla 9. Interfaces externas de salida..................................................................................................................................29
Tabla 10. Requerimientos no funcionales del sistema. .............................................................................................. 30
Tabla 11.Flujo de Caja. .................................................................................................................................................................35
Tabla 12. Caso de Uso Registro de Usuario. ..................................................................................................................... 43
Tabla 13. Caso de Uso Modificar Datos Personales...................................................................................................... 44
Tabla 14. Caso de Uso Registro de Categoría................................................................................................................... 45
Tabla 15. Caso de Uso Eliminar Categoría......................................................................................................................... 46
Tabla 16. Caso de Uso Modificar Categoría....................................................................................................................... 47
Tabla 17. Caso de Uso Visualizar Usuarios. ...................................................................................................................... 48
Tabla 18. Especificación de Pruebas de Sistema. .......................................................................................................... 54
Tabla 19. Pruebas de sistema para el Modulo Usuario. ............................................................................................. 55
Tabla 20. Pruebas de sistema para Modulo Administrador. ................................................................................... 56
Tabla 21. Caso de Uso Agregar productos al carro de compras. ........................................................................... 61
Tabla 22. Caso de Uso Realizar pedidos en línea. .......................................................................................................... 62
Tabla 23. Caso de Uso Modificar datos de Productos.................................................................................................. 63
Tabla 24. Caso de Uso Bloquear Usuarios. ........................................................................................................................ 64
Tabla 25. Caso de Uso Modificar estado de un pedido. .............................................................................................. 65
Tabla 26. Caso de Uso Reporte de ventas por rango de Fecha. .............................................................................. 66
Tabla 27. Caso de Uso Visualizar mapa del Pedido. ..................................................................................................... 67
Tabla 28. Caso de Uso Modificar estado de un pedido. .............................................................................................. 68
Tabla 29. Especificación de Pruebas de Sistema. .......................................................................................................... 75
Tabla 30. Especificación de Pruebas de Seguridad. ..................................................................................................... 76
Tabla 31. Especificación de Pruebas de Usabilidad. .................................................................................................... 76
Tabla 32. Pruebas de sistema Módulo Usuario. ............................................................................................................. 77
Tabla 33. Pruebas de sistema Módulo Usuario. ............................................................................................................. 79
Tabla 34. Pruebas de sistema Módulo Administrador. .............................................................................................. 80
Tabla 35. Pruebas de sistema Módulo Administrador. .............................................................................................. 81
Tabla 36. Pruebas de sistema Módulo Repartidor. ...................................................................................................... 82
Tabla 37. Prueba de Seguridad. ..............................................................................................................................................83
Tabla 38. Caso de uso Listar productos por categoria. ............................................................................................... 95
Tabla 39. Caso de uso Eliminar productos del Carro de compras. ....................................................................... 96
Tabla 40. Caso de uso Visualizar Pedidos.......................................................................................................................... 97
Tabla 41. Caso de uso Crear estados. ...................................................................................................................................98
Tabla 42. Caso de uso Modificar estados. .......................................................................................................................... 99
Tabla 43. Caso de uso Visualizar estados........................................................................................................................ 100
Tabla 44. Caso de uso Visualizar categoría. ................................................................................................................... 101
Tabla 45. Caso de uso Registro de productos............................................................................................................... 102
Tabla 46. Caso de uso Visualizar productos. ................................................................................................................. 103
7
Tabla 47. Caso de uso Eliminar productos..................................................................................................................... 104

Tabla 48. Caso de uso Visualizar pedidos....................................................................................................................... 105
Tabla 49. Caso de uso Modificar rol de usuario........................................................................................................... 106
Tabla 50. Caso de uso Visualizar pedidos....................................................................................................................... 107
Tabla 51. Caso de uso Visualizar mapa del pedido. ................................................................................................... 108
Tabla 52. Pruebas de sistema Módulo Usuario. .......................................................................................................... 109
Tabla 55. Pruebas de sistema Módulo Administrador. ........................................................................................... 113
Tabla 58. Pruebas de sistema Módulo Repartidor. ................................................................................................... 116
8
Índice Figuras
Figura 1. Diagrama iterativo incremental. ........................................................................................................................ 17

Figura 20. Ecuación calculo VAN............................................................................................................................................35
Figura 2. Diagrama de caso de uso del Usuario.............................................................................................................. 41
Figura 3. Diagrama de caso de uso del Administrador............................................................................................... 42
Figura 4. Diseño físico de la Base de Datos. ...................................................................................................................... 49
Figura 5. Interfaz del Sub-módulo de Registro. .............................................................................................................. 50
Figura 6. Interfaz del Sub-módulo de Productos. .......................................................................................................... 51
Figura 7. Interfaz del Sub-módulo de Modificar Datos Personales...................................................................... 51
Figura 8. Interfaz del Sub-módulo de Crear Categorías. ............................................................................................ 52
Figura 9. Interfaz del Sub-módulo de Usuarios en el Sistema. ............................................................................... 53
Figura 10. Diagrama de caso de uso del Usuario. .......................................................................................................... 58
Figura 11. Diagrama de caso de uso del Administrador............................................................................................ 59
Figura 12. Diagrama de caso de uso del Repartidor. ................................................................................................... 60
Figura 13. Modelamiento de datos. ......................................................................................................................................69
Figura 14. Diseño físico de la Base de Datos. ................................................................................................................... 71
Figura 15. Interfaz del Sub-módulo de Productos. ....................................................................................................... 72
Figura 16. Interfaz del Sub-módulo de Agregar Productos. .................................................................................... 73
Figura 17. Interfaz del Sub-módulo de Visualizar Mapa del Pedido. .................................................................. 74
Figura 18. Encuesta usuarios. ..................................................................................................................................................85
Figura 19. Resultado encuesta usuarios.............................................................................................................................86
9
1 INTRODUCCIÓN
Hoy en día, las aplicaciones y diversos tipos de software se han convertido en la base
tecnológica de las empresas modernas, siendo un factor clave en el proceso de toma de
decisiones y administración de información clara, precisa y confiable.
Nosotros, como equipo de desarrollo de software, nos hemos contactado con empresas de
venta de comidas que necesitan un “Sistema de Pedidos de Comida Online”. Las empresas
requieren de este sistema porque desean recibir pedidos en línea de sus usuarios, dado a
que no cuentan con este medio, aparte que les ayudara a incrementar sus ventas. Asimismo,
esperan popularizar sus productos para tener una mayor clientela.
Bajo este contexto, la idea a realizar es elaborar un proyecto capaz de sustentar y satisfacer
todos y cada uno de los requisitos exigidos por el usuario, representándolos finalmente en
un software. Se desarrollarán a lo largo del tiempo múltiples etapas y tareas que irán
dándole forma al software, quedando adjuntadas y documentadas todas y cada una de ellas
en el presente informe, con el fin de representar de manera clara, especifica y legible cómo el
proyecto y sus respectivos avances dieron la forma final del software.
En el presente informe se abordarán la definición de la empresa, junto con la problemática
en cuestión y la una propuesta de solución especificada en el Capítulo 4. Además, se incluirá
la definición del proyecto, junto con los objetivos del desarrollo de esta. Posteriormente se
especificarán los requerimientos funcionales y no funcionales de software, en donde se
detallarán los tres tipos de usuarios que participan y los requerimientos para cada uno de
estos.
Una etapa importante, es el desarrollo de cada incremento, la que podremos ver en el
Capítulo 5 del presente informe, donde se desglosaran el análisis del incremento junto con el
diseño y las pruebas correspondientes.
Para ver si el software es factible realizar e implementar, es que se desarrolló la factibilidad
del sistema, en donde podremos ver los resultados de esta investigación en el Capítulo 6,
donde se desglosan la factibilidad técnica, factibilidad operacional y económica para el
desarrollo de software.
Finalmente se presentará la conclusión del desarrollo del software, donde se apreciarán los
conocimientos adquiridos y las dificultades en el desarrollo de esta.
10
CAPÍTULO 1
2 DEFINICIÓN DE LA EMPRESA O INSTITUCIÓN
11
2.1 Descripción de la empresa
El siguiente informe va enfocado a las empresas del rubro de las comidas rápidas o
restaurantes que se encuentran en la Ciudad de Chillán. Empresas que tienen una gran gama
de producto al servicio de los usuarios, y que se sitúan en entregar altos estándares de
entrega y satisfacción a los mismos. Por lo que el desarrollo del proyecto se enfocará en
entregar a la empresa solicitante, una página web que se encargue de ampliar su mercado, es
decir, participar más activamente en las redes sociales y en el ámbito de los sitios web, para
así contar con una ventaja competitiva frente a sus competidores y poder ampliar su rubro
de las comidas.
Entorno
 Competencia directa: la competencia directa que existe en el sector de Chillán es
alta, aunque se puede dividir en sub rubros dado a que no todos los locales se
dedican a vender los mismos productos, podemos apreciar locales que venden
comida china, otros que se especializan en pizzas, unos dedicados a la venta de
sushi, y diversos locales dedicados en vender comida rápida (completos, sándwich,
as, etc), etc. Pero, aunque existan distintos sub rubros de la venta de comida rápida
también existen varios competidores directos dentro de esos sub rubros.
 Cuota de mercado: la cuota de mercado dependerá de la empresa solicitando del
proyecto a realizar. Como se menciona en el punto anterior, existe muchas ramas
en el ámbito de las comidas rápidas o restaurantes, por lo que la cuota de mercado
para cada negocio dependerá del rubro en que se especialice el local. Es por esto
que contar con una página web, podría aumentar la cuota de mercado dentro de la
empresa, debido a que captaría más público.
12
2.2 Descripción del área de estudio
El área de estudio de este proyecto se centra en las funciones de venta de algún local de
comida rápida como objetivo principal, la venta de sus productos mediante una plataforma
web y la automatización de sus procesos de venta.
2.3 Descripción de la problemática
En la actualidad, y tomando en cuenta el avance de la tecnología, las empresas se

encontraron con la necesidad de adquirir un sistema que cumpliera con todas las
necesidades posibles para ejecutar su rubro (en este caso, la de venta de comida) mediante
un sitio web.
Es por este motivo que se decide ingresar en el rubro de los pedidos en línea, producto del
problema presentado actualmente con respecto al segmento de usuarios, que visto desde el
punto de vista de la realidad de las empresas se observa un decremento en dicho segmento,
estimando así un desarrollo necesario para optimizar su proceso de ventas y tener una
mayor gestión de las mismas, entre otras cosas.
Dicho esto, la problemática presentada es lograr realizar un software capaz de:
1. Difundir la empresa a través de Internet, así como también tener la opción de
realizar pedidos en el mismo sitio web.
2. Regular y monitorear el estado de un pedido de comida.
Entonces, la problemática real radica en que es necesario contar con un sitio web para el
usuario puesto que el segmento de clientes es menor si sólo realiza su rubro mediante una
tienda física. Esto también es posible visualizarlo gracias al artículo “Ventajas de tener una
página web” realizado por el sitio www.crecenegocios.com, en el apartado “Canal de venta”,
que cita:
“Una página web te puede servir como canal de venta. En vez de que tus clientes tengan que
acudir a algún lugar físico en donde puedan adquirir tus productos, podrían simplemente
ingresar a tu página y comprarlos a través de ésta sin tener que salir de sus casas.”
En base a lo anteriormente descrito, es necesario desarrollar una automatización para el

cliente con el fin de solucionar la problemática visualizada.
13
Para esto, es necesario tomar en cuenta que para las empresas el cliente exige realizar un
sistema completo que contenga todas y cada una de las partes que se presentan mediante los
requerimientos especificados.
Entre los problemas detectados, está la nula participación de las empresas en internet, lo que
demanda realizar un sistema completamente efectivo, legible, y que además su usabilidad
sea clara para el cliente.
1 Arturo K. (2011). Ventajas de tener una página web. 12-06-2011, de

crecenegocios.com Sitio web: http://www.crecenegocios.com/ventajas-de-tener-una-
pagina-web/
14
CAPÍTULO 2
3 DEFINICIÓN DEL PROYECTO
15
3.1 Objetivos del proyecto
Objetivo General:
• Diseñar y desarrollar un software para gestionar los pedidos de comida de forma
online, mediante una solución de arquitectura web, agilizando así los procesos
internos de la organización y, por consiguiente, ayudar a la gestión interna del área
de ventas de la empresa.
Objetivos Específicos:
• Agilizar las órdenes de comida.
• Geolocalizar las direcciones de las entregas de los pedidos con un mapa.
• Visualizar los pedidos efectuados por los usuarios.
• Diseñar una visualización en donde se pueda apreciar la información de la
empresa.
• Diseñar la interfaz de visualización de los productos ofrecidos por el restaurant,
con información de estos.
• Poder utilizar de forma responsiva el sistema web.
• Analizar el sistema de ventas del restaurant o local.
• Mantener un registro de los usuarios para su identificación.
• Generar reportes de gestión.
3.2 Ambiente de Ingeniería de Software
Metodología de desarrollo:
 Incremental e iterativa:
El Modelo Incremental combina elementos del MLS (Modelo Lineal Secuencial) con
la filosofía interactiva de construcción de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y
Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo
en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto
se mantiene al usuario en constante contacto con los resultados obtenidos en cada
incremento.
Es el mismo usuario el que incluye o desecha elementos al final de cada incremento

a fin de que el software se adapte mejor a sus necesidades reales. El proceso se
repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
16
Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza

interactiva, pero se diferencia de aquellos en que al final de cada incremento se entrega un
producto completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con una
dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo
reducido de personas y en cada incremento se añade personal, de ser necesario.
Por otro lado, los incrementos se pueden planear para gestionar riesgos técnicos.
Figura 1. Diagrama iterativo incremental.
Herramientas:
• Entorno de desarrollo Sublime Text 3.
• Framework Yii2.
• Consultas SQL en phpMyAdmin.
• Simulación del servidor Apache Xampp.
• Herramientas para modelado de información:
 yED modelado MER.
 MySQL Workbench.
Se utilizaron estas tecnologías dado a que nos facilitarán las tareas entorno a la
programación de nuestro sistema. El entorno de desarrollo Sublime Text 3 es un IDE de
programación. Es uno de los entornos de programación más completos en la actualidad,
permite editar códigos como PHP, HTML y JavaScript. El Framework Yii2 tiene como objetivo
permitir el uso de una sintaxis elegante y expresiva para crear código de forma sencilla y
permitiendo multitud de funcionalidades. Las consultas SQL se realizarán bajo el motor
phpMyAdmin, esta herramienta sirve para el manejo y administración de nuestro MySQL a
través de las páginas web utilizando Internet, este motor de Base de Datos permite crear,
eliminar y alterar tablas, borrar, editar y añadir campos y ejecutar cualquier sentencia SQL.
17
Para la simulación del servidor se utilizó la herramienta Apache Xampp el cual permitió la
gestión de bases de datos MySQL y los interpretes para lenguajes de script, PHP y Perl.
La herramienta para la implementación del MER fue yED, la cual es una herramienta editora
de diagramas, que permite una rápida generación de estos mediante una sencilla interface.
Para la administración de la base de datos se utilizó de MySQL WorkBench, esta herramienta
permite modelar diagramas Entidad-Relación para bases de datos MySQL.
3.3 Definiciones, Siglas y Abreviaciones
MLS: Modelo Lineal Secuencial. “Modelo de cascada”.

MER: Modelo Entidad Relación.
CU: Caso de Uso.
RF: Requisito Funcional.
RNF: Requisito No Funcional.
RFMU: Requisito Funcional Modulo Usuario.
RFMA: Requisito Funcional Modulo Administrador.
RFMR: Requisito Funcional Modulo Repartidor.
RNF: Requisito No Funcional
PSMU: Prueba de Sistema Modulo Usuario.
PSMA: Prueba de Sistema Modulo Administrador.
PSMR: Prueba de Sistema Modulo Repartidor.
18
CAPÍTULO 3
4 ESPECIFICACIÓN DE REQUERIEMIENTOS DE SOFTWARE
19
4.1 Alcances
• El Sistema de Pedidos de Comida Online deberá recibir pedidos solo de la cuidad de

Chillán y Chillán Viejo.
• El administrador del sistema, no podrá eliminar la cuenta del usuario, solo podrá
bloquear las cuentas.
• El sistema no permitirá crear nuevos perfiles, estos serán ingresados previamente
mediante una inserción en la base de datos (Cliente, Repartidor y Administrador).
• El sistema no permitirá modificar el formato de los reportes generados.
• El sistema no permitirá al administrador eliminar un pedido.
• El sistema no permitirá agregar nuevas funcionalidades a las cuentas de usuario.
• El sistema no permitirá cambiar las imágenes del Slider Carrusel (Página de Inicio).
• El sistema no permitirá cambiar las redes sociales que encuentran en el sistema.
• El sistema no se encargará de realizar ventas. Por lo tanto, una vez realizado el
pedido, el repartidor deberá llevar el encargo al lugar que el usuario específico.
Luego una vez efectuada la entrega y el pago del pedido, el mismo repartidor
deberá cambiar el estado del pedido efectuado recientemente.
• El sistema no permitirá al cliente agregar ingredientes a los pedidos, solo
permitirá quitar ingredientes y este se efectuará mediante un cuadro de texto, el
cual el cliente podrá escribir lo que desea quitar al producto al momento de
realizar el pedido.
4.2 Objetivo del software
Objetivo general:
El software manejará y administrara gran parte de la gestión de un Sistema de Pedidos de
Comida Online a través de una página web, en la que estarán claramente señaladas por
pestañas las secciones de catálogo, carro, pedido, etc. Esto también contribuirá en la gestión y
planificación integral de la empresa de nuestro cliente, logrando una optimización en su
sistema de ventas.
20
Objetivos específicos:
1. El software apoyará el Sistema de Pedidos de Comida, desde la realización del pedido
hasta su despacho.
2. El software gestionará y almacenará los pedidos y las ventas con motivo de respaldar
información crítica de la empresa.
3. El software permitirá a la empresa un mayor alcance hacia el usuario mediante una
plataforma web sin la necesidad de dirigirse a la empresa.
4. El software permitirá generar informes de las ventas realizadas.
4.3 Descripción global del producto.
4.3.1 Interfaz de usuario.
Según las opiniones de diferentes locales situadas en las Ciudad de Chillán, se logró llegar a
sacar un resultado de las opiniones obtenidas:
Los locales se enfocaban en:
• Tener el loco del local en la parte superior del sistema.

• En la sección de abajo tener los productos que ofrecerán.
• Para finalizar que las secciones para acceder a las opciones, se encontraran al lado
del logo de la empresa.
4.3.2 Interfaz de hardware.

La interfaz de hardware, se requerirán de dispositivos para procesar y entregar datos al
software tales como: pantalla táctil, teclado, ratón, y pantalla, además se requerirá de
conexión a internet.
4.3.3 Interfaz de software.

La información y los procesos que se ejecutarán serán mediante la utilización del protocolo
web HTTP, el cual está orientado al funcionamiento del tipo “Petición-Respuesta”, por lo que
requeriremos de un cliente y de un servidor para la comunicación. Siendo el cliente quien
efectué las peticiones y el servidor quien las responde.
21
4.4 Requerimientos Específicos
Los requisitos funcionales describen la funcionalidad o los servicios del sistema.

En esta sección se especificarán los requisitos funcionales del Sistema de Pedidos de Comida
Online.
4.4.1 Requerimientos Funcionales del Módulo de Usuario.
Los siguientes requisitos funcionales corresponden a el módulo de Usuario
ID Nombre Descripción Cumplimiento Notas Estado

RFMU_01 Registro de El Sistema de Pedidos de Cumple. La información que Implementado.
usuarios. Comida Online deberá se le solicitará a los
almacenar la usuarios en el
información de los registro será:
usuarios mediante un nombre, apellido
previo registro en línea. paterno, apellido
materno, dirección,
teléfono, email,
username y
password.
RFMU_02 Modificar datos El Sistema de Pedidos de Cumple. Los datos que podrá Implementado.
personales. Comida Online deberá modificar el usuario
permitir al usuario son:
modificar los datos de su dirección, teléfono,
cuenta de usuario. email y password.
RFMU_03 Listar productos El Sistema de Pedidos de Cumple. - Implementado.
por categoría. Comida Online deberá
permitir al usuario listar
productos de acuerdo a
categorización.
RFMU_04 Agregar productos El Sistema de Pedidos de Cumple - Implementado.
al carro de Comida Online deberá
compras. permitir al usuario
agregar productos a un
carro de compras.
Tabla 1. Requerimientos funcionales del módulo Usuario.
22

RFMU_05 Eliminar productos El Sistema de Pedidos Cumple. - Implementado.
del carro de de Comida Online
compras. deberá permitir al
usuario eliminar
productos del carro de
compras.
RFMU_06 Realizar pedidos en El Sistema de Pedidos Cumple. - Implementado.
línea. de Comida Online
deberá permitir a los
usuarios registrados
realizar pedidos en
línea.
RFMU_07 Visualizar pedidos. El Sistema de Pedidos Cumple. - Implementado.
de Comida Online
deberá permitir al
usuario generar un
listado con la
información de sus
pedidos en el sistema.
Tabla 2. Requerimientos funcionales del módulo Usuario.
23
4.4.2 Requerimientos Funcionales del Módulo de Administrador.
Los siguientes requisitos funcionales corresponden a el módulo de Administrador

RFMA_01 Registro de El Sistema de Pedidos Cumple. - Implementado.
categorías. de Comida Online
deberá permitir al
administrador,
registrar nuevas
categorías.
RFMA_02 Visualizar El Sistema de Pedidos Cumple. - Implementado.
categorías. de Comida Online
deberá permitir al
administrador,
visualizar las
categorías.
RFMA_03 Eliminar categorías. El Sistema de Pedidos Cumple. Se podrá eliminar Implementado.
la categoría solo
de Comida Online
si no tiene
deberá permitir al productos
relacionados.
administrador,
eliminar categorías
existentes en el
sistema.
RFMA_04 Modificar El Sistema de Pedidos Cumple. El administrador Implementado.
Categorías. de Comida Online solo podrá
deberá permitir al modificar el
administrador nombre de la
modificar categorías. categoría.
RFMA_05 Registro de El Sistema de Pedidos Cumple. - Implementado.
productos. de Comida Online
deberá permitir al
administrador,
registrar productos.
Tabla 3. Requerimientos funcionales del módulo Administrador.
24

RFMA_06 Visualizar productos. El Sistema de Pedidos Cumple. - Implementado.
de Comida Online
deberá permitir al
administrador,
visualizar los productos
del sistema.
RFMA_07 Eliminar productos. El Sistema de Pedidos Cumple. - Implementado.
de Comida Online
deberá permitir al
administrador, eliminar
productos existentes en
el sistema.
RFMA_08 Modificar datos de El Sistema de Pedidos Cumple. Los datos que Implementado.
productos. de Comida Online podrá modificar
deberá permitir al son: nombre,
administrador, detalle, categoría,
modificar los datos de precio, stock y la
un determinado imagen.
producto.
RFMA_09 Crear estados. El Sistema de Pedidos Cumple. - Implementado.
de Comida Online
deberá permitir al
administrador, crear
estados para los
pedidos.
RFMA_10 Modificar estado. El Sistema de Pedidos Cumple. El administrador Implementado.
de Comida Online podrá modificar
deberá permitir al solo el nombre
administrador del del estado.
sistema modificar el
estado.
RFMA_11 Visualizar estados El Sistema de Pedidos Cumple. - Implementado.
de Comida Online
deberá permitir al
administrador
visualizar los estados
del sistema.
25

RFMA_12 Visualizar pedidos. El Sistema de Pedidos Cumple. - Implementado.
de Comida Online
deberá permitir al
administrador
generar un listado
con la información de
los pedidos realizados
por los usuarios en el
sistema.
RFMA_13 Modificar estado de El Sistema de Pedidos Cumple. - Implementado.
un pedido. de Comida Online
deberá permitir al
administrador
modificar el estado de
un pedido.
RFMA_14 Modificar rol de El Sistema de Pedidos Cumple. Solo puede Implementado.
usuarios. de Comida Online modificar el
deberá permitir al perfil.
administrador
modificar a los
usuarios del sistema.
RFMA_15 Visualizar usuarios. El Sistema de Pedidos Cumple. - Implementado.
de Comida Online
deberá permitir al
administrador
visualizar a los
en el sistema.
RFMA_16 Bloquear usuarios. El Sistema de Pedidos Cumple. - Implementado.
de Comida Online
deberá permitir al
administrador
bloquear a los
en el sistema.
26

RFMA_17 Reporte de ventas El Sistema de Pedidos Cumple. - Implementado.
por rango de fecha. de Comida Online
deberá permitir al
administrador,
generar un reporte de
ventas por rango de
fecha.
RFMA_18 Visualizar mapa del El Sistema de Pedidos Cumple - Implementado.
pedido. de Comida Online
deberá permitir al
administrador,
visualizar el mapa de
los pedidos.
27
4.4.3 Requerimientos Funcionales del Módulo de Repartidor.
Los siguientes requisitos funcionales corresponden a el módulo de Repartidor

RFMR_01 Visualizar pedidos. El sistema para Cumple. - Implementado.
pedidos de comida
online deberá
permitir al repartidor
visualizar los pedidos
realizados por los
en el sistema.
RFMR_02 Modificar estado de El sistema para Cumple. - Implementado.
un pedido. pedidos de comida
online deberá
permitir al repartidor
modificar el estado de
un pedido.
RFMR_03 Visualizar mapa del El Sistema de Pedidos Cumple. - Implementado.
pedido. de Comida Online
deberá permitir al
repartidor, visualizar
el mapa de los
pedidos.
Tabla 7. Requerimientos funcionales del módulo Repartidor.
28
4.4.4 Interfaces externas de entrada
ID Nombre Datos
Username, nombre, apellido, dirección particular, dirección
ESPCO_01 Datos del usuario.
envío, celular, email, password.
Datos para modificar la Dirección particular, dirección envío, celular, email,
ESPCO_02
información del usuario. password.
ESPCO_03 Datos del producto. Nombre, precio, stock, descripción, imagen, categoría.
ESPCO_04 Datos de la categoría. Nombre.
Tabla 8. Interfaces externas de entrada.
4.4.5 Interfaces externas de Salida
ID Nombre Datos
Listado de pedidos del
SSPCO_01 ID Pedido, Estado, fecha pedido, fecha despacho.
usuario.
SSPCO_02 Listado de productos. ID Producto, precio, nombre, detalle, stock.
ID Usuario, nombre de usuario, teléfono, nombre, apellido,
SSPCO_03 Listado de usuarios.
dirección particular.
ID Pedido, ID Usuario, ID Estado, fecha pedido, dirección
SSPCO_04 Listado de pedidos.
pedido, precio.
SSPCO_05 Listado de categorías. Nombre.
Tabla 9. Interfaces externas de salida.
29
4.4.6 Atributos del producto
Los requisitos no funcionales definen propiedades y restricciones del sistema. En esta

sección se especificarán los requisitos no funcionales y las restricciones del Sistema de
Pedidos de Comida Online.

RNF_01 Control de El Sistema de Pedidos de Comida Online Cumple. - Implementado.
acceso. deberá realizar control de acceso, a
través de login-password establecido
según los perfiles definidos para los
usuarios del sistema.
RNF_02 Breve tiempo de El Sistema de Pedidos de Comida Online Cumple. - Implementado.
respuesta. deberá tener a lo más un tiempo de
respuesta de 5 segundos considerando
una conexión de red de velocidad
estándar de 1 Mbyte/s y 50 usuarios
conectados.
RNF_03 Mensajes de El Sistema de Pedidos de Comida Online Cumple. - Implementado.
error. deberá indicar claramente a través de un
mensaje, el error y la solución ante
cualquier operación relacionada con el
ingreso y procesamiento de datos.
RNF_04 Mensaje para El Sistema de Pedidos de Comida Online Cumple. - Implementado.
autentificar el validar en cada operación el llenado de
llenado de campos.
campos.
RNF_05 Sugerencias en El Sistema de Pedidos de Comida Online Cumple. - Implementado.
campos de deberá mostrar mensajes de sugerencias
llenado. de llenado en cada campo.
RNF_06 Interfaz gráfica. El Sistema de Pedidos de Comida Online Cumple. - Implementado.
deberá permitir al usuario, mediante una
interfaz gráfica, interactuar con los
elementos gráficos del sistema.
Tabla 10. Requerimientos no funcionales del sistema.
30
CAPÍTULO 4
5 FACTIBILIDAD
31
A continuación, se realizará un estudio de factibilidad, este nos permitirá analizar la viabilidad del
desarrollo del sistema de pedido de comida online.
Se evaluará los siguientes dos aspectos:
• Factibilidad técnica: Evalúa la viabilidad en cuanto a recursos de software, hardware y
recursos humanos competentes y necesarios para el correcto desarrollo del proyecto.
• Factibilidad operacional: Evalúa la viabilidad en cuanto al futuro uso y aceptación de
los usuarios finales.
• Factibilidad económica: Evalúa la viabilidad en cuanto a los costos del proyecto, es
decir, durante el desarrollo y la puesta en marcha. Además, se evalúan los beneficios
futuros que se obtendrá al poner en marcha el sistema.
5.1 Factibilidad Técnica
Este estudio determinará si el equipamiento técnico que se utilizara y los recursos humanos
con el que se dispone durante el desarrollo permiten la realización del proyecto.
5.2 Requerimientos técnicos para el desarrollo
Como lenguaje de programación se utilizó PHP y JavaScript, como gestor de base de datos se
utilizó MySQL, lenguaje de consulta SQL y Disponibilidad en cualquier momento mientras
exista alguna conectividad a internet.
Con lo mencionado anteriormente, se utilizó un equipo computacional que posee las
siguientes características:
Procesador: Intel core i7 de 2.0 GHz.
Memoria RAM: 8GB.
Almacenamiento: 1 TB.
Sistema Operativo: Windows 8.1 de 64 bits.
Software necesario para el desarrollo
Se requerirá tener instalado en el equipo de desarrollo las siguientes herramientas:
• Entorno de desarrollo Sublime Text 3.
• Framework Yii2.
• Consultas SQL en phpMyAdmin.
• Simulación del servidor Apache Xampp.
• Herramientas para modelado de información:
 yED modelado MER.
 MySQL Workbench.
Todos estos cuentan con una licencia gratuita.

5.3 Factibilidad operacional
La factibilidad operacional es la relación con el grado de aceptación que tendrá la solución

por parte de los potenciales usuarios, así como los obstáculos que pueden existir para su
desarrollo y posterior utilización.
Hoy en día los usuarios que regularmente compran productos de comida realizan los
pedidos a los locales de forma telefónica o mediante las redes sociales, pero al momento de
realizar los pedidos siempre falta información que no les permite realizar estos de forma
rápida y segura, con esto me refiero a que tienen que estar preguntando al operador de los
sistemas recién mencionado especificaciones de los productos que desea comprar y el
operador pide información para poder realizar él envió, con el sistema de pedido de comida
32
online proponemos un sistema más automatizado que ayudara tanto al cliente como al
dueño del local.
Los usuarios tendrán toda la información de los productos del local y podrán realizar
pedidos en línea, en los cuales tendrán toda la información de estos.
El dueño del local podrá tener la información de los usuarios y también de los pedidos
realizados, con esto poder visualizar las ventas realizadas en un rango de fecha, con esto
mejoraremos y remplazaremos los antiguos sistemas con los cuales proporcionaban los
repartos a sus usuarios.
Como conclusión del estudio de factibilidad operacional, podemos determinar que ambas
partes de este negocio podrán salir beneficiados con los cambios que se quieren
implementar.
5.4 Factibilidad económica
En este último estudio se determinan los recursos necesarios para desarrollar el proyecto,
los costos en los que se debe incurrir para su fabricación y los beneficios que se obtendrán a
partir de la implementación del sistema.
5.4.1 Costos de desarrollo

Hardware y Software de desarrollo: Los costos asociados a hardware y software para el
desarrollo del Sistema de Pedidos de Comida Online será de un total de $0, dado a que se
tienen las máquinas para el desarrollo del sistema y los softwares son de licencia gratuita.
Ingeniero Civil en Informática: Para la realización de este proyecto, se requerirá de un
Ingeniero Civil en Informática, según el Ministerio de Educación de Chile el sueldo promedio
es de $1.561.000, por ende, el costo de hora/hombre es de $9.756. El proyecto contempla un
periodo de 4 meses, con un trabajo de 20 horas semanales, lo que se traduce en un total de
400 horas. El costo total del Ingeniero Civil en Informática es de $3.902.400.
Técnico en Diseño Gráfico: Para la realización de este proyecto, se requiere de un Técnico
en Diseño Gráfico, según el Ministerio de Educación de Chile el sueldo promedio es de
$433.165, por ende, el costo de hora/hombre estimado es de $2.707. El diseño de la interfaz
del sistema contempla un periodo de dos semanas, con un trabajo de 20 horas semanales, lo
que se traduce en un total de 40 horas. El costo total del Técnico en Diseño Gráfico es de
$108.280.
5.4.2 Costos de operación

Hardware y Software del servidor: Para la puesta en marcha del sistema se requiere de un
hosting, el cual tiene un costo anual aproximado de $78.400 IVA incluido. Las características
de este hosting son: 1GB de memoria RAM, Procesador de 1 núcleo, Disco duro sólido de 30
GB y 2 TB de transferencia (DigitalOcean, Princing).
33
5.4.3 Costos de mantención

Técnico en Computación e Informática: Para la realización de un proyecto, se requiere de
un Técnico en Computación e Informática, según el Ministerio de Educación de Chile el
sueldo promedio es de $507.094, por ende, el costo de hora/hombre estimado es de $3.169.
Las funciones de este profesional es brindar soporte al local y efectuar mantención en el
sistema web. Es importante destacar que este proyecto no contempla la contratación de un
Técnico en Computación e Informática ya que depende del cliente si es que desea este
profesional.
Costos de desarrollo
Hardware y Software / Herramientas 0
Ingeniero Civil en Informática $3.902.400
Diseñador Gráfico $108.280
Costo total de desarrollo $4.010.680
Costo de operación
Hardware 0
Hosting $78.400
Costo total de operación $78.400
Costo de Mantención
Técnico en Computación e Informática 0
Costo total de mantención 0
COSTO TOTAL $4.089.080
5.5 Beneficios
Beneficios tangibles:
• Incremento de la productividad de los procesos que se realizan en el local.
• Reducción de costos en propaganda.
• Incremento al público que se quiera llegar.
• Incremento en los ingresos económicos del local.
Beneficios intangibles:
• Ahorro de tiempo y esfuerzo al usuario al realizar un pedido en línea.
• Mejora la capacidad de toma de decisiones para el administrador del local.
• Mejora del servicio de atención a los usuarios.
• Mejora la precisión, ya que se efectúan cálculos matemáticos automatizados en las
ventas y se realizan rutas de viaje para el Repartidor.
• Mejora la difusión del nombre del local.
34
5.6 Flujo de caja
Actualmente en la Cuidad de Chillán, existe un universo variado empresas del rubro de venta
de comida, dispuestas a adquirir tecnologías de la información. Al vender el servicio web a
estas empresas, cobrando la suma mencionada anteriormente que es de $4.089.080, en este
monto está considerado el sueldo del Ingeniero Civil en Informática y el del Diseñador
Gráfico, también tiene incluido el costo de arriendo anual del servidor, pero no está
considerado el costo de mantención.
Cabe mencionar que nosotros aproximamos las ganancias extras que podrán tener la
empresa que solicite la utilización de nuestro sistema, estas serán de $180.000 semanales, es
decir, $8.640.000 anual, (estos cálculos fueron sacados con aproximados de las ventas de los
negocios que cuentan con este medio de ventas).
Para determinar la factibilidad económica del proyecto se utilizará el indicador VAN, cuyo
valor proporcionará un criterio de decisión frente a esta.
Año 0 Año 1 Año 2 Año 3 Año 4 Año 5

Ingresos
• Beneficios 0 $8.640.000 $8.640.000 $8.640.000 $8.640.000 $8.640.000
Costos
• Hosting ($78.400) ($78.400) ($78.400) ($78.400) ($78.400) ($78.400)
• Mantención 0 0 0 0 0 0
Inversión
• Costos de ($4.010.680) 0 0 0 0 0
desarrollo
TOTAL ($4.089.080) $8.561.600 $8.561.600 $8.561.600 $8.561.600 $8.561.600

Tabla 11.Flujo de Caja.
5.6.1 Calculo del VAN

Para el cálculo del indicador VAN se utiliza la siguiente ecuación:
Figura 2. Ecuación calculo VAN

Donde:
• Vt: Representa los flujos de caja para el periodo t.
• Io: representa la inversión total inicial.
• n: es el número de periodos considerados.
• k: es la tasa de descuento o mínima rentabilidad exigida.
Para efectos del cálculo de considerará una tasa de descuento de 13%.

Considerando los datos antes mencionados, se realizará el cálculo de VAN correspondiente,
este corresponde a un caso en que la realización del proyecto se desarrolla de forma
tradicional (considerando los costos y gastos dispuestos en la Tabla Resumen de costos).
35
El VAN resultó ser positivo, lo cual indica que invertir en este sistema es rentable para
cualquier negocio de venta de comida que aún no tiene ventas online y quiera adquirirlo.
5.7 Conclusión de la factibilidad
Este proyecto es totalmente viable desde el punto de vista técnico y operacional. Además,
desde el punto de vista de la factibilidad económica se obtiene un VAN positivo, lo que
demuestra que también es viable económicamente, si es que se quisiera invertir en un
informático para la mantención de este proyecto, con lo visto en la factibilidad económica,
puede ser una opción totalmente aceptable dado a los beneficios económicos que traería el
uso de nuestro sistema.
36
CAPÍTULO 5
6 PROPUESTA DE SOLUCIÓN
37
6.1 Solución a la Problemática
Dada la problemática que se nos presentó al comienzo de este proyecto, en este punto
queríamos dejar en claro cuáles serán nuestras soluciones a dichas problemáticas.
Problemática Solución
Difundir la empresa a Con la creación de la página web se podrá tener en concreto un lugar
través de internet, así en donde las personas puedan acceder y conocer de una mejor manera
como también tener la los productos que ofrezca un local, también dentro de esta misma
opción de realizar página el cliente podrá realizar pedidos de comida de los productos
pedidos en el mismo seleccionados.
sitio web.
Regular y monitorear Por parte de la administración, se podrá modificar los estados de los
el estado de un pedido pedidos para que el cliente tenga un monitoreo de este.
de comida. Por parte del cliente este podrá saber en qué estado se encuentra su
pedido, por ejemplo : Pendiente, En Preparación, En Camino, etc.
También es importante destacar que daremos solución efectiva en la manera de poder

visualizar la dirección de un pedido, con esto nos referimos a que el repartidor podrá ver en
algún dispositivo móvil la dirección del pedido en Google Maps, también generará una ruta
en la cual podrá llegar a su destino.
Otro punto importante a destacar, el Administrador podrá generar un reporte de ventas
por rango de fechas, este documento será en formato PDF y se descargará a su
computadora.
38
CAPÍTULO 6
7 INCREMENTOS
39
7.1 Primer Incremento
7.1.1 Análisis
7.1.1.1 Diagrama de casos de uso

En el contexto de ingeniería de software, un caso de uso es una secuencia de interacciones
que se desarrollaran entre un sistema y sus actores en respuesta a un evento que inicia un
actor principal sobre el propio sistema.
A continuación, se presentarán los actores, diagramas y especificación de casos de uso
desarrollados en el primer incremento del Sistema de Pedidos de Comida Online.
7.1.1.1.1 Actores
Los personajes o entidades que participarán en un caso de uso se denominan actores.
Usuario:
• Rol: Representa al usuario del Sistema de Pedidos de Comida Online.

• Nivel de conocimientos técnicos requeridos: Conocimientos básicos en computación.
• Nivel de privilegio en el sistema: Privilegios limitados con acceso a funcionalidades
tales como; registrar cuenta, ver galería de productos, realizar pedidos, listar pedidos
y modificar datos de la cuenta.
Administrador:
• Rol: Representa al administrar del Sistema de Pedidos de Comida Online.

• Nivel de privilegio en el sistema: Privilegios máximos con acceso a las
funcionalidades administrativas del sistema, tales como; registrar productos,
registrar categorías, listar pedidos de usuarios, eliminar productos y categorías, ver
galería de productos, despachar pedidos, listar usuarios y generar reportes
7.1.1.1.2 Casos de Uso y descripción

Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento
de un sistema mediante su interacción con los usuarios y/u otros sistemas.
A continuación, se presentarán los casos de uso y su descripción desarrollados en el primer
incremento.
40
Usuario
Figura 2. Diagrama de caso de uso del Usuario.
Descripción:
El actor usuario sin autentificación podrá:
Crear: Cuenta de usuario.
Modificar: Sus datos de usuario.
41
Administrador
Figura 3. Diagrama de caso de uso del Administrador.
Descripción:
El actor Administrador de la empresa mediante una previa autentificación en el Sistema de
Pedidos de Comida Online podrá:
Visualizar: Estados, Categorías y Usuarios existentes en el sistema.
Crear: Nuevos Estados, Nuevas Categorías.
Modificar: Nombre de los Estados, Nombre de las Categorías.
Eliminar: Categorías existentes en el sistema.
7.1.1.1.3 Especificación de los Casos de Uso

El comportamiento de un caso de uso se especifica describiendo la secuencia de acciones que
el sistema debe llevar a cabo para proporcionar un servicio. Esta secuencia de acciones,
habitualmente denominada flujo de eventos, debe escribirse de forma que sea lo
suficientemente clara como para que alguien ajeno al sistema pueda entenderlo fácilmente.
A continuación, se especificarán los casos de usos más importantes desarrollados en el
primer incremento, los demás casos de uso se encontrarán especificados en el punto
denominado Anexos.
42
7.1.1.1.3.1 Especificación caso de uso módulo Usuario.
Nombre Registro de Usuario. ID CU_01

Actores Usuario.
Referencias Registro de usuarios. (RFMU_01)
Precondiciones El actor usuario debe estar dentro del sistema de pedidos de comida
online.
Post-condiciones El actor usuario quedará registrado en el sistema de pedidos de comida
online.
Autor Juan Zapata Fuentes. Fecha 03/10/2016
Propósito Almacenar la información del usuario mediante un previo registro en
línea.
Flujo Principal 1. El caso de uso empieza cuando el actor usuario ingresa en la opción
“Registrar Cuenta” del menú principal del sistema de pedidos de comida
online.
2. El actor usuario ingresa su username, password, nombre, apellidos,
dirección particular, número telefónico, correo electrónico.
3. El actor usuario aprieta el botón “Registrar”.
4. El Sistema de Pedidos de Cominda Online verifica que los datos hayan
sido ingresados y sean correctos.
5. El Sistema de Pedidos de Comida Online almacena los datos del
usuario.
6. Finaliza el caso de uso.
Flujos Alternos 4a. Si no se completa uno de los campos solicitados, el Sistema de Pedidos
de Comida Online mostrará el mensaje: “Campo no puede estar vacío”.
4b. Si se ingresa un username o un email ya registrado, el Sistema de
Pedidos de Comida Online mostrará el siguiente mensaje: “El username
ingresado ya está en uso”.
Estado Cumple.
Comentarios
Tabla 12. Caso de Uso Registro de Usuario.
43
Nombre Modificar Datos Personales. ID CU_02

Actores Usuario.
Referencias Modificar datos personales. (RFMU_02)
online.
Post-condiciones El Sistema de Pedidos de Comida Online permitirá modificar datos del
usuario.
Autor Sebastián Oñate Mena. Fecha 03/10/2016
Propósito Modificar los datos personales del usuario.
“Datos Personales” del menú principal del sistema de pedidos de comida
online.
2. El Sistema de Pedidos de Comida Online muestra los datos personales
del usuario.
3. El usuario modifica los datos.
4.El usuario presiona el botón “Modificar”.
Flujos Alternos 3a. Si no se completa uno de los campos solicitados, el Sistema de Pedidos
de Comida Online mostrará el mensaje: “Campo no puede estar vacío”.
3c. Si se ingresa un email ya registrado, el Sistema de Pedidos de Comida
Online mostrará el siguiente mensaje: “El email ingresado ya está en uso”.
Estado Cumple.
Comentarios
Tabla 13. Caso de Uso Modificar Datos Personales.
44
7.1.1.1.3.2 Especificación caso de uso módulo Administrador.
Nombre Registro de Categoría ID CU_03

Actores Administrador.
Referencias Registro de Categoría (RFMA_01).
Precondiciones El actor administrador debe estar dentro del sistema de pedidos de
comida online.
Post-condiciones El Sistema de Pedidos de Comida Online deberá permitir al
administrador registrar una categoría nueva en el sistema.
Propósito Registrar categorías en el sistema.
Flujo Principal 1. El caso de uso empieza cuando el actor administrador ingresa en la
opción “Categorías” del menú principal del Sistema de Pedidos de
Comida Online (en el lado izquierdo de la pantalla).
2. El Sistema de Pedidos de Comida Online muestra las categorías
existentes en el sistema.
3. El administrador debe hacer click en el botón verde que dice “Agregar
categoría”.
4. El sistema muestra el capo para poder darle un nombre a la categoría
nueva.
5. El administrador rellena el campo y da click en el botón verde que dice
“crear”
Flujos Alternos 5a. Si no rellena el campo del nombre de la categoría nueva a crear, el
sistema envía un mensaje diciendo “el campo no puede estar vacío “
Estado Cumple.
Comentarios
Tabla 14. Caso de Uso Registro de Categoría.
45
Nombre Eliminar Categoría ID CU_05

Referencias Eliminar Categoría (RFMA_03).
comida online.
administrador eliminar las categorías.
Propósito Eliminar categorías en el sistema.
3. El Administrador hace click en el botón de color rojo con un icono de
basurero.
4. El sistema muestra un mensaje que dice “¿Esta seguro que desea
eliminar esta categoría? “
5. El administrador hace un click en el botón “Aceptar”.
Flujos Alternos 2a. Si no existen registradas en el sistema, este no mostrará nada.
Estado Cumple.
Comentarios
Tabla 15. Caso de Uso Eliminar Categoría.
46
Nombre Modificar Categoría ID CU_06

Referencias Eliminar Categoría (RFMA_04).
comida online.
administrador modificar las categorías.
Propósito Modificar categorías en el sistema.
3. El Administrador hace click en el botón de color azul con un icono de
un lápiz.
4. El sistema muestra el capo para poder darle un nombre a la categoría.
5. El administrador rellena el campo y da click en el botón azul que dice
“Modificar”
5a. Si no rellena el campo del nombre de la categoría a modificar, el
sistema envía un mensaje diciendo “El campo no puede estar vacío “
Estado Cumple.
Comentarios
Tabla 16. Caso de Uso Modificar Categoría.
47
Nombre Visualizar Usuarios ID CU_10

Referencias Visualizar Usuarios (RFMA_15).
comida online.
administrador visualizar los usuarios existentes en el sistema.
Propósito Visualizar Usuarios en el sistema.
opción “Usuarios” del menú principal del Sistema de Pedidos de Comida
Online (en el lado izquierdo de la pantalla).
2. El Sistema de Pedidos de Comida Online muestra los Usuarios
Flujos Alternos
Estado Cumple.
Comentarios
Tabla 17. Caso de Uso Visualizar Usuarios.
48
7.1.2 Diseño
7.1.2.1 Diseño de Físico de la Base de datos

El modelo relacional, para el modelado y la gestión de bases de datos, es un modelo de datos
basado en la lógica de predicados y en la teoría de conjuntos.
A continuación, se presenta el Modelo Relacional (MR) correspondiente al diseño físico de la
base de datos del Sistema de Pedidos de Comida Online.
Figura 4. Diseño físico de la Base de Datos.
49
7.1.2.2 Diseño interfaz y navegación
7.1.2.2.1 Diseño de la interfaz

El diseño de la interfaz se enfoca en la experiencia de usuario y su interacción.
Las siguientes Figuras mostraran de manera global como será la relación del sistema con los
distintos actores.
Las figuras serán las más significativas para el incremento en cuestión.
7.1.2.2.1.1 Módulo de Usuario
• Sub-módulo de Registro
Figura 5. Interfaz del Sub-módulo de Registro.
50
• Sub-módulo de Modificar Datos Personales.
Figura 6. Interfaz del Sub-módulo de Productos.
Figura 7. Interfaz del Sub-módulo de Modificar Datos Personales.
51
7.1.2.2.1.2 Módulo de Administrador
• Sub-módulo de Crear Categoría.
Figura 8. Interfaz del Sub-módulo de Crear Categorías.
52
• Sub-módulo de Usuarios en el sistema
Figura 9. Interfaz del Sub-módulo de Usuarios en el Sistema.
53
7.1.3 Pruebas
7.1.3.1 Elementos de prueba

En el Sistema de Pedidos de Comida Online se realizaron pruebas a las funciones principales
de los dos módulos desarrollados, los cuales se detallarán a continuación:
• Usuario: se realizaron pruebas al registro de usuario y a la modificación de datos
personales.
• Administración: se realizaron pruebas al registro, eliminación y modificación de
una categoría, como también a la visualización de los usuarios registrado en el
sistema.
7.1.3.2 Especificación de las pruebas

En esta sección, se presentarán las pruebas de Sistema para el proyecto.
7.1.3.2.1 Pruebas de sistema.
Pruebas de sistema.
Características a probar. Funcionalidad
Nivel de prueba. Sistema
Objetivo de la prueba. Probar y validar que el software funcione correctamente.
Enfoque de la prueba. Caja negra.
Técnicas de definición de Se utilizarán valores límites y anómalos
casos de prueba.
Actividades de prueba. • Se establecerán los escenarios a ser probados.
• Se ejecutarán las funcionalidades del sistema para
verificar que no existan anomalías
• Se analizarán los resultados
• Se procederá a un oportuno control en caso de que la
prueba entregue información errónea
Criterios de cumplimiento. La ejecución de todas las pruebas debe corresponder con la
funcionalidad que se espera como resultado, obteniendo así un
control de todos los incidentes que puedan ocurrir
Tabla 18. Especificación de Pruebas de Sistema.
54
7.1.3.3 Responsable de las pruebas.

Las pruebas de sistema fueron realizadas y verificadas por los desarrolladores del sistema
Sebastián Oñate Mena y Juan Zapata Fuentes.
7.1.3.4 Detalle de las pruebas.
7.1.3.4.1 Plan de pruebas de sistema.

Se consideraron las funciones y módulos más importantes del Sistema de Pedidos de Comida
Online para la ejecución de las pruebas de sistema.
Las demás pruebas desarrolladas se encuentran en la sección Anexos.
7.1.3.4.1.1 Pruebas de sistema para el módulo Usuario.

A continuación, se presentarán los casos de pruebas de sistema para el Modulo de Usuario.
Caso de prueba Modificar datos personales de cuenta de usuario.
ID prueba PSMU_01 Fecha 17/11/2016
Propósito El Sistema de Pedidos de Comida Online deberá permitir modificar o
actualizar los datos en la cuenta del usuario.
Tipo de prueba Caja Negra.
Referencia (RF) Modificar datos personales. Actores Usuario
(RFMU_02)
Pre-condición Tener una cuenta registrada en el sistema.
El usuario registrado debe estar dentro del Sistema de Pedidos de Comida
Online.
Flujo principal • El usuario presiona la opción “DATOS PERSONALES”.
• El Sistema de Pedidos de Comida Online re-direcciona al usuario a
sus datos personales.
• El usuario modifica los datos a actualizar.
• El usuario presiona el botón “Modificar”.
• El Sistema de Pedidos de Comida Online notifica al usuario que su
actualización fue correcta.
Prueba Valores de prueba Resultado Resultado Evaluación.
esperado obtenido
1 (Caso valido) Dirección El sistema El sistema Aprobado.
Particular: cabildo almacenara los notifica al
540 datos usuario
Teléfono: actualizados por mediante un
996918618 el usuario. mensaje
Email: emergente que
[email protected] los datos
Contraseña: actualizados
123456 fueron
modificados
correctamente.
Tabla 19. Pruebas de sistema para el Modulo Usuario.
55
7.1.3.4.1.2 Pruebas de sistema para el modulo Administrador.

A continuación, se presentarán los casos de pruebas de sistema para el Modulo de Administrador.
Caso de prueba Crear categorías.

ID prueba PSMA_01 Fecha 19/11/2016
Propósito El Sistema de Pedidos de Comida Online deberá permitir al administrador del
sistema, agregar categorías en el sistema.
Referencia (RF) Registro de categorías. (RFMA_01) Actores. Administrador
El administrador registrado, debe estar dentro del Sistema de Pedidos de
Comida Online.
Flujo principal • El administrador ingresa a la opción “Categorías” en la columna a
mano izquierda del sistema.
• El administrador presiona el botón “Agregar categoría”.
• El Sistema de Pedidos de Comida Online re-direcciona al
administrador al nombre de la categoría que quiera crear.
• El administrador llena el campo.
• El administrador presiona “Crear”, para agregar una nueva
categoría.
administrador al grupo de categorías existentes en el sistema.
Prueba Valores de Resultado Resultado obtenido Evaluación.
prueba esperado
1 (Caso válido) Nombre El sistema El sistema almacena Aprobada
Categoría: Pizzas deberá la categoría
almacenar la ingresada,
categoría informando al
ingresada. administrador de su
correcta creación
con un mensaje
emergencia, además
lo re-direcciona a
todas las categorías
existentes en el
sistema
2 (Caso no Nombre: (vacío) El sistema El sistema notifica al Aprobada
válido) deberá validar el administrador,
llenado de identificando en
campos, rojos los campos
notificando al que no pueden estar
administrador vacíos, mostrando
en caso que no se el siguiente texto
cumpla con esta para el caso
condición. “Nombre categoría
no puede estar
vacío”.
Tabla 20. Pruebas de sistema para Modulo Administrador.
56
7.2 Segundo Incremento
7.2.1 Análisis
7.2.1.1 Diagrama de casos de uso

En el contexto de ingeniería de software, un caso de uso es una secuencia de interacciones
que se desarrollaran entre un sistema y sus actores en respuesta a un evento que inicia un
actor principal sobre el propio sistema.
A continuación, se presentarán los actores, diagramas y especificación de casos de uso
desarrollados en el segundo incremento del Sistema de Pedidos de Comida Online.
7.2.1.1.1 Actores
Los personajes o entidades que participarán en un caso de uso se denominan actores.
Usuario:
• Rol: Representa al usuario del sistema de pedidos de comida online.

• Nivel de privilegio en el sistema: Privilegios limitados con acceso a funcionalidades
tales como; registrar cuenta, ver galería de productos, realizar pedidos, listar pedidos
y modificar datos de la cuenta.
Administrador:
• Rol: Representa al administrar del sistema de pedidos de comida online.

• Nivel de privilegio en el sistema: Privilegios máximos con acceso a las
funcionalidades administrativas del sistema, tales como; registrar productos,
registrar categorías, listar pedidos de usuarios, eliminar productos y categorías, ver
galería de productos, despachar pedidos, listar usuarios y generar reportes.
Repartidor:
• Rol: Representa al repartidor del sistema de pedidos de comida online.

• Nivel de privilegio en el sistema: Privilegios limitados con acceso a la funcionalidad
de modificar los estados de los pedidos realizados.
57
7.2.1.1.2 Casos de Uso y descripción

Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento
de un sistema mediante su interacción con los usuarios y/u otros sistemas.
Usuario
Figura 10. Diagrama de caso de uso del Usuario.
Descripción:
El actor usuario sin autentificación podrá:
Visualizar: Los Productos existentes en el sistema y Listar productos por categoría.
Agregar: Productos al carro de compra.
Eliminar: Productos del carro de compra.
El actor usuario con previa autentificación en el sistema podrá:
Visualizar: Los Productos existentes en el sistema, Listar productos por categoría y los
pedidos realizados por el usuario.
Agregar: Productos al carro de compra.
Eliminar: Productos del carro de compra.
Modificar: Sus datos de usuario.
Realizar: Pedido de comida online.
58
Administrador
Figura 11. Diagrama de caso de uso del Administrador.
Descripción:
El actor Administrador de la empresa mediante una previa autentificación en el Sistema de
Visualizar: Estados existentes en el sistema, Categorías existentes en el sistema, Productos
existentes en el sistema, Pedidos existentes en el sistema, Usuarios existentes en el sistema y
Mapa de los pedidos.
Crear: Nuevos Estados, Nuevas Categorías y Nuevos Productos.
Modificar: Nombre de los Estados, Nombre de las Categorías, Datos de los Productos, Estado
de los pedidos y Perfil de los Usuarios.
Eliminar: Categorías existentes en el sistema y Productos existentes en el sistema.
Bloquear: Usuarios en el sistema.
Generar: Reporte de ventas.
59
Repartidor:
Figura 12. Diagrama de caso de uso del Repartidor.
Descripción:
El actor Repartidor de la empresa mediante una previa autentificación en el Sistema de
Visualizar: Pedidos existentes en el sistema y el mapa de cada pedido.
Modificar: Estado de los pedidos existentes en el sistema.
60
7.2.1.1.3 Especificación de los Casos de Uso

El comportamiento de un caso de uso se especifica describiendo la secuencia de acciones que
el sistema debe llevar a cabo para proporcionar un servicio.
A continuación, se especificarán los casos de usos más importantes desarrollados en el

segundo incremento, los demás casos de uso se encontrarán especificados en el punto
denominado Anexos.
7.2.1.1.3.1 Especificación caso de uso módulo Usuario.
Nombre Agregar productos al carro de compras. ID CU_12

Actores Usuario.
Referencias Agregar productos al carro de compras. (RFMU_04)
Precondiciones El actor usuario debe estar dentro de su cuenta en el sistema de pedidos
de comida online.
Post-condiciones El Sistema de Pedidos de Comida Online permitirá agregar un producto
al carro de compras.
Propósito Agregar productos al carro de compra.
“Productos” del menú principal del sistema de pedidos de comida online.
2. El Sistema de Pedidos de Comida Online muestra los productos
3. El usuario hace un click en el botón “Añadir al carro”.
4.El sistema muestra un mensaje diciendo “El producto se ha agregado
exitosamente a su carro de compras”.
Flujos Alternos 3a. Si el usuario no se encuentra dentro de su cuenta en el sistema se
mostrará un mensaje diciendo “debe estar conectado con una cuenta en
el sistema para poder agregar un producto”.
Estado Cumple.
Comentarios
Tabla 21. Caso de Uso Agregar productos al carro de compras.
61
Nombre Realizar pedidos en línea. ID CU_14

Actores Usuario.
Referencias Realizar pedidos en línea. (RFMU_06)
Precondiciones El actor Usuario debe estar dentro de su cuenta en el sistema de pedidos
de comida online.
Post-condiciones El Sistema de Pedidos de Comida Online permitirá realizar un pedido al
usuario.
Propósito Realizar un pedido en línea.
4. El usuario hace click en el botón “Ver carro”.
5. El sistema muestra lo que contiene el carro de compras.
6. El usuario hace click en el botón “Realizar Pedido”.
7. El sistema muestra un pequeño formulario del pedido.
8. El usuario rellena el formulario para poder realizar el pedido.
9. El sistema muestra los pedidos realizador por el usuario.
Flujos Alternos 4a. Si el carro de compras está vacío no se mostrará ningún producto y no
saldrá ningún botón para realizar acciones.
6a. Si el carro de compras está vacío el sistema mostrara un mensaje en
donde dice “El carro debe tener productos”.
Estado Cumple.
Comentarios
Tabla 22. Caso de Uso Realizar pedidos en línea.
62
7.2.1.1.3.2 Especificación caso de uso módulo Administrador.
Nombre Modificar datos de Productos. ID CU_19

Referencias Modificar datos de Productos. (RFMA_08).
comida online.
administrador modificar los productos.
Propósito Modificar los datos de los Productos.
opción “Productos” del menú principal del Sistema de Pedidos de Comida
un lápiz.
4. El sistema muestra el formulario para poder modificar un producto en
el sistema.
5. El administrador rellena el formulario y da click en el botón azul que
dice “Modificar”.
Flujos Alternos 2a. Si no existen registrados en el sistema, este no mostrará nada.
5a. Si no rellena los campos del formulario del producto a modificar, el
sistema envía un mensaje diciendo “el campo no puede estar vacío’’
Estado Cumple.
Comentarios
Tabla 23. Caso de Uso Modificar datos de Productos.
63
Nombre Bloquear Usuarios ID CU_23

Referencias Visualizar Usuarios (RFMA_16).
comida online.
administrador Bloquear los usuarios existentes en el sistema.
Propósito Bloquear Usuarios en el sistema.
3. El Administrador hace click en el botón de color amarillo con un icono
de un circulo tachado.
4. El sistema muestra un mensaje diciendo “¿Esta seguro que desea
cambiar el estado de la cuenta?”
5. El administrador hace un click en el botón “aceptar”.
6. El sistema muestra un mensaje diciendo “La cuenta del Usuario ha sido
bloqueada”
Flujos Alternos
Estado Cumple.
Comentarios
Tabla 24. Caso de Uso Bloquear Usuarios.
64
Nombre Modificar estado de un Pedido. ID CU_21

Referencias Modificar estado de un Pedido (RFMA_13).
comida online.
administrador modificar el estado de un pedido.
Propósito Modificar estado de un pedido en el sistema.
opción “Pedidos” del menú principal del Sistema de Pedidos de Comida
2. El Sistema de Pedidos de Comida Online muestra los Estados
un lápiz.
4. El sistema muestra un dropdown con los estados existentes en el
sistema.
5. El administrador elige algún estado y da click en el botón azul que dice
“Modificar”
Estado Cumple.
Comentarios
Tabla 25. Caso de Uso Modificar estado de un pedido.
65
Nombre Reporte de Ventas por Rango de Fecha. ID CU_25

Referencias Reporte de Ventas por Rango de Fecha. (RFMA_17).
comida online.
administrador realizar un reporte de ventas por un rango de fecha.
Propósito Generar un reporte de ventas por un rango de fecha.
opción “Reporte” del menú principal del Sistema de Pedidos de Comida
2. El Sistema de Pedidos de Comida Online muestra un calendario y un
botón.
3. El Administrador selecciona el rango de fecha para generar el reporte y
luego presiona el botón que dice “Generar Reporte”.
4. El Sistema genera un reporte en formato PDF de los pedidos por rango
de fecha seleccionados

Flujos Alternos 2.a Si no se han realizado ventas dentro del rango escogido, este no
mostrará nada.
Estado Cumple.
Comentarios
Tabla 26. Caso de Uso Reporte de ventas por rango de Fecha.
66
Nombre Visualizar Mapa del Pedido. ID CU_24

Referencias Visualizar Mapa del Pedido. (RFMA_18).
comida online.
administrador visualizar un mapa de la dirección del pedido.
Propósito Visualizar Mapa del Pedido.
opción “Pedido” del menú principal del Sistema de Pedidos de Comida
2. El Sistema de Pedidos de Comida Online muestra los Pedidos
una lupa.
4. El sistema muestra el mapa de la dirección del pedido.
Flujos Alternos 2.a Si no existen registrados en el sistema, este no mostrará nada.
Estado Cumple.
Comentarios
Tabla 27. Caso de Uso Visualizar mapa del Pedido.
67
7.2.1.1.3.3 Especificación caso de uso módulo Repartidor.
Nombre Modificar estado de un Pedido ID CU_27

Actores Repartidor.
Referencias Modificar estado de un Pedido (RFMR_02).
Precondiciones El actor Repartidor debe estar dentro del sistema de pedidos de comida
online.
Post-condiciones El Sistema de Pedidos de Comida Online deberá permitir al Repartidor
modificar el estado de un pedido.
Propósito Modificar estado de un pedido en el sistema.
Flujo Principal 1. El caso de uso empieza cuando el actor Repartidor ingresa en la opción
“Pedidos” del menú principal del Sistema de Pedidos de Comida Online
(en el lado izquierdo de la pantalla).
un lápiz.
4. El sistema muestra un dropdown con los estados existentes en el
sistema.
5. El administrador elige algún estado y da click en el botón azul que dice
“Modificar”
Estado Cumple.
Comentarios
Tabla 28. Caso de Uso Modificar estado de un pedido.
68
7.2.1.2 Modelamiento de datos general
Figura 13. Modelamiento de datos.
69
7.2.1.2.1 Descripción del modelamiento de datos

User: En esta entidad se guardará la información de un cliente o trabajador del local, la
información que contendrá será: un id, username, contraseña, email y rol. Esta entidad se
vinculará con la Entidad Cliente.
Cliente: En esta entidad se guardará información de las personas que se registren en la
página web, tanto Usuario como trabajadores, está vinculada con la entidad User, pero esta
entidad guardará diferentes datos como: nombre, apellido paterno y materno, dirección y
teléfono.
Pedido: En esta entidad se guardará la información de un pedido en el sistema, los cuales
son: un id del pedido, fecha del pedido, precio del pedido y dirección del pedido, este pedido
lo podrá generar una persona registrada en el sistema, tiene como relaciones las entidades
Usuario, Estado y Pedido_has_Producto.
Estado: En esta entidad se guardará la información de los estados de un pedido, la
información a guardar será: un id del estado y un nombre para el estado, esta entidad se
relaciona con la entidad Pedido.
Pedido_has_Producto: En esta entidad se guardará la información de la relación entre las
tablas Producto y Pedidos, también se guardará un dato en esta tabla que será cantidad.
Producto: En esta entidad se guardará la información de los productos registrados en el
sistema, esta información será: un id del producto, nombre del producto, precio del
producto, stock del producto, detalle del producto y una imagen del producto, esta tabla está
vinculada con la entidad Pedido_has_Producto.
Categoría: En esta entidad se guardará la información de las categorías que se registren en el
sistema, esta información que se guardará será: un id de la categoría y un nombre de la
categoría, esta tabla está vinculada con la entidad
Local: en esta entidad se guardará la información del local en donde se efectuarán los
pedidos. La información a guardar será: dirección de local y comuna.
70
7.2.2 Diseño
7.2.2.1 Diseño de Físico de la Base de datos

A continuación, se presenta el Modelo Relacional (MR) correspondiente al diseño físico de la
base de datos del Sistema de Pedidos de Comida Online, al cual se incluyó la tabla Local para
poder referencias la dirección que tiene la empresa y para poder calcular las rutas para los
diversos pedidos que se puedan generar por parte de los usuarios.
Figura 14. Diseño físico de la Base de Datos.
71
7.2.2.2 Diseño interfaz y navegación
7.2.2.2.1 Diseño de la interfaz

El diseño de la interfaz se enfoca en la experiencia de usuario y su interacción.
Las siguientes Figuras mostraran más en detalle la relación del sistema con los distintos
actores.
Las figuras serán las más significativas para cada actor en el desarrollo del segundo
incremento.
7.2.2.2.1.1 Módulo de Usuario

• Sub-módulo de Productos.
Figura 15. Interfaz del Sub-módulo de Productos.
72
7.2.2.2.1.2 Módulo de Administrador
• Sub-módulo de Agregar productos.
Figura 16. Interfaz del Sub-módulo de Agregar Productos.
73
7.2.2.2.1.3 Módulo de Repartidor

• Sub-módulo visualizar mapa pedido.
Figura 17. Interfaz del Sub-módulo de Visualizar Mapa del Pedido.
74
7.2.3 Pruebas
7.2.3.1 Elementos de prueba

En el Sistema de Pedidos de Comida Online se realizarán pruebas a las funciones principales
de los tres módulos, los cuales se detallarán a continuación:
• Administración: se realizarán pruebas a la generación de reportes, visualización de
pedidos, cambio de estado en un pedido.
• Usuario: se realizarán pruebas al agregar productos al carro de compras, realizar un
pedido, y ver el estado de un pedido.
• Repartidor: se realizarán pruebas al cambiar el estado de un pedido, visualizar los
mismos y ver la ruta para este.
7.2.3.2 Especificación de las pruebas

En esta sección, se presentarán las pruebas de sistema y de seguridad definidas para el
proyecto. Además, se realizó la prueba usabilidad para ver la aceptación del sistema de los
potenciales usuarios.
7.2.3.2.1 Pruebas de sistema.
Pruebas de sistema.
Características a probar. Funcionalidad
Nivel de prueba. Sistema
Objetivo de la prueba. Probar y validar que el software funcione correctamente.
Enfoque de la prueba. Caja negra.
Técnicas de definición de Se utilizarán valores límites y anómalos
casos de prueba.
Actividades de prueba. • Se establecerán los escenarios a ser probados.
• Se ejecutarán las funcionalidades del sistema para
verificar que no existan anomalías
prueba entregue información errónea
Criterios de cumplimiento. La ejecución de todas las pruebas debe corresponder con la
funcionalidad que se espera como resultado, obteniendo así un
control de todos los incidentes que puedan ocurrir
Tabla 29. Especificación de Pruebas de Sistema.
75
7.2.3.2.2 Pruebas de seguridad

Pruebas de seguridad.
Características a probar Seguridad
Nivel de prueba Sistema
Objetivo de la prueba Control de acceso para el sistema, esto quiere decir que no sea
accedida por un usuario no autorizado.
Enfoque de la prueba Caja negra.
Técnicas de definición de Seguridad técnica. Modificar la URL.
casos de prueba. Acceso de usuario sin registro o que no este logeado.
Actividades de prueba. • Se ingresará al sistema utilizando diferentes roles en
el sistema
• Ingresado al sistema se modificará la URL de modo de
descubrir acciones que solo tiene permiso y acceso
otro rol.
prueba entregue información que no sea de seguridad
para el sistema
Criterios de cumplimiento. El sistema se comporta de manera que los usuarios solo tienen
acceso a sus URL designadas por los desarrolladores, de manera
que no existe problemas de seguridad.
Tabla 30. Especificación de Pruebas de Seguridad.
7.2.3.2.3 Pruebas de usabilidad.
Pruebas de usabilidad.
Características a probar Interfaz y navegación.
Nivel de prueba Aceptación.
Objetivo de la prueba Determinar qué tan fácil de utilizar es la aplicación.
Enfoque de la prueba Caja negra.
Técnicas de definición de Se le solicitará a un grupo de personas que utilice el sistema y
casos de prueba. luego se les aplicará una encuesta.
Actividades de prueba. Para la ejecución de estas pruebas se requerirá de un
computador u otro dispositivo. Las actividades planificadas
para ejecutar estas pruebas son:
• Se seleccionarán a diez personas de distintos rangos
de edad para que utilicen el sistema.
• La persona realizará pedido en el sistema.
• Se le aplicará una encuesta para determinar su nivel
de entendimiento al utilizar el sistema.
• Se realizará un análisis de resultados.
Criterios de cumplimiento. Obtener un análisis positivo de los datos entregados por la
encuesta. En concreto, se espera una aceptación del usuario igual
o superior al 80%.
Tabla 31. Especificación de Pruebas de Usabilidad.
76
7.2.3.3 Responsable de las pruebas.

Las pruebas de sistema y de seguridad fueron realizadas y verificadas por los
desarrolladores del sistema Sebastián Oñate Mena y Juan Zapata Fuentes.
Las pruebas de usabilidad fueron realizadas por un grupo de potenciales usuarios, en total 9
personas.
7.2.3.4 Detalle de las pruebas.
7.2.3.4.1 Plan de pruebas de sistema.

Se consideraron las funciones y módulos más importantes del Sistema de Pedidos de Comida
Online para la ejecución de las pruebas de sistema.
La especificación de más pruebas las podrá encontrar en la sección Anexos.
7.2.3.4.1.1 Pruebas de sistema para el modulo Usuario.

A continuación, se presentarán los casos de pruebas de sistema para el Modulo de Usuario.
Caso de prueba Agregar productos al carro de compras.

Propósito El Sistema de Pedidos de Comida Online deberá permitir al usuario agregar
productos al carro de compras.
Referencia (RF) Agregar productos al carro de Actores. Usuario
compras. (RFMU_04)
El usuario registrado debe estar dentro del sistema de pedidos de
comida online.
El administrador debe crear por lo menos una categoría en el sistema.
El administrador debe relacionar un producto a la categoría creada.
Flujo principal • El usuario presiona la opción “PRODUCTOS”.
• El Sistema de Pedidos de Comida Online re-direcciona al usuario
a los productos existentes en el sistema.
• El usuario selecciona el producto que desea.
• El usuario presiona la opción “Añadir al carro”.
• El Sistema de Pedidos de Comida Online agregara el producto al
carro de compras.
Prueba Valores de Resultado Resultado Evaluación.
prueba esperado obtenido
1 (Caso válido) El sistema debe El sistema El sistema Aprobada
contar con almacenara el agrega el
categorías producto en el producto al carro
creadas y carro de de compras.
productos. compras.
2 (Caso no El sistema no No se listarán los No se podrá Aprobada
válido) cuenta con productos ni agregar
productos categorías productos al
carro de
compras
Tabla 32. Pruebas de sistema Módulo Usuario.
77
Caso de prueba Realizar pedidos en línea.

Propósito El Sistema de Pedidos de Comida Online deberá permitir al usuario
registrado realizar pedidos en línea.
Referencia (RF) Realizar pedidos en línea. Actores. Usuario
(RFMU_06)
Online.
El usuario debe contar con productos en el carro de compras.
El usuario debe estar en su carro de compras con al menos un producto.
Flujo principal • El usuario presiona el botón “Realizar pedido”.

a la Confirmación de Pedido
• El sistema solicita el relleno de su formulario en la “Confirmación
de pedido”
• El usuario rellana los campos y presiona el botón “Confirmar
pedido”
• El Sistema de Pedidos de Comida Online re-direcciona a las
ordenes generadas por el usuario
1 (Caso válido) En la sección El sistema El sistema Aprobado
“Confirmación almacenara los notifica al
pedido” valores: datos del pedido usuario con un
Precio pedido: realizado. recuadro
3500 (no emergente, la
modificable) realización
Dirección correcta del
Pedido: Cabildo pedido.
540
Observación:
(Vacío)
2 (Caso válido) En la sección El sistema El sistema Aprobado
“Confirmación almacenara los notifica al
pedido” valores: datos del pedido usuario con un
Precio pedido: realizado. recuadro
3500 (no emergente, la
modificable). realización
Dirección correcta del
Pedido: Cabildo pedido.
540
¿Desea quitar
algún
ingrediente?: Sin
mayonesa.
78
3 (Caso no En la sección El sistema brinde El sistema Aprobada

válido) “Confirmación información notifica al
pedido” valores: sobre un campo usuario
Precio pedido: requerido. mediante un
3500 (no recuadro rojo,
modificable) que el campo de
Dirección la dirección del
Pedido: (Vacío) pedido no puede
¿Desea quitar estar vacía.
algún
ingrediente?: Sin
mayonesa.
79
7.2.3.4.1.2 Pruebas de sistema para el modulo Administrador.

A continuación, se presentarán los casos de pruebas de sistema para el Modulo de Administrador.
Caso de prueba Bloquear cuentas

Propósito El Sistema de Pedidos de Comida Online deberá permitir al administrador
del sistema, bloquear las cuentas de los usuarios
Tipo de prueba Caja negra
Referencia (RF) Bloquear usuarios. (RFMA_16) Actores Administrador
El administrador registrado debe estar dentro del sistema de pedidos de
comida online.
Debe haber por lo menos un usuario registrado en el Sistema de Pedidos de
Comida Online.
Flujo principal • El administrador ingresa a la opción “Usuarios” en la columna a
• El administrador presiona el icono de bloquear cuenta.
• El Sistema de Pedidos de Comida Online lanza un mensaje con la
confirmación de esta operación.
• El administrador confirma el bloqueo de cuenta presionando
“Aceptar”
1 (Caso valido) Tener una El sistema El sistema Aprobada
cuenta de un bloqueara las notifica al
usuario cuentas de los administrador
registrado usuarios. con un mensaje
emergente, que
la cuenta de
“xxxxx” ha sido
bloqueada.
Tabla 34. Pruebas de sistema Módulo Administrador.
80
Caso de prueba Realizar reportes de ventas por rango de fecha.

del sistema, generar un reporte de las ventas por un rango de fechas.
Tipo de prueba Caja negra
Referencia (RF) Reporte de ventas por rango de Actores Administrador
fecha. (RFMA_17)
El administrador registrado debe estar dentro del Sistema de Pedidos de
Comida Online.
El Sistema de Pedidos de Comida Online deberá tener por lo menos un
pedido en su registro.
Flujo principal • El administrador ingresa a la opción “Reportes” en la columna a
• El administrador selecciona el rango de fecha para generar el
reporte.
• El administrador presiona el botón “Generar reporte”.
• El Sistema de Pedidos de Comida Online genera un reporte en
formato PDF de los pedidos por rango de fecha seleccionados
1 (Caso valido) Fecha inicio: El sistema El sistema Aprobada.
23/10/2016 generara el genera un
Fecha fin: reporte de las reporte en
20/11/2016 ventas. formato PDF con
las ventas
realizadas por
los usuarios en el
rango de fechas
seleccionadas
1 (Caso no Fecha inicio: El sistema El sistema Aprobada.
valido) 23/10/2016 deberá informar informa al
Fecha fin: al administrador administrador
(Mayor a la que la fecha fin mediante un
actual) no puede ser mensaje que la
mayor a la actual fecha fin no
puede exceder la
fecha actual.
81
7.2.3.4.1.3 Pruebas de sistema para el modulo Repartidor.

A continuación, se presentarán los casos de pruebas de sistema para el Modulo de Repartidor.
Caso de prueba Modificar estado de un pedido

ID prueba PSMR_01 Fecha 21/11/2016
Propósito El Sistema de Pedidos de Comida Online deberá permitir al repartidor,
modificar el estado de un pedido realizado por los usuarios en el sistema.
Tipo de prueba Caja negra.
Referencia (RF) Modificar estado de un pedido. Actores Repartidor
(RFMR_02)
El repartidor registrado debe estar dentro del Sistema de Pedidos de Comida
Online.
Por lo menos debe haber un pedido generado por un usuario.
Flujo principal • El repartidor ingresa a la opción “Pedidos” en la columna a mano
izquierda del sistema.
• El repartidor presiona el icono de editar.
• El repartidor selecciona el estado del pedido a la que se
encuentra el pedido.
• El repartidor presiona el botón “Actualizar”.
repartidor a todos los pedidos realizados por los usuarios.
1 (Caso valido) Cambiar estado El sistema El sistema Aprobada
de pedido: En actualizara el actualizará el
preparación estado de un estado del
pedido. pedido
Actualización: modificado por
En camino el administrador.
Tabla 36. Pruebas de sistema Módulo Repartidor.
82
7.2.3.4.2 Plan de pruebas de seguridad.

7.2.3.4.2.1 Prueba de seguridad.
A continuación, se presentarán los casos de pruebas de seguridad para el Modulo de Usuario
Caso de prueba Acceso al sistema

ID prueba PS_01 Fecha 22/11/2016
Propósito El Sistema de Pedidos de Comida Online deberá al usuario acceder a la
plataforma web.
Referencia (RF) Control de acceso. (RNF_01) Actores. Usuario
Pre-condición El actor concursante debe tener una cuenta registrada en el Sistema de
Pedidos de Comida Online.
Flujo principal • El usuario ingresa a la opción “Login” del manu principal
• El sistema re-direcciona al usuario al formulario de inicio de
sesión.
• El usuario llena los datos solicitados.
• El usuario persona el botón “Login”
Prueba Valores de prueba Resultado Resultado obtenido Evaluación.
esperado
1 (Caso válido) Username: El sistema El sistema le permite Aprobado
juanleonardo deberá al usuario iniciar
Password: permitirle al sesión.
juanleonardo usuario iniciar
sesión.
2 (Caso no Username: El sistema El sistema notifica al
válido) juanleonardo deberá validar usuario, destacando en
Password: el correcto rojo lo campos de
juanleonardo123456 ingreso de textos inválidos y
datos, mostrando el detalle
notificando al de las observaciones
administrador encontradas. El
en el caso que mensaje para el campo
no se cumpla es: “Usuario o
con esta contraseña incorrecta”
condición.
3 (Caso no Username: (Vacío) El sistema El sistema notifica al Aprobado.
válido) Password: (Vacío) deberá validar usuario, destacando en
el correcto rojo lo campos de
ingreso de textos inválidos y
datos, mostrando el detalle
notificando al de las observaciones
administrador encontradas. El
en el caso que mensaje para el campo
no se cumpla es: “Username y
con esta Password no puede
condición. estar vacío”
Tabla 37. Prueba de Seguridad.
83
7.2.3.4.3 Plan de pruebas de usabilidad.

7.2.3.4.3.1 Prueba de usabilidad.
Para la realización de las pruebas de usabilidad, se seleccionó un grupo de potenciales

usuarios del Sistema de Pedidos de Comida Online. Se definen como usuarios concurrentes en
locales de comida rápida. La edad rodea entre los 20 a 62 años. El total de encuestados fue de
10 usuarios.
Para llevar a cabo esta aceptación del sistema, se sometió a todos estos integrantes a utilizar
el sistema, y realizar un pedido. Luego de utilizado el sistema, se les solicito responder una
encuesta realizada a través de Google Forms para medir el nivel de aceptación de los usuarios
al sistema.
Los usuarios encuestados fueron los siguientes:
1. Camila Gallardo Soto, 25 años de edad.

2. Juan Pablo Rojas Troncoso, 20 años de edad.
3. Esteban Zapata Fuentes, 21 años de edad.
4. Patricia Fuentes Roman, 47 años de edad.
5. Leonor Fuentes Roman, 50 años de edad.
6. Martin Loyola Cofre, 30 años de edad
7. Camilo Formas Morales, 25 años de edad.
8. Carola Sallorenzo Morales, 24 años de edad.
9. Alejandro Oñate Pinto, 62 años de edad.
10. Carmen Mena Bastias, 58 años de edad.
84
A continuación, se presentará la encuesta realizada y análisis de los resultados de la misma.
Figura 18. Encuesta usuarios.
85
Los resultados a la encuesta son las siguientes:
Figura 19. Resultado encuesta usuarios.

86
Resultados: como resultado de la encuesta realizada, se puede apreciar que da un resultado

positivo en la utilización de nuestro sistema. Logrando y obteniendo los resultados
propuestos por nuestra prueba de usabilidad, logrando así obtener el 80% de aceptabilidad
del sistema para los usuarios potenciales.
87
CAPÍTULO 7
8 SEGURIDAD
88
Existen muchas definiciones del término seguridad. Simplificando, y en general, podemos

definir la seguridad como: "Característica que indica que un sistema está libre de todo
peligro, daño o riesgo."
Cuando hablamos de seguridad de la información estamos indicando que dicha información
tiene una relevancia especial en un contexto determinado y que, por tanto, hay que proteger.
La Seguridad de la Información se puede definir como conjunto de medidas técnicas,
organizativas y legales que permiten a la organización asegurar la confidencialidad,
integridad y disponibilidad de su sistema de información.
Yii2, el Framework que se utilizó para desarrollar el sistema, tiene integrado por defecto tres
tópicos en seguridad, los cuales son:
1. Prevención de ataques a través de cookies: Yii2 implementa un sistema de validación

de cookies para que éstas no puedan ser modificadas. Es una medida de seguridad muy
importante ya que los identificadores de sesión se almacenan comúnmente en las
cookies lo cual compromete en gran medida la seguridad tanto del usuario como del
sistema propiamente tal.
2. Cross-site scripting (Secuencias de órdenes en sitios cruzados): Permite la inyección

de código JavaScript o en otro lenguaje similar, que puede ser utilizado para robar
información delicada, secuestrar sesiones de usuario y comprometer el navegador,
subyugando la integridad del sistema.
3. Cross-site request forgery (Falsificación de peticiones en sitios cruzados): Es un tipo

de exploit malicioso de un sitio web en el que comandos no autorizados son
transmitidos por un usuario en el cual el sitio web confía, es decir, utiliza a un usuario
validado en el sistema para, a través de éste, introducir solicitudes “válidas” que
modifiquen el comportamiento de la aplicación a favor del atacante.
Se proporcionaron validaciones en todos los métodos que obtienen identificadores mediante

el método GET (utilizado para el envío de datos hacia el controlador) con el propósito de
restringir el acceso a un sitio no autorizado del sistema a través de la modificación de la URL.
Además, para cada módulo (Usuario y Administración) se realizaron controles de
acceso, con el fin de generar un mecanismo de autentificación y autorización.
89
CAPÍTULO 8
9 CONCLUSIONES
90
En base a los expuesto anteriormente, los objetivos planteados al principio del proyecto se
cumplieron a cabalidad, luego de un periodo en el cual nos acercamos a diferentes locales de
comida rápida en Chillán, para conocer las falencias en sus procesos de gestión de ventas no
convencionales (teléfono-redes, sociales), se desarrolló un software propiamente tal, que
involucro las etapas de especificación de requisitos, análisis de requisitos, diseño,
codificación y desarrollo de pruebas, culminando con la presentación a nuestro profesor
guía.
En referencia a la metodología de desarrollo de software que se utilizó (iterativa

incremental), esta se ajustó adecuadamente a los requerimientos del proyecto, permitiendo
generar dos incrementos en los plazos estipulados.
El desarrollo de las pruebas de usabilidad demostró que el sistema en cuestión desarrollado,

cumple y está al nivel de los requerimientos que los usuarios pretenden de un sistema de
pedidos de comida, por lo que el desarrollo del software y el contar con este sistema, es una
gran oportunidad para las empresas de comida.
En el primer incremento que realizamos, utilizamos el Framework Laravel, el cual nos ocupó
bastante tiempo en replicar el modelado de datos y luego migrarlo. Realizamos el desarrollo
del módulo gestión de cuenta del administrador y de usuario. El escoger en un principio este
Framework fue para colocarnos un reto y poder conocer otra herramienta que nos permita
desarrollar softwares, pero decidimos cambiarnos a Yii2, dado a que anteriormente nos
habíamos familiarizado con esta herramienta de desarrollo, además sabíamos que al ocupar
esta herramienta podríamos desarrollar un mejor proyecto final dado a todas las bondades
que nos ofrece Yii2, y a los conocimientos adquiridos anteriormente.
En el segundo incremento, dado al cambio realizado, tuvimos que replicar lo que realizamos
en el primer incremento y realizar lo acordado en la carta Gantt, este incremento significo un
gran desafío, dado corto tiempo que teníamos para poder realizarlo, pero sin embargo
pudimos avanzar de forma rápida dado a que teníamos conocimientos previos con el
Framework Yii2, cumpliendo así el desarrollo de los tres módulos (Modulo de Usuario,
Modulo de Administrador y Modulo Repartidor) con éxito.
Una de las dificultades que generalmente se nos presentaban era que al momento de ocupar
alguna API o extensiones para el Framework Yii2, era que teníamos que instruirnos de ella y
aprender a utilizarla para el correcto uso en el desarrollo del proyecto, sin embargo, al
momento de escoger alguna de estas extensiones o API, siempre encontrábamos
información concreta y concisa de como poder realizarlo y replicarlo en nuestro proyecto,
logrando así generar un software de calidad en el cual se pudo realizar todo lo planteado al
principio del proyecto.
Este proyecto tiene como objetivos futuros el desarrollo de nuevas tareas como sistema de
pagos online, convenio con otras instituciones o tarjetas de crédito o débito para el pago
directo desde el sistema, una opcion de menú interactivo para las promociones del local, y
contar con auspiciadores para una mayor atracción al usuario, además se pretende que el
sistema cuente con promociones personalizadas por cada cliente, dependiendo de los gustos
y compras frecuentes efectuadas por este, para lograr así la fidelidad y compromiso que tiene
la empresa gracias al sistema.
91
Finalmente, es importante mencionar que el desarrollo de este proyecto fue una experiencia
totalmente enriquecedora, tanto por la consolidación de los conocimientos que se han
entregado de parte de la Universidad y de sus académicos, como también por el trabajo
autodidáctico, la motivación de aprender y experiencia adquirida durante el desarrollo del
proyecto. La realización de un proyecto en conjunto con un compañero exige establecer
permanentemente consensos, establecer metodologías ágiles, afrontar las incidencias de
forma adecuada y lo más importante, el trabajo en equipo. El desarrollo de este proyecto,
resultó ser una experiencia muy valiosa, la cual servirá para el futuro laboral de los autores
de este proyecto.
92
10 BIBLIOGRAFÍA
W3SCHOOLS. SQL. [En línea] < http://www.w3schools.com/sql/> [15 de agosto del

2016]
W3SCHOOLS. JavaScript Reference. [En línea] < http://www.w3schools.com/js/> [16

de agosto del 2016]
W3SCHOOLS. HTML. [En línea] <http://www.w3schools.com/html/> [17 de agosto del

2016]
W3SCHOOLS. CSS. [En línea] < http://www.w3schools.com/css/> [17 de agosto del

2016]
JQUERY. JQuery API Documentation. [En línea] < http://api.jquery.com/jquery.ajax/>

[17 de agosto del 2016]
MySQL. MySQL 5.7 Reference Manual. [En línea]

<http://dev.mysql.com/doc/refman/5.7/en/> [18 de agosto del 2016]
Framework Laravel 5.3. Installation[En línea] < https://laravel.com/docs/5.3> [10 de

agosto del 2016]
Framework Yii2. The Definitive Guide to Yii 2.0. [En línea]

<http://www.yiiframework.com/doc-2.0/guide-index.html> [29 de agosto del 2016]
JQuery. JQuery Core API Documentation. [En línea] < http://api.jquery.com/> [Consulta:
5 de septiembre del 2016]
Code Tutorials (5 de septiembre 2015). Introduction to the Yii Framework.

http://code.tutsplus.com
Krajee (01 de noviembre 2015). Krajee Yii extensions – Kartik.

http://demos.krajee.com/
Google Developers (12 de noviembre de 2016). Google Maps APIs.

https://developers.google.com/maps/
93
CAPÍTULO 9
ANEXOS
94
A continuación, se presentarán como anexo los casos de usos, pruebas desarrolladas y

diseño de los tres módulos del sistema.
En primer lugar, se especificarán los casos de uso el módulo Usuario desarrollados en el
segundo incremento, se presenta como continuidad del punto 4.2.1.1.3.1.
4.2.1.1.3.1. Anexo Especificación caso de uso módulo Usuario Segundo Incremento.

Nombre Listar Productos por Categoría. ID CU_11
Actores Usuario.
Referencias Listar Productos por Categoría. (RFMU_03)
online.
Post-condiciones El Sistema de Pedidos de Comida Online permitirá visualizar los
productos filtrados por categoría.
Propósito Visualizar los productos categorizados.
existentes en el sistema y un cuadro donde muestra las categorías
3. El usuario hace un click en alguna categoría del recuadro a la derecha
de la pantalla.
4.El sistema muestra los productos filtrados por la categoría seleccionada
anteriormente.
Flujos Alternos 4a. Si no se encuentra algún producto asociado a alguna categoría el
sistema no mostrara productos.
Estado Cumple.
Comentarios
Tabla 38. Caso de uso Listar productos por categoria.
95
Nombre Eliminar productos del carro de compras. ID CU_13

Actores Usuario.
Referencias Eliminar productos del carro de compras. (RFMU_05)
de comida online.
Post-condiciones El Sistema de Pedidos de Comida Online permitirá eliminar un producto
al carro de compras.
Propósito Eliminar productos del carro de compra.
4. El usuario hace click en el botón “Ver carro”.
5. El sistema muestra lo que contiene el carro de compras.
6. El usuario hace click en el botón rojo con una figura de un basurero.
7. el sistema muestra un mensaje diciendo “¿Estás seguro que deseas
eliminar el producto del carro de compras?”.
8. El usuario hace click en el botón Aceptar.
9. El sistema muestra un mensaje diciendo “El producto se ha eliminado
de su carro de compras”.
Flujos Alternos 4a. Si el carro de compras está vacío no se mostrará ningún producto y no
saldrá ningún botón para realizar acciones.
Estado Cumple.
Comentarios
Tabla 39. Caso de uso Eliminar productos del Carro de compras.
96
Nombre Visualizar Pedidos. ID CU_15

Actores Usuario.
Referencias Realizar pedidos en línea. (RFMU_07)
de comida online.
Post-condiciones El Sistema de Pedidos de Comida Online permitirá visualizar los pedidos
del usuario en el sistema.
Propósito Visualizar pedidos en el sistema.
“Mis pedidos” del menú principal del sistema de pedidos de comida
online.
2. El Sistema de Pedidos de Comida Online muestra los pedidos
realizados por el usuario.
Flujos Alternos 2a. Si el usuario no tiene pedidos realizados aun, el sistema no mostrara
nada
Estado Cumple.
Comentarios
Tabla 40. Caso de uso Visualizar Pedidos.
97
Continuando, se especificarán los casos de uso del módulo Administrador desarrollados

en el primer y segundo incremento, se presenta como continuación del punto 4.1.1.1.3.2.
y 4.2.1.1.3.2
4.1.1.1.3.2. Anexo Especificación caso de uso módulo Administrador Primer Incremento.
Nombre Crear Estados ID CU_07

Referencias Crear Estados (RFMA_09).
comida online.
administrador crear un estado nuevo en el sistema.
Propósito Crear Estados en el sistema.
opción “Estados” del menú principal del Sistema de Pedidos de Comida
estado”.
4. El sistema muestra el capo para poder darle un nombre al estado
nueva.
5. El administrador rellena el campo y da click en el botón verde que dice
“crear”
Flujos Alternos 5a. Si no rellena el campo del nombre del estado nuevo a crear, el sistema
envía un mensaje diciendo “el campo no puede estar vacío’’
Estado Cumple.
Comentarios
Tabla 41. Caso de uso Crear estados.
98
Nombre Modificar Estados ID CU_09

Referencias Modificar Estados (RFMA_10).
comida online.
administrador modificar los Estados.
Propósito Modificar Estados en el sistema.
un lápiz.
4. El sistema muestra el capo para poder darle un nombre al Estado.
5. El administrador rellena el campo y da click en el botón azul que dice
“Modificar”
5a. Si no rellena el campo del nombre del Estados a modificar, el sistema
envía un mensaje diciendo “el campo no puede estar vacío “
Estado Cumple.
Comentarios
Tabla 42. Caso de uso Modificar estados.
99
Nombre Visualizar Estados ID CU_08

Referencias Visualizar Estados (RFMA_11).
comida online.
administrador visualizar los estados existentes en el sistema.
Propósito Visualizar Estados en el sistema.
Estado Cumple.
Comentarios
Tabla 43. Caso de uso Visualizar estados.
100
Nombre Visualizar Categoría ID CU_04

Referencias Visualizar Categoría (RFMA_02).
comida online.
administrador visualizar las categorías existentes en el sistema.
Propósito Visualizar categorías en el sistema.
Estado Cumple.
Comentarios
Tabla 44. Caso de uso Visualizar categoría.
101
4.2.1.1.3.2. Anexo Especificación caso de uso módulo Administrador Segundo Incremento.

Nombre Registro de Productos. ID CU_16
Referencias Registro de Productos (RFMA_05).
comida online.
administrador registrar un nuevo producto en el sistema.
Propósito Registrar Productos en el sistema.
producto”.
4. El sistema muestra el formulario para poder añadir un nuevo producto
al sistema.
5. El administrador rellena el formulario y da click en el botón verde que
dice “crear producto”
Flujos Alternos 5a. Si no rellena los campos del nuevo producto a crear, el sistema envía
un mensaje diciendo “El campo no puede estar vacío’’
Estado Cumple.
Comentarios
Tabla 45. Caso de uso Registro de productos.
102
Nombre Visualizar Productos ID CU_17

Referencias Visualizar Productos (RFMA_06).
comida online.
administrador visualizar los productos existentes en el sistema.
Propósito Visualizar productos en el sistema.
Estado Cumple.
Comentarios
Tabla 46. Caso de uso Visualizar productos.
103
Nombre Eliminar Productos ID CU_18

Referencias Eliminar Productos (RFMA_07).
comida online.
administrador eliminar los productos.
Propósito Eliminar productos en el sistema.
3. El Administrador hace click en el botón de color rojo con un icono de
basurero.
4. El sistema muestra un mensaje que dice “¿Esta seguro que desea
eliminar este producto? “
5. El administrador hace un click en el botón “Aceptar”.
Estado Cumple.
Comentarios
Tabla 47. Caso de uso Eliminar productos.
104
Nombre Visualizar Pedidos ID CU_20

Referencias Visualizar Pedidos (RFMA_12).
comida online.
administrador visualizar los pedidos existentes en el sistema.
Propósito Visualizar Pedidos en el sistema.
opción “Pedidos” del menú principal del Sistema de Pedidos de Comida
Estado Cumple.
Comentarios
Tabla 48. Caso de uso Visualizar pedidos.
105
Nombre Modificar rol de un usuario. ID CU_22

Referencias Modificar rol de un usuario. (RFMA_14).
comida online.
administrador modificar rol de un usuario.
Propósito Modificar rol de un usuario.
un lápiz.
4. El sistema muestra un dropdown con los roles existentes en el sistema.
5. El administrador elige algún rol y da click en el botón azul que dice
“Modificar”
Flujos Alternos
Estado Cumple.
Comentarios
Tabla 49. Caso de uso Modificar rol de usuario.
106
Para finalizar la especificación de los casos de uso, se presentará la especificación de

estas del Módulo Repartidor, implementadas en el segundo incremento, se presenta
como continuación del punto 4.2.1.1.3.3.
4.2.1.1.3.3. Anexo Especificación caso de uso módulo Repartidor Segundo Incremento.
Nombre Visualizar Pedidos ID CU_26

Actores Repartidor.
Referencias Visualizar Pedidos (RFMR_11).
Precondiciones El actor Repartidor debe estar dentro del sistema de pedidos de comida
online.
Post-condiciones El Sistema de Pedidos de Comida Online deberá permitir al Repartidor
visualizar los pedidos existentes en el sistema.
Propósito Visualizar Pedidos en el sistema.
Flujo Principal 1. El caso de uso empieza cuando el actor Repartidor ingresa en la opción
“Pedidos” del menú principal del Sistema de Pedidos de Comida Online
Estado Cumple.
Comentarios
Tabla 50. Caso de uso Visualizar pedidos.
107
Nombre Visualizar Mapa del Pedido. ID CU_28

Actores Repartidor.
Referencias Visualizar Mapa del Pedido. (RFMR_03).
Precondiciones El actor repartidor debe estar dentro del sistema de pedidos de comida
online.
Post-condiciones El Sistema de Pedidos de Comida Online deberá permitir al repartidor
visualizar un mapa de la dirección del pedido.
Propósito Visualizar Mapa del Pedido.
Flujo Principal 1. El caso de uso empieza cuando el actor repartidor ingresa en la opción
“Pedido” del menú principal del Sistema de Pedidos de Comida Online
una lupa.
4. El sistema muestra el mapa de la dirección del pedido.
Flujos Alternos 2.a Si no existen registrados en el sistema, este no mostrará nada.
Estado Cumple.
Comentarios
Tabla 51. Caso de uso Visualizar mapa del pedido.
108
Otro punto importante que cabe destacar, son las pruebas al sistema, por lo que
dejaremos a continuación las pruebas de sistema del módulo Usuario, Administrador y
Repartidor desarrolladas en el segundo incremento, estas serán la continuación del
punto 4.2.3.4.1.1, 4.2.3.4.1.2 y 4.2.3.4.1.3 respectivamente.
4.2.3.4.1.1. Anexo Pruebas de sistema para el módulo Usuario Segundo Incremento.
Caso de prueba Listar productos por categoría.

Propósito El Sistema de Pedidos de Comida Online deberá permitir listar los productos
de acuerdo a su categorización.
Referencia (RF) Listar productos por categoría. Actores. Usuario
(RFMU_03)
El usuario registrado debe estar dentro del sistema de pedidos de comida
online.
El administrador debe crear por lo menos una categoría en el sistema.
El administrador debe relacionar un producto a la categoría creada.
• El usuario visualiza las categorías que existen en el sistema.
• El usuario visualiza los productos que existen en el sistema.
1 (Caso válido) El sistema debe El sistema listara El sistema lista Aprobado
contar con los productos de cada producto de
categorías acuerdo a su acuerdo a la
creadas y categorización. categoría que el
productos administrador
relacionados. asigno.
2 (Caso no El sistema no No se listarán los El sistema no Aprobado
válido) cuenta con productos ni brindara
categorías ni categorías información de
productos. ninguna
categoría y
producto.
109
Caso de prueba Eliminar productos del carro de compras.

Propósito El Sistema de Pedidos de Comida Online deberá permitir al usuario
registrado, eliminar productos del carro de compras.
Referencia (RF) Eliminar productos del carro de Actores. Usuario
compras. (RFMU_05)
Online.
El usuario debe contar con productos en el carro de compras.
a los productos existentes en el sistema.
• El usuario presiona el botón “Ver carro”.
a los productos agregados en el carro de compras.
• El usuario presiona la opción de eliminar producto
• El Sistema de Pedidos de Comida Online lanza un mensaje con la
confirmación de la operación.
• El usuario confirma la eliminación del producto del carro de
compras
1 (Caso válido) Ver Carro (1). El sistema El sistema Aprobado
eliminara el elimina el
producto producto
deseado del seleccionado,
carro de notificando al
compras. usuario que el
producto se
eliminó del carro
de compras
2 (Caso no Ver Carro (0). El sistema El sistema brinda Aprobado
válido) mostrara el Información
Carro de general de un
Compras, pero carro de
sin productos. compras, este sin
productos.
110
Caso de prueba Detalle de pedidos.

Propósito El Sistema de Pedidos de Comida Online deberá mostrar los pedidos
realizados por su propia cuenta, junto con el detalle de estos.
Referencia (RF) Visualizar pedidos. (RFMU_07) Actores. Usuario
Online
El usuario debe tener al menos un pedido realizado.
Flujo principal • El usuario presiona la opción “DETALLE”.
a sus órdenes de pedido.
• El usuario presiona el botón “Ver”.
al detalle de ese pedido.
1 (Caso válido) El usuario tenga El sistema El sistema Aprobada
al menos una deberá mostrar informa al
orden. todos los usuario de sus
pedidos pedidos
realizados. generados, y el
detalle de estos
unitariamente.
2 (Caso no El usuario no ha El sistema El sistema Aprobada
válido) generado deberá mostrar informa al
ninguna orden. datos generales usuario de datos
de una orden. generales de las
ordenes
generada.
111
4.2.3.4.1.2. Anexo Pruebas de sistema para el módulo Administrador Segundo Incremento.
Caso de Agregar productos.

prueba
Propósito El Sistema de Pedidos de Comida Online deberá permitir al administrador del
sistema, agregar productos en el sistema.
Desarrollo. Segundo Incremento.
Tipo de Caja negra
prueba
Referencia Registro de productos. (RFMA_05) Actores Administrador
(RF)
Comida Online.
Flujo • El administrador ingresa a la opción “Productos” en la columna a
principal mano izquierda del sistema.
• El administrador presiona el botón “Agregar producto.
administrador al formulario para crear un nuevo producto.
• El administrador llena el formulario.
• El administrador presiona “Crear producto” para agregar un nuevo
producto.
administrador al grupo de productos existentes en el sistema.
Prueba Valores de prueba Resultado Resultado obtenido Evaluación.
esperado
1 (Caso Nombre producto: El sistema deberá El sistema almacena Aprobada
valido) Pizzas napolitana almacenar el el producto
Detalle: Queso, producto ingresado,
salame y orégano ingresado. notificando al
Categoría: Pizzas administrador de su
Precio producto: correcta creación
6.900 con un mensaje
Stock:14 emergente, además
Imagen producto: lo re-direccionara a
pizzanapolitana.jpg todos los productos
existentes en el
sistema.
1 (Caso no Nombre producto: El sistema deberá El sistema notifica al Aprobada
valido) (Vacío) notificar al administrador,
Detalle: Queso, administrador de identificando en
salame y orégano un error en la rojos los campos
Categoría: (Vacío) creación del que no pueden estar
Precio producto: producto, por el vacíos, mostrando el
6.900 valor nulo en el siguiente texto para
Stock:14 campo requerido. el caso “No puede
Imagen producto: estar vacío”.
pizzanapolitana.jpg
112
Caso de prueba Modificar estado de un pedido

del sistema, modificar el estado de un pedido realizado por los usuarios en el
sistema.
Referencia (RF) Modificar estado de un pedido. Actores Administrador
(RFMA_13)
Comida Online.
Por lo menos debe haber un pedido generado por un usuario.
Flujo principal • El administrador ingresa a la opción “Pedidos” en la columna a
• El administrador presiona el icono de editar.
• El administrador selecciona el estado del pedido a la que se
encuentra el pedido.
• El administrador presiona el botón “Actualizar”.
administrador a todos los pedidos realizados por los usuarios.
1 (Caso valido) Cambiar estado El sistema El sistema Aprobada
de pedido: En actualizara el actualizará el
preparación estado de un estado del
pedido. pedido
Actualización: modificado por
En camino el administrador.
113
Caso de prueba Modificar datos de productos

del sistema, modificar los datos de un determinado producto.
Referencia (RF) Modificar datos de productos. Actores Administrador
(RFMA_08)
Comida Online.
Por lo menos debe haber un producto registrado.
Flujo principal • El administrador ingresa a la opción “Productos” en la columna a
• El administrador presiona el icono de editar.
formulario para modificar los datos de un producto.
• El administrador actualiza los datos.
• El administrador presiona el botón “Modificar”.
• El Sistema de Pedidos de Comida Online re-direccionara al
administrador a todos los productos registrados.
1 (Caso valido) Nombre El sistema El sistema Aprobada
Producto: Barros almacenara la actualizará los
Luco. actualización de datos del
Detalle: queso y los datos de un producto
jamón. producto modificados por
Categoría: el administrador.
Sandwich’s
Precio: 3500.
Stock: 5
Imagen
producto:
barrosluca.png
1 (Caso no Nombre El sistema El sistema Aprobada.
valido) Producto: deberá informar informa al
(Vacío). al administrador administrador
Detalle: queso y que hay campos mediante un
jamón. que no pueden mensaje en un
Categoría: estar vacíos. recuadro rojo
(Vacío) que el nombre
Precio: 3500. del producto y la
Stock: 5 categoría no
Imagen pueden estar
producto: vacíos.
barrosluca.png
114
Caso de prueba Visualizar mapa del pedido

Propósito El Sistema de Pedidos de Comida Online deberá permitir mostrar un mapa
de los pedidos realizados.
Referencia (RF) Visualizar mapa del pedido. Actores. Administrador
(RFMA_18)
El administrador registrado debe estar dentro del sistema de pedidos de
comida online.
El Sistema de Pedidos de Comida Online deberá contar por lo menos con un
pedido en sus registros.
Flujo principal • El Administrador presiona la opción “Pedidos”.
administrador a todos los pedidos generados por los usuarios.
• El administrador presiona el icono de búsqueda en un pedido.
administrador al mapa del pedido, en donde se realizada la
entrega de los productos.
1 (Caso válido) El sistema debe El sistema El sistema Aprobado
contar un pedido deberá mostrar informa al
realizado. el mapa de un usuario del mapa
pedido de recorrido
determinado. para el pedido
seleccionado.
115
4.2.3.4.1.3. Anexo Pruebas de sistema para el módulo Repartidor Segundo Incremento.
Caso de prueba Visualizar mapa del pedido

ID prueba PSMR_02 Fecha 22/11/2016
Propósito El Sistema de Pedidos de Comida Online deberá permitir mostrar un mapa
de los pedidos realizados.
Referencia (RF) Visualizar mapa del pedido. Actores. Repartidor
(RFMR_03)
El repartidor registrado debe estar dentro del sistema de pedidos de comida
online.
El Sistema de Pedidos de Comida Online deberá contar por lo menos con un
pedido en sus registros.
Flujo principal • El repartidor presiona la opción “Pedidos”.
repartidor a todos los pedidos generados por los usuarios.
• El repartidor presiona el icono de búsqueda en un pedido.
repartidor al mapa del pedido, en donde se realizada la entrega
de los productos.
1 (Caso válido) El sistema debe El sistema El sistema Aprobado
contar un pedido deberá mostrar informa al
realizado. el mapa de un repartidor del
pedido mapa de
determinado. recorrido para el
pedido
seleccionado.
Tabla 58. Pruebas de sistema Módulo Repartidor.
116

Oñate Mena, Sebastián Andrés

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Oñate Mena, Sebastián Andrés

Cargado por

Copyright:

Formatos disponibles

Universidad del Bío-Bío.

Red de Bibliotecas - Chile

SISTEMA DE PEDIDOS DE COMIDA

SEBASTIAN ANDRES OÑATE MENA

MEMORIA PARA OPTAR AL TÍTULO DE

El proyecto lleva como título “Sistema de Pedidos de Comida Online.”.

En cuanto al desarrollo, se optó por utilizar la metodología iterativa e incremental, usando el

Al implementar este Sistema se mejorará el proceso de gestión de pedidos de las empresas

The project is entitled " Online Food Order System.".

7.1.1.1.3 Especificación de los Casos de Uso............................................................................................................ 42

Tabla 1. Requerimientos funcionales del módulo Usuario. ..................................................................................... 22

Tabla 47. Caso de uso Eliminar productos..................................................................................................................... 104

Figura 1. Diagrama iterativo incremental. ........................................................................................................................ 17

2.1 Descripción de la empresa

2.2 Descripción del área de estudio

2.3 Descripción de la problemática

En la actualidad, y tomando en cuenta el avance de la tecnología, las empresas se

En base a lo anteriormente descrito, es necesario desarrollar una automatización para el

1 Arturo K. (2011). Ventajas de tener una página web. 12-06-2011, de

3.1 Objetivos del proyecto

3.2 Ambiente de Ingeniería de Software

Es el mismo usuario el que incluye o desecha elementos al final de cada incremento

Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza

Figura 1. Diagrama iterativo incremental.

3.3 Definiciones, Siglas y Abreviaciones

MLS: Modelo Lineal Secuencial. “Modelo de cascada”.

• El Sistema de Pedidos de Comida Online deberá recibir pedidos solo de la cuidad de

4.2 Objetivo del software

4.3 Descripción global del producto.

4.3.1 Interfaz de usuario.

Los locales se enfocaban en:

• Tener el loco del local en la parte superior del sistema.

4.3.2 Interfaz de hardware.

4.3.3 Interfaz de software.

4.4 Requerimientos Específicos

Los requisitos funcionales describen la funcionalidad o los servicios del sistema.

4.4.1 Requerimientos Funcionales del Módulo de Usuario.

Los siguientes requisitos funcionales corresponden a el módulo de Usuario

ID Nombre Descripción Cumplimiento Notas Estado

Tabla 1. Requerimientos funcionales del módulo Usuario.

ID Nombre Descripción Cumplimiento Notas Estado

Tabla 2. Requerimientos funcionales del módulo Usuario.

4.4.2 Requerimientos Funcionales del Módulo de Administrador.

Los siguientes requisitos funcionales corresponden a el módulo de Administrador

ID Nombre Descripción Cumplimiento Notas Estado

Tabla 3. Requerimientos funcionales del módulo Administrador.

ID Nombre Descripción Cumplimiento Notas Estado

Tabla 4. Requerimientos funcionales del módulo Administrador.

ID Nombre Descripción Cumplimiento Notas Estado

Tabla 5. Requerimientos funcionales del módulo Administrador.

ID Nombre Descripción Cumplimiento Notas Estado

Tabla 6. Requerimientos funcionales del módulo Administrador.

4.4.3 Requerimientos Funcionales del Módulo de Repartidor.

Los siguientes requisitos funcionales corresponden a el módulo de Repartidor

ID Nombre Descripción Cumplimiento Notas Estado

Tabla 7. Requerimientos funcionales del módulo Repartidor.

4.4.4 Interfaces externas de entrada

4.4.5 Interfaces externas de Salida

4.4.6 Atributos del producto

Los requisitos no funcionales definen propiedades y restricciones del sistema. En esta

ID Nombre Descripción Cumplimiento Notas Estado

Tabla 10. Requerimientos no funcionales del sistema.

Todos estos cuentan con una licencia gratuita.