Prototipo de integración de contenidos de aprendizaje con tecnologías web 2.0 implantado en Moodle como plataforma de aprendizaje

M a r i a M. S i a c h o q u e - J u a n V i l l a n u e v a - J u l i o B a r ó n V e l a n d i a V Í N C U L O S J U L I O D E 2 0 1 3 VOLUMEN 10 NÚMERO 2 Prototipo de integración de contenidos de aprendizaje con tecnologías web 2.0 implantado en Moodle como plataforma de aprendizaje Integration of learning contents prototype with web 2.0 technologies implemented in Moodle learning platform Maria M. Siachoque* 1 Juan Villanueva** Julio Barón Velandia*** Fecha de recepción: 30 de mayo de 2013 Fecha de aceptación: 15 de junio de 2013 Resumen El prototipo de integración de contenidos de aprendizaje pretende no solo la integración obtenida en Moodle como plataforma educativa sino también su enlace con la web 2.0 y el reuso de recursos para que la gestión del aprendizaje sea más cómoda y se pueda desarrollar esta tarea, facilitando la ubicación de recursos que permitan elaborar unidades de aprendizaje que permiten ejemplificar y apoyar actividades de enseñanza dentro y fuera del aula. Las enseñanzas presentadas a los estudiantes en las aulas de clase reduce el esfuerzo en el diseño y elaboración de unidades de aprendizaje. * Estudiante de ingeniería de sistemas de la Universidad Distrital Francisco José de Caldas. Ha liderado proyectos de desarrollo de software enfocados en áreas académicas y empresariales. Participó como expositora en la Quinta conferencia latinoamericana de objetos de aprendizaje (LACLO) 2010, realizada en Sao Paulo, Brasil. ** Estudiante de ingeniería de sistemas de la Universidad Distrital Francisco José de Caldas. Su especialidad es el desarrollo de software sobre herramientas SAP. Participo como expositora en la Quinta conferencia latinoamericana de objetos de aprendizaje (LACLO) 2010 realizada en Sao Paulo, Brasil. *** Correo electrónico: jbaron@udistrital.edu.co 325

A T Prototipo de integración de contenidos de aprendizaje con tecnologías web 2.0 implantado en Moodle como plataforma Palabras clave: Aprendizaje, educación, objetos de aprendizaje, colaboración. Abstract This paper aims to show the advantages, disadvantages and characteristics of electronic education through the implementation of LCMS (Learning Content Management System). It also illustrate the architecture and components of a learning content integration system through Web 2.0, which can manage learning contents, e-learning contents, learning objects and individual actives such as images, animations and videos. It includes a repository where these components are stored, authoring tools or integration with them, a tool to publish courses, communication and collaboration tools for the task force that developed the course content and the ability to integrate with an LMS. This will seek to integrate CMS and LCMS functionality, Web services, navigation, content, updating and retrieval of information, improving end-user experience in elearning approach. Key words: Learning, education, learning objects, repository, collaboration 326 1. Aprendizaje colaborativo Los procesos de autoaprendizaje soportados en tecnologías de información, se convierten en una oportunidad para mejorar la forma en que las personas acceden a recursos educativos, permitiendo la ampliación de la cobertura para el incremento de los niveles de aprendizaje y e-learning, que además posibilitan un apoyo en la difusión de los procesos de enseñanza y aprendizaje en ambientes virtuales, garantizando la facilidad de acceso de los usuarios a información web específica. Se permite también ampliar los intercambios de ideas, los foros de discusión y el acceso a grandes cantidades de información, superando las diferentes falencias que las herramientas de gestión de contenidos de aprendizaje presentan en cuanto a la rigurosidad y linealidad en el manejo de contenidos y la posibilidad de flexibilizarlos, anulando las distancias geográficas y temporales. Sin embargo y a pesar del creciente y continuo crecimiento de las herramientas tecnológicas y de comunicación, se ha generado paralelamente un analfabetismo tecnológico que supone la exclusión de muchos sectores de la población, debido a la rigidez y complejidad de la implementación de los sistemas administradores de contenido actuales y a la falta de socialización de estas herramientas educativas, demostrando cómo la incursión que han tenido dichas tecnologías en el apoyo educativo ha sido mínima en comparación con el desarrollo de las mismas. Cómo superar las falencias que los CMS y LMS presentan en cuanto a la rigurosidad y

M a r i a M. S i a c h o q u e - J u a n V i l l a n u e v a - J u l i o B a r ó n V e l a n d i a V Í N C U L O S J U L I O D E 2 0 1 3 VOLUMEN 10 NÚMERO 2 linealidad en el manejo de contenidos y la posibilidad de flexibilizarlos? El uso del software como herramienta educativa dentro del proceso de aprendizaje anula las distancias geográficas y temporales; sin embargo las herramientas existentes se enfocan hacia usuarios de un sistema específico y no hacia la diversidad de seres humanos que las utilizan, igualmente la subsistencia de módulos independientes que trabajan con estas herramientas dificultan la fluidez del proceso de aprendizaje. Es así como se plante la pregunta de cómo mejorar la integración y usabilidad de módulos de aprendizaje débilmente acoplados y cuál es la forma eficiente y efectiva para humanizar el proceso de aprendizaje electrónico teniendo en cuenta su desarrollo asincrónico para servir de apoyo al proceso de autoaprendizaje?. Los sistemas que promueven los procesos de enseñanza y aprendizaje a través del e-learning tienen una gran importancia para consolidar y unificar el conocimiento. No obstante, el desarrollo de sistemas que apoyen el autoaprendizaje está en sus fases iniciales y le falta un largo camino por recorrer hasta alcanzar su madurez y consolidación. El panorama actual de los LMS está caracterizado por su gran dispersión, ya que todavía no existe ningún liderazgo claro comparable al existente en otras áreas de software. En el mercado existen LMS de muchos fabricantes distintos. Por ello se hace necesaria una normativa que compatibilice los distintos sistemas y cursos a fin de lograr dos objetivos: Que un curso de cualquier fabricante pueda ser cargado en cualquier LMS de otro fabricante. Que los resultados de la actividad de los usuarios en el curso puedan ser registrados por el LMS. Para el cumplimiento de dichas normativas se han desarrollado especificaciones a nivel mundial. Dentro de los más reconocidos se encuentra SCORM (del inglés Sharable Content Object Reference Model) [2], que es una especificación que permite crear objetos pedagógicos estructurados que puedan importarse dentro de los diferentes sistemas de gestión de aprendizaje, siempre que estos soporten la norma SCORM. Los principales requerimientos que el modelo SCORM trata de satisfacer son: Accessibilidad: capacidad de acceder a los componentes de enseñanza desde un sitio distante a través de las tecnologías web, así como distribuirlos a otros sitios. Adaptabilidad: capacidad de personalizar la formación en función de las necesidades de las personas y organizaciones. Durabilidad: capacidad de resistir a la evolución de la tecnología sin necesitar reconfiguración o una reescritura del código. Interoperabilidad: capacidad de utilizarse en otro emplazamiento y con otro conjunto de herramientas o sobre otra plataforma de componentes de enseñanza desarrolladas dentro de un sitio, con un cierto conjunto de herramientas o sobre una plataforma específica. Existen numerosos niveles de interoperabilidad (física, sintáctica, semántica). Reusabilidad: flexibilidad que permite integrar componentes de enseñanza dentro de múltiples contextos y aplicaciones. Con este prototipo se pretenden integrar las funcionalidades de los módulos LMS y CMS de contenido académico y servicios web enfocados en la navegación de contenidos, actualización de información y consulta de la misma, mejorando la experiencia del usuario final en el enfoque del aprendizaje electrónico. 327

A T Prototipo de integración de contenidos de aprendizaje con tecnologías web 2.0 implantado en Moodle como plataforma 328 Cabe aclarar que con una integración de tecnologías de información en la que diversas herramientas puedan contribuir a disminuir la brecha de aprendizaje en el mundo, muchas personas verían fortalecido su proceso educativo de manera significativa, con mayor flexibilidad y agilidad que la ofrecida en la educación tradicional. 2. Arquitecturas tecnológicas para la integración con plataformas e-learning: Moodle Las arquitecturas tecnológicas que integran o son integradas son fundamentales en la construcción de los sistemas de gestión del conocimiento, pues estos utilizan una gran variedad de herramientas tecnológicas y su necesidad de integración, conllevan a que las diversas herramientas suplan los requerimientos de mensajería, navegación y búsqueda. La definición de arquitecturas tecnológicas nos ayuda a generar un marco de trabajo generalizado, permitiendo definir estrategias dentro de las TI. Se define una arquitectura tecnológica como un conjunto de patrones y abstracciones que brindan un marco de referencia básico para la guía de la construcción del software para un sistema de información. Según Ian Somerville, en su libro Ingeniería de Software (capitulo 14, pagina 296), una vez se han definido las interacciones entre el sistema de software que se está diseñando y el entorno del sistema, se puede utilizar esta información como base para diseñar la arquitectura del sistema, tratando de descomponer un sistema de tal forma que las arquitecturas sean lo más sinceras posibles. La arquitectura de software define cada uno de los componentes que llevan a cabo las tareas de automatización de componentes de software que realizan algún proceso computacional y su comunicación. La web responde a un modelo cliente-servidor, un paradigma de división del trabajo en el que se efectúan peticiones de servicio teniendo en cuenta un protocolo y servidores que responden a las peticiones. Para el desarrollo de este tipo de sistemas se necesita un protocolo que permite la comunicación de un nodo de origen a otro de destino (http), un lenguaje de representación de hipertextos que incluye información sobre la estructura y formato de los mismos y una arquitectura que define el comportamiento de cada uno de sus componentes. Existen diferentes técnicas de arquitectura software como REST (Representational State Transfer), que permiten desarrollar servicios y aplicaciones como una serie de URL activos y SOA, definidos dentro de una arquitectura orientada a servicios que precisan la utilización de servicios para dar soporte a los requisitos del negocio. Mientras que REST se basa únicamente en el protocolo http, y permite exprimir las optimizaciones y las cachés de las CDNs que existen en la nube, la pila de protocolos de SOA es más compleja y no utiliza las optimizaciones para http. 2.1. Arquitectura REST REST (Representational State Transfer) es una técnica de arquitectura de software para sistemas distribuidos que manejan un conjunto de métodos o procedimientos para escribir, diseñar o componer contenidos que tengan texto, video, audio, mapas u otros medios y que además tenga la posibilidad de interactuar con los usuarios. Un ejemplo de estos sistemas es Internet. El siguiente gráfico muestra la arquitectura que es manejada por el estándar REST:

M a r i a M. S i a c h o q u e - J u a n V i l l a n u e v a - J u l i o B a r ó n V e l a n d i a V Í N C U L O S J U L I O D E 2 0 1 3 VOLUMEN 10 NÚMERO 2 Figura 1. Arquitectura REST: composición de las diferentes capas de aplicación tanto en el cliente como en el servidor utilizando una versión modificada del patrón MVC Fuente: elaboración propia. REST es una forma de diseñar aplicaciones que están comunicadas usando mensajes HTTP y XML. El término REST se usa para describir cualquier interfaz web simple, sin abstracciones de protocolos basados en patrones de intercambio de mensajes. De esta manera es posible el diseño de sistemas de servicios web con REST y diseño de interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto sin usar SOAP. REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños fundamentales clave: Un protocolo cliente/servidor sin estado en el que cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes. Sin embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesión. Un conjunto de operaciones bien definidas que se aplican a todos los recursos de información: HTTP en sí define un conjunto pequeño de operaciones, las más importantes son POST, GET, PUT y DE- LETE. Con frecuencia estas operaciones se equiparan a las operaciones CRUD que se requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema, una sintaxis universal para identificar los recursos. En un sistema REST cada recurso es direccionable únicamente a través de su URI. El uso de hipermedios, tanto para la información de la aplicación como para las 329

