Autorizada la entrega del proyecto del alumno: Gorka Díaz de Orbe EL DIRECTOR DEL PROYECTO. Carlos Labanda Maján. Fdo.: Fecha: 28/07/2010

Autorizada la entrega del proyecto del alumno: Gorka Díaz de Orbe EL DIRECTOR DEL PROYECTO Carlos Labanda Maján Fdo.: Fecha: 28/07/2010 Vº Bº del Coordinador de Proyectos Eduardo Alcalde Lancharro Fdo.: Fecha: 03/09/2010

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA SISTEMA INTEGRAL PARA LA GESTIÓN DE RESTAURANTES AUTOR: GORKA DÍAZ DE ORBE MADRID, SEPTIEMBRE DE 2010

Dedicatoria A mi madre, por los valores que me ha enseñado y que nunca olvidaré Página I

Agradecimientos A mi padre y hermano, por saber sostenerme durante todos estos años de mi vida, otorgándome la posibilidad, de sentirme privilegiado, y hacerme crecer. A mis amigos, por su apoyo incondicional, desde que somos pequeños en todas las facetas de la vida. A mis compañeros, por toda la ayuda recibida. A Pablo, por sus fantásticos dibujos. A todos aquellos que de alguna manera habéis participando en el proyecto, con vuestra inquietud y apoyo inestimable. Página II

RESUMEN DEL PROYECTO El objeto de este proyecto es el desarrollo e implantación de un Sistema Integral para la Gestión de Restaurantes. Este sistema ha sido desarrollado para cubrir las necesidades básicas de la gestión de un restaurante, ofreciendo la tecnología existente al desarrollo del negocio. El Sistema Integral para la Gestión de Restaurantes está especialmente diseñado para aquellos restaurantes en los que el tiempo es una variable importante para su economía y para aquellos que simplemente deseen ofrecer un mejor servicio a sus clientes, proporcionándoles una forma diferente de información y atención de sus necesidades. En la actualidad, la gestión de las comandas de los clientes, la transmisión de las órdenes a la cocina, la proposición de sugerencias, la inserción de publicidad y la gestión de los diversos módulos del negocio, se lleva realizando de la misma manera desde hace muchos años. El análisis de esta situación, ha permitido llegar a la conclusión de que existe un amplio margen de mejora en todos los procesos diarios que se realizan en la atención y servicio a los clientes de un restaurante. Este sistema propone una revolución en la gestión de los diferentes elementos principales del negocio, haciendo uso de la tecnología en servicio de sus usuarios. Se ha dividido el sistema en dos módulos fundamentales, uno es el módulo de mesa, que está disponible en cada una de las mesas del salón de un restaurante, y otro es el módulo de cocina, que se instala en la cocina para posibilitar la comunicación directa de los clientes con la cocina. Ambos módulos ofrecen una funcionalidad distinta, y juntos controlan de forma integral diversos factores sobre el desarrollo y gestión del negocio. El Sistema Integral para la Gestión de Restaurantes está desarrollado en una arquitectura cliente-servidor de cliente ligero, haciendo uso de un entorno gratuito Página III

(J2EE, MySQL y Apache) y permite controlar los siguientes aspectos de la gestión de un restaurante: Carta virtual: muestra a los clientes del restaurante, en sus mesas, a través del módulo existente, la variedad de platos, bebidas y ofertas que el restaurante dispone para sus clientes. Además, permitirá el acceso a información más detallada que sobre un menú en papel en caso en que el cliente esté interesando, proporcionando más información acerca de los ingredientes, su forma de elaboración, presentación de imágenes sobre el aspecto real del plato, y posibilidad de visualización de videos acerca de su preparación. A través de la carta virtual, el chef de cocina o el gerente del restaurante, tendrá la posibilidad de ofrecer sugerencias o mostrar publicidad, como se especificará más adelante. Comandas: controla el transporte y trato de la información sobre las órdenes de los clientes, directamente desde sus mesas, hasta la cocina, donde en su respectivo módulo, se podrán visualizar todas las comandas que realicen los clientes, las comandas ya atendidas, y aquellas que aún están pendientes. Este innovador proceso, permite una comunicación directa de los clientes con la cocina, evitando tiempo de espera en la atención del camarero o en el transporte de la información del camarero, a la cocina. Publicidad y sugerencias: el gerente del restaurante, o el chef de cocina, podrán ofrecer a sus clientes sugerencias desde el módulo de cocina, al módulo de mesa, estimulando la demanda de sus consumidores. Además, también existe la posibilidad de reservar un espacio en la carta para la inserción de publicidad, creando de esta manera, un importante espacio para vender a terceros, o promocionar otros restaurantes asociados a los clientes. Economía: todos los movimientos relativos a la atención de comandas del restaurante, quedarán registrados con detalle en bases de datos, donde más tarde, a través de procesos que traten esta información, se obtendrán informes de especial importancia para el desarrollo del negocio, como es un resumen de la facturación, y un control de la demanda de platos ordenados de forma ascendente. Página IV

Para el desarrollo del proyecto se siguió el ciclo de vida lineal o en cascada, con sus respectivas fases: Identificación de necesidades, Análisis de Requisitos, Estudio de la arquitectura, Diseño externo, Diseño interno, Programación, Pruebas e Implantación. La última parte del proyecto incluye una valoración económica del mismo y la planificación llevada a cabo para su desarrollo. Como conclusión, este proyecto supone una importante modernización del sector más importante en España, como es la hostelería y la restauración, que son las bases de acogida del turismo, motor de la economía nacional, aportando una mayor funcionalidad a los restaurantes, perfeccionando su gestión, reduciendo tiempos innecesarios y mejorando por lo tanto, el servicio ofrecido a sus clientes. Página V

ABSTRACT The object of this project is the development and implementation of an Integral System for Restaurant Management. This system has been developed to meet the basic needs of managing a restaurant, offering the needed technology for business development. The Integral System for Restaurant Management is specially designed for those restaurants where time is an important variable for their business model and for those who simply want to offer their best service to their customers by providing increased attention to their needs. Currently, the management of client orders, the transmission of the orders to the kitchen, the proposal of suggestions, and advertising and management of various business modules has been carried out the same way for many years. Analysis of this situation has concluded that there is ample room for improvement in all the processes that take place daily in a restaurant. This system proposes a revolution in the management of the various major business elements, including making use of new technology in the service of their customers. The system has been divided into two basic modules: a module that is available on each of the tables in the dining section of the restaurant, and another in the kitchen that allows customers to communicate directly to the kitchen. Each module provides different functionality, but by working together, the modules seamlessly control the various factors in the development and management of the business. This integral system for restaurant management is developed in a thin client clientserver architecture using free environments (J2EE, MySQL and Apache) and can control the following aspects of managing a restaurant: Virtual menu: shows restaurant customers through the existing table module a variety of information. For example, it can show the variety of dishes, and Página VI

drinks that the restaurant offers. It allows access to more information than a paper menu could if the customer wishes to view it. For example, this digital menu system could provide more information to customers about ingredients, food preparation, and food origins. The possibility of displaying pictures and videos also exists. Orders: controls the transmission of customer orders directly from their tables to the kitchen, where all the customer orders and communications can be seen and accessed, including outstanding orders. This innovative process allows direct customer communication with the kitchen, avoiding the lag time of calling a waiter and waiting until he or she delivers one s message to the kitchen. Specials and Suggestions: restaurant managers or chefs would offer their customers suggestions from the kitchen module directly to the table module, appealing to the customers tastes. Moreover there is the possibility of other advertisements in the digital menu, thus promoting and encouraging business with other companies or restaurants. Business: all transactions and orders valuable to a restaurant would be recorded in detail in databases, where, through specific information processes, one would get valuable reports that are critical for business development. An example would be a summary list of dishes of the highest demand in descending order. The development of this project life follows the waterfall model, with these respective phases: identification of needs, analysis of requirements, study of architecture, external design, internal design, programming, testing, and implementation. The last part of the project includes an economic assessment of the planning and carried out for development. In conclusion, this project represents a significant modernization of the most important sector in Spain, such as hotels and restaurants, which are the basis of tourism, the national economic engine. The system provides enhanced functionality to restaurants, improving their management by reducing unnecessary time and resources and thus improving the services offered to its customers. Página VII

Índice 1. INTRODUCCIÓN 2 1.1 Sector de la hostelería. 2 1.1.1 Empleo en hostelería 10 1.2 Las empresas cliente 12 2. IDENTIFICACIÓN DE NECESIDADES 17 2.1 Organización empresarial 17 2.2 Tipología de los usuarios finales 25 2.3 Antecedentes del sistema 27 2.4 Objetivos del sistema 32 2.5 Alcance de la aplicación 35 2.6 Restricciones 36 3. ANÁLISIS DE REQUISITOS 38 3.1 Ámbito del proyecto 38 3.2 Contexto general del sistema 40 3.3 Funciones primarias afectadas 43 3.3.1 Órdenes de pago en un restaurante 49 3.3.2 Modificaciones sobre el funcionamiento 52 3.4 Unidades de la organización afectadas por la mecanización 57 3.5 Lista de requisitos 60 3.6 Modelo lógico de datos 82 3.6.1 DFD contextual 82 3.6.2 DFD conceptual 83 3.6.3 Modelo conceptual de datos. 105 Página VIII

4. ESTUDIO DE LA ARQUITECTURA 110 4.1 Especificación de las alternativas 110 4.1.1 Arquitecturas 110 4.1.2 Lenguajes de programación para los clientes 123 4.1.3 Lenguajes de programación para el servidor 135 4.1.4 Sistemas Gestor de Bases de Datos 143 4.1.5 Sistemas operativos 147 4.2 Evaluación de las alternativas 151 4.2.1 Evaluación de la arquitectura 151 4.2.2 Evaluación del sistema operativo 154 4.2.3 Evaluación del lenguaje de programación en el cliente 155 4.2.4 Evaluación del lenguaje de programación en el servidor 157 4.2.5 Evaluación del sistema gestor de bases de datos 158 4.3 Selección de la alternativa 159 5. DISEÑO EXTERNO 162 5.1 Entorno operativo 162 5.2 Fronteras de mecanización 163 5.3 Especificación de procesos 163 5.4 Diseño de interfaces 166 5.4.1 Interfaz login 166 5.4.2 Menú privado 167 5.4.3 Menú público 173 5.5 Procesos de seguridad 176 6. DISEÑO INTERNO 178 6.1 Diseño interno de programas 178 6.1.1 Diagrama HIPO Administración de empleados 179 6.1.2 Diagrama HIPO Alta comanda 180 6.1.3 Diagrama STC Administración de empleados 181 Página IX

6.2 Modelo físico de la base de datos 182 7. PRUEBAS 187 7.1 Pruebas unitarias 187 7.2 Pruebas de integración 189 8. IMPLANTACIÓN 191 8.1 Implantación física 191 9. CONCLUSIONES 193 10. FUTURAS MEJORAS 196 11. BIBLIOGRAFÍA 198 11.1 Libros 198 11.2 Páginas web 200 12. ANEXOS 202 12.1 Manuales 202 12.1.1 Manual de explotación 202 12.1.2 Manual de usuario 211 12.2 Valoración económica 218 12.2.1 Presupuesto en horas hombre 218 12.2.2 Presupuesto de hardware y software 220 12.2.3 Presupuesto total del proyecto 221 12.3 Planificación 222 Página X

1) Introducción

1. INTRODUCCIÓN El presente proyecto plantea el desarrollo de un sistema integral para la gestión de restaurantes, con el objeto de mejorar sustancialmente, gracias a la tecnología ofrecida, los restaurantes y otros negocios del sector hostelero relacionados con la alimentación, como bares, cafeterías y casas de comida. Para una mejor comprensión, se realiza en este capítulo una presentación del sector hostelero, dentro del cual se engloban todos los restaurantes, bares y cafeterías y un breve análisis del mercado en el cual, dicho proyecto, tiene su impacto. Para la realización de este proyecto se han seguido las referencias bibliográficas [WWW001], [WWW002], [WWW003], [WWW004], [WWW005] 1.1 Sector de la hostelería. Todas aquellas actividades económicas consistentes en la prestación de servicios ligados al alojamiento y la alimentación esporádica, pertenecen al sector de hostelería. Muy usualmente están ligados al turismo, tales como hoteles, hostales, paradores, bares, cafeterías y restaurantes. No se considera hostelería al servicio de comida a domicilio y todos aquellos combinados con otro tipo actividades de ocio como discotecas, etc. Página 2

El sector español de la hostelería tiene una elevada repercusión en la formación del PIB, algo superior al 7 %, lo que pone de manifiesto su influencia, y su repercusión, en la creación de riqueza y en la generación y mantenimiento del empleo. La modernización que la hostelería ha impulsado en las últimas décadas ha permitido que el sector se consolide con un rol destacado dentro de la economía y la sociedad española. El incremento en los parámetros de competitividad y eficiencia, es el principal indicador que refleja un desempeño sobresaliente, confirmando el alto grado de importancia relativa y absoluta alcanzado por el sector turístico español. Con una producción anual de casi 12 billones de euros y un volumen de empleo que se acerca al millón de personas, es evidente la importancia de la Hostelería en la economía nacional. Un sector que, tal y como recoge el informe presentado por la Federación Española de Hostelería (FEHR) en relación al año 1999, cuenta con más de 333.000 establecimientos repartidos entre las actividades de hoteles, restaurantes, colectividades, cafés-bares y cafeterías. De entre ellos, es el subsector de la restauración el que posee un mayor número de plazas con una cifra superior a los 3,3 millones. A continuación, para poder apreciar la progresión del sector, se representa en la siguiente tabla, el crecimiento del número de restaurantes en España, desde 1975 hasta el 2008: Página 3

Índice de crecimiento del sector de restaurantes Años Número Índice Variación interanual 1975 21.536 100 --- 1980 27.381 127 4,9 1985 37.227 173 5,6 1990 50.055 232 5,8 1998 53.591 249 4,0 2000 55.238 256 1,3 2002 60.436 281 4,2 2006 67.457 313 1,8 2007 69.298 322 2,7 2008 70.641 328 1,9 Fuente: Secretaría General de Turismo y DIRCE. Según la Secretaría General de Turismo y DIRCE (Directorio Central de Empresas), durante el año 2007, 69.298 establecimientos, con 4,29 millones de plazas, se integraron bajo la tipología de restaurantes, un 2,68 más que en 2005, y su producción se ha situado en 23.100 millones de euros. Como se recoge en la tabla anterior, la expansión del número de restaurantes casi se ha cuadriplicado desde 1975. Página 4

El cada vez más frecuente hábito de comer fuera del hogar se esconde detrás de este crecimiento, y además se debe al importante desarrollo que ha tenido el turismo en España y a los mejores niveles de vida que tiene la población. A continuación, se representa, la distribución del censo por comunidades autónomas de restaurantes en los años 2007 y 2008. Cabe señalar, que se han agregado también las cafeterías, en la siguiente tabla: Página 5

Comunidades Autónomas Año 2007 Año 2008 Andalucía 8.351 8.615 Aragón 1.772 1.823 Asturias (Principado) 2.495 2.548 Baleares (Islas) 4.269 5.104* Canarias (Islas) 6.816 7.219* Cantabria 1.141 1.174 Castilla León 2.781 4.552 Castilla La Mancha 4.419 2.987 *Cataluña 17.301 17.301** Extremadura 1.455 1.530 Galicia 5.225 5.145 Madrid (Comunidad) 8.051 8.363 Murcia (Región) 1.995 2.094 Navarra (Comunidad 632 651 Foral) País Vasco 3.135 3.623 La Rioja 469 469** C. Valenciana 11.682 12.113 TOTAL 81.989 84.879 (*) DIRCE 2008 (**) Se agrega el grupo de los restaurantes cafeterías El reparto por comunidades autónomas estaría encabezado por Cataluña, seguido de la Comunidad Valenciana, Andalucía, Madrid y Página 6

Canarias. En el extremo opuesto, se encuentra Extremadura, Cantabria, Navarra, y La Rioja con el menor número de establecimientos. Se representa a continuación, de forma gráfica, los datos representados en la tabla anterior, sobre la distribución de restaurantes por Comunidades Autónomas en el 2008, donde se puede apreciar, de una forma más intuitiva que la mayor concentración de restaurantes y cafeterías, se encuentra en Cataluña, Comunidad Valenciana, Andalucía y Madrid. Distribución de restaurantes por Comunidades Autónomas Año 2008 Andalucía Aragón Asturias (Principado) Baleares (Islas) Canarias (Islas) Cantabria Castilla León Castilla La Mancha Cataluña Extremadura Galicia Madrid (Comunidad) Murcia (Región) Navarra (Comunidad Foral) País Vasco Página 7

El subsector restauración, hacia el cual el presente proyecto está dirigido, supuso una participación del 32,91 % dentro del sector hostelería, aportando 42.233 millones de euros, como se puede observar en la tabla a continuación, además, para una mejor visualización de la importancia del subsector restauración, dentro de la hostelería, se representa la misma tabla de forma gráfica más abajo: Distribución de la producción nacional del sector de la hostelería, en 2008 Millones euros % Participación Sector Alojamiento 17.102 13,33 Sector de comidas 42.233 32,91 Sector de bebidas 59.505 46,37 Sec. Colectivid. y 9.477 7,39 Caterings Total 128.317 100,00 Página 8

Producción nacional de hostelería 2008 Sector Alojamiento Sector de comidas Sector de bebidas Sec. Colectivid. y Caterings El incremento medio de la producción sobre el año 2007 fue del 3,58 % siendo el sector de la hostelería, uno de los más importantes para la economía nacional, y más concretamente, el subsector restauración. Página 9

1.1.1 Empleo en hostelería Respecto a la situación de crisis económica actual, se presenta a continuación, un breve estudio de los últimos datos de empleo en hostelería y restauración. En el mes de abril el número de trabajadores con alta en empresas de hostelería era de 1.278.793, lo que supone un 1,2 % más que en el mismo mes de 2009, según los datos del Ministerio de Trabajo y Asuntos Sociales. Esta evolución positiva se debe a los servicios de restauración que representan la mayor parte de la hostelería, que llegaron a 1.023.286 trabajadores, repitiendo al igual que el mes anterior un 1,8 % de subida interanual. El empleo en el subsector del alojamiento, con 255.507 trabajadores, cayó un 1 %, después del aumento que se produjo en el mes de marzo (2,3 %). La media en los cuatro primeros meses del año supone en restauración un incremento del 1,1 %, con relación al mismo período de 2009. En hoteles y otros alojamientos cae el empleo un 1,4 % interanual. Concretamente, en el sector restauración, en el cual el presente proyecto tiene su impacto, en marzo de 2010 se registraron 1.001.441 de trabajadores afiliados a la Seguridad Social con alta en restauración, lo que supone un 1,8 % más que en el mismo mes del año anterior. Página 10

Esta tasa interanual es 1,2 puntos superior a la de enero y significa una ligera recuperación ya que en marzo de 2008 el número de trabajadores era un 3,9 % menos respecto al año anterior. En lo que va de año 1.213.035 trabajadores estuvieron empleados de media en el conjunto de la hostelería, aumentando un 0,4 % respecto al mismo período de 2009. A continuación se representa una gráfica comparativa de las tasas de empleo en alojamiento y restauración, comentadas anteriormente, de abril de 2009 a abril de 2010: Página 11

1.2 Las empresas cliente En este capítulo se presentan las empresas de restauración, a las que va especialmente dirigido el presente proyecto. Algunos de los objetivos principales que se buscan con el Sistema Integral para la Gestión de Restaurantes, son: la posibilidad de acceder al menú de forma virtual con información más detallada incluyendo fotos o videos, ahorro de tiempo en la gestión de comandas evitando el tiempo de espera hasta que atienda el camarero y el tiempo de transmisión de la comanda desde el camarero a la cocina, posibilidad para los restaurantes de la introducción de publicidad y sugerencias en sus cartas virtuales, y una mejor gestión de todos los pedidos, evitando errores de anotación de las comandas por parte de los camareros y liberando carga de trabajo a los camareros. Por todos estos objetivos, el perfil de la empresa cliente son restaurantes de comida rápida, y todas aquellas cadenas de restaurantes donde el tiempo para atender, y servir a los clientes, es una variable especialmente importante. A continuación, para un mejor conocimiento del perfil de posibles empresas cliente, se presentan algunos ejemplos, hacia las cuales, el Sistema Integral de Gestión de Restaurantes, está especialmente dirigido: Página 12

Mc Donald s: es una cadena de restaurantes de comida rápida fundada en 1940, por los hermanos Dick y Mac McDonald. Es la cadena más grande en el mundo y provee una gran variedad de emparedados, bocadillos y otros productos de comida rápida. En España, McDonald s factura 755 millones de euros, y tiene más de 311 restaurantes franquiciados. Burger King Corporation: es la segunda cadena más grande de restaurantes de comida rápida, fundada en Miami en 1954. Cuenta con más de 12.100 restaurantes en todo el mundo. Telepizza: es una cadena española de pizzerías con presencia en varios países fundada por Leopoldo Fernández Pujals en 1986. La cadena se extendió por Madrid primero y creció en pocos años hasta convertirse en líder del Página 13

mercado español de pizzas y en el segundo grupo de comida rápida por detrás de McDonald's. Telepizza cuenta con la siguientes presencia: 559 establecimientos en España 81 establecimientos en Portugal 61 establecimientos en Chile 92 establecimientos en Polonia 51 establecimientos en Guatemala 28 establecimientos en El Salvador Grupo vips: es la empresa líder en el sector de la hostelería en España. Cuenta con 6 cadenas (Vips, Ginos, Tio Pepe, The Wok, TGI Friday s, BSF) y 11 restaurantes (El bodegón, Iroco, Bice, Teatriz, Lucca, Tattaglia, Rugantino, Paparazzi, Mood, Root y Starbuck s) repartidos en 400 establecimientos, presente en 16 provincias españolas y en Portugal. Página 14

Grupo Zena (Foster s Hollywood): es la primera compañía de restauración multimarca en España gracias al éxito obtenido en su triple vertiente de franquiciado (Pizza Hut, Burger King, KFC), franquiciador (Foster's Hollywood, Cañas y Tapas e Il Tempietto) y restaurantes propios (La Vaca Argentina y Nostrus). Grupo Zena es un referente en el sector debido a la estrategia de negocio, a su gran capacidad de crecimiento y al modelo de gestión que desarrolla. Foster s Hollywood se fundó en 1971 como la primera cadena de restaurantes de comida americana en instalarse en España y dispone de más de 480 restaurantes. Página 15

2) Identificación de necesidades

2. IDENTIFICACIÓN DE NECESIDADES Esta etapa sirve como soporte a la petición que el cliente realiza para determinar las pautas generales de sus necesidades y contexto del sistema. El cliente debe establecer los objetivos y necesidades generales que el sistema debe cumplir. Se especifica el alcance del proyecto, las restricciones, los antecedentes, así como la tipología de los usuarios finales. Por lo tanto, en esta etapa se define el problema a resolver y se fijan las normas a seguir para la dirección del proyecto. 2.1 Organización empresarial El sistema integral de gestión de restaurantes está compuesto por un módulo de mesa, y otro módulo de cocina. Actualmente, los métodos para gestionar toda la información referente a los restaurantes, como pueden ser, la carta, los pedidos de los clientes...etc. se siguen realizando de una forma manual y con la necesidad de la espera para la disponibilidad de los camareros a sus clientes. Página 17

Con la implantación del sistema que propone este proyecto, se modificará sensiblemente la gestión de las comandas y el funcionamiento general de la gestión de un restaurante, por lo que es de suma importancia, un análisis detallado de los perfiles que se verán afectados, y cómo se llevará a cabo la nueva gestión. En el siguiente organigrama, se analizan los perfiles que se verán afectados por el sistema, diferenciando aquellos que se verán especialmente afectados por la implantación del módulo de cocina resaltados en un cuadro rojo, como aquellos que se verán afectados por la implantación del módulo de mesa, resaltados por el recuadro azul. Gerente Contable Jefe departamento Ventas Jefe departamento administración Chef Mesero encargado del salón Proveedores Sueldos Ayudantes de cocina Meseros Seguridad Limpieza Página 18

El organigrama anterior representa los diferentes perfiles que componen la estructura organizativa de un restaurante. Es importante estudiar los perfiles generales que componen un restaurante ya que la implantación del sistema integral de gestión de restaurantes, tendrá un impacto positivo en el funcionamiento general de muchos de ellos. A continuación se describen los participantes de dicha estructura: Gerente: es la persona encargada de la supervisión directa de los subordinados más próximos y de la organización en su globalidad. Asignando recursos como pueden ser capitales, materias primas, etc. o incluso delegando poder en las unidades para su adecuado funcionamiento pero siempre bajo su supervisión. A la vez gracias a esta supervisión puede detectar anomalías y resolverlas. Dentro de este conjunto de obligaciones también se encuentra el de difusor de conocimientos o información que deben conocer el resto de personal. Con todas estas obligaciones o funciones logra que la organización funcione debidamente como una unidad integrada. Contable: es el encargado de obtener y registrar datos contables, estadísticos y financieros, así como efectuar pagos y cobros. Realiza asientos en los registros o libros de contabilidad, efectúa cálculos, realiza costos de producción, hace transacciones bancarias, calcula los salarios a pagar partiendo de los registros de horas trabajadas por cada trabajador, y es el encargado de la Tesorería. Página 19

Jefe departamento de ventas: es el responsable de la apertura y cierre del local, asigna y supervisa tareas, es el encargado de la caja, de las compras, relaciones públicas y marketing. Jefe departamento de administración: realiza el pago a los proveedores, acreedores, administra las operaciones bancarias, legales, y los sueldos de los empleados. Proveedores: es el agente económico que entrega o provee materias primas, materiales o servicios, tiene la responsabilidad de cumplir con los compromisos de entrega pactados, según el lugar y el tiempo acordados. Su misión es fundamental para la prestación del servicio en un restaurante, suelen ser empresas externas y están especialmente supervisadas por el jefe del departamento de administración. Sueldos: encargados de la administración y supervisión de los salarios a los empleados. Chef: es el responsable del control de mercaderías y faltantes, la realización y elaboración de los distintos menús, control de higiene de la cocina y empleados, cuidado de los bienes de uso para realizar los menús, y todas las tareas desempeñadas en la cocina. Ayudantes de cocina: son colaboradores en la realización de los menús, mantienen la higiene de la cocina y cuidan de los bienes de uso de la cocina. Además realizan tareas Página 20

de agilidad para el trabajo del chef, ayudando en la elaboración de platos. Mesero encargado del salón: es el responsable de la organización del salón, del control de bienes y mercadería de salón, se encarga de seleccionar sectores para cada mesero, y supervisa sus tareas. También realiza la recepción y acomodamiento de clientes en el restaurante. Meseros: son los encargados del orden y limpieza del salón, del cuidado de su sector de trabajo, atienden las comandas de los clientes de una forma cordial y eficaz y reordenan el sector de trabajo después del servicio. Seguridad: es el responsable del mantenimiento de la seguridad dentro y fuera del local, y vela por el orden en el restaurante. Limpieza: son los encargados de la higiene y limpieza de todo el local, de los elementos de cocina y del salón. Con la implantación del sistema integral de gestión de restaurantes, algunas de las funciones principales de los miembros de esta estructura detalladas anteriormente, se verán modificadas sensiblemente, proporcionando una mejora en la gestión y en el tiempo de la atención a los clientes. Concretamente, modificarán su funcionamiento aquellos afectados por el módulo de mesa, remarcados en azul en el organigrama: Página 21

Mesero encargado del salón: seguirá siendo el responsable de la organización del salón, control de la mercadería de salón, supervisor de las tareas desempeñadas por los meseros y recepción y acomodación de los clientes. Además, presentará y explicará brevemente a los clientes el novedoso sistema de módulo de mesa para la visualización del menú virtualmente, con imágenes y videos correspondientes, la posibilidad de realizar los pedidos directamente desde sus mesas a la cocina y todas las funcionalidades que ofrece el sistema. Meseros: seguirán siendo los encargados del orden y limpieza del salón, del cuidado de su sector de trabajo, y reordenación del sector de trabajo después del servicio. Pero como gran novedad en sus funciones, no tendrán la necesidad de atender las comandas de los clientes, sin embargo podrán ayudarles en la utilización del sistema y en aquellos problemas y dudas que surjan, y seguirán llevando Página 22

y recogiendo las comandas que realicen sus clientes a sus respectivas mesas. Aquellos miembros, cuyo funcionamiento habitual, se verá modificado gracias al módulo de cocina del sistema integral de gestión de restaurantes, son los siguientes, según el marco rojo que se puede apreciar en el organigrama anterior: Chef: seguirá siendo el responsable del control de mercaderías y faltantes, la realización y elaboración de los distintos menús, control de higiene de la cocina y empleados, cuidado de los bienes de uso para realizar los menús, y todas las tareas desempeñadas en la cocina. Además, será el encargado de controlar, realizar y repartir las comandas entre los ayudantes de cocina según se visualizan directamente en el módulo de cocina. Página 23

Ayudantes de cocina: seguirán siendo los colaboradores en la realización de los menús, mantendrán la higiene de la cocina y cuidarán de los bienes de uso de la cocina, realización de tareas de agilidad para el trabajo del chef, y elaboración de platos. Además, controlarán la recepción de las comandas en el módulo de cocina, y marcarán aquellas comandas que ya hayan sido atendidas. Página 24

2.2 Tipología de los usuarios finales Este proyecto tendrá los siguientes usuarios: - Administrador: será el responsable de la implantación, diseño, actualización, inserción de publicidad y mantenimiento del sistema completo. - Usuarios finales Chef: realizará el control y repartirá la elaboración de las comandas que se reciben en el módulo de cocina entre los ayudantes de cocina. Ayudantes de cocina: controlarán la recepción de comandas según vayan visualizándose en el módulo de cocina, editarán aquellas comandas satisfechas y revisarán las comandas pendientes. Mesero encargado del salón: guiará a aquellos clientes que encuentren dificultades en el manejo del sistema y supervisará el correcto funcionamiento del módulo de mesa. Clientes: serán todas aquellas personas que realizarán las comandas desde sus mesas, navegarán a través del menú virtual, y podrán informarse de todas las ofertas, promociones y publicidad ofrecidas por el restaurante. Página 25

Dado que la aplicación va dirigida a un público general, se realizará un interfaz táctil hombre máquina agradable, intuitivo y vistoso a la vez que funcional, que facilite la adaptación de una forma sencilla y rápida a la nueva aplicación. Página 26

2.3 Antecedentes del sistema Desde hace años, se realiza la gestión de los restaurantes de una manera obsoleta, apoyándose únicamente en la tecnología en el uso de un software que permite registrar las comandas y emitir las facturas, pero aún se sigue anotando en papel, en muchos casos, las comandas, aun se siguen visualizando los menús que ofrece cada restaurante en papel, muchas veces con anotaciones escritas a mano y con descripciones muy poco claras sobre la composición de los platos, y aun se siguen transmitiendo oralmente o por escrito, las peticiones que realizan los clientes con las consecuentes equivocaciones humanas por falta de entendimiento. Todos estos posibles inconvenientes, y posibilidades de mejora, se solventarán gracias a la implantación del sistema integral de gestión de restaurantes, pero para ello se estudia la tecnología existente en la actualidad: RestBar Software: es un programa ampliamente utilizado en bares y restaurantes que incluye la facturación de mesas, ventas rápidas y servicio exprés (delivery), recetas y costos, la caja (ingresos y salidas de dinero), los inventarios de bebidas, bienes y otros, control de entradas y salidas de empleados. Página 27

Actualmente se usa en más de 16 países entre ellos España y es el software habitual usado por los meseros para anotar las comandas realizadas por cada cliente. Este es el aspecto general del software utilizado: Página 28

Además, en algunos restaurantes, en lugar de anotar las comandas posteriormente sobre el ordenador general que recoge las comandas, se ha implementado el software también para Pocket PC y así poder registrar la comanda más rápidamente. La versión para Pocket PC contiene básicamente la misma funcionalidad que la otra versión, pero implemente algunas novedades que se describen a continuación: - Ingreso de comandas en la mesa del cliente. Página 29

- Ingreso del número de Comensales en la mesa. - Impresión del estado de la cuenta o cuenta parcial. Este es el aspecto del software utilizado en Pockets PC: DataHouse Company: es otra de las principales soluciones software de gestión de restaurantes que se utiliza actualmente y que incluye las siguientes funcionalidades principales: - Mapa gráfico de mesas y cubiertos asignados. - Gestión de entregas a domicilio. - Panel de facturación rápida. - Gestión de reserva de mesas. Página 30

- Emisión de facturas en distintos idiomas. - Gestión administrativa y contable. En resumen, los restaurantes usan hoy en día dos tipos de soluciones software para la gestión de sus restaurantes: software de gestión corriente de comandas, y software para Pocket PC. Existen múltiples soluciones para la gestión corriente de un restaurante, sin embargo, todas estas soluciones no permiten que los usuarios visualicen virtualmente el menú, accedan a información más detallada como vídeos o imágenes y no ahorran el tiempo empleado a que el camarero atienda las comandas y las transmita a la cocina. El sistema que propone este proyecto propone unas funcionalidades diferentes que optimizan la gestión general de las comandas y el tiempo de atención a los clientes, y además de aprovechar el uso de la tecnología de forma más eficiente y eficaz para el negocio, da un toque de distinción y originalidad a los restaurantes que lo implementen. Página 31

2.4 Objetivos del sistema En este apartado se detallan los objetivos que el sistema persigue para ofrecer una mayor eficacia y eficiencia en la gestión de restaurantes. Los objetivos serán de tipo funcionales y estratégico-económicos. Como objetivos funcionales, se busca: Aportar una mayor utilidad y conocimiento a los clientes acerca del menú y los servicios que ofrece el restaurante, desplegando de forma virtual el menú, con acceso a ingredientes, fotografías o vídeos. Ofrecer una mayor precisión en la información transmitida hasta la cocina, evitando posibles errores humanos en la compresión de las comandas por parte de los camareros. Mejorar de manera sensible la transmisión y gestión general de las comandas evitando tiempos de atención del camarero a los clientes, y transmitiendo una información correcta, instantánea y segura desde la mesa hasta la cocina. Mejorar la gestión del reparto de trabajo en la cocina gracias a la visualización de las comandas en tiempo real en el módulo de cocina. Página 32

Dotar a los restaurantes de información exacta y detallada, para el estudio sobre los pedidos realizados por los clientes, los platos más demandados, y los platos menos demandados, que permitirá la importante toma de decisiones sobre actualizaciones en el menú y otras decisiones que los gerentes crean oportunas. Los objetivos estratégico-económicos que se persiguen son los siguientes: Motivar la demanda gracias a la inserción de publicidad, promociones y sugerencias que lleguen directamente a los clientes. Actualmente las posibilidades de incluir publicidad en un restaurante son muy limitadas debido a motivos estéticos principalmente, pero gracias a este sistema, se abre una nueva puerta muy importante a la publicidad, que puede proporcionar una mayor demanda, ya que los clientes que visitan un restaurante, son clientes con una necesidad primaria de consumir y por lo tanto, son clientes altamente potenciales. Reducir la carga de trabajo para los meseros y por lo tanto, posibilitar la reducción del número de ellos. Es posible que al introducir el sistema de gestión, el número de meseros que se necesiten sea inferior, ya que la carga de trabajo se reducirá considerablemente, al no tener que atender a los clientes, tan sólo transportando las comandas desde la cocina a las mesas, y viceversa. Los meseros seguirán siendo necesarios para poder atender correctamente a los clientes pero sin embargo, tendrán menos trabajo que desempeñar. Página 33

Optimización del tiempo, que implica posibilidad de acoger a un mayor número de clientes. Al eliminar los tiempos necesarios en atender a los clientes por parte de los meseros, y eliminar el tiempo de transmisión de la comanda desde el mesero hasta la cocina, la comanda se puede atender más rápidamente, los clientes pueden terminar de comer antes, y por lo tanto, se pueden atender un mayor número de clientes en el mismo día. Actualmente una de las limitaciones principales en los ingresos de los restaurantes, es el número de mesas disponibles para poder atender a los clientes, por lo tanto, los restaurantes están interesados en que sus clientes terminen de comer rápidamente, pudiendo ofrecer el sitio libre a otros nuevos clientes. Con este sistema, se facilitará esta situación. Lograr una ventaja competitiva frente a otros restaurantes marcando una estrategia de diferenciación, al implementar un sistema, en el sector de la restauración, que se percibirá como único, importante y exclusivo, y que aportará el placer de usarlo a sus clientes. Página 34

2.5 Alcance de la aplicación El proyecto abarcará los objetivos detallados anteriormente, para poder llevarlos a cabo se implementarán las siguientes funcionalidades en el sistema: Gestión del menú virtual: se mostrará información detallada sobre la composición y elaboración de los platos. Gestión de las comandas: se transmitirá directamente, desde la mesa de los clientes, a través de una pantalla, las peticiones que se realicen hasta un módulo en la cocina, donde se podrá visualizar quién ha realizado la comanda, y en qué consiste. Gestión de la economía: se podrá mostrar, en el módulo de cocina, toda la información referente a la cantidad de comandas realizadas y atendidas, el plato más pedido y el de menor demanda, así como un resumen de la facturación realizada hasta el momento que será de gran utilidad para el seguimiento y control del negocio. Gestión de la instalación: a través del módulo de cocina, se gestionará toda la actividad que se realice en el salón, así como la disposición de las mesas en el restaurante, y los clientes. Gestión de las sugerencias, promociones y publicidad: el gerente del restaurante, podrá introducir todas sus ofertas a través del menú virtual directamente a sus clientes. Página 35

2.6 Restricciones En este apartado se hace referencia a las principales restricciones que afectan al proyecto. Para el desarrollo de la aplicación, concretamente para el desarrollo del menú virtual se usarán bases de datos compuestas por información no específica de un solo restaurante, sino que se mezclarán datos que ofrecen distintos restaurante, a modo de prueba. Además existen otro tipo de restricciones: - Temporales: el proyecto se deberá entregar dentro de la fecha límite establecida, que es en Septiembre de 2010. - Económicas: no se dispone del dinero necesario para la implantación real del sistema en un restaurante, así como de las pantallas táctiles que se implantarían en las mesas de los clientes, por lo que se desarrollará únicamente toda la lógica y el software que lo compone. - Organizativas: el proyecto debe ser desarrollado por una sola persona, Gorka Díaz de Orbe. Página 36

3) Análisis de requisitos

3. ANÁLISIS DE REQUISITOS En esta etapa se busca tener un concepto claro de las necesidades, problemas y requisitos del usuario. Es necesario tener un conocimiento claro acerca del sistema para poder profundizar y proponer una solución de la mejor forma posible. A continuación se realiza un primer y básico análisis de la aplicación. Para ello, se comienza con una introducción, una descripción del sistema actual, una lista de requisitos que permite introducir el modelo lógico del nuevo sistema, el diccionario de datos y el modelo conceptual de datos. 3.1 Ámbito del proyecto En este apartado se especifican las funciones a desarrollar identificadas como necesidades, se muestra cómo el usuario se relacionará con el sistema y éste a su vez con la base de datos que servirá para visualizar el menú virtual, registrar las comandas y mostrarlas al módulo de mesa. A continuación se muestra un diagrama del funcionamiento general del sistema: Página 38

Cliente 1 Pantalla táctil Cliente 2 Pantalla táctil Servidor Módulo de cocina Cliente n Pantalla táctil Base de datos Como se puede apreciar en el diagrama, los clientes recibirán del servidor, que obtiene la información de la base de datos, las posibilidades que ofrece el restaurante en su menú, y estos una vez que hayan elegido, enviarán sus comandas sobre el servidor, que mostrará al módulo de cocina las peticiones de los clientes actualizándose la base de datos. Página 39

3.2 Contexto general del sistema A continuación se muestra un diseño del sistema, en el cual se puede apreciar una vista desde los clientes, que seleccionan sus comandas desde las mesas. La comunicación se establecería en dos sentidos, desde los módulos de mesa al servidor, y desde el módulo de cocina al servidor. La comunicación con el servidor que contiene la base de datos, en ambos sentidos, se realizaría a través de una conexión local inalámbrica como se puede ver reflejado en el diseño. Página 40

Además, para una mejor comprensión del módulo de mesa, se procede a incluir un diseño a continuación en el que se refleja la conexión inalámbrica que se realiza desde el módulo hasta el servidor, y algunos detalles de diseño físicos, para que las pantallas no molesten a los usuarios a la hora de consumir en el restaurante. Página 41

Página 42

3.3 Funciones primarias afectadas En este apartado, se analizan las funciones actuales que se verán afectadas por la implantación de la aplicación. A continuación se muestra el procedimiento habitual del funcionamiento de un restaurante, y posteriormente, las modificaciones pertinentes debido a la instalación del nuevo sistema de gestión. Página 43

Bienvenida no Mesa libre Acomodar Bebidas Orden de bebidas y aperitivos no si Comida Tramitar comanda no Algo más? no Cobrar y despedir En el siguiente diagrama se representa el nuevo funcionamiento de la gestión de un restaurante, donde las funciones primarias se seguirán realizando pero en este caso, algunas de ellas, las realizará el sistema. Página 44

Bienvenida no Mesa libre Acomodar y presentación del sistema Bebidas Orden de bebidas y aperitivos directo a cocina no si Comida Funciones realizadas por el sistema Tramitar comanda directamente a cocina no Algo más? no Cobrar y despedir El flujo de trabajo actual, que posteriormente se mejorará con el sistema, se compone por los siguientes pasos: Página 45

1. Bienvenida: La principal función del mesero encargado del salón es dar la bienvenida los clientes y preguntarles la cantidad de personas que ocuparán la mesa. Inmediatamente, se buscará un sitio disponible si existe y después deberá acomodarlos en la mesa. Aquellos establecimientos que dispongan de áreas de fumadores y no fumadores, se colocará al cliente según la predilección. Una vez en la mesa, el camarero debe acomodarlos sacando las sillas, teniendo preferencia las damas. El mesero encargado del salón procederá a registrar los clientes en el registro y control de reservaciones, colocando la cantidad de clientes, la hora y el número de mesa asignado. 2. Orden de bebidas y aperitivos: Una vez abordados los clientes y después de darle la bienvenida, el camarero preguntará si el cliente desea algún aperitivo, vino o cóctel antes de ver la carta. Después de servir los cócteles el camarero debe preguntar si los clientes desean algún entremés. Después de servido el entremés, el camarero debe preguntar si desean repetir sus bebidas o prefieren ver la carta. En caso de que el cliente solicite ver la carta, la misma será entregada por el camarero. 3. Tramitar comandas: se atiende a los clientes, y se anotan las comandas. El camarero que ha tomado la comanda, debe hacerla entregar de inmediato, no olvidando apuntar en ésta la hora exacta en que se terminó de tomar, la entrega al camarero de Página 46

cocina, o sea, al ayudante o camarero encargado de transportar los platos de la cocina al comedor y viceversa. La distribución de las copias de la comanda se realiza según el estándar del establecimiento, que generalmente es de la manera siguiente: la original a cocina, una copia a la caja y una segunda copia al camarero de cocina. Las comandas deberán pasar primeramente por la caja, para que la cajera verifique si concuerdan las copias y ésta sellará o firmará las que irán a la cocina, se quedará con la que le corresponde y devolverá el resto de las copias al Camarero, quien inmediatamente deberá dirigirse a la cocina y entregar la comanda al supervisor. Este canta el pedido y la cocina funciona. 4. La despedida: el servicio termina con la despedida al cliente. El momento de la despedida es muy importante, ya que es la última impresión que el cliente se lleva del establecimiento. Es responsabilidad camarero despedirlo en la mesa cuando se levanta y en la puerta debe despedirlo el mesero encargado del salón. El nuevo sistema seguirá contando con los camareros para guardar la importante imagen del restaurante y atender a los clientes, pero se mejorará el proceso, haciendo esperar menos a los clientes, ofreciéndoles mayor información, y evitando errores en la transmisión de la información hasta la cocina. Página 47

El nuevo flujo de trabajo consistirá en los siguientes pasos: 1. Bienvenida: se acomodará a los clientes exactamente igual que de la manera habitual, pero en este caso, el camarero informará a los clientes de la posibilidad y el funcionamiento del módulo de mesa que pueden encontrar. 2. Orden de bebidas: en este caso, el sistema ofrecerá bebidas, aperitivos y todas aquellas sugerencias pertinentes antes de que los clientes hayan tomado la decisión sobre el menú. La comanda se transmitirá directamente desde la mesa de los clientes a la cocina, sin tener que necesitar la atención del camarero. 3. Tramitar comandas: después de que los clientes hayan decidido su selección a través del menú virtual, se confirmará la comanda, y se transmitirá directamente hasta la cocina, sin necesidad de atención del camarero. En la cocina, se recibirá la comanda realizada, y se podrá visualizar a través del módulo. Se atenderá la comanda y se editará una vez que haya sido atendida. Todo este proceso se registra en la base de datos para en un futuro, realizar un análisis. 4. La despedida: este servicio no variará, el camarero seguirá realizándolo de la forma habitual. Página 48

3.3.1 Órdenes de pago en un restaurante En este apartado se muestra el funcionamiento general de las compras y pago de un restaurante que no estará afectado por la implantación del sistema, pero que es importante conocer en detalle para una mejor comprensión del alcance y funcionamiento general de un restaurante. Se representa a continuación, un diagrama que muestra el curso de las órdenes de compra y pago de un restaurante, así como de los participantes implicados: Página 49

1. En primer lugar el chef en la cocina, o el mesero comprenden la necesidad de adquirir materiales por un pedido, o por haber llegado al límite mínimo de existencia de los mismos, en tal caso inicia el procedimiento de compra de materiales. 2. Posteriormente el chef o el mesero confecciona una solicitud de compra de mercaderías por duplicado. 3. El jefe del departamento de administración, verifica, estudia y aprueba los datos de solicitud de compra. 4. Después de su aprobación, se selecciona el proveedor adecuado según la orden emitida. Página 50

5. Se envía la orden de compra por duplicado: emite el original al proveedor, el duplicado lo guarda para su control y luego lo archiva. Archiva el original de la solicitud de compra y espera la llegada de las mercaderías. 6. A continuación, el proveedor recibe el remito, y lo reenvía por triplicado, envía a la administración las mercaderías junto con el original y una copia. 7. Después, la administración controla las mercaderías recibidas con el duplicado de la orden de compra (archivada provisoriamente), el original y el duplicado del recibo, enviados por el proveedor, distribuye la documentación, se firma el duplicado del recibo y lo envía al proveedor. 8. Posteriormente el proveedor emite la factura por triplicado a la administración. 9. Por último, la administración controla la factura con los recibos que se habían archivado y se verifica el cumplimiento de los plazos y lugares de entrega. Página 51

3.3.2 Modificaciones sobre el funcionamiento A continuación se representa de forma gráfica el funcionamiento de la gestión de las comandas de un restaurante, y posteriormente se procederá a analizar de forma detallada las mejoras que supondrá la implantación del sistema. En este caso, se producirá un gran impacto en el funcionamiento habitual, mejorando especialmente, el tiempo de atención del mesero al cliente, el tiempo de transmisión de la comanda desde el mesero al cliente, la calidad de la información ofrecida a los clientes, y la calidad de la información transmitida desde la mesa hasta la cocina. En el gráfico que se aprecia a continuación, se representan los procesos habituales de un restaurante, antes de la implantación del sistema. Página 52

Llegada nuevo cliente Espera de bienvenida Acomodamiento y muestra del menú Espera de decisión de la comanda Espera de tiempo de atención del camarero Toma de la comanda Espera de tiempo transmisión de la comanda Espera preparación de la comanda Entrega de la comanda Tiempo de consumo Despedida de cliente Página 53

A continuación, el gráfico que representa el nuevo funcionamiento, ahorrando distintos tiempos en el proceso: Llegada nuevo cliente Espera de bienvenida Acomodamiento y muestra del menú Espera de decisión de la comanda Toma de la comanda Espera preparación de la comanda Entrega de la comanda Tiempo de consumo Despedida de cliente Página 54

Como se puede observar, se han representado las actividades que deben atender los meseros, en círculos, y las esperas que se realizan en todo el proceso de consumo del cliente, en rectángulos. En el primer diagrama, se ha enmarcado en rojo, los tiempos que desaparecerán tras la implantación del sistema. Se puede observar como el tiempo de espera de atención al cliente, y el tiempo de transmisión de la comanda, desaparecen en el segundo diagrama, variando así, el proceso habitual y mejorando por tanto la atención y el servicio al cliente. Estos dos tiempos comentados anteriormente, desaparecen ya que la información se comunicará directamente de forma transparente, desde los clientes, hasta la cocina, llegando las comandas de forma inmediata, y acelerando por tanto, el proceso. Actualmente, una de las limitaciones más importantes de los restaurantes, especialmente aquellos de comida rápida, es el número de clientes que pueden albergar en su interior. La modificación de este proceso, está especialmente diseñado, para acelerarlo, evitando tiempos largos, los clientes tendrán el servicio requerido con mayor prontitud, y por lo tanto, además de quedar más satisfechos por la rapidez, podrán liberar antes sus plazas para la acogida de nuevos clientes. Página 55

En definitiva, el restaurante será capaz de atender a más clientes, y de mejor manera, en el mismo día, gracias a la implantación del sistema integral de gestión de restaurantes. Página 56

3.4 Unidades de la organización afectadas por la mecanización En este apartado se detallan las áreas afectadas por el proyecto actual, mediante una tabla en la que el grado con que se altera el funcionamiento de un determinado proceso se determina por el siguiente código. 0: Nada afectado. 1: Poco afectado. 2: Muy afectado. Funciones Perfiles Gerente Chef Ayudante de cocina Mesero encargado del salón Meseros 1.- Gestión del menú 2.- Gestión de las comandas 3.-Gestión de la economía 4.-Gestión de instalaciones 5.-Gestión de la publicidad 1 2 2 1 1 0 2 2 1 1 2 1 0 0 0 0 1 1 1 1 2 0 0 0 0 Página 57

En las siguientes líneas se explican los resultados obtenidos en la anterior tabla, que representa el alcance del sistema, los perfiles afectados en cada eje, y en el interior, una valoración con un resultado cualitativo del impacto. 1. Gestión del menú virtual: el menú virtual es la base del funcionamiento de todo el sistema, es por ello que todos los perfiles representados se verán afectados por su implantación. Concretamente, el que mayor impacto tendrá sobre el menú, será el chef, que es el encargado de diseñar los platos para el restaurante. Además, los ayudantes de cocina también participarán activamente en este diseño, el gerente deberá dar su aprobación, y los meseros deberán conocer con detalle la composición y funcionamiento del nuevo menú. 2. Gestión de las comandas: en este caso, la tramitación de las comandas afectará especialmente en la cocina, al chef y a los ayudantes de cocina ya que son los encargados de visualizar y atender las comandas a través del módulo correspondiente. Tanto el mesero encargado del salón, como el resto de meseros, deberán participar en la tramitación de comandas en caso de algún problema o duda por parte de los clientes, aunque en principio, el sistema está diseñado para que no tengan que participar prácticamente nada. 3. Gestión de la economía: todas las comandas que se realicen en el restaurante, pasarán por el servidor y este a su vez, las registrará en la base de datos. Toda esta información será de especial interés para el gerente, ya que en función de la demanda, Página 58

adoptará unas medidas u otras respecto a la buena marcha del negocio. 4. Gestión de las instalaciones: el reparto de mesas y la disposición de los clientes, quedará registrado en el sistema, y será una información importante tanto para los trabajadores de la cocina como para los trabajadores del salón. 5. Gestión de la publicidad: el gerente deberá decidir en este caso, qué sugerencias desea incluir para sus clientes, qué promociones puede lanzar o incluso, puede decidir vender un cierto espacio a terceras empresas o restaurantes socios para promocionarlos a través del sistema. Página 59

