ingeniera del software aplicada al desarrollo de...

Ingeniera del software aplicada al desarrollo de aplicaciones con realidad aumentada.

Juan Carlos Vanegas Cerra, [email protected]

Sebastian Zapata Uribe, s.zapata05outlook.com

Trabajo de Grado presentado para optar al título de Ingeniero de Sistemas

Asesor: Carlos Arturo Castro Castro, Magíster (MSc) en Geoinformática

Claudia Elena Durango Vanegas Doctor (PhD) en ingeniería – sistemas

Universidad de San Buenaventura Colombia

Facultad de Ingenierías

Ingeniería de Sistemas

Medellín, Colombia

2018

Citar/How to cite [1]

Referencia/Reference

Estilo/Style:

IEEE (2014)

[1] J. C. Vanegas Cerra, y S. Zapata Uribe, “Ingeniera del software aplicada al

desarrollo de aplicaciones con realidad aumentada.”, Trabajo de grado Ingeniería

de Sistemas, Universidad de San Buenaventura Medellín, Facultad de

Ingenierías, 2018.

Semillero de investigación en ingeniería del software y áreas relacionadas (SISUSBMED).

Línea de investigación en ingeniería del software.

Bibliotecas Universidad de San Buenaventura

Biblioteca Fray Alberto Montealegre OFM - Bogotá.

Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.

Departamento de Biblioteca - Cali.

Biblioteca Central Fray Antonio de Marchena – Cartagena.

Universidad de San Buenaventura Colombia

Universidad de San Buenaventura Colombia - http://www.usb.edu.co/

Bogotá - http://www.usbbog.edu.co

Medellín - http://www.usbmed.edu.co

Cali - http://www.usbcali.edu.co

Cartagena - http://www.usbctg.edu.co

Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/

Revistas - http://revistas.usb.edu.co/

Biblioteca Digital (Repositorio)

http://bibliotecadigital.usb.edu.co

https://co.creativecommons.org/?page_id=13

https://co.creativecommons.org/?page_id=13

TABLA DE CONTENIDO

RESUMEN ....................................................................................................................................... 6

ABSTRACT ..................................................................................................................................... 7

I. INTRODUCCIÓN ........................................................................................................................ 8

II. PLANTEAMIENTO DEL PROBLEMA .................................................................................. 10

A. Estado del arte ....................................................................................................................... 11

B Antecedentes ........................................................................................................................... 12

III. JUSTIFICACIÓN ..................................................................................................................... 18

IV. OBJETIVOS ............................................................................................................................ 19

A. Objetivo general .................................................................................................................... 19

B. Objetivos específicos ............................................................................................................. 19

V MARCO TEORICO ................................................................................................................... 20

VI METODOLOGÍA ..................................................................................................................... 22

VII RESULTADOS ....................................................................................................................... 23

A.Feature driven development ................................................................................................... 24

1) Procesos .............................................................................................................................. 25

2) Develop an Overall Modell (Desarrollar un Modelo General) ........................................... 25

a) Build a Feature List (Construir una lista de características) .......................................... 26

b) Plan By Feature (Planear por características) ................................................................ 27

c) Design By Feature (Diseño por característica) .............................................................. 27

d) Build By Feature (Construcción por característica) ....................................................... 28

3). Reporte de avances de las tareas ........................................................................................ 29

4) Iteraciones de la metodología FDD .................................................................................... 29

5) Mejores practicas ................................................................................................................ 29

B) Arquitectura de software ....................................................................................................... 30

1) Requerimientos mínimos para desarrollo ........................................................................... 30

2) Requerimientos mínimos para ejecución de aplicaciones .................................................. 30

3) Adaptación de patrón de arquitectura ................................................................................. 31

4) MVC (Model-View-Controller) ......................................................................................... 31

a) Capa modelo (Model) .................................................................................................... 32

b) Capa vista (View) .......................................................................................................... 32

c) Capa Control (Controller) .............................................................................................. 32

5) MVAC (Model-View-Animation-Controller) .................................................................... 32

a) Modelo (Model) ............................................................................................................. 33

b) Vista (View) ................................................................................................................... 33

c) Animación (Animation) ................................................................................................. 33

d) Capa Control (Controller) .............................................................................................. 33

6) Ventajas de la implementación MVAC .............................................................................. 34

7) Esquema del patrón MVAC ............................................................................................... 35

8) Diagrama de secuencia MVAC .......................................................................................... 36

9) Comunicación de las capas ................................................................................................. 36

a) Definir el orquestador .................................................................................................... 37

b) Instanciado de objetos .................................................................................................... 37

c) Ejemplo .......................................................................................................................... 37

REFERENCIAS ............................................................................................................................. 39

LISTA DE FIGURAS

Fig. 1. Continuo virtual de Milgram .............................................................................................. 11

Fig. 2. Marcador de matriz 2D. ...................................................................................................... 13

Fig. 3. Aplicación ideada por Kalkusch et al. ................................................................................ 14

Fig. 4. Ejemplo de marcador 3D .................................................................................................... 15

Fig. 5. ARhrr! Primer videojuego con gráficos comerciales .......................................................... 16

Fig. 6. Patente del sensorama simulator ......................................................................................... 16

Fig. 7. Espada de Damocles ........................................................................................................... 17

Fig. 8. Head-up display .................................................................................................................. 21

Fig. 9. Diagrama de flujo: Develop an overall model .................................................................... 26

Fig. 10. Diagrama de flujo: Build a Feature List ........................................................................... 26

Fig. 11. Diagrama de flujo: Plan By Feature .................................................................................. 27

Fig. 12. Fiagrama de flujo Desing By Feature ............................................................................... 28

Fig. 13. Diagrama de flujo Build By Feature ................................................................................. 28

Fig. 14. MVC ................................................................................................................................. 32

Fig. 15. MVAC ............................................................................................................................... 34

Fig. 16. Adaptación del patrón MVAC .......................................................................................... 35

Fig. 17. Diagrama de secuencia MVAC ........................................................................................ 36

Fig. 18. Ejemplo instancia e inicialización de objetos ................................................................... 37

INGENIERIA DEL SOFTWARE APLICADA AL DESARROLLO DE APLICACIONES CON REALIDAD A… 6

RESUMEN

La realidad aumentada (RA o AR por sus siglas en inglés) es el sistema que consiste en el aumento

de la percepción de la realidad mediante la implementación de elementos virtuales. La adaptación

del modelado de objetos en tercera dimensión (3-D) al modelo de ingeniera del software tradicional

requiere de la implementación de una metodología, que para este caso sea bajo los procesos de

Feature Driven Development permitiendo iteraciones agiles. La ingeniería de software que se

aplica en el desarrollo de realidad aumentada es principalmente para entornos móviles. Sin