A T Prototipo de integración de contenidos de aprendizaje con tecnologías web 2.0 implantado en Moodle como plataforma transiciones de estado de la aplicación: la representación de este estado en un sistema REST son típicamente HTML o XML. Como resultado de esto es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional. Un concepto importante en REST es la existencia de recursos, que pueden ser accedidos utilizando un identificador global. Para manipular estos recursos los componentes de la red (clientes y servidores) se comunican a través de una interfaz estándar (HTTP) e intercambian representaciones de estos recursos. Un ejemplo de recurso URI se presenta graficado a continuación: Figura 2. Ejemplo de una jerarquía de recursos URI. Los recursos son objetos con links relacionales a otros recursos Fuente: elaboración propia. La petición puede ser tramitada por cualquier número de conectores (por ejemplo clientes, servidores, cachés, túneles, etc.) pero cada uno lo hace sin ver más allá de su propia petición (lo que se conoce como separación en capas, otra restricción de REST, que es un principio común con muchas otras partes de la arquitectura de redes y de la información). Así, una aplicación puede interactuar con un recurso conociendo el identificador del recurso y la acción requerida, no necesitando conocer si existen cachés, proxys, cortafuegos, túneles o cualquier otra cosa entre ella y el servidor que guarda la información. La aplicación, sin embargo, debe comprender el formato de la información devuelta (la representación), que es por lo general un documento HTML o XML, aunque también puede ser una imagen o cualquier otro contenido. 330

M a r i a M. S i a c h o q u e - J u a n V i l l a n u e v a - J u l i o B a r ó n V e l a n d i a V Í N C U L O S J U L I O D E 2 0 1 3 VOLUMEN 10 NÚMERO 2 2.2. ATOM El formato de redifusión ATOM es una alternativa al RSS y hace referencia a dos estándares relacionado: El formato de redifusión ATOM, que es un fichero en formato XML usado para redifusión web. El protocolo de publicación ATOM, que es un protocolo simple basado en HTTP para crear o actualizar recursos en la web. Los canales web permiten a los programas buscar actualizaciones de contenido publicado en determinado sitio web. La fuente web puede ser descargada por sitios web que distribuyen el contenido usando la fuente o por un agregador, que permite a los lectores suscribirse y ver los contenidos de la fuente. El formato ATOM fue desarrollado como una alternativa a RSS; Ben Trott notó la incompatibilidad entre algunas versiones del protocolo RSS. ATOM es un formato de documentos basado en XML que describe una lista de información relacionada conocida como feeds, estas entradas están compuestas de un número de ítems que son un conjunto extensible de metadatos, por ejemplo cada entrada tiene un título. 2.3. Integración de servicios de Google Apps con Moodle El protocolo de datos de Google provee una manera segura a desarrolladores externos para la generación de nuevas aplicaciones y permitir a usuarios finales el acceso y actualización a datos guardados por los diferentes grupos de aplicaciones de Google. Los desarrolladores externos pueden usar directamente el protocolo de datos de Google o utilizar las librerías cliente soportadas para varios lenguajes de programación como Java, PHP y Python. Una serie de productos de Google, como Google Calendar y Youtube proporcionan APIs que se basan en el protocolo de datos de Google. El desarrollador puede utilizar estas API para escribir aplicaciones cliente que ofrecen a los usuarios finales nuevas maneras de acceder y manipular los datos que se almacenan en los productos de Google. Las API de Google Apps al estilo REST se basan en Atom Publishing Protocol (Atom- Pub), utilizando el formato de sindicación Atom estándar para representar datos y HTTP para administrar la comunicación. El protocolo del API de datos de Google también amplía AtomPub para procesar consultas, autenticación, solicitudes por lotes y para proporcionar diferentes formatos de salida (JSON, RSS). Estas API para el desarrollo en lenguaje PHP, se encuentran en el Zend Framework. En el siguiente gráfico se puede observar su arquitectura. La misión de Google es organizar la información y hacerla universalmente asequible y útil, esto implica hacerla accesible para contextos externos al explorador web y a servicios externos a Google. 331

