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 Introducción................................................................................................................ 2 Descripción de la empresa..........................................................................................3 Modelado del sistema................................................................................................. 8 Definición del problema............................................................................................11 Diccionario de datos..................................................................................................15 Modelo entidad Relación...........................................................................................17

Introducción
Como sabemos la tecnología está evolucionando muy rápidamente, 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, además será capaz de generar un Manifiesto de Pasajeros de la Empresa De Transportes Y Turismo “SEÑOR DE LOCUMBA TORUS S.A.”

2

” L&G es una empresa dedicada al servicio de transporte y turismo de calidad. y todos sus procesos son manuales. como se encuentra actualmente.A. 3 . En un primer punto desarrollaremos una descripción de la empresa. esto representa una gran desventaja con respecto a la competitividad de esta.Uno de los principales objetivos de este proyecto es la automatización de su control de pasajeros ya que esta empresa no cuenta con ningún sistema implementado. Descripción: La Empresa De Transportes Y Turismo “SEÑOR DE LOCUMBA TORUS S. la cual le ofrece a su distinguido público los siguientes servicios: -Traslados al aereopuerto. contamos con un personal altamente calificado y modernas unidades. Descripción de la empresa 1. Además.

-Excursiones. Todas nuestras unidades son 0km. con oportunidad de crecimiento para sus socios y colaboradores. con la mejor hospitalidad.-Citytours dentro de Lima. 2. Nuestros tours anivel nacional y local incluyen guía bilingüe. -Paseos y expresos. y estan muy bien equipadas para sus eguridad y comodidad. Boleta Actual 4 . puntualidad. responsabilidad. en un ambiente confortable. -Alquiler de autos: Toyota Corolla y Hyundai Accent. -Traslados de personal (Sector Empresarial). manteniendo la excelencia del servicio y la eficiencia de la empresa. Misión y visión de la empresa Misión: Proporcionar un servicio de transporte turístico confiable bajo los más estrictos parámetros de seguridad. -Alquiler de unidades: H1-Minivan. -Turismo a nivel nacional. Visión: Ser la mejor empresa de transporte turístico del país.

Nota de Pedido 5 .

Procedimientos de la empresa Diagrama de flujos Área Ventas 6 .2.

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 Confirmación y/o consulta Solicita datos del cliente Confirma y/o Determina el precio y Duración de fabricación 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 7 .

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.Modelado del sistema 1. Especificación de los casos de uso 8 .

9 .

10 .

proformas y contratos de pedidos. cuadernos de apuntes de teléfonos y no son compartidos como lo serían con el sistema que permitiría a los encargados de ventas tener acceso a los datos. Identificación y definición del problema Todos los procesos que se llevan a cabo son manuales.. Diagrama de clases Cliente 0.. 2. No tener un sistema de consultas de los productos que están disponibles o en proceso de fabricación. No se tiene un control de precios. • • • • En este proyecto nosotros nos basaremos en el control de las ventas. 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 fabricación o en la tienda misma. ya que se encuentran agrupados en fólderes.Definición del problema 1. cuando estos cambian no hay una actualización inmediata de estos.n 0.. Baja eficiencia en el manejo de los datos de ventas y otros procesos.n Mueble Administrador Comprobante Fecha Boleta ContratoPedido Proforma Pago 11 . se manejan archivos clásicos. así mismo el sistema desarrollado será capaz de emitir boletas.n Interfaz 1 0. Casi nula disponibilidad de los datos de los productos.n Vendedor 1 1.

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.3. El sistema deberá poder generar una boleta a partir de un pedido. etc. 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 . El sistema deberá poder generar vistas de la base de datos. de ventas y de stock. servicios.1. El sistema será capaz de verificar de identificar la autenticidad de los usuarios registrados antes de que puedan acceder. de vendedores. El sistema deberá mostrar un mensaje de valido una vez verificada la cuenta. se abre una sesión con el sistema. Definición de requerimientos 3. Si el usuario se autentifica correctamente. Requerimientos Funcionales REF REQ 1 REQ 2 REQ 3 REQ 4 REQ 5 REQ 6 REQ 7 REQ 8 REQ 9 SISTEMA Descripción de requerimientos. El sistema.2. (productos. El sistema será capaz de registrar a un nuevo cliente.) 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. deberá mostrar un mensaje de denegado. de no ser válida la verificación de la cuenta. la seguridad y el desempeño del sistema informático a los diferentes usuarios. Requerimientos No funcionales Priorida d Important e Critico Riesgo Significativ o Critico REQUISITO DE DESEMPEÑO REQNF1 Garantizar la confiabilidad. modalidad.

El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades. La seguridad del sistema debe estar regida por las Políticas de Seguridad Informática de la Comisión Intersectorial de Políticas y Gestión de la Información para la Administración Pública. 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 . de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados afectando el código existente de la menor manera posible. REQUISITO DE FIABILIDAD REQNF7 REQNF8 Los usuarios del sistema deben ingresar su login y password para ingresar al sistema.aceptable y uniforme REQUISITO DE ESCALABILIDAD REQNF3 El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental. modificar o eliminar funcionalidades REQUISITOS DE AUDITORIA REQNF5 El sistema debe guardar información de cada usuario que ingrese al sistema (fecha. hora y usuario). de tal manera que la administración del sistema sea realizada por un administrador funcional del sistema. RESQUISITO DE FLEXIBILIDAD El sistema debe ser diseñado y construido con los mayores niveles de flexibilidad en cuanto a la parametrización de los tipos de datos. El sistema deberá contar con mecanismos que permitan el registro de actividades con identificación de los usuarios que los realizaron.

cada uno de los componentesde software que forman parte de la solución propuesta deberán estar debidamente documentados tanto en el código fuente como en los manuales de administración y de usuario.3 documentado. e o 14 .

Diccionario de datos 7 .

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 k 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 .D C N R D D T S.

Modelo entidad Relación 7 .

observamos la existencia de múltiples valores para los atributos siguientes: Codigo_producto.NORMALIZACIÓN BOLETA DE VENTA Para identificar la Boleta de venta. hemos considerado como clave primaria el código de la Boleta y además. precio unitario). descripción. Aplicando esto. La solución consiste en crear una nueva tabla. en nuestro caso los datos referentes a los artículos (codigo_producto. observamos que no cumple la condición de 1FN. Un atributo que contiene varios valores puede derivar en una pérdida de datos y por lo tanto no nos interesa. a la cual se trasladan los datos repetitivos. precio unitario. cantidad. descripción. cantidad. que podemos llamar DETALLE_BOLETA. hemos deducido que necesariamente una boleta debe poseer todos esos campos. Por lo tanto. 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 atómico (simple). el diseño de la base de datos para las boletas de venta en 1FN sería: 18 . Analizando el diseño inicial de la tabla BOLETA.

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. un atributo no debe depender de otro atributo no clave de su tabla 20 . es decir. • Todos los atributos que no son claves deben ser mutuamente independientes.

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 código de la nota de pedido y además. 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 .

Sign up to vote on this title
UsefulNot useful