Entorno de tiempo de ejecución SCORM

Descripción general del entorno de tiempo de ejecución SCORM

La especificación de tiempo de ejecución SCORM controla cómo el LMS inicia el contenido y cómo el contenido se comunica con el LMS. Toda esta comunicación ocurre en el contexto de un solo intento de una sola OCS. La navegación entre SCOs se rige por la secuencia especificada en el manifiesto, y se explica más adelante aquí.

Lanzamiento de contenido

Todo el contenido de SCORM debe entregarse en la web y toda la comunicación de SCORM se produce en el contexto de una sesión de navegador web. El LMS lanzará un SCO a la vez, según lo seleccione el usuario, o según lo determinado por las reglas de secuenciación SCORM 2004. En versiones anteriores a SCORM 2004 3a Edición, no había requisitos formales para la interfaz de usuario proporcionada por un LMS. Cada LMS es ligeramente diferente, pero en su mayor parte, es justo esperar que un LMS proporcione una interfaz similar a la que se muestra a continuación. Como mínimo, debe contener algún tipo de tabla de contenido navegable, así como controles para la navegación de flujo (botones anterior y siguiente). Estos elementos de navegación controlan la navegación entre SCOs. Si se necesita navegación dentro de una OCS, la OCS debe proporcionar sus propios elementos de navegación.

El LMS tiene dos opciones para lanzar un SCO. Puede lanzar el conjunto de marcos SCO ina (como se muestra en la imagen de arriba) o puede lanzar el SCO en una nueva ventana. Algunos LMS siempre lanzarán contenido de una forma u otra. Comúnmente, sin embargo, si un curso solo contiene un SCO (y por lo tanto no requiere elementos de navegación del LMS), el SCO se iniciará en una ventana emergente. Por el contrario, si el curso contiene muchos SCO, entonces el LMS comúnmente lanzará los SCO en un conjunto de cuadros rodeado de elementos de navegación. Algunos LMS permitirán a los autores de contenido controlar con precisión cómo se lanzan los SCO, qué elementos de navegación están disponibles e incluso el tamaño de las ventanas SCO.

La API

Toda la comunicación entre un SCO y el LMS se realiza a través de una API ECMAScript (JavaScript). Esta es la única manera de que ocurra la comunicación. No hay otros canales de comunicación disponibles. El contenido no puede comunicarse a través de servicios web, publicaciones de formularios, escrituras de bases de datos o cualquier otro mecanismo, solo a través de la API de JavaScript proporcionada por el LMS.

Encontrar la API

El LMS es responsable de proporcionar un objeto JavaScript con nombre específico en una ubicación específica dentro del DOM del navegador. Por lo tanto, el contenido, siempre puede localizar esta API utilizando un algoritmo común.

En SCORM 1.1 y SCORM 1.2, el objeto API siempre se denomina «API». En SCORM 2004, el objeto se llama «API_1484_11».

El objeto API debe estar ubicado en una ventana que sea padre de la SCO o padre de la ventana de apertura de la SCO. Una ventana «padre» se define como la cadena completa de ventanas padre hasta la ventana del navegador raíz. Por lo tanto, la API podría estar en los padres de la SCO, los padres de los padres de la SCO, los padres de los padres de los padres de la SCO, etc. Del mismo modo, la API podría estar en la ventana del abridor, el padre del abridor, el padre del padre del abridor, etc. Los diagramas a continuación de la especificación de la 3a Edición SCORM 2004 ilustran las posibles ubicaciones de la API.

SCORM incluye algoritmos específicos que el contenido puede usar para encontrar la API SCORM.

Usando la API

Una vez que un SCO ha encontrado la API SCORM, puede usar la API para comunicarse con el LMS. Tenga en cuenta que solo la OCS puede iniciar la comunicación. El LMS es una entidad pasiva que simplemente responde a las llamadas a la API realizadas por el contenido. El LMS no puede iniciar ninguna comunicación, simplemente inicia el contenido y responde a las solicitudes.

La API SCORM contiene ocho métodos con las siguientes firmas:

SCORM 2004

 Initialize( "" ) : bool Terminate ( "" ): bool getValue (elemento : CMIElement): string setValue (elemento : CMIElement, valor: string): string Commit ( "" ): bool GetLastError (): CMIErrorCode GetErrorString ( errorCode: CMIErrorCode ): string GetDiagnostic (errocCode : CMIErrorCode): string

