UNIVERSIDAD OBERTA DE CATALUNYA

TRABAJO DE FIN DE MÁSTER

Sistema de Análisis Lingüístico paraEnfermos mediante Voz

Autor:Raúl Campos Rubio

Consultor:Roger Monserrat Ribes

Profesor:Carles Garrigues Olivella

2 de junio de 2017

III

Declaración de autoría

Yo, Raúl Campos Rubio, declaro que esta memoria titulada, «Sistema de AnálisisLingüístico para Enfermos mediante Voz» y el trabajo presentado son de mi autoría.Yo afirmo que:

Este trabajo fue hecho completa o principalmente mientras formaba parte delcolectivo de alumnos de esta universidad.

Ninguna parte de este trabajo ha sido previamente presentado en ningun gra-do o título de esta universidad ni ninguna otra institución.

Cuando se ha consultado el trabajo publicado de otros, éste ha sido claramenteatribuido.

Cuando se ha citado el trabajo de otros, la fuente es siempre referenciada.

Se reconocen todas las fuentes principales en las que se basa el presente trabajo.

Cuando la información está basada en trabajo hecho por el presente autor enconjunción con otros, se deja claro qué partes corresponden a terceros.

Firmado:

Fecha: 2 de junio de 2017

V

«A mi familia por haber hecho esto posible, a tantas amistades por haber salpicado mi vida demomentos increíbles.»

Raúl Campos Rubio

VII

Universidad Oberta de Catalunya

Resumen

Máster en Desarrollo de Aplicaciones Móviles

Sistema de Análisis Lingüístico para Enfermos mediante Voz

por Raúl Campos Rubio

Actualmente, los teléfonos inteligentes se han convertido en dispositivos de mo-nitorización capaces de recolectar información muy valiosa del estado de los usua-rios. En este contexto, es interesante analizar cuáles son las reacciones y sentimientosque experimenta un usuario y cómo son sus interacciones con el resto de interlocu-tores.

El objetivo del presente trabajo es el de crear una aplicación que sea capaz dedeterminar el estado emocional y cognitivo del usuario mediante la grabación dellamadas y su posterior procesamiento mediante técnicas de inteligencia artificial enla nube, siempre desde el punto de vista de la salud.

IX

Universidad Oberta de Catalunya

Abstract

Máster en Desarrollo de Aplicaciones Móviles

Sistema de Análisis Lingüístico para Enfermos mediante Voz

por Raúl Campos Rubio

Nowadays, smartphones have became monitoring devices capable of collectingvaluable information about the status of users. In this context, it is interesting toanalyze what are the reactions and feelings that a user experiments and how are theinteractions with the other interlocutors.

The goal of the present work is to create an application capable of determine theemotional and cognitive status of the user through call recordings and its subsequentprocessing using artificial intelligence techniques in the cloud, always from the pointof view of health.

XI

Reconocimientos

Gracias a mi familia, padres y hermano, por apoyarme y no dudar de mi enningún momento, por su coraje, su trabajo y su ánimo constante y a Jesús por todosaquellos viajes y vivencias.

El trayecto siempre fue difícil, por ello agradecer a tantísimas caras que me hanayudado a abordar los problemas, algunas que nunca volverán y algunas que esperocon ilusión volver a ver.

Feliz por haber descubierto mi vocación, por intentar ser mejor profesional, por-que me hace sentir realizado y por un futuro brillante.

XIII

Índice general

Declaración de autoría III

Resumen VII

Resumen IX

Reconocimientos XI

Listado de acrónimos XIX

1. Introducción 1

1.1. Contexto y justificación del Trabajo . . . . . . . . . . . . . . . . . . . . . 1

1.2. Objetivos del Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Enfoque y método seguido . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Planificación del Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5. Breve sumario de productos obtenidos . . . . . . . . . . . . . . . . . . . 9

2. Diseño 11

2.1. Usuarios y contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Diseño conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3. Prototipado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5. Definición de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 31

2.6. Diseño de la arquitectura de la aplicación . . . . . . . . . . . . . . . . . 31

3. Implementación 39

3.1. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

XIV

3.1.1. Receptores de llamada [6] . . . . . . . . . . . . . . . . . . . . . . 39

3.1.2. Procesador y Watson Services [27] [16] . . . . . . . . . . . . . . . 40

3.1.3. Estructura de Interfaces [14] [1] . . . . . . . . . . . . . . . . . . . 41

