Gestión de turnos móvil

DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE ARQUITECTURA DE
SOFTWARE PARA ADMINISTRACIÓN DE TURNOS APOYANDO LA

ATENCIÓN AL CLIENTE EN DEPENDENCIAS PÚBLICAS DE LA CIUDAD DE
BOGOTÁ
SANDRA MILENA GUEVARA MORALES
DIRIGIDO POR:
Ph.D., MSC. ROBERTO FERRO ESCOBAR
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2017
DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE ARQUITECTURA DE
SOFTWARE PARA ADMINISTRACIÓN DE TURNOS APOYANDO LA
ATENCIÓN AL CLIENTE EN DEPENDENCIAS PÚBLICAS DE LA CIUDAD DE
BOGOTÁ
SANDRA MILENA GUEVARA MORALES
Cod. 20082020040
Trabajo de grado para optar al título de
Ingeniera de Sistemas
DIRIGIDO POR:
Ph.D., MSC. ROBERTO FERRO ESCOBAR
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2017
TABLA DE CONTENIDO
INTRODUCCIÓN .................................................................................................................. 5
1. PLANTEAMIENTO DEL PROBLEMA ....................................................................... 6
2. JUSTIFICACIÓN............................................................................................................ 8
2.1. JUSTIFICACIÓN TÉCNICA ...................................................................................... 8
2.2. JUSTIFICACIÓN ECONÓMICA ............................................................................... 8
2.3. JUSTIFICACIÓN AMBIENTAL................................................................................ 8
3. OBJETIVOS.................................................................................................................. 10
3.1. OBJETIVO GENERAL ............................................................................................. 10
3.2. OBJETIVOS ESPECÍFICOS .................................................................................... 10
4. ANTECEDENTES ........................................................................................................ 11
5. MARCO TEÓRICO ...................................................................................................... 13
5.1. Comunicación asíncrona ............................................................................................ 13
5.2. Programación orientada a eventos ............................................................................. 13
5.3. Javascript Asíncrono y XML (AJAX) ....................................................................... 16
5.4. Websockets ................................................................................................................ 16
5.5. Grupo de Investigación L.I.D.E.R: ............................................................................ 17
6. MARCO LEGAL Y NORMATIVIDAD ...................................................................... 19
6.1. NORMATIVIDAD EN COLOMBIA ................................................................... 19
6.2. PLAN ESTRATÉGICO DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ
DE CALDAS 2008 – 2016............................................................................................................ 21
7. METODOLOGÍA ......................................................................................................... 23
7.1. Enfoque investigativo ............................................................................................ 24
7.2. Población y muestra ............................................................................................... 25
7.3. Técnicas e instrumentos ......................................................................................... 25
7.4. Herramientas .......................................................................................................... 25
8. RESULTADOS ............................................................................................................. 27
8.1. Especificación funcional ........................................................................................ 28
8.1.1. Análisis de requerimientos ............................................................................. 28
8.1.2. Especificación de usuarios.............................................................................. 30
8.1.3. Casos de uso ................................................................................................... 31
8.1.4. Diagramas de actividades ............................................................................... 37
8.1.5. Bocetos de interfaz gráfica de usuario ............................................................ 39
8.1.6. Arquitectura del sistema ................................................................................. 40
8.2. Modelo de persistencia .......................................................................................... 43
8.3. Aspectos tecnológicos y de despliegue .................................................................. 51
8.3.1. Aplicación móvil ............................................................................................ 51
8.3.2. Aplicación servidor......................................................................................... 53
8.4. Pruebas de campo .................................................................................................. 55
9. LIMITACIONES .......................................................................................................... 60
10. CONCLUSIONES ..................................................................................................... 61
11. RECOMENDACIONES ........................................................................................... 62
12. ANEXOS ................................................................................................................... 63
13. REFERENCIAS ........................................................................................................ 66
INTRODUCCIÓN
Hoy en día varias ciudades hacen uso de la tecnología con el fin de mejorar la calidad de
vida de sus habitantes y así mismo mejorar la sostenibilidad y la competitividad. Estas
ciudades, también llamadas ciudades inteligentes, consideran factores clave tales como:
Planificación urbana, medio ambiente, cohesión social, movilidad y transporte, economía,
etc. La planificación urbana busca ejecutar procesos apoyados en la tecnología para
maximizar la productividad de la ciudad donde los habitantes realicen sus actividades de
manera eficiente.
Una exigencia evidente por parte de los usuarios en las instituciones que proveen servicios
es la asignación de turnos de manera eficiente y que en la actualidad no proporciona al
cliente un manejo apropiado de su tiempo mientras es atendida su necesidad, lo cual
generalmente es la causa de indisposición tanto de funcionarios como de consumidores.
Actualmente la implementación de un sistema de información por parte de cualquier

entidad que desee mejorar la experiencia de sus clientes a la hora de esperar su turno para
ser atendido, puede generar cambios positivos tanto en el rendimiento de sus trabajadores
como en sus finanzas, debido a que las dos partes tendrán mejor disposición a la hora del
encuentro.
Con el fin de proporcionar una solución a esta necesidad se propone el modelado y

desarrollo de un prototipo de software que permita a los usuarios solicitar turnos desde
cualquier sitio y que provea información como el turno actual, el tiempo estimado para ser
atendido y así él pueda realizar otras actividades. Contará con dos roles para usuarios;
cliente y administrador, este último acoge la funcionalidad de personalizar la aplicación
según el tipo de turnos manejados por la entidad.
1. PLANTEAMIENTO DEL PROBLEMA
Actualmente existen bastantes entidades que cuentan con un área de atención al cliente que
se encarga de atender las necesidades inmediatas de sus usuarios en el menor tiempo
posible. Desde hace algunos años varias de estas entidades han implementado la atención
virtual lo cual en un principio resolvió el problema de apilamiento de usuarios esperando
ser atendidos. Pero esta dificultad no ha sido solucionada debido a que las personas aún
deben esperar una cantidad de tiempo considerable para ser atendidas lo cual genera
indisposición, hostilidad y podría ser un factor negativo para la imagen de la corporación,
como lo respalda un estudio realizado por Elogia Research en enero de 2016 en el cual la
empresa Sotto Tempo puso a disposicion su departamento de atencion al cliente para
conocer el nivel de satisfaccion de sus clientes. El estudio tiene una muestra de 1196
estrevistas realizadas a hombre y mujeres entre los 18 y 64 años con diferentes ocupaciones
y dentro de las conclusiones reveladas es importante destacar las siguientes:
 Los tres principales canales de atencion al cliente mas utilizados por los usuarios
son: telefono, e-mail y sitio web.
 El 17% de los encuestados prefieren utilizar el canal presencial.
 El 50% utiliza canales digitales (e-mail, sitio web, aplicación, redes sociales, chat) y
tradicionales (telefono, personal), el 21% unicamente canales digitales y el 29%
utiliza solo canales tradicionales.
 1 de cada 2 personas considera irritante el tiempo de espera.
 La gran mayoria de los entrevistados (92%) considera que el servicio de atencion al
cliente es un factor de gran importancia para la construccion de la buena imagen de
la empresa.
 El 86% piensa que la innovacion en los canales de atencion mejora la imagen de la
corporación.
Las conclusiones del estudio anterior llevan a pensar que el servicio de atencion al cliente
es más importante de lo que parece al momento de captar nuevos clientes y crear fidelidad
entre los antiguos. La universidad Distrital maneja procesos que son bastante concurridos
por estudiantes, docentes y funcionarios en ciertas temporadas del año, por ejemplo,
inscripción manual de materias, asesorias académicas brindadas por dependencias, son
procedimientos que tienen tiempos variables de atención y no permiten que los interesados
tengan la posibilidad de hacer otras actividades en el lapso de espera.
Teniendo en cuenta que hoy en día las ciudades se están apoyando cada vez más en la
tecnología para brindar una mejor calidad de vida a sus habitantes con el objetivo de
incrementar la eficiencia de cada uno de ellos y en consecuencia de su propia ciudad, es
necesario que los canales tradicionales de atencion al cliente de las empresas hagan uso de
las nuevas tecnologias para incrementar su utilidad.
Formulación
¿Cómo la implementación de un sistema de administración de turnos como apoyo a la

atención al cliente puede incrementar la productividad de los usuarios y solucionar el
problema de congestión de clientes en las entidades públicas de la ciudad?
2. JUSTIFICACIÓN
2.1. JUSTIFICACIÓN TÉCNICA

El presente documento presenta una propuesta de trabajo de grado que busca innovar la
forma en que los usuarios de dependencias públicas de la ciudad de Bogotá solicitan turnos
para que sus inquietudes o trámites sean debidamente atendidos con la implementación de
un prototipo de software que funciona como aplicación web y que por este motivo es
multiplataforma respetando cualidades del software tales como: amigabilidad, usabilidad,
mantenibilidad, eficiencia y reusabilidad del código.
2.2. JUSTIFICACIÓN ECONÓMICA

Actualmente las ciudades necesitan habitantes eficientes y productivos para incrementar su
competitividad. Con la implementación de esta herramienta los usuarios podrán realizar
otras actividades mientras esperan ser atendidos con la garantía de ser atendidos en el
tiempo especificado por la aplicación. Esto permite a las personas administrar su tiempo de
una manera eficiente. Cabe destacar que este no es un sistema de agendamiento de citas,
debido a que está dirigido a las personas que necesitan realizar trámites en momentos no
previstos, sin realizar una solicitud de cita previa.
2.3. JUSTIFICACIÓN AMBIENTAL

Al implementar esta solución de software las personas harán uso de computadores, tablets o
smartphones para la solicitud de turnos y en consecuencia la cantidad de papel y tinta
utilizados para imprimir turnos en las entidades va a disminuir considerablemente
apoyando las políticas ambientales actuales.
La forma en que los usuarios de dependencias públicas de la ciudad de Bogotá solicitan

turnos para que sus inquietudes o trámites sean debidamente atendidos es ineficiente tanto
para trabajadores como para clientes. Actualmente las ciudades necesitan habitantes
eficientes y productivos para incrementar su competitividad. Con la implementación de esta
herramienta los usuarios podrán realizar otras actividades mientras esperan ser atendidos
con la garantía de que su solicitud será solucionada en el tiempo especificado por la
aplicación. Esto permite a las personas administrar su tiempo de una manera eficiente. De
igual manera cuando para una persona es imposible realizar un trámite debido a que se
encuentra en otro sitio donde es indispensable su presencia, se puede ver frustrada e
inclusive se podrían presentar problemas de tipo económico, salud, académico, etc.
Hoy en día las personas necesitan más tiempo para realizar otros trámites, compartir con
sus familias, ser más productivos en sus trabajos, pero claramente realizando una fila en
una entidad no es la mejor forma de optimizar el tiempo.
Adicionalmente esta propuesta plantea un sistema que permite a los asesores de los
departamentos de atención al cliente de las empresas públicas y privadas realizar llamados
desde sus propios dispositivos móviles, acabando así el hacinamiento de personas en el
establecimiento permitiendo que ellos realicen un mejor trabajo y mejoren la calidad de su
servicio.
3. OBJETIVOS
3.1. OBJETIVO GENERAL

