CIS2021CP02 - repository.javeriana.edu.co

CIS2021CP02

AEDRA

Aprendizaje de estructuras de datos mediado por realidad aumentada

Daniel Fernando Beltrán Huertas

Andrés Camilo Giraldo Gil

Natalia Andrea Navas Calderón

Juan Sebastián Santamaría Palomino

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

SYSTEMS ENGINEERING PROGRAM

BOGOTÁ, D.C.

2021

Pontificia Universidad Javeriana Informe del Proyecto final de Pregrado

Page i

CIS2021CP02

AEDRA

Aprendizaje de estructuras de datos mediado por realidad aumentada

Autores:

Daniel Fernando Beltrán Huertas

Andrés Camilo Giraldo Gil

Natalia Andrea Navas Calderón

Juan Sebastián Santamaría Palomino

REPORTE FINAL DEL PROYECTO DE PREGRADO REALIZADO PARA CUMPLIR UNO DE

LOS REQUERIMIENTOS PARA EL TÍTULO DE INGENIERÍA DE SISTEMAS

Director

Ing. César Julio Bustacara Medina

Jurados del Proyecto Final de Pregrado

Ing. Leonardo Florez Valencia

Ing. Jaime Pavlich Mariscal

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

PROGRAMA DE INGENIERÍA DE SISTEMAS

BOGOTÁ, D.C.

Noviembre, 2021

Ingeniería de Sistemas Informe del Proyecto final de Pregrado

- CIS2021CP02

Page ii

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA

PROGRAMA DE INGENIERÍA DE SISTEMAS

Rector Pontificia Universidad Javeriana

Padre Jorge Humberto Peláez Piedrahita, S.J.

Decano de la Facultad de Ingeniería

Ing. Lope Hugo Barrero Solano Ph.D.

Directora del Programa de Ingeniería de Sistemas

Ing. Alexandra Pomares Quimbaya Ph.D.

Director del Departamento de Ingeniería de Sistemas

Ing. César Julio Bustacara Medina Ph.D.


Page iii

Artículo 23 de la Resolución No. 1 de junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus

proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral

católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que

se vean en ellos el anhelo de buscar la verdad y la Justicia”


- CIS2021CP02

Page iv

AGRADECIMIENTOS

Agradecemos a los docentes que nos acompañaron en el proceso de desarrollo del

trabajo de grado, en especial, al Ingeniero César Julio Bustacara por su orientación,

disposición y compromiso para con nosotros.

Adicionalmente, como grupo sentimos gratitud por el trabajo realizado por parte de

cada miembro. Por la dedicación y esfuerzo a pesar de las circunstancias donde el

tiempo no siempre estuvo a favor.


Page v

I. INTRODUCCIÓN ............................................................................................... 1

II. DESCRIPCIÓN GENERAL .................................................................................... 2

1. OPORTUNIDAD, PROBLEMA ...................................................................................... 2

i. Contexto del problema .................................................................................................. 2

ii. Formulación del problema ........................................................................................ 3

iii. Solución propuesta ................................................................................................... 4

iv. Justificación de la solución........................................................................................ 5

2. DESCRIPCIÓN DEL PROYECTO .................................................................................... 7

i. Objetivo general ............................................................................................................ 7

ii. Objetivos específicos. ................................................................................................ 7

iii. Entregables, estándares y justificación .................................................................... 7

III. CONTEXTO DEL PROYECTO ............................................................................... 9

1. ANTECEDENTES ...................................................................................................... 9

2. ANÁLISIS DEL CONTEXTO ........................................................................................ 11

i. Alternativas de solución .............................................................................................. 11

ii. Comparación de alternativas ................................................................................. 13

IV. ANÁLISIS DEL PROBLEMA ............................................................................... 15

1. REQUERIMIENTOS ................................................................................................ 15

i. Requerimientos funcionales ........................................................................................ 15

ii. Requerimientos no funcionales .............................................................................. 16

2. RESTRICCIONES .................................................................................................... 18

i. Restricciones de Software. .......................................................................................... 18

ii. Restricciones de Hardware. .................................................................................... 18

3. ESPECIFICACIÓN FUNCIONAL ................................................................................... 19

i. Mockups ...................................................................................................................... 19

ii. Diagrama de casos de uso. ..................................................................................... 22

iii. Diagrama de actividades ........................................................................................ 23

V. DISEÑO DE LA SOLUCIÓN ................................................................................ 25

1. HERRAMIENTAS DE DESARROLLO ............................................................................. 25

i. Plataforma de desarrollo: ........................................................................................... 25

ii. Tecnología de realidad aumentada ........................................................................ 26

iii. Distribución de la solución ...................................................................................... 27


- CIS2021CP02

Page vi

2. ARQUITECTURA .................................................................................................... 27

i. Patrón arquitectural.................................................................................................... 27

ii. Vista de desarrollo .................................................................................................. 28

iii. Vista física ............................................................................................................... 32

3. DISEÑO DETALLADO DE LA SOLUCIÓN ........................................................................ 34

i. Clases .......................................................................................................................... 34

ii. Persistencia ............................................................................................................. 36

VI. DESARROLLO DE LA SOLUCIÓN ....................................................................... 37

1. FASE PRE-IMPLEMENTACIÓN ................................................................................... 37

2. FASE DE DESARROLLO ........................................................................................... 38

3. PRUEBAS ............................................................................................................ 39

4. PRODUCTO FINAL ................................................................................................. 40

i. Interfaces de inicio ...................................................................................................... 40

ii. Diseño de marcadores ............................................................................................ 41

iii. Marcador de estructuras ........................................................................................ 42

iv. Marcadores de algoritmos ..................................................................................... 42

v. Marcadores de información ................................................................................... 44

vi. Personalización de una ED ...................................................................................... 46

vii. Algoritmos implementados .................................................................................... 49

VII. PRUEBAS DE ACEPTACIÓN Y RESULTADOS ...................................................... 51

1. ENCUESTA DE ACEPTACIÓN AL USUARIO: ................................................................... 52

2. ANÁLISIS DE RESULTADOS ....................................................................................... 54

i. Análisis por dimensiones ............................................................................................. 54

ii. Síntesis de resultados ............................................................................................. 58

VIII. CONCLUSIONES ........................................................................................ 60

1. ANÁLISIS DEL IMPACTO DEL PROYECTO ..................................................................... 61

2. TRABAJO A FUTURO .............................................................................................. 62

i. Educación .................................................................................................................... 62

ii. Extensión de funcionalidades ................................................................................. 62

iii. Extensión de tecnología .......................................................................................... 63

IX. REFERENCIAS ................................................................................................. 65

X. APÉNDICES .................................................................................................... 68


Page vii

ABSTRACT

Data structures concepts are fundamental in careers related to systems

engineering. Nonetheless, courses in this area are challenging for stu-

dents, mainly due to the lack of practical skills and the abstract nature

of the data structures. Therefore, the present work takes advantage of

the rise of innovative technologies in the educational field to propose

a solution that, with the use of augmented reality, takes the concepts

to a visual and interactive context. Obtained results showed that this

tool can support the learning process by promoting interest and motiva-

tion.

RESUMEN

Los conceptos de estructuras de datos son fundamentales en carreras afines

a ingeniería de sistemas. No obstante, los cursos en esta área resultan

desafiantes para los estudiantes, principalmente por la falta de habili-

dades prácticas y la naturaleza abstracta de las estructuras. De esta

forma, el presente trabajo aprovecha el auge de tecnologías innovadoras

en el campo educativo para proponer una solución que, con el uso de

realidad aumentada, lleve los conceptos a un contexto visual e interac-

tivo. Los resultados evidenciaron que esta herramienta puede apoyar el

proceso de aprendizaje fomentando el interés y la motivación.


Page 1

I. INTRODUCCIÓN

En el presente documento se describe el proceso de desarrollo de AEDRA, una aplicación mó-

vil enfocada a dar soporte al proceso de aprendizaje de estructuras de datos utilizando reali-

dad aumentada. Esta idea se concibe teniendo en cuenta la dificultad de los estudiantes uni-

versitarios para comprender los conceptos abstractos asociados a estructuras de datos.

AEDRA es una solución que propone un enfoque visual e interactivo, haciendo uso de realidad

aumentada para proyectar el funcionamiento de diferentes algoritmos. El principal propósito

de esta herramienta consiste en impulsar el interés de los usuarios para aprender de forma

proactiva.

El documento se encuentra estructurado en diferentes secciones, partiendo de la formulación

de la problemática junto con la descripción general del proyecto. Posteriormente, se descri-

ben los antecedentes y alternativas de la solución, con el objetivo de introducir las diferentes

fases metodológicas realizadas, las cuales comprenden: especificación de requerimientos, di-

seño, desarrollo del software y finalmente, pruebas y análisis de resultados.


- CIS2021CP02

Page 2

II. DESCRIPCIÓN GENERAL

La presente sección tiene como finalidad brindar un contexto general sobre el cual se desa-

rrolla la solución y definir el objetivo del trabajo de grado.

1. Oportunidad, problema

A continuación, se presenta el contexto, la descripción y la justificación de la solución pro-

puesta en el presente trabajo de grado.

i. Contexto del problema

El mundo tecnológico se encuentra en constante desarrollo, como consecuencia se ha intro-

ducido en todos los aspectos de la vida. El internet, computadores, celulares, radios, disposi-

tivos IoT, consolas, electrodomésticos, etc. son parte del diario vivir de las personas y han

marcado un cambio drástico en la sociedad. Debido a dicha inmersión, ha aumentado la can-

tidad de personas interesadas en una formación profesional en el área de tecnología e infor-

mática [1]. Consecuentemente, hay un gran número de potenciales desarrolladores de soft-

ware que deberán afrontar grandes retos, como aprender a programar.

Enseñar lógica de programación es un reto debido a que se requieren diferentes competen-

cias para evidenciar mejoras en los resultados, tales como: comprensión de conceptos abs-

tractos, capacidad de identificar y corregir errores y la aplicación del conocimiento adquirido

para crear soluciones a problemas algorítmicos [2].

Para forjar competencias programáticas se emplean distintas técnicas de enseñanza, entre

las más comunes se encuentra el modelo tradicional, basado en definiciones teóricas de con-

ceptos y su respectiva representación en imágenes estáticas. Otro modelo, más llamativo, se

basa en el aprendizaje centrado en el estudiante, donde se incentiva a aprender fuera de las

aulas de clase mediante métodos de trabajo independiente [3].


Page 3

Dentro del área de programación e informática, se encuentra el concepto de estructuras de

datos. Entiéndase estructuras de datos como la forma en que se organizan y manejan los da-

tos en un computador [4]. Bajo este concepto, se desarrollan elementos vitales para el fun-

cionamiento de muchos de los sistemas de cómputo hoy en día, tales como, listas, arreglos,

pilas, colas, árboles, grafos, entre otras derivaciones. Tener conocimiento en esta área es pri-

mordial, no sólo para la formación profesional, sino también para comprender la dificultad

que conlleva realizar algoritmos eficientes. El uso de estructuras de datos es fundamental en

el desarrollo de programas de software, gracias a ellas es posible lidiar con la complejidad de

muchos algoritmos, mejoran el desempeño de programas informáticos y son esenciales en el

manejo de grandes volúmenes de información [5]. Por todas estas razones, representa uno

de los cursos más críticos, fundamentales y desafiantes para los estudiantes de carreras afines

a la ingeniería de sistemas [6].

Desafortunadamente, los estudiantes presentan dificultades para entender los principales

conceptos de estructuras de datos, esto se debe principalmente a la falta de motivación por

aprender junto con la complejidad de comprender la naturaleza abstracta y dinámica de las

estructuras [7]. Investigaciones realizadas, indican que más del 59% de los estudiantes de in-

formática desertan durante los primeros años, momento en que se instruyen cursos como

programación básica, orientada a objetos y estructuras de datos [8]. Debido a esto, se ha ge-

nerado una necesidad de crear estrategias pedagógicas que reduzcan la complejidad de tales

cursos. Haciendo énfasis en estructuras de datos, urge construir una solución que permita

desarrollar, en estudiantes universitarios de informática, interés y motivación promoviendo

la apropiación del conocimiento.

ii. Formulación del problema

Para formular el problema, primero se debe partir de comprender que la metodología tradi-

cional de enseñanza suele generar una curva de aprendizaje significativa en el estudiante para

aprender estructuras de datos. En palabras de Dongquing Wu esto se debe a que el contenido

de la materia es altamente teórico, en ocasiones llegando a presentar grandes porciones de

código o pseudocódigo que le resultan difíciles de asimilar a los estudiantes, los conceptos


- CIS2021CP02

Page 4

son abstractos y difíciles de visualizar. Adicionalmente, este estudio resalta que los estudian-

tes llegan a esta materia con insuficiencia de habilidades prácticas, en definitiva, todos estos

factores contribuyen a una pérdida de interés y frustración por el curso [9].

Por lo tanto, resulta indispensable encontrar métodos efectivos de aprendizaje de estructuras

de datos, con lo cual se plantea la pregunta ¿Qué estrategias se pueden incorporar para que

los estudiantes se puedan apropiar del conocimiento? Existen múltiples trabajos que intentan

dar respuesta a este interrogante, en particular, estas propuestas evidencian que el desafío

más importante para generar una solución efectiva consiste en mejorar el interés y el com-

promiso por parte de los estudiantes en aprender [5].

En este orden de ideas, el problema que se busca resolver consiste en desarrollar una solución

innovadora que incentive a los estudiantes a tomar un rol proactivo en su proceso de apren-

dizaje. Dicha solución destacaría de otras soluciones por estar orientada al uso de recursos