embargo, esta adaptación de métodos tradicionales carece aplicabilidad para estos tipos de

desarrollo, porque se trabaja en modelos agiles y en pruebas basadas en Mobile-D, creando

aplicaciones con requisitos que corren en ambientes inestables. El desarrollo de aplicaciones de

realidad aumentada es llevado a cabo por métodos y modelos sin estandarizar, por este motivo se

quiere implementar una ingeniería del software para garantizar las buenas prácticas en el desarrollo

de aplicaciones.

Palabras clave: Realidad aumentada, FDD, MVC, Arquitectura de software, Unity 3D.


ABSTRACT

Augmented reality (RA or AR for its acronym in English) is the system that consists of increasing

the perception of reality through the implementation of virtual elements. The adaptation of the

model of objects in third dimension (3-D) to the traditional software engineering model requires

the implementation of a methodology, which for this case is under the development processes

oriented to allow agile iterations. The software engineering that is applied to the development of

augmented reality mainly in mobile environments. However, this tool can be used in Mobile-D,

creating applications with requirements for corporate environments. The development of

applications of augmented reality was carried out by methods and models without standardizing,

for this reason it is wanted to implement a software engineering to guarantee good practices in the

development of applications.

Keywords: augmented reality, FDD, MVC, Software architecture, Unity 3D.


I. INTRODUCCIÓN

En la última década se evidencia un crecimiento exponencial de las invenciones tecnológicas con

el objetivo de facilitar la vida del ser humano y de proveer diversión. Esta situación, genera la

necesidad de adquirir nuevos conocimientos y de familiarizarse con los recientes dispositivos y

aplicativos, que son producto de esta ola tecnológica. Una muestra de esto son las aplicaciones de

realidad aumentada (RA), las cuales traen consigo una serie de cuestionamientos como ¿Qué es la

realidad aumentada? ¿Qué aplicaciones tienes la RA? ¿Qué software o herramientas son utilizadas

en la programación con RA? Para tratar de dar respuesta a estas preguntas se plantea este

documento, ofreciendo una perspectiva y análisis de la realidad aumenta.

La realidad aumentada consiste en mezclar componente de un mundo virtual con el mundo real,

existen diferentes usos de la realidad aumentada como la publicidad, cine entre otras, siendo esta

última el ejemplo más claro, en las películas de ciencia ficción utilizan fondos verdes o puntos de

referencia en los cuales son adaptados los componentes creados por computador, actualmente suele

confundirse la realidad aumentada con la realidad virtual (RV), pero son muy diferentes, la RA ya

fue definida con anterioridad, así que falta por definir el concepto de realidad virtual el cual consiste

de crear un mundo virtual en el que el usuario se sumerge, pero no tiene interacción que el mundo

real.

Como objetivo esencial de este proyecto se tiene la creación de contenidos interactivos con realidad

aumentada (RA) con fácil visualización en dispositivos móviles dando valores agregados a la

publicidad del programa de ingeniería de sistema en la Universidad de San Buenaventura seccional

Medellín como primer paso y como segundo, dar pie al inicio de un nuevo semillero donde se de

estudio a un tema que está notable crecimiento en la actualidad como lo es la realidad aumentada

y del cual sabemos tan poco en la universidad. Así mismo, poder aplicar el ciclo de vida a cada

uno de los contenidos desarrollados, documentando sus fases de requisitos, desarrollos y

validaciones en tu etapa final.

De igual manera, un objetivo del documento actual es realizar una investigación del estado del arte

de la RA móvil, enfatizando principalmente los dominios y algunas de las aplicaciones que han


sido desarrolladas en este campo, mostrando los prototipos y todo lo que se ha evolucionado hasta

la fecha.

DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 10

II. PLANTEAMIENTO DEL PROBLEMA

La realidad aumentada (RA) es un procedimiento de visualización que logra mezclar información

o componentes virtuales sobre escenarios reales; esta incorporación de información se logra

visualizar mediante un monitor, posterior a que el sistema interpreta la información recibida por la

cámara y procesa los componentes virtuales creados previamente, obteniendo una sincronización

a través de marcas o patrones (para este proyecto, serían los códigos QR). Dichas marcas, suelen

ser imágenes en la escala de grises que le orientan al sistema por medio de una cámara, la ubicación

y visualización de donde se debe de desplegar la información[1].

Esta tecnología que se encuentra en su punto de esplendor se ha visto en funcionamiento gracias a

diversas aplicaciones, como lo es el Pokémon Go. Pero el logro de esta propuesta de

investigación radica en cómo se desarrollan estas aplicaciones, lo que plantea el reto de empezar a

manejar nuevas herramientas y patrones de programación, herramientas tales como ARTTollKit,

una librería diseñada para el uso de aplicaciones de realidad aumentada que maneja algoritmos de

visión computacional para realizar cálculos de posición y orientación según el Ángulo de la cámara

en tiempo real. OsgART, una biblioteca que simplifica bibliotecas de diseño basándose en los

objetos de videos, patrones y registros fotométricos. FLARManager, SLARToolkit, D-Funsion,

ZooBurst o Unity, Este último será utilizado para el desarrollo de las aplicaciones gracias a la

facilidad de poder mezclar código C#[2].

En el semillero de investigación se han desarrollado aplicaciones con realidad aumentada, pero de

una forma desorganizada y sin un patrón de arquitectura claro, lo cual no proporciona eficacia en

su desempeño haciéndolas pesadas y difícil de entender. Estos contenidos tienen un gran campo de

aplicabilidad como video juegos, arquitectura publicidad entre otros, donde la universidad de San

Buenaventura seccional Medellín y la facultad de ingeniería puede aprovechar para generar

proyectos que incentiven los decesos de aprender de los estudiantes y posibles estudiantes de

ingeniería, adicionalmente apoyar el reconocimiento que posee la universidad en la industria.

Con base en lo anterior, surgen unos interrogantes ¿Qué metodología puede ser utilizada en el

desarrollo de contenidos con RA? ¿Qué arquitectura de software y hardware se pueden utilizar?


A. Estado del arte

En la actualidad, el entorno que rodea al ser humano es complejo y provee información constante

y abundante que al provenir en la misma dirección y tiempo se torna complejo de descifrar y

manipular, es por eso, que los ambientes modelados bajo el campo de la realidad virtual llegan a

ser simples, pero carecen de información referente al entorno. Y es ahí cuando entra la realidad

aumentada con una de sus ventajas, y es que el entorno, que es rico en información no presenta

alteración alguna, por el contrario, éste se enriquece retroalimentando el ambiente que se desea

reproducir.

No hay definición única sobre el campo de la Realidad Aumentada, aunque a través del tiempo han

surgido diversas definiciones en numerosas publicaciones. Una de ellas es Milgram, la cual plantea

