SistemaDeParqueaderos JorgeUseche LeonardoZambrano PDF

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
FACULTAD DE INGENIERÍA
BOGOTÁ D.C
2016
1
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

Oficina Asesora de Sistemas
2016
Sistema de Parqueaderos 2
Í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
7. RECOMENDACIONES
8. BIBLIOGRAFÍA
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
visitantes, solamente vehículos registrados. Dentro de la base de datos de vehículos que
ingresan a la universidad se encuentra el horario en el que estos pueden ingresar, ya que,
los funcionarios, docentes y estudiantes, tienen un horario dentro de la universidad, debido
al poco espacio ofrecido por la sede, se le permite o niega la entrada para evitar
hacinamiento y/o congestión, por lo cual se hace registro de la hora de ingreso y salida de
los vehículos.
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.
La parte física está compuesta por elementos y dispositivos tanto mecánicos como
electrónicos, con el fin de ejecutar las acciones dadas por el software y medir las señales a
controlar, proceso con el que se posibilita el acceso o paso de los vehículos en las
circunstancias dadas. Se implementó hardware bajo políticas de hardware libre u “open
hardware”. (Richard M. Stallman, 2015).
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
Ingeniería Electrónica que desarrollan el escrito.
2.1. Planteamiento del problema
La Universidad Distrital, es una zona generadora de viajes y de asentamiento temporal de

los usuarios, los cuales se movilizan por distintos medios de transporte, como los vehículos
particulares, motos, bicicletas; los cuales son de nuestro interés para este proyecto ya que
necesitan de sitios específicos para su estacionamiento y en los cuales se garantice la
seguridad de los mismos. Esta situación no es satisfecha por las zonas disponibles para el
parqueo hoy en día, generando así problemas de hacinamientos, desorden ocupacional,
caos vehicular, invasión de zonas prohibidas e inseguridad.
Específicamente la finalidad del proyecto se basa en la problemática de uso ineficiente de

los recursos asignados a zonas de parqueo, en donde a través del uso de tecnología se
puede hacer más fácil, rápido y óptimo cada proceso de parqueo y el uso del espacio,
además, se podrán dar indicadores mucho más fiables para mejorar el servicio.
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
Universidad Distrital Francisco José de Caldas.
2.2.2. Objetivos Específicos
● Realizar una aplicación web para la interfaz del proyecto en donde se vea la
disponibilidad de las zonas de parqueo.
● Implementar dispositivos de detección de vehículos para permitir su acceso o salida
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.
Quien Gestiona el bien espacial de los parqueaderos de la Universidad

Distrital.
El sistema de Es un sistema de gestión que ayuda a administrar de manera
gestión de sistemática y centralizada las islas de parqueadero de la Universidad
parqueaderos de Distrital Francisco José de Caldas. Además permite hacerle
la Universidad 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.
Nuestro ● Está basado en software y hardware libre de código abierto lo que

producto facilita el desarrollo y acceso al código fuente permitiendo a futuro
un continuo desarrollo y una actualización de todos los procesos
asociados a este producto.
● Tiene en cuenta las necesidades de gestionar el bien espacial y
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 ● Registrar propietarios, revisar aptitud de propietarios.

Recursos Físicos ● 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 ● Rendir información veraz de la distribución espacial de los

Planeación y parqueaderos.
Control ● Ayudar a la construcción y legitimación de políticas de uso de
parqueadero.
PIGA, Plan ● Vigilar la viabilidad ecológica del proyecto y revisar las políticas
Institucional de generadas para parqueaderos, para que vayan en favor del
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.
Por último, para el registro de incidencias, se plantea que: un propietario que cometa faltas
en el uso del servicio de parqueaderos, se le registra una de las incidencias que pueden ser
de muchos tipos ingresados previamente por el administrador de la de dependencia de
recursos físicos.
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.
Los principales requerimientos dados por la división de recursos físicos fueron acordados
mediante reuniones periódicas y adaptados por el grupo de desarrollo a este formato que
establece unas características necesarias para su desarrollo.
Épica
Número: 1 Usuario: División de Recursos Físicos
Nombre épica: Aplicación web para gestionar parqueaderos de la universidad
Prioridad en negocio: Riesgo en desarrollo:

