22doc 20 02 17

UNIVERSIDAD MAYOR DE SAN SIMÓN

DIRECCIÓN DE PLANIFICACIÓN ACADÉMICA
PROGRAMA DE TITULACIÓN DE ALUMNOS ANTIGUOS NO
GRADUADOS
FACULTAD DE CIENCIAS Y TECNOLOGÍA

CARRERA DE INGENIERÍA DE SISTEMAS
APLICACIÓN MOVIL PARA LA GESTION DEL

MENU Y TOMA DE COMANDAS DE UN
RESTARANT USANDO EL FRAMEWORK IONIC
PROYECTO DE GRADO INTERDISCIPLINARIO
PARA OPTAR EL GRADO ACADÉMICO DE
LICENCIATURA EN INGENIERÍA DE
SISTEMAS
PARTICIPANTES:
ERICK ALEJANDRO ERGUETA BASCOPE
ANTONIO DAVID OVANDO ARCIENEGA
JUAN WINDZOR UREÑA ORDOÑEZ
TUTOR:
LIC. CARMEN ROSA GARCIA PEREZ
TEC29TD017
COCHABAMBA - BOLIVIA
2017

DEDICATORIA
A nuestros Padres,Esposas e Hijos por habernos
apoyado en todo momento, por sus consejos, sus
valores, por la motivación constante que nos ha
permitido a ser personas de bien, pero más que
nada por su amor.
ii

AGRADECIMIENTOS
A Dios por habernos permitido llegar hasta este
punto y habernos dado salud para lograr nuestros
objetivos, además de su infinita bondad y amor.
A la Lic. Carmen Rosa Garcia Perez por

ayudarnos a que sea posible este Proyecto.
A los Docentes por sus consejos y enseñanzas,

haciendo de nosotros personas de bien.
A la Universidad por abrirnos las puertas y

cobijarnos hasta la culminación de nuestros
estudios.
¡Muchas Gracias!
iii

INDICE GENERAL
DEDICATORIA .......................................................................................................... ii
AGRADECIMIENTOS… .......................................................................................... iii
ÍNDICE GENERAL ................................................................................................... iv
FICHA RESUMEN..................................................................................................... xi
CAPITULO I
INTRODUCCIÓN
1.1. Antecedentes ........................................................................................................... 1

1.2. Definición del Problema ......................................................................................... 1
1.3. Objetivo General ..................................................................................................... 1
1.4. Objetivos Específicos.............................................................................................. 2
1.5. Justificación ............................................................................................................ 2
1.6. Alcances ................................................................................................................. 3
CAPITULO II
RESTAURANTE
2.1. Introducción .......................................................................................................... 4

2.2. Organización ......................................................................................................... 4
2.3. Proceso de Atención ............................................................................................. 7
CAPITULO III
HERRAMIENTAS Y METODLOGIA
3.1. Programación Móvil ........................................................................................... 9

3.1.1. Desarrollo Nativo ............................................................................................... 9
3.1.2. Desarrollo Multiplataforma Compilado a Nativo .............................................. 9
3.1.3. Desarrollo Multiplataforma Basado en HTML5 ................................................ 10
3.2. Paradigma de Programación .............................................................................. 10
3.3. Programación Reactiva ...................................................................................... 10
iv

3.3.1. Manifiesto de la Programación Reactiva ........................................................... 11

3.4. Programación reactiva orientada a Objetos ....................................................... 12
3.5. Sockets .............................................................................................................. 12
3.6. RethinkDB .......................................................................................................... 12
3.7. Node.Js .............................................................................................................. 13
3.8. Famework Ionic.................................................................................................. 13
3.8.1. Estructura del Framework Ionic ........................................................................ 14
3.9. SCRUM ............................................................................................................. 17
CAPITULO IV
PLANIFICACION DEL PROYECTO
4.1. Metodología a Aplicar ....................................................................................... 20

4.2. Herramientas para el Desarrollo de la Metrología Scrum .................................. 20
4.3. Producto Backlog ............................................................................................... 20
CAPITULO V
ITERACION - I
5.1. Introducción ........................................................................................................... 22

5.2. Planificación Sprint 1 “Análisis, Diseño y Creación de la Base de Datos” ............ 22
5.2.1. Historias de Usuario .......................................................................................... 23
5.2.2. Diagrama de Burn Down del Sprint 1“Análisis, diseño y creación de la base de
datos” .................................................................................................................. 28
5.2.3. Retrospectiva del Sprint 1 ................................................................................. 28
5.3. Planificación Sprint 2 “Diseño de Interfaz gráfica Responsivo del Comensal” ..... 29
5.4. Planificación Sprint 2 “Diseño de Interfaz gráfica responsive de la Cocina” ........ 33
5.5. Planificación Sprint 2 “Diseño de interfaz gráfica responsive del Administrador” 37
v

5.5.2. Diagrama de Burn Down del Sprint 2 “Diseño de la interfaz gráfica del
Comensal, Cocina y Administrador” ................................................................ 43
CAPITULO VI
ITERACION - II
6.1. Introducción .......................................................................................................... 45

6.2. Planificación Sprint 3 “Implementación de la carta menú Comensal” .................. 45
6.3. Planificación Sprint 3 “Implementación de la lista de pedidos para la cocina” .... 53
6.4. Planificación Sprint 3 “Implementación de la gestión de Administrador” ............ 57
6.4.2. Diagrama de Burn Down del Sprint 3 “Implementación de la gestión del
Comensal, Cocina y Administrador” ................................................................ 66
CAPITULO VII
ITERACION - III
7.1. Introducción ........................................................................................................... 68

7.2. Planificación Sprint 4 “Autentificación del cocinero y administrador” ................ 68
7.2.2. Diagrama de Burn Down del Sprint 4 “Autentificación del Cocinero y
Administrador” .................................................................................................. 72
7.3. Planificación Sprint 5 “Distribución de Software” ................................................ 73
7.3.2. Diagrama de Burn Down del Sprint 5 “Distribución de Software” .................. 77
vi

CAPITULO VIII
CONCLUCIONES Y RECOMENDACIONES
8.1. Conclusiones .......................................................................................................... 78

8.2. Recomendaciones .................................................................................................. 79
Referencias Bibliográficas ..................................................................................... 80
vii

ÍNDICE DE FIGURAS
FIGURA 2.1: Organigrama del Restaurante ...................................................................... 4

FIGURA 2.2: Diagrama del Proceso de Atención ............................................................. 7
FIGURA 3.1: Características Sistema Reactivo ................................................................ 11
FIGURA 3.2: Diagrama de Modelo Orientado a Eventos ................................................. 13
FIGURA 3.3: Arquitectura para el Diseño de Aplicaciones Moviles ............................... 15
FIGURA 3.4: Estructura de Archivos Frame Sistema Reactivo ...................................... 16
FIGURA 3.5: Marco de Trabajo SCRUM ......................................................................... 18
FIGURA 5.1: Diagrama de Gantt Sprint 1 (Análisis, Diseño y Creación de la Base de
Datos) .......................................................................................................... 23
FIGURA 5.2: Esquema B.D. ............................................................................................. 25
FIGURA 5.3: Diagrama Burn Down Sprint 1 ................................................................... 28
FIGURA 5.4: Diagrama de Gantt Sprint 2 (Diseño de Interfaz Gráfica Responsive del
Comensal) .................................................................................................. 29
FIGURA 5.5: Diagrama de Gantt Sprint 2 (Diseño de Interfaz Gráfica Responsive de la
Cocina) ....................................................................................................... 33
FIGURA 5.6: Diagrama de Gantt Sprint 2 (Diseño de Interfaz Gráfica Responsive del
Administrador) ........................................................................................... 38
FIGURA 5.7: Diagrama de Burn Down Sprint 2 .............................................................. 43
FIGURA 6.1: Diagrama de Gantt Sprint 3 (Implementación de la Carta Menú Comensal)
............................................................................................................................................ 46
FIGURA 6.2: Diagrama de Gantt Sprint 3 (Implementación de la Lista de Pedidos para la
Cocina) ........................................................................................................ 54
FIGURA 6.3: Diagrama de Gantt Sprint 3 (Implementación de la Gestión de
Administrador) ........................................................................................... 57
FIGURA 7.1: Diagrama de Gantt Sprint 4 (Autentificación del Cocinero y Administrador)
............................................................................................................................................ 69
FIGURA 7.3: Diagrama de Gantt Sprint 5 (Distribución de Software) ............................ 74
viii

ÍNDICE DE TABLAS
TABLA 5.1: Sprint 1 (Análisis, Diseño y Creación de la Base de Datos) ........................ 22

TABLA 5.2: Retrospectiva del Sprint 1 ............................................................................ 28
TABLA 5.3: Sprint 2 (Diseño de Interfaz Gráfica Responsive del Comensal) ................. 29
TABLA 5.4: Sprint 2 (Diseño de Interfaz Gráfica Responsive de la Cocina) ................... 33
TABLA 5.5: Sprint 2 (Diseño de Interfaz Gráfica Responsive del Administrador) ......... 37
TABLA 6.1: Sprint 3 (Implementación de la Carta Menú Comensal) .............................. 45
TABLA 6.2: Sprint 3 (Implementación de la Lista de Pedidos para la Cocina) ............... 53
TABLA 6.3: Sprint 3 (Implementación de la Gestión de Administrador) ........................ 57
TABLA 7.1: Sprint 4 (Autentificación del Cocinero y Administrador) ............................ 68
TABLA 7.3: Sprint 5 (Distribución de Software) ............................................................. 73
ix

ÍNDICE DE IMÁGENES
IMAGEN 5.1: Creación de la Base de Datos .................................................................... 27

IMAGEN 5.2: Mockups del Comensal .............................................................................. 31
IMAGEN 5.3: Mockup Usuario Cocina ............................................................................ 35
IMAGEN 5.4: Mockups Administrador ............................................................................ 40
IMAGEN 6.1: Lectura del código QR ............................................................................... 47
IMAGEN 6.2: Menú principal del comensal ..................................................................... 49
IMAGEN 6.3: Lista menú del comensal ........................................................................... 50
IMAGEN 6.4: Lista pedido del comensal ......................................................................... 52
IMAGEN 6.5: Lista de órdenes de la cocina ..................................................................... 55
IMAGEN 6.6: Creación de Categorías .............................................................................. 59
IMAGEN 6.7: Lista de Categorías .................................................................................... 59
IMAGEN 6.8: Menú Configuración .................................................................................. 61
IMAGEN 6.9: Creación de la Nueva Planificación del Menú .......................................... 61
IMAGEN 6.10: Menú General .......................................................................................... 62
IMAGEN 6.11: Lista de Menús por Categorías ................................................................ 62
IMAGEN 6.12: Creación de Categorías ............................................................................ 63
IMAGEN 6.13: Añadir nuevo ítem al Menú ..................................................................... 63
IMAGEN 7.1: Inicio de Sesión .......................................................................................... 71
x

FICHA RESUMEN
GRADO: LICENCIATURA EN INGENIERÍA DE SISTEMAS

TIPO DE TRABAJO: PROYECTO DE GRADO
FACULTAD: CIENCIAS Y TECNOLOGÍA
CARRERA: INGENIERÍA DE SISTEMAS
TITULO DEL TRABAJO:APLICACIÓN MOVIL PARA LA GESTION DEL MENU Y TOMA
DE COMANDAS DE UN RESTARANT USANDO EL FRAMEWORK IONIC
AUTORES: ERICK ALEJANDRO ERGUETA BASCOPE

ANTONIO DAVID OVANDO ARCIENEGA
JUAN WINDZOR UREÑA ORDOÑEZ
TUTOR: LIC. CARMEN ROSA GARCIA PEREZ
RESUMEN:
El objeto de este proyecto es el desarrollo e implantación de una aplicación móvil para la
gestión del menú y toma de comandas de un restaurant. Esta aplicación ha sido
desarrollada para cubrir las necesidades básicas de la gestión de toma de comandas de
un restaurant, ofreciendo la tecnología existente al desarrollo del negocio. La aplicación
móvil está especialmente diseñada para aquellos restaurantes en la que la toma de
órdenes se las realiza de manera tradicional con una entrega del menú físico
proporcionado por un mesero y la toma de órdenes se la realiza de forma manual en un
papel. Esta aplicación ofrece un mejor servicio a los clientes, proporcionándoles una
forma diferente de información y atención de sus necesidades de manera virtual, la misma
también propone una revolución en la gestión de los diferentes elementos principales del
negocio, haciendo uso de las nuevas tecnologías en servicio de sus usuarios con sus
dispositivos móviles. Se ha dividido el sistema en tres aplicaciones fundamentales,
módulo Administrador, modulo Cliente y modulo Cocina. Estos módulos ofrecen una
funcionalidad distinta, y juntos controlan la gestión de toma de órdenes.
Las herramientas que se emplearon para el desarrollo son: Node.js, RethinkDB,

Socket.IO, Ionic, AngularJS y Gulp.js.
Palabras claves: Programación Reactiva, Framework Ionic, Node.js, RethinkDB, Hibrido y

SCRUM.
xi

CAPITULO I
INTRODUCCIÓN
1.1. Antecedentes
Actualmente en la mayoría de los restaurantes, se realiza la gestión de manera obsoleta,
apoyándose únicamente en un software que permita registrar las comandas (pedidos de los
comensales) y emitir facturas.
Las comandas y el menú hoy en día aún se siguen anotando y proporcionando en papel, lo
cual muchas veces con anotaciones y descripciones muy poco claras, y aun así se siguen
transmitiendo oralmente o por escrito y eso lleva a que muchas veces las peticiones que
realizan los comensales o clientes tengan consecuentes equivocaciones humanas por falta
de entendimiento.
Todos estos posibles inconvenientes se solventaran gracias a la implementación de una
aplicación móvil para la gestión y administración de las comandas.
Por otro lado en la actualidad el uso de dispositivos se ha incrementado exponencialmente,
tanto así que se podría decir que la mayoría de la población cuenta con un dispositivo
inteligente (Tablet, Smartphone, etc.), y a la par surgen nuevas tecnologías con el objeto de
mejorar la productividad y aumentar la calidad de la atención al cliente. Estos dispositivos
electrónicos y tecnologías permiten simplificar los procesos, agilizar la gestión y reducir los
tiempos de espera de los clientes.
El análisis de esta situación, ha permitido llegar a la conclusión de que existe la posibilidad
de mejora en el proceso de atención al comensal de un restaurante usando tecnologías para
el desarrollo de aplicaciones móviles.
1.2. Definición del Problema.

Inexistencia de una aplicación móvil que permita gestionar el menu y la toma de comandas
de un restaurant.
1.3. Objetivo general

Desarrollar una aplicación móvil para la gestión del menu y toma de comandas de un
restaurant.
1

1.4. Objetivos Específicos

• Recolectar información del proceso de toma de comandas de un restaurant.
• Desarrollar una aplicación móvil para los comensales para mostrar la variedad de
platos y bebidas de un restaurante.
• Desarrollar una aplicación móvil y web para la administración del menú para el
administrador del restaurant.
• Desarrollar una aplicación móvil y web para el procesamiento de órdenes de los
comensales para el administrador de la cocina.
• Desarrollar un modulo para la administración de publicidad, promociones y
sugerencias de los comensales.
• Resportes de consumo diario del restaurant.
1.5. Justificación
Con la implementación de esta aplicación móvil se pretende innovar el proceso de gestión y
administración de toma de comandas, con el fin de agilizar la atención y brindar una
alternativa diferente a la forma tradicional.
Aportar una mayor utilidad y conocimiento a los clientes acerca del menú y los servicios
que ofrece el restaurante, desplegando de forma virtual el menú, con acceso a ingredientes,
fotografías y costo.
Ofrecer una mayor precisión en la información transmitida hacia la cocina, evitando
posibles errores humanos en la comprensión de las comandas por parte de los meseros.
Mejorar la gestión general de las comandas, reduciendo tiempos de atención del mesero
hacia los clientes o comensales, y transmitiendo una información correcta, instantánea y
segura desde la mesa hasta la cocina.
Mejorar la gestión de reparto de trabajo en la cocina gracias a la visualización de las
comandas en tiempo real en el módulo de la cocina.
Dotar al restaurante de información exacta y detallada, para el estudio sobre los pedidos
realizados por los clientes, los platos más demandados y menos demandados que permita la
importante toma de decisiones sobre actualizaciones en el menú y otras decisiones que el
administrador crea necesarias.
2

1.6. Alcances
• Se proveerá un sistema para la gestión del menu y comandas basado en una arquitectura
Cliente – Servidor.
• Gestión del menú: se mostrara información detallada sobre la composición y
elaboración de los platos.
• Gestión de las comandas: se transmitirá directamente desde la mesa del cliente a través
de su dispositivo inteligente (Android, IOS), las peticiones que realice hasta un modulo
en la cocina, donde se podrá visualizar quien realizó la comanda y en que consiste.
• Gestión de las sugerencias o promociones: El administrador del restaurante y de la
aplicación podrá introducir todas las ofertas a través del menú directamente a la
aplicación.
• El sistema trabajara sobre la red WiFi del establecimiento.
• El sistema no incluirá gestión contable y manejo de existencias.
• El sistema estará enfocado para establecimientos que manejan el procedimiento
tradicional donde el cliente es atendido por un mesero.
3

CAPITULO II
RESTAURANTE
2.1. Introducción
El término francés restaurant llegó al idioma español como restorán o restaurante. Se trata
del comercio que ofrece diversas comidas y bebidas para su consumo en el establecimiento.
Dicho consumo debe ser pagado por el cliente, que suele ser conocido como comensal
(Perez, Merino, 2016).
2.2. Organización
En la figura 2.1 se describe la organización del restaurante, además se analizan los perfiles
que se verán afectados por el sistema, diferenciando aquellos que se verán afectados por la
implantación, los cuales estan resaltados en un cuadro sombreado de color naranja (Diaz,
2010).
Gerente
Contable
Jefe Departamento Jefe Departamento
Ventas Administración
Chef Mesero Encargado Proveedores Sueldo

del Salón
Ayudante de Meseros Seguridad Limpieza

Cocina
Figura 2.1: Organigrama del Restaurante

[Fuente: Elaboracion Propia]
El organigrama descrito representa los diferentes perfiles que componen la estructura

organizativa de un restaurante. Es importante estudiar los perfiles generales que componen
4

un restaurante ya que la implantación del sistema, tendrá́ un impacto positivo en el

funcionamiento general de muchos de ellos(Diaz, 2010).
A continuación se describen los participantes de dicha estructura:(Diaz, 2010)

• Gerente: es la persona encargada de la supervisión directa de los subordinados más
próximos y de la organización en su globalidad. Asignando recursos como pueden
ser capitales, materias primas, etc. o incluso delegando poder en las unidades para
su adecuado funcionamiento pero siempre bajo su supervisión. A la vez gracias a
esta supervisión puede detectar anomalías y resolverlas. Dentro de este conjunto de
obligaciones también se encuentra el difundir de conocimientos o información que
deben conocer el resto de personal. Con todas estas obligaciones o funciones logra
que la organización funcione debidamente como una unidad integrada.
• Contable: es el encargado de obtener y registrar datos contables, estadísticos y
financieros, así como efectuar pagos y cobros. Realiza asientos en los registros o
libros de contabilidad, efectúa cálculos, realiza costos de producción, hace
transacciones bancarias, calcula los salarios a pagar partiendo de los registros de
horas trabajadas por cada trabajador, y es el encargado de la Tesorería.
• Jefe departamento de ventas: es el responsable de la apertura y cierre del local,
asigna y supervisa tareas, es el encargado de la caja, de las compras, relaciones
públicas y marketing.
• Jefe departamento de administración: realiza el pago a los proveedores,
acreedores, administra las operaciones bancarias, legales, y los sueldos de los
empleados.
• Proveedores: es el agente económico que entrega o provee materias primas,
materiales o servicios, tiene la responsabilidad de cumplir con los compromisos de
entrega pactados, según el lugar y el tiempo acordados. Su misión es fundamental
para la prestación del servicio en un restaurante, suelen ser empresas externas y
están especialmente supervisadas por el jefe del departamento de administración.
• Encargado de Sueldos: encargados de la administración y supervisión de los
salarios a los empleados.
5

• Chef: es el responsable del control de mercaderías y faltantes, la realización y

elaboración de los distintos menús, control de higiene de la cocina y empleados,
cuidado de los bienes de uso para realizar los menús, y todas las tareas
desempeñadas en la cocina.
• Ayudantes de cocina: son colaboradores en la realización de los menús, mantienen

la higiene de la cocina y cuidan de los bienes de uso de la cocina. Además realizan
tareas de agilidad para el trabajo del chef, ayudando en la elaboración de platos.
• Mesero encargado del salón: es el responsable de la organización del salón, del
control de bienes y mercadería de salón, se encarga de seleccionar sectores para
cada mesero, y supervisa sus tareas. También realiza la recepción y acomodamiento
de clientes en el restaurante.
• Meseros: son los encargados del orden y limpieza del salón, del cuidado de su
sector de trabajo, atienden las comandas de los clientes de una forma cordial y
eficaz y reordenan el sector de trabajo después del servicio.
• Seguridad: es el responsable del mantenimiento de la seguridad dentro y fuera del
local, y vela por el orden en el restaurante.
• Limpieza: son los encargados de la higiene y limpieza de todo el local, de los
elementos de cocina y del salón.
6

2.3. Proceso de atención

En la figura 2.2 se muestra el procedimiento habitual del funcionamiento de un
restaurant(Diaz, 2010).
Bienvenida
No
Mesa Libre
Acomodar
Bebidas
Orden de bebidas
y aperitivos
SI Comida
Tramitar Comanda
¿Algo más?
NO
NO
Cobrar y Despedir

Figura 2.2: Diagrama del Proceso de Atención

A continucacion se detalla el procesos de atencion de un restaurate tal como se muestra en

la figura 2.2: (Diaz, 2010)
7

• Bienvenida: La principal función del mesero encargado del salón es dar la

bienvenida los clientes y preguntarles la cantidad de personas que ocuparán la mesa.
Inmediatamente, se buscará un sitio disponible si existe y después deberá
acomodarlos en la mesa. Aquellos establecimientos que dispongan de áreas de
fumadores y no fumadores, se colocará al cliente según la predilección.
Una vez en la mesa, el mesero debe acomodarlos sacando las sillas, teniendo
preferencia las damas. El mesero encargado del salón procederá a registrar los
clientes en el registro y control de reservaciones, colocando la cantidad de clientes,
la hora y el número de mesa asignado.
• Orden de bebidas y aperitivos: Una vez abordados los clientes y después de darle
la bienvenida, el mesero preguntará si el cliente desea algún aperitivo, vino, cóctel u
otras bebidas antes de ver el menu. Después de servir la bebida el mesero debe
preguntar si los clientes desean algún entremés. Después de servido el entremés, el
mesero debe preguntar si desean repetir sus bebidas o prefieren ver el menu. En
caso de que el cliente solicite ver el menu, la misma será entregada por el mesero.
• Tramitar comandas: Se atiende a los clientes, y se anotan las comandas. El mesero
que ha tomado la comanda, debe entregar de inmediato, no olvidando apuntar en
ésta la hora exacta en que se terminó de tomar la camanda.
La distribución de las copias de la comanda se realiza según el estándar del
establecimiento, que generalmente es de la manera siguiente: la original a cocina,
una copia a la caja y una segunda copia al mesero de cocina.
Las comandas deberán pasar primeramente por la caja, para que la cajera verifique
si concuerdan las copias y ésta sellará o firmará las que irán a la cocina, se quedará
con la que le corresponde y devolverá el resto de las copias al Mesero, quien
inmediatamente deberá dirigirse a la cocina y entregar la comanda al supervisor.
Este canta el pedido y la cocina funciona.
• La despedida: El servicio termina con la despedida al cliente.
El momento de la despedida es muy importante, ya que es la última impresión que
el cliente se lleva del establecimiento.
Es responsabilidad delmesero despedirlo en la mesa cuando se levanta y en la puerta
debe despedirlo el encargado del salón.
8

CAPITULO III
HERRAMIENTAS Y METODOLOGIA
3.1. Programación móvil
Hoy en día se dispone de una infinidad de herramientas, lenguajes y entornos para el
desarrollo de aplicaciones móviles como ser:
• Los lenguajes y herramientas nativos de cada plataforma: ObjectiveC/Swift y
XCode en iOS, Java y Android Studio en Android, C#, XAML y Visual Studio en
el caso de Windows Phone y Windows 8.
• Herramientas multiplataforma que compilan a código nativo: La más conocida y
utilizada es Xamarin.
• Herramientas multiplataforma basadas en HTML: La más conocida es Ionic/Apache
Cordova, pero existen muchas más.
Cada una de estas opciones tiene sus ventajas y desventajas, a continuación se da una breve
descripción de ellas (CampusMVP, 2014).
3.1.1. Desarrollo Nativo

