Analisi http://blogs.ugidotnet.org/rgm/category/Analisi.aspx Analisi it-IT Gian Maria Ricci Subtext Version 2.6.0.0 Dominio del problema / dominio della soluzione http://blogs.ugidotnet.org/rgm/archive/2011/03/08/dominio-del-problema-dominio-della-soluzione.aspx <p>Durante l’analisi spesso la confusione tra i due domini causa problemi, questo perché spesso chi fa l’analista non è un vero analista, (nel peggiore dei casi è uno sviluppatore) e quindi tende sempre a vedere la soluzione prima del problema.</p> <p>Il buon analista invece conosce la distinzione e durante la raccolta dei requisiti non cade nella trappola di “sbirciare alla possibile soluzione”. Prendiamo un esempio: l’utente o comunque la persona che stiamo intervistando per l’elicitazione dei requisiti dice:</p> <p><em>“Quando inserisco un Nuovo Candidato voglio avere una combo per scegliere il valore di XXX”.</em></p> <p>Prendere questo come requisito è probabilmente sbagliato, sia perché si parla già di interfaccia utente, ma soprattutto può incorrere in problemi dovuti ad un’analisi insufficiente. Supponiamo infatti che XXX sia “il comune di residenza”…. in questo caso avremmo una combo con tutti i comuni italiani.. una situazione tipicamente difficile da gestire nella UI e sicuramente <i><strong>non usabile</strong></i>.</p> <p>L’analista dovrebbe quindi chiedere alla persona il perché stia parlando proprio di una combo, questo perché la <em>Combo</em> fa parte del dominio della soluzione, quindi è necessario capire il vero requisito che si nasconde in questa possibile soluzione. Il vantaggio è che in questo modo capiamo realmente le ragioni che portano alla “combo”. </p> <blockquote> <p><i>nel vecchio sistema avevamo una casella di testo e perdevamo un sacco di tempo per errori di digitazione,una combo impedisce di mettere valori non validi per cui non avremo più gente che abita a Molano :)</i></p> </blockquote> <p>Ora siamo più vicini al vero requisito, che potrebbe essere</p> <blockquote> <p><i>L’inserimento del comune di residenza deve essere effettuato tramite la scelta tra X valori possibili e non tramite inserimento libero, perché questo ha creato problemi con il vecchio sistema.</i></p> </blockquote> <p>Ora l’analista deve andare più a fondo e chiedere ad esempio:<em> dato che è possibile che ci siano nuovi comuni che vengono creati nel tempo, o comunque supponendo che la lista comuni sia errata, non è proprio possibile per l’utente inserire un valore libero</em>? Si potrebbe magari scoprire che in realtà quello che si vuole è solamente un avvertimento che dica all’utente “Il comune XXX non è presente nell’archivio, verificare errori di digitazione”, ma che sia comunque possibile poi andare avanti. A questo punto il requisito diventa</p> <blockquote> <p>E’ necessario che prima dell’inserimento dei dati a sistema sia fatto un errore per il controllo di eventuali errori di digitazione per campi specifici.</p> </blockquote> <p>A questo punto possiamo spostarci nel dominio della soluzione e trovare una soluzione migliore della combobox inizialmente citata, come ad esempio una texbox Ajax che alla digitazione di tre lettere presenta la lista dei comuni compatibili. L’utente può scrivere però quello che vuole, ed alla perdita del focus, se il comune non è in archivio appare un messaggio di “attenzione comune non presente nell’archivio” e l’utente è poi libero di seguire o meno il consiglio.</p> <p>Evitare di scambiare la soluzione per il problema è quindi fondamentale quando si raccolgono i requisiti.</p> <p>alk.</p><div class="wlWriterHeaderFooter" style="text-align:left; margin:0px; padding:4px 4px 4px 4px;"><a href="http://www.dotnetkicks.com/kick/?url=http://blogs.ugidotnet.org/rgm/archive/2011/03/08/dominio-del-problema-dominio-della-soluzione.aspx"><img src="http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=http://blogs.ugidotnet.org/rgm/archive/2011/03/08/dominio-del-problema-dominio-della-soluzione.aspx&amp;bgcolor=0080C0&amp;fgcolor=FFFFFF&amp;border=000000&amp;cbgcolor=D4E1ED&amp;cfgcolor=000000" alt="DotNetKicks Image" border="0/" /></a></div><img src="http://blogs.ugidotnet.org/rgm/aggbug/99790.aspx" width="1" height="1" /> Gian Maria Ricci http://blogs.ugidotnet.org/rgm/archive/2011/03/08/dominio-del-problema-dominio-della-soluzione.aspx Tue, 08 Mar 2011 20:38:22 GMT http://blogs.ugidotnet.org/rgm/archive/2011/03/08/dominio-del-problema-dominio-della-soluzione.aspx#feedback 4 http://blogs.ugidotnet.org/rgm/comments/commentRss/99790.aspx http://blogs.ugidotnet.org/rgm/services/trackbacks/99790.aspx Test dei requisiti http://blogs.ugidotnet.org/rgm/archive/2010/08/24/test-dei-requisiti.aspx <p>Quando si parla di testing, quasi sempre si pensa a procedure che operano su un programma o comunque su uno scheletro di una applicazione, spesso purtroppo si tralascia la fase di testing durante la raccolta dei requisiti.</p> <p>Dato che nella fase di raccolta requisiti non si ha ancora nemmeno una singola riga di codice, viene naturale pensare che non sia possibile “testare” nulla, ma invece è importante eseguire un cicolo di test anche sui requisiti stessi, anche perchè i bug che si annidano nei requisiti sono quelli che portano più danni al progetto. </p> <p>La prima cosa che si deve verificare è che le specifiche raccolte <em>individuino realmente il problema</em>, la domanda è “questi requisiti sono quelli <strong>giusti</strong>?”. Rispondere a questa domanda è difficile, quello che si dovrebbe fare è avere raccolto i requisiti su di un software o comunque in modo omogeneo, e rivederli assieme agli stakeholder, per capire se si è dimenticato qualche aspetto fondamenale e se si è ben compreso il nocciolo del problema. </p> <p>In questo scenario i casi d’uso sono molto utili, perchè presentano una descrizione testuale dei requisiti, possono essere letti dal cliente e non necessitano di prerequisiti particolari per essere compresi. Durante il test dei casi d’uso particolare attenzione va prestata non tanto al percorso principale di successo (Main Success Scenario), ma piuttosto alle estensioni e alle eccezioni.</p> <p>Un esempio pratico potrebbe essere il seguente. Se abbiamo un caso d’uso relativo ad una picking list di un magazziniere potremmo avere un main success scenario di questo tipo</p> <ol> <li>Il magazziniere chiede al sistema l’ordine successivo da processare</li> <li>Il sistema invia l’ordine costituito da una lista di oggetti</li> <li>Il magazziniere preleva i pezzi in sequenza, per ogni pezzo legge il suo codice a barre</li> <li>il sistema valida il codice a barre ed indica la quantità prelevata</li> <li>Si ripetono le operazioni 3 e 4 fino a che l’ordine non è completo</li> <li>Quando l’ordine è completo il sistema mostra un segnale a schermo ed impedisce la lettura di ulteriori pezzi</li> <li>Il magazzinere impacchetta i pezzi in un imballo e legge il codice dell’imballo</li> <li>Il sistema chiude la spedizione.</li> </ol> <p>In questo caso testare questo caso d’uso consiste prima di tutto nel verificare con un magazziniere che questa sia effettivamente la sequenza di operazioni necessaria per l’invio di un ordine, successivamente è necessario iniziare a verificare i percorsi alternativi. Il testing di un caso d’uso spesso consiste semplicemente nel pensare cosa “può andare storto” nel main success scenario, al fine di individuare percorsi alternativi. In pratica si inizia a porre domande di questo tipo:</p> <ul> <li>Cosa succede se il magazziniere legge un pezzo che non è in ordine?</li> <li>Cosa succede se la connessione del palmare cade ed il device non riesce più a raggiungere il server principale?</li> <li>Cosa succede se il magazziniere dimentica di leggere un codice a barre e quindi vede nel suo cestino tutti i pezzi ma il sistema sostiene che ne manca ancora uno?</li> <li>Cosa succede se l’ultimo pezzo disponibile di un dato oggetto ha il codice a barre rovinato e non riesce ad essere letto dal lettore?</li> </ul> <p>Pensare a questi problemi durante la fase di raccolta requisiti e catalogarli sul caso d’uso come percorso alternativo è una buona pratica, perchè è possibile ancora affrontare i problemi da un punto di vista concettuale. Quello che spesso accade invece è che le problematiche vengono rilevate con i primi prototipi, o ancora peggio con il software in produzione, aumentando in maniera enorme il costo di risoluzione.</p> <p>In altre situazioni il test può essere costituito da una simulazione su carta. Se ad esempio si deve dialogare con un vecchio sistema legacy e si è scelto di utilizzare una tabella di un database come canale di scambio informazioni, è utile iniziare a simulare su carta una sequenza di dialogo. Troppo spesso in questi casi la specifica cita solamente “verrà usata una tabella di un database condiviso per scambiare dati” poi ci si accorge durante lo sviluppo che si richiede una trasmissione veloce e quasi real-time, oppure che il processo logico scelto per la comunicazione ha delle falle. Anche in questo caso è utile “testare” la comunicazione prendendo un foglio di carta o un documento ed iniziando a simulare passo dopo passo cosa viene scritto nella tabella di scambio, chiedendo poi ai responsabili di entrambe le parti se pensano che ci possa essere un problema. </p> <p>Ujna attenta verifica/testing dei requisiti può evitare molte grane in fase di sviluppo. :)</p> <p>Alk.</p><div class="wlWriterHeaderFooter" style="text-align:left; margin:0px; padding:4px 4px 4px 4px;"><a href="http://www.dotnetkicks.com/kick/?url=http://blogs.ugidotnet.org/rgm/archive/2010/08/24/test-dei-requisiti.aspx"><img src="http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=http://blogs.ugidotnet.org/rgm/archive/2010/08/24/test-dei-requisiti.aspx&amp;bgcolor=0080C0&amp;fgcolor=FFFFFF&amp;border=000000&amp;cbgcolor=D4E1ED&amp;cfgcolor=000000" alt="DotNetKicks Image" border="0/" /></a></div><img src="http://blogs.ugidotnet.org/rgm/aggbug/99105.aspx" width="1" height="1" /> Gian Maria Ricci http://blogs.ugidotnet.org/rgm/archive/2010/08/24/test-dei-requisiti.aspx Tue, 24 Aug 2010 10:42:00 GMT http://blogs.ugidotnet.org/rgm/archive/2010/08/24/test-dei-requisiti.aspx#feedback 4 http://blogs.ugidotnet.org/rgm/comments/commentRss/99105.aspx http://blogs.ugidotnet.org/rgm/services/trackbacks/99105.aspx Chi &egrave; il cliente nella gestione dell&rsquo;ALM? http://blogs.ugidotnet.org/rgm/archive/2010/07/30/chi-egrave-il-cliente-nella-gestione-dellrsquoalm.aspx <p>Nella gestione del ciclo di vita di un software la figura più importante è il <em>cliente</em>, anche se il termine esatto da usare sarebbe <em>stakeholder. </em>La definizione di wikipedia è </p> <blockquote> <p><b>Project stakeholders</b> are those entities within or outside an <a href="http://en.wikipedia.org/wiki/Organization">organization</a> which:</p> <p>a) Sponsor a project or. <br />b) Have an interest or a gain upon a successful completion of a project. <br />c) May have a positive or negative influence in the Project Completion.</p> </blockquote> <p>In sostanza gli stakeholder sono coloro che sono interessati alla realizzazione del progetto stesso, senza i quali il software non esisterebbe. Formalizzare il concetto di <em>stakeholder </em>è importante, perchè troppo spesso si considera <em>cliente</em> solo chi <strong>mette i soldi</strong> oppure in generale chi <strong>commissiona il software</strong>, dimenticando completamente altre figure più importanti. Le categorie di persone che fanno parte degli stakeholder possono essere identificate a grandi linee in:</p> <ol> <li>Chi paga per il prodotto</li> <li>Chi lo ha richiesto</li> <li>Chi conosce il <em>dominio del problema </em></li> <li>Chi lo usa</li> <li>Chi interagisce con l’output del prodotto stesso.</li> </ol> <p>Purtroppo spesso solo i punti 1 e 2 sono considerati come clienti, provocando problemi nel raccoglimento delle specifiche dato che sono gli unici ad essere contattati dagli analisti. Dal punto di vista della raccolta requisiti infatti ogniuna di queste figure deve essere coinvolta per raccogliere tipologie differenti di requisiti.</p> <p>Gli stakeholder del punto 1 e 2 forniscono la <strong>visione del progetto</strong>  e sono in grado di <strong>dare la direzione principale</strong> da seguire cosi come una sommaria descrizione delle <strong>regole di business</strong>.</p> <p>Gli stakeholder del punto 3 forniscono invece le specifiche dettagliate sulle <strong>regole di business</strong> che il software deve implementare. Questa categoria di stakeholder è solitamente quella che realmente preme per realizzare il prodotto stesso, ed è rappresentata da coloro che hanno la necessità di creare il prodotto stesso. In questa categoria risiedono gli “esperti di dominio” ed una figura di questa categoria dovrebbe essere sempre presente o contattabile da tutto il team per dirimere eventuali dubbi durante lo sviluppo.</p> <p>Gli stakeholder del punto 4 sono invece gli utenti, dai quali vanno ricavati gli <strong><a href="http://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258">use case</a> </strong>a livello utente del sistema, ed eventuali mockup. In questa categoria troviamo anche le figure che dovrebbero validare l’usabilità del sistema. Il problema classico è che spesso queste persone non sono contattate per nulla, sebbene siano coloro che utilizzeranno fisicamente il sistema. Il nostro sistema infatti può implementare perfettamente le <strong>regole di business</strong>, ma essere poco usabile perchè ad esempio per compiere le operazioni più comuni richiede un numero elevato di interazioni con l’interfaccia utente.</p> <p>Gli stakeholder del punto 5 infine non sono sempre presenti, ma in alcuni casi sono invece molto importanti. Se ad esempio un software deve generare un output da spedire a tutti i fornitori, sarebbe necessario raccogliere da loro alcune specifiche sommarie sui formati attesi, invece di creare una esportazione xml e scoprire che il 90% dei fornitori utilizza un formato CSV. Se un programma deve generare delle informazioni da passare ad un altro dipartimento di un azienda che usa SAP, è doveroso contattare una persona di tale dipartimento per determinare come scambiare i dati.</p> <p>Queste piccole considerazioni fanno capire come la raccolta requisiti coinvolga molteplici figure, ma spesso gli stakeholder non vogliono spendere tempo con gli analisti, presupponendo che chi realizza il software sia in grado di lavorare da solo sulla base di specifiche vage del tipo: “ci serve un software di gestione magazzino da installare nel palmare dei magazzinieri”.</p> <p>Tra le regole di <a href="http://www.extremeprogramming.org/rules.html">Extreme programming</a> vi è infatti un <a href="http://www.extremeprogramming.org/rules/customer.html">contatto costante con il cliente</a>, e si richiede di avere sempre almeno uno Stakeholder che lavora a fianco con il team. Anche in Scrum e nei processi iterativi gli stakeholder sono sempre necessari, perchè vengono resi partecipi del risultato di ogni iterazione o sprint e della riprioritizzazione dei requisiti ad ogni iterazione/sprint.</p> <p>Sebbene coinvolgere molti stakeholder nel progetto sia difficile, è fondamentale se si vuole avere una elicitazione dei requisiti completa e non parziale. Dato che in <a href="http://www.ibm.com/developerworks/rational/library/347.html">letteratura</a> troviamo <a href="http://www.amazon.com/Software-Requirements-Objects-Functions-Revised/dp/013805763X">molti</a> esempi che mostrano come il 40% o più dei difetti di un software può essere ricondotto ad errori fatti durante la raccolta dei requisiti, viene da se che gli investimenti nel migliorare questo settore porterebbero sicuramente benefici, anche nel breve termine.</p> <p>alk.</p><div class="wlWriterHeaderFooter" style="text-align:left; margin:0px; padding:4px 4px 4px 4px;"><a href="http://www.dotnetkicks.com/kick/?url=http://blogs.ugidotnet.org/rgm/archive/2010/07/30/chi-egrave-il-cliente-nella-gestione-dellrsquoalm.aspx"><img src="http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=http://blogs.ugidotnet.org/rgm/archive/2010/07/30/chi-egrave-il-cliente-nella-gestione-dellrsquoalm.aspx&amp;bgcolor=0080C0&amp;fgcolor=FFFFFF&amp;border=000000&amp;cbgcolor=D4E1ED&amp;cfgcolor=000000" alt="DotNetKicks Image" border="0/" /></a></div><img src="http://blogs.ugidotnet.org/rgm/aggbug/99020.aspx" width="1" height="1" /> Gian Maria Ricci http://blogs.ugidotnet.org/rgm/archive/2010/07/30/chi-egrave-il-cliente-nella-gestione-dellrsquoalm.aspx Fri, 30 Jul 2010 10:24:39 GMT http://blogs.ugidotnet.org/rgm/archive/2010/07/30/chi-egrave-il-cliente-nella-gestione-dellrsquoalm.aspx#feedback 13 http://blogs.ugidotnet.org/rgm/comments/commentRss/99020.aspx http://blogs.ugidotnet.org/rgm/services/trackbacks/99020.aspx Rapporti con il cliente&ndash;questi sconosciuti http://blogs.ugidotnet.org/rgm/archive/2010/07/27/rapporti-con-il-clientendashquesti-sconosciuti.aspx <p>In un <a href="http://blogs.ugidotnet.org/rgm/archive/2010/07/24/lrsquoimportanza-dei-requisiti.aspx">recente post</a> si sono aggiunti alcuni commenti con spunti interessanti e proprio stamattina ho letto un altro post di Luka molto <a href="http://blogs.ugidotnet.org/luKa/archive/2010/07/26/two-ways-of-looking-at-the-same-problem.aspx">interessante</a>. Uno degli errori più macroscopici che si fanno solitamente durante lo sviluppo è quello di creare contrapposione tra dev e cliente. Tipicamente quando il cliente chiede una modifica, lo sviluppatore si sente frustrato e spesso accusa il cliente con frasi del tipo: “non sa mai cosa vuole”, “non è in grado di capire che cosi è meglio”, “debbo rifare tutto per colpa del cliente”, e potrei continuare ancora a lungo.</p> <p>Questo conflitto spesso è determinato dal mancato contatto cliente / dev, che viene solitamente mediato da figure di “Analisti Marchettari”, ovvero persone che vanno dal Cliente non con lo scopo di raccogliere veramente requisiti e fare gli analisti, ma piuttosto per “Vendere” un prodotto. Qui spesso si cela il male perchè il ciclo di sviluppo adottato molto spesso è</p> <p>1) andare dal cliente, cercare di capire alcune vaghe specifiche <br />2) vendere al cliente il proprio prodotto, convincendo il cliente che si è capito quello di cui ha bisogno <br />3) gettare le vaghe specifiche in una stanza con X sviluppatori <br />4) periodicamente aprire la porta di suddetta stanza e chiedere “è pronto?”. <br />5) quando si ha qualche cosa di più o meno funzionante lo si fa vedere al cliente</p> <p>quindi in sostanza non si ha nessun processo, è come costruire una casa senza progetto, prendendo X persone e dando loro calce e mattoni.</p> <p>Molto spesso inoltre le specifiche sono fumose e non sono corrette, principalmente perchè non le si è nemmeno cercate, ma le si è imposte al cliente stesso. Al termine il cliente ha un prodotto che non è quello che vuole e chiaramente inizia a chiedere cambiamenti creando quindi attrito con gli sviluppatori. La frustrazione maggiore è vedere il tempo perso ad implementare cose inutili.</p> <p>Se non si ha il controllo sul processo, ovvero se siamo meramente le persone nella stanza, è comunque utile adottare un approccio più costruttivo, e come nel link citato da Luka invece di dire “It’s Them” preferiamo dire “It’s all of us”. Lo scopo è quello di cercare di coinvolgere il più possibile il cliente nel processo, con la maggiore trasparenza possibile, e soprattutto continuando per tutto il corso del progetto a cercare di elicitare i requisiti con il cliente stesso. </p> <p>Cerchiamo quindi magari di convincere l’analista a parlare periodicamente con il cliente, facendo vedere il lavoro svolto fino a quel punto, e cercando strumenti che permettano di “aiutare” il cliente a capire cosa vuole (casi d’uso, mockup, prototipi, interviste).</p> <p>Lo scopo finale è quello di soddisfare il cliente, per cui ogni richiesta di cambiamento è lecita. Se adottiamo questo modo di pensare, probabilmente ci si eviterebbero arrabbiature… d’altra parte “Il cliente ha sempre ragione”</p> <p>Alk.</p><div class="wlWriterHeaderFooter" style="text-align:left; margin:0px; padding:4px 4px 4px 4px;"><a href="http://www.dotnetkicks.com/kick/?url=http://blogs.ugidotnet.org/rgm/archive/2010/07/27/rapporti-con-il-clientendashquesti-sconosciuti.aspx"><img src="http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=http://blogs.ugidotnet.org/rgm/archive/2010/07/27/rapporti-con-il-clientendashquesti-sconosciuti.aspx&amp;bgcolor=0080C0&amp;fgcolor=FFFFFF&amp;border=000000&amp;cbgcolor=D4E1ED&amp;cfgcolor=000000" alt="DotNetKicks Image" border="0/" /></a></div><img src="http://blogs.ugidotnet.org/rgm/aggbug/98997.aspx" width="1" height="1" /> Gian Maria Ricci http://blogs.ugidotnet.org/rgm/archive/2010/07/27/rapporti-con-il-clientendashquesti-sconosciuti.aspx Tue, 27 Jul 2010 15:29:59 GMT http://blogs.ugidotnet.org/rgm/archive/2010/07/27/rapporti-con-il-clientendashquesti-sconosciuti.aspx#feedback 4 http://blogs.ugidotnet.org/rgm/comments/commentRss/98997.aspx http://blogs.ugidotnet.org/rgm/services/trackbacks/98997.aspx I casi d'uso perch&eacute; usarli 2 http://blogs.ugidotnet.org/rgm/archive/2008/07/16/93420.aspx <p>Nel <a href="http://blogs.ugidotnet.org/rgm/archive/2008/07/15/93407.aspx">precedente</a> post si parlava di semplicità e basso formalismo come vantaggio dei casi d'uso, ma i vantaggi non si fermano li.</p> <p>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</p> <ol> <li>Cosa può andare storto nel flusso principale </li> <li>Come reagire a queste anomalie e che percorso alternativo prendere </li> </ol> <p>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.</p> <p>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. </p> <p>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.</p> <p>Un caso d'uso fatto bene avrebbe sicuramente evidenziato questo problema in fase di analisi e non in fasi sucessive.</p> <p>alk.</p><img src="http://blogs.ugidotnet.org/rgm/aggbug/93420.aspx" width="1" height="1" /> Gian Maria Ricci http://blogs.ugidotnet.org/rgm/archive/2008/07/16/93420.aspx Wed, 16 Jul 2008 10:44:59 GMT http://blogs.ugidotnet.org/rgm/archive/2008/07/16/93420.aspx#feedback http://blogs.ugidotnet.org/rgm/comments/commentRss/93420.aspx http://blogs.ugidotnet.org/rgm/services/trackbacks/93420.aspx I casi d'uso perch&egrave; usarli http://blogs.ugidotnet.org/rgm/archive/2008/07/15/93407.aspx <p>In un <a href="http://blogs.ugidotnet.org/rgm/archive/2007/11/16/89724.aspx">precedente post</a> 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. </p> <p>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.</p> <p>alk. </p> <div class="wlWriterSmartContent" id="scid:C16BAC14-9A3D-4c50-9394-FBFEF7A93539:f48e6242-b9eb-4bbb-83a3-f96b57664dd5" style="padding-right: 0px; display: inline; padding-left: 0px; padding-bottom: 0px; margin: 0px; padding-top: 0px"><!--dotnetkickit--></div><img src="http://blogs.ugidotnet.org/rgm/aggbug/93407.aspx" width="1" height="1" /> Gian Maria Ricci http://blogs.ugidotnet.org/rgm/archive/2008/07/15/93407.aspx Tue, 15 Jul 2008 11:15:52 GMT http://blogs.ugidotnet.org/rgm/archive/2008/07/15/93407.aspx#feedback 1 http://blogs.ugidotnet.org/rgm/comments/commentRss/93407.aspx http://blogs.ugidotnet.org/rgm/services/trackbacks/93407.aspx I casi d’uso come strumento raccolta requisiti http://blogs.ugidotnet.org/rgm/archive/2007/11/16/89724.aspx <p>Nel <a href="http://blogs.ugidotnet.org/rgm/archive/2007/11/15/89707.aspx">post precedente</a> 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. </p> <p>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 è <em>dovere degli analisti </em>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 <a href="http://www.guisa.it/forums/thread/1326.aspx">vari formati</a>, ma è solitamente molto semplice da capire anche per una persona non tecnica. Se si seguono le regole base che potete trovare in <a href="http://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258/ref=pd_bbs_sr_1?ie=UTF8&amp;s=books&amp;qid=1195201925&amp;sr=8-1">qualsiasi testo</a> 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. </p> <p>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". </p> <p>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. </p> <p>Alk </p> Technorati Tags: <a rel="tag" href="http://technorati.com/tag/use+cases">use cases</a><img src="http://blogs.ugidotnet.org/rgm/aggbug/89724.aspx" width="1" height="1" /> Gian Maria Ricci http://blogs.ugidotnet.org/rgm/archive/2007/11/16/89724.aspx Fri, 16 Nov 2007 10:43:17 GMT http://blogs.ugidotnet.org/rgm/archive/2007/11/16/89724.aspx#feedback 2 http://blogs.ugidotnet.org/rgm/comments/commentRss/89724.aspx http://blogs.ugidotnet.org/rgm/services/trackbacks/89724.aspx