Facultad de Ingeniería de Sistemas - Repositorio UTP ...repositorio.utp.edu.pe/bitstream/UTP/258/1/0620421.pdf · 1.2.4 Estado de Arte ... FIGURA Nº 2 Fases de la Metodología RUP

Facultad de Ingeniería de Sistemas

y Electrónica Carrera Profesional de Ingeniería de Sistemas

Informe de Suficiencia Profesional para optar el

Título Profesional de Ingeniero de Sistemas e

Informática

“SISTEMA DE CAJA Y CONTROL DE

PAGOS DE LA EMPRESA DE

TRANSPORTES TREINTITRES”

Bachiller:

SOTO RONDÓN, JOSÉ MARTÍN

Lima – Perú

2016

DEDICATORIA:

A DIOS POR SUS BENDICIONES

A mis padres, mi Esposa e hijas

Por su apoyo y su comprensión.

AGRADECIMIENTO:

A mis amigos por su apoyo en el

presente informe

A mis sobrinos por sus Aportes

Académicos

INDICE

CAPÍTULO 1 ...................................................................................................... 1

ASPECTOS GENERALES ................................................................................ 1

1.1 Definición del Problema ........................................................................ 1

.................................................................. 1 1.1.1 Descripción del Problema

................................................................. 3 1.1.2 Formulación del Problema

1.2 Definición de Objetivos .......................................................................... 3

Objetivo General ................................................................................ 3 1.2.1

1.2.2 Objetivos Específicos ......................................................................... 4

1.2.3 Alcances y Limitaciones ..................................................................... 4

1.2.3.1 Alcances. ........................................................................................... 4

1.2.3.2 Limitaciones ....................................................................................... 4

1.2.3.3 Justificación ....................................................................................... 5

1.2.4 Estado de Arte ................................................................................... 5

CAPÍTULO 2 ...................................................................................................... 6

MARCO TEORICO ............................................................................................ 6

2.1 PROGRAMACION ESTRUCTURADA .................................................. 6

2.1.1 Diagramas de Flujo de Datos ............................................................. 7

2.1.2 Diccionario de Datos .......................................................................... 7

2.1.3 Diagrama Entidad- Relación .............................................................. 7

2.1.4 Componentes de un DFD .................................................................. 7

2.2 PROGRAMACION ORIENTADA A OBJETOS ..................................... 7

....................................................... 8 2.3 DIAGRAMAS DE CASOS DE USO

2.3.1 Descripción de los Casos de Uso. ..................................................... 8

2.3.2 Construcción de Casos de Uso .......................................................... 9

................................................................................ 10 2.4 Metodología RUP

2.4.1 Especificación de los Procesos ........................................................ 10

CAPITULO 3 .................................................................................................... 12

DESARROLLO ................................................................................................ 12

3.1 FASE INICIO ....................................................................................... 12

3.1.1 Situación Actual ............................................................................... 13

3.1.1.1 Levantamiento de Información...................................................... 13

3.1.2 Análisis de Requerimiento y necesidad por Actores ........................ 16

3.2 Elaboración del Negocio. .................................................................... 16

3.2.1 Modelo del Dominio ......................................................................... 18

3.2.2 Análisis de los Requerimientos ........................................................ 18

3.2.3 ANALISIS DE PAGO DE LOS RUBROS ......................................... 19

3.3 SISTEMA PROPUESTO ..................................................................... 20

3.3.1 Usuarios ........................................................................................... 20

3.3.2 casos de uso .................................................................................... 20

3.3.2.1 De los Requerimientos ................................................................. 20

3.4 DISEÑO DE BASE DE DATOS ........................................................... 44

3.4.1 DESCRIPCION DE ENTIDADES ..................................................... 44

3.4.2 Diagrama Entidad – Relación .......................................................... 47

3.4.3 Requisitos Funcionales .................................................................... 48

3.4.4 Requisitos No Funcionales .............................................................. 50

3.5 Implementación del Sistema ............................................................... 51

3.5.1 Aplicación Centralizada.................................................................... 51

3.5.2 Plataforma Tecnológica de la PC ..................................................... 51

3.5.2.1 Sistema Operativo ........................................................................ 51

3.5.2.2 Gestor de Base de Datos ............................................................. 51

3.5.2.3 Antivirus ........................................................................................ 51

CAPITULO 4 .................................................................................................... 52

RESULTADOS ................................................................................................. 52

4.1 Resultado Operativo............................................................................ 52

4.2 Presupuesto ........................................................................................ 52

4.3 Cronograma ........................................................................................ 54

CONCLUSIONES ............................................................................................ 57

BIBLIOGRAFIA ............................................................................................... 58

ANEXOS .......................................................................................................... 59

Anexo A ........................................................................................................ 60

Análisis de la entrega de recibo en Forma Manual Comparado ................... 60

Con la tabla de Recibos del Proyecto Propuesto .......................................... 60

ANEXO B ...................................................................................................... 63

DIAGRAMA DE COMPONENTE Y ............................................................... 63

OTROS CASOS DE USO ............................................................................ 63

INDICE DE FIGURAS

FIGURA Nº 1 Árbol de Problemas 2

FIGURA Nº 2 Fases de la Metodología RUP 10

FIGURA Nº 3 Diagrama de Contexto 13 FIGURA Nº 4 Diagrama de Actividades del Sistema Actual 14 FIGURA Nº 5 Diagrama De Flujo Del Sistema Actual 15 FIGURA Nº 6 PROCESO 1: Pagar Rubros 15

FIGURA Nº 7 Modelo de Negocio del Concesionario 16

FIGURA Nº 8 Modelo de Negocio del Asistente De Caja 17

FIGURA Nº 9 Modelo De Negocio De La Gerencia 17

FIGURA Nº 10 Modelo Del Dominio 18

FIGURA Nº 11 Caso De Uso Del Sistema De Caja 20 FIGURA Nº 12cobro Al Concesionario 21 FIGURA Nº 13 Diagrama de Actividades Cobro al Concesionario 21 FIGURA Nº 14 Diagrama de Secuencia Cobro al Concesionario 22 FIGURA Nº 15 Reporte de Saldos del Concesionario 23 FIGURA Nº 16 Diagrama de Actividades Reporte de Saldos

Del Concesionario 24 FIGURA Nº 17 Diagrama de Secuencia Reporte de Saldos

Del Concesionario 25 FIGURA Nº 18 Reporte De Conciliación de Caja y Efectivo Diario 26 FIGURA Nº 19 Diagrama de Actividades Conciliación De Caja y Efectivo 27 FIGURA Nº 20 Diagrama de Secuencia Conciliación de Caja y Efectivo 28 FIGURA Nº 21 REPORTE DE PAGOS POR CONCESIONARIO 29 FIGURA Nº 22 Diagrama de Actividades Reporte de Pagos

por Concesionario 30 FIGURA Nº 23 Ingreso de Deudas 31 FIGURA Nº 24 Diagrama de Actividad Ingreso de Deudas 31 FIGURA Nº 25 Diagrama de Secuencia Ingreso de Deudas 32 FIGURA Nº 26 Listado de Saldos Por Rubros 33 FIGURA Nº 27 Diagrama de Actividad Listado de Saldos Por Rubros 33 FIGURA Nº 28 Reporte Cuadre de Caja por Día 34 FIGURA Nº 29 Diagrama de Actividades Cuadre de Caja por Día 35 FIGURA Nº 30 Diagrama de Secuencia Cuadre de Caja por Día 36 FIGURA Nº 31 Reporte Ingresos por Mes 37 FIGURA Nº 32 Diagrama de Actividades Ingresos por Mes 38 FIGURA Nº 33 Diagrama de Secuencia de Ingresos por Mes 39 FIGURA Nº 34 Ingreso de Nuevo Concesionario 40 FIGURA Nº 35 Diagrama de Actividades Nuevo Concesionario 41 FIGURA Nº 36 Diagrama de Secuencia Nuevo Concesionario 42 FIGURA Nº 37 Diagrama de Entidad – Relación 47

FIGURA Nº 38 Modulo de Archivos 48

FIGURA Nº 39 Modulo Movimientos 48

FIGURA Nº 40 Modulo Consultas 49

FIGURA Nº 41 Modulo Reportes 49

FIGURA Nº 42 Modulo Utilitarios 50

FIGURA Nº 43 Tabla Recibo 62

FIGURA Nº 44 Diagrama de Componentes 64

INDICE DE TABLAS

Tabla No.1: Árbol de Problemas 2

Tabla Nº 2: Especificaciones De Pago por Concesionario 23

Tabla Nº 3 Reporte de Saldos Del Concesionario 26

Tabla Nº 4 Reporte de Conciliación De Caja y Efectivo 38

Tabla Nº 5 Reporte de Pagos Por Concesionario 30

Tabla Nº 6 Ingreso de Deudas 32

Tabla Nº 7 Listado de Saldos por Rubros 34

