Testbed de Realidad Virtual para Inteligencia Ambiental (AAL)

Máster Universitario en Ingeniería Informática
2019 - 2020
Trabajo Fin de Máster
“Testbed de realidad virtual para

inteligencia ambiental (AAL)”
Ainara Del Barco Ventura
Tutor/es
Javier Carbo Rubiera
Leganés, 2020
Esta obra se encuentra sujeta a la licencia Creative Commons Reconocimiento - No

Comercial - Sin Obra Derivada
CAPÍTULO 0
RESUMEN
En este trabajo, realizamos una investigación sobre las aplicaciones diversas que pue-
de tener el uso de la Inteligencia Ambiental aplicado al ámbito de la vida asistida (AAL).
Para ello realizamos un estudio de esta tecnología y, dada la necesidad de contar con un
entorno controlado en el que visualizar los resultados, se implementará un entorno de
Realidad Virtual que contará con la implementación del sistema inteligente.
El entorno virtual se desarrollará con la herramienta Unity, y se permitirá al usuario
interactuar con los distintos elementos modelados en el entorno. Se diseñará el sistema
teniendo en mente las necesidades con las que puede contar una persona anciana o con
algún tipo de dependencia, y este reaccionará ante las interacciones o comportamientos
que realice el usuario, dando respuestas que incrementan la calidad de vida del mismo.
Palabras clave: Inteligencia Ambiental, Unity, Realidad Virtual, Vida asistida, AAL,
Ambient Assisted Living, Entorno virtual, Testbed
iii
CAPÍTULO 0
DEDICATORIA
No veía el momento de escribir estas líneas, cuando por fin finalizase el TFM y así,
mi etapa en la universidad. Ha sido duro, sobretodo la última parte del máster que ya la
compaginaba con un trabajo a tiempo completo. ¡Pero lo he conseguido!
Gracias a todos los que me han acompañado en este viaje.
A mi tutor, Javier, por haberme ayudado y guiado durante la realización de este pro-
yecto; especialmente en este año que ha sido un poco extraño para todos.
A mis padres y hermano, por apoyarme en todos mis años de estudio y estar ahí cuando
lo he necesitado. Por enseñarme los valores necesarios para afrontar la vida con decisión
y perseguir mis metas.
A los amigos que me llevo tras la realización del máster, Mario y Juan con los que
he establecido una relación lo suficientemente buena como para atreverme a dormir con
ellos tirada en el sofá de un aeropuerto. Con Juan aún me quedan algunas aventuras de
estudios por delante, ¡ya verás como logramos esa plaza de funcionarios!
A los amigos de toda la vida: Mario, Jessi, Patri, Sergio, Sara, María y Sergio... sois
los que siempre habéis estado y siempre estaréis, más que amigos sois una familia. Os
quiero un montón. Además, que gracias a nuestras cenas de los viernes estos años de
estudio se han hecho menos pesados, ¡y las que nos quedan aún por hacer!
Y por supuesto, no puedo dejarme a la persona con la que empecé todo esto, la que
me convenció para hacer el máster (cuanto te he maldecido escribiendo este documento,
lo siento), pero a la que no cambiaría por nada del mundo. Miguel, poco te puedo decir
que no sepas ya. Repites en dedicatoria de trabajo final, y si acaso hubiera otro, estoy
convencida de que seguirías formando parte de los agradecimientos. Gracias por hacer
todo más fácil.
v
CAPÍTULO 0 ÍNDICE GENERAL
ÍNDICE GENERAL
1. INTRODUCCIÓN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Motivación del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Organización del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ESTADO DE LA CUESTIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Inteligencia Ambiental. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Definición y características . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Campos de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Inconvenientes del AmI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Realidad virtual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. Definición y conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Ventajas e inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Herramientas para el desarrollo de entornos virtuales . . . . . . . . . . . . . . 15
2.3.1. Open Simulator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2. Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4. Conclusiones al estado de la cuestión . . . . . . . . . . . . . . . . . . . . . . . 21
3. DEFINICIÓN DEL PROYECTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1. Descripción general del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1. Funcionalidad del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2. Características de los usuarios . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3. Entorno operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.4. Suposiciones y dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2. Especificaciones del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1. Especificación de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2. Especificación de requisitos funcionales . . . . . . . . . . . . . . . . . . . . 41
3.2.3. Especificación de plan de pruebas . . . . . . . . . . . . . . . . . . . . . . . 57
vii
CAPÍTULO 0 ÍNDICE GENERAL
3.3. Definición del ciclo de vida y metodología . . . . . . . . . . . . . . . . . . . . 70

3.3.1. Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3.2. Metodología de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.4. Planificación del proyecto y presupuesto. . . . . . . . . . . . . . . . . . . . . . 73
3.4.1. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4.2. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4. EJECUCIÓN DEL PROYECTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1. Diseño del entorno virtual y la arquitectura del sistema . . . . . . . . . . . . . 81
4.1.1. Entorno virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1.3. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2. Implementación del entorno virtual diseñado . . . . . . . . . . . . . . . . . . . 90
4.3. Implementación de un entorno reactivo . . . . . . . . . . . . . . . . . . . . . . 92
4.3.1. Subsistema de gestión de entorno. . . . . . . . . . . . . . . . . . . . . . . . 92
4.3.2. Subsistema de gestión gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5. DESCRIPCIÓN DE RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.1. Validación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2. Conclusiones de la evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3. Resumen de ejecución del proyecto y costes . . . . . . . . . . . . . . . . . . . 103
5.3.1. Planificación Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.3.2. Análisis de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6. CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.1. Objetivos cumplidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2. Líneas futuras de trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
BIBLIOGRAFíA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
viii
CAPÍTULO 0 ÍNDICE DE FIGURAS
ÍNDICE DE FIGURAS
2.1 Inteligencia Ambiental por Lopez de Ipiña y Vázquez [5] . . . . . . . . . 5

2.2 Actividades en el hogar con AmI por Lopez de Ipiña y Vázquez [5] . . . 8
2.3 Diagrama del espectro de realidad vs virtualidad . . . . . . . . . . . . . . 11
2.4 Arquitectura de Open Simulator . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Matriz de trazabilidad de requisitos vs pruebas (parte 1) . . . . . . . . . . 68
3.3 Matriz de trazabilidad de requisitos vs pruebas (parte 2) . . . . . . . . . . 69
3.4 Metodología en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.5 Diagrama de Gantt de la planificación estimada . . . . . . . . . . . . . . 76
4.1 Diseño de la vivienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.2 Colocación de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3 Pantalla principal y pulsera inteligente . . . . . . . . . . . . . . . . . . . 85
4.4 Ventana de selección de horas para dormir . . . . . . . . . . . . . . . . . 86
4.5 Ventana de administración . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.6 Diagrama de componentes del sistema . . . . . . . . . . . . . . . . . . . 88
4.7 Modelado de la estructura de la vivienda . . . . . . . . . . . . . . . . . . 90
4.8 Modelado de la estructura de la vivienda . . . . . . . . . . . . . . . . . . 91
5.1 Gráfico comparativo días reales vs días estimados . . . . . . . . . . . . . 105

5.2 Diagrama de Gantt de la planificación final . . . . . . . . . . . . . . . . 106
x
CAPÍTULO 0 ÍNDICE DE TABLAS
ÍNDICE DE TABLAS
2.1 Comparativa de Open Simulator y Unity . . . . . . . . . . . . . . . . . . 19
3.1 CU-XX: Plantilla de caso de uso . . . . . . . . . . . . . . . . . . . . . . 29

3.2 CU-01: Abrir grifo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 CU-02: Cerrar grifo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 CU-03: Encender fogón . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 CU-04: Apagar fogón . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 CU-05: Encender luz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 CU-06: Apagar luz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8 CU-07: Dormir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.9 CU-08: Sentarse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.10 CU-09: Levantarse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.11 CU-10: Moverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.12 CU-11: Modificar hora . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.13 CU-12: Generar fuego . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.14 CU-13: Generar fuga de gas . . . . . . . . . . . . . . . . . . . . . . . . 37
3.15 CU-14: Generar caída . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.16 CU-15: Modificar temperatura . . . . . . . . . . . . . . . . . . . . . . . 39
3.17 CU-16: Modificar frecuencia cardiaca . . . . . . . . . . . . . . . . . . . 40
3.18 CU-17: Solicitar asistencia . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.19 Plantilla de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.20 RF-01 : Movimiento del usuario virtual (desplazamiento) . . . . . . . . . 41
3.21 RF-02 : Movimiento del usuario virtual (visión) . . . . . . . . . . . . . . 42
3.22 RF-03 : Obstáculos en el movimiento . . . . . . . . . . . . . . . . . . . 42
3.23 RF-04 : Interactuar con la luz apagada . . . . . . . . . . . . . . . . . . . 42
3.24 RF-05 : Interactuar con la luz encendida . . . . . . . . . . . . . . . . . . 42
3.25 RF-06 : Interactuar con fogón apagado . . . . . . . . . . . . . . . . . . . 42
3.26 RF-07 : Interactuar con fogón encendido . . . . . . . . . . . . . . . . . . 43
xii
3.27 RF-08 : Interactuar con grifo cerrado . . . . . . . . . . . . . . . . . . . . 43

3.28 RF-09 : Interactuar con grifo abierto . . . . . . . . . . . . . . . . . . . . 43
3.29 RF-10 : Interactuar con silla (sentarse) . . . . . . . . . . . . . . . . . . . 43
3.30 RF-11 : Movimiento cuando el usuario se sienta . . . . . . . . . . . . . . 43
3.31 RF-12 : Interactuar con silla (levantarse) . . . . . . . . . . . . . . . . . . 44
3.32 RF-13 : Interactuar con la cama para dormir . . . . . . . . . . . . . . . . 44
3.33 RF-14 : Interfaz de selección de horas de sueño . . . . . . . . . . . . . . 44
3.34 RF-15 : Interfaz de selección de horas de sueño (horas permitidas) . . . . 44
3.35 RF-16 : Interfaz de selección de horas de sueño (botón aceptar) . . . . . . 45
3.36 RF-17 : Interfaz de selección de horas de sueño (botón cancelar) . . . . . 45
3.37 RF-18 : Interfaz de la pulsera inteligente . . . . . . . . . . . . . . . . . . 45
3.38 RF-19 : Interfaz de la pulsera inteligente (mostrar temperatura) . . . . . . 45
3.39 RF-20 : Interfaz de la pulsera inteligente (mostrar frecuencia cardiaca) . . 46
3.40 RF-21 : Interfaz de la pulsera inteligente (mostrar hora) . . . . . . . . . . 46
3.41 RF-22 : Interfaz de la pulsera inteligente (mostrar avisos) . . . . . . . . . 46
3.42 RF-23 : Interacción con la pulsera inteligente (solicitar ayuda) . . . . . . 46
3.43 RF-24 : Menú de administración . . . . . . . . . . . . . . . . . . . . . . 46
3.44 RF-25 : Menú de administración (botón aceptar) . . . . . . . . . . . . . . 47
3.45 RF-26 : Menú de administración (cambio de hora) . . . . . . . . . . . . . 47
3.46 RF-27 : Menú de administración (formato de hora) . . . . . . . . . . . . 47
3.47 RF-28 : Menú de administración (generar fuego) . . . . . . . . . . . . . 47
3.48 RF-29 : Generar fuego en la cocina . . . . . . . . . . . . . . . . . . . . . 47
3.49 RF-30 : Menú de administración (generar fuga de gas) . . . . . . . . . . 48
3.50 RF-31 : Generar fuga de gas en la cocina . . . . . . . . . . . . . . . . . . 48
3.51 RF-32 : Menú de administración (generar caída) . . . . . . . . . . . . . . 48
3.52 RF-33 : Generar caída del usuario . . . . . . . . . . . . . . . . . . . . . 48
3.53 RF-34 : Menú de administración (modificar pulsaciones) . . . . . . . . . 48
3.54 RF-35 : Menú de administración (valores de pulsaciones permitidos) . . . 49
3.55 RF-36 : Menú de administración (modificar temperatura) . . . . . . . . . 49
3.56 RF-37 : Menú de administración (valores de temperatura permitidos) . . . 49
3.57 RF-38 : Menú de administración (ventana de notificaciones) . . . . . . . 49
xiii
3.58 RF-39 : Menú de administración (mensajes de la ventana de notificaciones) 50

3.59 RF-40 : Sistema inteligente (apagar luz) . . . . . . . . . . . . . . . . . . 50
3.60 RF-41 : Sistema inteligente (apagar fogón) . . . . . . . . . . . . . . . . . 50
3.61 RF-42 : Sistema inteligente (cerrar grifo) . . . . . . . . . . . . . . . . . . 50
3.62 RF-43 : Sistema inteligente (mensaje de solicitud de ayuda al administrador) 51
3.63 RF-44 : Sistema inteligente (mensaje de aviso de fuego al administrador) . 51
3.64 RF-45 : Sistema inteligente (mensaje de aviso de fuego al usuario) . . . . 51
3.65 RF-46 : Sistema inteligente (mensaje de aviso de fuga de gas al adminis-
trador) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.66 RF-47 : Sistema inteligente (mensaje de aviso de fuga de gas al usuario) . 52
3.67 RF-48 : Sistema inteligente (mensaje de aviso de caída al administrador) . 52
3.68 RF-49 : Sistema inteligente (solicitar interacción del usuario tras caída) . 52
3.69 RF-50 : Interacción con la pulsera inteligente tras caída (respuesta afir-
mativa) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.70 RF-51 : Sistema inteligente (mensaje de aviso de necesidad de ayuda tras
caída) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.71 RF-52 : Interacción con la pulsera inteligente tras caída (respuesta negativa) 53
3.72 RF-53 : Sistema inteligente (mensaje de aviso de estado de usuario co-
rrecto tras caída) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.73 RF-54 : Sistema inteligente (mensaje de aviso de falta de interacción del
usuario tras caída) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.74 RF-55 : Sistema inteligente (mensaje de aviso de exceso de temperatura) . 54
3.75 RF-56 : Sistema inteligente (mensaje de aviso de bradicardia) . . . . . . . 54
3.76 RF-57 : Sistema inteligente (mensaje de aviso de taquicardia) . . . . . . . 54
3.77 RF-58 : Sistema inteligente (detección de comportamiento anómalo noc-
turno) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.78 RF-59 : Sistema inteligente (detección de comportamiento anómalo visi-
tando el baño) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.79 RF-60 : Sistema inteligente (detección de comportamiento anómalo en el
movimiento) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.80 RF-61 : Sistema inteligente (detección de comportamiento anómalo al
interactuar con elementos) . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.81 RF-62 : Sistema inteligente (detección de comportamiento anómalo al
interactuar con la silla) . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
xiv
3.82 PS-XX: Plantilla de prueba de sistema . . . . . . . . . . . . . . . . . . . 57

3.83 PS-01 : Movimiento del usuario . . . . . . . . . . . . . . . . . . . . . . 58
3.84 PS-02 : Interactuar con la luz . . . . . . . . . . . . . . . . . . . . . . . . 58
3.85 PS-03 : Interactuar con el fogón . . . . . . . . . . . . . . . . . . . . . . 59
3.86 PS-04 : Interactuar con el grifo . . . . . . . . . . . . . . . . . . . . . . . 59
3.87 PS-05 : Interactuar con asiento . . . . . . . . . . . . . . . . . . . . . . . 59
3.88 PS-06 : Interactuar con la cama . . . . . . . . . . . . . . . . . . . . . . . 60
3.89 PS-07 : Cancelar interacción con la cama . . . . . . . . . . . . . . . . . 60
3.90 PS-08 : Solicitud de asistencia con la pulsera inteligente . . . . . . . . . . 60
3.91 PS-09 : Modificar la hora del entorno virtual . . . . . . . . . . . . . . . . 61
3.92 PS-10 : Generar situación: fuego en la cocina . . . . . . . . . . . . . . . 61
3.93 PS-11 : Generar situación: fuga de gas en la cocina . . . . . . . . . . . . 62
3.94 PS-12 : Generar situación: caída del usuario (respuesta afirmativa a nece-
sidad de ayuda) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.95 PS-13 : Generar situación: caída del usuario (respuesta negativa a necesi-
dad de ayuda) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.96 PS-14 : Generar situación: caída del usuario (sin respuesta a necesidad de
ayuda) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.97 PS-15 : Generar situación: temperatura elevada . . . . . . . . . . . . . . 64
3.98 PS-16 : Generar situación: bradicardia . . . . . . . . . . . . . . . . . . . 64
3.99 PS-17 : Generar situación: taquicardia . . . . . . . . . . . . . . . . . . . 65
3.100PS-18 : Generar situación: olvido de luz encendida . . . . . . . . . . . . 65
3.101PS-19 : Generar situación: olvido de fogón encendido . . . . . . . . . . . 65
3.102PS-20 : Generar situación: olvido de grifo abierto . . . . . . . . . . . . . 66
3.103PS-21 : Comportamiento anómalo: actividad nocturna . . . . . . . . . . . 66
3.104PS-22 : Comportamiento anómalo: visita reiterada al baño . . . . . . . . 66
3.105PS-23 : Comportamiento anómalo: movimiento errático . . . . . . . . . . 67
3.106PS-24 : Comportamiento anómalo: interacción errática . . . . . . . . . . 67
3.107PS-25 : Comportamiento anómalo: inquietud . . . . . . . . . . . . . . . 67
3.108Fechas estimadas para cada tarea del proyecto . . . . . . . . . . . . . . . 74
3.109Desglose de costes de contratación de un empleado . . . . . . . . . . . . 78
3.110Coste completo del hardware . . . . . . . . . . . . . . . . . . . . . . . . 79
xv
3.111Costes imputables del hardware . . . . . . . . . . . . . . . . . . . . . . 79

3.112Desglose del coste total . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1 Sensores a implementar por el sistema en entorno físico . . . . . . . . . . 84
5.1 PS-XX: Plantilla de pruebas . . . . . . . . . . . . . . . . . . . . . . . . 95

5.2 PS-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3 PS-02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4 PS-03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5 PS-04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.6 PS-05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.7 PS-06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.8 PS-07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.9 PS-08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.10 PS-09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.11 PS-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.12 PS-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.13 PS-12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.14 PS-13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.15 PS-14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.16 PS-15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.17 PS-16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.18 PS-17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.19 PS-18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.20 PS-19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.21 PS-20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.22 PS-21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.23 PS-22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.24 PS-23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.25 PS-24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.26 PS-25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.27 Desglose del coste real total . . . . . . . . . . . . . . . . . . . . . . . . 109
xvi
CAPÍTULO 1 INTRODUCCIÓN
1. INTRODUCCIÓN
1.1. Contexto
En la actualidad, existen multitud de referencias al futuro en las que aparatos inteli-

gentes nos ayudan en la vida cotidiana, desde el coche inteligente que frena antes de que
se produzca el accidente, o lograr que tu propia casa aprenda de tus costumbres y efectúe
acciones en base a ellas.
Aunque esta tecnología pueda sonar lejana, la realidad es que está más cerca de lo
que creemos, y ya hay multitud de proyectos que estudian maneras de integrar este tipo
de técnicas, conocidas como inteligencia ambiental, en nuestro día a día. Recibe este
nombre precisamente, porque toda esta gama de artefactos que se comunican entre sí y
nos harán la vida más cómoda y fácil, se acoplan en el entorno formando parte de nuestro
ambiente, sin resultar intrusivo para el usuario.
Dentro del marco de inteligencia ambiental, la cual se puede utilizar en muchos ám-
bitos, llama la atención la aplicación para el “Ambient Assisted Living” (AAL) o vida
asistida. Desde hace décadas, la esperanza de vida de las personas en los países desarro-
llados ha ido en aumento gracias a los avances en sanidad y seguridad [1]. Concretamente,
según el INE [2], en España se prevé que para el año 2060 la esperanza de vida de las mu-
jeres rebase los 90 años, mientras que la de los hombres, ligeramente por detrás, supere
los 85 años. Llegados a ese punto nos queda preguntarnos si la calidad de vida de las
personas será lo suficientemente buena como para que vivan de forma independiente, o
si por el contrario, necesitarán de algún tipo de supervisión por parte de equipo médico
o familiares. Es en este punto donde cobra fuerza la inteligencia ambiental orientada a la
vida asistida, que no necesariamente tiene que aplicarse en el ámbito de soporte a per-
sonas mayores o con cierto grado de discapacidad, pero ciertamente mejora su grado de
independencia para que sean capaces de realizar actividades cotidianas sin necesidad de
ayuda o supervisión constante.
Obviamente, como todos los aspectos en los que interviene la tecnología, previamente
a su incorporación en la vida real resulta conveniente tener un entorno de pruebas en
el que, si algo sale mal, no interfiera negativamente en el usuario. Más aún teniendo en
cuenta el ámbito de aplicación de la inteligencia ambiental.
No obstante, es cierto que una tecnología como la inteligencia ambiental, es compli-
cado probarla si no habilitamos un entorno físico previamente para ello, un proceso que
puede resultar costoso o incluso inviable en el caso de que únicamente queramos llevar a
cabo una pequeña prueba de concepto. Es en este aspecto donde se centra el proyecto que
nos ocupa, dado que con la aparición de nuevas tecnologías y el aumento de la capacidad
del hardware actual, se ha propiciado la aparición de nuevas herramientas y productos
1
que son capaces de generar entornos virtuales. En dicho entorno virtual, sin necesidad de
realizar un desembolso en hardware, instalación, etc, podríamos poner en marcha nuestro
entorno de inteligencia ambiental y testar sus beneficios o carencias de forma sencilla
como una primera aproximación o estudio de viabilidad.
1.2. Motivación del trabajo
La motivación de este proyecto no es otra que la de explorar las posibilidades que

ofrecen las diversas herramientas que permiten construir mundos virtuales a la par que
investigar a cerca del funcionamiento e implementación de la inteligencia ambiental.
Con el paso de los años, la calidad y realismo que presentan los entornos virtuales
construidos por ordenador han ido creciendo, llegando en algunos casos, a obtenerse un
resultado tan parecido a la realidad que podríamos confundirlos.
Por ello nos parece interesante aprovechar este potencial para ofrecer una alternativa
más sencilla y económica para testar la inteligencia ambiental en un entorno determinado.
Con las herramientas de creación de entornos virtuales, y la gran cantidad de posibilida-
des que estas ofrecen, replicaremos un entorno físico en un mundo virtual, sobre el que
disponer los distintos elementos inteligentes y poner en marcha un entorno integrado con
la tecnología de inteligencia ambiental. Realizarlo de esta manera supondrá, además del
impacto económico, tener una primera idea de cómo la inteligencia ambiental puede me-
jorar nuestra calidad de vida, sin necesidad de implementarlo físicamente en el entorno.
1.3. Organización del documento
Los contenidos del documento se encuentran estructurados en torno a seis capítulos:
1. Introducción. Contiene el contexto en el que se realiza el trabajo recogido en este

documento así como la motivación y objetivos del mismo en rasgos muy generales.
Además, queda contenido en este punto también la estructuración de los capítulos
que componen este documento.
2. Estado de la cuestión. En este capítulo se recoge la información de las distintas

tecnologías relacionadas con el proyecto, en nuestro caso, las que afectan a los
temas sobre inteligencia ambiental y entornos virtuales.
3. Definición del proyecto. En este capítulo se definen los objetivos concretos del pro-
yecto y cómo se va a llevar a cabo. En las especificaciones del sistema, se realizará
un análisis para identificar los casos de uso y requisitos necesarios para el desarro-
llo del proyecto, además de establecer un plan de pruebas de cara a comprobar el
correcto funcionamiento de la implementación. Finalmente, también se recoge en
este punto el ciclo de vida y metodología utilizada a lo largo de todo el proyecto,
así como la planificación y los costes estimados.
2
4. Ejecución del proyecto. En este capítulo se define cómo se ha llevado a cabo el

proyecto. Se especifican las tareas que se han realizado en cada fase y como se ha
ido implementando el entorno virtual.
5. Descripción de resultados. En este capítulo se validará el sistema implementado

en base al plan de pruebas previamente definido. Además, se expondrá un resumen
de la ejecución del proyecto en cuanto a la planificación real y los costes finales.
6. Conclusiones. En el último capítulo, evaluaremos si hemos cumplido los objetivos

