RodriguezHernanzFranciscoR ETIGa2009 10

SGP: SISTEMA DE GESTIN DE PEDIDOS
Memoria del proyecto de Ingenieria Tcnica en Informtica de Gestin realizada por Francisco Rodrguez Hernanz y dirigido por Mnica Denham
Escola dEnginyeria
Sabadell, septiembre de 2010
SGP: Sistema de Gestin de Pedidos
La abajo firmante, Mnica Denham, profesora de l'Escola dEnginyeria de la UAB,
CERTIFICA:
Que el trebajo al que corresponde la presente memoria ha estado realitzado bajo su direccin por en Francisco Rodriguez Hernanz Y para que conste firma la presente. Sabadell, septiembre
---------------------------------------------Firmado: Mnica Denham
Resumen
Este proyecto tiene como objetivo desarrollar una aplicacin en formato web capaz de dar soporte a la gestin de los pedidos de restaurante. El proyecto incluye un entorno de trabajo para un administrador con pequeos mdulos que ayudaran a realizar un buen mantenimiento del sistema. Nuestro objetivo comprender la creacin de un pedido y sus posteriores fases hasta su finalizacin.
NDICE
Resumen................................................................................................................................ 3 NDICE ................................................................................................................................... 4 1. PRESENTACIN .................................................................................................................. 7 1.1. Resumen ..................................................................................................................... 7 1.2. Estado del arte ............................................................................................................ 7 1.3. Objetivo y alcance previstos ...................................................................................... 11 1.4. Justificacin............................................................................................................... 11 2. ESTUDIO DE VIABILIDAD................................................................................................... 13 2.1. Introduccin .............................................................................................................. 13 2.2. Objeto ....................................................................................................................... 13 2.2.1. Situacin del estudio .......................................................................................... 13 2.2.2. Perfil de los usuarios del proyecto ...................................................................... 13 2.2.3. Objetivos ............................................................................................................ 14 2.3. Recursos.................................................................................................................... 14 2.3.1. Recursos de desarrollo ....................................................................................... 14 2.3.2. Recursos de implementacin .............................................................................. 15 2.4. Planificacin del proyecto.......................................................................................... 15 2.4.1. Planificacin inicial ............................................................................................. 15 2.4.2. Modelo de desarrollo ......................................................................................... 17 2.5. Conclusiones ............................................................................................................. 18 3. ANALISIS DEL PROYECTO .................................................................................................. 19 3.1. Requerimientos funcionales ...................................................................................... 19 3.1.1. Visin general ..................................................................................................... 19 3.1.2. Requisitos funcionales de usuarios ..................................................................... 19 3.1.3. Vistas de casos de uso ........................................................................................ 22 3.1.4. Diagramas de secuencia...................................................................................... 25 4
3.2. Requerimientos no funcionales ................................................................................. 26 4. DISEO ............................................................................................................................ 28 4.1. Introduccin .............................................................................................................. 28 4.1.1. Seleccin del entorno de desarrollo .................................................................... 28 4.1.2. Seleccin de base de datos ................................................................................. 28 4.1.3. Diagrama de Entidad-Relacin ............................................................................ 30 4.2. Estructura de la base de datos ................................................................................... 30 4.2.1. Contenido de las tablas de la base de datos ........................................................ 31 4.3. Arquitectura de la aplicacin ..................................................................................... 34 5. IMPLEMENTACIN ........................................................................................................... 35 5.1. Introduccin .............................................................................................................. 35 5.2. Codificacin de las diferentes capas de la aplicacin.................................................. 35 5.2.1. Interfaces ........................................................................................................... 35 5.2.2. Entorno de usuarios............................................................................................ 37 5.2.4. Capa de datos ..................................................................................................... 41 6. PRUEBAS .......................................................................................................................... 42 6.1. Pruebas de compatibilidad ........................................................................................ 42 6.2. Pruebas de seguridad ................................................................................................ 42 6.3. Pruebas de integracin de servicio ............................................................................ 43 6.4. Pruebas segn el tipo de usuario ............................................................................... 43 6.4.1. Usuario administrador ........................................................................................ 43 6.4.2. Usuario cliente ................................................................................................... 45 6.4.3. Usuario personal ................................................................................................ 46 6.4.4. Usuario cocina .................................................................................................... 48 7. CONCLUSIONES Y RESULTADOS ........................................................................................ 49 7.1. Consecucin de objetivos .......................................................................................... 49 7.2. Desviaciones observadas ........................................................................................... 49 5
7.3. Lneas de ampliacin ................................................................................................. 50 7.4. Valoracin personal de la experiencia........................................................................ 50 8. ANEXO I: CASOS DE USO................................................................................................... 52 9. ANEXO II: DIAGRAMAS DE SECUENCIA.............................................................................. 63 10. BIBLIOGRAFIA................................................................................................................. 71 10.1. Programacin .......................................................................................................... 71 10.1.1. Paginas web...................................................................................................... 71 10.1.2. Libros................................................................................................................ 71 10.2. Confeccin de la memoria ....................................................................................... 71
1. PRESENTACIN
1.1. Resumen
La situacin habitual en un restaurante en cuanto a pedidos, tiempo de espera, facturacin correcta, entre otros, no es la ms ideal en la mayora de los casos, lo que hace que resulte difcil dar un buen servicio al cliente, sobre todo durante las horas de mayor ocupacin del local. Los recursos con los que se cuentan en un local de este tipo (restaurante, bar, etc.) son escasos, y esto obliga al personal del restaurante a tener que desplazarse un gran un nmero de veces de un lugar a otro para poder cumplir con su labor, ocasionando deficiencias en el servicio, olvido de rdenes, retardos, y equivocaciones en los pedidos debido a que el sistema que se utiliza es manual. Todo lo anteriormente explicado conlleva prdidas econmicas y de clientela que pueden determinar el xito o fracaso del negocio. Es por eso que se propone disear e implementar un sistema que brinde flexibilidad gracias al uso de terminales tctiles en cada unas de las mesas, las cuales aumentarn la participacin del cliente, otorgar flexibilidad por medio de sus mdulos configurables, ofrecer informacin precisa garantizada por la aplicacin, llevar a cabo el control de usuarios, la integracin de los procesos del negocio por medio de los distintos mdulos del sistema, optimizacin de los mismos debido a que el sistema reduce el tiempo de ejecucin de los procesos y usabilidad.. En el actual mbito de desarrollo, el sistema ser implementado y testeado sin la utilizacin de terminales tctiles (debido a su falta de disponibilidad). Se asumen terminales con dispositivos de tipo ratn. De esta forma, es posible el desarrollo de la funcionalidad completa del software, previniendo que el cambio a pantallas tctiles sea mnimo.
1.2. Estado del arte

Un software de gestin de pedidos para restaurantes debe abarcar numerosas alternativas de facturacin y control. Y debe ser lo ms flexible posible. No son las mismas necesidades para un restaurante de clase A que en un fast food. Debe ser una herramienta moldeable a las necesidades de control y gestin que precisa el cliente. Las necesidades ms bsicas para un restaurante son: disponer de un sitio donde ofertar los productos, un sistema para la gestin de pedidos, y un registro donde poder almacenar dichos pedidos y el coste de los mismos.
Actualmente, en el mercado se pueden encontrar numerosas soluciones software, las cuales se dedican a la gestin de restaurantes, cumpliendo con las necesidades ms bsicas mencionadas previamente. Adems, se pretende una mayor participacin del cliente en el proceso de la gestin de pedidos, ya que con esa participacin se ahorrarn tiempos y mal entendidos, aparte de que sea de fcil manejo. Despus de haber realizado una bsqueda de diferentes soluciones y aplicaciones que cumplen con las necesidades bsicas, a continuacin se van a citar las diferentes soluciones encontradas: AZHosteleria o http://www.softpyme.net/software-bar-restaurante.php RestaWeb o http://www.techni-web.es RestBar o http://www.restbar.com/ A continuacin se detallan las principales caractersticas y carencias de dichas soluciones:
AZHosteleria
Est destinado a la gestin integral de negocios relacionados con la hostelera, y es poseedor de unas caractersticas que harn ms simples todas las tareas a realizar en este entorno. Incluye TPV (terminal punto de venta) tanto tctil como de pantalla no tctil. Est preparado para gestionar distintas mesas, con precios diferentes segn se trate de mesa o barra. Ofrece control de camareros con distintos perfiles de acceso. Adems de emitir tickets, puede emitir facturas, albaranes, compras, etc. Tambin est habilitado para trabajar en red y mediante lector de cdigo de barras an cuando se use en el modo de pantalla tctil.
Figura 1.1 Pantalla principal AZHosteleria
La principal carencia de esta solucin es la falta de participacin del cliente en el proceso de hacer un pedido, aparte de que no se lleva ningn control del estado del pedido.
RestaWeb
Propone una solucin de TPV (terminal punto de venta, Figura 1.3) tctil y software de gestin gil y moderna para coordinar las operaciones tanto de comedor como de cocina y la gestin administrativa del establecimiento. Est pensado para dar solucin a las ventas de mostrador que se realizan en un restaurante o cafetera. Sustituye la forma tradicional de trabajo en los restaurantes. Los empleados pueden anotar los artculos de cada mesa, mediante una interfaz totalmente grfica y tctil, generndose automticamente los pedidos a cocina y las lneas de stock. Existe la posibilidad de utilizar varios idiomas, para un uso ms personalizado.
Figura 1.2 Pantalla principal RestaWeb
Figura 1.3 TPV de RestaWeb
Al reducir los desplazamientos del personal y mejorar la comunicacin, reducir el tiempo de rotacin de la mesa notablemente, especialmente en momentos de mxima ocupacin. La solucin de RestaWeb pese a ser bastante buena, carece de la participacin del cliente, estos es algo que se busca desde el principio.
RestBar
El programa RestBar integra las diferentes reas de control para su negocio, la facturacin de mesas, ventas rpidas y servicio express (delivery), recetas y costos, la caja (ingresos y egresos de dinero), los inventarios de bebidas, insumos y otros, control de entradas y salidas de empleados, las cuentas por cobrar a clientes, las cuentas por pagar a proveedores, las reservaciones de clientes, la planeacin de eventos (clculo de requerimientos de insumos), estadsticas mensuales varias y utilitarios. Adems de una gil y completa interfaz tctil o "touchscreen" para el trabajo de los camareros y cajeros.
Figura 1.4 Pantalla principal de RestBar
Figura 1.5 Listado de mesas de RestaBar
10
Utiliza tambin TPV, y como la opcin anterior, RestaWeb, vuelve a tener la carencia de la participacin con el cliente, aparte de que todo el sistema est centralizado en un mismo punto, el TPV. En conclusin, todos las soluciones vistas, complacen las necesidades bsicas, disponer de un sitio donde ofertar los productos, un sistema para la gestin de pedidos, y un registro donde poder almacenar dichos pedidos y el coste de los mismos, pero ninguno de ellos cumple el requisito de la participacin del cliente a la hora de la gestin de pedidos, ya que todas las soluciones encontradas utilizan TPV a la vez que utilizan camareros, es decir, la implementacin del TPV hace que la participacin del cliente no aparezca.
1.3. Objetivo y alcance previstos

Automatizar la gestin de pedidos de una empresa relacionada con el sector de la restauracin. Para esto se desarrollar una aplicacin Web que permita gestionar la informacin sobre pedidos, como as tambin informacin relacionada a los usuarios registrados. Lograr una mayor participacin del cliente a la hora de realizar pedidos, consiguiendo mejorar el tiempo del proceso de gestin de los mismos. Tambin manejar informacin referente a los productos ofrecidos, y permitir realizar parte de la facturacin de la empresa.
1.4. Justificacin
Es habitual que en este tipo de empresas (restaurantes, bares, taperas, etc.), el proceso de atencin al cliente se realice de forma que no deje satisfecho al cliente: cuntas veces nos quejamos porque se tarda demasiado tiempo en ser atendidos?, o por el contrario, an no hemos decidido qu elegir y el encargado de registrar los pedidos ya est dispuesto a tomar nota? Las ventajas que obtendr la empresa con la utilizacin de un sistema que automatice la gestin de pedidos son mltiples. Las ms importantes se pueden resumir en: Mejorar la atencin al cliente: el cliente podr pedir cualquier producto cuando l lo dese, sin depender de la disponibilidad de otra persona (camarero). El sistema realizar la gestin de una parte del manejo econmico de la empresa: cada pago de un pedido se registrar, permitiendo conocer cunto dinero ha de haber en la caja, al final del da, del mes o durante un determinado periodo de tiempo. 11
Ahorrar en personal, ya que la automatizacin de procesos, hace que intervengan menos personas, y que se puedan dedicar a otros procesos internos. Colaborar con el medio ambiente ahorrando en papel, ya que cada vez que se necesite actualizar la carta con los productos ofertados, no har falta volver a imprimir nuevas cartas. Realizar estadsticas y estudios, ya que se dispondr de informacin almacenada en la base de datos, relacionada a los pedidos realizados por los clientes.
Las desventajas que obtendr la empresa con la utilizacin de un sistema que automatice las gestin de pedidos son muy pocas. Las ms importantes se pueden resumir: Inversin inicial, ya que al ser un sistema desarrollado a medida, supone un coste ms amplio. Hardware, dependiendo del que se disponga, hay que hacer una inversin econmica mayor o menor.
Automatizar un sistema o procesos conlleva a una serie de ventajas y desventajas. Como hemos demostrado, en este caso las ventajas son mayores que las desventajas, por lo que realizar esta automatizacin tendr como resultado un beneficio con respecto al sistema sin automatizar.
12
2. ESTUDIO DE VIABILIDAD
2.1. Introduccin
El objetivo del estudio de viabilidad es el anlisis de un conjunto concreto de necesidades para proponer una solucin a corto plazo, que tenga en cuenta restricciones econmicas, tcnicas, legales y operativas. El estudio de viabilidad se orientar a la especificacin de requisitos ya que costos, riesgos, problemas legales, etc., estn fuera de este proyecto. Durante el desarrollo de este captulo se analizar el alcance de la necesidad planteada y se identifican las restricciones relativas a la sincronizacin con otros procesos, que puedan interferir en la planificacin y futura puesta a punto del sistema objeto de estudio. Esta informacin se recoge en el apartado de requisitos.
2.2. Objeto
2.2.1. Situacin del estudio
El proyecto est pensado para restaurantes que no dispongan de un sistema automatizado para la gestin de sus pedidos. Despus de haber analizado distintas necesidades de restaurantes que no disponen de ningn sistema automatizado de gestin, a continuacin se exponen las necesidades de mejora ms importantes de dichos sistemas: Gestin de pedidos. Control de productos ofertados. Control de cuentas parcial.
2.2.2. Perfil de los usuarios del proyecto

Como se explicar en el captulo 3, existen distintos tipos de usuarios, para los cuales el sistema ofrecer un conjunto de funcionalidades especficas. Independientemente del tipo de usuario, el sistema ser desarrollado con el objetivo de que sea fcil de utilizar, intuitivo y que no se requiera conocimiento previo por parte de los usuarios, para que sea accesible a cualquier tipo de persona, tenga conocimientos de las nuevas tecnologas o no. 13
2.2.3. Objetivos
A. Objetivo General Desarrollar un sistema de gestin de informacin de pedidos basado en mdulos configurables, que permita automatizar parte del proceso generado por un cliente: ordenar su comida, facturarla, atenderla, etc. Adems, el sistema permitir manejar la informacin asociada a las distintas comidas ofrecidas.
B. Objetivos especficos Mejorar la gestin actual de los pedidos realizados por los clientes. Agilizar y mejorar el proceso de la informacin centralizada. Informacin centralizada se entiende como pedidos, informacin de productos y facturas. Detectar fallos/errores entre los tericos productos ofertados y los reales: actualizacin de productos. Comprobar que los productos ofertados son los correctos. Generar una cuenta/factura al finalizar el servicio. Ha de recoger informacin referente a los productos consumidos y el precio de los mismos. Los usuarios se han de identificar para utilizar la aplicacin. Implementar un sistema para el control de permisos. Mejorar la implicacin del sistema con el cliente.
2.3. Recursos
2.3.1. Recursos de desarrollo
Requisitos mnimos para el desarrollo de la aplicacin. Hardware: o PC/MAC 2.0 GHz, 1Gb memoria RAM, 100Gb de disco duro. o Conexin a internet: 1Mb. Software: o Servidor Web: Apache. o Entorno de desarrollo: Eclipse for php developers. o Base de datos: MySQL. 14
o o o o o
Editor de base de datos: phpMyAdmin. Programacion web: PHP, HTML, AJAX, jQuery. Sistema Operativo: Windows XP/Linux/MAC OS Navegador: Mozilla Firefox/Google Chrome/Opera Documentacin del proyecto: Open Office
En el capitulo 4, se explicarn las tecnologas mencionadas en la lista previa.
2.3.2. Recursos de implementacin

Requisitos mnimos para la implementacin de la aplicacin. Servidor o Servidor LAMP (Linux, Apache, MySQL, PHP), 1Gb memoria RAM, 1 GB de disco duro. Hardware del terminal del administrador/cocina/personal o PC/MAC 2.0 GHz, 1Gb memoria RAM, 1 Gb de disco duro. Software del terminal del administrador/cocina/personal o Navegador: Mozilla Firefox/Google Chrome/Opera Hardware del terminal del cliente o PC/MAC 2.0 GHz, 1Gb memoria, 1 Gb de disco duro. o Monitor LCD chasis de pantalla tctil 3M MicroTouch 15. o Ratn, en caso de no disponer pantalla tctil. Software del terminal del cliente o Navegador: Mozilla Firefox/Google Chrome/Opera
2.4. Planificacin del proyecto

2.4.1. Planificacin inicial
Numero 1 2
Tarea Inicio del proyecto: asignacin y matriculacin del proyecto Planificacin
Descripcin Asignacin y matriculacin del proyecto elegido. Planificar las tareas del proyecto, subtareas y tiempos. 15
3 4 5 6 7
Anlisis de la aplicacin Estudio del lenguaje Diseo de la aplicacin Desarrollo de la aplicacin Pruebas
8 9 10 11
Implementacin Generacin de documentos (memoria del proyecto) Cierre del proyecto Defensa del proyecto
Anlisis de requisitos del sistema. Estudio de lenguaje en el cual se implementara la aplicacin Diseo de las distintas partes que conforman la aplicacin. Desarrollar la aplicacin una vez realizado las fases de anlisis y diseo. Realizacin de pruebas del sistema: Compatibilidad Seguridad Integracin del servicio Segn el tipo de usuario Instalacin y configuracin del sistema en un ordenador Generacin de la memoria del proyecto, detallando los pasos seguidos. Comprobacin de que el proyecto est correctamente concluido. Defensa del proyecto delante de un tribunal.
En la figura 2.1 se muestra una tabla, la primera hace referencia a la planificacin, en la cual aparecen una columna con las horas que se haban previsto para la realizacin del sistema.
Figura 2.1 Tareas del sistema, con duracin prevista.
* 1 da = 24 horas. A continuacin se muestra un diagrama de Gantt, en el cual aparecen las actividades necesarias para desarrollar el sistema. 16
Figura 2.2 Diagrama de Gantt de las tareas del proyecto.
2.4.2. Modelo de desarrollo

Se ha elegido el modelo de desarrollo evolutivo, que es una metodologa de desarrollo de software muy relacionada con, pero claramente distinta de, desarrollo por prototipos. El nfasis est puesto sobre la importancia de obtener un sistema de produccin flexible y expandible. As, si los requerimientos cambian durante el desarrollo del sistema, entonces con un mnimo de esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible. La diferencia fundamental entre desarrollo evolutivo y prototipos de software es que el desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que tendra la propiedad de satisfacer los nuevos requerimientos lo ms rpido posible. En contraste, prototipos usa un enfoque iterativo slo para determinar los requerimientos 17
organizacionales. Por lo tanto el tiempo tomado entre cada iteracin es mucho ms importante para el desarrollo evolutivo. El desarrollo evolutivo asume que los requerimientos de un proyecto estn sujetos a cambios continuos, por lo cual es necesario definir una estrategia de desarrollo que refleje esta situacin. La idea entonces de la metodologa de desarrollo evolutivo es estar liberando constantemente una nueva versin del sistema que sea completamente funcional; as, cada sistema producto de las iteraciones sucesivas del mtodo tendra incorporado los nuevos requerimientos que ha sido posible identificar y que no estaran considerados en la anterior versin. As, las etapas del desarrollo evolutivo tienen por objetivo extender los incrementos de un producto de software operacional, en las direcciones determinadas por la evolucin de la experiencia operacional. El mtodo evolutivo tiene la gran ventaja de reconocer la existencia de una constante de cambios en los requerimientos y, desde esta premisa, propone una solucin, la cual es vlida para la solucin de ese problema pero que no resolvera la inquietud original.
2.5. Conclusiones
Despus de haber analizado el problema, ver qu soluciones existen en la actualidad exterior para solucionar este problema, podemos llegar a las siguientes conclusiones: No existe prcticamente en el mercado un software que se adapte a todas las necesidades buscadas. Los recursos para el desarrollo e implementacin del software no son difciles de conseguir, excepto las pantallas tctiles para la cual se propone como alternativa la utilizacin de ratones. Existe una programacin la cual ayuda para llevar un seguimiento de las mismas. El modelo de desarrollo es idneo para este tipo de proyectos.
Una vez expuestas las conclusiones, la ltima conclusin que se podra extraer es que este proyecto es VIABLE.
18
3. ANALISIS DEL PROYECTO

3.1. Requerimientos funcionales
3.1.1. Visin general
Como ya se ha mencionado, este proyecto tiene como objetivo desarrollar un aplicativo en formato web capaz de dar soporte a la gestin de pedidos de un restaurante y su posterior atencin. Nuestro objetivo comprende desarrollar un sistema de gestin de restaurantes basado en mdulos configurables, que permita automatizar parte del proceso generado por un cliente: ordenar su comida, facturarla, atenderla, etc. El modulo de gestin de pedidos est diseado para contener la informacin de los pedidos que se encuentren activos mediante la utilizacin de una base de datos. Dentro de cada pedido se sabr que productos se ha elegido, y sus caractersticas. Adems existe la posibilidad de mantener y manejar la informacin de los productos ofertados, mesas y datos personales de los clientes. El administrador tiene la posibilidad de modificar toda esta informacin. Existirn al menos cuatro tipos de usuarios a saber: Administrador: Administracin de productos, mesas y facturas. Camarero: Modificacin de pedidos y atencin de los mismos. Cocinero: Atencin de los pedidos, modificacin del estado de cada pedido. Cliente: Creacin de pedidos.
3.1.2. Requisitos funcionales de usuarios

A continuacin se presentan los requisitos funcionales de cada tipo de usuario, con fin de detallar los roles o capacidades de cada uno de ellos en el proyecto. Usuario cliente. Acciones que puede realizar el usuario cliente:
19
o Registrarse Si el cliente desea obtener la factura de su pedido, deber registrarse para que el sistema utilice sus datos personales. Si por alguna razn ajena al sistema, el usuario no desea registrarse, existe la posibilidad de utilizar un tipo de cliente annimo. o Crear pedido. Una vez el cliente haya consultado los productos. o Agregar un producto al pedido. o Visualizar pedido. Siempre puede saber qu productos existen en el pedido y el costo de los mismos (unitario y en general, lo que se lleva gastado). o Modificar el pedido antes de la confirmacin de envo. Antes de enviar el pedido, se preguntar si todos los productos introducidos son los correctos, puesto que una vez confirmado ya no se tiene la posibilidad de modificarlo, slo puede aadir ms productos a su pedido. o Elegir cmo se efectuar el pago del pedido. Elegir la forma de pago entre las opciones: pago en metlico, pago con tarjeta de crdito o Pay-pal. o Elegir el idioma que desee utilizar entre los idiomas disponibles.
Acciones que no puede realizar el usuario cliente: o No puede agregar productos nuevos a la lista de productos ofertados. o Modificar/anular el contenido del pedido una vez haya sido confirmado. Una vez confirmados los productos que componen el pedido, ste ya no tiene posibilidad alguna de sufrir una modificacin o una anulacin. o Varios pedidos desde una misma mesa. Slo es posible realizar un pedido desde una mesa, no hay posibilidad de hacer varios pedidos por mesa. Se puede ir agregando productos al pedido, siempre que no est en estado CERRADO.
20
Usuario personal. Acciones que puede realizar el usuario personal: o Modificar/anular pedidos. Se puede modificar o anular el contenido de un pedido desde este usuario si, y solo si, el producto no tiene estado servido. o Consultar productos ofertados Consultar los productos que estn ofertados.
o Identificar mesas Identificar cada terminal con el nmero de mesa correspondiente. o Elegir el idioma que desee utilizar entre los idiomas disponibles
Acciones que no puede realizar el usuario personal: o Aadir/modificar productos ofertados El administrador es el nico que tiene la posibilidad de aadir o modificar productos.
Usuario cocina. Acciones que puede realizar el usuario cocina: o Cambiar el estado a los productos del pedido. Cada producto pedido debe ser cocinado slo una vez. Para llevar este control, el cocinero es quien modifica el estado de un producto pedido cuando lo ha terminado de preparar. Estados de los productos: COCINA y SERVIDO. Estado de los pedidos: ABIERTO y CERRADO. o Elegir el idioma que desee utilizar entre los idiomas disponibles
Acciones que no puede realizar el usuario cocina: o Modificar el contenido de los pedidos. El usuario cocina, slo puede realizar el cambio de estado de los pedidos que hay en la cola para ser atendidos.
Usuario administrador. Acciones que puede realizar el usuario administrador: 21
o Aadir/modificar cualquier producto. Aadir o modificar cualquier producto a la base de datos para que se pueda ofertar. o Aadir mesas. Aadir nuevas mesas para su posible identificacin. o Elegir el idioma que desee utilizar entre los idiomas disponibles
Acciones que no puede realizar el usuario administrador: o Eliminar productos No puede eliminar productos, slo cambiar su estado, dependiendo si son actualmente ofertados o no. o Eliminar mesas No puede eliminar mesas, slo aadir.
3.1.3. Vistas de casos de uso
Figura 3.1 Vista global de casos de uso.
22
A. Vista de casos de uso para usuario cliente
Figura 3.2 Vista de los casos de uso del usuario Cliente.
B. Vista de casos de uso para usuario personal
Figura 3.3 - Vista de los casos de uso del usuario Personal.
C. Vista de casos de uso para usuario cocina
Figura 3.4 - Vista de los casos de uso del usuario Cocina.
23
D. Vista de casos de uso para usuario administrador
Figura 3.5 - Vista de los casos de uso del usuario Administrador.
A continuacin se detallarn dos casos de uso pertenecientes a usuarios de tipo personal del proyecto. El resto de los casos de uso se encuentran en el Anexo I de esta memoria. CU. Identificar mesa Actor/es Personal Descripcin Introducir el nmero identificador de mesa, quedando identificada la mesa antes de que ningn cliente pueda empezar a utilizar el sistema de gestin. Flujo del 1 - Elegir la opcin MESA. evento 2 - El sistema se iniciar con una ventana en la tendr que seleccionar principal entre las botones disponibles, los cuales representan mesas las mesas libres. 3 Seleccionar la mesa que se desea. 4 - Comprobacin por parte del sistema de que el nombre identificador introducido sea correcto. 5 - El nombre identificador introducido es correcto Flujo del 1 - Elegir la opcin MESA. evento 2 - El sistema se iniciar con una ventana en la tendr que seleccionar alternativo entre las botones disponibles, los cuales representan mesas las mesas libres. 3 Error, no hay ninguna mesa disponible. Precondicin El nombre identificador no est en uso. Postcondicin La mesa queda identificada. 24
CU. Cambiar estado al producto Actor/es Cocinero Descripcin Un pedido est compuesto por productos, y estos mismos tienen unos estados, la funcionalidad es cambiar el estado del producto de ENVIADO SERVIDO 1 - El sistema muestra dos campos para identificarse como usuario Flujo del personal y el password (nombre, password), y la opcin de aceptar evento 2 - Introducir los datos y aceptar. principal 3 - El sistema muestra una cola de productos de pedidos, los cuales se aaden a la cola segn van llegando y se les asigna un estado ENVIADO 4 - Seleccionar la opcin de CAMBIAR del producto que se haya atendido. 5 - El sistema muestra la opcin de confirmar el cambio de estado. 6 - Seleccionar aceptar. 7 - La cola de los productos de los pedidos se refrescar con la cola actualizada. 1 - El sistema muestra dos campos para identificarse como usuario Flujo del personal y el password (nombre, password), y la opcin de aceptar evento 2 - Introducir los datos y aceptar. alternativo 3 - El sistema muestra una cola de productos de pedidos, los cuales se aaden a la cola segn van llegando y se les asigna un estado ENVIADO 4 - Seleccionar la opcin de CAMBIAR del producto que se haya atendido. 5 - El sistema muestra la opcin de confirmar el cambio de estado. 6 - Seleccionar cancelar. 7 Aparece la cola con los mismos productos que haba. Precondicin El producto del pedido tiene que tener el estado ENVIADO Postcondicin El producto del pedido tiene que tener el estado SERVIDO
3.1.4. Diagramas de secuencia

Los diagramas de secuencia tienen como objetivo mostrar la secuencia necesaria para la realizacin de un caso de uso, mostrando el/los actor/es y el/los objeto/s que participan en dicha secuencia. A continuacin se expondrn dos diagramas de secuencia pertenecientes a los diagramas de uso. El resto de los diagramas de secuencia se encuentran en el Anexo II de esta memoria.
25
Diagrama de secuencia (DS) Identificar mesa
Figura 3.5 Diagrama de secuencia de identificar mesa.
Diagrama de secuencia(DS) Cambiar estado al pedido
Figura 3.6 Diagrama de secuencia de cambiar estado al pedido.
3.2. Requerimientos no funcionales

Los siguientes requerimientos no funcionales no forman parte de la funcionalidad del sistema, pero son importantes ya que son restricciones que debe cumplir el sistema. A continuacin se muestran los requerimientos no funcionales de este sistema: Controlar todas las entradas realizadas por los usuarios. 26
La interfaz ha de ser de fcil accesibilidad para cualquier tipo usuario. El sistema debe presentar un tiempo de respuesta corto. El sistema debe impedir el acceso a personas no autorizadas mediante mecanismos de seguridad.
27
4. DISEO
4.1. Introduccin
En este capitulo, se tratar el diseo del sistema, es decir, se describirn las estructuras de la aplicacin y con que se ha desarrollado.
4.1.1. Seleccin del entorno de desarrollo

A continuacin se van a describirn aspectos importantes para el diseo del sistema. Entorno de desarrollo
Eclipse for php developers: En el mercado hay una gran cantidad de productos de programacin en php, la mayora shareware, pero no podemos olvidar los freeware. Un producto de los ms importantes, es Eclipse. Es un software de programacin totalmente gratuito, que lleva tiempo demostrando su hegemona en la programacin Java, despus de posicionarse como un software de desarrollo altamente competitivo entre los paquetes de desarrollo ms profesionales tambin est demostrando su calidad en el desarrollo de php con el plugin de php. Servidor web
Apache: es un servidor web HTTP de cdigo abierto para plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que implementa el protocolo HTTP/1.11 y la nocin de sitio virtual. Apache presenta entre otras caractersticas altamente configurables, bases de datos de autenticacin y negociado de contenido, pero fue criticado por la falta de una interfaz grfica que ayude en su configuracin.
4.1.2. Seleccin de base de datos
Base de datos
MySQL: es un sistema de gestin de base de datos relacional, multihilo y multiusuario. 28
Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia especfica que les permita este uso. Est desarrollado en su mayor parte en ANSI C. Editor de la base de datos
phpMyAdmin: es una herramienta escrita en PHP con la intencin de manejar la administracin de MySQL a travs de pginas web. Actualmente puede crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y aadir campos, ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar datos en varios formatos. Se encuentra disponible bajo la licencia GPL.
29
4.1.3. Diagrama de Entidad-Relacin

Este modelo representa a la realidad a travs de un esquema grfico empleando los terminologa de entidades, que son objetos que existen y son los elementos principales que se identifican en el problema a resolver con el diagrama y se distinguen de otros por sus caractersticas particulares denominadas atributos, el enlace que se rige la unin de las entidades esta representada por la relacin del modelo.
Figura 4.1 Diagrama Entidad-Relacin.
4.2. Estructura de la base de datos

A partir de las entidades y sus interrelaciones, la base de datos constar de 6 tablas. Estas tablas contendrn toda la informacin de las mesas, pedidos, facturas, clientes y productos. 30
Se pasa a detallar el contenido principal de cada una de ellas, el motivo de las relaciones y los tipos de datos ms significativos. En la figura 4.2 se muestran las tablas grficamente.
Figura 4.2 Diagrama de la base de datos.
4.2.1. Contenido de las tablas de la base de datos

Tabla MESA Mesa es el nombre seleccionado para la tabla de las mesas del restaurante, estn disponibles o no. Detalle de los campos de mesa a continuacin: idMesa: Identificador nico de la tabla auto-incremental. Es un entero. nombreMesa: Nombre o nmero con el cual se identifica la mesa. Es un varchar. ocupado: Indica si una mesa si esta libre o no para su posterior eleccin. Es un entero.
Tabla PEDIDO Pedido es el nombre seleccionado para la tabla donde se registrarn los pedidos realizados. Detalle de los campos de pedido a continuacin: idPedido: Identificador nico de la tabla auto-incremental. Es un entero. 31
idMesa: Indica qu mesa es la que realiza el pedido. Es un entero. fecha: Fecha en la se realiza el pedido. Es un date. estado: El estado en que se encuentra el pedido. Puede ser ABIERTO o CERRADO. Es un varchar. totalProductos: Numero total de productos que hay en el pedido. Es un entero.
Tabla PRODUCTO Producto es el nombre elegido para la tabla que almacena la informacin de los diferentes productos ofertados por el restaurante. Estos productos, pueden estar disponibles o no. Detalle de los campos de producto a continuacin: idProducto: Identificador nico de la tabla auto-incremental. Es un entero. nombre: Nombre del producto. Es un varchar. categoria: Categora a la que pertenece el producto. Hay 5 categoras, ENTRANTE, PRIMERO, SEGUNDO, POSTRE y BEBIDA. Es un varchar. tipo: Tipo de producto. Existen distintos tipos de productos, como por ejemplo: , agua, alcohol, arroz, carne, ensalada, fruta, helado, legumbres, pasta, pescado, repostera y verdura.
precioProducto: Precio que tiene el producto. Es un entero. Disponibilidad: Indica si el producto esta disponible. El administrador es quien decide si un producto est disponible o no para que est ofertado a los clientes. Es un entero. imagen: Contiene la ruta donde se encuentra la imagen del producto que se mostrar en distintas partes del sistema. Es un varchar.
Tabla CARRITO Carrito es el nombre elegido para la tabla donde se registrarn el contenido de cada pedido, es decir, los productos que el cliente agreg en su pedido. Detalle de los campos de carrito a continuacin: idPedido: Indica el pedido al que pertenece el producto. Es un entero. 32
idProducto: Indica el producto, el cual pertenece a un pedido. Es un entero cantidad: Indica la cantidad del producto pedido. Es un entero. precio: Indica el precio que tiene el producto por sus unidades. Cantidad del producto * precio del producto (unidad). Es un entero. EstadoProducto: Estado en el que se encuentra el producto pedido. Hay dos tipos de estadoProducto, ENVIADO y SERVIDO. ENVIADO significa que el producto ha sido enviado a cocina y todava no ha sido atendido, SERVIDO significa que el producto ha sido atendido en cocina y se ha servido a su respectiva mesa. Es un varchar.
Tabla CLIENTE Cliente el nombre de la tabla donde se registrarn los datos personales de los clientes, si un cliente no desea registrar sus datos, puede utilizar la opcin de cliente annimo, el cual es un tipo de cliente con valores por defecto y para el cual no se genera un nuevo registro en la tabla CLIENTE de la Base de datos. Detalle de los campos de cliente a continuacin: idCliente: Identificador nico de la tabla auto-incremental. Es un entero. dni: Numero de DNI del cliente. Es un entero. pass: Password perteneciente al cliente. Es un varchar. Cifrado md5. nombre: Nombre del cliente. Es un varchar. pApellido: Primero apellido del cliente. Es un varchar. sApellido: Segundo apellido del cliente. Es un varchar. mail: e-mail del cliente. Es un varchar.
Tabla FACTURA Factura es el nombre elegido para la tabla donde van a quedar registradas las facturas de los pedidos una vez que hayan sido cerrados.
33
Detalle de los campos de factura a continuacin: idFactura: Identificador nico de la tabla auto-incremental. Es un entero. idPedido: Indica el pedido para el que se realiza la factura. Es un entero. idCliente: Indica el cliente. Es un entero. fecha: Fecha en la se realiza el pedido. Es un date. modoPagar: Modalidad a pagar. Hay 3 formas de pago, EFECTIVO, TARJETA y PAYPAL. totalFactura: Indica el precio total de la factura, incluyendo el IVA. Es un entero.
4.3. Arquitectura de la aplicacin

La aplicacin utiliza una arquitectura cliente servidor.
Figura 4.1 Arquitectura de la aplicacin, cliente-servidor.
34
5. IMPLEMENTACIN
5.1. Introduccin
Se ha implementado toda la funcionalidad que se ha propuesto anteriormente. Las ms caractersticas segn los roles de los usuarios son: Administrador: Gestin de productos, mesas y facturas. Camarero: Modificar pedidos. Cocinero: Modificar estado de los producto pedidos. Cliente: Realizar pedidos y pagar facturas.
5.2. Codificacin de las diferentes capas de la aplicacin

A continuacin se mostrarn las capturas de pantalla ms importantes del sistema, correspondientes a los diferentes usuarios del sistema.
5.2.1. Interfaces
A. Usuario administrador
Figura 5.1 Interfaz usuario Administrador.
35
B. Usuario cliente
Figura 5.2 Interfaz de consultar producto.
C. Usuario personal
Figura 5.3 Interfaz de identificar mesa.
36
D. Usuario cocina
Figura 5.4 Interfaz de administracin de pedidos
5.2.2. Entorno de usuarios
Como ya se ha mencionado se ha conseguido implementar todos los objetivos para los distintos usuarios. Se pasa a detallarlos ms concretamente a continuacin: Administrador: o Gestin de productos: altas y modificaciones de los productos en la aplicacin. o Gestin de mesas: altas y modificaciones de las mesas. o Consulta de facturas: consultar datos referentes a las facturas. Camarero: o Gestin de pedidos: modificar el contenido del pedido, aadiendo o eliminando un producto, dependiendo del estado en el que se encuentre. Cocinero: o Gestin de pedidos: modificar el estado de los productos de los pedidos. Cliente: o Creacin de pedidos: realizar pedidos desde el terminal de la mesa. 37
o Pago de facturas: pagar las facturas creadas a partir de los pedidos.
5.2.3 Motor de aplicacin