y define a la Realidad Aumentada referente a un esquema, denominado continuo de Milgrana. Ver

Fig. 1. Un ambiente virtual se considera como algo enteramente artificial en el que los usuarios

están completamente sumergidos; el ambiente real se considera la parte opuesta, integrado

exclusivamente por los objetos reales limitado por las leyes de la física.

Fig. 1. Continuo virtual de Milgram

Tomado de:[3, p. 3]

Cuando el sistema programado se halla más en la parte central del continuo se torna arbitrario ya

que no se especifica cual es el entorno que predominará sobre el otro. Nótese que la Realidad

Aumentada se ubica más cerca del ambiente real y físico que para el entorno virtual y esto se puede

entender de manera que la RA es una extensión o complemento del mundo real, solo que con

valores agregados (objetos virtuales) para su mejoramiento.


Por otro lado, se tiene AZUMA[4], como segunda publicación referente a la Realidad Aumentada

en el año de 1993 la cual, identifica características fundamentales para la misma dando una

definición propia de un sistema de Realidad Aumentada sin la necesidad de determinar (por ahora)

un Hardware específico:

En un sistema de RA debe combinar realidad y virtualidad.

Un sistema de RA debe de ser interactivo en tiempo real.

Implementación de objetos en 3D.

La última definición que brinda AZUMA representa un constante problema en la Realidad

Aumentada (RA), y es que los objetos virtuales en 3D deben mostrarse obligatoriamente alineados

a los objetos del entorno físico. Pero para AZUMA, es solo un problema básico y es por esto por

lo que propone el “seguimiento basado en reconocimiento de patrones a través de marcadores”[4,

p. 9] para proporcionar niveles de precisión.

B Antecedentes

La presente sección posee como objetivo realizar una pequeña reseña a retrospectiva sobre la RA.

Este pequeño resumen ha sigo extraído de History of mobile augmented reality[5].

Sutherland [6] para el año de 1968 se da inicio al primer sistema de Realidad Virtual, utilizando

como concepto primario el HDM de la mano de diversos mecanismos para la obtención de los

seis grados de libertad, tal y como son: un tracker mecánico y un software de seguimiento

mediante el ultrasonido. A causa del bajo nivel de los procesadores de la época, solo se podían

visualizar dibujos sencillos creados en máquina.

Caudell y Mizell referencian el termino “Realidad Aumentada” para el año de 1992. Dicho

termino se empleo para hacer referencia al hecho de añadir información procesada y

reproducida por ordenador en tiempo real. Caudell y Mizell dieron los planteamientos

preliminares al mundo de ventajas que poseía la AR (Realidad aumentada) contra lo que se

tenia en referencia a la VR (Realdad Virtual)[7].


Para 1992, el gigante de procesadores IBM lanza al mercado el primer Smartphone con

aproximaciones a las primeras imágenes en pantallas. Los comunicadores de IBM dieron los

datos que para la época resultaron un significativo avance para las tecnologías puesto que dicho

teléfono contaba con 1 Megabyte de memoria y una pantalla a blanco y negro con 160x293

pixeles de resolución.

Para 1994, Milgram y Kishino publican su “Taxonomía de la Realidad Mixta”[3] o más

conocido como el continuo de Milgram (Reality-Virtuality Continuum). Manifiesto donde se

describen las relaciones con el mundo real y el virtual, con el paso de ambas etapas y sus

aspectos significativos para el avance de las investigaciones de la RA.

Para 1995, Rekimoto y Katashi lanzan NaviCam. NaviCam[8] contaba con la interface de

trabajo con la incorporación de una cámara para el seguimiento de posiciones ópticas. NaviCam

consistían en la detección de marcadores previamente codificados en el recepto de imagen del

dispositivo permitiendo visualizar las secuencias en el video.

Rekimoto[8] presenta en 1996 los targets de matriz 2D (cuadros predeterminados codificados),

ver figura 2, convirtiéndose en uno de los pioneros en términos de targets permitiendo de esa

forma la interacción entre cámara y dispositivo con grados de movimiento amplios.

Fig. 2. Marcador de matriz 2D.

En 1997, Ronald Azuma da a conocer los avances para la Realizad Aumentada, Azuma

enumera los aspectos de mayor relevancia, enunciando sus características: la combinación de

una escena real con objetos, la interacción en tiempo real y el aumento de la imagen a 3D.

Kato y Billinghurst presentan ARToolKit[9] para el año de 1999, convirtiéndose en una librería

de seguimiento con los 6 grados de libertan enunciados en investigaciones pasadas, utilizando


códigos prediseñados y una plantilla para el reconocimiento. ARToolKit se diseña y se basa en

el libre pensar del código abierto bajo la licencia GPL.

En la llegada del año 2000, Julier et al. Saca al mundo, tanto tecnológico como comercial BARS

(Battlefield Augmented Reality system)[10]. Sistema baso en el uso de HDM con conexión a

periféricos utilizando un receptor GPS con la compañía de acelerómetros para la presentación

visual de datos previamente obtenidos por el sistema. BARS tenia como objetivo la simulación

de escenarios de combate, tal y como eran las estructuras y demás representaciones del campo

de batalla.

En el año 2001 se presentan AR-PDA[11], como un pre aplicativo para la creación de sistemas

RA. La idea básica de PDA era la de interactuar en ambientes de hogar.

Para el mismo año, Reitmayr y Schamaslteig presenta un aplicativo de realidad aumentada con

la opción de ser multiusuario y de trabajo compartido, semejante a la hoy llamada nube. La

idea de dichas mejoras a los aplicativos de la nueva generación era la de compartir espacios

virtuales[12].

En 2002, se saca al mercado una aplicación para cuya idea era la ida del usuario mediante

códigos preestablecidos en el interior de una edificación simulando estructuras en 3D. El

aplicativo se basaba en la funcionalidad HDM[13]. Para el momento de este aplicativo, se hace

el uso de las librerías de código libre ARToolKit, como aparece en la Fig. 3.

Fig. 3. Aplicación ideada por Kalkusch et al.

Tomado de:[13, p. 1]


En 2004 se introduce un sistema para el posicionamiento con targets para la visualización de

figuras diseñadas en 3D mediante la simulación ver Fig. 4., soportando la detección de figuras

y la integración de gráficos 3D en pantallas mediante video[14].

Fig. 4. Ejemplo de marcador 3D


Visual Codes fue presentado por Rohs y Gfeller, consistía en ser un sistema de targets 2D para

teléfonos móviles. Estos targets podrían ser utilizados con objetos físicos y tangibles para

superponer información[15].

ARToolKit se convirtió para el 2005 en uno de los sistemas/librerías mas usados y

referenciados para la realidad aumentada, puesto que era el complemento encajable con

