Nel precedente post si parlava di semplicità e basso formalismo come vantaggio dei casi d'uso, ma i vantaggi non si fermano li.
Personalmente il secondo grande punto di forza dei casi d'uso è che, grazie alla stesura dei percorsi alternativi al flusso principale, obbligano sviluppatori e clienti a pensare a
- Cosa può andare storto nel flusso principale
- Come reagire a queste anomalie e che percorso alternativo prendere
Queste cose spessissimo invece sono prese sottogamba, ci si concentra sull'implementare il flusso principale di una operaizione, e poi ci si accorge durante i test, o peggio in produzione, che non sempre il mondo è ideale.
Un caso pratico: Un utente deve inserire un certo numero di informazioni, composte da un certo numero di step, al termine deve avere un riepilogo di tutto quello che è stato inserito e confermare l'inserimento in blocco di tutte le informazioni. L'implemnetazione tramite web.form memorizza i dati dei vari passi in sessione.
Ad un certo punto ci si accorge che gli utenti sono persone che si connettono con portatili e schede UMTS o simili, quindi spesso cade la linea, è fondamentale che l'utente non debba reinserire tutto daccapo e che il sistema al successivo login lo riporti al punto dove era quando la connessione era caduta. Purtroppo accorgersi di questo con il software fatto, significa prendere ed andare a mettere delle "toppe", questo perchè chiaramente non si ha tempo per riprogettare il tutto per questa nuova specifica. La situazione spesso porta gli sviluppatori a lamentarsi con il cliente perchè "il cliente non sa mai cosa vuole" quando in realtà è comunque dell'analista il compito di capire realmente le necessità del cliente.
Un caso d'uso fatto bene avrebbe sicuramente evidenziato questo problema in fase di analisi e non in fasi sucessive.
alk.