¿Qué es SCORM?
SCORM son las siglas de Shareable Content Object Reference Model (Modelo Referenciado de Objetos de Contenido Compartible). Es una especificación técnica que permite el intercambio de contenidos entre diferentes plataformas de teleformación (LMS) que sean compatibles con esta especificación.
SCORM provee de los métodos de comunicación y de los modelos de datos que posibilitan que los contenidos y las plataformas de teleformación trabajen juntos.
Un poco de historia
Cómo otras muchas iniciativas, SCORM surgió de un problema del Departamento de Defensa de los Estados Unidos. El ejército se encontró que tenía una gran cantidad de manuales de formación de los distintos cuerpos, tierra, mar y aire, que no podían compartir entre ellos. Para solventar el problema crearon un laboratorio llamado Advanced Distributed Learning (ADL), cuya tarea fue recopilar iniciativas de formatos ya existentes, y desarrollar las suyas propias. El objetivo final era concebir una especificación que permitiera distribuir el contenido formativo en cualquier sistema de gestión de aprendizaje compatible. Era el año 1999.
SCORM es una especificación, pero no es un estándar, aunque se haya convertido en un estándar de facto para la industria del e-learning.
Existen varias versiones de SCORM:
SCORM 1.0, del año 2000.
SCORM 1.1, que apareció rápidamente teniendo en cuenta las inquietudes y sugerencias de la comunidad y de los participantes en el proyecto.
SCORM 1.2, del año 2001.
SCORM 2004 (SCORM 1.3) Ahora mismo se encuentra en la cuarta edición, presentada en el año 2009.
En contra de lo que es habitual en todos los intentos de estandarización, la versión de SCORM más utilizada no es la más reciente, sino que es SCORM 1.2, del año 2001. Y esto es un punto importante a tener en cuenta. Aún a día de hoy, la mayor parte de los proveedores de contenidos te venderán sus cursos en formato SCORM 1.2 y los contenidos SCORM 2004 son casi inexistentes. Existen diversos motivos para ello, pero los principales son la mayor complejidad para la creación de los paquetes, que tardaron años en lanzar un proceso para certificarlos y, como en muchas otras cosas, que SCORM 1.2 era lo suficientemente bueno para un gran porcentaje de los casos.
La diferencia entre la versión más utilizada, SCORM 1.2, y la última, SCORM 2004, se encuentra fundamentalmente en la separación de los estados de las lecciones. Mientras que en SCORM 1.2 la lección puede tomar los estados "pasado", "fallado", "completado", "incompleto", "visto" o "No intentado", en la versión SCORM 2004 se separaron los estados. Por un lado tenemos los estados de finalización de la lección ("completado"/"incompleto") y por otro los estados de éxito ("aprobado"/"suspenso"), esto permite a los tutores tener más información acerca del desempeño del alumno sobre el contenido. Aunque, por otro lado, cuando un contenido es una evaluación no suele necesitar el estado de "Completado"/"Incompleto" puesto que si se ha evaluado es que se ha completado el contenido.
La otra gran diferencia es la secuenciación de los contenidos, esto significa que SCORM 2004 provee de las herramientas necesarias para poder crear rutas predefinidas y por lo tanto restringidas para los alumnos, de esta forma define el orden en el cual se tienen que realizar los contenidos, si bien esto se pisa mucho con las responsabilidades de la propia plataforma de e-learning.
Pongámonos (mínimamente) técnicos: ¿Cómo funciona SCORM?
SCORM se encarga de dos funciones:
Empaquetamiento del contenido
Cuando se genera un contenido SCORM tenemos, por un lado los archivos físicos que lo forman, que pueden ser de cualquier tipo: vídeo, texto plano, HTML, etc. ordenados en sus carpetas correspondientes de la forma que deseemos. Y por otro lado, tenemos los archivos de definición propios de SCORM, que ahora explicaremos con más detalle. Es decir, SCORM nunca va a decidir cómo deberemos crear ni ordenar nuestro contenido.
SCORM empieza a entrar en juego a través de su modelo de agregación de contenido, que se encarga de describir el orden y las propiedades del contenido que se va a entregar al LMS. La definición del contenido viene dada por los SCOs (Sharable Content Objects) objetos de contenidos compartidos, que son las unidades básicas de información de un paquete SCORM. Esto no significa que un SCO defina un archivo físico del contenido, ya que un SCO puede estar compuesto por múltiples archivos, representando una unidad lógica de aprendizaje y además a su vez puede estar relacionado con otros SCOs.
Todo este conjunto de definiciones viene "escrito" en un archivo de metadatos (un archivo de metadatos es aquel que lleva información acerca de otros datos, en este caso información acerca de la definición del contenido) que sirve para representar el contenido de una forma común y predefinida para todos los LMS, este archivo se llama imsmanifest.xml.
Comunicación contenidos-plataforma
La otra parte de SCORM es la comunicación entre el contenido y la plataforma. SCORM expone una API (Application Programming Interface. Una API es un medio para que dos softwares se comuniquen) que permite que el contenido se comunique con la plataforma de teleformación para que pueda enviar y recuperar información. Por ejemplo, en dónde se encuentra el alumno dentro del contenido, qué nota ha sacado en caso de que realice una evaluación, cuánto tiempo ha estado un alumno dentro un contenido, etc.
Hay que tener muy claro que es responsabilidad del contenido ofrecer esta información y la responsabilidad del LMS es guardarla y entregarla al contenido cuando se la solicite, para que este la procese de nuevo y realice las acciones pertinentes.
Por ejemplo, entra un alumno en un contenido que consta de 10 puntos, se queda en el punto 5 y sale del LMS. En ese momento, el contenido suministra los datos al LMS para que los guarde. Cuando este alumno vuelva a entrar en ese contenido más tarde, el LMS expone esos datos y el contenido es el encargado de moverse al punto 5 después de haber procesado esa información. Toda esta secuencia de comunicación se realiza con la API de SCORM.
El futuro de SCORM
SCORM es una tecnología que podría considerarse anticuada para los tiempos que se manejan en el software. Lo que más se le achaca a SCORM es que no proporciona suficiente información, es poco flexible y que solamente se pueda utilizar dentro de un LMS. Pero no hay ninguna duda de que sigue realizando su función y lo hace razonablemente bien.
Existen nuevas especificaciones como la Experience API (también conocida como Tin-Can API o xAPI), que vienen a sustituir a SCORM en parte, pero que todavía no han alcanzado el grado suficiente de adopción.
En el año 2011, el organismo ADL en el que se originó SCORM encargó a una empresa externa la creación del sucesor de la especificación. El resultado fue xAPI. Se centra en conseguir que todas las experiencias de aprendizaje, dentro y fuera de un LMS, cuenten para el historial de conocimiento de los alumnos. Así, contenidos consumidos en aplicaciones móviles, artículos de la Web, vídeos de YouTube, una simulación en un juego... Incluso experiencias no digitales, fuera de línea... Todo ello se puede recoger en un repositorio central de experiencias de cada alumno llamado LRS (Learning Record Store), que no tiene por qué formar parte de un LMS, aunque trabajan con ellos.
Es un concepto interesante pero no suple algunas necesidades concretas que tienen los contenidos empaquetados que se utilizan en las plataformas de e-learning. Digamos que xAPI puede sustituir a la parte de comunicación de SCORM, pero no a la de empaquetamiento. Por otro lado un LMS y un LRS son sistemas completamente diferentes y se sigue necesitando un LMS si queremos ofrecer un contenido empaquetado tradicional, con una experiencia y acceso común, tutorías, etc... en oposición a un formato de formación más libre, basado en cientos o miles de microexperiencias no necesariamente conectadas.
Por lo tanto, SCORM seguirá entre nosotros por lo menos unos cuantos años más.
