UNIVERSIDAD DE SANTIAGO DE CHILE

FACULTAD DE INGENIERA DEPARTAMENTO DE INGENIERA INFORMTICA

INFORME N1

Etapa de concepcin

Paola Ignacia Armijo Torres, Roberto Julio Moya Surez, Paulo Ignacio Paillacar Oyarzo, Felipe Andr Tapia Aracena.

Profesor Ayudante Asignatura

: Edgardo Seplveda S. : Felipe Fuentes B. : Proyecto de Base de Datos.

Fecha Entrega: Martes 22 de Abril de 2011.

TABLA DE CONTENIDOS
CAPTULO 1. INTRODUCCIN..................................................................................... 1 CAPTULO 2. FASE DE CONCEPCIN ........................................................................ 3 2.1 DEFINICIN Y ANLISIS DEL PROBLEMA .................................................... 3 2.1.1 Enunciado del problema.................................................................................... 3 2.2 ALCANCES DEL PROYECTO .............................................................................. 4 2.2.1 Personas involucradas en el proyecto ............................................................... 4 2.2.2 Metodologa a usar ............................................................................................ 5 2.3 RIESGOS DEL PROYECTO .................................................................................. 6 2.4 REQUERIMIENTOS DEL SISTEMA .................................................................... 9 2.4.1 Requerimientos funcionales .............................................................................. 9 2.4.2 Requerimientos no funcionales ....................................................................... 11 2.5 CASOS DE USO .................................................................................................... 11 2.5.1 Actores del sistema ......................................................................................... 12 2.5.2 Dependencias .................................................................................................. 13 2.5.3 Casos de uso principales del sistema .............................................................. 15 2.6 DEFINICIN DEL PREMODELO DE DATOS .................................................. 33 2.6.1 Cliente Reserva ............................................................................................... 33 2.6.2 Consumo con y sin reserva. ............................................................................ 34 2.6.3 Delivery ........................................................................................................... 35 2.6.4 Pedido de preparacin a cocina y despacho a las mesas ................................. 35 2.6.5 Modelo de datos completo .............................................................................. 37 2.7 DEFINICIN DEL MAPA DE NAVEGACIN .................................................. 39 2.8 MAPA DE PROCESOS ASOCIADO ................................................................... 47

2.8.1 Proceso de reserva va web ............................................................................. 47 2.8.2 Proceso de reserva va telefnica .................................................................... 48 2.8.3 Proceso de pedido en el restaurant .................................................................. 49 2.8.4 Proceso de delivery ......................................................................................... 50 2.9 MODELO DE NEGOCIO ASOCIADO ................................................................ 50 CAPTULO 3. CONCLUSIONES................................................................................... 53 CAPTULO 4. REFERENCIAS ...................................................................................... 55 CAPTULO 5. ANEXOS ................................................................................................. 56 5.1 LAYOUT DE LA WEB DEL CLIENTE ............................................................... 56 5.2 LAYOUT DEL RESTAURANT ........................................................................... 60 5.3 CARTA GANTT .................................................................................................... 62 5.4 OTROS ANEXOS .................................................................................................. 62

CAPTULO 1. INTRODUCCIN

Ubicado en la calle Freire, de la ciudad de Osorno, el futuro restaurant Casern Freire, un plan personal de Luis Paillacar Silva, quien lo comenz a erigir a fines de 2010. Se va a caracterizar por servir platos de la zona y cerveza artesanal. En este local se desea automatizar algunas tareas, para hacer ms eficiente la atencin a los comensales. Para lograr esto, se desea implementar un sistema que se encargue de las reservas de las mesas, de la entrega de platos a domicilio (delivery), implemente un sistema de puntos para los clientes y organice los platos en la cocina. Hoy en da Internet ha posibilitado que prcticamente cualquier diligencia que antes se realizaba personalmente o va telefnica, se pueda hacer desde cualquier lugar, a cualquier hora y con un mayor grado de comodidad debido a la gran cantidad de opciones y preferencias que se pueden incorporar. Este factor es determinante para el xito de un negocio y se ha convertido en una arista muy importante en el mundo de los negocios. Por todo lo anterior, es que Casern Freire requiere un sistema que posea todas esas caractersticas. El objetivo principal de este trabajo es idear un sistema que se adece a las necesidades del restaurant dados los requerimientos que se han recopilado en la etapa de concepcin del proyecto. En esta entrega se tratar de documentar e identificar todos aquellos detalles esenciales para la construccin de un sistema robusto y funcional, mediante las herramientas que tenemos a disposicin y que han sido expuestas en la ctedra del curso. Cabe destacar que esta etapa es quizs la ms importante, ya que determina el xito o fracaso del proyecto. Por esto ltimo es que se pretende ser lo ms exhaustivo posible en la recopilacin de informacin y procesamiento de ella para lograr el mximo entendimiento del problema.

Como objetivo final, se espera comprender y aprender a utilizar las metodologas usadas para la elaboracin de software, utilizando todos los instrumentos y patrones enseados para este fin. Finalmente, este informe consta de cuatro partes que sintetizan toda la informacin que se ha obtenido hasta el momento: 1. La introduccin que sirve como apoyo a entender el contexto del problema y los objetivos que se quieren lograr. 2. El desarrollo y exposicin de todo lo realizado hasta ahora. Es la parte medular del trabajo y consta del fruto de la investigacin que corresponde a esta primera etapa. 3. Las conclusiones obtenidas terminado esta fase. 4. Algunas referencias que se ocuparon para realizar el trabajo y por ltimo, 5. Un anexo con imgenes e ilustraciones que

complementan el trabajo realizado y ayudan a su comprensin.

CAPTULO 2. FASE DE CONCEPCIN

2.1 DEFINICIN Y ANLISIS DEL PROBLEMA

Todo restaurant debe manejar de alguna manera el estado y uso de sus mesas (entre otras cosas). Pero se convierte en una tarea crtica cuando se manejan reservas, sobre todo cuando este proceso se desea ampliar, dejndolo disponible para que pueda realizarse a travs de Internet. Casern Freire desea automatizar el proceso antes mencionado. Adems de ocupar las tecnologas recientes para generar mayor inters entre sus clientes. Con la informtica se pueden resolver muchos de estos problemas, pero tambin surgen otros. Y no solamente se requiere controlar las reservas de las mesas, tambin manejar un sistema de puntos, dndole ofertas a los clientes buscando la fidelizacin de estos. Adems el restaurant cuenta con pedidos a domicilio (delivery) el cual, en conjunto con las reservas de las mesas, se pretenden registrar todos los platos que se consuman en el restaurant para generar reportes. Por ltimo, idear un medio por el cual categorizar los pedidos de los clientes de tal manera que puedan ser mostrados en terminales dispuestos estratgicamente (en la cocina para los platos preparados, en el bar para los bebestibles). Por lo tanto se desea encontrar la solucin que genere la mayor cantidad de soluciones sin crear nuevos problemas.

2.1.1 Enunciado del problema

Se requiere un sistema que controle y administre las reservas de las mesas; ya sea de forma telefnica (lo har una persona) o mediante Internet. Las mesas deben planificarse de tal manera que no ocurran problemas entre horarios. Debe admitir

aplazamientos y cancelaciones. Adems el cliente tiene la posibilidad de pedir su orden por Internet. Se desea registrar los pedidos hechos en el local, internet y a domicilio con el fin de obtener la mayor cantidad de datos que puedan ayudar a elaborar estadsticas y de esta forma confeccionar estrategias de negocio. Por cada reserva, pedido en local o delivery hecho, el cliente acumula puntos (proporcionales posteriormente. Para implementar la idea anterior, los clientes deben registrarse en el sistema, con algunos de sus datos personales; de esta manera se podrn asignar los puntos de forma eficiente. al monto consumido). Estos puntos pueden ser canjeados

2.2 ALCANCES DEL PROYECTO

2.2.1 Personas involucradas en el proyecto

El dueo del restaurant, quien ser el sponsor del proyecto y ser el cliente directo del grupo. Es quien dar el lineamiento de los requerimientos del proyecto.

Los clientes, quienes se vern afectados por el sistema cuando decidan consumir en el Casern Freire. Ellos desearn un sistema fcil de usar para sus reservas, deliverys y manejo de puntos. No tienen incidencia directa en las decisiones del proyecto, pero buena parte de la funcionalidad del sistema debe satisfacerlos a ellos.

Diseadores y programadores, son alumnos de la Universidad de Santiago, los cuales rinden el curso de Proyecto de base de datos. Ellos son los encargados de realizar la etapa de concepcin del proyecto, diseo, desarrollo y transicin. Es decir levantar requerimientos, realizar modelos de negocios, mapas de navegacin, modelo de datos, prototipos, programar, implementar y capacitar al personal en Casern Freire.

2.2.2 Metodologa a usar

Las metodologas sirven principalmente para ver cmo se puede enfrentar un problema determinado, y hallar su solucin. Existen variadas metodologas tales como, OMT++, Scrum, XP, UP, etc. Para el caso de este proyecto, la metodologa a utilizar es una variante de UP, llamada RUP (Rational Unified Process)[1]. RUP utiliza los procesos de desarrollo de software, en conjunto con UML (Unified Model Language), para ser utilizada para anlisis, implementacin y documentacin de sistemas OO (Object Oriented). A diferencia de, por ejemplo, OMT++, RUP no es un sistema con pasos rgidos, sino que es un sistema que se adapta a cada organizacin que lo requiera. En RUP, el sistema se divide en objetos, que es la mnima unidad de este sistema, los cuales contienen datos y funciones que interaccionan entre ellos. RUP establece 4 fases, en las cuales hay iteraciones que dependen del proyecto. Las fases son: Fase de inicio o concepcin: Aqu se realizan los planes de las fases a partir de la Carta Gantt, los casos de uso esenciales, los riesgos del proyecto. Adicionalmente se ve la idea, visin, enmarcacin y alcances del proyecto.

Fase de elaboracin: Aqu se realiza el plan del proyecto, casos de uso completos, a partir de los esenciales, mitigacin de riesgos. Planificacin de actividades y recursos, especificndolos.

Fase de construccin: Como lo dice su nombre, se basa en la construccin del producto, a travs de la arquitectura y planes obtenidos de las etapas anteriores. Al final de esta fase, el producto debe estar prcticamente listo para su uso. Este debe incluir un manual de usuario para que el cliente pueda utilizarlo.

Fase de transicin: Se instala el proyecto al cliente, y se capacita a los usuarios, lo cual incluye: manufactura, envo, entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios.

2.3 RIESGOS DEL PROYECTO

Los riesgos del sistema consisten en ver cules pueden ser las principales problemticas que pueden suscitarse al momento de utilizar el sistema y a su vez, de aquellas personas que estn ntegramente involucradas con el negocio. Los riesgos se pueden categorizar segn el grado que estos posean. Las categoras son:

Riesgos que necesitan monitorizacin. Riesgos que necesitan investigacin. Riesgos que necesitan mitigacin

Para el caso del restaurant, los principales riesgos encontrados fueron:

1. Cambio de sponsor: Sponsor es la persona que coloca los recursos para generar el negocio. Este desea hacer los sistemas y el restaurant, segn su decisin. En caso de que suceda un cambio de sponsor, es decir, llegue otra persona a tomar las riendas del negocio, el sistema puede seguir siendo utilizado segn lo que desee el nuevo sponsor. Este riesgo se considera mnimo, ya que el negocio est recin partiendo. 2. Disponibilidad de sponsor: El sponsor no siempre va a tener el tiempo para aclarar las dudas de las personas que van a realizar el sistema. Por lo tanto, esto se refiere a que el sponsor coloque en duda si su sistema funcione. En el caso del proyecto casern Freire, la disponibilidad se encuentra en riesgo medio, ya que solo se puede contactar al sponsor o a alguno de los stakeholders mediante llamadas telefnicas o mediante e-mails, los cuales poseen restricciones de horario. 3. Disponibilidad del trabajo humano: Las personas encargadas del sistema pueden tener una vasta experiencia haciendo proyectos, pero si estas no se coordinan, pueden haber dificultades al momento de saber cules son los actores involucrados dentro del proyecto. Para el proyecto "casern Freire", el riesgo de esto es mnimo/medio, ya que el equipo de trabajo, si bien ha habido reuniones para establecer acuerdos, no tiene disponibilidad de tiempo para generar conversaciones grupales. 4. Definicin de alcance: Los alcances sirven para ver qu es lo que debe y no debe hacer el sistema. Estos son dados a partir de datos extrados de conversaciones con las personas que rodean al sistema, ya sean trabajadores, stakeholders o sponsors. Estos pueden variar en el tiempo, haciendo que su riesgo sea medio. 5. Cambios en los requerimientos: Se refiere a los cambios que se puedan suscitar, debido a que alguna de las personas que rodean al sistema, necesiten agregar, eliminar o editar algunos de los requerimientos del sistema. Adicionalmente, pueden modificar los requisitos no funcionales del sistema, como por ejemplo, cambio de sistema operativo. El riesgo de que esto suceda es medio/alto, ya que

el stakeholder puede cambiar los requerimientos funcionales del restaurant, tales como: entregas por separado de los platos y bebestibles, que fue lo que sucedi ahora ltimo. 6. Disponibilidad de infraestructura/equipo: La infraestructura, se refiere a los elementos fsicos utilizados para la construccin del recinto, y en cuanto a la disponibilidad de equipo, hace referencia a la adquisicin de equipo computacional, para que el sistema pueda ser utilizado. El riesgo de disponibilidad en infraestructura y/o equipo es mnimo, ya que este restaurant es un negocio que recin est partiendo, y los equipos fueron adquiridos hace no ms de 2 meses. 7. Aspectos legales: Esto se refiere a los permisos dados para que el establecimiento pueda utilizarse. Dentro de estos estn el expendio de bebidas alcohlicas, sitios para personas fumadoras y no fumadoras, permisos sanitarios, etc. Los riesgos de estos son mnimos, ya que la empresa mantiene todas estas actividades al da. 8. Aspectos de mercado: Se refiere a ver la competencia cercana al restaurant, a travs de encuestas, consultas, sugerencias y principalmente, el feedback con los clientes. En este caso, el riesgo del restaurant es medio/alto, ya que este se encuentra recin tomando sus primeras armas. 9. Aspectos sociales: Se refiere fundamentalmente a la relacin entre el restaurant y el cliente. Para conseguir que el cliente sienta gusto de venir al restaurant, este debe recibir un trato como se merece y para esto, se debe capacitar al personal a cargo. El riesgo es medio, ya que an no hay una capacitacin de personal, ya que eso es un proceso que se lleva a cabo en estos momentos.

A continuacin, se da la matriz de riesgo, que es un medio grafico en donde se muestra si los riesgos necesitan monitorizacin, investigacin o mitigacin. Se debe tener en cuenta que la escala es de 1 a 5, en donde 1 es riesgo ms bajo y 5 el ms alto.

Tabla 2-1: Matriz de riesgo Restaurant Casern Freire

Probabilidad

(8)

(5)

(3)

(4)(9)

(1)

(7)

(2)

(6)

Impacto
2.4 REQUERIMIENTOS DEL SISTEMA

2.4.1 Requerimientos funcionales

El sistema debe permitir a los clientes poder registrarse. El sistema debe permitir a los clientes, que ya estn registrados, que puedan cambiar sus datos (ej. direccin, telfono). No as su nombre o RUT. El sistema debe permitir a un usuario registrado darse de baja del sistema.

10

El sistema debe ser capaz de enviar a su correo la contrasea a un cliente registrado en el caso que no la recuerde. El sistema debe permitir a un usuario administrador poder dar de baja a un cliente registrado. El sistema debe llevar un registro de todo lo que se consuma en el restaurant. El sistema deber tener la posibilidad de admitir un usuario administrador que sea capaz de anotar todo lo que se consuma en el restaurant. El usuario registrado deber tener la posibilidad de reservar mesas a travs de internet. El sistema no debe permitir a un cliente que no est registrado que pueda reservar una mesa por internet. El usuario registrado puede ordenar el men al momento de reservar una mesa por internet. El sistema debe permitir postergar y/o anular una reserva; ya sea por telfono (llevada a cabo por un usuario administrador) o por internet. El sistema deber tener la posibilidad de admitir un usuario administrador capaz de anular, postergar y reservar mesas. Esto para manejar las reservas hechas por telfono.

El sistema deber tener la posibilidad de mostrar los datos de los clientes registrados a algn usuario con privilegios preestablecidos. El sistema debe permitir hacer pedidos a domicilio (delivery) mediante internet solo a clientes registrados. El sistema debe coordinar los horarios de las mesa de manera que no existan conflictos. El sistema debe coordinar los platos y bebidas pedidos en una mesa de manera que los categorice y muestre en el terminal correspondiente (cocina o bar). El sistema debe mostrar, en los terminales correspondientes, los platos y bebidas en orden de llegada.

11

El sistema debe ser capaz de cancelar una orden y reordenar los pedidos posteriores. El sistema debe agregar automticamente los platos pedidos en una reserva hecha por internet, en el horario correspondiente, al momento que la mesa sea ocupada por las personas que reservaron.

El sistema debe ser capaz de cambiar los mens que se ofrecen por internet. El sistema debe ser capaz de cambiar los platos que los clientes pidan en el local. El sistema debe ser capaz de lidiar con la devolucin de platos y registrar el motivo de la devolucin.

2.4.2 Requerimientos no funcionales

El sistema debe implementarse bajo una plataforma Web. Debe dar la posibilidad de ingresar a este mediante internet. El ingreso mediante internet hacia el sistema puede hacerse desde cualquier sistema operativo o navegador web. El sistema debe registrar todos los datos en una base de datos. El sistema debe permitir ser ejecutado simultneamente por ms de un usuario del sistema. El sistema debe tener un tiempo de respuesta no mayor a 2 segundos por consulta. El sistema debe ser capaz de recuperarse ante eventuales errores.

2.5 CASOS DE USO

12

A continuacin se presenta el modelo de casos de uso del sistema Casern Freire:

ADMINISTRAR MESAS

GESTIONAR MESA RESERVA GESTIN CLIENTE

ADMINISTRAR PLATOS

Administrador

PAGAR RESERVA

CONSULTA DE PUNTOS Mesero

GESTIONAR DELIVERY

Cliente

Gestion de pedidos

GESTIONAR PLATOS RESERVA

Jefe de cocina

GESTION DE MESAS LOCAL

Telefonista

Anfitrion

Figura 2-1: Casos de uso del Restaurant Casern Freire

2.5.1 Actores del sistema

A continuacin se listan los actores del sistema con su nombre y una breve especificacin de su rol. Nombre Administrador Cdigo Administrador Breve especificacin Persona que maneja clientes,

ubicacin de mesas, Anfitrion Anfitrion Persona ubicada en la entrada del local la cual recibe a los clientes y

13

los ubica en sus mesas. Cliente Cliente Cualquier persona que haga un pedido delivery o reserva en el local. Ya sea de manera telefnica o internet. Siempre queda

registrado en el sistema. Jefe de cocina Jefe_de_cocina Persona que dirige la cocina

indicando que platos preparar y eliminando los ya preparados. Mesero Mesero Persona que recibe los pedidos del local y hace operaciones CRUD sobre ellos en el sistema. Telefonista Telefonista Persona que recibe llamados

telefnicos y hace operaciones dependiendo de lo que implique la llamada recibida.

2.5.2 Dependencias

Lista de dependencias: Nombre Cdigo Influent Object Dependent Object AdminGestionCliente AdminGestionCliente GESTIN CLIENTE AdminMesas AdminMesas ADMINISTRAR MESAS AdminPedidos AdminPlatos AdminPedidos AdminPlatos Gestion de pedidos ADMINISTRAR Administrador Administrador Administrador Administrador

14

PLATOS AdminPuntos AdminPuntos CONSULTA PUNTOS AnfitrionMesas AnfitrionMesas GESTION MESAS LOCAL ClienteDelivery ClienteDelivery GESTIONAR DELIVERY ClienteGestionCliente ClienteGestionCliente GESTIN CLIENTE ClienteMesaReserva ClienteMesaReserva GESTIONAR MESA RESERVA ClientePagar ClientePlatosReserva ClientePagar ClientePlatosReserva PAGAR RESERVA GESTIONAR PLATOS RESERVA ClientePuntos ClientePuntos CONSULTA PUNTOS CocinaPedidos MeseroPedidos TelefonistaDelivery CocinaPedidos MeseroPedidos TelefonistaDelivery Gestion de pedidos Gestion de pedidos GESTIONAR DELIVERY TelefonistaGestionclie nte TelefonistaMesaReser va TelefonistaPuntos TelefonistaGestionclien te TelefonistaMesaReserv a TelefonistaPuntos GESTIN CLIENTE GESTIONAR MESA RESERVA CONSULTA PUNTOS DE Telefonista Telefonista Telefonista Jefe de cocina Mesero Telefonista DE Cliente Cliente Cliente Cliente Cliente Cliente DE Anfitrion DE Administrador

15

2.5.3 Casos de uso principales del sistema

Se muestra una lista de los casos de uso principales del sistema: Nombre ADMINISTRAR MESAS Cdigo ADMINISTRAR_MESAS Modelo Ligado A Orientado a

objetos 'Casern Freire' ADMINISTRAR PLATOS ADMINISTRAR_PLATOS Modelo Orientado a

objetos 'Casern Freire' CONSULTA DE PUNTOS CONSULTA_DE_PUNTOS Modelo Orientado a

objetos 'Casern Freire' GESTION LOCAL GESTION DE PEDIDOS DE MESAS GESTION_DE_MESAS_LOC AL GESTION_DE_PEDIDOS Modelo Orientado a

objetos 'Casern Freire' Modelo Orientado a

objetos 'Casern Freire' GESTIONAR DELIVERY GESTIONAR_DELIVERY Modelo Orientado a

objetos 'Casern Freire' GESTIONAR RESERVA GESTIONAR RESERVA GESTIN CLIENTE MESA GESTIONAR_MESA_RESER VA PLATOS GESTIONAR_PLATOS_RES ERVA GESTION_CLIENTE Modelo Orientado a

objetos 'Casern Freire' Modelo Orientado a

objetos 'Casern Freire' Modelo Orientado a

objetos 'Casern Freire' PAGAR RESERVA PAGAR_RESERVA Modelo Orientado a

objetos 'Casern Freire'

16

A continuacin se especificarn de manera ms profunda los casos de uso del sistema.

2.5.3.1 Caso de Uso ADMINISTRAR MESAS

Carta de caso de uso ADMINISTRAR MESAS

Nombre Cdigo Ligado A

ADMINISTRAR MESAS ADMINISTRAR_MESAS Modelo Orientado a objetos 'Casern Freire'

Pasos de accin del caso de uso ADMINISTRAR MESAS

El administrador agrega una mesa al local, con su respectiva ubicacin (Excepcin 1: No se puede colocar la mesa en el lugar especificado). El administrador desea eliminar una mesa, con su ubicacin. Para esto, va a la pestaa "Eliminar mesa", la cual la elimina por completo (Excepcin 2: La mesa que desea eliminar no se encuentra disponible). El administrador desea modificar la posicin de la mesa. Para esto, va a la pestaa "Modificar mesa", y modifica los datos (Excepcin 3: La mesa que desea modificar es inexistente). Excepciones del caso de uso ADMINISTRAR MESAS

Excepcin 1: No se puede colocar la mesa en el lugar especificado La posicin en que se desea colocar la mesa, est ocupado. Excepcin 2: La mesa que desea eliminar no se encuentra disponible

17

Al buscar una mesa para eliminar, esta es inexistente. Excepcin 3: La mesa que desea modificar es inexistente La mesa buscada, no existe.

Precondiciones del caso de uso ADMINISTRAR MESAS El sistema se ha iniciado. El administrador se autentica correctamente y se

encuentra en la vista de administracin de mesas.

o o

Post-condiciones del caso de uso ADMINISTRAR MESAS

El sistema se ha actualizado. El registro de las mesas agregadas, modificadas y eliminadas, se ha actualizado.

Lista de todas las dependencias del caso de uso ADMINISTRAR MESAS

Nombre

Cdigo

Nombre de la Clase

AdminMesas

AdminMesas

Dependency

2.5.3.2 Caso de Uso ADMINISTRAR PLATOS

18

Carta de caso de uso ADMINISTRAR PLATOS

Nombre Cdigo Ligado A

ADMINISTRAR PLATOS ADMINISTRAR_PLATOS Modelo Orientado a objetos 'Casern Freire'

Pasos de accin del caso de uso ADMINISTRAR PLATOS

El administrador desea agregar algn elemento al men. El elemento puede ser un plato, un postre, un lquido o agregado. Para esto, ingresa a la pestaa "Agregar nuevo". El administrador agrega nuevo plato, agregado, postre o lquido al men (Excepcin 1: Lo ingresado ya se encuentra en la BD). El administrador desea modificar algo en el men. Para esto debe ir a la pestaa "Modificar". Para esto selecciona un elemento del men, lo modifica y lo guarda en el sistema. El administrador desea eliminar un elemento del men. Para esto, va a la pestaa "Eliminar" y desde ah elige si desea eliminar un men completo, o bien, un ingrediente de un men.

Excepciones del caso de uso ADMINISTRAR PLATOS

Excepcin 1: El ingrediente ingresado ya se encuentra en la BD El administrador ha ingresado un ingrediente que ya se encuentra en la lista de ingredientes, o bien, dentro de un men, ingresa un ingrediente ya colocado.

19

Pre-condicin del caso de uso ADMINISTRAR PLATOS

El administrador se ha autenticado correctamente. Este se encuentra en la vista de men.

Post-condicin del caso de uso ADMINISTRAR PLATOS

El sistema se ha actualizado. Los elementos del men han sido actualizados de forma satisfactoria.

Lista de todas las dependencias del caso de uso ADMINISTRAR PLATOS

Nombre

Cdigo

Nombre de la Clase

AdminPlatos

AdminPlatos

Dependency

2.5.3.3 Caso de Uso CONSULTA DE PUNTOS

Carta de caso de uso CONSULTA DE PUNTOS

Nombre Cdigo Ligado A

CONSULTA DE PUNTOS CONSULTA_DE_PUNTOS Modelo Orientado a objetos 'Casern Freire'

20

Pasos de accin en caso de uso CONSULTA DE PUNTOS

Permite a un determinado cliente registrado consultar la cantidad de puntos que lleva acumulados hasta el momento de realizar la consulta. El usuario telefonista y el usuario administrador pueden ver los puntos de todos los clientes.

Lista de todas las dependencias del caso de uso CONSULTA DE PUNTOS Nombre Cdigo Nombre de la Clase

AdminPuntos ClientePuntos TelefonistaPuntos

AdminPuntos ClientePuntos TelefonistaPuntos

Dependency Dependency Dependency

2.5.3.4 Caso de Uso GESTION DE MESAS LOCAL

Carta de caso de uso GESTION DE MESAS LOCAL

Nombre Cdigo Ligado A

GESTION DE MESAS LOCAL GESTION_DE_MESAS_LOCAL Modelo Orientado a objetos 'Casern Freire'

21

Pasos de accin del caso de uso GESTION DE MESAS LOCAL

El anfitrin en el momento de la llegada de clientes al local verifica si tiene reserva , en el caso de que el cliente no tenga reserva busca una mesa desocupada adecuada (Excepcin 1: No hay mesas disponibles) para el cliente, cambia el estado de la mesa a ocupada y lo gua hacia ella. Adems el anfitrin cambia el estado de las mesas cuando se desocupan. Excepciones del caso de uso GESTION DE MESAS LOCAL

Excepcin 1: No hay mesas disponibles El sistema indica al anfitrin que no quedan mesas disponibles para que ste avise a los clientes.

Precondicin del caso de uso GESTION DE MESAS LOCAL

El administrador de cocina se autentica correctamente en la seccin de administracin de mesas, mostrando las mesas libres y mesas ocupadas. El administrador se encuentra en la vista "Estadsticas del Restaurant"

Post-condicin en caso de uso GESTION DE MESAS LOCAL

El sistema se actualiza, guardando los datos de la mesa con las reservas pedidas.

Lista de todas las dependencias del caso de uso GESTION DE MESAS LOCAL

22

Nombre

Cdigo

Nombre de la Clase

AnfitrionMesas

AnfitrionMesas

Dependency

2.5.3.5 Caso de Uso GESTION DE PEDIDOS

Carta de caso de uso GESTION DE PEDIDOS

Nombre Cdigo Ligado A

GESTION DE PEDIDOS GESTION_DE_PEDIDOS Modelo Orientado a objetos 'Casern Freire'

Pasos de accin del caso de uso GESTION DE PEDIDOS

El usuario mesero toma el pedido en las mesas y a continuacin ingresa al sistema el pedido completo de cada mesa, es decir, los platos, bebestibles, agregados y postres que hayan solicitado indicando a que mesa pertenecen. Adems puede agregar elementos al pedido de cada mesa, como tambin modificar el pedido y eliminar los elementos que se vayan entregando El usuario jefe de cocina ve una lista con los platos requeridos por cada mesa, solo los que requieren preparacin, en el orden que han sido pedidos. Adems puede eliminar de la lista los platos ya entregados. El usuario administrador puede ver todos los pedidos.

23

Lista de todas las dependencias del caso de uso Gestin de pedidos

Nombre

Cdigo

Nombre de la Clase

