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.

Director: Miguel Ángel Rodríguez García

Objetivo: Desarrollo de un modelo de aprendizaje computacional para problemas de clasificación. 

Descripción: Utilización de técnicas de aprendizaje profundo para resolver problemas candentes en el dominio del Procesamiento del Lenguaje Natural. 

Entre los problemas a resolver, se destacan: identificación implícita de polaridad en el lenguaje natural, identificación de entidades y sus relaciones en el texto, elaboración de algoritmos para clasificar correos y evitar ataques de physing,

Metodología: La realización del proyecto se llevará acabo mediante una metodología incremental que permita al alumno ir aprendiendo paso a paso, desde el inicio con algoritmos de aprendizaje automático básicos, hasta el desarrollo de arquitecturas profundas de redes neuronales. 

Requisitos previos: Habilidades de programación en lenguajes interpretado como python y dominio del inglés para la lectura de la documentación.

Directora: Raquel Martí­nez Unanue (raquel@lsi.uned.es), Miguel Ángel Rodríguez. (miguelangel.rodriguez@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.

Director: Miguel Ángel Rodríguez García (miguelangel.rodriguez@lsi.uned.es)

Objetivo: Este TFG tiene por objetivo desarrollar modelos de aprendizaje automático para resolver problemas actuales en el procesamiento, entendimiento y generación del lenguaje natural. 

Descripción: Debido la diversidad del dominio de aplicación de este TFG, el primer paso se centra en concretar el dominio del problema a resolver. Actualmente, en el procesamiento del lenguaje existen diversos problemas que van desde problemas de textos generativos, análisis contenido clínico, identificación de lenguaje inclusivo o dañino, evaluación de perfiles políticos, entre otros. Después de seleccionar  el problema a abordar, se deberá identificar conjuntos de datos, diseñar e implementar algoritmos basados en aprendizaje automático para tratar de resolver el problema.

Metodología: La realización del proyecto se llevará acabo mediante una metodología incremental que permita al alumno ir aprendiendo paso a paso, desde el inicio con algoritmos de aprendizaje automático básicos, hasta el desarrollo de arquitecturas profundas de redes neuronales. 

Requisitos previos: Habilidades de programación en lenguajes interpretado como python y dominio del inglés para la lectura de la documentación 

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: Lourdes Araujo Serna (lurdes@lsi.uned.es) y Juan Martinez-Romo (juaner@lsi.uned.es)

Objetivo: En este proyecto se pretende diseñar e implementar un sistema para la visualización interactiva de los eventos y datos más relevantes mencionados en un documento médico ordenados temporalmente.

Descripción: Este tipo de herramientas son de gran utilidad para el personal sanitario que puede obtener una imagen inmediata del historial de un paciente, sin necesidad de una lectura detallada de largos documentos. El desarrollo del proyecto requiere representar las menciones
temporales que aparecen en el documento (hace 3 años, todas las semanas, etc.), así como de los sucesos médicos (ingreso, nueva medicación, etc.), y las relaciones entre ellos.
Se necesitará también explorar las opciones más adecuadas para la visualización de los datos.

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.
Los datos de entrada al sistema se realizarán mediante ficheros de intercambio de datos en formato JSON. 
El sistema se desarrollará y se evaluará con datos anotados con eventos y expresiones temporales.

Requisitos: Conocimientos de Python.

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

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