Sistema Web

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 114

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO

FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA

SISTEMA WEB DE PUBLICIDAD Y FIDELIZACIÓN


DE CLIENTES EN EL MERCADO DE
RESTAURANTES

JOSEFINA ANDREA ARAYA TAPIA


CRISTIAN ANDRÉS BASCUÑÁN LÓPEZ

INFORME FINAL DEL PROYECTO


PARA OPTAR AL TÍTULO PROFESIONAL DE
INGENIERO DE EJECUCIÓN EN INFORMÁTICA

DICIEMBRE DE 2013

I
PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA

SISTEMA WEB DE PUBLICIDAD Y FIDELIZACIÓN


DE CLIENTES EN EL MERCADO DE
RESTAURANTES

JOSEFINA ANDREA ARAYA TAPIA


CRISTIAN ANDRÉS BASCUÑÁN LÓPEZ

Profesor Guía: Pamela Hermosilla Monckton

Profesor Co-referente: Aldo Migliaro Osorio

Carrera: Ingeniería de Ejecución en Informática

DICIEMBRE DE 2013

II
Agradecimientos

Agradezco a mis padres, por el gran apoyo que me otorgaron a lo largo de toda mi
formación académica, sin su ayuda esto hubiera sido mucho más difícil. Agradezco a mis
hermanos y pareja por ser ese pilar fundamental en mi vida, los cuales me apoyaron tanto en
momentos difíciles como de alegría. A mis amigos que fueron ese apoyo incondicional a lo largo
de toda mi vida.

Agradezco a mis padres y hermana por su apoyo incondicional en mis grandes


decisiones personales, como lo fue la elección de estudiar esta carrera profesional, a mi
compañera y amiga con la cual desarrolle este proyecto y con la cual logramos unir fuertes
lazos de amistad, a mis amigos que fueron de gran ayuda en momentos difíciles con sus
palabras de aliento que ayudaron a sobreponerme a ellos. Dedico este proyecto a toda mi
familia, los quiero.

III
Resumen: Dentro del mercado gastronómico específicamente los restaurantes
emergentes, se ven afectados por diferentes problemáticas como lo es el captar, persuadir y
conservar a sus clientes. Es por esta razón que se crea el Sistema Web de Publicidad y
Fidelización de Clientes en el Mercado de Restaurantes, el cual es una herramienta que facilita
todo el trabajo que deben realizar las empresas en cuanto al concepto de publicidad y gestión
de clientes. El sistema da la posibilidad tanto al cliente como al administrador de interactuar
con el restaurante mediante los diferentes métodos de comunicación que ofrece éste. Dado al
crecimiento de las redes sociales tales como Facebook y su uso masivo, el sistema está
vinculado con dicha red social compartiendo publicaciones en el sitio y simultáneamente en la
red social.
Palabras Claves: Publicidad, Marketing, Fidelización, Restaurantes, Sistema Web,
Clientes, Redes Sociales.

Abstract: Within the food market specifically emerging restaurants, are affected
by different issues such as capture, convince and retain clients. It is for this reason that the
Web Advertising System and Customer Loyalty in the Market Restaurants is created, which is
a tool that makes all the work to be undertaken by companies on the concept of advertising
and management of clients. The system gives the possibility of both the client and the
administrator interacts with the restaurant by the different methods of communication that it
offers. Given the growth of social networks such as Facebook and massive use, the system is
linked to that network sharing site and postings on the social network simultaneously.
Keywords: Advertising, Marketing, Loyalty, Restaurants, Web System, Client, Social
Networks.

IV
Índice

Agradecimientos ................................................................................................................... III


Índice ..................................................................................................................................... V
Índice de Figuras ..................................................................................................................IX
Índice de Tablas ..................................................................................................................... X
Introducción ............................................................................................................................ 1
Capítulo 1 Estado del Arte ............................................................................................... 2
1.1 Antecedentes Generales ............................................................................................ 2
1.2 Fidelización de Clientes ............................................................................................ 2
1.3 Programas de Fidelización ........................................................................................ 2
1.4 Publicidad .................................................................................................................. 3
1.5 Problemas Identificados ............................................................................................ 4
Capítulo 2 Definición del Alcance del Solución .............................................................. 6
2.1 Antecedentes Generales del Cliente .......................................................................... 6
2.2 Justificación del Proyecto.......................................................................................... 6
2.3 Objetivos del Proyecto .............................................................................................. 7
2.3.1 Objetivo General ................................................................................................ 7
2.3.2 Objetivos Específicos ........................................................................................ 7
2.4 Descripción General de la Solución .......................................................................... 8
Capítulo 3 Detalle de la Solución .................................................................................... 9
3.1 Elección de Metodología ........................................................................................... 9
3.2 Elección de Paradigma .............................................................................................. 9
3.3 Herramientas Seleccionadas para el Desarrollo ........................................................ 9
3.3.1 Herramienta de Modelado ................................................................................. 9
3.3.2 Lenguaje de Programación .............................................................................. 10
3.3.3 Motor de Base de Datos ................................................................................... 10
3.3.4 Entornos de Desarrollo .................................................................................... 10
3.4 Arquitectura del Sistema ......................................................................................... 10
3.4.1 Arquitectura Lógica ......................................................................................... 10
3.4.2 Arquitectura Física ........................................................................................... 11
Capítulo 4 Estudio de Factibilidad ................................................................................. 12
4.1 Factibilidad Operativa ............................................................................................. 12
4.2 Factibilidad Técnica ................................................................................................ 12

V
4.3 Factibilidad Económica ........................................................................................... 12
4.4 Factibilidad Legal .................................................................................................... 12
Capítulo 5 Gestión de Riesgos ....................................................................................... 13
Capítulo 6 Desarrollo del Sistema ................................................................................. 14
6.1 Identificación de los Requerimientos ...................................................................... 14
6.1.1 Requerimientos Funcionales ............................................................................ 14
6.1.2 Requerimientos No Funcionales ...................................................................... 16
6.2 Análisis .................................................................................................................... 18
6.2.1 Actores del Sistema ......................................................................................... 18
6.2.2 Caso de Uso General ........................................................................................ 19
6.3 Diseño...................................................................................................................... 20
6.3.1 Diagramas de Secuencia .................................................................................. 20
6.3.2 Modelo de Clases ............................................................................................. 21
6.3.3 Modelo Relacional de Datos ............................................................................ 22
Capítulo 7 Implementación ............................................................................................ 23
7.1 Organización de la Implementación del Proyecto................................................... 23
7.2 Interfaces del Sistema.............................................................................................. 24
Capítulo 8 Pruebas de Usabilidad .................................................................................. 27
Capítulo 9 Conclusión.................................................................................................... 28
Capítulo 10 Referencias ................................................................................................... 29
Anexos .................................................................................................................................. 30
Anexo A. Detalles de la Solución ................................................................................. 30
Proceso Unificado ......................................................................................................... 30
Paradigma de Análisis Orientado a Objetos .................................................................. 32
Herramienta de Modelado ............................................................................................. 33
Lenguaje de Programación ............................................................................................ 34
Motor de Base de Datos ................................................................................................ 35
Anexo B. Arquitectura del Sistema .............................................................................. 37
Arquitectura Lógica ...................................................................................................... 37
Arquitectura Física ........................................................................................................ 38
Anexo C. Estudio de Factibilidad ................................................................................. 40
Factibilidad Operativa ................................................................................................... 40
Factibilidad Técnica ...................................................................................................... 41
Hardware ....................................................................................................................... 41

VI
Software ........................................................................................................................ 41
Recursos Humanos ........................................................................................................ 41
Factibilidad Económica ................................................................................................. 42
Estimación de gastos del Sistema Actual ...................................................................... 42
Valoración Económica del Proyecto ............................................................................. 43
Justificación Económica ................................................................................................ 44
Factibilidad Legal.......................................................................................................... 45
Anexo D. Gestión de Riesgos ....................................................................................... 46
Identificación de Riegos ................................................................................................ 46
Estimación de la Probabilidad ....................................................................................... 47
Estimación del Impacto ................................................................................................. 49
Exposición al Riesgo ..................................................................................................... 50
Líneas de Acción ........................................................................................................... 51
Plan de Acción de Riegos ............................................................................................. 51
Plan de Contingencia ..................................................................................................... 53
Anexo E. Planificación ................................................................................................. 55
Iteraciones de Proceso Unificado .................................................................................. 55
Anexo F. Casos de Uso ................................................................................................ 57
Caso de Uso General ..................................................................................................... 57
Caso de uso Gestionar Carta Online ............................................................................. 58
Caso de Uso Gestionar Clientes .................................................................................... 59
Caso de Uso Gestionar Publicidad ................................................................................ 60
Caso de Uso Editar Perfil .............................................................................................. 61
Caso de Uso Agregar Venta .......................................................................................... 62
Caso de Uso Gestionar Comentarios............................................................................. 63
Caso de Uso Ver Reportes ............................................................................................ 64
Caso de Uso Gestionar Venta ....................................................................................... 65
Anexo G. Diseño........................................................................................................... 66
Diagramas de Secuencia ............................................................................................... 66
Diccionario de Datos ..................................................................................................... 82
Anexo H. Pruebas de Usabilidad .................................................................................. 87
Objetivo de la Prueba .................................................................................................... 87
Diseño de la Prueba ....................................................................................................... 87
Selección de participantes ............................................................................................. 88

VII
Análisis de Resultados .................................................................................................. 88
Anexo I. Manual de Usuarios ...................................................................................... 89
Sistema Público - Sin Usuarios Registrados ................................................................. 89
Sistema Perfil Administrador ........................................................................................ 94
Sistema Perfil Súper Administrador............................................................................ 100
Sistema Perfil Cliente Registrado ............................................................................... 103

VIII
Índice de Figuras

Figura 2.4.1: Esquema Explicativo del Sistema. .................................................................... 8


Figura 3.4.1: Esquema de Arquitectura Lógica .................................................................... 11
Figura 6.2.1: Actores del Sistema......................................................................................... 18
Figura 6.2.2: Caso de Uso General. ...................................................................................... 19
Figura 6.3.1: Diagrama de Secuencia Ver Reportes. ............................................................ 20
Figura 6.3.2: Modelo de Clases del Sistema. ....................................................................... 21
Figura 6.3.3: Modelo Relacional de Datos. .......................................................................... 22
Figura 7.1.1: NetBeans luego de Crear el Proyecto. ............................................................ 23
Figura 7.2.1: Layout. ............................................................................................................ 24
Figura 7.2.2: Panel Administrador. ...................................................................................... 25
Figura 7.2.3: Página Publicaciones. ..................................................................................... 25
Figura 7.2.4: Agregar Venta. ................................................................................................ 26
Figura A.1 Proceso Unificado. ............................................................................................. 30
Figura B.1: Diagrama de Arquitectura Lógica. .................................................................... 37
Figura B.2: Arquitectura Física del Sistema. ........................................................................ 39
Figura F.1: Caso de Uso General.......................................................................................... 57
Figura F.2: Caso de Uso Gestionar Carta Online. ................................................................ 58
Figura F.3: Caso de Uso Gestionar Clientes. ....................................................................... 59
Figura F.4: Caso de Uso Gestionar Publicidad. ................................................................... 60
Figura F.5: Caso de Uso Editar Perfil. ................................................................................. 61
Figura F.6: Caso de Uso Agregar Venta............................................................................... 62
Figura F.7: Caso de Uso Gestionar Comentarios. ................................................................ 63
Figura F.8: Caso de Uso Ver Reportes. ................................................................................ 64
Figura F.9: Caso de Uso Gestionar Venta. ........................................................................... 65
Figura G.1: Diagrama de Secuencia “Agregar Cliente”. ...................................................... 66
Figura G.2: Diagrama de Secuencia “Agregar Cliente”. ...................................................... 66
Figura G.3: Diagrama de Secuencia “Editar Perfil”. ............................................................ 67
Figura G.4: Diagrama de Secuencia “Ingresar Producto”. ................................................... 68
Figura G.5: Diagrama de Secuencia “Ver Reportes”. .......................................................... 69
Figura G.6: Diagrama de Secuencia “Ver Notificaciones Comentarios”. ............................ 70
Figura G.7: Diagrama de Secuencia “Agregar Venta”. ........................................................ 71
Figura G.8: Diagrama de Secuencia “Compartir en Redes Sociales”. ................................. 72
Figura G.9: Diagrama de Secuencia “Editar Cliente”. ......................................................... 73
Figura G.10: Diagrama de Secuencia “Editar Publicidad”................................................... 74
Figura G.11: Diagrama de Secuencia “Eliminar Producto”. ................................................ 75
Figura G.12: Diagrama de secuencia “Eliminar Cliente”..................................................... 76
Figura G.13: Diagrama de Secuencia “Eliminar Publicidad”. ............................................. 77
Figura G.14: Diagrama de Secuencia “Ingresar Publicidad”. .............................................. 78
Figura G.15: Diagrama de Secuencia “Hacer Comentario”. ................................................ 79
Figura G.16: Diagrama de Secuencia “Ver Comentarios”. .................................................. 80
Figura G.17: Diagrama de Secuencia “Ver Notificación Reservas”. ................................... 81

IX
Índice de Tablas

Tabla 5.1.1: Riesgos Identificados. ...................................................................................... 13


Tabla 6.1.1: Requerimientos Cliente. ................................................................................... 14
Tabla 6.1.2: Requerimientos Administrador. ....................................................................... 15
Tabla 6.1.3: Requerimientos Sistema. .................................................................................. 16
Tabla A.1: Lenguaje de Programación. ................................................................................ 35
Tabla A.2: Comparación Motores de Base de Datos............................................................ 36
Tabla C.1: Estimación de Gastos Actuales Hechos por la Empresa. ................................... 42
Tabla C.2: Gastos Estimados por Etapa de Desarrollo. ........................................................ 43
Tabla C.3: Costos de Material. ............................................................................................. 44
Tabla C.4: Resumen de Costos de Proyecto. ........................................................................ 44
Tabla D.1: Riesgos Identificados. ........................................................................................ 47
Tabla D.2: Tabla de Estimación de Probabilidad. ................................................................ 47
Tabla D.3: Probabilidad de Riesgos. .................................................................................... 48
Tabla D.4: Estimación del Impacto. ..................................................................................... 49
Tabla D.5: Riegos y su Impacto. .......................................................................................... 50
Tabla D.6: Tabla de Exposición de los Riegos. .................................................................... 50
Tabla D.7: Definición de Planes de Acción para Riesgos Definidos. .................................. 51
Tabla D.8: Definición de Plan de Contingencia Para los Riesgos Definidos ....................... 53
Tabla G.1: Diccionario de Datos Tabla Carta_productos..................................................... 82
Tabla G.2: Diccionario de Datos Tabla Comentarios. ......................................................... 82
Tabla G.3: Diccionario de Datos Tabla Publicaciones. ........................................................ 83
Tabla G.4: Diccionario de Datos Tabla Reservas................................................................. 83
Tabla G.5: Diccionario de Datos Tabla Estado_reserva....................................................... 84
Tabla G.6: Diccionario de Datos Tabla Tipo_publicacion. .................................................. 84
Tabla G.7: Diccionario de Datos Tabla Tipo_productos. ..................................................... 84
Tabla G.8: Diccionario de Datos Tabla Rel_carta_ventas. .................................................. 85
Tabla G.9: Diccionario de Datos de Tabla Ventas. .............................................................. 85
Tabla G.10: Diccionario de Datos de Tabla Usuarios. ......................................................... 86

X
Introducción
En la actualidad de nuestro país el rubro gastronómico, específicamente el área de los
restaurantes, ha tenido un crecimiento exponencialmente acelerado, aumentando tanto en
cantidad como en diversidad. Esto, si bien es un símbolo de que la económica va
evolucionando, sobre todo para las pequeñas empresas, también trae con si un abanico de
problemas, como son el aumento de la oferta sobre el crecimiento más pausado de la demanda
dentro del rubro. También es un problema que enfrenta el rubro gastronómico, el fuerte
crecimiento de los locales de comida rápida, mucha gente prefiere ir a estos locales ya que se
ahorran el tiempo de espera, tiempo que cada día es más privilegiado para otras cosas por los
consumidores.
Si bien los restaurantes se ven enfrentados a este abanico de problemas, todo se puede
resumir al problema de captación de clientes. Cada restaurante busca captar nuevos clientes y
a la vez retener a los ya existentes. Si el restaurante posee una clientela fiel y creciente, se
puede decir que su rentabilidad se ve favorecida, lo que también es sinónimo de que se ofrece
un buen servicio y que los clientes están satisfechos con él. Es por esta razón que se ve la
necesidad de focalizarse en el concepto de “fidelización de clientes”. Este concepto se refiere a
actividades o tareas que se deben realizar para captar la atención del cliente y hacerlo volver a
que consuma el servicio o producto que se le ofrece.
Es por esto que se ha decidido desarrollar un sistema software que abarque esta
problemática, es decir, que se encargue de todo lo referente a marketing, publicidad y gestión
de clientes, todo esto enfocado a restaurantes emergentes pequeños que se vean enfrentados a
la realidad competitiva del mercado gastronómico nacional. Para poder realizar un verdadero
análisis del estado del arte, se estudiaron programas softwares actuales de fidelización tanto en
Chile como en el extranjero como son: Partner Restaurant1, SoftRestaurant2, Grand-Gour-
Net3, entre otros. En la actualidad existen diferentes técnicas con las que se pueden
implementar dichos softwares, técnicas que serán explicadas detalladamente.
Cabe destacar que dicho software será desarrollado para un cliente real, cuyo nombre
es restaurante Capicua Restobar. Se desarrollara el software en base a los requerimientos de
dicho cliente, pero será implementado pensando siempre en que será una aplicación genérica,
es decir, que pueda ser utilizado por cualquier restaurante emergente pequeño que requiera
captar nuevos clientes y fortalecer los lazos con los actuales.

1
Página Web http://www.partnerrestorant.cl/ - Empresa Lógica Web, Providencia – Santiago.
2
Página Web http://www.cbiz.cl/ - CBIZ S.A. es distribuidor oficial de SoftRestaurant en Chile
3
Página Web http://www.gour-net.cl/grand.html - Empresa Gout-Net, Providencia-Santiago