Alta Baja
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:
Épica
Nombre historia: Visor web geográfico de Islas en Tiempo Real

Alta Baja
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.
Observaciones:
Épica
Nombre historia: Dispositivos de Sensado de Ocupación de Islas

Alta Baja
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:
Épica
Nombre historia: Dispositivos de Acceso NFC

Alta Baja
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:
Estas épicas no son atómicas, por lo tanto se subdividieron en tareas que fueron
completadas en su totalidad para cumplir con los requerimientos mencionados en las
épicas. A estas se le llaman historias de usuario y su usuario generador se le denominó
“Scrum Master”, el encargado de traducir los requerimientos del “Business Owner” a
requerimientos que el “Scrum Team” en general puedan entender. Idealmente podría ser
otra persona, pero en este caso son los mismos pasantes los que realizan el trabajo de
“Scrum Master” y “Product Owner” contactando con los “Stake Holders” para conseguir
recursos para el proyecto.
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
Nombre historia: Definición de directrices para la administración de parqueaderos.

Alta Baja
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)
Observaciones:
Historia de Usuario
Nombre historia: Desplegar las versiones realizadas para permitir visualizar al cliente

Alta Baja
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:
Historia de Usuario
Nombre historia: Normalizar protocolos de acuerdo a las circulares y resoluciones

relacionadas a los parqueaderos.

Alta Baja
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.
Observaciones:
Historia de Usuario
Nombre historia: Normalización de protocolos mediante diagramas BPMN para los

procesos relacionados a parqueaderos

Alta Baja
Programador responsable:
Descripción:
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.
Observaciones:
Es importante usar el software BPMN2 que es un plugin de eclipse que resulta generar el
estándar de estos diagramas.
Historia de Usuario
Nombre historia: Documento propuesta con costos de implementación primer prototipo

Alta Baja
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:
Este debe ir dirigido a Recursos Físicos, se deben realizar varias propuestas de
implementación de tecnologías de manera que se escoja la más coherente para el
sistema.
Historia de Usuario
Nombre historia: Modelo de bases de datos

Alta Baja
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.
Historia de Usuario
Nombre historia: CRUD Propietario

Alta Baja
Descripción:
Generar el módulo en la aplicación de parqueaderos, que permite Crear, Consultar,
Actualizar y Eliminar propietarios.
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.
Historia de Usuario
Nombre historia: CRUD Tipo Propietario

Alta Baja
Descripción:
Actualizar y Eliminar tipos de propietarios.
Observaciones:
Historia de Usuario
Nombre historia: CRUD Incidencia

Alta Baja
Descripción:
Actualizar y Eliminar incidencias.
Observaciones:
Historia de Usuario
Nombre historia: CRUD Vehículos

Alta Baja
Descripción:
Actualizar y Eliminar vehículos.
Observaciones:
Historia de Usuario
Nombre historia: CRUD Islas

Alta Baja
Descripción:
Actualizar y Eliminar islas.
Observaciones:
Historia de Usuario
Nombre historia: CRUD Grupos Isla

Alta Baja
Descripción:
Actualizar y Eliminar grupos isla.
Observaciones:
Historia de Usuario
Nombre historia: CRUD Registro entrada/salida

Alta Baja
Descripción:
Actualizar y Eliminar registro entrada/salida.
Observaciones:
Historia de Usuario
Nombre historia: CRUD Incidencias

Alta Baja
Descripción:
Actualizar y Eliminar incidencias.
Observaciones:
Historia de Usuario
Nombre historia: Presentación de avances proyecto

Alta Baja
Descripción:
Se requiere hacer presentaciones periódicas de los avances del proyecto para conseguir
los recursos necesarios para el desarrollo del mismo.
Observaciones:
Historia de Usuario
Nombre historia: Cartografía base - mapa temático

Media Baja
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:
Historia de Usuario
Nombre historia: Servicios web OGC de entidades geográficas del proyecto

Alta Baja
Descripción:
Realizar servicios web en el estándar OGC (en WFS y WMS) de las entidades
geográficas isla y grupo_isla.
Observaciones:
Historia de Usuario
Nombre historia: Visor geográfico para visualizar Isla y Grupo Isla

