Sperimentare piattaforme Open Source Rapporto sulla metodologia d analisi

Transcript

1 Sperimentare piattaforme Open Source Rapporto sulla metodologia d analisi Rapporto a cura di: Dott. Andrea Massara Dott.ssa Veronica Mobilio

2 Indice: Capitolo 1 L impianto metodologico Introduzione Obiettivi di analisi Processo di analisi Definizione dei requisiti Pianificazione del benchmark Ricerca e documentazione Definizione dei criteri Definizione dello script Test di usabilità Analisi dei dati e valutazione Documentazione e sintesi dei risultati...8 Capitolo 2- Lo studio di usabilità Usabilità o Qualità in Uso Perché l usabilità è importante Analisi degli scenari Definizione del contesto d uso Definizione degli utenti Definizione dei compiti (task) Definizione dell ambiente Definizione degli obiettivi e del contesto di valutazione Metodologia di conduzione del test Preparazione Introduzione (brief) Conduzione del test Termine (debrief)...23 BIBLIOGRAFIA...24 Appendice 1: scheda di valutazione...27 Appendice 2: questionario SUS...28 Appendice 3: griglia di valutazione

3 Capitolo 1 - L impianto metodologico 1.1 Introduzione Presso il Cnipa è stata condotta una sperimentazione volta ad acquisire conoscenze teoriche e pratiche circa le opportunità offerte dalle piattaforme Open Source (OS) per l e-learning. Con l obiettivo di valutare e confrontare alcuni Learning Management System (LMS) è stata messa a punto una metodologia che focalizza l attenzione sull analisi delle funzionalità e degli utenti-tipo in interazione con i sistemi software presi in considerazione. In particolare, il lavoro è stato strutturato prendendo in prestito le principali fasi di un progetto di sviluppo di un sistema informatico ed utilizzando come strumenti di raccolta dati, da un lato, una griglia di valutazione; dall altro, alcuni test di usabilità. Il lavoro sul campo ha consentito di mettere a punto una metodologia semplice e riusabile che permette di analizzare le funzionalità di un sistema tecnologico senza dimenticare mai il target a cui ci si rivolge. 1.2 Obiettivi di analisi La sperimentazione è stata condotta mediante uno studio qualitativo volto a comparare due o più piattaforme e-learning ed effettuato sulla base di criteri di valutazione capaci di consentire una misurazione efficace e oggettiva. Tali criteri investono, da un lato, la verifica degli attributi di qualità del sistema, con particolare riferimento alle funzionalità presenti e alla loro affidabilità ed efficacia; dall altro, l analisi dell interazione, della facilità d apprendimento e della facilità d uso del sistema stesso, sia dalla prospettiva del discente che da quella del docente e del tutor. In questo rapporto viene presentata la metodologia e il processo di definizione, analisi e conduzione dello studio che è stato realizzato attraverso due strumenti fondamentali: una griglia di valutazione che ha consentito di verificare il livello di rispondenza delle piattaforme alle principali funzionalità di un LMS; una serie di test di usabilità condotti su utenti selezionati in base ad alcune variabili fondamentali quali sesso, età e livello di alfabetizzazione informatica. I test di usabilità sono stati introdotti nella sperimentazione ed affiancati alla griglia con l obiettivo di verificare non solo la qualità e l efficacia-efficienza delle funzionalità presenti nei sistemi presi in considerazione, ma anche la loro usabilità dal punto di vista degli utenti che li andranno ad utilizzare. L obiettivo è stato valutare gli LMS dal punto di vista del grado in cui: risultano adeguati ai bisogni e alle aspettative di specifici utenti in relazione a specifici contesti d uso; risultano facili da capire, imparare ed usare; sono percepiti come gradevoli; consentono di eseguire le specifiche attività lavorative e/o formative in maniera corretta, veloce e con soddisfazione; generano pochi errori non critici 1. La metodologia messa a punto, quindi, ha il duplice obiettivo di valutare la qualità dei sistemi software e la loro capacità di innescare tempi brevi di apprendimento, rapida esecuzione dei compiti, basso tasso di errore, facilità nel ricordare le istruzioni di base, alta soddisfazione dell utente 2. 1 Sentinelli M., Usabilità dei nuovi media, Carocci editore, Roma, Shneidermn B., Designing the User Interface: strategies for effective human computer interaction, Addison-Wesley Publishing Co, reading (MA),

4 1.3 Processo di analisi Le fasi in cui si è strutturato il processo di analisi sono: 1. definizione dei requisiti; 2. pianificazione del benchmark; 3. overview e documentazione; 4. definizione dei criteri; 5. definizione dello script; 6. test di usabilità; 7. analisi dei dati e valutazione; 8. documentazione e sintesi dei risultati. La tabella n. 1 riportata di seguito illustra in maniera sintetica le relazioni tra le 8 fasi così definite: Fase Descrizione 1 Definizione dei requisiti In questa fase vengono raccolti ed esplicitati i requisiti fondamentali della sperimentazione. 2 Pianificazione del benchmark In questa fase vengono definite le fasi del processo di benchmark ed individuati i ruoli e le responsabilità all interno del team di ricerca. 3 Ricerca e documentazione In questa fase sono individuate e reperite le fonti di ricerca: studi nazionali, studi internazionali, report dettagliati, griglie di analisi validate. 4 Definizione dei criteri In questa fase sono definiti, sulla base dei risultati ottenuti dalle fasi (1) e (3), i criteri per la valutazione qualitativa e quantitativa delle piattaforme. In base ad essi, viene, quindi, prodotta le griglia di valutazione definitiva. 5 Definizione dello script In questa fase viene preparato un protocollo condiviso per la conduzione del test di usabilità (6). Il protocollo comporta la definizione dei profili utente considerati, del contesto d uso e dell elenco di compiti (task) da portare a termine utilizzando le piattaforme. 6 Test di usabilità In questa fase vengono condotti i test di usabilità sulle piattaforme. Nella definizione della procedura e dei criteri del test, viene utilizzato lo script preparato nella fase (5) e i requisiti definiti nella fase (1). 7 Analisi dei dati e valutazione In questa fase i dati raccolti vengono sintetizzati e valutati in modo qualitativo, attraverso un processo di peer-review. 8 Documentazione e sintesi dei risultati In questa fase vengono documentati i risultati prodotti dallo studio di benchmark ponendo particolare attenzione ed enfasi sulla chiarezza e semplicità di consultazione dei dati raccolti nella comparazione delle piattaforme. Tabella n. 1: Fasi dello studio - - 4

