Construcción e implementación del componente sistema de gestión de parqueaderos, perteneciente al sistema de gestión administrativa del dominio de aplicaciones de la Universidad Distrital Francisco José de Caldas

(1)

CONSTRUCCIÓN E IMPLEMENTACIÓN DEL

COMPONENTE SISTEMA DE GESTIÓN DE PARQUEADEROS, PERTENECIENTE AL SISTEMA DE GESTIÓN ADMINISTRATIVA DEL DOMINIO DE APLICACIONES DE LA

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

JORGE ULISES USECHE CUELLAR 20091005082

OMAR LEONARDO ZAMBRANO PULGARÍN 20091005096

TRABAJO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO ELECTRÓNICO

DIRIGIDO POR:

CARLOS ENRIQUE MONTENEGRO MARÍN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA

(2)

ECOSIIS

SISTEMA DE GESTIÓN ADMINISTRATIVA

SISTEMA PARQUEADEROS

Sistema de Información de Gestión de

Parqueaderos

Equipo de Trabajo

Jorge Ulises Useche Cuellar - Pasante Oficina Asesora de Sistemas Omar Leonardo Zambrano Pulgarín - Pasante Oficina Asesora de Sistemas

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS Oficina Asesora de Sistemas

(3)

Índice

SISTEMA PARQUEADEROS 1. INTRODUCCIÓN

2. DESCRIPCIÓN DEL PROYECTO 2.1. Planteamiento del problema 2.2. Objetivos

2.2.1. Objetivo General 2.2.2. Objetivos Específicos

2.3. Definición de la solución propuesta 2.4. Descripción de los interesados 2.5. Limitaciones

3. RESULTADOS OBTENIDOS

3.1. Modelo de base de datos para indicadores de optimización del recurso espacial 3.2. Épicas e historias de usuario

3.3. Normalización de protocolos

3.4. Arquitectura general de la implementación 3.5. Aplicación web

3.6. Dispositivos de hardware 3.7. Indicadores

4. ANÁLISIS DE LOS RESULTADOS 4.1. Beneficios obtenidos

5. ALCANCE E IMPACTO DEL SISTEMA DE PARQUEADEROS 6. CONCLUSIONES

(4)

1. INTRODUCCIÓN

A través del proyecto se dio una solución al problema de organización de los parqueaderos de la Facultad de Ingeniería administrados por la División de Recursos Físicos de Universidad Distrital Francisco José de Caldas, donde su primera implementación abarca el sótano uno. Se desarrolló un sistema de control, seguimiento y gestión para el mejoramiento de las condiciones prestadas, basado en una metodología de sistematización y automatización de procesos en donde se integra un aplicativo a un sistema físico con el cual es posible obtener ciertas métricas fundamentales para el caso de estudio y con las mismas el sistema y los administradores tome decisiones claves.

El sistema consta de una base de datos que está conectada con la base de datos de la Universidad Distrital donde se indican los propietarios de vehículos que ingresan, permitiendo así su acceso, ya que, a los parqueaderos de la universidad no pueden ingresar

El aplicativo tiene dos tipos de entornos: usuario y administrador, el administrador, debe tener un registro previo donde se le asignará un usuario y contraseña que le dará acceso a un espacio donde podrá insertar, leer, eliminar o actualizar islas de parqueo y de esta manera modificar los cupos disponibles de su dominio métrico. El sistema ofrece un sitio web al usuario que le permitirá ver los espacios disponibles de los parqueaderos registrados previamente, el modelo de espacio se realizó mediante islas que se pueden agrupar en forma de pisos, bahías o según el administrador lo requiera.

El sistema obtenido, se desarrolló bajo licencia de software libre y se publicó con la licencia GNU AGPL (FSF, 2009) lo cual incentiva el uso y desarrollo de la aplicación por cualquier persona del mundo, de esta manera se podrán recibir mejoras al software o adaptación a las necesidades de los interesados, resultando así en un aporte para muchas organizaciones que posean el mismo problema. Cabe destacar que la implementación de tecnologías de “Software Libre” es más apropiada debido a su ideología y a que carece de la compra de licencias de uso, pudiendo adaptar estas al modelo de parqueaderos de la universidad.

(5)

Este proyecto inicialmente estaba planteado con varias tecnologías y metodologías que fueron cambiadas durante el desarrollo del proyecto debido al enfoque dado por el nuevo Jefe de la Oficina Asesora de Sistemas (OAS), se destaca como algo demasiado importante el cambio de la metodología de OpenUP OAS (OAS, 2015) a Scrum OAS (OAS, 2016), básicamente este último es una implementación en español de los documentos de Scrum Alliance (Scrum Alliance, 2014). Sin intentar explicar a profundidad, las principales características de esta es como se reconocen a los miembros del grupo como “The Scrum Team” y a los roles de estos como “The Product Owner”, “The Development Team” y “The Scrum Master”, estos términos van a ser utilizados en el desarrollo del escrito y sus tareas se encuentran bien definidas en las declaraciones de la metodología.

2. DESCRIPCIÓN DEL PROYECTO

La Universidad Distrital le ofrece a sus trabajadores y estudiantes, un espacio donde puedan estacionar sus vehículos mientras desarrollan sus respectivas actividades dentro de la universidad. La relación de vehículos frente al espacio ofrecido es mayor, por lo cual, se hace necesario optimizar el espacio y controlar el flujo de vehículos que hay en el mismo.

El propósito de este documento es analizar y presentar los resultados obtenidos del software y hardware para gestionar el uso de los parqueaderos de la Universidad Distrital Francisco José de Caldas.

El proyecto abarca para su desarrollo un conocimiento multidisciplinar y un manejo adecuado de herramientas de software y hardware para dejar el producto en un buen estado de desarrollo que permita escalamiento. El grupo de desarrollo debe poseer conocimientos en desarrollo e integración de hardware, desarrollo e integración de software especialmente web y conocimientos básicos de componente geográfico dentro del software. El proyecto se desarrolla entonces teniendo como “Development Team” a los pasantes de parqueo hoy en día, generando así problemas de hacinamientos, desorden ocupacional, caos vehicular, invasión de zonas prohibidas e inseguridad.

(6)

Actualmente, el personal de guardas de seguridad, es el encargado de realizar las tareas de asignación, ordenamiento y seguridad del parqueadero en el cual la habilidad humana es la que determina la eficiencia del parqueadero, limitando el eficaz funcionamiento del establecimiento, en donde además se discrimina a usuarios de otros medios de transporte (bicicletas), los cuales deben alojarse en una zona a la intemperie donde carecen de una buena prestación de la seguridad y el orden.

Dicho lo anterior, la problemática está dada en la falta de automatización del proceso de la utilización de las zonas de parqueo por los diferentes usuarios, además cada uno de sus propietarios establece un sistema de control para atender los servicios prestados generando una diversidad en los procesos que no posibilitan la estandarización de protocolos referentes al uso óptimo del espacio en parqueaderos, además, de fomentar el desorden en estas zonas.

2.2. Objetivos

2.2.1. Objetivo General

● Construir e implementar el componente sistema de gestión de parqueaderos, perteneciente al sistema de gestión administrativa del dominio de aplicaciones de la a través de algún mecanismo que garantice su identidad.

● Realizar un trabajo de normalización de protocolos y seguridad para el registro y control de acceso de vehículos para que su implementación pueda ser progresiva en las sedes de la universidad.

● Generar un modelo de parqueadero en un sistema informático que permita la optimización del recurso espacial.

2.3. Definición de la solución propuesta

Para Funcionarios, Docentes, Contratistas y Estudiantes.

(7)

gestión de

parqueaderos de la Universidad

sistemática y centralizada las islas de parqueadero de la Universidad Distrital Francisco José de Caldas. Además permite hacerle seguimiento a todos los procesos asociados al mal uso del bien espacial y de los servicios ofrecidos para el parqueadero a la comunidad universitaria.

Que El sistema de gestión PARQUEADEROS administra entradas y salidas de vehículos al parqueadero, mantiene un inventario en tiempo real de las islas de parqueo, hace seguimiento a los horarios en que debería utilizarse el servicio por todos los usuarios y registra las incidencias de uso inadecuado del recurso brindado.

A diferencia de La administración manual de los espacios, con la asignación de personal que recorra la planta física para determinar visualmente qué disponibilidad de parqueaderos hay en un determinado momento. brindar un mejor servicio a los usuarios de la Universidad Distrital.

2.4. Descripción de los interesados

Nombre Responsabilidades en el proceso

División de Recursos Físicos

● Registrar propietarios, revisar aptitud de propietarios. ● Registrar y revisar frecuentemente estado de incidencias. ● Vigilar activos del proyecto.

● Ayudar a la construcción y legitimación de políticas de uso de parqueadero.

● Controlar y gestionar recursos para la compra de elementos según necesidades del mantenimiento y escalamiento del proyecto.

Oficina Asesora de Planeación y Control

● Rendir información veraz de la distribución espacial de los parqueaderos.

● Ayudar a la construcción y legitimación de políticas de uso de parqueadero.

PIGA, Plan Institucional de

(8)

Gestión Ambiental uso de medios alternativos, en especial para parqueaderos es incentivar el uso de bicicleta en los miembros de la comunidad universitaria.

2.5. Limitaciones

El proyecto tiene un sistema informático y teleinformático que permite la gestión de parqueaderos. No se amplía en sensado de variables o en cuestiones mecánicas de cómo transportar físicamente los vehículos de un lado a otro. El análisis del sistema está más enfocado a modelar los parqueaderos actuales, con las necesidades no suplidas y generar indicadores que en el futuro ayudarán a la adquisición de equipos como los elevadores u otras implementaciones para vehículos diferentes a los automotores, por ejemplo, incentivar el uso de bicicleta con una mayor cobertura.

El sistema realizado no cuenta con módulos de reportes, estadísticas analísticas o descriptivas, pero sin duda alguna la arquitectura propuesta permite que dichos módulos puedan ser integrados de conformidad con los recursos asignados por la Universidad para la ampliación de su desarrollo.

Nuevos algoritmos pueden ser creados para analizar datos de las islas y mejorar la asignación buscando aplicar el concepto de optimización con continua mejora del proceso.

La aplicación realizada está más enfocada a la gestión de carros que de otro tipo de vehículos, debido a que los alcances iniciales del proyecto están dedicados a estos principalmente, sin embargo se analizaron muchos escenarios en donde la arquitectura está abierta para que el estacionamiento de los demás vehículos se genere sin contratiempos.

3. RESULTADOS OBTENIDOS

3.1. Modelo de base de datos para indicadores de optimización del recurso espacial

Después de un arduo trabajo y muchos controles de cambios, se obtuvo un modelo de base de datos descrito en la Fig. 3.1.1. De esta se tiene que el propietario es de varios tipos y un propietario puede tener muchos vehículos, los vehículos se registran en el sistema en el tiempo en que ingresan o salen del parqueadero, a cada vehículo en el registro de entrada se le asigna una isla que es la que debe ocupar y esta isla pertenece a un grupo isla, como puede ser el sótano 1, 2 o 3 de la facultad o cualquier otro que haya en la universidad.

(9)

Fig. 3.1.1. Modelo de base de datos de la aplicación

Esta abstracción del modelo de negocios fue concertada con los Administradores de Base de Datos de cóndor y con los Business Owner que son los administrativos de la División de Recursos Físicos de la universidad. Este modelo busca ser incremental en cuanto el propietario se puede reemplazar fácilmente por la entidad de usuario del sistema ECOSIIS. Esta tabla propietario se convertiría entonces en una tabla de parámetros del propietario que están asociados directamente al modelo de negocios del parqueadero.

