Informe Sistema

Sistema informático para la administración interna y control del servicio de
atención al cliente para el restaurante “Samaritana.”.
“Año de la Inversión para el Desarrollo Rural y la Seguridad Alimentaria”
Facultad de ingeniería
Escuela profesional de ingeniería informática y de sistemas
Título del Proyecto:
Implementar un Sistema informático para la administración interna y control del

servicio de atención al cliente para el restaurante “Samaritana.”.
Asignatura :
Practicas Pre Profesionales II
Autores :
Erick Reyes Torres
Asesor :
Ing. Oscar Valdivia Ascon
Ciclo :
VII
Chimbote, Abril del 2014
PERÚ
1
DEDICATORIA
Dedico este proyecto de tesis a Dios y a

mis padres. A Dios porque ha estado
conmigo a cada paso que doy, cuidándome
y dándome fortaleza para continuar.
A mis padres, quienes a lo largo de mi vida

han velado por mi bienestar y educación
siendo mi apoyo en todo momento.
Depositando su entera confianza en cada
reto que se me presentaba sin dudar ni un
solo momento en mi inteligencia y
capacidad.
Es por ello que soy lo que soy ahora. Los

amo con mi vida.
JÑ
2
AGRADECIMIENTO
En primer lugar nuestro agradecimiento va

brindado para nuestro Señor Dios por ser
nuestro guía y permitirnos crecer cada día
como ser humano.
Agradecemos a nuestro asesor por brindarnos

apoyo para poder llevar a cabo el proyecto y
motivarnos cada día con sus enseñanzas para
ser unos profesionales de éxito.
3
ÍNDICE
1. CARATULA………………………………………………………………………..….1
2. DEDICATORIA…………………………………………………………………..…...2
3. AGRADECIMIENTO……………………………………………………………..…..3
4. ÍNDICE……………………………………………………………………………..….4
5. RESUMEN……………………………………………………………………..……...5
6. ABSTRACT………………………………………………………………………..….6
7. INTRODUCCIÓN…………………………………………………………………..…7
8. DATOS GENERALES DE LA ORGANIZACIN………………………..….……..8
8.1. NOMBRE DEL PROYECTO………………………………..……….…….9

8.2. DESCRIPCIÓN DEL PROYECTO……………………………….…...….9
8.3. LOGOTIPO DE LA ORGANIZACIÓN………………………………...….9
8.4. RAZÓN SOCIAL DE LA ORGANIZACIÓN: NOMBRE, DIRECCIÓN,
FONO, E- MAIL……………………………………………………………..9
8.5. DESCRIPCIÓN DE LA ORGANIZACIÓN………………………………..10
8.6. ORGANIGRAMA……………………...……………………………………10
9. DATOS DE LA INVESTIGACION……………………………………..….……..11
9.1. SITUACIÓN PROBLEMÁTICA……………………………………..……..12

9.1.1. DESCRIPCIÓN DE LA ORGANIZACIÓN……………………………12
9.1.2. SELECCIÓN DEL PROBLEMA………………………………………12
9.1.3. ANTECEDENTES DEL PROBLEMA………………………………..13
9.2. JUSTIFICACIÓN DEL PROYECTO………………………………………13

9.2.1. JUSTIFICACIÓN TÉCNICA…………………………………………...13
9.2.2. JUSTIFICACIÓN OPERATIVA………………………………………13
9.2.3. JUSTIFICACIÓN ECONÓMICA………………………………………14
9.3. OBJETIVOS DEL PROYECTO……………………………………………14

9.3.1. OBJETIVO GENERAL…………………………………………………14
9.3.2. OBJETIVO ESPECIFICO…………………………………..…………14
9.4. LIMITACIONES DEL PROYECTO……………………….…….…………15

9.4.1. LIMITACIÓN CRONOLOGÍA…………………………………….……15
9.4.2. LIMITACIÓN TECNOLÓGICA…………………………………..…….15
9.4.3. LIMITACIÓN TÉCNICA………………………………………………...15
4
10. MARCO TEÓRICO ……………………………….………………………………17
10.1. METODOLOGÍA DE DESARROLLO RUP……………………..… 18-19

10.2. CICLOS Y FASES RUP……………………………………………….20-24
10.3. UML…………………………………………………………………...…24-29
10.4. ARQUITECTURA CLIENTE-SERVIDOR………………………………..30
10.5. SISTEMAS ADMINISTRADORES DE BASE DE DATOS ………..31-32
10.6. LENGUAJE DE PROGRAMACION ………………………..………..33-34
10.7. TECNICA DE PROGRAMACION ………………………..……………...35
10.8. ARQUITECTURA WEB ………….………………………..……………...36
5
RESUMEN
El proyecto consiste en el diseño e implantación de un sistema para la gestión

de un restaurante que ayude a mejorar el servicio a sus clientes y a optimizar el
tiempo y esfuerzo de sus empleados. Al lograr una mayor satisfacción de los
clientes y una mayor productividad en la toma y preparación de los pedidos, se
conseguirá aumentar los beneficios obtenidos en el restaurante
Se ha dividido el sistema en varios procesos fundamentales, uno es el área de

almacén de bebidas, módulo de mesas, pedidos de comandas, ventas y
reservaciones. Estos procesos ofrecen una funcionalidad distinta, y juntos
controlan de forma integral diversos factores sobre el desarrollo y gestión del
negocio del restaurante.
El área de almacén se encarga de llevar el control correcto de las Entradas y

Salidas de los productos de bebidas. Las Entradas serán relacionadas con los
proveedores y las Salidas para los clientes de consumo.
El módulo de las mesas de forma gráfica en el sistema que se mostrara el
estado disponible de cada una de las mesas del salón del restaurante.
El sistema permitirá registrar pedidos de comandas solicitados por los clientes,
de forma que se tenga a la mano siempre lo que el cliente ha solicitado, para
su preparación e informe del consume.
La venta se realizara por los usuarios de caja una vez consumido el pedido por
el cliente para su respectivo cobro, emitiendo una factura o boleta de pago.
En el proceso de reservación solo clientes registrados (mayor de edad) podrán
reservar mesas para una fecha y hora especificada
Gracias a estos procesos podemos lograr una gran variedad de información

generando reportes rápidamente que son utilices para el administrador del
restaurante. Así poder ver los logros y llevar una buena gestión del negocio.
6
Abstract
The project involves the design and implementation of a management system

for a restaurant to help improve customer service and optimize the time and
effort of its employees. To achieve greater customer satisfaction and increased
productivity in making and preparation of orders, it will get increased profits in
the restaurant
System has been divided in several fundamental processes, one is the

beverage storage area, table’s module, and you command orders, sales and
reservations. These processes offer different functionality and comprehensively
together control various factors on the development and management of the
restaurant business.
The storage area is responsible for maintaining proper control of the inputs and
outputs of the beverage products. Tickets will be related to Outputs providers
and consumer customers.
The module tables graphically in the system that is available showing the status
of each of the tables in the restaurant lounge.
The system will log you command orders requested by customers, so that you
always have on hand what the client has asked for report preparation and
consumption.
The sale will be made by user’s box once consumed the order by the customer
to their respective collection, issuing an invoice or payment.
In the reservation process registered customers only (minor) may reserve tables
for a date and time specified
Through these processes we can achieve a variety of information quickly

generate reports that are used to the restaurant manager. So we can see the
achievements and bring good business management.
7
INTRODUCCIÓN
En el presente proyecto utilizamos todos los pasos necesarios para poder

realizar un sistema para una organización siguiendo los pasos del RUP y el
UML, usando los artefactos de análisis, diseño de interfaces y procesos de
construcción.
El proyecto empieza con la investigación acerca del Organización en nuestro

caso el Restaurante “Samaritana”, en la cual sus datos son llenados
manualmente en hojas por lo que realizaremos un Sistema informático para
mejorar la administración interna y control del servicio de atención al cliente.
Realizando lo siguiente:
 Modelamiento del Negocio: Pictograma, Modelo de casos de uso del

Negocio, Diagrama de actividad de cada uso de Negocio, Modelo de Objetos
del Negocio y Modelo de Dominio. Donde se hace el dominio total de los
procesos (sistema) de la organización. Se conoce al detalle cómo se
desarrollan los procesos de negocio del sistema. Se descubre paso a paso
cómo funciona el caso de negocio.
 Modelo de Requerimientos: Modelo de Casos de uso de Requerimientos

Detallado, Diagrama de Casos de uso de Requerimientos. Donde se hace la
captura de requerimientos, la coordinación del equipo de desarrollo, la
validación de resultados, se valida los procesos. En el Diagrama de
Requerimientos, se indica las cosas que el sistema tiene que hacer e
implementar; y también quién usará cada caso de uso.
 Análisis: Diagrama de Colaboración, Diagrama de Clases Entidad, Diagrama

de Clases de Análisis, Diagrama de Paquetes de Análisis.
 Diseño: Interfaces de Usuario, Diagramas de secuencia de Diseño, Diagramas

de Clases de Diseño, Diagramas de Estado. Para lo cual usaremos las Reglas
de Oro y los procesos de Construcción, las Guías de Estilo. Esto, para conocer
cómo interactúan los objetos. Es importante también porque identificamos qué
objetos son usados antes que otros.
8
CAPITULO I
DATOS GENERALES DE LA
ORGANIZACION
9
8.1. NOMBRE DEL PROYECTO:
“Implementa un Sistema informático para la administración interna y control del

servicio de atención al cliente para el restaurante “Samaritana.”.”
8.2. DESCRIPCIÓN DEL PROYECTO:
El presente proyecto se realizará para ayudar al personal operativo, clientes

y a la administración del Restaurante. Está focalizado a la sistematización
en los procesos que desarrolla el restaurante, permitiendo llevar un mayor
control, suministración y administración de cada uno de los procesos
(producción, control de insumos y ventas) enfocado a las comandas,
órdenes de compras, reservaciones y documentos de venta.
El proceso completo desde el pedido, pasando por el almacén hasta caja
estará sistematizado.
8.3. LOGOTIPO DE LA ORGANIZACIÓN:
8.4. RAZÓN SOCIAL DE LA ORGANIZACIÓN:
o Organización:
Restaurante Samaritana
o Dirección :
Panamericana Norte Km 439 – Coishco – Santa
o Teléfono :
41*654*6018
10
8.5. DESCRIPCIÓN DE LA ORGANIZACIÓN:
8.5.1. Visión y Misión de la Organización:
 Misión
Ofrecer al cliente, un servicio de calidad, que se desarrolle en un
ambiente propicio para disfrutar de la mejor comida y las mejores
bebidas a una relación de precio, calidad excelente para satisfacer las
necesidades y deseos de nuestros clientes.
 Visión