5 Di seguito si descrive con maggiore dettaglio quali sono gli aspetti e i problemi da affrontare durante ciascuna fase del processo di studio. All interno della descrizione delle fasi riportata di seguito viene dedicata particolare rilevanza agli aspetti metodologici relativi ai test e alla definizione dei criteri Definizione dei requisiti I requisiti fondamentali della sperimentazione devono scaturire da un attenta analisi del contesto generale di riferimento e devono essere discussi in maniera approfondita all interno del team. In particolare, in questa fase dello studio, sono emersi una serie di requisiti, considerati essenziali per il raggiungimento degli obiettivi della sperimentazione condotta: Requisito Descrizione Utenti Popolazione eterogenea per attitudine ed esperienza nell uso del computer. Ruoli previsti: discente, tutor, docente. Comunicazione Da verificare l efficacia degli strumenti di comunicazione sincrona e asincrona nel supportare le attività previste (forum, chat, calendario, news, ecc.). Repository Da verificare l efficienza e le funzionalità degli strumenti di supporto al caricamento e all archiviazione dei materiali didattici. Coerenza dell interfaccia Gestione, authoring e tracking dei corsi Da verificare la coerenza tra le diverse funzionalità che costituiscono il sistema nello: - stile di presentazione delle informazioni, - uso delle funzionalità (task breakdown, modalità interazione, ecc.). Da verificare l efficacia delle funzionalità relative alla pianificazione e alla gestione dei corsi, all authoring dei contenuti e al tracciamento delle attività. Tabella n. 2: I requisiti fondamentali della sperimentazione Pianificazione del benchmark La pianificazione del benchmark implica l individuazione delle fasi del processo. Nel fare ciò è stata dedicata una grande attenzione nel costruire un flusso che ottimizzasse le risorse disponibili e garantisse la maggiore efficacia possibile nella raccolta e sintesi dei risultati. In particolare sono stati individuati i seguenti punti mission critical: definizione ed esplicitazione dei requisiti fondamentali; comunicazione e condivisione degli obiettivi di studio all interno del team; definizione dei criteri di valutazione delle piattaforme; individuazione di una metodologia di valutazione dell usabilità coerente al modello normativo degli standard di User Centred Design (ISO/IEC 13407) e di Qualità in Uso (ISO/IEC ); definizione di un protocollo di test. Al fine di ottimizzare il processo di ricerca, analisi e valutazione è stata stabilita, infine, una differenziazione dei compiti e dei ruoli all interno del team che ha condotto il benchmark Ricerca e documentazione Obiettivo di questa fase è stato individuare e reperire quelle fonti di ricerca e documentazione, a livello nazionale ed internazionale, critiche ai fini dell efficacia e della completezza dello studio. In particolare, sono state individuate, selezionate e prese in considerazione le seguenti fonti: best practices nella conduzione di benchmark nazionali e internazionali di Learning Management Systems (LMS); griglie di analisi validate a livello internazionale; - - 5

6 pubblicazioni scientifiche nazionali ed internazionali sulle caratteristiche, le linee di evoluzione e specifiche implementazioni di LMS; documentazione tecnica su standard relativi all e-learning (SCORM, IMS, ecc.); documentazione tecnica relativa alle piattaforme considerate; analisi di mercato nazionali ed internazionali del settore e-learning; testi specifici sull e-learning e sull instructional design; articoli di riviste e siti specializzati Definizione dei criteri In questa fase, sulla base dei risultati ottenuti attraverso il lavoro svolto nella fase 1 relativa alla definizione dei requisiti e nella fase 3 relativa alla individuazione, raccolta ed analisi della documentazione esistente sul tema, sono stati definiti i criteri per la valutazione qualitativa e quantitativa delle piattaforme, arrivando alla redazione e produzione della griglia attraverso cui è stata effettuata la valutazione. I criteri di valutazione individuati sono raggruppabili nelle seguenti macro-categorie: Macro-categoria Piattaforma tecnologica Strumenti per l'amministrazione Sviluppo e gestione del contenuto Strumenti per l'erogazione didattica Supporto agli standard Strumenti per la comunicazione e l'interazione Strumenti per la produttività Strumenti a disposizione del discente Supporto Descrizione In questa categoria sono inseriti i fattori relativi a caratteristiche tecniche, come il supporto di diversi tipi di server e/o database, e a caratteristiche di progettazione del sistema, come la modularità, la portabilità e la flessibilità di integrazione. In generale, queste caratteristiche sono di fondamentale importanza per valutare la qualità del sistema da un punto di vista tecnologico, di sviluppo e scalabilità. In questa categoria sono inserite tutte le caratteristiche che permettono di gestire efficacemente le procedure di accesso al sistema e la customizzazione grafica, la modularità del sistema, dei ruoli e dei permessi e i processi legati alla gestione delle competenze e della relativa certificazione. In questa categoria sono rilevate le potenzialità della piattaforma in termini di creazione (authoring) e gestione (management) del contenuto. Vengono valutati attentamente gli aspetti relativi alla condivisione e riuso del contenuto, alle capacità di creare percorsi di apprendimento e alle modalità di archiviazione. In questa categoria sono inseriti i fattori rilevanti nel processo di erogazione della didattica come la gestione dei corsi, il sistema di help, gli strumenti per la valutazione in itinere e complessiva, la capacità di gestire gruppi di lavoro e la reportistica. In questa categoria sono incluse le caratteristiche relative agli standard di e- learning e di accessibilità supportati. In questa categoria vengono valutati gli strumenti di supporto ai processi di comunicazione e interazione all interno della piattaforma con particolare attenzione alle caratteristiche del forum, del sistema di messaggistica interna e alle procedure di scambio dei file. In questa categoria sono inseriti i fattori che supportano le attività di lavoro quotidiano sul sistema come le funzionalità di ricerca, la scansione temporale attraverso il calendario e il monitoraggio costante dell avanzamento del lavoro svolto. In questa categoria sono inclusi gli strumenti che il discente utilizza per adeguare l interfaccia alle proprie esigenze, per strutturare le proprie attività e per relazionarsi con gli altri membri della comunità. In questa categoria sono valutate le potenzialità di evoluzione del sistema legate alla comunità degli sviluppatori, all adozione in organizzazioni simili e alla disponibilità di partners commerciali. Tabella n. 3: Definizione dei requisiti tecnico, funzionali, organizzati - - 6

