SISTEMA DE CONTROL DE PASAJEROS

EQUIPO:
ALAN KARL GOMEZ GARCIA JORGE RUELAS JUSTO CHSITIAN MENDEZ SARMIENTO 07/06/2012 7

Tabla de Contenidos Tabla de contenido

Tabla de contenido......................................................................................................2 Introduccin................................................................................................................ 2 Descripcin de la empresa..........................................................................................3 Modelado del sistema................................................................................................. 8 Definicin del problema............................................................................................11 Diccionario de datos..................................................................................................15 Modelo entidad Relacin...........................................................................................17

Introduccin
Como sabemos la tecnologa est evolucionando muy rpidamente, vemos que ante este acontecimiento algunas empresas no optan por hacer uso de esta y es uno de los principales motivos por la cual desarrollaremos este proyecto. En este presente trabajo, se desarrollara un SISTEMA DE CONTROL DE PASAJEROS, adems ser capaz de generar un Manifiesto de Pasajeros de la Empresa De Transportes Y Turismo SEOR DE LOCUMBA TORUS S.A.

Uno de los principales objetivos de este proyecto es la automatizacin de su control de pasajeros ya que esta empresa no cuenta con ningn sistema implementado, y todos sus procesos son manuales, esto representa una gran desventaja con respecto a la competitividad de esta. En un primer punto desarrollaremos una descripcin de la empresa, como se encuentra actualmente.

Descripcin de la empresa
1. Descripcin: La Empresa De Transportes Y Turismo SEOR DE LOCUMBA TORUS S.A. L&G
es una empresa dedicada al servicio de transporte y turismo de calidad. Adems, contamos con un personal altamente calificado y modernas unidades, la cual le ofrece a su distinguido pblico los siguientes servicios: -Traslados al aereopuerto.

-Citytours dentro de Lima. -Traslados de personal (Sector Empresarial). -Paseos y expresos. -Excursiones. -Alquiler de unidades: H1-Minivan. -Alquiler de autos: Toyota Corolla y Hyundai Accent. -Turismo a nivel nacional. Todas nuestras unidades son 0km. y estan muy bien equipadas para sus eguridad y comodidad. Nuestros tours anivel nacional y local incluyen gua bilinge.

2.

Misin y visin de la empresa

Misin: Proporcionar un servicio de transporte turstico confiable bajo los ms estrictos parmetros de seguridad, con la mejor hospitalidad, puntualidad, responsabilidad, en un ambiente confortable, con oportunidad de crecimiento para sus socios y colaboradores. Visin: Ser la mejor empresa de transporte turstico del pas, manteniendo la excelencia del servicio y la eficiencia de la empresa.

Boleta Actual

Nota de Pedido

2. Procedimientos de la empresa Diagrama de flujos rea Ventas

CLIENTE

VENDEDOR

Fabrica de Muebles

INICIO Solicita proforma Proforma Recibe Proforma Fin Inicio Solicita Pedido de Mueble(s)

El vendedor ve conveniente emitir proforma Llena proforma y solicita datos al cliente Proforma Hace llamada de Confirmacin y/o consulta Solicita datos del cliente Confirma y/o Determina el precio y Duracin de fabricacin del Mueble

Detalla el Mueble y sus precios y adelantos Desembolsa la cantidad acordada Contrato de Pedido Recibe Adelanto Acordado Recibe el Contrato de Pedido Firma Contrato de Pedido Fin Firma

Inicio Verifica contrato de Pedido Presenta su Contrato de Pedido Desembolsa el Saldo adeudado Recibe y verifica el pago Entrega el(los) Mueble(es) INICIO Forma de entrega y cancelacion

Fin

Desea Comprar

SI

Busca la boleta de Venta Solicita los datos del Cliente Detalla el o los Muebles Boleta de Venta

Recibe la Boleta de Venta Boleta de Venta

NO

Verifica

Recibe el pago acordado

Recibe los Muebles

Firma de entrega del Vendedor

Fin

Entrega el o los Muebles

Modelado del sistema

1. Diagrama de casos de Uso

Anular Comprobante

ADMINISTRADOR

Hacer Contrato de Pedido

<<include>> <<include>>

Hacer Proforma CLIENTE

<<include>>

Verificar

<<include>> Hacer boleta de Venta

Pago

VENDEDOR