Posee una tabla llamada “migrations”, lo cual permite desplegar los últimos cambios mediante una técnica que tienen muchos frameworks de desarrollo de software que se llama “migraciones” con la cual se actualiza los atributos de una tabla, de un esquema o de una base de datos, mediante SQL versionado.

3.2. Épicas e historias de usuario

La metodología usada contempla una disciplina de levantamiento de requerimientos basada en historias de usuario. Las historias usuario que tienen en tiempo de desarrollo muchísimas subtareas, en la que se puede dividir se conocen como épicas. A estas divisiones de las épicas se conocen simplemente como “User Stories” o historias de usuario.

(10)

Épica Número: 1 Usuario: División de Recursos Físicos

Nombreépica: Aplicación web para gestionar parqueaderos de la universidad

Prioridaden negocio:

Alta Riesgo en desarrolloBaja :

Puntos estimados: 1000 Iteración asignada:

Programador responsable: Jorge Useche y Leonardo Zambrano

Descripción:

Realizar un software que permita gestionar los parqueaderos de la universidad, manejando propietarios, vehículos, incidencias e islas de parqueo.

Observaciones:

Nombrehistoria: Visor web geográfico de Islas en Tiempo Real

Descripción:

Realizar un aplicativo web que permita ver las islas de parqueo en tiempo real de tal manera que se pueda consumir desde dispositivos y así se vea la disponibilidad de islas sobre el mapa.

(11)

Número: 3 Usuario: División de Recursos Físicos

Nombrehistoria: Dispositivos de Sensado de Ocupación de Islas

Descripción:

Realizar el prototipo de hardware necesario para sensar la ocupación de las islas de carros, conectarlos de alguna manera con internet para que se guarde el registro en base de datos.

Observaciones:

Nombrehistoria: Dispositivos de Acceso NFC

Descripción:

Realizar el prototipo de hardware necesario leer y enviar datos al servidor para verificar la autorización del acceso a los parqueaderos. Este debe controlar el acceso de

motocicletas, carros y bicicletas.

Observaciones:

(12)

Un diagrama que ilustra el comportamiento de los roles en la metodología scrum se muestra en la Fig. 3.2.1. los “Stake Holders” en este caso son los mostrados en la sección 2.4.

Fig. 3.2.1. Relación entre los roles de un proyecto con metodología scrum. (Swaraj Gupta, 2004)

Las historias de usuario escritas y realizadas son las siguientes:

Historia de Usuario Número: 1 Usuario: Scrum Master

Nombrehistoria: Definición de directrices para la administración de parqueaderos.

Programador responsable: Jorge Useche

Descripción:

Se necesita un documento que simplifique las políticas de uso y pertenencia relacionadas con parqueaderos, con las cuales se pueda realizar de la mejor manera el modelado de la solución al problema. Incluye reuniones con las dependencias de, División de Recursos Físicos, la Oficina Asesora de Planeación y Control y PIGA (Plan Institucional de Gestión Ambiental)

(13)

Nombrehistoria: Desplegar las versiones realizadas para permitir visualizar al cliente

Descripción:

Realizar versiones por nuevas características del software y desplegarlas en el servidor de pruebas para su revisión por parte de los stake holders.

Observaciones:

Nombrehistoria: Normalizar protocolos de acuerdo a las circulares y resoluciones relacionadas a los parqueaderos.

Descripción:

Realización de diagramas de flujo para la validación de usuario, ingreso de vehículo y salida del mismo. Esto de acuerdo a la Circular de división de recursos físicos del 16 de Agosto de 2016 (Recursos Físicos, 2016) y la Resolución de Rectoría No 206.

(14)

Nombre historia: Normalización de protocolos mediante diagramas BPMN para los procesos relacionados a parqueaderos

Se necesita normalizar los protocolos usados para:

● El ingreso del parqueadero para Carro, Moto y Bicicleta. ● La salida del parqueadero para Carro, Moto y Bicicleta.

● Revisión y registro de incidencias por parte del Administrador de Recursos Físicos.

Nombrehistoria: Documento propuesta con costos de implementación primer prototipo

Programador responsable: Leonardo Zambrano

Descripción:

Realizar documento propuesta con costos de implementación del primer prototipo de hardware para sensar ocupación de islas y autenticación por NFC. Debe ser por lo menos 10 dispositivos de sensado y el dispositivo de autenticación de entrada y salida de NFC.

Observaciones:

(15)

Historia de Usuario

Programador responsable: Leonardo Zambrano y Jorge Useche

Descripción:

Realización de modelo de bases de datos teniendo en cuenta la documentación disponible del proceso y las conclusiones del proyecto.

Observaciones:

El modelo debe poder ponerse en marcha mediante el motor de base de datos PostgreSQL, deben manejarse “migrations” migraciones para desplegar los cambios. Se debe usar PostGIS para los datos geográficos.

Nombrehistoria: CRUD Propietario

(16)

Nombrehistoria: CRUD Tipo Propietario

Prioridaden negocio: frontend, los permisos se deben dar por envío de Token por cookie.

Nombrehistoria: CRUD Incidencia

(17)

Historia de Usuario frontend, los permisos se deben dar por envío de Token por cookie.

(18)

Historia de Usuario frontend, los permisos se deben dar por envío de Token por cookie.

Nombrehistoria: CRUD Registro entrada/salida

(19)

Nombrehistoria: CRUD Incidencias

Descripción:

Generar el módulo en la aplicación de parqueaderos, que permite Crear, Consultar, Actualizar y Eliminar incidencias.

Observaciones:

Se debe usar el Framework Beego para el Backend y el Framework AngularJS para el frontend, los permisos se deben dar por envío de Token por cookie.

Nombrehistoria: Presentación de avances proyecto

Descripción:

Se requiere hacer presentaciones periódicas de los avances del proyecto para conseguir los recursos necesarios para el desarrollo del mismo.

(20)

Nombrehistoria: Cartografía base - mapa temático

Media Riesgo en desarrolloBaja :

Descripción:

Realizar cartografía base de parqueaderos para cada sótano de los parqueaderos de la facultad de ingeniería y publicarla como una capa raster “tiled” en geoserver.

Observaciones:

Nombrehistoria: Servicios web OGC de entidades geográficas del proyecto

Descripción:

Realizar servicios web en el estándar OGC (en WFS y WMS) de las entidades geográficas isla y grupo_isla.

(21)

Nombrehistoria: Visor geográfico para visualizar Isla y Grupo Isla

Descripción:

Realizar visor geográfico para visualizar Isla y Grupo Isla.

Observaciones:

Se debe realizar una selección de la mejor herramienta, para el caso se escogió Openlayers 3.0.

Nombrehistoria: Diseño arquitectónico a base de datos

Descripción:

Transformar información DWG (Diseño arquitectónico 2D CAD) a base de datos PostgreSQL (Digitalizar). Para ser consumido por el visor web y la aplicación web.

Observaciones:

(22)

Nombrehistoria: Métodos de localización inalámbrica.

Descripción:

Realizar documento con los métodos métodos de localización inalámbrica (tracking) para parqueaderos. Esto con el fin de ofrecer la propuesta con el banco de posibilidades de comunicaciones.

Observaciones:

Realizar una descripción vistosa para vender la idea a administrativos que puedan dar recursos para la realización del proyecto.

Nombrehistoria: Sistema de autenticación de usuarios al sistema

Prioridaden negocio: realizar actividades de Creación, Actualización y Eliminación sólo para los usuarios que tengan permisos.

(23)

Nombrehistoria: Documento didáctico para conseguir recursos con Stake Holders

Descripción:

Se necesitan diagramas pictóricos como parte de la documentación de los dispositivos y para ilustrar a administrativos el uso de componentes y así pedir específicamente recursos para eso. diagramas hacen parte de la presentación con stake holders.

Observaciones:

Usar software libre para hacer los diagramas.

Nombrehistoria: Propuesta de investigación con costes del prototipo dos

Descripción:

Propuesta de investigación con costes de dispositivos de desarrollo para 10 nodos con el segundo modelo del prototipo.

(24)

Nombrehistoria:

Descripción:

Se necesita un diagrama de diagrama de despliegue para documentar el proceso de conexión de hardware y software para próximas implementaciones.

Observaciones:

Nombrehistoria: Dispositivo de sensado de Ocupación de la Isla

Descripción:

Realizar el diseño y pruebas para implementar un dispositivo de bajo consumo y alimentado con baterías que permita sensar y enviar el dato de Ocupación de la isla.

Observaciones:

(25)

Nombrehistoria: Dispositivo de acceso por NFC

Descripción:

Realizar el diseño y montaje de un dispositivo que permita identificar al usuario por medio de un tag NFC con el cual se sabrá si tiene o no acceso o salida de un vehículo.

Observaciones:

Nombrehistoria: Dispositivo de gestión de Sensores de Isla

Descripción:

Realizar el diseño, montaje e implementación de un dispositivo que permita gestionar los mensajes de los Sensores de Isla y los envíe por internet a un servidor. Esta conexión debe ser cifrada mediante un algoritmo criptográfico.

Observaciones:

(26)

Nombrehistoria: Actualización en tiempo Real Visor Web Geográfico.

Descripción:

Se necesita implementar la actualización del visor web geográfico en tiempo real, actualizando el estado de las islas de parqueo. Al generarse un evento en el hardware, este debe representarse en el visor web instantáneamente.

Observaciones:

Para esto se debe considerar las opciones de long polling, server-send event y websocket.

Nombrehistoria: Comunicación cifrada entre Nodo Central y Servicio SSE

(27)

Nombrehistoria: Diagramas de conexión Sensor Isla y Nodo Central.

Descripción:

Se necesitan los diagramas de conexión eléctrica del sensor de la isla y el nodo central, estos deben ser publicados con licencia libre de acuerdo a los criterios del Hardware Libre u Open Hardware.

Observaciones:

3.3. Normalización de protocolos

La normalización de protocolos tiene como intención dejar de manera clara la forma en cómo deben realizarse los procesos, bien sea por la normativa actual o el correcto proceder de las actividades. Esto permite generar un desarrollo del proyecto más claro y sentar precedente para que se formen nuevas políticas que normalicen el uso del servicio de parqueo.

Una forma clave que se encontró viable para realizar este proceso fue la diagramación a través de BPMN (OMG, 2011); la cual estructura de forma simple y clara los procesos, ya que cada símbolo representa una idea adicional al diagrama mostrado.

(28)

Fig. 3.3.1. Diagrama de proceso ingreso de vehículo. En este hay un reconocimiento implícito por parte del actor “Propietario” del vehículo que está llevando a la universidad. Dependiendo del tipo de vehículo ingresado, se ejecutan los subprocesos Ingreso bicicleta,

moto o carro.

Fig. 3.3.2. Diagrama de proceso ingreso de carro. En este caso el actor es el propietario del carro que debe posarse frente a la talanquera y realizar el procedimiento propuesto. Se tiene como características las consultas implícitas a los datos del usuario para permitir que ingrese el vehículo o por el contrario que deniegue el acceso, teniendo este que abandonar la zona de entrada. Si por el contrario puede ingresar, se imprime un ticket con la hora de

(29)

Fig. 3.3.3. Diagrama de proceso ingreso de moto. Este es similar al de carro, a excepción que en el caso de estar autorizado para ingresar, el ticket no imprime una isla, ya que este

espacio de motocicletas se controla por cantidad de motos y no por islas ocupadas.

Fig. 3.3.4. Diagrama de proceso ingreso de bicicletas. Este presenta las tareas paralelas de sensar el tag NFC de la bicicleta y del carné con tag NFC al tiempo, lo cual dará como resultado que el usuario esté habilitado o no para sacar el vehículo, si es denegado se interpreta como una situación irregular que debe ser analizada por el personal de vigilancia

(30)

Fig. 3.3.5. Diagrama de proceso salida de vehículo. Se muestra algo similar a la Fig. 3.3.1. de acuerdo al tipo de vehículo, el propietario se dirige a una u otra zona en la cual se realiza

el sub-proceso correspondiente.

Fig. 3.3.6. Diagrama de proceso salida de bicicleta. En este el usuario saca su bicicleta y la dispone a un celador que se encuentra en la salida del parqueadero y éste ayuda a movilizar la pistola con lector NFC y se verifica la coherencia entre el tag NFC en el carné y

el tag NFC pegado en la bicicleta. En caso de que los TAGs no concuerden/correspondan, el celador dispone del protocolo de seguridad interno para disponer de un evento que puede

(31)

Fig. 3.3.7. Diagrama de proceso salida de carro. El propietario simplemente necesita pasar su tag NFC en el lector de salida y la compuerta se abrirá si detecta que es la salida correspondiente a un vehículo que se encontraba dentro del parqueadero, de lo contrario deniega el acceso y se dispone como una alarma de intento situación extraña poniéndose a

disposición de la vigilancia del parqueadero.

Fig. 3.3.8. Diagrama de proceso salida de moto. Es igual al de la salida de automóvil, solo cambia la identificación que se da a nivel de los sensores de identidad de vehículo de

(32)

Fig. 3.3.9. Diagrama de proceso asignación de parqueadero. Este corresponde a los pasos que debe seguir un miembro de la comunidad universitaria para solicitar la inscripción en el sistema de parqueaderos, si no se realiza la solicitud, no podrá ingresar a los parqueaderos.

Fig. 3.3.10. Diagrama de proceso registro de incidencias. El administrador de recursos físicos registra las incidencias a quien se demuestre que ha incurrido en alguna. De lo

(33)

Fig. 3.3.11. Diagrama de proceso revisión de incidencias. Este flujo de actividades representa a la tarea que tiene que hacer el administrador de recursos físicos de revisar las

incidencias puntuales en busca de tener consideración con el usuario y permitirle seguir disfrutando del servicio de parqueaderos.

Complementando la tarea de llevar a cabo un proceso de normalización, se realiza proceso de entendimiento de los documentos de reglas oficiales relacionados con parqueaderos, que son la Circular de división de recursos físicos del 16 de Agosto de 2016 (Recursos Físicos, 2016) y la Resolución de Rectoría No 206 (Rectoría, 2010). Existen otros documentos con los cuales pudimos contar para el modelado del negocio, documentos internos de la División de Recursos Físicos que están sirviendo de base para sacar nuevos comunicados, circulares o resoluciones. Al no ser oficiales se trabajaron como ideas que debe tener en consideración el modelo, más no que deban ser desarrolladas en su totalidad, ya que no existen normativas que las soporten.

Se hace un resumen para revisar esas características o particularidades del sistema de parqueaderos de la Universidad Distrital en la Tabla 3.3.1.

Tabla 3.3.1. Características del sistema de parqueaderos según normativa actual.

Característica Valor

Usuarios que pueden acceder al servicio

de parqueaderos. ● Docente: de planta u hora cátedra. ● Administrativos: personal que contrata por nómina la universidad. ● Estudiantes: Estudiantes activos de

la universidad.

(34)

Tipos de vehículo que pueden usar el parqueadero. (El vehículo debe estar registrado al nombre del usuario, menos bicicletas).

al parqueadero. El carné debe estar actualizado, no tenerlocausa denegación del servicio. El vehículo debe estar registrado en el

sistema. Para acceder al servicio el sistema debetener los datos de identificación, características y tarjeta de propiedad (a nombre de usuario propietario).

Causa de denegación del servicio. ● Desacato a vigilantes, división de recursos físicos o decanaturas de

(35)

Fig. 3.3.12. Diagrama de flujo del ingreso de vehículos. El símbolo “?” se da porque aún no existe normativa o ideas de qué debería hacer el sistema y no se consiguió que fuera

(36)

Fig. 3.3.13. Diagrama de flujo de la salida de vehículos.

(37)

La Fig. 3.4.1 muestra en bloques los componentes de hardware y software que se usan en el proyecto, se tiene un servidor de mapas llamado Geoserver que consume tablas con componente geográfico de PostgreSQL/PostGIS, Geoserver se conecta con Apache haciendo un proxy pass para que el PC cliente acceda a ese servicio a través del servidor web Apache. En el servidor web también se aloja el backend de la aplicación que es un servicio RESTFul con JWT que también se conecta a la aplicación por medio de un proxy pass. El SSE Go es un servicio web (Server-Send Event) dedicado a avisar al visor de islas de parqueo, de manera que al ocurrir cambios en las islas de parqueo (detectados por el hardware), automáticamente se muestre el cambio en el mapa. Este SSE Go se conecta a la capa de backend para registrar los cambios en la base de datos. A este servidor SSE se conecta el nodo central (componente de hardware) que tiene abstraídas todas las peticiones de los sensores de las islas, con lo cual solo envía los cambios ocurridos y no todo lo que sensan o captan los sensores de la isla. El Nodo central y los sensores de isla se conectan a través de transceptores en la banda de 2.4 GHz, haciendo que su capacidad de penetración sea mayor.

Por último se tiene los componentes que funcionan del lado de cliente y son descargados como archivos estáticos del servidor. Esta aplicación funciona en dos partes, el sitio de administración y el visor geográfico, el primero tiene como componentes AngularJS con varios sub-módulos de éste, tiene Twitter Bootstrap para la maquetación de la información y Jquery-Ui para componentes javascript avanzados. El visor geográfico tiene Materialize CSS para la maquetación de la información y OpenLayers para el renderizado de la información geográfica.

(38)

3.5. Aplicación web

El aplicativo web se compone principalmente de 2 partes, una página de administración que permite visualizar el contenido de todas las entidades creadas en el modelo de base de datos y una de acceso público donde se pueden visualizar las zonas de parqueo en tiempo real.

El tipo de aplicación usada se basa en el concepto de SPA (Single Page App) en el cual se cargan archivos estáticos durante la primera carga y de ahí se cargan recursos asincrónicamente buscando que el DOM (Document Object Model) obtenga esa información y la transforme en algo visible para el usuario. En la carga tradicional, el cambio de información que pedía el usuario, necesitaba recargar la página completamente y generando así una carga innecesaria de datos con el sitio web, ahora con SPA solo se trae la información por medio de formatos como JSON o XML y se grafica sin requerir más tráfico de datos por la red. En la Fig. 3.5.1. Se muestra un diagrama que nos muestra el ciclo de vida de un sitio tradicional en la que se trafica con mayor información de la necesaria al contrario de lo mostrado en la Fig. 3.5.2. en el cual carga solo lo estrictamente necesario.

(39)

Fig. 3.5.2. Ciclo de vida de SPA (Aplicación con página única). (Mike Wasson, 2013)

Fueron bastantes los componentes de software utilizados para el sitio de administración de parqueaderos y para el visor web, y fueron diversas las razones que hicieron que esa tecnología fuera escogida por sobre las demás, puede verse en la Tabla 3.5.1. todas las herramientas usadas y las características que hicieron de ella la más viable.

Tabla 3.5.1. Software y las características por las que se escogieron para el desarrollo del proyecto.

Nombre

Componente Funcionalidad Razón de Uso

Apache Servidor Web El servidor web más usado y más popular desde 1996 (The Apache Software Foundation, 2016). Resultar ser bastante depurado y ser muy confiable. En este proyecto se usa para servir archivos estáticos y para hacer proxy pass (o reverse) con otros servicios, por tanto un servidor bastante documentando facilita la implementación de este componente. Es software libre con licencia Apache.

PostgreSQL Motor de base

(40)

Geoserver Servidor de abiertos. Tiene una buena documentación para su integración con PostgreSQL+PostGIS. Es software lenguajes como PHP o NodeJS, ganando por mucho en velocidad de ejecución de un algoritmo. (Jonathan Warner, 2013). Además es desarrollado por Google, lo que hace que se obtenga un gran futuro y tareas de desarrollo como la creación del servicio RESTful a partir de la tabla en la base de datos

(41)

para construir herramienta de desarrollo. Es software libre bajo la licencia MIT.

El maquetador más usado con AngularJS y por tanto con más ejemplos en la web. Es posible conectarlo documentada y tiene muchísimos ejemplos. Se escogió porque permite una conexión con la mayoría de servicios web estándares establecidos por la OGC, característica que no tienen otras alternativas libres como leaflet. mapas ya que contiene estilos agradables al usuario.

(42)

Fig. 3.5.3. Pantalla de bienvenida del Sistema de Gestión de Parqueaderos.

(43)

Fig. 3.5.5. CRUD entidad Propietarios.

(44)

Fig. 3.5.7. CRUD entidad Grupo Islas.

(45)

Fig. 3.5.9. CRUD entidad Registros Entrada/Salida.

(46)

Fig. 3.5.11. CRUD entidad Vehículo, vista Crear o editar Vehículo.

(47)

Fig. 3.5.13. Vista ampliada del área de parqueo del sótano 1, del visor web geográfico de Parqueaderos de la Universidad Distrital.

Fig. 3.5.14. Muestra de la tabla de contenidos del mapa, en visor web geográfico de Parqueaderos de la Universidad Distrital.

(48)

como se ve en la Fig. 3.4.15 y una frecuencia diaria 24/7 de trabajo como se ve en la Fig. 3.4.16.

Fig. 3.5.15. Lista de commits realizados por los pasantes.

Fig. 3.5.16. Esfuerzo semanal promedio, situado en las horas del día en que se realizan más commits.

3.6. Dispositivos de hardware

(49)

características se le denomina hardware libre (Richard M. Stallman, 2015) y este proyecto hace públicos estos diseños y su software bajo licencia GPL.

Durante el desarrollo del proyecto se encontraron muchísimas alternativas, se comenzaron con pruebas de laboratorio de las más populares y a medida de que se obtenía la funcionalidad con dicha tecnología se iba pasando a otra con el ánimo de obtener mejores resultados en cuanto al consumo de potencia, precio, tiempo de desarrollo u otros criterios que hicieran más viable la implementación en otros lugares.

En la Tabla 3.6.1. se dan los dispositivos de hardware que se escogieron para realizar el desarrollo de los requerimientos. Estos elementos base son los que conforman el nodo central, el sensor de isla, el lector NFC de entrada, el lector NFC de salida, el lector NFC manual y el lector NFC de tablero. (Ver Fig 3.3.1 a 3.3.11).

Es necesario establecer ciertos conceptos teóricos, con los cuales se determinó cuál debería ser la tecnología a usar:

● Espectro Electromagnético: Es toda la distribución energética de las ondas electromagnéticas, desde las de más cortas longitudes de onda (rayos gamma) hasta las más largas longitudes de onda (radio). (Annamalai M., Hemantha J., 1997) ● Radiofrecuencia: Es el rango del espectro electromagnético utilizado para las radiocomunicaciones, la radioastronomía, el radar, la resonancia magnética nuclear,entre otras. Tal rango de ondas es el menos energético del espectro y está comprendido entre 3 KHz a 300 GHz. (Annamalai M., Hemantha J., 1997)

● Ondas Ultrasónicas: Ondas mecánicas que tienen una frecuencia superior a las ondas auditivas por el ser humano, son ampliamente utilizadas en sensores de proximidad ya que no sufren de roces mecánicos. Están ondas a diferencia de las electromagnéticas necesitan de un medio de propagación como lo es el aire. Algunos animales como el murciélago utilizan ondas de ultrasonido producidas por ellos mismos para localizar su comida, a través del efecto de reflexión y la detección dispositivos activos (generan la señal de radiofrecuencia) y pasivos (son excitados por la señal de radiofrecuencia de un dispositivo activo y generan una respuesta) o dispositivos mixtos (capaces de generar una señal y de detectar otra señal de radiofrecuencia). También se puede clasificar los dispositivos mediante sus transacciones ya sean de solo lectura, escritura y lectura-escritura. (Want, R., 2006) ● NFC: Comunicación de Campo Cercano es una aplicación del RFID, que está

(50)

de información, por el contrario, su objetivo es información básica que desencadene un procesamiento en dispositivos con mayores prestaciones. (Want, R., 2006) ● Microcontrolador: Es un circuito integrado que es programable, lo cual lo hace capaz

de ejecutar instrucciones que se almacenen en su memoria ROM. Este integrado posee varios bloques funcionales que tienen una función específica, así en conjunto estos bloques generan una computadora compuesta por la Unidad Lógica Aritmética (ALU), la memoria y los periféricos de entrada/salida.

● Lineas de Transmisión: Es cierto material que con cierta geometría uniforme en toda su estructura, es capaz de transportar eficientemente la energía de radiofrecuencia (ondas de radiofrecuencia) desde un punto a otro. Una de las características más importantes en la definición del comportamiento de la línea es su impedancia característica. Se tienen líneas de transmisión unifilar (coaxial), bifilar (par trenzado), fibra óptica, el aire, entre otros.

● Ethernet: Es un protocolo de capa de enlace, para redes de área local (LAN) que utilizan las computadoras para el acceso al medio utilizando la detección de portadora y detección de colisiones (CSMA/CD). Este protocolo utiliza el direccionamiento físico (MAC) para la transmisión de la información, este protocolo formatea los datos proveniente de la capa de red a través de tramas, además,

Tabla 3.6.1. Hardware y las características por las que se escogieron para el desarrollo del proyecto.

Nombre

Componente Funcionalidad Razón de Uso

Arduino Mega Nodo Central El arduino Mega es una placa de desarrollo para el microcontrolador ATMega1280, diseñado por la Open Source Products for Electronics Projects Arduino, esta placa de desarrollo tiene mayores prestaciones, como lo son más puertos de entrada, mayor capacidad de almacenamiento, por lo cual será el nodo central al cual se comunicarán los detectores de presencia. Lector NFC

para Arduino Mecanismos de control de

acceso al

parqueadero

El mecanismo de comprobación de identificación de un usuario al parqueadero se escogió, a través de RFID puntualmente NFC y su característica de transacciones a corta distancia que permiten un mayor grado de seguridad. Por esto, es necesario un dispositivo para la lectura de las etiquetas NFC de los usuarios.

(51)

este dispositivo no tiene mayores prestaciones no se

El sistema planteado, para la determinación del estado de las islas del parqueadero, se pensó como un sistema similar a un panal de abejas, en donde existen varios nodos centrales distribuidos a cierta distancia y encargados del monitoreo de un área a través de los detectores de presencia; por lo cual, estos nodos deben estar interconectados, tal interconectividad se estableció bajo una red de área local cableada LAN Ethernet, para esto es necesario integrar el módulo de Ethernet a Arduino.

Emisor /

Los dispositivos encargados de la detección de ocupación de las islas, deben comunicarse inalámbricamente a su nodo central, por razones espaciales, así que, tales detectores se comunican con los nodos centrales a través de radiofrecuencia a un vehículo posicionado sobre una isla en particular, tal información, se la entrega al microcontrolador.

Baterías

Recargables Servidorenvío dede eventos

Como hay dispositivos ubicados en posiciones que físicamente están impedidos de conexión a la eléctrica y cumplen un papel de ser dispositivos perifericos inalambricos, es necesario proveerles de alguna fuente de energía, por eso, la razón de usar baterias para cada uno de estos dispositivos.

(52)

Fig. 3.6.1. Diagrama pictórico de dispositivos de acceso NFC a la entrada y salida del parqueadero.

Fig. 3.6.2. Diagrama pictórico de detector de presencia enviando los datos por RF 2.4GHz y reenvío del estado por internet.

Los últimos dispositivos implementados se conoce como conjunto de prototipos N°3 el cual tiene la implementación de módulo “nRF24L01+PA+LNA SMA Antenna Wireless

Transceiver Communication Module 2.4g 1100m”, de por sí el nombre completo nos da las características y al ser un módulo comercial y económico, los costos de implementación y las características de comunicación mejoraron muchísimo. La implementación en

(53)

Fig. 3.6.3. Implementación del nodo central.

Otro de los productos es el sensor de ocupación de la isla, el cual tiene su versión en plataforma de desarrollo y en circuito para producción, estos se ven en la figura 3.6.4. El de la parte (a) incluso posee un diseño del contenedor que aloja el sensor en el piso de la isla, este se ve en la Fig. 3.6.7. De este también se publican libremente los diagramas PCB y de conexión eléctrica, estos se ven en la Fig. 3.6.5. y Fig. 3.6.6.

(54)

Fig. 3.6.5. Circuito PCB de sensor de ocupación de Isla

(55)

Fig. 3.6.7. Modelo 3D de contenedor de sensor de ocupación de isla en suelo.

3.7. Indicadores

(56)

Fig. 3.7.1. Diálogo de ocupación del espacio en parqueadero de acuerdo a vehículo.

4. ANÁLISIS DE LOS RESULTADOS

De lo observado en la implementación se tiene que la potencia requerida para enviar datos con una frecuencia alta, es mayor, estos son entonces directamente proporcionales.

A medida de que se varió la frecuencia de los dispositivos de transmisión también mejoró la capacidad de penetración, así que pasaba los obstáculos como paredes o vehículos con mayor facilidad, estos son entonces proporcionales.

La transmisión de datos por LAN por medio de la técnica SSE resultó bastante conveniente, se ve menos tráfico innecesario en la red al realizar las mediciones sobre el punto de salida de los sensores de isla. Este se comparó con respecto al método Ajax Polling, en el que se envía con una tasa de refresco (una petición separada equidistantemente en el tiempo) el estado así este no cambie.

(57)

Los resultados de consumo de corriente de un microcontrolador en estado de hibernación y en estado de loop para esperar los tiempos de sensado fueron de alrededor de 2 veces, el consumo en hibernación reducía la corriente a algo menos del 40% del total en modo pleno, debido a este resultado se realizan los tiempos muertos con el micro hibernado y no con bucles en la línea de ejecución (stack) del microcontrolador.

4.1. Beneficios obtenidos

Los beneficios para la universidad aún no son tangibles, ya que el proceso de implementación actual es muy reducido como para atreverse a generar conclusiones apresuradas, no representa una cantidad significativa comparada con el número de islas de el parqueadero y en general de todas las sedes, lo que sí se logró fue realizar una arquitectura tan escalable como sea posible, tanto en precio como en tecnologías.

5. ALCANCE E IMPACTO DEL SISTEMA DE PARQUEADEROS

El sistema dará mejores tiempos de parqueo, indicadores para la mejora del servicio y un sistema para el registro y revisión de incidencias. La comunidad universitaria sentirá que se cumplen por primera vez las reglas del parqueadero y más personas podrán gozar del servicio aumentando el contento generalizado. través de del su estructura modular de los componentes.

(58)

adaptación de tales módulos a los requerimientos del proyecto, en donde se buscó la

La metodología de desarrollo ágil SCRUM permitió dedicar más tiempo al desarrollo del producto y gastar menos tiempo en el desarrollo de artefactos poco fructíferos para lograr un producto que realmente el usuario necesita.

Utilizando tecnologías libres se pudieron ahorrar recursos significativos de tal manera que casi sin financiación esta etapa del proyecto se dió por finalizada.

7. RECOMENDACIONES

Al abordar un proyecto que requiera mucha financiación es necesario pensar en que puede haber un escenario en el que no se tenga la financiación requerida. Por tanto hay que hacer objetivos más relacionados al producto y no tanto al negocio ya que vender el producto no es un objetivo que se haya realizado en esta pasantía.

Se debe considerar los tiempos e inversión de implementación al realizar un prototipo de un producto comercializable. Muchos clientes potenciales pueden retractarse de adquirir el producto si se debe hacer mucha modificación a la infraestructura del parqueadero.

Se debe reunir en primera instancia con el “Business Owner” para realizar una propuesta que en primera instancia tenga en cuenta los criterios necesarios para satisfacer al cliente.

Seguir una metodología de trabajo diario asegura que se puedan dar características nuevas cada día, con lo cual se pueden hacer revisiones más seguidas y realizar los cambios pertinentes para que el software se adapte más rápidamente a los requerimientos y que la calidad del mismo mejore al ser utilizado tantas veces durante el desarrollo en busca de bugs.

8. BIBLIOGRAFÍA

Annamalai M., Hemantha J. (1997). TITULO, Berlin, Heidelberg: Springer

FSF. (2007). GNU AFFERO GENERAL PUBLIC LICENSE. Recuperado el 25 de Noviembre de 2016, de https://www.gnu.org/licenses/agpl-3.0.en.html

(59)

Jonathan Warner. (2013). Benchmarks: Node.js vs Go (vs PHP). Recuperado el 25 de Noviembre de 2016, de

https://jaxbot.me/articles/benchmarks_nodejs_vs_go_vs_php_3_14_2013

Mike Wasson. (2013). ASP.NET - Single-Page Applications: Build Modern, Responsive Web Apps with ASP.NET. Recuperado el 25 de Noviembre de 2016, de

https://msdn.microsoft.com/en-us/magazine/dn463786.aspx

OAS. (2016). Proceso de Desarrollo SCRUM/OAS. Recuperado el 15 de Noviembre de 2016, de

https://docs.google.com/document/d/1Co4qWIdtOOMPHKOtdz7qLwJYsj7HKJGZnm LPhBpyuAc/edit?usp=sharing

OAS. (2015). Guía Rápida Proceso de Desarrollo OPENUP/OAS. Recuperado el 25 de Noviembre de 2016, de

https://www.udistrital.edu.co/files/dependencias/oas/GuiaRapidaOpenUPOAS.pdf

OMG. (2011). Documents Associated with Business Process Model and Notation™ (BPMN™) Version 2.0. Recuperado el 25 de Noviembre de 2016, de http://www.omg.org/spec/BPMN/2.0/

Rectoría Universidad Distrital. (2010). Resolución de Rectoría No 206. Recuperado el 25 de Noviembre de 2016, de http://sgral.udistrital.edu.co/xdata/rec/res_2010-206.pdf

Recursos Físicos Universidad Distrital. (2016). Circular 16 de Agosto de 2016. Recuperado el 25 de Noviembre de 2016, de

http://www.udistrital.edu.co:8080/documents/73427/612864/Circular_parqueaderos_ 2016-3.pdf

Richard M. Stallman. (2015). Free Hardware and Free Hardware Designs. Recuperado el 15 de Enero de 2016, de https://www.gnu.org/philosophy/free-hardware-designs.html

Rose, J. L. (2004). Ultrasonic waves in solid media. Cambridge university press. Chicago

Scrum Alliance. (2014). The Scrum Guide. Recuperado el 25 de Noviembre de 2016, de https://www.scrumalliance.org/why-scrum/scrum-guide

(60)

http://www.quotium.com/performance/roles-team-members-involved-agile-scrum-proj ect/

The Apache Software Foundation. (2016). The Number One HTTP Server On The Internet. Recuperado el 25 de Noviembre de 2016, de https://httpd.apache.org/

The PostgreSQL Global Development Group. (2016). About PostgreSQL. Recuperado el 25 de Noviembre de 2016, de https://www.postgresql.org/about/

Unicronic Systems. (2015). Understanding long polling, comet, websockets and sse. Recuperado el 25 de Noviembre de 2016, de

http://www.unichronic.com/blog/get_single_blog/25