Tabla Nº 8 Reporte de Cuadre de Caja Por Día 37

Tabla Nº 9 Reporte De Ingresos Mensuales 40

Tabla Nº 10 Ingresar Nuevo Concesionario 43

Tabla Nº 11 Benchmarking: Comparación De Software 43

Tabla Nº 12 Flujo de Caja 52

Tabla Nº 13 Cronograma 54

TABLA Nº 14 Cuadro De Frecuenc. y Toma De Muestra De Padrón 61

Tabla Nº 15 Espec. Ingreso De Concesionario, Chofer O Cobrador 65

Tabla Nº 16 Especificaciones Ingreso De Unidades 65

Tabla Nº 17 Especificaciones Ingreso De Rubros 66

Tabla Nº 18 Especificaciones Ingreso De Asistentes De Caja 66

Tabla Nº 19 Especificaciones Registro De Pago Del Recibo 67

Tabla Nº 20 Especificaciones Registro De Pago de la Boleta 67

Tabla Nº 21 Espec. Reporte de Cuadre De Caja al Dpto. Economía. 68

Tabla Nº 22 Espec. Reporte de Ingresos por rubros a Gerencia 68

Tabla Nº 23 Especificaciones Consulta De Saldos 69

Tabla Nº 24 Especificaciones Consulta De Deudas 69

Tabla Nº 25 Especificaciones Copia De Seguridad – Backup 70

Tabla Nº 26 Especificaciones Restaurar Copia de Seguridad Backup 70

1

CAPÍTULO 1

ASPECTOS GENERALES

Las Empresas de Transporte se encuentran en tiempos de cambios, debido a

la competencia de nuevos servicios modernos y rápidos. Esto conlleva no solo

a mejorar el servicio, sino también a tener un mejor control administrativo de los

concesionarios, así como a ordenar la Empresa Administrativa y

Operativamente, usando las TIC`S como herramientas de orden y control de

los servicios administrativos.

1.1 Definición del Problema

1.1.1 Descripción del Problema

La Empresa de Transportes TREINTITRES S.A, dedicada al transporte de pasajeros y venta al por menor de combustible como actividad Secundaria. La Empresa se encuentra ubicada en Av. Canta Callao Mz. A, Lt. 1 Urb. Los Portales de Santa Rita – San Martin de Porres con una extensión de terreno aprox. de 3,000 m2, cuya principal actividad es el Transporte de Pasajeros. Tiene una trayectoria de 25 años en el mercado de Transporte, operan cerca de 60 unidades, las que salen de sus instalaciones diariamente, estas realizan pagos de diferentes rubros tales como: salida, boletaje, multas y otros, Diariamente 10,000 usuarios utilizan este servicio, La Empresa ha realizado mejoras en infraestructura, aumentando su flota en 80 unidades. Con la finalidad de identificar el problema central se ha utilizado la técnica del árbol de problemas. En el gráfico que se muestra a continuación se puede apreciar las causas y efectos del problema central.

2

Figura N° 1 Árbol de Problemas

FUENTE: ELABORACION PROPIA

Tabla N° 1

Árbol de Problemas

Descripción del Problema : Deficiencia en el Control de Pagos de los Concesionarios de la Empresa de Transportes Treintitres

Recibos Manuales

y

Mayor Número de Empleados

Mayor Tiempo de Espera

Informes a destiempo

Mayor Gasto Fijo

Mala Toma de Decisiones

FUENTE: ELABORACIÓN PROPIA.

3

Como se puede apreciar en la Figura No. 1: Árbol de Problemas de la Empresa de Transportes Treintitres, las causas del problema son:

1. Recibos manuales: al momento de realizar el pago los Concesionarios, se

emiten recibos de forma manual.

2. Mayor número de Empleados: Hasta cinco personas para emitir Recibos

Manualmente, cada emisión demoraba entre 3,5 a 4 minutos.

3. Estas causas generan efectos los cuales son:

4. Mayor Tiempo de espera: En relación a la emisión de cada recibo

5. Mayor gasto fijo: Al tener mayor número de empleados genera un

incremento en los gastos de la planilla de la empresa.

6. Mala toma de decisiones: Tener reportes a destiempo y mal elaborados

estos llevan al error.

7. Almacenes amplios y mayores estantes: Esto debido a que se guardan los

recibos físicos para el Historial

1.1.2 Formulación del Problema

El registro de los pagos de manera manual ha creado una “Deficiencia

en el Control de Pagos de los Concesionarios de la empresa de

Transportes Treintitres”.

1.2 Definición de Objetivos

Objetivo General1.2.1

Crear un Sistema de Información para el Control de Pagos de la

Empresa de Transportes TREINTITRES, usando Metodología

RUP.

4

1.2.2 Objetivos Específicos Análisis de Requerimiento y necesidad por Actores.

Analizar las reglas de negocio requeridas para el desarrollo de los Pagos de los rubros.

Diseñar las interfaces y crear la Base de Datos que permitan la interacción con el usuario con la aplicación de la manera más sencilla posible.

Realizar una fase de implementación y pruebas con su respectiva documentación hasta el nivel de Prueba, para validar y verificar el correcto funcionamiento del Sistema de Información.

1.2.3 Alcances y Limitaciones

1.2.3.1 Alcances.

El Sistema de Información a desarrollar permitirá controlar los rubros de pagos que realiza el concesionario.

La emisión de los reportes permitirá tener un mejor control de los pagos y los reportes necesarios para la mejor toma de decisiones.

El sistema a desarrollar será un manejador de base de datos Visual FOX PRO.

1.2.3.2 Limitaciones

El Sistema solo controlará los pagos realizados por los concesionarios.

El sistema a desarrollar solo es para el área de caja, no es para el Departamento de Operaciones o para otro departamento de la Empresa.

El sistema se desarrollará a nivel monousuario. Se respetará el número de padrón con que están

empadronados los concesionarios. La Empresa cuenta con Licencia FoxPro 6.0 y Licencia XP

para un usuario. Solo ingresaran al padrón los vehículos que estén

autorizados por la Dirección General de Transporte Urbano (DGTU).

5

1.2.3.3 Justificación

El desarrollo del Sistema se Justifica por lo siguiente:

Ordenar el área administrativa se tiene un mejor control de los pagos, así como de los concesionarios.

Usando la metodología RUP y las buenas prácticas de programación, se podrá realizar un producto que nos permita crecer y analizar otras mejoras en la empresa.

1.2.4 Estado de Arte Sistemas anteriores o parecidos se han realizado de forma mecánica, en otros casos han utilizado como en el caso de Colombia sistemas para grandes empresas haciendo caro el sistema y mantenimiento a continuación se presentan alguno de esos sistemas. El siguiente es un sistema de gestión realizada por la municipalidad de Madrid y de cómo la tecnología puede ayudar a tener un sistema eficiente en el transporte público y alcances en el sistema de pagos. EMPRESA MUNICIPAL DE TRANSPORTE DE MADRID, OPTIMIZAR LA GESTIÓN DEL TRANSPORTE PÚBLICO URBANO UN PASO MAS HACIA LA SOSTENIBILIDAD (http://www.ecourbano.es/imag/08T2%20PROYECTO%20E%20BUS%20emt.pdf) Concluye: El uso de las tarjetas con códigos de barras acelera el pago en la salida de unidades. Otro de los sistemas acerca de control de pagos es el desarrollado por FEDESARROLLO que realiza una integración de sistemas para una mejor gestión en el control de pagos de la salida de buses. (http://www.fedesarrollo.org.co/wp-content/uploads/2011/08/La-integraci%C3%B3n-de-los-sistemas-de-transporte-urbano-en-Colombia-Findeter.pdf) Concluye: Crear un fondo de contingencia en el cobro de salida de unidades del terminal para la mejora de unidades o compras a futuro de las mismas para la mejora en el servicio.

http://www.ecourbano.es/imag/08T2%20PROYECTO%20E%20BUS%20emt.pdf

http://www.ecourbano.es/imag/08T2%20PROYECTO%20E%20BUS%20emt.pdf

http://www.fedesarrollo.org.co/wp-content/uploads/2011/08/La-integraci%C3%B3n-de-los-sistemas-de-transporte-urbano-en-Colombia-Findeter.pdf



6

CAPÍTULO 2

MARCO TEORICO

2.1 PROGRAMACION ESTRUCTURADA

La programación estructurada permite a los programadores escribir códigos sin necesidad de conocer los detalles de la implementación de funciones de una librería y objetos respectivamente. Su implementación permanece oculta a los programadores, liberándoles de los condicionantes que esto imponía. Un Programador necesita saber cómo se representan internamente los datos. Tan solo necesitara saber cómo iniciar, mover o validar un determinado movimiento, en el caso de procedimientos o funciones necesarias para el desarrollo de aplicaciones de control y movimiento. El diseño requiere la máxima importancia que no tenía en la programación tradicional. Lo realmente complicado de la programación es encontrar los modelos o patrones conceptuales correctos para el problema y no la implementación de los mismos. El diseño resulta importante lo que no tenía la programación tradicional. El análisis de sistemas conduce al desarrollo de especificaciones para nuevos sistemas o para efectuar modificaciones o actualizaciones a los ya existentes. Yourdon, E. (1993)

El análisis estructurado la palabra estructura significa que:

El método intenta estructurar el proceso de determinación de los requerimientos comenzando con la documentación del sistema existente.

El proceso está organizado de tal forma que intenta incluir todos los detalles relevantes que describe al sistema en uso.

Se puede verificar cuando se omite detalles importantes.

Los requerimientos serán identificados será similar entre varios analistas e incluirá las mejoras, soluciones y estrategias para el desarrollo de sistemas.

Los documentos de trabajo generados para documentar los sistemas existentes propuestos son dispositivos de comunicación eficientes.

El análisis estructurado hace uso de:

Símbolos gráficos (Diagramas de Flujo de Datos).

Diccionario de datos. Yourdon, E. (1993).

7

2.1.1 Diagramas de Flujo de Datos Representan los procesos o funciones que debe llevar a cabo un sistema en distintos niveles de abstracción y los datos que fluyen entre las funciones. Los procesos más complejos se descomponen en nuevos diagramas hasta llegar a procesos sencillos. Yourdon, E. (1993).

2.1.2 Diccionario de Datos E s el conjunto de las definiciones de todos los datos que aparecen en el DFD, ya almacenados o indicados en los diferentes flujos de datos. El diccionario de datos se crea a la vez que los DFD`S durante el proceso de análisis del sistema. Yourdon, E. (1993).

