UNIVERSIDAD DISTRITAL

“FRANCISCO JOSE DE CALDAS”

TRABAJO FINAL
ESPECIALIZACIÓN EN PROYECTOS INFORMÁTICOS

DISEÑO DE PROTOTIPO DE SOFTWARE MÓVIL PARA LA

PROGRAMACIÓN Y CONTROL DEL PARQUEADERO UD

Autores
Sandra Milena Roa Parra
Norma Constanza Losada Motta
William Roberto García Rincón

Director
Roberto Ferro

Bogotá 2016
Resumen
La asignación de los cupos de los parqueaderos al tener éstos el carácter de bienes privados o
comunes debe ceñirse o basarse en los reglamentos internos de la entidad propietaria, adicional a
la reglas contenidas en estos estatutos las entidades pueden tener reglas particulares asociadas a
cada empleado tales como carga laboral, reuniones programadas, tipo de contrato, entre otras, un
caso particular es el de una institución universitaria en donde los docentes pueden ser asignados
por horario de clases, jornadas de investigación, horario de oficina o cualquier otra directriz
administrativa.

Con base en las reglas establecidas para la asignación de cupos de parqueo, el presente proyecto
busca desarrollar un prototipo que permita a través de un dispositivo móvil a los usuarios,
administradores y guardas de seguridad hacer gestión del uso, programación y control
respectivamente de los cupos de los parqueaderos de la empresa propietaria de una forma fácil y
efectiva, el propósito es hacer uso de la aplicación en el momento que se requiera conocer la
disponibilidad de los espacios de parqueo, para los administradores del parqueadero hacer la
distribución inicial de espacios así como la programación o asignación de los mismos y
configurar los mensajes de alerta, para el guarda de seguridad tener el control del acceso y
registro de novedades resultantes de los recorridos de revisión que deban realizar.

Finalmente con los resultados de la prueba del prototipo se hace un análisis que permita formular
la propuesta de escalabilidad adicionando funcionalidades inherentes al proceso de gestión de
parqueaderos.

PALABRAS CLAVE: Prototipo, modelo, programación, control, aparcamiento, aplicación

móvil, mensajes de alerta.
Abstract
The allocation of quotas of parking to have these in the character of private property or Common
must adhere or be based on the respective internal regulations of the owning entity, in addition to
the rules contained in these Statutes Entities may have particular rules associated with each
employee stories as workload, scheduled meetings, type of contract, among others, the UN is in
particular the case of a University institution where teachers can be assigned for class schedule,
conferences, research, business hours or any other administrative directive.

Based on the rules for the allocation of quotas parking, this project seeks to develop UN
prototype that allows for a Through Device UN Mobile users, Administrators and Security
Guards Make use management, programming and control respectively of quotas parking lots of
the owner of an easy and effective way, the purpose m is to make use of the application at the
time required to know the availability of parking spaces for Administrators parking Making
Distribution initial spaces as well as when programming or allocating them and Configure alert
messages, for the security guard have control access and novelties Registry resulting from Tours
Review to be conducted.

Finally with the results of prototype testing an analysis to formulate the proposal for adding
features inherent scalability Management Process is parking ago.

KEYWORDS: Prototype, model, programming, control, parking, mobile application, alert

messages
Agradecimientos

A Dios por bendecirnos con la oportunidad, mantenernos firmes y fuertes en ella y no decaer a
pesar de las adversidades que se presentaron durante la especialización y desarrollo del proyecto.

A la Universidad Distrital “Francisco José de Caldas”, en especial a su facultad de Ingeniería y

coordinación de la especialización en Proyectos Informáticos por permitirnos ser parte de ella y
continuar con nuestro proceso de formación como profesionales en el campo de la informática.

A los Docentes Roberto Ferro, Roberto Pava y John Jairo Londoño quienes estuvieron
involucrados en todo el proceso de desarrollo del presente proyecto de grado y que gracias a sus
indicaciones, consejos y constante apoyo logramos culminar esta etapa en el largo y complejo
camino en la búsqueda del conocimiento.

A nuestras familias cuyo apoyo emocional ha sido la principal fuente de motivación que hizo
visibles todos los caminos hacia los objetivos cuando creíamos que estos eran difíciles.

A nuestros compañeros de especialización con quienes no solamente intercambiamos conceptos,

puntos de vista y reflexiones, además hicieron agradable cada sesión de trabajo que derivaron en
buenos lazos de amistad.

“No le pongas excusas a lo que no puedes terminar. Enfócate en todas aquellas razones por las
que debes hacer que suceda”. Ralph Marston
Tabla de contenido
Resumen ........................................................................................................................................................................ 2
Abstract.......................................................................................................................................................................... 3
INTRODUCCIÓN ....................................................................................................................................................... 10
PARTE I FUNDAMENTACIÓN DE LA INVESTIGACIÓN .................................................................................. 11
CAPITULO 1 DESCRIPCIÓN DE LA INVESTIGACIÓN ...................................................................................... 11
1.1 IDENTIFICACIÓN DEL PROBLEMA ......................................................................................................... 11
1.2 OBJETIVOS ................................................................................................................................................... 12
1.2.1 OBJETIVO GENERAL ............................................................................................................................. 12
1.2.2 OBJETIVOS ESPECÍFICOS ..................................................................................................................... 12
1.3 JUSTIFICACIÓN ........................................................................................................................................... 13
1.4 HIPÓTESIS .................................................................................................................................................... 13
1.5 MARCO REFERENCIAL ............................................................................................................................. 14
1.5.1 MARCO TEÓRICO ................................................................................................................................... 14
1.5.2 MARCO CONCEPTUAL .......................................................................................................................... 18
1.5.3 ASPECTOS LEGALES ............................................................................................................................. 19
1.6 METODOLOGÍA........................................................................................................................................... 20
1.6.1 LEVANTAMIENTO DE INFORMACION .............................................................................................. 20
1.6.2 DISEÑO ..................................................................................................................................................... 20
1.6.3 DESARROLLO DEL PROTOTIPO .......................................................................................................... 20
1.7 ORGANIZACIÓN DEL TRABAJO .............................................................................................................. 21
1.8 ESTADO DEL ARTE .................................................................................................................................... 23
CAPITULO 2 DESCRIPCIÓN DE LA INVESTIGACIÓN ...................................................................................... 27
CAPITULO 3 DESCRIPCIÓN SOLUCIÓN .............................................................................................................. 39
3.1 SITUACION ACTUAL DEL PARQUEADERO UNIVERSIDAD DISTRITAL – SEDE SABIO CALDAS
39
3.2 DESCRIPCION GENERAL DEL SISTEMA ................................................................................................ 42
CAPITULO 4 DEFINICIÓN DE ROLES, FUNCIONES Y REQUERIMIENTOS DE LOS USUARIOS DEL
SISTEMA. ................................................................................................................................................................... 51
CAPÍTULO 5 DISEÑO CASOS DE USO, MODELO ENTIDAD RELACIÓN Y DIAGRAMA DE SECUENCIA
..................................................................................................................................................................................... 55
5.1 CADENA LÓGICA DE NEGOCIO .......................................................................................................... 55
5.3 DIAGRAMA DE CASOS DE USO .......................................................................................................... 56
CAPITULO 6: DISEÑO PROTOTIPO MÓVIL ......................................................................................................... 81
PARTE III CIERRE DE LA INVESTIGACIÓN ....................................................................................................... 97
CAPÍTULO 7 RESULTADOS Y DISCUSIÓN ..................................................................................................... 97
CAPÍTULO 8 CONCLUSIONES ......................................................................................................................... 102
4.1 VERIFICACIÓN, CONTRASTE Y EVALUACIÓN DE LOS OBJETIVOS ........................................ 102
4.2 SÍNTESIS DEL MODELO PROPUESTO .............................................................................................. 103
 CAPÍTULO 9 PROSPECTIVA DEL TRABAJO DE GRADO ............................................................................ 105
9.1 LÍNEAS DE INVESTIGACIÓN FUTURAS .......................................................................................... 105
9.2 TRABAJOS DE INVESTIGACIÓN FUTUROS .................................................................................... 113
BIBLIOGRAFÍA ....................................................................................................................................................... 115
ANEXOS ................................................................................................................................................................... 116
ANEXO 1 .................................................................................................................................................................. 116
ANEXO 2 .................................................................................................................................................................. 117
ANEXO 3 .................................................................................................................................................................. 117
ANEXO 4 .................................................................................................................................................................. 117
Tabla de Figuras

Figura 1 Partes de una Tarjeta Inteligente. Tomado de (Tarjetas Inteligentes) .......................................................... 15

Figura 2 Modelo de red para la asignación de parqueaderos. Tomado de (VENKATARAMANAN & BORNSTEIN,
1991) ............................................................................................................................................................................ 24
Figura 3 Sistema de soporte de decisiones para la asignación de parqueaderos. Tomado de (VENKATARAMANAN
& BORNSTEIN, 1991) ............................................................................................................................................... 25
Figura 4 Arquitectura del sistema de carga de PHEV. Tomado de (Huang, Gupta, & Huang, 2012) ......................... 26
Figura 5 Arquitectura Peer to Peer NFC. Tomado de (Vilanoveta, 2015) ................................................................... 28
Figura 6 Tipos Etiquetas NFC. Tomado de (INTECO, 2004) ..................................................................................... 28
Figura 7 Esquema del Web Service. Modificado de (Ribas Lequerica, 2003) ........................................................... 31
Figura 8 Sistema básico de un Web Service. Modificado de (Ribas Lequerica, 2003) .............................................. 31
Figura 9 Representación de un sistema más sofisticado de Web Service. Modificado de (Ribas Lequerica, 2003) .. 31
Figura 10 Arquitectura del prototipo ........................................................................................................................... 34
Figura 11 Modelo Lógico del Prototipo ...................................................................................................................... 35
Figura 12 Modelo Físico del Prototipo ........................................................................................................................ 36
Figura 13 Diagrama de Componentes propuesto para el Prototipo ............................................................................. 37
Figura 14 Carnet para el Acceso al Parqueadero ......................................................................................................... 39
Figura 15 Mecanismo actual de control de acceso al parqueadero .............................................................................. 40
Figura 16 Espacios para motocicletas en el Parqueadero UD-Sede Calle 40 .............................................................. 41
Figura 17 Espacios para automóviles en el Parqueadero UD-Sede Calle 40 ............................................................... 41
Figura 18 Escenarios del prototipo del producto informático ...................................................................................... 42
Figura 19 Sistema de Control de Acceso. Modificado de (Smart Card Alliance Latin America (SCALA), 2006) ..... 44
Figura 20 Circuito Sensor Infrarrojo ........................................................................................................................... 45
Figura 21 LED ............................................................................................................................................................. 46
Figura 22 Conexión arduino y sensor .......................................................................................................................... 46
Figura 23 Conexión LEDs ........................................................................................................................................... 46
Figura 24 Esquema codificación WS Actualizar estado parqueadero ......................................................................... 47
Figura 25 Procedimiento almacenado para actualizar estado en BD ........................................................................... 48
Figura 26 Request WS Actualizar estado parqueadero ................................................................................................ 48
Figura 27 Response WS Actualizar estado parqueadero ............................................................................................. 49
Figura 28 Actualización estado en BD ........................................................................................................................ 49
Figura 29 Cadena Lógica de Negocio .......................................................................................................................... 55
Figura 30 Componentes Sistema ................................................................................................................................. 56
Figura 31 Diagrama de Flujo Administrador ............................................................................................................... 56
Figura 32 Diagrama de flujo Usuario .......................................................................................................................... 56
Figura 33 Diagrama de flujo Sistema .......................................................................................................................... 57
Figura 34 Diagrama de flujo Controlador físico .......................................................................................................... 57
Figura 35 Modelo Dependencia Funcional Exclusiva ................................................................................................. 69
Figura 36 Modelo Relacional ...................................................................................................................................... 71
Figura 37 Modelo Entidad-Relación............................................................................................................................ 72
Figura 38 Diagrama secuencia: Ingreso Autorización ................................................................................................. 73
Figura 39 Diagrama de Secuencia Registro usuario .................................................................................................... 73
Figura 40 Diagrama de Secuencia Ingreso usuario ...................................................................................................... 74
Figura 41 Diagrama de Secuencia Disponibilidad ....................................................................................................... 74
Figura 42 Diagrama de Secuencia Consultar Usuario ................................................................................................. 75
Figura 43 Diagrama de Secuencia Eliminar Usuario ................................................................................................... 76
Figura 44 Diagrama de Secuencia Actualizar información ......................................................................................... 77
Figura 45 Diagrama de Secuencia Configurar Parqueadero ........................................................................................ 78
Figura 46 Diagrama de Secuencia Registrar ingreso de usuario .................................................................................. 79
Figura 47 Diagrama de Secuencia Registrar disponibilidad de espacio de parqueadero ............................................. 79
Figura 48 Diagrama de Secuencia Notificar Alertas por horario ................................................................................. 80
Figura 49 Diagrama de Secuencia Registro de Novedades por el Controlador Físico ................................................ 80
Figura 50 Plano Sótano 1 Sabio Caldas ....................................................................................................................... 81
Figura 51 Sótano 2 Sabio Caldas ................................................................................................................................ 81
Figura 52 Plano Sótano 3 Sabio Caldas ...................................................................................................................... 82
Figura 53 Modulo Administrador ................................................................................................................................ 82
Figura 54 Creación de Usuario .................................................................................................................................... 83
Figura 55Usuario creado............................................................................................................................................. 84
Figura 56 Consultar Usuario ........................................................................................................................................ 85
Figura 57 Actualizar Usuario ...................................................................................................................................... 85
Figura 58 Usuario Actualizado ................................................................................................................................... 86
Figura 59 Eliminar Usuario ......................................................................................................................................... 86
Figura 60 Configurar Parqueadero .............................................................................................................................. 87
Figura 61 Parqueadero creado .................................................................................................................................... 87
Figura 62 Opción Info ................................................................................................................................................. 89
Figura 63 Pantalla Inicio ............................................................................................................................................. 89
Figura 64 Completar Registro ..................................................................................................................................... 90
Figura 65 Información de registro inválida ................................................................................................................. 90
Figura 66 Parking ....................................................................................................................................................... 91
Figura 67 Usuario con Horario valido ......................................................................................................................... 91
Figura 68 Usuario horario no valido ........................................................................................................................... 92
Figura 69 Consulta disponibilidad espacio ................................................................................................................. 93
Figura 70 Elección de estacionamiento ...................................................................................................................... 93
Figura 71 Opción liberar espacio ................................................................................................................................ 94
Figura 72 Usuario libera espacio ................................................................................................................................. 94
Figura 73 Modulo Control ........................................................................................................................................... 95
Figura 74 Selección espacio para generación de alerta ................................................................................................ 96
Figura 75 Envío alerta por mal uso .............................................................................................................................. 96
Figura 76 Grafica Encuesta - Respuesta Pregunta uno ................................................................................................ 97
Figura 77 Grafica Encuesta - Respuesta Pregunta dos ................................................................................................ 98
Figura 78 Grafica Encuesta - Respuesta Pregunta tres ................................................................................................ 98
Figura 79 Grafica Encuesta - Respuesta Pregunta cuatro ............................................................................................ 99
Figura 80 Grafica Encuesta - Respuesta Pregunta cinco ............................................................................................. 99
Figura 81Grafica Encuesta - Respuesta Pregunta seis ............................................................................................... 100
Figura 82 Grafica Encuesta - Respuesta Pregunta siete ............................................................................................ 100
Figura 83 Diagrama BPMN Prototipo Parqueadero UD ........................................................................................... 104
Figura 84 Función Objetivo del modelo de asignación. ............................................................................................ 110
Figura 85 Restricciones asociadas al modelo de asignación ...................................................................................... 110
Figura 86 Definición de conjuntos y parámetros en GAMS ...................................................................................... 111
Figura 87 Definición de variables, ecuaciones y métodos de solucione en GAMS ................................................... 111
Figura 88 Resultado generado por GAMS al ejecutar el modelo de optimización .................................................... 112
Figura 89 Resultado generado por GAMS al ejecutar el modelo de optimización .................................................... 112
Índice de Tablas

Tabla 1 Distribución del Parqueadero ......................................................................................................................... 41

Tabla 2 Usuarios del sistema ....................................................................................................................................... 51
Tabla 3 Rol Administrador y funciones ....................................................................................................................... 52
Tabla 4 Rol Usuario y funciones ................................................................................................................................. 52
Tabla 5 Rol controlador físico y funciones .................................................................................................................. 52
Tabla 6 REQ001 Autorizaciones ................................................................................................................................. 53
Tabla 7 REQ002 Administración de usuarios ............................................................................................................. 53
Tabla 8 REQ003 Administración parqueadero ............................................................................................................ 53
Tabla 9 REQ004 Alertas .............................................................................................................................................. 54
Tabla 10 Caso de Uso: Ingreso autorización ............................................................................................................... 58
Tabla 11 Caso de Uso: Crear cuenta ............................................................................................................................ 59
Tabla 12 Caso de Uso – Ingreso .................................................................................................................................. 60
Tabla 13 Caso de Uso: Registrar ingreso de usuario ................................................................................................... 60
Tabla 14 Caso de Uso: Consultar disponibilidad ......................................................................................................... 61
Tabla 15 Caso de Uso: Consultar Usuario ................................................................................................................... 62
Tabla 16 Caso de Uso: Eliminar Usuario .................................................................................................................... 63
Tabla 17 Caso de Uso: Actualizar información ........................................................................................................... 64
Tabla 18: Caso de Uso: Configurar parqueadero ......................................................................................................... 65
Tabla 19 Caso de Uso: Registrar disponibilidad de espacio de parqueadero .............................................................. 66
Tabla 20 Caso de Uso: Notificar Alertas por horario .................................................................................................. 67
Tabla 21 Caso de Uso: Registro de Novedades por el Controlador Físico .................................................................. 68
Tabla 22 Tipos de Usuarios y Restricciones ................................................................................................................ 88
Tabla 23 Tipos de problemas de programación lineal según su tamaño .................................................................... 107
Tabla 24 Horizonte de asignación con día de no carro .............................................................................................. 108
Tabla 25 Horizonte de asignación sin restricción ...................................................................................................... 109
Tabla 26 Conjuntos de licitación de los docentes ...................................................................................................... 109
Tabla 27 Terminología utilizada en el desarrollo del modelo.................................................................................... 110
INTRODUCCIÓN
Con el avance de las TIC del País (UIT destaca avances TIC en Colombia, 2015) y de acuerdo a
Asomóvil, la empresa que reúne a todas las compañías de celular en el país, se reportó que
25.785.262 usuarios tienen internet móvil, es decir, más de la mitad de los colombianos estarían
usando un dispositivo inteligente (Semana, 2015); y lo usan para ver y enviar correos, navegar en
internet, comunicarse con otras personas, hacer transacciones (pagos de facturas, transferencias,
etc.) y saber la ubicación de las personas por medio del GPS que generalmente son usadas por
varias aplicaciones de movilidad, redes sociales y mapas.

Con el proyecto planteado “Diseño de prototipo móvil para la programación y control del
parqueadero para la universidad Distrital Francisco José de Caldas Sede Sabio Caldas”, se
pretende aprovechar el uso de la tecnología y el Smartphone de los usuarios y desarrollar una
aplicación móvil orientada a facilitar la búsqueda de disponibilidad de los espacios dentro del
parqueadero; la cual ayudaría a identificar antes de su llegada si hay cupos disponibles,
optimizando además el servicio prestado en el lugar; evitando además temas como
incumplimiento de reuniones o eventos importantes, y pérdida de tiempo al llegar al parqueadero
y tener que dirigirse a otro lugar por no contar con disponibilidad de espacios.

Por lo anterior se propone diseñar y generar un prototipo para usuarios que permita conocer la
disponibilidad que existe de espacio y tiempo; permita a los administradores del parqueadero
controlar el ingreso y salida de vehículos y la gestión de los cupos de acuerdo a la asignación de
horario definida.
PARTE I FUNDAMENTACIÓN DE LA INVESTIGACIÓN

CAPITULO 1 DESCRIPCIÓN DE LA INVESTIGACIÓN

1.1 IDENTIFICACIÓN DEL PROBLEMA

A pesar de que las TIC se convirtieron en una herramienta esencial para el desarrollo del País, y
que continuamente se está buscando que la tecnología haga parte de la vida y entorno de cada
Colombiano (MINTIC, 2015), existen aún muchos lugares, personas que están lejos de su uso.
Es el caso del área de parqueaderos, muchas empresas e instituciones importantes, ejercen su
control y gestión de manera manual.

Para constatar lo mencionado anteriormente se tiene como ejemplo la Universidad Distrital

Francisco José de Caldas Sede Sabio Caldas donde no se cuenta con un sistema tecnológico que
permita gestionar, administrar y facilitar el servicio de aparcamiento de los usuarios en el
parqueadero que tienen para su disposición. Actualmente el parqueadero es manejado
manualmente, cada usuario registrado mediante recursos físicos tiene derecho a un espacio de
parqueadero, que puede usar según el horario definido inicialmente y según disponibilidad; es
decir no es seguro que pueda encontrar un parqueadero. El registro de acceso se lleva en un cajón
cuyas divisiones representan espacios en el parqueadero, cada vez que va llegando un usuario
entrega el carnet de la universidad y a cambio se le entrega una tarjeta de cartón. Algunos
usuarios no hacen buen uso de los recursos, es decir parquean de forma incorrecta, ocupando
hasta más de un espacio. Con todo lo mencionado anteriormente y teniendo en cuenta la alta
demanda de cupos, poca oferta, y el proceso manual que tiene el parqueadero de la Universidad
no es posible llevar un control exacto de disponibilidad y buen uso, que facilite el acceso a los
usuarios de estos y que a la vez permita optimizar las actividades de administración y control del
parqueadero.
De acuerdo a lo anterior, se puede formular la siguiente pregunta de investigación “¿Cómo
mejorar el servicio de parqueadero optimizando el acceso, disponibilidad, control y tiempo de los
usuarios en el Parqueadero de la Universidad Distrital-Sede Sabio Caldas?”.
1.2 OBJETIVOS

El planteamiento del problema tomando como idea principal la gestión, disponibilidad y control
de cupos de parqueo con un prototipo como solución propuesta permite formular los siguientes
objetivos.

1.2.1 OBJETIVO GENERAL

Diseñar un prototipo móvil de software para la consulta, gestión y control en tiempo real de la
disponibilidad de cupos de los parqueadero de la Universidad Distrital Francisco José de Caldas-
Sede Sabio Caldas.

1.2.2 OBJETIVOS ESPECÍFICOS

 Definir los roles, funciones y requerimientos de los usuarios del sistema.

 Diseñar los Casos de Uso, el Modelo Entidad Relación y el Diagrama de Secuencia que
permitan definir la lógica de interacción entre actores y acciones.
 Diseñar un prototipo móvil de software, que permitirá la gestión de la disponibilidad de
cupos de parqueadero, y administración de alertas de notificación a usuarios, sobre los
eventos que pueden presentarse en relación con el uso y salida del parqueadero.
1.3 JUSTIFICACIÓN

De acuerdo a la investigación sobre el funcionamiento actual del parqueadero de la Universidad

Distrital Francisco José de Caldas sede Sabio Caldas (ver ANEXO 2) se evidencian diferentes
factores en los procesos que actualmente no están muy estructurados como lo son: el manejo
manual de los registros de los datos de gestión para determinar cupos reales y horarios; en cuanto
al ingreso de los vehículos se desconoce el tamaño de los espacios disponibles que impide la
optimización y buen uso de lugares, el control de acceso que se hace de manera manual
ocasionando que se deba validar la disponibilidad de espacios a través de una revisión personal,
así como la verificación del mal uso del espacio por algunos conductores, esto puede tardar
demasiado tiempo y generar falencias y demoras en la prestación del servicio.

El objetivo es facilitar que los usuarios que participan en el proceso puedan conocer el estado
actual del parqueadero para tomar medidas en caso de no existir un cupo y que esto no genere
demoras en las actividades agendadas.

El sistema facilitara el ingreso y la salida del personal asegurando seguridad y control en cuanto
a evitar el acceso de personas no autorizadas, asegurara el buen uso y optimización de los
procesos del servicio de parqueadero, y brindara una gran experiencia a los usuarios en cuanto al
uso del parqueadero.

1.4 HIPÓTESIS

¿Es posible desarrollar para la Universidad Distrital sede Sabio Caldas, un prototipo de
aplicación móvil de un sistema de control que garantice que un parqueadero preste un buen
servicio y permita a los usuarios conocer disponibilidad y gestión del tiempo asignado?
1.5 MARCO REFERENCIAL
En este apartado se describirán los términos, conceptos, reglamentaciones más importantes y
necesarias para el desarrollo de este proyecto, que permitirán aclarar el tema de investigación y
son el apoyo para cumplir los objetivos propuestos.

1.5.1 MARCO TEÓRICO

En el marco teórico se encontraran un conjunto de conceptos que contribuirán a la explicación

del desarrollo de este proyecto.

1.5.1.1 SISTEMAS DE CONTROL DE ACCESO

Los sistemas de control de acceso son los mecanismos que permiten a través de una
identificación que debe estar previamente identificada acceder a datos o recursos. Se encuentran
diferentes tipos de sistemas de controles de acceso los cuales se pueden usar en diferentes
entornos. Por ejemplo, están los sistemas de control de acceso por software cuando se ingresa la
contraseña para acceder al correo, también cuando se debe colocar la huella en un lector para
encender el computador. Los casos mencionados anteriormente, son ejemplos que permiten el
acceso a los datos. Teniendo en cuenta el entorno de seguridad electrónica y recursos físicos este
concepto está relacionado con la apertura de una puerta, un torniquete, el ingreso a un
parqueadero. (Villegas, 2009)

Existen diferentes tipos de sistema de control de acceso, los cuales se listan a continuación:

 Control de acceso peatonal

 Control de acceso vehicular
 Control de personal (Sandoval, 2016)

Los sistemas de control de acceso vehicular son implantados para tener el control de los
vehículos que transitan por un espacio público o privado, asegurando de esta forma el ingreso a
un lugar solo de los vehículos permitidos y restringiendo a aquellos que no estén autorizados...
(Dointech, s.f.)

1.5.1.2 TARJETAS INTELIGENTES

¿QUÉ SON?

Es bastante frecuente denominar a todas las tarjetas que poseen contactos dorados o plateados
sobre su superficie como "tarjetas inteligentes". Sin embargo, este término es bastante ambiguo y
conviene hacer una clasificación más correcta. La International Standard Organization (ISO)
prefiere usar el término "tarjeta de circuito integrado" (Integrated Circuit Card o ICC), para
referirse a todas aquellas tarjetas que posean algún dispositivo electrónico. Este circuito contiene
elementos para realizar transmisión, almacenamiento y procesamiento de datos. La transferencia
de datos puede llevarse a cabo a través de los contactos, que se encuentran en la superficie de la
tarjeta, o sin contactos por medio de campos electromagnéticos. Estas tarjetas presentan
bastantes ventajas en comparación con las de bandas magnéticas: son capaces de almacenar más
información; pueden proteger la información almacenada de posibles accesos no autorizados y
poseen una mayor resistencia al deterioro de la información almacenada. Dado que el acceso a la
información se realiza a través de un puerto serie y supervisado por el propio sistema operativo
de la tarjeta, es posible escribir datos confidenciales que no puedan ser leídos por personas no
autorizadas. En principio, las funciones de escritura, lectura y borrado de la memoria pueden ser
controladas tanto por el hardware como por el software, o por ambos a la vez. Esto permite una
gran variedad de mecanismos de seguridad. Al ser el chip integrado su componente más
importante, las tarjetas están clasificadas según el tipo de circuito. (Tarjetas Inteligentes)

Figura 1 Partes de una Tarjeta Inteligente. Tomado de (Tarjetas Inteligentes)

COMPONENTES

 RAM (Random Access Memory): Memoria de trabajo del Microprocesador, se

almacenan los datos de sesión, al ser volátil puede perder toda la información al momento
de ser desconectada de su alimentación de energía.

 ROM (Read Only Memory): Aquí se encuentra el sistema operativo, el cual es el

encargado de manejar la asignación de almacenamiento de la memoria, la protección de
accesos y las comunicaciones descartando así la posibilidad de poder introducir
externamente comandos falsos que puedan comprometer la seguridad del sistema.

 EEPROM (Electrical Erasable Progamable Read Only Memory): Memoria no volátil

que contiene todos los datos que deben permanecer en la tarjeta a lo largo de múltiples
sesiones, así como también el código de las instrucciones que están bajo el control del
sistema operativo. También puede contener información como el nombre del usuario,
número de identificación personal o PIN (Personal Identification Number).

 COPROCESADOR: Este elemento se utiliza básicamente para propósitos de

criptografía.
  CPU: Controla el funcionamiento del resto de componentes y además realiza operaciones
de cálculo.

 I/O: El puerto de Entrada/Salida normalmente consiste en un simple registro, a través del

cual la información es transferida bit a bit. (Pupiales, 2009)

CLASES DE TARJETAS INTELIGENTES

Las tarjetas inteligentes se dividen en dos grupos:

 Tarjeta Inteligente de Contacto: Estas tarjetas necesitan ser insertadas en una terminal
con lector inteligente para que, por medio de contactos, pueda ser leída. A su vez estas
pueden ser Sincrónicas y Asincrónicas.

 Tarjetas Inteligentes sin Contacto: Son similares a las de contacto en usos y funciones
pero utilizan diferentes protocolos de transmisión en capa lógica y física, no utilizan
contacto galvánico sino de interface inductiva. Poseen además del chip, una antena de la
cual se valen para realizar transacciones. Son ideales para las transacciones que tienen
que ser realizadas muy rápidamente. (Tarjetas Inteligentes)

FUNCIONAMIENTO

Las tarjetas se activan al introducirlas en un lector de tarjetas que son el dispositivo que actúa
como la interface entre el usuario y el sistema, existe una gran diversidad de lectores y sus
capacidades varían de acuerdo a las necesidades de los usuarios. Los lectores pueden ser
alámbricos, inalámbricos, con teclados, sin teclado, con pantalla o sin ella. Un contacto metálico,
un campo magnético o incluso una lectura laser, permite la transferencia de información entre el
lector y la tarjeta.
Las comunicaciones de las tarjetas inteligentes se rigen por el estándar ISO 7816/3, la tasa de
transferencia de datos es de 9600 baudios en modo asincrónico. (Pupiales, 2009)

1.5.1.3 SENSORES INFRAROJOS

¿QUE SON?

Son una tecnología que inicio en los años 90s, son aquellos que detectan la radiación emitida por
los materiales calientes y la transforman en una señal eléctrica. Para una amplia gama de
aplicaciones se utilizan ópticas que reducen el campo visual con el agregado de un valor
predeterminado de temperatura de conmutación. El sensor infrarrojo requiere de una
comunicación lineal entre transmisor y receptor, lo que hace impredecible la línea de vista para
su efectiva transmisión por lo tanto siempre será uno a uno, dejando de lado las configuraciones
punto multipunto. La velocidad de transmisión de datos, un archivo de datos de
aproximadamente unos 4Mb, puede tardar de 15 a 20 minutos pasándola por infrarrojo, este se
comunica por medio de ondas de muy alta frecuencia (similar a las ondas de radio), como las
infrarrojas, pero tienen limitaciones, como el ángulo y distancia, tienen que estar muy cerca y
casi de frente para poder que transfiera datos.

SUS APLICACIONES

Los sensores infrarrojos están diseñados especialmente para la detección, clasificación y

posicionado de objetos; la detección de formas, colores y diferencias de superficie, incluso bajo
condiciones ambientales extremas. Este componente puede tener la apariencia de un LED
normal, la diferencia radica en que la luz emitida por el no es visible para el ojo humano,
únicamente puede ser percibida por otros dispositivos electrónicos. (Tatiana Naranjo, 2009)

1.5.1.4 MICROPROCESADORES ARDUINOS

Arduino es una plataforma de prototipos electrónica de código abierto (open-source) basada en

hardware y software flexibles y fáciles de usar. Está pensado para artistas, diseñadores, como
hobby y para cualquiera interesado en crear objetos o entornos interactivos (Ingeniería MCI
Ltda, s.f.).

Arduino puede sentir el entorno mediante la recepción de entradas desde una variedad de
sensores y puede afectar a su alrededor mediante el control de luces, motores y otros artefactos.
El microcontrolador de la placa se programa usando el Arduino Programming Language (basado
en Wiring) y el Arduino Development Environment (basado en Processing). Los proyectos de
Arduino pueden ser autónomos o se pueden comunicar con software en ejecución en un
ordenador (por ejemplo con Flash, Processing, MaxMSP, etc.) (Ingeniería MCI Ltda, s.f.).

Las placas se pueden ensamblar a mano o encargarlas pre ensambladas; el software se puede
descargar gratuitamente. Los diseños de referencia del hardware (archivos CAD) están
disponibles bajo licencia open-source, por lo que eres libre de adaptarlas a tus necesidades
(Ingeniería MCI Ltda, s.f.).

Arduino recibió una mención honoríca en la sección Digital Communities del Ars Electrónica
Prix en 2006 (Ingeniería MCI Ltda, s.f.).

1.5.1.5 BASES DE DATOS

Es un sistema computarizado para llevar registros, es decir es un depósito o contenedor de una

colección de archivos de datos. Los usuarios del sistema pueden realizar una variedad de
operaciones sobre dichos archivos como (Date, 2001):
 Agregar nuevos archivos vacíos a la base de datos
 Insertar datos dentro de los archivos existentes
 Recuperar datos de los archivos
 Modificar datos
  Eliminar datos
 Eliminar archivos

1.5.1.6 PROTOTIPO

Un prototipo es un modelo experimental de un sistema o de un componente de un sistema que

tiene los suficientes elementos que permiten su uso (Garcia, 2014).

OBJETIVOS

 Son un medio eficaz para aclarar los requisitos de los usuarios e identificar las
características de un sistema que deben cambiarse o añadirse
 Mediante el prototipo se puede verificar la viabilidad del diseño de un sistema

CARACTERÍSTICAS

 Es una aplicación que funciona

 Su finalidad es probar varias suposiciones con respecto a las características requeridas
por el sistema
 Se crean con rapidez
 Evolucionan a través de un proceso iterativo
 Tienen un costo bajo de desarrollo

1.5.2 MARCO CONCEPTUAL

Para el desarrollo del sistema de control y programación para ingreso, ubicación y disponibilidad
de parqueaderos, es necesario el uso de diferentes herramientas que permitan plantear el diseño
que se quiere lograr para brindar la mejor experiencia y mejor servicio a los usuarios.

El sistema de control y programación de parqueaderos, permitirá que los usuarios conozcan antes
de llegar al lugar de aparcamiento si hay disponibilidad o no de lugares según su parametrización
(Su horario asignado, tipo de vehículo), a través de una interfaz con la visualización de los
espacios por sótano en la aplicación móvil. En segundo lugar ayudara a la administración del
parqueadero, mediante la parametrización de la distribución física de este, y el control de
novedades a través de alertas generadas en la aplicación móvil, para conseguir un buen uso del
lugar.

La gestión de la Base de datos permitirá registrar la información de los usuarios del parqueadero,
teniendo acceso a los datos relevantes que apoyaran los procesos de ingreso, control y
administración del parqueadero. Los datos registrados son: Cedula, Nombres, apellidos, tipo
usuario, tipo de vehículo, marca, placa, celular, email. Este registro es diseñado en el motor de
Base de datos Oracle 11g, que permitirá almacenar la información necesaria para ejecutar los
procesos del sistema.
El uso de sensores infrarrojos y micro controladores arduino en los espacios del parqueadero
facilita la visualización de disponibilidad en la aplicación móvil, que tendrá a través de un
WebServices la información de si está o no ocupado el lugar. A través de las interfaces para cada
rol (Usuario, Administrador del Sistema y Controlador Físico) se pueden gestionar las
notificaciones que le llegaran a cada usuario para conseguir un uso óptimo del lugar en tiempo
real.

La tarjeta inteligente es la encargada de consultar y validar la informacion registrada en la Base

de datos, para permitir el acceso al parqueadero de cada usuario según los datos almacenados y
la disponibilidad que previamente debio mostrar la aplicación movil, a partir de la informacion
que recibio del Webservices que lleva el mensaje del sensor infrarrojo y el arduino.

1.5.3 ASPECTOS LEGALES

El escenario en el cual se desarrollará el prototipo corresponde al parqueadero de la sede Calle

40 de la universidad distrital “Francisco José de Caldas”, en consecuencia, se deben tener en
cuenta los estatutos emitidos por la Universidad y las disposiciones contenidas en ellos, en
principio se aborda la Resolución 107 del 26 de marzo de 1999 (Universidad Distrital
"Francisco José de Caldas", 1999) "Por la cual se adopta la Planta Global del Personal
Administrativo a la nueva nomenclatura y clasificación de empleos establecida para el orden de
las entidades territoriales reguladas por las disposiciones de la Ley 443 del 12 de Junio de
1998.", y la Resolucion 1101 del 29 de julio de 2002 (Universidad Distrital "Francisco José de
Caldas", 2002) “Por la cual se establece el Manual Descriptivo de Funciones Generales y
específicas y los Requisitos Mínimos para los cargos de Planta de Personal Administrativo de la
Universidad Distrital Francisco José de Caldas”, en ellas se encuentra asignada la
responsabilidad de la administración del parqueadero de la sede calle 40 a la División de
Recursos Físicos en cabeza de la Vicerrectoría Administrativa.

La universidad emite la resolucion de rectoría No 206 del 23 de marzo de 2010 (Universidad

Distrital "Francisco José de Caldas", 2010)“Por medio de la cual se reglamenta la prestación del
servicio y el uso de los parqueaderos de la Universidad Distrital Francisco José de Caldas” aquí
son consignados los requisitos, prioridades, prohibiciones y credenciales de uso de los
parqueaderos de la Universidad.

Los parqueaderos de la universidad al estar ubicados en la ciudad de bogota y como entidad del
distrito adoptan una serie de normas dispuestas por la alcaldía mayor entre las que podemos
encontrar el Decreto 321 del 29 de mayo de 1992 (BOGOTA, 1992) “por el cual se dictan
normas generales para los Estacionamientos de servicio al público, tal como lo establece el
literal B del Artículo 460 del Acuerdo 6 de 1990.” en su SUBCAPÍTULO II “Condiciones
urbano - arquitectónicas y técnicas de los estacionamientos” se definen las dimensiones mínimas
de uso institucional, los estacionamientos para minusválidos, zonas de maniobra, las condiciones
de pavimento o asfaltado del piso, ancho mínimo de los garajes y condiciones especiales en el
uso de estos, altura mínima, entre otros.
El Ministerio de Transporte a través de su Decreto número 1660 del 16 de junio 2003 “Por el
cual se reglamenta la accesibilidad a los modos de transporte de la población en general y en
especial de las personas con discapacidad” establece la demarcación y sitios especiales de zonas
de parqueo en las que se rige por los estándares nacionales dispuestos para tal fin como la norma
NTC 4139 de simbología y la norma NTC 4904 de accesibilidad al medio.

En la actualidad bajó la alcaldía de Enrique Peñalosa se ha emitido la Directiva 002 del 04 de

febrero de 2016 que bajo el plan maestro de movilidad busca priorizar los modos de transporte
sostenibles como el transporte público y los no motorizados (peatonal o bicicleta), fomentando
entre los ciudadanos el cambio en su hábitos de desplazamiento, así como la implementación en
los organismos distritales (que incluye a la Universidad) del no uso del vehículo el primer jueves
de cada mes. Disposiciones que repercuten en el diseño de prototipo en el manejo de sus
restricciones.

1.6 METODOLOGÍA
A continuación se describen cada una de las técnicas metodológicas que se utilizaran para el
desarrollo de este proyecto.

1.6.1 LEVANTAMIENTO DE INFORMACION

Para realizar el levantamiento de información para este proyecto se basara en el método

hipotético deductivo, de manera que se identifique una hipótesis que fundamente y explique el
problema encontrado a través de la previa investigación del objeto de estudio.
Es necesario realizar inicialmente una investigación del funcionamiento actual del parqueadero
de la UD, para poder percibir y determinar las diferentes necesidades que suplirá y beneficios
que aportara el sistema a los usuarios y clientes finales.

1.6.2 DISEÑO

Bajo el lenguaje grafico UML se especificará y documentará el sistema a través de Casos de

Uso, Modelo entidad-Relación y Diagrama de Secuencia y a partir de esto se diseña el prototipo.

1.6.3 DESARROLLO DEL PROTOTIPO

En el mercado se encuentran muchas metodologías o elementos de trabajo usados para el

desarrollo de productos informáticos, cada una con sus ventajas y desventajas que permiten a los
usuarios seleccionarlas a partir de las necesidades de cada proyecto. Una de las más usadas y
preferidas actualmente es Scrum, que para el caso del proyecto se ajusta correctamente por ser
una metodología de desarrollo ágil donde se verán los resultados en poco tiempo y facilita la
entrega de productos de calidad a tiempo.
1.7 ORGANIZACIÓN DEL TRABAJO
El plan de trabajo de este proyecto se describe a continuación:

PARTE I

1. CAPITULO 1
Presenta la fundamentación de la investigación, se describe la problemática detectada en el
parqueadero de la Universidad Distrital Francisco José de Caldas – sede Sabio Caldas

PARTE II

2. CAPITULO 2
Se definen más a fondo cada uno de los componentes que se aplican al desarrollo del
proyecto.

3. CAPITULO 3
En esta capitulo se describe la solución propuesta, junto con cada uno de sus componentes.

4. CAPITULO 4
En este capítulo se muestra el desarrollo del primer objetivo específico, el cual comprende la
definición de los roles y sus funciones; y la definición de los requerimientos de los usuarios
del sistema.

5. CAPITULO 5
En este capítulo se muestra el desarrollo del segundo objetivo específico, el cual comprende
los diagramas y definiciones de los casos de uso, el diseño del modelo de base de datos y el
modelo de secuencia.

6. CAPITULO 6
En este capítulo se muestra el desarrollo del segundo objetivo específico, el cual comprende el
desarrollo del diseño del prototipo de software que permitirá validar la disponibilidad.

PARTE III

7. CAPITULO 7
En este capítulo se encuentran los resultados del desarrollo del proyecto.

8. CAPITULO 8
Este capítulo comprende las conclusiones del proyecto desarrollado; donde se expone la
verificación, contraste y evaluación de los objetivos, síntesis del modelo propuesto, aportes
originales y trabajos o publicaciones derivadas.

9. CAPITULO 9
En este capítulo se exponen líneas de investigación futuras o trabajos que se puedan llegar
hacer para complementar o alimentar la solución de esta propuesta.
1.8 ESTADO DEL ARTE

1.8.1. SISTEMA PARA LA ADMINISTRACIÓN DE UN ESTACIONAMIENTO

PÚBLICO