Ser reconocidos como el mejor restaurante de la ciudad de Coishco,

además de ser un restaurante original, sólido y profesional, con calidad
humana y principios éticos, que ofrece servicios y productos de
excelencia.
Lograr una empresa altamente productiva, innovadora, competitiva y
dedicada para la satisfacción plena de nuestros clientes.
8.6. ORGANIGRAMA:
Organigrama
Fuente: Elaboración Propia
11
CAPITULO II
DATOS DE LA
INVESTIGACIÓN
12
8.7. SITUACIÓN PROBLEMÁTICA

8.7.1. Descripción De Situación Problemática:
La atención de los pedidos en almacén en los procesos de entrada y

salida de productos no cuentan con un control sistematizado por tal
motivo no conocen el stock ocasionando perdías de productos y dinero,
el registro de reservas, son manualmente en hojas escrito por los
trabajadores en algunas casos estas anotaciones son pérdidas o
extraviadas y ocasiona una mal administración en el momento de
atención al cliente. En el proceso de comandas y el control de los
mismos se realizan de manera manual, ocasionando un desorden en las
llegas de comandas y provoca molestia a los clientes por lo que la
calidad del servicio es regular. En conjunto, todas estas variables
ocasionan malestar entre los comensales, llegando incluso a la pérdida
de clientes, perdida de dinero y confusiones en los procesos, siendo un
restaurante de mucho prestigio en la cuidad.
8.7.2. Selección Del Problema
Debido a lo anteriormente descrito se percibe insatisfacción por parte de

sus clientes, lo cual se ve reflejado en pérdidas económicas para el
restaurante.
De tal manera se tendrá que Implementar un Sistema informático para el
control del servicio de atención al cliente en el restaurante “Samaritana.”
8.7.3. Antecedentes Del Problema
Una de las aplicaciones más usadas en la capital del País son las del
Software Restaurante Punto de Venta, destinado para cafeterías, bares
y restaurantes. Existiendo varias versiones del mismo.
SIRBA Restaurante y Bares 1.0, es una aplicación destinada a optimizar
las operaciones de restaurantes y bares proporcionando control de las
operaciones efectuadas en el restaurante
A nivel local por el momento no existe ningún restaurante que cuente

con un sistema igual o parecido al que deseamos implementar; pero a
13
nivel nacional, si existen referencias de sistemas similares al que

desarrollaremos, como es el caso de un restaurantes de lima, que
cuenta con una pantalla digital en la entrada del restaurante, en la cual
aparece un croquis del restaurante con la ubicación de las mesas, en el
cual la persona tiene que elegir el lugar que ocupará, colocar la cantidad
de personas que ocuparán la mesa y posteriormente aparecerá el menú
del día junto a una pequeña lista por persona, en la que se registrará los
platos que ésta eligió, una vez efectuada la orden ésta es enviada a
cocina para su preparación. Cuentan con sistemas web mostrando los
menús del día y realizar la reservación online.
8.7.4. Formulación Interrogativa Del Problema
¿De qué manera un Sistema informático puede mejorar la administración

interna y control del servicio de atención al cliente para el Restaurante
“Samaritana”?
8.8. Justificación del Proyecto
8.8.1. Justificación Técnica
 Brindar un soporte de información adecuado y eficiente, mediante el

desarrollo de un sistema informático para el control de los procesos y la
administración que se llevan a cabo en el restaurante “SAMARITANA”
 Implementar un soporte de información online que interactúe con el

restaurante para los usuarios mediante un sitio web.
8.8.2. Justificación Operativa
 El manejo de información segura y confiable.

 El cliente resultará más satisfecho por la atención rápida que se le
brindará, ya que el sistema ahorrará mucho tiempo, pues todo lo tendrá
registrado y actualizado en la PC
 Con el sitio web el cliente gozara desde la zona donde se encuentre la
información necesaria de lo que existe en el restaurante.
 Facilidad del manejo de los procesos en el sistema de información
gracias a una interfaz Gráfica fácil de usar para el usuario.
14
 Permitiendo agilizar el proceso completo desde el pedido, pasando por

la cocina hasta caja estará computarizado, permitiendo agilizar el
proceso de atención al cliente, brindando un buen servicio y obteniendo
gran información estadísticas para la toma de decisiones del negocio.
8.8.3. Justificación Económica
 Con el desarrollo de proyecto disminuirán las pérdidas económicas, ya

que en el sistema estarán registradas todas las transacciones que se
realizaron en el día.
 Para el desarrollo del sistema se usarán herramientas como Microsoft
Visual Studio 2010 Express, es una versión gratuita, y puede ser usada
en empresas pequeñas y medianas ya que cuenta con lo necesario para
poder administrarlas; y para el manejo de la base de datos se hará uso
del SQL Server 20010 Express, ésta versión es gratuita, y permite la
construcción de aplicaciones robustas, ofreciendo una sencilla pero
potente base de datos. Por lo tanto la empresa no tendrá que gastar en
licencia para éstos productos, ya que además de ser gratuitos le
brindarán lo necesario para el manejo de su empresa.
8.9. OBJETIVOS DEL PROYECTO
8.9.1. Objetivo General
Implementar un Sistema informático para la administración interna y

control del servicio de atención al cliente para el restaurante
“Samaritana.”.
8.9.2. Objetivo Especifico
 Recopilar y clasificar la información de la institución capturando los

requerimientos que plantee en las diferentes áreas del restaurante.
Analizar la situación problemática actual por la que está pasando la
Institución.
 Realizar el modelado de negocios aplicando el Proceso Unificado de
Rational (RUP).
15
 Analizar un diseñar el sistema aplicando RUP y utilizando la Herramienta

Case Rational Rose.
 Realizar el modelo de la base de datos utilizando la herramienta Case
Erwin.
 Crear el sistema informático (Escritorio) y el sistema gestor de base de
datos SQL server 2010 utilizando como herramienta de desarrollo
Microsoft Visual Studio 2010.
 Implementar el Sitio web en Asp.net con Visual Studio 2010 y Sql 2010
8.10. LIMITACIONES DEL PROYECTO
8.10.1. Limitación Cronología
 El Sistema Informático que se llevara a cabo será en un plazo corto de 4

meses, por lo que se tendrá que acelerar en el desarrollo de los
objetivos mencionados anteriormente de la Empresa, para que de esa
manera se pueda cumplir con lo prometido.
8.10.2. Limitación Tecnológica
 El restaurante actualmente realiza sus operaciones y sus registros en

documentos los cuales se encuentran archivados por el tiempo, como
también Hojas de Cálculo, por ello se retrasaría al momento de
desarrollar los procesos cotidianos.
8.10.3. Limitación Técnica
 Poco dominio por parte de los integrantes del equipo de desarrollo en

Modelamiento.
 Falta de destreza en la definición clara de los objetivos..
 Baja experiencia en los trabajadores al utilizar el sistema informático por
no estar familiarizados.
 La empresa por el momento no cuenta con el equipo necesario para
realizar el funcionamiento de este sistema, ya que todos los registros lo
realizan a mano.
16
CAPITULO III
MARCO TEORICO
17
10.1. METODOLOGÍA DE DESARROLLO: RUP (Racional Unified Process)
RUP es un proceso para el desarrollo de un proyecto de un software que

define claramente quien, cómo, cuándo y qué debe hacerse en el
proyecto. Es un lenguaje gráfico para visualizar, especificar, construir y
documentar un sistema. Se usa para entender, diseñar, configurar,
mantener y controlar la información sobre los sistemas a construir.
RUP Implementa las mejores prácticas en Ingeniería de Software:
 Desarrollo interactivo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelo visual del software
 Verificación de la calidad del software
Características:
 Proporciona a los desarrolladores un lenguaje de moldeamiento

ampliamente aceptado y listo para usar.
 Integra las mejores prácticas del desarrollo del software.
 Permite el intercambio de modelos entre las diferentes herramientas
de software.
 Es independiente del lenguaje de propagación y de métodos y
procesos particulares.
Como 3 características esenciales está dirigido por los Casos de Uso:

que orientan el proyecto a la importancia para el usuario y lo que este
quiere, está centrado en la arquitectura: que Relaciona la toma de
decisiones que indican cómo tiene que ser construido el sistema y en
qué orden, y es iterativo e incremental: donde divide el proyecto en mini
proyectos donde los casos de uso y la arquitectura cumplen sus
objetivos de manera más depurada. Como filosofía RUP maneja 6
principios clave:
18
 Adaptación Del Proceso
El proceso deberá adaptarse a las características propias de la

organización. El tamaño del mismo, así como las regulaciones que lo
condicionen, influirán en su diseño específico. También se deberá tener
en cuenta el alcance del proyecto.
 Balancear Prioridades
Los requerimientos de los diversos inversores pueden ser diferentes,

contradictorios o disputarse recursos limitados. Debe encontrarse un
balance que satisfaga los deseos de todos.
 Colaboración Entre Equipos
El desarrollo de software no lo hace una única persona sino múltiples

equipos. Debe haber una comunicación fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes, resultados, etc.
 Demostrar Valor Iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas

iteradas. En cada iteración se analiza la opinión de los inversores, la
estabilidad y calidad del producto, y se refina la dirección del proyecto
así como también los riesgos involucrados.
 Elevar El Nivel De Abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales

como patrón del software, lenguajes 4GL o esquemas (frameworks) por
nombrar algunos. Éstos se pueden acompañar por las representaciones
visuales de la arquitectura, por ejemplo con UML.
 Enfocarse En La Calidad
El control de calidad no debe realizarse al final de cada iteración, sino en

todos los aspectos de la producción.
19
10.2. EL CICLO DE VIDA DE RUP
RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias

iteraciones en número variable según el proyecto y en las que se hace
un mayor o menor hincapié en los distintas actividades.
En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes

actividades
o Inicio: Se hace un plan de fases, se identifican los principales

casos de uso y se identifican los riesgos. Se define el alcance del
proyecto
o Elaboración: Se hace un plan de proyecto, se completan los

casos de uso y se eliminan los riesgos.
o Construcción: sé concentra en la elaboración de un producto

totalmente operativo y eficiente y el manual de usuario
o Transición: sé Instala el producto en el cliente y se entrena a los

usuarios. Como consecuencia de esto suelen surgir nuevos
requisitos a ser analizados.
20
A. FASE DE INICIO:
Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en

actividades modelado del negocio y de requisitos.
 Modelado del Negocio:
En esta fase el equipo se familiarizará más al funcionamiento de la empresa,

sobre conocer sus procesos.
 Entender la estructura y la dinámica de la organización para la cual el
sistema va ser desarrollado.
 Entender el problema actual en la organización objetivo e identificar
