Ip 96272011 CD Ramirez Glori Mar

REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA

VICERRECTORADO ACADÉMICO COORDINACIÓN GENERAL DE PREGRADO

COORDINACIÓN DE PASANTÍA PROYECTO DE CARRERA: INGENIERÍA EN INFORMÁTICA

DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA ADMINISTRACIÓN DE LOS RECURSOS DE LA GERENCIA DE RECAUDACIÓN EN LA EMPRESA

DE TRANSPORTE PÚBLICO DEL ESTADO BOLÍVAR C.A.

Trabajo Especial de Grado presentado como requisito para optar al Título De INGENIERO EN INFORMÁTICA.

Autor : Ramírez Glorima r

CIUDAD GUAYANA, MAYO DEL 2011




DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA ADMINISTRACIÓN DE LOS RECURSOS DE LA GERENCIA DE RECAUDACIÓN EN LA EMPRESA

DE TRANSPORTE PÚBLICO DEL ESTADO BOLÍVAR C.A.

Autor: Ramírez Glorimar C.I: 19.298.727 Tutor: Salazar Oscar

CIUDAD GUAYANA, MAYO DEL 2011




APROBACIÓN DEL JURADO

Quienes suscriben a los miembros del jurado evaluador del

informe Desarrollo de un sistema de información para la

administración de los recursos de la Gerencia de

Recaudación en la Empresa de Transporte Público del Estado

Bolívar C.A. presentado por la tecnólogo en computación

Glorimar J. Ramírez D, C.I: 19.298.727 para optar por el título de

“Ingeniero en Informática”, ha sido considerado que el mismo

cumple con los requisitos exigidos por los reglamentos

respectivos por lo que da aprobación al mismo.

Ing. Salazar Oscar Ing. Lóp ez Josué Tutor Académico Tutor Industrial

Escalona Jorge

Jurado

iv

DEDICATORIA

Toda meta cumplida y propuesta en el transcurrir de mis años se las

dedico al ser que me dio la vida, la que día a día está a mi lado apoyándome,

impulsándome a conseguir todo lo que me proponga, porque a veces no sólo

las palabras son suficientes, los detalles que te demuestran a diario es lo que

te hacen pensar que vale la pena seguir adelante y brindarle la felicidad de

vernos realizados.

Como dicen popularmente el logro de un hijo siempre será el logro de

una madre; y esta etapa que se cierra pero que me abre muchas puertas

mas te la dedicado a ti mamá.

Gracias…

v

AGRADECIMIENTOS

Mis agradecimientos van dirigidos a aquellas personas que de alguna

manera contribuyeron a la realización de este proyecto y brindaron una

experiencia personal y profesional en mi vida de gran trascendencia:

Le doy gracias a dios por darme la vida, ampararme en cada momento

y regalarme a la grandiosa madre y a los preciados hermanos que tengo.

A mi mamá por apoyarme, estar siempre a mi lado y facilitarme

siempre el cumplimiento de mis sueños y metas.

A Oscar Salazar, que mas que un profesor, un profesional es un

excelente amigo y una persona en la que estoy segura siempre podré contar.

vi

ÍNDICE GENERAL

Pág.

ACTA DE APROBACIÓN DE LOS TUTORES……………………... iii DEDICATORIA………………………………………………………… iv AGRADECIMIENTOS…………………………………………………. v ÍNDICE GENERAL…………………………………………………… vi INDICE DE TABLAS…………………………………………………… viii INDICE DE GRÁFICOS..……………………………………………… ix ÍNDICE DE ANEXOS…………………………………………………. x INTRODUCCIÓN……………………………………………………… 11 1. CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA

1.1. Descripción del Problema……………………………………. 13 1.2. Objetivos Objetivos General……………………………………………… 15 Objetivos Específicos…………………………………………. 15 1.3. Justificación…………………………………………………… 16 1.4. Alcance………………………………………………………… 17

2. CAPÍTULO II. MARCO TEÓRICO

2.1. Antecedentes de la Empresa………………………………… 2.2. Bases Teóricas……………………………………………….

2.2.1. Recaudación ……………………………………………. 2.2.2. Arqueo de Caja……………………………………….. 2.2.3. Administración de Recursos………………………… 2.2.4. Recursos Financieros………………………………… 2.2.5. Hoja de Calculo……………………………………….. 2.2.6. Utilidad de la hoja de calculo……………………….. 2.2.7. Sistemas……………………………………………….. 2.2.8. Sistemas de Información……………………………. 2.2.9. Requerimientos de Información……………………. 2.2.10. Etapas de la fase de Requerimientos…….. 2.2.11. Clasificación de los Requerimientos……….. 2.2.12. Características de los Requerimientos…….. 2.2.13. Base de Datos………………………………… 2.2.14. Sistema de administración de base de datos

18

21 21 21 22 22 22 23 23 24 24 24 25 26 26

vii

2.2.15. Administrador de base de datos…………… 2.2.16. Página web……………………………………. 2.2.17. Elementos de la página web……………….. 2.2.18. Apache…………………………………………. 2.2.19. Php………………………………………………

27 29 30 30 32

3. CAPÍTULO II I. MARCO METODOLÓGICO

3.1. Tipo de Investigación………………………………………. 3.2. Población y muestra………………………………………… 3.3. Técnicas e instrumentos de recolección de datos…….. 3.4. Modelo del proceso del software basado en desarrollo en

espiral…………………………………………………………. 3.4.1. Obtención y Análisis de requerimiento……………. 3.4.2. Análisis y gestión de riesgos………………………… 3.4.3. Diseño y programación……………………………….. 3.4.4. Evaluación del cliente………………………………….

33 33 34

35 36 36 37 37

4. CAPÍTULO IV PRESENTACIÓN Y ANÁLISIS DE LOS

RESULTADOS 4.1. Ámbito…………………………………………………………… 4.2. Viabilidad………………………………………………………… 4.3. Obtención y análisis de requerimientos……………………… 4.4. Especificación de requerimientos…………………………….. 4.5. Descomposición del Problema………………………………... 4.6. Plan de actividades…………………………………………….. 4.7. Análisis y gestión de riesgos………………………………….. 4.8. Diseño y Programación………………………………………...

4.8.1. Modelo funcional y de flujo de información………….. 4.8.2. Modelado de datos……………………………………… 4.8.3. Análisis orientado a objetos……………………………. 4.8.4. Modelado de clases…………………………………….. 4.8.5. Modelado de diseño……………………………………..

38 39 40 41 43 44 45 48 50 51 62 67 68

CONCLUSIONES……………………………………………………….. 101 RECOMENDACIONES…………………………………………………. 103 GLOSARIO………………………………………………………………. 104 BIBLIOGRAFÍAS………………………………………………………… 107 ANEXOS…………………………………………………………………. 108

viii

LISTA DE TABLAS

Pág.

Tabla 01. Plan de Actividades…………………………………… 45 Tabla 02. Tabla de identificación de riesgos………………….. 51 Tabla 03. Tabla de priorización. ………………………………… 52 Tabla 04. Tabla RSGS 01. ………………………………………. 53 Tabla 05. Tabla RSGS 02………………………………………… 54 Tabla 06. Tabla cargo……………………………………………. 57 Tabla 07. Tabla estado…………………………………………… 58 Tabla 08. Tabla entrega recepción valores vial…………......... 58 Tabla 09. Tabla nivel……………………………………………… 60 Tabla 10. Tabla Operador……………………………………….. 60 Tabla 11. Tabla ruta………………………………………………. 61 Tabla 12. Tabla tipo-operador…………………………………… 62 Tabla 13. Tabla recepción-valores-viales………………………. 62 Tabla 14. Tabla turno…………………..…………………………. 63 Tabla 15. Tabla unidad…………………………………….......... 65 Tabla 16. Tabla usuario………………………………………….. 65 Tabla 17. Tabla Estado…………………………………………… 66 Tabla 18. Caso de Uso General

ix

LISTA DE GRÁFICOS

Pág.

Gráfico 01. Mapa de procesos de TRANSBOLIVAR……………. 21 Gráfico 02. Estructura organizativa de TRANSBOLIVAR………. 22 Gráfico 03. Actividades básicas de un sistema de información.. 25 Gráfico 04. Modelo del proceso del software basado en

desarrollo espiral………………………………………. 37 Gráfico 05. Diagrama de flujo de datos nivel 0…………………… 56 Gráfico 06. Diagrama DER…………………………………………. 67 Gráfico 07. Diagrama casos de usos……………………………… 68 Gráfico 08. Diagrama de actividad nivel 1………………………… 69 Gráfico 09. Diagrama de actividad nivel 2………………………… 70 Gráfico 10. Diagrama de actividad nivel 3………………………… 71 Gráfico 11. Diagrama de clases……………………………………. 72 Gráfico 12. Diseño arquitectónico………………………………….. 73 Gráfico 13. Inicio de sesión…………………………………………. 81 Gráfico 14. Página principal………………………………………… 82 Gráfico 16. Módulo de administración de usuario……………….. 84 Gráfico 17. Registro del personal………………………………….. 85 Gráfico 18. Registrar nuevo usuario………………………………. 86 Gráfico 19. Modificar usuario existente…………………………… 88 Gráfico 20. Eliminar usuario existente……………………………. 89 Gráfico 21. Registro de operador…………………………………. 91 Gráfico 22. Modificar operador……………………………………. 92 Gráfico 23. Eliminar Operador…………………………………….. 93 Gráfico 24. Módulo de Recaudación……………………………… 95 Gráfico 25. Recepción de valores…………………………………. 96 Gráfico 26. Página de impresión…………………………………… 98 Gráfico 27. Recibo de recepción de valor………………………… 99 Gráfico 28. Consulta de recepciones……………………………… 100 Gráfico 29. Recepción de valor consultada………………………. 100 Gráfico 30. Modificar recepción……………………………………. 102 Gráfico 31. Reporte turno…………………………………………... 103 Gráfico 32. Recibo de reporte turno………………………………. 105 Gráfico 33. Reporte por operador…………………………………. 107

x

Gráfico 34. Recibo de reporte por operador……………………… 109 Gráfico 35. Reporte Diario…………………………………………. 111 Gráfico 36. Módulo de cierre laboral……………………………… 112 Gráfico 37. Arqueo de caja………………………………………… 113

ANEXOS

Pág.

Nº 01 Formato Recepción de Valores……………………... 111 Nº 02 Formato de Reporte por Turno……………………… 112 Nº 03 Formato de Arqueo de Caja…………………………. 113 Nº 04 Minuta de Entrevista 01……………………………… 114 Nº 05 Minuta de Entrevista 02……………………………… 115 Nº 06 Planificación de mesas de trabajo………………….. 116

11

INTRODUCCIÓN

En el campo de la informática se dice que todo proceso que se realice

en reiteradas ocasiones en una empresa es fiel candidato para ser

automatizado, permitiendo simplificar las labores diarias, obteniendo

resultados satisfactorios, precisos y exactos. La idea de automatización es

considerada como una acción de progreso y de incremento en el desempeño

de los trabajadores, permitiendo simplificar sus actividades y asegurando el

resguardo de la data.

La Empresa de Transporte Público del Estado Bolívar

TRANSBOLIVAR C.A, es una organización que apoya fielmente la

implementación de automatización de procesos, ya que esta no sólo presta

el servicio de traslado a la comunidad sino que también necesita llevar un

control de todos sus ingresos resultantes de los recaudos de las unidades de

transporte por ser una empresa autosustentable.

De acuerdo a la necesidad de tener un resguardo de la información

que certifica la recaudación de la empresa y a fin de emitir reportes de

gestión sobre ello, surge la concepción de analizar, diseñar y desarrollar un

sistema de información que facilite la gestión y administración de los recursos

monetarios existentes en la Gerencia de Recaudación.

Tomando en consideración esta propuesta se dará continuidad a la

creación del actual proyecto que contará con cuatro (04) capítulos que se

desglosarán de la siguiente manera:

Capítulo I, se presenta el planteamiento del problema, se expone la

descripción del problema, objetivo general, objetivos específicos, justificación

y alcance de la investigación.

12

Capítulo II, se desarrolla el marco teórico, los antecedentes del tema,