A T Prototipo de integración de contenidos de aprendizaje con tecnologías web 2.0 implantado en Moodle como plataforma Figura 3. Arquitectura Zend Framework: Se pueden aplicar en patrones de diseño, da soporte para transacciones, logging y desarrollar objetualmente. Además es un framework propietario de una empresa que se encuentra detrás del desarrollo de PHP. Es soportado por empresas como Google e IBM y es fácil desacoplarlo de la arquitectura básica de Zend para crear una arquitectura propia dependiendo de las prácticas a implementar. Fuente: elaboración propia. 332 2.4. Autenticación y autorización a servicios de Google Apps La autenticación a los servicios de Google permite a un usuario acceder a sus funciones que vinculan contenido o información a una cuenta determinada de Google. Estas funciones requieren que el usuario o la aplicación proporcionen el nombre de usuario y la contraseña de Google de dicha cuenta. La siguiente lista muestra los diferentes tipos de autenticación manejado por Google Apps: La autenticación de proxy AuthSub permite a las aplicaciones web autenticar al usuario a los servicios de Google sin tener que acceder el usuario y contraseña de su cuenta. Se debe utilizar este tipo de autenticación si se desea crear una aplicación web que permita vincular archivos, comentarios, puntuaciones, contactos u otra información con una cuenta de Google. El protocolo OAuth proporciona un método estándar de acceder a datos protegidos desde diferentes sitios web. Mientras que los métodos AuthSub y Client- Login son específicos de Google, OAuth es un protocolo abierto que puede implementarse en otros sitios. Al igual que sucede con AuthSub, la autenticación OAuth es útil si se desea crear una aplicación web que permita a los usuarios vincular videos, comentarios, puntuaciones, contactos u otra información

M a r i a M. S i a c h o q u e - J u a n V i l l a n u e v a - J u l i o B a r ó n V e l a n d i a V Í N C U L O S J U L I O D E 2 0 1 3 VOLUMEN 10 NÚMERO 2 con una cuenta de Google. OAuth puede resultar realmente útil si la aplicación también se integra a varias API aparte de las de Google, y si dichas API también admiten el protocolo OAuth. La autenticación ClientLogin permite asociar todas las acciones del API con una única cuenta de Google. Si el cliente es una aplicación instalada, independiente y para un único usuario, como una aplicación de escritorio, se debe utilizar la autenticación ClientLogin. En este caso la aplicación pedirá al usuario que introduzca su nombre de usuario y su contraseña de Google y, a continuación, utilizará dichos valores para solicitar un token de autenticación ClientLogin. 3. Técnica metodológica La metodología trabajada se encuentra basa en el proceso unificado de desarrollo de software, por medio del cual se establecen las actividades necesarias para la transformación de los requisitos de los usuarios de un sistema en un proceso de software. 3.1. Actividades clasificadas en cada fase por flujos de trabajo 3.1.1. Fase de inicio Analisis y Diseño Modelado de negocio 1. Planteamiento del problema Definición de requerimientos funcionales (modelo inicial de casos de uso) Definición de requerimientos de información Descripción global del desarrollo Descripción de la oportunidad de negocio Definición de las consultas del sistema Definición de roles y responsabilidades Definición de actividades Definición de riesgos 3.1.2. Fase de elaboración Modelamiento y Requisitos Refinación de los requisitos funcionales y captura de los no funcionales Requisitos adicionales que capturen los requisitos no funcionales Descripción de la arquitectura de software Actualización de los artefactos entregables de la fase de inicio Análisis y Diseño Refinación de la arquitectura Diseño preliminar del modelo Prototipo de la arquitectura del sistema Implementación Elaboración e implementación de un prototipo funcional Pruebas Elaboración de un plan de pruebas 3.1.3. Fase de construcción Implementación Se implementaron las clases diseñadas y objetos determinados por los diagramas. Se integró el producto de software en la plataforma Moodle Cada desarrollador integró los módulos respectivos en el sistema y se decidió el orden en que se iba a implementar 333

