DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA...

100
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

Transcript of DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA...

Page 1: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 2: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 3: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 4: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 5: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 6: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

6

7 CONCLUSIONES 75

8 BIBLIOGRAFÍA 76

Page 7: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 8: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 9: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 10: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 11: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 12: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 13: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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?

Page 14: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 15: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 16: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 17: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 18: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 19: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 20: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 21: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 22: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 23: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 24: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 25: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 26: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 27: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 28: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 29: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 30: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 31: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 32: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 33: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 34: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 35: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 36: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 37: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 38: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 39: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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 ..

Page 40: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 41: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 42: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 43: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 44: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 45: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 46: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 47: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 48: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 49: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 50: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 51: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

51

Ilustración 16: Servicios de Cargos

Fuente: autores.

Page 52: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 53: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 54: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 55: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 56: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 57: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 58: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 59: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 60: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 61: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

61

Ilustración 12: Punto de control asignado a un viaje

Fuente: autores.

Page 62: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

62

Ilustración 13: Asignación de puntos de control

Fuente: autores.

Page 63: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 64: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

64

Ilustración 15: Resumen de puntos de control asignados

Fuente: autores.

Page 65: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 66: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 67: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓ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.

Page 68: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

68

Ilustración 18: Seguimiento del recorrido de la ruta 2

Fuente: autores.

Page 69: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 70: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 71: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 72: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 73: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 74: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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

Page 75: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 76: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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].

Page 77: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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].

Page 78: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

78

ANEXOS

Page 79: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

79

ANEXO 1: DISEÑO DE ARQUITECTURA DE VIRTUALIZACIÓN.

Ilustración 33: Diseño de arquitectura de virtualización

Fuente: autores.

Page 80: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

80

ANEXO 2: CRONOGRAMA.

Ilustración 34: Cronograma

Fuente: autores.

Page 81: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 82: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 83: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 84: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 85: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 86: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 87: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 88: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 89: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 90: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 91: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 92: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 93: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 94: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 95: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 96: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 97: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 98: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 99: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.

Page 100: DESARROLLO DE UN SISTEMA BASADO EN ARQUITECTURA DErepository.udistrital.edu.co/bitstream/11349/14208/7/RoblesFajardo... · introducciÓn 11 1 planteamiento del problema 12 1.1 descripciÓn

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.