Ciao a tutti. Grazie per essere qui con me oggi. Oggi parlerò di un progetto a cui ho lavorato, intitolato "Dallo sviluppo al test: un percorso di creazione e convalida di un componente aggiuntivo JMP".
Solo un po' di informazioni su di me. Innanzitutto, mi presento. Sono uno studente laureato che sta conseguendo un dottorato di ricerca in Scienze Matematiche presso la Clemson University, negli Stati Uniti. I miei interessi di ricerca riguardano principalmente la progettazione sperimentale e l'apprendimento delle preferenze. Sono tirocinante presso il team DOE & Reliability di JMP dall'estate del 2024. Durante il mio periodo lì, ho lavorato a progetti relativi sia alla sperimentazione a scelta discreta che al test del software. Due campi piuttosto diversi. Questo è abbastanza su di me.
Proseguirò con una panoramica del discorso di oggi. Innanzitutto, nella prima sezione di questo discorso, parlerò delle motivazioni che ci hanno spinto a creare questo componente aggiuntivo che abbiamo sviluppato durante l'estate. La motivazione è che stavamo conducendo alcuni studi di usabilità per il programma Easy DOE di JMP e stavamo cercando di comprendere le preferenze dell'interfaccia utente di individui appartenenti a diversi gruppi demografici della base utenti. Dopo aver parlato delle motivazioni che ci hanno spinto a creare questo componente aggiuntivo, ne parlerò concretamente e ne fornirò una dimostrazione. Infine, parlerò brevemente del test del componente aggiuntivo tramite il framework di unit test JSL per convalidare l'applicazione o il componente aggiuntivo che abbiamo creato.
Ecco la prima sezione. La motivazione per la creazione del nostro componente aggiuntivo. Come alcuni di voi sapranno, all'interno di JMP è presente un programma chiamato Easy DOE. Questo programma viene utilizzato per aiutare le persone, per guidarle attraverso l'intero processo di progettazione e analisi di un esperimento. Il flusso di lavoro di Easy DOE presenta un paio di componenti diversi. Lo sperimentatore inizia definendo i fattori e le risposte a cui è interessato. Successivamente, seleziona il modello che desidera utilizzare per analizzare i dati che intende raccogliere. Dopo aver selezionato un modello, progetta un esperimento per il suo modello.
Una volta progettato l'esperimento, possono eseguirlo e quindi inserire i dati raccolti nella scheda Inserimento dati. Una volta raccolti i dati, possono analizzare il modello. Analizzare i dati e adattare il modello. Infine, possono utilizzare il modello per fare previsioni e selezionarne le impostazioni ottimali, se sono interessati. Infine, possono visualizzare un report riepilogativo del modello.
Un aspetto particolare che ci interesserà oggi è la scheda Analizza. Come alcuni di voi che hanno utilizzato Easy DOE sapranno, la scheda Analizza si presenta così, come mostrato nella Figura 2. Durante l'estate, ci interessava vedere quali modifiche apportare ad alcune parti della scheda Analizza per renderla più fruibile per gli sperimentatori e gli utenti che utilizzavano Easy DOE. Alla fine, abbiamo proposto un paio di versioni diverse dell'interfaccia utente che gli utenti avrebbero potuto visualizzare, e volevamo scoprire quale di queste versioni fosse la più apprezzata.
Questo design dell'interfaccia utente, così come l'avevamo progettato, aveva una struttura fattoriale. La parte specifica dell'interfaccia utente che ci interessava era questa guida in hover. Questa guida in hover presenta un paio di messaggi diversi che informano l'utente su alcune proprietà statistiche del modello. Alcuni di questi messaggi nelle impostazioni della guida in hover includono il messaggio "Inserimento", che indica se un termine è stato inserito nel modello. Avevamo due versioni diverse per questo messaggio. Il messaggio "Significanza", che indica se il termine è significativo o meno. Un messaggio "Eredità", che indica perché un certo termine è stato incluso nel modello, anche se è insignificante?
Spesso, esiste questa proprietà chiamata ereditarietà, per cui se un termine di interazione è significativo, ma l'effetto principale non lo è, lo includiamo comunque. Infine, un ultimo fattore di questa impostazione della guida in alto a sinistra era la posizione della guida in alto a sinistra. È contenuta in un intervallo di confidenza o nella colonna di anteprima?
Volevamo scoprire quale di queste impostazioni fosse preferita dagli utenti. Come dicevo, avete visto che avevamo quattro fattori. Due di questi fattori o tre di questi fattori avevano due livelli, e poi uno dei fattori aveva tre livelli, quindi c'era la possibilità di una differenza di 24 diverse versioni dell'interfaccia utente per le impostazioni di aiuto al passaggio del mouse.
Un altro aspetto da considerare è che, all'interno di Easy DOE, spesso gli utenti di Easy Doe sono persone alle prime armi o con una discreta esperienza nella progettazione di esperimenti. A volte, però, abbiamo anche persone esperte nella progettazione di esperimenti che utilizzano Easy Doe, e possono utilizzarlo per uso personale o per scopi didattici. Abbiamo diversi gruppi demografici che utilizzano Easy Doe. Volevamo scoprire quali impostazioni di guida al passaggio del mouse sono preferite dai diversi gruppi demografici, in modo da poter personalizzare la progettazione della guida al passaggio del mouse per ciascun gruppo demografico.
Volevamo affrontare questo problema attraverso il framework della sperimentazione di scelta discreta contestuale. Parlerò brevemente di questo framework. Innanzitutto, parlerò del processo di raccolta dati. Nella sperimentazione di scelta discreta contestuale, si ha un gruppo di partecipanti e si hanno a disposizione alcune informazioni di covariazione su questi partecipanti. O, ad esempio, le chiamiamo informazioni di covariazione o informazioni contestuali. Spesso potrebbero essere informazioni demografiche sui propri utenti.
In questo contesto, sottoponiamo i diversi partecipanti a un questionario, in cui a ogni domanda viene chiesto loro di confrontare due o più progetti alternativi e di scegliere quello che preferiscono. Il processo di raccolta dati è piuttosto intuitivo e riflette il modo in cui le persone potrebbero scegliere le opzioni nella vita reale.
Ora parlerò un po' di modellazione e analisi per la sperimentazione di scelte discrete contestuali. Una volta raccolti i dati, è possibile adattare a questi dati un modello di utilità che tenga conto non solo dei fattori dell'oggetto di studio, che nel nostro caso sono le impostazioni di hover help, ma anche delle informazioni contestuali provenienti dai partecipanti. Questi due elementi, combinati insieme, possono dare un'idea delle preferenze di diverse impostazioni di hover help per diversi utenti, appartenenti a diversi gruppi demografici. In definitiva, una volta adattato questo modello di utilità, è possibile utilizzarlo per apprendere o scoprire quali design di hover help sono maggiormente preferiti per ciascun gruppo demografico.
Una componente importante della sperimentazione di scelta discreta contestuale è la progettazione di questi esperimenti. Come scegliamo le domande da presentare ai partecipanti? Se avete familiarità con la sperimentazione di scelta discreta tradizionale, spesso per ottenere una buona progettazione di un esperimento di scelta discreta è necessario disporre di informazioni preliminari sulle preferenze dell'utente.
Il modo in cui lo facciamo nella sperimentazione sulla scelta discreta contestuale è condurre innanzitutto un cosiddetto studio di screening, in cui gli utenti, partendo da un certo numero di partecipanti, otteniamo le loro informazioni contestuali o demografiche, e poi li sottoponiamo a un questionario e raccogliamo i dati sulle loro preferenze. Da questo studio di screening, adattiamo un modello per lo studio di screening che caratterizza le preferenze dell'utente. Possiamo quindi utilizzare questo modello per comprendere le preferenze tra diversi gruppi demografici.
Possiamo quindi utilizzare questo modello per creare prior bayesiani che possono essere utilizzati per creare disegni bayesiani D-ottimali per il questionario. Possiamo utilizzarlo per creare questionari mirati a ciascun gruppo demografico, in modo da ottenere maggiori informazioni statistiche in modo più efficiente da quel gruppo. Questa è la metodologia che volevamo... il modo in cui volevamo affrontare questo problema. Volevamo creare questionari statisticamente molto efficienti da somministrare ai nostri partecipanti, in modo da poter raccogliere informazioni in modo più efficiente e conoscere le preferenze tra i diversi gruppi demografici.
Parlerò brevemente della creazione di questo componente aggiuntivo. Innanzitutto, per chi non lo sapesse, JSL è l'acronimo di JMP Scripting Language. Permette agli utenti di estendere le funzionalità di JMP, consentendo loro di fare molte cose, come eseguire analisi di routine multistep o adattare un modello specifico ai dati generati quotidianamente. JSL permette davvero agli utenti di estendere le funzionalità di JMP. Un componente aggiuntivo JMP è uno script JSL che estende le funzionalità di JMP e che altri utenti JMP possono scaricare e utilizzare.
Perché abbiamo creato un componente aggiuntivo JMP per il nostro specifico problema? Innanzitutto, stavamo conducendo diversi studi di usabilità. Stavamo conducendo lo stesso studio di usabilità, quello per l'impostazione della guida in linea, in momenti diversi. Raccoglievamo sempre più dati nel tempo e li usavamo per perfezionare i progetti sperimentali o i questionari che inviavamo ai partecipanti. Stiamo anche conducendo diversi studi di usabilità, ad esempio, in cui diversi fattori dell'interfaccia utente potrebbero cambiare. Ad esempio, uno degli studi di usabilità riguardava la combinazione di colori e la posizione dei messaggi di notifica nella scheda Analizza.
Un altro motivo per cui abbiamo creato questo componente aggiuntivo era che la creazione di questi esperimenti di scelta discreta contestuale poteva essere tediosa, poiché spesso richiedeva il calcolo delle medie a priori e delle matrici di covarianza per creare i disegni bayesiani D-ottimali per ciascun gruppo. Abbiamo scoperto che questo processo poteva essere automatizzato tramite scripting JSL.
Infine, questo framework di sperimentazione della scelta discreta contestuale può essere utilizzato per un'ampia gamma di attività di scelta. Non si limita ai soli studi di usabilità, ma a qualsiasi tipo di studio in cui sia necessario che gli utenti esprimano le proprie preferenze tra più opzioni. Volevamo creare questo componente aggiuntivo non solo per aiutarci, ma anche per consentire ad altri di utilizzarlo per risolvere i propri problemi.
Parlerò brevemente del flusso di lavoro del nostro componente aggiuntivo per la scelta discreta contestuale. Innanzitutto, ciò che l'utente o lo sperimentatore deve fare è raccogliere dati da uno studio di screening, che dovrebbe includere informazioni come: quali domande sono state poste ai partecipanti? Quali erano gli attributi? Gli attributi del profilo? I fattori dell'oggetto dello studio, così come le covariate del soggetto.
Una volta ottenuti questi dati, si adatta un modello di screening ai dati. Nel modello di screening, lo sperimentatore deve specificare sia gli effetti del profilo. Nel nostro caso, si trattava delle impostazioni di aiuto al passaggio del mouse, sia degli effetti del soggetto. Questo consente allo sperimentatore di creare un modello di utilità. Questo modello di utilità viene quindi stimato utilizzando la piattaforma di analisi delle scelte di JMP.
Una volta fatto ciò, l'utente seleziona un gruppo demografico per ulteriori studi. Per farlo, seleziona i livelli di ciascuno di questi effetti soggettivi o fattori contestuali. Una combinazione di questi livelli specifica un gruppo per ulteriori studi. Una volta selezionato il gruppo, viene costruito un disegno bayesiano D-ottimale o un questionario bayesiano D-ottimale per quel gruppo, in modo che lo sperimentatore possa studiarlo ulteriormente in modo statisticamente efficiente.
Ora farò una dimostrazione del componente aggiuntivo per l'esperimento di scelta discreta contestuale. Andrò qui, aprirò JMP e andrò ai miei componenti aggiuntivi. Seleziono la tabella dati. Questa tabella dati contiene informazioni... Vi mostrerò rapidamente come appare. Questa tabella dati contiene informazioni su precedenti studi di usabilità condotti per la guida in linea. Potete vedere che abbiamo informazioni come: quale opzione ha scelto l'utente? Quali opzioni sono state presentate? Abbiamo alcune informazioni contestuali sull'utente, come il suo livello di esperienza nella progettazione di esperimenti, nonché il motivo per cui utilizza Easy DOE. È per uso personale o per insegnare ad altri?
All'interno di questo... vado qui e lo apro. Innanzitutto inseriamo l'indicatore di risposta, che rappresenta la scelta effettuata dall'utente, e impostiamo anche l'ID del set di scelte e gli ID dell'oggetto. Poi possiamo procedere e inserire gli effetti del profilo, che nelle nostre impostazioni erano quei tre messaggi nella posizione della guida al passaggio del mouse. Se volessimo, potremmo aggiungere effetti di interazione, se volessimo. Ma per ora lo manterrò come modello di effetti principali. Inoltre, possiamo aggiungere effetti dell'oggetto come il livello di esperienza e se gli utenti insegnano ad altri o utilizzano Easy DOE per uso personale.
Come potete vedere, molte delle informazioni qui sembrano identiche alla configurazione della Piattaforma di Analisi delle Scelte. Quando clicchiamo su "Esegui", in background viene visualizzata la Piattaforma di Analisi delle Scelte, che analizza il modello di screening per lo studio di screening. Naturalmente, possiamo interagire con questa piattaforma proprio come faremmo con la Piattaforma di Analisi delle Scelte. Ad esempio, possiamo visualizzare un profiler di utilità e, ad esempio, vedere che gli utenti esperti, che insegnano ad altri, preferiscono una determinata opzione per il messaggio sull'ereditarietà, che è la seconda alternativa.
Una volta analizzato questo aspetto, possiamo richiamare questo componente che ci chiede di selezionare un gruppo demografico per ulteriori studi. Supponiamo che io stia conducendo questi studi e voglia studiare gli utenti esperti di Easy DOE, ovvero coloro che hanno esperienza nella progettazione di esperimenti e che sono interessato a vedere quando insegnano ad altri. Voglio creare un questionario per conoscere le preferenze degli utenti esperti che insegnano ad altri. Clicco su "Crea progetto" e questo richiama la piattaforma "Choice Design" in modo tale che le informazioni che abbiamo già inserito nella fase "Choice Analysis" o "Screening Study" vengano automaticamente inserite nella piattaforma "Choice Design".
Abbiamo i nostri attributi, abbiamo il nostro modello per questo particolare gruppo, che era un modello a effetti principali che avevamo specificato. La cosa più importante qui è che, utilizzando il modello dello studio di screening, quel modello di screening, siamo stati in grado di calcolare le variabili a priori bayesiane per la media a priori e la varianza a priori per il particolare gruppo che eravamo interessati a studiare.
Una volta creato questo modello, possiamo creare un cosiddetto Design Bayesiano D-Ottimale cliccando su "Crea Design". Otterremo un design personalizzato per il gruppo specifico che stiamo studiando. La costruzione di questo design ha preso in considerazione le informazioni precedenti che avevamo sulle preferenze di questo gruppo. Ora questo design è personalizzato per il gruppo che vogliamo studiare ulteriormente. Questa è la mia dimostrazione del componente aggiuntivo per la sperimentazione della scelta discreta contestuale. Chiuderò alcune di queste diapositive e tornerò alle nostre slide.
Proseguendo, l'ultima cosa di cui parlerò ora è il test del componente aggiuntivo tramite il framework di test unitari JSL. Cos'è il test unitario, innanzitutto, per chi non lo sapesse? Il test unitario consiste nel testare i singoli componenti di un'applicazione software per identificare gli errori. In particolare, il test unitario automatizzato consente di eseguire frequentemente test unitari su un'applicazione software per identificare e correggere errori di nuova introduzione durante il processo di sviluppo.
In particolare, JMP dispone di un framework di unit testing chiamato framework di unit testing JSL, progettato appositamente per le applicazioni JSL. La funzione più importante all'interno di questo framework è la funzione ut assert, che consente agli utenti di testare determinati componenti dell'applicazione JSL. L'utente ottiene quello che ritiene essere l'output corretto, che dovrebbe essere l'output corretto, ovvero il cosiddetto valore atteso. Lo testa confrontandolo con l'output reale della propria applicazione. Se i valori corrispondono, significa che il caso di test è stato superato, mentre se non corrispondono, significa che il caso di test è fallito. Quando l'utente scrive uno script con queste funzioni ut assert e lo esegue, viene restituito un report che informa l'utente se tutti i casi di test sono stati superati o quali sono falliti, in modo che possano essere ulteriormente analizzati.
Abbiamo testato diverse funzionalità all'interno del componente aggiuntivo per la sperimentazione della scelta discreta contestuale. Ad esempio, una delle funzionalità che abbiamo testato è stato il pulsante con la croce per aggiungere effetti di interazione. Funzionava correttamente? Avevamo l'idea che, se scegliamo due opzioni specifiche e premiamo il pulsante con la croce, sappiamo come dovrebbe apparire, e quindi possiamo testarlo rispetto all'output effettivo per assicurarci che il sistema funzioni correttamente.
Un altro aspetto importante che abbiamo testato è che, quando si seleziona un gruppo demografico per un ulteriore studio, vogliamo assicurarci che venga visualizzato un messaggio se lo sperimentatore lascia vuota una delle opzioni. Abbiamo effettuato dei test e ci siamo assicurati che questo messaggio di errore comparisse come richiesto.
Infine, questo è un aspetto importante. Volevamo assicurarci che le informazioni precedenti che stavamo caricando nel Choice Designer fossero corrette. Lo abbiamo testato. Lo abbiamo confrontato con l'output della piattaforma Choice Analysis. Se i due dati corrispondevano, sapevamo di aver inserito correttamente le informazioni precedenti nel Choice Designer, mentre se c'era una discrepanza, sapevamo che qualcosa non andava. Fortunatamente, abbiamo scoperto che stavamo caricando correttamente le informazioni precedenti corrette.
Ora, uno degli aspetti più importanti di questo test unitario automatizzato è quando si procede al refactoring del codice. Il test unitario automatizzato consente di refactoring del codice e di verificare se sono stati introdotti errori. Per refactoring del codice, intendo apportare modifiche al codice durante il processo di sviluppo. Se si apporta una modifica al codice, come si fa a sapere se si è verificato un errore in qualcosa di diverso da ciò che si stava modificando?
Un esempio concreto che abbiamo trovato è che uno degli utenti di prova di questo componente aggiuntivo ha scoperto che quando uno dei fattori contestuali aveva un'etichetta di valore, l'elenco per quel fattore contestuale non veniva visualizzato correttamente. In realtà, non veniva visualizzato affatto.
Siamo tornati indietro e abbiamo corretto quell'errore. Ma volevamo assicurarci che, correggendolo nel modo in cui lo abbiamo fatto, non danneggiassimo qualcos'altro. Era possibile farlo. Lo abbiamo verificato rieseguendo il nostro script di unit test. Fortunatamente, dopo averlo eseguito, abbiamo visto che non erano stati introdotti nuovi errori, il che ci ha aiutato a garantire che non danneggiassimo altro. La nostra correzione proposta per quel problema con l'etichetta del valore ha risolto correttamente il problema, come potete vedere sul lato destro di questa immagine.
Questo test unitario è importante perché, in primo luogo, può farti sapere se ci sono errori nel tuo codice. In secondo luogo, ti permette di riorganizzare il codice e assicurarti di non aver introdotto altri errori. In terzo luogo, con gli aggiornamenti di JMP, alcune funzionalità interne di JMP cambieranno, e alcune piattaforme potrebbero cambiare. Se disponi di questo script di test unitario, puoi sempre testare il tuo componente aggiuntivo quando JMP viene aggiornato per assicurarti che qualcosa che è cambiato in JMP non abbia influenzato o abbia influenzato il tuo componente aggiuntivo.
A conclusione della presentazione odierna, ho introdotto il problema della progettazione di esperimenti di scelta discreta contestuale per aiutare a comprendere le preferenze dell'interfaccia utente per Easy DOE in diversi gruppi demografici della nostra base utenti. Ho poi dimostrato come lo scripting JSL possa consentirci di creare un componente aggiuntivo JMP molto pratico da usare per la costruzione di questi esperimenti di scelta discreta. Infine, ho discusso l'importanza di... una volta che, durante o dopo il processo di creazione del componente aggiuntivo, sarà opportuno eseguire alcuni test unitari per individuare eventuali errori durante e dopo il processo di sviluppo.
Con questo si conclude il mio intervento di oggi. Ci sono domande?
