1

INGENIERÍA DE SOFTWARE ORIENTADO A

OBJETOS
3ISTORIA DE REVISIONES

Fecha Versión Descripción Autor

/04/2012 1.0 Elegir el Proyecto Todos los

integrantes

17/01/2012 Corrección de los Procesos de Todos los

Negocio Integrantes

17/01/2012 1.2 Instalar el Tortoise y Probar su

funcionamiento

17/01/2012 2.0 Actualizar el Site Google Code

17/01/2012 2.3 Subir

SIGERAP
los
V1.1del
Documentos
Modelado del Negocio

18/01/2012 2.4 Hacer el Plan del Proyecto

18/01/2012 2.7 Subir el Codigo a Google Code

Utilizando Subvertion

17/01/2012 2.8 Identificar Casos de Uso

17/01/2012 2.9 Subir al Repositorio las ECUs

versión 1.0

17/01/2012 3.0 Modificar el Documento SRS

17/01/2012 3.1 Actualizar ECU

18/01/2012 3.2 Diseñar los prototipos de las ECU

Arias Camacho,Jhino
20/01/2012 3.6 Actualizaciones
Apeña Menor, José de Realizaciones
Flores Eugenio, María
de Diseño
Mendieta Garcia,Emilio
Mora Mallqui, Iván
20/01/2012 3.7 Actualizaciones
Peña Palacios, Luis de las
Zumaeta Mejía, Doris
realizaciones de Análisis
Isabel Canchari Maria
21/01/2012 3.9 Hacer el Wiki en JUnit

Fecha de Actualización: 10/04/2007 Gestión del Proyecto AvsaNet

Responsable: Marisella Zelada Versión: 4.6 AvsaNet

DEL 2012
 2

HISTORIA DE REVISIONES

Fecha Versión Descripción Autor

06/03/2012 1.0 Elegir el Proyecto Todos los

integrantes

17/03/2012 Corrección de los Procesos de Todos los

Negocio Integrantes

24/03/2012 1.2 Instalar el Tortoise y Probar su Todos los

funcionamiento Integrantes

24/03/2012 2.0 Actualizar el Site Google Code Todos los

Integrantes

27/01/2012 2.3 Subir los Documentos del Todos los

Modelado del Negocio Integrantes

5/04/2012 2.4 Hacer el Plan del Proyecto Todos los

Integrantes

7/04/2012 2.7 Subir el Código a Google Code Todos los

Utilizando Subvertion Integrantes

17/04/2012 2.8 Identificar Casos de Uso Todos los

Integrantes

17/04/2012 2.9 Subir al Repositorio las ECUs Todos los

versión 1.0 Integrantes

17/05/2012 3.0 Modificar el Documento SRS

17/05/2012 3.1 Actualizar ECU Apeña Menor Jose

18/05/2012 3.2 Diseñar los prototipos de las ECU Mora Mallqui Ivan

20/05/2012 3.6 Actualizaciones de Realizaciones Apeña Menor Jose

de Diseño

20/05/2012 3.7 Actualizaciones de las Apeña Menor José

Fecha de Actualización: 15/06/2012 Gestión del Proyecto SISGERAP
Responsables: María Isabel Canchari, Iván Versión: 1.2 SISGERAP
Mora, Arias Camacho, Jhino
 3

realizaciones de Análisis

21/05/2012 3.9 Hacer el Wiki en JUnit Luis Peña

Palacios

22/05/2012 4.0 Implementación de los prototipos Mora Mallqui Ivan

26/06/2012 4.2 Integración del Documento Luis Peña

Palacios

27/06/2012 4.5 Reglas de negocio, requerimientos todos

no funcionales y metas y
restricciones.

05/06/2012 4.6 Creación del documento Final todos

06/06/2012 4.7 Corrección del Documento Final Todos

15/06/2012 4.8 Revisión del Scrum Master Luis Peña

Palacios

Fecha de Actualización: 15/06/2012 Gestión del Proyecto SISGERAP

Responsables: María Isabel Canchari, Iván Versión: 1.2 SISGERAP
Mora, Arias Camacho, Jhino
 4

RESUMEN EJECUTIVO

PIO´s Chicken, empresa dedicada al rubro de restaurantes pollería, inicia sus

actividades en el año 2001, con el propósito de satisfacer los gustos exigentes de
sus clientes.

Ha extendido sus servicios al delivery, asistencia a eventos especiales,

promociones de fiestas infantiles, entre otros, consolidando su posición en el
exigente mercado limeño, basando su éxito en una visión empresarial y en una
estrategia de crecimiento a través de franquicias.

Siendo que hoy en día la mayoría de las empresas se están acoplando más a un
mundo donde la automatización de procesos, la optimización de las actividades, y
el control laboral efectivo es el objetivo primordial para lograr un funcionamiento
efectivo en el medio. Pios Chicken nos ha encargado implementar un sistema que
les permita llevar un control más estricto y eficiente de sus procesos, en razón a
que en este momento los pedidos que realizan los comensales se vienen
realizando de manera manual e incluso de forma errónea, generando
insatisfacción en el cliente e incluso perdiendo algunos de ellos.

Los pagos que se realizan son anotados de forma manual en boleta de consumo
y facturas manuales lo cual toma mucho tiempo para poder saber cuántos
pedidos fueron registrada al día.

Así mismo las reservas se anotan en un libro de anotaciones sin llevar un control
sobre las reservas solicitadas por los comensales.

El Sistema de Gestión de Reservas, Atención y Pagos (SIGERAP), le permitirá

a la empresa Pio´s Chicken gestionar sus procesos eficientemente

Asimismo, es importante mencionar que se ha aplicado una nueva metodología

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 5

de gestión de trabajo, Scrum el mismo que nos ha permitido organizar

entregables según el avance del proyecto. La idea es crear una aplicación
iteractiva, rápida y eficaz

ÍNDICE

RESUMEN...............................................................................................................IV

ÍNDICE......................................................................................................................V

INTRODUCCIÓN.....................................................................................................XI

1. DESCRIPCIÓN DEL PROYECTO..................................................................1

1.1. Objeto de Estudio..........................................................................................1

1.1.1. Descripción del proyecto............................................................................1
1.1.2. Objetivos de la organización......................................................................2
1.1.2.1 Objetivos Generales de la organización........................................2
1.1.2.2 Objetivos Específicos de la organización......................................2

2. MODELADO DE NEGOCIO............................................................................5

2.1. Reglas del Negocio........................................................................................5

2.2. Modelado de Casos de Uso del Negocio..................................................15

2.2.1. Lista de Actores del Negocio...................................................................15
2.2.2. Diagrama de Casos de Uso del Negocio................................................16

2.3. Realización de Casos de Uso del Negocio...............................................17

2.3.1. Especificaciones de Casos de Uso del Negocio.....................................17
2.3.1.1. CUN001 – .........................................................................................17
2.3.1.2. CUN002 – .........................................................................................25
Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken
Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 6

2.3.2. Diagramas del Actividades......................................................................30

2.3.2.3. CUN001 –..........................................................................................30
2.3.2.4. CUN002 –..........................................................................................35

2.4. Modelo de Análisis del Negocio.................................................................41

2.4.1. Lista de Trabajadores del Negocio..........................................................41
2.4.2. Lista de Entidades del Negocio...............................................................41

3. REQUERIMIENTOS......................................................................................48

3.1 Especificación de requerimientos de Software........................................48

3.1.1. Funcionalidad...........................................................................................48
3.1.2. Suposiciones y dependencias.................................................................50
3.1.3. Licencia e Instalacion...............................................................................50
3.1.4. Seguridad.................................................................................................51
3.1.5. Seguimiento continuo de las ordenes de pedido....................................51
3.1.6. Requerimientos de Diseño......................................................................51
3.1.7. Ayuda en Línea........................................................................................52
3.1.8. Standares aplicables................................................................................52
3.1.9. Desempeño..............................................................................................52
3.1.10. Entorno.....................................................................................................53
3.1.11. Documentación........................................................................................53

3.1. Modelo de Casos de Uso del Sistema.......................................................54

3.1.1. Lista de los actores del sistema...............................................................54
3.1.2. Diagrama de Actores del Sistema...........................................................55
3.1.3. Diagrama de Paquetes............................................................................55

3.2. Priorización de los Casos de Uso del Sistema.........................................61

3.2.1. Clasificación de los casos de uso del sistema........................................61

3.3. Realización de los Casos de Uso del Sistema..........................................64

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 7

3.3.1. Especificación de Alto Nivel.....................................................................64

Especificación de los casos de uso del sistema..................................................70
3.3.1.1. CUS001 – Generar Comanda...........................................................70
3.3.1.2. CUS002 – Generar Cuenta de Consumo..........................................76
3.3.1.3. CUS003 – Generar Comprobante de Pago.......................................81
3.3.1.4. CUS006 – Generar Voucher..............................................................90
3.3.1.5. CUS007 – Generar Ticket de Atención.............................................93
3.3.1.6. CUS008 – Generar Lista de Insumos................................................97

3.4. Modelo Conceptual......................................................................................127

3.4.2. Diccionario de Clases..............................................................................128

4. ARQUITECTURA DE SOFTWARE............................................................137

4.1. Metas y restricciones................................................................................138

4.2. Vista de Casos de Uso..............................................................................143

4.2.1. Diagrama mostrando los actores y sus relaciones................................143

4.3. VISTA LÓGICA.............................................................................................147

4.3.1. Vista general............................................................................................149

4.3.1.1. Diagrama de Capas...........................................................................149
4.3.1.2. Descripción de Capas........................................................................150
4.3.1.3. Paquetes de diseño más significativos..............................................151
4.3.1.4. Diagrama de Paquetes......................................................................151
4.3.1.5.Diagrama de clases con las principales clases de diseño.................151
4.3.2. Realizaciones de los casos de uso de Diseño...................................153
4.3.2.1. CUS001 – Generar Comanda.........................................................153
4.3.2.2. CUS002 – Generar Cuenta de Consumo........................................154
4.3.2.3. CUS003 – Generar Comprobante de Pago....................................155
4.3.2.4. CUS004 – Generar Voucher............................................................156
4.3.2.5. CUS005 – Generar Ticket de Atención...........................................157

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 8

4.3.2.6. CUS006 – Generar Lista de Insumos..............................................157

4.4.1 Vista de Implementación..................................................................161

4.4.2. Vista de Despliegue..........................................................................161
4.4.3. Vista de Datos...................................................................................162
4.4.3.1. Diagrama Entidad............................................................................162

5. ANEXOS...........................................................................................................177

5.1 ANALISIS....................................................................................................177
5.1.1. Diagramas de secuencia y de clase de análisis por escenarios...........177
5.1.1.1. CUS001 Generar Comanda............................................................177
5.1.1.2. CUS002 Generar Cuenta de Consumo...........................................179
5.1.1.3. CUS003 Generar Comprobante de Pago........................................181
5.1.1.4. CUS004 Generar Voucher...............................................................183
5.1.1.5. CUS005 Generar Ticket de Atención..............................................185
5.1.1.6. CUS006 Ejecutar Lista de Insumos.................................................187
5.1.2. Diagrama de Clases..............................................................................205
5.1.3. Diagrama de Clases con Atributos y Relaciones..................................206

5.2 Casos de Prueba........................................................................................207

CONCLUSIONES.................................................................................................214

BIBLIOGRAFÍA....................................................................................................215

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 9

INTRODUCCIÓN

Sistema de Gestión de Exportación de Artesanías (SISGEXA) es un proyecto

que innovará las capacidades tecnológicas en la empresa INKATRADE puesto
que contará con la metodología RUP de IBM que propone buenas prácticas en el
desarrollo de Software.

El proyecto que presentamos como solución tiene como objetivo principal realizar
un profundo análisis de los procesos que se dan en la empresa, con la finalidad
de optimizar aquellos que sean posibles y brindar un mejor rendimiento y
disminución en los tiempos del proceso. De tal manera que el manejo de
información sea confiable, disminuyendo el grado de incertidumbre producida por
el error humano.

El sistema que proponemos plantea automatizar el proceso de comercialización y

exportación de artesanías desde que se recibe el pedido, se realizan las
adquisiciones requeridas, se embala y envía el pedido atendido, al verificarse el
pago con depósito en las cuentas de la empresa.

SISGEXA es la solución planteada para la problemática de INKATRADE que

tiene estos procesos de comercialización en forma manual, lo cual no permite la
eficiencia de sus actividades ni la confiabilidad esperada. El personal (vendedor)
que usará el sistema administrará los pedidos y se podrá asignar al negociador
que esté más experimentado según el tipo de pedido recibido por parte de los
Clientes. Al tener el pedido completo se embalará para el envío respectivo.

Los pedidos serán manejados con un control automatizado de la disponibilidad de

proveedores según la artesanía requerida. El encargado de área controlará tanto
el proceso de recepción de pedidos como el seguimiento y contacto que realicen
los negociadores responsables, luego llevará el control de los pagos recibidos
para elaborar sus informes.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 10

1. Descripción del Proyecto

1.1. Definición del Proyecto

El proyecto “SISGEXA” consiste en la elaboración de un producto de
software para la Empresa INKATRADE, cuyo local se encuentra ubicado
en la ciudad de Trujillo; en la cual se hará uso del Proceso Unificado
Rational (RUP).

Con el desarrollo de este proyecto se plantea automatizar todas las

actividades que se realizan manualmente tanto como sean posibles desde
el momento que los pedidos son recibidos por los vendedores, asignación
de negociadores y envío de pedidos embalados por barco o avión a su
destino según los contratos pactados.
El proyecto será propuesto y desarrollado por los alumnos del Curso de
Ingeniería de Software Orientado a Objetos.

1.1.1. Objetivos General de la Organización

