Concetti:
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à.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
|