Sistema Gestion de Restaurantes 1

Autorizada la entrega del proyecto del alumno:
Gorka Daz de Orbe

EL DIRECTOR DEL PROYECTO

Carlos Labanda Majn

Fdo.: Fecha: 28/07/2010

V B del Coordinador de Proyectos

Eduardo Alcalde Lancharro

Fdo.: Fecha: 03/09/2010

PROYECTO FIN DE CARRERA

SISTEMA INTEGRAL PARA LA
GESTIN DE RESTAURANTES

AUTOR: GORKA DAZ DE ORBE

MADRID, SEPTIEMBRE DE 2010

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)
INGENIERO EN INFORMTICA

Sistema Integral para la Gestin Restaurantes

Pgina I

Dedicatoria

A mi madre, por los valores que me ha enseado y que nunca olvidar


Pgina II

Agradecimientos

A mi padre y hermano, por saber sostenerme durante todos estos aos
de mi vida, otorgndome la posibilidad, de sentirme privilegiado, y
hacerme crecer.

A mis amigos, por su apoyo incondicional, desde que somos pequeos
en todas las facetas de la vida.

A mis compaeros, por toda la ayuda recibida.

A Pablo, por sus fantsticos dibujos.

A todos aquellos que de alguna manera habis participando en el
proyecto, con vuestra inquietud y apoyo inestimable.


Pgina III

RESUMEN DEL PROYECTO
El objeto de este proyecto es el desarrollo e implantacin de un Sistema Integral para la
Gestin de Restaurantes.
Este sistema ha sido desarrollado para cubrir las necesidades bsicas de la gestin de un
restaurante, ofreciendo la tecnologa existente al desarrollo del negocio.
El Sistema Integral para la Gestin de Restaurantes est especialmente diseado para
aquellos restaurantes en los que el tiempo es una variable importante para su economa
y para aquellos que simplemente deseen ofrecer un mejor servicio a sus clientes,
proporcionndoles una forma diferente de informacin y atencin de sus necesidades.
En la actualidad, la gestin de las comandas de los clientes, la transmisin de las
rdenes a la cocina, la proposicin de sugerencias, la insercin de publicidad y la
gestin de los diversos mdulos del negocio, se lleva realizando de la misma manera
desde hace muchos aos.
El anlisis de esta situacin, ha permitido llegar a la conclusin de que existe un amplio
margen de mejora en todos los procesos diarios que se realizan en la atencin y servicio
a los clientes de un restaurante.
Este sistema propone una revolucin en la gestin de los diferentes elementos
principales del negocio, haciendo uso de la tecnologa en servicio de sus usuarios.
Se ha dividido el sistema en dos mdulos fundamentales, uno es el mdulo de mesa, que
est disponible en cada una de las mesas del saln de un restaurante, y otro es el mdulo
de cocina, que se instala en la cocina para posibilitar la comunicacin directa de los
clientes con la cocina.
Ambos mdulos ofrecen una funcionalidad distinta, y juntos controlan de forma integral
diversos factores sobre el desarrollo y gestin del negocio.
El Sistema Integral para la Gestin de Restaurantes est desarrollado en una
arquitectura cliente-servidor de cliente ligero, haciendo uso de un entorno gratuito


Pgina IV

(J2EE, MySQL y Apache) y permite controlar los siguientes aspectos de la gestin de
un restaurante:
Carta virtual: muestra a los clientes del restaurante, en sus mesas, a travs del
mdulo existente, la variedad de platos, bebidas y ofertas que el restaurante
dispone para sus clientes. Adems, permitir el acceso a informacin ms
detallada que sobre un men en papel en caso en que el cliente est interesando,
proporcionando ms informacin acerca de los ingredientes, su forma de
elaboracin, presentacin de imgenes sobre el aspecto real del plato, y
posibilidad de visualizacin de videos acerca de su preparacin.
A travs 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
ms adelante.
Comandas: controla el transporte y trato de la informacin sobre las rdenes de
los clientes, directamente desde sus mesas, hasta la cocina, donde en su
respectivo mdulo, se podrn visualizar todas las comandas que realicen los
clientes, las comandas ya atendidas, y aquellas que an estn pendientes. Este
innovador proceso, permite una comunicacin directa de los clientes con la
cocina, evitando tiempo de espera en la atencin del camarero o en el transporte
de la informacin del camarero, a la cocina.
Publicidad y sugerencias: el gerente del restaurante, o el chef de cocina, podrn
ofrecer a sus clientes sugerencias desde el mdulo de cocina, al mdulo de mesa,
estimulando la demanda de sus consumidores. Adems, tambin existe la
posibilidad de reservar un espacio en la carta para la insercin de publicidad,
creando de esta manera, un importante espacio para vender a terceros, o
promocionar otros restaurantes asociados a los clientes.
Economa: todos los movimientos relativos a la atencin de comandas del
restaurante, quedarn registrados con detalle en bases de datos, donde ms tarde,
a travs de procesos que traten esta informacin, se obtendrn informes de
especial importancia para el desarrollo del negocio, como es un resumen de la
facturacin, y un control de la demanda de platos ordenados de forma
ascendente.


Pgina V

Para el desarrollo del proyecto se sigui el ciclo de vida lineal o en cascada, con sus
respectivas fases: Identificacin de necesidades, Anlisis de Requisitos, Estudio de la
arquitectura, Diseo externo, Diseo interno, Programacin, Pruebas e Implantacin.
La ltima parte del proyecto incluye una valoracin econmica del mismo y la
planificacin llevada a cabo para su desarrollo.
Como conclusin, este proyecto supone una importante modernizacin del sector ms
importante en Espaa, como es la hostelera y la restauracin, que son las bases de
acogida del turismo, motor de la economa nacional, aportando una mayor
funcionalidad a los restaurantes, perfeccionando su gestin, reduciendo tiempos
innecesarios y mejorando por lo tanto, el servicio ofrecido a sus clientes.


Pgina VI

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 client-
server 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


Pgina VII

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 ones 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.


Pgina VIII

ndice

1. INTRODUCCIN ________________________________________________ 2
1.1 Sector de la hostelera. ____________________________________ 2
1.1.1 Empleo en hostelera _____________________________________ 10
1.2 Las empresas cliente ______________________________________ 12
2. IDENTIFICACIN DE NECESIDADES __________________________ 17
2.1 Organizacin empresarial _________________________________ 17
2.2 Tipologa de los usuarios finales __________________________ 25
2.3 Antecedentes del sistema _________________________________ 27
2.4 Objetivos del sistema _____________________________________ 32
2.5 Alcance de la aplicacin __________________________________ 35
2.6 Restricciones _____________________________________________ 36
3. ANLISIS 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 organizacin afectadas por la mecanizacin
57
3.5 Lista de requisitos ________________________________________ 60
3.6 Modelo lgico de datos ____________________________________ 82
3.6.1 DFD contextual __________________________________________ 82
3.6.2 DFD conceptual _________________________________________ 83
3.6.3 Modelo conceptual de datos. _____________________________ 105


Pgina IX

4. ESTUDIO DE LA ARQUITECTURA ___________________________ 110
4.1 Especificacin de las alternativas_______________________ 110
4.1.1 Arquitecturas ___________________________________________ 110
4.1.2 Lenguajes de programacin para los clientes _____________ 123
4.1.3 Lenguajes de programacin para el servidor ______________ 135
4.1.4 Sistemas Gestor de Bases de Datos ______________________ 143
4.1.5 Sistemas operativos _____________________________________ 147
4.2 Evaluacin de las alternativas __________________________ 151
4.2.1 Evaluacin de la arquitectura ___________________________ 151
4.2.2 Evaluacin del sistema operativo ________________________ 154
4.2.3 Evaluacin del lenguaje de programacin en el cliente ____ 155
4.2.4 Evaluacin del lenguaje de programacin en el servidor __ 157
4.2.5 Evaluacin del sistema gestor de bases de datos _________ 158
4.3 Seleccin de la alternativa ______________________________ 159
5. DISEO EXTERNO __________________________________________ 162
5.1 Entorno operativo ______________________________________ 162
5.2 Fronteras de mecanizacin _____________________________ 163
5.3 Especificacin de procesos _____________________________ 163
5.4 Diseo de interfaces ____________________________________ 166
5.4.1 Interfaz login ____________________________________________ 166
5.4.2 Men privado ___________________________________________ 167
5.4.3 Men pblico ___________________________________________ 173
5.5 Procesos de seguridad __________________________________ 176
6. DISEO INTERNO ___________________________________________ 178
6.1 Diseo interno de programas ___________________________ 178
6.1.1 Diagrama HIPO Administracin de empleados ____________ 179
6.1.2 Diagrama HIPO Alta comanda ___________________________ 180
6.1.3 Diagrama STC Administracin de empleados _____________ 181


Pgina X

6.2 Modelo fsico de la base de datos _______________________ 182
7. PRUEBAS ___________________________________________________ 187
7.1 Pruebas unitarias _______________________________________ 187
7.2 Pruebas de integracin __________________________________ 189
8. IMPLANTACIN _____________________________________________ 191
8.1 Implantacin fsica _____________________________________ 191
9. CONCLUSIONES _____________________________________________ 193
10. FUTURAS MEJORAS ______________________________________ 196
11. BIBLIOGRAFA ____________________________________________ 198
11.1 Libros ___________________________________________________ 198
11.2 Pginas web _____________________________________________ 200
12. ANEXOS ___________________________________________________ 202
12.1 Manuales ________________________________________________ 202
12.1.1 Manual de explotacin ________________________________ 202
12.1.2 Manual de usuario ____________________________________ 211
12.2 Valoracin econmica __________________________________ 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 Planificacin ____________________________________________ 222

1) Introduccin


Pgina 2

1. INTRODUCCIN

El presente proyecto plantea el desarrollo de un sistema integral para la
gestin de restaurantes, con el objeto de mejorar sustancialmente,
gracias a la tecnologa ofrecida, los restaurantes y otros negocios del
sector hostelero relacionados con la alimentacin, como bares,
cafeteras y casas de comida.

Para una mejor comprensin, se realiza en este captulo una
presentacin del sector hostelero, dentro del cual se engloban todos los
restaurantes, bares y cafeteras y un breve anlisis del mercado en el
cual, dicho proyecto, tiene su impacto. Para la realizacin de este
proyecto se han seguido las referencias bibliogrficas [WWW001],
[WWW002], [WWW003], [WWW004], [WWW005]

1.1 Sector de la hostelera.

Todas aquellas actividades econmicas consistentes en la prestacin de
servicios ligados al alojamiento y la alimentacin espordica, pertenecen
al sector de hostelera.

Muy usualmente estn ligados al turismo, tales como hoteles, hostales,
paradores, bares, cafeteras y restaurantes.

No se considera hostelera al servicio de comida a domicilio y todos
aquellos combinados con otro tipo actividades de ocio como discotecas,
etc.


Pgina 3

El sector espaol de la hostelera tiene una elevada repercusin en la
formacin del PIB, algo superior al 7 %, lo que pone de manifiesto su
influencia, y su repercusin, en la creacin de riqueza y en la
generacin y mantenimiento del empleo.

La modernizacin que la hostelera ha impulsado en las ltimas
dcadas ha permitido que el sector se consolide con un rol destacado
dentro de la economa y la sociedad espaola. El incremento en los
parmetros de competitividad y eficiencia, es el principal indicador que
refleja un desempeo sobresaliente, confirmando el alto grado de
importancia relativa y absoluta alcanzado por el sector turstico
espaol.

Con una produccin anual de casi 12 billones de euros y un volumen
de empleo que se acerca al milln de personas, es evidente la
importancia de la Hostelera en la economa nacional.

Un sector que, tal y como recoge el informe presentado por la
Federacin Espaola de Hostelera (FEHR) en relacin al ao 1999,
cuenta con ms de 333.000 establecimientos repartidos entre las
actividades de hoteles, restaurantes, colectividades, cafs-bares y
cafeteras. De entre ellos, es el subsector de la restauracin el que posee
un mayor nmero de plazas con una cifra superior a los 3,3 millones.
A continuacin, para poder apreciar la progresin del sector, se
representa en la siguiente tabla, el crecimiento del nmero de
restaurantes en Espaa, desde 1975 hasta el 2008:


Pgina 4

ndice de crecimiento del sector de restaurantes

Aos Nmero ndice Variacin
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: Secretara General de Turismo y DIRCE.

Segn la Secretara General de Turismo y DIRCE (Directorio Central de
Empresas), durante el ao 2007, 69.298 establecimientos, con 4,29
millones de plazas, se integraron bajo la tipologa de restaurantes, un
2,68 ms que en 2005, y su produccin se ha situado en 23.100
millones de euros.

Como se recoge en la tabla anterior, la expansin del nmero de
restaurantes casi se ha cuadriplicado desde 1975.


Pgina 5

El cada vez ms frecuente hbito de comer fuera del hogar se esconde
detrs de este crecimiento, y adems se debe al importante desarrollo
que ha tenido el turismo en Espaa y a los mejores niveles de vida que
tiene la poblacin.

A continuacin, se representa, la distribucin del censo por
comunidades autnomas de restaurantes en los aos 2007 y 2008.
Cabe sealar, que se han agregado tambin las cafeteras, en la
siguiente tabla:


Pgina 6

Comunidades
Autnomas

Ao 2007 Ao 2008
Andaluca 8.351
8.615
Aragn 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 Len 2.781 4.552
Castilla La Mancha 4.419 2.987
*Catalua 17.301 17.301**
Extremadura 1.455 1.530
Galicia 5.225 5.145
Madrid (Comunidad) 8.051 8.363
Murcia (Regin) 1.995 2.094
Navarra (Comunidad
Foral)
632 651
Pas 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 cafeteras

El reparto por comunidades autnomas estara encabezado por
Catalua, seguido de la Comunidad Valenciana, Andaluca, Madrid y


Pgina 7

Canarias. En el extremo opuesto, se encuentra Extremadura,
Cantabria, Navarra, y La Rioja con el menor nmero de
establecimientos.

Se representa a continuacin, de forma grfica, los datos representados
en la tabla anterior, sobre la distribucin de restaurantes por
Comunidades Autnomas en el 2008, donde se puede apreciar, de una
forma ms intuitiva que la mayor concentracin de restaurantes y
cafeteras, se encuentra en Catalua, Comunidad Valenciana,
Andaluca y Madrid.

Distribucin de restaurantes por
Comunidades Autnomas
Ao 2008
Andaluca
Aragn
Asturias (Principado)
Baleares (Islas)
Canarias (Islas)
Cantabria
Castilla Len
Castilla La Mancha
Catalua
Extremadura
Galicia
Madrid (Comunidad)
Murcia (Regin)
Navarra (Comunidad Foral)
Pas Vasco


Pgina 8

El subsector restauracin, hacia el cual el presente proyecto est
dirigido, supuso una participacin del 32,91 % dentro del sector
hostelera, aportando 42.233 millones de euros, como se puede
observar en la tabla a continuacin, adems, para una mejor
visualizacin de la importancia del subsector restauracin, dentro de la
hostelera, se representa la misma tabla de forma grfica ms abajo:

Distribucin de la produccin nacional del sector de la hostelera,
en 2008

Millones euros % Participacin

Sector Alojamiento 17.102 13,33
Sector de comidas 42.233 32,91
Sector de bebidas 59.505 46,37
Sec. Colectivid. y
Caterings
9.477 7,39

Total 128.317 100,00


Pgina 9

El incremento medio de la produccin sobre el ao 2007 fue del 3,58 %
siendo el sector de la hostelera, uno de los ms importantes para la
economa nacional, y ms concretamente, el subsector restauracin.

Produccin nacional de hostelera 2008
Sector Alojamiento
Sector de comidas
Sector de bebidas
Sec. Colectivid. y Caterings


Pgina 10

1.1.1 Empleo en hostelera

Respecto a la situacin de crisis econmica actual, se presenta a
continuacin, un breve estudio de los ltimos datos de empleo en
hostelera y restauracin.

En el mes de abril el nmero de trabajadores con alta en empresas de
hostelera era de 1.278.793, lo que supone un 1,2 % ms que en el
mismo mes de 2009, segn los datos del Ministerio de Trabajo y
Asuntos Sociales. Esta evolucin positiva se debe a los servicios de
restauracin que representan la mayor parte de la hostelera, 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 %, despus del
aumento que se produjo en el mes de marzo (2,3 %).

La media en los cuatro primeros meses del ao supone en restauracin
un incremento del 1,1 %, con relacin al mismo perodo de 2009. En
hoteles y otros alojamientos cae el empleo un 1,4 % interanual.

Concretamente, en el sector restauracin, 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 restauracin,
lo que supone un 1,8 % ms que en el mismo mes del ao anterior.


Pgina 11

Esta tasa interanual es 1,2 puntos superior a la de enero y significa una
ligera recuperacin ya que en marzo de 2008 el nmero de trabajadores
era un 3,9 % menos respecto al ao anterior.

En lo que va de ao 1.213.035 trabajadores estuvieron empleados de
media en el conjunto de la hostelera, aumentando un 0,4 % respecto al
mismo perodo de 2009.

A continuacin se representa una grfica comparativa de las tasas de
empleo en alojamiento y restauracin, comentadas anteriormente, de
abril de 2009 a abril de 2010:


Pgina 12

1.2 Las empresas cliente

En este captulo se presentan las empresas de restauracin, a las que
va especialmente dirigido el presente proyecto.

Algunos de los objetivos principales que se buscan con el Sistema
Integral para la Gestin de Restaurantes, son: la posibilidad de acceder
al men de forma virtual con informacin ms detallada incluyendo
fotos o videos, ahorro de tiempo en la gestin de comandas evitando el
tiempo de espera hasta que atienda el camarero y el tiempo de
transmisin de la comanda desde el camarero a la cocina, posibilidad
para los restaurantes de la introduccin de publicidad y sugerencias en
sus cartas virtuales, y una mejor gestin de todos los pedidos, evitando
errores de anotacin 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 rpida, y todas aquellas cadenas de
restaurantes donde el tiempo para atender, y servir a los clientes, es
una variable especialmente importante.

A continuacin, para un mejor conocimiento del perfil de posibles
empresas cliente, se presentan algunos ejemplos, hacia las cuales, el
Sistema Integral de Gestin de Restaurantes, est especialmente
dirigido:


Pgina 13

Mc Donalds: es una cadena de restaurantes de comida
rpida fundada en 1940, por los hermanos Dick y Mac
McDonald.
Es la cadena ms grande en el mundo y provee una gran
variedad de emparedados, bocadillos y otros productos de
comida rpida.

En Espaa, McDonalds factura 755 millones de euros, y
tiene ms de 311 restaurantes franquiciados.

Burger King Corporation: es la segunda cadena ms
grande de restaurantes de comida rpida, fundada en
Miami en 1954. Cuenta con ms de 12.100 restaurantes en
todo el mundo.

Telepizza: es una cadena espaola de pizzeras con
presencia en varios pases fundada por Leopoldo Fernndez
Pujals en 1986. La cadena se extendi por Madrid primero
y creci en pocos aos hasta convertirse en lder del


Pgina 14

mercado espaol de pizzas y en el segundo grupo de comida
rpida por detrs de McDonald's. Telepizza cuenta con la
siguientes presencia:

559 establecimientos en Espaa
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 lder en el sector de la hostelera
en Espaa. Cuenta con 6 cadenas (Vips, Ginos, Tio Pepe,
The Wok, TGI Fridays, BSF) y 11 restaurantes (El bodegn,
Iroco, Bice, Teatriz, Lucca, Tattaglia, Rugantino, Paparazzi,
Mood, Root y Starbucks) repartidos en 400
establecimientos, presente en 16 provincias espaolas y en
Portugal.


Pgina 15

Grupo Zena (Fosters Hollywood): es la primera compaa
de restauracin multimarca en Espaa gracias al xito
obtenido en su triple vertiente de franquiciado (Pizza Hut,
Burger King, KFC), franquiciador (Foster's Hollywood,
Caas 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 gestin que
desarrolla.

Fosters Hollywood se fund en 1971 como la primera
cadena de restaurantes de comida americana en instalarse
en Espaa y dispone de ms de 480 restaurantes.

2) Identificacin de
necesidades


Pgina 17

2. IDENTIFICACIN DE NECESIDADES

Esta etapa sirve como soporte a la peticin 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 tipologa 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 direccin del proyecto.

2.1 Organizacin empresarial

El sistema integral de gestin de restaurantes est compuesto por un
mdulo de mesa, y otro mdulo de cocina.

Actualmente, los mtodos para gestionar toda la informacin 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.


Pgina 18

Con la implantacin del sistema que propone este proyecto, se
modificar sensiblemente la gestin de las comandas y el
funcionamiento general de la gestin de un restaurante, por lo que es
de suma importancia, un anlisis detallado de los perfiles que se vern
afectados, y cmo se llevar a cabo la nueva gestin.

En el siguiente organigrama, se analizan los perfiles que se vern
afectados por el sistema, diferenciando aquellos que se vern
especialmente afectados por la implantacin del mdulo de cocina
resaltados en un cuadro rojo, como aquellos que se vern afectados por
la implantacin del mdulo de mesa, resaltados por el recuadro azul.

Gerente
Contable
Jefe departamento
Ventas
Jefe departamento
administracin

Chef Mesero encargado
del saln

Meseros
Ayudantes
de cocina
Seguridad Limpieza

Proveedores

Sueldos


Pgina 19

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 implantacin
del sistema integral de gestin de restaurantes, tendr un impacto
positivo en el funcionamiento general de muchos de ellos.

A continuacin se describen los participantes de dicha estructura:

Gerente: es la persona encargada de la supervisin directa
de los subordinados ms prximos y de la organizacin 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 supervisin. A la vez gracias a esta
supervisin puede detectar anomalas y resolverlas. Dentro
de este conjunto de obligaciones tambin se encuentra el de
difusor de conocimientos o informacin que deben conocer
el resto de personal. Con todas estas obligaciones o
funciones logra que la organizacin funcione debidamente
como una unidad integrada.

Contable: es el encargado de obtener y registrar datos
contables, estadsticos y financieros, as como efectuar
pagos y cobros. Realiza asientos en los registros o libros de
contabilidad, efecta clculos, realiza costos de produccin,
hace transacciones bancarias, calcula los salarios a pagar
partiendo de los registros de horas trabajadas por cada
trabajador, y es el encargado de la Tesorera.


Pgina 20

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 pblicas y
marketing.

Jefe departamento de administracin: realiza el pago a
los proveedores, acreedores, administra las operaciones
bancarias, legales, y los sueldos de los empleados.

Proveedores: es el agente econmico que entrega o provee
materias primas, materiales o servicios, tiene la
responsabilidad de cumplir con los compromisos de entrega
pactados, segn el lugar y el tiempo acordados. Su misin
es fundamental para la prestacin del servicio en un
restaurante, suelen ser empresas externas y estn
especialmente supervisadas por el jefe del departamento de
administracin.

Sueldos: encargados de la administracin y supervisin de
los salarios a los empleados.

Chef: es el responsable del control de mercaderas y
faltantes, la realizacin y elaboracin de los distintos
mens, control de higiene de la cocina y empleados,
cuidado de los bienes de uso para realizar los mens, y
todas las tareas desempeadas en la cocina.

Ayudantes de cocina: son colaboradores en la realizacin
de los mens, mantienen la higiene de la cocina y cuidan
de los bienes de uso de la cocina. Adems realizan tareas


Pgina 21

de agilidad para el trabajo del chef, ayudando en la
elaboracin de platos.

Mesero encargado del saln: es el responsable de la
organizacin del saln, del control de bienes y mercadera
de saln, se encarga de seleccionar sectores para cada
mesero, y supervisa sus tareas. Tambin realiza la
recepcin y acomodamiento de clientes en el restaurante.

Meseros: son los encargados del orden y limpieza del saln,
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 despus 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 saln.

Con la implantacin del sistema integral de gestin de restaurantes,
algunas de las funciones principales de los miembros de esta estructura
detalladas anteriormente, se vern modificadas sensiblemente,
proporcionando una mejora en la gestin y en el tiempo de la atencin a
los clientes.

Concretamente, modificarn su funcionamiento aquellos afectados por
el mdulo de mesa, remarcados en azul en el organigrama:


Pgina 22

Mesero encargado del saln: seguir siendo el responsable
de la organizacin del saln, control de la mercadera de
saln, supervisor de las tareas desempeadas por los
meseros y recepcin y acomodacin de los clientes.
Adems, presentar y explicar brevemente a los clientes el
novedoso sistema de mdulo de mesa para la visualizacin
del men virtualmente, con imgenes 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: seguirn siendo los encargados del orden y
limpieza del saln, del cuidado de su sector de trabajo, y
reordenacin del sector de trabajo despus del servicio.
Pero como gran novedad en sus funciones, no tendrn la
necesidad de atender las comandas de los clientes, sin
embargo podrn ayudarles en la utilizacin del sistema y en
aquellos problemas y dudas que surjan, y seguirn llevando


Pgina 23

y recogiendo las comandas que realicen sus clientes a sus
respectivas mesas.

Aquellos miembros, cuyo funcionamiento habitual, se ver modificado
gracias al mdulo de cocina del sistema integral de gestin de
restaurantes, son los siguientes, segn el marco rojo que se puede
apreciar en el organigrama anterior:

Chef: seguir siendo el responsable del control de
mercaderas y faltantes, la realizacin y elaboracin de los
distintos mens, control de higiene de la cocina y
empleados, cuidado de los bienes de uso para realizar los
mens, y todas las tareas desempeadas en la cocina.

Adems, ser el encargado de controlar, realizar y repartir
las comandas entre los ayudantes de cocina segn se
visualizan directamente en el mdulo de cocina.


Pgina 24

Ayudantes de cocina: seguirn siendo los colaboradores en
la realizacin de los mens, mantendrn la higiene de la
cocina y cuidarn de los bienes de uso de la cocina,
realizacin de tareas de agilidad para el trabajo del chef, y
elaboracin de platos.
Adems, controlarn la recepcin de las comandas en el
mdulo de cocina, y marcarn aquellas comandas que ya
hayan sido atendidas.


Pgina 25

2.2 Tipologa de los usuarios finales

Este proyecto tendr los siguientes usuarios:

- Administrador: ser el responsable de la implantacin, diseo,
actualizacin, insercin de publicidad y mantenimiento del
sistema completo.

- Usuarios finales

Chef: realizar el control y repartir la elaboracin de las
comandas que se reciben en el mdulo de cocina entre los
ayudantes de cocina.

Ayudantes de cocina: controlarn la recepcin de
comandas segn vayan visualizndose en el mdulo de
cocina, editarn aquellas comandas satisfechas y revisarn
las comandas pendientes.

Mesero encargado del saln: guiar a aquellos clientes
que encuentren dificultades en el manejo del sistema y
supervisar el correcto funcionamiento del mdulo de
mesa.

Clientes: sern todas aquellas personas que realizarn las
comandas desde sus mesas, navegarn a travs del men
virtual, y podrn informarse de todas las ofertas,
promociones y publicidad ofrecidas por el restaurante.


Pgina 26

Dado que la aplicacin va dirigida a un pblico general, se realizar un
interfaz tctil hombre mquina agradable, intuitivo y vistoso a la vez
que funcional, que facilite la adaptacin de una forma sencilla y rpida
a la nueva aplicacin.


Pgina 27

2.3 Antecedentes del sistema

Desde hace aos, se realiza la gestin de los restaurantes de una
manera obsoleta, apoyndose nicamente en la tecnologa en el uso de
un software que permite registrar las comandas y emitir las facturas,
pero an se sigue anotando en papel, en muchos casos, las comandas,
aun se siguen visualizando los mens que ofrece cada restaurante en
papel, muchas veces con anotaciones escritas a mano y con
descripciones muy poco claras sobre la composicin 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
solventarn gracias a la implantacin del sistema integral de gestin de
restaurantes, pero para ello se estudia la tecnologa existente en la
actualidad:

RestBar Software: es un programa ampliamente utilizado en
bares y restaurantes que incluye la facturacin de mesas, ventas
rpidas y servicio exprs (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.


Pgina 28

Actualmente se usa en ms de 16 pases entre ellos Espaa 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:


Pgina 29

Adems, en algunos restaurantes, en lugar de anotar las comandas
posteriormente sobre el ordenador general que recoge las comandas, se
ha implementado el software tambin para Pocket PC y as poder
registrar la comanda ms rpidamente.

La versin para Pocket PC contiene bsicamente la misma
funcionalidad que la otra versin, pero implemente algunas novedades
que se describen a continuacin:

- Ingreso de comandas en la mesa del cliente.


Pgina 30

- Ingreso del nmero de Comensales en la mesa.

- Impresin 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 gestin de restaurantes que se utiliza actualmente y
que incluye las siguientes funcionalidades principales:

- Mapa grfico de mesas y cubiertos asignados.

- Gestin de entregas a domicilio.

- Panel de facturacin rpida.

- Gestin de reserva de mesas.


Pgina 31

- Emisin de facturas en distintos idiomas.

- Gestin administrativa y contable.

En resumen, los restaurantes usan hoy en da dos tipos de soluciones
software para la gestin de sus restaurantes: software de gestin
corriente de comandas, y software para Pocket PC.

Existen mltiples soluciones para la gestin corriente de un
restaurante, sin embargo, todas estas soluciones no permiten que los
usuarios visualicen virtualmente el men, accedan a informacin ms
detallada como vdeos o imgenes 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 gestin general de las comandas y el tiempo
de atencin a los clientes, y adems de aprovechar el uso de la
tecnologa de forma ms eficiente y eficaz para el negocio, da un toque
de distincin y originalidad a los restaurantes que lo implementen.


Pgina 32

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 gestin de restaurantes.

Los objetivos sern de tipo funcionales y estratgico-econmicos.

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, fotografas o
vdeos.

Ofrecer una mayor precisin en la informacin transmitida hasta
la cocina, evitando posibles errores humanos en la compresin de
las comandas por parte de los camareros.

Mejorar de manera sensible la transmisin y gestin general de
las comandas evitando tiempos de atencin del camarero a los
clientes, y transmitiendo una informacin correcta, instantnea y
segura desde la mesa hasta la cocina.

Mejorar la gestin del reparto de trabajo en la cocina gracias a la
visualizacin de las comandas en tiempo real en el mdulo de
cocina.


Pgina 33

Dotar a los restaurantes de informacin exacta y detallada, para
el estudio sobre los pedidos realizados por los clientes, los platos
ms 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 estratgico-econmicos que se persiguen son los
siguientes:

Motivar la demanda gracias a la insercin 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 estticos
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 reduccin del nmero de ellos. Es posible que al
introducir el sistema de gestin, el nmero 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 slo
transportando las comandas desde la cocina a las mesas, y
viceversa. Los meseros seguirn siendo necesarios para poder
atender correctamente a los clientes pero sin embargo, tendrn
menos trabajo que desempear.


Pgina 34

Optimizacin del tiempo, que implica posibilidad de acoger a un
mayor nmero de clientes. Al eliminar los tiempos necesarios en
atender a los clientes por parte de los meseros, y eliminar el
tiempo de transmisin de la comanda desde el mesero hasta la
cocina, la comanda se puede atender ms rpidamente, los
clientes pueden terminar de comer antes, y por lo tanto, se
pueden atender un mayor nmero de clientes en el mismo da.
Actualmente una de las limitaciones principales en los ingresos
de los restaurantes, es el nmero de mesas disponibles para
poder atender a los clientes, por lo tanto, los restaurantes estn
interesados en que sus clientes terminen de comer rpidamente,
pudiendo ofrecer el sitio libre a otros nuevos clientes. Con este
sistema, se facilitar esta situacin.

Lograr una ventaja competitiva frente a otros restaurantes
marcando una estrategia de diferenciacin, al implementar un
sistema, en el sector de la restauracin, que se percibir como
nico, importante y exclusivo, y que aportar el placer de usarlo a
sus clientes.


Pgina 35

2.5 Alcance de la aplicacin

El proyecto abarcar los objetivos detallados anteriormente, para poder
llevarlos a cabo se implementarn las siguientes funcionalidades en el
sistema:

Gestin del men virtual: se mostrar informacin detallada
sobre la composicin y elaboracin de los platos.

Gestin de las comandas: se transmitir directamente, desde la
mesa de los clientes, a travs de una pantalla, las peticiones que
se realicen hasta un mdulo en la cocina, donde se podr
visualizar quin ha realizado la comanda, y en qu consiste.

Gestin de la economa: se podr mostrar, en el mdulo de
cocina, toda la informacin referente a la cantidad de comandas
realizadas y atendidas, el plato ms pedido y el de menor
demanda, as como un resumen de la facturacin realizada hasta
el momento que ser de gran utilidad para el seguimiento y
control del negocio.

Gestin de la instalacin: a travs del mdulo de cocina, se
gestionar toda la actividad que se realice en el saln, as como la
disposicin de las mesas en el restaurante, y los clientes.

Gestin de las sugerencias, promociones y publicidad: el gerente
del restaurante, podr introducir todas sus ofertas a travs del
men virtual directamente a sus clientes.


Pgina 36

2.6 Restricciones

En este apartado se hace referencia a las principales restricciones que
afectan al proyecto.

Para el desarrollo de la aplicacin, concretamente para el desarrollo del
men virtual se usarn bases de datos compuestas por informacin no
especfica de un solo restaurante, sino que se mezclarn datos que
ofrecen distintos restaurante, a modo de prueba.

Adems existen otro tipo de restricciones:

- Temporales: el proyecto se deber entregar dentro de la
fecha lmite establecida, que es en Septiembre de 2010.

- Econmicas: no se dispone del dinero necesario para la
implantacin real del sistema en un restaurante, as como
de las pantallas tctiles que se implantaran en las mesas
de los clientes, por lo que se desarrollar nicamente toda
la lgica y el software que lo compone.

- Organizativas: el proyecto debe ser desarrollado por una
sola persona, Gorka Daz de Orbe.

3) Anlisis de requisitos


