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

A. Descripción de la empresa 1. y todos sus procesos son manuales. la cual le ofrece a su distinguido público los siguientes servicios: -Traslados al aereopuerto. Descripción: La Empresa De Transportes Y Turismo “SEÑOR DE LOCUMBA TORUS S. esto representa una gran desventaja con respecto a la competitividad de esta. Además. como se encuentra actualmente. 3 .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. contamos con un personal altamente calificado y modernas unidades.” L&G es una empresa dedicada al servicio de transporte y turismo de calidad. En un primer punto desarrollaremos una descripción de la empresa.

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

Nota de Pedido 5 .

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

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 .

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

9 .

10 .

n Interfaz 1 0. Casi nula disponibilidad de los datos de los productos. Identificación y definición del problema Todos los procesos que se llevan a cabo son manuales. No tener un sistema de consultas de los productos que están disponibles o en proceso de fabricación. 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. así mismo el sistema desarrollado será capaz de emitir boletas. cuando estos cambian no hay una actualización inmediata de estos.. por lo tanto se presentan los siguientes problemas: • No se tiene un control del stock. Diagrama de clases Cliente 0. ya que se encuentran agrupados en fólderes.Definición del problema 1.n 0.n Mueble Administrador Comprobante Fecha Boleta ContratoPedido Proforma Pago 11 . ya sea en el taller de fabricación o en la tienda misma.. no se sabe en tiempo real si hay o no un producto disponible para la venta. proformas y contratos de pedidos. 2. No se tiene un control de precios...n Vendedor 1 1. Baja eficiencia en el manejo de los datos de ventas y otros procesos. se manejan archivos clásicos. • • • • En este proyecto nosotros nos basaremos en el control de las ventas.

modalidad. 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 será capaz de registrar a un nuevo cliente. servicios.3. etc. 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.) 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. Requerimientos No funcionales Priorida d Important e Critico Riesgo Significativ o Critico REQUISITO DE DESEMPEÑO REQNF1 Garantizar la confiabilidad. (productos. de no ser válida la verificación de la cuenta. Definición de requerimientos 3.2. 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. la seguridad y el desempeño del sistema informático a los diferentes usuarios.1. 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. de ventas y de stock. El sistema deberá mostrar un mensaje de valido una vez verificada la cuenta. se abre una sesión con el sistema. Si el usuario se autentifica correctamente. de vendedores. El sistema. deberá mostrar un mensaje de denegado.

aceptable y uniforme REQUISITO DE ESCALABILIDAD REQNF3 El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental. REQUISITO DE FIABILIDAD REQNF7 REQNF8 Los usuarios del sistema deben ingresar su login y password para ingresar al sistema. hora y usuario). modificar o eliminar funcionalidades REQUISITOS DE AUDITORIA REQNF5 El sistema debe guardar información de cada usuario que ingrese al sistema (fecha. El sistema deberá contar con mecanismos que permitan el registro de actividades con identificación de los usuarios que los realizaron. 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 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. de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados afectando el código existente de la menor manera posible.

3 documentado. 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. e o 14 .

Diccionario de datos 7 .

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 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 .

Modelo entidad Relación 7 .

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

un atributo no debe depender de otro atributo no clave de su tabla 20 .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.

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 .

hemos considerado como clave primaria el código de la nota de pedido y además.NOTA DE PEDIDO Para identificar la nota de pedido. 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