Analisis de Sistema 1 02-12-17

UNIVERSIDAD DE AQUINO BOLIVIA
FACULTAD DE CIENCIA Y TECNOLOGÍA
CARRERA DE INGENIERÍA DE SISTEMAS
ANÁLISIS DE SISTEMAS II
SISTEMA DE INFORMACIÓN PARA RESERVAS DE UN

RESTAURANTE
Integrantes:
Saavedra Alvarez Brian Ruddy
Segurondo Aramayo Erwin Humberto
28/03/2018
Santa Cruz – Bolivia

ÍNDICE GENERAL
CAPÍTULO # 1. DESCRIPCIÓN DEL PROYECTO ...................................................... 2

1.1. Situación técnica actual ....................................... Error! Bookmark not defined.
1.2. Descripción de los Problemas de la Situación Técnica Actual ............................ 4
1.3. Situación Deseada ................................................................................................. 5
1.4. Alcance................................................................................................................... 5
1.4.1Límite Espacial ...................................................................................................... 5
1.4.2. Límite Sustantivo ................................................................................................ 6
1.5. Objetivos ................................................................................................................ 8
1.5.1 Objetivo General .................................................................................................. 8
1.5.2. Objetivos Específicos .......................................................................................... 8
1.6. Justificación ............................................................................................................ 8
1.6.1. Justificación Personal .......................................................................................... 8
1.6.2 Justificación Social ............................................................................................... 9
1.7. Metodología............................................................................................................ 9
CAPÍTULO # 2 MARCO TEÓRICO REFERENCIAL .................................................. 10
2.1. Proyecto Sistema de Gestión de Pedidos ............................................................ 25
2.2. Proyecto Sistema de Información de Restaurante ............................................... 31
2.3. Restaurante: Prototipo de un Restaurante Digital ................................................ 37
CAPÍTULO # 3 MARCO TEÓRICO CONCEPTUAL .................................................. 44
3.1. Conceptos Sobre el Tema de Estudio .................... Error! Bookmark not defined.
3.2. Conceptos sobre Sistemas de Información de GestiónError! Bookmark not
defined.
3.3. Concepto sobre la Metodología .............................. Error! Bookmark not defined.
CAPÍTULO # 4 MODELADO DE NEGOCIO .............................................................. 52
4.1. Lista de Procesos ................................................................................................. 53
4.1.1. Proceso de Solicitar Reserva ............................................................................ 53
4.1.2. Proceso Cambio de Reserva ............................................................................. 54
4.1.3. Proceso de Cancelar Reserva ........................................................................... 55
4.1.4. Reserva Realizada ............................................................................................ 56
CAPÍTULO # 5 REQUISITOS ..................................................................................... 57
5.1. Lista de Requisitos ............................................................................................... 58
5.1.1. Identificación de Requerimiento ........................................................................ 58
5.2. Identificación de Actores ...................................................................................... 59
5.2.1. Encargado de Reserva ...................................................................................... 59
5.2.2 Encargado de Administrar .................................................................................. 59
5.3. Captura de Requisitos como Casos De Uso ........................................................ 60
5.3.1. Casos De Uso: Administrar Reserva ................................................................. 60
5.3.2 Casos de Uso: Administrar Clientes ................................................................... 60
5.3.3. Casos de Uso: Administrar Mesa ...................................................................... 61
5.3.4. Casos de Uso: Gestionar Reporte ..................................................................... 61
5.4. Estructura del Modelo de Casos de Uso .............................................................. 62
5.5. Modelo de Dominio .............................................................................................. 63
CAPÍTULO #6 ANÁLISIS ........................................................................................... 64
6.1. Análisis de la Arquitectura .................................................................................... 65
6.2. Arquitectura de Casos de Uso en función al modelo del análisis ......................... 66
6.2.1. Módulo: Reserva y Reporte. .............................................................................. 66
6.3 Realización de Casos de Usos-Análisis ................................................................ 67
6.3.1 Especificación de Casos De Uso ....................................................................... 69
6.4. Diagrama de Clases del Análisis .......................................................................... 77
ÍNDICE DE FIGURAS
Figura 1. Límite Sustantivo ....................................................................................................... 6

Figura 2. Contenido de RUP .................................................. Error! Bookmark not defined.
Figura 3. Interfaz Gestionar Mesa......................................................................................... 26
Figura 4. Interfaz Administrador ............................................................................................ 26
Figura 5. Interfaz Seleccionar Mesa ..................................................................................... 27
Figura 6. Interfaz Gestión de Pedidos .................................................................................. 27
Figura 7.Sistema Cerrado ...................................................... Error! Bookmark not defined.
Figura 8. Sistema Abierto ....................................................... Error! Bookmark not defined.
Figura 9.Caracteristicas de un sistema ................................ Error! Bookmark not defined.
Figura 10. RUP......................................................................... Error! Bookmark not defined.
Figura 11. Fases de RUP ....................................................... Error! Bookmark not defined.
Figura 12.Diagrama de Actividad - Proceso de solicitar reserva ..................................... 53
Figura 13.Diagrama de Actividad - Proceso cambio de reserva ...................................... 54
Figura 14.Diagrama de Actividad - Proceso de cancelar la reserva ............................... 55
Figura 15.Diagrama de Actividad - Reserva realizada ...................................................... 56
Figura 16. -Actor- Recepcionista ........................................................................................... 59
Figura 17. -Actor- Administrador ........................................................................................... 59
Figura 18.Diagrama de Casos de Uso ................................................................................. 62
Figura 19. Modelo De Dominio .............................................................................................. 63
Figura 20.Diagrama de Paquetes ......................................................................................... 65
Figura 21.Diagrama de Paquetes - Módulo de Reserva y Reporte................................. 66
Figura 22. Diagrama de Colaboración - Gestionar Cliente ............................................... 69
Figura 23. Diagrama de Colaboración - Gestionar Reserva............................................. 70
Figura 24. Diagrama de Colaboración - Gestionar Mesa .................................................. 71
Figura 25. Diagrama de Colaboración - Gestionar Reporte ............................................. 72
Figura 26. Diagrama de Clase del Análisis ......................................................................... 77
ÍNDICE DE TABLAS
Tabla 1. Lista De Requerimientos ......................................................................................... 58

Tabla 2. -Caso de Uso: Administrar Reserva ...................................................................... 60
Tabla 3. -Caso de Uso: Administrar Clientes ...................................................................... 60
Tabla 4. -Caso de Uso: Administrar Mesa ........................................................................... 61
Tabla 5. -Caso de Uso: Gestionar Reporte ......................................................................... 61
Tabla 6. Formato de Descripción de Procesos – Administrar Reserva .......................... 67
Tabla 7. Formato de Descripción de Procesos – Administrar Clientes. ......................... 67
Tabla 8.Formato de Descripción de Procesos – Administrar Mesas .............................. 68
Tabla 9. Formato de Descripción de Procesos – Gestionar Reporte............................. 68
Tabla 10. Especificación de Caso de Uso: Gestionar Cliente .......................................... 73
Tabla 11. Especificación de Caso de Uso: Gestionar Reserva ....................................... 74
Tabla 12. Especificación de Caso de Uso: Gestionar Mesa............................................. 75
Tabla 13. Especificación de Caso de Uso: Gestionar Reporte ........................................ 76
INTRDUCCIÓN
En el presente proyecto se desarrolló un sistema de información para un restaurante

basado específicamente en el área de reservas en la cual dicho restaurante no cuenta
con un software.
La situación habitual en un restaurante en cuanto a reserva, tiempo de espera entre
otros, no es la más ideal en la mayoría de los casos, lo que hace que resulte difícil dar
un buen servicio al cliente, sobre todo durante las horas de mayor ocupación del local.
Por mucho tiempo el proceso de reserva para el restaurante ha sido engorroso y
manual. Una reserva ineficiente conduce a pérdidas ya sea porque la recepcionista
escribió mal la hora o no sabía que mesas estaban disponibles y como último deja una
insatisfacción en los clientes.
Todo lo anteriormente explicado conlleva pérdidas económicas y de clientela que
pueden determinar el éxito o el fracaso del negocio. Es por eso que se propone diseñar
e implementar un sistema para mejorar el modo de reserva.
Para realizar el proyecto se utilizó la metodología unificada aplicando el ciclo de vida
RUP para lograr el objetivo, se analizó la evaluación del sistema actual de información
manual para poder determinar los problemas y determinar cuáles serán las
funcionalidades que tendrá el nuevo sistema de información, en este nuevo diseño se
implementó la herramienta de modelado (UML) para poder visualizar por medio de
diagramas el nuevo sistema de información.
1
CAPÍTULO # 1.
DESCRIPCIÓN DEL
PROYECTO
2
1.1. Descripción Técnica de la Situación Actual
San Ho se inicia en el año 2008 como un restaurante de comida china, que empezó
con número personal muy reducido, de 3 persona junto con el fundador Marco Suarez
y un prestigioso chef llamado Guillermo González Beristaín, ofreciendo un menú de
comida china, con una gran variedad de platos. A finales del 2010 el restaurante ofrece
una gran variedad de buffet.
El Restaurante San Ho que se encuentra en la Av. Cristóbal de Mendoza (2do anillo)
entre Alemania y Beni Calle Paquiao, al oeste de la ciudad de Santa Cruz de la Sierra,
este establecimiento consta con dos tipos de áreas, sociales y de reservas para la
comodidad de sus diferentes tipos de clientes. El Área social consta de diez mesas en
la cual cada mesa se le asigna seis sillas, el área de reserva consta de cinco mesas.
Para realizar la reserva en el restaurante la recepcionista se encarga de preguntar para
cuantas personas quiere la reserva. Por cada persona se cobra la suma de 30Bs.-, el
dinero anticipado será utilizado como saldo a favor para aplicar a la cuenta generada
por sus consumos ese día en el que realizó su visita. El restaurante no realiza cargos
adicionales por la reserva.
El restaurante proporciona una mesa con el número de sillas para realizar su reserva,
por ello es importante indicar que si el número de invitados es distintos al que acordó
con el personal de reserva el restaurante aplica la siguiente política: el cobro por el
número que acordaron en su reserva, pero si el número de personas es menor a lo
indicado, se realiza el pago por el número de personas registradas en la reserva.
Al realizar una reserva con anticipo, el cliente cuenta con una tolerancia de 30 minutos
contando a partir de la hora pactada que hizo en dicha reserva, en caso de que pasen
los 30 minutos, si el cliente no se presenta a la mesa reservada a su nombre podrá ser
utilizada por otros clientes en la lista de espera y por ende la mesa será cancelada.
El cliente tiene un plazo máximo de 48 horas previas a la fecha que acordó su reserva
para cancelar ya sea personalmente o mediante una llamada telefónica, y así devolver
el dinero que se entregó para la reserva de mesas y sillas. Pasadas las 48 horas el
cliente tiene la opción de cancelar la reserva, pero se le devuelve el 50% del dinero
total de la reserva, esto se informa al momento que el cliente este realizando la reserva.
3
1.2. Descripción de los Problemas Encontrados en la Situación Actual
Actualmente existen problemas que sufre San Ho, por no tener una tecnología
adecuada Eso provoca dificultades a la hora hacer una reserva, entre los problemas
tenemos los siguientes:
Cuando la reserva está escrita a mano surgen problemas, al reservar mesas que no
están disponibles, ya sea porque la recepcionista perdió la libreta donde anoto la
reserva o por ende no entiende lo que escribió en dicha libreta.
Uno de los problemas más habituales es que el cliente cancelo la reserva y no se anotó
en la libreta.
Otro problema es la falta de prioridad al cliente, el cliente frecuente que tiene que estar
respondiendo las mismas preguntas cada vez que hace una reserva.
También al llamar los clientes para confirmar la hora de la reserva existe el problema
que no están en lista y por tanto no hay reserva por falta de organizar las reservas
realizadas y de este modo el cliente llama molesto a cada cierto tiempo para preguntar
su reserva.
4
1.3. Descripción de la Situación Deseada
Para la solución al problema de reserva será implementar un sistema de información

esto nos permitirá manejar los datos de reserva, también facilitará cualquier cambio
que se desee, este sistema de información tendrá la inmediata cancelación de mesa si
el cliente tiene una demora de 30 minutos o más sin un aviso previo.
Para resolver el problema de los recepcionistas y mejorar la eficiencia se llevará a cabo
el funcionamiento de tabletas, teléfonos inteligentes, Pantallas táctiles.
Con unos dispositivos de estos se logrará mejorar la comunicación entre el
recepcionista y encargado de cocina donde le permita observar la confirmación de la
orden y que por el mismo dispositivo se muestre la notificación al recepcionista, una
vez que la orden ya esté lista para la entrega también que muestre el tiempo de puede
demorar el pedido. En tal caso que el pedido demore más del tiempo establecido se
informará al mesero e inmediatamente se procederá a informarle al cliente de la
situación y así ofrecer un mejor servicio al cliente.
1.4. Alcance
1.4.1. Límite Espacial
El sistema de información para reserva será desarrollado para el restaurante “San Ho”,
este se encuentra en la Av. Cristóbal de Mendoza (2do anillo) entre Alemania y Beni
Calle Paquiao, al oeste de la ciudad de Santa Cruz de la Sierra.
1.4.2. Límite Temporal
De 23 de agosto de 2017 hasta 20 de junio de 2018 se estudiará a profundidad el

problema del restaurante San Ho en base a entrevista, visitas, observaciones e
investigaciones.
De 23 de agosto de 2017 hasta 4 de abril de 2018 se construirán los diferentes modelos
arquitectónicos del sistema para el restaurante San Ho como ser: diagrama de
paquetes, diagrama de clases, diagrama de componentes, diagrama de caso de uso,
diagrama de actividad, diagrama de secuencia y diagrama de colaboración.
De 6 de abril de 2018 hasta 20 de junio de 2018 se codificará el sistema con el entorno
de desarrollo Microsoft Visual Studio y con el manejador de base de datos Microsoft
Sql Server.
5
1.4.3. Límite Sustantivo
Sistema de información
para la reserva de un
restaurante
Módulo de Reserva Módulo de Reporte Módulo de Seguridad
Realizar copia de
Gestionar Cliente Reporte de clientes
Seguridad
Gestionar Reserva Reporte de Reserva
Gestionar Mesa
Figura 1. Límite Sustantivo
6
Módulo de Reserva: Se clasifican en dos sub módulos: Gestionar Cliente, Gestionar
Reserva y Gestionar Mesa.
Gestionar Cliente: Solicita la reserva.
Gestionar Reserva: Se realizan la reserva en una determinada hora, que el cliente
solicite.
Gestionar Mesa: Solicita la mesa y comprueba si está ocupada o no.
Módulo de Reporte: Se clasifican en dos sub módulos: Reporte de Cliente y Reporte
de Reserva.
Reporte de Cliente: Mostrara la cantidad de cliente que ingresan por día, mes y año.
Reporte de Reserva: Mostrara las mesas más solicitas por los clientes.
Módulo de Seguridad: Consta de un sub módulo: Realizar copia de seguridad.
Realizar copia de seguridad: Donde se guardan datos de la reserva.
7
1.5. Objetivos
1.5.1 Objetivo General
Desarrollar un sistema información para la reserva de un restaurante

1.5.2. Objetivos Específicos
 Construir el modelo de negocios con diagramas de actividades en base a

entrevista, reuniones.
 Documentar lista de requerimientos realizar la captura de casos de uso y modelo
de dominio con los principios de UML.
 Realizar los modelos de análisis y diseño con diagrama de secuencia, diagrama
de colaboración, diagrama de paquetes.
 Codificar el sistema de información utilizando visual estudio 2015 con el lenguaje
C# y el manejador de base de datos Microsoft SQL Server.
 Documentar la implementación con diagramas de componentes.
 Realizar pruebas o testeos para que el programa funcione correctamente.
 Proveer asistencia y ayuda a los usuarios del sistema entregable.
1.6. Justificación
1.6.1. Justificación Técnica
El presente proyecto que se elabora para el restaurante San Ho reducirá tiempo en que
se realiza una reserva y permitirá al restaurante ordenarse en cuanto a la atención del
cliente y la reserva.
1.6.2. Justificación Personal
Es habitual que, en este tipo de restaurante, el proceso de reserva se realice de forma

que no deje satisfecho al cliente: ¿cuántas veces nos quejamos porque se tarda
demasiado tiempo en hacer la reserva? por el contrario, ¿aún no hemos decidido qué
elegir y el encargado de registrar la reserva ya está dispuesto a tomar nota?
Por eso se decidió hacer este sistema que se implementara en el restaurante “San Ho”
eliminara todo ese inconveniente ya mencionado antes.
Esta propuesta se presenta con la finalidad de brindar la facilidad, comodidad y
seguridad de realizar los procesos.
8
1.6.3. Justificación Social
Este sistema de información para la reserva puede ayudar a otros restaurantes a usar
la tecnología para así mejorar esa área de todos los restaurantes de Santa cruz de la
sierra.
1.7. Metodología
La metodología que servirá para el sistema de información será la “Unificada” con el

ciclo Proceso Unificado de Rational (RUP), la notación Lenguaje de Modelamiento
Unificado (UML) y las herramientas de desarrollo Microsoft Visual Studio y el manejador
de base de datos Microsoft Sql Server.
9
CAPÍTULO # 2
MARCO TEÓRICO
DEL PROYECTO
10
CAPÍTULO#2 MARCO TEÓRICO DEL PROYECTO
2.1. Arquitectura de implementación
Una arquitectura de implementación se crea asignando los bloques de construcción

lógicos de una aplicación (la arquitectura lógica) a un entorno informático físico de modo
que se cumplan los requisitos de calidad del servicio especificados en el escenario de
implementación. El escenario de implementación se traduce en una arquitectura de
implementación, como se muestra en la siguiente figura.
Conversión de un escenario de implementación en una arquitectura de implementación
Cliente servidor
La arquitectura cliente-servidor es un modelo de diseño de software en el que las tareas
se reparten entre los proveedores de recursos o servicios, llamados servidores, y los
demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el
servidor, quien le da respuesta. Esta idea también se puede aplicar a programas que
se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema
operativo multiusuario distribuido a través de una red de computadoras.
El concepto de cliente-servidor, refiere por lo tanto a un modelo de comunicación que
vincula a varios dispositivos informáticos a través de una red. El cliente, en este marco,
realiza peticiones de servicios al servidor, que se encarga de satisfacer dichos
requerimientos.
Con esta arquitectura, las tareas se distribuyen entre los servidores (que proveen los
servicios) y los clientes (que demandan dichos servicios). Dicho de otro modo: el cliente
le pide un recurso al servidor, que brinda una respuesta. repartir de la capacidad de
procesamiento. El servidor puede ejecutarse sobre más de un equipo y ser más de un
programa. De acuerdo a los servicios que brinda, se lo puede llamar servidor web,
servidor de correo o de otro modo. Es importante mencionar que gran parte de los
servicios de Internet obedecen a la arquitectura cliente servidor. El servidor web pone
a disposición del cliente los sitios web, a los cuales el cliente accede a través de su
navegador. El servidor, de esta manera, aloja los datos que el cliente solicita mediante
el navegador instalado en su computadora.
11
Entre las disposiciones más comunes del modelo cliente servidor se encuentran los
sistemas multicapa, según los cuales el servidor ofrece la ejecución de varios
programas para que varios ordenadores puedan solicitarlos según sus necesidades,
de manera que el nivel de distribución aumenta.
2.2. Arquitectura de desarrollo
es un conjunto de patrones que proporcionan un marco de referencia necesario para