Pgina 38

3. ANLISIS 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
solucin de la mejor forma posible.

A continuacin se realiza un primer y bsico anlisis de la aplicacin.
Para ello, se comienza con una introduccin, una descripcin del
sistema actual, una lista de requisitos que permite introducir el modelo
lgico 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 cmo 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 mdulo de
mesa.

A continuacin se muestra un diagrama del funcionamiento general del
sistema:


Pgina 39

Cliente 1 Pantalla tctil

Cliente 2 Pantalla tctil Servidor Mdulo de cocina

Cliente n Pantalla tctil Base de datos

Como se puede apreciar en el diagrama, los clientes recibirn del
servidor, que obtiene la informacin de la base de datos, las
posibilidades que ofrece el restaurante en su men, y estos una vez que
hayan elegido, enviarn sus comandas sobre el servidor, que mostrar
al mdulo de cocina las peticiones de los clientes actualizndose la base
de datos.


Pgina 40

3.2 Contexto general del sistema

A continuacin se muestra un diseo del sistema, en el cual se puede
apreciar una vista desde los clientes, que seleccionan sus comandas
desde las mesas.

La comunicacin se establecera en dos sentidos, desde los mdulos de
mesa al servidor, y desde el mdulo de cocina al servidor.

La comunicacin con el servidor que contiene la base de datos, en
ambos sentidos, se realizara a travs de una conexin local inalmbrica
como se puede ver reflejado en el diseo.


Pgina 41

Adems, para una mejor comprensin del mdulo de mesa, se procede
a incluir un diseo a continuacin en el que se refleja la conexin
inalmbrica que se realiza desde el mdulo hasta el servidor, y algunos
detalles de diseo fsicos, para que las pantallas no molesten a los
usuarios a la hora de consumir en el restaurante.


Pgina 42


Pgina 43

3.3 Funciones primarias afectadas

En este apartado, se analizan las funciones actuales que se vern
afectadas por la implantacin de la aplicacin.

A continuacin se muestra el procedimiento habitual del
funcionamiento de un restaurante, y posteriormente, las modificaciones
pertinentes debido a la instalacin del nuevo sistema de gestin.


Pgina 44

Mesa libre
Acomodar
Bienvenida
Orden de bebidas
y aperitivos
Comida
Tramitar comanda
Algo ms ?
no
Cobrar y despedir
no
Bebidas
no
no
si

En el siguiente diagrama se representa el nuevo funcionamiento de la
gestin de un restaurante, donde las funciones primarias se seguirn
realizando pero en este caso, algunas de ellas, las realizar el sistema.


Pgina 45

Mesa libre
Acomodar y
presentacin del
sistema
Bienvenida
Orden de bebidas
y aperitivos directo
a cocina
Comida
Tramitar comanda
directamente a
cocina
Algo ms ?
no
Cobrar y despedir
no
Bebidas
no
no
si
Funciones realizadas por el
sistema

El flujo de trabajo actual, que posteriormente se mejorar con el
sistema, se compone por los siguientes pasos:


Pgina 46

1. Bienvenida: La principal funcin del mesero encargado del
saln es dar la bienvenida los clientes y preguntarles la cantidad
de personas que ocuparn la mesa. Inmediatamente, se buscar
un sitio disponible si existe y despus deber acomodarlos en la
mesa. Aquellos establecimientos que dispongan de reas de
fumadores y no fumadores, se colocar al cliente segn la
predileccin.

Una vez en la mesa, el camarero debe acomodarlos sacando las
sillas, teniendo preferencia las damas. El mesero encargado del
saln proceder a registrar los clientes en el registro y control de
reservaciones, colocando la cantidad de clientes, la hora y el
nmero de mesa asignado.

2. Orden de bebidas y aperitivos: Una vez abordados los clientes
y despus de darle la bienvenida, el camarero preguntar si el
cliente desea algn aperitivo, vino o cctel antes de ver la carta.
Despus de servir los ccteles el camarero debe preguntar si los
clientes desean algn entrems. Despus de servido el entrems,
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


Pgina 47

cocina, o sea, al ayudante o camarero encargado de transportar
los platos de la cocina al comedor y viceversa.

La distribucin de las copias de la comanda se realiza segn el
estndar 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 debern pasar primeramente por la caja, para que
la cajera verifique si concuerdan las copias y sta sellar o
firmar las que irn 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 impresin 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
saln.

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,
ofrecindoles mayor informacin, y evitando errores en la transmisin
de la informacin hasta la cocina.


Pgina 48

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 mdulo
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 decisin sobre el men. La
comanda se transmitir directamente desde la mesa de los
clientes a la cocina, sin tener que necesitar la atencin del
camarero.

3. Tramitar comandas: despus de que los clientes hayan
decidido su seleccin a travs del men virtual, se confirmar la
comanda, y se transmitir directamente hasta la cocina, sin
necesidad de atencin del camarero.

En la cocina, se recibir la comanda realizada, y se podr
visualizar a travs del mdulo. 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
anlisis.

4. La despedida: este servicio no variar, el camarero seguir
realizndolo de la forma habitual.


Pgina 49

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 implantacin del
sistema, pero que es importante conocer en detalle para una mejor
comprensin del alcance y funcionamiento general de un restaurante.

Se representa a continuacin, un diagrama que muestra el curso de las
rdenes de compra y pago de un restaurante, as como de los
participantes implicados:


Pgina 50

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 lmite mnimo 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 mercaderas por duplicado.

3. El jefe del departamento de administracin, verifica, estudia y
aprueba los datos de solicitud de compra.

4. Despus de su aprobacin, se selecciona el proveedor adecuado
segn la orden emitida.


Pgina 51

5. Se enva 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 mercaderas.

6. A continuacin, el proveedor recibe el remito, y lo reenva por
triplicado, enva a la administracin las mercaderas junto con el
original y una copia.

7. Despus, la administracin controla las mercaderas recibidas
con el duplicado de la orden de compra (archivada
provisoriamente), el original y el duplicado del recibo, enviados
por el proveedor, distribuye la documentacin, se firma el
duplicado del recibo y lo enva al proveedor.

8. Posteriormente el proveedor emite la factura por triplicado a la
administracin.

9. Por ltimo, la administracin controla la factura con los recibos
que se haban archivado y se verifica el cumplimiento de los
plazos y lugares de entrega.


Pgina 52

3.3.2 Modificaciones sobre el funcionamiento

A continuacin se representa de forma grfica el funcionamiento de la
gestin de las comandas de un restaurante, y posteriormente se
proceder a analizar de forma detallada las mejoras que supondr la
implantacin del sistema.

En este caso, se producir un gran impacto en el funcionamiento
habitual, mejorando especialmente, el tiempo de atencin del mesero al
cliente, el tiempo de transmisin de la comanda desde el mesero al
cliente, la calidad de la informacin ofrecida a los clientes, y la calidad
de la informacin transmitida desde la mesa hasta la cocina.

En el grfico que se aprecia a continuacin, se representan los procesos
habituales de un restaurante, antes de la implantacin del sistema.


Pgina 53

Llegada nuevo
cliente
Espera de
bienvenida
Acomodamiento
y muestra del
men
Espera de
decisin de la
comanda
Espera de tiempo
de atencin del
camarero
Toma de la
comanda
Espera de tiempo
transmisin de la
comanda
Espera
preparacin de la
comanda
Entrega de la
comanda
Tiempo de
consumo
Despedida de
cliente


Pgina 54

A continuacin, el grfico que representa el nuevo funcionamiento,
ahorrando distintos tiempos en el proceso:
Llegada nuevo
cliente
Espera de
bienvenida
Acomodamiento
y muestra del
men
Espera de
decisin de la
comanda
Toma de la
comanda
Espera
preparacin de la
comanda
Entrega de la
comanda
Tiempo de
consumo
Despedida de
cliente


Pgina 55

Como se puede observar, se han representado las actividades que deben
atender los meseros, en crculos, y las esperas que se realizan en todo el
proceso de consumo del cliente, en rectngulos.

En el primer diagrama, se ha enmarcado en rojo, los tiempos que
desaparecern tras la implantacin del sistema. Se puede observar
como el tiempo de espera de atencin al cliente, y el tiempo de
transmisin de la comanda, desaparecen en el segundo diagrama,
variando as, el proceso habitual y mejorando por tanto la atencin y el
servicio al cliente.

Estos dos tiempos comentados anteriormente, desaparecen ya que la
informacin 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 ms importantes de los
restaurantes, especialmente aquellos de comida rpida, es el nmero de
clientes que pueden albergar en su interior.

La modificacin de este proceso, est especialmente diseado, para
acelerarlo, evitando tiempos largos, los clientes tendrn el servicio
requerido con mayor prontitud, y por lo tanto, adems de quedar ms
satisfechos por la rapidez, podrn liberar antes sus plazas para la
acogida de nuevos clientes.


Pgina 56

En definitiva, el restaurante ser capaz de atender a ms clientes, y de
mejor manera, en el mismo da, gracias a la implantacin del sistema
integral de gestin de restaurantes.


Pgina 57

3.4 Unidades de la organizacin afectadas por la mecanizacin

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 cdigo.

0: Nada afectado.
1: Poco afectado.
2: Muy afectado.

Funciones Perfiles
Gerente Chef Ayudante
de cocina
Mesero
encargado
del saln
Meseros
1.- Gestin del
men
1 2 2 1 1
2.- Gestin de
las comandas
0 2 2 1 1
3.-Gestin de
la economa
2 1 0 0 0
4.-Gestin de
instalaciones
0 1 1 1 1
5.-Gestin de
la publicidad
2 0 0 0 0


Pgina 58

En las siguientes lneas 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 valoracin con un resultado
cualitativo del impacto.

1. Gestin del men virtual: el men virtual es la base del
funcionamiento de todo el sistema, es por ello que todos los
perfiles representados se vern afectados por su implantacin.
Concretamente, el que mayor impacto tendr sobre el men, ser
el chef, que es el encargado de disear los platos para el
restaurante. Adems, los ayudantes de cocina tambin
participarn activamente en este diseo, el gerente deber dar su
aprobacin, y los meseros debern conocer con detalle la
composicin y funcionamiento del nuevo men.

2. Gestin de las comandas: en este caso, la tramitacin 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 travs del mdulo correspondiente. Tanto
el mesero encargado del saln, como el resto de meseros, debern
participar en la tramitacin de comandas en caso de algn
problema o duda por parte de los clientes, aunque en principio, el
sistema est diseado para que no tengan que participar
prcticamente nada.

3. Gestin de la economa: todas las comandas que se realicen en
el restaurante, pasarn por el servidor y este a su vez, las
registrar en la base de datos. Toda esta informacin ser de
especial inters para el gerente, ya que en funcin de la demanda,


Pgina 59

adoptar unas medidas u otras respecto a la buena marcha del
negocio.

4. Gestin de las instalaciones: el reparto de mesas y la
disposicin de los clientes, quedar registrado en el sistema, y
ser una informacin importante tanto para los trabajadores de la
cocina como para los trabajadores del saln.

5. Gestin 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
travs del sistema.


Pgina 60

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
captulo de Identificacin de Necesidades, y se han recogido en forma de
fichas individuales, fcilmente identificables y que ayudarn al diseo
del nuevo sistema.


Pgina 61

Proyecto: Sistema Integral de Gestin de Restaurantes
Jefe de proyecto: Gorka Daz de Orbe
Requisitos
Ttulo Entorno de fcil uso.
Identificador R-01 Fecha 25/03/2010
Versin 1.0 Prioridad Media
Estado Aceptado Categora Funcional
Descripcin Diseo de un interfaz cmodo de fcil de uso para los usuarios.
Medicin
Este requisito deber estar recogido en la aplicacin y ser objeto de un conjunto de
pruebas que validen su correcto funcionamiento.
Beneficios
Tener un interfaz agradable, de uso fcil y claro facilita el trabajo al usuario y como
consecuencia, rentabiliza el trabajo al mximo, eliminando tiempos adicionales por un
mal diseo de la aplicacin.
Comentarios / Soluciones sugeridas
La aplicacin debe estar pensada para interactuar con ella de forma fcil e intuitiva. Debe
ser apto para las manos, con botones lo suficientemente grandes, sin demasiada
informacin, y sencillez.
Documentos relacionados
Ninguno
Requisitos relacionados
Ninguno


Pgina 62

Requisitos
Ttulo Gestin del men virtual.
Versin 1.0 Prioridad Alta
Descripcin La aplicacin permitir el alta/baja/modificacin de los datos que se
representar en el men virtual.
Medicin
Este requisito deber estar recogido en la aplicacin y ser objeto de un conjunto de pruebas
que validen su correcto funcionamiento.
Beneficios
Tratar de innovar en la presentacin del men a los clientes, ofrecindoles mayor
simplicidad, informacin, y rapidez a la hora de realizar las comandas.
Este requisito se desarrollar en el mdulo de mesa. Existir una base de datos, de la cual se
obtendr el men.
Ninguno
R-03/ R-04


