Grupo 8 Tesis

UNIVERSIDAD NACIONAL DEL ALTIPLANO
FACULTAD DE INGENIERÍA MECÁNICA ELÉCTRICA,

ELECTRÓNICA Y SISTEMAS
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS
DESARROLLO DE UN SISTEMA DE CONTROL Y MONITOREO

VEHICULAR MEDIANTE GPS PARA MEJORAR LA EFICIENCIA
EN EL PROCESO DE GESTIÓN DE VEHÍCULOS EN LA
EMPRESA CONSORCIO SAN MIGUEL
TESIS
PRESENTADA POR:
Bach. LUZ CLARA TICONA ACERO
PARA OPTAR EL TÍTULO PROFESIONAL DE:
INGENIERO DE SISTEMAS
PUNO – PERÚ
2021
DEDICATORIA
El presente trabajo de investigación, está

dedicado principalmente a Dios, por ser mi
guía e inspiración en quien halle la
fortaleza para continuar adelante pese a las
dificultades.
A mis amados padres Eloy y Elena, por su

amor, trabajo y sacrificio en todos estos
años, gracias por inculcar en mí el ejemplo
de esfuerzo y valentía, de no temer las
adversidades.
A mis hermanos Marco y Lenin por estar

siempre presentes, por el apoyo moral, que
me brindaron a lo largo de esta etapa de mi
vida, a toda mi familia porque con sus
consejos y palabras de aliento hicieron de
mí una mejor persona.
Luz
AGRADECIMIENTOS
A la Universidad Nacional del Altiplano, en especial a la escuela profesional de
Ingeniera de Sistemas y plana docente, por la formación que se me otorgo.
A los miembros del Jurado, por sus sugerencias y acertados aportes en la elaboración
de este trabajo de investigación.
Finalmente, mis agradecimientos para todas las personas que han cooperado en la
realización de esta investigación.
Luz
ÍNDICE GENERAL
DEDICATORIA
AGRADECIMIENTOS
ÍNDICE DE TABLAS
ÍNDICE DE FIGURAS
ÍNDICE DE ACRÓNIMOS
RESUMEN .................................................................................................................... 12
ABSTRACT................................................................................................................... 13
CAPITULO I
INTRODUCCIÓN
1.1. PLANTEAMIENTO DEL PROBLEMA .................................................... 15
1.2. FORMULACIÓN DEL PROBLEMA ........................................................ 17
1.3. OBJETIVOS DE LA INVESTIGACIÓN ................................................... 18
1.3.1. Objetivo general .......................................................................................... 18
1.3.2. Objetivos específicos .................................................................................. 18
1.4. HIPÓTESIS Y VARIABLES ....................................................................... 18
1.4.1. Hipótesis general......................................................................................... 18
1.4.2. Variables ..................................................................................................... 18
1.5. JUSTIFICACIÓN DE LA INVESTIGACIÓN .......................................... 19
CAPITULO II
REVISIÓN DE LA LITERATURA
2.1. ANTECEDENTES ........................................................................................ 20
2.2. MARCO TEÓRICO ..................................................................................... 22
2.2.1. Gestión vehicular ........................................................................................ 22
2.2.2. Geolocalización .......................................................................................... 23
2.2.3. Sistema ........................................................................................................ 25
2.2.4. Aplicación móvil......................................................................................... 26
2.2.5. MongoDB ................................................................................................... 30
2.2.6. Firebase ....................................................................................................... 31
2.2.7. GPS ............................................................................................................. 31
2.2.8. Metodología Scrum..................................................................................... 32
2.2.9. Modelo vista controlador ............................................................................ 35
2.2.10. Modelo de la calidad ISO/IEC 2500 ...................................................... 37
2.3. MARCO CONCEPTUAL ............................................................................ 41
CAPITULO III
MATERIALES Y MÉTODOS
3.1. ZONA DE ESTUDIO .................................................................................... 44
3.2. TIPO Y DISEÑO DE INVESTIGACIÓN ................................................... 45
3.2.1. Tipo de investigación .................................................................................. 45
3.2.2. Diseño de investigación .............................................................................. 45
3.2.3. Población y muestra de investigación ......................................................... 45
3.2.4. Material experimental ................................................................................. 46
3.3. TÉCNICAS E INSTRUMENTOS ............................................................... 46
3.3.1. Técnicas para el procesamiento y análisis de datos .................................... 46
3.4. PLAN DE TRATAMIENTO DE LOS DATOS .......................................... 47
3.5. DISEÑO ESTADÍSTICO ............................................................................. 47
CAPITULO IV
RESULTADOS Y DISCUSIÓN
3.6. RESULTADOS ............................................................................................. 48
3.6.1. Desarrollo del sistema de control y monitoreo vehicular mediante GPS ... 48
3.6.2. Evaluación del nivel de calidad del sistema ............................................... 81
3.6.3. Evaluación de la eficiencia en el proceso de gestión vehicular .................. 87
3.7. DISCUSIÓN .................................................................................................. 96
V. CONCLUSIONES ................................................................................................... 98
VI. RECOMENDACIONES ........................................................................................ 99
VII. REFERENCIAS .................................................................................................. 100
ANEXOS ...................................................................................................................... 104
Área: Sistemas de información.

Línea: Ingeniería de software
FECHA DE SUSTENTACIÓN: 30 de julio 2021
ÍNDICE DE TABLAS
Tabla N° 1: Historia de usuario N° 01 - Registro y visualización de datos del conductor. 49
Tabla N° 2: Historia de usuario N° 02 - Registro de información de vehículo. ............... 50
Tabla N° 3: Historia de usuario N° 03 - Visualización de ubicación de vehículos en tiempo
real . ...................................................................................................... 51
Tabla N° 4: Historia de usuario N° 04 - Visualizar parte diario de vehículos.................. 52
Tabla N° 5: Historia de usuario N° 05 - Programación de ordenes de salida fuera de obra. 53
Tabla N° 6: Historia de usuario N° 06 - Visualizar ordenes de salida. ............................. 54
Tabla N° 7: Historia de usuario N° 07 - Visualización de rutas recorridas de vehículos.55
Tabla N° 8: Historia de usuario N° 08 - Registro de parte diario del vehículo. ............... 56
Tabla N° 9: Historia de usuario N° 09 - Enviar y visualizar notificaciones. .................... 57
Tabla N° 10: Pila de producto................................................................................................ 59
Tabla N° 11: Pila Sprint. ........................................................................................................ 60
Tabla N° 12: Roles Scrum. .................................................................................................... 61
Tabla N° 13: Actores de diagrama de casos de uso. ............................................................ 64
Tabla N° 14: Historias de usuario de sprint 1 ....................................................................... 67
Tabla N° 15: Historias de Usuario de Sprint 1 ..................................................................... 74
Tabla N° 16: Historias de usuario de Sprint 3. ..................................................................... 76
Tabla N° 17: Historias de usuario de Sprint 4 ...................................................................... 79
Tabla N° 18: Requerimientos para la evaluación de la calidad. .......................................... 81
Tabla N° 19: Resumen de la evaluación de calidad interna según ISO/IEC 25000. ......... 82
Tabla N° 20: Resumen de la evaluación de calidad externa según ISO/IEC 25000. ......... 83
Tabla N° 21: Resumen de evaluación de calidad en uso según ISO/IEC 25000. .............. 85
Tabla N° 22: Valores asignados a las respuestas del cuestionario según escala Likert. .... 88
Tabla N° 23: Resultados fínales de encuestas pre test y post test ....................................... 89
Tabla N° 24: Resultados prueba T-student. .......................................................................... 89
Tabla N° 25: Indicador del nivel de mejora de la eficiencia en el proceso de gestión
vehicular…. ...................................................................................................... 91
Tabla N° 26: Tiempo de acceso a la información en el proceso de gestión unidades
vehiculares sin el sistema…… ........................................................................ 92
Tabla N° 27: Porcentaje de la eficiencia de la productividad sin el sistema. ..................... 93
Tabla N° 28: Tiempo de acceso a la información con ayuda del sistema........................... 94
Tabla N° 29: Porcentaje de la eficiencia en la productividad con ayuda del sistema. ....... 94
Tabla N° 30: Nivel de impacto de la eficiencia de la productividad con y sin el sistema. 95

ÍNDICE DE FIGURAS
Figura N° 1: Arquitectura Android ............................................................................ 27
Figura N° 2: GPS en Android. ................................................................................... 32
Figura N° 3: Ciclo de Scrum...................................................................................... 34
Figura N° 4: Diagrama Modelo Vista Controlador. .................................................. 36
Figura N° 5: División de la Norma ISO/IEC 25000. ................................................. 37
Figura N° 6: Ciclo de Vida de la evaluación de Calidad de Producto Software. ...... 39
Figura N° 7: Características y subcaracterísticas para evaluar la Calidad Interna y
Externa ..................................................................................................... .
.............................................................................................................. 40
Figura N° 8: Características y subcaracterísticas para evaluar la calidad en uso. ..... 41
Figura N° 9: Módulos del sistema. ............................................................................ 58
Figura N° 10: Burndown general. ................................................................................ 60
Figura N° 11: Estructura del modelo de implementación............................................ 62
Figura N° 12: Diagrama de casos de uso de sistema. .................................................. 63
Figura N° 13: Diagrama de clases. .............................................................................. 65
Figura N° 14: Diagrama de base de datos.................................................................... 66
Figura N° 15: Sprint Burndown Chart 1 ...................................................................... 68
Figura N° 16: Interfaz de registro de administrador o supervisor. ............................... 68
Figura N° 17: Login del administrador, usuario y supervisor. ..................................... 69
Figura N° 18: Vista principal de usuario (Conductor). ................................................ 69
Figura N° 19: Interfaz Panel de control Administrador y Supervisor .......................... 70
Figura N° 20: Interfaz gráfica de registro de conductores. .......................................... 70
Figura N° 21: Interfaz de registro de vehículo parte 1 ................................................. 71
Figura N° 22: Interfaz de registro de vehículo parte 2 ................................................. 71

Figura N° 23: Vista de selección de conductor. ........................................................... 72
Figura N° 24: Interfaz de registro de parte diario. ....................................................... 72
Figura N° 25: Interfaz de registro de parte diario parte 2 ............................................ 72
Figura N° 26: Listado de vehículos registrados. .......................................................... 73
Figura N° 27: Listado de conductores registrados. ...................................................... 73
Figura N° 28: Burndown Chart 2 ................................................................................. 74
Figura N° 29: Interfaz de programación de orden de salida 1. .................................... 75
Figura N° 30: Vista de generación de orden de salida 2. ............................................. 75
Figura N° 31: Interfaz de listado de notificaciones de ordenes de salida programadas. ..... 76
Figura N° 32: Burndown Chart 3. ................................................................................ 77
Figura N° 33: Vista de generación de orden de salida ................................................. 77
Figura N° 34: Documento PDF de la orden de salida generado por el sistema. .......... 78
Figura N° 35: Interfaz de visualizar y descargar parte diario. ..................................... 78
Figura N° 36: Documento PDF de parte diario, generado por el sistema. ................... 79
Figura N° 37: Burndown Chart 4. ................................................................................ 80
Figura N° 38: Interfaz gráfica de monitoreo y control de vehículos en tiempo real. ... 80
Figura N° 39: Interfaz gráfica de recorrido de rutas de cada vehículo. ....................... 81
Figura N° 40: Porcentaje de la evaluación de calidad interna según ISO/IEC 25000. 83
Figura N° 41: Porcentaje de evaluación de calidad externa según ISO/IEC 25000. ... 85
Figura N° 42: Porcentaje de evaluación de calidad en uso según ISO/IEC 25000. ..... 86
Figura N° 43: Porcentaje de calidad interna, externa y en uso, obtenido, al evaluar el
sistema de control y monitoreo vehicular mediante GPS. .................... 86
Figura N° 44: Nivel de calidad total obtenido, en la evaluación del sistema............... 87
Figura N° 45: Campana de Gauss. ............................................................................... 90
Figura N° 46: Contrastación de pre test y post test según escala Likert. ..................... 91
Figura N° 47: Resultados de encuesta pre test. .......................................................... 105
Figura N° 48: Resultados de encuesta post test. ........................................................ 107
Figura N° 49: Control y registro de vehículos sin el sistema. .................................... 108
Figura N° 50: Control y registro de vehículos sin el sistema. .................................... 108
Figura N° 51: Registro y validación de parte diario sin el sistema ............................ 109
Figura N° 52: Programación y aprobación de orden de salida de vehículos sin el sistema. 109
Figura N° 53: Registro de vehículos con el sistema. ................................................. 110
Figura N° 54: Control de conductores con el sistema. ............................................... 110
Figura N° 55: Registro de conductores con el sistema. ............................................. 111
Figura N° 56: Control de conductores con el sistema. ............................................... 111
Figura N° 57: Registro de parte diario con el sistema. .............................................. 112
Figura N° 58: Validación de parte diario con el sistema. .......................................... 112
Figura N° 59: Programación de orden de salida con el sistema. ................................ 113
Figura N° 60: Monitoreo de vehículos mediante GPS. .............................................. 114
Figura N° 61: Procedimiento para la evaluación de la calidad interna. ..................... 115
Figura N° 62: Procedimiento para la evaluación de la calidad externa del sistema. . 117
Figura N° 63: Procedimiento para la evaluación de calidad en uso del sistema. ....... 118
ÍNDICE DE ACRÓNIMOS
GPS: Global Positioning System (sistema de posicionamiento global).
API: Application Programming Interface (entorno de desarrollo integrado).
APK: Android Application Package (paquete de aplicación android).
SDK: Software Development Kit (kit de desarrollo de software).
MVC: Modelo Vista Controlador (estilo de arquitectura software)
IDE: Integrated Development Environmen (entorno de desarrollo integrado).
JVM: Java Virtual Machine (maquina Virtual de proceso Nativo).
JSON: JavaScript Object Notation (notación de objeto de Java Script).
BSON: Binary JSON (Json Binario).
SQL: Structured Query Language (lenguaje de consulta estructurada).
NoSQL: No solo SQL (bases de datos no relacionales).

RESUMEN
En la presente investigación se identificó la ineficiencia en el proceso de gestión
de unidades vehiculares para empresas del sector construcción, actualmente los
dispositivos móviles se han convertido en uno de los recursos más importantes para las
organizaciones, esto permite contar con nuevas herramientas para control, gestión de
recursos, y monitoreo mediante GPS, para afrontar el alto grado de ineficiencia en sus
procesos. Por esta razón se desarrolló, el sistema de control y monitoreo vehicular
mediante GPS, para mejorar la eficiencia en el proceso de gestión de unidades
vehiculares, en los proyectos del Consorcio San Miguel, basándose en una aplicación
móvil para la geolocalización mediante GPS móvil de los conductores, utilizando la
metodología ágil Scrum, el cual se acomodó a las necesidades y etapas del proyecto, el
mismo que en la etapa final se validó aplicando el ISO/IEC 25000 de calidad de software,
obteniendo como resultado un 90% de Calidad Total y un 10% de Calidad Faltante. Para
el análisis estadístico se utilizó la Prueba de T-Student para dos muestras relacionadas
(Pre-test y Post-test), los resultados obtenidos prueban que la implementación de la
aplicación móvil de control y monitoreo de vehículos mediante GPS mejora
significativamente la eficiencia en el proceso de gestión de vehículos en un 32%, a si
mismo se reafirmó este resultado mediante la evaluación de la eficiencia de la
productividad en base al tiempo de acceso a la información, en el cual se identificó el
nivel de mejora en un 31%, ya que se logró reducir el tiempo de acceso a la información
en el proceso de gestión vehicular de 162 minutos a 24 minutos.
Palabras Clave: Control, monitoreo, Sistema de Posicionamiento Global (GPS),
eficiencia, gestión.
12
ABSTRACT
This research identified the inefficiency in the management process of vehicle
units for companies in the construction sector, currently mobile devices have become one
of the most important resources for organizations, this allows to have new tools for
control, resource management, and monitoring by GPS, to address the high degree of
inefficiency in their processes. For this reason, it developed, the GPS vehicle control and
monitoring system, to improve efficiency in the management process of vehicle units, in
the projects of Consorcio San Miguel, based on a mobile application for GPS mobile
geolocation of drivers, using the agile Scrum methodology, which was adapted to the
needs and stages of the project, which in the final stage it was validated applying the
ISO/IEC 25000 software, obtained as a result quality, in a 90% of Total Quality and 10%
of Missing Quality. For the statistical analysis the T-Student Test was used for two related
samples (Pre-test and Post-test), the results obtained prove that the implementation of the
mobile application for vehicle control and monitoring through GPS significantly
improves the efficiency in the vehicle management process by 32%, This result was
reaffirmed by evaluating the efficiency of productivity based on the time of access to
information, in which the level of improvement was identified by 31%, since it was
possible to reduce the time of access to the information on the vehicle management
process from 162 minutes to 24 minutes.
Keywords: Control, monitoring, Global Positioning System (GPS), efficiency,
management.
13
CAPITULO I
INTRODUCCIÓN
En la actualidad las herramientas para la gestión de unidades vehiculares mediante
GPS, en empresas del sector transporte, hacen uso de sistemas de geolocalización para
mantener un control y monitoreo adecuado de sus flotas, sin embargo, según la INEI
(2020) en el Perú solo 30% de las empresas del sector construcción e ingeniera, hacen
uso de estas herramientas tecnológicas.
Al respecto diversas empresas han incursionado en el uso de la tecnología móvil,
ya que los dispositivos móviles generan innovación porque sus nuevas aplicaciones
permiten generar mejoras en la eficiencia de los procesos gerenciales y administrativos
dentro de las organizaciones, considerando que en el Perú en base a los resultados
obtenidos en la encuesta realizada por la INEI (2020), el 12.4% de empresas desarrollaron
su propio software, diseñado para necesidades específicas logrando una gestión eficiente
de sus procesos, en tal sentido, actualmente empresas del sector construcción apuestan
por el uso de aplicaciones móviles para mejorar sus procesos, ya que la ineficiencia en el
control de los recursos es notable, afectando financiera y productivamente a la
organización, es por ello que surgió la idea de desarrollar un sistema de control y
monitoreo vehicular mediante GPS, con la finalidad de mejorar la eficiencia en el proceso
de gestión de unidades vehiculares, en los proyectos del Consorcio San Miguel.
La presente investigación consta de Capítulo I, en donde se describe el
planteamiento de problema, formulación del problema, objetivos, hipótesis y la
justificación de la investigación; en el Capítulo II, hace referencia a los antecedentes, que
tiene relacion con el presente trabajo, marco teórico y marco conceptual; en el Capítulo
III se detalla la metodología de investigación, finalmente en el Capítulo IV se muestran
los resultados e interpretación, conclusiones y recomendaciones.
14
1.1. PLANTEAMIENTO DEL PROBLEMA
Según Diaz (2019) en la actualidad el avance tecnológico nos lleva a reinventarnos
y actualizarnos constantemente, esto también ocurre en las organizaciones quienes deben
establecer estrategias de modernización en sus procesos tanto administrativos como
operativos, con el fin de mantenerse activas en el mercado, la implementación de las TICs
en los procesos de una empresa, cuenta con un elemento diferenciador que las posiciona
por encima de aquellas que no han contemplado su uso, en este caso para el control y
monitoreo tanto de personal o activos, con los que cuenta una empresa como vehículos,
maquinarias, dispositivos tecnológicos y otros, es por ello que Cano (2018) sostiene que
las TICs permiten una distribución de la información a toda la organización de manera
rápida y eficiente, con la finalidad de promover la toma de decisiones en cualquier área
de la organización.
Hoy en día la tecnología móvil ha revolucionado en diversos aspectos, Merchan
et al. (2017) afirma que en América Latina se puede evidenciar que el impacto de las
tecnologías de la información y la comunicaciones no se limita al sector, sino que se
extiende a todos los sectores de producción y consumo en la sociedad, ya que sus nuevas
aplicaciones han generado cambios en la gerencia de las empresas, comprendiendo que
los beneficios asociados a la difusión de una tecnología de uso general van más allá de su
aplicación a los procesos de negocio, podemos identificar una serie de áreas en las que la
presencia de aplicaciones móviles está impulsando cambios en combinación con la
tecnología móvil, ya que la comunicación inalámbrica e instantánea permite una mayor
flexibilidad de gestión y acelera los procesos que dependen de esta dentro de las
organizaciones.
15
Según la Mobile Marketing Association (2018), en el 2017 los dispositivos
portátiles manejaron el 50% de las interacciones totales del mercado de aplicaciones en
Latinoamérica, y la mayoría de las aplicaciones se desarrollaron para mejorar procesos.
En el Perú en base a los resultados obtenidos por la INEI (2018), en la Encuesta
Nacional de Empresas 2018 indica que, del total de empresas investigadas solo el 12.4 %
desarrollaron su propio software, haciendo uso de las TICs el cual fue diseñado para
necesidades específicas, logrando una gestión eficiente de sus procesos.
Por otro lado Servin (2018), afirma que el control y monitoreo interno en las
empresas es una tarea ineludible para aquellos que desean lograr competitividad en sus
negocios, ya que una empresa que implemente controles internos disminuye la ocurrencia
de incidentes en sus procesos, a su vez generan un impacto positivo en su negocio, por
ello se debe desarrollar un control interno adecuado a cada tipo de organización lo que
permitirá optimizar la utilización de recursos como las TICs, para alcanzar una adecuada
gestión financiera y administrativa, logrando mejores niveles de productividad.
En la empresa Consorcio San Miguel, dedicada a la supervisión de obras públicas
y privadas, en la actualidad cuenta con 10 obras de construcción y remediación ambiental
ubicadas en Cajamarca, Puno, Ayacucho y Lima, que actualmente se están ejecutando,
cada una de ellas cuenta con 5 unidades vehiculares, un total de 50 vehículos que el área
de administración y supervisión, de proyecto se encarga de controlar y monitorear siendo
este el proceso de gestión de vehículos (camionetas), en el cual se ha observado que se
tiene un pésimo control y monitoreo de las camionetas, en consecuencia la gestión de
vehículos es ineficiente, ya que a diario se designa actividades a realizar mediante ordenes
de salida en formatos Excel, que genera el administrador de obra, el mismo que es
aprobado mediante firma original del supervisor de obra, quien no siempre se encuentra
16
en oficina dado que parte de su trabajo es en campo, por lo que la aprobación del formato
demanda un tiempo de 60 a 100 minutos, dependiendo de la disponibilidad del supervisor.
El control se realiza de manera manual, el formato de parte diario de los vehículos
que registran los conductores asignados a cada uno de los vehículos, debe de ser validado
por el administrador, esta actividad se realiza a diario y demanda un tiempo de entre 30
a 70 minutos, generando retrasos en la salida de los vehículos para sus actividades diarias,
cabe resaltar también que no se tiene información de la ubicación de los vehículos en
tiempo real, los conductores no reportan la hora y el lugar en donde se encuentran con el
vehículo, el mal uso de los vehículos por los conductores al realizar actividades para uso
personal fuera de obra, en horario de trabajo, haciendo uso del combustible de la empresa,
afectando financiera y productivamente al Consorcio San Miguel.
En ese sentido se tiene como problema, que el control y monitoreo de vehículos,
en el proceso de gestión de vehículos es ineficiente, para que este proceso mejore se
requiere la información de la ubicación del vehículo en tiempo real mediante GPS,
disminuir el tiempo de acceso a la información, tener los activos de la empresa seguros
en caso de robo, evitar accidentes o incidentes que puedan afectar la salud del personal y
en consecuencia la ejecución de una obra, contar con dicha información para el
procesamiento de datos mejorara la toma de decisiones del consorcio de tal manera que
no se verá afectada económicamente y su productividad mejorará .
1.2. FORMULACIÓN DEL PROBLEMA
¿En qué medida el sistema de control y monitoreo de vehículos mediante GPS
podría contribuir a mejorar la eficiencia en el proceso de gestión de vehículos en la
empresa Consorcio San Miguel?
17
1.3. OBJETIVOS DE LA INVESTIGACIÓN
1.3.1. Objetivo general
Determinar el nivel de mejora de la eficiencia en el proceso de gestión de unidades
vehiculares, con ayuda del sistema de control y monitoreo vehicular mediante
GPS, en los proyectos del Consorcio San Miguel.
1.3.2. Objetivos específicos
− Desarrollar el sistema de control y monitoreo vehicular mediante GPS, basado en
una aplicación móvil, para el proceso de gestión de unidades vehiculares, de la
empresa Consorcio San Miguel.
− Determinar el nivel de calidad del sistema de control y monitoreo vehicular
mediante GPS implementado para los proyectos del Consorcio San Miguel.
− Determinar el nivel de mejora de la eficiencia de la productividad de acuerdo al
tiempo de acceso a la información, para la gestión de unidades vehiculares, con
ayuda del sistema de control y monitoreo vehicular mediante GPS, en los
proyectos del Consorcio San Miguel.
1.4. HIPÓTESIS Y VARIABLES
1.4.1. Hipótesis general
Con ayuda del sistema de control y monitoreo de vehículos mediante GPS se
mejora significativamente la eficiencia en el proceso de gestión de vehículos, en la
1.4.2. Variables
− Variable independiente. Sistema de control y monitoreo de vehículos
mediante GPS.
− Variable dependiente. Eficiencia en el proceso de gestión de vehículos
en la empresa Consorcio San Miguel.
18
1.5. JUSTIFICACIÓN DE LA INVESTIGACIÓN
La metodología SCRUM para desarrollar el sistema, la evaluación de software
según la ISO/2500, el modelo de investigación cuantitativa con un diseño
cuasiexperimental, el análisis de datos con el modelo Likert y prueba T student para
muestras relacionadas, la evaluación del nivel de eficiencia de la productividad en base
al tiempo de acceso a la información del proceso de gestión vehicular, se adaptaron en
cada fase del desarrollo, implementación, evaluación del sistema de control y monitoreo
vehicular mediante GPS, el mismo que sirve de aporte y se puede tomar como base para
futuros proyectos de investigación en el desarrollo de software, dejando así un precedente
de cómo mejorar los procesos de empresas o entidades de diversos ámbitos.
La presente investigación, emplea los conocimientos adquiridos durante los años
de estudio en la Universidad Nacional del Altiplano- Puno, lo cual ayudo en la evaluación
del proceso de gestión de unidades vehiculares de la empresa Consorcio San Miguel, en
donde se determinó que , se tiene un pésimo control y monitoreo vehicular, ya que el
desconocimiento de la ubicación real de cada uno de los vehículos en tiempo real, la
generación y aprobación tardía de ordenes de salida, la demora en el registro de partes
diarios, no permite una eficiente gestión de unidades vehiculares, en consecuencia
perturba la labor realizada por los equipos de supervisión afectando de esta forma a la
entidad productiva y financieramente.
El desarrollo del sistema de control y monitoreo mediante GPS, basado en una
aplicación móvil tanto para el administrador y usuario, permitió a la empresa saber el
punto exacto de los vehículos en tiempo real, contar con información actualizada y
oportuna, por lo que la implementación correcta del sistema mencionado, mejora la
eficiencia en el proceso de gestión vehicular.
19
CAPITULO II
REVISIÓN DE LITERATURA
2.1. ANTECEDENTES
Antecedentes de contexto internacional

Avalos y Garces (2017), en su tesis manifiestan que la investigación realizada en
México, las cadenas de suministro, en el proceso de distribución de materiales y
productos, no existía un Sistema de Rastreo Vehicular fabricado localmente a si mismo
que en el mercado actual no existía un dispositivo de rastreo vehicular que incluya un
módulo WiFi, este trabajo de tesis presenta el diseño y construcción de un sistema de
rastreo vehicular por satélite activo, se trata de un sistema con aplicación en el área de
logística y cadena de suministro, que se instala en vehículos y flotillas con fines de
monitoreo remoto en tiempo real, finalmente se llegó a la conclusión de que se logró
satisfactoriamente el desarrollo de un sistema de rastreo vehicular mediante satélite activo
haciendo posible el monitoreo eficiente en las áreas de logista y cadena de suministros.
Soto et al. (2019), en esta investigación los autores indican que los grandes
volúmenes de basura que se generan, crean un problema en la definición de las rutas y
localización de la flota vehicular de recolección, tiene como problema encontrar el punto
óptimo de localización de una flota de vehículos recolectores de basura en 144 barrios del
municipio Dosquebradas, Risaralda – Colombia, motivo por el cual en esta investigación
diseñaron una nueva metodología, hibrida CSGTR (Clustering, sweep, genetic, tabu
routing), que permitió aprovechar las ventajas de la clusterizacion, antes del ruteo de
vehículos, incluyendo modelos heurísticos como la técnica del barrido, finalmente
concluye que la aplicación de la metodología hibrida CSGTR para resolver el problema
ya mencionado, permitió reducir el tiempo y los costos de los recorridos de los camiones.
20
Antecedentes de contexto Nacional
Bashualdo (2017), en su trabajo de investigación indica que, en Perú, como en
otros países en vías de desarrollo, muchos distritos con baja densidad poblacional carecen
de un servicio de rastreo satelital para la seguridad de sus medios de trasporte y choferes,
dado que por la falta de interés de los servidores públicos municipales a si mismo indica
que la municipalidad de Chancay tiene inconvenientes en el manejo del sistema de
monitoreo vehicular ya que dificulta la tranquilidad del desarrollo de sus actividades, se
tienen perdida monetaria, pérdida de tiempo por lo que el proceso de monitoreo vehicular
es ineficiente, es por ello que se implementó un sistema de monitoreo satelital por GPS
para los vehículos de la municipalidad distrital de Chancay, finalmente concluye que con
la implementación del sistema se mejora la calidad de servicio de la municipalidad
distrital de chancay 2017.
Antecedentes de contexto Local

Según Flores (2016)en su tesis Modelo de control, seguimiento y monitoreo
satelital en tiempo real de usuarios móviles mediante el uso de teléfonos celulares, para
el control y la gestión de personal de campo de la entidad financiera Caja Rural de Ahorro
y Crédito los Andes S.A., en su investigación se enfoca más al personal que labora en
campo denominado Recuperador, estos realizan visitas en diferentes zonas y/o sectores
donde residen los clientes morosos, de tal modo que en varios casos no se tiene la
ubicación exacta del personal, en consecuencia la productividad viene a ser afectada ya
que no se tiene certeza de la visita a los clientes, por lo que presento un modelo para el
control seguimiento y monitoreo satelital en tiempo real de usuarios móviles con la ayuda
de teléfonos celulares, para mejorar las labores realizadas dentro de la unidad de
recuperaciones, finalmente concluye que en base a los resultados e indicadores
estadísticos se determinó el nivel de mejora del modelo a la gestión y control de personal
de campo de la entidad.
21
Chuquija (2019), en su tesis Aplicación Móvil de Geolocalización para el control
y la gestión de la seguridad en conductores de la Empresa de Taxi Exitoso E.I.R.L Juliaca
2019, manifiesta que la empresa de Taxi Exitoso opera a nivel local, utilizando el sistema
de radio para el proceso de localización de los conductores con sus respectivas unidades,
por lo que no es suficiente para un mejor control y gestión en temas de seguridad,
determinó que la gestión es ineficiente y no ayuda a la tranquilidad del conductor, por lo
que la empresa de taxis tiene la necesidad de brindar al conductor la seguridad y la
tranquilidad, es por eso que esta investigación desarrollo un aplicativo móvil de
geolocalización para mejorar el control y la gestión de la seguridad en conductores de la
Empresa de Taxi Exitoso E.I.R.L., el mismo que concluye indicando que el nivel de
control y gestión de la seguridad mejora significativamente en un 20% .
2.2. MARCO TEÓRICO
2.2.1. Gestión vehicular
“La gestión de flotas de transporte es la administración de un grupo de
vehículos que han sido reunidos bajo un mismo propósito por una organización, cumple
diversas funciones como el monitoreo de las unidades, planificar los recorridos, control
del presupuesto y los gastos entre otros, a través de estas acciones, tiene como objetivo
optimizar la eficiencia y productividad de una flota en todas las etapas de la cadena
logística, minimizando riesgos, aumentando la productividad y la vida útil de los
transportes, y reduciendo los costos de su operación”. (FLIIT BY PROSEGUR, 2019)
“La administración de flotas es vital para el desarrollo de las empresas, para
algunas es el motor principal de su actividad económica, como las compañías
de transporte de cargas, renting de vehículos, o mensajería; mientras que para otras es
un recurso valioso en la eficiencia de las operaciones logísticas que funcionan como
22
soporte a su actividad comercial principal (supermercados, industrias manufacturas,
etc.)”.(Pulpomatic, 2021)
De acuerdo a Sateliun (2021), las políticas de gestión se diseñan a partir de las
características y objetivos de cada organización, y se apoyan en la tecnología para facilitar
el análisis y administración de los activos de hecho, invertir en soluciones de gestión de
flotas es considerado un gasto eficiente que profesionaliza la operación de transporte y
logística en una organización, cada tipo de flota presenta particularidades y elementos en
común. Una gestión de flotas eficiente parte de los elementos comunes, pero se adapta a
las características de cada compañía. Para eso es imprescindible que el sistema de gestión
utilizado sea lo suficientemente versátil, hay tres características que se destacan sobre el
resto.
a) Seguimiento satelital de alta velocidad y precisión: El rastreo satelital de los
vehículos es una de las funciones más importantes dentro de la administración de
flotas de transporte.
b) Funciones de control y monitoreo avanzadas: Sólo algunos sistemas de gestión
de flotas de transporte incorporan funciones de control y monitoreo avanzadas para
complementar el seguimiento mediante GPS.
c) Estadísticas y reportes detallados: El volumen de información que generan los
sistemas de gestión de flotas de transporte es enorme. Esto permite tomar decisiones
basadas en datos para optimizar procesos al máximo.
2.2.2. Geolocalización
“Geolocalización consiste en la identificación de la posición de un dispositivo en
el espacio real, el Sistema de Posicionamiento Global (GPS) es la forma más común y
precisa en que se realiza la localización geográfica, la geolocalización se encarga
específicamente en obtener la localización de una persona, empresa, evento, ciudad
23
pueblo etc. En un punto geográfico exacto que es determinado por medio de ciertas
coordenadas, usualmente provenientes de satélites, pero que cabe destacar que también
pueden provenir de otros dispositivos como los móviles”.(Martinez ,2018)
GPS
“El GPS obtiene la localización mediante satélites y es la que más de usa en la
actualidad, ya que permite determinar, con muy buena precisión hasta del orden de
metros, la posición espacial de objetos fijos o móviles sobre la superficie terrestre”.
(Villegas, 2020)
Por otro lado Villegas (2020) también manifiesta que el GPS en la actualidad se
ha convertido en parte de la vida diaria y es utilizado en todas las actividades de la vida
humana como en la industria de la telefonía móvil, es usado en los vehículos mayormente
para seguir su posición y movimiento, tiene vital importancia en la navegación marítima,
para obtener información de la topografía marina y colocación de boyas, también es útil
en la navegación aérea pues permite a los aviones volar con una ruta precisa.
Parámetros de precisión
Latitud. La latitud proporciona la localización de un lugar, en dirección Norte o
Sur desde el ecuador y se expresa en medidas angulares que varían desde los 0°
del ecuador hasta los 90°N del polo Norte o los 90°S del polo Sur. (AristaSur,
2010)
Longitud. Aristasur (2010) expresa que la distancia angular entre un punto dado
de la superficie terrestre y el meridiano que se tome como 0° (es decir el meridiano
de base) medida a lo largo del paralelo en el que se encuentra dicho punto, una
circunferencia cuyo centro es la intersección del eje de la Tierra con el plano del
citado paralelo.
24
2.2.3. Sistema
Un sistema se conceptualiza en la abstracción de sus componentes, con el objeto
de expresar su comportamiento y sus procesos en términos de isomorfismo.
Según Van (1987), un sistema se define como “ una unión de partes o
componentes, conectados en una forma organizada. Las partes se afectan por estar en el
sistema y se cambian si lo dejan. La unión de partes hace algo (muestra una conducta
dinámica como opuesto a permanecer inerte). Además, un sistema puede existir
realmente como un agregado natural de partes componentes encontradas en la
naturaleza, o ésa puede ser un agregado inventado por el hombre, una forma de ver el
problema que resulta de una decisión deliberada de suponer que un conjunto de
elementos relacionados, y constituyen una cosa llamada un sistema”.
Por otro lado de acuerdo al cibernauta Stafford (1966), afirma que un sistema se
define como un conjunto de ítems que están dinámicamente relacionados, se trata de un
conjunto de elementos que son las partes u órganos del sistema, dinámicamente
relacionados en una red de comunicaciones resultante de la interacción de los elementos
formando una actividad, que es la operación (o procesamiento) del sistema, para alcanzar
un objetivo o propósito operando sobre datos/energía/materia, que son los insumos o
entradas de recursos para que el sistema pueda operar.
Procesos internos de un sistema
Según Daniel (2020) propone una modelización simple, que comprende las instancias
básicas de entradas – proceso – salidas de un sistema.
a) Entradas: También conocidas como insumos, impulsos o input, son los elementos
(materia o energía) que dan la fuerza de arranque al sistema. En una organización
25
las entradas serán las materias primas, el capital, los recursos humanos y
tecnológicos, etc.
b) Procesos: Es el mecanismo que transforma las entradas en salidas o resultados.
Dada lo complejo de explicar y representar lo que ocurre dentro del sistema de
procesos, se lo sustituye por un modelo simplificado, denominado caja negra.
c) Concepto de caja negra: Stafford (1966), sugiere como ejemplo de caja negra un
sistema pequeño, definible en principio, aunque inaccesible. Este sistema se halla
encerrado en una caja opaca, que no puede ser penetrada en forma alguna, y sus puntos
visibles son las entradas y las salidas (resultados). Por ejemplo, en el caso del cerebro
humano, o del procesador de una computadora, pueden utilizarse para su estudio.
Al respecto Pavesi (1996) , manifiesta que el concepto de caja negra se utiliza
cuando en un sistema complejo, al observador no le conviene analizar todos los
elementos, tan solo basta conocer su comportamiento o saber que existe, ese subsistema
que puede o no tener interacción relevante con el subsistema analizado, cuando no se
conoce un sistema determinado ni su comportamiento, el enfoque de la caja negra permite
inferir estructuras y comportamientos.
d) Salida, producto o resultado: Las salidas son el resultado de un proceso, las que,
en términos ideales, deben ser coherentes con los objetivos del sistema.
2.2.4. Aplicación móvil
“Una aplicación móvil, también llamada app móvil, es un programa diseñado para
ejecutarse en un dispositivo móvil o tableta, que permite al usuario realizar actividades
profesionales, acceder a servicios y otros”. (Herazo, 2021)
26
Según Gallego (2017), Android es un sistema operativo de código abierto para
dispositivos móviles, se programa principalmente en Java, y su núcleo está basado en
Linux y por otro lado en Universidad de Alicante (2014), manifiesta que Android es el
sistema operativo soportado por la mayor cantidad dispositivos móviles, por lo que el
mercado de aplicaciones Android está en continuo crecimiento, la presencia de las
empresas y de sus aplicaciones en esta plataforma se está convirtiendo en un requisito
indispensable.
Arquitectura
“Android es una pila de software de código abierto basado en Linux creada para
una variedad amplia de dispositivos y factores de forma. En el siguiente diagrama, se
muestran los componentes principales de la plataforma Android”. (Android Developers,
2020)
Figura N° 1: Arquitectura Android

Fuente: (Android Developers, 2020)
27
Android Developers (2020), afirma que el núcleo es la capa encargada de los
controladores (drivers) del hardware, los procesos, la memoria, seguridad, red, gestión de
energía, es decir abstrae el resto de las capas del hardware. El Android run time es lo que
hace a Android diferente de una distribución de Linux, está compuesto por las librerías
"core" (núcleo) y por Dalvik, la máquina virtual de Java, basada en registros cuenta con
el núcleo de Linux para la gestión de hilos y para el manejo de memoria a bajo nivel. El
framework de aplicaciones está compuesto por las clases que se utilizan para crear
aplicaciones Android, actividades, servicios, views, proveedores de contenidos, etc.
Finalmente, la capa de aplicaciones está compuesta por las aplicaciones nativas y por las
de terceros, así como las de desarrollo.
Desarrollo de aplicaciones móviles en Android
Android Studio
De acuerdo a Android Developers (2020), Android Studio es el entorno de
desarrollo integrado (IDE) oficial para el desarrollo de apps para Android, basado
en IntelliJ IDEA. Además del potente editor de códigos y las herramientas para
desarrolladores de IntelliJ, Android Studio tiene funciones que aumentan la
productividad cuando se desarrolla apps para Android, como las siguientes:
− Un sistema de compilación flexible basado en Gradle
− Un emulador rápido y cargado de funciones
− Un entorno unificado donde puedes desarrollar para todos los dispositivos
Android
− Aplicación de cambios para insertar cambios de códigos y recursos a la
aplicación en ejecución sin reiniciar la aplicación
− Integración con GitHub y plantillas de código para ayudarte a compilar
funciones de apps comunes y también importar código de muestra
28
− Variedad de marcos de trabajo y herramientas de prueba
− Herramientas de Lint para identificar problemas de rendimiento,
usabilidad y compatibilidad de la versión, entre otros
− Compatibilidad integrada con Google Cloud Platform, que facilita la
integración con Google Cloud Messaging y App Engine
Android SDK
De acuerdo al Dpto. de Ciencia de la Computacion e Inteligencia Artificial (2014),
El SKD de Android incluye numerosas y completas API's para facilitar el
desarrollo. Algunas de las características más relevantes son:
− Acceso al hardware de WiFi, GPS, Bluetooth y telefonía, permitiendo
realizar y recibir llamadas y SMS. Control completo de multimedia,
incluyendo la cámara y el micrófono.
− APIs para los sensores: acelerómetros y brújula.
− Mensajes entre procesos (IPC).
− Almacenes de datos compartidos, acceso a SD Card.
− Aplicaciones y procesos en segundo plano.
− Widgets para la pantalla de inicio (escritorio).
− Integración de los resultados de búsqueda de la aplicación con los del
sistema. Uso de mapas y sus controles desde las aplicaciones.
− Aceleración gráfica por hardware, incluyendo OpenGL ES 2.0 para los
3D.
29
Kotlin
“Kotlin es un lenguaje de programación estático de código abierto que admite la
programación funcional y orientada a objetos. Proporciona una sintaxis y conceptos
similares a los de otros lenguajes, como C#, Java y Scala, entre muchos otros. No pretende
ser único, sino que se inspira en décadas de desarrollo del lenguaje. Cuenta con variantes
que se orientan a la JVM (Kotlin/JVM), JavaScript (Kotlin/JS) y el código nativo
(Kotlin/Native)”. (Android Developers, 2019)
Al respecto Android Developers (2019), afirma que Kotlin es administrado
por Kotlin Foundation, un grupo creado por JetBrains y Google, que se ocupa de
continuar el desarrollo del lenguaje. Google admite oficialmente Kotlin para el desarrollo
de Android, lo cual significa que la documentación y las herramientas de Android están
diseñadas para ser compatibles con Kotlin, algunas API de Android, como Android KTX,
son específicas de Kotlin, pero la mayoría están escritas en Java y se pueden llamar desde
Java o Kotlin. La interoperabilidad de Kotlin con Java es fundamental para su
crecimiento. Eso quiere decir que se puede llamar al código Java desde Kotlin, y
viceversa, y de esa manera aprovechar todas tus bibliotecas de Java existentes.
2.2.5. MongoDB
En base a SiliconNews (2019), se afirma que MongoDB es una base de datos
NoSQL que responde al acrónimo Not Enly SQL, también se categoriza en el término de
base de datos documental, ya que almacena documentos BSON (similares a JSON) y no
registros como en MySQL, la diferencia entre ambas es la estructuras, es que MongoDB
trabaja con documentos independientes, modifica su contenido individual sin afectar al
resto. Mientras que MySQL, no permite modificar individualmente cada registro, ya que
utiliza un conjunto de documentos o bases de datos enteros.
30
2.2.6. Firebase
“Firebase es una plataforma en la nube, para el desarrollo de aplicaciones web y
móvil, está disponible para distintas plataformas (iOS, Android y web), con lo que es más
rápido trabajar en el desarrollo”.(Lopez, 2020)
Para Lopez (2020), fue creada en el 2011 paso a ser parte de Google en 2014,
comenzando como una base de datos en tiempo real, sin embargo, se añadieron más
funciones que permitieron agrupar los SDK, de productos con distintos fines, facilitando
su uso, considerando que su agrupación simplifica las tareas de gestión a una misma
plataforma, una de las herramientas más destacadas y esenciales de firebase son las bases
de datos en tiempo real. Estas se alojan en la nube, son No SQL y almacenan los datos
como JSON, permiten alojar y disponer de los datos e información de la aplicación en
tiempo real, manteniéndolos actualizados, aunque el usuario no realice ninguna acción.
2.2.7. GPS
“El sistema de Posicionamiento Global (GPS) es un servicio, que proporciona a
los usuarios información sobre posicionamiento, navegación y cronometría. Este sistema
está constituido por tres segmentos: el segmento espacial, el segmento de control y el
segmento del usuario”.(GPS.Gov, 2015)
Según Fernandez (2018), GPS en Android, se trata de una de las funciones clave
de cualquier dispositivo, la cual te permite utilizar aplicaciones de navegación y muchas
otras que basan su contenido en la localización ya que detecten la ubicación de un usuario,
la red de GPS tiene un total de 27 satélites orbitando la tierra, de los cuales se utilizan 24
de forma activa y otros tres funcionan como refuerzo en el caso de que algunos activos
fallen. Esta red está repartida de tal manera que, en cualquier sitio, se pueda tener
conexión directa con varios de estos satélites.
31
La acción del receptor GPS en el móvil, se conecta con al menos tres de los
satélites que hay cerca de ti, entonces, utiliza datos como la ubicación actual en relación
con los satélites y la distancia de cada uno de ellos respecto a ti posición para calcular la
posición en el mapa en la que te encuentras, con tres satélites es suficiente para triangular
la posición en un mapa, también suele utilizarse un cuarto satélite para determinar la
altitud.
Figura N° 2: GPS en Android.

Fuente: (Fernandez, 2018)
Los receptores de GPS del móvil utilizan bastante batería, y necesitan tener una
conexión clara con los satélites.
2.2.8. Metodología Scrum
Para Peralta (2003), Scrum es un proceso ágil para desarrollar software, parte
como base de que los procesos definidos funcionan bien sólo si las entradas están
perfectamente definidas y el ruido, ambigüedad o cambio es muy pequeño, por lo tanto,
resulta ideal para proyectos con requerimientos inestables, ya que fomenta el surgimiento
de los mismos, el ciclo de vida definido por Scrum es incremental iterativo y se
caracteriza por ser muy adaptable.
32
Elementos de Scrum
De acuerdo a Alvarez y Joiz.Net (2018), los elementos de Scrum son:
− Sprints: Los Sprints tienen una duración fija y determinada a lo largo del
proyecto, porque se rigen según el ´principio de “timeboxing”.
− Definición de Hecho: El equipo de trabajo tiene que encontrar una
definición para el concepto de “hecho” para darlo por finalizado un sprint,
y poder ser entregado.
Esquema General
El trabajo a ser realizado en un proyecto Scrum es listado en el Product
Backlog, lista de todos los cambios requeridos sobre un producto, los proyectos
se realizan durante una serie de iteraciones de un mes de duración llamadas
Sprints. Al comienzo de cada Sprint tiene lugar a una Sprint Planning Meeting
durante el cual el Product Owner prioriza el Product Backlog y el Scrum Team
selecciona las tareas que serán completadas durante el Sprint que va a comenzar.
Esas tareas son removidas del Product Backlog para ser llevadas al Sprint
Backlog, durante el Sprint el equipo se mantiene en contacto a través de las Daily
Meetings y al final del Sprint debe mostrar la funcionalidad completa en la Sprint
Review Meeting.
33
Figura N° 3: Ciclo de Scrum.
Fuente: (Peralta, 2003)
Roles en Scrum
− ProductOwner. Decide que se incluye (y que no) en el backlog del
proyecto, ordena los ítems en el backlog en función de su prioridad de
negocio, explica y hace entender al equipo de trabajo en qué consisten esos
ítems (historias de usuario).
− ScrumMaster: Representa la figura de lides sirviente, es el experto en la
metodología, guiando y enseñando al equipo a llevarla a cabo
adecuadamente, soluciona problemas y elimina barreras.
− Scrum Team: Realiza el trabajo necesario para construir y entregar el
producto final, el equipo es un grupo de profesionales con todas las
capacidades en conjunto para realizar el trabajo.
34
2.2.9. Modelo vista controlador
“Su nombre, MVC, parte de las iniciales de Modelo-Vista-Controlador (Model-
View-Controller), que son las capas o grupos de componentes en los que se organiza las
aplicaciones, considerado también un patrón de diseño de la capa de presentación, pues
define la forma en que se organizan los componentes de presentación en sistemas
distribuidos, la arquitectura MVC propone, la separación de los componentes de una
aplicación en tres grupos (o capas) principales: el modelo, la vista, y el controlador, y
describe cómo se relacionarán entre ellos para mantener una estructura organizada,
limpia y con un acoplamiento mínimo entre las distintas capas”.(María , 2019)
− Modelo. En la capa Modelo se encuentra siempre la lógica de negocio de la
aplicación, es decir, la implementación de las reglas, acciones y restricciones que
permiten gestionar las entidades del dominio, es el responsable de que el sistema se
encuentre siempre en un estado consistente e íntegro, y es el encargado de gestionar
el almacenamiento y recuperación de datos o entidades del dominio, es decir, incluirá
mecanismos de persistencia o será capaz de interactuar con ellos.
− Vista. Los componentes de la Vista son los responsables de generar la interfaz de la
aplicación, es decir, de componer las pantallas, páginas, o cualquier tipo de resultado
utilizable por el usuario o cliente del sistema, la Vista es una representación del estado
del Modelo en un momento concreto y en el contexto de una acción determinada.
− Controlador. El controlador actúa como intermediario entre el usuario y el sistema,
capturan las acciones de este sobre la Vista, realiza también tareas de transformación
de datos para hacer que los componentes de la Vista y el Modelo se entiendan, así
traducirán la información enviada desde la interfaz de la misma forma, el Controlador
tomará la información procedente del Modelo y la adaptará a formatos o estructuras
de datos que la Vista sea capaz de manejar.
35
Relación entre Modelo, Vista y Controlador
El siguiente diagrama refleja las relaciones existentes entre los componentes del
Modelo, Vista y Controlador, y de éstos a su vez con el usuario, o cliente, del sistema.
Figura N° 4: Diagrama Modelo Vista Controlador.

Fuente: (Maria, 2019)
Acerca de lo que se muestra en el diagrama, Maria (2019) agrega que las acciones
e información procedentes del usuario son recogidas exclusivamente por los
controladores, ningún componente de otra capa debe acceder a los datos generados desde
el cliente, de la misma forma que sólo los componentes de la vista estarán autorizados a
generar interfaces de usuario con las que envían información de retorno.
Destaca también el papel central del controlador, ya que tiene acceso bidireccional
al modelo, es decir, será capaz tanto de actualizar su estado, invocando métodos o
acciones incluidos en su lógica de negocio. Sin embargo, en ningún caso el modelo
mostrará acoplamiento alguno respecto a las clases controlador que lo están utilizando.
Por otra parte, el controlador puede usar clases del modelo, denominadas View-
Models, que contendrán toda la información que la vista necesite para maquetarse y
mantendrá a ésta aislada de los cambios en el modelo, la responsabilidad de la vista, por
tanto, se reduce a generar la interfaz partiendo de los datos que le suministre el
controlador.
36
2.2.10. Modelo de la calidad ISO/IEC 2500
“Las normas ISO/IEC 25000 provee una guía para el uso de las nuevas series y
estándares internacionales, llamados Requisitos y Evaluación de Calidad de Productos
de Software – Square”.(ISO 25000, 2021)
Tiene como objetivo principal guiar la evaluación de calidad de productos
software estableciendo criterios para la especificación de requisitos de calidad de
sotfware, sus métricas y su evaluación.
División de la Norma ISO/IEC 25000
Como se puede visualizar en la figura 5, la norma ISO/IEC 25000 está dividida
en cinco partes, las cuales se describen en base al marco teórico de la tesis de Balseca
(2016).
Figura N° 5: División de la Norma ISO/IEC 25000.

Fuente: (Balseca, 2016)
a) ISO/IEC 2500n: Gestión de calidad

Los estándares que forman esta división definen modelos, términos y definiciones
comunes, utilizadas por los demás estándares que conforman esta norma, los
cuales son:
37
− ISO/IEC 25000: Guía de SQuaRE
− ISO/IEC 25001: Planificación y gestión.
b) ISO/IEC 2501n: Modelo de calidad
El estándar que conforma esta división es la ISO/IEC 25010, que detalla las
características para la calidad interna, externa y en uso.
c) ISO/IEC 2502n: Medición de la calidad
Los estándares que forman parte de esta división, incluyen un modelo de
referencia de calidad del producto software, definiciones matemáticas de las
métricas de calidad y una guía práctica para su aplicación.
Los estándares son:
− ISO/IEC 25020: Modelo de referencia para la medida con guía.
− ISO/IEC 25021: Primitivas
− ISO/IEC 25022: Medidas de calidad en uso.
− ISO/IEC 25023: Medidas de Calidad del Producto Software (calidad
interna, calidad externa, calidad en uso).
d) ISO/IEC 2503n: Requisitos de la calidad
El estándar que conforma esta norma es la ISO/IEC 25030, el cual está orientado
a ayudar en la especificación de requisitos para un producto software que va a ser
desarrollado o como entrada para un proceso de evaluación.
e) ISO/IEC 2504n: Evaluación de la calidad
Los estándares pertenecientes a esta división, proporcionan requisitos,
recomendaciones y guías para la evaluación de un producto software, ya sea
realizada por evaluadores independientes, compradores o desarrolladores.
Esta división contiene los siguientes estándares.
− ISO/IEC 25040: Proceso de Evaluación
− ISO/IEC 25041: Guía de evaluación para desarrolladores, compradores y
evaluadores independientes.
38
Ciclo de vida de la calidad del Producto Software
En base a ISO/IEC 25000 (2018), el ciclo de vida la calidad del producto software
especifica que la calidad de un producto software requiere un proceso similar al de
desarrollo para cada uno de los tipos de calidad, como son especificación de requisitos,
implementación y validación de los resultados, tal como se muestra en la Figura.
Figura N° 6: Ciclo de Vida de la evaluación de Calidad de Producto Software.

Fuente: (Balseca, 2016)
El ciclo de vida en SQuaRE maneja la calidad del producto software en tres principales
faces:
− Calidad Interna: Cuando el producto se encuentra en etapa de desarrollo.

− Calidad Externa: Cuando el producto software se encuentra en funcionamiento.
− Calidad en Uso: Cuando el producto software se encuentra en uso.
Para cada una de estas fases existen requisitos que responden a una necesidad del
producto que deberán ser implementados y validados.
− Los requisitos de calidad de uso, especifican el nivel de calidad requerido desde
el punto de vista del usuario, estos requisitos son los que determinan la validación
del software por parte del usuario.
39
− Los requisitos de calidad externa se utilizan para la verificación y validación
técnica del producto. Estos requisitos ayudan a determinar los requisitos de
calidad interna pero además sirven para predecir si se alcanzara la calidad en uso
deseada.
− Los requisitos de calidad Interna se utilizan para verificar el producto a lo largo
de las distintas etapas del desarrollo y pueden utilizarse también para definir
estrategias y criterios de evaluación.
Modelo de Calidad del Producto Software
Calidad Interna y Externa
El modelo define 8 características para la calidad interna y externa de un
producto software, los cuales a su vez son subdivididos en sub
características descritas en la figura 7, estas sub características pueden ser
medidas con métricas internas o externas.
Figura N° 7: Características y subcaracterísticas para evaluar la Calidad Interna y

Externa.
Fuente: (ISO 25000, 2021)
40
Modelo para Calidad en Uso
El modelo de calidad en uso define 5 características, las cuales a su vez sn
subdivididos en subcaracterísticas descritas en la figura 8, estas subcaracterísticas
pueden ser medidas con métricas de calidad en uso.
Figura N° 8: Características y subcaracterísticas para evaluar la calidad en uso.

Fuente: (ISO 25000 , 2021)
2.3. MARCO CONCEPTUAL
Administrador de obra
Es aquel profesional, que tiene como labor principal llevar el control, monitoreo,
y gestión de procesos administrativos.
Supervisor de obra
Es el jefe del equipo de supervisión, tiene como labor principal velar por el
cumplimiento correcto, de los procesos administrativos y técnicos relacionados al
proyecto.
Gestión
“La gestión es un conjunto de procedimientos y acciones que se llevan a cabo
para lograr un determinado objetivo”. (Westreicher, 2020)
41
Eficiencia
“Eficiencia es el vínculo existente cuando pocos recursos son utilizados para
alcanzar un mismo fin, con el manejo con minimos recursos o medios”.(Yirda, 2021)
Ineficiencia
“Ineficiencia es la imposibilidad de realizar una actividad o alcanzar una meta
al menor coste y en el menor tiempo posible”. (Westreicher, 2021)
Productividad
“La productividad es una medida económica que calcula cuántos bienes y servicios
se han producido por cada factor utilizado (trabajador, capital, tiempo, tierra, etc)
durante un periodo determinado”.(Sevilla Arias, 2016)
GPS
“Global Positioning System (Sistema de Posicionamiento Global), que permite
posicionar cualquier objeto”.(GPS.Gov, 2015)
MVC
“Modelo Vista Controlador, es un patrón de arquitectura de software, que separa
los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres
componentes distintos”.(Maria , 2019)
MONGODB
“Base de datos distribuida, basada en documentos y de código abierto, MongoDB
guarda estructuras de datos BSON con un esquema dinámico, haciendo que la
integración de los datos en ciertas aplicaciones sea eficiente. de aplicaciones”
.(SiliconNews, 2019)
42
BSON
“ Es un formato de intercambio de datos usado principalmente y transferencia en
la base de datos MongoDB, su estructura es binaria y su nombre está basado en JSON y
Binary”.(SiliconNews, 2019)
API REST
“Es un backend capaz de contestar llamadas a una serie de URLs en formato
JSON, se usa para el desarrollo de aplicaciones, que conectan diferentes instancias del
tráfico de información”. (Android Developers, 2019)
Firebase
“Firebase Realtime Database es una base de datos NoSQL alojada en la nube
que permite almacenar y sincronizar datos en tiempo real”. (Lopez, 2020)
ISO/IEC 25000:
“Es una familia de normas cuyo objetivo es la creación de un marco de trabajo
común para evaluar la calidad del producto software”.(ISO 25000, 2021)
Calidad interna
“Es la totalidad de características del producto que determinan su habilidad para
satisfacer las necesidades establecidas e implícitas bajo condiciones específicas”.(ISO
25000, 2021)
Calidad externa
“Es la totalidad de características que se determinan hasta que un punto un
producto satisface las necesidades explicitas e implícitas cuando es usado bajo
condiciones específicas”. (ISO 25000, 2021)
Calidad en uso
“La perspectiva del usuario de la calidad del producto cuando este es usado
en un ambiente especifico y un contexto de uso especifico”.(ISO 25000, 2021)
43
CAPITULO III
MATERIALES Y MÉTODOS
3.1. ZONA DE ESTUDIO
La presente investigación se realizó en tres proyectos del Consorcio San Miguel
de RUC: 20604954216, ubicados en la Provincia de Puno y Hualgayoc.
− Recuperación de los Servicios Ecosistémicos en la Microcuenca del rio San
Antonio, afectada por los Pasivos Ambientales Mineros de la Ex Unidad
Minera San Antonio de Esquilache, Distrito de San Antonio, Provincia y
Región Puno.
− Recuperación de los Servicios Ecosistémicos en la Microcuenca Hualgayoc y
Microcuenca Arascorgue contaminadas por los Pasivos Ambientales Mineros
de la Ex Unidad Minera los Negros, Distrito y Provincia de Hualgayoc –
Cajamarca.
− Recuperación de los servicios Ecosistémicos de la microcuenca de la quebrada
Sinchao, afectada por los Pasivos Ambientales Mineros de la Ex Unidad
Minera Cleopatra, Distrito y Provincia de Hualgayoc -Cajamarca.
Cabe mencionar que, cada proyecto, tiene 28 trabajadores, entre ellos el personal
profesional técnico encargado de supervisar las actividades del contratista en obra y
personal administrativo, responsable de gestionar eficientemente todos los procesos
respecto a su area, la sede central se encuentra ubicado en Cal.Monte Rosa Nro. 270 Dpto.
802 Urb. Chacarilla del Estanque Lima - Lima - Santiago De Surco, asesorado por la Lic.
Guadalupe Rodríguez Morales – Representante Legal.
44
3.2. TIPO Y DISEÑO DE INVESTIGACIÓN
3.2.1. Tipo de investigación
Según Sousa et al., (2007) la investigación cuantitativa adopta una estrategia
sistemática, objetiva y rigurosa para generar y refinar el conocimiento, en este diseño, se
utiliza inicialmente el raciocinio deductivo y la generalización.
El presente proyecto es tipo Investigación Cuantitativo, porque se ha aplicado
una encuesta que permite evaluar el nivel de mejora de la eficiencia en el proceso de
gestión de vehículos en el Consorcio San Miguel.
3.2.2. Diseño de investigación
El diseño utilizado es el Cuasi Experimental, en el cual según Hernandez
Sampieri et al. (2014), las variables se manipulan deliberadamente, al menos una variable
independiente para observar su efecto y relacion con una o más variables dependientes,
es por ello que se aplicó pre test y post test para probar la hipótesis, con un alto grado de
probabilidad, el método estadístico elegido para este análisis fue la prueba T-Student para
muestras relacionadas.
3.2.3. Población y muestra de investigación
Población
La población se determinó de acuerdo al método no probabilístico por
conveniencia, en tal sentido en la presente investigación la población está
comprendida dentro del Consorcio San Miguel, específicamente al personal del
área administrativa.
45
Muestra
Para la presente investigación se ha considerado a 12 colaboradores, entre
Administradores de obra, asistentes administrativos, jefes de supervisión y
asistentes de supervisor, que laboran en el Consorcio San Miguel en tres proyectos
diferentes ubicados en Puno y Cajamarca.
3.2.4. Material experimental
En la presente investigación, se empleará ficha de observación para el análisis de
control y seguimiento de vehículos con el sistema y sin el sistema, así mismo estadísticas
básicas para la prueba de hipótesis, intervalos de confianza y pruebas de normalidad.
3.3. TÉCNICAS E INSTRUMENTOS
Técnicas
En la presente investigación se utilizó las técnicas de observación ya que nos
permite tener contacto directo con la realidad, lo cual influye a obtener un mayor
conocimiento de la realidad, encuestas con la que se obtuvo información, por medio de
preguntas, la información recogida se limita a la delineada por las preguntas que
componen el cuestionario.
Instrumentos
El cuestionario se realizó de forma virtual utilizando formularios Google,
mediante un conjunto de preguntas diseñadas para generar los datos necesarios para
alcanzar los objetivos propuestos del proyecto de investigación, para la técnica de
observación se aplicó fichas de observación directa, en donde registro el tiempo de acceso
a la información sin el sistema y con el sistema.
3.3.1. Técnicas para el procesamiento y análisis de datos
El tratamiento de datos se realizará con el programa estadístico SPSS, tomando en cuenta
el siguiente procedimiento.
46
− Recolección y evaluación de datos.
− Codificación de datos.
− Tabulación de datos.
− Presentación de los resultados, en cuadros y tablas estadísticas.
− Interpretación de resultados obtenidos de la media y desviación estándar.
3.4. PLAN DE TRATAMIENTO DE LOS DATOS
Se realizo el análisis y explicación de los resultados de la investigación con el
sistema y sin el sistema, en contraste con la hipótesis de la investigación y el sustento
teórico, para extraer las conclusiones correspondientes.
3.5. DISEÑO ESTADÍSTICO
La prueba de T Student para muestras relacionadas, se utiliza para comparar las
medias de un mismo grupo en diferentes etapas, por ejemplo, para las comparaciones de
los resultados de una prueba pre test y post test para un grupo determinado.
El planteamiento de la hipótesis nula y la hipótesis alterna es:
H0= Sin el sistema de control y monitoreo de vehículos mediante GPS, mejora la
eficiencia en el proceso de gestión de vehículos.
H1= Con el sistema de control y monitoreo de vehículos mediante GPS, mejora la
eficiencia en el proceso de gestión de vehículos.
47
CAPITULO IV
RESULTADOS Y DISCUSIÓN
3.6. RESULTADOS
3.6.1. Desarrollo del sistema de control y monitoreo vehicular mediante GPS
Análisis de requerimientos
En esta sección se analizaron y definieron las características del entorno del
sistema de control y monitoreo vehicular, así mismo se llevaron a cabo reuniones con el
área de administración de la empresa Consorcio San Miguel, con la finalidad de conocer
la situación actual del proceso de gestión de vehículos, de esta forma se obtuvo los
requerimientos e historias de usuario, definir roles y herramientas para el desarrollo del
sistema.
Los requerimientos de software, contienen una visión general del problema desde
el punto de vista del desarrollador, y estos se expresan a través de las historias de usuario.
48
Tabla N° 1: Historia de usuario N° 01 - Registro y visualización de datos del
conductor.
Historia de usuario N° 001 - Administrador
Descripción: El administrador deberá de registrar los datos de los conductores en la base

de datos, para que estos sean asignados como conductores de un vehículo.
Numero: 001 H001
Nombre de la historia: Registro y visualización de datos del conductor

Rol: Administrador
Quiero: Registrar datos del conductor y visualizarlo, ambos con el siguiente detalle.
Datos:
• DNI
• Nombres y Apellidos
• Dirección
• Teléfono
• ID Usuario
• Contraseña
• Dos números de referencia
Para: Tener información y que cada conductor sea asignado a un vehículo o camioneta,
para que este se encargue de transportar, manejar y hacerse responsable de la misma,
también se requerirá el usuario y contraseña, para que el conductor pueda iniciar sesión en
el aplicativo móvil.
Criterios de aceptación:
• El DNI debe de tener solo 8 dígitos.
• El ID de usuario debe ser generado con la inicial de su nombre y apellido paterno.
• La contraseña deberá ser generado aleatoriamente con números y caracteres.
• Los dos números de referencia deben de ser de familiares cercanos al conductor, por
seguridad en caso haya problemas con el vehículo como desaparición y demás.
• Se debe de visualizar en pantalla un listado de todos los conductores de en orden
alfabético.
Elaboración propia
49
Tabla N° 2: Historia de usuario N° 02 - Registro de información de vehículo.
Descripción: El administrador deberá de registrar información del vehículo designado a

un proyecto.
Numero: 002 H002
Nombre de la historia: Registro y visualización de datos de vehículo

Rol: Administrador
Quiero: Registrar datos de vehículo, con el siguiente detalle.
Datos de vehículo:
• ID N° Placa
• Conductor
• N° Serie
• N° Vin
• N° Motor
• Color
• Marca
• Modelo
• Placa Vigente
• Placa Anterior
• Estado
• Anotaciones
• Sede
• Fotografía del vehículo
Para: Tener control y gestionar la asignación de conductor a los vehículos o

camionetas.
• El N° de placa desde ser solo 6 dígitos.
• N° de serie y N° de VIN son idénticos.
Elaboración propia
50
Tabla N° 3: Historia de usuario N° 03 - Visualización de ubicación de
vehículos en tiempo real.
Descripción: El administrador y supervisor deberán visualizar y monitorear en tiempo real

la ubicación de cada uno de los vehículos.
Numero: 003 H003

Visualización en tiempo real la ubicación de cada uno de
Nombre de la historia:
los vehículos.
Rol: Administrador, Supervisor
Quiero: Visualizar en un mapa en tiempo real la ubicación de los vehículos, y la ruta que
realizo desde que sale de la cochera.
Para: Tener control y monitorear eficientemente, con el fin de tener información en

tiempo real en caso soliciten reportes del supervisor o superiores
• Mapeo en tiempo real general, de todos los vehículos.
• Para cada vehículo se debe de visualizar a detalle la ruta desde que inicio sus labores
hasta que finalice el día.
• Cada vehículo debe de diferenciarse en el mapa por placa y color.
• La vista se debe visualizar con tipo de mapa satelital, cuando el vehículo se encuentre
dentro de obra.
• La vista del mapa debe de ser predeterminado y satelital si el vehículo sale de obra.
• Dentro de mapa deberá de haber una función, en donde se muestre una ruta para llegar de
donde se encuentra el administrador a donde se encuentra un vehículo, así mismo el
tiempo estimado de demora.
• Para determinar la ubicación del vehículo, de requiere el dato exacto de Latitud y
Longitud.
Elaboración propia
51
Tabla N° 4: Historia de usuario N° 04 - Visualizar parte diario de vehículos.

Descripción: El administrador deberá de visualizar el parte diario de cada uno de los
vehículos y descargarlo en formato PDF.
Numero: 004 H004
Visualizar y descargar el parte diario de cada uno de los
vehículos
Rol: Administrador
Quiero: Descargar el parte diario en formato PDF y visualizar el parte diario de cada uno de
los vehículos, con el siguiente detalle.
• Fecha del día
• Datos de vehículo y conductor (estos datos anteriormente se registran en la H.U 002).
Estado de Vehículo:
• Tarjeta de propiedad
• Conos de seguridad
• Nivel de líquido de frenos
• Soat
• Botiquín y otros herramientas
Actividad del día:
• Actividad
• Inicio (hora y kilometraje)
• Termino (hora y kilometraje)
Kilometraje (importante):
• Kilometraje Inicio
• Kilometraje Final
• Kilometraje Recorrido en el día
Nivel de Combustible:
• Nivel de combustible, nivel de tanque.
• Fotografía de vehículo nivel de tanque.
Abastecimiento:
• Hora
• Kilometraje
• Galones
Para: Tener información de detalle y dar conformidad del mismo en caso si este bien
registrado, en caso haya observaciones notificar al conductor los errores observados con el
fin de tener un mejor control del vehículo.
• El parte diario debe ser registrado por el conductor en cuando inicie su actividad.
• Después de revisar el parte diario, si no hay observaciones dar conformidad del mismo,
sino enviar una notificación al conductor indicando las observaciones encontradas para que
el conductor subsánelo más pronto posible, para lo cual debe de haber un boto en donde el
administrador dará clic, dando a si su conformidad del parte diario
Elaboración propia
52
Tabla N° 5: Historia de usuario N° 05 - Programación de ordenes de salida
fuera de obra.
Descripción: El administrador deberá de gestionar y programar las salidas de los vehículos

para que salgan de obra para traslado de personal u otros y el supervisor deberá de aprobar la
orden de salida programada.
Número: 005 H005

Programar y aprobar ordenes de salidas de las camionetas que
transitaran fuera de obra.
Quiero: El administrador programara las salidas de los vehículos en base al nivel de
combustible, con el siguiente detalle.
• Fecha Solicitud
• Autorizado por: Cargo (Supervisor, asistente del supervisor)
• Autorizado a: (quien sea)
• Conductor
• Camioneta:
o Buscar por Placa
• Ocupantes para vehículo (Listado de personas que viajaran dentro del vehículo)
• Observaciones
El supervisor aprobara la orden se salida, autorizando que el vehículo salga fuera de obra.
Para: Generar ordenes de salida y enviar notificación al conductor con un día de

anticipación para que organice sus actividades y tiempo.
• La orden de salida programada solo la debe de aprobar el supervisor de obra o Asistente de
Supervisor de obra (en el formulario se debe de seleccionar para agilizar el registro).
• Se le autoriza al personal principal, que solicita la autorización en este caso al
administrados y/o o especialistas (en el formulario se debe de seleccionar para agilizar el
registro).
• Al Seleccionar la camioneta a la cual se le está programando la salida debe incluir el
conductor del mismo.
• Ocupantes de vehículo y observación, será solo texto.
• En Cuanto se registre toda la información se debe de generar la orden de salida y notificar
al conducto
Elaboración propia
53
Tabla N° 6: Historia de usuario N° 06 - Visualizar ordenes de salida.
Descripción: El administrador y supervisor deberán de visualizar una lista detallada de las

ordenes de salidas programadas a si mismo descargarlas.
Numero: 006 H006
Nombre de la historia: Visualizar y descargar las ordenes de salidas programadas

Quiero: Descargar en formato PDF y visualizar una lista detallada de todas las ordenes de
salida programadas, ordenadas por fecha a sí mismo, ver a detalle la programación, de cada
una de las ordenes de salida, con la información que se describió en la historia de usuario N°
005, la lista debe de tener el siguiente detalle.
Ordenado por:
o Fecha
o Camioneta
o Autorizado a
Para: Para tener información, visualizar el detalle para generar un reporte mensual, para la
valorización mensual de cada mes.
• La lista del detalle se deberá visualizar ordenado por fecha
Elaboración propia
54
Tabla N° 7: Historia de usuario N° 07 - Visualización de rutas recorridas de
vehículos.
Descripción: El administrador deberá de visualizar la ruta que recorrió los vehículos durante
el día, así mismo se deberá tener un registro diario de la ruta recorrida de los vehículos
durante el horario de trabajo.
Numero: 007 H007
Visualizar el registro diario de la ruta recorrida del día de

cada uno de los vehículos
Rol: Administrador
Quiero: Visualizar en un mapa, la ruta recorrida de cada uno de los vehículos, durante el día
laborado, así mismo visualizar la distancia recorrida y kilometraje recorrido.
Para: Tener información de la ruta recorrida, distancia y kilometraje, con el fin de tener un
mejor control y monitoreo en el proceso de gestión de vehículos.
• El mapa debe de marcar el punto de inicio y final. en caso de que el vehículo realice
actividades fuera de obra.
• El registro de ruta recorrida se debe visualizar por vehículo y deberá de haber la opción de
búsqueda de registro por fecha, al ingresar la fecha de debe de visualizar la ruta recorrida
durante el día, y como descripción la distancia recorrida y kilometraje recorrido al finalizar
el día.
Elaboración propia
55
Tabla N° 8: Historia de usuario N° 08 - Registro de parte diario del vehículo.
Historia de usuario N° 008 – Usuario (conductor)

Descripción: El conductor lo primero a hacer al iniciar el día deberá ser iniciar sesión,
activar su GPS, registrar el parte diario el kilometraje de inicio, registrar hora de inicio de
actividades y al finalizar el día terminar el registro con el kilometraje de termino y hora.
Numero: 008 H008
Nombre de la historia: Registro de parte diario del vehículo
Rol: Usuario
Quiero: Quiero: Registrar parte diario de vehículo, con el siguiente detalle.
• Fecha del día
Estado de Vehículo: (Check)
Actividad del día:
• Actividad
• Inicio (hora y kilometraje)
• Termino (hora y kilometraje)
Kilometraje (importante):
• Kilometraje Inicio (Es igual al kilometraje final del día anterior)
• Kilometraje Recorrido en el día
Nivel de Combustible:
• Nivel de combustible, nivel de tanque.
• Fotografía de vehículo nivel de tanque.
Abastecimiento:
Para: Remitir información a administración.
• La fecha del día debe de ser automática.
• En cuanto al estado de vehículo, los datos serán registrados con un check si está en buen
estado y sino también.
• Actividad del día será texto, la hora de inicio y termino se registrarán en el formato que
corresponde.
• Kilometraje
• Kilometraje Inicio (Es igual al kilometraje final del día anterior)
• Kilometraje Recorrido en el día (Es igual al Kilometraje Final - Kilometraje de inicio)
• Nivel de combustible, se registrara el nivel se encuentra en , medio tanque o tanque lleno,
así mismo el usuario de subir al aplicativo una imagen de la camioneta en donde se visualice
el nivel de combustible.
• Para el registro de abastecimiento, se registrará siempre en cuando se abastece al vehículo
registrando la hora, el kilometraje en el que se encuentra y la cantidad de galones
abastecidos.
• Debe de haber un botón de enviar para que, al finalizar el registro de parte diario, se remita
el registro a administración.
Elaboración propia
56
Tabla N° 9: Historia de usuario N° 09 - Enviar y visualizar notificaciones.
Historia de usuario N° 009 – Administrador y usuario
Descripción: Visualizar notificaciones, de todo tipo que serán notificadas por

administración y notificaciones automáticas.
Numero: 009 H009
Nombre de la historia: Visualizar Notificaciones

Rol: Administrador, Usuario, Supervisor
Quiero: Visualizar notificaciones enviadas por administración, y notificaciones de usuario.
De administración:
• Notificaciones de ordenes de salida con el detalle de la orden de salida.
• Notificaciones de observaciones, con respecto al registro de parte diario.
• Notificaciones de otras observaciones.
De usuario:
• Notificación para mantenimiento de vehículo.
• Notificación de Nivel de combustible
Para: Tener información a tiempo, proveer tiempos para salir fuera de obra, solicitar
administración programación para mantenimiento, y subsanar observaciones de
administración.
• Las notificaciones de ordenes de salida deberá remitirla administración 24 hora antes de la
salida programada, se debe remitir la orden de salida final generada por administración.
• Las notificaciones de observaciones, con respecto al registro de parte diario deberá
subsanarse 2 horas después de recibir dicha notificación.
• Notificaciones de otras observaciones deberá subsanarse en el tiempo que el conductor crea
conveniente.
• La notificación para mantenimiento de vehículo, se realizará cada 25 días desde el inicio
de actividades, para comunicar a administración y esta programe la orden de salida fuera de
obra antes de llegar al día 30.
• La notificación de nivel de combustible deberá se deberá realizar cada que se registre en el
parte diario como nivel de combustible medio tanque, para comunicar a administración y se
haga el abastecimiento correspondiente.
Elaboración propia
57
Módulos del sistema
En el presente estudio se desarrolló los siguientes módulos que formaron parte del
sistema de control y monitoreo de vehículos, el cual se muestra en la figura 9 .
MODULO I
REGISTRO
Sistema de
MODULO IV control y MODULO II
GESTION monitoreo CONTROL
vehicular
MODULO III
MONITOREO
Figura N° 9: Módulos del sistema.

Elaboración propia
Artefactos
Como se puede observar en la tabla 10, existen 9 historias de usuario, que se
desarrollaron en base a las reuniones con el Product Owner las cuales se describen en el
cuadro, por consiguiente, el Scrum Team realizo la estimación de la puntuación de
dificultad de cada una de las historias de usuario en una escala del 1 al 10, a si mismo se
estimó el esfuerzo programado en días, según la escala de prioridad con la finalidad de
que se dividan en sprints.
58
Tabla N° 10: Pila de producto.
Estimación
Puntuación
Id Historia de usuario Modulo de esfuerzo
de historia
programado
Registro y visualización de
H001 Registro 5 8
datos del conductor
Registro y visualización de
H002 Registro 5 8
datos de vehículo
Visualización en tiempo real
H003 la ubicación de cada uno de Monitoreo 9 16
los vehículos.
Visualizar y descargar el
H004 parte diario de cada uno de Control 4 8
los vehículos.
Programar y aprobar ordenes
H005 de salidas de las camionetas Gestión 7 12
que transitaran fuera de obra.
Visualizar y descargar las
H006 ordenes de salidas Gestión 4 8
programadas.
Visualizar el registro diario
H007 de la ruta recorrida del día de Monitoreo 7 14
cada uno de los vehículos.
Registro de parte diario del
H008 6 9
vehículo. Registro
H009 Visualizar Notificaciones. Gestión 6 10
Elaboración propia
En base a lo detallado anteriormente, se reitera que existe 9 historias de usuario,
en ese sentido el desarrollo del sistema se dividió en 4 Sprints las cuales, el primer sprint
contiene 3 historias de usuario, el segundo Sprint 2 historias de usuario, el tercer Sprint 2
historias de usuario y el cuarto sprint 2 historias de usuario, que se describe en la tabla N°
11.
59
Tabla N° 11: Pila Sprint.
Puntuación Estimación Tiempo

Sprint Id Historia de usuario
de historia de esfuerzo estimado
H001 Registro y visualización de
5 8
datos del conductor
H002 Registro y visualización de
Sprint 1 5 8 25
datos de vehículo
H008 Registro de parte diario del
6 9
vehículo
H005 Programar y aprobar ordenes
de salidas de las camionetas 7 12
Sprint 2 que transitaran fuera de obra 22
H009 Visualizar Notificaciones 6 10
H004 Visualizar y descargar el
parte diario de cada uno de 4 8
los vehículos
Sprint 3 16
H006 Visualizar y descargar las
ordenes de salidas 4 8
programadas
H003 Visualización en tiempo real
la ubicación de cada uno de 9 16
los vehículos.
Sprint 4 30
H007 Visualizar el registro diario
de la ruta recorrida del día de 7 14
cada uno de los vehículos
Elaboración propia
Burndown
La figura 10 muestra el diagrama burndown de todo el proyecto especificando, el
tiempo estimado en días para el proceso de desarrollo de cada sprint.
Figura N° 10: Burndown general.
60
Elaboración propia
Personas y roles del proyecto
Para el desarrollo de la aplicación móvil se formó los siguientes roles detallados
en la Tabla 12.
Tabla N° 12: Roles Scrum.
Persona Contacto Rol
Luz Clara Ticona Acero [email protected] Product
Sandra Cornejo Martinez [email protected] Owner
Edwin Quispe Cari [email protected] Development
Luz Clara Ticona Acero [email protected] Team
Luz Clara Ticona Acero [email protected] Scrum Master
Elaboración propia
Diseño y desarrollo del sistema de control y monitoreo vehicular mediante
GPS
En esta sección me basare en la descripción del proceso de diseño y desarrollo del
sistema de control y monitoreo mediante GPS utilizando la metodología SCRUM, en base
al análisis de los requerimientos, el sistema se basa en un aplicativo móvil, ya que es más
accesible tanto para los usuarios (conductores de camionetas) y administradores por que
podrán tener un control y monitoreo de vehículos eficaz desde su móvil, en consecuencia
mejorara la eficiencia en el proceso de gestión de vehículos en la empresa Consorcio San
Miguel.
Diseño arquitectónico
Según Pressman (2010) afirma: “El diseño arquitectónico representa la estructura
de los datos y de los componentes, que se requieren para construir un sistema,
considera un estilo de arquitectura que adoptara el sistema”.
61
En la presente investigación se representa diagramas que contemplaron la mejor
solución en cuanto al diseño del sistema de control y monitoreo de vehículos, el
mismo que permitió implementar las historias de usuario.
Estructura del sistema
El sistema utilizo una arquitectura basada en servicios SOA (Arquitectura
orientada a servicios) concretamente REST (Representational State Transfer) el cual es
un estilo de arquitectura para lograr la comunicación entre cliente y servidor, así mismo
firebase brinda un servicio de base de datos en tiempo real sincronizando los datos
mediante su API, por otro lado, el servidor recibe los cambios de la API de firebase, para
luego guardar los cambios actualizados en la base de datos, el cliente o la interfaz obtiene
las coordenadas mediante GPS móvil y se comunica con la API de firebase mediante
HTTP para enviar notificación es y datos en tiempo real.
Figura N° 11: Estructura del modelo de implementación.

Elaboración propia
Diagrama de casos de uso del sistema
A continuación, en la figura 12 se muestra los casos de uso del sistema, que describe la
secuencia de acciones realizadas por el personal de Consorcio San Miguel a si mismo las
funcionalidades del sistema de control y monitoreo de vehículos, en la tabla 13 se muestra
los actores que interactúan con el sistema.
62
Figura N° 12: Diagrama de casos de uso de sistema.
Elaboración propia
63
Definición de Actores
Tabla N° 13: Actores de diagrama de casos de uso.

Actor Descripción
Actor 1 - Conductor Representa el conductor del vehículo.
Representa la persona encargada del

Actor 2 – Administrador de obra
control y monitoreo de camionetas.
Actor 3 – Jefe de supervisión o Representa la persona encargada del

supervisor de obra control y monitoreo de camionetas.
Elaboración propia
Diagrama de clases
En la presente investigación, se ha utilizado una base de datos MongoDB la misma
que es posible representar con un diagrama de clases, un esquema que represente la
estructura de datos BSON(una especificación similar a JSON), con el fin de visualizar en
forma general la estructura de información del sistema, ya que los diagramas de clases no
están dirigidos específicamente a bases de datos relacionales, sino entornos orientados a
objetos, MongoDB concuerda conceptualmente con UML mejor que una base de datos
relacional, en la figura 13 se muestra el diagrama de clases del sistema de control y
monitoreo vehicular.
64
Figura N° 13: Diagrama de clases.
Elaboración propia
65
Diagrama de la base de datos
Para almacenar los datos del sistema de ha utilizado una base de datos MongoDB,
en nodos independientes y no tablas relacionales, los mismos que se almacenan en un
servidor de MongoAtlas, a diferencia de firebase en donde solo se almacenarán las
coordenadas de GPS (latitud y longitud)
La sincronización entre MongoDB y firebase, permitió que se pueda guardar los
datos de posición desde un dispositivo móvil, estos se guardan y actualizan en la nube y
notifica simultáneamente a otros dispositivos, ya que se usaron las notificaciones de
firebase para enviar alertas al celular Android y la base de datos esta alojada en la nube.
Figura N° 14:Diagrama de base de datos

Elaboración propia
66
Diseño de la arquitectura
El patrón arquitectónico que se utilizo es MVC (Modelo, Vista, Controlador), ya
que es un estilo de arquitectura de software que separa los datos de una aplicación, la
interfaz del usuario, y la lógica de control, por lo que se separó los datos del sistema en
el siguiente detalle.
Fase de desarrollo
El objetivo en esta fase es realizar el desarrollo de los sprints previa planificación,
por lo que cada sprint contiene historias de usuario y cada una de ellas se relaciona con
un conjunto de tareas.
Sprint 1
El primer sprint pertenece al módulo de registro, el cual describe funcionalidades
de registro del administrador, registro de datos de vehículos, registro de datos de
conductores, creación y administración de las cuentas de los conductores, en la tabla 14
se observa las historias de usuario que corresponden al sprint 1.
Tabla N° 14: Historias de usuario de sprint 1
Puntuación de Estimación de
Id Historia de usuario
historia esfuerzo
Registro y visualización de datos
H001 5 8
del conductor
Registro y visualización de datos
H002 5 8
de vehículo
Registro de parte diario del
H008 6 9
vehículo
Elaboración propia
Sprint Burndown Chart 1
En base a la tabla anterior al sprint 1 se le ha asignado una duración de 25 días,
así mismo la puntuación total de historias de usuarios es 16, se estimó tener un avance
proporcional constante de 0.64 por día, en la figura 14 se muestra el avance diario que se
realizó en el desarrollo del Sprint 1.
67
Figura N° 15: Sprint Burndown Chart 1
Elaboración propia
Presentación del producto
En las figuras 16 y 17 de observa las vistas de registro de administrador y login del
administrador, supervisor y usuario.
Figura N° 16: Interfaz de registro de administrador o supervisor.

Elaboración propia
68
Figura N° 17: Login del administrador, usuario y supervisor.
Elaboración propia
En las figuras 18 y 19, se muestran las vistas de panel de control del administrador y
usuario (Conductor).
Figura N° 18:Vista principal de usuario (Conductor).

Elaboración propia
69
Figura N° 19:Interfaz Panel de control Administrador y Supervisor
Elaboración propia
En la figura 20 se muestra la interfaz gráfica del registro de conductor, en donde se
registran los principales datos como DNI, nombres, apellidos y el sistema o aplicativo
móvil genera un password aleatorio, el administrador brindara el usuario (DNI) y el
password generado al conductor, para que pueda acceder al sistema.
Figura N° 20: Interfaz gráfica de registro de conductores.

Elaboración propia
70
En las figuras 21 y 22, se observan la interfaces gráficas de registro de vehículo, cabe
recalcar que a cada vehículo se le asigna un conductor.
Figura N° 21: Interfaz de registro de vehículo parte 1

Elaboración propia
Figura N° 22: Interfaz de registro de vehículo parte 2

Elaboración propia
A continuación, en la figura 23, se muestra específicamente la vista en donde el
administrador deberá de seleccionar al conductor asignado al vehiculó que se está
registrara.
71
Figura N° 23: Vista de selección de conductor.
Elaboración propia
En las figuras 24 y 25, se muestra las interfaces graficas del registro de parte diario, el
cual deberá de ser registrado por el conductor, y el administrador deberá validar.
Figura N° 24: Interfaz de registro de parte diario.

Elaboración propia
Figura N° 25: Interfaz de registro de parte diario parte 2

Elaboración propia
72
En las figuras 27 y 26 se muestra el listado de vehículos y conductores registrados.
Figura N° 26: Listado de vehículos registrados.

Elaboración propia
Figura N° 27: Listado de conductores registrados.

Elaboración propia
Sprint 2
El segundo sprint pertenece al módulo de gestión, el cual describe las
funcionalidades de programar y aprobar ordenes de salida de las unidades vehiculares que
transitaran fuera de obra, también visualizar las notificaciones de ordenes aprobadas y
otros, en la tabla 15 se observa las historias de usuario que corresponden al sprint 2.
73
Tabla N° 15: Historias de Usuario de Sprint 1
Puntuación Estimación de
de historia esfuerzo
Programar y aprobar ordenes de salidas
H005 de las camionetas que transitaran fuera 7 12
de obra
H009 Visualizar Notificaciones 6 10
Elaboración propia
En base a la tabla anterior, al sprint 2 se le ha asignado una duración de 22 días,
Figura N° 28: Burndown Chart 2

Elaboración propia
En las figuras 29 y 30, se muestra las interfaces graficas para la programación de
ordenes de salida para los vehículos que transitan fuera de obra, la orden es aprobada por
el jefe de supervisión, para luego notificar al conductor que tiene programada una orden
de salida.
74
Figura N° 29: Interfaz de programación de orden de salida 1.
Elaboración propia
Figura N° 30: Vista de generación de orden de salida 2.

Elaboración propia
En la figura 31 muestra la interfaz del listado de ordenes de salidas programadas
en donde el supervisor aprueba o valida las ordenes de salidas generadas por el
administrador.
75
Figura N° 31:Interfaz de listado de notificaciones de ordenes de salida programadas.
Elaboración propia
Sprint 3
El tercer sprint pertenece al módulo de control y gestión, el cual describe las
funcionalidades de visualizar y descargar las ordenes de salida programadas de las
unidades vehiculares que transitaran fuera de obra, de igual forma los partes diarios
registrados por los conductores en la tabla 16 se observa las historias de usuario que
corresponden al sprint 3.
Tabla N° 16: Historias de usuario de Sprint 3.
historia esfuerzo
Visualizar y descargar el parte diario
H004 4 8
de cada uno de los vehículos
Visualizar y descargar las ordenes de
H006 4 8
salidas programadas
Elaboración propia
En base a la tabla anterior al sprint 3 se asignó, una duración de 16 días, así mismo
la puntuación total de historias de usuarios es 8, se estimó tener un avance proporcional
constante de 0.5 por día, en la figura 32 se muestra el avance diario que se realizó en el
desarrollo del Sprint 3.
76
Figura N° 32: Burndown Chart 3.
Elaboración propia
En la figura 33 y 34 se muestra el documento generado en PDF, de la orden de salida
registrado por el administrador, aprobado por el supervisor.
Figura N° 33:Vista de generación de orden de salida

Elaboración propia
77
Figura N° 34: Documento PDF de la orden de salida generado por el sistema.
Elaboración propia
En la figura 35 y 36 se muestra la interfaz de visualizar y descargar, en formato PDF el
parte diario registrado por el conductor y validado por el administrador.
Figura N° 35: Interfaz de visualizar y descargar parte diario.

Elaboración propia
78
Figura N° 36: Documento PDF de parte diario, generado por el sistema.
Elaboración propia
Sprint 4
El cuarto sprint pertenece al módulo de monitoreo, el cual describe las
funcionalidades de visualizar la ubicación en tiempo real de todas las unidades
vehiculares, así mismo visualizar el registro por fechas de la ruta recorrida de cada unidad
vehicular desde que sale de cochera hasta su ingreso, en la tabla 17 se observa las historias
de usuario que corresponden al sprint 4.
Tabla N° 17: Historias de usuario de Sprint 4

historia esfuerzo
Visualización en tiempo real la
H003 9 16
ubicación de cada uno de los vehículos.
Visualizar el registro diario de la ruta
H007 recorrida del día de cada uno de los 7 14
vehículos
Elaboración propia
En base a la tabla anterior al sprint 4 se le ha asignado una duración de 30 días,
79
Figura N° 37: Burndown Chart 4.
Elaboración propia
En las figuras 38 se muestra la interfaz gráfica para el monitoreo y visualización de la
ubicación de vehículos, en la figura 39 se muestra el panel de registro y búsqueda por
fecha de rutas recorridas de las unidades vehiculares.
Figura N° 38: Interfaz gráfica de monitoreo y control de vehículos en tiempo real.

Elaboración propia
80
Figura N° 39: Interfaz gráfica de recorrido de rutas de cada vehículo.
Elaboración propia
Fase de finalización
El objetivo de esta fase es finalizar el proceso de desarrollo de los sprints; instalar
las aplicaciones móviles para el lado usuario y administrador, se realizó las
pruebas para verificar el correcto funcionamiento de la aplicación, y finalmente la
entrega del producto quedando vacío el product backlog.
3.6.2. Evaluación del nivel de calidad del sistema
Para la implementación del sistema de control y monitoreo vehicular mediante
GPS, en el Consorcio San Miguel, previamente se realizó la evaluación a través de la
norma ISO/IEC 25000, que permite evaluar la calidad de los sistemas de información, los
requerimientos necesarios para la evaluación de calidad de software se muestran en la
tabla 18.
Tabla N° 18: Requerimientos para la evaluación de la calidad.
Tipo de calidad a medir Requerimientos

Historias de usuario
Calidad Interna y Calidad Externa Diseño
Código Fuente
Calidad en uso Usuarios, Clientes, Historias de usuario
Elaboración propia
81
La calidad del sistema de control y monitoreo vehicular, fue evaluada a través de
características y sub características, de la calidad interna, externa, y en uso según la
ISO/IEC 25000, las fórmulas utilizadas para la sumatoria de sub características y
características según la norma ISO/IEC 25000 son las siguientes.

∑𝑚 ∑ 𝑚𝑉𝑠𝑐
𝑉𝑠𝑐 = 𝑉𝑐 =
𝑛 𝑛𝑐𝑠
Donde: Donde:
Vsc: valor de la subcaracterísticas Vc: valor de la característica
m: valor de la métrica Vsc: valor de la sub característica
n: número de métricas nsc: número de sub características
En la tabla 19 se muestra un 87% de calidad interna obtenido en la evaluación, lo que
significa que el sistema tiene atributos de exactitud funcional, madurez, tolerancia a
fallos, capacidad para ser entendido, operatividad y reusabilidad, la figura 40 se ilustra
que la característica de facilidad de uso resalta con un 90% sobre las demás.
Tabla N° 19: Resumen de la evaluación de calidad interna según ISO/IEC
25000.
Sub Valor
Característica Métrica m Vsc Vc
característica total
Exactitud 0.85 0.85
Adecuación Exactitud
Precisión 0.83
funcional funcional 0.80 0.80
computacional
Eliminación de
0.86
errores
Madurez 0.88
Cobertura de
0.90
Fiabilidad Pruebas 0.89
Anulación de
Tolerancia a
operación 0.89 0.89
fallos
incorrecta 0.87
Capacidad para Funciones
0.92 0.92
ser entendido evidentes
Recuperabilidad
Facilidad de uso de error 0.91 0.90
Operatividad operacional 0.87
Claridad del
0.83
mensaje
Ejecución de
Mantenibilidad Reusabilidad 0.89 0.89 0.89
reusabilidad
Elaboración propia
82
Figura N° 40: Porcentaje de la evaluación de calidad interna según ISO/IEC 25000.
Elaboración propia
A continuación, en la tabla 20 se muestra un 89% de calidad externa, de la
evaluación, lo que significa que el sistema tiene atributos de adecuación funcional,
fiabilidad, eficiencia en el desempeño, facilidad de uso, seguridad y mantenibilidad, en la
figura 41 ilustra que la característica de seguridad resalta con un 92% sobre las demás
características.
Tabla N° 20: Resumen de la evaluación de calidad externa según ISO/IEC
25000.
Sub Valor
Característica Métrica M Vsc Vc
Completitud de la
Adecuación Completitud
implementación 0.89 0.89 0.89
funcional funcional
funcional
Tiempo medio
Madurez 0.80
entre fallos
Fiabilidad 0.83 0.83 0.89
Tiempo medio de
Disponibilidad 0.86
inactividad
Tiempo de
0.87
Eficiencia en Comportamiento respuesta
0.87 0.90
el desempeño en el tiempo
Tiempo de espera 0.86
83
(continuación…)
Utilización de Utilización de
0.93 0.93
recursos memoria
Número de
0.89
peticiones online
Capacidad 0.91
Numero de
accesos 0.93
simultáneos
Integridad de
Capacidad de 0.89
descripción
reconocer su 0.90
adecuación Capacidad de
0.91
demostración
Consistencia
0.89
operacional
Operatividad 0.89
Posibilidad de
0.89
Facilidad de personalización
0.89
uso
Verificación de
Protección 0.90
entradas validadas.
contra errores de 0.88
usuario Prevención del uso
0.85
incorrecto
Personalización de
Estética de la
la apariencia de la
interfaz del 0.90 0.90
interfaz del
usuario
usuario
Capacidad de
Confidencialidad 0.89 0.89
control de acceso
Seguridad 0.92
Métodos de
Autenticidad 0.95 0.95
autenticación
Complejidad de
0.89
Capacidad de ser modificación
0.89
modificado Índice de éxito de
Mantenibilidad 0.88 0.90
modificación
Capacidad de ser Capacidad de
0.84 0.92
probado reinicio de pruebas
Elaboración propia
84
Figura N° 41:Porcentaje de evaluación de calidad externa según ISO/IEC 25000.
Elaboración propia
En la tabla 21 se muestra un 93% de calidad en uso alcanzado en la evaluación, lo que
significa que el sistema tiene atributos de efectividad, eficiencia y satisfacción, a
continuación, en la figura 43 muestra que la característica de satisfacción resalta con un
95% sobre las demás características.
Tabla N° 21: Resumen de evaluación de calidad en uso según ISO/IEC 25000.
Sub Valor
Característica Métrica M Vsc Vc
Completitud de la
0.94
tarea
Efectividad Efectividad 0.94 0.94
Efectividad de la
0.94
tarea
Eficiencia en la
0.92
tarea
Eficiencia Eficiencia 0.91 0.91 0.93
Eficiencia relativa
0.89
de la tarea
Nivel de
0.95
satisfacción
Satisfacción Utilidad 0.95 0.95
Uso discrecional de
0.95
funciones
Elaboración propia
85
Figura N° 42:Porcentaje de evaluación de calidad en uso según ISO/IEC 25000.
Elaboración propia
En base a la anterior tabla 20, de resumen de evaluación de la calidad software aplicado
al sistema de control y monitoreo vehicular, en la figura 44 se muestra que el porcentaje
de calidad interna es de 87%, externa de 89% y calidad en uso de 93% obtenido en la
evaluación según ISO/IEC 25000.
Figura N° 43: Porcentaje de calidad interna, externa y en uso, obtenido, al evaluar el

sistema de control y monitoreo vehicular mediante GPS.
Elaboración propia
86
De acuerdo al grafico siguiente se denota que el sistema desarrollado tiene una calidad
total de 90% y por otro lado se denota que hace falta el 10% de calidad para tener una
calidad de 100%.
Figura N° 44: Nivel de calidad total obtenido, en la evaluación del sistema.

Elaboración propia
3.6.3. Evaluación de la eficiencia en el proceso de gestión vehicular
Después de la implantación del sistema de control y monitoreo vehicular, se
realizó dos cuestionarios de pre test y post test, a los administradores obra, asistentes
administrativos, jefes de supervisión, y asistentes de supervisor, de los proyectos que se
tomaron como muestra, con el fin de obtener la información necesaria para determinar el
nivel de mejora de la eficiencia en el proceso de gestión vehicular.
Prueba de Hipótesis
Planteamiento de la hipótesis
Para la prueba de hipótesis se formuló las siguientes hipótesis que serán
comprobadas en aplicación y prueba de resultados.
H0= Sin el sistema de control y monitoreo vehicular mediante GPS, mejora
la eficiencia en el proceso de gestión de vehículos.
H1= Con el sistema de control y monitoreo vehicular mediante GPS,
mejora la eficiencia en el proceso de gestión de vehículos.
87
Nivel de significancia
El nivel de significancia escogido es del 5% (α = 0.05), por lo que se
considera el nivel de confianza a 95% (1 – α =0.95).
Zona de rechazo
Para todo valor de probabilidad mayor que 0.05 se acepta la hipótesis nula
y se rechaza la hipótesis alternativa.
Estadístico de prueba
Para la muestra se ha evaluado a un total de 12 personas entre ellos
administradores de obra, asistentes administrativos, supervisores de obra
y asistentes de supervisión, por conveniencia se aplica la prueba de T
Student para validar la hipótesis, en base a los resultados obtenidos de las
dos encuestas pre test y post test.
Se desarrollo las encuestas pre test y post test dando la siguiente significancia de
alternativas.
Tabla N° 22: Valores asignados a las respuestas del cuestionario según escala
Likert.
Alternativa Valor
Muy Bueno 5
Bueno 4
Regular 3
Malo 2
Muy Malo 1
Elaboración propia
88
Los resultados de las encuestas pre test y post test, se describen en la tabla 23.
Tabla N° 23: Resultados fínales de encuestas pre test y post test
N°
Pre test Post test
encuesta
1 17 28
2 20 33
3 18 31
4 18 32
5 22 29
6 19 26
7 21 26
8 18 31
9 15 29
10 12 20
11 10 29
12 17 27
Elaboración propia
Procesamiento de datos
Para validar la hipótesis se realizó la prueba T-student para muestras relacionadas,
en la tabla 24, se muestra el resumen de los resultados obtenidos en el programa
especializado SPSS.
Tabla N° 24: Resultados prueba T-student.
Pre test Post test

Media 17.25 28.42
Varianza 12,205 12,083
Observaciones 12 12
Correlación de muestras emparejadas 0.254
Grados de libertad 11
Significancia bilateral (P-valor) 0.000
Valor α 0.05
Estadístico t 9.792
Valor critico t (α/2) 2.201
Elaboración propia
89
Criterio de decisión
− Si la probabilidad obtenida P-valor <= α, se rechaza la H0 y se acepta H1
− Si la probabilidad obtenida P-valor > α, se acepta la H1 y se rechaza la H0
Interpretación de resultados
Figura N° 45: Campana de Gauss.

Fuente: Tabla 24 resultados de prueba T student.
Puesto que el nivel de significancia escogido para la prueba es de 5%, siendo α =
0.05 y 11 grados de libertad, se obtiene el valor tabulado de t critico = 2,201, como t
calculado = 9.792 es mayor a t crítico, estando este dentro de la región de rechazo y que
el nivel de significancia obtenido en la prueba es 0.000 <= 0.05 es menor al error
permitido 5%, se rechaza la hipótesis nula y se acepta la hipótesis alterna, esto significa
que existe una diferencia significativa en las medias del pre test y post test, por lo tanto
se concluye que con el sistema de control y monitoreo vehicular mediante GPS mejora
significativamente la eficiencia en el proceso de gestión vehicular en la empresa
Consorcio San Miguel.
Para determinar el nivel de mejora de la eficiencia en el proceso de gestión
vehicular, en la figura 61 se muestra el promedio de respuestas de las 7 preguntas del
cuestionario realizado en el pre test y post test, según la escala Likert, considerando la
escala del 1 al 5.
90
Figura N° 46: Contrastación de pre test y post test según escala Likert.
Elaboración propia
En base a la figura anterior, se ha medido la variabilidad del nivel de mejora, tanto
en el pre test y post test, para lo cual se resume los valores obtenidos en la tabla 22,
considerando como base la escala Likert, para los cálculos se toma el valor 5 como el
100%.
Tabla N° 25: Indicador del nivel de mejora de la eficiencia en el proceso de
gestión vehicular.
Nivel de
Pre test Post Test
Impacto
2.46 49% 4.06 81% 1.60 32%
Elaboración propia
En la tabla 22 se observa que el nivel de la eficiencia en el proceso de gestión
vehicular, en el pre test obtuvo un puntaje de 2.46 con un porcentaje de 49% sin embargo,
el nivel de eficiencia en el proceso de gestión vehicular en el post test tiene un puntaje de
4.06 con un porcentaje de 81%, teniendo como nivel de impacto, un incremento de 1.60,
evidenciando de esta forma un nivel de mejora de un 32%.
91
Nivel de mejora de la productividad de acuerdo al tiempo de acceso a la
información
Tiempo de acceso a la información sin el sistema
Para determinar el tiempo de acceso a la información en el proceso de gestión de
unidades vehiculares sin el sistema de control y monitoreo vehicular mediante GPS, se
utilizó la unidad de “minutos”, con el cual se obtuvo el tiempo real y tiempo perdido
como se muestra en la tabla 26.
Tabla N° 26: Tiempo de acceso a la información en el proceso de gestión
unidades vehiculares sin el sistema.
Ítem Proceso de gestión de vehículos Tiempos
Tiempo Tiempo
Participantes Actividad
real perdido
Administrador de obra / Control y registro de

1 00:16:07 00:07:12
Asistente Administrativo vehículos

2 00:19:01 00:12:01
Asistente Administrativo conductores
3 Usuario/ Conductor Registro de parte diario 00:25:28 00:17:28
Administrador de obra / Validación de parte

4 00:16:55 00:06:42
Asistente Administrativo diario
Administrador de obra / Programación de orden

00:20:55 00:12:33
Asistente Administrativo de salida de vehículos
5
Supervisor de Obra / Aprobación de la orden
00:15:55 00:10:00
Asistente de supervisor de salida
92
(continuación…)
Notificación de orden
Usuario/ Conductor 00:16:55 00:13:11
de salida
Administrador de obra /
Asistente Administrativo
6 Monitoreo de vehículos 00:30:55 00:20:55
Supervisor de Obra /
Asistente de supervisor
Total 02:42:11 01:40:02
Total, en Minutos 162 100
Elaboración propia
Cálculo de la eficiencia de la productividad:
Eficiencia = (Tiempo Real – Tiempo Perdido) / Tiempo Real
Tabla N° 27: Porcentaje de la eficiencia de la productividad sin el sistema.
Tiempo Total
Tiempo real sin el sistema 162
Tiempo perdido con el sistema 100
Eficiencia de la productividad 38%
Elaboración propia
De los resultados que se muestra en la tabla anterior, se observa que el tiempo real
de acceso a la información es de 162 minutos con un tiempo perdido de 100 minutos,
durante el proceso de gestión de vehículos del consorcio san miguel, datos con el cual se
determinó que la productividad sin el sistema de control y monitoreo vehicular mediante
GPS, es eficiente en un 38%.
Tiempo de acceso a la información con el sistema
Para determinar el tiempo de acceso a la información en el proceso de gestión de
unidades vehiculares del consorcio san miguel con ayuda del sistema de control y
monitoreo vehicular mediante GPS, se utilizó la unidad de “minutos”, con el cual se
obtuvo el tiempo real y perdido de cada actividad del proceso.
93
Tabla N° 28: Tiempo de acceso a la información con ayuda del sistema.
Ítem Proceso de gestión de vehículos Tiempos

Tiempo Tiempo
Participantes Actividad
real perdido
1 00:04:07 00:00:40
Asistente Administrativo vehículos
2 00:04:23 00:00:58
Asistente Administrativo Conductores
Registro de parte
3 Usuario/ Conductor 00:04:20 00:00:57
diario
Administrador de obra / Validación de parte
4 00:01:12 00:00:22
Asistente Administrativo diario
Administrador de obra / Programación de orden
00:05:01 00:00:33
Asistente Administrativo de salida de vehículos
Supervisor de Obra / Aprobación de la

00:02:20 00:00:47
5 Asistente de supervisor orden de salida
Notificación de orden
Usuario/ Conductor 00:01:05 00:00:34
de salida
Administrador de obra /
Asistente Administrativo Monitoreo de
6 00:02:15 00:00:55
Supervisor de Obra / vehículos
Asistente de supervisor
00:24:43 00:05:46
24 05
Elaboración propia
Cálculo de la mejora de la eficiencia en la productividad con ayuda del sistema
Tabla N° 29: Nivel de eficiencia en la productividad con ayuda del sistema.
Total
Tiempo
Tiempo real con el sistema 24
Tiempo perdido con el sistema 05
Eficiencia de la productividad 79%
Elaboración propia
94
De los resultados que se muestra en la tabla anterior, se observa que el tiempo
real, de acceso a la información con ayuda del sistema de control y monitoreo vehicular
mediante GPS, durante el proceso de gestión de vehículos del Consorcio San Miguel
es de 24 minutos, con un tiempo perdido de 5 minutos, datos con el cual se determinó
que la productividad con ayuda del sistema, es eficiente en un 79%.
Tabla N° 30: Nivel de impacto de la eficiencia de la productividad con y sin
el sistema.
Tiempo Tiempo
Eficiencia de la productividad %
Real perdido
Sin el sistema 162 100 38%
Con el sistema 24 5 79%
Nivel de Impacto 138 95 31%
Elaboración propia
En la tabla 30 se puede observar que el nivel de la eficiencia de la productividad
de acuerdo al tiempo de acceso a la información en el proceso de gestión vehicular, sin
el sistema obtuvo como tiempo real 162 minutos, con un tiempo perdido de 100
minutos, obteniendo un porcentaje de 38% sin embargo, el nivel de eficiencia de la
productividad con ayuda del sistema de control y monitoreo vehicular mediante GPS
en el proceso de gestión vehicular, tiene un tiempo real de 26 minutos con un tiempo
perdido de 5 minutos, logrando un porcentaje de 79%, teniendo como nivel de impacto
la disminución del tiempo de acceso a la información en 136 minutos, en tal sentido se
evidencia un nivel de mejora del en 31%, en la eficiencia de la productividad, logrando
reducir el tiempo de acceso a la información de 162 minutos a 24 minutos, con ello se
reafirma los resultados obtenidos en la prueba T-Student de muestras relacionadas.
95
3.7. DISCUSIÓN
En la presente investigación, se demuestra de manera clara y detallada que
Scrum es una metodología ideal para la implementación del sistema de control y
monitoreo de vehículos mediante GPS, por ser iterativa y adaptable a los cambios.
De acuerdo a la ISO/IEC 25000, que permite medir la calidad de un sistema
basado en tres enfoques, calidad interna, calidad externa y calidad de uso, en la presente
investigación se aplicó y evaluó el sistema de control y monitoreo de vehículos
mediante GPS, en base a las métricas solidas que nos da como referencia la ISO/IEC
25000 permitiendo establecer la calidad necesaria del sistema, con la finalidad de evitar
percances en la ejecución e implantación del sistema.
Haciendo uso de las herramientas estadísticas software SPSS, Google Forms y
Excel, se ha medido la variabilidad del nivel tanto en el pre test 49% y el post test 81%,
evidenciando de esta forma una mejora significativa de la eficiencia en el proceso de
gestión de vehículos en el Consorcio San Miguel en un 32%, es así como se acepta la
hipótesis alterna y se rechaza la hipótesis nula.
Cabe precisar que con la implementación del sistema de control y monitoreo
vehicular mediante GPS, basado en un aplicativo móvil, se mejoró significativamente
la eficiencia en el proceso de gestión de vehículos , ya que se disminuyó el tiempo de
generación y aprobación de ordenes de salida , el registro y validación de partes diarios,
así mismo se logró visualizar la ubicación real de cada uno de los vehículos asignados
a cada proyecto ya que el sistema siendo un aplicativo móvil, tiene la ventaja de realizar
estos procesos desde cualquier lugar solo con un dispositivo móvil, como se muestra
en los resultados de la eficiencia en la productividad de acuerdo al tiempo de acceso a
la información, en donde se determinó el nivel de mejora en un 31%, logrando
disminuir el tiempo de acceso a la información de 162 minutos a 24 minutos.
96
De esta manera se mejoró la eficiencia en el proceso de gestión vehicular, en
las obras del Consorcio San Miguel que se tomaron como muestra, las cuales se vieron
beneficiadas financiera y productivamente.
El sistema de control y monitoreo vehicular mediante GPS, mejoro
significativamente la eficiencia en el proceso de gestión vehicular en el Consorcio San
Miguel, este resultado guarda relacion con los resultados de Flores (2016), en donde
concluye que el modelo de control, seguimiento y monitoreo satelital en tiempo real de
usuarios móviles mediante el uso de teléfonos celulares mejoró significativamente la
gestión y el control del personal y Chuquija (2019), el cual concluyo que el desarrollo
de una aplicación móvil de geolocalización mejoró significativamente el control y la
gestión de la seguridad en conductores de la empresa de taxi Exitoso E.I.R.L.
97
V. CONCLUSIONES
PRIMERO: Se identifico el nivel de la mejora de la eficiencia, a través de los
resultados e indicadores estadísticos, aplicando la prueba T-Student de muestras
relacionadas, que permitió determinar el nivel de mejora significativa de la eficiencia
en el proceso de gestión vehicular, por lo que se concluye que con el sistema de control
y monitoreo vehicular mediante GPS se mejora significativamente la eficiencia en el
proceso de gestión vehicular en un 32%, siendo este un resultado favorable para la
SEGUNDO: Se logro desarrollar el sistema de control y monitoreo vehicular
mediante GPS basado en una aplicación móvil, aplicando la metodología SCRUM en
donde se identificaron 9 historias de usuario y se obtuvo la arquitectura del sistema con
un total de 28 interfaces.
TERCERO: Se estableció el nivel de calidad del sistema, aplicando la norma
ISO/IEC 25000 para la evaluación de calidad de software SQuaRE (calidad Interna,
calidad externa, y calidad en uso), de los resultados de la evaluación de software, se
determinó un 90% de calidad total y un 10% de calidad faltante.
CUARTO: Se determino el nivel de mejora de la eficiencia de la productividad
de acuerdo al tiempo de acceso a la información, para la gestión de unidades
vehiculares, con ayuda del sistema de control y monitoreo vehicular mediante GPS, en
donde se identificó el nivel de mejora en un 31 %, es decir se logró disminuir el tiempo
de acceso a la información de 162 minutos a 24 minutos, por ende se reafirma los
resultados obtenidos en la prueba T-Student de muestras relacionadas.
98
VI. RECOMENDACIONES
PRIMERO: Se recomienda hacer uso de una metodología ágil para la
elaboración del producto software como SCRUM, ya que ha demostrado ser eficaz para
el desarrollo de proyectos brindando respuestas con mayor agilidad, calidad y
satisfacción en el menor tiempo posible, así mismo aplicar la norma ISO/IEC 25000
para la evaluación de calidad de software, siendo este el resultado de la evolución de la
ISO/IEC 1926, cabe mencionar que la norma ISO 25000 establece criterios para la
especificación de requisitos de calidad y métricas para su evaluación.
SEGUNDO: Se recomienda el uso de firebase como servidor backend para la
obtención de datos en tiempo real y el enfoque API REST para una comunicación
mediante JSON entre servidores, bases de datos y usuarios, con una arquitectura que se
adapte al proyecto.
TERCERO: Se recomienda que se documente todos los procesos informáticos,
de desarrollo del sistema de control y monitoreo vehicular mediante GPS, ya que
posteriormente pueden ser utilizados como marco de referencia, para la
implementación de próximos módulos y realizar el estudio de nuevos módulos para la
mejora de los diferentes procesos de una organización.
CUARTO: Se recomienda, la evaluación de la eficiencia en base a tiempos, ya
que puede enriquecer la información para el análisis y brindar resultados
científicamente fundamentados.
99
VII. REFERENCIAS
Alvarez M, I., & Joiz.Net. (2018). Desarrollo agil con SCRUM.
Android Developers. (2019). Descripción general de Kotlin.
https://developer.android.com/kotlin/overview?hl=es-419
Android Developers. (2020). Android Developers.
https://developer.android.com/guide/platform?hl=es-419
Aristasur. (2010). Sistema de Coordenadas Geográficas: Longitud y Latitud.
https://www.aristasur.com/contenido/sistema-de-coordenadas-geograficas-longitud-y-
latitud
AristaSur. (2010). Sistema de Coordenadas Geográficas: Longitud y Latitud.
https://www.aristasur.com/contenido/sistema-de-coordenadas-geograficas-longitud-y-
latitud
Avalos Felipe, G., & Alva Garces, O. A. (2017). Diseño y Construccion de un Sistema de
Rastreo Vehicular por Satelite Activo Mediante el uso de las tecnologias GPS, GLONASS,
GSM, GPRS y WiFi. UNAM.
Balseca Chisaguano, E. A. (2016). Evaluacion de la calidad de productos software en empresas
del desarrollo software aplicando la norma ISO/IEC 25000. Escuela Plitecnica Nacional
- Quito Ecuador.
Bashualdo Quinto, J. C. (2017). Implementacion de un sistema de monitoreo satelital por GPS
para los vehiculos de la municipalidad distrital de chancay 2017. Uladech Catolica.
Cano Pita, G. E. (2018). Las TICs en las empresas: evolucion de la tecnologia y cambio
estructural en las organizaciones.
Chuquija Aracayo, E. (2019). Aplicacion movil de geolocalizacion para el control y la gestion
de la seguridad en conductores de la Empresa de Taxi Exitoso E.I.R.L. Juliaca 2019.
D. Sousa, V., Driessnack, M., & Costa Mendes Isabel, A. (2007). Revision de diseños de
investigacion. Scielo.
Daniel Salazar, R. J. (2020). Introduccion a la administracion: Paradigmas en las
100
Organizaciones. https://www.eumed.net/libros-gratis/2011e/1090/sistema.html
Diaz Aparicio, M. Y. (2019). La implementacion de las TICs hace mas competitivas a las
organizaciones.
Dpto. de Ciencia de la Computacion e Inteligencia Artificial. (2014). Desarrollo de
aplicaciones para Android. Universidad de Alicante.
http://www.jtech.ua.es/cursos/apuntes/moviles/daa2013/
Fernandez, Y. (2018). GPS en Android: cómo funciona, cómo mejorar su precisión y cómo
decidir qué aplicaciones lo usan. Xataka. https://www.xataka.com/basics/gps-android-
como-funciona-como-mejorar-su-precision-como-decidir-que-aplicaciones-usan
FLIIT BY PROSEGUR. (2019). ¿Qué es la gestión de vehiculos o flotas?
https://www.fliit.com/blog/que-es-la-gestion-de-flotas
Flores Humpiri, R. (2016). Modelo de control, seguimiento y monitoreo satelital en tiempo real
de usuarios moviles mediante el uso de telefonos celulares, para el control y la gestion
de personal de campo de la entidad financiera Caja Rural de Ahorro y Credito los Andes
S.A. (Universidad Nacional del Altiplano (ed.)).
Gallego, A. J. (2017). Introduccion al desarrollo de aplicaciones android (GitBook (ed.)).
GPS.Gov. (2015). El sistema de Posicionamiento global.
https://www.gps.gov/systems/gps/spanish.php
Herazo, L. (2021). AN INCUBATOR - Tecnologia Movil. https://anincubator.com/que-es-una-
aplicacion-movil/
Hernandez Sampieri, R., Collado Fernandez, C., & Baptista Lucio, M. del P. (2014).
Metodologia de la Investigacion (S. A. D. C. V. McGRAW-HILL / INTERAMERICANA
EDITORES (ed.)).
INEI. (2018). Principales Resultados de la Encuesta Nacional de Empresas 2015.
INEI. (2020). Tecnologias de Informacion y Comunicaciones en las empresas.
ISO/IEC 25000. (2018). Software producto quality life cycle model (G. to SQuaRE (ed.)).
ISO 25000. (2021). ISO 25000 Calidad de Software y datos. Portal ISO 25000.
https://iso25000.com/index.php
101
Lopez, S. (2020). Firebase qué es, para qué sirve, funcionalidades y ventajas. Digital55.
https://www.digital55.com/desarrollo-tecnologia/que-es-firebase-funcionalidades-
ventajas-conclusiones/
Maria Aguilar, J. (2019). ¿Qué es el patrón MVC en programación y por qué es útil?
https://www.campusmvp.es/recursos/post/que-es-el-patron-mvc-en-programacion-y-por-
que-es-util.aspx
Martinez Perez, E. M., Gonzales Magaña, H. E., Margarita Pineda, E., & Hernandez Avila, R.
E. (2018). Desarrollo de una aplicacion movil para orientacion mediante GPS. 3–4.
Merchan Riera, J. M., Moreno Rodriguez, C., Josuepht, Lopez Franco, M. L., & Santamaria
Yagual, J. A. (2017). El impacto de las aplicaciones moviles en la gestion empresarial en
Latinoamerica. 2–5.
Mobile Marketing Association. (2018). Latin America Is Fastest-Growing Mobile Ad Market.
Pavesi, P. (1996). La teoria de la Decision (Fce (ed.)).
Peralta, A. (2003). Metodologia SCRUM (Universidad ORT (ed.)).
Pressman, R. (2010). Ingenieria de Software un enfoque practico (McGRAW (ed.)).
Pulpomatic. (2021). Webinar Gratuita: Eficiencia en la gestión de flotas vehiculares. Eficiencia
En La Gestión de Flotas Vehiculares. https://forodelogistica.com/eficiencia-en-la-
gestion-de-flotas-vehiculares/
Sateliun. (2021). Gestión y organización de una flota de vehículos. | Blog Sateliun.
https://www.sateliun.com/gestion-y-organizacion-de-una-flota-de-vehiculos/
Servin, L. (2018). ¿Por qué es importante el control interno en las empresas?
https://www2.deloitte.com/py/es/pages/audit/articles/opinion-control-interno-
empresas.html
Sevilla Arias, A. (2016). Productividad - Qué es, definición y concepto | 2021 | Economipedia.
https://economipedia.com/definiciones/productividad.html
SiliconNews. (2019). MongoDB que es y como funciona?
https://siliconnews.plataformasinc.es/mongodb-como-funciona/
Soto Mejia, J., Solarte Martinez, G. R., & Muñoz Guerrero, L. E. (2019). Localización del
102
punto óptimo de partida en el problema de ruteo vehicular con capacidad restringida
(CVRP). Scielo. https://doi.org/https://doi.org/10.14483/22487638.13653
Stafford Beer, A. (1966). Cibernetica y Administracion Industrial. Wiley.
Van Gigch, J. P. (1987). Teoria General de Sistemas Aplicada. Trillas.
Villegas, F. (2020). Relatividad y el sistema de Posicionamiento Global (GPS). Revista de
Investigacion de Fisica - UNSA. https://revistasinvestigacion.unmsm.edu.pe
Westreicher, G. (2020). Gestión - Qué es, definición y concepto | 2021 | Economipedia.
https://economipedia.com/definiciones/gestion.html
Westreicher, G. (2021). Ineficiencia - Qué es, definición y concepto | 2021 | Economipedia.
https://economipedia.com/definiciones/ineficiencia.html
Yirda, A. (2021). ¿Qué es Eficiencia? » Su Definición y Significado [2021].
https://conceptodefinicion.de/eficiencia/
103
ANEXOS
Anexo A: Resultados de encuesta pre test y post test
Resultados de Encuesta pre test
104
Figura N° 47: Resultados de encuesta pre test.
Fuente: Google Forms
105
Resultados de encuesta post test
106
Figura N° 48: Resultados de encuesta post test.
Fuente: Google Forms
107
Anexo B: Proceso de gestión vehicular sin el sistema
Evidencia del proceso de gestión vehicular antes del sistema de control y monitoreo
vehicular mediante GPS.
− Control y registro de vehículos
Figura N° 49:Control y registro de vehículos sin el sistema.
Fuente: Archivo documentos de control CSM – Proyecto Los negros
− Control y registro de conductores
Figura N° 50: Control y registro de vehículos sin el sistema.

Fuente: Archivo documentos de control CSM – Proyecto Los negros
108
− Registro y validación de parte diario
Figura N° 51: Registro y validación de parte diario sin el sistema

Fuente: Archivo de documentos de control CSM – Proyecto Cleopatra
− Programación de orden de salida
Figura N° 52: Programación y aprobación de orden de salida de vehículos sin el

sistema.
Fuente: Archivo de documentos de control CSM – Proyecto Esquilache
109
Anexo C: Proceso de gestión vehicular con ayuda del sistema
− Control y registro de vehículos
Registro de vehículos
Registro Control General
Figura N° 53: Registro de vehículos con el sistema.

Elaboración propia
Control de vehículos
Proyecto Esquilache Proyecto Los Negros Proyecto Cleopatra
Figura N° 54:Control de conductores con el sistema.

Elaboración Propia
110
− Control y registro de conductores
Registro de conductores:
Registro Control General
Figura N° 55:Registro de conductores con el sistema.

Elaboración propia
Control de conductores por obra

Proyecto Esquilache Proyecto Los Negros Proyecto Cleopatra
Figura N° 56: Control de conductores con el sistema.

Elaboración propia
111
− Registro y validación de partes diarios
Registro de parte diario

Vista A Vista B
Figura N° 57: Registro de parte diario con el sistema.

Elaboración propia
Validación de parte diario

Documento PDF
Visualización y registro Notificación
Generado
Figura N° 58: Validación de parte diario con el sistema.

Elaboración propia
112
− Programación y aprobación de ordene de salida
Programación de orden de salida

Registro -Administrador Validación - Supervisor Documento PDF Generado Notifica - Usuario
Figura N° 59: Programación de orden de salida con el sistema.

Elaboración propia
113
− Monitoreo de personal
Monitoreo de vehículos mediante GPS

Visualizacion en tiempo real
Ruta Proyecto Esquilache Proyecto Los Negros Proyecto Cleopatra
Figura N° 60: Monitoreo de vehículos mediante GPS.

Elaboración propia
114
Anexo D: Procedimiento de métricas seleccionadas para evaluación de la calidad
interna
Valor Recursos
C Sc Métrica Propósito Método Formula
deseado utilizados
X=A/B
Contar el número de
Exactitud ¿Cuánto del A= Numero de fallas 0<=X<=1
fallas corregidas en la Historias de
estándar requerido corregidas El más
fase de usuario, código
Adecuación funcional
Exactitud funcional
de exactitud se B = Numero de fallas cercano a 0

diseño/codificación/prue fuente
cumple? detectadas en las pruebas. es mejor
bas
Donde B>0
computacional
X= A/T X= A/T
¿Con que Contar el número de
Precisión
A=Numero de cálculos El más

frecuencia ocurren cálculos inexactos Código fuente,
inexactos encontrados. donde el
los resultados encontrados y tomar el desarrollador
T=Tiempo de operación. peor caso es
inexactos? tiempo de operación
Donde T>0 >=10/t
Contar el número de Historias de

X=A/B
Eliminación de
fallas corregidas en la usuario, código

A=Número de fallas 0<=X<=1
¿Cuántos errores fase de fuente, casos de
errores
corregidas. El más
detectados han sido diseño/codificación/ pruebas,
B=Numero de fallas cercano a 0
corregidos? pruebas y el número de desarrollador.
detectadas en las pruebas es mejor
fallas detectadas en las
Donde: B>0
pruebas
Madurez
X=A/B
Cobertura de Pruebas
A=Número de casos de
Contar el número de Historias de
¿Cuántos casos de pruebas realizadas en un
casos de pruebas 0<=X<=1 usuario, código
prueba requeridos escenario de operación
Fiabilidad
realizados y el número El más fuente, casos de

han sido ejecutados durante la prueba
de casos de prueba a ser cercano a 0 pruebas,
durante la etapa de B=Numero de pruebas a ser
realizados para cubrir es mejor desarrollador.
pruebas? realizadas para cubrir los
los requerimientos.
requerimientos
Donde: B>0
X=A/B
Tolerancia a fallos
A=Número de operaciones
Anulación de
¿Cuentas funciones funciones Historias de

incorrectas 0<=X<=1
incorrecta
operación
son implementadas implementadas que usuario, código

B=Número total de El más
con capacidad de evitan fallas críticas y fuente,
funciones implementadas cercano a 0
anular operaciones serias causadas por desarrollador.
para anular operaciones es mejor
incorrectas? operaciones incorrectas
incorrectas.
presentadas
Donde: B>0
X=A/B
Capacidad para
ser entendido
¿Qué cantidad de Contar el numero de

A=Numero de funciones 0<=X<=1
Funciones
evidentes
funciones del funciones que son

evidente al usuario El más
producto son evidente al usuario y Código fuente
B=Número total de cercano a 0
evidentes al comparar con el número
funciones es mejor
usuario? total de funciones
Donde B>0
Contar el numero de X=A/B
Facilidad de uso
Recuperabilida
funciones A=Numero de funciones

operacional
¿Qué cantidad de 0<=X<=1

d de error
implementadas con implementadas con

funciones pueden El más
tolerancia de error de tolerancia de error de Código Fuente
tolerar errores de cercano a 0
usuarios y el numero usuarios y numero total de
usuario? es mejor
Operatividad
total de funciones con funciones requeridas con

capacidad de tolerancia. capacidad de tolerancia
X=A/B
Contar el numero de
A=El numero de mensajes
Claridad del
mensajes 0<=X<=1 Especificación de

mensaje
¿Qué cantidad de implementados con

implementados con El más requerimientos,
mensajes son auto explicaciones claras.
explicaciones claras y cercano a 0 código fuente,
explicativo? B=Numero total de
el número de mensajes es mejor desarrollador.
mensajes implementados.
implementados.
Donde: B>0
Mantenibilidad
Reusabilidad
Ejecución de
reusabilidad
X=A/B A=Número de 0<=X<=1

¿Cuántos elementos reutilizados y
elementos reutilizados. El más
elementos pueden el numero de elementos Código fuente
B=Número total de cercano a 0
ser reutilizados? utilizado de la biblioteca
elementos de la biblioteca. es mejor
reutilizable.
Figura N° 61: Procedimiento para la evaluación de la calidad interna.

Fuente: Adaptado de Balseca (2016)
115
Anexo E: Procedimiento de métricas seleccionadas para evaluación de la calidad
externa
Valor Recursos
C Sc Métrica Propósito Método Formula
deseado utilizados
Contar el número de las X=A/B
implementación
Completitud de
¿Cuán completa es la funciones indicadas en A=Numero de Historias de
Completitud
Adecuación
0<=X<=1
funcional
funcional
funcional
implementación de la especificación de funciones incorrectas o usuario,
El más
la
acuerdo a la requerimientos y el no implementadas. código
cercano a
especificación de número de funciones B=Numero de fuente,
0 es mejor
requerimientos? que faltan o están funciones establecidas desarrollador
incorrectas en las especificaciones
X=AT
X=A/T
medio entre
Tomar el tiempo de A=Numero de fallas Historias de

Madurez
Tiempo
¿Cuál es la frecuencia El más

fallos
operación y contar el detectadas usuario,

en que el sistema falla cercano a
número total de fallas T=Tiempo de desarrollador,
en la operación? 0/t es
detectadas actualmente operación tester
Fiabilidad
mejor
Donde: T>0
X=AT
Disponibilidad
Tiempo medio
de inactividad
X=A/T
¿Cuál es el tiempo A=Numero de fallas Historias de
Tomar el tiempo total El más
promedio que el detectadas usuario,
de inactividad y contar cercano a
sistema esta inactivo T=Tiempo de desarrollador,
el número de fallos 0/t es
después de algún fallo? inactividad tester
mejor
Donde: T>0
X= B – A 0<=X<=1
Historias de
Comportamiento en el tiempo
Tiempo de
Tomar el tiempo desde A= Tiempo de envió de El más

respuesta
¿Cuál es el tiempo usuario,

que se envía la petición petición cercano a
estimado para código
hasta obtener la B= Tiempo en que 0 mejor, y
completar una tarea? fuente,
respuesta. recibe la primera el peor
desarrollador
respuesta >=15t
0<=X<=1
¿Cuál es el tiempo Historias de
X= B – A
Tiempo de
Tomar el tiempo El más

desde que se envía una usuario,
espera
cuando se inicia un A= Tiempo de inicio cercano a

instrucción para que código
trabajo y el tiempo en B= Tiempo en 0 mejor, y
inicie un trabajo, hasta fuente,
completar el trabajo completas el trabajo el peor
Eficiencia en el desempeño
que lo completa? desarrollador

>=15t
X= B – A
Medir la cantidad total Historias de
de memoria
de recursos
Utilización
Utilización
A= Cantidad de 0<=X<=1
¿Cuánto espacio de de espacio de memoria usuario,
espacios de memoria El más
memoria es usado para y la cantidad de código
real. cercano a
realizar una tarea dada? espacios de memoria fuente,
B= Cantidad total de 0 mejor
real desarrollador
espacio de memoria
X=A/T 0<=X<=1
Contar el número Historias de
Número de
¿Cuántas peticiones A=Número máximo de El más

peticiones
máximo de peticiones usuario,

online
online pueden ser peticiones online cercano a

online procesadas y código
procesadas por unidad T=Tiempo de 0 mejor, y
tomas el tiempo de fuente,
Capacidad
de tiempo? operación el peor

operación desarrollador
Donde: T>0 >=10t
X=A/T
¿Cuántos usuarios Historias de
simultáneos
Numero de
Contar el número A=Número máximo de X=A/T

accesos
pueden acceder al usuario,

máximo de accesos accesos simultáneos. El más
sistema código
simultáneos y tomar el T=Tiempo de lejano a 0/t
simultáneamente en un fuente,
tiempo de operación operación es mejor
tiempo cierto? desarrollador
Donde: T>0
X=A/B Historias de
Integridad de
¿Qué cantidad de funciones descritas

descripción
A=Numero de 0<=X<=1 usuario,

funciones son descritas como entendibles en la
Capacidad de reconocer su adecuación
funciones entendibles El más código

como entendibles en la descripción del
B=Número total de cercano a fuente,
descripción del producto y contar el
funciones 0 mejor desarrollador,
producto? número total de
Donde: B>0 tester
funciones.
X=A/B
Contar el número de A=Numero de
funciones funciones
Historias de
Capacidad de
demostración
implementadas con implementadas con

¿Qué cantidad de 0<=X<=1 usuario,
Facilidad de uso
capacidad de capacidad de
funciones tienen la El más código
demostración y contar demostración.
capacidad de cercano a fuente,
el número total de B=Número total de
demostración? 0 mejor desarrollador,
funciones que funciones que
tester
requieren capacidad de requieren
demostración. demostración.
Donde: B>0
X=A/B
Contar el número de A=Número de
operaciones que se operaciones que se Historias de
Operatividad
Consistencia
operacional
¿Cuántas operaciones comportan de manera comportan de manera 0<=X<=1 usuario,

similares pueden incoherente y el incoherente El más código
llevarse a cabo número total de B=Número total de cercano a fuente,
consecuentemente? operaciones que se operaciones que se 1 mejor desarrollador,
comportan de forma comportan de forma tester
normal normal
Donde: B>0
116
Contar el numero de X=A/B
funciones A=Numero de
implementadas que funciones Historias de
personalización
Posibilidad de
¿Cuántas funciones y
pueden ser implementadas que se 0<=X<=1 usuario,
procedimientos
personalizados durante personalicen El más código
operacionales puede un
la operación y el B=Número total de cercano a fuente,
usuario modificar para
numero de funciones funciones que 1 mejor desarrollador,
su conveniencia?
que requieran la requieren tester
capacidad de personalización
personalización Donde: B>0
X=A/B
A=Numero de ítems Historias de
Verificación de
validados 0<=X<=1 usuario,
validadas.
entradas
¿Qué cantidad de ítems ítems de entrada que
B=Número de ítems El más código
de entrada son son validados y el
que requieren ser cercano a fuente,
Protección contra errores de usuario
validados? número de ítems que

validados 1 mejor desarrollador,
necesitan ser validados
Donde: B>0 tester
X=A/B
A=Numero de
Prevención del uso incorrecto
operaciones iniciales
Contar el numero de
incorrectas
funciones Historias de
B=Número de
¿Cuántas funciones implementadas para 0<=X<=1 usuario,
funciones
tiene la capacidad de enviar fallos de El más código
implementadas para
evitar operaciones funcionamiento y el cercano a fuente,
evitar fallos de
incorrectas? numero total de 1 mejor desarrollador,
funcionamiento
operaciones iniciales tester
provocados por un uso
incorrectas
incorrecto
Donde: B>0
X=A/B
Contar el numero de
Personalización de
la apariencia de la
A=Numero de Historias de
Estética de la
¿Qué cantidad de los tipos de elementos de

interfaz del
interfaz del
elementos de interfaz 0<=X<=1 usuario,

elementos de interfaz interfaz que pueden ser
usuario
usuario
que se personalizan El más código

de usuario pueden ser personalizados y contar
B=Número total de cercano a fuente,
personalizados en el numero total de tipos
elementos de interfaz 1 mejor desarrollador,
apariencia? de elementos de
Donde: B>0 tester
interfaz
X=A/B
Capacidad de control
Contar el numero de A=Número de

Confidencialidad
Historias de
diferentes tipos de diferentes tipos de
0<=X<=1 usuario,
de acceso
¿Qué tan controlable operaciones ilegales operaciones ilegales

El más código
son los accesos al detectados y el numero detectados.
cercano a fuente,
sistema? de tipos de operaciones B=Número total de
1 mejor desarrollador,
Seguridad
ilegales en la operaciones ilegales

tester
especificación Donde: B>0
X>=0 Historias de
Autenticidad
autenticació
Métodos de
¿Qué tan bien el X=A Donde X usuario,

Contar con el número
sistema autentica la A= Numero de es mayor a código
de métodos de
n
identidad de un sujeto o métodos de 0, siendo fuente,

autenticación previstos
recurso? autenticación previstos X el mejor, desarrollador,
>= 2 tester
X=A/T
A=Número de
Complejidad de
¿Con que facilidad el Tomar el tiempo de

modificación
modificaciones X=A/T
desarrollador puede trabajo que le toma al
T=Tiempo de trabajo El mas
modificar el software desarrollador modificar Desarrollador
que demora el lejano a 0/t
para resolver y contar el número de
Capacidad de ser modificado
desarrollador en es el mejor
problemas? modificaciones
modificar
Donde: T>0
X=A/B
A=Número de
Contar el numero de problemas dentro de un
Índice de éxito de
problemas dentro de un determinado periodo

modificación
Mantenibilidad
¿Hasta que punto puede determinado periodo antes de 0<=X<=1

el sistema ser operado antes de mantenimiento mantenimiento. El más
Desarrollador
sin fallas después del y contar el numero de B=Número de cercano a
mantenimiento? problemas en el mismo problemas en el mismo 0 mejor
periodo después del periodo después del
mantenimiento mantenimiento.
Donde: B>0
X=A/B
Contar el numero de
Capacidad de reinicio
A=Número de casos en
Capacidad de ser
casos en los cuales el

¿con que facilidad se los cuales el
de pruebas
mantenedor puede 0<=X<=1

probado
puede llevar a cabo las mantenedor puede

pausar y restaurar las El más Desarrollador
pruebas nuevamente pausar y restaurar
pruebas y contar el cercano a / tester
después del B= Número de casos de
numero de casos de 1 mejor
mantenimiento? pausa en la ejecución
pausa en la ejecución
Donde: B>0
de pruebas
Figura N° 62: Procedimiento para la evaluación de la calidad externa del sistema.

117
Anexo F: Procedimiento de métricas seleccionadas para evaluación de la calidad
en uso
Valor Recursos
C Sc Métrica Propósitos Método Formula
deseado utilizados
Contar el X=A/B
Completitud
¿Qué cantidad de número de A=Numero de 0<=X<=1

de la tarea
tareas son tareas tareas completadas El más Usuario

completadas completadas y el B=Numero de total cercano a
correctamente? número total de de tareas intentadas 1 es mejor
tareas intentadas Donde: B>0
Efectividad
Efectividad
X=A/B
Efectividad de la tarea
Tomar el valor A=Cantidad de

proporcional de objetivos
¿Qué cantidad de 0<=X<=1
cada completados por la
los objetivos de la El más Usuario
componente tarea
tarea se realiza cercano a
faltante o B=Cantidad de
completamente? 1 es mejor
incorrecto en la objetivos planeados
salida de la tarea que realiza la tarea
Donde: B>0
Contar el X=A/T
X=A/T
Eficiencia en
numero de A=Numero de
¿Qué tan El mas
la tarea
tareas efectivas tareas efectivas

eficientes son los lejano a Usuario
y tomar el T=Tiempo de la
usuarios? 0/t es el
tiempo de la tarea
mejor
tarea Donde: T>0
Contar el
Eficiencia
Eficiencia
Eficiencia relativa de la
numero de X=A/B
tareas eficientes A=Numero de
Usuario,
¿Qué tan eficiente realizadas por tareas eficientes por 0<=X<=1
Especifica
tarea
es un usuario un usuario usuario El más

ciones de
comparado con lo ordinario y B=Numero de cercano a
requerimie
planeado? contar el tareas eficientes 1 es mejor
nto
numero de planeadas
tareas eficientes Donde: B>0
planeadas
X=A/B
A= Numero de
Realizar un
satisfacción
preguntas con 0<=X<=1

Nivel de
¿Qué tan cuestionario

respuesta El más
satisfecho está el sobre el nivel de Usuario
satisfactoria cercano a
usuario? satisfacción
B=Número total de 1 es mejor
sobre el sistema
preguntas
Donde: B>0
Satisfacción
X=A/B
Utilidad
Uso discrecional de funciones
A=Numero de
funciones
específicas del
¿Qué porcentaje
software que se 0<=X<=1
de los usuarios
Observación de usan El más
optan por utilizar Usuario
uso B= Numero de cercano a
las funciones del
funciones que están 1 es mejor
sistema?
destinados a ser
usado
Donde: B>0
Figura N° 63: Procedimiento para la evaluación de calidad en uso del sistema.

118

Grupo 8 Tesis

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Grupo 8 Tesis

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Grupo 8 Tesis

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DEL ALTIPLANO

FACULTAD DE INGENIERÍA MECÁNICA ELÉCTRICA,

DESARROLLO DE UN SISTEMA DE CONTROL Y MONITOREO

Bach. LUZ CLARA TICONA ACERO

PARA OPTAR EL TÍTULO PROFESIONAL DE:

El presente trabajo de investigación, está

A mis amados padres Eloy y Elena, por su

A mis hermanos Marco y Lenin por estar

A la Universidad Nacional del Altiplano, en especial a la escuela profesional de

Ingeniera de Sistemas y plana docente, por la formación que se me otorgo.

de este trabajo de investigación.

realización de esta investigación.

VI. RECOMENDACIONES ........................................................................................ 99

VII. REFERENCIAS .................................................................................................. 100

ANEXOS ...................................................................................................................... 104

Área: Sistemas de información.

Tabla N° 1: Historia de usuario N° 01 - Registro y visualización de datos del conductor. 49

Tabla N° 2: Historia de usuario N° 02 - Registro de información de vehículo. ............... 50

Tabla N° 3: Historia de usuario N° 03 - Visualización de ubicación de vehículos en tiempo

Tabla N° 4: Historia de usuario N° 04 - Visualizar parte diario de vehículos.................. 52

Tabla N° 5: Historia de usuario N° 05 - Programación de ordenes de salida fuera de obra. 53

Tabla N° 6: Historia de usuario N° 06 - Visualizar ordenes de salida. ............................. 54

Tabla N° 7: Historia de usuario N° 07 - Visualización de rutas recorridas de vehículos.55

Tabla N° 8: Historia de usuario N° 08 - Registro de parte diario del vehículo. ............... 56

Tabla N° 9: Historia de usuario N° 09 - Enviar y visualizar notificaciones. .................... 57

Tabla N° 10: Pila de producto................................................................................................ 59

Tabla N° 11: Pila Sprint. ........................................................................................................ 60

Tabla N° 12: Roles Scrum. .................................................................................................... 61

Tabla N° 13: Actores de diagrama de casos de uso. ............................................................ 64

Tabla N° 14: Historias de usuario de sprint 1 ....................................................................... 67

Tabla N° 15: Historias de Usuario de Sprint 1 ..................................................................... 74

Tabla N° 16: Historias de usuario de Sprint 3. ..................................................................... 76

Tabla N° 17: Historias de usuario de Sprint 4 ...................................................................... 79

Tabla N° 18: Requerimientos para la evaluación de la calidad. .......................................... 81

Tabla N° 25: Indicador del nivel de mejora de la eficiencia en el proceso de gestión

Tabla N° 26: Tiempo de acceso a la información en el proceso de gestión unidades

vehiculares sin el sistema…… ........................................................................ 92

Tabla N° 27: Porcentaje de la eficiencia de la productividad sin el sistema. ..................... 93

Tabla N° 28: Tiempo de acceso a la información con ayuda del sistema........................... 94

Tabla N° 30: Nivel de impacto de la eficiencia de la productividad con y sin el sistema. 95

Figura N° 1: Arquitectura Android ............................................................................ 27

Figura N° 2: GPS en Android. ................................................................................... 32

Figura N° 3: Ciclo de Scrum...................................................................................... 34

Figura N° 4: Diagrama Modelo Vista Controlador. .................................................. 36

Figura N° 5: División de la Norma ISO/IEC 25000. ................................................. 37

Figura N° 6: Ciclo de Vida de la evaluación de Calidad de Producto Software. ...... 39

Figura N° 7: Características y subcaracterísticas para evaluar la Calidad Interna y

Figura N° 8: Características y subcaracterísticas para evaluar la calidad en uso. ..... 41

Figura N° 9: Módulos del sistema. ............................................................................ 58

Figura N° 10: Burndown general. ................................................................................ 60

Figura N° 11: Estructura del modelo de implementación............................................ 62

Figura N° 12: Diagrama de casos de uso de sistema. .................................................. 63

Figura N° 13: Diagrama de clases. .............................................................................. 65

Figura N° 14: Diagrama de base de datos.................................................................... 66

Figura N° 15: Sprint Burndown Chart 1 ...................................................................... 68

Figura N° 16: Interfaz de registro de administrador o supervisor. ............................... 68

Figura N° 17: Login del administrador, usuario y supervisor. ..................................... 69