dispositivos que se desarrollaban en la época y su licencia de código ágil. ARToolKit migro a

Symbian, para dar comiendo a AR-Tennis[16], para convertirse en la primera aplicación para

teléfonos celulares.

“2006. Reitmayr et al. presentan un modelo basado en un sistema de seguimiento híbrido de

RA en entornos urbanos. Esto permite tomar, en tiempo real, captura de vídeo sobre en un

dispositivo tipo PDA” [17, p. 50].

Con el éxito en los aplicativos móviles, Mobilizy lanza Wikitude[18], con el objetivo de

combinar el GPS y la brújula digital para mostrar datos sobre espacios con marcadores

prediseñados.

ARhrrr![19] ver Fig. 5., el primer videojuego de realidad aumentada involucrando gráficos de

la nueva generación. Esta aplicación utiliza el kit de desarrollo Tegra de Nvidia, optimizado

para las GPU. Todo el procesamiento se realiza en la GPU.


Fig. 5. ARhrr! Primer videojuego con gráficos comerciales

Tomado de:[19]

Morton Heilig se conoce como el “padre de la realidad virtual” por sus investigaciones e inventos

en los años 50 y 60. Fue él quien patentó el sensorama simulator ver Fig. 6, al cual llamo una

“experiencia de cine”, el 28 de agosto de 1962 [20].

Fig. 6. Patente del sensorama simulator

Tomado de: [20, p. 26]

En 1968, el informático y profesor de Harvard Ivan Sutherland, junto con su alumno Bob Sproull,

inventan “La espada de Damocles”[21]. Ver Fig. 7.


Fig. 7. Espada de Damocles

Tomado de: [6, pp. 759–760]

La espada de Damocles fue el primer sistema de visualización de realidad aumentada directamente

en la cabeza mientras éste se encontraba suspendido en el techo, el espectador experimentaba

gráficos alimentados por un ordenador – a Sutherland se le conoce como el “Padre de los

gráficos”[22].

El siguiente gran avance se dio en los años 1990, año en el que el investigador Tom Caudell

referencio la “Realidad Aumentada” como termino oficial al tipo de tecnología surgente y el

Australiano Julie Martin adapto dicha tecnología a la televisión. Para el año de 1997, Ronald t.

Azuma en su publicación “"A Survey of Augmented Reality” indago sobre las diferentes

aplicaciones de la misma en diferentes campos, tal y como fueron la medicina, elaboración de

productos, la investigación y los avances en el tema de la indagación matemática. Para la década

de los 2000, Hirokazu Kato saca su creación llamada ARToolKit, la cual empleaba la combinación

de gráficos virtuales con la imagen de la vida real, que a su vez utilizaban el rastreo de imagen y

video para la superposición de gráficos con la mezcla de ordenadores y elementos de videos [23].


III. JUSTIFICACIÓN

Dentro de la universidad de San Buenaventura seccional Medellín, en el programa de Ingeniería

de Sistemas, existe una escasez en el conocimiento del desarrollo de contenido con realidad

aumentada. La actualización en conocimientos, herramientas y software en la ingeniería de

sistemas es algo inherente a su ser, por lo cual se ve la importancia de asignar un proyecto de

investigación en esta nueva tecnología que beneficiaran a los próximos estudiantes ofreciéndoles

unas bases sobre las cuales se pueden apoyar para adentrarse en este nuevo conocimiento.

El ser humano siempre busca la manera de crear nuevas opciones que le permita adquirir nuevos

conocimientos y les facilite la vida. Es aquí donde la realidad aumentada se ha posicionado como

una buena opción debido a su amplio campo de uso, desde lo comercial donde se permite ver el

objeto que desea comprar y plasmarlo o visualizarlo en el espacio que desee ofreciendo una

perspectiva mejor para ayudar al cliente a tomar la mejor decisión; hasta en la educación, donde se

podría mostrar en mejor detalle cosas tales como los sistemas nerviosos, motores, piezas,

arquitecturas, etc. Estas pueden ser difícil de imaginar solo con ver una ilustración en un libro, o

pueden ser muy costosas de adquirir, para lo cual la realidad aumentada ofrece una alternativa más

económica y de fácil transporte al momento de mostrar prototipos, por ejemplo, un motor, el diseño

de una casa o un prototipo de maquinaria industrial, entre otros. La modelación de estos objetos 3d

podrá ser visualizada prometiendo una experiencia más interactiva y de esta forma una mejor

comprensión de lo que se desea transmitir. La realidad aumenta es un tema que permea muchos

campos de la ingeniería, por ejemplo, la ingeniería de sistemas, sonido, multimedia e industrial. Y

el poseer unas bases sólidas en esta nueva tecnología permitiría una integración de las diferentes

ramas de la ingeniería para desarrollar contenidos que apoyen el proceso de educación o enseñanza.


IV. OBJETIVOS

A. Objetivo general

Implementar prácticas de la ingeniería del software aplicadas en el desarrollo de aplicaciones

interactivas con realidad aumentada.

B. Objetivos específicos

Definir los componentes característicos de la realidad aumentada que permitan diferenciarla de

la realidad virtual.

Proponer una metodología ágil para el diseño y desarrollo de aplicaciones de realidad

aumentada que faciliten el proceso de ingeniería del software.

Plantear una arquitectura de software y hardware adecuadas para la implementación contenidos

de diferentes dominios de realidad aumentada.

Desarrollar contenidos interactivos con tecnologías de la realidad aumentada para diferentes

dominios de aplicación.


V MARCO TEORICO

La realidad aumentada y la realidad virtual son términos muy usados en la actualidad, pero sus

inicios se remontan a 1956 cuando Morton Heilig realiza la primera aproximación a una realidad

virtual(VR, por sus siglas en inglés), diseñando un simulador de motos que llamó “Sensorama”[20],

este estaba compuesto por una pantalla y otros elementos del mundo real tales como movimientos

del asiento, vientos, olores y sonidos que ofrecía recrear eventos lo más real posible, pero a este le

hacía falta la interacción con el usuario. Ya en 1968 Ivan Sutherland inventa las gafas de realidad

virtual (head mounted display o HMD)[6] este dispositivo incluía una parte visual, auditiva y un

sistema de cables que permiten la interactividad del usuario con el sistema y viceversa[24].

La realidad aumentada (AR, por sus siglas en inglés) es una derivación de la realidad virtual(VR),

esta última sumerge por completo al individuo en un entorno virtual aislándolo del mundo real que

se encuentra a su alrededor, por otra parte, la AR toma todo lo diseñado virtualmente y lo sobrepone

en el mundo real, ya sea imágenes 2D o 3D, sonidos y videos creando una interacción en tiempo

real, en otras palabras, es el equilibrio o punto medio entre lo sintético y lo real, de hecho esto es

apreciable en los HUD (Head-up display) utilizado por los pilotos de combate donde les muestra

información del mundo real como la velocidad y distancia mientras continúa viendo por la

ventana[25]. Ver fig. 8.


Fig. 8. Head-up display

Tomado de:[25]

Para ser considerada como realidad virtual debe cumplir 3 características esenciales:

Combinación de la información virtual y real.

Interactividad en tiempo real.

Fusionar y usar entornos de 3D.

La Realidad Aumentada (RA) es la línea de exploración que incluye información generada por

computadoras al ámbito realista. Este pequeño razonamiento es lo inverso a la Realidad Virtual

(RV), ya que en la RV hay exclusivamente información virtual. Estos dos campos, aunque difieren

en definición aciertan en el objetivo final, y es el de presentar información al usuario final.

Durante las últimas décadas, esta visión artificial del mundo físico – conocida como realidad

aumentada – maduró desde el juguete de un científico a ser parte de la vida diaria. La realidad

aumentada hace énfasis en una vista compuesta o falsa del mundo simulado por imágenes

proyectadas por un ordenador en tiempo real.


VI METODOLOGÍA

Es una investigación aplicada en la cual se pretende definir un marco referencial que permita

emplear la ingeniería del software en el desarrollo de aplicaciones de realidad aumentada utilizando

la metodología ágil: Feature Driven Development (FDD), con la cual se podrá ir realizando ajustes

de una forma más fácil aplicando el ciclo de vida del software.

Se pasará por el proceso de elicitación de requisitos, donde quedara evidenciado que el

levantamiento de los mismo no se hace de una forma tradicional (sistemas de gestión de

información), por lo cual mediante la ayuda y libertad que nos brinda FDD daremos nuevas técnicas

y caminos para la obtención de estos.

La arquitectura o diseño de las aplicaciones es algo en lo que se planteara un modelo de

construcción que permita garantizar un orden en el contenido de los diferentes objetos usando el

desarrollo, para este proceso, se realizara la adaptación de la clásica metodología de programación

MVC (Modelos – Vista – Controlador) permitiendo tener un manejo más claro de los objetos 3D

y sus funciones internas en relación con el usuario.

Se llevará a cabo el proceso de pruebas unitarias, analizado los estándares de verificación y

validación del software existente. Una vez más, FDD nos proporcionara total libertad para realizar

las pruebas unitarias, puesto que esta metodología no es estricta en cuanto a pruebas. Al ser una

metodología ágil con procesos de interactividad está en continua supervisión de código, esto

brindara mayor facilidad para experimentar nuevos métodos de testeo en referencia a los objetos

de realidad aumentada.

En la metodología se establecen las perspectivas de investigación, esto es, cuantitativo, cualitativo

o mixto.


VII RESULTADOS

Se obtuvo mediante un proceso de análisis en referencia entre la tecnología de realidad aumentada

y realidad virtual, permitiendo realizar los objetivos que se encontraban sujetos a la realidad

aumentada, lo cual ofreció un campo más amplio para la aplicación de la metodología de desarrollo

ágil y una arquitecta se fuera basada en el modelo, vista, animación y controlador. FDD es una

metodología que está siendo implementada por primera vez en proyectos del seminario de

ingeniera de software, y es algo totalmente diferente a la construcción software tradicional. Con

FDD se cuenta con una metodología que permite la aplicación de manera correcta del ciclo de vida

del software con la permitividad de realizar cambios de último momento y la libertad de aplicar

adicionalmente el proceso de elicitación y pruebas.

El modelo vista-modelo-control es un modelo tradicional para programar en la ingeniería de

sistemas, exista la intención de hacer la integración de este modelo tradicional a los sistemas de

realidad aumentada, con la integración de la capa animación que sería una nueva capa, trabajando

con el nuevo sistema modelo-vista-animación-controlador (MVAC). El haber realizado la

adaptación de una arquitectura basada en un modelo de programación tradicional nos permitió

controlar de manera más precisa la realidad aumentada y hacerle una adaptación al área de

ingeniera de sistemas y todo lo relacionado al ciclo de vida del software. MVAC garantiza un

nuevo modelo de desarrollo en base a parámetros que aseguran el manejo de datos a través de capaz

en donde sus modificaciones se hacen mucho más fáciles con relación a un futuro.

Otros resultados que están ligados al proyecto es la participación en el Join del 2016 representando

al semillero en la calidad de expositores con poster. Para el año 2017 la participación en las jornadas

de investigación formativa en ingeniería, esta vez como expositor invitado a conferencias el

estudiante Juan Carlos Vanegas, además la inclusión del tema de investigación en la primera

edición del libro: “Investigación Formativa en ingeniería” mediante la realización de un artículo

con el título: “Metodología FDD y arquitectura MCV adaptada al desarrollo de realidad

aumentada”. De manera adicional la participación en RedColsi regional donde Juan Carlos fue

encargado de realizar la exposición del tema de investigación y la participación en RedColsi a nivel

departamental que se realizó en la ciudad de Barranquilla por parte de Sebastian Zapata.


A.Feature driven development

FDD (Feature Driven Development) o (Desarrollo basado en funcionalidades en español) es un

enfoque ágil para el desarrollo de sistemas. Fue diseñada por Jeff De Luca y el gurú de la

programación orientada a objetos Peter Coad. FDD podría ser considerada como un camino medio

entre RUP y XP. Como las metodologías adaptables, se enfoca en iteraciones cortas que entregan

funcionalidad tangible, dichas iteraciones llegan a pasar de más de 2 semanas y son decididas en

base a las features, que son pequeñas partes del software con significado para el cliente. FDD no

muestra un énfasis en el levantamiento de requerimientos, dejando esta parte al libre uso y libre

metodología del desarrollado, caso contrario a las fases de diseño y construcción. Además, hace

énfasis en aspectos de calidad durante todo el proceso en incluye un monitoreo permanente del

avance del proyecto[26].

FDD consta de cinco procesos: Develop Overall Model (Desarrollar el modelo global), Build by

feature (Construir una lista de características), Plan by feature (Planificar), Desing by features

(Diseñar), Build by features (construir). Los tres primeros procesos ocupan gran parte del tiempo

en las primeras iteraciones, siendo las dos últimas las que ocupan mayor tiempo según se da el

avance del proyecto, limitando las primeas a un proceso de refinamiento.

El trabajo (modelamiento/desarrollo) se ejecuta en equipos previamente conformados, pero

siempre habrá un responsable último (según la fase), el cual será el que posea más experiencia y

tendrá la última palabra en cuento a la entrega. Al hacer los modelamientos y desarrollos en grupos

se consigue que todos conformen el proyecto[26].

