autorizada la entrega del proyecto del alumno - iit comillas · detallada que sobre un menú en...

Autorizada la entrega del proyecto del alumno:

Gorka Díaz de Orbe

EL DIRECTOR DEL PROYECTO

Carlos Labanda Maján

Fdo.: …………………… Fecha: 28/07/2010

Vº Bº del Coordinador de Proyectos

Eduardo Alcalde Lancharro

Fdo.: …………………… Fecha: 03/09/2010

PROYECTO FIN DE CARRERA

SISTEMA INTEGRAL PARA LA

GESTIÓN DE RESTAURANTES

AUTOR: GORKA DÍAZ DE ORBE

MADRID, SEPTIEMBRE DE 2010

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO EN INFORMÁTICA

Sistema Integral para la Gestión Restaurantes

Página I

Dedicatoria

“A mi madre, por los valores que me ha enseñado y que nunca olvidaré”


Página II

Agradecimientos

A mi padre y hermano, por saber sostenerme durante todos estos años

de mi vida, otorgándome la posibilidad, de sentirme privilegiado, y

hacerme crecer.

A mis amigos, por su apoyo incondicional, desde que somos pequeños

en todas las facetas de la vida.

A mis compañeros, por toda la ayuda recibida.

A Pablo, por sus fantásticos dibujos.

A todos aquellos que de alguna manera habéis participando en el

proyecto, con vuestra inquietud y apoyo inestimable.


Página III

RESUMEN DEL PROYECTO

El objeto de este proyecto es el desarrollo e implantación de un Sistema Integral para la

Gestión de Restaurantes.

Este sistema ha sido desarrollado para cubrir las necesidades básicas de la gestión de un

restaurante, ofreciendo la tecnología existente al desarrollo del negocio.

El Sistema Integral para la Gestión de Restaurantes está especialmente diseñado para

aquellos restaurantes en los que el tiempo es una variable importante para su economía

y para aquellos que simplemente deseen ofrecer un mejor servicio a sus clientes,

proporcionándoles una forma diferente de información y atención de sus necesidades.

En la actualidad, la gestión de las comandas de los clientes, la transmisión de las

órdenes a la cocina, la proposición de sugerencias, la inserción de publicidad y la

gestión de los diversos módulos del negocio, se lleva realizando de la misma manera

desde hace muchos años.

El análisis de esta situación, ha permitido llegar a la conclusión de que existe un amplio

margen de mejora en todos los procesos diarios que se realizan en la atención y servicio

a los clientes de un restaurante.

Este sistema propone una revolución en la gestión de los diferentes elementos

principales del negocio, haciendo uso de la tecnología en servicio de sus usuarios.

Se ha dividido el sistema en dos módulos fundamentales, uno es el módulo de mesa, que

está disponible en cada una de las mesas del salón de un restaurante, y otro es el módulo

de cocina, que se instala en la cocina para posibilitar la comunicación directa de los

clientes con la cocina.

Ambos módulos ofrecen una funcionalidad distinta, y juntos controlan de forma integral

diversos factores sobre el desarrollo y gestión del negocio.

El Sistema Integral para la Gestión de Restaurantes está desarrollado en una

arquitectura cliente-servidor de cliente ligero, haciendo uso de un entorno gratuito


Página IV

(J2EE, MySQL y Apache) y permite controlar los siguientes aspectos de la gestión de

un restaurante:

Carta virtual: muestra a los clientes del restaurante, en sus mesas, a través del

módulo existente, la variedad de platos, bebidas y ofertas que el restaurante

dispone para sus clientes. Además, permitirá el acceso a información más

detallada que sobre un menú en papel en caso en que el cliente esté interesando,

proporcionando más información acerca de los ingredientes, su forma de

elaboración, presentación de imágenes sobre el aspecto real del plato, y

posibilidad de visualización de videos acerca de su preparación.

A través de la carta virtual, el chef de cocina o el gerente del restaurante, tendrá

la posibilidad de ofrecer sugerencias o mostrar publicidad, como se especificará

más adelante.

Comandas: controla el transporte y trato de la información sobre las órdenes de

los clientes, directamente desde sus mesas, hasta la cocina, donde en su

respectivo módulo, se podrán visualizar todas las comandas que realicen los

clientes, las comandas ya atendidas, y aquellas que aún están pendientes. Este

innovador proceso, permite una comunicación directa de los clientes con la

cocina, evitando tiempo de espera en la atención del camarero o en el transporte

de la información del camarero, a la cocina.

Publicidad y sugerencias: el gerente del restaurante, o el chef de cocina, podrán

ofrecer a sus clientes sugerencias desde el módulo de cocina, al módulo de mesa,

estimulando la demanda de sus consumidores. Además, también existe la

posibilidad de reservar un espacio en la carta para la inserción de publicidad,

creando de esta manera, un importante espacio para vender a terceros, o

promocionar otros restaurantes asociados a los clientes.

Economía: todos los movimientos relativos a la atención de comandas del

restaurante, quedarán registrados con detalle en bases de datos, donde más tarde,

a través de procesos que traten esta información, se obtendrán informes de

especial importancia para el desarrollo del negocio, como es un resumen de la

facturación, y un control de la demanda de platos ordenados de forma

ascendente.


Página V

Para el desarrollo del proyecto se siguió el ciclo de vida lineal o en cascada, con sus

respectivas fases: Identificación de necesidades, Análisis de Requisitos, Estudio de la

arquitectura, Diseño externo, Diseño interno, Programación, Pruebas e Implantación.

La última parte del proyecto incluye una valoración económica del mismo y la

planificación llevada a cabo para su desarrollo.

Como conclusión, este proyecto supone una importante modernización del sector más

importante en España, como es la hostelería y la restauración, que son las bases de

acogida del turismo, motor de la economía nacional, aportando una mayor

funcionalidad a los restaurantes, perfeccionando su gestión, reduciendo tiempos

innecesarios y mejorando por lo tanto, el servicio ofrecido a sus clientes.


Página 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


Página 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 one’s message to the kitchen.

Specials and Suggestions: restaurant managers or chefs would offer their

customers suggestions from the kitchen module directly to the table module,

appealing to the customers’ tastes. Moreover there is the possibility of other

advertisements in the digital menu, thus promoting and encouraging business

with other companies or restaurants.

Business: all transactions and orders valuable to a restaurant would be recorded

in detail in databases, where, through specific information processes, one would

get valuable reports that are critical for business development. An example

would be a summary list of dishes of the highest demand in descending order.

The development of this project life follows the waterfall model, with these

respective phases: identification of needs, analysis of requirements, study of

architecture, external design, internal design, programming, testing, and

implementation.

The last part of the project includes an economic assessment of the planning and

carried out for development.

In conclusion, this project represents a significant modernization of the most

important sector in Spain, such as hotels and restaurants, which are the basis of

tourism, the national economic engine. The system provides enhanced functionality

to restaurants, improving their management by reducing unnecessary time and

resources and thus improving the services offered to its customers.


Página VIII

Índice

1. INTRODUCCIÓN ________________________________________________ 2

1.1 Sector de la hostelería. ____________________________________ 2

1.1.1 Empleo en hostelería _____________________________________ 10

1.2 Las empresas cliente ______________________________________ 12

2. IDENTIFICACIÓN DE NECESIDADES __________________________ 17

2.1 Organización empresarial _________________________________ 17

2.2 Tipología de los usuarios finales __________________________ 25

2.3 Antecedentes del sistema _________________________________ 27

2.4 Objetivos del sistema _____________________________________ 32

2.5 Alcance de la aplicación __________________________________ 35

2.6 Restricciones _____________________________________________ 36

3. ANÁLISIS DE REQUISITOS ____________________________________ 38

3.1 Ámbito del proyecto ______________________________________ 38

3.2 Contexto general del sistema _____________________________ 40

3.3 Funciones primarias afectadas ____________________________ 43

3.3.1 Órdenes de pago en un restaurante _______________________ 49

3.3.2 Modificaciones sobre el funcionamiento ___________________ 52

3.4 Unidades de la organización afectadas por la mecanización

57

3.5 Lista de requisitos ________________________________________ 60

3.6 Modelo lógico de datos ____________________________________ 82

3.6.1 DFD contextual __________________________________________ 82

3.6.2 DFD conceptual _________________________________________ 83

3.6.3 Modelo conceptual de datos. _____________________________ 105


Página IX

4. ESTUDIO DE LA ARQUITECTURA ___________________________ 110

4.1 Especificación de las alternativas_______________________ 110

4.1.1 Arquitecturas ___________________________________________ 110

4.1.2 Lenguajes de programación para los clientes _____________ 123

4.1.3 Lenguajes de programación para el servidor ______________ 135

4.1.4 Sistemas Gestor de Bases de Datos ______________________ 143

4.1.5 Sistemas operativos _____________________________________ 147

4.2 Evaluación de las alternativas __________________________ 151

4.2.1 Evaluación de la arquitectura ___________________________ 151

4.2.2 Evaluación del sistema operativo ________________________ 154

4.2.3 Evaluación del lenguaje de programación en el cliente ____ 155

4.2.4 Evaluación del lenguaje de programación en el servidor __ 157

4.2.5 Evaluación del sistema gestor de bases de datos _________ 158

4.3 Selección de la alternativa ______________________________ 159

5. DISEÑO EXTERNO __________________________________________ 162

5.1 Entorno operativo ______________________________________ 162

5.2 Fronteras de mecanización _____________________________ 163

5.3 Especificación de procesos _____________________________ 163

5.4 Diseño de interfaces ____________________________________ 166

5.4.1 Interfaz login ____________________________________________ 166

5.4.2 Menú privado ___________________________________________ 167

5.4.3 Menú público ___________________________________________ 173

5.5 Procesos de seguridad __________________________________ 176

6. DISEÑO INTERNO ___________________________________________ 178

6.1 Diseño interno de programas ___________________________ 178

6.1.1 Diagrama HIPO Administración de empleados ____________ 179

6.1.2 Diagrama HIPO Alta comanda ___________________________ 180

6.1.3 Diagrama STC Administración de empleados _____________ 181


Página X

6.2 Modelo físico de la base de datos _______________________ 182

7. PRUEBAS ___________________________________________________ 187

7.1 Pruebas unitarias _______________________________________ 187

7.2 Pruebas de integración __________________________________ 189

8. IMPLANTACIÓN _____________________________________________ 191

8.1 Implantación física _____________________________________ 191

9. CONCLUSIONES _____________________________________________ 193

10. FUTURAS MEJORAS ______________________________________ 196

11. BIBLIOGRAFÍA ____________________________________________ 198

11.1 Libros ___________________________________________________ 198

11.2 Páginas web _____________________________________________ 200

12. ANEXOS ___________________________________________________ 202

12.1 Manuales ________________________________________________ 202

12.1.1 Manual de explotación ________________________________ 202

12.1.2 Manual de usuario ____________________________________ 211

12.2 Valoración económica __________________________________ 218

12.2.1 Presupuesto en horas hombre _________________________ 218

12.2.2 Presupuesto de hardware y software ___________________ 220

12.2.3 Presupuesto total del proyecto _________________________ 221

12.3 Planificación ____________________________________________ 222

1) Introducción


Página 2

1. INTRODUCCIÓN

El presente proyecto plantea el desarrollo de un sistema integral para la

gestión de restaurantes, con el objeto de mejorar sustancialmente,

gracias a la tecnología ofrecida, los restaurantes y otros negocios del

sector hostelero relacionados con la alimentación, como bares,

cafeterías y casas de comida.

Para una mejor comprensión, se realiza en este capítulo una

presentación del sector hostelero, dentro del cual se engloban todos los

restaurantes, bares y cafeterías y un breve análisis del mercado en el

cual, dicho proyecto, tiene su impacto. Para la realización de este

proyecto se han seguido las referencias bibliográficas [WWW001],

[WWW002], [WWW003], [WWW004], [WWW005]

1.1 Sector de la hostelería.

Todas aquellas actividades económicas consistentes en la prestación de

servicios ligados al alojamiento y la alimentación esporádica, pertenecen

al sector de hostelería.

Muy usualmente están ligados al turismo, tales como hoteles, hostales,

paradores, bares, cafeterías y restaurantes.

No se considera hostelería al servicio de comida a domicilio y todos

aquellos combinados con otro tipo actividades de ocio como discotecas,

etc.


Página 3

El sector español de la hostelería tiene una elevada repercusión en la

formación del PIB, algo superior al 7 %, lo que pone de manifiesto su

influencia, y su repercusión, en la creación de riqueza y en la

generación y mantenimiento del empleo.

La modernización que la hostelería ha impulsado en las últimas

décadas ha permitido que el sector se consolide con un rol destacado

dentro de la economía y la sociedad española. El incremento en los

parámetros de competitividad y eficiencia, es el principal indicador que

refleja un desempeño sobresaliente, confirmando el alto grado de

importancia relativa y absoluta alcanzado por el sector turístico

español.

Con una producción anual de casi 12 billones de euros y un volumen

de empleo que se acerca al millón de personas, es evidente la

importancia de la Hostelería en la economía nacional.

Un sector que, tal y como recoge el informe presentado por la

Federación Española de Hostelería (FEHR) en relación al año 1999,

cuenta con más de 333.000 establecimientos repartidos entre las

actividades de hoteles, restaurantes, colectividades, cafés-bares y

cafeterías. De entre ellos, es el subsector de la restauración el que posee

un mayor número de plazas con una cifra superior a los 3,3 millones.

A continuación, para poder apreciar la progresión del sector, se

representa en la siguiente tabla, el crecimiento del número de

restaurantes en España, desde 1975 hasta el 2008:


Página 4

Índice de crecimiento del sector de restaurantes

Años Número Índice Variación

interanual

1975 21.536 100 ---

1980 27.381 127 4,9

1985 37.227 173 5,6

1990 50.055 232 5,8

1998 53.591 249 4,0

2000 55.238 256 1,3

2002 60.436 281 4,2

2006 67.457 313 1,8

2007 69.298 322 2,7

2008 70.641 328 1,9

Fuente: Secretaría General de Turismo y DIRCE.

Según la Secretaría General de Turismo y DIRCE (Directorio Central de

Empresas), durante el año 2007, 69.298 establecimientos, con 4,29

millones de plazas, se integraron bajo la tipología de restaurantes, un

2,68 más que en 2005, y su producción se ha situado en 23.100

millones de euros.

Como se recoge en la tabla anterior, la expansión del número de

restaurantes casi se ha cuadriplicado desde 1975.


Página 5

El cada vez más frecuente hábito de comer fuera del hogar se esconde

detrás de este crecimiento, y además se debe al importante desarrollo

que ha tenido el turismo en España y a los mejores niveles de vida que

tiene la población.

A continuación, se representa, la distribución del censo por

comunidades autónomas de restaurantes en los años 2007 y 2008.

Cabe señalar, que se han agregado también las cafeterías, en la

siguiente tabla:


Página 6

Comunidades

Autónomas

Año 2007 Año 2008

Andalucía 8.351 8.615

Aragón 1.772 1.823

Asturias (Principado) 2.495 2.548

Baleares (Islas) 4.269 5.104*

Canarias (Islas) 6.816 7.219*

Cantabria 1.141 1.174

Castilla León 2.781 4.552

Castilla La Mancha 4.419 2.987

*Cataluña 17.301 17.301**

Extremadura 1.455 1.530

Galicia 5.225 5.145

Madrid (Comunidad) 8.051 8.363

Murcia (Región) 1.995 2.094

Navarra (Comunidad

Foral)

632 651

País Vasco 3.135 3.623

La Rioja 469 469**

C. Valenciana 11.682 12.113

TOTAL 81.989 84.879

(*) DIRCE 2008

(**) Se agrega el grupo de los restaurantes – cafeterías

El reparto por comunidades autónomas estaría encabezado por

Cataluña, seguido de la Comunidad Valenciana, Andalucía, Madrid y


Página 7

Canarias. En el extremo opuesto, se encuentra Extremadura,

Cantabria, Navarra, y La Rioja con el menor número de

establecimientos.

Se representa a continuación, de forma gráfica, los datos representados

en la tabla anterior, sobre la distribución de restaurantes por

Comunidades Autónomas en el 2008, donde se puede apreciar, de una

forma más intuitiva que la mayor concentración de restaurantes y

cafeterías, se encuentra en Cataluña, Comunidad Valenciana,

Andalucía y Madrid.

Distribución de restaurantes por Comunidades Autónomas

Año 2008

Andalucía

Aragón

Asturias (Principado)

Baleares (Islas)

Canarias (Islas)

Cantabria

Castilla León

Castilla La Mancha

Cataluña

Extremadura

Galicia

Madrid (Comunidad)

Murcia (Región)

Navarra (Comunidad Foral)

País Vasco


Página 8

El subsector restauración, hacia el cual el presente proyecto está

dirigido, supuso una participación del 32,91 % dentro del sector

hostelería, aportando 42.233 millones de euros, como se puede

observar en la tabla a continuación, además, para una mejor

visualización de la importancia del subsector restauración, dentro de la

hostelería, se representa la misma tabla de forma gráfica más abajo:

Distribución de la producción nacional del sector de la hostelería,

en 2008

Millones euros % Participación

Sector Alojamiento 17.102 13,33

Sector de comidas 42.233 32,91

Sector de bebidas 59.505 46,37

Sec. Colectivid. y

Caterings

9.477 7,39

Total 128.317 100,00


Página 9

El incremento medio de la producción sobre el año 2007 fue del 3,58 %

siendo el sector de la hostelería, uno de los más importantes para la

economía nacional, y más concretamente, el subsector restauración.

Producción nacional de hostelería 2008

Sector Alojamiento

Sector de comidas

Sector de bebidas

Sec. Colectivid. y Caterings


Página 10

1.1.1 Empleo en hostelería

Respecto a la situación de crisis económica actual, se presenta a

continuación, un breve estudio de los últimos datos de empleo en

hostelería y restauración.

En el mes de abril el número de trabajadores con alta en empresas de

hostelería era de 1.278.793, lo que supone un 1,2 % más que en el

mismo mes de 2009, según los datos del Ministerio de Trabajo y

Asuntos Sociales. Esta evolución positiva se debe a los servicios de

restauración que representan la mayor parte de la hostelería, que

llegaron a 1.023.286 trabajadores, repitiendo al igual que el mes

anterior un 1,8 % de subida interanual. El empleo en el subsector del

alojamiento, con 255.507 trabajadores, cayó un 1 %, después del

aumento que se produjo en el mes de marzo (2,3 %).

La media en los cuatro primeros meses del año supone en restauración

