Naviga tra le sottosezioni
Per i software la cui qualità è decaduta tanto da rendere i costi di manutenzione diseconomici e/o la qualità avvertita dall’utilizzatore insoddisfacente, si ritiene opportuno modernizzare il software. Per modernizzare il software si intende far rimanere immutati il comportamento e le funzioni del software ma rifare la struttura del sistema e/o modificare l’interfaccia utente e/o modificare le tecnologie utilizzate nella sua implementazione, seguendo i modelli di processo adeguati agli obiettivi della stessa modernizzazione.
Trascuriamo qui la progettazione della modernizzazione ovvero il percorso di modernizzazione che è stato deciso ed eseguito in ognuno dei casi di studio che è stata specifica per ogni software e dipendente dalle condizioni di qualità e dal ruolo che ha negli obiettivi industriali di questo stesso. Invece verifichiamo che il software modernizzato migliori la usabilità, la esperienza dell’utilizzatore, la evolvibilità e la qualità.
Per questa indagine sono stati utilizzati 3 casi di studio su altrettanti sistemi software in esercizio di Auriga.
Prima di passare alla rilevazione dei dati sperimentali è opportuno descrivere come si è inteso valutare la Usabilità e la User Experience.
MISURA DELLA USABILITÀ
La usabilità è misurata attraverso indagini qualitative fatte con un insieme di utenti campioni. Si è utilizzato il System Usability Scale. Per completezza, il questionario utilizzato è riportato in figura 5.1.a.
Le risposte dei partecipanti sono trasformati in punteggi:
- Il punteggio per i quesiti dispari (positivi) = numero segnato dal partecipante -1
- Il punteggio per i quesiti pari (negativi) = 5-numero segnato dal partecipante.
- La somma dei punteggi assegnati da ogni quesito dallo stesso utilizzatore sarà nell’intervallo 0-40; questo moltiplicato per 2,5 si trasforma in un numero da 0-100 che individua la posizione in percentile.
- Dalla esperienza di letteratura il punteggio così ricavato può far classificare il software valutato in una delle classi previste in Figura 5.1.b.
Figura 5.1.a. Questionario SUS
Figura 5.1.b. Classi di punteggio SUS
MISURA DELLA USER EXPERIENCE
La UX è misurata attraverso indagini qualitative fatte con un insieme di utenti campioni. Si è utilizzato lo User Experience Questionnaire (UEQ). Per completezza, il questionario utilizzato è riportato in figura 5.2.a. nella figura citata i quesiti sono espressi in lingua inglese; ma, i questionari distribuiti in Auriga hanno i quesiti in italiano o in inglese dipendentemente dalla lingua utilizzata dal partecipante che deve rispondere, rispettivamente italiana o altra lingua diversa dall’italiano.
I quesiti elencati sono casualmente impostati in crescente negatività o positività. Questo per stimolare il partecipante al sondaggio a rispondere riflettendo sul quesito.
I quesiti a loro volta sono raggruppati per aspetti di interesse della UX. La classificazione è riportata in figura 5.2.b. Anche in questo caso la figura riporta gli aspetti in inglese ma i risultati esposti nel resto di questa sezione sono tutti espressi in italiano.
I sette gradi di ogni quesito sono tradotti in punteggi che vanno da “-3” (estremamente negativo a “+3” (estremamente positivo) lo “0” è neutro. La valutazione è basata sulle medie dei punteggi, purché si sia utilizzato un campione sufficientemente numeroso.
Se si deve valutare la UX di un software non avendo un sistema di controllo si usano le soglie riportate dall’esperienza presente in letteratura e mostrate nelle figure 5.2.c e 5.2.d
Se invece si devono confrontare due prodotti diversi: uno sperimentale e l’altro di controllo è necessario confrontare le rispettive medie per ogni aspetto.
Figura 5.2.a UEQ in inglese
Figura 5.2.b. Classificazione dei quesiti per aspetti
Figura 5.2.c. Soglie per la valutazione di un Business Software (Ricavati da 158 prodotti sperimentali)
Figura 5.2.d. Soglie per la valutazione di Web Sites e WEB Services (Ricavati da 85 prodotti sperimentali)
Modernizzazione Nuova Console
Il primo caso di studio ha come oggetto la componente console di WWS. Questa ha bisogno di migliorare la usabilità, la user experience e la modificabilità.
Q5.1 - Quanto si è guadagnato in qualità?
La qualità è valutata con gli indicatori di KIUWAN: Manutenibilità, Affidabilità, Portabilità, Efficienza e Sicurezza.
La versione in esercizio è utilizzata come oggetto sperimentale di controllo, la versione modernizzata è l’oggetto sperimentale.
La versione in esercizio di questo sottosistema presenta gli indicatori di qualità mostrati in figura 5.3. Gli stessi indicatori per le successive versioni della Nuova Console sono mostrati nella figura 5.4.
Figura 5.3. Indicatori di qualità della Console in esercizio
Figura 5.4. indicatori di qualità delle successive versioni della Nuova Console
In questo caso la qualità del software non cambia molto con la modernizzazione perché era già di livello alto nel sistema in esercizio.
Q5.2 - Qual è il livello di usabilità raggiunto?
La versione in esercizio è l’oggetto di controllo, la nuova versione è l’oggetto sperimentale. Per entrambi sono impegnati 5 utenti a cui viene sottoposto il questionario SUS.
Il risultato del sondaggio per la versione in esercizio, il è riportato nelle figure 5.5.a, 5.5.b.
Figura 5.5.a. Risposte SUS dei Partecipanti- Versione in esercizio
Figura 5.5.b. Punteggio SUS per partecipante- Versione in esercizio
Punteggio SUS= 53,5
Per la nuova versione I risultati rilevati dal primo sondaggio sono riportati in figura 5.6.a,5.6.b.
Facendo riferimento alla figura 5.1.b il punteggio SUS della versione in esercizio è insufficiente.
Figura 5.6.a. Risposte SUS dei Partecipanti - Nuova versione (I rilascio)
Figura 5.6.b. Punteggio SUS dei Partecipanti - Nuova versione (I rilascio)
Punteggio SUS= 63
Il SUS delle Nuova versione risulta migliore di quello della versione in esercizio ma è anch’esso nella fascia insufficiente, con riferimento alla figura 5.1.b.
Per migliorare il coefficiente di usabilità complessivo, sono state apportate delle modifiche al prodotto, suggerite dalle evidenze di feedback e dai test eseguiti. Sono state analizzate insieme le evidenze dai sondaggi dell’usabilità e della UX, descritta più avanti. Le modifiche eseguite che sono servite per entrambe le caratteristiche sono state:
In particolare:
- è stata revisionata la parte dei colori delle interfacce
- introdotto uno stile di default di tutte le videate
- utilizzo di parti standard ripetute nelle videate della stessa tipologia (filtri, ordinamenti, bottoni nelle stesse posizioni)
- migliorie nelle schermate dashboard
Nelle figure 5.7.a,5.7.b sono riportati i risultati del successivo sondaggio da cui si ricava che il SUS complessivo è migliorato notevolmente e si è portato in campo Buono, con riferimento sempre alla tavola 5.1
Figura 5.7.a. Risposte SUS dei Partecipanti - Nuova versione (Ii rilascio)
Figura 5.7.b. Punteggio SUS per partecipante - Nuova versione (II rilascio)
Media Punteggio SUS= 70,5
La nuova console ha realizzato un notevole miglioramento nella usabilità; questa potrà essere migliorata ulteriormente in meglio, a costi relativamente contenuti.
Q5.3 - Quanto si è guadagnato in UX?
Nella vecchia versione la UX è lampantemente negativa perché i rilievi degli utilizzatori sono stati una delle motivazioni più rilevanti nella decisione di modernizzazione di questo sistema. Altresì, quando è stata prodotta i concetti di User Experience non erano, di certo, considerati a livello industriale. Pertanto per questo quesito si è inteso analizzare i risultati raggiunti con la nuova versione.
Per l’indagine sono stati utilizzati due rilasci che sono stati sottoposti a 5 utilizzatori che hanno risposto al questionario UEQ.
I risultati rilevati sono riportati nelle figure 5.8.a, 5.8.b..
Figura 5.8.a Dati grezzi rilevati dal sondaggio ( I rilascio)
Figura 5.8. b Trasformazione in punteggi dei dati rilevati (I rilascio)
In figura 5.8.c mostra la media raggiunta per ogni persona in ognuno degli aspetti componenti la UX. Da questa si evince che tra i soggetti sperimentali non ci sono persone particolarmente severe o particolarmente tolleranti. Se ci fossero bisognerebbe trattarli come outlier e fare le analisi necessarie senza le loro risposte.
Figura 5.8.c. Media per ogni partecipante (I rilascio)
La figura 5.8.d mostra il grafico del punteggio complessivo di ogni componente e lo confronta con le esperienze di letteratura. Di qui si evince che molti aspetti sono tra il campo ”bad” e il campo “sotto la media”.
In conclusione la UX deve essere migliorata.
Figura 5.8.d. Benchmark della UX con la letteratura (I rilascio)
Per decidere le iniziative di miglioramento che sono opportune intraprendere, la figura 5.8.e consente di valutare l’influenza di ogni quesito sul risultato finale.
Figura 5.8.e. Risultati per ognuno dei quesiti. (I rilascio)
Dopo aver apportato le modifiche di cui si è detto prima è stato fatto un secondo sondaggio che ha dato i risultati riportati nelle figure 5.9
Figura 5.9.a Dati grezzi rilevati dal sondaggio (II rilascio)
Figura 5.9.b Trasformazione in punteggi dei dati rilevati (Ii rilascio)
5.9.c Benchmark della UX con la letteratura (II rilascio)
5.9.d Benchmark della UX con la letteratura (II rilascio)
Q5.4. - Quanto si guadagna in impegno-persona nelle modifiche?
La economicità di realizzazione dei cambiamenti si è sperimentata con progetti in cui il sistema è modificato. L’indicatore rilevato sarà il tempo-persona necessario per la implementazione. Il confronto può essere fatto con l’esperienza dei manager di Auriga. Le misure rilevate sono:
Tprec =Tempo-persona previsto per la modifica sulla versione precedente.
Treale =Tempo-persona realmente speso sulla versione attuale.
G= Guadagno = (Tprec – Treale)/Treale *100.
In figura 5.10 sono riportati i dati rilevati da tre casi di studio.
Figura 5.10. Rilevazioni e calcolo del Guadagno dopo la modernizzazione
L’affinamento della progettazione per favorire il riuso interno delle componenti e la modificabilità del software inizialmente richiede più impegno-persona che però si recupera ampiamente con la realizzazione incrementale del prodotto e con le sue modifiche.
Modernizzazione Versamenti
L’architettura di Versamenti legacy aveva molte parti sviluppate attraverso un linguaggio proprietario che adotta file di tipo XML. L’utilizzo di questo linguaggio non permette il debug, il test e il controllo statico del codice, ovvero costituisce delle barriere al miglioramento della qualità del prodotto pertanto un obiettivo della modernizzazione è la riduzione delle parti scritte in XML che come si dirà di seguito.
Allo stadio attuale di modernizzazione il prototipo di Versamenti continua ad avere alcune parti in XML ma queste sono in misura notevolmente ridotta. La figura 5.11 mette a confronto l’utilizzo dei file XML nelle due versioni, legacy e moderna. Altresì la figura 5.12 mostra come l’utilizzo dei file XML si sia drasticamente ridotto nell’ultima versione del software.
Figura 5.11. Confronto di contenuti XML nelle due versioni di Versamenti
Figura 5. 12. Confronto di file XML nelle due versioni di Versamenti
Infine, è interessante osservare come nella versione moderna si sia potuto raccogliere un patrimonio di casi di test eseguibili automaticamente, che ammontano a 684 (figura 5.13).
Grazie ai casi di test automatizzati è stata raggiunta una copertura del codice del 70% circa (figura 5.14).
Figura 5.13. Patrimonio di casi di test nelle due versioni di Versamenti
Figura 5.14. Confronto della copertura del codice in entrambe le versioni di Versamenti
Tutto ciò premesso si è indagato su quanto si è guadagnato in qualità e nella evolvibilità. In questo caso la usabilità e la UX non sono caratteristiche di interesse perché questa è una componente di servizio ad altre componenti software; quindi gli utilizzatori non la vedono.
Q5.5 - Quanto si è guadagnato in qualità?
In figura 5.15.a vengono mostrati i dati relativi al controllo statico del codice effettuato attraverso KIUWAN sulle due versioni del codice.
Figura 5.15.a. Confronto della qualità delle due versioni di Versamentisecondo KIUWAN
Figura 5.15.b. Grafico del Confronto della qualità delle due versioni di Versamenti secondo KIUWAN
In figura 5.15.b sono mostrati i 6 indicatori usati da KIUWAN per misurare la qualità globale del progetto, con grafico radar.
Apparentemente dalle figure 5.14 sembrerebbe che le due versioni sono molto simili secondo la valutazione di KIUWAN ma ciò non è vero perché nella versione legacy sono valutate solo le parti di codice che non usano file XML che come si è detto prima sono la gran parte del codice.
La qualità di Versamenti ha guadagnato molto sia nel suo valore istantaneo sia nella gestibilità che consentirà di non fare decadere la stessa qualità con l’evoluzione del software.
Q5.8. - Quanto si guadagna in impegno-persona nelle modifiche?
La economicità di realizzazione dei cambiamenti si è sperimentata con progetti campioni di cambiamenti. Le misure rilevate saranno confrontate con l’esperienza dei manager di AURIGA. Le misure rilevate sono
Tprec =Tempo-persona previsto per la modifica sulla versione precedente.
Treale =Tempo-persona realmente speso sulla versione attuale.
G= Guadagno = (Tprec – Treale)/Treale *100.
I risultati sono riportati in figura 5.16.
Figura 5.16. Rilevazioni e calcolo del Guadagno dopo la modernizzazione di Versamenti
La evolvibilità della procedura è migliorata notevolmente con una considerevole economia nella realizzazione dei cambiamenti.
Modernizzazione SDK
Lo SDK è un sistema che consente di produrre automaticamente il codice necessario per la erogazione di nuovi servizi coordinando algoritmi esistenti.
Lo SDK legacy, prodotto anche di recente, ha avuto rilevanti problemi nella usabilità e nella evolvibilità pertanto si è dovuto modernizzare questa applicazione utilizzando tecnologie più performanti e un’architettura più conforme ai moderni principi di ingegneria del software, soprattutto dal punto di vista della evolvibilità. Per verificare il raggiungimento degli obiettivi si è indagato sui due aspetti critici detti attraverso i seguenti quesiti.
Q5.9 - Quanto si è guadagnato in usabilità rispetto alla precedente versione?
La usabilità è stata misurata con il questionario SUS.
Sono stati paragonati i punteggi ricavati con lo SDK Legacy con quelli dello SDK modernizzato su tre rilasci sequenziali.
In entrambi i casi gli utilizzatori sono partiti senza nessuna conoscenza dello SDK, quindi hanno eseguito tutte le operazioni che sono state loro assegnate subito dopo aver ricevuto l’addestramento. Per lo SDK Legacy l’addestramento è durato un mese, per lo SDK modernizzato l’addestramento è durato 2 hh.
Per lo SDK legacy furono utilizzati 4 soggetti sperimentali. I risultati sono riportati nelle figure 5.17.
Figura 5.17.a. Risposte SUS dei Partecipanti per SDK Legacy
Figura 5.17.b. Punteggio SUS dei Partecipanti per SDK Legacy
Media Punteggio SUS= 24,37
Furono fatti tentativi per il miglioramento dell’usabilità ma non hanno dato risultati apprezzabili. A conferma della scarsa usabilità dello SDK, risulto molto farraginoso l’utilizzazione senza dare apprezzabili risultati di produttività. Pertanto si decise di modernizzare il portale come è stato detto prima.
Con lo SDK modernizzato è stato fatto un primo sondaggio con 12 soggetti sperimentali. I risultati sono riportati nelle figure 5.18.
Figura 5.18.a. Risposte SUS dei Partecipanti per SDK Modernizzato, I Gruppo
Figura 5.18.b. Punteggio SUS dei Partecipanti per SDK Modernizzato, I Gruppo
Media Punteggio SUS= 72,5
Sono state apportate le modifiche descritte con il quesito Q5.10 che sono state suggerite essenzialmente dai sondaggi per la rilevazione della UX.
Figura 5.19.a. Risposte SUS dei Partecipanti per SDK Modernizzato, II Gruppo
Figura 5.19.a. Risposte SUS dei Partecipanti per SDK Modernizzato, II Gruppo
Media Punteggio SUS= 74,37
Figura 5.20.a. Risposte SUS dei Partecipanti per SDK Modernizzato, III Gruppo
Figura 5.20.b. Risposte SUS dei Partecipanti per SDK Modernizzato, III Gruppo
Media Punteggio SUS= 76,25
Facendo riferimento alla figura 5.1.b, lo SDK legacy ha fatto rilevare il livello di usabilità “scarso” mentre i tre rilasci dello SDK modernizzato hanno fatto rilevare il livello di usabilità migliorata al primo rilascio in pieno campo “buona”. Pertanto la modernizzazione ha migliorato il livello di usabilità che aveva il corrispondente tool legacy ed ha anche dato la possibilità di migliorare la sua usabilità.
Q5.10 - Quanto si è guadagnato in UX rispetto alla precedente versione?
Nella vecchia versione la UX è negativa nella esperienza degli sviluppatori di Auriga che la hanno sviluppata ed utilizzata come strumento di sviluppo. Purtroppo quando era attiva non è stato mai misurato in alcun modo un livello quantitativo di UX (come invece era stato fatto con la usabilità); altresì attualmente non è stato possibile far funzionare la vecchia versione, per cui non si è potuto misurare tale livello quantitativo. Pertanto, si è inteso analizzare i risultati raggiunti con la nuova versione.
L’indagine in questo caso è consistita in un sondaggio con gli stessi 26 soggetti sperimentali coinvolti nella misurazione della usabilità.
I risultati rilevati sono riportati da figura 5.21.a a figura 5.21.d per un rilascio (da SPRINT 3).
Figura 5.21.a Dati grezzi rilevati dal sondaggio
Figura 5.21. b. Trasformazione in punteggi dei dati rilevati
In figura 5.21.c mostra la media raggiunta per ogni persona in ognuno degli aspetti componenti la UX. Da questa si evince che tra i soggetti sperimentali non ci sono persone particolarmente severe o particolarmente tolleranti. Se ci fossero bisognerebbe trattarli come outlier e fare le analisi necessarie senza le loro risposte.
Figura 5.21.c. Media e varianza per ogni partecipante
La figura 5.24.d. mostra il grafico del punteggio complessivo di ogni componente e lo confronta con le esperienze di letteratura (cfr. 5.2c). Di qui si evince che: tutte le componenti sono “sopra il valore “media” ed il valore “buona”.
Figura 5.21.d. Benchmark della UX con la letteratura
Per decidere le iniziative di miglioramento che sono opportune intraprendere, la figura 5.21.e consente di valutare l’influenza di ogni quesito sul risultato finale.
Figura 5.21. Risultati per ognuno dei quesiti nella valutazione di UX
Sono state fatte alcune iniziative di miglioramento: migliorate le icone per esprimere le scelte che il sistema propone agli utilizzatori così che il sistema risulti meno noioso; per le funzioni più frequentemente usate sono stati diminuiti il numero di scelte necessarie per accedervi così che gli utilizzatori avvertano una maggiore apprendibilità del sistema e quindi si è passato a nuove misure; è stata fatta qualche modifica strutturale per rendere il sistema più efficiente.
Da figura 5.22.a 5.22.c sono riportati i risultati essenziali del sondaggio effettuato avendo come oggetto sperimentale il rilascio successivo (da SPRINT 4).
La figura 5.22.c mostra che le modifiche effettuate hanno portato ad un miglioramento significativo della UX. Questo è di particolare interesse per Auriga perché questo tool deve essere molto utilizzato dagli sviluppatori per accelerare ed economizzare la produzione delle future modifiche di WWS.
Figura 5.22.a Dati grezzi rilevati dal sondaggio
Figura 5.22. b Trasformazione in punteggi dei dati rilevati
Figura 5.22.c. Confronto grafico con le soglie da letteratura per lo sprint 9
Q5.11. - Quanto si guadagna in impegno-persona nella produzione di nuove file “.AUR” rispetto alla precedente versione?
La economicità di realizzazione delle interfacce è stata sperimentata con 7 casi di studio reale.
I dati rilevati
Tprev = tempo-persona previsto per la produzione della stessa funzione senza l’ausilio di SDK. È valutato sulla base dell’eesperienza degli sviluppatori ed è ricavato dal confronto del parere di software engineering e programmatori che hanno profonda conoscenza del dominio applicativo.
Tprec =Tempo-persona previsto per la modifica sulla versione precedente.
Treale =Tempo-persona realmente speso sulla versione attuale.
GS= Guadagno sullo sviluppo senza l’attuale SDK = (Tprev – Treale)/Tprev *100.
GM = guadagno con la modernizzazione, guadagno del nuovo SDK rispetto al vecchio = (Tprec-Treale)/Tprec *100
I risultati della sperimentazione sono riportati in figura 5.23.
Figura 5.23. Guadagno nello sviluppo prodotto dallo SDK modernizzato
In tutte le prove l’attuale SDK guadagna rispetto allo sviluppo senza il suo supporto, tranne che per il giroconto. La perdita in giroconto è causata dalla circostanza che questa funzione è molto simile a quella di bonifico quindi uno sviluppatore avrebbe usato il riuso del codice, mentre lo sdk prevede sempre la produzione del codice dalle specifiche dello stesso e non dalla copia di un codice già in essere. Questo comportamento dello SDK ha il vantaggio che la modifica di una funzione già in esercizio richieda solo la modifica delle sue caratteristiche senza che lo sviluppatore entri nel codice. Questo come è noto dall’esperienza empirica della Ingegneria del Software garantisce che la qualità del software non degradi e mantenga sempre, in questo caso, la qualità del software prodotto da SDK.
Il guadagno che si ha nella produzione del software con il supporto dello SDK è notevole. Inoltre è notevole anche il guadagno rispetto allo SDK legacy; quindi la modernizzazione ha prodotto notevoli miglioramenti in usabilità, esperienza dell’utente ed evolvibilità.