propuestos así como las líneas futuras de trabajo que pueden extenderse de este
proyecto.
3
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
2. ESTADO DE LA CUESTIÓN
En este capítulo se presentan los antecedentes y los fundamentos teóricos sobre los
que se basará nuestra propuesta, es decir, la teoría que rodea a la inteligencia ambiental y
la realidad virtual, así como las aplicaciones que pueden tener. Finalmente se realizará un
estudio de las herramientas propuestas para construir entornos virtuales, escogiendo una
de ellas, y daremos unas conclusiones al estado de la cuestión que nos permitan comenzar
con el desarrollo del proyecto.
2.1. Inteligencia Ambiental
El el primer capítulo, hemos introducido muy ligeramente una pequeña aproximación

de la definición de Inteligencia Ambiental (AmI). No obstante en este apartado, expli-
caremos más profundamente de que trata esta tecnología así como sus características y
aplicaciones principales.
El principal objetivo que persigue el AmI, es el de ampliar la interacción entre los
seres humanos y las tecnologías de la información y la comunicación. Para ello se crean
espacios donde la interacción de los usuarios con esta tecnología resulte natural, sin que
resulte invasiva para el mismo gracias a la alta capacidad sensorial de este tipo de sistemas
y la comunicación existente entre los mecanismos que la componen. De esta forma, se
logra que la tecnología del AmI se adapte a los usuarios y al entorno, actuando en función
de la información que recibe del mismo y ayudando a los usuarios en la realización de sus
tareas diarias.
2.1.1. Definición y características
En [3] se describe el AmI desde dos perspectivas diferentes. Una que tiene un enfo-
que más psicológico en la que se define como “el soporte eficaz y transparente para la
actividad de los sujetos a través del uso de las tecnologías de la información y las comu-
nicaciones” y otra desde el punto de vista tecnológico en la que se define la Inteligencia
Ambiental como “una inteligencia omnipresente y transparente en un entorno vigilado
que ayuda a la realización de las distintas actividades e interacciones de los usuarios”. Si
realizamos una síntesis de ambas, describiremos el AmI como un conjunto de dispositivos
electrónicos que se encuentran ocultos al usuario y además responden a los cambios que
se producen en el entorno de forma inteligente.
Además, se identifican las características que deben tener los sistemas que implemen-
ten esta tecnología para que sea considerada ‘ìnvisible” por el usuario [4]:
Los elementos que integran el sistema tales como sensores, deben ser totalmente
4
invisibles al usuario.
El sistema deberá reaccionar de acuerdo al entorno que rodea al usuario y las ac-
ciones que este toma. Además también deberá adaptarse al perfil de cada usuario.
El sistema podrá modificar el entorno en función de la información que recibe y

procesa por parte de las acciones que realiza el usuario.
El sistema debe ser capaz de adelantarse a aquello que va a ocurrir en el entorno.
Con dichas características podemos identificar que un sistema que integre AmI dis-
pondrá de tres atributos destacables: la ubicuidad, que permitirá acompañar al usuario allá
donde vaya puesto que el entorno se encuentra integrado con los dispositivos interconec-
tados entre sí; la invisibilidad, que otorga al sistema la posibilidad de pasar plenamente
desapercibido; y la inteligencia, que permite dotar al sistema de un comportamiento reac-
tivo ante los cambios que se suceden en el entorno.
En la siguiente figura extraída de [5] podemos apreciar una infografía de todos estos
atributos que caracterizan la inteligencia ambiental.
Fig. 2.1. Inteligencia Ambiental por Lopez de Ipiña y Vázquez [5]
En el eje horizontal observamos el espectro entre una visión centrada en la tecnología

y centrada en la persona, mientras que en el eje vertical podemos apreciar si la naturaleza
de la tecnología es aislada o interactúa entre si. En el bloque inferior izquierdo, nom-
brado como “Ambiente” identificamos los elementos tecnológicos que de forma aislada,
componen un entorno que implementa la Inteligencia Ambiental. Por otro lado, el bloque
inferior derecho, nombrado como “Inteligente”, está más apegado a la interacción con la
persona y presenta las características que debe tener dicho sistema, así como los servicios
5
que debe incorporar. Finalmente, en el bloque superior vemos los métodos que se utili-
zan para integrar todas las características individuales y conformar así la tecnología de
Inteligencia Ambiental.
2.1.2. Campos de aplicación
Un entorno que implementa Inteligencia Ambiental, puede estar aplicado a múltiples

dominios, entre los que principalmente se encuentran la aplicación en salud, educación y
cultura, movilidad y transporte, entretenimiento y vida asistida (AAL) [6]. Ya adelanta-
mos que este último será en el que nos centremos en este proyecto, pero como podemos
observar los campos de aplicación son muy variados.
2.1.2.1. Salud
En el caso de la aplicación de la Inteligencia Ambiental al ámbito de la salud, distin-

guimos principalmente tres categorías.
La prevención, que se centra en la monitorización de la salud del usuario para poder

determinar la aparición de posibles enfermedades.
El tratamiento, que se centra en el autodiagnóstico y la posibilidad de realizar tra-

tamientos de un paciente tras su paso por el hospital de forma remota, en lugar de
que este permanezca ingresado, como por ejemplo a la hora de realizar una rehabi-
litación [7].
El cuidado, centrado en la creación de sistemas capaces de responder a las necesi-

dades diarias de los usuarios o pacientes así como a situaciones de emergencia. Por
ejemplo, en el caso de un hospital en el que se establece un sistema que monitoriza
a los pacientes y se asegura que todos están atendidos [8] o facilitar los cuidados de
pacientes con alzheimer en una residencia [9]
2.1.2.2. Cultura y Educación
Cuando aplicamos la Inteligencia Ambiental al entorno educativo y cultural, nos en-

contramos con que, gracias a la existencia de dispositivos móviles se pueden incrementar
las capacidades de aprendizaje de los usuarios debido a que no es necesario que estos
se encuentren en una localización determinada como puede ser la escuela, el instituto, la
universidad, etc. Además, se pueden crear aplicaciones que fomenten el aprendizaje a la
vez que se interactúa con el entorno físico que rodea al usuario. Por ejemplo, a través de
una aplicación móvil con la que interactuar durante la visita a un parque arqueológico,
para ayudar a los visitantes a adquirir conocimientos sobre historia [10].
6
2.1.2.3. Movilidad y transporte
Por otro lado, cuando hablamos de Inteligencia Ambiental aplicada al transporte y

la movilidad, nos referimos a un sistema con capacidades como la gestión del tráfico,
soporte a la navegación e incremento de la seguridad.
En el caso de la gestión del tráfico o el soporte a la navegación, se recoge información
de distintos sitios, como el estado de los semáforos, la cantidad de vehículos que pasan
por un determinado punto, etc, con el objetivo de procesar esa información y optimizar
el tráfico. Además, con dicha información se podrá avisar al usuario de si la ruta que ha
escogido es la mejor, o existe otra más rápida en función de los cambios que se produz-
can en el entorno en tiempo real. Incluso, en el futuro, se prevé que todos los vehículos
puedan comunicarse entre sí y entre los distintos elementos del entorno, suponiendo esto
un aumento en la seguridad de los conductores, puesto que si un vehículo detecta que
justamente el que tiene delante frena bruscamente, podrá reaccionar para frenar antes que
el conductor gracias al aviso del sistema.
Algunos ejemplos de este tipo de tecnología aplicada al transporte y movilidad son
un sistema capaz de proporcionar mejores rutas en función de la actividad del tráfico en
tiempo real [11], lo cual resulta útil en el caso de empresas de transporte. O un sistema ca-
paz de establecer comunicaciones entre los vehículos y elementos del entorno tales como
semáforos de forma que colaboren entre ellos para aumentar la seguridad de conductores
y viandantes, mejorar la eficiencia, reducir las emisiones de gases, etc [12].
2.1.2.4. Ocio y entretenimiento
En el campo del ocio y el entretenimiento, es usual utilizar esta tecnología enfocada

al turismo, dado que se trata de una actividad en la que se puede aportar información a
través de un dispositivo electrónico como el teléfono móvil, a la par que se interactúa con
el entorno.
Concretamente en el caso del turismo tenemos dos tipos de sistemas en función de si
la actividad se realiza en el interior o en el exterior. En los casos en los que se desarrolla
en el interior, es bastante usual encontrar paneles con códigos QR que se pueden escanear
con el teléfono móvil para obtener más información o reproducir contenido multimedia
[13].
En el caso de las actividades que se realizan al exterior, el funcionamiento es similar,
con ayuda del teléfono móvil se escanean carteles dispuestos a lo largo del entorno y el
dispositivo se encarga de ir añadiendo información contextual sobre lo que el usuario está
viendo en ese momento, los servicios disponibles cercanos, etc. Un ejemplo de ello es la
aplicación de este sistema para visitar la ciudad de Córdoba [14].
7
2.1.2.5. Vida asistida (AAL)
El concepto de vida asistida está estrechamente ligado a las acciones que se desarro-
llan en el entorno doméstico. Para lograrlo se dota a la vivienda de sensores que recogen
información constantemente con el objetivo de monitorizar el movimiento y las activida-
des que se producen en el hogar así como detectar situaciones de peligro (humo, fuego,
etc). Esta monitorización activa, permite proporcionar la ayuda necesaria al usuario para
sus actividades diarias y aumenta la productividad en el hogar.
A modo de ejemplo, se presenta la siguiente tabla extraída de [5], en la que podemos
observar como diversas actividades que realizamos en el día a día se verían afectadas por
el uso del AmI.
Fig. 2.2. Actividades en el hogar con AmI por Lopez de Ipiña y Vázquez [5]
Como podemos observar, el número de tareas que tiene que realizar el usuario de
forma activa se reducen notablemente, dado que será el sistema el que las ejecute en su
lugar.
8
Principalmente, un hogar con estas características debe presentar estas cuatro funcio-
nes básicas [6]:
Automatización del hogar: Soporte para las funcionalidades básicas como pueden
ser la iluminación, la calefacción, así como otro tipo de instalaciones eléctricas. En
este ámbito se incluye también la monitorización frente a riesgos que pueden darse
en el hogar, como por ejemplo que se declare fuego, un escape de gas, etc.
Comunicación y socialización: Incluye aspectos para facilitar la comunicación a

través de internet o hacia otras personas. En este ámbito ya disponemos de la exis-
tencia del teléfono móvil mediante el cual hemos adquirido el paradigma de “siem-
pre conectados”.
Descanso, relajación y entretenimiento: El hogar constituye el entorno principal

para el descanso y el cuidado personal, así como el entretenimiento (aunque este
último puede llevarse a cabo también fuera del hogar). Por tanto, debe proporcionar
estas características ayudando al correcto descanso (atenuando la luz por ejemplo)
y disponer de formas de entretenimiento como la TV, videoconsolas, etc.
Trabajo y aprendizaje: Incorporan tareas para el cuidado y mantenimiento de la casa

(como por ejemplo puede ser el riego automático en función del calor, la humedad,
etc).
No obstante, la gran mayoría de aplicaciones de esta tecnología en el entorno domés-

tico tiene como principal objetivo el soporte a personas de avanzada edad o usuarios con
enfermedades o discapacidades, de manera que, se les proporciona una mayor calidad de
vida aportándoles un mayor grado de independencia en las actividades que realizan día a
día.
Será en este aspecto en el que nos centremos a la hora de la realización de este trabajo,
en el que estudiaremos la aplicación de todas las técnicas anteriormente descritas (auto-
matización del hogar, comunicación, etc) para mejorar la calidad de vida de este tipo de
usuarios y poder visualizar el impacto positivo que tiene en su día a día.
2.1.3. Inconvenientes del AmI
Una vez presentada esta tecnología, vemos que resulta beneficiosa en las áreas de
aplicación. No obstante, debemos remarcar algunos de sus inconvenientes, siendo el más
importante el rechazo del usuario a este tipo de tecnologías por la percepción de falta de
privacidad.
Está claro que avanzamos hacia un mundo en el que todo estará conectado, una de
las principales características del AmI, pero puede generar inquietud el hecho de que
constantemente se estén recopilando datos sobre nuestra forma de vida, dado que esta
9
tecnología podría llegar a estar presente en prácticamente todos los ámbitos de nuestro
día a día. No obstante, debe quedar claro que cuando se diseñan este tipo de sistemas,
también se tiene en cuenta los datos que se van a recopilar, y si estos resultan de carácter
sensible (como por ejemplo puede suceder con datos médicos), se toman las medidas de
seguridad necesarias.
Otro de los inconvenientes de desarrollar un sistema de este tipo, es el despliegue de
medios que debe realizarse. Cuanto mayor sea el entorno en el que se quiere aplicar (por
ejemplo, una ciudad) mayor inversión será necesaria para la sensorización del espacio
así como las comunicaciones entre los distintos dispositivos y el procesamiento de los
datos. Afortunadamente, con el avance de la tecnología, cada vez resulta más sencilla la
fabricación de sensores que permitan el intercambio de información e interconexión entre
ellos (conocidos como dispositivos IoT: Internet of Things) por lo que se reduce el coste
de los mismos y por tanto, el coste de un sistema que los integre.
10
2.2. Realidad virtual
Previamente a ofrecer una definición completa sobre qué es la realidad virtual, debe-
mos de realizar una distinción acerca de qué forma parte del mundo real y qué forma parte
del mundo virtual y dar una descripción básica de las múltiples realidades que existen hoy
en día gracias al avance tecnológico.
Fig. 2.3. Diagrama del espectro de realidad vs virtualidad
Como vemos en la figura 2.3 el espectro se extiende desde la Realidad Virtual has-
ta la Realidad Aumentada, denominándolo Realidad Extendida, aquella que engloba la
Realidad Aumentada, Realidad Mixta y Realidad Virtual. [15]
La Realidad Virtual nos transporta a un mundo enteramente virtual reemplazando
la realidad del usuario en el mundo real, por la realidad construida digitalmente. Hoy
en día esta inmersión en un mundo que no es real, se consigue principalmente a través
de dispositivos como son los Head Mounted Displays o dicho de otra forma, cascos de
realidad virtual.
En el caso de la Realidad Aumentada, esta no nos transporta a un mundo distinto del
que percibimos en la realidad, si no que transporta los elementos tecnológicos al plano
real, aplicando sobre este capas de información digital. Dispositivos como las cámaras del
teléfono móvil nos permiten aplicar esta capa digital, como sucede por ejemplo con los
filtros de redes sociales como Instagram.
Finalmente, la Realidad Mixta es donde convergen ambas realidades (virtual y au-
mentada) teniendo como característica que no solo superpone capas digitales a la realidad
(como hace la realidad aumentada) si no que estos elementos virtuales son capaces de
interactuar con elementos reales.
En el ámbito del trabajo que nos ocupa, nos centraremos en los aspectos relaciona-
dos con la Realidad Virtual, dejando a un lado las otras realidades contempladas en el
espectro.
11
2.2.1. Definición y conceptos básicos
Lo primero que debemos tener en cuenta sobre la Realidad Virtual (RV), es que existe
cierta discrepancia a la hora de dar una definición sobre la misma, dado que depende en
gran parte de la forma en la que percibamos como debe ser una experiencia de RV para
el usuario. Para nosotros y a lo largo de todo este proyecto, tomaremos como definición
aquella en la que se define la Realidad Virtual como la inmersión del usuario en un entorno
tridimensional generado por ordenador (al que se denomina entorno virtual) y en el que
se puede navegar e interactuar con los distintos elementos que lo componen [16].
A pesar de que esta definición de Realidad Virtual pueda resultar algo amplia, se
sigue pudiendo diferenciar de otro tipo de tecnologías similares (o que se llevan a cabo
con las mismas herramientas) como por ejemplo pueden ser los efectos especiales de las
películas, puesto que en este caso concreto no se permite ningún tipo de interacción del
usuario con el entorno, quedándose este en el plano de expectador.
En cuanto a cómo definimos la experiencia de RV para un usuario, esta depende en
gran medida de dos propiedades: la inmersión en el entorno virtual y la presencia del
usuario en el mismo. En el caso de la inmersión esta se refiere al grado en el que el
usuario se encuentra aislado del mundo real. En este aspecto identificamos dos tipos de
sistema: semi-inmersivos y totalmente inmersivos.
En el caso de los entornos totalmente inmersivos, el usuario se encuentra completa-
mente introducido en el entorno virtual, de forma que puede resultar complicado en algu-
nos casos diferenciarlo del mundo real. Sin embargo, en los entornos semi-inmersivos el
usuario sigue manteniendo algún tipo de contacto con el entorno real (como sucede con
los videojuegos).
En cuanto a la otra característica de la RV, la sensación de presencia, se trata de la
percepción de encontrarte más inmerso en el entorno virtual que en el entorno físico en
el que el usuario se encuentra realmente. Naturalmente, esta característica se encuentra
estrechamente ligada a la inmersión, puesto que cuanta más inmersión ofrezca el sistema,
mayor sensación de presencia conseguirá el usuario. No obstante, no deja de resultar una
característica subjetiva y dependiente de la predisposición psicológica del usuario hacia
el entorno virtual, dado que habrá personas que ante la misma situación se comporten
de una manera muy similar a como lo harían en el mundo real mientras que otras no lo
harán [17]. Cabe destacar que para alcanzar un grado óptimo en ambas características, ha
ayudado el avance tecnológico que se ha realizado en el ámbito de la realidad virtual en
los últimos años, dado que a día de hoy somos capaces de generar entornos virtuales de
alta calidad.
2.2.2. Ventajas e inconvenientes
Como sucede con todas las tecnologías, la Realidad Virtual trae consigo muchas ven-
tajas, pero también algún inconveniente.
12
Entre las ventajas más destacables encontramos que se trata actualmente de la úni-
ca tecnología que ofrece la posibilidad de “trasladarse” a otro lugar diferente del que se
percibe en la realidad gracias a sus características de inmersión y presencia. De la mano
de esta característica tan peculiar, se generan posibilidades tales como la práctica de si-
mulaciones en un entorno que esta completamente controlado y no entraña ningún riesgo
(físico) para el usuario. Además, supone un ahorro en costes puesto que la generación de
un espacio digital evita tener que invertir en la adecuación de un espacio físico en algunos
ámbitos.
Por otro lado, también presenta ciertas desventajas, como por ejemplo, durante el uso
prologando de este tipo de tecnología, puede ocurrir que el usuario se encuentre tan in-
merso en el entorno virtual que le provoque una distorsión de la realidad, o problemas de
índole psicológica. Además, se pueden producir efectos secundarios como mareos o vi-
sión alterada, producto de la utilización de dispositivos como gafas o cascos. Finalmente,
destacamos como desventaja de esta tecnología la problemática de que, cuando un usuario
se encuentra totalmente inmerso en el entorno virtual, este no tiene constancia de lo que
sucede a su alrededor en el mundo real, quedándose expuesto ante posibles accidentes o
peligros como puede ser un incendio, un robo, etc.
2.2.3. Aplicaciones
Las aplicaciones o usos que se pueden dar a la realidad virtual es bastante amplia.
Algunas de las aplicaciones más interesantes de esta tecnología son las siguientes:
Generar nuevas formas de entretenimiento como sucede en el mundo de los video-

juegos, que se utilizan elementos de RV para crear una inmersión aun mayor en el
jugador. [18]
El tratamiento de afecciones psicológicas tales como fobias [19] [20] [21], en las
que se utiliza la RV para exponer levemente al paciente a sus miedos y ayudarle a
superarlos.
Prevención de riesgos ante situaciones fortuitas que no son peligrosas de generar en

la vida real, como por ejemplo inundaciones, terremotos, incendios, avalanchas, etc.
Simulando este tipo de situaciones en RV [22] [23] se puede conseguir un resultado
muy inmersivo y así poder generar un plan de acción en caso de que sucediera, sin
poner en riesgo la vida de personas en el proceso.
Soporte para entrenamiento o aprendizaje de prácticas que son peligrosas de realizar

en la vida real, aplicándose sobre todo en campos como la medicina [24] [25] o el
pilotaje [26]
Proliferación de nuevas formas de realizar turismo mediante visitas virtuales [27].

Esta modalidad resulta interesante sobre todo para visitar zonas a las que de otra
forma nos sería complicado viajar, como por ejemplo el espacio [28].
13
En definitiva, existen multitud de aplicaciones a las que se puede aplicar la tecnología

de Realidad Virtual, y dado el avance en tecnología y la fidelidad (cada vez mayor) que
ofrecen estos entornos, se está explotando cada vez más en diversos sectores [29].
14
2.3. Herramientas para el desarrollo de entornos virtuales
En esta sección discutiremos las posibles herramientas que podemos utilizar a la hora
de realizar la implementación de entornos virtuales. Como ya hemos indicado anterior-
mente, hoy en día el concepto de realidad virtual está comenzado a explotarse más con
la aparición de hardware especializado, lo que a su vez hace que aparezcan multitud de
herramientas que los desarrolladores pueden utilizar para crear estos entornos virtuales.
Existen multitud de herramientas para la realización de este tipo de tareas, pero dadas
las características de cada una, nos ha parecido oportuno estudiar Open Simulator y Unity.
Open Simulator se trata de un servidor de aplicaciones que permite la creación de entornos
virtuales de forma sencilla. Unity es un motor de videojuegos, que ofrece posibilidades
más complejas a la hora de generar un entorno virtual. A continuación expondremos los
defectos y virtudes de cada uno y finalmente discutiremos cual se ha escogido y las razo-
nes de dicha elección.
2.3.1. Open Simulator
Esta herramienta de código abierto, permite la creación de aplicaciones 3D multi-

plataforma y multi-usuario. Es decir, permite poner en marcha con relativa sencillez, un
servidor de un mundo virtual, el cual puede ejecutarse en una máquina de forma local,
o bien desplegado en internet. De esta forma, los mundos virtuales creados con esta he-
rramienta son capaces de ejecutarse sobre cualquier sistema operativo, dado que pueden
ejecutarse en un servidor Web, además de ser accesibles para cualquiera de forma senci-
lla. Open Simulator puede utilizarse para simular entornos virtuales como los creados por
Second Life (un simulador de vida online), pero este proyecto de código abierto no persi-
gue el mismo objetivo que dicha plataforma, dado que a pesar de su parecido, el objetivo
principal es proporcionar una forma rápida y sencilla de crear entornos virtuales [30].
Open Simulator, provee al desarrollador de herramientas y frameworks para poner
en marcha la aplicación 3D de forma casi transparente. A continuación se muestra un
pequeño diagrama de las posibilidades que ofrece.
15
Fig. 2.4. Arquitectura de Open Simulator
Como se puede observar, por un lado tenemos el ejecutable OpenSims.exe, que en el

