GuevaraMoralesSandraMilena2017

Vista previa del material en texto

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 DELPROBLEMA 
 
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 granmayoria 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 
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Mandyam,%20G.D..QT.&newsearch=true
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Ehsan,%20N..QT.&newsearch=true
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Xiao-Feng%20Gu.QT.&newsearch=true
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Xiao-Feng%20Gu.QT.&newsearch=true
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Le%20Yang.QT.&newsearch=true
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Shaoquan%20Wu.QT.&newsearch=trueejemplo, "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, 
https://es.wikibooks.org/wiki/Programaci%C3%B3n_en_JavaScript
https://es.wikibooks.org/wiki/Lenguaje_XHTML/Ventajas_del_XML
https://es.wikibooks.org/w/index.php?title=Web&action=edit&redlink=1
https://es.wikibooks.org/w/index.php?title=Cliente_(inform%C3%A1tica)&action=edit&redlink=1
https://es.wikibooks.org/w/index.php?title=As%C3%ADncrono&action=edit&redlink=1
https://es.wikibooks.org/w/index.php?title=Usabilidad&action=edit&redlink=1
https://es.wikibooks.org/w/index.php?title=Hojas_de_estilos_en_cascada&action=edit&redlink=1
https://es.wikibooks.org/w/index.php?title=Document_Object_Model&action=edit&redlink=1
https://es.wikibooks.org/w/index.php?title=ECMAScript&action=edit&redlink=1
https://es.wikibooks.org/wiki/Programaci%C3%B3n_en_JavaScript
https://es.wikibooks.org/w/index.php?title=XMLHttpRequest&action=edit&redlink=1
https://es.wikibooks.org/wiki/Lenguaje_XHTML/Ventajas_del_XML
https://es.wikibooks.org/w/index.php?title=Formato&action=edit&redlink=1
https://es.wikibooks.org/w/index.php?title=JSON&action=edit&redlink=1
https://es.wikibooks.org/w/index.php?title=EBML&action=edit&redlink=1
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Tilkov,%20S..QT.&newsearch=true
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Vinoski,%20S..QT.&newsearch=true
 
 
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ónpara 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 
requerimientos. 
Establecer los 
requerimientos 
funcionales y no 
funcionales del 
sistema. 
Realizar una observación 
detallada de la situación 
del modelo de atención al 
cliente actual. 
Generacion de 
modulos con sus 
respectivos 
requerimientos. 
Diseño del 
prototipo. 
Realizar el 
modelado 
funcional. 
Establecimiento de 
roles e interacción 
con el sistema. 
 
Establecer casos de uso y 
sus respectivos diagramas. 
 
Realizar diagramas de 
actividades. 
 
Realizar diagrama de roles 
de usuarios. 
Descripción de la 
etapa de modelado. 
Implementación Desarrollo del 
sistema e 
Realizar el desarrollo de 
cada módulo y la 
Sistema en 
funcionamiento que 
 
 
integración de 
herramientas 
necesarias. 
interacción entre ellos. consta de módulo 
de autenticación 
para 
administradores, de 
solicitud de turnos 
y de notificaciones. 
Despliegue en 
ambiente de 
producción. 
Ejecutar la 
aplicación en 
ambiente de 
producción. 
Transladar archivos e 
instalar herramientas 
necesarias en servidor. 
Puesta en marcha 
del sistema en un 
ambiente de 
producción. 
Pruebas Verificar el 
funcionamiento del 
sistema. 
Realizar prueba piloto de 
funcionamiento del 
sistema en RITA. 
Documentación de 
las pruebas 
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 exclusivapara 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 
R1 
La aplicación contará con una sección de autenticación que permitirá establecer 
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. 
R4 
La aplicación informará a todos los usuarios que tengan abierta la aplicación el 
turno atendido en ese momento y el último turno solicitado en tiempo real. 
R5 
La aplicación permitirá a los clientes calificar la asesoría recibida a través de una 
encuesta. 
R6 
La aplicación debe informar a los usuarios el tiempo faltante para ser atendido 
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: 
RNF 01 
Nombre: 
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 
Identificador: 
RNF 02 
Nombre: 
Plataforma aplicación móvil 
Descripción: La aplicación debe tener un correcto funcionamiento en la mayoría de 
dispositivos móviles Android. 
Criterios de Aceptación 
Tanto clientes como asesores podrán utilizar la aplicación desde sus dispositivos móviles. 
Tabla 8.3 Descripción requerimiento no funcional 
 
Calidad del Software 
Identificador: 
RNF 03 
Nombre: 
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. 
Tabla 8.4 Descripción requerimiento no funcional 
 
Disponibilidad 
Identificador: 
RNF 04 
Nombre: 
Disponibilidad del servicio 
Descripción: La aplicación debe estar disponible durante las 24. 
Criterios de Aceptación 
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. 
Tabla 8.5 Descripción requerimiento no funcional 
 
 
 
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 alternativos N/A 
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. 
Tabla 8.8 Descripción caso de uso 
 
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 alternativos N/A 
Caminos de excepción N/A 
Puntos de Extensión N/A 
Precondiciones N/A 
Criterios de aceptación La aplicación se puede cerrar desde cualquier punto. 
Tabla 8.9 Descripción caso de uso 
 
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 
 
El usuario oprime el tipo de 
asesoría que desea. 
La aplicación muestra al 
usuario un menú de posibles 
asesorías que puede recibir. 
 
La aplicación muestra el turno 
que está siendo atendido y el 
próximo turno disponible. 
Caminos alternativos N/A 
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. 
Tabla 8.10 Descripción caso de uso 
 
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 
 
 
 
El usuario selecciona 
cualquier ítem de la lista. 
usuario un listado de los turnos 
activos y su tipo de asesoría. 
 
La aplicación muestrael 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. 
Tabla 8.11 Descripción caso de uso 
 
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 alternativos N/A 
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. 
Tabla 8.12 Descripción caso de uso 
 
 
 
 
Nombre del Caso de Uso Realizar encuesta 
Resumen El cliente realiza una encuesta sobre la asesoría recibida. 
Curso básico de eventos 
 
 
El cliente diligencia la 
encuesta y oprime el botón 
“Enviar”. 
La aplicación muestra la 
encuesta al cliente antes de 
solicitar un turno del mismo 
tipo de asesoría. 
 
 
La aplicación envía los datos al 
servidor para ser almacenados. 
Caminos alternativos N/A 
Caminos de excepción No es posible establecer la conexión con el servidor. 
No se han diligenciado todos los campos de la encuesta. 
Puntos de Extensión N/A 
Precondiciones El cliente debe haber recibido una asesoría. 
Criterios de aceptación La aplicación permite al cliente evaluar la asesoría brindada. 
Tabla 8.13 Descripción caso de uso 
 
 
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. 
Caminos alternativos N/A 
Caminos de excepción No es posible establecer la conexión con el servidor. 
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. 
Tabla 8.14 Descripción caso de uso 
 
 
 
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. 
Caminos alternativos N/A 
Caminos de excepción No es posible establecer la conexión con el servidor. 
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. 
Tabla 8.15 Descripción caso de uso 
 
 
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. 
Caminos alternativos N/A 
Caminos de excepción No es posible establecer la conexión con el servidor. 
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. 
Tabla 8.16 Descripción caso de uso 
 
 
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). 
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Zhanikeev,%20M..QT.&newsearch=true
 
 
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 escritacon Node.js. 
2. Consulta a la base de datos (INSERT, SELECT, DELETE, UPDATE). 
3. Respuesta de la base de datos. 
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Jaramillo,%20D..QT.&newsearch=true
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Nguyen%20Van%20Duy.QT.&newsearch=true
http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Newhook,%20R..QT.&newsearch=true
 
 
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 
Atributo 
Descripción Tipo de 
dato 
Dominio 
R
eq
u
er
id
o
 
L
la
v
e 
p
ri
m
a
ri
a
 
L
la
v
e 
fo
rá
n
ea
 
C
la
v
e 
ú
n
ic
a
 Tabla 
referenciada 
Id_usuario Contiene un 
consecutivo que 
identifica a cada 
usuario dentro de 
esta tabla 
INT (1,214748
3647) 
S S N S 
documento Contiene el 
número de 
identificación del 
usuario 
VARCHA
R(50) 
a-z, A-Z S N N N 
nombre_com
pleto 
Contiene el 
nombre 
completo del 
usuario. 
VARCHA
R(140) 
a-z, A-Z S N N N 
clave Contiene la 
contraseña del 
usuario para 
tener acceso a las 
funciones de la 
aplicación. 
VARCHA
R(100) 
a-z, A-Z S N N N 
correo Contiene el 
correo 
electrónico del 
usuario 
VARCHA
R(100) 
a-z, A-Z S N N N 
id_rol Contiene una 
referencia al rol 
del usuario 
dentro de la 
aplicación 
INT (1,214748
3647) 
S N S N Rol(id_rol) 
Id_rolUniver
sidad 
Contiene una 
referencia al rol 
que tiene el 
usuario dentro de 
la universidad 
Distrital 
INT (1,214748
3647) 
S N S N RolUniversid
ad(id_rolUni
versidad) 
 
 
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. 
Nombre 
Atributo 
Descripción Tipo de 
dato 
Dominio 
R
eq
u
er
id
o
 
L
la
v
e 
p
ri
m
a
ri
a
 
L
la
v
e 
fo
rá
n
ea
 
C
la
v
e 
ú
n
ic
a
 Tabla 
referenciada 
id_tipoAseso
ria 
Contiene un 
consecutivo que 
identifica a cada 
tipo de asesoría 
dentro de esta 
tabla 
INT (1,214748
3647) 
S S N S 
nombre_tipo
Asesoria 
Contiene el 
nombre del tipo 
de asesoría 
VARCHA
R(50) 
a-z, A-Z S N N N 
turno_actual Contiene el turno 
que está siendo 
atendido 
actualmente. 
INT (1,214748
3647) 
S N N N 
ultimo_turno
_solicitado 
Contiene el 
número del 
último turno 
solicitado a 
través de la 
aplicación. 
INT (1,214748
3647) 
S N N N 
url_imagen Contiene la ruta 
de la imagen que 
representa el tipo 
de asesoría 
VARCHA
R(100) 
a-z, A-Z S N N N 
Tabla 8.18 Diccionario de tabla de la base de datos 
 
 
 
Asesoria 
Descripción Tabla que contiene los datos de las asesorías solicitadas. 
Nombre 
Atributo 
Descripción Tipo de 
dato 
Dominio 
R
eq
u
er
id
o
 
L
la
v
e 
p
ri
m
a
ri
a
 
L
la
v
e 
fo
rá
n
ea
 
C
la
v
e 
ú
n
ic
a
 Tabla 
referenciada 
 
 
Id_asesoria Contiene un 
consecutivo que 
identifica a cada 
asesoría 
solicitada 
INT (1,214748
3647) 
S S N S 
hora_inicio Contiene el día y 
la hora de inicio 
de la asesoría. 
TIMESTA
MP 
(01-01-
1970 
00:00, 31-
12-2037 
00: 00) 
N N N N 
hora_fin Contiene el día y 
la hora de 
finalización de la 
asesoría. 
TIMESTA
MP 
(01-01-
1970 
00:00, 31-
12-2037 
00: 00) 
N N N N 
numero_turn
o 
Numero de turno 
solicitado. 
INT (1,214748
3647) 
S N N N 
hora_solicitu
d 
Hora en que el 
usuario solicita 
el turno a través 
de la aplicación 
móvil. 
TIMESTA
MP 
(01-01-
1970 
00:00, 31-
12-2037 
00: 00) 
S N N N 
hora_cancela
cion 
Hora en que el 
usuario canceló 
la solicitad 
realizada. 
TIMESTA
MP 
(01-01-
1970 
00:00, 31-
12-2037 
00: 00) 
N N N N 
id_usuario Referencia del 
usuario que 
realizó la 
solicitud de 
turno. 
INT (1,214748
3647) 
S N S N Usuario(id_u
suario) 
id_encuesta Referencia a la 
encuesta 
realizada por el 
usuario. 
INT (1,214748
3647) 
S N S N Encuesta(id_
encuesta) 
id_tipoAseso
ria 
Referencia al 
tipo de asesoría a 
la cual pertenece 
el turno 
solicitado. 
INT (1,214748
3647) 
S N S N TipoAsesoria
(id_tipoAses
oria) 
Tabla 8.19 Diccionario de tabla de la base de datos 
 
 
 
 
 
 
 
 
Encuesta 
Descripción Tabla que contiene las respuestas de los usuarios que contestaron la encuesta a través 
de la aplicación móvil. 
Nombre 
Atributo 
Descripción Tipo de 
dato 
Dominio 
R
eq
u
er
id
o
 
L
la
v
e 
p
ri
m
a
ri
a
 
L
la
v
e 
fo
rá
n
ea
 
C
la
v
e 
ú
n
ic
a
 Tabla 
referenciada 
id_encuesta Contiene un 
consecutivo que 
identifica a cada 
encuesta 
realizada. 
INT (1,214748
3647) 
S S N S 
fecha Fecha en que se 
realiza la 
encuesta 
TIMESTA
MP 
(01-01-
1970 
00:00, 31-
12-2037 
00: 00) 
S N N N 
actitud Respuesta 
relacionada a la 
pregunta sobre 
actitud del 
asesor. 
INT (1,214748
3647) 
S N N N 
tiempo Respuesta 
asociada al 
tiempo de 
respuesta del 
asesor. 
INT (1,214748
3647) 
S N N N 
orientacion Respuesta 
asociada al nivel 
de orientación 
brindada por el 
asesor. 
INT (1,214748
3647) 
S N N N 
grado Respuesta 
asociada al grado 
de conformidad 
con la asesoría 
recibida. 
INT (1,214748
3647) 
S N N N 
observacione
s 
Observaciones 
adicionales 
enviadas por los 
usuarios. 
VARCHA
R(400) 
a-z, A-Z S N N N 
Tabla 8.20 Diccionario de tabla de la base de datos 
 
 
 
 
 
 
 
Encuesta 
Descripción Tabla que contiene las respuestas de los usuarios que contestaron la encuesta a través 
de la aplicación móvil. 
Nombre 
Atributo 
Descripción Tipo de 
dato 
Dominio 
R
eq
u
er
id
o
 
L
la
v
e 
p
ri
m
a
ri
a
 
L
la
v
e 
fo
rá
n
ea
 
C
la
v
e 
ú
n
ic
a
 Tabla 
referenciada 
id_encuesta Contiene un 
consecutivo que 
identifica a cada 
encuesta 
realizada. 
INT (1,214748
3647) 
S S N S 
fecha Fecha en que se 
realiza la 
encuesta 
TIMESTA
MP 
(01-01-
1970 
00:00, 31-
12-2037 
00: 00) 
S N N N 
actitud Respuesta 
relacionada a la 
pregunta sobre 
actitud del 
asesor. 
INT (1,214748
3647) 
S N N N 
tiempo Respuesta 
asociada al 
tiempo de 
respuesta del 
asesor. 
INT (1,214748
3647) 
S N N N 
orientacion Respuesta 
asociada alnivel 
de orientación 
brindada por el 
asesor. 
INT (1,214748
3647) 
S N N N 
grado Respuesta 
asociada al grado 
de conformidad 
con la asesoría 
recibida. 
INT (1,214748
3647) 
S N N N 
observacione
s 
Observaciones 
adicionales 
enviadas por los 
usuarios. 
VARCHA
R(400) 
a-z, A-Z S N N N 
Tabla 8.21 Diccionario de tabla de la base de datos 
 
 
 
 
 
 
 
Rol 
Descripción Tabla que contiene los diferentes roles que los usuarios pueden tener para acceder al 
contenido de la aplicación. 
Nombre 
Atributo 
Descripción Tipo de 
dato 
Dominio 
R
eq
u
er
id
o
 
L
la
v
e 
p
ri
m
a
ri
a
 
L
la
v
e 
fo
rá
n
ea
 
C
la
v
e 
ú
n
ic
a
 Tabla 
referenciada 
id_rol Contiene un 
consecutivo que 
identifica cada 
tipo de rol. 
INT (1,214748
3647) 
S S N S 
nombre_rol Nombre que 
describe el rol 
VARCHA
R(50) 
a-z, A-Z S N N N 
Tabla 8.22 Diccionario de tabla de la base de datos 
 
 
RolUniversidad 
Descripción Tabla que contiene los diferentes roles que los usuarios pueden tener dentro de la 
universidad Distrital. 
Nombre 
Atributo 
Descripción Tipo de 
dato 
Dominio 
R
eq
u
er
id
o
 
L
la
v
e 
p
ri
m
a
ri
a
 
L
la
v
e 
fo
rá
n
ea
 
C
la
v
e 
ú
n
ic
a
 Tabla 
referenciada 
id_rolUniver
sidad 
Contiene un 
consecutivo que 
identifica cada 
tipo de rol dentro 
de la 
universidad. 
INT (1,214748
3647) 
S S N S 
rol Nombre que 
describe el rol. 
VARCHA
R(50) 
a-z, A-Z S N N N 
Tabla 8.23 Diccionario de tabla de la base de datos 
 
 
 
 
 
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. 
http://localhost:8100/
 
 
 
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