didácticos, con un enfoque en el aprendizaje visual interactivo para representar adecuada-

mente la naturaleza abstracta y dinámica de las estructuras de datos [10].

A partir de lo mencionado anteriormente, el problema puede ser formulado de la siguiente

forma ¿Cómo generar motivación e interés en el aprendizaje de estructuras de datos, en es-

tudiantes de carreras afines a ingeniería de sistemas, utilizando técnicas interactivas?

iii. Solución propuesta

Con el objetivo de afrontar el problema descrito, se presenta como solución el desarrollo de

una aplicación móvil, con la cual los usuarios pueden aprender de forma interactiva conceptos

teóricos y prácticos sobre estructuras de datos. El desarrollo de esta solución lleva consigo el

uso de tecnologías de realidad aumentada con el objetivo de incentivar técnicas de aprendi-

zaje interactivas y llamativas para los estudiantes. En particular, AEDRA irá acompañada de la

creación de tarjetas físicas, denominadas como marcadores, sobre las cuales se proyectarán

diferentes estructuras de datos, algoritmos o información teórica. Una definición más formal

de un marcador se presenta a continuación:


Page 5

Marcador de Realidad Aumentada: Es una imagen que le proporciona a una aplicación de

realidad aumentada un punto de referencia para posicionar y proyectar contenido tridimen-

sional [11]. En la Ilustración 1 Marcador RA se puede observar un ejemplo de este tipo de

imágenes.

Ilustración 1 Marcador RA

Teniendo en cuenta lo anterior, los marcadores planteados para la solución tienen las siguien-

tes características: por un lado, cuentan con una parte frontal para proyectar contenido diná-

mico, aquí se encuentra un identificador único representado mediante un título descriptivo y

una imagen con un patrón establecido para poder proyectar la estructura correspondiente en

RA. Por otro lado, la parte posterior es empleada para proyectar contenido informativo de

una estructura de datos o un algoritmo.

A continuación, se presenta un ejemplo de la forma en que funciona la aplicación: dado un

marcador que representa una estructura, el aplicativo le permite al usuario, con ayuda de la

cámara, reconocer el identificador único y proyectar el elemento asociado mediante RA. Adi-

cional a ello, se brinda la posibilidad de interactuar con la ejecución de determinados algorit-

mos que se aplican sobre dicha estructura y poder consultar información sobre la misma.

iv. Justificación de la solución

Existen diversas maneras de justificar el uso de realidad aumentada (RA) para enseñar estruc-

turas de datos [12]. Primeramente, se hará énfasis en los beneficios que trae consigo esta


- CIS2021CP02

Page 6

tecnología en el ámbito educativo. En particular, una investigación realizada en la universidad

de Cologne, enuncia los beneficios que obtienen los estudiantes [12]:

• Incremento de la Motivación: hace referencia a que los usuarios están más interesa-

dos en aprender. En un estudio al comparar un grupo de estudiantes que empleaba

métodos sin RA y otro con ellos, se evidenció que en este último las personas toma-

ban un rol mucho más participativo y proactivo durante las sesiones.

• Incremento de la concentración: se afirma que la interacción física propia de la RA

conlleva un mayor grado de concentración por parte del usuario.

• Incremento de la satisfacción en el proceso de aprendizaje: los estudiantes encuen-

tran más entretenido experimentar con una aplicación que tener que realizar tareas

manuales. Una forma de argumentar este hecho es que el nivel de frustración es ma-

yor cuando se debe reproducir un procedimiento manual.

• Mejora la interactividad dado que le da la oportunidad a los estudiantes de manipu-

lar contenido con el fin de entender la solución que se está construyendo.

Un beneficio indirecto del uso de esta nueva tecnología para el aprendizaje consiste en la

mejora de retención de información, esto se debe a que la RA permite generar recuerdos más

vívidos en la persona, esta conclusión fue realizada por el grupo de Klopfer [13] quienes ob-

servaron que los visitantes de una galería de museo eran capaces de recordar más detalles

acerca de las obras presentadas cuando se usaba el formato de realidad aumentada, en com-

paración a aquellos que se les mostraban las obras de forma plana.

Teniendo en cuenta la información expresada anteriormente, el desarrollo de una propuesta

que se enfoque en llevar conceptos abstractos y complejos de entender a un contexto más

tangible y práctico, tendrá un impacto positivo en la comunidad de estudiantes, mejorando

su interés por tomar un rol más proactivo en el proceso de aprendizaje, ayudándolos a con-

solidar conocimientos en estructuras de datos.


Page 7

2. Descripción del proyecto

A continuación, se presentan los objetivos generales y específicos planteados para la solución,

así como los diferentes entregables producto de esta.

i. Objetivo general

Desarrollar una aplicación móvil que emplea tecnologías de realidad aumentada para apoyar

el proceso de aprendizaje de estructuras de datos mediante medios visuales e interactivos,

enfocada a estudiantes de ingeniería de sistemas y carreras afines.

ii. Objetivos específicos.

A continuación, se presentan los objetivos específicos del proyecto:

• Determinar los requerimientos de la aplicación móvil.

• Especificar las estructuras de datos y algoritmos que harán parte del producto.

• Diseñar una herramienta aplicando tecnologías de realidad aumentada para el

aprendizaje de estructuras de datos.

• Implementar un producto mínimo viable (PMV) acorde al diseño.

• Validar la aplicación móvil mediante un grupo de estudiantes universitarios.

iii. Entregables, estándares y justificación

La Tabla 1 Entregables y sus estándares muestra el listado de elementos que fueron realizados

para este trabajo de grado.

Entregable Estándares asociados Justificación

PMP (Project Manage-

ment Plan)

ISO/IEC/IEEE

16326:2019

El estándar provee las especificaciones de un plan de ges-

tión de proyectos de software. Su propósito es definir una

estructura con los elementos más importantes de un plan

de proyecto para alinear al equipo de desarrollo a concluir

satisfactoriamente el sistema [14].

SDD IEEE 1016-2009 El estándar IEEE 1016-2009, provee un modelo, alineado

a buenas prácticas, para la descripción de diseños tanto

de alto, como de bajo nivel. Generando así una estructura


- CIS2021CP02

Page 8

para describir, detalladamente, el diseño de software

[15].

SRS ISO/IEC/IEEE

29148:2018

El estándar tiene como propósito especificar los procesos

necesarios que deben ser implementados en proyectos

de software para definir los requisitos del sistema. Es de

vital importancia dado que especifica el contenido funda-

mental de la documentación de requerimientos, así como

una serie de directrices para implementarlos y los proce-

sos relacionados [16].

Plan de pruebas ISO /IEC 29119 Estándar fundamental para el proceso de pruebas del sis-

tema, su función es especificar definiciones de los térmi-

nos y conceptos de testing. A su vez, comprende un con-

junto de directrices para la realización de un plan de prue-

bas [17].

Diseño del sistema UML Para el apartado de diseño se utiliza el Lenguaje de Mo-

delado Unificado que permite especificar, visualizar, cons-

truir y documentar los distintos componentes del sistema

de software [18].

Diseño de procesos

del sistema

Diagrama de activida-

des

Diagrama UML que describe el flujo de las actividades u

operaciones ejecutadas por un sistema [19].

Reportes de pruebas TDD (Testing Driven

Development)

Para la creación de reportes de pruebas, se utiliza TDD

como un modelo de desarrollo de software. Establece una

metodología donde se la codificación está guiada por las

pruebas. Al ser un proceso iterativo y cíclico, se comple-

menta con otras metodologías ágiles como SCRUM [20].

Reportes de avance

(demos)

SCRUM SCRUM se define como un estándar, metodología o marco

de trabajo para el desarrollo ágil de proyectos de soft-

ware. Se fundamenta en una estrategia de desarrollo in-

cremental y cíclico donde se definen pequeños entrega-

bles para un periodo de tiempo establecido. Este enfoque

ágil permite que sea adaptable a pequeños grupos de tra-

bajo y a un entorno potencialmente cambiante [21].

Tabla 1 Entregables y sus estándares


Page 9

III. CONTEXTO DEL PROYECTO

La presente sección tiene como finalidad describir el contexto sobre el cual se desarrolla

AEDRA, puntualmente, se detallan los antecedentes y se presentan las alternativas a la solu-

ción con su respectivo análisis.

1. Antecedentes

Las estructuras de datos (ED) consisten en una forma de representar, organizar y manejar

grandes volúmenes de datos en un sistema de cómputo. Hoy en día, se encuentran presentes

en sistemas GPS, sistemas de bases de datos, computación gráfica, analítica de datos entre

otros [4]. Debido a su importancia, estos conceptos hacen parte fundamental del proceso de

formación profesional en programas afines a ingeniería de sistemas. Por un lado, las estruc-

turas de datos lineales almacenan la información de forma secuencial y ordenada, las más

representativas de este tipo son: arreglos, pilas, colas y listas. Por otro lado, las ED no lineales

carecen de orden secuencial y se caracterizan por poseer elementos multienlazados, los tipos

más representativos de las estructuras no lineales son: árboles y grafos. Siendo las no lineales

más complicadas de enseñar y aprender en cursos intermedios de programación, debido a su

naturaleza abstracta fundamentada en conceptos matemáticos [22].

Para entender las dificultades que trae consigo el reto del aprendizaje de ED se deben com-

prender las principales formas de enseñanza, las cuales consisten en:

• Metodología tradicional: se caracteriza por la diferencia marcada entre el estudiante

y el profesor, donde se concibe al alumno como un receptor pasivo de la información

mientras que el docente toma un rol de experto que transmite sus conocimientos. La

principal característica de este modelo pedagógico es la memoria, donde la práctica

y la repetición son las principales herramientas de retención de información [23].

• Metodología centrada en el estudiante: es un enfoque en el cual los estudiantes in-

fluyen en el contenido, actividades, materiales y ritmo de trabajo, este modelo ubica


- CIS2021CP02

Page 10

al estudiante en el centro del proceso de aprendizaje, brindando los recursos necesa-

rios para aprender de manera independiente [3].

Teniendo en cuenta lo anterior, un estudio de la universidad Marshall de Huntington comparó

la efectividad de enseñar ED mediante metodologías tradicionales con alternativas enfocadas

al aprendizaje independiente. En particular, destacan el uso de realidad aumentada en la en-

señanza, la cual es una tecnología que permite la proyección de elementos virtuales en un

ambiente real, ofreciendo los siguientes beneficios [6]:

• Una aplicación de realidad aumentada es más interesante para los estudiantes que

otros métodos, dado que están más involucrados en el proceso de aprendizaje.

• La realidad aumentada se puede utilizar eficazmente como ayuda interactiva para ex-

plicar temas complejos y abstractos en el aula.

• Presentar los conceptos de forma visual e interactiva mejora la motivación e interés

de los estudiantes por el tema.

Para generar una solución de realidad aumentada que aproveche los beneficios anterior-

mente descritos, es importante comprender las principales técnicas de enseñanza mediante

RA, las cuales son [12]:

• Aprendizaje basado en el descubrimiento: es una técnica en la cual se simulan lugares

del mundo real para permitir a las personas explorar y aprender de ellos.

• Modelado de objetos: consiste en la representación de objetos tridimensionales que

facilitan el aprendizaje mediante la interactividad.

• Material impreso RA: son recursos de RA que van acompañados de material textual

educativo.

• Entrenamiento de habilidades: consiste en la simulación de situaciones reales con el

objetivo de entrenar habilidades específicas de las personas.

• AR Gaming: Son plataformas altamente interactivas que utilizan la gamificación como

recurso de aprendizaje.


Page 11

Teniendo en cuenta los conceptos descritos anteriormente, se observa que las estrategias de

modelado de objetos, material impreso RA y AR gaming son técnicas potenciales que se pue-

den aplicar en la enseñanza de estructuras de datos, dados los beneficios que conllevan.

2. Análisis del contexto

El presente apartado tiene como finalidad detallar las alternativas de la solución propuesta y

realizar su respectivo análisis comparativo.

i. Alternativas de solución

A continuación, se presentan las alternativas y soluciones más relevantes con relación al pre-

sente trabajo de grado, que bien abordan el aprendizaje de estructuras de datos o la ense-

ñanza interactiva.

• ARCSE: Proyecto de software que ofrece un entorno de práctica y aprendizaje para

estudiantes basado en Realidad Aumentada para la enseñanza de estructuras de da-

tos lineales (listas enlazadas, arreglos y pilas) [6]. La finalidad del proyecto, además

de desarrollar una aplicación móvil no pública, consiste en comparar la efectividad de

la enseñanza por medio de la realidad aumentada, contrastada con herramientas de

aprendizaje de estructuras de datos mediante la visualización de animaciones en 2D

(Ej.: VisuAlgo) y enseñanza tradicional a través de libros o representaciones estáticas

[6].

A grandes rasgos, consiste en un sistema que, dado un marcador, proyecta estructu-

ras de datos lineales en realidad aumentada. Sobre estas proyecciones, el usuario

puede interactuar añadiendo o eliminando elementos, estas acciones se ven refleja-

das en la pantalla del dispositivo mediante animaciones. Adicional a ello, el usuario

cuenta con la experiencia tridimensional que ofrece la tecnología de realidad aumen-

tada [6]. En contraste con la solución AEDRA, ARCSE carece de marcadores de infor-

mación y no abarca estructuras de datos no lineales como árboles y grafos.


- CIS2021CP02

Page 12

• AR-MAZE: Herramienta que utiliza realidad aumentada para enseñar lógica de pro-

gramación a niños. Se divide en tres componentes principales, una aplicación móvil

que provee el material visual y textual para la retroalimentación de los escenarios

virtuales, un sistema de seguimiento del mapa que se proyecta en RA y tres tipos de