El desarrollo nativo significa usar el mismo lenguaje de programación de la plataforma para
la cual se esta desarrollando, por lo tanto es considerado como la mejor opción.
Cada plataforma móvil (iOS, Android, Windows Phone) utiliza un lenguaje de
programación diferente, herramientas propias y paradigmas de programación particulares,
por lo cual se obtiene la máxima flexibilidad, adaptación total al entorno en el que se
ejecuta la aplicación y el máximo rendimiento.
Una de las principales desventajas es que se tiene que dominar muchos lenguajes y
herramientas y que el tiempo de desarrollo se multiplica, pues es necesario crear desde cero
tres versiones diferentes de la misma aplicación (una para cada plataforma).
Los programadores en general solamente se especializan y eligen una única plataforma
(Paradigmas de programación, 2017).
3.1.2. Desarrollo multiplataforma compilado a nativo
Mediante el uso de este tipo de herramientas se utiliza un único lenguaje y se crean
aplicaciones para todas las plataformas, reutilizando gran parte del código, y de esta manera
generar aplicaciones nativas para todos los entornos móviles.
9

La más conocida es Xamarin. Está basada en el lenguaje C# de Microsoft y en la

plataforma .NET, gracias a sus herramientas permite crear aplicaciones para todas las
plataformas, reutilizando gran parte del código (a excepción de la interfaz) (Paradigmas de
programación, 2017).
3.1.3. Desarrollo multiplataforma basado en HTML5

Las apps escritas en HTML5 permiten crear la interfaz usando HTML, CSS y JavaScript,
creando un contenedor para la aplicación la cual se ejecuta como si estuviese en un servidor
web local que brinda gran parte de la funcionalidad nativa del dispositivo móvil a través de
librerías.
Entre las desventajas principales están que las aplicaciones no tiene el mismo rendimiento
que una app nativa, ni tampoco te dan acceso a todas las APIs nativas de cada plataforma
(Paradigmas de programación, 2017).
3.2. Paradigmas de Programación

Un paradigma de programación es una propuesta tecnológica adoptada por una comunidad
de programadores y desarrolladores cuyo núcleo central es incuestionable en cuanto que
únicamente trata de resolver uno o varios problemas claramente delimitados; la resolución
de estos problemas debe suponer consecuentemente un avance significativo en al menos un
parámetro que afecte a la ingeniería de software(Paradigmas de programación, 2017).
3.3. Programación Reactiva

Es un paradigma de la programación orientada al flujo de datos y a la propagación de
cambios. Cómo lo indica su denominación, la programación reactiva está orientada a la
reacción, al flujo de datos y al principio de causalidad, es decir, cada causa está asociada a
sus efectos.
Quizá el ejemplo más conocido es el de las planillas de cálculo; donde la modificación de
una celda (evento) desencadena la posterior modificación de todas las celdas que la
estaban observando. Y “observando” es una de las palabras clave porque es más fácil
entender el tema si se tiene conocimiento del patrón GoF observer (Fundamentos de la
programación reactiva, 2016).
10

3..3.1. Maniifiesto de laa programaación reactiiva

See reescribióó a fines de 2014 y, seegún éste, loos sistemas reactivos ttienen 4 carracterísticass,
co
omo se mueestran en la figura 3.1:
• Respoonsividad: Están
E enfoccados a tiem
mpos de resspuesta rápiidos y conssistentes. See
simpllifica el trataamiento de errores y see incita a la interacciónn con el usuaario
• Resiliiencia: Los sistemas seguirán
s sieendo responnsivo incluuso en la presencia
p dee
falloss. Para quee esto se logre,
l las fallas debeen ser aisladas y con
ntenidas enn
compponentes y deben
d poderr recuperarse sin comprrometer a laa integridad del mismo..
• Elastiicidad: Porqque se adapptan a variaaciones en la carga de trabajo, asignando
a y
liberaando recurssos de forrma dinám
mica, y poorque se ddiseñan parra que suss
compponentes no formen cueellos de boteella.
• Orienntados a mensajes:
m Se confía pplenamente en el inteercambio de
d mensajess
asíncrronos. No existe
e la coomunicaciónn bloqueannte (Jonas Bonér,
B Farley, Kuhn y
Thom
mpson, 20144).
Figura 3.1:
3 Características Sistema Reeactivo
[Fuente: http://www.reeactivemanifestoo.org/]
3..4. Progrramación Reactiva
R Orientada a Objetos
Ess una combbinacion de la progarm
macion orienntada a objjetos y proggramacion reactiva.
r Laa
foorma más naatural de haacer tal com
mbinación ess la siguientte: En lugarr de métodos y camposs,
loos objetos tiienen reacciiones que reeevalúan auutomáticameente cuandoo se emite un
u evento al
a
cu
ual el objetoo esta suscriito (Tejerinaa, 2008).
11
1

3.5. Sockets
Es un método para la comunicación entre un programa del cliente y un programa del
servidor en una red. Un socket se define como el punto final en una conexión. Los sockets
se crean y se utilizan con un sistema de peticiones o de llamadas de función a veces
llamados interfaz de programación de aplicación de sockets (API, application programming
interface). Un socket es también una dirección de Internet, combinando una dirección IP (la
dirección numérica única de cuatro partes que identifica a un ordenador particular en
Internet) y un número de puerto (el número que identifica una aplicación de Internet
particular, como FTP, Gopher, o WWW).
WebSocket es una tecnología que proporciona un canal de comunicación bidireccional y
full-duplex sobre un único socket TCP. Está diseñada para ser implementada en
navegadores y servidores web, pero puede utilizarse por cualquier aplicación
cliente/servidor (Definición de Socket, 2017).
3.6. RethinkDB
RethinkDB es una base de datos open source, NoSQL, distribuida orientada a documentos,
creada originalmente por la compañía del mismo nombre. La base de datos almacena
documentos JSON con esquemas dinámicos y está diseñada para facilitar empujar
actualizaciones en tiempo real para resultados de consultas a aplicaciones. Inicialmente
financiada por Y Combinator en junio de 2009, la compañía anunció en octubre de 2016
que no había sido capaz de construir un negocio sostenible y que sus productos serían en el
futuro enteramente de código abierto sin apoyo comercial (RethinkDB pushes JSON to
your apps in real time, 2017).
3.7. Node.Js
Node.js es una librería y entorno de ejecución de E/S dirigida por eventos y por lo tanto
asíncrona que se ejecuta sobre el intérprete de JavaScript creado por Google V8 como se
muestra en la figura 3.2.
12

Figura 3.2: Diagrama de Modelo Orientado a Eventos

Con Node.JS se tiene un "Javascript sin restricciones", ya que todo se ejecuta del lado del
servidor, esta diseñado para potenciar los beneficios de la programación asíncrona.
La filosofía detrás de Node.JS es hacer programas que no bloqueen la línea de ejecución de
código con respecto a entradas y salidas, de modo que los ciclos de procesamiento se
queden disponibles cuando se está esperando a que se completen tales acciones
(Node.js ,2016).
3.8. Framework Ionic

Ionic es una herramienta gratuita y open source, para el desarrollo de aplicaciones
híbridasbasadas en HTML5, CSS y JavaScript. Sus principales ventajas son: (Apache
Cordova, 2016)
• Unica fuente: Desde una única fuente se tiene que llegar a las plataformas que
soporta este framework (Android e iOS).
• Alto rendimiento: Ionic está construido para ser rápido gracias a la mínima
manipulación del DOM, con cero jQuery y con aceleraciones de transiciones por
hardware.
• Integracion Nativa: Proporcina un variedad de librerias que permite acceder a la
mayoria de las interfaces nativas.
13

• Diseño adaptable: Ionic ha sido diseñado para poder trabajar con todos los
dispositivos móviles actuales. Con muchos componentes usados en móviles,
tipografía, elementos interactivos, etc.
Entre las principales desventajas se tiene:
• El rendimiento puede ser ligeramente menor que las aplicaciones desarrolladas de
forma nativa, pero no de forma al menos que el proyecto sea para la creación de
juegos con gráficosdetallados u otras aplicaciones que hagan uso de grandes
cantidades de recursos.
• Es una herammienta joven de modo que aun se estan cambiando y afinando algunas
características tanto del framework como de sus normas en lo que a soporte, uso,
bibliotecas y demás se refiere (Mocholí, 2015).
3.8.1. Estructura del Framework Ionic

Las aplicaciones de Ionic se construyen con Apache Cordova, el cual es un medio de
empaquetar HTML / CSS / JavaScript en aplicaciones que pueden ejecutarse en
dispositivos móviles. Cordova proporciona plugins para acceder a la funcionalidad nativa
de los dispositivos moviles como ser sistema de archivos, camara, gps, lector de huellas y
otras interfaces ta como se ilustra en la figura 3.3.
14

Arquitectura – Mobile App Design
CordovaPlugins
Acceleromete Geolocation
Web App
Camara Media
HTML/JS/ Native
Ionic Framework CSS APIs HTML APIs
Motor de Compass Red

Angularjs Renderizado
Cordova
(Web View) File Storage
JS APIs
HTML/JavaScript/CSS Navegador
Keyboard Push
Notifications
OS API`s OS API`s
Mobile OS
Services Sensors PushNotifications
(Android, iOS, etc) InPut Graphics
Figura 3.3: Arquitectura para el Diseño de Aplicaciones Moviles

Como tal, las aplicaciones de Ionic tienen la estructura de archivos que propone el servidor
Apache Cordova, tal como se ilustra en la figura 3.4.
El directorio Cordova contiene los archivos necesarios para ejecutar el servidor.El
directorio Platforms contiene los proyectos de iOS y Android, en general, no es necesario
trabajar en este directorio ya que es generado automaticamente por Ionic, a menos que esté
haciendo una personalizacion a nivel nativo para enviar la aplicación a la producción.
El directorio Hooks son acciones particulares que deben tomarse para una plataforma en
particular, es útil para proyectos grandes que requieren procesos automatizados para
modificarcodigo fuente (Mocholí, 2015).
15

F
Figura 3.4: Estrructura de Archhivos Frame Sisstema Reactivo
[Fuente: Elaborracion propia]
Ell directorio
o Plugins es
e donde ell Servidor Apache Co
ordova guaarda los com
mplementoss
neecesarios paara acceder a funcionallidades nativvas, el comaando para aañadir un plu
ugin es:
ionnic plugin add

a {plugin}}
Donde {plugin} es el ideentificador del

d complem
mento o la url
u de githuub.
Ell directorio WWW es donde se desarrolla la aplicación y donde see pasara la mayor
m partee
ucción de la aplicación en Ionic, laa manera de organizar la
deel tiempo enn la constru l estructuraa
dee archivos es
e discutiblee pero de fo
orma predeteerminada, Ionic organiiza tu aplicaación en unaa
seerie de direcctorios: css, img, js, lib y plantillass.
Controllers.jss contiene los
l controlaadores de A
Angujar.js para los estaados que los requieren
n.
Seervices.js no
n siempree está inclu
uido en loos iniciadorres, pero ccontiene lo
os servicioss
peersonalizado
os Angular que su apllicación pueede usar, co
omo uno quue llama a una API dee
teerceros para obtener infformación que
q utiliza suu aplicación
n.
LIIB es dondde se puedee colocar cualquier otra
o biblioteeca que utiilice, TEMP
PLATES ess
do
onde van tu
us archivos de vista. Su
S proyectoo tiene un archivo
a prinncipal index
x.html en el
diirectorio WW
WW, pero su
s aplicació
ón probablem
mente contiiene muchass vistas de plantilla
p quee
see añaden din
námicamentte (Mocholíí, 2015).
16
6

3.9. SCRUM
Scrum es un marco de desarrollo ágil y iterativo de desarrollo de software para gestionar el
desarrollo de productos. Define una estrategia flexible de desarrollo de productos en la que
un equipo de desarrollo trabaja como una unidad para alcanzar un objetivo común, permite
a los equipos organizar una estrecha colaboración en línea de todos los miembros del
equipo, así como la comunicación cara a cara diaria entre todos los miembros del equipo y
las disciplinas involucradas.
Los roles principales en Scrum son el Scrum Master, que procura facilitar la aplicación de
scrum y gestionar cambios, el Product Owner, que representa a los stakeholders
(interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás
elementos relacionados con él. Durante cada sprint, un periodo entre una y cuatro semanas
(la magnitud es definida por el equipo y debe ser lo más corta posible), el equipo crea un
incremento de software potencialmente entregable (utilizable). El conjunto de
características que forma parte de cada sprint viene del Product Backlog, que es un
conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI,
Product Backlog Item). Los elementos del Product Backlog que forman parte del sprint se
determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner
identifica los elementos del Product Backlog que quiere ver completados y los hace del
conocimiento del equipo. Entonces, el equipo conversa con el Product Owner buscando la
claridad y magnitud adecuadas para luego determinar la cantidad de ese trabajo que puede
comprometerse a completar durante el siguiente sprint, como se muestra en la figura 3.5
(Priolo, 2009).
17