A T Prototipo de integración de contenidos de aprendizaje con tecnologías web 2.0 implantado en Moodle como plataforma 334 Se desarrollaron los modelos completos Se desarrolló el manual inicial de usuario Se obtuvo un prototipo operacional Pruebas En las pruebas se evalúa la calidad del software que se está entregando. Se desarrollaron así: Pruebas y ajustes de interfaces Encontrar defectos en la calidad del software Se validaron los supuestos realizados en la fase de modelado de negocio y especificación de requerimientos por medio de demostraciones concretas Se verificó que los requisitos tuvieran adecuada implementación Instalación Instalación de entorno de prueba Instalación de entorno de producción Instalación de entorno de desarrollo 3.1.4. Fase de transición Implementación Se obtuvo un prototipo operacional Prueba de la versión primera Operación paralela con el sistema de prueba inicial ya desarrollado, que luego será reemplazado 4. Conclusiones Los riesgos asociados al desarrollo e implementación de componentes sobre sistemas de integración de contenidos de aprendizaje como Moodle se ven mitigados por el análisis, el diseño y el uso de herramientas como ajax, jquery, que facilitan la realización de cambios, teniendo en cuenta la arquitectura que ofrecen las plataformas educativas. La estandarización en el manejo de objetos de aprendizaje asociados a las tecnologías de información en la web 2.0 permite agilizar la construcción de contenidos educativos al tener un repositorio centralizado e indexado de objetos, en el caso de este proyecto, facilitó la ubicación de recursos que permiten elaborar unidades de aprendizaje para ejemplificar y apoyar actividades de enseñanza dentro y fuera del aula, reduciendo el esfuerzo en el diseño y elaboración de contenidos por parte del docente. El aporte que brinda este proyecto al usar herramientas web 2.0 basadas en un marco de desarrollo de software como up, permite además del consumo de servicios externos o disponibles en la nube que se brinde eficiencia y eficacia en el desarrollo, también facilitó la integración de componentes de aprendizaje en un sistema de manejo de contenidos como Moodle. 5. Referencias [1] Díaz-antón, Gabriela y Pérez, María. (2005). Hacia una ontología sobre lms. Proceeding VII Jornadas internacionales de las ciencias computacionales. México: Universidad de Ccolima. W.- K. Chen, Linear Networks and Systems (Book style). Belmont, CA: Wadsworth, 1993, pp. 123 135. [2] García, Lorenzo (2007). De la educación a distancia a la educación virtual. Barcelona: Ariel. B. Smith, An approach to graphs of linear forms (Unpublished work style), unpublished. [3] Sveiby, Karl-erik. (1996) What is knowledge management? Recuperado el 13 de octubre de 2012, de http://www. sveiby.com.au/knowledgemanagement.html. [4] Ortiz, F y Farley, Luis. (2007) Campus virtual: la educación más allá del lms. Re-

M a r i a M. S i a c h o q u e - J u a n V i l l a n u e v a - J u l i o B a r ó n V e l a n d i a V Í N C U L O S J U L I O D E 2 0 1 3 VOLUMEN 10 NÚMERO 2 vista de universidad de y sociedad del conocimiento (rusc) Universidad Oberta de Catalunya. Vol. 4, N. I. Págs. 1-7. [5] Piskurich, George. (2003) The ama handbook of e-learning: effective design, implementation, and technology solutions. Amacom, isbn: 9780814407219, nro. Pag. 496 [6] Rodríguez, Amparo (2009). Entornos virtuales en la enseñanza aprendizaje. Revista de formación e innovación educativa universitaria. Vol.2, N 2, Págs. 98-100. [7] Verdugo, H; Fuentes, C y Olivos, A (2009). Computación en la nube [en línea] Universidad Técnica Federico de Santa María. Recuperado 10 de octubre de 2011 de http://profesores.elo.utfsm.cl/~agv/ elo322/1s09/project/reports/computacionenlanube.pdf. [8] Yus, Rafael. (2010). Temas transversales, hacia una nueva escuela. Revista Eufonía. [Versión electrónica]. N. 23. Barcelona. Recuperado el 01 de febrero de 2012 en http://eufonia.grao.com/ revistas/eufonia/023-en-torno-a-lavozhumana/libros-temas-transversales-hacia-una-nueva-escuela. 335