diagrama representa el servidor que contiene la aplicación en 3D. No obstante, es nece-
sario que para visualizar dicho mundo virtual, hagamos uso de otra herramienta externa
a Open Simulator, un visor, que nos permita conectarnos al servidor e interprete la in-
formación contenida en el mismo para mostrar los elementos 3D al usuario. Por tanto, el
visor será el encargado de presentar la interfaz e interactuar con los distintos elementos
que proporciona Open Simulator al desarrollador. Por ejemplo, uno de los visores que se
pueden utilizar es el mismo que se utiliza para ingresar a los servidores de la plataforma
Second Life, entre otros 1 .
Entre estos elementos se encuentra el servicio de Login, dado que cuando creamos
un servidor de Open Simulator nos solicitará crear una cuenta administradora dentro de
ese mismo servidor, que inicialmente será el que maneje toda la configuración del mismo.
Posteriormente podremos crear más usuarios con distintos permisos para realizar diferen-
tes acciones. Adicionalmente, también ofrece un sistema de inventario para los usuarios
del servidor, dado que estos podrán interactuar y almacenar objetos que se encuentren
en el mundo virtual. Y finalmente, un servicio para la construcción del propio mundo
tridimensional, en el que podremos colocar objetos, moverlos, importar elementos 3D,
etc.
Todas estas características, que son transparentes para el desarrollador que inicia un
proyecto con Open Simulator, serán visibles y accesibles gracias al visor anteriormente
mencionado, en el que aparecerá la interfaz de inicio de sesión para ingresar la dirección
del servidor (local o remota), el nombre de usuario y contraseña. Una vez ingresado en
el servidor, se generará automáticamente un usuario virtual, es decir, un personaje tridi-
mensional que podremos manejar para interactuar con el mundo (inicialmente vacío) y
1
http://opensimulator.org/wiki/Connecting
16
comenzar la construcción del mismo gracias a los distintos menús que aparecen en pan-
talla y que nos permitirán realizar las acciones de modelado e importación de objetos en
3D. Cabe destacar que la interfaz de estos visores es bastante intuitiva y sencilla, haciendo
realmente fácil la construcción del entorno virtual.
Además de todas estas características, Open Simulator también ofrece formas de
transformar el mundo virtual en un entorno interactivo que cambie en función de las
acciones del usuario. Esto se realiza a través de la utilización de scripts que modifiquen el
estado del entorno. Dichos scripts tienen como lenguaje base LSL (Linden Script Langua-
ge), y pueden asociarse a cualquier elemento que exista en el mundo virtual exceptuando
el propio usuario, es decir, que este no puede ver afectadas sus características por medio
de un script.
La principal característica de este lenguaje de programación es la capacidad de tratar
todos los elementos del mundo virtual a través de estados. Por ejemplo, una puerta estará
“abierta” o “cerrada”, una luz puede encontrarse “encendida” o “apagada”, etc. A su vez,
estos estados pueden modificarse a través de disparadores o eventos, por ejemplo, que un
usuario toque un determinado objeto.
En cuanto a la posibilidad de utilizar librerías y elementos de terceros en Open Simu-
lator, al ser una herramienta con un lenguaje tan especializado y con una comunidad tan
reducida no dispone de muchas posibilidades. Podremos utilizar elementos 3D externos
si previamente los convertimos al formato que acepta la herramienta, o si directamente
los modelamos en el entorno virtual. Esta última opción no será la más acertada si quere-
mos un modelado profesional, dado que las posibilidades que ofrece Open Simulator para
modelar utiliza formas y herramientas muy básicas.
En definitiva, la metodología que se utiliza en esta herramienta, tanto a la hora de pro-
gramar como a la hora de “poblar” el mundo virtual, es muy sencilla y hace que sea po-
sible que desarrolladores sin conocimientos extensos sobre programación o herramientas
de modelado en 3D, puedan desarrollar con Open Simulator mundos virtuales de forma
rápida. A costa de esta sencillez, se sacrifican otros aspectos como la libertad que ofrece
el poder modificar a partir de la programación cualquier elemento del entorno (dado que,
aunque se puede programar con LSL, este tipo de programación es muy limitada) y el
acabado final del entorno virtual, que tendrá un resultado más básico.
2.3.2. Unity
Esta es una herramienta que, al contrario que Open Simulator, no está específicamente
diseñada para la creación de entornos virtuales interactivos de forma rápida y sencilla. Se
trata de un motor de videojuegos por lo que posee un mayor número de herramientas de
diseño y ofrece muchísimas más posibilidades a la hora de crear un entorno virtual. Esto
también hace que sea bastante más complejo de utilizar, convirtiéndolo en una herramien-
ta más profesional.
17
En cuanto a la licencia de Unity, esta es de pago, aunque ofrece una versión gratuita
personal si el proyecto que se va a realizar no va a ser comercializado y lo realiza un
particular. No obstante, si estás en disposición de una cuenta educativa, si podrás acceder
a una licencia de pago. Si bien es cierto que las diferencias entre una y otra en el aparta-
do de desarrollo son inexistentes. Las diferencias principalmente se encuentran en que la
versión de pago ofrece herramientas para la monetización del videojuego creado, análisis
del comportamiento de los jugadores y la posibilidad de realizar proyectos de forma co-
laborativa. Puesto que no nos encontramos en la realización de un proyecto colaborativo,
y tampoco vamos a publicar el sistema en ninguna plataforma, no necesitaremos de estas
herramientas por lo que no supone un inconveniente utilizar la licencia personal gratuita.
En cuanto a las herramientas más destacables que ofrece Unity, para nuestro caso par-
ticular son el editor visual y el IDE de programación Visual Studio 2017. Con el editor
visual, podremos poblar el entorno virtual de elementos 3D. Este es bastante sencillo e
intuitivo de utilizar de forma básica. No obstante, posee muchas opciones que harán que
el entorno virtual adquiera un resultado final de mayor calidad. Por ejemplo, podremos
introducir iluminación volumétrica, sombras, reflejos, etc Aspectos que no influyen direc-
tamente sobre el desempeño de nuestro proyecto, pero que se encargarán de acercarlo a
la realidad lo máximo posible.
Además Unity permite añadir elementos 3D de terceros, es decir, modelos en 3D rea-
lizados con otras herramientas y que se podrán importar sin necesidad de modificar a un
formato compatible con Unity, dado que este soporta multitud de formatos provenientes
de distintas herramientas. De esta forma, en lugar de modelar los objetos en la propia
aplicación de Unity, podremos modelar con otras herramientas e importarlo sin ningún
inconveniente.
Por otro lado, con Visual Studio, podremos desarrollar scripts codificados en el len-
guaje de programación orientado a objetos C#. Dichos scripts, podremos agregarlos a
cualquier elemento que se encuentre en el editor para modificar su comportamiento, mo-
verlo, apagar o encender en el caso de que se trate de una fuente de luz, reproducir sonidos
etc. En definitiva, podremos crear scripts y algoritmos complejos dada la naturaleza del
lenguaje de programación que se utiliza, y que se pone a disposición del desarrollador
una librería básica que permite acceder a las propiedades de los objetos del entorno y
modificarlas en función de las necesidades del sistema. Adicionalmente, y al igual que
ocurre en el caso de los elementos 3D, Unity también permite la importación de libre-
rías de programación de terceros, lo que aumenta considerablemente las posibilidades de
dicha herramienta.
En la línea de la importación de elementos de terceros, Unity proporciona a sus desa-
rrolladores una plataforma en la que se pueden publicar y/o descargar elementos creados
por otros usuarios. Generalmente, los elementos publicados en dicha plataforma son de
pago, puesto que para los desarrolladores supone un esfuerzo la creación de contenido.
No obstante, siempre hay alguna excepción y se pueden encontrar también elementos gra-
18
tuitos, que quizá no sean tan profesionales, pero para el ámbito de este proyecto serán más
que suficientes.
En resumen, con Unity podremos crear un mundo virtual más realista dado que se
trata de una herramienta mucho más potente, pero a costa del incremento de complejidad
a la hora de utilizarla.
2.3.3. Comparativa
En los puntos anteriores, se han expuesto las características principales de las dos
herramientas propuestas para la implementación del entorno virtual así como su funcio-
namiento. A continuación, se expone en formato tabla las características de cada uno de
forma resumida:
Licencia Open Source Pago (con opción gratuita)

Lenguaje de programación LSL C#
Paradigma de programación Estados Orientada a objetos
Curva de aprendizaje Complejidad baja Complejidad alta
Documentación Escasa Abundante
Comunidad Poca Activa
Contenido de terceros Escaso Amplio catálogo
Gráficos Muy limitados Última generación
Tipo aplicación Servidor Todo tipo
Multiplataforma Sí Sí
Tabla 2.1. Comparativa de Open Simulator y Unity
Además de todas estas características, hay una que no hemos contemplado en la tabla
y es la experiencia previa con estas dos herramientas. No poseemos un conocimiento
previo de Open Simulator, mientras que si que disponemos de este conocimiento en el
caso de Unity dado que hemos trabajado con esta herramienta durante la realización del
máster. Por ello, aunque Unity no es fácil de utilizar y tiene una curva de aprendizaje muy
pronunciada, no resulta un inconveniente puesto que el equipo de desarrollo ya es capaz
de manejar dicha herramienta. No obstante, a pesar de tener conocimiento sobre el uso de
Unity, es necesario sopesar detenidamente con cual de las herramientas llevaremos a cabo
el proyecto.
El primer inconveniente radica en el tipo de licencia que posee cada uno. En el caso
de Open Simulator se trata de una licencia libre, mientras que Unity ofrece varios tipos
19
de licencia. Ofrece una licencia gratuita siempre y cuando los proyectos que se realicen
con la misma no se comercialicen. Este es el caso en el que nos encontramos puesto que
no se va a comercializar el producto obtenido fruto de la realización de este proyecto. No
obstante, también ofrece la opción de obtener una licencia de pago a través de una cuenta
educativa, y así tener todas las ventajas que ofrece la herramienta, por lo que podríamos
optar por esta segunda opción, salvando el inconveniente de la licencia.
Por otro lado, a favor de Open Simulator tenemos la gran facilidad con la que po-
demos crear un mundo virtual, siendo totalmente transparente para el desarrollador el
manejo del usuario dentro de este mundo virtual, la interacción con objetos, etc. Además
que el lenguaje de programación LSL permite añadir interacciones de forma sencilla con
el entorno que rodea al usuario. Esto no ocurre así con Unity, dado que en el caso de utili-
zarlo, además de generar el entorno virtual deberemos programar todas las interacciones
y el movimiento del usuario.
En cuanto al resultado final del entorno, con Unity lograremos un acabado más pro-
fesional y creíble mientras que con Open Simulator tendremos un entorno más básico
debido a las pocas opciones con las que cuenta para importar elementos 3D. Unity sin
embargo, posee un catálogo de objetos bastante extenso (si bien es cierto que muchos
de ellos son de pago) y es compatible con múltiples formatos de objetos 3D, por lo que
no solamente tenemos los disponibles en su catálogo, si no todos aquellos que podamos
encontrar a través de internet.
Finalmente, en cuanto a posibilidades, Unity ofrece a los desarrolladores mayor liber-
tad puesto que permite agregar scripts a cualquier elemento del entorno. Open Simulator
también ofrece esta posibilidad, pero en un ámbito más limitado debido a la metodología
de programación. Adicionalmente, el lenguaje de programación no está muy extendido lo
que dificulta encontrar información en sitios web especializados acerca del uso del mis-
mo, y la documentación que ofrece Open Simulator es muy escasa. En contraposición, los
scripts en Unity se codifican en el lenguaje C#, que sigue el paradigma de programación
orientada a objetos con el que estamos muy familiarizados, además de haber utilizado di-
cho lenguaje en anteriores ocasiones. Además la comunidad de foros especializados que
posee Unity unida a su amplia documentación hace que sea mucho más sencillo codificar
con esta herramienta que con Open Simulator.
Teniendo en cuenta esta comparativa, finalmente se ha decidido que la herramienta es-
cogida para el desarrollo del entorno virtual será Unity. La razón de escoger esta opción es
básicamente las posibilidades que ofrece Unity frente a Open Simulator, dado que podre-
mos construir un entorno virtual de mayor calidad. Adicionalmente, como ya se conoce el
funcionamiento de la herramienta y Open Simulator apenas dispone de documentación,
se ha determinado que será más sencillo desarrollar el entorno virtual en Unity que en
Open Simulator.
20
2.4. Conclusiones al estado de la cuestión
Así pues, una vez una vez expuestas ambas tecnologías (Realidad Virtual e Inteli-
gencia Ambiental) y algunas de las aplicaciones que tienen, vemos el gran potencial que
presenta cada una de ellas.
El caso de la Inteligencia Ambiental aplicada a la vida asistida resulta sumamente
interesante y útil, puesto que puede centrarse en hacer más fácil la vida de personas que
tienen cierto grado de discapacidad. Pero si queremos realizar un estudio sobre el uso de
la Inteligencia Ambiental en este ámbito nos encontramos varias limitaciones: la adecua-
ción del entorno, la adquisición de hardware, su instalación, etc... Un proyecto demasiado
ambicioso para el trabajo que nos ocupa. Es por esto que se presenta la tecnología de la
Realidad Virtual, que con su gran capacidad para generar entornos realistas e interactua-
bles, nos proporciona las herramientas adecuadas para generar un entorno de vida asistida
controlado por la Inteligencia Ambiental, evitando esas limitaciones que se imponen en
el plano físico.
No obstante, debemos tener en cuenta que en el ámbito de los entornos virtuales,
podemos lograr que estos sean más o menos inmersivos. En nuestro caso, el objetivo del
trabajo no es conseguir que el usuario tenga una presencia plena en el entorno virtual, sino
demostrar los beneficios que puede aportar al día a día de personas dependientes, el uso de
tecnología como la Inteligencia Ambiental, para lo cual se deciden utilizar las facilidades
que ofrece la Realidad Virtual para construir entornos. Por ello, nuestro entorno virtual
no hará uso de herramientas externas como cascos o gafas, que aporten una sensación
más inmersiva, sino que se utilizará simplemente la interfaz clásica de un ordenador para
controlar un usuario dentro del entorno virtual, y mediante acciones sobre el mismo, se
desencadenarán acciones del sistema controlado por la Inteligencia Ambiental.
21
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
3. DEFINICIÓN DEL PROYECTO
En esta sección trataremos los aspectos necesarios para la realización de este trabajo
así como la primera fase de análisis del mismo.
En primer lugar, realizaremos la descripción general de la funcionalidad del sistema,
así como las características de los usuarios que lo van a utilizar y del entorno operativo.
También estableceremos suposiciones y dependencias para el sistema a desarrollar.
Acto seguido, estableceremos las especificaciones del sistema, que contendrá los dis-
tintos casos de uso identificados a partir de la descripción funcional, y los requisitos fun-
cionales, de manera que obtengamos una primera visión de la situación que abordaremos
en este proyecto.
Finalmente definiremos el ciclo de vida y la metodología que hemos seguido a la
hora de abordar el proyecto. A partir de esta metodología, iremos construyendo una pla-
nificación estimada que nos ayudará a completar los objetivos definidos, de forma que
seamos capaces de realizar la entrega del trabajo a tiempo sin inconvenientes. Gracias a
esta planificación, también podremos establecer unos costes estimados, que en el capítu-
lo “Descripción de resultados” compararemos con los costes reales tras la ejecución del
proyecto.
22
3.1. Descripción general del sistema
Como ya hemos adelantado en el estado del arte, existen multitud de aplicaciones para
la inteligencia ambiental. No obstante, nos parece interesante enfocar este trabajo en la
realización de un testbed de realidad virtual aplicado al entorno de vida asistida, concreta-
mente, en el ámbito de personas que tienen cierto grado de dependencia debido al avance
de la edad y la aparición de enfermedades. Este nivel de especificidad nos permitirá aco-
tar el entorno para generar situaciones que se suelen dar en el día a día de estas personas,
como pueden ser olvidos (no recordar la toma de pastillas, olvidar luces y aparatos en-
cendidos, etc) o accidentes (caerse, enfermar, etc). Implementando el testbed en realidad
virtual, lograremos una primera aproximación al comportamiento real que debería tener
un sistema en este ámbito, ahorrando los costes que supone la instalación de sensores y
aclimatación del espacio.
En esta sección describiremos de forma general la funcionalidad del sistema así como
las características que deberán tener los usuarios que lo utilicen.
3.1.1. Funcionalidad del sistema
Se construirá un entorno virtual en el que se puedan poner a prueba algunas de las

características de la inteligencia ambiental en este ámbito. El primer paso consistirá en
el diseño y desarrollo de una vivienda en tres dimensiones, la cual será el escenario de
acción del testbed. En dicho entorno, permitiremos al usuario virtual moverse e inter-
actuar con los distintos elementos que compongan la escena, y en base a sus acciones,
la inteligencia ambiental implementada en el entorno virtual reaccionará tomando unas
decisiones u otras.
El escenario a diseñar constará de las estancias básicas de una vivienda: cocina, baño,
habitación, comedor y salón. El usuario tendrá plena libertad para moverse por ellas e
interactuar con los distintos elementos de cada estancia. Además, puesto que una de las
herramientas más utilizadas en el ámbito del AAL suele ser la existencia de wereables que
monitorizan al usuario, simularemos virtualmente la existencia de una pulsera inteligente
con la que el usuario podrá interactuar.
No obstante, somos conscientes de la cantidad de acciones que podemos realizar en
una vivienda y, dado que nos resulta inviable contemplar todas y cada una de ellas, se han
tenido en cuenta las acciones más básicas que serán las que se implementen en el testbed.
Estas son las siguientes:
El usuario virtual podrá moverse libremente entre todas las estancias de la vivienda.
El usuario virtual podrá interactuar con interruptores de la luz para encender y apa-
gar las luces de la vivienda.
23
El usuario virtual podrá interactuar con las diferentes superficies disponibles para
sentarse (sofá, sillas, sillones...) o levantarse si se encuentra sentado.
El usuario virtual podrá interactuar con la cama para dormir, seleccionando cuanto
tiempo quiere dedicar a esta acción a través de una interfaz en la que seleccionará
el número de horas, con un mínimo de 1 hora y un máximo de 10 horas.
El usuario virtual podrá interactuar con el fogón de la cocina para encenderlo y

apagarlo. De esta forma simulamos la acción de cocinar.
El usuario virtual podrá interactuar con el lavabo de la cocina o el baño para abrir o
cerrar el grifo.
El usuario virtual podrá solicitar asistencia a través de la pulsera inteligente, provo-

cando que el sistema emita un mensaje indicando que el usuario solicita ayuda.
Adicionalmente, dispondremos de un usuario administrador que podrá controlar al-

gunos elementos del entorno para realizar acciones que modifiquen el entorno o afecten
al usuario virtual. Para ello se dispondrá de una pantalla de administración que permitirá
realizar las siguientes acciones:
El usuario administrador podrá avanzar el tiempo del entorno virtual dado que este
dispondrá de un horario virtual propio que avanzará de la misma forma que en el
mundo real, es decir, una hora en el entorno virtual equivaldría a una hora en la
realidad.
El usuario administrador podrá generar un fuego en la cocina.
El usuario administrador podrá generar una fuga de gas en la cocina.
El usuario administrador podrá ocasionar que el usuario virtual tropiece y caiga.
El usuario administrador podrá modificar las constantes vitales medidas por la pul-
sera inteligente. Podrá modificar la temperatura entre los 35 y 40 grados centígrados
y la frecuencia cardiaca de 40 a 120 pulsaciones por minuto.
El objetivo de permitir la realización de estas acciones es la de generar situaciones en

el entorno para las cuales la inteligencia ambiental debería realizar alguna acción.
Cabe destacar que a la hora de manejar el sistema, la distinción entre ambos usuarios
radica en que el controlador de la simulación (es decir, la persona que maneja el sistema)
podrá abrir esta pantalla de administración en cualquier momento de la ejecución mientras
se está manejando al usuario virtual, para ejecutar dichas acciones, cambiando así de actor
entre el usuario virtual y el usuario administrador.
Finalmente, en función de las acciones que efectúa el usuario virtual, las que efectúa el
usuario administrador, o la combinación de ambas, el sistema reaccionará de la siguiente
manera:
24
Si el usuario virtual se mueve a una estancia e interactúa con el interruptor de la luz,

encendiéndola, posteriormente sale de la estancia y está durante 5 minutos fuera de
la misma, el sistema apagará la luz.
Si el usuario virtual se mueve hasta la cocina y enciende el fogón, posteriormente

sale de la cocina y pasan 10 minutos sin que vuelva a entrar, el sistema apagará el
fogón.
Si el usuario virtual se mueve hasta la cocina o el baño y abre el grifo, sale de la

estancia y pasan 2 minutos sin que vuelva a entrar en la estancia, el sistema cortará
el flujo del agua.
Si el usuario administrador genera un fuego o un escape de gas en la cocina, el

sistema emitirá un mensaje indicando la existencia de un peligro y avisará al usuario
virtual a través de la pulsera inteligente de dicho peligro.
Si el usuario administrador genera una caída del usuario virtual, el sistema emitirá
un mensaje informando de la caída y mostrará en la pulsera una notificación pa-
ra que el usuario seleccione si se encuentra bien o necesita ayuda. Si pasados 50
segundos el usuario no ha contestado, se emitirá un nuevo mensaje indicando que
este no responde, mientras que si lo hace, se emitirá otro mensaje indicando que el
usuario está fuera de peligro.
Si el usuario administrador eleva la temperatura del usuario virtual por encima de

37 grados centígrados, el sistema emitirá un mensaje indicando un aumento de tem-
peratura.
Si el usuario administrador disminuye la frecuencia cardiaca por debajo de 60 pul-

saciones por minuto, se considerará que el usuario virtual sufre una bradicardia. Si
por el contrario, el usuario administrador aumenta la frecuencia cardiaca por enci-
ma de 100 pulsaciones por minuto, se considerará que el usuario virtual sufre una
taquicardia. Hay ocasiones en las que un ritmo cardíaco por encima de 100 pul-
saciones por minuto no supone un peligro (como por ejemplo cuando se realiza
actividad física), no obstante en nuestro caso supondremos que el usuario virtual se
encuentra siempre en reposo. En ambos casos el sistema emitirá un mensaje para
avisar de dicha situación.
Si el usuario virtual realiza comportamientos extraños como los descritos a conti-

nuación:
• Levantarse de la cama de madrugada (entre las 12:00 y las 6:00)

• Ir al baño dos o más veces seguidas en un lapso menor a 20 minutos.
• Entrar y salir reiteradamente de una habitación (tres o más veces en un lapso
de 1 minuto).
25
• Activar o desactivar reiteradamente las luces, los grifos o el fogón de la cocina

sin haber salido de la estancia.
• Sentarse y levantarse reiteradamente (tres o más veces en un lapso de 1 minu-
to).
El sistema emitirá un mensaje para avisar de un comportamiento errático en el usua-

rio virtual.
Finalmente, presupondremos la existencia de un supervisor o supervisores a los que el

sistema enviará los diversos mensajes anteriormente expuestos informando de la situación
del usuario virtual. Al implementarse el AAL en un entorno real, no se “abandona” al
usuario por el hecho de utilizar tecnología, sino que únicamente se facilita la supervisión
del mismo mediante otras técnicas para después informar al personal especializado de
lo que le ocurre. Por tanto, el acto de solicitar asistencia o emitir un mensaje, no tendrá
ningún desencadenante en nuestro entorno más allá de mostrar un texto en la pantalla
de administración con el tipo de asistencia que se requiere. Esta acción en un entorno
real, desencadenaría la reacción de los supervisores y/o familiares, bien fuese avisar a
emergencias, personarse en la vivienda, llamar por teléfono al usuario, etc, en función del
mensaje de asistencia que se haya emitido y la gravedad del mismo.
3.1.2. Características de los usuarios
Como ya hemos indicado, el sistema tendrá dos tipos de actores, por un lado, el usuario
administrador que controlará lo que sucede en el entorno, y por otro, el usuario virtual que
se moverá por el entorno e interactuará con los distintos elementos.
No obstante, a pesar de la dualidad de actores en el sistema, el usuario final que lo
utilice será el mismo con la casuística de poder intercambiar su rol entre usuario virtual
(mientras se encuentra manejando al usuario dentro del entorno) o el usuario administra-
dor (cuando accione el menú para modificar elementos del entorno).
Por tanto, dado que va a ser un único usuario final el que utilice este sistema, este
deberá estar familiarizado con la interacción en entornos virtuales y los controles que se
manejan en este tipo de sistemas (similares a los de un videojuego).
3.1.3. Entorno operativo
Para el correcto funcionamiento del sistema, necesitamos que este se ejecute en un

ordenador con características equivalentes o superiores a las mostradas a continuación:
Sistema operativo Windows 7 SP1 de 64 bits.
CPU con arquitectura X64 o X86 y soporte para el juego de instrucciones SSE2.
26
Gráfica compatible con DirectX 10, 11 o 12.
Estas características se han extraído de la página oficial de Unity (herramienta con

la que se va a realizar el desarrollo) y son las características recomendadas para que un
equipo ejecute el archivo que genera la herramienta.
En nuestro caso, principalmente utilizaremos dos equipos. Uno dedicado al desarrollo
del entorno virtual cuyas características son las siguientes:
PC de sobremesa con Sistema Operativo Windows 10 de 64 bits.
16GB de RAM.
8GB de memoria de vídeo dedicada (Radeon RX Vega 56)
Procesador AMD Ryzen 5 2600X Six-Core Processor a 3,6GHz.
Almacenamiento de 256GB SSD y 1TB HDD.
Y otro dedicado a la realización de las pruebas que se especifican en el siguiente

punto, así como a la recopilación de la documentación afectada por este proyecto. Las
características de este segundo equipo son las siguientes:
MacBook Pro 13” (2020) con Sistema Operativo macOS Catalina
8GB de RAM.
1536 MB de memoria de vídeo integrada en el procesador. Intel Iris Plus Graphics

645.
Procesador Intel Core i5 de 4 núcleos a 1,4 GHz.
Almacenamiento de 256GB SSD.
Se ha utilizado un equipo algo más modesto para la realización de las pruebas, con
el objetivo de testar el sistema en un entorno operativo que no disponga de una tarjeta de
vídeo dedicada.
3.1.4. Suposiciones y dependencias
A continuación se describen las suposiciones y dependencias que se han asumido a la

hora de la realización de este proyecto.
El sistema se ejecutará en un ordenador que posea las características descritas en el