bloques de programación que combinan la parte física y lógica de la aplicación. Su

funcionamiento consiste en una serie de mapas prediseñados que contienen una ruta

que se debe seguir de inicio a fin. Los usuarios deben acomodar los diferentes bloques

de tal forma que todas las instrucciones al ejecutarse completen el mapa [24].

Su objetivo es reforzar el conocimiento de niños en relación con las habilidades

computacionales, dejando de lado los lenguajes de programación textuales que ne-

cesitan contexto para comprenderse. En contraste con AEDRA, se enfoca en la ense-

ñanza de lógica de programación y no de estructuras de datos.

• VISUALGO: Es una herramienta de aprendizaje basada en la web que tiene como ob-

jetivo mejorar la enseñanza de estructuras de datos y algoritmos a través de visuali-

zaciones interactivas dinámicas. Ofrece 25 módulos de aplicación donde se pueden

observar animaciones en 2D de diferentes algoritmos sobre estructuras de datos

tanto lineales como no lineales [25]. El valor agregado de esta alternativa consiste en

que a la par de la ejecución de animaciones, permite observar el pseudo código del

algoritmo de forma paralela. Aunque fue diseñada para estudiantes de la Universidad

Nacional de Singapur, se convirtió en una herramienta conocida en otros países, ac-

tualmente se encuentra pública y se puede acceder a través de su página web [25].

A pesar de sus múltiples características, a diferencia de AEDRA, su interfaz se limita a

representaciones 2D animadas y no ofrece una experiencia más interactiva para los

usuarios.

• OpenDSA: Open Source Interactive Computer Science Instruction o OpenDSA es una

infraestructura y herramienta tanto web como standalone que aporta material para

el apoyo de cursos de estructuras de datos, algoritmos, lenguajes formales, autóma-

tas finitos y lenguajes de programación. Posee una interfaz 2D sobre la cual el usuario

encuentra ejercicios y ejemplos aplicados a cada uno de los temas con los cuales los


Page 13

estudiantes deben interactuar e incluso realizar pequeñas líneas de código para dar

solución a los problemas. Su funcionamiento consiste en una parte teórica y práctica

en donde se explican los conceptos asociados al tema, seguidamente se presenta un

problema a resolver [26]. A pesar de que se considera una herramienta más robusta

que Visualgo dado que ofrece más información y funcionalidades, su interfaz es téc-

nica y menos amigable con el usuario. Si bien cuenta con visualizaciones 2D, no ofrece

experiencias interactivas como es el uso de realidad aumentada.

• OGMENTED: Aplicación móvil que utiliza RA para la enseñanza de programación abs-

tracta, enfocándose en programación orientada a objetos. Contiene dos componen-

tes principales: tutoriales en los que el usuario aprende los conceptos y ejercicios a

través de objetos proyectados en RA. Se enfoca en la enseñanza de manejo de obje-

tos, sobrecarga e invocación de métodos. Su funcionamiento se basa en mostrarle al

usuario animaciones sobre un objeto cuando se invoca un método de este, así como

permitirle escribir el código para la invocación [27].

El objetivo principal es enseñar la lógica detrás de POO para que los estudiantes se

familiaricen con los conceptos generales y no abordar un problema específico. A pe-

sar de utilizar realidad aumentada, Ogmented no está enfocada en la enseñanza de

conceptos de estructuras de datos.

ii. Comparación de alternativas

Una vez descritas las características de las distintas alternativas identificadas, a continuación,

la Tabla 2 Criterios de comparación de las alternativas presenta un cuadro comparativo de los

criterios más importantes para la solución propuesta.

ARCSE VisuAlgo AR-Maze Ogmented OpenDSA Nuestra propuesta

Enseña concep-tos básicos de

ED

Soporta Soporta No soporta No soporta Soporta Soporta

Enseña concep-

tos sobre ED no

lineales

No soporta Soporta No soporta No soporta Soporta Soporta


- CIS2021CP02

Page 14

Representa vi-sualmente la

ejecución de al-goritmos

Soporta Soporta Soporta No soporta Soporta Soporta

Permite el con-trol de las ani-

maciones

No soporta Soporta No soporta No soporta Soporta Soporta

Emplea realidad aumentada

Soporta No soporta Soporta Soporta No soporta Soporta

Es una aplica-

ción para dispo-

sitivos móviles


Presenta la in-formación en un

espacio tridi-mensional


El usuario puede utilizar elemen-tos físicos para interactuar con

el aplicativo


Los elementos físicos pueden interactuar en-

tre ellos

No soporta No soporta Soporta No soporta No soporta Soporta

Tabla 2 Criterios de comparación de las alternativas

Como se puede observar en la tabla anterior, existen alternativas que, a primera vista, pre-

tenden dar solución al mismo problema planteado en el presente documento, sin embargo,

difieren en cuanto a metodología o enfoque se refiere. AEDRA, por su parte, posee las siguien-

tes características que le dan un valor agregado a la solución:

• Enfoque en estructuras de datos

• Uso de realidad aumentada

• Animaciones explicativas de algoritmos

• Interacción de elementos físicos con la aplicación

AEDRA destaca de las alternativas planteadas anteriormente gracias a que hace uso de reali-

dad aumentada y animaciones para proyectar estructuras de datos y algoritmos. Estos ele-

mentos agregan valor a la solución ya que apoyan el proceso de aprendizaje de temas com-

plejos utilizando tecnologías altamente interactivas. Las características mencionadas ante-

riormente favorecen la motivación de los usuarios por utilizar la solución.


Page 15

IV. ANÁLISIS DEL PROBLEMA

La presente sección tiene como finalidad describir los requerimientos, las restricciones y la

especificación funcional de la solución. Cabe recalcar que solo se presenta la información más

relevante para el propósito del documento, el análisis detallado puede ser encontrado en el

anexo Especificación de requerimientos de software (SRS).

1. Requerimientos

AEDRA es una aplicación móvil cuyo objetivo es incentivar el interés en el aprendizaje de es-

tructuras de datos mediante el uso de realidad aumentada, facilitando el entendimiento de

conceptos abstractos y promoviendo la apropiación del conocimiento. Para desarrollar la so-

lución, se realizó el proceso de levantamiento de requerimientos siguiendo principios ágiles.

Con lo cual, en primera instancia, se identificó un conjunto de requerimientos generales que,

por la naturaleza incremental e iterativa de las metodologías, fueron refinados y especificados

para determinadas estructuras de datos. En este orden de ideas, se presentan los requeri-

mientos funcionales y no funcionales de AEDRA.

i. Requerimientos funcionales

Con el fin de especificar las funcionalidades de la solución descrita en la sección Solución pro-

puesta, se definieron 12 requerimientos generales del sistema priorizados en una escala de 1

a 5, esto con el fin de anteponer el desarrollo de las funcionalidades críticas. A continuación,

en la Tabla 3 Requerimientos funcionales de la solución se presentan los más relevantes junto

con su respectiva priorización. La especificación y el detalle de todos los requerimientos se

encuentra en el anexo Documentación de requerimientos.


- CIS2021CP02

Page 16

ID Requerimiento funcional Prioridad

RF6 El sistema debe permitir al usuario ver la proyección de una estructura de datos en

realidad aumentada 5

RF7 El sistema debe permitir al usuario añadir un nuevo elemento a la estructura de da-

tos proyectada. 4,9

R12 El sistema debe permitir al usuario buscar datos en la estructura de datos proyec-

tada. 4,8

RF1 El sistema debe permitir la detección de marcadores de realidad aumentada. 4,5

RF8 El sistema debe permitir al usuario eliminar elementos de la estructura de datos pro-

yectada. 4,5

RF9 El sistema debe permitir al usuario realizar algoritmos de recorrido sobre la estruc-

tura de datos proyectada. 4,5

R10 El sistema debe permitir al usuario modificar los datos de la estructura de datos pro-

yectada 4,5

RF3 El sistema debe permitir al usuario visualizar la información de los marcadores exis-

tentes.

4,0

RF11 El sistema debe permitir al usuario reproducir paso a paso la ejecución de un algo-

ritmo sobre la estructura de datos proyectada. 3,8

RF5 El sistema debe permitir al usuario limpiar la estructura de datos proyectada elimi-

nando todos los elementos existentes. 3,6

RF2 El sistema debe ofrecer al usuario la posibilidad de descargar marcadores en formato

png. 3,5

RF4 El sistema debe ofrecer tutoriales en formato de video para que los usuarios entien-

dan cómo utilizar la aplicación. 3

Tabla 3 Requerimientos funcionales de la solución

ii. Requerimientos no funcionales

En segundo lugar, se definen los requerimientos no funcionales (RNF) de la solución. Los cua-

les fueron clasificados según los atributos de calidad definidos en el ISO 25010 [28] (compati-

bilidad, fiabilidad, usabilidad, desempeño, mantenibilidad, portabilidad y seguridad). Te-

niendo las características de la solución, se priorizan los siguientes atributos de calidad para

el levantamiento de requerimientos no funcionales:

1. Usabilidad: como se menciona en la Justificación de la solución, se debe desarrollar

una aplicación altamente interactiva y con una baja curva de aprendizaje para incen-

tivar el interés de los estudiantes por aprender. Adicionalmente, la tecnología de

realidad aumentada implica el uso de la cámara del dispositivo de forma constante,

por lo tanto, la interfaz gráfica debe ser sencilla, poco obstructiva y disponer de un


Page 17

buen contraste de colores para mejorar la experiencia del usuario. Por estas dos ra-

zones, la usabilidad es el atributo de calidad de mayor importancia en los RNF.

2. Mantenibilidad: teniendo en cuenta que el tema central de la problemática son las

estructuras de datos y sus algoritmos, es crucial desarrollar una solución extensible a

largo plazo. En este orden de ideas, el diseño debe permitir que se puedan adicionar

fácilmente nuevas funcionalidades, lo cual implica que la arquitectura sea modular y

aplique principios de diseño que permitan la extensibilidad y mantenibilidad.

3. Desempeño: dado que la solución está orientada a dispositivos móviles que poseen

especificaciones limitadas (RAM, CPU, GPU, etc.), es importante monitorear el rendi-

miento de la misma. El consumo excesivo de recursos por parte de un sistema, ralen-

tiza los dispositivos lo que arruina la experiencia de los usuarios a la par que puede

afectar negativamente los componentes de hardware. Teniendo en cuenta que el

apartado visual de la aplicación es uno de los más importantes para AEDRA, se deben

limitar los recursos utilizados de tal forma que no se vea comprometida la fluidez del

componente gráfico y tampoco el hardware del dispositivo.

Teniendo en cuenta el modelo ISO 25010 y los atributos de calidad priorizados, se establece

un total de 22 requerimientos no funcionales, en el anexo Documentación de requerimientos

se encuentran los detalles y la descripción de cada uno de ellos. A continuación, se presenta

la Tabla 4 Requerimientos no funcionales de la solución con el fin de resaltar los más impor-

tantes para el propósito del documento.

ID Requerimientos no funcionales

Usabilidad

RNF3 Las interfaces del sistema deben ser intuitivas para que el usuario pueda navegar por ellas fácil-

mente.

RNF9 La interfaz de la aplicación debe ser adaptable a distintos tamaños de pantallas.

RNF2 El sistema debe contar con herramientas de apoyo y manuales de instalación.

RNF11 El sistema debe proveer notificaciones y mensajes de error que sean comprensibles e informati-

vos para el usuario.

RNF6 Las interfaces del sistema deben tener colores que contrasten con cualquier imagen mostrada

por la cámara.


- CIS2021CP02

Page 18

Mantenibilidad

RNF13 El sistema debe permitir añadir nuevas operaciones sin afectar las funcionalidades existentes.

RNF14 El sistema debe permitir adaptar elementos existentes para adicionar o incorporar nuevas estruc-

turas de datos y algoritmos.

Desempeño

RNF16 La ejecución del sistema mantendrá un promedio de 30 cuadros por segundo.

RNF4 El sistema debe limitar la cantidad de elementos de realidad aumentada que se pueden proyectar

en la pantalla.

Tabla 4 Requerimientos no funcionales de la solución

2. Restricciones

A continuación, se presentan las restricciones establecidas para el desarrollo de la solución

AEDRA.

i. Restricciones de Software.

A continuación, se presentan las restricciones establecidas para el desarrollado del sistema:

• AEDRA será compatible con dispositivos móviles con sistema operativo Android, para

una versión mínima de Android 6.0 Marshmallow. Esto con el fin de garantizar ciertos

requerimientos de software de los dispositivos.

• AEDRA será una solución de código abierto, por lo tanto, se utilizarán librerías de có-

digo abierto para mantener consistencia con la licencia GPLv2.

• AEDRA será compatible con dispositivos móviles con API de gráficos OpenGL v2 o su-

perior para permitir la producción de gráficos 2D o 3D.

ii. Restricciones de Hardware.

Teniendo en cuenta las tecnologías empleadas para el desarrollo de la solución se establecie-

ron un conjunto de restricciones mínimas de hardware para garantizar el correcto funciona-

miento en los dispositivos:


Page 19

• El dispositivo móvil deberá tener una resolución de pantalla HD (1280x720 píxeles) o

superior. Esto no restringe a que se utilicen dimensiones inferiores, sin embargo, re-

duce la calidad y puede provocar efectos visuales no deseados en las interfaces.

• Teniendo en cuenta que la detección de marcadores de realidad aumentada requiere

el uso de la cámara, el dispositivo móvil deberá tener cámara digital trasera de por lo

menos 5 MP para garantizar un nivel mínimo de calidad de imagen.

• El dispositivo móvil deberá tener mínimo 1 GB de memoria RAM para garantizar el

