Attività: Analisi della funzionalità
Questa attività trasforma le descrizioni sulla funzionalità fornite dai requisiti in una serie di elementi su cui è possibile basare il progetto.
Estende: Analisi della funzionalità
DescrizioneElemento di interruzione del lavoroAssegnazione teamUtilizzo del prodotto di lavoro
Relazioni
Descrizione

Questa attività si verifica in ogni iterazione in cui ci sono requisiti comportamentali da analizzare e da progettare.

Le analisi dei requisiti comportamentali includono quanto segue:

  • identificazione delle classi di analisi che soddisfano la funzionalità richiesta
  • determinazione del modo in cui queste classi di analisi si adattano all'architettura logica (i sottosistemi principali e le classi) del sistema. Le classi di analisi possono essere determinate dall'appartenenza ai sottosistemi esistenti, richiedono la creazione di nuovi sottosistemi o comportano la ridefinizione di sottosistemi esistenti e delle loro interfacce.

Questa attività può includere anche la modellazione e la creazione del prototipo dell'interfaccia utente.

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

Specialmente nei progetti di grandi dimensioni, la progettazione dell'interfaccia utente e la creazione del prototipo viene eseguita separando gruppi di persone, focalizzando l'attenzione solo sull'utilizzabilità del sistema e dell'interfaccia utente. Tuttavia, questo gruppo deve lavorare in stretta collaborazione con altri membri del team di sviluppo, specialmente con quelli che sono responsabili dei requisiti e della logica aziendale, per essere certi che l'interfaccia utente sia quella che ci si aspetta e che la logica aziendale fornisca quello che l'interfaccia utente richiede (in termini di contenuto e di azioni dell'utente).

Il Compito: Analisi del caso d'uso viene condotta al meglio da un piccolo gruppo con un miscela di skill; le linee guida sulla formazione dello staff sono presentate in Linee guida: Workshop sull'analisi dei casi d'uso. Il Compito: Identificazione degli elementi del progetto richiede un'ampia prospettiva dell'architettura e dei risultati di altri workshop sull'analisi dei casi d'uso, e richiede un po' di esperienza nella tecnologia di implementazione e di eventuali framework utilizzati nel progetto. Le revisioni devono essere fatte da personale che abbia una profonda conoscenza delle tecnologie di implementazione nonché una comprensione del dominio del problema.

Utilizzo
Guida all'uso

Compito: Progettazione dell'interfaccia utente e Compito: Prototipizzazione dell'interfaccia utente vengono eseguiti in modo interattivo nelle iterazioni dell'elaborazione. Le iterazioni pongono l'attenzione sul progetto dell'interfaccia utente iniziale, che include l'identificazione e il progetto degli elementi di interfaccia utente chiave e i percorsi di navigazione tra di questi. La creazione di storyboard è una tecnica efficace che può essere utilizzata durante la progettazione dell'interfaccia utente per avere maggiori informazioni su come dovrebbe funzionare l'interfaccia utente. Una volta raggiunto il consenso del progetto interfaccia utente iniziale, allora inizia lo sviluppo di un prototipo interfaccia utente eseguibile . Il feedback sul prototipo ha un riscontro nel progetto dell'interfaccia utente (e possibilmente anche nei requisiti). Il prototipo iniziale generalmente supporta un sottoinsieme delle funzioni del sistema. Nelle iterazioni successive, è ingrandito, aggiungendo gradualmente una copertura più ampia di funzioni di sistema. Il vantaggio principale di produrre versioni non funzionali dell'interfaccia utente durante la progettazione dell'interfaccia utente è di rinviare l'impiego di prototipi interfaccia utente più elaborati e più costosi a quando esiste il consenso sul progetto interfaccia utente generale. È importante lavorare a contatto con gli utenti e gli utenti potenziali del sistema durante la progettazione e la creazione del prototipo dell'interfaccia utente per confermare e convalidare l'utilizzo del sistema.

Un numero di workshop di analisi del caso d'uso può essere organizzato in parallelo, limitato solo dal pool di risorsa disponibile e dalle abilità dei partecipanti. Appena possibile, seguendo ogni workshop di analisi del caso d'uso, alcuni membri del workshop e del team di architettura dovrebbero lavorare per unire i risultati del workshop in Identificazione elementi di progettazione. I membri di entrambi i team sono essenziali: i membri del team di analisi del caso d'uso comprendono il contesto nel quale le classi di analisi sono state identificate, mentre il team di architettura comprende il contesto più ampio del progetto e altri casi d'uso che sono già stati identificati.

Quando il lavoro del progetto si sviluppa e si stabilizza, parti sempre maggiori di questo possono e dovrebbero essere riviste. Revisioni più piccole, e più attente sono migliori rispetto alle grandi revisioni onnicomprensive; otto revisioni di due ore focalizzate su aspetti molto specifici sono molto meglio di una revisione singola che supera i due giorni. Nelle revisioni focalizzate, definire gli obiettivi per delimitare l'attenzione della revisione, e assicurare che un piccolo team di revisione con le capacità giuste per la revisione, dati gli obiettivi, sia disponibile per la revisione. Le revisioni anticipate si concentrano principalmente sull'integrità della stratificazione e dell'impacchettamento nel progetto, la stabilità e la qualità dell'interfaccia e la completezza di copertura del funzionamento del caso d'uso. Le revisioni più recenti dovrebbero analizzare i pacchetti e i sottosistemi per verificare che i contenuti realizzino in modo completo e corretto le interfacce definite e che le dipendenze e le associazioni tra gli elementi di progetto siano necessarie, sufficienti e corrette. Vedere i punti di controllo su ogni artefatto del progetto per i punti di revisione specifici.