Analisi
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. 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: “Quando inserisco un Nuovo Candidato voglio avere una combo per scegliere il valore di XXX”. Prendere questo come requisito...
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. 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. La prima cosa che...
Nella gestione del ciclo di vita di un software la figura più importante è il cliente, anche se il termine esatto da usare sarebbe stakeholder. La definizione di wikipedia è Project stakeholders are those entities within or outside an organization which: a) Sponsor a project or. b) Have an interest or a gain upon a successful completion of a project. c) May have a positive or negative influence in the Project Completion. In sostanza gli stakeholder sono coloro che sono interessati...
In un recente post si sono aggiunti alcuni commenti con spunti interessanti e proprio stamattina ho letto un altro post di Luka molto interessante. 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. Questo conflitto spesso è determinato...
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...
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...
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...