2.1.3 Diagrama Entidad- Relación Se centra en los datos del sistema modelado, brindando una visión unificada de los mismos. Los elementos principales de este modelo son las entidades y las relaciones a las que se suman los atributos, de ambas. Yourdon, E. (1993).

2.1.4 Componentes de un DFD

Procesos, funciones o Transformaciones: son los

componentes funcionales del sistema.

Almacenes: representan datos almacenados o en reposo.

Entidades Externas: Representan la fuente y/o el destino de la

información del sistema.

Flujos de Datos: representan los datos que fluye entre las

funciones o procesos. Yourdon, E. (1993).

2.2 PROGRAMACION ORIENTADA A OBJETOS La programación orientada a objetos consiste en intentar superar la complejidad a los problemas del mundo real gracias a la abstracción de nuestro conocimiento sobre tales problemas y su encapsulación dentro de módulos y objetos respectivamente. Se utiliza el término encapsular porque los objetos y los módulos pueden verse como "cápsulas" a modo de barrera conceptual que separa un conjunto de valores y operaciones, que poseen un substrato conceptual idéntico, del resto del sistema.

8

Así, tanto objetos como módulos tienen dos partes bien diferenciadas: la declaración y la implementación. La declaración o interfaz es de dominio público, conocido por las demás partes del programa. En la implementación se codifican los elementos necesarios para responder a lo especificado en la declaración. Esta separación permite que cada objeto definido en nuestro sistema pueda ocultar su implementación y hacer pública su interfaz de comunicación. La ocultación de la información permite aislar una parte del programa del resto, y que el código de una parte sea revisado o extendido sin afectar a la integridad de las demás partes. En este sentido, es interesante resaltar que la opción de encapsular datos y operaciones en librerías y objetos facilita enormemente que se puedan utilizar en una aplicación ajena. Se puede, por tanto, empezar a hablar de una relación consumidor/ proveedor de código. La programación convencional daba más importancia a la relación entre el programador y su código, que a la relación entre el código y las aplicaciones en que se usa. GOYANES L. (1996)

2.3 DIAGRAMAS DE CASOS DE USO

Son técnicas para especificar el comportamiento de un sistema: “Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.” Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software. Por ejemplo, un sistema de compras, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso de uso ingresando pedido. Yourdon, E. (1993)

2.3.1 Descripción de los Casos de Uso. - Un caso de uso describe una funcionalidad más una

interacción entre un actor y un sistema en forma de secuencia

de acciones.

- La descripción se centra en lo que debe hacerse, no en la

manera de hacerlo.

- Debe evitarse expresiones imprecisas. Se busca sencillez y

claridad.

- Puede utilizarse un lenguaje estructurado para representar

secuencia, repeticiones y situaciones opcionales.

9

- La descripción debe contener:

- Inicio del caso de uso.

- Fin del caso de uso.

- Interacción entre el caso de uso y los actores.

- Intercambios de datos.

- Cronología y origen de los datos. Smuller J.(1999)

2.3.2 Construcción de Casos de Uso Es un proceso iterativo. Se van descubriendo los

escenarios, desde el punto de vista del usuario, es decir los ACTORES.

Para detectar los casos de uso es conveniente hacer las siguientes preguntas:

– ¿Cuáles son las principales tareas de cada actor?

– ¿Escribe/lee/modifica el actor alguna información del sistema?

– ¿Informa el actor al sistema de los cambios externos?

– ¿Desea el actor ser informado de cambios no esperados?

Es un proceso iterativo, en el que pueden utilizarse

distintas técnicas de observación o de entrevista

estructurada (para describir los escenarios

potenciales desde el punto de vista del usuario).

Los casos de uso no pueden ser demasiado

pequeños, ya que deben aportar algún valor al actor.

En el momento de identificar los actores es

conveniente distinguir entre:

– actores principales (que son los que emplean

directamente el sistema llevando a cabo las tareas más

importantes)

– actores secundarios (existen para que los principales

puedan utilizar el sistema).

La estructura del sistema debe decidirse

teniendo en cuenta a los actores principales.

Smuller J.(1999)

10

2.4Metodología RUP

Es guía para implementar buenas y ágiles prácticas de desarrollo, las cuales se adaptan a la empresa El proceso se divide en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. Carrillo A. (2004)

Figura N° 2

FASES DE LA METODOLOGIA RUP

FUENTE: Carrillo A. (2004)

2.4.1 Especificación de los Procesos

INICIO

Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se desarrolla, un plan de negocio para determinar que recursos deben ser asignados al proyecto.

ELABORACION

El propósito de la fase de elaboración es analizar el dominio del problema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos.

11

En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos de Uso críticos identificados en la fase de inicio. También debe demostrarse que se han evitado los riesgos más graves.

CONSTRUCCION

En esta fase es alcanzar la parte operacional del producto de forma incremental a través de las sucesivas iteraciones. Durante esta fase todos los componentes, características y requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una versión aceptable del producto. Deben incluirse los requerimientos de los actores.

IMPLEMENTACION

Es poner el producto en manos de los usuarios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuración, instalación y facilidad de uso del producto. Es bueno y necesario el desarrollo de un manual de usuario, esto permitirá un mejor uso del sistema y que está a la vez se actualice conforme se actualiza el sistema.

12

CAPITULO 3

DESARROLLO

3.1 FASE INICIO En esta fase se detalla la fase inicial del Proyecto.

Plan del Proyecto

Disciplinas / Artefactos generados o modificados Comienzo Aprobación

Modelado del Negocio

Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio

Semana 1

Semana 3

Requerimientos

Modelo de Casos de Uso Semana 3 siguiente fase

Especificación de Casos de Uso Semana 3 siguiente fase

Especificaciones Adicionales Semana 3 siguiente fase

Análisis / Diseño

Modelo de Análisis / Diseño Semana 4 siguiente fase

Modelo de Datos Semana 4 siguiente fase

Implementación

Prototipos de Interfaces de Usuario Semana 5 siguiente fase

Pruebas

Casos de Pruebas Funcionales Semana 6 siguiente fase

Gestión del proyecto

Plan de Desarrollo del Software en su versión 1.0 y planes de las Iteraciones

Semana 1 Semana 3

28/10 – 3/11

13

3.1.1 Situación Actual

3.1.1.1 Levantamiento de Información Las técnicas empleadas en la Investigación han sido las siguientes: A. Recolección de Información. Se realizaron los siguientes:

a) La Observación b) Entrevistas c) Encuestas

FIGURA Nº 3

DIAGRAMA DE CONTEXTO

SISTEMA DE CAJA

GERENCIA

Concesionario

No.

PADRON

RUBROS A

PAGAR

PAGO

INFORME DIARIO POR

RUBROS

RECIBO DE

PAGO

DPTO. ECONOMIA

INFORME DE

CUADRE

DE CAJA

EFECTIVO TOTAL RECIBIDO

DPTO DE OPERACIONES

INF. SALIDA DE UNIDADES

INF. DE NUEVAS UNIDADES

Concesionario

Fuente: Elaboración Propia

14

Figura Nº 4 DIAGRAMA DE ACTIVIDADES DEL SISTEMA MANUAL

inicio

Numero de padron

existe

Ingresar rubros a pagar

Dpto de operaciones

Ingresar nuevo concesionario y

numero de padron

PAGAR RUBROS

PAGOCOMPLETO

EMITIR RECIBO

FIN DE COBRO


15

FIGURA Nº 5

DIAGRAMA DE FLUJO DEL SISTEMA ACTUAL

Concesio-nario

PAGAR

RUBROS

1

ELABORAR

INFORME

DE

INGRESOS

2

GERENCIA

INFORME

CUADRE DE

CAJA

DIARIO

INFORMACION

DE LOS

RUBROS

TRANSACCION

EN EFECTIVO

RUBROS A

PAGAR

Nº PADRON

PAGO

D1 PADRON

SISTEMA DPTO. DE

OPERACIONES

INFORME SALIDA DE

UNIDADES

DPTO ECONOMIA

EFECTIVO

TOTAL

RECIBIDO

INFORME DE INGRESOS

POR RUBROS

AGREGAR

NUEVA

UNIDAD,

CHOFER O

COBRADOR

3INFORME

NUEVAS UNIDADES,

CHOFER O COBRADOR

REGISTRO DE

LA UNIDAD

Concesio-narioFOTOCHEK

RECIBO DE PAGO

D2 RUBROS


FIGURA Nº 6

PROCESO 1: PAGAR RUBROS

ConcesionarioBusqueda del padron

PADRON

CONSULTA

SALIDA

ANTERIOR

DEUDA

HACER RECIBO

RUBROS A PAGARCONCESIONARIO

INFORME

DE

INGRESOS

- EXCEL

Nº PADRON

Nº PADRON

Nº PADRON + DEUDA

Nº PADRON Y MONTO

RECIBO

TIEMPO DE EMISION DE RECIBO 3,5 MIN PROM.

PROCESO DE PAGAR RUBROS Y EMISION DEL RECIBO11


Tiempo de demora del Proceso de emisión recibo forma manual es de 3,5 min. (*) (*) Muestra tomada in situ, en el horario de 6:00 a 9:00 am, Los resultados de

pago se muestra en el Anexo A (según frecuencia de salida)

16

3.1.2 Análisis de Requerimiento y necesidad por Actores Concesionario

Recibo de Caja al Detalle Reporte de saldo del concesionario. Asistente de Caja Reporte de ingresos Diarios Reporte de Pagos Por Concesionario Listado de Concesionarios Reporte de Saldos por Pagar. Director de Economía Reporte de Cuadre de Caja Por Día Reporte Detallado por Rubros. Gerencia Reporte de Ingresos por Mes Reporte al Detalle por Rubros

3.2 Elaboración del Negocio. El modelado del negocio se basa en dos diagramas principales, el modelo de casos de uso del negocio, el modelo del dominio.

FIGURA Nº 7

MODELO DE NEGOCIO DEL CONCESIONARIO

Concesionario

PAGAR RUBROS


http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html#cu_negocio

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html#dominio

17

FIGURA Nº 8

MODELO DE NEGOCIO DEL ASISTENTE DE CAJA

ASISTENTE DE CAJA

COBRAR RUBROS

CONCILIAR CAJA

FUENTE: ELABORACION PROPIA

FIGURA Nº 9

MODELO DE NEGOCIO DE LA GERENCIA

GERENCIA

SOLICITAR INFORMEDE

CAJA

LISTAR DEUDORES


18

3.2.1 Modelo del Dominio FIGURA Nº 10

MODELO DEL DOMINIO


3.2.2 Análisis de los Requerimientos Requerimientos del Producto: Agilizar y controlar los procesos de cobros de los Concesionarios

Requerimientos Organizacionales: Política Empresarial: Todo chofer debe cumplir con las normas de la Dirección General de Transporte Urbano-DGTU CHOFER: Brevete según Categoría para el manejo de la unidad. Cobrador: Sin antecedentes Penales, con documentos en regla. Los Trabajadores (Chofer/Cobrador), deben salir a trabajar con su debida indumentaria e identificación. Tanto chofer como cobrador deben pasar las charlas dictadas por la DGTU Asimismo los vehículos deben cumplir con las normas que emite la DGTU, para evitar falta o papeletas que afecten al vehículo, trabajadores, y empresa etc.

19

REQUERIMIENTOS EXTERNOS: Normas DE LA DGTU Licencia de Ruta otorgada por la DGTU.

3.2.3 ANALISIS DE PAGO DE LOS RUBROS A continuación se detallan los pagos que realizan los concesionarios al salir del terminal Cotización(salida) Tarifario Cochera Voladas - no se cumple la frecuencia, según controlador. OTROS UNIFORMES FOTOCHECK STICKERS DIAGRAMA DE RUTA BOLETAJE – BOLETO ADULTO, MEDIO, ESCOLAR BOTIQUIN EXTINGUIDOR CINTURON DE SEGURIDAD OTROS

RUBROS QUE COBRA LA EMPRESA Para un mejor análisis estos rubros se han dividido en dos grupos uno Administrativo y otro Operativo: Los rubros del área administrativa son recibos simples de control interno en la Empresa.

ADMINISTRATIVOS - Cotización(salida) - Tarifario - Cochera - Voladas - no se cumple la frecuencia, según controlador. - OTROS

Los rubros del área operativa se emiten boleta de venta

OPERATIVOS o UNIFORMES o FOTOCHECK o STICKERS DIAGRAMA DE RUTA o BOLETAJE – BOLETO ADULTO, MEDIO, ESCOLAR o BOTIQUIN o EXTINGUIDOR o CINTURON DE SEGURIDAD o OTROS

20

3.3 SISTEMA PROPUESTO

3.3.1 Usuarios Asistente de Caja (AC): Es el responsable de los cobros a los concesionarios

Gerente (G): encargado de Supervisar y Controlar los ingresos realizados por los concesionarios durante el día o mes

Director de Economía (DE): Responsable de la conciliación diaria de los pagos realizados por los concesionarios, realiza el cuadre de caja con el Asistente de caja.

3.3.2 Casos de Uso Se busca ir modelando los procesos que se quiere para el sistema.

FIGURA Nº 11 Caso De Uso Del Sistema De Caja

CREAR RECIBO

EMITIR RECIBO

REPORTE DE CUADRE DE CAJAFINAL DEL DIA


3.3.2.1 De los Requerimientos A continuación se detallan algunos casos de uso de los actores según su requerimiento. Otros casos de uso se muestran en el Anexo III.

Concesionario: Responsable de los pagos de salida de las unidades y/u otros rubros.

21

FIGURA Nº 12 Cobro Al Concesionario

Concesionario

Pago Salidade Unidad

EMITIR RECIBOAL DETALLE

Asistente de Caja

PAGAR

<<incluir>>

REGISTRAR PAGO


FIGURA Nº 13 DIAGRAMA DE ACTIVIDADES COBRO AL CONCESINARIO

inicio

Numero de padronDEL

CONCESIONARIO

existe

Ingresar rubros a pagar

VERIFICACION EN EL DPTO DE

OPERACIONES


numero de padron

PAGAR RECIBO

COMPLETO

EMITIR RECIBO

FIN DE COBRO

1

1


22

FIGURA 14

DIAGRAMA DE SECUENCIA: COBRO AL CONCESIONARIO

COBRO AL CONCESIONARIO

CONCESIONARIO

REGISTRAR

REGISTRAR PAGO

NO

SI

ASISTENTE DE CAJA SISTEMA

PAGAR POR

SALIDA DE UNIDAD

PAGO POR UNIFORME

PAGO VARIOS

PAGO COMPLETO

REGISTRAR EN

SISTEMA

IMPRIMIR RECIBO

NO

SI

SI

SI


23

Tabla Nº 2

ESPECIFICACIONES DE PAGO POR CONCESIONARIO

PAGO POR CONCESIONARIO

Objetivos Aso.

Actores Asistente de Caja, Concesionario

Requisitos Aso.

Descripción

Precondición El Asistente de caja debe tener código de usuario y clave. El concesionario debe estar registrado en el sistema.

Paso Acción

SECUENCIA 1 1. Ingreso al Módulo de Movimientos.

NORMAL 2 2. Ingresar a la Opción de Ingresos

3

3. Ingresa código del concesionario

4. Ingresa los rubros por cobrar.

5. Emitir recibo de pago al detalle.

POSTCON-DICION * Los datos de los rubros son validados por el sistema.


FIGURA Nº 15 REPORTE DE SALDOS DEL CONCESIONARIO

ASISTENTE DE CAJA

REPORTE DE SALDOSCONCESIONARIO

EMITIR REPORTE DELCONCESIONARIO

CONCESIONARIO


24

FIGURA Nº 16 DIAGRAMA DE ACTIVIDADES REPORTE DE SALDOS DEL

CONCESIONARIO

inicio

existeVERIFICACION EN EL

DPTO DE OPERACIONES


numero de padron

REPORTE DE SALDOS PREVIO

EMITIR REPORTE

FIN DE REPORTE

INGRESAR NUMERO DE

PADRON

1

1


25

FIGURA N° 17 DIAGRAMA DE SECUENCIA: REPORTE DE SALDOS DEL

CONCESIONARIO

REPORTE DE SALDOS DEL CONCESIONARIO

CONCESIONARIO

INGRESA NUMERO PADRON


IMPRIMIR

SOLICITA REPORTEDE SALDO

PREPARADATOS

REPORTE VISUALIZA

DO

NO

REPORTEEMITIDO


26

Tabla Nº 3



Objetivos Asoc.

Actores Concesionario, Asistente de Caja

Requisitos Aso.

Descripción

Precondición

El Asistente de caja debe tener código de usuario y clave. Se deben de haber registrado pagos de concesionarios. Haber ingresado

Paso Acción

SECUENCIA 1 1. Ingreso al Módulo Reportes. Opción saldos

NORMAL 2 2. Ingresar a la opción Concesionarios.

3.ingresar código del concesionario

4.Visualizar o imprimir

POSTCON-DICION * La fecha de consulta es validada por el sistema.

Fuente: Elaboración Propia Asistente de Caja: Encargado de los cobros de los concesionarios y realizar los reportes de conciliación de caja.

FIGURA Nº 18 REPORTE DE CONCILIACION DE CAJA Y EFECTIVO DIARIO

Pagos del Concesionariodiario

Reporte de cuadre de caja diario

Asistente de Caja

Conciliar reporte y efectivo

DIRECTOR DEECONOMIA


27

FIGURA Nº 19

DIAGRAMA DE ACTIVIDADES CONCILIACION DE CAJA Y EFECTIVO DIARIO

inicio

OK

REPORTE PREVIO

EMITIR REPORTE

FIN DE REPORTE

INGRESAR REPORTE OPCION

DIARIO POR RUBRO

1

1

INGRESAR FECHA INICIAL Y FINAL DEL

MES

CUADRA REPORTE CON

EFECTIVO

REPORTAR EFECTIVO

SOBRANTE O FALTANTE


28

FIGURA Nº 20

DIAGRAMA DE SECUENCIA CONCILIACION DE CAJA Y EFECTIVO


29

Tabla Nº 4

REPORTE DE CONCILIACION DE CAJA y EFECTIVO

REPORTE CONSOLIDADO DE INGRESOS

Objetivos Asoc.

Actores Asistente de Caja

Requisitos Aso.

Descripción

Precondición Se debe haber registrado pagos en el sistema

Paso Acción

SECUENCIA 1 1. Ingreso al Módulo de Reportes.

NORMAL 2 2. Ingresar a la opción reporte del día

3. Ingresar fecha a emitir.

4. Imprimir

POSTCON-DICION * La fecha es validada por el sistema.


FIGURA Nº 21

REPORTE DE PAGOS POR CONCESIONARIO

Pago del Concesionario

REPORTE DE PAGOSDE LOS CONCESIONARIOS

Asistente de Caja


30

FIGURA Nº 22 DIAGRAMA DE ACTIVIDADES DE PAGOS POR CONCESIONARIO

inicio

Existe MOVIMIENTOS

INGRESAR TRANSACCIONES

DEL DIA

REPORTE DE IPAGOS POR DIA

PREVIO

EMITIR REPORTE

FIN DE REPORTE1

1INGRESAR MODULO REPORTES OPCION

PAGOS POR DIA

INGRESAR FECHAA EMITIR


Tabla Nº 5



Objetivos Asoc.


Requisitos Aso.

Descripción

Precondición debe haberse registrado pagos en el sistema

Paso Acción


NORMAL 2 2. Ingresar a la opción Recibos por Día

3.Ingresar fecha a reportar

4. Imprimir

POSTCON-DICION * La fecha es validada por el sistema.


31

FIGURA Nº 23

INGRESO DE DEUDAS

INGRESAR A DEUDAS

Asistente de CajaDpto de Operaciones LISTA DE UNIDADES

SIN PAGAR SALIDA


FIGURA Nº 24 DIAGRAMA DE ACTIVIDAD INGRESO DE DEUDAS

inicio

Existe PADRONREPORTAR AL DPTO

DE OPERACIONES

INGRESAR RUBRO Y MONTO DE DEUDA

FIN DE INGRESO DEUDA

1

1

INGRESAR MODULO MOVIMIENTOS

OPCION DEUDAS

INGRESAR NUMERO DE PADRON


32

FIGURA Nº 25

DIAGRAMA DE SECUENCIA INGRESO DE DEUDAS

INGRESO DE DEUDAS

DPTO DE OPERACIONES

REGISTRAR DEUDAS


DEUDAOK

SI

LISTA DE UNIDADES SIN PAGAR

INGRESAR PADRON

INGRESAR RUBRO Y MONTO

GUARDAR


Tabla Nº 6

Ingreso de Deudas

INGRESO DE DEUDAS

Objetivos Asoc.

Actores DPTO DE Operaciones, Asistente de Caja

Requisitos Aso.

Descripción

Precondición debe haberse registrado las padrón

SECUENCIA NORMAL

Paso Acción

1 1. Ingreso al Módulo de Movimientos, Opción Deudas

2 2. Ingresar número de padrón

POSTCON-DICION

3 3.Ingresar código del rubro y monto de la deuda

4 Guardar


33

FIGURA Nº 26

Listado de Saldos por Rubros

LISTADO DE SALDOS POR RUBROS

Asistente de Caja


FIGURA Nº 27 DIAGRAMA DE ACTIVIDAD Listado de Saldos por Rubros

inicio

Existe

REPORTE PREVIO

FIN DE REPORTE DE SALDOS

1

1INGRESAR MODULO

reportesOPCION SALDOS

INGRESAR CODIGODEL RUBRO


34

Tabla Nº 7



Objetivos Asoc.


Descripción

Precondición debe haberse registrado las deudas

Paso Acción


NORMAL 2 2. Ingresar código del rubro a reportar

3. Visualizar o imprimir.

POSTCON-DICION


Director de Economía: Responsable de controlar el efectivo diario que ingresa por caja.

FIGURA Nº 28 REPORTE DE CUADRE DE CAJA POR DIA


Pagos del Concesionariopor Rubro

Reporte de cuadre de caja diario por rubro

Asistente de CajaDIRECTOR DEECONOMIA

35

FIGURA Nº 29

DIAGRAMA DE ACTIVIDADES DE CUADRE DE CAJA POR DIA

inicio

OK

REPORTE PREVIO

EMITIR REPORTE

FIN DE REPORTE

INGRESAR REPORTE OPCION

DIARIO POR RUBRO

1

1

INGRESAR FECHA INICIAL Y FINAL DEL

MES

CUADRA REPORTE CON

EFECTIVO

REPORTAR EFECTIVO

SOBRANTE O FALTANTE


36

FIGURA Nº 30 DIAGRAMA DE SECUENCIA CUADRE DE CAJA POR DIA

CUADRE DE CAJA DIARIO

ASISTENTE DE CAJA

CERRAR CAJA DEL DIA

DIRECTOR DE ECONOMIA SISTEMA

SOLICITA REPORTE

VERIFICAR DINERO

PREPARAR DATOS

REPORTAR FALTANTE O SOBRANTE

VERIFICAR EFECTIVO Y

REPORTE

GUARDAR DOCUMENTO Y

EFECTIVO

CUADRE DE CAJE

OK

NO

SI


37

Tabla Nº 8

REPORTE DE CUADRE DE CAJA POR DIA

REPORTE DE CUADRE DE CAJA POR DIA

Objetivos Asoc

Actores Asistente de Caja, Director de Economía

Requisitos Aso.

Descripción

Precondición Debe haberse registrado pagos de los concesionarios.

Paso Acción


NORMAL 2 2. Ingresar a la opción Resumen Diario.

3. Ingresar fecha a emitir el reporte de cuadre de caja


POSTCON-DICION El sistema valida la fecha de ingreso.


Gerencia: Responsable de administrar eficientemente los ingresos que tiene la empresa.

FIGURA Nº 31 REPORTE DE INGRESOS POR MES

Pagos del Concesionario

Reporte iNGRESOS MENSUALESAsistente de Caja

GERENCIA


38

FIGURA Nº 32 DIAGRAMA DE ACTIVIDADES DE INGRESOS POR MES

inicio

OK

REPORTE PREVIO

EMITIR REPORTE

FIN DE REPORTE

INGRESAR MODULO

REPORTE OPCION MES RUBRO

1

1

INGRESAR MES A REPORTAR


39

FIGURA Nº 33 DIAGRAMA DE SECUENCIA DE INGRESOS POR MES

REPORTE DE INGRESOS POR MES

GERENCIA

ANALISIS DE INFORME

IMPRIMIR INFORME

SOLICITA REPORTE DE INGRESOS POR MES

PREPARA INFOME

SISTEMA


40

Tabla Nº 9

REPORTE DE INGRESOS MENSUALES

