Environnement d’exécution SCORM

Aperçu de l’environnement d’exécution SCORM

La spécification d’exécution SCORM contrôle la façon dont le LMS lance le contenu et comment le contenu communique ensuite avec le LMS. Toute cette communication se fait dans le cadre d’une seule tentative sur un seul SCO. La navigation entre les SCO est régie par le séquençage spécifié dans le manifeste, et expliqué plus en détail ici.

Lancement de contenu

Tout le contenu SCORM doit être livrable sur le Web et toute communication SCORM se produit dans le contexte d’une session de navigateur Web. Le LMS lancera un SCO à la fois, tel que sélectionné par l’utilisateur, ou tel que déterminé par les règles de séquençage SCORM 2004. Dans les versions antérieures à la 3e édition de SCORM 2004, il n’y avait pas d’exigences formelles pour l’interface utilisateur fournie par un LMS. Chaque LMS est légèrement différent, mais pour la plupart, il est juste de s’attendre à ce qu’un LMS fournisse une interface similaire à celle illustrée ci-dessous. Au minimum, il doit contenir une certaine forme de table des matières navigable ainsi que des commandes de navigation de flux (boutons précédent et suivant). Ces éléments de navigation contrôlent la navigation entre les OCS. Si la navigation est nécessaire au sein d’un OCS, celui-ci doit fournir ses propres éléments de navigation.

Le LMS dispose de deux options pour lancer un SCO. Il peut soit lancer le jeu de cadres SCO ina (comme illustré ci-dessus), soit lancer le SCO dans une nouvelle fenêtre. Certains LMS lanceront toujours du contenu d’une manière ou d’une autre. Généralement cependant, si un cours ne contient qu’un seul SCO (et ne nécessite donc pas d’éléments de navigation du LMS), le SCO sera lancé dans une fenêtre contextuelle. Inversement, si le cours contient de nombreux SCO, le LMS lancera généralement les SCO dans un jeu de cadres entouré d’éléments de navigation. Certains LMS permettront aux auteurs de contenu de contrôler précisément comment les SCO sont lancés, quels éléments de navigation sont disponibles et même la taille des fenêtres SCO.

L’API

Toutes les communications entre un SCO et le LMS se font via une API ECMAScript (JavaScript). C’est le seul moyen de communication. Il n’y a pas d’autres canaux de communication disponibles. Le contenu ne peut pas communiquer via des services Web, des publications de formulaires, des écritures de base de données ou tout autre mécanisme, uniquement via l’API JavaScript fournie par le LMS.

Recherche de l’API

Le LMS est chargé de fournir un objet JavaScript spécifiquement nommé à un emplacement spécifique dans le DOM du navigateur. Ainsi, le contenu, peut toujours localiser cette API en utilisant un algorithme commun.

Dans SCORM 1.1 et SCORM 1.2, l’objet API est toujours nommé « API ». Dans SCORM 2004, l’objet est nommé « API_1484_11 ».

L’objet API doit être situé dans une fenêtre qui est un parent de la SCO ou un parent de la fenêtre d’ouverture de la SCO. Une fenêtre « parent » est définie comme étant l’ensemble de la chaîne de fenêtres parentes jusqu’à la fenêtre du navigateur racine. Ainsi, l’API peut être dans le parent du SCO, le parent du parent du SCO, le parent du parent du SCO, etc. De même, l’API peut se trouver dans la fenêtre de l’ouvreur, le parent de l’ouvreur, le parent du parent de l’ouvreur, etc. Les diagrammes ci-dessous de la spécification de la 3e édition de SCORM 2004 illustrent les emplacements possibles des API.

SCORM inclut des algorithmes spécifiques que le contenu peut utiliser pour trouver l’API SCORM.

Utilisation de l’API

Une fois qu’un SCO a trouvé l’API SCORM, il peut utiliser l’API pour communiquer avec le LMS. Notez que seul l’OCS peut initier la communication. Le LMS est une entité passive qui répond simplement aux appels d’API effectués par le contenu. Le LMS ne peut initier aucune communication, il lance simplement le contenu et répond aux demandes.

L’API SCORM contient huit méthodes avec les signatures suivantes :

SCORM 2004

 Initialize("") : bool Terminate("") : bool GetValue(élément: CMIElement) : string SetValue(élément : CMIElement, value: string): string Commit(""): bool GetLastError(): CMIErrorCode GetErrorString(errorCode: CMIErrorCode): string GetDiagnostic(Errocode: 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

Les noms des méthodes varient légèrement entre les versions de SCORM, mais conceptuellement, les méthodes sont identiques.

Notes:

• Le type bool est un booléen SCORM, qui est en fait une chaîne ayant la valeur « true » ou « false ».
• Le paramètre «  » est requis par toutes les méthodes SCORM qui n’acceptent aucun autre argument. Les SCO doivent simplement transmettre un paramètre de chaîne vide à ces méthodes.
• Le type de données CMIElement est une chaîne correspondant aux éléments du modèle de données SCORM décrits ci-dessous.
• Le type de données CMIErrorCode est un nombre à trois chiffres, représenté par une chaîne, qui correspond à l’un des codes d’erreur d’exécution SCORM.

Initialize/LMSInitialize

La méthode Initialize indique au LMS que le contenu souhaite démarrer une session de communication. Tous les SCOS doivent appeler Initialize avant d’effectuer toute autre communication. Le LMS renvoie un booléen indiquant le succès ou l’échec de l’initialisation. En règle générale, les LMS n’ont pas besoin de faire beaucoup d’initialisation et retourneront toujours « true ».

Terminate/LMSFinish

La méthode Terminate indique au LMS que le contenu a fini de communiquer. Tous les SCO doivent appeler Terminate. Appeler Terminate n’indique pas nécessairement que l’utilisateur a terminé avec le SCO, techniquement, cela indique seulement que le SCO a fini de communiquer. En pratique cependant, le contenu sera plus compatible et utilisable si Terminate n’est appelé que lorsque le contenu peut être retiré à l’utilisateur. Puisque Terminate doit toujours être appelé, quelle que soit la façon dont l’apprenant quitte le SCO, il est sage de placer un appel pour terminer dans l’événement onunload d’un SCO. La valeur booléenne renvoyée par le LMS indique souvent si les données SCO ont été conservées avec succès sur le serveur.

GetValue/LMSGetValue

La méthode GetValue permet à un SCO de récupérer des données du LMS. Les données qui sont toujours récupérées sont l’un des éléments du modèle de données SCORM définis. Chacun de ces éléments du modèle de données contient une donnée différente. Certains des éléments du modèle de données ont des valeurs initialisées par le LMS qui parlent des circonstances dans lesquelles le SCO est lancé. D’autres valeurs sont initialisées par le SCO via des appels à SetValue. Si l’appel à GetValue renvoie une chaîne vide, il est possible qu’une erreur se soit produite et que la méthode GetLastError soit appelée pour rechercher des problèmes.

SetValue/LMSSetValue

La méthode SetValue permet au SCO de conserver les données dans le LMS. Les données sont toujours stockées dans l’un des éléments de modèle de données SCORM définis. Certains éléments du modèle de données sont contraints d’avoir des valeurs dans un vocabulaire limité (par exemple, le statut peut être « terminé » ou « passé »), d’autres sont contraints d’être un type de données spécifique (par exemple, le score doit toujours être un nombre) tandis que d’autres permettent à l’OCS de conserver des données de texte libre sans signification sémantique. L’appel SetValue renvoie un booléen indiquant le succès ou l’échec de l’appel.

Commit/LMSCommit

La méthode Commit signale au LMS qu’un nombre important de données a été enregistré et qu’elle doit s’assurer que les données sont correctement conservées. Il n’y a aucune exigence sur la façon dont le LMS doit implémenter la méthode Commit, il s’agit simplement d’un signal informatif. Certains LMS effectueront un aller-retour vers le serveur pour chaque appel à valider afin de s’assurer que toutes les données sont conservées. Bien qu’intuitive, cette stratégie de mise en œuvre peut entraîner des problèmes d’évolutivité. Veillez à ne pas appeler Commit de manière excessive afin de ne pas surcharger ces LMS.

GetLastError/LMSGetLastError

La méthode GetLastError vérifie si le dernier appel d’API SCORM a provoqué une erreur. Si c’est le cas, cette méthode renvoie un numéro d’erreur qui correspond à un ensemble défini d’erreurs possibles. Certains numéros d’erreur représentent des situations parfaitement légitimes (comme l’élément de modèle 403-Data Non Initialisé). Les auteurs de SCO doivent veiller à ne signaler à l’utilisateur que les erreurs légitimement inattendues. La liste complète des codes d’erreur se trouve dans le tableau de référence d’exécution SCORM.

GetErrorString/ LMSGetErrorString

Étant donné un numéro d’erreur particulier (généralement le numéro d’erreur renvoyé par GetLastError), la méthode GetErrorString renverra une description textuelle de ce que signifie le code d’erreur. Par exemple, dans SCORM 2004, le passage du numéro d’erreur « 406 » renverra une chaîne indiquant « Inadéquation du type d’élément du modèle de données » pour indiquer que le résultat de l’appel précédent (probablement un SetValue) a échoué car les données stockées n’étaient pas dans le bon format.

GetDiagnostic / LMSGetDiagnostic

La méthode GetDiagnostic permet au LMS de renvoyer des informations détaillées sur l’erreur antérieure qui peuvent être utiles pour diagnostiquer le problème. Par exemple, les informations de diagnostic pour l’erreur « 406 » mentionnée ci-dessus peuvent être « La valeur « zéro » n’est pas autorisée pour cmi.Note.brut. Le cmi.Note.l’élément brut doit contenir un nombre valide représenté uniquement sous forme de chiffres « .

Le modèle de données d’exécution SCORM

Le modèle de données d’exécution contient de nombreux éléments, chacun ayant sa propre signification. Les éléments peuvent être lus et écrits à l’aide de l’API. Le graphique de référence d’exécution SCORM contient une liste de chaque élément du modèle de données ainsi que son type de données et une brève description de sa signification et de son utilisation.

Chaque SCO a son propre ensemble de données d’exécution. Chacun de ces éléments de modèle de données a une valeur distincte pour chaque SCO d’un cours, les éléments de modèle de données ne sont pas partagés entre les SCO. De plus, chaque « tentative » sur un SCO a son propre ensemble de données d’exécution. Lorsque l’apprenant commence une nouvelle tentative sur un SCO, les valeurs du modèle de données sont réinitialisées pour le début de la nouvelle tentative.

Les éléments du modèle de données sont légèrement différents selon les versions de SCORM, mais pour la plupart, il existe un élément correspondant dans chaque version des normes. SCORM 1.1 et SCORM 1.2 ont des modèles de données identiques. SCORM 2004 a un ensemble de modèles de données différent. Il existe également des différences subtiles mineures entre les éditions de SCORM 2004. Le tableau fournit une référence complète pour chaque version/édition. Les changements les plus significatifs de SCORM 2004 sont les suivants:

• Renommage mineur, supprimant principalement le « noyau » des noms d’éléments du modèle de données.
• Séparation de statut. Dans SCORM 1.2, un seul élément, cmi.core.lesson_status représente le statut de l’OCS. Dans SCORM 2004, le statut est divisé en deux éléments distincts, cmi.completion_status (terminé vs incomplet) et cmi.success_status (réussite vs échec).
• Les interactions (résultats des questions) sont en lecture/écriture au lieu d’en écriture seule. Les interactions contiennent également un champ de description qui faisait défaut dans SCORM 1.2.
• Ajout d’adl.nav.* les éléments de modèle de données qui permettent au SCO d’initier des demandes de séquençage

En utilisant le temps d’exécution

En utilisant le temps d’exécution SCORM est largement facultatif du point de vue de la conformité stricte, mais la norme du secteur consiste à utiliser au moins un sous-ensemble des éléments de modèle de données d’exécution disponibles.

Au plus simple, si votre cours ne contient que des ressources lancables, aucun appel d’exécution n’est nécessaire. Le LMS lance simplement chaque actif à la demande de l’utilisateur et l’actif est considéré comme terminé immédiatement après le lancement.

Pour une interaction plus riche, la première chose à faire est d’activer la communication à l’exécution. Cela impliquera de trouver l’API, puis de s’assurer que Initialize et Terminate sont appelés. Dans la plupart des cas, Initialize doit être appelé immédiatement après le lancement du SCO. Une fois initialize appelé, il est essentiel que Terminate soit appelé dans chaque scénario de sortie.

Une fois la communication initialisée, il est temps de commencer à communiquer réellement les données. Les éléments de modèle de données  » 1er niveau  » suivants sont les plus importants et les plus couramment utilisés (SCORM 1.2 équivalent entre parenthèses):

• cmi.état d’achèvement & cmi.statut de réussite (cmi.core.lesson_status) – Ces éléments du modèle de données sont les plus fondamentaux et les plus importants. Ils indiquent quand un utilisateur a terminé un cours et s’il a réussi ou échoué. Ces informations fondamentales sont essentielles pour la plupart des LMS.
• cmi.Note.mise à l’échelle (cmi.core.Note.brut) – Indique le score que l’apprenant a obtenu sur toute évaluation au sein d’un SCO. Signaler un score min et max en conjonction avec un score brut est également une bonne forme.
• cmi.session_time (cmi.core.session_time– – Indique le temps que l’apprenant a passé dans le SCO.
• cmi.emplacement (cmi.core.lesson_location– – Fournit un champ de texte libre pour que le SCO enregistre un signet. Si le SCO est plus grand que quelques pages HTML, il devrait envisager d’implémenter une fonctionnalité de mise en signet pour permettre à l’apprenant de reprendre une tentative en pause.
• cmi.sortie (cmi.core.exit) – Cette valeur indique comment l’apprenant quitte le SCO. Réglage du cmi.quitter pour « suspendre » garantira que la tentative en cours est préservée et que les données d’exécution ne sont pas réinitialisées lors du prochain lancement du SCO. Réglage du cmi.la sortie sur «  » indiquera que le LMS devrait commencer une nouvelle tentative avec un nouvel ensemble de données d’exécution lors du prochain lancement du SCO.

La norme industrielle s’attend à ce que tous les éléments des modèles de données de 1er niveau soient utilisés correctement dans un SCO. Une fois cette fonctionnalité activée, les éléments suivants du modèle de données les plus courants, ou 2ème niveau, incluent:

• interactions – Utilisez les éléments du modèle de données sur les interactions pour rapporter les résultats de chaque réponse à la question. Une interaction ne doit pas nécessairement être une réponse de test traditionnelle. Par exemple, un OCS pourrait documenter les choix de l’apprenant au fur et à mesure qu’il progresse dans une simulation. Si possible, utilisez tous les éléments d’interaction pour fournir l’image la plus complète des réponses de l’apprenant. Utilisez au minimum « id », « type », « résultat » et « description » pour permettre aux LMS de fournir des rapports de base.
• objectifs – Dans les grandes OCS, envisager de rendre compte de la maîtrise par l’apprenant d’objectifs d’apprentissage spécifiques à l’aide des éléments du modèle de données des objectifs. Les objectifs permettent de rendre compte plus granulaire des progrès de l’apprenant et de la maîtrise du matériel de formation.
• cmi.progress_measure – Utilisez l’élément progress_measure dans SCORM 2004 pour signaler les progrès de l’utilisateur vers l’achèvement d’un SCO. La mesure progress_measure est comme une mesure de « pourcentage d’achèvement » qui permettrait au LMS de fournir une barre de progression de l’achèvement global d’un cours.

Entrée, Mode et crédit

Le cmi.entrée (cmi.core.entrée), cmi.mode (cmi.core.mode de cours) et cmi.crédit (cmi.core.les éléments du modèle de données fournissent à l’OCS un contexte qu’il peut utiliser pour fournir à l’apprenant l’expérience optimale.

• cmi.l’entrée indique si l’utilisateur démarre le SCO pour la première fois ou s’il reprend une tentative antérieure. Si vous utilisez des signets, le SCO peut utiliser cette valeur pour inviter l’utilisateur à commencer depuis le début ou à partir du point auquel la tentative précédente s’est terminée.
• cmi.le mode indique si l’apprenant lance ce SCO : normalement – dans une session de formation « en direct »; en mode navigation – l’utilisateur parcourt un catalogue de formations et souhaite « prévisualiser » ce cours; ou, en mode révision – l’utilisateur a déjà terminé le SCO et revient pour revoir le matériel. En mode navigation, l’auteur du SCO devrait envisager de modifier le comportement du SCOs pour offrir une navigation plus libre, fournir une vue d’ensemble ou une carte du cours et éventuellement masquer les évaluations. En mode révision, l’auteur de l’OCS devrait également envisager de permettre aux plus maigres une totale liberté de navigation. En mode révision, l’apprenant peut également naviguer librement dans tous les tests et parcourir une liste de bonnes réponses. Lorsqu’il est lancé en mode révision, un SCO doit veiller à ne pas modifier le statut de l’apprenant ni réinitialiser le score.
• cmi.le crédit indique si cette OCS est ou non une tentative de crédit, ou si elle « compte » ou non. Similaire au mode de navigation, si un SCO est lancé sans crédit, le comportement devrait probablement être modifié.