Figurra 3.5: Marco dee Trabajo SCRU

UM
[Fuente: Sccrum.org]
Durante el sp
print, nadie puede camb
biar el Sprinnt Backlog, lo que signnifica que lo
os requisitoss
esstán congelaados durantee el sprint.
U principio clave de Scrum
Un S es el reconocimiiento de que durante un
u proyecto los clientess
pu
ueden camb
biar de ideaa sobre lo qu
ue quieren y necesitan
n (a menudoo llamado reequirementss
ch
hurn), y quee los desafío
os impredeccibles no pueden ser fáccilmente enfrentados de una formaa
prredictiva y planificad
da. Por lo tanto, Scrrum adoptaa una aprooximación pragmáticaa,
acceptando que
q el prob
blema no puede serr completam
mente enteendido o definido, y
ceentrándose en
e maximizzar la capaccidad del eqquipo de en
ntregar rápid
damente y responder a
reequisitos em
mergentes.
Laas caracteríísticas más marcadas que
q se lograan notar en
n Scrum serrían: gestión
n regular dee
laas expectativvas del clieente, resultados anticippados, flex
xibilidad y adaptación,, retorno dee
in
nversión, m
mitigación de
d riesgos, productividdad y calid
dad, alineam
miento entrre cliente y
eq
quipo, por úúltimo equip
po motivad
do. Cada un
no de estos puntos
p menncionados hacen
h que el
Sccrum sea uttilizado de manera
m regu
ular en un co
onjunto de buenas
b práccticas para el
e trabajo en
n
eq
quipo y de esa
e manera obtener resu
ultados posiibles.
Ex
xisten variaas implemen d sistemas para gestion
ntaciones de nar el proceeso de Scru
um, que van
n
deesde notas amarillas
a "p
post-it" y pizarras hastta paquetes de softwarre. Una de las
l mayoress
veentajas de S
Scrum es que
q es muy fácil de ap
prender, y requiere muuy poco essfuerzo paraa
18
8

comenzarse a utilizar. Así, si se utiliza una pizarra con notas autoadhesivas cualquier
miembro del equipo podrá ver tres columnas: trabajo pendiente ("backlog"), tareas en
proceso ("in progress") y hecho ("done"). De un solo vistazo, una persona puede ver en qué
están trabajando los demás en un momento determinado (Priolo, 2009).
19

CAPITULO IV
PLANIFICACION DEL PROYECTO
4.1 Metodología a Aplicar
Este trabajo incluye un conjunto de procedimientos de ciclo vital iterativa e incremental
para el proyecto, donde se analiza los primeros requerimientos para la entrega de
documentos frecuentes y continuos al dueño del producto en un mínimo de tiempo, donde
este podrá ver la dimensión completa del sistema y así realizar mejoras continuas.
En Scrum los requisitos se expresan como elementos del producto Backlog, el producto
Backlog es una lista viva de requisitos funcionales y no funcionales priorizados por su
valor para el cliente. Al decir que se trata de una lista viva, se deja claro que los requisitos
que en ella aparecen y el orden de los mismos es cambiante a lo largo de la vida del
proyecto. En Scrum, los requisitos se van abordando en Sprints en el orden en que aparecen
en el producto Backlog.
4.2 Herramientas para Desarrollar la Metodología Scrum

La herramienta para desarrollar la metodología Scrum será el uso de planillas Excel.
Se ha utilizado esta herramienta para rastrear el estado diario de cada sprint, el producto
Backlog, las historias de usuario y las reuniones.
4.3 Producto Backlog

Se ha realizado una reunión con el cliente, y se ha obtenido una lista de objetivos y
requisitos priorizada, esta representa la visión y expectativa del cliente respecto a los
objetivos y entrega del proyecto.
Se ha explicado al cliente que él es responsable de crear y gestionar la lista (con la ayuda
del equipo, quien proporciona el tiempo estimado de completar cada requisito). Dado que
refleja la expectativa del cliente, esta lista permite involucrar en la dirección de los
resultados del producto.
20

PRODUCT BACKLOG
ID PRODUCT ESTIMACION DIAS

ESTADO ITER.
SPRINT BACKLOG EN DIAS REALIZADOS
Análisis, diseño y
S1 creación de la base 6 días 3 días Terminado 1
de datos
Diseño de interfaz
S2 gráfica responsive 6 días 5 días Terminado 1
del Comensal
Diseño de interfaz
de la cocina
Diseño de interfaz
del Administrador
Implementación de
S3 la gestión del menú 15 días 16 días Terminado 2
Comensal
Implementación de
de la cocina
Implementación de
del Administrador
Autentificación del
S4 Cocinero y 5 días 3 días Terminado 3
Administrador
Reporte de ventas y
S5 Distribución de 5 días 5 días Terminado 3
software
73,0 63,0
21

CAPITULO V
ITERACION – I
5.1 Introducción
Este capítulo cubre la primera iteración del proyecto, la cual comprende de dos Sprints
relacionados al diseño, implementación de la base de datos y diseño de interfaces de los
usuarios.
5.2 Planificación Sprint 1 “Análisis, Diseño y Creación de la Base de Datos”

La tabla 5.1 describe las historias de usuario del sprint 1
SPRINT 1
NOMBRE: ANALISIS, DISEÑO Y CREACION DE LA BASE DE DATOS
FECHA INICIO: 12/12/2016 DURACION ESTIMADA: 6 Días
FECHA FIN: 14/12/2016 DURACION ESTIMADA: 48 Horas
HORAS
SPRIN HISTORIAS DE
ID RESP. TRABAJADAS
T USUARIO
EST. REA.
Análisis de
S1-H1 EQUIPO 16 8
Requerimientos B.D.
Diseño del Modelo

S1 S1-H2 A.D.O.A. 20 8
Documental
Implementación del
S1-H3 A.D.O.A. 12 8
Modelo Documental
48 24
Tabla 5.1: Sprint 1 (Análisis, Diseño y Creación de la Base de Datos)

[Fuente: Elaboración Propia]
22

• El diagrama de Gantt del sprint 1 “Análisis, Diseño y Creación de la Base de Datos” se

detalla en la figura 5.1 donde se visualiza las tareas en días.
Figura 5.1: Diagrama de Gantt Sprint 1(Análisis, Diseño y Creación de la Base de Datos)
5.2.1 Historias de Usuario

A continuación se describen los casos de prueba e historias de usuarios S1-H1, S1-H2 y S1-
H3.
• S1-H1: Análisis de Requerimientos B.D
El objetivo de esta tarea es definir las tablas requeridas para la implementación del
sistema.
¾ S1-H1:Casos de Prueba
ESCENARIO: CREACION Y DISEÑO DE LA BASE DE DATOS
SUB-ESCENARIO: Análisis de Requerimientos B.D.
No. TIPO DESCRIPCIÓN
Se realizó una simulación manual del proceso de toma

1 UN
de órdenes para la base de datos.
Se realizó una simulación manual del proceso de

2 UN
inserción de datos en las tablas del menú.
Se realizó una simulación manual del proceso para la

3 UN
gestión de órdenes de la cocina.
Se realizó un análisis grupal para llegar a un acuerdo

4 UN
mutuo con el análisis
23

¾ S1-H1:Historia de Usuario
Historia de Usuario: S1-H1
Nombre historia: Análisis de Requerimientos B.D.
Fecha Inicio: 12/12/2016 Fecha Fin: 12/12/2016
Descripción:
1. Se definió las tablas requeridas para la implementación del sistema.
2. Se estableció la relación entre las tablas.
• S1-H2: Diseño del Modelo Documental

El objetivo del modelo documental es el de diagramar las tablas utilizando la
herramienta online llamado Cacoo, como muestra en la figura 5.2.
SUB-ESCENARIO: Diseño del Modelo Documental.
Revisión minuciosa por parte del equipo para verificar

1 UN
el diseño en general.
2 UN Verificación de nombres de tablas y atributos.
Se realizó una simulación manual del proceso para la

3 UN
gestión de órdenes de la cocina.
Se realizó un análisis grupal para llegar a un acuerdo

4 UN
mutuo con el análisis
24

Figura 5.2: Essquema B.D.