REPORTE DE INGRESOS MENSUALES

Objetivos AsoC.

Actores Asistente de Caja, Gerencia

Requisitos Aso.

Descripción

Precondición Debe haberse registrado pagos de los concesionarios.

Paso Acción


NORMAL 2 2. Ingresar a la opción Mes.

3. Ingresar mes a reportar


POSTCON-DICION El rango de fecha es validada por el sistema.


FIGURA Nº 34

INGRESO DE NUEVO CONSECIONARIO

INGRESAR NUEVO CONSECIONARIO

Asistente de Caja

Dpto de Operaciones

NUEVO CONSECIONARIO

DATOS DEL CONSECIONARIO


41

FIGURA Nº 35 DIAGRAMA DE ACTIVIDADES DEL NUEVO CONSECIONARIO

inicio

OK

GENERA CODIGO

GUARDAR

FIN DE INGRESO

INGRESAR AL MODULO

ARCHIVO OPCION NUEVO

CONSECIONARIO

1

1

INGRESAR DATOS


42

FIGURA Nº 36 DIAGRAMA DE SECUENCIA DEL NUEVO CONSECIONARIO

INGRESO DENUEVO CONCESIONARIO

DPTO DE OPERACIONES

INGRESANUEVO

CONCESIONARIO


DATAOK

SI

DATOS DEL NUEVO

CONCESIONARIO

GENERAPADRON

GUARDARNO


43

Tabla Nº 10

INGRESAR NUEVO CONSECIONARIO

INGRESO NUEVO CONSECIONARIO

Objetivos Aso.

Actores Dpto. de Operaciones, Asistente de Caja

Requisitos Aso.

Descripción

Precondición El Dpto. de operaciones remite datos del nuevo concesionario.

Paso Acción

SECUENCIA 1 1. Ingreso al Módulo de Archivo

NORMAL 2 2. Ingresar a la opción nuevo

3. Ingresar datos del concesionario

4. Genera código y guardar

POSTCON-DICION El rango de fecha es validada por el sistema.


Software para Nuestro Aplicativo

Para la construcción de nuestro aplicativo hemos realizado una comparación del software a usar.

Tabla Nº 11

Bechmarking: COMPARACION DE SOFTWARE

LENGUAJE PRO. PHP VFP JAVA

COSTO GRATUITO, PUEDE NECESITA GRATUITO, PUEDE

FUNCIONAR SOBRE LICENCIA FUNCIONAR SOBRE

OTRAS APACHE RAPIDA: FACIL APACHE

DE APRENDER DIFICIL DE APRENDER

GESTOR DE B.D. Puede trabajar con MYSQL ES GESTOR B.D.

Puede trabajar con MYSQL


Se recomienda el uso de PHP, por ser gratuito y es escalable, la desventaja es que se necesita un servidor web, y características mínimas de equipos de desktop, con ello licencias para cada equipo.

Por cuestiones de orden económico de parte de la empresa se acepta trabajar en VFOXPRO, y por el tiempo de programación del aplicativo a desarrollar, además la empresa cuenta con la licencia del software.

44

3.4 DISEÑO DE BASE DE DATOS El nombre de la base de datos llevará el nombre del Proyecto en nuestro caso será: TRANSPORTES_CAJA.

3.4.1 DESCRIPCION DE ENTIDADES Concesionario: Almacena los datos de los concesionarios, choferes y cobradores que laboran en la Empresa

Ómnibus: todas las unidades que laboran en la empresa previamente registradas en las DGTU con numero padrón obtenido.

Detalle: Detalla los rubros a cobrar al concesionario (chofer o cobrador) y que estos rubros son divididos en administrativa y operativa, además se indica si son de recibo simple o boleta de venta.

Movimiento: Almacena toda transacción realizada sea administrativa u operativa.

Recibos: Almacena cada emisión realizada, producto de la transacción hecha al cobro administrativo.

Boletas: Almacena cada emisión realizada, producto de la transacción hecha al cobro operativo

Usuarios: Son los usuarios encargados y responsables de administrar el sistema.

Controlbol: controla la numeración de los documentos emitidos tanto Recibos como Boletas.

TABLA Concesionario

Nombre campo Tipo tamaño descripción

PK Cod_socio Apell_nom Dirección Fecha_ing DNI

Carácter Carácter Carácter Fecha Carácter

4 40 40 8 8

Código de Concesionario Nombre y apellido del concesionario Dirección del concesionario Fecha de ingreso a la empresa DNI del concesionario

TABLA Omnibus

Nombre campo tipo tamaño descripción

Pk N_padrón Cod_socio Apell_nom Dirección Fecha_ing DNI

Carácter Carácter Carácter Carácter Fecha Carácter

3 4

40 40 8 8

Código del Padrón Código del Concesionario Nombre y apellido del concesionario Dirección del concesionario Fecha de ingreso a la empresa DNI del concesionario

45

TABLA Detalle

Nombre campo

tipo tamaño descripción

PkCod_mov Tipo_doc Serie Rubro Detalle

Carácter Carácter Carácter Carácter Carácter

2 1 3 12 25

Código de movimiento Tipo de documento (Recibo o Boleta) Dirección del concesionario Separación de ingreso Descripción del rubro

TABLA Recibos

Nombre campo

Tipo tamaño Decimal descripción

Pk nro_recibo Cod_socio N_padrón Fecha_pago Total Observación

Carácter Carácter Numérico Date Numérico Memo

4 4 6 8 8 4

2

Código del Concesionario Tipo de documento. (Recibo o Boleta) Dirección del concesionario Fecha de Pago del Recibo Separación de ingreso Descripción del rubro

TABLA Boletas

Nombre campo

tipo tamaño Decimal descripción

PK nro_recibo Cod_socio N_padrón Serie Total Observación

Carácter Carácter Carácter Numérico Numérico Memo

4 4 3 6 8 4

2

Código del Concesionario Tipo de documento. (Recibo o Boleta) Serie del documento Dirección del concesionario Separación de ingreso Descripción del rubro

TABLA Usuarios

Nombre campo


PK Código Clave Usuario

Carácter Carácter Carácter

4 6

15

Código del Usuario Responsable Clave de ingreso al Sistema Nombre del usuario autorizado

46

TABLA Controlbol

Nombrecampo


Xnro_rec Xnro_bolet

Carácter Carácter

8 8

Contador del número de recibo Contador del número de boleta

TABLA Movimiento

Nombre campo

tipo Tamaño Decimal Descripción

Cod_socio N_padron Placa Cod_mov Fech_pago Tipo_docum Serie Nro_docum Nro_boleta Cant Importe

Carácter Carácter Carácter Carácter Fecha Carácter Carácter Numérico Numérico 2 numérico

4 4 6 3 8 1 3 6 6 2 8

2

Código del socio Número del padrón Número de placa Código del rubro a pagar Fecha de pago Tipo documento(recibo o boleta) Serie de la boleta Número del recibo a emitir Número de la boleta a emitir Cantidad del rubro a pagar Precio del rubro

47

3.4.2 Diagrama Entidad – Relación

Figura 37

Diagrama de Entidad – Relación


48

3.4.3 Requisitos Funcionales El Sistema Proveerá los siguientes servicios:

Figura 38: Modulo de Archivos

El Menú de archivos nos permite en sus opciones el ingreso de los concesionarios, el padrón de los ómnibus, el personal encargado de caja, los rubros a pagar y la posibilidad de cambiar la clave al ingresar al sistema.

Figura 39: Modulo Movimientos

El Menú Movimientos se genera los recibos/boletas/facturas que los concesionarios pagan, además existe la posibilidad de anular algún documento que fuera mal emitido y el ingreso de alguna deuda.

49

Figura 40: Modulo Consultas

En el Menú Consultas, podemos ver las deudas que podrían tener un concesionario, chofer o cobrador, así como en los saldos

Figura 41: Modulo Reportes

En el Menú Reportes nos permite reportar el padrón de los concesionarios, así como el cuadre de caja diario, Además de las deudas o saldos que tiene cada concesionario, chofer o cobrador.

50

Figura 42: Modulo Utilitarios

En el Menú Utilitarios generamos las copas de seguridad, Reindexar las tablas o restaurar alguna copia de seguridad de alguna tabla que haya sido dañada.

3.4.4 Requisitos No Funcionales Requisitos Mínimos para el Manejo del Sistema

Mainboard INTEL G30/33 S/V/R Entrada 2 USB, LPT1

Microprocesador: Pentium Dual Core 1,8GB

Disco Duro : 500 GB

Monitor SVGA: 640 X 480

Impresora LX-300 entrada USB

51

3.5 Implementación del Sistema

3.5.1 Aplicación Centralizada Dada la Implementación del aplicativo y siendo monousuario

Con solo una PC

La implementación del sistema se realizara por módulos con sus respectivas pruebas, dado que el sistema tiene una duración de 5 meses

Se hace la entrega de un módulo por mes.