potenciales mejoras.
 Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento común de la organización objetivo.
 Requisitos:
En esta línea los requisitos son el contrato que se debe cumplir, de modo que
los usuarios finales tienen que comprender y aceptar los requisitos que
especifiquemos.
 Establecer y mantener un acuerdo entre clientes y otros stakeholder s
sobre lo que el sistema podría hacer.
 Proveer a los desarrolladores un mejor entendimiento de los requisitos
del sistema.
 Definir el ámbito del sistema.
 Proveer una base para estimar costos y tiempo de desarrollo del
sistema.
 Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.
21
B. FASE DE ELABORACIÓN
En la fase de elaboración, las iteraciones se orientan al desarrollo de la base

line de la arquitectura, abarcan más los flujos de trabajo de requerimientos,
modelo de negocios (refinamiento), análisis, diseño y una parte de
implementación orientado a la base line de la arquitectura.
 Análisis y diseño
En esta actividad se especifican los requerimientos y se describen sobre cómo

se van a implementar en los sistemas
 Transformar los requisitos al diseño del sistema.
 Desarrollar una arquitectura para el sistema.
 Adaptar el diseño y sea consistente con el entorno de implementación
C. FASE DE CONSTRUCCIÓN
 Implementación
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y

demás. El resultado final es un sistema ejecutable.
 Planificar qué subsistemas deben ser implementados y en qué orden
deben ser integrados, formando el Plan de Integración.
 Cada implementador decide en qué orden implementa los elementos
del subsistema.
 Si encuentra errores de diseño, los notifica.
 Se integra el sistema siguiendo el plan.
22
 Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que

estamos desarrollando, pero no para aceptar o rechazar el producto al final del
proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
 Encontrar y documentar defectos en la calidad del software.
 Generalmente asesora sobre la calidad del software percibida.
 Provee la validación de los supuestos realizados en el diseño.
 Verificar las funciones del producto de software según lo diseñado.
 Verificar que los requisitos tengan su apropiada implementación.
 Despliegue
Esta actividad tiene como objetivo producir con éxito distribuciones del
producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:
 Probar el producto en su entorno de ejecución final.
 Empaquetar el software para su distribución.
 Distribuir el software.
 Instalar el software.
 Proveer asistencia y ayuda a los usuarios.
 Formar a los usuarios y al cuerpo de ventas.
 Migrar el software existente o convertir bases de datos.
D. FASE DE TRANSICIÓN
El objetivo es traspasar el software desarrollado a la comunidad de usuarios.

Una vez instalado surgirán nuevos elementos que implicarán nuevos
desarrollos (ciclos).Incluye:
 Pruebas Beta para validar el producto con las expectativas del cliente
 Ejecución paralela con sistemas antiguos
 Conversión de datos.
 Entrenamiento de usuarios
 Distribuir el producto
23
E. FASE DE MANTENIMIENTO
Una vez instalado el producto, el usuario realiza requerimiento de ajustes, esto

se hace de acuerdo a solicitudes generadas como consecuencia de actuar con
el producto.
10.3. LENGUAJE UNIFICADO DE MODELADO (UML)
Es un lenguaje de modelado visual que se usa para especificar, visualizar,

construir y documentar artefactos de un sistema de software. Se usa para
entender, diseñar, configurar, mantener y controlar la información sobre los
sistemas a construir.
 Arquitectura de UML
Un sistema puede ser visto de diferentes perspectivas y puntos de vista UML,

propone cinco puntos de vista mediante las cuales se puede visualizar un
sistema.
 Use Case View

 Design View
 Process View
 Implementación View
 Diplomen View
24
 Características de UML
- Proporciona a los desarrolladores un lenguaje de modelamiento

ampliamente aceptado y listo para usar.
- Integra las mejores prácticas del desarrollo de software.
- Permite el intercambio de modelos entre las diferentes herramientas de
software.
- Es independiente del lenguaje de programación y de métodos y
procesos particulares de desarrollo de software.
- Proporciona sus propios mecanismos de extensión:
Diagramas:
 DIAGRAMA DE CASO DE USO:
Un diagrama de Caso de Uso representa lo que hace el sistema y como se

relaciona con su entorno.
Representa los distintos requerimientos que hacen los usuarios de un
sistema. Un diagrama de casos de uso está compuesto por:
 Caso de uso
 Actores
 Relaciones entre ellos
25
 DIAGRAMA DE OBJETOS:
Son utilizados durante el proceso de análisis y diseño de los sistemas

informáticos en la metodología UML. Se puede considerar un caso especial de
un diagrama de clases en el que se muestran instancias específicas de clases
(objetos) en un momento particular del sistema. Los diagramas de objetos
utilizan un subconjunto de los elementos de un diagrama de clase. Los
diagramas de objetos no muestran la multiplicidad ni los roles, aunque su
notación es similar a los diagramas de clase.
 DIAGRAMA DE ACTIVIDADES:
Representa los flujos de trabajo paso a paso de negocio y operacionales de los

componentes en un sistema. Un Diagrama de Actividades muestra el flujo de
control general.
26
 DIAGRAMA DE COLABORACIÓN:
Muestran explícitamente las relaciones de los roles. Por otra parte, un

diagrama de colaboración no muestra el tiempo como una dimensión
aparte, por lo que resulta necesario etiquetar con números de secuencia
los mensajes.
Muestra como las instancias específicas de las clases trabajan juntas
para conseguir un objetivo común.
 DIAGRAMA DE CLASES:
Es un tipo de diagrama estático que describe la estructura de un sistema

mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de
clases son utilizados durante el proceso de análisis y diseño de los sistemas,
donde se crea el diseño conceptual de la información que se manejara en el
sistema, y los componentes que se encargaran del funcionamiento y la relación
entre uno y otro. Por Ejemplo:
27
 DIAGRAMA DE COMPONENTES:
Es un diagrama tipo del Lenguaje Unificado de Modelado. Un diagrama de

componentes representa la separación de un sistema de software en
componentes físicos (por ejemplo archivos, cabeceras, módulos, paquetes,
etc.) y muestra las dependencias entre estos componentes. Debido a que estos
son más parecidos a los diagramas de casos de usos estos son utilizados para
modelar la vista estática de un sistema. Muestra la organización y las
dependencias entre un conjunto de componentes.
 DIAGRAMA DE DESPLIEGUE:
Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para

modelar el hardware utilizado en las implementaciones de sistemas y las
relaciones entre sus componentes.
28
 DIAGRAMA DE PAQUETES:
Muestra como un sistema está dividido en agrupaciones lógicas mostrando las

dependencias entre esas agrupaciones. Dado que normalmente un paquete
está pensado como un directorio, los diagrama s de paquetes suministran una
descomposición de la jerarquía lógica de un sistema. Los Paquetes están
normalmente organizados para maximizar la coherencia interna dentro de cada
paquete y minimizar el acoplamiento externo entre los paquetes.
 Diagrama de Secuencia:
Muestra la secuencia de mensajes entre objetos durante un escenario

concreto. Cada objeto viene dado por una barra vertical. Se llama línea de
vida. El tiempo transcurre de arriba abajo.
Cada mensaje se representa mediante una flecha entre las líneas de vida y
cada mensaje se etiqueta con el nombre del mensaje y pueden incluirse los
argumentos.
Los rectángulos en las líneas de vida indican el tiempo en el cual un
método está activo.
29
10.4. ARQUITECTURA CLIENTE – SERVIDOR
En los sistemas cliente-servidor, el servidor es un equipo relativamente

grande situado en una ubicación central que administra recursos utilizados
por varios individuos. Cuando los individuos tienen que utilizar un recurso,
se conectan con el servidor desde sus equipos, o clientes, a través de la
red. Ejemplos de servidores son:
 Servidores de impresión.
 Administran las impresoras utilizadas por un equipo o una unidad.
 Servidores de archivos.
 Almacenan grandes archivos utilizados por un equipo o una unidad
mediante unidades de disco de gran tamaño.
Las aplicaciones del servidor suelen poder trabajar con varios clientes al
mismo tiempo. SQL Server puede operar con miles de aplicaciones clientes
simultáneos. El servidor tiene funciones que impiden que se produzcan
problemas de lógica si un usuario intenta leer o modificar los datos
actualmente utilizados por otros usuarios.
Aunque SQL Server ha sido diseñado como servidor para redes cliente-
servidor, también puede funcionar directamente como base de datos
independiente en el cliente. Esta escalabilidad y la facilidad de uso de las
funciones de SQL Server le permiten funcionar eficazmente en los clientes,
sin consumir demasiados recursos.
30
10.5. SISTEMAS ADMINISTRADORES DE BASES DE DATOS
10.5.1. Base de Datos:
Conjunto de datos persistentes que pertenecen al mismo contexto que

es utilizado por los sistemas de aplicación.
La palabra datos se deriva del vocablo latín para “dar”; por lo tanto, los
datos en realidad son hechos dados, a partir de los cuales es posible
inferir hechos adicionales. (Inferir hechos adicionales a partir de hechos
dados es exactamente lo que hace el Sistema Gestor de Base de Datos
cuando responde a una consulta de un usuario) Un “hecho dado”
corresponde a su vez a lo que en lógica se denomina proposición
verdadera; por ejemplo, el enunciado “El proveedor PROV001 se ubica
en Perú” podría ser una de estas proposiciones verdaderas. De aquí se
desprende que una base de datos es en realidad una colección de tales
proposiciones verdaderas.
10.5.2. Modelo De Base de Datos:
Es una definición lógica, independiente y abstracta de los objetos,

operadores y demás que en conjunto constituyen la maquina abstracta
con la que interactúan los usuarios. Los objetos nos permiten modelar la
estructura de los datos. Los operadores modelan su comportamiento.
El modelo es aquello que los usuarios tienen que conocer; la
implementación es lo que los usuarios no tienen que conocer
10.5.3. Base de Datos Relacional:
Es una base de datos que los usuarios perciben como un conjunto de

variables de relación es decir tablas. Un sistema relacional es aquel que
maneja base de datos y operaciones relacionales en dichas bases de
datos, incluyendo las operaciones restringir, proyectar y juntar en
particular. Las tablas pueden actualizarse mediante la operación de
asignación relacional; las operaciones INSERT, UPDATE y DELETE
conocidas pueden ser vistas como abreviaturas de ciertas asignaciones
relacionales comunes.
31
10.5.4. Sistema de Administración de Base de Datos:
Es el software que maneja todo acceso a la base de datos. De manera

conceptual, lo que sucede es lo siguiente:
1) Un usuario emite una petición de acceso, utilizando algún