Diseñar y desarrollar un prototipo de software para administracion de turnos apoyando la
atención al cliente en dependencias públicas de la ciudad de Bogotá.
3.2. OBJETIVOS ESPECÍFICOS

● Diseñar una aplicación para dispositivos android que permita elegir un tipo de
trámite y un turno, además de consultar el turno actual y el tiempo estimado para ser
atendido.
● Desarrollar una aplicación móvil basada en tecnologías web que permitirá elegir un
trámite y hacer un llamado al siguiente turno para soportar la aplicación movil.
● Diseñar el modelo de persistencia que almacenará los datos consumidos y generados
por la aplicación web y la aplicación movil.
● Realizar el despliegue del software en los servidores de la Red de Investigaciones de
Tecnología Avanzada – RITA de la Universidad Distrital Francisco José de Caldas.
● Implementar el sistema en el área de asesorias académicas de la Red de
Investigaciones de Tecnología Avanzada – RITA como caso de estudio.
● Realizar encuestas a los usuarios para generar estadísticas y conclusiones más
consistentes.
4. ANTECEDENTES
Las entidades que cuentan con una sección o departamento de atención al cliente tienen
como objetivo principal atender a la mayor cantidad de clientes y que estos tengan la mejor
experiencia desde su llegada hasta la atención de su petición. Actualmente se han
implementado varios sistemas de solicitud de turnos apoyados en tecnologías que permiten
al cliente solicitar un turno dentro de la corporación, la estación fisica lo imprime y el
cliente debe esperar dentro del lugar hasta que sea atendido, como es el caso de la gran
mayoria de entidades bancarias, prestadoras de servicios de salud y corporaciones con alto
flujo de usuarios que pretenden realizar tramites con la mayor eficiencia posible, tales
como: Banco Agrario de Colombia, Davivienda, Bancolombia, E.P.S. Sanitas, entre otras
entidades.
La Dirección de Impuestos y Aduanas Nacionales de Colombia (DIAN) posee un sistema

para el agendamiento de citas (Agendamientodigiturno.dian.gov.co, 2017) que está
compuesto por un formulario para ser diligenciado por el usuario indicando datos
personales, tipo de trámite que pretende realizar, el día y la hora en la que desea ser
atendido y al momento de realizar la solicitud envía un mensaje al correo señalado por el
cliente previamente advirtiendo al cliente que su envío fue realizado y que será atendido en
el horario pactado.
Algunas empresas han ido un poco más allá y han implementado sistemas tales como
Digiturno que tiene el siguiente ciclo de uso: el usuario debe desplazarse hasta el lugar,
solicitar su turno es la estación local y este imprime el turno y un código QR para ser leído
con un smartphone para generar notificaciones al cliente indicando el turno actual que está
siendo atendido y el turno asignado. Este sistema fue recientemente implementado en
algunas sucursales del Banco Agrario de Colombia. Digiturno (Cielingenieria.com, 2017)
es una empresa dedicada a producir soluciones tecnológicas para optimizar el servicio de
atención al cliente que cuenta con aproximadamente 8 productos. Su producto principal y
más completo es “Digiturno 5: Atención inteligente” el cual involucra funcionalidades
como la generación de reportes, interfaz de administración, plataforma web y movil para
agendar citas y encuestas y calificación del servicio.
Un proyecto desarrollado recientemente y patrocinado por Apps.co que va en la misma
línea de esta propuesta es Like Parrot (Likeparrot.com, 2017), un sistema orientado a
reforzar el servicio de atencion al cliente y las ventas a través de internet cuyas principales
funcionalidades son: establecer contacto directo y en tiempo real con el cliente a través de
chats que permiten la carga de archivos solo si es necesario para llevar a cabo el trámite
seleccionado, generar metricas, gestionar tickets, perfilar clientes según gustos y
preferencias, entre otras. Actualmente se encuentra en desarrollo permanente de nuevas
funcionalidades.
La característica en común de estas herramientas es el objetivo de brindar una mejor

experiencia a los usuarios que necesitan realizar un trámite al momento de solicitar turnos y
esperar ser atendido.
5. MARCO TEÓRICO
5.1. Comunicación asíncrona

En telecomunicaciones, comunicación asíncrona hace referencia a la transmisión de datos,
generalmente sin la dependencia temporal, donde un dato puede ser transmitido
intermitentemente en lugar de un flujo continuo. El aspecto más significativo de la
comunicación asíncrona es que los datos no son transmitidos en intervalos regulares, por lo
tanto, hace posible que la tasa de bits sea variable, y entonces el transmisor y receptor no
están sincronizados exactamente todo el tiempo. (Puranik y Feiock, 2013)
5.2. Programación orientada a eventos

En general la programación orientada a eventos, la actividad principal es la reacción a la
recepción de señales semánticamente significativas ("Eventos"). Las señales pueden ser de
cualquier fuente, incluyendo los sensores más comunes como la intervención humana (por
ejemplo, clic en un botón), temporizadores, la observación de estados compartidos, o
producidos durante el cálculo como resultado de la reacción de otras señales. (Mesa J.
2016).
Es importante observar que existe una posibilidad potencial de tener eventos reactivos
recursivos infinitos (al menos en el caso general), por lo tanto, para poner en práctica la
programación orientada a eventos en el caso general, es necesario proporcionar una cola de
mensajes (o colas). Una cola no impide la recursividad infinita, pero sí permite garantizar
que cada evento será manejado después de un recuento finito de pasos, incluso si existen
tales bucles. Sólo esta limitación impide que sistemas más orientados a objetos sean
fácilmente transformados en sistemas orientados a eventos.
En contraste con la programación procedimental (que simplemente actúa, y no reacciona) y

la programación basada en objetivos (IA fuerte o teoría de control, donde la actividad
principal es la planificación y actuación hacia una meta, y las señales sólo se consideran
como retroalimentación sensorial para ayudar en las decisiones futuras). Estos (en conjunto
con la programación orientada a eventos) constituyen los tres enfoques mejor entendidos
hacia describir el comportamiento en cualquier sistema. La programación orientada a
eventos es muy útil cuando se trata de interfaces gráficas de usuario, Interaccion humano-
computador (HCI), y otros sistemas de objetos, donde se espera una respuesta a la acción
como la actividad principal. (Mandyam y Ehsan 2015)
Por tanto la programación orientada a eventos no es apropiada para los sistemas que deben
hacer una tarea bien y terminar sin intervención (como compiladores, este tipo de cosas
implica programación procedural); no es apropiada también para sistemas que deben
reaccionar inteligentemente en base a la totalidad del contexto observado de cualquier tipo
(lo que implica otros tipos de programación ), por ejemplo, es difícil hacer el trabajo de
programación orientada a eventos cuando no hay una distinción clara entre los eventos, o
cuando las señales son temporalmente ambiguas (donde una señal podría significar una de
las muchas cosas sobre la base de lo que sucede a continuación o lo sucedido con
anterioridad). La programación orientada a eventos es útil para la reacción simple a
estímulos obvios no mucho más que el comportamiento “inteligente” de una medusa
(Puranik y Feiock, 2013).
La programación orientada a eventos puede o no puede ser orientada a objetos o poseer un

modelo de objetos o algo como un patrón observador. La programación orientada a
eventos, por ejemplo, no tiene porqué implicar que los eventos son siempre enviados a
llamadas de métodos sobre diferentes objetos después de la recepción, excepto en lo que
sean despachados de alguna manera durante el proceso que los recibe en el primer lugar.
Sin embargo, es más común en los sistemas orientados a objetos implementar la
programación orientada a eventos como una forma de enlazar directamente llamadas a
métodos sobre objetos particulares, posiblemente con observadores.
En un punto de vista “todo es relativo” a la programación orientada a eventos se puede ver

como el caso en el que un desarrollador no puede controlar o cambiar el “llamador”, y por
lo tanto tienen que centrarse en la rutina de llamada y en la infraestructura y convenciones
relacionadas.
Características típicas de eventos en la programación orientada a eventos (Xiao-Feng

Gu, Le Yang, Shaoquan Wu. 2014)
● Los eventos son generalmente referenciados, indexados, o nombrados sobre la base

de un objeto (sustantivo) y el tipo de acción que desencadenó el evento. Por
ejemplo, "icono_click" o "icono_ onClick". Por lo tanto, suelen tener por lo menos
dos "claves" (en un sentido informal).
● Generalmente hay un comodín de lo anterior de manera que uno opcionalmente
puede reaccionar o interceptar un click de una colección de objetos sin tener que
asignar un escuchador individual a cada uno.
● A menudo es un objeto, conjunto de parámetros, o una matriz con estructura de
diccionario que se pasa como parámetro que se puede utilizar para obtener más
información sobre el ambiente que desencadenó el evento. Por ejemplo, puede
contener la pulsación de tecla o las coordenadas del ratón en el momento de evento
desencadenante.
● Los eventos a menudo retornan un indicador de estado en cuanto a si el evento fue
un éxito o no. Por ejemplo, un evento "OnValidar" puede devolver “verdadero” si
un formulario aprueba una validación o “falso” si no lo hizo. Otro enfoque consiste
en devolver una cadena o estructura que contiene el mensaje (s) de error si hubo un
problema detectado.
● Eventos a menudo pueden interactuar con un marco de trabajo declarativo y / o base
de datos. Por ejemplo, en una interfaz gráfica de usuario un evento puede ser capaz
de cambiar los colores o texto de un cuadro de entrada no relacionada con el evento.
● Eventos generalmente son tratados como pequeños módulos de procedimiento.
Idealmente múltiples funciones (locales) están permitidas en los acontecimientos,
pero en algunos sistemas que no permiten que múltiples rutinas por evento sean
ejecutadas se deben llamar a las funcionen en bibliotecas compartidas (API´s). En
general, un lenguaje como Javascript que permite funciones anidadas simplifica las
cuestiones de alcance.
● Algunas reglas generalmente necesitan establecer sobre qué caso tienen prioridad si
varios eventos se activan al mismo tiempo. Por ejemplo, tanto un formulario y un
widget pueden tener un evento "onTeclaPresionada". A veces, las prioridades se
pueden establecer en los eventos individuales, otras veces el marco establece las
reglas y no se pueden modificar directamente.
5.3. Javascript Asíncrono y XML (AJAX)
AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es