entorno operativo.
El sistema descrito no contempla el uso de hardware de realidad virtual (gafas o

controladores)
El sistema funcionará utilizando el teclado y ratón del ordenador.
27
3.2. Especificaciones del sistema
En esta sección se establecen las especificaciones a las que se acoge este proyecto
en forma de casos de uso y requisitos funcionales. En esta fase de análisis se establecerá
también el plan de pruebas que se seguirá durante la evaluación.
3.2.1. Especificación de casos de uso
A partir de los objetivos que se han definido al comienzo de este capítulo, se han
extraído los casos de uso del sistema. Estos recogen todos los escenarios posibles que
pueden darse al utilizar el entorno virtual.
A continuación, se muestra el diagrama de casos de uso construido. En el se iden-
tifican los dos actores intervinientes en nuestro sistema, el usuario virtual y el usuario
administrador, con cada una de las acciones que pueden realizar sobre el sistema.
28
Fig. 3.1. Diagrama de casos de uso
La especificación de cada caso de uso se establece a continuación siguiendo el formato

de la siguiente tabla:
Identificador
Título : Título del caso de uso
Descripción : Descripción del caso de uso
Flujo principal : Pasos a realizar para efectuar la acción
Pre-condiciones : Condiciones necesarias para realizar la acción
Post-condiciones : Estado final del sistema tras realizar la acción
Actor : Actor que realiza la acción
Tabla 3.1. CU-XX: Plantilla de caso de uso
29
Dónde los campos de las tabla indican lo siguiente:
Identificador : Cada caso de uso posee un identificador único. La nomenclatura

utilizada es CU-XX, donde CU indica que se trata de un caso de uso, y XX repre-
senta un número entero de dos cifras comenzando en 01 y que se irá incrementando
de uno en uno.
Título : Título del caso de uso.
Descripción : Descripción breve del caso de uso.
Flujo principal : Secuencia de pasos mediante los cuales se consigue el objetivo

del caso de uso.
Pre-condiciones : Conjunto de condiciones que, tanto el usuario como el sistema,

deben cumplir para realizar la acción.
Post-condiciones : Efectos de realizar la acción, se corresponde con la respuesta

del sistema.
Actor : Indica el tipo de usuario que realiza la acción. Puede ser:
• Usuario virtual : Actor que representa el usuario que se manejará en el en-

torno virtual.
• Inteligencia ambiental : Actor que realiza acciones en función de los cambios
del entorno virtual.
A continuación, se detalla la especificación de casos de uso identificados en el diagra-

ma:
30
CU-01
Título : Abrir grifo
Descripción : El usuario interactuará con el grifo del baño o la cocina para abrirlo
Flujo principal :
1. El usuario se desplaza a la cocina o el baño
2. El usuario se acerca al lavabo
3. El usuario pulsa la tecla “E” del teclado para interactuar con

el lavabo.
Pre-condiciones : La aplicación deberá estar iniciada y el grifo del lavabo de la cocina

o el baño deberán estar cerrados
Post-condiciones : El grifo de la cocina o el baño deberá expulsar agua
Actor : Usuario virtual
Tabla 3.2. CU-01: Abrir grifo
CU-02
Título : Cerrar grifo
Descripción : El usuario interactuará con el grifo del baño o la cocina para cerrar-
lo
Flujo principal :
1. El usuario se desplaza a la cocina o el baño donde se encuen-

tra el grifo abierto
2. El usuario se acerca al lavabo

el lavabo.
Pre-condiciones : La aplicación deberá estar iniciada y el grifo del lavabo de la cocina

o el baño deberán estar abiertos
Post-condiciones : El grifo de la cocina o el baño deberá dejar de expulsar agua
Tabla 3.3. CU-02: Cerrar grifo
31
CU-03
Título : Encender fogón
Descripción : El usuario interactuará con el fogón para encenderlo
Flujo principal :
1. El usuario se desplaza a la cocina
2. El usuario se acerca al fogón

el fogón.
Pre-condiciones : La aplicación deberá estar iniciada y el fogón de la cocina apagado

Post-condiciones : El fogón de la cocina se enciende
Tabla 3.4. CU-03: Encender fogón
CU-04
Título : Apagar fogón
Descripción : El usuario interactuará con el fogón para apagarlo
Flujo principal :
1. El usuario se desplaza a la cocina
2. El usuario se acerca al fogón

el fogón.
Pre-condiciones : La aplicación deberá estar iniciada y el fogón de la cocina encendi-

do
Post-condiciones : El fogón de la cocina se apaga
Tabla 3.5. CU-04: Apagar fogón
32
CU-05
Título : Encender luz
Descripción : El usuario interactuará con la luz de cualquier habitación mientras
esta esté apagada
Flujo principal :
1. El usuario se desplaza a la habitación
2. El usuario se acerca al interruptor de la luz

el interruptor.
Pre-condiciones : La aplicación deberá estar iniciada y la luz de la habitación apagada

Post-condiciones : La luz de la habitación se enciende
Tabla 3.6. CU-05: Encender luz
CU-06
Título : Apagar luz
Descripción : El usuario interactuará con la luz de cualquier habitación mientras
esta esté encendida
Flujo principal :
1. El usuario se desplaza a la habitación con la luz encendida
2. El usuario se acerca al interruptor de la luz

el interruptor.
Pre-condiciones : La aplicación deberá estar iniciada y la luz de la habitación encen-

dida
Post-condiciones : La luz de la habitación se apaga
Tabla 3.7. CU-06: Apagar luz
33
CU-07
Título : Dormir
Descripción : El usuario interactuará con la cama para dormir
Flujo principal :
1. El usuario se desplaza a la habitación principal
2. El usuario se acerca a la cama

la cama.
4. La aplicación despliega un menú interactivo para indicar

cuantas horas quiere dormir (mínimo 1 hora y máximo 10).
5. El usuario introduce el número de horas y pulsa el botón

aceptar.
Pre-condiciones : La aplicación deberá estar iniciada

Post-condiciones : El usuario duerme y avanza el tiempo en el sistema el número de
horas indicadas
Tabla 3.8. CU-07: Dormir
CU-08
Título : Sentarse
Descripción : El usuario interactuará con el sofa o cualquier silla para sentarse
Flujo principal :
1. El usuario se desplaza a la habitación con sofá / sillas
2. El usuario se acerca al sofá / silla

el sofá / silla.
Pre-condiciones : La aplicación deberá estar iniciada y el usuario deberá estar de pie

Post-condiciones : El usuario se sienta
Tabla 3.9. CU-08: Sentarse
34
CU-09
Título : Levantarse
Descripción : El usuario, estando sentado en un sofá o silla, interactuará con el
elemento para levantarse
Flujo principal :
1. El usuario se encuentra sentado en una silla / sofá

el sofá / silla.
Pre-condiciones : La aplicación deberá estar iniciada y el usuario deberá estar sentado

Post-condiciones : El usuario se levanta
Tabla 3.10. CU-09: Levantarse
CU-10
Título : Moverse
Descripción : El usuario virtual se desplaza por el entorno virtual
Flujo principal :
1. Se pulsa la tecla “W”, “A”, “S” y “D” para moverse hacia

delante, izquierda, atrás y derecha respectivamente.
2. Se mueve el ratón para simular el movimiento de cabeza del

usuario.
Pre-condiciones : La aplicación deberá estar iniciada y el usuario virtual deberá en-

contrarse activo
Post-condiciones : El usuario se desplazará en función de la tecla pulsada y moverá la
cabeza en función del ángulo en el que se desplace el ratón
Tabla 3.11. CU-10: Moverse
35
CU-11
Título : Modificar hora
Descripción : El usuario administrador abre el menú de administración y modifica
la hora del entorno virtual
Flujo principal :
1. Se pulsa el botón “ESCAPE” del teclado para abrir el menú

de administración.
2. En el menú de administración, se localiza la sección “Modi-

ficar hora”.
3. Se modifica la hora a la deseada.
4. Se guardan los cambios pulsando en el botón aceptar.

Post-condiciones : La hora se modifica a la indicada
Actor : Usuario administrador
Tabla 3.12. CU-11: Modificar hora
CU-12
Título : Generar fuego
Descripción : El usuario administrador abre el menú de administración y pulsa el
botón para generar un fuego en la cocina
Flujo principal :

de administración.
2. En el menú de administración, se localiza el checkbox “Ge-

nerar fuego”.
3. Se marca el checkbox.

Post-condiciones : Se genera un fuego en la cocina y el sistema reacciona avisando al
usuario mediante una notificación en la pulsera además de mostrar
un texto en la ventana de administración indicando el peligro
36
Tabla 3.13. CU-12: Generar fuego
CU-13
Título : Generar fuga de gas
botón para generar una fuga de gas en la cocina
Flujo principal :

de administración.

nerar fuga de gas”.

Post-condiciones : Se genera una fuga de gas en la cocina y el sistema reacciona avi-
sando al usuario mediante una notificación en la pulsera además
de mostrar un texto en la ventana de administración indicando del
peligro de fuga de gas
Tabla 3.14. CU-13: Generar fuga de gas
37
CU-14
Título : Generar caída
botón para generar una caída del usuario virtual
Flujo principal :

de administración.

nerar caída”.
Pre-condiciones : La aplicación deberá estar iniciada y el usuario deberá estar de pie

Post-condiciones : Cuando vuelve el control al usuario virtual, este andará unos pasos
y posteriormente caerá al suelo, desencadenado una reacción del
sistema en la que primeramente se emite un mensaje indicando que
el usuario se ha caído. Posteriormente se envía una notificación a
la pulsera del usuario indicando que responda si se encuentra bien
o no. Si tras 50 segundos este no responde se emitirá un segundo
mensaje para notificar que no se ha obtenido respuesta del usuario.
Si por el contrario este responde, se emitirá un mensaje indicando
que el usuario se encuentra bien.
Tabla 3.15. CU-14: Generar caída
38
CU-15
Título : Modificar temperatura
la temperatura del usuario virtual
Flujo principal :

de administración.

ficar temperatura”.
3. Se modifica la temperatura entre 35 y 40 grados centígrados.
4. Se pulsa el botón “Aceptar”

Post-condiciones : El sistema detecta la variación de temperatura, y si esta es mayor
que 37 grados centígrados muestra un mensaje avisando del au-
mento de temperatura en la pantalla de administración
Tabla 3.16. CU-15: Modificar temperatura
39
CU-16
Título : Modificar frecuencia cardiaca
la frecuencia cardiaca del usuario virtual
Flujo principal :

de administración.

ficar frecuencia cardiaca”.
3. Se modifica la frecuencia a la deseada con valores entre 40 y

120.
4. Se pulsa el botón “Aceptar”

Post-condiciones : El sistema detecta la disminución o aumento de la frecuencia car-
diaca y muestra un mensaje en la pantalla de administración avi-
sando del peligro de bradicardia o taquicardia
Tabla 3.17. CU-16: Modificar frecuencia cardiaca
CU-17
Título : Solicitar asistencia
Descripción : El usuario virtual interactúa con la pulsera inteligente para pedir
asistencia, si siente que necesita cualquier tipo de ayuda
Flujo principal :
1. El usuario pulsa la tecla “F” del teclado para mostrar la pul-

sera inteligente.
2. El usuario pulsa el botón “Solicitar ayuda”

Post-condiciones : El sistema detecta que el usuario está solicitando ayuda y muestra
un mensaje indicando esta solicitud en la pantalla de administración
Tabla 3.18. CU-17: Solicitar asistencia
40
3.2.2. Especificación de requisitos funcionales
Una vez finalizada la extracción de casos de uso en el que quedan definidos los dis-
tintos comportamientos que pueden efectuar los usuarios contra el sistema, es el turno de
completar el análisis con los requisitos funcionales. Estos se encargarán de especificar,
desde el punto de vista del sistema, el comportamiento que debe tener la aplicación.
Para una buena organización de los requisitos funcionales, se ha optado por utilizar el
formato de tabla que sigue a continuación:
RF-XX
Título : Título del requisito
Descripción : Descripción del requisito
Prioridad : Alta-Baja
Tabla 3.19. Plantilla de requisitos
Dónde las celdas que lo componen se refieren a:
RF-XX: Se trata del identificador del requisito. RF indica que se trata de un Requi-
sito funcional, mientras que XX irá adquiriendo valores numéricos comenzando en
uno para numerar el requisito funcional.
Título: Descripción breve del requisito.
Descripción: Explicación detallada del requisito.
Prioridad: Indica la importancia de que el requisito se encuentre incluido en el

sistema. Un valor de “Alta” indica que el sistema es incapaz de funcionar sin el
requisito, mientras que un valor de “Baja” indica que el sistema puede ser perfecta-
mente funcional sin el mismo.
A continuación se listan los requisitos identificados:
RF-01
Título : Movimiento del usuario virtual (desplazamiento)
Descripción : Al pulsar las teclas “W”, “A”, “S” y “D” del teclado el usuario
virtual se moverá
Prioridad : Alta
Tabla 3.20. RF-01 : Movimiento del usuario virtual (desplazamiento)
41
RF-02
Título : Movimiento del usuario virtual (visión)
Descripción : Al desplazar el ratón, la visión del usuario virtual se desplazará
acorde con el movimiento
Prioridad : Alta
Tabla 3.21. RF-02 : Movimiento del usuario virtual (visión)
RF-03
Título : Obstáculos en el movimiento
Descripción : Al chocar con una pared o mueble, el usuario no continuará avan-
zando
Prioridad : Alta
Tabla 3.22. RF-03 : Obstáculos en el movimiento
RF-04
Título : Interactuar con la luz apagada
Descripción : Al pulsar la tecla “E” cerca de un interruptor de una luz apagada,
esta se encenderá.
Prioridad : Alta
Tabla 3.23. RF-04 : Interactuar con la luz apagada
RF-05
Título : Interactuar con la luz encendida
Descripción : Al pulsar la tecla “E” cerca de un interruptor de una luz encendida,
esta se apagará.
Prioridad : Alta
Tabla 3.24. RF-05 : Interactuar con la luz encendida
RF-06
Título : Interactuar con fogón apagado
Descripción : Al pulsar la tecla E cerca del fogón de la cocina cuando está apa-
gado, este se encenderá.
Prioridad : Alta
Tabla 3.25. RF-06 : Interactuar con fogón apagado
42
RF-07
Título : Interactuar con fogón encendido
Descripción : Al pulsar la tecla E cerca del fogón de la cocina cuando está encen-
dido, este se apagará.
Prioridad : Alta
Tabla 3.26. RF-07 : Interactuar con fogón encendido
RF-08
Título : Interactuar con grifo cerrado
Descripción : Al pulsar la tecla E cerca de un grifo cerrado, este se abrirá.
Prioridad : Alta
Tabla 3.27. RF-08 : Interactuar con grifo cerrado
RF-09
Título : Interactuar con grifo abierto
Descripción : Al pulsar la tecla E cerca de un grifo abierto, este se cerrará.
Prioridad : Alta
Tabla 3.28. RF-09 : Interactuar con grifo abierto
RF-10
Título : Interactuar con silla (sentarse)
Descripción : Al pulsar la tecla E cerca de una superficie para sentarse (silla o
sofá) el usuario se sentará.
Prioridad : Baja
Tabla 3.29. RF-10 : Interactuar con silla (sentarse)
RF-11
Título : Movimiento cuando el usuario se sienta
Descripción : Mientras el usuario permanezca sentado, este no podrá moverse.
Prioridad : Alta
Tabla 3.30. RF-11 : Movimiento cuando el usuario se sienta
43
RF-12
Título : Interactuar con silla (levantarse)
Descripción : Mientras el usuario permanezca sentado, podrá pulsar la tecla E
para levantarse.
Prioridad : Alta
Tabla 3.31. RF-12 : Interactuar con silla (levantarse)
RF-13
Título : Interactuar con la cama para dormir
Descripción : Al pulsar la tecla E cerca de la cama, aparecerá una interfaz para
escoger las horas que quiere dormir.
Prioridad : Alta
Tabla 3.32. RF-13 : Interactuar con la cama para dormir
RF-14
Título : Interfaz de selección de horas de sueño
Descripción : La interfaz deberá tener un selector que permita seleccionar el nú-
mero de horas que se quiere dormir.
Prioridad : Alta
Tabla 3.33. RF-14 : Interfaz de selección de horas de sueño
RF-15
Título : Interfaz de selección de horas de sueño (horas permitidas)
Descripción : El número de horas deberá estar comprendido entre 1 y 10.
Prioridad : Baja
Tabla 3.34. RF-15 : Interfaz de selección de horas de sueño (horas

permitidas)
44
RF-16
Título : Interfaz de selección de horas de sueño (botón aceptar)
Descripción : La interfaz deberá tener un botón aceptar para realizar la acción de
dormir las horas seleccionadas.
Prioridad : Alta
Tabla 3.35. RF-16 : Interfaz de selección de horas de sueño (botón

aceptar)
RF-17
Título : Interfaz de selección de horas de sueño (botón cancelar)
Descripción : La interfaz deberá tener un botón cancelar para cancelar la acción
de dormir.
Prioridad : Alta
Tabla 3.36. RF-17 : Interfaz de selección de horas de sueño (botón

cancelar)
RF-18
Título : Interfaz de la pulsera inteligente
Descripción : El usuario virtual podrá ver en pantalla en todo momento una inter-
faz flotante que simulará una pulsera inteligente.
Prioridad : Alta
Tabla 3.37. RF-18 : Interfaz de la pulsera inteligente
RF-19
Título : Interfaz de la pulsera inteligente (mostrar temperatura)
Descripción : La interfaz de la pulsera mostrará la información de la temperatura
del usuario.
Prioridad : Baja
Tabla 3.38. RF-19 : Interfaz de la pulsera inteligente (mostrar

temperatura)
45
RF-20
Título : Interfaz de la pulsera inteligente (mostrar frecuencia cardiaca)
Descripción : La interfaz de la pulsera mostrará la información de la frecuencia
cardiaca del usuario.
Prioridad : Baja
Tabla 3.39. RF-20 : Interfaz de la pulsera inteligente (mostrar frecuencia

cardiaca)
RF-21
Título : Interfaz de la pulsera inteligente (mostrar hora)
Descripción : La interfaz de la pulsera mostrará la hora del entorno virtual
Prioridad : Baja
Tabla 3.40. RF-21 : Interfaz de la pulsera inteligente (mostrar hora)
RF-22
Título : Interfaz de la pulsera inteligente (mostrar avisos)
Descripción : La interfaz de la pulsera mostrará avisos al usuario.
Prioridad : Alta
Tabla 3.41. RF-22 : Interfaz de la pulsera inteligente (mostrar avisos)
RF-23
Título : Interacción con la pulsera inteligente (solicitar ayuda)
Descripción : El usuario podrá solicitar asistencia a través de la pulsera pulsando
el botón F del teclado.
Prioridad : Alta
Tabla 3.42. RF-23 : Interacción con la pulsera inteligente (solicitar

ayuda)
RF-24
Título : Menú de administración
Descripción : Al pulsar la tecla ESC se abrirá o cerrará el menú de administración
en función de si este se encuentra abierto o no.
Prioridad : Alta
Tabla 3.43. RF-24 : Menú de administración
46
RF-25
Título : Menú de administración (botón aceptar)
Descripción : El menú de administración dispondrá de un botón aceptar para
guardar los cambios.
Prioridad : Alta
Tabla 3.44. RF-25 : Menú de administración (botón aceptar)
RF-26
Título : Menú de administración (cambio de hora)
Descripción : El menú de administración dispondrá de un cuadro de texto para
cambiar la hora.
Prioridad : Alta
Tabla 3.45. RF-26 : Menú de administración (cambio de hora)
RF-27
Título : Menú de administración (formato de hora)
Descripción : La hora tendrá el formato HH:MM
Prioridad : Baja
Tabla 3.46. RF-27 : Menú de administración (formato de hora)
RF-28
Título : Menú de administración (generar fuego)
Descripción : El menú de administración dispondrá de un checkbox “Generar
fuego”.
Prioridad : Alta
Tabla 3.47. RF-28 : Menú de administración (generar fuego)
RF-29
Título : Generar fuego en la cocina
Descripción : Al dejar activado el checkbox “Generar fuego” del menú de admi-
nistración, la cocina se incendiará cuando se guarden los cambios.
Prioridad : Alta
Tabla 3.48. RF-29 : Generar fuego en la cocina
47
RF-30
Título : Menú de administración (generar fuga de gas)
Descripción : El menú de administración dispondrá de un checkbox “Generar fu-
ga de gas”.
Prioridad : Alta
Tabla 3.49. RF-30 : Menú de administración (generar fuga de gas)
RF-31
Título : Generar fuga de gas en la cocina
Descripción : Al dejar activado el checkbox “Generar fuga de gas”, aparecerá
humo en la cocina cuando se guarden los cambios.
Prioridad : Alta
Tabla 3.50. RF-31 : Generar fuga de gas en la cocina
RF-32
Título : Menú de administración (generar caída)
Descripción : El menú de administración dispondrá de un checkbox “Generar caí-
da”.
Prioridad : Alta
Tabla 3.51. RF-32 : Menú de administración (generar caída)
RF-33
Título : Generar caída del usuario
Descripción : Al dejar activado el checkbox “Generar caída” el usuario virtual se
caerá cuando se guarden los cambios.
Prioridad : Alta
Tabla 3.52. RF-33 : Generar caída del usuario
RF-34
Título : Menú de administración (modificar pulsaciones)
introducir las pulsaciones.
Prioridad : Alta
Tabla 3.53. RF-34 : Menú de administración (modificar pulsaciones)
48
RF-35
Título : Menú de administración (valores de pulsaciones permitidos)
Descripción : El cuadro de texto para introducir las pulsaciones permitirá valores
entre 40 y 120.
Prioridad : Baja
Tabla 3.54. RF-35 : Menú de administración (valores de pulsaciones

permitidos)
RF-36
Título : Menú de administración (modificar temperatura)
introducir la temperatura en grados centígrados.
Prioridad : Alta
Tabla 3.55. RF-36 : Menú de administración (modificar temperatura)
RF-37
Título : Menú de administración (valores de temperatura permitidos)
Descripción : El cuadro de texto para introducir la temperatura permitirá valores
entre 35 y 40.
Prioridad : Baja
Tabla 3.56. RF-37 : Menú de administración (valores de temperatura

permitidos)
RF-38
Título : Menú de administración (ventana de notificaciones)
Descripción : El menú de administración dispondrá de una ventana de notifica-
ciones.
Prioridad : Alta
Tabla 3.57. RF-38 : Menú de administración (ventana de notificaciones)
49
RF-39
Título : Menú de administración (mensajes de la ventana de notificaciones)
Descripción : La ventana de notificaciones del menú de administración mostrará
los últimos 3 mensajes que ha emitido el sistema.
Prioridad : Baja
Tabla 3.58. RF-39 : Menú de administración (mensajes de la ventana de

notificaciones)
RF-40
Título : Sistema inteligente (apagar luz)
Descripción : El sistema apagará la luz cuando esta lleve más de 5 minutos en-
cendida sin que el usuario se encuentre en la estancia.
Prioridad : Alta
Tabla 3.59. RF-40 : Sistema inteligente (apagar luz)
RF-41
Título : Sistema inteligente (apagar fogón)
Descripción : El sistema apagará el fogón cuando este lleve más de 10 minutos
encendido sin que el usuario se encuentre en la estancia.
Prioridad : Alta
Tabla 3.60. RF-41 : Sistema inteligente (apagar fogón)
RF-42
Título : Sistema inteligente (cerrar grifo)
Descripción : El sistema cerrará el grifo cuando este lleve encendido más de 2
minutos sin que el usuario se encuentre en la estancia.
Prioridad : Alta
Tabla 3.61. RF-42 : Sistema inteligente (cerrar grifo)
50
RF-43
Título : Sistema inteligente (mensaje de solicitud de ayuda al administra-
dor)
Descripción : En caso de que el usuario interactúe con la pulsera para solicitar
ayuda, el sistema emitirá un mensaje a la ventana de notificaciones
informando de dicha solicitud.
Prioridad : Alta
Tabla 3.62. RF-43 : Sistema inteligente (mensaje de solicitud de ayuda al

administrador)
RF-44
Título : Sistema inteligente (mensaje de aviso de fuego al administrador)
Descripción : En caso de producirse fuego, el sistema emitirá un mensaje a la
ventana de notificaciones informando del fuego.
Prioridad : Alta
Tabla 3.63. RF-44 : Sistema inteligente (mensaje de aviso de fuego al

administrador)
RF-45
Título : Sistema inteligente (mensaje de aviso de fuego al usuario)
Descripción : En caso de producirse fuego, el sistema avisará al usuario virtual a
través de la pulsera.
Prioridad : Alta
Tabla 3.64. RF-45 : Sistema inteligente (mensaje de aviso de fuego al

usuario)
RF-46
Título : Sistema inteligente (mensaje de aviso de fuga de gas al administra-
dor)
Descripción : En caso de producirse una fuga de gas, el sistema emitirá un men-
saje a la ventana de notificaciones informando de la fuga de gas.
Prioridad : Alta
Tabla 3.65. RF-46 : Sistema inteligente (mensaje de aviso de fuga de gas

al administrador)
51
RF-47
Título : Sistema inteligente (mensaje de aviso de fuga de gas al usuario)
Descripción : En caso de producirse una fuga de gas, el sistema avisará al usuario
a través de la pulsera.
Prioridad : Alta
Tabla 3.66. RF-47 : Sistema inteligente (mensaje de aviso de fuga de gas

al usuario)
RF-48
Título : Sistema inteligente (mensaje de aviso de caída al administrador)
Descripción : En caso de producirse una caída, el sistema emitirá un mensaje a la
ventana de notificaciones informando de la caída.
Prioridad : Alta
Tabla 3.67. RF-48 : Sistema inteligente (mensaje de aviso de caída al

administrador)
RF-49
Título : Sistema inteligente (solicitar interacción del usuario tras caída)
Descripción : En caso de producirse una caída, el sistema preguntará al usuario si
necesita ayuda a través de la pulsera.
Prioridad : Alta
Tabla 3.68. RF-49 : Sistema inteligente (solicitar interacción del usuario

tras caída)
RF-50
Título : Interacción con la pulsera inteligente tras caída (respuesta afirmati-
va)
Descripción : El usuario podrá contestar a la pregunta del sistema sobre si nece-
sita ayuda tras la caída, pulsando la tecla “Y” (yes) del teclado si
su respuesta es afirmativa.
Prioridad : Alta
Tabla 3.69. RF-50 : Interacción con la pulsera inteligente tras caída

(respuesta afirmativa)
52
RF-51
Título : Sistema inteligente (mensaje de aviso de necesidad de ayuda tras
caída)
Descripción : Si la respuesta del usuario es afirmativa, el sistema emitirá un men-
saje a la ventana de notificaciones indicando que el usuario necesita
ayuda.
Prioridad : Alta
Tabla 3.70. RF-51 : Sistema inteligente (mensaje de aviso de necesidad

de ayuda tras caída)
RF-52
Título : Interacción con la pulsera inteligente tras caída (respuesta negativa)
Descripción : El usuario podrá contestar a la pregunta del sistema sobre si nece-
sita ayuda tras la caída, pulsando la tecla “N” (no) del teclado si su
respuesta es negativa.
Prioridad : Alta
Tabla 3.71. RF-52 : Interacción con la pulsera inteligente tras caída

(respuesta negativa)
RF-53
Título : Sistema inteligente (mensaje de aviso de estado de usuario correcto
tras caída)
Descripción : Si la respuesta del usuario es negativa, el sistema emitirá un men-
saje a la ventana de notificaciones indicando que el usuario se en-
cuentra bien.
Prioridad : Alta
Tabla 3.72. RF-53 : Sistema inteligente (mensaje de aviso de estado de

usuario correcto tras caída)
53
RF-54
Título : Sistema inteligente (mensaje de aviso de falta de interacción del
usuario tras caída)
Descripción : En caso de que el usuario no conteste, pasados 50 segundos se
emitirá un mensaje a la ventana de notificaciones indicando que
el usuario no contesta tras la caída.
Prioridad : Alta
Tabla 3.73. RF-54 : Sistema inteligente (mensaje de aviso de falta de

interacción del usuario tras caída)
RF-55
Título : Sistema inteligente (mensaje de aviso de exceso de temperatura)
Descripción : Si la temperatura del usuario virtual excede los 37 grados, el sis-
tema emitirá un mensaje a la ventana de notificación indicando la
existencia de fiebre.
Prioridad : Alta
Tabla 3.74. RF-55 : Sistema inteligente (mensaje de aviso de exceso de

temperatura)
RF-56
Título : Sistema inteligente (mensaje de aviso de bradicardia)
Descripción : Si la frecuencia cardiaca del usuario virtual disminuye a menos de
60 pulsaciones por minuto, el sistema emitirá un mensaje a la ven-
tana de notificaciones indicando la existencia de bradicardia.
Prioridad : Alta
Tabla 3.75. RF-56 : Sistema inteligente (mensaje de aviso de bradicardia)
RF-57
Título : Sistema inteligente (mensaje de aviso de taquicardia)
Descripción : Si la frecuencia cardiaca del usuario virtual aumenta a más de 100
pulsaciones por minuto, el sistema emitirá un mensaje a la ventana
de notificaciones indicando la existencia de taquicardia.
Prioridad : Alta
Tabla 3.76. RF-57 : Sistema inteligente (mensaje de aviso de taquicardia)
54
RF-58
Título : Sistema inteligente (detección de comportamiento anómalo noc-
turno)
Descripción : Si el usuario virtual realiza actividades entre las 12:00 AM y las
6:00 AM durante más de 5 minutos, el sistema emitirá un mensaje a
la ventana de notificación indicando el tiempo que ha estado activo.
Prioridad : Alta
Tabla 3.77. RF-58 : Sistema inteligente (detección de comportamiento

anómalo nocturno)
RF-59
Título : Sistema inteligente (detección de comportamiento anómalo visitan-
do el baño)
Descripción : Si el usuario virtual visita el baño 2 o más veces en menos de 20
minutos, el sistema emitirá un mensaje a la ventana de notificación
indicando un comportamiento extraño.
Prioridad : Alta

anómalo visitando el baño)
RF-60
Título : Sistema inteligente (detección de comportamiento anómalo en el
movimiento)
Descripción : Si el usuario virtual entra y sale tres o más veces de una habitación
en el lapso de 1 minuto, el sistema emitirá un mensaje a la ventana
de notificación indicando un comportamiento extraño.
Prioridad : Alta

anómalo en el movimiento)
55
RF-61
Título : Sistema inteligente (detección de comportamiento anómalo al in-
teractuar con elementos)
Descripción : Si el usuario virtual interactúa 5 o más veces con el mismo elemen-
to sin salir de la estancia, el sistema emitirá un mensaje a la ventana
de notificación indicando un comportamiento extraño.
Prioridad : Alta

anómalo al interactuar con elementos)
RF-62
Título : Sistema inteligente (detección de comportamiento anómalo al in-
teractuar con la silla)
Descripción : Si el usuario virtual se sienta y se levanta tres o más veces en un
lapso de 1 minuto, el sistema emitirá un mensaje a la ventana de
notificación indicando un comportamiento extraño.
Prioridad : Alta

anómalo al interactuar con la silla)
56
3.2.3. Especificación de plan de pruebas
Una vez se han definido los casos de uso y requisitos que el sistema tendrá que im-
plementar, se debe proceder a la siguiente tarea del análisis: la definición de un plan de
pruebas. El objetivo que se busca conseguir no es otro que dar una guía para la realización
de pruebas de nuestro sistema, que se realizará más adelante en el capítulo “Descripción
de resultados”, y verificar que este cubre todos los requisitos especificados en el apartado
anterior. Es importante destacar que existen multitud de pruebas que pueden realizarse
sobre el software, pero en función de la solución adoptada y la situación concreta de cada
sistema, es posible que determinadas pruebas sean más importantes que otras.
Un ejemplo claro de ello son las pruebas de implantación, a las que no daremos mucha
importancia debido a que realizar la instalación de nuestro testbed resultará muy sencillo
dado que Unity permite la exportación del proyecto a un archivo ejecutable. Tampoco se
contemplan en este documento las pruebas de carga, en las que se mide la capacidad de
respuesta del sistema, puesto que nuestro entorno virtual no contempla el acceso concu-
rrente de múltiples usuarios. En cuanto a las pruebas unitarias y pruebas de integración,
nos parecen demasiado específicas para la tarea que tenemos que desarrollar, ya que no
se trata de un software en sí mismo si no de un entorno virtual que nos permita visualizar
sin realizar un gran desembolso, como funciona la inteligencia ambiental en el apartado
doméstico para facilitar la autonomía de personas dependientes.
Por tanto, las funcionalidades de código que se desarrollen serán bastante simples y
concluimos que lo verdaderamente interesante es mostrar que el funcionamiento del en-
torno virtual es el que se espera, realizando pruebas de sistema. Estas pruebas verificarán
que los casos de uso expuestos y requisitos se cumplen en el código, es decir, que el sis-
tema realiza todo aquello que se pretendía en un primer momento de forma correcta. En
otras palabras, para nuestro sistema virtual, se comprueba que dadas las acciones que se
efectúen en el mundo, este reacciona tal y como se ha especificado.
Una vez introducida la ruta que se va a seguir en el plan de pruebas, gracias al análisis
realizado, el alcance del trabajo que va a tener este proyecto y el entorno de pruebas que
se ha establecido en puntos anteriores, se identifican las pruebas que se van a realizar. La
tabla que se ha usado para representar cada prueba ha sido la siguiente:
PS-XX
Título : Título de la prueba
Descripción : Descripción de la prueba
Resultado esperado : Resultado esperado
Procedencia : Identificador de requisito funcional
Tabla 3.82. PS-XX: Plantilla de prueba de sistema
57
Dónde los campos de las tablas indican lo siguiente:
PS-XX : Identifica la prueba de sistema. XX toma valores de 0 a N indicando la

numeración de la prueba.
Título : Título que describe brevemente la prueba.
Descripción : Explicación detallada de la prueba.
Resultado esperado : Resultado que se espera de la prueba.
Procedencia : Indica la relación que existe entre la prueba y los requisitos funcio-
nales a partir de los cuales se ha establecido la misma.
A continuación se exponen las pruebas identificadas:
PS-01
Título : Movimiento del usuario
Descripción : Cuando el usuario utiliza las teclas de movimiento y el ratón, el
usuario virtual se desplaza por la estancia y se para si encuentra
algún obstáculo
Resultado esperado : El usuario se mueve por la estancia hacia delante, izquierda, atrás
y derecha en función de si se pulsa las tecla “W”, “A”, “S” y
“D”respectivamente. Si se encuentra algún obstáculo se le impide
el movimiento en esa dirección
Procedencia : RF-01 RF-02 RF-03
Tabla 3.83. PS-01 : Movimiento del usuario
PS-02
Título : Interactuar con la luz
Descripción : El usuario se desplaza hasta el interruptor de la luz y pulsa la tecla
de interacción para encender la luz si esta está apagada, o apagarla
si está encendida
Resultado esperado : Al pulsar la tecla “E” si la luz está apagada se enciende y si está
encendida se apaga
Procedencia : RF-04 RF-05
Tabla 3.84. PS-02 : Interactuar con la luz
58
PS-03
Título : Interactuar con el fogón
Descripción : El usuario se desplaza hasta el fogón y pulsa la tecla de interacción
para encenderlo si está apagado, o apagarlo si está encendido
Resultado esperado : Al pulsar la tecla “E” si el fogón está apagado se enciende y si está
encendido se apaga
Tabla 3.85. PS-03 : Interactuar con el fogón
PS-04
Título : Interactuar con el grifo
Descripción : El usuario se desplaza hasta el grifo y pulsa la tecla de interacción
para abrirlo si está cerrado, o cerrarlo si está abierto
Resultado esperado : Al pulsar la tecla “E” si el grifo está cerrado se abre y si está abierto
se cierra
Tabla 3.86. PS-04 : Interactuar con el grifo
PS-05
Título : Interactuar con asiento
Descripción : El usuario se desplaza hacia un asiento y pulsa la tecla de interac-
ción para sentarse. Una vez sentado no se podrá desplazar pero si
podrá mover la cabeza. Para volver a desplazarse se pulsará la tecla
de interacción nuevamente
Resultado esperado : Al pulsar la tecla “E” el usuario se sienta. Una vez sentado si pulsa-
mos las teclas de desplazamiento este no se moverá, pero si move-
mos el ratón si podremos cambiar el ángulo de visión. Al volver a
pulsar la tecla “E” nuevamente el usuario se levanta y puede volver
a desplazarse.
Tabla 3.87. PS-05 : Interactuar con asiento
59
PS-06
Título : Interactuar con la cama
Descripción : El usuario se desplaza hacia la cama y pulsa la tecla de interacción
para dormir. Aparece un menú en el que se le permite seleccionar
las horas que va a dormir, selecciona 8 horas y se pulsa el botón
aceptar para realizar la acción.
Resultado esperado : Al pulsar la tecla “E” aparece una interfaz para seleccionar las ho-
ras de sueño, se selecciona el valor de 8 horas y al pulsar aceptar, el
usuario visualiza en el reloj de la pulsera que han pasado 8 horas.
Procedencia : RF-13 RF-14 RF-15 RF-16 RF-18 RF-21
Tabla 3.88. PS-06 : Interactuar con la cama
PS-07
Título : Cancelar interacción con la cama
Descripción : El usuario se desplaza hacia la cama y pulsa la tecla de interacción
para dormir. Aparece un menú en el que se le permite seleccionar
las horas que va a dormir, y el usuario pulsa el botón cancelar.
Resultado esperado : Al pulsar la tecla “E” aparece una interfaz para seleccionar las ho-
ras de sueño, el usuario pulsa el botón cancelar y el menú se cierra.
El usuario visualiza en el reloj de la pulsera que no ha pasado el
tiempo.
Tabla 3.89. PS-07 : Cancelar interacción con la cama
PS-08
Título : Solicitud de asistencia con la pulsera inteligente
Descripción : El usuario pulsa la tecla para interactuar con la pulsera inteligente,
solicitando ayuda. Posteriormente el usuario administrador visuali-
za en los avisos un nuevo mensaje en el que se indica que el usuario
solicita asistencia.
Resultado esperado : Al pulsar la tecla “F”, en la ventana de notificaciones del menú ad-
ministrador aparecerá el mensaje “El usuario virtual solicita asis-
tencia” indicando que el usuario ha solicitado ayuda.
Procedencia : RF-23 RF-24 RF-38 RF-39 RF-43
Tabla 3.90. PS-08 : Solicitud de asistencia con la pulsera inteligente
60
PS-09
Título : Modificar la hora del entorno virtual
Descripción : A través del menú de administración, se modifica la hora del en-
torno a las 17:00.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración,
que permitirá modificar en el cuadro de texto la hora en formato
HH:MM. Al guardar los cambios, se podrá apreciar el cambio de
hora en la interfaz de la pulsera.
Tabla 3.91. PS-09 : Modificar la hora del entorno virtual
PS-10
Título : Generar situación: fuego en la cocina
Descripción : A través del menú de administración, se genera el fuego en la coci-
na.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración, al
activar el checkbox “Generar fuego” y guardar los cambios se de-
clarará un fuego en la cocina. En la interfaz de la pulsera aparecerá
un aviso de fuego y, si volvemos al menú administrador, en la ven-
tana de notificaciones veremos el mensaje “Peligro, se ha declarado
un fuego en la cocina”.
Procedencia : RF-18 RF-22 RF-24 RF-25 RF-28 RF-29 RF-38 RF-39 RF-44 RF-
45
Tabla 3.92. PS-10 : Generar situación: fuego en la cocina
61
PS-11
Título : Generar situación: fuga de gas en la cocina
Descripción : A través del menú de administración, se genera la fuga de gas en la
cocina.
activar el checkbox “Generar fuga de gas” y guardar los cambios
se declarará una fuga de gas en la cocina. En la interfaz de la pulsera
aparecerá un aviso de fuga de gas y, si volvemos al menú adminis-
trador, en la ventana de notificaciones veremos el mensaje “Peligro,
hay una fuga de gas en la cocina”.
47
Tabla 3.93. PS-11 : Generar situación: fuga de gas en la cocina
PS-12
Título : Generar situación: caída del usuario (respuesta afirmativa a necesi-
dad de ayuda)
Descripción : A través del menú de administración, se genera la caída del usua-
rio. La pulsera emite una notificación solicitando al usuario que
responda si necesita ayuda y el usuario responde afirmativamente.
activar el checkbox “Generar caída” y guardar los cambios el usua-
rio virtual se caerá. En la ventana de notificaciones del menú admi-
nistrador aparecerá el mensaje “Atención, el usuario se ha caído”.
En la interfaz de la pulsera aparecerá un aviso solicitando que el
usuario conteste si necesita ayuda, a lo que al responder afirmati-
vamente con la tecla “Y”, si volvemos al menú administrador, en
la ventana de notificaciones veremos el mensaje “Peligro, necesita
ayuda tras la caída”.
49 RF-50 RF-51
Tabla 3.94. PS-12 : Generar situación: caída del usuario (respuesta

afirmativa a necesidad de ayuda)
62
PS-13
Título : Generar situación: caída del usuario (respuesta negativa a necesidad
de ayuda)
responda si necesita ayuda y el usuario responde negativamente.
usuario conteste si necesita ayuda, a lo que al responder negativa-
mente con la tecla “N”, si volvemos al menú administrador, en la
ventana de notificaciones veremos el mensaje “El usuario se en-
cuentra bien tras la caída”.
49 RF-52 RF-53
Tabla 3.95. PS-13 : Generar situación: caída del usuario (respuesta

negativa a necesidad de ayuda)
PS-14
Título : Generar situación: caída del usuario (sin respuesta a necesidad de
ayuda)
responda si necesita ayuda y el usuario no responde.
usuario conteste si necesita ayuda, a lo que al esperar sin respon-
der, pasados 50 segundos si volvemos al menú administrador, en la
ventana de notificaciones veremos el mensaje “Peligro, el usuario
no ha respondido tras la caída”.
49 RF-54
Tabla 3.96. PS-14 : Generar situación: caída del usuario (sin respuesta a
necesidad de ayuda)
63
PS-15
Título : Generar situación: temperatura elevada
Descripción : A través del menú de administración, se modifica la temperatura
del usuario a 37,5 grados.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración, que
permitirá modificar en el cuadro de texto la temperatura. Al guar-
dar los cambios, se podrá apreciar el cambio de temperatura en
la interfaz de la pulsera y en la ventana de notificaciones del me-
nú administrador veremos el mensaje “Peligro, la temperatura del
usuario es elevada”.
Procedencia : RF-18 RF-19 RF-24 RF-25 RF-36 RF-37 RF-38 RF-39 RF-55
Tabla 3.97. PS-15 : Generar situación: temperatura elevada
PS-16
Título : Generar situación: bradicardia
Descripción : A través del menú de administración, se modifica la frecuencia car-
diaca del usuario a 50 pulsaciones.
permitirá modificar en el cuadro de texto las pulsaciones. Al guar-
dar los cambios, se podrá apreciar el cambio de frecuencia cardiaca
en la interfaz de la pulsera y en la ventana de notificaciones del
menú administrador veremos el mensaje “Peligro, el usuario está
sufriendo una bradicardia”.
Tabla 3.98. PS-16 : Generar situación: bradicardia
64
PS-17
Título : Generar situación: taquicardia
Descripción : A través del menú de administración, se modifica la frecuencia car-
diaca del usuario a 110 pulsaciones.
permitirá modificar en el cuadro de texto las pulsaciones. Al guar-
dar los cambios, se podrá apreciar el cambio de frecuencia cardiaca
en la interfaz de la pulsera y en la ventana de notificaciones del
menú administrador veremos el mensaje “Peligro, el usuario está
sufriendo una taquicardia”.
Tabla 3.99. PS-17 : Generar situación: taquicardia
PS-18
Título : Generar situación: olvido de luz encendida
Descripción : El usuario enciende la luz y abandona esa estancia durante más de
5 minutos.
Resultado esperado : Una vez que han pasado 5 minutos, la luz se apaga.
Tabla 3.100. PS-18 : Generar situación: olvido de luz encendida
PS-19
Título : Generar situación: olvido de fogón encendido
Descripción : El usuario enciende el fogón y abandona la estancia de la cocina
durante más de 10 minutos.
Resultado esperado : Una vez que han pasado 10 minutos, el fogón se apaga.
Tabla 3.101. PS-19 : Generar situación: olvido de fogón encendido
65
PS-20
Título : Generar situación: olvido de grifo abierto
Descripción : El usuario abre un grifo y abandona esa estancia durante más de 2
minutos.
Resultado esperado : Una vez que han pasado 2 minutos, el grifo se cierra.
Tabla 3.102. PS-20 : Generar situación: olvido de grifo abierto
PS-21
Título : Comportamiento anómalo: actividad nocturna
Descripción : Se modifica la hora a las 2:00AM través del menú de administra-
ción y el usuario realiza actividades durante más de 5 minutos (10
minutos).
Resultado esperado : En la ventana de notificaciones del menú de administración, vere-
mos el mensaje “Atención, el usuario ha estado activo por la noche
durante 10 minutos”.
Procedencia : RF-24 RF-25 RF-26 RF-27 RF-38 RF-39 RF-58
Tabla 3.103. PS-21 : Comportamiento anómalo: actividad nocturna
PS-22
Título : Comportamiento anómalo: visita reiterada al baño
Descripción : El usuario visita el baño 3 veces en un periodo inferior a 20 minu-
tos.
mos el mensaje “Atención, el usuario ha visitado el baño 2 o más
veces en los últimos 20 minutos”.
Tabla 3.104. PS-22 : Comportamiento anómalo: visita reiterada al baño
66
PS-23
Título : Comportamiento anómalo: movimiento errático
Descripción : El usuario entra y sale de una habitación 3 veces en menos de un
minuto.
mos el mensaje “Atención, el usuario presenta movimientos erráti-
cos”.
Tabla 3.105. PS-23 : Comportamiento anómalo: movimiento errático
PS-24
Título : Comportamiento anómalo: interacción errática
Descripción : El usuario interactúa con el mismo elemento sin salir de la habita-
ción 5 veces.
mos el mensaje “Atención, el usuario presenta interacciones erráti-
cas”.
39 RF-61
Tabla 3.106. PS-24 : Comportamiento anómalo: interacción errática
PS-25
Título : Comportamiento anómalo: inquietud
Descripción : El usuario se sienta y se levanta tres veces en menos de un minuto.
mos el mensaje “Atención, el usuario presenta inquietud”.
Procedencia : RF-10 RF-12 RF-38 RF-39 RF-61
Tabla 3.107. PS-25 : Comportamiento anómalo: inquietud
En la siguiente página se muestra la matriz de trazabilidad para comprobar que todas

las pruebas realizadas cubren los casos de uso especificados anteriormente. Cabe destacar
que en la segunda parte de la tabla, las columnas vacías que tienen requisitos asignados
en la primera parte, se han marcado en gris para evitar confusiones a la hora de visualizar
la trazabilidad.
67
Fig. 3.2. Matriz de trazabilidad de requisitos vs pruebas (parte 1)
68
Fig. 3.3. Matriz de trazabilidad de requisitos vs pruebas (parte 2)
69
3.3. Definición del ciclo de vida y metodología
En esta sección estableceremos las pautas que van a seguirse a lo largo de la realiza-
ción del proyecto, el orden de las tareas y la manera en la que estas van a abordarse.
3.3.1. Ciclo de vida
Debemos establecer la metodología de trabajo que vamos a seguir durante todo el

ciclo de vida del proyecto. Para ello, hemos optado por identificar las distintas tareas que
son necesarias para realizar nuestro proyecto.
Para llevar a cabo la solución propuesta, tal y como hemos mencionado con anteriori-
dad, se diseñará y pondrá en ejecución un entorno de realidad virtual, mediante el cual se
demuestren los beneficios del AAL. Por ello, se han identificado tres grandes tareas a la
hora de realizar este proyecto:
Tarea 1: Diseño del entorno de realidad virtual, en la que se diseñará el modelo

en 3D de la vivienda que implementará el paradigma de inteligencia ambiental.
Además en esta fase diseñaremos también la arquitectura de nuestro sistema.
Tarea 2: Implementación del diseño, en el que haremos uso de herramientas de

modelado de objetos 3D y Unity para llevar a cabo la construcción del entorno
virtual.
Tarea 3: Implementación del entorno interactivo, en la que se utilizará el lenguaje

C# para convertir los elementos estáticos del entorno previamente diseñado, en ele-
mentos reactivos a los cambios del ambiente. Para ello se tendrá en cuenta también
la arquitectura definida en la primera fase.
Por tanto, será necesario que escojamos una metodología acorde con esta división a la
hora de realizar la ejecución del proyecto.
70
3.3.2. Metodología de trabajo
Puesto que ya hemos determinado la forma en la que llevaremos a cabo la ejecución

del proyecto, es el momento de escoger una metodología. De esta manera, se capacita al
equipo para marcarse objetivos a lo largo de todo el ciclo de vida, además de ir cumplién-
dolos de forma exitosa a medida que avanza el tiempo.
Como ya hemos especificado, el desarrollo de este trabajo vendrá determinado por
las tres fases anteriormente mencionadas. De entre todas las metodologías de desarrollo
de software más comunes, se barajó la utilización de las siguientes, ya que todas ellos
permiten la organización del trabajo a través de ciclos o fases [31]:
Metodología incremental: Tiene como aspecto central requisitos cambiantes"lo que

permite realizar el desarrollo en función de las necesidades que van surgiendo a lo
largo del ciclo de vida del proyecto. [32]
Metodología en espiral: Tiene como característica principal la fragmentación de un

proyecto en fases y a su vez, en cada una de estas fases se realizan siempre las
mismas acciones. Estas suelen ser la definición de objetivos, análisis, desarrollo y
pruebas, y finalmente, la planificación de la siguiente fase. [33]
Metodología iterativa: Tiene como característica principal que los requisitos no se

encuentren bien definidos, por lo que al comienzo del ciclo del proyecto es necesa-
rio realizar un primer prototipo del producto final. [32]
Metodología secuencial: Tiene como base la existencia de un análisis amplio y

completo previo a la implementación, en el cual se identifican todos los casos de
uso y requisitos que deberá tener el producto final.
La metodología incremental no encajaba en nuestra situación debido a que no vamos

a tener unos requisitos que cambien o modifiquen a lo largo del tiempo. Además que cada
iteración en este modelo, constituye una versión completa del producto software final,
algo que tampoco se ajusta a nuestro caso, puesto que la división en fases que hemos
realizado, por si solas no da lugar a un producto completo y funcional.
Analizando la metodología en espiral, comprobamos que tampoco encaja en nuestro
proyecto, debido a que no vamos a realizar para cada una de las fases identificadas las
tareas de definir objetivos, análisis, desarrollo y pruebas, para que llegado al final de la
fase, discutamos si continuamos o no con una iteración más de la espiral. Las fases que
hemos descrito ya están acotadas, y no vemos el sentido a desgranarlas aún más en estas
cuatro subtareas, además que este tipo de metodologías se suelen utilizar en proyectos que
no tienen una definición clara de requisitos y por tanto hay que evaluar continuamente si
se realiza otra iteración más o no, lo cual, no se ajusta a nuestro caso.
En cuanto a la metodología iterativa, claramente tampoco encaja en nuestro proyecto
debido a que este si que posee unos requisitos definidos al comienzo de su ciclo de vida.
71
Descartando estas tres opciones, esto nos deja con la última metodología, comúnmente
conocida como metodología en cascada, y que es la que mejor se ajusta a nuestro proyecto.
La razón principal de esta decisión, es que desde el comienzo y tras la realización del
análisis, disponemos de una idea clara de como deberá ser el producto final una vez que
este se encuentre implementado.
En la siguiente imagen, podemos observar todas las fases que componen la metodo-
logía en cascada. A continuación explicaremos cada una de estas fases y el trabajo que
realizaremos en ellas.
Fig. 3.4. Metodología en cascada
En la primera fase de esta metodología, llevaremos a cabo la definición del problema,

en la que realizaremos la recolección de los requisitos a los que se acogerá el sistema a
desarrollar así como la especificación del plan de pruebas. Esta fase queda enteramente
contenida en este capítulo.
En la segunda fase, contenida en el siguiente capítulo, se realizará el desarrollo del
sistema, en el cual llevaremos a cabo el diseño del mismo así como la implementación en
código.
Finalmente, en la última fase, realizaremos la evaluación del sistema, pasando las
pruebas que se definieron en la primera fase y evaluando el resultado obtenido de las
mismas, si ha sido satisfactorio y por tanto, se han cumplido los objetivos del proyecto.
72
3.4. Planificación del proyecto y presupuesto
Teniendo en cuenta la metodología que se va a utilizar, estableceremos la planificación

del proyecto. Además, también se presupuestará el coste en función de la duración en
tiempo que se estime, así como los materiales que se utilizarán a lo largo del ciclo de vida
del proyecto.
3.4.1. Planificación
Cabe mencionar que la naturaleza de este documento, no es otra que la de plasmar el

desarrollo efectuado en el proyecto final, necesario para finalizar los estudios de máster
de Ingeniería Informática. De acuerdo con el plan de estudios del máster (impartido en
la Universidad Carlos III de Madrid) encontramos que la realización del Trabajo Fin de
Máster (TFM) equivale a un esfuerzo por parte del alumno de 12 créditos ECTS [34].
Teniendo en cuenta la información que proporciona la universidad acerca de a cuantas
horas equivale un crédito ECTS (30 horas) podemos calcular fácilmente cual es el tiempo
estimado del que disponemos para la realización de este proyecto:
N oCreditosT F M · Horascredito = 12 · 30 = 360 horas
Como ya hemos mencionado, el trabajo se estructurará en las fases pertinentes a la

metodología en cascada. Conociendo las actividades que se realizarán en cada una de
ellas, se ha estimado que el desarrollo del total de las mismas debe ser como máximo de
230 horas. Esto nos permite repartir las horas restantes hasta llegar a las 360 totales de
forma que dediquemos 90 horas a la escritura de la documentación que nos ocupa, y 40
horas dedicadas a la subsanación de posibles problemas o imprevistos que puedan surgir
a lo largo del ciclo de vida del proyecto y ralenticen la realización de alguna de las tareas.
Además, dentro de las 230 horas que se van a dedicar a la implementación del pro-
yecto como tal, cabe destacar que el reparto de horas no será equitativo entre las fases
identificadas por la metodología en cascada, debido a que algunas nos llevarán más tiem-
po que otras. Este reparto se realizará de la siguiente manera:
Definición del proyecto: 25 horas.
Análisis: 35 horas.
Diseño: 30 horas.
Implementación: 90 horas.
Pruebas: 50 horas.
73
El comienzo del proyecto está fijado en torno a la fecha en la que comienza la asigna-
tura en el plan de estudios (Febrero de 2020) por lo que se estima el día de comienzo el
primer día hábil de dicho mes, el Lunes 3 de Febrero de 2020.
La duración estimada del proyecto será de 7 meses. Podría acortarse esta duración,
puesto que 360 horas a repartir en 7 meses resulta en un volumen de trabajo diario muy
escueto, pero la razón de esta elección es debido a que el alumno trabaja y entre diario
a penas cuenta con tiempo para dedicarlo al proyecto. Además se pretende realizar la
entrega en la convocatoria de Septiembre, teniendo esta como fecha límite el día 7 de ese
mismo mes. Por tanto, la fecha estimada de finalización, habiendo iniciado el proyecto el
3 de Febrero, se estima a más tardar el día 3 de Septiembre de 2020. De esta forma no
situamos la fecha fin muy cercana a la fecha límite, dejando algunos días de margen si
acaso surgiese algún imprevisto que afectase a la planificación.
Por tanto, deberemos repartir las 360 horas que se han estimado (incluyendo en este
total las 40 horas destinadas a posibles imprevistos) entre los siete meses que se estima
que durará el proyecto. Como la duración (en días) de los meses es variable, se ha tomado
como referencia los días totales que se suceden entre el inicio del proyecto y el final del
mismo, dando como resultado que entre las dos fechas hay un total de 213 días.
Con estos datos nos resulta sencillo calcular el total de horas estimadas al día que se
dedicarán al proyecto, que como ya se había mencionado, no resulta en una cantidad muy
grande de trabajo al día.
Horastotales 360
= = 1, 69 horas/dia
Diastotales 213
Teniendo en cuenta estos datos, podemos determinar los días que durará cada fase
y establecer fechas de comienzo y fin para cada una de ellas. Debemos tener en cuenta
también, que hemos destinado 40 horas a posibles imprevistos, que suman un total de 24
días de los 213 que disponemos para acometer el proyecto. Esto supone que en lugar de
finalizar el proyecto el día 3, si no hay ningún inconveniente, se finalizará realmente 24
días antes, el 9 de agosto de 2020.
Por tanto, el resumen de comienzo, fin y duración de cada fase es la que se recoge en
la siguiente tabla:
Fase Fecha Inicio Fecha Fin Duración

Definición del proyecto 03-02-2020 17-02-2020 15 días
Análisis 18-02-2020 08-03-2020 20 días
Diseño 09-03-2020 26-03-2020 18 días
Implementación 27-03-2020 18-05-2020 53 días
Pruebas 19-05-2020 17-06-2020 30 días
Documentación del proyecto 18-06-2020 09-08-2020 53 días
Tabla 3.108. Fechas estimadas para cada tarea del proyecto
74
Si representamos esa duración con un diagrama Gantt, obtenemos una visión general
de la planificación a lo largo del tiempo tal y como podemos apreciar en la siguiente
figura:
75
Fig. 3.5. Diagrama de Gantt de la planificación estimada
76
3.4.2. Presupuesto
En esta sección, analizaremos el presupuesto necesario estimado para la realización de

este proyecto. Para llevar a cabo la estimación, calcularemos dos tipos de costes, directos
e indirectos, teniendo en cuenta la planificación estimada descrita en el anterior apartado.
Para el cálculo de los costes indirectos se ha tomado el valor de un 17 % sobre los
costes directos.
Para el cálculo de los costes directos se han tenido en cuenta los siguientes aspectos:
Coste humano en función de las horas de dedicación al desarrollo del proyecto.
Costes de material en el que se incluyen componentes hardware y software.
3.4.2.1. Coste humano
Teniendo en cuenta que el equipo de desarrollo estará compuesto por una única per-
sona, y esta será la que desempeñe las tareas durante todo el ciclo de vida del proyecto,
calcularemos el coste humano tomando como referencia el sueldo que recibe dicha perso-
na en función de la formación que posee y la zona geográfica en la que trabaja. En el caso
concreto, se está en posesión de la titulación de grado y máster de Ingeniería informática,
y se trabaja en Madrid, en el área de las TIC. El puesto que ostenta una persona con estas
características, en una escala general es “Analista”. Según la página web “indeed” [35],
especializada en realizar estimaciones salariales en base a un puesto concreto, un analista
programador percibe un sueldo medio de 31.494 e/brutos al año. Este valor distribuido
en 14 pagas mensuales, equivale a unos 2.249 e/brutos al mes.
No obstante, debemos tener en cuenta que este no es el coste total de un empelado,
sino que a esto hay que sumarle los gastos en seguridad social. Para realizar este calculo,
utilizaremos las bases y tipos de cotización que publica el Ministerio de inclusión, segu-
ridad social y migraciones Español [36]. Por tanto, aplicaremos los porcentajes de tipos
de cotización indicados, que incrementarán el coste humano, siendo estos los siguientes:
Contingencias comunes : Supone un incremento del coste humano del 23,6 % en

concepto de contribución para las pensiones.
Desempleo : Supone un incremento del 6,7 % puesto que el contrato tendrá una
duración determinada (igual a la duración del proyecto) en lugar de ser un contrato
general indefinido.
FOGASA : Incrementa el coste en un 0,2 % en concepto de cobertura para el em-

pleado en caso de que la empresa se declarase insolvente y no pudiera afrontar los
costes de despido.
77
Formación Profesional : Incremento de un 0,6 % en concepto de formación para el

empleado.
Por tanto, el desglose completo del coste del empleado en un mes es el que se muestra
en la siguiente tabla:
Concepto Valor (e/mes)

Salario Bruto mensual 2.249
Contingencias comunes 530,76
Desempleo 150,68
FOGASA 4,50
Formación Profesional 13,49
COSTE TOTAL 2.948,43
Tabla 3.109. Desglose de costes de contratación de un empleado
Por tanto, el coste humano es de 2.948,43 e/mes. De esta cifra, extraeremos el coste
por hora para poder calcular el coste de personal del proyecto (ya que este tiene una dura-
ción por horas). Teniendo en cuenta que el sueldo inicial estimado pertenece a un salario
con jornada completa, se toma de referencia que la jornada no supondrá una dedicación
de más de 40 horas semanales. Sabiendo a su vez que un mes dispone de 4 semanas de
media, las horas mensuales totales dedicadas serían unas 160. Si dividimos el coste total
del trabajador, entre dichas horas, obtendremos como resultado el coste del trabajador por
hora.
CosteT otalmes 2948,43

= = 18,43 euros/hora
Horasmes 160
Puesto que gracias a la estimación realizada, sabemos la duración del proyecto, po-
demos calcular el coste humano a lo largo de este. Disponemos de 320 horas para la
realización del mismo (puesto que 40 horas se destinaron para posibles inconvenientes)
por lo que el coste humano alcanzará un valor de:
Preciohoras · T otalhoras = 18,43 · 320 = 5897, 6 euros
Adicionalmente, si hubiese problemas durante el ciclo de vida del proyecto y tuvié-

ramos que invertir las 40 horas (24 días) que se destinaron para disponer de un margen
temporal, deberíamos aportar más presupuesto al proyecto. Además, teniendo en cuenta
que estas horas entran dentro de la categoría de horas extra, aplicaremos el porcentaje co-
rrespondiente que se especifica en los tipos de cotización (Horas extraordinarias de fuerza
mayor) que aumenta el coste del precio / hora en un 12 % más. Por tanto este recargo en
78
el coste, dejaría un precio / hora de 20,64 e. En total, para cubrir este exceso de horas
destinaríamos el importe de:
Preciohoras · T otalhoras = 20,64 · 40 = 825, 6 euros
Por tanto, hemos tenido esta cifra extra en cuenta a la hora de presupuestar el proyecto,
estableciéndolo como un margen de presupuesto para, en el caso de que finalmente la
duración se alargue más de lo que se había estimado, no dar un presupuesto inferior.
3.4.2.2. Costes Materiales
En esta sección estableceremos los costes materiales. Para ello estimaremos los gastos
de los materiales hardware y software adquiridos previamente a la realización del proyec-
to. Dividiremos los costes en dos tablas, recogiendo en la primera los costes de hardware
y en la segunda los originados por software.
Concepto Valor (e)

MacBook Pro 13” (2020) 1.349
PC sobremesa 1.565
Ratón Logitech G402 34,99
Teclado NewSkill Hanshi Spectrum 54,99
TOTAL 3003,98
Tabla 3.110. Coste completo del hardware
No obstante, no es correcto imputar el gasto total del hardware al proyecto, dado que
lo hemos adquirido con anterioridad al comienzo del mismo. Por esta razón calcularemos
el coste hardware en función del porcentaje de vida útil del mismo que dedicaremos al
proyecto.
Concepto Coste (e) % Uso Días Uso Vida útil (días) 1 Coste imputable 2
MacBook 1.349 100 189 1825 139,70
PC 1565 100 189 1825 162,07
Ratón 34,99 100 189 1825 3,62
Teclado 54,99 100 189 1825 5,69
TOTAL 1.437,99 311,08
1
El valor de la vida útil de un elemento de hardware se establece en 5 años.
2
El coste imputable se calcula con la fórmula de amortización (T iempousoEnProyecto /T iempovidaUtil ) ·
Costeequipo · %U so
Tabla 3.111. Costes imputables del hardware
79
En cuanto a los gastos software, todas las herramientas que se han utilizado para llevar
a cabo el proyecto, no han supuesto ningún desembolso. Por ejemplo en el caso de Unity,
se ha utilizado la versión de pago del programa, pero a través del registro con una cuenta
educativa, no ha supuesto ningún coste. Por tanto los costes de material, entre hardware y
software, ascienden a 311,08 e.
Por último, recalcar que al igual que sucedía en el caso de los costes humanos, a
la hora de calcular el coste imputable de los dispositivos hardware utilizados, podemos
encontrarnos en la casuística de tener que usarlos durante más tiempo debido a que con-
sumamos el margen de 24 días destinado a posibles inconvenientes durante la realización
del proyecto. Por tanto, los costes de material aumentarían ligeramente si esto sucediese,
sumando al valor previamente calculado un importe de 39,50 e.
3.4.2.3. Costes totales
Con el resultado del cálculo de costes humanos y materiales, podemos establecer los
costes directos del proyecto sumando estos valores. Adicionalmente se sumarán también
los valores de coste humano y material estimados en caso de utilizar los 24 días de margen
para no estimar el presupuesto al límite y tener algo de margen. De esta manera obtenemos
el importe de:
CosteHumano + Coste Material + CosteHumanoAdicional + Coste MaterialAdicional

= 5897, 60 + 311, 08 + 825, 60 + 39, 50 = 5159, 15 euros
A este importe, le incrementaremos el valor en un 17 %, correspondiente a lo que se ha

estimado en costes indirectos. Además de esto aplicaremos el IVA del 21 %, desglosando
el importe total en los siguientes valores:
Concepto Valor (e)

Costes directos 7073,78
Costes indirectos 1202,54
Costes totales sin IVA 8276,32
Costes totales con IVA 7491,08
TOTAL 10.014,35
Tabla 3.112. Desglose del coste total
Por tanto, el presupuesto final de este proyecto aplicando un IVA del 21 % es de

DIEZ MIL CATORCE COMA TREINTA Y CINCO euros.
80
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
4. EJECUCIÓN DEL PROYECTO
En este capítulo detallamos como se ha llevado a cabo el diseño y la implementación

del sistema tras el análisis realizado.
Como ya hemos especificado en el capítulo anterior, el desarrollo del proyecto se divi-
dirá en tres fases principalmente una vez completado el análisis inicial: una primera fase
en la que diseñaremos como va a ser el entorno además de la arquitectura del sistema; una
segunda fase en la que implementaremos dicho entorno a través de la herramienta Unity,
modelando los objetos 3D; y finalmente, una tercera fase en la que convertiremos el en-
torno 3D construido en un entorno reactivo teniendo en cuenta la arquitectura previamente
diseñada.
Teniendo esto en cuenta, concluimos que la primera fase, coincide enteramente con
la fase de diseño de nuestra metodología, mientras que la segunda y tercera fase, se trata
de la implementación, que para mayor sencillez, se ha dividido en la implementación del
entorno 3D por un lado y la implementación de las reacciones del sistema y acciones del
usuario por otro.
4.1. Diseño del entorno virtual y la arquitectura del sistema
En primer lugar, realizaremos el diseño del entorno virtual para posteriormente, esta-
blecer cual será la arquitectura de nuestro sistema.
4.1.1. Entorno virtual
Llegados a este punto, somos conocedores de que debemos diseñar el entorno de una
vivienda que cuente con las siguientes estancias básicas:
Cocina: Donde se desempeñará las acción simulada de cocinar al interactuar con

el fogón y se podrá encender o apagar la luz. Además, toda cocina consta de un
fregadero con lo cual podremos interactuar con el grifo de esta estancia.
Habitación principal: En esta estancia se podrá interactuar con las luces, así como
realizar la acción de dormir.
Comedor: Aquí se desempeñará la acción simulada de alimentarse, al sentarse en la

mesa. Además se podrá interactuar con las luces.
Salón: Donde se desempeñan actividades de relajación, podremos interactuar con

las luces o sentarnos en el sofá.
81
Baño: Podremos interactuar con los grifos que se encuentran en esta estancia para
simular la acción de visitar el baño, además de interactuar con las luces.
Identificadas las estancias, efectuaremos el diseño del entorno, que será el que se
muestra en la siguiente figura:
Fig. 4.1. Diseño de la vivienda
Como se puede observar, este tendrá los elementos necesarios para interactuar con
todos los elementos que se describen en los requisitos y los casos de uso, a excepción
de las luces que no aparecen en la figura pero se presupone su existencia en todas las
estancias.
No obstante, como ya especificamos en el capítulo del “Estado de la cuestión” la
implementación de Inteligencia Ambiental en el entorno se caracteriza por la alta senso-
rización del mismo. Obviamente, al estar diseñando un entorno de realidad virtual que se
controla enteramente de forma digital, no será necesario modelar e incluir sensores puesto
que podemos controlar el entorno igualmente sin la acción de estos. Sin embargo, si que
nos parece adecuado hacer un pequeño resumen de los sensores que utilizaríamos en el
82
caso de estar implementando el sistema en un entorno real. A continuación, enumeramos

dichos sensores y actuadores y la función que desempeñaría en el sistema.
Tipo de sensor / actuador Uso

Se encontrarán situadas en todas las fuentes de
luz de la vivienda. Estas bombillas permiten
modificar su color, luminosidad y estado
(apagado o encendido) de forma remota, sin
tener que activar un interruptor manual (aunque
Bombilla inteligente obviamente también se pueden accionar de esta
manera).
Será el sensor encargado de detectar la aparición

de fuego, de forma que este se detecte lo antes
posible y se pueda avisar tanto al usuario de la
vivienda como a los supervisores.
Detector infrarrojo fuego
Este sensor detecta si existen partículas de gas

en el ambiente, el cual en grandes cantidades
puede incluso llegar a ser mortal.
Detector de gas
Gracias al sensor del caudalímetro se puede

determinar si existe o no caudal de agua en la
tubería, de manera que si se detecta que el
usuario no se encuentra en la estancia (con el
Caudalímetro y electroválvula sensor de presencia) se podría cerrar el flujo
mediante la activación de una electroválvula.
Se trata de un sensor inalámbrico que se instala
bajo el colchón y es capaz de determinar si el
usuario se encuentra o no tumbado en la cama.
Detector presencia en cama
83
Estos sensores se colocan en el techo, y son

capaces de detectar la presencia de movimiento
en la estancia, de manera que podemos conocer
si el usuario se encuentra en una habitación o en
otra colocando estos dispositivos en cada una de
Detector de presencia las estancias.
Al igual que el sensor de la cama, este se coloca

en los asientos, de manera que se detecta si el
usuario se encuentra sentado o no.
Detector de presión asiento
Tabla 4.1. Sensores a implementar por el sistema en entorno físico
En la siguiente figura se observa donde se colocarían dichos sensores. No se muestra

en el diagrama la colocación de las bombillas inteligentes, ya que todas las fuentes de luz
de la vivienda constarían de bombillas de ese tipo.
Fig. 4.2. Colocación de sensores
84
Destacamos también, aunque no aparece en estos diagramas y no es un sensor propia-

mente dicho, la pulsera inteligente que llevaría el usuario en todo momento en el caso de
tratarse de un entorno físico. Esta dispondría de sensores capaces de medir la temperatura,
la frecuencia cardíaca, así como un giroscopio para la detección de caídas.
4.1.2. Interfaces
Por otro lado, además de diseñar el entorno y la sensorización virtual del mismo,
también debemos diseñar las diversas interfaces que tendrá nuestro sistema y que hemos
identificado en la tarea del análisis. Estas son las siguientes:
Fig. 4.3. Pantalla principal y pulsera inteligente
La interfaz de interacción principal del usuario con el entorno, en la que podremos

ver el entorno 3D diseñado cuando manejemos el usuario virtual desde un punto de vista
en primera persona y además, se mostrará en la esquina inferior izquierda la información
que podríamos ver en la pulsera inteligente: hora, temperatura y frecuencia cardíaca.
85
Fig. 4.4. Ventana de selección de horas para dormir
La ventana modal que aparecerá cuando se interactúe con la cama, en la que se podrá
elegir a través del selector deslizable las horas que se quieren dormir. Debajo del selector
aparecerán las horas seleccionadas, siendo 1 hora el mínimo (y seleccionada por defecto)
y 10 horas el máximo. Finalmente tendrá un botón “Aceptar” para guardar los cambios y
efetuar la acción de dormir y un botón “Cancelar” que permitirá cancelar la acción.
Fig. 4.5. Ventana de administración
86
Finalmente tenemos la pantalla de administración a la que podremos acceder a través

de la pulsación del botón “Escape”. En ella podemos ver la ventana de notificaciones en
las que se visualizaran todos los mensajes que emita el sistema. En la parte inferior, se
listan todas las modificaciones que puede realizar el usuario administrador en el entorno:
cambiar la hora, temperatura y pulso y los checkboxes para generar la caída del usuario
o generar un fuego o fuga de gas en la cocina. Finalmente un botón aceptar con el que
guardar los cambios realizados.
4.1.3. Arquitectura del sistema
Una vez diseñado el entorno virtual que implementaremos, y las interfaces, deberemos
especificar la arquitectura que tendrá nuestro sistema.
Seguiremos una arquitectura clásica de aplicación en tres capas en las que los distintos
elementos que componen cada capa se comunican unos con otros. Estas capas son las
siguientes:
Capa de presentación: Será la encargada de mostrar la interfaz gráfica e interaccio-

nar con el usuario a través de los controles.
Capa de negocio: Esta capa es la que contiene la lógica del sistema, procesa las
peticiones que realiza la capa de presentación.
Capa de datos: Se encarga de gestionar los datos que maneja el sistema. En nuestro
caso esta capa no se implementará puesto que no vamos a almacenar ningún tipo de
información de forma persistente.
Cabe destacar que dentro de las capas de presentación y negocio (que han sido las que
se han implementado) se ha realizado una subdivisión en subsistemas, que a su vez con-
tienen componentes que representan funciones que requiere la aplicación para funcionar
correctamente. A continuación se muestra el diagrama que se ha confeccionado:
87
Fig. 4.6. Diagrama de componentes del sistema
88
En primer lugar tenemos el subsistema de control, que pertenece a la capa de presen-

tación. Engloba el componente de Controlador del usuario, que ofrece los controles del
mismo para que se puedan ejecutar las diferentes acciones.
El otro subsistema de la capa de presentación es el de gráficos, que mostrará todos
los elementos relacionados con la interfaz del juego, es decir, el propio entorno virtual, el
menú de administración y la pulsera virtual del usuario.
Si nos fijamos en la capa de negocio tenemos dos subsistemas, el subsistema de ges-
tión del entorno, que se encargará de todas las acciones que tienen que ver con el mismo, y
el subsistema de gestión gráfica, que se encargará de modificar los valores de los distintos
elementos de interfaz gráfica (a excepción del entorno).
Concretamente, en el subsistema de gestión del entorno tenemos los componentes:
Controlador del entorno virtual: se encargará de exponer dos interfaces, la que mo-
difica el entorno virtual y la que lo actualiza de cara a la capa de presentación para
que dichas modificaciones se vean reflejadas en pantalla.
Controlador de acciones: se encargará exponer la interfaz para permitir las acciones

del usuario que llegan a través de los controles y en función de estas se comunica
con el componente que controla el entorno virtual para modificarlo y con el compo-
nente del controlador inteligente, al que comunicará todas las acciones que realiza
el usuario para que este reaccione en consecuencia.
Controlador inteligente: se encargará de reaccionar ante las acciones que realiza el

usuario, y modificar así el entorno virtual. Adicionalmente escribirá los mensajes
al menú de administración y recibirá información de la pulsera inteligente (en caso
de que el usuario solicite ayuda o responda en el caso de caída)
Por otro lado, en el subsistema de gestión gráfica tenemos los siguientes componentes:
Gestor menú administración: Este componente se encarga de exponer la interfaz

para actualizar los valores y mensajes que se muestran en este menú. Además inter-
actúa con el controlador de entorno virtual para modificarlo en base a las opciones
del menú administrador, al igual que sucede con la interacción de la pulsera virtual.
Escribirá los mensajes que recibe por parte del controlador inteligente, que después
mostrará en la ventana de notificaciones gracias a la interfaz expuesta.
Gestor pulsera virtual: Este componente expone la interfaz para actualizar los valo-
res que muestra la pulsera en la capa de presentación. Además recibe mensajes del
controlador inteligente cuando este detecta peligros (fuego, fuga de gas, etc) y le
reenvía la información en los casos en los que el usuario interactúa con la pulsera.
Además modifica los valores de la pulsera en base a la edición que se realiza de
estos en el menú de administración.
89
4.2. Implementación del entorno virtual diseñado
Una vez que hemos finalizado el diseño del entorno virtual, así como de sus compo-
nentes, nos introduciremos en la segunda fase que se identifica para este proyecto, en la
que implementaremos dicho entorno en tres dimensiones.
Para ello, modelaremos la vivienda que se ha diseñado en la fase 1, y la poblaremos
de todos los elementos con los que el usuario podrá interactuar, así como otros que serán
meramente decorativos pero aportarán realismo al entorno.
Aunque a raíz del estudio sobre utilización de herramientas para construir el entorno,
extraemos que utilizamos Unity, debemos tener en cuenta que para realizar modelado en
3D y la aplicación de texturas a dicho modelo, no podremos utilizar esta herramienta,
dado que existen otras especializadas en ese ámbito con las que nos resultará mucho más
sencillo llevar al plano tridimensional la vivienda diseñada.
Para nuestro caso concreto, hemos utilizado la herramienta SketchUp, dado que es
muy simple de utilizar y se puede hacer uso de ella enteramente a través de su aplicación
web sin necesidad de instalar ningún programa. Dicho lo cual, teniendo en cuenta el
diseño expuesto en la anterior fase, el resultado de modelar la vivienda fue el que se ve en
la siguiente figura.
Fig. 4.7. Modelado de la estructura de la vivienda
90
Como podemos observar, se han modelado todas las estancias y se han agregado tex-
turas a suelos, paredes y otros elementos como ventanas y puertas.
Gracias a una de las principales características que nos hizo decantarnos por utili-
zar Unity para llevar a cabo este proyecto (la gran compatibilidad de este con distintos
formatos de modelos 3D), podremos importar este modelo en la herramienta y, una vez
colocado, comenzar a poblarlo con los distintos elementos.
Cabe destacar que dichos elementos no los hemos modelado manualmente (como si
hemos hecho con la estructura de la casa) si no que hemos utilizado el amplio catálogo
de modelos que ofrece Unity, así como modelos encontrados en página web que disponen
también de una amplia selección de estos.
Finalmente, el resultado de incluir los muebles y elementos en la vivienda, ya desde
la herramienta Unity, ha sido el siguiente:
Fig. 4.8. Modelado de la estructura de la vivienda
En esta imagen podemos observar la existencia de los distintos elementos que ya ha-
bíamos identificado en el propio diseño. No obstante, tal y como especificamos, no se
observan los sensores puesto que al tratarse de un entorno meramente digital, podremos
modificar cada elemento sin necesidad de simular la sensorización que posee un sistema
que implementa Inteligencia Ambiental.
Además de implementar el entorno virtual, en esta fase también implementaremos las
interfaces especificadas, para en la siguiente fase, poder completarlas con la capacidad
91
interactiva que deben poseer.
4.3. Implementación de un entorno reactivo
Finalmente, en la tercera fase del proyecto (que también forma parte del proceso de
implementación), una vez que dispongamos del entorno construido así como sus interfa-
ces, implementaremos la capa de negocio propiamente dicha.
Cabe destacar que esta implementación se ha realizado enteramente con la herramien-
ta Unity utilizando el lenguaje de programación orientado a objetos C#. Unity proporciona
un bucle infinito mientras dura la simulación, durante la cual se ejecutará la funcionalidad
de los subsistemas que conforman la aplicación.
4.3.1. Subsistema de gestión de entorno
Este subsistema se encarga de controlar todo aquello que tiene que ver con el entorno
virtual. Tal y como se ha definido en el diseño, se crea el componente “Controlador de ac-
ciones” que se encargará de interpretar las acciones del usuario y posteriormente llamará
a los métodos correspondientes del “Controlador del entorno” para efectuar los cambios
que sean necesarios.
La navegación del usuario a través del entorno, es decir, el desplazamiento del mismo
y el movimiento de la cámara, se ha implementado en el componente “Controlador de
acciones” a través de un Asset (módulo ofrecido por Unity) que proporciona un elemento
plenamente funcional para permitir el control del usuario por teclado y ratón. Este Asset se
ha modificado para incluir dos funcionalidades adicionales: la posibilidad de interactuar
con objetos al pulsar la tecla “E” y la interacción con la pulsera, bien sea para la llamada
de asistencia al pulsar la tecla “F” o la respuesta que debe dar el usuario sobre si necesita
ayuda cuando se detecta una caída del mismo (teclas “Y” o “N”).
Cabe destacar que para saber con qué elemento esta interaccionando el usuario, se
utilizará la técnica de Ray-Casting, muy utilizada en sistemas con gráficos por ordenador.
Esta técnica consiste en lanzar un rayo cada vez que el usuario pulse la tecla de interacción
(la tecla “E”) desde el centro de la pantalla en dirección hacia delante y hasta una distancia
determinada. Cuando dicho rayo (que es invisible para el usuario que utiliza la aplicación)
intersecciona con el elemento que se encuentra frente al jugador, se evalúa si este es un
elemento interactuable (un interruptor, el grifo, etc). Si resulta serlo y en función de qué
elemento sea, se llamará a la acción pertinente que ofrece el módulo de “Controlador de
entorno” para que cambie el entorno tras la interacción del usuario.
El módulo que controla el entorno por tanto, dispondrá de funciones para modificar
las propiedades de los distintos elementos que forman el entorno virtual:
Encender/Apagar luces: en función de con que fuente de luz se interactúe y el estado
92
de la misma se apagará o se encenderá.
Abrir/Cerrar grifo: Al igual que sucede con la iluminación, en función de con qué
grifo interactuemos (baño o cocina) y el estado en el que estuviera, se iniciará el
flujo del agua o se cerrará.
Encender/Apagar fogón: Se encenderá o apagará en función del estado anterior en

el que se encontrase.
Dormir: Se mostrará la interfaz para seleccionar el número de horas que se quiere

dormir y al aceptar la acción, se modificará la hora del entorno.
Sentarse/Levantarse: Esta no modifica directamente el entorno de forma percepti-

ble, si no que cancelará el movimiento del usuario.
En el caso de la interacción con la pulsera que realiza el usuario a través del “Con-
trolador de acciones”, esta acción la detectará el propio sistema a través del componente
“Controlador Inteligente” que enviará la información al componente que gestiona la pul-
sera o al que gestiona la pantalla de administración.
Además, este componente que es el último que conforma nuestro subsistema, se en-
cargará de detectar las acciones que realiza el usuario, y en base a ellas reaccionar de una
forma u otra modificando las características del entorno mandando la información per-
tinente (igual que cuando el usuario interacciona) al módulo “Controlador de entorno”.
Por ejemplo, cuando el usuario se olvide el grifo abierto, la luz o el fogón y salga de la
estancia en la que se encuentra el elemento, este módulo lo detectará, y pondrá en marcha
un contador medidor del tiempo que pasa el usuario fuera de la estancia con el elemento
activo. Si se vence el tiempo especificado en los requisitos, será el propio controlador el
que llame a la acción de apagar luz, cerrar el grifo o apagar el fogón según corresponda.
También se encargará de la detección de fuego, gas o caídas (generadas por el usuario
administrador) y reaccionará ante el comportamiento extraño del usuario, actuando en
consecuencia enviando notificaciones a la pulsera y emitiendo mensajes para los supervi-
sores a la ventana de notificaciones.
4.3.2. Subsistema de gestión gráfica
Este subsistema se encarga de controlar aquello que tiene que ver con las interfaces
del menú de administrador y de la pulsera virtual.
En el caso del módulo “Gestor del menú de administrador”, este llamará a las fun-
ciones de modificar el entorno o modificar los valores de la pulsera en función de las
opciones que seleccione el usuario.
Para las opciones de generar fuego, fuga de gas o caída, se generarán dichos escenarios
en el entorno virtual. En el caso de la implementación del fuego y la fuga de gas, se han
93
utilizado sistemas de partículas provistos en los Assets de Unity que se muestran u ocultan
en función de si la opción está activada o no, mientras que para la caída se prohíbe el
movimiento del usuario en el entorno y el módulo “Controlador Inteligente” procederá a
realizar las acciones necesarias tras la detección de la caída.
En el caso de modificar los valores de hora, temperatura o pulsaciones, se llamarán a
las funciones expuestas por el módulo “Gestor pulsera virtual” para modificar los valores
mostrados. Además, igual que sucede en otros casos, el módulo “Controlador Inteligente”
detectará dichos cambios y mandará los mensajes pertinentes a la ventana de notificacio-
nes.
Finalmente, el módulo ”Gestor pulsera virtual”, únicamente gestiona los valores de
hora, pulsaciones y temperatura e incorpora funciones para emitir notificaciones en la
misma o recibir información del controlador inteligente (respuesta del usuario cuando se
le pregunta si se encuentra bien tras la caída, o solicitud de ayuda por parte del usuario).
94
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
5. DESCRIPCIÓN DE RESULTADOS
En este capítulo se recogen los resultados tanto de validación, como de ejecución que
se han obtenido tras la realización de este proyecto. En los resultados de validación se
exponen las pruebas que se han realizado sobre el sistema de expansión presentado en el
capítulo anterior y que ya fueron establecidas en el plan de pruebas del capítulo “Defini-
ción del proyecto”. En el caso de los resultados referentes a la ejecución del proyecto, se
expone la ejecución temporal y el coste del mismo y se compara con la planificación y el
presupuesto realizados previamente.
5.1. Validación
Para verificar que el sistema desarrollado funciona perfectamente, se estableció un

plan de pruebas en el capítulo del análisis en el que determinamos las pruebas que debía
superar nuestro sistema.
En los siguientes apartados, organizados según los tipos de prueba, se describe en
forma de tablas los resultados obtenidos para las pruebas que se han realizado sobre el
sistema. La tabla que se ha usado para representar cada prueba ha sido la siguiente:
PS-XX
Módulo presentación : Módulo(s) afectado(s) de la capa de presentación
Módulo negocio : Módulo(s) afectado(s) de la capa de negocio
Resultado obtenido : Resultado obtenido
Tabla 5.1. PS-XX: Plantilla de pruebas
Dónde los campos de las tablas indican lo siguiente:
PS-XX : Identifica que se trata de una prueba de sistema XX indica la numera-

ción de cada tipo de prueba. Ambos valores en conjunto forman el identificador de
la prueba. Estos valores coinciden para las pruebas establecidas en el capítulo de
“Definición del proyecto”.
Módulo presentación : Módulos de la capa de presentación que se ven afectados

por esta prueba.
Módulo negocio : Módulos de la capa de negocio que se ven afectados por esta
prueba.
Resultado obtenido : Resultado que ha arrojado la prueba tras su realización.
95
PS-01
Módulo presentación : Controlador de usuario, entorno virtual
Módulo negocio : Controlador de acciones, Controlador entorno virtual
Resultado obtenido : El usuario se desplaza correctamente en todas direcciones, respe-
tando la existencia de objetos o paredes.
Tabla 5.2. PS-01
PS-02
Resultado obtenido : La luz se enciende si está apagada o se apaga si está encendida.
Tabla 5.3. PS-02
PS-03
Resultado obtenido : El fogón se enciende si está apagado o se apaga si está encendido.
Tabla 5.4. PS-03
PS-04
Resultado obtenido : El grifo se abre si está cerrado o se cierra si está abierto
Tabla 5.5. PS-04
PS-05
Resultado obtenido : El usuario se sitúa en la silla / sofá y no se puede mover, al pulsar
la tecla de interacción se recupera el movimiento.
Tabla 5.6. PS-05
96
PS-06
Módulo presentación : Controlador de usuario, entorno virtual, pulsera virtual
Módulo negocio : Controlador de acciones, Controlador entorno virtual, Gestor pul-
sera virtual
Resultado obtenido : Al interactuar con la cama aparece el menú, se seleccionan las ho-
ras y tras aceptar la acción de dormir se visualiza que la hora ha
cambiado siendo 8 horas más.
Tabla 5.7. PS-06
PS-07
Módulo presentación : Controlador de usuario, entorno virtual, pulsera virtual
Módulo negocio : Controlador de acciones, Controlador entorno virtual, Gestor pul-
sera virtual
Resultado obtenido : Al interactuar con la cama aparece el menú y al pulsar el botón
cancelar, se aborta la acción de dormir y se visualiza que la hora
sigue siendo la misma.
Tabla 5.8. PS-07
PS-08
Módulo presentación : Controlador de usuario, menú administración
Módulo negocio : Controlador de acciones, Controlador inteligente, gestor menú ad-
ministración
Resultado obtenido : Al interactuar con la pulsera aparece el mensaje indicado en la ven-
tana de notificaciones
Tabla 5.9. PS-08
PS-09
Módulo presentación : Menú administración, pulsera virtual
Módulo negocio : Gestor menú administración, Gestor pulsera virtual
Resultado obtenido : Al modificar la hora, en la pulsera se visualiza que marca las 17:00
Tabla 5.10. PS-09
97
PS-10
Módulo presentación : Menú administración, pulsera virtual, entorno virtual
Módulo negocio : Controlador entorno virtual, Controlador Inteligente, Gestor menú
administración, Gestor pulsera virtual
Resultado obtenido : Aparece fuego en la cocina, aparece la notificación en la pulsera y
el mensaje indicado en la ventana de notificaciones
Tabla 5.11. PS-10
PS-11
Módulo presentación : Menú administración, pulsera virtual, entorno virtual
Módulo negocio : Controlador entorno virtual, Controlador Inteligente, Gestor menú
administración, Gestor pulsera virtual
Resultado obtenido : Aparece fuego en la cocina, aparece la notificación en la pulsera y
el mensaje indicado en la ventana de notificaciones
Tabla 5.12. PS-11
PS-12
Módulo presentación : Controlador usuario, menú administración, pulsera virtual, entorno
virtual
Módulo negocio : Controlador entorno virtual, Controlador de acciones, Controlador
Inteligente, Gestor menú administración, Gestor pulsera virtual
Resultado obtenido : El usuario pierde la capacidad de moverse, en la venta de notifica-
ciones aparece un mensaje informando de la caída. Llega un men-
saje a la pulsera que indica que contestemos si necesitamos ayuda
o no, y al contestar afirmativamente en la ventana de notificaciones
aparece el mensaje indicando la necesidad de ayuda del usuario.
Después el usuario recupera la capacidad de movimiento para con-
tinuar la simulación.
Tabla 5.13. PS-12
98
PS-13
virtual
o no, y al contestar negativamente en la ventana de notificaciones
aparece el mensaje indicando que el usuario se encuentra bien. Des-
pués el usuario recupera la capacidad de movimiento para continuar
la simulación.
Tabla 5.14. PS-13
PS-14
virtual
o no, y al no contestar, pasados 50 segundos, en la ventana de no-
tificaciones aparece el mensaje indicando que el usuario no ha res-
pondido. Después el usuario recupera la capacidad de movimiento
para continuar la simulación.
Tabla 5.15. PS-14
PS-15
Módulo negocio : Controlador inteligente, Gestor menú administración, Gestor pul-
sera virtual
Resultado obtenido : Aparece la temperatura de 37,5 grados en la pulsera.
Tabla 5.16. PS-15
99
PS-16
sera virtual
Resultado obtenido : Aparece la frecuencia cardiaca de 50 pulsaciones en la pulsera.
Tabla 5.17. PS-16
PS-17
sera virtual
Resultado obtenido : Aparece la frecuencia cardiaca de 110 pulsaciones en la pulsera.
Tabla 5.18. PS-17
PS-18
inteligente
Resultado obtenido : La luz de la estancia se apaga sola.
Tabla 5.19. PS-18
PS-19
inteligente
Resultado obtenido : El fogón encendido se apaga solo.
Tabla 5.20. PS-19
PS-20
inteligente
Resultado obtenido : El grifo abierto deja de expulsar agua.
Tabla 5.21. PS-20
100
PS-21
Módulo presentación : Controlador de usuario, entorno virtual, menú administrador
Módulo negocio : Controlador entorno virtual, Controlador de acciones, Gestor menú
administración, Controlador inteligente
Resultado obtenido : Aparece el mensaje indicado en la ventana de notificaciones
Tabla 5.22. PS-21
PS-22
Tabla 5.23. PS-22
PS-23
Tabla 5.24. PS-23
PS-24
Tabla 5.25. PS-24
PS-25
Tabla 5.26. PS-25
101
5.2. Conclusiones de la evaluación
Para finalizar con la evaluación del sistema, comentamos que los resultados que este
arrojó fueron los esperados. Las acciones que realiza el usuario, como hemos podido
observar, tienen un impacto directo en el sistema, actuando este por cuenta propia cuando
así se requiere.
Con esta implementación, hemos podido observar el impacto y beneficios que tiene
un sistema de Inteligencia Ambiental en el día a día de personas de la tercera edad, o con
enfermedades, que son propensas a tener olvidos o accidentes. De esta forma, se mejora
su independencia, pero sin “abandonarlos”, ya que será el sistema inteligente el que de un
soporte primario y, si fuera necesaria una intervención mayor, se avisará a las personas
adecuadas para que tomen las acciones oportunas.
Con esto damos por finalizada la implementación de un entorno de Inteligencia Am-
biental en Realidad Virtual de forma satisfactoria, ya que hemos podido observar las ca-
racterísticas de este tipo de entornos sin invertir tiempo y costes en adecuar un espacio
físico, lo cual, era el objetivo de este proyecto.
102
5.3. Resumen de ejecución del proyecto y costes
En este punto se explica detalladamente la planificación real que ha llevado a cabo

durante la realización del proyecto; esta planificación real se comparará con la planifica-
ción inicial y, como resultado de dicha comparación, podremos observar las desviaciones
y retrasos sufridos durante el proyecto. Por otro lado, se detallan los costes reales que
ha supuesto la realización del proyecto. Este cálculo final de costes se comparará con
el presupuesto que se dio inicialmente, para analizar las desviaciones producidas por las
diferencias entre la planificación estimada y la real.
5.3.1. Planificación Final
Esta sección tiene como objetivo principal presentar de una manera detallada el tiempo
real que se ha dedicado en cada fase del proyecto. Esta ejecución se reflejará con un
diagrama de Gantt, en el que podremos visualizar las subtareas de cada fase y la duración
de las mismas.
La fecha de comienzo del proyecto se estableció el día 3 de febrero de 2020, mientras
que la fecha de finalización se sitúa el día 9 de agosto de 2020. En ese lapso de tiempo
se deberían realizar las diferentes fases en las que dividió el proyecto en la planificación
inicial: Definición del proyecto, Análisis, Diseño, Implementación, Pruebas y Documen-
tación, es decir, el documento que nos ocupa.
Sin embargo, durante la realización del proyecto fueron surgiendo diversos problemas
e inconvenientes en algunas de las fases mencionadas anteriormente. Como resultado de
esos contratiempos la duración de las fases no ha sido exactamente como se había planifi-
cado inicialmente, por lo que las fechas han variado ligeramente. No obstante, gracias al
margen temporal que se había establecido para paliar posibles contratiempos, el proyecto
sí que ha finalizado dentro de los plazos establecidos.
En primer lugar, como fase inicial del proyecto, se estableció una fase de Definición
del proyecto que tenía una duración estimada de 15 días; entre el 3 y el 17 de febrero de
2020. Sin embargo, fueron necesarios dedicar dos días más de lo estimado inicialmente.
Durante esta fase se llevó a cabo el estudio sobre la Inteligencia Ambiental y sus posibi-
lidades para poder establecer nuestros objetivos de una manera más concisa, así como la
planificación y el presupuesto que se estimaron en un primer momento.
La siguiente fase, la fase del Análisis, tenía estimada una duración de 20 días entre el
18 de febrero y el 8 de marzo de 2020. Esta fase sufrió una desviación de 5 días debido
a la necesidad de establecer los requisitos de una manera clara y concisa. Este proceso
de identificación de casos de uso y establecimiento de requisitos así como de definición
de pruebas sufrió un retraso debido a la necesidad de revisar y redefinir los requisitos a
medida que se avanzaba en el proyecto.
Posteriormente al Análisis, se encontraba la fase de Diseño, estimada con una duración
103
de 18 días entre el 9 de febrero y el 26 de marzo de 2020. Durante esta fase se realizó

