www.e-fad.it

da AICC a SCORM

come passare dal refrence model SCORM alle specifiche AICC e viceversa.
Qui trovate il doc e la presentazione, mentre qui trovate, nel sito, le pagine web.



 

da SCORM a AICC
andata e ritorno
~
come convertire in modo (quasi) indolore i materiali didattici per la formazione a distanza
~








introduzione
SCORM e AICC
Per la lettura di queste note si devono avere presenti le basi del funzionamento di SCORM e AICC come specifiche per la definizione dei materiali didattici e del loro rapporto con le piattaforme.
AICC è storicamente nata prima del reference model SCORM; dedicata allo sviluppo di specifiche per i materiali didattici all'interno dell'industria aeronautica, ha cominciato i lavori nell'era pre-internet, per cui alcune parti riguardano il funzionamento di sistemi stand-alone senza connessioni in rete. Le specifiche, scaricabili dal sito aicc.org, sono erogate direttamente dall'associazione.
SCORM è una raccolta di specifiche, o meglio reference model, che non sono erogate dai promotori del progetto, ma una raccolta di specifiche create da altri attori, tra cui anche AICC; ecco perchè in qualche caso i concetti si intersecano. SCORM è un progetto erogato da ADLNET, a sua volta erogazione del dipartimento della difesa USA e dell'ufficio per le tecnologie della casa bianca.
Nel definire il reference model vengono analizzate e promosse le specifiche di altri attori pubblici o privati, quali sono AICC, IMS, IEEE.
Il metodo di lavoro
Sia i materiali SCORM che quelli AICC si riferiscono alla formazione erogata attraverso piattaforme tecnologiche; le modalità di costruzione dei materiali didattici riguardano più 'momenti' vissuti all'interno delle piattaforme di erogazione: è quindi necessario sezionare in parti la vita del materiale nella piattaforma per isolare le singole situazioni nelle quali vengono applicate le specifiche. In questo modo, comparando la modalità di funzionamento di AICC e SCORM, si possono ricavare i dati necessari per traghettare il materiale didattico da una modalità all'altra.
lifecicle del materiale didattico nella piattaforma
schema generale
Esistono due casi totalmente distinti di interazione del materiale didattico con la piattaforma: uno asincrono e l'altro sincrono rispetto alla fruizione.
Il primo, asincrono, riguarda l'importazione ed esportazione dei corsi. Un materiale didattico deve essere costruito in modo che, fornito sotto forma di pachetto software isolato, possa essere importato all'interno della piattaforma e possedere i requisiti di funzionamento che l'autore ha impostato. Lo stesso vale per l'esportazione: un corso immesso in una piattaforma può essere esportato conservando tutte le caratteristiche che ha avuto al momento dell'authoring.
Il secondo, sincrono, riguarda l'interazione del materiale didattico con l'utente al momento della fruizione. Dal momento in cui qualcuno esegue il login sulla piattaforma, viene riconosciuto, e richiede il lancio di un materiale didattico, avvengono una serie di interazioni tra materiale e piattaforma che vengono chiamate di runtime.


La 'traduzione' di un materiale da una tipologia all'altra deve conservare le funzionalità in entrambi i momenti; sarebbe inutile importare un corso che non può funzionare, né avere un corso che teoricamente può 'parlare' con la piattaforma ma che su essa non può essere installato.
La struttura dei corsi AICC e SCORM
Un corso AICC si presenta come un insieme di materiali didattici descritti come struttura e funzionamento all'interno di una struttura di 7 files, 4 obbligatori (legati alla struttura) e tre facoltativi (legati al sequencing):


L'insieme dei 7 files si chiama Course Interchange File set. Per i significati dei singoli files, si riporta ad opportuni approfondimenti.

Un corso SCORM si presenta come unico file con estensione PIF (package interchange format) che è un file zippato che ha obbligatoriamente a livello di radice un file di nome imsmanifest.xml che contiene tutte le descrizioni del corso e, solitamente in opportune directory, tutti i files che costituiscono le lezioni del corso.
All'interno del file imsmanifest.xml sono presenti diverse sezioni codificate in xml, relativi alla descrizione (metadata), alla struttura (organization – sub-manifest), ai file utilizzati (resources)

L'importazione / esportazione dei corsi
Due aspetti devono essere considerati: lo spostamento 'fisico' dei materiali e la loro strutturazione e descrizione
spostamento delle risorse
Innanzitutto va ricordato che mentre SCORM si riferisce solo a materiali digitali, AICC prevede di poter utilizzare anche risorse non digitali; nel prosieguo si tratterà solo di materiali digitali.
Inoltre AICC ha un forte accento sull'ambiente operativo Microsoft Windows; alcune funzioni sono direttamente riferite a chiamate interne Windows (es.: createProcess()), o fanno riferimento a valori che vanno direttamente scritti nel registro di Windows.
Va ancora considerato che AICC prevede anche il funzionamento standalone, con materiali didattici direttamente eseguiti sul pc utente, che non possono essere utilizzati in un'archiettura di rete HTTP; in quel caso, per portarli a SCORM, vanno previste riscritture totali dei materiali didattici.
Esistono 'luoghi' nei quali sono descritte tutte le risorse utili, cioè tutti i file necessari per il funzionamento del corso; individuati questi 'luoghi' si potrà estrarre l'elenco e la posizione dei file necessari in modo da poterli singolarmente individuare e sistemare nella piattaforma di erogazione nella posizione più opportuna.
• per AICC sono descritti all'interno del Course Interchange File set nel file con estensione DES, che tiene traccia di ogni singolo elemento del corso, mantenendo la corrispondenza tra identificativi generati dalla piattaforma e identificativi dei materiali, sotto forma di tabella CSV
• per SCORM sono all'interno dell'imsmanifest.xml nella sezione resources, sotto forma di XML.
Lo spostamento dei file quindi si risolve nell'andare a cercare nel giusto punto l'elenco dei file necessari e nel portarli a destinazione; nel caso di 'traduzione' da uno standard all'altro si tratta semplicemente di scrivere in modo diverso l'elenco dei files.
interpretazione della struttura e del sequencing
Il discorso è più complesso per quanto riguarda la struttura dei materiali; va 'capita' la strutturazione data ai materiali nel primo formato per poterla tradurre nel formato di destinazione.
Ciò ha importanza fondamentale, perchè, oltre a inibire o meno il funzionamento, ha diretta influenza sulle procedure di runtime, che a loro volta si basano sulla struttura del corso.
SCORM, nel modello più semplificato, precede una struttura a tre livelli: il corso è costituito da learning objects chiamati SCO che a loro volta possono essere costituiti da Assets; gli assets sono oggetti semplici che non hanno capacità di comunicazione con la piattaforma, gli SCO sono i più piccoli oggetti in grado di comunicare con la piattaforma ed essere 'autonomi' nel funzionamento, mentre il corso è una aggregazione di SCO. Esiste una certa differenza nella definizione di 'corso' tra SCORM1.2 e SCORM1.3 (o 2004). Le specifiche più recenti indicano un corso come aggregazione di contenuti (content aggregation) costituito da una organizzazione (content organization) a sua volta costituita da learning activities che a loro volta possono contenerne altre; a livello di foglia dell'albero delle attività (activity tree) ogni learning activity corrisponde ad uno SCO. A tali learning activities sono direttamente colllegati i meccanismi di sequencing and navigation.
In SCORM 1.2 la struttura è direttamente espressa come content aggregation e definito come mappa delle risorse disponibili; attraverso i prerequisiti di fruizioni possono definirsi modalità di sequencing.
Va qui fatta una nota: in realtà le modalità di sequencing non sono quasi mai state eseguite in questo modo, perchè la norma non è chiara e perchè l'evoluzione (1.3) ha seguito altre strade. Di conseguenza si è assistito ad un uso vendor-based dei requisiti per ottenere meccanismi di sequencing o, più semplicemente, si sono utilizzati modi di fruizioni lineari tra le unità didattiche messe a disposizione. E' diventato uso comune non prevedere meccanismi di sequencing in SCORM 1.2
In SCORM 1.3 il sequencing rappresenta la 'novità' della versione e prevede meccanismi derivati da IMS sequencing che sono di una certa complessità. Le specifiche prevedono 70 pagine di pseudo-code per definire il modo con il quale le piattaforme dovrebbero interpretare i meccanismi di sequencing forniti dai materiali didattici. E' un'operazione complessa da seguire, ad oggi poche piattaforme supportano questa modalità di funzionamento.
In AICC la struttura è definita per unità didattiche (AU), blocchi di unità e obbiettivi; i meccanismi di sequencing sono più consolidati, basati sullo stato di prerequisiti e requisiti di completamento delle unità didattiche, dei blocchi e degli obbiettivi.
Migrare la struttura
Per quanto riguarda la struttura del corso i meccanismi di traduzione tra i due standard non rappresentano particolari difficoltà. Il 'mattone' di base in entrambi i casi è un oggetto autonomo (AICC->AU, SCORM->SCO), il raggruppamento in blocchi è facoltativo in entrambi i casi, la sovra-struttura corso esiste allo stesso livello per entrambi; a parte le differenze nel binding, cioè nel tradurre i concetti in file (di testo, CSV per AICC - XML per SCORM) i concetti sono similari.
Ciò che è ben sviluppato, fin dalle prime versioni , in SCORM sono i metadati, che non trovano analogo corrispondente in AICC. I metadati cono la ricchezza informativa che circonda ogni singolo corso o SCO; pur essendo prevista in AICC una sezione relativa alle informazioni per ogni oggetto, non esiste una modalità così ricca come IEEE LOM (learning object metadata, la specifica su come scrivere i metadati). Inoltre AICC non prevede specificatamente il livello assets, mentre in SCORM il livello esiste e può utilizzare metadati LOM.
Questo significa che nel passare da SCORM a AICC si perde la ricchezza del dato, mentre nella direzione opposta diventa obbligatorio marcare i nuovi oggetti con i metadati; quantunque IEEE LOM di per sè non preveda l'obbligatorietà di nessun dato e consenta l'utilizzo di risorse digitali, quando ADLnet ne ha scelto la specifica per l'introduzione in SCORM ne ha ristretto l'ambito di applicazione ai soli oggetti digitali e ha definito per ogni livello, corso - SCO - asset, quali metadati devono essere obbligatoriamente presenti.
Migrare il sequencing
Non sempre, all'interno dei corsi presenti in commercio, sono previsti meccanismi di sequencing. I casi che si verficano sono di tre tipi:
• non c'è alcun meccanismo di sequencing
• sono presenti semplici meccanismi di sequencing che prevedono due modalità di fruizione: la libera fruizione di tutte le unità didattiche o la fruizione vincolata ad un accesso sequenziale alle unità didattiche; il passaggio dalla unità x alla unità (x+1) è definito dall'aver frequentato/visto quella precedente o dall'aver superato il test precedente
• ci sono meccanismi più avanzati di sequencing, che prevedono modalità complesse di navigazione tra le unità didattiche dipendenti dall'interazione dell'utente con la piattaforma
Nel primo caso, chiaramente, siamo nella soluzione più semplice per quanto riguarda la migrazione; le unità didattiche vengono proposte a libera scelta e disposte in modo sequenziale. E' il caso di default per SCORM 1.2.
Il secondo e terzo caso sono più complessi, perchè interessano anche le chiamate di runtime; oltre a ricostruire l'esatta struttura e l'esatto sequencing, si deve far sì che le chiamate di runtime interagiscano con la struttura nel modo definito nel sequencing.
In particolare nel secondo caso, la migrazione tra SCORM e AICC diventa abbastanza semplice se si tratta di SCORM 1.2; altrementi si cade nel terzo caso. Si tratta, a livello di AICC, di leggere come i file opzionali descrivono il sequencing che, in questo caso, è semplice; in SCORM si andrà a posizionare gli SCO in modo sequenziale/lineare e a livello di prerequisiti di fruizione li si lascerà vuoti (fruizione a libera scelta) o ogni SCO avrà come prerequisito l'aver frequentato quello precedente o aver ricevuto dal runtime un certo voto dal precedente (l'implementazione del dato è molto vendor-oriented, in quando ADLnet non fornisce dettagli su questo tipo di sequencing perchè li specifica in 1.3)
Nel terzo caso prevediamo che i materiali SCORM saranno erogati da un LMS SCORM 1.3 per il sequencing, che quindi implementa tutto il pseudo code (i casi sono ad oggi pochi!). Le informazioni di sequencing per AICC si ottengono ancora dai file opzionali, mentre per SCORM 1.3 vanno scritte/lette le specifiche di sequencing, che in parte sono contenute all'interno della descrizione della struttura (content organization) ed in parte sono a livello generale nel CAM (content aggregation) come specifica a sè (IMSsequencing). La traduzione passa attraverso uno stato intermedio in cui, su carta, vengono definiti i modelli di sequenziamento letti dal corso da tradurre; in un secondo momento vengono scritti nella modalità del file di destinazione
E... navigation?
In SCORM 1.3 il book che si occupa di sequenziamento si chiama sequencing and navigation. Oltre alle specifiche di sequenziamento riporta anche quelle di navigazione: questo significa che una piattaforma LMS SCORM 1.3 fornisce al corso le modalità di navigazione, cioè i menu attraverso i quali l'utente può navigare nel corso, sfogliare le pagine, afrontare nuove unità/test, etc.

Mentre 'normalmente' il corso prevede un proprio menù di navigazione, in queto caso il corso contiene materiali didattici non singolarmente fruibili se non con l'ausilio di una piattaforma di supporto che ne fornisca i meccanismi di navigazione.
Non c'è nulla di simile in AICC.
Tuttavia, nella conversione AICC -> SCORM 1.3 e nel caso del secondo punto del paragrafo precedente, potrebbe bastare fornire quale modalità di navigazione utilizzare (sequenziale/libera) per utilizzare navigation e risolvere il problema del sequencing.
Nell'immagine viene utilizzato l'ambiente di runtime fornito come esempio da ADLnet per testare un materiale didattico;
a sinistra la navigazione è imposta come sequenziale, la piattaforma offre il pulsante ‘continua' per fornite lo SCO all'utente ;
a destra la navigazione è impostata come libera, quindi vengono fatti vedere i contenuti del corso tra i quali si può scegliere, mentre la piattaforma offre i pulsanti per sospendere o abbandonare la lezione.

il runtime

Con il termine runtime si identificano quelle azioni che vengono poste in essere al momento della fruizione del corso e che riguardano l'interazione tra materiale didattico e piattaforma in conseguenza delle azioni dell'utente.

Trattandosi di comunicazione vanno identificati un mezzo trasmissivo (come comunicare) e una intesa su cosa comunicare, anche chiamata il data model.

cosa prevede AICC
AICC prevede 3 modelli adottabili sul come comunicare e un data model.
I tre modelli sono:
1. per piattaforme stand alone, basate su file locali: protocollo basato su file (runtime file binding)
2. per piattaforme su web:
a. comunicazione via protocollo HTTP (HACP binding)
b. comunicazione attraverso API ECMAscript (API binding)

Sul cosa comunicare è previsto un data model, che prevede:
• nella prima parte, core, sono tutti obbligatori e sono relativi allo stato della particolare unità che si sta fruendo; i restanti dati sono quasi tutti facoltativi
• commenti inviati dall'utente al CMI e viceversa;
• la valutazione sul raggiungimento degli obbiettivi;
• i dati sulla fruizione della lezione da parte dello studente
• le preferenze che lo studente può settare
• le interazioni dello studente con l'LMS
• i percorsi frequentati
• dati demografici sullo studente

cosa prevede SCORM
Nella storia del modello SCORM si sono susseguite tre fasi nei confronti del runtime:
• in un primo momento, nelle prime versioni del modello, il focus era sull'organizzazione dei contenuti e sulla descrizione con i metadati
• in un secondo momento (SCORM 1.2) è stato introdotto il runtime; in particolare è stato adottato il modello proposto da AICC, integrandone il come e il cosa comunicare.
• l'ultima versione di SCORM, 1.3 o 2004, adotta un'altro modello di runtime, conservando però le modalità di comunicazione (ECMAscript) del runtime precedente; pur mantenendo il come è cambiato il cosa comunicare, cioè il data model.


AICC-> SCORM

Si deve definire verso quale versione di SCORM si vogliono convertire i materiali AICC.

Se la versione è SCORM 1.2 le operazioni di conversione possono anche essere poche o nulle, a seconda del binding di partenza.
Se si parte da corsi che utilizzano il file binding l'operazione è complessa: si devono ‘smontare' i corsi, individuare le singole chiamate che vengono fatte, trasformarle in chiamate alle API magari sviluppando un wrapper in ECMAscript per facilitarsi il compito di traduzione.
Se si parte da corsi che utilizzano l'HACP binding si può con opportuna ingegneria e qualche malizia da webmaster cercare un percorso più veloce trasformando le chiamate su HTTP in chiamate ad un wrapper che a sua volta le trasformi in chiamate API.
Se si parte da corsi che utilizzano l'API binding si è nel caso più fortunato, in quanto la modalità di funzionameno è la stessa di SCORM. Potrebbe non essere necessario alcun cambiamento, ma si deve comunque fare una verifica perchè potrebbero esserci chiamate con risposte in funzione della struttura del corso, diversamente definita da AICC e SCORM, che quindi potenzialmente potrebbero dover essere modificate.

Se la versione è SCORM 1.3 sono valide tutte le considerazioni precedenti per il come comunicare, ma devono essere riscritte tutte le chiamate perchè cambia il data model, passando da quello di AICC a quello di IEEE. Lo SCORM Run-Time Environment Data Model è basato su P1484.11.1 Draft Standard for Learning Technology - Data Model for Content Object Communication standard prodotto da IEEE LTSC Computer Managed Instruction (CMI).
La differenza non è abissale, ma le stesse chiamate indispensabili per comunicare l'inizio e la fine della fruizione sono chiamate con termini diversi, quindi vanno riscritte.
Andando nel dettaglio ci sono chiamate presenti nell'uno e non nell'altro modello, quindi non è sufficiente sviluppare un ‘traduttore' di chiamate.

Login / Newsletter

learning object
repository
second life

credits | contatti | mappa | versione per la stampa | versione ad alta accessibilità | photo gallery | ricerca | referrer | dalla rete | dove siamo | iPhone
Valid XHTML 1.0! Valid CSS! RSS Linkomm - SEO Web Agency Torino Customizer