funcionamiento de la aplicación en presencia de posibles picos de consumo de la me-

moria.

• El dispositivo móvil deberá tener mínimo 70 MB de memoria interna disponible para

poder almacenar la aplicación y la posible información que esta genere.

3. Especificación funcional

La especificación funcional de la solución presenta, de forma resumida, la navegabilidad del

sistema, la descripción general de los casos de uso y el flujo del proceso más importante de

AEDRA.

i. Mockups

En primera instancia, la Ilustración 2 Pantallas principales del sistema presenta las opciones

con las cuales interactúa el usuario. Inicialmente, se muestra la pantalla principal, la cual es el

punto de acceso a las demás funcionalidades de la aplicación. A partir de aquí, el usuario

puede consultar y descargar los marcadores, acceder a los tutoriales e ir a la pantalla de “De-

tección de marcador RA”. Esta última, es la más importante debido a que hace uso de la cá-

mara del dispositivo móvil para detectar los marcadores sobre los cuales se proyectan las

estructuras de datos en realidad aumentada.


- CIS2021CP02

Page 20

Ilustración 2 Pantallas principales del sistema

Es importante destacar que la pantalla “Detección marcador RA” es una interfaz dinámica, lo

que quiere decir que el contenido que se le presenta al usuario va a depender principalmente

del tipo de marcador que este siendo enfocado. En este orden de ideas, se definieron tres

tipos principales de marcadores, los cuales se evidencian en la Ilustración 3 Tipos de marca-

dores.

Ilustración 3 Tipos de marcadores

- Marcadores de ED: corresponden con marcadores que representan tipos de estruc-

turas de datos, por ejemplo: vectores, árboles binarios, montículos, grafos, etc. El

principal objetivo es mostrar la forma en que se construye la estructura correspon-

diente, por lo tanto, el usuario tendrá acceso a las operaciones del CRUD.

- Marcadores de algoritmos: son marcadores que permiten observar la ejecución de

un algoritmo aplicado sobre una estructura de datos. Se diferencian del tipo anterior


Page 21

ya que no se usan para construir una estructura, sino para observar la ejecución paso

a paso de un algoritmo. Algunos ejemplos comunes son: búsqueda binaria, algoritmo

Dijkstra, ordenamiento, etc.

- Marcadores de información: por último, los marcadores de información proyectan

datos estáticos en realidad aumentada, es decir, que no se centran en interactuar con

el usuario, sino en presentar información relevante para comprender las estructuras

proyectadas.

Todas las funcionalidades de la aplicación se establecieron alrededor de estos 3 tipos de mar-

cadores fundamentales. Finalmente, en la Ilustración 4 Diagrama de navegación se puede

evidenciar la interacción entre las pantallas mencionadas anteriormente. De igual forma, se

puede observar que, desde la pantalla “Detección de marcador RA”, el usuario puede proyec-

tar los diferentes tipos de marcadores y se le presentará la interfaz correspondiente.

Ilustración 4 Diagrama de navegación


- CIS2021CP02

Page 22

ii. Diagrama de casos de uso.

A partir de los mockups y el diagrama de navegación mostrado en la sección anterior, se de-

finen los flujos de los casos de uso o CU, los cuales se detallan en el anexo Documentación de

casos de uso, sin embargo, en esta subsección se presentan los más relevantes. Teniendo en

cuenta lo anterior, se destaca Proyectar ED, el cual consiste en la detección de un marcador

para proyectar una estructura y mostrarle al usuario las operaciones que puede realizar sobre

la misma. Consecuentemente, este CU es el punto de entrada a las principales funcionalidades

del sistema como se evidencia en la Ilustración 5 Diagrama de casos de uso.

Ilustración 5 Diagrama de casos de uso

El sistema permite al usuario personalizar las estructuras de datos proyectadas a través de los

CU añadir, eliminar o modificar elemento. Como resultado de dichas operaciones, el sistema


Page 23

persiste los cambios a través del CU Guardar estado. Finalmente, se ofrece un CU enfocado al

componente de enseñanza y aprendizaje, el cual es reproducir animación. El CU anterior,

muestra al usuario una representación visual usando animaciones para las operaciones y al-

goritmos que realiza en las estructuras como, por ejemplo, cuando se busca un elemento o

se hace un recorrido.

iii. Diagrama de actividades

En el diagrama de actividades Ilustración 6 Proceso de detección de marcador, se desglosa el

flujo del CU de proyección en Realidad Aumentada.

Ilustración 6 Proceso de detección de marcador

El flujo comienza cuando el usuario enfoca un marcador con la cámara, para lo cual se pre-

sentan 3 casos. En el primero de ellos, se detecta un marcador de tipo estructura de datos,

aquí se proyecta un objeto en realidad aumentada sobre el cual el usuario puede realizar

operaciones de modificación de los datos y visualizar los algoritmos básicos de recorrido pro-

pios de la ED.

En el segundo caso se detecta un marcador de tipo algoritmo, en el cual es posible visualizar

dos escenarios. Por un lado, si el usuario solamente enfoca el marcador de algoritmo, se mos-

trará en pantalla una estructura predefinida por el sistema sobre la que se aplicará el algo-

ritmo, sin embargo, dicha proyección no podrá ser manipulada por el usuario. Por otro lado,

el usuario tiene la posibilidad de detectar un marcador de tipo algoritmo y de tipo estructura


- CIS2021CP02

Page 24

al mismo tiempo, por ejemplo: marcador de grafo + marcador de Dijkstra. De esta forma, y

como se observa en el flujo, la aplicación podrá reconocer que existe una estructura de datos

creada por el usuario, y procederá a ejecutar el algoritmo especificado sobre dicha estructura.

Finalmente, se puede detectar un marcador de tipo informativo, el cual cargará la información

y contenido multimedia predefinidos. En cualquiera de los tres escenarios mencionados an-

teriormente, una vez que el usuario retira el enfoque de la cámara sobre el marcador, el apli-

cativo procederá a ocultar los objetos proyectados y, adicionalmente, guardará el estado de

las operaciones realizadas por el usuario para retomar la ejecución en el último punto guar-

dado.


Page 25

V. DISEÑO DE LA SOLUCIÓN

En este capítulo se especifica el diseño arquitectural acorde a los requerimientos establecidos

en ANÁLISIS DEL PROBLEMA. Para ello, se tuvieron presentes múltiples factores que afectan

la toma de decisiones, de los cuales se destaca la extensibilidad por su alto impacto en la

arquitectura. Con base en lo anterior, se requiere que la solución permita incorporar nuevos

componentes relacionados con estructuras de datos y algoritmos. En este orden de ideas, en

las siguientes subsecciones se describe la selección de herramientas y librerías para la solu-

ción, así como la arquitectura y el diseño detallado.

1. Herramientas de desarrollo

En esta sección se detallan los criterios utilizados para la selección de la plataforma de desa-

rrollo y las librerías usadas.

i. Plataforma de desarrollo:

Para la selección de la plataforma en la cual se desarrolló el aplicativo, se priorizaron aquellas

que incorporasen un motor gráfico para el manejo de elementos 3D. Existen diferentes en-

tornos que cumplen con estas características, sin embargo, en la Tabla 5 Comparación de

plataformas de desarrollo se presentan las más usadas para aplicaciones de RA, junto con sus

respectivos criterios de evaluación.

Característica/Alternativas Unity Unreal Engine

Documentación Amplia Amplia

Es de uso libre Si Si

Fácil integración con la tecnología

RA Si

Si

Curva de aprendizaje baja Si No

Tabla 5 Comparación de plataformas de desarrollo

El criterio más importante de los mencionados, es la curva de aprendizaje por parte del desa-

rrollador para usar la herramienta. Unity tiende a ser más sencillo en comparación con Unreal


- CIS2021CP02

Page 26

Engine, esto se debe a su amplia documentación, el soporte de la comunidad y el fácil manejo

de objetos 3D [29], por lo cual se seleccionó Unity para el desarrollo de la solución.

ii. Tecnología de realidad aumentada

Para el desarrollo de la solución, se vio la necesidad de contar con una herramienta que sea

capaz de reconocer y rastrear imágenes en tiempo real para la proyección de objetos 3D en reali-

dad aumentada. Los principales criterios que se tuvieron en cuenta para la elección de la tec-

nología se presentan en la Tabla 6 Comparación de tecnologías para realidad aumentada.

Característica / Al-

ternativas Vuforia Spark Ar.js ArFoundation

Se ejecuta de

forma nativa en el

dispositivo

Si No No Si

Libre uso Si No No Si

Acceso directo al

hardware del dis-

positivo

Si No No Si

Facilidad de uso Alta Alta Media

Media

Tabla 6 Comparación de tecnologías para realidad aumentada

Con base en la tabla anterior y teniendo en cuenta que la aplicación es standalone, se descar-

tan opciones como Spark y Ar.js dado que ofrecen realidad aumentada a través de la web. Lo

anterior implica que el usuario debería contar con una conexión permanente a internet, lo

que conlleva a que la solución dependa de servicios de terceros, como servidores web y se

dificulte el acceso al hardware del dispositivo [30].

Por otro lado, aunque AR foundation y Vuforia son herramientas similares, esta última ofrece

un sistema para evaluar marcadores de realidad aumentada (en una escala de 1 a 5) según su

facilidad de detección. Dado que, una de las características fundamentales de AEDRA es el

uso de marcadores, esta funcionalidad de Vuforia es de gran utilidad para el desarrollo de la

solución. Otro punto a favor es la facilidad para integrarse con Unity y su amplia documenta-

ción. De esta forma, se opta por utilizar Vuforia como tecnología de realidad aumentada.


Page 27

iii. Distribución de la solución

AEDRA contempla los requerimientos que exige Google para subir aplicaciones a su plata-

forma Play Store para Android, los cuales son [31]:

• Tamaño de descarga de la aplicación comprimida en formato APK inferior a 100 MB.

• Versión de la app inferior a 2100000000.

• Configuración de firmas digitales.

• Especificación del nivel de API mínimo y recomendado soportado por la aplicación.

2. Arquitectura

Teniendo en cuenta los requerimientos establecidos en el ANÁLISIS DEL PROBLEMA y las he-

rramientas seleccionadas, se establece el modelo 4+1 para para definir la arquitectura del

sistema y sus respectivas vistas arquitecturales que describen a AEDRA [32]. En las subseccio-

nes posteriores, se detalla la vista de desarrollo y la vista física, por su parte, la vista lógica se

encuentra en la sección Diseño detallado de la solución y, finalmente, los escenarios se des-

criben en el Diagrama de casos de uso. La vista de procesos no se considera relevante para el

diseño de AEDRA y, por consiguiente, no se detalla en el presente documento.

i. Patrón arquitectural

El punto de partida para diseñar la arquitectura fue definir un patrón arquitectural coherente

con los requerimientos. En primer lugar, se tuvo como factor principal la interactividad con el

usuario por lo cual se tuvieron en cuenta estilos como MVC, MVVM, PAC, etc. En segundo

lugar, dado que se definió que la solución era tipo standalone se descartaron estilos que no

son recomendados para este tipo de sistemas, como cliente-servidor y microservicios. Final-

mente, se requería una solución mantenible que ofrezca extensibilidad e independencia entre

sus componentes. Teniendo en cuenta lo anterior, se optó por una arquitectura MVC dado


- CIS2021CP02

Page 28

que cumplía todos los criterios anteriormente descritos y es ampliamente utilizada para el

desarrollo de soluciones interactivas [33].

ii. Vista de desarrollo

La Ilustración 7 Diagrama de vista de desarrollo, presenta la forma en que se aplicó el patrón

MVC anteriormente mencionado, sin embargo, fue extendido para incorporar otros elemen-

tos como el patrón observer; que permite mantener la comunicación desacoplada entre vista

y modelo, el sidecar; para el traspaso de información dentro del sistema, el repositorio; para

la persistencia de datos, y Vuforia; para la detección de marcadores de realidad aumentada.

El detalle de cada uno de los paquetes se describe en subsecciones posteriores.

Ilustración 7 Diagrama de vista de desarrollo

A partir de lo anterior, se detallan las principales decisiones de diseño que permiten la exten-

sibilidad del sistema. En este orden de ideas, las siguientes subsecciones describen la vista de

implementación de cada uno de los paquetes en los cuales se evidencian los patrones de di-

seño más relevantes.


Page 29

View

La responsabilidad de la vista consiste en renderizar los objetos 3D y presentar las pantallas

al usuario. Para cumplir este objetivo y dado que uno de los requerimientos no funcionales

más importantes es la extensibilidad para facilitar la incorporación de nuevas formas de re-

presentar visualmente las estructuras, se tomaron dos decisiones de diseño fundamentales

evidenciadas en la Ilustración 8 Paquete de vista. La primera, fue aplicar el principio de abs-

tracción de la programación orientada objetos, con lo cual mediante una herencia se agrupan

los elementos visuales de tal forma que se ofrece un conjunto de objetos gráficos para repre-

sentar diferentes tipos de estructuras. Por ejemplo, a partir de nodos y aristas se pueden re-

presentar tanto árboles como grafos. La segunda, emplea un patrón estrategia para animar

diferentes algoritmos sobre las estructuras proyectadas.

Ilustración 8 Paquete de vista

Controller

La responsabilidad del controlador consiste en capturar las interacciones del usuario y delegar

las correspondientes acciones al modelo. Con el fin de permitir esta comunicación y seguir los

lineamientos de los requerimientos no funcionales de mantenibilidad, se emplea el patrón


- CIS2021CP02

Page 30

comando, el cual facilita la adición de nuevas operaciones sin impactar las funcionalidades ya

