PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA Análisis, Diseño e Implementación de un repositorio de objetos de aprendizaje con contenido versionable e integración con plataformas LMS Tesis para optar por el Título de Ingeniero Informático que presenta el/la bachiller/a: Oscar Miguel Cerna Loli 20121302 Asesor: Mg. Dennis Cohn Muroy Coasesor: Mg. Natalí Flores Lafosse Lima, enero de 2020 A mis padres y mi hermano, por darme su apoyo incondicional. A los amigos que me han acompañado en esta etapa de mi vida. Agradecimientos A mis asesores, por su apoyo y guía durante todo el desarrollo de mi tesis. A los profesores que solucionaron mis dudas y transmitieron su conocimiento. Resumen Los Objetos de Aprendizaje son cualquier tipo de entidad -digital o no digital- y pueden ser usados, reutilizados y referenciados durante el aprendizaje apoyado en tecnología. Comúnmente son utilizados por programas conocidos como Sistemas de Gestión de Aprendizaje (LMS por sus siglas en inglés) que distribuyen y gestionan dichos objetos en forma de cursos o programas educativos. Además, registran la interacción del alumno con cada recurso interactivo dentro de un curso y los reportan a sus instructores o docentes. Para hacer factible esta conexión entre los Sistemas de Gestión de Aprendizaje y Objetos de Aprendizaje se desarrollaron ciertos estándares de creación de objetos. Uno de ellos es SCORM, que especifica técnicas y lineamientos para el desarrollo de contenido. Otro estándar desarrollado es LTI que provee un conjunto de especificaciones que habilitan la interoperabilidad entre contenido remoto y un LMS de manera que se pueda diseñar material educativo que pueda interactuar con el usuario, no solamente ser visualizado por él. Lo que procuran estos estándares es organizar todas las características de los Objetos de Aprendizaje en forma de metadatos. Estos metadatos buscan asegurar la accesibilidad (capacidad de ser accedido), interoperabilidad (capacidad de ser distribuido) y reusabilidad (capacidad para ser utilizado en diferentes contextos) de dichos objetos. Si bien los Sistemas de Gestión de Aprendizaje son los entornos más populares en cuanto a la utilización de los Objetos de Aprendizaje, estos son ambientes de información aislados. Mientras que algunos sistemas almacenan estos recursos en una base de datos propia sin contar con funcionalidades básicas de organización y búsqueda de contenido; otros cuentan con repositorios que almacenan específicamente Objetos de Aprendizaje. Sin embargo, la integración de estos repositorios se limita únicamente al Sistema de Gestión de Aprendizaje con el que fue distribuido. Ello dificulta la adopción de estos objetos en otros espacios, debido a que se deben descargar y volver a subir si se desea usarlo en otro sistema o incluso, en otro curso ofrecido dentro de la misma plataforma. Para que los Objetos de Aprendizaje cumplan con las características de accesibilidad, interoperabilidad y reusabilidad es necesario que estén ubicados de tal manera que sean accesibles por varios usuarios. Esta necesidad es cubierta por los Repositorios de Objetos de Aprendizaje (LOR, por sus siglas en inglés) que son bases de datos en línea que guardan, gestionan y comparten Objetos de aprendizaje. En este proyecto se realizará el análisis de los requisitos con los que debe contar el repositorio, así como las características con las que deben contar los Objetos de Aprendizaje que serán almacenados. También se realizará el diseño de la arquitectura del sistema. Finalmente, la implementación de un Repositorio de Objetos de Aprendizaje que pueda integrarse a plataformas LMS. Que además cuente con herramientas de apoyo que aseguren un mejor aprovechamiento de los Objetos de Aprendizaje como la generación de contenido derivado y funcionalidades de búsqueda por características tomando en cuenta la utilidad del objeto para el usuario. 1 Tabla de Contenido Tabla de Contenido ...................................................................................................... 1 Índice de Figuras .......................................................................................................... 4 Índice de Tablas ........................................................................................................... 6 Capítulo 1. .................................................................................................................... 7 1.1 Problemática .................................................................................................. 7 1.2 Objetivos .......................................................................................................10 1.2.1 Objetivo general .....................................................................................10 1.2.2 Objetivos específicos .............................................................................10 1.2.3 Resultados esperados ...........................................................................11 1.2.4 Mapeo de objetivos, resultados y verificación ........................................12 1.3 Herramientas y métodos ...............................................................................14 1.3.1 Resumen ...............................................................................................14 1.3.2 Herramientas .........................................................................................16 1.3.3 Métodos .................................................................................................20 Capítulo 2. Marco Conceptual ..................................................................................25 2.1 Objetos de Aprendizaje (LO): ........................................................................25 2.2 Repositorio de Objetos de Aprendizaje (LOR): ..............................................28 2.3 Sistema de Gestión del Aprendizaje (LMS): ..................................................29 2.4 SCORM: .......................................................................................................30 2.5 LTI:................................................................................................................31 Capítulo 3. Estado del Arte ......................................................................................34 3.1 Revisión y discusión ......................................................................................35 3.1.1 Investigaciones realizadas .....................................................................35 3.1.2 Productos similares ................................................................................37 3.2 Conclusiones ................................................................................................39 2 Capítulo 4. Análisis y diseño del proyecto ................................................................41 4.1 Análisis .........................................................................................................41 4.1.1 Catálogo de requerimientos ...................................................................41 4.1.2 Descripción de los actores .....................................................................44 4.1.3 Diagramas de casos de uso ...................................................................44 4.2 Diseño ...........................................................................................................47 4.2.1 Vista de proceso ....................................................................................47 4.2.2 Vista lógica.............................................................................................48 4.2.3 Vista de desarrollo .................................................................................50 4.2.4 Vista física..............................................................................................54 4.3 Diseño de pantallas .......................................................................................56 4.3.1 Creación de Objetos de Aprendizaje ......................................................56 4.3.2 Visualización de detalle del objeto .........................................................58 4.3.3 Visualización de lista de objetos creados por el usuario .........................59 4.3.4 Visualizaciones de pedidos de modificación ...........................................59 4.3.5 Creación de nuevas versiones de Objetos de Aprendizaje .....................60 4.3.6 Generación de contenido derivado .........................................................61 4.3.7 Búsqueda simple de Objetos de Aprendizaje .........................................62 4.3.8 Búsqueda avanzada de Objetos de Aprendizaje ....................................63 Capítulo 5. Esquema de metadatos a utilizar ...........................................................65 5.1 Atributos del DCMI-EMS y IEEE-LOM ...........................................................65 5.2 Definición del esquema de metadatos a utilizar en el repositorio ..................66 Capítulo 6. Implementación del proyecto .................................................................69 6.1 Iteración 0 .....................................................................................................69 6.2 Iteración 1 .....................................................................................................69 6.3 Iteración 2 .....................................................................................................70 3 6.4 Iteración 3 .....................................................................................................71 6.5 Iteración 4 .....................................................................................................71 Capítulo 7. Conclusiones y trabajos futuros .............................................................73 7.1 Conclusiones ................................................................................................73 7.2 Trabajos futuros ............................................................................................75 Referencias .................................................................................................................75 Anexo A: Plan de Proyecto ..........................................................................................80 Anexo B: Especificación de casos de uso ...................................................................94 Anexo C: Diagramas de actividades .......................................................................... 105 Anexo D: Diagramas de secuencia ........................................................................... 108 Anexo E: Resultados de juicio de expertos ............................................................... 111 Anexo F: Pruebas de aceptación funcional ............................................................... 113 Anexo G: Criterios de búsqueda y pruebas ............................................................... 124 Anexo H: Pruebas de integración .............................................................................. 131 Anexo I: Diccionario de datos .................................................................................... 135 4 Índice de Figuras Figura 1. Ciclos de desarrollo de un proyecto usando Crystal Clear. ..........................21 Figura 2. Modelo 4+1 y relación entre las vistas. ........................................................24 Figura 3. Elementos y estructura del esquema conceptual LOM ................................28 Figura 4: Flujo general de LTI .....................................................................................33 Figura 5. Identificación de usuarios. ...........................................................................44 Figura 6. Ingreso al repositorio ...................................................................................45 Figura 7. Acceder al contenido ...................................................................................45 Figura 8. Creación y distribución de Objetos de Aprendizaje. .....................................46 Figura 9. Interoperabilidad con Sistemas de Gestión de Aprendizaje .........................46 Figura 10. Esquema de la arquitectura. ......................................................................47 Figura 11. Diagrama entidad relación. ........................................................................48 Figura 12. Diagrama de clases de análisis. ................................................................49 Figura 13. Diagrama entidad relación. ........................................................................50 Figura 14. Diagrama de componentes del Back end. .................................................51 Figura 15. Diagrama de componentes de back end – detalle de la integración vía LTI. ....................................................................................................................................52 Figura 16. Diagrama de componentes. .......................................................................54 Figura 17. Formulario de creación de Objeto de Aprendizaje. ....................................55 Figura 18. Validación de URL .....................................................................................56 Figura 19. Creación de objeto de tipo archivo. ............................................................56 Figura 20. Vista de detalle de Objeto de Aprendizaje. ................................................57 Figura 21. Lista de objetos de usuario. .......................................................................57 Figura 22. Lista de solicitudes pendientes de aprobación. ..........................................58 Figura 23. Lista de solicitudes aprobadas ...................................................................58 Figura 24. Diagrama de componentes. .......................................................................59 5 Figura 25. Versiones de un Objeto de Aprendizaje .....................................................59 Figura 26. Formulario de generación de contenido derivado ......................................60 Figura 27. Indicador de Objeto derivado. ....................................................................60 Figura 28. Barra de búsqueda simple .........................................................................61 Figura 29. Formulario de búsqueda avanzada ............................................................61 Figura 30. Estructura de descomposición del trabajo para el proyecto. (Elaboración propia). ........................................................................................................................83 Figura 31: Cronograma del proyecto. (Elaboración propia) .........................................88 Figura 32: Datos para exportar mediante LTI – prueba 1.......................................... 121 Figura 33: Agregar recurso LTI en Moodle ............................................................... 122 Figura 34: Descarga de Objeto de Aprendizaje con LTI ........................................... 122 Figura 35: Datos para exportar mediante LTI – prueba 1.......................................... 123 Figura 36: Agregar Objeto LTI en Canvas ................................................................ 123 Figura 37: Objeto de Aprendizaje interactivo ............................................................ 124 Figura 38: Objeto de Aprendizaje interactivo ............................................................ 124 6 Índice de Tablas Tabla 1. Cuatro dimensiones para la definición de LO (Alarcón, Alemany, Boza, Cuenca, Gordo, Fernández & Ruiz, 2015) ...................................................................25 Tabla 2. Análisis de definiciones de LO basado en dimensiones (Alarcón, Alemany, Boza, Cuenca, Gordo, Fernández & Ruiz , 2015) ........................................................27 Tabla 3. Especificaciones técnicas de SCORM ..........................................................30 Tabla 4. Comparación de Funcionalidades ofrecidas por cuatro LOR en el mercado .39 Tabla 5. Requerimientos funcionales y no funcionales ................................................44 Tabla 6. Componentes de la capa front end................................................................51 Tabla 7. Componentes de la capa back end ...............................................................52 Tabla 8. Componentes de la capa back end – detalle de la integración vía LTI ..........53 Tabla 9. Detalle de nodos y artefactos del diagrama de componentes........................54 Tabla 10. Estándar de metadatos de Objetos de Aprendizaje Dublin Core .................63 Tabla 11. Estándar de metadatos propuesto para el Repositorios de Objetos de Aprendizaje a desarrollar. ............................................................................................65 Tabla 12. Espala de impactos y riesgos ......................................................................80 Tabla 13. Identificación de riesgos del proyecto. (Elaboración propia) ........................81 Tabla 14. Niveles de severidad y acciones a tomar. (Elaboración propia) ...................82 7 Capítulo 1. 1.1 Problemática El impacto que tienen tecnologías como las computadoras y más actualmente, el internet, es innegable en la vida de las personas. Para Schwab (2016) la aparición de los ordenadores representa la tercera revolución industrial mientras que el internet, la cuarta. Esta última revolución ha cambiado la sociedad y, con ello, un cambio en el paradigma de los procesos de enseñanza y aprendizaje al incluir la tecnología (Bozkurt, A., & Hilbelink, A., 2019). Santos (2012) afirma que “El aprendizaje concebido apenas en acciones como: transmitir o depositar información revela poco para los alumnos de esta nueva generación. Ellos están envueltos de forma efectiva en el proceso de enseñanza y aprendizaje”. Asimismo, otros estudios han mostrado que estudiantes universitarios y de educación superior sienten preferencia al utilizar tecnología que apoye el proceso de aprendizaje (López, López, Flores-Rios & García, 2018; Tick, 2018). La educación virtual o e-learning proveen un medio para que estudiantes puedan interactuar con material educativo desde sus propios computadores o dispositivos móviles (Tick, 2018). Actualmente las aplicaciones de e-learning se fundamentan principalmente en el uso de servicios provistos por programas conocidos como Sistemas de gestión de aprendizaje o LMS, por sus siglas en inglés (Zeman, Vodrážka, Hrad, 2018). Estos sistemas hacen uso de materiales educativos conocidos como Objetos de Aprendizaje (LO, por sus siglas en inglés) que son cualquier tipo de entidad -digital o no digital- y pueden ser usados, reutilizados y referenciados durante el aprendizaje apoyado en tecnología (IEEE, 2002). Los LMS’s son usados en el proceso de e-learning para distribuir y gestionar los LO’s en forma de cursos o programas educativos. Además, registran la interacción del alumno con cada recurso interactivo dentro de un curso y los reportan a sus instructores o docentes (Wang, Niu, Song, Liu, 2007). Para hacer factible esta conexión entre los LMS’s y LO se desarrollaron algunos estándares de creación de objetos como SCORM, desarrollado por Advanced Dristributed Learning (“SCORM Overview”, n.d.) - que especifica técnicas y lineamientos para el desarrollo de contenido - y LTI, desarrollado por IMS Global (“Basic Overview of how LTI Works”, 8 n.d.) - que provee un conjunto de especificaciones que habilitan la interoperabilidad entre contenido remoto y un LMS - de manera que se pueda diseñar material educativo que pueda interactuar con el usuario, no solamente ser visualizado por él. Lo que procuran estos estándares es organizar todas las características de los LO’s en forma de metadatos. Estos metadatos buscan asegurar el cumplimiento de las siguientes capacidades (Dirección de Informática Académica PUCP ,2008):  Accesibilidad: Que el LO pueda ser catalogado a través de metadatos que faciliten su almacenamiento y que pueda ser almacenado y referenciado en una base de datos (Abdelbasset, Larbi, Akhrouf, Yahia, 2015). Si bien la palabra “Accesibilidad” tiene varias definiciones, en este documento cada vez que se use este término se estará refiriendo a la definición dada por Abdelbasset, Larbi, Akhrouf y Yahia mencionada anteriormente.  Interoperabilidad: Que sea sencillo de distribuir a diferentes plataformas.  Reusabilidad: Que pueda ser utilizado en diferentes contextos instruccionales. Si bien los LMS’s son los entornos más populares en cuanto a la utilización de los LO, estos son ambientes de información aislados (Ochoa, Duval, 2009). Mientras que algunos LMS almacenan estos recursos en una base de datos propia sin contar con funcionalidades básicas de organización y búsqueda de contenido; otros cuentan con repositorios que almacenan específicamente LO’s. Sin embargo, la integración de estos repositorios se limita únicamente al LMS con el que fue distribuido. Ello dificulta la adopción de estos objetos en otros espacios, debido a que se deben descargar y volver a subir si se desea usarlo en otro LMS o incluso, en otro curso ofrecido dentro de la misma plataforma. Para que los LO’s cumplan con las características de accesibilidad, interoperabilidad y reusabilidad es necesario que estén ubicados de tal manera que sean accesibles por varios usuarios. Esta necesidad es cubierta por los Repositorios de Objetos de Aprendizaje (LOR, por sus siglas en inglés) que son bases de datos en línea que guardan, gestionan y comparten Objetos de aprendizaje (Lehman, 2007; Tolba, Atwan, Atta, 2009). Un estudio publicado en 2016 mostró el impacto que tuvo el uso de un LOR en las calificaciones de los alumnos inscritos en un curso dictado en una universidad (Ibrahim, Yasien, 2016). En dicho estudio se dividió a los alumnos de una clase en dos grupos, uno de ellos buscaría material de estudio en diferentes páginas web y motores de búsqueda; y otro usaría un LOR para conseguir material. Los 9 resultados al evaluar las notas finales fueron significativos, evidenciando el impacto positivo que tiene un Repositorio de Objetos de Aprendizaje al centralizar y distribuir material útil y significativo. El facilitar la distribución y reutilización de LO’s por medio de los LOR’s pueden hacer que esta tecnología sea potencialmente ventajosa en el apoyo del proceso educativo, aún no se ha adoptado su uso de manera masiva (Casali, Cechinel, Ochoa, 2016). Un análisis cuantitativo sobre el uso de estos repositorios realizado en el año 2009 concluyó que la cantidad de contenido subido a los repositorios crece de manera lineal. La razón principal de este comportamiento es por la deserción de los contribuidores (Ochoa, Duval, 2009). En consecuencia, muchos de los objetos de alta calidad en un repositorio no son accedidos y usados, generando una pérdida en el esfuerzo y tiempo dedicados por los autores que los crearon; y para los autores de nuevos LO quienes crean recursos similares porque no pudieron encontrar y verificar la existencia de estos objetos de alta calidad (Xu, 2015). Xu (2015) realizó una investigación en la cual, junto a tres grupos de expertos, se identificaron los factores más influyentes en cuanto al impedimento del uso de los LOR. Siendo los dos factores principales: la preocupación sobre la estabilidad y persistencia de LO’s; y la cantidad inadecuada de objetos dentro del repositorio. Las recomendaciones dadas para disminuir el impacto de estos factores fueron:  Incrementar la cantidad de los Objetos de Aprendizaje: Se debe resaltar que, debe existir también un aumento de la calidad de los objetos. Se deben aplicar estándares a los metadatos de un LO para facilitar su identificación, descripción de atributos para que así el usuario pueda establecer el grado de utilidad de este objeto (Matkin, 2002).  Implementar un control de versiones para cada Objeto de Aprendizaje: Debido a la preocupación en cuanto a la estabilidad y persistencia de un LOR deben existir funcionalidades que puedan mostrar al usuario que el recurso que desea utilizar es constantemente actualizado y corregido de manera que se pueda encontrar y verificar la existencia de objetos de alta calidad dentro del repositorio (Xu, 2015).  Incorporar los Repositorios de Objetos de Aprendizaje en sistemas de gestión del aprendizaje (LMS): Conesa et al. (2012) sugirió que la integración entre estos sistemas facilitaría el uso de los repositorios dentro del ámbito 10 académico. Xu (2015) indicó que esta integración es un factor muy deseado por las personas que participaron en el estudio de investigación que motivaría al uso de los LOR’s. De acuerdo a los factores presentados por Xu y a lo descrito anteriormente, se han identificado las causas raíces por los cuales no se ha adoptado ampliamente el uso de un LOR dentro de las comunidades educativas:  Problemas en cuanto a la utilidad de los Objetos de Aprendizaje debido a la dificultad al momento de buscar y seleccionar al objeto más útil para el usuario.  Problemas debido a la futura estabilidad y persistencia de los Objetos de Aprendizaje almacenados.  La mínima integración que existe entre los Repositorios de Objetos de Aprendizaje y los LMS’s usados en el mercado actualmente. En base a los problemas presentados se define el propósito de este trabajo de fin de carrera como la implementación de un Repositorio de Objetos de Aprendizaje que pueda integrarse a plataformas LMS. Que además cuente con herramientas de apoyo que aseguren un mejor aprovechamiento de los Objetos de Aprendizaje. Si bien existen actualmente repositorios que logren solucionar parte o alguno de estos problemas, no existe se encontró alguno que brinde generación de contenido derivado cuando se revisaron las opciones que hay en el mercado a la fecha de redacción de este documento, ofrezca funcionalidades de búsqueda por características o utilidad y cuente con interoperabilidad entre todos los LMS’s. 1.2 Objetivos 1.2.1 Objetivo general En base al problema identificado se plantea como objetivo general de este proyecto el desarrollar el Análisis, Diseño e Implementación de un repositorio de objetos de aprendizaje que pueda integrarse con plataformas LMS para así mejorar la accesibilidad, interoperabilidad y reusabilidad de los Objetos de Aprendizaje. 1.2.2 Objetivos específicos O 1. Desarrollar un Repositorio de Objetos de Aprendizaje que permita interconectarse con plataformas LMS. 11 O 2. Definir la estructura de los metadatos de Objetos de Aprendizaje que serán usados en el repositorio para permitir catalogar correctamente los recursos que serán almacenados en el repositorio. O 3. Implementar funcionalidades para que el Repositorio permita la generación de contenido derivado. O 4. Implementar funcionalidades de búsqueda de contenido de manera que el usuario encuentre los Objetos de Aprendizaje que más sean de su interés y utilidad mejorando así la accesibilidad de estos. O 5. Definir los criterios e implementar la interoperabilidad entre el Repositorio de Objetos de Aprendizaje y por lo menos dos LMS utilizados en el mercado. 1.2.3 Resultados esperados Para O 1: R 1. Documento de definición de la arquitectura del Repositorio de Objetos de Aprendizaje a implementar. R 2. Implementación de un Repositorio de Objetos de Aprendizaje siguiendo la arquitectura propuesta. Para O 2: R 3. Documento de definición del proceso de generación del Objeto de Aprendizaje. R 4. Documento de la estructura de los metadatos para el Objeto de Aprendizaje. Para O 3: R 5. Implementación de un módulo de control de versiones de los objetos generados mediante criterios clasificables (fecha y número de versión). R 6. Implementación de funcionalidad que permita generar copias de un Objeto de Aprendizaje las cuales serán utilizadas en el momento de generar una nueva versión de objeto con contenido modificado. Para O 4: R 7. Documento de especificación de los criterios de búsqueda que serán utilizados por el motor para encontrar Objetos de Aprendizaje relevantes para un usuario. 12 R 8. Implementación de funcionalidad en el repositorio que permita a un usuario dar retroalimentación sobre la utilidad de un Objeto de Aprendizaje de manera que se vea reflejado al momento de realizar búsquedas. Para O 5: R 9. Diagramas de los protocolos de integración con plataformas LMS. R 10. Implementación de los protocolos de integración con plataformas LMS. R 11. Diagramas de los procesos de integración de la información del Repositorio de Objetos de Aprendizaje con plataformas LMS. R 12. Implementación de los procesos de integración de la información del Repositorio de Objetos de Aprendizaje con plataformas LMS. 1.2.4 Mapeo de objetivos, resultados y verificación Objetivo: Desarrollar un Repositorio de Objetos de Aprendizaje que permita interconectarse con plataformas LMS. Resultado Meta física Medio de verificación Documento de definición de la arquitectura del Repositorio de Objetos de Aprendizaje a implementar. Documento de arquitectura  Prueba de concepto. Implementación de un Repositorio de Objetos de Aprendizaje siguiendo la arquitectura propuesta. Software  Pruebas de validación Objetivo: Definir la estructura de los Objetos de Aprendizaje que serán usados en el repositorio. Resultado Meta física Medio de verificación Documento de definición del proceso de generación del Objeto de Aprendizaje Documento con diagramas mostrando el proceso.  Pruebas de validación funcional.  Encuesta sobre uso del sistema. 13 Documento de la estructura de los metadatos para el Objeto de Aprendizaje. Documento con la estructura de los metadatos  Juicio de expertos. Objetivo: Implementar funcionalidades para que el Repositorio permita la generación de contenido derivado, esto es, de un Objeto de Aprendizaje en base a otro Resultado Meta física Medio de verificación Implementación de un módulo de control de versiones de los objetos generados mediante criterios clasificables (fecha y número de versión). Software  Pruebas de aceptación que demuestre la generación de un LO derivado a partir de uno existente en el sistema. Implementación de funcionalidad que permita generar copias de un Objeto de Aprendizaje las cuales serán utilizadas en el momento de generar una nueva versión de objeto con contenido modificado. Software  Pruebas de aceptación Objetivo: Implementar funcionalidades de búsqueda de contenido de manera que el usuario encuentre los Objetos de Aprendizaje que más sean de su interés y utilidad mejorando así la accesibilidad de estos. Resultado Meta física Medio de verificación Documento de especificación de los criterios de búsqueda que serán utilizados por el motor para encontrar Objetos de Aprendizaje relevantes para un usuario. Documento de especificación  Juicio de expertos Implementación de funcionalidad que apoye a Software  Pruebas de precisión y exhaustividad, con una 14 la búsqueda de Objetos de Aprendizaje a través de la retroalimentación por parte de usuarios. relevancia definida por expertos Objetivo: Definir los criterios e implementar la interoperabilidad entre el Repositorio de Objetos de Aprendizaje y por lo menos dos LMS utilizados en el mercado. Resultado Meta física Medio de verificación Diagramas de los protocolos de integración con plataformas LMS Documento de arquitectura  Correspondencia entre los Diagramas actividades, secuencia, clases de análisis y componentes Implementación de los protocolos de integración con los LMS’s Software  Pruebas de integración Diagramas de los procesos de integración de la información del Repositorio de Objetos de Aprendizaje con el LMS. Documento de arquitectura  Correspondencia entre los Diagramas actividades, secuencia, clases de análisis y componentes. Implementación de los procesos de integración de la información del Repositorio de Objetos de Aprendizaje con el LMS. Software  Pruebas de integración 1.3 Herramientas y métodos 1.3.1 Resumen Resultados esperados Herramientas y metodologías R1: Documento de definición de la arquitectura del Repositorio de Objetos de Aprendizaje a implementar Documento de casos de uso UML Visual Paradigm R2: Implementación de un Repositorio de Diagrama de secuencia 15 Objetos de Aprendizaje siguiendo la arquitectura propuesta. Diagrama de actividades UML Visual Paradigm R3: Documento de definición del proceso de generación del Objeto de Aprendizaje. Se utilizarán las mismas herramientas y procedimientos que serán usados en R2 R4: Documento de definición de la estructura de los metadatos para un Objeto de Aprendizaje. Se utilizarán las mismas herramientas y procedimientos que serán usados en R2 R5: Implementación de un control de versiones de los objetos generados mediante criterios clasificables (fecha y número de versión). Herramientas a usar: Javascript AngularJS NodeJs Express Base de datos MySql Intellij Idea Máquina Virtual Metodología a aplicar: Metodología Crystal Clear R6: Implementación de funcionalidad que permita generar copias de un Objeto de Aprendizaje las cuales serán utilizadas en el momento de generar una nueva versión de objeto con contenido modificado. R7: Documento de especificación de los criterios de búsqueda usados por el motor. Documento de casos de uso UML Visual Paradigm R8: Implementación de funcionalidad que apoye a la búsqueda de Objetos de Aprendizaje. a través de la retroalimentación por parte de usuarios. Plataforma de búsqueda Solr R9: Diagramas de los protocolos de integración con los LMS’s. Modelo de vista arquitectónica 4 + 1 UML Visual Paradigm R10: Implementación de los protocolos de integración con los LMS’s Moodle LMS Sakai LMS R11: Diagramas de los mecanismos de integración de la información del Repositorio de Objetos de Aprendizaje. con el LMS. Se utilizarán las mismas herramientas y procedimientos que serán usados en R7 R12: Implementación de los mecanismos de integración de la información del Repositorio de Objetos de Aprendizaje Se utilizarán las mismas herramientas y procedimientos que serán usados en R3, R4 y R8. 16 con el LMS. 1.3.2 Herramientas A continuación, se explicarán en más detalle las herramientas a usar obtener los resultados esperados de este proyecto:  Javascript: Es un lenguaje ligero e interpretado, orientado a objetos (Mozilla, n.d.) además de ser multi-paradigma, basado en prototipos y dinámico. Es más conocido como el lenguaje script para páginas web, pero actualmente se puede usar por el lado del servidor (Mozilla, n.d.). Una de las capacidades más dinámicas de Javascript es la capacidad de construir objetos en tiempo de ejecución (Mozilla, n.d.). Se eligió usar este lenguaje ya que es open-source y tiene una comunidad activa que puede ayudar a resolver las diferentes dudas que puedan ocurrir.  AngularJS: Es un framework para Javascript de código abierto para implementar interfaces de usuario. AngularJS permite al usuario extender el vocabulario HTML de una aplicación, resultando en un ambiente más expresivo, fácil de leer y desarrollar. Es completamente extensible y funciona bien con otras librerías. A diferencia de otros frameworks, AngularJS trata el problema de que HTML no fue diseñado para vistas dinámicas al extender su vocabulario a diferencia de abstraer los archivos HTML, CSS y JavaScript (Google, n.d.).  NodeJs: NodeJs es un entorno de ejecución de Javascript orientado a eventos asíncronos ejecutado en el lado de servidor. Node está diseñado para construir aplicaciones en red escalables porque es capaz de manejar muchas conexiones concurrentes (Nodejs, n.d.). Se utilizará Node para el backend del sistema porque la capacidad de atender pedidos de cliente asíncronamente significa que ninguno de los procesos del sistema es capaz de bloquearse. Esta capacidad es necesaria para la implementación del repositorio ya que debe ser capaz de poder atender los pedidos de varios usuarios (Mozilla, n.d.). 17  Express: Express es un framework web, escrito en Javascript y alojado dentro del entorno de ejecución NodeJs. Proporciona mecanismos para la escritura de manejadores de peticiones en diferentes rutas URL y establece ajustes de aplicaciones web como qué puerto usar para conectar. Se utilizará este framework para el backend porque permite manejar el recibimiento de peticiones HTTP del lado de cliente de una forma minimalista y sencilla de implementar.  MySQL Workbench: Herramienta visual unificada para arquitectos, desarrolladores y administradores de bases de datos. MySQL Workbench provee herramientas de modelado de datos, desarrollo SQL y comprensivas herramientas de administración para configuración del lado del servidor, administración de usuarios, backups, entre otras (MySQL, n.d.). Se utilizará esta herramienta para elaborar el diagrama Entidad Relación de la base de datos que se utilizará, así como para la creación de las tablas y sentencias que serán necesarias para su implementación y gestión. Se eligió esta herramienta ya que este software dispone de una versión gratuita y ha sido usada en los diferentes cursos dictados por la especialidad de Ingeniería Informática.  Git: Git es sistema de control de versiones gratuito diseñado para manejar proyectos, ya sea grandes o pequeños. La funcionalidad que separa a Git de otros sistemas de control de versiones es el modelo de ramificación con el que cuenta. Este sistema permite generar versiones de código llamados “ramas” que son independientes una de otra de manera que se pueden tener ramas que contienen solamente lo que irá a producción, otra que esté destinado al entorno de desarrollo y varias para la implementación de nuevas funcionalidades (Git, n.d.). Se utilizará Git para el versionamiento del proyecto de forma que se pueda trabajar en orden, creando ramas para cada nueva funcionalidad, ambiente de desarrollo y producción. Además, se asegurará que cada rama funcione sin 18 ningún tipo de problemas antes de ser integrada a desarrollo y posteriormente, producción.  Intellij Idea: Es un entorno de desarrollo integrado (IDE) para el desarrollo de programas tanto de escritorio como web. Entre sus funcionalidades se encuentran el análisis de líneas de código para detectar bloques repetidos, integración con herramientas de control de versiones como Git y el soporte para los frameworks más populares en el mercado (Jetbrains, n.d.). Esta herramienta fue elegida debido a que sus funcionalidades apoyan muchos procesos del desarrollo web como lo es la implementación del LOR. También, el IDE tiene soporte con los frameworks elegidos. Además, se puede obtener una licencia comercial del IDE de manera gratuita pasando por un sencillo proceso de selección.  Máquina virtual: Una máquina virtual es un entorno ficticio que emula una computadora. Sus implementaciones envuelven especialización de software, hardware o una combinación. Se utilizará para alojar el ambiente en producción del sistema.  Plataforma de búsqueda Solr: Solr es una plataforma de búsquedas open source. Sus funcionalidades resaltantes incluyen: capacidades de búsqueda de tiempo completo, optimización en altos volúmenes de tráfico, integración con bases de datos y provee flexibilidad y adaptación al momento de configurar la plataforma (Apache Solr, n.d.). Una de las funcionalidades de Solr que lo diferencian de una búsqueda usando una base de datos tradicional es la capacidad de poder filtrar los resultados bajo diferentes parámetros ya que permite colocar “pesos” a ciertos atributos sobre otros al realizar la búsqueda. También permite obtener métricas con respecto al uso y desempeño de la plataforma, que serán útiles al momento de realizar las pruebas de precisión y exhaustividad. 19 Se usará esta herramienta para implementar las funcionalidades de búsqueda de Objetos de Aprendizaje dentro del repositorio ya que se desea poder encontrar recursos en función de sus atributos, no solamente por su nombre.  Visual Paradigm Community Edition: Visual Paradigm Community Edition es una herramienta CASE, esto es, que puede ayudar en los aspectos del ciclo de vida de desarrollo de software, en este caso, de las etapas de análisis y diseño. También soporta el modelado de diagramas UML. Se eligió esta herramienta ya que permite elaborar todos los diagramas relativos a las vistas del modelo 4 +1, se tiene acceso a una licencia gratuita y se cuenta con experiencia al realizar diagramas usándola.  Moodle LMS: Moodle es una plataforma de aprendizaje diseñada para proporcionarle a educadores, administradores y estudiantes un sistema integrado único, robusto y seguro para crear ambientes de aprendizaje personalizados (Moodle, n.d.). Esta plataforma será usada para realizar las pruebas de integración con el LOR implementado ya que es open source y actualmente es el LMS usado para proveer el servicio de Paideia de la Pontificia Universidad Católica del Perú.  Sakai LMS: Sakai es un LMS que provee un entorno flexible y lleno de funcionalidades para la enseñanza, aprendizaje, investigaciones y otras colaboraciones. Es usado por universidades, gobiernos y otras organizaciones debido a que contiene herramientas que facilitan la expansión de sus funcionalidades (Sakai Project, n.d.). Esta plataforma también será usada para realizar las pruebas de integración planteadas ya que, es open source y está construida en un lenguaje de programación diferente de Moodle. Con ello se probaría la integración con diferentes LMS de forma independiente a la tecnología sobre la cual fueron construidos. 20 1.3.3 Métodos  Metodología Crystal Clear: Crystal Clear es una metodología de desarrollo ágil de software desarrollada por Alistair Cockburn. Está orientada para grupos de desarrollo pequeños de 1 a 6 personas (Cockburn, 2004). Se basa en una serie de propiedades que son:  Entregas frecuentes: La propiedad más importante en cualquier proyecto es la entrega de código que funcione sin problemas a usuarios reales en intervalos frecuentes.  Mejora reflexiva: El equipo de desarrollo debe comprender que siempre existe espacio para la mejora continua.  Comunicación osmótica: Se desea alcanzar un grado de comunicación tan cercana dentro del equipo de trabajo a tal punto que, los integrantes puedan captar información relevante incluso en procesos en los que no están envueltos activamente.  Seguridad Personal: Cada miembro del equipo debe poder ser capaz de hablar libremente sin tener miedo o vergüenza. Este tipo de ambiente genera confianza dentro del equipo y mejora el desempeño de trabajo.  Foco: Saber qué es lo que se va a hacer y luego, tener tiempo y paz mental para trabajar en eso.  Fácil acceso a usuarios expertos: Es vital poder tener retroalimentación de usuarios reales, para así poder realizar los cambios necesarios antes que sea demasiado tarde.  Ambiente técnico con pruebas automatizadas, Gestión de la configuración e Integración continua: Contar con herramientas de pruebas automatizadas, gestión de configuración e integración continua apoyan al principio de realizar entregas frecuentes testeadas y sin problemas. El proceso de desarrollo del proyecto es dividido en ciclos de diferentes longitudes. Dentro del ciclo del proyecto se encuentran varios ciclos de entregas definidas. Dentro de una entrega se definen los ciclos de iteración necesarios para conseguir la entrega. En una iteración se ejecutan, prueban y validan las tareas planificadas y asignadas. La figura 1 ilustran los ciclos del desarrollo del proyecto 21 Figura 1. Ciclos de desarrollo de un proyecto usando Crystal Clear. (Traducción propia de: https://www.researchgate.net/publication/234820806_Crystal_clear_a_human- powered_methodology_for_small_teams.) Se usará esta metodología para el desarrollo de este proyecto de fin de carrera debido a que está diseñada para grupos pequeños de personas, inclusive solamente una persona. De las propiedades propuestas por Crystal Clear solamente no se tomará en cuenta la de Comunicación Osmótica ya que el equipo de trabajo solamente la conformará una persona. Asimismo, la propiedad de Seguridad Personal se adaptará a fin de asegurar una comunicación fluida y libre con los asesores de este proyecto de fin de carrera. También, se modificará la propiedad del Ambiente técnico ya que no se desarrollarán pruebas automatizadas sino pruebas de validación de funcionalidad con un usuario real. Finalmente, debido a que se deben presentar constantes avances del desarrollo del proyecto el uso de los ciclos de desarrollo de Crystal Clear se ajusta adecuadamente a esta forma de evaluación ya que se deberán presentar avances semanales en el curso de Proyecto de tesis 2. La presentación de una serie de pequeñas entregas de producto funcional será de suma importancia al momento de identificar errores con anticipación.  PMBOK (Project Management Body Of Knowledge): Con respecto a la gestión del proyecto la metodología a utilizar estará basada en ciertas áreas de PMBOK, que es un marco de buenas prácticas y lineamientos que se deben seguir para alcanzar los objetivos de todo proyecto (PMI ,2016). Se definen 9 áreas de conocimiento de los cuales las áreas de Gestión de Alcance y Gestión de Tiempo serán consideradas. Tomando en cuenta esto, se considerarán los siguientes procesos de estas áreas al momento de definir el ciclo de vida del proyecto:  Procesos de inicio: En este grupo de procesos se define el proyecto a desarrollar y se busca su aprobación para poder iniciar las siguientes fases. En el caso de este proyecto de fin de carrera se definió y buscó la aprobación https://www.researchgate.net/publication/234820806_Crystal_clear_a_human-powered_methodology_for_small_teams https://www.researchgate.net/publication/234820806_Crystal_clear_a_human-powered_methodology_for_small_teams 22 del profesor del curso, el asesor de tesis y el comité de tesis. Un resultado de este proceso es la aprobación de este documento ya que contiene la declaración y el propósito de este trabajo de fin de carrera.  Procesos de planificación: En estos procesos se define el alcance y las limitaciones del proyecto, así como la lista de requerimientos del sistema a desarrollar. También se realizará un plan de proyecto conteniendo todas las actividades a realizar.  Procesos de ejecución: En este grupo de procesos se ejecutan las actividades resultantes de los procesos de planificación. En este caso, estas actividades serán ejecutadas y controladas según la metodología Crystal Clear. Tanto los procesos de ejecución como los de planificación podrán ejecutarse varias veces durante el ciclo de vida del proyecto.  Procesos de monitoreo y control: Estos procesos tienen como objetivo revisar el progreso y desempeño del proyecto. Serán ejecutados en paralelo a los demás procesos del ciclo de vida del proyecto ya que, al medir y analizar en intervalos de tiempo definidos se pueden identificar a tiempo desviaciones de las actividades planificadas o errores en los procesos de ejecución.  Procesos de cierre: En este grupo de procesos se toman las acciones necesarias para completar el proyecto o fase. En muchos casos, el cierre de una fase debe ser aprobado antes que la fase pueda ser considerada como cerrada. Para estos procesos se deberá entregar toda la documentación requerida al momento de sustentar el proyecto de tesis.  UML: UML o Unified Modeling language es un lenguaje de modelado que ayuda a especificar, visualizar y documentar modelos de sistemas de software, incluyendo su estructura y diseño (UML, n.d.). Es usado para modelar cualquier tipo de aplicación sin importar el hardware donde es desplegado, plataforma o lenguaje de programación. Es un lenguaje altamente flexible y posee una curva de aprendizaje baja. También, se cuenta con experiencia previa en el uso de este lenguaje de modelado. Finalmente, es el lenguaje de modelado usado por la herramienta Visual Paradigm, que será utilizada para elaborar los diagramas requeridos. 23 Por estas razones, UML será usado para los diagramas que serán incluidos dentro del documento de arquitectura del LOR a implementar.  Modelo de vista 4 +1: 4+1 es un modelo de vista diseñado por Philippe Krutchen para representar y describir una arquitectura de software (Krutchen,1995). Este modelo está compuesto de cinco vistas o perspectivas:  Vista lógica: Esta vista tiene como propósito mostrar las funcionalidades que el sistema proveerá a los usuarios. Los diagramas de clase de análisis son usados para representar esta vista ya que al abstraer el sistema en clases se pueden explotar los principios de abstracción, encapsulación y herencia que ayudan a identificar los mecanismos comunes y elementos de diseño presentes en varias partes del sistema.  Vista de proceso: Esta vista toma en cuenta algunos requerimientos no funcionales del sistema y como las abstracciones principales de la vista lógica encajan dentro de los procesos del sistema. El diagrama UML usado para representar esta vista es el diagrama de actividades que representan los flujos de trabajo del sistema.  Vista de desarrollo: Esta vista se enfoca en la organización real por módulos del sistema en el ambiente de desarrollo. Muestra la organización por capas de estos componentes, así como la comunicación entre estos. El diagrama UML de componentes es usado para representar esta vista. Cabe resaltar que los componentes del sistema son cualquier elemento requerido para ejecutar una función. Ejemplos de posibles componentes a representar son: tablas de bases de datos, módulos del proyecto o incluso otros sistemas.  Vista física: Esta vista toma en cuenta los requisitos no funcionales del sistema como disponibilidad, tolerancia a fallos, desempeño y escalabilidad. Muestra la topología de los componentes del sistema y como se conectan físicamente. El diagrama de despliegue UML es usado para esta vista ya que identifica a estos componentes como nodos y muestra su comunicación.  Escenarios: Los elementos descritos en las cuatro vistas anteriores son integrados por el uso de escenarios o casos de uso que describen las interacciones entre los componentes del sistema, procesos y el usuario. Estos escenarios son usados para identificar elementos arquitectónicos y validar el 24 diseño del sistema. Los documentos de historias de usuario o diagramas de casos de uso son usados para representar los escenarios del sistema. Figura 2. Modelo 4+1 y relación entre las vistas. (Extraído de: Krutchen P. (2015). Planos Arquitectónicos: El Modelo de 4+1 Vistas de la Arquitectura del Software) Se eligió utilizar este modelo para representar la arquitectura del sistema ya que, al ser un modelo genérico, este no establece una notación o herramienta específica para elaborar los diagramas de las diferentes vistas. Esto permite diseñar solamente los diagramas que serán necesarios para cada vista arquitectónica que serán elaborados con las herramientas definidas en esta sección. 25 Capítulo 2. Marco Conceptual En esta sección se detallarán los conceptos relevantes para la comprensión del proyecto que consiste en la implementación de un Repositorio de Objetos de Aprendizaje que almacene y clasifique estos objetos además de ser capaz de versionarlos y que pueda integrarse con Sistemas de Gestión de Aprendizaje. En tal sentido se explicarán los conceptos relacionados a Objetos de Aprendizaje, Repositorios de Objetos de Aprendizaje y los protocolos y sistemas con los que se desea alcanzar la interoperabilidad. 2.1 Objetos de Aprendizaje (LO): Existen muchas definiciones de un LO, por lo que se buscará un concepto consensuado. Para ello se usarán las dimensiones planteadas por Alarcón, Alemany, Boza, Cuenca, Gordo, Fernández y Ruiz que, en el año 2015, identificaron cuatro dimensiones que pueden usarse para definir los LO. Estas dimensiones se presentan en la Tabla 1. Dimensión Descripción ¿Qué es? A través de esta dimensión se identifican los LO con elementos existentes usados en la enseñanza. ¿Cómo es? En esta dimensión se describen las propiedades relevantes de los LO. ¿Cómo es usado? Cuándo y dónde el uso de un LO es apropiado. ¿Cómo es soportado? En esta dimensión se cubre el soporte tecnológico y material. Tabla 1. Cuatro dimensiones para la definición de LO (Alarcón, Alemany, Boza, Cuenca, Gordo, Fernández & Ruiz, 2015) A partir de las dimensiones planteadas se analizaron diversas definiciones aprovisionadas por diferentes autores. La Tabla 2 muestra algunos resultados del análisis. 26 Autores ¿Qué es? ¿Cómo es soportado? ¿Cómo es? ¿Cómo es usado? Wiley (2000) Recurso Digital Que puede ser reusado Para apoyar el aprendizaje IEEE (2002) Entidad Digital o no digital N.A. Que puede ser usado para aprender, educar o entrenar Govindansamy (2002) Bloque de información relevante N.A. Compartible y reusable. Al igual que un átomo, el LO también se compone de varios componentes pequeños Que los alumnos pueden acceder e internalizar en una sesión. Learning Technology Standards Committee (2002) Entidad Digital o no digital Que puede ser usada, referenciada o reutilizada Durante el aprendizaje apoyado en tecnología Vargo, Nesbit, Belfer, Archambault (2003) Elemento de conocimiento, recurso de aprendizaje y componente instruccional Material en línea Tres partes: Un objetivo de aprendizaje, una actividad de aprendizaje y una evaluación del aprendizaje N.A. Polsani (2003) Unidad de contenido instruccional N.A. Independiente y predispuesto a su reutilización. En múltiples contextos instruccionales Del Moral, Cernea (2005); Del Moral, Cernea , Villalustre (2013) Unidad mínima de contenido de aprendizaje Compuesto por múltiples paquetes de formatos interactivos, identificables por metadatos Sus características son ser: reusables, compatibles a nivel técnico, adaptables y durables. Diseñados a alcanzar un solo objetivo de aprendizaje integrando contenido instruccional, recursos, actividades y evaluaciones. 27 Grace, Suan, Wanzhen (2008) Bloques de construcción Que pueden ser presentados a través de una variedad de medios incluyendo texto, gráficos, animaciones, audio y video Que pueden ser combinados en una variedad de formas virtualmente infinita. Pueden ser tan pequeños como un párrafo o tan largos como un tutorial Para construir colecciones que pueden ser referidas como lecciones, módulos, cursos o currículas. Tabla 2. Análisis de definiciones de LO basado en dimensiones (Alarcón, Alemany, Boza, Cuenca, Gordo, Fernández & Ruiz , 2015) En base a la Tabla 2, se concluye que la mayoría de los autores identifican al Objeto de Aprendizaje como una entidad, átomo, bloque o unidad. En consecuencia, se puede llegar a definir que el LO es un elemento independiente que puede formar parte de algo más grande. Los autores concuerdan, también, que estos objetos deberían apoyar el proceso de aprendizaje y para facilitarlo, ellos deben ser reutilizables en diversos contextos y plataformas digitales. En base a estas conclusiones, la definición que será tomada en cuenta para el desarrollo de este proyecto de investigación es el propuesto por Del Moral y Cernea debido a que contiene no solamente la definición de un Objeto de Aprendizaje sino también las características y el propósito que poseen. Para ello, el LO tiene una estructura de información externa -metadatos - que facilita su almacenamiento, identificación y recuperación (Colombia Aprende, 2018). La IEEE ha definido un estándar llamado Learning Object Metadatos (IEEE LOM, 2002) para especificar los metadatos de un LO en forma de que éste pueda ser interoperable, esto es, poder ser usado en diferentes plataformas digitales de aprendizaje. Estos metadatos están descritos en un archivo XML que se distribuye junto al LO e incluye las siguientes categorías: A. Categoría General B. Categoría del Ciclo de vida C. Categoría de Meta-metadatos D. Categoría Técnica E. Categoría Educacional 28 F. Categoría del Derecho G. Categoría de Relación H. Categoría de Anotaciones I. Categoría de Clasificación En la Figura 3, se muestran las etiquetas que pueden acompañar a cada categoría. Figura 3. Elementos y estructura del esquema conceptual LOM (Extraído de: https://www.palabraclave.fahce.unlp.edu.ar/article/view/PCe040/8864) 2.2 Repositorio de Objetos de Aprendizaje (LOR): Es la infraestructura clave para el desarrollo, almacenamiento, administración, localización y recuperación de todo tipo de contenido digital (ADL, 2002). Se puede definir como un almacén de LO con metadatos asociada, donde los recursos se identifican y se clasifican de una manera específica, de forma que se facilite su posterior búsqueda y utilización (Bieliuskas, 2015). Se debe aclarar que un repositorio digital, si bien se almacena contenido, tiene aspectos y características diferentes a una base datos o de un sistema de gestión de contenidos. Heery y Anderson (2015) identificaron cuatro características que diferencian a los LOR de otros sistemas de almacenamiento de colecciones digitales: https://www.palabraclave.fahce.unlp.edu.ar/article/view/PCe040/8864 29  Los contenidos son depositados en el repositorio ya sea por el autor, el propietario o por terceros.  Se genera metadatos para cada contenido depositado.  Se ofrecen servicios básicos mínimos como: subir, encontrar, buscar y controlar el acceso de contenidos.  El repositorio debe ser sostenible, es decir, preservable ante cambios técnicos o de hardware; estar bien mantenido y apoyado. También describen algunas funcionalidades que los repositorios deben buscar cumplir:  Preservación de recursos digitales.  Reusabilidad de los recursos almacenados.  Compartir el acceso de los recursos a varios usuarios. 2.3 Sistema de Gestión del Aprendizaje (LMS): Es una aplicación de software que automatiza la administración, rastreo y reporte de eventos de entrenamiento (Ellis, 2009). Los LMS’s proveen una forma de simplificar la enseñanza y el aprendizaje conectando todas las herramientas digitales que los docentes usan en una sola plataforma (Canvas, n.d.). Ellis también define los siguientes requerimientos funcionales que un LMS debe cumplir:  Herramientas de administrador: El LMS debe permitir que usuarios administradores gestionen el registro de usuarios y perfiles, definir roles y administrar contenido.  Adherencia a estándares: Un LMS debe poder ser capaz de importar y gestionar contenido que cumpla ciertos estándares, como SCORM, sin importar qué herramienta generó dicho contenido.  Configurable: La organización que usa un LMS debe ser capaz de poder configurar o cambiar ciertos procesos del sistema de forma sencilla.  Seguridad: La seguridad es una prioridad en un sistema que contiene información de usuarios y contenido propietario. El uso de contraseñas 30 y encriptación de datos son algunas de las típicas medidas de seguridad dentro de un LMS  Integración de contenido: Es importante que se pueda añadir contenido de terceros a un LMS sin tener problemas de compatibilidad. 2.4 SCORM: Por sus siglas significa: “Modelo compartible de referencia de contenido de objeto”. Es un grupo de estándares técnicos que habilitan la comunicación entre un contenido de aprendizaje en línea con un LMS (“SCORM Overview”, n.d.). Esta colección de especificaciones técnicas y lineamientos están diseñados para la creación de Objetos de aprendizaje (ADL, Scorm Users Guide for developers). Consiste en especificaciones técnicas agrupadas en tres diferentes secciones, las cuales pueden ser visualizadas en la Tabla 3. Sección Contenido SCORM Run-time Environment (RTE) Define un modelo de datos común y API para contenido de aprendizaje electrónico. Esto permite que la comunicación entre el contenido - por el lado del cliente - y el entorno de ejecución comúnmente provisto por un LMS sea estandarizada y se logre la interoperabilidad. SCORM Content Aggregation Model (CAM) Define como empaquetar el contenido para facilitar el intercambio entre sistema y sistema. Esto estandariza el mecanismo de portabilidad entre varios LMS. También describe cómo organizar y aplicar metadatos a todos los componentes de un paquete de contenidos, de manera que se facilite la búsqueda de un contenido específico. De esta forma se asegura la reusabilidad. SCORM Sequencing and Navigation (SN) Describe como el contenido dentro de un paquete será presentado al usuario mediante una serie de eventos definidos. Tabla 3. Especificaciones técnicas de SCORM 31 Todo contenido SCORM se encuentra en un “paquete de contenido”, el cuál es un archivo comprimido en formato zip donde se hallan todas las especificaciones necesarias para la integración con un LMS. Está compuesto por dos partes principales: los componentes de contenido y un archivo Manifest. Los componentes de contenido SCORM mantienen una jerarquía: los más pequeños son los recursos, los cuales son representaciones electrónicas de texto, imágenes, sonidos, media, páginas HTML y otros pedazos de datos. Su función no es comunicarse con el LMS sino de ser ítems reutilizables en diferentes contextos y aplicaciones. Uno o más recursos pueden ser contenidos dentro de un Objeto de Contenido Compartible o SCO, por sus siglas en inglés, la cual es la mínima unidad lógica de información que puede interactuar con un LMS. En términos técnicos, este es el único componente de un curso que usa el API de SCORM para comunicarse con los LMS’s. Este API, es el medio estandarizado por el cual se registra la interacción entre un alumno y un curso registrado en el LMS. Cuando se tiene una colección de actividades relacionadas, éstas son agrupadas en una agregación, que puede contener SCOs u otras agregaciones. Al grupo de agregaciones que es parte de un mismo contenido se le conoce como organización y es aquí donde los objetos son ordenados y se definen comportamientos de secuencia. La organización es un conjunto de agregaciones que se pretenden entregar como un solo paquete de contenido y es el componente de mayor jerarquía dentro de un paquete de contenido SCORM. En el archivo Manifest XML se describen:  Todos los SCOs o recursos que se desean incluir en el paquete.  La representación del como el contenido está estructurado, en otras palabras, la organización.  Las reglas de secuencia de los contenidos.  Los metadatos para los SCOs, agregaciones y el paquete en sí. 2.5 LTI: Learning Tools Interoperability, diseñado por Internet Media Services (IMS), es un conjunto de especificaciones que permiten que herramientas y contenidos remotos se puedan integrar a un LMS (IMS Global, n.d.). 32 Este estándar provee un estilo simple de modelo de despliegue que consiste en una URL, una llave y un código secreto que el administrador del LMS o el instructor de un curso pueden ingresar para que el recurso educativo remoto pueda interactuar con la plataforma. Además, define un protocolo para lanzar una aplicación externa desde el sistema de forma que soporte single-sign-on (SSO) y preserve el contexto de aprendizaje y los roles de usuario según ese contexto. En la práctica, la comunicación de LTI con un LMS funciona de la siguiente forma: 1. Un instructor o administrador de LMS debe obtener acceso a una herramienta educativa LTI alojada externamente. 2. El proveedor del recurso LTI entrega el link de acceso, la llave y el código secreto del LO. 3. Este link, llave y código pueden añadirse a la estructura de un curso como metadatos del LO. 4. Cuando los alumnos acceden al objeto mediante el link, comienza la comunicación entre el consumidor (el LMS) y el proveedor de la herramienta LTI. 5. El consumidor manda al proveedor datos como: el nombre del LMS de donde se está queriendo acceder al recurso, el nombre del usuario que accede y el nombre del curso al que pertenece el recurso. 6. El proveedor encuentra el LO buscado, verifica que se cuenten con los permisos necesarios y de ser así, provee al usuario con acceso a dicho objeto. Toda comunicación entre el consumidor y el proveedor se realiza mediante los servicios LTI de manera que el usuario no se dé cuenta que está interactuando con un recurso que no se encuentra alojado dentro del LMS. Se puede ver el flujo descrito en la Figura 4. 33 Figura 4: Flujo general de LTI (Elaboración propia basado en: https://help.blackboard.com/es- es/Blackboard_Open_Content/Administrator/Open_Content_Technical_Details/Learning_Tools_Interopera bility_%28LTI%29 https://help.blackboard.com/es-es/Blackboard_Open_Content/Administrator/Open_Content_Technical_Details/Learning_Tools_Interoperability_(LTI) https://help.blackboard.com/es-es/Blackboard_Open_Content/Administrator/Open_Content_Technical_Details/Learning_Tools_Interoperability_(LTI) https://help.blackboard.com/es-es/Blackboard_Open_Content/Administrator/Open_Content_Technical_Details/Learning_Tools_Interoperability_(LTI) 34 Capítulo 3. Estado del Arte En esta sección se describirán algunas investigaciones realizadas, así como otras alternativas de LOR ya implementadas en el mercado con el propósito de conocer los esfuerzos realizados por otras personas que han brindado soluciones a medida según los problemas encontrados en su propio contexto. Además, se realizará una comparación entre los LOR identificados a nivel de funcionalidades y se culminará describiendo el alcance de la propuesta de este proyecto de fin de carrera. Para identificar las investigaciones anteriores se realizó una revisión bibliográfica en diversas fuentes. Primero se hizo una búsqueda con la cadena “Learning Objects Repository” en la base de datos IEEExplore. Se eligió esta base de datos debido a que la IEEE produce muchos artículos y conferrencias sobre tecnologías orientadas específicamente al aprendizaje. Se seleccionaron los artículos que contenían exactamente la cadena de búsqueda en su título, resumen o palabras clave, identificándose alrededor de 100 artículos. Luego se revisaron trabajos presentados en la Conferencia Latinoamericana de Tecnologías de Aprendizaje (LACLO) debido a que los expositores intercambian experiencias sobre los diversos aspectos del desarrollo tecnológico aplicado al aprendizaje. Dado que esta conferencia es realizada en Latinoamérica muchas de las motivaciones y el contexto que presentan estos trabajos de investigación son aplicables al entorno peruano y pueden ser aprovechadas para el desarrollo de este proyecto de fin de carrera. Finalmente se realizó una búsqueda de proyectos de tesis similares en el repositorio de tesis de la PUCP mediante el ingreso de las cadenas de búsqueda: “objeto de aprendizaje” AND “repositorio” y “learning object” AND “repository”. De entre los resultados no se pudo encontrar ningún proyecto relacionado al análisis, diseño o desarrollo de un LOR. Todas las búsquedas, tanto en la base de datos de IEEExplore como los archivos de LACLO y el repositorio de tesis PUCP fueron realizados en el mes de setiembre del año 2018. Para identificar a los productos similares se buscó en internet cuales eran los LOR más usados en el mercado. 35 3.1 Revisión y discusión 3.1.1 Investigaciones realizadas Al realizar la búsqueda de investigaciones se encontraron resultados que pueden ser catalogados en dos tipos: Implementación de LOR en un contexto específico y desarrollo de modelos y lineamientos para una mejor implementación de LOR. Varias de las investigaciones de implementación fueron realizadas para ayudar a universidades en la distribución de LO’s. Una de estos proyectos es ROACAA (Bieliukas, 2015). Este proyecto de investigación tuvo como propósito desarrollar e implementar un Repositorio de lo que la autora denomina Objetos de Aprendizaje de Contenidos Abiertos Accesibles (OACAA). Este repositorio está encargado de los procesos de almacenamiento, búsqueda, recuperación, visualización y uso de estos recursos, con el propósito de que los OACAA sean accesibles para todo que desee usarlos. Este proyecto es un componente del Sistema de Gestión de Objetos de Aprendizaje de Contenidos Abiertos Accesibles propuesto por Hernández, Arredondo, Monasterio y Díaz en el LACLO del año 2013. El LOR desarrollado es de tipo centralizado y cuenta con las siguientes funcionalidades: herramientas de búsqueda, herramientas de recopilación, colectividad, meta-etiquetado, administración de contenidos, administración y cumplimiento de derechos digitales de autor, presentación y salidas de consorcio, integración e interoperabilidad, consideraciones técnicas, y licenciamiento. A la fecha de escritura de este documento, el LOR no se encuentra operativo. Otras investigaciones de implementación tienen como objetivo el de facilitar el desarrollo y distribución de LO. Este es el caso de CLOVer (Silva, Souza & Souza M. 2017). El propósito de esta investigación fue presentar una propuesta de LOR cuya funcionalidad principal es el de proveer al usuario una manera de customizar LO sin necesidad de tener ciertos conocimientos técnicos previos, ya que comúnmente muchos de estos son producidos como bloques monolíticos cuyas modificaciones deben ser hechas a nivel de código fuente. El proveer al usuario una manera sencilla de ajustar, adaptar, modificar o alterar el contenido de un LO procura alcanzar una mejor reutilización de contenido. A este nuevo tipo de recurso se le llamó Objeto de Aprendizaje Customizable (CLO). 36 Este LOR, llamado CLOVer (Customizable Learning Object Versioning), fue propuesto como una herramienta accesible desde una plataforma web y tiene funcionalidades como guardar, buscar, visualizar y descargar CLO ya sea mediante el uso de la herramienta como por medio de servicios REST. CLOVer también maneja usuarios y permisos de visualización. Existe también una funcionalidad de versionamiento de CLO pero no a nivel de los objetos que lo componen. Similar a estos dos trabajos mencionados anteriormente, se encontraron alrededor de 70 artículos detallando el proceso de implementación de un LOR, la mayoría de ellos contando con una fecha de publicación anterior a diez años de la fecha de redacción de este proyecto de tesis. Es evidente entonces, la relevancia de este tipo de tecnologías en el campo educativo en la actualidad; sin embargo, el alcance de estas investigaciones pasadas es reducido, en la mayoría de casos, el uso de estos LOR’s está orientando al personal de ciertas universidades sin tomar en cuenta la interoperabilidad con las plataformas LMS existentes. Si bien el trabajo que se desarrollará para este proyecto de tesis contará con funcionalidades básicas similares a las provistas por la mayoría de LOR’s como: subir, guardar y buscar contenido, éste se diferenciará de ellos debido a que buscará disminuir las barreras de interoperabilidad causantes del poco aprovechamiento de estas tecnologías por parte de los docentes. Con respecto a las investigaciones sobre modelos y lineamientos para el desarrollo de LOR se identificó la de Nascimento, Brandão L. & Brandão A. (2013). Esta investigación parte de la pregunta: ¿Cómo distribuir mejor LOs? y afirma que, si bien el desarrollo de un LOR ayuda a alcanzar una mejor reutilización y distribución de LO, aún existe una serie de barreras que impide sean usados por docentes. Algunas de ellas son la alta curva de aprendizaje al crear contenido en un repositorio y la falta de integración con los LMS’s usados en la enseñanza. Los autores proponen un modelo de características que un LOR debe poseer y culminan realizando la integración de este modelo con el LMS Moodle. Las características de este modelo son:  Clasificación y búsqueda de LO: El LOR debe poder soportar los estándares más usados de metadatos como IEEE Learning Object Metadata para así lograr que el proceso de búsqueda específica de LO sea más exacta. 37  Control de granularidad de LO y dependencias: Cuando se habla de granularidad en LO se hace referencia al nivel de detalle y alcance de un objeto. Debido a que un LO puede ser desde un documento de texto hasta una página web con elementos interactivos los profesores deben ser capaces de crear y organizar LO’s de una forma que representen un arreglo lógico de contenido digital como un paquete auto contenido. De esta forma se facilita la composición, versionamiento y distribución de los LO’s más complejos.  Control de versiones: Se espera que los contenidos de un LO cambien al transcurrir el tiempo ya sea añadiendo, removiendo o actualizando los archivos que lo componen, así como sus metadatos. Es por eso que un LOR debe ser capaz de registrar cualquier cambio hecho por un autor de manera que todas las versiones del LO sean automáticamente actualizadas en el repositorio.  Evaluación de la calidad de un LO por otros autores: Es importante que varios autores puedan evaluar el nivel de calidad de un LO ya que dichos indicadores pueden ser considerados al momento de realizar una búsqueda, logrando así la reutilización de los LO’s más útiles. Para validar este modelo se implementó un prototipo de LOR y se desarrolló un plugin de Moodle para poder realizar la conexión entre el repositorio y el LMS. Esta integración funcionó de tal manera que el usuario pueda acceder a las funcionalidades del LOR desde la misma interfaz de Moodle incluso usando la misma cuenta, rol y privilegios que posee en el LMS. Debido a que toda operación básica del LOR puede ser ejecutada desde la plataforma Moodle siguiendo una estructura similar a las acciones del LMS, se reduciría la curva de aprendizaje para un docente, promoviendo su uso. Para el desarrollo de este proyecto de tesis se tomarán en cuenta las características propuestas por este modelo al momento de definir la forma en como los LO’s usados por el LOR a implementar deberán ser modelados. 3.1.2 Productos similares Se han identificado cuatro LOR ya existentes en el mercado:  Canvas Commons: Repositorio de objetos de aprendizaje que permite a los usuarios del LMS Canvas el encontrar, importar y compartir recursos. Permite construir cursos con Objetos de Aprendizaje compartidos por otros usuarios de Canvas así como extraer materiales de otros cursos para poder usarlos en la 38 creación de nuevos. Si se modifica un recurso en Canvas que fue compartido en Commons este será actualizado también (Canvas, n.d.).  Blackboard Open Content: Es un Repositorio basado en tecnología cloud. Permite la creación y la distribución de Objetos de Aprendizaje. Sin embargo, solamente se puede acceder al repositorio mediante el Sistema de Gestión de Aprendizaje Blackboard Learn aunque los recursos almacenados pueden ser compartidos entre diversas instancias de este LMS. Open Content cuenta con soporte para dos formas de protección de derechos de autor: Creative Commons y licencias particulares cuyos objetos protegidos solamente pueden ser accedidos por los creadores de dichas licencias (Blackboard, n.d.).  SAFARI Montage: Repositorio que cuenta con contenido precargado como videos de varias publicadoras educativas (SAFARI Montage, n.d.). Soporta interoperabilidad mediante LTI  Brightspace: Repositorio que cuenta con funcionalidades de búsqueda avanzadas como uso de palabras clave, calificaciones y comentarios además de poseer administración de metadatos que permite clasificar fácilmente los recursos almacenados (Brightspace Learning Repository n.d.). La Tabla 4 muestra una comparación de las funcionalidades con las que cuentan tales alternativas: Canvas Commons Blackboard Open Content SAFARI Montage Brightspace Learning Repository Creación de LO Se puede subir contenido educativo y generar los metadatos correspondientes. Búsqueda de LO Se pueden buscar los LO almacenados mediante filtros o palabras clave. Soporte SCORM No especificado No especificado No especificado No es posible 39 Soporte LTI Soportado Soportado Soportado Soportado Compartir contenido con otros usuarios Se puede decidir si el contenido almacenado es público o visible solamente para ciertos usuarios. Versionamiento Versionamiento de cursos almacenados Permite el versionamiento de recursos No especificado Permite el versionamiento de recursos Integración con LMS Solamente a Canvas LMS Solamente a Blackboard LMS Solamente vía LTI Solamente vía LTI Tabla 4. Comparación de Funcionalidades ofrecidas por cuatro LOR en el mercado Al analizar la Tabla 4 se observa que dos de los cuatro LOR tienen integración directa con el LMS de la propia familia desarrolladora del repositorio. Además, ninguna de las opciones comparadas almacena paquetes de tipo SCORM. Podemos inferir, que se debe a que mayormente se guarda este tipo de paquetes a nivel de Sistemas de Gestión de Aprendizaje. Por otro lado, todas soportan la norma LTI. Las funcionalidades en común que presentan estos Repositorios de Objetos de Aprendizaje son las operaciones básicas de un repositorio como el subir, guardar y buscar contenido, así como generar metadatos relativa al LO almacenado. Finalmente, solo tres de las cuatro opciones analizadas contaban con un mecanismo de versionamiento de contenidos como característica del sistema. 3.2 Conclusiones Tanto los trabajos de investigación como los repositorios alternativos tienen como objetivo lograr la fácil distribución y reusabilidad de los LO’s para apoyar a la enseñanza basada en la tecnología. Se han conseguido lograr estos objetivos en cierta medida: se ha vuelto más sencilla la creación y organización de LO, la generación de metadatos ayuda a que pueda ser más rápido el proceso de búsqueda 40 de algún recurso en específico e incluso se logra cierta interoperabilidad a través del soporte LTI. Sin embargo, las barreras que impiden un uso y distribución más amplio de estos objetos siguen en pie. Es por ello que se desarrollan lineamientos para que los LOR puedan proveer una ayuda al docente en la elaboración de material educativo y no solamente sea usado como una base de datos en donde se guarda y descarga contenido. A medida que más LMS son desarrollados y permiten el uso de más estándares e implementan nuevas funcionalidades, se hace más evidente la necesidad de contar con un LOR que pueda ser integrado de manera poco compleja a cualquier LMS. Además de contar con las funcionalidades básicas de subir, buscar y organizar LO y de poseer la opción de generar metadatos de acuerdo con estándares específicos, este repositorio debe de ser capaz de versionar y compartir contenido, siguiendo las razones mencionadas por Nascimento y Brandao en su propuesta de un modelo de LOR. Debido a que muchas de las investigaciones e implementaciones de LOR realizadas se enfocan en el mapeo y discusión de estándares de metadatos o el nivel de granularidad de los LO. Si bien estos problemas consiguen aumentar, de manera técnica, el grado de reutilización de los LO, Casali, Cechinel y Ochoa (2016) sostienen que una de las razones por las cuales la comunidad educativa no haya adoptado el uso de los LOR’s es porque aún se requiere una gran cantidad de esfuerzo en desarrollar mejores funcionalidades de indexación, búsqueda y reutilización de los LO’s. También se ha notado que los LOR en el mercado son muy similares a nivel de funcionalidad teniendo como diferencia la integración con el LMS que fue desarrollado por el mismo proveedor del repositorio. Se debería lograr un valor agregado no solamente en el uso y distribución de los LO; sino, incluyendo herramientas de apoyo como motores de búsqueda y análisis de datos que puedan ayudar a los docentes a encontrar los LO’s más útiles en base a criterios como la cantidad de descargas, el nivel de utilidad, clasificación de LO, entre otros. Finalmente se debe buscar no solamente el soporte LTI sino también ser capaz de almacenar SCORM debido a su frecuente uso dentro de un LMS y así permitir la migración de este tipo de recurso de un LMS a otro. 41 Capítulo 4. Análisis y diseño del proyecto En este capítulo se desarrollará el primer objetivo específico del proyecto, el cual trata de las fases de análisis y diseño del proyecto de manera que se pueda obtener como resultado la arquitectura del sistema a implementar para que el repositorio pueda cumplir con los siguientes objetivos específicos. 4.1 Análisis En esta sección se presentarán los resultados de la fase de análisis del proyecto. En esta fase se definen los participantes del sistema y lo que se requiere del producto. 4.1.1 Catálogo de requerimientos Para identificar los requerimientos que el proyecto debe cumplir se tomaron en cuenta las características que un Repositorio de Objetos de Aprendizaje debe poseer, así como las que permitan mejorar la accesibilidad, reusabilidad e interoperabilidad de los Objetos de Aprendizaje. Estos requerimientos se encuentran en la Tabla 5. N° Descripción Tipo 1 El sistema deberá contar con autenticación de usuarios por medio de nombre de usuario y contraseña F 2 La autenticación será validada mediante el uso de JWT NF 3 El sistema permitirá el registro de nuevos usuarios F 4 Al momento de registro se deberá proveer el correo electrónico, nombre de usuario y contraseña. F 5 Tanto el correo electrónico como el nombre de usuario deben ser únicos F 6 El sistema podrá permitir la creación de Objetos de Aprendizaje F 7 El usuario deberá proveer los siguientes datos para la creación del objeto: Título, descripción, categorías, una palabra o término clave que describa al objeto, idioma, tipo de recurso, nivel de educación orientado, temas que el objeto enseñará, entidad que usa el objeto y el archivo que contenga el objeto F 8 El sistema deberá registrar de manera interna los siguientes atributos: Fechas de creación y modificación del objeto, autor, identificador único del objeto, su versión más reciente, formato del archivo, tamaño en bytes del archivo y sus fechas de creación y modificación más reciente F 9 El usuario debe poder visualizar todos los atributos del objeto en el momento que accede a la vista detallada de este F 10 Dentro de la vista detallada debe haber la opción de descargar el objeto F 11 Si el autor del objeto o un usuario con permisos de modificador entran a la vista detallada podrán visualizar la opción de modificación del objeto F 42 12 Los usuarios que no tengan permiso de modificación verán la opción de solicitar permisos en lugar del botón de modificación F 13 Para solicitar un permiso el usuario que realiza el pedido debe llenar un formulario en el que indique las razones por las cuales desea modificar el objeto F 14 El usuario debe recibir una notificación cuando se registre un pedido de modificación de algún objeto de su autoría F 15 El usuario podrá visualizar las solicitudes de permisos de modificación que han sido realizadas para los Objetos de Aprendizaje de su autoría F 16 El usuario podrá ver el detalle del pedido que incluye: nombre de usuario y correo electrónico del solicitante y la justificación del pedido F 17 El usuario podrá aprobar o negar los pedidos de modificación que le han sido realizados F 18 Cuando se haya resuelto un pedido el usuario que realizó la solicitud debe recibir una notificación informándole el resultado F 19 El usuario podrá visualizar los permisos que ha otorgado sobre sus Objetos de Aprendizaje F 20 El usuario podrá visualizar los permisos que le han sido otorgados sobre sus Objetos de Aprendizaje F 21 El sistema permitirá manejar dos tipos de versiones: nueva versión y contenido derivado F 22 Se generará una nueva versión cuando se realice algún cambio en el archivo o la URL del objeto, pero no los metadatos F 23 Se generará contenido derivado cuando se realice algún cambio a nivel de metadatos y archivo F 24 El usuario autor de un Objeto de Aprendizaje podrá realizar actualizaciones de los dos tipos F 25 Un usuario modificador solamente podrá generar contenido derivado de un Objeto de Aprendizaje F 26 Para generar una nueva versión el usuario subirá un nuevo archivo o URL y deberá especificar cuáles son los cambios que han sido realizados F 27 Para generar contenido derivado el sistema mostrará un formulario con todos los atributos a cambiar F 28 El usuario debe modificar el formulario de atributos del objeto al momento de realizar una modificación, también debe especificar qué cambios se están realizando F 29 El formulario de atributos de modificación debe estar pre cargado con los atributos actuales del Objeto de Aprendizaje F 30 El sistema generará un nuevo Id de versión para el objeto modificado y lo guardará como una entidad diferente F 31 El sistema mantendrá un registro de todas las versiones del Objeto de Aprendizaje y cuál es la versión más reciente F 32 Siempre se mostrará la versión más reciente de un objeto al acceder a su vista detallada F 43 33 El usuario podrá elegir que versión del Objeto de Aprendizaje desea ver en la vista detallada F 34 Si algún Objeto de Aprendizaje ha sido derivado de otro se hará referencia de esto en la pantalla de detalle de objeto F 35 El sistema contará con una barra de búsqueda en la cual el usuario escribirá un término que será buscado de entre todos los atributos de los Objetos almacenados en el repositorio F 36 El sistema contará con una funcionalidad de búsqueda avanzada en la cual podrá especificar los valores específicos de cada atributo de los objetos dentro del repositorio F 37 El usuario podrá visualizar una lista de los objetos que ha creado o que tiene acceso pudiéndolos filtrar por título, descripción, categoría y fechas de creación y modificación y la utilidad percibida por los usuarios F 38 Dentro de la vista del detalle de un Objeto de Aprendizaje existirá una opción que brindará las instrucciones a seguir en caso se desee usar el objeto dentro de un LMS F 39 La modificación de un Objeto de Aprendizaje debe reflejarse en los LMS en los que está siendo utilizado F 40 El sistema podrá mostrar una lista de todos los Objetos de Aprendizaje almacenados en el repositorio pudiéndolos ordenar por fecha de creación, fecha de modificación y valoración de usuarios F 41 El sistema podrá filtrar la lista de objetos según sus características como: Tipo de recurso, nivel de educación y categorías F 42 El sistema podrá mostrar una lista de todos los usuarios que contribuyen al repositorio pudiéndolos filtrar por orden alfabético F 43 El sistema podrá mostrar una lista de todos los Objetos de Aprendizaje subidos por un autor en específico F 44 El componente front end del sistema será desarrollado en AngularJS 7 N. F 45 El componente back end del sistema será desarrollado en NodeJS usando el framework Express N. F 46 Se contará con una base de datos MySQL para alojar los datos de los usuarios, Objetos de Aprendizaje, versiones y permisos N. F 47 Se utilizará Amazon S3 para alojar los archivos que serán guardados en el repositorio N. F 48 Se utilizará Apache Solr como el motor de búsqueda de los objetos almacenados N. F 49 Cada Objeto de Aprendizaje en el repositorio tendrá un botón que permitirá guardar feedback del usuario F 50 El feedback se recibirá de la siguiente manera: si al usuario siente que el objeto es útil marcará el botón caso contrario no realizará ninguna acción F 51 Al momento de realizar una búsqueda se priorizarán los objetos que sean percibidos como útiles por la mayor parte de usuarios F 52 La contraseña tendrá como mínimo 8 caracteres y debe contar con números y símbolos N. F 53 Para almacenar la contraseña en la base de datos se deberá usar algún tipo N. F 44 Tabla 5. Requerimientos funcionales y no funcionales 4.1.2 Descripción de los actores Se han identificado los siguientes actores los cuales interactuarán con el sistema (Ver figura 5): Figura 5. Identificación de usuarios.  Usuario: Toda persona que interactúa con el sistema.  Usuario no logueado: Usuario que ingresa al sistema sin estar logueado o registrado.  Usuario logueado: Usuario que se ha logueado exitosamente al sistema.  Modificador: Tipo de usuario logueado que tiene permisos de generación de contenido derivado de un Objeto de Aprendizaje  Autor: Tipo de usuario modificador que además puede generar nuevas versiones de un Objeto de Aprendizaje, crear un nuevo objeto y otorgar permisos de modificación sobre objetos de su autoría.  LMS: Sistema de Gestión del Aprendizaje sobre el cual se realizará la integración mediante el uso de protocolos 4.1.3 Diagramas de casos de uso A continuación, se definen los casos de uso para el sistema, que son una referencia de las acciones que los actores del sistema pueden realizar. La especificación completa de los casos de uso se encuentra en el Anexo B. de encriptación 54 El componente front end del sistema debe poder ser utilizado en la versión 73 de Google Chrome N. F 45  Ingreso al repositorio Figura 6. Ingreso al repositorio  Acceder al contenido Figura 7. Acceder al contenido 46  Creación y distribución de Objetos de Aprendizaje Figura 8. Creación y distribución de Objetos de Aprendizaje.  Interoperabilidad con Sistemas de Gestión de Aprendizaje Figura 9. Interoperabilidad con Sistemas de Gestión de Aprendizaje 47 4.2 Diseño La Arquitectura a utilizar será web. Se tendrán dos proyectos, uno de front end en AngularJS y un back end en NodeJS. Estos sistemas estarán apoyados por una base de datos MySQL, una instancia del motor de búsqueda Apache Solr y Amazon S3 en donde estarán alojados los archivos guardados. La Figura 10 nos muestra en forma de esquema esta arquitectura. Figura 10. Esquema de la arquitectura. 4.2.1 Vista de proceso Esta vista toma en cuenta algunos requerimientos no funcionales del sistema y como las abstracciones principales de la vista lógica encajan dentro de los procesos del sistema. Se han elaborado diagramas de actividades para los siguientes casos:  Login y registro.  Creación de Objetos de aprendizaje.  Solicitar permisos de modificación de Objetos de Aprendizaje.  Realizar búsquedas de Objetos de Aprendizaje.  Modificación de Objetos de Aprendizaje. Estos diagramas se encuentran en el Anexo C. 48 4.2.2 Vista lógica Esta vista muestra la estructura que tendrá el sistema para cumplir con las funcionalidades requeridas. Se muestra el diagrama entidad – relación que usará la base de datos en la figura 11 y el diagrama de clases de análisis en la figura 12. El diccionario de datos respectivo se encuentra en el Anexo I Figura 11. Diagrama entidad relación. 49 Figura 12. Diagrama de clases de análisis. Nombre de clase Descripción User Usuario del repositorio Author Tipo de usuario, autor de un Objeto de Aprendizaje Modifier Tipo de usuario autor, con permisos de creación de objetos derivados LearningObjetct Objeto de Aprendizaje Version Versión de un Objeto de Aprendizaje Derivated Objeto de Aprendizaje derivado de una versión específica de otro objeto Permit Solicitud de permiso de modificación sobre un objeto 50 ResourceType Tipo de recurso de un Objeto de Aprendizaje EducationType Nivel de educación recomendado para un Objeto de Aprendizaje Category Categoría de un Objeto de Aprendizaje UsefulCount Evento “me parece útil” de un Objeto de Aprendizaje LTIprovider Clase con los parámetros necesarios para una conexión mediante LTI 4.2.3 Vista de desarrollo Esta vista se enfoca en la organización real por módulos del sistema en el ambiente de desarrollo. Muestra la organización por capas de estos componentes, así como la comunicación entre estos. Se realizaron diagramas de componentes para representar el front end y back end del sistema los cuales se muestran en las Figuras 13, 14 y 15 con el detalle de sus componentes en las Tablas 6, 7 y 8. 51 Figura 13. Diagrama de componentes del Front end Componente Descripción Node_modules Librerías y paquetes que serán usados en todo el proyecto Angular_material Paquete que provee componentes de Material Design para la interfaz gráfica _components Pequeños componentes que pueden ser reutilizados como: Dialogos, listas y alertas _services Carpeta en donde se encuentran los archivos que llaman los API REST del backend _guards Carpeta en donde se encuentran archivos de guardia de permisos 52 _helpers Interceptadores de las llamadas al backend que agregan información adicional a los requests y responses de los APIs _models Carpeta en donde se encuentra el modelo de las clases que serán usadas por el sistema Authentication Componentes de autenticación. Incluye el login y el registro de usuarios Search Componentes de búsqueda de Objetos de Aprendizaje Pages Diversas páginas del sistema LOManagement Componentes relacionados a la gestión de Objetos de Aprendizaje. Incluyen la creación y modificación de objetos y solicitudes de permisos Tabla 6. Componentes de la capa front end Figura 14. Diagrama de componentes del Back end. Componente Descripción Node_modules Librerías y paquetes que serán usados en todo el proyecto Src Componentes particulares del sistema Config Carpeta donde se encuentran los archivos de configuración general del proyecto 53 Session Componente que maneja las sesiones de los usuarios del sistema Controller Carpeta que contiene la lógica del negocio del sistema Routes Carpeta que contiene la definición de los APIs y sus rutas respectivas entities Entidades que serán usadas por el sistema y sus respectivas conexiones con la base de datos, Solr y S3 Apache Solr Motor de búsqueda usado por el sistema Amazon S3 bucket Servicio de Amazon que permite guardar archivos Oauth Componente que permite proteger las comunicaciones entre los Sistemas de Gestión de Aprendizaje y el repositorio mediante el estándar Oauth Tabla 7. Componentes de la capa back end Figura 15. Diagrama de componentes de back end – detalle de la integración vía LTI. Componente Descripción Routes Carpeta que contiene la definición de los APIs y sus rutas respectivas LtiExport Componentes particulares del sistema 54 Controller Carpeta que contiene la lógica del negocio del sistema LtiControler Lógica de implementación del protocolo LTI LoController Lógica de funcionalidades relacionadas a creación, actualización y descarga de Objetos de Aprendizaje Entities Entidades que serán usadas por el sistema y sus respectivas conexiones con la base de datos, Solr y S3 LtiProvider Clase que contiene los parámetros necesarios para utilizar el protocolo LTI y comunicar datos con los Sistemas de Gestión de Aprendizaje LearningObject Clase que contiene los atributos de un Objeto de Aprendizaje Oauth Componente que permite proteger las comunicaciones entre los Sistemas de Gestión de Aprendizaje y el repositorio mediante el estándar Oauth Tabla 8. Componentes de la capa back end – detalle de la integración vía LTI 4.2.4 Vista física Esta vista muestra la topología de los componentes del sistema y como se conectan físicamente. El diagrama de despliegue se muestra en la figura 16 y se detalla en la tabla 9. De ser necesario la solución se podrá clusterizar, cada artefacto puede ser desplegado en un servidor diferente. Además, se podrá escalar por duplicación contando con un servidor con una copia de los proyectos de front y back end, así como un balanceador de carga que se encargará de distribuir el tráfico web entre los servidores. 55 Figura 16. Diagrama de componentes. Nodo Descripción Client Navegador web utilizado por el usuario para acceder a la plataforma Server Elemento encargado de alojar y ejecutar los proyectos front end y back end del sistema Front end project Interfaz gráfica del sistema Back end project Proyecto que contiene toda la lógica del negocio del sistema Apache Solr Motor de búsqueda de documentos MySql database Base de datos de tipo MySQL AWS S3 Servicio de almacenamiento de archivos provisto por Amazon Web Service Tabla 9. Detalle de nodos y artefactos del diagrama de componentes 56 4.3 Diseño de pantallas 4.3.1 Creación de Objetos de Aprendizaje Mediante la opción “Nuevo objeto” del menú el usuario del repositorio podrá crear un Objeto de Aprendizaje llenando el formulario que aparecerá en pantalla (Figura 17). Se podrán subir Objetos de Aprendizaje de dos tipos: archivo y URL. En caso se trate de una URL el usuario deberá validar que esta dirección exista usando el botón correspondiente (Figura 18). Si el objeto es de tipo archivo se lo deberá subir con el uso de un botón (Figura 19). Luego, el usuario deberá llenar los campos especificados como “Ingresados por el usuario” indicados por la especificación de metadatos de Objetos de Aprendizaje definidos en la Tabla 10. Para llenar los campos “Categorías”, “Nivel de aprendizaje”, “Tipo de recurso” y “Lenguaje” se elegirá de una serie de términos ya definidos por el sistema. Al momento de hacer clic al botón “Crear objeto” se verificará que todos los campos hayan sido completados, de ser así el caso se creará el objeto y se mostrará la pantalla de detalle de objeto 57 Figura 17. Formulario de creación de Objeto de Aprendizaje. Figura 18. Validación de URL 58 Figura 19. Creación de objeto de tipo archivo. 4.3.2 Visualización de detalle del objeto Todo Objeto de Aprendizaje cuenta con una vista en la que se pueden ver: los metadatos, el autor y las versiones pasadas, así como acceder a la URL o descargar el objeto (Ver figura 20). Figura 20. Vista de detalle de Objeto de Aprendizaje. 59 4.3.3 Visualización de lista de objetos creados por el usuario Mediante la opción “Mis objetos” del menú el usuario podrá visualizar una lista de los objetos que ha creado (Figura 21). Figura 21. Lista de objetos de usuario. 4.3.4 Visualizaciones de pedidos de modificación Cuando un usuario reciba una solicitud de permiso de modificación de un objeto, el usuario autor la podrá revisar ingresando a la opción “Permisos” del menú, en esta pantalla el usuario podrá ver sus solicitudes pendientes (Figura 22), las solicitudes que ha aprobado (Figura 23). Allí podrá aprobar o negar la solicitud de modificación. En caso de aprobarse el pedido el usuario que lo solicitó podrá ver la opción “Modificar” en la pantalla de detalle del objeto. Figura 22. Lista de solicitudes pendientes de aprobación. 60 Figura 23. Lista de solicitudes aprobadas 4.3.5 Creación de nuevas versiones de Objetos de Aprendizaje En la pantalla de detalle del objeto el usuario autor podrá acceder a la opción “Modificar”, luego aparecerá un modal que le permitirá elegir entre dos opciones: “Nueva versión” si es que se desea actualizar el contenido de un Objeto de Aprendizaje, pero no los metadatos y la opción “Derivar contenido” cuando se quiera crear un objeto cuyo contenido está basado en otro existente. Si se eligió la opción “Nueva versión” se redirigirá a una pantalla en la cual se especificará una nueva URL o subirá un nuevo archivo, así como los cambios realizados en la nueva versión (Figura 24). Una vez que se cree la nueva versión, ésta es la que se mostrará en la página de detalle del objeto, pudiendo acceder a las versiones pasadas con la opción “Ver todas las versiones” (Figura 25). Figura 24. Diagrama de componentes. 61 Figura 25. Versiones de un Objeto de Aprendizaje 4.3.6 Generación de contenido derivado Si se eligió la opción “Derivar contenido” el usuario autor o con permisos de modificador podrá generar contenido basado en un objeto existente. El sistema redirigirá al usuario a una pantalla similar a la de creación de Objetos de Aprendizaje (Figura 26) en donde se llenarán los mismos campos además de especificar la razón de la derivación del objeto. Luego de crear la versión derivada, en la pantalla de detalle del objeto se podrá observar un indicador mostrando que es contenido derivado junto a un botón que redirigirá al usuario a la pantalla de detalle del objeto padre (Figura 27). 62 Figura 26. Formulario de generación de contenido derivado Figura 27. Indicador de Objeto derivado. 4.3.7 Búsqueda simple de Objetos de Aprendizaje En la barra de menú se encuentra una caja de texto (Figura 28) en la cual el usuario puede ingresar una o varias palabras para encontrar el Objeto de Aprendizaje que desee. El motor de búsqueda buscará el o los términos ingresados entre los campos Título, Descripción, Categoría y Palabra clave de los objetos indexados por el Apache Solr y mostrará lo que encuentre en orden descendiente según la cantidad de valoraciones de usuarios. 63 Figura 28. Barra de búsqueda simple 4.3.8 Búsqueda avanzada de Objetos de Aprendizaje Con la opción “Búsqueda avanzada” del menú se mostrará un formulario conteniendo campos que el usuario debe llenar los cuales hacen referencia a los metadatos de un Objeto de Aprendizaje (Figura 29). El sistema, como en la búsqueda simple, quitará los stopwords (Palabras sin significado como artículos, preposiciones o pronombres) y buscará los objetos que contengan las características especificadas. Adicionalmente, si el usuario lo requiere podrá acceder a más opciones de búsqueda pudiendo especificar palabras o valores a excluir de entre los campos de los metadatos. También se podrán armar estructuras condicionales de búsqueda (Ej: “Si es que se encuentran objetos del autor X buscar que estén en español). Figura 29. Formulario de búsqueda avanzada 64 65 Capítulo 5. Esquema de metadatos a utilizar En este capítulo se definirá el esquema de metadatos con los que contará un Objeto de Aprendizaje que será almacenado en el repositorio de manera que se logre el Objetivo Específico 2. Para conseguir la accesibilidad y reutilización de los Objetos de Aprendizaje es necesario que estos posean metadatos que faciliten su clasificación y su capacidad de ser encontrados dentro del repositorio. Para la definición de los metadatos que usarán los Objetos de Aprendizaje creados usando el Repositorio de Objetos de Aprendizaje se extenderán ciertos elementos del DCMI-EMS (Dublin Core Metadata Initiative – Education Metadata Set) tomando como referencia los estándares de metadatos de Objetos de Aprendizaje propuestos por la IEEE. 5.1 Atributos del DCMI-EMS y IEEE-LOM El estándar de Dublin Core contiene quince elementos (DCMI). Sus nombres y descripciones se encuentran en la tabla 10. Estos metadatos contienen elementos útiles para uso general pero no posee atributos específicos para la perspectiva pedagógica. Nombre Descripción Title Nombre dado al recurso Subject Tema, palabra clave del recurso Description Descripción del recurso Type Naturaleza o género del recurso Source Recurso de donde se deriva el recurso subido Relation Recurso relacionado Coverage El tema o aplicación espacial o temporal que abarca el recurso Creator Entidad responsable de la elaboración del recurso Publisher Entidad responsable por publicar el recurso 66 Contributor Entidad responsable por hacer contribuciones al recurso Rights Información sobre los derechos a los cuales el recurso está sujeto Date Punto o periodo de tiempo asociado con un evento en el ciclo de vida del recurso Format El formato de archivo, medio físico o dimensiones del recurso Identifier Referencia que no presente ambigüedad perteneciente únicamente a un recurso Language Lenguaje del recurso Tabla 10. Estándar de metadatos de Objetos de Aprendizaje Dublin Core El estándar propuesto por la IEEE tiene como propósito el facilitar la búsqueda, evaluación, adquisición y el uso de los Objetos de Aprendizaje. Se especifica un esquema conceptual de data que puede ser extendido según se requiera. Es por esta razón que este estándar facilita la distribución y el intercambio de los LO’s al habilitar el desarrollo de catálogos e inventarios y al mismo tiempo tomar en cuenta la diversidad cultural y de lengua que el Objeto de Aprendizaje pueda poseer. La imagen 1 muestra las categorías básicas definidas por el estándar. Se puede observar que se cuentan con varias categorías específicas para temas pedagógicos y técnicos (IEEE, 2002). 5.2 Definición del esquema de metadatos a utilizar en el repositorio En un estudio realizado por Devshri, Sudeshna y Sujoy (2010) donde se realizó una comparación entre los esquemas de metadatos de Objetos de Aprendizaje usados en 9 repositorios existentes, 8 de ellos utilizan el estándar propuesto por la IEEE. Por este motivo también se utilizará este estándar como base para definir el esquema de metadatos que usará el Repositorio de Objetos de Aprendizaje que será desarrollado como proyecto de fin de carrera. Ya que no se utilizarán todas las categorías definidas por el estándar se mostrará el detalle del esquema en la tabla 11. 67 Id Nombre Etiqueta Descripción Observaciones 1 General 1.1 Identificador Id Identificador único del objeto Número entero 1.2 Titulo Title Título dado al objeto Cadena de caracteres 1.3 Idioma Language Idioma en el que el objeto se encuentra Se utilizarán los códigos establecidos por la ISO 639 1.4 Descripción Description Descripción de lo que trata el objeto Cadena de caracteres 2 Ciclo de vida 2.1 Versión version Ubicación del objeto Cadena de caracteres 2.2 Estado filename Identificador de la versión del objeto Cadena generada automáticamente 2.3 Id del autor authorId Identificador del autor del objeto Número entero 2.4 Id del modificador modifierId Identificador del autor del objeto Número entero 2.5 Fecha de creación created Fecha de creación del objeto 2.6 Fecha de modificación updated Última fecha de modificación del objeto 2.7 Id del objeto padre fatherId Identificador del objeto del cual Número entero 3 Técnico 3.1 Formato format Formato o mimetype del archivo guardado Si el objeto es una colección de archivos comprimido en formato zip se guardará como formato zip 3.2 Tamaño size Tamaño del archivo En bytes 3.3 Localización location Localización del objeto 3.4 Key key Identificador del objeto en el bucket de AWS S3 Cadena generada automáticamente por S3 3.5 Nombre de filename Nombre del Cadena de caracteres 68 archivo archivo del objeto subido 4 Clasificación 4.1 Categoría category Categorías pertenecientes al objeto Arreglo de palabras clave relacionadas al objeto. Se utilizarán las categorías del Tesauro de la UNESCO (http://vocabularies.unesco.org/browser/thesaurus/en/groups) 4.2 Palabra clave keyword Palabra que describe el tema central del objeto 5 Educacionales 5.1 Tipo de recurso resourceType Tipo de recurso educacional Ej: Test, libro de texto, material de referencia, etc. 5.2 Nivel de educación educationType Nivel de educación a la que el objeto está orientado EJ: primaria, secundaria, etc. 5.3 Usado por usedBy Organización, persona o entidad para la cual fue creado el objeto 5.4 Usado para usedFor Uso que se le dará al objeto Por ejemplo, sobre qué temas el objeto enseñará Tabla 11. Estándar de metadatos propuesto para el Repositorios de Objetos de Aprendizaje a desarrollar. http://vocabularies.unesco.org/browser/thesaurus/en/groups 69 Capítulo 6. Implementación del proyecto Siguiendo la metodología propuesta, se dividió la fase de implementación por iteraciones, cada una cuenta con una etapa de revisión de la pila de producto, desarrollo y control de los entregables y riesgos presentes en el proyecto, así como el cumplimiento de los Objetivos Específicos restantes. A continuación, se relatarán los acontecimientos ocurridos en cada iteración. 6.1 Iteración 0 En esta iteración se realizaron:  Etapa de análisis del sistema: Se identificaron los actores y sus casos de uso para luego poder especificar los requisitos funcionales y no funcionales.  Etapa de diseño del sistema: Siguiendo el modelo de vistas arquitectónicas “4 + 1” se elaboró el documento de arquitectura con diagramas a alto nivel que serán detallados en las siguientes iteraciones. En esta iteración se obtuvo el Resultado esperado 1, el documento de arquitectura. Con respecto a la gestión de riesgos, en esta iteración no se presentaron problemas debido a que la carga académica aún era leve ya que la iteración ocurrió a inicios del ciclo de estudios de la universidad así que se pudieron cumplir con los tiempos propuestos en el cronograma de entregables. 6.2 Iteración 1 En esta iteración se realizaron:  Correcciones de los documentos de análisis y diseño en base a los comentarios recibidos en la iteración 0.  Configuración de entornos de desarrollo: se crearon repositorios en GitHub para los proyectos de front y back end, se configuró una cuenta gratuita en Amazon Web Services para comenzar a utilizar el servicio de alojamiento de archivos S3, se creó una base de datos MySql y finalmente se configuró el motor de búsqueda Apache Solr (Resultado esperado 2). 70  Elaboración de documento de estructura de metadatos: se realizó una investigación para definir la estructura de metadatos que tendrán los objetos almacenados en el repositorio. Esta estructura fue sometida a un juicio de expertos (Resultado esperado 3).  Implementación de la funcionalidad de creación de Objetos de Aprendizaje  Validaciones funcionales para la creación de Objetos de Aprendizaje (Resultado esperado 4). Si bien la configuración del Solr estaba planeada para la iteración 3 se identificó que podía ser realizada en esta etapa sin afectar el cronograma planteado. Sin embargo, se detectó que el riesgo R05 podría convertirse en problema siguiendo la arquitectura planeada ya que se identificó que la curva de aprendizaje de React era elevada y causaría retrasos en los tiempos propuestos. Por ello se decidió que el proyecto front end sería implementado con Angular 7 dado que su curva de aprendizaje era menor. Para esta iteración hubo un retraso en el cronograma debido a que se tardó en encontrar a los expertos que validarían el documento de estructura de metadatos. Ello generó un nuevo riesgo: Retraso causado por la búsqueda de expertos que validarán los documentos. Este riesgo fue añadido a la matriz de riesgos que está ubicada en el anexo A 6.3 Iteración 2 En esta iteración se realizaron:  Implementación del módulo de control de versiones y modificación de Objetos de Aprendizaje: Con el apoyo diagramas de actividad del documento de diseño se implementaron las dos formas de modificación de un Objeto de Aprendizaje: creación de nueva versión y derivación de contenido (Resultado esperado 5).  Implementación de funcionalidad de otorgar permisos de creación de contenido derivado a otros usuarios (Resultado esperado 6).  Pruebas de validación de las funcionalidades implementadas. Para esta iteración, sí se cumplieron los tiempos del cronograma debido a que se pudo encontrar con facilidad a un docente que pueda realizar las pruebas de validación de software. No se activaron ni aparecieron nuevos riesgos en esta iteración. Aún se 71 presentan dificultades con respecto a la implementación de interfaces gráficas en el proyecto de front end, sin embargo, no son lo suficientemente graves para ocasionar retrasos. 6.4 Iteración 3 En esta iteración se realizó:  Investigación sobre la sintaxis de búsqueda del Apache Solr.  Implementación de funcionalidad que permite a un usuario indicar si un Objeto de Aprendizaje dentro del repositorio le parece útil (Resultado esperado 8).  Implementación de funcionalidad de búsqueda simple (Resultado esperado 7).  Implementación parcial de la búsqueda avanzada de objetos (Resultado esperado 7).  Correcciones en el documento de arquitectura del sistema Para esta iteración se activó el riesgo R02 que trata sobre retrasos causados por estimaciones de esfuerzo incorrectamente realizadas. La funcionalidad de búsqueda avanzada abarcaba más casos de los que se consideró actualmente pero que serán desarrollados en la iteración 4. 6.5 Iteración 4 Esta iteración duró dos semanas. En la primera se realizaron:  Culminación de la implementación de la funcionalidad de búsqueda avanzada (Resultado esperado 7).  Pruebas de precisión y exhaustividad de búsquedas.  Pruebas de validación funcional de usuarios. Como se indicó en el punto 6.4, la búsqueda avanzada contemplaba más casos, específicamente la exclusión de términos y la utilización de cláusulas condicionales. Para verificar la funcionalidad de búsqueda de objetos se realizó una prueba de precisión y exhaustividad cuyo diseño y resultados se encuentran en el Anexo D. Debido a que se había considerado cierto tiempo de holgura dentro del desarrollo del 72 proyecto, la implementación de estas funcionalidades inicialmente no consideradas no llegó a causar retrasos considerables en el cronograma planteado. Además, en esta iteración se logró obtener los resultados faltantes del juicio de expertos de la iteración 1. En la segunda semana se realizaron:  Definición de los métodos de integración del repositorio con los Sistemas de Gestión de Aprendizaje (Resultados esperados 9 y 11).  Selección de los Sistemas de Gestión de Aprendizaje en los que se realizarán las pruebas de integración.  Implementación de los métodos de integración (Resultados esperados 10 y 12).  Ejecución de pruebas de integración (Anexo H). Se actualizaron los diagramas de componentes, clases de análisis, actividades y secuencia como resultado del proceso de definición de los métodos de integración. Luego de esto se realizó una investigación de los Sistemas de Gestión de Aprendizaje que serán utilizados para las pruebas de integración y se eligieron los siguientes: Moodle, Sakai y Canvas, esto se debe a su porcentaje de uso en el mercado, actualización frecuente y que poseen plataformas de demostración del sistema en línea. Finalmente se ejecutaron pruebas de integración que verificaron la interoperabilidad y la comunicación de datos entre el repositorio y los entornos de prueba. 73 Capítulo 7. Conclusiones y trabajos futuros 7.1 Conclusiones En esta sección se presentarán las conclusiones obtenidas al conseguir los resultados esperados de los objetivos específicos, así como las conclusiones generales del proyecto. El primer Objetivo Específico era realizar el análisis y diseño de un Repositorio de Objetos de Aprendizaje de manera que se puedan desarrollar funcionalidades que permitan que los objetos almacenados puedan ser accedidos, compartidos y clasificados. En base a la arquitectura diseñada resultante de las fases de análisis y diseño, se consiguió implementar un Repositorio de Objetos de Aprendizaje Web compuesto por una capa Front end escrita en Angular Js y una capa Back end en Node Js. Una vez implementado el repositorio se procedió a desarrollar la funcionalidad de creación de Objetos de Aprendizaje, de acuerdo con el Objetivo Específico 2, se definió el esquema de metadatos de los Objetos de Aprendizaje que se almacenarán en el repositorio, los campos de este esquema fueron planteados con el objetivo de hacer que el proceso de creación de un Objeto de Aprendizaje sea simple y no requiera conocimientos técnicos por parte del usuario además de proveer una forma de clasificar a los objetos de manera que los usuarios puedan encontrar los recursos que les interesen. Este esquema fue validado por un grupo de expertos a través de un cuestionario. Los resultados se encuentran en el Anexo E. Con el esquema definido y validado se procedió a implementar la funcionalidad de creación de un Objeto de Aprendizaje utilizando el repositorio, esta funcionalidad fue sometida a una prueba de validación. Para que los objetos almacenados en el repositorio puedan ser mejor utilizados el usuario debe poder observar que los recursos sean frecuentemente actualizados. Para esto, el Objetivo Específico 3 trata sobre la implementación de funcionalidades que permitan: actualizar la versión de un objeto de su autoría y generar contenido derivado a partir de un objeto ya existente. Las funcionalidades respectivas a este módulo fueron implementadas y validadas con un director de una escuela privada que es un potencial usuario del sistema. 74 Además de versionar contenido, como se indica en el Objetivo Específico 4 se desarrollaron funcionalidades de búsqueda para que los usuarios puedan encontrar los Objetos de Aprendizaje que más sean de su interés y así mejorar la accesibilidad de estos. Se implementaron dos funcionalidades para la búsqueda: simple y avanzada, esto permitirá que el usuario encuentre los objetos más relevantes según la cadena de búsqueda que ingrese. Estas funcionalidades fueron sometidas a una prueba de precisión y exhaustividad que indicaron la precisión de las búsquedas y la capacidad que tienen para ser mejoradas. Finalmente, para lograr que el Repositorio de Objetos de Aprendizaje cumpla con la interoperabilidad se cumplió con el Objetivo Específico 5 que trata de la definición e implementación de funcionalidades de integración entre el repositorio y los Sistemas de Gestión de Aprendizaje. Mediante el uso del protocolo LTI se consiguió que los objetos del repositorio puedan ser utilizados en múltiples Sistemas de Gestión de Aprendizaje, se implementaron dos formas de exportación: última versión del objeto y versión específica, se verificó mediante pruebas de integración que los objetos del repositorio puedan ser subidos a entornos de prueba y puedan ser accedidos correctamente, además de poder verificar el correcto envío de información entre el Objeto de Aprendizaje y los entornos de prueba en el caso de que se tratase de un recurso interactivo. En base a los resultados obtenidos se concluye que, el repositorio de Objetos de Aprendizaje cumple con las siguientes características:  Accesibilidad: Los Objetos de Aprendizaje almacenados dentro del repositorio son clasificados mediante un esquema de metadatos que permite que los recursos sean referenciados correctamente por el usuario.  Reusabilidad: Las funcionalidades de control de versiones, generación de contenido derivado y los varios tipos de búsquedas permite que los usuarios encuentren los objetos que más les interesen y puedan darse cuenta si siguen siendo actualizados lo que incentiva a que los recursos almacenados se usen con frecuencia.  Interoperabilidad: Mediante el protocolo LTI se pueden distribuir los objetos almacenados a los Sistemas de Gestión de Aprendizaje además de poder comunicar datos entre estos sistemas y el Objeto de Aprendizaje caso exista algún tipo de interacción por parte del usuario. 75 7.2 Trabajos futuros Se proponen los siguientes trabajos futuros que podrán extender las capacidades del repositorio y de esta forma aumentar su utilidad:  Implementación y uso de herramientas de aprendizaje de máquina que permita extraer de forma automática los metadatos de un Objeto de Aprendizaje al momento de ser subidos por el usuario.  Implementación de funcionalidad para poder registrar derechos de autor de material e incluir mecanismos que prevengan que no se infrinjan estos derechos.  Implementación de herramienta de creación de contenido dentro del repositorio en el cual un usuario pueda diseñar Objetos de Aprendizaje interactivos (Exámenes y encuestas) dentro del repositorio y exportarlos utilizando el protocolo LTI . Referencias Abdelbasset R., Larbi S., Akhrouf S. & Yahia B. (2015). "Dihya: An Intelligent Learning Object Repository," 2015 International Conference on Interactive Mobile Communication Technologies and Learning (IMCL), Thessaloniki, pp. 154-159 ADL Advanced Distributed Learning (2002). “Emerging and Enabling Technologies for the design of Learning Object Repositories Report”. http://xml.coverpages.org/ADLRepositoryTIR.pdf Apache Solr (n.d.). Solr Features. Recuperado de http://lucene.apache.org/solr/features.html Basic Overview of how LTI works (n.d.). Recuperado de http://www.imsglobal.org/basic-overview-how-lti-works Bates, T. (2000). Managing technological change: strategies for college and university leaders. Jossey-Bass Bieliuskas Y. (2015). ROACAA: Un Repositorio de Objetos de Aprendizaje de Contenidos Abiertos Accesibles “Para todas y todos”. Presentado en la décima Conferencia Latinoamericana de Objetos y Tecnologías de Aprendizaje. Recuperado a partir de: http://www.br- ie.org/pub/index.php/teste/article/view/5820/4110 http://xml.coverpages.org/ADLRepositoryTIR.pdf 76 Blackboard Open Content (n.d.) About Blackboard Open Content .Recuperado de https://help.blackboard.com/es- es/Blackboard_Open_Content/Administrator/About_Blackboard_Open_Content Blackboard Open Content (n.d.) Recuperado de https://help.blackboard.com/es- es/Learn/Administrator/Hosting/Course_Management/Blackboard_Open_Conte nt Brightspace Learning Repository (n.d.). Recuperado de https://www.d2l.com/es/productos/learning-repository/ Bozkurt, A., & Hilbelink, A. (2019). Paradigm Shifts in Global Higher Education and e- learning: An ecological perspective: Special Issue: Paradigm shifts in global higher education and e-learning. eLearn, 2019(5), 1 Casali A., Cechinel C. & Ochoa X., "Special Issue on Strategies to Improve the Usability of Learning Object Repositories," in IEEE Revista Iberoamericana de Tecnologias del Aprendizaje, vol. 11, no. 2, pp. 71-72, May 2016. Canvas (n.d.). ¿Qué es Canvas Commons? Recuperado de https://es.guides.instructure.com/m/54832/l/507482-que-es-canvas-commons Cockburn, Alistair. (2004). Crystal clear a human-powered methodology for small teams. Contenidos para aprender (2018). Recuperado de http://aprende.colombiaaprende.edu.co/node/121165 Creative Commons. (2018). Frequently Asked Questions. Recuperado de: https://creativecommons.org/faq/ Del Moral E., Cernea A. & Villalustre L. (2013) Connectivist Learning Objects and Learning Styles Interdisciplinary Journal of E-Learning and Learning Objects Volume 9, 2013 105-124 Del Moral, M. E., & Cernea, A. (2005). Design and evaluate learning objects in the new framework of the semantic web. In A. Méndez-Vilas, B. González-Pereira, J. Mesa González, & J. A. Mesa González (Eds.), Recent research developments in learning technologies, pp.1032- 1036. Dirección Académica de Informática, Pontificia Universidad Católica del Perú (n.d.). Propuesta psicopedagógica que sustenta el desarrollo de los Objetos de Aprendizaje Reusables en la PUCP. Downes, S. (2001). Learning Objects: Resources For Distance Education Worldwide. The International Review Of Research In Open And Distributed Learning, 2(1). doi:http://dx.doi.org/10.19173/irrodl.v2i1.32 https://www.d2l.com/es/productos/learning-repository/ http://aprende.colombiaaprende.edu.co/node/121165 http://dx.doi.org/10.19173/irrodl.v2i1.32 77 Google. (n.d.) AngularJS. Extraído de: https://angularjs.org/ Git (n.d.). About. https://git-scm.com/about Govindansamy T. (2002) Successful implementation of e-Learning Pedagogical considerations Internet and Higher Education 4 (2002) 287–299 Grace, T.P.L., Suan, N.P. & Wanzhen L. (2008). An evaluation of learning objects in Singapore primary education: a case study approach. Interactive Technology and Smart Education 5 (4), 244–256 Heery, R., & Anderson, S. (2005). Digital Repositories Review. Joint Information Committee. University of Bath. http://www.jisc.ac.uk/uploaded_documents/digital-repositories-review-2005.pdf Ibrahim A., Yasien M. (2016). The impact of learning object repository (LOR) in the development of pattern making skills of home economics students. Bristish Journal of Education. 2016 vol: 4 (2) pp: 87-99 IEEE Standard for Learning Object Metadata," in IEEE Std 1484.12.1-2002 , vol., no., pp.1-40, 6 Sept. 2002. doi: 10.1109/IEEESTD.2002.94128 JetBrains (n.d.). Making development an enjoyable experience. Recuperado de https://www.jetbrains.com/idea/features/ Krutchen, P (1995). “Architectural Blueprints – The “4+1” View Model of Software Architecture”, IEEE Software 12, November 1995, pp. 42-50. Lehman, R. (2007). "Learning object repositories", New Directions for Adult and Continuing Education, vol. 2007, no. 113, pp. 57-66, 2007. López A. C. J., López Morteo G., Flores-Rios B. L. & García L. C., "Processes Reference Model for Interoperability in Learning Object Environments," 2017 5th International Conference in Software Engineering Research and Innovation (CONISOFT), Mérida, 2017, pp. 81-88. Matkin G. (2002). Learning Object Repositories: Problems and Promise. Recuperado de unex.uci.edu/distance/seminar/more_info/Hewlett_postseminar_report.pdf el día 2018-11-09. Moodle (n.d.). Acerca de Moodle. Recuperado de https://docs.moodle.org/all/es/Acerca_de_Moodle Mozilla (n.d.). Acerca de JavaScript. Recuperado de https://developer.mozilla.org/es/docs/Web/JavaScript/Acerca_de_JavaScript http://www.jisc.ac.uk/uploaded_documents/digital-repositories-review-2005.pdf https://www.jetbrains.com/idea/features/ https://docs.moodle.org/all/es/Acerca_de_Moodle 78 Mozilla (n.d.). Introducción a Express/Node. Recuperado de https://developer.mozilla.org/es/docs/Learn/Server- side/Express_Nodejs/Introduction MySQL (n. d.). Recuperado de https://www.mysql.com/products/workbench/ Nascimento M. G. F., Brandão L. O. & Brandão A. A. F. (2013). "A model to support a learning object repository for web-based courses," 2013 IEEE Frontiers in Education Conference (FIE), Oklahoma City, OK, pp. 548-552. doi: 10.1109/FIE.2013.6684883 NodeJs (n.d.). Acerca de NodeJs. Recuperado de https://nodejs.org/es/about/ Ochoa X. & Duval E., "Quantitative Analysis of Learning Object Repositories," in IEEE Transactions on Learning Technologies, vol. 2, no. 3, pp. 226-238, July-Sept. 2009. PMI. (2016). A guide to the project management body of knowledge (PMBOK guide). Project Management Institute. Polsani, P.R. (2003), “Use and abuse of reusable learning objects”, Journal of Digital Information, Vol. 3 No. 4, Article No. 164. SAFARI Montage Overview (n.d.). Recuperado de http://www.safarimontage.com/os/ Sakai Project (n.d.). Sakai Overview. Recuperado de https://sakaiproject.org/overview Santos, K. (2012) “Aprendizagem colaborativa na educação a distância: um caminho para a formação continuada” Dissertação (Mestrado em Educação) – Pontifícia Universidade Católica do Paraná, Curitiba Schwab, K. (2016). La cuarta revolución industrial. Editorial Debate SCORM Overview (n.d.). Recuperado de https://www.adlnet.gov/scorm Silva J. W. F. d., Souza C. T. d. & Souza M. d. F. C. d. (2017). "CLOVeR: An Optimized Repository for Customizable Learning Objects," 2017 IEEE 17th International Conference on Advanced Learning Technologies (ICALT), Timisoara, pp. 76-78. doi: 10.1109/ICALT.2017.114 Tick A., "Research on the Digital Learning and E-learning Behaviour and Habits of the Early Z Generation," 2018 IEEE 22nd International Conference on Intelligent Engineering Systems (INES), Las Palmas de Gran Canaria, Spain, 2018, pp. 000033-000038. http://www.safarimontage.com/os/ 79 Tolba A. S., Atwan A. & Atta A. M. (2009). "Development of Distributed Learning Object Repository," 2009 International Conference on Networking and Media Convergence, Cairo, pp. 118-121. Vargo, J., Nesbit, J.C., Belfer, K., & Archambault, A. (2003). Learning object evaluation: computer-mediated collaboration and inter-rater reliability. International Journal of Computers and Applications 25(3), pp. 198-205. (In Wolfgand S. Matsui Siqueira Maria Helena Lima Baptista Braz Rubens Nascimento Melo (2007),"Modeling e-learning content", International Journal of Web Information Systems, Vol. 3 Iss 1/2 pp. 140 – 152) Wang J., Niu Z., Song H. & Liu L. (2007). "The Design and Realization of Distributed Learning Management System Based on Internet," 2007 First IEEE International Symposium on Information Technologies and Applications in Education, Kunming, pp. 162-166. Why Canvas Commons? (2017). Recuperado de https://community.canvaslms.com/docs/DOC-11178-38287725286 Wiley, D.A. (2000). Connecting Learning Objects to Instructional Design Theory: a Definition, a Metaphor and a Taxonomy. In Wiley, D.A. (Ed.), The Instructional Use of Learning Objects. http://wesrac.usc.edu/wired/bldg- 7_file/wiley.pdf Xu, H (2015). Factors affecting faculty use of learning object repositories. The Electronic Libray 2015 vol: 33 (6) pp: 1065-1078 Zeman T., Vodrážka J. & Hrad J., "Impact of Next Generation Access Networks on Technical Quality of E-Learning," 2018 28th EAEEIE Annual Conference (EAEEIE), Hafnarfjordur, Iceland, 2018, pp. 1-6. http://wesrac.usc.edu/wired/bldg-%207_file/wiley.pdf 80 Anexo A: Plan de Proyecto  Justificación El presente proyecto de fin de carrera tiene como propósito promover el uso de los Objetos de Aprendizaje al proveer un entorno en el cual éstos se puedan clasificar, organizar y compartir de una manera sencilla. La implementación del Repositorio de Objetos de Aprendizaje contribuirá a que más docentes y educadores puedan disponer de material de calidad constantemente actualizada y revisada al momento de dictar una lección y de esta forma elevar la calidad de su enseñanza beneficiando adicionalmente a los alumnos de cuyas clases estén dictando. También, se desea proponer una solución a una de las causas raíces de la poca contribución de Objetos de Aprendizaje dentro de un repositorio: la poca integración que existe con los diversos Sistemas de Gestión de Aprendizaje utilizados actualmente. Con esta integración los docentes se sentirán motivados a subir su material educativo al repositorio ya que tendrán la garantía de que podrán utilizar sus recursos en la enseñanza sin importar que tipo de LMS utilice la institución educativa en la que se encuentren dictando.  Viabilidad Para analizar la viabilidad se han tomado en cuenta tres factores:  Viabilidad técnica: Se cuenta con experiencia previa en programación Web usando el lenguaje de programación Javascript. Con respecto a la gestión de base de datos, también se cuenta con experiencia en el uso de MySQL. En cuanto a la propuesta de la arquitectura del sistema a implementar, se cuenta con la disponibilidad de expertos en el tema los cuales validarán o sugerirán posibles mejoras. Para la configuración de los entornos LMS a utilizar para las pruebas de integración se cuentan con comunidades activas en los foros oficiales de cada producto por lo que la resolución de dudas relativas a estos sistemas puede ser resueltos en un breve tiempo.  Viabilidad económica: Todas las herramientas necesarias para llevar a cabo la implementación son gratuitas o tienen versiones de código abierto. En vista que se implementará un sistema web se hace necesario adquirir un servidor para su publicación; en cuanto a eso, la Especialidad de Ingeniería Informática puede proveer este servicio ya que será usado para fines de investigación. 81  Viabilidad temporal: En base al plan de proyecto formulado se ha establecido un cronograma de trabajo en el cual se define el periodo necesario para lograr obtener los resultados esperados propuestos dentro de la duración del ciclo académico en que será desarrollado el proyecto.  Alcance El objetivo de este proyecto es realizar la implementación de un repositorio de objetos de aprendizaje que, a diferencia de las opciones actuales en el mercado, pueda integrarse con los LMS’s usados actualmente por medio de los protocolos de comunicación que serán definidos en el desarrollo de este proyecto. Este LOR será un entorno Web y contará con las funcionalidades básicas de subir, buscar y organizar objetos de aprendizaje. Al momento de subir material educativo, el sistema pedirá al usuario algunas características relativas al recurso y otras las generará automáticamente para poder elaborar los metadatos del LO. En base a estos metadatos se podrán realizar búsquedas dentro del repositorio utilizando un motor especializado que devolverá al usuario los recursos que más le pueden ser de utilidad, así como los más descargados o vistos por otros usuarios. El usuario podrá autorizar la visibilidad y el uso público de un LO de su autoría. Además, el repositorio podrá gestionar las versiones de los objetos ya sea al momento de modificar características o subir una nueva versión del objeto. No se está considerando un marco legal para el desarrollo de este proyecto, se asumirá que todo material subido al repositorio es libre para ser distribuido o cuenta con una licencia Creative Commons que habilita la distribución y reutilización de material (Creative Commons, 2018) de manera que el Objeto de Aprendizaje queda libre para poder ser visualizado y compartido por los diversos usuarios del repositorio. Asímismo se mantendrá registrado al autor original del LO dentro de los metadatos del objeto Finalmente, mediante el uso de protocolos los objetos almacenados en el repositorio podrán ser integrados al momento de subir un recurso dentro de un LMS eliminando así la necesidad de tener que manualmente subir o actualizar el mismo objeto a la plataforma educativa que un docente utilice. 82  Limitaciones No se está considerando un marco legal para el desarrollo de este proyecto, se asumirá que todo usuario del repositorio respete la autoría original del Objeto de Aprendizaje que decida utilizar. Debido a que se necesita comprar una licencia para poder instalar y usar algunos de los Sistemas de Gestión de Aprendizaje más usados en el mercado, las pruebas de integración se realizarán con productos open-source o que cuenten con algún tipo de licencia gratuita. Además, se realizarán dichas pruebas en entornos locales de prueba y no en LMS desplegados en entornos productivos.  Identificación de los riesgos del proyecto  Escalas de medición de riesgos: En la tabla 12 se definirá la escala para medir el nivel de probabilidad e impacto de cada riesgo: Escala de probabilidad Calificación 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Interpretación baja media alta un hecho Escala de impacto Calificación Interpretación 1 Fracaso del proyecto 0.9 Proyecto retrasado en 40% 0.8 Proyecto retrasado entre 30% y 40% 0.7 Proyecto retrasado entre 20% y 30% 0.6 Proyecto retrasado entre 10% y 20% 0.5 Proyecto retrasado entre 1% y 10% 0.4 Reducción importante de las reservas de tiempo y costo 0.3 Reducción media de las reservas de tiempo y costo 0.2 Reducción pequeña de las reservas de tiempo y costo 0.1 Muy poco impacto 83 Probabilidad 0.9 0.09 0.18 0.27 0.36 0.45 0.54 0.63 0.72 0.81 0.9 0.8 0.08 0.16 0.24 0.32 0.4 0.48 0.56 0.64 0.72 0.8 0.7 0.07 0.14 0.21 0.28 0.35 0.42 0.49 0.56 0.63 0.7 0.6 0.06 0.12 0.18 0.24 0.3 0.36 0.42 0.48 0.54 0.6 0.5 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.4 0.04 0.08 0.12 0.16 0.2 0.24 0.28 0.32 0.36 0.4 0.3 0.03 0.06 0.09 0.12 0.15 0.18 0.21 0.24 0.27 0.3 0.2 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 0.2 0.1 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1 Impacto 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Tabla 12. Espala de impactos y riesgos  Riesgos identificados: En esta tabla 13 se presenta la lista de riesgos identificados que se identificaron respecto al proyecto Código de riesgo Riesgo Causas raíces R01 No terminar el proyecto en la fecha establecida. - Pérdida de recursos y documentos necesarios - Estimación equivocada de costos y esfuerzos en las tareas - Errores en la gestión del tiempo disponible - Inadecuado levantamiento de necesidades - Errores en el diseño de la solución R02 No se realizan tareas acordadas en los tiempos acordados. - Estimación equivocada de costos y esfuerzos en las tareas - Emergencias médicas y/o familiares R03 Implementar funcionalidades no definidas en los requerimientos. - Levantamiento de requerimientos incompleto - Errores al redactar el documento de arquitectura 84 R04 Modificación del alcance. - Mala gestión del tiempo disponible - Inadecuada definición del alcance inicial R05 Curva de aprendizaje elevada. - Aprender una nueva tecnología - Falta de documentación de las tecnologías a utilizar - No se consideró la curva de aprendizaje al asignar los tiempos para cada tarea R06 El jurado no acepta el proyecto terminado. - Entregas fuera de tiempo - El proyecto entregado no cumple con el alcance definido R07 Caída en la productividad del desarrollador del proyecto. - Fatiga - Emergencias médicas y/o familiares R08 Pérdida de documentos y/o archivos relevantes - Backup incorrecto o inexistente R09 La arquitectura planteada imposibilita la implementación del proyecto - Errores en la etapa de diseño R10 Carga educativa adicional no considerada - Asignación de trabajos académicos o exámenes R11 Retrasos ocasionados por la falta de expertos que validen los entregables - No se buscó con tiempo a expertos - Expertos identificados no disponibles Tabla 13. Identificación de riesgos del proyecto. (Elaboración propia)  Niveles de severidad y acciones a tomar: En esta tabla 14 se presenta el cálculo de los niveles de severidad caso los riesgos se materialicen, así como las acciones para mitigar el impacto. 85 Código de riesgo Probabilidad Impacto Prob Xmpacto Estrategia de respuesta Respuesta planificada R01 0.2 1 0.2 Evitar - Realizar una correcta estimación de costo y esfuerzo de las tareas R02 0.2 0.7 0.14 Mitigar - Realizar una correcta estimación de costo y esfuerzo de las tareas R03 0.1 0.5 0.05 Evitar - Realizar un correcto análisis y diseño R04 0.3 0.7 0.21 Evitar - Realizar una correcta estimación de costo y esfuerzo de las tareas - Realizar un correcto análisis y diseño R05 0.5 0.4 0.2 Mitigar - Conseguir capacitación con anticipación R06 0.2 1 0.2 Evitar - Validación de entregables periódicos R07 0.5 0.6 0.3 Mitigar - Respetar el cronograma de trabajo en su totalidad R08 0.1 0.7 0.07 Evitar - Implementar un proceso de backup adecuado y realizarlo constantemente R09 0.2 0.8 0.16 Evitar - Realizar un correcto análisis y diseño R10 0.5 0.4 0.2 Mitigar - Organizar el tiempo disponible correctamente R11 0.5 0.7 0.35 Mitigar - Identificar expertos con anticipación - Contar con expertos adicionales caso uno o más no estén disponibles Tabla 14. Niveles de severidad y acciones a tomar. (Elaboración propia) 86  Estructura de descomposición del trabajo (EDT) Figura 30. Estructura de descomposición del trabajo para el proyecto. (Elaboración propia). Descripción de componentes: A continuación, se detallarán los componentes del EDT describiendo cada paquete, entregable relacionado y criterio de aceptación. Componente Descripción Código del paquete de trabajo P.1 Descripción del paquete de trabajo Plan de Tesis Entregable(s) Plan de Tesis Criterios de aceptación del entregable(s) Aceptación del jurado Componente Descripción Código del paquete de trabajo P.2 Descripción del paquete de trabajo Plan de proyecto, incluyendo cronograma de tareas, estimación de costos y esfuerzos Entregable(s) Plan de proyecto Criterios de aceptación del entregable(s) Aceptación del jurado Componente Descripción Código del paquete de trabajo 0.1 Descripción del paquete de trabajo Documento de casos de uso Entregable(s) Documento de casos de uso Criterios de aceptación del entregable(s) Aceptación de expertos 87 Componente Descripción Código del paquete de trabajo 0.2 Descripción del paquete de trabajo Documento de arquitectura Entregable(s) El documento contendrá: - Especificación de requerimientos funcionales y no funcionales. - Diagramas de actividades - Diagramas de secuencia - Diagramas de componentes - Diagramas de clase - Diagramas de implantación - Esquema de base de datos Criterios de aceptación del entregable(s) Aceptación de expertos Componente Descripción Código del paquete de trabajo 1.1 Descripción del paquete de trabajo Entorno de desarrollo en línea Entregable(s) Se contará con el entorno en línea para el desarrollo Criterios de aceptación del entregable(s) Pruebas de validación aceptadas Componente Descripción Código del paquete de trabajo 1.2 Descripción del paquete de trabajo Módulo de gestión de cuentas de usuario Entregable(s) Se entregarán las siguientes funcionalidades: - Creación de cuenta de usuario - Uso de protocolos de autenticación y seguridad - Ingreso al LOR vía autenticación de usuario. Criterios de aceptación del entregable(s) Pruebas de validación aceptadas Componente Descripción Código del paquete de trabajo 1.2 Descripción del paquete de trabajo Módulo de carga, descarga y visualización de Objetos de Aprendizaje Entregable(s) Se validarán las siguientes funcionalidades: - Flujo de creación de un LO. - Validar la correcta visualización de los atributos del LO. - Descargar correctamente el LO. Criterios de aceptación del entregable(s) Pruebas de validación aceptadas 88 Componente Descripción Código del paquete de trabajo 2.1 Descripción del paquete de trabajo Objetos de Aprendizaje versionables Entregable(s) Se validarán las siguientes funcionalidades: - Flujo de creación de contenido versionable a causa de modificación de atributos o actualización de LO. - Generación de copias del LO al momento de crear una nueva versión. Criterios de aceptación del entregable(s) Pruebas de validación aceptadas Componente Descripción Código del paquete de trabajo 2.2 Descripción del paquete de trabajo Funcionalidad que habilita la visualización y/o edición de Objetos de Aprendizaje a otros usuarios Entregable(s) Se verificará y validará el proceso de poder dar permisos de lectura y/o escritura de un LO a otro usuario. Criterios de aceptación del entregable(s) Pruebas de validación aceptadas Componente Descripción Código del paquete de trabajo 3.1 Descripción del paquete de trabajo Módulo de búsquedas de Objetos de Aprendizaje Entregable(s) Se verificará y validará el proceso de búsqueda de LO en base a criterios como: nombre del objeto, características de metadatos, relevancia y utilidad del objeto. Criterios de aceptación del entregable(s) Pruebas de validación, precisión y exhaustividad aceptadas Componente Descripción Código del paquete de trabajo 4.1 Descripción del paquete de trabajo Repositorio con soporte de protocolos de interoperabilidad Entregable(s) Se verificará que el LOR implementado pueda soportar los protocolos definidos Criterios de aceptación del entregable(s) Pruebas de validación e integración aceptadas 89 Componente Descripción Código del paquete de trabajo 4.2 Descripción del paquete de trabajo Pruebas de integración validadas Entregable(s) Se realizará una prueba de integración en la cual se verificará que el LOR pueda integrarse con un LMS Criterios de aceptación del entregable(s) Pruebas de validación e integración aceptadas Componente Descripción Código del paquete de trabajo 4.3 Descripción del paquete de trabajo Documentación final de tesis Entregable(s) Se entregará el documento de tesis completo, según lo pedido por los requisitos del curso Proyecto de tesis 2 Criterios de aceptación del entregable(s) Aprobación de jurados  Lista de tareas Nombre Duración Esfuerzo Costo Iteración 0 Reunión de inicio de iteración con el asesor 2 horas 2 horas-persona 20 soles Elaborar documento de casos de uso 12 horas 12 horas-persona 96 soles Elaborar documento de arquitectura 12 horas 12 horas-persona 108 soles Verificar y validar la documentación realizada 2 horas 2 horas-persona 16 soles Revisión de monitoreo y control de iteración con el asesor 2 horas 2 horas-persona 20 soles Iteración 1 Revisión de backlog y planificación con el asesor 2 horas 2 horas-persona 20 soles Preparar el ambiente de desarrollo: base de datos, proyecto de desarrollo y repositorio de control de versiones 2 horas 2 horas-persona 20 soles Implementar funcionalidades de creación de cuentas de usuario y autenticación 24 horas 24 horas-persona 240 soles Implementar funcionalidades de subir, crear, visualizar y descargar Objetos de 42 horas 42 horas-persona 420 soles 90 Aprendizaje Realizar validaciones funcionales 3 horas 3 horas-persona 24 soles Revisión de monitoreo y control de iteración con el asesor 2 horas 2 horas-persona 20 soles Iteración 2 Revisión de backlog y planificación con el asesor 2 horas 2 horas-persona 20 soles Implementar un control de versiones para los Objetos de Aprendizaje dentro del repositorio 30 horas 30 horas-persona 300 soles Implementar funcionalidad de compartir el acceso a los Objetos de Aprendizaje a otros usuarios 30 horas 30 horas-persona 300 soles Realizar validaciones funcionales 2 horas 2 horas-persona 16 soles Revisión de monitoreo y control de iteración con el asesor 2 horas 2 horas-persona 20 soles Iteración 3 Revisión de backlog y planificación con el asesor 2 horas 2 horas-persona 20 soles Realizar la configuración inicial de Apache Solr 10 horas 10 horas-persona 100 soles Implementar funcionalidades de búsqueda de Objetos de Aprendizaje en base a criterios 30 horas 30 horas-persona 300 soles Realizar validaciones funcionales 2 horas 2 horas-persona 16 soles Revisión de monitoreo y control de iteración con el asesor 2 horas 2 horas-persona 20 soles Iteración 4 Revisión de backlog y planificación con el asesor 2 horas 2 horas-persona 20 soles Implementar los protocolos de interoperabilidad del repositorio 42 horas 42 horas-persona 420 soles Realizar validaciones funcionales 2 horas 2 horas-persona 16 soles Desplegar los LMS’s de prueba Moodle y Sakai 6 horas 6 horas-persona 60 soles Realizar pruebas de Integración 10 horas 10 horas-persona 80 soles Realizar validaciones finales 2 horas 2 horas-persona 16 soles Revisión de monitoreo y control de iteración con el asesor 2 horas 2 horas-persona 20 soles  Cronograma del proyecto: La figura 25 muestra el cronograma del proyecto. 91 Figura 31: Cronograma del proyecto. (Elaboración propia) 92  Lista de recursos o Personas involucradas y necesidades de capacitación El equipo de trabajo está conformado por una persona, el autor de este documento, que tomará los roles de coordinador del proyecto, arquitecto del sistema, analista funcional, programador y ejecutor de las pruebas unitarias. Con respecto a necesidades de capacitación, solamente se tiene inexperiencia con el uso y configuración del Apache Solr. Apache distribuye de forma gratuita la documentación en cuanto al uso de esta tecnología por lo que ésta se estudiará de antemano. o Materiales requeridos para el proyecto Para el presente proyecto se consideran materiales de oficina tales como hojas de papel para realizar bosquejos de la arquitectura del sistema y la comunicación entre módulos. o Equipamiento requerido  Computadora: Se requiere una computadora en donde se instalarán las herramientas necesarias para ejecutar las tareas referentes a la fase de Análisis, Diseño e Implementación del proyecto. Funcionará como ambiente de desarrollo y pruebas del sistema.  Servidor: Se requiere una máquina virtual que pueda cumplir las funciones de un servidor en donde se alojará el LOR y los LMS’s que serán utilizados para las pruebas de integración. Cumplirá las funciones de un entorno de producción. o Herramientas requeridas Nombre Importancia Visual Paradigm Community Edition Herramienta usada para la elaboración de diagramas UML Intellij Idea Ultimate Edition IDE en donde el proyecto será desarrollado 93 MySQL Workbench Herramienta utilizada en la creación y gestión de la base de datos del proyecto Apache Solr Motor de búsqueda que será utilizada en el proyecto Moodle LMS Plataformas que serán utilizadas para las pruebas de integración Sakai LMS Git Herramienta de control de versiones de proyectos. Se alojará el código desarrollado aquí. Google Drive Herramienta que permite guardar archivos en la nube. Se subirá toda la documentación en esta plataforma.  Costeo del Proyecto Ítem Descripción Unidad Cantidad Valor Unidad (S/.) Monto Total (S/.) 0 Costo total del proyecto --- --- --- 4728 1. Roles dentro del proyecto --- --- --- 1.1 Coordinador de proyecto Horas 20 10 200 1.2 Arquitecto del sistema Horas 12 9 108 1.3 Analista funcional Horas 12 8 96 1.4 Programador Horas 208 10 2080 1.5 Ejecutor de pruebas Horas 23 8 184 2. Otros participantes --- --- --- No aplica 3. Servicios y consultoría --- --- --- 3.1 No aplica 4. Materiales e insumos --- --- --- 15 4.1 Hojas bond A4 Paquete de 500 hojas 1 15 15 5. Bienes y equipos - 5.1 Computadoras Equipo 1 2000 2000 6. Pasajes y viáticos - 6.1 Movilidad (Reuniones con asesores) Viajes/Día 15 3 45 94 Anexo B: Especificación de casos de uso ID 1 Nombre Realizar login Breve Descripción Caso de uso que permite al usuario loguearse al repositorio mediante el ingreso de un nombre de usuario y contraseña Actores Usuario no logueado Flujo de Eventos Flujo Primario 1. El usuario ingresa a la pantalla inicial del sistema 2. El usuario ingresa su nombre de usuario y contraseña en el formulario que se mostrará 3. El usuario envía los datos del formulario al sistema que verificará sus credenciales 4. El sistema valida las credenciales y redirige al usuario a la pantalla de bienvenida Flujo Alternativo 1 Si en el paso 3 del flujo primario son enviados datos incorrectos el sistema responderá con un mensaje de error, en este caso el usuario puede intentar ingresar de nuevo siguiendo el paso 2 del flujo primario Flujo Alternativo 2 En caso que en el paso 2 el usuario no recuerde sus credenciales de acceso, podrá ingresar a la opción de recuperar contraseña la cual le será enviada mediante correo electrónico, en este caso el usuario puede intentar ingresar de nuevo siguiendo el paso 2 del flujo primario Postcondiciones El usuario queda validado en el sistema ID 2 Nombre Registrar nuevo usuario 95 Breve Descripción Caso de uso que permite a un usuario registrarse en el sistema para que pueda utilizarlo Actores Usuario no logueado Flujo de Eventos Flujo Primario 1. El usuario ingresa a la pantalla inicial del sistema 2. El usuario accede a la opción de registro 3. Se mostrará un formulario en el cual el usuario debe llenar los siguientes datos:  Nombre de usuario  Contraseña  Correo electrónico  Áreas de interés 4. El usuario envía los datos del formulario al sistema que procederá a registrarlos 5. Se continúa con el caso de uso 1 desde el paso 3 Flujo Alternativo 1 Si en el paso 3 del flujo primario algún dato del formulario es llenado incorrectamente entonces el sistema mostrará un mensaje de error y el usuario podrá intentar el paso 3 nuevamente Postcondiciones El usuario queda registrado y validado en el sistema ID 3 Nombre Subir Objeto de Aprendizaje Breve Descripción Caso de uso que permite al usuario el subir un nuevo Objeto de Aprendizaje al sistema Actores Usuario logueado, autor Flujo de Eventos Flujo Primario 1. El usuario ingresa a la pantalla de subir objeto 2. Se mostrará un formulario en el cual el usuario debe llenar los siguientes datos: 96  Título  Idioma  Descripción  Tipo de recurso  Nivel de educación  Usado por  Usado para  Categorías  Palabra clave 3. El usuario subirá el archivo que quiere subir 4. El sistema crea el Objeto de Aprendizaje y redirige al usuario a la página de detalle del Objeto subido Flujo Alternativo 1 Si en el paso 2 del flujo primario el usuario no ingresa los campos obligatorios o los llena incorrectamente entonces el sistema mostrará un mensaje de error Flujo Alternativo 2 Si en el paso 3 del flujo primario el usuario no sube un archivo u ocurre algún error en el sistema al momento de subirlo entonces se mostrará un mensaje de error Precondiciones El usuario debe estar logueado en el sistema Postcondiciones El Objeto de Aprendizaje se encuentra registrado en el sistema ID 4 Nombre Pedir permisos de modificación Breve Descripción Caso de uso en el cual un usuario pide permisos para modificar un Objeto de Aprendizaje Actores Usuario Flujo de Eventos Flujo Primario 1. El usuario presiona el botón “Pedir permiso de modificación” 97 2. Se mostrará un formulario en el cual el usuario deberá especificar la razón por la cual desea solicitar el permiso 3. El usuario confirmará el envío de la solicitud Precondiciones El autor debe estar logueado en el sistema y debe encontrarse en la página de detalle del Objeto de Aprendizaje que desea pedir permiso Postcondiciones Notificación de pedido de solicitud enviada a usuario Autor ID 5 Nombre Crear nueva versión de Objeto de Aprendizaje Breve Descripción Caso de uso en el cual un usuario autor sube una nueva versión del Objeto de Aprendizaje, pero no hay cambios en los metadatos Actores Usuario autor Flujo de Eventos Flujo Primario 1. El usuario presionará el botón “modificar” 2. El usuario selecciona la opción “Crear nueva versión” 3. Se mostrará un formulario en donde el usuario debe ingresar la nueva URL o subir la nueva versión del archivo y describir cuales son los cambios realizados en la nueva versión 4. El sistema creará la nueva versión del objeto y redirigirá al usuario a la pantalla de detalle del objeto. 5. El usuario podrá descargar las versiones pasadas seleccionando la opción “ver versiones pasadas” e indicando la versión que desea descargar Precondiciones El autor debe estar logueado en el sistema y debe encontrarse en la página de detalle del Objeto de Aprendizaje que desea crear una nueva versión 98 Postcondiciones Objeto de Aprendizaje con una nueva versión de contenido ID 6 Nombre Generar contenido derivado Breve Descripción Caso de uso en el cual un usuario autor o con permisos de modificador genera contenido derivado de un Objeto de Aprendizaje, este contenido posee metadatos distintos a la versión padre Actores Usuario autor, modificador Flujo de Eventos Flujo Primario 1. El usuario presionará el botón “modificar” 2. El usuario selecciona la opción “Generar contenido derivado” 3. Se mostrará un formulario en el cual el usuario debe llenar los siguientes datos:  Título  Idioma  Descripción  Tipo de recurso  Nivel de educación  Usado por  Usado para  Categorías  Palabra clave  Descripción de los cambios que se están realizando  URL o archivo del Objeto de Aprendizaje 4. El sistema crea el Objeto de Aprendizaje y redirige al usuario a la página de detalle del Objeto derivado 5. El sistema mostrará un mensaje que informará que el objeto ha sido derivado y permitirá la navegación a la versión padre del objeto Precondiciones El usuario debe estar logueado en el sistema y debe 99 tener permiso de modificador ID 5 Nombre Descargar Objeto de Aprendizaje Breve Descripción Caso de uso que permite al usuario descargar un Objeto de Aprendizaje guardado en el repositorio Actores Usuario Flujo de Eventos Flujo Primario 1. El usuario accede a la opción de descargar objeto dentro de la pantalla de detalle de Objeto de Aprendizaje 2. El sistema comienza la descarga del objeto Precondiciones El usuario debe estar logueado en el sistema ID 6 Nombre Gestionar permisos Breve Descripción Caso de uso que permite a un usuario aprobar o negar permisos de modificación sobre un Objeto de Aprendizaje Actores Autor, Modificador Flujo de Eventos Flujo Primario 1. El usuario accede a la pantalla de Gestión de permisos 2. El usuario selecciona la opción de permisos pendientes y el sistema mostrará una lista con el 100 detalle de cada pedido 3. El usuario decide aprobar o negar los pedidos 4. El usuario que pidió el permiso recibirá una notificación del resultado de la solicitud Flujo Alternativo 1 1. El usuario accede a la pantalla de Gestión de permisos 2. El usuario selecciona la opción de permisos dados y el sistema mostrará el detalle de cada pedido de modificación que el usuario haya otorgado Precondiciones El usuario debe estar logueado en el sistema ID 7 Nombre Realizar búsquedas Breve Descripción Caso de uso que permite encontrar Objetos de Aprendizaje mediante búsquedas en base a parámetros Actores Usuario logueado Flujo de Eventos Flujo Primario 1. El usuario ingresa el término que desee buscar en la barra de búsqueda del sistema, estos términos pueden ser título, descripción, categoría y palabra clave de un objeto 2. El sistema realiza la búsqueda y brinda al usuario una lista de Objetos de Aprendizaje que tengan relación con el objeto buscado 3. El usuario puede acceder a cada uno de los objetos de la lista lo cual iniciará el caso de uso 9 Flujo Alternativo 1 1. El usuario selecciona la opción de búsqueda avanzada 2. El sistema mostrará un formulario que el usuario debe llenar uno o más de los siguientes campos:  Título  Idioma  Descripción  Tipo de recurso 101  Nivel de educación  Rango de edad  Usado por  Usado para  Categorías  Palabra clave  Fecha de creación  Fecha de modificación 3. El sistema realiza la búsqueda y brinda al usuario una lista de Objetos de Aprendizaje que tengan relación con el objeto buscado priorizando los más útiles 4. El usuario puede acceder a cada uno de los objetos de la lista lo cual iniciará el caso de uso 9 Precondiciones El usuario debe estar logueado en el sistema ID 8.1 Nombre Ver lista de Objetos creados Breve Descripción Caso de uso que permite visualizar los objetos que se tenga autoría Actores Usuario logueado Flujo de Eventos Flujo Primario 1. El usuario selecciona la opción de visualización de sus Objetos de Aprendizaje 2. El sistema devuelve una lista con los objetos de su autoría 3. El usuario puede navegar a la página que muestra el detalle de cada uno de los objetos lo cual iniciará el caso de uso 9 Precondiciones El usuario debe estar logueado en el sistema 102 ID 8.2 Nombre Ver lista de Objetos permitidos Breve Descripción Caso de uso que permite visualizar los objetos que se tenga permisos de modificación Actores Usuario logueado Flujo de Eventos Flujo Primario 1. El usuario selecciona la opción de visualización de sus Objetos de Aprendizaje 2. El usuario elige la opción de visualizar los objetos en los cuales posee permisos de modificación 3. El sistema devuelve una lista con los objetos El usuario puede navegar a la página que muestra el detalle de cada uno de los objetos lo cual iniciará el caso de uso 9 Precondiciones El usuario debe estar logueado en el sistema ID 9 Nombre Ver detalle de Objeto de Aprendizaje Breve Descripción Caso de uso que permite visualizar los atributos de un Objeto de Aprendizaje Actores Usuario logueado Flujo de Eventos Flujo Primario 1. El usuario ingresa a la pantalla de detalle del objeto 2. El sistema muestra en pantalla todos los atributos del Objeto de Aprendizaje que son:  Título 103  Idioma  Descripción  Tipo de recurso  Nivel de educación  Rango de edad  Usado por  Usado para  Categorías  Palabra clave  Fecha de creación  Fecha de modificación  Tamaño  Formato  Versión  Identificador 3. Se mostrará la opción de poder indicar si el objeto le parece útil al usuario 4. Si el usuario no es el autor del objeto aparecerá la opción para poder pedir permiso de modificación el cual iniciará el flujo alternativo 2 del caso de uso 4 Flujo Alternativo 1 En el paso 3 del flujo primario si es que el usuario ha indicado si le parece útil entonces podrá desmarcar la opción Precondiciones El usuario debe estar logueado en el sistema ID 10 Nombre Exportar Objetos de Aprendizaje Breve Descripción Caso de uso que permite exportar un Objeto de Aprendizaje a un LMS Actores Usuario logueado Flujo de Eventos Flujo Primario 1. El usuario ingresa a la opción de exportar objeto 2. El sistema mostrará al usuario los pasos a seguir 104 Precondiciones El usuario debe estar logueado en el sistema y debe encontrarse en la página del detalle del objeto a exportar 105 Anexo C: Diagramas de actividades  Login y registro  Creación de Objeto de Aprendizaje 106  Solicitar permisos de modificación de Objetos de Aprendizaje  Realizar búsquedas 107  Modificación de Objeto de Aprendizaje 108 Anexo D: Diagramas de secuencia  Pedido de parámetros LTI 109  Integración con un Sistema de Gestión de Aprendizaje 110  Integración con un Sistema de Gestión de Aprendizaje – Contenido interactivo 111 Anexo E: Resultados de juicio de expertos  Diseño del cuestionario Se elaboró un cuestionario que evaluase el esquema de metadatos de Objetos de Aprendizaje (Tabla 11) en base a su facilidad de ser entendido y llenado y la capacidad de poder clasificar los objetos de manera apropiada. El cuestionario es el siguiente: De acuerdo con los siguientes indicadores califique cada uno de los ítems según corresponda siendo: (1) Altamente en desacuerdo, (2) En desacuerdo, (3) Ni en acuerdo ni en desacuerdo, (4) De acuerdo, (5) Altamente de acuerdo. P1. Considera que los campos definidos son suficientes para clasificar objetos de aprendizaje dentro de un ámbito pedagógico (1) (2) (3) (4) (5) P2. Considera que la descripción de los campos definidos es clara y entendible (1) (2) (3) (4) (5) P3. Considera que la elección de los campos que son ingresados por el usuario y los que son automáticos es correcta. (1) (2) (3) (4) (5) P4. Considera que los campos ingresados por el usuario son fáciles de describir y llenar (1) (2) (3) (4) (5) P5. Considera que los campos definidos facilitan la distinción de Objetos de Aprendizaje de tal manera que el docente pueda elegir sin complicaciones el material que sea más apropiado usar (1) (2) (3) (4) (5) P6. Considera que los campos definidos son los apropiados tomando en cuanto la diversidad de diversos contextos culturales y lingüísticos (1) (2) (3) (4) (5) P7. Considera que existen términos ambiguos entre los campos definidos (1) (2) (3) (4) (5) 112  Resultados Este cuestionario fue respondido por cuatro personas, dos de ellos son potenciales usuarios del sistema, un director de una institución educativa privada y un docente universitario; los dos jueces restantes fueron dos bibliotecólogos con experiencia en el uso y mantenimiento del repositorio de tesis de la PUCP. Estas fueron sus respuestas: Pregunta Director IEP Docente Bibliotecólogo 1 Bibliotecólogo 2 P1 5 5 4 3 P2 5 4 4 3 P3 5 5 5 3 P4 5 5 5 3 P5 5 5 5 3 P6 5 4 4 3 P7 2 2 1 2 113 Anexo F: Pruebas de aceptación funcional  Trazabilidad de casos de prueba con los requerimientos Para la funcionalidad de creación de Objetos de Aprendizaje Id Requerimiento Caso de prueba 6 El sistema podrá permitir la creación de Objetos de Aprendizaje CA-1, CU-1 7 El usuario deberá proveer los siguientes datos para la creación del objeto: Título, descripción, categorías, una palabra o término clave que describa al objeto, idioma, tipo de recurso, nivel de educación orientado, temas que el objeto enseñará, entidad que usa el objeto y el archivo que contenga el objeto CA-1, CU-1 8 El sistema deberá registrar de manera interna los siguientes atributos: Fechas de creación y modificación del objeto, autor, identificador único del objeto, su versión más reciente, formato del archivo, tamaño en bytes del archivo y sus fechas de creación y modificación más reciente CA-1, CU-1 9 El usuario debe poder visualizar todos los atributos del objeto en el momento que accede a la vista detallada de este CA-1, CU-1 10 Dentro de la vista detallada debe haber la opción de descargar el objeto CA-1, CU-1 Para las funcionalidades de versionamiento y generación de contenidos derivados: Id Requerimiento Caso de prueba 20 El sistema permitirá manejar dos tipos de versiones: nueva versión y contenido derivado NV1, NV2, CD1, CD2 21 Se generará una nueva versión cuando se realice algún cambio en el archivo o la URL del objeto, pero no los metadatos NV1, NV2 22 Se generará contenido derivado cuando se realice algún cambio a nivel de metadatos y archivo CD1, CD2 23 El usuario autor de un Objeto de Aprendizaje podrá realizar actualizaciones de los dos tipos NV1, NV2, CD1, CD2 25 Para generar una nueva versión el usuario subirá un nuevo archivo o URL y deberá especificar cuáles son los cambios que han sido realizados NV1, NV2 26 Para generar contenido derivado el sistema mostrará un formulario con todos los atributos a cambiar CD1, CD2 114 27 El usuario debe modificar el formulario de atributos del objeto al momento de realizar una modificación, también debe especificar qué cambios se están realizando CD1, CD2 28 El formulario de atributos de modificación debe estar pre cargado con los atributos actuales del Objeto de Aprendizaje CD1, CD2 29 El sistema generará un nuevo Id de versión para el objeto modificado y lo guardará como una entidad diferente NV1, NV2, CD1, CD2 30 El sistema mantendrá un registro de todas las versiones del Objeto de Aprendizaje y cuál es la versión más reciente NV1, NV2 31 Siempre se mostrará la versión más reciente de un objeto al acceder a su vista detallada NV1, NV2 32 El usuario podrá elegir que versión del Objeto de Aprendizaje desea ver en la vista detallada NV1, NV2 33 Si algún Objeto de Aprendizaje ha sido derivado de otro se hará referencia de esto en la pantalla de detalle de objeto CD1, CD2 115  Definición de los casos de prueba Crear nuevo Objeto de Aprendizaje – tipo archivo Código: CA-1 Descripción: Se creará un nuevo Objeto de Aprendizaje de tipo archivo Prerrequisitos:  El usuario debe estar logueado en el sistema  El usuario contará con el archivo de prueba a subir al repositorio Pasos: 1. Hacer clic a la opción “Nuevo objeto” del menú 2. Elegir la opción “Archivo” 3. Subir el archivo Bases_de_datos.pdf 4. Llenar el resto del formulario con las siguientes características: Campo Valor category Información y comunicación /Tecnología de información (software) description Presentación sobre bases de datos Oracle educationType Educación universitaria Keyword Informática language ES resourceType Material de referencia Title Base de datos Oracle 11g usedBy Profesor de informática usedFor Curso Bases de datos 5. Hacer clic al botón “Crear” y esperar a que se redirija al usuario a la página de detalle del Objeto de Aprendizaje 6. Hacer clic al botón “Ir al recurso” y verificar que se descargue el archivo Bases_de_datos.pdf Resultado esperado: Objeto de Aprendizaje creado 116 Crear nuevo Objeto de Aprendizaje – tipo URL Código: CU-1 Descripción: Se generará una nueva versión de un Objeto de Aprendizaje de tipo url Prerrequisitos:  El usuario debe estar logueado en el sistema Pasos: 1. Hacer clic a la opción “Nuevo objeto” del menú 2. Elegir la opción “URL” 3. Ingresar la URL “https://www.musictheory.net/” 4. Llenar el resto del formulario con las siguientes características: Campo Valor category Cultura/ Artes ejecutadas/ Música description Sitio web con ejercicios de teoría musical educationType Otros Keyword Teoría musical language EN resourceType Curso en línea Title Página web Teoría musical usedBy Profesor de música usedFor Enseñar conceptos básicos de teoría musical 5. Hacer clic al botón “Crear” y esperar a que se redirija al usuario a la página de detalle del Objeto de Aprendizaje 6. Hacer clic al botón “Ir al recurso” y verificar que se abra una nueva pestaña con la URL del Objeto de Aprendizaje Resultado esperado: Objeto de Aprendizaje creado https://www.musictheory.net/ 117 Crear nueva versión de OA de tipo archivo Código: NV-1 Descripción: Se generará una nueva versión de un Objeto de Aprendizaje de tipo archivo Prerrequisitos  El usuario debe estar logueado en el sistema  Se ha subido un Objeto de Aprendizaje de tipo archivo con las siguientes características: Campo Valor authorId 3 category Educación Created ["2019-04-14T23:39:00.849Z"] description Este es un objeto que será usado para una prueba educationType Educación primaria Filename Version1.docx Id 45 Key 1555285134231 Keyword Versión language -- location https://s3.us-east- 2.amazonaws.com/learning.object.repo.tesis/1555285134231 mimetype application/vnd.openxmlformats- officedocument.wordprocessingml.document resourceType Curso en línea title Prueba de versión 118 updated ["2019-04-14T23:39:00.849Z"] usedBy Usado por un usuario de prueba usedFor Usado para prueba version d82KgT20djba2sbBJF_wBVeTQoOXcRRl Pasos: 7. Hacer clic a la opción “Mis objetos” del menú 8. Hacer clic al botón con la flecha del Objeto de Aprendizaje llamado “Prueba de versión” 9. Hacer clic al botón “Modificar” y luego a la opción “Nueva versión” en la ventana que aparecerá 10. Subir el archivo Version2.pdf y colocar la descripción “Se cambió de formato a pdf” 11. Hacer clic al botón “Crear nueva versión”, lo cual creará la nueva versión y redirigirá al usuario a la pantalla de detalle de archivo 12. Hacer clic al botón “Ir al recurso” y verificar que se descargue el archivo Version2.pdf 13. Hacer clic al botón “Ver todas las versiones” y validar que existen dos versiones: la primera y la actualización del paso 4 14. Hacer clic al botón de descarga en la fila de la primera versión y validar si es la versión inicial del objeto llamado Version1.docx Resultado esperado: Objeto de Aprendizaje con una nueva versión generada y archivo actualizado 119 Crear nueva versión de OA de tipo URL NV-2 Descripción: Se generará una nueva versión de un Objeto de Aprendizaje de tipo archivo Prerrequisitos  El usuario debe estar logueado en el sistema  Se ha subido un Objeto de Aprendizaje de tipo URL con las siguientes características: Campo Valor authorId 3 Category Información y comunicación /Tecnología de información (software) Created ["2019-04-14T23:14:44.797Z"] Description A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. educationType Universidad Filename https://en.wikipedia.org/wiki/Deployment_diagram Id 44 Key 1555283684753 Keyword Diagrama despliegue language En location https://en.wikipedia.org/wiki/Deployment_diagram mimetype url resourceType Material de referencia title Deployment diagram – Wikipedia https://en.wikipedia.org/wiki/Deployment_diagram 120 updated ["2019-04-14T23:14:44.797Z "] usedBy Profesor de sistemas usedFor Enseñar sobre arquitectura de software version 7281608a09215d160cb4660f6d3bb285db13bfa99f9b52791f Pasos: 1. Hacer clic a la opción “Mis objetos” del menú 2. Hacer clic al botón con la flecha del Objeto de Aprendizaje llamado “Deployment diagram - Wikipedia” 3. Hacer clic al botón “Modificar” y luego a la opción “Nueva versión” en la ventana que aparecerá 4. Ingresar “https://www.uml-diagrams.org/deployment-diagrams-overview.html como la nueva URL y colocar la descripción “Cambio a URL actualizada” 5. Hacer clic al botón “Crear nueva versión”, lo cual creará la nueva versión y redirigirá al usuario a la pantalla de detalle de archivo 6. Hacer clic al botón “Ir al recurso” y verificar que se redirija a la URL “https://www.uml-diagrams.org/deployment-diagrams-overview.html” 7. Hacer clic al botón “Ver todas las versiones” y validar que existen dos versiones: la primera y la actualización del paso 4 8. Hacer clic al botón de descarga en la fila de la primera versión y validar si se redirige a la versión inicial del objeto con la URL “https://en.wikipedia.org/wiki/Deployment_diagram” Resultado esperado: Objeto de Aprendizaje con una nueva versión generada y URL actualizado https://www.uml-diagrams.org/deployment-diagrams-overview.html https://www.uml-diagrams.org/deployment-diagrams-overview.html https://en.wikipedia.org/wiki/Deployment_diagram 121 Crear contenido derivado de un Objeto de Aprendizaje de tipo archivo CD-1 Descripción: Generación de contenido derivado de un Objeto de Aprendizaje de tipo archivo, esta generación implica el cambio de los metadatos de un Objeto Prerrequisitos  El usuario debe estar logueado en el sistema  Se ha subido un Objeto de Aprendizaje de tipo archivo con las siguientes características: Campo Valor authorId 3 category Educación created ["2019-04-14T23:39:00.849Z"] description Este es un objeto que será usado para una prueba educationType Educación primaria Filename Version1.docx Id 45 Key 1555285134231 Keyword Versión language -- location https://s3.us-east- 2.amazonaws.com/learning.object.repo.tesis/1555285134231 mimetype application/vnd.openxmlformats- officedocument.wordprocessingml.document resourceType Curso en línea title Prueba de versión 122 updated ["2019-04-14T23:39:00.849Z"] usedBy Usado por un usuario de prueba usedFor Usado para prueba version d82KgT20djba2sbBJF_wBVeTQoOXcRRl Pasos: 1. Hacer clic a la opción “Mis objetos” del menú 2. Hacer clic al botón de la flecha del Objeto de Aprendizaje llamado “Prueba de versión” 3. Hacer clic al botón “Modificar” y luego a la opción “Derivar contenido” en la ventana que aparecerá 4. Subir el archivo Version2.pdf y colocar la descripción “Se cambió el nivel de educación y el tipo de formato de archivo” 5. Cambiar el título a “Prueba de versión – derivado” 6. Cambiar la descripción a “Nuevo contenido derivado” 7. En el campo “Nivel de educación” cambiar a “Secundaria” 8. Hacer clic al botón “Crear contenido derivado”, lo cual creará un nuevo objeto y redirigirá al usuario a la pantalla de detalle de archivo 9. Hacer clic al botón “Ir al recurso” y verificar que se descargue el archivo Version2.pdf 10. Hacer clic al botón “Ir a objeto padre” y que lo redirigirá a la página de detalle del archivo padre 11. Hacer clic al botón “Ir al recurso” y validar si es la versión padre del objeto llamado Version1.docx 12. Ir a la opción “Mis objetos” y verificar que se muestren por separado los dos Objetos: el padre y su derivado Resultado esperado: Objeto de Aprendizaje derivado que referencie al objeto padre 123 Crear contenido derivado de un Objeto de Aprendizaje de tipo URL CD-2 Descripción: Prerrequisitos  El usuario debe estar logueado en el sistema  Se ha subido un Objeto de Aprendizaje de tipo archivo con las siguientes características: Campo Valor authorId 3 category Información y comunicación /Tecnología de información (software) created ["2019-04-14T23:14:44.797Z"] description A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. educationType Universidad Filename https://en.wikipedia.org/wiki/Deployment_diagram Id 44 Key 1555283684753 Keyword Diagrama despliegue language En location https://en.wikipedia.org/wiki/Deployment_diagram mimetype url resourceType Material de referencia title Deployment diagram – Wikipedia updated ["2019-04-14T23:14:44.797Z "] https://en.wikipedia.org/wiki/Deployment_diagram 124 usedBy Profesor de sistemas usedFor Enseñar sobre arquitectura de software version 7281608a09215d160cb4660f6d3bb285db13bfa99f9b52791f Pasos: 1. Hacer clic a la opción “Mis objetos” del menú 2. Hacer clic al botón de la flecha del Objeto de Aprendizaje llamado “Deployment diagram - Wikipedia” 3. Hacer clic al botón “Modificar” y luego a la opción “Derivar contenido” en la ventana que aparecerá 4. Ingresar “https://es.wikipedia.org/wiki/Diagrama_de_despliegue” como la nueva URL y colocar la descripción “Cambio de URL y de lenguaje” 5. Cambiar el título a “Diagrama de despliegue” 6. Cambiar la descripción a “Diagrama de despliegue, material en español” 7. Cambiar el lenguaje a “es” 8. Hacer clic al botón “Crear contenido derivado” lo cual creará el objeto y redirigirá al usuario a la pantalla de detalle de archivo 9. Hacer clic al botón “Ir al recurso” y verificar que se redirija a la URL “https://es.wikipedia.org/wiki/Diagrama_de_despliegue” 10. Hacer clic al botón “Ir a objeto padre” y que lo redirigirá a la página de detalle del archivo padre 11. Hacer clic al botón “Ir al recurso” y validar si es la versión inicial del objeto llamado Version1.docx 12. Ir a la opción “Mis objetos” y verificar que se muestren por separado los dos Objetos: el padre y su derivado Resultado esperado: Objeto de Aprendizaje derivado que referencie al objeto padre Anexo G: Criterios de búsqueda y pruebas Búsqueda simple https://es.wikipedia.org/wiki/Diagrama_de_despliegue https://es.wikipedia.org/wiki/Diagrama_de_despliegue 125 Para el caso de la búsqueda simple, el usuario ingresa una cadena conteniendo los términos que desea buscar y hace clic al botón de búsqueda. El sistema procede a limpiar la cadena ingresada removiendo los stopwords y procede a generar la cadena de búsqueda que consiste en la unión de los términos mediante el operador OR, luego de esto el sistema busca esta cadena en los campos: Título, categoría, descripción y Keyword dando los siguientes pesos: Título – 1, Categoría - 2, Descripción – 1 y Keyword – 1.5; cuanto más sea el peso más se priorizará. Ejemplo:  El usuario ingresa la cadena “Programación de aplicativos móviles en Kotlin”  El sistema remueve las palabras “de” y “en” y genera la siguiente cadena: “programación OR aplicativos OR móviles OR kotlin”  Se realiza la búsqueda en Apache Solr mediante el siguiente código reemplazando el término “searchterm” con la cadena generada por el sistema: q=title:(${searchTerm}) & category: (${searchTerm}) ^2 & description:(${searchTerm}) & keyword:(${searchTerm}) ^1.5 & sort=upvoteCount desc & rows = 1000000 Búsqueda avanzada Cuando el usuario accede a la opción de búsqueda avanzada se mostrará un formulario en el cual el usuario puede especificar un campo respectivo a los metadatos de los Objetos de Aprendizaje ingresados o seleccionados por el usuario, para cada campo elegido se podrá ingresar o seleccionar una cadena que contiene los términos que se desea buscar pertenecientes a ese campo. De manera opcional, el usuario podrá seleccionar términos que se deseen evitar de entre los campos del formulario. De la misma forma se pueden especificar clausulas condicionales, por ejemplo: “Si se encuentra el término X en el campo A, que se busque el término Y en el campo B”. Ejemplo:  El usuario busca los siguientes términos en los campos: o Título: “Programación de aplicativos móviles en Kotlin” o Categorías: Ciencia y tecnología / Tecnologías de Información (seleccionado por el usuario) o Keyword: “Programación móvil”  Adicionalmente elije evitar los siguientes términos: o Lenguaje: EN (seleccionado por el usuario) o Tipo de recurso: Presentación (seleccionado por el usuario)  Finalmente ingresa la siguiente clausula 126 o SI Tipo de Recurso: Material de referencia o ENTONCES Lenguaje: ES  El sistema remueve los stopwords de los campos donde el usuario ha ingresado (no seleccionado) términos  Se realiza la búsqueda en Apache Solr mediante el siguiente código: q=title:( programación OR aplicativos OR móviles OR kotlin) & keyword: “Programación móvil” & fq=category: “Ciencia y tecnología” & fq=category: “Tecnologías de información” & fq=language: (NOT EN) & fq= resourceType: (NOT Presentacion)  Al resultado de la ejecución anterior se le adicionan los nuevos resultados de una nueva búsqueda conteniendo la cláusula condicional Pruebas de precisión y exhaustividad Se consultó con un bibliotecólogo experto en repositorios sobre cuál debería ser el grado ideal de precisión y exhaustividad para un repositorio de este tipo e indicó que estos valores deben ser los siguientes: 90% de precisión y 80% de exhaustividad. 127 Se evaluarán los dos tipos de búsqueda presentes en el repositorio: simple y avanzada; para cada una de estas se realizarán tres búsquedas de términos distintos y se registrará los resultados relevantes recuperados totales y en la primera página de los resultados, esto debido a que los usuarios no acostumbran mirar más que la primera página al hacer consultas en un motor de búsqueda. Se calcularán la precisión y exhaustividad de cada resultado y finalmente, el promedio de estos valores.  Búsqueda simple: Para la búsqueda simple se realizaron búsquedas con 3 cadenas de búsqueda las cuales fueron: o Q1: Software (Único término) o Q2: Desarrollo software (Término doble) o Q3: Libro sobre biología (Búsqueda por frase) Se realizaron las pruebas con un total de 150 objetos indexados en Apache Solr y los resultados fueron registrados en la siguiente tabla: Query de búsqueda Relevantes recuperados Recuperados Relevantes totales Q1 20 20 20 Q2 10 15 10 Q3 25 45 25 Query de búsqueda Precisión Exhaustividad Q1 1 1 Q2 0.67 1 Q3 0.55 1 Precisión media: 0.74 128 Además, se registraron los objetos recuperados en la primera página de los resultados (primeros 9) elementos: Query de búsqueda Relevantes recuperados Irrelevantes Recuperados Precisión primera página Q1 9 0 1 Q2 7 2 0.77 Q3 5 4 0.55 Precisión media: 0.77  Búsqueda avanzada: Para la búsqueda simple se realizaron búsquedas con 3 cadenas de búsqueda las cuales fueron: o Q1: Búsqueda sin negativos y condicionales o Q2: Búsqueda con negativos o Q3: Búsqueda con cláusula condicional Se realizaron las pruebas con un total de 150 objetos indexados en Apache Solr y los resultados fueron registrados en la siguiente tabla: Query de búsqueda Relevantes recuperados Recuperados Relevantes totales Q1 44 53 44 Q2 16 21 25 Q3 5 7 15 Query de búsqueda Precisión Exhaustividad 129 Q1 0.83 1 Q2 0.76 0.64 Q3 0.71 0.33 Precisión media: 0.76 Además, se registraron los objetos recuperados en la primera página de los resultados (primeros 9) elementos: Query de búsqueda Relevantes recuperados Irrelevantes Recuperados Precisión primera página Q1 8 1 0.89 Q2 6 3 0.67 Q3 4 5 0.44 Precisión media primera página: 0.67  Conclusiones: Si bien los resultados obtenidos no son iguales a los grados ideales de precisión y exhaustividad tampoco se alejan mucho de estos, por lo que no se puede concluir que la funcionalidad de búsqueda en el repositorio no sea eficaz. Los resultados obtenidos reflejan que para los dos tipos de búsqueda más de la mitad de los resultados recuperados son correctos, incluso para los resultados de la primera página siendo la búsqueda avanzada con cláusulas condicionales la menos precisa en términos de precisión y exhaustividad. A medida que más usuarios suban objetos al repositorio e indiquen cuales son más útiles y relevantes se deberán hacer estas pruebas de nuevo para evaluar cuanto han influido los usuarios en los valores de precisión y exhaustividad y así 130 poder decidir si ajustar o no los pesos para cada parámetro al momento de realizar las búsquedas. 131 Anexo H: Pruebas de integración  Prerrequisitos: Se utilizarán dos Objetos de Aprendizaje almacenados en el repositorio para probar la interoperabilidad con los entornos de prueba o “Organización del imperio Inca”, Objeto de Aprendizaje de tipo archivo, cuenta con varias versiones, este recurso será utilizado para verificar que se exporte la última versión del objeto o una versión específica. o “Test quiz”, Objeto de Aprendizaje de tipo URL, recurso de tipo interactivo que será utilizado para verificar que se transfiera información entre el recurso y el entorno de pruebas.  Ejecución de la prueba 1 – LTI con objeto versionable En la página de detalle del objeto, hacer clic al botón “Exportar”, se mostrará una pantalla con los siguientes datos: url para exportar la última versión del objeto, url para exportar la versión que se muestra en la página, llave y secreto LTI. (Ver imagen 27). Figura 32: Datos para exportar mediante LTI – prueba 1 En los Sistemas de Gestión de Aprendizaje de prueba subir un recurso usando la opción “Herramienta externa” e ingresar la URL, secreto y llaves provistas por el repositorio. (Ver imagen 28). 132 Figura 33: Agregar recurso LTI en Moodle Acceder al recurso y verifcar que se muestre la versión correcta del Objeto de Aprendizaje. (Ver imagen 29) Figura 34: Descarga de Objeto de Aprendizaje con LTI  Ejecución de la prueba 2 – Objeto interactivo En la página de detalle del objeto, hacer clic al botón “Exportar”, se mostrará una pantalla con los siguientes datos: url para exportar la última versión del objeto, url para exportar la versión que se muestra en la página, llave y secreto LTI. (Ver imagen 30). 133 Figura 35: Datos para exportar mediante LTI – prueba 1 En los Sistemas de Gestión de Aprendizaje de prueba subir un recurso usando la opción “Herramienta externa” e ingresar la URL, secreto y llaves provistas por el repositorio. (Ver imagen 31). Figura 36: Agregar Objeto LTI en Canvas 134 Acceder al recurso y verifcar que se muestre la versión correcta del Objeto de Aprendizaje. (Ver imagen 32) Figura 37: Objeto de Aprendizaje interactivo Responder el cuestionario mostrado y hacer clic al botón “Submit” al terminar. En los Sistemas de Gestión de Aprendizaje verificar que se haya registrado la nota resultante de responder el cuestionario. (Ver imagen 31). Figura 38: Objeto de Aprendizaje interactivo 135 Anexo I: Diccionario de datos Esta sección incluye una descripción de las tablas que conforman el sistema, incluyendo la descripción de cada uno de sus atributos. User Tabla general de usuario Atributo Tipo Descripción Id(PK) Integer Identificador único de usuario firstName Varchar(255) Nombre real del usuario lastName Varchar(255) Primer apellido de usuario Email Varchar(255) Correo electrónico de usuario Username Varchar(255) Nombre de usuario Password Varchar(255) Contraseña del usuario lastName2 Varchar(255) Segundo apellido del usuario (opcional) Learning_object Tabla con atributos de un Objeto de Aprendizaje Atributo Tipo Descripción Id(PK) Int Identificador único Location Varchar(255) Localización en donde el objeto está almacenado Key Varchar(255) Identificador del objeto en AWS S3 Created DATETIME Fecha de creación del objeto Updated DATETIME Fecha de la última modificación authorId(FK) Int Id del usuario creador del objeto 136 Language Varchar(255) Lenguaje en que está el objeto Keyword Varchar(255) Palabra o término clave que describe el objeto usedFor Varchar(255) Organización, persona o entidad para la cual fue creado el objeto usedBy Varchar(255) Uso que se le dará al objeto title Varchar(255) Título del objeto educationTypeId(FK) Int Id del tipo del nivel de educación al que el objeto está orientado resourceTypeId(FK) Int Id del tipo de recurso del objeto description Varchar(255) Descripción del contenido del objeto licenceId(FK) int Id del tipo de licencia que posee el objeto Category Tabla que contiene las categorías a las que un objeto puede pertenecer Atributo Tipo Descripción Id(PK) Int Identificador único Name Varchar(255) Nombre de la categoría parent int Id de categoría padre 137 Learning_object_categories_category Tabla en donde se almacena la relación categoría – objeto de aprendizaje Atributo Tipo Descripción learningObjectId(PK) Int Id del Objeto de Aprendizaje categoryId(PK) Int Id de la categoría Session Tabla en donde se almacenan los datos relativos a una sesión de usuario Atributo Tipo Descripción Id(PK) Int Identificador único token Varchar(255) JWT Token de la sesión emission DATE Fecha de emisión del token userId(FK) int Id del usuario que pertenece la sesión Permit Permisos de modificador sobre un Objeto de Aprendizaje Atributo Tipo Descripción Id(PK) Int Identificador único Reason Varchar(255) Justificación por la que se requiere el permiso State Int Estado de la solicitud. 0 = creado, 1 = aprobado y 2 = negado requesterId Int Id del usuario que solicita el permiso ownerId Int Id del usuario que otorga el permiso 138 learningObjectId int Id del Objeto de Aprendizaje sobre el que se pide el permiso Resource_type Tipo de recurso que puede ser un Objeto de Aprendizaje Atributo Tipo Descripción Id(PK) Int Identificador único name Varchar(255) Nombre del tipo de recurso education_type Tipo de nivel educativo al que está orientado un Objeto de Aprendizaje Atributo Tipo Descripción Id(PK) Int Identificador único name Varchar(255) Nombre del nivel de educación Useful_count Tabla que contiene indicación sobre los eventos “Me parece útil” de un Objeto de Aprendizaje Atributo Tipo Descripción Id(PK) Int Identificador único learningObjectId(PK) Int Id del Objeto de Aprendizaje categoryId(PK) Int Id de la categoría 139 version Atributos de una versión de un Objeto de Aprendizaje Atributo Tipo Descripción versionId(PK) Int Identificador único Active Int Indicador si la versión almacenada es la versión actual del objeto Created DATETIME Fecha de creación de la versión learningObjectId(FK) Tin Id del Objeto de Aprendizaje modifierId(FK) Int Id del usuario creador de la nueva versión Mimetype Varchar(255) Mimetype del archivo del Objeto de Aprendizaje Size int Tamaño en bytes del archivo del Objeto de Aprendizaje Filename Varchar(255) Nombre del archivo del Objeto de Aprendizaje changeDescription Varchar(255) Descripción de los cambios que se realizaron al crear una nueva versión license Tipos de licencia que puede tener un Objeto de Aprendizaje Atributo Tipo Descripción Id(PK) Int Identificador único licenseType Varchar(255) Tipo de licencia 140 Derivated Atributos de un Objeto de Aprendizaje derivado Atributo Tipo Descripción Id(PK) Int Identificador único learningObjectId(FK) Int Id del Objeto de Aprendizaje versionId(FK) Varchar(255) Id de la versión