7 1.3.5 Definizione dello script Lo script (sceneggiatura) è un documento che specifica nel dettaglio gli attori coinvolti nella simulazione d uso della piattaforma (es. discente, tutor, docente, ecc.), i compiti che questi eseguono (es. iscrizione di un utente al corso, inserimento delle risorse didattiche, ecc.) e il contesto d uso previsto (es. browser supportato, velocità e interruzioni della rete, ecc). Lo script è un vero e proprio protocollo di comunicazione e di lavoro che deve essere condiviso all interno del team. Esso consente di esplicitare con efficacia i requisiti del lavoro e di focalizzare l attenzione del benchmark solo sugli aspetti realmente importanti. Lo script che è stato utilizzato in questo studio segue la traccia di seguito riportata: Creazione e strutturazione di un corso: in questo primo scenario il docente crea un corso, crea gli account per i discenti ed effettua la loro iscrizione al corso, notificando l operazione attraverso l invio di una mail. Creazione e strutturazione di una unità didattica: in questo scenario il docente crea e pubblica una unità didattica all interno del corso utilizzando dei contenuti Scorm con l integrazione di pagine generate dal sistema di authoring della piattaforma. Creazione e verifica di un questionario di valutazione: in questo scenario il docente realizza un test a risposta multipla e verifica i risultati generati da un questionario già erogato. Strutturazione delle attività didattiche: in questo scenario il tutor utilizza il calendario, le news e i messaggi per modulare e notificare il flusso delle attività didattiche. Tracciamento: in questo scenario il tutor monitora l andamento delle attività, individua i discenti a cui segnalare eventuali mancanze ed esporta i dati in locale. Predisposizione dei materiali didattici: in questo scenario il tutor predispone una serie di cartelle pubbliche dove carica i documenti di approfondimento del corso. Fruizione del corso: in questo scenario il discente accede al corso, fruisce il contenuto disponibile ed effettua il test di valutazione previsto. Condivisione di documenti: in questo scenario il discente utilizza le cartelle pubbliche e private per caricare dei documenti e condividerli con gli altri discenti del corso. Partecipazione alle attività didattiche: in questo scenario il discente controlla le news ed eventuali segnalazioni sul calendario, partecipa ad una discussione sul forum del corso contattando il tutor per chiedere spiegazioni dettagliate ed inviando un messaggio ad un discente che ha inserito dei post sul forum. Monitoraggio delle attività svolte: in questo scenario il discente cerca di reperire i dati quantitativi utili per monitorare le attività svolte Test di usabilità La procedura utile per valutare l usabilità di una piattaforma LMS comporta quattro stadi: 1. definizione degli scenari e del contesto d uso, 2. definizione degli obiettivi della valutazione, 3. conduzione dei test, 4. analisi e sintesi dei risultati. Per un analisi più approfondita, cfr. Capitolo 2 Lo studio di usabilità Analisi dei dati e valutazione I risultati ottenuti attraverso la griglia di valutazione sono stati, in questa fase del lavoro, sottoposti ad un ulteriore processo di analisi. L obiettivo è stato ottenere degli indici sintetici per ciascuna area di valutazione che ricordiamo essere: piattaforma tecnologica; strumenti per l'amministrazione; sviluppo e gestione del contenuto; strumenti per l'erogazione didattica; supporto agli standard; strumenti per la comunicazione e l'interazione; strumenti per la produttività; strumenti a disposizione del discente; 7

8 supporto. In particolare, all interno di ciascuna categoria individuata sono stati inseriti una lista di fattori (item). Ad esempio, nella prima categoria Piattaforma tecnologica, è possibile individuare i seguenti item: Piattaforma tecnologica Caratteristica Valutazione 1. Requisiti del browser 3 2. Requisiti del database 1 3. Requisiti del server 2 4. Modularità del codice 3 5. Integrabilità con altri sistemi 1 Tabella n. 4: Esempio di griglia di valutazione compilata Ogni item ha un peso relativo differente. Nell esempio riportato, ad esempio, l item n. 4 ( Modularità del codice ) ha un peso pari a [0.7], mentre l item n. 3 ( Requisiti del server ) ha un peso pari a [0.5]. I pesi dei relativi item sono stati determinati e stabiliti nella fase di definizione dei requisiti della sperimentazione. A questo punto, i valutatori hanno attribuito un valore a ciascun item, utilizzando la seguente scala di valutazione: Scala di valutazione 0 = non presente 1 = soluzione inefficace o parziale 2 = soluzione intermedia 3 = soluzione valida e efficace Tabella n. 5: Scala di valutazione Dopodiché, le valutazioni sono state sottoposte all elaborazione di un foglio di calcolo attraverso il quale si è ottenuto un valore sintetico per ogni categoria, pari alla media dei valori ottenuti moltiplicando la valutazione media complessiva per il peso specifico di ogni item. Infine ogni piattaforma è stata collocata su una scala ordinata di valore, generale o relativa alle singole categorie Documentazione e sintesi dei risultati La documentazione dei risultati comporta la descrizione delle soluzioni scelte in base ai risultati ottenuti attraverso il benchmark. Affinché esso sia un lavoro e quindi uno strumento realmente efficace, si è scelto di dedicare particolare attenzione alla chiarezza e semplicità di consultazione dei dati raccolti, in particolare nella comparazione delle piattaforme. 8