Las funcionalidades que implementa en una release se dividen entre los distintos subgrupos del

equipo, y se analizan para su debida implementación. Las clases escritas poseen un propietario

(integrante del proyecto), es por ello por lo que quien implementa una funcionalidad debe estar con

los dueños de la clase implicada.

En el proceso de implementar la funcionalidad, también se contempla como parte de este proceso

la preparación y ejecución de pruebas, así como revisiones de código e integración de componentes.


Cabe aclarar que la metodología FDD no hace énfasis en el cómo se debe llevar a cabo el proceso

de pruebas, al igual que el proceso de licitación de requisitos[27].

1) Procesos

Feature Driven Development consta de 5 procesos secuenciales, durante las cuales el diseño e

implementación del sistema entran en etapa de construcción de manera iterativa[28].

2) Develop an Overall Modell (Desarrollar un Modelo General)

Cuando la fase de predesarrollo comienza, los expertos de cada dominio ya poseen un dibujo claro

del contexto entrado en los requisitos preliminares. Es probable que el documento de especificación

de requerimiento ya exista y esto se debe al cliente. Cuando la fase comienza, los expertos en cada

dominio ya poseen una idea clara del contexto y los requisitos del sistema. Sin embargo, FDD no

hace énfasis en la recolección y administración de los requerimientos. Los expertos del dominio a

tratar se encargan de presentar un informe o vista global llamado walkthrough en el cual los

miembros del equipo y el Chief Arquitect son informados a través de una descripción de alto nivel

del sistema.

El dominio global es dividido en diversas áreas y se realiza un walkthrough para cada una de ellas.

Inmediatamente finalizan los walkthrough, los equipos asignados para el desarrollo tienen como

tarea la modelación de una estructura en referencia al área de dominio. A su vez, el equipo de

desarrollo argumenta y se base en la mejor decisión de saber cuál es el modelo más apropiado.

Simultáneamente, el modelo global del sistema es construido.


Fig. 9. Diagrama de flujo: Develop an overall model

Tomada de: [29, p. 106]

a) Build a Feature List (Construir una lista de características)

Los walkthroughs, los modelamientos de estructura para los dominios y los requisitos del sistema

existentes ofrecen una buena base para construir una features list que contenga de manera resumida

la funcionalidad del sistema a ser desarrollado. Las listas de planeación para posterior desarrollo

por características serán evaluadas en referencia a cada función presentada por el cliente. Las

funcionalidades son presentadas por cada área del dominio y estas forman un Mejor List Sets.

Dicha lista es dividida en subconjuntos en base a la funcionalidad.

Fig. 10. Diagrama de flujo: Build a Feature List



b) Plan By Feature (Planear por características)

En esta etapa se incluye la creación de un plan de alto nivel, en el cual la features list es ordenada

en base a la prioridad y a la dependencia entre cada feature. Además, las clases identificadas en la

primera etapa son asignadas a cada programador.

Fig. 11. Diagrama de flujo: Plan By Feature


c) Design By Feature (Diseño por característica)

Una seria de características están programadas para el desarrollo y se encuentra asignadas a un

Cheif programmer. El Cheif Programmer selecciona las features para el desarrollo de su bandeja

de entrada de features asignadas. Operacionalmente es habitual que el Cheif Programmer programe

un pequeño grupo de características a la ves para el desarrollo. Este grupo de características forman

paquete de trabajo. El Cheif Programmer forma entonces un equipo de características identificando

a los propietarios de las clases (desarrolladores) que probablemente estarán involucrados en el

desarrollo de las características seleccionadas. El Cheif Programmer luego refina el modelo de

objeto basado en el contenido del diagrama de secuencias. Los desarrolladores escriben prólogos

de clase y método. Se lleva a cabo una inspección de diseño.


Fig. 12. Fiagrama de flujo Desing By Feature


d) Build By Feature (Construcción por característica)

Se trabaja desde el paquete de diseño producido durante el proceso anterior (Desing By Features),

los propietarios de clases implementan los elementos necesarios para que su clase soporte el diseño

de las funciones de trabajo. El código desarrollado es entonces probado en unidad y se hace una

inspección, en un orden de prioridad según las instrucciones es del Chief Programmer. Después de

una inspección de código exitosa, el código entra en proceso de construcción.

Fig. 13. Diagrama de flujo Build By Feature



3). Reporte de avances de las tareas

La reunión entre el Release Manager y los Chief Programmers tiene como objetivo el reporte de

avances de las tareas. La duración de dichas reuniones tiene como duración un tiempo máximo de

30 minutos (tiempo similar al de Scrum), cada Chief Programmer informaran en forma de reporte

verbal bueno para que cada uno de los Chief Programmers se tome el tiempo de escuchar a los

otros y saber en que parte de la lista de desarrollo se encuentran los demás, de esta forma, se

coordinaran para saber que Feature tiene prioridad de salida. Al final de la entrevista, el release

manager anota los resultados, actualiza la base de datos y genera los reportes. El release manager

reportara los resultados obtenidos semanalmente, con información para el equipo y a su vez para

el cliente. Tanto clientes como gerentes tendrán un reporte donde se incluya en avance de cada

característica, para el equipo se informa cual es el desempeño de el mismo[30].

4) Iteraciones de la metodología FDD

El tiempo máximo de las características con de 2 semanas. 2 semanas en las que se debe de entregar

un avance considerable a la semana anterior y dichos avances, deben de ser aprobados por Project

manager y Chief architect.

Como su nombre lo dice, las características son un aspecto importante de FDD. Una característica

es un aspecto importante FDD. Una característica es una pequeña función, un valor esperado en l

forma <action><result><object>. Las características son para FDD como casos de usos son para

RUP y las historias de usuario son a Scrum, siendo la fuente primaria de los requisitos y la entrada

principal en sus esfuerzos de planificación[31].

5) Mejores practicas

FDD se basa en un conjunto básico de mejores prácticas de la ingeniería del software, todas ellas

encaminadas a una perspectiva de valor.

Modelado de objetos de domino.


Desarrollo de características.

Clase individual.

Equipo de características.

Inspecciones.

Gestión de la configuración.

Construcción regular.

Visibilidad de avances y resultados.

B) Arquitectura de software

Para iniciar el tema de la arquitectura obligatoriamente hay que tener en cuenta los requerimientos

mínimos para poder desarrollar y ejecutar una aplicación de realidad aumentada, para este caso la

aplicación será desarrollada con unity 3D.

1) Requerimientos mínimos para desarrollo

OS: Windows 7 SP1+, 8, 10; Mac OS X 10.8+.

GPU: Tarjeta gráfica con DX9 (modelo de shader 3.0) o DX11 con capacidades de funciones

de nivel 9.3

Android: Android SDK y Java Development Kit (JDK).

Visual Studio 2013 o versión posterior[32].

2) Requerimientos mínimos para ejecución de aplicaciones

Por lo general, las aplicaciones desarrolladas con Unity se pueden ejecutar o son compatibles con

casi todos los dispositivos, puede presentarse incompatibilidad dependiendo de la complejidad de

cada proyecto, pero podemos mencionar ciertos componentes que podrían garantizarle una mejor

compatibilidad.

Sistema operativo: Windows XP SP2+, Mac OS X 10.8+, Ubuntu 12.04+, SteamOS+.


Android: OS 2.3.1 o posterior; CPU ARMv7 (Cortex) con tecnología NEON o CPU Atom;

OpenGL ES 2.0 o posterior.

iOS player requires iOS 7.0 or higher (dropping 6.0).

Windows Phone: 8.1 o posterior.

WebGL: Cualquier versión de escritorio reciente de Firefox, Chrome, Edge o Safari[32].

3) Adaptación de patrón de arquitectura

La arquitectura de software hace referencia a la organización, interacción y relación de los

diferentes componentes que conforman el software, aplicando principios y normas de diseño para

favorecer la calidad y usabilidad de este, Es un tema muy importante en el desarrollo de software,

ya que esta brinda un cierto grado de estandarización y orden.

Existen diferentes tipos de arquitectura, dentro de las cuales se destaca el patrón MVC (Model-

View-Controller) el cual ha sido ampliamente usado y verificado. Este servirá de base para la

configuración de un nuevo patrón de arquitectura orientado a la programación de aplicaciones de

realidad aumentada MVAC (Model-View-Animation-Controller).

4) MVC (Model-View-Controller)

Este patrón de arquitectura fue descrito por primera vez en 1979 para SmallTalk, desde entonces

ha sido usado por múltiples frameworks como:

Java Swing.

Java Enterprise Edition (J2EE).

XForms.

ASP.NET MVC Framework.

Google Web Toolkit

Este patrón sugiere un desarrollo estructurado, facilitando la programación en tres capas de forma

paralela e independiente.


a) Capa modelo (Model)

El modelo es la representación de los datos en el sistema.

b) Capa vista (View)

En esta capa es donde el usuario interactúa con el sistema, ejemplo de esto son las paginas HTML

que permiten la recepción y entrega de información de una forma dinámica.

c) Capa Control (Controller)

El controlador es el intermediario u orquestador entre la vista y el modelo, acá se realiza todas las

operaciones necesarias para que el sistema tenga un funcionamiento adecuado.

Fig. 14. MVC

5) MVAC (Model-View-Animation-Controller)

Como se había mencionado anteriormente este patrón de arquitectura tiene de base el MVC por lo

cual comparte varias capas que permite tener una estructuración organizada del desarrollo, dado

que el patrón MVC fue pensado para el diseño de software estructurado de una manera general, en

el caso del desarrollo de aplicaciones de realidad aumentada hay un componente adicional y el cual


es necesario tener en cuenta, por tal motivo se hace la una adaptación para agregar una capa más

que es la animación.

a) Modelo (Model)

El modelo es la representación de los datos en el sistema para el caso de las aplicaciones de realidad

aumentada puede que se utilicen bases de datos o no, por lo cual esta capa puede ser opcional.

b) Vista (View)

En esta capa es donde el usuario interactúa con el sistema, acá es donde se encontrará los modelos

3D, terrenos, imágenes, videos y demás componentes visuales.

c) Animación (Animation)

Capa en la que se encapsularán las animaciones que se encuentran representadas por unos archivos.

fbx que le darán la interactividad a la aplicación.

d) Capa Control (Controller)

El controlador es el intermediario u orquestador entre la vista, animación y el modelo, acá se realiza

todas las operaciones necesarias para que el sistema tenga un funcionamiento adecuado.


Fig. 15. MVAC

6) Ventajas de la implementación MVAC

Desarrollo modular lo que permitirá trabajar de forma independiente cada módulo.

El tener una arquitectura definida permitirá tener un estándar en el desarrollo lo que hace que

el desarrollo sea más entendible dado el caso que existan múltiples desarrolladores.

Reutilización de componentes.

Organización de los componentes.

Facilidad al momento de hacer nuevas versiones.

El estar basado MVC que es uno de los patrones más usados y verificado ofrece un punto de

partida con cierto grado de confiabilidad.


7) Esquema del patrón MVAC

Fig. 16. Adaptación del patrón MVAC

En este esquema se puede observar que existe un controlador general (Orquestador) el cual es el

encargado de realizar las comunicaciones y direccionamientos entre los diferentes niveles (escenas,

ventanas o menús), cada nivel contiene las capas del MVAC en su interior estos pueden

desarrollarse de una forma individual, pero con una estructura ya definida para que puedan

interactuar.


8) Diagrama de secuencia MVAC

Fig. 17. Diagrama de secuencia MVAC

La capa controlador es la capa operacional, en esta se llevarán a cabo todo el proceso lógico de los

niveles y permitirá la comunicación con el orquestador.

9) Comunicación de las capas

Para poder aplicar este modelo se tiene que definir un esquema de comunicación donde el papel

principal lo tiene el orquestador, esta comunicación es el resultado de la interacción entre los

(controladores – orquestador) y (orquestador - GameObject). La mayoría de los desarrollos se

hacen por módulos para luego ser unificados por un arquitecto, con el fin de que esta comunicación

se efectiva se deben seguir los siguientes pasos.


a) Definir el orquestador

La persona encargada de unificar los desarrollos debe definir el orquestador (nombre), crear los

métodos necesarios para comunicar los diferentes niveles y a su vez los métodos necesarios para

cumplir requerimientos solicitados. Los desarrolladores deben tener claro el nombre del

orquestador y sus métodos para poder ser instanciado dentro de los controladores de cada nivel.

b) Instanciado de objetos

Para que las capas internas y externas de un modelo se puedan comunicar es necesario definir un

objeto que haga referencia a la capa donde se encuentran los métodos solicitados.

c) Ejemplo

Este es un ejemplo sencillo de direccionamiento en el que se vera la definición del orquestador,

controlador y vista. Esto desde un script que será realizado desde Visual Studio.

Fig. 18. Ejemplo instancia e inicialización de objetos

Para iniciar con la descripción del ejemplo vale la pena explicar que es un GameObject, es un

componente esencial dentro del ambiente de unity, estos pueden almacenar diferentes componentes

como animación, scripts, objetos 3d y demás componentes.


Ahora si se procede con las líneas de códigos:

GameObject ObjMenuPrincipal;

Crea un objeto que hace referencias a un panel (GameObject) que contiene unos botos que

conforman la ventana principal.

GameObject ObjObjetivo1;

Crea un objeto que hace referencia a un canvas (GameObject) que contiene unos objetos 3d

que son asociados a un targets.

CtrMenuPrincipal ObjCtrMenuPrincipal;

Crea un objeto del script controlador del menuprincipal para poder acceder a sus métodos.

ObjMenuPrincipal = GameObject.Find(name: “MenuPrincipal”);

ObjObjetivo1=GameObject.Find(name: “Objetivo1”);

Estas dos líneas de código lo que hacen es instanciar los objetos GameObject los cuales están

siendo buscados por sus nombres.

ObjCtrObjectivo1=GameObject.Find(name:“Objetivo1”).GetComponent<CtrObjetivo

1>();

Esta línea de código está haciendo una instancia del componente CtrObjetivo1 que un script

asociado al GameObject Objetivo1.


REFERENCIAS

[1] T. Lara, Mlearning. Cuando el Caballo de Troya entró en el aula. 2012.

[2] G. Perezbolde, “¿Quieres hacer Realidad Aumentada? Aquí está todo lo que necesitas,”

Revista Merca 2.0, 2013. [Online]. Available: https://bit.ly/2pm2Tkc.

[3] M. Paul and F. Kishino, “a Taxonomy of Mixed Reality Visual Displays,” IEICE Trans. Inf.

Syst., vol. 77, no. 12, pp. 1–15, 2003.

[4] R. T. Azuma, “Billinghurst, Clark, Lee - 2015 - A Survey of Augmented Reality,” pp. 355–

385, 1997.

[5] C. Arth, R. Grasset, L. Gruber, T. Langlotz, A. Mulloni, and D. Wagner, “The History of

Mobile Augmented Reality,” no. May, 2015.

[6] I. E. Sutherland, “A head-mounted three dimensional display,” in Proceedings of the

December 9-11, 1968, fall joint computer conference, part I on - AFIPS ’68 (Fall, part I),

1968, p. 757.

[7] T. P. Caudell and D. W. Mizell, “Augmented reality: an application of heads-up display

technology to manual manufacturing processes,” in Proceedings of the Twenty-Fifth Hawaii

International Conference on System Sciences, 1992, pp. 659–669 vol.2.

[8] J. Rekimoto and K. Nagao, “The world through the computer,” Proc. 8th Annu. ACM Symp.

User interface Softw. Technol. - UIST ’95, no. November, pp. 29–36, 1995.

[9] H. Kato and M. Billinghurst, “Marker tracking and HMD calibration for a video-based

augmented reality conferencing system,” Proc. 2nd IEEE ACM Int. Work. Augment. Real.

(IWAR 99), pp. 85–94, 1999.

[10] S. Julier, M. Baillot, D. Lanzagorta, Brown, and L. Rosenblum, “BARS: Battlefield

Augmented Reality System,” NATO Inf. Syst. Technol. Panel Symp. New Inf. Process. Tech.

Mil. Syst., 2000.

[11] J. Fruend, C. Geiger, M. Grafe, and B. Kleinjohann, “The augmented reality personal digital

assistant,” Proc. 2nd Int. Symp. Mix. Real., no. May 2016, pp. 145–146, 2001.

[12] G. Reitmayr and D. Schmalstieg, “Mobile Collaborative Augmented Reality,” Proc. Int.

Symp. Augment. Real., pp. 114–123, 2001.

[13] M. Kalkusch, T. Lidy, M. Knapp, G. Reitmayr, H. Kaufmann, and D. Schmalstieg,

“Structured Visual Markers for Indoor Pathfinding,” Proc. First IEEE Int. Work. ARToolKit,

p. 8, 2002.


[14] C. Lessig, M. Mathias, and B. Oliver, “Optical Tracking and Video See-Through AR on

Consumer Cell-Phones,” 2004.

[15] M. Rohs and B. Gfeller, “Using Camera-Equipped Mobile Phones For Interacting with Real-

World Objects,” Adv. Pervasive Comput., vol. 176, pp. 265–271, 2004.

[16] A. Henrysson, M. Billinghurst, and M. Ollila, “Face to Face Collaborative AR on Mobile

Phones,” Proc. 4th IEEE/ACM Int. Symp. Mix. Augment. Real. (ISMAR 05), pp. 80–89,

2005.

[17] G. Reitmayr and T. Drummond, “Going Out: Robust Model- based Tracking for Outdoor

Augmented Reality,” Proc. 5th IEEE ACM Int. Symp. Mix. Augment. Real. (ISMAR 2006),

pp. 109–118, 2006.

[18] H. Andreas, “Wikitude World Browser,” 2010. [Online]. Available: https://goo.gl/o9xS4V.

[19] Augmented Reality Lab, “Augmented Environments Lab » ARhrrrr!,” 2010. [Online].

Available: https://goo.gl/2YpuLM.

[20] F. Steinicke, “Being really virtual: Immersive natives and the future of virtual reality,” Being

Really Virtual Immersive Nativ. Futur. Virtual Real., pp. 1–166, 2016.

[21] J. Cruz, J. Rodr, and J. Mart, “Análisis de la Realidad Aumentada en Dispositivos Móviles,”

p. 6, 1998.

[22] C. A. Izquierdo, “Desarrollo de un sistema de Realidad Aumentada en dispositivos

móviles,” Proy. Final Carrera, pp. 1–89, 2010.

[23] J. Shore, Where did augmented reality come from? 2012.

[24] J. D. W. Alan Craig William R. Sherman, Developing Virtual Reality Applications:

Foundations of Effective Design. Morgan Kaufmann, 2009.

[25] G. Kipper and G. Kipper, “Chapter 1 – What Is Augmented Reality?,” in Augmented Reality,

2013, pp. 1–27.

[26] S. D. Amaro Calderón and J. C. Valverde Rebaza, “Metodologías Ágiles,” Esc. Informatica.,

pp. 1–37, 2007.

[27] A. Scott, “Agile Modeling and Feature-Driven Development,” 2003. [Online]. Available:

https://goo.gl/moysjM.

[28] S. Markus, “Feature Driven Development,” Springer Fachmedien Wiesbaden GmbH.

[Online]. Available: https://goo.gl/7NKx65.

[29] S. R. Palmer and J. M. Felsing, A Practical Guide to Feature-driven Development, 1st ed.


Pearson Education, 2002.

[30] R. Campinas, Universidade Estadual D E;Jane, Eleutério;Felipe, Gaia;Genaína

Rodrigues;Cecília, “Dependable Dynamic Software Product Line,” pp. 1–61, 2015.

[31] S. Goyal, “Major Seminar On Feature Driven Development,” p. 22, 2007.

[32] Unity, “Requisitos del sistema para la Unity.” [Online]. Available: https://goo.gl/DHmWnF.

ingeniera del software aplicada al desarrollo de...

Documents