Universidad ORT Uruguay
Facultad de Ingenier´ıa
Paciente Presente
Aplicaci´ on de inteligencia artificial sobre autorregistros en el marco de la terapia cognitivo-conductual
Entregado como requisito para la obtenci´on del t´ıtulo de Ingeniero en Sistemas
Mart´ın D’Uva - 217632 Valentina Llavayol - 221842
Mauricio Miguez - 217631 Facundo Pirez - 217428
Tutor: Mart´ın Solari
2022
Declaraciones de autor´ıa
Nosotros, Mart´ın D’Uva, Valentina Llavayol, Mauricio Miguez y Facundo Pirez, declaramos que el trabajo que se presenta en esta obra es de nuestra propia mano.
Podemos asegurar que:
La obra fue producida en su totalidad mientras realiz´abamos el proyecto de grado de la carrera Ingenier´ıa en Sistemas;
Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excep- ci´on de estas citas, la obra es enteramente nuestra;
En la obra, hemos acusado recibo de las ayudas recibidas;
Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado claramente qu´e fue contribuido por otros, y qu´e fue contribuido por nosotros;
Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Mart´ın D’Uva Pezzente 12 de mayo de 2022
Valentina Nicole Llavayol Guerra 12 de mayo de 2022
Mauricio Miguez Llorente 12 de mayo de 2022
Facundo Pirez Mascheroni 12 de mayo de 2022
Agradecimientos
El equipo aprovecha esta secci´on para agradecerle a todas aquellas personas que nos brindaron su apoyo y colaboraci´on a lo largo del proyecto.
En primer lugar, le agradecemos a nuestro tutor Mart´ın Solari por su tiempo y completa disposici´on. Le agradecemos por los conocimientos brindados, los cuales no solo nos sirvieron para llevar adelante el proyecto, sino tambi´en como crecimiento personal tanto a nivel profesional como a nivel humano.
Tambi´en queremos agradecer a Quanam por la posibilidad y la confianza en nosotros para llevar a cabo el proyecto. Agradecemos especialmente a Fernando L´opez y Gonzalo Herrera, nuestro punto de contacto con Quanam, quienes desde un comienzo se comprometieron con el proyecto, siendo siempre part´ıcipes en la toma de decisiones.
A su vez, les damos gracias a las personas que dedicaron su tiempo para ayu- darnos. A pacientes y psic´ologos, quienes completaron encuestas, participaron de entrevistas y brindaron feedback. Toda la informaci´on obtenida de los mismos fue fundamental para lograr cumplir con los objetivos planteados.
Agradecemos tambi´en a los revisores, Rafael Bentancur, Amalia ´Alvarez y ´Alvaro Ortas, por sus comentarios y cr´ıticas constructivas. Gracias a los mismos aprendimos y mejoramos aspectos importantes del proyecto con el fin de mejorar la calidad del mismo.
Luego, quer´ıamos agradecer a todos los miembros del equipo del laboratorio ORT Software Factory por la disponibilidad ofrecida para recibirnos en situaciones de dudas. Especialmente, nos gustar´ıa mencionar a Gast´on Mousqu´es por las instancias en las que estuvo presente para responder preguntas y aportar ideas, d´andonos una perspectiva diferente.
Finalmente, gracias a nuestros familiares y amigos. Su motivaci´on y apoyo cons- tante, no solo durante el proyecto, sino tambi´en a lo largo de la carrera, fue lo que nos dio fuerzas en los momentos m´as duros para seguir adelante.
Abstract
Paciente Presente es un proyecto de validaci´on tecnol´ogica que explora la posibi- lidad de aportar valor en el marco de la terapia cognitivo-conductual. Esto es llevado a cabo aplicando inteligencia artificial para analizar autorregistros. En particular, la rama de procesamiento del lenguaje natural.
La terapia cognitivo-conductual es un tipo de tratamiento psicoterap´eutico que ayuda a las personas a aprender a identificar y cambiar patrones de pensamiento. En el marco de esta terapia, una de las estrategias m´as importantes es el autorregistro.
Al llevar a cabo un autorregistro, el paciente describe una situaci´on que le caus´o angustia en el momento que le ocurri´o. Son utilizados por el paciente para practicar la racionalizaci´on de emociones y por el psic´ologo para evaluar al paciente.
Para definir el problema que aborda este proyecto, el equipo llev´o a cabo una etapa de investigaci´on sobre la terapia cognitivo-conductual. Durante la misma, el equipo aplic´o t´ecnicas de la metodolog´ıa Design Thinking, realiz´o entrevistas con psic´ologos, prototipos y consult´o bibliograf´ıa referente al ´area.
Como resultado, el equipo identific´o que en el marco de la terapia cognitivo- conductual, los pacientes encuentran dificultad a la hora de realizar autorregistros con frecuencia y de manera correcta. Esto limita la informaci´on que se pone a dis- posici´on del psic´ologo para que pueda realizar un an´alisis efectivo de la evoluci´on del paciente.
A partir de esto, el equipo construy´o una aplicaci´on que brinda apoyo al proceso de la terapia cognitivo-conductual. El objetivo es facilitarle al paciente la captura de autorregistros, asistir al psic´ologo con el an´alisis de los mismos y con el seguimiento de la evoluci´on del paciente.
Para analizar autorregistros fue necesario aplicar diversas t´ecnicas de inteligencia artificial tales como: detecci´on de emociones y palabras clave, etiquetado gramatical y pasaje de voz a texto. Para cada una, el equip´o debi´o seleccionar herramientas bas´andose en: los idiomas disponibles, la facilidad de integraci´on al sistema, el precio y los resultados de realizar diferentes pruebas.
Finalmente, el equipo condujo una serie de pruebas de usabilidad haciendo ´enfasis en la captura de autorregistros y se le entreg´o al cliente los prototipos en conjunto con los documentos de investigaci´on. El equipo valid´o que es posible aportar valor a la terapia cognitivo-conductual utilizando herramientas de inteligencia artificial.
Palabras clave
Psicolog´ıa, Terapia cognitivo-conductual, Autorregistros, Inteligencia artificial, Pro- cesamiento del lenguaje natural, An´alisis de emociones, Validaci´on tecnol´ogica
´Indice
1. Introducci´on 13
1.1. El equipo . . . 13
1.2. El cliente . . . 14
1.3. Objetivos . . . 14
1.3.1. Objetivos del proyecto . . . 14
1.3.2. Objetivos del prototipo . . . 15
1.3.3. Objetivos acad´emicos . . . 15
1.3.4. Lineamientos . . . 15
1.4. Estructura del documento . . . 16
2. Problema 18 2.1. Contexto . . . 18
2.2. Acotando el dominio . . . 19
2.2.1. Principios de la terapia cognitivo-conductual . . . 19
2.2.2. Autorregistros . . . 20
2.2.3. Exploraci´on del espacio del problema . . . 21
2.3. Definici´on del problema . . . 22
2.3.1. Actores . . . 23
2.3.2. Enunciado del problema . . . 24
3. Soluci´on 25 3.1. Captura de autorregistros . . . 25
3.2. An´alisis de autorregistros . . . 27
3.3. Seguimiento de la evoluci´on del paciente . . . 28
4. Ingenier´ıa de requerimientos 30 4.1. Identificaci´on de usuarios . . . 30
4.2. Elicitaci´on . . . 31
4.2.1. Entrevistas . . . 31
4.2.2. Ingenier´ıa reversa . . . 32
4.2.3. An´alisis de documentos . . . 33
4.3. An´alisis . . . 34
4.3.1. Interfaces de usuario . . . 34
4.3.2. An´alisis de viabilidad . . . 36
4.3.3. Priorizaci´on de requerimientos . . . 36
4.4. Especificaci´on . . . 38
4.5. Verificaci´on . . . 40
4.6. Validaci´on . . . 40
4.6.1. Reuni´on con el cliente . . . 41
4.6.2. Entrevistas . . . 41
4.6.3. Encuestas . . . 41
4.7. Alcance . . . 43
4.7.1. Requerimientos funcionales . . . 44
4.7.2. Requerimientos no funcionales . . . 48
5. Investigaci´on de inteligencia artificial 50 5.1. An´alisis de estrategias . . . 51
5.1.1. Investigaci´on de herramientas para el an´alisis de emociones y sentimientos . . . 52
5.1.2. Investigaci´on de herramientas para el an´alisis de t´opicos y en-
tidades . . . 55
5.1.3. Investigaci´on de herramientas para speech to text . . . 58
5.1.4. Investigaci´on de herramientas para el an´alisis de im´agenes y video . . . 60
6. Arquitectura 62 6.1. Requerimientos de arquitectura . . . 62
6.2. Atributos de calidad . . . 63
6.2.1. Integrabilidad . . . 63
6.2.2. Modificabilidad . . . 64
6.2.3. Seguridad . . . 64
6.2.4. Portabilidad . . . 64
6.2.5. Usabilidad . . . 65
6.3. Descripci´on de la arquitectura . . . 65
6.3.1. Backend . . . 67
6.3.2. Frontend . . . 76
6.4. Selecci´on de tecnolog´ıas . . . 86
6.4.1. Componentes del Backend . . . 86
6.4.2. Frontend . . . 89
6.4.3. Almacenamiento de datos . . . 91
6.4.4. Entorno de ejecuci´on . . . 91
6.4.5. Despliegue . . . 92
7. Gesti´on de proyecto 94 7.1. Ciclo de vida . . . 94
7.2. Metodolog´ıa . . . 94
7.3. Roles . . . 97
7.4. Gesti´on de la comunicaci´on . . . 98
7.4.1. Comunicaci´on con el cliente . . . 98
7.4.2. Comunicaci´on con el tutor . . . 98
7.4.3. Comunicaci´on interna del equipo . . . 99
7.4.4. Planificaci´on . . . 99
7.5. M´etricas de gesti´on . . . 103
7.5.1. Velocidad planead vs. velocidad real . . . 103
7.5.2. Acumulaci´on de story points planificados vs. reales . . . 104
7.5.3. Burndown chart durante los Sprint . . . 105
7.5.4. Esfuerzo del equipo . . . 105
7.5.5. Estimaci´on de tareas . . . 106
7.6. Gesti´on de riesgos . . . 107
7.6.1. Identificaci´on y an´alisis . . . 108
8. Gesti´on de la calidad 113 8.1. Objetivos de calidad . . . 113
8.1.1. Calidad del proceso . . . 113
8.1.2. Calidad del producto . . . 113
8.2. Plan de SQA . . . 114
8.3. Aseguramiento de la calidad . . . 117
8.3.1. Revisiones . . . 117
8.3.2. Validaciones . . . 118
8.3.3. Verificaciones . . . 120
8.3.4. Est´andares . . . 121
8.4. Pruebas . . . 125
8.4.1. Pruebas unitarias . . . 126
8.4.2. Pruebas de integraci´on a nivel de m´odulos . . . 126
8.4.3. Pruebas de integraci´on a nivel de interfaz de usuario . . . 128
8.4.4. Pruebas de integraci´on a nivel de componentes . . . 128
8.4.5. Pruebas de herramientas de IA . . . 129
8.4.6. Pruebas de aceptaci´on con el cliente . . . 129
8.4.7. Pruebas con usuarios . . . 129
8.4.8. Pruebas exploratorias . . . 130
8.5. M´etricas del prototipo . . . 131
9. Gesti´on de la configuraci´on 133 9.1. Identificaci´on de los elementos de la configuraci´on . . . 133
9.2. Control de versiones . . . 133
9.2.1. Google Drive . . . 134
9.2.2. Git y GitHub . . . 135
9.3. Manejo de dependencias . . . 137
9.3.1. Node.js . . . 137
9.3.2. Python . . . 138
9.3.3. Flutter . . . 138
9.4. Proceso de build . . . 138
9.4.1. Backend . . . 138
9.4.2. Frontend . . . 139
9.5. Integraci´on continua . . . 140
9.5.1. Pipeline . . . 140
9.5.2. Herramientas . . . 141
10.Conclusiones 142
10.1. Cumplimiento de los objetivos . . . 142
10.1.1. Objetivos del proyecto . . . 142
10.1.2. Objetivos del prototipo . . . 144
10.1.3. Objetivos acad´emicos . . . 145
10.1.4. Lineamientos . . . 146
10.2. Lecciones aprendidas . . . 146
10.2.1. Involucrar usuarios . . . 147
10.2.2. Investigaci´on . . . 147
10.2.3. Comunicaci´on con el cliente . . . 148
10.2.4. Proceso de ingenier´ıa de software . . . 148
10.3. Pr´oximos pasos . . . 148
10.3.1. Aspectos legales . . . 149
10.3.2. Usabilidad . . . 149
10.3.3. Funcionalidades adicionales . . . 150
11.Referencias bibliogr´aficas 152 12.Anexos 158 12.1. Ingenier´ıa de requerimientos . . . 158
12.1.1. Preguntas base de entrevistas a psic´ologos . . . 158
12.1.2. Ingenier´ıa reversa . . . 159
12.1.3. Preguntas base de validaci´on con psic´ologos . . . 164
12.1.4. Ejemplos de entrevistas de validaci´on . . . 165
12.1.5. Encuestas a psic´ologos . . . 167
12.1.6. Encuestas a pacientes . . . 169
12.1.7. Historias de usuario . . . 173
12.2. Investigaci´on de inteligencia artificial . . . 182
12.2.1. Resumen de la investigaci´on de tecnolog´ıas de an´alisis de emo- ciones y sentimientos . . . 182
12.3. Arquitectura . . . 184
12.3.1. Investigaci´on aplicaciones nativas vs. no nativas . . . 184
12.3.2. Investigaci´on sobre aplicaciones h´ıbridas vs. aplicaciones cross platform vs. PWA . . . 186
12.4. Gesti´on de proyecto . . . 189
12.4.1. Daki retrospective . . . 189
12.4.2. Tablero Kanban . . . 191
12.4.3. Planning poker . . . 192
12.4.4. Triangulaci´on . . . 194
12.4.5. MoSCoW . . . 195
12.5. Gesti´on de la calidad . . . 197
12.5.1. Encuesta de satisfacci´on al cliente . . . 197
12.5.2. Plantillas para el reporte de defectos . . . 200
12.5.3. Herramienta de registro de esfuerzo . . . 201
12.5.4. Resumen de pruebas con usuarios . . . 202
12.6. Conclusiones . . . 207
12.6.1. Investigaci´on sobre ley de protecci´on de datos . . . 207
12.6.2. Carta de conformidad Quanam . . . 210
1. Introducci´ on
El prop´osito del siguiente cap´ıtulo es realizar una introducci´on al proyecto de fin de carrera Paciente Presente: aplicaci´on de inteligencia artificial sobre autorregis- tros en el marco de la terapia cognitivo-conductual. El proyecto fue realizado como requisito para la obtenci´on del t´ıtulo de Ingeniero en Sistemas de la Universidad ORT Uruguay. Se describe la elecci´on del proyecto, el cliente con el que se trabaj´o durante el proceso, los principales objetivos del equipo y la estructura general del documento.
1.1. El equipo
El equipo est´a compuesto por cuatro integrantes:
Mart´ın D’uva: estudiante de Ingenier´ıa en Sistemas, docente de Estructuras de Datos y Algoritmos I en la Universidad ORT Uruguay.
Valentina Llavayol: estudiante de Ingenier´ıa en Sistemas, docente de Funda- mentos de la Computaci´on y l´ogica para Computaci´on en la Universidad ORT Uruguay.
Mauricio Miguez: estudiante de Ingenier´ıa en Sistemas.
Facundo Pirez: estudiante de Ingenier´ıa en Sistemas, docente de Estructuras de Datos y Algoritmos II en la Universidad ORT Uruguay.
Los integrantes del equipo se encuentran cursando el ´ultimo semestre de la carrera. Se conocen desde el primer semestre de la carrera y han trabajado juntos en diferentes oportunidades, por lo que ya conoc´ıan como trabaja cada uno, sus fortalezas y debilidades.
Al equipo le interes´o este proyecto por varias razones. En primer lugar, porque involucraba trabajar en conjunto con un cliente. Dado que ning´un integrante ten´ıa experiencia laboral, present´o una buena oportunidad para acercarse a la industria.
Adem´as, la propuesta inclu´ıa trabajar con inteligencia artificial que es un ´area de in- ter´es com´un a todos. Finalmente, al equipo le pareci´o atractiva la idea de adentrarse en el ´area de la psicolog´ıa, ya que es posible aportar valor a un grupo de personas con una necesidad.
1.2. El cliente
Paciente Presente es un proyecto propuesto por la empresa Quanam. Quanam es una consultora de servicios profesionales especializada en brindar soluciones de negocio. La meta es el ´exito y la mejora de los procesos de los clientes, por medio de soluciones y herramientas de ´ultima generaci´on.
Se encuentra compuesta por 400 consultores, entre ellos ingenieros, analistas, eco- nomistas, administradores, contadores, estad´ısticos y profesionales de comunicaci´on y gesti´on de cambio. Cuenta con 7 oficinas en Am´erica y 40 a˜nos de experiencia.
Fernando Lopez Bello (Practice Leader de Big Data y Data Science) y Gonzalo Herrera Torena (Consultor en Inteligencia Artificial y Data Science) fueron quienes representaron a la empresa en este proyecto y trabajaron junto a nosotros a lo largo del mismo.
Quanam cuenta con un ´area llamada “Data & Analytics”, que tiene como prop´osi- to “colaborar a desarrollar organizaciones m´as inteligentes, transformando datos en informaci´on confiable para que sean m´as competitivas, implantando soluciones de negocio y aplicando t´ecnicas innovadoras de advanced analytics, Big Data e inteli- gencia artificial.”[1].
De la mano de este prop´osito, la empresa vio una oportunidad de implementar una soluci´on de negocio aplicando inteligencia artificial dentro del ´area de la psi- colog´ıa. No obstante, ni el ´area, ni las t´ecnicas aplicables, hab´ıan sido investigadas en profundidad por la empresa. Se vio interesada en un proyecto de validaci´on tec- nol´ogica, donde se investiguen distintas herramientas y validando su aplicabilidad y utilidad con profesionales expertos en la terapia cognitivo-conductual.
1.3. Objetivos
En esta secci´on se describen los objetivos que plante´o el equipo. Los mismos se pueden clasificar como objetivos del proyecto, objetivos del prototipo y objetivos acad´emicos. Finalmente, se describen los principales lineamientos a los que se apeg´o el equipo durante el proyecto.
1.3.1. Objetivos del proyecto
Investigar t´ecnicas de inteligencia artificial en el estado del arte con el fin de aplicarlas en el marco de la terapia cognitivo-conductual.
Construir un prototipo de un sistema que utilice inteligencia artificial para apoyar la terapia cognitivo-conductual.
1.3.2. Objetivos del prototipo
En base a las oportunidades que el equipo logr´o identificar para aportar valor a la terapia cognitivo-conductual, se plantearon los siguientes objetivos del prototipo:
Brindar un medio que permita al paciente realizar autorregistros en el momen- to adecuado, es decir, inmediatamente despu´es de la situaci´on o evento que caus´o angustia.
Ayudar al psic´ologo a evaluar los autorregistros con el fin de identificar pen- samientos autom´aticos, creencias centrales y temas recurrentes que conducen a la angustia emocional del paciente.
Ayudar al psic´ologo a visualizar la evoluci´on del paciente a lo largo del tiempo.
1.3.3. Objetivos acad´ emicos
Los objetivos que se presentan a continuaci´on son de particular importancia dado que el proyecto se llev´o a cabo en un contexto acad´emico, principalmente con el fin de obtener el t´ıtulo de Ingeniero/a en Sistemas.
Cabe destacar que en todo momento el cliente tuvo en consideraci´on dicha rele- vancia acad´emica del proyecto para los integrantes del equipo.
Obtener el t´ıtulo de Ingeniero/a en Sistemas logrando un nivel de excelencia acad´emica.
Poner en pr´actica los conocimientos adquiridos a lo largo de la carrera.
Trabajar en conjunto con un cliente real para adquirir experiencia que contri- buya al desarrollo profesional de los integrantes del equipo.
1.3.4. Lineamientos
A continuaci´on se detallan diversos lineamientos referentes a la relaci´on entre los interesados y el compromiso con el trabajo, que el equipo tuvo en consideraci´on a lo largo del proyecto:
Mantener una buena relaci´on y comunicaci´on con: el cliente, el tutor y entre los integrantes del equipo.
Por cada integrante del equipo, dedicar un promedio de entre 15 y 20 horas semanales a trabajar en el proyecto.
1.4. Estructura del documento
Problema
Este cap´ıtulo trata sobre como el equipo acot´o y defini´o el problema. Se introduce el contexto y conceptos importantes relacionados con el mismo.
Soluci´on
En este cap´ıtulo se describe la soluci´on propuesta por el equipo para intentar solventar el problema planteado en el cap´ıtulo anterior. Se describe la soluci´on de una forma funcional a alto nivel.
Ingenier´ıa de requerimientos
Este cap´ıtulo introduce a los usuarios interesados junto con sus necesidades y una descripci´on de los mismos. Adem´as, se describe el proceso llevado a cabo por el equipo en la etapa de ingenier´ıa de requerimientos. Finalmente, se da una descripci´on t´ecnica de la soluci´on y se listan los requerimientos funcionales y no funcionales.
Investigaci´on de inteligencia artificial
Este cap´ıtulo trata sobre la investigaci´on de las herramientas de inteligencia artificial llevada a cabo por el equipo. En la misma se explora diferentes herramientas que aplican t´ecnicas de inteligencia artificial y qu´e papel juegan en el contexto del proyecto. Adem´as, se explica el criterio de selecci´on utilizado para elegir la herramienta m´as adecuada.
Arquitectura
En este cap´ıtulo se presenta una especificaci´on completa de la arquitectura del sis- tema Paciente Presente. Mediante la misma, se pretende plasmar de forma abstracta el comportamiento del sistema y las justificaciones de las decisiones arquitect´onicas tomadas. De esta forma se podr´a cumplir con los requerimientos y favorecer los atributos de calidad y restricciones establecidos por el cliente.
Gesti´on de proyecto
En este cap´ıtulo se explica c´omo el equipo gestion´o del proyecto, el marco meto- dol´ogico utilizado y sus adaptaciones, las herramientas utilizadas y sus justificacio- nes. Tambi´en se describe, explica la divisi´on de roles dentro del equipo. las m´etricas utilizadas y la gesti´on de riesgo realizada.
Gesti´on de calidad
El prop´osito del cap´ıtulo es describir c´omo el equipo gestion´o la calidad del producto y del proceso a lo largo del proyecto.
Gesti´on de la configuraci´on
El objetivo de este cap´ıtulo es describir c´omo el equipo manej´o la gesti´on de la configuraci´on a lo largo del proyecto. La gesti´on de la configuraci´on fue esencial para trabajar en equipo. Permiti´o realizar cambios sobre los distintos elementos del proyecto de forma continua y trabajando en paralelo. Adem´as, permiti´o asegurar la integridad de las distintas versiones de los elementos que el equipo fue generando.
Conclusiones
En este cap´ıtulo se describe como, a lo largo del proyecto, el equipo fue cum- pliendo con los objetivos planteados. Adem´as, se encuentra una reflexi´on del equipo sobre cu´ales fueron las lecciones aprendidas. Finalmente, se detallan aspectos y fun- cionalidades a tener en cuenta en el futuro en caso de que se desee construir un producto basado en este proyecto.
2. Problema
Esta secci´on tiene como objetivo introducir al lector al problema que el equipo defini´o e intent´o resolver durante el proyecto. Para esto, se introducir´an conceptos importantes y se explicar´a c´omo fue el proceso seguido para encontrar el problema y definirlo.
2.1. Contexto
Al inicio del proyecto, el cliente Quanam, realiz´o una propuesta de problema la cual se fue refinando a lo largo del tiempo. Dicho problema planteaba que, debido a la situaci´on sanitaria del momento, la psicolog´ıa se estaba viendo gravemente afectada, a la vez que se estaba volviendo cada vez m´as relevante en la vida de las personas.
Los encuentros remotos con los psic´ologos se dispararon durante el 2020, un periodo en el que se ha tambaleado la salud mental de gran parte de la poblaci´on.
El motivo principal es la pandemia de COVID-19, la cual ha afectado a muchos de los pilares sobre los que se asentaba la seguridad emocional. Seg´un un estudio realizado por la plataforma de psic´ologos online iFeel, en Espa˜na, en la era del COVID-19, el n´umero de consultas digitales ha aumentado un 98 %. La realidad es que los confinamientos, las p´erdidas de familiares, los despidos laborales y la limitaci´on para ver a amigos y seres queridos han dejado secuelas incluso en quienes gozaban de una buena salud emocional [2].
La ausencia de informaci´on consistente y confiable sobre el coronavirus parece es- tar aumentando la ansiedad de las personas. Preguntas tales como:“¿Estoy haciendo lo correcto?”; y “¿Qu´e m´as deber´ıa hacer?”; “No s´e qu´e hacer”; son pensamientos recurrentes en la mente de la mayor´ıa de las personas.
El problema radica en que estos pensamientos tienen un impacto directo sobre el bienestar y sentimiento de la persona, lo cual repercute en su comportamiento.
Se torna en un ciclo del cual es complicado salir.
En los ´ultimos a˜nos, la terapia psicol´ogica cada vez tiene mayor aceptaci´on a nivel global [3]. Adicionalmente, debido a la pandemia de COVID-19, toda interacci´on presencial entre personas se ha visto reducida dr´asticamente. A su vez, esto ha causado que la terapia psicol´ogica adquiera especial relevancia. Sin embargo, dicha interacci´on presencial, forma una parte fundamental del contacto paciente-psic´ologo, por lo que, la terapia psicol´ogica tambi´en se vi´o gravemente afectada [2].
Al margen de esta situaci´on de contexto espec´ıfica, no es menos importante vi- sualizar que toda terapia est´a sujeta a una agenda donde paciente y psic´ologo se alinean para acordar sesiones (por ejemplo, una o dos veces por semana). A menudo est´an acompa˜nadas de registros que el paciente fue completando manualmente sobre acontecimientos que le sucedieron o afectaron en el ´ınterin. Ejemplos de estos regis- tros pueden ser; anotaciones sobre emociones, sensaciones, preocupaciones en una suerte de bit´acora personal, que no siempre est´a a mano y sobre la que no ocurre un feedback instant´aneo [4].
2.2. Acotando el dominio
El alcance de este problema era demasiado amplio para el proyecto, ya que, por s´ı misma, la psicolog´ıa es una disciplina que tiene muchas escuelas con enfoques terap´euticos distintos. Por esta raz´on, el equipo decidi´o comenzar un proceso de investigaci´on y entrevistas con profesionales en el ´area para poder acotarlo.
En acuerdo con el cliente, el equipo comenz´o a investigar acerca de las diferentes escuelas dentro de la psicolog´ıa con el objetivo de encontrar una donde existiera la posibilidad de aportar valor. La primera que fue investigada fue la escuela del psicoan´alisis, ya que el cliente coordin´o una entrevista con un referente del ´area, Roberto Balaguer. En la entrevista el equipo encontr´o necesidades las cuales no eran factibles de satisfacer en el proyecto, debido a su complejidad. A este punto, el cliente sugiri´o las ramas de la psicolog´ıa cognitiva y conductista para ser investigadas y encontrar una oportunidad donde aportar valor. Para esto, el equipo consult´o bibliograf´ıa, diferentes fuentes de internet y realiz´o entrevistas a diversos psic´ologos.
A ra´ız de esta investigaci´on, el equipo encontr´o un tipo de terapia dentro de la psicolog´ıa, la cual tiene un desarrollo reciente a la vez que hace uso de diferentes herramientas tecnol´ogicas. Por este motivo, el equipo consider´o que esta terapia era un buen lugar en donde exist´ıa la posibilidad de aportar valor con software y realizar la validaci´on tecnol´ogica. Esta terapia se llama terapia cognitivo-conductual y agrupa aspectos de las ramas cognitiva y conductista.
2.2.1. Principios de la terapia cognitivo-conductual
La terapia cognitivo-conductual es un tipo de terapia psicol´ogica que se basa en la idea de que las conductas de las personas se originan a partir de sus pensamientos, creencias y emociones.
Es una terapia originada a partir de la fusi´on de los enfoques cognitivo y con- ductual, sugiere que cuando las personas generan cambios en su forma de pensar y en su sistema de creencias, experimentan mejoras en su comportamiento y estado
emocional. Dado un evento disparador y un conjunto de significados y creencias que el paciente asocia a dicho evento, experimenta consecuencias a nivel emocional y en el comportamiento.
Figura 1: Ecuaci´on de la terapia cognitivo-conductual [5, p. 12]
Cuando se trata un problema o alteraci´on psicol´ogica, existe un “pensamiento disfuncional” que influencia el estado emocional y comportamiento de la persona. Co- mo se mencion´o anteriormente, el enfoque inicial de la terapia cognitivo-conductual, es ayudar a identificar y cambiar los pensamientos negativos que conducen a la an- gustia emocional en situaciones problem´aticas. Para esto, se utilizan varios ejercicios y herramientas de las cuales, la principal, es el autorregistro [6] .
2.2.2. Autorregistros
Los autorregistros son un tipo de estrategia de self-monitoring que el psic´ologo le pide a sus pacientes que utilicen entre sesiones como tarea. Como su nombre lo dice, son registros escritos por el mismo paciente idealmente inmediatamente despu´es de la situaci´on o evento que caus´o angustia, ya que es en ese momento cuando uno es m´as consciente de los pensamientos relacionados a su experiencia [5, p. 19].
El autorregistro se lleva a cabo en una hoja de trabajo, en donde los pacientes re- dactan todo lo referente a la situaci´on mencionada anteriormente. Deben completar una serie de aspectos que son de ayuda para reflexionar sobre la situaci´on, a la vez que ayudan al psic´ologo a entenderla mejor. Estos aspectos pueden variar, aunque los m´as comunes son [7, p. 195]:
Situaci´on
Momento en el que se encontraba (fecha y hora) Lugar
Pensamientos autom´aticos Sensaciones (f´ısicas y no f´ısicas) Emociones (con su intensidad)
En la tabla 1 se muestra un ejemplo de un autorregistro.
Situaci´on: Pensamientos Autom´aticos: Emociones: Intensidad de las emociones:
Mi hija llam´o para pedirme que le env´ıe una cosa. Cuando intento seguir la conversaci´on,
ella se apura para dejar el tel´efono.
Extra˜no pasar tiempo con mis hijos. Estoy seguro que
hay algo mal conmigo. No le caigo bien a mis hijos.
He fallado como padre.
Triste, deca´ıdo, deprimido
100 %
Tabla 1: Ejemplo de autorregistro
Los autorregistros son de utilidad para identificar temas recurrentes y situaciones espec´ıficas que conducen a la angustia emocional. A su vez, son de utilidad para que el psic´ologo pueda ayudar a sus pacientes a cuestionar y evaluar estas suposiciones y creencias y a generar puntos de vista alternativos menos angustiantes a medida que ocurren estas situaciones.
Por lo general, los psic´ologos sugieren a sus pacientes que realicen autorregistros entre las sesiones. Luego, en la siguiente sesi´on, los autorregistros son compartidos y ambas partes charlan sobre los mismos. De esta manera, es posible llevar a cabo un seguimiento de los problemas a medida que ocurren en el d´ıa a d´ıa. Esto permi- te a las personas ser m´as conscientes de las situaciones que tienden a “activar” su angustia y las reacciones que tienen frente a dichas situaciones. Una vez que los pa- cientes son consientes de estas situaciones y sus pensamientos, es posible evaluarlos, reestructurarlos y trabajar sobre los mismos, cambi´andolos poco a poco.
Finalmente, los autorregistros no solo se usan para rastrear problemas; tambi´en se utilizan para ayudar a las personas a ser m´as conscientes de qu´e tan bien se sienten. Por ejemplo, se pueden utilizar para apreciar el grado de ´exito al alcanzar una meta de cambio de comportamiento, o para rastrear su experiencia durante ciertos eventos. Al ser registros de c´omo las personas se sienten y c´omo piensan frente a determinadas situaciones, se puede observar una evoluci´on al comparar los autorregistros a lo largo del tiempo [8].
2.2.3. Exploraci´ on del espacio del problema
A medida que el equipo llevaba a cabo la investigaci´on, se vio en la necesidad de ordenar y procesar la informaci´on recabada. El equipo decidi´o aplicar t´ecnicas del proceso de Design Thinking [9] para realizar dicha tarea. Primero, el equipo utiliz´o la t´ecnica Share Stories and Capture, por lo que se realiz´o una puesta a punto sobre el punto de vista de cada uno, plasmando las principales ideas y conceptos obtenidos. Luego, el equipo continu´o con Saturate and Group con el fin de agrupar la informaci´on para explorar cu´ales son los temas y los patrones que aparecen. De
esta forma es posible identificar las necesidades e insights que dar´an forma a las soluciones del dise˜no. Esto ´ultimo es, escribir frases y/o titulares que capturen lo que sorprende y explique el porqu´e de lo que dijeron los usuarios. A partir de los mismos, el equipo seleccion´o los que consider´o m´as relevantes y valiosos.
El equipo utiliz´o la herramienta Miro donde aplic´o las distintas t´ecnicas men- cionadas de Desing Thinking. A continuaci´on se ilustra un tablero donde el equipo hizo Share Stories and Capture.
Figura 2: Share Stories and Capture
Al finalizar la etapa de investigaci´on mencionada, tras entender mejor la terapia cognitivo-conductual y comprender mejor las necesidades de los usuarios, el equipo encontr´o oportunidades para aportar valor. Estas fueron convertidas a objetivos que se muestran en la secci´on 1.3.2.
2.3. Definici´ on del problema
En esta secci´on se presenta quienes son los afectados por el problema encontrado.
Adem´as, se presenta cu´al fue el problema definido por el equipo.
2.3.1. Actores
El equipo consider´o esencial identificar y profundizar en la caracterizaci´on de qui´enes eran los afectados por el problema y potenciales usuarios de la soluci´on. Se identificaron dos grupos principales; los usuarios pacientes y los usuarios psic´ologos.
Pacientes
Los pacientes constituyen un grupo de usuarios altamente relevante para el siste- ma. Como fue explicado anteriormente, las tareas constituyen un componente central de la terapia cognitivo-conductual y el paciente las lleva a cabo entre sesiones con su psic´ologo.
“El cumplimiento de las tareas est´a asociado con la mejora a corto y largo plazo de muchos trastornos y conductas no saludables, como la ansiedad, la depresi´on, las conductas patol´ogicas, el tabaquismo y la drogodependencia.” [10].
Un problema que el equipo identific´o es que los pacientes no realizan autorre- gistros o no los realizan en el momento adecuado. A veces porque lo olvidan, o simplemente porque les causa pereza tener que cargar un cuaderno donde escribir- los. En otras ocasiones, olvidan llevarlos a la consulta.
Si los pacientes no hacen sus autorregistros, se torna dif´ıcil para el psic´ologo poder trabajar la racionalizaci´on de emociones, ya que cuenta solamente con los recuerdos del paciente, provocando la necesidad de reconstruir ciertas ideas o sucesos.
Psic´ologos
Sin duda, las sesiones de terapia son fundamentales para identificar los problemas a resolver y permitir al paciente aprender estrategias para superarlos. Pero es la implementaci´on de estas estrategias en la vida diaria del paciente lo que representa potencial ´exito en el tratamiento [11]. Es por esta raz´on que es crucial para el psic´ologo que su paciente realice las tareas que se le env´ıa realizar.
En lugar de discutir los problemas exclusivamente en un entorno aislado, se alienta a los pacientes a abordar el problema en su vida cotidiana con la intenci´on de mantener un efecto terap´eutico [12].
A su vez, parte de su importancia radica en que posteriormente en las sesiones terap´euticas se discuten y cuestionan los contenidos de las tareas. Un efecto de ello es que el paciente comienza a incorporar t´ecnicas utilizadas por el psic´ologo, por ejemplo, espont´aneamente tomando su rol y cuestionando ciertas predicciones
o conclusiones tomadas por s´ı mismos [13, p. 4].
El psic´ologo necesita que el paciente haga los autorregistros con frecuencia, para poder recolectarlos y analizarlos. Necesitan que estos capturen informaci´on relevante como emociones, sentimientos, pensamientos autom´aticos e informaci´on situacional, para poder identificar cu´ales son los eventos desencadenantes o problem´aticos, pa- ra posteriormente poder intervenir estos pensamientos. Incluso, algunos psic´ologos hacen copias de los mismos para poder controlar la evoluci´on de sus pacientes.
2.3.2. Enunciado del problema
Finalmente, el equipo logr´o definir el siguiente problema:
En el marco de la terapia cognitivo-conductual, los pacientes encuentran difi- cultad a la hora de realizar autorregistros con frecuencia y de manera correcta, limitando la informaci´on que se pone a disposici´on del psic´ologo para que pueda realizar un an´alisis efectivo de la evoluci´on del paciente.
3. Soluci´ on
Como soluci´on al problema planteado, el equipo propuso una aplicaci´on que brinda apoyo al proceso de la terapia cognitivo-conductual. El objetivo es facilitarle al paciente la captura de autorregistros, asistir al psic´ologo con el an´alisis de los mismos y con el seguimiento de la evoluci´on del paciente.
3.1. Captura de autorregistros
El paciente cuenta con la posibilidad de realizar autorregistros a trav´es de su dispositivo m´ovil. De esta forma, se le brinda una alternativa a tener que cargar constantemente con la libreta donde los registra. Al llevarlo consigo la mayor parte del tiempo, se minimizan las posibilidades de que los autorregistros se pierdan o se olvide de llevarlos a la consulta.
Adem´as, la aplicaci´on brinda otra forma en la que los pacientes se pueden ex- presar, permiti´endoles registrar la informaci´on por medio de notas de audio.
De forma similar a la manera tradicional de realizar autorregistros, la aplica- ci´on cuenta con una plantilla en donde el paciente puede completar los campos de:
situaci´on, pensamientos autom´aticos, emociones e intensidad de las emociones. De esta manera, los pacientes registran esta informaci´on a la vez que son consientes y racionalizan sus emociones y pensamientos. A su vez, para aquellos usuarios que encuentren mayor facilidad en expresarse a trav´es del habla, se les permite registrar un autorregistro a trav´es de grabaciones de voz.
Figura 3: Autorregistro escrito Figura 4: Autorregistro con audio Como fue explicado anteriormente, realizar autorregistros ayuda al paciente a expresar y racionalizar sus pensamientos referentes a una situaci´on que gener´o an- gustia. Por ello, algunos pueden incluir temas delicados o privados. La aplicaci´on le permite compartir los autorregistros que desee con su psic´ologo en el momento que considere adecuado. Los autorregistros ´unicamente pueden ser accedidos por el propio paciente, a menos que lo haya compartido con su psic´ologo.
Para que un paciente pueda compartir sus autorregistros con su psic´ologo, es necesario que previamente se haya vinculado al mismo. Es decir, la plataforma per- mite a los pacientes vincularse con su psic´ologo de manera de poder compartir sus autorregistros f´acilmente.
3.2. An´ alisis de autorregistros
La aplicaci´on ayuda al psic´ologo a evaluar los autorregistros de sus pacientes, permiti´endoles identificar pensamientos autom´aticos, creencias centrales y temas recurrentes. Esto es posible gracias al an´alisis de los autorregistros utilizando in- teligencia artificial. La aplicaci´on es utilizada por el psic´ologo durante la consulta con su paciente. Al momento de dialogar sobre los autorregistros, el psic´ologo es capaz de ver los que fueron compartidos con ´el, junto con un an´alisis mencionado anteriormente.
Figura 5: Listado de pacientes y autorregistros.
Este an´alisis est´a compuesto por dos partes: un an´alisis de emociones y un an´alisis de t´opicos y entidades.
El primero muestra el porcentaje en el que se encuentran presentes las siguien- tes emociones: Alegr´ıa, Sorpresa, Asco, Tristeza, Miedo, Ira. A su vez, se incluye una categor´ıa “otras” en la que se muestra el porcentaje restante que no pudo ser clasificado en ninguna emoci´on particular.
El segundo an´alisis muestra los t´opicos y entidades m´as relevantes que fueron tratados en el autorregistro. En la siguiente figura se muestra el an´alisis con sus dos partes.
Figura 6: An´alisis de autorregistro
3.3. Seguimiento de la evoluci´ on del paciente
A la hora de ver como un paciente ha evolucionado a lo largo del tiempo, el psic´ologo tiene la posibilidad de ver un reporte que se realiza en base a los an´alisis de emociones de cada autorregistro.
Figura 7: Reporte de evoluci´on en aplicaci´on web
Como se puede ver en la imagen anterior, el reporte consta de una gr´afica. En el eje horizontal se muestra una l´ınea de tiempo, y en el eje vertical la medida en la que se encuentran presentes las emociones de los autorregistros compartidos. Es
decir, para cada emoci´on, la gr´afica muestra c´omo fue variando su intensidad a lo largo del tiempo. Adem´as, la gr´afica permite filtrar los resultados por emoci´on
Por lo tanto, a trav´es de este reporte, el psic´ologo puede de forma sencilla:
Visualizar las emociones predominantes en los autorregistros de un paciente en un punto del tiempo.
Visualizar la variaci´on de las emociones (o un conjunto particular de emocio- nes) a lo largo del tiempo.
Visualizar la frecuencia con la que el paciente realiz´o autorregistros.
4. Ingenier´ıa de requerimientos
En este cap´ıtulo se presenta el proceso de ingenier´ıa de requerimientos de softwa- re. Se explica como fue el proceso para lograr identificar y definir los requerimientos del proyecto para luego, a partir de estos, escribir historias de usuarios que formen parte de un Product Backlog adaptado a las necesidades del cliente.
El proceso de ingenier´ıa de requerimientos es de gran inter´es para el cliente, ya que uno de los objetivos del mismo es aportar valor a los usuarios y en este proceso es de donde se obtienen las principales oportunidades para eso. Adem´as, como resultado de este proceso, se obtienen los requerimientos que se incluir´an dentro del sistema, lo que es de particular inter´es para el cliente, ya que los mismos se deben adaptar tambi´en a sus necesidades.
El equipo decidi´o seguir un proceso de ingenier´ıa de requerimientos realizando actividades de elicitaci´on, an´alisis, especificaci´on, validaci´on y verificaci´on de reque- rimientos. El equipo llev´o a cabo este proceso de manera iterativa, hasta lograr obtener requerimientos bien definidos. El equipo realiz´o un total de 2 iteraciones, pasando, en cada iteraci´on, por cada una de las etapas en el orden mencionado.
4.1. Identificaci´ on de usuarios
Para lograr obtener requerimientos que aporten valor, se consider´o clave identi- ficar y profundizar en la caracterizaci´on de qui´enes eran los potenciales usuarios de la soluci´on, y en que grupos se los pueden clasificar. Como se explic´o en la secci´on 2.3.1, se identificaron dos grupos principales: los usuarios pacientes y los usuarios psic´ologos.
Los psic´ologos, adem´as de ser uno de los actores principales, son expertos en el
´area y por ende, son quienes pueden brindar un mayor nivel de conocimiento. Esto hace que los requerimientos que se desprendan de actividades llevadas a cabo en conjunto con ellos, sean de valor.
Existen distintos tipos de psic´ologos seg´un su especializaci´on. En este caso, es necesario acotar los tipos de psic´ologos a los que se apunta, debido a que cada uno posee intereses diferentes y el problema planteado est´a dirigido a solo un tipo espec´ıfico. Es por eso que se opt´o solamente por psic´ologos que trabajen con sesiones, es decir, encuentros peri´odicos (presenciales o remotos), que practiquen la terapia cognitivo-conductual y hagan uso del autorregistro.
Otro tipo de usuario del proyecto, son los pacientes de la terapia cognitivo- conductual que hacen uso del autorregistro. Estos se ver´an directamente afectados por la soluci´on del proyecto, por lo que tambi´en se les debe prestar especial atenci´on.
Sobre los mismos, el equipo tambi´en realiz´o una distinci´on. En este caso fue prin- cipalmente por rango etario. El equipo decidi´o trabajar con adolescentes y adultos, dejando de un lado a los ni˜nos. Esta distinci´on se da de forma casi obligatoria, ya que los ni˜nos, no utilizan autorregistros.
4.2. Elicitaci´ on
La primera etapa del proceso de ingenier´ıa de requerimientos fue la elicitaci´on[14, p. 48]. Para esto, el equipo llev´o a cabo diferentes actividades como entrevistas y encuestas a usuarios, ingenier´ıa reversa y an´alisis de documentos. Algunas de estas t´ecnicas, fueron nombradas en el cap´ıtulo 2, ya que tambi´en son t´ecnicas utilizadas para la etapa de empatizar[9, p. 1] de Design Thinking. Por esta raz´on, es que el equipo aprovech´o la informaci´on obtenida durante la exploraci´on del problema en la etapa de ingenier´ıa de requerimientos
El objetivo de esta etapa fue recabar informaci´on sobre la terapia, opiniones y necesidades de los usuarios para luego convertirlas en requerimientos. Cabe destacar que de cada una de estas t´ecnicas, surgieron uno o varios documentos, los cuales fueron entregados al cliente.
4.2.1. Entrevistas
Con el objetivo de conocer m´as en detalle las necesidades de los usuarios, y la problem´atica con la que se enfrentan, el equipo resolvi´o hacer entrevistas[14, p. 49]
personales con psic´ologos de la terapia cognitivo-conductual. Estas entrevistas fueron provechosas, puesto que, las personas entrevistadas, no solo eran posibles usuarios, sino que tambi´en expertos en el ´area. La ventaja de las entrevistas personales fue que permitieron adaptar las preguntas, en funci´on de lo que los entrevistados respond´ıan.
Previo a realizar las entrevistas, el quipo debi´o conseguir los contactos necesarios para comunicarse con los psic´ologos. Estos contactos fueron obtenidos principalmen- te de p´aginas web como Profesionales.Uy, RedPsi, SUAMOC o Linkedin. En estas p´aginas web, los psic´ologos disponibilizan medios de contacto, para que sea posible comunicarse con ellos de manera sencilla.
El equipo se puso en contacto con m´as de 25 psic´ologos diferentes, de los cuales 9 accedieron a tener entrevistas. La duraci´on de las mismas vari´o entre los 45 minutos y los 60 minutos, lleg´andose a extender en ciertos casos hasta los 90 minutos. En total, se llevaron a cabo 13 entrevistas, ya que, como se mencion´o anteriormente,
se realizaron 2 iteraciones sobre esta etapa, y algunos psic´ologos accedieron a tener una entrevista en cada iteraci´on.
Las entrevistas fueron llevadas a cabo de manera remota, en su mayor´ıa a trav´es de la plataforma Zoom. A modo de gu´ıa, el equipo escribi´o preguntas que se incluyen en el anexo 12.1.1, sin embargo, la idea era mantener una conversaci´on fluida con el entrevistado, y no limitarse a las mismas, haciendo preguntas adecuadas y acordes a c´omo se fuera desarrollando la entrevista. El equipo intent´o seguir los lineamientos y recomendaciones de diferentes bibliograf´ıas como [9] y [15, p. 104].
A medida que el equipo fue llevando a cabo entrevistas, se fueron agregando nuevas preguntas que se consideraban relevantes. A los entrevistados se les pregunt´o cuestiones generales sobre las consultas como: como se lleva a cabo una consulta, si realizan consultas remotas/online, cu´ales son las herramientas que se utilizan dentro y fuera de la consulta, dificultades que se presentan en o entre sesiones, etc. De esta manera se pudo obtener informaci´on relevante relacionada con el problema.
A cada entrevista, asistieron 2 miembros del equipo y el entrevistado. La idea detr´as de que fueran 2 entrevistadores, es que uno pudiera llevar la entrevista ade- lante haciendo preguntas, mientras que el otro documentaba todas las observaciones que parecieron valiosas. Luego, con el punto de vista de ambos entrevistadores y las notas tomadas, era posible establecer conclusiones sobre las dificultades presentadas.
4.2.2. Ingenier´ıa reversa
Otra t´ecnica de elicitaci´on utilizada, fue investigar y realizar ingenier´ıa reversa[14, p. 772] a soluciones existentes y similares a las que se quer´ıa desarrollar para usar como fuente de inspiraci´on y de esta manera obtener ideas y requerimientos. El ob- jetivo era poder extraer funcionalidades que puedan ser relevantes al sistema, las cuales ya est´en validadas por usuarios reales.
Para realizar esta actividad se buscaron aplicaciones relacionadas a la terapia cognitivo-conductual o a la psicolog´ıa en general. En particular se busc´o en sitios web que recomendaran aplicaciones y tiendas de aplicaciones como Play Store en Android y App Store en iOS.
Se encontraron aplicaciones y sitios web de todo tipo, desde plataformas permiten encontrar a psic´ologos y comunicarse con ellos por medio de la misma, pasando por herramientas que ayudan a practicar la meditaci´on, chatbots, asistentes para personas con depresi´on, hasta herramientas m´as especificas para utilizar en sesiones terap´euticas.
El equipo realiz´o un filtrado teniendo en cuenta opiniones y valoraciones de usuario y qu´e tan bien se adaptaban a nuestro problema. Se seleccionaron 9 herra- mientas para investigar m´as en profundidad, algunas aplicaciones m´oviles y otras
plataformas web. En caso de ser aplicaciones gratis, se descargaban y se utilizaban, intentando llevar a cabo casos de uso exhaustivos, contemplando todas o la mayor´ıa de las funcionalidades ofrecidas. En caso de que fueran herramientas pagas, se lle- vaba a cabo una investigaci´on indirecta, buscando informaci´on en distintas fuentes de internet.
Una de las aplicaciones encontradas que cuenta con una gran cantidad de ca- racter´ısticas parecidas a Paciente Presente fue Whats Up?. Esta es una aplicaci´on gratuita que utiliza m´etodos CBT (terapia cognitivo-conductual) y ACT (terapia de aceptaci´on y compromiso) para ayudar a sus usuarios a sobrellevar la depresi´on, ansiedad, estr´es y m´as. Entre sus funcionalidades m´as similares se encuentran: un diario para mantener los pensamientos y sentimientos juntos, capacidad de calificar los sentimientos en una escala, patrones comunes de pensamiento negativo, m´etodos simples para superarlos, entre otras.
Figura 8: Men´u de
”Whats Up?”
Figura 9: Diario de
”Whats Up?”
El documento completo de ingenier´ıa reversa se encuentra en el Anexo 12.1.2.
4.2.3. An´ alisis de documentos
A modo de comprender mejor el dominio y el contexto de la terapia cognitivo- conductual, se realiz´o una investigaci´on [16, p. 49] tomando informaci´on de diferentes fuentes bibliogr´aficas y de internet.
Debido a que el equipo no contaba con ning´un tipo de conocimiento en el ´area, se aprovecharon las entrevistas para consultar a los diferentes psic´ologos, cu´ales eran las fuentes y bibliograf´ıas m´as confiables y recomendables sobre la terapia cognitivo- conductual.
Se consultaron m´as de 20 art´ıculos, tanto en ingl´es como en espa˜nol y 3 libros, los cuales fueron de suma importancia: “Cognitive-behavioural therapy An infor- mation guide” [5], “Cognitive-behavioural therapy for dummies” [8] y “Cognitive- behavioural therapy Basics and Beyond” [7].
De esta investigaci´on se concluy´o que la situaci´on de pandemia ha obligado a disminuir la frecuencia de los encuentros presenciales, lo que, en la psicolog´ıa, ha llevado tanto a una creciente adopci´on de la tele-psicolog´ıa como a un aumento en los periodos inter-sesi´on.
Para los psic´ologos cognitivo-conductuales, la conceptualizaci´on y las t´ecnicas focalizadas en la emoci´on pueden ser de gran ayuda, ya que activar y acceder a experiencias emocionales, ayuda a los pacientes a reconocer los elementos cognitivos que est´an contenidos en cada esquema emocional.
En este contexto, la aplicaci´on de inteligencia artificial entre sesiones, es decir, analizando el contenido de los autorregistros realizados por los pacientes, puede ser la respuesta para lograr extraer t´opicos, polaridad o emociones y complementar la labor del psic´ologo que puede verse afectada por esta nueva modalidad.
4.3. An´ alisis
Luego de relevar los requerimientos, el equipo continu´o con el an´alisis [16, p. 50]
de los mismos. Esto implic´o refinarlos para garantizar que sean entendibles, siendo
´
util adem´as para buscar errores, omisiones y otras deficiencias. El an´alisis incluy´o la construcci´on de prototipos, el an´alisis de la viabilidad y la priorizaci´on de los requerimientos. El objetivo de estas t´ecnicas es poder descomponer de requisitos de alto nivel en requerimientos m´as detallados. A modo de obtener feedback temprano, el proceso y los resultados obtenidos de cada etapa del an´alisis, fueron compartidos y discutidos en conjunto con el cliente. Esto permiti´o poder introducir peque˜nos cambios requeridos por el mismo mientras se llevaban a cabo las etapas, y no uno de mayor tama˜no al final.
4.3.1. Interfaces de usuario
Se crearon bocetos de interfaces de usuarios [16, p. 50] con el fin de hacer los conceptos m´as tangibles y llegar a un acuerdo de c´omo el problema puede ser resuelto
en base a los requerimientos obtenidos en la etapa anterior.
La creaci´on de bocetos de interfaces de usuario, al igual que algunas otras t´ecnicas utilizadas en la parte de elicitacion, tambi´en es una t´ecnica compartida por el proceso de Design Thinking [9, p. 38] que el equipo llev´o a cabo en paralelo a la ingenier´ıa de requerimientos.
En una primera iteraci´on, el equipo gener´o prototipos de baja fidelidad debido a que no se contaba con requerimientos demasiado claros. Para esto, el quipo cre´o una presentaci´on con la ayuda de la herramienta online Canva. En esta presentaci´on se explicaba, a alto nivel, cu´ales eran las posibles funcionalidades y soluciones a las necesidades de los usuarios que el sistema pod´ıa contener. Es decir, se explicaba de que manera era posible ingresar un autorregistro al sistema (voz o texto), que y como el sistema analizaba los autorregistros ingresados y por ´ultimo, cu´al era el resultado obtenido de dicho an´alisis.
En la segunda iteraci´on sobre esta etapa, luego de tener requerimientos validados una primera vez, se construyeron interfaces de usuario de un dispositivo mobile, las cuales si bien no eran totalmente funcionales, se pod´ıa interactuar con las mismas.
Esta interacci´on fue posible gracias a la herramienta Adobe XD en la cual se crearon dichas vistas. Con estas interacciones era posible presionar ciertos botones, lo que generaba que la interfaz cambiara autom´aticamente, incluso en ocasiones mostrando datos pre cargados.
Figura 10: An´alisis de emociones en el prototipo
Figura 11: Evoluci´on del paciente en el prototipo
4.3.2. An´ alisis de viabilidad
Analizar la viabilidad [16, p. 50] de los requerimientos permite a los miembros del proyecto comprender los riesgos asociados con la implementaci´on de cada uno, las dependencias de factores externos y los obst´aculos t´ecnicos.
Teniendo esto en cuenta, los requerimientos que el equipo encontr´o importante analizar, fueron los relacionados con el procesamiento del lenguaje natural como: la conversi´on de voz a texto, el an´alisis de emociones en texto y el an´alisis de t´opicos y entidades en texto. Estas investigaciones ser´an explicadas con m´as detalle en el cap´ıtulo 5.
4.3.3. Priorizaci´ on de requerimientos
Otra t´ecnica utilizada fue la priorizaci´on [16, p. 50] de requerimientos analizando cu´ales eran las mayores dificultades presentadas por los usuarios.
Esta priorizaci´on se llev´o a cabo, en primera instancia, por los miembros del equipo del proyecto. El equipo utiliz´o la t´ecnica MoSCoW [17, p. 98] con la ayuda de la herramienta Miro. Cada uno colocaba los requerimientos en una matriz con 4 categor´ıas correspondientes a cada nivel de priorizaci´on: Must Have (requerimientos que deben ser incluidos en el sistema), Should Have (requerimientos que deber´ıan ser incluidos en el sistema), Could Have (requerimientos que podr´ıan ser incluidos en el sistema) y Wont Have (requerimientos que se tendr´an en cuenta para ser incluidos en un futuro). Posteriormente, se llevaba a cabo una puesta en com´un, en donde cada uno de los miembros del equipo daba una justificaci´on de por qu´e raz´on incluy´o cada requerimiento en su categor´ıa y se discut´ıa hasta llegar a un acuerdo sobre la priorizaci´on de cada requerimiento.
Figura 12: Ejemplo de priorizaci´on de requerimientos con MoSCoW
Luego se realiz´o una segunda instancia en conjunto con el cliente. Se le mostr´o el resultado de la priorizaci´on llevada a cabo por el equipo y se le pidi´o que, en base a esto, modificara y categorizara los requerimientos teniendo en cuenta sus propias necesidades. Esto fue ´util para garantizar que el equipo implemente primero los requerimientos con valor m´as alto tanto para los usuarios como para el cliente.
Como resultado final se obtuvo una matriz con los requerimientos priorizados en cada categor´ıa.
4.4. Especificaci´ on
La siguiente etapa fue la de especificaci´on [16, p. 51]. En esta etapa el equipo procedi´o a especificar formalmente lo relevado y analizado anteriormente. Para esto, el equipo decidi´o utilizar el formato de User Stories o historias de usuario [17], ya que se adapta mejor a una metodolog´ıa ´agil, adem´as de que facilita la comunicaci´on y la discusi´on con el cliente y los usuarios. As´ı mismo, las historias de usuario fomentan la discusi´on entre los integrantes del equipo, adem´as, a diferencia de otros formatos, no hablan sobre c´omo se deber´ıa realizar el trabajo para completar el requerimiento, logrando de esta manera ser m´as abiertas al cambio.
Al momento de escribir cada historia de usuario, se tuvo en cuenta las carac- ter´ısticas de INVEST [17, p. 17], es decir, cada requerimiento debe ser:
Independiente entre s´ı
Negociable con el cliente y los usuarios
Valuable, es decir, que aporte valor a los usuarios Estimable
Small o peque˜nas
Testable, para saber que est´a finalizada debe pasar los tests
Para facilitar la labor de cumplir con todas estas caracter´ısticas y seguir el for- mato correspondiente, se decidi´o que cada historia de usuario cuente con:
Un n´umero como identificador ´unico Un t´ıtulo que las describa
Una narrativa, con el formato Como ((rol)) quiero ((capacidad)) para ((obtener beneficio))
Criterios de aceptaci´on, para asegurar que los artefactos cumplen con los cri- terios de calidad
Notas o aspectos a tener en cuenta para discutir con el cliente y usuarios (en caso de ser necesarios)
Adem´as, para agregar completitud y consistencia a los requerimientos escritos, tambi´en se escribi´o un documento con los casos de uso [18] de los requerimientos
m´as relevantes. De esta manera, es posible saber cu´al es el flujo que debe seguir el sistema en cada situaci´on, quit´andole ambig¨uedad a los requerimientos.
Al igual que con las historias de usuario, el equipo tambi´en defini´o una estructura para los casos de uso, cada uno de estos cuenta con:
Un ID que lo identifique Un t´ıtulo descriptivo
Un actor quien lleva a cabo el caso de uso
El caso exitoso, es decir, como deber´ıa ser el flujo normal
Los casos alternativos, es decir, flujos posibles que podr´ıan suceder
Un ejemplo de caso de uso escrito es el siguiente:
Caso de uso 2: Baja de autorregistros
Actor: Usuario paciente
Precondici´on: Cuenta creada, usuario logueado y autorregistro creado Postcondici´on: Se elimina el autorregistro de la base de datos del sistema Caso exitoso:
1. Paciente: Indica que desea eliminar un determinado autorregistro 2. Sistema: Pregunta si est´a seguro de que desea eliminarlo
3. Paciente: Indica que si
4. Sistema: Elimina el autorregistro haciendo que ni el paciente ni el psic´olo- go (en caso de que el autorregistro estuviera compartido) ya no lo pueda visualizar
Casos alternativos:
1.a Indica que desea eliminar un autorregistro compartido:
1.a.1 Sistema: Notifica que el autorregistro se encuentra compartido 1.a.2 Paciente: Indica continuar
1.a.3 Vuelve al paso 2 3.a Indica que no
3.a.1 Sistema: no elimina el autorregistro y vuelve a la vista anterior Los requerimientos, tanto funcionales como no funcionales especificados en esta etapa, se encuentran listados en la secci´on de Alcance.
4.5. Verificaci´ on
La verificaci´on [15, p. 110] de los requerimientos, consiste en un conjunto orga- nizado de comprobaciones para evaluar si estos son acordes a un modelo de calidad definido. Es por esto que se llevaron a cabo dos documentos, los cuales contaban con una serie de preguntas, en forma de checklist, relacionadas a los requerimien- tos especificados, para saber cuando un requerimiento cumple con determinadas caracter´ısticas como: completitud, verificabilidad, no ambig¨uedad, correctitud, con- sistencia y trazabilidad.
En estos documentos se encontraban las preguntas para verificar, por un lado, las historias de usuarios y por otro los casos de uso. En el primero, se encuentran preguntas como:
¿Tiene cada requerimiento una ´unica interpretaci´on?
¿Existe conflicto entre requerimientos?
¿Puede cada requerimiento ser identificado correctamente y de forma ´unica?
Por otro lado, en el documento para los casos de uso se encuentran preguntas como:
¿Cumple el caso de uso con un ´unico objetivo o tarea?
¿Queda claro qu´e actor(es) participan y se benefician del caso de uso?
¿Es el caso de uso libre de detalles de dise˜no e implementaci´on de posibles soluciones?
De esta manera, fue posible verificar que todas las historias de usuario y casos de uso, cumplan con los criterios de calidad. De esta manera, no se corre el riesgo de implementar una mala especificaci´on, con el costo que esto podr´ıa implicar.
4.6. Validaci´ on
Una vez se encontraban los requerimientos definidos, se continu´o con la verifica- ci´on y la validaci´on [16, p. 52] de los mismos. Para esto el equipo utiliz´o diferentes t´ecnicas trabajando, por un lado, en conjunto con el cliente y por otro con los usua- rios finales.
Al igual que algunas t´ecnicas mencionadas anteriormente en la etapa de inge- nier´ıa de requerimientos, la validaci´on, tambi´en es una etapa compartida con el proceso de Design Thinking [9, p. 35]. La misma fue llevada a cabo en paralelo en ambos procesos.
4.6.1. Reuni´ on con el cliente
El equipo se puso en contacto con el cliente y le comparti´o los requerimientos especificados en la etapa anterior. De esta manera, el equipo logr´o tener una visi´on m´as clara de las necesidades del cliente y a su vez el cliente tuvo la posibilidad de agregar o quitar requerimientos.
4.6.2. Entrevistas
Por otro lado, el equipo se puso en contacto nuevamente con los psic´ologos entre- vistados en la etapa de elicitaci´on. Se coordinaron reuniones virtuales, en las cuales el equipo explic´o a los psic´ologos los requerimientos m´as relevantes y mostr´o los prototipos realizados en la etapa de an´alisis.
En total se realizaron 7 reuniones con 7 psic´ologos diferentes. De manera similar a las entrevistas realizadas en la etapa de elicitaci´on, las reuniones se llevaron a cabo a trav´es de una plataforma de videollamada online, en donde asist´ıan 2 integrantes del equipo y el psic´ologo. Los integrantes del equipo que asist´ıan, contaban con una lista de preguntas (para ver la lista completa, ver anexo 12.1.3), un texto gu´ıa en el que se explicaba el funcionamiento del sistema y el prototipo, sin embargo, se intent´o mantener un di´alogo fluido, permitiendo que el psic´ologo interrumpa la explicaci´on si as´ı lo deseaba. En el anexo 12.1.4 se pueden ver ejemplos de apuntes tomados por integrantes del equipo en estas entrevistas.
4.6.3. Encuestas
Finalmente, se realizaron 2 encuestas, una a pacientes y otra a psic´ologos. Para esto, el equipo utiliz´o la herramienta Google Forms la cual permiti´o al equipo com- partirla f´acilmente y obtener los resultados ordenados a medida que los usuarios la completaban.
A psic´ologos
Las encuestas realizadas a psic´ologos fueron orientadas a validar las tecnolog´ıas investigadas en la etapa de an´alisis de ingenier´ıa de requerimientos. M´as espec´ıfica- mente, a la herramienta de an´alisis de emociones, ya que a que es la m´as importante.
El objetivo fue verificar que la herramienta seleccionada para realizar esa tarea cum- pliera con las expectativas de los psic´ologos.
Para esto, se realizaron 3 encuestas similares. Estas encuestas contaban con las mismas preguntas, pero se diferenciaban en la informaci´on brindada. Es decir, en cada encuesta se presentaban autorregistros diferentes, para cada uno, se les pidi´o a los psic´ologos que clasificaran y analizaran autorregistros, realizando la misma tarea que llevar´ıa a cabo la herramienta. A continuaci´on, se les brindaba el an´alisis realizado por la herramienta (sobre el autorregistro previamente presentado), y se les solicit´o que eval´uen dicho an´alisis.
Esto permiti´o al equipo comprobar la eficiencia de la herramienta seleccionada para analizar emociones sobre los autorregistros. En el anexo 12.1.5, se encuentra la informaci´on de una de las tres encuestas realizadas a los psic´ologos junto con sus respuestas.
A pacientes
Por otro lado, la encuesta realizada a pacientes tuvo como objetivo validar as- pectos de usabilidad, se realizaron preguntas del tipo ¿En qu´e formato realiza auto- rregistros?, o Del 0 al 6 ¿Qu´e tanto le cuesta expresarse a trav´es de texto?. A modo de llegar a m´as usuarios, esta encuesta fue llevada a cabo en dos idiomas, ingl´es y espa˜nol.
El equipo hizo llegar la encuesta a los pacientes de dos maneras. Por un lado, el equipo le pidi´o a los psic´ologos contactados si era posible que compartieran la encues- ta con sus pacientes, por otro lado, el equipo busc´o grupos de Facebook espec´ıficos de terapia cognitivo-conductual, como CBT-REBT therapists, Cognitive Behavioral Therapy (CBT), Terapias Cognitivo-Conductuales, Conductuales Y Contextuales, entre otros. En estos grupos, el equipo realiz´o publicaciones solicitando a pacien- tes que realizaran la encuesta y a psic´ologos que compartieran la encuesta con sus pacientes.
Estas encuestas permitieron al equipo obtener un punto de vista diferente acerca de la importancia de los autorregistros, que hasta ahora hab´ıa sido brindado ´uni- camente por los psic´ologos. Al poder acceder a cierta informaci´on sobre los h´abitos y opiniones de pacientes que hacen uso de esta herramienta, se puede obtener una perspectiva m´as profunda sobre la relevancia que puede tener Paciente Presente no solamente para los psic´ologos, sino tambi´en para los pacientes. En el anexo 12.1.6,
se encuentran ejemplos de preguntas realizadas con sus respectivas respuestas.
4.7. Alcance
Como resultado de la etapa de ingenier´ıa de requerimientos, el equipo obtuvo dos propuestas de alcance, una en la primera iteraci´on y otra, la cual finalmente se design´o como propuesta de alcance final, luego de la segunda iteraci´on. Los reque- rimientos incluidos dentro de dicha propuesta se listar´an en las siguientes secciones de este documento.
En esta secci´on se detalla, desde un punto de vista funcional, la soluci´on pro- puesta en el cap´ıtulo 3.
Al inicio de este cap´ıtulo, se deja en claro que el equipo logr´o identificar que los usuarios finales del sistema podr´an desempe˜nar uno de los siguientes roles: pacien- te o psic´ologo. Por lo tanto, a continuaci´on se describen las funcionalidades m´as relevantes que el equipo incluy´o en el prototipo para cada uno de estos roles.
Funcionalidades para psic´ologos
En primer lugar, los usuarios psic´ologos ser´an capaces de visualizar a sus pacien- tes y los autorregistros compartidos por los mismos de forma cronol´ogica. Adem´as, podr´an acceder a un an´alisis de cada autorregistro, realizado a trav´es de inteligencia artificial.
Como se mencion´o anteriormente en el cap´ıtulo 3, este an´alisis se compone por dos partes. En primer lugar, el psic´ologo puede visualizar un an´alisis de emociones del autorregistro mostrando cu´ales son las m´as predominantes. Por otro lado, tam- bi´en se puede visualizar un an´alisis de los temas m´as relevantes tratados dentro del autorregistro.
A su vez, el psic´ologo puede ver el reporte de un paciente determinado. Este consta de una gr´afica que muestra las variaciones de las emociones detectadas en los diferentes autorregistros a lo largo del tiempo.
Otra funcionalidad para los psic´ologos que cabe mencionar, es la posibilidad de evaluar los an´alisis de los autorregistros realizados por el sistema. Es decir, una vez realizado un an´alisis a un autorregistro, obteniendo las emociones y los t´opicos, los psic´ologos son capaces de dar una puntuaci´on a ese an´alisis, en base a que tan acertado fue, y dejar un comentario sobre el mismo. Esta funcionalidad en particular, no surgi´o a partir de los usuarios, sino que fue solicitada por el cliente. El mismo pidi´o que se agregara esta funcionalidad, con el fin de poder obtener feedback sobre
el funcionamiento de las herramientas utilizadas y poder mejorar el resultado de los an´alisis si es necesario.
Funcionalidades para pacientes
Por otro lado, los usuarios pacientes, ser´an capaces de crear, modificar, borrar y visualizar sus autorregistros. A su vez, a la hora de crearlos, contar´an con una plantilla con los campos a completar y tendr´an la posibilidad de hacerlo tanto por medio de texto como por grabaciones de voz.
Los pacientes tambi´en ser´an capaces de vincularse con su psic´ologo. De esta ma- nera, la aplicaci´on les permitir´a compartirle f´acilmente los autorregistros que desee, en el momento que considere adecuado. Una vez compartidos, los autorregistros
´
unicamente podr´an ser accedidos por el propio paciente y por su psic´ologo.
A modo de especificar con m´as detalle las funcionalidades nombradas, se listar´an los requerimientos funcionales y no funcionales en las siguientes secciones.
4.7.1. Requerimientos funcionales
Como se mencion´o anteriormente, este alcance fue trabajado en conjunto con el cliente y los usuarios. En su mayor´ıa, los requerimientos funcionales fueron ob- tenidos de las necesidades de los usuarios, sin embargo, el cliente decidi´o agregar requerimientos basados en sus propias necesidades.
Cabe destacar que, debido al tipo acotado con el que contaba el equipo para el desarrollo del sistema, no todas las historias de usuario especificadas en la propuesta de alcance fueron implementadas. Gracias a la priorizaci´on realizada en la etapa de an´alisis y a la estimaci´on realizada, de la cual se hablar´a m´as adelante en el cap´ıtulo 7, fue posible discernir con facilidad, que historias de usuario ser´ıan implementadas y cu´ales no.
A continuaci´on se mostrar´a un listado con la informaci´on m´as relevante de todas las historias de usuarios incluidas en la propuesta de alcance final, diferenciando cu´ales fueron implementadas y cu´ales no. Las historias de usuario completas se encuentran en el anexo 12.1.7.
Historias de usuario implementadas
1. Realizar autorregistros
Como paciente quiero poder realizar un autorregistro para ejercitar la racionalizaci´on