Alta Baja
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.
Historia de Usuario
Nombre historia: Diseño arquitectónico a base de datos

Alta Baja
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:
Publicar por medio de Geoserver.
Historia de Usuario
Nombre historia: Métodos de localización inalámbrica.

Alta Baja
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.
Historia de Usuario
Nombre historia: Sistema de autenticación de usuarios al sistema

Alta Baja
Descripción:
Se necesita un formulario de acceso y un sistema de autenticación segura que permita
realizar actividades de Creación, Actualización y Eliminación sólo para los usuarios que
tengan permisos.
Observaciones:
Se debe utilizar JWT.
Historia de Usuario
Nombre historia: Documento didáctico para conseguir recursos con Stake Holders

Alta Baja
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.
Historia de Usuario
Nombre historia: Propuesta de investigación con costes del prototipo dos

Alta Baja
Descripción:
Propuesta de investigación con costes de dispositivos de desarrollo para 10 nodos con el
segundo modelo del prototipo.
Observaciones:
Historia de Usuario
Nombre historia:

Alta Baja
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:
Historia de Usuario
Nombre historia: Dispositivo de sensado de Ocupación de la Isla

Alta Baja
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:
Se necesita realizar un dispositivo que orqueste los sensores.
Historia de Usuario
Nombre historia: Dispositivo de acceso por NFC

Alta Baja
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:
Historia de Usuario
Nombre historia: Dispositivo de gestión de Sensores de Isla

Alta Baja
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:
Se denomina nodo-central.
Historia de Usuario
Nombre historia: Actualización en tiempo Real Visor Web Geográfico.

Alta Baja
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.
Historia de Usuario
Nombre historia: Comunicación cifrada entre Nodo Central y Servicio SSE

Alta Baja
Descripción:
Se necesita realizar una comunicación cifrada entre el cliente y el servidor. El cliente es
un Arduino MEGA 2560 y el servidor es un Ordenador con un servicio web en GoLang
utilizando SSE.
Observaciones:
Considerar AES128, AES256. Datos del REQUEST enviados por una codificación en
BASE(2^n).
Historia de Usuario
Nombre historia: Diagramas de conexión Sensor Isla y Nodo Central.

Alta Baja
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.
Las Fig. 3.3.1. a Fig. 3.3.11. muestran parte de los elementos entregados a la OAS para
este entregable. Se comenta en cada uno de estos el significado del diagrama para
contextualizar sobre el problema resuelto.
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
salida esperada y la isla de parqueo a la cual debe dirigirse.
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
de los parqueaderos.
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
ser un intento de hurto.
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
salida.
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
contrario la actividad no se lleva a cabo.
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 ● Docente: de planta u hora cátedra.

de parqueaderos. ● Administrativos: personal que
contrata por nómina la universidad.
● Estudiantes: Estudiantes activos de
la universidad.
● Contratistas: Personas con
contratos mayores o iguales a 3
meses de plazo.
● NO hay servicio a particulares.
Asignación flexible de usuarios de La administración puede retirar y asignar

parqueadero. cupos en cualquier momento y a
necesidad. Tiene autonomía sobre este
servicio.
Tipos de vehículo que pueden usar el ● Carro particular.
parqueadero. (El vehículo debe estar ● Motocicleta particular.
registrado al nombre del usuario, menos ● Carros autorizados.
bicicletas). ● Motocicletas autorizadas.
● NO servicio público.
Necesidad de autenticación para ingresar El carné debe estar actualizado, no tenerlo

al parqueadero. causa denegación del servicio.
El vehículo debe estar registrado en el Para acceder al servicio el sistema debe

sistema. tener 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
facultad.
● Irrespetar las normas de tránsito
locales.
● Incumplimiento de permanencia en
el parqueadero en las horas
autorizadas al usuario.
● No responder a daño o deterioro de
otros vehículos o bienes de la
universidad.
● Realizar dádivas o prebendas con
el servicio que presta los
parqueaderos.
De las características anteriores se elaboró dos diagramas genéricos que permiten revisar
el proceso realizado por el software al ingreso y salida de vehículos. Esto se muestra en la
gráfica Fig. 3.3.12. y Fig. 3.3.13.
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
definido durante la pasantía.
Fig. 3.3.13. Diagrama de flujo de la salida de vehículos.
3.4. Arquitectura general de la implementación
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.
Fig. 3.4.1. Diagrama de estructura y despliegue del proyecto.
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.
Fig. 3.5.1. Ciclo de vida de un sitio web tradicional. (Mike Wasson, 2013)
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 Funcionalidad Razón de Uso
Componente
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 Es un sistema de gestión de base de datos relacional,

