Sommario

Sommario 2

Introduzione 3

Background 4

Ambito di intervento 5

Elementi costituenti una piattaforma FAD 5

Caratteristiche di SCORM 7

Livelli di interazione interessati da SCORM 9

Importazione dei corsi 9

Funzioni dell’LMS 9

Presentazione dei contenuti 10

Funzioni dell’LMS 10

Fruizione e colloquio con la piattaforma 11

Funzioni dell’LMS 11

Descrizione 12

Funzioni dell’lms 12

Prerequisiti tecnici 13

Implementazione dei singoli componenti 15

Introduzione

E’ spesso sentita l’esigenza di dotare di funzionalità SCORM le piattaforme di formazione a distanza. A questo scopo vengono definiti gli ambiti di intervento in cui operare e le conoscenze tecniche necessarie per migrare da un sistema di formazione a distanza senza reference model SCORM ad una piattaforma che lo implementi, a partire da una generale descrizione dell’architettura del modello.

Il reference model SCORM conosce una fase di sempre maggiore attenzione nei sistemi di formazione a distanza grazie alla definizione di un livello complessivamente accettato di omogeneizzazione delle modalità tecniche di funzionamento dei sistemi FAD e alla garanzia di riusabilità e riorganizzazione dei contenuti.

Molte delle piattaforme di formazione oggi utilizzate sono la capitalizzazione di sforzi di progetto, realizzazione e testing; lavori basati sulla volontà di creazione di un ambiente funzionale, efficace dal punto di vista didattico, adattato alle realtà organizzative, ma spesso carente dal punto di vista dell’aderenza al reference model SCORM, sempre più richiesto.

In questo documento vengono presentati i passaggi necessari per l’implementazione del reference Model SCORM in base all’esperienza maturata con la piattaforma Maestra; non viene considerato il lato amministrativo che riguarda la certificazione.

Dapprima vengono riportati gli ambiti di intervento, le funzionalità introdotte da SCORM, i requisiti professionali necessari per intervenire; quindi vengono elencate le operazioni da effettuare in base al comportamento di un LMS che importa ed eroga corsi standard.

Nel documento verrà adottato il termine LMS (learning management system) per indicare la piattaforma di formazione a distanza nel suo complesso; vengono esaminati unicamente gli aspetti che riguardano la gestione di materiali didattici SCORM mentre non verranno affrontati la creazione e immagazzinamento dei singoli materiali e la certificazione della piattaform.

Background

Le considerazioni che seguono derivano da un processo di sviluppo che è iniziato a metà degli anni 90 per utilizzare le tecnologie informatiche applicate alla didattica; in particolare sulle piattaforme di formazione a distanza e sui materiali didattici.

Le esperienze effettuate hanno consentito un successivo affinamento delle conoscenze sulle piattaforme FAD soprattutto in relazione all’utilizzo in ambienti formativi.

Le prime esperienze fanno riferimento ad una piattaforma utilizzata dapprima in ambiente protetto (docenti) e quindi provata ‘sul campo’; il periodo relativamente acerbo per questo tipo di applicazioni (’96-’98) non ha consentito una applicazione ‘di massa’ per un test completo delle potenzialità; la tecnologia utilizzata era costituita da un web server collegato con un database (Microsoft Access) tramite applicazioni CGI (piattaforma ‘Luba!’, ENGiM).

Si è quindi passati ad una maturazione, dal punto di vista tecnologico, con l’utilizzo dell’allora (1999) nascente linguaggio di scripting PHP, sempre interfacciato a database Microsoft Access (piattaforma FA2B, Cnos-Piemonte, 1999).

La piattaforma FA2B è diventata la base per lo sviluppo della piattaforma Maestra; l’adozione di un più robusto database (MySql) e l’utilizzo di strumenti Open Source per lo sviluppo hanno caratterizzato la piattaforma maestra nella versione 1 (2001)

L’emergere degli standard internazioni, ed in particolare del reference Model Scorm, sono stati alla base della successiva evoluzione, costituita da un ‘irrobustimento’ del codice e dall’adozione del modello di riferimento SCORM 1.2, consentendo allo staff di maturare e condividere le conoscenze sugli standard internazionali (Piattaforma Maestra versione 2.3, Cnos-piemonte, 2003)

La successiva e corrente evoluzione è costituita da una riscrittura e riorganizzazione del codice, dal modello di sviluppo e implementazione modulare, e dallo svincolarsi dal progetto proprietario, aprendosi alle collaborazioni nello sviluppo di codice open source; il progetto con nome ‘maes3’ è pubblicato su sourceforge.net

Figura 1: l'evoluzione della piattaforma FAD

Ambito di intervento

Un LMS, a grandi linee, è costituito da un server web che interagisce con un database per fornire agli utenti pagine personalizzate contenenti materiali didattici e sistemi collaborativi.

Compito principale è mantenere e gestire il contatto e la comunicazione tra materiali didattici e persone, siano esse utenti o organizzatori della formazione.

In questa parte verranno analizzati i principali elementi costituenti un LMS definendo per ognuno il livello di interazione con il modello SCORM.

Elementi costituenti una piattaforma FAD

Un LMS è costituito da alcuni sottoinsiemi:

• il database utenti è l’insieme di tutte le persone iscritte a vario titolo; possono essere o meno raggruppati in classi e possono avere funzioni specifiche (tutor, gestore, esperto, utente…).

• Il database dei corsi è costituito dai percorsi formativi utilizzabili, che possono o meno fare perno su specifici materiali didattici creati

• I servizi forniti sono l’insieme dei sistemi di visualizzazione, collaborazione ed interazione che, in modo sincrono o asincrono, costituiscono il momento formativo vero e proprio

Il processo che avviene nella fruizione di un corso di formazione a distanza è normalmente costituito dalle fasi:

· ingresso nel sistema di formazione, normalmente è un accesso personalizzato vincolato da login e password

· associazione dell’utente ad un corso, in modo volontario o prestabilito

· erogazione di servizi all’utente

o presentazione dei servizi a disposizione

o ingresso in un servizio, utilizzo e tracking

· uscita dal servizio

Figura 2 - I servizi di una piattaforma - SCORM vieewer

I servizi a cui si fa riferimento sono quelli classicamente utilizzati negli lms, quali forum, chat, presentazione di documenti, files, videoconferenze, etc.; in particolare un servizio può occuparsi della visualizzazione dei corsi (WBT), che tipicamente avviene tramite finestra di browser su materiale HTML o comunque veicolabile su browser web.

E’ esattamente a questo punto che va situato l’oggetto SCORM VIEWER, in grado di avviare un corso SCORM e di gestire le interazioni tra corso e utente così come sono state definite dall’autore del corso stesso. Terminata la visualizzazione del corso lo Scorm Viewer ripasserà il controllo alla piattaforma, sulla quale potranno essere utilizzati tutti i servizi precedentemente citati.

Questo è l’ambito tipico di influenza di SCORM; ciò non vieta che anche servizi diversi dalla presentazione dei corsi (forum, chat, etc) possano utilizzare il modello di riferimento di SCORM per colloquiare con la piattaforma.

Caratteristiche di SCORM

In questo paragrafo vengono riassunte alcune delle caratteristiche del modello di riferimento, prendendo come base l’organizzazione dei contenuti.

Nei primi mesi del 2004 sono state pubblicate le specifiche di SCORM 1.3, versione che segue la 1.2; le due versioni, pur essendo una l’evoluzione dell’altra, non sono compatibili: i materiali realizzati secondo SCORM 1.2 non possono essere visualizzati con un LMS SCORM 1.3; quindi per poter visualizzare tutti i corsi un LMS dovrebbe avere due diversi fronti di applicazione, uno per i corsi 1.2 e l’altro per quelli 1.3.

Tuttavia, indicazioni riportate dagli ambienti di sviluppo del modello, indicano come buona norma il riferimento a SCORM 1.2[1]

Le differenze vanno ricercate in due aspetti diversi:

· da un lato l’introduzione del simple sequencing, il sistema di sequenziamento degli oggetti didattici

· dall’altra il cambiamento del modello di run time, che è passato dal riferimento AICC a quello IEEE

Scorm bookshelf

ADLnet fa riferimento ai singoli oggetti che costituiscono il reference model con la metafora dello scaffale in cui sono inseriti i diversi book con le specifiche.

Figura 3 - bookshelfI SCORM

Le sezioni definite:

1. l’overview dà una visione generale dello standard, senza scendere in approfondimenti tecnici;

2. il Content Aggregation Model (CAM) specifica la modalità con la quale aggregare i corsi in strutture veicolabili sui diversi LMS; in particolare

2.1. Metadata specifica come devono essere scritti i descrittori che a diversi livelli possono (o devono) essere utilizzati per ‘marcare’ le risorse utilizzate, sia dal punto di vista tecnico che da quello didattico e descrittivo

2.2. Content Structure definisce i livelli di aggregazione degli oggetti costituenti i corsi, definiti in

2.2.1. assets, oggetti semplici che non colloquiano con la piattaforma

2.2.2. sharable content objects (SCOs) aggregazione di assets in grado di stabilire un colloquio con l’LMS e di agire autonomamente

2.2.3. content aggregation che rappresenta il livello di corso, aggregazione di SCOs descriventi un percorso formativo

3. Il Run Time Environment definisce come e che cosa il materiale didattico e l’LMS possono scambiare; mentre nella versione precedente il modello seguito era quello di AICC in scorm 1.3 il modello è quello di IEEE.

3.1. API specifica la modalità con la quale vengono eseguite le chiamate durante il run time; l’interazione avviene attraverso javascript (ecmascript)

3.2. Data Model indica quali parametri possono essere passati da uno SCO all’LMS

4. Sequencing & Navigation serve ad indicare sia il sequenziamento, ovvero la modalità temporale con la quale gli SCOs vengono presentati all’utente che la modalità di navigazione tra gli SCOs che viene permessa.

Mentre il punto 1 è una introduzione generale, i seguenti tre punti rappresentano le ‘regole’ da seguire quando si crea un oggetto SCORM.

Viene fornita una matrice di conformità a seconda del tipo di oggetto SCORM che si deve realizzare, cioè a seconda che si voglia realizzare un LMS, un content packaging (una aggregazione di oggetti costituenti un corso SCORM), un singolo SCO o una descrizione degli oggetti con metadati:

	CAM 1.3	RTE 1.3	S&N 1.3
LMS	x	x	x
CP	x	x
SCO		x
MD	x

Dalla matrice si vede come la realizzazione di un LMS sia quella che richiede la conformità su tutte tre le specifiche.

Livelli di interazione interessati da SCORM

Da quanto finora riferito, il viewer SCORM potrebbe sembrare un oggetto totalmente ‘separato’ dall’LMS, senza interazioni forti.

Nei confronti della implementazione del reference model la modalità con la quale sono realizzati molti LMS rende difficile proprio questa separazione, e l’implementazione del reference model può comportare una ridefinizione della piattaforma con conseguenti cambiamenti nel codice di funzionamento.

L’interazione tra piattaforma e reference model avviene a livello di importazione dei corsi, di presentazione dei contenuti, di fruizione e colloquio con la piattaforma, di descrizione dei corsi e dei loro componenti.

Importazione dei corsi

La piattaforma deve essere in grado di importare corsi realizzati secondo il modello; a partire da un singolo file compresso devono essere ricavati tutti i componenti e le modalità di interazione previste dal progettista del corso.

Non è necessario che la piattaforma sia in grado di disaggregare i contenuti in modo che siano raggruppabili in modo diverso da quanto previsto dall’autore, né sono previste capacità di authoring.

Figura 4: l'importazione di corsi esistenti

Funzioni dell’LMS