En este proyecto desarrollado por Francisco Luna para la Universidad Nacional Autónoma de
México se expone la problemática de encontrar de manera rápida un lugar donde estacionar un
vehículo en la ciudad. El motivo para la realización del sistema para la administración de un
estacionamiento público se basa en la falta de organización para la asignación de un espacio; la
forma de vida es más rápida en la ciudad de manera subsecuente la necesidad de conseguir un
lugar seguro y rápido para que el conductor pueda realizar sus posteriores actividades aumenta
(LUZ, 2013).

La propuesta de desarrollo establece un modelado del sistema, implementación de una base de

datos y el desarrollo de un prototipo.

Para el modelado del sistema se generan los diagramas de casos de uso, modelo de datos, entidad
relación, clases y un diccionario de datos; se implementa una base de datos PostgreSQL 8.2.4 en
Windows donde se crean las tablas siguiendo un modelo relacional que permitan almacenar la
información con un mínimo de redundancia, pero que a la vez faciliten la recuperación de la
información; y posterior a esto para el diseño de a interfaz se trabaja con una estructura
jerárquica previamente definida, se trabaja con proveedor de datos Npgsq permite una
implementación de código abierto de un proveedor de datos .NET para C# y proporciona una
interfaz directa con el protocolo de red que utiliza PostgreSQL. Permite el acceso a bases de
datos PostgreSQL, tanto local como a través de la red. Puede soportar todo tipo de proyectos,
desde consola hasta Windows Forms.

La interfaz del sistema se desarrolló en Visual C#, para operar en ambiente Windows, funciona
por medio de una serie de ventanas, menús y submenús que facilita la operación del mismo;
cuenta con una ventana Login de Usuario, que posterior a la validación de datos despliega el
menú principal que cuenta con varias ventanas con las que se realizan distintas funciones en los
sistemas, como registro de vehículos al accesar al estacionamiento, la administración de clientes,
la administración de empleados, entre otros.

En este proyecto se evidencia que el control está determinado solo para los administradores del
parqueadero y el control de reportes y cifras; pero el usuario o cliente de estos establecimientos
no cuentan con una opción adicional que les permita conocer desde fuera del lugar la
disponibilidad.
1.8.2. A DECISIÓN SUPPORT SYSTEM FOR PARKING SPACE ASSIGNMENT

Este trabajo describe un sistema de soporte de decisiones basado en red de una forma generar
para la asignación de plazas o lugares de parqueo, un sistema de optimización integrado
generado bajo un modelo de optimización y que genera reportes, el problema se modela como
una red de asignación que reduce al mínimo los valores de preferencia que se encuentran en
función de la distancia, costo y prioridad, la metodología que se presenta puede ser aplicada a
una variedad de situaciones de asignación donde hay objetivos contrapuestos. Dado que el
enfoque se basa en un algoritmo de red, es capaz de resolver sistemas muy grandes de manera
eficiente, el escenario de prueba corresponde a un conjunto de apartamentos llamados Dunhill en
Bloomington, Indiana, Estados Unidos. El sistema puede ser utilizado en escala para varios
edificios y lotes de parqueo (VENKATARAMANAN & BORNSTEIN, 1991).

El problema consistía en que apartamentos Dunhill tenía 11 edificios y lotes de parqueo

distribuidos a lo largo del complejo, la escasez de lugares se debía a que personas ajenas al
complejo de apartamentos usaban los lugares lo que llevo a la administración a emitir permisos
de parqueo, sin embargo, el problema ahora era distribuir estos permisos de manera eficiente,
una vez analizado el problema se dio a la tarea de diseñar un sistema de toma de decisiones
(VENKATARAMANAN & BORNSTEIN, 1991).

El problema es modelado como un problema de red, identificando los nodos de suministro

(apartamentos) y los nodos de demanda (lotes de aparcamiento), los enlaces entre nodos o arcos
corresponden a los permisos emitidos por apartamento y bajo una prioridad, se establece la
función objetivo como la suma ponderada de prioridad, costo y distancia, los cuales
corresponden a objetivos en competencia y las asignaciones de peso de estos objetivos pueden
ser alternadas. (Véase Figura 2)

Figura 2 Modelo de red para la asignación de parqueaderos. Tomado de (VENKATARAMANAN

& BORNSTEIN, 1991)
Este artículo nos sirve de ejemplo de cómo modelar matemáticamente el problema que tenemos
para la Universidad Distrital teniendo en cuenta los parámetros de designación que establezca la
universidad y a la vez cómo este modelo puede extrapolarse en función de la asignación de
lugares de parqueo en otro tipo de organización.

Finalmente se quiere a llegar a diseñar y desarrollar un sistema de apoyo a la toma de decisiones

con los elementos de generador de problemas, optimizador y generador de informes, tal como se
muestra en la Figura 3

Figura 3 Sistema de soporte de decisiones para la asignación de parqueaderos. Tomado de (VENKATARAMANAN &
BORNSTEIN, 1991)

El sistema puede ser desarrollado en cualquier lenguaje de programación e implementado en

cualquier plataforma.

1.8.3. SCHEDULING ALGORITHMS FOR PHEV CHARGING IN SHARED PARKING LOTS

Se presenta un trabajo enfocado en la entrada de vehículos eléctricos al parque automotor y su

impacto en los parqueaderos de abastecimiento de carga, los denominados Vehículos eléctricos
híbridos enchufables (PHVE) por sus siglas en inglés, harán que la infraestructura pública o
sitios públicos de parqueo y carga consideren diseñar sistemas de asignación de lugar y tiempos
de carga, sitios tales como estacionamientos compartidos en los campus de oficinas comerciales
y centros comerciales, para los PHVE la demanda de carga puede variar de manera significativa
y estocásticamente con el tiempo, y el rendimiento general del sistema es un compromiso entre la
carga máxima en el sistema de distribución y las fechas límite de consumo específicas, se
considera el diseño de algoritmos de programación para optimizar el rendimiento del sistema. Se
demuestra que mediante un diseño adecuado de los algoritmos de planificación, el propietario del
estacionamiento puede equilibrar la carga del sistema de distribución y la calidad de servicio de
carga (Huang, Gupta, & Huang, 2012).

El problema aquí definido consiste en considerar un estacionamiento que posee varios lugares de
parqueo tal como se muestra en la figura X, cada lugar equipado con un medidor de carga que
los clientes pueden conectar a sus PHEV, además, los consumidores pueden introducir
información tal como fecha límite de salida, cantidad deseada de carga y la velocidad de carga
preferida.

Figura 4 Arquitectura del sistema de carga de PHEV. Tomado de (Huang, Gupta, & Huang, 2012)

El propietario del parqueadero, o el servicio proveedor, puede diseñar un controlador

centralizado para programar la carga de cada PHEV. El controlador tiene dos prestaciones
métricas:

 Debido a las preocupaciones económicas y de hardware, el número de los PHEV que se

pueden cargar al mismo tiempo (es decir, el carga pico) debe reducirse al mínimo.

 Para satisfacer la demanda de los clientes, el número de los PHEV que pierden su fecha
límite de carga (es decir, no son totalmente cargados al nivel solicitado por el cliente
hasta la fecha límite de salida respectiva) debe ser minimizado.

Desde la llegada del PHEV ya es un proceso estocástico, existe un claro compromiso entre las
dos métricas de rendimiento. Un problema relevante de optimización para diseñar el controlador
por lo tanto puede ser la de reducir al mínimo la probabilidad de que un vehículo le falte carga
sujeta a una restricción en la carga pico. En consecuencia, se plantea este problema
matemáticamente y, a se ofrece un análisis de los controladores para resolver este problema. Por
simplicidad, se supone que al menos un PHEV está completamente cargado hasta su plazo, se
cuenta como un plazo incumplido.

Este trabajo a diferencia del mencionado en el apartado anterior (1.8.2) involucra un mayor
grado de incertidumbre en sus variables asociadas, el tratamiento del modelo matemático y del
diseño del sistema es diferente, aquí se busca compararnos con otros sistemas analizados y
diseñados con el fin de encontrar la mejor solución en diseño e implementación para la
programación y control de sitios de parqueo tomando como escenario inicial el parqueadero de
la universidad distrital “Francisco José de Caldas”.
 PARTE II FUNDAMENTACIÓN DE LA INVESTIGACIÓN

CAPITULO 2 DESCRIPCIÓN DE LA INVESTIGACIÓN

En este capítulo se desglosan a más alto nivel cada uno de los conceptos necesarios para definir y
diseñar la solución al problema planteado en la parte I.

2.1 TEMAS DE CONTROL DE ACCESO CON TARJETAS INTELIGENTES

Para los autores en (OCDE, 2015), NFC (siglas de Near Field Communication) consiste en:

Es una tecnología bidireccional diseñada con fines de interacción, para realizar pagos o entrar a un edificio. Su
funcionamiento requiere que dos dispositivos con NFC se encuentren muy cerca uno del otro. Se integra
con tarjetas magnéticas de acceso a edificios o al transporte público. Se está extendiendo a los pagos sin
contacto, y cada vez más bancos introducen tarjetas de crédito y débito con NFC

Las características básicas del sistema NFC según los autores en (INTECO, 2004) son las
siguientes:

 Comunicación inalámbrica por proximidad: Este tipo de comunicación, similar al de otras tecnologías como
tarjetas de inteligentes, se realiza usando inducción electromagnética. Los dispositivos compatibles con NFC
deben contar con una pequeña antena en espiral que genera un campo electromagnético de radiofrecuencia.
Cuando un dispositivo entra en el campo electromagnético de otro, puede establecerse la comunicación. El
alcance del campo electromagnético para la tecnología NFC es muy pequeño, pudiendo ser en teoría de entre
10 y 20 centímetros pero aplicándose en la práctica una distancia de 4 centímetros o inferior. Esto provoca que
los dispositivos necesiten casi entrar en contacto físico para poder comunicarse.

 Pequeñas transacciones de datos: Los dispositivos NFC se pueden comunicar con cuatro velocidades de
comunicación de datos: 106, 212, 424 o 848 Kbit/s, aunque esta última no está reflejada en ISO/IEC 18092.
Esta limitación se debe a que la tecnología NFC no está orientada a la transmisión masiva de datos, sino a
pequeñas comunicaciones entre dispositivos. Sólo se permiten velocidades mayores, del orden de 6,78 Mbit/s,
en la comunicación entre dos dispositivos orientada al intercambio masivo de datos.

 Operaciones en la frecuencia ISM: En las transmisiones de dispositivos NFC se utiliza la banda de frecuencia
alojada en los 13,56 Mhz, tradicionalmente asignada a las etiquetas RFID en modo pasivo (como etiquetas de
identificación de productos farmacéuticos, documentos de identidad, etc.). Esta frecuencia pertenece al
conjunto de bandas de radio ISM, que son utilizadas generalmente con fines industriales, científicos y médicos
(de ahí su nombre ISM, Industrial, Scientific and Medical). Para el uso de estas bandas no es necesaria una
licencia, pero se debe garantizar que no se produzcan interferencias entre los dispositivos. Esto representa una
ventaja para la implantación y uso de NFC, ya que el canal de trasmisión es libre y no tiene un coste de uso
asociado. Otros sistemas que también utilizan estas bandas de frecuencia son, por ejemplo, Bluetooth y Wi-Fi.

Modo peer-to-peer

La modalidad peer-to-peer permite a dos dispositivos NFC comunicarse entre ellos para intercambiar información y
compartir ficheros. Los usuarios de dispositivos NFC pueden compartir información y otros ficheros
fácilmente, con un simple toque o aproximación. Dos dispositivos NFC crean una conexión para
intercambiar información de forma activa. Cuando se intercambian información, ésta se envía por un canal
de comunicaciones bidireccional half-duplex (cuando un dispositivo transmite, el otro debe escuchar, y
puede iniciar una transmisión sólo cuando el primero ha terminado). La velocidad máxima de transmisión
 de datos es 424 kbps. La arquitectura de esta modalidad está resumida en el siguiente esquema (Vilanoveta,
2015):

Figura 5 Arquitectura Peer to Peer NFC. Tomado de (Vilanoveta, 2015)

Etiquetas NFC

Las etiquetas NFC son pequeños dispositivos NFC pasivos que pueden contener fragmentos de información.
Básicamente se trata de pequeñas espirales de metal a las que se les añaden componentes de memoria y
comunicación. Su diseño completamente plano las hace ideales para presentarse en formatos como
pegatinas, tarjetas de visita, llaveros e incluso pulseras. Su funcionamiento es parecido al de los códigos de
barras y de los códigos QR, sin la necesidad del reconocimiento óptico del código. Así, un dispositivo NFC
activo (incorporado en un teléfono inteligente, por ejemplo) actúa como lector. Al acercarlo a una etiqueta
NFC, el campo de radiofrecuencia que el lector aplica sobre la etiqueta la activa y hace que le transmita los
datos que almacena en su interior. Estos datos dependerán, entre otros factores, del tipo de etiqueta NFC, ya
que existen varias clases en función de su memoria, su tasa de transferencia de datos y los modos de
interacción (INTECO, 2004).

Figura 6 Tipos Etiquetas NFC. Tomado de (INTECO, 2004)

2.2 MANEJO DE LA DISPONIBILIDAD CON SENSORES INFRAROJOS Y

MICROPROCESADROES ARDUINOS

Según el autor (Torrente Artero, 2013) Arduino es en realidad tres cosas:

 Una placa hardware libre que incorpora un microcontrolador reprogramable y una serie de pines-hembra
(los cuales están unidos internamente a los pines de E/S del microcontrolador) que permiten conectar allí
de forma muy sencilla y cómoda diferentes sensores y actuadores.

Cuando se habla de “placa hardware” nos estamos refiriendo en concreto a una PCB (del inglés “printed circuit
board”, o sea, placa de circuito impreso). Las PCBs son superficies fabricadas de un material no conductor
 (normalmente resinas de fibra de vidrio reforzada, cerámica o plástica) sobre las cuales aparecen laminadas
(“pegadas”) pistas de material conductor (generalmente cobre). Las PCBs se utiliza para conectar
eléctricamente, a través de los caminos conductores, diferentes componentes electrónicos soldados a ella.
Una PCB es la forma más compacta y estable de construir un circuito electrónico (en contraposición a una
breadboard, perfboard o similar) pero, al contrario que estas, una vez fabricada, su diseño es bastante
difícil de modificar. Así pues, la placa Arduino no es más que una PCB que implementa un determinado
diseño de circuitería interna.

 Un software (más en concreto, un “entorno de desarrollo”) gratis, libre y multiplataforma (ya que funciona
en Linux, MacOS y Windows) que se debe instalar en el ordenador y que permite escribir, verificar y
guardar (“cargar”) en la memoria del microcontrolador de la placa Arduino el conjunto de instrucciones
que se desea que este empiece a ejecutar. Es decir: permite programarlo. La manera estándar de conectar
un computador con la placa Arduino para poder enviarle y grabarle dichas instrucciones es mediante un
simple cable USB, gracias a que la mayoría de placas Arduino incorporan un conector de este tipo.

 Un lenguaje de programación libre. Por “lenguaje de programación” se entiende cualquier idioma

artificial diseñado para expresar instrucciones (siguiendo unas determinadas reglas sintácticas) que pueden
ser llevadas a cabo por máquinas. Concretamente dentro del lenguaje Arduino, se encuentran elementos
parecidos a muchos otros lenguajes de programación existentes (como los bloques condicionales, los
bloques repetitivos, las variables, etc.), así como también diferentes comandos –asimismo llamados
“órdenes” o “funciones” – que permiten especificar de una forma coherente y sin errores las instrucciones
exactas que programar en el microcontrolador de la placa. Estos comandos se escriben mediante el entorno
de desarrollo Arduino.