Pgina 63

Requisitos
Ttulo Gestin de las imgenes del mdulo de mesa.
Versin 1.0 Prioridad Baja
Descripcin La aplicacin permitir el alta/baja/modificacin de las imgenes que
se representarn en el men virtual.
Medicin
Beneficios
simplicidad, informacin, y permitir mostrar las imgenes de los platos que ofrece el
restaurante.
obtendr el men.
Ninguno
R-04


Pgina 64

Requisitos
Ttulo Gestin de los vdeos del mdulo de mesa.
Versin 1.0 Prioridad Baja
Descripcin La aplicacin permitir el alta/baja/modificacin de los vdeos que se
representarn en el men virtual.
Medicin
Beneficios
simplicidad, informacin, y permitir mostrar vdeos de los platos que ofrece el restaurante.
obtendr el men.
Ninguno
Ninguno


Pgina 65

Requisitos
Ttulo Gestin de las comandas.
Descripcin La aplicacin permitir el alta/baja/modificacin de las comandas
que realicen los clientes a travs del mdulo de mesa.
Medicin
Beneficios
Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportar una
mayor informacin en la gestin.

Los clientes podrn seleccionar los platos del men que desean consumir, se registrarn en la
base de datos, y se mostrar posteriormente en el mdulo de cocina.
Ninguno
R-06


Pgina 66

Requisitos
Ttulo Gestin de los ingredientes.
Descripcin La aplicacin permitir el alta/baja/modificacin de los
ingredientes que componen cada plato.
Medicin
Este requisito deber estar recogido en la aplicacin 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 informacin en la gestin.

El sistema permitir registrar la informacin referente a la composicin de cada plato, y
los clientes tendrn acceso a esta informacin a travs del mdulo de cocina.
Ninguno
Ninguno


Pgina 67

Requisitos
Ttulo Gestin de la economa.
Descripcin La aplicacin permitir una gestin eficiente de los datos econmicos
del restaurante.
Medicin
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 informticos actuales,
supondr un valor aadido al formar parte de la plataforma integral que contiene todos los
mdulos necesarios para la gestin de restaurantes.

Slo en el mdulo de cocina se podr tener acceso a la informacin, a travs de una interfaz
intuitiva, que mostrar el resumen principal de los datos econmicos.
Ninguno
R-08 / R-21


Pgina 68

Requisitos
Ttulo Gestin de la facturacin.
Descripcin La aplicacin permitir el alta/baja/modificacin de los datos de las
facturas.
Medicin
Beneficios

Slo en el mdulo de cocina se podr tener acceso a la informacin, a travs de una interfaz
intuitiva, que mostrar el resumen principal de las facturas.
Ninguno
R-21


Pgina 69

Requisitos
Ttulo Gestin de las instalaciones.
Descripcin La aplicacin permitir una gestin eficiente de las instalaciones del
restaurante. Para ello se deben desarrollar los siguientes submdulos:
gestin del saln y gestin de la cocina.
Medicin
El sistema estar compuesto por el mdulo de mesa, de acceso a los clientes, que gestionar
el saln, y el mdulo de cocina, que se implantar en la cocina.
Beneficios

El acceso a los distintos mdulos se realizar segn estn ubicados fsicamente, puede ser
desde la cocina, o desde el saln.
Ninguno
R-10 / R-11


Pgina 70

Requisitos
Ttulo Gestin del saln.
Descripcin La aplicacin permitir una gestin eficiente de los mdulos que se
encuentren en el saln del restaurante.
Medicin
Beneficios

El acceso se realizar desde los mdulos de mesa, situados en las mesas de los clientes.
Ninguno
R-11


Pgina 71

Requisitos
Ttulo Gestin de la cocina.
Descripcin La aplicacin permitir una gestin eficiente de los mdulos que se
encuentren en la cocina del restaurante.
Medicin
Beneficios

El acceso se realizar desde el mdulo de cocina, desde el cual se tendr acceso a informacin
detallada sobre las comandas y la disposicin de los clientes, as como de la facturacin.
Ninguno
R-10


Pgina 72

Requisitos
Ttulo Gestin de la publicidad.
Descripcin La aplicacin comprender una gestin eficiente de la publicidad,
compuesta por la promocin y sugerencias que ofrece el restaurante a
sus clientes.
Medicin
Este requisito se implantar en el mdulo de mesa de los clientes.
Beneficios
mayor funcionalidad y mejora del negocio para el restaurante.

La publicidad y sugerencias que desee realizar el restaurante, se mostrarn en los mdulos
de mesa directamente a los clientes, estimulando la demanda o vendiendo el espacio
publicitario a terceras empresas.
Ninguno
R-14


Pgina 73

Requisitos
Ttulo Gestin del personal.
Descripcin La aplicacin permitir una gestin eficiente de la gestin del personal
de restaurante, diferenciando entre el personal de cocina o el personal
de saln.
Medicin
El mdulo de gestin de personal se compondr de los mdulos de cocina y de saln,
diferenciando en ambos grupos los distintos trabajadores.
Beneficios

El sistema se compondr de un mdulo de cocina y de un mdulo de mesa, desde cada uno,
se tendr acceso a una informacin diferente y se gestionar el personal segn sea el acceso.
Ninguno
R-15 / R-16


Pgina 74

Requisitos
Ttulo Gestin de las sugerencias.
Descripcin La aplicacin comprender una gestin eficiente de las sugerencias
que desee hacer el chef a los clientes del restaurante.
Medicin
Este requisito se implantar en el mdulo de mesa de los clientes.
Beneficios

Las sugerencias que desee realizar el restaurante, se mostrarn en los mdulos de mesa
directamente a los clientes, estimulando la demanda.
Ninguno
Ninguno


Pgina 75

Requisitos
Ttulo Gestin del personal de cocina.
Descripcin La aplicacin permitir una gestin eficiente del personal de la cocina,
que estar compuesto por el chef y sus ayudantes.
Medicin
Beneficios

El sistema controlar el acceso del mdulo de cocina, y segn el perfil, los trabajadores
tendrn acceso a informacin especfica, como la gestin de las comandas o la gestin del
men virtual.
Ninguno
Ninguno


Pgina 76

Requisitos
Ttulo Gestin del personal de saln.
Descripcin La aplicacin permitir una gestin eficiente del personal de saln,
que estar compuesto por el encargado y los camareros.
Medicin
Beneficios

El sistema controlar el acceso del mdulo de cocina, y segn el perfil, los trabajadores
tendrn acceso a informacin especfica, como la gestin de la publicidad o la gestin del
men virtual.
Ninguno
Ninguno


Pgina 77

Requisitos
Ttulo Gestin de las tareas.
Descripcin La aplicacin permitir una gestin eficiente de las tareas pendientes
por realizar, y las tareas realizadas.
Medicin
Este requisito se implantar en el mdulo de cocina.
Beneficios

El sistema gestionar las tareas que no han sido an atendidas y aquellas que ya se han
atendido, se marcarn como satisfechas, permitiendo as una mejor gestin de las comandas
en la cocina.
Ninguno
Ninguno


Pgina 78

Requisitos
Ttulo Gestin de los restaurantes.
Descripcin La aplicacin permitir una gestin eficiente de los distintos
restaurantes en los cuales est implantado el sistema.
Medicin

Beneficios

El sistema permitir, en aquellos casos en los que existan varios restaurantes pertenecientes
a la misma empresa, imprimir la informacin sobre datos de los distintos negocios para su
posterior anlisis.
Ninguno
Ninguno


Pgina 79

Requisitos
Ttulo Gestin de los cobros.
Descripcin La aplicacin permitir una gestin eficiente de los distintos
restaurantes en los cuales est implantado el sistema.
Medicin
Beneficios

Este requisito se desarrollar en un mdulo de cocina. Debido a la multitud de datos
presentes en la base de datos de la aplicacin, los informes resultarn tiles a la direccin.
Ninguno
Ninguno
Ninguno


Pgina 80

Requisitos
Ttulo Login como precondicin de acceso al sistema.
Descripcin Para la realizacin de todas las operaciones que la aplicacin
permitir, se requerir el empleo de un login inicial que permita
conectarse a la misma slo los empleados registrados. De este modo,
se evitarn intrusismos.
Medicin
Beneficios
Gracias a la implementacin de este requisito se conseguir filtrar los accesos a la aplicacin
y se permitir una adaptacin de las tareas permitidas a los usuarios segn su perfil.

Para la verificacin del usuario y contrasea se acudir a la tabla de empleados en la que se
almacenan estos datos. La administracin del perfil se realizar segn esa misma tabla.

Ninguno
Ninguno


Pgina 81

Requisitos
Ttulo Gestin de los informes.
Descripcin La aplicacin crear informes sobre las comandas pendientes,
atendidas y los datos de la facturacin obtenida.
Medicin
Beneficios
Este requisito se desarrollar en un mdulo de cocina. Debido a la multitud de datos
presentes en la base de datos de la aplicacin, los informes resultarn tiles a la direccin.
Ninguno
R-07 / R-08
Ninguno


Pgina 82

3.6 Modelo lgico de datos

En este apartado se analiza el modelo lgico del nuevo sistema. Para su
obtencin se ha partido del anlisis del sistema actual y de la lista de
requisitos del sistema.

3.6.1 DFD contextual

A continuacin, se muestra el DFD contextual de la aplicacin a
desarrollar, donde se representa las entidades externas y el sistema.

El sistema se interrelacionar con dos tipos de usuarios diferentes,
ofrecindoles a cada uno una informacin diferente, y recibiendo
tambin unas entradas diferentes. Uno de los usuarios sern los
clientes que accedern desde el mdulo de mesa al men virtual y
realizarn sus comandas, y otro usuario ser el personal de cocina, que
atender las comandas, las editar segn se vayan atendiendo, y
adems tendrn acceso a otros mdulos del sistema que se han
especificado en la lista de requisitos anteriormente.

0
Sistema Integral
de Gestin de
Restaurantes
Usuario
cliente
Usuario
cocina
entradas
salidas
salidas entradas


Pgina 83

3.6.2 DFD conceptual

A continuacin, se muestra el DFD conceptual del sistema. Para mayor
claridad, se representar por niveles, lo que facilitar la comprensin
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 aplicacin, que se descompone
en los cuatro mdulos descritos a continuacin:

Men virtual: permitir mostrar el men de forma virtual,
actualizarlo, recibir sugerencias y promociones, enviar una
seleccin de comandas y mostrar el total a pagar despus de
haber consumido.

Comandas: se recibirn las comandas del men virtual, se
mostrarn por pantalla en el mdulo de cocina, y se guardarn en
una base de datos para sacar informes.

Publicidad: se usar este mdulo para aplicar promociones a los
clientes, mostrar sugerencias o publicidad en el men virtual

Informes: leer la informacin pertinente de la base de datos
para sacar estadsticas e informes de inters al gerente del
restaurante.


Pgina 84

1
Login
empleado
password
EMPLEADOS
2
Men principal
3
Publicidad
4
Men virtual
5
Comandas
6
Informes
SUGERENCIAS
MEN
COMANDAS
FACTURAS
comanda
factura
aviso cocina
men a cliente
sugerencia a cliente
informe
opcin


Pgina 85

En el diagrama anterior se ha representado el flujo de la informacin en
el sistema, a continuacin se detallan todos los componentes que
intervienen en el mismo:

1. Login: proceso que controla el acceso a la aplicacin, verificando
que el usuario que est entrando en el sistema, es un empleado,
segn los permisos que tenga tendr un acceso posterior para el
acceso de informes, y la insercin de publicidad, o bien slo la
visualizacin y edicin de comandas en el mdulo de cocina.

2. Men principal: ser el punto de partida de la aplicacin. Desde
este men se podrn 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 mostrarn a los clientes. Se detallar a
continuacin su funcionamiento a travs 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 envo de la comanda una vez
haya sido seleccionada. Se detallar a continuacin su
funcionamiento a travs de otro diagrama de flujo de datos.

5. Comandas: proceso que gestiona todas las comandas que
realizan los clientes y que se envan a la cocina, para
posteriormente mostrarlo en el mdulo. Adems, agrupar las
comandas de una misma mesa y las enviar a una base de datos
de facturas para posteriormente obtener informes. Se detallar a


Pgina 86

flujo de datos.

6. Informes: proceso que gestiona la obtencin de informes a partir
de comandas realizadas por los clientes. Se detallar a
flujo de datos.


Pgina 87

MINIESPECIFICACIONES

Tipo Nombre Atributos Descripcin
Proceso Login - Proceso encargado de
controlar el acceso a la
aplicacin.

Proceso Men principal - Proceso que genera un
men personalizado con
distintas opciones en
funcin del usuario y de
su perfil.

Proceso Publicidad - Proceso que gestiona las
sugerencias, promociones
y publicidad que se
mostrarn a los clientes.

Proceso Men virtual - Proceso que gestiona el
men virtual que se
mostrar a los clientes,
as como el envo de la
comanda una vez haya
sido seleccionada.

Proceso Comandas - Proceso que gestiona
todas las comandas que
realizan los clientes y que
se envan a la cocina,
para posteriormente


Pgina 88

mostrarlo en el mdulo.
Adems, 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
obtencin de informes a
partir de comandas
realizadas por los
clientes.
Flujo de
datos
Empleado - Clave de usuario.
Necesario para acceder a
la aplicacin.

Flujo de
datos
Password - Contrasea del usuario.
Flujo de
datos
Sugerencia a
cliente
- Envo al men virtual del
cliente, las sugerencias
del restaurante si
procede.

Flujo de
datos
Men a cliente - Impresin en el mdulo
de mesa, del men
confeccionado para el
cliente, con las
sugerencias pertinentes.

Flujo de Comanda - Envo de la comanda


Pgina 89

datos desde el mdulo de mesa
al mdulo de gestin de
comandas para su
registro.

Flujo de
datos
Aviso a cocina

- Envo de la comanda
registrada, al mdulo de
cocina.

Flujo de
datos
Factura - Envo 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 - Impresin de los informes
de carcter econmico al
gerente del restaurante.

Almacn de
datos
EMPLEADOS ID_EMP, PASS Registra las acciones
relacionadas con los
usuarios.

Almacn de
datos

SUGERENCIAS ID_SUG,
DESCR
Informacin sobre las
sugerencias que ofrece el
restaurante.
Almacn de
datos
MEN ID_PLATO,
INGRED,
DESC,
Informacin sobre el
men, y los ingredientes
de los que dispone el


Pgina 90

PRECIO_UNIT restaurante.

Almacn de
datos
COMANDAS MESA,
FECHA,
HORA,
ID_PLATO,
CANT
comandas que van
realizando los clientes y
que se visualizarn en la
cocina.

Almacn de
datos
FACTURAS ID_COMANDA,
TOTAL,
FECHA, HORA
Informacin sobre la
facturacin total del
restaurante, para cada
da.


Pgina 91

3.6.2.2 DFD conceptual de segundo nivel. Mdulo publicidad.

A continuacin, se muestra un diagrama del mdulo publicidad, que ha
sido anteriormente recogido en R-14 en la lista de requisitos:
3.1
Alta
sugerencia
3.2
Modificacin
sugerencia
3.3
Baja
sugerencia
3.4
Aplicar
sugerencia
SUGERENCIAS
sugerencia
Solicitud modificacin
Solicitud baja
Solicitud alta


Pgina 92


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
insercin en la base de
datos.

Proceso Modificacin
sugerencia
- Este proceso modifica
una sugerencia del
restaurante de la base de
datos. Necesita que el
administrador del sistema
enve la orden.

Proceso Baja sugerencia - Este proceso elimina una
sugerencia del
restaurante de la base de
enve la orden.

Proceso Aplicar
sugerencia
- Este proceso verifica las
promociones existentes
para los clientes, y en
caso de que exista
alguna, la enva al


Pgina 93

mdulo de mesa.

Flujo de
datos
Solicitud alta - Solicitud por parte del
de crear una nueva
sugerencia.

Flujo de
datos
Solicitud
modificacin
- Solicitud por parte del
de modificar una
sugerencia.

Flujo de
datos
Solicitud baja - Solicitud por parte del
de dar de baja una
sugerencia.

Flujo de
datos
Sugerencia - Envo de la sugerencia
encontrada, directamente
al cliente.

Almacn de
datos

SUGERENCIAS ID_PLATO,
SUGER
sugerencias que ofrece el
restaurante, con un
campo que identifica al
plato sugerido y la
descripcin que se
mostrar a los clientes.


Pgina 94

3.6.2.3 DFD conceptual de segundo nivel. Mdulo men virtual.

A continuacin, se muestra un diagrama del mdulo men
virtual, que ha sido anteriormente recogido en R-02 en la lista de
requisitos:

4.1
Procesar men
4.2
Alta men
4.3
Baja men
4.5
Enviar
seleccin
MEN
Solicitud baja
sugerencia
men
Solicitud alta
4.4
Modificacin
men
comanda


Pgina 95


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
datos.

Proceso Modificacin
men
- Este proceso modifica el
men del restaurante de
que el administrador del
sistema enve la orden.

Proceso Baja men - Este proceso elimina el
men del restaurante de

Proceso Procesar men - Este proceso muestra el
men al cliente, segn las
sugerencias particulares
que el restaurante le
ofrece, y despus guarda
la seleccin del usuario
para procesarla como


Pgina 96

comanda junto con otro
proceso.

Proceso Enviar seleccin - Este proceso enva 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
de crear un nuevo men.

Flujo de
datos
Solicitud
modificacin
de modificar el men.

Flujo de
datos
de dar de baja el men.

Flujo de
datos
Comanda - Envo de la comanda
realizada por el cliente,
directamente a la cocina.

Almacn de
datos

MEN ID_PLATO,
INGRED,
DESCR,
Informacin sobre los
platos que componen el
men y que se mostrar a


Pgina 97

URL,
PRECIO_UNIT
los clientes junto con su
descripcin
correspondiente, una url
del vdeo o foto
ilustrativo, ingredientes y
precio


Pgina 98

3.6.2.4 DFD conceptual de segundo nivel. Mdulo comandas.

A continuacin, se muestra un diagrama del mdulo comandas, que ha
5.1
Alta comanda
5.2
Baja comanda
COMANDAS
Solicitud baja
comanda
5.3
Modificacin
comanda
Comanda a cocina
5.4
Procesar
comanda


Pgina 99


Proceso Alta comanda - Este proceso da de alta la
comanda del cliente en la
una solicitud de alta
enviada por el cliente y el
resultado es una
datos.

Proceso Modificacin
comanda
- Este proceso modifica la
comanda del cliente de la

Proceso Baja comanda - Este proceso elimina la
comanda del cliente de la

Proceso Procesar
comanda
- Este proceso muestra la
comanda del cliente al
mdulo de cocina,
despus de haberse
guardado en la base de
datos, y a su vez, enva la


Pgina 100

comanda a otro proceso
para que se registre en la
base de datos de
facturacin para su
posterior estudio.

Flujo de
datos
Comanda - Recepcin por parte del
cliente de su comanda, y
registro en la base de
datos, despus se
mostrar en la cocina.

Flujo de
datos
Solicitud
modificacin
de modificar la comanda.
Flujo de
datos
de dar de baja una
comanda.

Flujo de
datos
Comanda a
cocina
- Impresin en el mdulo
de cocina, de la comanda,
y envo al mdulo de
facturacin la misma
para su proceso.

Almacn de
datos

COMANDAS ID_CLI,
MESA,
FECHA,
HORA,
ID_PLATO,
Informacin sobre la
comanda que ha realizado
el cliente, incluyendo un
nmero que le
identifique, su mesa, la


Pgina 101

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


Pgina 102

3.6.2.5 DFD conceptual de segundo nivel. Mdulo informes.

A continuacin, se muestra un diagrama del mdulo informes, que ha
6.1
Alta factura
6.2
Modificacin
factura
6.3
Baja factura
6.4
Informe
facturacin
FACTURAS
informe
Solicitud baja
Comanda a cocina


Pgina 103


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 insercin en la
base de datos.

Proceso Modificacin
factura
- Este proceso modifica
una factura de la base de
enve la orden.

Proceso Baja factura - Este proceso elimina una
factura de la base de
enve la orden.

Proceso Informe de
facturacin
- Este proceso imprime un
informe de la facturacin
del restaurante,
utilizando la informacin


Pgina 104

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
modificacin
de modificar una factura
de la base de datos.

Flujo de
datos
de dar de baja una
factura.

Flujo de
datos
Informe - Informe de facturacin
con todos los datos
correspondientes a la
actividad del restaurante.

Almacn de
datos

FACTURAS ID_CLI,
TOTAL,
FECHA,
HORA

facturas que ha realizado
el restaurante a sus
clientes, a partir de las
comandas.


Pgina 105

3.6.3 Modelo conceptual de datos.

El modelo conceptual de datos trata de modelar la gama de informacin
que manejar el nuevo sistema. Este modelo se obtiene a partir de la
situacin actual y de los requisitos previamente establecidos.

El modelo conceptual describe las caractersticas 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 especificacin de los componentes de ese
esquema.

Para la realizacin de esta metodologa se ha seguido el libro [BARR01]
que aparece en la bibliografa.

El modelo conceptual describe las entidades, atributos y relaciones de
inters para el negocio a representar. Este modelo deber ser
independiente del hardware y software utilizado para el manejo de los
datos.

Para la realizacin de este apartado se utilizar un mtodo de anlisis
de datos basado en el anlisis entidad-relacin que consta de los
siguientes elementos:

- Entidades. Son objetos que tienen una existencia propia
conforme a las decisiones de gestin de la empresa. Es


Pgina 106

aquello de inters duradero para la empresa, sobre lo cual
se pueden almacenar datos e identificar de un modo nico.

- Relaciones. Son las representaciones de asociacin entre
entidades. Las relaciones establecen el grado de asociacin
entre dos estructuras de datos diferentes.

- Atributos. Son caractersticas de una entidad que sirven
para definir, describir y clasificar.

Cabe destacar que, por motivos de optimizacin, las sugerencias se han
separado en una tabla aparte, en lugar de aadirse como atributo al
men ya que ser una informacin 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 diseado segn la metodologa estudiada, sin embargo la
especial complejidad del sistema residir en la funcionalidad y el trato
que se da a esta informacin.

A continuacin se representa el modelo entidad-relacin para el sistema
integral de gestin de restaurantes con sus respectivos atributos y
relaciones:


Pgina 107

-id_plato
-ingred
-desc
-url
-precio_unit
Men
-id_cli
-total
-fecha
-hora
Facturas
-id_cli
-mesa
-fecha
-hora
-id_plato
-cant
Comandas
-id_plato
-suger
Sugerencias
0..*
1 1
*
1 *

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 }


Pgina 108

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 explicara 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.

4) Estudio de la
arquitectura


Pgina 110

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
diseo. Para ello se propondrn dos alternativas evaluando las ventajas
e inconvenientes de cada una de ellas. Posteriormente, se elegir la ms
adecuada para ser desarrollada e implementada.

4.1 Especificacin de las alternativas

A continuacin se muestran las posibles soluciones que podran
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 mquina bastante potente que acta de
depsito 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.


Pgina 111

Una aplicacin informtica con arquitectura cliente-servidor consta de
dos programas:

El programa cliente, que se ejecuta en el ordenador que
interacta 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 aplicacin deben repartirse
entre ambos programas, en principio, de forma equitativa. Sin embargo,
por razones de viabilidad tcnica o econmica 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 cmputo est desplazada
hacia la computadora que ejecuta dicho programa.

Por ejemplo, en una arquitectura cliente servidor con un cliente
pesado, se realizaran as las tareas para el sistema integral de gestin
de restaurantes:

Cliente:


Pgina 112

o Representacin de los datos en la interfaz grfica.

o Proceso de login en el sistema (cifrado de conexin).

o Exportacin de datos a otros formatos.

o Impresin 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 Ejecucin de transacciones


Pgina 113

Para un posterior estudio de la mejor alternativa posible, que se
adaptar al sistema integral de gestin de restaurantes, se presentan a
continuacin las ventajas e inconvenientes del uso de una arquitectura
cliente-servidor con cliente pesado.

Mayor aprovechamiento de la capacidad de cmputo de los
ordenadores que lo ejecutan, generalmente infrautilizadas, en
favor del servidor. Dicho servidor asume menos funciones y, por
tanto, puede atender a un nmero mayor de programas cliente
con los mismos recursos.

Mejor desempeo multimedia. Los clientes pesados tienen
ventajas en aplicaciones ricas en multimedia que seran
intensivas en ancho de banda si estuvieran completamente
residentes en los servidores. Por ejemplo, los clientes pesados
estn bien adaptados para la edicin de vdeo.

Apropiado para conexiones de red pobres. Los clientes ligeros
pueden ser inusualmente lentos, o muy frustrantes para usar,
sobre una conexin de red de alta latencia. Por otra parte, no
trabajan en absoluto cuando la red est cada.

Riqueza en el interfaz de usuario. El interfaz no est limitado por
las caractersticas de un cliente universal, por ejemplo, un
navegador web. Por tanto, pueden disearse interfaces complejos,
ricos y ms fciles de usar.

Sin embargo, como inconvenientes cabe destacar:


Pgina 114

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 idnticos y pueden disponer de distinto software
de base, es posible que la aplicacin no funcione correctamente
en algunos lugares. En ocasiones, el diseador de la aplicacin no
conoce a priori cul es el perfil del ordenador que debe ejecutarlo.

Es necesaria una infraestructura para la instalacin y
actualizacin de la aplicacin de manera desatendida. Es inviable
realizar dichas tareas utilizando medios humanos cuando se trata
de cientos de ordenadores.

A continuacin se representa grficamente la arquitectura cliente-
servidor, donde a la izquierda aparecen los clientes, conectados con el
servidor, que contiene las bases datos, a travs de una red local:


Pgina 115


Pgina 116

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 ocurra en el servidor. Sin
embargo, dispositivos recientes etiquetados como clientes livianos
pueden correr sistemas operativos completos tales como Linux Debian,
calificndose como nodos sin disco o clientes hbridos. Algunos clientes
ligeros tambin son llamados "terminales de acceso".

Por consecuencia, el trmino "cliente ligero", en trminos de hardware,
ha venido a abarcar cualquier dispositivo usado como, un cliente ligero
en la definicin original, incluso si sus capacidades reales son mucho
mayores. El trmino tambin es a veces usado en un sentido incluso
ms 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


Pgina 117

servidor en tiempo de arranque, o segn lo que se necesite. Al
simplificar la carga en el cliente ligero, ste puede ser un dispositivo
muy pequeo y de baja energa, que da costos de compra y de operacin
ms bajos en cada puesto.

El servidor, o un clster 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 administracin de sistemas ms fcil y costos ms
bajos, as como todas las ventajas de la computacin en red:
almacenamiento y respaldo centralizados y una seguridad ms fcil.

Debido a que los clientes ligeros son numerosos pero relativamente
pasivos y de bajo mantenimiento, el sistema entero es ms simple y
ms fcil de instalar y operar. A medida que el costo del hardware baja
y el costo de emplear un tcnico y de energa, aumenta, las ventajas de
los clientes ligeros crecen. Por otro lado, desde la perspectiva del
usuario, la interaccin con el monitor, el teclado, y el ratn 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 gestin de restaurantes, se presenta a
continuacin las ventajas del uso de una arquitectura cliente-servidor
con cliente liviano.

Menores costes de administracin. Los clientes ligeros son
manejados casi enteramente en el servidor. El hardware tiene


Pgina 118

menos lugares donde puede fallar, el entorno local es altamente
restringido, y el cliente es ms simple y a menudo carece de
almacenamiento permanente, proporcionando proteccin contra
el malware.

Informacin centralizada. Como la informacin se encuentra en
un solo lugar facilita la realizacin de backups y evita que se
guarden archivos que no sean del negocio.

Ms fcil de asegurar. Los clientes livianos pueden ser diseados
de modo que ni siquiera los datos de aplicacin residan en el
cliente (apenas son exhibidos en la pantalla), centralizando la
proteccin contra el malware y reduciendo los riesgos de hurto de
los datos fsicos.

Seguridad de datos mejorada. Si un dispositivo del cliente ligero
sufre una seria desgracia o accidente de trabajo, no se perder
ningn dato, puesto que residen en el servidor y no en el
dispositivo de punto de operacin.

Costos de hardware ms bajos. El hardware del cliente ligero es
generalmente ms barato porque no contiene disco duro,
memoria de aplicaciones, o un procesador poderoso.
Generalmente tambin tienen un perodo ms largo antes de
requerir una mejora o llegar a ser obsoletos. Hay menos piezas
mviles y uno actualiza o mejora el servidor y la red en lugar de
los clientes, porque la limitacin en desempeo es la resolucin
de pantalla que tiene un ciclo de vida muy largo. Muchos clientes
pesados son reemplazados despus de 3 aos 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


Pgina 119

imgenes por 10 aos. Los requisitos totales de hardware para un
sistema de cliente ligero (incluyendo tanto servidores como
clientes) son generalmente mucho ms bajos comparados a un
sistema con clientes pesados. Una razn de esto es que el
hardware es mejor utilizado.

Una CPU en una estacin de trabajo pesada est ociosa la mayor parte
del tiempo. Con los clientes ligeros, los ciclos del CPU son compartidos.
Si varios usuarios estn corriendo la misma aplicacin, solo necesita
ser cargada una sola vez en un servidor central (si la aplicacin est
escrita para soportar esta capacidad). Con los clientes pesados, cada
estacin de trabajo debe tener en memoria su propia copia del
programa.

Menos consumo de energa. El hardware dedicado de cliente
ligero tiene un consumo de energa mucho ms bajo que los
tpicos PC de clientes pesados, ahorrando hasta un 80% de
electricidad y cuidando el medio ambiente. Esto no slo reduce
los costes de energa en los sistemas de computacin, 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 energa. Sin embargo, se requieren
servidores y sistemas de comunicaciones ms poderosos.

Mejor gestin 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
estn en el cliente.


Pgina 120

Operable en ambientes hostiles. La mayora de los clientes
livianos no tienen piezas mviles as que pueden ser usados en
ambientes polvorientos sin la preocupacin que puede haber con
la obstruccin de los ventiladores de los PC que pueden
recalentarlos y quemarlos.

Menos ancho de banda de la red. Puesto que los servidores de
terminales tpicamente residen en la misma espina dorsal de red
(backbone network) de alta velocidad que los servidores de
archivo, la mayor parte del trfico de red est confinado al cuarto
del servidor.

Uso ms eficiente de los recursos de computacin. Un tpico
cliente pesado ser especificado para hacer frente a la carga
mxima 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
computacin 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 correspondern muy probablemente a los bajos de uso de
otro.

Simple trayectoria de actualizacin de hardware. Si el pico de
recursos est sobre un lmite predefinido, es un proceso
relativamente simple agregar otro componente a un rack de
servidor (ya sea energa, 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,


Pgina 121

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 ms agradable y ms productivo.

Menos hardware desperdiciado. El hardware contiene metales
pesados y plsticos y requiere energa y recursos para ser
construido. Los clientes ligeros pueden permanecer en servicio
por ms tiempo y producen menos hardware excedente que una
equivalente instalacin de cliente pesado porque pueden ser
hechos sin partes mviles. 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 comunicacin entre clientes
livianos y servidores son:

X Window System (tambin conocido como X o X11) usado
esencialmente por variantes de Unix.

Tecnologa NX comprime el protocolo X11 para mejores
prestaciones.


Pgina 122

Computacin 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 continuacin se representa grficamente la arquitectura cliente-
servidor, donde a la izquierda aparecen los clientes, conectados con el
servidor, que contiene las bases datos, a travs de una red local:


Pgina 123

4.1.2 Lenguajes de programacin para los clientes

En este apartado se estudian las diferentes alternativas de lenguajes de
programacin que se podran utilizar en los mdulos de mesa como en
el mdulo de cocina.

Posteriormente, una vez realizado el estudio, se elegir la alternativa
que se adece mejor al sistema.

4.1.2.1 Lenguaje C

C es un lenguaje de programacin creado en 1972 por Dennis M.
Ritchie en los Laboratorios Bell como evolucin del anterior lenguaje B,
a su vez basado en BCPL.

Al igual que B, es un lenguaje orientado a la implementacin
de Sistemas Operativos, concretamente Unix. C es apreciado por la
eficiencia del cdigo que produce y es el lenguaje de programacin ms
popular para crear software de sistemas, aunque tambin se utiliza
para crear aplicaciones.

Se trata de un lenguaje dbilmente tipificado de medio nivel pero con
muchas caractersticas de bajo nivel. Dispone de las estructuras tpicas
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


Pgina 124

mezclar cdigo en ensamblador con cdigo C o acceder directamente a
memoria o dispositivos perifricos.

Hecho principalmente para la fluidez de programacin en sistemas
UNIX. Se usa tambin para el desarrollo de otros sistemas operativos
como Windows o Linux. Igualmente para aplicaciones de escritorio
como OpenOffice.org, cuyo principal lenguaje de programacin es C.

De la misma forma, es muy usado en aplicaciones cientficas (para
experimentos informticos, fsicos, qumicos, matemticos, entre otros,
parte de ellos conocidos como modelos y simuladores), industriales
(industria robtica, ciberntica, sistemas de informacin y base de
datos para la industria petrolera y petroqumica). Predominan tambin
todo lo que se refiere a simulacin de mquinas de manufactura,
simulaciones de vuelo (es la ms 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
caractersticas de bajo nivel para realizar implementaciones
ptimas.


Pgina 125

A pesar de su bajo nivel es el lenguaje ms portado en existencia,
habiendo compiladores para casi todos los sistemas conocidos.

Proporciona facilidades para realizar programas modulares y/o
utilizar cdigo o bibliotecas existentes.

Sin embargo, como inconvenientes se encuentran:

Existe una gran diferencia en velocidad de desarrollo: es mucho
ms lento programar en C. La razn estriba en que el compilador
de C se limita a traducir cdigo sin apenas aadir nada. La
gestin de la memoria es un ejemplo clsico: en C el programador
ha de reservar y liberar la memoria explcitamente. 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 difcil y costoso que con lenguajes de ms
alto nivel. El cdigo en C se presta a sentencias cortas y
enrevesadas de difcil interpretacin. Aunque el lenguaje admite
cdigo escrito de forma fcilmente legible, si no se siguen normas
en el equipo de programacin algunos programadores pueden
acabar escribiendo cdigo difcil de leer. Esto complica la revisin
y el mantenimiento.

C no dispone de sistemas de control automticos y la seguridad
depende casi exclusivamente de la experiencia del programador.
La mayor parte de los problemas de seguridad en los sistemas
informticos actuales deriva de haber sido realizados en C. El
fallo de seguridad clsico consiste en que algunas entradas de


Pgina 126

informacin al programa no se comprueban en longitud. Si un
atacante introduce datos lo bastante grandes puede provocar la
sobreescritura de cdigo en la pila del programa e incluso llegar a
forzar la ejecucin de cdigo pernicioso. Los lenguajes de tipo
dinmico cuentan con controles de gestin de memoria y de
entrada de datos automticos.


Pgina 127

4.1.2.2 Java

Java es un lenguaje de programacin orientado a objetos desarrollado
por Sun Microsystems a principios de los aos 90. El lenguaje en s
mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de
objetos ms simple y elimina herramientas de bajo nivel, que suelen
inducir a muchos errores, como la manipulacin directa de punteros o
memoria.

Las aplicaciones Java estn tpicamente compiladas en un bytecode,
aunque la compilacin en cdigo mquina nativo tambin es posible. En
el tiempo de ejecucin, el bytecode es normalmente interpretado o
compilado a cdigo nativo para la ejecucin, aunque la ejecucin directa
por hardware del bytecode por un procesador Java tambin es posible.

La implementacin original y de referencia del compilador, la mquina
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 evolucin del lenguaje a travs del Java
Community Process, si bien otros han desarrollado tambin
implementaciones alternativas de estas tecnologas 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 tecnologas Java bajo la licencia GNU GPL, de
acuerdo con las especificaciones del Java Community Process, de tal
forma que prcticamente todo el Java de Sun es ahora software


Pgina 128

libre (aunque la biblioteca de clases de Sun que se requiere para
ejecutar los programas Java an no lo es).

El lenguaje Java se cre con cinco objetivos principales:

1. Debera usar la metodologa de la programacin orientada a
objetos.

2. Debera permitir la ejecucin de un mismo programa en mltiples
sistemas operativos.

3. Debera incluir por defecto soporte para trabajo en red.

4. Debera disearse para ejecutar cdigo en sistemas remotos de
forma segura.

5. Debera ser fcil 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 mquina.


Pgina 129

Java es un lenguaje orientado a objetos. Por tanto todas las
ventajas que ofrece esta tcnica las contiene Java.

Los browser compatibles con Java no necesitan la instalacin de
plug-ins adicionales.

Los inconvenientes ms importantes de Java, son:

Los programas son lentos. Java, al ser un lenguaje interpretado
nunca ser tan rpido como un programa ejecutable.

Para la gente que no conoce Java deber de estudiar el lenguaje
para sacarle todo el partido.

Aunque lleva varios aos desde su origen, su optimizacin no es
tan grande como la de otros lenguajes que llevan ms aos.

Desde la creacin de la especificacin J2ME (Java 2 Platform, Micro
Edition), una versin del entorno de ejecucin Java reducido y
altamente optimizado, especialmente desarrollado para el mercado de
dispositivos electrnicos de consumo se ha producido toda una
revolucin en lo que a la extensin de Java se refiere.

Es posible encontrar microprocesadores especficamente diseados para
ejecutar bytecode Java y software Java para tarjetas inteligentes
(JavaCard), telfonos mviles, buscapersonas, set-top-boxes,
sintonizadores de TV y otros pequeos electrodomsticos.


Pgina 130

Hoy en da existen multitud de aplicaciones grficas de usuario basadas
en Java. El entorno de ejecucin Java (JRE) se ha convertido en un
componente habitual en los PC de usuario de los sistemas operativos
ms usados en el mundo. Adems, muchas aplicaciones Java lo
incluyen dentro del propio paquete de la aplicacin de modo que se
ejecuten en cualquier PC.


Pgina 131

4.1.2.3 Microsoft Visual Basic

Visual Basic es un lenguaje de programacin desarrollado para
Microsoft. Visual Basic constituye un IDE (entorno de desarrollo
integrado o en ingls Integrated Development Enviroment) que ha sido
empaquetado como un programa de aplicacin, es decir, consiste en un
editor de cdigo (programa donde se escribe el cdigo fuente), un
depurador (programa que corrige errores en el cdigo fuente para que
pueda ser bien compilado), un compilador (programa que traduce el
cdigo fuente a lenguaje de mquina), y un constructor de interfaz
grfica o GUI (es una forma de programar en la que no es necesario
escribir el cdigo para la parte grfica del programa, sino que se puede
hacer de forma visual).

Las versiones de Visual Basic para Windows son muy conocidas, pero
existe una versin de Microsoft Visual Basic 1.0 para MS-
DOS (ediciones Profesional y Estndar) menos difundida y que data de
1992. Era un entorno que, aunque en modo texto, inclua un diseador
de formularios en el que se podan arrastrar y soltar distintos controles.

La versin 6.0 contina utilizndose masivamente y es casi compatible
prcticamente 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.


Pgina 132

Cabe mencionar que aunque menos conocido, existi tambin una
versin gratuita de Visual Basic 5.0 dedicada en su prctica 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 rpida.

Se integra el diseo e implementacin de formularios de
Windows.

Se permite usar con suma facilidad la plataforma de los sistemas
Windows.

El cdigo en Visual Basic es fcilmente migrable a otros
lenguajes.

Como inconvenientes se encuentran:

Sin soporte de Microsoft desde el 4 de abril de 2008.

No es multiplataforma.


Pgina 133

Por defecto se permite la programacin sin declaracin de
variables (que puede ser sencillamente corregida escribiendo la
frase Option Explicit en el encabezado de cada formulario).

No se permite programacin a bajo nivel ni incrustar secciones de
cdigo en ASM.

Slo se permite el uso de funciones de libreras dinmicas (DLL)
stdcall.

Algunas funciones estn 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 dinmica, 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 lmites en
matrices entre otros, dejando as ms de la mano del
programador la tarea de controlar dichos errores)

No se tiene instrucciones de preprocesamiento.


Pgina 134

El tratamiento de mensajes de Windows es bsico 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
aplicacin. 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.


Pgina 135

4.1.3 Lenguajes de programacin para el servidor

En este apartado se estudian las diferentes alternativas de lenguajes de
programacin que se podra utilizar en el servidor.

Posteriormente, una vez realizado el estudio, se elegir la alternativa
que se adece mejor al sistema.

4.1.3.1 Active Server Pages

Active Server Pages (ASP) es una tecnologa de Microsoft del tipo "lado
del servidor" para pginas web generadas dinmicamente, que se ha
comercializado como un anexo a Internet Information Services.

La tecnologa ASP est estrechamente relacionada con el modelo
tecnolgico de su fabricante. Intenta ser solucin para un modelo de
programacin rpida ya que programar en ASP es como programar en
Visual Basic, por supuesto con muchas limitaciones.

Lo interesante de este modelo tecnolgico 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 interaccin de los scripts con el servidor SMTP que
integra IIS.


Pgina 136

Se facilita la programacin de sitios web mediante varios objetos
integrados, como por ejemplo un objeto de sesin basada en cookies,
que mantiene las variables mientras se pasa de pgina a pgina.


Pgina 137

4.1.3.2 PHP

PHP es un acrnimo recursivo que significa PHP Hypertext Pre-
processor (inicialmente PHP Tools, o, Personal Home Page Tools). Es un
lenguaje de programacin interpretado, diseado originalmente para la
creacin de pginas web dinmicas. Es usado principalmente en
interpretacin del lado del servidor (server-side scripting) pero
actualmente puede ser utilizado desde una interfaz de lnea de
comandos o en la creacin de otros tipos de programas incluyendo
aplicaciones con interfaz grfica usando las bibliotecas Qt o GTK+.

Algunas ventajas que presenta PHP son:

Es un lenguaje multiplataforma.

Completamente orientado a la web.

Capacidad de conexin con la mayora 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 mdulos (llamados ext's o extensiones).


Pgina 138

Posee una amplia documentacin en su pgina oficial, entre la
cual se destaca que todas las funciones del sistema estn
explicadas y ejemplificadas en un nico archivo de ayuda.

Es libre, por lo que se presenta como una alternativa de fcil
acceso para todos.

Se permite usar las tcnicas de Programacin Orientada a
Objetos.

No se requiere definicin de tipos de variables aunque sus
variables se pueden evaluar tambin por el tipo que estn
manejando en tiempo de ejecucin.

Manejo de excepciones (desde PHP5).

Si bien en PHP no se obliga a quien lo usa a seguir una
determinada metodologa 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
tcnica de programacin y/o desarrollo que le permita escribir
cdigo ordenado, estructurado y manejable. Un ejemplo de sto
son los desarrollos que en PHP se han hecho del patrn de diseo
Modelo Vista Controlador (o MVC), que permiten separar el
tratamiento y acceso a los datos, la lgica de control y la interfaz
de usuario en tres componentes independientes.


Pgina 139

Como desventajas se encuentra:

La ofuscacin de cdigo es la nica forma de ocultar los fuentes


Pgina 140

4.1.3.3 Java Server Pages

JavaServer Pages (JSP) es una tecnologa Java que permite generar
contenido dinmico para web, en forma de documentos HTML, XML o
de otro tipo.

Esta tecnologa es un desarrollo de la compaa Sun Microsystems. La
Especificacin JSP 1.2 fue la primera que se liber y en la actualidad
est disponible la especificacin JSP 2.1.

En JSP's se permite la utilizacin de cdigo Java mediante scripts.
Adems, es posible utilizar algunas acciones JSP predefinidas mediante
etiquetas. Estas etiquetas pueden ser enriquecidas mediante la
utilizacin de Libreras 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 pgina JSP puede hacer todo lo que un servlet
puede hacer, y viceversa. Cada versin de la especificacin de JSP est
fuertemente vinculada a una versin en particular de la especificacin
de servlets.


Pgina 141

El funcionamiento general de la tecnologa JSP es que el Servidor de
Aplicaciones interpreta el cdigo contenido en la pgina JSP para
construir el cdigo Java del servlet a generar.

Este servlet ser el que genere el documento (tpicamente HTML) que se
presentar en la pantalla del navegador del usuario.

El rendimiento de una pgina JSP es el mismo que tendra el servidor
equivalente, ya que el cdigo es compilado como cualquier otra clase
Java. A su vez, la mquina virtual compilar dinmicamente a cdigo de
mquina las partes de la aplicacin que lo requieran. Esto hace que JSP
tenga un buen desempeo y sea ms eficiente que otras tecnologas web
que ejecutan el cdigo de una manera puramente interpretada.

Como ventajas principales cabe destacar:

El lenguaje Java es un lenguaje de propsito general que excede
el mundo web y que es apto para crear clases que manejen lgica
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 mltiples plataformas sin cambios. Es comn
incluso que los desarrolladores trabajen en una plataforma y que
la aplicacin termine siendo ejecutada en otra.


Pgina 142

Como inconvenientes, se encuentran los ya comentados anteriormente
en referencia al lenguaje de programacin java.


Pgina 143

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 podran utilizar para implantar el
sistema, y posteriormente, se elegir una como solucin.

4.1.4.1 Oracle

Oracle es un sistema de gestin de base de datos relacional (o RDBMS
por el acrnimo en ingls de Relational Data Base Management
System), desarrollado por Oracle Corporation.

Se considera a Oracle como uno de los sistemas de bases de datos ms
completos, tiene como caractersticas principales:

Soporte de transacciones.

Estabilidad.

Escalabilidad.

Soporte multiplataforma.


Pgina 144

Ha sido criticada por algunos especialistas la seguridad de la
plataforma, y las polticas 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 gestin de bases de datos
relacionales (SGBD) basado en el lenguaje Transact-SQL, y
especficamente en Sybase IQ, capaz de poner a disposicin de muchos
usuarios grandes cantidades de datos de manera simultnea, as como
de disponer de las siguientes ventajas:

Soporte de transacciones.

Escalabilidad, estabilidad y seguridad.

Soporta procedimientos almacenados.

Incluye tambin un potente entorno grfico de administracin,
que permite el uso de comandos DDL y DML grficamente.


Pgina 145

Permite trabajar en modo cliente-servidor, donde la informacin
y datos se alojan en el servidor y los terminales o clientes de la
red slo acceden a la informacin.

Adems permite administrar informacin de otros servidores de
datos.


Pgina 146

4.1.4.3 MySQL

MySQL es un sistema de gestin de base de datos relacional, multihilo y
multiusuario con ms 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
especfica 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 aplicacin web est muy ligada a PHP, que a menudo aparece en
combinacin con MySQL. MySQL es una base de datos muy rpida en
la lectura cuando utiliza el motor no transaccional MyISAM. En
aplicaciones web hay baja concurrencia en la modificacin de datos y
en cambio el entorno es intensivo en lectura de datos, lo que hace a
MySQL ideal para este tipo de aplicaciones.


Pgina 147

4.1.5 Sistemas operativos

En este apartado se estudian las diferentes alternativas de sistemas
operativos que se podran utilizar para implantar en el servidor, y
posteriormente, se elegir uno como solucin.

4.1.5.1 Windows Server 2008 R2

Windows Server 2008 es el nombre de un sistema operativo diseado
para servidores de Microsoft. Es el sucesor de Windows Server 2003,
distribuido al pblico casi cinco aos antes. Al igual que Windows
Vista, Windows Server 2008 se basa en el ncleo Windows NT6.0.
Posteriormente se lanz una segunda versin, 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 ttulo
oficial (Windows Server 2008) durante su discurso de apertura en
WinHEC. El Windows Aero, est deshabilitado y usa la interfaz clsica
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 pblico el 25 de abril de 2007. Su lanzamiento fue el 27 de febrero de
2008.


Pgina 148

Hay algunas diferencias (unas sutiles y otras no tanto) con respecto a la
arquitectura del nuevo Windows Server 2008, que pueden cambiar
drsticamente 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 ms
efectiva, se puede controlar mucho mejor de forma remota y cambiar de
forma radical la poltica de seguridad. Entre las mejoras que se
incluyen, estn:

Nuevo proceso de reparacin de sistemas NTFS: proceso en
segundo plano que repara los archivos daados.

Creacin de sesiones de usuario en paralelo: reduce tiempos de
espera en los Terminal Services y en la creacin de sesiones de
usuario a gran escala.

Cierre limpio de Servicios.

Sistema de archivos SMB2: de 30 a 40 veces ms rpido el acceso
a los servidores multimedia.

Address Space Load Randomization (ASLR): proteccin contra
malware en la carga de controladores en memoria.

Server Core: el ncleo del sistema se ha renovado con muchas y
nuevas mejoras.


Pgina 149

4.1.5.2 Mandriva Linux

Mandriva Linux es una distribucin Linux destinada tanto para
principiantes como para usuarios experimentados, que ofrece
un sistema operativo orientado a computadoras personales y tambin
para servidores con un enfoque a los usuarios que se estn
introduciendo al mundo de Linux y al software libre adems por tener
una amplia gama y comunidad de desarrolladores, es adecuada para
todo tipo de variedad de necesidades: estaciones de trabajo, creacin de
clsteres, servidores, firewalls, etc. Es una de las distribuciones de
Linux referentes a nivel mundial.

Como caractersticas principales, se encuentran:

Internacionalizacin: disponible en 74 idiomas.

Instalacin control y administracin: el instalador de Mandriva
Linux es uno de los ms amigables de entre las diferentes
distribuciones de Linux, cabe destacar que Mandrake (ahora
Mandriva) fue la primera distribucin en incluir un instalador
grfico. En su primera versin el instalador present algunos
problemas con la resolucin de dependencias, cosa que ya est
solucionada.

Paquetes de software abundantes: viene con aproximadamente
205609 paquetes de software incluyendo juegos, programas de
oficina, multimedia, grficos, servidores y utilidades de Internet.


Pgina 150

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 versin 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 mximo su negocio, exprimiendo todas las novedades en
seguridad de redes y muchas ms cosas. Sun fabrica hardware libre,
como lo es la tecnologa SPARC.

Solaris 10 es la versin ms 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.


Pgina 151

4.2 Evaluacin de las alternativas

La evaluacin de las alternativas se realiza en base a aspectos de
inters que se consideran fundamentales para el buen funcionamiento
de la aplicacin. No slo de valoran caractersticas relacionadas con el
rendimiento, sino tambin con el coste, la rapidez con la que se
resuelven agujeros de seguridad, posibilidad de aadir nueva
funcionalidad, etc.

4.2.1 Evaluacin de la arquitectura

Al tratarse de una aplicacin que deben de usar mltiples 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 ms 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 ms
usuarios.

Menor coste del equipo servidor.


Pgina 152

Las desventajas del cliente pesado son:

Dificultad a la hora de actualizar los equipos clientes.

Posible fuente de problemas al existir diferente configuracin 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:


Pgina 153

Es necesario una mquina ms potente que las dems en el
servidor.

Si el servidor falla, ningn cliente podr acceder a la aplicacin.
Esto se resuelve con una buena planificacin y la redundancia de
sistemas.


Pgina 154

4.2.2 Evaluacin del sistema operativo

A la hora de evaluar el sistema operativo elegido hay que tener en
cuenta las consecuencias de dicha decisin 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 ampliacin de funcionalidades, integracin con otros
sistemas, y frecuencia con la que se detectan vulnerabilidades.

Windows server
2008
Mandriva Linux Solaris 10
Coste

Alto Bajo Medio
Ampliacin de
funcionalidades

Medio Alta Medio
Integracin

Alta Alta Alta
Frecuencia de
vulnerabilidades

Media Baja Baja
Complejidad de
uso
Bajo Medio Medio


Pgina 155

4.2.3 Evaluacin del lenguaje de programacin en el cliente

Para determinar el mejor lenguaje de programacin en el lado del cliente
se deben examinar a fondo los requerimientos que va a necesitar la
aplicacin. Visual Basic es un lenguaje muy fcil de aprender sin
embargo slo funciona en plataformas Windows. Java es ms
complicado de aprender y requiere mucho trabajo para desarrollar
elementos grficos, sin embargo destaca su extraordinaria portabilidad.
Esta caracterstica permite que un programa escrito en Java pueda ser
ejecutado en diferentes plataformas.

Se analiza el coste, la posibilidad de ampliar funcionalidades, el nmero
de expertos que conocen este lenguaje en caso de un futuro
mantenimiento, y el potencial de uso, que mejor permita adaptarse al
sistema requerido.


Pgina 156

Java

VisualBasic C
Coste

Gratuito 100 licencia
estudiante
Gratuito
Ampliacin de
funcionalidades

Alto Bajo Bajo
Expertos que
conocen el
lenguaje

Alto Medio Alto
Potencial de uso

Alto Medio Medio


Pgina 157

4.2.4 Evaluacin del lenguaje de programacin en el servidor

Para la eleccin de una arquitectura basada en cliente servidor, ser
necesario determinar el lenguaje de programacin del lado del servidor
ms adecuado para la aplicacin.

Se usan los mismos criterios de evaluacin que para los lenguajes de
programacin del lado cliente.

JSP

ASP PHP
Coste

Gratuito Gratuito Gratuito
Ampliacin de
funcionalidades

Alto Bajo Bajo
Expertos que
conocen el
lenguaje

Alto Medio Alto
Potencial de uso

Alto Medio Medio


Pgina 158

4.2.5 Evaluacin del sistema gestor de bases de datos

Independientemente de la arquitectura elegida, esta aplicacin deber
guardar los datos de los distintos usuarios. Para determinar cul es el
gestor de base de datos ms idneo se utilizarn los siguientes criterios:
coste, soporte de transacciones, soporte tcnico y concurrencia.

Cabe destacar que MySQL tiene un soporte tcnico 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 crticas, y en MySQL medio ya que necesita de una
mquina potente.

SQL Server

Oracle MySQL
Coste

Alto Alto Gratuito
Soporte de
transacciones

Medio Alto Medio
Soporte tcnico

Alto Alto Bajo
Concurrencia

Medio Alto Medio


Pgina 159

4.3 Seleccin de la alternativa

Despus de analizar las distintas opciones se selecciona la alternativa
basada en una arquitectura de cliente/servidor con un cliente ligero, ya
que ser ms fcil de centralizar la informacin y es la arquitectura ms
adecuada cuando sern varios los clientes que realicen transacciones a
la vez.

Respecto al servidor web, se ha seleccionado nicamente Apache
Tomcat, debido a su amplia difusin en la comunidad y su carcter
gratuito. Se trata de un servidor http multiplataforma de cdigo abierto
con un nivel de seguridad aceptable, se usar principalmente para
cargar los vdeos e imgenes que cada restaurante quiera mostrar a sus
clientes.

El sistema operativo seleccionado ser Windows, para tener el acceso a
la informacin de forma centralizada, sencillez y familiaridad con este
sistema.

El lenguaje de programacin tanto en el cliente como en el servidor,
ser Java J2EE, debido a su gratuidad, simplicidad, su orientacin a
objetos, carcter distribuido e interpretado, robustez, arquitectura
neutral, seguridad, portabilidad y posibilidad de ejecucin multihilo.

Como sistema gestor de bases de datos, el ms adecuado para el
sistema ser MySQL, debido a su coste gratuito, escalabilidad y
flexibilidad (maneja bases de datos empotradas ocupando slo 1MB, y


Pgina 160

es soportado en UNIX, Linux y Windows), alto rendimiento,
disponibilidad, facilidad de gestin y fuerte proteccin de datos.

5) Diseo externo


Pgina 162

5. DISEO EXTERNO

En esta etapa del proyecto se va a realizar la secuencia de actividades
que en la metodologa en cascada se recoge bajo el nombre de diseo
externo. Por tanto, se van a tratar diferentes aspectos como las
fronteras de mecanizacin, especificacin de procesos, entradas y
salidas, etc.

5.1 Entorno operativo

A continuacin se procede a representar de forma simplificada el
funcionamiento general del sistema:

Men virtual, sugerencias,
factura...

Comandas

Consulta facturacin, edicin del men,
insercin de publicidad...

Usuarios
clientes
Usuarios en
cocina

Sistema Integral
de Gestin de
Restaurantes


Pgina 163

5.2 Fronteras de mecanizacin

Teniendo en cuenta los estudios realizados previamente, se decide
mecanizar todas aquellas funciones que aparecen en el DFD del nuevo
sistema, ya que una ampliacin de esas excedera los lmites del
proyecto.

5.3 Especificacin de procesos

En este apartado, se estudian los procesos que componen la aplicacin.
A continuacin, se muestra un esquema general de la aplicacin, tanto
en su parte pblica como privada. Para la elaboracin de este apartado
se han seguido consejos de los libros [WESL99] y [LARM03].

Se representa en el diagrama a continuacin 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 pblico, que todos los clientes podrn ver,
que incluye la carta virtual con sus sugerencias y la funcin de realizar
comandas.

Por otro lado, existe un men privado, al que slo tendr acceso el
personal del restaurante mediante un login, que incluye la posibilidad
de editar el men que se muestra a los clientes, la funcin de insercin
de publicidad o sugerencias, la visualizacin de las comandas que los


Pgina 164

clientes realizan y la funcin de muestra de informes sobre la
facturacin del restaurante.

Todas estas funciones, se representan en el siguiente esquema:

Inicio Edicin de comandas

Men pblico Administracin Men privado

Ver carta Realizar comanda Publicidad Informes

Como se puede comprobar, la pantalla de administracin permite un
acceso personalizado a la aplicacin privada. En funcin del puesto se
permite un acceso a los siguientes mdulos de la aplicacin.


Pgina 165

Gerente

Personal de
saln
Personal de
cocina
Clientes
Ver carta
virtual

Realizar
comanda

Edicin de
comandas

Publicidad y
sugerencias

Informes

Se han especificado en este apartado los grandes mdulos que
descomponen la aplicacin, y los accesos a los distintos mdulos segn
el usuario que se conecte al sistema.


Pgina 166

5.4 Diseo de interfaces

En este apartado se recogen los interfaces de que constar la
aplicacin. Se realiza un anlisis detallado de todas las pantallas, con
sus funcionalidades completas.

Cabe destacar que el diseo de la aplicacin se ha hecho para una
interfaz tctil y es por eso que los botones son ms 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 aplicacin. Los clientes, no ven esta pantalla, ya que no tienen que
realizar ningn login. Segn los permisos de los que dispongan los
empleados, podrn acceder a unas funciones u otras, pero siempre es
necesario realizar una identificacin mediante usuario y contrasea.


Pgina 167

5.4.2 Men privado

Una vez que se ha accedido como empleado, se podr tener acceso a
unos mdulos u otros en funcin 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 contrasea que le
diferencie del resto de personal, podr tener acceso a cuatro mdulos
distintos: comandas, publicidad, carta virtual e informes.


Pgina 168

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 visin del mdulo de cocina, que se arranca al principio de la
actividad del restaurante para poder visualizar las comandas que llegan
de los clientes.


Pgina 169

5.4.2.3 Men privado introducir sugerencias

A continuacin se muestra la apariencia del men privado introducir
sugerencias al que slo puede acceder el chef o el gerente del
restaurante.

Las sugerencias que introduzca aqu, se guardarn en la base de datos,
y posteriormente se mostrar en el men virtual a los clientes.

El nmero de sugerencia coincidir con el nmero de plato al que se le
aplica.


Pgina 170

5.4.2.4 Men privado visualizar comandas

A continuacin se muestra el aspecto del mdulo de cocina. Los
empleados ven las comandas que envan 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.


Pgina 171

5.4.2.5 Men privado editar carta virtual

Este es el men que aparece para el gerente o el chef en el mdulo de
cocina, si desean modificar la informacin 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
nmero de plato, o bien se puede editar la informacin sobre los
ingredientes, descripcin y precio y adems se puede aadir
opcionalmente la url del vdeo o imagen que se mostrar a los clientes
sobre su preparacin detallada.


Pgina 172

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
facturacin del restaurante, o sobre los platos ms vendidos.

Y a continuacin el informe sobre los platos ordenados de ascendente
segn el nmero de ventas:


Pgina 173

5.4.3 Men pblico

En este caso se representa el men que visualizarn los clientes en el
mdulo de mesa, se presenta primeramente una ventana de bienvenida,
y a continuacin la carta completa con la posibilidad de acceder, en
cada plato, a informacin ms detallada con imgenes o vdeos.

5.4.3.1 Pantalla de bienvenida

Este es el aspecto de la pantalla de bienvenida que encontrarn los
clientes en su mdulo de mesa.


Pgina 174

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 informacin
ms detallada se muestra una segunda ventana con vdeos o imgenes.


Pgina 175

5.4.3.3 Informacin detallada

La siguiente figura muestra la informacin detallada a la que pueden
acceder los clientes, a travs del men virtual, al pulsar sobre el botn
ms informacin al lado de cada plato en el men.

Se puede ver una descripcin ms extensa sobre el plato, una imagen
de su aspecto, o un vdeo de su preparacin.


Pgina 176

5.5 Procesos de seguridad

El sistema cuenta con las medidas de seguridad que garantizan la
autenticacin de los usuarios, la autorizacin en los procesos de
consulta y modificacin de la informacin 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 diseado el proceso de
login, que permite un acceso personalizado a la aplicacin a partir de
un nombre de usuario y password.

Segn el tipo de empleado que acceda, tendr permiso para acceder a
una informacin u otra, mientras que los clientes, solo tendrn acceso a
la carta virtual y a realizar las comandas.

6) Diseo interno


Pgina 178

6. DISEO INTERNO

En la fase de Diseo Interno, se realiza una ltima caracterizacin de la
aplicacin, antes de iniciar la fase de Programacin. Para ello, se debe
centrar el trabajo en los dos elementos fundamentales del sistema
informtico a desarrollar: Procesos y entidades.

Para ello se estudia en este apartado, un diseo interno de los procesos
a travs de diagramas HIPO y STC y posteriormente el estudio de las
tablas que componen la base de datos. Para la elaboracin de este
captulo se ha empleado la referencia bibliogrfica [ESQU08].

6.1 Diseo interno de programas

A continuacin se representan los diagramas HIPO de los diferentes
procesos.


Pgina 179

6.1.1 Diagrama HIPO Administracin de empleados

A continuacin se representa el diagrama HIPO del login de empleados.

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 aplicacin; en caso contrario, se
denegar.

ID_EMP

PASS

EMPLEADOS
LOGIN
ACCESO/NO
ACCESO


Pgina 180

6.1.2 Diagrama HIPO Alta comanda

A continuacin se muestra el diagrama HIPO que permite dar de alta
una comanda en la base de datos de facturas el sistema.

SUGERENCIAS
COMANDAS MENU

SELECCIN

SELECCIN

SELECCIN
FACTURAS
COMANDAS-
SELECCIN
MEN-
SELECCIN
SUGERENCIAS-
SELECCIN
Salida Total

GUARDAR


Pgina 181

6.1.3 Diagrama STC Administracin de empleados

Como se puede observar en el siguiente diagrama, el proceso de login
requiere la introduccin de nombre de usuario y password, con sus
respectivas comprobaciones.

ENTRADA VALIDAR
INTRODUCIR
NOMBRE DE
USUARIO
INTRODUCIR
PASSWORD
CAPTAR DATOS
ADMINISTRACIN
VERIFICAR
DATOS
RESPUESTA
ACCESO
AUTORIZADO
ACCESO
DENEGADO

error
id_emp
error
id_emp
id_emp
id_emp
error
password
password
id_emp
error
id_emp
error
error
id_emp


Pgina 182

6.2 Modelo fsico de la base de datos

En las siguientes tablas se representa el diseo interno de la base de
datos.

TABLA

Atributos

Tipo
Facturas
ID_CLI INTEGER

TOTAL

DOUBLE
FECHA

DATE

HORA

DATE

La tabla facturas, guarda informacin sobre todas las comandas
atendidas y el precio total cobrado, junto con su fecha y hora.


Pgina 183

TABLA

Atributos

Tipo
Comandas
ID_CLI INTEGER

MESA

INTEGER

FECHA

DATE

HORA

DATE

ID_PLATO INTEGER

CANT INTEGER

La tabla comandas guarda informacin sobre las comandas realizadas
por cada cliente, con su mesa, fecha y hora, plato pedido y cantidad.


Pgina 184

TABLA

Atributos

Tipo
Men
ID_PLATO INTEGER
INGRED

VARCHAR(20)

DESC

VARCHAR(150)

URL

VARCHAR(50)

PRECIO_UNIT DOUBLE

La tabla men guarda informacin sobre cada plato que compone el
men que se mostrar a los clientes, incluyendo los ingredientes, una
descripcin general, una url en caso de que exista un vdeo ilustrativo y
su precio unitario.


Pgina 185

TABLA

Atributos

Tipo
Sugerencias
ID_PLATO INTEGER
SUGER

VARCHAR(80)

La tabla sugerencias, guarda informacin sobre las sugerencias que el
chef desea ofrecer a sus clientes, asignando esta sugerencia a un plato
concreto del men. Est informacin ser cambiante.

7) Pruebas


Pgina 187

7. PRUEBAS

Una vez desarrollados y probados cada uno de los componentes
integrantes de la aplicacin, 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 crtica y debe por tanto, ser planificada,
diseada 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 aceptacin de las mismas y a la
implantacin del sistema; en caso contrario, se debern subsanar las
anomalas encontradas. Se realizarn dos tipos de pruebas: Pruebas
unitarias, y pruebas de integracin.

7.1 Pruebas unitarias

Estn encaminadas a resolver los problemas de cada una de los
procesos por separado.

A todos los mdulos de la aplicacin se les ha pasado la siguiente lista
de pruebas unitarias.

5. Mensajes del sistema suficientemente explicativos.

6. Introduccin de datos con formato incorrecto.

7. Correcta insercin, modificacin y borrado de datos de la BD.


Pgina 188

8. Cumplimiento requisitos del usuario.

9. Funcionalidad de botones correcta.


Pgina 189

7.2 Pruebas de integracin

Estas pruebas son utilizadas fundamentalmente para comprobar la
integracin de los mdulos ya testados y probados de forma individual.
En este sentido, hay dos tipos de pruebas: de navegacin y de paso de
parmetros.

Tambin se ha diseado una lista para estas pruebas:

1. Navegacin correcta por los distintos mens.

2. Correcto paso de parmetros entre funciones.

Despus del estudio de pruebas de integracin en el sistema, el
resultado ha sido satisfactorio y se han depurado algunos errores.

8) Implantacin


Pgina 191

8. IMPLANTACIN

Una vez probada la integridad del software del sistema y especificada su
instalacin y configuracin, se debe transferir el software producido en
un entorno de desarrollo a uno de produccin, para llevar a cabo la
explotacin del sistema. Para ello, se debern realizar una implantacin
fsica de la aplicacin y despus proceder con la ejecucin de la base de
datos.

8.1 Implantacin fsica

La implantacin fsica, se debe realizar de acuerdo a las reuniones con
el cliente, es decir:

La aplicacin se situar sobre el nuevo servidor.

En un primer paso de la implantacin, slo se acceder a una
base de datos de desarrollo, pasando en una fase posterior a
acceder a la base de datos de explotacin.

En las primeras etapas de la implantacin se debern filtrar los
accesos a la aplicacin a aquellos usuarios que se decida prueben
la aplicacin. Para ello se deber configurar el firewall de acceso
al servidor. Posteriormente, se proceder con la ejecucin de la
base de datos.

9) Conclusiones


Pgina 193

9. CONCLUSIONES

El xito de un proyecto informtico depende de muchos factores como
puede ser, la calidad del equipo de trabajo, una buena planificacin, 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 inversin econmica.

Un proyecto informtico exitoso conlleva siempre un desarrollo bien
elaborado del mismo acompaado de una buena idea, adems de otros
factores tcnicos. Este proyecto ha tratado de unir estos dos elementos,
para poner la tecnologa en servicio de la gestin de los negocios de
hostelera.

Como ya ha sido comentado a lo largo de este proyecto, el sector de la
hostelera es el motor de la economa espaola, que sostiene al turismo.
Este sector se va adaptando lentamente al avance tecnolgico
comparado a otros sectores, a pesar de su importancia y extensin.

Ms concretamente, en el sector de la restauracin, la manera de llevar
el negocio y atender a los clientes se lleva realizando exactamente de la
misma manera desde hace muchos aos, sin ofrecer nada nuevo en la
gestin a sus clientes, o para la simple mejora del negocio.


Pgina 194

Este proyecto propone dar un paso, desde hace tiempo necesario, a la
implantacin de la tecnologa en un sector muy importante. Combina el
conocimiento tecnolgico sobre el tratamiento de la informacin, con
una idea que mejora sustancialmente la buena marcha del negocio,
reduciendo tiempos innecesarios, mejorando la gestin de todas las
actividades, aportando mayor informacin a los usuarios, y estimulando
el consumo de una nueva manera.

Adems este proyecto no plantea una mera herramienta funcional que
ayude en las tareas de gestin al negocio, sino que al mismo tiempo es
una invitacin a los clientes para participar en una nueva forma de
tecnologa, donde podrn contar con mayor informacin y control, y por
consiguiente, se busca producir interiormente la satisfaccin del placer
intelectual, ldico y esttico de sus usuarios, esto implica el uso de la
tecnologa bien diseada y aplicada.

En definitiva, el sistema presentado en este proyecto, es una
proposicin del uso de la tecnologa para la mejora de la calidad del
sector ms importante en Espaa en el mbito del negocio, la gestin y
el servicio a los clientes, y por lo tanto, una mejora en la calidad de vida
de todos sus participantes.

10) Futuras mejoras


Pgina 196

10. FUTURAS MEJORAS

En este apartado se consideran las posibles mejoras que se le podran
aplicar al sistema para otorgarle una mayor funcionalidad.

Algunas de las posibles funcionalidades adicionales seran:

Incrementar el nmero de informes: El gerente necesita numerosa
informacin, y se podra utilizar el sistema ya implantado para
registrar ms informacin acerca del desarrollo del negocio, de tal
manera que todo estara centralizado.

Exportar informes en PDF: actualmente los informes se muestran
por pantalla y esto implica tambin la posibilidad de imprimirlos.
Pero extraer los informes en PDF aportara mayor facilidad para el
almacenamiento digital.

Creacin de una red de usuarios: sera una opcin 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.

11) Bibliografa


Pgina 198

11. BIBLIOGRAFA

A continuacin se indican aquellas fuentes consultadas durante la
elaboracin del proyecto.

11.1 Libros

[BARR01] Jess Barranco de Areba, Metodologa del anlisis
estructurado de sistemas, Publicaciones de la
Universidad Pontificia Comillas, Madrid 2001.

[RIVE05] Enrique Rivero Cornelio, Luis Martnez Fuentes,
Israel Alonso Martnez, Bases de datos relacionales:
Fundamentos y diseo lgico, 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.

[MUO08] Manuel Muoz Garca, Apuntes de Gestin de
Proyectos Informticos,Madrid 2008.


Pgina 199

[ESQU08] Juan Carlos Esquivel, Apuntes de Ingeniera del
Software II, Madrid 2008.


Pgina 200

11.2 Pginas web

[WWW001] Ministerio de Industria, Turismo y Comercio.
http://www.mityc.es/turismo

[WWW002] Federacin Espaola de Hostelera.
http://www.fehr.es/

[WWW003] Portal de comunicacin de hostelera.
http://www.hosteleriadigital.es/

[WWW004] Instituto nacional de estadstica.
http://www.ine.es/inebmenu/mnu_hosteleria.htm

[WWW005] Restauracin electrnica.
http://www.e-restauracion.com

[WWW006] Portal de empleo para la hostelera y turismo.
http://www.emia.es/cgi-bin/master.pl?accion=inicio

[WWW007] Pgina oficial restbar.
http://www.restbar.com/

12) Anexos


Pgina 202

12. ANEXOS

En este apartado se incluye una valoracin econmica del proyecto, una
planificacin y un manual de usuario.

12.1 Manuales

En este apartado se muestran los dos manuales de que se compone la
aplicacin: manual de explotacin y manual de usuario.

12.1.1 Manual de explotacin

El manual de explotacin es aquel dirigido al administrador de la
aplicacin.

A continuacin, se presentan los pasos para establecer un entorno de
desarrollo idntico 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 instalacin 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


Pgina 203

11. Aparecer la primera ventana del asistente de instalacin,
en la que se pregunta los servidores a instalar. Es necesario
seleccionar al menos Glassfish V2 UR2. Pulsar el botn Next.

12. En la siguiente ventana, simplemente se solicitar la
aceptacin de los trminos de la licencia del producto.

13. En la siguiente ventana se muestra el directorio donde se va
a realizar la instalacin y donde se encuentra el JDK de Java.
En principio, se dejan los valores por defecto. En cualquier
caso, es importante tomar nota de dnde se va a instalar


Pgina 204

Netbeans 6.1 ya que se necesitar esa informacin
posteriormente. Pulsar Next.

14. La siguiente ventana muestra las opciones de instalacin
del servidor Glassfish. En principio, se dejarn los valores por
defecto que aparecen. Si se cambian, es importante tomar nota
de los valores que se asignan al usuario administrador, su
contrasea, puerto HTTP y puerto de la consola de
administracin. Pulsar el botn Next.

15. En la siguiente ventana aparece un resumen de los
parmetros de la instalacin. Pulsar el botn Install.


Pgina 205

16. Al finalizar, aparecer una ventana donde se informar de
que ha finalizado la instalacin y ofrecer la posibilidad de
registrar el producto. Pulsar el botn Finish.

Para la instalacin del entorno de MySQL es necesario seguir
estos pasos:

1. Ejecutar el programa mysql-5.0.67-setup.exe. Ello inicializar
el asistente de instalacin de MySQL. Pulsar Next.

2. Aparecer una ventana donde pide escoger el tipo de
instalacin. Seleccionar Typical.


Pgina 206

3. En la siguiente ventana que aparecer, pulsar Install. Tras la
instalacin, aparecern 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.


Pgina 207

4. Aparecer entonces la ventana inicial del asistente de
configuracin del servidor. Pulsar Next.


Pgina 208

5. En la siguiente ventana, escoger configuracin estndar 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.


Pgina 209

7. En la siguiente ventana se debe indicar la contrasea del
usuario root. Se recomienda la utilizacin de la contrasea
root.


Pgina 210

8. En la siguiente ventana que aparecer, pulsar el botn
Execute. Cuando finalice la configuracin, 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 (botn derecho y seleccionar Extraer ficheros). Se
recomienda una descompresin en la raz 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 raz de c.


Pgina 211

12.1.2 Manual de usuario

Este es el manual para usuarios del Sistema Integral para la Gestin de
Restaurantes. Existen tres grupos fundamentales de usuarios:

Gerente: con derecho de acceso a informacin reservada como
informes econmicos.

Empleados: aquellos usuarios con capacidad de visualizar
comandas e introducir sugerencias.

Clientes: sern todos aquellos usuarios que realicen comandas al
mdulo de cocina y que naveguen a travs del men virtual.

En primer lugar, slo en el mdulo de cocina, aparecer una ventana de
login, para comenzar una sesin como empleado o como gerente:


Pgina 212

Despus en el caso del gerente encontrar este men:

Mientras que en el caso de ser otro empleado, encontrar este men
ms reducido:


Pgina 213

En el lado del cliente, en el mdulo de mesa, este ser su inicio:

Posteriormente, en el caso en el que el gerente o el chef hayan pulsado
sobre introducir sugerencias, se encontrarn con la siguiente ventana:


Pgina 214

En caso en que se haya seleccin 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 descripcin, el nmero
de plato, los ingredientes, o la direccin de la URL donde est ubicada
la imagen o vdeo demostrativo:


Pgina 215

Sin embargo, si puls sobre acceder informes, obtendr los siguientes
resultados:


Pgina 216

Si los clientes, accedieron a travs del men de bienvenida a la carta
virtual, esto ser lo que encuentren:


Pgina 217

Si los clientes pulsan sobre el botn Ms informacin accedern a la
siguiente ventana que detalla un plato concreto:


Pgina 218

12.2 Valoracin econmica

A continuacin 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 implantacin 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
continuacin, se representa las horas que ha empleado cada
participante, junto con su tarifa y el clculo de horas empleadas en la
realizacin del proyecto.

El nmero de horas se ha calculado teniendo en cuenta que la duracin
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.


Pgina 219

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


Pgina 220

12.2.2 Presupuesto de hardware y software

Para el desarrollo del sistema, sern necesarias las siguientes
herramientas:

Elemento

Precio
Cantidad

Total
Equipo de
sobremesa
650
3
1950
Pantalla tctil
310
2
620
Servidor 283 1 283
Subtotal HW - 6 2853
Windows 150 3 450
Subtotal SW - 3 450
TOTAL - 9 3303


Pgina 221

12.2.3 Presupuesto total del proyecto

En este apartado se muestra el presupuesto total del proyecto despus
de los clculos 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 .


Pgina 222

12.3 Planificacin

En este anexo se muestra la planificacin realizada para el desarrollo
del proyecto.

Sistema Gestion de Restaurantes 1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema Gestion de Restaurantes 1

Cargado por

Copyright:

Formatos disponibles

Autorizada la entrega del proyecto del alumno:

Gorka Daz de Orbe

También podría gustarte