Operazione: Assegnazione delle priorità ai casi d'uso
In questo compito si assegnano le priorità ai casi d'uso, così da deciderne l'ordine di sviluppo. Si identificano e si assegnano inoltre le priorità ai casi d'uso significativi dal punto di vista strutturale.
Scopo

Lo scopo di questo compito è:

  • Definizione di input per la selezione dell'insieme degli scenari e dei casi d'uso da analizzare nell'iterazione corrente.
  • Definizione dell'insieme degli scenari e dei casi d'uso che rappresentano una funzionalità significativa e centrale.
  • Definizione dell'insieme degli scenari e dei casi d'uso che abbiano una sostanziale copertura strutturale (che coinvolge svariati elementi dell'architettura) o che evidenzino un punto delicato nella struttura.
 
Relazioni
Descrizione principale

Alcuni tra i fattori utilizzati per determinare la priorità dei casi d'uso possono essere registrati come attributi di Requisiti software . Le priorità risultanti potranno anche essere registrate come attributi dei requisiti, in modo da gestirli con efficacia.

Passi
Assegnazione delle priorità ai casi d'uso ed agli scenari

Un architetto di software suggerisce i contenuti tecnici e l'ordine delle successive iterazioni, selezionando un certo numero di scenari e casi d'uso da analizzare e progettare. Questi suggerimenti tecnici vengono completati e perfezionati da diversi team di sviluppo, basati sulla disponibilità di personale, sui requisiti del cliente in riferimento ai componenti distribuibili, alla disponibilità di tool ed ai prodotti COTS, ed alle necessità di altri progetti.

La selezione degli scenari e dei casi d'uso considerati "significati strutturalmente" (ad esempio, la costituzione della vista del caso d'uso dell'architettura) è basata su alcuni fattori riepilogati di seguito.  

  • Il beneficio dello scenario per gli stakeholder: critico, importante, utile.
  • L'impatto strutturale dello scenario: nessuno, estensioni, modifiche. Vi potranno essere casi d'uso critici che avranno un impatto minimo oppure nessun impatto sull'architettura, e altri con benefici minori che avranno un grande impatto. I casi d'uso con benefici minimi dovranno essere analizzati dal responsabile del progetto per considerarne l'eliminazione.
  • I rischi da attenuare (prestazioni, disponibilità del prodotto, ed adattamento di un componente).
  • Il completamento della copertura dell'architettura (accertandosi che al termine della fase di elaborazione ciascuna parte del software abbia trovato un posto nella vista dell'implementazione).
  • Altri obiettivi o vincoli tattici: dimostrazione all'utente e così via.

Vi potrebbero essere due scenari che riguardano lo stesso componente e considerano gli stessi rischi. Se si implementa prima A e poi B, non ha importanza dal punto di vista strutturale. Se si implementa prima B e poi A, non ha importanza dal punto di vista strutturale. Quindi questi attributi possono dipendere dall'ordine di iterazione, e debbono essere rivalutati quando cambia l'ordine, così come quando cambiano i requisiti.

I casi d'uso strutturalmente significativi che non vengono compresi completamente o che potranno facilmente subire modifiche devono avere assegnata un'alta priorità per chiarimenti e stabilizzazione. In alcuni casi ciò significa che si dovrà eseguire un'ulteriore analisi prima dell'implementazione del requisito. In alcuni casi è meglio utilizzare dei prototipi.

Documentazione della vista del caso d'uso

La vista caso d'uso viene documentata nella sezione Vista caso d'uso del Documento dell'architettura software. Questa sezione contiene un elenco di casi d'uso e scenari significativi all'interno di ciascun pacchetto del modello caso d'uso, assieme ad importanti proprietà quali descrizioni del flusso di eventi, relazioni, diagrammi del caso d'uso, e requisiti speciali relativi a ciascun caso d'uso. Notare che se la Vista caso d'uso viene sviluppata nella parte iniziale dell'iterazione, alcune di queste proprietà potrebbero non esistere ancora.

Valutazione dei propri risultati

Verificare la Vista caso d'uso in questa fase per controllare che il lavoro procede come deve, ma non per analizzarla in dettaglio. Per consigli specifici su cosa cercare durante l'analisi, consultare Elenco di controllo: Documento dell'architettura software.

Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni