Il workshop sui casi d'uso è una riunione organizzata di brainstorming. E' necessario rappresentare una vasta gamma di conoscenze:
-
Requisiti del cliente
-
Progettazione di sistema
-
Progettazione di unità
-
Rational Unified Process
-
Verifica
Questo significa che il gruppo conterrà persone con background, conoscenze ed esperienze differenti. Cercare di formare
un gruppo piccolo (meno di dieci partecipanti). Una configurazione normale è di prendere metà del gruppo dal team di
sviluppo e l'altra metà dai rappresentanti degli utenti. Al centro c'è il moderatore. Il moderatore deve fungere da
mediatore (un catalizzatore di tutte le idee e desideri).
I tool necessari sono:
-
Due grandi lavagne bianche (una è sufficiente ma due sono meglio)
-
Fogli da lavagna a cavalletto
-
Nastro adesivo
-
Foglietti autoadesivi in due colori
-
Penne per lavagne bianche (in diversi colori)
-
Matite
-
Pareti su cui attaccare i fogli, preferibilmente in una stanza "laboratorio" da poter utilizzare indisturbati per
due o tre settimane.
Tentare di identificare chi o cosa utilizzerà il sistema. Iniziare considerando che delle vere persone utilizzeranno il
sistema; la maggior parte delle persone riesce a focalizzare meglio su cose concrete piuttosto che astratte. Una volta
identificati gli utenti, tentare di individuare il ruolo che l'utente deve svolgere quando interagisce con il sistema -
in genere si tratta di un buon nome per un attore.
Quando si identificano gli attori, scrivere una breve descrizione di ognuno; di solito, pochi punti che riassumono il
ruolo svolto dall'attore nei confronti del sistema e le relative responsabilità sono utili successivamente quando verrà
il momento di stabilire di cosa ha bisogno l'attore dal sistema.
Quando si definiscono gli attori, non dimenticare gli altri sistemi con i quali interagisce il sistema in fase di
progettazione. L'icona relativa all'attore qui è fuorviante, sembra implicare una 'persona' ma il concetto di attore
comprende anche i sistemi. Tuttavia, inizialmente individuare degli attori 'umani'; la maggior parte dei gruppi rende
meglio se in principio ci si concentra su cose note e, in seguito, si prendono in considerazione quelle più insolite.
Non preoccuparsi della struttura del modello di casi d'uso o delle relazioni fra gli attori; individuare
semplicemente le persone o le cose che utilizzeranno il sistema. Focalizzare sull'identificazione e prepararsi ad
individuare molti attori. Non occuparsi ora di filtrare l'elenco; verrà fatto durante l'identificazione dei casi d'uso (vedere di seguito).
Porre questa domanda: quali sono i ruoli nell'organizzazione che utilizzerà il sistema? Disegnare un omino per ciascun
ruolo suggerito e scriverci sotto un nome. Quindi elencare due colonne di attori sulla lavagna - una su ogni lato della
nuvola o icona appena disegnata. A volte può essere utile utilizzare la parola ruolo o utente al posto di attore.
Domande da porre:
-
Chi utilizzerà il sistema?
-
A quali altri sistemi il sistema invierà informazioni?
-
Da quali altri sistemi riceverà informazioni?
-
Chi avvia il sistema?
-
Chi gestirà le informazioni degli utenti?
Potrebbero essere poste domande quali "Perché non è Tom l'attore? E' sempre Tom che se ne occupa". Sarà quindi
necessario porre altre domande per ottenere una comprensione di quale sia il ruolo di Tom. Il nome dell'attore deve
rifletterne il ruolo.
-
Qual è il ruolo di Tom?
-
Chi altro è in grado di eseguire quel ruolo?
-
Perché Tom ha quel ruolo?
Molti attori possono essere identificati direttamente dalla loro normale posizione nell'organizzazione. Una posizione
nell'organizzazione potrebbe corrispondere a più di un ruolo per il sistema. Ad esempio, Tom potrebbe essere un
magazziniere o la persona responsabile dell'organizzazione del magazzino per la creazione di spazio per i nuovi
prodotti. Queste due responsabilità potrebbero rappresentare due attori diversi per il sistema.
Alcune persone vorranno generalizzare fino agli estremi. Potrebbero suggerire un utente come attore, ed affermare che
si tratta dell'unico attore di cui si ha bisogno. Vero, ma noioso, e non aggiunge molto alla comprensione del sistema.
Tentare di evitare di discutere su questo argomento, se viene fuori. Annotare sulla lavagna l'attore Utente e
continuare con l'attore successivo.
-
Chiedere a tutti se manca qualcosa.
-
Esternare dei suggerimenti non buoni. In questo modo il team può correggervi e spiegare gli esatti ruoli del
sistema.
-
Accettare sempre tutti i suggerimenti (è sempre possibile rimuovere in un secondo momento i duplicati e i non
attori. Effettuare delle critiche ai suggerimenti di qualcuno abbassa semplicemente lo spirito della riunione.
La definizione degli attori in genere richiede da 1 a 4 ore. La lavagna a questo punto dovrebbe elencare molti attori,
ma accertarsi che vi sia ancora spazio per aggiungere i casi d'uso. Quando la serie di attori sembra essere completa, è
ora di iniziare con i casi d'uso.
Cancellare dalla lavagna la nuvola o l'icona ed iniziare ad identificare i casi
d'uso. Concentrare l'attenzione su casi d'uso concreti, evitare discussioni sulle relazioni di inclusione e di estensione. Tracciare un'ellisse e scrivere il nome di ogni suggerimento. Disegnare
delle frecce che puntano agli attori.
Utilizzare come punto di forza il fatto di non sapere nulla sulla loro applicazione. I partecipanti al workshop devono
spiegare cosa dovrebbe svolgere il sistema. Porre molte domande sul sistema. Quando i partecipanti forniscono le
spiegazioni, verranno creati i casi d'uso.
Alcune persone sono in grado di capire immediatamente il concetto di caso d'uso, altre no. Per collocare il concetto in
una prospettiva più semplice, far tracciare a qualcuno una vista del sistema. Una vista del sistema è un'astrazione del
sistema. Ad esempio, può trattarsi di un server con un database ed un certo numero di client oppure di schede di
circuiti con i relativi compiti speciali contrassegnati. Questa vista in genere è semplice da illustrare: uno dei
partecipanti di solito prende la penna della lavagna bianca e mostra come funziona il sistema. La vista del sistema
sarà utile per estendere i casi d'uso da un margine del sistema all'altro ed implicitamente indica un certo numero di
stati diversi del sistema. Porre delle domande sugli stati e verranno creati altri casi d'uso. Verificare cosa accade
quando si interrompono le differenti comunicazioni - ciò è utile per identificare dei flussi alternativi nei casi
d'uso.
Se si sta lavorando con un sistema tecnico, la vista del sistema è spesso qualcosa di molto noto a tutti e potrebbe
essere il metodo migliore per individuare gli attori. In questo caso si può lasciare ai partecipanti il compito di
disegnare la vista del sistema prima di iniziare a richiedere gli attori.
Se si sta lavorando con un sistema gestionale, la vista del sistema potrebbe non essere così ovvia a tutti. In questo
caso potrebbe essere più utile un grafico che descrive le routine manuali. Il grafico può descrivere come viene
spostata un'entità di business da una persona all'altra e cosa deve essere svolto con quell'entità. Per visualizzare il
processo di ordine e consegna, il grafico potrebbe mostrare una vista schematica dell'ufficio del cliente, il proprio
ufficio, il magazzino ed il magazzino del cliente.
Accertarsi che sia il modello di casi d'uso che la vista di sistema/vista delle entità di business siano chiaramente
visibili a tutti. Questo è uno dei casi in cui due lavagne potrebbero tornare utili.
Lasciare che i casi d'uso abbiano dei nomi lunghi. Un caso d'uso identificato di recente potrebbe avere un nome lungo
come una frase (è un buon inizio per la breve descrizione del caso d'uso ed in seguito il nome può essere accorciato).
Sarà sempre presente un certo numero di casi d'uso che sembrano avere delle parti in comune. Verificare che tutti
comprendano che per ora è accettabile. Non ha senso ancora procedere ora con la strutturazione, poiché non si conosce
abbastanza il contenuto dei casi d'uso. E' necessario attendere che il flusso di eventi sia stato delineato, prima di
iniziare a parlare delle relazioni dei casi d'uso.
Quando il gruppo concorda che i casi d'uso presenti sulla lavagna coprono la funzionalità dell'intero sistema,
effettuare una pausa per il pranzo.
Una volta rientrati dalla pausa, rivedere i risultati della sessione mattutina:
-
Osservare ciascun attore: quali sono i suoi compiti in questo sistema? 'Compito'
può risultare una parola più adatta di 'caso d'uso' per le persone non esperte di tecniche di modellazione di casi
d'uso.
-
Osservare ogni caso d'uso suggerito: è comprensibile il valore che ne otterrà
l'utente con questo caso d'uso? Se il risultato è positivo, l'utente sarà più predisposto a voler creare il caso
d'uso.
-
Osservare ciascun caso d'uso suggerito: è completo? Oppure è semplicemente una piccola parte di qualcosa di più
grande?
Domande da porre:
-
Ogni attore deve avere almeno un caso d'uso. In caso contrario, potrebbe trattarsi di un attore duplicato (un altro
attore esegue lo stesso ruolo) o l'attore non è realmente un diretto utente del sistema. In questi casi, se una
discussione in merito alla conservazione dell'attore non porta a forti motivazioni per mantenere l'attore, questi
può essere rimosso.
Esaminare i casi d'uso uno alla volta e creare un foglio per ogni caso d'uso. Disegnare un'ellisse e scrivere il nome
del caso d'uso in cima al foglio. Prendere una matita e chiedere al gruppo di aiutarvi a scrivere una breve descrizione
del caso d'uso. Una breve descrizione deve essere composta da circa un massimo di 3 frasi. A volte è utile disegnare
gli attori collegati al caso d'uso. Cercare di lasciare circa metà foglio vuoto per la fase successiva.
Durante questa attività ci si renderà conto che determinate cose che sembravano chiare a tutti in realtà non lo sono
affatto. Fare riferimento ai requisiti identificati come a funzioni ed
esigenze chiave dell'utente nella Visione e
tentare di individuare i requisiti su
questo caso d'uso.
Verranno creati dei nuovi casi d'uso. Altri scompariranno. Collocare i fogli dei casi d'uso sulle pareti. Organizzarli
in modo tale da avere una colonna per area funzionale. (Non utilizzare la lavagna per questa attività: è necessaria per
la vista del sistema, gli attori e i casi d'uso). Se non è possibile risolvere dei quesiti immediatamente, segnarli su
un foglietto adesivo e collocarli sul caso d'uso appropriato. Utilizzare un colore per i quesiti.
Quando tutti i casi d'uso hanno il proprio foglio e la propria descrizione, si passa alla successiva modalità. Spesso è
consigliabile ritagliare un po' di tempo per definire se davvero sono stati individuati tutti i casi d'uso necessari.
Il modello creato fino a questo momento può essere documentato in Rational
Rose o Rational RequisitePro e prodotto sotto forma di un report di
valutazione del modello di casi d'uso.
Il metodo per iniziare la scrittura di un caso d'uso è di strutturarne prima il testo. Non ha senso cercare di
strutturare da soli il testo senza prima aver ottenuto l'input dagli stakeholder.
Esaminare i casi d'uso uno alla volta. Annotare le differenti azioni in ordine. Non cercare di immaginare quale aspetto
avranno le strutture del codice, i loop, le istruzioni for-while, ecc., occuparsi semplicemente del flusso base di
eventi senza prendere ancora in considerazione le alternative. Denominare i passi 1, 2, 3, 4... Per facilitare al
gruppo la comprensione del livello di dettaglio richiesto, si può affermare di volere da 5 a 10 passi nel flusso di
base.
Una volta concordati i passi del flusso base di eventi, ripercorrerlo ed identificare dei passi alternativi. Denominare
i flussi alternativi A1, A2, A3, A4...
Durante la discussione verranno sollevate diverse questioni, molte delle quali non verranno risolte fino a che non si
arriva all'Analisi e progettazione. Ricordarsi di annotare tutte le
problematiche, oltre alle supposizioni necessarie lungo il percorso. Alcune delle problematiche devono essere risolte
presto in modo che lo specificatore di requisiti possa correttamente illustrare nei
dettagli il flusso di eventi ed alcune delle questioni che devono essere risolte prima di iniziare l'analisi e la
progettazione.
Ciò che è presente su ogni foglio ora deve essere sufficiente per lo specificatore di requisiti, perché possa
descrivere in dettaglio il flusso di eventi del caso d'uso.
Durante questa sessione vi saranno dei requisiti sul
sistema che non si sarà in grado di cogliere prontamente in un caso d'uso. In genere questo tipo di istruzioni ha a che
fare con la funzionalità, l'utilizzabilità, l'affidabilità, le prestazioni e la supportabilità del sistema. Tenere un
foglio separato in cui annotare queste istruzioni. Formeranno una base per le specifiche supplementari.
Ripercorrere le richieste chiave degli stakeholder ed ogni funzione contenute nel documento Visione e verificare che il modello di casi d'uso le
affronti nel modo appropriato. Discutere quali esigenze dell'utente o requisiti debbano essere ricondotti a quali casi d'uso.
Prendere il documento Visione e leggere la prima funzione. Annotarne l'identità su uno (o più, se necessario) foglietti autoadesivi
(utilizzare un secondo colore per facilitare la distinzione fra i requisiti e le problematiche). Posizionare il
foglietto sui casi d'uso che soddisfano quel requisito. In seguito sarà possibile inserire queste tracciabilità nel repository di RequisitePro.
Esiste sempre un certo numero di requisiti che non
possono essere collegati ad alcun caso d'uso:
-
Può trattarsi di requisiti specifici che devono essere rinviati alla progettazione; annotarli su un foglio
(requisiti di progettazione).
-
Può trattarsi di requisiti generali che non possono essere collegati ad alcun caso d'uso: collocarli nell'elenco
per le specifiche supplementari.
-
Può trattarsi di requisiti dimenticati e richiedono dei nuovi casi d'uso o delle modifiche a quelli esistenti.
Rivedere la struttura: esistono dei casi d'uso senza requisiti? Perché? Il caso d'uso non è necessario? O la persona
che ha scritto la specifica del requisito ne ha dimenticato la funzionalità? (In genere si tratta di questo). La
situazione deve essere risolta. Il cliente è al corrente che ha bisogno di questa funzionalità? Ha intenzione di
pagarla?
|