Modellazione di storie utente

Il team può creare modelli che facilitino la comprensione delle storie utente da stimare o sviluppare.I modelli possono inoltre essere utilizzati dal team durante le discussioni in corso con il proprietario del prodotto che si verificano durante la fase sviluppo, qualora le problematiche siano sufficientemente complesse.

Ad esempio, il progetto può comprendere un set di concetti nuovi per il team.Collaborando con il proprietario del prodotto, il team può sviluppare un diagramma classi di dominio per acquisire tali concetti e le relazioni tra di essi.Se il team ha l'esigenza di comprendere le sequenze principali di un'attività dell'utente, potrà creare un diagramma di attività.

Per ulteriori informazioni, vedere Modellazione dei requisiti utente.

Modello di dominio: il linguaggio degli utenti

Diagrammi classi di dominio

In un diagramma classi di dominio vengono illustrati i concetti e le relazioni associati all'applicazione.Chiunque sia associato all'applicazione può quindi utilizzare tali concetti per ottenere informazioni più coerenti.

L'esempio descritto nell'illustrazione precedente non è direttamente un diagramma classi della soluzione software, che potrebbe rappresentare tali relazioni in diversi modi.Al contrario, presenta un vocabolario con il quale è possibile scrivere le storie utente:

Il cliente sceglie un Menu da cui creare un Ordine, quindi crea gli Elementi ordine nell' Ordine selezionando le Voci di menu dal Menu.

Poiché si tratta di un modello di concetti anziché di oggetti in un programma, non vengono normalmente assegnate operazioni alle classi quando il diagramma viene utilizzato a tale scopo.Al contrario, è possibile utilizzare i diagrammi di attività per descrivere le azioni eseguite dagli utenti.

Per ulteriori informazioni, vedere Diagrammi classi UML: linee guida.

Diagrammi di attività

Il team può illustrare il flusso delle attività che un utente può eseguire e visualizzare le operazioni alternative in ogni punto utilizzando i diagrammi di attività.

Quando il team crea i test, può fare riferimento ai diagrammi di attività e creare un test per ogni percorso dal diagramma di attività.

Una storia utente potrebbe introdurre un percorso in un diagramma di attività esistente.Ad esempio, una storia utente potrebbe essere "Come cliente posso scegliere di salvare un ordine per un momento successivo anziché effettuarne il pagamento ora". Quando la storia viene inserita in uno sprint per essere sviluppata, è possibile aggiornare il diagramma di attività per esprimere la nuova funzionalità.

Il diagramma di attività consente di descrivere un set completo di percorsi che l'utente può seguire utilizzando una particolare versione dell'applicazione, purché si aggiorni il diagramma per riflettere tutte le storie utente implementate dal team.

Per ulteriori informazioni, vedere Diagrammi di attività UML: linee guida.

Utilizzo del modello per determinare i gap

Il team può comprendere meglio le esigenze degli utenti evitando i malintesi che si verificano nelle conversazioni non supportate da un diagramma.Ad esempio, un diagramma è in grado di distinguere chiaramente tra un elemento di un ordine e una voce di un menu.

La creazione del modello consente al team di porre domande, cosa che diversamente non potrebbe fare fino a una fase di sviluppo più avanzata.Tra le possibili tecniche rientrano le seguenti:

• Richiesta di informazioni relative alle cardinalità del diagramma classi, ad esempio, "È possibile che una voce di menu venga visualizzata in più menu"?

• Richiesta di informazioni sui cicli nel diagramma classi, ad esempio, "In un ordine qualsiasi, tutte le voci appartengono allo stesso menu"?

Le risposte a questi tipi di domande possono essere aggiunte come commenti nel diagramma.

Coerenza del modello

Il team può risolvere le ambiguità assicurandosi che il modello e le storie utente siano coerenti:

• Nelle storie utente vengono utilizzati i termini definiti nel modello e tali descrizioni sono coerenti con le relazioni definite.Se il modello definisce voci di menu, nelle storie non deve essere utilizzato il termine "prodotti" per indicare lo stesso elemento.Se nel diagramma classi viene illustrato che una voce di menu appartiene esattamente a un solo menu, nelle storie non si dovrà fare riferimento alla condivisione di una voce tra più menu.

• Ogni storia utente descrive una serie di passaggi consentiti dai diagrammi di attività.

• Le storie utente o le attività descrivono in che modo le classe e le relazioni nel diagramma classi vengono create e distrutte.Quale storia utente, ad esempio, comporta la creazione di una voce di menu?Quando viene distrutto un ordine?

Modelli e backlog del prodotto

Il team può contrassegnare i modelli e gli storyboard in modo da visualizzare le parti che verranno modificate da ogni storia utente e inserire un colore o un commento in un modello per facilitare la pianificazione dello sviluppo.Ad esempio, il team potrebbe assegnare un colore alle azioni in un diagramma di attività per indicare quali sono state completate e quali lo saranno nello sprint successivo.

Per ulteriori informazioni, vedere Modellazione dei requisiti utente.

Modelli e test

Il team può utilizzare un modello di dominio come base per i test di sistema, evidenziando una chiara relazione tra test ed esigenze degli utenti.Questa relazione consente al team di aggiornare i test in modo rapido e corretto, assicurando che il prodotto soddisfi le nuove esigenze.

Il team può collegare qualsiasi elemento in un modello UML (Unified Modeling Language) a qualsiasi elemento di lavoro, ad esempio un test.Quando una parte del modello viene modificata, il modello consentirà al team di individuare i test a cui è correlata.

Utilizzare il modello di dominio per facilitare la creazione dei test:

• Creare almeno un test che preveda la costruzione di ciascun tipo o associazione, ad esempio una voce di menu o un elemento dell'ordine e almeno un test che ne preveda la distruzione.

• Assicurarsi che tutti i percorsi descritti dai diagrammi di attività vengano testati.

  [!NOTA]

  I test devono inoltre analizzare i percorsi eccezionali che normalmente non vengono illustrati nei diagrammi di attività.

• Utilizzare il vocabolario del modello di dominio per definire i test.Ad esempio, i test dovrebbero includere un test dell'azione Selezione voce di menu per verificare che l'azione generi l' Ordine contenente un nuovo Elemento ordine.Per scrivere test automatizzati, è possibile utilizzare le classi e le relazioni basate direttamente sul diagramma.

Per ulteriori informazioni, vedere Sviluppo di test da un modello.