I casi d'uso non sono tutto.
No, UP è un metodo iterativo ed evolutivo, dunque la programmazione e il test devono iniziare molto presto, molto tempo prima che la maggior parte dei requisiti siano stati analizzati completamente o registrati. Il feedback proveniente dalla programmazione anticipata e dai test contribuisce all'evoluzione dei requisiti.
Tuttavia le ricerche dimostrano che è utile avere una "top-ten" di alto livello relativo ai requisiti a grana grossa. Utile è, inoltre, dedicare del tempo iniziale (non irrilevante) alla comprensione dei requisiti non funzionali (come prestazioni e affidabilità), poiché questi hanno un impatto significativo sulle scelte architetturali.
Gli esempi di requisiti scritti che seguono potrebbero dare l'illusione che i veri requisiti siano stati compresi e ben definiti, e possano essere utilizzati (nella fase iniziale) per fare delle stime affidabili e nella pianificazione del progetto. Questa illusione è più forte per coloro che non si intendono di sviluppo software, mentre i programmatori con esperienza sanno quanto essa sia menzognera.
Studi dimostrano che il 50% dei requisiti iniziali dei progetti stilati con approccio a cascata non vengono mai usati in un sistema sviluppato.
Ciò che è importante è cominciare presto a scrivere del codice che superi i test di accettazione definiti dagli utenti e che risponda ai loro veri obiettivi. Gli obiettivi, spesso, non vengono scoperti fino a quando non si comincia lo sviluppo del sistema.
Scrivere una Visione e delle Specifiche supplementari è un esercizio significativo per chiarire una prima approssimazione di ciò che si desidera, le motivazioni per il prodotto, e anche come "deposito" per le idee principali. Questi elaborati non sono una specifica affidabile, come non lo è nessun elaborato dei requisiti. Solo la scrittura del codice, i test, il feedback, una collaborazione stretta e continua con gli utenti e i clienti, e l'adattamento consentono di centrare veramente l'obiettivo.
Non è un invito ad abbandonare l'analisi e la riflessione per affrettarsi a iniziare a scrivere il codice, ma un suggerimento a trattare con "leggerezza" i requisiti scritti.
Come abbiamo visto nel file Linea guida - scrivere in uno stile essenziale, senza riferimento all'interfaccia utente, vediamo adesso quale potrebbe essere il processo e le tempistiche con cui potrebbero essere scritti i requisiti elencati all'inizio di questo file.
Ricordiamo, ancora una volta, che UP è un processo iterativo ed evolutivo, quindi i requisiti di qualsiasi genere non sono analizzati fino in fondo fin dall'inizio, ma vengono definiti nel corso del tempo e dei vari workshop che vengono fatti attraverso il feedback degli utenti e dei test.
| 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 (SSD) | i | r | ||
| Visione | i | r | |||
| Specifiche supplementari | i | r | |||
| Glossario | i | r | |||
| Regole di Business | i | r | |||
| Progettazione | Modello di progetto | i | r | ||
| Documento dell'architettura | |||||
| Software | i | ||||
| Modello dei dati | i | r |
Fase di ideazione
In questa fase, le parti interessate devono decidere se il progetto merita un'indagine seria, questa indagine avviene durante l'elaborazione, non l'ideazione. Durante l'ideazione il documento di Visione riassume l'idea del progetto in una forma che aiuta chi deve prendere le decisioni a stabilire se vale la pena di continuare e da dove iniziare.
Poiché la maggior parte dell'analisi dei requisiti avviene durante l'elaborazione, le Specifiche Supplementari devono essere sviluppare solo in modo leggere durante l'ideazione, evidenziando gli attributi di qualità significativi che presentano i rischi e le difficoltà principali (per esempio, il POS NextGen deve avere una capacità di ripristino quando i servizi esterni falliscono).
L'input per questi elaborati potrebbe essere generato durante un seminario sui requisiti della fase di ideazione.
Fase di elaborazione
Attraverso le iterazioni di elaborazione, la "visione" e il documento di Visione vengono raffinati, sulla base del feedback proveniente dalla costruzione incrementale di parti del sistema, dall'adattamento e dai vari workshop sui requisiti tenuti nel corso delle diverse iterazioni di sviluppo.
Attraverso l'indagine continua dei requisiti e lo sviluppo iterativo, gli altri requisiti diventeranno più chiari e potranno essere registrati nelle Specifiche Supplementari.
Verso la fine dell'elaborazione, è possibile avere dei casi d'uso, Specifiche Supplementari e Visione che riflettono in modo ragionevole le caratteristiche principali e gli altri requisiti stabilizzati che devono essere completati per la consegna. Tuttavia le Specifiche Supplementari e il documento Visione non devono essere congelati e firmati per accettazione come specifiche fissate definitivamente. L'adattamento è uno dei punti cardine di UP e dei metodi di sviluppo iterativi.
Il punto è che ha senso ad un certo punto, alla fine dell'elaborazione, stipulare un accordo formale (magari con un contratto) e assumersi degli impegni riguardo le tempistiche e i requisiti del sistema. Tuttavia il congelamento e la firma per accettazione implica alcune considerazioni:
Fase di costruzione
Per la costruzione, i requisiti principali, funzionali o meno, dovrebbero essere stati stabilizzati (anche se non finalizzati, ma soggetti solo a variazioni minori). Pertanto, è improbabile che le Specifiche Supplementari e il documento Visione subiscano molti cambiamenti.