existentes. Lo anterior es posible gracias a la herencia de comandos que ofrece un único punto

de acceso para delegar las peticiones del usuario. La adaptación de este patrón a la solución

se evidencia en la Ilustración 9 Paquete de controlador.

Ilustración 9 Paquete de controlador

Model & Repository

La responsabilidad del modelo consiste en realizar la lógica de negocio del sistema. Con el

propósito de desarrollar esta lógica y cumplir con los requerimientos no funcionales de man-

tenibilidad, se da prioridad a las sub-características de modificabilidad y reusabilidad del sis-

tema, por lo cual se tomaron las siguientes decisiones de diseño:

1. Utilizar el patrón factory method para facilitar la creación dinámica de estructuras

necesaria en el caso de uso “Proyectar ED”.

2. Emplear el patrón estrategia para facilitar la implementación de nuevos algoritmos a

futuro.


Page 31

3. Definir el paquete Repository que contiene la lógica de integración para guardar y

cargar las modificaciones realizadas sobre las estructuras, esto con el fin de imple-

mentar el caso de uso “Guardar estado”.

Todo lo anteriormente descrito se evidencia en la Ilustración 10 Paquete de modelo.

Ilustración 10 Paquete de modelo

Observer y sidecar:

Finalmente, dado que se tiene una arquitectura MVC, se optó por utilizar el patrón observer

para capturar las notificaciones provenientes del modelo y enviarlas a la vista con el fin de

actualizarla. El patrón descrito anteriormente es muy recomendado en sistemas interactivos,

como AEDRA, debido a que emplea comunicación asíncrona y contribuye al desacoplamiento

entre paquetes. Por otro lado, para la transferencia de información en el sistema se emplean

DTOs (data transfer objects) que permiten el encapsulamiento de datos. Las principales ven-

tajas de emplear DTOs son la mantenibilidad y modificabilidad, debido a que simplifican el

paso de parámetros y permiten agregar nuevos atributos sin generar impacto en las funcio-

nalidades existentes. Lo anteriormente descrito se puede evidenciar en la Ilustración 11 Pa-

quetes observer y sidecar.


- CIS2021CP02

Page 32

Ilustración 11 Paquetes observer y sidecar

iii. Vista física

En esta sección se detallan los componentes físicos y requerimientos de hardware para el

correcto funcionamiento del sistema a través de un diagrama de despliegue. En la Ilustración

12 Diagrama de vista física se observa la arquitectura del sistema.

Ilustración 12 Diagrama de vista física


Page 33

A partir del anterior diagrama se describen los nodos que conforman el sistema AEDRA.

Nodo Android Mobile Device

Corresponde al dispositivo móvil sobre el cual se instala AEDRA. Sus principales componentes

son:

• Vuforia API: tecnología usada para la detección de marcadores de Realidad Aumen-

tada.

• Unity AR App: corresponde al aplicativo implementado en Unity que provee todas las

funcionalidades de AEDRA, en este componente se pueden observar todos los ele-

mentos descritos previamente en la Ilustración 7 Diagrama de vista de desarrollo.

• File System: representa el almacenamiento local del dispositivo, en donde se almace-

nan los datos de las proyecciones, la configuración de la aplicación y la información

de los marcadores.

La comunicación entre componentes más importante ocurre entre Vuforia API y Unity AR App.

A partir de la detección de un marcador por parte de Vuforia, el componente Unity muestra

la proyección correspondiente.

Nodo Google Services

AEDRA utiliza los servicios de Google para almacenar videos informativos como tutoriales

que, dado su tamaño, es mejor no guardarlos en la aplicación. Sus principales componentes

son:

• Firebase Console: proporciona los servicios de comunicación para acceder a la base

de datos de Firebase.

• Firebase Storage: es la base de datos de Firebase usada para almacenar contenido

multimedia. De esta manera la aplicación pide el contenido conforme se necesita, lo

cual permite alivianar el espacio ocupado de la aplicación en el almacenamiento del

dispositivo.


- CIS2021CP02

Page 34

3. Diseño detallado de la solución

Una vez presentado el diseño general, se especifica la solución para cumplir el objetivo de

crear un producto mínimo viable o PMV y validar su factibilidad. Teniendo en cuenta lo ante-

rior, fue necesario acotar las ED y los algoritmos que hacen parte de la solución. En este orden

de ideas, se tomó como punto de partida el currículo dictado por cursos de estructuras de

datos para determinar el alcance del PMV en los siguientes aspectos:

• Tipo de estructura: el PMV se centró en las estructuras no lineales (grafos y árboles)

dada su complejidad y relevancia en la materia.

• Operaciones: se priorizaron las operaciones fundamentales (creación, eliminación y

modificación) y búsqueda de elementos.

• Algoritmos: se priorizaron los algoritmos de recorridos y Dijkstra en el caso del grafo.

Una vez definidos los elementos que comprende el PMV, se tomaron los requerimientos ge-

nerales de la sección Requerimientos funcionales y se especificaron para cada una de las es-

tructuras seleccionadas. El diseño de la solución se desarrolló para que los factores principales

del producto: extensibilidad y modificabilidad, se mantuviesen presentes. En las siguientes

subsecciones se detallan las consideraciones del PMV.

i. Clases

En la Ilustración 13 Diagrama de clases del paquete modelo se presenta la especificación del

modelo aplicado al PMV. En particular, se detallan los elementos descritos en la subsección

Model & Repository, acotados a las estructuras de árbol y grafo. Cabe destacar que el detalle

de todas las clases se encuentra en el anexo Especificación de diseño del software (SDD).


Page 35

Ilustración 13 Diagrama de clases del paquete modelo

El diseño se basó en las definiciones formales de las estructuras de datos, es decir, los atribu-

tos y métodos se derivaron de la forma estándar de implementación. Por un lado, como se

observa en el paquete Data Structure Graph un grafo se representa como un listado de nodos

y se adopta la lista de adyacencia para representar las relaciones entre ellos. Por otro lado,

en el paquete Data Structure Tree el árbol es una estructura jerárquica donde cada nodo tiene

asociado un valor y se relaciona con un listado de nodos hijos. Para las características ya men-

cionadas, se agregan una serie de interfaces siguiendo el diseño genérico descrito en la sub-

sección Model & Repository, estas permiten aplicar distintos patrones de diseño como factory

method y strategy para garantizar la extensibilidad de las estructuras de datos y los algorit-

mos. Adicionalmente, toda estructura de datos debe estar asociada a un marcador de realidad

aumentada, el cual es el elemento de mayor importancia para la solución, debido a que al ser

reconocido por la cámara proyecta la estructura correspondiente.


- CIS2021CP02

Page 36

ii. Persistencia

En cuanto a la persistencia de datos, dado que el usuario puede personalizar las estructuras

a través de las operaciones de añadir, eliminar y modificar, se guardan localmente en formato

JSON los resultados de estas. El proceso anterior ocurre al finalizar una operación y cada vez

que los objetos proyectados cambian de posición en el espacio. En este orden de ideas, cada

una de las estructuras tiene un archivo JSON asociado, el cual contiene la información de los

elementos de la ED y a su vez la posición de los objetos en el espacio. Cada vez que se proyecte

una estructura, el sistema cargara el archivo asociado con los cambios del usuario y a su vez

se representarán en la vista.


Page 37

VI. DESARROLLO DE LA SOLUCIÓN

Los requerimientos funcionales y no funcionales especificados y el diseño de alto y bajo nivel

planteado en las secciones previas, fueron el punto de partida para el desarrollo de la solu-

ción. Teniendo en cuenta lo anterior, en esta sección se detallan el proceso de desarrollo de

AEDRA, las fases de pruebas realizadas, así como el producto final entregado a los usuarios.

1. Fase pre-implementación

En la etapa pre-implementación se realizó una prueba de concepto o PoC cuyo objetivo fue

implementar alternativas de interfaces y de funcionalidades para determinar su factibili-

dad. Con este fin, se realizaron pruebas de usabilidad, también conocidas como pruebas

de experiencia de usuario (UX), las cuales son un método de testing para medir qué tan

amigable y fácil de utilizar es una aplicación [34]. Los principales motivos para efectuar

estas pruebas consistieron en la inexperiencia del equipo de trabajo con tecnologías de

realidad aumentada y la necesidad de seleccionar el enfoque más adecuado para el desa-

rrollo de la aplicación.

Esta prueba tuvo dos fases en las que se validaron los siguientes aspectos:

• Fase 1: su objetivo consistió en tomar decisiones en cuanto al apartado de interfaces

gráficas y a la forma en que el usuario interactúa con los elementos proyectados en

realidad aumentada. Para esta fase se contó con un total de 8 usuarios que probaron

el prototipo desarrollado.

• Fase 2: Su objetivo, principalmente, era comprobar qué tan intuitiva era la forma en

que el usuario podía modificar estructuras de datos y si consideraban adecuado el

modo en que se proyectaban los elementos en realidad aumentada. Esta prueba fue

realizada a un total de 17 usuarios.

Tras un análisis de la información obtenida tanto en la fase 1 como en la fase 2, se tomaron

las siguientes decisiones en cuanto aspectos de usabilidad:


- CIS2021CP02

Page 38

• Los menús desplegables deben estar distribuidos de forma radial. Dado que, según

los usuarios, es mucho más cómodo, obstruye menos la pantalla y, en general, les

parece más estético.

• La selección de los objetos proyectados debe realizarse mediante toques simples en

la pantalla. Los usuarios determinaron que es más práctico e intuitivo para seleccio-

nar uno o varios elementos.

• El sistema debe contar con herramientas de ayuda como tooltips y tutoriales, dado

que el sistema no es lo suficientemente intuitivo para los usuarios.

• Las proyecciones deben presentarse en 2.5D para mantener la representación con-

vencional de las estructuras de datos sin perder el factor tridimensional de la realidad

aumentada.

• El sistema debe permitir al usuario la reubicación manual de los elementos proyecta-

dos para personalizar la distribución de los mismos.

La descripción completa del proceso de pruebas de usabilidad se detalla en el anexo Control

de calidad.

2. Fase de Desarrollo

Tomando como insumo los resultados de la fase anterior, el equipo inició con el desarrollo de

la aplicación para lo cual se emplearon las metodologías ágiles SCRUM y TDD.

El uso de SCRUM en esta fase fue vital, dado que a medida que se iba desarrollando, se nece-

sitaba actualizar componentes de documentación, así mismo, si había modificaciones sobre

un requerimiento, el cambio se hacía tanto en código fuente como en los documentos. Apli-

cando dicha metodología, se definieron un total de 10 Sprints, que podían ser de dos tipos, el

primero es un sprint asociado a documentación o pruebas, este tendría una duración de una

semana; el segundo es un sprint asociado a código fuente, el cual tendría una duración de dos


Page 39

semanas. Para detallar la forma en que se aplicaron las metodologías, remitirse al anexo Plan

de administración de proyecto (PMP).

Por otra parte, se empleó TDD para asegurar la calidad de software. Esta metodología con-

siste en definir los casos de prueba necesarios para entregar un producto de calidad y luego

desarrollar el sistema que cumple con éxito dichos escenarios. En particular se adaptaron las

fases propuestas por TDD de la siguiente forma:

• Fase de pruebas: Se construyeron los criterios de aceptación para cada tarea e histo-

ria de usuario. Dichos criterios definen las condiciones para aceptar la tarea.

• Fase de implementación: Se implementó el código fuente asociado a la historia de

usuario o se realizó la tarea designada. En ambos casos, se tuvo en cuenta cada crite-

rio de aceptación.

• Fase de refactorización: Una vez finalizada la tarea, se procedía a hacer la revisión y

aprobación de la misma. Si algún criterio de aceptación no se cumplía, se realizaban

las actualizaciones pertinentes.

3. Pruebas

Siguiendo la metodología TDD se realizaron pruebas unitarias de forma paralela al desarrollo,

las cuales permitieron reducir al mínimo los errores. Dichas pruebas consistieron en verificar

que las funcionalidades desarrolladas cumplieran con los criterios de aceptación definidos

para los requerimientos. En este orden de ideas, se llevaron a cabo las pruebas para validar

los cuatro tipos de funcionalidades que se implementaron en el PMV, descritos a continua-

ción:

• Proyección de estructuras de datos: primer grupo de funcionalidades en ser proba-

das, relacionado con la correcta proyección de los nodos y aristas que representan las

estructuras.

• Algoritmos: hacen referencia a las funcionalidades que realizan alguna modificación

en las estructuras de datos, dentro de este grupo los criterios más importantes fueron


- CIS2021CP02

Page 40

el estado de la estructura después de las operaciones y la representación visual de las

mismas.

• Animaciones de los algoritmos: en este grupo se probaron cada una de las animacio-

nes definidas para las operaciones, como pintado, escalamiento y movimiento de los

elementos proyectos.

• Funcionalidades de soporte: hacen referencia a aquellas que brindan al usuario la in-

formación necesaria para el correcto uso de la PMV, dentro de las cuales se probaron

la descarga de marcadores y visualización de video tutoriales.

Cada una de las pruebas unitarias se ejecutaron en los distintos dispositivos del equipo de

trabajo. A partir de lo anterior, se evidencio que los grupos ya mencionados cumplieron satis-

factoriamente los criterios de aceptación definidos para estos. Los resultados y la especifica-

ción de los criterios se detallan en el anexo Control de calidad.

4. Producto final

Luego de completar el diseño, implementación y control de calidad de la solución, se obtuvo

como resultado el producto final presentado en las siguientes subsecciones.

i. Interfaces de inicio

En la Ilustración 14 Interfaces de inicio se evidencian las 4 pantallas iniciales con las cuales

interactúa el usuario. Desde la ‘pantalla menú inicio’ es posible acceder a las siguientes in-

terfaces: en la ‘pantalla color de tema’ el usuario puede seleccionar un color global para los

botones de AEDRA, en la ‘pantalla marcadores’ se despliega el listado de marcadores dispo-

nibles para ver el detalle y descargarlos. Por último, la ‘pantalla Tutoriales’ presenta el listado

de vídeos para aprender a usar el sistema.


Page 41

Ilustración 14 Interfaces de inicio

ii. Diseño de marcadores

Los marcadores son la herramienta principal para hacer uso de AEDRA, estos son extensibles

dado que el diseño implementado facilita la incorporación de nuevos marcadores de RA. Para

el PMV, se definieron tres tipos de marcador, los cuales se presentan en la Ilustración 15 Mar-

cadores soportados. Los marcadores ED, para la construcción de estructuras de datos; marca-

dores información, para la proyección de definiciones, características, ejemplos y otros datos

relevantes; los marcadores algoritmos, para mostrar la ejecución paso a paso de un algoritmo

aplicado a una estructura de datos. En las siguientes subsecciones se observa el funciona-

miento detallado de cada uno de estos.

Ilustración 15 Marcadores soportados


- CIS2021CP02

Page 42

iii. Marcador de estructuras

Los marcadores de estructuras de datos tienen la principal funcionalidad de permitir que el

usuario cree y modifique una estructura con datos personalizados. Una vez el usuario inicia

la cámara dentro de la aplicación, debe enfocar el marcador de RA deseado para observar la

proyección correspondiente. En la Ilustración 16 Detección de marcador se observan las in-

terfaces antes y después del reconocimiento, así mismo, en caso de que se cuente con infor-

mación previamente definida, le será mostrada al usuario.

Ilustración 16 Detección de marcador

iv. Marcadores de algoritmos

AEDRA contiene un sistema para el control de animaciones de algunas operaciones y algorit-

mos que se realizan en las estructuras, este sistema permite al usuario ver el paso a paso del

procedimiento dándole la oportunidad de controlar la reproducción. Adicionalmente, los

marcadores de algoritmos disponen de dos modalidades de proyección presentadas a conti-

nuación:

Individual

En primer lugar, como se observa en la Ilustración 17 Detección de marcador de algoritmo

individual si el usuario enfoca a un marcador de algoritmo se proyecta una estructura de


Page 43

datos predefinida que no puede ser modificada. El objetivo de este tipo de marcadores es

permitir que el usuario se enfoque en observar escenarios definidos de un algoritmo, esto

permite que sea más fácil ilustrar casos especiales dentro de un algoritmo, ya que los datos

de entrada son conocidos de antemano.

Ilustración 17 Detección de marcador de algoritmo individual

Compuesto

Por otro lado, el usuario puede combinar la detección de dos marcadores al mismo tiempo.

La Ilustración 18 Detección de marcadores compuestos, demuestra que es posible detectar

primero el marcador de estructura de datos y, posteriormente, el marcador de algoritmo.

Esta modalidad permite que el usuario vea la ejecución de un algoritmo sobre una ED cons-

truida por él. A futuro, la aplicación permite agregar nuevos algoritmos en forma de marca-

dores totalmente independientes, de esta forma, se ofrece extensibilidad en el sistema.


- CIS2021CP02

Page 44

Ilustración 18 Detección de marcadores compuestos

v. Marcadores de información

Finalmente, es posible proyectar información tal como definiciones, características, casos es-

peciales, entre otros. Dicha información está relacionada con la estructura de datos o algo-

ritmo del marcador, tal como se observa en la Ilustración 19 Detección de marcadores de

información, en donde el usuario enfoca la cámara en el marcador y visualiza la proyección

desde diferentes ángulos.


Page 45

Ilustración 19 Detección de marcadores de información

Adicionalmente, se presenta un botón al usuario que le permite ver otra sección, un ejemplo

de ello son las referencias mostradas en la Ilustración 20 Marcador de información proyectada

con el fin de entregar material al usuario para ampliar información sobre el tema.

Ilustración 20 Marcador de información proyectada


- CIS2021CP02

Page 46

vi. Personalización de una ED

Añadir nodos

Una vez se tiene una proyección de una ED, AEDRA permite que los usuarios agreguen ele-

mentos usando el botón de agregar. Esta acción le pedirá al usuario ingresar el valor deseado

con el cual crear el nodo. Adicionalmente, el usuario puede reubicar los elementos manual-

mente, para lo cual, debe arrastrar el nodo por la pantalla. En un grafo puede moverlos en

todas las direcciones del plano, mientras que en un árbol solo puede moverlos horizontal-

mente. Este proceso se evidencia en la Ilustración 21 Añadir elementos.

Ilustración 21 Añadir elementos

Físicas

AEDRA cuenta con un sistema que ubica los elementos automáticamente en la proyección

para evitar colisiones entre ellos y mantener la representación visual de las estructuras. Este

sistema, llamado sistema de físicas, obliga a los elementos a ubicarse bajo ciertas restriccio-

nes. Para grafos, los nodos deben estar a una distancia predefinida de los otros nodos. Para


Page 47

árboles, se tiene en cuenta la jerarquía, es decir, los nodos hijos deben estar a la izquierda o

derecha de su padre dependiendo de su valor, también debe haber una distancia mínima

tanto vertical como horizontalmente de los nodos padres. Lo anterior se da gracias a una

fuerza de repulsión entre nodos, la cual actúa hasta cumplir las restricciones dadas, este pro-

ceso se evidencia en la Ilustración 22 Comportamiento de físicas, en la imagen ‘Parte A’ se

observa el árbol inicial, en la ‘Parte B’ el nodo hijo se mueve a la derecha dado que se inserta

un hijo izquierdo, en la ‘Parte C’ se empieza a crear el nuevo nodo y en la ‘Parte D’ se muestra

el resultado final.

Ilustración 22 Comportamiento de físicas

Añadir aristas (Grafo)

AEDRA ofrece menús que cambian a medida que el usuario interactúa con la aplicación, en

particular, para un grafo los menús dependen de la cantidad de nodos que se seleccionen,

como se evidencia en la Ilustración 23 Conectar elementos. Al seleccionar dos nodos se mues-

tra la ‘pantalla multiselección’. En este punto, se debe presionar el botón conectar, el cual

crea una arista entre los nodos seleccionados, dando como resultado la ‘Pantalla Arista

Creada’.


- CIS2021CP02

Page 48

Ilustración 23 Conectar elementos

Eliminar elementos

Finalmente, se puede observar en la Ilustración 24 Eliminar elementos, las operaciones res-

pectivas para quitar elementos en un grafo y en un árbol binario. Es importante destacar, que

para eliminar un nodo en el árbol el usuario debe ingresar el valor a quitar, mientras que, en

el menú de grafo, basta con que el usuario seleccione el nodo que desea borrar. Independien-

temente de la estructura, primero se eliminan las conexiones antes de eliminar el nodo.

Ilustración 24 Eliminar elementos


Page 49

vii. Algoritmos implementados

Finalmente se detallan los algoritmos específicos que fueron implementados en cada una de

las estructuras correspondientes.

Búsqueda binaria (Árbol)

Como se observa en la Ilustración 25 Algoritmo de búsqueda, se pide al usuario que ingrese

el valor a buscar, posteriormente, la animación inicia de forma automática. Allí se puede con-

trolar mediante los botones desplegados en la parte inferior. Finalmente, en la parte frontal

del marcador se van proyectando los pasos de la ejecución.

Ilustración 25 Algoritmo de búsqueda

Recorridos

Los recorridos son operaciones específicas de cada estructura y por lo general existen varias

formas de realizarlos. Como se puede observar en la Ilustración 26 Recorridos en estructuras,

en grafos se debe seleccionar un nodo de inicio, una vez seleccionado el usuario puede esco-

ger entre los algoritmos de BFS (Breadth First Search) y DFS (Depth First Search). Por su parte,

en árboles el usuario debe escoger en el menú de recorridos entre las operaciones preorden,

postorden e inorden. Tanto en árbol como en grafo, se mostrará la ejecución respectiva de

dichos recorridos y el menú de control de animaciones.


- CIS2021CP02

Page 50

Ilustración 26 Recorridos en estructuras

Algoritmo de Dijkstra (Grafo)

Este algoritmo fue implementado para funcionar con los algoritmos Compuestos, por ello para

ver su ejecución paso a paso se puede usar el modo individual o el modo compuesto. Como

se observa en la Ilustración 27 Algoritmo Dijkstra, una vez inicia el algoritmo, se pintan los

nodos y aristas visitadas, y al mismo tiempo, se proyectan textos explicativos para que el

usuario entienda su funcionamiento.

Ilustración 27 Algoritmo Dijkstra


Page 51

VII. PRUEBAS DE ACEPTACIÓN Y RESULTADOS

Las pruebas de aceptación o UAT (User Acceptance Testing) se definen como aquellas pruebas

aplicadas a los usuarios finales para determinar si el sistema cumple con los objetivos espera-

dos [34]. Dichas pruebas se realizaron en el momento en que se determinó que el sistema era

estable, funcional y que cumplía con los requerimientos acordados para el producto mínimo

viable.

Al trabajar con realidad aumentada, dado que es un enfoque relativamente innovador y fuera

de lo convencional en el ámbito de enseñanza de estructuras de datos, se requirió de una

metodología que facilitara medir el nivel de interés de los estudiantes frente a la solución

propuesta. Teniendo en cuenta lo anterior, se hizo uso del modelo de aceptación tecnológica

(TAM) propuesto por Fred Davis en 1989 [35]. Es definido como un marco que permite evaluar

y predecir el nivel de aceptación de una tecnología emergente por parte de los usuarios [36].

Este marco se aplicó en AEDRA mediante una encuesta con preguntas categorizadas en las

siguientes dimensiones definidas por TAM [36]:

• Utilidad percibida: determina el grado en que una persona piensa que una tecnología

en particular mejorará su rendimiento en un área específica.

• Facilidad de uso percibida: determina qué tan intuitiva y fácil de usar es la solución

para el usuario.

• Actitud hacia el uso: determina la actitud que toman los usuarios al usar la aplicación,

teniendo en cuenta la utilidad y la facilidad de uso percibida.

• Intención de uso: determina el grado de intención de uso a futuro de los usuarios para

con la solución.

A partir de dichas dimensiones, se genera un total de 13 preguntas que buscan brindar infor-

mación precisa para realizar un análisis de los resultados sobre los objetivos propuestos. Te-

niendo en cuenta las preguntas planteadas, se definió un umbral en el cual se esperaba que


- CIS2021CP02

Page 52

el nivel de aceptación en las dimensiones fuese mayor a: 70% en utilidad percibida y actitud

hacia el uso y 60% en facilidad de uso e intención de uso.

1. Encuesta de aceptación al usuario:

Para llevar a cabo las pruebas de aceptación, se restringió que los encuestados hayan apren-

dido estructuras de datos usando la metodología tradicional. Lo anterior se debe a que se

espera obtener una comparativa entre el aprendizaje con libros, videos o clases magistrales y

AEDRA, para medir por un lado la motivación e interés y por otro, el potencial de la aplicación

como material didáctico. Por esta razón, la población que se seleccionó fue un grupo de 20

alumnos y exalumnos de carreras afines a ingeniería de sistemas. Posteriormente, se seg-

mentó la población en dos grupos; 7 usuarios probaron la aplicación haciendo uso de marca-

dores físicos (impresos) y los 13 restantes utilizaron marcadores digitales (imágenes). La razón

de realizar dicha separación se debió a la facilidad por parte de los usuarios para acceder a

los marcadores.

A continuación, en la Tabla 7 Preguntas del cuestionario se presentan las más relevantes y su

respectivo peso dentro de las dimensiones del TAM. Adicionalmente, dichas preguntas tienen

una nomenclatura que será usada para referenciarlas en secciones posteriores.

Utilidad percibida Peso

[U1] Si cuando usted aprendió estructuras de datos hubiese existido esta herramienta ¿Con

qué frecuencia la habría utilizado?

30%

[U2] ¿Considera que usar esta herramienta en un aula de clase mejoraría la participación de los estudiantes?

No aplica

[U3] Evalúe de 1 a 5 las siguientes alternativas de aprendizaje teniendo en cuenta cual con-

sidera mejor para ENTENDER el funcionamiento de las estructuras de datos.

70%

[U4] ¿De 1 a 5 que tanto le gustaría aprender otras estructuras de datos mediante realidad aumentada?

No aplica

Facilidad de uso percibida

[F1] ¿De 1 a 5 que tan intuitiva fue utilizar la aplicación para usted? 50%

[F2] ¿De 1 a 5 qué tan intuitivo fue el uso de marcadores para proyectar en realidad au-

mentada?

50%

Actitud hacia el uso

[A1] Si hubiese tenido la oportunidad de usar esta aplicación cuando vio estructuras de da-

tos ¿Considera que hubiese mejorado su interés por los temas?

25%


Page 53

[A2] ¿En una escala de 1 a 5 que tan satisfecho se siente al aprender estructuras de datos

usando realidad aumentada?

15%

[A3] ¿Le resulta llamativo el uso de marcadores físicos para interactuar con la aplicación? No aplica

[A4] Evalúe de 1 a 5 las siguientes alternativas de aprendizaje teniendo en cuenta que tan

INTERESANTES considera que son.

60%

Intención de uso

[I1] ¿Bajo cuales circunstancias estaría dispuesto a utilizar la aplicación? No aplica

[I2] ¿Utilizaría esta aplicación como método de estudio fuera del aula de clase? 60%

[I3] ¿Considera que esta app es potencialmente útil para la enseñanza en clases como ma-

terial didáctico?

40%

Tabla 7 Preguntas del cuestionario


- CIS2021CP02

Page 54

2. Análisis de resultados

Para calcular el grado de aceptación en cada dimensión, se tuvieron en cuenta 9 de las 13

preguntas planteadas, sin embargo, las preguntas I1, A3, U2 y U4 que se dejaron por fuera,

NO desvían los resultados presentados. Cabe recalcar que no se realiza un análisis detallado

en cuanto a la segmentación de la población mencionada anteriormente, esto se debe a que

no se considera un factor relevante para el análisis.

i. Análisis por dimensiones

Ilustración 28 Resultados de actitud hacia el uso

A partir de la gráfica de resultados a la pregunta A1 en la Ilustración 28 Resultados de actitud

hacia el uso, se evidencia que el 100% de los usuarios consideran que la herramienta mejora


Page 55

su interés por los temas. Con respecto a los resultados a la pregunta A2, el 80% de los usua-

rios, se sienten algo y muy satisfechos al aprender con realidad aumentada, lo cual es un

punto a favor de AEDRA, dado que dicha evaluación supera el nivel de satisfacción esperado.

En la gráfica de resultados a la pregunta A4 se presenta una comparativa del nivel de interés

percibido por los usuarios frente a herramientas como libros, clases magistrales, videos, he-

rramientas visuales y AEDRA. En este punto, se evidencia que el 100 % de los usuarios califican

a AEDRA con una evaluación mayor o igual a 4 para indicar que es interesante para el apren-

dizaje. En el caso de libros y clases magistrales, más del 60% de los usuarios no se sienten

suficientemente motivados por estas opciones. A partir de este análisis, se evidencia que

AEDRA, gracias a su componente altamente interactivo, genera interés y motivación en los

estudiantes quienes adoptan un rol activo en su propio aprendizaje.

Ilustración 29 Resultados de intención de uso


- CIS2021CP02

Page 56

Para medir la dimensión de intensión de los usuarios por utilizar la aplicación en distintas

situaciones, se plantearon las preguntas I1, I2 e I3 presentadas en la Ilustración 29 Resultados

de intención de uso. A partir de los resultados, se evidencia que el 100% de los usuarios con-

sideran que la aplicación tiene potencial como material didáctico dentro del aula de clase y,

adicionalmente, estarían dispuestos a utilizarla fuera de la misma como parte de su proceso

de estudio independiente en el desarrollo de talleres e incluso preparación para exámenes.

AEDRA, al ser una aplicación móvil, portable, de instalación sencilla y asequible, permite que

los usuarios puedan utilizarla en cualquier momento y lugar, lo que facilita su uso tanto fuera

como dentro de las aulas.

Ilustración 30 Resultados de utilidad percibida

Para realizar el análisis de los resultados evidenciados en la Ilustración 30 Resultados de utili-

dad percibida es necesario destacar que la población encuestada ya tenía un acercamiento

previo a ED, por lo tanto, las preguntas se orientaron al potencial que ellos perciben si hubie-

sen tenido la herramienta cuando aprendieron los conceptos.

En este orden de ideas, en los resultados de la pregunta U3 se evidencia que los encuestados

perciben que las alternativas visuales e interactivas tienen un gran potencial como medio para


Page 57

entender el funcionamiento de las ED. No obstante, se observa que el 75% de los estudiantes

consideran que las clases magistrales fueron fundamentales para comprender los conceptos.

A partir de lo anterior, se puede determinar que para apoyar de forma efectiva el proceso de

aprendizaje, se podrían complementar las metodologías tradicionales con técnicas interacti-

vas aprovechando los beneficios que cada una ofrece.

Adicionalmente, es importante aclarar que AEDRA no tendría una alta frecuencia de uso como

se observa en los resultados de U1, lo cual se debe a la naturaleza que tiene la solución como

material didáctico y también a las circunstancias en las cuales sería utilizada, estas últimas se

evidencian en la gráfica I1. A pesar de lo anterior, los usuarios demuestran que estarían dis-

puestos a usar la solución moderadamente.

Ilustración 31 Resultados de facilidad de uso percibida

Como se evidencia en las gráficas de resultados a las preguntas F1 y F2 en Ilustración 31 Re-

sultados de facilidad de uso percibida, en promedio el 80% los usuarios tuvieron una reacción

altamente positiva frente a la facilidad de uso de AEDRA. Específicamente en F2 se evidencia

que, a pesar de que los marcadores no son un recurso convencional de estudio, las personas

consideran que el uso de los mismos es altamente intuitivo, lo cual es un punto a favor para

utilizarlos como material didáctico.


- CIS2021CP02

Page 58

ii. Síntesis de resultados

Es importante tener en cuenta que por cada tipo de pregunta se definió un criterio para de-

terminar si sus resultados contribuyen positivamente a la dimensión correspondiente. En pri-

mer lugar, las preguntas con respuestas de escalas tienen como criterio que los usuarios que

respondieron dentro del rango [4-5] se consideran como un aporte positivo. En segundo lugar,

las preguntas cerradas (Si/No), tienen como criterio que los usuarios que respondieron “Si”,

tienen un aporte positivo.

Por consiguiente, en la Ilustración 32 Porcentaje de aceptación esperado vs obtenido en las

dimensiones TAM se presentan los resultados finales por cada dimensión.

Ilustración 32 Porcentaje de aceptación esperado vs obtenido en las dimensiones TAM

A continuación, se presenta el nivel de aceptación obtenido en cada una de las dimensiones

del TAM:

• Utilidad percibida: el nivel de aceptación fue del 70.5%, con lo cual, se infiere que los

estudiantes que tuvieron un acercamiento previo a estructuras de datos, perciben

que AEDRA tiene potencial para complementar el aprendizaje. Sin embargo, a partir


Page 59

de estos resultados no es posible determinar que la solución propuesta es más efec-

tiva para aprender estructuras de datos que otras alternativas de enseñanza.

• Facilidad de uso percibida: se obtuvo un grado de aceptación del 85%, con lo cual se

evidencia el cumplimiento de uno de los RNF más importantes, que corresponde con

la usabilidad. De esto se puede concluir que la solución propuesta es fácil de entender

y utilizar para los usuarios.

• Actitud hacia el uso: se obtuvo un nivel de aceptación del 97% por parte de los usua-

rios, estos demuestran interés por usar AEDRA para apoyar su aprendizaje de ED, lo

anterior se debe a que la tecnología es innovadora y disruptiva en el ámbito de la

enseñanza de ED, por consiguiente, la solución es muy llamativa para los usuarios.

• Intención de uso: el nivel de aceptación fue de 100% debido a que los usuarios mos-

traron una alta disposición de usar la herramienta tanto dentro como fuera de las

aulas de clase, apoyando el estudio autónomo para el desarrollo de talleres e incluso

preparación para exámenes.

Teniendo en cuenta que los resultados obtenidos sobrepasan el umbral de aceptación defi-

nido en cada una de las dimensiones, se considera que AEDRA supera las expectativas plan-

teadas en el objetivo general del trabajo de grado. Por un lado, AEDRA incentiva a los estu-

diantes a tomar un rol activo en su proceso de aprendizaje por medio del interés y la motiva-

ción y por el otro, AEDRA es aceptada por los estudiantes para apoyar su proceso de ense-

ñanza sin reemplazar la metodología tradicional.


- CIS2021CP02

Page 60

VIII. CONCLUSIONES

El objetivo general se cumplió a cabalidad porque se evidenció, a partir de los resultados ob-

tenidos, que incorporar realidad aumentada apoya el proceso de aprendizaje de estructuras

de datos mejorando el interés y la motivación en el estudiante para consolidar los conoci-

mientos. A continuación, se detallan las conclusiones que sustentan el cumplimiento del ob-

jetivo:

• AEDRA, al llevar conceptos abstractos a un contexto más tangible y práctico, incentiva

el interés de los estudiantes por apropiarse de los conceptos de estructuras de datos.

• A partir de los resultados obtenidos por la metodología TAM, se concluye que la so-

lución es altamente aceptada por parte de la población objetivo, para apoyar el pro-

ceso de aprendizaje de ED. Lo anterior se debe a que, con base en los resultados de

las encuestas, los usuarios consideran que AEDRA es útil, interesante, fácil de usar y

tiene potencial futuro.

• AEDRA es efectiva como material didáctico debido a que el uso de marcadores de

realidad aumentada facilita adaptar la solución en diferentes contextos dentro y fuera

del aula de clases. En otras palabras, no busca reemplazar las metodologías tradicio-

nales de enseñanza, sino favorecer la construcción de aprendizaje significativo en di-

ferentes entornos educativos.

El desarrollo de una solución de esta índole que emplea tecnologías de realidad de aumentada

involucra desafíos en el proceso de diseño e desarrollo de la misma. A partir del trabajo rea-

lizado se concluyeron los siguientes ítems:

• La implementación de la prueba de concepto fue un factor determinante para

alcanzar el objetivo propuesto. Por un lado, contribuyó a refinar los requerimien-

tos y el diseño de interfaces de usuario desde etapas tempranas. Por el otro, per-

mitió validar la factibilidad desde distintos puntos de vista: en primer lugar, se

evidenció que la idea propuesta era factible a nivel técnico. En segundo lugar,

permitió tener un primer acercamiento del nivel de aceptación de los usuarios


Page 61

por la solución. Finalmente, no solo brindó al equipo la experiencia necesaria para

utilizar las tecnologías y herramientas, sino que también la seguridad de que la

solución era alcanzable.

• Uno de los mayores retos para crear soluciones de realidad aumentada es la com-

patibilidad con los dispositivos. En particular, se evidenciaron escenarios en

dónde la detección de marcadores no funcionaba según lo esperado en algunos

dispositivos y los objetos no se mostraban de forma adecuada, esto se debía en-

tre otras razones, por diferencias en la forma en que el giroscopio orientaba el

espacio tridimensional. De lo anterior se concluye, que la compatibilidad exige un

esfuerzo adicional por parte de los desarrolladores para construir una solución

efectiva empleando estas tecnologías.

• En el desarrollo de AEDRA, fue particularmente compleja la ubicación de los ele-

mentos 3D en el espacio. Entre los retos más importantes se encontraba limitar

el espacio que podían ocupar las proyecciones para evitar que salieran del campo

de visión de la cámara. Adicionalmente, dependiendo del tipo de ED el posiciona-

miento de los elementos involucraba dificultades totalmente diferentes para ob-

tener buenos resultados visuales. De los anteriores desafíos se resalta que para

soluciones de esta índole es fundamental definir detalladamente las restricciones

de espacio para garantizar una buena experiencia de usuario.

En resumen, las soluciones basadas en realidad aumentada para el aprendizaje de conceptos

de estructuras de datos implican retos importantes para su desarrollo. Sin embargo, con

AEDRA se evidenció que, como material didáctico de apoyo, son una gran herramienta para

complementar el proceso de aprendizaje incentivando la motivación y el interés.

1. Análisis del impacto del Proyecto

En el corto plazo, se espera que AEDRA sea adoptada por docentes y estudiantes que cursen

estructuras de datos con el fin de aprovechar los beneficios que ofrece la solución como ma-

terial de apoyo para las clases.


- CIS2021CP02

Page 62

En el mediano plazo, por un lado, se espera que la solución sea usada por los estudiantes para

estudiar de manera independiente y así obtener mejores resultados en el aprendizaje de es-

tructuras de datos. Por otro lado, se prevé que algunos miembros de la comunidad educativa,

como grupos estudiantiles, tomen la iniciativa de extender esta solución para profundizar es-

tructuras de datos y abarcar temas de mayor complejidad.

En el largo plazo, se espera que AEDRA sirva como punto de referencia para trabajos futuros

en otras áreas que deseen adoptar las técnicas interactivas para complementar el proceso de

enseñanza-aprendizaje. Adicionalmente, se prevé que el uso de RA en entornos educativos

sea más frecuente, dado que es una tecnología de gran acogida, asequible, fácil de usar y

genera motivación en los estudiantes para ampliar su conocimiento.

2. Trabajo a futuro

Finalmente, se presentan las principales propuestas que pueden ser desarrolladas en un fu-

turo para profundizar sobre los resultados obtenidos en el presente trabajo de grado, estas

se encuentran agrupadas en tres grupos:

i. Educación

En el ámbito educativo, el trabajo futuro de mayor importancia, consiste en validar que

AEDRA se puede usar de manera activa como material de apoyo dentro de las aulas de clase.

Por consiguiente, se recomienda contar con el análisis de un experto en pedagogía que de-

termine si la realidad aumentada es adecuada para entender los conceptos abstractos de es-

tructuras de datos. Una vez validado lo anterior, se sugiere dar mayor visibilidad a la solución

haciendo que esta llegue a más estudiantes y docentes, con el objetivo de observar la efecti-

vidad de AEDRA en entornos reales.

ii. Extensión de funcionalidades

Una vez se valide que la solución se puede utilizar de manera efectiva en cursos de estructuras

de datos, se propone agregar los siguientes elementos:


Page 63

• Agregar nuevas estructuras y algoritmos: para abarcar la completitud de los funda-

mentos de estructuras de datos, se debería complementar el apartado de ED no li-

neales añadiendo nuevos tipos de árboles y haciendo la distinción entre grafos dirigi-

dos y no dirigidos. Adicionalmente, se deberían incorporar ED lineales tales como lis-

tas, pilas, colas, entre otras. Lo anteriormente mencionado es posible gracias al di-

seño altamente extensible de AEDRA que soporta la incorporación de nuevas estruc-

turas de datos y algoritmos.

• Crear un apartado de resolución de problemas: para contribuir aún más en el proceso

de aprendizaje, se requiere que los estudiantes se apropien de los conocimientos y

sean capaces de aplicarlos en distintos escenarios. Para ello, se considera que, en el

futuro, AEDRA ofrezca marcadores que planteen problemas y proyecten su respectiva

solución aplicando algoritmos sobre estructuras de datos en realidad aumentada.

• Permitir la personalización de marcadores: esta propuesta está principalmente enfo-

cada en los docentes, el objetivo es que puedan crear sus propios escenarios y plas-

marlos en nuevos marcadores que sean utilizados como material de apoyo para una

clase.

• Implementar un modo de trabajo colaborativo: se propone un modo donde diferen-

tes usuarios sean capaces de observar y modificar la misma estructura de datos pro-

yectada en tiempo real. Lo anterior con el fin de realizar explicaciones grupales, a

partir de escenarios de estudio, permitiendo la interacción entre estudiantes.

iii. Extensión de tecnología

Finalmente, se propone profundizar en el uso de la tecnología y las plataformas usadas en

AEDRA, para ello se recomiendan los siguientes ítems:

• Desarrollo multiplataforma: Con la finalidad de que más personas puedan hacer uso

de la aplicación, se debería dar soporte a dispositivos con sistema operativo iOS.

• Adaptación de la solución a otras tecnologías: A la par de la realidad aumentada, exis-

ten tecnologías que se centran aún más en una experiencia de usuario inmersiva y en


- CIS2021CP02

Page 64

la forma en como este se involucra con la solución, este es el caso de la realidad vir-

tual. Las funcionalidades de AEDRA pueden ser adaptadas a esta tecnología, sin em-

bargo, se sacrifican características importantes como: la intención de uso a modo de

material didáctico para una clase, la portabilidad y la facilidad de acceso debido a los

costos significativos que conlleva la realidad virtual.

• Mejorar la interacción: crear nuevos modos de interacción con el sistema, por ejem-

plo, en un futuro el usuario podría realizar acciones directamente sobre la proyección

simulando el contacto físico en lugar de tocar una pantalla. De esta forma, se genera-

ría un sentimiento de mayor interactividad con la aplicación.

• Profundizar en los beneficios de la Realidad Aumentada: esta tecnología tiene la ca-

pacidad de proyectar cualquier elemento modelado en 3D. A futuro se pretende lle-

gar a un nivel de diseño mucho más avanzado donde el usuario pueda observar la

representación de objetos reales en este entorno virtual. Un ejemplo de lo anterior-

mente mencionado es ambientar el algoritmo de encontrar el camino más corto entre

dos puntos en un mapa y establecer estaciones, caminos, decoración y efectos. De

esta forma, se logrará reforzar el apartado visual generando en el usuario mayor in-

terés e inquietud por comprender el significado de lo que se está proyectando.


Page 65

IX. REFERENCIAS

[1] Fayer, S., Lacey, A. and Watson, A., 2017. “Stem occupations: Past present and future.”

[Online] Available: https://www.bls.gov/spotlight/2017/science-technology-engineering-and-

mathematics-stem-occupations-past-present-and-future/pdf/science-technology-engineering-

and-mathematics-stem-occupations-past-present-and-future.pdf [Accessed 1 - May- 2021].

[2] R. Pessoa Medeiros, G. Lisboa Ramalho and T. Pontual Falcão, "A Systematic Literature

Review on Teaching and Learning Introductory Programming in Higher Education", Ieeex-

plore.ieee.org, 2018. [Online]. Available: https://ieeexplore-ieee-org.ezproxy.javeri-

ana.edu.co/stamp/stamp.jsp?tp=&arnumber=8447543. [Accessed: 02- May- 2021].

[3] J. Froyd and N. Simpson, "Student-Centered Learning Addressing Faculty Questions

about Studentcentered Learning", Citeseerx.ist.psu.edu, 2016. [Online]. Available:

http://citeseerx.ist.psu.edu/viewdoc/download;jses-

sionid=A13A5032D2D54320E9B92B5C1FC7AC04?doi=10.1.1.526.348&rep=rep1&type=p

df. [Accessed: 04- May- 2021]

[4] A. Tenenbaum, "Algorithms & data structures | Guide books", ACM, 2012. [Online].

Available: https://dl.acm.org/doi/abs/10.5555/4546. [Accessed: 01- May- 2021]

[5] S. Patel, "A Literature Review on Tools for Learning Data Structures", Peo-

ple.cs.uct.ac.za, 2014. [Online]. Available: https://people.cs.uct.ac.za/~spatel/PDFs/Litera-

ture%20Review%20[Shirin][FINAL].pdf. [Accessed: 02- May- 2021].

[6] H. Narman, C. Berry and A. Canfield, "Augmented Reality for Teaching Data Structures

in Computer Science", IEEE Xplore, 2020. [Online]. Available: https://ieeexplore-ieee-

org.ezproxy.javeriana.edu.co/document/9342932?arnumber=9342932. [Accessed: 01- May-

2021].

[7] E. Muñoz Andrade, C. Arévalo Mercado and J. Gómez Reynoso, "Learning Data Struc-

tures Using Multimedia-Interactive Systems", 2008. [Online]. Available: https://www.re-

searchgate.net/publication/255587395_Learning_Data_Structures_Using_Multimedia-Inter-

active_Systems. [Accessed: 02- May- 2021].

[8]. X. Chen and M. Soldner, “Stem attrition: College students’ paths into and out of stem

fields,” 2013. [Online]. Available: https://nces.ed.gov/pubs2014/2014001rev.pdf [Accessed:

01- May- 2021].

[9] D. Wu, P. Guo and C. Zhang, “Research and Practice of Data Structure Curriculum Re-

form Based on Outcome-Based Education and Chaoxing Platform”. 2021 [Online]. Availa-

ble: http://www.ijiet.org/vol11/1537-IJIET-1856.pdf. [Accessed: 25- Oct- 2021]

[10] V. Karavirta, A. Korhonen, L. Malmi and K. Stalnacke, "MatrixPro – A Tool for On-

The-Fly Demonstration of DataStructures and Algorithms", 2021. [Online]. Available:


- CIS2021CP02

Page 66

https://www.researchgate.net/publication/230785179_MatrixPro_--_A_Tool_for_On-The-

Fly_Demonstration_of_Data_Structures_and_Algorithms. [Accessed: 01- May- 2021].

[11] Y. Chen, Q. Wang, H. Chen and X. Song, "ShieldSquare Captcha", Iopscience.iop.org,

2021. [Online]. Available: https://iopscience.iop.org/article/10.1088/1742-

6596/1237/2/022082/meta. [Accessed: 01- Nov- 2021]

[12] Phil Diegmann, Manuel Schmidt-Kraepelin, Sven van den Eynden, and Dirk Basten.

“Benefits of Augmented Reality in Educational Environments – A Systematic Literature Re-

view”. Conference: 12. Internationale Tagung Wirtschaftsinformatik (WI 2015) At: Osna-

brück, Germany. 2015. [Online]. Avalaible: https://www.researchgate.net/publica-

tion/312147184_Benefits_of_Augmented_Reality_in_Educational_Environments_-_A_Syste-

matic_Literature_Review. [Accesed: 01- May- 2021].

[13] Klopfer, E., Squire, K.: “Environmental Detectives - The Development of an Augmented

Reality Platform for Environmental Simulations.” Educational Tech-nology Research and

Development 56, 2008, pp 203–228.

[14] "16326-2019 - ISO/IEC/IEEE International Standard - “Systems and software engineer-

ing - Life cycle processes - Project management – Redline”, Ieeexplore.ieee.org, 2021.

[Online]. Available: https://ieeexplore.ieee.org/document/9006999. [Accessed: 01- May-

2021]

[15] "IEEE 1016-2009 - IEEE Standard for Information Technology - "Systems Design -

Software Design Descriptions”, Standards.ieee.org, 2021. [Online]. Available: https://stand-

ards.ieee.org/standard/1016-2009.html [Accessed: 01- May- 2021].

[16] "29148-2018 - ISO/IEC/IEEE International Standard – “Systems and software engi-

neering - Life cycle processes - Requirements engineering", Ieeexplore.ieee.org, 2021.

[Online]. Available: https://ieeexplore.ieee.org/document/8559686. [Accessed: 01- May-

2021]

[17] "IEEE/ISO/IEC P29119-1 - ISO/IEC/IEEE Draft International Standard – “Software

and systems engineering - Software testing- Part 1: Concepts and definitions”, Stand-

ards.ieee.org, 2021. [Online]. Available: https://standards.ieee.org/project/29119-1.html.

[Accessed: 01- May- 2021]

[18]"Unified Modeling Language", Object Management Group, 2021. [Online]. Available:

https://www.omg.org/spec/UML/2.5.1/PDF. [Accessed: 01- May- 2021]

[19] M. Tabare, J. Pineda and A. Barrera, "Un patrón de interacción entre diagramas de ac-

tividades uml y sistemas workflow", Redalyc.org, 2008. [Online]. Available:

https://www.redalyc.org/pdf/1492/149212844008.pdf. [Accessed: 14- Nov- 2021].


Page 67

[20] "Test Driven development | Guide books", ACM, 2021. [Online]. Available:

https://dl.acm.org/doi/abs/10.5555/864016. [Accessed: 01- May- 2021]

[21] K. Schwaber, "SCRUM Development Process", Advanced Development Methods, 2021.

[Online]. Available: http://www.jeffsutherland.org/oopsla/schwapub.pdf. [Accessed: 01-

May- 2021]

[22] J. Bullinaria, "Data Structures and Algorithms", University of Birmingham, 2019.

[Online]. Available: https://www.cs.bham.ac.uk/~jxb/DSA/dsa.pdf. [Accessed: 22- May-

2021]

[23] M. Hurtado, "Modelos pedagógicos y reflexiones para las pedagogías del sur", Dialnet,

2016. [Online]. Available: https://dialnet.unirioja.es/servlet/articulo?codigo=6066089. [Ac-

cessed: 23- May- 2021]

[24] Jin, Qiao, et al. “AR-maze: a tangible programming tool for children based on AR tech-

nology”. 2018, pp. 611-16, doi:10.1145/3202185.3210784.

[25] S. Halim, "Visualización de estructuras de datos y algoritmos mediante animación", Vi-

suAlgo, 2011. [Online]. Available: https://visualgo.net/es. [Accessed: 01- May- 2021]

[26] OpenDSA. 2019. “GitHub Wiki OpenDSA”. [Online] Available at:

https://github.com/OpenDSA/OpenDSA/wiki [Accessed 1 May 2021].

[27] Patel, T., 2017. “Learning Object Oriented Programming Using Augmented Reality A

Case Study with Elementary School Students”. Master of Science. ARIZONA STATE

UNIVERSITY.

[28] J. Marulanda, “Aseguramiento de la calidad en el diseño del software”. Medellin: Uni-

versidad EAFIT, 2014 [Online]. Available: https://core.ac.uk/download/pdf/47246132.pdf.

[Accessed: 13- Sep- 2021]

[29] I. Buyuksalih and S. Bayburta, "3d modelling and visualization based on the unity game

engine – advantages and challenges", 3D GIS Research Group, 2021. [Online]. Available:

https://core.ac.uk/download/pdf/206025657.pdf. [Accessed: 16- Nov- 2021].

[30] R. Timchenko, O. Grechnyev, S. Skuratovskyi, Y. Chyrka and I. Gorovyi, "Augmented

Reality in Web: Results and Challenges," 2020 IEEE Third International Conference on Data

Stream Mining & Processing (DSMP), 2020, pp. 211-216, doi:

10.1109/DSMP47368.2020.9204240.

[31]Google. "Play Console Help", Support.google.com, 2021. [Online]. Available:

https://support.google.com/googleplay/android-developer/?hl=en. [Accessed: 03- Nov- 2021]


- CIS2021CP02

Page 68

[32] P. Kruchten, "Architectural Blueprints—The “4+1” View Model of Software Architec-

ture", Www3.software.ibm.com, 1995. [Online]. Available: http://www3.soft-

ware.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf. [Accessed:

15- Nov- 2021].

[33] C. Vichido, M. Estrada and A. Sanchez, "A constructivist educational tool: software ar-

chitecture for Web-based video games," Proceedings of the Fourth Mexican International

Conference on Computer Science, 2003. ENC 2003., 2003, pp. 144-150, doi:

10.1109/ENC.2003.1232888.

[34] K. NAIK and P. TRIPATHY, "Software Testing And Quality Assurance - Theory and

Practice", Wiley, 2021. [Online]. Available: https://www.softwaretestinggenius.com/down-

load/staqtpsn.pdf. [Accessed: 31- Oct- 2021].

[35] Davis, F.D. (1989). “Perceived usefulness, perceived ease of use, and user acceptance

of information technology”. MIS Quarterly 13(3), 319–340. Recuperado de:

http://www.jstor.org/stable/249008?seq=1#page_scan_tab_contents

[36] B. Fenández, "Aplicación del Modelo de Aceptación Tecnológica (TAM) al uso de la

realidad aumentada en estudios universitarios", Helvia.uco.es, 2017. [Online]. Available:

https://helvia.uco.es/xmlui/bitstream/handle/10396/14886/2017000001624.pdf?se-

quence=1&isAllowed=y. [Accessed: 31- Oct- 2021].

X. APÉNDICES

Anexo 1 - Plan de administración de proyecto (PMP).

Anexo 2 - Especificación de requerimientos de software (SRS).

Anexo 3 - Especificación de diseño del software (SDD).

Anexo 4 - Control de calidad.

Documents

CIS2021CP02 - repository.javeriana.edu.co