sublenguaje de datos específico (SQL).
2) El DBMS intercepta esa petición y la analiza.
3) El DBMS inspecciona, en su momento, (las versiones objeto

de) el esquema externo para ese usuario, la transformación
externa/conceptual correspondiente, el esquema conceptual, la
transformación conceptual/interna y la definición de la
estructura de almacenamiento.
4) El DBMS ejecuta las operaciones necesarias sobre la base de

datos almacenada.
10.5.5. SQL Server 2012:
El motor de base de datos es el servicio de aplicación central en el

paquete de SQL Server para almacenar, procesar y proteger datos con
SQL Server 2012. El SQL Server 2012 base de datos del motor es un
servicio de Windows que puede utilizar para almacenar y procesar datos
en un formato relacional, como documentos XML, y los nuevos para el
año 2012, como los datos espaciales. La siguiente son las
responsabilidades principales del motor de base de datos:
• Proporcionar un almacenamiento fiable para los datos.
• Proporcionar un medio para recuperar rápidamente estos datos.
• Proporcionar un acceso consistente a los datos.
• Control de acceso a los datos de seguridad de todo.
• Hacer cumplir las reglas de integridad de datos para confirmar

que los datos sean fiables y consistentes.
• Cada una de estas responsabilidades se examina con más

detalle en capítulos posteriores de este libro.
32
10.6. LENGUAJE DE PROGRAMACION
Un lenguaje de programación es una técnica estándar de comunicación

que permite expresar las instrucciones que han de ser ejecutadas en
una computadora. Consiste en un conjunto de reglas sintácticas y
semánticas que definen un lenguaje informático.
Un programa escrito en un lenguaje de programación necesita pasar por

un proceso de compilación, es decir, ser traducido al lenguaje de
máquina, o ser interpretado para que pueda ser ejecutado por el
ordenador.
10.6.1. Visual Studio:
Visual Studio es un conjunto

completo de herramientas de
desarrollo para la generación de
aplicaciones Web ASP.NET,
Servicios Web XML, aplicaciones
de escritorio y aplicaciones móviles. Visual Basic, Visual C++, Visual C#
y Visual J# utilizan el mismo entorno de desarrollo integrado (IDE), que
les permite compartir herramientas y facilita la creación de soluciones en
varios lenguajes. Asimismo, dichos lenguajes aprovechan las funciones
de .NET Framework, que ofrece acceso a tecnologías clave para
simplificar el desarrollo de aplicaciones Web ASP y Servicios Web XML.
10.6.2. Visual Basic:

El Visual Basic ha sido desarrollado con el objetivo de entregar a los
usuarios de programación informática un paquete de utilidades simples y
accesibles. Es por esto que el Visual Basic puede ser usado y fácilmente
comprendido por expertos como también por usuarios principiantes. Su
base parte del dialecto BASIC pero con componentes novedosos que lo
adaptan a los lenguajes informáticos modernos. A esto se suma que el
Visual Basic es además un lenguaje de programación guiado por
eventos que permite mayor operatividad y mejores resultados.
33
Razones principales por las cuales se optó por elegir Visual Basic:
o Experiencias De Desarrollo, es un lenguaje conocido y utilizado

por los desarrolladores del proyecto.
o Compatibilidad, existe compatibilidad en los tipos de datos con

Microsoft SQL Server 2008, evitando posible errores de
conversión de los tipos de datos.
o Programación Orientado A Objetos, Visual Basic permite

aplicar programación orientada a objetos como: encapsulamiento,
polimorfismo y herencia de clases para construir cualquier tipo de
aplicaciones en el menor tiempo posible
10.6.3. Asp.Net :
ASP.NET es un modelo de desarrollo Web unificado que incluye los

servicios necesarios para crear aplicaciones Web empresariales con el
código mínimo. ASP.NET forma parte de .NET Framework y al codificar
las aplicaciones ASP.NET tiene acceso a las clases en .NET
Framework. El código de las aplicaciones puede escribirse en cualquier
lenguaje compatible con el Common Language Runtime (CLR), entre
ellos Microsoft Visual Basic, C#, JScript .NET y J#. Estos lenguajes
permiten desarrollar aplicaciones ASP.NET que se benefician del
Common Language Runtime, seguridad de tipos, herencia, etc.
 Rendimiento: la aplicación se compila en una sola vez al lenguaje

nativo, y luego, en cada petición tiene una compilación Just In Time,
es decir se compila desde el código nativo, lo que permite mucho
mejor rendimiento. También permite el almacenamiento del caché en
el servidor
 Rapidez en programación: mediante diversos controles, podemos
con unas pocas líneas y en menos de 5 minutos mostrar toda una
base de datos y hacer rutinas complejas.
 Servicios Web: trae herramientas para compartir datos e información
entre distintos sitios.
 Seguridad: tiene diversas herramientas que garantizan la seguridad.
34
10.7. TECNICA DE PROGRAMACION
Cuando se construye software como producto empresarial o comercial,

se llevan a cabo varias técnicas de manera que el desarrollo se haga en
forma ordenada y así poder asegurar un avance continúo, un producto
final de calidad, y realizar posteriores mejoras sea una tarea más fácil.
10.7.1. Programación en Capas :
La programación por capas es una arquitectura cliente-servidor 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 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
se ataca al nivel requerido sin tener que revisar entre código mezclado.
35
10.8. ARQUITECTURA WEB
Para abrir una página Web en un navegador, normalmente se teclea el

correspondiente URL o se pica en el hiperenlace oportuno. Una vez que
se solicita esta petición mediante el protocolo HTTP y la recibe el
servidor Web, éste localiza la página Web en su sistema de ficheros y la
envía de vuelta al navegador que la solicitó, según se muestra en la
Figura
10.8.1. Aplicaciones Web :
Es un conjunto de páginas Web estáticas y dinámicas. Una página Web

estática es aquella que no cambia cuando un usuario la solicita: el
servidor Web envía la página al navegador Web solicitante sin
modificarla. Por el contrario, el servidor modifica las páginas Web
dinámicas antes de enviarlas al navegador solicitante. La naturaleza
cambiante de este tipo de página es la que le da el nombre de dinámica.
36
CAPITULO IV
APLICACIÓN DE LA
METODALOGIA
37
Sistema informático para la administración interna y control del servicio de atención al cliente para el restaurante “Samaritana.”.
10.1. Modelamiento del Negocio

10.1.1. Pictograma del Negocio
38
10.1.1. Descripción Del Pictograma
El restaurante Samaritana en el Área de Almacén tiene la responsabilidad de

llevar el control de las entras y salidas de productos dentro del restaurante, los
cuales son realizados las ordenes de compras por el jefe de alancen,
verificando el gerente dicho documento para posteriormente verificarlo y
enviarlo al proveedor seleccionado. Luego dicho proveedor enviara los
productos a nuestro restaurante en el área de almacén donde nuestro jefe de
almacén registrar la orden de compra como aceptada y actualizara nuestro
stock de productos del almacén.
También en el Área de atención el recepcionista podrá realizar los procesos de

reservación y registro de comandas con sus respectivos documento de ventas,
donde el cliente puede realizar su dicha reservación directamente con el
recepcionista del restaurante, así como también solicitara atención de nuestros
mozos para anotar la comanda y llevarlo hacia el recepcionista donde registrar
dicha comanda pedida por el cliente para luego enviar el documento hacia el
área de cocina para su preparación. El mozo es el encargado de recibir de la
cocina el pedido y llevarlo hacia el cliente, por último el cliente consume dicho
pedido y realiza la cancelación al recepcionista del restaurante entregándole un
documento de venta.
39
10.1.2.1. PROCESO DE NEGOCIO: CONTROL DE ALMACÉN
 DESCRIPCION:
Este proceso permite que el jefe de almacén realizara el documento de
Orden de compra en el que se encontraran el listado de insumos de bebidas
que se pedirá al proveedor, la cual será modificada y comprobada por el
gerente administrativo, registrando las entradas y salidas de bebidas.
 ROLES ASOCIADOS:
Proveedor, Jefe de Almacén, Administrador
 TAREAS:
 PROVEEDOR:
Persona encargada de recibir la orden de compra y traer los insumos
pedidos por el restaurante.
 JEFE DE ALMACEN:
Encargado del control del almacén, realiza las órdenes de compra,
verificando las entras y salidas de productos.
 ADMINISTRADOR:
Encargado del manejo del restaurante, verifica las órdenes de compra.
 REGLAS DE NEGOCIO:
 REGLA 01
El orden de compra no podrá ser emitida sin antes no haberse realizado
las cotizaciones, verificación y aprobación por el administrador.
 REGLA 02
Las entregas de los insumos sólo podrán ser realizadas en
determinadas horas, según horario del restaurante.
40
 REGLA 03
Un proveedor que no cumpla con él envió de la fecha indicada pasara
automáticamente a un estado inactivo
 REGLA 04
La alarma de alerta para elaborar el documento de orden de compra se
activa siempre y cuando el stock se encuentre menos o igual a 20
unidades
10.1.2.2. PROCESO DE NEGOCIO: REALIZAR COMONDAS
 DESCRIPCION:
Este proceso implica que el mesero anote lo que solicita el cliente, para
luego ser registrado por el recepcionista, automáticamente pasa el pedido a
cocina y a caja para la respectiva venta e imprimiendo los documentos para
el cliente.
Cliente, Recepcionista, Mesero, Cajero
 TAREAS:
 CLIENTE:
Persona que solicita el pedido del menú y el pago del costo del pedido.
 RECEPCIONISTA:
Encargado del registro de cliente y pedido de comanda para su
preparación y posterior venta
 MESERO:
Atender a los clientes, registrando la comanda
 CAJERO:
Persona encargada de realizar la venta, hacer efectivo el pago y recibo
de dinero que le proporcionara el cliente.
41
 REGLAS DE NEGOCIO:
 REGLA 01
El mozo deberá cubrir con todas las necesidades del cliente, que estén
relacionadas con la atención de los servicios que brinda el restaurante,
para que éste se sienta a gusto, de no ser así podría ser sancionado.
 REGLA 02
El cliente podrá hacer modificaciones o cancelaciones de su pedido
máximo a los 10 minutos después de haberlo realizado.
 REGLA 03
Se pueden cambiar ingredientes en el platillo salvo previa aprobación del
cliente con un comentario al realizar el pedido.
 REGLA 04
Los privilegios elaborados por el restaurante solo se les darán a los
clientes registrados por el sistema y no a clientes comunes.
 REGLA 05
En fechas estratégicas como Navidad, Fiestas Patrias, etc., se realizan
ofertas de descuento en el monto total de la venta, establecido
únicamente por el gerente del restaurante (Estrategia de marketing).
 REGLA 06