una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet
Applications). Éstas se ejecutan en el cliente, es decir, en el navegador de los usuarios y
mantiene comunicación asíncrona con el servidor en segundo plano. De esta forma es
posible realizar cambios sobre la misma página sin necesidad de recargar la misma. Esto
significa aumentar la interactividad, velocidad y usabilidad en la misma.
AJAX es una combinación de tres tecnologías ya existentes:
● HTML y hojas de estilos en cascada (CSS) para el diseño que acompaña a la

información.
● Document Object Model (DOM) accedido con un lenguaje de scripting por
parte del usuario, especialmente implementaciones ECMAScript como
JavaScript, para mostrar e interactuar dinámicamente con la información
presentada.
● El objeto XMLHttpRequest para intercambiar datos asincrónicamente con el
servidor web.
● XML es el formato usado comúnmente para la transferencia de vuelta al
servidor, aunque cualquier formato puede funcionar, incluyendo HTML
preformateado, texto plano,JSON y hasta EBML. (Tilkov y Vinoski 2010).
5.4. Websockets
WebSockets representa una evolución esperada en tecnología web cliente-servidor.
Permiten una conexión de socket TCP única establecida entre el cliente y el servidor que
permite comunicación bidireccional, dúplex completo, y mensajes para ser distribuidos al
instante con poca sobrecarga que resulta en una conexión de muy baja latencia. (Xi-qi
2016).
Tanto el API WebSocket y el protocolo WebSocket están estandarizados, lo que significa

que la web tiene ahora una norma acordada para la comunicación en tiempo real entre los
clientes de Internet y servidores. Considerado originalmente una tecnología de navegador,
WebSockets ha llegado mucho más allá de los navegadores web y se están convirtiendo en
un estándar multiplataforma para la comunicación en tiempo real entre el cliente y el
servidor. Así como el apoyo a WebSocket en navegadores como Google Chrome, Firefox,
Opera, ahora hay implementaciones de WebSocket en Objective-C, .NET, Ruby, Java,
Node.js, ActionScript y muchos otros lenguajes. (Madsen, Tip y Lhoták, 2015).
5.5. Grupo de Investigación L.I.D.E.R1:

El grupo de investigación LIDER (Laboratorio de Investigación y Desarrollo en Electrónica
y Redes) fue creado en el año 2007 e institucionalizado a través de Acta 005-09 del Centro
de Investigaciones y Desarrollo Científico (CIDC) de la universidad Distrital, en sesión
realizada el 24 de febrero del 2009, con el aval del Consejo de Facultad. Actualmente está
conformado por su director el Ph.D. Roberto Ferro, su codirector el Ing. Carlos Martínez,
docentes de la Universidad Francisco José de Caldas, estudiantes de doctorado y pregrado.
El Grupo de Investigación se encuentra estrechamente ligado al Doctorado en Ingeniería
con un énfasis inicial en Ciencia y Tecnología de la información y del conocimiento, y la
red de investigación de tecnología avanzada (RITA), convirtiéndose en un grupo de
extensión en pregrado, dado que sus objetivos, misión y visión tienen un alto grado de
afinidad.
Misión
Generar y ejecutar en todas sus etapas, proyectos de investigación, desarrollo e innovación,

en las áreas de estudio de las líneas de investigación definidas, que propendan la creación
de soluciones basadas en tecnología emergente de alta calidad con aplicación en la solución
de problemas técnicos y de carácter práctico a nivel nacional e internacional.
Visión
El Grupo de Investigación LIDER será, en un lapso no superior a 5 años, un grupo de

excelencia reconocido a nivel universitario en el ámbito local y nacional, y valorado por la
comunidad científica internacional por sus aportes al estudio e innovación, en las áreas de
interés.
1
Grupo LIDER. Disponible en http://comunidad.udistrital.edu.co/grupolider/
Las áreas de investigación donde está enfocado el grupo LIDER son las siguientes:
● Aplicación en domótica, inmótica y telemedicina.

● Electrónica aplicada a la industria.
● Electrónica embebida para el diseño de aplicaciones de micro redes de
telecomunicaciones.
● Estudio y diseño de protocolos de red y de enrutamiento para redes de alta
velocidad.
● Ingeniería aeronáutica.
● Investigación y desarrollo de satélites.
● Nanotecnología.
● Redes de nueva generación (IPv6) y redes Ipv4.
● Redes de telefonía celular.
● Redes inalámbricas.
6. MARCO LEGAL Y NORMATIVIDAD
6.1. NORMATIVIDAD EN COLOMBIA

La Ley 1341 de 2009 determina el marco general para la formulación de las políticas
públicas que regirán el sector de las Tecnologías de la Información y las Comunicaciones,
su ordenamiento general, el régimen de competencia, la protección al usuario, así como lo
concerniente a la cobertura, la calidad del servicio, la promoción de la inversión en el sector
y el desarrollo de estas tecnologías, el uso eficiente de las redes y del espectro
radioeléctrico, así como las potestades del Estado en relación con la planeación, la gestión,
la administración adecuada y eficiente de los recursos, regulación, control y vigilancia del
mismo y facilitando el libre acceso y sin discriminación de los habitantes del territorio
nacional a la Sociedad de la Información2.
De acuerdo a esta misma ley el Estado intervendrá en el sector de las TIC para lograr los
siguientes fines:
1. Proteger los derechos de los usuarios, velando por la calidad, eficiencia y adecuada
provisión de los servicios.
2. Promover el acceso a las Tecnologías de la Información y las comunicaciones,
teniendo como fin último el servicio universal.
3. Promover el desarrollo de contenidos y aplicaciones, la prestación de servicios que
usen Tecnologías de la Información y las Comunicaciones y la masificación del
gobierno en línea.
4. Promover la oferta de mayores capacidades en la conexión, transporte y condiciones
de seguridad del servicio al usuario final, incentivando acciones de prevención
de fraudes en la red.
5. Promover y garantizar la libre y leal competencia y evitar el abuso de la posición
dominante y las prácticas restrictivas de la competencia.
6. Garantizar el despliegue y el uso eficiente de la infraestructura y la igualdad de
oportunidades en el acceso a los recursos escasos, se buscará la expansión, y
2
Ley 1342 de 2009. Disponible en http://www.mintic.gov.co/portal/604/articles-3707_documento.pdf
cobertura para zonas de difícil acceso, en especial beneficiando a poblaciones
vulnerables.
7. Garantizar el uso adecuado del espectro radioeléctrico, así como la reorganización
del mismo, respetando el principio de protección a la inversión, asociada al uso del
espectro. Los proveedores de redes y servicios de telecomunicaciones responderán
jurídica y económicamente por los daños causados a las infraestructuras.
8. Promover la ampliación de la cobertura del servicio.
9. Garantizar la interconexión y la interoperabilidad de las redes de
telecomunicaciones, así como el acceso a los elementos de las redes e instalaciones
esenciales de telecomunicaciones necesarios para promover la provisión y
comercialización de servicios, contenidos y aplicaciones que usen Tecnologías de la
Información y las comunicaciones.
10. Imponer a los proveedores de redes y servicios de telecomunicaciones obligaciones
de provisión de los servicios y uso de su infraestructura, por razones de defensa
nacional, atención y prevención de situaciones de emergencia y seguridad pública.
11. Promover la seguridad informática y de redes para desarrollar las Tecnologías de la
Información y las Comunicaciones.
12. Incentivar y promover el desarrollo de la industria de tecnologías de la información
y las comunicaciones para contribuir al crecimiento económico, la competitividad,
la generación de empleo y las exportaciones.
13. Propender por la construcción, operación y mantenimiento de infraestructuras de las
tecnologías de la información y las comunicaciones por la protección del medio
ambiente y la salud pública.
De manera complementaria, en el 2010 nació la propuesta política del Plan Vive Digital
como estrategia público-privada para afrontar el reto de ampliar la cobertura y la
penetración de la Banda Ancha, tanto para los hogares como para las micro, pequeñas y
medianas empresas del país3.
3 Mapa normativo y regulatorio del sector TIC. Disponible en http://cintel.org.co/wp-

content/uploads/2013/05/07.Documentos_Sectoriales_2011_Mapa_Normativo_y_Regulatorio_Nuevo-Mapa-normativo-y-regulatorio-sector-TIC-_-2011.pdf
El objetivo principal del plan Vive Digital es impulsar la masificación del uso de Internet,
para dar un salto hacia la Prosperidad Democrática.
6.2. PLAN ESTRATÉGICO DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE

CALDAS 2008 – 2016 4
El Plan Estratégico “Saberes, Conocimientos e Investigación de Alto Impacto para el

Desarrollo Humano y Social” 2007 –2016 es un documento indicativo y flexible que busca
constituirse como dispositivo dinamizador de los procesos institucionales, en tanto
instrumento que se adecua a los retos y necesidades del entorno local, regional, nacional y
mundial para el cumplimiento de la misión de la Universidad. Por lo tanto, se asume como
ruta y horizonte para el desarrollo las funciones de docencia, investigación, innovación,
creación y proyección social, referente vinculante para la planeación del gobierno distrital e
instrumento de obligatorio cumplimiento para la administración universitaria en cuanto a la
formulación de sus planes trianuales, de acción, operativos, al igual que marco para la
evaluación permanente de los avances y limitaciones en su ejecución.
El Plan Estratégico de Desarrollo requiere armonizar sus acciones con las tendencias y
prioridades de la Educación Superior en el ámbito internacional, en cuanto definen cuál es
el sentido de la Universidad y su compromiso social en el contexto actual.
Con este Plan, la comunidad universitaria cuenta con la orientación estratégica que guiará
la acción universitaria en los próximos 10 años y será la base para la definición de
metodologías para la alimentación del Banco de Proyectos de la Universidad Distrital,
BPUD, para establecer la prioridad en la asignación de recursos y para la elaboración de los
Planes de Desarrollo Trianuales de las distintas unidades académicas y administrativas de la
Universidad y su desglose en planes de acción anuales.
Uno de los Objetivos generales es Contar con una infraestructura física, tecnológica, de
conectividad y de medios educativos adecuados y coherentes para garantizar el desarrollo
de las funciones misionales de la Universidad Distrital, la comunicación y el bienestar
institucional. Ya que el desarrollo de las tecnologías de la información y las
4 Plan estratégico “Saberes, Conocimientos e Investigación de Alto Impacto para el Desarrollo Humano y Social” 2007 –2016”. Disponible en
http://acreditacion.udistrital.edu.co/documentos/plan_desarrollo.pdf
comunicaciones y los grandes volúmenes de información que circulan hoy día por
diferentes mecanismos y medios, plantean a la Universidad el reto de actualizar de manera
permanente y proyectar el desarrollo de su infraestructura física y de servicios de
información y comunicación de tal forma que la comunidad universitaria pueda contar con
acceso y condiciones para el trabajo académico y administrativo.
Puntualmente para el tema de tecnologías de la información está el programa 4 que se

enuncia a continuación:
● Programa 4: Consolidación de la Infraestructura Informática, de Comunicaciones y

de conectividad.
● Proyecto 1: Crear y definir la arquitectura del Sistema de Información y
comunicación interno y externo.
● Proyecto 2: Fortalecer, adecuar y dotar la infraestructura de comunicaciones e
información y conectividad.
● Proyecto 3: Masificar el uso de tecnologías de comunicación e información.
● Proyecto 4: Adquirir, diseñar, construir y dotar infraestructura de educación virtual.
● Proyecto 5: Adquirir equipos de computación para la labor docente.
7. METODOLOGÍA
El diseño e implementación del prototipo de software para la administración de turnos

como apoyo a la atención al cliente planteado en este escrito se realizó en las siguientes
fases:
● Fase 1: Análisis de requerimientos.

● Fase 2: Diseño del prototipo.
● Fase 3: Implementación.
● Fase 4: Despliegue en ambiente de producción.
● Fase 5: Pruebas.
Formalmente todo proyecto de software debe seguir una metodología para que el proceso
de desarrollo se lleve a cabo en el menor tiempo posible mostrando los resultados
esperados. Para el proyecto planteado se utilizó una metodología ágil (programación
extrema) debido a la naturaleza de esta propuesta, el cual permite que el proyecto
evolucione durante el desarrollo debido a nuevos requerimientos, pero siempre teniendo en
cuenta las limitaciones ya planteadas.
A continuación, se presenta una descripción más detallada de cada etapa.
Fase Objetivo por fase Actividad Resultado
Análisis de Establecer los Realizar una observación Generacion de

requerimientos detallada de la situación modulos con sus
requerimientos.
funcionales y no del modelo de atención al respectivos
funcionales del cliente actual. requerimientos.
sistema.
Diseño del Realizar el Establecer casos de uso y Descripción de la

modelado sus respectivos diagramas. etapa de modelado.
prototipo.
funcional.
Establecimiento de Realizar diagramas de
roles e interacción actividades.
con el sistema.
Realizar diagrama de roles
de usuarios.
Implementación Desarrollo del Realizar el desarrollo de Sistema en

sistema e cada módulo y la funcionamiento que
integración de interacción entre ellos. consta de módulo
herramientas de autenticación
necesarias. para
administradores, de
solicitud de turnos
y de notificaciones.
Despliegue en Ejecutar la Transladar archivos e Puesta en marcha

aplicación en instalar herramientas del sistema en un
ambiente de
ambiente de necesarias en servidor. ambiente de
producción. producción. producción.
Pruebas Verificar el Realizar prueba piloto de Documentación de

funcionamiento del funcionamiento del las pruebas
sistema. sistema en RITA. realizadas.
Tabla 7.1. Fases de la metodología
7.1. Enfoque investigativo

El enfoque investigativo de esta propuesta es de carácter mixto debido a que los métodos
utilizados están asociados a las entrevistas realizadas al área de calidad e implementación
de políticas TIC de la Red RITA. Así mismo, se realizaron varias visitas a entidades de tipo
bancario, salud, educación, entre otras, con el fin de verificar el tiempo que los usuarios
debían esperar para ser atendidos. Se encontró que en una sucursal de la EPS Sanitas los
usuarios deben esperar en promedio una hora y treinta minutos para ser atendidos a través
de una modalidad de cita prioritaria. Adicionalmente, una de las sucursales de Bancolombia
mantiene a los clientes que desean consultar el monto de préstamo de libre inversión dentro
del establecimiento durante aproximadamente 40 minutos. En todos los casos es evidente
que las personas preferirían estar realizando otras actividades mientras son atendidas.
Al implementar herramientas como la planteada en este escrito, en el caso de las personas

con un problema de salud que pueda ser atendido a través de una cita prioritaria o de
urgencia podría solicitar una cita al momento de salir de sus viviendas y así estarían menos
tiempo expuestas en las calles a más enfermedades o poniendo en riesgo la salud de los
demás usuarios de la entidad mientras espera ser atendido.
7.2. Población y muestra
Se realizó la implementación del sistema en el área de servicios académicos de la Red de
Investigaciones de Tecnología Avanzada – RITA debido a la alta concurrencia de
estudiantes y docentes que solicitan asesorias para sus proyectos de investigación. Este es el
caso de estudio que permitió poner en marcha la fase de pruebas y finalmente plantear las
conclusiones pertinentes en cuanto a la mejora del servicio al interior de la Red.
7.3. Técnicas e instrumentos

La Red de Investigaciones de Tecnología Avanzada – RITA posee un área de Calidad e
implementación de políticas TIC, la cual permitió establecer las preguntas de la encuesta
realizada a los usuarios dentro de la aplicación. En este momento, dicha encuesta es
diligenciada por los solicitantes con el fin de mejorar el servicio en formato físico.
Para las pruebas de campo se tomó un grupo de integrantes de RITA para realizar la prueba
de concurrencia que se presenta en varios momentos dentro de la Red, haciendo solicitudes
de asesorías internas. La instalación de la aplicación en los dispositivos móviles se realizó
manualmente y, por otro lado, se impartió una capacitación para el correcto uso de las
funcionalidades de esta.
Se realizó una reunión después de cada fase con el director del proyecto, con el fin de llevar
un proceso de mejora continua aplicando principios de retroalimentación y así lograr un
producto de software que cumpliera con los objetivos planteados inicialmente.
7.4. Herramientas
Las herramientas utilizadas para la fase de investigación y apropiamiento del
funcionamiento de asesorías académicas dentro de RITA fueron:
 Formato de encuestas de satisfacción de servicio (ANEXO 1).
 Sitio web de RITA. (rita.udistrital.edu.co, 2017).
 Estadísticas de atención a usuarios durante los últimos 3 meses (Octubre,
Noviembre y Diciembre de 2016)
Para el diseño de artefactos de ingeniería de software se utilizaron las siguientes

herramientas:
 Enterprise Architect (Sparxsystems.com, 2017).
 Draw.io (Draw.io, 2017).
Las tecnologías implementadas en el desarrollo de la aplicación se nombrarán en el ítem
relacionado al diseño de prototipo (p.39).
8. RESULTADOS
Actualmente la Red de Investigaciones de Tecnología Avanzada – RITA brinda asesorías

académicas a la comunidad investigativa de la universidad Distrital en diferentes áreas,
tales como: RStudio, Sage, OpenSim, programación, etc. En algunas ocasiones el nivel de
concurrencia de usuarios supera el esperado y algunos de ellos prefieren desistir.
Adicionalmente, al finalizar una asesoría el asesor debe realizar una encuesta al usuario en
formato físico para ser entregada al área de calidad (ANEXO 1).
El crecimiento de las empresas que presta uno o más servicios se debe a la cantidad de
usuarios que utilicen dicho servicio, a la calidad de este y a la capacidad de respuesta de sus
asesores al momento de presentar un inconveniente o realizar un trámite. La fidelidad de un
cliente a una entidad se ve afectada por el tiempo de respuesta a sus inquietudes, si estas no
son atendidas en un tiempo razonable y adicionalmente no se cuenta con herramientas que
brinden una mejor experiencia durante el lapso de espera, fácilmente el usuario puede elegir
otra compañía. Esta situación se presenta en varias entidades públicas y privadas a nivel
mundial en diferentes campos (banca, salud, educación, telecomunicaciones, vivienda,
entre otros.)
Para solucionar este problema, se creó esta propuesta de implementación de una aplicación
móvil que permite a un usuario solicitar turnos para ser atendido asegún su necesidad. En
este proyecto se tomó como entidad a la Red de Investigaciones de Tecnología Avanzada
RITA donde la aplicación permite a estudiantes solicitar turnos para ser atendidos por un
asesor de RITA sin tener que salir de su salón de clase o interrumpir otras actividades
académicas sabiendo el tiempo aproximado en que podría ser atendido.
Adicionalmente, el prototipo desarrollado permite a los asesores realizar llamados a través

de una sección exclusiva para su rol y así las entidades estarían menos congestionadas.
Cada vez que hay un cambio de turno el tiempo de espera para ser atendido disminuye y es
actualizado en todos los dispositivos que han solicitado turnos según el tiempo de asesoría.
Este prototipo brinda una sección de encuesta que para el caso de estudio (Área de
asesorías académicas de la Red de Investigaciones de Tecnología Avanzada - RITA) debido
a que al interior de la Red se acostumbra realizar encuestas de satisfacción de prestación de
servicio para optimizar la atención al cliente. Estas encuestas pueden resultar útiles para los
departamentos de atención al cliente de las empresas porque allí pueden obtener datos
cuantitativos que les permitirían medir el desempeño de asesores e inclusive sucursales.
8.1. Especificación funcional

A continuación, se describen los requerimientos funcionales y no funcionales identificados
para la posterior implementación del prototipo.
8.1.1. Análisis de requerimientos
8.1.1.1. Requerimientos funcionales
CÓDIGO REQUERIMIENTO
La aplicación contará con una sección de autenticación que permitirá establecer

R1
un control de acceso y así mismo filtrar el contenido según el rol del usuario.
R2 La aplicación contará con dos tipos de roles: cliente y asesor.
R3 La aplicación permitirá a los clientes solicitar y cancelar turnos.
La aplicación informará a todos los usuarios que tengan abierta la aplicación el

R4
turno atendido en ese momento y el último turno solicitado en tiempo real.
La aplicación permitirá a los clientes calificar la asesoría recibida a través de una

R5
encuesta.
La aplicación debe informar a los usuarios el tiempo faltante para ser atendido
R6
teniendo en cuenta los turnos que vayan siendo atendidos.
Tabla 8.1. Requerimientos
8.1.1.2. Requerimientos no funcionales
Seguridad y control de acceso

Identificador: Nombre:
RNF 01 Control de acceso
Descripción: El sistema contara con un módulo de autenticación de usuarios para el control
de acceso y así asegurar que cada usuario accede a las funcionalidades y a los datos
disponibles según su rol.
Criterios de Aceptación
El usuario puede realizar un conjunto de acciones limitadas según su rol.
Tabla 8.2 Descripción requerimiento no funcional
Plataforma de implementación
RNF 02 Plataforma aplicación móvil
Descripción: La aplicación debe tener un correcto funcionamiento en la mayoría de
dispositivos móviles Android.
Tanto clientes como asesores podrán utilizar la aplicación desde sus dispositivos móviles.
Calidad del Software

RNF 03 Calidad del software
Descripción: El sistema soportará atributos de calidad tales como: usabilidad,
mantenibilidad, y portabilidad.
Criterios de Aceptación:
El sistema tendrá una interfaz gráfica amigable para el usuario.
El sistema tendrá alta capacidad de mantenibilidad a través de la formalidad en la
documentación.
Disponibilidad
RNF 04 Disponibilidad del servicio
Descripción: La aplicación debe estar disponible durante las 24.
El cliente puede solicitar turnos en cualquier momento.
Los asesores podrán realizar llamados a turnos.
El sistema informará en tiempo real a los clientes el turno actual atendido y el restante para
ser atendido.
8.1.2. Especificación de usuarios
Se identificaron dos tipos de usuario o roles dentro de la aplicación, en la imagen 8.1. se
muestra el diagrama de actores y una descripción de las acciones que puede realizar cada
uno de ellos.
Imagen 8.1 Diagrama de actores del sistema
Ninguno de los dos hereda comportamientos del otro dentro de la aplicación y es por esto
que solo se presenta una asociación entre ellos.
ACTOR DESCRIPCIÓN
Cliente El cliente es quien solicita y cancela turnos a través de la aplicación.

El cliente es quién evalúa las asesorías recibidas.
Asesor El asesor es la persona que atiende a cada cliente asociado a un turno
solicitado y realiza llamados a turnos a través de la aplicación.
Tabla 8.6 Descripción de roles
8.1.3. Casos de uso
A continuación, se presentan los casos de uso establecidos según el levantamiento de
requerimientos realizado previamente, la imagen 8.2 muestra el diagrama de casos de uso
general y las tablas 8.7 a 8.16 muestran la descripción detallada de cada caso de uso.
Imagen 8.2 Diagrama general de casos de uso
Nombre del Caso de Uso Iniciar aplicación
Resumen El usuario podrá lanzar la aplicación desde el menú de su

dispositivo móvil.
Curso básico de eventos El usuario ingresa al menú

principal de su dispositivo
móvil y selecciona la
aplicación.
El sistema operativo abre la

aplicación y muestra al usuario
la vista de login.
Caminos alternativos N/A
Caminos de excepción Si la versión del sistema operativo del dispositivo es antigua la

aplicación podría no abrirse o cerrarse en el proceso mostrando
un error de incompatibilidad.
Puntos de Extensión Al abrir la aplicación el usuario podrá ingresar datos para
iniciar sesión o salir de ella.
Precondiciones N/A
Criterios de aceptación La aplicación se inicia sin mostrar errores de incompatibilidad.
Tabla 8.7 Descripción caso de uso
Nombre del Caso de Uso Iniciar sesión
Resumen El usuario podrá iniciar sesión al abrir la aplicación para

acceder a todas las funcionalidades.
Curso básico de eventos El usuario ingresa nombre de

usuario y contraseña.
El sistema valida los datos y si
son correctos el usuario inicia
sesión.
Caminos de excepción Si los datos que ingresa el usuario no son correctos no es

posible iniciar sesión.
Puntos de Extensión N/A
Precondiciones Ingresar datos (usuario y contraseña).

El usuario ha sido registrado anteriormente en la base de datos.
Criterios de aceptación Posibilidad de ingresar al sistema e interactuar con él.
Nombre del Caso de Uso Cerrar aplicación

Resumen El usuario podrá cerrar la aplicación en cualquier momento.
Curso básico de eventos El usuario oprime el botón
menú cuya ubicación y
funcionamiento dependen del
dispositivo.
El sistema operativo cierra la

aplicación y la mantiene en
segundo plano.
Caminos de excepción N/A
Precondiciones N/A
Criterios de aceptación La aplicación se puede cerrar desde cualquier punto.
Nombre del Caso de Uso Elegir tipo de asesoría
Resumen El usuario podrá elegir un tipo de asesoría del menú

presentado.
Curso básico de eventos La aplicación muestra al

usuario un menú de posibles
asesorías que puede recibir.
El usuario oprime el tipo de
asesoría que desea.
La aplicación muestra el turno
que está siendo atendido y el
próximo turno disponible.
Caminos de excepción No se estableció conexión con el servidor.
Puntos de Extensión El usuario podrá solicitar el siguiente turno disponible o podrá

regresar al menú de asesorías.
Precondiciones El usuario debe haber iniciado sesión anteriormente.
Criterios de aceptación La aplicación permite al usuario seleccionar tipo de asesoría y

muestra el turno atendido y el siguiente disponible.
Nombre del Caso de Uso Consultar turnos activos
Resumen El usuario podrá visualizar la lista de turnos activos.
Curso básico de eventos La aplicación muestra al

usuario un listado de los turnos
activos y su tipo de asesoría.
El usuario selecciona
cualquier ítem de la lista.
La aplicación muestra el turno

que está siendo atendido y el
turno asignado.
Caminos alternativos A través del menú lateral es posible ir al listado de turnos

activos.
Caminos de excepción No se estableció conexión con el servidor.
Puntos de Extensión El usuario podrá cancelar su turno.
Precondiciones N/A
Criterios de aceptación La aplicación permite al usuario conocer un listado de los

turnos activos y su avance en tiempo real.
Nombre del Caso de Uso Solicitar turno
Resumen El usuario solicita un turno asociado a un tipo de asesoría.
Curso básico de eventos El usuario oprime el botón

“Solicitar turno”.
La aplicación realiza la nueva
petición al servidor y este a su
vez envía la respuesta
indicando el turno asignado.
Caminos de excepción No es posible establecer la conexión con el servidor.
Puntos de Extensión El usuario podrá cancelar el turno.
Precondiciones El usuario debe elegir un tipo de asesoría previamente.
Criterios de aceptación La aplicación permite al usuario cerrar sesión en cualquier

momento.

Nombre del Caso de Uso Realizar encuesta
Resumen El cliente realiza una encuesta sobre la asesoría recibida.
Curso básico de eventos La aplicación muestra la

encuesta al cliente antes de
solicitar un turno del mismo
tipo de asesoría.
El cliente diligencia la
encuesta y oprime el botón
“Enviar”.
La aplicación envía los datos al
servidor para ser almacenados.

No se han diligenciado todos los campos de la encuesta.
Precondiciones El cliente debe haber recibido una asesoría.
Criterios de aceptación La aplicación permite al cliente evaluar la asesoría brindada.
Nombre del Caso de Uso Hacer llamado al siguiente turno
Resumen El asesor hace un llamado al siguiente turno.
Curso básico de eventos El asesor oprime el botón

“Siguiente turno”.
La aplicación envía una
notificación al cliente
informando que su turno será
atendido inmediatamente.
La aplicación muestra al asesor
el turno atendido y los datos de
la persona que lo solicitó.
El servidor emite un mensaje

global informando el
incremento a los clientes que se
encuentran en espera de
atención.

No hay más clientes en la cola.
Puntos de Extensión Guardar datos de la asesoría.

Hacer llamado al siguiente turno.
Precondiciones N/A
Criterios de aceptación La aplicación permite al asesor hacer llamado al siguiente

turno.
Nombre del Caso de Uso Cancelar turno
Resumen El cliente cancela un turno previamente solicitado.
Curso básico de eventos El cliente oprime el botón

“Cancelar turno”.
La aplicación realiza la petición
al servidor y muestra al usuario
el menú de asesorías
disponibles.
Puntos de Extensión Regresar al menú de tipos de asesorías.

Precondiciones El usuario debe haber solicitado un turno.
Criterios de aceptación La aplicación permite al usuario cancelar un turno solicitado.
Nombre del Caso de Uso Guardar datos de asesoría atendida
Resumen El asesor guarda los datos relevantes de la asesoría brindada.
Curso básico de eventos El asesor oprime el botón

“Guardar” después de
realizar la asesoría.
La aplicación hace la petición al
servidor y este se encarga de
almacenar los datos asociados a
la asesoría.

El cliente no se presentó.
Puntos de Extensión Hacer llamado al siguiente turno.
Precondiciones N/A
Criterios de aceptación La aplicación permite al asesor guardar los datos relacionados

a las asesorías brindadas.
8.1.4. Diagramas de actividades

Los diagramas de actividades a continuación presentan el flujo de actividades realizadas
tanto por los usuarios como por el servidor. La imagen 8.3 muestra las acciones realizadas
por el cliente para solicitar un turno, por otro lado, la imagen 8.4 muestra la interacción
entre el asesor y la aplicación.
Imagen 8.3 Diagrama de actividades para cliente
Imagen 8.4 Diagrama de actividades para asesor
8.1.5. Bocetos de interfaz gráfica de usuario

Adicionalmente, teniendo en cuenta los requerimientos, los casos de uso identificados y los
diagramas de actividades, se realizaron bocetos de interfaz gráfica para tener claro durante
el proceso de implementación y desarrollo los datos importantes que los usuarios deben
conocer. Es importante destacar que son aproximaciones debido a que en el tiempo de
desarrollo pueden surgir nuevas necesidades.
Imagen 8.5 Bocetos de interfaz gráfica
8.1.6. Arquitectura del sistema
A continuación, la imagen 8.6 muestra el diseño de la arquitectura general del sistema,

especificando tecnologías utilizadas en cada una de las capas, además de describir su
interacción.
Imagen 8.6 Diagrama de arquitectura del sistema
Capas
 Cliente/Asesor: Se desarrollará una aplicación móvil con Ionic versión 2, un
framework que permite crear aplicaciones móviles tanto para dispositivos Android
como iOS a partir de una misma fuente de código. Este framawork está basado en
tecnologías web, tales como:
o Typescript: Lenguaje de programación de código abierto basado en

Javascript y añade características compatibles con la programación orientada
a objetos tradicional. (Bierman, Abadi y Torgersen 2014).
o Angular 2: Framework frontend que permite crear aplicaciones web, de

escritorio y móviles de alto rendimiento y productividad. (Angular.io, 2017)
o HTML5: Es la quinta especificación que define el lenguaje básico de la

World Wide Web (WWW). (Zhanikeev 2013).
o CSS3: Es la última especificación de las hojas de estilo en cascada que
permiten dar a los documentos HTML o HTML mayor interactividad y
presentación con el fin de mejorar la experiencia del usuario
(developer.mozilla.org, 2017).
o XML (Xtensible Markup Language): En un meta lenguaje que permite dar

mayor significado a los datos almacenados en un documento, así mismo, es
muy útil a la hora realizar intercambio de datos entre arquitecturas
(w3.org/XML, 2017).
Es importante aclarar que para el desarrollo de este prototipo solo se generará una
aplicación para dispositivos Android y queda abierta la posibilidad de generar una
aplicación para iOS con las mismas funcionalidades en trabajos futuros por parte de la
universidad.
 Web Server: La aplicación en el lado del servidor será implementada con Node.js