AdminPedidos CocinaPedidos MeseroPedidos

AdminPedidos CocinaPedidos MeseroPedidos

Dependency Dependency Dependency

2.5.3.6 Caso de Uso GESTIONAR DELIVERY

Carta de caso de uso GESTIONAR DELIVERY

Nombre Cdigo Ligado A

GESTIONAR DELIVERY GESTIONAR_DELIVERY Modelo Orientado a objetos 'Casern Freire'

Pasos de accin de caso de uso GESTIONAR DELIVERY

24

El cliente puede hacer un pedido delivery por telfono o por internet. Para hacer el pedido por internet debe registrarse y elegir los platos. Luego Debe elegir el medio de compra, el cual podr ser por internet (con tarjeta de crdito) o por pago en efectivo en el momento de la entrega. Si el pedido delivery es telefnico la recepsionista recibe el pedido, lo guarda en el sistema y el pago es obligatoriamente en efectivo por parte del cliente cuando le llega el pedido a su casa.

Post-condicin de caso de uso GESTIONAR DELIVERY

El cliente recibe en su casa el pedido realizado. En el caso de no haber pagado por internet, el cliente debe cancelar el pedido. Lista de todas las dependencias del caso de uso GESTIONAR DELIVERY

Nombre

Cdigo

Nombre de la Clase

ClienteDelivery TelefonistaDelivery

ClienteDelivery TelefonistaDelivery

Dependency Dependency

2.5.3.7 Caso de Uso GESTIONAR MESA RESERVA

Carta de caso de uso GESTIONAR MESA RESERVA

25

Nombre Cdigo Ligado A

GESTIONAR MESA RESERVA GESTIONAR_MESA_RESERVA Modelo Orientado a objetos 'Casern Freire'

Pasos de accin del caso de uso GESTIONAR MESA RESERVA

El cliente escoge una opcin. Si la opcin escogida es crear una nueva reserva, el cliente debe elegir las mesas en el layout (Excepcin 1: La mesa seleccionada no se encuentra disponible). Si el cliente desea modificar su mesa(s) reservada(s), deber ir a la opcin "Modificar reserva" (Excepcin 1: La mesa seleccionada no se encuentra disponible). Si la opcin escogida es ver su reserva, el cliente solo debe ir a la opcin "Ver reserva". En caso de que una reserva fuese eliminada, las mesas son eliminadas en forma de cascada, es decir, las mesas que iban a ser ocupadas, pasan a estar libres. Excepciones del caso de uso GESTIONAR MESA RESERVA

Excepcin 1: La mesa seleccionada no se encuentra disponible: El cliente ha seleccionado una mesa que previamente ha sido ocupada.

Pre-condicin del caso de uso GESTIONAR MESA RESERVA

1. El sistema se ha iniciado

26

2. El cliente est autenticado correctamente y se encuentra en la vista "Reserva". 3. Para las mesas de una nueva reserva, la nueva reserva est creada y para modificar la reserva de mesa, se hace sobre una reserva existente.

Post-condicin del caso de uso GESTIONAR MESA RESERVA

Para una reserva dada, el sistema realiza las operaciones CRUD pertinentes en la tabla correspondiente a la relacin entre mesas y reservas. El control es devuelto al usuario, indicando el estado de la operacin. El usuario contina o termina haciendo uso de la aplicacin.

Lista de todas las dependencias del caso de uso GESTIONAR MESA RESERVA

Nombre

Cdigo

Nombre de la Clase

ClienteMesaReserva TelefonistaMesaReserva

ClienteMesaReserva TelefonistaMesaReserva

Dependency Dependency

2.5.3.8 Caso de Uso GESTIONAR PLATOS RESERVA

27

Carta del caso de uso GESTIONAR PLATOS RESERVA

Nombre Cdigo Ligado A

GESTIONAR PLATOS RESERVA GESTIONAR_PLATOS_RESERVA Modelo Orientado a objetos 'Casern Freire'

Pasos de accin para el caso de uso GESTIONAR PLATOS RESERVA

El cliente desea agregar un plato a su reserva. Para esto, debe ir dentro de su perfil a "agregar plato", el cual le muestra los platos a seleccionar (Excepcin 1: El plato que desea el cliente no existe). El cliente desea modificar el plato para la reserva, esto implica, quitar o agregar platos. Para modificar, el cliente ingresa a "Modificar plato" (Excepcin 1: El plato que desea el cliente no existe). El cliente desea ver sus paltos, para esto, el cliente se dirige a "Ver platos" (Excepcin 2: El cliente no posee platos).

Excepciones del caso de uso GESTIONAR PLATOS RESERVA

Excepcin 1: El plato que desea el cliente no existe: Si el plato que desea el cliente no se encuentra en el men, el cliente puede armar su plato personalizado, a partir d las porciones individuales. Excepcin 2: El cliente no posee platos: Este caso se da cuando un cliente ha realizado una reserva, sin la existencia de platos aadidos. Se indica al cliente que no hay platos para esa reserva.

28

Pre-condicin de caso de uso GESTIONAR PLATOS RESERVA

Se muestran los platos disponibles en ese momento.

Post-condicin del caso de uso GESTIONAR PLATOS RESERVA

Para una reserva dada, el sistema realiza las operaciones CRUD pertinentes en la tabla correspondiente a la relacin entre platos y reservas. El control es devuelto al usuario, indicando el estado de la operacin. El usuario contina o termina haciendo uso de la aplicacin.

Lista de todas las dependencias del caso de uso GESTIONAR PLATOS RESERVA

Nombre

Cdigo

Nombre de la Clase

ClientePlatosReserva Telefonista

ClientePlatosReserva Telefonista

Dependency Actor

2.5.3.9 Caso de Uso GESTIN CLIENTE

29

Carta de caso de uso GESTIN CLIENTE

Nombre Cdigo Ligado A

GESTIN CLIENTE GESTION_CLIENTE Modelo Orientado a objetos 'Casern Freire'

Pasos de accin de caso de uso GESTIN CLIENTE

El usuario cliente o el usuario telefonista crean una cuenta. Para esto debe ingresar como datos obligatorios el Nombre completo, Rut, Telfono de contacto, Direccin y Mail de contacto del cliente (Excepcin 1: Faltan datos obligatorios), el sistema guarda los datos del cliente. Tambin el usuario cliente y usuario telefonista pueden modificar la cuenta de usuario cliente, se va a la pestaa "Modificar cliente", en el cual se modifican los datos del cliente, incluidos los datos que no son obligatorios (Excepcin 1: Faltan datos obligatorios), el sistema< guarda los datos en la BD. El usuario administrador desea eliminar una cuenta. Este se elimina debido a la cantidad de "Bluff" realizados, es decir, la cancelacin de reservas, la no asistencia a una reserva. Para esto, el usuario administrador tiene una pestaa especial para eliminar a los clientes mal evaluados (Excepcin 2: No existen clientes), este enva un correo de notificacin al usuario, nombrando las razones de su eliminacin. El usuario cliente, el usuario telefonista y el usuario administrador desean ver los clientes (Excepcin 2: No existen clientes). Para el caso del cliente, solo puede ver sus propios datos. Este hace ingreso mediante su cuenta. Para el caso del administrador y telefonista, estos pueden ver los datos de todos los clientes que se encuentren registrados.

30

Excepciones de caso de uso GESTIN CLIENTE

Excepcin 1: Faltan datos obligatorios El cliente recibe un mensaje de error, destacando los datos que faltan por aadir. Excepcin 2: No existen clientes para eliminar No hay un registro de clientes. El registro se encuentra vaco, por lo tanto, no se puede hacer ninguna operacin de eliminar, modificar o ver un cliente.

