Se volessimo darne una definizione estremamente sintetica, lo SCORM è un protocollo a supporto dei contenuti e-learning.
In realtà, la definizione corretta recita che lo SCORM è un modello di riferimento per l’e-learning, qualcosa che assomiglia molto ad uno standard, ma senza l’ufficializzazione dell’ente IEEE (Istituto degli ingegneri elettrici ed elettronici), la più importante organizzazione al mondo nell’ambito dell’ingegneria elettrica ed elettronica e delle tecnologie dell’informazione.
In questo modello di riferimento, sono presenti varie direttive che possiamo dividere in tre macroaree:
- Struttura ed organizzazione dei file
- Metadati di descrizione ed organizzazione dei contenuti
- Protocollo di comunicazione con le piattaforme LMS
Alcuni di questi aspetti, come i metadata, hanno avuto un successo molto contenuto. Altri aspetti, come il protocollo di comunicazione, si sono diffusi prepotentemente a livello mondiale, facendo crescere l’e-learning e sviluppandosi poi insieme ad esso.
Lo SCORM, sebbene abbia ormai più di 20 anni, è ancora il sistema più diffuso per fruire e scambiare contenuti e-learning.
Storia e versioni dello SCORM
Le prime versioni di SCORM nascono all’inizio degli anni 2000 come evoluzione di un precedente protocollo chiamato AICC. Quando l’ADL, l’ente statunitense che si occupa di formazione distribuita, si rese conto che l’AICC non veniva usato solo in ambito militare, dove era nato, ma prendeva piede per la maggior parte dei contenuti detti WBT (Web Based Training) studiò un protocollo con uno scopo più generale.
Forte di innovazioni tecnologiche nel web, come il supporto dei browser per le chiamate asincrone XHR, l’ADL diede vita allo SCORM. Venne quasi immediatamente raffinato e perfezionato nella versione 1.2, ancora oggi la più diffusa.
Vista la notevole adozione, fu iniziato subito il lavoro sulla nuova versione, quella che poi venne chiamata 2004, la quale a sua volta venne ottimizzata nelle 4 versioni consecutive chiamate “edizioni”.
Oggi, quando qualcuno fa riferimento allo SCORM 2004, sottintende la terza edizione, che è quella che ha avuto un’adozione maggiore, sebbene comunque ancora inferiore alla versione 1.2.
La versione SCORM 2004 migliora la 1.2 sostanzialmente in 4 ambiti, in ordine di importanza:
- Distinzione tra punteggio e progresso
- Distinzione tra superamento e completamento
- Possibilità di navigare gli SCO in maniera non lineare (in un pacchetto MultiSCO)
- Possibilità di avere politiche annidiate e di roll back sugli obiettivi
Circa nel 2012 fa poi la sua comparsa il Tin Can – o, per dire meglio, l’xApi – che ha lo scopo di sostituire lo SCORM introducendo il supporto nativo per i dispositivi mobili e per la formazione informale.
Ultimo arrivato nei sistemi di tracciamento per l’e-learning è il CMI-5, un clone dell’xApi con delle direttive più fiscali, che ha lo scopo di correggere le lacune dell’xApi per promuoverne l’adozione.
Struttura del pacchetto scorm
Semplice ma fondamentale è la direttiva del modello SCORM riguardante la struttura del pacchetto.
Tutto parte dal formato del file, lo ZIP: un archivio compresso tramite il più comune sistema di compressione utilizzato nei nostri computer.
La compressione non è fondamentale solo per ridurre il “peso” dei corsi, ma ci permette anche di aggregare semplicemente e condensare in un unico file anche migliaia e migliaia di file di contenuto.
Avendo poi un unico file, questo diventa facilmente condivisibile, trasportabile e spesso anche allegabile via e-mail, se le sue dimensioni lo permettono. Questa semplice accortezza ne ha facilitato di molto l’adozione, soprattutto nei primi anni 2000 quando la digitalizzazione della maggior parte degli uffici Risorse Umane era ancora agli inizi.
Cosa c’è dentro questo file ZIP?
C’è sicuramente un file chiamato imsmanifest.xml, o più comunemente manifest.
Il manifest è obbligatorio e deve essere nella “root” del pacchetto, ovvero non può essere all’interno di una qualsiasi cartella o sottocartella all’interno del file ZIP.
La mancanza di questo file o la sua ubicazione sbagliata rende il pacchetto SCORM non valido, verrà quindi rifiutato in fase di upload in una piattaforma LMS.
Ubicare il file manifest all’interno di una sottocartella è un errore molto comune.
Spesso, infatti, decomprimiamo il corso in una cartella, effettuiamo qualche modifica, e poi “zippiamo” la stessa dall’esterno, riposizionando il file manifest in una sottocartella…
Il file MANIFEST
Il file imsmanifest.xml è un file XML, ovvero un file di markup che segue una sintassi a TAG e ATTRIBUTI.
Attenzione, esso non è il classico HTML delle pagine WEB, anche se a prima vista possiamo riscontrare delle somiglianze tra i due.
L’XML è, infatti, un linguaggio più generico ma che impone comunque di essere BEN FORMATO e VALIDATO secondo una definizione precisa.
In questa sede, non scenderemo in dettagli troppo tecnici, poiché editare un file di Manifest manualmente richiede delle competenze avanzate.
Sappiamo però che il Manifest si suddivide solitamente in 4 parti:
- Dichiarazione di versione ed identificativo
In questa parte vengono espressi i vari namespace che validano il file XML, la versione dello SCORM SCHEMA di riferimento ed anche un identificativo del corso che dovrebbe risultare univoco, sebbene non ne possiamo avere la certezza - Metadati
La parte in cui vengono descritti i contenuti del corso contenuto nel pacchetto scorm. Questa può essere utilizzata dalla piattaforma per categorizzare ed indicizzare il corso in un sistema di ricerca o di categorizzazione dei contenuti. - Struttura del corso
Un elenco degli SCO (Moduli) e degli ASSETS (Corredi) contenuti nel pacchetto SCORM, con eventuali requisiti di propedeuticità e politiche di obiettivi.
Nel caso di un pacchetto MultiSCO, questa parte sarà interpretata dalla piattaforma per generare un menu di navigazione tra i vari SCO che compongono il pacchetto. - Elenco dei file
Per ogni risorsa associata alla struttura del corso, che sia uno SCO o un ASSET, viene redatto un elenco dei file ad esso associati. Talvolta, nelle piattaforme più moderne, questo elenco può essere non troppo preciso ed in qualche modo viene ricreato dalla piattaforma LMS in fase di upload.
In un pacchetto SCORM corretto, però, ogni file interno allo zip (tranne lo stesso file imsmanifest.xml) deve avere almeno un riferimento in questo elenco.
Protocollo di Comunicazione SCORM
Forse la caratteristica più importante del modello SCORM è stata proprio quella di creare un protocollo di comunicazione condiviso tra Contenuto e-learning e piattaforme LMS.
Cosa significa di preciso?
Lo SCORM definisce una serie di funzioni e variabili JAVASCRIPT che le piattaforme devono assolutamente implementare, e che i contenuti e-learning possono utilizzare. Viene da sé che, qualora un contenuto non faccia uso di tali funzioni, non andrà a generare dati di tracciamento e di conseguenza una reportistica di piattaforma.
I dati di tracciamento che possono essere generati tramite l’utilizzo di queste funzioni possono variare. Dai più semplici, come lo stato di completamento di un corso (esempio: non iniziato, iniziato, completato, etc…) o il tempo trascorso in una sessione formativa, si passa a elementi anche più complessi come addirittura il tempo impiegato da un utente per scegliere una riposta dopo che è stata proposta una domanda in un quiz a risposta multipla.
Le funzioni e le variabili messe a disposizione dallo SCORM non sono molte, ma fino ad oggi sembrano ancora sufficientemente adatte alla maggior parte dei corsi e-learning che stentano ad adottare altri protocolli. Questo è dovuto, forse, anche alla complessità delle informazioni “tracciabili”.
Lo SCORM nelle piattaforme LMS e LXP
Oggi possiamo contare su vari sistemi tecnologicamente più avanzati, ma una piattaforma LMS che vuole definirsi tale sicuramente anche oggi non può fare a meno di supportare il protocollo SCORM. Ogni piattaforma che supporta correttamente lo SCORM (e viene certificata come tale da ADL) si definisce SCORM ADOPTER.
Come può la mia piattaforma LMS supportare lo SCORM?
Come accennato precedentemente, il supporto SCORM lato piattaforma – quindi lato server – deve essere implementato con una serie di funzioni e variabili javascript che siano a disposizione del contenuto in erogazione. Per questo motivo la piattaforma sarà in qualche modo obbligata ad incapsulare il contenuto SCORM all’interno di un iframe o simili, in cui tali funzioni sono già definite. Il loro funzionamento non è complesso e lo SCORM non si occupa di determinare cosa debba avvenire lato server, come ad esempio dichiarare se queste variabili vadano immagazzinate in un database o meno.
Il comportamento di queste funzioni deve però rispecchiare le direttive del modello.
Prendiamo come esempio la variabile cmi.core.lesson_status per il protocollo SCORM 1.2. Essa rappresenta lo stato di completamento dello SCO e può assumere, secondo il modello, i seguenti valori:
- “passed”
- “completed”
- “failed”
- “incomplete”
- “browsed”
- “not attempted”
Qualora un contenuto cercasse di valorizzare tale variabile con una chiamata javascript del tipo: LMSSetValue(“cmi.core.lesson_status”, “finished”); significherebbe che il contenuto sta cercando di valorizzare tramite una funzione LECITA una variabile LECITA con un valore ILLECITO: “finished”.
Da definizione SCORM questa variabile non può assumere quel valore, anche se a noi può sembrare sensato. La piattaforma dovrà quindi restituire un errore consono a tale chiamata.
Esistono strumenti che permettono di validare il corretto funzionamento del contenuto SCORM ed un elenco di piattaforme certificate come SCORM COMPLIANT.
Come dicevano, una piattaforma LMS SCORM compliant viene definita SCORM ADOPTER, un elenco delle piattaforme certificate si può trovare qui: https://adlnet.gov/assets/uploads/SCORMAdoptersLocked2016.xlsx
Evoluzioni dello SCORM
Per avere un’idea delle evoluzioni dello SCORM nei protocolli più recenti e quali novità essi hanno apportato, potete trovare qualche informazione utile negli articoli del nostro blog suggeriti tra i correlati.