las bases teóricas necesarias para la toma de decisión, como son:

recaudación, recepción de valores, arqueo de caja, herramienta para la

creación de aplicaciones web, entre otros.

Capítulo III, se realiza el marco metodológico, el tipo de investigación

aplicada, las técnicas y herramientas de recolección de información y la

metodología de software aplicada.

Capítulo IV, se muestran los resultados de la puesta en marcha del

proyecto.

Y por último se presentan las conclusiones, recomendaciones y

bibliografías.

13

CAPÍTULO I

PLANTEAMIENTO DEL PROBLEMA

1.1. Descripción del Problema

El transporte público es parte esencial de una ciudad, a través de él se

desplazan personas desde un punto a otro en un área específica de la

misma. Venezuela cuenta con diferentes medios de transportes que son

destinados para varias zonas del país. Existen empresas tanto públicas

como privadas destinadas a brindar este servicio, una de las empresas

encargadas de ofrecer el servicio de transporte público en la región de

Ciudad Guayana – Estado Bolívar es La Empresa de Transporte Público de

Bolívar (TRANSBOLIVAR C.A), cuenta con treinta y cuatro (34) autobuses

rurales que se desplazan por todo el municipio Caroní y once (11) buses

interurbanos que se trasladan desde Ciudad Bolívar hasta Santa Elena con

diversas escalas entre las distintas zonas. Su oficina administrativa está

ubicada en el CTE Cachamay de Puerto Ordaz en ella se operan todas las

actividades relacionadas con la administración, recaudación y las estrategias

para brindar un buen servicio a los pasajeros que se dirigen en cada unidad

vehicular. TRANSBOLIVAR, está conformada por seis (6) Gerencias y

Presidencia entre ellas podemos mencionar:

La Gerencia de Recaudación, Gerencia de Administración y Finanzas,

Gerencia de Operaciones, Gerencia de Gestión del Talento Humano,

Gerencia General y Gerencia de Gestión Estratégica. Cada gerencia se

encuentra encargada de una tarea en particular, permitiendo así el buen

funcionamiento de la empresa.

14

Una de las funciones de mayor peso en la empresa se lleva a cabo en

la Gerencia de Recaudación, en ella se remiten todos los ingresos que

percibe la empresa a través de los servicios que brinda. Todas y cada una de

las actividades que realiza dicha gerencia se encuentran bajo hojas de

cálculo de Excel en donde se almacenan la recepción de valores por cada

operador de las unidades de transporte público, el arqueo de caja, los

reportes diarios, semanales, mensuales y por turno de la recepción de

valores. Cada formato tiene un objetivo característico que es de vital

importancia en dicha gerencia a continuación se describirán cada uno de

ellos:

El Formato de Recepción de Valores: almacena todas las

recaudaciones realizadas por los operadores de las unidades de transporte

público por turno diariamente. (Ver Anexo 01).

Los Reportes por turno, diario, semanales, mensuales: están

relacionados con la recepción de valores en ellos se totaliza la recaudación

dependiendo de cada caso. (Ver Anexo 02).

Arqueo de Caja: es una herramienta utilizada para que el analista y

supervisor lleven un control de todo lo percibido en su turno, también es

aplicado para el jefe de la unidad en el arqueo diario de caja. (Ver Anexo 03).

Todos estos formatos son llenados diariamente por el personal de

Recaudación, siendo de vital importancia ya que la empresa es sustentable

de acuerdo a los ingresos que la misma perciba.

Los formatos en hoja de cálculo satisfacen los requerimientos

necesarios para emitir los reportes que indican el total recaudado diaria,

semanal, mensualmente, por turno y operador, aún así no brinda la

eficiencia y eficacia en la administración de los datos; impidiendo la

protección bajo cualquier error humano, la duplicidad e inconsistencia de la

información, perdida de la data por fuentes externas, entre otras. Una buena

administración de los datos incurre de manera positiva en el trabajo de los

15

integrantes de la Gerencia de Recaudación ya que los ayuda a emprender

sus actividades de manera más simplificada.

Dada las circunstancias la Gerencia de Recaudación necesita un

sistema administrativo que le permita llevar un control de los recursos que

percibe la misma, de forma automatizada almacenando en una base de

datos toda la información recolectada por cada recepción de valor. Es por

ello que se forja la idea de diseñar e implementar un sistema que permita

almacenar información y a su vez generar reportes de la recepciones de

valores.

1.2. Objetivos

Objetivo General

Desarrollar un sistema de información para la administración de los

recursos de la Gerencia de Recaudación en la Empresa de Transporte

Público del Estado Bolívar (TRANBOLIVAR, C.A).

Objetivos Específicos

• Analizar los requerimientos de información de los procesos

involucrados para el desarrollo del sistema.

• Diseñar la arquitectura del software, tomando en cuenta el

cumplimiento de los requerimientos planteados por los usuarios.

• Codificar el sistema bajo un lenguaje que permita la adecuación

correcta de la arquitectura del software diseñada.

• Evaluar el correcto funcionamiento del software, destacando el

cumplimiento de los requerimientos propuestos por el usuario.

16

1.3. Justificación

El Sistema Administrativo de Boletería, Servicios Especiales y

Recepción de Valores (SABSERV), es un sistema que facilitará la

administración de los recursos que maneja el personal de recaudación como

lo son: ingresar los datos de las recaudaciones, generar reportes, emitir

estadísticas, entre otros; logrando su implementación de manera consistente

y contribuyendo positivamente en los avances y adecuación tecnológica de la

empresa, ayudando a la realización del trabajo en un menor periodo de

tiempo e incrementando la productividad de la Gerencia de Recaudación de

TRANSBOLIVAR C.A, tomando esta característica como la finalidad

primordial del sistema.

SABSERV registrará diariamente los ingresos emitidos por cada

operador responsable de las unidades de transportes existentes en la

empresa, ofreciendo así un resguardo de la información de manera segura

en la base de datos evitando redundancias y disminuyendo posibles errores

humanos, a su vez estarán disponibles la generación de reportes que

permitirán al gerente llevar un control global de lo recaudado. El sistema no

sólo llevará el control de la recepción de valores sino que permitirá realizar

un arqueo de caja una vez culminado cada turno y jornada diaria a fin de

validar la cantidad de ingresos recolectados en ese momento.

Con la implantación del sistema el personal que labora en la

Gerencia de Recaudación se ahorrará la necesidad de realizar reportes a

través de hojas de cálculo, disminuirán problemas de rendimiento de los

equipos utilizados, reducirán el margen de error en el tratamiento de la

información e incluso la posibilidad de perder la información por fuentes

externas (virus informáticos, apagones eléctricos, etc.).

17

1.4. Alcance

Este sistema será desarrollado e implantado en la Gerencia de

Recaudación de la Empresa de Transporte Público del Estado Bolívar

(TRANSBOLIVAR C.A), ya que ha sido diseñado para cumplir

específicamente con los parámetros y funcionamientos de la gerencia en

cuestión, teniendo como finalidad servir como herramienta de apoyo para el

registro de las recepciones diarias, la emisión de reportes y el arqueo de

caja.

18

CAPÍTULO II

MARCO TEÓRICO

2.1. Antecedentes de la Empresa.

2.1.1. Reseña de creación

Transporte Público del Estado Bolívar (TRANSBOLIVAR C.A.), es una

Empresa de Producción Social Indirecta (EPSI), con capital accionario 100 %

de la Gobernación del Estado Bolívar, destinada al servicio de transporte

público en rutas urbanas e interurbanas en el ámbito del Estado Bolívar,

generando trabajo estable, cuya propiedad es ejercida por el Estado a

nombre de la comunidad, el cual y progresivamente podrá transferir la

propiedad a una o varias comunidades, a una o varias comunas, en beneficio

del colectivo.

Su razón de ser, se fundamenta en las necesidades de movilización

no satisfechas a la población, encontrándose el gobierno regional con una

situación de anarquía en el servicio de transporte público, inexistente en 5

municipios del estado, inaccesible a personas de bajos recursos por altas

tarifas, operado en un Setenta (70) % por modalidad de carros por puesto y

camionetas Pickup, con Ochenta (80) % de flota privada con más de 10 años

de uso, no apta para la prestación del servicio de transporte público,

determinándose entonces, la creación de la Empresa TRANSBOLIVAR C.A.,

mediante Decreto del Ejecutivo Regional del Estado Bolívar Nº 194 de fecha

30/05/2008, iniciando operaciones en fecha 10/11/2008, con el servicio de

transporte urbano en el Municipio Caroní, y posteriormente en fecha

18/11/2008 incorpora el servicio de transporte interurbano para los

Municipios del Sur del Estado Bolívar, bajo un marco socialista incluyente,

19

con esquemas de operación conceptualizados en la interconexión de centros

poblados, salarios justos a la condición del operador de transporte público, y

unidades dignas para el usuario del servicio, como lo merece el pueblo de

