DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DE
VIRTUALIZACIÓN DE SERVIDORES PARA EL SEGUIMIENTO Y MONITOREO DE
LOS SERVICIOS DE ESCOLTA DE LA EMPRESA ESCOLTRAMS LTDA.
CARLOS ANDRES ORTIZ GALINDO
JAIME BRANDON ROBLES FAJARDO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERIA EN TELEMATICA
BOGOTA D.C
2018
DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DE
VIRTUALIZACIÓN DE SERVIDORES PARA EL SEGUIMIENTO Y MONITOREO DE
LOS SERVICIOS DE ESCOLTA DE LA EMPRESA ESCOLTRAMS LTDA.
CARLOS ANDRES ORTIZ GALINDO
JAIME BRANDON ROBLES FAJARDO
TRABAJO DE GRADO PARA OPTAR POR EL TÍTULO DE INGENIERO EN
TELEMÁTICA
DIRECTOR DEL PROYECTO:
MIGUEL ANGEL LEGUIZAMÓN PAÉZ
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA TELEMÁTICA
BOGOTA D.C
2018
3
TABLA DE CONTENIDO
INTRODUCCIÓN 11
1 PLANTEAMIENTO DEL PROBLEMA 12
1.1 DESCRIPCIÓN DEL PROBLEMA 12
1.2 FORMULACIÓN DEL PROBLEMA 13
1.3 ALCANCES Y LIMITACIONES 14
1.2.1 ALCANCES 14
1.2.2 LIMITACIONES 14
1.3 OBJETIVOS 15
1.3.1 OBJETIVO GENERAL 15
1.3.2 OBJETIVOS ESPECÍFICOS 15
1.5 JUSTIFICACIÓN 16
1.6 CONTEXTUALIZACION 17
1.6.1 VISIÓN DEL PROYECTO 17
1.6.1.1 MISIÓN DE LA COMPAÑÍA 17
1.6.1.2 VISIÓN DE LA COMPAÑÍA 17
1.7 MARCO TEÓRICO 18
1.7.1 TRANSPORT APP 18
1.7.2 NOSTRA LOGISTICS 18
1.7.3 COPILOT TRUCK 19
1.7.4 UBER 19
1.7.5 STRAVA 19
1.7.6 SISTEMA DE SEGUIMIENTO A RUTAS REALIZADAS POR TAXISTAS A
TRAVÉS DE ALERTAS TAXI TRACK 19
1.7.7 SISTEMA DE GESTIÓN DE MANTENIMIENTOS APLICADO A FLOTAS
DE VEHÍCULOS DE CARGA PESADA MEDIANTE EL USO DE GPS 20
1.7.8 GPS 20
1.7.9 GOOGLEMAPS 21
1.7.10 NOSQL 21
4
1.7.11 DOCKER 22
1.7.12 METODOLOGÍA SCRUM 22
1.7.12.1 RECOGIDA DE REQUISITOS 22
1.7.12.2 GESTIÓN DE BACKLOG 23
1.7.12.3 SPRINT PLANNING MEETING 23
1.7.12.4 EJECUCIÓN DE SPRINT 24
1.7.12.5 INSPECCIÓN E ITERACIÓN 24
1.8 FACTIBILIDAD 25
1.8.1 FACTIBILIDAD ECONÓMICA 25
1.8.2 FACTIBILIDAD TÉCNICA 27
1.8.3 FACTIBILIDAD OPERACIONAL 28
1.8.4 FACTIBILIDAD LEGAL 29
2 IMPLEMENTACIÓN DE CONTENEDORES CON EL USO DE DOCKER 30
2.1.1 DISEÑO DEL SISTEMA 30
2.1.2 CREACIÓN DE IMÁGENES 30
2.1.2.1 BASE 30
2.1.2.2 BASE_PHP7.1-FPM 31
2.1.2.3 BASE_COMPOSER 31
2.1.2.4 BASE_JDK8 32
2.1.2.5 BASE_NGINX 32
2.1.2.6 APIREST 33
2.1.2.7 KEYCLOAK 33
2.1.3 JERARQUÍA DE IMÁGENES 34
2.1.4 CREACIÓN DE CONTENEDORES 34
2.1.4.1 ESCOLTRAKING KEYCLOAK 34
2.1.4.2 ESCOLTRAKING API PHP 35
2.1.4.3 ESCOLTRAKING NGINX 35
2.1.4.4 ESCOLTRAKING COMPOSER API 35
2.1.5 CLÚSTER DE SERVIDORES 35
2.1.6 DISTRIBUCIÓN DE CONTENEDORES 36
2.1.7 CONJUNTO DE REPLICAS DE BASES DE DATOS 37
5
3 DESARROLLO DEL SISTEMA PARA EL CONSUMO DE SERVICIOS DEL API DE
OSRM Y OPEN STREET MAPS. 39
4 DESARROLLO DEL SISTEMA BACKEND 41
4.1 ANALISIS Y RECOLECCION DE INFORMACION 41
4.1.1 IDENTIFICACIÓN DEL SCRUM MASTER 41
4.1.2 FORMACIÓN DE EQUIPOS 41
4.1.3 LISTA PRIORIZADA DE PENDIENTES DEL PRODUCTO 42
4.1.4 PLANIFICACIÓN DEL LANZAMIENTO (VER ANEXO 2: CRONOGRAMA)
42
4.1.5 HISTORIAS DE USUARIO 42
4.1.6 ENTIDADES IDENTIFICADAS 44
4.1.7 APROBACIÓN, ESTIMACIÓN Y ASIGNACIÓN DE HISTORIAS DE
USUARIO 45
4.1.8 CREACIÓN DE LA LISTA DE PENDIENTES DEL SPRINT 46
4.2 SERVICIOS WEB 47
5 CONSTRUCCIÒN DE LA INTERFAZ CLIENTE 52
6 PRUEBAS 69
6.1 SERVICIOS REST 69
6.1.1 PRUEBAS DE CARGA Y DE ESTRES 69
6.1.1.1 PRUEBAS CON UN NODO 69
6.1.1.1.1 PRUEBA 1 69
6.1.1.1.2 PRUEBA 2 70
6.1.1.1.3 PRUEBA 3 70
6.1.1.2 PRUEBAS CON DOS NODOS 71
6.1.1.2.1 PRUEBA 1 71
6.1.1.2.2 PRUEBA 2 71
6.1.1.2.3 PRUEBA 3 72
6.1.1.3 PRUEBAS CON TRES NODOS 72
6.1.1.3.1 PRUEBA 1 72
6.1.1.3.2 PRUEBA 2 73
6.1.1.3.3 PRUEBA 3 73
6.1.1.4 COMPARACIÓN DE RESULTADOS 74
6
7 CONCLUSIONES 75
8 BIBLIOGRAFÍA 76
7
LISTA DE TABLAS
Tabla 1: Costos personal .............................................................................................. 25
Tabla 2: Costos Infraestructura ..................................................................................... 26
Tabla 3: Otros costos .................................................................................................... 26
Tabla 4. Resumen costos .............................................................................................. 27
Tabla 5: Especificaciones técnicas mínimas del servidor .............................................. 27
Tabla 6: Especificaciones técnicas mínimas del dispositivo móvil ................................ 28
Tabla 7: Imagen base .................................................................................................... 30
Tabla 8:Imagen PHP 7 .................................................................................................. 31
Tabla 9: Imagen composer ............................................................................................ 32
Tabla 10:Imagen JDK8 .................................................................................................. 32
Tabla 11: Imagen Nginx ................................................................................................ 32
Tabla 12: Imagen API REST ......................................................................................... 33
Tabla 13: Imagen Keycloak ........................................................................................... 33
Tabla 14: Historia 1 ....................................................................................................... 42
Tabla 15: Historia 2 ....................................................................................................... 43
Tabla 16: Historia 3 ....................................................................................................... 43
Tabla 17: Historia 4 ....................................................................................................... 43
Tabla 18: Historia 5 ....................................................................................................... 44
Tabla 19: Requerimientos ............................................................................................. 45
Tabla 20: Lista de pendientes ....................................................................................... 46
Tabla 21: Resumen de la prueba 1 a un nodo .............................................................. 69
Tabla 22: Resumen de la prueba 2 a un nodo .............................................................. 70
Tabla 23: Resumen de la prueba 3 a un nodo .............................................................. 70
Tabla 24: Resumen de la prueba 1 a dos nodos ........................................................... 71
Tabla 25: Resumen de la prueba 2 a dos nodos ........................................................... 71
Tabla 26: Resumen de la prueba 3 a dos nodos ........................................................... 72
Tabla 27: Resumen de la prueba 1 a tres nodos .......................................................... 72
Tabla 28: Resumen de la prueba 2 a tres nodos .......................................................... 73
Tabla 29: Resumen de la prueba 3 a tres nodos .......................................................... 73
Tabla 30: Consultar usuarios ........................................................................................ 81
Tabla 31: Crear usuarios ............................................................................................... 82
Tabla 32: Editar usuario ................................................................................................ 83
Tabla 33: Eliminar usuario ............................................................................................. 84
Tabla 34: Crear empresa. ............................................................................................. 85
Tabla 35: Consultar empresa ........................................................................................ 86
Tabla 36:Editar empresa ............................................................................................... 87
Tabla 37: Eliminar empresa .......................................................................................... 88
Tabla 38:Crear viaje ...................................................................................................... 89
8
Tabla 39: Consultar viaje ............................................................................................... 90
Tabla 40: Editar viaje ..................................................................................................... 91
Tabla 41: Aceptar viaje .................................................................................................. 92
Tabla 42: Cerrar viaje .................................................................................................... 93
Tabla 43: Cerrar viaje .................................................................................................... 94
Tabla 44: Registrar punto de control ............................................................................. 95
Tabla 45: Consultar punto de control ............................................................................ 96
Tabla 46: Editar punto de control .................................................................................. 97
Tabla 47: Eliminar punto de control ............................................................................... 98
Tabla 48: Registrar reporte punto de control ................................................................. 99
Tabla 49: Consultar reportes puntos de control .......................................................... 100
9
LISTA DE ILUSTRACIONES
Ilustración 1: Jerarquía de Imágenes ............................................................................ 34
Ilustración 2: Clúster de servidores ............................................................................... 36
Ilustración 3: Distribución de contenedores en tres servidores ..................................... 37
Ilustración 4: Conjunto de réplicas de base de datos .................................................... 38
Ilustración 5: Url servicio route driving de OSRM .......................................................... 39
Ilustración 6: Mapa ejemplo servicio router driving OSRM ............................................ 40
Ilustración 7: Servicios de País ..................................................................................... 47
Ilustración 8: Servicios de Departamento ...................................................................... 47
Ilustración 9: Servicios de Municipio ............................................................................. 47
Ilustración 10: Servicios de Empresa ............................................................................ 48
Ilustración 11: Servicios de Punto de control ................................................................ 48
Ilustración 12: Servicios de Vehículo............................................................................. 49
Ilustración 13: Servicios de Tipo de servicio ................................................................. 49
Ilustración 14: Servicios de Viaje .................................................................................. 50
Ilustración 15: Servicios de Persona ............................................................................. 50
Ilustración 16: Servicios de Cargos ............................................................................... 51
Ilustración 17: Área de autenticación ............................................................................ 52
Ilustración 18: Pantalla inicial ........................................................................................ 53
Ilustración 19: Menú principal ........................................................................................ 54
Ilustración 20: Autorización de ubicación ...................................................................... 55
Ilustración 21: Selección de coordenada GPS .............................................................. 57
Ilustración 22: Especificación técnica de nodos de prueba ........................................... 69
Ilustración 23: prueba 1 con un nodo ............................................................................ 69
Ilustración 24: prueba 2 con un nodo ............................................................................ 70
Ilustración 25: prueba 3 con un nodo ............................................................................ 70
Ilustración 26: prueba 1 con dos nodos......................................................................... 71
Ilustración 27: prueba 2 con dos nodos......................................................................... 71
Ilustración 28: prueba 3 con dos nodos......................................................................... 72
Ilustración 29: prueba 1 con tres nodos ........................................................................ 72
Ilustración 30: prueba 2 con tres nodos ........................................................................ 73
Ilustración 31: prueba 3 con tres nodos ........................................................................ 73
Ilustración 32: Comparación de cantidad de nodos Vs tiempo promedio de respuesta 74
Ilustración 33: Diseño de arquitectura de virtualización ................................................ 79
Ilustración 34: Cronograma ........................................................................................... 80
10
LISTA DE ANEXOS
ANEXO 1: DISEÑO DE ARQUITECTURA DE VIRTUALIZACIÓN. .............................. 79
ANEXO 2: CRONOGRAMA. ......................................................................................... 80
ANEXO 3: ESPECIFICACIÓN DE CASOS DE USO .................................................... 81
11
INTRODUCCIÓN
El siguiente proyecto se realiza con el fin de optar por el título de Ingeniería en
Telemática de la Universidad Distrital Francisco José de Caldas en la modalidad de
Pasantía con el título “Desarrollo de un sistema basado en arquitectura de virtualización
de servidores para el seguimiento y monitoreo de los servicios de escolta de la
empresa Escoltrams Ltda.
El siguiente documento ilustra de manera ordenada y secuencial los procesos y
actividades llevadas a cabo durante el desarrollo del proyecto, donde, además de
mostrar mediante la implementación del proyecto como una solución tecnológica puede
ayudar a monitorear y gestionar un proceso de suma importancia para la empresa.
Por otro lado, el documento hará una presentación de cada uno de los componentes
técnicos y tecnológicos utilizados, resaltando la arquitectura de virtualización de los
servidores con Docker, el componente backend desarrollado en PHP con Symfony 3 y
el componente móvil con IONIC 2.
Este documento evidenciara el proceso de desarrollo de la aplicación y realizará el
recogimiento de los conceptos de mayor relevancia para la puesta en marcha del
producto final, pasando por los objetivos, justificación, alcances y limitaciones, marco
referencial, estudio de factibilidad hasta llegar al cronograma de actividades, que
estructuran y direccionan el avance del proyecto, asimismo, aplicando todos los
conocimientos adquiridos durante la formación académica de los desarrolladores.
12
1 PLANTEAMIENTO DEL PROBLEMA
1.1 DESCRIPCIÓN DEL PROBLEMA
ESCOLTRAMS es una empresa dedicada a prestar servicios de seguridad y
acompañamiento. Unos de los servicios más importantes que ofrece la empresa es el
de escolta acompañante. Este servicio consiste en enviar un escolta, ya sea en
motocicleta o automóvil, para que acompañe a una carga o tráiler que es transportado
en un tracto camión hacia diferentes partes del país.
Desde el momento en que una empresa adquiere los servicios de acompañamiento de
ESCOLTRAMS, se configura un completo escenario logístico donde participan
esencialmente tres partes. Una empresa que necesita que sus mercancías (tráiler) sea
escoltada de un lugar específico hasta otro, la empresa que adquiere el servicio que es
el CLIENTE. El área de logística que es la encargada de recibir la solicitud del cliente,
analizar cuáles son las necesidades de su servicio y asignar el personal necesario para
realizar la labor. Por último, el ESCOLTA, quien es una persona calificada que se
encarga de acompañar al tracto camión durante todo su recorrido ya sea en
motocicleta o automóvil según sea necesario.
El CLIENTE adquiere los servicios de la empresa debido a que, según la normativa del
ministerio de transporte de Colombia, las cargas pesadas y extra pesadas deben
cumplir con ciertos requisitos para poder movilizarse en las carreteras del país, entre
uno de estos requisitos se encuentra el vehículo acompañante (escolta).
Para llevar el control de viaje, ESCOLTRAMS hace uso de planillas en papel en las
cuales se consigna la información con los datos más relevantes dentro del recorrido en
ciertos puntos de camino, principalmente en los peajes. Sin embargo, estos puntos de
control solo evidencian que la carga evidentemente pasa por ese lugar y da el visto
bueno con una firma de alguno de los funcionarios.
La recolección de la información y los registros de control son llevados de manera
manual por los conductores o por los escoltas que son responsables de cada viaje. La
información que es recolectada tiene que ver con los datos del tráiler, la empresa que
contrata el servicio, el número de placa tanto del tráiler como del tracto camión,
información del conductor y de su escolta, observaciones de viaje, fecha y hora en la
que pasa por cada punto de control. Esta plantilla debe viajar junto al responsable
desde el inicio del viaje hasta que sea entregada de nuevo a la oficina central de
ESCOLTRAMS donde se realiza la respectiva verificación de los datos y se almacena
13
en una bitácora viaje que luego podrá ser consultada por los funcionarios de logística
de la empresa.
Con la recopilación de información durante los viajes, se puede crear una bitácora con
los principales acontecimientos durante el recorrido, en caso de algún siniestro este
historial servirá para tomar las decisiones respectivas o hacer un completo seguimiento
y encontrar las causas de los problemas presentados. Sin embargo, el acceso a esta
información no se puede realizar de manera inmediata, debido a que los datos sólo
pueden ser auditados cuando el servicio retorna a su punto de inicio.
Algunas de las situaciones encontradas fueron:
La información de las planillas solo puede ser verificada cuando el viaje ha finalizado y
el documento regresa a la oficina central.
Las planillas están expuestas a deteriorarse fácilmente porque no se lleva una correcta
manipulación de las mismas.
No se puede validar que el acompañamiento se haya realizado de manera constante.
1.2 FORMULACIÓN DEL PROBLEMA
¿Cómo mejorar el proceso de monitoreo y seguimiento del servicio de escolta,
buscando optimizar los procesos de trazabilidad para Escoltrams LTDA?
14
1.3 ALCANCES Y LIMITACIONES
1.2.1 ALCANCES
Implementar un sistema de monitoreo GPS de escoltas mediante una aplicación móvil
con la capacidad de generar reportes detallados con la trazabilidad de cada uno de los
recorridos, toma de evidencias fotográficas según configuración, obtención de
ubicación geográfica utilizando los sensores de los teléfonos inteligentes.
1.2.2 LIMITACIONES
El acceso y transferencia de información de la aplicación se realizará por medio de
datos móviles propios de los dispositivos y ofrecidos por diferentes operadores de
servicio, por lo tanto, la disponibilidad del envío y recepción de información estará dado
por la cobertura y disponibilidad de los datos.
La recolección de la información en carretera será obtenida por los dispositivos de las
personas responsables del servicio de escolta.
Informe de seguimiento de rutas contará con evidencias fotográficas, descripciones y
un trazado del recorrido. Los reportes de ubicación serán realizados con cierto intervalo
de tiempo el acceso a la aplicación se podrá realizar sólo si se está conectado a
internet.
15
1.3 OBJETIVOS
1.3.1 OBJETIVO GENERAL
Desarrollar e Implementar un sistema telemático para el seguimiento y monitoreo de los
servicios de escolta de ESCOLTRAMS LTDA.
1.3.2 OBJETIVOS ESPECÍFICOS
● Implementar contenedores de los diferentes servidores para facilitar la gestión y
escalabilidad tanto de la infraestructura y el sistema.
● Desarrollar un sistema que haga uso de los servicios del API de OSRM y Open
Street Maps, capaz de monitorear en tiempo real elementos en movimiento, para
servir de acompañamiento en las operaciones del negocio.
● Desarrollar un sistema backend donde se ofrezca los servicios web del negocio
para que otros sistemas tanto internos como externos de la empresa pueda
hacer uso de ellos.
● Construir una interfaz cliente capaz de consumir los servicios expuestos por el
API para que los usuarios puedan hacer uso de esos servicios de forma
amigable.
● Ejecutar pruebas lógicas y de negocio con la finalidad de validar que los
procesos cumplan con los objetivos del negocio.
16
1.5 JUSTIFICACIÓN
ESCOLTRAMS LTDA, es una empresa del sector seguridad la cual tiene como foco de
negocio los servicios de acompañamiento y escolta a tracto camiones que llevan
consigo contenedores desde y hacia diferentes partes del país. Su función primordial
es dar un acompañamiento continuo durante todo el recorrido y de esta manera
asegurar que los contenedores lleguen al lugar de destino sin ningún inconveniente y
en caso de que exista, contar con el personal adecuado para sortear estas situaciones.
Sin embargo, la empresa debe llevar un control de los diferentes eventos que surgen
en la ruta y realizar un registro donde se describa los participantes del mismo, ya sea el
conductor, el serial del container, el número de placa del tracto camión, el lugar donde
se realiza el control entre otros. Este proceso se realiza por medio de planillas físicas y
diligenciadas a mano que implican una cantidad considerable de errores propios de las
omisiones humanas. Por lo tanto, en los últimos meses, ESCOLTRAMS ha identificado
que este proceso no se está llevando a cabo, pues muchos de los escoltas ni siquiera
están realizando este acompañamiento, luego, no hay forma de verificar que se realizó
el acompañamiento debido a las limitantes que tiene el sistema de planillas utilizado
por la empresa.
Dado lo anterior, la empresa decide desarrollar un sistema en el que se asegure el
registro de cada uno de estos eventos no solo con la información anteriormente
descrita, sino que además se tomen registro de la ubicación geográfica y evidencias
fotográficas de cada uno de estos eventos durante el recorrido.
El sistema aprovechará las facilidades de acceso a los dispositivos inteligentes, de esta
manera se aprovecha el auge de los mismos y la gran cobertura en cuanto a tecnología
y sensores que ayudarán a cumplir con los objetivos de la aplicación.
La principal motivación para realizar este desarrollo se sustenta en el mejoramiento del
proceso de trazabilidad de los viajes que son contratados por ESCOLTRAMS, cabe
resaltar que con la puesta en marcha del proyecto se le dará un valor agregado al
servicio de escolta pues creará confianza a los clientes que sus contenedores y
mercancías van a estar seguras desde su origen hasta su destino.
17
1.6 CONTEXTUALIZACION
1.6.1 VISIÓN DEL PROYECTO
Escoltrams es una empresa dedicada a la prestación de servicios de vigilancia y seguridad, que quiere implementar un sistema de para la trazabilidad y monitoreo de su servicio de escolta motorizado, con cobertura a nivel nacional. Por esta razón requiere implementar y desarrollar una aplicación que gestione el proceso de escolta y genere informes sobre cada uno de los servicios que se presten.
1.6.1.1 MISIÓN DE LA COMPAÑÍA
Somos una empresa que dirige sus esfuerzos a satisfacer las necesidades de los clientes en servicios de vigilancia y seguridad privada, creando estrategias de calidad, brindando desarrollo permanente al recurso humano y a la comunidad, generando rentabilidad para sus socios, basados siempre en el respeto a las normas éticas y valores.
1.6.1.2 VISIÓN DE LA COMPAÑÍA
Para el año 2020, Escoltrams Seguridad Ltda. será la empresa líder en prestación del servicio de vigilancia y seguridad privada con cubrimiento nacional, apoyado en tecnología y un sistema de gestión integral orientado hacia el servicio al cliente y al desarrollo permanente del recurso humano, acorde a los objetivos corporativos.
18
1.7 MARCO TEÓRICO
El tema de seguimiento (tracking) ha dado múltiples utilidades a gran variedad de
sectores de la industria, principalmente al logístico, en esta área se pueden encontrar
gran número de aplicaciones que son capaces de monitorear elementos que se
mueven alrededor del mundo, Google maps es uno de los mayores exponentes de este
tipo de tecnología. Google presenta una variedad de servicios encapsulados en su API
llamada Google Maps. Esta herramienta es utilizada por una infinidad de aplicaciones
donde sea necesario la utilización de mapas y georreferenciación.
Sin embargo, existen aplicaciones dedicadas exclusivamente a tracking entre ellas se
encuentran:
1.7.1 TRANSPORT APP
Aplicación para el seguimiento de coordenadas, control y entrega de órdenes,
desarrollo de módulos para el seguimiento a través de los gps y donde estas
coordenadas se capturan en nuestro sistema backend hecho en PHP. Este sistema
también está disponible el código del backend se da después de haber adquirido la
aplicación de iones
Se puede desactivar o en la captura de coordenadas se realiza a través del fondo de
forma continua y se envía a una base de datos en mysql, a continuación, mostrar el
seguimiento en google maps.
Esta aplicación tiene un complemento que le permite integrarse con aplicaciones como
google maps, waze para encontrar la mejor ruta entre dos puntos.1
1.7.2 NOSTRA LOGISTICS
Su principal atractivo es la posibilidad de llevar a cabo trazabilidad en tiempo real de
unidades GPS. Esta aplicación, desarrollada por Globe- Tech Co., Ltd, permite
suministrar información al usuario, como última posición, fecha y hora de registro de la
misma, descripción de la localización, velocidad y dirección del vehículo, entre otras.
También es posible calcular la distancia entre dos puntos (la del paquete y el vehículo,
y su origen o destino) y la relación entre la última ubicación del objeto rastreado y el
dispositivo desde el cual se lleva a cabo el proceso.2
1 Transportapp ionic App, Transportapp ionic App Logic and Transport Backend, disponible en: https://market.ionicframework.com/starters/transportapp, consultado el 27 de agosto de 2018.
19
1.7.3 COPILOT TRUCK
Calcula rutas eficientes basadas en la información del perfil del vehículo, parámetros de
enrutamiento y tipo de carga, con ajustes adicionales para el transporte de materiales
peligrosos. Manejo del enrutamiento PC * MILER estándar de la industria garantiza que
cumpla y evite multas o daños en el vehículo. Mapas off-line de alta calidad con
actualizaciones de mapas regulares. No necesita Internet móvil.3
1.7.4 UBER
Aunque es una app enfocada al servicio de transporte de personas, sirve de base de
cómo gestionar el proceso de asignación de conductores a clientes, además de contar
con un sistema de fácil acceso y una interfaz gráfica muy amigable con el usuario.
1.7.5 STRAVA
Pese a que es una aplicación deportiva y va orientada al atletismo, ciclismo y natación,
cuenta con características interesantes que pueden servir como referencia, estas
características son el seguimiento de rutas realizadas por los usuarios, la realización de
reportes durante el recorrido, resumen del recorrido e historial de todos los recorridos
del usuario.4
También existen proyectos académicos orientados al tracking:
1.7.6 SISTEMA DE SEGUIMIENTO A RUTAS REALIZADAS POR TAXISTAS A TRAVÉS DE ALERTAS TAXI TRACK
Es un prototipo de aplicación para dispositivos móviles que permite realizar verificación
de taxis y realizar seguimiento a la ruta de un servicio tomado, Taxi Track es una
aplicación unificada que proporciona información sobre el estado o reporte existente
sobre un vehículo de servicio público brindándole al usuario una herramienta que
2 Nostra Logistics , Nostra Logistics Map , disponible en: http://logistics.nostramap.com , consultado el 27 de agosto de 2018. 3 Copilot truck , Truck Navigation For Every Journey, disponible en: https://copilottruck.com/en-gb/ , consultado el 27 de agosto de 2018. 4 Strava, Funciones de strava, disponible en: https://www.strava.com/features, consultado el 27 de agosto de 2018.
20
permite conocer de antemano el historial y tener la opción de ser monitoreado o
seguido por una persona previamente autorizada.5
1.7.7 SISTEMA DE GESTIÓN DE MANTENIMIENTOS APLICADO A FLOTAS DE VEHÍCULOS DE CARGA PESADA MEDIANTE EL USO DE GPS
Esta aplicación gestiona el proceso mantenimiento de vehículos de carga pesada
durante el recorrido en carretera, evidencia la utilización de un sistema de
georreferenciación y como estos ayudan a mejorar el proceso de mantenimiento de
este tipo de vehículos, además de la generación avanzada y configurables sobre la
trazabilidad.6
1.7.8 GPS
El Sistema de Posicionamiento Global, más conocido por sus siglas en inglés, GPS
(siglas de Global Positioning System), es un sistema que permite determinar en toda la
Tierra la posición de un objeto (una persona, un vehículo) con una precisión de hasta
centímetros (si se utiliza GPS diferencial), aunque lo habitual son unos pocos metros
de precisión.
El GPS funciona mediante una red de 24 satélites en órbita sobre el planeta Tierra, a
20.200 km de altura, con trayectorias sincronizadas para cubrir toda la superficie de la
Tierra. Cuando se desea determinar la posición, el receptor que se utiliza para ello
localiza automáticamente como mínimo tres satélites de la red, de los que recibe unas
señales indicando la identificación y la hora del reloj de cada uno de ellos. Con base en
estas señales, el aparato sincroniza el reloj del GPS y calcula el tiempo que tardan en
llegar las señales al equipo, y de tal modo mide la distancia al satélite mediante el
método de trilateración inversa, el cual se basa en determinar la distancia de cada
satélite al punto de medición.7
5 Moreno Castro, L. and Fajardo Rodríguez, D. (2015). Sistema de seguimiento a rutas
realizadas por taxistas a través de alertas taxi track. Bogotà.
6 Aranda Pinilla, C. and Rojas Ruiz, E. (2015). Sistema de gestión de mantenimientos aplicado a flotas de vehículos de carga pesada mediante el uso de GPS /. Bogotá: Universidad Distrital Francisco José de Caldas. 7 Es.wikipedia.org. (2017). Sistema de posicionamiento global. [online] Disponible en: https://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global, Consultado el 12 oct. 2017.
21
1.7.9 GOOGLEMAPS
Google Maps es un servidor de aplicaciones de mapas en la web que pertenece a
Alphabet Inc. Este servicio propicia imágenes de mapas desplazables, así como
fotografías por satélite del mundo, e incluso, la ruta entre diferentes ubicaciones o
imágenes a pie de calle con Google Street View.
Google Maps fue anunciado por primera vez en Google Blog el 8 de febrero de 2005.
Originalmente soportaría solo a los usuarios de Internet Explorer y Mozilla Firefox, pero
el soporte para Opera y Safari fue agregado el 25 de febrero de 2005. El software
estuvo en su fase beta durante seis meses, antes de convertirse en parte de Google
Local, el 6 de octubre de 2005.
Como en las aplicaciones web de Google, se usan un gran número de archivos
JavaScript para crear Google Maps. Como el usuario puede mover el mapa, la
visualización del mismo se baja desde el servidor. Cuando un usuario busca un
negocio, la ubicación es marcada por un indicador en forma de pin, el cual es una
imagen PNG transparente sobre el mapa. Para lograr la conectividad sin sincronía con
el servidor, Google aplicó el uso de AJAX dentro de esta aplicación. Es una aplicación
para el desarrollo de mapas.8
1.7.10 NOSQL
Es una amplia clase de sistemas de gestión de bases de datos que difieren del modelo
clásico de SGBDR (Sistema de Gestión de Bases de Datos Relacionales) en aspectos
importantes, siendo el más destacado que no usan SQL como lenguaje principal de
consultas. Los datos almacenados no requieren estructuras fijas como tablas,
normalmente no soportan operaciones JOIN, ni garantizan completamente ACID
(atomicidad, consistencia, aislamiento y durabilidad), y habitualmente escalan bien
horizontalmente. Los sistemas NoSQL se denominan a veces "no sólo SQL" para
subrayar el hecho de que también pueden soportar lenguajes de consulta de tipo SQL.
8 Google Maps, Google maps platform, disponible en: https://cloud.google.com/maps-platform/, consultado el 27 de agosto de 2018.
22
1.7.11 DOCKER
Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones
dentro de contenedores de software, proporcionando una capa adicional de abstracción
y automatización de Virtualización a nivel de sistema operativo en Linux. Docker utiliza
características de aislamiento de recursos del kernel de Linux, tales como cgroups y
espacios de nombres (namespaces) para permitir que "contenedores" independientes
se ejecuten dentro de una sola instancia de Linux, evitando la sobrecarga de iniciar y
mantener máquinas virtuales.
El soporte del kernel de Linux para los espacios de nombres aísla la vista que tiene una
aplicación de su entorno operativo, incluyendo árboles de proceso, red, ID de usuario y
sistemas de archivos montados, mientras que los cgroups del kernel proporcionan
aislamiento de recursos, incluyendo la CPU, la memoria, el bloque de E / S y de la red.
Desde la versión 0.9, Docker incluye la biblioteca libcontainer como su propia manera
de utilizar directamente las facilidades de virtualización que ofrece el kernel de Linux,
además de utilizar las interfaces abstraídas de virtualización mediante libvirt y LXC
(Linux Containers).
De acuerdo con la firma analista de la industria 451 Research, "Docker es una
herramienta que puede empaquetar una aplicación y sus dependencias en un
contenedor virtual que se puede ejecutar en cualquier servidor Linux. Esto ayuda a
permitir la flexibilidad y portabilidad en donde la aplicación se puede ejecutar, ya sea en
las instalaciones físicas, la nube pública, nube privada, etc.9
1.7.12 METODOLOGÍA SCRUM
1.7.12.1 RECOGIDA DE REQUISITOS
El proceso comienza con la generación de la lista de objetivos o requisitos priorizada,
que actúa como plan del proyecto y que es entregada por el cliente o dueño del
producto al equipo. La lista de objetivos/requisitos priorizada representa la visión y
expectativas del cliente respecto a los objetivos y entregas del producto o proyecto.
9 Docker. (2017). What is Docker. [online] Disponible en: https://www.docker.com/what-docker, Consultado el 9 oct. 2017.
23
Es importante comprender que el cliente es el responsable de crear y gestionar la lista
con ayuda del líder del proceso, el Scrum master, que es el director del proyecto y
encargado de eliminar los obstáculos que impiden que el equipo de desarrollo alcance
el objetivo del sprint.10
Esta etapa sería la “planificación” del proyecto, en un marco no ágil de trabajo.
1.7.12.2 GESTIÓN DE BACKLOG
Es el conjunto de funcionalidades y tareas a realizar. Para cada objetivo/requisito se
indica el valor que aporta al cliente y el costo estimado de completarlo, velando por un
equilibrio entre ambos en pos del ROI.
1.7.12.3 SPRINT PLANNING MEETING
Un sprint es una unidad de trabajo que agrupa un conjunto de tareas en un periodo de
tiempo. La primera iteración es de planificación y está compuesta por dos partes:
Selección de requisitos: Es la iteración entre cliente y equipo, el momento en que el
equipo pregunta al cliente las dudas que surgen y se seleccionan los requisitos más
prioritarios que se comprometen a completar en la iteración. Tiene una duración
máxima de cuatro horas.
Planificación de la iteración: Se elabora la lista de tareas o acciones necesarias para
desarrollar los requisitos a los que se han comprometido. La estimación de esfuerzo se
hace de manera conjunta, siempre con el scrum master como facilitador, y los
miembros del equipo se auto asignan las tareas. La duración de este ejercicio no debe
superar las cuatro horas.11
10 Satpathy, T. (2017). Scrum body of knowledge (sbok guide). [online] scrumstudy. Disponible en: https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf, Consultado el 9 oct. 2017. 11 Ibit
24
1.7.12.4 EJECUCIÓN DE SPRINT
En la metodología Scrum un proyecto se ejecuta en bloques temporales cortos y fijos,
llamados sprint, que son iteraciones de 2 semanas. Si se sobrepasa este tiempo, como
máximo un sprint puede tomar 4 semanas.
Daily Scrum Meeting: Todos los días, una vez comenzado el sprint, el equipo realiza
una reunión de coordinación. En estas sesiones diarias, cada miembro del equipo
revisa el trabajo que el resto está realizando.
En la reunión cada integrante debe responder a tres preguntas:
¿Qué he hecho desde la última reunión de sincronización?
¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener?
Estas reuniones son fundamentales en el proceso, ya que son instancias para avanzar
desde los procesos individuales que desarrolla cada miembro del equipo a la
colaboración de todos en el desarrollo.12
1.7.12.5 INSPECCIÓN E ITERACIÓN
El último día de la iteración se realiza la reunión de revisión de la iteración, y se
compone de dos partes:
Sprint Review: El equipo desarrollador presenta al cliente los requisitos completados en
la iteración, en forma de incremento de producto preparado para ser entregado. El
cliente revisa el entregable y se adaptan las mejoras necesarias.
Sprint Retrospective: En esta fase el equipo analiza cómo ha sido su manera de
trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente,
enfocando el proceso a la mejora continua del equipo.
Toda la instancia de reunión se debe cronometrar y respetar en el marco de tiempos
establecidos. Esta variable es fundamental para mantener los esfuerzos enfocados en
el desarrollo del producto.13
12 Ibit 13 Ibit
25
1.8 FACTIBILIDAD
1.8.1 FACTIBILIDAD ECONÓMICA
Para la realización del proyecto se realizó un informe detallado de cada uno de los
insumos necesarios para su desarrollo. Los costos del proyecto se dividen en tres
partes importantes: el recurso humano que lo conforman los ejecutantes de proyectos,
el director de proyecto y el personal encargado de realizar las pruebas. Los salarios de
estas personas serán asumidos por la universidad dado que la modalidad del proyecto
es pasantía.
Por otro lado, se encuentran los costos relacionados con los temas de infraestructura,
que tienen que ver con el lugar en donde se va a almacenar el sistema para que pueda
ser accedido desde cualquier navegador. Se decidió optar por los servicios de Amazon
EC2 que en principio ofrece un paquete gratuito por un año, con algunas limitaciones
de máquina, que luego serán cobrados dependiendo de uso al servidor, estos costos
serán asumidos por la empresa Escoltrams.
Por último, se realizó un análisis sobre los posibles costos de improvistos, demás
costos que estarían fuera del core de negocio, por ejemplo: servicios públicos,
papelería, transporte, etc. Los anteriormente mencionados serán asumidos por los
ejecutores del proyecto.
A continuación, se presenta el análisis de costos del proyecto:
Tabla 1: Costos personal
ITEM DURACIÓN COSTO
UNITARIO(MES)
TOTAL
Salarios desarrolladores 6 meses $4.000.000 $48.000.000
Salario director del proyecto 4 meses (48H) $2.400.000 $16.000.000
Personal de pruebas 0.5 meses $1.000.000 $500.000
Imprevistos (10 %) $6.450.000
GRAN TOTAL $70.950.000
Fuente: autores.
26
Tabla 2: Costos Infraestructura
ITEM DURACIÓN COSTO
UNITARIO(MES)
TOTAL
Servicio Amazon Elastic
Compute Cloud (Amazon EC2)
(Primer año free. Luego el costo
depende del consumo de la
aplicación)
12 meses $25.920 $311.040
Imprevistos (10 %) $31.104
GRAN TOTAL $342.144
Fuente: autores.
Tabla 3: Otros costos
ITEM DURACIÓN COSTO UNITARIO TOTAL
Recursos de máquina 6 meses $400.000 $2.400.000
Servicios públicos 6 meses $150.000 $900.000
Transporte 6 meses $56.000 $336.000
Imprevistos (10 %) $363.600
GRAN TOTAL $3.999.600
Fuente: autores.
27
RESUMEN COSTOS
Tabla 4. Resumen costos
ITEM TOTAL
Costos personales $70.950.000
Costos infraestructura $342.144
Otros costos $3.999.600
TOTAL $75.291.744
Fuente: autores.
Con lo anterior se puede determinar que el proyecto en cuanto al tema económico
puede ser desarrollado a cabalidad, pues se evidencia que cada una de las partes
estaría dispuesta a aportar los recursos necesarios en cada uno de los aspectos
destallados.
1.8.2 FACTIBILIDAD TÉCNICA
Para la implantación del sistema se debe contar con las siguientes especificaciones
mínimas en cuanto a software y hardware.
Tabla 5: Especificaciones técnicas mínimas del servidor
Sistema operativo Linux Ubuntu 16.04
Memoria RAM 8 Gb
Procesador físico Intel Xeon
Otros Docker v.3
NGINX v.1.15
PHP 7
MongoDB v.3.4
Keycloak v.3.4.1
Fuente: autores.
28
Para la aplicación móvil, las características mínimas para que el dispositivo sea capaz
de funcionar correctamente son la siguientes:
Tabla 6: Especificaciones técnicas mínimas del dispositivo móvil
Sistema operativo Android > 5 o IOS
Memoria RAM > 2 Gb
GPS Si
Disco duro >16 Gb
Acceso a internet Si
Fuente: autores.
Según la tabla anterior, las especificaciones de los equipos necesarios, que pueden ser
adquiridos en cualquier prestador de servicios, ya sea Amazon, Google Cloud y demás.
Para el caso del presente proyecto la empresa Escoltrams asumirá los costos
generados por el concepto de alquiler de los servicios prestados por Amazon y todas
las características del servidor donde se hospedará el sistema.
Por lo tanto, en cuanto a factores técnicos el sistema es factible completamente.
1.8.3 FACTIBILIDAD OPERACIONAL
La empresa creara un área especializada para el manejo y soporte del sistema, en
principio los ejecutores serán los encargados de brindar el apoyo hasta que la empresa
sea capaz de mantener el sistema por su cuenta. De esta manera se asegura que el
sistema contara con los recursos humanos necesarios para mantener el sistema.
En cuanto a la operación y puesta en marcha del proyecto se creó un cronograma
donde se especifican las actividades y tareas, asignadas a cada uno de los ejecutores
con esto se asegura que de seguir y cumplir con lo estipulado el proyecto se terminara
correctamente.
Es de resaltar que con el desarrollo y diseño intuitivo de la aplicación no será necesario
tener conocimientos especializados en los procesos, por lo tanto, casi que cualquier
persona que tenga acceso al sistema podrá utilizarlo sin ningún problema. De igual
forma se realizarán capacitaciones donde se explique claramente el funcionamiento y
el correcto funcionamiento del software.
29
De esta manera se puede concluir que el sistema se puede desarrollar desde el punto
de vista operacional y es factible en su totalidad.
1.8.4 FACTIBILIDAD LEGAL
La solución platea hacer uso de una serie de tecnologías no privativas. Las tecnologías
utilizadas en el proyecto tienen licenciamiento para el uso libre, por lo tanto, no se
incurrirá en ninguna falta para estos efectos.
Por otro lado, para el manejo de la información de los usuarios, según la normatividad
para el almacenamiento y tratamiento de información de los usuarios se hace necesario
crear una metodología para que cada una de las personas que va a brindar información
personal en la aplicación tenga la posibilidad de editar o eliminar dicha información,
según lo reglamentado en la ley Habeas Data 1266 de 2008.14
Respecto a la obtención de la posición geográfica de las personas, con el uso de los
dispositivos, se pedirá en primera instancia el permiso para poder acceder a dicha
información de esta manera se asegura que todo el procedimiento se hace bajo la
autorización de las mismas.
Se concluye el proyecto es factible legalmente pues no presenta ningún impedimento
para su puesta en marcha.
14 Superintendencia de Industria y comercio, Manejo de la información Personal, Habeas Data, Disponible en: http://www.sic.gov.co/manejo-de-informacion-personal, Consultado el 9 oct. 2017.
30
2 IMPLEMENTACIÓN DE CONTENEDORES CON EL USO DE DOCKER
La implementación de un ambiente para el despliegue de una aplicación tanto en
desarrollo, pruebas o producción, conlleva a una serie de pasos repetitivos como la
instalación de herramientas, configuración del sistema y entre otras cosas, que
consumen tiempo y agrega complejidad innecesaria a la aplicación.
Por lo anterior, se opta por la implementación de un sistema Docker para optimizar el
proceso de despliegue en los diferentes entornos.
2.1.1 DISEÑO DEL SISTEMA
Se diseña un sistema con Docker que sea capaz de interpretar las peticiones HTTP y
procesarlas a partir de su dominio y puerto como se muestra en el ANEXO 1 (Diseño
de arquitectura de virtualización.). Este sistema cuenta con redundancia en los
servicios de PHP (APIREST) y JAVA (Keycloak) con el objetivo de distribuir la carga de
trabajo y evitar el bloqueo en las aplicaciones cuando en ellas se presenten algún error.
2.1.2 CREACIÓN DE IMÁGENES
2.1.2.1 BASE
Se establece herramientas, configuraciones básicas, usuarios y el directorio de trabajo
para la mayoría de las imágenes a utilizar en el sistema.
Tabla 7: Imagen base
Imagen base Ubuntu 16.04
Directorio de trabajo /opt/escoltrams
Herramientas
curl nano
Nmap unzip
Zip
Fuente: autores.
31
2.1.2.2 BASE_PHP7.1-FPM
Se establece herramientas, configuraciones básicas, usuarios, directorio de trabajo y
librerías para PHP para las imágenes que hereden de la misma.
Tabla 8:Imagen PHP 7
Imagen base php:7.1-fpm
Directorio de trabajo /opt/escoltrams
Herramientas
Acl apt-file
Curl git
Nano nmap
openssl software-properties-common
unzip zip
zlib1g-dev autoconf
pkg-config libssl-dev
Librerías PHP
Pdo pdo_mysql
Zip mongodb
Configuración
PHP
Se habilita las siguientes extensiones:
● apcu
● mongodb
Fuente: autores.
2.1.2.3 BASE_COMPOSER
Hereda de la imagen BASE_PHP e implementa herramientas, configuraciones y un
script que se encarga de instalar o actualizar las dependencias de un proyecto PHP
que se encuentre ubicado en el directorio de trabajo y haga uso de composer.
32
Tabla 9: Imagen composer
Imagen base BASE_PHP7.1-FPM
Herramientas principales
composer Configuración por defecto
Fuente: autores.
2.1.2.4 BASE_JDK8
Hereda de la imagen BASE e implementa herramientas para las sub imágenes o
contenedores que necesiten de JAVA 8.
Tabla 10:Imagen JDK8
Imagen base BASE
Herramientas principales
java8 Configuración por defecto
Fuente: autores.
2.1.2.5 BASE_NGINX
Contiene las herramientas y configuraciones necesarias para crear una imagen o
contenedor para servidor web o proxy inverso.
Tabla 11: Imagen Nginx
Imagen base nginx
Directorio de trabajo opt/escoltrams
Herramientas
nano nmap
procps acl
Configuración
NGINX ● Establecimiento de usuario
● Configuración de eventos y peticiones Http
Fuente: autores.
33
2.1.2.6 APIREST
Extiende las funcionalidades de la imagen BASE_PHP7.1-FPM e instala extensiones
de PHP dependiendo el tipo de entorno a implementar.
Tabla 12: Imagen API REST
Imagen base BASE_PHP7.1-FPM
Directorio de trabajo opt/escoltrams/apirest
Herramientas
xdebug
Configuración
Sistema ● Instala dependencia a partir de la variable de
entorno ($MODO_EJECUCION).
Fuente: autores.
2.1.2.7 KEYCLOAK
Extiende las funcionalidades de la imagen BASE_JDK8, se instala y se configuran
herramientas para montar sin sistema Keycloak con conexión a un servidor Mysql.
Tabla 13: Imagen Keycloak
Imagen base BASE_JDK8
Puertos 8080: Keycloak
Herramientas
keycloak JDBC MYSQL
Configuración
Keycloak
● Se configura para que el servidor Keycloak se
conecte a un servidor Mysql mediante
variables de entorno que pueden ser
modificadas por imágenes o contenedores
Fuente: autores.
34
2.1.3 JERARQUÍA DE IMÁGENES
El sistema Docker dentro de sus funciones establece una serie de contenedores que
cuentan con una serie de imágenes de las dependencias que requiera un sistema en
particular, existen varias imágenes públicas con elementos básicos como PHP, JAVA,
Ubuntu, Apache entre otras.
En la ilustración 1 se esbozan las imágenes (requisitos para que funcione el sistema) y
como están relacionadas jerárquicamente cada una de ellas.
Ilustración 1: Jerarquía de Imágenes
Fuente: autores.
2.1.4 CREACIÓN DE CONTENEDORES
2.1.4.1 ESCOLTRAKING KEYCLOAK
Expone los servicios de keycloak en los puertos 8080 y 9990 para la red interna (api) y
60005 y 60006 hacia la red externa.
Imagen escoltrams/keycloak
Puertos Servidor Contenedor
60005 8080
60006 9990
Networks api
BASE
BASE_JDK8 BASE_COMPOS
ER APIREST BASE_NGINX
BASE_PHP7.1-
FPM
KEYCLOAK
35
2.1.4.2 ESCOLTRAKING API PHP
Imagen escoltrams/apirest
Volumes Servidor Contenedor
./Code/escoltraking /opt/escoltrams/apirest
./Logs/php /opt/escoltrams/apirest/var/logs
Networks api
2.1.4.3 ESCOLTRAKING NGINX
Contenedor encargado del procesamiento de peticiones HTTP
Imagen escoltrams/base_nginx
Puertos Servidor Contenedor
60010 80
60009 8080
Volumes
Servidor Contenedor
./Config/nginx/default.conf /etc/nginx/conf.d/default.conf
./Config/nginx/sites-enabled /etc/nginx/sites-enabled
./Code/escoltraking /opt/escoltrams/apirest
./Logs/nginx /var/log/nginx
Networks Api
2.1.4.4 ESCOLTRAKING COMPOSER API
Servicio que está disponible únicamente en la red interna (api) y que tiene como
objetivo actualizar las dependencias de los proyectos PHP que se encuentre en la
carpeta opt/escoltrams/app ubicada dentro del contenedor.
Imagen escoltrams/base_composer
Volumes Servidor Contenedor
./Code/escoltraking /opt/escoltrams/app
Networks api
2.1.5 CLÚSTER DE SERVIDORES
El sistema cuenta con una infraestructura que además de separar cada uno de los
servicios en diferentes contenedores con la tecnología brindada por Docker, se
36
desarrolló una solución de alta disponibilidad y rendimiento con la implementación de
un clúster capaz de distribuir las cargas y disminuir el tiempo de respuesta de la
aplicación, todo esto realizado con un clúster de máquinas con Docker Swarm. Esta
tecnología permite la inicialización de un clúster con un nodo mánager primario, el cual
tiene la capacidad de vincular o expulsar nodos al clúster, ya sean manager o worker.
Los nodos mánager son los encargados de administrar y distribuir los diferentes
servicios y tareas a los nodos workers, por otro lado, los nodos worker solamente se
limitan a brindar los recursos de hardware para la ejecución de los servicios y el
desarrollo de las tareas.
Al implementar un clúster con Docker Swarm, facilita la escalabilidad del sistema al
permitir la integración de nuevos nodos con Sistemas Operativos distintos y poderlos
administrar desde cualquier nodo Manager.
Ilustración 2: Clúster de servidores
Fuente: autores.
2.1.6 DISTRIBUCIÓN DE CONTENEDORES
Con la replicación y distribución de contenedores en los diferentes servidores
dependiendo su carga de manera automática, se garantiza la disponibilidad de los
servicios ante la caída de algún servidor y la distribución de procesos entre los
diferentes servidores.
37
Ilustración 3: Distribución de contenedores en tres servidores
Fuente: autores.
Con la implementación del sistema Swarm que brinda Docker, se da la posibilidad de
escalar el sistema en cualquier momento de manera fácil y rápida.
2.1.7 CONJUNTO DE REPLICAS DE BASES DE DATOS
Por otro lado, se garantizará el acceso a la base de datos desde diferentes servidores
con la implementación de un conjunto de réplicas de en los diferentes servidores con
los que cuente la empresa en su momento, donde el servidor principal va a hacer las
veces de réplica primaria y en caso de alguna caída, alguno de los servidores
secundarios pasa a ser el primario y no interrumpe el funcionamiento del sistema.
38
Ilustración 4: Conjunto de réplicas de base de datos
Fuente: https://docs.mongodb.com/manual/replication/
Con la implementación de este tipo de estrategia para el almacenamiento, se dan las
pautas para una futura implementación de un sistema de bases de datos distribuidas
debido a la proyección que tiene el negocio y la necesidad de acceso a la información
desde diferentes partes del país y del conteniente conforme el sistema y el negocio
vaya creciendo.
39
3 DESARROLLO DEL SISTEMA PARA EL CONSUMO DE SERVICIOS DEL API DE OSRM Y OPEN STREET MAPS.
El sistema hace uso de diferentes servicios web ofrecido por OSRM Project, que es
una máquina de enrutamiento realizada en C++ de uso gratuito, que junto con Open
Street Maps como para la implementación de mapas, componen las tecnologías
utilizadas para el desarrollo principal del proyecto.
Para el presente proyecto uno de los servicios más importantes es el de route driving
que entrega los datos respecto a la ruta que debe tomar el automóvil de un origen a un
destino dado previamente. Para hacer uso de este servicio basta con hacer una
petición http de tipo POST a la siguiente dirección:
Ilustración 5: Url servicio route driving de OSRM
"http://router.project-osrm.org/route/v1/driving/"+latO+","+lonO+";"+latD+","+lonD+"?geometries=geojson&overview=full"
Fuente: Autores
Donde latO es latitud de origen, lonO es longitud de origen, latD es latitud destino
lonD es longitud destino.
En respuesta a esta petición llega una estructura de datos en forma de JSON que
contiene la información necesaria para dibujar el mapa en Open Street Maps.
{"routes":[{"geometry":{"coordinates":[[-74.216019,4.580233],[-
74.215691,4.580414],[-74.215296,4.580634],[-74.214418,4.581122],[-
74.214143,4.581275],[-74.213699,4.581523],[-74.213228,4.581786],[-
74.213182,4.581811],[-74.212381,4.582262],[-74.211684,4.582681],[-
74.211626,4.58272],[-74.211406,4.582854],[-74.21107,4.583032],[-
74.210727,4.583197],[-74.210628,4.583248],[-74.210426,4.583343],[-
74.210216,4.583453],[-74.20995,4.583593],[-74.209741,4.583695],[-
74.209652,4.583739],[-74.20931,4.583899],[-74.209121,4.583987],[-
74.209006,4.584043],[-74.208858,4.584115],[-74.208603,4.584238],[-
74.208291,4.584389],[-74.207715,4.584676],[-74.207544,4.584758],[-
74.207071,4.584979],[-74.207031,4.585],[-74.206914,4.585062],[-
74.206578,4.58524],[-74.206383,4.585349],[-74.206326,4.58538],[-
74.205914,4.585586],[-74.205428,4.585813],[-74.204278,4.586367],[-
74.203209,4.586882],[-74.203153,4.586909],[-74.202314,4.587319],[-
74.202042,4.587455],[-74.201776,4.587593],[-74.20125,4.587884],[-
74.200895,4.588084],[-74.200572,4.588257],[-74.199476,4.588842],[-
74.199401,4.58888],[-74.19887,4.589145],[-74.198547,4.589306 ..
40
El anterior es un ejemplo de una respuesta a una petición realizada a los servicios de
OSRM para obtener la ruta por la que debe cruzar el automóvil para llegar a su destino.
Luego de obtener esta información se procede a plasmarla en Open Street Maps de la
siguiente forma:
Ilustración 6: Mapa ejemplo servicio router driving OSRM
Fuente: Autores
A partir de lo anterior se puede evidenciar como la aplicación consumió los servicios de
OSRM y como grafico los resultados mediante la utilización de la librería Leaflet basada
en Open Street Maps.
41
4 DESARROLLO DEL SISTEMA BACKEND
El sistema backend se desarrolló con PHP y el Framework Symfony, implementado
sobre una plataforma Linux en un servidor ofrecido por Amazon EC2.
Cada uno de los servicios devolverá como respuesta, según sea el caso, la información
en formato JSON (JavaScript Object Notation). Para realizar una petición al servidor se
debe contar con un token previamente designado a cada usuario, de esta forma se
asegura que no cualquier usuario puede hacer uso de dichos servicios.
Para el desarrollo del proyecto se implementaron los procesos que propone el marco
para desarrollos agiles SCRUM, debido en gran medida a la experiencia de los
desarrolladores en la implementación de este tipo de metodología, además de la
practicidad y alta productividad que se puede lograr con este método de trabajo. De
manera detallada se expondrán cada una de las etapas del desarrollo dando cuenta de
cada uno de los requerimientos, el análisis y las actividades planeadas para cumplir
con los objetivos del proyecto.
4.1 ANALISIS Y RECOLECCION DE INFORMACION
Para el diseño e implementación del sistema backend se realizó un proceso de análisis
y recolección de información para determinar cuáles eran las entidades que
participaban
4.1.1 IDENTIFICACIÓN DEL SCRUM MASTER
En la reunión realizada se selecciona como Scrum Master a: Jaime Brandon Robles
Fajardo quien será responsable de la planificación y asignación de tareas, además de
aplicar y enriquecer el proyecto con las prácticas Scrum.
4.1.2 FORMACIÓN DE EQUIPOS
Para el caso, se establece un equipo único de trabajo conformado por:
Equipo 1:
• Carlos Andrés Ortiz Galindo
Tecnólogo en Sistematización de datos
Experiencia en desarrollo de software de más de 3 años.
• Jaime Brandon Robles Fajardo
Tecnólogo en Sistematización de datos
Experiencia en desarrollo de software de más de 3 años.
42
4.1.3 LISTA PRIORIZADA DE PENDIENTES DEL PRODUCTO
● Diseñar base de datos para almacenar la información.
● Realizar la virtualización de los servidores.
● Asignación de viajes a los conductores.
● Capturar datos de trazabilidad durante el viaje.
● Gestión de usuarios.
● Captura de evidencias fotográficas en cada punto de control.
● Generación de reporte con información de cada viaje realizado.
Para la entrega de los pendientes de producto se establecen los siguientes criterios de
terminado:
● Cada entrega debe ser puesta a prueba por parte del equipo de desarrollo quien
dará las pautas para aceptar o no el producto.
● El desarrollo debe contar con los mínimos requerimientos en cuanto diseño
establecidos por el equipo.
● Luego de realizar las validaciones anteriores se hace entrega a el dueño del
producto, quién será el encargado de dar el visto bueno para la puesta en
producción del desarrollo.
4.1.4 PLANIFICACIÓN DEL LANZAMIENTO (VER ANEXO 2: CRONOGRAMA)
4.1.5 HISTORIAS DE USUARIO
Se dedicará una semana con reuniones diarias para la recolección de la información de
cada uno de los procesos realizados por la empresa enfocados con el objetivo principal
planteado. Con esto se generarán historias de usuarios y se desarrollarán y priorizaron
los requerimientos. Por otro lado, se plantean una serie de entregables luego de
realizar este proceso.
Tabla 14: Historia 1
Historia 1: Un coordinador asigna un viaje a un escolta.
Como coordinador, debería asignar un viaje a un escolta.
El coordinador debe ingresar los datos de viaje ingresados previamente.
Fuente: autores.
43
Tabla 15: Historia 2
Historia 2: Un coordinador ve el listado de viajes asignados.
Como coordinador, debería ver los viajes asignados a los diferentes escoltas.
En la vista del escolta se muestra un listado con todos los viajes asignados a él y la
opción de iniciar el que tenga activo en ese momento.
Fuente: autores.
Tabla 16: Historia 3
Historia 3: Un escolta, debería aceptar el viaje.
Como coordinador, debería ver los viajes asignados a los diferentes escoltas.
Cada vez que el escolta esté a cierta distancia del punto de control debe ingresar los
datos especificados en reporte.
Se debe mostrar una alerta cuando el escolta esté cerca de cada punto de control.
La toma de los datos debe ser parametrizable (cada cuanto tiempo se va a
enviar información sobre la ubicación del escolta).
La aplicación debe guardar la ubicación GPS en el momento en que se guarda cada
REPORTE.
Este proceso se repite tantas veces como puntos de control existan.
Fuente: autores.
Tabla 17: Historia 4
Historia 4: Un escolta, termina el viaje.
Como escolta, deberá verificar que todos los requisitos durante el viaje se
cumplieron.
Al finalizar el recorrido se debe mostrar una opción donde se verifique que se
cumplieron todos los requisitos y firmados los documentos necesarios.
Fuente: autores.
44
Tabla 18: Historia 5
Historia 5: Un coordinador, genera reportes.
Como coordinador, debería generar reportes sobre los viajes realizados.
Exportación de reportes con información de los viajes realizados
Fuente: autores.
4.1.6 ENTIDADES IDENTIFICADAS
Persona
● Escolta
● Coordinador
● Cliente (Dueño de la carga)
Viaje
● Fecha y hora
● Datos de la carga
● Placas de Tráiler
● Tipo de transporte
○ Vehicular
○ Motorizado
○ Cabina
● Placas de cabezote
● Observaciones
● Punto de origen (Ciudad Origen)
● Punto destino (Ciudad Destino)
● Anticipo (si existe)
● Orden de servicio
● Consecutivo
Tipo de servicio
● Escolta
● Apoyo y control
Reporte: datos que se recolectan en cada punto de control
● Ubicación GPS (Longitud y Latitud)
● Fotografía
● Observaciones
45
Módulos candidatos a desarrollar
● Login para usuarios
● CRUDS para todas las entidades que necesiten de administración
● Asignación de viaje
● Listado con viajes asignados al escolta
● Vista del viaje ya aceptado y en curso
● Registro de cada uno de los puntos de control
● Vista final de verificación de requerimientos
4.1.7 APROBACIÓN, ESTIMACIÓN Y ASIGNACIÓN DE HISTORIAS DE USUARIO
EJ1: Carlos Andres Ortiz Galindo
EJ2: Jaime Brandon Robles Fajardo
Tabla 19: Requerimientos
Requerimiento Responsable Prioridad
Diseñar base de datos para almacenar
la información.
EJ1 Alta
Realizar la virtualización de los
servidores.
EJ1 Alta
Capturar datos de trazabilidad durante
el viaje.
EJ2 Alta
Asignación de viajes a los conductores. EJ2 Alta
Gestión de usuarios. EJ1 Media
Implementación de servicios de Project
OSRM y Open Street Maps.
EJ2 Alta
Captura de evidencias fotográficas en
cada punto de control.
EJ2 Media
Fuente: autores.
46
4.1.8 CREACIÓN DE LA LISTA DE PENDIENTES DEL SPRINT
Tabla 20: Lista de pendientes
SPRING NOMBRE ENTREGABLE RESPONSABLE
1 BASE DE DATOS Modelos relacional y base de datos
creada en Mongodb
EJ1
2 VIRTUALIZACIÓN DE
SERVIDORES
Arquitectura funcional con los
servidores y base de datos.
EJ1
3 WEB SERVICES API rest funcional. EJ1
Usuarios EJ1
Viajes EJ1
Asignación de viajes EJ1
4 APLICACIÓN MÓVIL Interfaz móvil capaz de consumir
servicios del API.
EJ2
Usuarios EJ2
Viajes EJ2
Asignación de viajes EJ2
5 CAPTURA Y
ALMACENAMIENTO DE
FOTOGRAFÍAS
Toma de fotografías en cada punto
de control.
EJ2
Captura en inicio de viaje EJ2
Captura en punto de control EJ2
Captura en finalización del
viaje
EJ2
6 IMPLEMENTACIÓN DE
SERVICIOS DE OSRM Y
OPEN STREET MAPS
Consumo de servicios de geocoder
y places.
EJ2
7 PRUEBAS Testeo del sistema EJ1, EJ2 y
cliente
Fuente: autores.
47
4.2 SERVICIOS WEB
El API Rest cuenta con una serie de servicios que serán consumidos por la aplicación móvil, a continuación, se listan cada uno de los servicios desarrollados especificando su url y método HTTP respectivamente.
En la ilustración 7 se puede observar los tres servicios expuestos, lo cuales
representan la creación y obtención de la entidad Países, que hace referencia a los
países a los que está relacionados tanto el usuario de la app y la empresa.
Ilustración 7: Servicios de País
Fuente: autores.
En la ilustración 8 y la ilustración 9 se puede observar los tres servicios expuestos, lo
cuales representan la creación y obtención de la entidad Departamentos y Municipios,
que hace referencia a la relación con los viajes.
Ilustración 8: Servicios de Departamento
Fuente: autores.
Ilustración 9: Servicios de Municipio
Fuente: autores.
48
La ilustración 10 muestra los servicios de creación, edición y listado de empresas registradas
en el sistema. Estos servicios sirven para registrar las empresas que se requieran en el
sistema.
Ilustración 10: Servicios de Empresa
Fuente: autores.
La ilustración 11 muestra los servicios de puntos de control, dentro de los que se encuentra uno
de los más importantes, donde se ingresaran los puntos donde el sistema debe mostrar alertas
para notificar al usuario que ha llegado al punto de control y debe subir la información referente
a este punto.
Ilustración 11: Servicios de Punto de control
Fuente: autores.
En la ilustración 12 se pueden observar los servicios referentes a la creación, edición y
obtención de la entidad vehículos, esta hace referencia a toda la flota de vehículos que se
relaciona en el sistema. Existen vehículos para los escoltas, vehículos escoltados en el
sistema.
49
Ilustración 12: Servicios de Vehículo
Fuente: autores.
En la ilustración 13, tipos de servicios, se puede observar los servicios expuestos para
la entidad tipos de servicios. Los tipos de servicios son las categorías en las que se
puede clasificar los viajes: servicio de escolta motorizado, servicio de escolta en
automóvil, etc.
Ilustración 13: Servicios de Tipo de servicio
Fuente: autores.
La ilustración 14, una de las más importantes, muestra los servicios expuestos para la
entidad viajes. Al momento de crear un viaje, al registrar cada cierto intervalo de tiempo
las coordenadas del viaje en curso. Además de contar con los servicios de edición y
listado de todos los viajes.
50
Ilustración 14: Servicios de Viaje
Fuente: autores.
La ilustración 15, muestra los servicios referentes a las operaciones de creación,
edición, lectura de las personas que se encuentran registradas en el sistema.
Ilustración 15: Servicios de Persona
Fuente: autores.
La ilustración 15, muestra los servicios referentes a las operaciones de creación,
edición, lectura de los cargos que se encuentran registradas en el sistema, entra los
que se encuentran: escolta, administrador, conductor y cliente.
51
Ilustración 16: Servicios de Cargos
Fuente: autores.
52
5 CONSTRUCCIÒN DE LA INTERFAZ CLIENTE
En este capítulo se evidenciará el desarrollo de la aplicación móvil y las diferentes
vistas construidas para la app, evidenciando con cada una vista y la descripción de la
funcionalidad de cada una.
La aplicación consume los servicios ofrecidos por el BackEnd desarrollado en Symfony
3.4. La comunicación con el APIRest se hace bajo el estándar de autorización OAuth
2.0 con la generación de tokens únicos para la realización de las peticiones al servidor.
Para el desarrollo de la aplicación web se hizo uso del framework Ionic 2, el cual da
una gran cantidad de utilidades para la creación de este tipo de aplicaciones. En cuanto
al tema de estilos Ionic 2 ofrece herramientas graficas con una calidad aceptable,
adaptadas a cada uno de los escenarios necesarios en este proyecto.
La aplicación móvil cuenta con una interfaz para la autentificación de usuarios en la que
se deberá ingresar el username y el password previamente creados por el
administrador del sistema.
Ilustración 17: Área de autenticación
Fuente: autores.
53
En la página principal se mostrarán los viajes asignados a cada uno de los escoltas,
con la opción de “Ver” para dar seguimiento o aceptar cada uno de ellos. Además, se
muestra una opción para acceder a la parte administrativa.
Ilustración 18: Pantalla inicial
Fuente: autores.
54
Ilustración 19: Menú principal
Fuente: autores.
El menú lateral cuenta con las opciones de CRUD’s de las entidades del sistema con las que se podrá acceder más fácilmente a cualquiera de las opciones.
55
Ilustración 20: Autorización de ubicación
Fuente: autores.
Al iniciar la aplicación pedirá la autorización para acceder a la ubicación del dispositivo móvil y así poder capturar la información necesaria para cada viaje o proceso necesario.
56
Ilustración 7: Formularios de creación de viaje
Fuente: autores.
El sistema cuenta con una serie de formularios para cada una de las entidades (CRUD). La finalidad de estas vistas y formulario es la de gestionar toda información necesaria para el correcto funcionamiento de la aplicación.
El usuario administrador puede crear un viaje dependiendo de las necesidades que
tenga la empresa en su momento. En este formulario sé que el usuario ingrese toda la
información referente al viaje: nombre del viaje origen, destino, etc.
57
Ilustración 21: Selección de coordenada GPS
Fuente: autores.
El sistema hace uso de los servicios de OpenStreetMap para visualizar los mapas y así
poder seleccionar el origen y el destino del viaje.
58
Ilustración 9: Confirmación de viaje creado
I
Fuente: autores.
Cuando se crea un viaje aparece este mensaje indicado la correcta creación y el
registro de viaje es almacenado y asignado al escolta que se haya indicado.
59
Ilustración 10: Visualización de la ruta del viaje
Fuente: autores.
Cada viaje se le debe asignar una serie de puntos de control, donde se tomarán los
registros fotográficos y las observaciones según sea cada caso.
60
Ilustración 11: Formulario de creación de puntos de control
Fuente: autores.
Luego de crear el viaje se debe asignar cada uno de los puntos de control sobre el
recorrido. Para este proceso, se selecciona un punto en la pantalla e ingresar el
nombre y el radio (metros) de alcance para la notificación.
61
Ilustración 12: Punto de control asignado a un viaje
Fuente: autores.
62
Ilustración 13: Asignación de puntos de control
Fuente: autores.
63
Ilustración 14: Listado de puntos de control asignados a un viaje
Fuente: autores.
Cuando se ingresan todos los puntos de control al viaje, solo queda presionar el botón
continuar y ya quedaran guardados todos los puntos para iniciar el viaje cuando se
decida.
64
Ilustración 15: Resumen de puntos de control asignados
Fuente: autores.
65
Ilustración 16: Pasó 2 de creación de viaje diligenciado
Fuente: autores.
Cuando el escolta este en el punto de inicio del viaje debe completar la información del
viaje, esta información tiene que ver con el automóvil que va a ser escoltado. Se
registrará información como: número de placa, nombre del conductor, numero de
container etc.
66
Ilustración 16: Confirmación de iniciar el viaje
Fuente: autores.
Al culminar el diligenciamiento del formulario y presionar el botón de asignar, el sistema
lanzara un mensaje de confirmación.
67
Ilustración 17: Seguimiento del recorrido de la ruta
Fuente: autores.
Cuando se acepta el viaje el sistema abre la aplicación Waze con las coordenadas de
origen y destino para guiar al escolta sobre su ruta en el presente viaje.
68
Ilustración 18: Seguimiento del recorrido de la ruta 2
Fuente: autores.
69
6 PRUEBAS
6.1 SERVICIOS REST
6.1.1 PRUEBAS DE CARGA Y DE ESTRES
Se realiza un conjunto de pruebas con la herramienta jMeter al clúster de servidores
que contiene los servicios del API REST, con el objetivo de observar el comportamiento
de los mismos ante posibles situaciones que se puedan presentar en el futuro.
Ilustración 22: Especificación técnica de nodos de prueba
Tipo Máquina virtual
RAM 0.969G RAM
Procesado Intel Core I5-7200U CPU @ 2.50 GHz 2.71 GHz
Núcleos 1
Tipo de disco duro Mecánico
Fuente: autores.
6.1.1.1 PRUEBAS CON UN NODO
6.1.1.1.1 PRUEBA 1
Tabla 21: Resumen de la prueba 1 a un nodo
Escenario de pruebas – 1m:46s
No. Nodos 1 Total de muestras 100
Ciclos 1 Tiempo medio 9721 ms
Periodo 10s Tiempo mínimo 2617 ms
Peticiones 10 Tiempo máximo 20368 ms
Usuarios 10 Porcentaje de error 0%
Fuente: autores.
Ilustración 23: prueba 1 con un nodo
Fuente: autores.
70
6.1.1.1.2 PRUEBA 2
Tabla 22: Resumen de la prueba 2 a un nodo
Escenario de pruebas – 2m:45s
No. Nodos 1 Total de muestras 200
Ciclos 2 Tiempo medio 7706
Periodo 10s Tiempo mínimo 2033
Peticiones 10 Tiempo máximo 17130
Usuarios 10 Porcentaje de error 0%
Fuente: autores.
Ilustración 24: prueba 2 con un nodo
Fuente: autores.
6.1.1.1.3 PRUEBA 3
Tabla 23: Resumen de la prueba 3 a un nodo
Escenario de pruebas – 2m:59s
No. Nodos 1 Total de muestras 200
Ciclos 1 Tiempo medio 16746 ms
Periodo 10s Tiempo mínimo 2703 ms
Peticiones 10 Tiempo máximo 28126 ms
Usuarios 20 Porcentaje de error 0%
Fuente: autores.
Ilustración 25: prueba 3 con un nodo
Fuente: autores.
71
6.1.1.2 PRUEBAS CON DOS NODOS
6.1.1.2.1 PRUEBA 1
Tabla 24: Resumen de la prueba 1 a dos nodos
Escenario de pruebas – 1m:15s
No. Nodos 2 Total de muestras 100
Ciclos 1 Tiempo medio 6085 ms
Periodo 10s Tiempo mínimo 1817 ms
Peticiones 10 Tiempo máximo 13561 ms
Usuarios 10 Porcentaje de error 0%
Fuente: autores.
Ilustración 26: prueba 1 con dos nodos
Fuente: autores.
6.1.1.2.2 PRUEBA 2
Tabla 25: Resumen de la prueba 2 a dos nodos
Escenario de pruebas – 2m:26s
No. Nodos 2 Total de muestras 200
Ciclos 2 Tiempo medio 6563 ms
Periodo 10s Tiempo mínimo 1866 ms
Peticiones 10 Tiempo máximo 15777 ms
Usuarios 10 Porcentaje de error 0%
Fuente: autores.
Ilustración 27: prueba 2 con dos nodos
Fuente: autores.
72
6.1.1.2.3 PRUEBA 3
Tabla 26: Resumen de la prueba 3 a dos nodos
Escenario de pruebas – 2m:08s
No. Nodos 2 Total de muestras 200
Ciclos 1 Tiempo medio 10905 ms
Periodo 10s Tiempo mínimo 1757 ms
Peticiones 10 Tiempo máximo 22162 ms
Usuarios 20 Porcentaje de error 0%
Fuente: autores.
Ilustración 28: prueba 3 con dos nodos
Fuente: autores.
6.1.1.3 PRUEBAS CON TRES NODOS
6.1.1.3.1 PRUEBA 1
Tabla 27: Resumen de la prueba 1 a tres nodos
Escenario de pruebas – 0m:57s
No. Nodos 3 Total de muestras 100
Ciclos 1 Tiempo medio 4876 ms
Periodo 10s Tiempo mínimo 1687 ms
Peticiones 10 Tiempo máximo 17009 ms
Usuarios 10 Porcentaje de error 0%
Fuente: autores.
Ilustración 29: prueba 1 con tres nodos
Fuente: autores.
73
6.1.1.3.2 PRUEBA 2
Tabla 28: Resumen de la prueba 2 a tres nodos
Escenario de pruebas – 1m:38s
No. Nodos 3 Total de muestras 200
Ciclos 2 Tiempo medio 4498 ms
Periodo 10s Tiempo mínimo 1713 ms
Peticiones 10 Tiempo máximo 10200 ms
Usuarios 10 Porcentaje de error 0%
Fuente: autores.
Ilustración 30: prueba 2 con tres nodos
Fuente: autores.
6.1.1.3.3 PRUEBA 3
Tabla 29: Resumen de la prueba 3 a tres nodos
Escenario de pruebas – 1m:31s
No. Nodos 3 Total de muestras 200
Ciclos 1 Tiempo medio 8083 ms
Periodo 10s Tiempo mínimo 1960 ms
Peticiones 10 Tiempo máximo 15053 ms
Usuarios 20 Porcentaje de error 0%
Fuente: autores.
Ilustración 31: prueba 3 con tres nodos
Fuente: autores.
74
6.1.1.4 COMPARACIÓN DE RESULTADOS
De acuerdo con las pruebas anteriores se puede evidenciar que a medida que se
aumentan las peticiones en un mismo lapso, la peticiones son resueltas en un mayor
intervalo de tiempo, por otra parte, se puede constatar que el intervalo de tiempo de las
tres pruebas, se reduce al agregar más nodos al clúster.
En la siguiente Ilustración se plasma el resultado de las pruebas que se detallan en las
tablas de la 21 a la 29 y se puede ver la relación de tiempo de respuesta versus
cantidad de nodos.
Ilustración 32: Comparación de cantidad de nodos Vs tiempo promedio de respuesta
Fuente: autores.
Prueba 1 Prueba 2 Prueba 3
1 Nodo 9721 7706 16746
2 Nodos 6085 6563 10905
3 Nodos 4876 4498 8083
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
Tie
mp
o e
n m
s
Tiempo promedio de respuesta
75
7 CONCLUSIONES
Durante el desarrollo del presente proyecto se pudieron evidenciar gran variedad de
inconvenientes y aprendizajes debido a la implementación de algunas tecnologías que
requirieron de un riguroso seguimiento e investigación para aplicarlas de la mejor
manera. Para resaltar y que pueda servir de retroalimentación para otros proyectos,
para el juicio de los desarrolladores, a continuación algunas de los ítems más
relevantes:
• Para la implementación de un sistema basado en posicionamiento global se
debe tener en cuenta las desviaciones en la medición de las coordenadas
debido a la inexactitud de los sensores de los dispositivos móviles.
• Las ventajas evidenciadas durante el desarrollo fueron: la descomposición de un
sistema en subsistemas, facilita la escalabilidad y mantenimiento de mismos,
contar con servicios redundantes en una red, aumenta la disponibilidad y
rendimiento del sistema y la implementación de metodologías agiles hace que
las entregas se hagan constantemente y se genere una comunicación dinámica
entre el cliente y el grupo de desarrollo.
• MongoDB cuenta con el soporte para la creación de un conjunto de réplicas que
nutre de gran manera un sistema de alta disponibilidad ya que permite la
actualización de base de datos en diferentes servidores.
• La utilización de frameworks para el desarrollo frontend, como Ionic, facilitan el
desarrollo de una buena interfaz gráfica y brinda muchas funcionalidades, pues
presenta muchas soluciones a problemas típicos de este tipo de desarrollos.
76
8 BIBLIOGRAFÍA
Aranda Pinilla, C. and Rojas Ruiz, E. (2015). Sistema de gestión de mantenimientos
aplicado a flotas de vehículos de carga pesada mediante el uso de GPS /. Bogotá:
Universidad Distrital Francisco José de Caldas.
Babel Blog. (2017). ¿Por qué debería usar Docker en mi proyecto? [online] Disponible
en: http://babel.es/es/blog/blog/febrero-2017/por-que-deberia-usar-docker-en-mi-
proyecto [Consultado el 12 oct. 2017].
Docker. (2017). What is Docker. [online] Disponible en: https://www.docker.com/what-
docker [Consultado el 9 oct. 2017].
Google Developers. (2017). Google Maps API | Google Developers. [online] Disponible
en: https://developers.google.com/maps/?hl=es-419 [Consultado el 9 oct. 2017].
Ionicframework.com. (2017). Welcome to Ionic - Ionic Framework. [online] Disponible
en: http://ionicframework.com/docs/v1/guide/preface.html [Consultado el 9 oct. 2017].
MongoDB. (2017). What Is MongoDB? [online] Disponible en:
https://www.mongodb.com/what-is-mongodb [Consultado el 9 oct. 2017].
Moreno Castro, L. and Fajardo Rodríguez, D. (2015). Sistema de seguimiento a rutas
realizadas por taxistas a través de alertas taxi track. Bogotà.
Nginx.org. (2017). Basic HTTP server features. [online] Disponible en:
https://nginx.org/en/ [Consultado el 13 oct. 2017].
Satpathy, T. (2017). Scrum body of knowledge (sbok guide). [online] scrumstudy.
Disponible en: https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-
2016.pdf [Consultado el 9 oct. 2017].
Symfony.com. (2017). What is Symfony. [online] Disponible en:
https://symfony.com/what-is-symfony [Consultado el 9 oct. 2017].
Turnbull, J. (2017). The docker book. [online] Containerization is the new virtualization.
Disponible en: https://www.dockerbook.com/TheDockerBook_sample.pdf [Consultado el
9 oct. 2017].
77
Es.wikipedia.org. (2017). Sistema de posicionamiento global. [online] Disponible en:
https://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global [Consultado el 12 oct.
2017].
Es.wikipedia.org. (2017). NoSQL. [online] Disponible en:
https://es.wikipedia.org/wiki/NoSQL [Consultado el 12 oct. 2017].
78
ANEXOS
79
ANEXO 1: DISEÑO DE ARQUITECTURA DE VIRTUALIZACIÓN.
Ilustración 33: Diseño de arquitectura de virtualización
Fuente: autores.
80
ANEXO 2: CRONOGRAMA.
Ilustración 34: Cronograma
Fuente: autores.
81
ANEXO 3: ESPECIFICACIÓN DE CASOS DE USO
Tabla 30: Consultar usuarios
IDENTIFICACIÓN CASO DE USO ACTORES
CU_1 Consultar usuarios Administrador, Coordinador.
OBJETIVO
Listar usuarios registrados en el sistema.
DESCRIPCIÓN
Listar los usuarios registrados en el sistema. Cada registro debe tener las opciones para editar y desactivar.
ENTRADAS 1. Filtros como parámetros para listar a los usuarios.
RESULTADOS 1. Listado de usuarios registrados en el sistema.
PRECONDICIONES 1. El usuario administrador o coordinador debe estar registrado en el
sistema.
POSTCONDICIONES 1. El sistema debe quedar listo para que el nuevo usuario ingrese a la
aplicación.
CURSO NORMAL DE LOS EVENTOS
1. Ingresar a la opción de usuarios.
2. Se listan los usuarios registrados en el sistema.
PUNTOS DE INTERRUPCIÓN
● Las entradas tendrán tipos de datos específicos, en caso de no validarse el sistema no continuara con
el proceso.
Fuente: autores.
82
Tabla 31: Crear usuarios
IDENTIFICACIÓN CASO DE USO ACTORES
CU_2 Crear usuario Administrador, Coordinador.
OBJETIVO
Creación de usuarios para que puedan acceder al sistema
DESCRIPCIÓN
Muestra un formulario para realizar el registro de los datos del nuevo usuario
ENTRADAS
2. Identificación
3. Nombres
4. Apellidos
5. fecha de nacimiento
6. email
7. teléfono
8. rol
9. username
10. password
RESULTADOS El usuario queda registrado en el sistema y puede ser consultado.
PRECONDICIONES 2. El usuario administrador o coordinador debe estar registrado en el
sistema.
POSTCONDICIONES 2. El sistema debe quedar listo para que el nuevo usuario ingrese a la
aplicación.
CURSO NORMAL DE LOS EVENTOS
3. Ingresar a la opción de crear nuevo usuario.
4. El sistema muestra formulario (ver sección Entradas).
5. El usuario diligencia los datos.
6. El sistema valida los datos ingresados.
7. El sistema almacena los datos del nuevo usuario.
8. El sistema muestra un mensaje que indica que se guardó correctamente el usuario.
PUNTOS DE INTERRUPCIÓN
● Las entradas tendrán tipos de datos específicos, en caso de no validarse el sistema no continuara con
el proceso.
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará
Fuente: autores.
83
Tabla 32: Editar usuario
IDENTIFICACIÓN CASO DE USO ACTORES
CU_3 Editar usuario Administrador, Coordinador y trabajador.
OBJETIVO
Edición de datos de usuarios.
DESCRIPCIÓN
Muestra un formulario para realizar la actualización de los datos del usuario.
ENTRADAS
1. Identificación
2. Nombres
3. Apellidos
4. fecha de nacimiento
5. email
6. teléfono
7. rol
8. username
9. password
RESULTADOS Se actualizan los datos del usuario.
PRECONDICIONES 1. El usuario administrador, coordinador y trabajador debe estar
registrado en el sistema.
POSTCONDICIONES 1. El sistema debe quedar listo para editar otro usuario.
CURSO NORMAL DE LOS EVENTOS
1. Ingresar a la opción de editar usuario.
2. El sistema muestra formulario con los datos del usuario seleccionado (ver sección Entradas).
3. El usuario diligencia los datos.
4. El sistema valida los datos ingresados.
5. El sistema almacena los datos del usuario.
6. El sistema muestra un mensaje que indica que se guardó correctamente el usuario.
PUNTOS DE INTERRUPCIÓN
● Las entradas tendrán tipos de datos específicos, en caso de no validarse el sistema no continuara con
el proceso.
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
Fuente: autores.
84
Tabla 33: Eliminar usuario
IDENTIFICACIÓN CASO DE USO ACTORES
CU_4 Eliminar usuario Administrador, Coordinador.
OBJETIVO
Inhabilitar el usuario en el sistema.
DESCRIPCIÓN
Se muestra en el listado de usuarios la opción de eliminar usuario.
ENTRADAS
RESULTADOS Se inactiva el usuario en el sistema.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de
eliminación del usuario.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. Ingresar al listado de usuario activos en el sistema.
2. El sistema muestra la opción de eliminar en cada uno de los registros de usuario.
3. El sistema muestra un mensaje de confirmación.
4. el sistema inhabilita el usuario seleccionado.
PUNTOS DE INTERRUPCIÓN
● En el punto (3) en caso de no confirmarse la eliminación el sistema sigue mostrando el listado de
usuario.
Fuente: autores.
85
Tabla 34: Crear empresa.
IDENTIFICACIÓN CASO DE USO ACTORES
CU_5 Crear empresa Administrador, Coordinador.
OBJETIVO
Crear una nueva empresa en el sistema.
DESCRIPCIÓN
Se muestra un formulario con los datos necesarios para crear una empresa.
ENTRADAS 1. NIT
2. Nombre empresa
RESULTADOS 1. Se crea una nueva empresa en sistema.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de
creación de empresas.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. Ingresar a la opción de crear nueva empresa.
2. El sistema muestra el formulario con los campos definidos (ver sección Entradas).
3. El usuario diligencia los datos con la información correspondiente.
4. El usuario almacena la información.
5. El sistema guarda la nueva empresa.
6. El sistema muestra mensaje de finalización del proceso.
PUNTOS DE INTERRUPCIÓN
● Tanto el nombre y el NIT debe ser únicos, de lo contrario se mostrará un mensaje indicando la
situación.
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
Fuente: autores.
86
Tabla 35: Consultar empresa
IDENTIFICACIÓN CASO DE USO ACTORES
CU_6 Consultar empresa Administrador, Coordinador.
OBJETIVO
. Listar las empresas registradas en el sistema.
DESCRIPCIÓN
El sistema muestra un filtro para consultar las empresas registradas en el sistema.
ENTRADAS 1. NIT (filtro)
2. Nombre empresa (filtro)
RESULTADOS El sistema lista las empresas según el filtro seleccionado.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de listar de
empresas.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. El usuario ingresa a la opcion de empresas.
2. El sistema muestra una serie de campos (ver Entradas).
3. El usuario selecciona los filtros
4. El sistema muestra las empresas que cumplen con los filtros seleccionados.
PUNTOS DE INTERRUPCIÓN
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
Fuente: autores.
87
Tabla 36:Editar empresa
IDENTIFICACIÓN CASO DE USO ACTORES
CU_7 Editar empresa Administrador, Coordinador.
OBJETIVO
. Actualizar los datos de una empresa registrada en el sistema.
DESCRIPCIÓN
El sistema muestra un formulario con los datos de la empresa cargados y permite la actualización de los
mismos.
ENTRADAS 3. NIT
4. Nombre empresa
RESULTADOS 1. El sistema actualiza los datos de la empresa seleccionada.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de editar
de empresas.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. El usuario ingresa a la opción de listar empresas.
2. El usuario selecciona la empresa que desea editar.
3. El sistema muestra un formulario con los campos de la empresa (ver entradas).
4. El usuario diligencia los campos.
5. El sistema actualiza la información de la empresa.
PUNTOS DE INTERRUPCIÓN
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
● Tanto el nombre y el NIT debe ser únicos, de lo contrario se mostrará un mensaje indicando la
situación.
Fuente: autores.
88
Tabla 37: Eliminar empresa
IDENTIFICACIÓN CASO DE USO ACTORES
CU_8 Eliminar empresa Administrador, Coordinador.
OBJETIVO
Inhabilitar la empresa en el sistema.
DESCRIPCIÓN
El sistema inhabilita la empresa y todos lo relacionada a ella en el sistema.
ENTRADAS
RESULTADOS Se inactiva la empresa en el sistema.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de
eliminación de empresas.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. Ingresar al listado de empresas registradas en el sistema.
2. El usuario selecciona la empresa que desea inhabilitar.
3. El sistema muestra un mensaje de confirmación
4. El sistema inhabilita la empresa y todo lo relacionado a ella en el sistema.
PUNTOS DE INTERRUPCIÓN
● En el punto (3) en caso de no confirmarse la eliminación el sistema sigue mostrando el listado de
usuario.
Fuente: autores.
89
Tabla 38:Crear viaje
IDENTIFICACIÓN CASO DE USO ACTORES
CU_9 Crear viaje Administrador, Coordinador.
OBJETIVO
Creación de un nuevo viaje y asignándole un escolta para realizar el acompañamiento.
DESCRIPCIÓN
El sistema crea un nuevo viaje, solicitado por una empresa, y asignado a un escolta para realizar el
acompañamiento.
ENTRADAS
1. Origen: Campo autocompletado, lista los municipios de Colombia.
2. Destino: Campo autocompletado, lista los municipios de Colombia.
3. Tipo de servicio:
4. Escolta asignado: Campo autocompletado, lista los escoltas
registrados en el sistema.
5. Empresa: Nombre de la empresa que solicitó el servicio.
RESULTADOS 1. El sistema asigna el viaje al escolta seleccionado.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de
creación de nuevos viajes.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. El usuario selecciona la opción de crear nuevo viaje.
2. El sistema muestra un formulario con los campos (Ver Entradas).
3. El usuario diligencia el formulario con los datos necesarios.
4. El sistema asigna el nuevo viaje al escolta seleccionado.
5. El sistema alerta al escolta seleccionado que tiene un nuevo viaje.
PUNTOS DE INTERRUPCIÓN
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
Fuente: autores.
90
Tabla 39: Consultar viaje
IDENTIFICACIÓN CASO DE USO ACTORES
CU_10 Consultar viaje Administrador, Coordinador.
OBJETIVO
Listar los viajes realizados y asignados a los diferentes usuarios.
DESCRIPCIÓN
El sistema listara listara los viajes realizados y asignados a los diferentes usuarios. Contará con filtro para
realizar las búsquedas con mayor facilidad.
ENTRADAS
1. Origen: Campo autocompletado, lista los municipios de Colombia.
2. Destino: Campo autocompletado, lista los municipios de Colombia.
3. Tipo de servicio:
4. Escolta asignado: Campo autocompletado, lista los escoltas
registrados en el sistema.
5. Empresa: Nombre de la empresa que solicitó el servicio.
RESULTADOS Listado de los viajes registrados en el sistema.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de listar
viajes.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. El usuario selecciona la opción de viajes.
2. El sistema muestra un formulario con los campos para realizar el filtrado (ver Entradas).
3. El usuario define los filtros para la búsqueda.
4. El sistema muestra los resultados según según los filtros seleccionados.
PUNTOS DE INTERRUPCIÓN
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
Fuente: autores.
91
Tabla 40: Editar viaje
IDENTIFICACIÓN CASO DE USO ACTORES
CU_11 Editar Viaje Administrador, Coordinador.
OBJETIVO
Actualizar los datos de los viajes registrados en el sistema.
DESCRIPCIÓN
El sistema permite actualizar los datos de los viajes registrados en el sistema.
ENTRADAS
1. Origen: Campo autocompletado, lista los municipios de Colombia.
2. Destino: Campo autocompletado, lista los municipios de Colombia.
3. Tipo de servicio:
4. Escolta asignado: Campo autocompletado, lista los escoltas
registrados en el sistema.
5. Empresa: Nombre de la empresa que solicitó el servicio.
RESULTADOS 1. El sistema actualiza los datos del viaje registrado.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de listar
viajes.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. El usuario selecciona la opción de editar viaje.
2. El sistema muestra un formulario con los campos diligenciados (Ver Entradas).
3. El usuario diligencia el formulario con los datos necesarios.
4. El sistema actualiza la información del viaje al escolta seleccionado.
PUNTOS DE INTERRUPCIÓN
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
Fuente: autores.
92
Tabla 41: Aceptar viaje
IDENTIFICACIÓN CASO DE USO ACTORES
CU_12 Aceptar Viaje Administrador, Coordinador, Escolta.
OBJETIVO
El escolta acepta el viaje que fue asignado a él.
DESCRIPCIÓN
El sistema muestra un formulario donde el escolta debe ingresar algunos datos sobre el tractocamión que va a
escoltar.
ENTRADAS
1. Placa del automotor.
2. Nombre del conductor.
3. Número celular.
4. Color del tractocamión.
5. R.O
6. Número del contenedor.
7. Número del sello.
8. Foto general, debe aparecer el escolta junto a el tractocamión que va
a escoltar.
9. Foto del precinto #1.
10. Foto del precinto #2.
RESULTADOS 1. El escolta acepta el viaje e inicia el proceso de escolta.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de inicio
de viaje.
POSTCONDICIONES El sistema debe quedar listo para iniciar el viaje.
CURSO NORMAL DE LOS EVENTOS
PUNTOS DE INTERRUPCIÓN
● El usuario puede cancelar el viaje y el sistema debe mostrar un formulario para que describa la razón
de la cancelación del viaje.
Fuente: autores.
93
Tabla 42: Cerrar viaje
IDENTIFICACIÓN CASO DE USO ACTORES
CU_13 Cerrar viaje Administrador, Coordinador, Escolta.
OBJETIVO
Terminar el viaje al terminar el recorrido.
DESCRIPCIÓN
Al finalizar el viaje y se hayan registrado todas las evidencias del viaje el sistema debe terminar el viaje.
ENTRADAS
RESULTADOS 1. El sistema debe mostrar un mensaje de confirmación para cerrar o
terminar el viaje.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debió iniciar un viaje.
3. El usuario debe tener los permisos para realizar el proceso de
terminar viajes.
POSTCONDICIONES El sistema debe quedar listo para iniciar un nuevo viaje.
CURSO NORMAL DE LOS EVENTOS
1. Al terminar llegar al destino el sistema muestra un mensaje de confirmación para terminar el viaje.
2. El usuario acepta la finalización del viaje.
3. El sistema muestra un mensaje indicando que el viaje a sido terminado.
PUNTOS DE INTERRUPCIÓN
Fuente: autores.
94
Tabla 43: Cerrar viaje
IDENTIFICACIÓN CASO DE USO ACTORES
CU_14 Cerrar Viaje Administrador, Coordinador, Escolta.
OBJETIVO
Cancelar el viaje que le ha sido asignado.
DESCRIPCIÓN
El usuario puede cancelar el viaje, describiendo la razón de la misma.
ENTRADAS
RESULTADOS 1. El viaje queda cerrado.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de cerrar
viajes.
POSTCONDICIONES 1. El sistema debe quedar listo para iniciar un nuevo viaje.
CURSO NORMAL DE LOS EVENTOS
1. El sistema muestra todos los viajes asignados al usuario.
2. El usuario muestra la opción de cerrar viaje.
3. El sistema cierra el viaje.
PUNTOS DE INTERRUPCIÓN
Fuente: autores.
95
Tabla 44: Registrar punto de control
IDENTIFICACIÓN CASO DE USO ACTORES
CU_15 Registrar punto de control Administrador, Coordinador.
OBJETIVO
Registrar las coordenadas de los puntos de control en las diferentes partes del país.
DESCRIPCIÓN
El sistema debe permitir registrar los datos de los diferentes puntos de control.
ENTRADAS
1. Nombre.
2. Municipio.
3. Longitud.
4. Latitud.
5. Radio (metros).
RESULTADOS 1. El sistema almacena el nuevo punto de control.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de cerrar
viajes.
POSTCONDICIONES 1. El sistema debe quedar listo para registrar un nuevo punto de control.
CURSO NORMAL DE LOS EVENTOS
1. El usuario selecciona la opción de registrar un nuevo punto de control.
2. El sistema muestra un formulario con los campos necesarios (Ver entradas).
3. El usuario diligencia el formulario.
4. El sistema valida y almacena la información diligenciada.
5. El sistema muestra mensaje de almacenamiento correcto.
PUNTOS DE INTERRUPCIÓN
Fuente: autores.
96
Tabla 45: Consultar punto de control
IDENTIFICACIÓN CASO DE USO ACTORES
CU_16 Consultar punto de control Administrador, Coordinador.
OBJETIVO
Visualizar todos los puntos de control registrados en el sistema.
DESCRIPCIÓN
El sistema muestra un filtro para realizar la consulta de los diferentes puntos de control registrados en el
sistema.
ENTRADAS
1. Nombre.
2. Municipio.
3. Longitud.
4. Latitud.
5. Radio (metros).
RESULTADOS 1. El sistema filtra la información diligenciada y muestra los puntos de
control que concuerdan con los filtros.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de cerrar
viajes.
POSTCONDICIONES El sistema debe quedar listo para realizar otro filtro.
CURSO NORMAL DE LOS EVENTOS
1. El usuario ingresa a la opción de puntos de control.
2. El sistema muestra una serie de campos (ver Entradas).
3. El usuario selecciona los filtros
4. El sistema muestra los puntos de control que cumplen con los filtros seleccionados.
PUNTOS DE INTERRUPCIÓN
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
Fuente: autores.
97
Tabla 46: Editar punto de control
IDENTIFICACIÓN CASO DE USO ACTORES
CU_17 Editar punto de control Administrador, Coordinador.
OBJETIVO
Actualizar los datos de un punto de control registrado en el sistema.
DESCRIPCIÓN
El sistema muestra un formulario con los datos del punto de control cargados y permite la actualización de los
mismos.
ENTRADAS
1. Nombre.
2. Municipio.
3. Longitud.
4. Latitud.
5. Radio (metros).
RESULTADOS 1. El sistema actualiza los datos del punto de control seleccionado.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de editar
puntos de control.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
1. El usuario ingresa a la opción de listar puntos de control.
2. El usuario selecciona el punto de control que desea editar.
3. El sistema muestra un formulario con los campos del punto de control (ver entradas).
4. El usuario diligencia los campos.
5. El sistema actualiza la información del punto de control.
PUNTOS DE INTERRUPCIÓN
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
● El nombre debe ser único, de lo contrario se mostrará un mensaje indicando la situación.
Fuente: autores.
98
Tabla 47: Eliminar punto de control
IDENTIFICACIÓN CASO DE USO ACTORES
CU_18 Eliminar punto de control Administrador, Coordinador.
OBJETIVO
Inhabilitar el punto de control en el sistema
DESCRIPCIÓN
El sistema inhabilita el punto de control y todo lo relacionada en el sistema
ENTRADAS
RESULTADOS 1. Se inactiva el punto de control en el sistema.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de
eliminación de empresas.
POSTCONDICIONES 1. El sistema debe quedar listo para realizar cualquier actividad para el
usuario en sesión.
CURSO NORMAL DE LOS EVENTOS
1. Ingresar al listado de puntos de control registrados en el sistema.
2. El usuario selecciona el punto de control que desea inhabilitar.
3. El sistema muestra un mensaje de confirmación
4. El sistema inhabilita el punto de control y todo lo relacionado a ella en el sistema.
PUNTOS DE INTERRUPCIÓN
● En el punto (3) en caso de no confirmarse la eliminación el sistema sigue mostrando el listado de
usuario.
Fuente: autores.
99
Tabla 48: Registrar reporte punto de control
IDENTIFICACIÓN CASO DE USO ACTORES
CU_19 Registrar reporte punto de
control Administrador, Coordinador, Escolta.
OBJETIVO
Recolectar y almacenar evidencias en los puntos de control durante el viaje.
DESCRIPCIÓN
Durante el recorrido de un viaje el escolta tendrá que recolectar información en cada uno de los puntos por los
que se hayan determinado. Entre la evidencia que el escolta debe capturar se encuentran: fotografia, breve
descripción del viaje.
ENTRADAS
1. Evidencia fotográfica.
2. Observaciones punto de control.
3. Fecha y hora.
4. Longitud y latitud.
RESULTADOS 1. El sistema registra las evidencias de cada punto de control.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de registro
de punto de control.
POSTCONDICIONES 1. El sistema luego de registrar las evidencias vuelve a mostrar el mapa
de viaje.
CURSO NORMAL DE LOS EVENTOS
1. El sistema muestra una notificación en el momento donde se llegue a un punto de control.
2. El usuario abre la notificación.
3. El sistema muestra un formulario con los campos necesarios (ver entradas).
4. El usuario diligencia el formulario con las respectivas evidencias.
5. El sistema almacena la información y las evidencias fotográficas.
PUNTOS DE INTERRUPCIÓN
● El usuario puede no llenar la información y esto generara un registro respectivo cuando se salga de la
valla geográfica.
● El dispositivo puede no tener cobertura y no realizarse el proceso.
Fuente: autores.
100
Tabla 49: Consultar reportes puntos de control
IDENTIFICACIÓN CASO DE USO ACTORES
CU_20 Consultar Reportes puntos
de control Administrador, Coordinador.
OBJETIVO
Generar reportes a partir de las evidencias obtenidas en los puntos de control.
DESCRIPCIÓN
El sistema mostrará un filtro donde se podrán generar reportes detallados con evidencias de los viajes
realizados.
ENTRADAS
1. Fecha del viaje
2. Escolta.
3. Empresa.
RESULTADOS
El sistema debe mostrar los registros de viaje, según los filtros
seleccionados y la opción de generar un archivo pdf con toda la
información
El informe debe contener:
● Fecha de viaje
● Origen Destino
● Nombre de la empresa
● Nombre conductor
● Informe de trazabilidad: Fotografías de cada uno de los puntos de
control.
PRECONDICIONES
1. El usuario administrador, coordinador debe estar registrado en el
sistema.
2. El usuario debe tener los permisos para realizar el proceso de registro
de generar informe punto de control.
POSTCONDICIONES 1. Luego de generar el informe el sistema debe quedar listo para generar
otro informe.
CURSO NORMAL DE LOS EVENTOS
1. El usuario ingresa a la opción de reportes puntos de control.
2. El sistema muestra una serie de campos (ver Entradas).
3. El usuario selecciona los filtros.
4. El sistema muestra los viajes que cumplen con los filtros seleccionados.
5. El usuario selecciona que reporte generar.
PUNTOS DE INTERRUPCIÓN
● El usuario puede salir en cualquier momento y si no ha guardado los datos el formulario se reiniciará.
Fuente: autores.