/05/
DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA
INTEGRAL DE CONTROL DE TURNOS
DESIGN AND IMPLEMENTATION OF AN INTEGRAL
SYSTEM OF CONTROL OF TURNS
Eder Carlos Rai Ramos Rosales
Ingeniero en Informática, Estudiante de Maestría en Sistemas Computacionales,
Instituto Tecnológico de Colima (México).
E-mail: g1746001@itcolima.edu.mx ORCID: https://orcid.org/0000-0001-7747-582X
Jesús Alberto Verduzco Ramírez
Doctor en Informática, Docente Investigador,
Instituto Tecnológico de Colima (México).
E-mail: averduzco@itcolima.edu.mx ORCID: https://orcid.org/0000-00001-5041-374
Noel García Díaz
Doctor en Tecnologías de Información, Docente Investigador,
Instituto Tecnológico de Colima (México).
E-mail: ngarcia@itcolima.edu.mx ORCID: https://orcid.org/0000-0002-7078-0941
Santiago Arceo Díaz
Doctor en Ciencias con especialidad en Astrofísica, Docente Investigador,
Instituto Tecnológico de Colima (México).
E-mail: santiago.arceo@itcolima.edu.mx ORCID: https://orcid.org/0000-0002-7085-3653
Recepción: 04/07/2018. Aceptación: 03/09/2018. Publicación: 25/02/2019
Citación sugerida:
Ramos Rosales, E. C. R., Verduzco Ramírez, J. A., García Díaz, N. y Arceo Díaz, S. (2019). Diseño e
implementación de un sistema integral de control de turnos. 3C Empresa. Investigación y pensamiento crítico, 8(1),
pp. 92-111. doi: http://dx.doi.org/10.17993/3cemp.2019.080137.92-111
94
3C Empresa. Investigación y pensamiento crítico. ISSN: 2254-3376
RESUMEN
Los sistemas de control de turnos son una herramienta indispensable para cualquier empresa que
atiende un gran número de personas en la labor de su día a día. En el proyecto aquí expuesto
se presenta un sistema integral desarrollado en un ambiente web, a través de la metodología de
desarrollo Scrum, obteniendo como resultado la creación de reportes e históricos, la gestión de la
empresa, así como verificar la productividad en tiempo real mediante gráficas.
ABSTRACT
Turn control systems are an indispensable tool for any company that attends a large number of people in the work of
their day to day. In this project, is presented an integral system developed in a web environment, through the methodology
of scrum development, obtaining as result the creation of reports and historical, the management of the company, as
well as verifying the productivity in real time by means of graphs.
PALABRAS CLAVE
Sistema Integral, Toma Turnos, Web, Gestión, Control.
KEYWORDS
Integral System, Take Turns, Web, Management, Control.
95
Ed. 37. Vol.8 Nº 1. Febrero-Mayo ‘19
DOI: http://dx.doi.org/10.17993/3cemp.2019.080137.92-111
1. INTRODUCCIÓN
Actualmente, para las empresas del sector público y privado, no es sencillo adquirir las herramientas
tecnológicas que les permita brindar una mejor experiencia a los usuarios, por lo que no se percibe
un valor agregado en los trámites y servicios que diariamente ofertan a la población. Una de las
alternativas para las empresas, es implementar sistemas de información automatizada, que se
definen por Peralta (2008) como un conjunto de elementos que interactúan entre sí con el fin de
apoyar las actividades de una empresa o negocio. Para las empresas que atienden diariamente
numerosos usuarios los sistemas de control de turnos automáticos son un elemento esencial para la
satisfacción con los trámites y servicios prestados. Existen diferentes soluciones en el mercado actual,
sin embargo, estas soluciones, en términos generales, implican altas erogaciones a las empresas y son
sistemas genéricos que representan problemas de adaptación a los procesos de cada organización. El
proyecto desarrollado se enfoca en generar una solución accesible y a la medida de las necesidades
tecnológicas de las empresas del mercado mexicano que en su catálogo oferten trámites y servicios.
La empresa piloto, para la cual se desarrolló el proyecto que se presenta en este trabajo, se dedica
a la prestación de trámites y servicios a la población. De acuerdo con datos de INEGI, en la
Ciudad de México habitan 8.918.653 personas (INEGI, 2015). La empresa está ubicada en la zona
industrial de la Ciudad de México (México), la cual atiende diariamente alrededor de 600 personas
y pertenece al ramo de trámites y servicios de una empresa gubernamental, que de acuerdo con
(INEGI, 2015) representaron el 61.9% de los trámites realizados en el país en el año 2015. En sus
oficinas no contaban con la automatización de la expedición, control y seguimiento de turnos.
Para las empresas que atienden diariamente numerosos usuarios los sistemas de control de
turnos automáticos son un elemento esencial para la satisfacción con los trámites y servicios
prestados.
96
3C Empresa. Investigación y pensamiento crítico. ISSN: 2254-3376
2. METODOLOGÍA
Para el desarrollo de este proyecto se llevó a cabo una investigación documental en la empresa, medios
electrónicos, así como información impresa recopilada. Para la investigación de campo, se elaboró
un cuestionario en dos versiones, una dirigida a los trabajadores y a la población que comúnmente
acuden a realizar algún trámite o servicio. En su elaboración, se cuidó que se documentaran
los procesos que se llevan a cabo diariamente para la atención, así como la información básica
requerida por las instituciones que las norman. En el caso de los trabajadores, se les preguntó por las
principales funciones que podría atender el sistema integral de control de turnos, de tal manera que
las evaluaran por su utilidad. Respecto a la investigación aplicada, esta utilizó la metodología Scrum,
que define Mariño (2014) como un sistema interactivo e incremental para el desarrollo de proyectos
y se estructura en ciclos de trabajo llamados sprint. Schwaber y Sutherland (2016), los definen como
a un intervalo de tiempo de máximo un mes, donde se desarrolla el incremento de un producto,
potencialmente entregable. El equipo multi-funcional selecciona los elementos (requerimientos del
cliente) de una lista priorizada. Dicha metodología se seleccionó por las bondades que tiene para
generar las funcionalidades más prioritarias señaladas por el cliente en un corto tiempo, en este caso
el responsable o administrador de la empresa.
2.1. ANÁLISIS
En esta fase se detectaron los requerimientos, los cuales fueron representados en la herramienta
Enterprise Architect para poder llevar a cabo la elaboración del sistema. Por lo cual, se realizó
una reunión con cada uno de los involucrados en el sistema, donde se definieron sus roles y sus
principales requerimientos, los cuales se muestran en la Figura 1.
97
Ed. 37. Vol.8 Nº 1. Febrero-Mayo ‘19
DOI: http://dx.doi.org/10.17993/3cemp.2019.080137.92-111
ADMINISTRADOR OPERADOR USUARIOS
El sistema debe permitir
imprimir grácos de la
productividad.
El sistema debe permitir
elegir al operador su caja
de atención.
El sistema debe permitir
imprimir un turno.
El sistema debe permitir
asignar cajas a los
operadores.
El sistema debe permitir
nalizar turnos.
El sistema debe permitir
imprimir reportes por
operador, rango de
fechas, trámite y/o
servicio.
El sistema debe permitir
llamar al cliente hasta
tres veces.
El sistema debe mostrar
la información actual de
los turnos atendidos y
cancelados.
El sistema debe permitir
cancelar turnos.
Figura 1. Requerimientos funcionales.
2.2. CASOS DE USO
En cuanto al modelado formal del sistema, se diseñaron casos de uso para representar las actividades
del sistema y la interacción de los actores con este. Así pues, esta técnica de modelado se desarrolló
para reducir los errores en la fase de diseño y construcción debido a que UML es un estándar
mundial, que define Fowler (1997), como un lenguaje de modelado de sistemas y no un método. En
la Figura 2 se muestra un ejemplo de un caso de uso general. Asimismo, se muestra la interacción de
cada uno de los actores con el sistema, teniendo como actores principales al Administrador, que es
quien se encarga de gestionar todos los módulos del sistema. El Operador, que es el responsable de
atender a los usuarios y llamar a los usuarios hasta tres veces, cancelar y finalizar turnos. Por último,
tenemos al Usuario, que es el que acude a realizar un trámite y/o servicio a la empresa, y tiene la
capacidad de imprimir su ticket al que se le asignará un turno.
98
3C Empresa. Investigación y pensamiento crítico. ISSN: 2254-3376
Generar Turno
Tomar Turno
Finalizar Turno
Cancelar Turno
Administrar
Catálogos
Imprimir
Reportes
Figura 2. Diagrama de casos de uso.
2.3. PLAN DE EJECUCIÓN
Para llevar el control y seguimiento de las actividades incluidas en las distintas fases del ciclo de
vida del sistema, se implementó un calendario de actividades bajo un diagrama de Gantt, tal como
el desarrollado en el trabajo de Dayani y Gelbard, (2015). Esto permitió determinar la ruta crítica
del sistema y detectar retrasos que a la larga representan sobrecostos en el tiempo y presupuesto de
desarrollo del sistema (Figura 3).
Figura 3. Plan de ejecución del sistema.
99
Ed. 37. Vol.8 Nº 1. Febrero-Mayo ‘19
DOI: http://dx.doi.org/10.17993/3cemp.2019.080137.92-111
2.4. SOLUCIONES SIMILARES
En cuanto a la revisión de los proyectos similares, se encontró que en el trabajo realizado por
Ramos, (2014) se busca crear una herramienta informática que permita al usuario solicitar un
turno para realizar trámites referentes a licencias de conducir en la Agencia Nacional de Transito
Babahoyo. De igual manera, en el proyecto desarrollado en Ramos, et al (2012), se implementó un
sistema en ambiente web donde el objetivo fue automatizar los turnos de llegada y atención que se
brinda a los usuarios. Una de las funciones principales del sistema es asignar los respectivos turnos a
cada ciudadano teniendo en cuenta la diligencia o documentación que se va a realizar.
2.5. INICIACIÓN
En la fase de análisis, establecimos la visión del proyecto y se definió un alcance en la funcionalidad
del sistema. Con respecto a la programación y desarrollo del sistema, se eligió el lenguaje ASP.
NET, que en el trabajo desarrollado por Min, (2011) se describe como la solución de Microsoft
para la creación de aplicaciones web dinámicas de alto rendimiento. Por otra parte, se trabajó en
conjunto con el framework MVC que, de acuerdo con González y Romero (2012), es un paradigma
que divide las partes que conforman una aplicación en el modelo, las vistas y los controladores,
permitiendo la implementación por separado de cada elemento, garantizando así la actualización y
mantenimiento del software de forma sencilla y en un reducido espacio de tiempo.
En cuanto al tratamiento y almacenamiento de los datos, se optó por SQL, por ser un lenguaje que
encabeza los estándares de seguridad y fiabilidad. Además, se identificó al Scrum Master que, de
acuerdo con Schwaber y Sutherland (2016), es el responsable de asegurar que Scrum se entienda
y se adopte. En cuanto a los interesados, el personal de la empresa fungió como usuarios piloto. El
equipo SCRUM, según Schwaber y Sutherland, (2016) consiste en un Dueño de Producto (Product
Owner), el Equipo de Desarrollo (Development Team) y un Scrum Master. Dicho Equipo Scrum
estuvo integrado por seis ingenieros, con roles diferentes para desarrollar el proyecto. Las primeras
épicas fueron realizadas en base a la visión del proyecto. Estas están relacionadas con la funcionalidad
100
3C Empresa. Investigación y pensamiento crítico. ISSN: 2254-3376
del sistema, entre ellas están la alta de pantallas, cajas o puntos de atención, usuarios, generación de
reportes, el llenado de los catálogos del sistema, entre otros. Hecho esto, se creó la lista de pendientes
en la que se categorizó la prioridad de las épicas, dando lugar a la siguiente lista:
Registro de trámites y servicios.
Generación reportes.
Emisión de tickets.
Registro de personal.
Una vez formuladas las épicas, se determinó que al término del tercer sprint se podría hacer el primer
lanzamiento de la aplicación en nivel prototipo.
2.6. PLANEACIÓN Y ESTIMACIÓN
El Product Owner y los Stakeholders Nateevo (2012), los define como un conjunto de personas que
no forman parte directa del proceso de desarrollo pero que deben ser tomados en cuenta, por ser
personas interesadas en el mismo. Al mismo tiempo que estos validaron las épicas, procedimos a
elaborar las historias de usuario, por cada Épica se crearon más de una historia de usuario, la Tabla
1 muestra un ejemplo:
Tabla 1. Historias de usuario.
Registro de personal
COMO < Administrador> QUIERO <Registrar a los empleados que laboran dentro de la empresa >
DE TAL MANERA QUE <Pueda llevar el control de los trabajadores>
CON LOS SIGUIENTES CRITERIOS DE ACEPTACION < Nombre de empleado; Rol; Usuario >
Organizados como Scrum Team, se llevó a cabo la reunión para aprobar, estimar y asignar historias
de usuarios a los miembros. Una vez asignadas las historias de usuarios procedimos a que cada
miembro creara sus tareas. Así, por cada épica se crearon historias de usuario y por cada historia
101
Ed. 37. Vol.8 Nº 1. Febrero-Mayo ‘19
DOI: http://dx.doi.org/10.17993/3cemp.2019.080137.92-111
de usuario se crearon tareas, las cuales fueron estimadas en tiempo y esfuerzo para delimitar la lista
de tareas que serían parte de cada sprint. Para el desarrollo del proyecto se utilizó una herramienta
de apoyo llamada Trello que de acuerdo con Trello (2018), es una herramienta de colaboración
que organiza proyectos en tableros. Dicha herramienta permite conocer cuáles son las tareas que se
llevan a cabo, quién trabaja en una tarea determinada y cuál es el estado de un proceso. La Figura
4 muestra ejemplos de tareas del desarrollo del proyecto.
Figura 4. Ejemplo de tareas.
2.7. IMPLEMENTACIÓN
El Scrum Team desarrolló los entregables de cada sprint, les aplicó las pruebas pertinentes y los
validó con el Product Owner. Diariamente, se realizó la reunión de 15 minutos donde el Scrum
Master preguntaba al equipo las acciones que se habían tomado y qué obstáculos se presentaban
diariamente.
2.8. REVISIÓN Y RETROSPECTIVA
Se realizó la reunión para mostrar y validar los entregables de cada sprint. En esta reunión estuvo
presento el Dueño del Producto. En algunos sprint, las observaciones impidieron entregar la lista de
funcionalidades programadas. Se revisó cada sprint y se mejoró el desempeño del equipo conforme
se avanzaba el proyecto.
102
3C Empresa. Investigación y pensamiento crítico. ISSN: 2254-3376
2.9. LANZAMIENTO
En términos generales, el proyecto se presentó de acuerdo a la lista priorizada de pendientes y
funcionalidades. Sus módulos fueron integrados conforme se liberaban en cada sprint, así en la
fase de trámites y servicios se pudo completar el proceso que debe seguirse en la atención de un
turno, como son: la generación del turno, llamado del turno, y atención del mismo. En la parte
que corresponde a los reportes, se logró la generación de reportes por periodo, cajas y/o puntos de
atención y se representaron en forma gráfica los datos solicitados en distintas gráficas.
El proceso de retrospectiva del proyecto dio como resultado mejorar la coordinación del equipo y
ser más precisos con las historias de usuario para desarrollar con mayor certidumbre y eficiencia las
épicas.
3. RESULTADOS
Con relación al proyecto, se realizaron pruebas funcionales, por ejemplo, atender un turno,
en cuanto a las de caja negra. Pongamos por caso cuando el sistema envía una notificación de
los turnos restantes para comprobar la fiabilidad del sistema desarrollado. Por otra parte, se
realizaron reuniones de capacitación para el administrador y cajas o puntos de atención. Se les
explicó de manera detallada el funcionamiento del sistema y ellos operaron durante un tiempo
de prueba de tres meses. Durante este periodo, los usuarios del sistema estuvieron reportando las
incidencias encontradas. Estas incidencias fueron atendidas en reuniones semanales para mejorar
el funcionamiento de los módulos establecidos, así como nuevas solicitudes de cambios. Con la
finalidad de facilitar la explicación relacionada a los resultados obtenidos, esta sección se divide en
varios módulos, lo mismos que se muestran en el diagrama de la Figura 5 y que se describen en esta
sección del artículo.
103
Ed. 37. Vol.8 Nº 1. Febrero-Mayo ‘19
DOI: http://dx.doi.org/10.17993/3cemp.2019.080137.92-111
Figura 5. Estructura de la aplicación.
3.1. ADMINISTRADOR
El módulo de administración es la pieza modular del sistema, ya que desde aquí se puede acceder
a la configuración de cajas o puntos de atención, así como mantener el control de contenidos para
personalizar las pantallas. De igual manera, su desarrollo está orientado hacia catálogos, lo cual le
otorga la libertad en todo momento de ser configurable y adaptable a las necesidades de la empresa
(Figura 6).
Figura 6. Módulo de administración del sistema.
3.2. OPERADOR
El módulo del operador es la interfaz que permite al encargado de caja o punto de atención, llamar
y/o atender un turno (Figura 7). Concretamente, se puede llamar un turno hasta tres veces y si la
104
3C Empresa. Investigación y pensamiento crítico. ISSN: 2254-3376
persona no se presenta se tiene la posibilidad de cancelarlo. De igual manera, se muestran los turnos
restantes que se actualizan en tiempo real, sin necesidad de recargar la página. Así pues, al atender
un turno este será llamado por la voz del sistema mencionando su serie y su número, el mismo que
se desplegará en la pantalla (Figura 9).
Figura 7. Módulo de operador del sistema.
3.3. DISPENSADOR
El módulo de dispensador de tickets es la vista que despliega los trámites y servicios con los que
cuentan la empresa (Figura 8). En particular, cuando un usuario elige un trámite o servicio se arroja
un mensaje que le indica que su ticket está siendo procesado, para finalmente imprimirlo y el usuario
pueda retirarlo. En la Figura 6 se muestra el diseño del ticket arrojado por el dispensador.
105
Ed. 37. Vol.8 Nº 1. Febrero-Mayo ‘19
DOI: http://dx.doi.org/10.17993/3cemp.2019.080137.92-111
Figura 8. Módulo de dispensador.
Figura 9. Ticket generado por el sistema.
3.4. PANTALLA
El módulo de pantalla es la vista que permite la visualización de manera gráfica y sonora de los
turnos que son llamados por los encargados de ventanilla (Figura 10). Por otro lado, la vista se
actualiza conforme los operadores están llamando y/o atendiendo turnos, esto gracias a un web
socket que se encarga de verificar el estatus de todos los turnos, además este módulo es totalmente
configurable desde el administrador (Figura 6).