3.5.2 Plataforma Tecnológica de la PC

3.5.2.1 Sistema Operativo Producto Windows XP Requisitos: Contar con la licencia de uso respectivo Condiciones: Ninguno

3.5.2.2 Gestor de Base de Datos Producto VFP 6.0 recomendado: Requisitos: Tener una PC con sistema operativo XP Service Pack 2.0

3.5.2.3 Antivirus Kaspersky Smart-antivirus Licencia para una 1 pc.

52

CAPITULO 4

RESULTADOS

4.1 Resultado Operativo La atención al Concesionario de redujo de 3,5 minutos a 1,5 minuto y

medio.

El Análisis Comparativo se muestra en el Anexo A

4.2 Presupuesto COSTO

EQUIPOS:

La empresa cuenta con un equipo Core 2 Duo, PLACA INTEL G30/33

S/V/R H.D. 500 GB- Memoria RAM 2 GB. E impresora Epson Matricial

FX-890.

PERSONAL:

JP : JEFE DEL PROYECTO

AJ : ANALISTA JUNIOR

P1 : PROGRAMADOR

COSTO DEL EQUIPO TECNICO A CARGO DEL PROYECTO.

PERSONAL COSTO MES 1 MES 2 MES 3 MES 4 TOTAL

JP 3800 25% 950 25% 950 25% 950 25% 950 3800 AJ 3000 25% 750 25% 750 25% 750 25% 750 3000 P1 2000 25% 500 25% 500 25% 500 25% 500 2000

2200

2200

2200

2200 8800

TABLA Nº 12: FLUJO DE CAJA

MES-0 MES-1 MES-2 MES-3 MES-4 MES-5 MES-6

Beneficios 2.000,00 2.000,00 2.000,00 2.000,00 2.000,00 2.000,00

Gastos 10.000,00 300,00 300,00 300,00 300,00 300,00 300,00

Flujo Neto -10.000,00 1.700,00 1.700,00 1.700,00 1.700,00 1.700,00 1.700,00

Acumulado -10.000,00 -

8.300,00 -

6.600,00 -

4.900,00 -

3.200,00 -

1.500,00 200,00

53

MES-7 MES-8 MES-9 TOTAL

Beneficios 2.000,00 2.000,00 2.000,00 18.000,00

Gastos 300,00 300,00 300,00 12.700,00

Flujo Neto 1.700,00 1.700,00 1.700,00 5.300,00

Acumulado 1.900,00 3.600,00 5.300,00

P1 : PROGRAMADOR

Proyecto Realizado por Terceros: 8800,00

Gastos de planilla 1000,00

Otros Gastos del proyecto 200,00

Total del Proyecto 10 000,00

Tasa de descuento Anual 15%

Tasa de Descuento Mensual 1,171%

VAN S/.9543, 17

VAN NETO S/.4440, 99

46,54%

PERIODO DE RECUPERACION 6 MESES

54

4.3 Cronograma

TABLA Nº 13

CRONOGRAMA

CRONOGRAMA DE SISTEMA DE CAJA Y CONTROL DE PAGO DE LA E.T. TREINTITRES

Nombre de tarea Duración Comienzo Fin

SISTEMA DE CAJA 150 días mié 13/02/13 jue 10/09/13

ASPECTOS GENERALES 18 días mié 13/02/13 vie 08/03/13

Definición del Problema 2 días mié 13/02/13 jue 14/02/13

Formulación del Problema 1 día vie 15/02/13 vie 15/02/13

Objetivos 1 día lun 18/02/13 lun 18/02/13

Alcances 2 días mar 19/02/13 mié 20/02/13

Justificación 2 días jue 21/02/13 vie 22/02/13

Análisis del Sistema Actual 4 días lun 25/02/13 jue 28/02/13

Modelamiento del Sistema Actual 5 días lun 04/03/13 vie 08/03/13

MARCO TEORICO 16 días lun 11/03/13 vie 01/04/13

DESARROLLO 109 días lun 02/04/13 jue 30/08/13

Diseño de la Aplicación 8 días lun 25/03/13 mié 03/04/13

Diagrama de Caso de Uso 8 días jue 04/04/13 lun 15/04/13

Diagrama de Secuencia 4 días mar 16/04/13 vie 19/04/13

Diagrama de Colaboración 4 días lun 22/04/13 jue 25/04/13

Diagrama de Clases 4 días vie 26/04/13 mié 01/05/13

Desarrollo de la aplicación 45 días jue 02/05/13 mié 03/07/13

Diseño de Menús 4 días jue 04/07/13 mar 09/07/13

Generación de Base de Datos 5 días mié 10/07/13 mar 16/07/13

Validación del Modelo 5 días mié 17/07/13 mar 23/07/13

Pruebas unitarias 3 días mié 24/07/13 vie 26/07/13

Pruebas de integración 3 días lun 29/07/13 mié 31/07/13

Pruebas con usuario 3 días jue 01/08/13 jue 04/08/13

CONCLUSIONES Y RECOMENDACIONES 6 días mar 23/08/13 jue 30/08/13

CONCLUSIONES 2 día vie 02/09/13 vie 03/09/13

RECOMENDACIONES 2 día lun 04/09/13 lun 05/09/13

Referencias Bibliográficas 1 día mar 06/09/13 mar 06/09/13

55

CRONOGRAMA DE SISTEMA DE CAJA Y CONTROL DE PAGO DE LA E.T. TREINTITRES

Nombre de tarea Duración Comienzo Fin

Anexos 1 día mié 09/09/13 mié 09/09/13

ENTEREGA Y CIERRE DEL PROYECTO 1 día jue 10/09/13 jue 10/09/13

Se ha identificado los actores y cada actor tuvo sus respectivas

necesidades, la cuales se han atendido al 100%.

Se han modelado todas las necesidades al 100%.

Nos ha permitido ordenar los rubros de pagos de los concesionarios,

esto necesario para los reportes de Gerencia para la tomas de

decisiones.

La Empresa tiene un beneficio de 10,000 soles anuales ahorrando en

Contratación de Personal.

La atención se redujo de 3,5 min a menos de 1,5 min.

La recuperación de la inversión es en 6 meses.

56

57

CONCLUSIONES

Usando las técnicas de Programación Estructurada-Orientada a Objetos se pudo cumplir con los objetivos y con los requerimientos que la empresa necesitaba.

Usando le metodología RUP y las buenas prácticas en el desarrollo del software se llegó a cumplir con los requerimientos al 100% de la E.T. TREINTITRES.

Habiéndose Reducido La Atención en los pagos de Los Concesionarios. El Dpto. de operaciones puede reducir su frecuencia de salida.

Los reportes entregados a Gerencia y al Dpto. de Economía son eficaces para la toma de decisiones.

A futuro se puede realizar otros módulos de otras áreas como el Dpto. de operaciones y /o despacho de combustible, que permitirán tener un mejor control de la información de la Empresa de Transportes.

58

BIBLIOGRAFIA

[1] Alfredo Weitzenfeld, Ingeniería de software orientada a objetos con UML,

Java e Internet (2005), Cengage Learning Editores

[2] Carrillo Anay Ramos, Metodología RUP de Ingeniería Del Software (2004).

[3] Edward Yourdon, Análisis Estructurado Moderno (1993) – Capitulo 10.

[4] Luis Joyanes Aguilar, Programación Orientada a Objetos (1996)

[5] Santiago Ceria, Casos de Uso, Un Método Práctico para Explorar Requerimientos. Buenos Aires (1997).

[6] Smuller Joseph, Aprendiendo UML (1999), Prentice Hall. México: Pearson Educación Latinoamericana.

59

ANEXOS

60

Anexo A

Análisis de la entrega de recibo en Forma Manual Comparado

Con la tabla de Recibos del Proyecto Propuesto

61

TABLA Nº 14

CUADRO DE FRECUENCIA Y

TOMA DE MUESTRA DE PAGO POR PADRON

La Tabla e frecuencia de unidades representa el orden de salida de las unidades de la Empresa de Transportes.

FRECUENCIA DE UNIDADES

PADRON TIEMPO CUADRO DE MUESTRA DE PAGO POR PADRON

3 6:00

7 6:07

SERIE RECIBO PADRON TIEMPO(*)

12 6:14

001 23490 3 3,6

16 6:21

001 23491 7 3,9

23 6:28

001 23492 12 4

24 6:35

001 23493 16 3,7

29 6:42

001 23494 23 3,5

30 6:49

001 23495 24 3

31 6:56

001 23496 29 2

32 7:03

001 23497 30 3,4

33 7:10

001 23498 31 3,6

37 7:17

001 23499 32 3,9

39 7:24

001 23500 33 3,8

41 7:31

Promedio 3,49090909

42 7:38

47 7:45

PROMEDIO DE PAGO POR PADRON 3,5 MIN

49 7:52

(*) EXPRESADO EN MIN.

53 7:59

57 8:06