La aplicacin se ha desarrollado sobre distintos lenguajes de programacin que otorgan la capacidad y flexibilidad oportunas. En mayor parte se ha desarrollado en PHP, donde se encuentra el motor principal de la aplicacin. Por otra parte, se ha implementado en Java Script el control de los campos de los formularios para evitar campos vacos, as como tipo de contenido adecuado para prevenir ataques de SQL injection. Dentro del Java Script encontramos tambin Ajax que da un aspecto dinmico a la web. Para finalizar, se ha utilizado CSS (Cascading Style Sheets) para dar el diseo fsico de la aplicacin. Se ha utilizado el patrn de diseo de software MVC (Modelo Vista Contrlador), que separa los datos en una aplicacin, la interfaz de usuario, y la lgica de control entre capas distintas (como se ilustra en la Figura 5.5).
Figura 5.5 Estructura modelo MVC.
A continuacin se explican detalladamente las capas del modelo MVC: Modelo: Esta es la representacin especfica del dominio de la informacin sobre la cual funciona la aplicacin, es la lgica de negocio. Su funcin es la de llevar a cabo 38
operaciones solicitadas y dar una respuesta a las mismas, aadiendo significado a los datos. Vista: Representa el modelo en un formato adecuado para interactuar, usualmente a travs de una interfaz de usuario. Cuando un actor hace una solicitud desde una vista, ste se comunica con un controlador y espera a que el mismo le d una respuesta. Controlador: Su funcin es la de redirigir la solicitud de una vista al componente del modelo adecuado mediante un mapeo definido.
Como parte interesante a destacar del cdigo encontraramos el encabezado de cada pgina.php (Figura 5.6). Este encabezado se encarga de controlar las variables de sesin desautorizadas.
Figura 5.6 Cdigo PHP, en el cual aparecen variables de sesin.
Tambin se puede observar cmo se cargan (lnea 11-12) las clases y posteriormente se hace una instancia de las clases (lnea 16-17).
39
Figura 5.7 Clase mesa.php
Se puede observar en la figura 5.7, que en la parte izquierda se encuentran las clases en la carpeta class, y a la derecha se puede observar la clase mesa con sus atributos.
Algunos mdulos de la aplicacin utilizan la tecnologa Ajax ( Asynchronous JavaScript And XML). Es una tcnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicacin asncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las pginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones.
A continuacin se muestra el cdigo Ajax(Figura 5.8), el cual pertenece a actualizar datos de la mesa y al de cambiar el estado del producto de un pedido.
40
Figura 5.8 Funciones Ajax (jquery.functions.js)
5.2.4. Capa de datos

La aplicacin se ha desarrollado con una base de datos en MySQL, segn el diseo original previsto. As, toda la informacin queda almacenada en sus respectivas tablas. Se cree conveniente destacar que gestionan las mesas, con variables de sesin, es decir, se controla desde qu mesa se realiza cada pedido. Esto otorga una seguridad extra que no proporcionan las cookies. No se cree destacable ninguna otra parte siendo la mayora del cdigo consultas a la base de datos (como por ejemplo, ilustra la Figura 5.9).
Figura 5.9 Consulta MySQL para listar el contenido de los pedidos.
41
6. PRUEBAS
Se han efectuado varias pruebas para comprobar la solidez y robustez de la aplicacin. Como se puede ver a continuacin, se han efectuado pruebas de compatibilidad, de seguridad y de integracin de servicio o funcionamiento.
6.1. Pruebas de compatibilidad

