Trabajos Fin de Grado en Ingeniería Informática

Este Trabajo Fin de Grado (TFG) propone el diseño y desarrollo de una aplicación web para gestionar la documentación textual (parte estructurada creada por el estudiante y parte en texto libre) sobre cursos de formación permanente o reglados (oficiales) en el área de la informática.

Los posibles usuarios pueden navegar directamente por las páginas web del repositorio creado, pero además pueden utilizar el sistema de búsqueda.

DESCRIPCIÓN DEL SISTEMA

La aplicación debe mantener información sobre:

• El catálogo de cursos: contiene la información de cada uno de los cursos ofertados y almacenados en un repositorio. Los cursos se imparten en semestres y/o cuatrimestres y un grupo de ellos configura una titulación. Para obtener el título correspondiente es necesario cursar un número de créditos mínimo o un número de cursos determinado. En los cursos no reglados, la formación es mas abierta y el estudiante que finaliza un curso obtiene automáticamente un diploma de estudios avanzados en ese curso.
• De cada curso en el catálogo tenemos información al menos:
  • Identificador
  • Tipo (reglado (pertenece a uno o varios títulos), abierto) (puede ser ambos)
  • Título
  • Director(es/as)
  • Profesor(es/as)
  • Impartición (distancia, presencial, híbrido) (no puede ser mas de uno)
  • Descripción textual (texto libre)
  • Temática (s) (Puede tener varias)
  • Número de créditos
  • Semestre/cuatrimestre (1º/2º)
  • Link de la página en la que aparece su descripción
  • Identificador/es del/ de los títulos en los que aparece ofertado el curso
• Usuario: se registran en el sistema por propia iniciativa o en otro caso solo podrán visitar las páginas con información. De cada miembro se debe almacenar al menos la siguiente información:
  • cuenta de correo electrónico
  • nombre y apellidos
  • palabras clave de su titulación superior (si la tienen, al menos dos palabras clave) (pueden tener varias titulaciones)
  • población y código postal
  • clave acceso

El sistema informático que se pretende implementar debe realizar las siguientes funcionalidades:

1. Incorporación de un nuevo curso al catálogo. Cuando se incluye un nuevo curso se genera un registro con los datos correspondientes, proporcionando un identificador al mismo. Los campos de un curso concreto se podrán actualizar.
2. Cuando un usuario solicita registrarse, se almacenan sus datos. El usuario podrá actualizar sus datos personales accediendo en la plataforma a su perfil.
3. El sistema debe permitir a los socios consultas online al sistema de búsqueda. Estas consultas podrán realizarse en texto libre o en alguna de las siguientes modalidades:
   • Por temática. Todos los cursos se muestran por temas.
   • Por tipo de contenido. Dentro de cada tipo se podrán ver por temas.
   • Por posible afinidad con los gustos del usuario para una consulta en texto libre. Esto es una recomendación. Un sistema de recomendación es un tipo específico de filtro que, en este caso, trata de presentar a un usuario cursos o títulos relacionados con la temática de su pregunta o de su titulación.
   • Además, se podrán realizar búsquedas por título, director, profesor, semestre o número de créditos.
4. Debe ser posible obtener estadísticas (número de visualizaciones por usuario, temas más demandados, etc.).

El sistema tiene dos perfiles de usuario, que operan del siguiente modo:

• Socios: acceden a través de la web con un código de usuario (su correo electrónico), y su clave. Podrán hacer consultas, actualizar sus datos y visualizar los resultados.
• Personal de gestión del sistema: acceden al sistema a través de la web. Pueden dar de alta o baja a los usuarios y modificaciones de todo tipo, así como configurar, reinstalar el sistema y realizar copias de seguridad.

Justifique la tecnología que utilizará para realizar el sistema y almacenar la información en el repositorio.