9 Capitolo 2- Lo studio di usabilità 2.1 Usabilità o Qualità in Uso Nella letteratura di settore, le definizioni di usabilità proposte per stabilirne i confini di applicazione sono diverse. Brian Shackel 3, ad esempio, ha definito l usabilità come la capacità di un sistema - in termini di caratteristiche cognitive umane - di essere utilizzato facilmente ed efficacemente da una determinata categoria di utenti, dati uno specifico addestramento e supporto all utente, per svolgere categorie di compiti ben individuate, all interno di specifici scenari ambientali. Questa definizione punta sul fattore umano e su quello ambientale di un sistema. Per questo motivo considera l usabilità come qualità del sistema nella sua globalità, non come attributo della sola interfaccia o in rapporto alle funzionalità presenti e alla mancanza di errori 4. Jacob Nielsen 5, invece, definisce l usabilità come la misura della qualità dell esperienza dell utente in interazione con uno strumento, sia esso un sito web o un applicazione software. Secondo l autore, un prodotto è usabile quando è facile da apprendere, è efficiente nell utilizzo, è semplice da ricordare, permette pochi errori di interazione e di bassa gravità ed è piacevole da utilizzare. In questa definizione, quindi, viene dato particolare risalto agli elementi di interazione tra utente e prodotto. Rispetto a tali definizioni, nel presente studio, la valutazione di usabilità è stata effettuata facendo riferimento al modello di analisi derivato dagli standard ISO/IEC e ISO/IEC Questo modello, a differenza degli altri, consente una valutazione quantitativa degli aspetti legati all interazione tra utenti e sistema e si adatta meglio alle finalità di un benchmark. Pertanto, in questa sede, si preferisce utilizzare non il termine usabilità, ma quello di qualità in uso, coerentemente all utilizzo che si fa di questi termini negli standard menzionati. Nello specifico, essi definiscono la qualità in uso come la capacità di un prodotto software di mettere in grado determinati utenti di raggiungere specifici obiettivi con efficacia, efficienza e soddisfazione, in definiti contesti d uso. Il modello cui si fa riferimento mette in evidenza il fatto che la qualità di un sistema non è data dall essere senza difetti o ricco di funzionalità o tecnologicamente innovativo. Essa è raggiungibile solo tenendo conto delle esigenze degli utenti in relazione al contesto d uso 8. 3 Shackel B., Usability: context, framework, design and evaluation in Shackel B, Richardson S., Human factors for informatics Usability, Cambridge University Press, Cambridge, 1991, pag Commissione interministeriale permanente per l impiego ICT a favore delle categorie deboli o svantaggiate, La Legge Stanca: i riferimenti tecnici, Quaderno CNIPA n. 4, 2005, pag Nielsen J., Usabilità engineering, Accademic Press Inc., Boston, ISO/IEC Ergonomic requirements for office work with visual display terminals (VDTs): è lo standard che definisce i requisiti ergonomici per il lavoro di ufficio con i videoterminali. La parte 11, Guida all'usabilità, fornisce un framework di riferimento per la progettazione e la valutazione dell'usabilità intesa come il grado in cui un prodotto può essere usato da specifici utenti per raggiungere specifici obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d'uso. 7 ISO/IEC 13407: è lo standard che recepisce il processo di produzione user centered. Esso si caratterizza per l'attivo coinvolgimento degli utenti e una chiara comprensione delle loro caratteristiche e dei compiti che svolgono; una appropriata allocazione delle funzioni tra gli utenti e la tecnologia; l'iterazione delle soluzioni progettuali e una progettazione multisciplinare. 8 Commissione interministeriale permanente per l impiego ICT a favore delle categorie deboli o svantaggiate, op. cit, pag

10 Usabilità o Qualità in uso L usabilità, o più specificamente la qualità in uso, viene valutata, in un contesto specifico, dalla misura in cui obiettivi prefissati d uso vengono raggiunti in maniera accurata e completa (efficacia); dalle risorse di tempo, denaro o sforzo mentale che devono essere spese per raggiungere quegli obiettivi (efficienza); dallo misura in cui gli utenti trovano il sistema globalmente accettabile e piacevole da utilizzare (soddisfazione). Il sistema comprende, in questa definizione, il complesso di compiti, strumenti (hardware e software), ambienti fisici e organizzativi che influenzano l interazione. Questo modello di qualità in uso è ben riassunto nella figura seguente: utenti compiti strumenti ambienti Componenti del contesto d uso Efficacia Efficienza Soddisfazione Metriche della qualità in uso Figura n. 1: Qualità in Uso Perché l usabilità è importante Un Learning Management System inusabile è inefficace o addirittura inutile 9 e rappresenta un costo notevole per l organizzazione che lo adotta. In particolare, una mancata attenzione all'usabilità e, in definitiva, alla qualità non fa altro che spostare in avanti, nel ciclo di vita dei prodotti, i costi di acquisizione e di mantenimento del sistema, spesso maggiorandoli e facendoli pesare interamente sull'utente finale. I vantaggi che derivano dall'usabilità non riguardano solo gli utenti finali, ma anche le organizzazioni che la promuovono. In sintesi, per le organizzazioni i benefici si evidenziano in termini di: incremento della qualità dei prodotti; incremento della produttività attraverso: - riduzione dei tempi di sviluppo, - riduzione degli interventi e dei costi di manutenzione, - riduzione degli interventi e dei costi di assistenza (ad esempio degli help desk), - riduzione dei costi della formazione per gli utenti finali, - riduzione della documentazione utente (manuali e guide operative) e dei tempi per la sua realizzazione. Per gli utenti finali, invece, i vantaggi si evidenziano in termini di: incremento della produttività attraverso: - riduzione dei tempi di esecuzione delle attività, - riduzione degli errori e dei tempi di recupero degli errori, - riduzione dei tempi per richiedere supporto e assistenza, - riduzione dei tempi di apprendimento (formazione, consultazione dei manuali); incremento della soddisfazione; incremento della qualità del lavoro, anche attraverso la riduzione della fatica e dello stress Inutile perchè vale la regola se l utente non la trova, la funzione non esiste [Sentinelli M., op. cit., pag. 76]. 10 Nielsen J., Designing Web Usability: the practice of simplicity, New Riders Publishing, Indianapolis,

11 2.2 Analisi degli scenari Lo studio di usabilità è stato svolto prendendo in considerazione tre differenti scenari: Scenario a) denominato Supportare l auto-apprendimento : ci si trova di fronte alla dinamica classica dell e-learning dove vi è un ente erogatore della formazione, un numero variabile di utenti da formare che rappresentano il target di riferimento, un tempo x entro il quale chiudere il progetto e dei contenuti strutturati da fruire in auto-apprendimento. Scenario b) denominato Supportare il blended learning : presenta una situazione in cui è fondamentale il ruolo del tutor. Il progetto di formazione si svolge parte in presenza e parte a distanza, motivo per cui si pone il problema di coordinare i calendari didattici degli eventi previsti e sincronizzare le diverse attività. In questo caso, i tempi e le modalità di fruizione possono essere profondamente differenti, così come i materiali didattici presentati in aula e quelli utilizzati a distanza devono essere complementari o, per lo meno, correlati tra loro. In questo scenario, è cruciale la gestione dell aspetto cronologico e l organizzazione temporale del progetto, ma l aspetto positivo riguarda il fatto che già esiste un gruppo di persone che si conosce e che ha potuto socializzare in presenza. Scenario c) denominato Supportare una comunità virtuale : presenta la situazione tipica di una comunità virtuale. Le community on line sono una particolare declinazione del concetto di comunità. Con questo termine si fa riferimento a quelle comunità che nascono e si sviluppano secondo i principi tipici di una comunità, ma interagiscono in uno spazio virtuale mediato elettronicamente. Le comunità virtuali sono, infatti, i luoghi dove si mettono in comune le risorse (la tecnologia), le informazioni (il repertorio), si lavora a distanza (l impresa comune) e si socializza (l impegno). Esse però danno origine a legami deboli di natura connettiva che si sviluppano attraverso le reti telematiche. Per questo motivo è necessario studiare un modello di sviluppo organizzativo e tecnologico di tali comunità che da un lato, consenta loro di beneficiare del network cui appartengono; dall altro, non ne soffochi l autonomia e le dinamiche di sviluppo e funzionamento interno. E stato scelto questo approccio metodologico perché la definizione degli scenari ha un ruolo fondamentale in quanto offre un'opportunità non trascurabile per catturare ed individuare in maniera chiara i principali requisiti di un sistema. Uno scenario descrive e fornisce indicazioni chiare e precise su un contesto d uso, sulle relazioni tra gli elementi caratterizzanti il contesto, sugli utenti e, in particolare, sulle attività che essi svolgono e sulle esigenze che scaturiscono dall insieme degli elementi e dei fattori che costituiscono il contesto preso in analisi. Lo scenario quindi va oltre il flusso e la sequenza procedurale. È un metodo che permette di integrare le diverse componenti di un sistema e le sue funzionalità intorno all'utente, fornendo al progettista alcune indicazioni vive ed indispensabili 11. La definizione di un contesto d uso, in particolare, permette di individuare con estrema chiarezza alcune richieste fondanti (claims), che costituiscono la rappresentazione dei requisiti di un sistema informatico. Un claim, quindi, è un ipotesi sugli effetti che le caratteristiche di un sistema possono avere sulle attività degli utenti. L analisi dei claim permette di identificare le conseguenze positive o negative derivanti dall uso del sistema in un determinato contesto preventivamente delineato Carroll J. M., Making use: scenario based design of human computer interaction, MIT Press, Carroll J.M., Rosson M. B., Getting around the task-artifact cycle: how to make claims and design by scenario, ACM Transactions on information systems. Vol. 10, N. 2, 1992, pag