1
Capítulo 1 Estado del Arte
1.1 Antecedentes Generales

En nuestro país siempre se ha tenido la costumbre de comer de tres a cuatro comidas


diarias, desayuno, almuerzo, once y cena, siendo el almuerzo y cena las comidas más
importantes, para el común de la gente. La vida diaria de las personas desde hace un tiempo se
viene dando muy agitada y ocupada, lo que conlleva una disminución en el tiempo destinados
históricamente para los quehaceres del hogar, como en este caso, el cocinar, es por este motivo
que la gran mayoría de las personas decide ir a un recinto para consumir sus alimentos de
forma rápida y sencilla a cambio de un desembolso económico. En resumen se podría decir
que la gente visita los restaurantes por la comodidad y rapidez, siempre considerando los
gustos y preferencias de cada individuo.

1.2 Fidelización de Clientes

El fidelización o lealtad de los clientes se utiliza para describir el comportamiento de


los clientes que vuelven, describe también la tendencia de que un cliente elija un negocio o
producto sobre otro para una necesidad en particular. Los clientes pueden expresar altos
niveles de satisfacción con una empresa en una encuesta, pero la satisfacción no es lo mismo
que la lealtad. La lealtad se demuestra por las acciones del cliente, los clientes pueden estar
muy satisfechos y aun así no ser leal.
La lealtad del cliente se ha convertido en un término común y efectivo para el
resultado final de muchas estrategias de marketing donde los datos de los clientes se
utilizan. Es un proceso, un programa o un conjunto de programas dirigidos a mantener un
cliente satisfecho para que él regrese y así contribuir a una mejor rentabilidad. La lealtad del
cliente es el resultado de una buena gestión de programas de retención de clientes, los clientes
que son el objetivo de un programa de retención demuestran una mayor fidelidad a una
empresa. Todos los programas de retención de clientes se basan en la comunicación con los
clientes, dándoles ánimo para mantenerse activo y la elección continua del servicio.

1.3 Programas de Fidelización

Los Programas de fidelización de clientes son iniciados por las empresas con dos
objetivos principales, la adquisición de la información relativa a los hábitos de consumo de sus
clientes, y cultivar activamente la lealtad entre los clientes para asegurarse de que continuarán
participando del negocio.

2
Existen varios programas de fidelización, como por ejemplo:
ƒ Cupones de descuento: Practica consistente en el que el propio cliente pueda recortar
un cupón, ya sea desde folletos de publicidad o internet, y obtendrá el artículo más
barato en la tienda asociada.
ƒ Puntos por compra: se obtienen beneficios en tiempo real, lo que fomenta la actividad
de los internautas, ya que los puntos se van acumulando en la cuenta personal de forma
inmediata.
ƒ Venta cruzada: Conocida como venta asociada, consistente en proponer con motivo de
una oferta, productos que puedan ser vistos como complementarios para el cliente en el
momento de comprar uno de ellos.
ƒ Descuentos: Consiste en la reducción del precio de un producto para fomentar la
compra del mismo.
ƒ CRM: Apoyo tecnológico de fidelización de clientes, permite a las empresas analizar y
utilizar toda su información relevante sobre sus clientes a lo largo de la relación
comercial entre ambos.
ƒ Club de clientes: consiste en un club en donde se establece una serie de vínculos entre
la empresa y el cliente, así como un diálogo natural y permanente.

1.4 Publicidad
La Publicidad es una técnica de comunicación comercial que tiene como objetivo el
incentivar al individuo receptor de esta, al consumo de productos y servicios determinados, a
través de los medios de comunicación. La publicidad se puede agrupar según los medios de
comunicación que utilizan para llegar a su público objetivo. La publicidad llega a los
consumidores a través de diversos medios de comunicación, estos medios emiten la
propaganda a cambio de una contraprestación por lo general en dinero, es por esto que las
empresas que deseen realizar publicidad sea cual sea el medio, deben desembolsar una gran
suma de dinero. Existen diferentes tipos de publicidad dependiendo del objetivo que se
busque:
ƒ Publicidad Primaria: Busca mantener las demandas del producto, no trata que el
producto se haga conocido, porque ya lo es, sino que dar en claro que el producto está
vigente.
ƒ Publicidad de Marca: Interviene cuando el posicionamiento ya está realizado, y la
empresa quiere atraer a más consumidores del bien o producto que ofrece y asegurar su
demanda.
ƒ Publicidad de Lanzamiento: Su objetivo es influir en los consumidores, mostrando lo
bueno de sus productos. busca crear expectación en la gente, para que por curiosidad
pruebe lo que se les ofrece.
ƒ Publicidad de Imagen: Este tipo de publicidad está relacionada con las relaciones
públicas, y su fin es crear y mantener su prestigio comercial. dentro de esto cabe
cuando muestran las acciones buenas (o buenas obras) que realizan a favor de su
entorno social cercano, obras de beneficencia, etc.
Los canales o medios que se utilizan para transmitir el mensaje publicitario, son los
medios de comunicación masivos como televisión, radio, televisión y medios escritos. En la

3
actualidad el medio que toma cada vez mayor importancia es el Internet. La publicidad en
internet tiene como principal herramienta la página web y el contenido de esta. Internet ofrece
diferentes mecanismos para realizar publicidad como lo son, textos, enlaces, banner, blog,
logo, anuncios, audio, video, animación, imágenes, y siempre teniendo como finalidad dar a
conocer el producto o servicio al consumidor que está en línea por medio de dichos formatos.

1.5 Problemas Identificados

Algunos problemas que se pueden observar son:


ƒ El inevitable y potencial crecimiento de la oferta en el mercado. Cada día aparecen más
restaurantes y de distintas líneas gastronómicas, también se ven afectados los
restaurantes tradicionales por la masiva aparición de patios de comida rápida, que hoy en
día son elegidos por una gran cantidad de personas.
ƒ Cantidad de restaurantes que ofrecen distintos tipos de comidas hoy en el país es mucha.
Cada día aparecen locales con nuevas alternativas innovadoras para comer que son bien
aceptadas por un gran número de personas.
ƒ Poca o nula interacción del cliente para con el restaurante. Esto es, casi no existe algún
mecanismo de comunicación más personalizado por parte del restaurante hacia el cliente
para así tomar en consideración el parecer de él para ayudar a mejorar el servicio.
ƒ Deben recurrir a empresas externas para poder hacer publicidad y promocionar sus
ofertas, esto implica un gasto significativo por parte del restaurante que podría ser
utilizado en mejorar su servicio para así dejar más satisfechos a sus clientes.
ƒ Tiempos de espera extensos. Las personas hoy en día uno de los recursos que más
valoran y aprecian es el tiempo, es por esto que es muy importante el tiempo que deben
esperar a ser atendidos en el restaurante, tiempos en que demora la toma del pedido
hasta que la comida llegue a la mesa.
ƒ Manejo de propinas. Si bien no es algo obligatorio, existen restaurantes que obligan al
cliente a pagar el 10% de propina incluyéndolo en el total de la boleta. Lo que se puede
considerar como algo ilegal. Con respecto a esto Marcelo Miranda4 explico que la Ley
N° 7.388 de 1942 fijaba como porcentaje histórico como propina el 10% obligatorio. No
obstante, a partir del 14 de Agosto de 1981 esto fue derogado por la Ley N° 18.018, por
tanto en la actualidad la legislación chilena es clara al respecto: no existe la propina legal
u obligatoria del 10% de lo consumido en un restaurante.
ƒ Disponibilidad de estacionamientos. En muchos casos los clientes deben utilizar
estacionamientos privados lo que significa que deben considerar un costo adicional al
consumido en el restaurante. Esto se debe a que la mayoría de los restaurantes no cuenta
con estacionamientos propios. Problema que se ve más en fechas importantes en donde
la concurrencia a los recintos es mayor.
ƒ Falta de ofertas y descuentos para clientes nuevos. La mayoría de los restaurantes
focaliza sus ofertas y promociones a clientes concurrentes pero no realizan ofertas y
promociones a clientes nuevos para así captar mayor cantidad de clientes.

4
Marcelo Miranda, Abogado Servicio Nacional del Consumidor, Chile.

4
ƒ Poca claridad en ofertas de clientes frecuentes. (sistemas de puntos, tarjetas etc.). La
mayoría de las personas que participa en sistemas de acumulación de puntos o cualquier
otra sistema de Fidelización de clientes no tiene muy claro cómo funcionan, por falta de
información al usuario.
Como es de común conocimiento la tecnología y sus avances han llegado a solucionar
diversos problemas, automatizando diversas tareas que antes se debían realizar de forma
manual y demorosa. El mercado gastronómico no ha estado ajeno a esta evolución
tecnológica. Durante el último tiempo los mercados gastronómicos han tenido que adaptarse a
la tecnología para poder administrar sus locales, los cuales han optado por distintos tipos de
software dependiendo de los requerimientos de cada empresa y/o local.

5
Capítulo 2 Definición del Alcance del Solución

2.1 Antecedentes Generales del Cliente

El sistema será desarrollado en un principio para un cliente especifico, pero siempre


pensando en que puede ser aplicable de forma genérica a cualquier restaurante que cumpla con
características similares, es decir, a restaurantes emergentes y que desean potencializar la
fidelidad de sus clientes y la publicidad de su negocio. El presente sistema será desarrollado
para el restaurante “Capicúa Restobar”, el cual es un pequeño restaurante ubicado en 12 Norte
con 5 Oriente, Viña del Mar. La especialidad en comidas son las colaciones, menús diarios,
sándwich, empanadas, entre muchas otras. En cuanto a bebidas la especialidad del restaurante
son las cervezas de distintos tipos, como también jugos y bebidas gaseosas. El perfil de la
clientela se trata de un cliente frecuente, trabajadores que pertenecen al perímetro del
restaurante. También es un lugar de encuentro para celebraciones de tipo cumpleaños o
eventos privados, como también celebración de partidos de futbol entre otros.
Se espera que el público consumidor varíe un poco en un futuro próximo, debido a un
potencial crecimiento educacional del sector en el cual está ubicado dicho restaurante, en los
próximos meses se inauguraran diversas universidades que atraerán público nuevo al
restaurante. Es a este tipo de público al que hay que atraer con ofertas y promociones, además
se sabe que a nivel nacional como internacional los estudiantes universitarios son los que
tienen mayor acceso a internet en estos días.
Si bien el sistema a desarrollar esta debidamente acotado en cuanto a requerimientos
por parte del cliente, en el presente caso, como el sistema debe hacer uso una página web del
restaurante, lo que se espera como requerimiento para poder implantar el sistema. Se deberá
diseñar nuevamente el sitio web actual del restaurante para poder cumplir con todo lo
necesario para poder llevar a cabo de buena manera e l sistema a desarrollar.

2.2 Justificación del Proyecto

Debido a la gran cantidad de problemas que se han podido descubrir dentro del rubro
gastronómico, se ha tomado la decisión de desarrollar un producto software que abarque una
serie de soluciones a problemas como son:
ƒ El potencial crecimiento de la oferta en el mercado. Lo que conlleva como consecuencia
mayor competencia entre los restaurantes para captar mayor cantidad de clientes.
ƒ La casi inexistente interacción del cliente con el restaurante. Esto es que en la mayoría
de los casos no existe un sistema práctico y cómodo para que el cliente pueda expresar
sus opiniones sobre el restaurante.
ƒ Los restaurantes deben acudir a empresas externas para promocionar su negocio. Esto
implica un gasto de dinero que podría ser utilizado en mejorar la calidad del servicio
ofrecido.

6
ƒ Falta de ofertas y descuentos para clientes nuevos. Las ofertas y descuentos son muy
eficientes para la captación de nuevos clientes lo que conlleva a un movimiento de fluyo
mayor en la asistencia al restaurante.
ƒ Poca claridad en el sistema de fidelización. Por lo general las personas que están
asociadas a un programa de fidelización no tienen mucha claridad de cómo funciona o
utiliza, lo que tiene como consecuencia el no cumplimento del fin o meta por el cual fue
creado.

Como ya se nombró anteriormente se ha decidido desarrollar un software que sea una


ayuda al mercado gastronómico emergente nacional, de modo de incentivar a clientes nuevos
y frecuentes a visitar el restaurante nuevamente. Esto se conoce con nombre de captación y
fidelización de clientes. Como se explicó inicialmente existen diferentes mecanismos para
manejar y trabajar la fidelización de los clientes frente a la empresa, en este caso, restaurantes.
Se ha decidido utilizar 3 de estas técnicas como son: Cupones de Descuentos, Descuentos y
Puntos por compras. Se trabajara con estas 3 técnicas ya que son las más fáciles de
implementar desde el punto de vista de un restaurante emergente pequeño. No requieren de un
gran sacrificio económico por parte de la empresa y son bien recibidos por los clientes, en
otras palabras, son fáciles de comprender y usar. En cuanto a la publicidad, de la clasificación
que se dio anteriormente, el proyecto hará uso de 2 tipo de publicidad, de Marca y de
Lanzamiento, y el medio a utilizar será Internet, ya que el sistema constara de su propio sitio
web, y también constara con perfiles en redes sociales, medios por los cuales se masifica la
publicidad por medio de internet.

2.3 Objetivos del Proyecto

A continuación se dan a conocer los objetivos tanto generales como específicos del
proyecto a desarrollar.

2.3.1 Objetivo General

Desarrollar un sistema informático de publicidad y fidelización de clientes, para


empresas emergentes dentro del mercado gastronómico, específicamente a los restaurantes.

2.3.2 Objetivos Específicos

Se tiene como objetivos específicos cumplir con las siguientes metas esperadas:
ƒ Estudiar y analizar el mercado de los restaurantes nacionales con el objetivo de
encontrar problemáticas que afectan al rubro.

7
ƒ Analizar diversos software que actualmente operen en los restaurantes nacionales e
internacionales.
ƒ Estudiar diversas herramientas con las cuales se va a desarrollar el software.
ƒ Investigar y analizar diversas alternativas de programas de fidelización.
ƒ Implementar el sistema software, aplicando las especificaciones requeridas por el
cliente.

2.4 Descripción General de la Solución

Figura 2.4.1: Esquema Explicativo del Sistema.

En la Figura 2.1.4.1 se puede observar una explicación del sistema a desarrollar. Los
clientes frecuentes son clientes ya registrados en el sistema, cuando éstos realizan una compra
en el restaurante, ésta es registrada por algún administrativo en el restaurante y además los
clientes reciben beneficios por su fidelidad. Estos registros son almacenados por el sistema
para luego ser utilizados para generar reportes. El sistema ofrecerá distintos servicios como es,
reservas, ver noticias, registrarse, editar perfil de clientes, etc.

8
Capítulo 3 Detalle de la Solución
3.1 Elección de Metodología

Para la implementación del este proyecto se ha tomado la decisión de seleccionar la


Metodología de Proceso Unificado, dicha decisión se justifica por las siguientes razones,
debido a que no existe un proyecto igual a otro, se eligió esta metodología , ya que es el que
aporta mayor flexibilidad en cuando a adaptarse a distintos tipos y tamaños de proyectos. Este
método posee una etapa denominada “Modelado del negocio” es en esta en donde se debe
realizar toda la investigación del estado del arte del tema a desarrollar, con el objetivo de
aportar una base de conocimiento del tema en el cual se va a trabajar. Otro factor muy
importante a la hora de definir este paradigma, es la posibilidad de realizar n cantidad de
iteraciones por cada etapa, permitiendo modificar o mejor dicho corregir errores anteriores y
nuevos requerimientos, en cada una de sus partes (análisis, diseño, implementación, etc.). UP
también permite fragmentar el trabajo, lo que permite un desarrollo por módulos. Para
profundizar más en cuanto a definición de proceso unificado ver Anexo A Detalle de la
Solución.

3.2 Elección de Paradigma

En cuanto a la elección del paradigma se ha decidido trabajar con orientado a objetos,


ya que se adecua al mundo real y responde a las necesidades de flexibilidad y evoluciones que
pueda sufrir a futuro el sistema software. Las técnicas orientadas a objetos permiten que el
software se construya a partir de objetos con comportamiento específico, y esta es una de las
características claves para poder desarrollar el software lo más cercano a la realidad. Para
profundizar más en cuanto a definición de este paradigma ver Anexo A Detalle de la Solución.

3.3 Herramientas Seleccionadas para el Desarrollo

3.3.1 Herramienta de Modelado

El Lenguaje Unificado de Modelado se ha vuelto el lenguaje de modelado estándar


usado en análisis y diseño orientado a objetos, describe la semántica esencial de lo que estos
diagramas y símbolos significan. Este lenguaje se caracteriza por su simpleza y fácil
comprensión tanto por programadores, analistas como para los clientes. Es por esta razón que
se determinó trabajar con esta herramienta de modelado. Para profundizar más en cuanto a
definición de UML ver Anexo A Detalle de la Solución.

9
3.3.2 Lenguaje de Programación

PHP5, es un lenguaje interpretado de alto nivel, fácil de aprender, es muy similar a C,


java, Perl, pensado para el desarrollo Web, que permite eliminar limitaciones existentes en
páginas HTML, brindando paginas dinámicas. Es por estas razones que se ha decidido optar
por esta herramienta para el desarrollo del presente sistema. Para profundizar más en cuanto al
lenguaje de programación seleccionado ver Anexo A Detalle de la Solución.

3.3.3 Motor de Base de Datos

MySQL es una base de datos que con el tiempo y sus asociaciones comerciales, ha
ido creciendo e integrando cualidades para ser una base de datos potente y que cumple con
todas las características para el desarrollo del sistema a desarrollar, es por esto que se ha
decidido utilizar MySQL como motor de base de datos. Para mayor información sobre el
motor de base de datos seleccionado ver Anexo A Detalle de la Solución.

3.3.4 Entornos de Desarrollo

Para la etapa de diseño se utilizó la herramienta MySQL Workbench, este software es


una herramienta visual de diseño de base de datos, permite crear tablas de forma más simple y
generando el código SQL respectivo, también se utiliza el software Navicat for MySQL
(versión trial), que es un administrador de base de datos, este permite manipular los datos
almacenados de forma más practica desde el punto de vista de los desarrolladores.
Se realizó una búsqueda de herramientas para la implementación de Php5 en un IDE
o Framework, como conclusión de dicha búsqueda se determinó trabajar con Zend
Framework, el cual es un Framework de código abierto para desarrollar aplicaciones web y
servicios web con PHP 5 orientado a objetos. Se utilizó un Virtual host para trabajar, y se
utiliza NetBeans, el cual es un entorno de desarrollo de software integrado y libre.
Es impórtate decir que los desarrolladores del presente sistema trabajan con una
modalidad de subversión, esto significa que al trabajar en línea, cada desarrollador al realizar
una copia del archivos a utilizar, lo bloquea, pera que otro no pueda acceder, así evitar
problemas de conflictos.

3.4 Arquitectura del Sistema


3.4.1 Arquitectura Lógica

Actualmente la arquitectura lógica sigue un esquema básico formado por 3 capas


primarias. Es esta la arquitectura que se ha elegido para la implementación del sistema a
desarrollar.

10
Estas 3 capas son:
ƒ Interfaz.
ƒ Lógica de dominio (de negocio).
ƒ Fuente de datos (capa de datos).

Figura 3.4.1: Esquema de Arquitectura Lógica

La Figura 3.4.1 es una explicación grafica de cómo está constituida la Arquitectura


Lógica de 3 capas del presente proyecto, se puede ver cómo interactúan la capa de
presentación. (HTML), con la capa Lógica (PHP5) y la capa de Dato (MySQL).

3.4.2 Arquitectura Física

En este apartado se especifica la división física del sistema identificando los nodos y
las comunicaciones entre nodos. Se entiende por nodo cada partición física o parte
significativa del sistema de información con características propias de ejecución y función, e
incluso de diseño y construcción. La arquitectura física del sistema debe permitir organizar
de forma distribuida el sistema, estableciendo una arquitectura multinivel cliente/servidor, en
la cual, los múltiples clientes realizan peticiones al servidor, y el servidor responde a esas
solicitudes.
Para mayor información sobre el tipo de arquitecturas empleadas en el presente
proyecto ver Anexo B Arquitectura del Sistema.

11
Capítulo 4 Estudio de Factibilidad

4.1 Factibilidad Operativa

Con el objetivo de que el proyecto sea operacionalmente factible, el equipo de


desarrollo realizará las capacitaciones necesarias para los administradores del restaurante,
adicionalmente se entregará el respectivo manual de usuario para facilitar su uso. (Hardware,
Software, Recurso Humano).

4.2 Factibilidad Técnica

En cuanto al sistema a desarrollar será un sistema web, es por esto que se debe contar
con un computador con acceso a internet. En la actualidad el restaurante cuenta con un
computador con conexión a internet, el cual cuenta con todos los requerimientos técnicos para
el buen funcionamiento del sistema a implementar.

4.3 Factibilidad Económica

Se realizó un estudio de costo/beneficio, esto considerando gastos que conllevan el


desarrollo del proyecto, versus los desembolsos actuales realizados por la empresa en cuanto a
marketing para aumentar y retener la clientela. Se estimaron los gastos mensuales hechos por
la empresa y dieron como resultado la factibilidad que es la implementación de dicho sistema
por parte de la empresa considerando beneficios económicos. Si bien se estima que una
empresa desembolsa alrededor de $475.863 cada mes, al año una empresa gastaría 5.710.356.
El proyecto tiene un valor de 5.600.000, lo que significaría que la empresa recuperaría la
inversión a partir del mes 11 luego de haber optado por el software para gestionar a sus
clientes y publicidad. Para ver más detalle sobre todos los Estudios de factibilidad realizados
ver Anexo C Estudios de Factibilidad.

4.4 Factibilidad Legal

Para el presente proyecto no existen trabas legales que impidan el buen desempeño y
funcionamiento del software, puesto que no se incurre en infracciones a las leyes vigentes en
la actualidad.

12
Capítulo 5 Gestión de Riesgos

Para manejar los riesgos que pudiesen ocurrir durante el desarrollo del sistema
primero de identificaron, luego se evaluaron y mitigaron, creándose finalmente un plan de
control por si llegaran a suceder. A continuación se presentan los riesgos, para ver el detalle de
los riesgos identificados y su análisis de probabilidad, impacto y exposición ver Anexo D
Gestión de Riesgos.
Tabla 5.1.1: Riesgos Identificados.

ID RIESGO

R1 Planificación del proyecto demasiado optimista.

R2 Un retraso en una tarea produce retrasos en cascada en las tareas dependientes.

Las herramientas de desarrollo no funcionan como se esperaba; el equipo de


R3
desarrollo necesita tiempo para resolverlo o adaptarse a las nuevas herramientas.
El desarrollador no es capaz de adquirir los conocimientos de los lenguajes
R4
involucrados en la aplicación.
Las herramientas de desarrollo no se han elegido en funciones de sus
R5
características técnicas, y no proporcionan las prestaciones previstas.
El desarrollador no es capaz de comprender el diseño de la interfaz para su
R6
desarrollo.
Cambios de requisitos del producto software por parte del cliente antes de la
R7
entrega.
Las partes del proyecto que no se han especificado claramente consumen más
R8
tiempo del esperado.
El tiempo de comunicación del clientes (Por ejemplo: tiempo para responder
R9
preguntas para aclarar los requisitos) es más lenta de lo esperado.

R10 Fecha de entrega no cumplida.

R11 Documentación incompleta o no entendible por parte del cliente.

R12 No hay coordinación entre los integrantes del grupo.

13
Capítulo 6 Desarrollo del Sistema
6.1 Identificación de los Requerimientos
6.1.1 Requerimientos Funcionales
Los requerimientos funcionales definidos para el presente proyecto fueron agrupados
en distintas Módulos como son:

¾ Modulo Cliente
Tabla 6.1.1: Requerimientos Cliente.

Requerimiento RF-1 Cliente


Funcionalidad El sistema permitirá registrarse a usuarios nuevos vía internet.
Especificación Un usuario nuevo al ingresar al sitio del restaurante, se le dará la
opción de registrarse en el sistema para poder acceder a los beneficios.

Requerimiento RF-2 Cliente


Funcionalidad El usuario registrado podrá ver y editar sus datos personales y foto.
Especificación Todos los usuarios registrados en el sistema podrán ver y modificar
sus datos de registro además de agregar o cambiar su foto de perfil.

Requerimiento RF-3 Cliente


Funcionalidad Los usuarios podrán ver los comentarios hechos por otros, y para
poder hacer uno deben estar registrados.
Especificación Si bien todo usuario podrá ver los comentarios hechos por los
demás usuarios, para poder realizar uno, será necesario estar registrado.

Requerimiento RF-4 Cliente


Funcionalidad Los clientes podrán solicitar una reserva vía Online.
Especificación Todos los clientes registrados, podrán realiza una reserva a través
del sitio del restaurante, para luego esperar su confirmación.

Requerimiento RF-5 Cliente


Funcionalidad Los clientes podrán ver las publicaciones hechas por Administrador.
Especificación Existirá una sección en donde se publicaran, los eventos, publicidad,
y podrá ser visto por cualquier usuario que ingrese al sitio.

14
Requerimiento RF-6 Cliente
Funcionalidad Los clientes registrados podrán realizar consultas.
Especificación Todos los usuarios registrados en el sistema podrán realizar
consultas y comentarios de forma interna a través de un formulario,
que enviara el mensaje al mail del administrador.

¾ Modulo Administrador
Tabla 6.1.2: Requerimientos Administrador.

Requerimiento RF-1 Administrador


Funcionalidad Registrar ventas asociadas a cliente registrado.
Especificación El sistema permitirá al administrador registrar cada venta realizada
por el cliente, indicando tipo producto, su cantidad, y precio.

Requerimiento RF-2 Administrador


Funcionalidad El sistema permitirá gestionar a los clientes.
Especificación El sistema permitirá al administrador registrar, editar y eliminar a
clientes que deseen estar registrados en el sistema y acceder a
beneficios.

Requerimiento RF-3 Administrador


Funcionalidad Se podrá agregar publicidad y eventos.
Especificación El sistema permitirá al administrador poder subir y publicar
publicidad que el estime conveniente, como eventos a realizar, fechas
importantes, y promociones, etc.

Requerimiento RF-4 Administrador


Funcionalidad Publicar en redes sociales.
Especificación El sistema permitirá al administrador poder anunciar todas las
publicaciones, como eventos, publicidad, noticias, en redes sociales.

Requerimiento RF-5 Administrador


Funcionalidad Gestionar Carta Online.
Especificación El sistema permitirá al administrador agregar, modificar o eliminar
productos en la carta Online.

Requerimiento RF-6 Administrador


Funcionalidad El administrador podrá ver reportes.
Especificación El sistema permitirá al administrador consultar por diferentes tipos
de reportes como por ejemplo, por venta, producto y cliente.
15
Requerimiento RF-7 Administrador
Funcionalidad Gestionar comentarios
Especificación El sistema permitirá al administrador gestionar comentarios,
permitiendo publicarlos o bien, denegando su publicación.

Requerimiento RF-8 Administrador


Funcionalidad El administrador podrá crear nuevas cuentas de administrador.
Especificación El sistema permitirá al administrador crear nuevas cuentas con
privilegios de administrador.

Requerimiento RF-9 Administrador


Funcionalidad Gestionar reservas
Especificación El sistema permitirá al administrador ver notificaciones de reservas
hechas por clientes registrados, las cuales podrán ser aceptadas o
rechazadas por él.

¾ Modulo Sistema

Tabla 6.1.3: Requerimientos Sistema.

Requerimiento RF-1 Sistema


Funcionalidad Enviar e-mail masivos
Especificación El sistema podrá enviar e-mail masivo a todos los clientes
registrados en el sistema. Notificándole alguna noticia importante.

Requerimiento RF-2 Sistema


Funcionalidad Automatizar envió de emails
Especificación El sistema podrá enviar email a clientes específicos en fechas
específicas, notificándoles alguna oferta o promoción.

6.1.2 Requerimientos No Funcionales

Se entienden como requerimientos no funcionales a las características requeridas del


sistema, del proceso de desarrollo, de préstamos de servicios o de cualquier otro aspecto del
desarrollo, que señale una restricción del mismo. Características estéticas también están dentro
de esta categoría.

16
Tabla 6.1.2.1: Requerimientos No Funcionales.

Requerimiento RNF-1
Característica El sistema debe desarrollar una interfaz de usuario completamente
en el idioma Español.
Especificación Como es de esperar los dos tipos de usuarios que poseerá el
software serán personas que dominan el idioma español.

Requerimiento RNF-2
Característica La interfaz del sistema deber utilizar colores que faciliten su
comprensión y que no confundan al usuario.

Especificación La sencillez es fundamental a la hora del diseño de interfaz.

Requerimiento RNF-3
Característica Las consultas hechas por parte del administrador al sistema no
deberán demorar más de lo esperado.

Especificación La generación de informes cuando sean solicitados, no deberán


exceder los 20 segundos de espera.

Requerimiento RNF-4
Característica El sistema deberá permitir que el administrador pueda ingresar los
registros de ventas a una velocidad aceptable.

Especificación Debido a que el restaurante tiene un flujo constante de clientela el


sistema no debe retrasar la calidad del servicio entregado.

Requerimiento RNF-5
Característica El sistema deberá estar siempre disponible para todo tipo de
usuario.

Especificación Al tratarse de un sistema Web, este deberá estar siempre disponible


para que los distintos usuarios puedas acceder a él en cualquier
momento.

17
Requerimiento RNF-6
Característica El sistema deberá permitir ser visto desde cualquier navegador
usado por los clientes y administrador.

Especificación Esto es, el sitio no se debería ver afectado (diseño) independiente


del navegador que se utilice para verlo.

6.2 Análisis
6.2.1 Actores del Sistema

Los actores son los “usuarios” del sistema que está siendo modelado. Cada actor
tiene un papel bien definido, y en el contexto de esa función tienen interacciones útiles con el
sistema.

Figura 6.2.1: Actores del Sistema.

Una persona puede realizar la función de más de un actor, a pesar de que sólo asumirá
una función durante una interacción caso de uso. Un papel Actor puede ser realizado por un
sistema no humano, por ejemplo, otro programa de ordenador. En el sistema a desarrollar
todos los actores que interactuaran con el software son personas.

ƒ Cliente: es considerado cliente al público que acude al restaurante, este puede ser
nuevo y frecuente. Siendo considerado un cliente frecuente el cual este registrado en el
sistema y posea un historial de ventas. El cliente nuevo, puede ser una persona que se
registre por primera vez en el sistema ya sea en el mismo restaurante o vía Web.

ƒ Administrador: es el actor que llevara a cabo toda las tareas por parte del restaurante
hacían los clientes, es decir, será el encargado de ingresar las ventas de clientes,

18
registrar un nuevo cliente, gestionar la carta ofrecida, solicitar informes al sistema, etc.
Es la persona que actuara en representación del restaurante frente al sistema.

6.2.2 Caso de Uso General

Se presenta el caso de uso general del sistema, en donde es posible apreciar los
actores del sistema y cuáles son las posibilidades de acciones que pueden realizar.

Figura 6.2.2: Caso de Uso General.

Para poder ver todos los diagramas de casos de uso del presente sistema y mayor
información sobre cada uno de ellos ver Anexo F Casos de Uso.

19
6.3 Diseño
6.3.1 Diagramas de Secuencia

A continuación se presenta un diagrama de secuencia considerado el más complejo y


completo del sistema, para poder observar todos los diagramas de secuencia respectivos ver
Anexo G.
6.3.1.1 Ver Reportes.

Figura 6.3.1: Diagrama de Secuencia Ver Reportes.

20
6.3.2 Modelo de Clases

Figura 6.3.2: Modelo de Clases del Sistema.

21
6.3.3 Modelo Relacional de Datos

Se presenta el modelo relacional de datos con las tablas, atributos correspondientes


para poder acceder al Diccionario de Datos ver Anexo G Diseño.

Figura 6.3.3: Modelo Relacional de Datos.

22
Capítulo 7 Implementación
7.1 Organización de la Implementación del Proyecto

A continuación se demuestra de forma gráfica como se organizan los proyectos en


Zend Framework.

Figura 7.1.1: NetBeans luego de Crear el Proyecto.

A continuación se da una breve explicación de las principales carpetas utilizadas en la


organización del proyecto en Zend observadas en la Figura 7.1.1
La carpeta principal lleva el nombre del Proyecto “capicuarestaurant”, en esta
carpeta se encuentran 5 carpetas principales application, data, docs, library y public.

23
La carpeta “application” es la encargada de manejar el modelo de 3 capas de Zend
Framework, acá contiene las 4 carpetas esenciales, controllers, models views y froms.
La carpeta controllers responde a eventos, usualmente acciones del usuario, e invoca
peticiones al modelo y, probablemente, a las vistas.

La carpeta views, son páginas HTML que se generarán a partir de los controladores,
las cuales tendrán extensiones PHTML. Este presenta el modelo en un formato adecuado para
interactuar, usualmente la interfaz de usuario. Dentro de esta carpeta se encuentran otras
carpetas entre ellas layout, en esta se encontrara el archivo layout.phtml, esta página nos
permite definir la estructura del sitio, es decir su distribución topográfica, como ser si dispone
de un encabezado, pie de página, barra lateral izquierda, barra lateral derecha y donde residirá
el contenido de la acción que se está ejecutando actualmente.

Por último la carpeta public es en donde se almacenan todas las imágenes requeridas
por el sistema (productos, usuarios, publicaciones, etc.), en esta carpeta también se almacena
los archivos CSS, los cuales almacenan los estilos (diseño) de las etiquetas y objetos del
sistema.

Si bien el presente proyecto se realiza con un lenguaje de programación orientado a


objeto, php5 se utilizó además un framework, Zend Framework, el cual facilita de manera
óptima la implementación del sistema en 3 capas, en la carpeta views se encuentra la capa de
presentación, en la carpeta controllers se encuentra la capa de negocio, y en la capa models, se
encuentra la capa de datos.

7.2 Interfaces del Sistema

A continuación se presentan las principales interfaces del sistema definitivo. En


primer lugar el layout del sitio web, este se puede observar a continuación:

Figura 7.2.1: Layout.

En la parte superior derecha del sitio web, se puede observar esta sección que al
realizar un ingreso al él, ya sea por parte de un usuario o de Administrador, se muestra la
fotografía y datos personales de cada usuario. El otro extremo del layout, es la zona del logo

24
en donde se pueden observar los iconos de acceso directo a las redes sociales del restaurante.
El mismo logo redirecciona a la página de inicio, en cualquier momento desde cualquier lugar.

Figura 7.2.2: Panel Administrador.

En la Figura 7.2.2 se puede observar el panel del administrador, esta página es la que
aparece al ingresar cualquier administrador y superadministrador al sistema, en ella se pueden
observar los 6 botones principales, con las tareas más recurrentes realizadas por el
administrador. Al costado izquierdo se puede observar un menú desplegable en donde se
puede acceder a todas las funcionalidades ofrecidas a los Administradores del sistema.

Figura 7.2.3: Página Publicaciones.

25
En la Figura 7.2.3 se puede observar la página de publicaciones, que está constituida
por una paginación, cada publicaciones posee sus datos correspondiente y un enlace para ver
más, en donde se podrán ver los comentarios de cada publicación.

Figura 7.2.4: Agregar Venta.

En la figura 7.2.4 se puede observar el primer paso para el registro de ventas, en


donde el administrador debe seleccionar los productos de dicha venta, existen filtros para
poder hacer más ágil este paso, para ahorrar tiempo al administrador en el proceso de registrar
la venta. En el siguiente paso se debe seleccionar al cliente asociado a dicha venta. Para mayor
Información del funcionamiento de Registro de venta y otras funciones de Administrador
revisar “Manual de Usuarios de Sistema de Publicidad y Fidelización de Clientes para
Restaurantes Emergentes”.

26
Capítulo 8 Pruebas de Usabilidad
Una vez concluida la implementación del sistema, se decidió realizar pruebas de
usabilidad para verificar y garantizar que las principales funcionalidades del sistema no
incurran en errores. Y si fuese así, utilizar las últimas iteraciones del proceso unificado, para
poder corregir dichos errores y falencias.