El repositorio para la web del sistema contendrá las “fichas de los cursos” seleccionados por el estudiante, pero únicamente de las fuentes del curso 2022-23 de los estudios de la ETSI Informática de la UNED (https://www.uned.es/universidad/facultades/informatica/bienvenida/estudios.html) secciones Másteres y Formación Permanente.

El objetivo final, es realizar el sistema de búsqueda y la web asociada. El estudiante tiene que decidir 30 asignaturas de máster y/o formación permanente, de forma que haya al menos una titulación ofertada. El sistema tendrá información de 5 usuarios al menos, desde el inicio. Además, debe pensar 20 preguntas a su sistema y las respuestas correctas deben ser conocidas, esto es, preparadas manualmente por el estudiante. Finalizado el desarrollo y la ejecución de las preguntas, el estudiante construirá una tabla con cada pregunta y sus respuestas en las dos formas (con su sistema y la conocida previamente) y aportará al menos cinco conclusiones.

Se deja a criterio del estudiante y su director/ra el diseño y desarrollo. Aunque la tecnología utilizada para implementar el proyecto queda a elección del estudiante, la visualización e interacción con los contenidos debe ser adecuada y adaptada al dispositivo desde el que se visualiza.

PLAN DE TRABAJO

1. 1. Planificación

      El estudiante deberá realizar un plan con un calendario realista y especificará claramente las tareas y el cronograma para realizarlas, concretando los aspectos que quedan abiertos en este documento de descripción. Este anteproyecto será revisado y aprobado por su director

   2. Desarrollo

      A continuación, el estudiante deberá desarrollar el proyecto siguiendo todas las fases del ciclo de desarrollo de software, e implementar un prototipo de la solución aportada. La documentación deberá recoger el diseño técnico, especificando la arquitectura general del sistema, la estructuración en módulos o paquetes, la descripción técnica de cada módulo del sistema, la descripción de los interfaces entre los módulos y módulos externos (si los hay), las estructuras de datos fundamentales y los desarrollos algorítmicos que se hayan utilizado de terceros o programado personalmente. Asimismo, hay que presentar un plan de pruebas y factores que permitan definir y valorar la calidad de la solución aportada. Se valorará la escalabilidad del producto final así como la modularidad y extensibilidad del desarrollo a otros problemas similares.

   3. Memoria

      La versión final de la memoria se realizará teniendo en cuenta los documentos indicados en el epígrafe anterior (Desarrollo), así como los resultados obtenidos y las conclusiones extraídas de los mismos. Asimismo, la memoria deberá contener como Anexos el manual de instalación y el manual de usuario conteniendo alguna pantalla impresa de las pruebas realizadas.

   4. Presentación y defensa pública del proyecto realizado

      La valoración del TFG dependerá tanto de cómo se ha realizado y documentado todo el proceso del desarrollo del proyecto, el producto software final y la calidad de la presentación realizada en su defensa pública.

Se propone para este curso la realización de un portal de wikis que permita la edición de artículos similar a la Wikipedia.

 El objetivo es ofrecer soporte a la creación de un portal donde, por un lado, haya un almacenamiento de los artículos y contenidos multimedia asociados a un descriptor, y por otro una jerarquía de colaboradores, editores y gestores que supervisen la actividad.

DESCRIPCIÓN DEL SISTEMA

Cada página de la wiki se visualiza en HTML pero está confeccionada en un lenguaje específico denominado WikiText. La especificación está disponible en https://en.wikipedia.org/wiki/Help:Wikitext

 La propuesta de TFG debe incorporar un subconjunto del lenguaje existente en la Wikipedia de manera que los contenidos incorporen texto, imágenes y vídeos. El gestor proporcionará un parser del lenguaje que genere su equivalente HTML.

Gestión de usuarios

La aplicación debe admitir los siguientes tipos de usuarios registrados: gestor, supervisor y colaborador.

1.  Un gestor es un usuario con privilegios sobre las wikis del sistema: creación, modificación, borrado, etc., y sobre la asignación de roles a usuarios de cada wiki. Asigna supervisores a la wiki o a artículos determinados dentro de cada wiki.
2. Un coordinador de wiki es un usuario con capacidad de dar de alta artículos y de borrarlos, así como de asignar supervisores. No puede borrar wikis asignadas.
3. Un supervisor tiene una lista de wikis disponibles y , dentro de ellas, los artículos asignados con privilegios de edición sobre todos ellos. Dispone también de derecho de veto sobre los colaboradores que acceden a los artículos que supervisa. El supervisor no puede borrar artículos.
4. Un colaborador es un usuario registrado que puede realizar modificaciones en los artículos de una wiki.

Al contrario que en la Wikipedia, no se permite la edición anónima. Tampoco hay un lenguaje de edición, por lo que los artículos estarán editados en HTML directamente. Los colaboradores se pueden proponer para gestores y el gestor acepta o rechaza la solicitud.

Vista de cada rol

Cada rol dispone de una vista que le permita realizar su función.

•  El gestor dispone de una vista de las wikis con funciones de gestión de estas. Dentro de cada una de ellas dispone de las funciones de:
  • Gestión de usuarios: altas, bajas, asignación de artículos a cada uno de ellos, listado de auto-propuestos  para supervisor, etc.
  • Gestión de wikis: creación y borrado
• Un coordinador tiene una vista similar al gestor. Puede crear artículos pero sin gestión de usuarios ni capacidad de borrado o creación de wikis.
• El supervisor tiene una vista donde dispone de la misma vista que el coordinador, pero sin acceso a la gestión de usuarios ni de las capacidades de gestión sobre los artículos. Sí dispone de la lista de artículos asignados para supervisión y de la lista de solicitudes de modificación
• El colaborador dispone de una lista de los artículos donde ha realizado modificaciones y el resultado de estas (aceptado, rechazado, en evaluación).

Cualquier usuario tiene capacidad de solicitar ser asignado a otro rol. Estas solicitudes las acepta o las rechaza el gestor.

Gestión de modificaciones

El mecanismo de realización de modificaciones se ha simplificado con respecto a la Wikipedia. La modificación de un artículo se efectúa de la siguiente manera:

• Se permite al usuario descargar el fichero WikiText correspondiente a un artículo.
• El usuario lo modifica en local.
• Se permite al usuario subir el fichero como propuesta. Esto dispara un aviso al supervisor.
• El supervisor encuentra un nuevo ítem en su lista de revisiones pendientes. El supervisor dispondrá de una vista con las diferencias entre los dos ficheros con la posibilidad de aceptar o rechazar cada uno de los cambios.
• El usuario encontrará su propuesta bien en la lista de aceptadas, o en la de rechazadas.

Casos de uso

Consideremos el portal en funcionamiento, con actividad, contenido y diversos roles y usuarios ya activos. A modo de ejemplo, se proponen los siguientes casos de uso: 

1. Un usuario anónimo accede a la wiki y consulta una entrada. El usuario lee el artículo y al final de este encuentra un enlace a registrarse para hacer modificaciones. Se da de alta y a continuación al consultar el mismo artículo le aparece activa la manera de realizar modificaciones. Realiza una modificación y espera la supervisión de este.
2. Un gestor crea una wiki sobre una temática nueva. En el portal aparece listada. Diversos colaboradores proponen ser supervisores o coordinadores.
3. Un coordinador crea un artículo nuevo en una wiki asignada. Gestiona el alta de varios supervisores de artículos.

PLAN DE TRABAJO

1. 1. Planificación

      El estudiante deberá realizar un plan con un calendario realista y especificará claramente las tareas y el cronograma para realizarlas, concretando los aspectos que quedan abiertos en este documento de descripción. Este anteproyecto será revisado y aprobado por su director

   2. Desarrollo

      A continuación, el estudiante deberá desarrollar el proyecto siguiendo todas las fases del ciclo de desarrollo de software, e implementar un prototipo de la solución aportada. La documentación deberá recoger el diseño técnico, especificando la arquitectura general del sistema, la estructuración en módulos o paquetes, la descripción técnica de cada módulo del sistema, la descripción de los interfaces entre los módulos y módulos externos (si los hay), las estructuras de datos fundamentales y los desarrollos algorítmicos que se hayan utilizado de terceros o programado personalmente. Asimismo, hay que presentar un plan de pruebas y factores que permitan definir y valorar la calidad de la solución aportada. Se valorará la escalabilidad del producto final así como la modularidad y extensibilidad del desarrollo a otros problemas similares.

   3. Memoria

      La versión final de la memoria se realizará teniendo en cuenta los documentos indicados en el epígrafe anterior (Desarrollo), así como los resultados obtenidos y las conclusiones extraídas de los mismos. Asimismo, la memoria deberá contener como Anexos el manual de instalación y el manual de usuario conteniendo alguna pantalla impresa de las pruebas realizadas.

   4. Presentación y defensa pública del proyecto realizado

      La valoración del TFG dependerá tanto de cómo se ha realizado y documentado todo el proceso del desarrollo del proyecto, el producto software final y la calidad de la presentación realizada en su defensa pública.

Se deja a criterio del estudiante y su director/ra el diseño y desarrollo. Aunque la tecnología utilizada para implementar el proyecto queda a elección del estudiante, que hay que justificar en la memoria del trabajo, la visualización e interacción con los contenidos debe ser adecuada y adaptada al dispositivo desde el que se visualizará.

Directora: Covadonga Rodrigo (covadonga@lsi.uned.es)

Objetivo: El objetivo de este proyecto es la creación de una actividad de aprendizaje adaptativo basada en la generación de un flujo de preguntas al estudiante de forma interactiva a través de Telegram.

Descripción: El aprendizaje adaptativo (adaptive learning) es un método que individualiza las estrategias de enseñanza-aprendizaje según las necesidades y preferencias del alumno. Tiene particular aplicación en la educación mixta y en línea, desarrollada con el apoyo de entornos virtuales de aprendizaje. Se pretende diseñar y testar una actividad específica de auto-evaluación guiada que contenga preguntas realizadas por profesores y también generadas de forma automatizada mediante ChatGPT.

Metodología: desarrollo de software mediante enfoque iterativo e incremental, de manera que se generen versiones demostrables a partir del primer mes de trabajo en el proyecto.

Requisitos: conocimientos de programación en PHP. Se utilizará la API Telegram Bot.

Directora: Covadonga Rodrigo (covadonga@lsi.uned.es)

Objetivo: El objetivo de este proyecto es la remodelación de una aplicación móvil desarrollada como una actividazd formativa gamificada sobre el cuadro de Fra Angelico "La Anunciación" y desarrollada en el seno del proyecto de investigación MUSACCES.

Descripción: Los museos ya no permanecen ajenos a la evolución de las tecnologías y existen múltiples apps desarrolladas para disfrutar del arte y el patrimonio artístico. En el seno del proyecto MUSACCES se desarrolló un prototipo de app sobre el el cuadro de Fra Angelico "La Anunciación" alojado en el Museo del Prado. La aplicación dispone de elementos de RV y RA así como pequeñas gamificaciones y puntos de interacción con los usuarios. Se quiere continuar con el desarrollo del prototipo, la mejora de su funcionalidad y la integración de nuevos elementos de audio y vídeo.

Requisitos: conocimientos de programación en Unity.

Directora: Raquel Martí­nez Unanue (raquel@lsi.uned.es)

Objetivo: dada una tarea del dominio biomédico se pretende implementar un sistema que permita la transferencia de conocimiento de un dominio a otro, o de una lengua a otra, asumiendo que en el dominio y/o lengua origen se dispone de más conocimiento que en el dominio y/o lengua destino para resolver la tarea.

Descripción: Es habitual en problemas relacionados con la minería de textos y el procesamiento del lenguaje natural que para una determinada tarea se dispongan de herramientas y recursos cuando ésta está limitada a un determinado dominio o a una lengua. Las técnicas de aprendizaje por transferencia (transfer learning) permiten exportar y aprovechar ese conocimiento en otro dominio de especialidad o lengua. Las aplicaciones estarán relacionadas con el dominio biomédico.

Metodología: Se desarrollarán y aplicarán diferentes técnicas de aprendizaje por transferencia a una tarea concreta.

Requisitos: Conocimientos de Java o Python.

Directores: Víctor Fresno (vfresno@lsi.uned.es) y Enrique Amigó (enrique@lsi.uned.es)

Objetivo: El objetivo de este proyecto es el desarrollo de una aplicación que permita comparar representaciones de frases cortas (sentences) basadas en embeddings generados con diferentes modelos de Deep Learning.

Descripción: Desarrollo de una aplicación que permita integrar y comparar diferentes modelos Transformers recopilados en https://huggingface.co/transformers.

Metodología: Se realizará en primer lugar un estudio del problema de la creación de embeddings para representar fragmentos de textos más largos que una palabra, así como de las diferentes arquitecturas neuronales que se han propuesto con este objetivo. Se desarrollará una aplicación que permita ejecutar en paralelo diferentes modelos y aplicar fases de fine-tuning a cada uno de ellos.

Requisitos: Conocimientos de Python.

Director: Francisco Iniesto (finiesto@lsi.uned.es)

Objetivo: El objetivo de este proyecto es la creación de una dashboard que permita comparar las auditorias de accesibilidad web WCAG 2.1 realizadas sobre un mismo o varios recursos (una misma página o portal), por distintos evaluadores, en diversos formatos visuales y estadísticos.

Descripción: El WCAG 2.1 (Web Content Accessibility Guidelines 2.1) es un conjunto de pautas y estándares desarrollados por el World Wide Web Consortium (W3C) para mejorar la accesibilidad de los sitios web y las aplicaciones web. En total, el WCAG 2.1 incluye 13 pautas principales, que se dividen en 61 criterios de éxito. El dashboard debe permitir importar datos, así como crear, editar y guardar auditorías de accesibilidad WCAG 2.1 directamente en el entorno. Además, la visualización de modelos comparativos, incluyendo datos estadísticos, así como la visualización de los resultados de distintas auditorias y comparativas de las mismas.

Metodología: En primer lugar, se realizará un estudio de los principales dashboards existentes en el área de las ciencias y su uso. Posteriormente se procederá a investigar de las distintas herramientas para su creación. Una vez elegida la mejor opción se procederá a su implementación.

Requisitos: Básicos: conocimientos de programación para entornos gráficos (por ejemplo, Python/ Altair o Dash) y conocimientos en estadística. Deseados: lectura de documentación en inglés y de entornos como Tableau, Power BI o similares.

Directores: Raquel Martí­nez Unanue (raquel@lsi.uned.es) y Soto Montalvo (soto.montalvo@urjc.es)

Objetivo: En este proyecto se pretende diseñar e implementar un sistema para el reconocimiento de entidades biomédicas y la identificación de un determinado conjunto de relaciones entre ellas en textos de biomedicina en español.

Descripción: El reconocimiento de entidades y las posibles relaciones que puedan existir entre ellas es fundamental para la extracción de conocimiento de textos no estructurados. Existen diferentes enfoques en el estado del arte, fundamentalmente basados en aprendizaje automático, pero su eficacia es limitada dada la dificultad del problema.

Metodología: Se partirá del estudio de los sistemas existentes que resuelven este problema de manera más exitosa y se llevará a cabo una implementación basada en ellos. El sistema se desarrollará y se evaluará con los recursos proporcionados en https://knowledge-learning.github.io/ehealthkd-2020/.

Requisitos: Conocimientos de Java o Python.

Directores: Laura Plaza (lplaza@lsi.uned.es) Jorge Carrillo (jcalbornoz@lsi.uned.es)

Objetivo: El trabajo que se propone consiste en el desarrollo de un sistema capaz de monitorizar distintos foros de salud en Internet con el objetivo de detectar y extraer información acerca de los tratamientos disponibles para una determinada enfermedad, de su efectividad y de su agresividad.

Descripción: Las opiniones y comentarios de los pacientes, especialmente en el caso de enfermedades crónicas como la diabetes o ciertos tipos de cánceres, constituyen, en opinión de los propios pacientes, la principal fuente de información actualizada y fiable. Cuando se trata de tratamientos (medicación, intervención quirúrgica, revisiones periódicas, etc.), ofrecen la experiencia de quienes ya han sido sometidos a ellos.

Con el auge de la WWW, el número de foros y redes de salud ha crecido exponencialmente, y hoy día, son algunos de los principales puntos de encuentro para pacientes y profesionales. Es por esto que el diseño y desarrollo de nuevas tecnologías capaces de procesar eficientemente esta información ha despertado el interés de la comunidad científica y empresarial.

En este proyecto, nos limitaremos a extraer de estos foros la información relativa a los diferentes tratamientos disponibles para una determinada enfermedad, y clasificarlos en función de su efectividad y agresividad en opinión de los propios pacientes.

Metodología: En primer lugar, se realizará un estudio del problema (extracción y clasificación de información biomédica). En segundo lugar, se estudiarán y seleccionarán distintas fuentes de internet para el caso de estudio. En tercer lugar, se construirá un corpus de trabajo. Finalmente, se diseñarán e implementarán distintos algoritmos encaminados a extraer y clasificar la información sobre los distintos tratamientos.

Requisitos: Conocimientos de programación en Java. También sería deseable tener experiencia en el desarrollo de aplicaciones web, así como conocimientos de procesamiento de lenguaje natural y estadística.

Directora: Covadonga Rodrigo (covadonga@lsi.uned.es)

Objetivo: Desarrollo de un sistema capaz de extraer información en los Términos y Condiciones del servicio (Terms & Conditions) que firman los usuarios en el proceso de registro en un portal web y/o app móvil y su conformidad con el reglamento GDPR (General Data Protection Regulation - Reglamento General de Protección de Datos).

Descripción: Utilizando ejemplos reales de Términos y Condiciones del servicio de varios portales web y/o apps móviles se pretende analizar dicho texto y extraer sus características en relación a los datos y procesos cuya privacidad y seguridad está regulada en Europa por la GDPR. Con el auge de las descargas de las apps móviles y su bajo o nulo coste para el usuario, se han incrementado las violaciones de privacidad de datos almacenados en los dispositivos móviles por parte de las empresas que desarrollan dichas apps. Es por esto que el diseño y desarrollo de nuevas tecnologías capaces de procesar eficientemente esta información ha despertado el interés de la comunidad científica y empresarial.

Metodología:En primer lugar, se realizará un estudio del problema (extracción y clasificación de información de Términos y Condiciones de servicios web). En segundo lugar, se estudiarán y seleccionarán distintas fuentes de portales web o apps móviles para el caso de estudio. En tercer lugar, se construirá un corpus de trabajo. Finalmente, se diseñarán e implementarán distintos algoritmos encaminados a extraer y clasificar la información sobre los distintos tratamientos.

Requisitos: Conocimientos de programación en Java. También sería deseable tener experiencia en el desarrollo de aplicaciones web, así como conocimientos de procesamiento de lenguaje natural y estadística.

Directores: Covadonga Rodrigo (covadonga@lsi.uned.es) y y Marcela Paz González (mpgonzalez@psi.uned.es)

Objetivo: Desarrollo de una aplicación móvil para basada en Realidad virtual para la aplicación de técnicas de exposición (psicología clínica).

Descripción: Este proyecto propone la realización de un sistema de Realidad Virtual cuyo contenido sea flexible (a personalizar según patología o problemática psicológica). La exposición es una técnica psicológica con evidencia empírica para el tratamiento de fobias y otros trastornos de ansiedad.

Metodología: Realización de una app móvil con diseño responsive, con tecnologías Unity y Vuforia.

Requisitos: Conocimientos de programación web o móvil. Deseables conocimientos previos de programación con librerías 3D.

Directores: Alberto Pérez (alberto.perez@lsi.uned.es) y Santiago Dueñas (sduenas@bitergia.com)

Objetivo: Desarrollar un componente para SortingHat que:

• Recomiende qué perfiles de usuarios podrían corresponder a la misma persona (y por tanto podrían ser mezclados)
• Recomiende al usuario cuál podría ser la organización a la que pertenece una determinada identidad de SortingHat en base a información disponible públicamente en Internet.

Descripción: GrimoireLab es un toolkit Open Source para la recolección, enriquecimiento, consumo y visualización de datos procedentes de herramientas comunmente utilizadas en el proceso de desarrollo de Software Libre (Git, GitHub. GitLabe, Gerrit, Jira, Jenkins, StackExchange, Pipermail, etc.). La manera en que se visualzan los datos es a través de dashboards (p.e. https://chaoss.biterg.io/). Estos Dashboards se construyen sobre OpenSearch Dashboards (antes Kibana). Una parte importante de estos dashboards son las identidades únicas, o dicho de otra forma, las personas que hay detrás de los perfiles de usuarios que se encuentran en las distintas fuentes de datos. Para ser capaces de calcular y mostrar métricas robustas es muy importante ser capaces de atribuir las contribuciones a sus autores independientemente de la fuente o el perfil que utilicen para realizarlas. La gestión de estas identidades la realiza un componente llamado SortingHat que permite mezclar o separar perfiles de usuario y asignarles las organizaciones a las que han pertenecido durante un periodo de tiempo determinado.

Este trabajo está orientado a mejorar SortinHat para facilitar al usuario parte del trabajo manual que debe realizar para gestionar las identidades. Para ello se proponen dos caminos principales (durante el desarrollo del trabajo el alumno puede proponer abordar nuevas líneas de trabajo si lo desea, cuya inclusión será evaluada por los directores):

• Recomendación de perfiles similares para mezclar. Se trata de encontrar perfiles que pudieran pertenecer a la misma persona y que no estén aún mezclados. Para ello contamos con la información almacenada en la propia base de datos de SortingHat y podríamos basarnos en la similitud de nombres, correos electrónicos, nombres de usuario, etc. Sería conveniente además que con la sugerencia se incluya cierta información de por qué se realiza o con qué grado de confianza se propone.

• [Extra] También se podría explorar el uso de la información de los perfiles mezclados manualmente para extraer umbrales o reglas que aplicar automáticamente.

• Recomendación de afiliaciones. Dado una identidad, SortingHat es capaz de asociarla a una organización en base al dominio de su correo electrónico, sin embargo hay dos cosas que no hace y que serán parte de este trabajo:

• Cuando aparece un dominio para el que no hay organización asociada, buscar la posible organización y sugerir al usuario su inclusión en la base de datos.
• Cuando un usuario no tiene correo electrónico asociado o éste pertenece a un servidor genérico (gmail, hotmail, etc.) actualmente no hay más solución que buscar manualmente en Internet esa persona y tratar de averiguar a que organización pertenece. El objetivo sería reproducir en la medida de lo posible esos pasos manuales para que se realicen de forma automática y proponer al usuario la posible organización o las fuentes en las que se ha encontrado información relevante para que la consulte y decida. Por ejemplo, un camino habitual es buscar su perfil en GitHub y ver si tiene organización asociada y buscar su nombre en LinkedIn para comprobar si tiene perfil publico con información de afiliación. Ambas cosas, y posiblemente otras, podrían automatizarse para facilitar el trabajo del administrador de SortingHat.

Metodología: El trabajo se llevará a cabo en varias etapas tratando en cada una de ellas de incorporar nuevas funcionalidades respecto a la anterior. Se seguirá un modelo de desarrollo de Software Libre. El proyecto tendrá licencia libre y se desarrollará utilizando un repositorio alojado en GitHub, siguiendo un modelo de forks, ramas y releases (si fuera necesario) básico y utilizando Issues y Pull Requests para documentar los cambios y las posibles mejoras.

La idea final es tener una serie de desarrollos que puedan ser contribuídos upstream a SortingHat. Si bien que esto se realice o que sean aceptados no es requisito necesario para el trabajo, sí es deseable completar el ciclo para entender mejor cómo funcionan los proyectos de este tipo.

En cuanto a las etapas, una posible división sería como sigue:

1. Instalar GrimoireLab y entender su arquitectura y funcionamiento. Será necesario disponer de un entorno funcional y con datos para poder realizar pruebas en las etapas posteriores. Sobre todo nos centraremos en SortingHat y sus interacciones con el resto de componentes, su API y su front-end web.
2. Evaluación de alternativas para sugerir perfiles similares para mezclar.
3. Implementación de alguna(s) de estas alternativas.
4. Evaluación de alternativas para sugerir nuevas organizaciones que incluir en la base de datos.
5. Implementación de alguna de estas alternativas.
6. Evaluación de alternativas para sugerir posibles afiliaciones para las identidades más allá del dominio de su e-mail y de los confines de SortingHat.
7. Implementación de alguna de estas alternativas.

Si bien el trabajo propone varias líneas de acción, dependiendo de la profundidad con la que se vayan atacando cada una de ellas puede que no se lleguen a cubrir todas estas etapas.

Requisitos: Conocimientos de Python, JavaScript, SQL, GraphQL (recomendable, pero se puede aprender durante el trabajo) e inglés leído y escrito

Director: Roberto Centeno (rcenteno@lsi.uned.es) y Álvaro Rodrigo (alvarory@lsi.uned.es)

Objetivo: El trabajo que se propone consiste en el desarrollo de una aplicación capaz de i) recuperar titulares de noticias clasificadas como falsas por alguna web de fact checking (por ej. https://maldita.es o https://www.newtral.es/ o https://www.politifact.com/); ii) recuperar perfiles de usuario de redes como, por ej. Twitter o Facebook, que hayan compartido estos titulares, recopilando datos como sus último "n" mensajes, número de seguidores, likes, fecha de creación, etc.. y; iii) construir datasets con los datos recopilados, almacenándolos en algún formato concreto (por ej. csv, json, etc..).

Descripción: El término "fake news" ha experimentado un increíble aumento de popularidad y atención en los últimos años, convirtiéndose en un área de investigación muy importante. Dentro del área centrado en la detección de noticias falsas de manera automática, una de las tareas fundamentales se focaliza en mitigar o impedir la difusión de noticias falsas en las redes sociales, surgiendo en los últimos años nuevas propuestas centradas en la detección e identificación de perfiles de usuario difusores de noticias en los medios sociales.

Partiendo de estas ideas, el objetivo de este trabajo se centra en el desarrollo de una aplicación que nos permita crear datasets de perfiles de usuarios difusores de noticias falsas en las redes sociales, que sirvan en un futuro para evaluar los mecanismos centrados en la tarea de detección de estos perfiles. Para ello, la aplicación debe permitir recopilar titulares de noticias que han sido catalogadas como falsas por webs dedicadas a la detección de noticias falsas de manera manual. A partir de los titulares recopilados, la herramienta debe buscar en redes sociales como Twitter o Facebook, si ha sido compartida o no dicha noticia y en caso afirmativo recopilar todos los datos posibles de los perfiles de usuarios que han compartido la noticia. Una vez recopilados los datos de estos usuarios, el objetivo final será la construcción de datasets, almacenando los datos en algún formato estándar como puede ser csv o json. 

Metodología: En primer lugar, se realizará un estudio del problema y de las distintas técnicas que se van a aplicar. En esta etapa se contribuirá a la definición de requisitos de la aplicación. A continuación, se realizará una arquitectura de la aplicación, así como la determinación de las funcionalidades requeridas. En tercer lugar, se diseñarán e implementarán dichas funcionalidades, permitiendo el acceso a un conjunto de webs de fact checking y recopilando titulares de noticias catalogadas como falsas. En la siguiente etapa se definirán los aspectos necesarios para el acceso a un conjunto de redes sociales predefinidas, como Twitter o Facebook, que permitan la recopilación de perfiles de usuarios que hayan compartido los titulares recopilados. En esta fase se determinará qué aspectos de los usuarios se van a recopilar. En una siguiente etapa se definirá el formato de almacenamiento de los datos recopilados, para generar conjuntos de datos como resultado final de la aplicación. Finalmente, se llevará a cabo una fase de prueba, evaluando el funcionamiento de la aplicación.

Requisitos: Conocimientos de programación en python o java.

Directores: Alberto Pérez (alberto.perez@lsi.uned.es) y Santiago Dueñas (sduenas@bitergia.com)

Objetivo: El objetivo de este proyecto es integrar un sistema de gestión de credenciales en GrimireLab de tal manera que cualquier componente pueda solicitar las credenciales para acceder a una fuente de datos o servicio.

Descripción: GrimoireLab es un toolkit Open Source para la recolección, enriquecimiento, consumo y visualización de datos procedentes de herramientas comúnmente utilizadas en el proceso de desarrollo de Software Libre (Git, GitHub. GitLabe, Gerrit, Jira, Jenkins, StackExchange, Pipermail, etc.).

Las técnicas utilizadas para la recolección de los datos son diversas y suelen depender de sus fuentes. Por ejemplo, en la versión actual de GrimoireLab, para obtener información de los commits de un repositorio Git, se analiza su log obtenido mediante la ejecución del comando `git log`; para leer los informes de errores (issues) de Bugzilla, se analiza un fichero XML obtenido de la ejecución de un CGI, o para recuperar los datos sobre pull request de GitHub, se utiliza su API REST. En cualquier caso e independientemente del método empleado, el acceso y uso suele estar limitado mediante el uso de credenciales.

Las credenciales permiten a la fuente de datos (herramienta, aplicación web, etc) determinar que el usuario que intenta acceder es quien dice ser (comúnmente conocido como autenticación) y al mismo tiempo, limitar el acceso a los datos en base a su tipo y a las acciones que se pueden realizar sobre estos (también conocido como autorización). En GitHub, por ejemplo, si el usuario no tiene permisos de lectura de un repositorio privado, no podrá descargar información sobre sus issues, pero sí lo podrá hacer sobre todos los repositorios públicos. También se verá limitado en el uso de su API, ya que está restringida a un número determinado de peticiones por hora. Si se hacen más peticiones a la API de las permitidas, tendrá que esperar a que transcurra este tiempo para volver a utilizar su API.

Las credenciales a su vez pueden ser de varios tipos: claves simétricas (usuario y contraseña), claves asimétricas (GPG), tokens de autenticación (JWT), etc.

Actualmente, en GrimoireLab, la gestión de credenciales no es la más adecuada. Se guardan en ficheros de configuración, por lo que, si los permisos de acceso a estos ficheros son erróneos, cualquiera podría tener acceso a estas credenciales. También les resulta complicado a los administradores añadir nuevas credenciales, o actualizar o cancelar las ya existentes cuando su número es elevado. Al mismo tiempo, no se permite proporcionar distintas credenciales para una misma fuente de datos en base a las necesidades. Afortunadamente existen soluciones libres que permiten solucionar todos estos problemas de manera eficiente. Por ejemplo una de las más conocidas es HashiCorp Vault.

El objetivo de este proyecto es elegir una herramienta que permita la gestión eficiente de credenciales y secretos e integrarla en GrimoireLab teniendo en cuenta los siguientes requisitos:

• Gestión de todos los tipos de credenciales usados en GrimoireLab.
• Acceso directo de los componentes de GrimoireLab a las credenciales, evitando el paso de estas entre componentes.
• Manejo de las credenciales de los servicios que usa la plataforma (MariaDB/Mysql, Redis, OpenSearch/ElasticSearch).
• Permiso de creación de una bolsa de credenciales para una misma fuente de datos.
• Uso múltiple de una misma credencial en distintas fuentes de datos.

Metodología: El trabajo se llevará a cabo en varias etapas tratando en cada una de ellas de incorporar nuevas funcionalidades respecto a la anterior. Se seguirá un modelo de desarrollo de Software Libre. El proyecto tendrá licencia libre y se desarrollará utilizando un repositorio alojado en GitHub, siguiendo un modelo de ramas y releases básico y utilizando Issues y Pull Requests para documentar los cambios y las posibles mejoras.

La idea final es tener un proyecto de Software Libre real que cualquiera pueda utilizar y al que cualquiera pueda contribuir, como lo son los proyectos de GrimoireLab.

1. Instalar GrimoireLab y entender su arquitectura y funcionamiento. Será necesario disponer de un entorno funcional y con datos para poder realizar pruebas en las etapas posteriores.
2. Entender los requisitos específicos de cada tipo de credencial gestionado por GrimoireLab.
3. Seleccionar una herramienta de software libre que permita la gestión de credenciales en base a los requisitos obtenidos en el punto anterior.
4. Implementar la gestión y acceso a las credenciales de una fuente de datos basada en API tokens (por ejemplo, GitHub).
5. Implementar la gestión de un pool de API tokens de la fuente de datos seleccionada en el punto anterior.
6. Implementar el uso de distintos tokens para una misma fuente de datos dependientes del repositorio.
7. Implementar la gestión de las credenciales de acceso a los distintos servicios usados por GrimoireLab: MariaDB, Redis, OpenSearch.
8. Implementar el resto de credenciales soportadas por GrimoireLab y obtenidas en el punto 2.

Requisitos: Conocimientos de Python, conocimientos básicos de seguridad informática (ciberseguridad) e inglés leído y escrito