Bolívar. (Tomado de la Intranet http://transbolivar).

A continuación en el Gráfico Nº 01, se presenta el mapa de procesos

de TRANSBOLIVAR, en donde se expresa esquemáticamente la razón de

ser de la organización.

GESTION DE LA DIRECCION

PROCESO

DIRECTIVO

C

O

M

U

N

I

D

A

D

NECESIDAD

DE

VIAJES

PROCESO

SUBSTANCIAL

Operación del Servicio de Transporte

Público de Pasajeros (Urbano e Interurbano)

DESTINOS INTERVALOS DE DESPACHOS

FRECUENCIA TIEMPO DE VIAJE

RECURSO HUMANO

PROCESO

DE APOYO SUPERVISION

OPERACIONAL RECAUDACION

MANTENIMIENTO FLOTA, EQUIPOS E INFRAESTRUCTURA

PROVISION DE RECURSOS

INFRAESTRUCTURA VIAL , TRANSITO Y TRANSPORTE

SATISFACCION

DE

LA

C

O

M

U

N

I

D

A

D

Mejora continua del Sistema Gestión de la Calidad

A

(ACTUAR)

P

(PLANIFICAR)

V(VERIFICAR)

H(HACER)

GESTION DE LA

CALIDAD

GESTION DE

MEDICION Y CONTROL

MAPA DE PROCESOS

TRB-900-MP-001/2010Fecha de Vigencia: 01/09/2010

Elaborado :

Supervisor de Transporte

Revisado y Autorizado:

Representante por la Dirección para la Implementación SGC

Aprobado:

Presidente TRANSBOLIVAR C.A

Actualización N°00

Gráfico Nº 01. Mapa de Procesos de TRANSBOLIVAR: intranet http://transbolivar

20

A su vez en el Gráfico Nº 02 se muestra la estructura organizativa

vigente de la Empresa de Transporte Público del Estado Bolívar.

ASAMBLEA ACCIONISTAS

FUNCIONES ESTRATÉGICAS

JUNTA DIRECTIVA

PRESIDENCIA

AUDITORIA INTERNA

GERENCIA GENERAL

SEGURIDAD Y PROTECCION

GERENCIA OPERACIONES

GERENCIA RECAUDACION

GERENCIA ADMINISTRACIÓN

Y FINANZAS

GERENCIA GESTION

ESTRATEGICA

PLANIFICACION Y CONTROL

MANTENIMIENTO

OPERACIONES

BOLETERIA ENCOMIENDAS

RUTA URBANA

RUTA INTERURBANA

TESORERIA

ADMINISTRACIÓN

SERVICIOS GENERALES

GESTION DEL TALENTO

HUMANO

CONSULTORIA JURIDICA

Gráfico Nº 02. Estructura Organizativa de TRANSBOLIVAR: intranet

http://transbolivar.

21

2.2. Bases Teóricas

2.2.1. Recaudación

La recaudación es un factor relevante en los procesos administrativos

de una organización, permitiendo llevar el control y registro de los ingresos

percibidos (Citado de Calva J, Aguilar G 2007, pág. 35).

2.2.2. Arqueo de Caja

Según Madariaga Gorocica (2004), se dice que: el Arqueo de Caja

consiste en el análisis de las transacciones del efectivo, durante un lapso

determinado, con el objeto de comprobar si se ha contabilizado todo el

efectivo recibido y por tanto el saldo que arroja esta cuenta, corresponde con

lo que se encuentra físicamente en caja en dinero efectivo. Sirve también

para saber si los controles internos se están llevando adecuadamente.

2.2.3. Administración de Recursos

Según Arzuedo (1991), la administración de los recursos consiste en

el manejo eficiente de estos medios bien sean tangibles o intangibles, con el

fin de cumplir con la satisfacción de algún interés.

22

2.2.4. Recursos Financieros

Según Arzuedo (1991), los recursos financieros son activos que tienen

algún grado de liquidez, que son generados a partir de diversas actividades

realizadas por una empresa, bien sea venta de productos o prestación de

algún servicio.

2.2.5. Hoja de Cálculo

Según Curt Frye (2004), se dice que una hoja de cálculo es un

programa que permite manipular datos numéricos y alfanuméricos dispuestos

en forma de tablas (la cual es la unión de filas y columnas). Habitualmente es

posible realizar cálculos complejos con formulas y funciones y dibujar

distintos tipos de graficas.

2.2.6. Utilidad de las Hojas de Cálculo

Debido a la versatilidad de las hojas de cálculo modernas, se

utilizan a veces para hacer pequeñas bases de datos, informes, gráficos

estadísticos, clasificaciones de datos, entre otros usos. Las operaciones

más frecuentes se basan en cálculos entre celdas, las cuales son

referenciadas respectivamente mediante la letra de la columna y el

número de la fila. (Citado de Curt F 2004, pág. 14).

23

2.2.7. Sistemas

Según Kendall & Kendall (2005): “Es un conjunto de elementos dinámicamente relacionados, que forman una actividad para obtener los objetivos deseados operando sobre datos o materias para proveer la información deseada”.

2.2.8. Sistemas de información

Un sistema de información es un conjunto de elementos que

interactúan entre sí con el fin de apoyar las actividades de una empresa o

negocio. Este realiza cuatro actividades básicas para su funcionamiento,

entre ella podemos mencionar: entrada, almacenamiento, procesamiento y

salida de información. (Citado de Kendall & Kendall 2005).

Las diferentes actividades que realiza un Sistema de Información se

pueden observar en el diseño conceptual ilustrado en el Gráfico Nº 03.

Gráfico Nº 03. Actividades básicas de un sistema de información: (Kendall & Kendall, 2005).

24

2.2.9. Requerimientos de información

Los requerimientos son declaraciones que identifican atributos,

capacidades, características y/o cualidades que necesita cumplir un sistema

(o un sistema de software) para que tenga valor y utilidad para el usuario. En

otras palabras, los requerimientos muestran qué elementos y funciones son

necesarias para un proyecto. (Citado de Kendall & Kendall 2005).

2.2.10. Etapas de la fase de requerimientos

• Obtención de requerimientos: búsqueda y obtención de los

requerimientos desde los grupos de interés.

• Análisis: comprobación de la consistencia y completitud de los

requerimientos.

• Verificación: constatación de que los requerimientos especificados son

correctos.

2.2.11. Clasificación de los requerimientos

• Requerimientos funcionales: qué debe hacer el sistema o software.

• Requerimientos no funcionales: cómo debe funcionar el sistema o

software (no su implementación), por ej. calidad, rendimiento, facilidad de

uso, etc.

25

• Requerimientos externos: a qué se debe atener el sistema o software con

respecto a su entorno: compatibilidad con otros sistemas, adecuación a

determinadas leyes, etc.

2.2.12. Características que deberían cumplir los requerimientos

• Actual: el requerimiento no debe volverse obsoleto con el paso del

tiempo.

• Cohesión: el requerimiento debe dirigirse a solo una única cosa.

• Completo: el requerimiento debe estar completamente declarado en un

único lugar, sin información faltante.

• Consistente: el requerimiento no debe contradecir ningún otro

requerimiento y debe ser completamente consistente con toda la

documentación.

• Correcto/necesario: el requerimiento debe cumplir con la necesidad

declarada por los interesados en el sistema/software.

• Factible/viable: el requerimiento debe poder ser implementado.

• No ambiguo: el requerimiento debe estar concisamente declarado. Debe

expresar hechos objetivos, no opiniones subjetivas. Debe poder ser

interpretado de una única manera.

• Obligatorio: el requerimiento debe representar una característica definida

por el grupo interesado en el desarrollo del sistema/software, su ausencia

no puede ser reemplazada.

• Observable externamente: el requerimiento debe especificar una

característica observable externa o experimentable por el usuario del

producto.

26

• Verificable/demostrable: La implementación del requerimiento debe

poder ser resuelta en alguno de estos cuatro métodos: inspección,

análisis, demostración o prueba.

2.2.13. Base de Datos

Según James (1990), la base de datos puede definirse como una

colección de datos interrelacionados, almacenados en conjunto sin

redundancias perjudiciales e innecesarias; su finalidad es la de servir a una

aplicación o más, los datos se almacenan de manera que resulten

independientes de los programas que lo usan. Se emplean métodos bien

determinados para incluir datos nuevos y para modificar o extraer los datos

almacenados.

2.2.14. Sistema de Administración de Base de Datos

Según James (1990), la administración de las bases de datos tiene

como finalidad servir a los programas de aplicación, ejecutando sus

operaciones de datos. Al momento en que el sistema de administración de

base de datos lee un registro se desarrollan unos procesos primordiales para

su ejecución entre ellos se encuentran:

• El programa de aplicación le pide al sistema de administración de datos

que lea un registro.

• El sistema de administración de base de datos obtiene la descripción de

los datos del programa o sub-esquema que utiliza la aplicación y los

examina.

27

• El sistema de administración de base de datos obtiene el esquema o

descripción lógica global y determina que tipo lógico de datos se

necesita.

• El sistema de administración de base de datos examina la descripción

física de la base de datos y determina que registro físico debe leer.

• El sistema de administración emite una orden al sistema operativo de la

computadora, indicando lo que debe leer (el registro pedido).

• El sistema operativo interacciona con el almacén físico en el que se

encuentra el dato.

• Los datos pedidos se transfieren desde el almacén a los almacenes

intermedios (buffers) del sistema.

• Se compara el esquema y sub-esquema, el sistema de a administración

de la base de datos deduce de los datos el registro lógico pedido por el

programa de aplicación, este ejecuta todas las transformaciones que

sean necesarias entre los datos tal como están declarados en el sub-

esquema y los datos tal como están declarados en el esquema.

• El sistema de administración transfiere los datos desde los almacenes

intermedios al área de trabajo del programa de aplicación.

• El sistema de administración provee una información de estado al

programa de aplicación informándole sobre el resultado de su pedido,

inclusive cualquier posible indicación de error.

• El programa de aplicación puede ahora operar con los datos pedidos, los

que se hallan en su área de trabajo.

2.2.15. Administrador de Base de Datos

El administrador de base de datos (DBA) es la persona responsable

de los aspectos ambientales de una base de datos. En general esto incluye:

28

• Recuperabilidad - Crear y probar respaldos. Significa que, si se da algún

error en los datos, hay un bug de programa ó de hardware que permite

traer de vuelta la base de datos al tiempo y estado en que se encontraba,

en estado consistente antes de que el daño se causara. Las actividades

de recuperación incluyen el hacer respaldos de la base de datos y

almacenar esos respaldos de manera que se minimice el riesgo de daño

ó pérdida de los mismos, tales como hacer diversas copias en medios de

almacenamiento removibles y almacenarlos fuera del área en antelación

a un desastre anticipado.

• Integridad - Verificar o ayudar a la verificación en la integridad de datos.

Significa que, la base de datos ó los programas que generaron su

contenido, incorporen métodos que aseguren que el contenido de los

datos del sistema no se rompan así como las reglas del negocio.

• Seguridad - Definir y/o implementar controles de acceso a los datos. Es

decir, es la capacidad de los usuarios para acceder y cambiar los datos

de acuerdo a las políticas del negocio, así como, las decisiones de los

encargados.

• Disponibilidad - Asegurarse del mayor tiempo de encendido. Significa

que los usuarios autorizados tengan acceso a los datos cuando lo

requieran para atender a las necesidades del negocio.

• Desempeño - Asegurarse del máximo desempeño incluso con las

limitaciones, impidiendo dar respuestas en tiempos poco razonables.

• Desarrollo y soporte a pruebas - Ayudar a los programadores e

ingenieros a utilizar eficientemente la base de datos. Las actividades de

soporte incluyen la colecta de datos de producción para llevar a cabo

pruebas con ellos; consultar a los programadores respecto al

desempeño; y hacer cambios a los diseños de tablas de manera que se

puedan proporcionar nuevos tipos de almacenamientos para las

funciones de los programas. (Tomado de Date C 2001, pág. 436).

29

2.2.16. Página Web

Es un documento electrónico que contiene información específica de

un tema determinado, se presenta generalmente en formato HTML

(HyperText Markup Language), es accesible gracias a un navegador, son

solicitadas y transferidas por los servidores usando el protocolo de

transferencia de hipertexto (HTTP Hypertext Transfer Protocol), es

almacenado en un computador que se encuentra enlazado a la red mundial

de información denominada internet, de forma que este documento pueda

ser visitado desde cualquier usuario que esté conectado en esta red mundial

de comunicaciones y que cuente con la permisología adecuada.

Como señala Weinman, L Weinman, W. (2002): “HTML, significa

Lenguaje de Marcación de Hipertexto. Es el leguaje en el que están escritas

y diseñadas las páginas Web, aunque la idea de llamar lenguaje de diseño a

HTML, consternaría a la mayoría de los diseñadores y esa no es

precisamente la idea: HTML no se escribió para ser un lenguaje de diseño.

Se hizo para ser un lenguaje de presentación, con la interacción de que

pudiera mostrarse de manera diferentes en distintos equipos y sistemas

operativos”.

Como señala Berzal, F. Cubero, J & Cortijo, F. (2007): “El protocolo

HTTP [HyperText Transfer Protocol] es un protocolo simple de tipo solicitud-

respuesta incluido dentro de la familia de protocolos TCP/IP que se utiliza en

Internet. Esto quiere decir, cada vez que accedemos a una página (en

general, a un recurso accesible de HTTP), se establece una conexión

diferente e independiente de las anteriores”.

30

2.2.17. Elementos de una Página Web

El contenido de las páginas web puede ser visto y/o escuchado por el

usuario final, estos elementos pueden ser:

• Texto, el texto detalla la información básica en aspectos definidos, se

muestra en algún tipo de fuente que el usuario posea en su computador.

• Imágenes, son archivos alojados a los archivos de pagina, de forma

independiente, y se presentan generalmente en los formatos: GIF, JPG y

PNG.

• Audio, es una característica particular, y se presentan generalmente en

los formatos: MIDI, WAV y MP3.

• Otros elementos dinámicos como Flash, de software propietario Adobe,

gráficas vectoriales según sea la página (SVG – Scalable Vector

Graphics), hipervínculos, vínculos y marcadores.

Las páginas web también pueden poseer contenido específico

desarrollado, que puede ser interpretado por el navegador y generalmente no

es apreciado por el usuario final tales como script, meta tags y hojas de estilo

en cascada o CSS.

Como señala Weinman, L. Weinman, W. (2002): “Una hoja de estilo es

un conjunto de plantillas, o estilos, que se aplican a varias partes de su

documento y describen la forma en que se presentan. Las hojas de estilo han

estado disponibles desde hace bastante tiempo en todos los procesadores

de texto principales”.

2.2.18. Apache

Es un servidor bajo el protocolo http, es de software libre, de código

abierto para diferentes plataformas tales como UNIX, Windows, Macintosh

31

entre otras, su desarrollo inició en 1995 y se basó principalmente en el

código popular NCSA HTTP, pero luego fue reescrito por completo. Su

nombre se debe a su creador que planteó la idea como una connotación de

algo que fuese firme y enérgico pero no agresivo, y la tribu apache fue la

última en rendirse al que pronto sería el gobierno de los Estados Unidos de

América.

El servidor Apache se desarrolla dentro del proyecto HTTP Server

(httpd) de la Apache Software Foundation.

Apache presenta entre otras características mensajes de error

altamente configurables, bases de datos de autenticación y negociado de

contenido. Apache tiene amplia aceptación en la red: desde 1996, es el

servidor más usado.

La mayoría de las vulnerabilidades de la seguridad descubiertas y

resueltas tan sólo pueden ser aprovechadas por usuarios locales y no

remotamente. Sin embargo, algunas se pueden accionar remotamente en

ciertas situaciones, o explotar por los usuarios locales malévolos en las

disposiciones de recibimiento compartidas que utilizan PHP como módulo de

Apache.

Ventajas

- Modular.

- Multi-plataforma.

- Extensible.

- Popular (fácil conseguir ayuda/soporte).

- Gratuito.

Como señala Cobo & Gómez (2005): “El servidor Apache,

desarrollado por más de cien desarrolladores voluntarios del proyecto

Apache, gestionando por la Fundación Apache, The Apache Software

Foundation , es el servidor web más utilizado en el mundo y esto es debido a

32

sus características: robustez, rapidez, multiplataforma con versiones para

Linux, Win32, MacOS, Unix, modularizable, dispone de módulos para

ejecutar PHP, Perl, etc”.

2.2.19. PHP

Es un lenguaje de programación interpretado, diseñado originalmente

para la creación de páginas web dinámicas. Es usado principalmente en

interpretación del lado del servidor pero actualmente puede ser utilizado

desde una interfaz de línea de comandos o en la creación de otros tipos de

programas incluyendo aplicaciones con interfaz gráfica.

PHP es un acrónimo recursivo que significa PHP Hypertext Preta re-

processor. Fue creado originalmente por Rasmus Lerdof en 1994; sin

embargo la implementación principal de PHP es producida ahora por The

PHP Group y sirve como el estándar de facto para PHP al no haber una

especificación formal.

Publicado bajo la PHP License, la Free Software Foundation considera

esta licencia como software libre.

PHP es un lenguaje interpretado de propósito general ampliamente

usado y que está diseñado especialmente para desarrollo web y puede ser

embebido dentro de código HTML. Generalmente se ejecuta en un servidor

web, tomando el código en PHP como su entrada y creando páginas web

como salida. Puede ser desplegado en la mayoría de los servidores web y en

casi todos los sistemas operativos y plataformas sin costo alguno.

33

CAPÍTULO III

MARCO METODOLÓGICO

En este capítulo se hará referencia a las estrategias que asume el

investigador para dar respuesta al problema planteado, contribuyendo en el

logro de los objetivos propuesto en la investigación. Para ello se describirán

el tipo y nivel de investigaciones utilizadas, la población así como las

técnicas e instrumentos de recolección de información.

3.1. Tipo de Investigación

La presente investigación es por su diseño de campo, por su nivel

descriptiva, y según su objeto de estudio es aplicada permitiendo buscarle

una solución al problema existente (Arias, F. 2004). Específicamente a los

procedimientos manejados en la Gerencia de recaudación de la empresa

TRANSBOLIVAR C.A, con la finalidad de desarrollar un sistema de

automatización que permita la simplificación, reducción de errores y

exactitud de cada procedimiento.

3.2. Población y Muestra

La población que será tomada como objeto de estudio para el

cumplimiento de los objetivos propuestos en la investigación está constituida

por los trabajadores que laboran en la Gerencia de Recaudación de Empresa

TRANSBOLIVAR C.A.

34

3.3. Técnicas e Instrumentos de recolección de dato s e información

Para la obtención de la información recopilada de la presente

investigación se utilizaron las siguientes técnicas e instrumentos:

• Entrevista Semi-estructurada. Se elaboró una guía con preguntas

relacionas al tema de interés en este caso los procedimientos llevados en la

Gerencia de Recaudación, en ella se formularon preguntas libres que

permitieron establecer los requerimientos y necesidades de los usuarios

entrevistados. En el Anexo Nº 04 y 05 se muestran los principales puntos que

se destacaron en las entrevistas realizadas y las personas entrevistadas.

• Observación directa. El investigador formó parte del grupo de trabajo a

fin visualizar atentamente los procesos llevados a cabo en la Gerencia de

Recaudación.

• Mesas de Trabajo. Se establecieron reuniones tanto con miembros de

la Gerencia de Recaudación como los desarrolladores a fin de delimitar el

alcance del software a diseñar, determinar los requerimientos funcionales

necesarios para su ejecución, responder y emitir sugerencias de cómo

debería ser la herramienta a diseñar así como recopilar información de las

herramientas existentes y aplicadas en sus operaciones. En el Anexo Nº 06

se muestra la agenda pautada para la realización de las mesas de trabajo.

Como instrumento de recolección de información será utilizó una

libreta de notas, así como una carpeta para archivar formatos/reportes

existente.

35

3.4. Modelo del proceso del software basado en Desa rrollo en Espiral

A continuación se referirá la representación de los procesos del

software a diseñar, permitiendo de esta manera mostrar información parcial

de cada uno de ellos. En este caso en particular según la metodología

empleada la investigación se llevara a cabo por medio del desarrollo en

espiral ya que la evolución del mismo estará determinada por cada una de

las fases que integraran su diseño. A continuación se presentan las

descripciones de cada una de las fases señaladas en el Gráfico Nº 04

propuestas por Ian Sommerville:

Gráfico Nº 04. Modelo del Proceso del Software Basado en Desarrollo Espiral: (Sommervill, I. 2007).

36

3.4.1. Obtención y Análisis de requerimientos.

En esta etapa se señalan cada uno de los objetivos que contendrá la

evolución del proyecto; así como el alcance, la viabilidad del mismo y demás

información relacionada con él. Por consiguiente se presentan a continuación

las secciones que integran la ingeniería de requerimientos:

• Ámbito. Se indicará en donde se va a desempeñar el sistema,

el objetivo de la investigación, para que usuarios va dirigido el desarrollo, así

como su funcionalidad.

• Vialidad. Demostrará si el desarrollo del sistema es factible o no

para la organización cumpliendo con la viabilidad técnica, económica y

operativa.

• Obtención y Análisis de requerimientos. Se recabará la

información a partir de las consultas realizadas a los usuarios.

• Especificación de Requerimientos. Se extraen los

requerimientos necesarios para la implementación del proyecto, tanto

funcionales como no funcionales.

• Descomposición del Proyecto. El sistema será descompuesto

en pequeños módulos a fin de simplificar su diseño.

• Plan de Actividades. Se realizará la planificación de cómo será

llevado a cabo el desarrollo del sistema.

3.4.2. Análisis y Gestión de Riesgos.

En esta etapa se analizan los posibles riesgos del proyecto así como

los pasos que podrían incurrir en la disminución de los mismos. Para ello se

realizará una tabla de identificación, una de priorización de los mismos y el

plan de reducción, supervisión y gestión de los riesgos (RSGS).

37

3.4.3. Diseño y Programación.

Se mostraran gráficamente como se encontrará descompuesto el

sistema, cumpliendo con los requisitos de los usuarios.

3.4.4. Evaluación del Cliente.

El cliente evaluará la representación del software creada durante la

etapa de diseño y programación.

38

CAPÍTULO IV

PRESENTACIÓN Y ANÁLISIS DE LOS RESULTADOS

Para el cumplimiento de los objetivos propuestos en el proyecto se ha

dado continuidad al desarrollo de un sistema administrativo que facilite el

control de los recursos de la Gerencia de Recaudación de la Empresa de

Transporte Público del Estado Bolívar.

Previamente al desarrollo de un sistema es necesario plantearse una

metodología por la cual regirse, de manera que sea mas manejable la

ejecución del proyecto. A continuación se mostrarán los pasos llevados a

cabo de acuerdo al modelo del proceso del software basado en un Desarrollo

en Espiral.

4.1. Ámbito.

El proyecto consiste en el desarrollo de un sistema administrativo que

sirva de apoyo en las actividades diarias de la Gerencia de Recaudación de

TRANSBOLIVAR C.A, dicha herramienta ha sido denominada como Sistema

Administrativo de Boletería, Servicios Especiales y Recepción de Valores

(SABSERV), el cual recabará toda la información generada por cada

recepción de ingresos emitida por los operadores de las unidades de

transporte público de la empresa, contabilizará y facilitará el control de la

principal fuente de ingreso de la misma, brindando un mayor grado de

seguridad y confiabilidad de los datos.

39

El Software estará diseñado para tres (03) tipos de usuarios con

privilegios diferentes de acuerdo a los requerimientos especificados por el

cliente. SABSERV será desarrollado única y exclusivamente con

funcionalidades de recaudar, emitir reportes y generar arqueos diarios de

caja, delimitando de esta manera su uso para la Gerencia de Recaudación.

4.2. Viabilidad

Permite determinar si el desarrollo del sistema es factible para la

organización tanto monetaria como en tiempo de respuesta, para ello se

deben abordar tres (3) aspectos fundamentales:

4.2.1. Viabilidad Técnica. SABSERV es un sistema

administrativo que tiene como principal objetivo llevar el control de los

recursos existentes en la Gerencia de Recaudación, para su desarrollo se

cuenta con las herramientas necesarias permitiendo que su ejecución sea

efectiva, entre ellas se pueden mencionar maquinas locales (laptop o de

escritorio), así como el servidor que contendrá todo el sistema.

El desarrollo se llevará a cabo bajo software libre y lenguaje de

programación web (php, html, javascript, jquery), utilizando como manejador

de bases de datos PostgreSQL. Según lo anterior, se puede determinar que

el proyecto cumple técnicamente con una de las fases de requerimientos

primordiales, permitiendo de esta manera dar antesala a la evaluación de los

demás términos necesarios para la aceptación de la puesta en marcha del

desarrollo de SABSERV.

4.2.2. Viabilidad Económica. Para el desarrollo del sistema se

cuenta con los equipos necesarios (hardware) y las herramientas (software)

distribuidas libremente, los horarios de trabajo serán ajustados a las jornadas

laborales de lunes a viernes, tanto para el desarrollador como para los

usuarios directos en este caso el personal de la Gerencia de Recaudación, el

40

costo del desarrollo es considerado como una bonificación emitida por

cumplimiento de proyecto de pasantía a nivel de ingeniería en la mención de

informática.

Considerando que los costos que genera la puesta en marcha del

desarrollo del sistema son bajos se puede deducir que su implementación es

viable económicamente.

4.2.3. Viabilidad Operacional. El personal que operará en el

sistema adscrito a la Gerencia de Recaudación, cuenta con los

conocimientos, experiencia y la pro-actividad necesaria para usar este nuevo

sistema, ya que han asumido la incorporación de la nueva herramienta

computacional como gran apoyo a la consecución de sus actividades diarias

y operativas. Adicional a esto, el sistema estará disponible en los diferentes

equipos de los usuarios a través de la infraestructura de red de la empresa y

ofrecerá una interfaz gráfica muy flexible que facilitará la manipulación del

mismo. Esto nos permite concluir que SABSERV es un sistema

operacionalmente viable.

4.3. Obtención y Análisis de Requerimientos.

El proceso de recaudación viene formulado por una serie de

requerimientos de entrada y de salida que han sido desglosados con el fin de

buscar la manera de diseñar el sistema administrativo.

4.3.1. Requerimientos de Entrada.

• Datos del Personal. Es la información que debe ingresar el

usuario del sistema al momento de entrar en su cuenta: nick y clave.

• Datos del Operador. Se refiere a la información que suministra

el operador de la unidad de transporte al momento de llegar a la Gerencia

41

de Recaudación con los valores recolectados en su turno, como hora de

llegada, ciclos de recorrido, ruta, nombre, número de unidad.

4.3.2. Requerimientos de Salida

• Cuenta. Dependiendo del usuario ingresado se mostrarán una

serie de módulos de acuerdo a los permisos que este posea, (misma

interfaz, cantidad de módulos variantes).

• Recibo. Al realizar una recepción de valor se generará un recibo

de la misma con copia que serán entregados uno (1) al operador y el otro

como respaldo.

• Reportes. De acuerdo a las necesidades del usuario se

generarán reportes con la información requerida.

4.4. Especificación de Requerimientos.

La obtención de los requerimientos necesarios para la implementación

del proyecto han sido desglosados en dos (2) tipos, los cuales son los

requerimientos funcionales, o propios del usuario y los no funcionales o del

sistema.

4.4.1. Requerimientos funcionales.

4.4.1.1. Interfaz de usuario. Facilita el uso y manejo del sistema.

Los perfiles de personales, permitirán registrar los diferentes usuarios que

tendrán acceso al sistema estos se dividen en tres (3) niveles:

• Analista. Este usuario tendrá acceso a ingresar las recepciones

de valores emitidas por cada operador (chofer), diariamente, así como

imprimir el recibo de la recepción.

42

• Supervisor. Tendrá permiso para realizar recepciones de

valores, así como visualizar e imprimir los reportes diarios, por operador, por

turno.

• Administrador. Este usuario tendrá todos los privilegios, no solo

de realizar las funcionalidades del usuario supervisor sino que también podrá

anular recepciones, visualizar e imprimir reportes semanales, mensuales, y

administrar los usuarios que tendrán acceso al sistema como tal.

4.4.1.2. Recepción de valores. El usuario tendrá la disponibilidad

de ingresar al sistema el total recaudado de cada operador en su jornada

laboral diaria, este formulario contará con los atributos de desglose de

valores (cantidad monedas, cantidad billetes, cantidad de ticket

estudiantiles), ruta recorrida, datos del operador, tiempo del recorrido (ciclos),

fecha y horas. Este reporte se podrá imprimir, anular, modificar, consultar.

4.4.1.3. Reportes. Una vez ingresadas las recepciones de valores

tanto el administrador como el supervisor tendrán la disponibilidad de

generar e imprimir los reportes que totalicen las recaudaciones de acuerdo a

una serie de criterios bien sea por operadores-rango de fecha (un operador y

una fecha delimitada), turno-rango de fecha (puede ser turno A o B en una

fecha delimitada), diario (total recaudado en un día tanto del turno A como el

B), semanal (total recaudado en el turno A o B en una semana en

especifico), mensual (total recaudado en el turno A y/o B en un mes en

especifico) se conoce como turno A la comprendida entre el horario de 5am a

1pm y turno B de 11pm a 7pm.

4.4.1.4. Arqueo de caja. Una vez finalizada las recepciones

diarias el usuario administrador tendrá la disponibilidad de obtener un reporte

con las totalizaciones de monedas, billetes y ticket estudiantiles que deben

estar recaudados a fin de contabilizar y certificar su correcta recepción.

43

4.4.2. Requerimientos no funcionales.

4.4.2.1. Seguridad. El sistema debe garantizarle a los usuarios

seguridad absoluta al momento de realizar las recepciones de valores así

como los reportes, el arqueo de caja y que la información suministrada sea

fiable. A su vez la información ingresada debe ser almacenada de manera

correcta a fin de que las consultas resultantes sean las pertinentes.

4.4.2.2. Disponibilidad. SABSERV deber ser soportado por

mínimo requerimiento bajo Linux y Windows y por los principales

navegadores utilizados en la empresa.

4.4.2.3. Escalabilidad. SABSERV debe ser diseñado de manera

que se puedan agregar nuevas funcionalidades para mayor comodidad de

los usuarios, en futuro se tiene pensado anexar los módulos de boletería y

servicios especiales de transporte.

4.4.2.4. Límites. La información será suministrada bajo el idioma

español, y el software será utilizado únicamente por la Gerencia de

Recaudación de la empresa TRANSBOLIVAR, C.A.

4.4.2.5. Mantenibilidad. SABSERV permitirá la realización de

mantenimientos correctivos o de mejora con la finalidad de minimizar errores

y mantener el sistema actualizado.

4.4.2.6. Facilidad de uso. El sistema será desarrollado con una

interfaz sencilla y agradable al usuario a fin de que su uso sea entendible,

facilitando encontrar la información necesaria.

44

4.5. Descomposición del Problema.

El proyecto será descompuesto en pequeños subsistemas con la

finalidad de afrontar su diseño de manera más sencilla y que este sea más

manejable.

4.5.1. Módulo de administración de usuario. Este módulo le permitirá

al administrador de SABSERV las siguientes funciones:

Ingresar personal de la Gerencia de Recaudación.

Ingresar, modificar y eliminar operadores (choferes) de la empresa.

Ingresar, modificar y eliminar usuarios con acceso al sistema.

4.5.2. Módulo de recaudación. Este módulo contendrá los siguientes

aspectos:

Ingreso de la recepción de valores.

Consultar recepción de valores existentes.

Modificar recepción de valores existentes.

Reportes. Permitirá generar los siguientes reportes: Por operador, por

turno, diario, semanal, mensual.

4.5.3. Módulo de cierre laboral. En este módulo el administrador del

sistema podrá realizar las siguientes actividades: Arqueo de caja diario,

reporte de cierre diario.

4.6. Plan de Actividades.

A continuación se muestra en que periodos de tiempos serán

realizados las fases de ejecución del proyecto. Este se ve plasmado en la

Tabla Nº 01.

45

ACTIVIDADES SEMANAS

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Levantamiento de

Información

X X

Análisis de la

Información y/o

Sistema

X X

Diseño del

Sistema

X X X

Codificación del

Sistema

X X X X X X X

Pruebas

Funcionales

X X X X X X

2.1. Análisis y Gestión de Riesgos. En esta etapa se analizan los

posibles riesgos del proyecto así como los pasos que podrían incurrir

en la disminución de los mismos. A continuación en la Tabla Nº 02 se

mostraran los posibles riesgos que incurrirían en el fracaso de la

realización del proyecto.

Tabla de identificación de riesgos

Riesgo Categoría Probabilidad Impacto

Entender los requisitos. ST 35% 1

El cliente cambiará los requisitos PS 40% 1

Asignación de tareas al personal. ST 10% 3

Tabla Nº 01. Plan de Actividades: el Autor.

46

Complicaciones de implementación

y/o diseño.

ST 35% 2

Problemas para completarlo a tiempo. PS 45% 2

Fecha de entrega muy ajustada. BU 30% 2

Falta de formación en las

herramientas

DE 25% 2

ST: experiencia técnica del desarrollador. PS: tamaño del software que se quiere

BU: riesgo del negocio. 1: catastrófico 2: critico 3: marginal.

Priorización de los riesgos

De acuerdo con la mayor probabilidad de que suceda un riesgo y seguido del

impacto del mismo en el desarrollo del proyecto se muestra en la Tabla Nº 03

la priorización de ellos.

Riesgo Categoría Probabilidad Impacto

Problemas para completarlo a tiempo. PS 45% 2

El cliente cambiará los requerimientos PS 40% 1

Entender los requisitos. ST 35% 1

Complicaciones de implementación

y/o diseño.

ST 35% 2

LINEA DE CORTE

Fecha de entrega muy ajustada. BU 30% 2

Tabla Nº 02. Tabla de Identificación de Riesgos: el Autor.

47

Falta de formación en las

herramientas.

DE 25% 2

Asignación de tareas al personal. ST 10% 3

Plan de reducción, supervisión y gestión de riesgo (RSGS)

• Problemas para completarlo a tiempo. En la tabla Nº 04 se muestra el

motivo de considerarse este problema como un factor de riesgo.

Fecha:04/01/2011 Probabilidad=45% Impacto=Medio

Descripción:

Se concluye que existe una probabilidad del 45% de que el proyecto tendrá

problemas para ser completado a tiempo, por lo tanto su entrega cumplirá

con los requerimientos mínimos solicitados.

Refinamiento/Contexto:

Sub-condición 1: La definición de cada uno de los procesos que son llevados

a cabo en la Gerencia de Recaudación no tienen una definición concreta,

impidiendo de esta manera la recolección de información correcta para el

diseño y codificación del sistema.

Sub-condición 2: Existe un nivel de incertidumbre del lado del solicitante del

desarrollo del software impidiendo de esta manera estructurar que es lo que

se desea hacer.

Sub-condición 3: La etapa de levantamiento de información suele requerir

más tiempo de lo regular, con la existencia de nuevos requerimientos en el

Tabla Nº 03. Tabla de Priorización: el Autor.

48

transcurrir del desarrollo.

Reducción:

1. Crear mesas de trabajo que contribuyan a la creación de unos

procesos estables que identifiquen las actividades realizadas en la Gerencia

a fin de recabar información vital para el desarrollo del software.

2. Contactar al cliente y discutir cuales son los requerimientos

funcionales prioritarios con los que debe cumplir el software, tomando en

consideración las actividades diarias realizadas en la Gerencia.

3. Una vez definidos correctamente los procesos de la Gerencia se

debería levantar la información requerida con mayor facilidad, previniendo de

esta manera la aparición de nuevos requerimientos.

Gestión/plan de Contingencia/Acción:

El desarrollador irá creando los módulos asignados por el gestor del

proyecto, una vez finalizados irá integrando las partes funcionales

correspondientes, a fin de ir evaluando su desempeño. Descartando el

incumplimiento total de la planificación estipulada.

Estado Actual:

07/01/2011 Fases de reducción iniciadas.

Tabla Nº 04. Tabla RSGS 01: el Autor.

49

• El cliente cambiará los requerimientos. En la Tabla Nº 05 se indican

las razones de considerar esta opción como un factor de riesgo.

Fecha:04/01/2011 Probabilidad=40% Impacto=Alto

Descripción:

Se concluye que existe una probabilidad del 40% de que el proyecto sufra modificaciones debido al cambio de requerimientos exigidos por el cliente, impidiendo de esta manera el cumplimento de la planificación planteada.

Refinamiento/Contexto:

Sub-condición 1: La Gerencia de Recaudación no cumple con unos procesos definidos y normalizados por ende estos sufren modificación a medida de que se presenten las necesidades.

Sub-condición 2: El cliente no posee una idea clara de cuáles son los pasos que deben llevar a cabo para el cumplir con los procesos existentes en la Gerencia de Recaudación.

Reducción:

1. La Gerencia de Recaudación conjuntamente con el desarrollador deberán definir cuáles son las labores vitales que realizan la misma a fin de estructurar todos y cada una de las actividades llevadas a cabo en ella. 2. La puesta en marcha de la definición de los procesos permitirá al cliente tener una idea más clara de cómo manejar el trabajo que se genere día a día. 3. Conjuntamente con la estandarización de los procesos se debe llevar la recolección de información necesaria para el desarrollo del sistema. Gestión/plan de Contingencia/Acción:

Antes de la fase de diseño el desarrollador debe tener claro cuáles son las acciones que debe generar para el cumplimiento satisfactorio del diseño y codificación del software para ello debe recabar la información correcta y que se encuentre totalmente estandariza evitando de esta manera la modificación o inserción de nuevos requerimientos. De llegar a presentarse este inconveniente es

50

recomendable para el desarrollo del sistema realizar nuevamente el estudio de los parámetros que se cumplen en el proceso de recaudación a fin de verificar si existe algún otro paso omitido, contribuyendo así al buen uso del tiempo estimado en la planificación.

Estado Actual:

04/01/2011 Fases de reducción iniciadas.

4.8. Diseño y Programación.

De acuerdo con los requerimientos suministrados por los usuarios

de la Gerencia de Recaudación se inicia el modelado del diseño, utilizado en

la puesta en marcha del desarrollo del sistema. Para el cumplimiento de las

características presentes en el modelo del proceso en espiral este será

entregado por fases en periodos de tiempos diferentes. A continuación se

mostrarán los modelados utilizados para el análisis de la información

recabada.

Tabla Nº 05. Tabla RSGS 02: el Autor.

51

4.8.1. Modelado Funcional y de Flujo de Información .

• Diagrama de Flujo de Datos DFD . Al analizar los procesos realizados

en la Gerencia de Recaudación, se detectaron aquellos requerimientos de

entrada y de salida existentes, de esta información se diseño el diagrama de

contexto mostrado en el Gráfico Nº 05.

Usuario 0

SABSERV

Usuario

Datos Personal

Reportes

Gráfico Nº 05. DFD Diagrama de Contexto: el Autor

Usuario Operador

Datos Operador

Recibo

Diagrama de Contexto

52

4.8.2. Modelado de Datos.

• Diagrama de Entidad de Relación DER . Para el modelado de la

base de datos fue necesaria la creación de un DER que permitiera ver las

relaciones entre las entidades que la conformarían, en el Gráfico Nº 06 se

muestra el resultado obtenido.

Gráfico Nº 06. Diagrama de Entidad de Relación: el Autor

53

• Modelo Relacional. Es un modelo que permite visualizar las

relaciones entre el conjunto de datos que serán almacenados. Ver Gráfico

07.

Gráfico Nº 07. Modelo Relacional: el Autor

54

• Diccionario de Datos . Aquí se identifican los atributos existentes en

cada entidad con sus tipos de datos.

Nombre de la Tabla: Cargo

Descripción: Se almacenaran todos los datos del personal que labora

en la Gerencia de Recaudación.(Ver Tabla 06).

Nombre Descripción Tipo

Nombre_personal El nombre del analista, supervisor, asistente, subgerente o gerente

Varchar

Apellido_personal El apellido del analista, supervisor, subgerente o gerente.

Varchar

Cedula_personal La cedula del personal ingresado

Entero

Cargo_personal La ocupación que desempeña en la gerencia

Varchar

Ficha El numero de la ficha que identifica al trabajador

Entero

Id_personal El identificador del registro

Incremental

Id_estado Identifica si el personal se encuentra activo o inactivo

integer

Tabla Nº 06. Tabla Cargo: el Autor.

55

Nombre de la Tabla: Estado

Descripción: Se asignan y describen los diferentes estatus que

poseerá el sistema.(Ver Tabla 07).


Id_estado Identificador del registro Entero

Nombre Se muestra los tipos de estados que podrían existir

varchar

Nombre de la Tabla: Entrega-Recepción –Valores-Vial

Descripción: En esta tabla se almacenará la cabecera del formulario

de recepción de Valores.(Ver Tabla 08).


Fecha Indica la fecha actual Fecha

Hora_entrega Muestra la hora en que fue entregada la recepción

Hora

Hora_salida Muestra la hora en que el operador salió del patio con la unidad

Hora

Hora_llegada Muestra la hora en que el operador finalizo su turno

Hora

Id_unidad Almacena el identificador de la unidad

Entero

Cant_ciclos Almacena la cantidad de ciclos Entero

Tabla Nº 07. Tabla Estado: el Autor.

56

realizados por el operador

Id_ruta Almacena el identificador de la ruta recorrida

Entero

Id_operador Almacena el identificador del operador que realiza la entrega de la recepción

Entero

Id_personal Almacena el identificador del personal de recaudación que realizo la recepción

Entero

Fecha_modificación Almacena la fecha en que en dado caso se haya realizado algún tipo de modificación a la recepción de valor

Fecha

Id_modificación Guarda el identificador de la persona que realizo la modificación

Entero

Id_estado Muestra en que estado se encuentra la recepción si activo o anulada

Entero

Observación Muestra algún tipo de observación hecha por el operador

Varchar

Id_entrega_recepcion_vial Es el identificador del registro Incremental

Id_recepcion_valores_vial Es el campo relación con la tabla que guarda los ingresos recibidos

entero

Tabla Nº 08. Tabla Entrega Recepción Valores Vial: el Autor.

57

Nombre de la Tabla: Nivel

Descripción: Se designan las permisologías que poseerá cada

usuario con acceso al sistema.(Ver Tabla 09).


Id_nivel Identificador del registro Entero

Descripción Señala el tipo de permisos existente varchar

Tipo Almacena los niveles numéricamente

entero

Nombre de la Tabla: Operador

Descripción: Se almacenan datos de los operadores o choferes que

laboran en la empresa.(Ver Tabla 10).


Nombre_operador Almacena el nombre del operador Varchar

Apellido_operador Almacena el apellido del operador Varchar

Cedula_operador Guarda la cedula del operador que se ingresó

Entero

Id_turno El identificador del turno que labora Entero

Id_tipo El identificador del tipo de operador al que pertenece

Entero

Ficha el numero de ficha que posee el operador

entero

Id_estado Indica el estado que se encuentra el Entero

Tabla Nº 09. Tabla Nivel: el Autor.

58

operador si activo o inactivo

Id_operador El identificador del registro Entero

Nombre de la Tabla: Ruta

Descripción: Se describen todas las rutas que cubren las unidades

operativas. (Ver Tabla 11).


Nombre_ruta Almacena el código de las rutas existentes

Varchar

Id_ruta El identificador de la ruta Entero

Tipo_ruta Identifica el tipo de ruta que cubre urbana o inter-urbana

Entero

Descripción Almacena el nombre de las rutas que cubre

Varchar

Tabla Nº 10. Tabla Operador: el Autor.

Tabla Nº 11. Tabla Ruta: el Autor.

59

Nombre de la Tabla: Tipo-Operador

Descripción: se describen los tipos de operadores existentes

dependiendo de la ruta que cubra.(Ver Tabla 12).


Nombre Almacena el nombre del tipo de operador de acuerdo a las rutas que cubre

Varchar

Id_tipo El identificador del tipo de operador Entero

Descripción Almacena una descripción de los tipos de operadores existentes

Varchar

Nombre de la Tabla: Turno

Descripción: se describen los diferentes turnos que cubren los

operadores.(Ver Tabla 13).


Nombre Almacena el nombre de los tipos de turnos existentes

Varchar

Id_turno El identificador del tipo de turno Entero

Descripción Almacena una descripción de los tipos de turnos existentes

Varchar

Tabla Nº 12. Tabla Tipo-Operador: el Autor.

Tabla Nº 13. Tabla Turno: el Autor.

60

Nombre de la Tabla: Recepción-Valores-Viales

Descripción: en esta tabla se almacenan todos los datos monetarios

de cada recepción generada en la gerencia.(Ver Tabla 14).


Correlativo Guarda el correlativo de cada recepción de valor

entero

Cien_bill Almacena la cantidad de billetes recibidos del operador

Hora

Cincuenta_bill Almacena la cantidad de billetes recibidos del operador

Hora

Veinte_bill Almacena la cantidad de billetes recibidos del operador

Hora

Diez_bill Almacena la cantidad de billetes recibidos del operador

Entero

Cinco_bill Almacena la cantidad de billetes recibidos del operador

Entero

Dos_bill Almacena la cantidad de billetes recibidos del operador

Entero

Uno_mon Almacena la cantidad de monedas recibidos del operador

Entero

Cincuenta_mon Almacena la cantidad de monedas recibidos del operador

Entero

Veinticinco_mon Almacena la cantidad de monedas recibidos del operador

Entero

Ciento_veinticinco_mon

Almacena la cantidad de monedas recibidos del operador

Entero

Diez_mon Almacena la cantidad de monedas Entero

61

recibidos del operador

Cinco_mon Almacena la cantidad de monedas recibidos del operador

Entero

Cant_ticket_estud Guarda la cantidad de ticket estudiantiles recaudados

Entero

Valor_ticket_estud Guarda el valor actual del ticket estudiantil Entero

Id_unidad Identificador de la unidad recaudada Entero

Total_efectivo Guarda el total recaudado en billetes mas monedas

Real

Total_monedas Guarda el total de monedas recaudado Real

Total_billetes Guarda el total de billetes recaudado Real

Total_valores Guarda el total recaudado por el operador Real

Cant_ticket_vencid Guarda la cantidad de ticket entregados ya vencidos

Entero

Id_turno Almacena el identificador del turno en que se recaudo

Entero

Id_operador Almacena el identificador del operador que realiza la entrega de la recepción

Entero

Id_personal Almacena el identificador del personal de recaudación que realizo la recepción

Entero

Id_recepcion_valores_vial

El identificador del registro Entero

Tabla Nº 14. Tabla Recepción-Valores-Viales: el Autor.

62

Nombre de la Tabla: Unidad

Descripción: se ingresan todas las unidades existentes en la flota de

transportes de la empresa.(Ver Tabla 15).


Numero Guarda el numero de las unidades existentes

Entero

Id_unidad El identificador de cada unidad Entero

Descripción Almacena una descripción de los tipo de unidad.

Varchar

Nombre de la Tabla: Usuario

Descripción: se almacenarán a todos los usuarios que tendrán

acceso al sistema.(Ver Tabla 16).


Login Nombre del usuario varchar

Nivel Guarda el tipo de nivel que le fue asignado

entero

Clave Guarda la clave del usuario Varchar

Ficha Almacena el numero de la ficha del personal

Entero

Id_estado El identificador del estado en que se encuentra el usuario

Entero

Tabla Nº 15. Tabla Unidad: el Autor.

Tabla Nº 16. Tabla Usuario: el Autor

63

Nombre de la Tabla: Valores

Descripción: se almacenan los valores de los ticket-estudiantiles,

pasaje de casos especiales.(Ver Tabla 17).


Nombre Guarda el nombre en relación al concepto existente

Varchar

Id_nombre El identificador de cada valor Entero

Monto_valor Se asigna el valor de cada registro dependiendo del caso

Entero

Tabla Nº 17. Tabla Estado: el Autor.

64

4.8.3. Análisis Orientado a Objetos

• Diagrama de Casos de Uso. En el siguiente diagrama se mostrará

las funciones del sistema y como interactuan con el exterior. (Ver Gráfico 08).

Gráfico Nº 08. Funciones Generales: el Autor.

65

Leyenda de documentación del Caso de uso de las funciones generales del sistema propuesto, (Ver Tabla 18).

Caso de Uso: Funciones Generales

Actores: Administrador, Supervisor, Analista

Tipo: Flujo Generalizado

Propósito: Identificar los permisos de cada usuario que conforma el sistema administrativo.

Resumen: Se identifican las actividades a las cuales cada usuario tiene permiso, en el caso del Administrador este podrá controlar el acceso al sistema, generar reportes, modificar y anular recepciones, generar arqueos de caja. El supervisor tendrá permisos para generar y modificar recepciones, emitir algunos reportes mientras que el Analista solo podrá ingresar recepciones.

Precondiciones: Todo usuario debe estar previamente registrado en el sistema con su permisología asignada.

Flujo Principal: Designación del tipo de usuario

SubFlujos: (S-1) Almacenamiento de recepciones

Tabla Nº 18. Documentación de Caso de Uso: el Autor.

66

• Diagramas de Actividades.

Administrador (Nivel 1). En el diagrama de actividades del Administrador

se evidencia cuales son las acciones que este puede realizar, siendo

mostradas en el Gráfico Nº 09.

Gráfico Nº 09. Diagrama Actividad Nivel 1: el Autor.

67

Supervisor (Nivel 2). En el diagrama de actividad del supervisor se

visualizan los módulos a los cuales puede acceder. Ver Gráfico Nº 10.


68

Analista (Nivel 3). Se perciben las acciones que el analista puede

ejecutar, ver Gráfico Nº 11.


69

4.8.4. Modelado de Clases.

• Diagrama de Clases. En el Gráfico Nº 12 se presenta el modelado

de la estructura interna del sistema, las entidades, atributos y

relaciones entre cada clase.

Gráfico Nº 12. Diagrama de Clases: el Autor.

70

4.8.5. Modelado de Diseño.

• Diseño Arquitectónico. En el diseño arquitectónico presente en el

Grafico Nº 13 se identifica la descomposición del sistema en pequeños

módulos.

Gráfico Nº 13. Diseño Arquitectónico: el Autor.

71

• Diseño de Interfaz. El diseño de la interfaz esta compuesto por las

siguientes pantallas:

Pantalla de Inicio de Sesión .

En esta pantalla se mostrara el nombre del sistema así como los

campos necesarios para el acceso al sistema ente ellos el nombre del

usuario, la clave y la base de datos con que se desea trabajar como lo indica

el Gráfico Nº 14.

Descripción.

• Usuario. Aquí se deberá introducir el nombre del usuario que accederá

al sistema administrativo.

• Contraseña. Se ingresa la clave de dicho usuario.

1

2

3

4 Gráfico Nº 14. Inicio de Sesión: SABSERV

72

• Base de Datos. Se selecciona la base de datos donde se desea

trabajar al ingresar al sistema como tal.

Se toma en consideración que el usuario debe previamente poseer

una cuenta activa y con una permisología definida de lo contrario se

mostrará un mensaje de error.

Pantalla Principal.

La pantalla principal esta compuesta por un membrete de

identificación, una barra de menú y el área de trabajo para los usuarios. (Ver

Gráfico Nº 15).

1

3 2 4 5 6 7 8

Gráfico Nº 15. Página Principal: SABSERV

73

Descripción.

• Encabezado. Se identifica el logo de la empresa y del sistema y como

imagen ilustrativa las unidades de transporte pertenecientes a la

empresa.

• Inicio. El botón inicio retorna a la pantalla principal del sistema las

veces que el usuario lo desee.

• Usuario. Este módulo tiene como finalidad la administración de todos

los usuarios que estarán involucrados en el sistema tanto el personal de

recaudación así como los operadores de las unidades de transporte.

• Recaudación. En este módulo se encontrará el formulario de

recepción de valores a su vez los diversos reportes que se generan a

partir de este y las operaciones anexas que pueden aplicársele a la

recepción (consulta, modificación y anulación).

• Cierre Laboral. En este módulo se realiza el arqueo de caja de los

turnos y del día como tal a fin de cerciorar que lo recaudado físicamente

concuerde con lo que muestra el sistema.

El módulo 6 y 7 no forman parte del desarrollo de este proyecto.

• Salir. Este botón permite al usuario salir del sistema administrativo,

retornando la pantalla de inicio de sesión.

74

Módulo de administración de usuario.

En este módulo el usuario de Nivel 1, puede administrar a todo el

personal que será ingresado en el sistema bien sean operadores, así como

el personal interno de la Gerencia de Recaudación, las opciones pueden ser

vistas en el Gráfico Nº 16.

1

3

5

7

2

4

6

Gráfico Nº 16. Módulo de administración de usuario: SABSERV

75

1. Registrar personal.

Esta opción permite la inserción de todo el personal que labora en la

Gerencia de Recaudación, para el registro satisfactorio se deben agregar

todos los datos solicitados entre ellos los que serán mencionados a

continuación en el Gráfico Nº 17.

Descripción.

• Inicio. Te permite retornar a la página principal.

• Ficha. Se ingresa la ficha del personal que desea ingresar.

• Nombre. Se agrega el nombre de la persona a ingresar.

• Apellido. Se agrega el apellido de la persona a ingresar.

• Cedula. Se anexa la cedula del personal.

1

2

4

6

3

5

7 8

Gráfico Nº 17. Registro del Personal: SABSERV

76

• Cargo. Se selecciona el cargo que la persona ocupa en la Gerencia de

recaudación.

• Registrar. Con este botón se da concluida la inclusión del

personal en el sistema, como notificación aparecerá una ventana

informativa como la siguiente:

• Borrar. Permite limpiar los campos del formulario.

2. Registrar Nuevo Usuario.

Esta opción permite agregar a todos aquellos usuarios que tendrán

acceso al sistema administrativo cada uno con permisos definidos. (Ver

Gráfico Nº 18).

1

2

3

4

5

6

7 8 Gráfico Nº 18. Registrar nuevo usuario:

SABSERV

77

Descripción.

• Inicio. Este botón permite re-direccionar al menú principal.

• Ficha. Se ingresa la ficha del personal de la Gerencia de

Recaudación. Este debió ser agregado con antelación en el “registro de

personal”.

• Login. Se anexa el nombre que poseerá el usuario convenientemente

seria la inicial del nombre seguido de su apellido completo ej: “gramirez”.

• Clave. Se anexa la clave de acceso, esta no debe exceder de diez

(10) dígitos.

• Re-clave. Se introduce nuevamente la clave deseada a fin de verificar

su exactitud.

• Nivel. Se selecciona el nivel o la permisología que tendrá dicho

usuario.

• Registrar. Con este botón se da concluida la inclusión del

personal en el sistema, mostrando como resultado la siguiente ventanilla:

• Borrar. Permite limpiar los campos del formulario.

78

3. Modificar Usuario Existente.

Permite modificar la contraseña y la permisología del usuario

seleccionado como lo expresa el Gráfico Nº 19.

Descripción.

• Inicio. Este botón permite re-direccionar al menú principal.

• Login. Se agrega el login del usuario que deseas modificar y se

cliquea a fin de consultar la información requerida.

• Ficha. Se muestra la ficha del operador.

• Login. Se muestra el usuario.

• Clave. Se visualiza y modifica la información de la clave del usuario.

• Nivel. Se visualiza y modifica el nivel de acceso al sistema o

permisología del usuario.

1

2

3

5 4

6 7

Gráfico Nº 19. Modificar usuario existente: SABSERV

79

• Modificar. Al cliquear este botón se almacenaran las

modificaciones realizadas, se mostrará como ventana de verificación la

siguiente:

4. Eliminar Usuario Existente.

Permite inhabilitar un usuario en particular, se visualizará la

información del personal que se desee deshabilitar tal como muestra el

Gráfico Nº 20.

1

2

3

4

5

6

Gráfico Nº 21. Eliminar usuario existente: SABSERV

80

Descripción

• Inicio. Redirección al menú principal.

• Login. Se ingresa el login del usuario que será deshabilitado y se

cliquea para obtener la información de verificación de datos.

• Clave. Se visualiza la clave del usuario que será deshabilitado.

• Nivel. muestra el grado de permisología que posee el usuario.

• Eliminar. Este botón al ser cliqueado ejecutará la acción de

eliminar el usuario elegido, una vez realizada la operación aparecerá el

siguiente mensaje:

81

5. Registro de Operadores .

Este formulario permite ingresar los principales datos de los

operadores de las unidades de transporte. (Ver Gráfico Nº 21).

Descripción.

• Inicio. Re-direcciona a la página principal.

• Ficha. Se ingresa la ficha del operador.

• Nombre. Se agrega el nombre del operador.

• Apellido. Se agrega el apellido del operador.

• Cedula. Se anexa la cedula de identidad.

• Turno. Se anexa el turno al que pertenece el operador.

• Tipo. Se agrega qué tipo de servicio presta en la empresa.

1

2

4

6

3

5

8 9

7

Gráfico Nº 21. Registro de operador: SABSERV

82

• Registrar. Al seleccionar este botón se almacena todos los

datos del operador y se finaliza la operación. Una vez culminada la

operación se mostrará el siguiente mensaje:

• Borrar. Se limpian los campos del formulario.

6. Modificar Operador.

Permite actualizar o corregir los datos de algún operador en particular

como se muestra en la Gráfica Nº 22.

1

2

3 4

5 6

7

8

Gráfico Nº 22. Modificar operador: SABSERV

83

Descripción.

• Campo Texto. Se introduce la ficha del operador, para obtener sus

datos se cliquea .

• Ficha. Se visualiza la ficha del operador.

• Nombre. Se muestra el nombre del operador.

• Apellido. Se muestra el apellido del operador.

• Cedula. Se muestra la cedula del operador.

• Turno. Muestra el turno al que el operador pertenece.

• Tipo Operador. Muestra el tipo de servicio que presta en la empresa.

• Modificar. Al seleccionar el botón se realizan las respectivas

modificaciones al operador seleccionado y será visualizada la siguiente

ventana:

84

7. Eliminar Operador .

Esta opción permite deshabilitar a los operadores que ya no prestan

servicios en la empresa.

Descripción.

• Campo de Texto. Se ingresa la ficha del operador para cerciorar sus

datos y se cliquea .

• Ficha. Se mostrara la ficha del operador.

• Nombre. Se visualizará el nombre del operador.

• Apellido. Se visualizará el apellido del operador.

• Cedula. Se mostrará la cedula de identidad del operador.

• Turno. Se muestra el turno al que pertenece.

1

2 3

4 5

6 7

8 Gráfico Nº 23. Eliminar operador:

SABSERV

85

• Tipo de Operador. Se muestra el tipo de servicio que presta en la

empresa.

• Eliminar. Al cliquear este botón automáticamente será deshabilitado el

operador que se ha seleccionado y mostrado sus datos. Una vez

realizada la operación aparecerá el siguiente mensaje:

Módulo de Recaudación.

Este módulo permite la administración de lo referente a la recepción

de valores y a la generación de los reportes existentes. Se accederá a través

del menú por las pestañas señalas en el Gráfico Nº 24.

1

2

3

4

5

6

7

Gráfico Nº 24. Módulo de Recaudación: SABSERV

86

1. Recepción de Valores.

Este formulario permitirá a los usuarios de la Gerencia de

Recaudación recabar toda la información necesaria al momento de recibir el

ingreso diario de cada uno de los operadores que laboraron en la

empresa.(Ver Gráfico 25).

Descripción.

• Muestra el logo que representa a la empresa.

• Hora Salida. Se ingresa la hora que el operador partió a cumplir con

su jornada laboral.

1

9

10

11

12

13

14

15

16

18

2

3

4

5

6

7

8

17 19 20

Gráfico Nº 25. Recepción de valores: SABSERV

87

• Hora llegada. Se ingresa la hora en la que el operador entrego su

guardia y finalizó su jornada.

• Operador. Se selecciona el nombre del operador a recaudar.

• Nº de la Unidad. Se selecciona el número de la unidad en la que el

operador laboró.

• Cant. De Ciclos. Se selecciona la cantidad de ciclos que el operador

recorrió.

• Ruta Urbana. Se selecciona la ruta que el operador realizo su jornada.

• Observaciones. Se ingresan las observaciones del operador si fuese

el caso.

• Nº recepción. Se muestra el número correlativo de la recepción.

• Fecha. Muestra la fecha actual en que se está realizando la recepción.

• Hora. Muestra la hora actual en la que llego el operador a ser

recaudado.

• Turno. Se selecciona el turno en que se esta recaudando.

• Monto. Se muestra el monto total de lo recaudado dependiendo del

valor al que pertenezca.

• Cantidad. Se ingresa la cantidad de cada uno de los valores en sus

casillas correspondientes.

• Total Billetes. Muestra el total recaudado en billetes.

• Total Efectivo. Muestra el total recaudado tanto en billetes como en

monedas.

• Total Monedas. Muestra el total recaudado en monedas.

• Total Valores. Muestra el total recaudado tanto en efectivo como en

ticket estudiantiles.

• Registrar. Al cliquear esta opción aparecerá un mensaje de

verificación como se muestra a continuación:

88

al aceptar la condicion de la ventana se almacenará todos los datos

suministrados de la recaudación del operador y aparecerá el mensaje de

conformación como este:

• Borrar. Limpia los campos del formulario.

Al almacenar el registro de la recepción de valores aparecerá una pantalla

que permitirá la impresión del recibo de la recepción presente en el Gráfico

Nº 26.

Gráfico Nº 26. Recibo de la recepción de valor: SABSERV

89

2. Consultar Recepción.

Esta opción permite consultar aquellas recepciones que han sido

creadas o almacenadas. En esta se presentará la pantalla del Gráfico Nº

27.

1 2 3 4

5

Gráfico Nº 27. Consulta de recepciones: SABSERV

Gráfico Nº 28. Recepción de valor: SABSERV

90

Descripción.

• Ref. Indica el número de la recepción.

• Fecha. Muestra la fecha en que fue creada.

• Operador. Muestra el operador recaudado.

• Turno. El turno en que fue recaudado.

• Al cliquear la lupa se visualizará la recepción seleccionada como se

muestra en la imagen anterior.

3. Modificar Recepción.

Esta opción permite corregir errores encontrados en las recepciones

de valores almacenadas. La operación será exacta a la de la recepción de

valores sólo deben ingresar el número de la recepción que desea modificar y

cliquear . (Ver Gráfico 29).

91

4. Reportes .

Al desplegar la pestaña se reflejaran todos los tipos de reportes

que podrán generarse a partir de las recepciones de valores.

Reporte por turno.

En este reporte se mostraran todas aquellas recepciones

generadas en un día y turno específico, ingresando todos los datos

solicitados que se muestran en el Gráfico Nº 30.

1

2

3

Gráfico Nº 29. Modificar recepción: SABSERV

92

Descripción.

• Turno. Se ingresa el turno que desea visualizar.

• Fecha. Selecciona la fecha que desea que se haga la consulta a

través de

.

• Al cliquear se mostrará el reporte deseado, así como se muestra en

la imagen anterior.

• Imprimir. Muestra el reporte por turno con los datos deseados

que será impreso.

4

Gráfico Nº 30. Reporte turno: SABSERV

93

Reporte Impreso.

Al seleccionar la impresora se mostrará el formato señalado en el

Gráfico Nº 31 como resultado final de la consulta.

Descripción.

• Fecha. Se muestra la fecha del reporte que fue consultado.

• Turno. Muestra el turno al que pertenece el reporte.

• Hora. Muestra la hora en que se genero el reporte.

1

4

5

2

3

7

8

6

9

10

11

12

Gráfico Nº 31. Recibo de reporte turno: SABSERV

94

• Nº de Recepción de Valores. Muestra todas las recepciones que

fueron generadas en ese día y turno.

• Datos del Operador. Muestra información referente al operador como

nombre, núm. de unidad, hora salida, hora llegada, ciclos recorridos y

ruta.

• Valores en Efectivo. Se visualiza los totales recaudados tanto de

monedas, billetes y la suma de ambos.

• Tickets Estudiantiles. Muestra la cantidad de ticket y el monto

recaudado en tickets.

• Total Recaudado. Es el total recaudado en cada recepción de valores.

• Totales. Se muestra el total recaudado en todo el turno tanto en

valores efectivos como en tickets estudiantiles.

• Observaciones. Se muestra un resumen de todas las observaciones

realizadas a aquellos operadores en su entrega de valores.

• Supervisor. Se muestran los datos referentes a la persona que genera

el reporte.

• Gerente. Se muestra la información del usuario que valida el reporte

del turno.

95

Reporte Operador.

Permite generar un reporte por operador en un rango de fecha

específica. Tal como se presenta en el Gráfico Nº 32.

Descripción.

• Ficha. se ingresa la ficha del operador que desee generar el reporte.

• Fecha Inicio. Se coloca la fecha desde cuando desea que se genere el

reporte.

1

2 3 4

Gráfico Nº 32. Reporte por operador: SABSERV

96

• Fecha Fin. Se coloca la fecha hasta donde será mostrado el reporte.

• Al cliquear la lupa se mostrará la consulta deseada.

• Imprimir. Se mostrará el reporte que será impreso con la

información deseada.

97

Reporte Impreso.

Al seleccionar la impresora se mostrará el formato señalado en el

Gráfico Nº 33 como resultado final de la consulta.

Descripción

• Fecha. Se muestra las fechas límites.

• Operador. Se identifica a quien pertenece el reporte.

• Hora. Se muestra a qué hora se generó el reporte.

• Nº Recepción de Valores. Muestras las recepciones realizadas por el

operador en el rango de fecha especificado.

• Datos Operador. Se describen tanto la ruta, unidad, ciclos, turnos, y

horas salida- llegada de cada una de las recepciones hechas por el

operador.

• Valores Efectivo. Se describe el total recaudado de cada recepción

bien sea de monedas, billetes y en general.

1

5

4

9

10

2

3

6

7

8

11

Gráfico Nº 33. Recibo de reporte por operador: SABSERV

98

• Tickets Estudiantiles. Se muestra lo recaudado en tickets.

• Total Recaudado. Se visualiza el monto total de la recaudación de

cada una de las recepciones realizadas por el operador.

• Totales. Se muestran la sumatoria de cada uno de los totales de las

recepciones realizadas por el operador especificado.

• Supervisor. Se percibirán los datos referente a la persona que realizó

la solicitud del reporte al sistema

• Gerente. Se mostrará la información de la persona que cerciorará la

exactitud de los datos.

7. Reporte Diario . En este reporte se mostrará el total de recepciones

realizadas en un día. Tal se muestra en el Gráfico Nº 34.

1

2

3 4

6

5

7

8

9

Gráfico Nº 34. Reporte diario: SABSERV

99

Descripción.

• Se introduce el día que desee generar el reporte.

• Al cliquear la lupa se visualizará el reporte diario con la información

requerida.

• Fecha. Se muestra la fecha del reporte realizado.

• Hora. Se visualiza la hora en que se genero el reporte.

• Nº Recepción de Valores. Se mostrarán todas las recepciones

realizadas en el día.

• Datos de Operador. Información referente a las rutas, turnos,

operadores, unidades y horas llegadas-salidas de cada operador.

• Valores Efectivo. los totales recaudados de los billetes, monedas y en

general.

• Tickets Estudiantiles. Se mostrará la cantidad y el total recaudado por

tickets.

• Total recaudado. Se visualiza el total recaudado incluyendo efectivo y

tickets estudiantiles.

100

Módulo Cierre Laboral.

Con este módulo la gerencia de recaudación podrá verificar la correcta

recaudación del dia. Se tendrá acceso al mismo a través de la pestaña

visualizada en el Gráfico Nº 35.

1

Gráfico Nº 35. Módulo de cierre laboral: SABSERV

101

1. Arqueo de Caja.

Este formulario permitirá certificar que el valor recaudado existente

en físico sea el mismo que muestra o se encuentra en el sistema, este

será realizado cada vez que finalice un turno y al finalizar el día. Con la

ayuda del formato que se muestra en el Gráfico Nº 36.

1

2

3

4

6

7

9

5

10

11

13

12

14

15

8

16

Gráfico Nº 36. Arqueo de caja: SABSERV

102

Descripción.

• Encabezado. Alusivo al formulario realizado con datos específicos de

la Gerencia.

• Turno. Se identifica el turno al que pertenece la verificación.

• Fecha. Indica la fecha a la cual pertenece la verificación.

• Monedas-Billetes. Se identifican los tipos de monedas y billetes

existentes.

103

CONCLUSIONES

Con el cumplimiento a cabalidad de cada uno de los objetivos

planteados se obtuvo como resultado el desarrollo de un sistema con la

capacidad de administrar la información de los recursos recabados en la

Gerencia de Recaudación de la Empresa de Transporte Público del Estado

Bolívar TRANSBOLIVAR C.A, alcanzando las siguientes conclusiones:

∗ Una vez analizados los formatos hechos bajo hojas de

cálculo en Excel de la Gerencia de Recaudación, se tomó en

consideración el rediseño de los mismos con la inclusión de nuevos

ítems como; cantidad de tickets vencidos, observaciones, entre otros;

a fin de obtener los parámetros necesarios para facilitar la

administración de la información requerida.

∗ Para el diseño de la arquitectura del software se tomaron

como premisa los requerimientos obtenidos en la etapa de

levantamiento de información permitiendo determinar las entidades

necesarias para el resguardo de información en la base de datos, así

como la interfaz grafica, los módulos que contendrían el sistema, la

permisología de los usuarios y el plan de trabajo que denotaría el

periodo de entrega para cada fase del proyecto.

∗ La construcción del sistema se desarrolló bajo el entorno

web, es por ello que se utilizaron los lenguajes mencionados a

continuación: php, html, javascript, jquery, css, para la codificación de

la interfaz grafica y para las funciones que permitirían el

almacenamiento de toda la información recabada se empleó el

manejador de base de datos PostgreSQL.

104

∗ Con la evaluación de cada una de las fases de entrega

se lograron detectar errores en los requerimientos de información

definidos, los cuales fueron solventados oportunamente cooperando

de esta manera a la aproximación de los resultados deseados.

105

RECOMENDACIONES

Para un mejor uso y maximizar las funcionalidades del software

desarrollado se recomiendan las siguientes consideraciones:

∗ Usar continuamente el Sistema Administrativo de Boletería

Servicios Especiales y Recepción de Valores (SABSERV) a fin de medir el

ajuste de los requerimientos de información actuales con los que se

presentaran en el futuro considerando las políticas cambiantes de toda

organización como los es la Empresa de Transporte Público del Estado

Bolívar (TRANSBOLIVAR C.A).

∗ Es conveniente que el usuario cumpla con los requerimientos

mínimos del sistema como lo son inserción de toda la información solicitada,

configuración básica de los equipos de computación, entre otros, a fin de que

aproveche al máximo su funcionalidad.

∗ Tomar en cuenta el mantenimiento periódico del sistema,

generar respaldos automáticos de la data, del código fuente, a su vez brindar

accesibilidad a la información almacenada en cualquier momento;

cooperando con el proceso de optimización y mejoras continuas;

contribuyendo al buen uso de los recursos empleados para brindar este

servicio a la Gerencia de Recaudación.

106

GLOSARIO

C CSS

Las hojas de estilo en cascada (Cascading Style Sheets, CSS) son un

lenguaje formal usado para definir la presentación de un documento

estructurado escrito en HTML o XML.

D Datos

Son los hechos que describen sucesos y entidades.

E Entrada

Se refiere a los datos o señales que entran en un proceso.

H Hardware

Representa todos los componentes físicos de un computador.

I Información

Es la forma en la cual los datos se agrupan y ordenan, para ser entendidos

por un ente en particular.

107

Ingeniería Es la profesión en la que el conocimiento de las ciencias matemáticas y

naturales adquirido mediante el estudio, la experiencia y la práctica, se aplica

con buen juicio a fin de desarrollar las formas en que se pueden utilizar, de

manera económica, los materiales y las fuerzas de la naturaleza en beneficio

de la comunidad.

Ingeniería del Software Es una disciplina de Ingeniería que comprende todos los aspectos de la

producción de software.

Interfaz Es la definición de un conjunto de métodos para los que no se da la

implementación, sino que se les define de una manera similar a como se

definen los métodos abstractos.

Internet Es un método de interconexión descentralizada de redes de computadoras

implementado en un conjunto de protocolos denominado TCP/IP y garantiza

que redes físicas heterogéneas funcionen como una red lógica única, de

alcance mundial.

O Operador

Persona encargada de conducir un vehículo de motor para transportar a

personas, personalidades o cualquier tipo de cliente que haya contratado sus

servicios.

R Registro

Estructuras de datos que contiene información relativa a un mismo ente.

Recaudación

Cantidad de dinero o de bienes que se obtiene mediante este cobro.

108

S Salida

Es el resultado de la entrada procesada.

Servidor Es un elemento que presta un recurso (servicio).

Software Es la parte lógica que data al equipo físico de capacidad para realizar

cualquier tipo de trabajo.

T Tabla Es la representación de una entidad compuesta por varios atributos.

109

BIBLIOGRAFÍA

Arteaga, P. (2009). Metodología de la investigación I y II. Venezuela.

Arzuedo, A. C. (1991). Administración de Recursos. Fondo de Naciones Unidas para Población.

Berzal, Cubero, & Cortijo. (2007). Desarrollo profesional de aplicaciones web con ASP.NET. Ikor Consulting.

Cobo, & Gómez. (2005). Técnologias para el desarrollo de aplicaciones web. Díaz de Santos.

Kendall, & Kendall. (2005). Análisis y Diseño de Sistemas. México: Pearson Educación.

Madariaga Gorocica, J. M. (2004). Manual Práctico de Auditoria. Deusto.

Pressman, R. (2005). Ingenieria del Software. Un enfoque práctico. McGraw-Hill.

Calva, J., Aguilar, G. (2007). Finanzas públicas para el desarrollo. México: Miguel Ángel Porrúa.

Sommerville, I. (2007). Ingenieria del Software. España: Pearson Educación.

Weinman, L., & Weinman, W. (2002). Diseño Creativo HTML. México: Pearson Educación.

Curt F. (2004). Excel. Guía de Bolsillo. EEUU: Ediciones Nowtilus SL. Date, C. (2011). Introducción a los sistemas de bases de datos. México:

Pearson Educación.

110

ANEXOS

111

Anexo Nº 01. Formato de Recepción de Valores.

112

Anexo Nº 02. Formato de Reporte por turno.

113

Anexo Nº 03. Formato de Arqueo de Caja.

114

Anexo Nº 04. Minuta de Primera Entrevista.

115

Anexo Nº 05. Minuta de Segunda Entrevista.

116

Anexo Nº 06. Agenda pautada para las Mesas de Traba jo.

Ip 96272011 CD Ramirez Glori Mar

Documents

Transcript of Ip 96272011 CD Ramirez Glori Mar