3.5 Lista de requisitos En este apartado se exponen los requisitos que debe cumplir el sistema. Para ello se han tenido en cuenta los objetivos identificados en el capítulo de Identificación de Necesidades, y se han recogido en forma de fichas individuales, fácilmente identificables y que ayudarán al diseño del nuevo sistema. Página 60

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Entorno de fácil uso. Identificador R-01 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción Diseño de un interfaz cómodo de fácil de uso para los usuarios. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios Tener un interfaz agradable, de uso fácil y claro facilita el trabajo al usuario y como consecuencia, rentabiliza el trabajo al máximo, eliminando tiempos adicionales por un mal diseño de la aplicación. Comentarios / Soluciones sugeridas La aplicación debe estar pensada para interactuar con ella de forma fácil e intuitiva. Debe ser apto para las manos, con botones lo suficientemente grandes, sin demasiada información, y sencillez. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 61

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión del menú virtual. Identificador R-02 Fecha 25/03/2010 Versión 1.0 Prioridad Alta Estado Aceptado Categoría Funcional Descripción La aplicación permitirá el alta/baja/modificación de los datos que se representará en el menú virtual. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios Tratará de innovar en la presentación del menú a los clientes, ofreciéndoles mayor simplicidad, información, y rapidez a la hora de realizar las comandas. Comentarios / Soluciones sugeridas Este requisito se desarrollará en el módulo de mesa. Existirá una base de datos, de la cual se obtendrá el menú. Documentos relacionados Ninguno Requisitos relacionados R-03/ R-04 Página 62

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de las imágenes del módulo de mesa. Identificador R-03 Fecha 25/03/2010 Versión 1.0 Prioridad Baja Estado Aceptado Categoría Funcional Descripción La aplicación permitirá el alta/baja/modificación de las imágenes que se representarán en el menú virtual. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios Tratará de innovar en la presentación del menú a los clientes, ofreciéndoles mayor simplicidad, información, y permitirá mostrar las imágenes de los platos que ofrece el restaurante. Comentarios / Soluciones sugeridas Este requisito se desarrollará en el módulo de mesa. Existirá una base de datos, de la cual se obtendrá el menú. Documentos relacionados Ninguno Requisitos relacionados R-04 Página 63

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de los vídeos del módulo de mesa. Identificador R-04 Fecha 25/03/2010 Versión 1.0 Prioridad Baja Estado Aceptado Categoría Funcional Descripción La aplicación permitirá el alta/baja/modificación de los vídeos que se representarán en el menú virtual. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios Tratará de innovar en la presentación del menú a los clientes, ofreciéndoles mayor simplicidad, información, y permitirá mostrar vídeos de los platos que ofrece el restaurante. Comentarios / Soluciones sugeridas Este requisito se desarrollará en el módulo de mesa. Existirá una base de datos, de la cual se obtendrá el menú. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 64

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de las comandas. Identificador R-05 Fecha 25/03/2010 Versión 1.0 Prioridad Alta Estado Aceptado Categoría Funcional Descripción La aplicación permitirá el alta/baja/modificación de las comandas que realicen los clientes a través del módulo de mesa. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor información en la gestión. Comentarios / Soluciones sugeridas Los clientes podrán seleccionar los platos del menú que desean consumir, se registrarán en la base de datos, y se mostrará posteriormente en el módulo de cocina. Documentos relacionados Ninguno Requisitos relacionados R-06 Página 65

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de los ingredientes. Identificador R-06 Fecha 25/03/2010 Versión 1.0 Prioridad Alta Estado Aceptado Categoría Funcional Descripción La aplicación permitirá el alta/baja/modificación de los ingredientes que componen cada plato. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor información en la gestión. Comentarios / Soluciones sugeridas El sistema permitirá registrar la información referente a la composición de cada plato, y los clientes tendrán acceso a esta información a través del módulo de cocina. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 66

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de la economía. Identificador R-07 Fecha 25/03/2010 Versión 1.0 Prioridad Alta Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente de los datos económicos del restaurante. Medición Se registrará en la base de datos, el consumo que realiza cada cliente, el precio de cada plato y la suma total de todas las consumiciones. Beneficios A pesar de tratarse de una funcionalidad recogida en los sistemas informáticos actuales, supondrá un valor añadido al formar parte de la plataforma integral que contiene todos los módulos necesarios para la gestión de restaurantes. Comentarios / Soluciones sugeridas Sólo en el módulo de cocina se podrá tener acceso a la información, a través de una interfaz intuitiva, que mostrará el resumen principal de los datos económicos. Documentos relacionados Ninguno Requisitos relacionados R-08 / R-21 Página 67

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de la facturación. Identificador R-08 Fecha 25/03/2010 Versión 1.0 Prioridad Alta Estado Aceptado Categoría Funcional Descripción La aplicación permitirá el alta/baja/modificación de los datos de las facturas. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios A pesar de tratarse de una funcionalidad recogida en los sistemas informáticos actuales, supondrá un valor añadido al formar parte de la plataforma integral que contiene todos los módulos necesarios para la gestión de restaurantes. Comentarios / Soluciones sugeridas Sólo en el módulo de cocina se podrá tener acceso a la información, a través de una interfaz intuitiva, que mostrará el resumen principal de las facturas. Documentos relacionados Ninguno Requisitos relacionados R-21 Página 68

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de las instalaciones. Identificador R-09 Fecha 25/03/2010 Versión 1.0 Prioridad Alta Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente de las instalaciones del restaurante. Para ello se deben desarrollar los siguientes submódulos: gestión del salón y gestión de la cocina. Medición El sistema estará compuesto por el módulo de mesa, de acceso a los clientes, que gestionará el salón, y el módulo de cocina, que se implantará en la cocina. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor información en la gestión. Comentarios / Soluciones sugeridas El acceso a los distintos módulos se realizará según estén ubicados físicamente, puede ser desde la cocina, o desde el salón. Documentos relacionados Ninguno Requisitos relacionados R-10 / R-11 Página 69

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión del salón. Identificador R-10 Fecha 25/03/2010 Versión 1.0 Prioridad Alta Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente de los módulos que se encuentren en el salón del restaurante. Medición El sistema estará compuesto por el módulo de mesa, de acceso a los clientes, que gestionará el salón, y el módulo de cocina, que se implantará en la cocina. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor información en la gestión. Comentarios / Soluciones sugeridas El acceso se realizará desde los módulos de mesa, situados en las mesas de los clientes. Documentos relacionados Ninguno Requisitos relacionados R-11 Página 70

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de la cocina. Identificador R-11 Fecha 25/03/2010 Versión 1.0 Prioridad Alta Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente de los módulos que se encuentren en la cocina del restaurante. Medición El sistema estará compuesto por el módulo de mesa, de acceso a los clientes, que gestionará el salón, y el módulo de cocina, que se implantará en la cocina. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor información en la gestión. Comentarios / Soluciones sugeridas El acceso se realizará desde el módulo de cocina, desde el cual se tendrá acceso a información detallada sobre las comandas y la disposición de los clientes, así como de la facturación. Documentos relacionados Ninguno Requisitos relacionados R-10 Página 71

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de la publicidad. Identificador R-12 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación comprenderá una gestión eficiente de la publicidad, compuesta por la promoción y sugerencias que ofrece el restaurante a sus clientes. Medición Este requisito se implantará en el módulo de mesa de los clientes. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor funcionalidad y mejora del negocio para el restaurante. Comentarios / Soluciones sugeridas La publicidad y sugerencias que desee realizar el restaurante, se mostrarán en los módulos de mesa directamente a los clientes, estimulando la demanda o vendiendo el espacio publicitario a terceras empresas. Documentos relacionados Ninguno Requisitos relacionados R-14 Página 72

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión del personal. Identificador R-13 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente de la gestión del personal de restaurante, diferenciando entre el personal de cocina o el personal de salón. Medición El módulo de gestión de personal se compondrá de los módulos de cocina y de salón, diferenciando en ambos grupos los distintos trabajadores. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor funcionalidad y mejora del negocio para el restaurante. Comentarios / Soluciones sugeridas El sistema se compondrá de un módulo de cocina y de un módulo de mesa, desde cada uno, se tendrá acceso a una información diferente y se gestionará el personal según sea el acceso. Documentos relacionados Ninguno Requisitos relacionados R-15 / R-16 Página 73

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de las sugerencias. Identificador R-14 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación comprenderá una gestión eficiente de las sugerencias que desee hacer el chef a los clientes del restaurante. Medición Este requisito se implantará en el módulo de mesa de los clientes. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor funcionalidad y mejora del negocio para el restaurante. Comentarios / Soluciones sugeridas Las sugerencias que desee realizar el restaurante, se mostrarán en los módulos de mesa directamente a los clientes, estimulando la demanda. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 74

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión del personal de cocina. Identificador R-15 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente del personal de la cocina, que estará compuesto por el chef y sus ayudantes. Medición El módulo de gestión de personal se compondrá de los módulos de cocina y de salón, diferenciando en ambos grupos los distintos trabajadores. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor funcionalidad y mejora del negocio para el restaurante. Comentarios / Soluciones sugeridas El sistema controlará el acceso del módulo de cocina, y según el perfil, los trabajadores tendrán acceso a información específica, como la gestión de las comandas o la gestión del menú virtual. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 75

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión del personal de salón. Identificador R-16 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente del personal de salón, que estará compuesto por el encargado y los camareros. Medición El módulo de gestión de personal se compondrá de los módulos de cocina y de salón, diferenciando en ambos grupos los distintos trabajadores. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor funcionalidad y mejora del negocio para el restaurante. Comentarios / Soluciones sugeridas El sistema controlará el acceso del módulo de cocina, y según el perfil, los trabajadores tendrán acceso a información específica, como la gestión de la publicidad o la gestión del menú virtual. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 76

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de las tareas. Identificador R-17 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente de las tareas pendientes por realizar, y las tareas realizadas. Medición Este requisito se implantará en el módulo de cocina. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor funcionalidad y mejora del negocio para el restaurante. Comentarios / Soluciones sugeridas El sistema gestionará las tareas que no han sido aún atendidas y aquellas que ya se han atendido, se marcarán como satisfechas, permitiendo así una mejor gestión de las comandas en la cocina. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 77

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de los restaurantes. Identificador R-18 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente de los distintos restaurantes en los cuales esté implantado el sistema. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una mayor funcionalidad y mejora del negocio para el restaurante. Comentarios / Soluciones sugeridas El sistema permitirá, en aquellos casos en los que existan varios restaurantes pertenecientes a la misma empresa, imprimir la información sobre datos de los distintos negocios para su posterior análisis. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 78

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de los cobros. Identificador R-19 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación permitirá una gestión eficiente de los distintos restaurantes en los cuales esté implantado el sistema. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios A pesar de tratarse de una funcionalidad recogida en los sistemas informáticos actuales, supondrá un valor añadido al formar parte de la plataforma integral que contiene todos los módulos necesarios para la gestión de restaurantes. Comentarios / Soluciones sugeridas Este requisito se desarrollará en un módulo de cocina. Debido a la multitud de datos presentes en la base de datos de la aplicación, los informes resultarán útiles a la dirección. Documentos relacionados Ninguno Requisitos relacionados Ninguno Requisitos relacionados Ninguno Página 79

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Login como precondición de acceso al sistema. Identificador R-20 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción Para la realización de todas las operaciones que la aplicación permitirá, se requerirá el empleo de un login inicial que permita conectarse a la misma sólo los empleados registrados. De este modo, se evitarán intrusismos. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios Gracias a la implementación de este requisito se conseguirá filtrar los accesos a la aplicación y se permitirá una adaptación de las tareas permitidas a los usuarios según su perfil. Comentarios / Soluciones sugeridas Para la verificación del usuario y contraseña se acudirá a la tabla de empleados en la que se almacenan estos datos. La administración del perfil se realizará según esa misma tabla. Documentos relacionados Ninguno Requisitos relacionados Ninguno Página 80

Proyecto: Sistema Integral de Gestión de Restaurantes Jefe de proyecto: Gorka Díaz de Orbe Requisitos Título Gestión de los informes. Identificador R-21 Fecha 25/03/2010 Versión 1.0 Prioridad Media Estado Aceptado Categoría Funcional Descripción La aplicación creará informes sobre las comandas pendientes, atendidas y los datos de la facturación obtenida. Medición Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas que validen su correcto funcionamiento. Beneficios A pesar de tratarse de una funcionalidad recogida en los sistemas informáticos actuales, supondrá un valor añadido al formar parte de la plataforma integral que contiene todos los módulos necesarios para la gestión de restaurantes. Comentarios / Soluciones sugeridas Este requisito se desarrollará en un módulo de cocina. Debido a la multitud de datos presentes en la base de datos de la aplicación, los informes resultarán útiles a la dirección. Documentos relacionados Ninguno Requisitos relacionados R-07 / R-08 Requisitos relacionados Ninguno Página 81

3.6 Modelo lógico de datos En este apartado se analiza el modelo lógico del nuevo sistema. Para su obtención se ha partido del análisis del sistema actual y de la lista de requisitos del sistema. 3.6.1 DFD contextual A continuación, se muestra el DFD contextual de la aplicación a desarrollar, donde se representa las entidades externas y el sistema. El sistema se interrelacionará con dos tipos de usuarios diferentes, ofreciéndoles a cada uno una información diferente, y recibiendo también unas entradas diferentes. Uno de los usuarios serán los clientes que accederán desde el módulo de mesa al menú virtual y realizarán sus comandas, y otro usuario será el personal de cocina, que atenderá las comandas, las editará según se vayan atendiendo, y además tendrán acceso a otros módulos del sistema que se han especificado en la lista de requisitos anteriormente. Usuario cliente entradas salidas 0 Sistema Integral de Gestión de Restaurantes salidas entradas Usuario cocina Página 82

3.6.2 DFD conceptual A continuación, se muestra el DFD conceptual del sistema. Para mayor claridad, se representará por niveles, lo que facilitará la comprensión del mismo. 3.6.2.1 DFD conceptual de primer nivel En este apartado, se presenta el DFD conceptual de primer nivel, que muestra el funcionamiento global de la aplicación, que se descompone en los cuatro módulos descritos a continuación: Menú virtual: permitirá mostrar el menú de forma virtual, actualizarlo, recibir sugerencias y promociones, enviar una selección de comandas y mostrar el total a pagar después de haber consumido. Comandas: se recibirán las comandas del menú virtual, se mostrarán por pantalla en el módulo de cocina, y se guardarán en una base de datos para sacar informes. Publicidad: se usará este módulo para aplicar promociones a los clientes, mostrar sugerencias o publicidad en el menú virtual Informes: leerá la información pertinente de la base de datos para sacar estadísticas e informes de interés al gerente del restaurante. Página 83

3 Publicidad SUGERENCIAS sugerencia a cliente opción 4 Menú virtual MENÚ empleado 1 Login 2 Menú principal menú a cliente password comanda EMPLEADOS 5 Comandas COMANDAS factura aviso cocina 6 Informes FACTURAS informe Página 84

En el diagrama anterior se ha representado el flujo de la información en el sistema, a continuación se detallan todos los componentes que intervienen en el mismo: 1. Login: proceso que controla el acceso a la aplicación, verificando que el usuario que está entrando en el sistema, es un empleado, según los permisos que tenga tendrá un acceso posterior para el acceso de informes, y la inserción de publicidad, o bien sólo la visualización y edición de comandas en el módulo de cocina. 2. Menú principal: será el punto de partida de la aplicación. Desde este menú se podrán gestionar las promociones y publicidad, el menú virtual, las comandas y los informes. 3. Publicidad: proceso que gestiona las sugerencias, promociones y publicidad que se mostrarán a los clientes. Se detallará a continuación su funcionamiento a través de otro diagrama de flujo de datos. 4. Menú virtual: proceso que gestiona el menú virtual que se mostrará a los clientes, así como el envío de la comanda una vez haya sido seleccionada. Se detallará a continuación su funcionamiento a través de otro diagrama de flujo de datos. 5. Comandas: proceso que gestiona todas las comandas que realizan los clientes y que se envían a la cocina, para posteriormente mostrarlo en el módulo. Además, agrupará las comandas de una misma mesa y las enviará a una base de datos de facturas para posteriormente obtener informes. Se detallará a Página 85

continuación su funcionamiento a través de otro diagrama de flujo de datos. 6. Informes: proceso que gestiona la obtención de informes a partir de comandas realizadas por los clientes. Se detallará a continuación su funcionamiento a través de otro diagrama de flujo de datos. Página 86

MINIESPECIFICACIONES Tipo Nombre Atributos Descripción Proceso Login - Proceso encargado de controlar el acceso a la aplicación. Proceso Menú principal - Proceso que genera un menú personalizado con distintas opciones en función del usuario y de su perfil. Proceso Publicidad - Proceso que gestiona las sugerencias, promociones y publicidad que se mostrarán a los clientes. Proceso Menú virtual - Proceso que gestiona el menú virtual que se mostrará a los clientes, así como el envío de la comanda una vez haya sido seleccionada. Proceso Comandas - Proceso que gestiona todas las comandas que realizan los clientes y que se envían a la cocina, para posteriormente Página 87

mostrarlo en el módulo. Además, agrupará las comandas de una misma mesa y las enviará a una base de datos de facturas para posteriormente obtener informes. Proceso Informes - Proceso que gestiona la obtención de informes a partir de comandas realizadas por los clientes. Flujo de Empleado - Clave de usuario. datos Necesario para acceder a la aplicación. Flujo de datos Flujo de datos Password - Contraseña del usuario. Sugerencia a - Envío al menú virtual del cliente cliente, las sugerencias del restaurante si procede. Flujo de datos Menú a cliente - Impresión en el módulo de mesa, del menú confeccionado para el cliente, con las sugerencias pertinentes. Flujo de Comanda - Envío de la comanda Página 88

datos desde el módulo de mesa al módulo de gestión de comandas para su registro. Flujo de datos Aviso a cocina - Envío de la comanda registrada, al módulo de cocina. Flujo de datos Factura - Envío de todas las comandas realizadas por un mismo cliente a lo largo de su estancia, para agruparlas, tratarlas y obtener el total a pagar posteriormente. Flujo de datos Informe - Impresión de los informes de carácter económico al gerente del restaurante. Almacén de datos EMPLEADOS ID_EMP, PASS Registra las acciones relacionadas con los usuarios. Almacén de SUGERENCIAS ID_SUG, Información sobre las datos DESCR sugerencias que ofrece el restaurante. Almacén de MENÚ ID_PLATO, Información sobre el datos INGRED, menú, y los ingredientes DESC, de los que dispone el Página 89

PRECIO_UNIT restaurante. Almacén de COMANDAS MESA, Información sobre las datos FECHA, comandas que van HORA, realizando los clientes y ID_PLATO, que se visualizarán en la CANT cocina. Almacén de FACTURAS ID_COMANDA, Información sobre la datos TOTAL, facturación total del FECHA, HORA restaurante, para cada día. Página 90

3.6.2.2 DFD conceptual de segundo nivel. Módulo publicidad. A continuación, se muestra un diagrama del módulo publicidad, que ha sido anteriormente recogido en R-14 en la lista de requisitos: Solicitud alta 3.1 Alta sugerencia Solicitud modificación 3.2 Modificación sugerencia SUGERENCIAS Solicitud baja 3.3 Baja sugerencia sugerencia 3.4 Aplicar sugerencia Página 91

MINIESPECIFICACIONES Tipo Nombre Atributos Descripción Proceso Alta sugerencia - Este proceso da de alta una nueva sugerencia en la base de datos. Necesita una solicitud de alta y el resultado es una inserción en la base de datos. Proceso Modificación sugerencia - Este proceso modifica una sugerencia del restaurante de la base de datos. Necesita que el administrador del sistema envíe la orden. Proceso Baja sugerencia - Este proceso elimina una sugerencia del restaurante de la base de datos. Necesita que el administrador del sistema envíe la orden. Proceso Aplicar sugerencia - Este proceso verifica las promociones existentes para los clientes, y en caso de que exista alguna, la envía al Página 92

módulo de mesa. Flujo de datos Solicitud alta - Solicitud por parte del administrador del sistema de crear una nueva sugerencia. Flujo de datos Solicitud modificación - Solicitud por parte del administrador del sistema de modificar una sugerencia. Flujo de datos Solicitud baja - Solicitud por parte del administrador del sistema de dar de baja una sugerencia. Flujo de datos Sugerencia - Envío de la sugerencia encontrada, directamente al cliente. Almacén de SUGERENCIAS ID_PLATO, Información sobre las datos SUGER sugerencias que ofrece el restaurante, con un campo que identifica al plato sugerido y la descripción que se mostrará a los clientes. Página 93

3.6.2.3 DFD conceptual de segundo nivel. Módulo menú virtual. A continuación, se muestra un diagrama del módulo menú virtual, que ha sido anteriormente recogido en R-02 en la lista de requisitos: sugerencia 4.1 Procesar menú Solicitud alta 4.2 Alta menú menú MENÚ Solicitud baja 4.3 Baja menú Solicitud modificación 4.4 Modificación menú comanda 4.5 Enviar selección Página 94

MINIESPECIFICACIONES Tipo Nombre Atributos Descripción Proceso Alta menú - Este proceso da de alta un nuevo menú en la base de datos. Necesita una solicitud de alta y el resultado es una inserción en la base de datos. Proceso Modificación menú - Este proceso modifica el menú del restaurante de la base de datos. Necesita que el administrador del sistema envíe la orden. Proceso Baja menú - Este proceso elimina el menú del restaurante de la base de datos. Necesita que el administrador del sistema envíe la orden. Proceso Procesar menú - Este proceso muestra el menú al cliente, según las sugerencias particulares que el restaurante le ofrece, y después guarda la selección del usuario para procesarla como Página 95

comanda junto con otro proceso. Proceso Enviar selección - Este proceso envía la comanda del cliente, a la cocina, una vez que se la han mostrado las promociones y sugerencias en el menú. Flujo de datos Solicitud alta - Solicitud por parte del administrador del sistema de crear un nuevo menú. Flujo de datos Solicitud modificación - Solicitud por parte del administrador del sistema de modificar el menú. Flujo de datos Solicitud baja - Solicitud por parte del administrador del sistema de dar de baja el menú. Flujo de datos Comanda - Envío de la comanda realizada por el cliente, directamente a la cocina. Almacén de MENÚ ID_PLATO, Información sobre los datos INGRED, platos que componen el DESCR, menú y que se mostrará a Página 96

URL, PRECIO_UNIT los clientes junto con su descripción correspondiente, una url del vídeo o foto ilustrativo, ingredientes y precio Página 97

3.6.2.4 DFD conceptual de segundo nivel. Módulo comandas. A continuación, se muestra un diagrama del módulo comandas, que ha sido anteriormente recogido en R-05 en la lista de requisitos: comanda 5.1 Alta comanda COMANDAS Solicitud baja 5.2 Baja comanda Solicitud modificación 5.3 Modificación comanda Comanda a cocina 5.4 Procesar comanda Página 98

MINIESPECIFICACIONES Tipo Nombre Atributos Descripción Proceso Alta comanda - Este proceso da de alta la comanda del cliente en la base de datos. Necesita una solicitud de alta enviada por el cliente y el resultado es una inserción en la base de datos. Proceso Modificación comanda - Este proceso modifica la comanda del cliente de la base de datos. Necesita que el administrador del sistema envíe la orden. Proceso Baja comanda - Este proceso elimina la comanda del cliente de la base de datos. Necesita que el administrador del sistema envíe la orden. Proceso Procesar comanda - Este proceso muestra la comanda del cliente al módulo de cocina, después de haberse guardado en la base de datos, y a su vez, envía la Página 99

comanda a otro proceso para que se registre en la base de datos de facturación para su posterior estudio. Flujo de datos Comanda - Recepción por parte del cliente de su comanda, y registro en la base de datos, después se mostrará en la cocina. Flujo de datos Flujo de datos Solicitud modificación - Solicitud por parte del administrador del sistema de modificar la comanda. Solicitud baja - Solicitud por parte del administrador del sistema de dar de baja una comanda. Flujo de datos Comanda a cocina - Impresión en el módulo de cocina, de la comanda, y envío al módulo de facturación la misma para su proceso. Almacén de COMANDAS ID_CLI, Información sobre la datos MESA, comanda que ha realizado FECHA, el cliente, incluyendo un HORA, número que le ID_PLATO, identifique, su mesa, la Página 100

CANT fecha y hora, los platos que pide, y la cantidad de cada uno de ellos. Página 101

3.6.2.5 DFD conceptual de segundo nivel. Módulo informes. A continuación, se muestra un diagrama del módulo informes, que ha sido anteriormente recogido en R-20 en la lista de requisitos: Comanda a cocina 6.1 Alta factura Solicitud modificación 6.2 Modificación factura FACTURAS Solicitud baja 6.3 Baja factura informe 6.4 Informe facturación Página 102

MINIESPECIFICACIONES Tipo Nombre Atributos Descripción Proceso Alta factura - Este proceso da de alta una nueva factura en la base de datos. Para ello se utiliza las comandas de los clientes que llegan a la cocina y el resultado es una inserción en la base de datos. Proceso Modificación factura - Este proceso modifica una factura de la base de datos. Necesita que el administrador del sistema envíe la orden. Proceso Baja factura - Este proceso elimina una factura de la base de datos. Necesita que el administrador del sistema envíe la orden. Proceso Informe de facturación - Este proceso imprime un informe de la facturación del restaurante, utilizando la información Página 103

almacenada en la base de datos. Flujo de datos Comanda a cocina - La comanda que se recibió en la cocina, se guarda en la base de datos de facturas para su proceso. Flujo de datos Solicitud modificación - Solicitud por parte del administrador del sistema de modificar una factura de la base de datos. Flujo de datos Solicitud baja - Solicitud por parte del administrador del sistema de dar de baja una factura. Flujo de datos Informe - Informe de facturación con todos los datos correspondientes a la actividad del restaurante. Almacén de FACTURAS ID_CLI, Información sobre las datos TOTAL, facturas que ha realizado FECHA, el restaurante a sus HORA clientes, a partir de las comandas. Página 104

3.6.3 Modelo conceptual de datos. El modelo conceptual de datos trata de modelar la gama de información que manejará el nuevo sistema. Este modelo se obtiene a partir de la situación actual y de los requisitos previamente establecidos. El modelo conceptual describe las características principales de los datos del sistema. De forma similar al modelo de procesos analizado anteriormente, el modelo de datos consta de dos elementos: un esquema grafico y una especificación de los componentes de ese esquema. Para la realización de esta metodología se ha seguido el libro [BARR01] que aparece en la bibliografía. El modelo conceptual describe las entidades, atributos y relaciones de interés para el negocio a representar. Este modelo deberá ser independiente del hardware y software utilizado para el manejo de los datos. Para la realización de este apartado se utilizará un método de análisis de datos basado en el análisis entidad-relación que consta de los siguientes elementos: - Entidades. Son objetos que tienen una existencia propia conforme a las decisiones de gestión de la empresa. Es Página 105

aquello de interés duradero para la empresa, sobre lo cual se pueden almacenar datos e identificar de un modo único. - Relaciones. Son las representaciones de asociación entre entidades. Las relaciones establecen el grado de asociación entre dos estructuras de datos diferentes. - Atributos. Son características de una entidad que sirven para definir, describir y clasificar. Cabe destacar que, por motivos de optimización, las sugerencias se han separado en una tabla aparte, en lugar de añadirse como atributo al menú ya que será una información que cambiará con alta frecuencia, que no siempre se mostrará, evitando así, accesos constantes a todo el menú cada vez que se quiera editar una sugerencia, simplificando los accesos y reduciendo el tiempo. El modelo conceptual de datos del sistema resultará claro y sencillo, ya que ha sido diseñado según la metodología estudiada, sin embargo la especial complejidad del sistema residirá en la funcionalidad y el trato que se da a esta información. A continuación se representa el modelo entidad-relación para el sistema integral de gestión de restaurantes con sus respectivos atributos y relaciones: Página 106

Facturas -id_cli -total -fecha -hora 1 * Comandas -id_cli -mesa -fecha -hora -id_plato -cant 0..* Menú -id_plato -ingred -desc -url -precio_unit 1 1 * Sugerencias -id_plato -suger FACTURAS = { ID_CLI, TOTAL, FECHA, HORA} COMANDAS = { ID_CLI, ID_PLATO, MESA, FECHA, HORA, CANT} MENU = { ID_PLATO, INGRED, DESCR, URL, PRECIO_UNIT } SUGERENCIAS = {ID_PLATO, SUGER } Página 107

3.6.3.1 Relaciones principales entre entidades En este apartado se desarrolla cada una de las relaciones expresadas en el diagrama junto con el nombre que mejor explicaría su contenido. FACTURAS COMANDAS (COMPUESTO POR): una factura, solo tiene sentido de existir, si está compuesto por un conjunto de comandas de un mismo cliente. Por otro lado, cada comanda, aparecerá solamente en una única factura ya que es individual, y el campo que lo identificará será el id_cliente junto con la hora y fecha. COMANDAS MENÚ (POSEE): una comanda, estará formada por un único plato que aparezca en el menú, sin embargo, un plato del menú, puede aparecer en distintas comandas, o incluso en ninguna en el caso en que no se haya pedido nunca ese plato. MENU SUGERENCIAS (POSEE): un plato del menú, podrá tener o no una sugerencia asociada, mientras que una sugerencia siempre tendrá siempre un plato del menú asociado. Página 108

4) Estudio de la arquitectura

4. ESTUDIO DE LA ARQUITECTURA En esta etapa se definen las distintas arquitecturas posibles para desarrollar este proyecto que satisfagan los requisitos de usuario y de diseño. Para ello se propondrán dos alternativas evaluando las ventajas e inconvenientes de cada una de ellas. Posteriormente, se elegirá la más adecuada para ser desarrollada e implementada. 4.1 Especificación de las alternativas A continuación se muestran las posibles soluciones que podrían utilizarse para el funcionamiento y la puesta en marcha del sistema. 4.1.1 Arquitecturas 4.1.1.1 Arquitectura cliente-servidor (cliente pesado) Esta arquitectura se divide en dos partes claramente diferenciadas, la primera es la parte del servidor y la segunda la de un conjunto de clientes. Normalmente el servidor es una máquina bastante potente que actúa de depósito de datos y funciona como un sistema gestor de base de datos (SGBD). Por otro lado los clientes suelen ser estaciones de trabajo que solicitan varios servicios al servidor. Página 110

Una aplicación informática con arquitectura cliente-servidor consta de dos programas: El programa cliente, que se ejecuta en el ordenador que interactúa con el usuario (habitualmente un ordenador personal). El programa servidor, que se ejecuta en un servidor central (habitualmente en un servidor dentro de un CPD). Ambos programas colaboran entre sí gracias a una red de comunicaciones. Las funcionalidades de la aplicación deben repartirse entre ambos programas, en principio, de forma equitativa. Sin embargo, por razones de viabilidad técnica o económica puede ser necesario un reparto desigual de dichas funcionalidades. Se denomina cliente pesado al programa "cliente" de una arquitectura cliente-servidor cuando la mayor carga de cómputo está desplazada hacia la computadora que ejecuta dicho programa. Por ejemplo, en una arquitectura cliente servidor con un cliente pesado, se realizarían así las tareas para el sistema integral de gestión de restaurantes: Cliente: Página 111

o Representación de los datos en la interfaz gráfica. o Proceso de login en el sistema (cifrado de conexión). o Exportación de datos a otros formatos. o Impresión de informes por pantalla. o Calcular el importe total de la factura. o Aplicar ofertas y descuentos. o Calcular el ticket de compra. Servidor: o Almacenamiento de datos y facturas. o Procesado de comandas. o Ejecución de transacciones Página 112

Para un posterior estudio de la mejor alternativa posible, que se adaptará al sistema integral de gestión de restaurantes, se presentan a continuación las ventajas e inconvenientes del uso de una arquitectura cliente-servidor con cliente pesado. Mayor aprovechamiento de la capacidad de cómputo de los ordenadores que lo ejecutan, generalmente infrautilizadas, en favor del servidor. Dicho servidor asume menos funciones y, por tanto, puede atender a un número mayor de programas cliente con los mismos recursos. Mejor desempeño multimedia. Los clientes pesados tienen ventajas en aplicaciones ricas en multimedia que serían intensivas en ancho de banda si estuvieran completamente residentes en los servidores. Por ejemplo, los clientes pesados están bien adaptados para la edición de vídeo. Apropiado para conexiones de red pobres. Los clientes ligeros pueden ser inusualmente lentos, o muy frustrantes para usar, sobre una conexión de red de alta latencia. Por otra parte, no trabajan en absoluto cuando la red está caída. Riqueza en el interfaz de usuario. El interfaz no está limitado por las características de un cliente universal, por ejemplo, un navegador web. Por tanto, pueden diseñarse interfaces complejos, ricos y más fáciles de usar. Sin embargo, como inconvenientes cabe destacar: Página 113

El cliente pesado necesita ser instalado en cada uno de los ordenadores cliente, y posteriormente actualizado en todas ellos cuando sea necesario. Pueden surgir incompatibilidades. Dado que no todos los ordenadores son idénticos y pueden disponer de distinto software de base, es posible que la aplicación no funcione correctamente en algunos lugares. En ocasiones, el diseñador de la aplicación no conoce a priori cuál es el perfil del ordenador que debe ejecutarlo. Es necesaria una infraestructura para la instalación y actualización de la aplicación de manera desatendida. Es inviable realizar dichas tareas utilizando medios humanos cuando se trata de cientos de ordenadores. A continuación se representa gráficamente la arquitectura clienteservidor, donde a la izquierda aparecen los clientes, conectados con el servidor, que contiene las bases datos, a través de una red local: Página 114

Página 115

4.1.1.2 Arquitectura cliente-servidor (cliente liviano) Un cliente liviano o cliente ligero es un ordenador cliente o un software de cliente en una arquitectura de red cliente-servidor que depende primariamente del servidor central para las tareas de procesamiento, y principalmente se enfoca en transportar la entrada y la salida entre el usuario y el servidor remoto. En contraste, un cliente pesado hace tanto procesamiento como sea posible y pasa solamente los datos para las comunicaciones y el almacenamiento al servidor. Muchos dispositivos de cliente liviano ejecutaban solamente navegadores web o programas de escritorio remoto, lo que significaba que todo el procesamiento significativo ocurría en el servidor. Sin embargo, dispositivos recientes etiquetados como clientes livianos pueden correr sistemas operativos completos tales como Linux Debian, calificándose como nodos sin disco o clientes híbridos. Algunos clientes ligeros también son llamados "terminales de acceso". Por consecuencia, el término "cliente ligero", en términos de hardware, ha venido a abarcar cualquier dispositivo usado como, un cliente ligero en la definición original, incluso si sus capacidades reales son mucho mayores. El término también es a veces usado en un sentido incluso más amplio que incluye nodos sin disco. En un sistema cliente liviano-servidor, el único software que es instalado en el cliente ligero es la interface de usuario, algunas aplicaciones frecuentemente usadas, y un sistema operativo de red. Este software puede ser cargado desde una unidad de disco local, del Página 116

servidor en tiempo de arranque, o según lo que se necesite. Al simplificar la carga en el cliente ligero, éste puede ser un dispositivo muy pequeño y de baja energía, que da costos de compra y de operación más bajos en cada puesto. El servidor, o un clúster de servidores, tiene el peso total de todas las aplicaciones, servicios, y datos. Al mantener algunos servidores ocupados y muchos clientes livianos ligeramente cargados, los usuarios pueden esperar una administración de sistemas más fácil y costos más bajos, así como todas las ventajas de la computación en red: almacenamiento y respaldo centralizados y una seguridad más fácil. Debido a que los clientes ligeros son numerosos pero relativamente pasivos y de bajo mantenimiento, el sistema entero es más simple y más fácil de instalar y operar. A medida que el costo del hardware baja y el costo de emplear un técnico y de energía, aumenta, las ventajas de los clientes ligeros crecen. Por otro lado, desde la perspectiva del usuario, la interacción con el monitor, el teclado, y el ratón cambia poco respecto a cuando se está usando un cliente pesado. Para un posterior estudio de la mejor alternativa posible, que se adaptará al sistema integral de gestión de restaurantes, se presenta a continuación las ventajas del uso de una arquitectura cliente-servidor con cliente liviano. Menores costes de administración. Los clientes ligeros son manejados casi enteramente en el servidor. El hardware tiene Página 117

menos lugares donde puede fallar, el entorno local es altamente restringido, y el cliente es más simple y a menudo carece de almacenamiento permanente, proporcionando protección contra el malware. Información centralizada. Como la información se encuentra en un solo lugar facilita la realización de backups y evita que se guarden archivos que no sean del negocio. Más fácil de asegurar. Los clientes livianos pueden ser diseñados de modo que ni siquiera los datos de aplicación residan en el cliente (apenas son exhibidos en la pantalla), centralizando la protección contra el malware y reduciendo los riesgos de hurto de los datos físicos. Seguridad de datos mejorada. Si un dispositivo del cliente ligero sufre una seria desgracia o accidente de trabajo, no se perderá ningún dato, puesto que residen en el servidor y no en el dispositivo de punto de operación. Costos de hardware más bajos. El hardware del cliente ligero es generalmente más barato porque no contiene disco duro, memoria de aplicaciones, o un procesador poderoso. Generalmente también tienen un período más largo antes de requerir una mejora o llegar a ser obsoletos. Hay menos piezas móviles y uno actualiza o mejora el servidor y la red en lugar de los clientes, porque la limitación en desempeño es la resolución de pantalla que tiene un ciclo de vida muy largo. Muchos clientes pesados son reemplazados después de 3 años para evitar fallos del hardware en servicio y para usar el último software, mientras que los clientes ligeros pueden hacer la misma tarea de desplegar Página 118

imágenes por 10 años. Los requisitos totales de hardware para un sistema de cliente ligero (incluyendo tanto servidores como clientes) son generalmente mucho más bajos comparados a un sistema con clientes pesados. Una razón de esto es que el hardware es mejor utilizado. Una CPU en una estación de trabajo pesada está ociosa la mayor parte del tiempo. Con los clientes ligeros, los ciclos del CPU son compartidos. Si varios usuarios están corriendo la misma aplicación, solo necesita ser cargada una sola vez en un servidor central (si la aplicación está escrita para soportar esta capacidad). Con los clientes pesados, cada estación de trabajo debe tener en memoria su propia copia del programa. Menos consumo de energía. El hardware dedicado de cliente ligero tiene un consumo de energía mucho más bajo que los típicos PC de clientes pesados, ahorrando hasta un 80% de electricidad y cuidando el medio ambiente. Esto no sólo reduce los costes de energía en los sistemas de computación, en algunos casos puede significar que los sistemas de aire acondicionado no son requeridos o no necesitan ser actualizados lo que puede ser un ahorro de costos significativo y contribuir a alcanzar los objetivos en ahorro de energía. Sin embargo, se requieren servidores y sistemas de comunicaciones más poderosos. Mejor gestión de los fallos de hardware. Si un cliente ligero falla, un reemplazo puede ser simplemente colocado mientras el cliente es reparado; el usuario no será incomodado porque sus datos no están en el cliente. Página 119

Operable en ambientes hostiles. La mayoría de los clientes livianos no tienen piezas móviles así que pueden ser usados en ambientes polvorientos sin la preocupación que puede haber con la obstrucción de los ventiladores de los PC que pueden recalentarlos y quemarlos. Menos ancho de banda de la red. Puesto que los servidores de terminales típicamente residen en la misma espina dorsal de red (backbone network) de alta velocidad que los servidores de archivo, la mayor parte del tráfico de red está confinado al cuarto del servidor. Uso más eficiente de los recursos de computación. Un típico cliente pesado será especificado para hacer frente a la carga máxima de las necesidades del usuario, lo que puede ser ineficiente en los momentos en que no es usado. En contraste, los clientes ligeros usan solamente la cantidad exacta de recursos de computación requeridos para la tarea actual. En una red grande, hay una alta probabilidad que la carga de cada usuario fluctuará en un ciclo diferente a la de otro usuario, es decir, los picos de uno corresponderán muy probablemente a los bajos de uso de otro. Simple trayectoria de actualización de hardware. Si el pico de recursos está sobre un límite predefinido, es un proceso relativamente simple agregar otro componente a un rack de servidor (ya sea energía, procesamiento, o almacenamiento), estableciendo los recursos exactamente a la cantidad requerida. Las unidades existentes pueden continuar sirviendo junto a la nueva, mientras que un modelo de cliente pesado requiere que sea reemplazada por una unidad de escritorio completa, Página 120

resultando en tiempo muerto para el usuario, y el problema de disponer de la unidad vieja. Menor ruido. El ya mencionado retiro de ventiladores reduce el ruido producido por la unidad. Esto puede crear un ambiente de trabajo más agradable y más productivo. Menos hardware desperdiciado. El hardware contiene metales pesados y plásticos y requiere energía y recursos para ser construido. Los clientes ligeros pueden permanecer en servicio por más tiempo y producen menos hardware excedente que una equivalente instalación de cliente pesado porque pueden ser hechos sin partes móviles. Los ventiladores y unidades de disco del ordenador (usados para enfriar y el almacenamiento de datos en los clientes pesados) tienen un tiempo medio antes de fallos de muchas miles de horas pero los transistores y los conductores en el cliente ligero tienen tiempos medios antes de fallos de millones de horas. Algunos de los protocolos usados para la comunicación entre clientes livianos y servidores son: X Window System (también conocido como X o X11) usado esencialmente por variantes de Unix. Tecnología NX comprime el protocolo X11 para mejores prestaciones. Página 121

Computación en Red Virtual o VNC. Citrix ICA con MetaFrame. RDP es el protocolo por defecto que incluyen los sistemas Windows para acceder remotamente al escritorio. A continuación se representa gráficamente la arquitectura clienteservidor, donde a la izquierda aparecen los clientes, conectados con el servidor, que contiene las bases datos, a través de una red local: Página 122

4.1.2 Lenguajes de programación para los clientes En este apartado se estudian las diferentes alternativas de lenguajes de programación que se podrían utilizar en los módulos de mesa como en el módulo de cocina. Posteriormente, una vez realizado el estudio, se elegirá la alternativa que se adecúe mejor al sistema. 4.1.2.1 Lenguaje C C es un lenguaje de programación creado en 1972 por Dennis M. Ritchie en los Laboratorios Bell como evolución del anterior lenguaje B, a su vez basado en BCPL. Al igual que B, es un lenguaje orientado a la implementación de Sistemas Operativos, concretamente Unix. C es apreciado por la eficiencia del código que produce y es el lenguaje de programación más popular para crear software de sistemas, aunque también se utiliza para crear aplicaciones. Se trata de un lenguaje débilmente tipificado de medio nivel pero con muchas características de bajo nivel. Dispone de las estructuras típicas de los lenguajes de alto nivel pero, a su vez, dispone de construcciones del lenguaje que permiten un control a muy bajo nivel. Los compiladores suelen ofrecer extensiones al lenguaje que posibilitan Página 123

mezclar código en ensamblador con código C o acceder directamente a memoria o dispositivos periféricos. Hecho principalmente para la fluidez de programación en sistemas UNIX. Se usa también para el desarrollo de otros sistemas operativos como Windows o Linux. Igualmente para aplicaciones de escritorio como OpenOffice.org, cuyo principal lenguaje de programación es C. De la misma forma, es muy usado en aplicaciones científicas (para experimentos informáticos, físicos, químicos, matemáticos, entre otros, parte de ellos conocidos como modelos y simuladores), industriales (industria robótica, cibernética, sistemas de información y base de datos para la industria petrolera y petroquímica). Predominan también todo lo que se refiere a simulación de máquinas de manufactura, simulaciones de vuelo (es la más delicada, ya que se tienen que usar demasiados recursos tanto de hardware como de software para desarrollar aplicaciones que permitan simular el vuelo real de una aeronave). Se aplica por tanto, en diversas áreas desconocidas por gran parte de los usuarios noveles. Algunas de las ventajas del lenguaje C son: Lenguaje muy eficiente puesto que es posible utilizar sus características de bajo nivel para realizar implementaciones óptimas. Página 124

A pesar de su bajo nivel es el lenguaje más portado en existencia, habiendo compiladores para casi todos los sistemas conocidos. Proporciona facilidades para realizar programas modulares y/o utilizar código o bibliotecas existentes. Sin embargo, como inconvenientes se encuentran: Existe una gran diferencia en velocidad de desarrollo: es mucho más lento programar en C. La razón estriba en que el compilador de C se limita a traducir código sin apenas añadir nada. La gestión de la memoria es un ejemplo clásico: en C el programador ha de reservar y liberar la memoria explícitamente. En otros lenguajes (como BASIC, Matlab o C#) la memoria es gestionada de forma transparente para el programador. Esto alivia la carga de trabajo humano y en muchas ocasiones previene errores. El mantenimiento es difícil y costoso que con lenguajes de más alto nivel. El código en C se presta a sentencias cortas y enrevesadas de difícil interpretación. Aunque el lenguaje admite código escrito de forma fácilmente legible, si no se siguen normas en el equipo de programación algunos programadores pueden acabar escribiendo código difícil de leer. Esto complica la revisión y el mantenimiento. C no dispone de sistemas de control automáticos y la seguridad depende casi exclusivamente de la experiencia del programador. La mayor parte de los problemas de seguridad en los sistemas informáticos actuales deriva de haber sido realizados en C. El fallo de seguridad clásico consiste en que algunas entradas de Página 125

información al programa no se comprueban en longitud. Si un atacante introduce datos lo bastante grandes puede provocar la sobreescritura de código en la pila del programa e incluso llegar a forzar la ejecución de código pernicioso. Los lenguajes de tipo dinámico cuentan con controles de gestión de memoria y de entrada de datos automáticos. Página 126

4.1.2.2 Java Java es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de punteros o memoria. Las aplicaciones Java están típicamente compiladas en un bytecode, aunque la compilación en código máquina nativo también es posible. En el tiempo de ejecución, el bytecode es normalmente interpretado o compilado a código nativo para la ejecución, aunque la ejecución directa por hardware del bytecode por un procesador Java también es posible. La implementación original y de referencia del compilador, la máquina virtual y las bibliotecas de clases de Java fueron desarrolladas por Sun Microsystems en 1995. Desde entonces, Sun ha controlado las especificaciones, el desarrollo y evolución del lenguaje a través del Java Community Process, si bien otros han desarrollado también implementaciones alternativas de estas tecnologías de Sun, algunas incluso bajo licencias de software libre. Entre noviembre de 2006 y mayo de 2007, Sun Microsystems liberó la mayor parte de sus tecnologías Java bajo la licencia GNU GPL, de acuerdo con las especificaciones del Java Community Process, de tal forma que prácticamente todo el Java de Sun es ahora software Página 127

libre (aunque la biblioteca de clases de Sun que se requiere para ejecutar los programas Java aún no lo es). El lenguaje Java se creó con cinco objetivos principales: 1. Debería usar la metodología de la programación orientada a objetos. 2. Debería permitir la ejecución de un mismo programa en múltiples sistemas operativos. 3. Debería incluir por defecto soporte para trabajo en red. 4. Debería diseñarse para ejecutar código en sistemas remotos de forma segura. 5. Debería ser fácil de usar y tomar lo mejor de otros lenguajes orientados a objetos, como C++. Las ventajas fundamentales de Java, son: Los programas solo se escriben una vez. No hace falta escribir el programa otra vez para ejecutarlo en otra máquina. Página 128

Java es un lenguaje orientado a objetos. Por tanto todas las ventajas que ofrece esta técnica las contiene Java. Los browser compatibles con Java no necesitan la instalación de plug-ins adicionales. Los inconvenientes más importantes de Java, son: Los programas son lentos. Java, al ser un lenguaje interpretado nunca será tan rápido como un programa ejecutable. Para la gente que no conoce Java deberá de estudiar el lenguaje para sacarle todo el partido. Aunque lleva varios años desde su origen, su optimización no es tan grande como la de otros lenguajes que llevan más años. Desde la creación de la especificación J2ME (Java 2 Platform, Micro Edition), una versión del entorno de ejecución Java reducido y altamente optimizado, especialmente desarrollado para el mercado de dispositivos electrónicos de consumo se ha producido toda una revolución en lo que a la extensión de Java se refiere. Es posible encontrar microprocesadores específicamente diseñados para ejecutar bytecode Java y software Java para tarjetas inteligentes (JavaCard), teléfonos móviles, buscapersonas, set-top-boxes, sintonizadores de TV y otros pequeños electrodomésticos. Página 129

Hoy en día existen multitud de aplicaciones gráficas de usuario basadas en Java. El entorno de ejecución Java (JRE) se ha convertido en un componente habitual en los PC de usuario de los sistemas operativos más usados en el mundo. Además, muchas aplicaciones Java lo incluyen dentro del propio paquete de la aplicación de modo que se ejecuten en cualquier PC. Página 130

4.1.2.3 Microsoft Visual Basic Visual Basic es un lenguaje de programación desarrollado para Microsoft. Visual Basic constituye un IDE (entorno de desarrollo integrado o en inglés Integrated Development Enviroment) que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código (programa donde se escribe el código fuente), un depurador (programa que corrige errores en el código fuente para que pueda ser bien compilado), un compilador (programa que traduce el código fuente a lenguaje de máquina), y un constructor de interfaz gráfica o GUI (es una forma de programar en la que no es necesario escribir el código para la parte gráfica del programa, sino que se puede hacer de forma visual). Las versiones de Visual Basic para Windows son muy conocidas, pero existe una versión de Microsoft Visual Basic 1.0 para MS- DOS (ediciones Profesional y Estándar) menos difundida y que data de 1992. Era un entorno que, aunque en modo texto, incluía un diseñador de formularios en el que se podían arrastrar y soltar distintos controles. La versión 6.0 continúa utilizándose masivamente y es casi compatible prácticamente al 100% con las últimas versiones de Windows como Vista y Windows 7. Las versiones actuales de Visual Basic se basan en la plataforma.net, que se desligan de las anteriores versiones. Página 131

Cabe mencionar que aunque menos conocido, existió también una versión gratuita de Visual Basic 5.0 dedicada en su práctica al desarrollo de controles y componentes, su nombre en concreto era Microsoft Visual Basic 5.0 Control Creation Edition (Visual Basic 5 CCE). Las ventajas principales del lenguaje Visual Basic son las siguientes: Es un lenguaje RAD. Posee una curva de aprendizaje muy rápida. Se integra el diseño e implementación de formularios de Windows. Se permite usar con suma facilidad la plataforma de los sistemas Windows. El código en Visual Basic es fácilmente migrable a otros lenguajes. Como inconvenientes se encuentran: Sin soporte de Microsoft desde el 4 de abril de 2008. No es multiplataforma. Página 132

Por defecto se permite la programación sin declaración de variables (que puede ser sencillamente corregida escribiendo la frase Option Explicit en el encabezado de cada formulario). No se permite programación a bajo nivel ni incrustar secciones de código en ASM. Sólo se permite el uso de funciones de librerías dinámicas (DLL) stdcall. Algunas funciones están indocumentadas. Es un lenguaje basado en objetos y no orientado a objetos. No se maneja muy bien los apuntadores de memoria. No se soporta tratamiento de procesos como parte del lenguaje. No se incluye operadores de desplazamiento de bits como parte del lenguaje. No se permite el manejo de memoria dinámica, punteros, etc. como parte del lenguaje. No se avisa de ciertos errores o advertencias (se puede configurar el compilador para generar ejecutables sin los controladores de desbordamiento de enteros o las comprobaciones de límites en matrices entre otros, dejando así más de la mano del programador la tarea de controlar dichos errores) No se tiene instrucciones de preprocesamiento. Página 133

El tratamiento de mensajes de Windows es básico e indirecto. La gran gama de controles incorporados son, sin embargo en algunos casos, muy generales, lo que lleva a tener que reprogramar nuevos controles para una necesidad concreta de la aplicación. Esto cambia radicalmente en Visual Basic.NET donde es posible reprogramar y mejorar o reutilizar los controles existentes. Los controles personalizados no mejoran la potencia de la API de Windows, y en determinados casos acudir a ésta será el único modo de conseguir el control personalizado deseado. Página 134

4.1.3 Lenguajes de programación para el servidor En este apartado se estudian las diferentes alternativas de lenguajes de programación que se podría utilizar en el servidor. Posteriormente, una vez realizado el estudio, se elegirá la alternativa que se adecúe mejor al sistema. 4.1.3.1 Active Server Pages Active Server Pages (ASP) es una tecnología de Microsoft del tipo "lado del servidor" para páginas web generadas dinámicamente, que se ha comercializado como un anexo a Internet Information Services. La tecnología ASP está estrechamente relacionada con el modelo tecnológico de su fabricante. Intenta ser solución para un modelo de programación rápida ya que programar en ASP es como programar en Visual Basic, por supuesto con muchas limitaciones. Lo interesante de este modelo tecnológico es poder utilizar diversos componentes ya desarrollados como algunos controles ActiveX así como componentes del lado del servidor, tales como CDONTS, por ejemplo, que permite la interacción de los scripts con el servidor SMTP que integra IIS. Página 135

Se facilita la programación de sitios web mediante varios objetos integrados, como por ejemplo un objeto de sesión basada en cookies, que mantiene las variables mientras se pasa de página a página. Página 136

4.1.3.2 PHP PHP es un acrónimo recursivo que significa PHP Hypertext Preprocessor (inicialmente PHP Tools, o, Personal Home Page Tools). Es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Es usado principalmente en interpretación del lado del servidor (server-side scripting) pero actualmente puede ser utilizado desde una interfaz de línea de comandos o en la creación de otros tipos de programas incluyendo aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+. Algunas ventajas que presenta PHP son: Es un lenguaje multiplataforma. Completamente orientado a la web. Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL. Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones). Página 137

Posee una amplia documentación en su página oficial, entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda. Es libre, por lo que se presenta como una alternativa de fácil acceso para todos. Se permite usar las técnicas de Programación Orientada a Objetos. No se requiere definición de tipos de variables aunque sus variables se pueden evaluar también por el tipo que estén manejando en tiempo de ejecución. Manejo de excepciones (desde PHP5). Si bien en PHP no se obliga a quien lo usa a seguir una determinada metodología a la hora de programar (muchos otros lenguajes tampoco lo hacen), aun estando dirigido a alguna en particular, el programador puede aplicar en su trabajo cualquier técnica de programación y/o desarrollo que le permita escribir código ordenado, estructurado y manejable. Un ejemplo de ésto son los desarrollos que en PHP se han hecho del patrón de diseño Modelo Vista Controlador (o MVC), que permiten separar el tratamiento y acceso a los datos, la lógica de control y la interfaz de usuario en tres componentes independientes. Página 138

Como desventajas se encuentra: La ofuscación de código es la única forma de ocultar los fuentes Página 139

4.1.3.3 Java Server Pages JavaServer Pages (JSP) es una tecnología Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo. Esta tecnología es un desarrollo de la compañía Sun Microsystems. La Especificación JSP 1.2 fue la primera que se liberó y en la actualidad está disponible la especificación JSP 2.1. En JSP's se permite la utilización de código Java mediante scripts. Además, es posible utilizar algunas acciones JSP predefinidas mediante etiquetas. Estas etiquetas pueden ser enriquecidas mediante la utilización de Librerías de Etiquetas (TagLibs o Tag Libraries) externas e incluso personalizadas. JSP puede considerarse como una manera alternativa, y simplificada, de construir servlets. Es por ello que una página JSP puede hacer todo lo que un servlet puede hacer, y viceversa. Cada versión de la especificación de JSP está fuertemente vinculada a una versión en particular de la especificación de servlets. Página 140

El funcionamiento general de la tecnología JSP es que el Servidor de Aplicaciones interpreta el código contenido en la página JSP para construir el código Java del servlet a generar. Este servlet será el que genere el documento (típicamente HTML) que se presentará en la pantalla del navegador del usuario. El rendimiento de una página JSP es el mismo que tendría el servidor equivalente, ya que el código es compilado como cualquier otra clase Java. A su vez, la máquina virtual compilará dinámicamente a código de máquina las partes de la aplicación que lo requieran. Esto hace que JSP tenga un buen desempeño y sea más eficiente que otras tecnologías web que ejecutan el código de una manera puramente interpretada. Como ventajas principales cabe destacar: El lenguaje Java es un lenguaje de propósito general que excede el mundo web y que es apto para crear clases que manejen lógica de negocio y acceso a datos de una manera prolija. Esto permite separar en niveles las aplicaciones web, dejando la parte encargada de generar el documento HTML en el archivo JSP. JSP hereda la portabilidad de Java, y es posible ejecutar las aplicaciones en múltiples plataformas sin cambios. Es común incluso que los desarrolladores trabajen en una plataforma y que la aplicación termine siendo ejecutada en otra. Página 141

Como inconvenientes, se encuentran los ya comentados anteriormente en referencia al lenguaje de programación java. Página 142

4.1.4 Sistemas Gestor de Bases de Datos En este apartado se estudian las diferentes alternativas de sistemas gestores de bases de datos que se podrían utilizar para implantar el sistema, y posteriormente, se elegirá una como solución. 4.1.4.1 Oracle Oracle es un sistema de gestión de base de datos relacional (o RDBMS por el acrónimo en inglés de Relational Data Base Management System), desarrollado por Oracle Corporation. Se considera a Oracle como uno de los sistemas de bases de datos más completos, tiene como características principales: Soporte de transacciones. Estabilidad. Escalabilidad. Soporte multiplataforma. Página 143

Ha sido criticada por algunos especialistas la seguridad de la plataforma, y las políticas de suministro de parches de seguridad. Aunque su dominio en el mercado de servidores empresariales ha sido casi total hasta hace poco, recientemente sufre la competencia de Microsoft SQL Server de Microsoft y de la oferta de otros RDBMS con licencia libre como PostgreSQL,MySQL o Firebird. 4.1.4.2 SQL Server Microsoft SQL Server es un sistema de gestión de bases de datos relacionales (SGBD) basado en el lenguaje Transact-SQL, y específicamente en Sybase IQ, capaz de poner a disposición de muchos usuarios grandes cantidades de datos de manera simultánea, así como de disponer de las siguientes ventajas: Soporte de transacciones. Escalabilidad, estabilidad y seguridad. Soporta procedimientos almacenados. Incluye también un potente entorno gráfico de administración, que permite el uso de comandos DDL y DML gráficamente. Página 144

Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el servidor y los terminales o clientes de la red sólo acceden a la información. Además permite administrar información de otros servidores de datos. Página 145

4.1.4.3 MySQL MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones. MySQL se desarrolla como software libre en un esquema de licenciamiento dual. 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 se debe comprar a la empresa una licencia específica que les permita este uso. MySQL es muy utilizado en aplicaciones web y en plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python). Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones. Página 146

4.1.5 Sistemas operativos En este apartado se estudian las diferentes alternativas de sistemas operativos que se podrían utilizar para implantar en el servidor, y posteriormente, se elegirá uno como solución. 4.1.5.1 Windows Server 2008 R2 Windows Server 2008 es el nombre de un sistema operativo diseñado para servidores de Microsoft. Es el sucesor de Windows Server 2003, distribuido al público casi cinco años antes. Al igual que Windows Vista, Windows Server 2008 se basa en el núcleo Windows NT6.0. Posteriormente se lanzó una segunda versión, denominada Windows Server 2008 R2. Fue conocido como Windows Server "Longhorn" hasta el 16 de mayo de 2007, cuando Bill Gates, presidente de Microsoft, anunció su título oficial (Windows Server 2008) durante su discurso de apertura en WinHEC. El Windows Aero, está deshabilitado y usa la interfaz clásica de versiones anteriores de Windows. La beta 1 fue lanzada el 27 de julio de 2005. La beta 2 fue anunciada y lanzada el 23 de mayo de 2006 en WinHEC 2006 y la beta 3 fue lanzada al público el 25 de abril de 2007. Su lanzamiento fue el 27 de febrero de 2008. Página 147

Hay algunas diferencias (unas sutiles y otras no tanto) con respecto a la arquitectura del nuevo Windows Server 2008, que pueden cambiar drásticamente la manera en que se usa este sistema operativo. Estos cambios afectan a la manera en que se gestiona el sistema hasta el punto de que se puede llegar a controlar el hardware de forma más efectiva, se puede controlar mucho mejor de forma remota y cambiar de forma radical la política de seguridad. Entre las mejoras que se incluyen, están: Nuevo proceso de reparación de sistemas NTFS: proceso en segundo plano que repara los archivos dañados. Creación de sesiones de usuario en paralelo: reduce tiempos de espera en los Terminal Services y en la creación de sesiones de usuario a gran escala. Cierre limpio de Servicios. Sistema de archivos SMB2: de 30 a 40 veces más rápido el acceso a los servidores multimedia. Address Space Load Randomization (ASLR): protección contra malware en la carga de controladores en memoria. Server Core: el núcleo del sistema se ha renovado con muchas y nuevas mejoras. Página 148

4.1.5.2 Mandriva Linux Mandriva Linux es una distribución Linux destinada tanto para principiantes como para usuarios experimentados, que ofrece un sistema operativo orientado a computadoras personales y también para servidores con un enfoque a los usuarios que se están introduciendo al mundo de Linux y al software libre además por tener una amplia gama y comunidad de desarrolladores, es adecuada para todo tipo de variedad de necesidades: estaciones de trabajo, creación de clústeres, servidores, firewalls, etc. Es una de las distribuciones de Linux referentes a nivel mundial. Como características principales, se encuentran: Internacionalización: disponible en 74 idiomas. Instalación control y administración: el instalador de Mandriva Linux es uno de los más amigables de entre las diferentes distribuciones de Linux, cabe destacar que Mandrake (ahora Mandriva) fue la primera distribución en incluir un instalador gráfico. En su primera versión el instalador presentó algunos problemas con la resolución de dependencias, cosa que ya está solucionada. Paquetes de software abundantes: viene con aproximadamente 205609 paquetes de software incluyendo juegos, programas de oficina, multimedia, gráficos, servidores y utilidades de Internet. Página 149

4.1.5.3 Solaris 10 Solaris es un sistema operativo de tipo Unix desarrollado desde 1992 inicialmente por Sun Microsystems y actualmente por Oracle Corporation como sucesor de SunOS. Es un sistema certificado oficialmente como versión de Unix. Funciona en arquitecturas SPARC y x86 para servidores y estaciones de trabajo. Si bien Solaris en un ordenador personal apenas necesita mantenimiento profesional, utilizado en una empresa es posible que el empresario quiera contratar los servicios del equipo de Sun para hacer rendir al máximo su negocio, exprimiendo todas las novedades en seguridad de redes y muchas más cosas. Sun fabrica hardware libre, como lo es la tecnología SPARC. Solaris 10 es la versión más reciente del sistema operativo desarrollado por Sun Microsystems. Solaris es en sí software propietario y ahora la parte principal del sistema operativo se ha liberado como un proyecto de software libre denominado OpenSolaris. Esto es novedad para Sun, pues todas las versiones anteriores eran cerradas. Plantearon distribuir su producto bajo la licencia CDDL Common development and distribution license. Página 150

4.2 Evaluación de las alternativas La evaluación de las alternativas se realiza en base a aspectos de interés que se consideran fundamentales para el buen funcionamiento de la aplicación. No sólo de valoran características relacionadas con el rendimiento, sino también con el coste, la rapidez con la que se resuelven agujeros de seguridad, posibilidad de añadir nueva funcionalidad, etc. 4.2.1 Evaluación de la arquitectura Al tratarse de una aplicación que deben de usar múltiples clientes queda claro que la mejor arquitectura es la basada en cliente / servidor. Dentro de este esquema se han expuesto dos configuraciones; una con un cliente ligero y otra con un cliente pesado. Para evaluar las arquitecturas, se estudian las ventajas e inconvenientes, posteriormente se seleccionará las más adecuada. Las ventajas del cliente pesado son: La carga de proceso se realiza en el equipo del usuario pudiendo el servidor escalar con mayor facilidad para dar servicio a más usuarios. Menor coste del equipo servidor. Página 151

Las desventajas del cliente pesado son: Dificultad a la hora de actualizar los equipos clientes. Posible fuente de problemas al existir diferente configuración en cada ordenador. Necesidad de crear un cliente para cada plataforma (Windows, Mac, Linux, etc.) Mientas que las ventajas de utilizar un cliente ligero son: El software cliente se encuentra centralizado en un solo punto por lo que distribuir las actualizaciones es mucho sencillo. Se eliminan los problemas de compatibilidad de software entre plataformas ya que se utiliza un navegador web. El tiempo de proceso del cliente se puede invertir en otras aplicaciones que tenga instaladas en su ordenador. Y como desventajas de los clientes ligeros cabe destacar: Página 152

Es necesario una máquina más potente que las demás en el servidor. Si el servidor falla, ningún cliente podrá acceder a la aplicación. Esto se resuelve con una buena planificación y la redundancia de sistemas. Página 153

4.2.2 Evaluación del sistema operativo A la hora de evaluar el sistema operativo elegido hay que tener en cuenta las consecuencias de dicha decisión ya que se da el caso de que determinado software funciona mejor en un sistema operativo que en otro o simplemente es incompatible. De las diferentes alternativas presentadas se ha evaluado coste, posibilidad de ampliación de funcionalidades, integración con otros sistemas, y frecuencia con la que se detectan vulnerabilidades. Windows server Mandriva Linux Solaris 10 2008 Coste Alto Bajo Medio Ampliación de funcionalidades Medio Alta Medio Integración Alta Alta Alta Frecuencia de vulnerabilidades Media Baja Baja Complejidad de uso Bajo Medio Medio Página 154

4.2.3 Evaluación del lenguaje de programación en el cliente Para determinar el mejor lenguaje de programación en el lado del cliente se deben examinar a fondo los requerimientos que va a necesitar la aplicación. Visual Basic es un lenguaje muy fácil de aprender sin embargo sólo funciona en plataformas Windows. Java es más complicado de aprender y requiere mucho trabajo para desarrollar elementos gráficos, sin embargo destaca su extraordinaria portabilidad. Esta característica permite que un programa escrito en Java pueda ser ejecutado en diferentes plataformas. Se analiza el coste, la posibilidad de ampliar funcionalidades, el número de expertos que conocen este lenguaje en caso de un futuro mantenimiento, y el potencial de uso, que mejor permita adaptarse al sistema requerido. Página 155

Java VisualBasic C Coste Gratuito 100 licencia estudiante Gratuito Ampliación de funcionalidades Alto Bajo Bajo Expertos que conocen el lenguaje Alto Medio Alto Potencial de uso Alto Medio Medio Página 156

4.2.4 Evaluación del lenguaje de programación en el servidor Para la elección de una arquitectura basada en cliente servidor, será necesario determinar el lenguaje de programación del lado del servidor más adecuado para la aplicación. Se usan los mismos criterios de evaluación que para los lenguajes de programación del lado cliente. JSP ASP PHP Coste Gratuito Gratuito Gratuito Ampliación de funcionalidades Alto Bajo Bajo Expertos que conocen el lenguaje Alto Medio Alto Potencial de uso Alto Medio Medio Página 157

4.2.5 Evaluación del sistema gestor de bases de datos Independientemente de la arquitectura elegida, esta aplicación deberá guardar los datos de los distintos usuarios. Para determinar cuál es el gestor de base de datos más idóneo se utilizarán los siguientes criterios: coste, soporte de transacciones, soporte técnico y concurrencia. Cabe destacar que MySQL tiene un soporte técnico calificado como bajo ya que debe ser contratado aparte, y respecto a la concurrencia, en SQL Server es medio ya que el rendimiento desciende al aumentarlos usuarios conectados, en Oracle alto al usarse actualmente en aplicaciones críticas, y en MySQL medio ya que necesita de una máquina potente. SQL Server Oracle MySQL Coste Alto Alto Gratuito Soporte de transacciones Medio Alto Medio Soporte técnico Alto Alto Bajo Concurrencia Medio Alto Medio Página 158

4.3 Selección de la alternativa Después de analizar las distintas opciones se selecciona la alternativa basada en una arquitectura de cliente/servidor con un cliente ligero, ya que será más fácil de centralizar la información y es la arquitectura más adecuada cuando serán varios los clientes que realicen transacciones a la vez. Respecto al servidor web, se ha seleccionado únicamente Apache Tomcat, debido a su amplia difusión en la comunidad y su carácter gratuito. Se trata de un servidor http multiplataforma de código abierto con un nivel de seguridad aceptable, se usará principalmente para cargar los vídeos e imágenes que cada restaurante quiera mostrar a sus clientes. El sistema operativo seleccionado será Windows, para tener el acceso a la información de forma centralizada, sencillez y familiaridad con este sistema. El lenguaje de programación tanto en el cliente como en el servidor, será Java J2EE, debido a su gratuidad, simplicidad, su orientación a objetos, carácter distribuido e interpretado, robustez, arquitectura neutral, seguridad, portabilidad y posibilidad de ejecución multihilo. Como sistema gestor de bases de datos, el más adecuado para el sistema será MySQL, debido a su coste gratuito, escalabilidad y flexibilidad (maneja bases de datos empotradas ocupando sólo 1MB, y Página 159

es soportado en UNIX, Linux y Windows), alto rendimiento, disponibilidad, facilidad de gestión y fuerte protección de datos. Página 160

5) Diseño externo

5. DISEÑO EXTERNO En esta etapa del proyecto se va a realizar la secuencia de actividades que en la metodología en cascada se recoge bajo el nombre de diseño externo. Por tanto, se van a tratar diferentes aspectos como las fronteras de mecanización, especificación de procesos, entradas y salidas, etc. 5.1 Entorno operativo A continuación se procede a representar de forma simplificada el funcionamiento general del sistema: Menú virtual, sugerencias, Usuarios clientes factura... Comandas Sistema Integral de Gestión de Restaurantes Usuarios en cocina Consulta facturación, edición del menú, inserción de publicidad... Página 162

5.2 Fronteras de mecanización Teniendo en cuenta los estudios realizados previamente, se decide mecanizar todas aquellas funciones que aparecen en el DFD del nuevo sistema, ya que una ampliación de esas excedería los límites del proyecto. 5.3 Especificación de procesos En este apartado, se estudian los procesos que componen la aplicación. A continuación, se muestra un esquema general de la aplicación, tanto en su parte pública como privada. Para la elaboración de este apartado se han seguido consejos de los libros [WESL99] y [LARM03]. Se representa en el diagrama a continuación los procesos que pueden ejecutar los clientes, y los procesos que ejecutan los empleados, incluyendo el gerente del restaurante, trabajadores en la cocina... Por un lado existe un menú público, que todos los clientes podrán ver, que incluye la carta virtual con sus sugerencias y la función de realizar comandas. Por otro lado, existe un menú privado, al que sólo tendrá acceso el personal del restaurante mediante un login, que incluye la posibilidad de editar el menú que se muestra a los clientes, la función de inserción de publicidad o sugerencias, la visualización de las comandas que los Página 163

clientes realizan y la función de muestra de informes sobre la facturación del restaurante. Todas estas funciones, se representan en el siguiente esquema: Inicio Edición de comandas Menú público Administración Menú privado Ver carta Realizar comanda Publicidad Informes Como se puede comprobar, la pantalla de administración permite un acceso personalizado a la aplicación privada. En función del puesto se permite un acceso a los siguientes módulos de la aplicación. Página 164

Gerente Personal de Personal de Clientes salón cocina Ver carta virtual Realizar comanda Edición de comandas Publicidad y sugerencias Informes Se han especificado en este apartado los grandes módulos que descomponen la aplicación, y los accesos a los distintos módulos según el usuario que se conecte al sistema. Página 165

5.4 Diseño de interfaces En este apartado se recogen los interfaces de que constará la aplicación. Se realiza un análisis detallado de todas las pantallas, con sus funcionalidades completas. Cabe destacar que el diseño de la aplicación se ha hecho para una interfaz táctil y es por eso que los botones son más grandes de lo habitual. 5.4.1 Interfaz login Esta es la primera pantalla a la que acceden los empleados o el gerente en la aplicación. Los clientes, no ven esta pantalla, ya que no tienen que realizar ningún login. Según los permisos de los que dispongan los empleados, podrán acceder a unas funciones u otras, pero siempre es necesario realizar una identificación mediante usuario y contraseña. Página 166

5.4.2 Menú privado Una vez que se ha accedido como empleado, se podrá tener acceso a unos módulos u otros en función de si se trata del gerente del restaurante, o del resto del personal. 5.4.2.1 Menú privado del gerente El gerente, que tendrá su propio nombre de usuario y contraseña que le diferencie del resto de personal, podrá tener acceso a cuatro módulos distintos: comandas, publicidad, carta virtual e informes. Página 167

5.4.2.2 Menú privado de empleados En este caso, se muestra el menú al que tienen acceso el resto de empleados que no son gerentes, que poseen otros permisos. Esta es la visión del módulo de cocina, que se arranca al principio de la actividad del restaurante para poder visualizar las comandas que llegan de los clientes. Página 168

5.4.2.3 Menú privado introducir sugerencias A continuación se muestra la apariencia del menú privado introducir sugerencias al que sólo puede acceder el chef o el gerente del restaurante. Las sugerencias que introduzca aquí, se guardarán en la base de datos, y posteriormente se mostrará en el menú virtual a los clientes. El número de sugerencia coincidirá con el número de plato al que se le aplica. Página 169

5.4.2.4 Menú privado visualizar comandas A continuación se muestra el aspecto del módulo de cocina. Los empleados ven las comandas que envían los clientes y su detalle en los distintos apartados. Al pulsar sobre ellas pueden editarlas, y marcarlas como atendidas, desapareciendo así de la lista de tareas pendientes. Página 170

5.4.2.5 Menú privado editar carta virtual Este es el menú que aparece para el gerente o el chef en el módulo de cocina, si desean modificar la información que se mostrará a los clientes, de uno de los platos de la carta. Se puede eliminar directamente de la base de datos introduciendo el número de plato, o bien se puede editar la información sobre los ingredientes, descripción y precio y además se puede añadir opcionalmente la url del vídeo o imagen que se mostrará a los clientes sobre su preparación detallada. Página 171

5.4.2.6 Menú privado acceder a informes En este apartado se muestra el menú al que tiene acceso el gerente del restaurante, en el cual se puede imprimir por pantalla informes sobre la facturación del restaurante, o sobre los platos más vendidos. Y a continuación el informe sobre los platos ordenados de ascendente según el número de ventas: Página 172

5.4.3 Menú público En este caso se representa el menú que visualizarán los clientes en el módulo de mesa, se presenta primeramente una ventana de bienvenida, y a continuación la carta completa con la posibilidad de acceder, en cada plato, a información más detallada con imágenes o vídeos. 5.4.3.1 Pantalla de bienvenida Este es el aspecto de la pantalla de bienvenida que encontrarán los clientes en su módulo de mesa. Página 173

5.4.3.2 Carta virtual En la siguiente imagen se muestra un fragmento de la carta virtual que ofrece el restaurante a sus clientes, si se desea acceder a información más detallada se muestra una segunda ventana con vídeos o imágenes. Página 174

5.4.3.3 Información detallada La siguiente figura muestra la información detallada a la que pueden acceder los clientes, a través del menú virtual, al pulsar sobre el botón más información al lado de cada plato en el menú. Se puede ver una descripción más extensa sobre el plato, una imagen de su aspecto, o un vídeo de su preparación. Página 175

5.5 Procesos de seguridad El sistema cuenta con las medidas de seguridad que garantizan la autenticación de los usuarios, la autorización en los procesos de consulta y modificación de la información así como su integridad. Se debe asegurar que los datos de la empresa sean utilizados por aquellos a los que van dirigidos. Para ello se ha diseñado el proceso de login, que permite un acceso personalizado a la aplicación a partir de un nombre de usuario y password. Según el tipo de empleado que acceda, tendrá permiso para acceder a una información u otra, mientras que los clientes, solo tendrán acceso a la carta virtual y a realizar las comandas. Página 176

6) Diseño interno

6. DISEÑO INTERNO En la fase de Diseño Interno, se realiza una última caracterización de la aplicación, antes de iniciar la fase de Programación. Para ello, se debe centrar el trabajo en los dos elementos fundamentales del sistema informático a desarrollar: Procesos y entidades. Para ello se estudia en este apartado, un diseño interno de los procesos a través de diagramas HIPO y STC y posteriormente el estudio de las tablas que componen la base de datos. Para la elaboración de este capítulo se ha empleado la referencia bibliográfica [ESQU08]. 6.1 Diseño interno de programas A continuación se representan los diagramas HIPO de los diferentes procesos. Página 178

6.1.1 Diagrama HIPO Administración de empleados A continuación se representa el diagrama HIPO del login de empleados. ID_EMP PASS EMPLEADOS LOGIN ACCESO/NO ACCESO Como se puede observar, se valida el usuario y la password para ver si coinciden con los almacenados en la tabla de empleados. En caso afirmativo, se permitirá el acceso a la aplicación; en caso contrario, se denegará. Página 179

6.1.2 Diagrama HIPO Alta comanda A continuación se muestra el diagrama HIPO que permite dar de alta una comanda en la base de datos de facturas el sistema. COMANDAS MENU SUGERENCIAS SELECCIÓN SELECCIÓN SELECCIÓN COMANDAS- SELECCIÓN MENÚ- SELECCIÓN SUGERENCIAS- SELECCIÓN Total Salida GUARDAR FACTURAS Página 180

6.1.3 Diagrama STC Administración de empleados Como se puede observar en el siguiente diagrama, el proceso de login requiere la introducción de nombre de usuario y password, con sus respectivas comprobaciones. password error ADMINISTRACIÓN id_emp id_emp password error error error id_emp CAPTAR DATOS id_emp VERIFICAR DATOS error RESPUESTA id_emp INTRODUCIR NOMBRE DE USUARIO INTRODUCIR PASSWORD ACCESO AUTORIZADO ACCESO DENEGADO id_emp id_emp error ENTRADA VALIDAR Página 181

6.2 Modelo físico de la base de datos En las siguientes tablas se representa el diseño interno de la base de datos. TABLA Atributos Tipo Facturas ID_CLI INTEGER TOTAL DOUBLE FECHA DATE HORA DATE La tabla facturas, guarda información sobre todas las comandas atendidas y el precio total cobrado, junto con su fecha y hora. Página 182

TABLA Atributos Tipo Comandas ID_CLI INTEGER MESA INTEGER FECHA DATE HORA DATE ID_PLATO CANT INTEGER INTEGER La tabla comandas guarda información sobre las comandas realizadas por cada cliente, con su mesa, fecha y hora, plato pedido y cantidad. Página 183

TABLA Atributos Tipo Menú ID_PLATO INGRED INTEGER VARCHAR(20) DESC VARCHAR(150) URL VARCHAR(50) PRECIO_UNIT DOUBLE La tabla menú guarda información sobre cada plato que compone el menú que se mostrará a los clientes, incluyendo los ingredientes, una descripción general, una url en caso de que exista un vídeo ilustrativo y su precio unitario. Página 184

TABLA Atributos Tipo Sugerencias ID_PLATO SUGER INTEGER VARCHAR(80) La tabla sugerencias, guarda información sobre las sugerencias que el chef desea ofrecer a sus clientes, asignando esta sugerencia a un plato concreto del menú. Está información será cambiante. Página 185

7) Pruebas

7. PRUEBAS Una vez desarrollados y probados cada uno de los componentes integrantes de la aplicación, deben realizarse una serie de pruebas unitarias para integrar todo el sistema. Así, el objetivo global de esta fase es someter al sistema desarrollado y sus componentes, a una serie de verificaciones encaminadas a garantizar un nivel de fiabilidad aceptable. Esta fase es crítica y debe por tanto, ser planificada, diseñada y realizada con el mismo rigor y control con el que se realiza el desarrollo del sistema. Si los resultados de las pruebas son satisfactorios, se procederá a la aceptación de las mismas y a la implantación del sistema; en caso contrario, se deberán subsanar las anomalías encontradas. Se realizarán dos tipos de pruebas: Pruebas unitarias, y pruebas de integración. 7.1 Pruebas unitarias Están encaminadas a resolver los problemas de cada una de los procesos por separado. A todos los módulos de la aplicación se les ha pasado la siguiente lista de pruebas unitarias. 5. Mensajes del sistema suficientemente explicativos. 6. Introducción de datos con formato incorrecto. 7. Correcta inserción, modificación y borrado de datos de la BD. Página 187

8. Cumplimiento requisitos del usuario. 9. Funcionalidad de botones correcta. Página 188

7.2 Pruebas de integración Estas pruebas son utilizadas fundamentalmente para comprobar la integración de los módulos ya testados y probados de forma individual. En este sentido, hay dos tipos de pruebas: de navegación y de paso de parámetros. También se ha diseñado una lista para estas pruebas: 1. Navegación correcta por los distintos menús. 2. Correcto paso de parámetros entre funciones. Después del estudio de pruebas de integración en el sistema, el resultado ha sido satisfactorio y se han depurado algunos errores. Página 189

8) Implantación

8. IMPLANTACIÓN Una vez probada la integridad del software del sistema y especificada su instalación y configuración, se debe transferir el software producido en un entorno de desarrollo a uno de producción, para llevar a cabo la explotación del sistema. Para ello, se deberán realizar una implantación física de la aplicación y después proceder con la ejecución de la base de datos. 8.1 Implantación física La implantación física, se debe realizar de acuerdo a las reuniones con el cliente, es decir: La aplicación se situará sobre el nuevo servidor. En un primer paso de la implantación, sólo se accederá a una base de datos de desarrollo, pasando en una fase posterior a acceder a la base de datos de explotación. En las primeras etapas de la implantación se deberán filtrar los accesos a la aplicación a aquellos usuarios que se decida prueben la aplicación. Para ello se deberá configurar el firewall de acceso al servidor. Posteriormente, se procederá con la ejecución de la base de datos. Página 191

9) Conclusiones

9. CONCLUSIONES El éxito de un proyecto informático depende de muchos factores como puede ser, la calidad del equipo de trabajo, una buena planificación, el dinero disponible o el tiempo. Sin embargo, es bien conocido por todos que el éxito de un proyecto en numerosas ocasiones no implica ideas complejas, desarrollo arduo o una gran inversión económica. Un proyecto informático exitoso conlleva siempre un desarrollo bien elaborado del mismo acompañado de una buena idea, además de otros factores técnicos. Este proyecto ha tratado de unir estos dos elementos, para poner la tecnología en servicio de la gestión de los negocios de hostelería. Como ya ha sido comentado a lo largo de este proyecto, el sector de la hostelería es el motor de la economía española, que sostiene al turismo. Este sector se va adaptando lentamente al avance tecnológico comparado a otros sectores, a pesar de su importancia y extensión. Más concretamente, en el sector de la restauración, la manera de llevar el negocio y atender a los clientes se lleva realizando exactamente de la misma manera desde hace muchos años, sin ofrecer nada nuevo en la gestión a sus clientes, o para la simple mejora del negocio. Página 193

Este proyecto propone dar un paso, desde hace tiempo necesario, a la implantación de la tecnología en un sector muy importante. Combina el conocimiento tecnológico sobre el tratamiento de la información, con una idea que mejora sustancialmente la buena marcha del negocio, reduciendo tiempos innecesarios, mejorando la gestión de todas las actividades, aportando mayor información a los usuarios, y estimulando el consumo de una nueva manera. Además este proyecto no plantea una mera herramienta funcional que ayude en las tareas de gestión al negocio, sino que al mismo tiempo es una invitación a los clientes para participar en una nueva forma de tecnología, donde podrán contar con mayor información y control, y por consiguiente, se busca producir interiormente la satisfacción del placer intelectual, lúdico y estético de sus usuarios, esto implica el uso de la tecnología bien diseñada y aplicada. En definitiva, el sistema presentado en este proyecto, es una proposición del uso de la tecnología para la mejora de la calidad del sector más importante en España en el ámbito del negocio, la gestión y el servicio a los clientes, y por lo tanto, una mejora en la calidad de vida de todos sus participantes. Página 194

10) Futuras mejoras

10. FUTURAS MEJORAS En este apartado se consideran las posibles mejoras que se le podrían aplicar al sistema para otorgarle una mayor funcionalidad. Algunas de las posibles funcionalidades adicionales serían: Incrementar el número de informes: El gerente necesita numerosa información, y se podría utilizar el sistema ya implantado para registrar más información acerca del desarrollo del negocio, de tal manera que todo estaría centralizado. Exportar informes en PDF: actualmente los informes se muestran por pantalla y esto implica también la posibilidad de imprimirlos. Pero extraer los informes en PDF aportaría mayor facilidad para el almacenamiento digital. Creación de una red de usuarios: sería una opción interesante permitir a los clientes hacer comentarios sobre sus platos preferidos, y que estos los puedan visualizar en tiempo real durante su estancia en el restaurante, elaborando así un ranking personalizado de platos preferidos. Página 196

11) Bibliografía

11. BIBLIOGRAFÍA A continuación se indican aquellas fuentes consultadas durante la elaboración del proyecto. 11.1 Libros [BARR01] Jesús Barranco de Areba, Metodología del análisis estructurado de sistemas, Publicaciones de la Universidad Pontificia Comillas, Madrid 2001. [RIVE05] Enrique Rivero Cornelio, Luis Martínez Fuentes, Israel Alonso Martínez, Bases de datos relacionales: Fundamentos y diseño lógico, Publicaciones de la Universidad Pontificia Comillas, Madrid 2005. [LARM03] Craig Larman, Applying UML and Patterns. 2nd edition, 2003. [WESL99] Addison Wesley Longman, Martin Fowler, UML gota a gota, 1999. [MUÑO08] Manuel Muñoz García, Apuntes de Gestión de Proyectos Informáticos,Madrid 2008. Página 198

[ESQU08] Juan Carlos Esquivel, Apuntes de Ingeniería del Software II, Madrid 2008. Página 199

11.2 Páginas web [WWW001] Ministerio de Industria, Turismo y Comercio. http://www.mityc.es/turismo [WWW002] Federación Española de Hostelería. http://www.fehr.es/ [WWW003] Portal de comunicación de hostelería. http://www.hosteleriadigital.es/ [WWW004] Instituto nacional de estadística. http://www.ine.es/inebmenu/mnu_hosteleria.htm [WWW005] Restauración electrónica. http://www.e-restauracion.com [WWW006] Portal de empleo para la hostelería y turismo. http://www.emia.es/cgi-bin/master.pl?accion=inicio [WWW007] Página oficial restbar. http://www.restbar.com/ Página 200

12) Anexos

12. ANEXOS En este apartado se incluye una valoración económica del proyecto, una planificación y un manual de usuario. 12.1 Manuales En este apartado se muestran los dos manuales de que se compone la aplicación: manual de explotación y manual de usuario. 12.1.1 Manual de explotación El manual de explotación es aquel dirigido al administrador de la aplicación. A continuación, se presentan los pasos para establecer un entorno de desarrollo idéntico al utilizado en el proyecto. Para ello se requieren los siguientes pasos: entorno de desarrollo Netbeans, servidor de BBDD MySQL, servidor Apache Tomcat. Para la instalación del entorno de desarrollo Netbans, es necesario seguir estos pasos: 10. En un entorno Windows hay que ejecutar simplemente el instalador, por ejemplo netbeans-6.1-mljavaee-windows.exe Página 202

11. Aparecerá la primera ventana del asistente de instalación, en la que se pregunta los servidores a instalar. Es necesario seleccionar al menos Glassfish V2 UR2. Pulsar el botón Next. 12. En la siguiente ventana, simplemente se solicitará la aceptación de los términos de la licencia del producto. 13. En la siguiente ventana se muestra el directorio donde se va a realizar la instalación y donde se encuentra el JDK de Java. En principio, se dejan los valores por defecto. En cualquier caso, es importante tomar nota de dónde se va a instalar Página 203

Netbeans 6.1 ya que se necesitará esa información posteriormente. Pulsar Next. 14. La siguiente ventana muestra las opciones de instalación del servidor Glassfish. En principio, se dejarán los valores por defecto que aparecen. Si se cambian, es importante tomar nota de los valores que se asignan al usuario administrador, su contraseña, puerto HTTP y puerto de la consola de administración. Pulsar el botón Next. 15. En la siguiente ventana aparece un resumen de los parámetros de la instalación. Pulsar el botón Install. Página 204

16. Al finalizar, aparecerá una ventana donde se informará de que ha finalizado la instalación y ofrecerá la posibilidad de registrar el producto. Pulsar el botón Finish. Para la instalación del entorno de MySQL es necesario seguir estos pasos: 1. Ejecutar el programa mysql-5.0.67-setup.exe. Ello inicializará el asistente de instalación de MySQL. Pulsar Next. 2. Aparecerá una ventana donde pide escoger el tipo de instalación. Seleccionar Typical. Página 205

3. En la siguiente ventana que aparecerá, pulsar Install. Tras la instalación, aparecerán una serie de ventanas de publicidad de MySQL y finalmente la ventana siguiente, donde se debe comprobar que está seleccionado el checkbox para configurar el servidor. Tras ello, pulsar Finish. Página 206

4. Aparecerá entonces la ventana inicial del asistente de configuración del servidor. Pulsar Next. Página 207

5. En la siguiente ventana, escoger configuración estándar y pulsar Next. 6. En la siguiente ventana que aparece, deben estar seleccionados todos los checkboxes que aparecen, tal como se muestra en la imagen. Página 208

7. En la siguiente ventana se debe indicar la contraseña del usuario root. Se recomienda la utilización de la contraseña root. Página 209

8. En la siguiente ventana que aparecerá, pulsar el botón Execute. Cuando finalice la configuración, aparecerá la siguiente ventana. Pulsar Finish. Servidor Apache Tomcat: Para instalar el servidor Tomcat, simplemente se debe descomprimir el fichero apachetomcat- 6.0.14.zip (botón derecho y seleccionar Extraer ficheros). Se recomienda una descompresión en la raíz del disco C, con lo cual se creará en este disco la carpeta C:\apache-tomcat-6.0.14. En caso de que ya estuviese instalado, se recomienda hacer una copia en la raíz de c. Página 210

12.1.2 Manual de usuario Este es el manual para usuarios del Sistema Integral para la Gestión de Restaurantes. Existen tres grupos fundamentales de usuarios: Gerente: con derecho de acceso a información reservada como informes económicos. Empleados: aquellos usuarios con capacidad de visualizar comandas e introducir sugerencias. Clientes: serán todos aquellos usuarios que realicen comandas al módulo de cocina y que naveguen a través del menú virtual. En primer lugar, sólo en el módulo de cocina, aparecerá una ventana de login, para comenzar una sesión como empleado o como gerente: Página 211

Después en el caso del gerente encontrará este menú: Mientras que en el caso de ser otro empleado, encontrará este menú más reducido: Página 212

En el lado del cliente, en el módulo de mesa, este será su inicio: Posteriormente, en el caso en el que el gerente o el chef hayan pulsado sobre introducir sugerencias, se encontrarán con la siguiente ventana: Página 213

En caso en que se haya selección visualizar comandas, esta será su ventana: Si el gerente en su menú, pulsó sobre editar carta virtual, se encontrará con la siguiente ventana, donde podrá editar la descripción, el número de plato, los ingredientes, o la dirección de la URL donde está ubicada la imagen o vídeo demostrativo: Página 214

Sin embargo, si pulsó sobre acceder informes, obtendrá los siguientes resultados: Página 215

Si los clientes, accedieron a través del menú de bienvenida a la carta virtual, esto será lo que encuentren: Página 216

Si los clientes pulsan sobre el botón Más información accederán a la siguiente ventana que detalla un plato concreto: Página 217

12.2 Valoración económica A continuación se estima el presupuesto del proyecto que incluirá a los participantes del mismo, director, jefe de proyecto, analista y programador y los gastos software y hardware pertinentes necesarios para la implantación del sistema. 12.2.1 Presupuesto en horas hombre Se han considerado cuatro participantes en el proyecto: director, jefe de proyecto, analista y programador. En la tabla que se muestra a continuación, se representa las horas que ha empleado cada participante, junto con su tarifa y el cálculo de horas empleadas en la realización del proyecto. El número de horas se ha calculado teniendo en cuenta que la duración total del proyecto es de unas 490 horas de trabajo, de las cuales el director emplea unas 30, el jefe de proyecto 50, el analista 281 y el programador 120. Página 218

Participante Horas Tarifa por hora Total Director 30 95 2850 Jefe de proyecto 60 70 4200 Analista 281 50 14050 Programador 120 30 3600 TOTAL 491-24700 Página 219

12.2.2 Presupuesto de hardware y software Para el desarrollo del sistema, serán necesarias las siguientes herramientas: Elemento Precio Cantidad Total Equipo de 650 3 1950 sobremesa Pantalla táctil 310 2 620 Servidor 283 1 283 Subtotal HW - 6 2853 Windows 150 3 450 Subtotal SW - 3 450 TOTAL - 9 3303 Página 220

12.2.3 Presupuesto total del proyecto En este apartado se muestra el presupuesto total del proyecto después de los cálculos de tarifas hardware, software y de los participantes. Tipo Coste Sueldos y salarios 24700 Hardware 2853 Software 450 TOTAL 28003 El presupuesto final del proyecto es de 28003. Página 221

12.3 Planificación En este anexo se muestra la planificación realizada para el desarrollo del proyecto. Página 222