Durante uno workshop sui requisiti, il cassiere potrebbe dire che uno dei suoi obiettivi è effettuare l'autenticazione. Questo è solo un meccanismo per raggiungere uno scopo, più che lo scopo in sé. Esaminando la gerarchia degli obiettivi ("Qual è l'obiettivo di quel meccanismo?"), l'analista deve giungere a degli obiettivi indipendenti dai meccanismi: per esempio, "identificare me stesso e ottenere l'autenticazione" oppure un obiettivo di livello ancora più elevato "prevenire i furti".
Questo processo di scoperta dell'obiettivo radice può suggerire soluzioni nuove, per esempio l'uso di tastiere con lettori biometrici basati su impronte digitali. Tuttavia bisogna effettuare anche una analisi dell'usabilità. Se il sistema è richiesto da una società i cui dipendenti hanno spesso le dita sporche di grasso, qualcosa del genere non fa per loro.
Esempi a confronto:
Stile essenziale:
1. L’Amministratore si identifica.
2. Il Sistema autentica l’identità.
3. ...
Stile concreto (da evitare durante le attività inziali sui requisiti):
1. L’Amministratore inserisce ID e password nella finestra di dialogo (si veda Figura 3).
2. Il Sistema autentica l’Amministratore.
3. Il Sistema visualizza la finestra “edit users” (si veda Figura 4).
4. ...
Questo tipo di requisiti possono essere utili nella progettazione di GUI concrete o dettagliate, ma in una fase successiva.
Da questo deriva la scrittura di casi d'uso concisi:
per esempio è preferibile scrivere "Il Sistema autentica l'Amministratore" anziché "L'amministratore viene autenticato" (da chi?).
Il tipo più comune e consigliato sono i casi d'uso a scatola nera:
Usando i casi d'uso a scatola nera per definire le responsabilità del sistema, è possibile specificare che cosa deve fare il sistema senza decidere come lo farà.
Naturalmente, nello sviluppo iterativo ed evolutivo, non tutti gli obiettivi o i casi d'uso saranno identificati completamente fin dall'inizio. Anche la scoperta dei requisiti è iterativa.
Come vengono organizzati gli attori e gli obiettivi:
- Man mano che vengono scoperti, vengono disegnati in un diagramma dei casi d'uso chiamando i casi d'uso come gli obiettivi.
- Scrivere dapprima un elenco di attori-obiettivi, rivederlo e raffinarlo, per poi disegnare il diagramma dei casi d'uso
Se si crea un elenco attori-obiettivi allora, in termini di elaborati di UP, è utile riportate questo elenco in una sezione dell'elaborato Visione.
Ecco un esempio:
Il sistema per l'Analisi delle Vendite è un'applicazione remota che chiederà frequentemente i dati sulle vendite.
Chiede agli attori gli obiettivi anziché i casi d'uso
Gli attori hanno degli obiettivi e utilizzano le applicazioni per raggiungerli. La modellazione dei casi d'uso è interessata a trovare questi attori e i rispettivi obiettivi, e creare soluzioni che producono un risultato di valore. Il modellatore si chiederà "Chi utilizza il sistema?" invece di "Quali sono le attività svolte?". Il nome di un caso d'uso per un obiettivo di un utente dovrebbe infatti rispecchiare il nome dell'obiettivo stesso, per sottolineare questo punto di vista. Se l'obiettivo è acquisire o elaborare una vendita, il caso d'uso si chiamerà Elabora Vendita.
Tra le domande:
- "Che cosa fate?"
- "Quali sono i vostri obiettivi i cui risultati hanno un valore misurabile?"
si preferisce la seconda.
Nel caso d'uso Elabora Vendita, perché l'attore primario è il cassiere e non il cliente?
Dipende:
- se il negozio, o il servizio di cassa viene visto come un sistema aggregato, allora il cliente è un attore primario, che ha lo scopo di acquistare merci o servizi e poi andarsene.
- Tuttavia dal punto di vista del sistema POS, il sistema è a servizio dell'obiettivo di un cassiere esperto di elaborare la vendita del cliente. Questo corrisponde a un ambiente tradizionale di pagamento, che comprende anche un cassiere, anche se c'è un numero sempre maggiore di sistemi POS a cassa automatica utilizzabili dai clienti.
Il cliente è un attore, ma non primario, invece quello primario è il cassiere che usa il POS per raggiungere l'obiettivo di elaborazione della vendita.
D'altro canto si consideri un sito web per l'acquisto di biglietti che possa essere utilizzato, nello stesso identico modo, sia da un cliente che da un agente telefonico che risponde alle chiamate dei clienti per il supporto all'acquisto. In questo caso l'agente è un intermediario per il cliente; il sistema non è progettato per soddisfare gli obiettivi specifici dell'agente. In questo caso sarebbe corretto mostrare come attore primario il cliente e non l'agente.
Altro approccio per trovare attori, obiettivi e casi d'uso è basato sull'identificazione di eventi esterni. Quali sono? Da dove provengono? Perché?
Per esempio:
Ci sono diverse regole pratiche:
- Il test del capo
- Il test EBP
- Il test della dimensione
Il test del capo...
Il capo vi chiede: "Cosa avete fatto tutto il giorno?", voi rispondete: "Il login!". Il vostro capo sarà felice?
Se non lo è, il caso d'uso non supera il test del capo, il che vuol dire che non è fortemente mirato a ottenere risultati il cui valore sia misurabile. Potrebbe essere un caso d'uso a livello più basso. L'autenticazione può non superare il test del capo, ma potrebbe essere importante e difficile.
Il test EPB...
Processo di Business Elementare (Elementary Business Process o EPB) deriva dal settore dell'ingegneria dei processi business
Un processo di business elementare è un'attività svolta da una persona in un determinato tempo e luogo, in risposta a un evento di business misurabile a lascia i dati in uno stato consistente; per esempio Approva un credito o Stabilisci il presso per un ordine
Linea guida: concentrarsi sui casi d'uso che corrispondono a degli EBP.
La definizione non va presa troppo alla lettera. Se sono necessarie due persone, oppure se una persona deve andare in giro, il caso d'uso fallisce l'EBP? Probabilmente no, ma il tono alla definizione è più o meno corretto. Non è un piccolo paso come "eliminare una riga per un articolo" o "stampare il documento". Lo scenario principale di successo sarà costituito probabilmente da cinque-dieci passi. Non occorrono giorni e sessioni multiple, come "negoziare un contratto con un fornitore", è un'attività eseguita in una sola sessione di lavoro tra i dieci minuti/un'ora.
Il test della dimensione...
Un caso d'uso raramente è costituito da una sola azione o passo. Normalmente comprende diversi passi. Un errore è definire il caso d'uso in un unico passo (o punto).
Applicazione dei test...
- Negoziare un contratto con un fornitore
- Molto più ampi e lungo di un EBP. Potrebbe essere modellato come un caso d'uso di business invece che come un caso d'uso di sistema.
- Gestire una restituzione
- Il capo è d'accordo. É simile ad un EBP. Le dimensioni vanno bene.
- Effettuare il login
- Il capo non è contento se ci si limita a fare questo tutto il giorno!
- Spostare una pedina sul tabellone da gioco
- Passo singolo, non supera il test della dimensione.
Nell'analisi dei requisiti è utile concentrarsi soprattutto sui casi d'uso EBP.
Gestire una restituzione è a livello di obiettivo utente, poiché consente all'utente di raggiungere un proprio scopo di valore mediante un singolo utilizzo del sistema.
Un caso d'uso può essere invece utile per descrivere un singolo passo complesso nell'utilizzo del sistema; per esempio Effettuare il login. Si noti che l'utilizzo di un tale caso d'uso, da solo, non consente all'utente di raggiungere un proprio obiettivo. Un caso d'uso di questo tipo è a livello di sotto-funzione, poiché rappresenta solo una funzionalità nell'uso del sistema. Nell'analisi dei requisiti, casi d'uso di questo tipo vengono normalmente creati per mettere a fattor comune delle sequenze di passi condivise da più casi d'uso, per evitare la duplicazione del testo in comune. Per esempio: Pagamento con carta di credito.
Un caso d'uso può anche riguardare un obiettivo ampio, che di solito non può essere raggiunto con un singolo utilizzo del sistema, ma con molti accessi ad esso. Spesso anche in momenti diversi. Per esempio: Negoziare un contratto con un fornitore. Un caso d'uso di questo tipo è a livello sommario, e la sua esecuzione di solito richiedere ore, giorni, mesi, o anche anni. In genere è utile identificare sempre questo tipo di casi d'uso per avere una visione complessi sugli obiettivi del sistema. Tuttavia, non forniscono direttamente dei requisiti per il sistema software da sviluppare.
I diagrammi dei casi d'uso e le relazioni tra casi d'uso sono secondari nel lavoro che riguarda i casi d'uso. I casi d'uso sono documenti di testo. Lavorare sui casi d'uso significa scrivere testo.
Ciò detto, un semplice diagramma dei casi d'uso può essere utile per fornire un diagramma di contesto per il sistema, visuale e conciso, che illustri gli attori esterni e il modo in cui essi utilizzano il sistema.
Disegnare un semplice diagramma dei casi d'uso insieme a un elenco attori-obiettivi.
Un diagramma è utile per riassumere il comportamento di un sistema, i suoi confini e i suoi attori.
Si noti che il rettangolo per l'attore (nella figura sopra), con il simbolo «actor». Questo stile è utilizzato per parole chiave e stereotipi UML, e comprende le virgolette basse, costituite da un solo carattere («» e non <<>>).
Il rettangolo può essere utilizzato per qualsiasi attore, sistema informatico o umano, fornisce una distinzione visuale per gli attori che sono sistemi informatici, mentre l'omino per l'attore umano.
É importante ridurre al minimo i diagrammi, mantenerli brevi e semplici. Concentrarsi sul testo.
Motivazione: altri vantaggi dei casi d'uso...
- Una motivazione alla base è quella di concentrarsi su quali sono gli attori principali, i loro obiettivi e la modalità d'uso comuni per il sistema. Inoltre i casi d'uso sono scritti in forma semplice, comprensibile da tutti.
- Un'altra è la sostituzione degli elenchi dettagliati delle funzioni di basso livello con i casi d'uso (usati negli anni 70).
Si ribadisce che i casi d'uso non sono l'unico elaborato necessario per i requisiti. Altri elementi quali per esempio: requisiti non funzionali, struttura dei report, regole di dominio e altri, difficili da collocare nei casi d'uso siano raccolti nelle Specifiche supplementari di UP.
Anche se gli elenchi sono sconsigliati per le funzioni di basso livello, può essere utile riassumere le funzionalità del sistema con un elenco di caratteristiche di alto livello, chiamato caratteristiche di sistema, come parte del documento di Visione. Contrariamente alle caratteristiche di basso livello, costituite da molte pagine, un elenco di caratteristiche di sistema dovrebbe comprendere solo alcune decine di voci per fornire un riepilogo conciso delle funzionalità del sistema, separato dal modello dei casi d'uso, come nel seguente esempio:
A volte, può succedere che i casi d'uso non sono adatti. Alcune applicazioni richiedono un punto di vista guidato dalle caratteristiche. Per esempio, gli application server, i sistemi di gestione di basi di dati e altri sistemi e framework di middleware o di back-end vanno piuttosto descritti e si evolvono in termini di caratteristiche. I casi d'uso non sono idonei a questo tipo di sistemi software e al modo in cui essi si evolvono in termini di forze del mercato.
Esempio...
Un esempio significativo nel sistema software del Monopoly è Gioca una partita a Monopoly.
Processo: come lavorare con i casi d'uso nei metodi iterativi...
| Disciplina | Elaborato | Ideaz.: 1 settimana | Elab. 1: 4 settimane | Elab. 2: 4 settimane | Elab. 3: 4 settimane | Elab. 4: 4 settimane |
|---|---|---|---|---|---|---|
| Requisiti | Modello dei casi d'uso | Workshop dei requisiti di 2 giorni. La maggior parte dei casi d'uso vengono identificati, gli viene dato un nome e sono riassunti in un breve paragrafo. Il 10% dei casi d'uso più importanti viene analizzati e scritto in dettaglio. Questo 10% dovrà avere maggior importanza dal punto di vista dell'architettura e del rischio, ed elevato valore di business. | Quasi alla fine di questa iterazione si tiene un altro workshop sui requisiti di 2 giorni. Si ottengono un approfondimento e un feedback dal lavoro di implementazione, quindi si completa il 30% dei casi d'uso nel dettaglio | Quasi alla fine di questa iterazione si tiene un altro workshop sui requisiti di 2 giorni. Si ottiene un approfondimento e feedback dal lavoro di implementazione, quindi si completa il 50% dei casi d'uso nel dettaglio. | Si ripete, si completa il 70% di tutti i casi nel dettaglio | Si ripete con l'obiettivo di chiarire e scrivere nel dettaglio l'80-90% dei casi d'uso. Solo una piccola parte di questi è stata implementata durante l'elaborazione, mentre il resto verrà fatto durante la costruzione. |
| Progettazione | Modello di progetto | Nessuno | Progettazione relativa a un piccolo insieme di requisiti significativi dal punto di vista dell'architettura e del rischio | Ripetere | Ripetere | Ripetere. I rischi maggiori e gli aspetti più significativi dell'architettura dovrebbero ora essere stati stabilizzati. |
| Implementazione | Modello di implementazione (codice e così via) | Nessuno | Implementare questi | Ripetere. Viene costruito il 5% del sistema finale | Ripetere. Viene costruito il 10% del sistema finale. | Ripetere. Viene costruito il 15% del sistema finale. |
| Gestione del progetto | Piano di sviluppo software | Stime molto vaghe dell'impegno complessivo | Le stime iniziano a prendere forma | Un po' meglio.. | Un po' meglio.. | Ora è possibile affidarsi in modo razionale a stime sulla durata complessiva del progetto, le milestone principali, l'impegno e i costi. |
Questa tabella è solo un esempio di come potrebbe funzionare UP, la durata delle iterazioni varia da progetto a progetto, questa analisi non è da seguire alla lettere per tutti i progetti, vuole dare solo l'idea del funzionamento incrementale del modello di sviluppo UP.
Si noti che:
- il team di sviluppo inizia ad implementare il nucleo del sistema quando forse solo 10% dei requisiti p stato scritto in dettaglio; di fatto, il team si attarda deliberatamente nel proseguire con la lavorazione approfondita dei requisiti fino a quasi alla fine della prima iterazione dell'elaborazione.
- lo sviluppo del nucleo del sistema inizia presto, molto tempo prima che tutti i requisiti siano noti
- quasi alla fine della prima iterazione dell'elaborazione, viene tenuto un altro workshop sui requisiti, durante il quale viene scritto in dettaglio circa il 30% dei casi d'uso. Questa analisi dei requisiti trae vantaggio dal feedback ottenuto dall'implementazione di una parte del nucleo del software. Il feedback comprende la valutazione da parte dell'utente, i test e una migliore comprensione di "ciò che non si sa". L'atto di costruire il software fa emergere rapidamente supposizioni e domande che necessitano di chiarimenti.
UP incoraggia la scrittura dei casi d'uso durante i workshop dei requisiti. La figura offre suggerimenti sul tempo e lo spazio per lo svolgimento di questo lavoro:
Quando vanno creati i vari elaborati UP (compresi i casi d'uso)...
| Disciplina | Elaborato | Ideaz. | Elab. | Costr. | Trans. |
|---|---|---|---|---|---|
| Iterazione | I1 | E1..En | C1..Cn | T1..T2 | |
| Modellazione del business | Modello di dominio | i | |||
| Requisiti | Modello dei casi d'uso | i | r | ||
| Visione | i | r | |||
| Specifiche supplementari | i | r | |||
| Glossario | i | r | |||
| Progettazione | Modello di progetto | i | r | ||
| Documento dell'Architettura Software | i |
Legenda: i sta per inizio, r sta per raffinamento
La tabella sopra illustra alcuni elaborati di UP e un esempio sul loro possibile inizio e raffinamento.
Il modello dei casi d'uso viene iniziato durante l'ideazione, quando è stato scritto nel dettaglio solo il 10% dei casi d'uso, quelli più significativi dal punto di vista dell'architettura, il resto dei casi d'uso vengono scritti in modo incrementale. Verso la fine dell'elaborazione sarà stata scritta gran parte dei casi d'uso dettagliati e degli altri requisiti (nelle Specifiche Supplementari).
Come scrivere i casi d'uso durante l'ideazione...
Non tutti i casi d'uso vengono scritti nel formato dettagliato durante la fase di ideazione. Piuttosto si supponga che venga svolto un workshop dei requisiti di due giorni all'inizio del progetto.
- La prima parte del giorno dedicata all'identificazione degli obiettivi e delle parti interessate, e facendo delle ipotesi su ciò che rientra o meno nella portata del progetto. Viene creata una tabella attori-obiettivi-casi d'uso e visualizzata con proiettore collegato ad un computer. Viene iniziato un diagramma di contesto dei casi d'uso. Dopo alcune ore saranno stati identificati per nome circa 20 casi d'uso. La maggior parte dei casi d'uso interessanti, complessi o rischiosi viene scritta in formato breve, dedicando circa un paio di minuti alla scrittura di ciascun caso d'uso. Il team comincia a formare un quadro di alto livello della funzionalità del sistema.
- Dopo di ciò, viene riscritto in formato il 10-20% dei casi d'uso, che rappresentano funzioni principali complicate, significative per l'architettura o particolarmente rischiosi per qualche aspetto. Questa analisi potrebbe riguardare due soli casi d'uso nel caso del POS NextGen: Elabora vendita e Gestisci restituzione.
Come scrivere i casi d'uso durante l'elaborazione...
La fase di elaborazione prevede diverse iterazioni timeboxed (per esempio 4) in cui vengono implementate, in modo incrementale, le parti del sistema più critiche, di valore maggiore o significative dal punto di vista dell'architettura; viene inoltre identificata e chiarita la "maggior parte" dei requisiti. Il feedback proveniente dai passi concreti della programmazione influenza e agevola la comprensione dei requisiti da parte del team, che li raffina in maniera iterativa e adattiva. Probabilmente, in ciascuna delle iterazioni, si terrà un workshop dei requisiti di due giorni. Tuttavia in ciascun workshop non vengono esaminati tutti i casi d'uso, piuttosto vengono assegnati ad essi delle priorità. I workshop iniziali si concentrano solo sui casi d'uso importanti.
In ogni breve workshop successivo viene adattata e raffinata la visione sui requisiti principali, che sarà instabile nelle prime iterazioni, ma si stabilizzerà. Dunque, c'è un'iterazione, mutua e iterativa, tra la scoperta dei requisiti e l'implementazione delle parti software.
Durante ciascun workshop dei requisiti, gli elenchi degli obiettivi degli utenti e quello dei casi d'uso vengono raffinati. Vengono scritti (e riscritti) più casi d'uso in formato dettagliato. Alla fine dell'elaborazione, l'80-90% dei casi d'suo sarà stato scritto in dettaglio.
Come scrivere i casi d'uso durante la costruzione...
La fase di costruzione è costituita da iterazioni timeboxed che si concentrano su completamento del sistema, dopo che gli aspetti fondamentali più rischiosi e potenzialmente instabili sono stati stabilizzati nell'elaborazione. Potrebbe essere ancora necessario scrivere alcuni casi d'uso minori e tenere alcuni workshop dei requisiti, ma molto meno che nella fase di elaborazione.
Studio caso: i casi d'uso nella fase di ideazione del POS NextGen...
| Dettagliato | Informale | Breve |
|---|---|---|
| Elabora vendita | Elabora noleggio | Cash out |
| Analizzare dati sulle vendite | Gestisci resituzione | |
| Gestisci sicurezza | Cash in | |
| ... | Gestisci gli utenti | |
| Avviare il sistema | ||
| Arrestare il sistema | ||
| Gestisci |
Prossimo argomento altri requisiti.