En el caso de un cliente que no pague el consume seguirá la venta
como pendiente hasta que se comunique al administrador para el visto
bueno, considerando al cliente como inactivo.
 REGLA 02
Si al corte de caja hace falta una cantidad mayor a $20.00 soles el
empleado tiene que pagar la diferencia.
42
10.1.2.3. PROCESO DE NEGOCIO: REGISTRAR RESERVACION
 DESCRIPCION:
Este proceso implica que el recepcionista registre las reservaciones
correspondientes de cada cliente registrado en el sistema, así separando el
día, hora, mesa indicada y el pedido realizado.
Cliente, Recepcionista
 TAREAS:
 CLIENTE
Solicita reservación y es atendido en el restaurante.
Llegar a su reservación a la hora acordada, consume el pedido, paga el
costo del consumo
 RECEPCIONISTA
Encargado de realizar las reservaciones, pedidos.
 REGLAS DE NEGOCIO
 REGLA 01
Solo los clientes con DNI que estén registrados en el sistema podrán
solicitar su reservación.
 REGLA 02
El cliente podrá hacer su reservación mínimo con 4 horas de
anticipación de la hora en que ésta se realizó dicha reservación.
 REGLA 03
Una reservación podrá ser creada, anulada y modificada por el
recepcionista o el administrador.
43
 REGLA 04
La anulación de una reservación sedara automáticamente pasado los 20
minutos de la hora de registro.
 REGLA 04
La reservación será realizada siempre y cuando registre un pedido. El
cliente tendrá que pagar el 50% del monto total del pedido.
 REGLA 04
La anulación de una reservación sedara automáticamente pasado los 20
minutos de la hora de registro
Modelo de Caso de Uso del Negocio
DCUNSistemarRestauranteSamaritana
44
10.1.6. Especificación de Caso de Uso de Negocio:
 Tabla: Control de Almacén
Caso De Uso Control de Almacén

Descripción Este proceso permite que el jefe de almacén registrara el documento de Orden
de compra en el que se encontraran el listado de insumos de bebidas que se
pedirá al proveedor, la cual será modificada y comprobada por el gerente
administrativo, registrando las entradas y salidas de bebidas.
Precondición Personal contratado. E jefe de almacén debe tener reporte de stock de bebidas
Secuencia Paso Acción

Normal
1 El Jefe de Almacén Busca los productos de bebidas si ya existen.
2 El Jefe de Almacén registra las nuevas Órdenes de Compras.
3 El Jefe de Almacén Registra, Modifica y Actualiza las Entradas y

Salidas de bebidas.
Postcondición Todas las Entradas y Salida de productos deben de estar registrados.
Excepciones Paso Acción
1 En el caso de que no se haya ingresado correctamente todos los

datos de la Orden de compra, el sistema deberá mandar un mensaje
al Jefe de Almacén indicando que no se registró correctamente los
datos de la Orden de compra.
2 En caso de que las requisiciones de Suministro ya estén registrados

anteriormente, el sistema mandará un mensaje al Jefe de Almacén
indicando que las requisiciones de Suministros ya existen.
Rendimiento El sistema deberá realizar el registro de la orden de compra en un tiempo de 3

minutos.
Frecuencia 2 veces / Semana
Importancia Importante
Urgencia Inmediatamente
Comentarios Sin Comentarios Adicionales
45
 Tabla: Registrar Reservación
Caso De Uso Registrar Reservación

Descripción Este proceso implica que el recepcionista registre las reservaciones correspondientes
de cada cliente registrado en el sistema, así separando el día, hora, mesa indicada y el
pedido realizado.
Precondición Personal sea contratado. El recepcionista debe tener comandas a su disposición, para
que el deje su pedido al momento de realizar su reservación.
Secuencia Normal Paso Acción
1 El cliente solicita una reservación al recepcionista.
2 El recepcionista verifica si se cuenta con mesa disponible de acuerdo a la

fecha y hora solicitada
3 El recepcionista registra la reservación y la comanda teniendo en cuenta los

datos del cliente y emitiendo un documento de reservación.
Postcondición Todas las reservaciones deben de estar registrados. El recepcionista emitirá una
lista de reservaciones a los mozos, para que éstos preparen las mesas de
clientes a hora indicada
1 En el caso de que no se haya ingresado correctamente todos los datos de la

reservación, el sistema deberá mandar un mensaje al recepcionista
indicando que no se registró correctamente los datos de la reservación.
2 En caso que el cliente no cancele la primera parte de la reservación solo

podrá proceder por la orden del administrador.
Rendimiento El sistema deberá realizar el registro de reservaciones en un tiempo de 3 minutos.
Frecuencia 2 veces / día
46
 Tabla: Realizar Comandas.
Caso De Uso Realizar Comandas

Descripción Este proceso implica que el mesero anote lo que solicita el cliente, para luego ser
registrado por el recepcionista, automáticamente pasa el pedido a cocina y a caja para
la respectiva venta e imprimiendo los documentos para el cliente.
Precondición Personal sea contratado. El asistente debe tener controlado los productos en una lista
para verificar la posibilidad de atención de la comanda del cliente
1 El Recepcionista verifica la reservación del cliente
2 El Recepcionista selecciona la mesa y registra la comanda.
3 El Recepcionista imprime el documente de venta para el cliente.
Postcondición Todos las comandas deben de estar registrados y por cada comanda debe imprimir
documento.
1 En el caso de que no se haya ingresado correctamente todos de la comanda,

el sistema deberá mandar un mensaje al recepcionista indicando que no se
registró correctamente los datos de la comanda.
2 Si no existe ninguna reservación, entonces se proseguirá con los pasos

siguientes.
Rendimiento El sistema deberá realizar el registro de comandas en un tiempo de 3 minutos.
Frecuencia 20 veces / día
47
10.1.8. MODELO DE OBJETO DEL NEGOCIO:
MONControldeAlmacen
MONRealizarReservacion
48
MONRegistrarComandas
49
MONIntegrado
50
10.1.7. DIAGRAMA DE ACTIVIDAD DE CADA CASO DE USO DE NEGOCIO
DACUNControldeAlmacen
51
DACUNRealizarComanda
52
DACUNRegistrarReservacion
53
10.1.9. MODELO DOMINIO:
Modelo Dominio Restaurante
54
 Glosario del Negocio:

Es necesario conocer conceptos importantes que se manejan dentro del
Restaurante “Samaritana”, por eso que se elabora el presente glosario de
términos.
 Proveedor: persona o una empresa que abastece a otras empresas con

existencias (productos), los cuales serán transformados para venderlos
posteriormente o directamente se compran para su venta.
 Comanda: Es el listado de pedido de productos(Platos, Bebidas) y el

monto de dinero a cancelar para el cliente
 Orden de Compra: Documento donde se encuentra el listado de

productos para enviar al proveedor
 Categoría: Es donde los productos se van a encontrar por selección de

categoría.
 Menú: Se encuentran los productos (platos, bebidas) del día con sus
respectivos precios que serán pedidos por los clientes.
 Reservación: Es el proceso del separar un mesa y comanda en una

fecha y hora indicada por el cliente.
 Tipo Documento: Documento de venta que puede ser boleta o factura

dependiendo del cliente.
55
10.2. Modelo de Requerimientos:
Requerimientos Funcionales
ID DEL REQUERIMIENTO RFR-001 (Requerimiento funcional restaurante).
NOMBRE DEL REQUERIMIENTO Registrar Tipo Producto
CARACTERÍSTICAS DEL Requerimiento de datos.- Administración de información

REQUERIMIENTO para los listados
DESCRIPCIÓN DEL El sistema permitirá que el usuario registre los tipos de
REQUERIMIENTO productos existentes en el restaurante, contara con una
interfaz gráfica para el ingreso de datos
PRIORIDAD DEL
REQUERIMIENTO Media Alta
ENTRADA Datos del tipo de producto ( nombre,estado)
SALIDA Reporte de información de tipos de productos
NOMBRE DEL REQUERIMIENTO Registrar Producto

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre los
REQUERIMIENTO productos existentes en el restaurante, contara con una
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA Datos del producto ( nombre, precio, stock, descripción,
mediad, cantidad medida ,tipo producto ,estado)
56
NOMBRE DEL REQUERIMIENTO Registrar Mesa

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre mesas que
REQUERIMIENTO existentes en el restaurante, contara con una interfaz
gráfica para el ingreso de datos
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA Datos de la mesa ( nombre,estado)
NOMBRE DEL REQUERIMIENTO Registrar Proveedores

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre los
REQUERIMIENTO proveedor, contara con una interfaz gráfica para el
ingreso de datos
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA Datos del proveedor ( nombre compañía ,nombre de
contacto, ruc, teléfono, dirección, email, estado)
NOMBRE DEL REQUERIMIENTO Registrar Cliente

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre los clientes
REQUERIMIENTO especiales que sean parte del restaurante, contara con
una interfaz gráfica para el ingreso de datos
PRIORIDAD DEL
ENTRADA Datos del cliente (dni, nombre, apellidos, teléfono, fecha
de nacimiento, dirección, email, estado)
57
NOMBRE DEL REQUERIMIENTO Registrar Reservación

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre
REQUERIMIENTO reservaciones que son realizadas por los cliente,
contara con una interfaz gráfica para el ingreso de datos
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA Datos del tipo de producto ( fecha de atención, fecha de
reservación, hora, mesa, cliente, estado)
NOMBRE DEL REQUERIMIENTO Registrar Menú

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre los menús
REQUERIMIENTO del día que existentes en el restaurante, contara con
una interfaz gráfica para el ingreso de datos
PRIORIDAD DEL
ENTRADA Datos del tipo de producto ( nombre ,productos, tipo,
descripción, estado)
NOMBRE DEL REQUERIMIENTO Registrar Orden de Compra

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre las ordenes
REQUERIMIENTO de compras hacia los proveedores, contara con una
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA Datos del tipo de producto ( fecha, estado, proveedor,
cantidad, productos)
58
NOMBRE DEL REQUERIMIENTO Registrar Comanda

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre las
REQUERIMIENTO comandas realizadas por los clientes, contara con una
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA Datos del tipo de producto ( fecha, estado, productos,
cliente, mesa ,cantidad, monto total, observacion)
NOMBRE DEL REQUERIMIENTO Registrar Tipo Documento