un incremento del 1,1 %, con relación al mismo período de 2009. En

hoteles y otros alojamientos cae el empleo un 1,4 % interanual.

Concretamente, en el sector restauración, en el cual el presente

proyecto tiene su impacto, en marzo de 2010 se registraron 1.001.441

de trabajadores afiliados a la Seguridad Social con alta en restauración,

lo que supone un 1,8 % más que en el mismo mes del año anterior.


Página 11

Esta tasa interanual es 1,2 puntos superior a la de enero y significa una

ligera recuperación ya que en marzo de 2008 el número de trabajadores

era un 3,9 % menos respecto al año anterior.

En lo que va de año 1.213.035 trabajadores estuvieron empleados de

media en el conjunto de la hostelería, aumentando un 0,4 % respecto al

mismo período de 2009.

A continuación se representa una gráfica comparativa de las tasas de

empleo en alojamiento y restauración, comentadas anteriormente, de

abril de 2009 a abril de 2010:


Página 12

1.2 Las empresas cliente

En este capítulo se presentan las empresas de restauración, a las que

va especialmente dirigido el presente proyecto.

Algunos de los objetivos principales que se buscan con el Sistema

Integral para la Gestión de Restaurantes, son: la posibilidad de acceder

al menú de forma virtual con información más detallada incluyendo

fotos o videos, ahorro de tiempo en la gestión de comandas evitando el

tiempo de espera hasta que atienda el camarero y el tiempo de

transmisión de la comanda desde el camarero a la cocina, posibilidad

para los restaurantes de la introducción de publicidad y sugerencias en

sus cartas virtuales, y una mejor gestión de todos los pedidos, evitando

errores de anotación de las comandas por parte de los camareros y

liberando carga de trabajo a los camareros.

Por todos estos objetivos, el perfil de la empresa cliente son

restaurantes de comida rápida, y todas aquellas cadenas de

restaurantes donde el tiempo para atender, y servir a los clientes, es

una variable especialmente importante.

A continuación, para un mejor conocimiento del perfil de posibles

empresas cliente, se presentan algunos ejemplos, hacia las cuales, el

Sistema Integral de Gestión de Restaurantes, está especialmente

dirigido:


Página 13

Mc Donald’s: es una cadena de restaurantes de comida

rápida fundada en 1940, por los hermanos Dick y Mac

McDonald.

Es la cadena más grande en el mundo y provee una gran

variedad de emparedados, bocadillos y otros productos de

comida rápida.

En España, McDonald’s factura 755 millones de euros, y

tiene más de 311 restaurantes franquiciados.

Burger King Corporation: es la segunda cadena más

grande de restaurantes de comida rápida, fundada en

Miami en 1954. Cuenta con más de 12.100 restaurantes en

todo el mundo.

Telepizza: es una cadena española de pizzerías con

presencia en varios países fundada por Leopoldo Fernández

Pujals en 1986. La cadena se extendió por Madrid primero

y creció en pocos años hasta convertirse en líder del


Página 14

mercado español de pizzas y en el segundo grupo de comida

rápida por detrás de McDonald's. Telepizza cuenta con la

siguientes presencia:

559 establecimientos en España

81 establecimientos en Portugal

61 establecimientos en Chile

92 establecimientos en Polonia

51 establecimientos en Guatemala

28 establecimientos en El Salvador

Grupo vips: es la empresa líder en el sector de la hostelería

en España. Cuenta con 6 cadenas (Vips, Ginos, Tio Pepe,

The Wok, TGI Friday’s, BSF) y 11 restaurantes (El bodegón,

Iroco, Bice, Teatriz, Lucca, Tattaglia, Rugantino, Paparazzi,

Mood, Root y Starbuck’s) repartidos en 400

establecimientos, presente en 16 provincias españolas y en

Portugal.


Página 15

Grupo Zena (Foster’s Hollywood): es la primera compañía

de restauración multimarca en España gracias al éxito

obtenido en su triple vertiente de franquiciado (Pizza Hut,

Burger King, KFC), franquiciador (Foster's Hollywood,

Cañas y Tapas e Il Tempietto) y restaurantes propios (La

Vaca Argentina y Nostrus). Grupo Zena es un referente en

el sector debido a la estrategia de negocio, a su gran

capacidad de crecimiento y al modelo de gestión que

desarrolla.

Foster’s Hollywood se fundó en 1971 como la primera

cadena de restaurantes de comida americana en instalarse

en España y dispone de más de 480 restaurantes.

2) Identificación de necesidades


Página 17

2. IDENTIFICACIÓN DE NECESIDADES

Esta etapa sirve como soporte a la petición que el cliente realiza para

determinar las pautas generales de sus necesidades y contexto del

sistema.

El cliente debe establecer los objetivos y necesidades generales que el

sistema debe cumplir. Se especifica el alcance del proyecto, las

restricciones, los antecedentes, así como la tipología de los usuarios

finales. Por lo tanto, en esta etapa se define el problema a resolver y se

fijan las normas a seguir para la dirección del proyecto.

2.1 Organización empresarial

El sistema integral de gestión de restaurantes está compuesto por un

módulo de mesa, y otro módulo de cocina.

Actualmente, los métodos para gestionar toda la información referente a

los restaurantes, como pueden ser, la carta, los pedidos de los

clientes...etc. se siguen realizando de una forma manual y con la

necesidad de la espera para la disponibilidad de los camareros a sus

clientes.


Página 18

Con la implantación del sistema que propone este proyecto, se

modificará sensiblemente la gestión de las comandas y el

funcionamiento general de la gestión de un restaurante, por lo que es

de suma importancia, un análisis detallado de los perfiles que se verán

afectados, y cómo se llevará a cabo la nueva gestión.

En el siguiente organigrama, se analizan los perfiles que se verán

afectados por el sistema, diferenciando aquellos que se verán

especialmente afectados por la implantación del módulo de cocina

resaltados en un cuadro rojo, como aquellos que se verán afectados por

la implantación del módulo de mesa, resaltados por el recuadro azul.

Gerente

Contable

Jefe departamento

Ventas

Jefe departamento

administración

Chef Mesero encargado

del salón

Meseros Ayudantes

de cocina Seguridad Limpieza

Proveedores

Sueldos


Página 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 implantación

del sistema integral de gestión de restaurantes, tendrá un impacto

positivo en el funcionamiento general de muchos de ellos.

A continuación se describen los participantes de dicha estructura:

Gerente: es la persona encargada de la supervisión directa

de los subordinados más próximos y de la organización en

su globalidad. Asignando recursos como pueden ser

capitales, materias primas, etc. o incluso delegando poder

en las unidades para su adecuado funcionamiento pero

siempre bajo su supervisión. A la vez gracias a esta

supervisión puede detectar anomalías y resolverlas. Dentro

de este conjunto de obligaciones también se encuentra el de

difusor de conocimientos o información que deben conocer

el resto de personal. Con todas estas obligaciones o

funciones logra que la organización funcione debidamente

como una unidad integrada.

Contable: es el encargado de obtener y registrar datos

contables, estadísticos y financieros, así como efectuar

pagos y cobros. Realiza asientos en los registros o libros de

contabilidad, efectúa cálculos, realiza costos de producción,

hace transacciones bancarias, calcula los salarios a pagar

partiendo de los registros de horas trabajadas por cada

trabajador, y es el encargado de la Tesorería.


Página 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 públicas y

marketing.

Jefe departamento de administración: realiza el pago a

los proveedores, acreedores, administra las operaciones

bancarias, legales, y los sueldos de los empleados.

Proveedores: es el agente económico que entrega o provee

materias primas, materiales o servicios, tiene la

responsabilidad de cumplir con los compromisos de entrega

pactados, según el lugar y el tiempo acordados. Su misión

es fundamental para la prestación del servicio en un

restaurante, suelen ser empresas externas y están

especialmente supervisadas por el jefe del departamento de

administración.

Sueldos: encargados de la administración y supervisión de

los salarios a los empleados.

Chef: es el responsable del control de mercaderías y

faltantes, la realización y elaboración de los distintos

menús, control de higiene de la cocina y empleados,

cuidado de los bienes de uso para realizar los menús, y

todas las tareas desempeñadas en la cocina.

Ayudantes de cocina: son colaboradores en la realización

de los menús, mantienen la higiene de la cocina y cuidan

de los bienes de uso de la cocina. Además realizan tareas


Página 21

de agilidad para el trabajo del chef, ayudando en la

elaboración de platos.

Mesero encargado del salón: es el responsable de la

organización del salón, del control de bienes y mercadería

de salón, se encarga de seleccionar sectores para cada

mesero, y supervisa sus tareas. También realiza la

recepción y acomodamiento de clientes en el restaurante.

Meseros: son los encargados del orden y limpieza del salón,

del cuidado de su sector de trabajo, atienden las comandas

de los clientes de una forma cordial y eficaz y reordenan el

sector de trabajo después del servicio.

Seguridad: es el responsable del mantenimiento de

la seguridad dentro y fuera del local, y vela por el orden en

el restaurante.

Limpieza: son los encargados de la higiene y limpieza de

todo el local, de los elementos de cocina y del salón.

Con la implantación del sistema integral de gestión de restaurantes,

algunas de las funciones principales de los miembros de esta estructura

detalladas anteriormente, se verán modificadas sensiblemente,

proporcionando una mejora en la gestión y en el tiempo de la atención a

los clientes.

Concretamente, modificarán su funcionamiento aquellos afectados por

el módulo de mesa, remarcados en azul en el organigrama:


Página 22

Mesero encargado del salón: seguirá siendo el responsable

de la organización del salón, control de la mercadería de

salón, supervisor de las tareas desempeñadas por los

meseros y recepción y acomodación de los clientes.

Además, presentará y explicará brevemente a los clientes el

novedoso sistema de módulo de mesa para la visualización

del menú virtualmente, con imágenes y videos

correspondientes, la posibilidad de realizar los pedidos

directamente desde sus mesas a la cocina y todas las

funcionalidades que ofrece el sistema.

Meseros: seguirán siendo los encargados del orden y

limpieza del salón, del cuidado de su sector de trabajo, y

reordenación del sector de trabajo después del servicio.

Pero como gran novedad en sus funciones, no tendrán la

necesidad de atender las comandas de los clientes, sin

embargo podrán ayudarles en la utilización del sistema y en

aquellos problemas y dudas que surjan, y seguirán llevando


Página 23

y recogiendo las comandas que realicen sus clientes a sus

respectivas mesas.

Aquellos miembros, cuyo funcionamiento habitual, se verá modificado

gracias al módulo de cocina del sistema integral de gestión de

restaurantes, son los siguientes, según el marco rojo que se puede

apreciar en el organigrama anterior:

Chef: seguirá siendo el responsable del control de

mercaderías y faltantes, la realización y elaboración de los

distintos menús, control de higiene de la cocina y

empleados, cuidado de los bienes de uso para realizar los

menús, y todas las tareas desempeñadas en la cocina.

Además, será el encargado de controlar, realizar y repartir

las comandas entre los ayudantes de cocina según se

visualizan directamente en el módulo de cocina.


Página 24

Ayudantes de cocina: seguirán siendo los colaboradores en

la realización de los menús, mantendrán la higiene de la

cocina y cuidarán de los bienes de uso de la cocina,

realización de tareas de agilidad para el trabajo del chef, y

elaboración de platos.

Además, controlarán la recepción de las comandas en el

módulo de cocina, y marcarán aquellas comandas que ya

hayan sido atendidas.


Página 25

2.2 Tipología de los usuarios finales

Este proyecto tendrá los siguientes usuarios:

- Administrador: será el responsable de la implantación, diseño,

actualización, inserción de publicidad y mantenimiento del

sistema completo.

- Usuarios finales

Chef: realizará el control y repartirá la elaboración de las

comandas que se reciben en el módulo de cocina entre los

ayudantes de cocina.

Ayudantes de cocina: controlarán la recepción de

comandas según vayan visualizándose en el módulo de

cocina, editarán aquellas comandas satisfechas y revisarán

las comandas pendientes.

Mesero encargado del salón: guiará a aquellos clientes

que encuentren dificultades en el manejo del sistema y

supervisará el correcto funcionamiento del módulo de

mesa.

Clientes: serán todas aquellas personas que realizarán las

comandas desde sus mesas, navegarán a través del menú

virtual, y podrán informarse de todas las ofertas,

promociones y publicidad ofrecidas por el restaurante.


Página 26

Dado que la aplicación va dirigida a un público general, se realizará un

interfaz táctil hombre máquina agradable, intuitivo y vistoso a la vez

que funcional, que facilite la adaptación de una forma sencilla y rápida

a la nueva aplicación.


Página 27

2.3 Antecedentes del sistema

Desde hace años, se realiza la gestión de los restaurantes de una

manera obsoleta, apoyándose únicamente en la tecnología en el uso de

un software que permite registrar las comandas y emitir las facturas,

pero aún se sigue anotando en papel, en muchos casos, las comandas,

aun se siguen visualizando los menús que ofrece cada restaurante en

papel, muchas veces con anotaciones escritas a mano y con

descripciones muy poco claras sobre la composición de los platos, y aun

se siguen transmitiendo oralmente o por escrito, las peticiones que

realizan los clientes con las consecuentes equivocaciones humanas por

falta de entendimiento.

Todos estos posibles inconvenientes, y posibilidades de mejora, se

solventarán gracias a la implantación del sistema integral de gestión de

restaurantes, pero para ello se estudia la tecnología existente en la

actualidad:

RestBar Software: es un programa ampliamente utilizado en

bares y restaurantes que incluye la facturación de mesas, ventas

rápidas y servicio exprés (delivery), recetas y costos, la caja

(ingresos y salidas de dinero), los inventarios de bebidas, bienes y

otros, control de entradas y salidas de empleados.


Página 28

Actualmente se usa en más de 16 países entre ellos España y es el

software habitual usado por los meseros para anotar las comandas

realizadas por cada cliente.

Este es el aspecto general del software utilizado:


Página 29

Además, en algunos restaurantes, en lugar de anotar las comandas

posteriormente sobre el ordenador general que recoge las comandas, se

ha implementado el software también para Pocket PC y así poder

registrar la comanda más rápidamente.

La versión para Pocket PC contiene básicamente la misma

funcionalidad que la otra versión, pero implemente algunas novedades

que se describen a continuación:

- Ingreso de comandas en la mesa del cliente.


Página 30

- Ingreso del número de Comensales en la mesa.

- Impresión del estado de la cuenta o cuenta parcial.

Este es el aspecto del software utilizado en Pockets PC:

DataHouse Company: es otra de las principales soluciones

software de gestión de restaurantes que se utiliza actualmente y

que incluye las siguientes funcionalidades principales:

- Mapa gráfico de mesas y cubiertos asignados.

- Gestión de entregas a domicilio.

- Panel de facturación rápida.

- Gestión de reserva de mesas.


Página 31

- Emisión de facturas en distintos idiomas.

- Gestión administrativa y contable.

En resumen, los restaurantes usan hoy en día dos tipos de soluciones

software para la gestión de sus restaurantes: software de gestión

corriente de comandas, y software para Pocket PC.

Existen múltiples soluciones para la gestión corriente de un

restaurante, sin embargo, todas estas soluciones no permiten que los

usuarios visualicen virtualmente el menú, accedan a información más

detallada como vídeos o imágenes y no ahorran el tiempo empleado a

que el camarero atienda las comandas y las transmita a la cocina.

El sistema que propone este proyecto propone unas funcionalidades

diferentes que optimizan la gestión general de las comandas y el tiempo

de atención a los clientes, y además de aprovechar el uso de la

tecnología de forma más eficiente y eficaz para el negocio, da un toque

de distinción y originalidad a los restaurantes que lo implementen.


Página 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 gestión de restaurantes.

Los objetivos serán de tipo funcionales y estratégico-económicos.

Como objetivos funcionales, se busca:

Aportar una mayor utilidad y conocimiento a los clientes acerca

del menú y los servicios que ofrece el restaurante, desplegando de

forma virtual el menú, con acceso a ingredientes, fotografías o

vídeos.

Ofrecer una mayor precisión en la información transmitida hasta

la cocina, evitando posibles errores humanos en la compresión de

las comandas por parte de los camareros.

Mejorar de manera sensible la transmisión y gestión general de

las comandas evitando tiempos de atención del camarero a los

clientes, y transmitiendo una información correcta, instantánea y

segura desde la mesa hasta la cocina.

Mejorar la gestión del reparto de trabajo en la cocina gracias a la

visualización de las comandas en tiempo real en el módulo de

cocina.


Página 33

Dotar a los restaurantes de información exacta y detallada, para

el estudio sobre los pedidos realizados por los clientes, los platos

más demandados, y los platos menos demandados, que permitirá

la importante toma de decisiones sobre actualizaciones en el

menú y otras decisiones que los gerentes crean oportunas.

Los objetivos estratégico-económicos que se persiguen son los

siguientes:

Motivar la demanda gracias a la inserción de publicidad,

promociones y sugerencias que lleguen directamente a los

clientes. Actualmente las posibilidades de incluir publicidad en

un restaurante son muy limitadas debido a motivos estéticos

principalmente, pero gracias a este sistema, se abre una nueva

puerta muy importante a la publicidad, que puede proporcionar

una mayor demanda, ya que los clientes que visitan un

restaurante, son clientes con una necesidad primaria de

consumir y por lo tanto, son clientes altamente potenciales.

Reducir la carga de trabajo para los meseros y por lo tanto,

posibilitar la reducción del número de ellos. Es posible que al

introducir el sistema de gestión, el número de meseros que se

necesiten sea inferior, ya que la carga de trabajo se reducirá

considerablemente, al no tener que atender a los clientes, tan sólo

transportando las comandas desde la cocina a las mesas, y

viceversa. Los meseros seguirán siendo necesarios para poder

atender correctamente a los clientes pero sin embargo, tendrán

menos trabajo que desempeñar.


Página 34

Optimización del tiempo, que implica posibilidad de acoger a un

mayor número de clientes. Al eliminar los tiempos necesarios en

atender a los clientes por parte de los meseros, y eliminar el

tiempo de transmisión de la comanda desde el mesero hasta la

cocina, la comanda se puede atender más rápidamente, los

clientes pueden terminar de comer antes, y por lo tanto, se

pueden atender un mayor número de clientes en el mismo día.

Actualmente una de las limitaciones principales en los ingresos

de los restaurantes, es el número de mesas disponibles para

poder atender a los clientes, por lo tanto, los restaurantes están

interesados en que sus clientes terminen de comer rápidamente,