Arduino se considera Software libre porque se publica con una combinación de la licencia GPL (para el entorno
visual de programación propiamente dicho) y la licencia LGPL (para los códigos fuente de gestión y
control del microcontrolador a nivel más interno) y Hardware libre porque sus ficheros esquemáticos están
disponibles para descargar de la página web del proyecto con la licencia Creative Commons Attribution
Share-Alike (http://es.creativecommons.org/licencia), la cual es una licencia libre que permite realizar
trabajos derivados tanto personales como comerciales (siempre que estos den crédito a Arduino y
publiquen sus diseños bajo la misma licencia).

La elección de Arduino para el elemento de diseño del sistema de sensores con luz infrarroja
obedece a sus ventajas integradas en cuanto a Hardware y Software entre las que podemos
mencionar que Arduino es libre y extensible, es decir, que cualquiera que desee ampliar y
mejorar tanto el diseño hardware de las placas como el entorno de desarrollo software y el propio
lenguaje de programación, puede hacerlo sin problemas. Arduino tiene una gran comunidad,
muchas personas lo utilizan, enriquecen la documentación y comparten continuamente sus ideas,
su entorno de programación es multiplataforma, Su entorno y el lenguaje de programación son
simples y claros, son económicas, reutilizables y versátiles (Torrente Artero, 2013)

Para efectos del presente estudio se propone utilizar sensores de presencia con luz infrarroja, en
donde se detecta la existencia o no de un obstáculo (automóvil, moto, bicicleta) en un rango de
distancia, por lo cual en el mercado existe gran variedad de dispositivos siendo los de luz
infrarroja los que mejor se adaptan a las condiciones de los subsótanos que componen el
parqueadero de la universidad, Funcionan emitiendo un haz infrarrojo y comprobando si le llega
rebotado. Si es así, el sensor generará una señal LOW (que podrá ser leída por una placa Arduino
conectada a él convenientemente) y si no se detecta ningún objeto, el sensor generará una señal
HIGH. Cuanta más distancia tenga el obstáculo, menos voltaje de salida obtendremos del sensor,
por mencionar lagunas referencias en el mercado se encuentra la gama de sensores IS471F,
QRD114, QRE1113 o los PIR que involucran sensores piroeléctricos de infrarrojos, el principio
consiste en que las personas o vehículos emiten radiación infrarroja, así, en cuanto más caliente
se encuentra un objeto más radiación de este tipo es emitida (Torrente Artero, 2013)

La información emitida por el sensor será almacenada en la base de datos del sistema que a su
vez es tomada como información de restricción para el modelo de asignación.

2.3 WEBSERVICES

Los autores (Ribas Lequerica, 2003) y (Baltopoulos, 2005) explican los servicios web de la
siguiente manera:

Los Web Services surgen como una solución a problemas de comunicación entre un grupo de
sistemas de información cada vez más variados y dispersos en cuanto a su ubicación geográfica,
permitiendo estos una rápida adaptación a los cambios de estrategias empresariales, debido a su
fácil integración e independencia de la plataforma y/ o entorno que lo contiene. Con la evolución
de internet el panorama de implementación de esta tecnología crece exponencialmente así como
el desarrollo modular que ofrece la programación orientada a objetos, mediante la utilización de
estos objetos, es posible abstraer la lógica que se encierra en ellos para ser tratados como código
independiente capaz de realizar tareas específicas y pudiendo ser llamados desde cualquier parte
del programa, permitiendo su reutilización y un fácil mantenimiento y reutilización (Ribas
Lequerica, 2003).

Una definición concreta diría que un Web Service es una interfaz, accesible por protocolos
(estándar o no) usado en internet o en un canal de comunicaciones que permite acceder a las
funcionalidades de un objeto concreto, sin importar las tecnologías ni plataformas implicadas en
la petición. Un Web Service es una parte lógica de negocio, capaz de procesar y accesible desde
cualquier lugar, por cualquier persona al que se la haya otorgado los permisos suficientes y
necesarios, a través de cualquier medio, siendo más explícitos un Web Service es una interface
hacia una aplicación o proceso accesible vía red de datos mediante cualquier tipo de tecnología
orientada a internet (Ribas Lequerica, 2003).

El Web Service se pone entre el usuario y el código usado, se encargará de abstraer las
especificaciones técnicas del programa que atenderá la petición para que cualquier lenguaje de
programación que tenga soporte web Service tenga acceso a nuestro programa. Esta abstracción
nos permite usar los web Services en transacciones Bussiness to Bussiness, Peer to Peer,
pudiendo ser, por ejemplo, el elemento cliente una persona, otro Web Service o un programa, se
podría decir, haciendo una analogía, que los Web Services son para el software como el Plug &
Play para el hardware (Ribas Lequerica, 2003).
 Canal de
Proceso
•Persona comunicaciones •XML
•Web Service •Internet •SOAP •Insert
•Programa •Red de datos •WSDL •Execute
•UDDI •Update

Cliente Web Service

Figura 7 Esquema del Web Service. Modificado de (Ribas Lequerica, 2003)

En los Web Services los beneficios están dados entre otros por la independencia de la existencia
de cada servicio con los demás que componen la aplicación los cuales pueden ser modificados
sin afectar áreas no relacionadas, la facilidad de integración, los datos del sistema son aislados
mediante la creación de “silos” para los cuales el Web Service actúa como una unión entre ellos
permitiendo la fácil comunicación entre y a través de las organizaciones, la reutilización de
servicios, existen funciones específicas que son utilizadas una y otra vez por las aplicaciones del
sistema. El más simple sistema de Web Service tiene dos participantes: un productor de servicios
(proveedor) y un consumidor de servicios (solicitante) en dónde el proveedor presenta la interfaz
y la aplicación del servicio y el solicitante utiliza el Web Service (Baltopoulos, 2005).

solicitante Enlace Proveedor

Figura 8 Sistema básico de un Web Service. Modificado de (Ribas Lequerica, 2003)

Un sistema más sofisticado contiene: un registro que actúa como un corredor de Web Services,
un proveedor quien publica servicios para el registro y un consumidor que consulta los servicios
en el registro (Baltopoulos, 2005).

Registro

Solicitante Proveedor

Figura 9 Representación de un sistema más sofisticado de Web Service. Modificado de (Ribas Lequerica, 2003)
 En lo que refiere a la topología de los Web Services, sabemos que su entorno es gestionado por
mensajes, por lo que se darán constantes acciones de envío y recibo de estos mensajes. En una
acción de petición (respuesta de un Web Service), pueden intervenir desde una sola máquina
hasta N máquinas que existan conectadas en la red, toda vez que el Web Service no tiene por qué
ser invocado directamente, esto puede ser en cascada, máquina a máquina, hasta que el servicio
sea activado y así su camino de respuesta, camino que puede ser configurado de tal manera que
siga una línea de retorno específica, de esta manera, se puede hablar entonces del tipo de
máquina que afecta el funcionamiento del Web Service, siendo estos: la que realiza la búsqueda
y petición del Web Service, la que responde a la búsqueda y la que responde al servicio
cumpliéndose la representación o arquitectura de la Figura 9. (Ribas Lequerica, 2003)

Ahora bien, para que el proceso del Web Service se cumpla a cabalidad se requiere mantener una
coherencia entre los datos recibidos y los datos emitidos teniendo en cuenta que estos pueden ser
de sistemas diferentes, entonces, se deben seguir unas normas tanto para codificación como
transporte. Todos los intercambios de mensajes se realizan de tal manera que sean compatibles
para todos los sistemas, mediante mensajes de tipo texto, para hacer la petición a un Web Service
se utiliza un mensaje y la respuesta se dará de la misma forma, es decir, mediante otro mensaje,
dadas estas condiciones se puede tratar la interface de comunicaciones como un entorno de
trabajo orientado a mensajes sin importar la localización física del destinatario, tampoco la
tecnología usada en el elemento que responda a la petición (Ribas Lequerica, 2003).

Debe existir un lenguaje o estándar que cumpla o garantice las políticas mencionadas, es aquí
donde le damos la bienvenida al lenguaje extensible de etiquetas o XML (extensible Markup
Language) el cual no es solamente de vital importancia para los Web Services sino que ha sido
implementado como estándar en muchas aplicaciones por ser de fácil interpretación e integrable,
este lenguaje de marcas (o etiquetas) basado en texto plano (sin formato), esto es, el significado o
interpretación de cada parte del documento depende de la posición que ocupan sus etiquetas. En
cuanto a los protocolos de red utilizados, no existe una limitación física que prohíba usar alguno
de ellos debe estar claro que cliente y servicio deben utilizar el mismo protocolo para el paso de
mensajería para evitar la respuesta nula a las peticiones. En el momento de construir los
mensajes a emitirse se debe tener en cuenta el método de codificación de los datos, con la
naturaleza de tipo texto del mensaje y además que no todos los datos aplicados son de este tipo,
es así como de alguna manera debe controlarse la transformación entre el dato del mensaje a
transmitir o recibir y el código de la aplicación que lo gestione, para esto existe SOAP (Simple
Object Access Protocol) que actúa como una especie de plantilla para generar los mensajes entre
cliente y Web Service, para codificar las peticiones y las respuestas, además marcará el modo en
el que cliente y servicio se hablarán (Ribas Lequerica, 2003).

En los Web Services los lenguajes o protocolos que son usados principalmente son (Ribas
Lequerica, 2003):

 SOAP (Simple Object Access Protocol)

 WSDL (Web Services Description Language)
 UDDI (Universal Description Discovery and Integration) o WSIL (Web Service
Inspection Language)
  WS-Routing, Enrutamiento
 WS-Security, Seguridad
 Coordinación y Transacciones entre Web Services

2.4 ARQUITECTURA

El diseño del prototipo se construye basados en la Arquitectura de Tres Capas: Capa de

Presentación, Capa Lógica o de Negocio y Capa de Persistencia o de Datos; cuyo objetivo es
separar las responsabilidades relacionadas entre sí. Cada capa como tal es simplemente una
agrupación lógica de los componentes de hardware y software que conforman el prototipo,
ayudan a diferenciar entre los distintos tipos de tareas que realizan los componentes, facilitando
su reutilización en la solución.

La Capa de Datos de la aplicación es la encargada de almacenar de manera permanente la

información obtenida de las características del parqueadero, su estado, lectura de los sensores,
características de los usuarios e información obtenidas de otros sistemas de información,
apoyando a la Capa de Negocio mediante procedimientos almacenados. Esta capa incluye el
modelo de optimización propuesto.

La Capa de Negocio encapsula la lógica e implementación de las reglas de negocio,

consideraciones de diseño y restricciones. Esta capa es la responsable de contener los
componentes de entidades del prototipo, que representan objetos que van a ser manejados o
consumidos por la aplicación. Incluye también otros tipos de objetos responsables de acceder a la
base de datos cuando sea necesario, manejo de excepciones o Webservice.

La Capa de Presentación ofrece una interfaz de aplicación móvil para el acceso a los usuarios
finales. Brinda al usuario la posibilidad de acceder a la funcionalidad implementada por el
prototipo utilizando un Smartphone, Tablet o dispositivo móvil. Con esta interfaz, el usuario
puede ingresar desde cualquier dispositivo móvil a través de Internet, a cada una de las opciones
asociadas al rol desempeñado dentro del prototipo, sea este usuario del parqueadero,
administrador o controlador físico.

Entre las ventajas de esta arquitectura, se puede mencionar que el desarrollo se puede llevar a
cabo por niveles, ante la eventualidad de un cambio sólo se involucra al nivel requerido sin tener
que hacer revisiones entre código. Cada nivel puede estar en un servidor diferente y ser
intervenido por equipos de trabajo independientes, siempre y cuando se mantenga las interfaces
y/o condiciones definidas.

La siguiente Figura muestra el modelo de capas de la aplicación con el esquema de

comunicación entre estas representado con flechas bidireccionales.
 CAPA DE PRESENTACIÓN
Interfaz Web App

CAPA DE NEGOCIO

Acceso a Datos Auditoría Manejo de

Cadena Lógica de
excepciones
Negocio Arquitectura Base

CAPA DE DATOS

Webservices

Figura 10 Arquitectura del prototipo

La Figura 10 muestra la funcionalidad de cada capa y la comunicación que existe entre ellas
teniendo en cuenta que las capas superiores utilizan los servicios de las capas inferiores y en
donde los usuarios finales del prototipo acceden únicamente a la capa de presentación, mediante
las interfaces creadas para el acceso, consulta, gestión y administración del prototipo.

2.4.1 ARQUITECTURA LÓGICA

Una forma que ha tenido buen recibimiento dentro del diseño de aplicaciones distribuidas es
dividirla en componentes que ofrezcan servicios de presentación, reglas de negocio y de datos.
En el prototipo, los componentes que realizan tipos de funciones similares se pueden agrupar en
capas, que en varios casos están organizados en forma de pila para que los componentes que se
encuentran en un nivel superior de una capa determinada utilicen los servicios proporcionados
por ésta, y un componente especifico utilizará la funcionalidad proporcionada por otros
componentes de su propia capa y otras capas en un nivel inferior para ejecutarse.
En la Figura 11 observamos el modelo lógico del prototipo, en general, los componentes
generales de cada capa, la interacción entre estas y los actores involucrados con el sistema.

Usuarios

Controlador Físico
Administrador
Usuario

CAPA DE PRESENTACIÓN

Componentes de
Interfaz de Usuario Web Componentes de Proceso

CAPA DE NEGOCIO
Funcionalidad

Componentes de Negocio

Lógica de consulta
Lógica de gestión

Componente Lógico de Acceso a Datos

CAPA DE DATOS

BD
parqueadero

Figura 11 Modelo Lógico del Prototipo

2.4.2 ARQUITECTURA FÍSICA

Para entender la arquitectura física, se debe analizar dos segmentos de este ítem, entonces, se
presenta a continuación la Infraestructura Física y el Diagrama de Despliegue del Prototipo.
2.4.2.1 Infraestructura o modelo físico

La estructura de Servidores del Prototipo se encuentra ligada conforme se definió anteriormente,

la arquitectura tres capas de la siguiente manera: un servidor para la capa de presentación, un
servidor para la capa referente a la lógica de Negocio y un servidor de base de datos para
almacenamiento de la información del prototipo. Para dar una idea de esta estructura se muestra
la siguiente Figura:

Figura 12 Modelo Físico del Prototipo

2.4.2.2 Diagrama de Componentes

En el interior de cada una de las capas que conforman la arquitectura del Prototipo existe un
conjunto de componentes de software que se especializa en desarrollar ciertas actividades para
cada nivel compartiendo de esta manera las responsabilidades entre ellos cumpliendo con una
labor específica, es decir, en el diagrama de componentes se representa la estructura física del
código. A continuación se muestra el diagrama de componentes propuesto para el prototipo
 COMPONENTES
[parámetros]

COMPONENTES DE INTERFAZ DE USUARIO

COMPONENTES DE PROCESO

COMPONENTES EMPRESARIALES

COMPONENTES LÓGICOS
AGENTES DE SERVICIOS
DE ACCESO A DATOS

ORÍGENES DE DATOS SERVICIOS

Figura 13 Diagrama de Componentes propuesto para el Prototipo

En la capa de presentación se encuentran los siguientes componentes:

 Componentes de la Interfaz de Usuario: es una agrupación de Frames y formularios

diseñados para interactuar directamente con los usuarios de la aplicación desde los
dispositivos móviles.

 Componentes de proceso de la Interfaz de Usuario: facilitan la sincronización y

organización de las interacciones con el usuario, haciendo bastante útil el emplear
componentes de proceso de interfaz de usuario. De este modo, el flujo del proceso y la
lógica de administración de estado no se incluye en el código de los elementos de la
interfaz de usuario, por lo que varias interfaces podrán utilizar el mismo mecanismo con
el que interactúa

En la capa de negocios se encuentran los siguientes componentes:

 Componentes de negocio: componentes que representan objetos del negocio e

implementan la lógica de la asignación, control y consulta del parqueadero.
  Componentes lógicos de acceso a datos: componente que abstrae la lógica necesaria
para obtener acceso a los datos, ya que de este modo se centraliza la funcionalidad de
acceso a datos, se facilita la configuración y el mantenimiento de la misma.

 Agentes de servicios: El Prototipo podrá hacer uso de servicios externos como los de
seguridad y uso de recursos de apoyo como las librerías predefinidas según el lenguaje de
programación a utilizar; por tal motivo existirán componentes que permiten administrar
la comunicación a dichos servicios.

En la capa de datos se encuentran los siguientes componentes:

 Orígenes de Datos: corresponde a la base de datos con sus respectivas tablas creadas
para el prototipo atendiendo una cadena lógica de negocio predefinida.
CAPITULO 3 DESCRIPCIÓN SOLUCIÓN
En este capítulo se describirá la situación actual del objeto de estudio de este proyecto, junto con
el diseño del sistema, teniendo en cuenta las necesidades identificadas en la investigación
realizada y plasmadas en los requerimientos funcionales de los usuarios del sistema, y en los
diferentes diagramas.

3.1 SITUACION ACTUAL DEL PARQUEADERO UNIVERSIDAD DISTRITAL – SEDE

SABIO CALDAS

Actualmente el parqueadero de la Universidad Distrital “Francisco José de Caldas” – Sede Calle

40, funciona de manera muy manual conllevando así a diferentes problemas como lo son: una
distribución inadecuada en los espacios de parqueadero, no llevar un control adecuado de los
vehículos, del establecimiento, entre otros; los cuales se pueden minimizar con la automatización
de los procesos, y por lo que se propone la solución descrita más adelante.

El acceso al parqueadero se realiza a través de tarjetas de cartón que contienen los datos de cada
uno de los usuarios, una vez el celador permite su ingreso teniendo en cuenta el horario que tiene
cada uno, ingresan al parqueadero con sus vehículos y dejan la tarjeta la cual es ubicada en el
espacio de la caja que corresponde al espacio de parqueadero.

PARQUEADERO UNIVERSIDAD FRANCISCO JOSE DE CALDAS

PLACA: Par HORARIO: 6:00 pm a 10:00 pm

VEHICULO/MARCA/PLACA:
VALIDO HASTA: 31 – Diciembre - 2016
Moto Hyundai – CGN-65D

NOMBRE: Felipe Martínez CÉDULA: 1098789817 Bogotá

USUARIO: Estudiante

Figura 14 Carnet para el Acceso al Parqueadero

 Figura 15 Mecanismo actual de control de acceso al parqueadero

Para la asignación y disponibilidad de espacios se tienen las siguientes restricciones según el

usuario:

 Los administrativos tienen prioridad en el uso de parqueadero en el horario de 6:00 am a

10:00 pm, hasta en pico y placa.
 Los profesores de planta también tienen prioridad en el uso de parqueadero en el horario
de 6:00 am a 10:00 pm, hasta en pico y placa en caso de tener carro.
 Los profesores de catedra, solo pueden acceder al parqueadero en el horario en el que
tienen la clase (Esto teniendo en cuenta el horario registrado en Cóndor), en caso de
excederse en el tiempo tienen un llamado de atención.
 Los estudiantes de la jornada Diurna solo pueden acceder al parqueadero de 6:00 am a
5:00 pm, si el vehículo es moto, tiene autorizado un espacio y hay disponibilidad.
 Los estudiantes de la jornada Nocturna solo pueden acceder al parqueadero en el horario
de 6:00 pm a 10:00 pm, no aplica en pico y placa, debe tener estar autorizada y haber
disponibilidad.
 En caso de que algún usuario exceda el horario que tiene permitido, el celador llama la
atención personalmente y si su comportamiento es recurrente pueden retener su carnet.

A continuación se pueden observar algunos de los espacios destinados para carros y motos,
dentro del parqueadero:
 Figura 16 Espacios para motocicletas en el Parqueadero UD-Sede Calle 40

Figura 17 Espacios para automóviles en el Parqueadero UD-Sede Calle 40

El parqueadero de la UD – Sede Sabio Caldas cuenta con 3 sótanos, pero se debe tener en cuenta
que los espacios de parqueadero del sótano 1 no están disponibles, ya que es de uso exclusivo de
los funcionarios de la Universidad.
Teniendo en cuenta esto, a continuación se muestra la distribución del parqueadero (Sótano 2 y
3).
Vehículo Cantidad Espacios Sótano
Motos 1 espacio de carro para 7 motos. 2
9 Espacios de carro para 68 3
motos.
Carros 48 2
41 3
Tabla 1 Distribución del Parqueadero
3.2 DESCRIPCION GENERAL DEL SISTEMA

La solución planteada para el desarrollo de este proyecto es una simulación de procesos de

gestión y control del parqueadero de la Universidad Distrital Francisco José de Caldas sede
Sabio Caldas. Este sistema les permitirá a los usuarios crear una cuenta con su información
personal y la del vehículo, modificarla, consultar la disponibilidad de espacios dentro del
parqueadero según su tipo de vehículo y teniendo en cuenta las restricciones de su cuenta,
además podrá visualizar las alertas que les sean enviadas. Los controladores físicos podrán
enviar alertas a los usuarios del parqueadero, teniendo en cuenta el uso que realicen de este y el
horario permitido para cada uno. Por último a través de un módulo de administración se podrá
configurar la estructura del parqueadero, con el área, niveles, espacios que lo conforman de
manera que en un futuro estas funcionalidades puedan acoplarse a cualquier otro parqueadero.

Se van a tener diferentes módulos que tendrán las funcionalidades correspondientes según el rol
registrado en el sistema, en los cuales los usuarios podrán visualizar la disponibilidad de
parqueaderos, recibir mensajes de alerta, etc.

Para llevar a cabo el diseño y la simulación del sistema se utilizaron enfoques de la metodología
de ingeniería de software para recoger la información pertinente a los requerimientos y la
identificación de stakeholders, consiguiendo además plantear los casos de uso que describirán las
actividades y funciones que tendrá el sistema.
En la figura que se muestra a continuación se puede observar cómo sería la interacción del
sistema, con el usuario, con otras herramientas, con base de datos, para dar una idea global de
este proyecto.

El diseño del sistema propuesto está compuesto por un sistema de acceso con tarjetas inteligentes
las cuales permitirán el ingreso al parqueadero y contendrán la información de los usuarios, que
se almacenara en una base de datos. Esta será consultada por la aplicación móvil para informar
notificaciones y la disponibilidad de espacios de parqueadero a los usuarios obtenida a través del
webservices, que lleva la información enviada por el arduino permitiendo saber por medio del
sensor si el espacio está o no disponible.

Figura 18 Escenarios del prototipo del producto informático

3.3 CONTROL ACCESO

Dentro del análisis y diseño del prototipo se considera el modus operandi para el acceso a los
sótanos, un sistema de control de acceso físico para los vehículos o motocicletas, una red
estructurada u organizada que se propone con el uso de tarjetas de identificación inteligentes,
lectores de estas tarjetas ubicadas en la entrada principal de los sótanos para el acceso de los
vehículos y un servidor con el sistema y base de datos de autenticación y validación de las
vigencias de las autorizaciones generadas a quienes requieran hacer uso del parqueadero de la
sede calle 40 de la Universidad distrital “Francisco José de Caldas”.

Se ha decidido el uso de las tarjetas inteligentes con base en el nivel de seguridad que ofrecen, la
administración del parqueadero debe emitir estas tarjetas a los usuarios interesados en el uso del
mismo, independientes del carné estudiantil o de identificación docente según corresponda el
caso o puede ser este integrado en un solo documento de identificación, principalmente con el fin
de evitar su falsificación, cada tarjeta almacena la información sobre el usuario y privilegios de
este de forma protegida, estos privilegios se encontrarían mapeados en el servidor central de
autenticación validando contra la base de datos principal del sistema cuyo prototipo es tema de
desarrollo del presente documento, estos mismos privilegios pueden ser mapeados en servidores
alternos en el caso futuro de escalar el sistema a otros parqueaderos que quizá cuenten con
múltiples accesos.

En el momento en que la tarjeta es puesta en el lector sea de contacto o proximidad, el acceso es

brindado o negado de forma segura, cuando la autorización cumpla su vigencia de forma
permanente los privilegios pueden ser removidos del sistema, evitando así que el usuario intente
ingresar posteriormente, adicionalmente, el uso de tarjetas inteligentes ofrece a la universidad
específicamente a la dirección de recursos físicos encargada de la administración del
parqueadero, otros beneficios inherentes a esta tecnología, tales como: evitar el uso de múltiples
tarjetas, códigos de acceso, carnés específicos, entre otros, reforzar los sistemas de acceso
existentes, cambios de tarjetas por cambios de privilegios, administración unificada del sistema o
flexibilizar las funciones para manejar y controlar aplicaciones haciendo el uso de una única
tarjeta.

Vale la pena mencionar una de las ventajas redundantes de todo sistema y es el que cualquier
cambio implementado en el sistema de control de acceso será transparente para el usuario, esto
se debe a la visión que tiene el usuario del sistema de acceso, para él, únicamente éste se
encuentra compuesto por la tarjeta de acceso, el lector de la tarjeta y la barrera vehicular, sin
embargo, detrás de estos componentes se encuentran otros de hardware y software que
configuran una funcionalidad soportada en funciones de seguridad, entonces, adicional a los
componentes vista del usuario se suman un panel de control, el servidor de autenticación y
control de acceso, el software y la base de datos, en la siguiente Figura se muestra el esquema de
conexión del control de acceso al parqueadero
 Figura 19 Sistema de Control de Acceso. Modificado de (Smart Card Alliance Latin America (SCALA), 2006)

El proceso de control de acceso comienza cuando el usuario acerca la tarjeta al lector (el cual por
lo general se encuentra ubicado próximo a la barrera vehicular), el lector extrae los datos de la
tarjeta, realiza la traducción o proceso de datos para ser enviados al panel de control el cual hace
la validación del lector y posteriormente recibe los datos de transmitido de éste, posteriormente
el panel de control transmite los datos al servido de control de acceso o autenticación el cual
compara los datos tomados de la tarjeta con las credenciales almacenadas en la base de datos,
mientras que el sistema controlador comprueba los privilegios y autorizaciones con sus
respectivas vigencias, en caso positivo de acceso otorgado el servidor de control de acceso
genera un señal dirigida al panel de control para elevar la barrera vehicular, el panel de control a
su vez genera a vez dos señales, una de ellas para ejecutar el mecanismo de elevación de la
barrera y la otra hacia el lector que indicará al usuario el acceso permitido, esta indicación se da
por lo general a través de un sonido o mensaje lumínico en un display.

La negación del acceso está definido por las políticas (reglas de negocio) registradas en el
sistema y vigencias de las autorizaciones también cargadas en el sistema, en este caso, el
servidor de control de acceso podrá no emitir ninguna señal al panel de control o generar una
señal diferente para que el panel de control no active el mecanismo de la barrera vehicular y el
lector emita un sonido o mensaje lumínico diferente alertando de esta manera al usuario de la
negativa de acceso al parqueadero.

La tecnología propuesta en el diseño del prototipo para las tarjetas de acceso es la de tarjetas de
acceso inteligente sin contacto ya que por sus características técnicas son aptas para el uso en
ambientes de alto tráfico y/o expuestos a la intemperie, particularidades comprobables del acceso
al parqueadero de la sede calle 40 como a cualquier otro parqueadero, adicional a esto se
encuentra la necesidad de acercamiento del usuario al lector de tarjetas que se pretende situar a la
entrada de los sótanos, se analizaron entonces varias opciones que pudiesen cubrir los
requerimientos descritos, encontrándose la tecnología ISO/IEC 14443 como aquella que incluía
el ser tecnología de tarjetas inteligentes sin contacto con un radio de acción operacional de
máximo de aproximadamente 4” o 10 cm
Dentro del análisis efectuado se dejan abiertas las definiciones o consideraciones a nivel de
sistema, esto es su diseño y de la arquitectura de seguridad que se quiera adoptar con base o no
en los requerimientos de desempeño o interacción con el usuario, tener en cuenta que las
características de los parqueaderos no son las mismas así como su comunidad de usuarios, para
el caso particular del parqueadero de la sede calle 40 de la Universidad Distrital “Francisco José
de Caldas” estos parámetros se ciñen a los contemplados en el análisis y diseño del prototipo
propuesto.

3.4 HARDWARE

Para actualizar la información de la disponibilidad de espacios en el parqueadero de la

universidad se investiga la funcionalidad de micro controladores arduinos con sensores
infrarrojos, los cuales permitirán detectar la presencia de un vehículo cuando está estacionado y
alimentara por medio de un servicio la información a mostrar en la aplicación que consultará el
usuario (Perez, 2016).

A continuación una solución ya desarrollada, que será usada como referencia, para el desarrollo
de este proyecto.

1. El sensor emite señales de luz, la cual debe ser reflejada para que el fototransistor la
detecte (Perez, 2016).

Figura 20 Circuito Sensor Infrarrojo

2. El arduino Mega 2560 es un sistema embebido basado en un micro controlador, al cual le

llega la información de los sensores (estado), donde rojo indica ocupado y verde
disponible (Perez, 2016).
3. Leds: Diodo emisor de luz
 Figura 21 LED

CONEXIÓN

- ARDUINO Y SENSOR: Se utilizaran los siguientes pines: 5V Tierra y Pin Digital D44,
en el cual se conecta el control para determinar el estado del parqueadero de acuerdo al
sensor. Se programará para que reciba un 1 o 0 lógico del sensor

Figura 22 Conexión arduino y sensor

- LEDS PARA INDICAR ESTADO SENSOR: Se necesitan 5V de alimentación de

voltaje, a través de una resistencia de 330Ω, se conectan al ánodo y a Tierra.

Figura 23 Conexión LEDs

3.5 WEB SERVICE

Servicio Actualizar estado PARQUEADERO

Descripción El servicio permite actualizar en base de datos el estado actual del parqueadero,
dependiendo de la respuesta del microcontrolador
Expone Parking

Datos Entrada
Campo Descripción Tipo de dato Longitud
ParkId Corresponde al número del parqueadero Int 3
que fue ocupado

Datos Salida
Campo Descripción Tipo de dato Longitud
Nombres Corresponde al nombre del usuario que Texto 200
seleccionó el espacio
Cedula Número de cédula de la persona Numérico 20
Placa Placa del vehículo asociado por el usuario Alfanumérico 7
Nomb_Tipo Tipo de vehículo del usuario Texto 150
Nom_Marca Marca del vehículo del usuario Texto 150
Celular Número de celular del usuario Numérico 10
Email Correo del usuario Correo 150
Id_Parq Id de parqueadero actualizado Int 3
Lugar Corresponde al sótano donde está el Id del Texto 150
parqueadero
Estado Se actualiza de acuerdo a entrada enviada si Boolean 5
está True a False y viceversa

CONSTRUCCIÓN

- PROGRAMACIÓN

Figura 24 Esquema codificación WS Actualizar estado parqueadero

- BASE DE DATOS
 Figura 25 Procedimiento almacenado para actualizar estado en BD

SIMULACIÓN DEL SERVICIO:

- REQUEST:

Figura 26 Request WS Actualizar estado parqueadero

- RESPONSE
 Figura 27 Response WS Actualizar estado parqueadero

- BASE DE DATOS

Figura 28 Actualización estado en BD

3.6 PROTOTIPO

La propuesta planteada para el desarrollo de este proyecto a nivel de software (Prototipo) está
basada en lo siguiente:

Se desarrollará un Prototipo funcional que simule los usuarios permitidos en el sistema de

acuerdo a sus restricciones por horario, con la posibilidad de consultar la disponibilidad de
espacios de parqueadero, y envío de alertas por uso u horario permitido. A continuación se
realiza una descripción detallada de este:

El prototipo está compuesto por cuatro módulos:

 Inicio: A través de este módulo se ingresa al sistema.

 Usuario: En este módulo ingresan los usuarios permitidos en el sistema y según su perfil
revisan la disponibilidad de espacios.
  Control: En este módulo se pueden crear alertas de uso y de tiempo.
 Administración: A través de este módulo se pueden realizar el registro de usuarios
(Ingreso de datos básicos como los nombres, apellidos, el username, la cedula, el perfil,
la consulta, actualización (Se registran el tipo de vehículo, marca, placa, celular, email,
password), eliminación de usuarios y la configuración del parqueadero (área, sótanos,
espacios).

Los perfiles creados son:

 Administrador (Recursos Físicos).

 Usuario (Docente planta, Docente catedra, Estudiante diurno, Estudiante nocturno,
Administrativo).
 Controlador: Envío de alertas

Este prototipo funcional para móviles, es creado para la simulación del parqueadero de la
Universidad Francisco José de Caldas – Sede Sabio Caldas, la cual es soportada sobre una
plataforma web en Oracle Apex 5.0 (Sistema de Aplication express) e integrada con Oracle
Jdeveloper, funciones basadas en javascript y manejo de plsql.
CAPITULO 4 DEFINICIÓN DE ROLES, FUNCIONES Y
REQUERIMIENTOS DE LOS USUARIOS DEL SISTEMA.

En este apartado de definen los usuarios, roles y se establecen las funciones para cada uno de los
usuarios que intervienen en el sistema:

Actor Nombre Horario Observaciones

Administrador Recursos físicos 6AM – 10 PM Tiene prioridad,
puede usar el
parqueadero incluso
si hay Pico y placa
Usuario Docente Planta 6AM – 10 PM Tiene prioridad,
puede usar el
parqueadero (carro o
moto), carro incluso
si hay Pico y placa
Docente Catedra Por horas de clase Solo puede ingresar
el vehículo en
horario de clase
Estudiante 6AM – 5PM Solo pueden
Diurno ingresar motos si
tiene asignado
parqueadero y hay
cupos
Estudiante 6PM – 10PM Puede usar
Nocturno parqueadero de
carros (No aplica en
pico y placa) y
motos solo si está
autorizado y hay
disponibilidad
Administrativo 6AM – 10 PM Tiene prioridad,
puede usar el
parqueadero incluso
si hay Pico y placa
Controlador físico Vigilantes N.A. Encargado del
control interno de
vehículos ubicados
en el parqueadero de
la universidad
Tabla 2 Usuarios del sistema
 ROL FUNCIONES
Configurar parámetros del Sistema dentro
de los que se encuentran: (Área, niveles y
ADMINISTRADOR espacios de parqueadero).
Consultar información de los usuarios y
eliminarlos.
Tabla 3 Rol Administrador y funciones

ROL FUNCIONES
Crear cuenta con la información solicitada
por el sistema.
Loguearse en la aplicación desde su celular
una vez tenga la necesidad de consultar la
disponibilidad del parqueadero.
USUARIO Revisar las alertas que le envíen, sobre el
uso del parqueadero o si excedió el horario
de parqueo permitido.
Actualizar información de su cuenta, en
caso de ser necesario.
Consultar la disponibilidad del
parqueadero, a través de la aplicación
móvil.
Tabla 4 Rol Usuario y funciones

ROL FUNCIONES
Revisar el parqueadero a través de las
cámaras, y del sistema.
Identificar los vehículos mal parqueados,
que ocasionan un mal uso del parqueadero.
CONTROLADOR FISICO Enviar alerta al celular del usuario o los
usuarios que están haciendo mal uso del
parqueadero.
Enviar alerta al celular del usuario o los
usuarios, que cumplieron el horario de uso
permitido de parqueadero, de acuerdo a la
información del sistema.
Tabla 5 Rol controlador físico y funciones

Todo sistema debe tener una especificación de requerimientos que describan exactamente lo que
el sistema debe realizar, para que satisfaga las necesidades de los usuarios. A continuación se
definen los requerimientos funcionales con los que contara este proyecto para obtener los
resultados esperados:
 NOMBRE REQUERIMIENTO CASOS DE USO
Registrar autorizaciones: El administrador ingresa los
números de autorizaciones de los usuarios a quien se les
REQ001: Autorizaciones
asigno cupo en el parqueadero.

Tabla 6 REQ001 Autorizaciones

NOMBRE REQUERIMIENTO CASOS DE USO

Registro de usuario: El usuario registra sus datos
personales y los datos del vehículo que se va a almacenar
en el parqueadero, en el sistema.

Asignación de tipo de usuario: El Administrador ingresa

los tipos de usuario permitidos en el sistema.

Ingreso a la aplicación: El usuario ingresa sus datos

REQ002: Administración de para acceder a la aplicación
usuarios
Actualizar información: El usuario ingresa al menú de
Información personal y actualiza sus datos.

Consultar usuario: El Administrador puede consultar los

usuarios del sistema.

Eliminar usuario: El Administrador puede eliminar los

usuarios del sistema.
Tabla 7 REQ002 Administración de usuarios

NOMBRE REQUERIMIENTO CASOS DE USO

Consultar Disponibilidad Parqueadero: El usuario
ya está registrado en la aplicación y antes de ingresar
al parqueadero consulta los espacios que hay
disponibles en el parqueadero, teniendo en cuenta los
datos de su cuenta (Tipo de vehículo, carga
académica, horario permitido).
Configurar Área del parqueadero: El
Administrador ingresa la información
REQ003: Administración correspondiente al área del parqueadero.
parqueaderos Configurar Niveles Parqueadero: El
Administrador ingresa la información
correspondiente al número de niveles del
parqueadero.
Configurar Cantidad de espacios de
parqueadero: El Administrador ingresa la
información correspondiente al número de espacios
de parqueadero por nivel.
Tabla 8 REQ003 Administración parqueadero
 NOMBRE REQUERIMIENTO CASOS DE USO
Enviar Alertas Uso parqueadero: El controlador
envía un mensaje o alerta a los usuarios, en caso de
observar a través de las cámaras algún uso
inadecuado de los espacios del parqueadero.
REQ004: Alertas
Enviar Alertas Horario Parqueadero: El
controlador envía mensaje o alerta, cuando se
detecten los usuarios que ya cumplieron su tiempo
límite para el uso del parqueadero.
Tabla 9 REQ004 Alertas
CAPÍTULO 5 DISEÑO CASOS DE USO, MODELO ENTIDAD
RELACIÓN Y DIAGRAMA DE SECUENCIA
En el presente capítulo se recopila la información de los elementos de diseño de manera clara y
precisa, haciendo uso del modelamiento de datos, apoyándonos en algunos de los parámetros
dispuestos en la metodología RUP (Rational Unified Process) y las especificaciones del
lenguaje UML (Unified Modeling Language), con el fin de especificar los elementos que lo
componen, definir la forma en la que será construido y describir cómo interactúan sus unidades
al interior, esto es explicado a través de los diagramas de la arquitectura, componentes, clases y
datos (modelo entidad relación de la base de datos). Se inicia con la definición de la cadena
lógica de negocio, la cual nos determina los dos caminos a desarrollar: base de datos y software.

5.1 CADENA LÓGICA DE NEGOCIO

Figura 29 Cadena Lógica de Negocio

Se define el componente Usuario, teniendo en cuenta que éste puede tener en la universidad
muchas Autorizaciones las cuales se dan cada semestre; con dicha autorización puede ingresar
al parqueadero y tener muchos Ingresos o número de tickets. La idea del sistema es controlar el
cupo de los parqueaderos, que corresponden a una autorización dada para un usuario.
El usuario solo puede ingresar al sistema si tiene un número de autorización; si cuenta con éste,
podrá ver la disponibilidad del parqueadero en el horario permitido e indicar el parqueadero a
utilizar.
5.3 DIAGRAMA DE CASOS DE USO
De acuerdo a la cadena lógica de negocio definida, se tienen los siguientes componentes de
sistema:

Figura 30 Componentes Sistema

A continuación los casos de uso definidos por cada usuario del sistema:

Figura 31 Diagrama de Flujo Administrador

Figura 32 Diagrama de flujo Usuario

 Figura 33 Diagrama de flujo Sistema

Figura 34 Diagrama de flujo Controlador físico

5.1.1 ESPECIFICACIÓN CASOS DE USO

REQ001 Autorizaciones
Identificador: CU 001 –01 Nombre Caso de Uso: Ingreso autorización
Generado por: Sandra Milena Roa
Resumen: El usuario ingresa autorización en la aplicación

Actores: Docentes
Administrativos
Estudiantes
Pre-condición: El usuario debe tener un registro de autorización del administrador previo a la aplicación
Se debe descargar previamente la aplicación
Datos de entrada
Nombre ¿Es Tipo y tamaño Descripción
obligatorio?
Upar Si Numérico Número de autorización asignado por el encargado de recursos
físicos quien define y autoriza cupos en el parqueadero de la
universidad Francisco José de Caldas, sede Sabio Caldas.

Si este número no es válido no es posible registrarse en el sistema

Número de documento Si Numérico Número de identificación del usuario que se va a registrar en el

sistema
Iniciar Si Botón Permite el procesamiento de la información si está completamente
diligenciada y es válida

Flujo Básico
Actor Sistema
1. E usuario ingresa a la aplicación a la sección de Autorización 2. El sistema habilita los campos “UPar” , “Cedula” y la opción
Iniciar
3. Si el número de autorización y la cédula existen en el sistema ,
se carga el formulario para continuar con el registro
Flujo Excepción
El número de autorización no existe (paso 1 flujo básico)
1. El sistema muestra en pantalla el mensaje “El usuario no existe
o ha ingresado de manera incorrecta los datos, verifique los
datos o contacte a su administrador”
Pos condiciones: Registro a la aplicación
Requerimientos N.A.
especiales:
Tabla 10 Caso de Uso: Ingreso autorización

REQ002 Administrar usuarios

Identificador: CU 002 –01 Nombre Caso de Uso: Crear cuenta

Generado por: Sandra Milena Roa
Resumen: Registro del usuario en la aplicación

Actores: Docentes
Administrativos
Estudiantes
Pre-condición: El usuario debe tener un registro de autorización del administrador previo a la aplicación
Datos de entrada
Nombre ¿Es Tipo y tamaño Descripción
obligatorio?
Nombre Completo Si Texto (200) Nombre de la persona que va a realizar el registro en e sistema (No
editable)

Número de documento Si Numérico Número de identificación del usuario que se va a registrar en el

sistema.
Carga el número de identificación autorizado en el sistema
Tipo Vehículo Si Lista Lista con las opciones Carro o Moto

Marca Vehículo Si Lista Lista de marcas según tipo de vehículo seleccionado.

Placa Vehículo Si Alfanumérico (6) Campo que permite el ingreso de la placa del vehículo que ingresará
al parqueadero
Teléfono Si Numérico Campo que registra el número de celular de la persona que se
registra
Login Si Texto (9) Nombre de usuario designado por el usuario con el cual ingresará a
la aplicación
Password Si Alfanumérico Campo tipo password, corresponde a la contraseña que registrará el
(50) usuario para el ingreso a la aplicación
Guardar Si Botón Permite el procesamiento de la información si está completamente
diligenciada
Flujo Básico
Se debe descargar previamente la aplicación
Actor Sistema
1. El usuario previamente ingresó el número de autorización y 2. El sistema carga el formulario para continuar con el registro
cédula con los siguientes campos:
  Nombre Completo
 Número de documento
 Tipo Vehículo
 Marca Vehículo
 Placa Vehículo
 Teléfono
 Login
 Password
3. El usuario ingresa la información requerida y hace clic en 4. El sistema guarda la información y regresa a usuario a la
Guardar pantalla principal para que ingrese
Flujo Excepción
Falta información requerida por diligenciar (paso 1 flujo básico)
1. El sistema muestra en pantalla el mensaje correspondiente de
acuerdo al campo no diligenciado
Pos condiciones:
Requerimientos N.A.
especiales:
Tabla 11 Caso de Uso: Crear cuenta

Identificador: CU 002 –02 Nombre Caso de Uso: Ingreso a la aplicación

Generado por: Sandra Milena Roa
Resumen: Acceso del usuario a la aplicación

Actores: Docentes
Administrativos
Estudiantes
Administrador del sistema
Pre-condición: El usuario debe tener un registro previo a la aplicación
Datos de entrada
Nombre ¿Es Tipo y tamaño Descripción
obligatorio?
Usuario Si Texto (9) Campo que permite el ingreso del nombre de usuario que registro
previamente

Contraseña Si Alfanumérico Campo tipo password, corresponde a la contraseña registrada por el

(50) usuario

Ingresar Si Botón Permite el procesamiento de la información (Login y Password)

Flujo Básico
Actor Sistema
1. Ingresar Usuario y Contraseña; y hacer clic en el botón 2. El sistema procesa la información, si la información es válida
Ingresar carga la pantalla principal dependiendo del perfil
Flujo Alterno 1
El usuario que ingresa es Administrador de sistema
Pasos Resultado esperado
1. El sistema muestra en pantalla las siguientes opciones:
Registrar usuario
Consultar Usuario
Configurar parqueadero
Flujo Alterno 2
El usuario que ingresa es Estudiante, Docente o Administrativo
1. El sistema muestra en pantalla las siguientes opciones:
Consultar disponibilidad

Si usuario consulta fuera del horario permitido no podrá ver la

disponibilidad.
Flujo Excepción
El Login y/o Password no es válido (paso 1 flujo básico)
1. El sistema debe mostrar el mensaje “Credenciales de conexión
 no válidas”
Pos condiciones:
Requerimientos N.A.
especiales:
Tabla 12 Caso de Uso – Ingreso

Identificador: CU 002 –03 Nombre Caso de Uso: Registrar ingreso de usuario

Generado por: William Roberto García Rincón
Resumen: El sistema hará la asignación en base de datos de usuario y sitio de parqueo asignado

Actores: Usuario
Sistema
Controlador Físico
Pre-condición: El usuario debe estar autentificado
Existencia de autorización de ingreso al parqueadero
Datos de entrada
Nombre ¿Es Tipo y Descripción
obli tamaño
gato
rio?
Identificador del usuario en el sistema, este será correspondido con el número de
Login Si Texto
identificación asociado en base de datos

Numéric
IdAutorizacion Si Identificador del permiso de acceso al parqueadero
o

Numéric
IdParqueadero Si Identificador del parqueadero asignado
o

Flujo Básico
Actor Sistema
1. 2. El sistema validará la vigencia de la autorización de entrada
3. El sistema notificará al usuario y controlador físico del acceso al parqueadero. Ver
requerimiento especial 1
4. El sistema almacena los cambios de estado de los usuarios
Flujo Alterno 1
En el caso de no existir una autorización de ingreso
Pasos Resultado esperado
1. No existe autorización de 2. El sistema notificará al usuario y controlador físico de la restricción de acceso al parqueadero
ingreso
Pos condiciones: Se hará el registro en la base de datos del sistema de la instancia de acceso o restricción del usuario y
notificaciones pertinentes
Requerimientos especiales: 1. Mensaje usuario y Controlador Físico: “<DD/MM/YYYY HH24:MI>: Ingreso del vehículo
<PLACA> propiedad de <USUARIO>, Sótano <NUMERO SÓTANO> posición
<IDPARQUEADERO>”
Tabla 13 Caso de Uso: Registrar ingreso de usuario

Identificador: CU 002 –04 Nombre Caso de Uso: Consultar disponibilidad

Generado por: Sandra Milena Roa
Resumen: Permite al usuario validar la disponibilidad del parqueadero de la universidad Francisco José de Caldas, sede Sabio
Caldas
Actores: Docentes
Administrativos
Estudiantes
Administrador del sistema
Pre-condición: El usuario está logueado en el sistema
Datos de entrada
Nombre ¿Es Tipo y tamaño Descripción
obligatorio?
Consultar disponibilidad N.A. Opción búsqueda Opción que permite ingresar a consultar la disponibilidad actual del
parqueadero de la universidad, solo aparece si usuario está dentro
del horario permitido

Sótano N.A. Numérico Campo no editable, que muestra el número de Sótano

Número parqueadero disponible N.A. Numérico Campo no editable, que muestra los espacios disponibles por sótano

Flujo Básico
Actor Sistema
1. Ingresa a la aplicación en horario válido 2. El sistema carga en pantalla a siguiente información:
 Sótano
 Parqueaderos disponibles
Flujo alterno
1. Usuario ingresa en horario no vàlido 2. El sistema permite el ingreso del usuario pero le muestra en
pantalla el mensaje: “En este momento no cuentas con permiso
para ingresar al parqueadero. Intenta en el horario en el que
estas autorizado”
Pos condiciones:
Requerimientos La información debe estar actualizada en tiempo real según los espacios ocupados durante la consulta del usuario
especiales:
Tabla 14 Caso de Uso: Consultar disponibilidad

Identificador: CU 002 –05 Nombre Caso de Uso: Consultar Usuario

Generado por: Norma Losada
Resumen: En este caso de uso se consultan los usuarios registrados en el sistema.

Actores: Administrador
Sistema
Pre-condición: Tener acceso al módulo – Usuario Administrador y permisos.
Datos de entrada
Nombre ¿Es obligatorio? Tipo y Descripción
tamaño
Usuario N/A Texto Campo que permite visualizar el nombre de usuario registrado,
para consultar su información.

Flujo Básico
Actor Sistema (Resultado esperado)
1. Ingresar a la aplicación con Usuario 2. El sistema muestra un campo para buscar el usuario y una
Administrador e ingresar a la opción lista con los usuarios registrados.
Consultar.

3. Hacer clic en uno de los usuarios 4. El sistema muestra la información correspondiente al usuario
registrados. seleccionado.
 Registro
 Nombres Apellidos
 User Name
  Cedula
 Tipo vehículo
 Marca
 Placa
 Celular
 Email
 Password

El sistema muestra los botones:

 Actualizar Usuario.
Eliminar usuario.
5. Ingresar en la lupa el nombre de uno 6. El sistema muestra el usuario.
de los usuarios registrados.
Flujo Alterno 1

Pasos Resultado esperado

1. Ingresar en la lupa el nombre de un 2. El sistema muestra mensaje “Ningún dato encontrado”.
usuario no registrado.
Pos condiciones:
Requerimientos especiales: N/A
Tabla 15 Caso de Uso: Consultar Usuario

Identificador: CU Nombre Caso de Uso: Eliminar Usuario

002 –06
Generado por: Norma Losada
Resumen: En este caso de uso se eliminan usuarios registrados en el sistema.

Actores: Administrador
Sistema
Pre-condición: Tener acceso al módulo de Administrador y permisos.
Datos de entrada
Nombre ¿Es Tipo y Descripción
obligatorio? tamaño
Usuario N/A Texto Campo que permite visualizar el nombre de usuario registrado,
para consultar su información.

Eliminar Usuario Si Botón Permite eliminar el usuario seleccionado y previamente

registrado en el sistema.

Flujo Básico
Actor Sistema (Resultado esperado)
1. Ingresar a la aplicación con Usuario 2. El sistema muestra un campo para buscar el usuario y una
Administrador e ingresar a la opción Consultar. lista con los usuarios registrados.

3. Hacer clic en uno de los usuarios registrados. 4. El sistema muestra la información correspondiente al
usuario seleccionado.
 Registro
 Nombres Apellidos
 User Name
 Cedula
 Tipo vehiculo
 Marca
 Placa
 Celular
 Email
  Password

El sistema muestra los botones:

 Actualizar Usuario.
Eliminar usuario.
5. Dar clic en el botón Eliminar Usuario 6. El sistema muestra mensaje de confirmación “Esta seguro
de borrar el usuario”.
7. Dar clic a la opción Si. 8. El sistema se devuelve a la pantalla de las opciones
Registrar, consultar, configurar. Muestra mensaje “Acción
procesada”.
Flujo Alterno 1

Pasos Resultado esperado

1 Dar clic en el botón Eliminar Usuario 2 El sistema muestra mensaje de confirmación “Esta seguro
de borrar el usuario”.
3 Dar clic a la opción No. 4 El sistema cierra la ventana de confirmación del mensaje y
muestra la información del usuario.
Pos condiciones:
Requerimientos especiales: N/A
Tabla 16 Caso de Uso: Eliminar Usuario

Identificador: CU 002 –07 Nombre Caso de Uso: Actualizar información

Generado por: Sandra Milena Roa
Resumen: Permite al administrador actualizar información personal del usuario

Actores: Administrador del sistema

Pre-condición: Ingresar a consultar usuario
Datos de entrada
Nombre ¿Es Tipo y tamaño Descripción
obligatorio?
Upar Si Numérico Campo editable, muestra el número de autorización del usuario

Número de documento Si Numérico Campo editable, muestra el número de documento ingresado por el
usuario en el registro

Nombre Completo Si Texto (200) Campo no editable, muestra el nombre registrado por el usuario

Teléfono SI Numérico Campo editable, muestra el número celular registrado por el usuario

Tipo Vehículo No Lista Campo editable, muestra el tipo de vehículo seleccionado por el
usuario

Marca Vehículo Si Lista Campo editable, lista de opciones de las marcas según el tipo de
vehículo

Placa Si Alfanumérico Campo editable, muestra la información registrada

Email No Correo Campo editable, muestra el correo actual del usuario

User name Si Alfanumérico Nombre de usuario para ingreso a la aplicación

Password Si Alfanumérico Contraseña para ingreso a la aplicación

Guardar Si Botón Permite el procesamiento de la información

Flujo Básico
Actor Sistema
1. Ingresar a la opción Actualizar información 2. El sistema muestra el formulario de actualización con los
campos definidos en las entradas de este CU; solo los
siguientes campos son editables:
Upar
Cedula
Tipo vehículo
Marca Vehículo
Placa
Teléfono
Email
User name
Password
3. Se cambia la información requerida y hace clic en Actualizar 4. El sistema guarda la información
Flujo Excepción
No se ingresaron todos los campos requeridos (paso 3 flujo básico)
1. El sistema debe mostrar el mensaje “No es posible guardar la
información, revise que todos los campos requeridos están
diligenciados”
Pos condiciones:
Requerimientos N.A.
especiales:
Tabla 17 Caso de Uso: Actualizar información

REQ003 Administrar parqueadero

Identificador: Nombre Caso de Uso: Configurar parqueadero
CU 003 –01
Generado por: Norma Losada
Resumen: En este caso de uso se define la configuración del área del parqueadero.

Actores: Administrador
Sistema
Pre-condición: Tener acceso al módulo de Administrador y permisos.
Datos de entrada
Nombre ¿Es Tipo y tamaño Descripción
obligatorio?
Área Si Alfanumérico Campo que permite ingreso del dato del área
(50) correspondiente al parqueadero a configurar.

Lugar Si Lista Campo que permite seleccionar de una lista desplegable el

número de sótano a configurar.

Tipo de vehículo Si Lista Campo que permite seleccionar de una lista desplegable el
tipo de vehículo al cual se le va a asociar el número de
espacios.

Cantidad Si Numérico Campo que permite ingresar el número de espacios para el

sótano y tipo de vehículo a configurar.

Guardar Si Botón Permite el procesamiento y almacenamiento de la

información de la configuración del parqueadero.

Flujo Básico
Actor Sistema (Resultado esperado)
1 Ingresar a la aplicación con Usuario Administrador e 2 El sistema muestra pantalla con los campos:
ingresar a la opción Configurar.  Área
 Lugar
 Tipo vehículo
 Cantidad
3 Ingresar el área en m2 (Este dato puede estar 4 El sistema almacena el dato en el campo.
previamente definido por defecto, para el caso de la
universidad)
5 Seleccionar el lugar a configurar, es decir el sótano. 6 El sistema permite seleccionar el número de sótano y lo
almacena en el campo.
7 Seleccionar el Tipo de vehículo a configurar. 8 El sistema permite seleccionar el tipo de vehículo y lo
almacena en el campo.
9 Ingresar el número de espacios disponibles por tipo de 10 El sistema permite seleccionar el tipo de vehículo y lo
vehículo y lugar seleccionado. almacena en el campo.
11 Dar clic al botón Guardar 12 El sistema almacena en la Base de datos la información
configurada del parqueadero y muestra mensaje
“Acción completada”:
Flujo Alterno 1

Pasos Resultado esperado

1. 2.

Pos condiciones:
Requerimientos especiales: N/A
Tabla 18: Caso de Uso: Configurar parqueadero

Identificador: CU 003–02 Nombre Caso de Uso: Registrar disponibilidad de espacio de parqueadero

Generado por: William Roberto García Rincón
Resumen: El sistema notificará al usuario de la existencia espacios de parqueo disponibles, se efectúa la solicitud de parqueo y
autorización.

Actores: Usuario
Administrador del sistema
Sistema
Controlador Físico
Pre-condición: El usuario debe estar autentificado
Datos de entrada
Nombre ¿Es obligatorio? Tipo y tamaño Descripción
Identificador del usuario en el sistema, este será correspondido
Login Si Texto
con el número de identificación asociado en base de datos

IdParqueadero Si Numérico Identificador del parqueadero disponible

IdSolicitud No Numérico Identificador de la solicitud de acceso al parqueadero

IdAutorizacion No Numérico Identificador del permiso de acceso al parqueadero

Flujo Básico
Actor Sistema
1. 2. El sistema validará el estado de los parqueaderos
3. 4. El sistema genera en la interfaz de usuario el listado de los
parqueaderos en estado disponible. Ver requerimiento especial
1
Flujo Alterno 1
Se genera una solicitud de parqueo a partir de la disponibilidad
 Pasos Resultado esperado
1. El usuario genera solicitud de parqueo 2. El sistema notificará al administrador del sistema de la
solicitud de parqueo. Ver requerimiento especial 2
3. El administrador del sistema genera autorización a partir de la 4. El sistema notificará al usuario de la autorización de ingreso,
solicitud horario y parqueadero asignado. Ver requerimiento especial 3
5. 6. El sistema notificará al controlador físico del usuario,
autorización de ingreso, horario y parqueadero asignado. Ver
requerimiento especial 4
Flujo Alterno 2
Se genera rechazo de la solicitud de parqueo
Pasos Resultado esperado
1. El administrador del sistema rechaza la solicitud de parqueo 2. El sistema notificará al usuario del rechazo de la solicitud. Ver
efectuada por el usuario requerimiento especial 5
Pos condiciones: Se genera el listado de disponibilidad de parqueaderos, solicitud de ingreso al parqueadero y notificaciones
Requerimientos 1. Listado de disponibilidad:
especiales: “Parqueaderos disponibles:

Sótano <NUMERO SÓTANO>, posición <IDPARQUEADERO>

.
.
.
Sótano <NUMERO SÓTANO>, posición <IDPARQUEADERO>”

2. Mensaje solicitud al administrador del sistema: “<DD/MM/YYYY HH24:MI>: <USUARIO> solicita

autorización de parqueo al Sótano <NUMERO SÓTANO> posición <IDPARQUEADERO>”
3. Mensaje notificación de autorización al usuario: “<DD/MM/YYYY HH24:MI>: Autorización de parqueo
<NÚMERO AUTORIZACIÓN>, Sótano <NUMERO SÓTANO>, posición <IDPARQUEADERO> vigente
hasta <FECHAHORA FIN VIGENCIA>”
4. Mensaje notificación de autorización al Controlador Físico: “<DD/MM/YYYY HH24:MI>: Autorización de
parqueo <NÚMERO AUTORIZACIÓN>, Sótano <NUMERO SÓTANO>, posición <IDPARQUEADERO>
vigente hasta <FECHAHORA FIN VIGENCIA> para el usuario <USUARIO>”
5. Mensaje notificación de rechazo de autorización al usuario: “<DD/MM/YYYY HH24:MI>: Autorización de
parqueo denegada”
Tabla 19 Caso de Uso: Registrar disponibilidad de espacio de parqueadero

REQ004 Alertas
Identificador: CU 004–01 Nombre Caso de Uso: Notificar Alertas por horario
Generado por: William Roberto García Rincón
Resumen: El usuario controlador notificará al usuario del sistema que ya fue cumplido el horario asignado para tener el vehículo
dentro del parqueadero de la universidad

Actores: Controlador Físico

Pre-condición: Ninguna
Datos de entrada
Nombre ¿Es Tipo y tamaño Descripción
obligatorio?
Número Parqueadero Si Numérico Identificador del parqueadero

Sótano Si Numérico Identificador del parqueadero

Campo de lectura, viene del registro del usuario que ocupa el

Correo Si Correo
parqueadero

Asunto Si Texto Campo abierto que permite el ingreso del mensaje a notificar

Enviar N.A. Botón Permite enviar la alerta al correo en pantalla

Flujo Básico
Actor Sistema
1. El usuario controlador ingresa a la aplicación, selecciona un 2. El sistema validará la contra la fecha y hora actual el horario de
parqueadero asignado, selecciona el tipo de alerta (horario), el registro del usuario.
asunto y envía la alerta al correo del usuario que ocupa el
espacio anteriormente seleccionado
3. 4. El sistema envía alerta al usuario de la finalización de la
vigencia para retiro del vehículo
Pos condiciones: Se generan los mensajes de alerta a todos los actores del sistema cuando se produzca la finalización de la vigencia
de una autorización de parqueo.
Requerimientos 1. Mensaje de alerta al Usuario: “<DD/MM/YYYY HH24:MI>: Apreciado usuario, Agradecemos por
especiales: favor retirar el vehículo del parqueadero de forma inmediata, ya que está fuera del horario autorizado
por Recursos físicos”

Tabla 20 Caso de Uso: Notificar Alertas por horario

Identificador: CU 004–02 Nombre Caso de Uso: Registro de Novedades por el Controlador Físico
Generado por: William Roberto García Rincón
Resumen: Registro de novedades del parqueadero por el controlador físico y notificación a usuarios.

Actores: Usuario
Sistema
Controlador Físico
Pre-condición: El controlador físico debe estar autentificado en el sistema
Datos de entrada
Nombre ¿Es Tipo y tamaño Descripción
obligatorio?
Botón de navegación que activa el formulario de registro de
Registrar Novedad Si Botón
novedades del parqueadero

Lista desplegable
Tipo Novedad Si Especificación de la novedad suscitada (Ubicación, Horario, Otro)
<Texto>

Fecha
Fecha Hora Novedad Si <dd/mm/yyyy Fecha hora del Evento
hh24:mi>

Lista desplegable
Sótano Si Identificador del Sótano
<Alfanumérico>

Lista desplegable
Parqueadero Si Identificador del Parqueadero
<Alfanumérico>

TextBox
Placa Si <Alfanumérico 6 Identificación del Vehículo/Moto que genera la novedad
caracteres>

TextBox <Texto
Observación Si Detalle de la novedad presentada
150 Caracteres>

Botón para la ejecución del guardado de la información en el

Guardar Registro Si Botón
sistema.

Flujo Básico
Actor Sistema
1. El controlador Físico ejecuta el botón “Registrar Novedad” 2. El sistema genera el formulario de registro de novedades con
los campos Tipo Novedad, Fecha Hora, Sótano, Parqueadero,
Placa y Observaciones.
3. El controlador Físico selecciona el tipo de novedad 4. El sistema consulta el listado de tipos de novedad creados en el
sistema y los muestra en la lista desplegable “Tipo Novedad”.
5. El controlador Físico registra la fecha hora de la novedad en el 6. El sistema consulta el listado de sótanos creados en el sistema y
campo fecha hora los muestra en la lista desplegable “Sótano”.
7. El controlador Físico selecciona el sótano correspondiente 8. El sistema consulta el listado de parqueaderos creados y
asociados en el sistema al sótano seleccionado y los muestra en
la lista desplegable “Parqueadero”.
9. El controlador Físico selecciona el parqueadero correspondiente 10. El sistema consulta la última autorización asociada al
parqueadero y retorna la placa del vehículo/moto en el campo
placa
11. El controlador Físico corrige la placa y/o registra la 12. El sistema almacena la información de la novedad y se genera
observación, ejecuta el botón “guardar registro” el mensaje de registro exitoso. Ver requerimiento especial 1.
Flujo Alterno 1
La placa corregida por el controlador físico no registra en el sistema
Pasos Resultado esperado
1. El controlador Físico corrige la placa y/o registra la 2. El sistema genera mensaje de alerta de la no existencia de la
observación, ejecuta el botón “guardar registro” placa en la base de datos. Ver requerimiento especial 2.
Flujo Alterno 2
Se genera mensaje de alerta al usuario por novedad registrada
Pasos Resultado esperado
1. El controlador Físico corrige la placa y/o registra la 2. El sistema genera mensaje de alerta al usuario notificándolo de
observación, ejecuta el botón “guardar registro” la novedad presentada. Ver requerimiento especial 3.
Pos condiciones: Se almacena la novedad registrada por el controlador físico en el sistema y se generan los mensajes de alerta
correspondientes
Requerimientos 1. Mensaje de Registro Exitoso: “Novedad registrada exitosamente”
especiales: 2. Mensaje de alerta al controlador físico de la no existencia de la placa en la base de datos: “ALERTA: El
vehículo de placas <PLACA> no se encuentra registrado en el sistema”.
3. Mensaje de alerta al usuario de la novedad presentada: “ALERTA: Novedad de parqueo por <TIPO
NOVEDAD> el <FECHA HORA NOVEDAD> para el vehículo <PLACA>, Observacion
<OBSERVACION>”.
Tabla 21 Caso de Uso: Registro de Novedades por el Controlador Físico
5.2 DISEÑO BASE DE DATOS

En el diseño de la base de datos del proyecto se definen 3 componentes claves que intervienen en
la cadena lógica de negocio los cuales se definen en el siguiente numeral:

5.2.1 Construcción por el modelo de las dependencias funcionales para una DFE

Basados en el modelo definido en el libro “Modelo seudomatemático para el diseño de las bases
de datos relacionales” del autor John Jairo Londoño, se define el siguiente modelo de
dependencia funcional exclusiva para el desarrollo del proyecto. (Londoño, 2016)

1
DFE
m
1 1 DFE
Usuario
1
m
1
Cedula (PK) Autorización
1
NombreCompleto
TelefonoCelular m
TipoUsuario(FKD) IdAutorizacion (PK) Ingreso
Fecha
Placa (FKD)
Estado NumeroTicket (PK)
Horario Fecha
Cedula (FK) HoraIngreso
Login HoraSalida
Password IdParqueadero (FKD)
Figura 35 Modelo Dependencia FuncionalIdAutorizacion
Exclusiva (FK)

Las tablas definidas a partir de la construcción del modelo de dependencias funcionales son:

Tabla Usuario
{Cedula (PK), Nombre, TelefonoCelular, TipoUsuario (FKD)}

En esta tabla va la información básica de los usuarios autorizados por recursos físicos para el
uso del parqueadero

Tabla Autorización
{IdAutorizacion (PK), Fecha, Placa (FKD), Estado, Horario, Cedula (FK), Login,
Password}

En esta tabla se almacena la información de autorización de un usuario

Tabla Ingreso
{NumeroTicket (PK), Fecha, HoraIngreso, HoraSalida, IdParqueadero (FKD),
IdAutorizacion (FK)}

Esta tabla contiene la información de ingreso que se presenta día adía, donde se relaciona
directamente con la autorización dada al usuario

Tabla Parqueadero
{IdParqueadero (PK), Sotano, TipoVehiculo (FKD), EsFijo, Cantidad, Estado}

Esta tabla contiene la información de la numeración de los parqueaderos por cada sótano y de
acuerdo al tipo de vehículo a parquear (moto o carro), tiene un campo estado que determina si
está ocupado o no (0 o 1).
Como los espacios están numerados de acuerdo a un campo para carro, si es tipo vehículo
“Moto”, la cantidad varia (en un espacio de carro hay 9 motos)
En caso de incluirse el sótano 1 se usará la variable “EsFijo”, ya que estos no se asignan
porque son exclusivos de los administrativos.

Tabla TipoUsuario
{TipoUsuario (PK), Nombre, Estado}

En esta tabla están discriminados los tipos de usuarios del sistema, los cuales son: Estudiantes
Diurno, Estudiante nocturno, Docente Planta, Docente cátedra y Administrativos

Tabla Placa
{Placa (PK), Ciudad, TipoVehiculo (FKD), Marca (FKD)}

Contiene la información de los vehículos de los usuarios registrados

Tabla TipoVehiculo
{TipoVehiculo (PK), Nombre}

Tabla donde se almacenan los tipos de vehículos que pueden ser parqueados, en este caso son
carro y moto

Tabla Marca
{IdMarca (PK), Nombre, TipoVehiculo(FK)}

En esta tabla se almacenan las marcas que existen en el mercado actualmente por tipo de
vehículo (carro o moto)

Con este diseño de base de datos a partir del modelo de dependencias funcionales, se destaca que
el número de ticket es la clave única e irrepetible dentro del sistema lo cual lo determina como
un sistema de información y permitirá la generación de reportes donde se podrá consultar la
cantidad de veces que un usuario ingresa en un día al parqueadero por ejemplo, los ingresos en el
mes, nuevos funcionarios que ingresaron en un semestre, etc.
5.2.2 Modelo Relacional

Figura 36 Modelo Relacional

5.2.3 Modelo Entidad Relación

Figura 37 Modelo Entidad-Relación

5.3 DIAGRAMAS DE SECUENCIA

REQ001 Autorizaciones

Figura 38 Diagrama secuencia: Ingreso Autorización

REQ002 Administrar usuarios

Figura 39 Diagrama de Secuencia Registro usuario

Figura 40 Diagrama de Secuencia Ingreso usuario

Figura 41 Diagrama de Secuencia Disponibilidad

Figura 42 Diagrama de Secuencia Consultar Usuario
Figura 43 Diagrama de Secuencia Eliminar Usuario
Figura 44 Diagrama de Secuencia Actualizar información
REQ003 Administrar parqueadero

Figura 45 Diagrama de Secuencia Configurar Parqueadero

 GUI
Controlador Base de
Usuario GUI Usuario Físico Sistema
Datos

Valida Autorización

Valida Datos Consulta Autorización

Acceso Autorizado Existe Autorización

Acceso Autorizado

Valida Autorización Valida Datos Consulta

Acceso Restringido No existe Autorización

Acceso Restringido

Figura 46 Diagrama de Secuencia Registrar ingreso de usuario

GUI
Controlador GUI Base de
Usuario GUI Usuario Físico Sistema
Admin Datos
Sistema

Consulta Disponibilidad
Valida Datos Consulta Estado Parqueaderos

Genera listado de disponibilidad Retorna Estado

Solicita Autorización Inserta solicitud

Guarda Solicitud
Mensaje Solicitud Nueva Solicitud

Genera Autorizacion Inserta Autorizacion

Guarda Autorización
Notificacion de Autorización Nueva Autorización
Notificacion de Autorización

Consulta Disponibilidad

Valida Datos Consulta Estado Parqueaderos

Genera listado de disponibilidad Retorna Estado

Solicita Autorización Inserta solicitud
Guarda Solicitud
Mensaje Solicitud Nueva Solicitud
Rechazo Inserta Rechazo
Guarda Rechazo
Notificacion de Rehazo Autorización Nueva Rechazo

Figura 47 Diagrama de Secuencia Registrar disponibilidad de espacio de parqueadero

REQ004 Alertas

GUI GUI
Administrador Controlador Base de
GUI Usuario Físico Sistema
sistema Datos

Consulta Vigencia

Alerta Vencimiento Autorización Vigencia Vencida

Alerta Vencimiento

Alerta Vencimiento Autorización

Figura 48 Diagrama de Secuencia Notificar Alertas por horario

Controlador GUI Base de

GUI Usuario Sistema
Físico Controlador Datos

Registra Datos

Valida Datos Consulta

Validación Respuesta Guarda Datos

Novedad Registrada Insert Exitoso

Alerta

Registra Datos Valida Datos Consulta

Placa No Existe Respuesta

Figura 49 Diagrama de Secuencia Registro de Novedades por el Controlador Físico

CAPITULO 6: DISEÑO PROTOTIPO MÓVIL
El prototipo propuesto como ya se ha mencionado en otros apartes del documento tiene como
objetivo ofrecer información en tiempo real de la disponibilidad de los estacionamientos del
parqueadero de la sede calle 40 de la Universidad Distrital “Francisco José de Caldas”, a través
de una aplicación móvil o web que presenta un listado de los espacios de parqueadero asociados
a los sótanos de la sede, así como notificaciones de uso y restricción que se generen.

En el presente capítulo se explica el funcionamiento del prototipo de asignación y control del

parqueadero.

6.1 PLANOS PARQUEADERO

Figura 50 Plano Sótano 1 Sabio Caldas

Figura 51 Sótano 2 Sabio Caldas

 Figura 52 Plano Sótano 3 Sabio Caldas

6.2 MODULOS PROTOTIPO PARQUEADERO

Para el desarrollo del prototipo se definieron los siguientes datos:

- Usuarios con diferente perfil (docente planta, administrativo, docente cátedra, estudiante
diurno y estudiante nocturno), con horarios predefinidos para mostrar o no la
disponibilidad.
- Un administrador quien puede controlar la información del sistema
- Usuario controlador, quien se encargará de generar las alertas
- Base de datos precargada con tipos de vehículos y marcas según el tipo seleccionado

A continuación la funcionalidad por cada tipo de usuario del sistema; administrador, usuario y
controlador

6.2.1 ADMINISTRADOR

Este módulo está compuesto por tres opciones Registrar, consultar y configurar:

Figura 53 Modulo Administrador

a) Opción Registrar:

En esta pantalla se registran los datos básicos del usuario, seleccionando además el perfil
asociado para determinar el horario de acceso permitido al parqueadero.

Figura 54 Creación de Usuario

Una vez se ingresan los datos, y se da clic al botón Crear Usuario el sistema muestra mensaje de
confirmación de la acción realizada.
Figura 55Usuario creado
b) Opción Consultar:

En esta pantalla se pueden consultar los usuarios ya registrados en el sistema. Se selecciona el

usuario a actualizar y el sistema muestra la información de este.

Figura 56 Consultar Usuario

Una vez dentro el sistema permite mediante dos botones Actualizar el Usuario o Eliminarlo.

Figura 57 Actualizar Usuario

Al seleccionar Actualizar usuario, se pueden modificar los datos y guardar los cambios.

Figura 58 Usuario Actualizado

Al seleccionar Eliminar usuario, el sistema pregunta si está seguro de borrarlo, y al final muestra
mensaje de confirmación.

Figura 59 Eliminar Usuario

c) Opción Configurar:

En esta pantalla se pueden parametrizar los datos del parqueadero, de manera que esta
configuración funcione para cualquier otro parqueadero. Primero se indican los lugares que
corresponde al número de sótanos que tiene el parqueadero, el tipo de vehículo si es moto, carro,
la cantidad de espacios por el tipo de vehículo y el área del sótano que se está configurando.

Figura 60 Configurar Parqueadero

Una vez se ingresa la información se crea la configuración del sótano, y el sistema muestra
mensaje de confirmación.

Figura 61 Parqueadero creado

6.2.2 USUARIO

Para este módulo se definieron los siguientes tipos de usuarios:

Tipo Usuario Horario Restricciones

Docente Planta I6AM – 10 Tiene prioridad, puede usar el parqueadero (carro
PM o moto), carro incluso si hay Pico y placa
Docente Cátedra Por horas de Solo puede ingresar el vehículo en horario de
clase clase
Estudiante 6AM – 5PM Solo pueden ingresar motos si tiene asignado
Diurno parqueadero y hay cupos
Estudiante 6PM – 10PM Puede usar parqueadero de carros (No aplica en
Nocturno pico y placa) y motos solo si está autorizado y
hay disponibilidad
Administrativo 6AM – 10 Tiene prioridad, puede usar el parqueadero
PM incluso si hay Pico y placa
Tabla 22 Tipos de Usuarios y Restricciones

De acuerdo a cada tipo se crea un usuario en la base de datos, a continuación los flujos definidos
por cada uno y según sus restricciones.

a) Ingreso de autorización

Para que un usuario pueda loguearse a la aplicación una vez descargada debe, seleccionar la
opción “INFO”
 Figura 62 Opción Info

Se mostrará un formulario con los campos Upar, Cédula y opción Iniciar. Ingresar la
información.

Figura 63 Pantalla Inicio

 Si la información es válida el sistema carga la pantalla:

Figura 64 Completar Registro