Pre-condiciones de caso de uso GESTIN CLIENTE

o o o

El sistema se ha iniciado. Cliente desea inscribirse, modificar sus datos y observarlos, con una autenticacin correcta. El administrador observa y elimina clientes.

Post-condiciones de caso de uso GESTIN CLIENTE

o o

El sistema ha actualizado los datos del cliente (Cliente, telefonista y administrador). El sistema ha eliminado clientes de forma satisfactoria (Administrador).

31

Lista de todas las dependencias del caso de uso GESTIN CLIENTE

Nombre

Cdigo

Nombre de la Clase

AdminGestionCliente ClienteGestionCliente TelefonistaGestioncliente

AdminGestionCliente ClienteGestionCliente TelefonistaGestioncliente

Dependency Dependency Dependency

2.5.3.10 Caso de uso PAGAR RESERVA

Carta de caso de uso PAGAR RESERVA

Nombre Cdigo Ligado A

PAGAR RESERVA PAGAR_RESERVA Modelo Orientado a objetos 'Casern Freire'

Pasos de accin en caso de uso PAGAR RESERVA

El cliente paga por internet la reserva pedida. Puede pagar el total del men pedido, si es que lo solicit, o el mnimo para la reserva de 0.5 UF. (Excepcin 1)

32

Excepciones del caso de uso PAGAR RESERVA

Excepcin 1: El usuario no posee fondos: Si el usuario no posee fondos se le avisa que cambie la cuenta que indicaba o sino finalmente no se realiza la reserva.

Pre-condicin del caso de uso PAGAR RESERVA

o o

El sistema ha iniciado y el cliente se encuentra autenticado correctamente. Cliente ha realizado, de forma efectiva, la reserva, hasta el momento del pago.

Post-condicin del caso de uso PAGAR RESERVA

o o

1.- Cliente cancela su cuenta total o mnima. 2.- Aumentan puntos del cliente, dependiendo de la cantidad de personas de la reserva.

Lista de todas las dependencias de caso de uso PAGAR RESERVA

Nombre

Cdigo

Nombre de la Clase

33

ClientePagar

ClientePagar

Dependency

2.6 DEFINICIN DEL PREMODELO DE DATOS

El modelo de datos que responde a los requerimientos del problema debe poder manejar los pedidos de delivery, de reserva de mesa por internet o por telfono, as tambin el consumo que se realiza sin reserva previa. Gestionar los mens y platos. Ver los pedidos en mesa y ver cuando estos pedidos para una mesa ya fueron entregados. El desglose de los patrones de modelo usado es el siguiente.

2.6.1 Cliente Reserva

Figura 2-2: Modelo cliente reserva

34

En este pre modelo se observa que el cliente puede realizar las reservas con el patrn de documento, el cual tiene una lnea de detalle asociada a los platos, adems de tener las mesas asociadas a la reserva.

2.6.2 Consumo con y sin reserva.

Figura 2-3: Modelo consumo con y sin reserva

Para el consumo sin reserva son los mismos patrones de reserva, solo que no est contemplado un cliente registrado en el consumo. El consumo con reserva a nivel de patrn de modelo es casi idntico al anterior, solo que las entidades pretenden manejar el consumo real y no el terico de la reserva.

35

2.6.3 Delivery

Figura 2-4: Modelo delivery

El delivery es otra aplicacin del clsico modelo de documentos, tal como se ha visto en los casos anteriores.

2.6.4 Pedido de preparacin a cocina y despacho a las mesas

Para este caso se utilizar el clsico patrn de orden de fabricacin y gua de despacho, donde el material sern los platos que sern pedidos por una mesa y donde para cara orden de fabricacin (de preparacin en cocina) se generar una orden de despacho que indique el los platos salieron para cada mesa.

36

Figura 2-5: Modelo Pedido de preparacin a cocina y despacho a las mesas

El resto de las reglas del negocio de aplican con atributos de las entidades relacionadas. Tambin falta aadir que tanto los platos como las mesas tienen una agenda asociada que permite saber la disponibilidad de las mesas, y la existencia en el tiempo de los platos en el men.

37

2.6.5 Modelo de datos completo

Este es el modelo que implementa cada uno de los modelos patrones vistos con anterioridad. El cual implementa los requerimientos de documentos del delivery, reservas, consumo real de los clientes registrados, y de los clientes no registrados. Tambin maneja los puntos de fidelizacin de los clientes, los pedidos de preparacin de un mesero a la cocina y el correspondiente egreso de un plato de la cocina a una mesa. Maneja la agenda de las mesas y el historial de los platos en el tiempo, es decir permite saber que platos estn o estarn disponibles en tal fecha como platos disponibles para el restaurant. A modo ilustrativo se muestran las imgenes del modelo completo y dos vistas ampliadas del mismo modelo.

38

Figuras 2-6, 2-7 y 2-8: Vistas del modelo de datos

39

2.7 DEFINICIN DEL MAPA DE NAVEGACIN

El mapa de navegacin sirve para ver los contenidos que pueden tener los usuarios, administradores y algn otro actor involucrado dentro del sistema. En la pgina web, se muestra comnmente como el nombre de mapa del sitio, en donde se van desglosando los sectores, es decir, cada uno de los enlaces y a que llevan. Para el caso del Restaurant Casern Freire, se crea un mapa de navegacin a partir de la informacin que fue entregada por el stakeholder involucrado, Don Luis Paillacar.

40

Administrador

(Desglose ms abajo) (Desglose ms abajo) (Desglose ms abajo) (Desglose ms abajo) (Desglose ms abajo) (Desglose ms abajo)

Cliente

Telefonista Iniciar Sesin Mesero

Jefe de cocina

Anfitrin

Inicio
Ingresar datos Registrarse

Finalizar

Volver Volver

Recuperar

Olvid mi contrasea

Ingrese Nombre y rut Volver Volver

41

Consultar puntos

Volver Agregar pedido Elegir mesa Cantidad de personas Volver Volver Cancelar reserva Terminar reserva Terminar pedido pagar

pagar

Realizar Reserva

Fecha

Ver Reserva Modificar Reserva Pagina inicio cliente Pedido Mesa Pago efectivo Finalizar Confirmacin de transaccin volver volver

Delivery

Agregar platos y bebidas

Terminar pedido Volver

Finalizar

Pago con tarjeta

Volver

Eliminar Cuenta Cerrar sesin

42

Consultar puntos

Ingresar cliente a consultar Volver

Volver Terminar pedido pagar

Agregar pedido Elegir mesa Cantidad de personas Volver Agregar pedido Terminar reserva

pagar

Cliente Registrado

Terminar pedido pagar

pagar

Realizar Reserva

Elegir mesa Cliente no registrado Cantidad de personas Volver Volver Cancelar reserva Fecha Terminar reserva

Pagina inicio telefonista

Ver Reserva

Ingrese cliente Modificar Reserva

Pedido

Mesa

Pago efectivo

Finalizar
Confirmacin de transaccin volver

Delivery

Agregar platos y bebidas

Terminar pedido

Pago con tarjeta

Finalizar

Volver
Eliminar Cuenta Cerrar sesin

volver

43

Agregar pedido
Modificar pedido Eliminar pedido Volver

Elegir mesa
Mesero Cerrar sesin

44

Mesa Ocupada

Elegir mesa

Mesa Desocupada

