Sistema web para la gestión del restaurante de la empresa Conclisan Cia. Ltda. by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas SISTEMA WEB PARA LA GESTIÓN DEL RESTAURANTE DE LA EMPRESA CONCLISAN CIA. LTDA. EN LA PROVINCIA DE SANTO DOMINGO DE LOS TSÁCHILAS EN EL PERÍODO 2017-2018.

Trabajo de Titulación previa a la obtención del título de Ingeniero/a de Sistemas y Computación

Línea de Investigación: Estudio, diseño e implementación de software Autores: FERNANDA YADIRA ALMACHE LOOR JIMMY ISRAEL QUIGUANGO GAONA Director: Mg. RODOLFO SIRILO CÓRDOVA GÁLVEZ

Santo Domingo – Ecuador Enero, 2018

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas HOJA DE APROBACIÓN

SISTEMA WEB PARA LA GESTIÓN DEL RESTAURANTE DE LA EMPRESA CONCLISAN CIA. LTDA. EN LA PROVINCIA DE SANTO DOMINGO DE LOS TSÁCHILAS EN EL PERIODO 2017-2018. Línea de Investigación: Estudio, Diseño e Implementación de Software Autores: FERNANDA YADIRA ALMACHE LOOR JIMMY ISRAEL QUIGUANGO GAONA Rodolfo Sirilo Córdova Gálvez, Mg.

DIRECTOR DEL TRABAJO DE TITULACIÓN Willian Javier Ocampo Pazos, Mg.

CALIFICADOR Fausto Ernesto Orozco Iguasnia, Mg.

CALIFICADOR

Luis Javier Ulloa Meneses, Mg.

DIRECTOR DE LA ESCUELA DE SISTEMAS Santo Domingo – Ecuador Enero, 2018

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Fernanda Yadira Almache Loor portadora de la cédula de ciudadanía No. 171657452- 8 declaro que los resultados obtenidos en la investigación que presento como informe final, previo la obtención del Grado de Ingeniera en Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Fernanda Yadira Almache Loor CI. 171657452- 8

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Jimmy Israel Quiguango Gaona portador de la cédula de ciudadanía No. 172180295-5 declaro que los resultados obtenidos en la investigación que presento como informe final, previo la obtención del Grado de Ingeniero en Sistemas y Computación son absolutamente originales, auténticos y personales.

Jimmy Israel Quiguango Gaona CI. 172180295-5

AGRADECIMIENTO

En primer lugar, a Dios por permitirnos tener salud, sabiduría e inteligencia, siendo nuestra fortaleza en los momentos difíciles a lo largo de la carrera, para llevar a cabo una meta más que se ve reflejada en la culminación de nuestro Trabajo de Titulación. A los docentes por la enseñanza, aprendizaje, experiencia y conocimientos que nos fueron brindados en todo el proceso como estudiante, quisiéramos agradecer especialmente a nuestro director del Trabajo de Titulación, el Mg. Rodolfo Córdova, por su dedicación y seguimiento. Sintiéndonos privilegiados por su apoyo incondicional en toda esta etapa. Finalmente, agradecer de manera especial a nuestros padres, familiares y seres queridos, por brindarnos su apoyo en todo momento, por enseñarnos los valores inculcados en el transcurso de nuestras vidas y por ser las fuentes de motivación en los momentos difíciles y retos planteados.

Fernanda & Jimmy

DEDICATORIA

A nuestras familias, pero en especial a nuestras madres y hermanos por darnos todo su amor, apoyo, comprensiรณn y ser nuestra fortaleza en aquellos momentos complicados.

Fernanda & Jimmy

vii

RESUMEN El presente Trabajo de Titulación permitió automatizar los diferentes procesos de gestión de manera eficiente para el restaurante de la empresa de CONCLISAN CIA. LTDA. RESAN (Santiago’s Restaurant) ha sido desarrollado para liberar de la sobrecarga de trabajo a la administradora, con la finalidad de optimizar el tiempo empleado en cada actividad, disminuir recursos materiales y mejorar el control de las operaciones que se realizaban. El sistema informático cuenta con ocho módulos que se detallan a continuación: módulo de clientes, permite gestionar los clientes que harán uso del sistema; módulo de dispositivos, dedicado a registrar los dispositivos biométricos; módulo de horarios, asignar hora de inicio y fin para cada tipo de alimentación (Desayuno, Almuerzo, Sopa y Segundo); módulo de menús, ingresar los diferentes menús que se ofrecerá en el día; módulo de cartas, activar los distintos menús para horas especificas; módulo de pedidos, registrar el menú seleccionado; módulo de parámetros, indica quien será la persona responsable de firmar los reportes; módulo de reportes, visualiza, imprime y envía por correo electrónico los reportes de alimentación. Para el desarrollo de RESAN se empleó la metodología XP con una arquitectura basado en MVC. En la implementación, para el diseño se empleó HTML5 y Bootstrap v3.3.7 (CSS3); para la de base de datos se usó MariaDB v5.5.52, en la programación de los módulos se utilizó PHP v7.1.9 y JavaScript (jQuery v3.2.1) y por último como editor de texto Sublime Text 3.

Palabras clave: Automatización, Metodología, Software de código abierto.

viii

ABSTRACT The current titling work allowed to automate the different management processes in an efficient way for the restaurant of the company CONCLISAN CIA. LTDA RESAN (Santiago's Restaurant). It has been developed to free the administrator from overload, in order to optimize the time spent in each activity, decrease material resources and improve control of the operations that were carried out. The computer system has eight modules that are detailed below: client module, allows to manage the clients that will use the system; device module, dedicated to registering biometric devices; schedule module, assign start and end time for each type of food (breakfast, lunch, soup and main course); menu module, enter the different menus that will be offered on the day; card module, activate the different menus for specific hours; order module, register the selected menu; parameter module, indicates who will be the person responsible for signing the reports; Reports module, visualize, print and e-mail the feed reports. For the development of RESAN, the XP methodology was used with an architecture based on MVC. In the implementation, HTML5 and Bootstrap v3.3.7 (CSS3) were used for the design; for the database, MariaDB v5.5.52 was used, in the programming of the modules, PHP v7.1.9 and JavaScript (jQuery v3.2.1) were used and finally, as text editor Sublime Text 3.

Keywords: Automation, Methodology, Open source software.

ÍNDICE DE CONTENIDOS

2.2.1. 2.4.1. 2.4.2. 3.1.1. 3.1.2. 3.1.3. 3.1.4.

3.1.5.

3.1.6. 3.1.7.

3.1.8.

3.1.9.

4.1.1. 4.1.2.

INTRODUCCIÓN ...................................................................................................... 1 PLANTEAMIENTO DEL PROBLEMA ................................................................... 3 Antecedentes ............................................................................................................... 3 Problema de Investigación .......................................................................................... 5 Preguntas Básicas. ....................................................................................................... 5 Justificación del problema ........................................................................................... 6 Objetivos ..................................................................................................................... 8 Objetivo General. ........................................................................................................ 8 Objetivos Específicos. ................................................................................................. 8 MARCO REFERENCIAL .......................................................................................... 9 Revisión de la literatura o fundamentos teóricos ........................................................ 9 Ingeniería de Software. ............................................................................................... 9 Definición. ................................................................................................................... 9 Paradigmas de Programación. ..................................................................................... 9 Programación orientada a objetos. .............................................................................. 9 Metodología de Desarrollo. ......................................................................................... 9 Metodologías tradicionales. ...................................................................................... 10 Metodologías ágiles................................................................................................... 11 Biometría. .................................................................................................................. 17 Definición. ................................................................................................................. 17 Recomendación de huellas dactilares. ....................................................................... 18 Autentificación. ......................................................................................................... 18 Dispositivo biométrico. ............................................................................................. 18 Base de Datos. ........................................................................................................... 19 Definición. ................................................................................................................. 19 Sql.............................................................................................................................. 19 MariaDB. ................................................................................................................... 19 Sistemas de administración de datos. ........................................................................ 19 Aplicaciones Web. .................................................................................................... 20 Definición. ................................................................................................................. 20 Tipos de aplicaciones web......................................................................................... 22 Herramientas de desarrollo web. ............................................................................... 22 Editor de código. ....................................................................................................... 22 Lenguajes de programación. ..................................................................................... 22 Diseño web. ............................................................................................................... 23 Sdk............................................................................................................................. 24 Arquitectura MVC..................................................................................................... 24 Modelo. ..................................................................................................................... 25 Vista. ......................................................................................................................... 25 Controlador................................................................................................................ 25 Administración Estratégica. ...................................................................................... 26 Reportes. .................................................................................................................... 26 Registro de pedidos. .................................................................................................. 26 Recursos en una empresa. ......................................................................................... 26 METODOLOGÍA ..................................................................................................... 27 Tipo/diseño/enfoque de Investigación ...................................................................... 27 Enfoque de investigación. ......................................................................................... 27 Diseño de Investigación. ........................................................................................... 27

Diseño no experimental. ............................................................................................ 27 4.1.3. Tipo de Investigación. ............................................................................................... 27 Investigación exploratoria. ........................................................................................ 27 Investigación descriptiva. .......................................................................................... 28 Población/Muestra ..................................................................................................... 28 4.2.1. Población. .................................................................................................................. 28 4.2.2. Muestra. ..................................................................................................................... 28 Técnica e Instrumentos de recogida de datos ............................................................ 29 4.3.1. Técnicas de recogida de datos. .................................................................................. 29 Entrevista. .................................................................................................................. 29 Observación. .............................................................................................................. 29 Encuesta. ................................................................................................................... 29 4.3.2. Instrumento de recogida de datos. ............................................................................. 30 Técnicas de análisis de datos ..................................................................................... 30 RESULTADOS ......................................................................................................... 31 Discusión y análisis de resultados ............................................................................. 31 5.1.1. Análisis situacional de la población para uso del sistema. ........................................ 31 Entrevista realizada a la administradora del restaurante de CONCLISAN CIA LTDA. ....................................................................................................................... 31 Entrevista realizada a la directora del área de sistemas de CONCLISAN CIA. LTDA. ....................................................................................................................... 33 Encuesta realizada al personal de CONCLISAN CIA. LTDA. ................................ 34 Propuesta de Intervención ......................................................................................... 42 5.2.1. Metodología de Desarrollo de Software.................................................................... 42 Comparativa de metodologías tradicionales y ágiles. ............................................... 42 Elección de modelos ágiles. ...................................................................................... 43 5.2.2. Desarrollo del software utilizando la metodología XP. ............................................ 44 Planeación. ................................................................................................................ 44 Diseño........................................................................................................................ 50 Codificación. ............................................................................................................. 60 Pruebas. ..................................................................................................................... 63 Análisis del impacto .................................................................................................. 65 5.3.1. Impacto tecnológico. ................................................................................................. 66 5.3.2. Impacto económico. .................................................................................................. 66 5.3.3. Impacto ambiental. .................................................................................................... 67 5.3.4. Impacto general. ........................................................................................................ 68 Conclusiones ............................................................................................................. 69 Recomendaciones ...................................................................................................... 70 REFERENCIAS ....................................................................................................................... 71 GLOSARIO ............................................................................................................................. 73 ANEXOS ................................................................................................................................. 74

ÍNDICE DE TABLAS Tabla 1 Roles XP .................................................................................................................... 15 Tabla 2 Roles Scrum ................................................................................................................ 17 Tabla 3 Necesidad de un sistema web para la gestión del restaurante..................................... 34 Tabla 4 Utilización de un sistema informático ........................................................................ 35 Tabla 5 Control en el proceso del registro de pedidos ............................................................. 36 Tabla 6 Tiempo en el registro del pedido ................................................................................ 37 Tabla 7 Reducción del tiempo en el registro del pedido ......................................................... 38 Tabla 8 Registro de pedidos ..................................................................................................... 39 Tabla 9 Reporte a cuenta de correo electrónico ....................................................................... 40 Tabla 10 Tecnologías para la competitividad y calidad de servicio ........................................ 41 Tabla 11 Comparativa entre metodologías de desarrollo de software ..................................... 43 Tabla 12 Elección de modelos ágiles ....................................................................................... 44 Tabla 13 Plan de Entrega ......................................................................................................... 46 Tabla 14 Plan de Iteraciones .................................................................................................... 48 Tabla 15 Tarjeta CRC - Clientes .............................................................................................. 50 Tabla 16 Tarjeta CRC - Dispositivos ....................................................................................... 51 Tabla 17 Tarjeta CRC - Pedidos .............................................................................................. 51 Tabla 18 Tarjeta CRC - Usuario .............................................................................................. 51 Tabla 19 Tarjeta CRC - Horario .............................................................................................. 51 Tabla 20 Tarjeta CRC - Menús ................................................................................................ 52 Tabla 21 Tarjeta CRC - Reportes............................................................................................. 52 Tabla 22 Tarjeta CRC - Cartas................................................................................................. 52 Tabla 23 Tarjeta CRC - Parámetros ......................................................................................... 52 Tabla 24 Tabla de Impactos ..................................................................................................... 65 Tabla 25 Impacto tecnológico ................................................................................................. 66 Tabla 26 Impacto económico .................................................................................................. 66 Tabla 27 Impacto ambiental.................................................................................................... 67 Tabla 28 Impacto general........................................................................................................ 68

xii

ÍNDICE DE FIGURAS Figura 1. Modelo de Cascada................................................................................................. 10 Figura 2. Modelo Incremental................................................................................................ 11 Figura 3. Modelo Espiral ....................................................................................................... 11 Figura 4. Modelo XP............................................................................................................. 12 Figura 5. Digital Persona U ARE U 4500.............................................................................. 18 Figura 6. Modelo Cliente-Servidor ........................................................................................ 21 Figura 7. Arquitectura Patrón MVC ...................................................................................... 25 Figura 8. Porcentaje de la pregunta 1 de la encuesta al personal ........................................... 34 Figura 9. Porcentaje de la pregunta 2 de la encuesta realizada al personal .......................... 35 Figura 10. Porcentaje de la pregunta 3 de la encuesta realizada al personal ........................... 36 Figura 11. Porcentaje de la pregunta 4 de la encuesta realizada al personal ........................... 37 Figura 12. Porcentaje de la pregunta 5 de la encuesta realizada al personal ........................... 38 Figura 13. Porcentaje de la pregunta 6 de la encuesta realizada al personal ........................... 39 Figura 14. Porcentaje de la pregunta 7 de la encuesta realizada al personal ........................... 40 Figura 15. Porcentaje de la pregunta 8 de la encuesta realizada al personal ........................... 41 Figura 16. Plantilla Historia de Usuario .................................................................................. 45 Figura 17. Modelo lógico de la base de datos del sistema RESAN ......................................... 53 Figura 18. Diseño de Interfaz de ingreso al sistema ................................................................ 54 Figura 19. Diseño de interfaz de vista principal. ..................................................................... 55 Figura 20. Diseño de interfaz del módulo clientes .................................................................. 55 Figura 21. Diseño de interfaz del módulo dispositivos............................................................ 56 Figura 22. Diseño de interfaz del módulo pedidos .................................................................. 56 Figura 23. Diseño de interfaz del módulo horarios.................................................................. 57 Figura 24. Diseño de interfaz del módulo de menús ............................................................... 57 Figura 25. Diseño de interfaz del módulo de reportes ............................................................. 58 Figura 26. Diseño de interfaz del módulo de parámetros ........................................................ 58 Figura 27. Diseño de menús del módulo de cartas .................................................................. 59 Figura 28. Diseño de interfaz de Login de usuario .................................................................. 59 Figura 29. Diseño de interfaz del módulo pedidos .................................................................. 60 Figura 30. Codificación de la conexión a la base de datos ...................................................... 61 Figura 31. Codificación de la clase clientes............................................................................. 61 Figura 32. Interfaz de ingreso al sistema web.......................................................................... 62 Figura 33. Codificación del Login de usuario para el administrador ...................................... 62 Figura 34. Interfaz de la página principal ................................................................................ 63 Figura 35. Codificación de la interfaz principal ...................................................................... 63 Figura 36. Ejemplo de prueba unitaria realizada a la clase Cliente. ........................................ 64

xiii

ร NDICE DE ANEXOS Anexo 1. Entrevista realizada a la administradora del restaurante de CONCLISAN CIA. LTDA .................................................................................................................................................. 74 Anexo 2. Entrevista realizada a la directora del รกrea de sistemas de CONCLISAN CIA. LTDA. .................................................................................................................................................. 75 Anexo 3. Encuesta realizada al personal de CONCLISAN CIA. LTDA. ............................... 76 Anexo 4. Historias de usuario .................................................................................................. 77 Anexo 5. Diccionario de datos ............................................................................................... 100 Anexo 6. Pruebas de aceptaciรณn del sistema RESAN ........................................................... 105 Anexo 7. Manual de usuario .................................................................................................. 112 Anexo 8. Manual de instalaciรณn............................................................................................. 112 Anexo 9. Acta de entrega y recepciรณn .................................................................................. 113 Anexo 10. Carta de impacto................................................................................................... 114

INTRODUCCIÓN La implementación de tecnologías informáticas (TIC´s) brinda un apoyo que se fundamenta en la sociedad para el desarrollo de las empresas; contando con diversas herramientas que ayuden con la optimización de los procesos, mejorando así el tiempo establecido y a la vez la calidad del servicio que se ofrece al cliente. Al desarrollar esta Disertación de Grado se optimizaron los distintos procesos que se realizaban para el registro de pedidos y presentación de reportes de alimentación para el servicio de restaurante que se ofrece en la empresa CONCLISAN CIA. LTDA ubicada en la ciudad de Santo Domingo de los Tsáchilas, proporcionando a la misma de una herramienta apropiada para automatizar los procesos que actualmente se los llevan de una forma manual. A continuación, se detalla en breves rasgos los apartados que conforma este plan de disertación: El planteamiento del problema consta de las siguientes partes: antecedentes, problemática, justificación y objetivos de la investigación. Los antecedentes sirven de guía para elaborar las preguntas de investigación; El problema de investigación es la idea que se convierte en objeto de estudio y se define por medio de preguntas; La justificación corresponde a las argumentaciones respecto a la conveniencia de realizar la investigación relacionada con los objetivos del buen vivir 2017-2020; y por último se determinan los objetivos de la invetigación los cuales reflejan los propósitos de la misma. El marco referencial tiene la revisión literaria de los fundamentos teóricos en relación al tema escogido,

el cual permitió definir

contenidos como: ingeniería de software,

paradigmas de programación, biometría, bases de datos, aplicaciones web, herramientas de desarrollo web, arquitectura MVC, la administración estratégica para la gestión y el control de pedidos en una empresa. En la metodología de la investigación se detalló el enfoque, diseño, tipo de investigación, población, muestra, técnicas e instrumentos de recogida de datos y técnica de análisis de datos, estos puntos fueron importantes porque permitieron realizar un mejor manejo de la información para así conocer las necesidades que tenía el cliente. En los resultados se plasmaron la discusión y análisis de los resultados, la propuesta de

intervención, el impacto del proyecto, conclusiones y recomendaciones obtenidas de la presente investigación, correspondientes al desarrollo del sistema web mediante la correcta selección de la metodología de desarrollo de software. Para terminar, se detalla la lista de referencias bibliográficas utilizadas en el desarrollo del presente documento sustentando así todo lo descrito.

PLANTEAMIENTO DEL PROBLEMA Antecedentes CONCLISAN CIA. LTDA es una institución privada que ofrece servicios médicos a la población, fundada en 1981 por el Dr. Alfredo Curipoma y está ubicada en la provincia de Santo Domingo de los Tsáchilas en la Av. Quito 118 y Oranzonas. Este consorcio brinda servicios de: laboratorio, imágenes, hospitalización, consulta externa, farmacia interna y restaurante. CONCLISAN CIA. LTDA al ofrecer también el servicio de restaurante para el personal que elabora en la misma tiene que llevar un control de los procesos que se realiza para los pedidos que se efectúen diariamente, para así al finalizar cada mes enviar los reportes al respectivo departamento. Esta empresa, como misión: brinda los mejores servicios para aliviar los problemas de salud con calidez y seguridad y como visión: ser líderes regionales en servicios de salud certificados a través de la excelencia profesional con tecnología moderna y mejora continua. Mediante la visita a la empresa CONCLISAN, se detectó que en el servicio de restaurante existe un bajo control en el registro de pedidos y como resultado se tiene un mal manejo del mismo al momento de generar los reportes para presentarlos al departamento de contabilidad, para hacer el descuento del consumo mensual de servicio de restaurante en el rol de pagos. A continuación se hace referencias a trabajos de investigación relacionados con la presente Disertación de Grado que sirvieron de guía para tener una idea sobre cómo se trató el problema en dicha ocasión. A nivel mundial se ha encontrado tres Disertaciones de Grado referentes a la gestión realizada en los restaurantes, las cuales se detallan a continuación: En la Universidad Autónoma de Barcelona en la escuela de Ingeniería de Sistemas, se encuentra la Disertación de Grado intitulada “SGP: SISTEMA DE GESTIÓN DE PEDIDOS” del año 2010 desarrollada por el señor Francisco Rodríguez Hernanz, se basa en la implementación de un sistema web para la gestión de los pedidos del restaurante desde la creación de un pedido hasta su finalización. Utiliza terminales táctiles en las mesas para la

interacción del cliente con el sistema, reduciendo el tiempo de ejecución de los procesos. En la Universitat Oberta de Catalunya en la escuela de Ingeniería Técnica en Informática de Gestión, se encuentra el proyecto intitulado “TFC-RESTAURANTE TOC TOC” del año 2012 desarrollada por el señor Antonio del Rio Fernández, este proyecto tiene como propósito el desarrollo de una aplicación para la gestión de pedidos de un restaurante. Consta de tres módulos; una interfaz web, para la interacción de los clientes con el restaurante; módulo de administración, para que el usuario administrador pueda ingresar los datos dinámicos (carta y menús diarios) y un módulo de comunicación entre el personal de sala y cocina. En la Universidad Carlos III de Madrid de la escuela de Informática, se encuentra la Disertación de Grado “DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN ANDROID PARA LA GESTIÓN DE PEDIDOS EN RESTAURANTES” del año 2013 desarrollado por la señorita Carmen Fuentes Alba. Se basa en la selección de los pedidos en tiempo real para poder organizar cada uno de ellos en la cocina, mediante dispositivos Android. A nivel nacional se ha encontrado dos Disertaciones de Grado referentes a la gestión realizada en los restaurantes, las cuales se detallan a continuación: En la ciudad de Guayaquil en la Universidad Politécnica Salesiana, en la escuela de Ingeniera de Sistemas, se encuentra la Tesis intitulada “IMPLEMENTACIÓN DE SISTEMA PARA RESTAURANTES PARA GESTIÓN DE PEDIDOS Y FACTURACIÓN ELÉCTRÓNICA (AMBIENTE MÓVIL & SISTEMA ADMINISTRABLE DESDE UNA PC)” en el año 2015, desarrollada por los señores Roberto Carlos Espinosa Rivas y Juan Carlos León Quiñonez. La misma que consta de los módulos de gestión de pedidos, facturación, emisión y notificación de comprobantes electrónicos del SRI para ambientes móviles y PCs. En la ciudad de Quito en la Escuela Politécnica Nacional en la facultad de Ingeniería de Sistemas, se encuentra el Proyecto intitulado “DESARROLLO DE UN SISTEMA WEB PARA LA GESTIÓN DE PEDIDOS EN UN RESTAURANTE” en el año 2015 desarrollado por el señor Carlos Xavier Burgos Cando. El cual se basa en la implementación de una aplicación para realizar los pedidos de una manera ágil y segura.

Problema de Investigación En el servicio de restaurante de CONCLISAN CIA. LTA para realizar un pedido por parte del personal tarda demasiado tiempo, teniendo la administradora que hacer el proceso de registro de forma manual mediante el uso de papel. Llevar un control de estos significa un gasto excesivo de recursos como: papel, tinta de impresora, esferos, carpetas plásticas entre otros. Este problema afecta a la administradora porque realiza el registro manual de pedido de cada uno de los clientes generando un gasto adicional y al cliente porque es tedioso esperar demasiado tiempo a que llegue el momento de solicitar su pedido. Cuando llega la fecha de corte que se lo hace mensualmente, la administradora verifica el consumo total de pedidos de cada cliente y este debe cuadrar con el listado que se realiza diariamente, para así corroborar que todo esté correctamente y enviar el reporte al departamento de contabilidad. Además, cuando los clientes tienen el mismo apellido, ellos pueden confundirse al momento de firmar en el listado de registro, firmando en el cuadro correspondiente de la otra persona, el cual ocasiona un descuento a la persona equivocada en su rol de pago a fin de mes. El presente proyecto de investigación se apoya en la necesidad de ofrecer en el servicio del restaurante de CONCLISAN CIA. LTDA, un mejor control en el registro de pedidos de alimentación durante el periodo 2017. 2.2.1. Preguntas Básicas. El presenta proyecto de investigación responderá a la problemática: ¿Cómo mejorar el control en la gestión de restaurante del personal en CONCLISAN CIA. LTDA en la provincia de Santo Domingo de los Tsáchilas? ¿Cuáles son los procesos para el control del registro de pedidos de alimentación en el servicio de restaurante en CONCLISAN CIA LTDA? ¿Cuáles son las metodologías de desarrollo de software que se podrían aplicar para el desarrollo del sistema web para la gestión de restaurante del personal en CONCLISAN CIA LTDA.?

¿De qué manera un sistema informático facilitará la gestión de restaurante del personal en CONCLISAN CIA. LTDA.?

Justificación del problema La Disertación de Grado se desarrolló en base al objetivo 4 del Plan Nacional del Buen Vivir, el cual establece: “Fortalecer las capacidades y potencialidades de la ciudadanía” en la política 4.6 “Promover la interacción recíproca entre la educación, el sector productivo y la investigación científica y tecnológica, para la transformación de la matriz productiva y la satisfacción de necesidades”. Con ello se fomenta el impulso tecnológico a la empresa generando mayor productividad a la misma y se contribuye con el empleo de conocimientos adquiridos de las tecnologías en tendencia. A lo largo del tiempo la tecnología ha minimizado los inconvenientes a la hora de hacer negocios; incrementando los ingresos, mejorando procesos e implementando herramientas de vanguardia dentro de las organizaciones. Actualmente, las organizaciones hacen uso de diversas herramientas tecnológicas ya no como un lujo ni inversión, sino como una necesidad fundamental con el propósito de ampliar sus servicios, generar procesos competitivos, y mejorar su productividad. El constante cambio tecnológico ha influido para que varias empresas estén inmersas en el mundo digital. Es importante recalcar que la adquisición de innovaciones tecnológicas mejora la productividad de las empresas, realizando así operaciones eficaces gracias al apoyo de herramientas informáticas, en donde estas permiten obtener una mayor ventaja frente a otras dedicas a la misma labor. Las empresas se manejan dentro de una sociedad muy competitiva por lo cual buscan aumentar las ganancias y reducir perdidas. Este es el caso, en el área del restaurante de CONCLISAN CIA. LTDA que busca mejorar el control de sus procesos, optimizando tiempo y recursos. Debido a la dificultad que se presentaba en el servicio de restaurante para realizar el control de los pedidos de alimentación, se determinó la necesidad de utilizar una herramienta tecnológica que permita llevar este control. Es importante tener un apropiado manejo de estos pedidos para

mejorar el desempeño de todas las tareas realizadas por parte de la

administradora. Mediante la implementación de un sistema web se optimizó el tiempo de espera de los clientes al momento de realizar el registro de sus pedidos. Además, esto facilitó a la administradora llevar un control eficiente y seguro, arrojando información verídica en los reportes de alimentación del personal. Esta información será utilizada por el departamento de contabilidad para el descuento mensual en sus roles de pago. Las razones que se consideraron y justificaron para el desarrollo del sistema web son: registrar y controlar los procesos que se realizaban manualmente, mediante la implementación de este sistema se buscó optimizar tiempo, recursos y agilizar los procesos actuales, obteniendo información precisa para ser manejada por la administradora. El desarrollo e implementación del sistema benefició de una manera directa a los clientes porque obtuvieron una herramienta que ayudó a mejorar la efectividad en el servicio, dando solución a los inconvenientes

presentados y como beneficiaria indirecta a la

administradora porque es la encargada del área del restaurante y es quien maneja todos los procesos existentes. El trabajo de titulación fue factible de realizar porque se pudo recopilar toda la información necesaria, se contó con el apoyo y asistencia del personal de CONCLISAN CIA. LTDA quienes proporcionaron la información del problema, también con las instalaciones, recursos tecnológicos y humanos que ayudaron en el desarrollo y cumplimento de los objetivos propuestos para el proyecto.

Objetivos 2.4.1. Objetivo General. Implementar un sistema web para la gestión de restaurante del personal de CONCLISAN CIA. LTDA en la provincia de Santo Domingo de los Tsáchilas en el periodo 2017-2018. 2.4.2. Objetivos Específicos. 

Determinar los diferentes procesos para el control del registro de pedidos para el servicio de restaurante del personal en CONCLISAN CIA. LTDA.



Definir la metodología de desarrollo de software que se va a aplicar para el desarrollo del sistema web.



Desarrollar el software para la gestión de restaurante del personal en CONCLISAN CIA. LTDA.

MARCO REFERENCIAL Revisión de la literatura o fundamentos teóricos Para el desarrollo de la presente investigación se fundamenta con las siguientes teorías y definiciones: 3.1.1. Ingeniería de Software. Definición. De acuerdo con Pressman (2010) donde se señala que la ingeniería de software está compuesta por técnicas, métodos y herramientas que se utiliza en el desarrollo, implementación y mantenimiento de sistemas informáticos que se utiliza para apoyar el desarrollo del software profesional que sea confiable y trabaje con eficiencia. Por otro lado en Sommerville (2011) refiere que la ingeniería de software no solo trata sobre los programas si no hace énfasis en toda la documentación asociada y datos de configuración para que pueda funcionar adecuadamente del programa. 3.1.2. Paradigmas de Programación. Es la manera de estructurar y organizar las tareas que se llevan a cabo en un programa, asociándose a un estilo de programación. Programación orientada a objetos. La programación orientada a objetos según Guardati (2014) señala que es el método en donde los programas se componen como un conjunto cooperativo de objetos, en donde cada uno de ellos simboliza una instancia de alguna clase. Este paradigma se identifica por trabajar con técnicas como herencia, cohesión, abstracción, polimorfismo, acoplamiento y encapsulamiento. Esta basada en cuatro caracteristicas principales: abstraccion, polimorfismo, encapsulamiento y herencia. 3.1.3. Metodología de Desarrollo. En concordancia con lo establecido en Pressman (2010) donde señala que la metodología de desarrollo es un proceso paso a paso sobre el desarrollo del software con el fin

de hacerlo más eficiente y predecible para obtener resultados confiables. Metodologías tradicionales. Las metodologías tradicionales son utilizadas para el uso exhaustivo de documentación durante todo el ciclo de vida del proyecto y orientadas a procesos de varios meses es decir para proyectos grandes (Pressman, 2010). 3.1.3.1.1. Modelo en cascada. El modelo cascada es también conocido como ciclo de vida clásico, se aplica desarrollando el software de manera sistemático y secuencial para el desarrollo del software, el cual necesita tener todos los requerimientos por el cliente, además este método organiza etapas del proceso para el desarrollo de software y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado (Pressman, 2010)

Figura 1. Modelo de Cascada. Adaptado de “Ingeniería de Software. Un Enfoque Práctico” por R.S. Pressman, 2010, México Mc Graw Hill.

3.1.3.1.2. Modelo incremental. En conformidad con Pressman (2010) refiere que este modelo se centra en que cada incremento se entrega un producto funcional. Los primeros incrementos son versiones desnudas del producto final, permitiendo una evaluacion por parte del usuario desde el inicio.

Figura 2. Modelo Incremental. Adaptado de “Ingeniería de Software. Un Enfoque Práctico” por R.S. Pressman, 2010, México Mc Graw Hill.

3.1.3.1.3. Modelo espiral De acuerdo a lo señalado en Pressman (2010) el modelo de desarrollo espiral es un generador de modelo de proceso evolutivo y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada. Además, tiene el potencial para hacer un desarrollo rápido de versiones cada vez más completas.

Figura 3. Modelo Espiral. Adaptado de “Ingeniería de Software. Un Enfoque Práctico” por R.S. Pressman, 2010, México Mc Graw Hill.

Metodologías ágiles. En base a Pressman (2010) donde señala que las metodologías ágiles son orientadas a pequeños proyectos con duración de pocas semanas y con un bajo nivel de documentación.

3.1.3.2.1. Programación extrema - XP. La programación extrema (XP), es el enfoque más utilizado del desarrollo de software ágil, además define un grupo de valores que establece el fundamento para todo trabajo elaborado (Pressman, 2010). XP utiliza un enfoque orientado a objetos como paradigma preferido de desarrollo y esta sujeta a actividades estructurales del proceso XP.

Figura 4. Modelo XP. Adaptado de “Ingeniería de Software. Un Enfoque Práctico” por R.S. Pressman, 2010, México Mc Graw Hill.

3.1.3.2.1.1. Fases de la metodología. 

Fase de Planeación o Exploración: Pressman (2010) señala que la exploración define el alcance general del proyecto, el cliente precisa lo que necesita mediante la redacción de sencillas “historias de usuario”. Los programadores estiman los tiempos de desarrollo en base a esta información. Se debe entender la propuesta en esta fase ya que están basadas en datos reales y eficientes.

o Plan de Publicaciones: el plan de publicaciones el cliente y el grupo de desarrolladores acuerdan el orden en que deberán implementarse las historias de usuario y las entregas. Esta fase consiste en una o varias reuniones grupales de planificación. También, esta fase se encarga del plan de entregas que se detallan en las reglas XP y prácticas (Pressman, 2010) o Plan de Iteraciones: el plan de iteraciones se

desarrollarán las

funcionalidades, generando una funcionalidad que implementa las historias de usuario asignadas a la iteración. Las iteraciones se encargarán de medir el progreso del proyecto. Una iteración terminada sin errores es una medida muy buena generando al final de cada una un entregable funcional (Pressman, 2010). 

Fase de Diseño: es aquí donde se realiza el diseño sencillo, así como se refiere Pressman (2010) donde en esta etapa se sigue el principio de simplicidad, además el diseño guía la implementación de una historia conforme se escribe y se hace uso de las tarjetas CRC como mecanismo para pensar en un software orientado a objetos.



Fase de Codificación: en esta fase uno de los puntos claves es la programación en pareja. Dos personas deberán trabajar unidas en una estación de trabajo con el objeto de crear el código para las historias para así tener una mejor solución frente a los problemas que puedan presentarse (Pressman, 2010).



Fase de Pruebas: de acuerdo con Pressman (2010) donde se señala que no se debe poner el sistema en producción hasta tener completamente la funcionalidad de este. No se desarrollarán más funcionalidades, pero pueden ser necesarias algunos procesos de configuraciones o ajustes.

3.1.3.2.1.2. Valores en XP. Los valores XP se definen como un conjunto de cinco valores que son: comunicación, simplicidad, retroalimentación, valentía y respeto. Cada una de estos realiza acciones y tareas específicas de XP. 

Comunicación Eficaz: Pressman (2010) señala que la base del éxito del trabajo de un equipo de desarrollo es la comunicación, XP pone el énfasis en la colaboración informal entre los clientes y los desarrolladores, es la mejor forma de evitar la mayoría de los problemas y errores.



Simplicidad: el objetivo es crear un diseño sencillo que se implemente con facilidad en forma de código, la cual al construir de forma simple disminuya la cantidad de código que hay que escribir y aumente la calidad del software (Pressman, 2010).



Retroalimentación: existen tres fuentes

de donde se obtiene la

retroalimentación que son el software implementado, cliente y otros miembros del equipo. Al diseñar y realizar una estrategia de pruebas, el software da retroalimentación al equipo así como también cuando se obtienen nuevos requerimientos como parte de la planeación iterativa (Pressman, 2010). 

Valentía: Pressman (2010) señala que para aplicar este valor en nuestro trabajo se requiere de mucha disciplina para comunicarse eficazmente con el cliente y compañeros para afrontar los cambios en el producto.



Respeto: Pressman (2010) señala que se debe valorar el trabajo de los demás y sus aportaciones teniendo muy presente como puede afectar dicho trabajo en las personas que colaboran en la organización.

3.1.3.2.1.3. Roles de xp. Tabla 1 Roles XP Rol de XP

Actividad Define las especificaciones. Escoge las historias de usuario para cada iteración. Cambiar el alcance del proyecto para hacer frente a los cambios en la planificación. Determinar que funcionalidades serán las siguientes en implementar.

Cliente

Hace estimaciones de su propio trabajo. Responsable del código. Tiene que tener capacidad de comunicación. Responsable del diseño y de las pruebas. Implementa las funcionalidades del cliente. Implementa las historias y las pruebas unitarias.

Programador

Responsable del proceso de guiar y orientar. Experto en XP. Identifica las señales de peligro y se asegura que el proyecto se mantenga en curso proponiendo ideas para mejorar.

Coach

Encargado de seguimiento (Tracker)

Monitoriza el progreso del programador. Controla el fiel cumplimiento de las estimaciones en cada iteración. Proporciona realimentación al equipo.

Consultor

Es una persona externa del grupo. Tiene conocimiento específico y apoya al equipo en cuestiones puntuales.

Gestor (Big Boss)

Planifica las reuniones y anota sus resultados. El cliente puede asumir este papel de gestor.

Nota: Roles de XP Fuente: Brito, K., Sosa, D., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. San Bernardino, CA: Académica Española.

3.1.3.2.2. Scrum. En conformidad con Pérez (2015) donde señala que Scrum es un modelo de desarrollo ágil de software que se ejecuta en bloques temporales, pueden ser de dos o tres semanas. Los principios de Scrum son congruentes con el manifiesto ágil y se usan para llevar las actividades de desarrollo en el proceso de análisis. 3.1.3.2.2.1. Actividades de la metodología Scrum 

Planificación de la Iteración: Estas planificaciones de dividen en dos partes: o Primera Parte: Se realiza en un tiempo máximo cuatro horas: 

El cliente presenta la lista de requisitos del proyecto al equipo.



El equipo examina la lista, una vez examinada hace preguntas al cliente sobre las dudas que surgen.

o Segunda Parte: El equipo es el responsable de organizar su trabajo.





Complementan cada requisito definiendo las tareas necesarias.



Estimación de esfuerzo necesario para realizar cada tarea.



Se asignan tareas cada miembro del equipo que pueden realizar.

Ejecución de la Iteración o Cada iteración tiene que proporcionar un resultado. o El equipo cada dia realiza una reunión sincronizada, en donde los miembros inspeccionan el trabajo o El facilitador se encarga de todo el equipo cumpla con su compromiso, además, elimina problemas que no se pueden resolver por sí mismo.



Reunión diaria de sincronización del equipo: Los miembros del equipo colaboran con la inspección del trabajo del resto que se está realizando, al finalizar una reunión se podrá hacer las adaptaciones necesarias que permitirán cumplir con el compromiso.



Demostración de requisitos completados o El equipo presenta al cliente los requisitos completados. o El cliente realiza las adaptaciones necesarias de manera objetiva.



Retrospectiva: El equipo analiza que cosas han funcionado excelente, que debemos mejorar. El objetivo de mejorar de manera continúa su productividad. El facilitador se encargara de eliminar los problemas identificados que no se pueden resolver por sí mismo.



Replanificación del proyecto: Los cambios en la lista de requisitos pueden ser debidos a:

o Se realiza modificaciones que el cliente solicita al final de cada iteración sobre los resultados obtenidos. o Cambiar y hacer frente a urgencias o nuevas peticiones de clientes. o Nuevos requisitos como resultados. 3.1.3.2.2.2. Roles de scrum. Tabla 2 Roles Scrum Roles Scrum

Actividad

Product Owner

Representa a todas las personas interesadas en los resultados del proyecto. Define los objetivos del proyecto. Participa en la reunión de demostración, revisando los requisitos completados.

Scrum master

Guía la colaboración del equipo con el cliente. Quita los impedimentos que el equipo tiene en su proceso para conseguir el objetivo y poder finalizar el proyecto con éxito. Enseña al equipo a auto gestionarse.

Equipo

Selecciona los requisitos que se compromete a completar. Tienen habilidades necesarias para poder identificar y ejecutar todas las tareas que permiten proporcionar al cliente.

Nota: Roles Scrum. Fuente: Brito, K., Sosa, D., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. San Bernardino, CA: Académica Española.

3.1.4. Biometría. Definición. Según Jean-Marc Royer (2007) la biometría mide una de las características del cuerpo humano con el objetivo de identificar un individuo. Se elige una característica que diferencie a un individuo de otro. Los principales métodos utilizados son: la cara, la huella, la geometría de la mano, el iris, la voz, las venas, las orejas, el pulso cardiaco, la radiografía dental, el ADN. (p.98)

Recomendación de huellas dactilares. El reconocimiento de las huellas dactilares son técnicas utilizadas a nivel mundial por organizaciones para controlar a sus trabajadores, ya que estas son únicas y permanecen fijas a lo largo de la vida. “Una huella digital normalmente está conformada por una serie de líneas oscuras que representan las crestas y una serie de espacios blancos que representan los valles”. (Osorio, Aguirre, & Escobar, 2010). Autentificación. Según García (2013) el proceso de autentificación biométrica se basa en: un sensor, procesamientos y comparación de una imagen escaneada de las huellas dactilares las cuales se encuentran almacenadas con anterioridad en una base de datos. Un sensor realiza la adquisición de datos después de esto, un algoritmo procesa los datos y extrae características biométricas (plantillas); por último, la plantilla se almacena en una memoria local o remota para futuras comparaciones. (García, 2003). Dispositivo biométrico. Digital Persona U ARE U 4500 es un lector biométrico de huellas dactilares este dispositivo está desarrollado y diseñado concretamente para aplicaciones de negocios que demanden un grado de estabilidad y exactitud, además tiene capacidad para simplificar el trabajo a los usuarios y mantener la seguridad.

Figura 5. Digital Persona U ARE U 4500. Adaptado de ELSI Post Technology. (s.f.). DigitalPersona U ARE U 4500. Obtenido de http://www.elsi.es/lectores-de-huella/digital-persona-u-are-u-4500-ref275.html.

3.1.5. Base de Datos. Definición. Es un conjunto de datos que se relacionan entre sí. Están compuestas de tablas y estas de registros donde cada uno de ellos se compone por conjuntos de campos también llamados atributos los cuales permiten extraer información de una entidad u objeto del mundo real. Se hace una comparación en la cual una base de datos se parece a un gabinete debidamente organizado, en donde este es electrónico y guarda archivos que son procesados por un software, también conocido como sistema de administración de base de datos, el cual permite manejar la información del gabinete de una manera eficaz. (Coronel, Morris, & Rob, 2011). Sql. SQL (Structured Query Language) es una herramienta la cual permite ordenar, gestionar y recuperar datos almacenados en una base de datos relacional, realizando así la comunicación con el sistema de gestión de la base de datos. (Ramos, Ramos, & Montero, 2006) MariaDB. MariaDB se desarrolla como software de código abierto y como una base de datos relacional que proporciona una interfaz SQL para el acceso a los datos. MariaDB se lo utiliza porque es rápido, escalable y robusto, con un rico ecosistema de motores de almacenamiento. (MariaDB, 2017) Sistemas de administración de datos. Según Coronel (2011) un sistema de administración de bases de datos (DBMS, por sus siglas en inglés) es un conjunto de programas encargados del manejo estructural de la base de datos permitiendo el control, acceso y manipulación de los datos guardados en la misma (p. 7) 3.1.5.4.1. Funciones de un sistema de administración de base de datos. Las funciones de un DBMS son las de definición, manipulación y control y se encontrarán en cualquier sistema de base de datos.

3.1.5.4.1.1. Función de definición. Permite al diseñador de la base de datos definir cada uno de los elementos que formen parte de la estructura además de las relaciones existentes entre sí, esta función se realiza mediante de definición de datos (DDL), propio del sistema (Nevada, 2010). 3.1.5.4.1.2. Función de manipulación. Es capaz de insertar nuevos datos o realizar peticiones para recuperar, actualizar o eliminar datos existentes en la base de datos, esta función se realiza a través de la manipulación de datos (DML), propio del sistema (Date, 2012). 3.1.5.4.1.3. Función de control. Consiste en el conjunto de varios instrumentos que permita la agilización y una mejor administración, pudiendo cambiar la dimensión de la base de datos, aplicar seguridades en el acceso, realizar copias de seguridad, respuesta ante fallos (Nevada, 2010). 3.1.6. Aplicaciones Web. En la ingeniería de software una aplicación web es una extensión dinámica o herramientas de un servidor web que los usuarios pueden interactuar a través de internet o intranet mediante un navegador (Martínez et a.l, 2010). Definición. Es una arquitectura se basa en el modelo denominado Cliente / Servidor, basado en la idea de servicio, el cual el cliente es un componente consumidor de servicios y el servidor es un proceso proveedor de servicios. Además, están relacionados robustamente en el intercambio de mensajes. Es decir, el agente que solicita la información se denomina cliente, mientras que el componente software que responde a esa solicitud es el que se conoce como servidor. (López, y otros, 2014).

Figura 6. Modelo Cliente-Servidor. Adaptado de “Desarrollo Web en Entorno Servidor” por López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & de Castro, V, 2014, Madrid, España: RA-MA, Obtenido de https://ebookcentral.proquest.com.

3.1.6.1.1. Servidores. Los servidores pueden ser ejecutados desde cualquier computador y son equipos tecnológicos que están al servicio de otros equipos que están dentro de una red. Es un software que está en ejecución, el cual recibe las peticiones de un cliente y responder a la solicitud con concordancia (Marchionni, 2011). 3.1.6.1.1.1. Servidores web. El servidor web permite transferir páginas web, cuando éste recibe una petición por parte del cliente, éste se encuentra ejecutándose continuamente en un ordenador a la espera de las solicitudes. Es un servidor de ficheros o archivos, donde los clientes del servidor acceden al mismo a través del protocolo HTTP. (Groussard, 2010). 

Servidor Web Apache: El servidor HTTP de Apache es de código abierto para sistemas operativos modernos como Unix y Windows, siendo el más utilizado en servidores web desde el año 1996. Además, de poseer varias características la principal es su arquitectura modular, lo que permite adaptar la funcionalidad del mismo en función de nuestras necesidades fácilmente (Gómez López, Villar Fernández, & Alcayde García, 2011)

3.1.6.1.1.2. Servidores de base de datos. Son servidores dedicados al almacenamiento de grandes volúmenes de información, esta se encuentra resumida en tablas relacionadas entre sí, manteniendo una misma estructura 3.1.6.1.1.3. Servidor de correo. Es un servidor encargado de la gestión, envío y recepción de correo de un grupo de usuarios. En algunos casos estos servidores no son muy potentes, debe tener a su favor protocolos de correo, por ejemplo: SMTP, POP3, IMAP. Tipos de aplicaciones web. 3.1.7. Herramientas de desarrollo web. Editor de código. 3.1.7.1.1. Sublime text 3. Sublime Text es un editor de texto y código multiplataforma ligero, elegante y flexible para su alto rendimiento en ejecución, es una herramienta utilizada para programar sin distracciones. Además, soporta un gran número de lenguajes y se puede descargar una versión de prueba y sin limitación de tiempo, la aplicación está disponible para Linux, Windows y OS X (Sublime Text, 2016). Lenguajes de programación. 3.1.7.2.1. Front-end. 3.1.7.2.1.1. Html. Es el lenguaje de marcado predominante para la elaboración de páginas Web. Permite representar el contenido en forma de texto, así como también trabajar con objetos, como el caso de las imágenes. HTML describe la estructura del contenido, además, puede manejar la apariencia de un documento y también su comportamiento a través de un script (Rosendo & Greguas, 2010).

3.1.7.2.1.2. Css. El lenguaje CSS se usa para definir el aspecto de todos los contenidos, formato de tablas, separación, color, tamaño y tipo de fuente de titulares y textos, la tabulación con la que se muestran los elementos de una lista o menú. (Rosendo & Greguas, 2010, pág. 70). 3.1.7.2.1.3. Javascript. “Está diseñado específicamente para el desarrollo web, es un lenguaje de scripts, multiplataforma, es pequeño, ligero y orientado a objetos. Fue creado para funcionar como complemento de otros lenguajes y aplicaciones, como por ejemplo los navegadores Web” (Benavides, 2011, págs. 11-12). 3.1.7.2.1.4. Jquery. jQuery es una biblioteca JavaScript ágil, pequeña y con una gran variedad en funciones, facilita la forma de trabajar con los documentos HTML, maneja el árbol DOM, utiliza eventos, y agrega interacción con la técnica AJAX a páginas web (jQuery, 2017). 3.1.7.2.2. Back-end. 3.1.7.2.2.1. Php. PHP es el acrónimo Hypertext Preprocessor es un lenguaje de codigo abierto utilizado para el desarrollo web. PHP es un lenguaje flexible del lado del servidor. Lo mejor de PHP es su simplicidad para desarrolladores principiantes, pero ofrece muchas características avanzadas para programadores profesionales. Además, brinda soporta para POO (Programación Orientada a Objetos). Diseño web. 3.1.7.3.1. Framework de diseño. 3.1.7.3.1.1. Bootstrap. Bootstrap es un conjunto de herramientas de código abierto para desarrollar con HTML, CSS y JS. Se construye de una manera muy rapida el diseño de sitios y aplicaciones web, abarca un conjunto de elementos como: plantillas de diseño con tipografía, formularios, botones, cuadros y otros elementos apoyados en HTML y CSS. (Bootsrap, 2015).

3.1.7.3.2. Plantilla de diseño para administración. 3.1.7.3.2.1. Gentelella. Es una plantilla de administrador de Bootstrap gratuita que utiliza estilos predeterminados de Bootstrap 3 tiene una variedad de bibliotecas para gráficos, calendarios, validación de formularios, etc. Además, cuenta con una variedad de potentes complementos y herramientas de jQuery (Github, 2017). Sdk. 3.1.7.4.1. Flexcode sdk. FlexCode SDK es un kit de desarrollo de software generalmente es un conjunto de herramientas y programas de desarrollo que le permite al programador crear aplicaciones. FlexCode es simple de utilizar trabaja con unas funciones necesarias para registrar y verificar huellas digitales (FingerSpot, 2014). 3.1.8. Arquitectura MVC. Es bastante conocido que el patrón Modelo, Vista y Controlador (MVC) es el más extendido para el desarrollo de aplicaciones donde se debe trabajar con interfaces de usuarios, éste se centra en la separación de los datos o modelo, y la vista, mientras que el controlador es el encargado de relacionar a estos dos (Camarena, Espinosa, Reyes, & López, 2012).

Figura 7. Arquitectura Patrón MVC. Adaptado de “Automatización de la codificación del patrón modelo vista controlador (MVC) en proyectos orientados a la Web” por Camarena, j., Espinosa, A., Reyes, M., & López, M, 2012, Ciencia Ergo Sum, 9, 239-250.

Modelo. Representa el estado de la aplicación y cualquier lógica de negocio y operaciones que se deba hacer. La lógica de negocio debe estar encapsulada en el modelo, junto con cualquier lógica de implementación para persistir el estado de la aplicación. Las vistas fuertemente tipificadas utilizarán típicamente tipos ViewModel específicamente diseñados para contener los datos que se visualizaran en ellas (Microsoft, 2016) Vista. Presentan el contenido a través de la interfaz de usuario. Utilizan el motor de vista Razor para incrustar código .NET en el marcado HTML. Debería haber una lógica mínima dentro de las vistas, y cualquier lógica en ellas debería relacionarse con la presentación del contenido. Si encuentra la necesidad de realizar una gran cantidad de lógica en los archivos de vista para mostrar los datos de un modelo complejo, considere la posibilidad de utilizar un Componente View, ViewModel o una plantilla para simplificar la vista (Microsoft, 2016). Controlador. Los controladores son los componentes que manejan la interacción del usuario, trabajan con el modelo y, finalmente, seleccionan una vista para procesar. En una aplicación MVC, la

vista sólo muestra información; El controlador maneja y responde a la entrada e interacción del usuario. En el patrón MVC, el controlador es el punto de entrada inicial y es responsable de seleccionar los tipos de modelo con los que se va a trabajar y la vista a renderizar (de ahí su nombre: controla cómo responde la aplicación a una solicitud determinada) (Microsoft, 2016). 3.1.9. Administración Estratégica. La administración trata de la importancia estratégica en la empresa. Se define las directrices de la organización, en el que el administrador determina las metas y objetivos que deben alcanzarse, además la forma de administrar una empresa lleva a un determinado objetivo que es el éxito o fracaso de la gestión de una organización. La administración se la define como el proceso de planear, organizar, dirigir, coordinar y controlar. Esto nos ayuda a mantener las actividades aumentando el desempeño en la empresa. (Lana, 2012). Reportes. Según García (2014) un reporte es un informe que ordena y muestra la información de una manera detallada que se encuentra almacenada en una base de datos. Este tipo de documento tiene que ser fácil de entender por los usuarios. Registro de pedidos. De acuerdo a García (2014) el registro de pedidos es un formato con el cual se registra los pedidos de una empresa, en los que se incluyen varios campos como: número y fecha, descripción del producto, identificación, proveedor, valor, para así simplificar el trabajo de la organización. Recursos en una empresa. Según García (2014) los recurso son aquellos bienes tangibles, perteneciente a la organización, tales como: instalaciones: edificios, terrenos, maquinaria, herramientas, vehículos., materias primas, materias auxiliares que forman parte del producto, productos en proceso, productos terminados, etc.

METODOLOGÍA Tipo/diseño/enfoque de Investigación 4.1.1. Enfoque de investigación. El presente proyecto se realizó con los enfoques de investigación cuantitativo y cualitativo, en donde el cuantitativo se lo utilizó para basarse en los resultados numéricos obtenidos de las encuestas y el cualitativo en la observación como método de recolección de datos sin medición numérica. 4.1.2. Diseño de Investigación. Diseño no experimental. Este tipo de investigación permite observar la situación, la necesidad o el problema y de acuerdo a eso plantear las variables y desarrollar una solución (Sampieri, Fernández, & Batista, 2010) Mediante este diseño se observó y analizó los procesos llevados a cabo en el área del restaurante con la finalidad de obtener documentación sobre los requerimientos específicos para el desarrollo del sistema web. 4.1.3. Tipo de Investigación. Investigación exploratoria. El presente proyecto se basó en la investigación exploratoria que permitió tener una visión general del problema. Se asistió a la institución para obtener información de los procesos que se realizan en el área del restaurante, se conversó con la directora del área del departamento de sistemas y con la administradora del restaurante quienes proporcionaron la información necesaria y los requerimientos para desarrollar de una manera adecuada el sistema web. La investigación exploratoria se debe realizar cuando el tema de estudio nunca o casi nunca ha sido analizado o tratado, obteniendo así información directamente de la fuente (Sampieri, Fernández, & Batista, 2010).

Investigación descriptiva. Se procedió a emplear la investigación descriptiva la cual expone que los estudios descriptivos buscan especificar propiedades, características y rasgos importantes de cualquier fenómeno que se analice. Se basa principalmente en técnicas como la encuesta, la entrevista, la observación y la revisión documental (Sampieri, Fernández, & Batista, 2010). Esta investigación permitió conocer las características o propiedades importantes del problema a resolver, así da la oportunidad de recolectar, comprobar y estudiar los datos recogidos del problema de control del registro de pedidos.

Población/Muestra 4.2.1. Población. De acuerdo con Sampieri, Fernández, y Batista (2010) se refiere a la población como el grupo central de estudio, es decir, participantes, objetos, comunidades (unidades de análisis), los cuales poseen características en común y sobre los cuales se tiene que deducir la información necesaria para el desarrollo de una investigación. De acuerdo a la problemática, se detectó que los involucrados en el proyecto son el personal que trabaja en CONCLISAN CIA LTDA, teniendo como beneficiaria directa a la administradora porque es quien maneja todos los procesos existentes en el restaurante y los clientes como beneficiarios indirectos porque mediante la utilización del sistema web obtuvieron una herramienta que ayudó a agilizar el servicio y a solucionar los problemas que se presentaban a diario. La población que se consideró para la Disertación de Grado fue el personal que labora bajo a contrato en esta empresa y estuvo comprendida por 93 empleados de los diferentes departamentos existentes (logística, administración, caja, emergencias, entre otros). 4.2.2. Muestra. En el proceso de investigación cuantitativa la muestra es una parte de la población, sobre los cuales se obtendrá los datos con el fin de realizar un posterior análisis. (Sampieri, Fernández, & Batista, 2010)

Bernal (2010) señala que cuando la población es menor de los 100 individuos no es necesario determinar la muestra y los instrumentos se los debe aplicar a toda la población. Considerando lo anteriormente mencionado, en la presente Disertación de Grado, la muestra fue igual a la población, es decir 93 personas.

Técnica e Instrumentos de recogida de datos 4.3.1. Técnicas de recogida de datos. A continuación se detalla cada una de las técnicas que se utilizaron para la obtención de información concreta y necesaria. Entrevista. Método para la obtención de información mediante un contacto directo con personas que se consideran fuentes directas (Bernal, 2010). Se entrevistó a la Administradora y a la directora del departamento de sistemas; donde se pudo obtener información importante para los requerimientos de la aplicación. Observación. Permite recoger datos de una manera distinta, donde los investigadores toman apuntes de lo que pueden apreciar visualmente, el investigador toma apuntes de la información de lo que cree que es importante (Bernal, 2010). Para tener claro el problema se procedió a visitar las instalaciones de CONCLISAN CIA. LTDA y se analizó cuidadosamente todos los procesos que se realizaban en el área del restaurante, se pudo constatar que el proceso de registro de pedidos se lo hacía manualmente, y por ende podía existir errores humanos. Encuesta. Técnica que permite obtener información primaria, donde el investigador recolecta datos mediante la elaboración de un cuestionario con preguntas que ayuden a obtener datos estratégicos (Bernal, 2010). La encuesta fue realizada a la muestra obtenida de la población de CONCLISAN CIA. LTDA con un banco de preguntas elaborado a un previo análisis al problema y a los objetivos generales y específicos del presente Plan de Disertación de Grado.

4.3.2. Instrumento de recogida de datos. Estas permitieron determinar los requerimientos, los cuales fueron importantes para dar solución al problema mediante la recolección de datos. Los instrumentos de recogida de datos fueron las herramientas que permitieron reunir la información de una forma ordenada, ayudando a registrar y resolver las preguntas que aparecieron en la investigación del problema. Estos fueron: la ficha de observación, el cuestionario de encuesta y el cuestionario de entrevista.

Técnicas de análisis de datos El análisis de datos consiste en una serie de procesos que permiten tabular e interpretar la información obtenida por medio de diferentes técnicas e instrumentos de recogida de datos, con el fin de realizar un estudio preliminar de los problemas planteados y formular resultados (Bernal, 2010). Luego de obtener los datos se procedió a hacer el estudio y análisis de ellos, para esto se hizo uso de técnicas básicas de estadística como son: elaboración de los gráficos estadísticos, las tabulaciones y análisis e interpretaciones de datos, por medio de programas de Excel y Word. Con esos datos se pudo responder a varias inquietudes que se tenía sobre el desarrollo del sistema web.

RESULTADOS Discusión y análisis de resultados 5.1.1. Análisis situacional de la población para uso del sistema. Entrevista realizada a la administradora del restaurante de CONCLISAN CIA LTDA. Mediante una entrevista (Ver Anexo 1) a la administradora del restaurante se realizó el levantamiento de información y se determinó cada uno de los procesos que se lleva a cabo, los mismos que se obtuvieron a través de las siguientes preguntas: ¿Cuáles son los procesos que se realizan para la gestión del restaurante? La administradora realiza distintos procesos manuales para la gestión del restaurante, los cuales se detallan a continuación: •

Búsqueda del cliente

•

Registro del cliente

•

Verificación diaria de los tickets que se entrega a los clientes

•

El control total de los consumos mensuales

¿Cree usted que sea indispensable implementar un sistema web para mejorar los procesos para el control y gestión en el restaurante? En la entrevista se determinó que si es necesario y de gran ayuda porque así la administradora no realizaría los procesos manualmente de cada uno de los clientes y optimizaría el tiempo de atención y recursos físicos. ¿Cuáles son los problemas que tiene al realizar los procesos manualmente? La administradora tenía algunos problemas al realizar cada uno de los diferentes procesos para la gestión del restaurante, los cuales se detallan a continuación: •

Pérdida de tiempo al realizar la búsqueda de los clientes

•

El registro no era confiable porque se podían confundir los clientes al momento

de firmar en la casilla correspondiente. •

Al momento de realizar el control mensual del consumo de cada cliente existía

la posibilidad de que haya error al realizar los cálculos. •

Consumo de recursos físicos.

¿Qué beneficios encuentra con la implementación del sistema web? Con la implementación del sistema la administradora tuvo el control de todos los procesos que se realizan en el restaurante y ya no los ejecutaba manualmente, además los clientes interactuarán con una interfaz que les facilitará la elección de sus pedidos. Los beneficios fueron los siguientes: •

La facilidad de búsqueda de los clientes.

•

Registro eficiente de los clientes.

•

Ver el reporte de alimentación en general o de cada cliente para la entrega física

o envió por correo para el departamento de contabilidad para realizar los respectivos descuentos en los roles de pago o para enviar a las cuentas personales de correo de cada uno de ellos. •

Ver el reporte de alimentación de cada cliente para la entrega física o envió por

correo a sus cuentas personales. •

Reducción de recursos físicos.

¿Cómo se manejan los procesos antes mencionados? La administradora buscaba el nombre del cliente en un listado separado por áreas y después le hacía firmar y le entregaba un ticket para hacer el pedido de alimentación. 5.1.1.1.1. Discusión de la entrevista realizada a la administradora del restaurante de CONCLISAN CIA. LTDA. Al realizar la entrevista a la Lic. Johana Dueñas, quien facilitó la información necesaria para determinar la problemática que existía por la realización manual de todos los procesos,

por lo tanto, se concluyó que la implementación del sistema web es de vital importancia para llevar el control de los mismos, optimizando así recursos y tiempo Entrevista realizada a la directora del área de sistemas de CONCLISAN CIA. LTDA. El resultado obtenido mediante el levantamiento de información de la entrevista (Ver Anexo 2) realiza a la jefa del área de sistemas en CONCLISAN CIA. LTDA fue lo siguiente: ¿Cree usted que sea necesario implementar un sistema web en el área del restaurante que ayude a mejorar el control del servicio de pedidos para los clientes? La respuesta que se obtuvo fue que, si era necesaria la implementación de un sistema, ya que les facilitaría la manera llevar los pedidos en un entorno tecnológico y no manual, evitando así errores en el registro de los pedidos y optimizando el tiempo de espera de los clientes. ¿En qué condición se encuentra la administradora para utilizar un sistema web? La respuesta fue que la administradora estaba capacitada y tenía experiencia en la utilización de sistemas, ya que anteriormente ha trabajado en el restaurante con una aplicación de escritorio para el registro de los clientes. ¿Estaría de acuerdo en facilitar los recursos tecnológicos para el desarrollo de un sistema web? Al realizar la pregunta a la directora fue afirmativa, estaban prestos a brindar todos los requerimientos necesarios en hardware y software para que el sistema se implemente en el restaurante. 5.1.1.2.1. Discusión de la entrevista realizada a la directora del área de sistemas de CONCLISAN CIA. LTDA. Al realizar la entrevista a la Ing. Diana Laica quien facilitó la información necesaria donde se concluyó que existían todos los recursos tecnológicos necesarios para desarrollar el sistema web, el mismo que es manejado por la administradora del restaurante, la cual estaba capacitada y tenía experiencia trabajando con aplicaciones de escritorio

Encuesta realizada al personal de CONCLISAN CIA. LTDA. La encuesta (Ver Anexo 3) fue aplicada al personal que utiliza el servicio de restaurante de CONCLISAN CIA. LTDA a 93 personas que participan en el proceso de registro de pedidos. Pregunta # 1. ¿Cree usted que sea indispensable implementar un sistema web para mejorar el control de los pedidos del restaurante de CONCLISAN CIA LTDA? Tabla 3 Necesidad de un sistema web para la gestión del restaurante ALTERNATIVA

FRECUENCIA

PORCENTAJE

SÍ

91,40%

8,60%

TOTAL

100%

Nota: Investigación de campo.

¿Cree usted que sea necesario implementar un sistema web que ayude a mejorar el control del registro de los pedidos del restaurante de CONCLISAN CIA LTDA? 8,60%

91,40%

SÍ

Figura 8. Porcentaje de la pregunta 1 de la encuesta al personal. Adaptado de investigación de campo.

Análisis: De acuerdo a los resultados obtenidos en la primera pregunta el 91,40% de los encuestados considera que si es necesario un sistema para mejorar el control del registro de los pedidos en el restaurante de CONCLISAN CIA. LTDA mientras que el 8,60% no está de acuerdo.

Pregunta #2. ¿Está usted en condiciones de desenvolverse sin inconvenientes en la utilización de un sistema informático? Tabla 4 Utilización de un sistema informático ALTERNATIVA

FRECUENCIA

PORCENTAJE

SÍ

92,47%

7,53 %

TOTAL

100%

Nota: Investigación de campo.

¿Está usted en condiciones de desenvolverse sin inconvenientes en la utilización de un sistema informático? 7,53%

92,47%

SÍ

Figura 9. Porcentaje de la pregunta 2 de la encuesta realizada al personal. Adaptado de investigación de campo.

Análisis: De acuerdo a los resultados obtenidos en la segunda pregunta el 92,47% de los encuestados estan en condiciones de manejar un sistema informático sin problema alguno y el 7,53% tiene dificultades en la utilización del mismo.

Pregunta #3. ¿Cree usted que se realiza un buen control en el proceso del registro de pedidos del cliente en el área del restaurante? Tabla 5 Control en el proceso del registro de pedidos ALTERNATIVA

FRECUENCIA

PORCENTAJE

SÍ

10, 75%

89,25%

TOTAL

100%

Nota: Investigación de campo.

¿Cree usted que se realiza un buen control en el proceso del registro de pedidos del cliente en el área del restaurante? 10,75%

89,25%

SÍ

Figura 10. Porcentaje de la pregunta 3 de la encuesta realizada al personal. Adatado de investigación de campo.

Analisis: De acuerdo a los resultados obtenidos en la tercera pregunta el 89,25% de los encuestados no consideran que se realiza un buen control en el proceso del registro de pedidos mientras que el 10,75% esta de acuerdo con el trabajo realizado por la admisitradora.

Pregunta #4. ¿Considera usted que en el servicio del restaurante se realiza un proceso que tarda un tiempo considerable desde el registro del cliente hasta la entrega del pedido? Tabla 6 Tiempo en el registro del pedido ALTERNATIVA

FRECUENCIA

PORCENTAJE

SÍ

12,90%

87,10%

TOTAL

100%

Nota: Investigación de campo.

¿Considera usted que en el servicio del restaurante se realiza un proceso que tarda un tiempo considerable desde el registro del cliente hasta la entrega del pedido? 12,90%

87,10%

SÍ

Figura 11. Porcentaje de la pregunta 4 de la encuesta realizada al personal. Adaptado de investigación de campo.

Analisis: De acuerdo a los resultados obtenidos en la cuarta pregunta el 87,10% de los encuestados consideran que el proceso que se realiza en el restaurante para el registro de pedidos tarda un tiempo considerable y el 12,90% esta satisfecho con el tiempo de espera para la entrega del pedido.

Pregunta #5. ¿Considera usted que implementando un sistema web para el control de los pedidos se pueda disminuir el tiempo de espera para los clientes? Tabla 7 Reducción del tiempo en el registro del pedido ALTERNATIVA

FRECUENCIA

PORCENTAJE

SÍ

87,10%

12,90%

TOTAL

100%

Nota: Investigación de campo.

¿Considera usted que implementando un sistema web para el control de los pedidos se pueda disminuir el tiempo de espera para los clientes? 12,90%

87,10%

SÍ

Figura 12. Porcentaje de la pregunta 5 de la encuesta realizada al personal. Adatado de investigación de campo.

Análisis: De acuerdo a los resultados obtenidos en la quinta pregunta el 87,10% de los encuestados consideran que con la implementacion de un sistema web se disminuirá el tiempo de espera para la entrega del pedido mientras que el 12,90% piensa que el tiempo para la entrega del mismo no cambiará.

Pregunta #6. ¿Para usted, qué alternativa amerita la forma de como se lleva el control del registro de pedidos en el restaurante? Tabla 8 Registro de pedidos ALTERNATIVA

FRECUENCIA

PORCENTAJE

Malo

33,33%

Regular

72,46%

Bueno

21,74%

Muy bueno

7,25%

TOTAL

100%

Nota: Investigación de campo.

¿Para usted, qué alternativa amerita la forma de como se lleva el control del registro de pedidos en el restaurante? 7,25% 33,33%

21,74%

72,46%

Malo

Regular

Bueno

Muy bueno

Figura 13. Porcentaje de la pregunta 6 de la encuesta realizada al personal. Adaptado de investigación de campo.

Análisis: De acuerdo a los resultados obtenidos en la sexta pregunta el 72,46% de los encuestados consideran que el control del registro de pedidos en el restaurante es regular, el 33,33% es malo, el 21,74% es bueno y el 7,25% es muy bueno.

Pregunta #7. ¿Considera útil que se le notifique a su cuenta de correo electrónico un reporte personal de su alimentación mensual? Tabla 9 Reporte a cuenta de correo electrónico ALTERNATIVA

FRECUENCIA

PORCENTAJE

SÍ

86,02%

13,98%

TOTAL

100%

Nota: Investigación de campo.

¿Considera útil que se le notifique a su cuenta de correo electrónico un reporte personal de su alimentación mensual? 13,98%

86,02%

SÍ

Figura 14. Porcentaje de la pregunta 7 de la encuesta realizada al personal. Adaptado de investigación de campo.

Analisis: De acuerdo a los resultados obtenidos en la séptima pregunta el 86,02% de los encuestados consideran útil que se le notifique a la cuenta de correo electrónico el reporte personal de su alimentación mensual mientras que el 13,98% no considera útil este servicio.

Pregunta #8. ¿Considera que el uso de las Tecnologías mejora la competitividad y calidad de servicio en el área del restaurante? Tabla 10 Tecnologías para la competitividad y calidad de servicio ALTERNATIVA

FRECUENCIA

PORCENTAJE

SÍ

92,47%

7,53%

TOTAL

100%

Nota: Investigación de campo.

¿Considera que el uso de las Tecnologías mejora la competitividad y calidad de servicio en el área del restaurante? 7,53%

92,47%

SÍ

Figura 15. Porcentaje de la pregunta 8 de la encuesta realizada al personal. Adaptado de investigación de campo.

Análisis: De acuerdo a los resultados obtenidos en la octava pregunta el 92,47% de los encuestados consideran que el uso de las tecnologías si mejorará la competitividad y calidad del servicio en el área del restaurante y el 7,53% no está de acuerdo con el uso de las tecnologías. 5.1.1.3.1. Discusión de la encuesta realizada al personal de CONCLISAN CIA. LTDA Después de haber realizado el respectivo análisis de las encuestas al personal de CONCLISAN CIA.LTDA, se determinó la necesidad de implementar un sistema informático que ayude a mejorar el control y gestión en el servicio de restaurante, automatizando los procesos que se realizaban manualmente, ahorrado recursos y tiempo. Con el desarrollo del

sistema orientado a la web se agilizó dichos procesos que permitieron dar solución a la problemática de la empresa.

Propuesta de Intervención 5.2.1. Metodología de Desarrollo de Software Para seleccionar la metodología adecuada para desarrollar el sistema web se realizó cuadros comparativos con criterios que expongan los beneficios de cada una de ellas de acuerdo a las necesidades que tiene el servicio de restaurante de CONCLISAN CIA. LTDA y se describen a continuación. Comparativa de metodologías tradicionales y ágiles. En las metodologías de desarrollo de software se debe tener varios elementos que son buenas prácticas para lograr los objetivos de la empresa, costes, funcionalidad, sencillez, etc. Para eso se realizó la comparación entre la mejor metodología de desarrollo: tradicional y ágil para integrarla al proyecto se debe tomar una elección de acuerdo a los requerimientos de la empresa, por lo tanto, una mala elección de una metodología inadecuada puede conducir a que el proyecto sea o no exitoso. A continuación, las ventajas que ofrece cada técnica de desarrollo.

43 Tabla 11 Comparativa entre metodologías de desarrollo de software Metodologías de desarrollo de software Metodologías tradicionales

Metodologías ágiles

Se necesita una especificación precisa de los requerimientos del software.

Los requerimientos van cambiando conforme se avanza en el desarrollo del software.

El usuario final interactúa con el equipo de desarrollo solo en reuniones establecidas.

El usuario final desarrolladores.

Reuniones formales con documentos escritos.

Minimiza documentación comunicaciones informales.

Se utiliza para el desarrollo de grandes proyectos.

Se utiliza para pequeñas y medianos proyectos.

Se utiliza grandes grupos de trabajo.

Se utiliza pequeños grupos de trabajo.

Mayor control de procesos.

Procesos menos controlados.

Utiliza procesos predictivos.

Utiliza procesos adaptivos.

No se adaptan adecuadamente a cambios.

Está preparada para adaptarse a cambios.

Existe un contrato prefijado.

El contrato es flexible a cambios.

parte

del

con

equipo

uso

Nota: Fuente: Álvarez, A., De las Heras del Dedo, R., & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: Anaya.; Brito, K., Sosa, D., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. San Bernardino, CA: Académica Española.

Es muy importante elegir una excelente metodología para obtener éxito en el proyecto, por ende, se analizó las características de las metodologías tradicionales y ágiles, obteniendo como resultado a realizar el sistema web con una metodología ágil porque otorga la adaptación de cambios en los requerimientos y permite tener una forma de trabajo fluida frente a estos cambios. Elección de modelos ágiles. La elección del modelo ágil se realizó mediante una comparativa entre XP Y SCRUM cada uno de estos modelos fueron valorados y se seleccionó al que tuvo mayor número de puntuación. A continuación, se detalla algunas características para determinar que modelo es el más óptimo dándole una puntuación de uno (1) para el modelo de desarrollo ágil que si cumpla y cero (o) para el que no cumpla.

44 Tabla 12 Elección de modelos ágiles Características

SCRUM

Mayor flexibilidad en las iteraciones Buenas prácticas de desarrollo Colaboración Respeto de las fechas de entrega El grado de interacción con el cliente Simplicidad

1 1 1 0 1 1

0 0 1 1 1 1

TOTAL

En los resultados se observó que al puntuar a XP y SCRUM se obtuvo más puntuación hacia el modelo ágil XP por ser la más óptima para el desarrollo del sistema web, en este caso XP se contó con 5 puntos sobre las características que sí cumplió frente a SRUM que le corresponde 4 puntos sobre las características cumplidas. 5.2.2. Desarrollo del software utilizando la metodología XP. El software se desarrolló en base a las diferentes etapas de la metodología XP y se detalla a continuación: Planeación. En esta fase, en base a las Historias de Usuario la administradora estableció la prioridad de cada una de ellas, y correspondientemente, se realizó una estimación del esfuerzo necesario de estas. 5.2.2.1.1. Exploración. En esta fase, la administradora dió todos los requerimientos necesarios, los cuales se plasmaron en las historias de usuario que fueron de interés para la primera entrega del producto. Al mismo tiempo se conoció las herramientas, tecnologías y prácticas que se utilizarían en el proyecto. Esta fase se la ha realizado en conjunto con el cliente para conocer y comprender de mejor manera el modelo del negocio y los procesos involucrados en el mismo. 5.2.2.1.1.1. Historias de usuario. Las historias de usuario han sido la base para la ejecución del presente proyecto

empleando metodologia XP, estas permitieron especificar las funcionalidades necesarias para el desarrollo del producto software mediante el empleo de tarjetas en donde se describe las particularidades que el sistema debe tener. La identificación de las historias de usuario dependió de la futura complejidad de la funcionalidad del sistema y fueron divididas en tareas de ingenierias en el plan de entregas para ser desarrolladas durante las iteraciones. 5.2.2.1.1.2. Valoración de las historias de usuario. Para la valoración de las historias de usuario se procedió a estimar haciendo uso de la serie Fibonacci, la cual consiste en dar una estimación (valor) a la complejidad de la historia. Como es bien conocido, la serie Fibonacci es una sucesion infinita de números naturales, pero para el presente caso se procedió a acotarla en la sucesion 1,2,3,5,8,13,21. Es de este modo que se dividió en tres la serie acotada identificando la complejidad como Alta, Media, Baja, quedando de la siguiente forma: 1,2,3 es complejidad Baja; 5,8,13 es complejidad Media; 21 es complejidad Alta. A continuación, se detalla una plantilla de Historia de Usuario utilizada en el proyecto con una descripción de sus elementos.

Figura 16. Plantilla Historia de Usuario. Adaptado de investigación de campo.

La especificacion de todas las Historias de Usuario que se han utilizado para el desarrollo del sistema se encuentran en el (Ver Anexo 4) del presente documento.

5.2.2.1.2. Plan de publicaciones (release planning). En cuanto al plan de entrega, éste especifica cuales son las de historias de usuario que se implementarán en una determinada release o entrega del sistema previamente planificada. El Plan de entrega, que por lo general no varía, es un artefacto que guia el desarrollo del producto de forma global, y sirve de base para la creación del plan de iteraciones que guía el proceso de forma más específica. En base a ello, durante la reunión de planificación se determina realizar cinco entregas con una duración de 3 semanas cada una, desplegando uno o varios módulos de acuerdo al avance del equipo. A continuación, se expone el plan de entrega con las historias agrupadas en iteraciones: Tabla 13 Plan de Entrega PLAN DE ENTREGAS Módulo

Historia de Usuario

Prioridad de Negocio

Duración 1

Autenticación Dispositivos Clientes

Horarios Menús Cartas Pedidos

Reportes Parámetros

Acceso al Sistema Registro de Dispositivos biométricos Edición de Dispositivos Biométricos Registro de clientes Registro de Huellas Dactilares Búsqueda de Clientes Edición de clientes Registro de Horarios Edición de horarios Registro de menús Búsqueda de menús Edición de menús Visualización de las cartas Activación de las cartas Búsqueda de cartas Acceso al panel de pedidos públicos Registro automático de pedidos (principal) Registro de pedidos (secundario) Visualización de pedidos Imprimir comprobante de pedido Reporte de alimentación Envío de los reportes de alimentación Parámetros del reporte

Alta Alta Alta Alta Alta Alta Alta Alta Alta Media Media Media Media Media Media Media Media Media Media Media Baja Baja Baja

Nota: Última versión del Plan de Entrega. Fuente: Investigación de campo.

3 Semanas 3 Semanas 3 Semanas

3 Semanas

2.2 semanas

Entrega Planificada 2 3 4

                      

5.2.2.1.3. Plan de iteraciones (iteration planning) Consiste en el nรบmero de iteraciones que se realizarรกn durante el desarrollo del sistema, se lo hace en base a un plan de entrega definido anteriormente. Se considera que en cada iteraciรณn disminuye el trabajo por completar gracias a cada incremento verificado y testeado. Se definen cuantas historias de usuario se realizarรกn en cada iteraciรณn programada. Para el desarrollo del producto se dividiรณ el trabajo en cinco iteraciones, agrupando varios mรณdulos en determinadas iteraciones. Las primeras cuatro iteraciรณnes poseen una duraciรณn de 15 dias (3 semanas) y la ultima iteraciรณn se desarrollรณ en 11 dias (2.2 semanas). La velocidad de desarrollo fue de 55 puntos por iteraciรณn aprรณximadamente.

2-3

4-5-6-7

8-9

10-11-12

13-14-15

16-17-18 19-20

Dispositivos

Clientes

Horarios

Menús

Cartas

Pedidos

Funcionalidad HU ∑ Estimación

Autenticación

Módulo

Tabla 14 Plan de Iteraciones

Análisis general de la base de datos y sus componentes Crear el modelo_usuarios.php Crear la interfaz de login empleando Bootstrap (HTML y CSS) Validar funcionalidades de la interfaz con jQuery Crear el controlador_usuarios.php Análisis general de la base de datos y sus componentes Crear el modelo_dispositivos.php Crear vista_dispositivos.php usando Bootstrap (HTML y CSS) Validar funcionalidades de la interfaz con jQuery Crear el controlador_dispositivos.php Análisis general de la base de datos y sus componentes Crear el modelo_clientes.php Crear vista_clientes.php usando Bootstrap (HTML y CSS) Validar funcionalidades de la interfaz con jQuery Crear el controlador_clientes.php Análisis general de la base de datos y sus componentes Crear el modelo_horarios.php Crear la vista_horarios.php con Bootstrap (HTML y CSS) Validar las funcionalidades de la interfaz con jQuery Crear el controlador_horarios.php Análisis general de la base de datos y sus componentes Crear el modelo_menus.php Crear la vista_menus.php con Bootstrap (HTML y CSS) Validar las funcionalidades de la interfaz con jQuery Crear el controlador_menus.php Análisis general de la base de datos y sus componentes Crear el modelo_cartas.php Crear la vista_cartas.php con Bootstrap (HTML y CSS) Validar las funcionalidades de la interfaz con jQuery Crear el controlador_cartas.php Análisis general de la base de datos y sus componentes Crear el modelo_pedidos.php Crear la vista_pedidos.php con Bootstrap (HTML y CSS)

PLAN DE ITERACIONES Tareas de Ingeniería Descripción 6 7 3 3 2 7 10 8 5 4 10 20 12 8 5 5 8 3 3 2 6 9 4 4 3 2 3 1 3 2 10 20 12

Estimación

Jimmy Quiguango Fernanda Almache

Responsable                              

  

Iteración Asignada 1 2 3 4 5

Parámetros

8 5 8 12 6 5 3 2 2 2 1 1

Jimmy Quiguango Fernanda Almache

Nota: HU= Historia de Usuario; ∑ Estimación= sumatoria total de la estimación de cada una de las historias de usuario involucradas en el módulo. Fuente: Investigación de campo.

21-22

Reportes

Validar las funcionalidades de la interfaz con jQuery Crear el controlador_pedidos.php Análisis general de la base de datos y sus componentes Crear el modelo_reportes.php Crear la vista_reportes.php con Bootstrap (HTML y CSS) Validar las funcionalidades de la interfaz con jQuery Crear el controlador_reportes.php Análisis general de la base de datos y sus componentes Crear el modelo_parametros.php Crear la vista_parametros.php con Bootstrap (HTML y CSS) Validar las funcionalidades de la interfaz con jQuery Crear el controlador_parametros.php            

Diseño. La metodología XP toma como requerimiento base la utilización de las tarjetas CRC, para describir las responsabilidades de los usuarios en base a las clases desarrolladas, para el diseño de la base de datos, como lo es el diseño del modelo conceptual, modelo físico y del sistema en su totalidad. En la fase de diseño se obtuvo como producto resultante la base de datos funcional del sistema; script de creación de base de datos, tablas, funciones, procedimientos almacenados (stored procedure). El objetivo de realizar esta tarea fue obtener las responsabilidades que va a ejecutar cada entidad o clases colaboradoras. 5.2.2.2.1. Tarjetas crc. La utilización de tarjetas CRC (Class-Responsibility-Collaboration) es una técnica de diseño orientado a objetos propuesta por Kent Beck. Con el objetivo de tener las clases que se van utilizar para implementar el sistema y la forma en que van a interactuar para facilitar el análisis y diseño de las mismas por parte de los desarrolladores, con cada una de sus funcionalidades, responsabilidades y clases colaboradoras. A continuación, se detallan cada una. 5.2.2.2.1.1. Especificación de las tarjetas crc. Tabla 15 Tarjeta CRC - Clientes Tarjeta CRC Número: 1

Clase: ClassCliente

Responsabilidades:

Colaboradores

Ingresar cliente Actualizar cliente Enrolar cliente Consultar cliente

ClassConexion

Nota: Fuente: Investigación de campo.

51 Tabla 16 Tarjeta CRC - Dispositivos Tarjeta CRC Número: 2

Clase: ClassDispositivo:

Responsabilidades:

Colaboradores

Ingresar dispositivo

ClassConexion

Editar dispositivo Nota: Fuente: Investigación de campo.

Tabla 17 Tarjeta CRC - Pedidos Tarjeta CRC Numero: 3

Clase: ClassPedido

Responsabilidades:

Colaboradores:

Ingresar pedidos

ClassConexion

Búsqueda de pedidos

ClassCliente

Visualización de pedidos

ClassHorario

Imprimir pedidos

ClassMenu ClassCarta

Nota: Fuente: Investigación de campo.

Tabla 18 Tarjeta CRC - Usuario Tarjeta CRC Numero: 4

Clase: ClassUsuario

Responsabilidades:

Colaboradores:

Validar Usuario Verificar Login Verificar sesión

ClassConexion

Cargar módulos Nota: Fuente: Investigación de campo.

Tabla 19 Tarjeta CRC - Horario Tarjeta CRC Número: 5

Clase: ClassHorario

Responsabilidades:

Colaboradores:

Ingresar horarios

ClassConexion

Editar horarios Búsqueda de horarios Nota: Fuente: Investigación de campo.

52 Tabla 20 Tarjeta CRC - Menús Tarjeta CRC Número: 6

Clase: ClassMenu

Responsabilidades:

Colaboradores:

Ingresar menús

ClassConexion

Editar menús Búsqueda de menús Nota: Fuente: Investigación de campo.

Tabla 21 Tarjeta CRC - Reportes Tarjeta CRC Número: 7

Clase: ClassReporte

Responsabilidades:

Colaboradores:

Visualización de reportes

ClassConexion

Procesar reportes

ClassCliente

Nota: Fuente: Investigación de campo.

Tabla 22 Tarjeta CRC - Cartas Tarjeta CRC Número: 8

Clase: ClassCarta

Responsabilidades: Modificar cartas

Colaboradores: ClassConexion

Búsqueda de cartas

ClassHorario

Activar cartas

ClassMenu

Nota: Fuente: Investigación de campo.

Tabla 23 Tarjeta CRC - Parámetros Tarjeta CRC Número: 9

Clase: ClassParametro

Responsabilidades:

Colaboradores:

Ingresar parámetros

ClassConexion ClassReporte

Nota: Fuente: Investigación de campo.

5.2.2.2.2. Diseño de la base de datos. Para la construcción de la base de datos, la empresa en cuestion proporcionó algunas tablas de su base de datos CLISAN, las cuales fueron fundamentales para la creación de la base de datos del sistema web, a partir de ahí se crearon nuevas tablas para relacionarlas y realizar el diseño de la misma. A continuación se presenta el diseño de la base de datos realizada con el apoyo de las historias de usuario y a los requerimientos descritos en las entrevistas.

5.2.2.2.2.1. DiseĂąo lĂłgico de la base de datos.

Figura 17. Modelo lĂłgico de la base de datos del sistema.

5.2.2.2.3. Diccionario de datos. EL objetivo del diccionario de datos (Ver Anexo 5) es, presentar un listado organizado de todas las entidades del sistema, con sus respectivos detalles como el nombre de la tabla, tipo de claves, tipo de datos y contenido de entidades. Sirve de guía para que el analista pueda entender todo el flujo de entrada, salida y cálculos que se realicen. script de la base de datos. 5.2.2.2.4. Script de la base de datos. El script de base de datos (Ver Documentos Complementarios en el CD-Script de la Base de Datos) es un archivo generalmente con extensión .sql, tiene las instrucciones de código del lenguaje SQL que llevan a la creación de una base de datos completa. En este archivo adicional del modelado de la base de datos es en donde se encuentran las creaciones de tablas, relaciones, procedimientos y funciones. 5.2.2.2.5. Diseño de interfaces. El diseño de las interfaces de usuario son el medio con que el usuario se comunica con el equipo, estas deben ser amigables e intuitivas para no tener futuros inconvenientes. Facilitan el trabajo del desarrollador porque dan una vista de cómo quedaría el sistema para que interactúe con el usuario final. A continuación, se muestran las capturas de las interfaces más representativas del sistema web RESAN. 5.2.2.2.5.1. Interfaz de usuario para la administradora. 

Figura 18. Diseño de Interfaz de ingreso al sistema.



Página principal

Figura 19. Diseño de interfaz de vista principal.



Módulo clientes

Figura 20. Diseño de interfaz del módulo clientes.



Módulo Dispositivos

Figura 21. Diseño de interfaz del módulo dispositivos.



Módulos pedidos

Figura 22. Diseño de interfaz del módulo pedidos.



Módulos horarios

Figura 23. Diseño de interfaz del módulo horarios.



Módulo menús

Figura 24. Diseño de interfaz del módulo de menús.



Módulo de reportes

Figura 25. Diseño de interfaz del módulo de reportes.



Módulo de parámetros

Figura 26. Diseño de interfaz del módulo de parámetros.



Módulo de cartas

Figura 27. Diseño de menús del módulo de cartas.

5.2.2.2.5.2. Interfaz de usuario para los clientes. 

Figura 28. Diseño de interfaz de Login de usuario.



Pedidos

Figura 29. Diseño de interfaz del módulo pedidos.

Codificación. La fase de la codificación es en donde se escribe el código de todas las funcionalidades del sistema, se procedió a realizar la codificación analizando los requerimientos especificados en las historias de usuarios por parte de la administradora del restaurante. La codificación aquí se comprende tanto a nivel de base de datos como reglas del negocio. A continuación se presenta la codificación de los puntos más importantes del sistema RESAN:



Conexión a la base de datos

Figura 30. Codificación de la conexión a la base de datos.



Codificación de los clientes

Figura 31. Codificación de la clase clientes.

5.2.2.3.1. Codificación de las interfaces de usuario. 

Figura 32. Interfaz de ingreso al sistema web.

Figura 33. Codificación del Login de usuario para el administrador.



Interfaz de la página principal

Figura 34. Interfaz de la página principal.

Figura 35. Codificación de la interfaz principal.

Pruebas. En esta fase fue necesario realizar pruebas adicionales para la comprobacion de rendimiento y la toma de decisiones para la integracion de nuevos requerimientos sobre la

iteración actual, para esto se realizaron junto con la administradora del restaurante, las mismas que garantizaron la funcionalidad del sistema reduciendo el número de errores no detectados. XP divide las pruebas del sistema en dos grupos que se describe a continuación: 5.2.2.4.1. Pruebas unitarias. Las pruebas unitarias fueron las encargadas de verificar el código y realizadas por los desarrolladores conforme se iba avanzando en la codificación de las funcionalidades del sistema, estas aseguraron que un determinado módulo cumpliera con un comportamiento esperado en forma aislada antes de haberlo integrado al sistema.

Figura 36. Ejemplo de prueba unitaria realizada a la clase Cliente.

5.2.2.4.2. Pruebas de aceptación. Las pruebas de aceptación o funcionales fueron las encargadas de evaluar si al terminar cada iteración se cumplía con la funcionalidad asignada por la administradora. Por lo tanto los desarrolladores tenían conocimiento de lo que faltaba por hacer en cada iteración antes de ser aceptado por el cliente. En total se han realizado ocho pruebas de aceptación (agrupadas por moódulos) y se detallan en el apartado de anexos (Ver Anexo 6). 5.2.2.4.3. Finalización. Conocido también como muerte del proyecto, aquí el usuario ya no especifica más historias para ser agregadas en el sistema y el software se ha terminado en su totalidad satisfactoriamente. Como documentación entregable de la finalización del proyecto se generó el manual de usuario (Ver anexo 7) y el manual de instalación (Ver anexo 8) como guía para un correcto uso y entendimiento del sistema.

Independientemente de la entrega de los manuales del proyecto, se dió una capacitación a la administradora del restaurante y al personal de CONCLISAN CIA. LTDA, la misma que fue supervisada por la directora del área de sistemas.

Análisis del impacto Los impactos indican si los resultados en el entorno fueron los deseados en un proyecto, estos pueden ser positivos o negativos y se producen en términos de factores económicos, culturales, sociales, educativos, ambientales, tecnológicos, etc. El análisis de los impactos se lo puede realizar de dos maneras: 

Prospectiva: se lo realiza cuando el proyecto aún no ha sido puesto en marcha.



Retrospectiva: se lo realiza cuando el proyecto ya ha sido puesto en marcha.

En el presente proyecto se realizó de manera retrospectiva. Para realizar el análisis de los impactos, se utilizó la siguiente matriz. Tabla 24 Tabla de Impactos Nivel de impacto

Descripción del nivel de impacto

-3

Impacto alto negativo

-2

Impacto medio negativo

-1

Impacto bajo negativo

No hay impacto

Impacto bajo positivo

Impacto medio positivo

Impacto alto positivo

Nota: Adaptado de “Metodología para el trabajo de grado: Tesis y Proyectos” por M.A. Posso, 2009, Ibarra, p196.

Para el cálculo de los niveles de impacto se utilizó la siguiente fórmula: Nivel de impacto= Σ de los niveles de impacto / Número de indicadores de impacto

5.3.1. Impacto tecnolĂłgico. Tabla 25 Impacto tecnolĂłgico Nivel de impacto

-3

-2

-1

Indicadores x

Impulso tecnolĂłgico

Integridad de la informaciĂłn -

Total

â&#x2C6;&#x2018;=2+3=5

Sumatoria â&#x2C6;&#x2018; Total Resultado de FĂłrmula

đ?&#x2018; đ??ź =

5 = 2.5 2

Impacto alto positivo

Resultado Nota: InvestigaciĂłn de campo.

AnĂĄlisis El impulso tecnologico es elemental en toda institucion pĂşblica o privada por lo tanto la utilizaciĂłn de las nuevas herramientas tecnolĂłgicas mejoran el rendimiento de las actividades diarias realizadas por las empresas. La informaciĂłn manejada por la administradora del restaurante debe garantizar la integridad de la misma para asĂ mantener los datos reales, como fueron generados y libres de alteraciones por terceros. 5.3.2. Impacto econĂłmico. Tabla 26 Impacto econĂłmico Nivel de impacto

-3

-2

-1

Indicadores x

Recursos fĂsicos x

Ingreso econĂłmico Total Sumatoria â&#x2C6;&#x2018; Total Resultado de FĂłrmula Resultado Nota: InvestigaciĂłn de campo.

â&#x2C6;&#x2018;=2+3=5 đ?&#x2018; đ??ź =

5 = 2.5 2

Impacto alto positivo

AnĂĄlisis Con la implementacion del sistema, a largo plazo se ahorrarĂĄ en recursos fisicos (papel, esferogrĂĄficos, carpetas, etc) lo cual reducirĂĄ costos beneficiando al restaurante. Existe un mayor ingreso econĂłmico ya que se disminuye el tiempo en pedido debido a la utilizacion del sistema, por lo que el personal ya no consume en otros restaurantes cercanos. 5.3.3. Impacto ambiental. Tabla 27 Impacto ambiental Nivel de impacto

-3

-2

-1

Indicadores x

UtilizaciĂłn de papel

Materiales de oficina -

Total Sumatoria â&#x2C6;&#x2018; Total Resultado de FĂłrmula Resultado

â&#x2C6;&#x2018;=2+3=5 đ?&#x2018; đ??ź =

5 = 2.5 2

Impacto alto positivo

Nota: InvestigaciĂłn de campo.

AnĂĄlisis Con la implementaciĂłn del sistema se logra tener la informacion de manera digital, ahorrando asi el uso del papel, ayudando a conservar el medio ambiente. Se disminuye la utilizaciĂłn de los materiales de oficina como esferogrĂĄficos, correctores, carpetas, etc., debido a la automatizaciĂłn de los procesos permitiendo tener asĂ los resultados de forma digital.

5.3.4. Impacto general. Tabla 28 Impacto general Nivel de impacto

-3

-2

-1

Indicadores Impacto TecnolĂłgico

Impacto EconĂłmico

Impacto Ambiental

x -

Total

â&#x2C6;&#x2018; =9

Sumatoria â&#x2C6;&#x2018; Total Resultado de FĂłrmula Resultado

đ?&#x2018; đ??ź =

9 =3 3

Impacto alto positivo

Fuente: InvestigaciĂłn de campo.

AnĂĄlisis La implementacion del sistema en el restaurante de CONCLISAN CIA LTDA, generĂł un impacto alto positivo, el cual contribuye al progreso econĂłmico, ambiental y tecnolĂłgico de la misma. Con la automatizacion de los procesos se mejora el control en el registro de los pedidos, disminuyendo el tiempo y recursos brindando un servicio eficaz para los clientes. Como constancia se firma la carta de impacto (Ver Anexo 10).

Conclusiones Con la implementación del sistema web se automatizó eficazmente los procesos de gestión que se realizaban manualmente en el servicio de restaurante de CONCLISAN CIA. LTDA, esto se pudo demostrar debido a las pruebas realizadas en la fase cuatro de la metodología XP. Para realizar un proyecto es necesario seleccionar la metodología a utilizar, analizando todas sus caracteristicas con el fin de escoger la idónea para el desarrollo de software obteniendo así una forma más eficiente en su elaboración como también el ahorro de tiempo y recursos La metodología de desarrollo de software seleccionada XP al ser ágil fue adecuada para la elaboración del sistema porque permitió planificar, diseñar, realizar pruebas para construir un software a la medida, de acuerdo a los requerimientos dados por parte de la administradora del restaurante, ajustándose a cambios imprevistos conforme se avanzaba en el desarrollo del mismo. Se determinaron los requerimientos tecnológicos para el desarrollo del sistema web de acuerdo a las necesidades del cliente, experiencia de los programadores y con los recursos que contaba CONCLISAN CIA. LTDA. Con la elaboración del manual de usuario y las capacitaciones a la administradora y al personal, se dio a conocer las funcionalidades del sistema web, como por ejemplo los distintos procesos que se realizaban en los módulos.

Recomendaciones Desarrollar un módulo de administración (permisos, perfiles y usuarios) para que la administradora pueda controlar desde el sistema web dicho módulo, el cual es actualmente manejado únicamente por el departamento de sistema como política de seguridad. Hacer un correcto levantamiento de información respecto a los procesos que se realizan en el área del restaurante para tener una visión clara y diseñar sin problemas la lógica del negocio para posterior realizar la respectiva codificación de la misma. Seleccionar herramientas de desarrollo de software de acuerdo a los requerimientos específicos por parte de la institución, teniendo en cuenta diversos aspectos como su eficiencia, simplicidad y costo. Para un adecuado manejo o inquietudes del funcionamiento del sistema web, el personal nuevo deberá hacer uso del manual de usuario para conocer los diferentes procesos que se realizan. Dar capacitaciones al personal de la institución y entregar el manual de usuario e instalación para que puedan resolver problemas a futuro con el correcto funcionamiento del sistema web.

REFERENCIAS Álvarez, A., De las Heras del Dedo, R., & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: Anaya. Benavides, E. (2011). Desarrollo de un sistema de administración academica para la escuela “cristobal colon” bajo plataforma web (tesis de maestria). Obtenido de http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf Bernal, C. (2010). Metodología de la Investigación. Colombia: Pearson Educación. Bootsrap. (Abril de 2015). Bootstrap. Obtenido de http://getbootstrap.com/ Brito, K., Sosa, D., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. San Bernardino, CA: Académica Española. Camarena, j., Espinosa, A., Reyes, M., & López, M. (2012). Automatización de la codifcación del patrón modelo vista controlador (MVC)en proyectos orientados a la Web. Ciencia Ergo Sum, 9, 239-250. Coronel, C., Morris, S., & Rob, P. (2011). Bases de Datos, Diseño, Implementación y Administración. Mexco, D.F.: Cengage Learning Editores, S.A. Date, C. J. (2012). Introduccion a los sitemas de base de datos | https://books.google.com.ec. Obtenido de https://books.google.com.ec/books?id=Vhum351TK8C&printsec=frontcover&dq=base+de+datos&hl=es&sa=X&ved=0ahUKEwjzwNK fjMXRAhXB6iYKHWjbDFIQ6AEIITAA#v=onepage&q=base%20de%20datos&f=f alse ELSI Post Technology. (s.f.). DigitalPersona U ARE U 4500. Obtenido de http://www.elsi.es/lectores-de-huella/digital-persona-u-are-u-4500-ref275.html FingerSpot. (2014). FingerSpot. Obtenido de https://www.flexcodesdk.com/ García, J. (2014). Contabilidad de Costos. México: McGRAW-HILL/INTERAMERICANA EDITORES, S.A. DE C.V. Github. (2017). Github. Obtenido de https://github.com/puikinsh/gentelella Gómez López, J., Villar Fernández, E., & Alcayde García, A. (2011). Diseño y creación de portales WEB. Colombia, Bogotá: StarBook. Guardati, S. (2014). Estructura de datos orientada a objetos: Algoritmos con C++. México: Pearson. jQuery. (28 de 06 de 2017). jQuery write less, do more. Obtenido de http://blog.jquery.com/

Lana, R. A. (Junio de 2012). La Administración Estratégica como Herramienta de Gestión. Revista Científica "Visión de Futuro". Obtenido de http://www.redalyc.org/articulo.oa?id=357935469001 López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & de Castro, V. (2014). Desarrollo Web en Entorno Servidor. Madrid, España: RA-MA. Obtenido de https://ebookcentral.proquest.com Marchionni, E. (2011). Administrador de servidores. Obtenido de https://clasesdeseguridadinformatica.files.wordpress.com/2014/03/administrador-deservidores.pdf MariaDB. (2017). MARIADB FOUNDATION. Obtenido de https://mariadb.org/blog/ Microsoft. (2016). Microsoft.com. Obtenido de Overview of ASP.NET Core MVC: https://docs.microsoft.com/es-es/aspnet/core/mvc/overview Nevada, V. (2010). Introducción a las Bases de Datos Relacionales. Obtenido de https://books.google.com.ec/books?id=0lUpB1lNUdIC&printsec=frontcover&hl=es& source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false Osorio, J. C., Aguirre, F. M., & Escobar, J. M. (2010). Sistema de seguridad basados en biometría. Scientia Et Technica, 17(46), 98-102. Posso, M. A. (2009). Metodología para el trabajo de grado: Tesis y Proyectos. Ibarra. Pressman, R. (2010). Ingeniería del Software: Un enfoque práctico. México: McGraw-Hill. Ramos, J., Ramos, A., & Montero, F. (2006). Obtenido de https://issuu.com/sgp82/docs/162630262-sistemas-gestores-de-base Rosendo, L., & Greguas, B. (2010). Estándares de Diseño Web. Ciencias de la Información, 41(2), 69-71. Sampieri, Fernández, & Batista. (2010). Metodología de la Investigación. México: McGRAW-HILL. Sommerville, I. (2011). Ingenieria de software. Mexico: Person Educación. Sublime Text. (2016). Sublime Text. Obtenido de https://www.sublimetext.com/

GLOSARIO Apache: Es un servidor web HTTP de código libre utilizado para el desarrollo web. Bootstrap: Es un conjunto de herramientas para el diseño de aplicaciones web de código abierto para desarrollar con HTML, CSS y JS. CSS: El lenguaje CSS se usa para definir el aspecto de todos los contenidos, formato de tablas, separación, color, tamaño, etc. Hojas de Estilo en Cascada (Cascading Style Sheets). DBMS: Es un sistema de administración de bases, es un conjunto de programas encargados del manejo estructural de la base de datos. HTML: Es el lenguaje de marcado predominante para la elaboración de páginas Web, sus siglas HyperText Markup Language. HTTP: Es un protocolo de capa de aplicación para transmitir documentos hipermedia, como HTML. Diseñado para la comunicación entre navegadores web y servidores web. (Protocolo de transferencia de hipertexto). Javascript: Está diseñado específicamente para el desarrollo web, es un lenguaje de scripts, creado para funcionar como complemento de otros lenguajes y aplicaciones. jQuery: Es una biblioteca JavaScript ágil, pequeña y con una gran variedad en funciones, facilita la forma de trabajar con los documentos HTML. PHP: Es el acrónimo Hypertext Preprocessor es un lenguaje de código abierto utilizado para el desarrollo web. XP: La programación extrema (XP), es el enfoque más utilizado del desarrollo de software ágil, además define un grupo de valores que establece el fundamento para todo trabajo elaborado.

ANEXOS Anexo 1. Entrevista realizada a la administradora del restaurante de CONCLISAN CIA. LTDA

1. ¿Cuáles son los procesos que se realizan para la gestión del restaurante?

2. ¿Cree usted que sea necesario implementar un sistema web que ayude a mejorar los procesos para el control y gestión en el restaurante?

3. ¿Cuáles son los problemas que tiene al realizar los procesos manualmente?

4. ¿Qué beneficios encuentra con la implementación del sistema web?

5. ¿Cómo se manejan los procesos antes mencionados?

Anexo 2. Entrevista realizada a la directora del área de sistemas de CONCLISAN CIA. LTDA. 1. ¿Cree usted que sea necesario implementar un sistema web en el área del restaurante que ayude a mejorar el control del servicio de pedidos para los clientes?

2. ¿En qué condición se encuentra la administradora para utilizar un sistema web?

3. ¿Estaría de acuerdo en facilitar los recursos tecnológicos para el desarrollo de un sistema web?

Anexo 3. Encuesta realizada al personal de CONCLISAN CIA. LTDA. Este documento tiene como finalidad reunir información para comprender el nivel de aceptación que tendría el desarrollo de un Sistema Web para la gestión del servicio de restaurante en CONCLISAN CIA. LTDA. Instrucciones: Seleccionar una sola respuesta por pregunta marcando con una X. ¿Cree usted que sea indispensable implementar un sistema web para mejorar la gestión del restaurante de la empresa CONCLISAN CIA LTDA? ¿Está usted en condiciones de desenvolverse sin inconvenientes en la utilización de un sistema informático? ¿Cree usted que se realiza un buen control en el proceso del registro de pedidos del cliente en el área del restaurante? ¿Considera usted que el servicio en el restaurante es un proceso que tarda desde el registro del cliente hasta la entrega del pedido? ¿Considera usted que implementando un sistema web para el control de los pedidos se pueda disminuir el tiempo de espera para los clientes? ¿Para usted, qué alternativa amerita la forma de como se lleva el control del registro de pedidos en el restaurante? ¿Considera útil que se le notifique a su cuenta de correo electrónico un reporte personal de su alimentación mensual? ¿Considera que el uso de las Tecnologías mejora la competitividad y calidad de servicio en el área del restaurante?

Anexo 4. Historias de usuario

Historia de usuario – Acceso al sistema

Historia de Usuario Número: 1

Usuario: Administradora

Nombre historia: Acceso al sistema principal Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 21

Iteración asignada: 1

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO poder ingresar al sistema PARA acceder al menú principal de administración Escenario de prueba: DADO el ingreso correcto de usuario y contraseña CUANDO la administradora haga clic en el botón “Ingresar” ENTONCES el sistema lo redirigirá al menú principal. DADO el ingreso incorrecto de usuario o contraseña CUANDO la administradora haga clic en el botón “Ingresar” ENTONCES el sistema alertará del inconveniente mostrando el mensaje “Información incorrecta”. DADO el ingreso vacío de los campos usuario/contraseña CUANDO la administradora haga clic en el botón “Ingresar” ENTONCES el sistema mostrará un mensaje de alerta solicitando el ingreso de los datos.

78 Historia de usuario – Registro de dispositivos biométricos

Historia de Usuario Número: 2

Usuario: Administradora

Nombre historia: Registro de dispositivos biométricos Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 21

Iteración asignada: 1

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO registrar los dispositivos biométricos de huella dactilar PARA la detección del mismo, llevar un control y brindar mayor seguridad en el sistema. Escenario de prueba: DADO el ingreso completo de los datos del dispositivo en los campos obligatorios del formulario de registro CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará el siguiente mensaje “Guardado, dispositivo creado” confirmando la transacción. DADO el ingreso incompleto o en blanco de los datos del dispositivo en los campos obligatorios del formulario de registro CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará mensajes alertando de los campos que faltan por rellenar. DADO el ingreso completo, incompleto o en blanco de los datos del dispositivo en el formulario de registro CUANDO la administradora haga clic en el botón “Cancelar” ENTONCES el sistema limpiará los campos del formulario y se visualizará la lista de dispositivos registrados.

79 Historia de usuario – Edición de dispositivos Historia de Usuario Número: 3

Usuario: Administradora

Nombre historia: Edición de dispositivos Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 13

Iteración asignada: 1

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO modificar los datos de los dispositivos existentes PARA actualizar la lista de dispositivos Escenario de prueba: DADO la selección de un dispositivo determinado CUANDO la administradora haga clic en el botón “Editar” ENTONCES el sistema presentará una interfaz con la información completa. DADO la modificación de los datos del dispositivo en los campos obligatorios del formulario de edición CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará el siguiente mensaje “Editado, dispositivo editado” confirmando la transacción. DADO el ingreso de datos incompletos o vacíos en el formulario de edición CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema alertará de los errores asociados. DADO la actualización del estado del dispositivo en el formulario de edición CUANDO la administradora pulse sobre la casilla de verificación del estado ENTONCES el sistema procederá a cambiar el estado (activo/inactivo) del dispositivo.

80 Historia de Usuario – Registro de clientes Historia de Usuario Número: 4

Usuario: Administradora

Nombre historia: Registro de clientes Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 21

Iteración asignada: 2

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO registrar los datos informativos del cliente PARA poder asignarlos a la lista de clientes del sistema Escenario de prueba: DADO el ingreso de los datos del cliente en todos los campos obligatorios del formulario de registro CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará el mensaje “Guardado, cliente creado” que confirma la transacción. DADO el ingreso vacío de los campos obligatorios del formulario de ingreso CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema alertará al usuario solicitando el ingreso de los datos correspondientes. DADO el ingreso de los datos del cliente CUANDO la administradora haga clic en el botón “Cancelar” ENTONCES el sistema limpiará los campos del formulario y se visualizará la lista de clientes

81 Historia de usuario – Registro de huellas dactilares

Historia de Usuario Número: 5

Usuario: Administradora

Nombre historia: Registro de huellas dactilares Prioridad en negocio: Alta

Riesgo en desarrollo: Alto

Puntos estimados: 21

Iteración asignada: 2

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO registrar las huellas dactilares de los clientes PARA llevar un control de los mismos y que puedan realizar su pedido de alimentación. Escenario de prueba: DADO el ingreso correcto del cliente CUANDO la administradora del sistema pulse el botón “Enrolar” ENTONCES el sistema presentará la interfaz del equipo biométrico para la captura de huellas dactilares DADO la visualización correcta de la interfaz del equipo biométrico CUANDO la administradora registra de manera correcta cuatro veces la huella dactilar ENTONCES el sistema presentará el mensaje “Guardado, cliente enrolado exitosamente” confirmando la transacción. DADO la visualización correcta de la interfaz del equipo biométrico CUANDO la administradora deja pasar 30 segundos o no registra ninguna huella ENTONCES el sistema presentará el mensaje “Error, tiempo de enrolamiento agotado por favor intente nuevamente”.

82 Historia de usuario – Búsqueda de Clientes

Historia de Usuario Número: 6

Usuario: Administradora

Nombre historia: Búsqueda de Clientes Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 8

Iteración asignada: 2

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO buscar el nombre del cliente PARA acceder fácilmente a ellos y poder realizar operaciones sobre los mismos Escenario de prueba: DADO el ingreso del cliente a buscar en la caja de búsqueda CUANDO la administradora teclee el nombre ENTONCES el sistema automáticamente realizará la búsqueda según los criterios de búsquedas ingresados en la caja de texto DADO el ingreso de clientes inexistentes, números, caracteres especiales o datos erróneos dentro de la caja de búsqueda CUANDO la administradora lo teclee ENTONCES el sistema presentará el mensaje de “No se encontraron resultados”

83 Historia de Usuario – Edición de clientes Historia de Usuario Número: 7

Usuario: Administradora

Nombre historia: Edición de clientes Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 5

Iteración asignada: 2

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO editar los datos de los clientes PARA actualizar la lista de clientes. Escenario de prueba: DADO la selección de un cliente determinado CUANDO la administradora haga clic en el botón “Editar” ENTONCES el sistema presentará la interfaz con la información completa. DADO la modificación de los datos del cliente en los campos obligatorios del formulario de edición CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará el siguiente mensaje “Editado, cliente editado exitosamente” confirmando la transacción. DADO la actualización del estado del cliente en el formulario de edición CUANDO la administradora pulse sobre la casilla de verificación del estado ENTONCES el sistema procederá a cambiar el estado (activo/inactivo) del cliente. DADO el ingreso de datos incompletos o vacíos en el formulario de edición CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema alertará de los errores asociados.

84 Historia de usuario – Registro de horarios

Historia de Usuario Número: 8

Usuario: Administradora

Nombre historia: Registro de horarios Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 13

Iteración asignada: 3

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO registrar los horarios PARA programar las horas de inicio y fin de los desayunos y almuerzos Escenario de prueba: DADO el ingreso de los datos de los horarios en todos los campos obligatorios del formulario de registro CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará el mensaje “Guardado, horario creado” que confirma la transacción. DADO el ingreso de datos en blanco o incompletos en los campos obligatorios del formulario de registro CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema alertará al usuario solicitando el ingreso de los datos correspondientes. DADO el ingreso de datos completos, incompletos o en blanco CUANDO la administradora haga clic en el botón “Cancelar” ENTONCES el sistema limpiará los campos del formulario y se visualizará la lista de horarios creados.

85 Historia de usuario – Edición de horarios

Historia de Usuario Número: 9

Usuario: Administradora

Nombre historia: Edición de horarios Prioridad en negocio: Alta

Riesgo en desarrollo: Bajo

Puntos estimados: 8

Iteración asignada: 3

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO modificar los datos de los horarios PARA actualizar la lista de horarios Escenario de prueba: DADO la selección de un horario determinado CUANDO la administradora haga clic en el botón “Editar” ENTONCES el sistema presentará una interfaz con la información completa DADO el ingreso de datos incompletos o vacíos en el formulario de edición CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema alertará de los errores asociados. DADO la modificación de los datos del horario en los campos obligatorios del formulario de edición CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará el siguiente mensaje “Editado, horario editado” confirmando la operación. DADO la actualización del estado del horario en el formulario de edición CUANDO la administradora pulse sobre la casilla de verificación ENTONCES el sistema procederá a cambiar el estado (activo/inactivo) del horario editado.

86 Historia de usuario – Registro de menús Historia de Usuario Número: 10

Usuario: Administradora

Nombre historia: Registro de menús Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 13

Iteración asignada: 3

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO registrar el menú del día PARA que los clientes puedan observar lo que el restaurant ofrece al momento de realizar su pedido. Escenario de prueba: DADO el acceso al módulo “Menús” CUANDO la administradora haga clic en el botón “Nuevo” ENTONCES el sistema presentará una interfaz para el registro de los datos. DADO el ingreso de los datos del menú en todos los campos obligatorios del formulario de registro CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará el mensaje “Guardado, menú creado” que confirma la operación. DADO el ingreso de datos en blanco o incompletos en los campos obligatorios del formulario de registro CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema alertará al usuario solicitando el ingreso de los datos correspondientes. DADO la selección de una foto para el menú CUANDO la administradora haga clic en el botón “Subir foto” ENTONCES el sistema abrirá el explorador de archivos del ordenador para permitir escoger una foto representativa.

87 Historia de Usuario – Búsqueda de Menús Historia de Usuario Número: 11

Usuario: Administradora

Nombre historia: Búsquedas de menús Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 8

Iteración asignada: 3

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO poder buscar los menús PARA poder acceder fácilmente a ellos y poder realizar operaciones sobre los mismos. Escenario de prueba: DADO una búsqueda en la lista de menús CUANDO la administradora escriba el nombre del menú en la caja de búsqueda ENTONCES el sistema automáticamente realizará la búsqueda según los criterios de búsquedas ingresados en la caja de texto DADO una búsqueda de un registro no existente de la lista de menús CUANDO la administradora escriba el nombre en la caja de búsqueda ENTONCES el sistema presentará el siguiente mensaje “No se encontraron resultados”. DADO una búsqueda de menús en la caja de texto correspondiente CUANDO la administradora escriba caracteres especiales o números en la caja de búsqueda ENTONCES el sistema presentará el siguiente mensaje “No se encontraron resultados”.

88 Historia de usuario – Edición de menús Historia de Usuario Número: 12

Usuario: Administradora

Nombre historia: Edición de menús Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 5

Iteración asignada: 3

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO poder editar los menús PARA actualizar sus horas de inicio-fin en la lista general de menús Escenario de prueba: DADO la selección de un menú determinado CUANDO la administradora haga clic en el botón “Editar” ENTONCES el sistema presentará una interfaz con la información completa. DADO el ingreso de datos incompletos o en blanco en el formulario de edición CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema alertará de los errores asociados. DADO la modificación de los datos del menú en los campos obligatorios del formulario de edición CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema presentará el siguiente mensaje “Editado, menú editado” confirmando la operación. DADO el ingreso de datos vacíos o incompletos CUANDO la administradora haga clic en el botón cancelar ENTONCES se visualiza la lista de menús. DADO la actualización del estado del menú en el formulario de edición CUANDO la administradora pulse sobre la casilla de verificación ENTONCES el sistema procederá a cambiar el estado (activo/inactivo) del menú seleccionado.

89 Historia de usuario – Visualización de las Cartas Historia de Usuario Número: 13

Usuario: Administradora

Nombre historia: Visualización de las cartas Prioridad en negocio: Media

Riesgo en desarrollo: Bajo

Puntos estimados: 3

Iteración asignada: 3

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO visualizar la lista de cartas PARA identificar el horario y el menú que se ofrecerá a los clientes durante día. Escenario de prueba: DADO el acceso a la Lista de Cartas CUANDO la administradora haga clic en el botón “Cartas” ENTONCES el sistema abrirá el módulo de “Cartas” y presentará una interfaz con la lista de todos los menús ingresados en el sistema ordenados de acuerdo a la fecha, horario, contenido y tipo.

90 Historia de Usuario – Activación de las cartas Historia de Usuario Número: 14

Usuario: Administradora

Nombre historia: Activación de las cartas Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 5

Iteración asignada: 3

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO poder activar el menú del día PARA poder presentarlo a los clientes y que estos conozcan lo que se ofrece durante día. Escenario de prueba: DADO el acceso al módulo “Cartas” CUANDO la administradora haga clic en el botón “Modificar” ENTONCES el sistema presentará una interfaz de los menús de acuerdo a la fecha y con sus respectivos horarios. DADO la selección de la fecha determinada del correspondiente menú CUANDO la administradora pulse sobre la opción de “Activación” ENTONCES el sistema automáticamente cambiará el estado de la Carta (activado/desactivado) y se reflejará en la Lista General de Cartas. DADO la activación del menú correspondiente CUANDO la administradora haga clic en el botón “Cerrar” ENTONCES el sistema presentará la lista de cartas actualizadas.

91 Historia de usuario – Búsqueda en la lista de cartas Historia de Usuario Número: 15

Usuario: Administradora

Nombre historia: Búsqueda en la lista de cartas Prioridad en negocio: Media

Riesgo en desarrollo: Bajo

Puntos estimados: 3

Iteración asignada: 3

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO buscar los datos de las Cartas PARA tener un rápido acceso a su información existente. Escenario de prueba: DADO una búsqueda en la lista de cartas CUANDO la administradora escribe el nombre del menú en la caja de búsqueda ENTONCES el sistema automáticamente realizará la búsqueda según los criterios ingresados en la caja de texto DADO una búsqueda de un registro no existente en la lista de cartas CUANDO la administradora escriba el dato en la caja de búsqueda ENTONCES el sistema presentará el siguiente mensaje “No se encontraron resultados”. DADO una búsqueda en la lista de cartas CUANDO la administradora escriba caracteres especiales en la caja de búsqueda ENTONCES el sistema presentará el siguiente mensaje “No se encontraron resultados”.

92 Historia de Usuario – Acceso al panel de pedidos públicos (clientes) Historia de Usuario Número: 16

Usuario: Cliente

Nombre historia: Acceso al panel de pedidos públicos (clientes) Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 8

Iteración asignada: 4

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO cliente QUIERO poseer una interfaz de acceso a la sección “Pedidos” PARA poder observar el menú del día y realizar el pedido. Escenario de prueba: DADO el correcto ingreso del código (único para cada cliente) y autenticación por huella dactilar (o por clave registrada) CUANDO el cliente pulse sobre la opción “Verificar” ENTONCES el sistema comprobará los parámetros enviados y validará el ingreso a la sección “Pedidos” DADO el ingreso incorrecto del código, huella dactilar o clave registrada CUANDO el cliente pulse sobre la opción siguiente o verificar ENTONCES el sistema presentará un mensaje de error notificando del suceso. DADO el ingreso incorrecto del código o clave registrada CUANDO el cliente pulse sobre la opción “Limpiar” ENTONCES el sistema limpiará los datos que se han ingresado en la caja de texto DADO la interfaz para el ingreso de la huella dactilar CUANDO el cliente coloque el dedo en el dispositivo biométrico dentro del tiempo permitido (10 segundos) ENTONCES el sistema lo redireccionará a la interfaz de Pedidos.

93 Historia de Usuario – Registro automático de pedidos (principal) Historia de Usuario Número: 17

Usuario: Clientes

Nombre historia: Registro de pedidos del cliente Prioridad en negocio: Media

Riesgo en desarrollo: Alto

Puntos estimados: 21

Iteración asignada: 4

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO cliente QUIERO seleccionar un determinado platillo el menú del día PARA registrar el pedido y poder adquirir los alimentos seleccionados Escenario de prueba: DADO el ingreso correcto del código y huella dactilar (o clave registrada) CUANDO el cliente acceda al panel de “Pedidos” fuera del horario establecido ENTONCES el sistema presentará una notificación de alerta con el siguiente mensaje “Información. No existen opciones de cartas disponibles para la hora actual”. DADO la selección de un platillo de la Carta presentada CUANDO el cliente haga clic en el botón “Enviar” ENTONCES el sistema presentará el mensaje “Guardado, pedido creado” y se imprime el comprobante de pedido DADO la selección de más de un platillo de las opciones de Cartas presentadas CUANDO el cliente pulse sobre otro menú u opción de carta ENTONCES el sistema presentará un mensaje “Error, solo se permite escoger 1 opción para el horario actual”. DADO el ingreso al panel de “Pedidos” CUANDO el cliente selecciona un platillo en el mismo horario y pulsa sobre el botón “Enviar” ENTONCES el sistema presentará el siguiente mensaje “Error, Ya ha realizado un pedido en el día y horario actual”.

94 Historia de usuario – Registro de pedidos (secundario) Historia de Usuario Número: 18

Usuario: Administradora

Nombre historia: Registro secundario de pedidos Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 13

Iteración asignada: 4

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO poder seleccionar un platillo del menú del día PARA registrar el pedido de los clientes cuando el dispositivo biométrico no funciones adecuadamente. Escenario de prueba: DADO el acceso al módulo “Pedidos” CUANDO la administradora haga clic en el botón “Nuevo” ENTONCES el sistema presentará una interfaz para el registro de los datos. DADO la selección completa de los datos del pedido CUANDO la administradora haga clic en el botón “Guardar” ENTONCES se visualiza un mensaje “Guardado, pedido creado”. DADO la selección de más de una opción de la lista de cartas CUANDO la administradora haga clic sobre otra casilla de selección de menús ENTONCES el sistema presentará un mensaje “Error, solo se permite hasta 1 opciones de carta en el horario actual”. DADO el ingreso a la interfaz de “Pedidos” CUANDO la administradora selecciona un platillo con el mismo cliente-horario y pulsa sobre el botón “Guardar” ENTONCES el sistema presentará el siguiente mensaje “Error, Ya ha realizado un pedido para el cliente, día y horario actual”.

95 Historia de usuario – Visualización de pedidos Historia de Usuario Número: 19

Usuario: Administradora

Nombre historia: Visualización de pedidos Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 8

Iteración asignada: 4

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO visualizar los pedidos que han realizado los clientes PARA obtener la información sobre los pedidos del día. Escenario de prueba: DADO el acceso a la “Lista de Pedidos” del módulo Pedidos CUANDO la administradora selecciona un cliente y da clic en el botón “Ver” ENTONCES el sistema presentara una pequeña tabla con los detalles del pedido.

96 Historia de usuario – Imprimir comprobante de pedido. Historia de Usuario Número: 20

Usuario: Administradora

Nombre historia: Impresión del comprobante. Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 5

Iteración asignada: 4

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO imprimir el comprobante del pedidos de un determinado cliente PARA obtener el ticket correspondiente y entregárselo al mismo Escenario de prueba: DADO el acceso a la “Lista de Pedidos” del módulo “Pedidos” CUANDO la administradora seleccione el cliente que ha realizado el pedido y haga clic en el botón “Imprimir” ENTONCES el sistema imprimirá el ticket del pedido realizado.

97 Historia de usuario – Reporte de alimentación Historia de Usuario Número: 21

Usuario: Administradora

Nombre historia: Reporte de alimentación Prioridad en negocio: Baja

Riesgo en desarrollo: Medio

Puntos estimados: 21

Iteración asignada: 5

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO generar un reporte de alimentación PARA ver la información detallada de los pedidos de alimentación que han realizado los clientes. Escenario de prueba: DADO la selección del tipo de reporte, rango de la fecha y cliente CUANDO la administradora haga clic en el botón “Ver” ENTONCES el sistema presentará la hoja de reporte de alimentación con los detalles de los pedidos. DADO la selección en blanco del tipo de reporte y cliente CUANDO la administradora haga clic en el botón “Ver” ENTONCES el sistema presentará un mensaje “Error, seleccione el tipo de reporte y cliente”. DADO sólo la selección del tipo de reporte CUANDO la administradora haga clic en el botón “Ver” ENTONCES el sistema presentará un mensaje “Error, seleccione el cliente”. DADO sólo la selección del cliente CUANDO la administradora haga clic en el botón “Ver” ENTONCES el sistema presentará un mensaje “Error, seleccione el tipo de reporte”.

98 Historia de usuario – Envío de los reportes de alimentación Historia de Usuario Número: 22

Usuario: Administradora

Nombre historia: Envío de los reportes de alimentación Prioridad en negocio: Baja

Riesgo en desarrollo: Medio

Puntos estimados: 13

Iteración asignada: 5

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO enviar por correo electrónico los reportes de alimentación PARA la entrega de información al departamento de contabilidad y a los respectivos clientes Escenario de prueba: DADO la selección del tipo de reporte, rango de fecha y cliente CUANDO la administradora haga clic en el botón “Procesar” ENTONCES el sistema procederá al envío de los reportes de alimentación por correo electrónico a los respectivos clientes. DADO la selección en blanco del tipo de reporte y cliente CUANDO la administradora haga clic en el botón “Procesar” ENTONCES el sistema presentará un mensaje “Error, seleccione el tipo de reporte y cliente”. DADO sólo la selección del tipo de reporte CUANDO la administradora haga clic en el botón “Procesar” ENTONCES el sistema presentará un mensaje “Error, seleccione el cliente”. DADO sólo la selección del cliente CUANDO la administradora haga clic en el botón “Procesar” ENTONCES el sistema presentará un mensaje “Error, seleccione el tipo de reporte”.

99 Historia de Usuario – Parámetros del reporte

Historia de Usuario Número: 23

Usuario: Administradora

Nombre historia: Parámetros del reporte Prioridad en negocio: Baja

Riesgo en desarrollo: Bajo

Puntos estimados: 8

Iteración asignada: 5

Programador responsable: Jimmy Quiguango – Fernanda Almache Descripción: COMO administradora QUIERO poder configurar la información de las firmas PARA que se visualicen correctamente en el reporte de alimentación generado

Escenario de prueba: DADO el ingreso correcto de los nombres en los correspondientes tipos de firmas CUANDO la administradora haga clic en el botón “Guardar” ENTONCES el sistema registrará dichos cambios y se reflejarán en los reportes de alimentación.

100

Anexo 5. Diccionario de datos El diccionario de datos cuenta con las definiciones de todas las 20 tablas creadas para la base de datos del sistema web “RESAN” y la forma de presentación de cada una de ellas se describe a continuación: Nombre de la columna, tipo de dato, si es clave primaria de la tabla, si es un tipo nulo, y comentarios de los campos. 

Tabla aliemp



Tabla áreas



Tabla clientes

101 

Tabla grusud



Tabla objdic



Tabla perfiles



Tabla rescarta

102 

Tabla resdispos



Tabla reshorari



Tabla resmenús



Tabla resregist

103 

Tabla tarali



Tabla tipali



Tabla usuari



Tabla corteali



Tabla grusub

104 

Tabla nmemp



Tabla parext



Tabla perfilac



Tabla ressecuen

105

Anexo 6. Pruebas de aceptación del sistema RESAN

Prueba de Funcionalidad 1 Prueba de funcionalidad ID Caso de prueba: 01

Nombre caso de prueba: Acceso al sistema

Módulo/sección a evaluar: Autenticación

Historia de usuario involucrada: 1

Descripción: Se comprueba el correcto funcionamiento de la Autenticación del sistema verificando que se cumpla con la funcionalidad especificada y se efectúen los criterios de aceptación que poseen las historias de usuario que participan en el test. La administradora ingresará al sistema para comprobar el funcionamiento del Login de Usuario. Pre-condiciones  Los servicios (base de datos, servidor web, etc) deben estar funcionando Pasos y condiciones de ejecución  La administradora accede al sistema mediante la URL proporcionada  La administradora ingresa el usuario/contraseña que se le ha proporcionado  Después de ello pulsa en el botón “Ingresar”  El sistema verifica los datos ingresados y comprueba el inicio de sesión  El sistema re-direcciona al administrador al panel principal de administración del sistema. Resultado esperado  La administradora puede iniciar sesión correctamente en el sistema

Exitoso Estado de prueba

Errores asociados: Ninguno Post-condiciones: El usuario ingresa al sistema y sus sesión se activa

Falló

106 Prueba de Funcionalidad 2 Prueba de funcionalidad ID Caso de prueba: 02

Nombre caso de prueba: Administración del dispositivo

Módulo/sección a evaluar: Módulo Dispositivos

Historia de usuario asociada: 2-3

Descripción: Se comprueba el correcto funcionamiento del Módulo de Dispositivos verificando que se cumpla con la funcionalidad especificada y se efectúen los criterios de aceptación que poseen las historias de usuario que participan en el test. La administradora ingresará los códigos del SDK para el funcionamiento del dispositivo biométrico. Pre-condiciones  La administradora debe iniciar sesión en el sistema  El dispositivo biométrico a registrar debe estar conectado y funcionando Pasos y condiciones de ejecución  La administradora ingresa al Módulo de Dispositivos  La administradora pulsa sobre el botón “Nuevo”  Procede a registrar los datos correspondientes al dispositivo biométrico (como los códigos del SDK) y de esta forma agregarlo a la lista de dispositivos pulsando el botón nuevo  La administradora puede activar o no el dispositivo mediante la verificación de la casilla en el apartado “Estado”  Los cambios registrados se guardarán exitosamente en el sistema Resultado esperado  Se guardan todos los datos correspondientes del registro del dispositivo biométrico  El sistema muestra un mensaje de confirmación exitoso. Exitoso Estado de prueba

Falló

Errores asociados: Ninguno Post-condiciones: El dispositivo queda registrado en el sistema, listo para su uso inmediato.

107 Prueba de Funcionalidad 3 Prueba de funcionalidad ID Caso de prueba: 03

Nombre caso de prueba: Administración de clientes

Módulo/sección a evaluar: Módulo Clientes

Historia de usuario asociada: 4-5-6-7

Descripción: Se comprueba el correcto funcionamiento del Módulo de Clientes verificando que se cumpla con la funcionalidad especificada y se efectúen los criterios de aceptación que poseen las historias de usuario que participan en el test. La administradora seleccionará al cliente para registrar las huellas dactilares en el sistema. Pre-condiciones  La administradora debe iniciar sesión en el sistema  El dispositivo biométrico debe estar registrado en el sistema antes de cualquier operación  El dispositivo biométrico debe estar encendido y en correcto funcionamiento Pasos y condiciones de ejecución  La administradora ingresa al Módulo de Clientes  La administradora pulsa sobre el botón “Nuevo”  Después se selecciona al cliente (Nomina) para proceder al registro de huella  Se registran todos los datos correspondientes al cliente determinado  La administradora realiza la búsqueda del cliente para registrar las huellas dactilares o modificar datos  Se realiza el proceso de registrar las huellas dactilares pulsando el botón “Enrolar”  Las operaciones realizadas se guardan exitosamente en el sistema. Resultado esperado  Se guardan todos los datos correspondientes del registro de clientes  Se registra la huella dactilar del cliente en el sistema  El sistema muestra un mensaje de confirmación exitoso. Exitoso Estado de prueba

Falló

Errores asociados: Ninguno Post-condiciones: El cliente queda registrado y puede realizar sus pedidos de alimentación por medio de su huella dactilar

108 Prueba de Funcionalidad 4 Prueba de funcionalidad ID Caso de prueba: 04

Nombre caso de prueba: Administración de Horarios

Módulo/sección a evaluar: Módulo Horarios

Historia de usuario asociada: 8-9

Descripción: Se comprueba el correcto funcionamiento del Módulo de Horarios verificando que se cumpla con la funcionalidad especificada y se efectúen los criterios de aceptación que poseen las historias de usuario que participan en el test. La administradora ingresará los horarios para asignar la hora de inicio y fin para los diferentes tipos de alimentación. Pre-condiciones  La administradora debe iniciar sesión en el sistema Pasos y condiciones de ejecución  La administradora ingresa al Módulo de Horarios  La administradora pulsa sobre el botón “Nuevo”  Se procede a ingresar la hora de inicio y fin para cada tipo de alimentación  Se confirma la operación cuando el administrador pulsa sobre el botón “Guardar”  La administradora puede realizar la búsqueda del horario para realizar modificaciones pulsando el botón editar  Todas las operaciones realizadas se guardan exitosamente en el sistema. Resultado esperado  Se guardan todos los datos correspondientes del registro de los horarios  El sistema muestra un mensaje de confirmación exitoso. Exitoso Estado de prueba

Falló

Errores asociados: Ninguno Post-condiciones: Los horarios queda registrado para la activación de las cartas de presentación

109 Prueba de Funcionalidad 5 Prueba de funcionalidad ID Caso de prueba: 05

Nombre caso de prueba: Administración de Menús

Módulo/sección a evaluar: Módulo de Menús

Historia de usuario asociada: 10-11-12

Descripción: Se comprueba el correcto funcionamiento del Módulo de Menús verificando que se cumpla con la funcionalidad especificada y se efectúen los criterios de aceptación que poseen las historias de usuario que participan en el test. La administradora registrará los diferentes tipos de menús. Pre-condiciones  La administradora debe iniciar sesión en el sistema Pasos y condiciones de ejecución  La administradora ingresa al Módulo de Menús  Para ingresar un nuevo menú, el administrador debe pulsa sobre el botón “Nuevo”  Se procede al ingreso de las diferentes opciones de los menús del día. La administradora confirma la operación dando clic sobre el botón “Guardar”  Búsqueda de los menús para realizar modificaciones pulsando el botón editar  La administradora puede realizar la búsqueda del horario para efectuar modificaciones sobre los mismos pulsando el botón editar  Todas las operaciones realizadas se guardan exitosamente en el sistema. Resultado esperado  Se guardan todos los datos correspondientes del registro de los menús  El sistema muestra un mensaje de confirmación exitoso. Exitoso Estado de prueba

Errores asociados: Ninguno Post-condiciones: Los menús quedan registrados para la presentación al cliente en el día.

Falló

110 Prueba de Funcionalidad 6 Prueba de funcionalidad ID Caso de prueba: 06

Nombre caso de prueba: Administración de cartas

Módulo/sección a evaluar: Módulo de “Cartas”

Historia de usuario asociada: 13-14-15

Descripción: Se comprueba el correcto funcionamiento del Módulo de Cartas verificando que se cumpla con la funcionalidad especificada y se efectúen los criterios de aceptación que poseen las historias de usuario que participan en el test. La administradora activará los diferentes menús del día en los horarios correspondientes para presentarlos en a los clientes. Pre-condiciones  La administradora debe iniciar sesión en el sistema  Deben estar configurados previamente los horarios y menús. Pasos y condiciones de ejecución  La administradora ingresa al Módulo de Cartas  Para activar el menú del día, la administradora da clic en el botón “Modificar”  Se procede a activar o desactivar el menú del día pulsando sobre el switch de estado (Si/No)  La administradora puede realizar la búsqueda de las cartas para acceder fácilmente a ellas  Todas las operaciones realizadas se guardan exitosamente en el sistema. Resultado esperado  Se guardan todos los datos correspondientes de la activación de las cartas  El sistema muestra un mensaje de confirmación exitoso. Exitoso Estado de prueba

Falló

Errores asociados: Ninguno Post-condiciones: Las cartas quedan activadas para la presentación de los diferentes menús del día en su respectivo horario.

111 Prueba de Funcionalidad 7 Prueba de funcionalidad ID Caso de prueba: 07

Nombre caso de prueba: Administración de pedidos (principal y secundario)

Módulo/sección a evaluar: Módulo de Pedidos

Historia de usuario asociada: 16-17-18-19-20

Descripción: Se comprueba el correcto funcionamiento del Módulo de Pedidos verificando que se cumpla con la funcionalidad especificada y se efectúen los criterios de aceptación que poseen las historias de usuario que participan en el test. El cliente podrá registrar su pedido por medio de su huella dactilar o clave asignada o a su vez la administradora podrá seleccionar el menú del día para registrar el pedido de los clientes Pre-condiciones  El cliente debe estar registrado en el sistema para acceder al panel público de pedidos  La administradora debe iniciar sesión en el sistema Pasos y condiciones de ejecución Principal  En el panel táctil, el cliente ingresará su código personal asignado  El cliente podrá acceder por medio de su huella dactilar o clave registrada  El cliente elegirá su pedido y confirmara su pedido pulsando sobre la opción “Enviar”  El cliente obtendrá su ticket en donde se evidencia el pedido realizado  Todas las operaciones realizadas se guardan exitosamente en el sistema. Secundario  La administradora ingresará al módulo de pedidos  Para registrar un pedido, la administradora da clic sobre el botón “Nuevo”  Se procede a seleccionar el cliente y registrar el pedido pulsando sobre el botón “Guardar”  El sistema presentara una tabla con la lista de los pedidos registrados.  La administradora imprime y entrega el ticket al cliente  Todas las operaciones realizadas se guardan exitosamente en el sistema. Resultado esperado  Se guardan todos los datos correspondientes del registro de pedidos (principal)  Se guardan todos los datos correspondientes del registro de pedidos (secundario)  El sistema muestra un mensaje informando que la transacción se realizó con éxito Exitoso Estado de prueba

Errores asociados: Ninguno Post-condiciones: Los pedidos quedan registrados para su posterior uso.

Falló

112 Prueba de Funcionalidad 8 Prueba de funcionalidad ID Caso de prueba: 08

Nombre caso de prueba: Administración de reportes

Módulo/sección a evaluar: Módulo de Parámetros y Reportes

Historia de usuario asociada: 21-22-23

Descripción: Se comprueba el correcto funcionamiento del Módulo de Parámetros y de Reportes verificando que se cumplan con las funcionalidades especificadas y se efectúen los criterios de aceptación que poseen las historias de usuario que participan en el test. La administradora podrá configurar las firmas a presentar en el reporte, además podrá visualizar la información detallada de los pedidos de alimentación de los clientes, imprimiendo los reportes y enviando a los correos personales Pre-condiciones  La administradora debe iniciar sesión en el sistema Pasos y condiciones de ejecución  La administradora ingresa al módulo de parámetros y configura las firmas a presentar en el reporte  Luego de ello, la administradora ingresa al módulo de reportes.  La administradora podrá visualizar el reporte de alimentación de forma individual o grupal  Para observar el reporte de alimentación, la administradora debe pulsar sobre el botón “Ver”  La administradora podrá enviar el reporte de alimentación a los correos personales pulsando el botón “Procesar”  Todas las operaciones realizadas se guardan exitosamente en el sistema. Resultado esperado  Se realizan los procesos correspondientes a los reportes  El sistema muestra un mensaje informando que la transacción se realizó con éxito  Se imprime los reportes de alimentación en formato pdf  Se envía los reportes a los correos personales Exitoso Estado de prueba

Errores asociados: Ninguno Post-condiciones: los correos enviados quedan registrado en el programa Zimbra

Anexo 7. Manual de usuario El manual de usuario se adjunta en el CD.

Anexo 8. Manual de instalación El manual de instalación se adjunta en el CD.

Falló

113

Anexo 9. Acta de entrega y recepciรณn

114

Anexo 10. Carta de impacto