Skip to topic | Skip to bottom
Home

Tesi
Tesi.AICCr1.1 - 25 Sep 2004 - 16:16 - RobertoCorradettitopic end

Start of topic | Skip to actions

2.3.3.1 AICC

“L’AICC produce tre tipi di documenti, le “AICC Guidelines and Reccommendations” (AGR), gli “AICC White Paper e Technical Reports” e gli “AICC Working Papers”. Il primo tipo di documenti rappresenta la voce ufficiale dell’AICC riguardo un determinato argomento. Questi documenti vengono poi votati dai membri dell’AICC e approvati o meno. Una volta approvati diventano “Technical Reports”. Questa categoria di documenti può essere considerata la parola ufficiale dell’AICC. Il terzo tipo di documenti non ha un’approvazione ufficiale da parte dei membri dell’associazione. Fanno parte dei Working Papers i documenti dei sottocomitati nel corso di un lavoro che porterà a un AGR. Questi documenti possono variare radicalmente di settimana in settimana.” Per quel che riguarda la parte relativa all’interoperabilità dei corsi on-line possiamo far riferimento in un primo momento all’ AGR006 “Computer Managed Instruction” . “Interoperabilità significa la capacità di un dato sistema CMI di gestire lezioni CBT da differenti origini. Significa anche la possibilità di un corso CBT di scambiare informazioni con differenti sistemi CMI” Questo è l’obiettivo di tale raccomandazione,le specifiche funzionali e i requisiti tecnici sono illustrati nel documento CMI001 che riguarda appunto questa raccomandazione. Farò una panoramica di questo documento soffermandomi sugli aspetti principali e non entrando troppo nel dettaglio. Gestione di un CBT da parte di un CMI Ci sono 2 punti fondamentali dell’approccio dell’AICC volto a garantire l’interoperabilità di un sistema CMI con diversi CBT:

  1. Inizializzazione lezioni: un CMI deve avere un approccio standard all’inizializzazione di una lezione
  2. Comunicazione: un CMI deve avere un approccio standard nel distribuire informazioni ad una lezione CBT e nel reperire informazioni da un CBT. AICC definisce due file a questo scopo e la figura 4 può aiutarci a capire come vengono gestite le informazioni attraverso questi due file.

Data File:CMI to CBT Informazioni sullo start-up di una lezione. Tutte quelle informazioni dello studente che possono essere utili alla lezione stessa.
Data File: CBT to CMI Informazioni richieste dal sistema CMI per registrare i risultati di uno studente e permettergli di avanzare nelle lezioni.

4.JPG

Figura4 flusso dei dati tra CMI e CBT e viceversa

Le varie fasi che garantiscono l’interoperabilità sono le seguenti:

  • Il CMI crea un file contenente i file necessari allo start-up della lezione. Questo file viene creato prima del lancio della lezione.

  • Una volta cominciata la lezione il CBT legge il file creato dal CMI poi lo cancella.

  • Il CBT deve creare a sua volta un file contenente i dati che poi verranno ripassati al CMI. Il CMI grazie a questi dati aggiornerà il profilo dei risultati dello studente e sarà in grado di andare avanti con il percorso educativo.

  • Il CMI passa il file “Lesson to CMI” come parte del nucleo del file “CMI to Lesson”

  • Quando lo studente abbandona la lezione il CBT aggiorna e completa il file delle informazioni per il CMI

  • Il CMI legge il “Lesson to CMI” file, aggiorna il profilo dello studente e traccia il profilo dello studente calcolando i suoi prossimi percorsi educativi

Concludendo, la comunicazione tra CMI e CBT avviene in due sensi e tramite due file. Il CMI manda informazioni alla lezione quando questa inizia. La lezione manda informazioni al CMI quando la lezione è finita. Il CMI to CBT File è costituito da argomenti che una lezione ottiene da un CMI per far si che questo faccia le funzioni per cui è stato progettato. Il File è suddiviso in elementi del nucleo e elementi opzionali. Gli elementi del nucleo devono essere sempre forniti dal sistema CMI per rispondere agli standard AICC. Gli elementi opzionali sono gruppi di informazioni o keyword che possono servire al funzionamento ottimale della lezione. Un corso può essere semplice come poche lezioni da seguire in maniera sequenziale o può essere complesso come centinaia di lezioni che sono prerequisiti di altrettante o da seguire in maniera casuale. Comunque sia strutturato il corso esso prevede questa forma a due componenti: elementi didattici e struttura. Come è facile prevedere gli elementi didattici sono composti da: lezioni, testi ed altre unità assegnabili nel corso. Nel definire la struttura lo sviluppatore spesso raggruppa le lezioni da assegnare. Negli altri casi il progettista definisce una più complicata gerarchia di lezioni. La struttura determina l’ordine nel quale ogni studente deve seguire i contenti del corso. La parte del CMI che svolge questo compito si chiama “router”. Ci sono due circostanze per cui le AGR su come rendere interoperabili corsi su due ambienti diversi sono usate. La prima prevede che il corso è completo e deve essere trasferito da un fornitore ad un altro. La seconda prevede che il corso è stato creato con un altro tool diverso da un sistema CMI. Avendo un meccanismo standardizzato per la descrizione dei contenuti del corso e la loro struttura, un sistema CMI può ospitare nuovi corsi senza particolari problemi. AICC ha identificato sette file (alcuni dei quali opzionali) che possono essere usati per descrivere i contenuti di un corso e la loro struttura. In aggiunta, le raccomandazioni AICC definiscono cinque livelli di complessità per descrivere la struttura di un corso.