· Decompattazione del file compresso

· Lettura del file IMSmanifest.xml

· Eventuale controllo di congruenza

· Sistemazione dei files in zona di pubblicazione sotto server web

· Lettura dei metadati per la presentazione del corso ai fruitori / gestori

Presentazione dei contenuti

Un primo livello di interazione diretta con l’utente lo si ha a livello di indicazione dei contenuti del corso.

In una piattaforma non SCORM la modalità con la quale descrivere i collegamenti ai contenuti (indice, link ai capitoli/paragrafi) è normalmente proprietario e diverso da caso a caso; nella migliore delle ipotesi consiste in un elenco di link html che visualizzano le risorse costituenti il corso.

In una piattaforma SCORM l’elenco dei contenuti deve essere ricavato dal corso stesso così come l’autore l’ha implementato, con il rispetto di tutti i vincoli a cui può essere sottoposto.

A differenza delle piattaforme non scorm è quindi necessario creare un oggetto che estragga i contenuti dal corso e li presenti all’utente nella giusta sequenza; con scorm 1.3 è stato notevolmente ampliato il meccanismo di presentazione dei contenuti in base a condizioni specifiche definite/ottenute dall’utente e dall’autore del materiale (Simple Sequencing)

Figura 5: la presentazione dei contenuti

Funzioni dell’LMS

· Estrazione dei contenuti dai metadati

· Presentazione all’utente

· Eventuale organizzazione dei contenuti secondo simple sequencing (rif.:pseudo-code ADLnet)

· Implementazione dei meccanismi di navigazione, se richiesti.

· Implementazione del meccanismo di lancio delle risorse

Fruizione e colloquio con la piattaforma

Un secondo livello di interazione è presente al momento del run-time; durante la fruizione del corso SCORM il materiale didattico deve poter agganciare alcune funzioni che l’LMS deve presentare; in assenza delle risposte alle chiamate del materiale ne può essere inibito il funzionamento.

Queste chiamate avvengono dal primo momento di apertura del materiale didattico, cioè appena azionato uno dei link ai contenuti precedentemente definiti.

Tali interazioni inoltre devono prevedere la possibilità di fissare i dati in modo permanente su un database, in modo da poter essere ripresentati agli utenti nelle successive sessioni.

Queste interazioni sono presenti sia nella direzione dall’LMS verso il materiale didattico (es.: l’LMS passa il nome dell’utente al materiale didattico) sia in senso inverso (es.: il materiale didattico comunica all’LMS il risultato di un test)

Figura 6: l'ambiente di run time

Funzioni dell’LMS

· Implementazione delle API e relativo DATA MODEL

· Compilazione delle variabili nel DATA MODEL da presentare al fruitore (API_1484_11)

o Estrazione dei dati da imsmanifest.xml

o Eventuale recupero di dati da precedenti fruizioni

· Risposte alle chiamate del materiale secondo standard API

· Implementazione del meccanismo di ritorno per fissare i dati di fruizione sul DB

Descrizione

Un terzo livello di interazione riguarda la lettura dei metadata, ovvero di tutti i descrittori del corso che sono contenuti nel materiale didattico e che, a vario livello, possono essere presentati come informazioni agli utenti della piattaforma. Questi dati hanno maggiore importanza nel caso di LCMS, mentre per un LMS sono dati di semplice lettura.

Dal punto di vista tecnico si deve considerare che il materiale didattico va visto in una finestra diversa rispetto a quella dell’LMS; ovvero il corso deve avere una finestra-parente con la quale comunicare. Questo è risolvibile in due modi: o aprendo una finestra in pop-up oppure costruendo una interfaccia a frames.[2]

Funzioni dell’lms

Lettura dell’xml, per presentazione, repository, editor di corsi, dati sul copyright, browser, sistema operativo etc.

Prerequisiti tecnici

Indicando in forma grafica diversa quanto appena espresso, si può rappresentare il funzionamento di un LMS abbinato a contenuti SCORM come un cerchio diviso in tre parti: il modello di aggregazione dei contenuti, l’interazione di funzionamento, la modalità di sequenziamento e navigazione tra i contenuti.

Rappresentando su corone circolari gli oggetti come prima citati, vengono presentati come settori colorati quelli in cui devono essere rispettate le specifiche; come prima citato, LMS copre tutti tre i settori.

Figura 7 - rapporto tra oggetti costituenti l'LMS e livelli di conformità

A partire da questo schema, può essere definito un elenco di presupposti/conoscenze teoriche necessari per implementare quanto richiesto.

La rappresentazione grafica proposta (figura seguente) vede alla base i settori circolari prima espressi; a partire dall’alto sono indicate le conoscenze necessarie per giungere all’implementazione.

Nella prima parte (background) sono indicate conoscenze generali sulla formazione a distanza e sull’evoluzione che ha subito negli ultimi decenni, la conoscenza chiara dell’iter normativo che porta alle norme / modelli in materia con riferimento agli enti coinvolti, la divisione di un sistema FAD nei singoli componenti, i necessari presupposti tecnici per procedere all’implementazione.

Nella seconda parte è rappresentato lo studio di dettaglio delle norme e degli esempi applicativi;

A questo punto è possibile l’applicazione vera e propria delle norme per l’implementazione SCORM sull’LMS.

Figura 8 - schema dei prerequisiti tecnici

Implementazione dei singoli componenti

CAM: l’organizzazione dei contenuti

Il Content Aggregation è l’oggetto che descrive il corso nella sua interezza.

L’LMS deve essere in grado di aprire il file XML che lo descrive e da esso estrarre tutti i dati relativi agli oggetti che costruiscono il corso, ai loro descrittori, alle modalità di funzionamento comprensive di sequenziamento e navigazione.

Figura 9 - Content Aggregation

Una volta identificate le risorse che fanno capo al corso, è compito dell’LMS il lancio del primo oggetto che deve essere visualizzato dall’utente o presentare un menù che proponga tutti gli oggetti lanciabili.

Per chiarire il concetto si riporta un esempio pratico.

Dato un file descrittore di corso (volutamente breve, a scopo didattico) quale:

<?xml version="1.0" standalone="no" ?>

- <manifest identifier="prova_seq" version="1.3" xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_v1p3" xmlns:imsss="http://www.imsglobal.org/xsd/imsss" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd http://www.adlnet.org/xsd/adlcp_v1p3 adlcp_v1p3.xsd http://www.imsglobal.org/xsd/imsss imsss_v1p0.xsd">

- <metadata>

<schema>ADL SCORM</schema>

</metadata>

- <organizations default="TOC1">

- <organization identifier="TOC1">

<title>corso con sequencing e flow=true</title>

- <item identifier="INTRODUZIONE" identifierref="myIntro">

<title>Introduction</title>

</item>

- <item identifier="prima_lex" identifierref="lexx1">

<title>prima lezione</title>

</item>

- <item identifier="secona_lex" identifierref="lexx2">

<title>seconda lezione, con RT</title>

</item>

- <item identifier="esempio" identifierref="xml_example">

<title>codice del manifest</title>

</item>

- <imsss:sequencing>

<imsss:controlMode flow="true" choiceExit="false" choice="false" />

</imsss:sequencing>

</organization>

</organizations>

- <resources>

- <resource href="lezione2.htm" adlcp:scormType="sco" identifier="lexx2" type="webcontent">

</resource>

- <resource href="lezione1.htm" adlcp:scormType="asset" identifier="lexx1" type="webcontent">

</resource>

- <resource identifier="myIntro" adlcp:scormType="asset" type="webcontent" href="intro.htm">

</resource>

- <resource identifier="xml_example" adlcp:scormType="asset" type="webcontent" href="imsmanifest.xml">

</resource>

</resources>

</manifest>

Sono evidenziate con la sottolineatura le parti che individuatno il file da lanciare per la seconda lezione; dapprima, nella sezione organization viene definito che deve essere disponibile una risorsa dal nome ‘lexx2’; quindi, nella sezione resources, viene definito che tale risorsa è uno SCO e corrisponde al file ‘lezione2.htm’

MD: l’utilizzo dei metadati

I Metadati sono descrittori, sono presenti all’interno degli oggetti SCORM a diversi livelli.

I metadati presenti a livello di Content Aggregation descrivono il corso nella sua interezza; la base è il modello IEEE LOM 1.0 che descrive, attraverso 9 sezioni principali, i dati del corso.

In figura un esploso del modello IEEE LOM

Figura 10 - Esplosione del modello IEEE LOM

Tuttavia i metadati sono presenti in diverse sezioni del file xml che descrive il corso, e non solo nella sezione metadata; nell’immagine seguente sono rappresentati diversi contesti nei quali sono inseriti.

Figura 11 - metadati all'interno di imsmanifest.xml

L’LMS deve essere in grado di estrarre i metadati per proporli all’utente quando ritenuto necessario.

RT: il momento del run-time

Dal momento in cui viene individuata la risorsa che deve essere lanciata sul browser deve iniziare un dialogo tra materiale didattico e piattaforma. Questo dialogo avviene attraverso javascript.

Da un lato l’LMS deve esporre le chiamate (API), dall’altro il materiale didattico deve agganciare le API per poter effettuare il colloquio.

L’oggetto che si occupa di esporre le API può essere un insieme di funzioni javascript presenti nella pagina o un oggetto JAVA che presenta le stesse funzioni interrogabili via javascript.

Figura 12 - modello delle interazioni di run time

Quindi attraverso un mezzo di comunicazione (javascript) vengono esposte delle chiamate (nella figura: nome utente, risultato test, etc.) le cui interrogazioni e risposte avvengono secondo un data model.

Fino a SCORM 1.2 le API sono state definite in base al modello di AICC, ma nello stesso tempo IEEE stava valutando la proposta AICC per farne un modello proprio

Da SCORM 1.3 (2004) il modello utilizzato è IEEE 1484.11.2 per le API e 1484.11.1 per il data model, cambiando la modalità di funzionamento dell’ambiente di runtime;ci sono cambiamenti che si riflettono in differenze, anche sostanziali, di funzionamento tra SCORM 1.2 e SCORM 1.3

Compito dell’LMS è quello di costruire l’ambiente nel quale l’oggetto didattico SCORM trovi le condizioni per agire come previsto dal suo autore; tecnicamente si risolve nell’esporre le API e consentirne il funzionamento secondo il data model.

Dal punto di vista delle API, si può far riferimento allo schema in figura seguente, che evidenzia il rapporto tra SCO (a destra) e LMS (a sinistra) passando attraverso le API disponibili:

Figura 13 – API

Lo SCO passa attraverso tre stati:

non inizializzato: questa fase termina quando viene chiamato ‘Initialize()’

inizializzato: da questo momento sono disponibili ‘GetValue()’ per ottenere valori dalla piattaforma, ‘SetValue()’ per scriverne, ‘Commit()’ per fissare in modo statico lo stato dei dati

terminato, una volta chiamato ‘Terminate()’

Le tre restanti chiamate devono sempre essere lasciate a disposizione dello SCO.

Per quanto riguarda il data model, esso riporta tutti i dati che possono essere letti/scritti dallo SCO; a titolo di esempio se ne riporta uno ad esempio, cmi.learner_name, che è a disposizione dello SCO che lo può richiedere all’LMS.

SN: sequencing and navigation

Rappresenta la modalità di navigazione tra LO, permettendo di inserire vincoli relativi al raggiungimento degli obbiettivi prefissati per consentire la prosecuzione della fruizione dei LO.

Inserisce una notevole complessità nello sviluppo della piattaforma, i testi di riferimento di ADLnet mettono a disposizione uno pseudo-code che spiega nel dettaglio le procedure da seguire per implementare correttamente questa parte.

Allegato: schema generale