guiar la construcción de un software, permitiendo a los programadores, analistas y todo
el conjunto de desarrolladores del software compartir una misma línea de trabajo y
cubrir todos los objetivos y restricciones de la aplicación. Es considerada el nivel más
alto en el diseño de la arquitectura de un sistema puesto que establecen la estructura,
funcionamiento e interacción entre las partes del software.
Capa de negocio
La capa lógica de negocios ocupa un lugar preeminente en la construcción de una
infraestructura de software, al permitir el crecimiento y la extensión de servicios para
todas las aplicaciones existentes y futuras.
La definición de los límites de cada capa nos permitirá definir correctamente la
colaboración que proporcionará cada una de ellas y descubriremos que la capa
intermedia es inevitablemente la lógica de negocios. Esto dará lugar a una
infraestructura robusta y lista para la extensión y el crecimiento como proveedora de
servicios.
Para la construcción de esta capa se emplearán los componentes tecnológicos más
adecuados en cada caso.
Capa de presentación
La programación por capas es un estilo de programación en el que el objetivo primordial
es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de
esto consiste en separar la capa de datos de la capa de presentación al usuario. La
12
ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios
niveles y, en caso de que sobrevenga algún cambio, sólo es necesario actuar sobre el
nivel requerido sin que sea necesario realizar modificaciones en el código de los
restantes niveles.
La capa de presentación es la que ve el usuario (también se la denomina "capa de
usuario"), presenta el sistema al usuario, le comunica la información y captura la
información del usuario en un mínimo proceso (realiza un filtrado previo para comprobar
que no hay errores de formato). 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" (comprensible y fácil de usar) para el usuario.
2.3. Metodología de desarrollo
Concepto sobre la Metodología

Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros
desarrolladores sino también para servir de apoyo en los procesos de análisis de un
problema. Con este objetivo se creó el Lenguaje Unificado de Modelado (UML: Unified
Modeling Language). UML se ha convertido en ese estándar tan ansiado para
representar y modelar la información con la que se trabaja en las fases de análisis y,
especialmente, de diseño.
El lenguaje UML comenzó a gestarse en octubre de 1994 [1], cuando Rumbaugh se
unió a la compañía Rational fundada por Booch (dos reputados investiga-dores en el
área de metodología del software). El objetivo de ambos era unificar dos métodos que
habían desarrollado: el método Booch y el OMT (Object Modelling Tool). El primer
borrador apareció en octubre de 1995. En esa misma época otro reputado investigador,
Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son
conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de
otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron
a la definición de la primera versión de UML.
Un diagrama es la representación gráfica de un conjunto de elementos con sus
relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para
poder representar correctamente un sistema, UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas. UML incluye los
siguientes diagramas:
• Diagrama de casos de uso.
• Diagrama de clases.
• Diagrama de objetos.
• Diagrama de secuencia.
• Diagrama de colaboración.
• Diagrama de estados.
• Diagrama de actividades.
13
• Diagrama de componentes.
• Diagrama de despliegue.
Los diagramas más interesantes (y los más usados) son los de casos de uso, clases
y secuencia, por lo que nos centraremos en éstos. Pare ello, se utilizará ejemplos de
un sistema de venta de entradas de cine por Internet.
El diagrama de casos de usos representa gráficamente los casos de uso que tiene un
sistema. Se define un caso de uso como cada interacción supuesta con el sistema a
desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo
lo que tiene que hacer un sistema y cómo. En la figura 3 se muestra un ejemplo de
casos de uso, donde se muestran tres actores (los clientes, los taquilleros y los jefes
de taquilla) y las operaciones que pueden realizar (sus roles).
El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste
es el diagrama más común a la hora de describir el diseño de los sistemas orientados
a objetos.
En el diagrama de secuencia se muestra la interacción de los objetos que componen
un sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 5
muestra la interacción de crear una nueva sala para un espectáculo.
El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar
el comportamiento dinámico del sistema están los de interacción, colaboración, estados
y actividades. Los diagramas de componentes y despliegue están enfocados a la
implementación del sistema.
UML y su función en el modelado y diseño orientados a objetos
Hay muchos paradigmas o modelos para la resolución de problemas en la informática,
que es el estudio de algoritmos y datos. Hay cuatro categorías de modelos para la
resolución de problemas: lenguajes imperativos, funcionales, declarativos y orientados
a objetos (OOP). En los lenguajes orientados a objetos, los algoritmos se expresan
definiendo 'objetos' y haciendo que los objetos interactúen entre sí. Esos objetos son
cosas que deben ser manipuladas y existen en el mundo real. Pueden ser edificios,
artefactos sobre un escritorio o seres humanos.
Los lenguajes orientados a objetos dominan el mundo de la programación porque
modelan los objetos del mundo real. UML es una combinación de varias notaciones
orientadas a objetos: diseño orientado a objetos, técnica de modelado de objetos e
ingeniería de software orientada a objetos.
UML usa las fortalezas de estos tres enfoques para presentar una metodología más
uniforme que sea más sencilla de usar. UML representa buenas prácticas para la
construcción y documentación de diferentes aspectos del modelado de sistemas de
software y de negocios.
OMG: Tiene un significado diferente
14
Según su sitio web, el Object Management Group® (OMG®) es un consorcio

internacional sin fines de lucro y de membresía abierta para estándares tecnológicos,
fundado en 1989. Los estándares de OMG son promovidos por proveedores, usuarios
finales, instituciones académicas y agencias gubernamentales. Los grupos de trabajo
de OMG desarrollan estándares de integración empresarial para una amplia gama de
tecnologías y una gama incluso más amplia de industrias. Los estándares de modelado
de OMG, incluidos UML y Model Driven Architecture® (MDA®), permiten un eficaz
diseño visual, ejecución y mantenimiento de software y otros procesos.
OMG supervisa la definición y el mantenimiento de las especificaciones de UML. Esta
supervisión ofrece a los ingenieros y programadores la capacidad de usar un lenguaje
para muchos propósitos durante todas las etapas del ciclo de vida del software en
sistemas de cualquier tamaño.
La finalidad de UML según OMG
El OMG define los propósitos de UML de la siguiente manera:
• Brindar a arquitectos de sistemas, ingenieros y desarrolladores de software las
herramientas para el análisis, el diseño y la implementación de sistemas basados en
software, así como para el modelado de procesos de negocios y similares.
• Hacer progresar el estado de la industria permitiendo la interoperabilidad de
herramientas de modelado visual de objetos. No obstante, para habilitar un intercambio
significativo de información de modelos entre herramientas, se requiere de un acuerdo
con respecto a la semántica y notación.
UML cumple con los siguientes requerimientos:
• Establecer una definición formal de un metamodelo común basado en el
estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del UML. La
sintaxis abstracta define el conjunto de conceptos de modelado UML, sus atributos y
sus relaciones, así como las reglas de combinación de estos conceptos para construir
modelos UML parciales o completos.
• Brindar una explicación detallada de la semántica de cada concepto de
modelado UML. La semántica define, de manera independiente a la tecnología, cómo
los conceptos UML se habrán de desarrollar por las computadoras.
• Especificar los elementos de notación de lectura humana para representar los
conceptos individuales de modelado UML, así como las reglas para combinarlos en una
variedad de diferentes tipos de diagramas que corresponden a diferentes aspectos de
los sistemas modelados.
• Definir formas que permitan hacer que las herramientas UML cumplan con esta
especificación. Esto se apoya (en una especificación independiente) con una
especificación basada en XML de formatos de intercambio de modelos
correspondientes (XMI) que deben ser concretados por herramientas compatibles.
UML y el modelado de datos
15
El UML es popular entre programadores, pero no suele ser usado por desarrolladores
de bases de datos. Una razón es sencillamente que los creadores de UML no se
enfocaron en las bases de datos. A pesar de ello, el UML es efectivo para el modelado
de alto nivel de datos conceptuales y se puede usar en diferentes tipos de diagramas
UML. Puedes encontrar información sobre la multidimensionalidad de un modelo de
clases orientado a objetos en una base de datos relacional en este artículo sobre
Modelado de bases de datos en UML.
Actualizaciones en UML 2.0
El UML se perfecciona continuamente. UML 2.0 extiende las especificaciones de UML
para cubrir más aspectos de desarrollo, incluido Agile. La meta era reestructurar y
perfeccionar UML de forma que la facilidad de uso, la implementación y la adaptación
se simplificaran. Estas son algunas de las actualizaciones de los diagramas UML:
• Mayor integración entre modelos estructurales y de comportamiento.
• Capacidad de definir jerarquía y desglosar un sistema de software en
componentes y subcomponentes.
• UML 2.0 eleva el número de diagramas de 9 a 13.
Familiarízate con el vocabulario de UML, con esta lista extraída del documento UML
2.4.1, cuya finalidad es ayudar a quienes no son miembros de OMG a entender los
términos comúnmente usados.
• Compatibilidad con sintaxis abstracta Los usuarios pueden mover modelos a
través de diferentes herramientas, incluso si usan diferentes notaciones.
• Metamodelo de almacén común (CWM) Interfaces estándares que se usan para
permitir el intercambio de metadatos de almacén e inteligencia de negocios entre
herramientas de almacén, plataformas de almacén y repositorios de metadatos de
almacén en entornos heterogéneos distribuidos.
• Compatibilidad con sintaxis concreta Los usuarios pueden continuar usando una
notación con la que estén familiarizados a través de diferentes herramientas.
• Núcleo En el contexto de UML, el núcleo comúnmente se refiere al "paquete
central", que es un metamodelo completo particularmente diseñado para una alta
reutilización.
• Unidad de lenguaje Consiste en una colección de conceptos de modelado
estrechamente vinculados que proporciona a los usuarios la capacidad de representar
aspectos del sistema en estudio según un paradigma o formalismo en particular.
• Nivel 0 (L0) Nivel de cumplimiento inferior para la infraestructura UML - una sola
unidad de lenguaje que hace posible el modelado de tipos de estructuras basadas en
clases que se encuentran en los lenguajes más populares de programación orientados
a objetos.
• Meta Object Facility (MOF) Una especificación de modelado de OMG que brinda
la base para las definiciones de metamodelos en la familia de lenguajes MDA de OMG.
16
• Metamodelo Define el lenguaje y los procesos a partir de los cuales formar un

modelo.
• Construcciones de metamodelos (LM) Segundo nivel de cumplimiento en la
infraestructura UML - una unidad adicional de lenguaje para estructuras más
avanzadas basadas en clases, usadas para construir metamodelos (por medio de
CMOF), tales como el UML mismo. UML solo tiene dos niveles de cumplimiento.
• Arquitectura dirigida por modelos (MDA) Un enfoque y un plan para lograr un
conjunto coherente de especificaciones de tecnología dirigida por modelos.
• Lenguaje de restricciones para objetos (OCL) Un lenguaje declarativo para
describir reglas que se aplican al Lenguaje Unificado de Modelado. OCL complementa
a UML proporcionando términos y símbolos de diagramas de flujo que son más precisos
que el lenguaje natural, pero menos difíciles de dominar que las matemáticas.
• Object Management Group (OMG) Es un consorcio sin fines de lucro de
especificaciones para la industria de la computación, cuyos miembros definen y
mantienen la especificación UML.
• UML 1 Primera versión del Lenguaje Unificado de Modelado.
• Lenguaje Unificado de Modelado (UML) Un lenguaje visual para especificar,
construir y documentar los artefactos de los sistemas.
• XMI Una especificación basada en XML de formatos de intercambio de modelos
correspondientes.
Conceptos de modelado especificados por UML
El desarrollo de sistemas se centra en tres modelos generales de sistemas
diferentes:
• Funcionales: Se trata de diagramas de casos de uso que describen la
funcionalidad del sistema desde el punto de vista del usuario.
• De objetos: Se trata de diagramas de clases que describen la estructura del
sistema en términos de objetos, atributos, asociaciones y operaciones.
• Dinámicos: Los diagramas de interacción, los diagramas de máquina de estados
y los diagramas de actividades se usan para describir el comportamiento interno del
sistema.
Estos modelos de sistemas se visualizan a través de dos tipos diferentes de diagramas:
estructurales y de comportamiento.
Conceptos orientados a objetos en UML
Los objetos en UML son entidades del mundo real que existen a nuestro alrededor. En
el desarrollo de software, los objetos se pueden usar para describir, o modelar, el
sistema que se está creando en términos que sean pertinentes para el dominio. Los
objetos también permiten la descomposición de sistemas complejos en componentes
comprensibles que permiten que se construya una pieza a la vez.
17
Estos son algunos conceptos fundamentales de un mundo orientado a objetos:

• Objetos Representan una entidad y el componente básico.
• Clase Plano de un objeto.
• Abstracción Comportamiento de una entidad del mundo real.
• Encapsulación Mecanismo para enlazar los datos y ocultarlos del mundo
exterior.
• Herencia Mecanismo para crear nuevas clases a partir de una existente.
• Polimorfismo Define el mecanismo para salidas en diferentes formas.
Metodología RUP
La metodología RUP, abreviatura de Rational Unified Process (o Proceso Unificado
Racional), es un proceso propietario de la ingeniería de software creado por Rational
Software, adquirida por IBM, ganando un nuevo nombre Irup que ahora es una
abreviatura Rational Unified Process y lo que es una marca en el área de software,
proporcionando técnicas que deben seguir los miembros del equipo de desarrollo de
software con el fin de aumentar su productividad en el proceso de desarrollo.
La metodología RUP utiliza el enfoque de la orientación a objetos en su diseño y

está diseñado y documentado el uso de la notación UML (Unified Modeling Language
) para ilustrar los procesos en acción. Utiliza técnicas y prácticas probadas
comercialmente.
Es un proceso considerado pesado y preferentemente aplicable a grandes equipos
de desarrollo y grandes proyectos, pero el hecho de que es ampliamente personalizable
que permite adaptarse a proyectos de cualquier escala.
18
Para la gestión del proyecto, la metodología RUP proporciona una solución

disciplinada como las tareas y responsabilidades señaladas dentro de una organización
de desarrollo de software.
RUP es, en sí, un producto de software. Es modular y automatizado, y toda su
metodología se apoya en varias herramientas de desarrollo integradas y vendidos por
IBM a través de sus “Suites racional.”
Los métodos de la competencia en el campo de la ingeniería de software incluyen”
salas blancas” (considerado pesado) y ágil (luz) como Extreme Programming
(Programación XP-Extreme), Scrum, FDD y otros.
El uso de modelos visuales de software en la metodología RUP

Al abstraer la programación de su código y representarla utilizando bloques de
construcción gráficas, RUP puede una manera eficaz de conseguir una visión general
de una solución.
El uso de modelos visuales también puede permitir que los individuos menos perfil
técnico (como clientes) tienen una mejor comprensión de un problema dado, y así estar
más involucrados en el proyecto en su conjunto.
El lenguaje de modelado UML se ha convertido en un estándar de la industria para
representar los proyectos, y es ampliamente utilizado por RUP
Comprobar la calidad del software
No asegura la calidad del software es el fallo más común en todos los proyectos de
sistemas informáticos. Por lo general, uno piensa en la calidad del software después
de la finalización de los proyectos, o la calidad es la responsabilidad de un equipo de
desarrollo de equipo diferente.
RUP tiene como objetivo ayudar en el control de la planificación de la calidad,
comprobando que en la construcción de todo el proceso y la participación de todos los
miembros del equipo de desarrollo.
Software de gestión y de cambio de control
En todos los proyectos de software de la existencia del cambio es inevitable. RUP
define métodos para controlar y vigilar los cambios. Como un pequeño cambio puede
afectar a las aplicaciones de maneras totalmente impredecibles, el control de cambio
es esencial para el éxito de un proyecto.
RUP también define las áreas de trabajo y seguridad, lo que garantiza un
programador que cambia en otro sistema no afectará a su sistema.
Fases de la metodología RUP
Hasta ahora estas líneas guía son generales, para ser adherido a pasar por la vida
de un ciclo de proyecto. Las fases (ver figura abajo) indican el énfasis se da en el
19
proyecto en un instante dado. Para capturar la dimensión temporal de un proyecto, RUP

divide el proyecto en cuatro fases diferentes:
• Iniciación o Diseño: énfasis en el alcance del sistema;

• Preparación: énfasis en la arquitectura;
• Construcción: énfasis en el desarrollo;
• Transición: énfasis en la aplicación.
• RUP se basa también en las 4 Ps:
• Personas
• Diseño
• Producto
• Proceso
Las capas se componen de iteraciones. Iteraciones son ventanas de tiempo;

iteraciones han definido término como las fases son objetivos.
Todas las fases generan artefactos. Estos serán utilizados en la siguiente fase y
documentar el proyecto y permite un mejor seguimiento.
Fase de diseño
La fase de diseño o de iniciación contiene los flujos de trabajo necesarios para el
acuerdo de las partes interesadas – interesados – con los objetivos, la arquitectura y la
planificación del proyecto. Si estos actores tienen un buen conocimiento, no será
necesario analizar. De lo contrario, se requiere un análisis más elaborado.
En esta etapa, los requisitos esenciales del sistema se transforman en los casos de
uso. El objetivo no es para cerrarlas en absoluto, sino sólo las que sean necesarias
para dar forma a la opinión.
El paso es generalmente corto y se utiliza para definir si es factible para continuar
con el proyecto y definir los riesgos y el coste de la última. Un prototipo se puede hacer
para que el cliente apruebe. Como cita el RUP, lo ideal es realizar iteraciones, las
cuales deben estar bien definida en cuanto a su importe y objetivos.
Fase de elaboración
La preparación será para el diseño del sistema, como complemento de la encuesta
y / o documentación de casos de uso, frente a la arquitectura del sistema, revisar el
modelo de negocio para el proyecto e iniciar la versión del manual del usuario. Uno
debe aceptar:
20
Descripción del producto (aumento + integración) es estable; ¿El plan del proyecto
es fiable?; Los costos son elegibles?
Fase de construcción
En la fase de construcción, el desarrollo físico del software se inicia, códigos de
producción, pruebas alfa. pruebas beta se llevaron a cabo al inicio de la fase de
transición.
Se debe aceptar las pruebas, procesos estables y de prueba, y el código del sistema
son “línea de base”.
Fase de transición
En esta fase es la entrega (“despliegue”) de software, que se lleva a cabo el plan de
despliegue y entrega, el seguimiento y la calidad del software. Productos
(lanzamientos, las versiones) se van a entregar, y coloque la satisfacción del cliente.
Esta etapa también se lleva a cabo la formación de los usuarios.
Disciplinas de la metodología rup
Seis disciplinas de ingeniería de software
La disciplina modelada de negocio
Las organizaciones dependen cada vez más de los sistemas de TI, por lo que es
imperativo que los ingenieros de sistemas de información saben cómo se integran las
aplicaciones en el desarrollo de la organización. Las empresas invierten en TI, que
entienden la ventaja competitiva del valor añadido por la tecnología.
El objetivo de modelado de negocio es establecer primero una mejor comprensión y
comunicación entre ingeniería de negocios y la ingeniería de software.
Comprender el negocio significa que los ingenieros de software deben entender la
estructura y la dinámica de la empresa objetivo (el cliente), los problemas actuales de
la organización y las posibles mejoras. También deben asegurar una comprensión
común de la organización de destino entre los clientes, usuarios finales y
desarrolladores.
El modelado de negocios explica cómo describir la visión de una organización en la
que se implementará el sistema y cómo utilizar esta visión como base para describir
los procesos, funciones y responsabilidades.
Requisitos del curso
Este curso explica cómo al llegar peticiones de las partes interesadas (“partes
interesadas”) y los convierten en un conjunto de requisitos que los productos funcionan
dentro del sistema que se construirán y proporcionar los requisitos detallados para lo
que es necesario que el sistema.
Análisis y diseño de la disciplina (“diseño”)
El propósito del análisis y diseño es mostrar cómo se llevará a cabo el sistema. El
objetivo es construir un sistema que:
21
Ejecutar en un entorno de ejecución específica, las tareas y las funciones

especificadas en las descripciones de casos de uso
Satisfacer todas sus necesidades
Es fácil de mantener cuando no son cambios en los requisitos funcionales, los
resultados del proyecto en un modelo de análisis y diseño tiene opcionalmente un
modelo de análisis. El modelo de diseño sirve como una abstracción del código fuente,
es decir, el proyecto sirve como modelo de “retroalimentación” de la forma en que el
código fuente está estructurado y escrito.
El modelo de diseño consta de clases de diseño estructurados en paquetes y
subsistemas con interfaces bien definidas, en representación de lo que se convertirá
componentes de la aplicación. También contiene descripciones de cómo los objetos de
estas clases colaboran para llevar a cabo el diseño de casos de uso.
La disciplina implementación
Los efectos de la aplicación son:
Para configurar el código de la organización en términos de subsistemas de
aplicación organizados en capas
Para llevar a cabo las clases y objetos en términos de componentes (archivos de
código fuente, binarios, ejecutables, etc.)
Para probar los componentes desarrollados como unidades
Incorporar los resultados producidos por los ejecutores individuales (o equipos), en
un sistema ejecutable
Los sistemas se logran a través de los componentes de la aplicación. El proceso
describe cómo reutilizar componentes existentes o implementar nuevos componentes
con responsabilidades bien definidas, haciendo que el sistema sea más fácil de
mantener y aumentar las posibilidades de reutilización.
Prueba de disciplina
Los fines de disciplina prueba son:
• Comprobar la interacción entre los objetos.
• Comprobar la correcta integración de todos los componentes de software.
• Compruebe que todos los requisitos han sido ejecutados correctamente.
• Identificar y asegurar que los defectos se tratan antes de la implementación de
software.
• Asegúrese de que todos los defectos son corregidos, revisados y cerrados.
22
El Rational Unified Process propone un enfoque iterativo, lo que significa que debería
estar probando el proyecto en su totalidad. Esto le permite encontrar defectos tan
pronto como sea posible, lo que reduce drásticamente el costo de reparar el defecto.
Las pruebas se realizan a lo largo de cuatro dimensiones de la calidad: fiabilidad,
funcionalidad, rendimiento de las aplicaciones y el rendimiento del sistema. Para cada
una de estas dimensiones de la calidad, el proceso se describe cómo a pasar la prueba
de la planificación, diseño, implementación, ejecución y evaluación
23
CAPÍTULO # 3
MARCO TEÓRICO
REFERENCIAL
24
CAPITULO # 3 MARCO TEÓRICO REFERENCIAL
3.1. Proyecto Sistema de Gestión de Pedidos
Resumen
La situación habitual en un restaurante en cuanto a pedidos, tiempo de espera,

facturación correcta, entre otros, no es la más ideal en la mayoría de los casos, lo que
hace que resulte difícil dar un buen servicio al cliente, sobre todo durante las horas de
mayor ocupación del local. Los recursos con los que se cuentan en un local de este tipo
(restaurante, bar, etc.) son escasos, y esto obliga al personal del restaurante a tener que
desplazarse un gran un número de veces de un lugar a otro para poder cumplir con su
labor, ocasionando deficiencias en el servicio, olvido de órdenes, retardos, y
equivocaciones en los pedidos debido a que el sistema que se utiliza es manual. Todo lo
anteriormente explicado conlleva pérdidas económicas y de clientela que pueden
determinar el éxito o fracaso del negocio.
Es por eso que se propone diseñar e implementar un sistema que brinde flexibilidad
gracias al uso de terminales táctiles en cada una de las mesas, las cuales aumentarán la
participación del cliente, otorgará flexibilidad por medio de sus módulos configurables,
ofrecerá información precisa garantizada por la aplicación, llevará a cabo el control de
usuarios, la integración de los procesos del negocio por medio de los distintos módulos
del sistema, optimización de los mismos debido a que el sistema reduce el tiempo de
ejecución de los procesos y usabilidad.
En el actual ámbito de desarrollo, el sistema será implementado y testeado sin la

utilización de terminales táctiles (debido a su falta de disponibilidad). Se asumen
terminales con dispositivos de tipo ratón. De esta forma, es posible el desarrollo de la
funcionalidad completa del software, previniendo que el cambio a pantallas táctiles sea
mínimo.
Objetivo y alcance previsto
Automatizar la gestión de pedidos de una empresa relacionada con el sector de la

restauración. Para esto se desarrollará una aplicación Web que permita gestionar la
información sobre pedidos, como así también información relacionada a los usuarios
registrados. Lograr una mayor participación del cliente a la hora de realizar pedidos,
consiguiendo mejorar el tiempo del proceso de gestión de los mismos.
También manejará información referente a los productos ofrecidos, y permitirá realizar
parte de la facturación de la empresa.
Situación del estudio
El proyecto está pensado para restaurantes que no dispongan de un sistema

automatizado para la gestión de sus pedidos.
25
Después de haber analizado distintas necesidades de restaurantes que no disponen de

ningún sistema automatizado de gestión, a continuación, se exponen las necesidades de
mejora más importantes de dichos sistemas:
 Gestión de pedidos.
 Control de productos ofertados.
 Control de cuentas parcial.
Se ha implementado toda la funcionalidad que se ha propuesto anteriormente. Las más

características según los roles de los usuarios son:
 Administrador: Gestión de productos, mesas y facturas.

 Camarero: Modificar pedidos.
 Cocinero: Modificar estado del producto pedidos.
 Cliente: Realizar pedidos y pagar facturas.
Figura 2. Interfaz Gestionar Mesa
Figura 3. Interfaz Administrador
26
Figura 4. Interfaz Seleccionar Mesa
Figura 5. Interfaz Gestión de Pedidos
27
Justificación
Es habitual que en este tipo de empresas (restaurantes, bares, taparías, etc.), el proceso
de atención al cliente se realice de forma que no deje satisfecho al cliente: ¿cuántas veces
nos quejamos porque se tarda demasiado tiempo en ser atendidos?, o por el contrario,
¿aún no hemos decidido qué elegir y el encargado de registrar los pedidos ya está
dispuesto a tomar nota? Las ventajas que obtendrá la empresa con la utilización de un
sistema que automatice la gestión de pedidos son múltiples. Las más importantes se
pueden resumir en:
 Mejorar la atención al cliente: el cliente podrá pedir cualquier producto cuando él lo
deseé, sin depender de la disponibilidad de otra persona (camarero).
 El sistema realizará la gestión de una parte del manejo económico de la empresa
cada pago de un pedido se registrará, permitiendo conocer cuánto dinero ha de haber en
la caja, al final del día, del mes o durante un determinado periodo de tiempo. SGP Sistema
de Gestión de Pedidos 12
 Ahorrar en personal, ya que la automatización de procesos, hace que intervengan
menos personas, y que se puedan dedicar a otros procesos internos.
 Colaborar con el medio ambiente ahorrando en papel, ya que cada vez que se
necesite actualizar la carta con los productos ofertados, no hará falta volver a imprimir
nuevas cartas.
 Realizar estadísticas y estudios, ya que se dispondrá de información almacenada en
la base de datos, relacionada a los pedidos realizados por los clientes. Las desventajas
que obtendrá la empresa con la utilización de un sistema que automatice las gestiones
de pedidos son muy pocas. Las más importantes se pueden resumir:
 Inversión inicial, ya que, al ser un sistema desarrollado a medida, supone un coste
más amplio.
 Hardware, dependiendo del que se disponga, hay que hacer una inversión económica
mayor o menor. Automatizar un sistema o procesos conlleva a una serie de ventajas y
desventajas. Como hemos demostrado, en este caso las ventajas son mayores que las
desventajas, por lo que realizar esta automatización tendrá como resultado un beneficio
con respecto al sistema sin automatizar. SGP: Sistema
ESTUDIO DE VIABILIDAD
Introducción El objetivo del estudio de viabilidad es el análisis de un conjunto concreto de
necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones
económicas, técnicas, legales y operativas. El estudio de viabilidad se orientará a la
especificación de requisitos ya que costos, riesgos, problemas legales, etc., están fuera
de este proyecto. Durante el desarrollo de este capítulo se analizará el alcance de la
necesidad planteada y se identifican las restricciones relativas a la sincronización con
otros procesos, que puedan interferir en la planificación y futura puesta a punto del
sistema objeto de estudio. Esta información se recoge en el apartado de requisitos.
Objeto
Situación del estudio
28
El proyecto está pensado para restaurantes que no dispongan de un sistema

automatizado para la gestión de sus pedidos. Después de haber analizado distintas
necesidades de restaurantes que no disponen de ningún sistema automatizado de
gestión, a continuación, se exponen las necesidades de mejora más importantes de
dichos sistemas:
 Gestión de pedidos.
 Control de productos ofertados.
 Control de cuentas parcial.
Perfil de los usuarios del proyecto
Como se explicará en el capítulo 3, existen distintos tipos de usuarios, para los cuales el
sistema ofrecerá un conjunto de funcionalidades específicas. Independientemente del
tipo de usuario, el sistema será desarrollado con el objetivo de que sea fácil de utilizar,
intuitivo y que no se requiera conocimiento previo por parte de los usuarios, para que sea
accesible a cualquier tipo de persona, tenga conocimientos de las nuevas tecnologías o
no.
Recursos
Recursos de desarrollo Requisitos mínimos para el desarrollo de la aplicación.
 Hardware: o PC/MAC 2.0 GHz, 1Gb memoria RAM, 100Gb de disco duro.
 Conexión a internet: 1Mb
 Software: o Servidor Web: Apache.
 Entorno de desarrollo: Eclipse for php developers.
 Base de datos: MySQL. SGP: Sistema de Gestión de Pedidos 15
 Editor de base de datos: phpMyAdmin.
 Programación web: PHP, HTML, AJAX, jQuery.
 Sistema Operativo: Windows XP/Linux/MAC OS
 Navegador: Mozilla Firefox/Google Chrome/Opera
 Documentación del proyecto: Open Office
Recursos de implementación
Requisitos mínimos para la implementación de la aplicación.
 Servidor
 Servidor LAMP (Linux, Apache, MySQL, PHP), 1Gb memoria RAM, 1 GB
de disco duro.
 Hardware del terminal del administrador/cocina/personal
 PC/MAC 2.0 GHz, 1Gb memoria RAM, 1 Gb de disco duro.
 Software del terminal del administrador/cocina/personal
 Navegador: Mozilla Firefox/Google Chrome/Opera
 Hardware del terminal del cliente
29
 PC/MAC 2.0 GHz, 1Gb memoria, 1 Gb de disco duro.

 Monitor LCD chasis de pantalla táctil 3M MicroTouch 15”.
 Ratón, en caso de no disponer pantalla táctil.
 Software del terminal del cliente o Navegador: Mozilla Firefox/Google
Chrome/Opera
Modelo de desarrollo
Se ha elegido el modelo de desarrollo evolutivo, que es una metodología de desarrollo de
software muy relacionada con, pero claramente distinta de, desarrollo por prototipos. El
énfasis está puesto sobre la importancia de obtener un sistema de producción flexible y
expandible. Así, si los requerimientos cambian durante el desarrollo del sistema, entonces
con un mínimo de esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible.
La diferencia fundamental entre desarrollo evolutivo y prototipos de software es que el
desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que tendría la
propiedad de satisfacer los nuevos requerimientos lo más rápido posible. En contraste,
prototipos usa un enfoque iterativo sólo para determinar los requerimientos SGP: Sistema
de Gestión de Pedidos 18 organizacionales. Por lo tanto, el tiempo tomado entre cada
iteración es mucho más importante para el desarrollo evolutivo. El desarrollo evolutivo
asume que los requerimientos de un proyecto están sujetos a cambios continuos, por lo
cual es necesario definir una estrategia de desarrollo que refleje esta situación. La idea
entonces de la metodología de desarrollo evolutivo es estar liberando constantemente
una nueva versión del sistema que sea completamente funcional; así, cada sistema
producto de las iteraciones sucesivas del método tendría incorporado los nuevos
requerimientos que ha sido posible identificar y que no estarían considerados en la
anterior versión. Así, las etapas del desarrollo evolutivo tienen por objetivo extender los
incrementos de un producto de software operacional, en las direcciones determinadas
por la evolución de la experiencia operacional. El método evolutivo tiene la gran ventaja
de reconocer la existencia de una constante de cambios en los requerimientos y, desde
esta premisa, propone una solución, la cual es válida para la solución de ese problema
pero que no resolvería la inquietud original.
Conclusiones
Después de haber analizado el problema, ver qué soluciones existen en la actualidad
exterior para solucionar este problema, podemos llegar a las siguientes conclusiones:
 No existe prácticamente en el mercado un software que se adapte a todas las
necesidades buscadas.
 Los recursos para el desarrollo e implementación del software no son difíciles de
conseguir, excepto las pantallas táctiles para la cual se propone como alternativa la
utilización de ratones.
 Existe una programación la cual ayuda para llevar un seguimiento de las mismas.  El
modelo de desarrollo es idóneo para este tipo de proyectos.
30
3.2. Proyecto Sistema de Información de Restaurante

Introducción
La aplicación de metodologías y prácticas ágiles dentro de empresas dedicadas al
desarrollo de software, es en la actualidad una realidad que se viene acrecentando en los
últimos años alrededor del mundo. Son muchas las personas y empresas dedicadas al
desarrollo de software que se enfrentan hoy por hoy con el dilema de ser o no ser ágiles.
Bien sea porque sus actuales metodologías de desarrollo no dan los resultados
esperados o bien porque desean incursionar en prácticas que están de moda a lo largo y
ancho de las comunidades de desarrollo en todo el mundo, lo cierto es que el auge de las
metodologías ágiles es un tema que apasiona y hace reflexionar a todo aquel que se
encuentre inmerso dentro del proceso de desarrollo de software. Este trabajo presenta
un enfoque práctico para la elección y adecuación de metodologías ágiles de desarrollo
de software a un proyecto real:
El desarrollo de un sistema de reservas para una agencia de viajes usando tecnología
J2EE.
Justificación del proyecto
El sector de las Agencias de Viaje ha vivido una crisis desde la aparición de Internet.
Según el Foro Internacional de Turismo, las compras de viajes por Internet han crecido
de forma significativa hasta el punto de llevar a la crisis a las agencias de viaje
tradicionales. La tendencia se presenta como consolidada, aunque ello no tiene por qué
suponer la desaparición de estas agencias sino un cambio en su concepción original de
manera que se puedan adaptar a los nuevos tiempos. Las compañías aéreas y las
centrales de reservas de hoteles fueron algunas de las primeras entidades en usar
grandes sistemas en red para gestionar la reserva y venta de sus productos. Estos
sistemas conectaban los ordenadores centrales con los terminales de las Agencias de
Viajes. Éstas por su parte vendían luego el producto al público final llevándose una
comisión por la gestión. La incorporación de las agencias a la red ha supuesto la
liberalización masiva del sector, y cualquier competencia en la oferta es beneficiosa para
el cliente ya que la competitividad conlleva una bajada de precios y una mejora del
producto. Con la aparición de Internet las compañías aéreas y las centrales de reservas
de hoteles han extendido sus redes de computadores que antes únicamente servían a
agencias de viajes. En muchos casos hoy en día sale más barato comprar un billete por
Internet, que en una Agencia. Y las compañías aéreas recortan cada vez más sus
comisiones a las Agencias. 5 las compañías de viajes (ferroviarias, aéreas, de alquiler de
coches…), los hoteles, guías y otros muchos servicios que antes dependían de una
agencia u organizador de viajes, ahora pueden ofertarse directamente en la red, sin
intermediarios y sin monopolios que limiten su actividad comercial, de manera que se
ponen en manos de una buena gestión para ofrecer la mejor opción al cliente y del
marketing. Internet es donde se compra, vende y se contratan la inmensa mayoría de los
viajes, cualquiera con conexión puede hacerlo con cuatro clics. Las Agencias de viajes
están pues en crisis, necesitan reinventarse, ya no pueden ser intermediarios en la venta
de billetes de proveedores. Necesitan poder competir en este nuevo mercado de venta
por Internet. El producto diferenciado que ofrecen las agencias de viajes es el paquete
turístico, que, para poder ser un producto alternativo a las ofertas de productos
31
individuales de transporte y alojamiento, debe contar con un sistema de reservas por

Internet que supere al de las compañías aéreas y centrales hoteleras, un sistema de
reservas que ofrezca al público los productos que las agencias elaboran. El sistema de
reservas que elaboraremos en este proyecto contará con una ventaja competitiva frente
a los sistemas de las grandes mayoristas tradicionales. Nuestra tecnología estará basada
en la potencia de Java y J2EE y utilizará metodologías ágiles apoyadas en test
automatizados con las que podremos ser más dinámicos frente a los cambios que puedan
surgir en el futuro.
Objetivos del trabajo
Con este proyecto pretendemos explorar tanto objetivos técnicos como metodológicos.
Objetivos técnicos
Para poder competir en este nuevo mercado de venta de viajes por Internet, necesitamos
por una parte que la aplicación sea extremadamente rápida en la gestión de reservas de
paquetes turísticos. Para ello debemos limitar al máximo la contención en las
transacciones y asegurar al mismo tiempo su corrección, o lo que es lo mismo, impedir
interferencias con otras transacciones en curso por ausencia de bloqueos. Por otro lado,
también será deseable que la aplicación sea estable con facilidad, para ello construiremos
una arquitectura en la que los objetos de negocio se puedan ejecutar tanto fuera como
dentro del contenedor J2EE, para así poderlo someter a todas las pruebas necesarias,
sin la complicación, y lentitud añadida de arrancar un servidor J2EE. Otra característica
necesaria y derivada de la anterior, es construir una arquitectura basada en el paradigma
de la orientación a objetos, conocido como Open / Cosed principle. Este principio postula
que el código este abierto para la extensión, pero cerrado para la modificación ya que
cada vez que modifiquemos 6 códigos corremos el riesgo de estropearlo. Por ello
debemos utilizar las técnicas de herencia y composición para añadir funcionalidad a
nuestros programas.
Objetivos metodológicos
Nosotros en este proyecto, usaremos prácticas de desarrollo ágil como las siguientes:
 Frecuente retroalimentación: para ello se han planificado casos de uso cortos y
en la medida de lo posible auto contenidos, es decir que no necesitan de otras
partes para ser probados.
 Pruebas automatizadas: se comenzará el desarrollo empezando por las pruebas.
Haremos pruebas de unidad y de integración en un ciclo constante como veremos
en más detalle más adelante.
Enfoque metodológico
Para este proyecto exploraremos cómo aplicar las principales prácticas de lo que se
conoce como “desarrollo ágil”. El enfoque tradicional de desarrollo de aplicaciones
heredado de otras ramas de la ingeniería, ha sido el de hacer un estudio exhaustivo del
problema, establecer un plan y llevar a cabo la construcción. Es la metodología conocida
como desarrollo en cascada, con las fases consecutivas de Análisis, Diseño, Codificación,
Pruebas e Implementación. Pero este enfoque no siempre es óptimo para el desarrollo
de software. La programación no es exactamente comparable a otras ramas de la
ingeniería o a la construcción. El desarrollo de software, es un proceso puramente
32
creativo, análogo a lo que en la construcción de una vivienda sería la elaboración de los

planos. A diferencia de la ingeniería civil, en el desarrollo de software no existe un proceso
de construcción en el que se sigan unos planos de modo mecánico previamente
establecidos por el arquitecto o ingeniero. En cada fase hay que ser creativo y tomar
decisiones. En realidad, sí existe un proceso análogo al de la pura construcción, en el
que no hay que tomar decisiones y solo aplicar lo dictado por el arquitecto. Es el paso del
código fuente al objeto, la compilación. Pero su coste es despreciable frente al coste del
diseño. Justo lo contrario a lo que sucede con la ingeniería civil, donde el coste del diseño
es infinitamente menor que el de la construcción.
El objetivo de las metodologías de desarrollo ágil de software es la organización de un
trabajo creativo, que suele ser bastante caótico. Se intenta dar prioridad a la 7 ejecución
sobre la planificación. A medida que se profundiza en el conocimiento de un problema se
cambian los planes. Cuando el cliente vea nuestras propuestas, se le ocurrirán nuevas
ideas que cambiarán los planes.
Cuando profundicemos en el conocimiento de nuevas tecnologías haremos
descubrimientos que cambiarán de nuevo los planes. La planificación excesiva es el
problema habitual de los enfoques de desarrollo de software en cascada. Una
planificación es excesiva cuando desconocemos parte o gran parte del problema al que
nos enfrentamos y aun así establecemos objetivos y plazos. En el mejor de los casos
renunciaremos a las ventajas que se obtendrían de un mejor entendimiento del problema.
En el peor, nuestro plan fracasará por encontrarnos riesgos con los que no contábamos.
Ágil quiere decir, adaptable. Desde esta premisa, los cambios son bienvenidos, derivan
de un mejor entendimiento del problema y son una oportunidad para mejorar el software.
Este proyecto será ágil porque tendremos que tratar con cierta incertidumbre tecnológica
al tener que evaluar la tecnología J2EE y el gestor de bases de datos PostgreSql.
También será ágil porque hemos de estar dispuestos a adaptarnos a la mejor solución
que encontremos al problema de conseguir un elevado rendimiento en las transacciones
de reservas de viaje, algo que puede afectar al planteamiento general de la aplicación. El
desarrollo ágil no equivale al caos. Para poderse llevar a cabo necesita basarse en en
dos pilares: pruebas automáticas y retroalimentación (feedback) temprana, es decir
objetivos.
Aplicación de la metodología Ágil en nuestro proyecto.
Hemos intentado seguir una metodología basada en SCRUM, pero el intento de asumir
los roles de cliente, jefe de proyecto y programadores en una sola persona hacían muy
artificial este enfoque. Por ello nos hemos centrado en dos aspectos de la metodología
ágil que a nuestro juicio tienen la mayor importancia: las pruebas automatizadas, y otorgar
más importancia al software que a la documentación, es decir la documentación será una
herramienta para el software y no otro producto a añadir.
Pruebas Automatizadas
Las pruebas automatizadas son la piedra angular de cualquier metodología de desarrollo
ágil, ¿Cómo si no vamos a permitirnos cambiar las características de una aplicación en 9
mitades del desarrollo y tener garantías de no haber estropeado nada? A pesar de los
esfuerzos de la ingeniería de software por mantener una independencia de los diferentes
componentes que conforman un sistema., inevitablemente los módulos de una aplicación
33
tienen que interactuar entre si generando interdependencias que a veces no son

evidentes. Al cambiar la funcionalidad de alguno de estos módulos se pueden tener
consecuencias imprevistas en otras partes del sistema. Estas consecuencias las
podemos detectar ejecutando pruebas automatizadas que comprueben todas las partes
del sistema. Las pruebas, por tanto, nos permiten afrontar con mayores garantías el
cambio. Además, el hecho de que sean automatizadas nos permite repetirlos infinidad de
veces sin encarecer el coste de desarrollo.
Justificación económica de las pruebas automatizadas
Esta aplicación tiene unos unos 140 métodos. Cada vez que hemos incluido o modificado
un método hemos ejecutado una suite de pruebas que ejecuta prácticamente todos los
métodos. Supongamos que hemos ejecutado la suite unas 500 veces (ejecuto la suite
varias veces mientras desarrollo) Si un programador tuviese que depurar a mano esas
pruebas tardaría 140 * 500 * 2 minutos por prueba = 140.000 minutos, o lo que es lo
mismo 291 jornadas de trabajo. El escribir las pruebas me ha costado entre 30 y 60
minutos por método, hay 56 métodos en el proyecto de test, por lo que he invertido 56 *
45minutos = unas 40 horas o 5 jornadas. El escribir las pruebas automatizadas nos ha
ahorrado 286 jornadas de trabajo. Eso suponiendo que el programador que ejecutase las
pruebas no se equivocase nunca y fuese tan perfecto como las pruebas automáticas.
Justificación de pruebas de unidad y de integración
En una aproximación ingenua podríamos pensar que una prueba se podría limitar a
arrancar la aplicación, seguir el manual de usuario y ver que hace lo que tiene que hacer,
es decir, lo que es una prueba de integración. Sin embargo, por poner un ejemplo, si un
programa tiene 6 controles con 4 valores de entrada posibles para dar un resultado
determinado, probarlo solo con una prueba de integración nos obligaría a escribir 4 * 4 *
4 * 4 * 4 * 4, pruebas que son las distintas posibilidades de entrada que tendría el sistema,
o lo que es lo mismo 4 ^ 6 = 46.656 10 pruebas diferentes. Con las pruebas de unidad
podemos probar estos componentes individualmente, es decir probaríamos el primer
control, para lo que escribiríamos cuatro pruebas para sus cuatro posibles valores de
entrada. Haríamos lo mismo con los 5 controles restantes con lo que escribiríamos 4
pruebas para cada uno, en total 4 + 4 + 4 + 4 + 4 + 4 = 4 * 6 = 24 pruebas para probar
todos los controles frente a las 46.656 pruebas que tendríamos que hacer si solo
hiciésemos pruebas de integración.
Pruebas de unidad
El objetivo de las pruebas no es demostrar que el sistema funciona, sino encontrar
errores. Empíricamente hemos visto que la mayor parte de los errores en las funciones
se encuentran en la entrada de valores nulos, las cadenas vacías y los valores límite. Por
valores límite entendemos que, si una función admite un rango de valores, los límites son
las fronteras de esos valores. Normalmente en todas las pruebas el primer paso ha sido
probar que hace lo que tiene que hacer con los valores esperados. Luego normalmente
se han probado con valores nulos, cadenas vacías y valores límite. No hemos probado
todas las clases, solo las que tenían cierta complejidad. Habitualmente se ha hecho una
prueba por método, aunque en algunos casos se han tenido que hacer más. El framework
elegido para las pruebas de unidad ha sido JUnit.
Pruebas de integración
34
Para las pruebas de unidad hemos usado HttpUnit y pruebas manuales. HttpUnit es un
cliente http hecho en java que podemos combinar con JUnit para hacer pruebas de
integración contra el servidor http.
Pruebas de rendimiento
Para ver la velocidad de las transacciones hemos usado clases sencillas con un
cronómetro software, para medir los rendimientos, ya que la velocidad era una parte
crítica del sistema.
Documentación
En cuanto a la documentación, no hemos prescindido de ella, hemos constatado que son
de gran utilidad los casos de uso bien documentados junto con diagramas de actividad
UML. 11 nos han sido especialmente útiles para describir el comportamiento de los
controladores de cada uno de los casos de uso. Los diagramas nos han ayudado a
mejorar la productividad ya que permitían centrarse en la funcionalidad que se estaba
desarrollando y dejar de lado las preocupaciones de las subsiguientes tareas. No nos han
parecido útiles sin embargo los diagramas de clases, de colaboración y de secuencia., y
por tanto no los hemos usado. Esto es porque siempre hemos usado los mismos
patrones: MVC, Façade, Decorators, Factorys y DAO.
Planificación del proyecto
A pesar de ser un proyecto ágil, no hemos renunciado a una mínima planificación,
inicialmente identificamos las siguientes etapas:
Investigación tecnología j2ee y PostgreSql
Se dedicará un tiempo finito a la formación e investigación. Queremos evaluar la nueva
tecnología JEE, Hibérnate, Spring y JSF. Acabado ese tiempo elegiremos la tecnología
que mejor se adapte a nuestro problema o la desarrollaremos nosotros mismos.
Instalación de entorno
Antes de empezar tan siquiera a hacer los casos de uso Instalaremos las siguientes
herramientas:
? Eclipse con soporte para jee (Ganymede)
? Java 1.6?
Herramienta de uml (Magic Draw)
? Tomcat? PostgreSql, jdbc y PgAdmin.
? Junit (pruebas de unidad)
? HttpUnit (pruebas de integración)
? Metrics (para medir aspectos de calidad del software)
Establecemos también un sistema de Backup automatizado a una unidad externa.
Se evaluarán la instalación de herramientas automatizadas de construcción de proyectos
como Ant y Maven.
Desarrollo de la aplicación por casos de uso (Sprint)
35
En la terminología SCRUM se denominan Sprint. SCRUM es la metodología de desarrollo

a la que intentamos atenernos en un principio. 12 1.4.3.1. Sprint1. Transacción de
reserva de plazas
Al ser la parte más crítica, la de la gestión de las reservas con transacciones, se hará en
primer lugar para despejar todas las incertidumbres al respecto. Se harán pruebas de
estrés para asegurar el buen rendimiento de la solución adoptada.
Sprint2. Búsqueda de ofertas (paquetes turísticos)
Se creará una pantalla de búsqueda para localizar las ofertas por diversos criterios y se
enlazará con la reserva de plaza.
Sprint 3. Login, Alta de usuario e integración con el sistema
Se crearán pantallas para el usuario se pueda dar de alta en el sistema en cualquier punto
de la aplicación y que exija estar registrado para hacer la reserva 1.4.3.4.
Sprint 4. Gestión completa de cuenta de usuario (CRUD) e integración con el
sistema.
Se crearán las pantallas para el mantenimiento de la cuenta de usuario. Alta, lectura,
modificación y borrado.
Sprint 5. Gestión de oferta de paquetes turísticos (CRUD)
Se crearán las pantallas para la gestión de las ofertas., lectura, modificación y borrado.
Ciclo de cada Sprint: 6H seguirá un modelo en espiral con las etapas de análisis, diseño,
pruebas y codificación e integración.
Productos obtenidos
Metodología y herramientas de testing
A través de la experiencia obtenida en el desarrollo de este proyecto, hemos llegado a
desarrollar una metodología de testing que resuelve algunos de los problemas
habituales en la implantación de pruebas automatizadas.
Aislamiento del código de pruebas del de producción.
Hemos creado un workspace específico para el proyecto de reservas, dentro de él se
ha creado un proyecto java para las pruebas: reservasTest. Este proyecto,
reservasTest accede a los otros proyectos del workspace, que contienen el código de
producción, así puede acceder a sus clases, instanciarlas y probar sus métodos. El
proyecto reservasTest tiene en su classpath referencias a las librerías JUnit, HttpUnit,
y las librerías JDBC de Postgresql.
Los otros proyectos no tienen ninguna referencia a estas bibliotecas. En la fase de
despliegue no se exporta el proyecto reservasTest y los componentes del código de
producción no contienen ningún test ni ninguna referencia a estos.
Pruebas de métodos privados
Un problema frecuente con las pruebas es la prueba de los métodos privados de las
clases. Nosotros hemos resuelto este problema sustituyendo la visibilidad private de
campos y métodos por la visibilidad de paquete, la visibilidad por defecto. Las clases
36
de prueba las ponemos en el mismo paquete que las clases a probar, pero en el
proyecto de reservasTest, es decir replicamos el paquete (la estructura de directorios)
Para java, cuando usa el classpath es como si estuviesen en el mismo paquete, y por
ello las clases de prueba, cables a corto plazo.
3.3. Restaurante: Prototipo de un Restaurante Digital
Introducción
Para empezar, se explicará la finalidad, en qué consiste y la estructura de elaboración
de este proyecto.
Objetivos y resumen del proyecto
El objetivo del proyecto, a grandes rasgos, es la implementación de una aplicación web,
que gestione un restaurante desde el punto de vista de los usuarios gerente, camarero
y cliente. No obstante, el objetivo más concreto es llevar a cabo la implementación
utilizando un concepto innovador. Este concepto consiste en que el cliente tenga
acceso a dicha aplicación desde su propia mesa y pueda seleccionar los productos que
desee directamente desde ésta, sin tener que necesitar al camarero para realizar su
pedido. A todo esto, debemos añadir que la aplicación debe permitir interactuar con ella
a los usuarios de una manera ágil y sencilla, dentro de las posibilidades de su
funcionalidad. A su vez, otro de los objetivos, éste desde el punto de vista del
desarrollador, es adquirir experiencia en la implementación de este tipo de sitios web,
que cada vez están más extendidos en la sociedad.
Problema Planteado
Desarrollar un sitio web para un restaurante que permita: A los gerentes gestionar el
catálogo de productos y los empleados del restaurante. A los camareros gestionar y
atender los pedidos, obteniendo en tiempo real los pedidos de los clientes en sus
terminales. A los clientes realizar pedidos desde su mesa desde el primer momento en
que llegan al restaurante, visualizar en qué estado se encuentra en tiempo real y realizar
reservas cuando se conecten a la aplicación desde fuera del restaurante. A cualquier
usuario que se conecte a la aplicación conocer el restaurante consultando información
diversa acerca del mismo y registrarse en el sistema.
Formulación Del Problema

Este sistema permitirá a los clientes realizar reservas y pedidos sobre la carta, y a los
camareros conocer el estado de cada mesa y saber los platos a servir en cada momento.
El principal objetivo de este software es permitir a los clientes de un restaurante obtener
una mejor atención y a los camareros facilitarles y organizarles el trabajo.
En forma general la situación problemática está especificada en la necesidad de
implementar un gestor Web que permita el procedimiento general en cuanto a pedidos en
un restaurante.
37
Estructura Del Proyecto

En este apartado describiremos el proceso de elaboración completa de un proyecto de
una aplicación web. En él se tratarán distintos puntos, como la especificación de
requisitos; aquí trataremos de describir cómo será la aplicación final que obtendremos,
las funciones que realizarán, los tipos de usuarios que la utilizarán, etc. Para ello hemos
seguido una guía, recomendada por la mayor parte de expertos en este campo, la
especificación IEEE Standard 830 1998. La siguiente parte será la de análisis, en la cual
se creará el diagrama de clases que ayudará a comprender la estructura de la aplicación.
La sección de diseño vendrá a continuación, donde se estudiará el diseño por capas que
vamos a utilizar (tres capas: de presentación, de lógica de la aplicación y de persistencia),
y describiremos la interfaz gráfica de la aplicación, la base de datos, etc. En el siguiente
capítulo, implementación e integración, explicaremos las tecnologías utilizadas para el
desarrollo, así como las herramientas usadas. Además, se explicará todo el desarrollo
realizado hasta obtener el producto final. Para finalizar, se presentan una serie de
conclusiones que se han obtenido durante la creación del sitio web y se hace referencia
a la bibliografía utilizada.
Especificación De Requisitos
Introducción
Propósito Este sistema permitirá a los clientes realizar reservas y pedidos sobre la carta,
y a los camareros conocer el estado de cada mesa y saber los platos a servir en cada
momento. El principal objetivo de este software es permitir a los clientes de un restaurante
obtener una mejor atención y a los camareros facilitarles y organizarles el trabajo.
Ámbito El producto software a desarrollar se denominará “e Restaurante”.
Definiciones, acrónimos y abreviaturas
 ERS. Documento de Especificación de Requisitos Software.
 Internet. Red de redes a escala mundial con millones de computadores
Interconectados entre ellos mediante el conjunto de protocolos TCP/IP. También se utiliza
este nombre para designar cualquier red de redes que utilice las mismas tecnologías que
Internet.
 Web. El web o WWW (acrónimo en inglés de World Wide Web, gran telaraña
mundial) es una red de páginas escritas en hipertexto, con el lenguaje de marcado
HTML, y conectadas entre sí. Para acceder la única herramienta indispensable es
un navegador web.
 Software. Programas, aplicaciones.
 Aplicación Web. Aplicación que los usuarios utilizan desde un servidor web a
través de Internet o una intranet. La facilidad para actualizar y mantener
aplicaciones sin la necesidad de instalar programas en los millones de clientes
potenciales es una de las principales causas de su popularidad.
 Usuario. Persona que después de haberse identificado hace uso de las funciones
de la aplicación.
38
 Sistema. Conjunto de partes interrelacionadas, hardware, software y de recurso

humano.
 Apache. Es un software libre, servidor HTTP de código abierto que implementa el
protocolo HTTP/1.1.
 Código abierto. Término usado para referirse a programas que se ofrecen con total
libertad de modificación, uso y distribución bajo la regla implícita de no modificar
dichas libertades hacia el futuro.
 Protocolo. Conjunto de reglas que especifican el intercambio de datos u órdenes
durante la comunicación entre sistemas.
 Servidor web. Es un programa que se ejecuta continuamente en un ordenador
manteniéndose a la espera de peticiones por parte de un cliente (un navegador
web) y que responde a estas peticiones adecuadamente, mediante una página
web que se exhibirá en el navegador o mostrando el respectivo mensaje si se
detectó algún error.
 MySQL. Sistema de gestión de base de datos.
Descripción General
Perspectiva del producto El producto software no depende de ningún sistema mayor, es
independiente.
Funciones del producto Podemos clasificarlas en dos partes diferenciadas: Funciones de
visualización: Nuestra aplicación visualizará información relacionada con el restaurante,
los clientes y los pedidos. a) Función de gestión de la información
 Consulta de los productos existentes y sus precios.
 Consulta de los menús de oferta.
 Envío de comentarios y sugerencias.
 Recordatorio de pedidos anteriores realizados por el cliente
 Visualizar los pedidos (camareros). Los camareros podrán ver en todo momento
la descripción de los pedidos realizados de sus mesas, así como el estado en el
que se encuentran: servido o sin servir.
 Visualización de pedidos (clientes). El cliente podrá acceder a un listado con los
pedidos realizados, los productos que componen cada pedido y el estado (servido
o sin servir) de cada producto del mismo. Funciones de
mantenimiento/actualización de la base de datos a) Función de control de usuarios
 Registro e identificación de usuarios
 Asignar clientes a una mesa. Los camareros serán los encargados de comprobar
qué mesas hay libres en el restaurante y asignar a los clientes a una mesa libre.
b) Función de gestión de los productos
 Añadir productos. Se podrán añadir productos al restaurante.
Análisis
El propósito principal del análisis es obtener una descripción lógica del sistema a
desarrollar, es decir, describir formalmente mediante modelos las características de la
aplicación. Estos modelos servirán posteriormente de guía para obtener el producto
deseado. Para ello utilizaremos el lenguaje de modelado UML (Lenguaje Unificado de
39
Modelado). Se trata de un lenguaje gráfico para visualizar, especificar, construir y

documentar un sistema de software. Éste tiene varios diagramas, aunque únicamente
desarrollaremos el diagrama de clases.
Diagrama De Clases
El diagrama de clases en UML es el diagrama principal para el modelado y el diseño en
la programación orientada a objetos y sirve para representar las clases del sistema, que
corresponden a tipos de usuarios, opciones, las relaciones que se establecen entre ellas,
ya sean de herencia o de tipo estructural. A continuación, se muestra el diagrama de
clases para el restaurante.
Utilizamos la entidad para representar los usuarios que pueden autenticarse en el
sistema: gerente, camarero y cliente, es por este motivo que hereda de, porque los
clientes tienen las propiedades del más otras extra, pero el usuario gerente no necesita
almacenar la información de los clientes tales como: nombre, teléfono, apellido1, etc. Algo
similar sucede con los camareros, se ha decidido diferenciar entre el usuario camarero
(puede autenticarse) y el empleado camarero. Esto se ha realizado en base a que cada
camarero no necesita un usuario, esta aplicación está pensada para que varios
camareros entren con el mismo usuario para así tener una vista general del restaurante.
Cada cliente puede tener asignados pedidos, aunque por la aplicación se controla que
cada cliente solamente tenga un pedido activo, el resto de pedidos pasarán a formar parte
del histórico. Cada pedido está, a su vez relacionado con un camarero que lo atenderá,
una mesa y las consumiciones seleccionadas por el cliente. Una consumición no es más
que un ítem de consumición que almacena las siguientes propiedades: cantidad (del ítem
de consumición), precio, servida y confirmada. Asimismo, un ítem de consumición puede
ser un producto (de un tipo de producto) o un menú. Observamos también en el diagrama
la entidad, de manera que un cliente podrá realizar una reserva para una fecha y una
mesa, cuando llegue al restaurante se le creará un pedido para la mesa reservada en esa
fecha o posterior. Por último, nuestra aplicación está preparada para almacenar
comentarios procedentes de clientes o usuarios anónimos.
Diagrama De Usuarios
En nuestra aplicación web tenemos 5 tipos de usuarios y cada tipo de usuario representa
un conjunto de usuarios con objetivos y responsabilidades comunes en el sistema. Estos
usuarios son: anónimo, cliente, cliente web, camarero y gerente, y sus inter-relaciones
así como su modo de acceso al sistema se muestran en el diagrama siguiente: Como se
ve en la figura, a nuestra aplicación podemos acceder como usuario anónimo o como
autenticado, esto es, como: gerente, camarero o cliente. El usuario cliente se especializa
en dos: Cliente normal y Cliente web. El cliente normal se asocia a un cliente que accede
a la aplicación físicamente desde el restaurante, mientras el cliente web a uno que accede
desde fuera del restaurante y que tiene acceso a funcionalidad diferente. Resulta
importante destacar que el cliente como tal no existe en la aplicación, se utiliza en el
diagrama para indicar que el cliente normal (estándar) y el web comparten funcionalidad.
Implementación E Integración
Tecnologías
40
Nuestra aplicación está construida sobre tres servidores, dos de código abierto: un
servidor HTTP Apache y un servidor de base de datos MySQL, y un servidor de correo
Mercury que no es libre ni de código abierto, pero que sí dispone de una versión gratuita
siempre que su uso sea privado y sin fines comerciales, que es nuestro caso. Utilizamos
el lenguaje ASP.NET (con VISUAL BASIC), AJAX y javascript para crear páginas web
dinámicas. Resulta importante destacar también la utilización del protocolo HTTPS, que
permite enviar información entre páginas de manera segura mediante cifrado SSL, así
que cuando nos autentificamos en la aplicación web ya sea como cliente, camarero o
gerente las páginas se muestran utilizando este protocolo seguro. A continuación
describiremos dichos componentes, así como también las tecnologías en las que se
sustentan.
 Xampp. Es un servidor independiente de plataforma, software libre, que consiste
principalmente en la base de datos MySQL, el servidor Web Apache y los
intérpretes para lenguajes de script: PHP y Perl. No obstante, nosotros lo hemos
utilizado con el lenguaje ASP.NET, gracias al módulo modaspnet. Incluye módulos
como OpenSSL y phpMyAdmin para la gestión de las bases de datos.
 Servidor HTTP Apache. Servidor web HTTP de código abierto, multiplataforma,
que implementa el protocolo HTTP/1.1 y la noción de sitio virtual. Entre otras
ventajas destacan que es modular, extensible y que es utilizado por una gran
comunidad de usuarios, por lo que es fácil de conseguir y existe mucha información
disponible al respecto en la web. La mayor parte de la configuración se realiza en
el fichero apache2.conf o httpd.conf, según el sistema donde esté corriendo.
Cualquier cambio en este archivo requiere reiniciar el servidor, o forzar la lectura
de los archivos de configuración nuevamente.
 MySQL. Es uno de los SGBD más empleados del mercado para aplicaciones web
debido a su sencillez. Es relacional, multihilo y multiusuario. Pertenece a Sun
Microsystems. Por un lado se ofrece bajo la GNU GPL para cualquier uso
compatible con esta licencia, pero para aquellas empresas que quieran
incorporarlo en productos privativos deben comprar a la empresa una licencia
específica que les permita este uso. Al contrario de proyectos como Apache, donde
el software es desarrollado 60 por una comunidad
 Mercury Mail Transport System. Es un servidor de correo, gratuito, basado en
estándares, proporcionando un completo apoyo y un servidor rápido para los
principales protocolos de correo electrónico. Va integrado en el paquete XAMPP.
 HTML. Acrónimo inglés de HyperText Markup Language (lenguaje de marcas
hipertextuales), es un lenguaje de marcación diseñado para estructurar textos y
presentarlos en forma de hipertexto, que es el formato estándar de las páginas web.
Gracias a Internet y a los navegadores del tipo Internet Explorer, Opera, Firefox o
Netscape, el HTML se ha convertido en uno de los formatos más populares que existen
para la construcción de documentos y también de los más fáciles de aprender. HTML es
una aplicación de SGML conforme al estándar internacional ISO 8879. XHTML es una
reformulación de HTML 4 como aplicación XML 1.0, y que supone la base para la
evolución estable de este lenguaje. Además, XHTML permite la compatibilidad con los
agentes de usuario que ya admitían HTML 4 siguiendo un conjunto de reglas. En sus
orígenes, HTML era un lenguaje diseñado para compartir información entre científicos de
todo el mundo. Era puramente un lenguaje estructural, donde no había forma de describir
41
la apariencia de las páginas (ni tan solo la posibilidad de poner un texto en negrita o
cursiva). Más adelante se añadieron numerosas opciones para dar formato y presentar
texto y gráficos. A mediados de los 90 empezaron las ampliaciones de HTML para
conseguir presentaciones mejoradas, pero siempre desde diferentes perspectivas de
cada desarrollador, que acabaron en diferentes soluciones no estándares para diferentes
navegadores. Esto provocó la aparición de un consorcio que controla la evolución del
HTML: elW3C (World Wide Web Consortium). Esta evolución tenía un punto clave: la
separación del contenido y la apariencia. Con la versión 4 del HTML se recomendaba otro
mecanismo para controlar la visualización del contenido HTML, las hojas de estilo (CSS:
Cascade Style Sheet). 61 actualmente se recomienda el uso del XHTML, que mantiene
la misma sintaxis y mecanismos que el HTML, pero reformulado con un documento XML,
preparándose para aprovechar las ventajas de este lenguaje.
 ASP.NET. ASP.NET es un conjunto de tecnologías de desarrollo de aplicaciones web
comercializado por Microsoft. Es usado para construir sitios web domésticos, aplicaciones
web y servicios XML. Forma parte de la plataforma .NET de Microsoft y es la tecnología
sucesora de la tecnología Active Server Pagés (ASP). Se trata una tecnología de páginas
activas que permite el uso de diferentes scripts y componentes en conjunto con el
tradicional HTML para mostrar páginas generadas dinámicamente. Microsoft desarrolló
una nueva tecnología denominada ASP.NET - como parte de su estrategia .NET- para el
desarrollo Web, con el objetivo de resolver las limitaciones de ASP. ASP.NET es mucho
más que la próxima versión de ASP. Su arquitectura ha sido rehecha desde cero para
facilitar al máximo la creación de aplicaciones Web dinámicas, y el modo en que
estructuramos el código ASP.NET también promueve una mejor reutilización. Mientras
que las aplicaciones tradicionales ASP utilizan la extensión .asp, las páginas ASP.NET
utilizan la extensión .aspx. Sin embargo, podemos utilizar tanto páginas ASP como
ASP.NET en un mismo sitio Web. El modelo de ASP.NET, con muchas características
nuevas, permite escribir código más limpioy más fácil de reutilizar y compartir,
incrementando el rendimiento y la escalabilidad al poder acceder a lenguajes compilados,
no interpretados. Otra de sus ventajas es que soporta muchos lenguajes compilados. La
versión actual de ASP está basada en lenguajes de scripting como VBScript y Script. No
hay nada malo en ello, pero el modelo presenta el inconveniente de la propia
interpretación del lenguaje y que los lenguajes de scripting no están fuertemente tipados.
Ambos conllevan a considerar con rigor los aspectos relacionados con el rendimiento.
ASP.NET, aunque no descarta totalmente la idea de los lenguajes de scripting, introduce
soporte para lenguajes completamente compilados, ofreciendo al desarrollador escribir el
código en Visual Basic, C++ o C#. De hecho, gracias a la incorporación del conjunto de
tipos comunes y el funcionamiento global del CLR, ofrece un verdadero entorno neutral
independiente del lenguaje para las aplicaciones Web.
Detalles De La Implementación
Páginas Principales
Para que el desarrollo del sitio web resultara más sencillo, rápido y organizado a medida
que avanzáramos en él, hemos utilizado páginas principales (master pages),
concretamente, una página principal por cada tipo de usuario (anónimo, empleado,
gerente y cliente), ya que, cada uno de estos usuarios precisan de una zona de
navegación distinta (un menú distinto). De esta forma, una vez tenemos las cuatro
42
páginas principales creadas ya sólo tenemos que preocuparnos del contenido de las
mismas, y es lo único que tendremos que implementar en el resto de páginas, que se
basaran en éstas. Las páginas principales permiten definir el aspecto, el diseño y el
comportamiento estándar que se desea que tengan todas las páginas (o un grupo de
páginas) de la aplicación en una sola página principal. A partir de ella se pueden crear
páginas de contenido individuales que incluyan lo que se desea mostrar. Cuando los
usuarios solicitan las páginas de contenido, éstas se combinan con la página principal
para dar como resultado una página con el diseño de la página principal y el contenido
de la página de contenido. 66 en definitiva, su utilización nos da muchas ventajas, ya que
proporcionan una funcionalidad que tradicionalmente los programadores creaban
copiando el código, el texto y los elementos de control existentes repetidamente,
mediante conjuntos de marcos, archivos de inclusión de elementos comunes, controles
de usuario de ASP.NET, etc. Entre las ventajas de las páginas principales se incluyen las
siguientes:
 Permiten centralizar las funciones comunes de las páginas para que las
actualizaciones puedan llevarse a cabo en un solo lugar.
 Facilitan la creación de un conjunto de controles y código, y aplican los resultados
en un conjunto de páginas. Por ejemplo, se pueden utilizar los controles en la
página principal para crear un menú que se aplique a todas las páginas.
 Proporcionan un modelo de objetos que permite personalizar la página principal a
partir de páginas de contenido individuales. A continuación, le voy a dar un enfoque
más práctico a este apartado para tratar de demostrar lo comentado. Para que una
página sea página principal debe tener un encabezado similar.
43
CAPÍTULO # 4
MARCO TEÓRICO
CONCEPTUAL
44
CAPITULO # 4 MARCO TEÓRICO CONCEPTUAL
45
CAPÍTULO # 5
METODOLOGÍA DE
LA INVESTIGACIÓN
46
CAPÍTULO # 5 METODOLOGÍA DE LA INVESTIGACIÓN
Metodología de la Investigación
Como metodología de la investigación se denomina el conjunto de procedimientos y

técnicas que se aplican de manera ordenada y sistemática en la realización de un
estudio.
En un proceso de investigación, la metodología es una de las etapas en que se divide
la realización de un trabajo. En ella, el investigador o los investigadores deciden el
conjunto de técnicas y métodos que emplearán para llevar a cabo las tareas vinculadas
a la investigación.
De esta manera, la metodología de investigación elegida es la que va a determinar la

manera en que el investigador recaba, ordena y analiza los datos obtenidos. La función
de la metodología de la investigación es otorgarles validez y rigor científico a los
resultados obtenidos en el proceso de estudio y análisis.Asimismo, como metodología
de la investigación se denomina la parte de un proyecto en que son expuestos y
descritos los criterios adoptados en la elección de la metodología de trabajo y las
razones por las cuales se considera que dichos procedimientos son los más pertinentes
para abordar el objeto de estudio, etc.
Por otro lado, como metodología de la investigación también se denomina una

disciplina de conocimiento que tiene como objeto elaborar, definir y sistematizar, el
conjunto de técnicas y métodos que se deben seguir durante el desarrollo de un
proceso de investigación.
Como tal, la metodología de la investigación es aplicable a las más variadas disciplinas

de estudio. Desde las científicas y las sociales, hasta las humanísticas, las educativas
y las jurídicas. Dependiendo de la materia y el tema de estudio, se elegirá la
metodología que se considere más adecuada.
La Investigación Cualitativa
La metodología cualitativa, como indica su propia denominación, tiene como objetivo
la descripción de las cualidades de un fenómeno. Busca un concepto que pueda
abarcar una parte de la realidad. No se trata de probar o de medir en qué grado una
cierta cualidad se encuentra en un cierto acontecimiento dado, sino de descubrir tantas
cualidades como sea posible.
En investigaciones cualitativas se debe hablar de entendimiento en profundidad en
lugar de exactitud: se trata de obtener un entendimiento lo más profundo posible.
Dentro de las características principales de esta de metodología podemos mencionar:
 La investigación cualitativa es inductiva.
 Tiene una perspectiva holística, esto es que considera el fenómeno como un
todo.
 Se trata de estudios en pequeña escala que solo se representan a sí mismos

47
 Hace énfasis en la validez de las investigaciones a través de la proximidad a la

realidad empírica que brinda esta metodología.
 No suele probar teorías o hipótesis. Es, principalmente, un método de generar

teorías e hipótesis.
 No tiene reglas de procedimiento. El método de recogida de datos no se

especifica previamente. Las variables no quedan definidas operativamente, ni
suelen ser susceptibles de medición.
 La base está en la intuición. La investigación es de naturaleza flexible,

evolucionaría y recursiva.
 En general no permite un análisis estadístico
 Se pueden incorporar hallazgos que no se habían previsto
 Los investigadores cualitativos participan en la investigación a través de

la interacción con los sujetos que estudian, es el instrumento de medida.
 Analizan y comprenden a los sujetos y fenómenos desde la perspectiva de los

dos últimos; debe eliminar o apartar sus prejuicios y creencias
Características de la metodología cualitativa
Las características de la metodología cualitativa que podemos señalar a modo de
sinopsis son:
 Una primera característica de estos métodos se manifiesta en su estrategia para
tratar de conocer los hechos, procesos, estructuras y personas en su totalidad,
y no a través de la medición de algunos de sus elementos. La misma estrategia
indica ya el empleo de procedimientos que dan un carácter único a las
observaciones.
 La segunda característica es el uso de procedimientos que hacen menos

comparables las observaciones en el tiempo y en diferentes circunstancias
culturales, es decir, este método busca menos la generalización y se acerca más
a la fenomenología y al interaccionismo simbólico.
 Una tercera característica estratégica importante para este trabajo se refiere al

papel del investigador en su trato -intensivo- con las personas involucradas en
el proceso de investigación, para entenderlas.
 El investigador desarrolla o afirma las pautas y problemas centrales de su trabajo

durante el mismo proceso de la investigación. Por tal razón, los conceptos que
se manejan en las investigaciones cualitativas en la mayoría de los casos no
están operacionalizados desde el principio de la investigación, es decir, no están
definidos desde el inicio los indicadores que se tomarán en cuenta durante el
proceso de investigación. Esta característica remite a otro debate
48
epistemológico, muy candente, sobre la cuestión de la objetividad en la

investigación social.
La investigación cuantitativa
Surge en los siglos XVIII y XIX, en el proceso de consolidación del Capitalismo y en el
seno de la Sociedad Burguesa Occidental. Con la finalidad de analizar los conflictos
sociales y el hecho económico como Universo complejo. Inspiradas en
las Ciencias Naturales y estas en la física Newtonianas a partir de los conocimientos
de Galileo. Con Claude Saint Simón y Augusto Comte surge la Sociología como
Ciencia.
Su racionalidad está fundamentada en el Cientificismo y el Racionalismo, como
posturas Epistemológicas Institucionalistas. Profundo apego a la tradicionalidad de la
Ciencia y utilización de la neutralidad valorativa como criterio de objetividad, por lo que
el conocimiento está fundamentado en los hechos, prestando poca atención a la
subjetividad de los individuos.
Su representación de la realidad es parcial y atomizada. El experto se convierte en una
autoridad de verdad.
Hurtado y Toro (1998). "Dicen que la investigación Cuantitativa tiene una concepción
lineal, es decir que haya claridad entre los elementos que conforman el problema, que
tenga definición, limitarlos y saber con exactitud donde se inicia el problema, también
le es importante saber qué tipo de incidencia existe entre sus elementos".
Metodología cuantitativa
La Metodología Cuantitativa es aquella que permite examinar los datos de manera
numérica, especialmente en el campo de la Estadística.
Para que exista Metodología Cuantitativa se requiere que entre los elementos del
problema de investigación exista una relación cuya Naturaleza sea lineal. Es decir, que
haya claridad entre los elementos del problema de investigación que conforman el
problema, que sea posible definirlo, limitarlos y saber exactamente donde se inicia el
problema, en cual dirección va y qué tipo de incidencia existe entre sus elementos.
Los elementos constituidos por un problema, de investigación Lineal, se denominan:
variables, relación entre variables y unidad de observación.
Edelmira G. La Rosa (1995) Dice que para que exista Metodología Cuantitativa debe
haber claridad entre los elementos de investigación desde donde se inicia hasta donde
termina, el abordaje de los datos es estático, se le asigna significado numérico.
El abordaje de los datos Cuantitativos es estadístico, hace demostraciones con los
aspectos separados de su todo, a los que se asigna significado numérico y hace
inferencias
 La objetividad es la única forma de alcanzar el conocimiento, por lo que utiliza la
medición exhaustiva y controlada, intentando buscar la certeza del mismo.
49
 El objeto de estudio es el elemento singular Empírico. Sostiene que, al existir

relación de independencia entre el sujeto y el objeto, ya que el investigador tiene
una perspectiva desde afuera.
 La teoría es el elemento fundamental de la investigación Social, le aporta su

origen, su marco y su fin.
 Comprensión explicativa y predicativa de la realidad, bajo una concepción

objetiva, unitaria, estática y reduccionista.
 Concepción lineal de la investigación a través de una estrategia deductiva.
 Es de método Hipotético – Deductivo.

Limitaciones cuantitativas
Las limitaciones se sitúan a nivel de varios riesgos de distorsión, el menor de los cuales
no es ciertamente la conversión deformante de lo cualitativo en cantidades
artificialmente calculadas sobre datos previamente transmutados ad hoc
González, Casanova (1975) menciona que la perspectiva y el énfasis Cuantitativo están
relacionados con muchas otras características del investigador. En términos generales
puede decirse que el análisis Cuantitativo es típico sobre todo en la las ciencias sociales
que trabajan con poblaciones, se liga al Empirismo y a la Ideología del proceso de las
ciencias Sociales".
 El investigador Sorokin ha indicado las limitaciones de la investigación
cuantitativa:
 La subjetividad disfrazada Cuantitativamente.
 La conjugación Cuantitativa de agrupaciones para estudiar los sistemas
Sociales.
 Tomar una parte del sistema como variable independiente (causa) y todo el de
los datos Cuantitativos lo que se puede observar en las investigaciones
tradicionales.
Diferencias entre investigación cuantitativa y cualitativa
El objetivo de cualquier ciencia es adquirir conocimientos y la elección del método

adecuado que nos permita conocer la realidad es por tanto fundamental. El problema
surge al aceptar como ciertos los conocimientos erróneos o viceversa. Los métodos
inductivos y deductivos tienen objetivos diferentes y podrían ser resumidos como
desarrollo de la teoría y análisis de la teoría respectivamente. Los métodos inductivos
están generalmente asociados con la investigación cualitativa mientras que el método
deductivo está asociado frecuentemente con la investigación cuantitativa.
50
 La investigación cuantitativa es aquella en la que se recogen y analizan datos

cuantitativos sobre variables.
 La investigación cualitativa evita la cuantificación. Los investigadores

cualitativos hacen registros narrativos de los fenómenos que son estudiados
mediante técnicas como la observación participante y las entrevistas no
estructuradas.
 La diferencia fundamental entre ambas metodologías es que la

cuantitativa estudia la asociación o relación entre variables cuantificadas y la
cualitativa lo hace en contextos estructurales y situacionales.
 La investigación cualitativa trata de identificar la naturaleza profunda de las

realidades, su sistema de relaciones, su estructura dinámica; mientras que la
investigación cuantitativa trata de determinar la fuerza de asociación o
correlación entre variables, la generalización y objetivación de los resultados a
través de una muestra para hacer inferencia a una población de la cual toda
muestra procede. Tras el estudio de la asociación o correlación pretende, a su
vez, hacer inferencia causal que explique por qué las cosas suceden o no de
una forma determinada.
El empleo de ambos procedimientos cuantitativos y cualitativos en una investigación
probablemente podría ayudar a corregir los sesgos propios de cada método, pero el
hecho de que la metodología cuantitativa se la más empleada no es producto del azar
sino de la evolución de método científico a lo largo de los años. Creemos en ese
sentido que la cuantificación incrementa y facilita la compresión del universo que nos
rodea y ya mucho antes de los positivistas lógicos o neopositivistas Galileo Galilei
afirmaba en este sentido "mide lo que sea medible y haz medible lo que no lo sea".
51
CAPÍTULO # 6
MODELADO DE
NEGOCIO
52
CAPITULO # 6. MODELADO DE NEGOCIO
4.1. Lista de Procesos
4.1.1. Proceso de Solicitar Reserva
Figura 6.Diagrama de Actividad - Proceso de solicitar reserva
53
4.1.2. Proceso Cambio de Reserva
Figura 7.Diagrama de Actividad - Proceso cambio de reserva
54
4.1.3. Proceso de Cancelar Reserva
Figura 8.Diagrama de Actividad - Proceso de cancelar la reserva
55
4.1.4. Reserva Realizada
Figura 9.Diagrama de Actividad - Reserva realizada
56
CAPÍTULO # 7
REQUISITOS
57
CAPITULO # 7. REQUISITOS
5.1. Lista de Requisitos
5.1.1. Identificación de Requerimiento
N.º Requisitos Descripción Estado Coste Prioridad Riesgo
1 Gestionar Permitirá registrar, Propuesto 2 Crítico Crítico

Reservas modificar, consultar
y eliminar.
2 Gestionar Permitirá registrar, Propuesto 2 Crítico Crítico

Clientes consultar, modificar
y eliminar los
clientes que realizan
pedidos.
3 Gestionar Mesas Permitirá registrar, Propuesto 2 Crítico Crítico

consultar, modificar
y eliminar.
4 Generar Reportes Permitirá realizar Propuesto 1 Crítico Significativo

una lista de reporte
de cada módulo
Tabla 1. Lista De Requerimientos
58
5.2. Identificación de Actores
5.2.1. Encargado de Reserva
Figura 10. -Actor- Recepcionista
Este actor es el encargado de realizar las reservas
5.2.2 Encargado de Administrar
Figura 11. -Actor- Administrador
Este actor se encargará de administrar los reportes
59
5.3. Captura de Requisitos como Casos De Uso
5.3.1. Casos De Uso: Administrar Reserva
Casos de uso: Administrar reservas.
Actores: Recepcionista.
Propósitos: Permitirá Registrar, consultar, modificar y eliminar la reserva.
Resumen: La recepcionista es encargada de administrará la reserva.
Tipo: Primario.
Referencia: Requisito n.1
Tabla 2. -Caso de Uso: Administrar Reserva
5.3.2 Casos de Uso: Administrar Clientes
Casos de uso: Administrar clientes.
Propósitos: Permitirá Registrar, consultar, modificar y eliminar a los clientes.
Resumen: La recepcionista administrará a los clientes.
Tipo: Primario.
Tabla 3. -Caso de Uso: Administrar Clientes
60
5.3.3. Casos de Uso: Administrar Mesa
Casos de uso: Administrar mesas.
Propósitos: Permitirá Registrar, consultar, modificar y eliminar las mesas

reservadas.
Resumen: La recepcionista administrara las mesas.
Tipo: Primario.
Tabla 4. -Caso de Uso: Administrar Mesa
5.3.4. Casos de Uso: Gestionar Reporte
Casos de uso: Gestionar reportes.
Actores: Administrador.
Propósitos: Realizar reportes.
Resumen: El administrador Permitirá realizar una lista de reporte de cada

módulo.
Tipo: Primario.
Tabla 5. -Caso de Uso: Gestionar Reporte
61
5.4. Estructura del Modelo de Casos de Uso
Figura 12.Diagrama de Casos de Uso
62
5.5. Modelo de Dominio
Figura 13. Modelo De Dominio
63
CAPÍTULO #8
ANÁLISIS
64
CAPITULO # 8. ANÁLISIS
6.1. Análisis de la Arquitectura
Figura 14.Diagrama de Paquetes
65
6.2. Arquitectura de Casos de Uso en función al modelo del análisis
6.2.1. Módulo: Reserva y Reporte.
Módulo de Reserva y Reporte
Figura 15.Diagrama de Paquetes - Módulo de Reserva y Reporte
66
6.3 Realización de Casos de Usos-Análisis
Nombre: Administrar Reservas.
Personal Involucrado e Interés: Recepcionista.
Precondiciones: Efectuar una reserva previa.
Garantía de éxito: Tiempo de llegada puntual, mesa disponible.
Acción del Actor Responsabilidad del Sistema
La recepción del cliente al momento de Verificar la reserva del cliente.

llegada al restaurante.
Extensiones (flujos alternativos)
La hora de la llegada del cliente puede ser antes o después de la hora de dicha
reserva.
Tabla 6. Formato de Descripción de Procesos – Administrar Reserva
Nombre: Administrar Clientes.
Personal Involucrado e Interés: Administrador.
Precondiciones: Llegada del cliente.
Garantía de éxito: Mesa disponible.
La recepción del cliente al momento de Verificar la reserva del cliente.

llegada al restaurante.
La llamada del cliente mediante al restaurante.
Tabla 7. Formato de Descripción de Procesos – Administrar Clientes.
67
Nombre: Administrar Mesas.
Precondiciones: Llegada del cliente.
Garantía de éxito: Mesa disponible.
Se encargará de la disponibilidad de las Gestionar mesa.

mesas.
Agregar mesas si fuera disponible si el cliente lo requiere.
Tabla 8.Formato de Descripción de Procesos – Administrar Mesas
Nombre: Gestionar Reportes.
Actores: Administrador.
Precondiciones: Registrar una reserva.
Garantía de éxito: Que exista una reserva previa.
Se encargará de administrar los Gestionar los reportes.

reportes.
La recepcionista puede generar reporte
Tabla 9. Formato de Descripción de Procesos – Gestionar Reporte
68
6.3.1 Especificación de Casos De Uso
Figura 16. Diagrama de Colaboración - Gestionar Cliente
69
Figura 17. Diagrama de Colaboración - Gestionar Reserva
70
Figura 18. Diagrama de Colaboración - Gestionar Mesa
71
Figura 19. Diagrama de Colaboración - Gestionar Reporte
72
Nombres: Gestionar clientes
Actores: Recepcionista
Personal involucrado e intereses: la recepcionista requiere atender a los clientes
Precondiciones: Ninguna
Garantía de éxito: La recepcionista debe haber corroborado los datos del

cliente(teléfono, dirección, nombre etc.)
Escenario principal de éxito (flujo básico)
Acción del Actor Responsabilidad del sistema
1 accede a la pantalla del restaurante. 1 Muestra la pantalla de cliente
2 solicita registrar clientes. 2 Solicita información de registro
2.1. Introduce los datos 2.1. Valida los datos
2.2. Registra el nuevo cliente 2.2. Guarda los datos
3 visualiza información de cliente. 3 Muestra la información del cliente
3.1. Introduce datos a modificar 3.1. Valida los datos
3.2. Modifica al cliente 3.2. Guarda los datos
4 solicita eliminar un cliente. 4 Muestra mensaje de confirmación
4.1. Brinda confirmación de la 4.1. Valida referencia del cliente

acción 4.2. Elimina el cliente
5 Proporciona filtro de búsqueda 5 Realiza búsqueda y muestra el
5.1. Visualiza el detalle de cualquier resultado
cliente en el resultado de búsqueda
1. Un cliente llama o recurre personalmente a la empresa
Tabla 10. Especificación de Caso de Uso: Gestionar Cliente
73
Nombres: Gestionar reservas
Garantía de éxito: La recepcionista debe haber corroborado los datos del

cliente(teléfono, dirección, nombre etc.) y la disponibilidad de las mesa.
1. Accede a la pantalla del restaurante. 1. Muestra la pantalla del restaurante.
2. Solicita registrar reserva. 2. Solicita información de reserva.
2.1. Introduce los datos de la 2.1. Valida los datos

reserva. 2.2. Guarda los datos
2.2. Registra. 3. Muestra la información de la mesa
3. Visualiza el estado de la mesa. 3.1. Valida los datos
3.1. Modifica datos. 3.2. Guarda los datos
3.2. Modifica. 4. Muestra mensaje de confirmación
4. Solicita eliminar reserva. 4.1. Valida referencia del cliente
4.1. Confirma solicitud. 4.2. Elimina el cliente
5. Proporciona filtro de búsqueda 5. Realiza búsqueda y muestra el
5.1. Visualiza detalle. resultado
1. la recepcionista atiende al cliente.
Tabla 11. Especificación de Caso de Uso: Gestionar Reserva
74
Nombres: Gestionar mesas
Garantía de éxito: La recepcionista debe consultar si existe mesa disponible
1. Accede a la pantalla del restaurante 1. Muestra la pantalla del restaurante
2. Verifica mesa para la reserva. 2. Solicita información de la mesa
2.1. Introduce los datos de la reserva 2.1. Valida los datos
2.2. Registra 2.2. Guarda los datos
3. Visualiza el estado de la mesa 3. Muestra la información de la mesa
3.1. Modifica datos 3.1. Valida los datos
4. Solicitar cambio de reserva. 3.2. Guarda los datos
4.1. Confirmar solicitud 4. Muestra mensaje de confirmación
4.1. Valida referencia de la mesa
4.2. Elimina la mesa
1. Agregar mesa si fuera disponible
Tabla 12. Especificación de Caso de Uso: Gestionar Mesa
75
Nombres: Gestionar reportes
Actores: Administrador
Personal involucrado e intereses: Administrador
Garantía de éxito: tener los datos de los clientes.
1. Accede a la pantalla del restaurante. 1. Muestra la pantalla del restaurante.
2. Solicita obtener reporte. 2. Solicita información de reporte.
2.1. Introduce los datos. 2.1. Valida los datos
3. Visualiza información del reporte. 2.2. Guarda los datos
4. Solicita eliminar reporte. 3. Muestra la información del reporte.
4.1. Confirma solicitud. 3.1. Valida los datos
5. Proporciona filtro de búsqueda 3.2. Guarda los datos
5.1. Visualiza detalle. 4. Muestra mensaje de confirmación
4.1. Valida referencia
4.2. Eliminar
5. Realiza búsqueda y muestra el

resultado
1. la recepcionista puede generar reporte.
Tabla 13. Especificación de Caso de Uso: Gestionar Reporte
76
6.4. Diagrama de Clases del Análisis
Figura 20. Diagrama de Clase del Análisis
77

Analisis de Sistema 1 02-12-17

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Analisis de Sistema 1 02-12-17

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDAD DE AQUINO BOLIVIA

FACULTAD DE CIENCIA Y TECNOLOGÍA

CARRERA DE INGENIERÍA DE SISTEMAS

SISTEMA DE INFORMACIÓN PARA RESERVAS DE UN

Saavedra Alvarez Brian Ruddy

Segurondo Aramayo Erwin Humberto

Santa Cruz – Bolivia

CAPÍTULO # 1. DESCRIPCIÓN DEL PROYECTO ...................................................... 2

Figura 1. Límite Sustantivo ....................................................................................................... 6

Tabla 1. Lista De Requerimientos ......................................................................................... 58

En el presente proyecto se desarrolló un sistema de información para un restaurante

Para la solución al problema de reserva será implementar un sistema de información

1.4.1. Límite Espacial

1.4.2. Límite Temporal

De 23 de agosto de 2017 hasta 20 de junio de 2018 se estudiará a profundidad el

Módulo de Reserva Módulo de Reporte Módulo de Seguridad

Gestionar Reserva Reporte de Reserva

Figura 1. Límite Sustantivo

1.5.1 Objetivo General

Desarrollar un sistema información para la reserva de un restaurante

 Construir el modelo de negocios con diagramas de actividades en base a

1.6.1. Justificación Técnica

1.6.2. Justificación Personal

Es habitual que, en este tipo de restaurante, el proceso de reserva se realice de forma

La metodología que servirá para el sistema de información será la “Unificada” con el

2.1. Arquitectura de implementación

Una arquitectura de implementación se crea asignando los bloques de construcción

2.2. Arquitectura de desarrollo

es un conjunto de patrones que proporcionan un marco de referencia necesario para

Concepto sobre la Metodología

Según su sitio web, el Object Management Group® (OMG®) es un consorcio

• Metamodelo Define el lenguaje y los procesos a partir de los cuales formar un

Estos son algunos conceptos fundamentales de un mundo orientado a objetos:

La metodología RUP utiliza el enfoque de la orientación a objetos en su diseño y

Para la gestión del proyecto, la metodología RUP proporciona una solución

El uso de modelos visuales de software en la metodología RUP

proyecto en un instante dado. Para capturar la dimensión temporal de un proyecto, RUP

• Iniciación o Diseño: énfasis en el alcance del sistema;

Las capas se componen de iteraciones. Iteraciones son ventanas de tiempo;

Ejecutar en un entorno de ejecución específica, las tareas y las funciones

3.1. Proyecto Sistema de Gestión de Pedidos

La situación habitual en un restaurante en cuanto a pedidos, tiempo de espera,

En el actual ámbito de desarrollo, el sistema será implementado y testeado sin la

Automatizar la gestión de pedidos de una empresa relacionada con el sector de la

El proyecto está pensado para restaurantes que no dispongan de un sistema

Después de haber analizado distintas necesidades de restaurantes que no disponen de

Se ha implementado toda la funcionalidad que se ha propuesto anteriormente. Las más

 Administrador: Gestión de productos, mesas y facturas.

Figura 2. Interfaz Gestionar Mesa

Figura 3. Interfaz Administrador

Figura 4. Interfaz Seleccionar Mesa

Figura 5. Interfaz Gestión de Pedidos

El proyecto está pensado para restaurantes que no dispongan de un sistema

 PC/MAC 2.0 GHz, 1Gb memoria, 1 Gb de disco duro.

3.2. Proyecto Sistema de Información de Restaurante

individuales de transporte y alojamiento, debe contar con un sistema de reservas por

creativo, análogo a lo que en la construcción de una vivienda sería la elaboración de los

tienen que interactuar entre si generando interdependencias que a veces no son

En la terminología SCRUM se denominan Sprint. SCRUM es la metodología de desarrollo

3.3. Restaurante: Prototipo de un Restaurante Digital

Formulación Del Problema

Estructura Del Proyecto

 Sistema. Conjunto de partes interrelacionadas, hardware, software y de recurso

Modelado). Se trata de un lenguaje gráfico para visualizar, especificar, construir y