2. Especificacin de los casos de uso

10

Definicin del problema

1. Identificacin y definicin del problema Todos los procesos que se llevan a cabo son manuales, se manejan archivos clsicos, por lo tanto se presentan los siguientes problemas: No se tiene un control del stock, no se sabe en tiempo real si hay o no un producto disponible para la venta, ya sea en el taller de fabricacin o en la tienda misma. No se tiene un control de precios, cuando estos cambian no hay una actualizacin inmediata de estos. Baja eficiencia en el manejo de los datos de ventas y otros procesos. Casi nula disponibilidad de los datos de los productos, ya que se encuentran agrupados en flderes, cuadernos de apuntes de telfonos y no son compartidos como lo seran con el sistema que permitira a los encargados de ventas tener acceso a los datos. No tener un sistema de consultas de los productos que estn disponibles o en proceso de fabricacin.

En este proyecto nosotros nos basaremos en el control de las ventas, as mismo el sistema desarrollado ser capaz de emitir boletas, proformas y contratos de pedidos. 2. Diagrama de clases
Cliente 0..n 0..n Vendedor 1 1..n Interfaz 1 0..n

Mueble

Administrador

Comprobante

Fecha

Boleta

ContratoPedido

Proforma

Pago

11

3. Definicin de requerimientos 3.1. Requerimientos Funcionales

REF REQ 1 REQ 2 REQ 3

REQ 4 REQ 5 REQ 6 REQ 7 REQ 8 REQ 9

SISTEMA Descripcin de requerimientos. El sistema ser capaz de registrar a un nuevo cliente. El sistema deber poder generar una boleta a partir de un pedido. El sistema ser capaz de verificar de identificar la autenticidad de los usuarios registrados antes de que puedan acceder. Si el usuario se autentifica correctamente, se abre una sesin con el sistema. El sistema deber mostrar un mensaje de valido una vez verificada la cuenta. El sistema, de no ser vlida la verificacin de la cuenta, deber mostrar un mensaje de denegado. El sistema deber poder generar vistas de la base de datos, de vendedores, de ventas y de stock. El sistema deber ser capaz de almacenar controles de ventas para ser visionadas en otro momento El sistema deber ser capaz de generar proyecciones y selecciones de las tablas de la base de datos El sistema deber ser capaz de generar proyecciones y selecciones de la tabla de ventas, (productos, servicios, modalidad, etc.)

Estado Valido Propuesto Propuesto

Prioridad Critico Important e Critico

Riesgo Critico Ordinario Critico

Propuesto Propuesto

Secundari o Secundari o Secundari o Important e Important e Critico

Ordinario Ordinario

Propuesto

Ordinario

Valido

Significati vo Significati vo Critico

Valido

Valido

3.2.

Requerimientos No funcionales Priorida d Important e Critico Riesgo Significativ o Critico

REQUISITO DE DESEMPEO REQNF1 Garantizar la confiabilidad, la seguridad y el desempeo del sistema informtico a los diferentes usuarios. El sistema debe estar en capacidad de dar respuesta al acceso de todos los usuarios y a los procesos batch con tiempo de respuesta

REQNF2

12

aceptable y uniforme REQUISITO DE ESCALABILIDAD REQNF3 El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental, de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados afectando el cdigo existente de la menor manera posible. El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades REQUISITOS DE AUDITORIA REQNF5 El sistema debe guardar informacin de cada usuario que ingrese al sistema (fecha, hora y usuario). RESQUISITO DE FLEXIBILIDAD El sistema debe ser diseado y construido con los mayores niveles de flexibilidad en cuanto a la parametrizacin de los tipos de datos, de tal manera que la administracin del sistema sea realizada por un administrador funcional del sistema. REQUISITO DE FIABILIDAD REQNF7 REQNF8 Los usuarios del sistema deben ingresar su login y password para ingresar al sistema. El sistema deber contar con mecanismos que permitan el registro de actividades con identificacin de los usuarios que los realizaron. La seguridad del sistema debe estar regida por las Polticas de Seguridad Informtica de la Comisin Intersectorial de Polticas y Gestin de la Informacin para la Administracin Pblica. Las claves de los usuarios deben ser guardadas en forma encriptada. REQUISITO DE MANTENIBILIDAD REQNF1 Toda el sistema deber estar complemente Priorida d Important e Riesgo Significativ o

REQNF4

Important e

Significativ o

Priorida d Opcional

Riesgo Significativ o Riesgo Significativ o

REQNF6

Priorida d Important e

Priorida d Important e Important e

Riesgo Significativ o Significativ o

REQNF9

Important e

Significativ o

REQNF1 2

Important e Priorida d Important

Significativ o Riesgo Significativ 13

documentado, cada uno de los componentesde software que forman parte de la solucin propuesta debern estar debidamente documentados tanto en el cdigo fuente como en los manuales de administracin y de usuario.

14

Diccionario de datos

D C N R D D T S- E P E A"M E L R O T " IC IO A IO E A O M R S U B E IA R IZ ET A N ID D E N_14_E MPR A ES C v N m te n o la e e o c ic K D A_14_R UC D A_14_E pNom m D A_14_E pD m ir D A_14_E pTel m D A_14_E pR m ep N m re o b R istro nico de C eg ontribuyente Nom E presa bre m D ireccion E presa m telefono E presa m representante E presa m D s rip io ec c n R istro nico de C eg ontribuyente de la em presa Nom de la em bre presa D ireccion de la em presa telefono de la em presa representante de la em presa T o ip Num C har C har C har C har L n itu og d

30 30 20 30

E N_14_C NTE LIE K D A_14_C od liC D A_14_C liNom D A_14_C ir liD C odig C o liente Nom C bre liente D ireccion C liente C odig del C o liente Nom del C bre liente D ireccion del C liente Num C har C har 30 30

E N_14_BOLETA_C AB k k k k D A_14_BolNum D A_14_BolFec D A_14_R UC D A_14_C od liC D A_14_C odPro D A_14_Tot D A_14_FecC an D A_14_E od plC Num B ero oleta Fecha B oleta R istro nico de C eg ontribuyente C odig C o liente C odig Producto o Total Fecha C ancelacion E pleado C m odig o Num de la B ero oleta Fecha de la B oleta R istro nico de C eg ontribuyente de la em presa C odig del C o liente C odig del Producto o total Fecha de C ancelacion C odig de Em o pleado Num C har Num Num Num R eal Num Num 30

E N_14_BOLETA_D T E D A_14_C anPro D A_14_PreVenPro D A_14_Tot D A_14_C odPro C antidad Producto Precio de venta Producto Total C odig Producto o C antidad del Producto Precio de venta del Producto Monto total C odig del Producto o Num Num Num Num

k E N_14_PR UC OD TO k

D A_14_C odPro D A_14_D esPro D A_14_PreUniPro

C odig Producto o D escripcion Producto Precio unitario Producto

C odig del Producto o D escripcion del Producto Precio unitario del Producto

Num C har Num

50

E N_14_E MPLE O AD kD A_14_E od plC D A_14_E plNom C odig E pleado o m Nom E pleado bre m C odig de Em o pleado Nom de Em bre pleado Num C har 30

16

Modelo entidad Relacin

NORMALIZACIN BOLETA DE VENTA Para identificar la Boleta de venta, hemos considerado como clave primaria el cdigo de la Boleta y adems, hemos deducido que necesariamente una boleta debe poseer todos esos campos.

EN_14_BOLETA_CAB DA_14_BolCod DA_14_EmpNom DA_14_EmpDir DA_14_EmpTel DA_14_EmpRep DA__14_RUC DA_14_CliCod DA_14_CliDir DA_14_CliNom DA_14_BolFecPag DA_14_ProCod DA_14_ProDes DA_14_DetCan DA_14_ProPreUni DA_14_DetImpTot

Primera forma normal (1FN) Recordemos que una base de datos se considera que est en 1FN si cada atributo (campo) de una tabla contiene un solo valor atmico (simple). Un atributo que contiene varios valores puede derivar en una prdida de datos y por lo tanto no nos interesa. Analizando el diseo inicial de la tabla BOLETA, observamos la existencia de mltiples valores para los atributos siguientes: Codigo_producto, descripcin, cantidad, precio unitario. Por lo tanto, observamos que no cumple la condicin de 1FN. La solucin consiste en crear una nueva tabla, que podemos llamar DETALLE_BOLETA, a la cual se trasladan los datos repetitivos, en nuestro caso los datos referentes a los artculos (codigo_producto, descripcin, cantidad, precio unitario). Aplicando esto, el diseo de la base de datos para las boletas de venta en 1FN sera:

18

EN_14_BOLETA_CAB DA_14_BolCod DA_14_EmpNom DA_14_EmpDir DA_14_EmpTel DA_14_EmpRep DA__14_RUC DA_14_CliCod DA_14_CliDir DA_14_BolFecPag DA_14_CliNom EN_14_DETALLE_B OLETA DA_14_BolCod DA_14_ProCod DA_14_ProDes DA_14_ProPreUni DA_14_DetImpTot DA_14_DetCan

Segunda forma normal (2FN) Una tabla se dice que est en segunda forma normal (2FN) si sucede que: Est en 1FN Cada atributo (campo) no clave depende de la clave completa, no de parte de ella.

EN_14_BOLETA_CAB DA_14_BolCod DA_14_EmpNom DA_14_EmpDir DA_14_EmpTel DA_14_EmpRep DA__14_RUC DA_14_CliCod DA_14_CliDir DA_14_BolFecPag DA_14_CliNom

EN_14_DETALLE_B OLETA DA_14_BolCod DA_14_ProCod DA_14_DetCan DA_14_DetImpTot

19

EN_14_PRODUCTO DA_14_ProCod DA_14_ProDes DA_14_ProPreUni

Tercera forma normal (3FN) Recordemos que una tabla se dice que est en tercera forma normal (3FN) si: Est en 2FN. Todos los atributos que no son claves deben ser mutuamente independientes, es decir, un atributo no debe depender de otro atributo no clave de su tabla

20

EN_14_EMPRESA DA__14_RUC DA_14_EmpNom DA_14_EmpDir DA_14_EmpTel DA_14_EmpRep

EN_14_CLIENTE DA_14_CliCod DA_14_CliNom DA_14_CliDir

EN_14_BOLETA_CAB DA_14_BolCod DA__14_RUC DA_14_CliCod DA_14_BolFecPag

EN_14_DETALLE_BOLETA DA_14_BolCod DA_14_ProCod DA_14_DetCan

EN_14_PRODUCTO DA_14_ProCod DA_14_ProDes DA_14_ProPreUni

21

NOTA DE PEDIDO Para identificar la nota de pedido, hemos considerado como clave primaria el cdigo de la nota de pedido y adems, hemos deducido que necesariamente una nota de pedido debe poseer todos esos campos EN_14_NOTA_PEDI DO DA_14_NotPedCod DA_14_CliCod DA_14_CliDir DA_14_CliNom DA_14_NotPedFec DA_14_ProCod DA_14_ProDes DA_14_DetCan DA_14_ProPreUni DA_14_DetPedImpTo t DA_14_EplCod DA_14_EplDir

Primera forma normal (1FN)

22

EN_14_NOTA_PEDI DO DA_14_NotPedCod DA_14_CliCod DA_14_CliDir DA_14_CliNom DA_14_NotPedFec DA_14_EplCod DA_14_EplDir

EN_14_DETALLE_P EDIDO DA_14_NotPedCod DA_14_ProCod DA_14_ProDes DA_14_ProPreUni DA_14_DetImpTot DA_14_DetCan

Segunda forma normal (2FN)

EN_14_NOTA_PEDI DO DA_14_NotPedCo d DA_14_CliCod DA_14_CliDir DA_14_CliNom DA_14_NotPedFec

EN_14_DETALLE_P EDIDO DA_14_NotPedCod DA_14_ProCod DA_14_DetPedCan DA_14_DetPedImpTo t

EN_14_PRODUCTO DA_14_ProCod DA_14_ProDes DA_14_ProPreUni

23

DA_14_EplCod DA_14_EplDir

Tercera forma normal (3FN)

EN_14_CLIENTE DA_14_CliCod DA_14_CliNom DA_14_CliDir

EN_14_EMPLEADO DA_14_EplCod DA_14_EplNom

EN_14_NOTA_PEDI DO DA_14_BolCod DA_14_NotPedCod DA_14_NotPedFec

EN_14_DETALLE_P EDIDO DA_14_NotPedCod DA_14_ProCod DA_14_DetPedCan DA_14_DetPedImpTo t

EN_14_PRODUCTO DA_14_ProCod DA_14_ProDes DA_14_ProPreUni

24