pudiendo ofrecer el sitio libre a otros nuevos clientes. Con este

sistema, se facilitará esta situación.

Lograr una ventaja competitiva frente a otros restaurantes

marcando una estrategia de diferenciación, al implementar un

sistema, en el sector de la restauración, que se percibirá como

único, importante y exclusivo, y que aportará el placer de usarlo a

sus clientes.


Página 35

2.5 Alcance de la aplicación

El proyecto abarcará los objetivos detallados anteriormente, para poder

llevarlos a cabo se implementarán las siguientes funcionalidades en el

sistema:

Gestión del menú virtual: se mostrará información detallada

sobre la composición y elaboración de los platos.

Gestión de las comandas: se transmitirá directamente, desde la

mesa de los clientes, a través de una pantalla, las peticiones que

se realicen hasta un módulo en la cocina, donde se podrá

visualizar quién ha realizado la comanda, y en qué consiste.

Gestión de la economía: se podrá mostrar, en el módulo de

cocina, toda la información referente a la cantidad de comandas

realizadas y atendidas, el plato más pedido y el de menor

demanda, así como un resumen de la facturación realizada hasta

el momento que será de gran utilidad para el seguimiento y

control del negocio.

Gestión de la instalación: a través del módulo de cocina, se

gestionará toda la actividad que se realice en el salón, así como la

disposición de las mesas en el restaurante, y los clientes.

Gestión de las sugerencias, promociones y publicidad: el gerente

del restaurante, podrá introducir todas sus ofertas a través del

menú virtual directamente a sus clientes.


Página 36

2.6 Restricciones

En este apartado se hace referencia a las principales restricciones que

afectan al proyecto.

Para el desarrollo de la aplicación, concretamente para el desarrollo del

menú virtual se usarán bases de datos compuestas por información no

específica de un solo restaurante, sino que se mezclarán datos que

ofrecen distintos restaurante, a modo de prueba.

Además existen otro tipo de restricciones:

- Temporales: el proyecto se deberá entregar dentro de la

fecha límite establecida, que es en Septiembre de 2010.

- Económicas: no se dispone del dinero necesario para la

implantación real del sistema en un restaurante, así como

de las pantallas táctiles que se implantarían en las mesas

de los clientes, por lo que se desarrollará únicamente toda

la lógica y el software que lo compone.

- Organizativas: el proyecto debe ser desarrollado por una

sola persona, Gorka Díaz de Orbe.

3) Análisis de requisitos


Página 38

3. ANÁLISIS DE REQUISITOS

En esta etapa se busca tener un concepto claro de las necesidades,

problemas y requisitos del usuario. Es necesario tener un conocimiento

claro acerca del sistema para poder profundizar y proponer una

solución de la mejor forma posible.

A continuación se realiza un primer y básico análisis de la aplicación.

Para ello, se comienza con una introducción, una descripción del

sistema actual, una lista de requisitos que permite introducir el modelo

lógico del nuevo sistema, el diccionario de datos y el modelo conceptual

de datos.

3.1 Ámbito del proyecto

En este apartado se especifican las funciones a desarrollar identificadas

como necesidades, se muestra cómo el usuario se relacionará con el

sistema y éste a su vez con la base de datos que servirá para visualizar

el menú virtual, registrar las comandas y mostrarlas al módulo de

mesa.

A continuación se muestra un diagrama del funcionamiento general del

sistema:


Página 39

Cliente 1 Pantalla táctil

Cliente 2 Pantalla táctil Servidor Módulo de cocina

Cliente n Pantalla táctil Base de datos

Como se puede apreciar en el diagrama, los clientes recibirán del

servidor, que obtiene la información de la base de datos, las

posibilidades que ofrece el restaurante en su menú, y estos una vez que

hayan elegido, enviarán sus comandas sobre el servidor, que mostrará

al módulo de cocina las peticiones de los clientes actualizándose la base

de datos.


Página 40

3.2 Contexto general del sistema

A continuación se muestra un diseño del sistema, en el cual se puede

apreciar una vista desde los clientes, que seleccionan sus comandas

desde las mesas.

La comunicación se establecería en dos sentidos, desde los módulos de

mesa al servidor, y desde el módulo de cocina al servidor.

La comunicación con el servidor que contiene la base de datos, en

ambos sentidos, se realizaría a través de una conexión local inalámbrica

como se puede ver reflejado en el diseño.


Página 41

Además, para una mejor comprensión del módulo de mesa, se procede

a incluir un diseño a continuación en el que se refleja la conexión

inalámbrica que se realiza desde el módulo hasta el servidor, y algunos

detalles de diseño físicos, para que las pantallas no molesten a los

usuarios a la hora de consumir en el restaurante.


Página 42


Página 43

3.3 Funciones primarias afectadas

En este apartado, se analizan las funciones actuales que se verán

afectadas por la implantación de la aplicación.

A continuación se muestra el procedimiento habitual del

funcionamiento de un restaurante, y posteriormente, las modificaciones

pertinentes debido a la instalación del nuevo sistema de gestión.


Página 44

Mesa libre

Acomodar

Bienvenida

Orden de bebidas

y aperitivos

Comida

Tramitar comanda

¿ Algo más ?

no

Cobrar y despedir

no

Bebidas

no

no

si

En el siguiente diagrama se representa el nuevo funcionamiento de la

gestión de un restaurante, donde las funciones primarias se seguirán

realizando pero en este caso, algunas de ellas, las realizará el sistema.


Página 45

Mesa libre

Acomodar y

presentación del

sistema

Bienvenida

Orden de bebidas

y aperitivos directo

a cocina

Comida

Tramitar comanda

directamente a

cocina

¿ Algo más ?

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:


Página 46

1. Bienvenida: La principal función del mesero encargado del

salón es dar la bienvenida los clientes y preguntarles la cantidad

de personas que ocuparán la mesa. Inmediatamente, se buscará

un sitio disponible si existe y después deberá acomodarlos en la

mesa. Aquellos establecimientos que dispongan de áreas de

fumadores y no fumadores, se colocará al cliente según la

predilección.

Una vez en la mesa, el camarero debe acomodarlos sacando las

sillas, teniendo preferencia las damas. El mesero encargado del

salón procederá a registrar los clientes en el registro y control de

reservaciones, colocando la cantidad de clientes, la hora y el

número de mesa asignado.

2. Orden de bebidas y aperitivos: Una vez abordados los clientes

y después de darle la bienvenida, el camarero preguntará si el

cliente desea algún aperitivo, vino o cóctel antes de ver la carta.

Después de servir los cócteles el camarero debe preguntar si los

clientes desean algún entremés. Después de servido el entremés,

el camarero debe preguntar si desean repetir sus bebidas o

prefieren ver la carta. En caso de que el cliente solicite ver la

carta, la misma será entregada por el camarero.

3. Tramitar comandas: se atiende a los clientes, y se anotan las

comandas. El camarero que ha tomado la comanda, debe hacerla

entregar de inmediato, no olvidando apuntar en ésta la hora

exacta en que se terminó de tomar, la entrega al camarero de


Página 47

cocina, o sea, al ayudante o camarero encargado de transportar

los platos de la cocina al comedor y viceversa.

La distribución de las copias de la comanda se realiza según el

estándar del establecimiento, que generalmente es de la manera

siguiente: la original a cocina, una copia a la caja y una segunda

copia al camarero de cocina.

Las comandas deberán pasar primeramente por la caja, para que

la cajera verifique si concuerdan las copias y ésta sellará o

firmará las que irán a la cocina, se quedará con la que le

corresponde y devolverá el resto de las copias al Camarero, quien

inmediatamente deberá dirigirse a la cocina y entregar la

comanda al supervisor. Este canta el pedido y la cocina funciona.

4. La despedida: el servicio termina con la despedida al cliente.

El momento de la despedida es muy importante, ya que es la

última impresión que el cliente se lleva del establecimiento.

Es responsabilidad camarero despedirlo en la mesa cuando se

levanta y en la puerta debe despedirlo el mesero encargado del

salón.

El nuevo sistema seguirá contando con los camareros para guardar la

importante imagen del restaurante y atender a los clientes, pero se

mejorará el proceso, haciendo esperar menos a los clientes,

ofreciéndoles mayor información, y evitando errores en la transmisión

de la información hasta la cocina.


Página 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 módulo

de mesa que pueden encontrar.

2. Orden de bebidas: en este caso, el sistema ofrecerá bebidas,

aperitivos y todas aquellas sugerencias pertinentes antes de que

los clientes hayan tomado la decisión sobre el menú. La

comanda se transmitirá directamente desde la mesa de los

clientes a la cocina, sin tener que necesitar la atención del

camarero.

3. Tramitar comandas: después de que los clientes hayan

decidido su selección a través del menú virtual, se confirmará la

comanda, y se transmitirá directamente hasta la cocina, sin

necesidad de atención del camarero.

En la cocina, se recibirá la comanda realizada, y se podrá

visualizar a través del módulo. Se atenderá la comanda y se

editará una vez que haya sido atendida. Todo este proceso se

registra en la base de datos para en un futuro, realizar un

análisis.

4. La despedida: este servicio no variará, el camarero seguirá

realizándolo de la forma habitual.


Página 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 implantación del

sistema, pero que es importante conocer en detalle para una mejor

comprensión del alcance y funcionamiento general de un restaurante.

Se representa a continuación, un diagrama que muestra el curso de las

órdenes de compra y pago de un restaurante, así como de los

participantes implicados:


Página 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 límite mínimo de existencia de los mismos, en tal caso

inicia el procedimiento de compra de materiales.

2. Posteriormente el chef o el mesero confecciona una solicitud de

compra de mercaderías por duplicado.

3. El jefe del departamento de administración, verifica, estudia y

aprueba los datos de solicitud de compra.

4. Después de su aprobación, se selecciona el proveedor adecuado

según la orden emitida.


Página 51

5. Se envía la orden de compra por duplicado: emite el original al

proveedor, el duplicado lo guarda para su control y luego lo

archiva. Archiva el original de la solicitud de compra y espera la

llegada de las mercaderías.

6. A continuación, el proveedor recibe el remito, y lo reenvía por

triplicado, envía a la administración las mercaderías junto con el

original y una copia.

7. Después, la administración controla las mercaderías recibidas

con el duplicado de la orden de compra (archivada

provisoriamente), el original y el duplicado del recibo, enviados

por el proveedor, distribuye la documentación, se firma el

duplicado del recibo y lo envía al proveedor.

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

administración.

9. Por último, la administración controla la factura con los recibos

que se habían archivado y se verifica el cumplimiento de los

plazos y lugares de entrega.


Página 52

3.3.2 Modificaciones sobre el funcionamiento

A continuación se representa de forma gráfica el funcionamiento de la

gestión de las comandas de un restaurante, y posteriormente se

procederá a analizar de forma detallada las mejoras que supondrá la

implantación del sistema.

En este caso, se producirá un gran impacto en el funcionamiento

habitual, mejorando especialmente, el tiempo de atención del mesero al

cliente, el tiempo de transmisión de la comanda desde el mesero al

cliente, la calidad de la información ofrecida a los clientes, y la calidad

de la información transmitida desde la mesa hasta la cocina.

En el gráfico que se aprecia a continuación, se representan los procesos

habituales de un restaurante, antes de la implantación del sistema.


Página 53

Llegada nuevo

cliente

Espera de

bienvenida

Acomodamiento

y muestra del

menú

Espera de

decisión de la

comanda

Espera de tiempo

de atención del

camarero

Toma de la

comanda

Espera de tiempo

transmisión de la

comanda

Espera

preparación de la

comanda

Entrega de la

comanda

Tiempo de

consumo

Despedida de

cliente


Página 54

A continuación, el gráfico que representa el nuevo funcionamiento,

ahorrando distintos tiempos en el proceso:

Llegada nuevo

cliente

Espera de

bienvenida

Acomodamiento

y muestra del

menú

Espera de

decisión de la

comanda

Toma de la

comanda

Espera

preparación de la

comanda

Entrega de la

comanda

Tiempo de

consumo

Despedida de

cliente


Página 55

Como se puede observar, se han representado las actividades que deben

atender los meseros, en círculos, y las esperas que se realizan en todo el

proceso de consumo del cliente, en rectángulos.

En el primer diagrama, se ha enmarcado en rojo, los tiempos que

desaparecerán tras la implantación del sistema. Se puede observar

como el tiempo de espera de atención al cliente, y el tiempo de

transmisión de la comanda, desaparecen en el segundo diagrama,

variando así, el proceso habitual y mejorando por tanto la atención y el

servicio al cliente.

Estos dos tiempos comentados anteriormente, desaparecen ya que la

información se comunicará directamente de forma transparente, desde

los clientes, hasta la cocina, llegando las comandas de forma inmediata,

y acelerando por tanto, el proceso.

Actualmente, una de las limitaciones más importantes de los

restaurantes, especialmente aquellos de comida rápida, es el número de

clientes que pueden albergar en su interior.

La modificación de este proceso, está especialmente diseñado, para

acelerarlo, evitando tiempos largos, los clientes tendrán el servicio

requerido con mayor prontitud, y por lo tanto, además de quedar más

satisfechos por la rapidez, podrán liberar antes sus plazas para la

acogida de nuevos clientes.


Página 56

En definitiva, el restaurante será capaz de atender a más clientes, y de

mejor manera, en el mismo día, gracias a la implantación del sistema

integral de gestión de restaurantes.


Página 57

3.4 Unidades de la organización afectadas por la mecanización

En este apartado se detallan las áreas afectadas por el proyecto actual,

mediante una tabla en la que el grado con que se altera el

funcionamiento de un determinado proceso se determina por el

siguiente código.

0: Nada afectado.

1: Poco afectado.

2: Muy afectado.

Funciones Perfiles

Gerente Chef Ayudante

de cocina

Mesero

encargado

del salón

Meseros

1.- Gestión del

menú

1 2 2 1 1

2.- Gestión de

las comandas

0 2 2 1 1

3.-Gestión de

la economía

2 1 0 0 0

4.-Gestión de

instalaciones

0 1 1 1 1

5.-Gestión de

la publicidad

2 0 0 0 0


Página 58

En las siguientes líneas se explican los resultados obtenidos en la

anterior tabla, que representa el alcance del sistema, los perfiles

afectados en cada eje, y en el interior, una valoración con un resultado

cualitativo del impacto.

1. Gestión del menú virtual: el menú virtual es la base del

funcionamiento de todo el sistema, es por ello que todos los

perfiles representados se verán afectados por su implantación.

Concretamente, el que mayor impacto tendrá sobre el menú, será

el chef, que es el encargado de diseñar los platos para el

restaurante. Además, los ayudantes de cocina también

participarán activamente en este diseño, el gerente deberá dar su

aprobación, y los meseros deberán conocer con detalle la

composición y funcionamiento del nuevo menú.

2. Gestión de las comandas: en este caso, la tramitación de las

comandas afectará especialmente en la cocina, al chef y a los

ayudantes de cocina ya que son los encargados de visualizar y

atender las comandas a través del módulo correspondiente. Tanto

el mesero encargado del salón, como el resto de meseros, deberán

participar en la tramitación de comandas en caso de algún

problema o duda por parte de los clientes, aunque en principio, el

sistema está diseñado para que no tengan que participar

prácticamente nada.

3. Gestión de la economía: todas las comandas que se realicen en

el restaurante, pasarán por el servidor y este a su vez, las

registrará en la base de datos. Toda esta información será de

especial interés para el gerente, ya que en función de la demanda,


Página 59

adoptará unas medidas u otras respecto a la buena marcha del

negocio.

4. Gestión de las instalaciones: el reparto de mesas y la

disposición de los clientes, quedará registrado en el sistema, y

será una información importante tanto para los trabajadores de la

cocina como para los trabajadores del salón.

5. Gestión de la publicidad: el gerente deberá decidir en este caso,

qué sugerencias desea incluir para sus clientes, qué promociones

puede lanzar o incluso, puede decidir vender un cierto espacio a

terceras empresas o restaurantes socios para promocionarlos a

través del sistema.


Página 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

capítulo de Identificación de Necesidades, y se han recogido en forma de

fichas individuales, fácilmente identificables y que ayudarán al diseño

del nuevo sistema.


Página 61

Proyecto: Sistema Integral de Gestión de Restaurantes

Jefe de proyecto: Gorka Díaz de Orbe

Requisitos

Título Entorno de fácil uso.

Identificador R-01 Fecha 25/03/2010

Versión 1.0 Prioridad Media

Estado Aceptado Categoría Funcional

Descripción Diseño de un interfaz cómodo de fácil de uso para los usuarios.

Medición

Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de

pruebas que validen su correcto funcionamiento.

Beneficios

Tener un interfaz agradable, de uso fácil y claro facilita el trabajo al usuario y como

consecuencia, rentabiliza el trabajo al máximo, eliminando tiempos adicionales por un

mal diseño de la aplicación.

Comentarios / Soluciones sugeridas

La aplicación debe estar pensada para interactuar con ella de forma fácil e intuitiva. Debe

ser apto para las manos, con botones lo suficientemente grandes, sin demasiada

información, y sencillez.

Documentos relacionados

Ninguno

Requisitos relacionados

Ninguno


Página 62



Requisitos

Título Gestión del menú virtual.


Versión 1.0 Prioridad Alta


Descripción La aplicación permitirá el alta/baja/modificación de los datos que se

representará en el menú virtual.

Medición

Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de pruebas

que validen su correcto funcionamiento.

Beneficios

Tratará de innovar en la presentación del menú a los clientes, ofreciéndoles mayor

simplicidad, información, y rapidez a la hora de realizar las comandas.


Este requisito se desarrollará en el módulo de mesa. Existirá una base de datos, de la cual se

obtendrá el menú.


Ninguno


R-03/ R-04


Página 63



Requisitos

Título Gestión de las imágenes del módulo de mesa.


Versión 1.0 Prioridad Baja


Descripción La aplicación permitirá el alta/baja/modificación de las imágenes que

se representarán en el menú virtual.

Medición



Beneficios


simplicidad, información, y permitirá mostrar las imágenes de los platos que ofrece el

restaurante.



obtendrá el menú.


Ninguno


R-04


Página 64



Requisitos

Título Gestión de los vídeos del módulo de mesa.


Versión 1.0 Prioridad Baja


Descripción La aplicación permitirá el alta/baja/modificación de los vídeos que se

representarán en el menú virtual.

Medición



Beneficios


simplicidad, información, y permitirá mostrar vídeos de los platos que ofrece el restaurante.



obtendrá el menú.


Ninguno


Ninguno


Página 65



Requisitos

Título Gestión de las comandas.




Descripción La aplicación permitirá el alta/baja/modificación de las comandas

que realicen los clientes a través del módulo de mesa.

Medición



Beneficios

Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará una

mayor información en la gestión.


Los clientes podrán seleccionar los platos del menú que desean consumir, se registrarán en la

base de datos, y se mostrará posteriormente en el módulo de cocina.


Ninguno


R-06


Página 66



Requisitos

Título Gestión de los ingredientes.




Descripción La aplicación permitirá el alta/baja/modificación de los

ingredientes que componen cada plato.

Medición

Este requisito deberá estar recogido en la aplicación y será objeto de un conjunto de

pruebas que validen su correcto funcionamiento.

Beneficios

Se trata de una funcionalidad no recogida en los sistemas actuales. Por tanto aportará

una mayor información en la gestión.


El sistema permitirá registrar la información referente a la composición de cada plato, y

los clientes tendrán acceso a esta información a través del módulo de cocina.


Ninguno


Ninguno


Página 67



Requisitos

Título Gestión de la economía.




Descripción La aplicación permitirá una gestión eficiente de los datos económicos

del restaurante.

Medición

Se registrará en la base de datos, el consumo que realiza cada cliente, el precio de cada plato

y la suma total de todas las consumiciones.

Beneficios

A pesar de tratarse de una funcionalidad recogida en los sistemas informáticos actuales,

supondrá un valor añadido al formar parte de la plataforma integral que contiene todos los

módulos necesarios para la gestión de restaurantes.


Sólo en el módulo de cocina se podrá tener acceso a la información, a través de una interfaz

intuitiva, que mostrará el resumen principal de los datos económicos.


Ninguno


R-08 / R-21


Página 68



Requisitos

Título Gestión de la facturación.




Descripción La aplicación permitirá el alta/baja/modificación de los datos de las

facturas.

Medición



Beneficios





Sólo en el módulo de cocina se podrá tener acceso a la información, a través de una interfaz

intuitiva, que mostrará el resumen principal de las facturas.


Ninguno


R-21


Página 69



Requisitos

Título Gestión de las instalaciones.




Descripción La aplicación permitirá una gestión eficiente de las instalaciones del

restaurante. Para ello se deben desarrollar los siguientes submódulos:

gestión del salón y gestión de la cocina.

Medición

El sistema estará compuesto por el módulo de mesa, de acceso a los clientes, que gestionará

el salón, y el módulo de cocina, que se implantará en la cocina.

Beneficios




El acceso a los distintos módulos se realizará según estén ubicados físicamente, puede ser

desde la cocina, o desde el salón.


Ninguno


R-10 / R-11


Página 70



Requisitos

Título Gestión del salón.




Descripción La aplicación permitirá una gestión eficiente de los módulos que se

encuentren en el salón del restaurante.

Medición



Beneficios




El acceso se realizará desde los módulos de mesa, situados en las mesas de los clientes.


Ninguno


R-11


Página 71



Requisitos

Título Gestión de la cocina.




Descripción La aplicación permitirá una gestión eficiente de los módulos que se

encuentren en la cocina del restaurante.

Medición



Beneficios




El acceso se realizará desde el módulo de cocina, desde el cual se tendrá acceso a información

detallada sobre las comandas y la disposición de los clientes, así como de la facturación.


Ninguno


R-10


Página 72



Requisitos

Título Gestión de la publicidad.




Descripción La aplicación comprenderá una gestión eficiente de la publicidad,

compuesta por la promoción y sugerencias que ofrece el restaurante a

sus clientes.

Medición

Este requisito se implantará en el módulo de mesa de los clientes.

Beneficios


mayor funcionalidad y mejora del negocio para el restaurante.


La publicidad y sugerencias que desee realizar el restaurante, se mostrarán en los módulos

de mesa directamente a los clientes, estimulando la demanda o vendiendo el espacio

publicitario a terceras empresas.


Ninguno


R-14


Página 73



Requisitos

Título Gestión del personal.




Descripción La aplicación permitirá una gestión eficiente de la gestión del personal

de restaurante, diferenciando entre el personal de cocina o el personal

de salón.

Medición

El módulo de gestión de personal se compondrá de los módulos de cocina y de salón,

diferenciando en ambos grupos los distintos trabajadores.

Beneficios




El sistema se compondrá de un módulo de cocina y de un módulo de mesa, desde cada uno,

se tendrá acceso a una información diferente y se gestionará el personal según sea el acceso.


Ninguno


R-15 / R-16


Página 74



Requisitos

Título Gestión de las sugerencias.




Descripción La aplicación comprenderá una gestión eficiente de las sugerencias

que desee hacer el chef a los clientes del restaurante.

Medición

Este requisito se implantará en el módulo de mesa de los clientes.

Beneficios




Las sugerencias que desee realizar el restaurante, se mostrarán en los módulos de mesa

directamente a los clientes, estimulando la demanda.


Ninguno


Ninguno


Página 75



Requisitos

Título Gestión del personal de cocina.




Descripción La aplicación permitirá una gestión eficiente del personal de la cocina,

que estará compuesto por el chef y sus ayudantes.

Medición



Beneficios




El sistema controlará el acceso del módulo de cocina, y según el perfil, los trabajadores

tendrán acceso a información específica, como la gestión de las comandas o la gestión del

menú virtual.


Ninguno


Ninguno


Página 76



Requisitos

Título Gestión del personal de salón.




Descripción La aplicación permitirá una gestión eficiente del personal de salón,

que estará compuesto por el encargado y los camareros.

Medición



Beneficios




El sistema controlará el acceso del módulo de cocina, y según el perfil, los trabajadores

tendrán acceso a información específica, como la gestión de la publicidad o la gestión del

menú virtual.


Ninguno


Ninguno


Página 77



Requisitos

Título Gestión de las tareas.




Descripción La aplicación permitirá una gestión eficiente de las tareas pendientes

por realizar, y las tareas realizadas.

Medición

Este requisito se implantará en el módulo de cocina.

Beneficios




El sistema gestionará las tareas que no han sido aún atendidas y aquellas que ya se han

atendido, se marcarán como satisfechas, permitiendo así una mejor gestión de las comandas

en la cocina.


Ninguno


Ninguno


Página 78



Requisitos

Título Gestión de los restaurantes.




Descripción La aplicación permitirá una gestión eficiente de los distintos

restaurantes en los cuales esté implantado el sistema.

Medición



Beneficios




El sistema permitirá, en aquellos casos en los que existan varios restaurantes pertenecientes

a la misma empresa, imprimir la información sobre datos de los distintos negocios para su

posterior análisis.


Ninguno


Ninguno


Página 79



Requisitos

Título Gestión de los cobros.




Descripción La aplicación permitirá una gestión eficiente de los distintos

restaurantes en los cuales esté implantado el sistema.

Medición



Beneficios





Este requisito se desarrollará en un módulo de cocina. Debido a la multitud de datos

presentes en la base de datos de la aplicación, los informes resultarán útiles a la dirección.


Ninguno


Ninguno


Ninguno


Página 80



Requisitos

Título Login como precondición de acceso al sistema.




Descripción Para la realización de todas las operaciones que la aplicación

permitirá, se requerirá el empleo de un login inicial que permita

conectarse a la misma sólo los empleados registrados. De este modo,

se evitarán intrusismos.

Medición



Beneficios

Gracias a la implementación de este requisito se conseguirá filtrar los accesos a la aplicación

y se permitirá una adaptación de las tareas permitidas a los usuarios según su perfil.


Para la verificación del usuario y contraseña se acudirá a la tabla de empleados en la que se

almacenan estos datos. La administración del perfil se realizará según esa misma tabla.


Ninguno


Ninguno


Página 81



Requisitos

Título Gestión de los informes.




Descripción La aplicación creará informes sobre las comandas pendientes,

atendidas y los datos de la facturación obtenida.

Medición



Beneficios





Este requisito se desarrollará en un módulo de cocina. Debido a la multitud de datos

presentes en la base de datos de la aplicación, los informes resultarán útiles a la dirección.


Ninguno


R-07 / R-08


Ninguno


Página 82

3.6 Modelo lógico de datos

En este apartado se analiza el modelo lógico del nuevo sistema. Para su

obtención se ha partido del análisis del sistema actual y de la lista de

requisitos del sistema.

3.6.1 DFD contextual

A continuación, se muestra el DFD contextual de la aplicación a

desarrollar, donde se representa las entidades externas y el sistema.

El sistema se interrelacionará con dos tipos de usuarios diferentes,

ofreciéndoles a cada uno una información diferente, y recibiendo

también unas entradas diferentes. Uno de los usuarios serán los

clientes que accederán desde el módulo de mesa al menú virtual y

realizarán sus comandas, y otro usuario será el personal de cocina, que

atenderá las comandas, las editará según se vayan atendiendo, y

además tendrán acceso a otros módulos del sistema que se han

especificado en la lista de requisitos anteriormente.

0

Sistema Integral

de Gestión de

Restaurantes

Usuario

cliente

Usuario

cocina

entradas salidas

salidas entradas


Página 83

3.6.2 DFD conceptual

A continuación, se muestra el DFD conceptual del sistema. Para mayor

claridad, se representará por niveles, lo que facilitará la comprensión

del mismo.

3.6.2.1 DFD conceptual de primer nivel

En este apartado, se presenta el DFD conceptual de primer nivel, que

muestra el funcionamiento global de la aplicación, que se descompone

en los cuatro módulos descritos a continuación:

Menú virtual: permitirá mostrar el menú de forma virtual,

actualizarlo, recibir sugerencias y promociones, enviar una

selección de comandas y mostrar el total a pagar después de

haber consumido.

Comandas: se recibirán las comandas del menú virtual, se

mostrarán por pantalla en el módulo de cocina, y se guardarán en

una base de datos para sacar informes.

Publicidad: se usará este módulo para aplicar promociones a los

clientes, mostrar sugerencias o publicidad en el menú virtual

Informes: leerá la información pertinente de la base de datos

para sacar estadísticas e informes de interés al gerente del

restaurante.


Página 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

opción


Página 85

En el diagrama anterior se ha representado el flujo de la información en

el sistema, a continuación se detallan todos los componentes que

intervienen en el mismo:

1. Login: proceso que controla el acceso a la aplicación, verificando

que el usuario que está entrando en el sistema, es un empleado,

según los permisos que tenga tendrá un acceso posterior para el

acceso de informes, y la inserción de publicidad, o bien sólo la

visualización y edición de comandas en el módulo de cocina.

2. Menú principal: será el punto de partida de la aplicación. Desde

este menú se podrán gestionar las promociones y publicidad, el

menú virtual, las comandas y los informes.

3. Publicidad: proceso que gestiona las sugerencias, promociones y

publicidad que se mostrarán a los clientes. Se detallará a

continuación su funcionamiento a través de otro diagrama de

flujo de datos.

4. Menú virtual: proceso que gestiona el menú virtual que se

mostrará a los clientes, así como el envío de la comanda una vez

haya sido seleccionada. Se detallará a continuación su

funcionamiento a través de otro diagrama de flujo de datos.

5. Comandas: proceso que gestiona todas las comandas que

realizan los clientes y que se envían a la cocina, para

posteriormente mostrarlo en el módulo. Además, agrupará las

comandas de una misma mesa y las enviará a una base de datos

de facturas para posteriormente obtener informes. Se detallará a


Página 86


flujo de datos.

6. Informes: proceso que gestiona la obtención de informes a partir

de comandas realizadas por los clientes. Se detallará a


flujo de datos.


Página 87

MINIESPECIFICACIONES

Tipo Nombre Atributos Descripción

Proceso Login - Proceso encargado de

controlar el acceso a la

aplicación.

Proceso Menú principal - Proceso que genera un

menú personalizado con

distintas opciones en

función del usuario y de

su perfil.

Proceso Publicidad - Proceso que gestiona las

sugerencias, promociones

y publicidad que se

mostrarán a los clientes.

Proceso Menú virtual - Proceso que gestiona el

menú virtual que se

mostrará a los clientes,

así como el envío de la

comanda una vez haya

sido seleccionada.

Proceso Comandas - Proceso que gestiona

todas las comandas que

realizan los clientes y que

se envían a la cocina,

para posteriormente


Página 88

mostrarlo en el módulo.

Además, agrupará las

comandas de una misma

mesa y las enviará a una

base de datos de facturas

para posteriormente

obtener informes.

Proceso Informes - Proceso que gestiona la

obtención de informes a

partir de comandas

realizadas por los

clientes.

Flujo de

datos

Empleado - Clave de usuario.

Necesario para acceder a

la aplicación.

Flujo de

datos

Password - Contraseña del usuario.

Flujo de

datos

Sugerencia a

cliente

- Envío al menú virtual del

cliente, las sugerencias

del restaurante si

procede.

Flujo de

datos

Menú a cliente - Impresión en el módulo

de mesa, del menú

confeccionado para el

cliente, con las

sugerencias pertinentes.

Flujo de Comanda - Envío de la comanda


Página 89

datos desde el módulo de mesa

al módulo de gestión de

comandas para su

registro.

Flujo de

datos

Aviso a cocina

- Envío de la comanda

registrada, al módulo de

cocina.

Flujo de

datos

Factura - Envío de todas las

comandas realizadas por

un mismo cliente a lo

largo de su estancia, para

agruparlas, tratarlas y

obtener el total a pagar

posteriormente.

Flujo de

datos

Informe - Impresión de los informes

de carácter económico al

gerente del restaurante.

Almacén de

datos

EMPLEADOS ID_EMP, PASS Registra las acciones

relacionadas con los

usuarios.

Almacén de

datos

SUGERENCIAS ID_SUG,

DESCR

Información sobre las

sugerencias que ofrece el

restaurante.

Almacén de

datos

MENÚ ID_PLATO,

INGRED,

DESC,

Información sobre el

menú, y los ingredientes

de los que dispone el


Página 90

PRECIO_UNIT restaurante.

Almacén de

datos

COMANDAS MESA,

FECHA,

HORA,

ID_PLATO,

CANT


comandas que van

realizando los clientes y

que se visualizarán en la

cocina.

Almacén de

datos

FACTURAS ID_COMANDA,

TOTAL,

FECHA, HORA

Información sobre la

facturación total del

restaurante, para cada

día.


Página 91

3.6.2.2 DFD conceptual de segundo nivel. Módulo publicidad.

A continuación, se muestra un diagrama del módulo publicidad, que ha

sido anteriormente recogido en R-14 en la lista de requisitos:

3.1

Alta

sugerencia

3.2

Modificación

sugerencia

3.3

Baja

sugerencia

3.4

Aplicar

sugerencia

SUGERENCIAS

sugerencia

Solicitud modificación

Solicitud baja

Solicitud alta


Página 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

inserción en la base de

datos.

Proceso Modificación

sugerencia

- Este proceso modifica

una sugerencia del

restaurante de la base de

datos. Necesita que el

administrador del sistema

envíe la orden.

Proceso Baja sugerencia - Este proceso elimina una

sugerencia del

restaurante de la base de



envíe la orden.

Proceso Aplicar

sugerencia

- Este proceso verifica las

promociones existentes

para los clientes, y en

caso de que exista

alguna, la envía al


Página 93

módulo de mesa.

Flujo de

datos

Solicitud alta - Solicitud por parte del


de crear una nueva

sugerencia.

Flujo de

datos

Solicitud

modificación

- 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 - Envío de la sugerencia

encontrada, directamente

al cliente.

Almacén de

datos

SUGERENCIAS ID_PLATO,

SUGER


sugerencias que ofrece el

restaurante, con un

campo que identifica al

plato sugerido y la

descripción que se

mostrará a los clientes.


Página 94

3.6.2.3 DFD conceptual de segundo nivel. Módulo menú virtual.

A continuación, se muestra un diagrama del módulo menú

virtual, que ha sido anteriormente recogido en R-02 en la lista de

requisitos:

4.1

Procesar menú

4.2

Alta menú

4.3

Baja menú

4.5

Enviar

selección

MENÚ

Solicitud baja

sugerencia

menú

Solicitud alta

4.4

Modificación

menú


comanda


Página 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.


menú

- Este proceso modifica el

menú del restaurante de


que el administrador del

sistema envíe la orden.

Proceso Baja menú - Este proceso elimina el

menú del restaurante de




Proceso Procesar menú - Este proceso muestra el

menú al cliente, según las

sugerencias particulares

que el restaurante le

ofrece, y después guarda

la selección del usuario

para procesarla como


Página 96

comanda junto con otro

proceso.

Proceso Enviar selección - Este proceso envía la

comanda del cliente, a la

cocina, una vez que se la

han mostrado las

promociones y

sugerencias en el menú.

Flujo de

datos

Solicitud alta - Solicitud por parte del


de crear un nuevo menú.

Flujo de

datos

Solicitud

modificación



de modificar el menú.

Flujo de

datos



de dar de baja el menú.

Flujo de

datos

Comanda - Envío de la comanda

realizada por el cliente,

directamente a la cocina.

Almacén de

datos

MENÚ ID_PLATO,

INGRED,

DESCR,

Información sobre los

platos que componen el

menú y que se mostrará a


Página 97

URL,

PRECIO_UNIT

los clientes junto con su

descripción

correspondiente, una url

del vídeo o foto

ilustrativo, ingredientes y

precio


Página 98

3.6.2.4 DFD conceptual de segundo nivel. Módulo comandas.

A continuación, se muestra un diagrama del módulo comandas, que ha


5.1

Alta comanda

5.2

Baja comanda

COMANDAS

Solicitud baja

comanda

5.3

Modificación

comanda


Comanda a cocina

5.4

Procesar

comanda


Página 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.


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

módulo de cocina,

después de haberse

guardado en la base de

datos, y a su vez, envía la


Página 100

comanda a otro proceso

para que se registre en la

base de datos de

facturación para su

posterior estudio.

Flujo de

datos

Comanda - Recepción por parte del

cliente de su comanda, y

registro en la base de

datos, después se

mostrará en la cocina.

Flujo de

datos

Solicitud

modificación



de modificar la comanda.

Flujo de

datos



de dar de baja una

comanda.

Flujo de

datos

Comanda a

cocina

- Impresión en el módulo

de cocina, de la comanda,

y envío al módulo de

facturación la misma

para su proceso.

Almacén de

datos

COMANDAS ID_CLI,

MESA,

FECHA,

HORA,

ID_PLATO,

Información sobre la

comanda que ha realizado

el cliente, incluyendo un

número que le

identifique, su mesa, la


Página 101

CANT fecha y hora, los platos

que pide, y la cantidad de

cada uno de ellos.


