Ip 96272011 CD Ramirez Glori Mar
-
Upload
francisco-enrique-blanco-bravo -
Category
Documents
-
view
34 -
download
10
description
Transcript of 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
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.
Autor: Ramírez Glorimar C.I: 19.298.727 Tutor: Salazar Oscar
CIUDAD GUAYANA, MAYO DEL 2011
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
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).
Nombre Descripción Tipo
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).
Nombre Descripción Tipo
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).
Nombre Descripción Tipo
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 Descripción Tipo
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 Descripción Tipo
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 Descripción Tipo
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 Descripción Tipo
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).
Nombre Descripción Tipo
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).
Nombre Descripción Tipo
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).
Nombre Descripción Tipo
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 Descripción Tipo
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.
Gráfico Nº 10. Diagrama Actividad Nivel 2: el Autor.
68
Analista (Nivel 3). Se perciben las acciones que el analista puede
ejecutar, ver Gráfico Nº 11.
Gráfico Nº 11. Diagrama Actividad Nivel 3: el Autor.
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.
117
118