utilizando una arquitectura orientada a eventos. Adicionalmente para el manejo de
comunicación en tiempo real entre el cliente y el servidor se utilizará la librería
socket.io en las dos capas.
 Base de datos: La persistencia se llevará a cabo en el motor de bases de datos

MySQL en su versión 5.7, el cual soporta bases de datos relacionales.
Comunicación
A continuación, se describe la comunicación e interacción entre los componentes
mencionados anteriormente. En este caso la comunicación que se da entre la aplicación
móvil y node.js es totalmente distinta a la que se da entre la aplicación móvil y socket.io
(Jaramillo, Nguyen y Newhook, 2014). La interacción entre la aplicación móvil y node.js es
la siguiente:
1. Llamado al api escrita con Node.js.
2. Consulta a la base de datos (INSERT, SELECT, DELETE, UPDATE).
3. Respuesta de la base de datos.

4. Retorno de un objeto JSON desde el servidor hasta la aplicación móvil.
Y finalmente la interacción entre la aplicación móvil y socket.io, para asegurar que los
usuarios obtengan la información en tiempo real en cuanto se presente un cambio es la
siguiente:
a y b. Conexión abierta y permanente entre cliente y servidor
c. Envío de mensajes de manera bidireccional de forma asíncrona.
d. Cierre de conexión unidireccional.
8.2. Modelo de persistencia
El modelo de persistencia de datos seleccionado fue el modelo relacional debido a la

confiabilidad que representa para el almacenamiento de datos, además de su gran
trayectoria en el mundo de las bases de datos. Es posible utilizar una base de datos
orientada a documentos si así se requiere en un futuro o inclusive un enfoque orientado a
grafos que resultaría igual de útil al seleccionado para la persistencia de datos en este
prototipo.
A continuación, la imagen 8.7 muestra el modelo entidad-relación que describe las

entidades, atributos y relaciones identificadas inicialmente.
El modelo relacional de la imagen 8.8 permite visualizar la estructura final que almacenará
los datos de la aplicación. Es importante destacar que se encuentra normalizada
completamente.
Adicionalmente, las tablas 8.17 a 8.23 detallan las propiedades de cada tabla en formato de
diccionario de datos. La letra S corresponde a que este campo cumple con la característica
que titula la columna donde se encuentra ubicada y la letra N corresponde al no
cumplimiento de ésta.
Tabla 8.7 Diagrama entidad-relación
Imagen 8.8 Modelo relacional
Usuario
Descripción Tabla que contiene los datos de todos los usuarios de la aplicación.
Nombre Descripción Tipo de Dominio
Llave primaria
Tabla
Llave foránea
Clave única
Requerido
Atributo dato referenciada
Id_usuario Contiene un INT (1,214748 S S N S

consecutivo que 3647)
identifica a cada
usuario dentro de
esta tabla
documento Contiene el VARCHA a-z, A-Z S N N N
número de R(50)
identificación del
usuario
nombre_com Contiene el VARCHA a-z, A-Z S N N N
pleto nombre R(140)
completo del
usuario.
clave Contiene la VARCHA a-z, A-Z S N N N

contraseña del R(100)
usuario para
tener acceso a las
funciones de la
aplicación.
correo Contiene el VARCHA a-z, A-Z S N N N
correo R(100)
electrónico del
usuario
id_rol Contiene una INT (1,214748 S N S N Rol(id_rol)

referencia al rol 3647)
del usuario
dentro de la
aplicación
Id_rolUniver Contiene una INT (1,214748 S N S N RolUniversid
sidad referencia al rol 3647) ad(id_rolUni
que tiene el versidad)
usuario dentro de
la universidad
Distrital
Tabla 8.17 Diccionario de tabla de la base de datos
TipoAsesoria
Descripción Tabla que contiene los datos de los tipos de asesoría que brinda la aplicación.
Llave primaria
Nombre Descripción Tipo de Dominio Tabla
Llave foránea
Clave única
Requerido
id_tipoAseso Contiene un INT (1,214748 S S N S

ria consecutivo que 3647)
identifica a cada
tipo de asesoría
dentro de esta
tabla
nombre_tipo Contiene el VARCHA a-z, A-Z S N N N
Asesoria nombre del tipo R(50)
de asesoría
turno_actual Contiene el turno INT (1,214748 S N N N

que está siendo 3647)
atendido
actualmente.
ultimo_turno Contiene el INT (1,214748 S N N N

_solicitado número del 3647)
último turno
solicitado a
través de la
aplicación.
url_imagen Contiene la ruta VARCHA a-z, A-Z S N N N
de la imagen que R(100)
representa el tipo
de asesoría
Asesoria
Descripción Tabla que contiene los datos de las asesorías solicitadas.
Llave primaria

Llave foránea
Clave única
Requerido

Id_asesoria Contiene un INT (1,214748 S S N S
identifica a cada
asesoría
solicitada
hora_inicio Contiene el día y TIMESTA (01-01- N N N N
la hora de inicio MP 1970
de la asesoría. 00:00, 31-
12-2037
00: 00)
hora_fin Contiene el día y TIMESTA (01-01- N N N N
la hora de MP 1970
finalización de la 00:00, 31-
asesoría. 12-2037
00: 00)
numero_turn Numero de turno INT (1,214748 S N N N
o solicitado. 3647)
hora_solicituHora en que el TIMESTA (01-01- S N N N

d usuario solicita MP 1970
el turno a través 00:00, 31-
de la aplicación 12-2037
móvil. 00: 00)
hora_cancela Hora en que el TIMESTA (01-01- N N N N
cion usuario canceló MP 1970
la solicitad 00:00, 31-
realizada. 12-2037
00: 00)
id_usuario Referencia del INT (1,214748 S N S N Usuario(id_u
usuario que 3647) suario)
realizó la
solicitud de
turno.
id_encuesta Referencia a la INT (1,214748 S N S N Encuesta(id_
encuesta 3647) encuesta)
realizada por el
usuario.
id_tipoAseso Referencia al INT (1,214748 S N S N TipoAsesoria

ria tipo de asesoría a 3647) (id_tipoAses
la cual pertenece oria)
el turno
solicitado.
Encuesta
Descripción Tabla que contiene las respuestas de los usuarios que contestaron la encuesta a través
de la aplicación móvil.
Llave primaria
Tabla
Llave foránea
Clave única
Requerido
id_encuesta Contiene un INT (1,214748 S S N S

identifica a cada
encuesta
realizada.
fecha Fecha en que se TIMESTA (01-01- S N N N
realiza la MP 1970
encuesta 00:00, 31-
12-2037
00: 00)
actitud Respuesta INT (1,214748 S N N N
relacionada a la 3647)
pregunta sobre
actitud del
asesor.
tiempo Respuesta INT (1,214748 S N N N
asociada al 3647)
tiempo de
respuesta del
asesor.
orientacion Respuesta INT (1,214748 S N N N
asociada al nivel 3647)
de orientación
brindada por el
asesor.
grado Respuesta INT (1,214748 S N N N
asociada al grado 3647)
de conformidad
con la asesoría
recibida.
observacione Observaciones VARCHA a-z, A-Z S N N N
s adicionales R(400)
enviadas por los
usuarios.

Encuesta
Descripción Tabla que contiene las respuestas de los usuarios que contestaron la encuesta a través
de la aplicación móvil.
Llave primaria
Tabla
Llave foránea
Clave única
Requerido
id_encuesta Contiene un INT (1,214748 S S N S

identifica a cada
encuesta
realizada.
fecha Fecha en que se TIMESTA (01-01- S N N N
realiza la MP 1970
encuesta 00:00, 31-
12-2037
00: 00)
actitud Respuesta INT (1,214748 S N N N
relacionada a la 3647)
pregunta sobre
actitud del
asesor.
tiempo Respuesta INT (1,214748 S N N N
asociada al 3647)
tiempo de
respuesta del
asesor.
orientacion Respuesta INT (1,214748 S N N N
asociada al nivel 3647)
de orientación
brindada por el
asesor.
grado Respuesta INT (1,214748 S N N N
asociada al grado 3647)
de conformidad
con la asesoría
recibida.
observacione Observaciones VARCHA a-z, A-Z S N N N
s adicionales R(400)
enviadas por los
usuarios.

Rol
Descripción Tabla que contiene los diferentes roles que los usuarios pueden tener para acceder al
contenido de la aplicación.
Llave primaria
Tabla
Llave foránea
Clave única
Requerido
id_rol Contiene un INT (1,214748 S S N S

identifica cada
tipo de rol.
nombre_rol Nombre que VARCHA a-z, A-Z S N N N
describe el rol R(50)
RolUniversidad
Descripción Tabla que contiene los diferentes roles que los usuarios pueden tener dentro de la
universidad Distrital.
Llave primaria
Llave foránea
Clave única
Requerido
id_rolUniver Contiene un INT (1,214748 S S N S

sidad consecutivo que 3647)
identifica cada
tipo de rol dentro
de la
universidad.
rol Nombre que VARCHA a-z, A-Z S N N N
describe el rol. R(50)

8.3. Aspectos tecnológicos y de despliegue
8.3.1. Aplicación móvil
La aplicación móvil de este prototipo fue desarrollada haciendo uso del framework IONIC
2 debido a la simplicidad que brinda a la hora de crear aplicaciones móviles totalmente
funcionales para dispositivos Android y iOS, a partir de una misma fuente de código
basado en tecnologías web, tales como: HTML5, CSS3, Typescript y Angular 2. Así
mismo, la conexión realizada con la aplicación del lado del servidor se simplifica debido a
que ésta última también está basada en tecnologías web.
El desarrollo de la aplicación fue realizado en un computador de usuario final con sistema

operativo Linux, distribución Linux Mint 17. Inicialmente se llevó a cabo la instalación de
algunos paquetes necesarios a través del gestor de paquetes synaptic, ejecutando los
comandos en la terminal como muestran las imágenes 8.9, 8.10 y 8.11.
Imagen 8.9 Instalación de npm
Imagen 8.10 Instalación de nodejs
Imagen 8.11 Instalación de IONIC 2
Adicionalmente, para generar aplicaciones para dispositivos Android es indispensable

instalar Android Studio, Para esto, es necesario ingresar al sitio web de Android para
desarrolladores y descargar el software de instalación.
Una vez finalizada la instalación, a través de la consola de linea de comandos de Ionic se

creó la estructura básica de la aplicación.
Imagen 8.12 Creación de estructura inicial de la aplicación
A partir de la estructura generada se inició el desarrollo de la aplicación utilizando Angular

2 para el data bindging, concepto aplicado para referirse al proceso de actualizar la vista
cuando hay un cambio en los datos. Adicionalmente, Typescript permitió que la aplicación
fuera completamente modularizada debido a que éste lenguaje permite crear componentes
que interactuan entre sí para definir funcionalidades dentro de la aplicación.
Para realizar la depuración tanto en el proceso de desarrollo como en el de pruebas fue

posible utilizar el navegador Google Chrome y un servidor proporcionado por el
framework, activado a traves de la interfaz de linea de comandos de Ionic, como muestra la
imagen 8.13.
Imagen 8.13 Activación de servidor web para depuración
La imagen 8.14 muestra que es posible acceder al servicio a través de la URL

http://localhost:8100. Cabe destacar que este es un ambiente de pruebas local y por esto
solo es posible acceder desde el computador donde se tiene alojada la aplicación.
Imagen 8.14 Depuración a través del navegador
Para realizar las pruebas en el dispositivo físico es necesario indicar a través de la interfaz
de línea de comandos de Ionic, sobre qué sistema operativo se desean ejecutar la aplicación
(Android o iOS), como se muestra a continuación.
Imagen 8.15 Ejecutar aplicación en dispositivo físico
Es importante destacar, que el dispositivo debe estar conectado al computador y debe tener
habilitada la opción para desarrolladores y adicionalmente tener activada la opción de
depuración para que el computador lo reconozca como tal y no unidad de almacenamiento.
8.3.2. Aplicación servidor
Esta sección del prototipo es la encargada de recibir y gestionar las peticiones que realiza la
aplicación móvil. La aplicación está escrita en Nodejs, un entorno de ejecución de código
Javascript orientado a eventos, y hace uso de Socket.io, una librería que permite establecer
una conexión bidireccional entre cliente y servidor usando websockets. La importancia de
esta librería en el desarrollo de este prototipo, se ve reflejada al momento de realizar
notificaciones a uno o varios usuarios cuando un evento es emitido por alguno de los
dispositivos conectados, por ejemplo, una solicitud de turno, un llamado a nuevo turno,
tiempo estimado de espera.
Para este caso se solicitó un espacio en el servidor de la Red de Investigaciones de

Tecnología Avanzada (RITA) con el fin de desplegar el servicio escrito y probado
previamente en un servidor local de pruebas. La máquina virtual proporcionada tiene las
siguientes características: Sistema operativo Linux, Distribucion Debian 8, 4 GB RAM, 10
GB de disco duro.
Inicialmente se realizó la instalación de npm como muestra la imagen 8.16 y de nodejs

como muestra la imagen 8.17.
Imagen 8.16 Instalación de npm en el servidor
Imagen 8.17 Instalación de nodejs en el servidor
La máquina virtual ya contaba con el gestor de bases de datos mysql. Adicionalmente, para
que el servicio tuviera alta disponibilidad se instaló un módulo de npm llamado Forever. Es
una interfaz de línea de comandos que permite y asegura que un script o servicio se ejecute
continuamente. La instalación de dicho módulo se realizó a través de la terminal como se
muestra en la imagen 8.18.
Imagen 8.18 Instalación de módulo Forever
Para comprobar los servicios que están siendo respaldados por Forever se ejecuta el
comando forever list
Imagen 8.19 Verificación de instalación de Forever

Imagen 8.20 Ejecución y verificación del servicio
La estructura de carpetas de la aplicación ya generada, desarrollada y probada en un

ambiente de pruebas local, es alojada a la carpeta /home/rita/ y se ejecuta el comando
forever start /home/rita/turnapp/app.js. Comprobando que el servicio se encuentra activo y
disponible nuevamente se ejecuta el comando forever list.
8.4. Pruebas de campo

A continuación, se presentan capturas de pantalla que evidencian el funcionamiento de la
aplicación ya instalada en el dispositivo. Al abrir la aplicación el usuario encuentra un
formulario que debe diligenciar para iniciar sesión y poder acceder a las funcionalidades
que brinda ésta según su rol (Imagen 8.21). La aplicación verifica en la base de datos la
existencia del usuario, si los datos son correctos automáticamente se desplegará un menú
principal que contiene los tipos de asesoría disponibles como se muestra en la imagen 8.22.
Debido a que el caso de estudio de este prototipo se llevó a cabo para las asesorías
académicas ofrecidas por la red RITA a la comunidad académica, se tuvieron en cuenta dos
de ellas: RStudio y OpenSim. RStudio es un entorno integrado de desarrollo web que
permite crear programas con el lenguaje de programación R. Actualmente la Red RITA
brinda este servicio para quienes deseen realizar implementaciones relacionadas con
trabajos de investigación que requieran un consumo de recursos de hardware superior y que
no puede suplir un computador personal. OpenSim es un simulador de código abierto que
permite crear ambientes virtuales aplicables en distintos proyectos de investigación.
Imagen 8.21 Login Imagen 8.22 Menú tipos de asesorías
El cliente selecciona el tipo de asesoría para conocer su estado. Luego se despliega una
ventana como muestra la imagen 8.23, que brinda información sobre el turno que está
siendo atendido, “Turno actual” y el próximo turno. Al momento de oprimir el botón
“Solicitar turno” automáticamente la misma ventana abierta en cualquier otro dispositivo es
actualizada, informando a los usuarios que el siguiente turno a solicitar ya ha sido asignado
a otro usuario. Igualmente, en ese momento, en el dispositivo desde el cual se realizó la
solicitud, se despliega información importante que permite al usuario conocer el turno que
está siendo atendido, el turno asignado y el tiempo estimado para que su turno sea llamado,
como muestra la imagen 8.24. En esta misma vista de la aplicación es posible cancelar el
turno cuando el cliente lo considere necesario.
Imagen 8.23 Turno actual y siguiente de Imagen 8.24 Estado turno solicitado
la asesoría RStudio
Adicionalmente, el usuario puede verificar los turnos que tiene asignados oprimiendo el
símbolo de menú ubicado en la parte superior izquierda de la pantalla de su dispositivo
móvil, como muestra la imagen 8.25. Al seleccionar el ítem “Mis turnos” se abre la sección
que lista los turnos solicitados por el usuario. Al momento de seleccionar uno de los turnos
se despliega la información asociada a este tal como se muestra en la imagen 8.26.
Imagen 8.25 Menú Imagen 8.26 Lista de Imagen 8.27 Encuesta
lateral para consultar lista turnos solicitados del servicio
de turnos solicitados
Cuando el usuario es atendido por el asesor y éste último registra la hora en que finalizó la
asesoría, el cliente no puede solicitar un nuevo turno si no diligencia la encuesta que
permite evaluar la asesoría. Cabe destacar, que las preguntas asociadas a esta encuesta
hacen parte del formato de evaluación de servicios de RITA, que se encuentra como anexo
1 es este escrito.
Por otro lado, el asesor inicia sesión de la misma manera que el cliente. El menú principal
de tipos de asesorías también es desplegado si los datos ingresados son correctos y al
momento de seleccionar uno de los ítems se muestra una ventana con la información del
usuario que solicitó el turno que está siendo llamado, como muestra la imagen 8.28.
Adicionalmente, se notifica a los usuarios que tienen abierta la aplicación que el turno
atendido ha cambiado y el tiempo de espera para ser atendido ha disminuido.
Imagen 8.28 Datos del turno que está siendo atendido
9. LIMITACIONES
Este proyecto no consideraba el módulo de impresión de turno en la estación local ni el

módulo de gestión de usuarios (crear, eliminar y modificar usuarios) debido a que no tiene
trascendencia en el objetivo que trataba de cumplir este proyecto.
10. CONCLUSIONES
Se construyó el prototipo de una aplicación móvil que cumple con los requerimientos
planteados y que permite, en este caso, a la comunidad académica solicitar turnos para
asesorías académicas.
Este prototipo puede ser modificado y aplicado en cualquier entidad o establecimiento que
gestione la atención al cliente de manera presencial, lo cual según las referencias de
fidelización que utilizan algunas empresas resultaría bastante útil.
La aplicación notifica a los clientes cuando hay un cambio en un turno de una asesoría
seleccionada permitiéndoles manejar su tiempo de manera más eficiente.
A partir de los datos almacenados es posible obtener estadísticas relacionadas al tiempo de

atención, evaluación del servicio, cancelaciones de turnos, asesorías con mayor número de
solicitudes, tipos de usuario dentro de la universidad que solicitan asesorías.
Las notificaciones a los usuarios se realizan sobre los datos mientras la aplicación se
encuentra en primer plano. Adicionalmente, la rapidez con la que el usuario recibe dichas
notificaciones depende de la disponibilidad de su conexión a internet y de la velocidad de la
misma.
El prototipo puede manejar sin problema alguno 12 usuarios concurrentes, es decir,

solicitando turnos al mismo tiempo sobre la misma asesoría, y realizando otras acciones
como cancelaciones, encuestas, llamados a nuevos turnos, etc.
La notificación a los usuarios fue la funcionalidad más compleja debido a que se dependía
de conexión a internet y disponibilidad del servicio instalado y configurado en el servidor.
Se realizaron pruebas dentro de la Red de Investigaciones de Tecnología Avanzada (RITA)

con 8 usuarios (2 asesores y 6 clientes) concurrentes para realizar asesorías internas sobre
RStudio y OpenSim. Cada asesoría tenía una necesidad diferente así que sus tiempos
transcurrieron de la misma forma, y cada persona podía continuar con sus actividades y
podían consultar en la aplicación el tiempo faltante aproximado para ser atendidos.
11. RECOMENDACIONES
 Las pruebas realizadas se llevaron a cabo en dispositivos Android de gama media y

alta donde la versión mínima era la 5.0 y la máxima 6.0. Se estima que la aplicación
tiene un correcto funcionamiento en dispositivos cuya versión de Android esté entre
la 4.4 (KitKat) y la 7.0 (Nougat). En otras versiones puede presentar inconvenientes
debido a la compatibilidad de framework utilizado con versiones anterior o futuras.
 La aplicación alojada en el servidor debe ser ejecutada utilizando el módulo

Forever, o uno similar para asegurar la disponibilidad del servicio y el correcto
funcionamiento de la aplicación móvil.
 La conexión a internet es indispensable para que las notificaciones se realicen en

tiempo real en todos los dispositivos que tengan abierta la aplicación y
específicamente se encuentren en la sección que debe ser actualizada.
12. ANEXOS
Anexo 1: Formato de evaluación de servicios de la Red de Investigaciones de Tecnología

Avanzada (RITA)
Imagen 12.1 Formato de evaluación de servicios de RITA
Anexo 2: Presupuesto
CONCEPTO FUENTE TOTAL
COSTOS DE PERSONAL NO APLICA $ 8’400.000
COSTOS DE SOFTWARE NO APLICA $0
COSTOS DE EQUIPOS NO APLICA $ 1’150.000
PAPELERIA Y VARIOS NO APLICA $ 200.000
TOTAL $ 9’750.000
Tabla Anexo 2.1. Costos totales del proyecto
NOMBRE TIPO DE FUNCIÓ MESES DE HORAS RECURSO TOTAL

VINCULA N VINCULAC POR S
CIÓN DENTRO IÓN / SEMAN
DEL SEMANAS A
PROYEC
TO
SANDRA ESTUDIAN PONENT 24 20 $150.000 $3’600.000

MILENA TE / ING. E
GUEVARA DE
MORALES SISTEMAS
ING. MSC DOCENTE DIRECTO 24 2 $200.000 $ 4’800.000

ROBERTO DE R
FERRO PLANTA
ESCOBAR
TOTAL $ 8’400.000
Tabla Anexo 2.2. Costos de personal
EQUIPO JUSTIFICACIÓN VALOR TOTAL

APROXIMADO
COMPUTADOR Requerido para crear el $150.000 $150.000

PORTATIL ambiente de desarrollo
local del prototipo (uso
de IDE, base de datos,
búsqueda de información,
modelado y documento
final)
EQUIPO SERVIDOR Requerido para crear el $ 1’000.000 $ 1’000.000

ambiente de producción
(base de datos y
despliegue de tecnologías
necesarias para el
correcto funcionamiento
del prototipo)
TOTAL $ 1’150.000
Tabla Anexo 2.3. Costos de equipos.
MATERIALES JUSTIFICACIÓN TOTAL
PAPELERIA / VARIOS Radicación, impresión del $ 200.000

documento de tesis,
anteproyecto, fotocopias.
TOTAL $ 200.000
Tabla Anexo 2.4. Costos de papelería y varios.
SOFTWARE JUSTIFICACIÓN COSTO TOTAL

APARENTE
NODE.JS Como soporte para la GNU/GPL $0

comunicación asíncrona.
SUBLIME TEXT IDE para el desarrollo de $ 220.000 $ 220.000

EDITOR la aplicación
LINUX (DISTRIBUCIÓN Sistema operativo donde GNU/GPL

NO ESPECIFICA) se establecerá el servidor. $0
ENTERPRISE Para realizar el modelado $ 300.000 $ 300.000

ARCHITECT de la aplicación.
TOTAL $ 520.000
Tabla Anexo 2.5. Costos de software.
13. REFERENCIAS
 Puranik, D.G., Feiock, D.C., Hill, J.H. (2013). Real-Time Monitoring using AJAX
and WebSockets. doi: 10.1109/ECBS.2013.10.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6601579&queryText=we
bsockets&newsearch=true
 Zhanikeev, M. (2013). A Practical Software Model for Content Aggregation in
Browsers Using Recent Advances in HTML5. doi: 10.1109/COMPSACW.2013.18.
 Mandyam, G.D., Ehsan, N. (2015). Impact of HTML5 persistent connectivity to
power consumption for the mobile web. doi: 10.1109/COMSNETS.2015.7098682
 Tilkov, S., Vinoski, S. (2010). Node.js: Using JavaScript to Build High-
Performance Network Programs. Internet Computing, IEEE. Volumen 14, 80-83.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5617064&queryText=no
de.js&newsearch=true
 Xiao-Feng Gu, Le Yang, Shaoquan Wu. (2014). A real-time stream system based on
node.js. doi: 10.1109/ICCWAMTIP.2014.7073454
 Jaramillo, D., Nguyen Van Duy, Newhook, R. (2014). Real-time experience
techniques for collaborative tools on mobile. doi: 10.1109/SECON.2014.6950669.
 Carter, B. (2014). HTML Architecture, a Novel Development System (HANDS):
An Approach for Web Development. doi: 10.1109/GOCICT.2014.23.
 Herrera-Quintero, L.F., Jalil-Naser, W.D., Banse, K., Samper-Zapater, J.J. (2015).
Smart cities approach for Colombian Context. Learning from ITS experiences and
linking with government organization. doi: 10.1109/SCSP.2015.7181557.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7181557&queryText=sm
art%20cities&newsearch=true
 Djahel, S., Doolan, R., Muntean, G.-M., Murphy, J. (2014). A Communications-
Oriented Perspective on Traffic Management Systems for Smart Cities: Challenges
and Innovative Approaches. Communications Surveys & Tutorials, IEEE. Volumen
(17). 125 - 151.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6857980&queryText=sm
art%20cities&newsearch=true
 Mesa J. (2016). Puzzle game online running on a bidirectional communication
framework based on Node.js and Socket.io. Microsoft Academic.
http://acceda.ulpgc.es/bitstream/10553/18827/1/0719712_00000_0000.pdf
 Xi-qi, Chen. (2016) On Implementation of Bidirectional Real-time Communication
between Server and Browser Based on Socket.IO Framework.
 Madsen, M., Tip, F., Lhoták, O. (2015) Static analysis of event-driven Node.js
JavaScript applications.
http://plg.uwaterloo.ca/~mmadsen/papers/oopsla15/paper.pdf.
 Bierman, G., Abadi, M., Torgersen, M. (2014) Understanding TypeScript.

Proceedings of the 28th European Conference on ECOOP 2014. doi: 10.1007/978-
3-662-44202-9_11.
 Vekris, P., Cosman, B., Jhala, R. (2016) Refinement types for TypeScript.
Proceedings of the 37th ACM SIGPLAN Conference on Programming Language
Design and Implementation. doi: 10.1145/2908080.2908110.
 Gabe, I., Hage, J. (2017) Refining types using type guards in TypeScript.
Proceedings of the 2017 ACM SIGPLAN Workshop on Partial Evaluation and
Program Manipulation. doi: 10.1145/3018882.3018887.
 Minder, P. (2016) Introducing modified TypeScript in an existing framework to
improve error handling.
http://liu.diva-portal.org/smash/get/diva2:937541/FULLTEXT01
 Like Parrot. Bogotá, Colombia. https://likeparrot.com

 Digiturno. Bogotá, Colombia. http://www.digiturno.com
 Elogia Marketing 4 ecommerce. Marzo 2016. I Customer Observatorium: la calidad
en atención al cliente.
http://www.lideresenservicio.com/wp-content/uploads/2016/03/Customer-
Observatorium-Informe-Completo.pdf
 Agendamientodigiturno.dian.gov.co. (2017). Agendamiento Web V2.0.0.4. [online]
Disponible en: https://agendamientodigiturno.dian.gov.co/.
 Cielingenieria.com. (2017). Digiturno – Ciel Ingeniería S.A.S.. [online] Disponible
en: http://cielingenieria.com/services/digiturno/
 Likeparrot. (2017). Likeparrot | Chat en Vivo Gratis para sitios web. [online]
Disponible en: https://likeparrot.com/home/

Gestión de turnos móvil

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestión de turnos móvil

Cargado por

Copyright:

Formatos disponibles

DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE ARQUITECTURA DE

SOFTWARE PARA ADMINISTRACIÓN DE TURNOS APOYANDO LA

SANDRA MILENA GUEVARA MORALES

Ph.D., MSC. ROBERTO FERRO ESCOBAR

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

SANDRA MILENA GUEVARA MORALES

Trabajo de grado para optar al título de

Ph.D., MSC. ROBERTO FERRO ESCOBAR

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

Actualmente la implementación de un sistema de información por parte de cualquier

Con el fin de proporcionar una solución a esta necesidad se propone el modelado y

¿Cómo la implementación de un sistema de administración de turnos como apoyo a la

2.1. JUSTIFICACIÓN TÉCNICA

2.2. JUSTIFICACIÓN ECONÓMICA

2.3. JUSTIFICACIÓN AMBIENTAL

La forma en que los usuarios de dependencias públicas de la ciudad de Bogotá solicitan

3.1. OBJETIVO GENERAL

3.2. OBJETIVOS ESPECÍFICOS

La Dirección de Impuestos y Aduanas Nacionales de Colombia (DIAN) posee un sistema

La característica en común de estas herramientas es el objetivo de brindar una mejor

5.1. Comunicación asíncrona

5.2. Programación orientada a eventos

En contraste con la programación procedimental (que simplemente actúa, y no reacciona) y

La programación orientada a eventos puede o no puede ser orientada a objetos o poseer un

En un punto de vista “todo es relativo” a la programación orientada a eventos se puede ver

Características típicas de eventos en la programación orientada a eventos (Xiao-Feng

● Los eventos son generalmente referenciados, indexados, o nombrados sobre la base

AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es

AJAX es una combinación de tres tecnologías ya existentes:

● HTML y hojas de estilos en cascada (CSS) para el diseño que acompaña a la

Tanto el API WebSocket y el protocolo WebSocket están estandarizados, lo que significa

5.5. Grupo de Investigación L.I.D.E.R1:

Generar y ejecutar en todas sus etapas, proyectos de investigación, desarrollo e innovación,

El Grupo de Investigación LIDER será, en un lapso no superior a 5 años, un grupo de

● Aplicación en domótica, inmótica y telemedicina.

6.1. NORMATIVIDAD EN COLOMBIA

3 Mapa normativo y regulatorio del sector TIC. Disponible en http://cintel.org.co/wp-

6.2. PLAN ESTRATÉGICO DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE

El Plan Estratégico “Saberes, Conocimientos e Investigación de Alto Impacto para el

Puntualmente para el tema de tecnologías de la información está el programa 4 que se

● Programa 4: Consolidación de la Infraestructura Informática, de Comunicaciones y

El diseño e implementación del prototipo de software para la administración de turnos

● Fase 1: Análisis de requerimientos.

Fase Objetivo por fase Actividad Resultado

Análisis de Establecer los Realizar una observación Generacion de

Diseño del Realizar el Establecer casos de uso y Descripción de la

Implementación Desarrollo del Realizar el desarrollo de Sistema en

Despliegue en Ejecutar la Transladar archivos e Puesta en marcha

Pruebas Verificar el Realizar prueba piloto de Documentación de

7.1. Enfoque investigativo

Al implementar herramientas como la planteada en este escrito, en el caso de las personas

7.3. Técnicas e instrumentos

Para el diseño de artefactos de ingeniería de software se utilizaron las siguientes

Actualmente la Red de Investigaciones de Tecnología Avanzada – RITA brinda asesorías

Adicionalmente, el prototipo desarrollado permite a los asesores realizar llamados a través

8.1. Especificación funcional

8.1.1. Análisis de requerimientos

8.1.1.1. Requerimientos funcionales

La aplicación contará con una sección de autenticación que permitirá establecer

R2 La aplicación contará con dos tipos de roles: cliente y asesor.

R3 La aplicación permitirá a los clientes solicitar y cancelar turnos.

La aplicación informará a todos los usuarios que tengan abierta la aplicación el