Página 102

3.6.2.5 DFD conceptual de segundo nivel. Módulo informes.

A continuación, se muestra un diagrama del módulo informes, que ha


6.1

Alta factura

6.2

Modificación

factura

6.3

Baja factura

6.4

Informe

facturación

FACTURAS

informe


Solicitud baja

Comanda a cocina


Página 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 inserción en la

base de datos.


factura

- Este proceso modifica

una factura de la base de



envíe la orden.

Proceso Baja factura - Este proceso elimina una

factura de la base de



envíe la orden.

Proceso Informe de

facturación

- Este proceso imprime un

informe de la facturación

del restaurante,

utilizando la información


Página 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

modificación



de modificar una factura

de la base de datos.

Flujo de

datos



de dar de baja una

factura.

Flujo de

datos

Informe - Informe de facturación

con todos los datos

correspondientes a la

actividad del restaurante.

Almacén de

datos

FACTURAS ID_CLI,

TOTAL,

FECHA,

HORA


facturas que ha realizado

el restaurante a sus

clientes, a partir de las

comandas.


Página 105

3.6.3 Modelo conceptual de datos.

El modelo conceptual de datos trata de modelar la gama de información

que manejará el nuevo sistema. Este modelo se obtiene a partir de la

situación actual y de los requisitos previamente establecidos.

El modelo conceptual describe las características principales de los

datos del sistema. De forma similar al modelo de procesos analizado

anteriormente, el modelo de datos consta de dos elementos: un

esquema grafico y una especificación de los componentes de ese

esquema.

Para la realización de esta metodología se ha seguido el libro [BARR01]

que aparece en la bibliografía.

El modelo conceptual describe las entidades, atributos y relaciones de

interés para el negocio a representar. Este modelo deberá ser

independiente del hardware y software utilizado para el manejo de los

datos.

Para la realización de este apartado se utilizará un método de análisis

de datos basado en el análisis entidad-relación que consta de los

siguientes elementos:

- Entidades. Son objetos que tienen una existencia propia

conforme a las decisiones de gestión de la empresa. Es


Página 106

aquello de interés duradero para la empresa, sobre lo cual

se pueden almacenar datos e identificar de un modo único.

- Relaciones. Son las representaciones de asociación entre

entidades. Las relaciones establecen el grado de asociación

entre dos estructuras de datos diferentes.

- Atributos. Son características de una entidad que sirven

para definir, describir y clasificar.

Cabe destacar que, por motivos de optimización, las sugerencias se han

separado en una tabla aparte, en lugar de añadirse como atributo al

menú ya que será una información que cambiará con alta frecuencia,

que no siempre se mostrará, evitando así, accesos constantes a todo el

menú cada vez que se quiera editar una sugerencia, simplificando los

accesos y reduciendo el tiempo.

El modelo conceptual de datos del sistema resultará claro y sencillo, ya

que ha sido diseñado según la metodología estudiada, sin embargo la

especial complejidad del sistema residirá en la funcionalidad y el trato

que se da a esta información.

A continuación se representa el modelo entidad-relación para el sistema

integral de gestión de restaurantes con sus respectivos atributos y

relaciones:


Página 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 }


Página 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 explicaría su contenido.

FACTURAS – COMANDAS (COMPUESTO POR): una

factura, solo tiene sentido de existir, si está compuesto por

un conjunto de comandas de un mismo cliente. Por otro

lado, cada comanda, aparecerá solamente en una única

factura ya que es individual, y el campo que lo identificará

será el id_cliente junto con la hora y fecha.

COMANDAS – MENÚ (POSEE): una comanda, estará

formada por un único plato que aparezca en el menú, sin

embargo, un plato del menú, puede aparecer en distintas

comandas, o incluso en ninguna en el caso en que no se

haya pedido nunca ese plato.

MENU – SUGERENCIAS (POSEE): un plato del menú,

podrá tener o no una sugerencia asociada, mientras que

una sugerencia siempre tendrá siempre un plato del menú

asociado.

4) Estudio de la arquitectura


Página 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

diseño. Para ello se propondrán dos alternativas evaluando las ventajas

e inconvenientes de cada una de ellas. Posteriormente, se elegirá la más

adecuada para ser desarrollada e implementada.

4.1 Especificación de las alternativas

A continuación se muestran las posibles soluciones que podrían

utilizarse para el funcionamiento y la puesta en marcha del sistema.

4.1.1 Arquitecturas

4.1.1.1 Arquitectura cliente-servidor (cliente pesado)

Esta arquitectura se divide en dos partes claramente diferenciadas, la

primera es la parte del servidor y la segunda la de un conjunto de

clientes.

Normalmente el servidor es una máquina bastante potente que actúa de

depósito de datos y funciona como un sistema gestor de base de datos

(SGBD).

Por otro lado los clientes suelen ser estaciones de trabajo que solicitan

varios servicios al servidor.


Página 111

Una aplicación informática con arquitectura cliente-servidor consta de

dos programas:

• El programa cliente, que se ejecuta en el ordenador que

interactúa con el usuario (habitualmente un ordenador personal).

• El programa servidor, que se ejecuta en un servidor central

(habitualmente en un servidor dentro de un CPD).

Ambos programas colaboran entre sí gracias a una red de

comunicaciones. Las funcionalidades de la aplicación deben repartirse

entre ambos programas, en principio, de forma equitativa. Sin embargo,

por razones de viabilidad técnica o económica puede ser necesario un

reparto desigual de dichas funcionalidades.

Se denomina cliente pesado al programa "cliente" de una arquitectura

cliente-servidor cuando la mayor carga de cómputo está desplazada

hacia la computadora que ejecuta dicho programa.

Por ejemplo, en una arquitectura cliente servidor con un cliente

pesado, se realizarían así las tareas para el sistema integral de gestión

de restaurantes:

Cliente:


Página 112

o Representación de los datos en la interfaz gráfica.

o Proceso de login en el sistema (cifrado de conexión).

o Exportación de datos a otros formatos.

o Impresión de informes por pantalla.

o Calcular el importe total de la factura.

o Aplicar ofertas y descuentos.

o Calcular el ticket de compra.

Servidor:

o Almacenamiento de datos y facturas.

o Procesado de comandas.

o Ejecución de transacciones


Página 113

Para un posterior estudio de la mejor alternativa posible, que se

adaptará al sistema integral de gestión de restaurantes, se presentan a

continuación las ventajas e inconvenientes del uso de una arquitectura

cliente-servidor con cliente pesado.

Mayor aprovechamiento de la capacidad de cómputo de los

ordenadores que lo ejecutan, generalmente infrautilizadas, en

favor del servidor. Dicho servidor asume menos funciones y, por

tanto, puede atender a un número mayor de programas cliente

con los mismos recursos.

Mejor desempeño multimedia. Los clientes pesados tienen

ventajas en aplicaciones ricas en multimedia que serían

intensivas en ancho de banda si estuvieran completamente

residentes en los servidores. Por ejemplo, los clientes pesados

están bien adaptados para la edición de vídeo.

Apropiado para conexiones de red pobres. Los clientes ligeros

pueden ser inusualmente lentos, o muy frustrantes para usar,

sobre una conexión de red de alta latencia. Por otra parte, no

trabajan en absoluto cuando la red está caída.

Riqueza en el interfaz de usuario. El interfaz no está limitado por

las características de un cliente universal, por ejemplo, un

navegador web. Por tanto, pueden diseñarse interfaces complejos,

ricos y más fáciles de usar.

Sin embargo, como inconvenientes cabe destacar:


Página 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 idénticos y pueden disponer de distinto software

de base, es posible que la aplicación no funcione correctamente

en algunos lugares. En ocasiones, el diseñador de la aplicación no

conoce a priori cuál es el perfil del ordenador que debe ejecutarlo.

Es necesaria una infraestructura para la instalación y

actualización de la aplicación de manera desatendida. Es inviable

realizar dichas tareas utilizando medios humanos cuando se trata

de cientos de ordenadores.

A continuación se representa gráficamente la arquitectura cliente-

servidor, donde a la izquierda aparecen los clientes, conectados con el

servidor, que contiene las bases datos, a través de una red local:


Página 115


Página 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 ocurría en el servidor. Sin

embargo, dispositivos recientes etiquetados como clientes livianos

pueden correr sistemas operativos completos tales como Linux Debian,

calificándose como nodos sin disco o clientes híbridos. Algunos clientes

ligeros también son llamados "terminales de acceso".

Por consecuencia, el término "cliente ligero", en términos de hardware,

ha venido a abarcar cualquier dispositivo usado como, un cliente ligero

en la definición original, incluso si sus capacidades reales son mucho

mayores. El término también es a veces usado en un sentido incluso

más amplio que incluye nodos sin disco.

En un sistema cliente liviano-servidor, el único software que es

instalado en el cliente ligero es la interface de usuario, algunas

aplicaciones frecuentemente usadas, y un sistema operativo de red.

Este software puede ser cargado desde una unidad de disco local, del


Página 117

servidor en tiempo de arranque, o según lo que se necesite. Al

simplificar la carga en el cliente ligero, éste puede ser un dispositivo

muy pequeño y de baja energía, que da costos de compra y de operación

más bajos en cada puesto.

El servidor, o un clúster de servidores, tiene el peso total de todas las

aplicaciones, servicios, y datos. Al mantener algunos servidores

ocupados y muchos clientes livianos ligeramente cargados, los usuarios

pueden esperar una administración de sistemas más fácil y costos más

bajos, así como todas las ventajas de la computación en red:

almacenamiento y respaldo centralizados y una seguridad más fácil.

Debido a que los clientes ligeros son numerosos pero relativamente

pasivos y de bajo mantenimiento, el sistema entero es más simple y

más fácil de instalar y operar. A medida que el costo del hardware baja

y el costo de emplear un técnico y de energía, aumenta, las ventajas de

los clientes ligeros crecen. Por otro lado, desde la perspectiva del

usuario, la interacción con el monitor, el teclado, y el ratón cambia poco

respecto a cuando se está usando un cliente pesado.

Para un posterior estudio de la mejor alternativa posible, que se

adaptará al sistema integral de gestión de restaurantes, se presenta a

continuación las ventajas del uso de una arquitectura cliente-servidor

con cliente liviano.

Menores costes de administración. Los clientes ligeros son

manejados casi enteramente en el servidor. El hardware tiene


Página 118

menos lugares donde puede fallar, el entorno local es altamente

restringido, y el cliente es más simple y a menudo carece de

almacenamiento permanente, proporcionando protección contra

el malware.

Información centralizada. Como la información se encuentra en

un solo lugar facilita la realización de backups y evita que se

guarden archivos que no sean del negocio.

Más fácil de asegurar. Los clientes livianos pueden ser diseñados

de modo que ni siquiera los datos de aplicación residan en el

cliente (apenas son exhibidos en la pantalla), centralizando la

protección contra el malware y reduciendo los riesgos de hurto de

los datos físicos.

Seguridad de datos mejorada. Si un dispositivo del cliente ligero

sufre una seria desgracia o accidente de trabajo, no se perderá

ningún dato, puesto que residen en el servidor y no en el

dispositivo de punto de operación.

Costos de hardware más bajos. El hardware del cliente ligero es

generalmente más barato porque no contiene disco duro,

memoria de aplicaciones, o un procesador poderoso.

Generalmente también tienen un período más largo antes de

requerir una mejora o llegar a ser obsoletos. Hay menos piezas

móviles y uno actualiza o mejora el servidor y la red en lugar de

los clientes, porque la limitación en desempeño es la resolución

de pantalla que tiene un ciclo de vida muy largo. Muchos clientes

pesados son reemplazados después de 3 años para evitar fallos

del hardware en servicio y para usar el último software, mientras

que los clientes ligeros pueden hacer la misma tarea de desplegar


Página 119

imágenes por 10 años. Los requisitos totales de hardware para un

sistema de cliente ligero (incluyendo tanto servidores como

clientes) son generalmente mucho más bajos comparados a un

sistema con clientes pesados. Una razón de esto es que el

hardware es mejor utilizado.

Una CPU en una estación de trabajo pesada está ociosa la mayor parte

del tiempo. Con los clientes ligeros, los ciclos del CPU son compartidos.

Si varios usuarios están corriendo la misma aplicación, solo necesita

ser cargada una sola vez en un servidor central (si la aplicación está

escrita para soportar esta capacidad). Con los clientes pesados, cada

estación de trabajo debe tener en memoria su propia copia del

programa.

Menos consumo de energía. El hardware dedicado de cliente

ligero tiene un consumo de energía mucho más bajo que los

típicos PC de clientes pesados, ahorrando hasta un 80% de

electricidad y cuidando el medio ambiente. Esto no sólo reduce

los costes de energía en los sistemas de computación, en algunos

casos puede significar que los sistemas de aire acondicionado no

son requeridos o no necesitan ser actualizados lo que puede ser

un ahorro de costos significativo y contribuir a alcanzar los

objetivos en ahorro de energía. Sin embargo, se requieren

servidores y sistemas de comunicaciones más poderosos.

Mejor gestión de los fallos de hardware. Si un cliente ligero falla,

un reemplazo puede ser simplemente colocado mientras el cliente

es reparado; el usuario no será incomodado porque sus datos no

están en el cliente.


Página 120

Operable en ambientes hostiles. La mayoría de los clientes

livianos no tienen piezas móviles así que pueden ser usados en

ambientes polvorientos sin la preocupación que puede haber con

la obstrucción de los ventiladores de los PC que pueden

recalentarlos y quemarlos.

Menos ancho de banda de la red. Puesto que los servidores de

terminales típicamente residen en la misma espina dorsal de red

(backbone network) de alta velocidad que los servidores de

archivo, la mayor parte del tráfico de red está confinado al cuarto

del servidor.

Uso más eficiente de los recursos de computación. Un típico

cliente pesado será especificado para hacer frente a la carga

máxima de las necesidades del usuario, lo que puede ser

ineficiente en los momentos en que no es usado. En contraste, los

clientes ligeros usan solamente la cantidad exacta de recursos de

computación requeridos para la tarea actual. En una red grande,

hay una alta probabilidad que la carga de cada usuario fluctuará

en un ciclo diferente a la de otro usuario, es decir, los picos de

uno corresponderán muy probablemente a los bajos de uso de

otro.

Simple trayectoria de actualización de hardware. Si el pico de

recursos está sobre un límite predefinido, es un proceso

relativamente simple agregar otro componente a un rack de

servidor (ya sea energía, procesamiento, o almacenamiento),

estableciendo los recursos exactamente a la cantidad requerida.

Las unidades existentes pueden continuar sirviendo junto a la

nueva, mientras que un modelo de cliente pesado requiere que

sea reemplazada por una unidad de escritorio completa,


Página 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 más agradable y más productivo.

Menos hardware desperdiciado. El hardware contiene metales

pesados y plásticos y requiere energía y recursos para ser

construido. Los clientes ligeros pueden permanecer en servicio

por más tiempo y producen menos hardware excedente que una

equivalente instalación de cliente pesado porque pueden ser

hechos sin partes móviles. Los ventiladores y unidades de disco

del ordenador (usados para enfriar y el almacenamiento de datos

en los clientes pesados) tienen un tiempo medio antes de fallos de

muchas miles de horas pero los transistores y los conductores en

el cliente ligero tienen tiempos medios antes de fallos de millones

de horas.

Algunos de los protocolos usados para la comunicación entre clientes

livianos y servidores son:

X Window System (también conocido como X o X11) usado

esencialmente por variantes de Unix.

Tecnología NX comprime el protocolo X11 para mejores

prestaciones.


Página 122

Computación en Red Virtual o VNC.

Citrix ICA con MetaFrame.

RDP es el protocolo por defecto que incluyen los

sistemas Windows para acceder remotamente al escritorio.

A continuación se representa gráficamente la arquitectura cliente-

servidor, donde a la izquierda aparecen los clientes, conectados con el

servidor, que contiene las bases datos, a través de una red local:


Página 123

4.1.2 Lenguajes de programación para los clientes

En este apartado se estudian las diferentes alternativas de lenguajes de

programación que se podrían utilizar en los módulos de mesa como en

el módulo de cocina.

Posteriormente, una vez realizado el estudio, se elegirá la alternativa

que se adecúe mejor al sistema.

4.1.2.1 Lenguaje C

C es un lenguaje de programación creado en 1972 por Dennis M.

Ritchie en los Laboratorios Bell como evolución del anterior lenguaje B,

a su vez basado en BCPL.

Al igual que B, es un lenguaje orientado a la implementación

de Sistemas Operativos, concretamente Unix. C es apreciado por la

eficiencia del código que produce y es el lenguaje de programación más

popular para crear software de sistemas, aunque también se utiliza

para crear aplicaciones.

Se trata de un lenguaje débilmente tipificado de medio nivel pero con

muchas características de bajo nivel. Dispone de las estructuras típicas

de los lenguajes de alto nivel pero, a su vez, dispone de construcciones

del lenguaje que permiten un control a muy bajo nivel. Los

compiladores suelen ofrecer extensiones al lenguaje que posibilitan

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n

http://es.wikipedia.org/wiki/1972

http://es.wikipedia.org/wiki/Dennis_M._Ritchie

http://es.wikipedia.org/wiki/Dennis_M._Ritchie

http://es.wikipedia.org/wiki/Laboratorios_Bell

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_B

http://es.wikipedia.org/wiki/BCPL

http://es.wikipedia.org/wiki/Sistema_Operativo

http://es.wikipedia.org/wiki/Unix


Página 124

mezclar código en ensamblador con código C o acceder directamente a

memoria o dispositivos periféricos.

Hecho principalmente para la fluidez de programación en sistemas

UNIX. Se usa también para el desarrollo de otros sistemas operativos

como Windows o Linux. Igualmente para aplicaciones de escritorio

como OpenOffice.org, cuyo principal lenguaje de programación es C.

De la misma forma, es muy usado en aplicaciones científicas (para

experimentos informáticos, físicos, químicos, matemáticos, entre otros,

parte de ellos conocidos como modelos y simuladores), industriales

(industria robótica, cibernética, sistemas de información y base de

datos para la industria petrolera y petroquímica). Predominan también

todo lo que se refiere a simulación de máquinas de manufactura,

simulaciones de vuelo (es la más delicada, ya que se tienen que usar

demasiados recursos tanto de hardware como de software para

desarrollar aplicaciones que permitan simular el vuelo real de una

aeronave). Se aplica por tanto, en diversas áreas desconocidas por gran

parte de los usuarios noveles.

Algunas de las ventajas del lenguaje C son:

• Lenguaje muy eficiente puesto que es posible utilizar sus

características de bajo nivel para realizar implementaciones

óptimas.


Página 125

• A pesar de su bajo nivel es el lenguaje más portado en existencia,

habiendo compiladores para casi todos los sistemas conocidos.

• Proporciona facilidades para realizar programas modulares y/o

utilizar código o bibliotecas existentes.

Sin embargo, como inconvenientes se encuentran:

• Existe una gran diferencia en velocidad de desarrollo: es mucho

más lento programar en C. La razón estriba en que el compilador

de C se limita a traducir código sin apenas añadir nada. La

gestión de la memoria es un ejemplo clásico: en C el programador

ha de reservar y liberar la memoria explícitamente. En otros

lenguajes (como BASIC, Matlab o C#) la memoria es gestionada de

forma transparente para el programador. Esto alivia la carga de

trabajo humano y en muchas ocasiones previene errores.

• El mantenimiento es difícil y costoso que con lenguajes de más

alto nivel. El código en C se presta a sentencias cortas y

enrevesadas de difícil interpretación. Aunque el lenguaje admite

código escrito de forma fácilmente legible, si no se siguen normas

en el equipo de programación algunos programadores pueden

acabar escribiendo código difícil de leer. Esto complica la revisión

y el mantenimiento.

• C no dispone de sistemas de control automáticos y la seguridad

depende casi exclusivamente de la experiencia del programador.

La mayor parte de los problemas de seguridad en los sistemas

informáticos actuales deriva de haber sido realizados en C. El

fallo de seguridad clásico consiste en que algunas entradas de


Página 126

información al programa no se comprueban en longitud. Si un

atacante introduce datos lo bastante grandes puede provocar la

sobreescritura de código en la pila del programa e incluso llegar a

forzar la ejecución de código pernicioso. Los lenguajes de tipo

dinámico cuentan con controles de gestión de memoria y de

entrada de datos automáticos.


Página 127

4.1.2.2 Java

Java es un lenguaje de programación orientado a objetos desarrollado

por Sun Microsystems a principios de los años 90. El lenguaje en sí

mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de

objetos más simple y elimina herramientas de bajo nivel, que suelen

inducir a muchos errores, como la manipulación directa de punteros o

memoria.

Las aplicaciones Java están típicamente compiladas en un bytecode,

aunque la compilación en código máquina nativo también es posible. En

el tiempo de ejecución, el bytecode es normalmente interpretado o

compilado a código nativo para la ejecución, aunque la ejecución directa

por hardware del bytecode por un procesador Java también es posible.

La implementación original y de referencia del compilador, la máquina

virtual y las bibliotecas de clases de Java fueron desarrolladas por Sun

Microsystems en 1995. Desde entonces, Sun ha controlado las

especificaciones, el desarrollo y evolución del lenguaje a través del Java

Community Process, si bien otros han desarrollado también

implementaciones alternativas de estas tecnologías de Sun, algunas

incluso bajo licencias de software libre.

Entre noviembre de 2006 y mayo de 2007, Sun Microsystems liberó la

mayor parte de sus tecnologías Java bajo la licencia GNU GPL, de

acuerdo con las especificaciones del Java Community Process, de tal

forma que prácticamente todo el Java de Sun es ahora software

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n

http://es.wikipedia.org/wiki/Orientado_a_objetos

http://es.wikipedia.org/wiki/Sun_Microsystems

http://es.wikipedia.org/wiki/A%C3%B1os_90

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_C

http://es.wikipedia.org/wiki/C%2B%2B

http://es.wikipedia.org/wiki/Puntero_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/C%C3%B3digo_m%C3%A1quina

http://es.wikipedia.org/wiki/Tiempo_de_ejecuci%C3%B3n

http://es.wikipedia.org/wiki/Int%C3%A9rprete_inform%C3%A1tico

http://es.wikipedia.org/wiki/Hardware

http://es.wikipedia.org/w/index.php?title=Procesador_Java&action=edit&redlink=1

http://es.wikipedia.org/wiki/Compilador

http://es.wikipedia.org/wiki/M%C3%A1quina_virtual




http://es.wikipedia.org/wiki/Java_Community_Process



http://es.wikipedia.org/wiki/Software_libre



http://es.wikipedia.org/wiki/GNU_GPL




Página 128

libre (aunque la biblioteca de clases de Sun que se requiere para

ejecutar los programas Java aún no lo es).

El lenguaje Java se creó con cinco objetivos principales:

1. Debería usar la metodología de la programación orientada a

objetos.

2. Debería permitir la ejecución de un mismo programa en múltiples

sistemas operativos.

3. Debería incluir por defecto soporte para trabajo en red.

4. Debería diseñarse para ejecutar código en sistemas remotos de

forma segura.

5. Debería ser fácil de usar y tomar lo mejor de otros lenguajes

orientados a objetos, como C++.

Las ventajas fundamentales de Java, son:

• Los programas solo se escriben una vez. No hace falta escribir el

programa otra vez para ejecutarlo en otra máquina.

http://es.wikipedia.org/wiki/Biblioteca_(programaci%C3%B3n)


Página 129

• Java es un lenguaje orientado a objetos. Por tanto todas las

ventajas que ofrece esta técnica las contiene Java.

• Los browser compatibles con Java no necesitan la instalación de

plug-ins adicionales.

Los inconvenientes más importantes de Java, son:

• Los programas son lentos. Java, al ser un lenguaje interpretado

nunca será tan rápido como un programa ejecutable.

• Para la gente que no conoce Java deberá de estudiar el lenguaje

para sacarle todo el partido.

• Aunque lleva varios años desde su origen, su optimización no es

tan grande como la de otros lenguajes que llevan más años.

Desde la creación de la especificación J2ME (Java 2 Platform, Micro

Edition), una versión del entorno de ejecución Java reducido y

altamente optimizado, especialmente desarrollado para el mercado de

dispositivos electrónicos de consumo se ha producido toda una

revolución en lo que a la extensión de Java se refiere.

Es posible encontrar microprocesadores específicamente diseñados para

ejecutar bytecode Java y software Java para tarjetas inteligentes

(JavaCard), teléfonos móviles, buscapersonas, set-top-boxes,

sintonizadores de TV y otros pequeños electrodomésticos.


Página 130

Hoy en día existen multitud de aplicaciones gráficas de usuario basadas

en Java. El entorno de ejecución Java (JRE) se ha convertido en un

componente habitual en los PC de usuario de los sistemas operativos

más usados en el mundo. Además, muchas aplicaciones Java lo

incluyen dentro del propio paquete de la aplicación de modo que se

ejecuten en cualquier PC.


Página 131

4.1.2.3 Microsoft Visual Basic

Visual Basic es un lenguaje de programación desarrollado para

Microsoft. Visual Basic constituye un IDE (entorno de desarrollo

integrado o en inglés Integrated Development Enviroment) que ha sido

empaquetado como un programa de aplicación, es decir, consiste en un

editor de código (programa donde se escribe el código fuente), un

depurador (programa que corrige errores en el código fuente para que

pueda ser bien compilado), un compilador (programa que traduce el

código fuente a lenguaje de máquina), y un constructor de interfaz

gráfica o GUI (es una forma de programar en la que no es necesario

escribir el código para la parte gráfica del programa, sino que se puede

hacer de forma visual).

Las versiones de Visual Basic para Windows son muy conocidas, pero

existe una versión de Microsoft Visual Basic 1.0 para MS-

DOS (ediciones Profesional y Estándar) menos difundida y que data de

1992. Era un entorno que, aunque en modo texto, incluía un diseñador

de formularios en el que se podían arrastrar y soltar distintos controles.

La versión 6.0 continúa utilizándose masivamente y es casi compatible

prácticamente al 100% con las últimas versiones de Windows como

Vista y Windows 7.

Las versiones actuales de Visual Basic se basan en la plataforma .NET,

que se desligan de las anteriores versiones.

http://es.wikipedia.org/wiki/Windows

http://es.wikipedia.org/wiki/MS-DOS

http://es.wikipedia.org/wiki/MS-DOS

http://es.wikipedia.org/wiki/.NET


Página 132

Cabe mencionar que aunque menos conocido, existió también una

versión gratuita de Visual Basic 5.0 dedicada en su práctica al

desarrollo de controles y componentes, su nombre en concreto

era Microsoft Visual Basic 5.0 Control Creation Edition (Visual Basic 5

CCE).

Las ventajas principales del lenguaje Visual Basic son las siguientes:

• Es un lenguaje RAD.

• Posee una curva de aprendizaje muy rápida.

• Se integra el diseño e implementación de formularios de

Windows.

• Se permite usar con suma facilidad la plataforma de los sistemas

Windows.

• El código en Visual Basic es fácilmente migrable a otros

lenguajes.

Como inconvenientes se encuentran:

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

• No es multiplataforma.


Página 133

• Por defecto se permite la programación sin declaración de

variables (que puede ser sencillamente corregida escribiendo la

frase Option Explicit en el encabezado de cada formulario).

• No se permite programación a bajo nivel ni incrustar secciones de

código en ASM.

• Sólo se permite el uso de funciones de librerías dinámicas (DLL)

stdcall.

• Algunas funciones están indocumentadas.

• Es un lenguaje basado en objetos y no orientado a objetos.

• No se maneja muy bien los apuntadores de memoria.

• No se soporta tratamiento de procesos como parte del lenguaje.

• No se incluye operadores de desplazamiento de bits como parte

del lenguaje.

• No se permite el manejo de memoria dinámica, punteros, etc.

como parte del lenguaje.

• No se avisa de ciertos errores o advertencias (se puede configurar

el compilador para generar ejecutables sin los controladores de

desbordamiento de enteros o las comprobaciones de límites en

matrices entre otros, dejando así más de la mano del

programador la tarea de controlar dichos errores)

• No se tiene instrucciones de preprocesamiento.


Página 134

• El tratamiento de mensajes de Windows es básico e indirecto.

• La gran gama de controles incorporados son, sin embargo en

algunos casos, muy generales, lo que lleva a tener que

reprogramar nuevos controles para una necesidad concreta de la

aplicación. Esto cambia radicalmente en Visual Basic .NET donde

es posible reprogramar y mejorar o reutilizar los controles

existentes.

• Los controles personalizados no mejoran la potencia de la API de

Windows, y en determinados casos acudir a ésta será el único

modo de conseguir el control personalizado deseado.


Página 135

4.1.3 Lenguajes de programación para el servidor

En este apartado se estudian las diferentes alternativas de lenguajes de

programación que se podría utilizar en el servidor.

Posteriormente, una vez realizado el estudio, se elegirá la alternativa

que se adecúe mejor al sistema.

4.1.3.1 Active Server Pages

Active Server Pages (ASP) es una tecnología de Microsoft del tipo "lado

del servidor" para páginas web generadas dinámicamente, que se ha

comercializado como un anexo a Internet Information Services.

La tecnología ASP está estrechamente relacionada con el modelo

tecnológico de su fabricante. Intenta ser solución para un modelo de

programación rápida ya que programar en ASP es como programar en

Visual Basic, por supuesto con muchas limitaciones.

Lo interesante de este modelo tecnológico es poder utilizar diversos

componentes ya desarrollados como algunos controles ActiveX así como

componentes del lado del servidor, tales como CDONTS, por ejemplo,

que permite la interacción de los scripts con el servidor SMTP que

integra IIS.


Página 136

Se facilita la programación de sitios web mediante varios objetos

integrados, como por ejemplo un objeto de sesión basada en cookies,

que mantiene las variables mientras se pasa de página a página.


Página 137

4.1.3.2 PHP

PHP es un acrónimo recursivo que significa PHP Hypertext Pre-

processor (inicialmente PHP Tools, o, Personal Home Page Tools). Es un

lenguaje de programación interpretado, diseñado originalmente para la

creación de páginas web dinámicas. Es usado principalmente en

interpretación del lado del servidor (server-side scripting) pero

actualmente puede ser utilizado desde una interfaz de línea de

comandos o en la creación de otros tipos de programas incluyendo

aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+.

Algunas ventajas que presenta PHP son:

• Es un lenguaje multiplataforma.

• Completamente orientado a la web.

• Capacidad de conexión con la mayoría de los motores de base de

datos que se utilizan en la actualidad, destaca su conectividad

con MySQL y PostgreSQL.

• Capacidad de expandir su potencial utilizando la enorme

cantidad de módulos (llamados ext's o extensiones).


Página 138

• Posee una amplia documentación en su página oficial, entre la

cual se destaca que todas las funciones del sistema están

explicadas y ejemplificadas en un único archivo de ayuda.

• Es libre, por lo que se presenta como una alternativa de fácil

acceso para todos.

• Se permite usar las técnicas de Programación Orientada a

Objetos.

• No se requiere definición de tipos de variables aunque sus

variables se pueden evaluar también por el tipo que estén

manejando en tiempo de ejecución.

• Manejo de excepciones (desde PHP5).

• Si bien en PHP no se obliga a quien lo usa a seguir una

determinada metodología a la hora de programar (muchos otros

lenguajes tampoco lo hacen), aun estando dirigido a alguna en

particular, el programador puede aplicar en su trabajo cualquier

técnica de programación y/o desarrollo que le permita escribir

código ordenado, estructurado y manejable. Un ejemplo de ésto

son los desarrollos que en PHP se han hecho del patrón de diseño

Modelo Vista Controlador (o MVC), que permiten separar el

tratamiento y acceso a los datos, la lógica de control y la interfaz

de usuario en tres componentes independientes.


Página 139

Como desventajas se encuentra:

• La ofuscación de código es la única forma de ocultar los fuentes


Página 140

4.1.3.3 Java Server Pages

JavaServer Pages (JSP) es una tecnología Java que permite generar

contenido dinámico para web, en forma de documentos HTML, XML o

de otro tipo.

Esta tecnología es un desarrollo de la compañía Sun Microsystems. La

Especificación JSP 1.2 fue la primera que se liberó y en la actualidad

está disponible la especificación JSP 2.1.

En JSP's se permite la utilización de código Java mediante scripts.

Además, es posible utilizar algunas acciones JSP predefinidas mediante

etiquetas. Estas etiquetas pueden ser enriquecidas mediante la

utilización de Librerías de Etiquetas (TagLibs o Tag Libraries) externas e

incluso personalizadas.

JSP puede considerarse como una manera alternativa, y simplificada,

de construir servlets.

Es por ello que una página JSP puede hacer todo lo que un servlet

puede hacer, y viceversa. Cada versión de la especificación de JSP está

fuertemente vinculada a una versión en particular de la especificación

de servlets.


Página 141

El funcionamiento general de la tecnología JSP es que el Servidor de

Aplicaciones interpreta el código contenido en la página JSP para

construir el código Java del servlet a generar.

Este servlet será el que genere el documento (típicamente HTML) que se

presentará en la pantalla del navegador del usuario.

El rendimiento de una página JSP es el mismo que tendría el servidor

equivalente, ya que el código es compilado como cualquier otra clase

Java. A su vez, la máquina virtual compilará dinámicamente a código de

máquina las partes de la aplicación que lo requieran. Esto hace que JSP

tenga un buen desempeño y sea más eficiente que otras tecnologías web

que ejecutan el código de una manera puramente interpretada.

Como ventajas principales cabe destacar:

• El lenguaje Java es un lenguaje de propósito general que excede

el mundo web y que es apto para crear clases que manejen lógica

de negocio y acceso a datos de una manera prolija. Esto permite

separar en niveles las aplicaciones web, dejando la parte

encargada de generar el documento HTML en el archivo JSP.

• JSP hereda la portabilidad de Java, y es posible ejecutar las

aplicaciones en múltiples plataformas sin cambios. Es común

incluso que los desarrolladores trabajen en una plataforma y que

la aplicación termine siendo ejecutada en otra.


Página 142

Como inconvenientes, se encuentran los ya comentados anteriormente

en referencia al lenguaje de programación java.


Página 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 podrían utilizar para implantar el

sistema, y posteriormente, se elegirá una como solución.

4.1.4.1 Oracle

Oracle es un sistema de gestión de base de datos relacional (o RDBMS

por el acrónimo en inglés de Relational Data Base Management

System), desarrollado por Oracle Corporation.

Se considera a Oracle como uno de los sistemas de bases de datos más

completos, tiene como características principales:

• Soporte de transacciones.

• Estabilidad.

• Escalabilidad.

• Soporte multiplataforma.


Página 144

Ha sido criticada por algunos especialistas la seguridad de la

plataforma, y las políticas de suministro de parches de seguridad.

Aunque su dominio en el mercado de servidores empresariales ha sido

casi total hasta hace poco, recientemente sufre la competencia de

Microsoft SQL Server de Microsoft y de la oferta de otros RDBMS con

licencia libre como PostgreSQL,MySQL o Firebird.

4.1.4.2 SQL Server

Microsoft SQL Server es un sistema de gestión de bases de datos

relacionales (SGBD) basado en el lenguaje Transact-SQL, y

específicamente en Sybase IQ, capaz de poner a disposición de muchos

usuarios grandes cantidades de datos de manera simultánea, así como

de disponer de las siguientes ventajas:

• Soporte de transacciones.

• Escalabilidad, estabilidad y seguridad.

• Soporta procedimientos almacenados.

• Incluye también un potente entorno gráfico de administración,

que permite el uso de comandos DDL y DML gráficamente.


Página 145

• Permite trabajar en modo cliente-servidor, donde la información

y datos se alojan en el servidor y los terminales o clientes de la

red sólo acceden a la información.

• Además permite administrar información de otros servidores de

datos.


Página 146

4.1.4.3 MySQL

MySQL es un sistema de gestión de base de datos relacional, multihilo y

multiusuario con más de seis millones de instalaciones. MySQL se

desarrolla como software libre en un esquema de licenciamiento dual.

Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible

con esta licencia, pero para aquellas empresas que quieran incorporarlo

en productos privativos se debe comprar a la empresa una licencia

específica que les permita este uso.

MySQL es muy utilizado en aplicaciones web y en plataformas

(Linux/Windows-Apache-MySQL-PHP/Perl/Python). Su popularidad

como aplicación web está muy ligada a PHP, que a menudo aparece en

combinación con MySQL. MySQL es una base de datos muy rápida en

la lectura cuando utiliza el motor no transaccional MyISAM. En

aplicaciones web hay baja concurrencia en la modificación de datos y

en cambio el entorno es intensivo en lectura de datos, lo que hace a

MySQL ideal para este tipo de aplicaciones.


Página 147

4.1.5 Sistemas operativos

En este apartado se estudian las diferentes alternativas de sistemas

operativos que se podrían utilizar para implantar en el servidor, y

posteriormente, se elegirá uno como solución.

4.1.5.1 Windows Server 2008 R2

Windows Server 2008 es el nombre de un sistema operativo diseñado

para servidores de Microsoft. Es el sucesor de Windows Server 2003,

distribuido al público casi cinco años antes. Al igual que Windows

Vista, Windows Server 2008 se basa en el núcleo Windows NT6.0.

Posteriormente se lanzó una segunda versión, denominada Windows

Server 2008 R2.

Fue conocido como Windows Server "Longhorn" hasta el 16 de mayo de

2007, cuando Bill Gates, presidente de Microsoft, anunció su título

oficial (Windows Server 2008) durante su discurso de apertura en

WinHEC. El Windows Aero, está deshabilitado y usa la interfaz clásica

de versiones anteriores de Windows.

La beta 1 fue lanzada el 27 de julio de 2005. La beta 2 fue anunciada y

lanzada el 23 de mayo de 2006 en WinHEC 2006 y la beta 3 fue lanzada

al público el 25 de abril de 2007. Su lanzamiento fue el 27 de febrero de

2008.

http://es.wikipedia.org/wiki/Sistema_operativo

http://es.wikipedia.org/wiki/Servidor

http://es.wikipedia.org/wiki/Microsoft

http://es.wikipedia.org/wiki/Windows_Server_2003

http://es.wikipedia.org/wiki/Windows_Vista



http://es.wikipedia.org/wiki/Windows_NT

http://es.wikipedia.org/wiki/Windows_Server_2008_R2



http://es.wikipedia.org/wiki/Bill_Gates

http://es.wikipedia.org/wiki/Windows_Aero


Página 148

Hay algunas diferencias (unas sutiles y otras no tanto) con respecto a la

arquitectura del nuevo Windows Server 2008, que pueden cambiar

drásticamente la manera en que se usa este sistema operativo. Estos

cambios afectan a la manera en que se gestiona el sistema hasta el

punto de que se puede llegar a controlar el hardware de forma más

efectiva, se puede controlar mucho mejor de forma remota y cambiar de

forma radical la política de seguridad. Entre las mejoras que se

incluyen, están:

Nuevo proceso de reparación de sistemas NTFS: proceso en

segundo plano que repara los archivos dañados.

Creación de sesiones de usuario en paralelo: reduce tiempos de

espera en los Terminal Services y en la creación de sesiones de

usuario a gran escala.

Cierre limpio de Servicios.

Sistema de archivos SMB2: de 30 a 40 veces más rápido el acceso

a los servidores multimedia.

Address Space Load Randomization (ASLR): protección contra

malware en la carga de controladores en memoria.

Server Core: el núcleo del sistema se ha renovado con muchas y

nuevas mejoras.


Página 149

4.1.5.2 Mandriva Linux

Mandriva Linux es una distribución Linux destinada tanto para

principiantes como para usuarios experimentados, que ofrece

un sistema operativo orientado a computadoras personales y también

para servidores con un enfoque a los usuarios que se están

introduciendo al mundo de Linux y al software libre además por tener

una amplia gama y comunidad de desarrolladores, es adecuada para

todo tipo de variedad de necesidades: estaciones de trabajo, creación de

clústeres, servidores, firewalls, etc. Es una de las distribuciones de

Linux referentes a nivel mundial.

Como características principales, se encuentran:

Internacionalización: disponible en 74 idiomas.

Instalación control y administración: el instalador de Mandriva

Linux es uno de los más amigables de entre las diferentes

distribuciones de Linux, cabe destacar que Mandrake (ahora

Mandriva) fue la primera distribución en incluir un instalador

gráfico. En su primera versión el instalador presentó algunos

problemas con la resolución de dependencias, cosa que ya está

solucionada.

Paquetes de software abundantes: viene con aproximadamente

205609 paquetes de software incluyendo juegos, programas de

oficina, multimedia, gráficos, servidores y utilidades de Internet.

http://es.wikipedia.org/wiki/Distribuci%C3%B3n_Linux


http://es.wikipedia.org/wiki/Computadoras_personales

http://es.wikipedia.org/wiki/Servidores

http://es.wikipedia.org/wiki/Linux


http://es.wikipedia.org/wiki/Mandriva_(distribuci%C3%B3n_Linux)#cite_note-8


Página 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 versión de Unix. Funciona en arquitecturas SPARC y

x86 para servidores y estaciones de trabajo.

Si bien Solaris en un ordenador personal apenas necesita

mantenimiento profesional, utilizado en una empresa es posible que el

empresario quiera contratar los servicios del equipo de Sun para hacer

rendir al máximo su negocio, exprimiendo todas las novedades en

seguridad de redes y muchas más cosas. Sun fabrica hardware libre,

como lo es la tecnología SPARC.

Solaris 10 es la versión más reciente del sistema operativo desarrollado

por Sun Microsystems. Solaris es en sí software propietario y ahora la

parte principal del sistema operativo se ha liberado como un proyecto

de software libre denominado OpenSolaris. Esto es novedad para Sun,

pues todas las versiones anteriores eran cerradas. Plantearon distribuir

su producto bajo la licencia CDDL Common development and

distribution license.

http://es.wikipedia.org/wiki/Hardware_libre

http://es.wikipedia.org/wiki/SPARC


http://es.wikipedia.org/wiki/Sun_Microsystems

http://es.wikipedia.org/wiki/OpenSolaris

http://es.wikipedia.org/wiki/CDDL

http://es.wikipedia.org/wiki/Common_development_and_distribution_license




Página 151

4.2 Evaluación de las alternativas

La evaluación de las alternativas se realiza en base a aspectos de

interés que se consideran fundamentales para el buen funcionamiento

de la aplicación. No sólo de valoran características relacionadas con el

rendimiento, sino también con el coste, la rapidez con la que se

resuelven agujeros de seguridad, posibilidad de añadir nueva

funcionalidad, etc.

4.2.1 Evaluación de la arquitectura

Al tratarse de una aplicación que deben de usar múltiples clientes

queda claro que la mejor arquitectura es la basada en cliente / servidor.

Dentro de este esquema se han expuesto dos configuraciones; una con

un cliente ligero y otra con un cliente pesado.

Para evaluar las arquitecturas, se estudian las ventajas e

inconvenientes, posteriormente se seleccionará las más adecuada.

Las ventajas del cliente pesado son:

• La carga de proceso se realiza en el equipo del usuario pudiendo

el servidor escalar con mayor facilidad para dar servicio a más

usuarios.

• Menor coste del equipo servidor.


Página 152

Las desventajas del cliente pesado son:

• Dificultad a la hora de actualizar los equipos clientes.

• Posible fuente de problemas al existir diferente configuración en

cada ordenador.

• Necesidad de crear un cliente para cada plataforma (Windows,

Mac, Linux, etc.)

Mientas que las ventajas de utilizar un cliente ligero son:

• El software cliente se encuentra centralizado en un solo punto

por lo que distribuir las actualizaciones es mucho sencillo.

• Se eliminan los problemas de compatibilidad de software entre

plataformas ya que se utiliza un navegador web.

• El tiempo de proceso del cliente se puede invertir en otras

aplicaciones que tenga instaladas en su ordenador.

Y como desventajas de los clientes ligeros cabe destacar:


Página 153

• Es necesario una máquina más potente que las demás en el

servidor.

• Si el servidor falla, ningún cliente podrá acceder a la aplicación.

Esto se resuelve con una buena planificación y la redundancia de

sistemas.


Página 154

4.2.2 Evaluación del sistema operativo

A la hora de evaluar el sistema operativo elegido hay que tener en

cuenta las consecuencias de dicha decisión ya que se da el caso de que

determinado software funciona mejor en un sistema operativo que en

otro o simplemente es incompatible.

De las diferentes alternativas presentadas se ha evaluado coste,

posibilidad de ampliación de funcionalidades, integración con otros

sistemas, y frecuencia con la que se detectan vulnerabilidades.

Windows server

2008

Mandriva Linux Solaris 10

Coste

Alto Bajo Medio

Ampliación de

funcionalidades

Medio Alta Medio

Integración

Alta Alta Alta

Frecuencia de

vulnerabilidades

Media Baja Baja

Complejidad de

uso

Bajo Medio Medio


Página 155

4.2.3 Evaluación del lenguaje de programación en el cliente

Para determinar el mejor lenguaje de programación en el lado del cliente

se deben examinar a fondo los requerimientos que va a necesitar la

aplicación. Visual Basic es un lenguaje muy fácil de aprender sin

embargo sólo funciona en plataformas Windows. Java es más

complicado de aprender y requiere mucho trabajo para desarrollar

elementos gráficos, sin embargo destaca su extraordinaria portabilidad.

Esta característica permite que un programa escrito en Java pueda ser

ejecutado en diferentes plataformas.

Se analiza el coste, la posibilidad de ampliar funcionalidades, el número

de expertos que conocen este lenguaje en caso de un futuro

mantenimiento, y el potencial de uso, que mejor permita adaptarse al

sistema requerido.


Página 156

Java

VisualBasic C

Coste

Gratuito 100 € licencia

estudiante

Gratuito

Ampliación de

funcionalidades

Alto Bajo Bajo

Expertos que

conocen el

lenguaje

Alto Medio Alto

Potencial de uso

Alto Medio Medio


Página 157

4.2.4 Evaluación del lenguaje de programación en el servidor

Para la elección de una arquitectura basada en cliente servidor, será

necesario determinar el lenguaje de programación del lado del servidor

más adecuado para la aplicación.

Se usan los mismos criterios de evaluación que para los lenguajes de

programación del lado cliente.

JSP

ASP PHP

Coste

Gratuito Gratuito Gratuito

Ampliación de

funcionalidades

Alto Bajo Bajo

Expertos que

conocen el

lenguaje

Alto Medio Alto

Potencial de uso

Alto Medio Medio


Página 158

4.2.5 Evaluación del sistema gestor de bases de datos

Independientemente de la arquitectura elegida, esta aplicación deberá

guardar los datos de los distintos usuarios. Para determinar cuál es el

gestor de base de datos más idóneo se utilizarán los siguientes criterios:

coste, soporte de transacciones, soporte técnico y concurrencia.

Cabe destacar que MySQL tiene un soporte técnico calificado como bajo

ya que debe ser contratado aparte, y respecto a la concurrencia, en SQL

Server es medio ya que el rendimiento desciende al aumentarlos

usuarios conectados, en Oracle alto al usarse actualmente en

aplicaciones críticas, y en MySQL medio ya que necesita de una

máquina potente.

SQL Server

Oracle MySQL

Coste

Alto Alto Gratuito

Soporte de

transacciones

Medio Alto Medio

Soporte técnico

Alto Alto Bajo

Concurrencia

Medio Alto Medio


Página 159

4.3 Selección de la alternativa

Después de analizar las distintas opciones se selecciona la alternativa

basada en una arquitectura de cliente/servidor con un cliente ligero, ya

que será más fácil de centralizar la información y es la arquitectura más

adecuada cuando serán varios los clientes que realicen transacciones a

la vez.

Respecto al servidor web, se ha seleccionado únicamente Apache

Tomcat, debido a su amplia difusión en la comunidad y su carácter

gratuito. Se trata de un servidor http multiplataforma de código abierto

con un nivel de seguridad aceptable, se usará principalmente para

cargar los vídeos e imágenes que cada restaurante quiera mostrar a sus

clientes.

El sistema operativo seleccionado será Windows, para tener el acceso a

la información de forma centralizada, sencillez y familiaridad con este

sistema.

El lenguaje de programación tanto en el cliente como en el servidor,

será Java J2EE, debido a su gratuidad, simplicidad, su orientación a

objetos, carácter distribuido e interpretado, robustez, arquitectura

neutral, seguridad, portabilidad y posibilidad de ejecución multihilo.

Como sistema gestor de bases de datos, el más adecuado para el

sistema será MySQL, debido a su coste gratuito, escalabilidad y

flexibilidad (maneja bases de datos empotradas ocupando sólo 1MB, y


Página 160

es soportado en UNIX, Linux y Windows), alto rendimiento,

disponibilidad, facilidad de gestión y fuerte protección de datos.

5) Diseño externo


Página 162

5. DISEÑO EXTERNO

En esta etapa del proyecto se va a realizar la secuencia de actividades

que en la metodología en cascada se recoge bajo el nombre de diseño

externo. Por tanto, se van a tratar diferentes aspectos como las

fronteras de mecanización, especificación de procesos, entradas y

salidas, etc.

5.1 Entorno operativo

A continuación se procede a representar de forma simplificada el

funcionamiento general del sistema:

Menú virtual, sugerencias,

factura...

Comandas

Consulta facturación, edición del menú,

inserción de publicidad...

Usuarios

clientes

Usuarios en

cocina

Sistema Integral

de Gestión de

Restaurantes


Página 163

5.2 Fronteras de mecanización

Teniendo en cuenta los estudios realizados previamente, se decide

mecanizar todas aquellas funciones que aparecen en el DFD del nuevo

sistema, ya que una ampliación de esas excedería los límites del

proyecto.

5.3 Especificación de procesos

En este apartado, se estudian los procesos que componen la aplicación.

A continuación, se muestra un esquema general de la aplicación, tanto

en su parte pública como privada. Para la elaboración de este apartado

se han seguido consejos de los libros [WESL99] y [LARM03].

Se representa en el diagrama a continuación los procesos que pueden

ejecutar los clientes, y los procesos que ejecutan los empleados,

incluyendo el gerente del restaurante, trabajadores en la cocina...

Por un lado existe un menú público, que todos los clientes podrán ver,

que incluye la carta virtual con sus sugerencias y la función de realizar

comandas.

Por otro lado, existe un menú privado, al que sólo tendrá acceso el

personal del restaurante mediante un login, que incluye la posibilidad

de editar el menú que se muestra a los clientes, la función de inserción

de publicidad o sugerencias, la visualización de las comandas que los


Página 164

clientes realizan y la función de muestra de informes sobre la

facturación del restaurante.

Todas estas funciones, se representan en el siguiente esquema:

Inicio Edición de comandas

Menú público Administración Menú privado

Ver carta Realizar comanda Publicidad Informes

Como se puede comprobar, la pantalla de administración permite un

acceso personalizado a la aplicación privada. En función del puesto se

permite un acceso a los siguientes módulos de la aplicación.


Página 165

Gerente

Personal de

salón

Personal de

cocina

Clientes

Ver carta

virtual

Realizar

comanda

Edición de

comandas

Publicidad y

sugerencias

Informes

Se han especificado en este apartado los grandes módulos que

descomponen la aplicación, y los accesos a los distintos módulos según

el usuario que se conecte al sistema.


Página 166

5.4 Diseño de interfaces

En este apartado se recogen los interfaces de que constará la

aplicación. Se realiza un análisis detallado de todas las pantallas, con

sus funcionalidades completas.

Cabe destacar que el diseño de la aplicación se ha hecho para una

interfaz táctil y es por eso que los botones son más grandes de lo

habitual.

5.4.1 Interfaz login

Esta es la primera pantalla a la que acceden los empleados o el gerente

en la aplicación. Los clientes, no ven esta pantalla, ya que no tienen que

realizar ningún login. Según los permisos de los que dispongan los

empleados, podrán acceder a unas funciones u otras, pero siempre es

necesario realizar una identificación mediante usuario y contraseña.


Página 167

5.4.2 Menú privado

Una vez que se ha accedido como empleado, se podrá tener acceso a

unos módulos u otros en función de si se trata del gerente del

restaurante, o del resto del personal.

5.4.2.1 Menú privado del gerente

El gerente, que tendrá su propio nombre de usuario y contraseña que le

diferencie del resto de personal, podrá tener acceso a cuatro módulos

distintos: comandas, publicidad, carta virtual e informes.


Página 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 visión del módulo de cocina, que se arranca al principio de la

actividad del restaurante para poder visualizar las comandas que llegan

de los clientes.


Página 169

5.4.2.3 Menú privado introducir sugerencias

A continuación se muestra la apariencia del menú privado introducir

sugerencias al que sólo puede acceder el chef o el gerente del

restaurante.

Las sugerencias que introduzca aquí, se guardarán en la base de datos,

y posteriormente se mostrará en el menú virtual a los clientes.

El número de sugerencia coincidirá con el número de plato al que se le

aplica.


Página 170

5.4.2.4 Menú privado visualizar comandas

A continuación se muestra el aspecto del módulo de cocina. Los

empleados ven las comandas que envían los clientes y su detalle en los

distintos apartados.

Al pulsar sobre ellas pueden editarlas, y marcarlas como atendidas,

desapareciendo así de la lista de tareas pendientes.


Página 171

5.4.2.5 Menú privado editar carta virtual

Este es el menú que aparece para el gerente o el chef en el módulo de

cocina, si desean modificar la información que se mostrará a los

clientes, de uno de los platos de la carta.

Se puede eliminar directamente de la base de datos introduciendo el

número de plato, o bien se puede editar la información sobre los

ingredientes, descripción y precio y además se puede añadir

opcionalmente la url del vídeo o imagen que se mostrará a los clientes

sobre su preparación detallada.


Página 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

facturación del restaurante, o sobre los platos más vendidos.

Y a continuación el informe sobre los platos ordenados de ascendente

según el número de ventas:


Página 173

5.4.3 Menú público

En este caso se representa el menú que visualizarán los clientes en el

módulo de mesa, se presenta primeramente una ventana de bienvenida,

y a continuación la carta completa con la posibilidad de acceder, en

cada plato, a información más detallada con imágenes o vídeos.

5.4.3.1 Pantalla de bienvenida

Este es el aspecto de la pantalla de bienvenida que encontrarán los

clientes en su módulo de mesa.


Página 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 información

más detallada se muestra una segunda ventana con vídeos o imágenes.


Página 175

5.4.3.3 Información detallada

La siguiente figura muestra la información detallada a la que pueden

acceder los clientes, a través del menú virtual, al pulsar sobre el botón

más información al lado de cada plato en el menú.

Se puede ver una descripción más extensa sobre el plato, una imagen

de su aspecto, o un vídeo de su preparación.


Página 176

5.5 Procesos de seguridad

El sistema cuenta con las medidas de seguridad que garantizan la

autenticación de los usuarios, la autorización en los procesos de

consulta y modificación de la información así como su integridad.

Se debe asegurar que los datos de la empresa sean utilizados por

aquellos a los que van dirigidos. Para ello se ha diseñado el proceso de

login, que permite un acceso personalizado a la aplicación a partir de

un nombre de usuario y password.

Según el tipo de empleado que acceda, tendrá permiso para acceder a

una información u otra, mientras que los clientes, solo tendrán acceso a

la carta virtual y a realizar las comandas.

6) Diseño interno


Página 178

6. DISEÑO INTERNO

En la fase de Diseño Interno, se realiza una última caracterización de la

aplicación, antes de iniciar la fase de Programación. Para ello, se debe

centrar el trabajo en los dos elementos fundamentales del sistema

informático a desarrollar: Procesos y entidades.

Para ello se estudia en este apartado, un diseño interno de los procesos

a través de diagramas HIPO y STC y posteriormente el estudio de las

tablas que componen la base de datos. Para la elaboración de este

capítulo se ha empleado la referencia bibliográfica [ESQU08].

6.1 Diseño interno de programas

A continuación se representan los diagramas HIPO de los diferentes

procesos.


Página 179

6.1.1 Diagrama HIPO Administración de empleados

A continuación 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 aplicación; en caso contrario, se

denegará.

ID_EMP

PASS

EMPLEADOS

LOGIN

ACCESO/NO

ACCESO


Página 180

6.1.2 Diagrama HIPO Alta comanda

A continuación se muestra el diagrama HIPO que permite dar de alta

una comanda en la base de datos de facturas el sistema.

SUGERENCIAS

COMANDAS MENU

SELECCIÓN

SELECCIÓN

SELECCIÓN

FACTURAS

COMANDAS-

SELECCIÓN

MENÚ-

SELECCIÓN

SUGERENCIAS-

SELECCIÓN

Salida Total

GUARDAR


Página 181

6.1.3 Diagrama STC Administración de empleados

Como se puede observar en el siguiente diagrama, el proceso de login

requiere la introducción de nombre de usuario y password, con sus

respectivas comprobaciones.

ENTRADA VALIDAR

INTRODUCIR

NOMBRE DE

USUARIO

INTRODUCIR

PASSWORD

CAPTAR DATOS

ADMINISTRACIÓN

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


Página 182

6.2 Modelo físico de la base de datos

En las siguientes tablas se representa el diseño interno de la base de

datos.

TABLA

Atributos

Tipo

Facturas

ID_CLI INTEGER

TOTAL

DOUBLE

FECHA

DATE

HORA

DATE

La tabla facturas, guarda información sobre todas las comandas

atendidas y el precio total cobrado, junto con su fecha y hora.


Página 183

TABLA

Atributos

Tipo

Comandas

ID_CLI INTEGER

MESA

INTEGER

FECHA

DATE

HORA

DATE

ID_PLATO INTEGER

CANT INTEGER

La tabla comandas guarda información sobre las comandas realizadas

por cada cliente, con su mesa, fecha y hora, plato pedido y cantidad.


Página 184

TABLA

Atributos

Tipo

Menú

ID_PLATO INTEGER

INGRED

VARCHAR(20)

DESC

VARCHAR(150)

URL

VARCHAR(50)

PRECIO_UNIT DOUBLE

La tabla menú guarda información sobre cada plato que compone el

menú que se mostrará a los clientes, incluyendo los ingredientes, una

descripción general, una url en caso de que exista un vídeo ilustrativo y

su precio unitario.


Página 185

TABLA

Atributos

Tipo

Sugerencias

ID_PLATO INTEGER

SUGER

VARCHAR(80)

La tabla sugerencias, guarda información sobre las sugerencias que el

chef desea ofrecer a sus clientes, asignando esta sugerencia a un plato

concreto del menú. Está información será cambiante.

7) Pruebas


Página 187

7. PRUEBAS

Una vez desarrollados y probados cada uno de los componentes

integrantes de la aplicación, deben realizarse una serie de pruebas

unitarias para integrar todo el sistema. Así, el objetivo global de esta

fase es someter al sistema desarrollado y sus componentes, a una serie

de verificaciones encaminadas a garantizar un nivel de fiabilidad

aceptable. Esta fase es crítica y debe por tanto, ser planificada,

diseñada y realizada con el mismo rigor y control con el que se realiza el

desarrollo del sistema. Si los resultados de las pruebas son

satisfactorios, se procederá a la aceptación de las mismas y a la

implantación del sistema; en caso contrario, se deberán subsanar las

anomalías encontradas. Se realizarán dos tipos de pruebas: Pruebas

unitarias, y pruebas de integración.

7.1 Pruebas unitarias

Están encaminadas a resolver los problemas de cada una de los

procesos por separado.

A todos los módulos de la aplicación se les ha pasado la siguiente lista

de pruebas unitarias.

5. Mensajes del sistema suficientemente explicativos.

6. Introducción de datos con formato incorrecto.

7. Correcta inserción, modificación y borrado de datos de la BD.


Página 188

8. Cumplimiento requisitos del usuario.

9. Funcionalidad de botones correcta.


Página 189

7.2 Pruebas de integración

Estas pruebas son utilizadas fundamentalmente para comprobar la

integración de los módulos ya testados y probados de forma individual.

En este sentido, hay dos tipos de pruebas: de navegación y de paso de

parámetros.

También se ha diseñado una lista para estas pruebas:

1. Navegación correcta por los distintos menús.

2. Correcto paso de parámetros entre funciones.

Después del estudio de pruebas de integración en el sistema, el

resultado ha sido satisfactorio y se han depurado algunos errores.

8) Implantación


Página 191

8. IMPLANTACIÓN

Una vez probada la integridad del software del sistema y especificada su

instalación y configuración, se debe transferir el software producido en

un entorno de desarrollo a uno de producción, para llevar a cabo la

explotación del sistema. Para ello, se deberán realizar una implantación

física de la aplicación y después proceder con la ejecución de la base de

datos.

8.1 Implantación física

La implantación física, se debe realizar de acuerdo a las reuniones con

el cliente, es decir:

La aplicación se situará sobre el nuevo servidor.

En un primer paso de la implantación, sólo se accederá a una

base de datos de desarrollo, pasando en una fase posterior a

acceder a la base de datos de explotación.

En las primeras etapas de la implantación se deberán filtrar los

accesos a la aplicación a aquellos usuarios que se decida prueben

la aplicación. Para ello se deberá configurar el firewall de acceso

al servidor. Posteriormente, se procederá con la ejecución de la

base de datos.

9) Conclusiones


Página 193

9. CONCLUSIONES

El éxito de un proyecto informático depende de muchos factores como

puede ser, la calidad del equipo de trabajo, una buena planificación, el

dinero disponible o el tiempo.

Sin embargo, es bien conocido por todos que el éxito de un proyecto en

numerosas ocasiones no implica ideas complejas, desarrollo arduo o

una gran inversión económica.

Un proyecto informático exitoso conlleva siempre un desarrollo bien

elaborado del mismo acompañado de una buena idea, además de otros

factores técnicos. Este proyecto ha tratado de unir estos dos elementos,

para poner la tecnología en servicio de la gestión de los negocios de

hostelería.

Como ya ha sido comentado a lo largo de este proyecto, el sector de la

hostelería es el motor de la economía española, que sostiene al turismo.

Este sector se va adaptando lentamente al avance tecnológico

comparado a otros sectores, a pesar de su importancia y extensión.

Más concretamente, en el sector de la restauración, la manera de llevar

el negocio y atender a los clientes se lleva realizando exactamente de la

misma manera desde hace muchos años, sin ofrecer nada nuevo en la

gestión a sus clientes, o para la simple mejora del negocio.


Página 194

Este proyecto propone dar un paso, desde hace tiempo necesario, a la

implantación de la tecnología en un sector muy importante. Combina el

conocimiento tecnológico sobre el tratamiento de la información, con

una idea que mejora sustancialmente la buena marcha del negocio,

reduciendo tiempos innecesarios, mejorando la gestión de todas las

actividades, aportando mayor información a los usuarios, y estimulando

el consumo de una nueva manera.

Además este proyecto no plantea una mera herramienta funcional que

ayude en las tareas de gestión al negocio, sino que al mismo tiempo es

una invitación a los clientes para participar en una nueva forma de

tecnología, donde podrán contar con mayor información y control, y por

consiguiente, se busca producir interiormente la satisfacción del placer

intelectual, lúdico y estético de sus usuarios, esto implica el uso de la

tecnología bien diseñada y aplicada.

En definitiva, el sistema presentado en este proyecto, es una

proposición del uso de la tecnología para la mejora de la calidad del

sector más importante en España en el ámbito del negocio, la gestión y

el servicio a los clientes, y por lo tanto, una mejora en la calidad de vida

de todos sus participantes.

10) Futuras mejoras


Página 196

10. FUTURAS MEJORAS

En este apartado se consideran las posibles mejoras que se le podrían

aplicar al sistema para otorgarle una mayor funcionalidad.

Algunas de las posibles funcionalidades adicionales serían:

Incrementar el número de informes: El gerente necesita numerosa

información, y se podría utilizar el sistema ya implantado para

registrar más información acerca del desarrollo del negocio, de tal

manera que todo estaría centralizado.

Exportar informes en PDF: actualmente los informes se muestran

por pantalla y esto implica también la posibilidad de imprimirlos.

Pero extraer los informes en PDF aportaría mayor facilidad para el

almacenamiento digital.

Creación de una red de usuarios: sería una opción interesante

permitir a los clientes hacer comentarios sobre sus platos

preferidos, y que estos los puedan visualizar en tiempo real

durante su estancia en el restaurante, elaborando así un ranking

personalizado de platos preferidos.

11) Bibliografía


Página 198

11. BIBLIOGRAFÍA

A continuación se indican aquellas fuentes consultadas durante la

elaboración del proyecto.

11.1 Libros

[BARR01] Jesús Barranco de Areba, “Metodología del análisis

estructurado de sistemas”, Publicaciones de la

Universidad Pontificia Comillas, Madrid 2001.

[RIVE05] Enrique Rivero Cornelio, Luis Martínez Fuentes,

Israel Alonso Martínez, “Bases de datos relacionales:

Fundamentos y diseño lógico”, Publicaciones de la

Universidad Pontificia Comillas, Madrid 2005.

[LARM03] Craig Larman,“Applying UML and Patterns. 2nd

edition”, 2003.

[WESL99] Addison Wesley Longman, Martin Fowler, “UML gota

a gota”, 1999.

[MUÑO08] Manuel Muñoz García, “Apuntes de Gestión de

Proyectos Informáticos”,Madrid 2008.


Página 199

[ESQU08] Juan Carlos Esquivel, “Apuntes de Ingeniería del

Software II”, Madrid 2008.


Página 200

11.2 Páginas web

[WWW001] Ministerio de Industria, Turismo y Comercio.

http://www.mityc.es/turismo

[WWW002] Federación Española de Hostelería.

http://www.fehr.es/

[WWW003] Portal de comunicación de hostelería.

http://www.hosteleriadigital.es/

[WWW004] Instituto nacional de estadística.

http://www.ine.es/inebmenu/mnu_hosteleria.htm

[WWW005] Restauración electrónica.

http://www.e-restauracion.com

[WWW006] Portal de empleo para la hostelería y turismo.

http://www.emia.es/cgi-bin/master.pl?accion=inicio

[WWW007] Página oficial restbar.

http://www.restbar.com/

http://www.mityc.es/turismo

http://www.fehr.es/

http://www.hosteleriadigital.es/

http://www.ine.es/inebmenu/mnu_hosteleria.htm

http://www.e-restauracion.com/

http://www.emia.es/cgi-bin/master.pl?accion=inicio

http://www.restbar.com/

12) Anexos


Página 202

12. ANEXOS

En este apartado se incluye una valoración económica del proyecto, una

planificación y un manual de usuario.

12.1 Manuales

En este apartado se muestran los dos manuales de que se compone la

aplicación: manual de explotación y manual de usuario.

12.1.1 Manual de explotación

El manual de explotación es aquel dirigido al administrador de la

aplicación.

A continuación, se presentan los pasos para establecer un entorno de

desarrollo idéntico al utilizado en el proyecto. Para ello se requieren los

siguientes pasos: entorno de desarrollo Netbeans, servidor de BBDD

MySQL, servidor Apache Tomcat.

Para la instalación del entorno de desarrollo Netbans, es

necesario seguir estos pasos:

10. En un entorno Windows hay que ejecutar simplemente el

instalador, por ejemplo netbeans-6.1-mljavaee-windows.exe


Página 203

11. Aparecerá la primera ventana del asistente de instalación,

en la que se pregunta los servidores a instalar. Es necesario

seleccionar al menos Glassfish V2 UR2. Pulsar el botón Next.

12. En la siguiente ventana, simplemente se solicitará la

aceptación de los términos de la licencia del producto.

13. En la siguiente ventana se muestra el directorio donde se va

a realizar la instalación y donde se encuentra el JDK de Java.

En principio, se dejan los valores por defecto. En cualquier

caso, es importante tomar nota de dónde se va a instalar


Página 204

Netbeans 6.1 ya que se necesitará esa información

posteriormente. Pulsar Next.

14. La siguiente ventana muestra las opciones de instalación

del servidor Glassfish. En principio, se dejarán los valores por

defecto que aparecen. Si se cambian, es importante tomar nota

de los valores que se asignan al usuario administrador, su

contraseña, puerto HTTP y puerto de la consola de

administración. Pulsar el botón Next.

15. En la siguiente ventana aparece un resumen de los

parámetros de la instalación. Pulsar el botón Install.


Página 205

16. Al finalizar, aparecerá una ventana donde se informará de

que ha finalizado la instalación y ofrecerá la posibilidad de

registrar el producto. Pulsar el botón Finish.

Para la instalación del entorno de MySQL es necesario seguir

estos pasos:

1. Ejecutar el programa mysql-5.0.67-setup.exe. Ello inicializará

el asistente de instalación de MySQL. Pulsar Next.

2. Aparecerá una ventana donde pide escoger el tipo de

instalación. Seleccionar Typical.


Página 206

3. En la siguiente ventana que aparecerá, pulsar Install. Tras la

instalación, aparecerán una serie de ventanas de publicidad de

MySQL y finalmente la ventana siguiente, donde se debe

comprobar que está seleccionado el checkbox para configurar

el servidor. Tras ello, pulsar Finish.


Página 207

4. Aparecerá entonces la ventana inicial del asistente de

configuración del servidor. Pulsar Next.


Página 208

5. En la siguiente ventana, escoger configuración estándar y

pulsar Next.

6. En la siguiente ventana que aparece, deben estar

seleccionados todos los checkboxes que aparecen, tal como se

muestra en la imagen.


Página 209

7. En la siguiente ventana se debe indicar la contraseña del

usuario root. Se recomienda la utilización de la contraseña

root.


Página 210

8. En la siguiente ventana que aparecerá, pulsar el botón

Execute. Cuando finalice la configuración, aparecerá la

siguiente ventana. Pulsar Finish.

Servidor Apache Tomcat: Para instalar el servidor Tomcat,

simplemente se debe descomprimir el fichero apachetomcat-

6.0.14.zip (botón derecho y seleccionar Extraer ficheros). Se

recomienda una descompresión en la raíz del disco C, con lo cual

se creará en este disco la carpeta C:\apache-tomcat-6.0.14. En

caso de que ya estuviese instalado, se recomienda hacer una

copia en la raíz de c.


Página 211

12.1.2 Manual de usuario

Este es el manual para usuarios del Sistema Integral para la Gestión de

Restaurantes. Existen tres grupos fundamentales de usuarios:

Gerente: con derecho de acceso a información reservada como

informes económicos.

Empleados: aquellos usuarios con capacidad de visualizar

comandas e introducir sugerencias.

Clientes: serán todos aquellos usuarios que realicen comandas al

módulo de cocina y que naveguen a través del menú virtual.

En primer lugar, sólo en el módulo de cocina, aparecerá una ventana de

login, para comenzar una sesión como empleado o como gerente:


Página 212

Después en el caso del gerente encontrará este menú:

Mientras que en el caso de ser otro empleado, encontrará este menú

más reducido:


Página 213

En el lado del cliente, en el módulo de mesa, este será su inicio:

Posteriormente, en el caso en el que el gerente o el chef hayan pulsado

sobre introducir sugerencias, se encontrarán con la siguiente ventana:


Página 214

En caso en que se haya selección visualizar comandas, esta será su

ventana:

Si el gerente en su menú, pulsó sobre editar carta virtual, se encontrará

con la siguiente ventana, donde podrá editar la descripción, el número

de plato, los ingredientes, o la dirección de la URL donde está ubicada

la imagen o vídeo demostrativo:


Página 215

Sin embargo, si pulsó sobre acceder informes, obtendrá los siguientes

resultados:


Página 216

Si los clientes, accedieron a través del menú de bienvenida a la carta

virtual, esto será lo que encuentren:


Página 217

Si los clientes pulsan sobre el botón “Más información “accederán a la

siguiente ventana que detalla un plato concreto:


Página 218

12.2 Valoración económica

A continuación se estima el presupuesto del proyecto que incluirá a los

participantes del mismo, director, jefe de proyecto, analista y

programador y los gastos software y hardware pertinentes necesarios

para la implantación del sistema.

12.2.1 Presupuesto en horas hombre

Se han considerado cuatro participantes en el proyecto: director, jefe de

proyecto, analista y programador. En la tabla que se muestra a

continuación, se representa las horas que ha empleado cada

participante, junto con su tarifa y el cálculo de horas empleadas en la

realización del proyecto.

El número de horas se ha calculado teniendo en cuenta que la duración

total del proyecto es de unas 490 horas de trabajo, de las cuales el

director emplea unas 30, el jefe de proyecto 50, el analista 281 y el

programador 120.


Página 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 €


Página 220

12.2.2 Presupuesto de hardware y software

Para el desarrollo del sistema, serán necesarias las siguientes

herramientas:

Elemento

Precio Cantidad

Total

Equipo de

sobremesa

650 € 3 1950 €

Pantalla táctil 310 € 2 620 €

Servidor 283 € 1 283 €

Subtotal HW - 6 2853 €

Windows 150 € 3 450 €

Subtotal SW - 3 450 €

TOTAL - 9 3303 €


Página 221

12.2.3 Presupuesto total del proyecto

En este apartado se muestra el presupuesto total del proyecto después

de los cálculos de tarifas hardware, software y de los participantes.

Tipo

Coste

Sueldos y salarios 24700 €

Hardware 2853 €

Software 450 €

TOTAL 28003 €

El presupuesto final del proyecto es de 28003 €.


Página 222

12.3 Planificación

En este anexo se muestra la planificación realizada para el desarrollo

del proyecto.

autorizada la entrega del proyecto del alumno - iit comillas · detallada que sobre un menú en...

Documents