el diseño de los componentes de la aplicación así como del entorno virtual. Durante la
ejecución de esta fase no hubo problemas importantes y únicamente hubo un retraso de
dos días.
A continuación de la fase de Diseño se estableció la fase de Implementación con una
duración estimada de 53 días entre el 27 de marzo y el 18 de mayo de 2020. Al hablar
de esta etapa resulta conveniente remarcar que se comenzó dos semanas más tarde de lo
especificado debido a la situación que asolaba a nuestro país. La aparición de la pandemia
e infección de familiares cercanos produjo que en estas dos semanas no se pudiera dedicar
tiempo a la realización del proyecto. Debido al retraso que se había acumulado de las fases
anteriores más la falta de dedicación tras la finalización de la fase de diseño, fue necesario
adelantar trabajo para que los tiempos no se excedieran demasiado, pero únicamente se
consiguió acortar la duración a 51 días, ya que se trataba de una fase crítica que requería
mucha dedicación.
Finalmente, la última fase relacionada con el desarrollo del sistema, la fase de Pruebas,
tenía una duración inicial estimada en 30 días; entre el 19 de mayo y el 17 de junio de
2020. Durante esta fase se ejecutaron en el sistema las pruebas definidas en la fase de
Análisis y, sumado al retraso que ya llevábamos, realizamos esta fase en un día más de
lo estimado, debido a la necesidad de corregir fallos y comportamientos erróneos del
sistema.
Paralelamente a las fases explicadas anteriormente, estas se iban documentando con
bajo detalle, para que cuando finalizase la implementación del sistema, poder ir rellenando
en este documento las partes relacionadas con cada fase. Esta fase de Documentación
tenía una duración prevista de 53 días; entre el 18 de junio y el 9 de agosto de 2020. No
obstante, debido al retraso acumulado en las fases anteriores así como a las revisiones
realizadas sobre el documento, está comenzó sustancialmente más tarde, el 12 de julio de
2020 (casi un mes más tarde). fue necesario adelantar trabajo para que la finalización del
proyecto entrara dentro de los plazos marcados. De esta manera, se consiguió finalizar
esta fase cuatro días antes de la fecha estimada.
A continuación se presenta en una gráfica la desviación sufrida en cada fase respecto
a la estimación inicial.
104
Fig. 5.1. Gráfico comparativo días reales vs días estimados
De esta manera, el proyecto sufre un retraso respecto a la fecha inicial de 20 días. No

obstante, como se había dejado un colchón de 24 días para posibles imprevistos, la fecha
de finalización entra dentro de los plazos marcados situando el día 29 de Agosto como
nueva fecha de finalización del proyecto.
Finalmente se presenta el diagrama de Gantt con la ejecución final del proyecto indi-
cando las fechas de cada fase.
105
Fig. 5.2. Diagrama de Gantt de la planificación final
106
Una vez que hemos expuesto el diagrama de Gantt, aclaramos como se ha repartido el
trabajo durante los 209 días que duró el proyecto. Aunque también tendremos en cuenta
que no se trabajó durante 14 días en este transcurso de tiempo debido al efecto de la
pandemia mundial.
Puesto que era necesario compaginar la realización del proyecto con el trabajo, y
por ello se estimó una dedicación diaria de 1,69 horas, aproximadamente 12 horas a la
semana. No obstante, debido a las obligaciones del trabajo, entre semana (de lunes a
viernes) le dedicábamos un tiempo medio de 4 horas, mientras que los fines de semana,
dedicábamos 7 horas y media para compensar dado que se disponía de mayor tiempo.
Esto hace que el tiempo medio a la semana fuese el siguiente:
HorasdiasLaborables + HorasdiasFinDeS emana = 4 + 7,5 = 11,5 horas/semana
Puesto que el desempeño en nuestro proyecto se mide en días y no en semanas debe-

mos calcular el tiempo de trabajo medio al día que habría supuesto dedicar estas 11 horas
y media, repartidas entre los días de la semana:
Horas semana 11,5

= = 1,64 horas/dia
7 7
Como sabemos, el proyecto ha tenido una duración total de 209 días, de los cuales,
14 no se trabajó. No obstante, se incluyen también en el cálculo puesto que, aunque no se
dedicasen a la realización del trabajo, si que afectó a la duración total del proyecto. Por
tanto, la dedicación total ha sido la siguiente:
Horasdia · Dias proyecto = 1,64 · 209 = 342,76 horas
Por tanto, tenemos que se estimó en un primer momento que se iba a trabajar al día
una media diaria de 1,69 horas (unas 12 horas a la semana) y finalmente se ha trabajado
ligeramente por debajo (a 1,64 horas al día y 11 horas y media a la semana). Esto se
ha reflejado en las pequeñas desviaciones sufridas en algunas de las fases, en las que
tardábamos algo más en finalizarlas que lo que se había estimado en un principio.
No obstante, lo que descuadra completamente la planificación y aumenta considera-
blemente el tiempo destinado a la realización del proyecto, ha sido la situación vivida en
los meses de cuarentena. Durante dos semanas no se realizó ninguna actividad que tuviera
que ver con el proyecto, por lo que se retrasaron las fechas de comienzo de las fases que
restaban por completar. De ahí que tardemos 209 días en finalizar el proyecto, en lugar de
los 189 que se habían planificado en un primer momento. Aun así, gracias a la previsión
de riesgos en la que se destinaron 24 días de margen temporal por si acaso sucedieran
imprevistos, se pudo finalizar el trabajo en tiempo, utilizando 20 días de dicho margen.
107
5.3.2. Análisis de costes
Una vez expuesta la planificación, podemos calcular los costes reales de la realización
de este proyecto. Para llevarlo a cabo, se ha estudiado el origen de los costes directos e
indirectos al igual que ya se hizo en el capítulo “Definición del proyecto”.
Para los costes directos, en el caso de los costes de personal tomaremos el coste por
hora calculado en el apartado de la estimación de costes y las horas totales de ejecución
del proyecto presentadas en la sección anterior. Tendremos dos tipos de costes, en el caso
de las horas que caen dentro de los límites establecidos de la estimación, será de 18,43
e/hora mientras que para el resto del tiempo (las horas destinadas durante los 20 días
extras en los que hicimos uso del margen temporal) el coste será de 20,64 e/hora.
De esta forma el coste de horas normales será de:
Preciohora_normal · T otalhoras_normales = 18,43 · 309,96 = 5712, 56 euros
Mientras que el coste de horas extra será:
Preciohora_normal · T otalhoras_normales = 20,64 · 32,8 = 676,99 euros
Siendo el coste de personal total el siguiente:
Coste personal_normal + Coste personal_extra = 5712, 56 + 676, 99 = 6389, 55 euros
En el caso de los costes de material, puesto que se han agotado los días estimados de
realización del proyecto, serán los 311,08 euros previamente calculados, a lo que se le
sumará la parte proporcional de uso material de los días extra. Puesto que este sobrecoste
se estimó en 39,50 euros en el caso de utilizar los 24 días, y solamente hemos utilizado el
material durante 20 días más, el coste será algo menor.
diasextra · Coste_materialextra 20 · 39, 50

= = 32, 91 euros
diasmargen 24
Adenñas, dado que no existían costes relacionados con el software, los costes de ma-
terial totales ascenderán a:
Costematerial_normal + Costematerial_extra = 311, 08 + 32, 91 = 343, 99 euros
Por lo que los costes directos totales sumarán un total, entre gastos humanos y mate-
riales, de:
CostesPersonal + Costes Materiales = 6389, 55 + 343, 99 = 6733, 54 euros
108
Aplicando de igual manera que en el presupuesto, unos costes indirectos del 17 %, y

aplicando un IVA del 21 %, obtenemos el siguiente desglose de costes:
Concepto Valor (e)

Costes directos 6733,54
Costes indirectos 1144,70
Costes totales Sin IVA 7878,24
Costes totales Con IVA 7242,72
TOTAL 9532,67
Tabla 5.27. Desglose del coste real total
Como podemos observar, este valor está por debajo de los 10,014, 35 euros estimados.
Esto es así debido a que en la estimación, se tuvo en cuenta agotar completamente los días
disponibles para la realización del proyecto, es decir, los 189 días con los 24 destinados al
margen. Por lo que incluimos un ligero sobrecoste en caso de que finalmente tuviéramos
que hacer uso de los días de margen. Finalmente, ha resultado ser así, pero no se han
llegado a utilizar los 24 días, sino que únicamente se han utilizado 20. Por ello, el coste
real es ligeramente inferior al coste estimado.
Finalmente, establecemos el coste real total de la realización de este proyecto en
NUEVE MIL QUINIENTOS TREINTA Y DOS COMA SESENTA Y SIETE
109
CAPÍTULO 6 CONCLUSIONES
6. CONCLUSIONES
En este capítulo se exponen las conclusiones extraídas tras la finalización del trabajo
que se ha realizado. En primer lugar, se discute si se han cumplido los objetivos que nos
propusimos en un primer momento o si por el contrario, se ha producido una desviación
de los mismos. Seguidamente, mencionamos las aplicaciones futuras que pueden surgir
de este trabajo.
6.1. Objetivos cumplidos
Como hemos expuesto reiteradamente en los capítulos iniciales de este trabajo, el

objetivo era construir un entorno virtual interactivo, para poder estudiar las características
de la Inteligencia Ambiental aplicada a la vida asistida.
Una vez que hemos finalizado el proyecto y tomamos perspectiva del trabajo realiza-
do, podemos concluir que dichos objetivos se han llevado a término de forma satisfactoria.
Hemos logrado implementar en un entorno de Realidad Virtual, un sistema capaz de reco-
nocer acciones del usuario y actuar en consecuencia, de la misma forma que se realizaría
si se tratara de un entorno real.
Con ello, hemos podido visualizar como algunos comportamientos que son usuales
que se produzcan en el entorno de las personas ancianas o personas con algún tipo de
enfermedad o discapacidad, serían detectados por la inteligencia implantada en el entorno
y así evitar accidentes o mejorar el ahorro en la vivienda.
6.2. Líneas futuras de trabajo
Para concluir finalmente la realización de este trabajo, exponemos a continuación po-

sibles líneas futuras en las que continuar la vía de investigación expuesta a lo largo de la
realización del proyecto.
Puesto que se ha logrado construir con éxito el sistema de Realidad Virtual, podemos
seguir explotando esta vía añadiendo mejoras sobre lo ya implementado:
Incluir interacción con más elementos del entorno o habilitar acciones nuevas para
el usuario que son comunes realizarlas en el contexto de la vida en el hogar.
Adecuar la solución para que presente una mayor inmersión para el usuario utili-
zando elementos hardware como gafas de realidad virtual.
Mejorar el sistema inteligente incluyendo técnicas de inteligencia artificial como el

deep learning. Por ejemplo, podemos hacer que el sistema recoja datos del compor-
110
CAPÍTULO 6 CONCLUSIONES
tamiento del usuario, los almacene y estudie, para detectar de forma más precisa
cuando éste se está comportando de forma extraña, dado que el sistema conoce cual
es su comportamiento usual.
Dotar al sistema de mayor número de sensores que simulen la recogida de informa-

ción biométrica del usuario para detectar con antelación la existencia de posibles
enfermedades.
Por otro lado, una vez abierta la puerta de construir este tipo de entornos en Realidad
Virtual, aplicarlo a otros campos de la Inteligencia Ambiental para estudiar su comporta-
miento, como puede ser la movilidad y el transporte, o el ámbito de salud.
Finalmente, como propuesta a largo plazo, si el sistema en Realidad Virtual resulta
viable y factible, se podría llegar a implementar un prototipo en la vida real, para estudiar
el comportamiento con usuarios humanos.
111
CAPÍTULO 6 BIBLIOGRAFÍA
BIBLIOGRAFÍA
[1] N. Cortés, ¿Por qué España tiene una esperanza de vida tan alta?, oct. de 2019.
[En línea]. Disponible en: https://www.consalud.es/pacientes/por-que-
espana-tiene-una-esperanza-de-vida-tan-alta_69172_102.html.
[2] INE. (). Esperanza de vida, [En línea]. Disponible en: https : / / www . ine .
es / ss / Satellite ? L = es _ ES & c = INESeccion _ C & cid = 1259926380048 &
p=1254735110672&pagename=ProductosYServicios/PYSLayout (Acceso:
22-08-2020).
[3] M. D. M. L. Ruiz, “Modelo de privacidad digital en inteligencia ambiental basado
en sistemas multiagente”, Tesis doct., Universidad Carlos III de Madrid, mayo de
2017.
[4] E. Aarts, R. Harwig y M. Schuurmans, “Ambient Intelligence”, English, en The
Invisible Future : the seamless integration of technology into everyday life, P. Den-
ning, ed. McGraw-Hill, 2001, pp. 235-250.
[5] I. V. y Diego López de Ipiña, “Inteligencia Ambiental: la presencia invisible”, Solo
Programadores, n.o 127, pp. 36-42, jul. de 2005.
[6] V. Ramos et al., Investigación en Tecnologías de Inteligencia Ambiental para la
Salud del Futuro. ene. de 2009.
[7] A. Gorave, “Ambient Intelligence for Rehabilitation: A Survey”, International Jour-
nal of Computer Applications, vol. 178, pp. 1-3, ago. de 2019. doi: 10 . 5120 /
ijca2019919250.
[8] A. Perez, “Ambient intelligence for improving healthcare”, dic. de 2017.
[9] A. Abraham, “GerAmi: Improving Healthcare Delivery in Geriatric Residences”,
Intelligent Systems, IEEE, vol. 23, pp. 19-25, ene. de 2008.
[10] M. F. Costabile et al., “Explore! Possibilities and Challenges of Mobile Learning”,
en Proceedings of the SIGCHI Conference on Human Factors in Computing Sys-
tems, ép. CHI ’08, Florence, Italy: Association for Computing Machinery, 2008,
pp. 145-154. doi: 10.1145/1357054.1357080. [En línea]. Disponible en: https:
//doi.org/10.1145/1357054.1357080.
[11] V. Gutiérrez et al., “Ambient Intelligence in Intermodal Transport Services: A Prac-
tical Implementation in Road Logistics”, en 2010 Fourth International Conference
on Sensor Technologies and Applications, 2010, pp. 203-209.
[12] K. Selvarajah, A. Tully y P. Blythe, “ZigBee for Intelligent Transport System ap-
plications”, jun. de 2008, pp. 1-7. doi: 10.1049/ic.2008.0814.
[13] F.-C. Tofan y D. Ghiurcă, “QR CODES IMPLEMENTATION IN MUSEUM EX-
HIBITIONS”, Studii si Comunicări, vol. 25, pp. 142-146, ene. de 2017.
112
[14] F. Borrego-Jaraba, I. Luque Ruiz y M. Á. Gómez-Nieto, “NFC Solution for the De-
velopment of Smart Scenarios Supporting Tourism Applications and Surfing in Ur-
ban Environments”, en Trends in Applied Intelligent Systems, N. García-Pedrajas,
F. Herrera, C. Fyfe, J. M. Benítez y M. Ali, eds., Berlin, Heidelberg: Springer Ber-
lin Heidelberg, 2010, pp. 229-238.
[15] T. T. Trout et al., “Networked Mixed Reality ( MxR ) Infrastructure for Collabora-
tive Decision-Making”, 2018.
[16] D. A. Guttentag, “Virtual reality: Applications and implications for tourism”, Tou-
rism Management, vol. 31, n.o 5, pp. 637-651, 2010. doi: https :/ /doi .org /
10.1016/j.tourman.2009.07.003. [En línea]. Disponible en: http://www.
sciencedirect.com/science/article/pii/S0261517709001332.
[17] A. G. A. Mario, D. Thalmann y V. Frédéric, Stepping into virtual reality. Springer,
2008.
[18] J. Bonilla Carranza, A. Peña Pérez Negrón y M. Contreras, “Teaching Approach for
the Development of Virtual Reality Videogames”, en. ene. de 2020, pp. 276-288.
doi: 10.1007/978-3-030-33547-2_21.
[19] M. Christofi y D. Michael-Grigoriou, “Designing and evaluating virtual environ-
ments for the treatment of claustrophobia”, jun. de 2016.
[20] E. Salehi, M. Mehrabi, F. Fatehi y A. Salehi, “Virtual Reality Therapy for So-
cial Phobia: A Scoping Review”, Studies in health technology and informatics,
vol. 270, pp. 713-717, jun. de 2020. doi: 10.3233/SHTI200253.
[21] M. Krijn et al., “Treatment of acrophobia in virtual reality: The role of immersion
and presence”, Behaviour Research and Therapy, vol. 42, n.o 2, pp. 229-239, 2004.
doi: https : / / doi . org / 10 . 1016 / S0005 - 7967(03 ) 00139 - 6. [En línea].
Disponible en: http://www.sciencedirect.com/science/article/pii/
S0005796703001396.
[22] R. Dai, Z. Fan y Z. Pan, “A Virtual Reality Training System for Flood Security”,
en. abr. de 2020, pp. 126-134. doi: 10.1007/978-3-662-61510-2_12.
[23] M. Messina, S. Teves, G. Scurati, M. Carulli y F. Ferrise, “DEVELOPMENT OF
VIRTUAL REALITY TRAINING SCENARIO FOR AVALANCHE RESCUE”,
ago. de 2020.
[24] N. Vaughan, N. John y N. Rees, “ParaVR: Paramedic Virtual Reality Training Si-
mulator”, oct. de 2019, pp. 21-24. doi: 10.1109/CW.2019.00012.
[25] J. Elliman, M. Loizou y F. Loizides, “Virtual Reality Simulation Training for Stu-
dent Nurse Education”, sep. de 2016, pp. 1-2. doi: 10.1109/VS- GAMES.2016.
7590377.
113
[26] R. Valdés, L. Sanz, J. Crespo y F. Alonso, “The use of virtual flight simulation
for airspace design in aeronautical engineering education”, 2011 IEEE Global En-
gineering Education Conference, EDUCON 2011, abr. de 2011. doi: 10 . 1109 /
EDUCON.2011.5773191.
[27] A. Pestek y M. Sarvan, “Virtual reality and modern tourism”, Journal of Tourism
Futures, vol. ahead-of-print, abr. de 2020. doi: 10.1108/JTF-01-2020-0004.
[28] K. Damjanov y D. Crouch, “Virtual Reality and Space Tourism”, en. sep. de 2019,
pp. 117-137. doi: 10.1108/S1571-504320190000025007.
[29] E. Press, La Realidad Aumentada y la Virtual tendrán un impacto de hasta 1,36
billones en la economía mundial en 2030, nov. de 2019. [En línea]. Disponible en:
https://www.europapress.es/economia/noticia-realidad-aumentada-
virtual - tendran - impacto - 136 - billones - economia - mundial - 2030 -
20191127120507.html.
[30] Open Simulator Main Page. [En línea]. Disponible en: http://opensimulator.
org/wiki/Main_Page.
[31] O. Tinoco Gómez, P. P. Rosales López y J. Salas Bacalla, “Criterios de selec-
ción de metodologías de desarrollo de software”, Español, Industrial Data, vol. 13,
pp. 70-74, 2010. [En línea]. Disponible en: http://www.redalyc.org/articulo.
oa?id=81619984009.
[32] E. M. Méndez Nava, “Modelo de evaluación de metodologías para el desarrollo
software”, Tesis de mtría., Universidad Católica Andrés Bello, jul. de 2006. [En
línea]. Disponible en: www . academia . edu / download / 38917027 / AAQ7365 .
pdf.
[33] I. Sommerville, Ingeniería del Software. Pearson Education, 2005, pp. 68-70. [En
línea]. Disponible en: https://books.google.es/books?hl=es%5C&lr=
%5C&id=gQWd49zSut4C.
[34] U. C. I. de Madrid. (2020). Ficha Reina Trabajo Fin de Máster. Máster en Ingeniería
Informática, [En línea]. Disponible en: https://aplicaciones.uc3m.es/cpa/
generaFicha?est=228&asig=14354&idioma=1 (Acceso: 29-07-2020).
[35] Salarios para empleos de Analista programador/a en Comunidad de Madrid | In-
deed.com. [En línea]. Disponible en: https : / / es . indeed . com / salaries /
analista-programador-Salaries,-Comunidad-de-Madrid (Acceso: 24-08-2020).
[36] Seguridad Social: Cotización / Recaudación de Trabajadores. [En línea]. Dispo-
nible en: http : / / www . seg - social . es / wps / portal / wss / internet /
Trabajadores/CotizacionRecaudacionTrabajadores/36537 (Acceso: 24-08-2020).
[37] M. Lopez, J. Pedraza, J. Carbo y J. M. Molina, “Ambient Intelligence: Applications
and Privacy Policies”, en Highlights of Practical Applications of Heterogeneous
Multi-Agent Systems. The PAAMS Collection, J. M. Corchado et al., eds., Cham:
Springer International Publishing, 2014, pp. 191-201.
114

Testbed de Realidad Virtual para Inteligencia Ambiental (AAL)

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Testbed de Realidad Virtual para Inteligencia Ambiental (AAL)

Cargado por

Copyright:

Formatos disponibles

Máster Universitario en Ingeniería Informática

Trabajo Fin de Máster

“Testbed de realidad virtual para

Ainara Del Barco Ventura

Esta obra se encuentra sujeta a la licencia Creative Commons Reconocimiento - No

3.3. Definición del ciclo de vida y metodología . . . . . . . . . . . . . . . . . . . . 70

2.1 Inteligencia Ambiental por Lopez de Ipiña y Vázquez [5] . . . . . . . . . 5

3.1 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Diseño de la vivienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.1 Gráfico comparativo días reales vs días estimados . . . . . . . . . . . . . 105

2.1 Comparativa de Open Simulator y Unity . . . . . . . . . . . . . . . . . . 19

3.1 CU-XX: Plantilla de caso de uso . . . . . . . . . . . . . . . . . . . . . . 29

3.27 RF-08 : Interactuar con grifo cerrado . . . . . . . . . . . . . . . . . . . . 43

3.58 RF-39 : Menú de administración (mensajes de la ventana de notificaciones) 50

3.82 PS-XX: Plantilla de prueba de sistema . . . . . . . . . . . . . . . . . . . 57

3.111Costes imputables del hardware . . . . . . . . . . . . . . . . . . . . . . 79

4.1 Sensores a implementar por el sistema en entorno físico . . . . . . . . . . 84

5.1 PS-XX: Plantilla de pruebas . . . . . . . . . . . . . . . . . . . . . . . . 95

En la actualidad, existen multitud de referencias al futuro en las que aparatos inteli-

1.2. Motivación del trabajo

La motivación de este proyecto no es otra que la de explorar las posibilidades que

1.3. Organización del documento

Los contenidos del documento se encuentran estructurados en torno a seis capítulos:

1. Introducción. Contiene el contexto en el que se realiza el trabajo recogido en este

2. Estado de la cuestión. En este capítulo se recoge la información de las distintas

4. Ejecución del proyecto. En este capítulo se define cómo se ha llevado a cabo el

5. Descripción de resultados. En este capítulo se validará el sistema implementado

6. Conclusiones. En el último capítulo, evaluaremos si hemos cumplido los objetivos

2.1. Inteligencia Ambiental

El el primer capítulo, hemos introducido muy ligeramente una pequeña aproximación

2.1.1. Definición y características

El sistema podrá modificar el entorno en función de la información que recibe y

El sistema debe ser capaz de adelantarse a aquello que va a ocurrir en el entorno.

Fig. 2.1. Inteligencia Ambiental por Lopez de Ipiña y Vázquez [5]

En el eje horizontal observamos el espectro entre una visión centrada en la tecnología

2.1.2. Campos de aplicación

Un entorno que implementa Inteligencia Ambiental, puede estar aplicado a múltiples

En el caso de la aplicación de la Inteligencia Ambiental al ámbito de la salud, distin-

La prevención, que se centra en la monitorización de la salud del usuario para poder

El tratamiento, que se centra en el autodiagnóstico y la posibilidad de realizar tra-

El cuidado, centrado en la creación de sistemas capaces de responder a las necesi-

2.1.2.2. Cultura y Educación

Cuando aplicamos la Inteligencia Ambiental al entorno educativo y cultural, nos en-

2.1.2.3. Movilidad y transporte

Por otro lado, cuando hablamos de Inteligencia Ambiental aplicada al transporte y

2.1.2.4. Ocio y entretenimiento

En el campo del ocio y el entretenimiento, es usual utilizar esta tecnología enfocada

2.1.2.5. Vida asistida (AAL)

Comunicación y socialización: Incluye aspectos para facilitar la comunicación a

Descanso, relajación y entretenimiento: El hogar constituye el entorno principal

Trabajo y aprendizaje: Incorporan tareas para el cuidado y mantenimiento de la casa

No obstante, la gran mayoría de aplicaciones de esta tecnología en el entorno domés-

2.1.3. Inconvenientes del AmI

2.2. Realidad virtual

Fig. 2.3. Diagrama del espectro de realidad vs virtualidad

2.2.1. Definición y conceptos básicos

2.2.2. Ventajas e inconvenientes

Generar nuevas formas de entretenimiento como sucede en el mundo de los video-

Prevención de riesgos ante situaciones fortuitas que no son peligrosas de generar en

Soporte para entrenamiento o aprendizaje de prácticas que son peligrosas de realizar

Proliferación de nuevas formas de realizar turismo mediante visitas virtuales [27].

En definitiva, existen multitud de aplicaciones a las que se puede aplicar la tecnología