Testbed de Realidad Virtual para Inteligencia Ambiental (AAL)
Testbed de Realidad Virtual para Inteligencia Ambiental (AAL)
2019 - 2020
Tutor/es
Javier Carbo Rubiera
Leganés, 2020
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
viii
CAPÍTULO 0 ÍNDICE DE FIGURAS
ÍNDICE DE FIGURAS
x
CAPÍTULO 0 ÍNDICE DE TABLAS
ÍNDICE DE TABLAS
xii
CAPÍTULO 0 ÍNDICE DE TABLAS
xiii
CAPÍTULO 0 ÍNDICE DE TABLAS
xiv
CAPÍTULO 0 ÍNDICE DE TABLAS
xv
CAPÍTULO 0 ÍNDICE DE TABLAS
xvi
CAPÍTULO 1 INTRODUCCIÓN
1. INTRODUCCIÓN
1.1. Contexto
1
CAPÍTULO 1 INTRODUCCIÓN
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.
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
CAPÍTULO 1 INTRODUCCIÓN
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.
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
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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.
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.
5
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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.1. Salud
6
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
7
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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.
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
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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.
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
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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.
Como sucede con todas las tecnologías, la Realidad Virtual trae consigo muchas ven-
tajas, pero también algún inconveniente.
12
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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:
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.
13
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
14
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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.
15
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
16
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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:
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
CAPÍTULO 2 ESTADO DE LA CUESTIÓN
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
CAPÍTULO 2 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
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
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
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
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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 lavabo de la cocina o el baño para abrir o
cerrar el grifo.
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á 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.
24
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
25
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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).
CPU con arquitectura X64 o X86 y soporte para el juego de instrucciones SSE2.
26
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
16GB de RAM.
8GB de RAM.
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.
27
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
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
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
29
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
30
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-01
Título : Abrir grifo
Descripción : El usuario interactuará con el grifo del baño o la cocina para abrirlo
Flujo principal :
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 :
31
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-03
Título : Encender fogón
Descripción : El usuario interactuará con el fogón para encenderlo
Flujo principal :
CU-04
Título : Apagar fogón
Descripción : El usuario interactuará con el fogón para apagarlo
Flujo principal :
32
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-05
Título : Encender luz
Descripción : El usuario interactuará con la luz de cualquier habitación mientras
esta esté apagada
Flujo principal :
CU-06
Título : Apagar luz
Descripción : El usuario interactuará con la luz de cualquier habitación mientras
esta esté encendida
Flujo principal :
33
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-07
Título : Dormir
Descripción : El usuario interactuará con la cama para dormir
Flujo principal :
CU-08
Título : Sentarse
Descripción : El usuario interactuará con el sofa o cualquier silla para sentarse
Flujo principal :
34
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-09
Título : Levantarse
Descripción : El usuario, estando sentado en un sofá o silla, interactuará con el
elemento para levantarse
Flujo principal :
CU-10
Título : Moverse
Descripción : El usuario virtual se desplaza por el entorno virtual
Flujo principal :
35
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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 :
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 :
3. Se marca el checkbox.
36
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-13
Título : Generar fuga de gas
Descripción : El usuario administrador abre el menú de administración y pulsa el
botón para generar una fuga de gas en la cocina
Flujo principal :
3. Se marca el checkbox.
37
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-14
Título : Generar caída
Descripción : El usuario administrador abre el menú de administración y pulsa el
botón para generar una caída del usuario virtual
Flujo principal :
3. Se marca el checkbox.
38
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-15
Título : Modificar temperatura
Descripción : El usuario administrador abre el menú de administración y modifica
la temperatura del usuario virtual
Flujo principal :
39
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
CU-16
Título : Modificar frecuencia cardiaca
Descripción : El usuario administrador abre el menú de administración y modifica
la frecuencia cardiaca del usuario virtual
Flujo principal :
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 :
40
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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.
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
41
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
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
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
42
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
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
RF-11
Título : Movimiento cuando el usuario se sienta
Descripción : Mientras el usuario permanezca sentado, este no podrá moverse.
Prioridad : Alta
43
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
RF-12
Título : Interactuar con silla (levantarse)
Descripción : Mientras el usuario permanezca sentado, podrá pulsar la tecla E
para levantarse.
Prioridad : Alta
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
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
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
44
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
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
45
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
RF-22
Título : Interfaz de la pulsera inteligente (mostrar avisos)
Descripción : La interfaz de la pulsera mostrará avisos al usuario.
Prioridad : Alta
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
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
46
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
RF-27
Título : Menú de administración (formato de hora)
Descripción : La hora tendrá el formato HH:MM
Prioridad : Baja
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
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
47
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
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
RF-34
Título : Menú de administración (modificar pulsaciones)
Descripción : El menú de administración dispondrá de un cuadro de texto para
introducir las pulsaciones.
Prioridad : Alta
48
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
RF-36
Título : Menú de administración (modificar temperatura)
Descripción : El menú de administración dispondrá de un cuadro de texto para
introducir la temperatura en grados centígrados.
Prioridad : Alta
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
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
49
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
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
50
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
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
51
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
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
52
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
53
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
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
54
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
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
55
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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
56
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
57
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
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
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
58
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
Procedencia : RF-06 RF-07
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
Procedencia : RF-08 RF-09
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.
Procedencia : RF-10 RF-11 RF-12
59
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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.
Procedencia : RF-13 RF-14 RF-15 RF-17 RF-18 RF-21
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
60
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
Procedencia : RF-18 RF-21 RF-24 RF-25 RF-26 RF-27
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
61
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración, al
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”.
Procedencia : RF-18 RF-22 RF-24 RF-25 RF-30 RF-31 RF-38 RF-39 RF-46 RF-
47
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.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración, al
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”.
Procedencia : RF-18 RF-22 RF-24 RF-25 RF-32 RF-33 RF-38 RF-39 RF-48 RF-
49 RF-50 RF-51
62
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
PS-13
Título : Generar situación: caída del usuario (respuesta negativa a necesidad
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 negativamente.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración, al
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 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”.
Procedencia : RF-18 RF-22 RF-24 RF-25 RF-32 RF-33 RF-38 RF-39 RF-48 RF-
49 RF-52 RF-53
PS-14
Título : Generar situación: caída del usuario (sin respuesta a necesidad 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 no responde.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración, al
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 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”.
Procedencia : RF-18 RF-22 RF-24 RF-25 RF-32 RF-33 RF-38 RF-39 RF-48 RF-
49 RF-54
Tabla 3.96. PS-14 : Generar situación: caída del usuario (sin respuesta a
necesidad de ayuda)
63
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
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.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración, que
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”.
Procedencia : RF-18 RF-20 RF-24 RF-25 RF-34 RF-35 RF-38 RF-39 RF-56
64
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
Resultado esperado : Al pulsar la tecla “ESC” aparecerá el menú de administración, que
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”.
Procedencia : RF-18 RF-20 RF-24 RF-25 RF-34 RF-35 RF-38 RF-39 RF-57
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.
Procedencia : RF-01 RF-04 RF-40
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.
Procedencia : RF-01 RF-06 RF-41
65
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
Procedencia : RF-01 RF-08 RF-42
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
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.
Resultado esperado : En la ventana de notificaciones del menú de administración, vere-
mos el mensaje “Atención, el usuario ha visitado el baño 2 o más
veces en los últimos 20 minutos”.
Procedencia : RF-01 RF-02 RF-03 RF-38 RF-39 RF-59
66
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
Resultado esperado : En la ventana de notificaciones del menú de administración, vere-
mos el mensaje “Atención, el usuario presenta movimientos erráti-
cos”.
Procedencia : RF-01 RF-02 RF-03 RF-38 RF-39 RF-60
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.
Resultado esperado : En la ventana de notificaciones del menú de administración, vere-
mos el mensaje “Atención, el usuario presenta interacciones erráti-
cas”.
Procedencia : RF-01 RF-02 RF-04 RF-05 RF-06 RF-07 RF-08 RF-09 RF-38 RF-
39 RF-61
PS-25
Título : Comportamiento anómalo: inquietud
Descripción : El usuario se sienta y se levanta tres veces en menos de un minuto.
Resultado esperado : En la ventana de notificaciones del menú de administración, vere-
mos el mensaje “Atención, el usuario presenta inquietud”.
Procedencia : RF-10 RF-12 RF-38 RF-39 RF-61
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
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
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
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
71
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
72
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
3.4.1. Planificación
Análisis: 35 horas.
Diseño: 30 horas.
Implementación: 90 horas.
Pruebas: 50 horas.
73
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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:
74
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
3.4.2. Presupuesto
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:
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.
77
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
Por tanto, el desglose completo del coste del empleado en un mes es el que se muestra
en la siguiente tabla:
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.
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:
78
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
el coste, dejaría un precio / hora de 20,64 e. En total, para cubrir este exceso de horas
destinaríamos el importe de:
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.
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.
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
79
CAPÍTULO 3 DEFINICIÓN DEL PROYECTO
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.
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:
80
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
En primer lugar, realizaremos el diseño del entorno virtual para posteriormente, esta-
blecer cual será la arquitectura de nuestro sistema.
Llegados a este punto, somos conocedores de que debemos diseñar el entorno de una
vivienda que cuente con las siguientes estancias básicas:
Habitación principal: En esta estancia se podrá interactuar con las luces, así como
realizar la acción de dormir.
81
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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:
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
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
Detector de gas
83
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
84
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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:
85
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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.
86
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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 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
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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.
Por otro lado, en el subsistema de gestión gráfica tenemos los siguientes componentes:
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
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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.
90
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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:
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
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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.
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:
92
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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á.
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.
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
CAPÍTULO 4 EJECUCIÓN DEL PROYECTO
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
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
Módulo negocio : Módulos de la capa de negocio que se ven afectados por esta
prueba.
95
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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.
PS-02
Módulo presentación : Controlador de usuario, entorno virtual
Módulo negocio : Controlador de acciones, Controlador entorno virtual
Resultado obtenido : La luz se enciende si está apagada o se apaga si está encendida.
PS-03
Módulo presentación : Controlador de usuario, entorno virtual
Módulo negocio : Controlador de acciones, Controlador entorno virtual
Resultado obtenido : El fogón se enciende si está apagado o se apaga si está encendido.
PS-04
Módulo presentación : Controlador de usuario, entorno virtual
Módulo negocio : Controlador de acciones, Controlador entorno virtual
Resultado obtenido : El grifo se abre si está cerrado o se cierra si está abierto
PS-05
Módulo presentación : Controlador de usuario, entorno virtual
Módulo negocio : Controlador de acciones, Controlador entorno virtual
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.
96
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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.
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.
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
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
97
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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
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
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.
98
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
PS-13
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 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.
PS-14
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 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.
PS-15
Módulo presentación : Menú administración, pulsera virtual
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.
99
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
PS-16
Módulo presentación : Menú administración, pulsera virtual
Módulo negocio : Controlador inteligente, Gestor menú administración, Gestor pul-
sera virtual
Resultado obtenido : Aparece la frecuencia cardiaca de 50 pulsaciones en la pulsera.
PS-17
Módulo presentación : Menú administración, pulsera virtual
Módulo negocio : Controlador inteligente, Gestor menú administración, Gestor pul-
sera virtual
Resultado obtenido : Aparece la frecuencia cardiaca de 110 pulsaciones en la pulsera.
PS-18
Módulo presentación : Controlador de usuario, entorno virtual
Módulo negocio : Controlador entorno virtual, Controlador de acciones, Controlador
inteligente
Resultado obtenido : La luz de la estancia se apaga sola.
PS-19
Módulo presentación : Controlador de usuario, entorno virtual
Módulo negocio : Controlador entorno virtual, Controlador de acciones, Controlador
inteligente
Resultado obtenido : El fogón encendido se apaga solo.
PS-20
Módulo presentación : Controlador de usuario, entorno virtual
Módulo negocio : Controlador entorno virtual, Controlador de acciones, Controlador
inteligente
Resultado obtenido : El grifo abierto deja de expulsar agua.
100
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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
PS-22
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
PS-23
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
PS-24
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
PS-25
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
101
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
104
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
105
Fig. 5.2. Diagrama de Gantt de la planificación final
106
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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:
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
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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:
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.
Por lo que los costes directos totales sumarán un total, entre gastos humanos y mate-
riales, de:
108
CAPÍTULO 5 DESCRIPCIÓN DE RESULTADOS
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.
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.
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.
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. Ghiurcă, “QR CODES IMPLEMENTATION IN MUSEUM EX-
HIBITIONS”, Studii si Comunicări, vol. 25, pp. 142-146, ene. de 2017.
112
CAPÍTULO 6 BIBLIOGRAFÍA
[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
CAPÍTULO 6 BIBLIOGRAFÍA
[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