DESCRIPCIÓN DEL El sistema permitirá que el usuario registre los tipos de
REQUERIMIENTO documento para la respectiva venta, contara con una
PRIORIDAD DEL
ENTRADA Datos del tipo de producto ( nombre,estado)
59
Requerimientos Funcionales
Los requerimientos no funcionales tienen que ver con las características que de
una u otra forma puedan limitar el sistema como son: el rendimiento (en tiempo
y espacio), confiabilidad, interfaces, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,
etc.
Usabilidad/Portabilidad
ID DEL REQUERIMIENTO RFR-010 (Requerimiento no funcional restaurante).
NOMBRE DEL REQUERIMIENTO El sistema Debe utilizar un diseño gráfico fácil de entender y
bien estructurado
CARACTERÍSTICAS DEL RE-N-Usabilidad.- Debe de utilizarse rápido atreves del
REQUERIMIENTO diseño entendible
DESCRIPCIÓN DEL Para que el usuario pueda utilizar correctamente el
REQUERIMIENTO sistema debe tener un diseño entendible y estructurado
correctamente
PRIORIDAD DEL
ENTRADA Diseño
SALIDA Buena Visualización e entendible
NOMBRE DEL REQUERIMIENTO El sistema tiene que avisar al usuario cuando introduce
datos falsos.
CARACTERÍSTICAS DEL RE-N-Usabilidad.- Eficaz al cometer errores por el
REQUERIMIENTO usuario dar signos de error
DESCRIPCIÓN DEL El sistema debe ser capaz atreves de mensajes o
REQUERIMIENTO señales graficas avisar al usuario cundo introduzca
datos erróneos
PRIORIDAD DEL
ENTRADA Introducir Datos
SALIDA Mensajes de confirmación o imagen grafica
60
NOMBRE DEL REQUERIMIENTO Es muy importante que el sistema sea portable y fácil de
instalar
CARACTERÍSTICAS DEL RE-N-Portabilidad.- Fácil de trasladar e instalar de un
REQUERIMIENTO lugar a otro
DESCRIPCIÓN DEL Es decir sea fácil de transportarlo a diferente hardware
REQUERIMIENTO o diferentes sistemas operativos
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA Introducir Datos
SALIDA Carpeta Sistema
Seguridad/Confiabilidad
NOMBRE DEL REQUERIMIENTO La base de datos tiene que estar bien protegida. El sistema
debe hacer Backus
CARACTERÍSTICAS DEL RE-N-Seguridad/Confiabilidad.- Seguridad de los datos
REQUERIMIENTO en Backus
DESCRIPCIÓN DEL Deberá de realizar copias de seguridad atreves de
REQUERIMIENTO Backus de la base de datos y alojarlos en sitio web.
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA
SALIDA Datos de información
NOMBRE DEL REQUERIMIENTO La base de datos tiene que estar bien protegida. El sistema
debe hacer Backus
CARACTERÍSTICAS DEL RE-N-Seguridad/Confiabilidad.- Seguridad de los datos
REQUERIMIENTO en Backus
DESCRIPCIÓN DEL Deberá de realizar copias de seguridad atreves de
REQUERIMIENTO Backus de la base de datos y alojarlos en sitio web.
PRIORIDAD DEL
REQUERIMIENTO Alta
ENTRADA
SALIDA Datos de información
61
10.2.1. Modelo de Casos de Uso de Requerimientos Detallado:
DCURSistemaRestauranteIntegrado
62
10.2.2. Diagrama de Casos de Uso de Requerimientos:
DCURControldeAlmacen
DCURRegistrarReservacion
63
DCURRealizarComandas
64
10.2.3. Matriz de Priorización de Casos de Uso
N° Caso de Uso Rendimiento Frecuenci Importancia Urgencia

a
1 Registrar Tipo 1 min 1 v / mes Vital Inmediata

documento
2 Registrar 1 min 4 v / mes Vital Inmediata

Producto

Mesa
4 Registrar 1 min 5 v / día Vital Inmediata

Cliente

Proveedor
6 Registrar Orden 3 min 3 v / mes Vital Inmediata

de compra

Menú

Reservación
9 Registrar Tipo 1 min 1v Vital Inmediata

documento
10 Registrar 3 min 15 v / día Vital Inmediata

Comandas
Fuente: Elaboración Propia
65
10.2.4. Especificación Casos de Uso – Requerimientos
Tabla: Registra Tipo Producto
CASO DE USO REGISTRA TIPO PRODCUTO

Descripción El Sistema deberá permitir al Jefe de Almacén registrar los datos del tipo
producto.
Precondición Se generará un código por defecto y correlativo para cada tipo de producto.
1 El Jefe de Almacén crea un nuevo registro de tipo producto.
2 El sistema brinda los campos a ingresar para el registro de

tipo de producto.
3 El Jefe de Almacén ingresa los datos del tipo de producto.
4 El sistema almacena los datos del tipo de producto ingresado

por el jefe de almacén.
Todos los tipos de producto deben de estar registradas.
Postcondición
1 En el caso de que no se haya ingresado correctamente todos los datos

del tipo de producto, el sistema deberá mandar un mensaje indicando
que no se registró correctamente los datos.
2 En caso de que el tipo de producto ya esté registrado anteriormente, el

sistema mandarán un mensaje indicando que ya existe.
Rendimiento El sistema deberá realizar el registro de los tipos de productos en un tiempo

de 1 minuto.
Frecuencia 1 vez / mes.
Importancia Vital.
Urgencia Inmediatamente.
Comentarios Sin comentarios adicionales.
66
Tabla: Registra Producto
CASO DE USO REGISTRA PRODUCTO

Descripción El Sistema deberá permitir al Jefe de Almacén registrar los datos de
los productos.
Precondición Se generará un código por defecto y correlativo para cada producto.
1 El Asistente de Almacén crea un nuevo registro de producto.

producto.
3 El Jefe de Almacén ingresa los datos del producto.
4 El sistema almacena los datos del producto ingresado por el

Jefe de almacén.
Todos los productos deben de estar registradas.
Postcondición
1 En el caso de que no se haya ingresado correctamente todos

los datos de los productos, el sistema deberá mandar un
mensaje indicando que no se registró correctamente los datos.
2 En caso de que el producto ya esté registrado anteriormente, el

Rendimiento El sistema deberá realizar el registro de los productos, en un tiempo

de 1 minuto.
Importancia Vital.
67
Tabla: Registra Proveedor
CASO DE USO REGISTRA PROVEEDOR

Descripción El Sistema deberá permitir al Jefe de Almacén registrar los datos de los
proveedores.
Precondición Se generará un código por defecto y correlativo para cada proveedor.
1 El Jefe de Almacén crea un nuevo registro de proveedor.

proveedor.
3 El Jefe de Almacén ingresa los datos del proveedor.
4 El sistema almacena los datos del proveedor ingresado por el

Jefe de almacén.
Todos los proveedores deben de estar registradas.
Postcondición

los datos de los proveedores, el sistema deberá mandar un
2 En caso de que el proveedor ya esté registrado anteriormente,

el sistema mandarán un mensaje indicando que ya existe.
Rendimiento El sistema deberá realizar el registro de los proveedores, en un tiempo

de 1 minuto.
Importancia Vital.
68
Tabla: Registra Orden de Compra
CASO DE USO REGISTRA ORDEN DE COMPRA

Descripción El Sistema deberá permitir al Jefe de Almacén registrar los datos de las
órdenes de compras de los productos del tipo de bebida.
Precondición Se generará código por defecto y correlativo para cada orden de compra
1 El Jefe de Almacén crea un nuevo registro de orden de compra.
2 El sistema brinda los campos a ingresar para el registro de orden

de compra.
3 El Jefe de Almacén ingresa los datos de la orden de compra.
4 El sistema almacena los datos de la orden de compra ingresada

por el Jefe de almacén.
Todos los órdenes de compras deben de estar registradas.
Postcondición

datos de la orden de compra, el sistema deberá mandar un
Rendimiento El sistema deberá realizar el registro de las órdenes de compra, en un

tiempo de 3 minutos.
Importancia Importante.
69
Tabla: Registra Tipo Documento
CASO DE USO REGISTRA TIPO DOCUMENTO

Descripción El Sistema deberá permitir al Recepcionista registrar los datos del tipo
documento.
Precondición Se generará un código por defecto y correlativo para cada tipo de

documento.
1 El Recepcionista crea un nuevo registro de tipo documento.

tipo de documento.
3 El Recepcionista ingresa los datos del tipo de documento.
4 El sistema almacena los datos del tipo de documento

ingresado por el Recepcionista.
Todos los tipos de documento deben de estar registradas.
Postcondición
1 En el caso de que no se haya ingresado correctamente todos los datos

del tipo de documento, el sistema deberá mandar un mensaje
indicando que no se registró correctamente los datos.
2 En caso de que el tipo de documento ya esté registrado anteriormente,

el sistema mandarán un mensaje indicando que ya existe.
Rendimiento El sistema deberá realizar el registro de los tipos de documento en un

tiempo de 1 minuto.
Importancia Vital.
70
Tabla: Registra Cliente
CASO DE USO REGISTRA CLIENTE

Descripción El Sistema deberá permitir al Recepcionista registrar los datos de los
clientes.
Precondición Se generará un código por defecto y correlativo para cada cliente.
1 El Recepcionista crea un nuevo registro de cliente (normal-

Jurídico).

Cliente.
3 El Recepcionista ingresa los datos del Cliente.
4 El sistema almacena los datos del cliente ingresado por el

Recepcionista.
Todos los clientes deben de estar registradas si desean formar parte

del restaurante.
Postcondición

los datos del cliente, el sistema deberá mandar un mensaje
2 En caso de que el cliente ya esté registrado anteriormente, el

Rendimiento El sistema deberá realizar el registro de los clientes, en un tiempo de 1

minuto.
Frecuencia 5 vez / Día.
Importancia Vital.
71
Tabla: Registra Mesa
CASO DE USO REGISTRA MESA

Descripción El Sistema deberá permitir al Recepcionista registrar los datos de las
Mesas.
Precondición Se generará un código por defecto y correlativo para cada Mesa.
1 El Recepcionista crea un nuevo registro de Mesa

Mesa.
3 El Recepcionista ingresa los datos de la mesa.
4 El sistema almacena los datos de la mesa ingresado por el

Recepcionista.
Todos las mesas del restaurante deben de estar registradas
Postcondición

los datos de la mesa, el sistema deberá mandar un mensaje
2 En caso de que la mesa ya esté registrado anteriormente, el

Rendimiento El sistema deberá realizar el registro de las mesas, en un tiempo de 1

minuto.
Importancia Vital.
72
Tabla: Registra Menú
CASO DE USO REGISTRA MENU

Descripción El Sistema deberá permitir al Recepcionista registrar los datos del
Menú.
Se generará un código por defecto y correlativo para cada Menú.
1 El Recepcionista crea un nuevo registro del Menú.
2 El sistema brinda los campos a ingresar para el registro del

Menú.
3 El Recepcionista ingresa los datos del Menú.
4 El sistema almacena los datos de la mesa ingresado por el