3.1.4. Adaptadores [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.5. Vistas web [28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.6. Persistencia [25] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.7. Dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.8. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1.9. Discrepacias con el diseño final . . . . . . . . . . . . . . . . . . . 44

3.2. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4. Viabilidad Económica 57

4.1. Coste Desarrollo y Mantenimiento . . . . . . . . . . . . . . . . . . . . . 57

4.2. Coste IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2.1. Speech to Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2.2. Natural Language Understanding . . . . . . . . . . . . . . . . . 58

4.2.3. Tone Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.4. Personality Insights . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3. Incomes y Modelos de negocio . . . . . . . . . . . . . . . . . . . . . . . 59

5. Conclusiones 61

5.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2. Logros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3. Planificación y Metodología . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.4. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Bibliografía 65

XV

Índice de figuras

1.1. Desglose de algunos de los servicios básicos de IBM Watson. . . . . . . 2

1.2. Diagrama del proceso unificado de desarrollo, se muestran las itera-ciones en conjunción con las fases del ciclo de vida y el esfuerzo re-querido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3. Diagrama del Gantt, incluye las tareas por código y en rojo los límitesde entrega. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1. Árbol de navegación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2. Splash screen o pantalla inial. . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3. Menú cajón (drawer) al que se accede tras pulsar el icono superior de-recho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4. Sección perfil, donde se observa el porcentaje de ‘sinceridad’ y las va-riables que lo determinan. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5. Sección perfil, donde se observa el porcentaje de ‘simpatía’ y las va-riables que lo determinan. . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6. Sección perfil, dentro de la pestaña valores donde se observan los re-sultados para ese grupo de variables. . . . . . . . . . . . . . . . . . . . . 23

2.7. Sección perfil, dentro de la pestaña necesidades donde se observan losresultados para ese grupo de variables. . . . . . . . . . . . . . . . . . . 24

2.8. Sección interlocutores donde se observa la lista de contactos junto alnúmero de llamadas procesadas. . . . . . . . . . . . . . . . . . . . . . . 25

2.9. Sección interlocutores, pestaña ‘Emociones’ para un usuario en parti-cular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.10. Sección interlocutores, pestaña ‘Conceptos’ para un usuario en parti-cular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.11. Sección llamadas, lista de llamadas que han sido analizadas ordena-das por fecha. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.12. Sección llamadas, pestaña ‘Emociones’. . . . . . . . . . . . . . . . . . . 29

2.13. Sección llamadas, pestaña ‘Conceptos’. . . . . . . . . . . . . . . . . . . . 30

XVI

2.14. Diagrama de casos de uso UML. . . . . . . . . . . . . . . . . . . . . . . 32

2.15. Diagrama de clases UML. . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.16. Diagrama de relaciones de la base de datos. . . . . . . . . . . . . . . . . 36

2.17. Diagrama de la arquitectura general de la aplicación. . . . . . . . . . . 37

3.1. Gráfico que representa la estructura de los componentes visuales prin-cipales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2. Menú cajón (drawer) al que se accede tras pulsar el icono superior de-recho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3. Sección perfil, pestaña necesidades. . . . . . . . . . . . . . . . . . . . . . 46

3.4. Sección perfil, pestaña valores. . . . . . . . . . . . . . . . . . . . . . . . 47

3.5. Sección perfil, pestaña personalidad. . . . . . . . . . . . . . . . . . . . . 48

3.6. Sección perfil, pestaña necesidades donde se pueden observar las ba-rras de progreso para cada característica. . . . . . . . . . . . . . . . . . 49

3.7. Sección interlocutores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.8. Sección interlocutores, emociones provocadas por un interlocutor enconcreto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.9. Sección interlocutores, conceptos surgidos en un conversación con uninterlocutor en concreto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.10. Sección llamadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.11. Sección llamadas, emociones surgidas a lo largo de la conversación(en color, superpuestas sobre la transcripción). . . . . . . . . . . . . . . 54

3.12. Sección llamadas, listado de conceptos surgidos a lo largo de la con-versación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1. Timeline de desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

XVII

Índice de cuadros

1.1. Recursos necesarios para llevar a cabo el proyecto. . . . . . . . . . . . . 7

1.2. Hitos principales del proyecto. . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. Ficha de persona de Fátima. . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2. Ficha de persona de Pedro. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Ficha de persona de Ana. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4. Mapa de experiencia de Fátima. . . . . . . . . . . . . . . . . . . . . . . . 15

2.5. Mapa de experiencia de Pedro. . . . . . . . . . . . . . . . . . . . . . . . 16

2.6. Mapa de experiencia de Ana. . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7. Tabla de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.8. Tabla de casos de uso (continuación). . . . . . . . . . . . . . . . . . . . . 34

3.1. Algunos de los mensajes existentes en el sistema Android. . . . . . . . 40

4.1. Cálculos de costes totales del desarrollo para el primer año. . . . . . . 58

4.2. Cálculos de costes totales mensuales por usuario. . . . . . . . . . . . . 59

XIX

Listado de acrónimos

TFM Trabajo de Fin de Máster

API Application Program Interface

IBM International Business Machines Corporation

GPS Global Positioning System

VoIP Voice over IP

SDK Software Development Kit

HTML5 Hypertext Markup Language version 5

mHealth Mobile Health

eHealth Electronic Health

CRM Customer Relationship Management

SMS Short Message Service

MP3 MPG-1/MPEG-2 Audio Layer III

pdf Portable Document Format

apk Android Application Package

IDE Integrated Development Environment

CSS Cascade Style Sheets

SQL Structured Query Language

SO Sistema operativo

XML eXtended Markup Language

CRUD Create Read Update Delete

SVG Scalable Vector Graphics

DOM Document Object Model

ROI Return Of Investment

1

Capítulo 1

Introducción

1.1. Contexto y justificación del Trabajo

Actualmente los dispositivos móviles o smartphones se han convertido en apa-ratos capaces de monitorizar a los usuarios gracias a dos aspectos fundamentales,su portabilidad (que les permite viajar con el usuario allá dónde vaya) y el variadoabanico de sensores de los que disponen (GPS, sensor lumínico, acelerómetro, etc.)que los convierten en entornos muy ricos donde proliferan una gran cantidad deaplicaciones muy diversas.

En este contexto, surje la idea del presente trabajo de fin de máster (de aquí enadelante TFM). En esencia consiste en poder analizar las conversaciones del usuariode forma transparente, para poder extraer información que resulte útil para el mismosobre su estado emocional y cognitivo, esto es posible gracias a que el dispositivomóvil sirve como punto centralizado de comunicación con el resto de personas. Esnecesario definir el tipo de procesamiento y análisis que requerimos a la hora deenfocar la idea, aquí es donde entra en juego el API de IBM Watson.

IBM Watson es un sistema de computación en la nube desarrollado por IBM queimplementa técnicas de deep learning [17], de forma que existen 4 tipos de serviciosde análisis, en concreto aquellos para análisis de lenguaje escrito, para voz, imágenesy datos (Véase un desglose en la figura 1.1).

Con el objetivo de obtener información fiable y continuada del estado del usuarioy alimentar a IBM Watson se pueden identificar varias fuentes de datos:

Fuentes de texto

• SMS: Es sencillo acceder a este tipo de mensajes desde el sistema operati-vo Android, no obstante su uso va reduciéndose conforme pasan los añosdebido al auge de los servicios de mensajería gratuitos, con lo cual en lapráctica resultan una fuente bastante pobre de información.

• Servicios de mensajería: Existen muchos como WhatsApp, Telegram, Han-gouts, etc., y su uso es masivo en la actualidad, sin embargo el acceso a lainformación que estas aplicaciones almacenan es muy difícil, por no decirimposible, ya que no disponen de API’s de consulta y cualquier intentodesde el exterior se considera un ataque a la privacidad y la seguridad delusuario.

2 Capítulo 1. Introducción

FIGURA 1.1: Desglose de algunos de los servicios básicos de IBM Wat-son.

1.1. Contexto y justificación del Trabajo 3

Fuentes de audio.

• Llamadas: Se han visto amenazadas en la actualidad por las llamadasmediante VOIP, sin embargo todavía se utilizan gracias a la bajada deprecios y tarifas por parte de los operadores y su mayor fluidez, sin em-bargo analizar lo que el usuario dice añade una capa nueva de dificultady puede no llegar a ser tan preciso.

Se han escogido las llamadas telefónicas como punto de partida, por ser unafuente rica y accesible, y por el soporte que Watson tiene para transcripción de audio.

Watson dispone de múltiples SDK’s para diferentes lenguajes de forma que per-mite integrar aplicaciones con sus servicios, para este trabajo la idea es utilizar losservicios de transformación de audio a texto (que estan disponibles en múltiplesidiomas) y de ahí analizar el contenido del mismo desde diferentes puntos de vistautilizando las API’s de análisis del lenguaje. A grandes rasgos podemos realizar 3funciones fundamentales:

Crear un perfil del interlocutor (si es introvertido, curioso, altruista, etc.).

Analizar emociones (ira, tristeza, alegría, etc.).

Determinar conceptos (contenido de la conversación).

Llegados a este punto resulta interesante analizar en qué nichos de mercado laidea puede ser rentable, podemos mencionar unos cuantos:

MHEALTH: Es un campo dentro de la EHEALTH, esta última es una rama muyamplia que engloba todas aquellas prácticas relacionadas con la salud que tie-nen soporte mediante dispositivos electrónicos, específicamente la MHEALTH

(abreviatura de mobile health) es aquella que tiene lugar utilizando disposi-tivos móviles [13]. En este sentido la idea se puede enfocar al análisis de pa-cientes con problemas mentales, gente con depresión, estrés crónico, etc. paradeterminar sus perfiles, realizar recomendaciones, y en general proporcionar alos profesionales de la salud una base sólida de información cognitiva y emo-cional.

Productividad empresarial: Podemos analizar las relaciones internas y exter-nas de la empresa. Un ejemplo sería analizar el grado de afinidad de los tra-bajadores entre sí e individualmente de forma dinámica, para poder realizargrupos de trabajo más afines, aumentando la productividad y reduciendo losconflictos que potencialmente pueden generarse entre los trabajadores. De caraal exterior podríamos analizar tendencias y mejorar nuestros sistemas CRM,un ejemplo sería monitorizar todas aquellas llamadas que se realizan a los telé-fonos de atención al cliente, para determinar el grado de satisfacción o enfadode nuestros usuarios, poder realizar un analisis exhaustivo de sus causas y a lalarga mejorar la percepción de nuestros clientes.

La presente aplicación tiene lugar en el ámbito de la salud, para servir de apoyoa pacientes, aunque puede extenderse al ámbito más general para cualquier usuarioque desee monitorizar sus conversaciones y obtener un feedback.

4 Capítulo 1. Introducción

En definitiva, podemos describir el desarrollo a realizar como una aplicación demonitorización de llamadas telefónicas destinada a pacientes con problemas psico-lógicos, utilizando deep learning y servicios en línea, que permita realizar un estudiodetallado de cuáles son las causas a nivel comunicativo de tales trastornos, fuentesde depresión y estrés, como pueden ser determinados interlocutores o temas.

No existen aplicaciones actualmente en el Play Store de Google que realicen es-tas funciones de forma conjunta, ni menos con este enfoque, aunque si se puedeninstalar apps que tocan tangencialmente algunas de la funciones antes comentadas.Por ejemplo, existen aplicaciones que permiten controlar tus llamadas, gestionarlas,bloquear las entrantes [3], incluso permiten grabarlas y generar un audio en for-mato MP3 [4]. Por el lado del reconocimiento de emociones no existen demasiadosdesarrollos, hay algunos que permiten analizar las caras en imágenes en busca desentimientos básicos [10] (hay que tener en cuenta que IBM Watson es un servicioreciente y pionero). En cuanto al análisis de texto y voz, existen multitud de bots(como los que incluye Telegram [26]) que permiten tener agentes conversacionalesen torno a multitud de temas, que van desde la simple selección de opciones porvoz, hasta aquellos que son capaces de aplicar aprendizaje automático y respondera preguntas arbitrarias utilizando técnicas de big data.

1.2. Objetivos del Trabajo

A continuación se listan el conjunto de objetivos funcionales y no funcionalesque se desean alcanzar con el desarrollo de la aplicación:

Funcionales:

• Realizar un análisis taxonómico y conceptual de las conversaciones. Res-ponder a preguntas como, ¿qué temas son los más recurrentes con unadeterminada persona?, a la hora de graficarlo se pueden utilizar nubes deconceptos por ejemplo.

• Generar un análisis emocional, dando respuesta a preguntas como ¿esbuena o mala la relación con una determinada persona? ¿qué emocionesson más recurrentes (furia, miedo, alegría, etc.)? ¿qué tendencias socialestienen lugar en la comunicación (sinceridad, extroversión, simpatía, etc.)?

• Análisis temporal, evolución de estos parámetros en el tiempo.

• Correlación de variables, determinar por ejemplo si hablar con un com-pañero de trabajo sobre un nuevo proyecto produce entusiasmo entre alusuario o si la percepción es mala o si mejora en el tiempo.

• Generación de un perfil basado en el conjunto total de llamadas que vayasiendo más preciso a medida que el número de conversaciones almace-nadas aumente. Este perfil puede incluir aspectos como la personalidad(introvertido/extrovertido, el grado de consciencia, amabilidad, sinceri-dad, etc.), las necesidades del usuario (que tipo de deseos expresa, liber-tad, estabilidad, búsqueda de la perfección, metas, etc.) y valores (si esuna persona arraigada y tradicional, si está enfocada al placer personal yla autoestimulación, etc.).

1.3. Enfoque y método seguido 5

La idea es poder desglosar todas estas variables con el objetivo de realizar gráficasque sean suficientemente intuitivas para el usuario.

No funcionales:

• La aplicación debe ser capaz de encolar las llamadas que se han realizadoen el caso de que no exista conexión a internet, para poder realizar elprocesamiento una vez que la conexión con los servicios de IBM se hayareestablecido.

• Se debe asegurar que el contenido de las llamadas telefónicas no es ac-cesible desde el exterior por parte de otras aplicaciones y por tanto semantiene la confidencialidad de las mismas.

• Se debe garantizar que existen un servicio en segundo plano para grabarlas llamadas y esté escuchando de forma permanente, independientemen-te de que la aplicación gráfica esté ejecutando o no.

• Se debe utilizar HTML5 a la hora de graficar los diferentes datos, habili-tando el uso de diferentes librerías e interfaces JavaScript.

1.3. Enfoque y método seguido

A la hora de seleccionar una metodología de trabajo existen dos vertientes, lastradicionales (donde existe una planificación rígida basada en estándares, diseñadapara proyectos complejos y grandes equipos)[5] y las ágiles (pensadas para proyec-tos flexibles, donde los requisitos cambian con facilidad)[24]. La estrategía más reco-mendable para este proyecto es una metodología tradicional, el equipo se conformadel presente estudiante más el profesor principal y el colaborador. En concreto seutiliza el proceso unificado de desarrollo como metodología y se sigue el ciclo devida en cascada en donde las etapas se suceden de manera lineal, específicamente:

Recogida de requisitos, funcionales y no funcionales. Normalmente los deter-mina el cliente, en este caso es el alumno quién define el alcance de la aplica-ción.

Análisis, también está englobada en el capítulo actual, consiste en definir lasnecesidades a cubrir y conectar los requisitos de usuario con la tecnología.

Diseño, esta etapa se deberá cubrir en capítulos posteriores, consiste en definirla arquitectura del software a desarrollar, determinando los artefactos softwarey sus conexiones.

Implementación, consiste en la codificación del software, esta etapa finalizacon una versión operativa del mismo.

Testing, se encarga de medir la calidad del software y de detectar errores paracorregir.

Existen vertientes que incluyen el mantenimiento como etapa, no obstante, no seha considerado en la planificación de este TFM.

6 Capítulo 1. Introducción

FIGURA 1.2: Diagrama del proceso unificado de desarrollo, se mues-tran las iteraciones en conjunción con las fases del ciclo de vida y el

esfuerzo requerido.

Como características fundamentales del proceso unificado se destacan el desa-rrollo iterativo e incremental (Véase figura 1.2):

Iterativo, se denomina al proceso que incluye iteraciones, en donde se puedensolapar varias fases del ciclo de vida. Por ejemplo, se puede estar en una ite-ración donde la etapa de diseño esté finalizando y la etapa de implementaciónhaya comenzado.

Incremental, implica que se van entregando los artefactos en pequeñas porcio-nes. Esto se ajusta bastante bien al modelo de evaluación por entregables.

Respecto a la estrategia a seguir, es preferible realizar un desarrollo desde ceropor varias razones, para empezar no existe ninguna base o producto anterior reuti-lizable, existen productos de terceros que implementan funciones parciales (como lagrabación de llamadas) [4], pero son soluciones privadas que no tienen un códigolibre. Esto no quiere decir que se desarrolle sin utilizar librerías ni código ya exis-tente, ya que se requieren de las plataformas de desarrollo para Android (AndroidStudio y su SDK), y el SDK para Watson, así como el soporte clásico para Java. Porel contrario, lo que implica es que no se pueden reutilizar soluciones completas yaexistentes, esta decisión facilita el seguimiento de nuestra metodología en tanto queseguimos el flujo de trabajo clásico.

1.4. Planificación del Trabajo

Los recursos que se utilizarán se encuentran reflejados en el cuadro 1.1. El con-junto de hitos se encuentra reflejado en el cuadro 1.2 y el diagrama de Gantt en lafigura 1.3. En cuanto al esfuerzo, se estiman 1 hora diaría para días laborables y 1hora y media para días festivos.

1.4. Planificación del Trabajo 7

Tipo de recurso Recurso específicoHardwareSmartphone Huawei P8 LiteLaptop Acer Aspire 5750GSotwareSistemas operativos Debian 8.0 para PC y Android 7.0 para

smartphone.Editor de código Atom Editor y Sublime Text principal-

mente.IDE Android Studio y opcionalmente Eclip-

se.Sistema de control de versiones GitEditor de imágenes escalares GimpLenguajes e intérpretes Java, JavaScript, HTML5, CSS y SQL.Sistema de composición de textos LATEXServicio de almacenamiento de reposi-torios

Bitbucket

Servicios de planificación Google Calendar y Trello

CUADRO 1.1: Recursos necesarios para llevar a cabo el proyecto.

Tarea Duración(horas)PEC 2 24 horas(P21) Analizar usuarios y contextos deuso.

6 horas

(P22) Crear diseño conceptual. 4 horas(P23) Diseñar prototipos 6 horas(P24) Llevar a cabo una evaluación 4 horas(P25) Actualizar memoria 4 horasPEC 3 48 horas(P31) Desarrollar el código 36 horas(P32) Realizar pruebas 4 horas(P33) Actualizar memoria 8 horasEntrega Final 24 horas(EF1) Crear un manual de usuario 8 horas(EF2) Crear una presentación 8 horas(EF3) Finalizar memoria 8 horas

CUADRO 1.2: Hitos principales del proyecto.

8 Capítulo 1. Introducción

FIGURA 1.3: Diagrama del Gantt, incluye las tareas por código y enrojo los límites de entrega.

1.5. Breve sumario de productos obtenidos 9

1.5. Breve sumario de productos obtenidos

La presente memoria en formato PDF.

Código fuente de la aplicación Android resultante y enlace al repositorio pú-blico.

Aplicación compilada en formato APK.

Diapositivas en formato PDF que resuman los puntos más importantes del pro-yecto.

Presentación en vídeo utilizando las diapositivas antes mencionadas.

11

Capítulo 2

Diseño

2.1. Usuarios y contexto de uso

Para dar cuerpo a esta subsección se utilizará la técnica ‘Personas’, que consisteen definir una serie de personajes o usuarios arquetípicos con el objetivo de servircomo guía al resto de decisiones sobre el producto, como navegación, características,interacciones o diseño visual [23].

Los cuadros 2.1, 2.2 y 2.3 se describen las fichas de los usuarios objetivo másrepresentativos.

2.2. Diseño conceptual

En esta sección se ha optado por utilizar la herramienta conocida como ‘Mapade experiencia’ a la hora de reflejar los escenarios más comunes [9]. De forma ge-neral el escenario se divide en fases muy acotadas, en las cuales se determinan 3componentes, el flujo de interacción, las funcionalidades utilizadas y las emocionesy sentimientos que el usuario experimenta.

En total hay un mapa de experiencia (o escenario) por cada usuario analizado enla subsección anterior, los cuadros 2.4, 2.5 y 2.6 respectivamente.

2.3. Prototipado

Se ha realizado un prototipado horizontal de la aplicación con las pantallas mássignificativas utilizando la herramienta online NinjaMock [21]. El resultado es el queaparece en las figuras de la 2.2 a la 2.13. El árbol de navegación que conecta las dife-rentes interfaces se encuentra reflejado en la figura 2.1 y ha sido diseñado utilizandola herramienta online Gliffy [15].

12 Capítulo 2. Diseño

Ficha de personaInformación generalNombre Fátima Fernández LugoEdad 37 añosUbicación MadridSexo FemeninoEducación Cursó ciclo superior en administración de empresas

cuando era joven (además de la enseñanza básica yobligatoria), suele asistir puntualmente a cursillos so-bre especialidades como pintura, cocina y otros hob-bies.

Situación Sentimental Lleva casada 15 años con su actual marido, tienen unhijo en común.

Situación Laboral Lleva trabajando 10 años en una empresa de audito-rias gestionando la parte administrativa.

Frase Personal La vida es dura, disfruta de los pequeños detalles.MisiónContexto Personal Padece estrés crónico desde hace algunos años debi-

do al trabajo, los hijos y los problemas matrimoniales,acude semanalmente a la consulta de su psicóloga.

Objetivo y Expectativas Tanto ella como la psicóloga necesitan determinar lasfuentes de estrés a las que está sometida, para poderdar un mejor tratamiento.

Contexto de UsoCuándo El número de llamadas que realiza es reducido entre

semana, aunque los sábados y domingos suele reali-zar una media de 4 llamadas diarias. Suele visualizarlos resultados con la especialista y puntualmente al-gunas noches.

Dónde Desde casa mayormente, aunque a veces llama a sumarido desde el trabajo.

Tipo de Dispositivo Smartphone (Samsung Galaxy S5 G900F)Grado de ConocimientosTecnológicos

Medio, aunque dispone de conocimiento avanzadosen ofimática.

MotivaciónDeseo Conocer qué o quiénes le producen sentimientos ne-

gativos.Urgencia No es urgente, el tratamiento es a largo plazo.

CUADRO 2.1: Ficha de persona de Fátima.

2.3. Prototipado 13

Ficha de personaInformación generalNombre Pedro Simón AltaresEdad 76 añosUbicación JaénSexo MasculinoEducación Realizó la educación básica cuando era niño.Situación Sentimental Es viudo, estuvo casado durante 40 años, pero su mu-

jer falleció hace 5, ahora vive solo.Situación Laboral Jubilado desde hace más de 10 años.Frase Personal Los tiempos han cambiado, la tranquilidad me agra-

da.MisiónContexto Personal Padece principio de Alzheimer y sus hijos están preo-

cupados por el avance de su enfermedad, los médicosy psiquiatras están muy pendientes de su condición.

Objetivo y Expectativas Aprovechando que todavía recuerda como realizarllamadas telefónicas y responderlas, sus hijos esperanrecoger aquellos temas y conceptos más recurrentes ydeterminar el nivel de olvido y senilidad que padece,conjuntamente con los especialistas. Un ejemplo seríadeterminar si un mismo tema ya lo ha hablado convarios de sus hijos y no lo recuerda.

Contexto de UsoCuándo Generalmente son sus hijos y familiares quienes lo lla-

man ya que viven en otras ciudades, él no sabe comoobservar los resultados de la app.

Dónde Suele pasar la mayor parte del tiempo en casa des-cansando, puntualmente va al bar a ver a los viejosamigos o al supermercado.

Tipo de Dispositivo Smartphone (Doro 8030, pensado para la terceraedad).

Grado de ConocimientosTecnológicos

La tecnología es algo extraño para él, su estado mentalno ayuda a adquirir nuevos conocimientos sobre lamisma.

MotivaciónDeseo Reconocer diariamente el estado de su enfermedad.Urgencia Media, el avance parece que este siendo muy fuerte

los últimos meses.

CUADRO 2.2: Ficha de persona de Pedro.

14 Capítulo 2. Diseño

Ficha de personaInformación generalNombre Ana Jiménez SantosEdad 15 añosUbicación ValenciaSexo FemeninoEducación Cursó educación básica, actualmente se encuentra en

3o de ESO.Situación Sentimental Soltera, tiene relaciones esporádicas.Situación Laboral Estudiante.Frase Personal No importa lo que la gente piense de ti.MisiónContexto Personal Tiene conflictos en clase debido a sus problemas de

ansiedad y agresividad, ya ha tenido diversas discu-siones con compañeras. Su familia está preocupada.

Objetivo y Expectativas Desea obtener un perfil personal que englobe su acti-tud frente a otras personas con las que entabla conver-sación, su personalidad, necesidades y estado emo-cional, sobre todo de cara al análisis por parte de lafamilia y otros especialistas.

Contexto de UsoCuándo Utiliza las llamadas constantemente, la mayoría de los

días de la semana, con una duración de alrededor deuna hora. Es muy curiosa y tiende a visualizar la appy ver los resultados después de cada conversación.

Dónde Normalmente desde casa, u otros lugares de ocio co-mo los parques o mientras saca al perro de paseo.

Tipo de Dispositivo Smartphone (Xiaomi redmi 4a)Grado de ConocimientosTecnológicos

Medio, es nativa digital, se desenvuelve bien y apren-de rápido.

MotivaciónDeseo Obtener un resumen de cómo la adolescente piensa,

actua y se siente, con el objetivo de minimizar actitu-des negativas producto del momento vital actual.

Urgencia No es urgente.

CUADRO 2.3: Ficha de persona de Ana.

2.3. Prototipado 15

Mapa de ExperienciaPrimera Fase Sección PerfilFlujo Fátima se encuentra con su psicóloga y tras una semana

utilizando la aplicación desean conocer los rasgos perso-nales que han sido detectados en las 25 llamadas proce-sadas. Acceden a la sección ‘Perfil Personal’.

Funciones Flujo normal de navegación.Emociones Está nerviosa porque no ha explorado la aplicación con

anterioridad y desea ver si los resultados son positivos ono.

Segunda Fase Consulta de característicasFlujo Aparece un gráfico circular y varias subsecciones, Fáti-

ma puede leer ‘Necesidades’, ‘Personalidad’ y ‘Valores’ ydiversas barras indicando porcentajes.

Funciones Flujo normal de navegación, generación de un gráfico cir-cular de características y barras porcentuales.

Emociones Está pensativa y dudosa, interacciona con la aplicaciónmuy lentamente.

Tercera Fase Análisis de resultadosFlujo Se centra sobre la subsección ‘Personalidad’, puede ob-

servar que parámetros como la sinceridad, optimismo ycalma son altos, pregunta a la psicóloga que le dé su opi-nión.

Funciones Las mismas que en la segunda fase.Emociones Se siente alegre al ver que los parámetros son buenos y

atiende expectante las explicaciones de la especialista.

CUADRO 2.4: Mapa de experiencia de Fátima.

16 Capítulo 2. Diseño

Mapa de ExperienciaPrimera Fase Llamada entranteFlujo El sistema se pone en funcionamiento, aparece un men-

saje en la parte inferior indicando que se va a grabar lallamada actual, Pedro descuelga.

Funciones Grabación de llamadas en segundo plano y notificación.Emociones Se siente muy emocionado, la llamada es de su hermana,

hace meses que no sabía nada de ella.Segunda Fase Llamada finalizadaFlujo Al colgar, el sistema cierra la grabación y comienza el

procesado, se conecta a la nube (IBM) para utilizar losservicios y obtener conclusiones. En la pantalla apareceun mensaje indicando que el micrófono se desactiva.

Funciones Conversión de audio a texto y procesamiento del lengua-je escrito mediante varios servicios.

Emociones Se siente muy confiado y tranquilo tras haber recibidonoticias de su hermana.

Tercera Fase Resultados de llamadaFlujo Los resultados se van obteniendo por lotes y se van alma-

cenando internamente, cuando todo está listo para mos-trar nueva información la aplicación notifica y generauna vibración.

Funciones Almacenamiento de los resultados y notificación.Emociones Se da cuenta de que el móvil vibra, lo cual lo molesta lige-

ramente, sin embargo no le presta atención porque des-conoce la mayoría de funciones de su dispositivo.

CUADRO 2.5: Mapa de experiencia de Pedro.

2.3. Prototipado 17

Mapa de ExperienciaPrimera Fase Lanzar aplicaciónFlujo Ana se encuentra paseando con su perro y utilizando

Whatsapp, cuando de repente recuerda la llamada quehizo esta mañana, y lanza la aplicación en busca de losresultados del análisis.

Funciones Flujo normal de navegaciónEmociones Siente curiosidad y urgencia, la aplicación le notificó está

mañana pero la ignoró completamente.Segunda Fase Sección conceptosFlujo Ella elige el apartado ‘Por llamada’, ya que sólo necesi-

ta el resultado de una llamada concreta, la selecciona dela lista. Acto seguido recuerda que los temas de conver-sación se almacenaban en la sección ‘Conceptos’. Lee porencima la nube de conceptos, y recuerda que la charla consu amiga no fue demasiado buena.

Funciones Nube de conceptos que refleja .Emociones Tiene una sensación de correspondencia entre la realidad

y lo que la aplicación refleja, se pone a reflexionar.Tercera Fase Sección emocionesFlujo También recuerda que en la pestaña ‘Emociones’ podías

visualizar el contenido de la conversación para la llama-da que habias escogido. Tras seleccionarla se muestra eltexto completo de la conversación utilizando diferentescolores. Ve que los niveles de aversión (morado) e ira (ro-jo) se encuentran por todo el texto, se replantea su situa-ción y decide volver a llamar a su amiga.

Funciones Mapeado de emociones sobre texto.Emociones Continua en su estado reflexivo, cuando visualiza el aná-

lisis emocional se siente arrepentida por su actitud.

CUADRO 2.6: Mapa de experiencia de Ana.

18 Capítulo 2. Diseño

FIGURA 2.1: Árbol de navegación.

2.3. Prototipado 19

FIGURA 2.2: Splash screen o pantalla inial.

20 Capítulo 2. Diseño

FIGURA 2.3: Menú cajón (drawer) al que se accede tras pulsar el iconosuperior derecho.

2.3. Prototipado 21

FIGURA 2.4: Sección perfil, donde se observa el porcentaje de ‘since-ridad’ y las variables que lo determinan.

22 Capítulo 2. Diseño

FIGURA 2.5: Sección perfil, donde se observa el porcentaje de ‘simpa-tía’ y las variables que lo determinan.

2.3. Prototipado 23

FIGURA 2.6: Sección perfil, dentro de la pestaña valores donde se ob-servan los resultados para ese grupo de variables.

24 Capítulo 2. Diseño

FIGURA 2.7: Sección perfil, dentro de la pestaña necesidades dondese observan los resultados para ese grupo de variables.

2.3. Prototipado 25

FIGURA 2.8: Sección interlocutores donde se observa la lista de con-tactos junto al número de llamadas procesadas.

26 Capítulo 2. Diseño

FIGURA 2.9: Sección interlocutores, pestaña ‘Emociones’ para unusuario en particular.

2.3. Prototipado 27

FIGURA 2.10: Sección interlocutores, pestaña ‘Conceptos’ para unusuario en particular.

28 Capítulo 2. Diseño

FIGURA 2.11: Sección llamadas, lista de llamadas que han sido anali-zadas ordenadas por fecha.

2.3. Prototipado 29

FIGURA 2.12: Sección llamadas, pestaña ‘Emociones’.

30 Capítulo 2. Diseño

FIGURA 2.13: Sección llamadas, pestaña ‘Conceptos’.

2.4. Evaluación

Después de iterar en las diferentes etapas de diseño (personas, escenarios y pro-totipos) resta realizar una evaluación del resultado, especificamente de la usabilidadde la aplicación.

Se ha elegido realizar una evaluación heurística, que consiste en el análisis delcumplimiento de una serie de requisitos a nivel de usabilidad, en concreto de aque-llos principios diseñados por Jakob Nielsen [20]. La justificación del cumplimientode todos los principios aporta una buena base para dar por validados nuestros bo-cetos.

1. Visibilidad del estado del sistema. La aplicación alerta (mediante un mensaje

2.5. Definición de los casos de uso 31

flotante) cuando una llamada está realizándose y por tanto el microfóno estáalmacenando la llamada, de la misma forma alerta cuando la llamada finaliza.

2. Relación entre el sistema y el mundo real. A pesar de que el análisis emocio-nal y conceptual tiene su propia terminología, los conceptos y etiquetas queaparecen son cercanos al usuario (simpatía, ira, interlocutor, armonía, etc.)

3. Control y libertad al usuario. En general la aplicación se comporta como unmonitor y no implica estados intermedios que no se puedan deshacer. El flujode navegación es sencillo y aporta bastante control.

4. Consistencia y estándares. Se siguen convenciones internas por ejemplo el co-lor de las emociones (tristeza azul o alegría amarillo) y también la división enemociones y conceptos.

5. Reconocimiento antes que recuerdo. Cada pantalla de la aplicación es inde-pendiente, de forma que el usuario no tiene que recordar pasos anteriores, cadainterfaz es lo suficientemente intuitiva.

6. Flexibilidad y eficiencia de uso. La aplicación no requiere segmentar a losusuarios en expertos e inexpertos, no es común la utilización de aceleradoresen aplicaciones móviles.

7. Estética y diseño minimalista. Es una aplicación Android, y por tanto las guíasde estilo que utiliza son las de Material Design de Google [18] que pretendenser paralelas a las texturas y contornos reales.

8. Ayudar a los usuarios a reconocer. No se generan errores en ningun punto dela interacción.

9. Ayuda y documentación. Se pueden utilizar tooltips para explicar diferentesvariables al usuario por ejemplo a qué nos referimos por ‘cooperación’ o por‘estimulación’.

2.5. Definición de los casos de uso

El diagrama de casos de uso aparece en la figura 2.14 y su desglose en los cuadros2.7 y 2.8. Se han identificado 7 casos de uso en total.

2.6. Diseño de la arquitectura de la aplicación

El diagrama de clases UML aparece en la figura 2.15, el diagrama relacional dela base de datos en la 2.16, y por último el diagrama arquitectural en la 2.17.

32 Capítulo 2. Diseño

FIGURA 2.14: Diagrama de casos de uso UML.

2.6. Diseño de la arquitectura de la aplicación 33

Casos de usoCU#1 Identificar las emociones presentes en la llamada.Actores Enfermo o paciente en tratamiento psicológico / Usuario ge-

nérico.Flujo 1. Se accede a la pestaña llamadas. 2. Se recuperan los datos bá-

sicos de todas las llamadas. 3. El usuario selecciona la llamadaespecífica. 4. Se recuperan los datos completos de esa llama-da. 5. Se genera la tabla de leyendas y se muestra el texto concolores indicativos.

Precondiciones Al menos una llamada procesada.Postcondiciones No se altera el estado del sistema.CU#2 Conocer los rasgos de personalidad.Actores Enfermo o paciente en tratamiento psicológico / Usuario ge-

nérico.Flujo 1. Se carga la sección perfil (por defecto). 2. Se buscan los datos

de personalidad (por defecto). 3. Se genera una gráfica juntocon un spinner de opciones y diversos sliders uno por variable.

Precondiciones Al menos una llamada procesada.Postcondiciones No se altera el estado del sistema.CU#3 Identificar los temas conversación presentes en la llamada.Actores Enfermo o paciente en tratamiento psicológico / Usuario ge-

nérico.Flujo 1. El usuario escoge la sección llamadas. 2. Se cargan los datos

básicos de todas las llamadas. 3. El usuario escoge una llamadade la lista. 4. Se cargan los datos completos para la llamadaseleccioanda. 5. El usuario selecciona la pestaña conceptos. 6.Se renderiza una tabla con los datos.

Precondiciones Al menos una llamada procesada.Postcondiciones No se altera el estado del sistema.CU#4 Identificar las emociones que genera un interlocutor.Actores Enfermo o paciente en tratamiento psicológico / Usuario ge-

nérico.Flujo 1. El usuario escoge la sección interlocutores. 2. Se cargan los

datos básicos de interlocutores. 3. El usuario selecciona un in-terlocutor de la lista. 4. Se cargan los datos completos del inter-locutor. 5. Se generan unos gráficos de barras a color basadosen los datos.

Precondiciones Al menos una llamada procesada.Postcondiciones No se altera el estado del sistema.

CUADRO 2.7: Tabla de casos de uso.

34 Capítulo 2. Diseño

Casos de usoCU#5 Conocer las necesidades comunicativas.Actores Enfermo o paciente en tratamiento psicológico / Usuario ge-

nérico.Flujo 1. Se carga la sección perfil (por defecto). 2. El usuario seleccio-

na la pestaña necesidades. 3. Se cargan los datos de todas lasvariables. 4. Se renderizan diferentes sliders, uno por variable

Precondiciones Al menos una llamada procesada.Postcondiciones No se altera el estado del sistema.CU#6 Conocer los valores personales que son expresados.Actores Enfermo o paciente en tratamiento psicológico / Usuario ge-

nérico.Flujo 1. Se carga la sección perfil (por defecto). 2. El usuario selec-

ciona la pestaña valores. 3. Se cargan los datos de todas lasvariables. 4. Se renderizan diferentes sliders, uno por variable

Precondiciones Al menos una llamada procesada.Postcondiciones No se altera el estado del sistema.CU#7 Reconocer los temas de conversación más comunes con un in-

terlocutor.Actores Enfermo o paciente en tratamiento psicológico / Usuario ge-

nérico.Flujo 1. El usuario escoge la sección interlocutores. 2. Se cargan los

datos básicos de interlocutores. 3. El usuario selecciona un in-terlocutor de la lista. 4. Se cargan los datos específicos de eseinterlocutor. 5. El usuario selecciona la pestaña conceptos. 6. Serenderiza la nube de conceptos en base a los datos.

Precondiciones Al menos una llamada procesada.Postcondiciones No se altera el estado del sistema.

CUADRO 2.8: Tabla de casos de uso (continuación).

2.6. Diseño de la arquitectura de la aplicación 35

FIGURA 2.15: Diagrama de clases UML.

36 Capítulo 2. Diseño

FIGURA 2.16: Diagrama de relaciones de la base de datos.

2.6. Diseño de la arquitectura de la aplicación 37

FIGURA 2.17: Diagrama de la arquitectura general de la aplicación.

39

Capítulo 3

Implementación

3.1. Desarrollo

A lo largo de este capítulo se describirán aquellos aspectos concernientes al desa-rrollo y la componente tecnológica del presente proyecto sin entrar en detalle delcódigo específico. Se hablará de los componentes Android y web utilizados y sufuncionamiento.

3.1.1. Receptores de llamada [6]

Los BroadcastReceiver son una forma de comunicación interproceso dentrodel sistema Android. El SO envía mensajes de forma global, de manera que aque-llas aplicaciones que hayan registrado sus receptores (utilizando la clase anterior)podrán ser notificadas de ello. Esto es interesante desde el punto de vista de la re-cepción de llamadas. Existen multitud de tipos de señales como las que refleja elCuadro 3.1.

El ciclo de vida de estos receptores es sencillo, existe un método onReceive()que se ejecuta cuando se lanza un mensaje del tipo que estamos esperando. Para elcaso de la telefonía, debemos escuchar anuncios del tipo ACTION_PHONE_STATE_CHANGED,en concreto, el campo EXTRA_STATE informará del nuevo estado del teléfono (lla-mada entrante, llamada finalizada, etc.), específicamente:

EXTRA_STATE_OFFHOOK: Indica que una comunicación está teniendo lugar,mediante una llamada entrante que está comunicando. La grabación de vozdebe iniciarse.

EXTRA_STATE_IDLE: Indica que la comunicación previamente existente hafinalizado y el dispositivo está ‘ocioso’ (idle). La grabación debe finalizarse eneste momento.

Mediante ambos campos se puede tener consciencia del estado del teléfono paratomar las acciones oportunas e iniciar el prosamiento posterior.

40 Capítulo 3. Implementación

Anuncio Categoría EmisorBATTERY_LOW Batería Sólo sistemaBOOT_COMPLETED Sistema operativo

cargadoSólo sistema

ACTION_TIME_TICK Se envía cada minuto Sólo sistemaACTION_CAMERA_BUTTON Se activa el botón de

la cámaraTodos

DEVICE_STORAGE_LOW Queda poca memoria Sólo sistemaPACKAGE_REMOVED Se eliminó una apli-

caciónSólo sistema

NETWORK_STATE_CHANGED Cambia la red wi-fi Sólo sistemaACTION_PHONE_STATE Llamada de teléfono TodosACTION_SHUTDOWN El dispositivo va a ser

desconectadoSólo sistema

INPUT_METHOD_CHANGED Cambia el método deentrada

Todos

CUADRO 3.1: Algunos de los mensajes existentes en el sistema An-droid.

3.1.2. Procesador y Watson Services [27] [16]

El presente proyecto incluye dos de los SDK que proporciona IBM Watson (An-droid y Java). Aunque IBM cobra por sus servicios, actualmente existe un plan decarácter académico que permite la utilización de la plataforma (durante 6 meses conopción a renovación), por otra parte también existe una tarificación por utilizaciónde cada uno de los servicios de forma independiente, sin embargo los planes gratui-tos proporcionan una cantidad de llamadas sin necesidad de pago, lo cual es muyconveniente y es la estrategía utilizada en este caso. Las claves que utiliza cada ser-vicio en esta implementación están asociadas a la cuenta del alumno.

Específicamente existen 4 servicios incluidos, dividos en dos categorías y repre-sentados por las siguientes clases:

Servicios de recepción:

• SpeechToText: Específico dentro del SDK de Android, permite la gra-bación por micrófono y las llamadas al API para transcribir una conver-sación de audio a texto escrito, todo de forma transparente. El texto resul-tante servirá de entrada al resto de servicios.

Servicios de procesamiento:

• NaturalLanguageUnderstanding: Entre otras muchas entidades per-mite el análisis de palabras clave, estas palabras clave derivan en objetosde la clase de persistencia Concept.

• PersonalityInsights: Es un servicio bastante caro (en términos compu-tacionales y económicos) que sólo se ejecuta cada 5 llamadas, combinan-do el texto de todas ellas. Como es obvio el análisis será más significa-tivo cuanto más contenido se aporte al servicio. Se traduce en entidades

3.1. Desarrollo 41

PersonalityTrait como hedonismo o curiosidad, que además se re-emplazan cuando un análisis de este tipo tiene lugar (se vacía la tabla debase de datos).

• ToneAnalyzer: Utilizado para la extracción de emociones. Dado el tex-to, éste los descompone en frases más pequeñas y le aporta un porcentajepara cada uno de los 5 sentimientos fundamentales (furia, tristeza, miedo,alegría y decepción), sin embargo persiste la componente más alta que sealmacena en un objeto de tipo EmotionalFragment.

El procesamiento y la recepción son independientes y se llevan a cabo mediantelas clases CallReceiver y CallProcessor, la segunda se ejecuta en un hilo in-dependiente (Thread), y permite de esta forma paralelizar el procesamiento con larecepción de otras llamadas si las hubiera.

3.1.3. Estructura de Interfaces [14] [1]

En el campo de las interfaces gráficas y dentro del sistema Android existen doscontenedores de información primordiales:

Activity: Es una unidad de interacción que tiene siempre una vista asocia-da en formato XML, toda aplicación Android está compuesta por una o másactividades que pueden instanciarse y comunicarse entre sí.

Fragment: Representa una porción de la interfaz de usuario que puede re-utilizarse a lo largo de muchas actividades, su utilización se regula mediantetransacciones.

La Figura 3.1 muestra de forma visual la estructura de contenedores (activida-des y fragmentos) de la cual está compuesta la aplicación. El color azul representaactividades (sólo MainActivity), el amarillo fragmentos y el verde otros compo-nentes (en este caso los RecyclerView que son listas y el Drawer que es el menúde cajón).

3.1.4. Adaptadores [2]

Los adaptores son unos componentes que enlazan estructuras de datos con vis-tas. Aunque esta definición es bastante genérica, en la práctica un adaptador se uti-liza para generar listas (mediante los ya mencionados RecyclerView’s), y tambiénpara personalizar los paneles con páginas y pestañas. En concreto se han implemen-tado tres:

CallAdapter: Se utiliza para renderizar la lista de llamadas, se utiliza un la-yout común para cada item de la lista que se enlaza a través de un ViewHolder.

InterlocutorAdapter: Exactamente igual pero para el caso de los interlo-cutores, con sus campos de texto específicos.

42 Capítulo 3. Implementación

FIGURA 3.1: Gráfico que representa la estructura de los componentesvisuales principales.

3.1. Desarrollo 43

CustomPagerAdapter: Se utiliza de forma genérica para almacenar y ma-nejar los fragmentos cuando existen menús de pestañas (gestionados por unViewPager).

3.1.5. Vistas web [28]

En algunos casos los elementos nativos de Android son insuficientes para la re-creación de ciertos componentes como gráficas, en esta situación puede recurrirsea elementos web (que incluyen lenguaje JavaScript). Se utilizan los componentesWebView que fundamentalmente suponen una instancia ligera del navegador Chro-me, esto penaliza en tiempo de ejecución, no obstante no es problema si se ofrecela respuesta adecuada al usuario, en este caso se utiliza el elemento de AndroidProgressBar en su versión Spinner para dar la sensación de carga al usuario. Estoselementos desaparecen cuando la vista web se carga complementamente, utilizandopuentes JavaScript.

La notación @JavaScriptInterface permite la comunicación entre la com-ponente Java y JavaScript mediante procedimientos remotos, de esta forma se com-parten datos (que deben de visualizarse en las gráficas) y procedimientos (JavaScriptavisa a la componente Java cuando todo está listo).

En concreto existen dos componentes que han sido implementados usando estatécnica: la nube de conceptos donde aparecen las palabras clave más utilizadas conun interlocutor y las graficas radiales que muestran los rasgos de la personalidad delusuario. Las librerías utilizadas para su generación se comentarán más adelante.

3.1.6. Persistencia [25]

En el ámbito de la persistencia de datos, las 5 clases que deben gestionarse sonCall, Interlocutor, Concept, EmotionalFragment y PersonalityTrait.Para su almacenamiento en la base de datos se ha utilizado la librería SugarORM,que permite abstraernos de escribir código SQL y ofrece operaciones CRUD paratodas aquellas clases que deriven de SugarRecord, aquellos campos que no desee-mos almacenar (como constantes), se marcan con la anotación @Ignore.

3.1.7. Dependencias

Para sintetizar, se listan todas las librerías de las que depende el proyecto (tantoen la parte Java como JavaScript):

ChartJS: Librería JavaScript para generación de gráficos de datos utilizandocanvas HTML5. [7]

d3: Data-Driven Documents, es una librería para manipular documentos basa-dos en datos, usando elementos como SVG y CSS, utilizando una aproxima-ción basada en datos para la manipulación del DOM. [8]

44 Capítulo 3. Implementación

d3-cloud: Layout específico para generar tag clouds utilizando d3. [29]

SugarORM: Es un Object-Relational Mapper para simplificar el almacenamientode entidades en bases de datos SQL. [25]

Java Watson SDK: Paquete de funciones específicas de IBM Watson para sim-plificar la interacción con éste. [27]

Android Watson SDK: Es un extra que incluye funciones interesantes como gra-bación de voz. [16]

Recycler View: Permite utilizar las listas RecyclerView en los layouts. Ges-tionan eficientemente la memoria cuando existe una cantidad muy grande dedatos a renderizar. [22]

3.1.8. Resultado

Las capturas del resultado final visual de la aplicación son las que muestran lasfiguras de la 3.2 a la 3.12, en total 11. Los datos que se representan no son reales, sinoque han sido extraídos de un fragmento de un artículo de periódico [11].

3.1.9. Discrepacias con el diseño final

Existen algunas diferencias mínimas entre el diseño planteado el capítulo ante-rior y el resultado final, por varias cuestiones.

La primera es una cuestión estética, aunque se sigue la convención de los 5 co-lores para las 5 emociones principales, muchos otros han tenido que ser redefinidos,como los colores de las barras de progreso.

Por otra parte, el comportamiento real de IBM Watson en algunos casos ha varia-do ligeramente del esperado. En el caso de análisis de conceptos se esperaba que elAPI fuera capaz de inferir el tipo de concepto (i.e. organización, lugar, animal, etc.),sin embargo no era posible y se omitió en la tabla final de conceptos.

Se esperaba utilizar gráficos semicirculares para la sección de perfil, sin embar-go la librería ChartJS no incluía este tipo de gráficas y se optó por una radial, quetambién encaja bastante bien con la estética principal.

También se ha simplificado el nivel de detalle en algunos casos como iconos, olos diferentes grados de emoción para los que estaba diseñado la sección llamadas-emociones.

De forma general, el resultado no varía sustancialmente del diseño original ycumple con los mismos principios del buen diseño de Nielsen mencionados en laevaluación heurística.

3.1. Desarrollo 45

FIGURA 3.2: Menú cajón (drawer) al que se accede tras pulsar el iconosuperior derecho.

46 Capítulo 3. Implementación

FIGURA 3.3: Sección perfil, pestaña necesidades.

3.1. Desarrollo 47

FIGURA 3.4: Sección perfil, pestaña valores.

48 Capítulo 3. Implementación

FIGURA 3.5: Sección perfil, pestaña personalidad.

3.1. Desarrollo 49

FIGURA 3.6: Sección perfil, pestaña necesidades donde se pueden ob-servar las barras de progreso para cada característica.

50 Capítulo 3. Implementación

FIGURA 3.7: Sección interlocutores.

3.1. Desarrollo 51

FIGURA 3.8: Sección interlocutores, emociones provocadas por un in-terlocutor en concreto.

52 Capítulo 3. Implementación

FIGURA 3.9: Sección interlocutores, conceptos surgidos en un conver-sación con un interlocutor en concreto.

3.1. Desarrollo 53

FIGURA 3.10: Sección llamadas.

54 Capítulo 3. Implementación

FIGURA 3.11: Sección llamadas, emociones surgidas a lo largo de laconversación (en color, superpuestas sobre la transcripción).

3.1. Desarrollo 55

FIGURA 3.12: Sección llamadas, listado de conceptos surgidos a lolargo de la conversación.

56 Capítulo 3. Implementación

3.2. Pruebas

Para el caso del testing se han realizado pruebas unitarias utilizando dos frame-work de testing:

Mockito: Se utiliza para generar Mock Objects, es decir, falsos objetos que pre-sentan la misma interfaz que aquellos a los que suplantan. De esta forma, laclase que se somete a prueba se aisla y aquellos elementos con los que inter-actúa se reemplazan por mocks, pudiendo medirse por ejemplo el número dellamadas a un método y corroborándolo con el comportamiento esperado [19].Se ha utilizado para testear toda la parte de ejecución en segundo plano, si-mulando los servicios de Watson (para evitar llamadas al API innecesarias) ysimulando la entrada de llamadas para comprobar el procesamiento y guarda-do de entidades en la base de datos.

Espresso: Se utiliza para realizar testing sobre elementos específicos de la inter-faz de usuario Android y simular eventos (como touches) [12]. En este caso nossirve para testear el ciclo de vida de las actividades y fragmentos de las que secompone la aplicación.

57

Capítulo 4

Viabilidad Económica

4.1. Coste Desarrollo y Mantenimiento

El objetivo de esta sección es dar a conocer cuál sería el costo de desarrollo real dela aplicación y sus costes de mantenimiento en caso de que no hubiese sido imple-mentada todavía y se quisiera dar un uso comercial. También se habla en seccionesposteriores de cuáles podrían ser los posibles modelos de monetización y revenuespara empezar a ser rentable.

En la Figura 4.1 se representa el tiempo estimado de desarrollo y cómo se distri-buyen las etapas a lo largo de los 5 meses que se ha estipulado su duración. En elCuadro 4.1 se representa el coste estimado para el personal (1 persona por rol).

Se ha considerado que la vida útil de la aplicación es de 8 años. El rol de res-ponsable de marketing sigue activo tras el desarrollo aunque con una 1 hora diariadurante los próximos 4-5 años (costo mensual de 240e ). No se tienen en cuenta po-sibles costos de actualizaciones ya que eso debe decidirse dinámicamente una vezque haya retorno de la inversión.

FIGURA 4.1: Timeline de desarrollo.

58 Capítulo 4. Viabilidad Económica

Persona Precio/Hora Horas Dia-rias

Horas Tota-les

Coste

Desarrollador 13e/h 6 horas/día 600 horas 7800eAnalista/Diseñador 15e/h 3 horas/día 60 horas 900eTester 13e/h 4 horas/día 160 horas 2080eResp. Marketing* 12e/h 2 horas/día 200 horas 2400eTOTAL 13180e

CUADRO 4.1: Cálculos de costes totales del desarrollo para el primeraño.

4.2. Coste IBM

Entre los costes variables se encuentran aquellos derivados del uso de Watson yde sus diferentes servicios. Para realizar los cálculos oportunos, realizaremos algu-nas hipótesis con el objetivo de acotar los costes por usuario:

Cada usuario realiza de media una llamada diaria (30 al mes).

Cada usuario habla de media 5 minutos por llamada (150 minutos al mes).

La cantidad de caracteres que incluye la transcripción de una conversación de5 minutos no excede en 10.000.

Bajo estas condiciones y utilizando los planes estándar para cada uno de los ser-vicios y la calculadora incluida en IBM Bluemix podemos calcular los costes men-suales por servicio.

4.2.1. Speech to Text

Las primeros mil minutos son gratuitos, no obstante obviaremos esta ventaja ycalcularemos precios a partir del minuto mil uno. Como ya se comentó, son 150 losminutos mensuales por usuario a un precio de 0.0151e por minuto, en total 2,27e almes.

4.2.2. Natural Language Understanding

Utiliza una unidad llamada NLU (Natural Language Understanding unit), quedepende del número de caracteres y el número de características a extraer. Se hancalculado 2 NLU diarias por usuario. Utilizando la tárifa básica (aquella que es máscostosa por llamada, en el peor de los casos), que consiste en 0.002257e por NLU,obtenemos un resultado de 0.14e al mes.

4.3. Incomes y Modelos de negocio 59

Servicio Precio/Unidad Unidades/Mes CosteSpeech to Text 0,0151e

/min150 min 2.27e

Natural Language Understanding 0,002257e /NLU

60 NLU 0.14e

Tone Analyzer 0,00662e/llamada alAPI

30 llamadasal API

0.20e

Personality Insights 0,015e /lla-mada al API

6 llamadas alAPI

0.09e

TOTAL: 2.70e

CUADRO 4.2: Cálculos de costes totales mensuales por usuario.

4.2.3. Tone Analyzer

Al igual que con el primer servicio ignoraremos que las 1000 primeras llamadasal API son gratuitas. Utilizando la tarifa básica (0,00662e / llamada al API), obtene-mos que el usuario con 30 llamadas mensuales supondrá un costo de 0.2e al mes.

4.2.4. Personality Insights

Tal como está implementada la aplicación, ésta ejecuta el servicio de análisis depersonalidad cada 5 llamadas con el objetivo de obtener un cuerpo de texto mayorsobre el que analizar y también para reducir costes, ya que éste es el servicio máscaro de los cuatro a día de hoy.

Quiere decir que se realizan 6 llamadas al API al mes, utilizando la tarifa es-tándar de 0.015e por llamada al API e ignorando las primeras llamadas gratuitas,obtenemos un total de 0.09e al mes.

En el cuadro 4.2.4 se encuentran el cómputo total de costes para la utilización deservicios Watson.

4.3. Incomes y Modelos de negocio

Existen varios modelos de monetización posibles para obtener beneficios:

Publicidad: Muy extendida, aunque rara vez suele utilizarse de forma única,sino en conjunción con otros modelos de monetización, sirviendo de apoyoeconómico.

Venta de la información: Podemos vender estadísticas a empresas prominentessobre el estado de los usuarios, esto es utilizado por empresas como Facebook.

Subscripción: Podemos cobrar por el uso mensual de la aplicación (superandolos costes de uso de IBM estimados por usuario) o tener un plan freemium.

60 Capítulo 4. Viabilidad Económica

Los costes de desarrollo y mantenimiento no son excesivamente altos, ni tam-poco la facturación a cargo de IBM. Sin embargo el éxito y el ROI, dependerá deutilizar uno o más de los modelos de negocio mencionados, de la capacidad de mar-keting (campañas push y pull) y su agresividad, y por supuesto de la capacidad paraatraer y retener usuarios.

61

Capítulo 5

Conclusiones

5.1. Descripción

Una vez finalizado el trabajo podemos dar cuenta de aquellos puntos más signi-ficativos a lo largo de su desarrollo:

Las técnicas de inteligencia artificial (en este caso IBM Watson), no son pre-cisas siempre. Cuando se aplican a un contexto real, complejo los resultadospueden ser inconsistentes, por ejemplo en el caso de reconocimiento del hablala transcripción rara vez coincide completamente con el texto original cuan-do éste se compone de varias oraciones. Lo mismo para el reconocimiento depalabras clave (a veces insuficiente).

Los modelos de vida en cascada (como el seguido en este proyecto) y las me-todologías clásicas a veces no se ajustan bien y son demasiado rígidas. En estecaso el proyecto incluía una parte de I+D importante, y estos paradigmas noaportan una salida cuando una tarea es irrealizable o no se obtienen tan buenosresultados como se esperaba, o si se decide cambiar de estrategia.

Las librerías, como por ejemplo los SDK, las librerías de componententes vi-suales, ORM, etc., facilitan enormemente labores que pueden ser implementa-bles de forma clásica, por ejemplo grabar el audio en vez de utilizar AndroidSDK Watson o utilizar un conector SQL en vez de SugarORM. En definitiva,agilizan y hacen el proceso de desarrollo más rápido.

El desarrollo nativo para Android utilizando Android Studio puede en ocasio-nes consumir mucho tiempo en tareas de setup!, compilación y ejecución. Losprocesos del IDE y del emulador pueden requerir muchos recursos y a veceses recomendable utilizar un dispositivo propio, una de las incidencias encon-tradas resultó ser la incapacidad del dispositivo para mostrar los mensajes deexcepción.

El prototipado en la etapa de diseño sirve como una base consistente a la horade generar las interfaces finales, pero existen complejidades a la hora de tra-ducir un boceto a un árbol de componentes. Puede ser el caso de que no sesoporten ciertos elementos tal y como están diseñados originalmente para unaplataforma nativa concreta.

62 Capítulo 5. Conclusiones

5.2. Logros

A grandes rasgos se puede decir que los logros establecidos en la introducciónde este documento han sido alcanzados, sin embargo existen matices. La precisiónde los procesos de transcripción de audio y procesamiento del texto no ha sido laesperada inicialmente, si consideramos ambientes ruidosos cuando el usuario es-tá realizando una llamada, los resultados empeoran todavía más. Los tipos de voztambién influyen, la claridad con la que se habla, esto es lo más común si lo extrapo-lamos al ámbito de las conversaciones humanas, donde a veces existen confusionesen los términos utilizados, ya sea porque el hablante no ha pronunciado claramenteo bien porque el oyente tiene problemas.

Los errores se van acumulando, es decir una palabra mal transcrita puede cate-gorizarse como palabra clave, generando un resultado erróneo desde nuestro puntode vista, no obstante esto no puede mejorarse desde el ámbito de la implementa-ción de la aplicación, el único responsable en este caso son los servicios de IBM quepresumiblemente irán perfilandose y mejorando a lo largo de los próximos años.

5.3. Planificación y Metodología

El tiempo de las diferentes tareas ha variado entre el planificado y el efectivo parala mayoría de ellas, a grandes rasgos se puede decir que tareas como la P23 (diseñarprototipos) han llevado más tiempo y recursos de los previstos, entre otras cosaspor el aprendizaje que conllevan herramientas para la generación de bocetos, suelección, análisis y nivel de detalle. Otras tareas se han acortado respecto al tiempoprevisto, como la P24 (Llevar a cabo una evaluación), cosa que se solventó aplicandouna evaluación heurística. En términos generales se podría decir que se ha requeridomás tiempo para implementación del planificado (1 mes y medio) y menos paradiseño y la entrega final.

La metodología como ya se comentó, ha resultado algo rígida en términos decambios, debido a la importante carga en I+D del trabajo. De replanificarse se hubie-ran simplificado algunas partes de la aplicación.

Por otro se esperaban ritmos de trabajo regulares a lo largo de todo el tiempo, larealidad es que el esfuerzo se concentra justo antes de cada una de las fechas clave(4 de abril, 17 de mayo y 7 de junio), aunque las fechas de los entregables han sidoestrictas, los tiempos de las tareas dentro de una misma PEC se distribuyen dinámi-camente. Se habían planificado consultas más regulares con el profesor coordinadorque han final no tuvieron lugar.

5.4. Trabajo Futuro

En definitiva, podemos decir que hemos creado un producto innovador, aplica-ble a multitud de situaciones, soportado por el gigante de las tecnologías de IBM, locual aporta fiabilidad y seguridad desde el punto de vista de los resultados.

5.4. Trabajo Futuro 63

No obstante, existen multitud del mejoras dentro de la aplicación desarrolladahasta el momento, e incluso podrían explotarse otras líneas de desarrollo (branches).A continuación se listan algunas de ellas:

Redes de afinidad. Podrían combinarse los resultados parciales de cada uno delos usuarios que utilizan la aplicación, de forma que utilizando alguna plata-forma intermedia en la nube podríamos crear grafos representando la afinidadde unos usuarios con otros, generando un valor añadido sin necesidad de nin-gún otro procesamiento adicional.

Recomendaciones. Podríamos utilizar un sistema experto para generar una se-rie de recomendaciones a aquellos usuarios que cumplan ciertas caracterís-ticas, por ejemplo para un nivel de tristeza generalizado muy alto, podríangenerarse alertas indicando que debe evitarse la interacción con ciertos inter-locutores o que debe promoverse la misma con otros.

Multilenguaje. Actualmente la configuración incluida en la aplicación solo so-porta español en broadband (16 KHz de muestreo), sin embargo podríamos ge-neralizarlo al resto de idiomas soportados (inglés, árabe, francés, etc.).

Más características. Aunque se utilizan muchos servicios, se han dejado de la-do muchas de las características que se extraen, entre otras cosas por no incluir-se dentro del alcance del presente proyecto. Algunas de esas características sonla negatividad/positivismo, tendencias sociales del hablante, etc.

Gráficos. Utilizando los datos ya extraídos pueden generarse otras gráficas,como por ejemplo sentimientos en el tiempo, o evolución del perfil.

Mayor nivel de detalle. En la aplicación desarrollada se ha intentado dar unavisión del estado del usuario sin entrar en detalles debido a limitaciones tem-porales, pero se podría haber dado una visión más profunda, por ejemplo den-tro de la transcripción de la conversación, podría indicarse el porcentaje de ca-da sentimiento para un fragmento específico y no el sentimiento predominantesin más.

65

Bibliografía

[1] Activity. https://developer.android.com/reference/android/app/Activity.html. Accedido el 16-05-2017.

[2] Adapter. https://developer.android.com/reference/android/widget/Adapter.html. Accedido el 16-05-2017.

[3] AppLabs. Call Manager App. https://play.google.com/store/apps/details?id=com.appstar.callrecorder&hl=en. Accedido el 10-03-2017.

[4] Appliqato. Automatic Call Recorder App. https://play.google.com/store/apps/details?id=com.appstar.callrecorder&hl=en. Acce-dido el 10-03-2017.

[5] Grady Booch, Ivar Jacobson y James Rumbaugh. «The unified software deve-lopment process». En: Reading: Addison Wesley (1999).

[6] BroadcastReceiver. https : / / developer . android . com / reference /android/content/BroadcastReceiver.html. Accedido el 16-05-2017.

[7] Chart.js. http://www.chartjs.org/. Accedido el 16-05-2017.

[8] Data-Driven Documents. https://d3js.org/. Accedido el 16-05-2017.

[9] DIY Experience Map. http://www.ux-lady.com/diy-experience-map/. Accedido el 27-03-2017.

[10] Emotions App. https://play.google.com/store/apps/details?id=com.that.dude.ippolite.emotions&hl=en. Accedido el 10-03-2017.

[11] España reclama un presupuesto del euro, un seguro de paro común y eurobonos.http://economia.elpais.com/economia/2017/05/14/actualidad/1494774800_135513.html. Accedido el 15-05-2017.

[12] Espresso. https://developer.android.com/reference/android/support/test/espresso/Espresso.html. Accedido el 16-05-2017.

[13] Jesús Fontecha y col. Ambient Intelligence for Health. Advances in vital signs andgait monitoring systems within mHealth environments. 2016. Cap. 1.

[14] Fragmentos. https://developer.android.com/guide/components/fragments.html. Accedido el 16-05-2017.

[15] Gliffy, make diagramming a team sport. https://www.gliffy.com. Accedidoel 31-03-2017.

[16] IBM Watson Developer Cloud Android SDK. https://github.com/watson-developer-cloud/android-sdk. Accedido el 16-05-2017.

[17] IBM Watson Services. https://www.ibm.com/watson/developercloud/services-catalog.html. Accedido el 08-03-2017.

[18] Material Design Guidelines. https://material.io/guidelines/. Accedi-do el 03-04-2017.

66 BIBLIOGRAFÍA

[19] Mockito, tasty mocking framework for unit tests in Java. https://developer.android.com/reference/android/support/test/espresso/Espresso.html. Accedido el 16-05-2017.

[20] Jakob Nielsen. «10 usability heuristics for user interface design». En: NielsenNorman Group 1.1 (1995).

[21] Ninjamock, slice your work in half. https://ninjamock.com. Accedido el31-03-2017.

[22] RecyclerView. https://developer.android.com/reference/android/support/v7/widget/RecyclerView.html. Accedido el 16-05-2017.

[23] Carol Righi y Janice James. User-centered design stories: real-world UCD case stu-dies. Morgan Kaufmann, 2010.

[24] Chris Sims e Hillary Louise Johnson. Scrum: A breathtakingly brief and agile in-troduction. Dymax, 2012.

[25] Sugar ORM. http://satyan.github.io/sugar/. Accedido el 16-05-2017.

[26] Telegram Bot Platform. https://telegram.org/blog/bot-revolution.Accedido el 10-03-2017.

[27] Watson Developer Cloud Java SDK. https://github.com/watson-developer-cloud/java-sdk. Accedido el 16-05-2017.

[28] WebView. https://developer.android.com/reference/android/webkit/WebView.html. Accedido el 16-05-2017.

[29] Word Cloud Layout. https://github.com/jasondavies/d3- cloud.Accedido el 16-05-2017.