de Datos es considerada la más avanzada y tiene más de 15
años de desarrollo activo (The PostgreSQL Global
Development Group, 2016) y es totalmente compatible
con ACID (atomicity consistency isolation durability).
Aparte tiene la característica más importante para el
proyecto, ser extensible para datos geográficos. Es
software libre con licencia PostgreSQL.
PostGIS Extensión de Agrega soporte a datos y operaciones espaciales al

Postgres para motor PostgreSQL. PostgreSQL + PostGIS es la más
datos clara alternativa libre al software de almacenamiento
espaciales privativo de bases de datos. Es software libre bajo
licencia GPLv2.
Geoserver Servidor de Es un servidor de código abierto para compartir datos
datos espaciales, diseñado para la interoperabilidad,
espaciales publicando los datos en la mayoría de estándares
abiertos. Tiene una buena documentación para su
integración con PostgreSQL+PostGIS. Es software
libre con licencia GPL.
GO Lenguaje de También conocido como Golang, es un lenguaje de

programación programación de código abierto que facilita la creación
de software simple, confiable y eficiente. La última es
la característica más atrayente teniendo test de
rendimiento “benchmarks” comparándose con otros
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
documentación para el uso del lenguaje. Es software
libre bajo licencia estilo BSD.
Beego Framework de Framework de desarrollo de aplicaciones en golang.

desarrollo de Es bastante rápido y de los mejores documentados
aplicaciones que se pudieron encontrar, resuelve muchas de las
web tareas de desarrollo como la creación del servicio
RESTful a partir de la tabla en la base de datos
(proceso de ingeniería inversa) lo cual agiliza la
implementación de proyectos. Software libre bajo
licencia Apache v2.0.
SSE GO Servidor de Componente realizado en golang para este proyecto

envío de utilizando el concepto de Server-Send Event, en este
eventos caso se revisó 3 formas de enviar datos de manera
asíncrona del servidor al cliente. Estos son long
polling, websockets y SSE (Unicronic Systems, 2015).
En el primero se envían peticiones al servidor que
dejan abierto el canal y que sólo responde el servidor
cuando necesita enviar un dato al cliente, terminado el
proceso envía una petición que bloquea nuevamente
el canal. En la segunda se utiliza un canal en que el
cliente establece la conexión y bloquea el canal, de
ahí tanto el cliente como el servidor pueden enviar
mensajes, es uno de los más versátiles de los tres.
Por último está SSE, en el cual el cliente establece la
conexión, bloquea el canal y sólo el servidor es capaz
de enviar datos. Este último fue el más conveniente ya
que nos permite enviar sólo los datos que se
necesitan ya que no se quieren datos del cliente para
la función de tiempo real, consecuentemente también
se ahorra en el uso de transferencia de datos por el
medio. Software libre, publicado con licencia AGPLv3.
AngularJS Framework Framework de Javascript que con su módulo
para construir ng-Resource permite el consumo fácil y apropiado de
aplicaciones servicios RESTful. Permite hacer fácilmente vistas con
MVW el módulo ng-Views y cantidad de facilidades para el
desarrollo de aplicaciones SPA. Se utilizó la versión 1
ya que es la única versión más reciente que se puede
utilizar sin usar “loaders” o transformadores de código
que acomplejan el proceso de aprendizaje de la
herramienta de desarrollo. Es software libre bajo la
licencia MIT.
Bootstrap Framework de El maquetador más usado con AngularJS y por tanto

maquetación con más ejemplos en la web. Es posible conectarlo
adaptable a fácilmente con las vistas generadas de AngularJS. Es
cualquier software libre bajo la licencia MIT.
tamaño de
dispositivo
JQuery Biblioteca de Una biblioteca de funciones necesaria para hacer

funciones funcionar el complemento Twitter Bootstrap. Es
Javascript software libre bajo la licencia MIT.
OpenLayers Biblioteca Es la más antigua de las opciones para visores de

javascript para mapas en los navegadores web, la versión 3 está bien
la inclusión de documentada y tiene muchísimos ejemplos. Se
mapas en el escogió porque permite una conexión con la mayoría
navegador de servicios web estándares establecidos por la OGC,
característica que no tienen otras alternativas libres
como leaflet.
Materialize Framework El material design es un concepto usado en Google

CSS front-end para hacer referencia a un conjunto de
basado en especificaciones de material de diseño que busca
Material Design mejorar la homogeneidad del consumo de interfaces,
(Google, 2016) haciendo que el usuario no tenga que complicarse y
tenga una interfaz agradable. Se usa para la api de
mapas ya que contiene estilos agradables al usuario.
Las Fig. 3.5.3. a Fig. 3.3.14. muestran las capturas de pantalla de la aplicación funcionando
en el entorno de pruebas de la OAS.
Fig. 3.5.3. Pantalla de bienvenida del Sistema de Gestión de Parqueaderos.
Fig. 3.5.4. CRUD entidad Tipos de Propietario.
Fig. 3.5.5. CRUD entidad Propietarios.
Fig. 3.5.6. CRUD entidad Vehículos.
Fig. 3.5.7. CRUD entidad Grupo Islas.
Fig. 3.5.8. CRUD entidad Islas.
Fig. 3.5.9. CRUD entidad Registros Entrada/Salida.
Fig. 3.5.10. CRUD entidad Propietarios, vista de Crear o Editar Propietario.
Fig. 3.5.11. CRUD entidad Vehículo, vista Crear o editar Vehículo.
Fig. 3.5.12. Vista inicial del visor web geográfico de Parqueaderos de la Universidad
Distrital.
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.
Esta aplicación es software libre y está alojada públicamente en el sistema TULEAP

perteneciente al dominio de aplicaciones de la universidad en el enlace
https://tuleap.udistrital.edu.co/projects/parqueaderos y, también en un repositorio en
GITHUB https://github.com/udistrital/parqueaderos se tienen alrededor de 380 commits
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

Para realizar el hardware se decidió preservar la ideología del software usado, se utiliza
hardware que tenga en su mayoría diseños de código abierto con los cuales se pueda usar,
copiar y redistribuir con o sin cambios libremente. Al hardware que cumple estas
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
de eco de su onda, este principio aplica para los sensores basados en ultrasonido.
(Rose, J. L., 2004)
● RFID: (identificación por radiofrecuencia), es un método de identificación, a través,
de la transmisión de los objetos identificables llamados etiquetas o tags RFID que
utilizan la radiofrecuencia para la transmisión remota de la información, existen
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á
limitado a transacciones a corta distancia pero se basa en tecnología similar, sino
que es de menor potencia y alcance, su utilidad está en aplicaciones donde la
comunicación deba ser lo más segura posible y no haya muchas posibilidades de
interferencia, esto se logra con la restricción física de las cortas distancias de
comunicación de los dispositivos, tampoco está enfocada a grandes transacciones
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,
establece, integra y define las características de la capa física. Por costumbre se
habla de Ethernet y el estándar IEEE 802.3 de forma indistinta, así, en el literal
802.3i de 1990 se define las características de la capa física como 10BASE-T de
tasa 10 Mbps sobre linal de par trenzado no blindado (UTP), con longitud máxima
del segmento de 150 metros.
Tabla 3.6.1. Hardware y las características por las que se escogieron para el desarrollo del
proyecto.
Nombre Funcionalidad Razón de Uso
Componente
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 Mecanismos El mecanismo de comprobación de identificación de

para Arduino de control de un usuario al parqueadero se escogió, a través de
acceso al RFID puntualmente NFC y su característica de
parqueadero 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.
Microcontrolad Nodo sensor Este dispositivo tiene la función de recibir y procesar

or la señal del sensor de proximidad para luego enviarla
ATMega328P a través de radiofrecuencia al nodo central. Ya que
este dispositivo no tiene mayores prestaciones no se
uso la placa completa de Arduino Uno si no, solo su
microcontrolador enfocado a las tareas puntuales a
realizar.
Modulo Mecanismo de El sistema planteado, para la determinación del

Ethernet para conectividad estado de las islas del parqueadero, se pensó como
Arduino entre nodos un sistema similar a un panal de abejas, en donde
centrales 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 / Dispositivo de Los dispositivos encargados de la detección de

Receptor de comunicación ocupación de las islas, deben comunicarse
Radio entre los inalámbricamente a su nodo central, por razones
Frecuencia detectores y el espaciales, así que, tales detectores se comunican
nodo central con los nodos centrales a través de radiofrecuencia a
2,4 Ghz.
Sensor de Dispositivo Este dispositivo cumple la tarea de determinar si hay

proximidad para la un vehículo posicionado sobre una isla en particular,
ultrasonico detección de tal información, se la entrega al microcontrolador.
objetos
Baterías Servidor de Como hay dispositivos ubicados en posiciones que

Recargables envío de físicamente están impedidos de conexión a la eléctrica
eventos 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.
Para la petición de recursos para las pruebas se realizaron diagramas pictóricos llamativos
los cuales permiten que los “Stake Holders” entiendan la importancia de realizar varios
prototipos en busca de la mejor solución de hardware. Estos diagramas pasaron por control
de versiones ya que a medida de que se cambiaba de tecnologías, estos diagramas
resultaban útiles para explicar las nuevas inversiones. Los últimos realizados son los
mostrados en la Fig. 3.6.1. y en la Fig. 3.6.2.
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
protoboard del Nodo Central con esta tecnología de comunicación se puede ver en la Fig.
3.6.3.
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.
Fig. 3.6.4. Implementación del sensor de ocupación. (a) Implementación con protoboard y
plataforma de desarrollo (b) Implementación con circuito PCB y alimentación por baterías.
Fig. 3.6.5. Circuito PCB de sensor de ocupación de Isla
Fig. 3.6.6. Diagrama de conexión eléctrica del sensor de ocupación de Isla
Fig. 3.6.7. Modelo 3D de contenedor de sensor de ocupación de isla en suelo.
3.7. Indicadores
En la propuesta se puso que los indicadores medidos serían de espacio y tiempos

registrados en el sistema. Estos dos indicadores se representan en el aplicativo web y en el
visor geográfico. El de espacio ocupado se muestra sobre la entidad geográfica de la isla y
compara el área del vehículo que está parqueado en la isla (obtenido mediante registro en
la tabla) con el área de la isla extraído mediante la geometría en el mapa, de estos realiza la
diferencia y da como resultado un índice de uso del espacio como se muestra en la Fig.
3.7.1. El indicador de tiempos registrados en el sistema se da mediante la analítica de la
entidad llamada registro (entrada y salida), el primer indicador que arroja es el de tiempo
esperado vs tiempo real con el cual se pueden registrar las incidencias (Ver modelo en Fig.
3.1.1).
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.
Se probó el consumo de potencia del microcontrolador y demás accesorios del Sensor de

Isla, se realizó con el ATMEGA328 con toda la plataforma de desarrollo de arduino UNO,
luego con solo el microcontrolador polarizado y por último con la versión picoPower del
microcontrolador, una versión reducida en potencia que mejora muchísimo los problemas de
consumo para un dispositivo que debe ser alimentado con baterías recargables. Entonces la
lógica de programación para usar este último no cambia para nada, lo que sí cambia es el
diseño de pcb ya que este tiene otro tipo de encapsulamiento, alternativamente se puede
usar el Arduino PRO Mini que usa el microcontrolador en su versión picoPower pero con
pines de conexión más asequibles para soldar manualmente a una baquela.
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.
Se espera que eso produzca una implementación masiva en los demás parqueaderos de la
Universidad. Además de que como pertenece al dominio de aplicaciones de la universidad,
se pueda vender el software adaptado a otras organizaciones como universidades e
parqueaderos públicos y privados.
6. CONCLUSIONES
El desarrollo de esta aplicación está basada en la satisfacer las necesidades de la gestión