Recepcionista.
Todos los menú del restaurante deben de estar registradas.
Postcondición

los datos de la mesa, el sistema deberá mandar un mensaje
2 En caso de que la mesa ya esté registrado anteriormente, el

Rendimiento El sistema deberá realizar el registro del Menú, en un tiempo de 1

minuto.
Importancia Vital.
73
Tabla: Registra Reservación
CASO DE USO REGISTRA RESERVACION

Reservaciones de los clientes registrados.
Precondición Se generará código por defecto y correlativo para cada Reservación.
1 El Recepcionista crea un nuevo registro de Reservación.
2 El sistema brinda los campos a ingresar para el registro de la

Reservación
3 El Recepcionista ingresa los datos de la Reservación.
4 El sistema almacena los datos de la Reservación ingresada por el

Recepcionista.
Todos los Reservaciones deben de estar registradas.
Postcondición

datos de la Reservación, el sistema deberá mandar un mensaje
Rendimiento El sistema deberá realizar el registro de las Reservaciones, en un tiempo

de 3 minutos.
74
Tabla: Registra Comanda
CASO DE USO REGISTRA COMANDA

Comandas de los clientes.
Precondición Se generará código por defecto y correlativo para cada Comanda.
1 El Recepcionista crea un nuevo registro de Comanda.
2 El sistema brinda los campos a ingresar para el registro de la

Comanda.
3 El Recepcionista ingresa los datos de la Comanda.
4 El sistema almacena los datos de la Comanda ingresada por el

Recepcionista.
Todos los Comandas deben de estar registradas.
Postcondición

datos de la Comanda, el sistema deberá mandar un mensaje
Rendimiento El sistema deberá realizar el registro de las Comandas, en un tiempo de 3

minutos.
Frecuencia 15 vez /día.
75
10.3. ANÁLISIS
10.3.1. DIAGRAMA DE COLABORACIÓN:
Registrar Mesa:
Registrar Reservación
76
Registrar Producto
Registrar Proveedor
77
Registrar Tipo Documento
Registrar Menú
78
Registrar Cliente
Registrar Orden Compra
79
Registrar Tipo Producto
Registrar Comanda
80
10.3.2. Diagrama de Clases de Entidad
81
10.3.3 Diagrama de Paquetes de Análisis (Boundary + Control + Entitis):
Boundary:
Entitis:
82
Control:
83
10.3.4. Diagrama de Clases de Análisis
84
10.4. DISEÑO
10.4.1. Web Restaurante
85
86
10.4.2. Acceso al Sistema
87
88
89
90
91
92
93
94
95
96
97
98
10.4.3. Diagrama de Clases de Diseño
99
10.4.4. Diagrama de Paquetes de Diseño
100
Modelo Físico De La Base De Datos Relacional (Erwin)
101
10.4.5. Script de Migración de La Base de Datos SQL
CREATE TABLE ABASTECER

(
IdAbastecer int NOT NULL ,
Estado INT NOT NULL ,
IdProveedor int NOT NULL
)
Go
ALTER TABLE ABASTECER

ADD CONSTRAINT XPKABASTECER PRIMARY KEY CLUSTERED
(IdAbastecer ASC)
Go
CREATE TABLE CATEGORIA_PLATO

(
IdCatePlato int NOT NULL ,
Nombre varchar(20) NOT NULL ,
Estado int NOT NULL
)
Go
ALTER TABLE CATEGORIA_PLATO

ADD CONSTRAINT XPKCATEGORIA_PLATO PRIMARY KEY
CLUSTERED (IdCatePlato ASC)
Go
CREATE TABLE CLIENTE

(
IdCliente INT NOT NULL ,
Dni char(8) NULL ,
Ruc char(11) NULL ,
RazonSocial varbinary(20) NULL ,
Nompre varchar(20) NOT NULL ,
Apellido varchar(30) NULL ,
Telefono char(8) NULL ,
FechaNacimiento datetime NULL ,
Direccion varbinary(max) NULL ,
Email varbinary(max) NULL ,
Estado INT NOT NULL
)
Go
102
ALTER TABLE CLIENTE

ADD CONSTRAINT XPKCLIENTE PRIMARY KEY CLUSTERED
(IdCliente ASC)
go
CREATE TABLE COMANDA

(
IdComanda INT NOT NULL ,
Fecha datetime NOT NULL ,
Estado char(10) NOT NULL ,
Descuento decimal(8,2) NULL ,
MontoTotal decimal(8,2) NOT NULL ,
Descripcion varbinary(max) NULL ,
IdMesa INT NOT NULL ,
IdCliente INT NOT NULL ,
IdtipoDocumento INT NOT NULL
)
Go
ALTER TABLE COMANDA

ADD CONSTRAINT XPKCOMANDA PRIMARY KEY CLUSTERED
(IdComanda ASC)
go
CREATE TABLE DETALLE_ABASTECER

(
IdDetaAbastecer int NOT NULL ,
IdAbastecer int NOT NULL
)
Go
ALTER TABLE DETALLE_ABASTECER

ADD CONSTRAINT XPKDetalle_abastecer PRIMARY KEY
CLUSTERED (IdDetaAbastecer ASC,IdAbastecer ASC)
Go
CREATE TABLE Detalle_Comanda_Plato

(
IdDetaComandaPlato INT NOT NULL ,
Cantidad INT NOT NULL ,
Importe decimal(8,2) NOT NULL ,
Notas varchar(max) NULL ,
Idplato INT NOT NULL ,
IdComanda INT NOT NULL
103
)
Go
ALTER TABLE Detalle_Comanda_Plato

ADD CONSTRAINT XPKDetalle_Comanda_Plato PRIMARY KEY
CLUSTERED (IdDetaComandaPlato ASC,IdComanda ASC)
Go
CREATE TABLE Detalle_Comanda_Producto

(
IdDetaComandaProducto int NOT NULL ,
Cantidad int NOT NULL ,
Importe decimal(8,2) NOT NULL ,
Notas varbinary(max) NULL ,
IdComanda int NOT NULL ,
IdProducto int NOT NULL
)
Go
ALTER TABLE Detalle_Comanda_Producto

ADD CONSTRAINT XPKDetalle_Comanda_Producto PRIMARY KEY
CLUSTERED (IdDetaComandaProducto ASC,IdComanda ASC)
Go
CREATE TABLE DETALLE_MENU

(
IdDetalleMenu NT NOT NULL ,
Cantidad INT NOT NULL ,
Idplato int NOT NULL ,
IdMenu INT NOT NULL
)
Go
ALTER TABLE DETALLE_MENU

ADD CONSTRAINT XPKDETALLE_MENU PRIMARY KEY
CLUSTERED (IdDetalleMenu ASC,IdMenu ASC)
Go
CREATE TABLE DETALLE_ORDEN_COMPRA

(
IdDetaOrdenCompra int NOT NULL ,
Cantidad int NOT NULL ,
IdOrdenCompra int NOT NULL ,
104
IdProducto int NOT NULL

)
Go
ALTER TABLE DETALLE_ORDEN_COMPRA

ADD CONSTRAINT XPKDETALLE_ORDEN_COMPRA PRIMARY KEY
CLUSTERED (IdDetaOrdenCompra ASC,IdOrdenCompra ASC)
Go
CREATE TABLE MENU

(
IdMenu INT NOT NULL ,
Descripcion varchar(max) NULL ,
Estado char(10) NOT NULL
)
Go
ALTER TABLE MENU

ADD CONSTRAINT XPKMENU PRIMARY KEY CLUSTERED (IdMenu
ASC)
Go
CREATE TABLE MESA

(
IdMesa NT NOT NULL ,
Estado int NOT NULL
)
Go
ALTER TABLE MESA

ADD CONSTRAINT XPKMESA PRIMARY KEY CLUSTERED (IdMesa
ASC)
Go
CREATE TABLE ORDEN_COMPRA

(
IdOrdenCompra int NOT NULL ,
Fecha datetime NOT NULL ,
IdProveedor int NOT NULL
)
105
Go
ALTER TABLE ORDEN_COMPRA

ADD CONSTRAINT XPKORDEN_COMPRA PRIMARY KEY
CLUSTERED (IdOrdenCompra ASC)
Go
CREATE TABLE PLATO

(
Idplato int NOT NULL ,
Precio decimal(8,2) NOT NULL ,
Descripcion varbinary(max) NULL ,
Estado int NOT NULL ,
IdCatePlato int NULL
)
Go
ALTER TABLE PLATO

ADD CONSTRAINT XPKPLATO PRIMARY KEY CLUSTERED (Idplato
ASC)
Go
CREATE TABLE PRODUCTO

(
IdProducto int NOT NULL ,
Precio decimal(8,2) NOT NULL ,
Medida char(10) NOT NULL ,
CantidadUnidadMedida int NOT NULL ,
Stock int NOT NULL ,
Estado int NOT NULL ,
IdTipoProducto int NOT NULL
)
Go
ALTER TABLE PRODUCTO

ADD CONSTRAINT XPKPRODUCTO PRIMARY KEY CLUSTERED
(IdProducto ASC)
Go
106
CREATE TABLE PROVEEDOR

(
IdProveedor int NOT NULL ,
NombreCompañia varchar(30) NOT NULL ,
NombreContacto varchar(30) NOT NULL ,
Ruc char(11) NOT NULL ,
Telefono char(9) NOT NULL ,
Direccion varbinary(max) NULL ,
Email varbinary(max) NULL ,
Estado int NOT NULL
)
Go
TABLE PROVEEDOR
ADD CONSTRAINT XPKPROVEEDOR PRIMARY KEY CLUSTERED
(IdProveedor ASC)
Go
CREATE TABLE RESERVACION

(
IdReservacon INT NOT NULL ,
FechaAtencion datetime NOT NULL ,
FechaReservacion datetime NOT NULL ,
HoraReservacion datetime NOT NULL ,
IdMesa NT NOT NULL ,
IdCliente INT NOT NULL
)
Go
ALTER TABLE RESERVACION

ADD CONSTRAINT XPKRESERVACION PRIMARY KEY CLUSTERED
(IdReservacon ASC)
Go
CREATE TABLE TIPO_DOCUMENTO

(
IdtipoDocumento INT NOT NULL ,
Nombre varchar(20) NOT NULL
)
go
107
ALTER TABLE TIPO_DOCUMENTO

ADD CONSTRAINT XPKTIPO_DOCUMENTO PRIMARY KEY
CLUSTERED (IdtipoDocumento ASC)
Go
CREATE TABLE TIPO_PRODUCTO

(
IdTipoProducto int NOT NULL ,
Estado int NOT NULL
)
Go
ALTER TABLE TIPO_PRODUCTO

