P. 1
Sistema de Control de Pasajeros

Sistema de Control de Pasajeros

|Views: 225|Likes:
Publicado porAlan Karl

More info:

Published by: Alan Karl on Jun 07, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

01/11/2013

pdf

text

original

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

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. contamos con un personal altamente calificado y modernas unidades.” L&G es una empresa dedicada al servicio de transporte y turismo de calidad. Además. Descripción de la empresa 1. como se encuentra actualmente. En un primer punto desarrollaremos una descripción de la empresa.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.A. 3 . y todos sus procesos son manuales. esto representa una gran desventaja con respecto a la competitividad de esta.

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

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 .

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

9 .

10 .

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

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

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. modificar o eliminar funcionalidades REQUISITOS DE AUDITORIA REQNF5 El sistema debe guardar información de cada usuario que ingrese al sistema (fecha. 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 . hora y usuario). de tal manera que la administración del sistema sea realizada por un administrador funcional del sistema. El sistema deberá contar con mecanismos que permitan el registro de actividades con identificación de los usuarios que los realizaron. 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. de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados afectando el código existente de la menor manera posible. El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades. 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.

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

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 .

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

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

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

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 .

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->