del área de parqueaderos de la facultad de ingeniería de la Universidad Distrital, sin
embargo, tal desarrollo se conceptualizo de forma general, para así obtener un sistema
escalable tanto en la parte de software a través de REST API y en la parte de hardware a
través de del su estructura modular de los componentes.
Este proyecto además íntegro el modelo de diseño Backend-Frontend, en donde para cada
caso se utilizó los lenguajes o framework más destacados del momento (Go-AngularJS
respectivamente), para así dejar un precedente del uso y desarrollo de aplicaciones con
tales herramientas, y que de esta manera se pueda llevar a cabo la migración de más
aplicaciones de la Universidad o de la OAS, para así obtener un mejoramiento de las
mismas.
En la parte de hardware del proyecto, el uso de elementos modulares, representó una gran
ayuda en el desarrollo del proyecto, así que al escoger la plataforma de desarrollo de
Arduino se pudo avanzar rápidamente en el desarrollo de la funcionalidad del proyecto y no
tener preocupaciones por la operatividad de los componentes, por lo cual, se realizó la
adaptación de tales módulos a los requerimientos del proyecto, en donde se buscó la
optimización de los recursos energéticos de los módulos y la funcionalidad correcta de
estos.
Para los desarrolladores del proyecto es muy importante poder promocionar la filosofía de la
cultura libre, por eso, este proyecto se llevó a cabo utilizando herramientas de software libre
y de hardware libre, la razón radica en el gran potencial de desarrollo y mejoramiento que la
comunidad puede agregar a estas herramientas.
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
Google. (2016). Material design Introduction. Recuperado el 25 de Noviembre de 2016, de

https://material.google.com/
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
Swaraj Gupta. (2016). Roles of team members involved in an AGILE Scrum project.
Recuperado el 25 de Noviembre de 2016, de
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
Want, R. (2006). An introduction to RFID technology. IEEE Pervasive Computing, 5(1),

25-33.

SistemaDeParqueaderos JorgeUseche LeonardoZambrano PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SistemaDeParqueaderos JorgeUseche LeonardoZambrano PDF

Uploaded by

Copyright:

Available Formats

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

OMAR LEONARDO ZAMBRANO PULGARÍN

TRABAJO DE GRADO PARA OPTAR AL TÍTULO DE

CARLOS ENRIQUE MONTENEGRO MARÍN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

SISTEMA DE GESTIÓN ADMINISTRATIVA

Sistema de Información de Gestión de

Jorge Ulises Useche Cuellar - Pasante Oficina Asesora de Sistemas

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

2. DESCRIPCIÓN DEL PROYECTO

4. ANÁLISIS DE LOS RESULTADOS

5. ALCANCE E IMPACTO DEL SISTEMA DE PARQUEADEROS

El aplicativo tiene dos tipos de entornos: usuario y administrador, el administrador, debe

2. DESCRIPCIÓN DEL PROYECTO

La Universidad Distrital le ofrece a sus trabajadores y estudiantes, un espacio donde

El propósito de este documento es analizar y presentar los resultados obtenidos del

El proyecto abarca para su desarrollo un conocimiento multidisciplinar y un manejo

2.1. Planteamiento del problema

La Universidad Distrital, es una zona generadora de viajes y de asentamiento temporal de

Específicamente la finalidad del proyecto se basa en la problemática de uso ineficiente de

Dicho lo anterior, la problemática está dada en la falta de automatización del proceso de la

2.2.1. Objetivo General

● Construir e implementar el componente sistema de gestión de parqueaderos,

2.2.2. Objetivos Específicos

2.3. Definición de la solución propuesta

Para Funcionarios, Docentes, Contratistas y Estudiantes.

Quien Gestiona el bien espacial de los parqueaderos de la Universidad

El sistema de Es un sistema de gestión que ayuda a administrar de manera

Que El sistema de gestión PARQUEADEROS administra entradas y

A diferencia de La administración manual de los espacios, con la asignación de

Nuestro ● Está basado en software y hardware libre de código abierto lo que

2.4. Descripción de los interesados

Nombre Responsabilidades en el proceso

División de ● Registrar propietarios, revisar aptitud de propietarios.

Oficina Asesora de ● Rendir información veraz de la distribución espacial de los

El proyecto tiene un sistema informático y teleinformático que permite la gestión de

