analisi-disegno.com
All'inizio della mia attività di sviluppatore software avevo preso sul serio l'espressione "raccolta dei requisiti". Pensavo che qualcuno (l'utente) dovesse darli. E che quando esprimeva dubbi, incertezze, o si contraddiceva lo faceva perché era inadeguato. Era inesperienza, la mia.
In realtà, noi non riceviamo i requisiti. Non ci vengono dal cielo, come la manna nella Bibbia, e non spuntano sul terreno come i funghi o le margherite.
I requisiti si scoprono, non si raccolgono. Dobbiamo tirarli fuori. Usando tecniche appropriate. E non è facile. Perché anche per gli stakeholder, per il committente, per gli utenti, la definizione dei requisiti consiste in una progressiva acquisizione di conoscenza. Tutt'altro che banale.
Se si tratta di far evolvere un prodotto o un sistema già esistenti, è più facile. Usi il prodotto e ti viene in mente come potrebbe essere migliorato. Ma se si tratta di innovazione, di tirare fuori un nuovo prodotto o un nuovo servizio, o di cambiare un processo esistente, esprimere requisiti diventa più difficile.
E' una vera e propria legge: quanto è maggiore il livello di innovazione, tanto più è difficile chiarire i requisiti all'inizio del progetto.
Quindi per progetti innovativi non è possibile pensare che il chiarimento e la definizione dei requisiti avvengano a cascata, in una sola fase progettuale e in modo completo.
Piuttosto, è molto più efficace un approccio incrementale alla gestione dei requisiti, basato sulla costruzione di un nucleo iniziale del sistema e sulla realizzazione di incrementi successivi. E sulla raccolta dei feedback degli utenti - questa sì una raccolta, fondamentale per far evolvere il sistema in base alle effettive priorità.
*** UML e SysML - interoperabilità strumenti ***
Acquisire in uno strumento UML o SysML dei modelli creati con un altro strumento. Esigenza molto comune, per proteggere gli investimenti di modellazione precenenti nel momento in cui si decide di passare ad uno strumento diverso.
L'interoperabilità tra strumenti UML è stata possibile fin dalla partenza di UML, grazie allo standard di interscambio XMI (XML Model Interchange). Solo che il livello di interoperabilità era spesso poco soddisfacente.
Nel 2009 si è costituito, nell'ambito dell'Object Management Group (OMG), il Model Interchange Working Group (MIWG), che ha l'obiettivo di migliorare il livello di interscambio tra strumenti UML/SysML. Il gruppo ha comunicato i risultati dei propri lavori, che dimostrano un significativo miglioramento del livello di interscambio tra i prodotti:
http://www.omg.org/news/releases/pr2011/12-01-11.htm
*** Documentazione architetturale: un esempio ***
Un esempio di documentazione UML di architetture software, conforme alle indicazioni del libro "Documenting Software Architectures. Views and Beyond" è stato pubblicato da Paulo Merson e Darpan Saini.
L'esempio è disponibile sul sito del Software Engineering Institute: https://wiki.sei.cmu.edu/sad/index.php/The_Adventure_Builder_SAD
*** Casi d'uso 2.0 ***
Ivar Jacobson, ideatore dei casi d'uso, ha pubblicato una presentazione dal titolo "Use Case 2.0".
L'elemento più interessante è il concetto di "use case slice" (fetta di caso d'uso).
La "use case slice" corrisponde ad un insieme di scenari e di relativi casi di test da implementare in modo incrementale. Solo alcuni tra i possibili percorsi all'interno del caso d'uso, non tutti.
A volte può anche essere opportuno rilasciare la "slice" prima che l'intero caso d'uso sia completato, in quanto rappresenta già da sola un elemento di valore per gli utenti del sistema. In questo modo lo sviluppo di "slice" successive si coniuga efficacemente con gli approcci iterativi e incrementali.
http://www.ivarjacobson.com/resource.aspx?id=1225 (è necessario fornire un indirizzo email)
*** Do you inspect? ***
Perché le verifiche sistematiche (ispezioni) su documenti di progetto e su codice vengono usate così poco, visto che sono il metodo più efficace ed efficiente per rimuovere difetti nei prodotti software?
Capers Jones e Olivier Bonsignour danno la loro risposta, verosimile: perché non c'è nessun interesse commerciale a promuoverle:
http://drdobbs.com/architecture-and-design/231903203?pgno=1
Se volete, potete contribuire ad ANALISI-DISEGNO:
ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita e regolare.
Archivio notiziari | Notiziario precedente | Notiziario successivo
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.