Consolidar su posición en el exigente mercado de exportaciones de
artesanías
.
1.1.2. Objetivos Específicos de la Organización
a. Incrementar en 15% los niveles de venta por trimestre en el
mercado internacional de artesanías.
b. Reducir el nro de incidencias mensuales de envío al 5%.
c. Optimizar los canales de atención a nuestros clientes.
d. Tener un control total del producto desde su elaboración en los
talleres de los proveedores hasta su embarque según los
requerimientos del cliente, para asegurar la calidad y el tiempo
de atención establecido.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 11

1.2. Alcance del Proyecto

El alcance de este proyecto consiste en el diseño del sistema y toda la
documentación de cada etapa del proceso del RUP (Rational Unified
Process). El producto a entregar consiste en el modelamiento del negocio
propuesto y recomendaciones de hardware a usar.

2. MODELADO DE NEGOCIO
La empresa “INCATRADE” es una sociedad anónima cerrada de capitales
mixtos (colombianos y peruanos) - comercializadora – ubicada en la ciudad
de Trujillo, cuya finalidad es la exportación de artesanías, con más de 15 años
de experiencia en ese campo, siendo una de las empresas de mayor
crecimiento en el Perú. Cuenta con una gerencia altamente profesional, donde
la artesanía de cerámica utilitaria es su principal rubro de negocio. Cuenta con
excelentes clientes en el exterior.
PRODUCTOS
• Textiles
• Orfebrería
• Cerámicas
• Piedra tallada
MERCADOS EN EL EXTERIOR
Estados Unidos – 45%
Reino Unido – 10%
Alemania – 10%
Francia – 3%
Canadá – 15%
Japón – 17%
PROVEEDORES
Asociaciones de Artesanos de Ayacucho (Quinua), Cusco, Huancayo, Piura.
PROCESO DE COMERCIALIZACIÓN
Los clientes generan su pedido por Internet, estableciendo las características
del producto, sus especificaciones técnicas y la forma de envío, embalaje
Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken
Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 12

requerido para ingresar a su país.

Al verificarse y validar el pedido, se establecen las condiciones de pago, fecha
de entrega y modo de envío.
Al tener el pedido formalizado, se procede a coordinar con el (los)
proveedor(es) requerido(s), indicando las especificaciones establecidas con el
cliente, luego al establecer la Orden de Compra, se debe determinar las
fechas de entrega, penalidades, formas de envío. Parte de las políticas de la
empresa es realizar el seguimiento del producto desde su elaboración hasta
que lo recibimos en nuestras instalaciones, mediante el envío de supervisores
y corroborar el cumplimiento de estándares, buscando asegurar la calidad del
producto.
Al cumplirse los tiempos de entrega, se preparan los envíos desde los puntos
de producción y se procede al trabajo en aduana. Nuestra empresa, tiene la
obligación con el Cliente hasta que la sube la mercadería al barco y el dueño
la traslada a su destino (FOB).
El cobro de la mercadería atendida se realiza de dos formas: por adelantado o
contra embarque.

2.1. Reglas del Negocio

Reglas de Negocio
Casos de uso
Código Nombre Descripción
afectados
Reglas de Negocio que han sido absorbidas por el sistema
R001 Los pedidos Los pedidos son registrados on- Gestión de Pedido
recibidos se line con detalle de las
registran en el especificaciones y
Formulario de requerimientos del cliente.
Pedidos
Reglas de Restricción de Estructura
R002 Todo vendedor Todo vendedor debe tener su Gestión de Ventas
debe tener su Cartera de Clientes asignada y
Cartera de Clientes así llevar el seguimiento
asignada. respectivo.
R003 El vendedor puede Un vendedor recepciona y Gestión de Pedido
atender uno o más asigna uno o muchos pedidos
pedidos

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 13

R004 El negociador Un negociador tiene uno o varios Gestión de

maneja su cartera proveedores asignados, cada adquisiciones
de proveedores. proveedor tiene un negociador al
cual está asignado.
R005 Cada pedido debe Todo pedido se embala y queda Gestión de envíos
ser embalado en listo para ser embarcado
según las según los estándares.
exigencias del
Cliente.
R006 El vendedor se El vendedor se encarga de Gestión de
encarga de embarcar la mercadería y embarques
embarcar la realizar la documentación
mercadería pertinente
R007 Tiempo máximo de El pedido embalado debe Gestión de almacén
permanencia de un permanecer máximo 24 en los
pedido en almacén almacenes cercanos al punto de
24 horas. embarque.
R008 Los encargados de Los encargados de área Realizar estudio de
área realizan mantienen la vista mercado
estudios de permanentemente en los
mercado mercados internacionales y
frecuentemente buscar nuevas plazas de
desarrollo.

2.2. Modelado de Casos de Uso del Negocio

2.2.1. Lista de Actores del Negocio

Lista de Actores del Negocio

Nombre Descripción

Persona natural o jurídica que realiza un pedido

desde donde se encuentre, establece sus
condiciones y formas de envío.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 14

Persona que elabora y nos proporciona las

artesanías según las especificaciones del
Cliente.

Persona encargada de gestionar y supervisar el

funcionamiento de los diversos procesos del
negocio.

Persona

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 15

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 16

2.2.2. Diagrama de Casos de Uso del Negocio

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 17

2.3. Realización de Casos de Uso del Negocio

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 18

2.3. Modelo de Análisis del Negocio

2.3.1. Lista de Trabajadores del Negocio

Lista de trabajadores de negocio

Nombre Descripción
Responsable de gestionar la carta de platos.

Solicita los insumos a los proveedores.

Lleva un control estricto de verificar la

preparación de los platos.
Responsable de generar los comprobantes de
pago y generar la cuenta de consumo.

Responsable de recibir las solicitudes de las

comandas que corresponda a su función esto
para atención en el local.
Responsable de generar los tickets de atención
a los comensales cuando esté lleno.
Responsable de generar los servicios delivery a
solicitud de los clientes por llamadas
telefónicas.
Responsable de recibir las solicitudes de las
comandas que corresponda a su función esto
ya sea para el local o para el servicio delivery
para su elaboración.
Responsable de realizar la carta de bebidas
solicitada por los comensales.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 19

2.3.2. Lista de Entidades del Negocio

Lista de entidades de negocio

Nombre Descripción Origen Tipo

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 20

I F
Esta Entidad contiene los datos de
los insumos que se hacen uso para
la preparación de los platos.

I P

Esta entidad contiene al detalle la

deuda que posee el cliente con la
empresa.

I F

Entidad que tiene todos los datos

del los pedidos consumidos por el
comensal en el restaurante.

I F
Comprobante de pago que se
generando usando como modo de
pago con tarjeta (crédito o débito).

E F

Lista de las tarjetas con las que

puede pagar el comensal.

I P
Entidad en la cual se registran todas
las reservas que se hacen alrededor
del día en el restaurant.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 21

I F
Entidad con la lista de todos los
platos que se ofrecen en el
restaurant.

I F

Entidad que contiene los datos de

los proveedores del restaurante.

E F
Entidad que contiene el listado de
las cuales por las cuales puede
accede el delivery.

I P

Entidad en la cual se encuentran los

comensales que se encuentran en
espera

I F
Entidad en la cual se anotan todos
los pedidos de las mesas en el
restaurant.

3. REQUERIMIENTOS

3.1 Especificación de requerimientos de Software

Esta sección contiene la descripción de los requerimientos de software con nivel
de detalle suficiente para que los analistas y diseñadores definan el sistema para
satisfacerlos y que los testadores prueben que el sistema los satisface.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 22

3.3.1. Funcionalidad
Requisitos Funcionales
Requerimiento
Código
RF001 Registrar una comanda
RF002 Registrar los datos detallados de la razón social, cuando el
cliente solicite una Factura

RF003 Proveerá la opción “Generar Cuenta de Consumo” al aprobar

una comanda solicitada
RF004 El sistema al generar una transacción de venta, podrá
contemplar la modalidad de pago en efectivo, tarjeta de crédito
y débito, registrando el número de operación en el caso de las
tarjetas.

RF005 Imprimir el comprobante que se genera en una cuenta

Requisitos No Funcionales

Tipo de Requisito Código Descripción

Los usuarios cuentan con un
nombre de usuario y clave
RNF-001 asignados por la facultada los
cuales lo utilizaran para que
Seguridad puedan ingresar al sistema.

El usuario cambiara de
RNF-002 contraseña cuando vea
conveniente.

Estándares El software será diseñado con los

RNF-003
Aplicables estándares de la empresa.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 23

Tipo de Requisito Código Descripción

Se desarrollará con la tecnología

RNF-004
Requisitos del JAVA
Sistema
El motor de base de datos que
RNF-005
utilizara el sistema será Mysql 5.2
El Sistema deberá permitir el
RNF-006 ingreso concurrente de por lo
menos 20 usuarios concurrentes
El tiempo de respuesta del
sistema para operaciones de
RNF-007 ingreso o registro de información
Requisitos de deberá ser como máximo 10
Desempeño segundos de espera

El tiempo de respuesta de la
RNF-008 ayuda de soporte será en no
máximo de 30 minutos.

El tiempo de levantamiento del

RNF-009
software no será más de 10 min.
Requerimientos de
El sistema será diseñado de
Usabilidad RNF-010
manera dinámica y fácil de usar.

La interfaz del usuario se

diseñará de tal manera que
facilite el uso de la misma, sin
RNF-011
necesidad de un soporte del área
de sistemas. Y tendrá que ser
validada por el usuario.
En caso de error del usuario el
RNF-012 sistema informará claramente: el
mensaje del error y la solución.

El sistema deberá mantener

almacenado a los responsables
RNF-013
que se encargaron a registrar los
pedidos.

El sistema deberá mantener

RNF-014 almacenado el contenido histórico
de todos los pedidos.
RNF-015 El sistema actualizará la base de
Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken
Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 24

Tipo de Requisito Código Descripción

datos en tiempo real, permitiendo
que los reportes sean 100%
reales.
El sistema estará diseñado para
permitir realizar archivos de
RNF-016
respaldo (backups) en forma
manual o automática.

El sistema contará con un manual

RNF-017
de usuario.
Requerimientos de
Utilización
El software mantendrá una
RNF-018 coherencia en la interfaz del
usuario.
Requerimientos de 1. Licencia para Windows Server
RNF-019
Licenciamiento 2008.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 25

3.1.2 Suposiciones y Dependencias

El Sistema de Gestión de Reservas, Atención y Pagos que estará en la empresa

seguirán en continuo control y mantenimiento hasta el 2014.

3.1.3 Licencia e Instalación

La gran parte del software utilizado para el desarrollo del SIGERAP será adaptado
a los software que están implementados en la empresa y todos ellos cuentan con
una licencia.

3.3.3 Seguridad Implementada

- El usuario, para poder ingresar algún pedido, tiene que ingresar su

usuario y contraseña para poder ingresar al módulo.
- El Administrador del Sistema tendrán privilegios especiales para
poder modificar datos especiales con respecto a los pedidos.

3.3.4 Seguimiento continuo de las Ordenes de Pedidos

- El usuario usará el módulo por medio de una búsqueda que brindara

los estados en el que se encuentran los pedidos, mostrando también
quien los atiende.

3.3.5 Ayuda en línea

El módulo contará con ayudas en línea para ayudar al usuario en su uso.

3.3.7 Estándares Aplicables

Todos los aplicados a sistemas de restaurantes.

3.3.8 Requerimientos del problema

 Sistema operativo.
 Base de datos online.
 Acceso a internet

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 26

3.3.9 Requerimientos de Desempeño

Hardware optimo.

3.3.10 Requerimientos de Entorno

Espacio exclusivo para los servidores.

3.3.11 Requerimientos de Documentación

Manual de usuario
Manual del sistema.
Ayuda en línea
Ayuda mediante texto que estará en la web.
Guías de Instalación, Configuración, y Fichero Léame
Todo se incluirá en el instalador.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 27

3.1. Modelo de Casos de Uso del Sistema

3.1.1. Lista de los actores del sistema

Lista de actores del sistema

Nombre Descripción

Responsable de gestionar la carta de platos.

Solicita los insumos a los proveedores.
Lleva un control estricto de verificar la preparación de
los platos.

Responsable de generar los comprobantes de

pago.
Responsable de generar la cuenta de consumo.

Responsable de generar los tickets de atención a los

comensales cuando esté lleno.

Responsable de generar los servicios delivery a

solicitud de los clientes por llamadas telefónicas.

Responsable de generar las comandas en el local

cuando el comensal le solicita pedidos de la carta de
platos.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 28

Responsable de la administración del restaurante.

Responsable de consultar las estadísticas

Responsable de generar, actualizar y consultar las

comandas de salón

Responsable del ingreso al sistema

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 29

3.1.2. Diagrama de Actores del Sistema

3.1.3. Diagrama de Paquetes

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 30

3.1.4. Lista de los Casos de Uso del Sistema por paquete

Lista de Casos de Uso del sistema

Nombre Descripción

Generar el ticket de atención para el comensal.

Consultar la cuenta de consumo del comensal

El cajero genera la cuenta de consumo del

comensal cuando este se retira del establecimiento.

Se consulta la comanda para revisar los pedidos

que hacen los comensales.

Ingresa de los usuarios al sistema SIGERAP

Registrar comensal.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 31

Buscar Comensal que ya se encuentra registrado

en el sistema.

Busca una mesa especificada con anterioridad

Registra insumos para la carta

El Personal de Pedido genera la comanda de los

pedidos del comensal.

El cajero genera voucher de pago a los comensales

que realizan pago con tarjeta.

El cajero emite comprobante de pago de los

consumos realizado por el comensal.

3.1.5. Diagrama de Casos de Uso del Sistema

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 32

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 33

3.2. Priorización de los Casos de Uso del Sistema

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 34

3.2. Realización de los Casos de Uso del Sistema

3.3.1. Especificación de Alto Nivel

Caso de Uso: CUS001 – Generar Comanda

Actor(es): Personal de pedido
Propósito: Generar una comanda para el cliente o comensal
Descripción: El caso de uso permite a un personal de pedido generar
una comanda para un cliente o comensal cuando este
solicita un pedido de la carta de platos ya sea de forma
presencial o vía telefónica. Estos pedidos se van
acumulando a la comanda a medida que se van solicitando
uno o más pedidos.
Clasificación: Primario

Caso de Uso: CUS002 – Generar Cuenta de Consumo

Actor(es): Cajero
Propósito: Mantener actualizados los montos de consumo.
Descripción: El caso de uso permite al cajero "Generar una cuenta de
Consumo" a solicitud del mozo para saber el monto de los
consumos realizados en la mesa.

Clasificación: Primario

Caso de Uso: CUS003 – Generar Comprobante de Pago

Actor(es): Cajero
Propósito: Obtener comprobante de pago
Descripción: El caso de uso permite al cajero generar un comprobante
de pago para el cliente, el cual solicita hacer el pago de su
consumo, ya sea efectivo o con Tarjeta.
Clasificación: Primario

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 35

Caso de Uso: CUS004 – Generar Voucher

Actor(es): Cajero, Sistema Pago de Tarjetas
Propósito: Emitir registro de pago
Descripción: Este caso de uso permite al cajero emitir un registro por el
pago de los consumos que realizo en el local por un medio
de pago siendo una tarjeta.

Clasificación: Primario

Caso de Uso: CUS005 – Generar Ticket de Atención

Actor(es): Recepcionista
Propósito: Generar ticket de atención
Descripción: El caso de uso permite al recepcionista generar un ticket de
atención para un comensal cuando solicita una mesa y
éstas aún no están disponibles.

Clasificación: Primario

Caso de Uso: CUS006– Registrar Lista de Insumos

Actor(es): Jefe de Cocina
Propósito: Registrar Lista de insumos
Descripción: El caso de uso permite al Jefe de Cocina solicitar los
insumos necesarios para el funcionamiento de la pollería a
un proveedor que determinado.

Clasificación: Primario

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 36

Especificación de los casos de uso del sistema

CUS001 – Generar Comanda

1. Breve Descripción
Este caso de uso permite a un personal de pedido generar una comanda para un
cliente o comensal cuando este solicita un pedido de la carta de platos ya sea de
forma presencial o vía telefónica. Estos pedidos se van acumulando a la comanda
a medida que se van solicitando uno o más pedidos.
2. Actor
Personal de Pedido
3. Flujo de Eventos
3.1 Flujo Básico
1. El caso de uso inicia cuando el personal de pedido solicita "Generar
Comanda" en la interfaz “Menú Principal”.
2. El sistema muestra la interfaz “Generar Comanda” con los siguientes
datos:
Datos de la Comanda: Numero de Comanda (###), fecha de la
comanda (cargada) y hora de la comanda (cargada), Número de
mesa.
Datos de Comensal: DNI, Nombre, Apellido.
Datos Envió (Inhabilitado): Teléfono, Dirección, Referencia
Datos del Pedido: Categoria, descripción, Cantidad, Detalle.
Una grilla que listara los pedidos agregados.
Además incluye las opciones: Registrar Comensal, Generar
Comanda, Buscar Comensal, Agregar Pedidos, Imprimir Comanda y
Salir.
3. El personal de pedido selecciona un número de mesa.
4. Si el personal de pedido selecciona numero de mesa D1 a D10.
4.1 Ir al subflujo "Comanda por delivery".
5. Si el personal de pedido selecciona numero de mesa 1 a 25.
5.1 Ir al subflujo "Comanda presencial".
6. El personal de pedido ingresa los datos del pedido.
7. El personal de pedido selecciona la opción "Agregar Pedido".
8. El sistema agrega el pedido a la lista de detalle de comanda.
9. Si el personal de pedido desea agregar otro pedido se repite los
pasos 6 al 8.
Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken
Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 37

10. El personal de pedido solicita "Generar comanda".

11. En el sistema quedará grabado la comanda con su detalle. El
sistema actualiza la mesa en estado "ocupado".
12. El personal desea imprimir.
12.1 El sistema imprime la comanda.
13. El personal de pedido solicita "salir" y el caso de uso termina.

3.2 Flujo Alternativo

Comensal no existe
Si el sistema no encuentra Datos de Comensal, el sistema muestra
un MSG “Comensal no Registrado” y ofrecerá la posibilidad de
registrar al comensal solicitando "Registrar Comensal", el sistema
incluye el CU ”Registrar comensal”.

Comanda no registra
Si el sistema no llega a grabar la Comanda y/o detalles enviará el
mensaje “Comanda no registrada” y el caso de uso finaliza.
Eliminar Pedido
Si el personal de pedido desea eliminar un pedido de la grilla,
seleccionara la opción eliminar “X”, el sistema muestra un mensaje
de confirmación “Desea eliminar el pedido de la lista” y el caso de
uso retorna al punto 9.
Datos Incompletos
Si no se ingresa los campos solicitados el sistema muestra el
mensaje “Por favor ingrese los campos solicitados”.
3.3 Subflujo
3.3.1 Comanda por Delivery.

1. El sistema habilita los datos de envío.

2. El personal de pedido solicita “buscar comensal”. El caso de uso
incluye el “CU Buscar Comensal”.
3. El sistema muestra los datos del comensal.
4. El personal de pedido ingresa los datos de envío.
5. Regresar al punto 6 del flujo básico.
3.3.2 Comanda presencial

1. El sistema habilita los datos de mesa.

2. El personal de pedido selecciona mesa Disponible.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 38

3. Regresa al punto 6 del flujo básico.

3.3.3 Eliminar Pedido

1. El sistema habilita los datos de mesa.

4 Requerimientos Especiales
1. El sistema estará conectado a una impresora.
5 Precondiciones
1. El personal de pedido esta logueado en el sistema.
2. Lista de Categorías disponibles.
3. Lista de Descripción de Producto disponible.
4. Lista de Mesas disponibles.
6 Post Condiciones
1. La comanda quedará registrado en el sistema con su detalle
2. Al generar la comanda el estado de la mesa procede a cambiar de
estado "OCUPADO".
7 Puntos de Extensión
Ninguno

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 39

8 Prototipos

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 40

CUS002 – Generar Cuenta de Consumo

1. Breve Descripción
Este caso de uso permite al cajero "Generar una cuenta de Consumo" a
solicitud del mozo para saber el monto de los consumos realizados en la
mesa.
4. Actor
Cajero
5. Flujo de Eventos
2.1 Flujo Básico
14. El caso de uso inicia cuando el cajero selecciona "Generar Cuenta
Consumo" en la interfaz “Menú Principal”.
15. El sistema obtiene la fecha del sistema.
16. El sistema muestra la interfaz “Generar Cuenta Consumo ” con los
siguientes datos:
Datos de la Cuenta de Consumo: Número de Cuenta Consumo N°
de Cta. Consumo (Cargado), fecha de la cuenta consumo Fecha
Consumo (Cargado), IGV, Total, Estado.
Datos Comanda: N° mesa (Listado Cargado), N° Comanda, Código,
Descripción, Cantidad, Precio Unitario y Total.
Datos del Envió: Dirección, teléfono y referencia.
Datos del Comensal: DNI, Apellidos y Nombres.
Además incluye las opciones: Consultar Comanda, Generar
Cuenta de Consumo, Imprimir y Salir.
17. El cajero elige la comanda del listado de comanda cargado
18. El cajero selecciona la opción consultar comanda.
19. El sistema muestra los datos de la comanda, datos del envió y
datos del comensal en la interfaz "Generar Cuenta de Consumo".
20. El sistema calcula el SUB-TOTAL, por todos los pedidos solicitados
en la comanda.
21. El sistema calcula el TOTAL, agregando el 18% de IGV del SUB-
TOTAL.
22. El cajero solicita Generar Cuenta de Consumo en estado
“TERMINADO”.
23. El cajero selecciona imprimir.
24. El cajero solicita "Salir" y el caso de uso termina.

2.2 Flujo Alternativo

5.1 Datos Incompletos

Si no se selecciona el número de mesa el sistema muestra el
mensaje “Por favor, seleccione una mesa”.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 41

5.1 5.2 Comanda no encontrada

El sistema muestra el MSG: “Comanda no encontrado”.

10.1 Cuenta de Consumo no generada

Si el sistema no llega a generar la cuenta de consumo enviará el
mensaje “Cuenta de Consumo no grabada” y el caso de uso finaliza.

6. Requerimientos Especiales
1. Tener una impresora conectada al terminal del cajero.

7. Precondiciones
5. El Cajero está logueado en el sistema.
6. La comanda para la mesa asignada debe estar generada.
7. Se debe cargar el listado de Mesa.

8. Post Condiciones
3. En el sistema quedara registrada la cuenta de consumo.

9. Puntos de Extensión
Ninguno

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 42

10. Prototipos

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 43

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 44

CUS003 – Generar Comprobante de Pago

1. Breve Descripción
Este caso de uso permite al cajero generar un comprobante de pago para
el cliente, el cual solicita hacer el pago de su consumo, ya sea efectivo o
con Tarjeta.
2. Actores
Cajero
3. Flujo de Eventos
3.1 Flujo Básico
1. El caso de uso inicia cuando el cajero accede al Sistema y solicita
“Generar Comprobante de Pago” en la interfaz del Menú Principal.
2. EL sistema muestra la interfaz Generar “Comprobante de Pago” con
los siguientes campos:
Datos Cuenta de Consumo
 Cuentas (combo cargado automáticamente)
 Total
Datos Cliente:
 Fecha Emisión (fecha actual del sistema)
 Tipo de Comprobante (combo)
 RUC/DNI (Según sea el caso)
 Razón social/Nombre (Según sea el caso)
 Dirección
Tipo de Pago
 Forma de pago (radio button: Contado – Tarjeta)
 Cancela con
 Monto a pagar

Además de las opciones “Consultar Cuenta de consumo”, “Aceptar”.

3. El cajero selecciona la cuenta según sea el caso.

4. El cajero selecciona la opción “Consultar cuenta de consumo”.
5. El sistema completa el campo Total, según la cuenta seleccionada.
6. El cajero ingresa RUC/DNI, Razón Social/Nombres, Dirección según
sea el caso.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 45

7. El cajero selecciona la forma de pago (Contado o Tarjeta).

8. El cajero ingresa el monto con el que el cliente le ha pagado.
9. El cajero ingresa el monto a pagar.
10. El cajero selecciona la opción “Aceptar”.
11. El sistema registra el comprobante de pago en base de datos, con la
fecha actual del sistema.
12. El sistema muestra el MSG: “Registro Satisfactorio”, además de
mostrar el vuelto total a entregar, y un enlace “Regresar”, el cual
lleve a la pantalla principal y el caso de uso finaliza.

a. Sub-Flujo
No existen sub – flujos.

b. Flujo Alternativo
6.1 Tipo de Pago “Tarjeta”
1. Si el cajero selecciona pago con “Tarjeta”, se abrirá una interfaz
para registrar dicho pago adecuadamente.

.
4. Requerimientos Especiales
1. Aprovisionamiento de papel con logo de la empresa para la impresión de
los comprobantes de pago
5. Precondiciones
1. El cajero logueado en el sistema.
2. Datos de consumo registrados en el sistema.
3. Lista de Clientes disponible
4. El Sistema debe contar con conexión dedicada para el sistema pago
de tarjetas.

6. Post Condiciones
1. El comprobante quedará registrado en el sistema con su respectivo
detalle.
2. Actualiza el estado de la Cuenta de Consumo.
7. Puntos de Extensión
No hay puntos de Extensión.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 46

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 47

8. Prototipo

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 48

CUS004 – Generar Voucher

2. Breve Descripción
Este caso de uso permite al cajero emitir un registro por el pago de los
consumos que realizo en el local por un medio de pago siendo una tarjeta.
9. Actores
Cajero, Sistema Pago de Tarjetas.
10. Flujo de Eventos
a. Flujo Básico
13. El caso de uso inicia cuando el cajero solicita "Tarjeta" en la interfaz
“Generar Comprobante de Pago”.
14. El sistema muestra la interfaz “Generar Voucher” con los siguientes
datos:
Datos de Voucher: Número de Operación (No editable), Fecha
(Cargada), Hora (Cargada).
Datos de Tarjeta: Nro de Tarjeta, Tipo de Pago, Fecha de
Vencimiento (Mes/Año) y Código de Verificación.
Datos de Consumo: Importe de Consumo (Cargado), Moneda, Nro
Cuotas.
Además de las siguientes opciones: Generar Voucher, Imprimir y
Salir.
15. El cajero ingresa los datos.
16. El cajero selecciona la opción “Generar Voucher”.
17. El sistema valida los datos ingresados del Voucher.
18. El sistema envía una trama al Sistema Pago de Tarjetas con los
datos de la transacción realizada.
19. El sistema graba el Voucher.
20. El sistema carga los datos en la interfaz del caso de uso base que lo
invocó y finaliza el caso de uso.

b. Flujo Alternativo
3.1 Numero de Tarjeta incorrecta
En el punto 3 del flujo básico, si la tarjeta ingresada es incorrecta muestra
el mensaje “Tarjeta ingresada errónea”
6.1 Transacción inválida
En los puntos 6 del flujo básico, si el sistema registra un error al ejecutar la
transacción, muestra el mensaje “Disculpe, en estos momentos no es posible
procesar su operación” y el caso de uso termina.

11. Requerimientos Especiales

1. La funcionalidad se implementara en una aplicación web.
Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken
Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 49

2. Tener una impresora conectada al terminal del cajero.3. En la impresión

de los tickets se mostrara el logo de la empresa.
12. Precondiciones
3. El cajero estará logueado en el sistema.
4. En el sistema la tarjeta del cliente existía y se encontraba en estado
“Activa”
5. El cliente ingresó el PIN correcto de la tarjeta.
6. La cuenta a pagar tenía el saldo suficiente para cubrir el monto del
pago.
13. Post Condiciones
1. El Sistema Pago de Tarjetas recibirá una trama con los datos del pago del
comensal.
2. El sistema generará un voucher que será dispensado por el POS al
comensal conteniendo los datos de la transacción.
3. El sistema carga el número de operación e importe a la interfaz “Generar
Comprobante de Pago”.
14. Puntos de Extensión
Ninguno

3 Prototipo

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 50

CUS005 – Generar Ticket de Atención

Breve Descripción
Este caso de uso permite al recepcionista generar un ticket de atención
para un comensal cuando solicita una mesa y éstas aún no están
disponibles.
Actores
Recepcionista
Flujo de Eventos
Flujo Básico
1. El caso de uso inicia cuando la recepcionista solicita "Generar Ticket
de Atención" en la interfaz “Menú Principal”.
2. El sistema obtiene el último número de Ticket de Atención auto
incrementado.
3. El sistema obtiene la fecha y hora del sistema.
4. El sistema muestra la interfaz “Generar Ticket de Atención” con los
siguientes campos:
Datos de Ticket: Número (autoincrementado), Fecha (), Hora
(Cargada).
Datos del Cliente: DNI, nombre, Apellido,
Datos de atención: Capacidad.
Además de las siguientes opciones, Generar Ticket, Imprimir
Ticket y Salir.
5.
6.
7.
8. La recepcionista selecciona la fecha en el calendario asociado al
campo Fecha.
La recepcionista ingresa datos de comensal (dni,Nombres,Apellidos)
9. La recepcionista ingresa dato de atención (capacidad).
10. La recepcionista selecciona la opción “Generar Ticket”.
11. El sistema valida los datos ingresados.
12. El sistema quedará grabado los datos del ticket con fecha, hora y
capacidad y los datos de comensal asociados al ticket
13. El sistema muestra el MSG: ”ticket registrado satisfactoriamente”
14. Si La recepcionista selecciona la opción “Imprimir”
El sistema imprime el ticket de atención.
12.La recepcionista selecciona la opción “Salir” y el caso de uso finaliza.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 51

Flujo Alternativo

Si el sistema no encuentra Datos de Comensal, el sistema muestra

un MSG “Comensal no Registrado” y ofrecerá la posibilidad de
registrar al comensal solicitando "Registrar Comensal", el sistema
incluye el CU ”Registrar comensal”.

8.1. Ticket de Atención no grabado

Si el sistema, no llega a grabar la ticket de atención y/o detalles enviará el
MSG: “Ticket de Atención no registrado” y el caso de uso finaliza.
3.2.2 Datos Incompletos
Si no ingresa lso datos requeridos
(Fecha,nombres,apellidos,dni,capacidad) el sistema muestra el
mensaje “Por favor ingrese los campos solicitados”.

Requerimientos Especiales
1. La funcionalidad se implementara en una aplicación web.
2. En la impresión de los tickets se mostrara el logo de la empresa.
Precondiciones
7. La recepcionista estará logueado en el sistema.
8. Lista de comensales disponible en el sistema.
Post Condiciones
3. El ticket quedará registrado en el sistema.
Puntos de Extensión
Ninguno.
Prototipo

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 52

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 53

CUS006 – Registrar Lista de Insumos

1. Breve Descripción
El caso de uso permite al Jefe de Cocina Solicitar los insumos necesarios para
el funcionamiento de la pollería.

2. Actor
Jefe de cocina.

3. Flujo de Eventos

3.1 Flujo Básico

1. El caso de uso se inicia cuando el jefe de cocina selecciona la opción
“Generar
Solicitud de Insumos” del menú lateral de la página web.
2. El Sistema muestra la interfaz “Solicitud de Lista de Insumos” con los
siguientes campos:
Datos de proveedor:
 razón social.
 Dirección
 RUC
Además de las opciones “Cargar Proveedor”, “Nuevo Proveedor”.
3. El Jefe de Cocina selecciona un proveedor de la lista de proveedores
disponibles.
4. El jefe de Cocina selecciona la opción cargar Proveedor.
5. El sistema carga los datos del proveedor.
6. El sistema Muestra la segunda parte de la interfaz:
Detalle de Insumo
 Nombre
 Descripción
 Unidad de medida con los datos (Kg. Gr., Lt.)
 Cantidad
Además de las opciones “Cargar Insumo”, “Nuevo Insumo” y “Agregar a la

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 54

Lista”.
7. El Jefe de Cocina selecciona un insumo de la lista mostrada.
8. El Jefe de Cocina selecciona la opción Cargar Insumo.
9. El Sistema carga los datos del insumo en la interfaz.
10. El Jefe de Cocina ingresa la cantidad solicitada del insumo.
11. El Jefe de Cocina selecciona “Agregar Solicitud de insumo”.
12. El sistema muestra un mensaje de confirmación.
13. El jefe de cocina acepta y el mensaje y el caso de uso finaliza.

3.2. Flujo Alternativo

5.1. Proveedor no figura en la lista de proveedores

 Si el proveedor no figura en la lista de proveedores, el Jefe de
Cocina selecciona la opción Nuevo Proveedor.
 El sistema muestra la interfaz de Registrar Nuevo Proveedor.
 El Jefe de Cocina completa los datos del nuevo proveedor.
 El Jefe de Cocina selecciona la opción “Registrar Proveedor”.
 El sistema registra los datos del proveedor en la Base de Datos.
 El sistema carga los datos del proveedor en la interfaz principal.
 El Caso de Uso continúa en el paso 6.

7.1. Proveedor no figura en la lista de proveedores

 Si el insumo no figura en la lista de insumo, el Jefe de Cocina
selecciona la opción Nuevo Insumo.
 El sistema muestra la interfaz de Registrar Nuevo Insumo.
 El Jefe de Cocina completa los datos del nuevo insumo.
 El Jefe de Cocina selecciona la opción “Registrar Insumo”.
 El sistema registra los datos del proveedor en la Base de Datos.
 El sistema carga los datos del proveedor en la interfaz principal.
 El Caso de Uso continúa en el paso 10.

11.1 Datos inválidos o campos vacíos

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken
Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 55

 En el paso 10, El sistema muestra el mensaje indicando que existen

campos llenados incorrectamente.

4. Requerimientos Especiales
No Aplica.

5. Precondiciones
1. El jefe de cocina logueado al sistema.
2. Lista de proveedores disponible.

6. Post Condiciones
La lista de insumos queda registrada con su detalle respectivo.

7. Puntos de Extensión
Ninguno.

8. Prototipo

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 56

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 57

3.4. Modelo Conceptual

3.4.1. Diagrama de Clases Entidad

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 58

Fecha de Actualización: 15/06/2012 Gestión del Proyecto PioChicken

Responsable: Responsables: María Isabel Versión: 1.2 PioChicken
Canchari, Iván Mora, Jhino Arias
 59

4. ARQUITECTURA DE SOFTWARE

1. Introducción
Este documento provee al usuario especializado una vista de la arquitectura
del Sistema SIGERAP
La plantilla de este documento se basó en las especificaciones de RUP
(Rational Unified Process) para el documento de arquitectura de software.

2. Propósito
Este documento proporciona una descripción de la arquitectura del sistema,
haciendo uso de diversas visiones arquitectónicas para representar diversos
aspectos del sistema. Se realiza con el fin de documentar las decisiones de
arquitectura significativas que se han tomado en el sistema.

3. Alcance
Este documento presenta proporciona una visión general de arquitectura del
sistema SIGERAP, definiendo de manera detallada la distribución de los
paquetes del sistema en las diversas capas que éste presenta, así como una
descripción de las capas a utilizar.
Este documento ha sido generado directamente desde el análisis de
SIGERAP y modelo de diseño implementado en RSA. La mayoría de las
secciones se han extraído del modelo de Rose con soda y la plantilla de
Arquitectura de Software de documentos.

4. Definiciones, Acrónimos, and Abreviaturas

Se brindan definiciones y acrónimos de términos usados en el presente
documento que necesiten de alguna explicación para su correcta
interpretación.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 60

5. Referencias
1. Documento de Especificación de Requisitos de Software de SIGERAP
2. Documento de Visión del Proyecto del Sistema SIGERAP
3. Glosario de Términos del Sistema SIGERAP.
4. Plan de Gestión de Requerimientos SIGERAP

6. Resumen
En todas las secciones de este documento se detalla la arquitectura del
software a desarrollar. Para ello se presenta de manera clara el caso de uso
que más representa la arquitectura del sistema, empleando un lenguaje
sencillo y directo, así como gráficos y vistas de acuerdo a la metodología
utilizada.

7. Representación de la Arquitectura.

Servidor
CapaTomcat
de Base de Datos del
Capa de Aplicación y
CapaSistema
de Datos
Presentación Lógica
J2EE de
Web Modeler Negocio
J2EE (JSP) Struts (Patrón
MVC)
Base de Datos
MySQL 5.1
JPA

La Arquitectura a utilizar será Cliente-Servidor. El cliente es la aplicación que será

implementada en el lugar donde se encuentra la empresa. Se desarrollará una sola
aplicación integrada, en la que solo se permitirá el acceso a los usuarios registrados

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 61

en el sistema y a las áreas a las cuales tengan acceso autorizado.

8. Metas y Restricciones de la arquitectura

La meta principal de la arquitectura del sistema es mostrar los aspectos
principales que influirán en la etapa de desarrollo.

Se tomarán en cuenta las siguientes metas y restricciones para el diseño de

la arquitectura del sistema.

4.2 Vista de Casos de Uso

4.2.1 Diagrama mostrando los actores y sus relaciones.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 62

4.3 Diagrama de casos de uso mostrando casos de uso significativos para

la arquitectura

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 63

4.4. Vista lógica

ista general

iagrama de Capas

La programación por capas es un estilo de programación en la que el objetivo

primordial es la separación de la lógica de negocios de la lógica de diseño.

<<layer>>
Presentacion

<<layer>>
Negocio

<<layer>>
Datos

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 64

cripción de Capas

1. Capa de presentación: es la que ve el usuario, presenta el sistema al usuario, le

comunica la información y captura la información del usuario dando un mínimo de
proceso (realiza un filtrado previo para comprobar que no hay errores de formato).
Esta capa se comunica únicamente con la capa de negocio.

2. Capa de negocio: es donde residen los programas que se ejecutan, recibiendo

las peticiones del usuario y enviando las respuestas tras el proceso. Se denomina
capa de negocio (e incluso de lógica del negocio) pues es aquí donde se establecen
todas las reglas que deben cumplirse. Esta capa se comunica con la capa de
presentación, para recibir las solicitudes y presentar los resultados, y con la capa de
datos, para solicitar al gestor de base de datos para almacenar o recuperar datos de
él.

3. Capa de datos: es donde residen los datos. Está formada por uno o más
gestores de bases de datos que realizan todo el almacenamiento de datos, reciben
solicitudes de almacenamiento o recuperación de información desde la capa de
negocio.

Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el

crecimiento de las necesidades lo aconseja se pueden separar en dos o mas
ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se
puede separar en varios ordenadores los cuales recibirán las peticiones del
ordenador en que resida la capa de negocio.

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 65

Realizaciones de los casos de uso de Diseño

CUS001 – Generar Comanda

Diagrama de Secuencia

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 66

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 67

Diagrama de Clases

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 68

CUS002 – Generar Cuenta de Consumo.

Diagrama de Secuencia

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 69

Diagrama de Clases

33

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 70

CUS003 – Generar Comprobante de Pago

Diagrama de Secuencia

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 71

Diagrama de Clases

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 72

CUS004-Generar Voucher
Diagrama de Secuencia

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 73

Diagrama de Clases

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 74

CUS005 – Generar Ticket de Atención

Diagrama de Secuencia

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 75

Diagrama de Clases

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 76

CUS006-Registrar Lista de Insumo

Diagrama de Secuencia

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 77

Diagrama de Clases

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 78

Vista de Componente

ista de Despliegue

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 79

Modelo Lógico

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 80

Modelo Físico

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 81

5. ANEXOS

ANALISIS

5.1.1. Diagramas de secuencia y de clase de análisis por escenarios.

CUS001 Generar Comanda

Diagrama de Clases

Diagrama de Colaboración Flujo Básico

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 82

CUS002 Generar Cuenta de Consumo.

Diagrama de Clases

Diagrama de Colaboración Flujo Básico

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 83

CUS003 Generar Comprobante de Pago.

Diagrama de Clases

Diagrama de Colaboración Flujo Básico

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 84

CUS004 Generar Voucher

Diagrama de Clases

Diagrama de Colaboración Flujo Básico

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 85

CUS005 Generar Ticket de Atención

Diagrama de Clases

Diagrama de Colaboración Flujo Básico

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
 86

CUS006 Registrar Lista de Insumos

Diagrama de Clases

Diagrama de Colaboración Flujo Básico

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias
Casos de Prueba

VER ANEXO 1
CONCLUSIONES

 La metodología Scrum sirve para la gestión y control de proyectos. Así mismo

la herramienta Scrumy nos ayuda a tener el control de tareas asignadas por
roles en los diferentes estados.
 El uso de las herramientas colaborativas cómo google code y subversion
tortoise, nos apoyaron con el control de las versiones, evitando duplicidad de
documentos.
 Las reuniones diarias (daily meeting), nos ayudó a tener una visión del
avance diario, actualizando el scrumy.
 Las realización de pruebas nos ayudó a poder comprobrar lo errores del
código de una manera anticipada, para evitar futuros cambios que costarían
más resolverlos.
 89

BIBLIOGRAFÍA
http://www.proyectosagiles.org/que-es-scrum
http://www.tecnotronic.edu.pe/web/comparaci%C3%B3n-entre-la-metodologia-rup-y-
srum

Fecha de Actualización: 15/06/2012 Gestión del Proyecto Sigerap

Responsable: Responsables: María Isabel Versión: 1.2 Sigerap
Canchari, Iván Mora, Jhino Arias