ADD CONSTRAINT XPKTIPO_PRODUCTO PRIMARY KEY
CLUSTERED (IdTipoProducto ASC)
Go
ALTER TABLE ABASTECER

ADD CONSTRAINT R_13 FOREIGN KEY (IdProveedor) REFERENCES
PROVEEDOR(IdProveedor)
ON DELETE NO ACTION
ON UPDATE NO ACTIOn
Go
ALTER TABLE COMANDA

ADD CONSTRAINT R_15 FOREIGN KEY (IdMesa) REFERENCES
MESA(IdMesa)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
ALTER TABLE COMANDA

ADD CONSTRAINT R_16 FOREIGN KEY (IdCliente) REFERENCES
CLIENTE(IdCliente)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
ALTER TABLE COMANDA
ADD CONSTRAINT R_19 FOREIGN KEY (IdtipoDocumento)
REFERENCES TIPO_DOCUMENTO(IdtipoDocumento)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
108
ALTER TABLE DETALLE_ABASTECER

ADD CONSTRAINT R_14 FOREIGN KEY (IdAbastecer) REFERENCES
ABASTECER(IdAbastecer)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go

ADD CONSTRAINT R_17 FOREIGN KEY (Idplato) REFERENCES
PLATO(Idplato)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go

ADD CONSTRAINT R_18 FOREIGN KEY (IdComanda) REFERENCES
COMANDA(IdComanda)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go

ADD CONSTRAINT R_23 FOREIGN KEY (IdComanda) REFERENCES
COMANDA(IdComanda)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go

ADD CONSTRAINT R_24 FOREIGN KEY (IdProducto) REFERENCES
PRODUCTO(IdProducto)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go

ADD CONSTRAINT R_4 FOREIGN KEY (Idplato) REFERENCES
PLATO(Idplato)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
109

ADD CONSTRAINT R_6 FOREIGN KEY (IdMenu) REFERENCES
MENU(IdMenu)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go

ADD CONSTRAINT R_9 FOREIGN KEY (IdOrdenCompra)
REFERENCES ORDEN_COMPRA(IdOrdenCompra)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go

ADD CONSTRAINT R_11 FOREIGN KEY (IdProducto) REFERENCES
PRODUCTO(IdProducto)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
ALTER TABLE ORDEN_COMPRA

ADD CONSTRAINT R_10 FOREIGN KEY (IdProveedor) REFERENCES
PROVEEDOR(IdProveedor)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
ALTER TABLE PLATO

ADD CONSTRAINT R_5 FOREIGN KEY (IdCatePlato) REFERENCES
CATEGORIA_PLATO(IdCatePlato)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
ALTER TABLE PRODUCTO

ADD CONSTRAINT R_8 FOREIGN KEY (IdTipoProducto)
REFERENCES TIPO_PRODUCTO(IdTipoProducto)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
110

ADD CONSTRAINT R_20 FOREIGN KEY (IdMesa) REFERENCES
MESA(IdMesa)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go

ADD CONSTRAINT R_21 FOREIGN KEY (IdCliente) REFERENCES
CLIENTE(IdCliente)
ON DELETE NO ACTION
ON UPDATE NO ACTION
Go
111
10.4.6. Modelo Físico de la Base Datos Relacional (SQL SERVER)
112
10.5.- Implementación
10.5.1.- Diagrama de Componentes
10.5.2.- Diagrama de Despliegue
113
10.6. Prueba De La Caja Negra Prueba
Caso De Uso: Registrar TipoProducto
Registrar TipoProducto: Ingreso de Datos Validos
Ítem Datos Tipo De Datos Respuesta
1 Nombre CERVEZAS Ingresado Correctamente
Registrar TipoProducto: Ingreso de Datos No Validos
2 Nombres %&$./()&_@ Error
Registrar TipoProducto: Resultados por Escenario
Use Case Escenario Resultado Conclusión
Se registró
Verificar si se registró El TipoProducto
Registrar correctamente y se
correctamente el pasa a formar parte
TipoProducto le asigna un código
TipoProducto del Sistema
único.
Caso De Uso: Registrar Producto
Registrar Producto: Ingreso de Datos Validos
3 Nombre Ingresado Correctamente

PILESEN
4 Descripcion 120 ml Ingresado Correctamente
5 Medida CAJA Ingresado Correctamente
6 CantidaMedida 12 Ingresado Correctamente
7 Stock 250 Ingresado Correctamente
8 Precio 6.00 Ingresado Correctamente
114
Registra Producto: Ingreso de Datos No Validos
3 Nombre %&$./()&_@ Ingresado Correctamente
4 Descripcion %&$./()&_@ Ingresado Correctamente
5 Medida 8@:_ Ingresado Correctamente
6 CantidaMedida A_.?@%& Ingresado Correctamente
7 Stock A_.?@%& Ingresado Correctamente
8 Precio A_.?@%& Ingresado Correctamente
Registrar Producto Resultados por Escenario
Use Case Resultado Conclusión
Registrar Producto tiene

Se registró correctamente y como Prerrequisito haber
Registrar Producto se le asigna un código registrado antes el
único. TipoProducto. Este proceso
es de vital importancia.
115
11.- Conclusiones del Proyecto:
 El Diseño propuesto va a brindar mayor seguridad a los datos que el sistema

manual, ya que restringe el acceso a ellos atreves de usuarios.
 El Diseño propuesto facilita la toma de decisiones ya que brinda la posibilidad

de crear salidas óptimas para esto atreves de los reportes emitidos.
 La aplicación de la Metodología RUP basada en UML es una buena

metodología de Análisis y Diseño de Sistemas ya que guía paso a paso de
manera fácil y clara la realización de estos
 El prototipo del sistema desarrollado permite almacenar la data concerniente

en la base de datos creada en SQL Server 2012 lo cual permite organizar la
seguridad de la información manejada.
 Con el sistema informático desarrollado se logra disminuir los gastos de la

institución, agilizar y controlar todos los procesos del negocio.
 La metodología empleada permitió la confección del modelo de Negocio el cual

nos brindó un panorama concreto de la problemática.
 Se realizó el levantamiento de la información e identificación de los problemas

del área y sus dominios en base al cual se desarrolló el sistema informático
que permite superar las deficiencias del área, optimizando el empleo de sus
recursos.
12.- Recomendaciones:
Estar capacitados para el uso del software para tener un buen control del
proceso y no intentarlo por personal no autorizado, porque se estará
arriesgando la seguridad de los datos de la institución.
13.- Referencias Bibliográficas y/o Enlaces
 http://www.slideshare.net/ortizrichard/metodologia-del-rup-10540203
 http://mtdologiarup.blogspot.com/
 http://www.slideshare.net/Decimo/arquitectura-3-capas
 http://www.solodrivers.com/manuales/programacion_visualbasic
 http://www.canalvisualbasic.net/foro/visual-basic-6-0/eliminar-fila-en-datagrid-
589/
116

Informe Sistema

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Informe Sistema

Загружено:

Авторское право:

Доступные форматы

Sistema informático para la administración interna y control del servicio de

atención al cliente para el restaurante “Samaritana.”.

“Año de la Inversión para el Desarrollo Rural y la Seguridad Alimentaria”

Escuela profesional de ingeniería informática y de sistemas

Título del Proyecto:

Implementar un Sistema informático para la administración interna y control del

Practicas Pre Profesionales II

Erick Reyes Torres

Ing. Oscar Valdivia Ascon

Chimbote, Abril del 2014

Dedico este proyecto de tesis a Dios y a

A mis padres, quienes a lo largo de mi vida

Es por ello que soy lo que soy ahora. Los

En primer lugar nuestro agradecimiento va

Agradecemos a nuestro asesor por brindarnos

8. DATOS GENERALES DE LA ORGANIZACIN………………………..….……..8

8.1. NOMBRE DEL PROYECTO………………………………..……….…….9

9.1. SITUACIÓN PROBLEMÁTICA……………………………………..……..12

9.2. JUSTIFICACIÓN DEL PROYECTO………………………………………13

9.3. OBJETIVOS DEL PROYECTO……………………………………………14

9.4. LIMITACIONES DEL PROYECTO……………………….…….…………15

10. MARCO TEÓRICO ……………………………….………………………………17

10.1. METODOLOGÍA DE DESARROLLO RUP……………………..… 18-19

El proyecto consiste en el diseño e implantación de un sistema para la gestión

Se ha dividido el sistema en varios procesos fundamentales, uno es el área de

El área de almacén se encarga de llevar el control correcto de las Entradas y

Gracias a estos procesos podemos lograr una gran variedad de información

The project involves the design and implementation of a management system

System has been divided in several fundamental processes, one is the

Through these processes we can achieve a variety of information quickly

En el presente proyecto utilizamos todos los pasos necesarios para poder

El proyecto empieza con la investigación acerca del Organización en nuestro

 Modelamiento del Negocio: Pictograma, Modelo de casos de uso del

 Modelo de Requerimientos: Modelo de Casos de uso de Requerimientos

 Análisis: Diagrama de Colaboración, Diagrama de Clases Entidad, Diagrama

 Diseño: Interfaces de Usuario, Diagramas de secuencia de Diseño, Diagramas

8.1. NOMBRE DEL PROYECTO:

“Implementa un Sistema informático para la administración interna y control del

8.2. DESCRIPCIÓN DEL PROYECTO:

El presente proyecto se realizará para ayudar al personal operativo, clientes

8.3. LOGOTIPO DE LA ORGANIZACIÓN:

8.4. RAZÓN SOCIAL DE LA ORGANIZACIÓN:

Panamericana Norte Km 439 – Coishco – Santa

8.5. DESCRIPCIÓN DE LA ORGANIZACIÓN:

8.5.1. Visión y Misión de la Organización:

Ser reconocidos como el mejor restaurante de la ciudad de Coishco,

Fuente: Elaboración Propia

8.7. SITUACIÓN PROBLEMÁTICA

La atención de los pedidos en almacén en los procesos de entrada y

8.7.2. Selección Del Problema

Debido a lo anteriormente descrito se percibe insatisfacción por parte de

8.7.3. Antecedentes Del Problema

A nivel local por el momento no existe ningún restaurante que cuente

nivel nacional, si existen referencias de sistemas similares al que

8.7.4. Formulación Interrogativa Del Problema

¿De qué manera un Sistema informático puede mejorar la administración

8.8. Justificación del Proyecto

8.8.1. Justificación Técnica

 Brindar un soporte de información adecuado y eficiente, mediante el

 Implementar un soporte de información online que interactúe con el

8.8.2. Justificación Operativa

 El manejo de información segura y confiable.

 Permitiendo agilizar el proceso completo desde el pedido, pasando por

8.8.3. Justificación Económica