SCORM 1.1 / SCORM 1.2

LMSInitialize( "" ) : bool LMSFinish( "" ) : bool LMSGetValue( element : CMIElement ) : string LMSSetValue( element : CMIElement, value : string) : string LMSCommit( "" ) : bool LMSGetLastError() : CMIErrorCode LMSGetErrorString( errorCode : CMIErrorCode ) : string LMSGetDiagnostic( errocCode : CMIErrorCode ) : string

Los nombres de los métodos varían ligeramente entre las versiones de SCORM, pero conceptualmente los métodos son idénticos.

Notas:

• El tipo bool es un booleano SCORM, que en realidad es una cadena que tiene el valor «true»o » false».
• El parámetro «» es requerido por todos los métodos SCORM que no aceptan ningún otro argumento. Los SCO simplemente se requieren para pasar un parámetro de cadena vacío a estos métodos.
• El tipo de datos CMIElement es una cadena que corresponde a los elementos del modelo de datos SCORM descritos a continuación.
• El tipo de datos CMIErrorCode es un número de tres dígitos, representado por una cadena, que corresponde a uno de los códigos de error en tiempo de ejecución de SCORM.

Initialize / LMSInitialize

El método Initialize indica al LMS que el contenido desea iniciar una sesión de comunicación. Todos los SCO deben llamar a Initialize antes de realizar cualquier otra comunicación. El LMS devuelve un booleano que indica el éxito o el fracaso de la inicialización. Por lo general, los LMS no necesitan hacer mucha inicialización y siempre devolverán «true».

Terminar / LMSFinish

El método Terminar indica al LMS que el contenido se ha terminado de comunicar. Todos los SCO deben llamar a Terminar. La terminación de llamada no indica necesariamente que el usuario ha terminado con la SCO, técnicamente solo indica que la SCO ha terminado de comunicarse. En la práctica, sin embargo, el contenido será más compatible y utilizable si Terminate solo se llama cuando el contenido se puede quitar al usuario. Dado que se requiere que se llame siempre a Terminate, sin importar cómo salga el alumno de la SCO, es aconsejable realizar una llamada para Terminar en el evento onunload de una SCO. El valor booleano devuelto por el LMS a menudo indica si los datos SCO se conservaron correctamente en el servidor o no.

getValue / LMSGetValue

El método getValue permite a una SCO recuperar datos del LMS. Los datos que siempre se recuperan son uno de los elementos definidos del modelo de datos SCORM. Cada uno de estos elementos del modelo de datos contiene una pieza de datos diferente. Algunos de los elementos del modelo de datos tienen valores inicializados por el LMS que se refieren a las circunstancias en las que se está lanzando la OCS. Otros valores son inicializados por el SCO a través de llamadas a setValue. Si la llamada a getValue devuelve una cadena vacía, es posible que se haya producido un error y que se invoque el método GetLastError para comprobar si hay problemas.

setValue / LMSSetValue

El método setValue permite al SCO conservar los datos en el LMS. Los datos siempre se almacenan en uno de los elementos definidos del modelo de datos SCORM. Algunos elementos del modelo de datos están limitados a tener valores en un vocabulario limitado (por ejemplo, el estado puede ser «completado» o «pasado»), otros están limitados a ser un tipo de datos específico (por ejemplo, la puntuación siempre debe ser un número), mientras que otros permiten que la SCO conserve datos de texto libre sin significado semántico. La llamada setValue devuelve un booleano que indica el éxito o el fracaso de la llamada.

Commit / LMSCommit

El método Commit indica al LMS que se ha guardado una cantidad significativa de datos y que debe asegurarse de que los datos se conserven correctamente. No hay requisitos sobre cómo el LMS debe implementar el método de confirmación, es simplemente una señal informativa. Algunos LMS harán un viaje de ida y vuelta al servidor para cada llamada a confirmar para garantizar que todos los datos se conserven. Aunque intuitiva, esta estrategia de implementación puede generar problemas de escalabilidad. Tenga cuidado de no llamar a Commit en exceso para no sobrecargar estos LMS.

GetLastError / LMSGetLastError

El método GetLastError comprueba si la última llamada a la API SCORM causó un error. Si es así, este método devuelve un número de error que corresponde a un conjunto definido de posibles errores. Algunos números de error representan situaciones perfectamente legítimas (como el elemento de Modelo de datos 403 No Inicializado). Los autores de la OCS deben tener cuidado de señalar al usuario únicamente errores inesperados legítimos. La lista completa de códigos de error se puede encontrar en el gráfico de referencia de tiempo de ejecución SCORM.

GetErrorString / LMSGetErrorString

Dado un número de error en particular (generalmente el número de error devuelto por GetLastError), el método GetErrorString devolverá una descripción textual de lo que significa el código de error. Por ejemplo, en SCORM 2004, pasar el número de error » 406 «devolverá una cadena que dice» Data Model Element Type Mismatch » para indicar que el resultado de la llamada anterior (probablemente un valor de conjunto) falló porque los datos almacenados no estaban en el formato correcto.

GetDiagnostic / LMSGetDiagnostic

El método GetDiagnostic permite al LMS devolver información detallada sobre el error anterior que puede ser útil para diagnosticar el problema. Por ejemplo, la información de diagnóstico para el error» 406 «mencionado anteriormente podría ser» El valor ‘cero’ no está permitido para cmi.puntaje.crudo. El cmi.puntaje.el elemento raw debe contener un número válido representado solo como dígitos».

El modelo de datos en tiempo de ejecución SCORM

El modelo de datos en tiempo de ejecución contiene muchos elementos, cada uno de los cuales tiene su propio significado. Los elementos se pueden leer y escribir utilizando la API. El gráfico de referencia de tiempo de ejecución SCORM contiene una lista de cada elemento del modelo de datos junto con su tipo de datos y una breve descripción de su significado y uso.

Cada SCO tiene su propio conjunto de datos en tiempo de ejecución. Cada uno de estos elementos del modelo de datos tiene un valor separado para cada OCS dentro de un curso, los elementos del modelo de datos no se comparten entre las OCS. Además, cada «intento» en un SCO tiene su propio conjunto de datos en tiempo de ejecución. Cuando el alumno inicia un nuevo intento en un SCO, los valores del modelo de datos se restablecerán para el inicio del nuevo intento.

Los elementos del modelo de datos son ligeramente diferentes entre las versiones de SCORM, pero en su mayor parte hay un elemento correspondiente en cada versión de los estándares. SCORM 1.1 y SCORM 1.2 tienen modelos de datos idénticos. SCORM 2004 tiene un conjunto de modelos de datos diferente. También hay pequeñas diferencias sutiles entre las ediciones de SCORM 2004. El gráfico proporciona una referencia completa para cada versión / edición. Los cambios más significativos en SCORM 2004 incluyen:

• Cambio de nombre menor, principalmente eliminando el» núcleo » de los nombres de elementos del modelo de datos.
• Separación del estatuto. En SCORM 1.2 un solo elemento, cmi.núcleo.lesson_status representa el estado del SCO. En SCORM 2004, el estado se divide en dos elementos separados, cmi.completion_status (completado vs incompleto) y cmi.success_status (pasado vs fallado).
• Las interacciones (resultados de preguntas) son de lectura/escritura en lugar de solo escritura. Las interacciones también contienen un campo de descripción que faltaba en SCORM 1.2.
• Adición de adl.nav.* elementos de modelo de datos que permiten al SCO iniciar solicitudes de secuenciación

Utilizando el tiempo de ejecución

El uso del tiempo de ejecución SCORM es en gran medida opcional desde una perspectiva de estricta conformidad, sin embargo, la norma del sector es utilizar al menos un subconjunto de los elementos de modelo de datos en tiempo de ejecución disponibles para usted.

En la forma más sencilla, si su curso no contiene nada más que activos ejecutables, no se necesitan llamadas en tiempo de ejecución. El LMS simplemente lanza cada activo según lo solicite el usuario y el activo se considera completado inmediatamente después del lanzamiento.

Para una interacción más rica, lo primero que necesitamos hacer es habilitar la comunicación en tiempo de ejecución. Esto implicará encontrar la API y luego asegurarse de que se llama a Inicializar y Terminar. En la mayoría de los casos, se debe llamar a Initialize inmediatamente después de que se inicie el SCO. Una vez que se ha llamado a initialize, es esencial que se llame a Terminate en cada escenario de salida.

Una vez inicializada la comunicación, es hora de comenzar a comunicar los datos. Los siguientes elementos del modelo de datos de» 1er nivel » son los más importantes y los más utilizados (SCORM 1.2 equivalente entre paréntesis):

• cmi.completion_status & cmi.success_status (cmi.núcleo.lesson_status) – Estos elementos del modelo de datos son los más fundamentales e importantes. Indican cuándo un usuario ha terminado un curso y si lo ha aprobado o no. Esta información fundamental es esencial para la mayoría de los LMS.
• cmi.puntaje.escalado (cmi.núcleo.puntaje.raw) – Indica la puntuación que el alumno obtuvo en cualquier evaluación dentro de una OCS. Informar de una puntuación mínima y máxima junto con una puntuación bruta también es una buena forma.
• cmi.hora de la sesión (cmi.núcleo.session_time) – Informa la cantidad de tiempo que el alumno pasó en la SCO.
• cmi.ubicación (cmi.núcleo.lesson_location) – Proporciona un campo de texto libre para que el SCO grabe un marcador. Si el SCO es más grande que un par de páginas HTML, debería considerar implementar una función de marcadores para permitir que el alumno reanude un intento en pausa.
• cmi.salida (cmi.núcleo.exit) – Este valor indica cómo el alumno está saliendo de la SCO. Configuración del cmi.salir para «suspender» asegurará que el intento actual se conserve y que los datos en tiempo de ejecución no se restablezcan la próxima vez que se inicie el SCO. Configuración del cmi.salir a «» indicará que el LMS debe comenzar un nuevo intento con un nuevo conjunto de datos de tiempo de ejecución en el próximo lanzamiento de la SCO.

La norma de la industria espera que todos los elementos de modelos de datos de 1er nivel se utilicen correctamente en una SCO. Una vez habilitada esa funcionalidad, los siguientes elementos más comunes del modelo de datos, o segundo nivel, incluyen:

• interacciones: Utilice los elementos del modelo de datos de interacciones para informar los resultados de cada respuesta a la pregunta. Una interacción no tiene que ser una respuesta de prueba tradicional. Por ejemplo, un SCO podría documentar las elecciones del alumno a medida que avanza a través de una simulación. Si es posible, utilice todos los elementos de interacciones para proporcionar la imagen más completa de las respuestas del alumno. Como mínimo, use «id», «tipo», «resultado» y «descripción» para permitir que los LMS proporcionen informes básicos.
• objetivos-En los SCO grandes, considere la posibilidad de informar sobre el dominio del alumno de objetivos de aprendizaje específicos utilizando los elementos del modelo de datos de objetivos. Los objetivos permiten informar de manera más detallada sobre el progreso del alumno y el dominio del material de capacitación.
• cmi.progress_measure: Utilice el elemento progress_measure en SCORM 2004 para informar del progreso del usuario hacia la finalización de un SCO. progress_measure es como una medida de «porcentaje completo» que permitiría al LMS proporcionar una barra de progreso de la finalización general de un curso.

Entrada, Modo y Crédito

El cmi.entrada (cmi.núcleo.entrada), cmi.modo (cmi.núcleo.lesson_mode) y cmi.crédito (cmi.núcleo.créditos) los elementos del modelo de datos proporcionan a la OCS un contexto que puede utilizar para proporcionar al alumno la experiencia óptima.

• cmi.la entrada indica si el usuario está iniciando el SCO por primera vez o si está reanudando un intento anterior. Si utiliza marcadores, la SCO puede usar este valor para pedirle al usuario que comience desde el principio o desde el punto en el que terminó el intento anterior.
• cmi.el modo indica si el alumno está lanzando esta OCS: normalmente, en una sesión de entrenamiento «en vivo»; en el modo de exploración, el usuario está navegando por un catálogo de entrenamiento y desea» previsualizar » este curso; o, en el modo de revisión, el usuario ya ha completado la OCS y vuelve a revisar el material. En el modo de exploración, el autor de SCO debe considerar la posibilidad de alterar el comportamiento de SCOs para proporcionar una navegación de forma más libre, proporcionar una visión general o un mapa del curso y posiblemente ocultar las evaluaciones. En el modo de revisión, el autor de la OCS debe considerar de manera similar permitir una mayor libertad de navegación. En el modo de revisión, el alumno también puede navegar libremente por cualquier prueba y navegar por una lista de respuestas correctas. Cuando se inicia en modo de revisión, una OCS debe tener cuidado de no cambiar el estado del alumno o restablecer la puntuación.
• cmi.crédito indica si se está intentando obtener crédito o no, o si «cuenta» o no. Al igual que en el modo de exploración, si se lanza un SCO sin crédito, es probable que el comportamiento se altere.