Recomendación personalizada de canciones

RECOMENDACIÓN PERSONALIZADA DE CANCIONES PERSONALIZED MUSIC RECOMMENDER TRABAJO FIN DE GRADO CURSO 2023-2024 AUTORAS LEIRE JIMÉNEZ GONZÁLEZ LAURA MARTÍNEZ TOMÁS DIRECTORA Mª BELÉN DÍAZ AGUDO GRADO EN INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID RECOMENDACIÓN PERSONALIZADA DE CANCIONES PERSONALIZED MUSIC RECOMMENDER TRABAJO DE FIN DE GRADO EN INGENIERÍA INFORMÁTICA AUTORAS LEIRE JIMÉNEZ GONZÁLEZ LAURA MARTÍNEZ TOMÁS DIRECTORA Mª BELÉN DÍAZ AGUDO CONVOCATORIA: JUNIO 2024 GRADO EN INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID 27 DE MAYO DE 2024 2 DEDICATORIA A todos los que nos han apoyado en todo este proceso. 3 AGRADECIMIENTOS Queremos agradecer a todas las personas que nos han rodeado y apoyado durante la elaboración de este proyecto. Este trabajo representa un camino lleno de aprendizaje y superación de desafíos. A Belén por guiarnos y orientarnos en todas las etapas del proyecto. A nuestros amigos y compañeros por ayudarnos y compartir con nosotras todos esos buenos y malos momentos, haciendo que el camino fuera más fácil. A nuestras familias por el apoyo constante. 4 RESUMEN Music4u, recomendación personalizada de canciones Hoy en día la música es una de las representaciones artísticas más usadas y accesibles para todo el público. Es por ello por lo que cada día son más las personas que utilizan plataformas digitales que ofrecen contenido musical, como Spotify, Amazon Music o YouTube, entre otras. La amplia variedad y el aumento progresivo de canciones en estas plataformas puede hacer que sea abrumador para el usuario. Los recomendadores suponen una buena solución a este problema, siendo de gran ayuda para clasificar y mostrar al usuario contenido relacionado con sus gustos y preferencias. En este Trabajo de Fin de Grado hemos implementado un algoritmo de recomendación híbrido de canciones mediante la investigación y análisis de diferentes técnicas. En nuestro caso hemos optado por un recomendador que aproveche las ventajas de los recomendadores basados en contenido y de filtrado colaborativo atendiendo a los problemas que pueden surgir, como es el cold-start y long tail, y la confianza del usuario con la recomendación, mejorándola con la explicabilidad. Asimismo, se ha desarrollado una interfaz de usuario para mostrar visualmente los resultados del algoritmo de recomendación al usuario. Palabras clave Música, recomendador, Python, explicabilidad, playlist. 5 ABSTRACT Music4u, personalized music recommender Music is one of the most widely used and accessible forms of artistic expression today. As a result, more and more people are using digital platforms that offer music content, such as Spotify, Amazon Music, or YouTube, among others. The wide variety and the progressive increase of songs on these platforms can make it overwhelming for users. Recommenders are a good solution to this problem, being of great help to classify and show users content related to their tastes and preferences. In this Final Degree Project, we have implemented a hybrid song recommendation algorithm through the research and analysis of different techniques. In our case, we have opted for a recommender that takes advantage of the advantages of content-based recommenders and collaborative filtering, considering the problems that may arise, such as cold-start and long tail, and the user's trust in the recommendation, improving it with explainability. Likewise, a user interface has been developed to visually show the results of the recommendation algorithm to the user. Keywords Music, recommendation, Python, explainability, playlist 6 ÍNDICE DE CONTENIDOS Capítulo 1 - Introducción ...................................................................................................... 1 1.1. Motivación .............................................................................................................. 1 1.2. Objetivos ................................................................................................................. 2 1.3. Plan de trabajo ...................................................................................................... 4 1.4. Proyecto .................................................................................................................. 5 Capítulo 2 - Estado de la cuestión ...................................................................................... 6 2.1. Fundamentos de los sistemas de recomendación. ......................................... 7 2.1.1. Tipos de sistemas de recomendación. ........................................................ 8 2.1.1.1. Filtrado colaborativo. .............................................................................. 9 2.1.1.2. Basado en contenidos. ......................................................................... 11 2.1.1.3. Sistemas híbridos. .................................................................................... 13 2.1.2. Explicabilidad ................................................................................................ 15 2.1.3. Problemas ...................................................................................................... 19 2.1.3.1. Problemas de Cold-Start ....................................................................... 19 2.1.3.2. Problemas de Long Tail ......................................................................... 20 2.2. Arquitectura software ......................................................................................... 22 2.3. Metodología ......................................................................................................... 24 2.4. Tecnologías........................................................................................................... 27 2.4.1. Lenguajes ....................................................................................................... 28 2.4.2. Librerías ........................................................................................................... 28 2.4.3. Frameworks .................................................................................................... 29 2.4.4. Herramientas ................................................................................................. 30 7 Capítulo 3 - Implementación ............................................................................................. 31 3.1. Metodología ......................................................................................................... 31 3.2. Descripción del conjunto de datos .................................................................. 31 3.2.1. Dataset canciones ....................................................................................... 32 3.2.2. Dataset rating ................................................................................................ 34 3.3. Diseño de la interfaz de usuario ........................................................................ 35 3.4. Desarrollo del algoritmo de recomendación.................................................. 44 3.4.1. Primera versión .............................................................................................. 44 3.4.2. Segunda versión............................................................................................ 46 3.4.3. Tercera versión .............................................................................................. 46 3.4.4. Última versión ................................................................................................. 48 3.5. Desarrollo de la aplicación web. ...................................................................... 50 3.5.1. Back-End ........................................................................................................ 52 3.5.1.1. Tabla “Cancion". .................................................................................... 54 3.5.1.2. Tabla Rating. ........................................................................................... 55 3.5.1.3. Tabla Playlist. ........................................................................................... 55 3.5.1.4. Tabla Usuario. .......................................................................................... 56 3.5.2. Front-End ........................................................................................................ 56 Capítulo 4 - Evaluación con usuarios ................................................................................ 67 4.1. Preparación del plan de evaluación ............................................................... 67 4.2. Preparación del entorno de evaluación ......................................................... 68 4.3. Encontrar y seleccionar a los usuarios .............................................................. 68 4.4. Preparación de los materiales para la evaluación ........................................ 69 4.5. Sesiones de evaluación ...................................................................................... 69 8 4.6. Debriefing con los participantes y los observadores...................................... 74 4.7. Análisis de los datos y las observaciones. ........................................................ 77 4.8. Informe de hallazgos y recomendaciones. ..................................................... 79 Capítulo 5 - Conclusiones y trabajo futuro ....................................................................... 80 5.1. Conclusiones. ....................................................................................................... 80 5.2. Trabajo futuro. ...................................................................................................... 81 4 5. Objetivo 5. Experimentar con usuarios reales para validar el diseño propuesto. a. Tarea 5.1. Crear usuarios de prueba para probar el funcionamiento. b. Tarea 5.2. Integrar en el sistema usuarios potenciales de la aplicación. 6. Objetivo 6. Escribir y revisar la memoria. a. Tarea 6.1. Desarrollo secuencial de la memoria. b. Tarea 6.2. Revisión de la completitud y cohesión de la memoria. 1.3. Plan de trabajo Para establecer el plan de trabajo hemos tenido en cuenta los tiempos de investigación, desarrollo y entrega de cada una de las partes de nuestro proyecto. Durante todo el proceso hemos seguido un desarrollo ágil basado en la metodología Scrum (ver apartado 2.3) con entregas pequeñas en periodos cortos de tiempo (generalmente, dos semanas), adaptando las necesidades que pudieran surgir a estos objetivos de tiempo. También, hemos realizado reuniones periódicas para revisar los progresos, la calidad y poner en común el trabajo a realizar futuro. Para realizar el seguimiento de todo este proceso, hemos usado la herramienta Excel con las diferentes tareas a realizar en los sprints y los tiempos de entrega. La investigación ha sido la primera tarea realizada, con el fin de familiarizarnos con los conceptos y conocer las diferentes herramientas disponibles para la posterior implementación de nuestro proyecto. Estas investigaciones se han realizado durante todo el proceso de desarrollo del proyecto con el fin de mejorar la consistencia y rendimiento del trabajo. Después de realizar la fase de investigación y alcanzar los conocimientos necesarios, hemos continuado con la fase de desarrollo. En esta fase hemos implementado el algoritmo recomendador y la aplicación, y nos ha servido para poner en práctica todo lo estudiado anteriormente. Durante la evolución del trabajo, hemos ido alternando las dos fases anteriormente mencionadas, investigación y desarrollo, con la tarea de escritura de la 5 documentación del proyecto. También, hemos ido corrigiendo los errores o cambios producidos en el transcurso del mismo para que la información aquí presente esté actualizada y conforme con el trabajo realizado. 1.4. Proyecto Para la gestión y colaboración en el desarrollo de nuestro proyecto, utilizamos GitHub, una de las plataformas de control de versiones y alojamiento de código que hemos usado en diferentes asignaturas a lo largo de la carrera (ver enlace). A continuación, enlazamos unos vídeos de los diferentes flujos de la aplicación: • Registro de usuario (ver enlace). • Perfil de usuario y cierre de sesión (ver enlace). • Descubrir canciones (ver enlace) • Crear playlist (ver enlace). • Mis favoritos y mis playlists (ver enlace) 6 Capítulo 2 - Estado de la cuestión Para este proyecto nos hemos centrado en el estudio de los sistemas de recomendación, una rama de la inteligencia artificial que ha cobrado gran relevancia en los últimos años y cómo integrarlo en una aplicación web, como hemos introducido en el capítulo anterior (sección 1.1). Por ello hemos estudiado los diferentes tipos de recomendadores para designar cual se adecua mejor a nuestro propósito. Además de investigar las distintas arquitecturas de software. En este capítulo introducimos los sistemas de recomendación, que son herramientas que proporcionan sugerencias personalizadas a los usuarios (sección 2.1). Existen distintos tipos de recomendadores (sección 2.1.1), entre los que destacan los basados en contenido, los colaborativos y los híbridos. Cada uno de estos tipos tiene sus ventajas y desventajas, y su elección depende del sistema y múltiples factores (tabla 2.2). Otro aspecto importante en los sistemas de recomendación es la explicabilidad, es decir, la capacidad de proporcionar a los usuarios razones comprensibles sobre por qué se les ha recomendado un determinado ítem (sección 2.1.2). La explicabilidad no solo aumenta la confianza del usuario en el sistema, sino que también puede mejorar su satisfacción y su compromiso con el sistema (tabla 2.3). Sin embargo, los sistemas de recomendación también se enfrentan a varios desafíos. Entre ellos están los problemas de cold-start y long tail. El problema de coldstart (sección 2.1.3.1) se refiere a la dificultad de hacer recomendaciones para nuevos usuarios o artículos, mientras que el problema de long tail se refiere a la tendencia de los sistemas de recomendación a concentrarse en un pequeño número de ítems populares, ignorando la gran cantidad de ítems menos populares (sección 2.1.3.2). Asimismo, en esta sección también se detallarán los fundamentos de los lenguajes usados (sección 2.4), la arquitectura software (sección 2.2) y la metodología (sección 2.3) seguida para el desarrollo del algoritmo de recomendación, así como los de la aplicación. 7 2.1. Fundamentos de los sistemas de recomendación. La idea de los sistemas de recomendación (Ricci et al. 2010) surgió al observar que las personas a menudo confían en recomendaciones de otros para tomar decisiones diarias. Este enfoque inicial, conocido como filtrado colaborativo, es una de las técnicas más usadas en las recomendaciones y en el que se aprovecha los gustos de usuarios similares. Los sistemas de recomendación se siguen estudiando en la actualidad ya que se trata de algo relativamente reciente, surgiendo como área de investigación en la década de 1990. El campo de investigación aborda diversas técnicas, explicabilidad de recomendaciones (como XAI o Inteligencia Artificial Explicable), interacción con los usuarios y algoritmos avanzados para mayor eficiencia y fiabilidad, así también incluye el uso de contenido generado para el usuario y la protección del usuario. Actualmente se celebran conferencias dedicadas al tema de los sistemas de recomendación y se ofrecen cursos para el aprendizaje del desarrollo de estos en instituciones educativas. Asimismo, con el desarrollo de sitios web de comercio electrónico en los años 2000, surgió la necesidad de filtrar la amplia gama de opciones disponibles. Los sistemas de recomendación ayudan a superar la sobrecarga de información al dirigir al usuario hacia ítems nuevos y relevantes para su tarea actual. Por lo que desempeñan un papel crucial en servicios digitales populares como Amazon, YouTube, Netflix, Tripadvisor y muchos más, ya que supone un aumento en las ventas y beneficios para estos sí está bien diseñado el recomendador. Simplificando la funcionalidad de los sistemas de recomendación, las recomendaciones personalizadas se ofrecen como listas clasificadas de ítems, que son evaluadas y clasificadas basándose en las preferencias del usuario. Las preferencias del usuario pueden ser proporcionadas explícitamente por el usuario o mediante interacciones, por ejemplo, con clasificación del ítem recomendado. Se ha de tener en cuenta que no necesariamente se trata de recomendaciones personalizadas, también existen recomendadores no personalizados. 8 2.1.1. Tipos de sistemas de recomendación. Todo modelo de sistema de recomendación opera con dos tipos de datos, y dependiendo de cuál prevalezca, se clasifica como un tipo específico de sistema de recomendación. Un tipo de datos se refiere a las interacciones entre el usuario y el ítem, como es el ejemplo ratings o valoraciones de la recomendación o el historial de compra. El otro tipo corresponde a la información asociada a los usuarios e ítems del sistema, como en el caso de las películas, que es un ítem, un género sería una característica (Aggarwal 2016). Si el sistema recomendador se basa principalmente en el primer tipo de datos, se clasifica como un sistema de filtrado colaborativo (sección 2.1.1.1), el cual es el modelo más comúnmente empleado en los sistemas recomendadores actuales. Este enfoque tiene en cuenta los ratings de todos los usuarios y cuanto más similares sean dos usuarios, más se recomendarán los ítems que el otro usuario ha valorado de manera positiva (Aggarwal 2016). Por otro lado, si el sistema utiliza principalmente el segundo tipo de datos, se trata de una recomendación basada en contenidos (sección 2.1.1.2). En este caso, la recomendación se realiza por similitud de ítems con características asociadas parecidas a los ítems que le gustaron al usuario anteriormente, por ejemplo, si el historial de un usuario es que le gustaron bastante canciones del género pop, la canción a recomendar será pop también. Este tipo de recomendadores busca satisfacer de manera precisa las necesidades del usuario (Aggarwal 2016). Además, existe la posibilidad de desarrollar sistemas de recomendación híbridos (sección 2.1.1.3), que combinan aspectos de distintos modelos de recomendadores. Esto se hace comúnmente para aprovechar las ventajas de un modelo y corregir las desventajas del otro (Ricci et al. 2010). Existen más modelos de recomendadores como los basados en conocimientos, demográficos, basados en grafos, etc. (Aggarwal 2016) (Caro Martínez 2022). En la Tabla 2.1 se muestran las comparativas de cada tipo. 9 Enfoque Descripción Datos Filtrado colaborativo Proporciona recomendaciones basadas en un enfoque colaborativo aprovechando las ratings y acciones del propio usuario como de los demás usuarios del sistema. ratings del usuario + ratings del resto de usuario Basado en contenidos Proporciona recomendaciones basadas en el contenido (atributos) que ha favorecido en ratings y recomendaciones anteriores. ratings del usuario + atributos de los ítems Tabla 2-1. Comparación de las características principales de los modelos básicos de sistemas de recomendación (Caro Martínez 2022) 2.1.1.1. Filtrado colaborativo. El filtrado colaborativo es un modelo fundamental, como bien se trata en los libros de (Aggarwal 2016) (Ricci et al. 2010) (Jannach et al. 2011), en el campo de los sistemas de recomendación, utilizada para predecir ítems que puedan gustar al usuario y prever las preferencias de éste en función de la información acumulada sobre las interacciones y valoraciones o ratings de todos los usuarios del sistema. La premisa básica es que, si dos usuarios tienen historiales de interacciones o ratings similares, es probable que compartan preferencias y, por lo tanto, las recomendaciones de uno pueden ser aplicables al otro. Esta técnica se basa en la idea de que las comunidades de usuarios comparten similitudes en sus comportamientos y preferencias. A través del análisis de patrones en los ratings o acciones de un grupo de usuario, el sistema puede predecir y sugerir ítems que podrían interesar al usuario actual. Esta información obtenida se ha vuelto esencial en la industria, como en sitios de venta en línea, donde se personaliza el contenido según las necesidades de un cliente específico para mejorar la experiencia del usuario, fomentar la compra de artículos adicionales y aumentar las ventas. El filtrado colaborativo puede implementarse de distintas maneras ya que hay distintos enfoques para éste. Los métodos más utilizados, según (Aggarwal 2016), son los conocidos métodos basados en memoria y los métodos basados en modelos: 10 1. Basados en memoria. También conocidos como basados en vecinos. Se trata de obtener ratings usuario-ítem en función de sus vecinos. Los vecinos son aquellos usuarios que valoran parecidos entre sí o ítems que son valorados parecidos. Estos vecinos pueden ser acorde al estudio realizado por (Caro Martínez 2022): ● Basados en usuarios. Determina la clasificación de un ítem A para un usuario X acorde a la clasificación dada por los vecinos del usuario X al ítem A. ● Basados en ítems. Determina la clasificación de un ítem A para un usuario X acorde a la clasificación dada por el usuario X a los vecinos del ítem A. 2. Basados en modelo. Utilizan métodos de aprendizaje automático y minería de datos para modelos predictivos. Algunos métodos son árboles de decisión, sistemas basados en reglas, Naive Bayes, modelos de variable latentes o factorización de matrices, entre otros. El método de factorización (Ko et al. 2022) de matrices permite comprender las preferencias de los usuarios a través de datos de evaluación, almacenados como vectores en una matriz. Esto facilita la identificación de factores latentes que expresan la información del usuario y sus preferencias. Una forma de usar este método es con la descomposición de valores singulares (SVD), que ayuda a predecir los datos a los clientes de manera eficiente, transformando usuarios y elementos en un espacio común de factores latentes. Otra forma es usando las matrices de utilidad, que se encargan de almacenar información sobre las interacciones entre usuarios e ítems, como las calificaciones dadas por los usuarios a los ítems. Para utilizar correctamente estas matrices se usan en modelos de filtrado colaborativo con métodos como las matrices de factorización o modelos basados en memoria (Ho, Le, and Vu 2023). En resumen, el filtrado colaborativo se basa en la premisa de que la sabiduría colectiva de la comunidad de usuarios puede guiar de manera efectiva las recomendaciones personalizadas. Este enfoque ha evolucionado a lo largo del tiempo, 11 con desarrollos continuos y adaptaciones, como se evidencia en la investigación y la competencia en el campo de los sistemas de recomendación. 2.1.1.2. Basado en contenidos. Los sistemas de recomendación basados en contenido, como también se trata en los libros de (Aggarwal 2016) (Ricci et al. 2010) (Jannach et al. 2011), son una categoría de algoritmos de recomendación que utilizan los atributos descriptivos de los ítems para proporcionar recomendaciones personalizadas a los usuarios. El término “contenido” en este contexto se refiere a las características que describen los ítems, como palabras claves, género, actores y otra información relevante. En los métodos basados en contenido, las recomendaciones se generan analizando las características de los ítems y combinándolas con los ratings o historial del comportamiento del usuario, si hay. El historial de interacciones del usuario con los distintos ítems, como los ratings, se utilizan como datos de entrenamiento para crear un modelo de clasificación o regresión específico del usuario. Además, estos datos de entrenamiento también incluyen las características de los ítems que el usuario haya interactuado en el algún momento. Así se crea un perfil para cada usuario teniendo en cuenta estos ítems y se utiliza para predecir si al usuario las preferencias del usuario, incluso si el ítem no tiene ningún rating. En cuanto a los aspectos positivos de este modelo de sistema de recomendación es que realiza recomendaciones para nuevos ítems, como una nueva canción que ha sido recién sacada, que pueden no tener suficientes ratings o no tiene valoraciones directamente, ya que este modelo aprovecha los atributos similares de otros ítems ya calificados por el usuario para hacer predicciones. Otro aspecto positivo es la independencia de unos usuarios con otros del sistema, ya que se trata de un sistema basado en contenido, en el que solo se tiene en cuenta los ratings proporcionados por el usuario que se va a construir el perfil. Esto último hace contraste con el método de filtrado colaborativo, explicado en el apartado anterior. Otra ventaja que ofrecen los modelos de recomendación basados en contenidos es que es más fácil producir explicaciones de las recomendaciones por las características. 12 Por otro lado, este modelo tiene desventajas, como es el caso de realizar recomendaciones obvias, debido a basarse en palabras claves o atributos, llevando a una reducción en la diversidad de recomendaciones. Además de resultar menos efectivos para nuevos usuarios por la ausencia o escasos ratings o historial de interacción con los ítems del sistema. Por lo que de primeras resulta difícil proporcionar recomendaciones precisas y a esto se le denomina cold-start, un problema clásico de los sistemas de recomendación (Gope and Jain 2017) que describiremos en la sección 2.1.3.1. Estos son los motivos por los que este tipo de recomendadores se usan en sistemas híbridos, para aprovechar sus ventajas y reducir sus desventajas con otro modelo. A este modelo se le puede especificar alguna especificación por parte del usuario. Sin embargo, esto a veces se le conoce como sistemas basados en conocimientos, lo que provoca que haya una línea muy fina entre estos dos modelos. Para calcular la similitud entre los elementos hay distintos métodos (Ko et al. 2022) como los modelos de vectores de espacio, TF-IDF, Naive Bayes o SVM, que se usa cuando se quiere hacer la similitud por lo parecido en texto, por ejemplo, cuando se parece un género del otro, es que paso como en rock y punk-rock, que son parecidos entre sí. Otros métodos son por vecinos próximos, como K-NN o Clustering. Clustering (Ko et al. 2022) es un algoritmo utilizado para agrupar datos en categorías o clusters, con el fin de describir patrones y similitudes entre ellos. El método más común es el clustering K-Means, que asigna datos al cluster más cercano basado en la similitud y repite el proceso para determinar el centro del cluster. Este tipo de algoritmo se usa en filtrado colaborativo, pero también en basado en contenido. En resumen, los sistemas basados en contenidos se enfrentan a desafíos como el análisis de contenido limitado y la sobre especialización. Para mejorar este modelo o se combina con otro modelo, conocido como sistemas de recomendación híbridos, o utilizando conocimientos comunes y específicos del dominio, es decir, pasando a ser sistemas de recomendación basados en conocimiento. Pero este modelo presenta ventajas que hace que sus recomendaciones sean precisas. 13 2.1.1.3. Sistemas híbridos. Un sistema de recomendación híbrido (Aggarwal 2016) (Burke 2002) (Jannach et al. 2011) es un enfoque sofisticado que aprovecha las fortalezas de múltiples métodos de recomendación para superar las limitaciones asociadas con modelos individuales, las cuales se encuentran en la Tabla 2.2. Este tipo de recomendadores están diseñados para integrar fuentes de datos y aprovechar el poder algorítmico de varios sistemas de recomendación para obtener recomendaciones más sólidas y precisas. Hay tres formas principales (Aggarwal 2016) de crear sistemas de recomendación híbridos: diseño en conjunto o ensemble design, diseño monolítico o monolithic design y sistemas mixto o mixed systems. Enfoque Ventajas Desventajas Filtrado colaborativo A. Puede identificar clientes B. No es necesario el conocimiento del dominio C. La calidad mejora con el tiempo D. Retroalimentación implícita suficiente H. Problema en nuevos usuarios I. Problema en incremento de nuevos artículos J. Problema de la "caja negra” K. La calidad de la recomendación depende de un conjunto de datos históricos. L. Problema de estabilidad frente a plasticidad Basado en contenidos B, C, D H, K, L Tabla 2-2. Comparación de las ventajas y desventajas principales de los modelos básicos de sistemas de recomendación (Burke 2002) 1. Diseño en conjunto. Estos sistemas utilizan múltiples algoritmos de recomendación, tratando cada uno como un componente separado. Las recomendaciones de estos sistemas se combinan luego en una salida única. Esta combinación puede ser secuencial, donde la salida de un recomendador se utiliza como entrada para otro, o paralela, donde los recomendadores funcionan de manera independiente y sus predicciones se combinan al final. 20 Para abordar este problema, un enfoque es utilizar información adicional sobre los usuarios, como sus datos demográficos o intereses, para ayudar a clasificar a los usuarios y encontrar usuarios similares o ítems que les puedan interesar. Sin embargo, este enfoque se aleja de un sistema puramente colaborativo y plantea un nuevo modelo híbrido combinado con un sistema basado en conocimiento. También se utilizan mecanismos de conmutación (Jannach et al. 2011) para manejar el problema de cold-start. Estos mecanismos implican usar un recomendador cuando hay menos datos disponibles y cambiar a otro recomendador cuando hay más datos disponibles, es decir, pasar a un modelo híbrido (sección 2.1.1.3), que ya hemos hablado anteriormente. Otro mecanismo es la recomendación grupal (Ricci et al. 2010), que cuando un usuario es nuevo en el sistema, se proporcionan recomendaciones que mantendrían contento a todo grupo de usuarios existentes. Gradualmente, a medida que el sistema aprende sobre los gustos del nuevo usuario, el peso asociado al nuevo usuario aumenta, y los pesos asociados a usuarios existentes cuyos gustos difieren del nuevo usuario disminuyen. Hay más técnicas para solucionar el problema como recopilar información faltante, ratings por defecto y, como hemos dicho, enfoques híbridos. En resumen, el problema de cold-start es un desafío significativo en los sistemas de recomendación, y se han propuesto diversas estrategias para abordarlo. Estas estrategias buscan recopilar información faltante, ya sea de manera explícita o implícita, y utilizar esta información para hacer recomendaciones precisas y relevantes. También buscan reducir el sesgo, garantizar la adaptabilidad y mantener la diversidad en las recomendaciones (Gope and Jain 2017). 2.1.3.2. Problemas de Long Tail En muchos escenarios del mundo real, la distribución de ratings o interacciones con ítems sigue una distribución de Long Tail (Ricci et al. 2010) (Aggarwal 2016) (Park and Tuzhilin 2008). Esto significa que un pequeño número de ítems son muy populares y tienen 21 muchos ratings, mientras que un gran número de ítems son menos populares y tienen pocos ratings. El problema surge al intentar hacer recomendaciones basadas en estos ítems menos populares. Debido a que tienen menos ratings, es más difícil hacer predicciones precisas sobre si a un usuario le gustará o no. Esto puede llevar a una disminución en la calidad de las recomendaciones. Un enfoque para abordar este problema es utilizar métodos de filtrado colaborativo, que hacen recomendaciones basadas en el comportamiento de usuario similares (ver sección 2.1.1.1). Sin embargo, estos métodos pueden verse influenciados por los ratings de los ítems populares y pueden ignorar los ítems que reciben muy pocos ratings. Otro enfoque es construir modelos (Park and Tuzhilin 2008) individuales de estimación de ratings para cada ítem. Sin embargo, este método tiende a aumentar las tasas de error para los ítems de baja clasificación en la cola del conjunto de ítems, lo que lleva nuevamente al problema de recomendación Long Tail. Para resolver este problema, una estrategia es el clustering o agrupamiento de ítems para que los modelos predictivos aprendan utilizando más datos, disminuyendo así las tasas de error para los ítems menos populares. Este método, conocido como Total Clustering (TC) o agrupamiento total, ha demostrado superar al método Each Item (cada ítem), especialmente para ítems en la cola de la distribución. Sin embargo, el método de TC puede ser computacionalmente costoso y puede no escalar bien a problemas de recomendación grandes. Una solución alternativa es dividir el conjunto de ítems en la cabeza y la cola y realizar el agrupamiento solo en la cola. Este enfoque puede producir tasas de error más pequeñas que TC en algunos casos, al tiempo que logra resultados de rendimiento razonables. En conclusión, el problema de Long Tail es un desafío significativo en los sistemas de recomendación, pero se pueden emplear diversas estrategias para abordarlo y mejorar la calidad de las recomendaciones para ítems menos populares. Estas 22 estrategias implican equilibrar la necesidad de recomendaciones precisas con las demandas computacionales de los métodos utilizados. En las secciones subsiguientes de este capítulo, abordaremos los aspectos restantes del trabajo. En la sección 2.2, profundizaremos en la arquitectura del software. Posteriormente, en la sección 2.3, discutiremos las metodologías empleadas para el desarrollo de la aplicación web. Finalmente, en la sección 2.4, exploramos las tecnologías web que se utilizarán en el proyecto. 2.2. Arquitectura software Para poner en contexto el concepto de arquitectura del software, nos tenemos que remontar a la década de los 70 donde aún no se contaba con una etapa para el diseño del sistema, y fue a partir de entonces cuando se empieza a distinguir entre pequeños o grandes programas. Llegando ya a la década de los 90, se empieza a construir el concepto de Arquitectura del Software en la Universidad de Carnegie-Mellon y el Instituto de Ingeniería del Software, que es el principio que conocemos actualmente. La arquitectura software es el diseño y la especificación de alto nivel de un sistema software, considerando aspectos estructurales, funcionales y relacionados con el rendimiento para garantizar la eficacia y el éxito del sistema. (Garlan and Shaw 1994). Por lo tanto, la arquitectura de software es fundamental para el buen funcionamiento y resultado del proyecto ya que nos ayuda a planificar el desarrollo y nos permite elegir las herramientas adecuadas para llevarlo a cabo. Utilizamos los patrones de arquitectura (Castro, 2012) como soluciones generales para problemas frecuentes en el diseño y desarrollo de aplicaciones. Algunos de los patrones más comunes son: 1. Modelo Vista Controlador (MVC). Dividen la aplicación en tres componentes (modelo, vista y controlador). Separa los datos y la lógica de su representación y del módulo de gestión. 23 2. Capas. Divide la aplicación en capas lógicas. Esto permite descomponer las tareas en grupos de subtareas en la que las capas inferiores proporcionan servicios a las capas superiores. 3. Cliente Servidor. Consta de dos partes (un servidor y múltiples clientes). El servidor proporciona servicios a los clientes y los clientes solicitan servicios a dicho servidor. 4. Microservicios. Consta de varias aplicaciones pequeñas e independientes que uniéndose forman el programa principal. Estos son algunos de los patrones más usados, pero existen muchos más. Dependiendo de los requisitos de cada proyecto, se usarán unos u otros, incluso se pueden combinar (Jiménez Torres, Tello Borja, and Ríos Patiño 2014). Para el desarrollo de nuestro proyecto hemos decidido utilizar el patrón Modelo Vista Controlador (MDN contributors 2023), que es un patrón en el diseño de software comúnmente utilizado para implementar interfaces de usuario, datos y lógica de control, y se centra en separar la lógica de la aplicación con la visualización de esta misma (Fernández Romero and Díaz González 2012). El concepto de MVC fue introducido por Trygve Reenskaug en los años 70 (Reenskaug 2003) y se propuso como forma de desarrollo de interfaces de usuario en aplicaciones de escritorio. Actualmente, este concepto sigue vigente y su implementación existe en muchos tipos de sistemas y lenguajes. En esta arquitectura (Voorhees 2020) se realiza una separación de la aplicación en tres componentes de diseño: 1. Modelo. Responsable de gestionar los datos, implementa la lógica para crear, leer, actualizar y eliminar los datos de la aplicación. 2. Vista. Proporciona una interfaz para las interacciones del usuario. 3. Controlador. Responsable de la lógica de dominio. Básicamente el controlador comunica los componentes de vista y modelo. Para clarificar, el flujo de control de este patrón queda reflejado en la Figura 2.1. 24 Figura 2-1. Diagrama de MVC inspirado en (MDN contributors 2023) Las ventajas (Voorhees 2020) que ofrece este modelo es mantener la interfaz de usuario separada de la gestión de datos, lo que provoca que cualquier cambio en alguna de estas no afecte a la otra y así, también, permite mejor mantenimiento. 2.3. Metodología La evolución de los desarrollos software (Esteban Gabriel, 2015) y el aumento de la complejidad de las tareas hacen que a finales de los 60 surja la necesidad de controlar los avances de los proyectos, estructurar de manera clara los equipos de trabajo y crear fases diferenciables para poder realizar verificaciones intermedias. Así como, la necesidad de documentar estos procesos y mayores estándares. (Zumba Gamboa and León Arreaga, 2018) Actualmente, y después de todos los modelos propuestos en el tiempo, podemos definir una metodología de desarrollo software como un enfoque estructurado para el desarrollo de software que incluye modelos de sistemas, notaciones, reglas y guías de procesos (Zumba Gamboa and León Arreaga, 2018). Las metodologías de desarrollo de software nos permiten controlar, estructurar y planificar todo el proceso de desarrollo del software para lograr que sea eficiente y 25 efectivo en todas sus fases, y permitir una correcta comunicación entre los equipos desarrolladores. La elección de la metodología es clave para el éxito del desarrollo y no existe una metodología correcta, dependiendo de los requisitos y los objetivos podremos aplicar una u otras. Las metodologías se dividen en tradicionales y ágiles (Esteban Gabriel, 2015). Las metodologías tradicionales se basan en realizar la planificación al inicio del proyecto, es decir, tener documentada la especificación de requisitos, modelado y plan de trabajo en la fase inicial. Este método plantea un enfoque lineal de las etapas del desarrollo, una etapa debe ser completada antes de pasar a la siguiente. Estas metodologías no se adaptan a cambios, por lo que su uso se debe realizar cuando los requisitos pueden predecirse y no dan lugar a variaciones. Las metodologías ágiles (Canós et al. 2003) nacen como una solución a los problemas derivados de las metodologías tradicionales, se basan en la flexibilidad, y pueden ser modificadas para ajustarse a los cambios que puedan ocurrir durante el desarrollo del software. El proyecto se divide en subproyectos más pequeños y cada uno se trata independiente y desarrolla características en un corto periodo (Navarro Cadavid et al.). 2013) En la Tabla 2.4 podemos encontrar las diferencias más relevantes entre las metodologías ágiles y las tradicionales. 26 Tabla 2-4. Diferencias entre metodología ágiles y no ágiles (Canós, Letelier, and Penadés 2003) En este proyecto, nos vamos a centrar en las metodologías ágiles, en concreto en una de las más representativas: Scrum (Schwaber and Sutherland 2020). Scrum nace en el año 1986 gracias a un artículo publicado por Takeuchi y Nonaka en el que se define un nuevo enfoque en el desarrollo de productos, centrado en mejorar la agilidad y flexibilidad de los procesos. Está diseñado para lograr la colaboración eficaz de equipos. Dentro de un equipo se atribuyen diferentes roles: Scrum Master (encargado de comprobar que el modelo y la metodología funcionan), Product Owner (encargado de tomar las decisiones durante el proceso) y equipo de desarrollo (compuesto por un equipo pequeño de 5-9 personas que organizan y toman decisiones para conseguir el objetivo). Esta metodología tiene como base la entrega del proyecto en pequeñas iteraciones llamadas “Sprints”. Cada Sprint corresponde a un periodo de tiempo en el que se realiza una parte del desarrollo del producto, y su duración máxima es de un mes. Un Sprint se compone de los diferentes elementos (Schwaber and Sutherland 2020): 1. Planificación del Sprint. Se establece el trabajo que se realizará en ese Sprint y es realizado por todo el equipo. 27 2. Daily Scrum. Lo realiza el equipo de desarrollo y tiene el propósito de poner en común el trabajo realizado hasta el momento y el progreso a realizar hasta el objetivo. 3. Revisión del Sprint. Se revisa el resultado del Sprint y se discute el progreso hacia el objetivo del proyecto. 4. Retrospectiva del Sprint. Se analiza los aspectos como la comunicación, el proceso y las herramientas del Sprint terminado para determinar posibles mejoras para el siguiente. Esta metodología se realiza en varias fases (Trigas Gallego 2012): 1. Preparación del proyecto (sprint 0). Es la fase inicial en la que se define el proyecto, el Backlog inicial, los entregables y se constituye el equipo. 2. Planificación del Sprint. En esta fase se realiza una reunión en la que participan todos los miembros del proyecto y tiene como finalidad seleccionar las funcionalidades sobre las que se va a trabajar en ese Sprint. 3. Desarrollo del Sprint. en esta fase se trabaja para cumplir los objetivos propuestos en ese Sprint. 2.4. Tecnologías En esta sección se detalla el conjunto de tecnologías que se han empleado en el desarrollo de este proyecto. La elección de estas tecnologías no ha sido aleatoria, sino que se ha basado en su relevancia en la industria actual, su robustez y la eficiencia que proporcionan en el desarrollo del software. En la sección 2.4.1 se describen los lenguajes de programación utilizados que es la base de cualquier desarrollo de software. En la sección 2.4.3 se detallan los frameworks empleados, es decir, los conjuntos de librerías que facilitan el desarrollo de software. En la sección 2.4.4 se detallan las herramientas que se van a utilizar para facilitar el desarrollo del proyecto. Estas herramientas abarcan desde entornos de desarrollo 28 integrados (IDEs), como Visual Studio Code, hasta sistemas de control de versiones, como es GitHub. Cada una de estas tecnologías ha jugado un papel importante en el desarrollo del proyecto, permitiendo un desarrollo más eficiente y robusto. 2.4.1. Lenguajes Un lenguaje de programación es un sistema artificial que permite expresar algoritmos (Gabbrielli and Martini 2010). Hay distintos tipos de lenguajes de programación, algunos que propone (Ben-Ari, 1996) son los lenguajes orientados a objetos (C++, Python), funcionales (Haskell) y lógico (Prolog). Nosotras nos centraremos en Python, que es el lenguaje de programación de alto nivel y orientado a objetos utilizado para desarrollar el modelo y controlador del proyecto (sección 2.2). Asimismo, se ha utilizado las tecnologías web, como JavaScript que es un lenguaje de programación de alto nivel responsable de definir el comportamiento de la web. HTML y CSS son tecnologías que complementan a JavaScript para definir, presentar y procesar el contenido y diseño de la aplicación (Sinha et al. 2020), respectivamente. 2.4.2. Librerías Las librerías son conjuntos de archivos de código usados para el desarrollo del mismo, que facilitan la programación mediante funcionalidades comunes previamente resueltas. Permiten a los desarrolladores una mayor agilidad y reducción de costes en el proceso (Equipo de datos.gob.es). Dado que Python es un lenguaje ampliamente usado, podemos encontrar multitud de librerías para simplificar el código de programación. A continuación, explicaremos las librerías que hemos utilizado para el desarrollo de este proyecto. 29 1. Numpy. Es una librería de Python que proporciona un objeto de matriz multidimensional y gran variedad de funciones matemáticas con operaciones rápidas. (NumPy Developers) 2. Pandas. Es una librería que proporciona estructuras de datos y herramientas para el análisis de datos. (“pandas documentation — pandas 2.2.1 documentation”) 3. Sklearn. Es una librería de aprendizaje automático que proporciona herramientas de ajuste de modelos, preprocesamiento de datos, selección y evaluación de modelos, entre otras utilidades. (scikit-learn developers) 4. Scipy. Es una librería que proporciona algoritmos de optimización e integración para modelar y resolver problemas científicos. (Virtanen et al. 2020), (SciPy Steering Council). 2.4.3. Frameworks Los Frameworks son una técnica de reutilización orientada a objetos con el objetivo de facilitar el desarrollo y la implementación de una aplicación mediante la estructuración y normalización del código. (Johnson 1997) Con el uso de Frameworks podemos programar un código de manera más eficaz y robusta, ya que ofrecen una estructura que puede ser modificada por el programador según sus necesidades. (Martínez Villalobos et al. 2010) (Pantoja and Pardo 2016) Uno de los Frameworks más utilizados en la programación con Python es Django, es gratuito y de código abierto. Este marco de trabajo fue desarrollado entre 2003 y 2005, y proporciona un Framework de alto nivel muy útil para la implementación de aplicaciones web debido a su rápido y fácil desarrollo. Django utiliza el patrón de diseño MTV (Model-Template-View), que es una modificación del MVC anteriormente descrito, en el que separa los componentes de la aplicación en tres: 1. Modelo. Lógica de la aplicación. 36 Con estos bocetos se ha buscado definir de forma parcial todos los elementos necesarios para la implementación y son un reflejo de lo que queríamos implementar en el resultado final. En la figura 3.1 hemos diseñado la ventana de inicio de sesión en la que el usuario deberá introducir el correo electrónico o nombre de usuario y la contraseña (existe la posibilidad de hacer visible este campo). En el caso de no tener una cuenta en la aplicación, se da la opción de registrarse en la parte inferior del cuadro. Figura 3-1. Diseño de inicio de sesión En la Figura 3.2.1 podemos encontrar la ventana de crear cuenta (registro de usuario) en la que el usuario debe introducir el correo electrónico, nombre de usuario y contraseña (existe la posibilidad de hacer visible este campo). Una vez completados los campos anteriores, el usuario tendrá que marcar las casillas con las canciones que más se identifiquen con sus gustos para generar un perfil inicial. 37 Figura 3-2-1. Diseño de crear cuenta La Figura 3.2.2 es la continuación de la Figura 3.2.1, y como en el boceto anterior, el usuario deberá marcar las casillas de los artistas y géneros acordes a sus gustos y preferencias. Figura 3-2-2. Diseño de crear cuenta La Figura 3.3 muestra el boceto de la página principal de la aplicación web. En esta pantalla hay un encabezado con el icono para el perfil del usuario, una barra de búsqueda para encontrar canciones a partir de la que recomendar y el icono de la casa para volver a la página de inicio. 38 En la parte central de la ventana encontramos los elementos para acceder a las funcionalidades principales de la aplicación: recomendación diaria (muestra canciones basadas en los gustos de cada usuario) y recomendación personalizada (genera una playlist a partir del perfil de cada usuario). Además, en la parte inferior, se muestra una barra de reproducción de canciones. También, tenemos una barra lateral que contiene la lista de canciones favoritas y la lista de playlists del usuario. Figura 3-3. Diseño de inicio de la aplicación web En la Figura 3.4 vemos la ventana de “Mis favoritos” que muestra la lista con la información principal (nombre, artista y duración) de todas las canciones que le han gustado al usuario. Tenemos la posibilidad de reproducir la canción y quitarla de la lista. 39 Figura 3-4. Diseño de canciones favoritas En la Figura 3.5 vemos la ventana de “Mis playlists” que muestra la lista con la información principal (nombre y duración) de todas las playlists del usuario. Tenemos la posibilidad de reproducir la playlist y quitarla de la lista. 40 Figura 3-5. Diseño de playlist creadas En la Figura 3.6 encontramos la primera funcionalidad principal en la que muestra la lista de canciones de una playlist en concreto. Además, contamos con la opción de recomendar otra playlist a partir de las canciones de esta playlist. 41 Figura 3-6. Diseño de playlist seleccionada En la Figura 3.7 encontramos la segunda funcionalidad principal en la que va mostrando canciones en función al perfil del usuario para que éste vaya creando su playlist personalizada. Cada vez que se muestra una canción con su información principal, tenemos varias opciones para tratar esa canción: 1. Corazón. El corazón se encuentra lleno si la canción está en la lista de favoritos del usuario, en caso contrario, se encontraría vacío. 2. Cruz. Rechaza la canción actual y mostraría otra en función a los gustos del usuario. 42 Figura 3-7. Diseño de recomendación En la Figuras 3.8.1 y 3.8.2 encontramos la tercera funcionalidad principal no mostrada en la página principal en la cual el usuario elige una o varias canciones, artistas y géneros, a partir de los cuáles recomienda (esta funcionalidad no se basa en el perfil del usuario). 43 Figura 3-8-1. Diseño de recomendación personalizada Figura 3-8-2. Diseño de recomendación personalizada 44 3.4. Desarrollo del algoritmo de recomendación Durante el transcurso del trabajo hemos desarrollado diferentes recomendadores acorde con las iteraciones o Sprints de la metodología Scrum (secciones 3.1 y 2.3), mejorando y aprendiendo más acerca de su funcionamiento y aplicación. En total hemos realizado cuatro iteraciones para el recomendador que corresponden a las secciones 3.4.1, 3.4.2, 3.4.3 y 3.4.4, respectivamente. 3.4.1. Primera versión En la primera versión hemos realizado numerosas iteraciones (sección 3.1), en la que hemos desarrollado un primer recomendador que se desarrolló usamos el Framework (sección 2.4.3) de “Surprise” pero se usó mal ya que hicimos que recomendara por géneros parecidos y para ello pasamos los distintos géneros que había en el dataset (sección 3.2.1) a números enteros, lo cual fue un error porque los números cercanos no tenían por qué tener relación alguna entre estos. Pese a ello con esta primera iteración pudimos aprender el funcionamiento de las librerías de Surprise para hacer un sistema recomendador. Además, en esta primera iteración conseguimos pasar el dataset de Pandas a Surprise, lo cual nos será útil para iteraciones posteriores. El dataset empleado para esta iteración fue el que hemos detallado en la sección 3.2.1, con la excepción de que la columna de “Genres” no existía, fue agregada más tarde. En una segunda iteración estuvimos estudiando cómo trabajar con los datos en el recomendador, para ello nos decantamos por la función de similitud del coseno (figura 3.9) tras investigar los distintos tipos de medidas para la función de similitud (Hug 2015). Ésta en concreto consiste en una medida matemática que se utiliza para evaluar la similitud entre dos ítems, a menudo representadas como vectores. Estos vectores podrían denotar diversas características o atributos de los objetos, como es en el caso de las canciones, el género o la popularidad o la puntuación. La similitud del coseno nos va a permitir evaluar cuán similares son esos vectores entre sí. En la figura 3.9 se muestra la fórmula de la similitud del coseno, donde u y v representan dos ítems o dos usuarios y rui y rvi son los vectores que corresponden al género o popularidad de los ítems o las calificaciones dadas a un conjunto de ítems por los usuarios (Sondur, Chigadani, 45 and Nayak 2016). La similitud entre dos ítems puede variar entre 0 y 1, donde 1 representa la máxima similitud y se alcanza cuando ambos ítems son idénticos. (Mana and T.Sasipraba 2021). Figura 3-9. Función de similitud del coseno (Hug 2015) Además, configuramos la función de similitud de nuestro primer recomendador usando la métrica de coseno y el recomendador basado en contenidos (sección 2.1.1.2). En una tercera iteración usamos la técnica de Validación cruzada para comprobar cuán bueno era nuestro modelo en 7 iteraciones (establecido con cv=7). Esta técnica consiste en dividir el conjunto de datos en 7 subconjuntos de manera aleatoria, de los cuales se entrenan 6 y el restante es el encargado de validar con el resto (Berrar 2018). Y como resultado, se muestra la medida de errores de validación en cada iteración, que es nuestro caso, tal como se muestra en la Figura 3.10, fueron números altos lo cual indica que nuestro modelo no era demasiado bueno. Figura 3-10. Resultado de la validación cruzada. Finalmente, en una cuarta iteración para comprobar el correcto funcionamiento del algoritmo, creamos una playlist con 10 canciones de forma aleatoria. Se genera un resultado bueno si hay suficientes canciones del mismo género porque o sino recomienda por otros géneros que no tienen ninguna relación ya que hicimos mal la correlación entre distintos géneros, como hemos dicho al principio de esta sección. 52 Una vez ya teníamos las funcionalidades anteriormente mencionadas, realizamos la página principal. En ella, empezamos a añadir los componentes siguiendo el modelo de los prototipos: header, barra lateral y contenido principal. La construcción de la vista de la página principal se fue alternando con la implementación de las dos funcionalidades principales del proyecto: descubrir nuevas canciones y crear playlist. Cabe destacar que durante todo el proceso de desarrollo de la aplicación web se han ido realizando cambios de diseño y utilidad para hacer la página web más funcional y adaptada a los objetivos establecidos. 3.5.1. Back-End El back-End se encarga de la manipulación de datos y de manejar la lógica de negocio, las operaciones del lado del servidor y la comunicación con la base de datos. (Pérez Ibarra et al. 2021) (Ramón Sanchis 2023) Para iniciar el desarrollo hemos decidido apoyarnos en el Framework Django (ver 2.4.3) basado en Python (ver 2.4.1) por su rapidez, seguridad y facilidad de uso. Además, este Framework utiliza una arquitectura semejante al MVC (ver 2.2), estudiada y aplicada en una de las asignaturas del grado por lo que resulta familiar y sencilla de utilizar. En cuanto a la base de datos, hemos decidido cambiar SQLite, que se configura en Django por defecto, a una base de datos PostgreSQL (ver 2.4.4) debido a las limitaciones que suponía la anterior base de datos en cuanto a los tipos de datos soportados y el rendimiento ofrecido. Aunque el uso de nuestra base de datos es muy simple, es bueno que el sistema pueda gestionar la aplicación si se introdujeran cambios más potentes en ella o mayor cantidad de datos. La elección de la base de datos se afianzó conforme íbamos desarrollando las tablas debido a que, en un primer momento, no se tuvieron en cuenta todos los campos de cada una de las tablas y se tuvieron que cambiar para satisfacer las necesidades de la aplicación. 53 En la Figura 3.13 podemos observar el diagrama entidad-relación realizado con Canva muestra las distintas tablas y sus relaciones implementadas en la base de datos. Figura 3-13. Diagrama entidad-relación de la base de datos A continuación, vamos a realizar una explicación detallada de las tablas de nuestra base de datos: 54 3.5.1.1. Tabla “Cancion". La tabla “Cancion” contiene todas las canciones que van a ser usadas en nuestra aplicación. Todas las canciones contienen “id” que es la clave primaria y el resto de los atributos de las canciones fueron descritas en detalle anteriormente (ver 3.2.1) En las Figuras 3.14.1, 3.14.2 y 3.15 podemos ver un ejemplo de lo que contiene la tabla “Cancion”. Figura 3-14-1. Tabla “Cancion”. Parte 1 Figura 3-14-2. Tabla “Cancion”. Parte 2 55 Figura 3-15. Tabla “Cancion”. Parte 3 3.5.1.2. Tabla Rating. La tabla “Rating” contiene todas las valoraciones realizadas por los usuarios sobre las canciones (les ha gustado o no la canción). Todos los ratings contienen “id” que es la clave primaria y el resto de los atributos de los ratings fueron descritas en detalle anteriormente (ver 3.2.2) En la Figura 3.16 podemos ver un ejemplo de lo que contiene la tabla “Rating”. Figura 3-16. Tabla “Rating”. 3.5.1.3. Tabla Playlist. La tabla “Playlist” contiene todas las playlist de todos los usuarios de la página web. Todas las playlists contienen “playlistId” que es la clave primaria, “playlistName” (nombre de la playlist) y “listaCanciones” (lista de ids de las canciones que contiene esa playlist). En la Figura 3.17 podemos ver un ejemplo de lo que contiene la tabla “Playlist”. 56 Figura 3-17. Tabla “Playlist”. 3.5.1.4. Tabla Usuario. La tabla “Usuario” contiene la información de todos los usuarios registrados de la página web. Todos los usuarios contienen “userId” que es la clave primaria, “userName” (nombre de usuario único), “email” (correo electrónico del usuario que no se puede repetir para varias cuentas), “password” (contraseña de la cuenta), “favoritos” (lista de ids de las canciones que le han gustado al usuario) y “playlists” (lista de ids de las playlists que tiene cada usuario). No hemos hecho diferencia de roles en los usuarios porque al tratarse de una página web simple, la diferencia entre un administrador y un usuario común, no habría tenido mucha relevancia y no habría aportado ningún valor añadido. En la Figura 3.18 podemos ver un ejemplo de lo que contiene la tabla “Usuario”. Figura 3-18. Tabla “Usuario”. 3.5.2. Front-End El Front-End se refiere a la parte de una aplicación con la que interactúa el usuario, la que crea la experiencia. Aquí incluimos la interfaz gráfica y las funcionalidades de la página web. 57 Como hemos explicado anteriormente, antes de comenzar a codificar la página web, realizamos una serie de diseños con las funcionalidades principales. Con el transcurso del proyecto se han ido cambiando progresivamente para cubrir las necesidades incipientes y poder solventar los problemas que iban surgiendo a medida que avanzamos. Para realizar el Front-End de la aplicación nos hemos apoyado en HTML, CSS y JavaScript, con el apoyo de jQuery (ver 2.4.1). Las funcionalidades implementadas tratan de ser intuitivas para que el usuario no experimente confusión al usarla. También, se ha puesto el foco en hacer la página lo más simple posible y sin utilizar elementos que puedan distraer al usuario de su función principal. A continuación, describiremos las pantallas finales de la aplicación. 1. Inicio de sesión. En esta página el usuario iniciará sesión en su cuenta introduciendo su correo electrónico y su contraseña. En el caso de no tener cuenta en la aplicación, se da la opción de registro. Figura 3-19. Inicio de sesión 2. Registro. En esta página permite al usuario registrarse en la aplicación introduciendo su correo electrónico, nombre de usuario y contraseña. 58 Figura 3-20. Registro 3. Página principal. Esta página encontramos la cabecera con el icono de la casa, que sirve para volver a la página principal; y el icono de usuario, que lleva a la sección de “Mi perfil” con la información de usuario. En la barra lateral de la derecha encontramos dos clickables para acceder a la biblioteca de “Mis favoritos” y la de “Mis playlists”. También encontramos la lista de las playlists del usuario con sus nombres. En la parte central, encontramos dos cajas con las funcionalidades que ofrece nuestra página web: descubrir nuevas canciones y crear playlist. En la figura 3.21 podemos observar la página principal con un usuario que ha iniciado sesión, en este caso, el usuario “Leire”. 59 Figura 3-21. Página principal con usuario registrado. En el caso de que el usuario no haya iniciado sesión, los botones de las funcionalidades están desactivadas y en la parte en la que se mostrarían las playlists del usuario, indica que se debe iniciar sesión para poder visualizarlas. La vista la podemos encontrar en la Figura 3.22. Figura 3-22. Página principal con usuario no registrado. 4. Descubrir canciones. En esta primera funcionalidad el usuario obtendrá una lista de canciones recomendadas (canciones que el usuario no tiene en su lista de favoritos) a partir de unos atributos y canciones que le gustan al usuario. 60 El usuario tendrá la opción de marcar ninguno, uno o varios atributos (género, año, duración y popularidad) según la relevancia que le quiera dar a la hora de obtener una recomendación como refleja la Figura 3.23. Figura 3-23. Crear playlist: elección de atributos Una vez seleccionados los atributos, se mostrará una lista con veinte canciones aleatorias de la lista de favoritos del usuario como se puede ver en la Figura 3.24. En el caso de que al usuario en ese momento no le hayan gustado al menos veinte canciones, se mostrarán las canciones favoritas hasta el momento. También se puede dar que el usuario no haya añadido ninguna canción a favoritos, por lo tanto, se mostrarán veinte canciones populares. 61 Figura 3-24. Crear playlist: selección de canciones Tras realizar los pasos anteriores, se mostrará una lista de canciones y dará la opción al usuario de guardar la playlist en la biblioteca (ver Figura 3.25). 68 2. Cerrar sesión e iniciar sesión. 3. Usar la funcionalidad “Descubrir nuevas canciones” sin opciones. 4. Usar la funcionalidad “Descubrir nuevas canciones” seleccionando alguna opción. 5. Usar la funcionalidad “Crear playlist”. 6. Mirar “Mis playlists”, acceder a las canciones que tiene dicha playlist y comprobar que son las que se han añadido. 7. Mirar “Mis favoritos” y quitar una canción. 8. Ir a perfil y volver a la página principal. 9. Cerrar sesión. Las anotaciones realizadas por las moderadoras se centrarán sobre todo en aquellas tareas que hayan resultado más tediosas y, por tanto, serán las funcionalidades a mejorar con mayor prioridad. 4.2. Preparación del entorno de evaluación La prueba se realizará de forma presencial en el ordenador de una de las desarrolladoras, previamente todo preparado para el inicio de esta. Se realizará en un entorno tranquilo, en el que estarán presente las dos o una de las moderadoras junto con el participante para mayor tranquilidad. 4.3. Encontrar y seleccionar a los usuarios Para esta prueba hemos contactado con 6 participantes que usan aplicaciones para escuchar música como Spotify o Apple Music. Antes de realizar la prueba, hemos realizado una entrevista corta con cada uno de los participantes para comprobar si su perfil encaja con el buscado. En dicha prueba hemos realizado una serie de preguntas: 1. ¿Escuchas música con frecuencia? 2. ¿Utilizas plataformas o aplicaciones para descubrir nueva música? 69 3. ¿Cuándo escuchas música, te gusta que la aplicación te recomiende o prefieres elegir manualmente las canciones? 4.4. Preparación de los materiales para la evaluación Para asegurar el éxito de la prueba se ha realizado una preparación previa que va a consistir en: 1. Una introducción a la utilidad de aplicación, es decir, de qué trata nuestra aplicación. 2. Realizaremos una entrevista muy corta antes de las pruebas para reclutar a los participantes. 3. Se anotará el comportamiento de cada participante con la aplicación. 4. Una lista de tareas a realizar, descritas en la sección 4.1. 5. Y para finalizar con la prueba se distribuirá un cuestionario para calificar la sesión y la aplicación según lo observado durante la ejecución de las tareas. 4.5. Sesiones de evaluación Durante las sesiones de evaluación con cada usuario hemos seguido el plan de evaluación donde el usuario ha seguido las tareas descritas. Todo este proceso ha sido supervisado y guiado por moderadores, en este caso, las desarrolladoras del proyecto para conseguir mejores resultados. Hemos utilizado la técnica Think-aloud, estudiada en la asignatura de “Desarrollo de Sistemas Interactivos” (Francisco Gilmartín 2023) en la se pide a los participantes que expresen en voz alta lo que sienten o piensen en cada prueba. De esta manera, el moderador puede recoger toda esta información para su posterior análisis. En las tablas 4.1, 4.2, 4.3 y 4.4, se muestran las opiniones de los participantes de las sesiones de evaluación antes de realizar cambios. 70 Tarea Opinión 1 El proceso ha sido gratificante. 2 El proceso ha sido sencillo. 3 Pregunta si es aleatorio la lista de canciones a seleccionar. Dice que no es intuitivo porque no hay checkbox pese a los cambios de colores. Debajo del texto “Lista de canciones” debería haber información de que hay que hacer, si seleccionar o qué sucede a continuación. Debajo del texto de “Playlist recomendada” se necesita información de que son esas canciones recomendadas. Hay que destacar la canción de algún modo en el texto de la explicación de la recomendación y el color de las tarjetas de recomendación debería ser más destacable. Poner en explicabilidad en algunas opciones similares, mejorar la explicación de filtrado colaborativo. 4 Hay que explicar que hace las opciones, por ejemplo: “Las opciones seleccionadas se van a tener en cuenta en la recomendación”. Dejar el header fijo de lista de canciones y solo bajar las canciones. 5 Los botones con información, no se entienden. Quiere saber las canciones que va añadiendo. 6 Debería redireccionar las playlists laterales y no sólo en mis playlists. Separar corazón más de duración. 7 Si no tienes favoritos, que ponga un mensaje informando. 8 Centrar el botón de cerrar sesión. 9 No ha surgido ningún problema. Tabla 4-1. Usuario 1 (22 años) Tarea Opinión 1 Si el usuario se equivoca de contraseña, tiene que rellenar todo de nuevo. Debería permanecer el correo y usuario. 71 2 Le ha parecido fácil. 3 La explicación está mal escrita. Le ha gustado la funcionalidad. Los colores le parecen tristes. 4 Quiere un “refresh” para seleccionar nuevas canciones, y no sólo 20. 5 No entiende los símbolos de los botones, quiere información. No entiende el símbolo de la flecha azul. No le transmite confianza al crear playlist por el pop-up. 6 Sale alguna canción repetida, pero en general le parece bien. No le gusta que se abran las ventanas. 7 No se pueden añadir favoritos desde mis playlists. Quitar corazón de playlist si no es para añadir en favoritos. 8 No ha surgido ningún problema. 9 No ha surgido ningún problema. Extra En la página principal tiene que indicar que inicie sesión y no sólo inhabilitar los botones. Tabla 4-2. Usuario 2 (21 años) Tarea Opinión 1 Debería haber un botón de registrarse en la página principal, no solo iniciar sesión. 2 Debería dar la opción de iniciar sesión con el nombre de usuario. El icono de usuario ya que no permite foto debería ser más original. El fondo le parece deprimente. 3 Falta Información en lista de canciones, quiere saber si son esas canciones tipo populares o de tu playlist. Falta más canciones, necesita ver más. Más información en la tarjeta de canciones: autor, duración, género y año. Falta información en esta sección. Acortar la explicabilidad: porque te ha gustado 72 tal y a otros usuarios similares. Al final, en la playlist recomendada, se necesita información como: creemos que estas canciones te gustarán. 4 Lo mismo que en la tarea 3. Cambiar la explicación a un lenguaje más humano. 5 Explicar los botones y añadir un botón que ponga terminar en lugar de la flecha negra. Cambiar el botón de refrescar, no se entiende. El texto de la explicación en rojo parece un error. La ventana de confirmación de crear playlist debería ser igual que el resto en formato. 6 Ir a playlist sin darle a la flecha (darle a la tarjeta de la playlist) La flecha es muy pequeña y no resalta cuando pasa por encima. 7 Más grandes los botones de corazón y separados. 8 Le ha parecido bien. 9 Le ha parecido bien. Extra En la página principal poner un botón de inicio en la barra lateral, arriba de “Mis favoritos” para ir al inicio de la aplicación. Tabla 4-3. Usuario 3 (22 años) Tarea Opinión 1 Se siente cómodo e incluido. 2 Le ha parecido muy simple y bien. 3 Los colores le parecen tristes, además de mucho espacio desaprovechado. Le falta información arriba de que tienes que hacer en cada paso. 4 Le falta información para los atributos a seleccionar. 5 No le parece que sea intuitivo los botones. Poco feedback visual. 73 6 Le parece bien, el corazón no tiene sentido en las playlists. 7 Le ha parecido bien. 8 Le ha parecido bien. 9 Le ha parecido bien. Tabla 4-4. Usuario 4 (21 años) En la tabla 4.5, se muestran los resultados de la sesión de evaluación una vez realizado algunos de los cambios acorde con las críticas constructivas de los anteriores participantes. Los cambios realizados sobre la aplicación fueron: 1. Colocación de un botón para registrarse en la página principal sin necesidad de meterse en “Iniciar sesión”. 2. Explicación de las diferentes partes de las funcionalidades. 3. Añadir información de los botones en la funcionalidad “Crear playlist”. 4. Cambio de botón de repetición en "Crear playlist". Tarea Opinión 1 Opina que el botón de registrarse debería estar al lado o arriba y los cuadrados cree que más grandes y el espacio más amplio. El color marrón no le gusta. El botón de atrás está mal. 2 Opina que debería haber un botón de atrás, pero le resulta bien el resto. 3 Le gustaría buscar canciones en lugar de seleccionar unas canciones que aparecen predeterminadas. 4 Le falta canciones para seleccionar aparte de las que te gustan. 5 Le parecen poco intuitivos los botones, sobre todo de siguiente y terminar playlists. Para él, el botón de siguientes sería más una cruz y el de terminar playlists sería más un botón de guardar. 74 6 Le parece muy bien, sólo el color de la interfaz le falla. 7 Le parece bien, funciona perfectamente. 8 Le parece intuitivo pero el icono le gustaría más grande. 9 Le parece bien. Tabla 4-5. Usuario 5 (22 años) Además de esta evaluación con un quinto usuario, realizamos una sesión de evaluación más reducida en la que obtuvimos un feedback acerca de las funcionalidades principales de la aplicación que consistía principalmente en añadir una opción de filtro para conseguir una recomendación más personalizada. Además de que debía tener la página una mejor consistencia al mostrar una lista de canciones. 4.6. Debriefing con los participantes y los observadores Tras las sesiones de evaluación realizamos un pequeño resumen (debriefing) de las impresiones del usuario para completar la información recogida en el transcurso de la entrevista. Después del debriefing compartiremos con todos los participantes un cuestionario en el que tendrán que expresar su grado de conformidad con las expresiones propuestas. El cuestionario tendrá preguntas generales, de la funcionalidad del sistema y de evaluación de la interfaz, y de manera opcional el usuario podrá dar su opinión de manera abierta sobre las partes que le han parecido más interesantes y las que menos. Los resultados del cuestionario se ven reflejados en el gráfico de las figuras 4.1, 4.2 y 4.3. 75 Figura 4-1. Resultados del cuestionario. Satisfacción general. En esta sección se realizan preguntas acerca de aspectos generales de la aplicación. Las preguntas son: 1. En general, estoy satisfecho/a con la facilidad para utilizar el sistema. 2. Pude completar las tareas rápidamente. 3. Me sentí cómodo/a usando el sistema. 4. Necesitas saber bastantes cosas antes de poder empezar a usar la aplicación. 5. Considero que las funciones de la aplicación están bien integradas. 76 Figura 4-2. Resultados del cuestionario. Evaluación de la aplicación. En esta sección se realizan preguntas acerca de las funcionalidades del sistema y del sistema de recomendación. Las preguntas son: 1. Me resulta útil la funcionalidad "Descubre nuevas canciones". 2. Me resulta útil la funcionalidad "Crear playlist". 3. Me resulta intuitiva la forma de acceder a "Mis favoritos". 4. Me resulta intuitiva la forma de acceder a "Mis playlists". 5. Me resulta fácil de usar "Descubre nuevas canciones". 6. Me resulta fácil de usar "Crear playlist". 7. Me resulta útil la información que muestra "Mi perfil". 8. Me resulta útil la información acerca de la recomendación. 9. Estoy de acuerdo con la recomendación dada según los criterios seleccionados. 77 Figura 4-3. Resultados del cuestionario. Evaluación de la interfaz. En esta sección se realizan preguntas acerca de la apariencia estética de la interfaz. Las preguntas son: 1. La forma de la interfaz me resulta agradable. 2. Me resulta fácil navegar por la interfaz. 3. Considero que los colores y el diseño son bonitos. 4. Considero que los colores permiten una buena visibilidad de la interfaz. 4.7. Análisis de los datos y las observaciones. Una vez tenemos toda la información de las sesiones de evaluación y los cuestionarios completados pasamos a analizarlos con el fin de añadir todas las observaciones y resultados de los datos. Respecto a las primeras sesiones de evaluación (sección 4.5) hemos observado que los usuarios han encontrado los siguientes problemas: 84 received is not accurate or simply does not offer us the necessary information we are looking for. An example could be when we search in Google, the recommenders act in such a way that they show the user the most relevant results according to their profile, discarding those that are not outstanding at that time. We have seen that recommenders are used for many areas, but in this work we focus on a specific recommendation domain: music, which is present in many areas of life and it is digital platforms such as Spotify, Amazon Music or YouTube that offer us most of this content. On many occasions we have found that we always receive the same type of information, and taking it to the musical field, when interacting with the system (for example, YouTube) we are shown the same songs without giving us the opportunity to know many others that are probably to our liking. Goals To develop this project, we have proposed a series of objectives and tasks in order to progressively implement a recommendation system based on the data offered by Spotify, and to develop the application as a support to show the operation of our recommender with the different functionalities for the final user. We have chosen to collect the information from Spotify because it is one of the largest music platforms that exist and has millions of songs (Spotify AB 2024), which can be useful for us to try to achieve maximum completeness of our recommendation algorithm. In addition, it has the content recommendation functionality, which serves as a reference for our work. These objectives and tasks are: 1. Objective 1. Understand technologies and similar work to help define the functionality of the system. a. Task 1.1. Reading of similar projects. b. Task 1.2. Search for datasets or platforms that publish their data. 85 c. Task 1.3. Design of the software architecture: study suitable patterns for the application. 2. Objective 2. Develop a recommendation algorithm. a. Task 2.1. Study the types of recommenders to determine the one that best suits the detected needs. b. Task 2.2. Study existing frameworks and determine if they are applicable in our design. c. Task 2.3. Understand the data provided by the dataset. d. Task 2.4. Implement a simple recommender and test it in a prototype with little data to check its operation. e. Task 2.5. Test different types of recommenders in a prototype with little data. f. Task 2.6. Scale the recommender to large data and/or connection with real-time data. g. Task 2.7. Verify that the data to be used and the recommender work correctly. 3. Objective 3. Develop a user web interface. a. Task 3.1. Design the interface prototypes. b. Task 3.2. Develop the web interface. c. Task 3.3. Implement the interface logic. d. Task 3.4. Perform usability tests to verify its correct operation. 4. Objective 4. Complete system working. a. Task 4.1. Integrate the parts: Recommender - Interface. b. Task 4.2. Resolve the integration between the parts. 5. Objective 5. Experiment with real users to validate the proposed design. a. Task 5.1. Create test users to test the operation. b. Task 5.2. Integrate potential users of the application into the system. 6. Objective 6. Write and review the memory. a. Task 6.1. Sequential development of the memory. b. Task 6.2. Review of the completeness and cohesion of the memory. 86 Work plan To establish the work plan, we have considered the research, development, and delivery times for each part of our project. Throughout the process, we have followed an agile development based on the Scrum methodology (see section 2.3) with small deliveries in short periods of time (generally, two weeks), adapting the needs that may arise to these time objectives. We have also held regular meetings to review progress, quality, and share the work to be done in the future. To track this entire process, we have used the Excel tool with the different tasks to be performed in the sprints and the delivery times. Research was the first task carried out, in order to familiarize ourselves with the concepts and know the different tools available for the subsequent implementation of our project. This research has been carried out throughout the project development process in order to improve the consistency and performance of the work. After carrying out the research phase and acquiring the necessary knowledge, we have continued with the development phase. In this phase, we have implemented the recommendation algorithm and the web application, and it has served us to put into practice everything studied previously. During the evolution of the work, we have alternated the two previously mentioned phases, research and development, with the task of writing the project documentation. We have also been correcting the errors or changes that have occurred during the same so that the information presented here is updated and in accordance with the work carried out. 87 Conclusions and future work “Conclusiones y trabajo futuro” section translated to English. Conclusions In this work, an application with a personalized hybrid recommendation system has been developed with the objectives outlined in section 1.2: 1. Objective 1: Understand technologies and similar work to help define the functionality of the system. 2. Objective 2: Develop a recommendation algorithm. 3. Objective 3: Develop a user web interface. 4. Objective 4: Complete system working. 5. Objective 5: Experiment with real users to validate the proposed design. 6. Objective 6: Write and review the memory. Although most of the objectives have been met, there have been some complications with some of them. The complications have been mainly in the development of the recommendation system in which, although frameworks have been studied, they have not been applied, since we have chosen to implement it without them, which has allowed us to better understand the operation of recommendation systems. Another problem encountered has been the datasets, since a complete one could not be found, so it had to be modified, as commented in section 3.2, since a column with the list of various genres of the song was missing. Another point that could not be fulfilled has been the use of very large data due to lack of time, as well as the use of real-time data such as the Spotify API, which is detailed later in section 5.2. In the development of the interface, there have been setbacks with the database, having to have been changed several times until the final one, which is indicated in section 2.4.4. And it has also not been possible to upload to an online server to be publicly tested, more detailed in section 5.2. 88 The rest of the objectives and tasks have been carried out correctly and without problems, which has allowed us to learn a lot about recommendation systems, web applications and ways to integrate them, such as with MVC models. It should be noted that during the first months of project development, the tasks were mainly based on research and testing, especially the recommender part. In the following months, the developed recommender was improved, as can be seen in section 3.4, and the web application could be developed with a much more visual and interactive interface (section 3.5). Future Work Although the work meets the objectives set out (section 1.2), the project admits improvements to be developed in the future that would provide it with additional value. The following are the improvement proposals: 1. Use of libraries like "Surprise" for the recommender. It would be interesting that, once the operation of a recommendation algorithm is known, it would be possible to introduce already implemented tools and algorithms to improve the performance of the recommender. 2. Use of the Spotify API. The use of a dataset limits the information with which you can operate. It would be convenient to be able to connect our application with the Spotify API since we would have millions of songs and the service offered would be much more complete and up-to-date. 3. Deploy the application in a public environment. Due to lack of time, we have not been able to upload the application to a production environment so that users can use the web on their own devices. End users should have accessibility to our application, and this would be a fundamental task to carry out in the future. 4. Add new features and improve the interface. 89 The use of the application only on web platforms greatly limits the usefulness of the application. To allow users to enjoy the recommendations, the web could be adapted for use on mobile devices. As for the functionalities, a search bar can be added so that the user can directly search for the name of the song or the artist from which they want recommendations. As well as the possibility of playing the songs in the application itself. Also, it would be important to improve the user interface and make it more adaptive to adapt it to different devices. In conclusion, all the objectives that were proposed at the beginning of the project have been met (section 1.2) and we have been able to learn about the internal workings of recommendation systems (section 2.1), the different types (section 2.1.1) and some of the problems that arise in these systems (sections 2.1.2 and 2.1.3) and despite having developed an algorithm without libraries, it has proven efficient and reliable. In addition, we have been able to apply the knowledge acquired throughout the career on user interfaces (section 3.3), web applications (section 3.5) and apply software methodologies and design patterns for the development of a project (sections 2.2 and 2.3). And according to the results obtained in the user testing phase (section 4.7), it has been confirmed that the objectives have been met despite some detected failures (section 4.5). 90 CONTRIBUCIONES PERSONALES En este capítulo se explicará en detalle el trabajo realizado por cada uno de los miembros durante el desarrollo del proyecto. Estas tareas se han realizado tanto de forma individual como en grupo para conseguir el objetivo propuesto. Leire Jiménez González. Al inicio de este TFG, he estudiado la viabilidad del proyecto junto a mi compañera, buscando información sobre sistemas de recomendación, definiendo los objetivos del proyecto, investigando las diferentes herramientas disponibles para usar y aportando ideas de diseño e implementación para el posterior desarrollo. Una vez comprobada la viabilidad del proyecto, resultando positivo, diseñamos en grupo un boceto de la interfaz de la aplicación mediante la herramienta Figma. Durante este proceso de diseño, aporté ideas de estilo y diseño general, así como definir el logo. Al contar con dos módulos de implementación en el proyecto (ver secciones 3.4 y 3.5), me he centrado en el desarrollo de la aplicación. Me he apoyado en el Framework Django para realizar la aplicación porque consideré que era la opción más sencilla para la posterior integración del algoritmo de recomendación programado en Python realizado por mi compañera. A continuación, enumeraré las aportaciones individuales dentro de la parte de implementación de la aplicación: 1. Creación de un proyecto Django y modificación de ficheros para adaptarlos a nuestras necesidades. 2. Importación de librerías y módulos necesarios para el funcionamiento del proyecto. 3. Definir la base de datos en SQLite y posterior cambio a PostgreSQL. Así como, crear las tablas en el fichero models.py, introducir la información necesaria y comprobar su correcto funcionamiento. 4. Desarrollo de la aplicación mediante HTML, CSS, JavaScript y Python. 91 5. Creación de dos módulos dentro del proyecto: “paginaPrincipal” y “usuarios”, para diferenciar entre las vistas generales y las de usuario. 6. Implementación de las funcionalidades de “Descubrir canciones” y “Crear Playlist”. 7. Implementación de las funcionalidades básicas de la aplicación en el módulo “usuarios”: inicio de sesión, registro y perfil de usuario siguiendo los bocetos propuestos. 8. Implementación de funcionalidades concretas para nuestro proyecto en el módulo “paginaPrincipal”: “Mis playlists” y “Mis favoritos”. 9. Realizar la conexión con la base de datos para recoger los datos necesarios en las funcionalidades que lo requerían. Esto lo he realizado en el fichero views.py del módulo correspondiente. 10. Integración del algoritmo de recomendación con la aplicación. 11. Comprobación unitaria del funcionamiento de las diferentes funcionalidades. En cuanto a la evaluación de usuarios, en colaboración con mi compañera preparé el plan de evaluación y participé en las diferentes sesiones de evaluación guiando a los participantes durante todo el proceso y analizando los datos posteriormente recabados durante las entrevistas y los cuestionarios. Con respecto a la memoria, he contribuido a la redacción de diferentes secciones: el Capítulo 1, donde se realiza una introducción sobre nuestro proyecto, junto a la motivación, objetivos propuestos y plan de trabajo; el Capítulo 2, donde expliqué la arquitectura software, la metodología y las tecnologías usadas; el Capítulo 3, realicé la explicación del diseño de la interfaz de usuario y el desarrollo de la aplicación; el Capítulo 4, donde desarrollé parte de la explicación de la evaluación con usuarios; y el Capítulo 5, donde se detallan las conclusiones y trabajo futuro. Laura Martínez Tomás. A lo largo del desarrollo del TFG he contribuido a diferentes partes del proyecto. Lo primero a lo que contribuí fue en el boceto inicial del diseño de la interfaz mediante la herramienta de Figma. 92 Respecto a la parte de la implementación del proyecto (ver secciones 3.4 y 3.5), he desarrollado el algoritmo para un sistema de recomendación híbrido (sección 3.4.4), tras haber realizado distintas versiones. Para poder implementar bien esta parte he investigado acerca de los distintos recomendadores, finalmente decantándome por un modelo híbrido que combina las ventajas de los sistemas de recomendación basado en contenido (sección 2.1.1.2) y de filtrado colaborativo (sección 2.1.1.1). Este algoritmo lo desarrollé en Python sin ningún uso de librerías hechas para implementar sistemas de recomendación como Surprise. Además, para poder ver el funcionamiento del algoritmo necesitaba un conjunto de datos o dataset, que tras una larga búsqueda encontré uno, que luego tuve que modificar con un algoritmo que yo misma creé en C++ para añadir una columna de la lista de géneros aleatorios para cada canción. Asimismo, tuve que reducir el dataset con otro algoritmo para dejarlo en 10000 canciones, ya que el original contenía un millón de canciones y no me permitía observar bien el funcionamiento del recomendador. Cuando tuvimos una versión funcional tanto para recomendador como página planteamos una evaluación de usuarios que junto con mi compañera preparé el plan de evaluación y participé en las diferentes sesiones de evaluación tomando notas acerca de los comentarios y comportamientos de los participantes durante todo el proceso y analizando los datos posteriormente tanto de las cuestiones como de las sesiones de evaluación y realicé la conclusión acerca de los fallos más comunes. Con respecto a la memoria, he contribuido a la redacción de diferentes secciones: el Capítulo 1, parte de la introducción sobre nuestro proyecto junto a parte de la motivación y he contribuido al desarrollo del plan de trabajo; el Capítulo 2, donde introduje el capítulo y expliqué toda la sección de los fundamentos de los sistemas de recomendación, además de los lenguajes en la sección de tecnologías. En el Capítulo 3 realicé la explicación de la metodología, la descripción de los conjuntos de datos y la descripción de mi parte de la implementación, el desarrollo del algoritmo de recomendación. En el Capítulo 4 desarrollé junto a mi compañera la preparación del plan de evaluación y luego describí los siguientes cuatro apartados. Como mi rol en las sesiones de evaluación era recolectar la información de los participantes, lo escribí en 93 las tablas. Y finalmente, en el Capítulo 4, realicé el análisis de los datos y el informe de hallazgos. En el Capítulo 5, detallé las conclusiones. 100 https://ruc.udc.es/dspace/bitstream/handle/2183/26156/D.Touri%c3%b1o_Calvo_2020_ Recomendacion_de_canciones_y_listas_de_reproduccion_sobre_Spotify.pdf?sequenc e=3&isAllowed=y Trigas Gallego, M. (2012). Metodología Scrum [Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles]. Vidal-Silva, C. L., Sánchez-Ortiz, A., Serrano, J., & Rubio, J. M. (2021). Experiencia académica en desarrollo rápido de sistemas de información web con Python y Django. Formación universitaria, 14(5). 10.4067/S0718-50062021000500085 Virtanen, P., Gommers, R., Oliphant, T. E., Haberland, M., Reddy, T., Cournapeau, D., Burovski, E., Peterson, P., Weckesser, W., Bright, J., van der Walt, S. J., Brett, M., Wilson, J., Millman, K. J., Mayorov, N., Nelson, A. R.J., Jones, E., Kern, R., Larson, E., … SciPy 1.0 Contributors. (2020). SciPy 1.0: fundamental algorithms for scientific computing in Python. Nature Methods, 17, 261-272. https://doi.org/10.1038/s41592-019-0686-2 Voorhees, D. P. (2020). Guide to Efficient Software Design: An MVC Approach to Concepts, Structures, and Models. Springer International Publishing. Zhang, Y., & Chen, X. (2020). Explainable Recommendation: A Survey and New Perspectives. Foundations and Trends® in Information Retrieval, 14(1), 1-101. 10.1561/1500000066 Zumba Gamboa, J. P., & León Arreaga, C. A. (2018). Evolución de las Metodologías y Modelos utilizados en el Desarrollo de Software. INNOVA Research Journal, 3(10), 20-33. ISSN 2477-90