Analisi

I casi d'uso perché usarli 2

Gian Maria Ricci — Wed, 16 Jul 2008 07:44:59 GMT

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.

I casi d'uso perchè usarli

Gian Maria Ricci — Tue, 15 Jul 2008 08:15:52 GMT

In un precedente post ho fatto una brevissima considerazione riguardo i casi d'uso, strumenti a mio avviso importantissimi nel processo di analisi e spesso invece poco conosciuti. Se dovessi dire la ragione numero 1 per cui vale la pena adottarli, a mio avviso è il basso livello di formalismo richiesto.

Non bisogna infatti dimenticare che il cliente/stakeholder non è un tecnico, è spesso restio a dover acquisire nuovi formalismi o strumenti e il suo vero interesse è solo avere un software che risponda alle sue esigenze. Il basso formalismo dei casi d'uso è quindi un facile strumento che può immediatamente essere appreso ed usato efficacemente dallo stakeholder, ma nonostante la sua semplicità può aiutare moltissimo nel processo di analisi.

alk.

I casi d’uso come strumento raccolta requisiti

Gian Maria Ricci — Fri, 16 Nov 2007 08:43:17 GMT

Nel post precedente ho parlato di come spesso la raccolta requisiti è svolta in maniera errata, portando poi a problemi in fase di sviluppo e alla classica sindrome di Penelope, in cui si fa e disfa il codice giorno dopo giorno. Quando si ha un problema e si vuole risolverlo, il modo migliore di partire è addossarsi la colpa e cercare di capire come migliorare; dire "il cliente non sa mai cosa vuole" è una scusa banale, e comunque non porta a nessuna soluzione.

Il modo corretto di porsi di fronte ad un problema è analizzarlo e trovare una soluzione. Nel caso del rapporto con il cliente, il problema principale è che il cliente effettivamente è spesso confuso sulle sue effettive necessità e quindi è dovere degli analisti cercare di carpire le informazioni al cliente. I casi d'uso in questo scenario si rivelano uno strumento eccezionale. Un caso d'uso può avere vari formati, ma è solitamente molto semplice da capire anche per una persona non tecnica. Se si seguono le regole base che potete trovare in qualsiasi testo dedicato all'argomento, il caso d'uso scorre bene e può essere letto anche dal nostro cliente che non ha mai visto un caso d'uso in vita sua.

L'analisi con i casi d'uso inoltre porta ad evidenti vantaggi, prima di tutto il cliente ha già da subito la sensazione di come funzionerà a grandi linee il software che si sta andando a costruire, si identificano gli attori e le parti del sistema, ma soprattutto mano a mano che si procede con l'analisi a "braccetto con il cliente", è più facile che le necessità emergano limitando il sintomo delle Macerie Nascoste, ed evitando che al momento della consegna il cliente lamenti funzionalità mancanti. La contrattazione delle funzionalità in questo caso è infatti fatta in maniera completamente trasparente evitando il classico sintomo dell'analista che: parla 1 ora con il cliente, stila un documento word spesso incompleto, lo fa firmare al cliente e da li si inizia la guerra della contrattazione con frasi del tipo "hai firmato il documento delle specifiche, ora ogni cambiamento si paga".

Chiaramente questo richiede, da parte degli analisti e dei project manager, l'essere disponibili a cambiare mentalità, realizzando che una sana contrattazione con uno Stakeholder deve basarsi su requisiti di: Trasparenza, Onestà e Collaborazione da entrambe le parti.

Alk

Technorati Tags: use cases