Volver
Anfitrin Verificar Reserva Cerrar sesin Ingresar cliente Volver

45

Jefe de cocina

Ver lista de pedidos Cerrar sesin

46

Guardar Agregar ingredientes Volver Gestionar Ingredientes

Guardar Eliminar ingredientes

Volver
volver

Ver mesas

Volver

Administrador

Gestionar mesas

Guardar
Agregar mesa Volver Modificar mesas Guardar

Ver Clientes

volver

Quitar mesa Volver

Cerrar sesin

Figuras 2-7 a 2-13: Mapas de navegacin de las distintas vistas

47

2.8 MAPA DE PROCESOS ASOCIADO

Los diagramas de proceso muestran, a nivel grfico, las actividades que desarrollan las empresas para tener una mayor claridad acerca de los procesos internos de esta. Estos diagramas tienen una estructura definida y elementos bsicos grficos que sirven para ver qu actividad realiza cada elemento. Entre estos elementos grficos se encuentran: Crculo solitario: Este representa el inicio del proceso. Crculo doble concntrico: Representa el trmino o aborto de un proceso. Rectngulo: Representa una actividad realizada por un determinado actor. Rombo: Representa un cuestionamiento, para ver la ruta a seguir (Condicin). Etc...

A partir de esto, se realizan los diagramas de proceso mostrados a continuacin.

2.8.1 Proceso de reserva va web

El cliente hace ingreso a travs de su nombre de usuario y contrasea a la pgina web. En esta realiza el pedido de la reserva. En primer lugar, se le consulta si posee la cantidad mnima de comensales para realizar la reserva. En caso de que no se posea la cantidad requerida, se aborta el proceso. En caso de que si se tenga la cantidad mnima de comensales exigidos por el restaurant para reservar, se pregunta al cliente si desea reservar los platos de forma previa o bien, si quiere pedirlos en el mismo restaurant. Si el cliente decide no reservar los platos junto con la reserva, se le consulta si tiene los fondos suficientes para cancelar el mnimo requerido por el restaurant, o la totalidad de

48 la reserva. Si el cliente decide reservar los platos, estos los puede elegir en la misma pgina web. Se consulta al cliente si los platos que fueron elegidos, son correctos. Si no son correctos, debe seleccionar nuevamente los platos. Si son correctos, se pregunta al cliente si posee los fondos suficientes para pagar el mnimo requerido del restaurant, o la totalidad de la reserva. En caso de que no posea fondos, se aborta el proceso. En caso de que posea los fondos suficientes, el administrador le confirma al sistema que la cuenta es correcta. El sistema le enva la reserva al recepcionista. Se consulta si la reserva es con o sin platos. Si es sin platos, el recepcionista solo obtiene los datos de la realizacin de la reserva. Una vez llegado el da, el recepcionista atiende al cliente, y este le pide lo que desea del restaurant (Platos). El recepcionista toma ese pedido en el instante y a travs del sistema, enva esto a los administradores de cocina y bar. En caso de que la reserva sea con platos incluidos, el mesero recibe esta reserva y divide los slidos y los lquidos, enviando estos a los administradores de cocina y bar, respectivamente. Una vez tenida la reserva (para ambos casos), los administradores de cocina y bar, envan los platos y/o bebestibles al mesero, y este a su vez, hace el envo de los platos al cliente. El mesero pregunta si el cliente desea algo adicional. Si la respuesta es No, el cliente hace el pago del resto de la reserva (si as lo fuera) y finaliza el proceso. Si la respuesta es S, el mesero vuelve a hacer una recepcin de platos en el instante, enviando una nueva solicitud a los administradores de cocina y bar, formando un ciclo, hasta llegar a lo anterior.

2.8.2 Proceso de reserva va telefnica

El cliente realiza una reserva telefnica. Se le consulta si posee la cantidad mnima de comensales requeridos por el restaurant. Si la respuesta es No, se aborta el proceso. Si la respuesta es S, se pregunta si desea reservar los platos. Si la respuesta es No, se consulta al cliente si hizo un depsito previo del monto requerido por el

49 restaurant o por la totalidad del pedido. Si quiso reservar los platos, el cliente hace la eleccin de estos, mientras el administrador hace la recepcin de estos y son guardados por el sistema. Si los platos elegidos no son correctos, el cliente vuelve a elegir los platos pedidos. Si son correctos, se pregunta si el cliente hizo el depsito bancario. Para ambos casos (con o sin reserva de platos), si no existe depsito, se aborta el proceso. Si se hizo el depsito mnimo, se guarda la reserva y es aceptada por el sistema. Esta reserva es enviada al mesero, en donde ve si la reserva es con o sin platos. Si la reserva es sin platos, el cliente hace el pedido en cuanto llega al restaurant y el mesero los recepciona. Si la reserva es con platos, el mesero recibe la reserva con platos, la cual la divide en slidos y lquidos, y se los enva a los administradores de cocina y bar, respectivamente. Los administradores de cocina y bar, preparan los platos y/o bebestibles requeridos, y se los entregan al mesero. Este ltimo, hace la entrega del pedido al cliente, y este los recepciona. Luego se consulta al cliente si desea algo ms. Si la respuesta es No, el cliente paga el resto de la reserva (si as lo fuera) y se termina el proceso. Si la respuesta del cliente es Si, se hace nuevamente una recepcin de platos en el instante, con lo que esto conlleva.

2.8.3 Proceso de pedido en el restaurant

El proceso inicia cuando el mesero le consulta al cliente que desea. El cliente hace el pedido y el mesero hace la recepcin de los platos y/o bebestibles en el instante y se los enva al administrador de cocina y bar, respectivamente, y el sistema guarda el pedido. Los administradores de cocina y bar preparan los platos y bebestibles, respectivamente, y hacen el envo de estos al mesero, el cual los recibe. El mesero enva los platos y bebestibles al cliente. El mesero le consulta al cliente si desea algo ms. Si la respuesta del cliente es No, hace el pago del consumo y se termina el proceso. Si su

50 respuesta es S, se hace una nueva recepcin de platos y bebestibles en el instante, haciendo ciclos, detenindose cuando ya no desee nada ms.

2.8.4 Proceso de delivery

El cliente hace un pedido de delivery, ya sea va telefnica o por va web. El administrador le pide al cliente sus datos personales para adquirir el delivery. El cliente le indica al administrador cuales son los platos y los bebestibles que desea. El administrador recibe estos datos. El administrador vuelve a nombrarle los pedidos realizados y pregunta si estos estn correctos. Si la respuesta del cliente es No, le vuelve a indicar los pedidos al administrador. Si la respuesta es S, el administrador pregunta al cliente el tipo de pago a ocupar. Si el pago es a travs de transaccin bancaria, el administrador ve la confirmacin del pago del delivery y enva a los administradores de cocina y bar, lo pedido por el cliente. Los administradores envan el delivery al mesero. Si el pago es en efectivo, el administrador enva directamente a travs del sistema, los platos y/o bebestibles a los administradores de cocina y bar, respectivamente. Estos administradores, le envan el delivery al mesero y el delivery llega al cliente, el cual realiza el pago y el mesero lo recibe. Finalmente, tanto para pago en efectivo como para transaccin bancaria, el cliente recibe el delivery, finalizando el proceso.

2.9 MODELO DE NEGOCIO ASOCIADO

Un modelo de negocios consiste en ver de forma grfica, como es que el negocio generar ingresos o beneficios.

51 Adems, sirve para ver en que forma, la empresa llegar al cliente y la forma en que se genera una relacin empresa-Cliente. Los datos adquiridos para la creacin del modelo de negocios son los siguientes:

El mercado-meta del restaurant se enfoca principalmente en aquellos clientes que posean una situacin econmica de clase media y alta, ya que esta restringe los precios a ese mercado objetivo.

En el caso de la fidelizacin de los clientes, para mantenerlos, se otorga puntos canjeables por productos del restaurant a aquellos clientes que consuman en el restaurant.

Adems, se sistematiza el restaurant para que haya fluidez en la atencin, y as, la atencin se hace ms automatizada. En caso de que haya problemas con los platos, el restaurant asume toda la responsabilidad, condonando la deuda total de los platos y bebestibles pedidos por el cliente.

En el caso de la publicidad, este posee 3 grandes auspiciadores: CCU, CocaCola y Abastible. Para los casos de CCU y Coca-Cola, estas le dan al restaurant un cartel publicitario, un cooler, vasos con la marca y una llave de cerveza. Estos a cambio, exigen que sean vistas sus marcas y que sus productos salgan a la venta.

Para el caso de Abastible, ellos hacen la instalacin de gas dentro del establecimiento, a travs de bombas de gas. La clusula que piden ellos, es que la marca de Abastible, sea visible a los clientes.

Otros auspiciadores y proveedores son cerveceras pequeas que fabrican cervezas artesanales, que son el fuerte, en cuanto a bebestibles, del restaurant. Para atraer a los clientes, el restaurant hace publicidad mediante radios y diarios locales, en conjunto con redes sociales, tales como Facebook y Twitter, adems de la misma pgina del restaurant.

52 A partir de estos puntos, se disea el modelo de negocio, que es mostrado a continuacin.

Figura 2-14: Modelo de negocio de Casern Freire

53

CAPTULO 3. CONCLUSIONES

Se ha terminado la etapa de concepcin del proyecto alcanzando todos los objetivos planteados, es decir. Se levantaron los requerimientos fundamentales, los casos de uso esenciales, se estableci el alcance del proyecto. El establecer el alcance del proyecto es fundamental ya que gracias a este punto se determina lo que se pretende hacer y lo que no se pretende hacer dentro del proyecto a realizar. Es decir es un punto fundamental para que el proyecto no se transforme en una bola de nieve, tal que pasado un tiempo sea imposible de llevar a la prctica porque se acept un alcance mayor al que se poda realizar. Para entender el funcionamiento del negocio de hizo un modelo de negocios que pese a no cumplir con la notacin estricta de estos modelos, para los efectos del curso cumple con su cometido. Es decir permite entender los procesos asociados al funcionamiento de Casern Freire y gracias a este pre modelo de procesos de negocio fue posible realizar el pre modelo de datos. El pre modelo de datos como tal cumple tambin con su misin de dar a entender como modelo, la complejidad futura que tendr el problema, y pese a ser un pre modelo; est analizado en una profundidad tal que se acerca bastante al modelo buscado. Falta afinar algunos detalles que deben ser conversados con el profesores, tales como el manejo de las agendas que es un patrn nuevo para los alumnos que estn encarando este problemaEl mapa de navegacin tambin est en una construido satisfactoriamente (entendiendo que se est en la etapa de concepcin) el cual indicar la complejidad de la navegacin misma de la aplicacin, pero a su vez simplificar la el diseo futuro de la aplicacin y ms an la futura programacin de esta. En base a todo lo anterior el grupo consider los tiempos estimados de las actividades que llevarn a concretar este proyecto en la carta gantt. Sobre esta carta gantt se puede concluir en este instante que es una carta terica. Es decir los alumnos nunca han

54 construido una carta Gantt para un proyecto, y nunca han estimado tiempo para las actividades propias de un proyecto. Es por esto que se reconoce que es posible que no sea una herramienta precisa para estimar los tiempos del proyecto, pero por otro lado se espera que sea una herramienta, basada en la experiencia, bastante til para los alumnos para refinar sus habilidades necesarias de estimar tiempo de proyectos. Hecha esa salvedad tambin se concluye que la construccin de la carta gantt es satisfactoria. Por otro lado se concluye que el concebir un proyecto desde el paradigma informtico es una etapa a la cual poco tiempo se le dedica, por lo mismo a los alumnos de este proyecto les ha sido difcil apartarse del paradigma informtico y dedicarle tiempo a la etapa de concepcin, pero aun as se logr terminar esta etapa. De la experiencia adquirida del punto anterior tambin se concluye que la etapa de concepcin de un proyecto es una etapa compleja, tanto en tiempo (HH) como en desgaste intelectual, pero si est bien hecha; como lo espera el grupo, debera hacer ms fcil las siguientes etapas. Como conclusin final, el grupo espera las recomendaciones y correcciones del profesor para empezar a trabajar en la siguiente etapa y cumplir con los tiempos autoimpuestos como grupo.

55

CAPTULO 4. REFERENCIAS
Araujo, Y., & Lpez, H. (Mayo de 2010). Metodologa RUP. Recuperado el 18 de Abril de 2011, de Metodologa RUP: http://es.scribd.com/doc/31440864/MetodologiaRUP [1]

56

CAPTULO 5. ANEXOS

5.1 LAYOUT DE LA WEB DEL CLIENTE

Como previa a la elaboracin, se hace un diseo preliminar de lo que es el sitio de registro de los clientes. El primer layout, muestra el sitio de ingreso de los clientes, en el cual se muestra el cuadro ingresar, en el cual el cliente, si es registrado, debe ingresar su RUT y contrasea, para acceder a sus datos. Bajo esto, se tienen dos enlaces, uno es en caso de que como cliente registrado, haya olvidado su contrasea y desea recuperarla, y el segundo, que sirve para registrarse como cliente. Estos layout se avocan principalmente a este ltimo punto.

57

Figura 5-1: Layout del cliente: Ingresar

En el segundo layout, se muestra el formulario que debiese rellenar el cliente para que este cuente como cliente registrado del restaurant. Existen datos que sern obligatorios, si desea registrarse. Estos datos son indicados con un asterisco (*).

58

Figura 5-2: Layout del cliente: Datos de usuario

59 En el tercer layout, se muestra un mensaje, indicando que los datos del cliente han sido ingresados de forma exitosa, y adicionalmente, que recibir un mail de confirmacin, para que su cuenta se valide. Tambin se tiene el botn volver a la pgina de inicio, en la cual mostrar algo similar a lo de la figura 5-1.

Figura 5-3: Layout del cliente: Ingreso de solicitud de registro exitosa

En el cuarto layout, se muestra la ventana de recuperacin de contrasea, en donde se pide al cliente que ingrese la pregunta que escogi para recuperarla, con su respectiva respuesta.

60

Figura 5-4: Layout del cliente: Recuperacin de contrasea

5.2 LAYOUT DEL RESTAURANT

A continuacin, se muestran imgenes del interior del restaurant, para tener en cuenta, y ver as el diseo del sistema que se debe hacer.

61

Figura 5-5: Layout del restaurant

62

5.3 CARTA GANTT

La carta Gantt ser anexada como un archivo de Microsoft Project 2010, llamado Carta Gantt.mpp. Adicionalmente, se anexa el historial que se posee hasta el momento de la primera entrega. El nombre de este es Historial.mpp.

5.4 OTROS ANEXOS

Junto con los anexos anteriores, se adicionan los mapas de procesos, debido a que estos son demasiados grandes para imprimir en el informe. Uno de ellos se abre con BizAgi (BPM Delivery.bpm) y el otro con Power designer.