[Fuente:
[ Elaborración Propia]
¾ S1-H2:Historria de Usuaario
H
S
N
Nombre historia: Diseñ
ño del Mode
elo Docume
ental
Fecha Inicio
o: 13/12/201
16 Fecha
a Fin: 13/12
2/2016
D
Descripción
n:
1. En base al
a sprint inicial, se toma
a el análisis y diseño prrevio de tod
das las
ta
ablas necessarias, poste
eriormente se realiza el
e diagrama correspond
diente.
2. En el desa
arrollo del diseño
d se re
ealizaron ca
ambios.
• S1-H33:Implemeentación del Modelo Documental

D l
El ob
bjetivo es la creación
n de la baase de dato
os Documeental en el manejadorr
Rethin
nkDB, com
mo muestra la
l imagen 5.1.
25
5

SUB-ESCENARIO: Implementación del Modelo Documental
1 UN Se verifico la creación de las tablas y atributos.
2 UN Se realizaron consultas de insertar, editar y eliminar
Se verifico la conexión y al acceso de la Base de

3 UN
Datos
Nombre historia: Implementación del Modelo Documental
Descripción:
1. Instalación y configuración de RethinkDB.
2. La creación de la estructura de la base de datos.
26

Imagenn 5.1: Creación de la Base de Datos

D
[Fuente:
27
7

5.2.2 Diagrama de Burn Down del Sprint 1“Análisis, diseño y creación de la base de
datos”
El diagrama de Burn Down del Sprint 1 se detalla en la figura 5.3 donde se visualiza las
horas de trabajo pendiente en el eje Y y los días trabajados en el eje X.
Diagrama Burn Down Sprint 1
30
25
20
15 Diagrama de Burn Down
Sprint 1
10
0
12‐dic 13‐dic 14‐dic 15‐dic

Figura 5.3: Diagrama Burn Down Sprint 1
5.2.3 Retrospectiva del Sprint 1
La tabla 5.2 detalla los problemas y las soluciones que surgieron durante el proceso del
Sprint 1
FECHA TAREA PROBLEMA LECCION RESP.
Se solucionó
Análisis de Problemas al
haciendo una
Requerimientos identificar las tablas EQUIPO
simulación manual
B.D. y atributos
del proceso
14/12/2016 Problemas de
instalación y Se solucionó
Implementación
configuración debido revisando la
del Modelo A.D.O.A.
a que no cuenta documentación
Documental
instalador para existente
plataforma Windows
Tabla 5.2: Retrospectiva del Sprint 1

28

5.3 Planificación Sprint 2 “Diseño de Interfaz gráfica Responsivo del Comensal”

La tabla 5.3, describe la tabla de planificación del Sprint 2 para el comensal.
SPRINT 2
NOMBRE: DISEÑO DE INTERFAZ GRAFICA RESPONSIVE DEL COMENSAL
HISTORIAS DE HORAS TRABAJADAS
SPRINT ID RESP.
USUARIO EST. REA.
Creación De
S2-H4 J.W.U.O. 16 8
Mockups
Implementación
J.W.U.O. /
S2-H5 del Diseño 24 24
E.A.E.B.
S2 Responsivo
Probar La Interfaz
S2-H6 En Diferentes E.A.E.B. 8 8
Plataformas
TOTAL HORAS 48 40
Tabla 5.3: Sprint 2 (Diseño de Interfaz Gráfica Responsive del Comensal)

• El diagrama de Gantt del sprint 2 “Diseño de Interfaz Gráfica Responsive del

Comensal”, se detalla en la figura 5.4 donde se visualiza las tareas en días.

Figura 5.4: Diagrama de Gantt Sprint 2 (Diseño de Interfaz Gráfica Responsive del Comensal)
29


A continuación se describen los casos de prueba e historias de usuarios S2-H4, S2-H5 y
S2-H6.
• S2-H4: Creación de Mockups
El objetivo es crear las maquetas de las interfaces de usuario para el comensal
usando la herramienta Balsamiq Mockups, con el fin de mostrar al cliente un
concepto previo de las pantallas de la interfaz del comensal para poder llegar a un
acuerdo mutuo con el mismo, como muestra la Imagen 5.2.
ESCENARIO: DISEÑO DE INTERFAZ GRAFICA RESPONSIVE DEL
COMENSAL
SUB-ESCENARIO: Creación De Mockups
En base a los requerimientos solicitados se identificó las

1 UN
posibles interfaces requeridas por el cliente.
2 UN Se identificares las principales pantallas del comensal.
3 UN Se crearon los Mockups de las principales pantallas.
Nombre historia: Creación De Mockup (Comensal)
Descripción:
1. Mockups de las principales pantallas del comensal
30

Imagen 5.2: Mockups del Comensal

• S2-H5: Implementación del Diseño Responsivo (Comensal)

Es la implementación de las interfaces responsive para el comensal usando las
herramientas Ionic Creator (https://creator.ionic.io) y Bootstrap
(http://getbootstrap.com/).
COMENSAL
SUB-ESCENARIO: Implementación del Diseño Responsivo
1 UN Se implementó las interfaces del comensal.
Se verifico que la información desplegada de la interfaz del

2 UN
comensal es la correcta.
31

Nombre historia: Implementación del Diseño Responsivo (Comensal)
Descripción:
1. Plantillas de la interfaz responsiva del comensal
• S2-H6: Probar la Interfaz en Diferentes Plataformas (Comensal)

Probar la correcta adaptabilidad de interfaz responsiva del comensal en dispositivos
IOs y Android en versiones superiores de IOs 6/Android 4.4.2.
COMENSAL
SUB-ESCENARIO: Probar la Interfaz en diferentes Plataformas
1 UN Se verifico la adaptabilidad en dispositivos Android.
2 UN Se verifico la adaptabilidad en dispositivos IOs.
Nombre historia: Probar la Interfaz en Diferentes Plataformas (Comensal)
Descripción:
1. Ser verifico que las interfaces del comensal son adaptables en los
dispositivos Android y IOs.
32

5.4 Planificación Sprint 2 “Diseño de Interfaz gráfica responsive de la Cocina”

La tabla 5.4, describe la tabla de planificación del Sprint 2 para la cocina.
SPRINT 2
NOMBRE: DISEÑO DE INTERFAZ GRAFICA RESPONSIVE DE LA COCINA
HISTORIAS DE HORAS TRABAJADAS

SPRINT ID RESP.
USUARIO EST. REA.
S2-H7 Creación de Mockups J.W.U.O. 16 8
Implementación del J.W.U.O. /

S2-H8 24 16
Diseño Responsivo E.A.E.B.
S2
Probar la Interfaz en
S2-H9 E.A.E.B. 8 8
Diferentes Plataformas
TOTAL HORAS 48 32
Tabla 5.4: Sprint 2 (Diseño de Interfaz Gráfica Responsive de la Cocina)

• El diagrama de Gantt del sprint 2 “Diseño de Interfaz Gráfica Responsive de la Cocina”

se detalla en la figura 5.5 donde se visualiza las tareas en días.
dic 2016
Id. Nombre de tarea Comienzo Fin Duración
20 21 22 23 24
1 S2-H7: Creación de Mockups 20/12/2016 20/12/2016 1d
S2-H8: Implementación del Diseño

2 21/12/2016 22/12/2016 2d
Responsivo
S2-H9: Probar la Interfaz en
3 23/12/2016 23/12/2016 1d
Diferentes Plataformas
Figura 5.5: Diagrama de Gantt Sprint 2 (Diseño de Interfaz Gráfica Responsive de la Cocina)
33


S2-H9.
• S2-H7: Creación De Mockups
El objetivo es crear maquetas para mostrar al cliente (Product Owner) un concepto
previo de las pantallas de la interfaz del cocinero para poder llegar a un acuerdo
mutuo con el mismo usando la herramienta Balsamiq Mockups, como muestra la
Imagen 5.3.
ESCENARIO:DISEÑO DE INTERFAZ GRAFICA RESPONSIVE DE LA
COCINA
En base a los requerimientos solicitados se identificó las
1 UN
posibles interfaces requeridas para la cocina.
Se identificares las principales pantallas para el usuario

2 UN
de la cocina.
Nombre historia: Creación de Mockup (Cocina)
Descripción:
1. Mockups de las principales pantallas del usuario de la Cocina.
34

Imaggen 5.3: Mockuup Usuario Cociina

[Fuente:
• S2-H88: Implemeentación deel Diseño R

Responsivo
Es la implementtación de las
l interfacees responsivas para ell usuario de
d la cocinaa
usanddo las herrramientas Ionic Creaator (http
ps://creator.ionic.io) y Bootstrap
p
(http:///getbootstrrap.com/)
¾ S2-H8:Casos de Pruebaa
ES
SCENARIO
O: DISEÑO DE INTERF
FAZ GRAFICA RESPO
ONSIVE DE
E LA
COCINA
SU
UB-ESCEN
NARIO: Implementa
ación Del Diseño Resp
ponsivo
No. T
TIPO DE
ESCRIPCIÓ
ÓN
1 UN Se
S impleme
entó las inte
erfaces del usuario de la cocina.
Se
S verifico que la inforrmación dessplegada de
e la interfazz
2 UN
del
d usuario de la cocin
na es la corrrecta.
35
5

Nombre historia: Implementación Del Diseño Responsivo (Cocina)
Descripción:
1. Plantillas de la interfaz responsiva del cocina.
• S2-H9: Probar la Interfaz en Diferentes Plataformas

El objetivo es el de probar la correcta adaptabilidad de interfaz responsiva del
usuario de la Cocina en dispositivos IOs y Android en versiones superiores de IOs
6/Android 4.4.2.
ESCENARIO: DISEÑO DE INTERFAZ GRAFICA RESPONSIVE DE LA
COCINA
SUB-ESCENARIO: Probar La Interfaz en Diferentes Plataformas
1 UN Se verifico la adaptabilidad en dispositivos Android.
2 UN Se verifico la adaptabilidad en dispositivos IOs.
36

Nombre historia: Probar la Interfaz en Diferentes Plataformas (Cocina)
Descripción:
1. Ser verifico que las interfaces del cocina son adaptables en los dispositivos
Android y IOs.
5.5 Planificación Sprint 2 “Diseño de interfaz gráfica responsive del Administrador”

La tabla 5.5, describe la tabla de planificación del Sprint 2 para el Administrador.
SPRINT 2
NOMBRE: DISEÑO DE INTERFAZ GRAFICA RESPONSIVE DEL ADMINISTRADOR
HORAS TRABAJADAS
SPRINT ID TAREAS RESP.
EST. REA.
S2-H10 Creación de Mockups J.W.U.O. 16 16
Implementación del J.W.U.O. /

S2-H11 24 24
S2 Diseño Responsivo E.A.E.B.
Probar la Interfaz en
S2-H12 E.A.E.B. 8 8
diferentes Navegadores
TOTAL HORAS 48 48
Tabla 5.5: Sprint 2(Diseño de Interfaz Gráfica Responsive del Administrador)

• El diagrama de Gantt del sprint 2 “Diseño de Interfaz Gráfica Responsive del

Administrador”, se detalla en la figura 5.6 donde se visualiza las tareas en días.
37

Figura 5.6: Diagrama de Gantt Sprint 2 (Diseño de Interfaz Gráfica Responsive del Administrador)

S2-H12.
• S2-H10: Creación de Mockups
El objetivo es el de crear maquetas para mostrar al cliente (Product Owner) un
concepto previo de las pantallas de la interfaz del Administrador para poder llegar a
un acuerdo mutuo con el mismo usando la herramienta Balsamiq Mockups, como
muestra la Imagen 5.4.
ESCENARIO:DISEÑO DE INTERFAZ GRAFICA RESPONSIVE DEL
ADMINISTRADOR
En base a los requerimientos solicitados se identificó
1 UN
las posibles interfaces requeridas para el Administrador.
Se identificaron las principales pantallas para el
2 UN
Administrador.
38

¾ S2-H10:Histo
oria de Usu
uario
H
Historia dee Usuarioo: S2-H10
ombre histtoria: Creacción de Mocckups (Adm
No ministrador)
Feecha Inicio: 24/12/201
16 Fecha Fin
n: 25/12/20016
Deescripción::
1. Mockups de
d las princiipales panta
allas del Ad
dministradorr.
39
9

Imaggen 5.4: Mockuups Administraddor

[Fuente:
40
0

• S2-H11: Implementación del Diseño Responsivo

Es la implementación de las interfaces responsive para el comensal usando las
herramientas Ionic Creator (https://creator.ionic.io) y Bootstrap
(http://getbootstrap.com/).
ADMINISTRADOR
SUB-ESCENARIO: Implementación Del Diseño Responsivo
1 UN Se implementó las interfaces del Administrador.
Se verifico que la información desplegada de la interfaz

2 UN
del Administrador es la correcta.
Nombre historia: Implementación del Diseño Responsivo (Administrador)
Descripción:
1. Plantillas de la interfaz responsiva del Administrador.
• S2-H12: Probar la Interfaz en Diferentes Navegadores

El objetivo es probar la correcta adaptabilidad de interfaz responsiva del
Administrador en diferentes Navegadores WEB (Chrome, Safari, Mozilla, IE,
Opera)en susúltimas versiones.
41

¾ S2-H12: Casos de Prueba

ADMINISTRADOR
SUB-ESCENARIO: Probar La Interfaz en Diferentes Plataformas
Se verifico la adaptabilidad en los diferentes

1 UN
navegadores.
Nombre historia: Probar la Interfaz en diferentes Plataformas (Administrador)
Descripción:
1. Ser verifico que las interfaces del Administrador se desplegaron
correctamente en los distintos navegadores.
42

5.5.2 Diagrama de Burn Down del Sprint 2 “Diseño de la interfaz gráfica del
Comensal, Cocina y Administrador”
Diagrama de Burn Down del Sprint 2
140
120
100
80
del Sprint 2
40
20
Figura 5.7: Diagrama de Burn Down Sprint 2

43


En la tabla 5.6 se detalla los problemas y las soluciones que surgieron durante el proceso
del Sprint 2

Probar la interfaz Problema con Se aplicó algunos
del usuario de la dispositivos móviles ajustes en el ancho
cocina en Android de baja y alto de los E.A.E.B.
diferentes resolución (tabletas componentes de la
plataformas chinas) interfaz
Probar la interfaz La aplicación no
Se limitó la
del comensal en funciona en
aplicación a E.A.E.B.
29/12/2016 diferentes versiones anteriores
versiones anteriores
plataformas a Android 4.2
Algunos
Probar la interfaz componentes web
Se utilizaron
del administrador se ven de diferente
elementos E.A.E.B.
en diferentes aspecto en los
genéricos
navegadores distintos
navegadores

44

CAPITULO VI
ITERACION – II
6.1 Introducción
Este capítulo contempla la implementación funcional de las aplicaciones para el comensal,
cocina y administrador.
6.2 Planificación Sprint 3 “Implementación de la carta menú Comensal”

La Tabla 6.1 describe la tabla de planificación del Sprint 3 para el comensal.
SPRINT 3
NOMBRE: IMPLEMENTACIÓN DE LA CARTA MENÚ COMENSAL
HORAS TRABAJADAS
EST. REA.
Implementar el
modulo lector de
S3-H13 QR para la J.W.U.O. 16 16
identificación de
mesas
Implementación
S3-H14 del menú principal J.W.U.O. 16 32
S3 del comensal
Implementación de
S3-H15 la lista menú del J.W.U.O./E.A.E.B. 24 32
comensal
Implementación de
S3-H16 J.W.U.O. 16 24
la lista del pedido
S3-H17 Pruebas del menú E.A.E.B. 16 24
TOTAL HORAS 88 128
Tabla 6.1: Sprint 3 (Implementación de la Carta Menú Comensal)

45

• El diagrama de Gantt del sprint 3 “Implementación de la Carta Menú Comensal” se

Figura 6.1: Diagrama de Gantt Sprint 3 (Implementación de la Carta Menú Comensal)


A continuación se describen los casos de prueba e historias de usuarios S3-H13, S3-H14,
S3-H15, S3-H16 y S3-H17.
• S3-H13: Implementar el modulo lector de QR para la identificación de mesas

En esta tarea se usara el plugin del Framework Ionic para identificar el código QR
de las respectivas mesas y el menú disponible, como se muestra en la imagen 6.1.
ESCENARIO:IMPLEMENTACIÓN DEL MENÚ COMENSAL
SUB-ESCENARIO: Implementar el modulo lector de QR para la identificación
de mesas
Se realizaron pruebas para que funciones en plataformas
1 UN
iOS y Android en sus últimas versiones.
Se verifico que el lector QR reconozca correctamente el
2 UN
código.
Mediante el código escaneado se verifica que exista la
3 UN
mesa en el servidor.
46

Nombre historia: Implementar el modulo lector de QR para la identificación de
mesas
Descripción:
1. La app es capaz de leer el código QR de la mesa de manera correcta.
Imagen 6.1: Lectura del código QR

47

• S3-H14: Implementación del menú principal del comensal

Se implementa la funcionalidad de la interfaz del menú principal del comensal,
como muestra en la Imagen 6.2.
SUB-ESCENARIO: Implementación del menú principal del comensal
Se verifico que la información desplegada del menú principal
1 UN
es la correcta.
Nombre historia: Implementación del menú principal del comensal
Descripción:
1. El menú desplegado está correctamente dividido en categorías (comida,
bebidas, postres).
48

Imagen 6.2: Menú principal del comensal

• S3-H15: Implementación de la lista menú del comensal

Se implementa la funcionalidad de la interfaz de la lista del menú comensal para las
comidas, bebidas y postres, como se muestra en la imagen 6.3.
SUB-ESCENARIO: Implementación de la lista menú del comensal
Se verifico que la información desplegada y funcionalidad de
1 UN
la lista menú de comidas sea la correcta.
2 UN
la lista menú de bebidas sea la correcta.
3 UN
la lista menú de postres sea la correcta.
49

Nombre historia: Implementación de la lista menú del comensal
Descripción:
1. La lista menú desplegada del comensal es coherente con la base de datos
2. Las listas menús desplegadas están correctamente categorizadas.
Imagen 6.3: Lista menú del comensal

50

• S3-H16: Implementación de la lista del pedido

Se implementó la lista de órdenes de pedidos del comensal, como se muestra en la
figura 6.4.
ESCENARIO: IMPLEMENTACIÓN DEL MENÚ COMENSAL
SUB-ESCENARIO: Implementación de la lista del pedido
1 UN Se verifico que la comanda sea la correcta.
Se verifico que la información enviada al servidor sea
2 UN
procesada correctamente.
Nombre historia: Implementación de la lista del pedido
Descripción:
1. La comanda fue correctamente elaborada.
2. El pedido se registró correctamente.
51

Imagen 6.4: Lista pedido del comensal

• S3-H17: Pruebas del menú.

Se realizaron las pruebas correspondientes del menú principal, lista menú y
comanda de la orden del pedido del comensal.
SUB-ESCENARIO: Pruebas del menú
Se verifico que los pedidos sean coherentes con la
1 UN
disponibilidad del menú.
Se creó un escenario de concurrencia para verificar la
2 UN
disponibilidad del pedido.
52

Nombre historia: Pruebas del menú
Descripción:
1. Correcta funcionalidad del proceso de toma de orden y pedido que realiza el
comensal.
6.3 Planificación Sprint 3 “Implementación de la lista de pedidos para la cocina”

La Tabla 6.2 describe la tabla de planificación del Sprint 3 para la cocina.
SPRINT 3
NOMBRE: IMPLEMENTACIÓN DE LA LISTA DE PEDIDOS PARA LA COCINA
HORAS TRABAJADAS
EST. REA.
Implementación
de la lista de
S3-H18 órdenes de las E.A.E.B. 48 56
comandas de la
S3 cocina
Pruebas de la
S3-H19 lista de pedidos E.A.E.B. 16 8
para la cocina
TOTAL HORAS 64 64
Tabla 6.2: Sprint 3 (Implementación de la Lista de Pedidos para la Cocina)

53

• El diagrama de Gantt del sprint 3 “Implementación de la lista de pedidos para la

cocina”, se detalla en la figura 6.2 donde se visualiza las tareas en días.
Figura 6.2: Diagrama de Gantt Sprint 3 (Implementación de la Lista de Pedidos para la Cocina)

A continuación se describen los casos de prueba e historias de usuarios S3-H18 y S3-H19.
• S3-H18: Implementación de la lista de órdenes de las comandas de la cocina

Se implementa la funcionalidad de la interfaz de la lista de órdenes de las comandas
de la cocina, como se muestra en la imagen 6.5.
ESCENARIO:IMPLEMENTACIÓN DE LA LISTA DE PEDIDOS PARA LA
COCINA
SUB-ESCENARIO: Implementación de la lista menú del comensal
1 UN
la lista de órdenes de la comanda de comidas sea la correcta.
2 UN
la lista de órdenes de la comanda de bebidas sea la correcta.
3 UN
la lista de órdenes de la comanda de postres sea la correcta.
54

Nombre historia: Implementación de la lista de órdenes de las comandas de
la cocina
Descripción:
1. La lista de órdenes de las comandas de la cocina son coherentes con la
información del pedido del comensal.
Imagen 6.5: Lista de órdenes de la cocina

55

• S3-H19: Pruebas de la lista de pedidos para la cocina

Se realizaron las pruebas correspondientes de la lista de órdenes de comandas de la
cocina.
ESCENARIO:IMPLEMENTACIÓN DE LA LISTA DE PEDIDOS PARA LA
COCINA
SUB-ESCENARIO: Pruebas de la lista de pedidos para la cocina
Se verifico que los pedidos solicitados sean coherentes con la
1 UN
disponibilidad de la lista de la cocina.
Nombre historia: Pruebas de la lista de pedidos para la cocina
Descripción:
1. La información desplegada de la lista de pedidos para la cocina es correcta.
56

6.4 Planificación Sprint 3 “Implementación de la gestión de Administrador”

La Tabla 6.3 describe la tabla de planificación del Sprint 3 para el Administrador.
SPRINT 3
NOMBRE: IMPLEMENTACIÓN DE LA GESTIÓN DE ADMINISTRADOR
FECHA FIN: 04/02/2017 DURACION ESTIMADA: 88 horas
HORAS
SPRINT ID TAREAS RESP. TRABAJADAS
EST. REA.
Implementación de la
S3-H20 gestión de Categorías A.D.O.A. 16 24
de los ítems del menú
S3-H21 A.D.O.A. 16 24
gestión del menú
gestión de control de
S3-H22 A.D.O.A. 24 24
existencias del menú
diario
S3
S3-H23 gestión de mesas y A.D.O.A. 16 24
códigos QR
Pruebas de la
funcionalidad de
S3-H24 A.D.O.A. 8 8
implementación del
Administrador
TOTAL HORAS 88 104
Tabla 6.3: Sprint 3 (Implementación de la Gestión de Administrador)

• El diagrama de Gantt del sprint 3 “Implementación de la gestión de Administrador”,

se detalla en la figura 6.3 donde se visualiza las tareas en días.

Figura 6.3: Diagrama de Gantt Sprint 3 (Implementación de la Gestión de Administrador)
57


A continuación se describen los casos de prueba e historias de usuarios S3-H20, S3-H21,
S3-H22, S3-H23 y S3-H24.
• S3-H20: Implementación de la gestión de Categorías de los ítems del menú

Se implementa la funcionalidad de la interfaz de las categorías de los ítems del
menú, como se muestra en las imágenes 6.6 y 6.7.
ESCENARIO:IMPLEMENTACIÓN DE LA GESTIÓN DE ADMINISTRADOR
SUB-ESCENARIO: Implementación de la gestión de Categorías de los ítems
del menú
Se verifico que las categorías del menú se desplieguen y
1 UN
cumplan con su respectiva funcionalidad.
Nombre historia: Implementación de la gestión de Categorías de los ítems del
menú
Descripción:
1. La información de las categorías del menú sean las correctas.
58

Imagen 6.6: Creación de Categorías

Imagen 6.7: Lista de Categorías

59

• S3-H21: Implementación de la gestión del menú

Se implementa la funcionalidad para la creación del menú del día, como se
muestran en las imágenes 6.8, 6.9, 6.10, 6.11, 6.12 y 6.13.
SUB-ESCENARIO: Implementación de la gestión del menú
Se verifico que el menú sea desplegado con la información
1 UN
correcta.
Nombre historia: Implementación de la gestión del menú.
Descripción:
1. La información del menú desplegado es la correcta.
2. Las categorías del menú están correctamente clasificadas
60

Imagen 6.8: Menú Configuración

Imagen 6.9: Creación de la Nueva Planificación del Menú

61

Imagen 6.10: Menú General

Imagen 6.11: Lista de Menús por Categorías

62

Imagen 6.12: Creación de Categorías

Imagen 6.13: Añadir nuevo ítem al Menú

• S3-H22: Implementación de la gestión de control de existencias del menú diario

Se implementa la funcionalidad del control de existencias del menú diario.
63

SUB-ESCENARIO: Implementación de la gestión de control de existencias del
menú diario
Se verifico que el control de existencias del menú diario sea
1 UN
la correcta.
Nombre historia: Implementación de la gestión de control de existencias del
menú diario
Descripción:
1. La información del control del existencial del menú diario sea la correcta.
• S3-H23: Implementación de la gestión de mesas y códigos QR

Se implementa la funcionalidad de la gestión de mesas y código QR.
SUB-ESCENARIO: Implementación de la gestión de mesas y códigos QR
Se verifico que los códigos QR generados son aleatorios e
1 UN
únicos.
Que el código QR generado corresponde a un código único
2 UN
de mesa.
64

Nombre historia: Implementación de la gestión de mesas y códigos QR
Descripción:
1. Los códigos generados son únicos, aleatorios y concuerda con el
identificador de la mesa.
• S3-H24: Pruebas de la funcionalidad de implementación del Administrador

Se realizaron las pruebas correspondientes de la implementación realizada para el
Administrador.
SUB-ESCENARIO: Pruebas de la funcionalidad de implementación del
Administrador
Se verifico que todas las funcionalidades del módulo del
1 UN
Administrador estén correctamente desarrolladas.
Nombre historia: Pruebas de la funcionalidad de implementación del
Administrador
Descripción:
1. El Modulo del Administrador funciona correctamente.
65

6.4.2 Diagrama de Burn Down del Sprint 3 “Implementación de la gestión del

Comensal, Cocina y Administrador”

350
300
250
200
Diagrama de Burn Down
150 del Sprint 3
100
50
0
30 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 2 4

66


del Sprint 3

Implementación Se convirtieron
Problemas al subir
de la gestión de las imágenes a
archivos mediante A.D.O.A.
Categorías de los un formato de
Sockets
ítems del menú base64
Problemas al tratar Ordenar
04/02/2017 de realizar manualmente
Implementación consultas complejas los resultados
del menú principal a la base de datos que devuelve la J.W.U.O.
del comensal (Seleccionar y base de datos
ordenar en la Node.Js o
misma consulta) Angular.

67

CAPITULO VII
ITERACION – III
7.1 Introducción
Este capítulo contempla la autentificación del cocinero, administrador y administrador de
software.
7.2 Planificación Sprint 4 “Autentificación del cocinero y administrador”

SPRINT 4
NOMBRE: AUTENTIFICACION DEL COCINERO Y ADMINISTRADOR
HORAS TRABAJADAS
ESTIMADO REALIZADO
Inclusión del
middleware
S4-H26 Passport.js para E.A.E.B. 2 1
el manejo de
sesiones
Inclusión de la
estrategia de
S4-H27 autentificación E.A.E.B. 1 1
usuario y
S4 password
Creación de los
formularios de
autentificación y
S4-H28 E.A.E.B. 2 1
verificación de
la llegada de los
parámetros
TOTAL HORAS 5 3
Tabla 7.1: Sprint 4 (Autentificación del Cocinero y Administrador)

68

• El diagrama de Gantt del sprint 4 “Autentificación del Cocinero y Administrador” se


Figura 7.1: Diagrama de Gantt Sprint 4 (Autentificación del Cocinero y Administrador)

S4-H28
.
• S4-H26: Inclusión del middleware Passport.js para el manejo de sesiones
El objetivo de esta tarea es el de dar soporte de sesiones a Node.js ya que no cuenta
con un manejador de sesiones.
ESCENARIO: AUTENTIFICACION DEL COCINERO Y ADMINISTRADOR
SUB-ESCENARIO: Inclusión del middleware Passport.js para el manejo de
sesiones
Se incluye la librería Passport.js a Node.js para el

1 UN
manejo de sesiones.
Se realiza una verificación de funcionalidad de la

2 UN
librería.
69

Nombre historia: Inclusión del middleware Passport.js para el manejo de
sesiones
Descripción:
1. Se incluyó la librería Passport.js con funcionalidad correcta.
• S4-H27: Inclusión de la estrategia de autentificación usuario y password

El objetivo de esta tarea es el de dar soporte de autentificación a la aplicación.
SUB-ESCENARIO: Inclusión de la estrategia de autentificación usuario y
password
1 UN La aplicación se autentifico en el usuario del cocinero.
La aplicación se autentifico en el usuario del

2 UN
administrador.
Nombre historia: Inclusión de la estrategia de autentificación usuario y
password
Descripción:
1. Se concluyó con la autentificación tanto para el cocinero como para el
administrador de manera correcta.
70

Imagen 7.1: Inicio de Sesión

• S4-H28: Creación de los formularios de autentificación y verificación de la

llegada de los parámetros
El objetivo de esta tarea es el de realizar pruebas de autentificación verificando la
información con la base de datos.
SUB-ESCENARIO: Creación de los formularios de autentificación y verificación
de la llegada de los parámetros
Se realizaron las pruebas correspondientes de

1 UN
autentificación para el usuario del cocinero.
Se realizaron las pruebas correspondientes de

2 UN
autentificación para el usuario del administrador.
71

Nombre historia: Creación de los formularios de autentificación y verificación
de la llegada de los parámetros
Descripción:
1. Se concluyó con las pruebas de autentificación de manera correcta para los
usuarios del cocinero y administrador.
7.2.2 Diagrama de Burn Down del Sprint 4 “Autentificación del Cocinero y

Administrador”
30
25
20
del Sprint 4
10
0
05‐feb 06‐feb 07‐feb 08‐feb

72


del Sprint 4

Inclusión del
middleware Problemas de Se solucionó
07/02/2017 Passport.js configuración e revisando E.A.E.B.
para el manejo instalación documentación.
de sesiones

7.3 Planificación Sprint 5 “Distribución de Software”

SPRINT 5
NOMBRE: DISTRIBUCION DE SOFTWARE
HORAS TRABAJADAS
ESTIMADO REALIZADO
Implementación
S5-H29 de reporte de A.D.O.A. 2 2
ventas
Generar las
aplicaciones
S5-H30 A.D.O.A. 2 1
S5 para iOS,
Android y web
Crear manual
S5-H31 A.D.O.A. 1 2
de usuario
Crear manual
S5-H32 A.D.O.A. 2 2
técnico
TOTAL HORAS 7 7
Tabla 7.3: Sprint 5 (Distribución de Software)

73

• El diagrama de Gantt del sprint 5 “Distribución de Software” se detalla en la figura

7.3 donde se visualiza las tareas en días.

Figura 7.3: Diagrama de Gantt Sprint 5 (Distribución de Software)

• S5-H29: Implementación de reporte de ventas
El objetivo de esta tarea es implementar el módulo de reporte de ventas diarias,
dicho reporte es solo de carácter informativo el cual no toma en cuenta la
contabilidad de ventas.
ESCENARIO: REPORTE DE VENTAS Y DISTRIBUCIÓN DE SOFTWARE
SUB-ESCENARIO: Implementación de reporte de ventas
1 UN Generar reportes de los ítems vendido del restaurant.
Nombre historia: Implementación de reporte de ventas
Descripción:
1. Se tiene reportes de ventas diarias.
74

• S5-H30: Generar las aplicaciones para iOS, Android y web

El objetivo de esta tarea es el de generar las apps para las diferentes plataformas.
SUB-ESCENARIO: Generar las aplicaciones para iOS, Android y WEB
1 UN Generar aplicación para iOS.
2 UN Generar aplicación para Android.
3 UN Generar aplicación para WEB.
Nombre historia: Generar las aplicaciones para iOS, Android y WEB
Descripción:
1. Se generó las apps para las diferentes plataformas.
• S5-H31: Crear manual de usuario

El objetivo de esta tarea es el de crear el manual correspondiente del usuario final.
SUB-ESCENARIO: Crear manual de usuario
Se realizó el manual de usuario para los diferentes

1 UN
usuarios del sistema.
75

Nombre historia: Crear manual de usuario
Descripción:
1. Se concluyó el manual de usuario para el manejo del sistema.
• S5-H32: Crear manual técnico

El objetivo de esta tarea es el de crear el manual técnico para el usuario encargado
de la instalación de la aplicación y sistema.
SUB-ESCENARIO: Crear manual técnico
Se realizó el manual técnico para el usuario encargado

1 UN
de la instalación de la aplicación y sistema.
Nombre historia: Crear manual técnico
Descripción:
1. Se concluyó el manual técnico.
76

7.3.2 Diagrama de Burn Down del Sprint 5 “Distribución de Software”

Diagrama Burn Down del Sprint 5
60
50
40
30
Diagrama Burn Down del
20 Sprint 5
10


del Sprint 5.

Problemas de Se utilizó el IDE
Generar las compatibilidad en el Android estudio
aplicaciones sistema operativo para poder
12/02/2017 A.D.O.A.
para iOS, Windows al compilar compilar y crear los
Android y web el paquete para paquetes para
Android Android

77

CAPITULO VIII
CONCLUSIONES Y RECOMENDACIONES
8.1 Conclusiones
• El éxito de un proyecto informático depende de muchos factores tales como el
equipo de trabajo y el tiempo.
• Un proyecto informático exitoso conlleva siempre un desarrollo bien elaborado
del mismo acompañado de una buena idea, además de factores técnicos. Este
proyecto ha tratado de unir estos dos elementos, para poner la tecnología actual
al servicio de los negocios dedicados al rubro de la venta y expendio de
alimentos de una manera innovadora ágil y divertida.
• En la actualidad, la gestión de las comandas de los clientes, la transmisión de las
órdenes a la cocina, la proposición de sugerencias, la inserción de publicidad y la
gestión de los diversos módulos del negocio, se lleva realizando de la misma
manera desde hace muchos años.
• Este proyecto propone dar una alternativa para la implantación de tecnología en
este sector, combinando ideas innovadoras y conocimiento tecnológico, con el
fin de reducir tiempos innecesarios y mejorar la calidad de atención a los clientes
(comensales)
• Las herramientas usadas en este proyecto son herramientas relativamente nuevas,
las cuales van ganando terreno y mejorando continuamente, brindando a los
desarrolladores un sin fin de opciones.
• Las herramientas hibridas de desarrollo en definitiva son una excelente opción
que permite el ahorro de tiempo durante el desarrollo y cubrir una buena cantidad
del mercado actual.
• Se cree que las aplicaciones móviles son el futuro debido a su crecimiento
exponencial en el mercado y las cuales brindan una experiencia agradable.
78

8.2 Recomendaciones
En esta sección se describen las posibles mejoras que se podrían hacer al sistema para
poder otorgarle una mayor y mejor funcionalidad, las mismas que se describen a
continuación:
• Implementar el módulo de almacenes para poder tener un mejor control de las
existencias.
• Implementar o integrar un módulo de contabilidad y facturación.
• Implementar un módulo de redes sociales con el fin de poder brindar al usuario la
posibilidad de compartir sus experiencias a través de las mismas (Twitter,
Facebook, etc.).
79

REFERENCIAS BIBLIOGRÁFICAS
Páginas Web
Julián Pérez Porto y María Merino. (Publicado: 2014. Actualizado: 2016)

Definición de restaurante (http://definicion.de/restaurante)
Gorka Díaz de Orbe (Publicado: 2010)

Sistema Integral para la Gestión de Restaurantes
(https://www.iit.comillas.edu/pfc/resumen)
CampusMVP (Publicado: 2014)

Programación móvil: Qué herramienta y lenguaje elegir
(http://www.campusmvp.es/recursos/post/Programacion-movil-Que-herramienta-y-
lenguaje-elegir.aspx\)
Paradigmas de programación (Publicado: 2017)

(https://www.ecured.cu/Paradigmas_de_programaci%C3%B3n)
Fundamentos de la programación reactiva (Publicado: 2016)
(http://hat.hexacta.com/fundamentos-de-la-programacion-reactiva/)
Jonas Bonér, Dave Farley, Roland Kuhn y Martin Thompson (Publicado: 2014 v2.0)
The Reactive Manifesto (http://www.reactivemanifesto.org/)
Tejerina Martín (Publicado: 2008)

Programación Orientada a Objetos (OOP, ObjectOrientedProgramming)
(http://www.monografias.com/trabajos14/progorie/progorie.shtml)
Definición de Socket (Publicado: 2017)

(http://www.masadelante.com/faqs/socket)
80

RethinkDB pushes JSON to your apps in realtime (Publicado: 2016)

(https://www.rethinkdb.com/)
Node.js (Publicado: 2016)

(https://nodejs.org/es/)
Ana Mocholí (Publicado: 2015)

Programar apps multiplataforma con HTML5
(https://www.yeeply.com/blog/programar-apps-multiplataforma-html5/)
Apache Cordova (Publicado: 2016)

(https://cordova.apache.org/docs/es/latest/guide/cli/)
Priolo Sebastián (Edición: 2009)

Métodos Agiles
81

ANEXOS
82

INDICE DE ANEXOS
ANEXO A
MANUAL DE INSTALACION
(Servidor/Base de Datos)
A.1. Introducción ......................................................................................................... 1
A.2. Instalación de NodeJS .......................................................................................... 1
A.3. Instalación de IONIC Framework ........................................................................ 2
A.4. Instalación de Cordova ......................................................................................... 3
A.5. Instalación y configuración RethinkDB ............................................................... 4
A.6. Ejecución del Servidor.......................................................................................... 6
ANEXO B
MANUAL DE USUARIOS
(Administrador/Comensal/Cocina)
B.1. Introducción ......................................................................................................... 9

B.2. Modulo Administrador ........................................................................................ 9
B.3. Modulo Cliente .................................................................................................... 15
B.4. Modulo Cocina .................................................................................................... 17
I

ANEXO A
MANUAL DE INSTALACION
(Servidor/Base de Datos)
A.1. Introducción
El presente documento describirá las herramientas necesarias y su forma de instalación para
poder ejecutar correctamente el modulo del servidor y la base de datos del presente
proyecto.
¾ Soporte de plataformas
• Windows 7 y superiores.
• MAC OS
• Linux/Unix
¾ Pre-requisitos
• Java JDK en su última Versión instalada.
• ( http://www.oracle.com/technetwork/java/javase/downloads/.html)
• Git instalado (https://git‐scm.com/downloads)
• Android SDK (https://developer.android.com/studio/index.html)
• Conexión a Internet
¾ Requisitos de Software
A continuación listaremos la lista de herramientas requeridas por el sistema.
• Nodejs
• Ionic Framework
• Cordova
• RethinkDB
A.2. Instalación de NodeJS.

1. Ir a https://nodejs.org/en/ y descargar el instalador para la plataforma de su
preferencia.
2. Una vez descargado el instalador proceder a la instalación del mismo.
3. Una vez finalizada la instalación, proceda a abrir una terminal en su entorno,
escriba la palabra “node” el cual le bebería dar la siguiente salida.
1

4. Escriba la palabra “npm” la cual le debería dar la siguiente salida en la consola
5. Si obtiene ambas salidas la instalación fue exitosa.

A.3. Instalación de IONIC Framework
1. Abrir la consola en el sistema operativo (GitBash) y ejecutar el siguiente
comando:
• Windows
npminstall ‐g ionic
• Linux/Unix
sudonpminstall ‐g ionic
• Mac Os
sudonpminstall ‐g Ionic

2

2. Una vez ejecutado el comando se procederá a la instalación del Framework Ionic,

esto tomara tiempo dependiendo de la velocidad de conexión con la que cuenta,
una vez finalizada la instalación escriba ionic en la consola y debería tener algo
como lo siguiente en la salida:
A.4. Instalación de Cordova

1. Abrir la consola en el sistema operativo (GitBash) y ejecutar el siguiente
comando:
• Windows
npminstall –g cordova
• Linux/Unix
sudonpminstall ‐g cordova
• Mac Os
sudonpminstall ‐g cordova
3

2. Una vez ejecutado el comando se procederá a la instalación Apache Cordova,

esto tomara tiempo dependiendo de la velocidad de conexión con la que cuenta,
una vez finalizada la instalación escriba cordova en la consola y debería tener
algo como lo siguiente en la salida:
A.5. Instalación y configuración RethinkDB

1. Descargar el archivo comprimido (.zip) que contiene RethinkDB de la siguiente
dirección dependiendo de su OS https://www.rethinkdb.com/docs/install/.
2. Una vez descargado el archivo, lo descomprimimos en algún lugar.
4

Configuración:
1. Abrimos una consola y nos movemos hasta el path donde se descomprimió el
archivo.
2. Ejecutamos el siguiente comando rethinkdb.exe, esto levantara el servicio de
rethinkdb, la consola debería lucir de la siguiente manera.
3. Abra algún navegador web y acceda a la siguiente dirección

http://localhost:8080/ para poder acceder al administrador de la base de datos.
5

4. Una vez el servicio de RethinkDB este corriendo procedemos a la creación de las

tablas requeridas por el sistema, para lo cual copiamos el archivo
[basedatos.json] del cd a la pc, abrimos otra consola y navegamos hasta el PATH
donde descomprimimos rethinkDB y ejecutamos el siguiente comando
“rethinkdbimport<dirección del archivo basedatos.json>”, este comando creara
las tablas necesarias para el funcionamiento del sistema.
A.6. Ejecución del Servidor

En esta sección describiremos como levantar el server encargado de la
comunicación entre la Base de Datos y los clientes IOs y Android para el Cliente
(comensal), Administrador y el usuario de la Cocina.
1. Descargar el código del cliente (.zip) de la siguiente dirección
https://www.dropbox.com/s/8ephzhd4qoshobv/codigoFuente.zip?dl=0.
2. Descomprimir el archivo previamente descargado.
3. Abrir una consola (GitBash) y navegar hasta el PATH donde se descomprimió el
archivo en el paso anterior.
6

4. Ejecutar el comando “npminstall” el cual instalara las Lib requeridas por el

proyecto.
5. Una vez instalada las dependencias ahora procedemos a levantar el servidor para
el cual utilizamos el siguiente comando “npmrun back” el cual levanta el
servidor para el sistema Mesero Virtual.
7

Nota: Para el correcto funcionamiento del sistema la instancia de RethinkDB server debería
estar corriendo. Los clientes tanto IOS y Android están en el CD listos para poder ser
instalados.
8

ANEXO B
MAN
NUAL DE USUARIO
O
(Cliente/Administrad
dor/Cocina))
B.1. Introdu
ucción
Ell presente ddocumento describirá la funcionaalidad básicca del Sisteema el cual cuenta con
n
trees Aplicacciones Móv
viles destin
nadas a diiferentes tipos de ussuario los cuales son
n
A
Administrado
or, Cliente y Cocina.
B.2. Modullo Administtrador

Paara ingresarr al sistemaa primero debemos seleccionar la aplicación de nuestro
o dispositivo
o
m
móvil, posterriormente se debe in
niciar sesió
ón, el usuarrio y contraaseña por defecto son
n
‘A
Administraddor’ y ‘1234
41234’
Esste módulo nos permiite planificaar y adminiistrar el meenú, categorías del meenú, ver loss
cllientes conectados, los pedidos quee realizan y contar con posterioress reportes.
Laa principal función dell módulo ad

dministradoor es aperturrar el menúú (iniciar veenta) ya quee
m
mientras el menú
m está cerrado
c los otros dos módulos dee Cocina y Cliente peermanecerán
n
nte se tiene un menú general defin
deesactivados. Para iniciaar la venta primeramen
p nido, ya quee
a partir de eese menú se
s puede teener uno más
m específiico para unn día planifficado, paraa
reealizar esta tarea
t primerro definirem
mos el menú
ú general.
9

See tiene que dirigir a laa sección dee Configuraación => Caategorías =>
> Añadir Categoría, en
n
essta sección debemos
d deefinir todas las categoríías de las qu
ue dispondrá nuestro menú.
m
nir el menú general, parra realizar esta

U vez definidas las caategorías see debe defin
Una e tarea see
tieene que diriigir a la seccción de Co
onfiguración
n => Menú General, enn esta secció
ón se puedee
ob
bservar las categorías anteriormen
nte definidaas, posterio
ormente se pprocederá añadir
a todoss
lo
os platos y bbebidas al menú.
m Para que el sisteema nos peermita guarddar se deben
n completarr
to
odos los cam
mpos requerridos.
10
0

U vez guarrdaras todass las opcion

Una nes del menú
ú ya se disp
pone de un m
menú generral completo
o
co
omo se mueestra a continuación.
Paara definir el menú del

d día se tiene que dirigir a la
l sección de Config
guración =>
>
Pllanificaciónn del Menú => Añadir Planificació
ón => Nuev
va Planificaación, como
o se muestraa
a continuació
ón.
11
1

Una vez en la sección “N

U Nueva Plannificación” se tiene quee seleccionaar el día parra el cual see
vaa a planificaar el menú del
d día, postteriormente hacer click
k en guardarr.
Una vez guaardada la pllanificación

U n se tiene un
u menú en n la secciónn de esperaa con el díaa
seeleccionado anteriorm
mente. Se puede
p tenerr la cantid
dad de plannificacioness que sean n
neecesarias.
Antes de haccer click en “Iniciar Veenta” se debbe verificar las existenncias que se dispondrán
A n
paara el menú del día Plan
nificado, haaciendo clicck en “Existtencias”.
Essta sección de Existenccias no es más

m que unaa copia del Menú
M Geneeral en el cu
ual se puedee
m
modificar loss precios, un
nidades disp
ponibles de cada plato y activar o desactivar la
l opción dee
un
n plato en específico. EnE resumen se puede haacer todo tip
po de modifficaciones.
12
2

Cabe aclarar que dichass modificacciones tamb

bién se las puede
p realizzar una vezz iniciada laa
veenta, las missmas se actu
ualizarán au mente y al instante en laa aplicación del Cliente.
utomáticam
U vez definido el men
Una nú se hace click
c en “In
niciar Ventaa” para que los comenssales puedan
n
em
mpezar a reaalizar sus peedidos med
diante el modulo Clientte.
U vez term
Una minadas las ventas se hace
h click een “Cerrar Menú”,
M donnde el clien
nte no podráá
reealizar más pedidos.
p
13
3

Al cerrar el m
A menú se ob
bserva que el
e mismo yaa no se encontrara dispponible “Menú cerrado
o
po
or favor esppere”.
En n la secciónn de Reportees se puede visualizar llos menús pasados

p y taambién se pu
uede ver loss
reeportes de ventas.
v Por otro
o lado taambién se puede reutiliizar un mennú específicco ya creado o
haaciendo clicck en “Clonar Menú”.
Laas secciones de Menú, Pedidos y Clientes

C sonn de monitooreo donde se s puede obbservar a loss
cllientes conectados, los pedidos quee estos están
n realizando
o, y las exisstencias del Menú.
En
n la seccióón de clienttes se visuaaliza a todo
os los clienntes conecttados que ya
y tienen laa
ap
plicación instalada en su
s dispositiv
vo y conectaada a la red.
14
4

B.3. Modullo Cliente

Paara ingresarr al módulo
o Cliente see debe selecccionar la aplicación
a “Mesero Virrtual” desdee
un osteriormentte se procedde a escanear el códigoo QR de un
n dispositivo móvil, po na mesa si el
diispositivo lo
o permite, caso contrariio se procedde a ingresaar el código manualmen
nte.
U vez que se ingresa al sistema se tiene el menú dispo

Una onible del ddía, el comensal puedee
ellegir entre to
odas las varriedades de promocionees, platos y bebidas, doonde el com
mensal podráá
peedir la cantiidad que req
quiera y haccer su pedid
do.
15
5

A continuaciión se hacee click en “Procesar

“ m
mi Pedido”.. Una vez realizado
r ell pedido, el
coomensal pueede visualizzar todo su pedido
p con el costo total, cantidadd de platos, bebidas
b y el
tieempo aproxximado de entrega.
e
En
n la secciónn Buzón el comensal
c pu
uede dejar comentarios
c s o sugerenccias.
16
6

B.4. Modullo Cocina

Paara ingresarr al módulo
o Cocina se debe selecccionar la ap
plicación “M
Modulo Co
ocina” desdee
un
n dispositivoo móvil, priimeramentee se debe iniiciar sesión.
Ell usuario y contraseña

c p defecto son “Cocin
por na” y “1234
41234”.
Enn esta sección se visuualizan todo

os los pedid dos por los comensales, estos son
dos realizad n
acctualizados automáticaamente y doonde el disppositivo em
mite un soniido de alerrta cada vezz
quue un comennsal realiza un pedido.
d encargado de la co
Laa función del ocina es haacer click enn “Iniciar” para que el
e pedido see
prrepare, con esta acciónn le llega una
u notificacción al clieente con el tiempo aproximado dee
prreparación o entrega dee su pedido..
17
7

Una vez entregado el pedido el encargado de la cocina debe hacer click en “Terminado”,
trasladándose el mismo pedido a la sección de “Reportes”, en esta sección se tiene un
pequeño reporte de los pedidos ya terminados.
18

22doc 20 02 17

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

22doc 20 02 17

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD MAYOR DE SAN SIMÓN

FACULTAD DE CIENCIAS Y TECNOLOGÍA

APLICACIÓN MOVIL PARA LA GESTION DEL

LIC. CARMEN ROSA GARCIA PEREZ

A la Lic. Carmen Rosa Garcia Perez por

A los Docentes por sus consejos y enseñanzas,

A la Universidad por abrirnos las puertas y

1.1. Antecedentes ........................................................................................................... 1

2.1. Introducción .......................................................................................................... 4

3.1. Programación Móvil ........................................................................................... 9

3.3.1. Manifiesto de la Programación Reactiva ........................................................... 11

PLANIFICACION DEL PROYECTO

4.1. Metodología a Aplicar ....................................................................................... 20

5.1. Introducción ........................................................................................................... 22

6.1. Introducción .......................................................................................................... 45

7.1. Introducción ........................................................................................................... 68

7.3.3. Retrospectiva del Sprint 5 ................................................................................. 77

8.1. Conclusiones .......................................................................................................... 78

FIGURA 2.1: Organigrama del Restaurante ...................................................................... 4

TABLA 5.1: Sprint 1 (Análisis, Diseño y Creación de la Base de Datos) ........................ 22

IMAGEN 5.1: Creación de la Base de Datos .................................................................... 27

GRADO: LICENCIATURA EN INGENIERÍA DE SISTEMAS

AUTORES: ERICK ALEJANDRO ERGUETA BASCOPE

Las herramientas que se emplearon para el desarrollo son: Node.js, RethinkDB,

Palabras claves: Programación Reactiva, Framework Ionic, Node.js, RethinkDB, Hibrido y

1.2. Definición del Problema.

1.3. Objetivo general

1.4. Objetivos Específicos

Chef Mesero Encargado Proveedores Sueldo

Ayudante de Meseros Seguridad Limpieza

Figura 2.1: Organigrama del Restaurante

El organigrama descrito representa los diferentes perfiles que componen la estructura

un restaurante ya que la implantación del sistema, tendrá́ un impacto positivo en el

A continuación se describen los participantes de dicha estructura:(Diaz, 2010)

• Chef: es el responsable del control de mercaderías y faltantes, la realización y

• Ayudantes de cocina: son colaboradores en la realización de los menús, mantienen

2.3. Proceso de atención

Figura 2.2: Diagrama del Proceso de Atención

A continucacion se detalla el procesos de atencion de un restaurate tal como se muestra en

• Bienvenida: La principal función del mesero encargado del salón es dar la

3.1.1. Desarrollo Nativo

La más conocida es Xamarin. Está basada en el lenguaje C# de Microsoft y en la

3.1.3. Desarrollo multiplataforma basado en HTML5

3.2. Paradigmas de Programación

3.3. Programación Reactiva

3..3.1. Maniifiesto de laa programaación reactiiva

Figura 3.2: Diagrama de Modelo Orientado a Eventos

3.8. Framework Ionic

3.8.1. Estructura del Framework Ionic

Motor de Compass Red

(Android, iOS, etc) InPut Graphics

Figura 3.3: Arquitectura para el Diseño de Aplicaciones Moviles

ionnic plugin add

Donde {plugin} es el ideentificador del

Figurra 3.5: Marco dee Trabajo SCRU

4.2 Herramientas para Desarrollar la Metodología Scrum

4.3 Producto Backlog

ID PRODUCT ESTIMACION DIAS

5.2 Planificación Sprint 1 “Análisis, Diseño y Creación de la Base de Datos”

Diseño del Modelo

Tabla 5.1: Sprint 1 (Análisis, Diseño y Creación de la Base de Datos)

• El diagrama de Gantt del sprint 1 “Análisis, Diseño y Creación de la Base de Datos” se

5.2.1 Historias de Usuario