El sistema realizado no cuenta con módulos de reportes, estadísticas analísticas o

Después de un arduo trabajo y muchos controles de cambios, se obtuvo un modelo de base

3.2. Épicas e historias de usuario

La metodología usada contempla una disciplina de levantamiento de requerimientos basada

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

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

Prioridad​ ​en negocio​: Riesgo en desarrollo​:

Puntos estimados​: 1000 Iteración asignada​:

Programador responsable​: Jorge Useche y Leonardo Zambrano

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

Nombre​ ​historia​: Visor web geográfico de Islas en Tiempo Real

Prioridad​ ​en negocio​: Riesgo en desarrollo​:

Puntos estimados​: 1000 Iteración asignada​:

Programador responsable​: Jorge Useche y Leonardo Zambrano

Nombre​ ​historia​: Dispositivos de Sensado de Ocupación de Islas

Prioridad​ ​en negocio​: Riesgo en desarrollo​:

Puntos estimados​: 1000 Iteración asignada​:

Programador responsable​: Jorge Useche y Leonardo Zambrano

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

Nombre​ ​historia​: Dispositivos de Acceso NFC

Prioridad​ ​en negocio​: Riesgo en desarrollo​:

Puntos estimados​: 1000 Iteración asignada​:

Programador responsable​: Jorge Useche y Leonardo Zambrano

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

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

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 1000 Iteración asignada:

Programador responsable: Jorge Useche y Leonardo Zambrano

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

Nombre historia: Visor web geográfico de Islas en Tiempo Real

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 1000 Iteración asignada:

Programador responsable: Jorge Useche y Leonardo Zambrano

Nombre historia: Dispositivos de Sensado de Ocupación de Islas

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 1000 Iteración asignada:

Programador responsable: Jorge Useche y Leonardo Zambrano

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

Nombre historia: Dispositivos de Acceso NFC

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 1000 Iteración asignada:

Programador responsable: Jorge Useche y Leonardo Zambrano

Número: 1 Usuario: Scrum Master

Nombre historia: Definición de directrices para la administración de parqueaderos.

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 10 Iteración asignada:

Programador responsable: Jorge Useche

Número: 2 Usuario: Scrum Master

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 10 Iteración asignada:

Programador responsable: Jorge Useche

Número: 3 Usuario: Scrum Master

Nombre historia: Normalizar protocolos de acuerdo a las circulares y resoluciones

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 10 Iteración asignada:

Programador responsable: Jorge Useche

Número: 4 Usuario: Scrum Master

Nombre historia: Normalización de protocolos mediante diagramas BPMN para los

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 100 Iteración asignada:

Número: 5 Usuario: Scrum Master

Nombre historia: Documento propuesta con costos de implementación primer prototipo

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 10 Iteración asignada:

Programador responsable: Leonardo Zambrano

Número: 6 Usuario: Scrum Master

Nombre historia: Modelo de bases de datos

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 100 Iteración asignada:

Programador responsable: Leonardo Zambrano y Jorge Useche

Número: 7 Usuario: Scrum Master

Nombre historia: CRUD Propietario

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 50 Iteración asignada:

Programador responsable: Leonardo Zambrano

Número: 8 Usuario: Scrum Master

Nombre historia: CRUD Tipo Propietario

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 50 Iteración asignada:

Programador responsable: Leonardo Zambrano

Número: 9 Usuario: Scrum Master

Nombre historia: CRUD Incidencia

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 50 Iteración asignada:

Programador responsable: Leonardo Zambrano

Número: 10 Usuario: Scrum Master

Nombre historia: CRUD Vehículos

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 50 Iteración asignada:

Programador responsable: Leonardo Zambrano

Número: 11 Usuario: Scrum Master

Nombre historia: CRUD Islas

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 50 Iteración asignada:

Programador responsable: Leonardo Zambrano

Número: 12 Usuario: Scrum Master

Nombre historia: CRUD Grupos Isla

Prioridad en negocio: Riesgo en desarrollo:

Puntos estimados: 50 Iteración asignada:

Programador responsable: Leonardo Zambrano

Número: 13 Usuario: Scrum Master

Nombre historia: CRUD Registro entrada/salida

Prioridad en negocio: Riesgo en desarrollo: