Concetto: Usability Engineering
Questa guida esamina il concetto di Usability Engineering. Usability Engineering, anche detta progettazione incentrata sull'utente, ha lo scopo di migliorare i sistemi promuovendo una migliore comprensione dell'utente finale, coinvolgendo gli stessi nella determinazione dei requisiti, nella progettazione dell'interfaccia utente e nelle fasi di verifica.
Descrizione principale
Concetti: 

Introduzione

Usability Engineering, anche nota come progettazione incentrata sull'utente, ha lo scopo di migliorare i sistemi promuovendo una migliore comprensione dell'utente, coinvolgendo gli stessi nella determinazione dei requisiti, nella progettazione dell'interfaccia utente e nelle fasi di verifica. I concetti base sono descritti in Concetto: Progettazione incentrata sull'utente, di cui se ne consiglia la lettura prima di proseguire. Questa pagina spiega come Rational Unified Process (RUP) attualmente gestisce le tecniche di usability engineering.

Ruoli

RUP offre una serie di ruoli responsabili delle considerazioni di utilizzabilità. L'Analista di sistema e il Specificatore di requisiti devono avere la capacità di raccogliere ed analizzare informazioni su utenti, relativi compiti ed ambienti, e catturarli nei requisiti. Questa documentazione deve essere esaminata dal Revisore requisiti. I ruoli Tester e Analista test sono i principali responsabili dei test di utilizzabilità. Il Progettista interfaccia utente è responsabile della progettazione e del "modellamento visiva" dell'interfaccia utente. L'Implementatore seleziona e/o sviluppa i componenti dell'interfaccia utente per costruire la versione funzionante della stessa.

Il Responsabile progetto svolge anch'esso un ruolo chiave, in quanto consente il coinvolgimento dell'utente nel processo di sviluppo e garantisce che il personale addetto all'organizzazione dello sviluppo sia dotato degli skill per costruire sistemi utilizzabili. Altri ruoli, quali Responsabile della distribuzione, Sviluppatore corsi e Redattore tecnico hanno anch'essi la responsabilità di assicurare che il sistema distribuito sia utilizzabile.

Discipline

Le sezioni successive esaminano le discipline di RUP in termini di attività ed artefatti, che assumono grande rilievo in termini di utilizzabilità.

Requisiti

La disciplina Requisiti, dal punto di vista dell'utilizzabilità, concentra l'attenzione su:

  • comprensione degli utenti e determinazione delle loro esigenze
  • identificazione dei casi d'uso che producono un vantaggio maggiore per gli utenti.

Le attività e gli artefatti specifici sono:

Attività Artefatti Contenuto correlato all'utilizzabilità
Deduzione delle richieste degli stakeholder Richieste degli stakeholder

L'attività prevede intervistare gli utente, distribuire questionari e organizzare workshop per comprendere meglio l'utente e il suo ambiente operativo. Tra questi:

La maschera per Artefatti: le richieste degli stakeholder catturano un profilo dettagliato dell'utente, compreso il background formativo, background informatico, l'esperienza, le aspettative, gli obiettivi, ecc. Cattura inoltre una descrizione dei problemi e delle priorità dal punto di vista dell'utente. Le Richieste degli stakeholder rappresentano la materia prima da cui viene compilata la Visione.

Sviluppo della visione Visione

La sezione Ambiente utente della maschera Visione descrive l'ambiente di lavoro dell'utente oppure ciò che ISO definisce come "contesto ambientale" [ISO 13407].

La sezione Profilo utente della maschera Visione descrive la professionalità, il background tecnico, le responsabilità, i criteri di successo, i componenti distribuibili, ecc. Ciò che ISO definisce come "contesto dell'utente" [ISO 13407].

Individuazione degli attori e dei casi d'uso, Strutturazione del Modello del caso d'uso, Descrizione dettagliata di un caso d'uso Modello del caso d'uso

Il Modello del caso d'uso descrive i compiti (casi d'uso) che gli utenti (attore - individui) eseguono. Cattura similarità e relazioni tra attori utilizzando relazioni di generalizzazione. Simile al "Modello del ruolo" proposto da Constantine [CON99]. I casi d'uso sono strutturati e correlati tra loro e agli attori mediante relazioni di Associazione comunicativa, inclusione, generalizzazione ed estensione.

I workshop rappresentano un ottimo metodo per coinvolgere l'utente. Vedere: Workshop sul caso d'uso

 

Actor

Le caratteristiche degli attori-individui sono catturate come attribuiti degli Attori. Tra questi:

  • L'ambito della responsabilità dell'attore.
  • L'ambiente fisico in cui l'attore che utilizzerà il sistema.
  • Il numero di utenti rappresentati dall'attore.
  • La frequenza con cui l'attore utilizzerà il sistema.
  • Il livello di conoscenza del dominio posseduta dall'attore.
  • Il livello generale di esperienza informatica dell'attore.
  • Caratteristiche generali degli attori, quali il livello professionale (formazione), implicazioni sociali (linguaggio) ed età.
 

Casi d'uso

Tra i casi d'uso, vi sono quelli cosiddetti essenziali, descritti da Constantine [CON99] (per una disamina dei casi d'uso essenziali, vedere Concetto: Progettazione incentrata sull'utente ). I requisiti specifici di utilizzabilità per un dato caso d'uso possono essere catturati come "Requisiti speciali" delle specifiche per il caso d'uso stesso.
Descrizione dettagliata dei requisiti software

Specifiche supplementari

Le Specifiche supplementari catturano i requisiti non specificate nei casi d'uso. Tra queste si segnalano requisiti di disponibilità e prestazioni che possono essere strettamente correlate all'utilizzabilità. Requisiti generali di utilizzabilità applicabili a più casi d'uso possono essere catturati in questa fase, insieme alla legislazione vigente e agli standard di utilizzabilità, i cui dettagli sono disponibili in Concetto: Progettazione incentrata sull'utente.
Gestione delle dipendenze Attributi dei requisiti Ogni volta che viene "individuato" un caso d'uso e un requisito di utilizzabilità, è necessario annotarne l'importanza o il vantaggio, da determinarsi consultando gli utenti e gli altri stakeholder. In questo artefatto è possibile catturare altri attributi, quali quali la frequenza di un caso d'uso.
Requisiti dell'analisi Richiesta di modifica L'impegno per uno sviluppo incentrato sull'utente coinvolge gli utenti il più possibile in tutte le fasi di analisi dei requisiti.
Cattura di un vocabolario comune Glossario Cattura i termini del vocabolario comune specifico del dominio dell'utente per facilitare la comprensione tra utenti e il resto del team di sviluppo.

È possibile ricorrere anche ad altre tecniche, utili per le attività per la determinazione dei requisiti succitate.

  • La schematizzazione in diagrammi di affinità [HOL96, BEY98] è una tecnica in cui ciascuna informazioni raccolta sugli utenti e relativi compiti viene inserita in promemoria. Gli utenti e gli analisti collaborano per suddividere le note correlate in gruppi concettuali o "affinità". Questa attività aiuta a promuovere la comprensione di tutti delle problematiche, la loro importanza relativa e le relazioni.
  • Card sorting [CON99] è un'attività simile dove le informazioni sono riportate su schede e organizzate in gruppi. Le schede possono essere organizzate in ordine di importanza, frequenza e così via.
  • La Modellazione gerarchico dei compiti [MAY99, CON99] analizza i compiti attualmente eseguiti dagli utenti e li organizza gerarchicamente. La gerarchia deve riflettere come gli utenti intendono i propri compiti all'interno dell'organizzazione.

Analisi e progettazione

Una serie di altre attività in questa disciplina sono mirate alla formazione e alla progettazione dell'interfaccia utente. Tra queste, si segnalano:

Attività

Artefatto

Contenuto correlato all'utilizzabilità

Progettazione dell'interfaccia utente

Storyboard

Mappa di esplorazione

Questa attività crea ciò cui spesso viene definita Progettazione concettuale [FER01], che corrisponde all'astrazione iniziale dell'interfaccia utente in sé, catturando le finestre e i percorsi di navigazione principali proposti all'utente. Questa attività concentra l'attenzione sui casi d'uso su cui si basa la progettazione dell'interfaccia utente.

Le Mappe di esplorazione, vedere[CON99], offrono una panoramica dei percorsi di esplorazione tra gli spazi di interazione (schermate, finestre e finestre di dialogo).

Prototipizzazione dell'interfaccia utente Prototipo dell'interfaccia utente

È possibile generare tre tipi di prototipi:

Disegni (su carta)
Bitmap (tool per disegnare)
Eseguibili (interattivo)
Nella maggior parte dei progetti, è previsto l'uso di tutte e tre i prototipi, nell'ordine testé citato.

Lo scopo principale nella creazione di un prototipo dell'interfaccia utente è di essere in grado di esporre e verificare la funzionalità e l'utilizzabilità del sistema prima che inizi la fase effettiva di progettazione e sviluppo. In questo modo, è possibile garantire che la versione del sistema in costruzione sia adeguata, prima di dedicare troppo tempo e risorse nello sviluppo.


Le tecniche esaminate di seguito possono essere utilizzate come parte della progettazione dell'interfaccia utente:

  • Card sorting [CON99], descritta in precedenza, è anche utile per la progettazione dell'interfaccia utente. Ciascuna voce di menu o elemento del contenuto viene rappresentato da schede, che vengono quindi organizzate dall'utente in gruppi logici.

Oltre alle attività descritte in precedenza, sono disponibili altre attività di Analisi e Sviluppo che fanno da complemento nella progettazione dell'interfaccia utente:

Attività

Artefatto

Contenuto correlato all'utilizzabilità

Analisi del caso d'uso Classe di analisi,
Realizzazione caso d'uso

Vedere inoltre:

Progettazione classi

Questa attività si serve dei risultati ottenuti dalla progettazione e prototipizzazione dell'interfaccia utente per progettare le classi. A differenza dei prototipi, questo non è un lavoro concettuale per l'interfaccia utente destinato a un solo utilizzo, ma ha lo scopo di rappresentare il sistema distribuito.

Vedere inoltre le seguenti linee guida:

Linea guida: Costruzione di applicazioni Web con UML


Implementazione

L'implementazione dell'interfaccia utente segue il generale Flusso di lavoro dell'implementazione. Si sottolinea che l'implementazione dell'interfaccia utente è spesso effettuata come parte dell'attività di progettazione.

Test

La Verifica di utilizzabilità, comprese le Verifiche sulle prestazioni relative all'utilizzabilità, devono essere eseguite non appena sono disponibili i modelli prova o i prototipi dell'interfaccia utente. I test dovrebbero includere la verifica di utilizzabilità e i requisiti di prestazione catturati nelle Specifiche supplementari o come "Requisiti speciali" nel Caso d'uso.

Distribuzione

Si consiglia di coinvolgere intensamente gli utenti nell'Attività: Fase di verifica beta del prodotto così come nella Verifica di utilizzabilità durante l'Attività: Gestione della verifica di accettazione.

L'Attività: Sviluppo del materiale di supporto comprende lo sviluppo del materiale per la formazione e della documentazione di supporto del sistema per garantire che gli utenti possano utilizzare nel modo migliore il prodotto software distribuito.

Gestione del progetto

La Gestione del progetto è l'arte di bilanciare obiettivi contrastanti, gestire i rischi e superare i vincoli per distribuire con successo un prodotto che sia conforme alle esigenze del cliente (committente) e degli utenti. Dalla prospettiva dell'usability engineering, l'attività critica è Compito: Definizione dell'organizzazione e del personale per il progetto. Questa attività definisce la struttura organizzativa, le interfacce esterne e i ruoli e relative responsabilità, così come, determina i limiti di coinvolgimento dell'utente nel processo di sviluppo e se sia necessario che gli sviluppatori siano esperti dei metodi di usability engineering.

Ambiente

La Disciplina dell'ambiente prevede la definizione del processo di sviluppo che il progetto o l'organizzazione deve seguire. Il Compito: Sviluppo del caso di sviluppo (Prodotto di lavoro: Caso di sviluppo) determina le tecniche di usability engineering da applicare e il metodo seguito per personalizzare i vari artefatti e le attività RUP in modo da incorporare tali tecniche.

Un'altra attività importante è Compito: Sviluppo delle linee guida specifiche per progetto che crea il Prodotto di lavoro: Linee guida del progetto che includono le linee guida per l'interfaccia utente, che aiutano a garantire l'uniformità dell'interfaccia utente, molto importante per l'utilizzabilità della stessa. Le linee guida catturano inoltre i principi di utilizzabilità, quali tasti di scelta rapida, capacità di "annullamento", uscite riconoscibili, interazione amodale e così via.

Sviluppo e fasi iterativi

Il ciclo di vita del software del RUP viene scomposto nel tempo in quattro fasi sequenziali, ciascuna conclusa da un cardine importante; ciascuna fase rappresenta sostanzialmente un periodo di tempo tra due cardini importanti. A fine fase viene eseguita una valutazione (Compito: Esame del cardine del ciclo di vita) per determinare se gli obiettivi della fase sono stati rispettati. Una valutazione soddisfacente consente al progetto di passare alla fase successiva.

All'interno di ciascuna fase possono verificarsi molte iterazioni. Un'iterazione corrisponde a un ciclo di sviluppo completo (interno o esterno) di un prodotto eseguibile, un sottoinsieme del prodotto finale in fase di sviluppo, che cresce ad incrementi da iterazione ad iterazione, fino a diventare il sistema finale. L'utilizzabilità trae enormi vantaggi dall'approccio iterativo. Consente agli utenti di fornire un feedback anticipato sull'utilizzabilità ed evitare di inoltrarsi su un percorso che non corrisponde alle esigenze del cliente.

L'utente deve essere coinvolto in questa iterazione, per perfezionare ulteriormente i requisiti, per valutare i concetti di progettazione e verificare/valutare l'utilizzabilità dei prototipi con proof of concept e del sistema in evoluzione.

Le sezioni successive descrivono i criteri di completamento correlati all'utilizzabilità e le attività principali per ciascuna fase.

Inizio

I due obiettivi chiave della Fase di inizio sono Inizio:

  • Accertamento dell'ambito del software e delle condizioni di boundary del progetto, ivi compresa la visione operativa, i criteri di accettazione e il contenuto del prodotto.
  • Discriminazione dei casi d'uso critici del sistema, gli scenari principali di operazione che realizzano i compromessi principali della progettazione.

Dalla prospettiva della usability engineering, ciò significa enfatizzare le attività correlate alla modellazione dei requisiti e del business (se eseguita):

  • comprensione degli utenti e determinazione delle loro esigenze
  • identificazione dei casi d'uso che producono un vantaggio maggiore per gli utenti.

La Fase di inizio è anche il momento adatto per esplorare alcune progettazioni concettuali e prototipizzazioni "proof of concept". Ciò si rivela particolarmente vero quando i rischi del progetto principale sono correlati all'interfaccia utente e alle considerazioni sull'utilizzabilità. La Verifica di utilizzabilità, comprese le Verifiche sulle prestazioni relative all'utilizzabilità, devono essere eseguite non appena sono disponibili i modelli prova o i prototipi dell'interfaccia utente.

Elaborazione

Siccome RUP è un processo iterativo, gli artefatti creati nella fase di inizio vengono rivisitate e riesaminate con gli utenti al fine di gestire l'ambito e garantire che il sistema in evoluzione soddisfi le esigenze dell'utente.

Nella fase di Elaborazione, l'attenzione viene concentrata sull'Architettura software - compresa l'architettura dell'interfaccia utente. L'interfaccia utente concettuale viene definita e gli elementi critici e/o di rischio della progettazione della stessa vengono implementati. Le attività correlate all'architettura software si riferiscono all'interfaccia utente in generale: prodotti commerciali da valutare, le considerazioni di riutilizzo, la scelta di meccanismi e pattern, ecc.

Questa fase pone particolare enfasi sulle attività di progettazione dell'interfaccia utente, così come sulle attività di supporto ricavate dalla disciplina Analisi e progettazione. Anche implementazione e test fanno parte di questa fase, in quanto il completamento dell'elaborazione richiede la costruzione di un sistema funzionante da poter valutare.

La Verifica di utilizzabilità e la Verifica delle prestazioni, devono focalizzare sui requisiti rischiosi catturati nelle Specifiche supplementari o come "Requisiti speciali" nel Caso d'uso.

Costruzione

Nella fase di Costruzione, l'attenzione viene concentrata sull'implementazione di più casi d'uso. Ciò prevede l'aggiunta dell'interfaccia utente, conservando, al tempo stesso, conformità con il modello concettuale dell'interfaccia stessa e con le le linee guida catturate nelle Linee guida specifiche per progetto. All'aggiunta di nuove funzioni, la Verifica di utilizzabilità continua ad essere molto importante.

La scelta di quale funzionalità inserire in ciascuna iterazione si basa sul valore per l'utente.

Transizione

L'attenzione nella fase di transizione passa sulla disciplina Distribuzione. In un'implementazione incentrata sull'utente, non bisogna aspettare fino alla fase di transizione per coinvolgere l'utente. Il coinvolgimento dell'utente deve essere su base continuativa, in primo luogo per offrire riscontri. Quando un utente è stato coinvolto durante tutta la fase di distribuzione, il rilievo dato ai test formali della versione beta e all'accettazione è spesso ridotto al minimo o non esistente, dato che il feedback e l'approvazione dell'utente sono stati ottenuti nel corso dell'impegno di distribuzione.

La distribuzione del materiale per la formazione e la documentazione di supporto del sistema è finalizzata nella fase di Transizione, sebbene si consiglia, se possibile, di avviarla nelle fasi precedenti, per poter ottenere il feedback dell'utente.

Durante la transizione, è presente un sistema funzionante utilizzabile dall'utente. Si consiglia di pianificare almeno una coppia di iterazioni durante la transizione, in modo che i problemi rilevati nelle versioni iniziali possano essere corretti e che il feedback dell'utente venga incorporato.