Las pruebas de compatibilidad ayudan a determinar si el producto funcionar correctamente con otro software en el entorno de operacin esperado.
Se ha probado el funcionamiento de la aplicacin en los navegadores, I.Explorer, Mozilla Firefox y Google Chrome. Se han probado para todos ellos todas las opciones de la aplicacin. Se ha conseguido un resultado satisfactorio, por lo que el motor de la aplicacin funciona correctamente. Por el contrario, se ha detectado un problema de compatibilidades con I.Explorer en el entorno grfico, donde algunos marcos no obtienen el tamao correcto. Se le ha restado importancia al ser un problema de esttica y que no afecta al correcto funcionamiento del aplicativo. Cabe destacar que la aplicacin valida los estndares de World Wide Web Consortium (W3C, http://validator.w3.org) tanto en HTML como en CSS.
6.2. Pruebas de seguridad

Como se deca en captulos anteriores, cada usuario tendr un rol definido as como una interfaz propia. Para esto se ha tratado de acceder logeado o sin logear en categoras que no son propias. El resultado ha sido la expulsin de la aplicacin. Adems se ha intentado acceder a la aplicacin con usuarios o contraseas incorrectas, con el mismo resultado, obviamente. Finalmente, se ha probado a introducir una inyeccin de SQL en el login, que tambin ha sido bloqueada.
42
6.3. Pruebas de integracin de servicio

En la seccin anterior, seccin 6.2: Pruebas de compatibilidad, se prob el funcionamiento de la aplicacin, para todas sus opciones y en diferentes navegadores. Por esto se puede concluir que, el funcionamiento de la aplicacin, ha sido correcta soportando todos los tests de pruebas realizados.
6.4. Pruebas segn el tipo de usuario

A continuacin se han realizado distintas pruebas, utilizando la interfaz grafica como medio de realizacin de las mismas.
6.4.1. Usuario administrador

A. Subir imgenes de productos Los productos del sistema llevan asociados una imagen, la cual ser mostrada a la hora de que un cliente pueda consultar los productos y crear un pedido.
Figura 6.1 Imagen asociada a un producto.
Se ha aadido un producto con su respectiva imagen. Los archivos aceptados tienen que tener la extensin, .jpg, .gif, .png y .bmp. El sistema debe detectar si el archivo adjunto esta existe ya en el sistema, o si la extensin no coincide con las arriba mencionadas.
43
Figura 6.2 Control de archivos subidos, error archivo no permitido (archivo: pruebas.php)
Despus de haber insertado varios productos en el sistema se puedo concluir que el sistema realiza este paso correctamente.
B. Control de usuarios El sistema tiene varias reas restringidas, las cuales son accesibles dependiendo del usuario introducido. El sistema debe detectar si el usuario introducido es correcto, y si lo es, redireccionarlo hasta el rea designada a dicho usuario. (Ejemplo: el usuario administrador acceder al rea correspondiente al administrador).
Figura 6.3 Control de usuarios, error datos incorrectos
44
Figura 6.4 Validacin de usuario correcta.
Despus de haber introducido varios usuarios con sus respectivos Password, se puede concluir que el sistema detecta cules usuarios forman parte del sistema y cules no.
6.4.2. Usuario cliente

A. Finalizar un pedido Para que un pedido se pueda finalizar, es necesario que todos los productos pertenecientes a dicho pedido tengan el estado SERVIDO. Para que un producto obtenga el estado servido, primero debe ser atendido por el usuario cocina.
Figura 6.5 El sistema muestra el pedido finalizado con las opciones de pago.
45
Se ha creado un pedido, despus de enviar el pedido ha cocina, se ha seleccionado la opcin de FINALIZAR.
Figura 6.6 Solicitar factura, con teclado tctil.
Despus de haber realizado varios pedidos, se ha comprobado que el sistema efecta este paso correctamente.
6.4.3. Usuario personal

A. Cambiar pedido Un pedido al ser creado obtiene el estado de ABIERTO. Los pedidos estn compuestos de productos los cuales tienen dos estados, ENVIADO o SERVIDO. Un pedido se puede cambiar, si tiene el estado ABIERTO, aadindole productos, eliminado productos que tengan el estado ENVIADO o modificando la cantidad del producto con estado ENVIADO. Se ha seleccionado un pedido con el estado ABIERTO, el cual ha sido modificado segn los cambios posibles, mencionados arriba.
46
Figura 6.6 Listado de pedidos con estado ABIERTO.
Figura 6.7 Contenido de un pedido, con las opciones de aadir producto y modificarla cantidad.
El sistema debe detectar qu opcin se ha escogido, entre las de aadir producto, modificar cantidad o eliminar producto, y actuar correspondientemente actualizando el pedido correspondiente.
47
6.4.4. Usuario cocina

A. Cambiar el estado de un producto de un pedido. Se ha seleccionado un producto de un pedido con estado ENVIADO, y se ha seleccionado la opcin de cambiar estado.
Figura 6.8 Interfaz para cambiar el estado del producto, usuario cocina
El resultado de dicha accin, debe de ser la actualizacin de la lista sin el producto atendido, y que el sistema avise de que el producto ha sido servido.
Figura 6.9 Alerta del sistema, indicando que el producto ha cambiado de estado
Despus de haber realizado el cambio de estado de productos con varios pedidos, no se ha encontrado ningn error, y el resultado de dicha accin es el esperado.
48
7. CONCLUSIONES Y RESULTADOS
7.1. Consecucin de objetivos
En este trabajo, se han propuesto los siguientes 6 objetivos: Mejorar la gestin actual de los pedidos realizados por los clientes. Agilizar y mejorar el proceso de la informacin centralizada. Informacin centralizada se entiende como pedidos, informacin de productos y facturas. Detectar fallos/errores entre los tericos productos ofertados y los reales: actualizacin de productos. Comprobar que los productos ofertados son los correctos. Generar una cuenta/factura al finalizar el servicio. Ha de recoger informacin referente a los productos consumidos y el precio de los mismos. Los usuarios se han de identificar para utilizar la aplicacin. Implementar un sistema para el control de permisos. Mejorar la implicacin del sistema con el cliente. De estos objetivos se puede afirmar que se han concluido exitosamente todos ellos.
7.2. Desviaciones observadas

Se ha producido una desviacin del calendario prevista, en el captulo 2, apartado 2.4, aparece el diagrama de Gantt del calendario previsto (figura 2.2), aparte aparece el nmero de horas previstas y el nmero de horas reales (figura 2.1).
Se haba previsto trabajar 7 horas semanales, de lunes a viernes, pero las 7 horas semanales previstas no han sido suficientes, a medida que se avanzaba en el trabajo se han ido ampliando la cantidad de horas. Adems se ha visto una prolongacin en la duracin de algunas tareas, respecto al tiempo que se tena previsto.
49
Figura 7.1 Duracin prevista y real de las tareas.
Cabe mencionar, que al ser el primer proyecto que se realiza desde el principio, han surgido problemas desconocidos, como los relacionados con el lenguaje ya que el lenguaje utilizado era desconocido antes de realizar el proyecto, o incluso la propia memoria al no haber realizado ninguna de este tipo haba fases que han resultado mas complejas.
7.3. Lneas de ampliacin

La aplicacin desarrollada es ampliable en diferentes aspectos segn necesidades posteriores al uso. Se citan algunas lneas posibles de ampliacin: Mejorar el aspecto esttico de la aplicacin web. Ampliacin de mdulos del sistema, es decir, aadir funcionalidades nuevas al sistema como control de stock, mapa de mesas, aadir anotaciones, etctera.
7.4. Valoracin personal de la experiencia

Como la mayora de las experiencias nuevas, he obtenido muchos puntos positivos de este proyecto. He aprendido a desarrollar un proyecto desde su comienzo, sobr etodo la memoria. He mejorado mis conocimientos de programacin web. He aprendido a tener que rehacer o mejorar parte del trabajo pues no era exactamente lo que se precisaba. En el proceso de desarrollo he cumplido de forma correcta los pasos de ingeniera del software para el desarrollo de una aplicacin web, el cual ha sido bastante productivo ya que 50
antes no haba realizado ningn desarrollo siguiendo dichos pasos. He conseguido adquirir una metodologa de trabajo que no tena, la cual es necesaria para un trabajo como este. He adquirido como: estudiar y realizar el estado del arte de un tema especfico, realizar un anlisis de requerimientos completo, disear un sistema informtico. A todo esto, se le suma el conocimiento adquirido mediante el estudio de los nuevos lenguajes de programacin y distintas herramientas informticas. Todos los objetivos propuestos (tanto a nivel de desarrollo como de escritura, de investigacin, etc.) los he cumplido de forma correcta. En general, he ganado experiencia en muchos aspectos psicolgicos y ganado virtudes de todo en general. Por lo tanto slo me queda concluir que, pese a haberme encontrado con problemas puntuales, ha sido una experiencia muy positiva y gratificante.
51
8. ANEXO I: CASOS DE USO

Caso de uso 1 Identificar mesa. CU1 - Identificar mesa Actor/es Personal Descripcin Introducir el nombre identificador de mesa, quedando identificada la mesa antes de que ningn cliente pueda empezar a utilizar el sistema de gestin. Flujo del 1 - Elegir la opcin MESA. evento 2 - El sistema se iniciara con una ventana en la tendr que seleccionar principal el nombre identificador de las mesas disponibles. 3 - Confirmacin por parte del usuario de que los datos introducidos son correctos. 4 - Comprobacin por parte del sistema de que el nombre identificador introducido sea correcto. 5 - El nombre identificador introducido es correcto. Flujo del 1 - Elegir la opcin MESA. evento 2 - El sistema se iniciara con una ventana en la tendr que seleccionar alternativo el nombre identificador de las mesas disponibles. 3 - Confirmacin por parte del usuario de que los datos introducidos son correctos. 4 Error, no hay ninguna mesa disponible. Precondicin El nombre identificador no este en uso. Postcondicin El nombre identificador este en uso.
Caso de uso 2 Cambiar estado al producto. CU2 Cambiar estado al producto Actor/es Cocina Descripcin Un pedido esta compuesto por productos, y estos mismos tienen unos estados, la funcionalidad es cambiar el estado del producto de ENVIADO SERVIDO 1 - El sistema muestra dos campos para identificarse como usuario Flujo del personal y el Password (nombre, password), y la opcin de aceptar evento 2 - Introducir los datos y aceptar. principal 3 - El sistema muestra una cola de productos de pedidos, los cuales se aaden a la cola segn van llegando y se les asigna un estado ENVIADO 4 - Seleccionar la opcin de CAMBIAR del producto que se haya atendido. 5 - El sistema muestra la opcin de confirmar el cambio de estado. 6 - Seleccionar aceptar. 52
7 - La cola de los productos de los pedidos se refrescara con la cola actualizada. 1 - El sistema muestra dos campos para identificarse como usuario Flujo del personal y el password (nombre, password), y la opcin de aceptar evento 2 - Introducir los datos y aceptar. alternativo 3 - El sistema muestra una cola de productos de pedidos, los cuales se aaden a la cola segn van llegando y se les asigna un estado ENVIADO 4 - Seleccionar la opcin de CAMBIAR del producto que se haya atendido. 5 - El sistema muestra la opcin de confirmar el cambio de estado. 6 - Seleccionar cancelar. 7 - La cola de los productos de los pedidos se refrescara con la cola actualizada. Precondicin El producto del pedido tiene que tener el estado ENVIADO Postcondicin El producto del pedido tiene que tener el estado SERVIDO
Caso de uso 3 Consultar producto. CU3 Consultar producto Actor/es Administrador, cliente. Descripcin Buscar/observar los distintos productos disponibles, a travs de las diferentes opciones y pasar de una opcin a otra con facilidad. Flujo del Cliente evento 1- El sistema muestra las distintas opciones para buscar productos principal disponibles (entrantes, primer plato, segundo plato, postres, bebidas) la opcin de crear pedido, cambiar el idioma y la opcin de liberar. 2 Seleccionar una opcin de bsqueda de productos disponibles. 3 El sistema muestra la imagen de los distintos productos disponibles de la opcin elegida (nombre, precio, tipo). 4. Situarse encima de la imagen del producto para ver las caractersticas del producto. 5 Seleccionar la opcin de crear pedido. Administrador 1 - El sistema muestra las distintas opciones para buscar productos disponibles (entrantes, primer plato, segundo plato, postres, bebidas) la opcin de volver y cambiar el idioma. 2 - Seleccionar una opcin de bsqueda de productos disponibles. 3 El sistema muestra un listado con los productos de la categora escogida, con la opcin de modificar el producto. 1- El sistema muestra las distintas opciones para buscar productos disponibles (entrantes, primer plato, segundo plato, postres, bebidas, 53
Flujo del evento
alternativo
men, recomendaciones), la opcin de crear pedido y cambiar el idioma. 2 Seleccionar una opcin de bsqueda de productos disponibles. 3 El sistema muestra los distintos productos disponibles de la opcin elegida, y la opcin volver para poder volver al men de opciones de bsqueda. 4 Observar los productos disponibles de la opcin seleccionada. 5 - Volver al men de opciones. 6 Elegir otra opcin de bsqueda diferente a la anterior. 7 Observar los productos disponibles de la opcin seleccionada. Precondicin Cliente - La mesa desde la cual se consulta el pedido debe de estar identificada correctamente. Administrador El usuario debe de estar validado correctamente como usuario personal. Postcondicin Deben aparecer los productos disponibles de la opcin elegida.
Caso de uso 4 Crear pedido. CU4 Crear pedido Actor/es Cliente Descripcin Observados los productos o no, ser necesario crear un pedido para su posterior envo. Flujo del 1- Seleccionar crear pedido. evento 2 El sistema muestra las distintas opciones para buscar productos principal disponibles (entrantes, primer plato, segundo plato, postres, bebidas, men, recomendaciones), la opcin de crear pedido y cambiar el idioma. 3 Arrastrar los productos que se deseen a la parte inferior, donde aparece la imagen de una libreta. 4 Una vez se han aadido los productos deseados, apretar el botn enviar. 5 El sistema pedir que se confirme el envo o se cancele, aceptar. 6 El pedido ha sido enviado a cocina. Flujo del 1- Seleccionar crear pedido. evento 2 El sistema muestra las distintas opciones para buscar productos alternativo disponibles (entrantes, primer plato, segundo plato, postres, bebidas, men, recomendaciones), la opcin de crear pedido y cambiar el idioma. 3 Arrastrar los productos que se deseen a la parte inferior, donde aparece la imagen de una libreta. 4 Una vez se han aadido los productos deseados, apretar el botn enviar. 54
5 El sistema pedir que se confirme el envo o se cancele, cancelar. 6 El pedido no ha sido enviado a cocina. Precondicin No puede haber otro pedido creado desde la misma mesa. Postcondicin El nombre identificador de la mesa debe de estar relacionado con el pedido creado. El pedido ha de aparecer con el estado ABIERTO.
Caso de uso 5 Aadir producto al pedido. CU5 Aadir producto al pedido Actor/es Cliente, personal Descripcin Aadir productos ofertados disponibles, a un pedido creado Flujo del Cliente evento 1 El sistema muestra las distintas opciones para buscar productos principal disponibles (entrantes, primer plato, segundo plato, postres, bebidas, men, recomendaciones), la opcin de crear pedido y cambiar el idioma. 2 Arrastrar los productos que se deseen a la parte inferior, donde aparece la imagen de una libreta. 3 Seleccionar la cantidad del producto elegido. 4 Apretar el botn de enviar. 5 El sistema pedir que se confirme el envo, aceptar. Personal 1 El sistema muestra un listado con los pedidos en estado ABIERTO. 2 Seleccionar el pedido que se desee y apretar la opcin de abrir el contenido del mismo. 3 Seleccionar la opcin de aadir producto. 4 El sistema muestra un listado de productos disponibles segn la categora elegida. 5 Marcar la casilla de los productos a aadir y la cantidad deseada. 6 Aceptar la insercin en el pedido de los productos. Cliente 1 El sistema muestra las distintas opciones para buscar productos disponibles (entrantes, primer plato, segundo plato, postres, bebidas, men, recomendaciones), la opcin de crear pedido y cambiar el idioma. 2 Arrastrar los productos que se deseen a la parte inferior, donde aparece la imagen de una libreta. 3 Seleccionar la cantidad del producto elegido. 4 Apretar el botn de enviar. 5 El sistema pedir que se confirme el envo, cancelar. 55
Flujo del evento alternativo
Personal 1 El sistema muestra un listado con los pedidos en estado ABIERTO. 2 Seleccionar el pedido que se desee y apretar la opcin de abrir el contenido del mismo. 3 Seleccionar la opcin de aadir producto. 4 El sistema muestra un listado de productos disponibles segn la categora elegida. 5 Marcar la casilla de los productos a aadir y la cantidad deseada. 6 Aceptar la insercin en el pedido de los productos. 7 Error, la cantidad introducida de productos tiene que ser => 1 Precondicin El pedido debe de estar creado y con estado ABIERTO. Postcondicin El pedido contiene el producto elegido
Caso de uso 6 Eliminar producto del pedido. CU6 Eliminar producto del pedido Actor/es Cliente, personal Descripcin Eliminacin de un producto del pedido, que todava no haya sido enviado ni finalizado sin necesidad de cancelar el pedido. Flujo del Cliente evento 1 - El sistema muestra las distintas opciones para buscar productos principal disponibles (entrantes, primer plato, segundo plato, postres, bebidas, men), una zona para arrastrar los productos seleccionados y la opcin de enviar. 2 - Seleccionar el producto del pedido que se quiere eliminar. 3 Elegir la opcin de borrar el producto. 4 El producto esta eliminado del pedido. Personal 1 El sistema muestra un listado con los pedidos en estado ABIERTO. 2 Seleccionar el pedido que se desee y apretar la opcin de abrir el contenido del mismo. 3 Seleccionar el producto que se desee eliminar y apretar la opcin de modificar. 4 Indicar el numero de productos deseado, tanto si se desea reducir la cantidad de un producto o si se quiere eliminar, en este caso se introducir el numero 0. 5 Aceptar la modificacin. Cliente 1 - El sistema muestra las distintas opciones para buscar productos 56
Flujo del evento
alternativo
disponibles (entrantes, primer plato, segundo plato, postres, bebidas, men), el pedido (idPedido, idMesa, fecha, estado) con los productos (idProducto, nombre, precio, cantidad) y las opciones de enviar, cancelar y finalizar el pedido. 2 - Seleccionar el producto del pedido que se quiere eliminar. 3 Elegir la opcin de borrar el producto. 4 El sistema muestra una advertencia de que el producto va a ser eliminado, hay que confirmar o cancelar. 5 Cancelar la eliminacin del producto. 6 El producto esta en el pedido.
Personal 1 El sistema muestra un listado con los pedidos en estado ABIERTO. 2 Seleccionar el pedido que se desee y apretar la opcin de abrir el contenido del mismo. 3 Seleccionar el producto que se desee eliminar y apretar la opcin de modificar. 4 Indicar el numero de productos deseado, tanto si se desea reducir la cantidad de un producto o si se quiere eliminar, en este caso se introducir el numero 0. 5 Error, no se ha introducido un nmero. Precondicin El pedido esta creado, y no tiene estado CERRADO. El producto a eliminar aparece en el pedido. Postcondicin El pedido aparece sin el producto seleccionado.
Caso de uso 7 Aadir mesa. CU7 Aadir mesa Actor/es Administrador Descripcin Aadir una mesa a listado de mesas disponibles. Flujo del 1 Seleccionar aadir mesa. evento 2 Introducir el nombre/numero deseado para la nueva mesa. principal 3 Apretar el botn de enviar. 4 Aparece un listado con las mesas del sistema. Flujo del 1 Seleccionar aadir mesa. evento 2 Introducir el nombre/numero deseado para la nueva mesa. alternativo 3 Apretar el botn de cancelar. 4 Error, el nombre/numero elegido esta en uso. Precondicin El nombre/numero ha introducir no este elegido. Postcondicin La mesa este creada y aparezca como disponible.
57
Caso de uso 8 Modificar mesa. CU8 Modificar mesa Actor/es Administrador Descripcin Modificar el nombre/numero de la mesa seleccionada. Flujo del 1 Seleccionar la mesa que se desee del listado de las mesas evento existentes en el sistema. principal 2 El sistema muestra la posibilidad de cambiar el nombre/numero de la mesa seleccionada. 3 Apretar enviar. 4 El sistema muestra la lista de las mesas existentes. Flujo del 1 Seleccionar la mesa que se desee del listado de las mesas evento existentes en el sistema. alternativo 2 El sistema muestra la posibilidad de cambiar el nombre/numero de la mesa seleccionada. 3 Apretar cancelar. 4 El sistema muestra la lista de las mesas existentes. Precondicin El nombre/numero a introducir no este elegido Postcondicin La mesa aparezca con el nombre/numero modificado
Caso de uso 9 Pagar factura. CU9 Pagar factura Actor/es Cliente Descripcin Eleccin del mtodo de pagar factura. Flujo del 1 El sistema mostrara el contenido del pedido, el precio de cada evento producto y el precio total, aparte tres opciones de pago: efectivo, principal tarjeta y pay-pal. 2 Seleccionar la opcin deseada para realizar el pago. 3 Decidir si se quiere registrar como usuario, validar el usuario o finalizar como annimo. A. Registrar Introducir los datos que pide el sistema y enviar. B. Validar Introducir los datos que pide el sistema y enviar. C. Annimo Presionar la opcin de finalizar. 4 El sistema comprobara la opcin elegida. 5 Factura pagada. Flujo del 1 El sistema mostrara el contenido del pedido, el precio de cada evento producto y el precio total, aparte tres opciones de pago: efectivo, alternativo tarjeta y pay-pal. 2 Seleccionar la opcin deseada para realizar el pago. 3 Decidir si se quiere registrar como usuario, validar el usuario o finalizar como annimo. 58
A. Registrar Introducir los datos que pide el sistema y enviar. B. Validar Introducir los datos que pide el sistema y enviar. C. Annimo Presionar la opcin de finalizar. 4 El sistema comprobara la opcin elegida. 5 Error. A. Registrar Datos introducidos son incorrectos. B. Validar Usuario o contrasea incorrectos. Precondicin El pedido debe de estar finalizado. Postcondicin La factura creada con los datos del pedido y el cliente.
Caso de uso 10 Registrar cliente CU10 Registrar cliente Actor/es Cliente Descripcin Registro de un cliente como usuario de la aplicacin para el posterior envo de la factura al mail. Flujo del 1 Seleccionar la opcin de nuevo cliente. evento 2 Introducir los datos personales en los campos que se pide, a travs principal del teclado virtual. 3 A continuacin enviar los datos. 4 El sistema comprobara que los datos introducidos sean correctos y no existan. 5 El usuario queda registrado. Flujo del 1 Seleccionar la opcin de nuevo cliente. evento 2 Introducir los datos personales en los campos que se pide, a traves alternativo del teclado virtual. 3 A continuacin enviar los datos. 4 El sistema comprobara que los datos introducidos sean correctos y no existan. 5 Error, datos introducidos incorrectos. Precondicin El usuario no esta dado de alta como usuario de la aplicacin. Postcondicin El usuario esta dado de alta como usuario de la aplicacin.
Caso de uso 11 Validar cliente. CU11 Validar usuario Actor/es Administrador, cliente, cocina, personal. Descripcin Recordar al sistema que el usuario ya ha sido cliente de la aplicacin. Flujo del 1 Introducir el DNI y el pass en los campos que se pide a travs del evento teclado virtualprincipal 2 A continuacin enviar los datos. 59
3 El sistema comprobara que los datos introducidos sean correctos. 4 El usuario queda registrado. Flujo del 1 Introducir el DNI y el pass en los campos que se pide a travs del evento teclado virtualalternativo 2 A continuacin enviar los datos. 3 El sistema comprobara que los datos introducidos sean correctos. 4 Error, el usuario o contrasea no son correctos. Precondicin El usuario debe de estar dado de alta. Postcondicin El usuario se ha validado correctamente.
Caso de uso 12 Aadir producto CU12 Aadir producto Actor/es Administrador Descripcin Aadir un producto al sistema. Flujo del 1 Seleccionar la opcin de aadir producto. evento 2 Introducir los datos del producto en los campos correspondientes. principal 3 Seleccionar la fotografa del producto que se desee aadir. Solo estn permitidos archivos con extensiones, .jpg, .gif, .bpm y .png. 4 Aceptar la introduccin del producto. 5 El sistema comprueba que los datos introducidos son correctos. 6 El sistema muestra la lista de productos. Flujo del 1 Seleccionar la opcin de aadir producto. evento 2 Introducir los datos del producto en los campos correspondientes. alternativo 3 Seleccionar la fotografa del producto que se desee aadir. Solo estn permitidos archivos con extensiones, .jpg, .gif, .bpm y .png. 4 Aceptar la introduccin del producto. 5 El sistema comprueba que los datos introducidos son correctos. 6 Error, el archivo ya existe. Precondicin El producto no este creado. Postcondicin El producto aparece en la lista actualizada.
Caso de uso 13 Modificar producto. CU13 Modificar producto Actor/es Administrador Descripcin Cambiar algn dato de un producto. Flujo del 1 El sistema muestra un listado de los productos segn la categora evento escogida. 60
principal
2 Seleccionar el producto deseado y seleccionar la opcin de modificar. 3 Cambiar los datos que se crean convenientes. 4 Aceptar la modificacin del producto. 5 El sistema comprueba que los datos modificados son correctos. 6 El sistema muestra la lista de productos. Flujo del 1 El sistema muestra un listado de los productos segn la categora evento escogida. alternativo 2 Seleccionar el producto deseado y seleccionar la opcin de modificar. 3 Cambiar los datos que se crean convenientes. 4 Aceptar la modificacin del producto. 5 El sistema comprueba que los datos modificados son correctos. 6 Error los datos modificados son incorrectos. Precondicin El producto debe de estar creado. Postcondicin El producto debe aparece en la lista con los datos modificados
Caso de uso 14 Consultar saldo. CU14 Consultar saldo Actor/es Administrador Descripcin Consultar el dinero obtenido con los pedidos en una determinada fecha o un rango de fechas. Flujo del 1 Seleccionar la opcin de FACTURAS. evento 2 Introducir la fecha o el rango de fechas que se desee consultar , a principal traves del calendario. Si se desea solo una fecha, introducir la misma fecha en los dos campos (desde, hasta). 3 Presionar buscar. 4 El sistema buscara las facturas pertenecientes a la fecha elegida. 5 El sistema mostrara un listado con las facturas del da o das seleccionados y el total de las facturas. Flujo del evento alternativo 1 Seleccionar la opcin de FACTURAS. 2 Introducir la fecha o el rango de fechas que se desee consultar , a travs del calendario. Si se desea solo una fecha, introducir la misma fecha en los dos campos (desde, hasta). 3 Presionar buscar. 4 El sistema buscara las facturas pertenecientes a la fecha elegida. 5 Error, la fecha introducida no puede ser posterior a la del da de hoy. Precondicin La fecha tiene que ser igual a la del da de hoy o das anteriores. Postcondicin Las facturas pertenecientes a la fecha escogida. 61
Caso de uso 15 Finalizar pedido CU16 Finalizar pedido Actor/es Cliente Descripcin Proceso mediante el cual un pedido pasa a estado CERRADO y a partir de ah se puede crear una factura. Flujo del 1 Seleccionar la opcin de finalizar el pedido, FINALIZAR. evento 2 El sistema pide confirmacin para finalizar el pedido, aceptar. principal 3 El pedido ha sido finalizado. Flujo del 1 Seleccionar la opcin de finalizar el pedido, FINALIZAR. evento 2 El sistema pide confirmacin para finalizar el pedido, aceptar. alternativo 3 Error, todos los productos deben de estar servidos para finalizar. Precondicin Todos los productos deben de tener el estado SERVIDO para poder finalizarse Postcondicin El pedido pasa a tener el estado CERRADO
62
9. ANEXO II: DIAGRAMAS DE SECUENCIA

Diagrama de secuencia 1 Identificar mesa.
Figura A2.1 Diagrama de secuencia de identificar mesa.
Diagrama de secuencia 2 Cambiar estado al pedido.
Figura A2.2 Diagrama de secuencia de cambiar estado al producto.
63
Diagrama de secuencia 3 Consultar producto.
Figura A2.3 Diagrama de secuencia de consultar producto.
Diagrama de secuencia 4 Crear pedido.
Figura A2.4 Diagrama de secuencia de crear pedido.
64
Diagrama de secuencia 5 Aadir producto al pedido.
Figura A2.5 Diagrama de secuencia de aadir producto al pedido.
Diagrama de secuencia 6 Eliminar producto del pedido.
Figura A2.6 Diagrama de secuencia eliminar producto del pedido.
65
Diagrama de secuuencia 7 Aadir mesa.
Figura A2.7 Diagrama de secuencia de aadir mesa
Diagrama de secuencia 8 Modificar mesa.
Figura A2.8 Diagrama de secuencia de modificar mesa.
66
Diagrama de secuencia 9 Pagar factura
Figura A2.9 Diagrama de secuencia de pagar factura.
Diagrama de secuencia 10 Registrar cliente
Figura A2.10 Diagrama de secuencia de registrar cliente.
67
Diagrama de secuencia 11 Validar usuario
Figura A2.11 Diagrama de secuencia de validar usuario.
Diagrama de secuencia 12 - Aadir producto
Figura A2.12 Diagrama de secuencia de aadir producto.
68
Diagrama de secuencia 13 Modificar producto.
Figura A2.13 Diagrama de secuencia de modificar producto
Diagrama de secuencia 14 Consultar saldo.
Figura A2.14 Diagrama de secuencia de consultar saldo.
69
Diagrama de secuencia 15 Finalizar pedido
Figura A2.15 Diagrama de secuencia de finalizar pedido.
70
10. BIBLIOGRAFIA
A continuacin se exponen las diversas fuentes de bibliografa que han sido necesarias para la realizacin del proyecto. Durante el mismo se, han hecho dos tipos de consultas bibliogrficas:
10.1. Programacin
10.1.1. Pginas web
Libros web www.librosweb.es Accedido en junio 2010. Wikipedia www.wikipedia.org Accedido en julio 2010. Foros del web www.forosdelweb.com Accedido en junio 2010. Desarrollo web www.desarrolloweb.com Accedido en mayo 2010. PHP www.php.net Accedido en julio 2010. jQuery www.jquery.com Accedido en julio 2010.
10.1.2. Libros
[1] Beginning PHP5, Apache, and MySQL Web Development (Programmer to Programmer), Elizabeth Naramore, Jason Gerner, Yann Le Scouarnec , Jeremy Stolz , Michael K. Glass, Edit. Wrox, 2007. [2] Introduccion A Ajax Con Php, Lee Babin, Edit. ANAYA, 2007.
10.2. Confeccin de la memoria

Captulo 1. o Wikipedia www.wikipedia.org Accedido en mayo 2010. o Ingenieria del software, Roger S. Pressman, Edit. Mc Graw-Hill, 2002. o AZHosteleria - www.softpyme.net/software-bar-restaurante.php - Accedido en abril 2010. o RestaWeb - www.techni-web.es Accedido en abril 2010. o RestBar www.restbar.com Accedido en abril 2010. o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010. Captulo 2. o Wikipedia www.wikipedia.org Accedido en mayo 2010.
71
o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010. Captulo 3. o Wikipedia www.wikipedia.org Accedido en mayo 2010. o Ingenieria del software, Roger S. Pressman, Edit. Mc Graw-Hill, 2002. o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010. Captulo 4. o Wikipedia www.wikipedia.org Accedido en mayo 2010. o MySQL www.mysql.com Accecido en junio 2010. o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010. Captulo 5. o Wikipedia www.wikipedia.org Accedido en mayo 2010. o Libros web www.librosweb.es Accedido en junio 2010. o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010. Captulo 6. o Wikipedia www.wikipedia.org Accedido en mayo 2010. o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010. Capitulo 7. o Wikipedia www.wikipedia.org Accedido en mayo 2010. o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010. Capitulo 8 o Wikipedia www.wikipedia.org Accedido en mayo 2010. o Ingenieria del software, Roger S. Pressman, Edit. Mc Graw-Hill, 2002. o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010.
72
Captulo 9 o Wikipedia www.wikipedia.org Accedido en mayo 2010. o Ingenieria del software, Roger S. Pressman, Edit. Mc Graw-Hill, 2002. o Enginyeria del software I www.cvc.uab.es/shared/teach/a21290/c21290.htm - Accedido en marzo 2010.
73
Firma del autor:
Francisco Rodrguez Hernanz Sabadell, septiembre 2010.
74

RodriguezHernanzFranciscoR ETIGa2009 10

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

RodriguezHernanzFranciscoR ETIGa2009 10

Cargado por

Copyright:

Formatos disponibles

SGP: SISTEMA DE GESTIN DE PEDIDOS

SGP: Sistema de Gestin de Pedidos

La abajo firmante, Mnica Denham, profesora de l'Escola dEnginyeria de la UAB,

---------------------------------------------Firmado: Mnica Denham

SGP: Sistema de Gestin de Pedidos

SGP: Sistema de Gestin de Pedidos

SGP: Sistema de Gestin de Pedidos

SGP: Sistema de Gestin de Pedidos

SGP: Sistema de Gestin de Pedidos

1.2. Estado del arte

SGP: Sistema de Gestin de Pedidos

Figura 1.1 Pantalla principal AZHosteleria

SGP: Sistema de Gestin de Pedidos

Figura 1.2 Pantalla principal RestaWeb

Figura 1.3 TPV de RestaWeb

SGP: Sistema de Gestin de Pedidos

Figura 1.4 Pantalla principal de RestBar

Figura 1.5 Listado de mesas de RestaBar

SGP: Sistema de Gestin de Pedidos

1.3. Objetivo y alcance previstos

SGP: Sistema de Gestin de Pedidos

SGP: Sistema de Gestin de Pedidos

2.2.2. Perfil de los usuarios del proyecto

SGP: Sistema de Gestin de Pedidos

SGP: Sistema de Gestin de Pedidos

En el capitulo 4, se explicarn las tecnologas mencionadas en la lista previa.

2.3.2. Recursos de implementacin

2.4. Planificacin del proyecto

Tarea Inicio del proyecto: asignacin y matriculacin del proyecto Planificacin

SGP: Sistema de Gestin de Pedidos

Figura 2.1 Tareas del sistema, con duracin prevista.

SGP: Sistema de Gestin de Pedidos

Figura 2.2 Diagrama de Gantt de las tareas del proyecto.

2.4.2. Modelo de desarrollo

SGP: Sistema de Gestin de Pedidos

SGP: Sistema de Gestin de Pedidos

3. ANALISIS DEL PROYECTO

3.1.2. Requisitos funcionales de usuarios

SGP: Sistema de Gestin de Pedidos

SGP: Sistema de Gestin de Pedidos

Usuario administrador. Acciones que puede realizar el usuario administrador: 21

SGP: Sistema de Gestin de Pedidos

3.1.3. Vistas de casos de uso

Figura 3.1 Vista global de casos de uso.

SGP: Sistema de Gestin de Pedidos

A. Vista de casos de uso para usuario cliente

Figura 3.2 Vista de los casos de uso del usuario Cliente.

B. Vista de casos de uso para usuario personal

Figura 3.3 - Vista de los casos de uso del usuario Personal.

C. Vista de casos de uso para usuario cocina

Figura 3.4 - Vista de los casos de uso del usuario Cocina.

SGP: Sistema de Gestin de Pedidos

D. Vista de casos de uso para usuario administrador

Figura 3.5 - Vista de los casos de uso del usuario Administrador.

SGP: Sistema de Gestin de Pedidos

3.1.4. Diagramas de secuencia

SGP: Sistema de Gestin de Pedidos

Diagrama de secuencia (DS) Identificar mesa

Figura 3.5 Diagrama de secuencia de identificar mesa.

Diagrama de secuencia(DS) Cambiar estado al pedido

Figura 3.6 Diagrama de secuencia de cambiar estado al pedido.

3.2. Requerimientos no funcionales

SGP: Sistema de Gestin de Pedidos