21 8:13

25 8:20

27 8:27

35 8:34

43 8:41

45 8:48

51 8:55

59 9:02

La muestra se tomó de 6:00 a 9:00 am

62

Figura Nº 43 Tabla Recibo

Se muestra un porcentaje delos pagos realizados los concesionarios, tomados entre 6:00 – 9:00 am. (Hora punta de salida de las unidades) En la tabla recibo se almacena todos los pagos realizados por los concesionarios al momento de salir el terminal, respetando la salida de acuerdo a la tabla de frecuencia de salida del día correspondiente.

63

ANEXO B

DIAGRAMA DE COMPONENTE Y

OTROS CASOS DE USO

64

FIGURA Nº 44

DIAGRAMA DE COMPONENTES

ARCHIVO

MOVIMIENTO

REPORTES

UTILITARIOS

CONSULTAS


65

Diagramas de Casos de Uso del Módulo Archivo

Tabla Nº 15

ESPECIFICACIONES INGRESO DE CONCESIONARIO, CHOFER O COBRADOR

REGISTRAR CONCESIONARIO, CHOFER O COBRADOR

Objetivos Asoc.

Actores Asistente de Caja, super

Requisitos Aso. Documento de ingreso de Concesionario, chofer o cobrador, visado por el Área de Operaciones

Descripción

Precondición

Si tiene el usuario, password y clave. El Dpto. de Operaciones remite los documentos de nuevos Concesionarios

Paso Acción

SECUENCIA 1 1. Ingreso al Módulo de Archivo.

NORMAL 2 2. Ingresar a la Opción de Trabajadores

3

3. Selecciona Tipo de Trabajador, C: Concesionario, B: Cobrador, H: Chofer.

4. Ingresar Datos Del Concesionario

POSTCON-DICION * LOS DATOS DEL CHOFER,COBRADOR EL SISTEMA VALIDA LOSCAMPOS


Tabla Nº 16

ESPECIFICACIONES INGRESO DE UNIDADES

REGISTRO DE UNIDADES

Objetivos Asoc.

Actores Usuarios del Sistema

Requisitos Asociados Documento de ingreso de UNIDAD validado por el área de Operaciones

Descripción

Precondición Si el usuario tiene password y clave. Código del Concesionario ingresado

Paso Acción

SECUENCIA 1 Ingresar al Módulo de Ingreso de Archivos.

NORMAL 2 Ingresar a la opción Ómnibus.

3 Seleccionar el Código del Concesionario.

4 Ingresar datos de la unidad.

POSTCON-DICION

El número de padrón debe estar de acuerdo al número del padrón del Dpto. de operaciones.


66

Tabla Nº 17

ESPECIFICACIONES INGRESO DE RUBROS

REGISTRO DE RUBROS

Objetivos Asoc.


Requisitos Asociados Documento de ingreso del Rubro validado por la Gerencia

Descripción

Precondición Si el usuario tiene Password y clave.

Paso Acción

SECUENCIA 1 Ingresar al Módulo Archivos

NORMAL 2 Ingresar a la opción de Categorías

3 Seleccionar Tipo de Documento RECIBO O BOLETA.

4 Ingresar datos del rubro y monto respectivo.

POSTCON-DICION

Los rubros a cobrar son autorizados por la Gerencia.


Tabla Nº 18

ESPECIFICACIONES INGRESO DE ASISTENTES DE CAJA

REGISTRO DE RUBROS DE PAGOS

Objetivos Asoc.

Actores Asistente de Caja,

Requisitos Aso. Documento de ingreso de asistente validado por el Dpto. de Economía.

Descripción

Precondición Al ingresar al sistema debe tener código de usuario y contraseña.

Paso Acción

1 1. Ingreso al Sistema valida usuario y contraseña

SECUENCIA

2. Ingreso al Módulo de Archivo

NORMAL

3. Ingresar a la Opción de Personal

4. Ingresa datos del asistente de caja

5. El Sistema crea un código del asistente de caja

6. El asistente crea su contraseña

POSTCON-DICION

El sistema valida los datos ingresados por el asistente de caja VISADO POR EL Director de Economía


67

Diagramas de Casos de Uso del Módulo Movimientos

Tabla Nº 19

ESPECIFICACIONES REGISTRO DE PAGO DEL RECIBO

REGISTRO DE PAGODEL RECIBO

Objetivos Asoc.


Requisitos Asociados

Ingreso de Concesionarios, Ingreso de Rubros Ingreso de Deudas remitida por el Área de Operaciones.

Descripción

Precondición Si el usuario tiene password y clave.

Paso Acción

SECUENCIA 1 Ingresar al Módulo de Movimiento.

NORMAL 2 Se solicita el número de padrón

3 Seleccionar los Rubros a Pagar.

4 Aceptar el pago y emitir recibo.

POSTCON-DICION


Tabla Nº 20

ESPECIFICACIONES REGISTRO DE PAGO DE LA BOLETA

REGISTRO DE PAGO DE LA BOLETA

Objetivos Asoc.


Requisitos Asociados

Ingreso de Concesionarios, Ingreso de Rubros Ingreso de Deudas remitida por el Área de Operaciones.

Descripción

Precondición Si el usuario tiene password y clave.

Paso Acción

SECUENCIA 1 Ingresar al Módulo de Movimiento.

NORMAL 2 Se solicita el número de padrón

3 Seleccionar los Rubros a Pagar.

POSTCON-DICION


68

Diagramas de Casos de Uso del Módulo Reportes

Tabla Nº 21

ESPECIFICACIONES REPORTE DE CUADRE DE CAJA AL DPTO DE ECONOMIA

REPORTE DE CUADRE DE CAJA AL DPTO. DE ECONOMIA

Objetivos Asoc.


Requisitos Asociados Ingreso de pagos de los concesionarios

Descripción

Precondición Si el usuario tiene Password y clave

SECUENCIA NORMAL

Paso Acción

1 Ingresar al Módulo de Reportes

2 Ingresar la opción Resumen x día

3 Ingresar la fecha del día de cuadre de caja

4 Aceptar e imprimir

POSTCON-DICION


Tabla Nº 22

ESPECIFICACIONES REPORTE DE INGRESOS POR RUBROS A GERENCIA

REPORTE DE INGRESOS POR RUBROS A GERENCIA

Objetivos Asoc.


Requisitos Asociados Ingreso de pagos de los concesionarios

Descripción

Precondición Si el usuario tiene password y clave

Paso Acción

SECUENCIA 1 Ingresar al Módulo de Reportes

NORMAL 2 Ingresar la opción Resumen x Rubros

3 Ingresar la fecha del día que desea imprimir

4 Aceptar e imprimir

POSTCON-DICION


69

Diagramas de Casos de Uso del Módulo Consultas

Tabla Nº 23

ESPECIFICACIONES CONSULTA DE SALDOS

REPORTE CONSULTA DE SALDOS

Objetivos Asoc.

Actores Asistente de caja

Requisitos Asociados Ingreso de las Deudas por rubros

Descripción

Precondición El usuario tiene Password y clave

SECUENCIA NORMAL

Paso Acción

1 Ingresar al Módulo de Consultas

2 Ingresar la opción consulta por saldos

3 Ingresar código del concesionario

4 Visualizar

POSTCON-DICION


Tabla Nº 24

ESPECIFICACIONES CONSULTA DE DEUDAS

REPORTE CONSULTA DE SALDOS

Objetivos Asoc.


Requisitos Asociados Ingreso de las Deudas por rubros

Descripción


SECUENCIA NORMAL

Paso Acción

1 Ingresar al Módulo de Consultas

2 Ingresar la opción consulta por deudas

3 Ingresar código del concesionario

4 Visualizar

POSTCON-DICION


70

Diagramas de Casos de Uso del Módulo Utilitarios

Tabla Nº 25

ESPECIFICACIONES COPIA DE SEGURIDAD - BACKUP

COPIA DE SEGURIDAD – BACKUP

Objetivos Asoc.


Requisitos Asociados Tener CD o USB para copia de seguridad

Descripción


SECUENCIA NORMAL

Paso Acción

1 Ingresar al Módulo de Utilitario

2 Ingresar la opción copia de seguridad

POSTCON-DICION


Tabla Nº 26

ESPECIFICACIONES RESTAURAR COPIA DE SEGURIDAD - BACKUP

RERSTAURAR COPIA DE SEGURIDAD

Objetivos Asoc.


Requisitos Asociados Tener CD o USB para copia de seguridad

Descripción


SECUENCIA NORMAL

Paso Acción

1 Ingresar al Módulo de Utilitario

2 Ingresar la opción restaurar copia de seguridad

POSTCON-DICION


Documents

Facultad de Ingeniería de Sistemas - Repositorio UTP ...repositorio.utp.edu.pe/bitstream/UTP/258/1/0620421.pdf · 1.2.4 Estado de Arte ... FIGURA Nº 2 Fases de la Metodología RUP