Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
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
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.
INGENIERIA DEL SOFTWARE APLICADA AL DESARROLLO DE APLICACIONES CON REALIDAD A… 7
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.
INGENIERIA DEL SOFTWARE APLICADA AL DESARROLLO DE APLICACIONES CON REALIDAD A… 8
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
INGENIERIA DEL SOFTWARE APLICADA AL DESARROLLO DE APLICACIONES CON REALIDAD A… 9
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?
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 11
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 12
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].
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 13
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
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 14
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]
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 15
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
Tomado de:[14, p. 1]
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 16
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 17
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].
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 18
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 19
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 20
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 21
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 22
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 23
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 24
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 25
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 26
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
Tomado de:[29, p. 135]
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 27
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
Tomado de:[29, p. 146]
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 28
Fig. 12. Fiagrama de flujo Desing By Feature
Tomado de:[29, p. 160]
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
Tomado de:[29, p. 181]
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 29
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 UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 30
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+.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 31
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 32
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
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 33
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 34
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 35
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 36
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 37
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 38
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 39
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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 40
[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.
DESARROLLO DE UN MODELO DE GESTIÓN DE CALIDAD BASADO EN LA NORMA ISO 9001... 41
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.