Se diseñaron 2 pruebas de usabilidad, cada una enfocada a los dos grandes grupos de
tipos de usuarios que tendrá el sistema. En primer lugar se realizó una prueba para tipo usuario
“Cliente” en la cual se definieron 3 tareas que englobaron las principales funcionalidades que
ofrece el sistema para dicho tipo de usuario. Dichas tareas incluían el registrarse, editar datos
personales, realizar comentarios, realizar reservas, entre otras. Dichas pruebas contaron con
dos cuestionarios, unos pre test y otro post test. En donde se buscada extraer información
relativa en primer caso sobre sitios similares al sistema desarrollado, y al uso de internet. El
segundo caso, post test, se buscaba extraer información relevante a la experiencia adquirida
luego de utilizar el sistema.

Por otro lado se diseñó una segunda prueba de usabilidad dirigida a usuarios del
sistemas tipos “Administrador o Superadministrador” se definieron 3 tareas a realizar que al
igual en la prueba anterior, englobaran las principales funcionalidades que deben realizar los
administradores y superadministradores dentro del sistema. Dentro de las actividades
solicitadas en la prueba se pueden ver el realizar venta, realizar publicaciones, editar reservas,
etc. Al igual que en la prueba de “cliente” también se realizaron cuestionarios pre test y post
test. De las cuales se pudieron extraer información relevante al uso del sistema. Cuya
información fue utilizada para mejorar algunas cosas del sistema en iteraciones posteriores.
Cabe destacar que dentro de los cuestionarios post test, se realizaron dos preguntas abiertas,
las cuales fueron respondidas por parte de los participantes de las pruebas. Estas preguntas
apuntaban concretamente a lo que más les gusto y lo que menos les gusto del sistema. Es en
esta pregunta en donde se focalizo la mejora a realizar posteriormente.

Para mayor información sobre las pruebas de usabilidad implementadas, dirigirse al


Anexo H Pruebas de Usabilidad.

27
Capítulo 9 Conclusión

Una vez finalizado el estudio del arte sobre el mercado gastronómico y en base al
posterior análisis que detectaron los problemas de dicho rubro, se decidió solucionar
específicamente los puntos relacionados con la publicidad, la captación y posterior
fidelización del cliente.
Se tomó la decisión de diseñar e implementar un sistema software que sea una
herramienta que facilite todo el trabajo que deben realizar las empresas en cuanto a marketing
y gestión de clientes. Se buscó un cliente que estuviese dispuesto a implantar el sistema y que
ayude a definir de mejor forma los requerimientos de éste.
La metodología con que se trabajó Proceso Unificado (UP), permitió realizar gracias
a su flexibilidad gran número de iteraciones, las cuales sirvieron para llevar a cabo un sin
número de correcciones y mejoras en la implementación del sistema. Esta metodología
permitió llevar una planificación bien definida, la cual se respetó para poder cumplir con las
fechas estipuladas.
En la etapa de implantación el primer trabajo que se realizo fue la purificación de
requerimientos que fueron modificados o mejorados desde etapas anteriores, para luego
comenzar con la codificación, este trabajo se realizó mediante módulos, creando diversos de
estos, como son, modulo clientes, módulo administrador, modulo productos, etc.
Luego de fragmentar las tareas de modo que cada módulo del sistema, estuviera
compuesto por sub-módulos y tareas, todo esto para aplicar el principio de “divide vencerá”,
ya que es una eficaz manera de solucionar las problemáticas, y en este caso de llevar a cabo un
gran trabajo.
Al término de esta etapa, dado como concluido el proyecto “Sistema de Publicidad y
Fidelización de Clientes para Restaurantes Emergentes” se puede asegurar que con un trabajo
arduo y con autocontrol, en equipo y compañerismo, fue posible el cumplimiento de todos los
requerimientos exigidos por parte del cliente. Lo anterior no pudo haber sido posible gracias a
los conocimientos adquiridos durante el transcurso de la formación académica.

28
Capítulo 10 Referencias

1.- [Empresa Loyalty Leaders, 2012] Empresa Loyalty Leader, Facts & Stats, Investigación
sobre la fidelizacion comercial. Disponible vía web en http://www.loyaltyleaders.org/facts.php
2. - [Hlavinka, 1990] Kelly Hlavinka y Jim Sullivan, The Billion Member March: The 2011
COLLOQUY Loyalty Census. Disponible via web en http://colloquy.com/files/2011-
COLLOQUY-Census-Talk-White-Paper.pdf
3.- [Decima, 2008] Alejandra Decima, Sistemas Informáticos, Modelo de Cascada.
Disponible vía Web en http://tsag-g1.blogspot.com/2008/06/proceso-de-creacin-de-
software.html
4.- [Coleman, 2010] Kenny Coleman, Ingeniería de Software, Modelos de Procesos de
Software. Disponible vía web en http://kennycoleman.blogspot.com/2010/10/modelos-de-
desarrollo-de-software.html
5.- [Sommerville, 2005] Ingeniería de Software – Ian Sommerville: Edición Séptima.
Disponible en biblioteca de la Pontificia Universidad Católica de Valparaíso, Facultad de
Ingeniería.
6.- [Willer, 2011] Jimmy Willer Maco Elera, Herramientas UML para el modelado de
sistemas. Disponible vía web en http://blog.jmacoe.com/aplicaciones/herramientas-uml-
modelado-sistemas/
7.- [Fernández, 2010] Raquel Fernández Fraile, Proyecto Fin de Carrera de la Universidad
de Madrid, Sistema de gestión de auditorios. Disponible vía web en http://e-
archivo.uc3m.es/bitstream/10016/11100/1/PFC_Raquel_Fernandez_Fraile.pdf
8.- [Popkin, 2010] Popkin Software and Systems, Modelado de Sistemas con UML.
Disponible vía web en http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-
modelado-sistemas-uml.pdf
9.- [Mosqueira, 2007] Eduardo Mosqueira Rey, Principios de análisis Informático.
Disponible vía Web en http://quegrande.org/apuntes/EI/OPT/PAI/teoria/07-08/tema_2_-
_el_proceso_unificado.pdf
10.- [Reija, 2005] Isabel Reija Ruiz, Proyecto fin de carrera, desarrollo e implantación de
un sistema de captación y fidelizacion de clientes en entorno web. Disponible vía web en
http://www.iit.upcomillas.es/pfc/resumenes/42a2e60094f89.pdf

29
Anexos
Anexo A. Detalles de la Solución
Proceso Unificado
El proceso unificado de desarrollo de software, es configurable lo que significa que es
capaz de modificarse según el proyecto que se desea realizar en cuanto a tamaño y
complejidad. Este paradigma refleja una alta relación entre el flujo de trabajo (ciclo de vida) y
las fases que el modelo presenta, lo que se puede apreciar en la Figura A.15

Figura A.1 Proceso Unificado.

El proceso unificado o UP va indicando como se debe manejar las iteraciones


incrementales que van dando forma al sistema en su totalidad, manteniendo un balance entre
los requerimientos del negocio, el tiempo de lanzamiento al mercado y los riesgos del
proyecto.
Características del Proceso Unificado de desarrollo:
ƒ Generalmente iterativo, en proyectos pequeños suele usarse un modelo lineal.
ƒ Desarrollo centrado en la arquitectura, facilitándose el desarrollo en paralelo, la
reutilización y el mantenimiento.
ƒ Dirigido por casos de uso.
ƒ Confiable, adaptable a diferentes proyectos.
ƒ Énfasis en control de calidad y gestión de riesgos.

5
Imagen Extraída de Documento-“El proceso Unificado de Desarrollo de Software RUP”. Universidad
Privada Antenor Orrego

30
Fases que componen el Proceso Unificado
Antes de empezar a definir las fases pertenecientes a este modelo, se definirá el
concepto fase, una fase consiste en un intervalo de tiempo entre dos hitos importantes durante
el cual se cumple un conjunto bien definido de objetivos, se completan artefactos y se toman
decisiones sobre si se pasara a la próxima fase. Ahora bien, continuando con las fases del
Proceso Unificado cabe decir que este modelo define 4 fases, de las cuales daremos unas
características a continuación:

Inicio:
ƒ Establecimiento de la planificación del proyecto y sus costos asociados.
ƒ Descripción del producto final a partir de una idea inicial y análisis de negocios para
el producto.
ƒ Posible arquitectura del sistema.
ƒ Identificación y priorización de riesgo.

Elaboración:
ƒ Establecimiento de un plan y arquitectura correcto.
ƒ Especificación en detalle de los principales casos de uso.
ƒ Se diseña la arquitectura conceptual, lógica y física del sistema. Produciendo para
ellos diversos modelos como son, los casos de uso, del modelo de análisis, modelo de
diseño, del modelo de implementación y modelo de despliegue.

Construcción:
ƒ Desarrollo del sistema.
ƒ Se crea el producto añadiendo el software a la arquitectura.
ƒ Al final se dispone de todos los casos de uso acordados para el desarrollo aunque
puede incorporar defectos.
ƒ Evoluciona la descripción inicial hasta convertirse en el sistema completo, en un
producto listo para ser entregado a los usuarios finales.

Transición:
ƒ En esta fase se entrega el software a los usuarios finales para que realicen pruebas y
puedan reportar tanto defectos como cambios necesarios.
ƒ Se entrega tanto el software como también ayudas como es el manual del usuario en
donde se describen la funcionalidad del sistema.

Ventajas:

ƒ Capturar los requisitos del usuario y demás interesados en el proyecto, de forma


completa y estructurada.
ƒ Proporcionar un método sistemático de desarrollo, de manera que se puede controlar y
planificar su progreso.
ƒ Facilitar la identificación de los posibles errores en el diseño del sistema en las
primeras etapas, evitando así que el desarrollo del proyecto se encarezca e incumpla
los plazos establecidos.
ƒ Permitir al cliente una visibilidad total del proyecto a nivel de desarrollo como de
gestión.

31
ƒ Elaborar el material de soporte necesario que facilite al usuario su interacción con el
sistema y permita al equipo de producción su posterior mantenimiento.
ƒ Predecir los resultados, en cuanto a calidad del producto, tiempos de entrega y coste.
ƒ Administrar el crecimiento, ya que el proceso está accesible a todos los desarrolladores
y está documentado, lo que permite a los nuevos empleados formarse para actuar en
los procesos, prácticas, conceptos y actividades definidos.
ƒ Mejorar continuamente. El sistema de calidad es visible y produce indicadores
cuantitativos, que permite a los responsables tener los procesos monitorizados
continuamente con el objeto de mejorar las prácticas.

Desventajas:

ƒ El método de UP requiere costos de dedicación altos por lo que no es conveniente


usarlo en procesos de un proyecto pequeño.
ƒ Si el proceso no se aplica bien desde el inicio el UP se puede volver muy grande y
difícil, tanto para aprender como para administrar.
ƒ Una cantidad sustancial de tiempo se gasta en tratar de adecuar el up a cada proyecto.
Es por eso que también se corre el riesgo de volver un esclavo del proceso y perder de
vista la razón del proceso.
ƒ Es un proceso pesado.
ƒ Se basa mucho en la documentación.

Paradigma de Análisis Orientado a Objetos


Podemos definir el Análisis Orientado a Objetos como el proceso de construcción de
modelos del dominio del problema, identificando y especificando un conjunto de objetos
semánticos6 que interactúan y se comportan de acuerdo a los requerimientos del sistema.
Un objeto puede servir para representar cualquier cosa física real o conceptual y
acerca de este, se almacenan datos y operaciones definidas para cada objeto específico de cada
clase7. Un objeto existe con la finalidad de prestar servicios y responder frente a solicitudes,
utilizando operaciones internas con sus datos para así entregar una respuesta.
Las clases pueden ser descompuestas en subclases, estas heredan todas las
características de su clase padre y además agregan características propias, por lo tanto totas las
subclases de la clase padre poseen características familiares, y el análisis orientado a objetos lo
asegura, permitiendo a cada subclase heredar las operaciones y atributos de sus predecesoras.
Durante el análisis orientado a objetos se identifica y se describen los objetos dentro
del dominio del problema. Para llevar a cabo esta metodología se construyen dos tipos de
modelos:

6
Los objetos semánticos son aquellos que poseen un significado específico en el dominio del problema, según Monarchi,
David & Gretchen Puhr. A Research Typology for Object-Oriented Analysis and Design.
7
Clase: describe un conjunto de objetos con atributos y métodos en común.

32
ƒ Análisis de Estructura de Objetos: define las categorías de los objetos y las formas en
que se asocian con otros objetos.

ƒ Análisis de comportamiento de Objetos: permiten apreciar los cambios de estados de


los objetos a través del tiempo.
Las diferencias del análisis orientado a objetos en relación al análisis estructurado son
las siguientes:
ƒ El análisis orientado a objetos construye un modelo de objetos en vez de un modelo
funcional.
ƒ El análisis orientado a objetos integra objetos, atributos y operaciones en vez de
separarlos.
ƒ El análisis orientado a objetos es más simple ya que se adecua al mundo real
relacionando objetos.

Herramienta de Modelado
El modelado de sistemas es una actividad importante e imprescindible en la
construcción de cualquier tipo de sistema, está considerado como un plano que nos muestra la
estructura genérica o abstracta de algún sistema. El lenguaje unificado de modelado se ha
vuelto el lenguaje de modelado estándar usado en análisis y diseño orientado a objetos., y
describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que
ha habido muchas notaciones y métodos usados para el diseño orientado a objeto, ahora los
modeladores solo tienen que aprender una única notación, UML.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software,
sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los
cuales se pueden utilizar para modelar sistemas:

ƒ Diagramas de Casos de Uso, para modelar los procesos del sistema.


ƒ Diagramas de Secuencia, para modelar el paso de mensajes entre objetos.
ƒ Diagramas de Colaboración para modelar interacciones entre objetos.
ƒ Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
ƒ Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos
u operaciones.
ƒ Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
ƒ Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
ƒ Diagramas de Componentes para modelar componentes.
ƒ Diagramas de Implementación para modelar la distribución del sistema.

UML sirve tanto como para captar información sobre la estructura estática como el
comportamiento dinámico de un sistema. Cabe destacar que UML no es un lenguaje de
programación, sino, más bien un lenguaje de modelado multipropósito para el modelado
orientado a objetos.

33
UML permite expresar un modelo de análisis utilizando una notación de modelado
con reglas sintácticas (se tiene un set de artefactos definidos), semánticas y prácticas.

En UML un sistema puede ser representado desde 5 vistas diferentes, en que casa
vista lo define de una perspectiva diferente.

x Vista del usuario: representa el sistema desde la perspectiva de los usuarios. El Caso
de Uso es el enfoque elegido para modelar esta vista.
x Vista estructural: los datos y la funcionalidad se muestran desde dentro del sistema, es
decir, modela la estructura estática (clases, objetos y relaciones).
x Vista del comportamiento: esta parte del modelo de análisis representa los aspectos
dinámicos o de comportamiento del sistema. También muestra las interacciones o
colaboraciones entre los diversos elementos estructurales descritos en las vistas
anteriores.
x Vista de implementación: los aspectos estructurales y de comportamiento se
representan aquí tal y como van a ser implementados.
x Vista del entorno: aspectos estructurales y de comportamiento en el que el sistema a
implementar se representa.
A modo de conclusión se puede decir que el modelo de análisis de UML se centra en
las vistas del usuario y estructural, estas proporcionan una visión interna al uso de las
situaciones para el sistema (facilitan guías para el modelado de comportamiento), y establecen
fundamentos para la implementación y vistas del modelo ambiental, identificando y
describiendo elementos estructurales estáticos del sistema. El diseño UML se dirige más a las
vistas del comportamiento y del entorno, el diseño de sistema se centra en arquitectura de
software definición de subsistemas. El diseño de objetos describe objetos, hasta un nivel en el
cual puedan ser implementados en un lenguaje de programación. Es por estas razones que se
ha decidido desarrollar la etapa de modelamiento de Análisis y diseño utilizando la
herramienta de Lenguaje de Modelado Unificado.

Se ha tomado la decisión en base a la descripción de cada uno de los diferentes


diagramas ofrecidos por UML y a las características del sistema a desarrollar, que los
diagramas a utilizar en la etapa de análisis y diseño serán:

9 Diagramas de Casos de Uso, para modelar los procesos del sistema.


9 Diagramas de Secuencia, para modelar el paso de mensajes entre objetos.
9 Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
9 Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.

Lenguaje de Programación
Como se trata de desarrollar una implementación de una plataforma web se evaluaron
diversas alternativas para escoger dentro de estas la que se adapte mejor a las condiciones
deseables de un lenguaje orientado a la Web y que el proyecto requiere. Se analizaron 3
alternativas y a continuación se mencionan los parámetros en que se focalizo la elección final
del lenguaje a utilizar.

34
Active Server Java
Pages (ASP) PHP5 Server Pages
(JSP)

Sin costo de licencia  D D

Nivel conocimiento D D
desarrolladores

Menor Consumo de Recursos D

Soporte D

Facilidad de mantención D

Mayor disponibilidad de D D
Hosting

Independencia de plataforma D D

Orientación a objetos D D D

Facilidad de comprensión D D
Tabla A.1: Lenguaje de Programación.

El lenguaje seleccionado es PHP5. En lo que se refiere a PHP5, cabe mencionar que


es un lenguaje interpretado de alto nivel, fácil de aprender, es muy similar a C, Java, Perl,
pensado para el desarrollo Web, que permite eliminar limitaciones existentes en páginas
HTML, brindando paginas dinámicas.

Motor de Base de Datos


En la selección de una base de datos, se investigaron tres motores de base de datos
distintos, para las cuales se realizó una tabla comparativa midiendo los criterios para realizar
una elección, en la Tabla Siguiente se puede apreciar la comparación:

PgSQL MySQL SQL


Server
Integridad de los Datos
ACID D D D
Bloque de Filas D D D
Rollback Parciales D D D
Características Avanzadas
Procedimientos almacenados D D D
Vistas D D D
Triggers D D D
Cursores D D D

35
Índices
Una columna D D D
Múltiples columnas D D D
Claves Primarias D D D
Varios
Mayor velocidad U D U
Transacciones D D D
Subconsultas D D D
Escalabilidad D D D
Conocimiento de los D D U
Desarrolladores
Sin Costo de Licencia D [ U
Tabla A.2: Comparación Motores de Base de Datos.

De acuerdo con la tabla anterior, se seleccionó MySQL por ser una base de datos que
con el tiempo y sus asociaciones comerciales, ha ido creciendo e integrando cualidades para
ser una base de datos potente y que cumple nuestras expectativas. La única desventaja de
MySQL es que tiene un licenciamiento dual, es decir se puede obtener el código fuente bajo
la licencia GPL v2 (Gratuita) o se puede comprar una licencia comercial.
La licencia GLP8, permite entre otras cosas:

ƒ La licencia GPL le permite manejar un negocio con fines de lucro usando MySQL.
ƒ La licencia GPL permite modificar el código fuente de MySQL en la forma que desee.
ƒ La licencia GPL le permite vender y distribuir MySQL.
ƒ La licencia GPL le permite redistribuir las modificaciones de MySQL.
Por otro lado existe la Licencia Comercial lo cual se utilizada para:

ƒ Modificar MySQL y redistribuir las modificaciones usufructuando de ellas.


ƒ Incluir MySQL dentro de un software, es decir, distribuir el software junto con
MySQL como uno solo.
Por lo mencionado anteriormente, la licencia GPL se adecua a los requerimientos y
MySQL contiene todas las características que se buscan para el desarrollo del proyecto.

8
http://www.gnu.org/licenses/gpl-faq.html

36
Anexo B. Arquitectura del Sistema

Se puede decir que la función define la forma, o lo que es lo mismo que la estructura
o arquitectura de cualquier sistema tiene una relación muy profunda con aquello que tiene que
realizar. Por esta razón los sistemas de información comparten una arquitectura o procesos
bien definidos. El concepto de arquitectura es usado con mucha frecuencia y en muy distintos
contextos, con lo que su significado se ha tornado algo difuso, es por motivo que se
considerara como arquitectura la estructura que tiene el conjunto de componentes que forman
un sistema, así como la relación entre los mismo. Es decir, una visión estructural de alto nivel
del sistema.
Se pueden distinguir dos tipos de arquitecturas de software.
ƒ Lógica: Formada por componentes, subsistemas y programas.
ƒ Física: Formada por computadores o grupo de ellos y sus conexiones.

Arquitectura Lógica
Actualmente la arquitectura lógica sigue un esquema básico formado por 3 capas
primarias. Es esta la arquitectura que se ha elegido para la implementación del sistema a
desarrollar. Estas 3 capas son:
ƒ Interfaz.
ƒ Lógica de dominio (de negocio).
ƒ Fuente de datos (capa de datos).

Figura B.1: Diagrama de Arquitectura Lógica.

La Figura B.1 es una explicación grafica de cómo está constituida la Arquitectura


Lógica de 3 capas del presente proyecto, se puede ver cómo interactúan la capa de
presentación. (HTML), con la capa Lógica (PHP5) y la capa de Dato (MySQL).

37
La arquitectura de 3 capas es un estilo de programación, su objetivo primordial es la
separación de la capa de presentación, capa de negocio y la capa de datos.
La principal ventaja es que el desarrollo se puede llevar a cabo en varios niveles y,
en caso de que sobrevenga algún cambio, este se pueda realizar solo en la capa determinada,
sin afectar al total del proyecto.

x Capa Interfaz (de presentación): Esta capa es la que ve el usuario, presenta el sistema
al usuario, le comunica la información y captura la información del usuario en un
mínimo de procesos.
Esta capa se comunica únicamente con la capa de negocio. También es conocida
como interfaz gráfica y debe tener la característica de ser “amigable”, para el usuario
generalmente se presentan como formularios.
x Capa de Negocio: Aquí es donde, se recibe las peticiones del usuario y se envían las
respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del
negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta
capa se comunica con la capa de presentación, para recibir las solicitudes y presentar
los resultados, y con la capa de datos, para solicitar al gestor de base de datos para
almacenar o recuperar datos de él.
Toda aplicación tiene código para implementar reglas de negocio. Se puede
seleccionar almacenar la lógica de negocios sobre cada estación de cliente, u optar por
ejecutar la lógica de negocios sobre el servidor de aplicaciones.
No toda la lógica de negocio es la misma, algunas no requieren un frecuente acceso
a los datos, pero una interfaz de usuario robusta necesita de la lógica de negocio para la
validación en la entrada de campos, cálculos en tiempo real u otras interacciones de
usuario.
x Capa de Datos: es donde residen los datos y es la encargada de acceder a los mismos,
está formada por uno o más gestores de bases de datos que realizan todo el
almacenamiento de datos reciben solicitudes de almacenamiento o recuperación de
información desde la capa de negocio.

Arquitectura Física
En este apartado se especifica la división física del sistema identificando los nodos y
las comunicaciones entre nodos. Se entiende por nodo cada partición física o parte
significativa del sistema de información con características propias de ejecución y función, e
incluso de diseño y construcción.
La arquitectura física del sistema debe permitir organizar de forma distribuida el
sistema, tal como lo indica la Figura 3.6, estableciendo una arquitectura multinivel
cliente/servidor, en la cual, los múltiples clientes realizan peticiones al servidor, y el servidor
responde a esas solicitudes.

38
Figura B.2: Arquitectura Física del Sistema.

ƒ Cliente Web: El cliente en la aplicación constituye una interfaz gráfica de usuario (GUI)
correspondiente con el lado cliente del protocolo HTTP (Hypertext Transfer Protocol), es
decir, lo que se denomina comúnmente como navegador Web. Este cliente debe permitir
además ejecutar algunas tecnologías Web conocidas como “del lado del cliente”, como
Javascript, CSS, etc.

ƒ Servidor: El servidor, constituye el componente HTTP del lado del servidor, comúnmente
denominado servidor Web, donde se depositan las páginas Web que solicita el cliente.
Este servidor atenderá las peticiones de los clientes y enviará las páginas HTML
requeridas a los mismos.

39
Anexo C. Estudio de Factibilidad

Para desarrollar un sistema nuevo, se debe llevar a cabo un estudio previo de


factibilidad del proyecto, teniendo como resultado indicadores que determinan si dicho
proyecto es viable o no de desarrollarse.
El estudio de factibilidad realizado se centró en 4 puntos que son:

ƒ Factibilidad Operacional.
ƒ Factibilidad Técnica.
ƒ Factibilidad Económica.
ƒ Factibilidad Legal.
A continuación se presenta el estudio de cada uno de los ítems.

Factibilidad Operativa
Dicha factibilidad corresponde a la probabilidad de que el sistema se utilice como se
debe, es decir, para lo que fue creado. Para que el presente proyecto posea una real factibilidad
operativa se deben considerar los dos tipos de usuarios que poseerá el sistema, estos son el
usuario administrativo, quien deberá administrar y el sistema directamente y los usuarios o
clientes del restaurante, y sus respectivos conocimientos computacionales.
A continuación se dan a conocer diversos factores que podrían afectar a dicha
factibilidad y como se pretenden solucionar:
ƒ El nuevo sistema puede ser demasiado complejo para los usuarios de la organización: Se
diseñara un sistema con prácticas de usabilidad y minimizar la complejidad con el diseño
de ésta.

ƒ El sistema puede ser complejo de entender por los usuarios: El sistema no debería tener
problemas en este aspecto, ya que este debe ser diseñado con un enfoque de usabilidad.

ƒ El sistema podría provocar cambios en el flujo de trabajo actual: El nuevo sistema Web no
debe causar ningún cambio en el trabajo actual, sino dar un aporte y beneficios a los
clientes del restaurant.

Con el objetivo de que el proyecto sea operacionalmente factible, el equipo de


desarrollo realizara las capacitaciones necesarias para los administradores del restaurante.
Adicionalmente se entregara el respectivo manual de usuario para facilitar su uso.

40
Factibilidad Técnica
El análisis de factibilidad técnica evalúa si el equipo y software están disponibles y si
tienen las capacidades técnicas requeridas por cada alternativa del diseño que se esté
considerando.
Hardware
Para las etapas de análisis de requisitos, diseño, construcción del sistema, y
documentación se cuenta con el siguiente hardware:

Hardware en posesión
x 2 notebook con conexión a Internet

Hardware que facilita la escuela para el uso de los alumnos:

x Atenas: 20 PC`s DELL, Core 2 Duo E6550/2.33GHz, 2GB RAM, 80GB SATA, DELL
19” LCD, Windows 7 y Ubuntu 11.10.
x Acrópolis: 10 PC`s DELL, Core 2 Duo E6550/2.33GHz, 2GB RAM, 80GB SATA,
DELL 21” LCD, Windows 7 y Ubuntu 11.10.

Software
Se detallan a continuación el software disponible y en posesión de los alumnos que
pueden ser usados en el proyecto.

 Software para desarrollo de informes y documentos: Microsoft Office 2010.

 Software para codificación del sistema: IDE Netbeans 7.1 Open source, IDE eclipse.

 Software para el motor de la bases de datos: Base de Datos Oracle 10g Express
Edición, MySQL 5.5.2 open source

 Software para servidor Web: Apache

 Software para navegar: Internet Explorer, Firefox, Google Chrome.

 Software de tipo Sistema Operativo: Windows 7 Service Pack 1.


Recursos Humanos
Para la realización del Proyecto se cuenta con 2 alumnos los cuales poseen las
siguientes competencias académicas.

 Lenguajes de programación: JAVA, C, C++, Prolog, PHP.

 Modelamiento de software, utilizando el lenguaje de modelado unificado UML.

 Motores de bases de datos: MySQL, PostgreSQL

 Sistemas Operativos: Windows XP Profesional, Windows 7, Linux.

41
 Cursos realizados competentes al desarrollo del proyecto:
ƒ Taller de Desarrollo de sistemas
ƒ Interacción Persona - Computador

Factibilidad Económica
Se realizó un estudio de costo/beneficio, esto considerando todos los gastos que
conllevan el desarrollo del proyecto. Se evalúan los costos actuales destinados por parte de la
empresa en cuanto al marketing desarrollado para aumentar y retener la clientela, nueva y
actual respectivamente. Se define como ingresos en el presupuesto de la organización el
ahorro que se produce por utilizar el sistema propuesto y como gastos aquellos que implica
desarrollar el sistema para la organización.
En primer lugar se realiza un análisis aproximado de los gastos que desembolsan las
empresas en las distintas técnicas y medios de publicidad que existen hoy en día en nuestro
país. Luego se analizó los costos que se requieren para el desarrollo e implementación del
sistema software planteado. Para finalmente realizar una comparación y explicar de forma
contable la rentabilidad por parte de la empresa si decide elegir implementar el software a
desarrollar.
Estimación de gastos del Sistema Actual
En la Tabla C.1 se identifican los gastos aproximados que un restaurante emergente
invierte en todo lo que es marketing con el objetivo de captar y retener a sus clientes.

Gastos en Marketing Cantidad Costo por Costo Mensual


Promocional (Mensual) Unidad

Flayers9 2000 $ 22 $ 44.000

Publicidad Diario 4 $69.863 $279.452

Empleado Part- 8 $10.000 $80.000


Time

Aviso radial 1 $1.500.000 $1.500.000

Sub Total - - $ 1.903.452

Gasto Promedio $475.863


Mensual
Tabla C.1: Estimación de Gastos Actuales Hechos por la Empresa.

En la Tabla C.1 se pueden observar los costos estimados que deben desembolsar las
distintas empresas que quieran hacer publicidad en cualquiera de los 5 medios nombrados. Se

9
Cotización de Sistema de Publicidad basado en Flayers http://aquinegocio.cl/p21129-volantes--flyers.html

42
puede concluir de la anterior tabla, que aproximadamente una empresa debe invertir a lo
menos $475.863 en publicidad.

Cabe destacar que actualmente los restaurantes emergentes están recurriendo más a
menudo a empresas de cupones electrónicos, como por ejemplo Grupon o Cupomatic, lo cual
es un medio arriesgado de publicidad ya que estas empresas solo aceptan promociones si están
sobre el 70% de descuento y además los restaurantes reciben un rembolso de sólo el 50% de lo
ofertado a los clientes.

Valoración Económica del Proyecto


En la realización del proyecto, resulta necesario realizar cálculos del esfuerzo en el
desarrollo y sobre los cuales poder estimar el número de recursos necesarios para su correcto
logro, y con ello obtener el coste económico total del proyecto a desarrollar.
Por lo que el costo real del desarrollo de este proyecto, es obtenido a partir de los
costos del personal y del material utilizado. A continuación se detallan cada uno de estos
costos:
Coste de Personal
En primer lugar se identifican las diferentes etapas de trabajo y el costo de cada
especialidad.

Etapa de Tiempo Horas Costo en Total en


Desarrollo Mensuales pesos/mes pesos
Análisis 2 meses 100 $ 400.000 $ 800.000
Diseño 2 meses 100 $ 300.000 $ 600.000
Implementación 4 meses 100 $ 300.000 $ 1.200.000
Pruebas 1 mes 100 $ 200.000 $ 200.000
Total 8 meses 800 - $ 2.800.000
Tabla C.2: Gastos Estimados por Etapa de Desarrollo.

Los costos anteriores son una ponderación referencial al sueldo de cada especialidad
ejercida por estudiantes universitarios. Cabe destacar que la realidad en la que se desarrollara
el sistema constara con la participación de 2 alumnos, los cuales serán los encargados de las
diferentes etapas de desarrollo. Teniendo esto en claro se concluye el costo final de recuso
humano del proyecto es $5.600.000.

Costo Asociado a la Adquisición de Software


Las herramientas utilizadas en las diferentes etapas de desarrollo e implementación
del presente proyecto son de carácter Open Source.

43
Costo de Material
Al tratarse de un sistema Web se requiere de un web hosting para poder alojar los
archivos funcionales y base de datos del software. Además debe cumplir con software y
servicios específicos, tales como, MySQL y PHP.

Concepto Cantidad Coste Total


Unitario
Hosting 1 $40.600 $40.600
Empresa10
Tabla C.3: Costos de Material.

Si bien este es el costo aproximado del material, la empresa a la cual se le


desarrollara el software, ya posee un Hosting el cual cumple con los requisitos necesarios para
la implementación del sistema software a desarrollar. Es por esto que este costo no se
considerara como el total del programa.

Costo Total del Proyecto


Concepto Total
Costo de Personal11 $5.600.000

Costo de Material -

Costo Total del Proyecto $5.600.000

Tabla C.4: Resumen de Costos de Proyecto.

Como ya se dijo anteriormente el valor del Hosting no se considerara como inversión


ya que la empresa cuenta con uno, el costo total del proyecto solo será el costo del personal, es
decir, $5.600.000.

Justificación Económica
Si bien se estima que una empresa desembolsa alrededor de $475.863 cada mes, al
año una empresa gastaría 5.710.356. El proyecto tiene un valor de 5.600.000, lo que
significaría que la empresa recuperaría la inversión a partir del mes 11 luego de haber optado
por el software para gestionar a sus clientes y publicidad.

10
Cotización de Hosting Anual - http://www.menteglobal.com/plan-empresa.html
11
Se ha realizado una estimación de los costos de personal

44
Factibilidad Legal
El objetivo de la factibilidad Legal es el poder verificar de que al desarrollar un
sistema, éste no incurre, en infracciones, violaciones u otros delitos que podrían implicar en la
imposibilidad de poner en práctica o interrumpir el funcionamiento del sistema.
Para el presente proyecto no existen trabas legales que impidan el buen desempeño y
funcionamiento del software, puesto que no se incurren en infracciones a las leyes vigentes en
la actualidad, de las cuales se especifican a continuación:
Ley Nº 19.223 la cual tipifica figuras penales relativas a la informática.
Artículo 1°.- El que maliciosamente destruya o inutilice un sistema de tratamiento de
información o sus partes o componentes, o impida, obstaculice o modifique su
funcionamiento, sufrirá la pena de presidio menor en su grado medio a máximo.
Si como consecuencia de estas conductas se afectaran los datos contenidos en el
sistema, se aplicará la pena señalada en el inciso anterior, en su grado máximo.
Artículo 2°.- El que con el ánimo de apoderarse, usar o conocer indebidamente de la
información contenida en un sistema de tratamiento de la misma, lo intercepte, interfiera o
acceda a él, será castigado con presidio menor en su grado mínimo a medio.
Artículo 3°.- El que maliciosamente altere, dañe o destruya los datos contenidos en
un sistema de tratamiento de información, será castigado con presidio menor en su grado
medio.
Artículo 4°.- El que maliciosamente revele o difunda los datos contenidos en un
sistema de información, sufrirá la pena de presidio menor en su grado medio. Si quien incurre
en estas conductas es el responsable del sistema de información, la pena se aumentará en un
grado.
Ley Nº 17.336 que tiene relación con la propiedad intelectual, específicamente el
artículo 41 el cual dice relación con copias o adaptaciones, pues en este proyecto no se
realizan copias de código fuente, interfaces, de algún otro software que pudiese tratar la misma
materia o similar.
Por lo tanto el equipo de trabajo dará cumplimiento a lo establecido en las
citadas leyes, no incurriendo en ningún tipo de problema legal, lo que para este efecto será
factible realizar el presente proyecto.

45
Anexo D. Gestión de Riesgos

Una de las tareas más relevantes a la hora de planificar un proyecto software es la


identificación de riesgos, ya que estos amenazan el plan del proyecto y una acertada
identificación de ellos anticipa al gestor del proyecto a evitarlos o contenerlos cuando estos
sucedan en el desarrollo del proyecto, y además poder administrarlos a lo largo del proyecto.

Identificación de Riegos
Para el desarrollo del proyecto se identificaron un conjunto de posibles problemas
que pueden presentar en la implementación y desarrollo del sistema, y en su mantenimiento.
La Tabla D.1 muestra la definición de los riegos12.

ID Riesgo

R1 Planificación del proyecto demasiado optimista


Un retraso en una tarea produce retrasos en cascada en las tareas
R2
dependientes.
Las herramientas de desarrollo no funcionan como se esperaba; el equipo de
R3
desarrollo necesita tiempo para resolverlo o adaptarse a las nuevas herramientas.

El desarrollador no es capaz de adquirir los conocimientos de los lenguajes


R4
involucrados en la aplicación.

Las herramientas de desarrollo no se han elegido en funciones de sus


R5
características técnicas, y no proporcionan las prestaciones previstas.

El desarrollador no es capaz de comprender el diseño de la interfaz para su


R6
desarrollo

Cambios de requisitos del producto software por parte del cliente antes de la
R7
entrega.

Las partes del proyecto que no se han especificado claramente consumen más
R8
tiempo del esperado.

El tiempo de comunicación del clientes (Por ejemplo: tiempo para responder


R9
preguntas para aclarar los requisitos) es más lenta de lo esperado.

R10 Fecha de entrega no cumplida.

12
Ingeniería de Software – Ian Sommerville: Capitulo 5 Gestión de proyectos – Pag: 96. Edición Séptima.

46
R11 Documentación incompleta o no entendible por parte del cliente

R12 No hay coordinación entre los integrantes del grupo.

Tabla D.1: Riesgos Identificados.

Estimación de la Probabilidad
La probabilidad del riesgo es una medida que calcula la probabilidad de que la
situación de riegos llegue a producirse de verdad.
Para cuantificar la incertidumbre acerca de la ocurrencia de los riesgos se emplearán
las categorizaciones expresadas en lenguaje natural, en base a un rango de probabilidades
establecido en un cuadro de referencia.

Rango de Promedio Expresión de Valor


Probabilidad para el Calculo Leguaje Numérico
de 1% a 10% 5% Baja 1
de 11 % a 18 % Poco probable 2
25%
de 26% a 40 % Media 3
55%
de 56% a 68 % Altamente probable 4
80%
de 81% a 90 % Casi seguro 5
99%

Tabla D.2: Tabla de Estimación de Probabilidad.

47
ID Riesgo Expresión Probabilidad

R1 Planificación del proyecto Media 30%


demasiado optimista
R2 Un retraso en una tarea produce Media 40%
retrasos en cascada en las tareas
dependientes.
R3 Las herramientas de desarrollo no Poco 20%
funcionan como se esperaba; el equipo Probable
de desarrollo necesita tiempo para
resolverlo o adaptarse a las nuevas
herramientas.
R4 El desarrollador no es capaz de Poco 15%
adquirir los conocimientos de los Probable
lenguajes involucrados en la aplicación.

R5 Las herramientas de desarrollo no se Poco 20%


han elegido en funciones de sus Probable
características técnicas, y no
proporcionan las prestaciones previstas.
R6 El desarrollador no es capaz de Baja 10%
comprender el diseño de la interfaz para
su desarrollo

R7 Cambios de requisitos del producto Media 35%


software por parte del cliente antes de
la entrega.
R8 Las partes del proyecto que no se Media 40%
han especificado claramente consumen
más tiempo del esperado.
R9 El tiempo de comunicación del Altamente 70%
clientes (Por ejemplo: tiempo para Probable
responder preguntas para aclarar los
requisitos) es más lenta de lo esperado.
R10 Fecha de entrega no cumplida. Poco 15%
Probable

R11 Documentación incompleta o no Baja 5%


entendible por parte del cliente
R12 No hay coordinación entre los Altamente 75%
integrantes del grupo. Probable

Tabla D.3: Probabilidad de Riesgos.

48
Estimación del Impacto
El impacto del riesgo calcula la gravedad de los efectos adversos, la magnitud de una
pérdida o el costo potencial de la oportunidad si el riesgo llega a producirse dentro del
proyecto.

Criterio Retraso en la Planificación Valor Numérico


Insignificante 1 semana 1
Marginal 2 semanas 2
Medio 1 mes 3
Critico 2 meses 4
Catastrófico Más de 2 meses 5
Tabla D.4: Estimación del Impacto.

La tabla D 5 muestra los riegos identificados y su estimación de Impacto.

ID Riesgo Impacto

R1 Planificación del proyecto demasiado optimista Marginal


Un retraso en una tarea produce retrasos en cascada en las
R2 Medio
tareas dependientes.
Las herramientas de desarrollo no funcionan como se
Critico
R3 esperaba; el equipo de desarrollo necesita tiempo para
resolverlo o adaptarse a las nuevas herramientas.
El desarrollador no es capaz de adquirir los conocimientos Critico
R4
de los lenguajes involucrados en la aplicación.
Las herramientas de desarrollo no se han elegido en Medio
R5 funciones de sus características técnicas, y no proporcionan las
prestaciones previstas.
El desarrollador no es capaz de comprender el diseño de la
R6 Insignificante
interfaz para su desarrollo
Cambios de requisitos del producto software por parte del Medio
R7
cliente antes de la entrega.
Las partes del proyecto que no se han especificado
R8 Marginal
claramente consumen más tiempo del esperado.
El tiempo de comunicación del clientes (Por ejemplo:
Medio
R9 tiempo para responder preguntas para aclarar los requisitos) es
más lenta de lo esperado.
Insignificante
R10 Fecha de entrega no cumplida.
Documentación incompleta o no entendible por parte del Insignificante
R11
cliente

49
R12 No hay coordinación entre los integrantes del grupo. Medio
Tabla D.5: Riegos y su Impacto

Exposición al Riesgo
La exposición al riesgo calcula la amenaza general que supone el riesgo combinando
la información que expresa la probabilidad de una pérdida real con información que indica la
magnitud de la pérdida potencial en un único valor numérico.
La exposición al riesgo se calcula multiplicando la probabilidad de riesgo por el
impacto. Luego se utilizará la magnitud de la exposición al riesgo para clasificar los riesgos.
Magnitud de exposición al riesgo:
Aprox. 1 = bajo riesgo.
Aprox. 2 = riesgo medio.
Aprox. 3 = alto riesgo
En la Tabla D.6 se muestra el cálculo para obtener la exposición del Riegos.

ID Riesgo Probabilidad Impacto Exposición


Planificación del proyecto
R1 30% 2 0,6
demasiado optimista
Un retraso en una tarea
R2 produce retrasos en cascada en las 40% 3 1,2
tareas dependientes.
Las herramientas de desarrollo
no funcionan como se esperaba; el
R3 equipo de desarrollo necesita 20% 4 0,8
Tabla D.5: Riegos
tiempo para resolverlo o adaptarse con su Estimación del Impacto.
a las nuevas herramientas.
El desarrollador no es capaz de
adquirir los conocimientos de los 15% 4 0,6
R4
lenguajes involucrados en la
aplicación.
Las herramientas de desarrollo
no se han elegido en funciones de
20% 3 0,6
R5 sus características técnicas, y no
proporcionan las prestaciones
previstas.

50
El desarrollador no es capaz de
R6 comprender el diseño de la 10% 1 0,1
interfaz para su desarrollo
Cambios de requisitos del
R7 producto software por parte del 35% 3 1,05
cliente antes de la entrega.
Las partes del proyecto que no
se han especificado claramente 40% 2 0,8
R8
consumen más tiempo del
esperado.
El tiempo de comunicación del
clientes (Por ejemplo: tiempo para
70% 3 2,1
R9 responder preguntas para aclarar
los requisitos) es más lenta de lo
esperado.
R1 15% 1 0,15
Fecha de entrega no cumplida.
0
R1 Documentación incompleta o 5% 1 0,05
1 no entendible por parte del cliente
R1 No hay coordinación entre los 75% 3 2,25
2 integrantes del grupo.
Tabla D.6: Tabla de Exposición de los Riegos.

Líneas de Acción
Para ejercer una adecuada gestión y supervisión de los riesgos mencionados
anteriormente, se elaborará un Plan de Acción y un Plan de Contingencias para cada uno de
ellos.
El Plan de Acción será utilizado para minimizar los riesgos mediante acciones
preventivas. La probabilidad de que un riesgo ocurra así como el impacto que el mismo podría
ocasionar en el proyecto pueden ser mitigados encarando los problemas en forma proactiva.
El Plan de Contingencia, por el contrario intenta implementar respuestas rápidas
para mitigar los efectos en caso de que los riesgos se concreten, es decir reducir el impacto de
los mismos mediante una reacción planeada.

Plan de Acción de Riegos

La Tabla D.7 muestra los planes de mitigación para los riesgos detectados para el
proyecto.

51
ID Riesgo Mitigación

Generar una planificación realista


Planificación del proyecto
R1 acorde a las exigencias del proyecto y a
demasiado optimista
las capacidades del equipo.
Un retraso en una tarea Dar el tiempo necesario real para
R2 produce retrasos en cascada en cada tarea y no caer en la planificación
las tareas dependientes. dependiente.
Las herramientas de
desarrollo no funcionan como
Se da un tiempo prudente para
se esperaba; el equipo de
R3 aprender el sobre las herramientas y
desarrollo necesita tiempo para
poder adaptarse a ellas.
resolverlo o adaptarse a las
nuevas herramientas.
El desarrollador no es capaz
de adquirir los conocimientos Se da un tiempo para investigar y
R4
de los lenguajes involucrados aprender sobre el lenguaje
en la aplicación.
Las herramientas de
Se investigan las funcionalidades de
desarrollo no se han elegido en
cada herramienta de desarrollo,
R5 funciones de sus características
eligiendo la que mejor se adapte al
técnicas, y no proporcionan las
proyecto.
prestaciones previstas.
Se deben generar documentación de
El desarrollador no es capaz diseño claro y entendible para el equipo
R6 de comprender el diseño de la de trabajo, con el objetivo de despejar
interfaz para su desarrollo todo tipo de dudas con respecto al
diseño de interfaz.
Se deben acordar reuniones
periódicas con el cliente y en cada una
Cambios de requisitos del
de ellas, realizar un resumen de los
R7 producto software por parte del
requerimientos para que sean re-
cliente antes de la entrega.
aprobados.

Las partes del proyecto que Se deben otorgar más tiempos para
no se han especificado tareas que no se han especificado
R8
claramente consumen más claramente.
tiempo del esperado.

52
El tiempo de comunicación Se deben acordar fechas de
del clientes (Por ejemplo: reuniones futuras con anterioridad, para
tiempo para responder que el cliente pueda organizarse. Se
R9
preguntas para aclarar los deben utilizar diferentes medios de
requisitos) es más lenta de lo comunicación, tanto personales como
esperado. por medio de email y teléfono.
Fecha de entrega no Estimar tiempos prudentes para las
R10
cumplida. actividades

Documentación incompleta Se debe utilizar un lenguaje lo mas


R11 o no entendible por parte del familiar al cliente para que este pueda
cliente entender todo tipo de documentación.

Se deberán realizar reuniones


cotidianamente en lo posible, cuando
No hay coordinación entre
R12 no, se utilizaran herramientas de
los integrantes del grupo.
comunicación como
Videoconferencias.
Tabla D.7: Definición de Planes de Acción para Riesgos Definidos.

Si alguno de los riesgos mencionados llegaba a ocurrir, se creó un plan de


contingencia con el fin de poder enfrentar el riesgo y mantener un control de éste.

Plan de Contingencia

La Tabla D.8 muestra los planes de contingencia para la posible ocurrencia de los
riesgos.

ID Riesgo Contingencia
Restructuración del proyecto a las
Planificación del proyecto capacidades del equipo, utilizado horas
R1
demasiado optimista extras para el cumplimento de las
tareas.
Se reorganizara el escalamiento de
Un retraso en una tarea produce retrasos
R2 las tareas, para que el retraso de una,
en cascada en las tareas dependientes.
no impida la posterior.
Las herramientas de desarrollo no
Se tomara la decisión de seguir
funcionan como se esperaba; el equipo
resolviendo los problemas actuales, o
R3 de desarrollo necesita tiempo para
derechamente buscar una nueva
resolverlo o adaptarse a las nuevas
herramienta.
herramientas.

53
Se pondrá personal en el grupo de
El desarrollador no es capaz de
desarrollo con las capacidades de
R4 adquirir los conocimientos de los
incorporarse y de aprender los
lenguajes involucrados en la aplicación.
lenguajes escogidos.
Las herramientas de desarrollo no se
Reanalizar las herramientas y ver la
han elegido en funciones de sus
R5 factibilidad de realizar algún cambio en
características técnicas, y no
la herramienta.
proporcionan las prestaciones previstas.
El desarrollador no es capaz de
Coordinar reunión el diseñador de
R6 comprender el diseño de la interfaz para
interfaz.
su desarrollo
Cambios de requisitos del producto Realizar un estudio para ver la
R7 software por parte del cliente antes de la factibilidad del cambio en la
entrega. incorporación del sistema.
Las partes del proyecto que no se Se deberá comunicar con el cliente
R8 han especificado claramente consumen para aclarar todo tipo de dudas por
más tiempo del esperado. parte de los desarrolladores.
El tiempo de comunicación del
Ajustarse a los requerimientos
clientes (Por ejemplo: tiempo para
R9 iniciales e insistir con las reuniones
responder preguntas para aclarar los
aclarativas.
requisitos) es más lenta de lo esperado.
No aplica, ya que existen fechas
R10 Fecha de entrega no cumplida.
establecidas.
Documentación incompleta o no Adecuar la documentación con un
R11
entendible por parte del cliente enfoque al cliente
No hay coordinación entre los Fijar reuniones presenciales y
R12
integrantes del grupo extras.
Tabla D.8: Definición de Plan de Contingencia Para los Riesgos Definidos.

54
Anexo E. Planificación
Iteraciones de Proceso Unificado
La 1º Iteración abarco el periodo de tiempo desde el 3 hasta el 17 de Agosto, donde
se dio inicio al proyecto, planificando las tareas y determinando la vialidad de éste. Se
investigó la situación actual del mercado y sus principales problemas. Al finalizar la Primera
iteración se entrega la Versión I del documento del Proyecto de “Sistema de Publicidad y
Fidelización de cliente”
La 2º Iteración transcurre entre el día 20 hasta el 31 de Agosto, en este
periodo se refinaron los puntos de la 1º Iteración, además de investigar los principales
problemas del mercado gastronómico y definir el alcance del proyecto y sus objetivos. Se
identificaron los principales riegos del proyecto, creando planes de mitigación y contingencia.
También se investigaron las Metodologías y Paradigmas, para posteriormente realizar una
elección acorde al proyecto. Al finalizar la 2° Iteración se entrega la Versión II del documento
del Proyecto de “Sistema de Publicidad y Fidelización de cliente”
La 3º Iteración se desarrolla entre los días 3 y 10 de Septiembre, donde se
refinaron los objetivos del proyecto y dando inicio a la fase de elaboración del proyecto, en
donde se especifican los requerimientos y se analizan, además se realiza la arquitectura tanto
lógica como física del sistema. Al finalizar la Tercera iteración se entrega la Versión III del
documento del Proyecto de “Sistema de Publicidad y Fidelización de cliente”
La 4º Iteración abarco el periodo de tiempo desde el 10 hasta el 21 de
Septiembre, periodo en el cual se refinaron los requerimientos tanto funcionales como no
funcionales después de la primera reunión con el cliente. Además se investigó sobre los
motores de bases de datos y se eligió la más adecuada, y se comenzó con el modelado del
sistema, modelando el caso de uso general y sus principales desgloses. Al finalizar la Cuarta
iteración se entrega la Versión de Avance IV del documento del Proyecto de “Sistema de
Publicidad y Fidelización de cliente”
La 5º Iteración abarco el periodo de tiempo desde el 23 de septiembre hasta el 12 de
Octubre, periodo en el cual se refinaron los modelos de caso de uso y se comenzó la
construcción de los diagramas de secuencia con el objetivo de analizar la interacción de los
objetos del sistema. Al finalizar la Quinta iteración se entrega la Versión de Avance V del
documento del Proyecto de “Sistema de Publicidad y Fidelización de cliente”
La 6º Iteración abarco el periodo de tiempo desde el 14 hasta el 31 de Octubre,
periodo en el cual se refinó el modelado del sistema, específicamente, los diagramas de
secuencia, además se comenzó el modelamiento del diagrama de clases y por consiguiente el
modelo relacional de datos .Al finalizar la Sexta iteración se entrega la Versión de Avance VI
del documento del Proyecto de “Sistema de Publicidad y Fidelización de cliente”.

La 7º Iteración abarco el periodo de tiempo desde el 15 hasta el 22 de Octubre,


periodo en el cual se refinó el modelado de datos, poniendo atención en los datos y sus tipos,
además de las relaciones con cada entidad, también se comenzó los diseño de interfaces,

55
logotipo e isotipos del sistema, dando a conocer al clientes varios prototipos para su elección.
Al finalizar la Séptima iteración se entrega la Versión de Avance VII del documento del
Proyecto de “Sistema de Publicidad y Fidelización de cliente”
La 8º Iteración abarco el periodo de tiempo desde el 5 hasta el 25 de Marzo del
2013, periodo en el cual se abarca la fase de construcción del sistema de información, en el
cual se refinan los diseño de interfaces y se analizan algunos requerimientos faltantes. Al
finalizar la Octava iteración se entrega la Versión de Avance VIII del documento del Proyecto
de “Sistema de Publicidad y Fidelización de cliente”.

La 9º Iteración abarca el periodo de tiempo desde el 25 de marzo hasta el 1 de Abril


de 2013, periodo en el cual se dio inicio formal a la codificación del sistema, refinando las
interfaces de usuario, definiendo los colores e iconografía .Al finalizar la Novena iteración se
entrega la Versión de Avance IX del documento del Proyecto de “Sistema de Publicidad y
Fidelización de cliente”
La 10º Iteración abarca el periodo de tiempo desde el 2 hasta el 5 de Abril de 2013,
periodo en el cual se fueron refinando los módulos de programación utilizando Zend
Framework .Al finalizar la Décima iteración se entrega la Versión de Avance X del documento
del Proyecto de “Sistema de Publicidad y Fidelización de cliente”

La 11º Iteración abarca el periodo de tiempo desde el 5 hasta el 12 de Abril de


2013, periodo en el cual se refino los modelos de bases de datos, creando sus respectivas
clases. Al finalizar la Onceava iteración se entrega la Versión de Avance XI del documento del
Proyecto de “Sistema de Publicidad y Fidelización de cliente”

La 12º Iteración abarca el periodo de tiempo desde el 12 hasta la fecha, periodo en


el cual se está dando forma al módulo de administración .Al finalizar la Doceava iteración se
entrega la Versión de Avance XII del documento del Proyecto de “Sistema de Publicidad y
Fidelización de cliente”

56
Anexo F. Casos de Uso
Caso de Uso General

Figura F.1: Caso de Uso General.

57
Caso de uso Gestionar Carta Online

Figura F.2: Caso de Uso Gestionar Carta Online.

Caso de Uso Gestionar Carta Online


Actor (es) Administrador
Requerimiento RF-5 Administrador
Precondiciones El Administrador debe previamente ingresar al sistema
Descripción Actor Respuesta Sistema
El Administrador al ingresar 1. Indexa al Administrador al
al sistema, tiene las siguientes formulario a llenar de nuevo
opciones: producto.
2. Indexa al Administrador al
1.- Ingresar Producto buscador de productos.
2.- Editar Producto 3. Se solicita seleccionar los
3.- Eliminar Producto alimentos o plato a eliminar.
Excepciones -
Post-Condiciones Luego de la confirmación de la acción se vuelve al menú

58
Caso de Uso Gestionar Clientes

Figura F.3: Caso de Uso Gestionar Clientes.

Caso de Uso Gestionar Clientes


Actor (es) Administrador
Requerimiento RF-2 Administrador
Precondiciones El Administrador debe previamente ingresar al sistema
Descripción Actor Respuesta Sistema
El Administrador al ingresar 1. Indexa al Administrador al
al sistema, y elegir “Modificar formulario de registro de
cliente” tiene las siguientes nuevo cliente.
opciones: 2. Muestra el listado de clientes.
1.- Ingresar Cliente. 3 y 4. Se indexa a “Buscador”
2.- Ver Clientes. de clientes.
3.- Modificar Cliente.
4.- Eliminar Cliente
Excepciones -
Post-Condiciones Luego de la confirmación de la acción se vuelve al menú

59
Caso de Uso Gestionar Publicidad

Figura F.4: Caso de Uso Gestionar Publicidad.

Caso de Uso Gestionar Publicidad


Actor (es) Administrador
Requerimiento RF-3 Administrador
Precondiciones El Administrador debe previamente ingresar al sistema
Descripción Actor Respuesta Sistema
El Administrador al ingresar 1. Indexa al Administrador al
al sistema, y elegir “Publicidad” formulario para crear
tiene las siguientes opciones: publicidad
1.- Crear Publicidad. 2. Publica la publicidad en
2.- Compartir RRSS. RRSS.
3.- Editar Publicidad. 3 y 4. Se indexa al listado de
4.- Eliminar Publicidad. publicidad.
Excepciones -
Post-Condiciones Luego de la confirmación de la acción se vuelve al menú

60
Caso de Uso Editar Perfil

Figura F.5: Caso de Uso Editar Perfil.

Caso de Uso Editar Perfil


Actor (es) Cliente
Requerimiento RF-2 Cliente
Precondiciones Cliente debe previamente ingresar al sistema y seleccionar editar
perfil.
Descripción Actor Respuesta Sistema
Cliente al ingresar en su cuenta y 1. Indexa a cliente al
seleccionar “Editar Cuenta” tendrá las formulario de sus
siguientes opciones: datos.
1.- Modificar datos personal 2.- Ofrece imágenes o da
2.- Foto de perfil. opción de subir.
3.- Cambiar contraseña 3.- Se pide ingresar
contraseña actual y
luego la nueva.
Excepciones -
Post- Luego de la confirmación de la acción se vuelve al menú
Condiciones

61
Caso de Uso Agregar Venta

Figura F.6: Caso de Uso Agregar Venta.

Caso de Uso Agregar Venta


Actor (es) Administrador
Requerimiento RF-1 Administrador
Precondiciones El Administrador debe previamente ingresar al sistema
Descripción Actor Respuesta Sistema
El Administrador al ingresar 1. Indexa al Administrador al
al sistema y elegir “Agregar formulario para guardar
Venta” tiene las siguientes venta
opciones: 1.1 Luego solicita ingreso de
1.- Agregar Cliente cliente asociado a venta y
2.- Confirmar Venta. productos.
2.1. se pide seleccionar 2 y 3. Se indexa al “Buscador de
producto de carta Ventas”
2.2 se pide seleccionar
cliente
Excepciones -
Post-Condiciones Luego de la confirmación de la acción se vuelve al menú

62
Caso de Uso Gestionar Comentarios

Figura F.7: Caso de Uso Gestionar Comentarios.

Caso de Uso Gestionar Comentarios


Actor (es) Administrador
Requerimiento RF-7 Administrador
Precondiciones El Administrador debe previamente ingresar al sistema
Descripción Actor Respuesta Sistema
El Administrador al ingresar 1. Indexa al Administrador a un
a la opción “Gestionar listado de notificaciones de
comentarios” tiene las comentarios hechos
siguientes opciones: (nuevos)
1.- Ver notificaciones. 1.1 Se da la opción de aprobar el
1.1 Aprobar comentario y publicarlo
1.2 Rechazar 1.2 Se da la opción de rechazar
2.-Ver comentarios el comentario y eliminarlo.
3.- Se muestran Todos los
comentarios publicados
Excepciones -
Post-Condiciones Luego de la confirmación de la acción se vuelve al menú

63
Caso de Uso Ver Reportes

Figura F.8: Caso de Uso Ver Reportes.

Caso de Uso Ver Reportes


Actor (es) Administrador
Requerimiento RF-6 Administrador
Precondiciones El Administrador debe previamente ingresar al sistema
Descripción Actor Respuesta Sistema
El Administrador al ingresar 1.1 y 2.1 indexan al
a la opción “Ver Reportes” Administrador a selección
tiene las siguientes opciones: de rango de fecha para
1.- Reportes por Cliente mostrar resultados.
Luego se solicita seleccionar las
2.-Reportes por Venta opciones de presentación de
resultados, es decir, orden
Luego se solicita ingresar decreciente, creciente, primeros
rango de fecha y orden 10, etc.
Excepciones -
Post-Condiciones Luego de la confirmación de la acción se vuelve al menú

64
Caso de Uso Gestionar Venta

Figura F.9: Caso de Uso Gestionar Venta.

Caso de Uso Gestionar Venta


Actor (es) Administrador
Requerimiento RF-1 Administrador
Precondiciones El Administrador debe previamente ingresar al sistema
Descripción Actor Respuesta Sistema
El Administrador al ingresar 1. Indexa al Administrador al
al sistema y elegir “Gestionar formulario para guardar
Venta” tiene las siguientes venta
opciones: 1.1 Luego solicita ingreso de
1.- Agregar Venta. cliente asociado a venta y
2.- Editar Venta. productos.
3.- Eliminar Venta. 2 y 3. Se indexa al “Buscador de
Ventas”
Excepciones -
Post-Condiciones Luego de la confirmación de la acción se vuelve al menú

65
Anexo G. Diseño
Diagramas de Secuencia

Figura G.1: Diagrama de Secuencia “Agregar Cliente”.

Agregar Cliente
Ver Clientes

Figura G.2: Diagrama de Secuencia “Agregar Cliente”.

66
Editar Perfil

Figura G.3: Diagrama de Secuencia “Editar Perfil”.

67
Ingresar Producto

Figura G.4: Diagrama de Secuencia “Ingresar Producto”.

68
Ver Reportes

Figura G.5: Diagrama de Secuencia “Ver Reportes”.

69
Ver Notificaciones Comentarios

Figura G.6: Diagrama de Secuencia “Ver Notificaciones Comentarios”.

70
Agregar Venta

Figura G.7: Diagrama de Secuencia “Agregar Venta”.

71
Compartir en Redes Sociales

Figura G.8: Diagrama de Secuencia “Compartir en Redes Sociales”.

72
Editar Cliente

Figura G.9: Diagrama de Secuencia “Editar Cliente”.

73
Editar Publicidad

Figura G.10: Diagrama de Secuencia “Editar Publicidad”.

74
Eliminar Producto

Figura G.11: Diagrama de Secuencia “Eliminar Producto”.

75
Eliminar Cliente

Figura G.12: Diagrama de secuencia “Eliminar Cliente”.

76
Eliminar Publicidad

Figura G.13: Diagrama de Secuencia “Eliminar Publicidad”.

77
Ingresar Publicidad

Figura G.14: Diagrama de Secuencia “Ingresar Publicidad”.

78
Hacer Comentario

Figura G.15: Diagrama de Secuencia “Hacer Comentario”.

79
Ver Comentarios

Figura G.16: Diagrama de Secuencia “Ver Comentarios”.

80
Ver Notificación Reservas

Figura G.17: Diagrama de Secuencia “Ver Notificación Reservas”.

81
Diccionario de Datos

Carta_productos
Nombre Tipo Dato P F N A Def Comentario
K K N I ault
id_productos INT ‫ݲ‬  ‫ݲ‬ ‫ݲ‬ Identificador de
cada producto
nombre VARCHAR  ‫ݲ‬
(45)
descripcion VARCHAR
(45)
precio INT  ‫ݲ‬ Costo para el
cliente
puntos INT  ‫ݲ‬ Puntos que gana
cliente al consumir
estado_web INT  ‫ݲ‬ indica si el
producto está expuesto
en la carta
id_tipo_prod INT ‫ݲ‬ ‫ݲ‬ Clave Foránea,
ucto hace referencia a tabla
tipo producto
Tabla G.1: Diccionario de Datos Tabla Carta_productos.

Comentarios
Nombre Tipo Dato P F N A Def Comentario
K K N I ault
id_coment INT ‫ݲ‬  ‫ݲ‬ ‫ݲ‬ Identificador de cada
ario comentario
cuerpo VARCHAR( Mensaje del
150) comentario
fecha DATE  ‫ݲ‬

id_publica INT ‫ݲ‬ ‫ݲ‬ ‫ݲ‬ Relación a la


cion publicación comentada
id_usuario INT ‫ݲ‬ ‫ݲ‬ ‫ݲ‬ Relación al usuario
que hace el comentario
Tabla G.2: Diccionario de Datos Tabla Comentarios.

82
Publicaciones

Nombre Tipo Dato P F N A Comentario


K K N I
id_publicidad INT ‫ݲ‬  ‫ݲ‬ ‫ݲ‬ Identificador de cada
publicación
titulo VARCHAR  ‫ݲ‬
(45)
contenido VARCHAR(  ‫ݲ‬ Cuerpo del mensaje de
150) publicidad
imagen VARCHAR(  ‫ݲ‬
45
fecha_vigencia DATETIME  ‫ݲ‬ Fecha terminó de valides

id_usuario INT ‫ݲ‬ ‫ݲ‬ ‫ݲ‬ Relación con que


administrador la publico
id_tipo_publica INT ‫ݲ‬ ‫ݲ‬ ‫ݲ‬ Relación con qué tipo de
cion publicación es

Tabla G.3: Diccionario de Datos Tabla Publicaciones.

Reservas
Nombre Tipo Dato P F N A Comentario
K K N I
id_reserva INT ‫ݲ‬  ‫ݲ‬ ‫ݲ‬ Identificador de cada
reserva
cantidad_perso INT  ‫ݲ‬
nas
fecha_realizaci DATETIME  ‫ݲ‬ Cuerpo del mensaje de
on publicidad
Fecha_reserva DATETIME  ‫ݲ‬

observacion VARCHAR(  ‫ݲ‬ Fecha terminó de valides


150)
id_usuario INT ‫ݲ‬ ‫ݲ‬ ‫ݲ‬ Relación a que cliente la
hace
id_estado_rese INT ‫ݲ‬ ‫ݲ‬ ‫ݲ‬ Relación a la tabla estado
rva de reserva.

Tabla G.4: Diccionario de Datos Tabla Reservas.

83
Estado_reserva
Nombre Tipo Dato P F N A Comentario
K K N I
id_estado_rese INT ‫ݲ‬  ‫ݲ‬ ‫ݲ‬ Identificador de cada reserva
rva
nombre_estad VARCHAR  ‫ݲ‬ Especifica el nombre del
o (25) estado de cada reserva
Tabla G.5: Diccionario de Datos Tabla Estado_reserva.

Tipo_publicaciones
Nombre Tipo Dato P F N A Comentario
K K N I
id_tipo_publica INT ‫ݲ‬  ‫ݲ‬ ‫ݲ‬ Identificador de cada
cion reserva
nombre_tipo VARCHAR  ‫ݲ‬ Especifica el nombre del
(25) tipo de publicación, noticia,
evento, promoción.
Tabla G.6: Diccionario de Datos Tabla Tipo_publicacion.

Tipo_productos
Nombre Tipo Dato P F N A Comentario
K K N I
id_tipo_prod INT ‫ݲ‬  ‫ݲ‬ ‫ݲ‬ Identificador de cada
ucto producto
nombre_tipo VARCHAR  ‫ݲ‬ Especifica el nombre del tipo
(25) de producto
Tabla G.7: Diccionario de Datos Tabla Tipo_productos.

84
Rel_carta_Ventas

Nombre Ti P F N A Def Comentario


po K K N I ault
Dato
id_producto IN ‫ݲ‬ ‫ݲ‬ ‫ݲ‬ Relación que identifica a
T algún producto de la tabla
Carta_producto
id_venta IN ‫ݲ‬ ‫ݲ‬ ‫ݲ‬ Relación que identifica a
T alguna venta de la tabla
Ventas
cantidad_prod IN   ‫ݲ‬
ucto T
Tabla G.8: Diccionario de Datos Tabla Rel_carta_ventas.

Ventas
Nombr Tipo Dato P F N A Def Comentario
e K K N I ault
id_venta INT ‫ݲ‬  ‫ݲ‬ Identificador de cada
venta
total INT ‫ݲ‬  ‫ݲ‬

mesa INT    Numero de mesa que se


atendió
fecha DATETIME   ‫ݲ‬ Fecha de venta

descuent INT   
o
observa VARCHAR(    Alguna aclaración que
cion 159) haya que hacer a la venta
id_usua INT  ‫ݲ‬ ‫ݲ‬ Relación al cliente
rio asociado a venta
Tabla G.9: Diccionario de Datos de Tabla Ventas.

85
Usuarios
Nombre Tipo Dato P F N A Comentario
K K N I
id_usuario INT ‫ݲ‬  ‫ݲ‬ ‫ݲ‬ Identificador de cada
usuario
nombre VARCHAR(  ‫ݲ‬
45)
apellido VARCHAR(   ‫ݲ‬
45)
email VARCHAR(4   ‫ݲ‬
5)
telefono INT   

domicilio VARCHAR(4   
5)
foto_perfil VARCHAR(4   
5)
puntos_acumula INT   ‫ݲ‬ Hace referencia los
dos puntos acumulados, por los
productos consumidos
nick_login VARCHAR(4   ‫ݲ‬
5)
password VARCHAR(4   ‫ݲ‬
5)
tipo_usuario INT   ‫ݲ‬ Clasificación de usuario,
es decir, administrador o
cliente
permiso INT   ‫ݲ‬ Clasificación entre los
administradores:
superadministrador,
administrador
fecha_alta DATETIME    Fecha de creación de
cuenta
ultimo_acceso DATETIME    Fecha del ultimo acceso
al sistema
Tabla G.10: Diccionario de Datos de Tabla Usuarios.

86
Anexo H. Pruebas de Usabilidad
Objetivo de la Prueba
El objetivo de la pruebas es probar las funcionalidades principales del sistema de
fidelización Capicua Restobar. Para el diseño de la prueba se tomó la cautela de realizar
algunas sub tareas indirectamente, es decir, que al realizar una de las tareas principales, los
pasos señaladas en esta involucraran algunas sub tareas, como por ejemplo, al realizar una
venta se debió elegir y buscar productos, así como también poder hacer algún descuento.
Para realizar cada una de las pruebas, se debió especificar los principales pasos al
usuario para cumplirla, para que así el usuario tenga todas la información necesaria para su
correcta realización y, en consecuencia, poder verificar la facilidad de uso del sistema.

Diseño de la Prueba
La preparación de la prueba de usabilidad, comenzó con una inspección del sitio web
capicúa-restobar.cl en donde se recorrieron todas las opciones que podía ejecutar el
Administrador/Usuario, basándonos en el criterio de encontrar errores frecuentes que posee la
página, lo que conllevaría errores en el uso y el tiempo de respuesta del usuario al enfrentarse
con las tareas que se podrán desglosar en base este análisis.
En primer lugar se decidió hacer prueba individuales para administrador y usuario,
para poder dividir los problemas que se daban a conocer en cada ámbito. En segundo lugar el
usuario de las pruebas leyó y firmo un acuerdo de confidencialidad en donde se les dan a
conocer en qué consistirá la prueba a la que se someterá. Luego de dicho acuerdo, se le
informó a través de un documento escrito al usuario, en qué consistía la prueba y cuál iba a ser
su trabajo a ser evaluado y bajo a qué condiciones. Además de estas indicaciones se le solicito
al usuario responder un pre-test de tan solo 3 preguntas.
También se definen 3 tareas descritas paso a paso, que debe realizar el usuario.

En el caso de la prueba de Administrador estas tareas son las siguientes:

x Tarea 1: Es poder ingresar al sitio www.capicua-restobar.cl luego poder ingresar al


portal en modo administrador, y realizar una venta con productos correspondientes y
asociados a algún cliente.
x Tarea 2: Es poder agregar un menú de productos.
x Tarea 3: Es poder agregar una publicación asociada al perfil de Facebook.
Las preguntas que conforman la parte de pre y post test que se realizaron a los
usuarios buscaron encontrar algunos problemas de usabilidad en el sitio, principalmente el
poder realizar una venta, tarea de gran importancia ya que es una de las principales. Otro tarea
critica era en la parte de agregar algún producto/menú al sistema ya que es parte de lo
principal para poder agregar una venta, además de dar a conocer estos a los clientes. Y otra
tarea es la de captación de clientes vía Facebook, en la cual son las publicaciones, las cuales se
muestran en el sistema así como en el perfil.

87
En el caso de la prueba de Usuario estas tareas son las siguientes:

x Tarea 1: Es poder ingresar al sitio www.capicua-restobar.cl luego poder registrarse en


el portal, ingresar y editar su perfil.
x Tarea 2: Es poder realizar una reserva en el restaurant.
x Tarea 3: Es poder agregar un comentario en alguna publicación del sistema.
Las preguntas que conforman la parte de pre y post test que se realizaron a los
usuarios buscaron encontrar algunos problemas de usabilidad en el sitio, principalmente el
poder acceder de manera fácil al portal como un cliente, poder revisar y editar los datos, así
como también poder realizar algunas acciones como poder hacer una reserva y poder comentar
publicaciones.

Selección de participantes
El principal criterio de selección se basó en los conocimientos en el manejo de
computadoras de los usuarios, para asegurarse de que no tuvieran problemas para ocupar el
computador y navegar por internet, porque si se evaluaba a usuario con poco conocimiento,
podía darse el caso de que aunque las tareas fueran muy fáciles, el usuario con poco
conocimientos no las haya podido realizar.

Análisis de Resultados
A la hora de definir las tareas que se le solicitaron realizar a los usuarios, se pensó en
las principales funcionalidades que ofrece el sitio capicua-restobar.cl a las personas que lo
visitan, estas son por parte de clientes: Registrarse y ver perfil, realizar reservas y hacer
comentarios a las publicaciones, así también como por parte del administrador: Realizar
ventas, Agregar menú y Realizar publicaciones.
Al analizar el sitio y sus principales funciones ofrecidas al Administrador, se pudo
descubrir que al corroborar el menú ingresado e intentar volver al panel de administración el
link no se era muy visible para los participantes. Como resultado de esta tarea de la prueba de
usabilidad de Administración, 4 de los 6 participantes no encontrar el link de panel de
administración, pasando mucho tiempo dando vueltas por el sitio buscando algún link, sin
encontrarlo. Se pudo observar un gran nivel de desagrado y de frustración por parte de los
participantes al no encontrar el link hacia el panel de administración, solo 3 de 6 participantes
pudo encontrar el link sin problemas, los 3 restantes tardaron en promedio 2 minutos en
encontrarlo.
Otro factor que se logró observar en el diseño de la página, es el hecho de la
utilización de botones con iconografía ayudo a guiar a los usuarios para poder realizar las
tareas, de los cuales 6 de 6 participantes accedió directamente de los botones principales.

88
Anexo I. Manual de Usuarios
Sistema Público - Sin Usuarios Registrados

Página inicio (índex)

El sistema público, permite ver en su página de inicio logotipo del restaurant, un


enlace a Facebook y Twitter respectivo de éste, a la parte superior izquierda da la opción de
ingresar a clientes registrados en el sistema, como también otorga la posibilidad de registrarse

89
a clientes nuevos que deseen pertenecer al sistema de fidelización. También se puede ver el
menú de navegación principal del sitio con enlaces a páginas como: Menús, Publicaciones,
Carta de productos y contacto.
El sistema en su página de inicio muestra 3 fotografías representativas del local, con
un mensaje, a continuación se ven las dos publicaciones más actualizadas realizadas por el
Administrador, al costado derecho de éstas, se encuentra un cuadro en donde se muestran los
comentarios de la red social Facebook realizados también por el Administrador, al pie de la
página se encuentra información básica de contacto y ubicación del restaurant.
Página Menús

En la página de menús se pueden observar todos los tipos de menús (categorías) en


distintas pestañas, y casa uno de los menús correspondientes a cada categoría, con su título,
descripción, precio, fecha de publicación e imagen del plato, en dicha imagen se puede hacer
clic para aumentarla de tamaño

90
Página Publicaciones

En la página Publicaciones, es posible observar todas la publicaciones ordenadas


desde la más actual a la más antigua de forma paginadas, se puede ver en cada una de ellas,
titulo, descripción, la fecha de publicación, la fecha de vigencia, el nombre del Administrador
que la publico, la categoría a la cual pertenece (evento, noticias, ofertas, etc.) al realizar clic
en el botón “Ver más” se ve la publicación con el número de comentarios que contiene, se
debe hacer clic en el número, para poder ver los comentarios, solo los usuarios registrar poden
realizar comentarios.

91
Página Carta de Productos

En la página de Carta de Productos, se observan todos los tipos de productos que


posee el restaurante por categorías, cada producto con su respectivo nombre, descripción,
precio y fotografía, la cual al hacer clic se puede observar en mayor tamaño.

92
Página Contáctenos

En la página Contáctenos, se puede observar un formulario de contacto, en donde


cualquier usuario perteneciente o no al sistema, puede enviar un mensaje al administrador del
restaurant, también se encuentra en esta página, el mapa donde se observa la ubicación exacta
del local, además de información de recinto, tal como días de la semana y horarios de
atención.

93
Sistema Perfil Administrador

El sistema en perfil de Administrador ofrece un sin número de tareas que se pueden


realizar, a continuación revisaremos cada una de ellas. Cabe destacar que este perfil está
disponible solo al momento de ingresar al sistema (email + contraseña).

Página Inicio Administrador

Una vez que el usuario Administrador ingresa el sistema lo re direcciona al panel del
Administrador, el cual posee en el centro de la página los botones de acceso directo, como
son: Agregar venta, Agregar cliente, Gestionar Menús, Gestionar Productos, Gestionar
Publicación, Ver reservas. También esta página posee un menú desplegable a l costado
izquierdo, en el cual se pueden acceder a tareas más específicas.

94
Agregar Venta

Al realizar una venta, es necesario:


1. Ingresar a Agregar Venta, esto derivara a una página en
donde se pueden ver todos los productos del restaurant,
este listado posee un buscado, también se puede
seleccionar el tipo de producto a listar, con el objetivo se
filtrar el listado y hacer más fácil la búsqueda del
producto
2. Luego se debe agregar el producto a la venta, esto se
hace presionando el botón “Agregar”, la cantidad del producto se puede ingresar de
dos formas, manual, ingresando el numero por teclado, o bien presionando el botón
agregar la cantidad deseada.

3. Una vez agregados toso los productos de la venta, se debe presionar “confirmar”, este
botón indexara a un formulario en donde se debe seleccionar al usuario que realiza la
venta, este formulario indica los puntos acumulados por el usuario, se debe indicar
algún tipo de descuento, existe la posibilidad de agregar algún comentario a la venta,
se debe indicar el número de mesa, para terminar solo se debe presionar “Agregar” y
la venta será registrada en el sistema.

95
Añadir Cliente
El administrador puede agregar un cliente, que no esté registrado en el sistema, esto
se realiza con tan solo 3 datos del cliente:
1. En primer lugar debe hacer clic en el botón Añadir Cliente,
en el panel del Administrador, este botón indexa a un
formulario pequeño en donde se piden datos como, nombre,
apellido y correo electrónico del cliente, luego se debe
presionar el botón agregar.

2. Una vez confirmado los datos del cliente en el formulario,


este quedara registrado en el sistema, el mismo sistema
enviara un mail, informándole al cliente que ha sido
registrado y se le indicara su clave de acceso personal a su
perfil.

Crear Menú
El administrador puede agregar menús nuevos si lo desea,
esto se hace accediendo al botón gestionar menús, el cual deriva a
un formulario.
1. Primero se debe ingresar el nombre del menú, luego su
descripción, se debe indicar el tipo de menú que se está
agregando, su precio, la fotografía respectiva y los puntos
respectivos del menú. Por último se debe confirmar el
nuevo menú presionando el botón “Agregar”.

2. Una vez confirmado, el nuevo menú será visible en la página “Menús” pública, para
ser vista por todo tipo de usuario que ingrese al sistema.

Crear Producto
El administrador también puede ingresar un nuevo
producto al sistema, esto se realiza accediendo al botón
Administrar productos. Lo cual deriva a un formulario similar al
de agregar menú:
1. Se debe ingresar nombre del producto, luego una
descripción, se debe seleccionar el tipo de producto, su
precio y los puntos respectivos del producto, por último se
debe seleccionar la foto de dicho producto, se finaliza
presionando “Agregar”.

2. Una vez confirmado el formulario, el producto nuevo recién ingresado estará visible en
la carta productos en la categoría en la que fue ingresado, para ser visto por todo tipo
de usuario del sistema.

96
Hacer Publicación
El sistema está relacionado a la red social Facebook, en cuanto a las publicaciones,
es por esto que al hacer clic en el botón agregar publicación, este lleva
una página que solicita identificarse en Facebook, este registrar debe
realizarse con los datos del Facebook del restaurant, una vez
completado el ingreso, se mostrara el formulario de publicación:
1. En primer lugar se debe ingresar el título de la publicación,
luego su descripción, la fecha nueva (fecha de vigencia de la
publicación) el tipo de publicación, y por último la imagen que
desea que aparezca en la publicación. Luego presionar
“Agregar”.

2. Una vez confirmado el formulario, la publicación aparecerá en la página principal del


sitio (índex), como también en la página de publicaciones, al mismo tiempo se
publicara en Facebook.
Ver Reservas
El administrador también puse revisar las reservas hechas por
los clientes registrados.
1. Hacer clic en el botón “Ver Reservas”, este botón re direccionara
a un listado con todas las reservas hechas, en donde se indica el
nombre del cliente, la cantidad de personas para la reserva, y las
fechas y lo más importante el “estado” de la reserva, este estado
puede ser de 3 tipos: Aceptada-Rechazada-Pendiente.

2. Al hacer clic en editar reserva, se enviara a un formulario más clarificador de los datos
de la reserva, en donde el administrador podrá modificar el estado de dicha reserva.

3. Una vez modificado el estado de la reserva el sistema envía un mail confirmando el


nuevo estado de su reserva, este nuevo estado será visible por el cliente que la solicito.

97
Menú panel izquierdo desplegable

™ El primer botón Inicio Administrador, direcciona al


panel del ministrador

™ La Segunda opción dice Gestión de Ventas, de la cual


se despliega:
¾ Agregar Venta, misma funcionalidad de botón de
agregar venta, de panel de administrador
¾ Listar Ventas, en esta opción se listan todas las
ventas paginadas, y se da la opción borrar.
x Borrar
Al presionar este botón, se borrara la venta de todo el sistema.
¾ Listar Ventas por Cliente, en esta opción se podrá acceder a ver todas las ventas de
un cliente específico.
1. Una vez seleccionada esta opción, de redirecciona a un filtro en donde
se debe seleccionar el nombre del usuario del cual se desean ver sus
ventas.
2. Una vez hecho el chic en aceptar, se listaran todas las ventas de dicho
cliente, en dicha página en la parte superior existe un botón Volver que
vuelve a la página del filtro para seleccionar otro cliente si lo desea.

98
™ La Tercera opción dice Gestión de Usuarios, de la cual se despliega:
¾ Agregar Cliente, misma funcionalidad de botón de
agregar cliente, de panel de administrador
¾ Ver Clientes, en esta opción se listan todos los
clientes registrados en el sistema de forma paginada,
y se dan las opciones de editar visibilidad.
x Editar Visibilidad
Al presionar esta opción, el sistema
modifica la visibilidad del usuario, la
cual puede ser Activo (el cliente es
visible en el sistema) o Desactivo (el
cliente esta desactivado en el sistema,
no se puede registrar ventas, hacer
comentarios ni ver perfil).
¾ Agregar Administrador opción solo permitida para Súper Administrador.
¾ Ver Administradores opción solo permitida para Súper Administrador.

™ La Cuarta opción dice Gestión Menú, de la cual se despliega:


¾ Crear un Menú, misma funcionalidad de botón de agregar menú, de panel de
administrador
¾ Listar Menús, en esta opción se listan todos los menús
de todas los tipos, y se dan dos opciones, editar y
borrar.
x Editar
Se muestra un formulario con los
datos actuales del menú, en donde mismo
se pueden editar, luego de presiona
“Agregar” y el menú será guardado con sus modificaciones.
x Borrar
Al presionar este botón, se borrara el menú de todo el sistema, no
será visto por ningún tipo de usuario del sistema.

™ La Quinta opción dice Gestión Productos, de la cual


se despliega:
¾ Crear un Producto, misma funcionalidad de
botón de agregar producto, de panel de
administrador
¾ Listar Producto, en esta opción se listan todos
los productos de todas los tipos, y se dan dos
opciones, editar y borrar.
x Editar
Se muestra un formulario con los datos actuales del producto, en
donde mismo se pueden editar, luego de presiona “Agregar” y el
producto será guardado con sus modificaciones.

99
x Borrar
Al presionar este botón, se borrara el producto de todo el sistema, no
será visto por ningún tipo de usuario del sistema.

™ La sexta opción dice Gestión de Publicaciones, de la cual


se despliega:
¾ Agregar Publicación, misma funcionalidad de botón
de agregar publicación, de panel de administrador
¾ Listar Publicación, en esta opción se listan todas las
publicaciones hechas en el sistema de forma paginada,
y se dan las opciones de editar y borrar.
x Editar
Se muestra un formulario con los datos actuales de la publicación, en
donde mismo se pueden editar, luego de presiona “Aceptar” y la
publicación será guardada con sus modificaciones.
x Borrar
Al presionar este botón, se borrara la publicación del sistema, no será
visto por ningún tipo de usuario del sistema.

™ La séptima opción dice Reportes, opción solo permitida para Súper Administrador
™ La octava opción dice Gestión Sistema, opción solo permitida para Súper Administrador

Sistema Perfil Súper Administrador

Súper Administrador es el usuario del


sistema, que posee mayor cantidad de permisos
dentro de éste, este tipo de usuario puede realzar
todas las actividades permitidas para
Administrador, más las que se nombran a
continuación:
Agregar Administrador
1. al ingresar en esta opción el Súper Administrador el sistema lo lleva a un
formulario en donde debe ingresar información básica sobre el nuevo
Administrador, tal como, nombre, apellido, email, y contraseña. Aquí también
se debe indicar que tipo de permiso o qué tipo de administrador será el nuevo
creado, el cual puede ser, Administrador o Súper Administrador.
2. Una vez aceptado el formulario, el sistema enviara un mail al nuevo
administrador indicándole su registro y contraseña para que pueda ingresar al
sistema.
Ver Administradores
1. En esta opción se muestra un listado con todos los administradores indicando
los datos y el tipo de permiso de cada uno. En esta página también existe en la
parte superior izquierda del listado, un botón directo a Agregar Administrador.

100
™ La opción dice Reportes, en esta opción el Súper Administrador puedo extraer varios
tipos de reportes como son:

i Ventas por clientes


i Usuarios más Activos (por venta)
i Usuarios más Activos (por publicación)
i 10 Productos más Vendidos
i 10 Productos menos Vendidos
i Publicaciones más comentadas

Todos los reportes pueden ser consultados sin rango de fechas, estos se generaran con
los registros históricos del sistema. Pero si lo desea puede ingresar un rango de fecha para
consultar.
Una vez presionado ejecutar, se mostrara el reporte consultado, en la parte superior
izquierda existe un botón con el nombre “Exportar pdf” el cual se utiliza para descargar en
forma de documento PDF el respectivo reporte.

101
™ La sexta opción dice Gestión Sistema, de la cual se despliega:
¾ Agregar Tipo Producto
1. Al ingresar en esta opción aparece un formulario donde se pide ingresar, nombre
del tipo producto, y luego se pide seleccionar si es tipo menú o no.
2. Una vez confirmado el formulario, el tipo producto será creado y será visible por
todos los tipos de usuarios del sistema.

¾ Listar Tipo Productos


1. Una vez seleccionada esta opción aparece una lista con todos los tipos de
productos, indicando si son tipo menú o no, también aparecen dos opciones:
x Editar visibilidad
Al presionar esta opción, el sistema modifica la visibilidad del tipo
producto, la cual puede ser Activo (el tipo producto es visible en el
sistema) o Desactivo (el tipo producto esta desactivado en el sistema,
oculto).
x Editar
Con esta opción se permite al súper administrador modificar el nombre
del tipo producto y si es menú o no.

¾ Agregar Tipo Publicación


1. Al ingresar en esta opción aparece un formulario donde se pide ingresar, nombre
del tipo de publicación.
2. Una vez confirmado el formulario, el tipo publicación será creado y será visible por
todos los administradores y podrán agregar publicaciones en esa categoría.

¾ Listar Tipo Publicación


2. Una vez seleccionada esta opción aparece una lista con todos los tipos de
publicaciones, indicando si están visibles o no. Además aparecen dos opciones:
x Editar visibilidad
Al presionar esta opción, el sistema modifica la visibilidad del tipo
publicación, la cual puede ser Activo (se muestran todas las publicaciones
de categoría) o Desactivo (no se muestran las publicaciones de dicha
categoría).
x Editar
Con esta opción se permite al súper administrador modificar el nombre
del tipo publicación.

¾ Enviar E-mail Masivos


Una vez seleccionada esta opción aparece un formulario donde se debe ingresar
el asunto y descripción (contenido) del mensaje a enviar, este mensaje será
enviado a todos los usuarios registrados del sistema.

102
Sistema Perfil Cliente Registrado

El sistema permite que nuevos usuarios puedan registrarse en él, esto para poder
acceder a los beneficios que significa, como son, acumular puntos, obtener descuentos,
promociones, poder acceder a la opción realizar reservas, etc.

Página Inicio Cliente

Una vez que el usuario Cliente ingresa el sistema lo re direcciona a la página de su


perfil, en la cual se puede ver su nombre, la imagen que posee como foto de perfil, los puntos
acumulados en compras hasta la fecha, la fecha en la que se registró (alta), su e-mail. Este
perfil también posee un menú lateral izquierda.
Menú Panel Izquierdo Cliente Desplegable

Este manu lateral, está compuesto por 4 opciones,


de las cuales se explicaran a continuación:
™ La primera opción “Inicio” direcciona a la página
de perfil del cliente, este donde este.
™ La segunda opción “Editar Perfil” le permite al
cliente modificar sus datos, como son nombre, foto,
etc.
™ La tercera opción “Reservas” se despliega y da 2
alternativas:
™ Hacer Reserva: en donde el cliente ingresa
los datos de la reserva en un formulario simple, y
se envía la reserva.

103
™ Estado Reservas: en esta opción el cliente puede revisar todas las reservas
realizadas por él, y en donde se indica el estado de las dichas reservas, cuyo
estado puede ser: Aceptada - Rechazad - En Espera

™ La última opción es “Ver Ventas” en donde el cliente podrá ver todas las ventas
realizadas por el con fecha, y detalle de la venta.

104

También podría gustarte