Si la información no es válida indica:

Figura 65 Información de registro inválida

b) Ingreso a la aplicación

Para ingresar a la aplicación, seleccionar “Parking”, el sistema mostrará un formulario con los
campos Usuario, Contraseña y la opción Ingresar

Figura 66 Parking

Si los datos son válidos el usuario visualizará una de las siguientes opciones:

- Horario válido

Figura 67 Usuario con Horario valido

 - Fuera de horario

Figura 68 Usuario horario no valido

c) Consultar disponibilidad y selección de parqueadero

Para consultar la disponibilidad, solo los usuarios en horario válido podrán disponer de un
espacio en el parqueadero y seleccionarlo.

Para ocupar un espacio, el usuario una vez ingresó a la aplicación debe seleccionar el
parqueadero, y el sistema le mostrará su elección.
 Figura 69 Consulta disponibilidad espacio

Para apartar el espacio, debe seleccionar “Elegir” y el sistema le mostrará un mensaje de

confirmación

Figura 70 Elección de estacionamiento

Cuando el usuario salga del parqueadero debe ingresar a liberar el espacio ocupado; el sistema le
mostrará al ingresar el número de parqueadero que tiene asignado, debe seleccionarlo y hacer
clic en la opción “Liberar”

Figura 71 Opción liberar espacio

Figura 72 Usuario libera espacio

6.2.3 CONTROLADOR FÍSICO

El usuario controlador, será el encargado de generar las alertas por tiempo o mal uso del espacio
del parqueadero.

Figura 73 Modulo Control

a) Alerta por mal uso y tiempo

El usuario selecciona la opción Alerta de Uso, el sistema cargará en pantalla los parqueaderos
actualmente ocupados, para que seleccione al que se le va a generar la alerta de uso.
 Figura 74 Selección espacio para generación de alerta

Una vez seleccionado, se abre el formulario para ingresar el comentario de la alerta y enviarlo

Figura 75 Envío alerta por mal uso

PARTE III CIERRE DE LA INVESTIGACIÓN

CAPÍTULO 7 RESULTADOS Y DISCUSIÓN

Se crea un video para que se puedan visualizar las funcionalidades que conforman el prototipo
diseñado para el presente proyecto, donde se puede validar la disponibilidad de espacios y
seleccionarlo siempre y cuando sea un usuario registrado y autorizado. Según el perfil del
usuario podrá contar con sus funcionalidades correspondientes, está el caso del Administrador el
cual cuenta con opciones como configurar Parqueadero, la creación y eliminación de usuarios;
así mismo el usuario Controlador que se encargara de administrar las notificaciones que pueden
ser enviadas a los usuarios ya sea por temas de mal uso o por el horario permitido. Para ver el
video ir al siguiente enlace: https://youtu.be/tfFUK96i9Ds.

Para evaluar el prototipo en cuanto a las especificaciones propuestas y definidas para cumplir
con este proyecto y la aceptación de posibles usuarios midiendo el nivel de satisfacción, se crea
una encuesta donde se toma como muestra 4 personas que son el Director, revisor del proyecto,
un docente de catedra y un estudiante de la jornada Nocturna. Para conocer la encuesta aplicada
(Anexo 4_ Encuesta Satisfacción Prototipo Parking UD).

A partir de los resultados obtenidos en la aplicación de la encuesta, se analiza y se llega a las

siguientes conclusiones:

1. ¿El prototipo móvil es fácil de usar?

Figura 76 Grafica Encuesta - Respuesta Pregunta uno

Análisis: A partir de las respuestas obtenidas para esta pregunta, se puede concluir que los
usuarios encuestados opinan que el prototipo es sencillo, lo que hace que ellos tengan una
experiencia agradable y comodidad en el uso, e interacción con el prototipo.
2. ¿El diseño del prototipo móvil es agradable para su uso?

Figura 77 Grafica Encuesta - Respuesta Pregunta dos

Análisis: Ante esta pregunta los usuarios encuestados opinaron que si es agradable, es decir
que cuenta con interfaces que brindan un entorno sencillo visualmente, por el que pueden
navegar y ejecutar las acciones que necesitan de una manera rápida y fácil.

3. ¿Cree usted que este prototipo facilitará el uso y servicio que presta el parqueadero de la
UD - Sede Calle 40?

Figura 78 Grafica Encuesta - Respuesta Pregunta tres

Análisis: Ante la situación actual de funcionamiento del parqueadero de la UD-Sede sabio

Caldas, la propuesta planteada en este proyecto y plasmada a nivel de software en el
prototipo, hace que la mayoría de usuarios encuestados estén de acuerdo con el beneficio
 que puede traer esta en cuanto al funcionamiento y optimización de procesos dentro del
parqueadero.

4. ¿Qué tan satisfecho quedo usted con el uso del prototipo móvil, para uso del parqueadero
UD-Sede Calle 40?

Figura 79 Grafica Encuesta - Respuesta Pregunta cuatro

Análisis: Las respuestas en esta pregunta están divididas entre un nivel de satisfacción alto,
medio, y una respuesta baja, esto es importante teniendo en cuenta que es la primera versión
generada y que puede tener mejoras para proyectos futuro. Por esto se decidió plantear la
pregunta 7 de donde se podrán tomar los comentarios y sugerencias para tenerlos en cuenta
y poder generar las mejoras correspondientes.

5. Una vez la aplicación este completa y sea implantada, ¿Usted está dispuesto a usarla?

Figura 80 Grafica Encuesta - Respuesta Pregunta cinco

 Análisis: Esta pregunta está relacionada con la pregunta 3, la mayoría de los usuarios están
de acuerdo con que la solución propuesta facilitara las funciones del parqueadero y
mejorara el servicio para los usuarios, estando de acuerdo con usarla una vez sea
implantada en un futuro. En cuanto a la respuesta negativa que se tuvo, se tendrá en cuenta
para realizar las mejoras correspondientes.

6. ¿Recomendaría usted en un futuro, esta aplicación?

Figura 81Grafica Encuesta - Respuesta Pregunta seis

Análisis: En esta pregunta casi toda la población encuestada está de acuerdo en que
recomendaría la aplicación, y se puede inferir que en caso de finalizada la aplicación tendrá
una buena acogida entre la población objetivo, pero se debe tener en cuenta que para poder
tener un 100% de acogida para una próxima versión se realizaran las sugerencias realizadas
en el punto 7.

7. Por favor escriba sus comentarios o sugerencias, para poder tenerlas en cuenta en una futura
versión.

Figura 82 Grafica Encuesta - Respuesta Pregunta siete

Análisis: Estos comentarios serán tenidos en cuenta para mejorar la solución e
implantarlos en versiones futuras.
CAPÍTULO 8 CONCLUSIONES
En este apartado se plasmarán todas las conclusiones obtenidas a través del desarrollo de los
objetivos planteados, para la solución de este proyecto.

4.1 VERIFICACIÓN, CONTRASTE Y EVALUACIÓN DE LOS OBJETIVOS

En el proyecto de grado “DISEÑO DE PROTOTIPO DE SOFTWARE MÓVIL PARA LA
PROGRAMACIÓN Y CONTROL DEL PARQUEADERO UD” se generó un prototipo para una
aplicación móvil cuyo objetivo principal es el de facilitar la vista de disponibilidad de los
espacios de parqueo situados en los sótanos 2 y 3 de la sede calle 40 de la Universidad Distrital
“Francisco José de Caldas”, antes, durante y al finalizar el proyecto se generaron la siguientes
conclusiones:

Alrededor del negocio de los parqueaderos se pueden identificar problemáticas o necesidades

desde el punto de vista del usuario como del propietario con esto se pretendía atacar inicialmente
como propuesta del proyecto el sistema de reserva de parqueaderos integrado con un sistema de
tarificación y facturación con cargo a la tarjeta de crédito y generación de códigos QR enviados a
la cuenta de correo del usuario final y/o propietario, sin embargo, la limitación en cuanto a
reglamentación o estandarización facilita la puesta en funcionamiento de los parqueaderos y
sumados a la demanda de uso hace que los propietarios no requieran el invertir en la
sistematización de los mismos, por tanto, se concluye la necesidad de generar un estudio de
mercado que soporte la propuesta sobre prototipos de software con fines comerciales.

La construcción del primer objetivo planteado “Definir los roles, funciones y requerimientos de
los usuarios del sistema” ha contribuido a la identificación de las necesidades que suplirá la
solución propuesta, teniendo como base los usuarios directamente implicados en el uso del
sistema.

El parqueadero de la sede calle 40 de la Universidad Distrital está sujeto a la aplicación de

directrices propias de la universidad consignadas en sus resoluciones emitidas y a la vez se
adoptan lineamientos emanados de la alcaldía mayor de Bogotá en cabeza de su alcalde y los
cuales se deben cumplir por parte de la universidad como ente distrital, de esta manera, la
definición de roles funciones y requerimientos estuvo sujeta al análisis de esta normatividad o
disposiciones en la asignación y control del parqueadero.

Las políticas de asignación de los parqueaderos por parte de la dirección de recursos físicos de la
Universidad Distrital no cuentan con un control del todo sistematizado, esto hizo que en el
momento de definir el modelo de entidades, los casos de uso, diagramas, entre otros, se
analizaran diferentes alternativas, pretendiendo en todo momento hacer un diseño óptimo y
viable teniendo en cuenta adicionalmente los factores externos del proyecto como el factor
tiempo.

Entre las alternativas de metodología de desarrollo analizadas se discutieron las opciones de

metodología ágil SCRUM y la metodología convencional RUP, desde el punto de vista de
proyecto y desde el punto de vista de desarrolladores, en dónde se logró comprobar que en aras
del proyecto, RUP ofrece un esquema sólido sobre todo en la etapa de diseño, de SCRUM se
resalta el manejo de las comunicaciones continuas para generar una etapa de procesos más
adaptativo al resultado que se pretendía obtener, en este caso, el prototipo de software.

El proyecto ha logrado cumplir con el objetivo general y con los objetivos específicos que se
habían propuesto haciendo valer todos y cada uno de los requerimientos planteados logrando
obtener un prototipo de aplicación móvil en la que se genera una relación sinérgica entre los tres
pilares o roles del proceso asociado al parqueadero como lo son el administrador, el controlador
físico o guarda de seguridad y como no, el usuario final, adicionalmente integrando una
normatividad traducida a reglas de negocio dentro en el lenguaje de la aplicación.

Por último, se lograron identificar nuevas vertientes del proyecto no incluidas en el alcance del
mismo y que se propone continuar con su investigación y desarrollo en futuros proyectos, entre
los que se mencionan, propuestas para integrar mecanismos electrónicos como sensores de
proximidad o ubicación, control de acceso automatizado diferente a tarjetas inteligentes o con la
integración de otros procesos a éstas, modelos de optimización para la asignación de
parqueaderos con base en la demanda de uso, así como estudios de inteligencia de mercados
cuando se quiera generar una propuesta de sistemas de información para parqueaderos en
entidades públicas o privadas.

4.2 SÍNTESIS DEL MODELO PROPUESTO

El prototipo propuesto en el presente documento se puede analizar a través del siguiente
diagrama BPMN en donde se muestran las diferentes interacciones o procesos de cada uno de los
actores del sistema
Figura 83 Diagrama BPMN Prototipo Parqueadero UD
CAPÍTULO 9 PROSPECTIVA DEL TRABAJO DE GRADO

9.1 LÍNEAS DE INVESTIGACIÓN FUTURAS

Para el problema analizado en el presente documento, su solución planteada no resulta suficiente

teniendo en cuenta el nivel de demanda de uso del parqueadero y la restricción en el número de
espacios de los sótanos 2 y 3 en la sede calle 40, el problema ahora consiste en generar una
programación de asignación de los espacios para los usuarios solicitantes de tal manera que se
optimice el tiempo y el recurso, de esta manera se presenta una propuesta teórica basada en la
investigación operativa de un modelo de optimización en la asignación de parqueaderos el cual
pretendemos sea abordado e implementado en un futuro proyecto de investigación.

En el siguiente aparte (9.1.1) se recopila la teoría básica de la investigación operativa y de cómo

elaborar un modelo de optimización, de esta manera, con el fin de darle un soporte teórico a la
propuesta se elabora un resumen tomado del documento “Modelos Matemáticos de
Optimización” elaborado por los Ingenieros Andrés Ramos, Pedro Sánchez, José María Ferrer,
entre otros, para la Universidad Pontificia COMILLAS de Madrid, España., adicionalmente en
este documento se presenta una guía paso a paso de aplicaciones del modelado en el programa
GAMS.

En el aparte 9.1.2 presentamos la propuesta inicial del modelo de optimización para la asignación
de parqueaderos especialmente enfocados a docentes de planta apuntando a la carga académica
registrada en el sistema cóndor.

9.1.1 INVESTIGACIÓN OPERATIVA Y OPTIMIZACIÓN

Para profundizar en los conceptos de este aparte, leer páginas de la 3 a la 15 del documento
“Modelos Matemáticos de optimización” (Ramos, Sánchez, Ferrer, Barquín, & Linares, 2010).

La Investigación Operativa consiste en “la aplicación de métodos científicos en la mejora de la efectividad en las
operaciones, decisiones y gestión” (Robinson, 1999) o como la ciencia de aplicar los recursos disponibles
para conseguir la satisfacción óptima de un objetivo específico deseada, de una forma extensa de puede
definir como la aplicación por grupos interdisciplinarios, del método científico a los problemas complejos
producidos en la dirección y gestión de grandes sistemas de hombres, máquinas, entre otros. La
investigación operativa se caracteriza por intentar construir un modelo científico del sistema del cual se
puede predecir y comparar los resultados de diversas estrategias, decisiones, incorporando medidas del azar
y del riesgo, su objetivo es ayudar a los responsables a determinar su política y actuaciones en forma
científica, por tanto y en este sentido se le conoce en otros términos como Management Science o análisis
de decisiones (Ramos, Sánchez, Ferrer, Barquín, & Linares, 2010)

Una de las disciplinas derivadas de la investigación operativa es la optimización en cada uno de sus métodos (lineal,
no lineal, entera, estocástica, multiobjetivo) como lo son también las teorías de juegos, decisión, grafos,
colas y simulación, o flujos de redes. Otras disciplinas que aunque pueden ser tratadas dentro de la
investigación de operaciones, al tener un mayor nivel de complejidad son tratadas y analizadas dentro del
área de estudio de la inteligencia artificial, tales como los algoritmos metaheurísticos, lógica borrosa e
inteligencia artificial compartiendo materia de estudio con la estadística (Ramos, Sánchez, Ferrer, Barquín,
& Linares, 2010)
La optimización como materia de estudio dentro de la investigación de operaciones tiene una gran relevancia, como
tal ha tenido un progreso algorítmico vertiginoso con el descubrimiento de técnicas de análisis durante la
historia como la programación lineal, programación dinámica, con sus respectivos métodos desde la década
de los 40 hasta la actualidad sino en los métodos de procesamiento de datos que terminan reduciendo el
tiempo de respuesta en la obtención de la solución esperada, un ejemplo de ello es que en la actualidad se
puede resolver un problema de programación lineal de más de 500.000 ecuaciones con más de 500.000
variables y más de 2.000.000 de restricciones, los problemas de optimización se componen de tres
elementos que son (Ramos, Sánchez, Ferrer, Barquín, & Linares, 2010):

 Función objetivo: medida cuantitativa del funcionamiento del sistema que se desea optimizar
(maximizar o minimizar)
 Variables: representan las decisiones que se pueden tomar para afectar el valor de la función objetivo,
las cuales se pueden clasificar en variables independientes, principales o de control o variables
dependientes, auxiliares o de estado, matemáticamente con igual representación
 Restricciones: conjunto de relaciones (expresadas por ecuaciones e inecuaciones) que ciertas variables
están obligadas a cumplir.

Entonces, resolver un problema de optimización consiste en encontrar el valor que deben tomar las variables para
hacer óptima la función objetivo satisfaciendo el conjunto de restricciones (Ramos, Sánchez, Ferrer,
Barquín, & Linares, 2010).

9.1.1.1 Modelo de optimización

Un modelo es una representación matemática simplificada de una realidad compleja. Modelar es la acción de
construir un modelo, de ajustar la realidad. Relaciona (dos figuras no necesariamente personas), al
modelador (quien se encarga de especificar y desarrollar el modelo) y el experto sobre la realidad
(conocedor del escenario o problema real), Un modelo debe equilibrar la necesidad de contemplar todos los
detalles con la factibilidad de encontrar técnicas de solución adecuadas. Un modelo es, en definitiva, una
herramienta de ayuda a la toma de decisiones, por tal razón los resultados que se generen deben ser
comprensibles y aplicables, modelar se puede concebir como ciencia y como arte, ciencia porque se basa en
un conjunto de procesos estructurados: análisis y detección de las relaciones entre los datos,
establecimiento de suposiciones y aproximaciones en la representación de los problemas, desarrollo o uso
de algoritmos específicos de solución, arte porque materializa una visión o interpretación de la realidad no
siempre de manera univoca, el desarrollo de un modelo es una creación hecha con ayuda de ciencias básicas
o herramientas de apoyo. (Ramos, Sánchez, Ferrer, Barquín, & Linares, 2010).

Entre los beneficios explícitos o implícitos, tanto para el modelador como para el experto, derivados del proceso de
modelado además del modelo en sí mismo, se pueden mencionar:

 Ayuda a establecer un dialogo con intercambio de información entre el modelador y el experto

 Organiza los datos, la información disponible sobre el sistema
 Organiza, estructura y mejora la comprensión del sistema
 Internaliza la estructura organizativa de la empresa
 Permite compartir supuestos y resultados entre el modelador y el experto
 Proporciona un entorno ágil para el análisis y la sensibilidad
 Indica la dirección de mejora en las decisiones

9.1.1.2 Etapas en el desarrollo de un modelo

Como si se tratase de un proyecto en sí, el desarrollo de un modelo tiene un ciclo de vida determinado en una serie
de etapas ordenadas y una dependiente de la anterior, las cuales son:

La identificación del problema que consiste en la recolección y análisis de la información relevante para el
problema, en el intercambio de información entre el modelador y el experto, en establecer una relación
 simbiótica y una estrecha coordinación entre ambos, esta etapa es fundamental para que las soluciones
proporcionadas, las conclusiones obtenidas sean útiles, las decisiones adoptadas sean correctas. Los datos
suelen ser vitales para conseguir un realismo o aplicabilidad en las soluciones. A menudo representan el
cuello de botella del proceso de modelado. (Ramos, Sánchez, Ferrer, Barquín, & Linares, 2010).

La especificación matemática y formulación la cual está dada en la escritura matemática del problema de
optimización, definiendo sus variables, sus ecuaciones, su función objetivo, sus parámetros. En esta etapa
se analiza el tamaño del problema, la estructura de la matriz de restricciones, su tipo (Programación Lineal,
Entera mixta, No Lineal). Es una etapa de creación donde se debe prestar especial atención a la precisión en
la formulación y a la escritura de las ecuaciones que describen el problema (Ramos, Sánchez, Ferrer,
Barquín, & Linares, 2010).

Para efectos del presente trabajo, se tratará un problema de programación lineal en el cual su elección no afecta de
manera significativa la resolución del mismo. La caracterización de un problema LP según su tamaño
resulta difícil y ha sufrido un gran cambio desde los recientes desarrollos de algoritmos simplex mejorados
y, sobre todo, desde la aparición de los métodos de punto interior. En la tabla 23 se propone una
clasificación de tipos de problemas de programación lineal según su tamaño. Esta clasificación debe ser
tomada como guía o referencia relativa donde se debe tener en cuenta que los tamaños relativos de los
problemas cambian conforme evolucionen los códigos de optimización (Ramos, Sánchez, Ferrer, Barquín,
& Linares, 2010).

Restricciones Variables
Caso Ejemplo 100 100
Tamaño medio 10000 10000
Gran Tamaño 100000 100000
Muy Gran Tamaño > 100000 > 100000
Tabla 23 Tipos de problemas de programación lineal según su tamaño

En la resolución se trata de implantar un algoritmo de obtención de la solución numérica (muy próxima a la

matemática) optima o cuasi óptima. El algoritmo puede ser de solución de un problema o diferentes
implantaciones de un mismo método. El tiempo de resolución de un problema también puede depender
drásticamente de como este formulado. La solución óptima debe ser suficientemente satisfactoria, debe ser
una guía de actuación para el experto (Ramos, Sánchez, Ferrer, Barquín, & Linares, 2010).

Posteriormente pasamos a la etapa de verificación, validación y refinamiento en donde se busca eliminar los errores
de codificación, en otras palabras, hacer que el modelo haga lo que se le indicó matemáticamente en la
etapa anterior pasándolo ya a lenguaje de máquina, en esta etapa es probable que se deba refinar el modelo
para que este se ajuste cada vez más a la realidad que se quiere representar así como también deba refinarse
el modelamiento matemático (Ramos, Sánchez, Ferrer, Barquín, & Linares, 2010).

La etapa de interpretación y análisis de resultados conlleva a la búsqueda o propuesta de soluciones para conocer el
detalle o comportamiento del modelo haciendo un análisis de sensibilidad en las entradas del modelo, se
analizan además los posibles escenarios, acercarse a la solución óptima y comprobar su capacidad (Ramos,
Sánchez, Ferrer, Barquín, & Linares, 2010)

Por último, en aras de difundir la solución se llega a la implementación, documentación y mantenimiento del modelo
propuesto, como si se tratara de un proyecto de software, la documentación debe ser lo suficientemente
clara y precisa para el usuario, tanto para el modelo como para el código implementado y así garantizar las
tareas de mantenimiento pertinentes, pues es allí donde se concentra el mayor porcentaje del ciclo de vida
del modelo y finalmente ha de incluirse un plan de entrenamiento al usuario final (Ramos, Sánchez, Ferrer,
Barquín, & Linares, 2010).
9.1.2 MODELO DE OPTIMIZACIÓN PARA LA ASIGNACIÓN DE PARQUEADEROS

La gestión de la asignación de parqueaderos a docentes en cualquiera de las sedes de la

Universidad “Francisco José de Caldas” resulta crítica debido a la limitación de espacios y la
distribución que por carga académica es asociada a cada docente, al mismo tiempo los docentes
pueden tener distintas preferencias de solicitud de asignación y algunos parqueaderos pueden no
estar disponibles, en síntesis, son diferentes las restricciones que se presentan en el momento de
la asignación.

Es así como se pretende que la reprogramación de los parqueaderos sea inmediata, es decir, el
objetivo de la programación o de la asignación es encontrar un sistema eficiente en donde se
optimice el recurso en este caso el tiempo de asignación de parqueadero en condiciones de
incertidumbre.

Trabajos relacionados con los problemas de planificación han sido elaborados, entre ellos en la
implementación de la asignación de funciones de grupo (GRA) el cual tiene un modelo de
solución de complejidad exponencial, sin embargo, diferentes estudios han abordado este mismo
problema llevándolo a un problema de complejidad polinómica y es con este enfoque que se
presenta el modelo de solución en la asignación de parqueaderos.

EL planteamiento del problema se hace con las premisas de asignación a docentes de la

universidad basados en su carga académica registrada en el sistema cóndor y con un horizonte
de asignación de 2 semanas, en un primer caso una de las semanas presenta la restricción de día
no carro por disposición de la alcaldía dirigida a sus entes distritales entre ellas la universidad,
este día puede ser el primer jueves de cada mes o la fecha dispuesta por decreto (por lo general
es jueves)

Lun Mar Mié Jue Vie Lun Mar Mié Jue Vie
06:00 0 9 17 25 33 41 49 57 65 73
08:00 1 10 18 26 34 42 50 58 66 74
10:00 2 11 19 27 35 43 51 59 67 75
12:00 4 12 20 28 36 44 52 60 68 76
14:00 5 13 21 29 37 45 53 61 69 77
16:00 6 14 22 30 38 46 54 62 70 78
18:00 7 15 23 31 39 47 55 63 71 79
20:00 8 16 24 32 40 48 56 64 72 80
Tabla 24 Horizonte de asignación con día de no carro
 Lun Mar Mié Jue Vie Lun Mar Mié Jue Vie
06:00 0 9 17 25 33 41 49 57 65 73
08:00 1 10 18 26 34 42 50 58 66 74
10:00 2 11 19 27 35 43 51 59 67 75
12:00 4 12 20 28 36 44 52 60 68 76
14:00 5 13 21 29 37 45 53 61 69 77
16:00 6 14 22 30 38 46 54 62 70 78
18:00 7 15 23 31 39 47 55 63 71 79
20:00 8 16 24 32 40 48 56 64 72 80
Tabla 25 Horizonte de asignación sin restricción

La carga académica mencionada anteriormente precargada en el sistema cóndor puede ser

representada por conjuntos de relaciones bihorarias, es decir, cada franja dentro del horizonte de
asignación representa un periodo de tiempo de 2 horas coincidente con la asignación académica
de cada docente, a partir de allí elaboramos los conjuntos de requerimientos de uso del
parqueadero para todos los docentes.

Docente Prioridad Requerimientos de parqueo

Roberto Lunes{5,6}, miércoles{21,22}, viernes {29,30,31,32}, lunes{45,46},
3
Ferro miércoles{61,62}, viernes{77,78}
Alexandra Martes{13,14,15,16}, jueves{29,30,31,32}, Martes{53,54,55,56},
2
Abuchar jueves{69,70,71,72},
Jairo Lunes{5,6},martes{13,14},miércoles{21,22},jueves{29,30},viernes{37,38},
3
Londoño Lunes{45,46},martes{53,54},miércoles{61,62},jueves{69,70},viernes{77,78}
Todos los días antes de medio día
Édgar
2 {0},{1},{2},{9},{10},{11},{17},{17},{19},{25},{26},{27},{33},{34},{35},{41},{4
Rincón
2},{43},{49},{50},{51},{57},{58},{59},{65},{66},{67},{73},{74},{75}
Roberto
1 Todos los días, en todo momento {0}….{80}
Pava
Todos los días después de medio día
Giovanni {5},{6},{7},{8},{13},{14},{15},{16},{21},{22},{23},{24},{29},{30},{31},{32},{3
3
Tarazona 7},{38},{39},{40},{45},{46},{47},{48},{53},{54},{54},{56},{61},{62},{63},{64}
,{69},{70},{71},{72},{77},{78},{79},{80}
José
Todos los días después de mediodía en la primera semana
Ignacio 2
{5,6,7,8},{13,14,15,16},{21,22,23,24},{20,30,31,32},{37,38,39,40}
Palacios
Tabla 26 Conjuntos de licitación de los docentes

Se lista a continuación la terminología utilizada y su significado correspondiente

Símbolo Significado
𝒫 conjunto de parqueaderos
Ω conjunto de espacios bihorarios
𝒥 Conjunto de docentes
Conjunto de espacios bihorarios asignados por carga académica o conjunto de
ℬ
licitación de los docentes
ℬΩ Conjunto asignación de licitación de espacios o franjas y espacios bihorarios
𝒥ℬ Conjunto asignación de docente y licitación.
 Conjunto de valores de prioridad de los docentes (roles), dónde 𝒲𝑗 será el valor de
𝒲
prioridad asignado al docente 𝑗𝜖J
Tabla 27 Terminología utilizada en el desarrollo del modelo

El modelo matemático de solución se presenta a continuación teniendo en cuenta las

restricciones que unicidad en la asignación de parqueaderos y bloques de licitación o solicitudes
de los docentes:

𝑚𝑎𝑥∆ = ∑ ∑ 𝑋(𝐽, 𝑃, 𝐵) 𝑥 𝑊𝑗 (1)

𝑏∈𝐵 𝑗∈𝐽
Figura 84 Función Objetivo del modelo de asignación.

Sujeto a:

∀𝑗𝜖𝐽, i𝜖Ω ∑ 𝑋(𝐽, 𝑃, 𝐵) ≤ 1 (2)

ℬΩ

∀𝑗𝜖𝐽 ∑ 𝑋𝑗 (𝐽, 𝑃, 𝐵) = ∀𝑝𝜖𝑃, 𝑏𝜖𝐵 ∑ 𝑋𝑗 (𝐽, 𝑃, 𝐵) (3)

𝐽 𝐽𝐵

∀𝑗𝑏𝜖𝐽𝐵 ∑ 𝑋(𝐽, 𝑃, 𝐵) ≤ 1 (4)

𝑃
Figura 85 Restricciones asociadas al modelo de asignación

En donde la restricción:

(2) Asegura que cada franja bihoraria en un parqueadero determinados se le asigne solamente a
un DOCENTE.

(3) Asegura que el bloque de licitación asignado fue realmente solicitado por el DOCENTE.

(4) Asegura que un DOCENTE y un bloque de licitación solo se le puede asignar un

parqueadero;

Se implementa este modelo en GAMS, definiendo en primera instancia los conjuntos (sets o
multisets), es decir, el conjunto de parqueaderos (a modo de piloto de prueba se tomaron 6
espacios de parqueo), el conjunto de espacios (bloques bihorarios), conjunto de docentes (7
docentes para efectos de prueba), las licitaciones o preferencias de los docentes y los conjuntos
de asignación correspondientes (preferenciasespacios, docentespreferencias) tal como se
muestra en la siguiente Figura:
 Figura 86 Definición de conjuntos y parámetros en GAMS

Acto seguido, se definen las prioridades de los docentes o parámetros, variables, ecuaciones y
método de solución, ver la siguiente Figura:

Figura 87 Definición de variables, ecuaciones y métodos de solucione en GAMS

Se requiere un sistema potente de cálculo para simular las iteraciones requeridas, las
características necesarias son propias de GAMS, el cual en la ejecución del modelo genera el
siguiente resultado:

Figura 88 Resultado generado por GAMS al ejecutar el modelo de optimización

Figura 89 Resultado generado por GAMS al ejecutar el modelo de optimización

El resultado puede interpretarse como la mejor asignación posible que puede hacerse de los 6
parqueaderos de acuerdo a las preferencias de los docentes y teniendo en cuenta el conflicto que
puede llegar a presentarse.

Se pretende presentar entonces un modelo base para ser profundizado en el futuro como
continuación del proyecto en donde se agregue un nuevo índice que indica la expansión
estudiantes o administrativos y parqueaderos de otras sedes y el cual genere la mejor asignación
posible.

9.2 TRABAJOS DE INVESTIGACIÓN FUTUROS

Durante el desarrollo del proyecto se encontraron variantes de interés dentro del contexto
abordado así como de consulta de disponibilidad o programación para la asignación de los
estacionamientos en cualquier otra sede de la universidad distrital “Francisco José de Caldas”
como en el parqueadero de cualquier sede organizacional tales como conjuntos residenciales,
centros comerciales o empresas privadas.

Las líneas de investigación futuras que se relacionan a continuación se derivan de los

cuestionamientos o análisis de cada uno de los factores limitantes de la investigación y que por
motivos de alcance no fueron desarrollados en el presente proyecto de investigación, se espera
que estas líneas de investigación futuras puedan ser desarrolladas dentro del marco de un
proyecto de grado para programas de pregrado de ingeniería o afines, como en programas de
especialización o tema de profundización para grupos de investigación. Entre las posibles líneas
de investigación o trabajos futuros podemos encontrar:

 Diseñar un sistema inteligente de asignación de parqueaderos con sistema de sensores

de posición y proximidad en el sitio de parqueo, acceso con tarjetas inteligentes para
otorgar credenciales y asignación de horarios con base en la información registrada en el
sistema cóndor, proyecto enfocado en los parqueaderos de cada una de las sedes de la
universidad distrital “Francisco José de Caldas”.

 Realizar un estudio con la población total de la universidad distrital “Francisco José de

Caldas” con el fin de obtener un resultado 100% real de demanda del parqueadero de
cada de sus sedes y utilizarlo como información base para el diseño de un sistema de
asignación.

 Realizar un estudio de factores críticos de movilidad en la ciudad de Bogotá,

resoluciones emanadas por la ministerio de transporte, secretaría de movilidad de la
alcaldía mayor y resoluciones privadas del ente distrital o privado para priorizar el uso
de parqueaderos con el fin de desarrollar un modelo predictivo de uso de los
parqueaderos, sus resultados generarán información de entrada para definir nuevas
resoluciones.
 Integrar un modelo matemático de optimización basado en la investigación de
operaciones para la asignación de lugares de parqueo basados en solicitudes de demanda,
prioridades y distancia.
BIBLIOGRAFÍA
Baltopoulos, I. G. (2005). Introduction to Web Services. Web Services Related Standards. Geneve, Switzerland.
BOGOTA, A. (1992). Recuperado el 2016, de alcaldiabogota.gov.co:
http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=2107
Date, C. (2001). Introducción a los sistemas de bases de datos. Pearson Prentice Hall.
Dointech. (s.f.). Obtenido de http://www.dointech.com.co/control-acceso-vehicular.html
Garcia, M. M. (2014). Modelos de proceso del software. Universidad de Salamanca, Salamanca. Obtenido de
http://avellano.usal.es/~mmoreno/ASTema2.pdf
Huang, J., Gupta, V., & Huang, Y. (2012). Scheduling Algorithms for PHVE Charging in Shared Parking Lots.
American Control Conference.
Ingeniería MCI Ltda. (s.f.). Arduino. Recuperado el 26 de 09 de 2016, de http://arduino.cl/que-es-arduino/
INTECO. (2004). LA TECNOLOGÍA NFC: APLICACIONES Y GESTIÓN DE SEGURIDAD.
Londoño, J. J. (2016). MODELO SEUDOMATEMÁTICO PARA EL DISEÑO DE LAS BASES DE DATOS
RELACIONALES. Bogotá.
LUZ, F. L. (2013). SISTEMA PARA LA ADMINISTRACIÓN DE UN ESTACIONAMIENTO PÚBLICO. MEXICO:
UNIVERSIDAD NACIONAL AUTÓNOMA DE MEXICO.
MINTIC. (Mayo de 2015). Obtenido de http://www.mintic.gov.co/portal/604/w3-propertyvalue-568.html
OCDE. (2015). Perspectivas de la OCDE sobre la economía digital 2015. Paris.
Perez, D. R. (2016). Implementación de un prototipo para la gestión de parqueaderos en la universidad de las
Americas. Santiago, Chile.
Pupiales, P. W. (2009). Diseno de un Sistema de Control de Acceso utilizando la tecnologia de Identificacion RFID
para la empresa soluciones G Cuatro del Ecuador CIA. LTDA. Quito: Escuela Politecnica Nacional.
Ramos, A., Sánchez, P., Ferrer, J., Barquín, J., & Linares, P. (2010). Modelos Matemáticos de Optimización.
Madrid.
Ribas Lequerica, J. (2003). Web Services (edición especial).
Robinson, R. (1999). Welcome to or Territory OR MS Today.
Sandoval, R. (26 de Abril de 2016). Linkedin. Obtenido de https://www.linkedin.com/pulse/para-que-sirve-un-
sistema-de-control-acceso-rovillel-sandoval
Semana. (2015). Colombia, el país de los ‘smartphones’. Semana.
Smart Card Alliance Latin America (SCALA). (2006). Uso de Tarjetas Inteligentes para un Control de Acceso
Físico. Smart Card Alliance, Princeton. Obtenido de http://www.smartcardalliance.org
Tarjetas Inteligentes. (s.f.). Negocios de Seguridad.
Tatiana Naranjo, J. M. (4 de Marzo de 2009). Obtenido de http://server-die.alc.upv.es/asignaturas/PAEEES/2008-
09/Sensor%20Infrarrojo%20-%20Grupo%20Naranja.pdf
Torrente Artero, O. (2013). ARDUINO Curso práctico de formación. Ciudad de México: Alfa Omega Grupo Editor.
UIT destaca avances TIC en Colombia. (03 de 08 de 2015). El tiempo.
Universidad Distrital "Francisco José de Caldas". (26 de marzo de 1999). SISGRAL. Obtenido de Sistema de
Información de Secretaría General - UD:
https://sgral.udistrital.edu.co/xdata/sisgral.php?qry=on&id_doc=2143
Universidad Distrital "Francisco José de Caldas". (29 de julio de 2002). SISGRAL. Obtenido de Sistema de
Información de Secretaría General - UD: http://sgral.udistrital.edu.co/xdata/rec/res_2002-1101.pdf
Universidad Distrital "Francisco José de Caldas". (23 de marzo de 2010). SISGRAL. Obtenido de Sistema de
Información de Secretaría General - UD:
http://sgral.udistrital.edu.co/xdata/sisgral.php?qry=on&id_doc=5520
VENKATARAMANAN, M., & BORNSTEIN, M. (1991). A DECISION SUPPORT SYSTEM FOR PARKING
SPACE ASSIGNMENT. MATHL COMPUT MODELING. págs. 71-76.
Vilanoveta, P. I. (2015). Tecnología NFC, modalidades operativas y aspectos técnicos. FQ Ingenieria Electronica.
Obtenido de http://www.fqingenieria.com/es/conocimiento/tecnologia-nfc-modalidades-operativas-y-
aspectos-tecnicos-47
Villegas, J. (22 de Febrero de 2009). TECNOSeguro. Obtenido de https://www.tecnoseguro.com/faqs/control-de-
acceso/%C2%BF-que-es-un-control-de-acceso.html
ANEXOS
ANEXO 1
A continuación imagen del cronograma definido con tres recursos; para mayor detalle ver el archivo “CronogramaParking.gan”
ANEXO 2
Se realiza encuesta a uno de los vigilantes de la Universidad Distrital Francisco José de Caldas –
Sede Sabio Caldas quien habla de cómo es el funcionamiento actual del parqueadero. Para más
detalle ver el documento “Acta Reunión 29082016.doc.

ANEXO 3
Para conocer el manejo actual de las autorizaciones y prioridades de los usuarios que pueden
ingresar se tuvo una reunión con Don “Armando Buitrago Sarmiento” quien pertenece al área de
Recursos Físicos de la Universidad Distrital Francisco José de Caldas – Sede Sabio Caldas. Para
mayor detalle ver el documento “Acta Reunión 23092016.doc.

ANEXO 4

En este anexo “Encuesta Satisfacción Prototipo Parking UD.doc” se encuentra la encuesta

realizada a una pequeña muestra para evaluar la satisfacción de los posibles usuarios.