12 Di seguito, nella tabella n. 6, n. 7 e n. 8, si riporta la descrizione dei tre scenari presi in analisi e dei corrispondenti claim. DESCRIZIONE SCENARIO N. 1 SUPPORTARE L AUTO-APPRENDIMENTO Il Comune X ha acquistato da un fornitore esterno un corso di inglese fruibile in modalità e-learning (WBT). Il responsabile della formazione interna dell amministrazione deve coinvolgere nel progetto i dipendenti dell amministrazione consentendo loro di fruire del corso a distanza supportati da un tutor che fornirà assistenza tecnica e didattica. Per fare ciò decide di utilizzare una piattaforma Open Source. Installata la piattaforma su un server, configurato il sistema ed effettuato l upload dei contenuti, il progetto è pronto per partire. Per avvisare gli utenti di questa nuova opportunità loro offerta decide di inviare una mail a ciascun dipendente esplicitando gli obiettivi e le caratteristiche fondamentali del progetto di formazione, le specifiche per accedere al sistema (userid e password loro attribuiti e modalità di navigazione), il tempo entro il quale fruire i materiali didattici e come ottenere supporto tecnico e didattico dal tutor attraverso gli strumenti di comunicazione a disposizione. Il progetto parte e gli utenti, dopo esser riusciti ad accedere al sistema, cominciano a studiare i materiali didattici, a dialogare tra di loro tramite i forum tematici strutturati e moderati dal tutor e, infine, a compilare i test on line attraverso i quali verificare le conoscenze apprese. Dopo circa sei mesi dall avvio del progetto il referente ha la necessità di monitorare e quindi verificare come sta andando la formazione. Accede quindi alla piattaforma lato back office e si scarica tutta la reportistica disponibile tramite la quale può verificare le attività svolte dal tutor e da tutti i partecipanti al progetto. Dall analisi dei report, dei messaggi che gli utenti si sono scambiati nei forum e dei documenti che hanno condiviso capisce che il progetto sta andando molto bene e decide di pubblicare una news sulla piattaforma per congratularsi con gli utenti del sistema. ANALISI DEI CLAIM 1. Il sistema permette di importare una lista di utenti utilizzando formati diffusi (Es: csv, excel, ecc.). 2. Il sistema di messaggistica permette di inviare una mail a tutti i corsisti iscritti. 3. La fase di login è semplice e intuitiva e permette di accedere e modificare i propri dati personali. 4. Il supporto (help) fornisce indicazioni chiare sull utilizzo contestuale delle funzionalità della piattaforma. 5. Il sistema permette un accesso intuitivo ai materiali didattici e alla loro fruizione anche a utenti poco esperti. 6. Il sistema supporta in maniera semplice e intuitiva le comunicazioni sincrone ed asincrone tra corsisti e tutor. 7. Il sistema permette ai corsisti di accedere intuitivamente ai dati relativi alla propria fruizione (tempo trascorso, stato di avanzamento di un corso, messaggi e notifiche in arrivo, post scritti nel forum, ecc.) e fornisce il quadro complessivo delle attività svolte. 8. Il sistema supporta il corsista durante la compilazione dei test attraverso una navigazione intuitiva e feedback adeguati. 9. Il sistema permette ai tutor di supportare attivamente i corsisti durante il periodo di fruizione. 10. Il sistema permette un accesso rapido ai dati della reportistica e supporta intuitivamente l analisi aggregata, la stampa e l esportazione (in formato csv, excel) di tali dati. Tabella n. 6: Descrizione dello scenario n. 1 e dei relativi claim 12

13 DESCRIZIONE SCENARIO N. 2 SUPPORTARE IL BLENDED LEARNING La Regione Y ha messo a punto per i responsabili dei servizi dell amministrazione regionale e locale un corso di formazione in modalità blended sulla gestione informatica dei flussi documentali adottando standard che garantiscano sicurezza e privacy delle informazioni e dei dati. Data la complessità delle tematiche trattate il corso è stato progettato in modalità blended: ci saranno una serie di lezioni che si svolgeranno in presenza e dei moduli di approfondimento da svolgere a distanza attraverso l uso di una piattaforma e-learning di tipo Open Source adottata ad hoc per il presente progetto. Definito nel dettaglio il calendario didattico (specificando le attività in presenza e quelle a distanza) e preparati tutti i materiali didattici, parte il corso di formazione in aula. Durante le prime settimane i partecipanti al progetto hanno modo di conoscersi e fare gruppo, avvicinarsi alle tematiche trattate e, infine, socializzare con il sistema tecnologico configurato ad hoc per loro. Accedendo alla piattaforma trovano una descrizione del progetto, un calendario didattico attraverso il quale verificare quali attività svolgere e dove (se in aula e a distanza), un repository dove sono raccolti tutti i materiali didattici presentati durante le lezioni in presenza, un forum e una chat per dialogare con i loro colleghi e infine un area contenente i materiali didattici di approfondimento e i test di valutazione. Dopo le prime due settimane di corso in aula il lavoro deve spostarsi a distanza. A questo punto cioè gli utenti devono proseguire le loro attività utilizzando la piattaforma e- learning presentata in aula. La loro necessità più grande diventa capire cosa e come devono fare per proseguire lo studio; avere supporto didattico e tecnico da parte di un tutor e colmare la distanza imposta dalla mediazione della tecnologia dialogando e collaborando con i colleghi attraverso i diversi strumenti a disposizione. Così imparano a non solo ad utilizzare il calendario delle attività didattiche, l agenda personale e i forum tematici moderati dal tutor ma anche a collaborare a distanza condividendo file e comunicando con gli altri partecipanti al progetto sia in maniera sincrona, che asincrona. Al termine del progetto, la regione y si trova a dover verificare il successo e il gradimento del corso. Per far ciò utilizza non solo i questionari di gradimento che gli utenti hanno compilato una volta tornati in aula al termine del progetto formativo, ma anche tutta la reportistica della piattaforma che offre una panoramica delle attività svolte dagli utenti durante le attività intermodulo svolte a distanza. ANALISI DEI CLAIM 1. Il sistema supporta in maniera efficace la scansione cronologica del lavoro con la possibilità di modificare rapidamente il flusso delle attività preventivate (Calendario e News). 2. Il sistema permette di strutturare gruppi con caratteristiche, privilegi e funzionalità differenti. 3. Il sistema permette di strutturare un archivio di documenti, in maniera semplice e rapida, con modalità di accesso diversificate. 4. Il sistema permette di strutturare e moderare ambienti di comunicazione sincrona ed asincrona con funzionalità di tracciamento e notifica multilivello delle comunicazioni effettuate. 5. Il sistema permette di strutturare spazi personalizzati per i corsisti. 6. Il sistema struttura i dati degli utenti in modalità Agenda favorendo il reperimento e la comunicazione tra gli utenti stessi. 7. Il sistema supporta le attività dei tutor nelle diverse fasi del progetto formativo. 8. Il sistema permette di monitorare il gradimento e le esigenze dei corsisti attraverso i sondaggi con un approccio semplice e non invasivo durante la fruizione. 9. Il sistema permette di strutturare e accedere rapidamente ai materiali didattici facilitando le attività di download e stampa dei materiali stessi. 10. Il sistema permette di accedere e interpretare i dati relativi alla reportistica con il focus posto sull analisi temporale dei dati presenti. Tabella n. 7: Descrizione dello scenario n. 2 e dei relativi claim 13

14 DESCRIZIONE SCENARIO N. 3 SUPPORTARE UNA COMUNITA VIRTUALE L Ente Z eroga regolarmente formazione, corsi o seminari tecnici, sia in presenza che a distanza. Il numero delle persone che ha partecipato e partecipa a tali eventi formativi cresce esponenzialmente e, al tempo stesso, sono individuabili alcune persone che partecipano in maniera costante e regolare a tutti o quasi gli eventi organizzati. Attorno all ente z si è formata quindi una comunità molto forte, ovvero un insieme di persone che condividono degli interessi e hanno un linguaggio e una cultura di base comune. Tali persone però interagiscono solo in occasione di questi eventi formativi organizzati secondo un calendario prestabilito. Per questo motivo l ente z ha deciso di installare su un server una piattaforma Open Source e configurare il sistema in maniera tale da trasformare la sua comunità di utenti in una comunità virtuale ovvero in una comunità che, attraverso la mediazione di una tecnologia, può interagire anche a distanza collaborando e condividendo informazioni e conoscenza in rete. Per fare ciò l ente z ha deciso di installare una piattaforma e-learning perché essa gli consente di avere a disposizione strumenti utili: - per comunicare velocemente news di interesse comune e pubblicare le date dei nuovi eventi in programma; - monitorare le attività dei membri della comunità e dividerli eventualmente in gruppi in base ai loro interessi ed obiettivi; - agevolare una comunicazione orizzontale e verticale veloce ed efficace attraverso strumenti sia sincroni che asincroni; - condividere documenti e materiali didattici in una logica sia top down, che bottom up. Oltre a ciò la piattaforma consente di gestire in maniera semplice la creazione degli account e dei profili degli utenti e avere un buon corpus di dati sull utilizzo effettivo degli strumenti e dell ambiente tecnologico messo a disposizione. ANALISI DEI CLAIM 1. L installazione della piattaforma è un processo semplice che non richiede competenze specifiche per il tipo di tool ed è supportata da una documentazione esaustiva. 2. La configurazione delle impostazioni di base è modulare e facilmente modificabile in momenti diversi e permette un rapido accesso ai parametri delle varie sezioni. 3. Il caricamento dei contenuti è rapido e semplice. 4. Il sistema permette una strutturazione modulare dei vari ambienti con possibilità di condizionare le modalità di accesso e le funzionalità presenti in ogni ambiente. 5. Il sistema permette la creazione di modalità di accesso personalizzate e profilazione dei corsisti. 6. Il sistema permette di supportare la nascita, l articolazione e l evolversi di una comunità di lavoro (gruppi di lavoro). 7. Il sistema permette di coordinare le attività dei vari gruppi attraverso la strutturazione temporale dei vari flussi e la notifica tempestiva degli eventi. 8. Il sistema supporta attivamente le attività collaborative di comunicazione all interno di un gruppo e tra i gruppi presenti. 9. Il sistema supporta attivamente le attività di condivisione dei materiali didattici all interno di un gruppo e tra i gruppi presenti. 10. Il sistema permette di monitorare ed estrapolare i dati relativi all utilizzo degli strumenti. Tabella n. 8: Descrizione dello scenario n. 3 e dei relativi claim 14

15 2.3 Definizione del contesto d uso Per quanto riguarda il contesto d uso, si è deciso di porre attenzione ai fattori che influenzano i seguenti aspetti: 1. Utenti: coloro che interagiscono col sistema, a tutti i livelli. 2. Compiti: l insieme delle attività e dei flussi che caratterizzano i processi di lavoro svolti sulla piattaforma. 3. Strumenti e ambienti: l insieme dei fattori ambientali, culturali e tecnici che influenzano le caratteristiche del contesto d uso Definizione degli utenti I profili utente che sono stati considerati nella fase di definizione degli obiettivi del test di usabilità sono: docente, tutor e discente. Per ciascuno dei profili sono stati condotti cinque test con utenti selezionati tra gli utenti potenziali (e quindi tutti dipendenti di pubbliche amministrazioni) e in base a tre variabili fondamentali: sesso, età e livello di competenza nell uso del computer. Il numero degli utenti su cui è stato condotto il test è stato definito in base alle risorse disponibili e all attendibilità del metodo dichiarata nella letteratura esistente sul tema. In particolare, i test di usabilità che sono stati condotti rientrano nella metodologia della task analysis che permette, più delle altre, una rilevazione quantitativa e comparativa delle caratteristiche di usabilità. Essa prevede il coinvolgimento diretto degli utenti finali che sono chiamati ad utilizzare il prodotto eseguendo una serie di compiti (task): si selezionano gli utenti; prima dell inizio dei test vengono definiti gli obiettivi e, in funzione di questi, i task da far eseguire nella sperimentazione; durante l effettuazione dei compiti il valutatore misura le prestazioni e rileva gli errori di utilizzo; in sede di analisi si confrontano i risultati sia dal punto di vista qualitativo, che statistico-quantitativo. Per la presente sperimentazione, però, la metodologia della task analysis è stata arricchita utilizzando l aspetto fondamentale della metodologia nota con il nome di thinking aloud che consiste nel far verbalizzare agli utenti quello che pensano durante l esecuzione di una attività. Il motivo per cui si è utilizzata questa tecnica sta nella volontà di far emergere attraverso i test anche le logiche di interazione e il modello d uso del sistema da parte dell utente 13. Definita la metodologia è stato necessario stabilire il numero di test da effettuare. Secondo la letteratura accademica e scientifica: nel caso del thinking aloud il numero di utenti da utilizzare va definito in relazione alle risorse disponibili: in ogni caso almeno tre campioni per classe di utenti (in questo caso profilo discente, docente e tutor); nel caso dell analisi dei task il numero degli utenti da utilizzare va definito in relazione alle risorse disponibili: per ottenere dati qualitativi dai 3 ai 5 utenti per profilo; per ottenere dati quantitativi per comparazioni ed indici, almeno 20 utenti 14. Dati gli obiettivi e lo scopo principale del presente studio (individuare la piattaforma che meglio risponde alle esigenze formative del CNIPA in particolare e di una PA in generale) si è scelto di realizzare un analisi di tipo qualitativo conducendo il test su: 5 utenti con profilo discente, 5 utenti con profilo tutor, 5 utenti con profilo docente. Questa scelta deriva dal fatto che con 5 utenti si è perfettamente in grado di scoprire la maggior parte dei problemi di usabilità in un tempo e con delle risorse ragionevoli Nielsen J., Mach R. L., Usability Inspection Methods, John Wiley & Sons, New York, Secondo la letteratura sul tema, in funzione del rapporto costi/benefici, selezionare e condurre i test su 5 utenti costituisce la soluzione più conveniente [Neilsen J., Marck R. L., Usability Inspection Methods, john Wiley & Sons, New York 1994; Rubin J., Handbook of Usability Testing, John Wiley & Sons, New York, 1994; Bias R., Mayhew, Cost-Justidying Usability, AP Professional, Cambridge (MA), 1994]. 15 Bias R., Mayhew, Cost-Justidying Usability, AP Professional, Cambridge (MA),

16 2.3.2 Definizione dei compiti (task) Dall analisi dei claim scaturiscono i compiti (task) che sono stati elaborati e utilizzati per effettuare lo studio di usabilità e per misurare la reale rispondenza del sistema ai requisiti fondamentali. I task che sono stati richiesti in fase di test sono: I. Creazione e configurazione di un corso Utente: docente Descrizione: in questo primo scenario il docente crea un corso, crea gli account dei discenti ed effettua la loro iscrizione al corso, notificando l operazione tramite l invio di una mail. Script: 1. login del docente; 2. creazione del corso con l impostazione dei parametri richiesti; 3. creazione degli account; 4. iscrizione dei discenti al corso; 5. invio del messaggio di notifica. II. Creazione e strutturazione di una unità didattica Utente: docente Descrizione: in questo scenario il docente crea e pubblica una unità didattica all interno del corso utilizzando dei contenuti Scorm con l integrazione di pagine generate dal sistema di authoring della piattaforma. Script: 1. login del docente; 2. importazione del pacchetto Scorm; 3. creazione delle pagine integrative; 4. pubblicazione del corso. III. Creazione e verifica di un questionario di valutazione Utente: docente Descrizione: in questo scenario il docente realizza un test a risposta multipla per l utilizzo nel proprio corso e verifica i risultati generati da un questionario già erogato. Script: 1. login del docente; 2. creazione dell archivio delle domande a risposta multipla (5 domande); 3. creazione di un nuovo questionario di valutazione; 4. verifica dei risultati ottenuti in questionario già attivo IV. Strutturazione delle attività didattiche Utente: tutor Descrizione: in questo scenario il tutor utilizza il Calendario, le news ed i messaggi per modulare e notificare il flusso delle attività didattiche. Script: 1. login del tutor; 2. inserimento nel calendario delle attività previste; 3. scrittura e pubblicazione delle news; 4. scrittura ed invio di messaggi a discenti con situazioni particolari (per i quali è necessario un messaggio individuale). V. Tracciamento Utente: tutor Descrizione: in questo scenario il tutor monitora l andamento delle attività svolte, individua i discenti a cui segnalare eventuali mancanze ed esporta i dati in locale. Script: 1. login del tutor; 2. accesso alle sezione che presenta i dati relativi alla attività svolte dai discenti; 3. consultazione dei dati; 16

17 4. invio di un messaggio di notifica ad un discente; 5. esportazione dei dati in locale. VI. Predisposizione dei materiali didattici Utente: tutor Descrizione: in questo scenario il tutor predispone una serie di cartelle pubbliche dove carica i documenti di approfondimento del corso. Script: 1. login del tutor; 2. strutturazione delle cartelle pubbliche; 3. caricamento dei file nelle cartelle VII. Fruizione del corso Utente: discente Descrizione: in questo scenario il discente accede al corso, fruisce il contenuto disponibile ed effettua il test di valutazione previsto. Script: 1. login del discente; 2. accesso alle unità che compongono il corso; 3. fruizione delle unità; 4. individuazione del test di valutazione associato al corso; 5. risposta alle domande del test ed eventuale verifica immediata dei risultati conseguiti. VIII. Condivisione di documenti Utente: discente Descrizione: in questo scenario il discente utilizza le cartelle pubbliche e private per caricare dei documenti e condividerli con gli altri discenti del corso. Script: 1. login del discente; 2. individuazione delle cartelle pubbliche e private; 3. caricamento del file nella cartella privata; 4. condivisione del file attraverso la cartella pubblica. IX. Partecipazione alle attività didattiche Utente: discente Descrizione: in questo scenario il discente controlla news ed eventuali segnalazioni sul calendario, partecipa ad una discussione sul forum del corso contattando il tutor per chiedere spiegazioni dettagliate ed inviando un messaggio ad un discente che ha inserito dei post sul forum. Script: 1. login del discente; 2. consultazione del Calendario e della sezione News; 3. individuazione del forum e di una discussione; 4. risposta ad un post del forum; 5. invio del messaggio di richiesta al tutor; 6. invio del messaggio al discente compagno di corso. X. Monitoraggio delle attività svolte Utente: discente Descrizione: in questo scenario il discente cerca di reperire dei dati quantitativi per monitorare le attività svolte. Script: 1. login del discente; 2. individuazione della sezione dove reperire i dati; 3. verifica della congruità dei dati; 17

18 TASK UTENTE I II III IV V VI VII VIII IX X Docente Tutor Discente Tabella n. 9: Distribuzione Utenti/task Definizione dell ambiente Il contesto d uso preso in analisi vede la considerazione di diversi fattori legati, in questo caso, alla fruizione del sistema tramite web browser. Per il profilo docente non sussistono particolari vincoli tecnologici, a parte l uso del solo protocollo http per le comunicazioni client/server. Per il discente, invece, potrebbero sussistere problemi legati alla banda disponibile e alla configurazione della relativa postazione. Date queste premesse, sono state utilizzate le seguenti postazioni di test: Tipologia postazione 1. Sistema operativo: Microsoft Windows XP Professional, versione 2002, service pack 2. Processore: Pentium 4 CPU 2.99 GHz Ram: 512 MB Tipo di connessione e banda: LAN 2. Sistema operativo: Microsoft windows xp professional, versione 2002, service pack 2. Processore: Centrino 1.60 GHz Ram: 128 MB Tipo di connessione e banda: Modem 56 KB Tabella n. 10: Tipologia di postazioni di test utilizzata 2.4 Definizione degli obiettivi e del contesto di valutazione Gli obiettivi della valutazione e il contesto d uso in cui questa si colloca sono i parametri fondamentali su cui si basa l attendibilità dei risultati. Per quanto riguarda gli obiettivi, si è fatto riferimento alla definizione dei requisiti effettuata nella prima fase del processo che ha portato alla realizzazione e alla produzione della sperimentazione (cfr Definizione dei requisiti ). In questo modo sono state identificate le principali metriche 16 di valutazione dell usabilità, divise in tre differenti categorie: a. Efficacia: la misura in cui gli obiettivi d uso prefissati vengono raggiunti (ovvero la misura in cui un utente è in grado di raggiungere l obiettivo di un compito in modo corretto e completo); b. Efficienza: la quantità di risorse di tempo, denaro o sforzo mentale che devono essere spese per raggiungere gli obiettivi di efficacia; c. Soddisfazione: la misura in cui gli utenti trovano il sistema globalmente accettabile e piacevole. Le misure che sono state utilizzate per le tre metriche sono rispettivamente: a. il tempo impiegato per eseguire un compito; b. il numero di errori commessi nell esecuzione di un compito; c. le reazioni dell utente raccolte attraverso la trascrizione dei commenti a voce alta fatti durante il test e un questionario somministrato al termine del test stesso. 16 Il termine metrica viene utilizzato in ingegneria dell usabilità per indicare i dati oggettivi di valutazione, che vengono distinti da quelli soggettivi. 18

19 Nel prendere in considerazione queste metriche è stata prestata particolare attenzione alla differenza esistente tra i concetti di facilità d uso e facilità di apprendimento. Facilità d uso e facilità d apprendimento: perché sono differenti. Gli obiettivi di usabilità possono essere orientati alla valutazione di due parametri differenti: - la facilità d uso, - la facilità di apprendimento. Facilità d uso Si focalizza sull uso del prodotto da parte di utenti esperti, che usano il sistema abbastanza frequentemente, tanto da mantenere un buon livello di esecuzione dei compiti. La facilità d uso viene definita anche dalla velocità potenziale, dall efficienza, dalla idoneità alla personalizzazione che un interfaccia offre all utente esperto. Facilità d apprendimento Si concentra sull esperienza per gli utenti novizi, ancora in fase di apprendimento o per gli utenti che usano il prodotto con scarsa frequenza. Si definisce in base al tempo impiegato nel completamento del compito e al numero degli errori commessi. La seguente lista di obiettivi di usabilità è stata predisposta per mettere a confronto le piattaforme su processi comuni. Questi processi, che definiscono utenti, compiti e ambienti, vengono comunemente definiti casi d uso: Casi d uso considerati Caso 1: Creazione e strutturazione di un corso Caso 2: Creazione e strutturazione di una unità didattica Caso 3: Creazione e verifica di un questionario di valutazione Caso 4: Strutturazione delle attività didattiche Caso 5: Tracciamento Caso 6: Predisposizione dei materiali didattici Caso 7: Fruizione del corso Caso 8: Condivisione di documenti Caso 9: Partecipazione alle attività didattiche Caso 10: Monitoraggio delle attività svolte Tabella n. 11: Casi d'uso 19

20 In ciascuno dei casi d uso preso in considerazione è stato identificato un set di obiettivi di usabilità, su cui è stata valutata ciascuna soluzione tecnologica. A tal scopo, vediamo nel dettaglio gli obiettivi di usabilità considerati e gli indicatori scelti: Task/Tipologia obiettivo Descrizione/indicatore Caso 1: Creazione e strutturazione di un corso 1.A Facilità d uso- efficienza Tempo impiegato nel completamento del task 1.B Facilità d uso- efficacia Numero di errori fatti nell esecuzione del task Caso 2: Creazione e strutturazione di una unità didattica 2.A Facilità d uso- efficienza Tempo impiegato nel completamento del task 2.B Facilità d uso- efficacia Numero di errori fatti nell esecuzione del task Caso 3: Creazione e verifica di un questionario di valutazione 3.A Facilità Facilità d uso - efficacia Numero di errori fatti nell esecuzione del task 3.A Facilità d uso- efficienza Tempo impiegato nel completamento del task Caso 4: Strutturazione delle attività didattiche 4.A Facilità d uso- efficienza Tempo impiegato nel completamento del task 4.B Facilità d uso- efficacia Numero di errori fatti nell esecuzione del task Caso 5: Tracciamento 2.A Facilità d uso- efficienza Tempo impiegato nel completamento del task 2.B Facilità d uso- efficacia Numero di errori fatti nell esecuzione del task Caso 6: Predisposizione dei materiali didattici 2.A Facilità d uso- efficienza Tempo impiegato nel completamento del task 2.B Facilità d uso- efficacia Numero di errori fatti nell esecuzione del task Caso 7: Fruizione del corso 7.A Facilità d apprendimentoefficienza Tempo impiegato nel completamento del task 7.B Facilità d apprendimento- efficacia Numero di errori fatti nell esecuzione del task Caso 8: Condivisione di documenti 8.A Facilità d apprendimentoefficienza Tempo impiegato nel completamento del task 8.B Facilità d apprendimento- efficacia Numero di errori fatti nell esecuzione del task 20