Aumentando i livelli di difficoltà si ottiene:

  • Minore sforzo per rivedere e modificare il sistema CMI dopo l’importazione dei nuovi dati.

  • Una maggiore descrizione delle intenzioni dello sviluppatore di come usare il materiale del corso

Il maggior livello di complessità di descrizione delle informazioni inoltre determina il numero di file richiesti e la quantità delle informazioni richieste in ogni file. La seguente tabella descrive il contenuto e le finalità di ogni file.

Course Description File Contiene informazioni sul corso: la sua descrizione,l’aspetto generale,il numero e i tipi di elementi del corso
Assignable Unit Table Informazioni circa le Assignable Unit (AU) nel corso. Ogni AU ha il proprio record nella tabella. Le informazioni comprendono il nome della AU, il suo ID, e il punteggio di superamento per ogni AU.
Descriptor Table Una lista completa di ogni elemento del corso. Queste informazioni comprendono le AU, i blocchi, gli obiettivi, e gli obiettivi complessi. Questo file è usato come il riferimento incrociato basilare che mostra la corrispondenza tra gli ID generati dal sistema con gli ID definiti dall’utente per ogni elemento.
Course Structure Table Le informazioni basilari sulla struttura del corso includendo AU e blocchi del corso e mostrando come sono organizzati tra loro. Infine, specifica l’ordine in cui devono essere utilizzati.
Objectives Relationships File Gli obiettivi hanno relazioni complicate e variabili con gli altri elementi del corso. Questo file definisce tutte queste relazioni. Il file in questione è opzionale e dipende dal livello di complessità della descrizione del corso.
Prerequisite Listing A volte è necessario impedire ad uno studente di seguire una lezione se prima non ha raggiunto certi prerequisiti. Questo file permette di associare combinazioni di vincoli in ogni blocco o AU del corso. Ci sono tre livelli di complessità che possono essere usati nella descrizione dei prerequisiti: 1)Un singolo AU o blocco come prerequisito da definire per ogni elemento nel corso. 2)Prerequisiti da definire nella forma di un costrutto logico (attraverso l’utilizzo di “and” o “or”). 3)La definizione di prerequisiti per ogni modalità (Review, Browse, Normal) della lezione
Completion Requirements Mentre lo stato della lezione o dell’obiettivo è determinato entro la lezione dalla logica designata per esso,non è cosi per i blocchi. I blocchi sono creati specificatamente per descrivere la struttura di una corso. Similmente gli obiettivi complessi sono definiti in termini di altri elementi strutturali. Pertanto lo stato dei blocchi e degli obiettivi complessi deve essere determinato dal sistema CMI. Questo file permette di specificare esplicitamente quando un blocco o obiettivo è completo quando esso non è conforme al completamento di default. E’ essenzialmente un file di eccezione.

Salvataggio informazioni di valutazione della lezione

Le informazioni sulla valutazione includono i dati che un CBT o test generano in base al comportamento dello studente che sta seguendo il corso. Possono essere incluse anche elementi come le risposte dello studente, l’attesa nel rispondere, e il percorso dei contenuti che lo studente compie per superare la lezione. Standardizzando il formato dei record relativi alle valutazioni dello studente si permette a più tool di manipolare queste informazioni. Le informazioni sulla valutazione sono contenute su più file. Il nome di questi file è passato alla lezione dal sistema CMI. Se il file già esiste , la lezione aggiunge i nuovi dati al file. Se il file non esiste, il file viene creato e le informazioni salvate. L’analisi delle informazioni non la tratterò in quanto mi dilungherei troppo. Di seguito elencherò i file che immagazzinano queste e altre informazioni sulla lezione. Questi file sono opzionali. Utilizzando tutti e cinque i file si riuscirebbe a salvare tutte le informazioni di cui ha bisogno un CBT.

I file sono i seguenti:

Comments File Una sorta di diario che contiene informazioni circa il feedback dello studente.
Interactions File Un interazione è un input riconosciuto e registrato che lo studente genera tramite il PC verso la lezione. Generalmente questo input è la risposta alle domande del test della lezione.
Objectives Status Comprende informazioni sugli obiettivi, includendo i loro ID e il loro status (superato, fallito, non tentato).
Path file Tiene traccia del percorso di contenuti che uno studente tiene per superare una lezione

Con questa tabella concludo la trattazione sullo standard AICC. Per un analisi più approfondita e dettagliata si possono consultare i White Papers e Technical Reports dell’ AICC e più specificatamente il documento CMI001 AICC/CMI Guidelines for Interoperability .

-- RobertoCorradetti - 25 Sep 2004


to top


Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback