Algunos buenos enlaces

Documentos pdf sobre scorm: Link

El RTE de SCORM

== RTE (Run-Time Environment) == El objetivo de SCORM es que los recursos de aprendizaje sean reusables e interoperables entre múltiples LMS. Para que esto pueda ser posible, debe existir: Una forma común para iniciar recursos de aprendizaje (Launch - lanzar). Este mecanismo define los procedimientos y las responsabilidades para el establecimiento de la comunicación entre el recurso de aprendizaje y el LMS. El protocolo de comunicación está estandarizado a través del uso de un API común. Un mecanismo común para que comunicarse con el LMS (API). La comunicación gira en torno al estado del recurso de aprendizaje (inicializado, terminado, condición de error) y además permite obtener y fijar datos (puntajes, límites, etc) entre el LMS y el SCO. Un lenguaje predefinido (vocabulario) que forme las bases de la comunicación (Data Model). En su forma más simple, el "modelo de datos" define elementos que tanto el LMS como el SCO están esperando conocer. El LMS debe mantener el estado de los elementos requeridos a través de sesiones, y el contenido de aprendizaje debe utilizar sólo estos elementos predefinidos para garantizar el reuso en diversos sistemas, que cumplan con la especificación de SCORM. LAUNCH Como está presente en el CAM de SCORM, el "Modelo de Contenido" de SCORM está conformado de los Assets, de los SCOs y de las "agregaciones de contenido". De ellos, los Assets y los SCOs pueden ser "iniciados" (lauched) por un LMS, y los procedimientos y las responsabilidades para el establecimiento de la comunicación entre los recursos de contenido y el LMS varian dependiendo del tipo de recurso de contenido. Asset: El "modelo de iniciamiento" de SCORM exige que un LMS inicie un Asset usando el protocolo HTTP. Dado que al asset no se le hace seguimiento, no necesita comunicarse y por lo tanto no hace uso del API ni del modelo de datos. SCO: El "modelo de iniciamiento" de SCORM exige que: El LMS lance uno y sólo un SCO al tiempo. El LMS es el único que puede iniciar un SCO. El LMS debe iniciar un SCO en la ventana de un browser que es una ventana hija o un frame hijo de la ventana del LMS que el Adpatador del API expone como un objeto del DOM. El adaptador del API debe ser proporcionado por el LMS. Es respondabilidad del SCO buscar recursivamente el padre hasta que el adptador del API sea encontrado para poder iniciar la comunicación con el LMS. API El uso de un API común satisface muchos de los requerimientos de más alto nivel de SCORM para la reusabilidad y la interoperabilidad. Proporciona un forma estandarizada a los SCO para comunicarse con los LMS, encapsulando la implementación de la comunicación del desarrollador. El adaptador del API es una pieza de software funcional, implementado por el LMS, que implementa las funciones del API y por medio de interfaces las hace disponibles a los clientes SCO. Una vez la comunicación entre el SCO y el LMS se establece, el SCO puede obtener y fijar información en el LMS. Toda la comunicación entre el adaptador del API y el SCO es iniciada por el SCO. Las funciones del adaptador del API pueden ser agrupados en tres grupos básicos: Ejecución del estado de un SCO: que permite iniciar y finalizar la ejecucicion de un SCO. Gestión del estado de un SCO: usadas para manejar errores. Transferencia de datos: usadas para transferir datos, obteniendo y fijando información. La comunicación entre el adaptador del API y el SCO pasa por una serie de estados bien determinados en tiempo de ejecución. Los estados son: No inicializado, Inicializado y Finalizado. No inicializado: El estado después de que el SCO ha sido "lanzado" y justo antes de sea inicializado (es decir, antes de que sea invocada la funcion de inicialización del API). Durante este estado es labor del SCO encontrar el Adaptador del API. Inicializado: Estado en el que se encuentra despues de ser inicializado y antes de ser terminado (silly?). Puede usar todos las funcioens del API, excepto la de inicialización. Finalizado: Es es estado en que se encuentre el SCO despues de invocar la funcion de terminacion. Puede acceder a las funciones de obtencion y manejo de errores, si el metodo de finalizacion no se llevo a cabo satisfactoriamente. Rol del LMS: SCORM exige que el LMS implemente un adaptador del api que implemente el API, haciendo uso de la encapsulación de forma que el SCO no tenga acceso a los los detalles de implementación. Las responsabilidades del adaptador del API son: El LMS debe lanzar el SCO en una ventana del browser que debe ser una venta o un frame hijo de la ventana del LMS el cual contiene el adpatador. El adaptador debe ser suministrador por el LMS. El único mecanismo permitido para la interacción entre el API y el SCO es a través de llamadas ECMAScript. El adaptador del api debe ser accesible por medio del DOM como un objeto llamado "API". El adapatador puede estar implementado en diversos lenguajes de programación como Java (haciendo uso de applets, por ejemplo) o C++ (como un plug-in del browser). La implementación del adaptador es responsabilidad del LMS. Rol del SCO Lo mínimo que debe hacer un SCO es invocar los métodos de inicialización y finalización del API. Para poder hacerlo, el contenido debe poder ubicar el adaptador. Es pues deber del contenido encontrar y establecer comunicación con el adaptador. MODELO DE DATOS La necesidad de definir un modelo de datos común es aseguranos que a un conjunto definido de información sobre un SCO se le puede hacer seguimiento sin importar el LMS en el que esté operando. Hay un número de modelo de datos bajo desarrollo en varios comités y organizaciones. Hasta la versión 1.2 de Scorm, el modelo de datos corresponde a una versión borrador (draft) de un modelo de datos. El modelo da datos del RTE: Para identificar el modelo de datos en uso, a las primeras palabras de los elementos que lo conforman. Todos los elementos utilizados por el modelo que utiliza SCORM fueron creados por el AICC CMI, por ellos es que todos los elementos comienzan con la palabra "cmi". Hay que aclarar una cosa y es que un SCO no puede acceder a los elementos de datos de otro SCO. Los elementos del modelo datos se clasifican en dos grandes grupos, que son la "obligada" y la "opcional". Todos los elementos "obligados" deben ser implementados por todos los LMS que cumplan con SCORM. Todo LMS está obligado a soportar: Todos los métodos y elementos del CORE (id, nombre, Ubicación de la lección, estado de la lección, etc) Todos los métodos y elementos que indiquen el desempeño del estudiante ("the raw", tiempo acumulado total, indicadores sobre como o por que se abandona un SCO, duracion de la ultima sesion, etc.) Los datos de suspensión y lanzamiento de un SCO.

El CAM de SCORM

La principal iniciativa que pretendemos, al inicio de este proyecto, es que la solución de aprendizaje desconectado se siga lo más posible a los lineamientos del standard con mas fuerza en el mundo del e-learning, SCORM. Para ello, es necesario entender los conceptos, y estructuras que propone SCORM en la definicion de los Objetos de aprendizaje, y sus estructuras de seguimiento. Comenzaremos con un resumen de los conceptos mas importantes del "Modelo de Agregación de Contenidos - CAM". == SCORM CAM: Modelo de Agregación de Contenidos == Representa un medio neutral y pedagógico para que los instructores adicionen recursos de aprendizaje con el propósito de crear una esperiencia de aprendizaje. El CAM de SCORM está constituido por: Modelo de contenido: Nomenclactura que define los componentes de contenido que constituyen una experiencia de aprendizaje. Meta-datos: Mecanismo para describir instancias específicas de los componentes del modelo de contenido. Empaquetamiento de contenido: Define cómo representar el comportamiento de una experiencia de aprendizaje (Estructura de contenido) y cómo empaquetar los recursos de contenido para el movimiento entre diferentes plataformas de aprendizaje (Empaquetiamiento de contenido). MODELO DE CONTENIDO Describe los componentes SCORM usados para construir una experiencia de aprendizaje con base en recursos de aprendizaje reusables. El modelo de contenido también define cómo, estos recursos de aprendizajes de bajo nivel reusables y compartibles, son agregados para conformar unidadades de instrucción de más alto nivel. Los componentes del modelo de contenido son considerados especializaciones de los recursos de aprendizaje. Está conformado por: Assets (activos), SCOs (Objetos de Contenido Compartibles) y Agregaciones de Contenido. Assets: Son considerados representaciones electrónicas de texto, imágenes, sonido, video o en general cualquier dato que pueda ser desplegados en un cliente web (un asset puede ser incluso TODA una página web). Un asset es descrito por medio de los "meta-datos de assets" para permitir búsqueda en los repositorios y el reuso. Los mecanismos para ligar un Asset a su metadato es el "empaquetamiento de contenido". SCO: Es el conjunto de uno o muchos assets que incluyen un asset especial que hace uso del RTE para comunicarse con el LMS y que puede ser lanzado, iniciado y finalizado. Un SCO representa el nivel de granuladidad más pequeño de los recursos de aprendizaje al que se le puede hacer seguimiento por un LMS usando el RTE. Un SCO debe ser independiente del contexto de aprendizaje para que pueda ser efectivamente reusable. Un SCO es un unidad subjetivamente pequeña de forma que se facilite el reuso. El tamaño subjetivo del SCO debería ser guiado por el contenido más pequeño al que se desearía hacer seguimiento a través del RTE. De igual manera, un SCO puede ser descrito haciendo uso del meta-dato del sco e igualmente queda ligado al SCO a través del "Empaquetamiento de Contenido". Algo importante para agregar acerca de los SCOs y su reusabilidad, es que sin importar con qué LMS fue generado, cualquier otro LMS puede hacerle seguimiento. Agregación de contenido: Es una "estructura de contenido" que puede ser usada para integrar recursos de aprendizaje en una unidad de instrucción cohesiva (como por ejemplo un curso, un capítulo, un módulo), para aplicar estructura y asociar taxonomías de aprendizaje. La estructura de contenido define la representación taxonómica de los recursos de aprendizaje. Una agragación de contenido puede tener referencia del "meta-dato de la agregación de contenido" para permitir la busqueda en los repositorios. La agregación de contenido define la estructura del contenido que proporciona los mecanismos para definir la SECUENCIA en que los recursos de aprendizaje deben ser presentrados al usuario. META-DATO La estructura de los meta-datos es una iniciativa que nació del IMS y que ha sido adaptada por ADL para SCORM, como una forma para describir, buscar y facilitar la creación de repositorios de recursos de aprendizajes. El "modelo de información" describe todos los elementos que conforman la estructura jerárquica para la creación de los metadatos en general. Existe una estructura de meta-datos particular, basada en la estructura general que propone el modelo de información, por cada componente del modelo de contenido (SCO, agregacion de contenido y los Asset). Esta particularización de la estructura de metadatos está definida en los "perfiles de aplicación de los metados a SCORM". EMPAQUETAMIENTO DE CONTENIDO El propósito del "empaquetamiento de contenido" es proporcionar una forma estandarizada para intercambiar recursos de aprendizaje digitales entre diferentes sistemas o herramientas. Además puede definir la estructura y el comportamiento de un grupo de recursos de aprendizaje. Define: Un archivo manifiesto que describe el paquete y que a su vez está compuesto por: Un archivo metadato del paquete Una sección opcional de "organización" que define la "estructura de contenido" y el comportamiento Una lista de referencias de los recursos en el paquete Las reglas para crear un manifiesto basado en XML Instrucciones para empaquetar el manifiesto y todos los archivos físicos relacionados en un archivo comprimido zip o en un CD-ROM, etc. Estructura de contenido: El propósito de la "estructura de contenido" es proveer al desarrollador de contenido los medios para agrupar recursos de contenido en una cohesiva unidad de instrucción, aplicar estructuras y asociar comportamientos específicos que pueden ser reproducidos uniformemente a través de ambientes LMS. Es como un mapa usado para recorrer los recursos de aprendizaje definidos en el paquete de contenido y el comportamiento que constituye la experiencia de aprendizaje. La estructura de contenido no define funcionalidades del LMS y se asume que cada LMS tiene representaciones privadas para los elementos de contenido y las estructuras, y que además permite exportar su estructura de cotenido (dentro de un paquete de contenido) de forma que otro LMS pueda importarla y guardarla en su formato local. De todas formas, es el LMS el que determina el orden (la secuencia) en que el contenido (recursos de aprendizaje) es mostrado al alumno. El LMS puede acceder a esta información a través de la "estructura de contenido", localizada en la sección de "organización" del empaquetamiento de contenido. La estructura de cotenido está conformada por tres partes. Jerarquía de cotenido: La cual define una representacion en forma de arbol, muy parecido a una tabla de contenidos, que agrupa los recursos de aprendizaje en un orgen lógico. En muchos casos, pero no en todos, esta estructura en arbol corresponde al orden por defecto en que el autor planea que el alumno navegue a través del material. Meta-datos específicos a un contexto: Cuando el desarrollador crea los recursos de aprendizaje crea junto con ellos meta-datos que definen el propósito, la descripción, el nombre, etc. Estos meta-datos son "independientes del contexto" en el que recurso de aprendizaje será usado. Pero cuando un grupo de recursos de aprendizaje son creados, debe existir un "metadato específico del contexto" que describe cómo cada recurso de aprendizaje es usado en ese grupo. Secuenciamiento y navegación: Le dice al LMS qué y cuando los recursos de aprendizaje deben ser presentados al alumno. Además, debería indicarle al usuario opciones para recorrer el contenido. Por ejemplo, la forma mas simple para recorrer los recursos de aprendizaje es siguiendo el arbol de contenido definido en la jerarquía de contenido. Navegaciones más complejas podrían estar basadas en el estado de finalización de ciertos recursos (que pueden ser definidos como pre-requisitos).

SCORM y el seguimiento

En nuestro contexto de aplicación, un estudiante desconectado (con conectividad a internet pobre o inexistente) debe poder disponer de un contenido y de una "experiencia de aprendizaje" tal y como se estuviera conectado disfruntando de todas las características y ventajas que el LMS le suministra, excepto probablemente, a todo lo que se encuentre por fuera del (de los) curso(s) que el estudiante esté tomando. Según SCORM, desde el punto de vista de un LMS el seguimiento se entiende como "el mantenimiento de información sobre el perfil del estudiante, el suministro de contenidos, y el monitoreo de las interacciones y el desempeño dentro del contenido para poder determinar lo que el estudiante debería expermientar próximamente"(*)... o al menos en el sentido estricto del seguimiento en línea. La pregunta que surge es si el seguimiento desconectado seguiría los mismos lineamientos de esta definición, si estaría en capacidad de hacerlo o incluso, si es correcto hacerlo. De todas formas, y expresando literalmente lo que dice la especificación, "La creación de SCOs que sean sujetos de seguimiento requiere un modelo estandard de la información que desea seguirse" (*). El RTE propone ese modelo estandard.

(*) Extraido de The Scorm Overview. Octubre 1, 2001. Version 1.2

¿SCORM nos cobija?

Bueno aquí comienza un resumen de los cosas mas importantes presentesen la especificación de SCORM 1.2.

Cuando uno busca en internet da la impresión que el contexto detrabajo en el que nos encontramos sencillamente sólo está presente ennuestro entorno. Parece que resulta inconcebible para el resto delmundo pensar en aprendizaje a distancia (o tecnicamenten mejordefinido como Technoligy-Based Instruction) sin contar conconectividad a Internet. Según la iniciativa ADL que se puede leer enla página 1-19 del overview de scorm se contemplan dos categorias deaprendizaje. El aprendizaje síncrono, también conocido como "Distance Learning" y el famosísimo aprendizaje asíncrono o "AdvancedDistributed Learning". Nuestro desarrollo cae en lo asíncrono por losiguiente:

SINCRONO al parecer implica el trabajo conjunto de grupos deestudiantes al mismo tiempo en lugares específicos aún estandofísicamente distantes del instructor. Las tecnologías que generalmenteabarcan este tipo de aprendizajes tienen que ver con "salones declases virtuales", es decir, que hagan uso de tele-entrenamiento porvideo, y tele-conferencia por video.

ASINCRONO se centra en cambio en en la capacitación disponible encualquier momento y en cualquier lugar. Dentro del grupo detecnologias que abarcan lo asíncrono, están los Technology-BasedTraining (que incluyen las basadas en computador, en multimedia y enweb) entre otras. Supone uno pues que los LCMS y los LMS caen en losWeb Based Training, y que el desarrollo "Desconectado" (si es querealmente es el término correcto) que está bajo nuestraresponsabilidad hacer, es un puente entre los Web Based Training y losComputer Based Instruction, entiendo la instrucción basada encomputador como las viejas aplicaciones que corrían en máquinas conprogramas de capacitación "stand-alone"..

Según ADL, la web y WBT son la base del presente y del futuro del aprendizaje porque las tecnologías basadas en web se están expandiendo rápidamente y se han vuelto la mejor forma de interoperar a todo elmundo, por lo tanto el mejor medio para enseñar; estandares sobre estas tecnologias de aprendizaje basada en web no existen formalmente y, lo que mas nos intereza a nosotros, porque el contenido web puede ser distribuido usando practicamente cualquier medio, aparte de lapropia internet, como son los CDs, los sistemas stand-alone y/oambientes conectados en red... Se supone que SCORM pretende ser laforma como ADL pretende lograr estas metas. En el cómo lo vamos alograr nostros? ahí está el dilema.

prologo

Hoy 8 de febrero de 2005 se crea el blog del proyecto de grado de ingerniería electrónica y telecomunicaciones de Victor Andrés Valencia y yo, Luis Eduardo Bravo. La intención principal de contar con este espacio es poder intercambiar informacion, la discusión de ideas, llevar un registro de las actividades realizadas. Con este blog esperamos que esta informacion sea de acceso libre a cualquier individuo además.
Se discutirá en general sobre el aprendizaje electrónico, particularizando en las herramientas tecnológicas que faciliten el acceso al contenido y permitan medir ciertas variables del proceso de aprendizaje, en entornos de conectvidad pobre o inexistente.