Torna alla pagina di Ingegneria del Software
:: Ingegeneria del software - Appunti del 9 marzo 2009 ::
Partiamo subito ribadendo il concetto che, se i requisiti sono stati raccolti male, allora quasi sicuramente il progetto fallisce. Ecco perché vanno raccolti e sistemati per bene.
La scala di priorità must - should - may è ovviamente soggettiva ma molto utile: occorre sempre tenere a mente che l'unico giudice del prodotto finito sarà il cliente, e il cliente ha sempre ragione.
Gli utenti finali del software molto probabilmente non sono dei tecnici. Ma non ci interessano solo gli utenti, bensì gli stakeholder, cioè tutti quelli che hanno un qualche interesse o una qualche parte nel progetto sw. Ovviamente quelli più importanti sono gli utenti, perché saranno loro ad avere in mano il sw alla fine.
Il problema è che non tutti gli utenti sono in grado di avere un'idea chiara su quello che deve fare il sw, e altre volte possono essere addirittura ostili, per varie ragioni, alla creazione del sw stesso. Gli ingegneri del software hanno inventato un po' di sistemi per andare in giro ad intervistare gli utenti e trarne informazioni utili senza farsi fermare dalla loro ostilità o dalla loro ignoranza in materia.
L'idea di questo sistema è che sono gli analisti a fare la maggior parte del lavoro di specifica dei requisiti, quindi persone che conoscono molto bene il dominio del software. Si fanno raccontare le esigenze degli utenti, e poi si riuniscono e decidono loro priorità, dipendenze etc. Possiamo dire che questo è un sistema developers power, proprio perché sono gli sviluppatori a fare la parte del leone nel decidere che cosa il sw deve fare.
Naturalmente i developers non possono inventarsi tutto di sana pianta: devono comunque avere un contatto nel mondo degli utenti. Questo contatto viene chiamato user liaison, e si tratta di una persona che viene considerata come la fonte da cui trarre le informazioni per i requisiti. E' importante che questa fonte rimanga sempre la stessa, perché è facile che utenti diversi abbiano visioni discordanti se non contraddittorie dello stesso sistema. Inoltre, occorre anche stare attenti a chi scegliere come liaison: se capiamo male i requisiti e il sw fallisce, allora la colpa sarà data solo a noi (noi intesi come sviluppatori). Ecco perché serve scegliere la fonte migliore possibile, altissima purissima e levissima.
Con questo sistema abbiamo un rappresentante del committente che prende su le valigie e si trasferisce, per tutta la durata della realizzazione del sistema, presso gli sviluppatori. Questo rappresentante in pratica diviene membro del team di sviluppo a tempo pieno.
Ci sono un paio di varianti rispetto a questa situazione:
Ocio: qui sopra ho scritto "il cliente", ma è ovvio che il cliente entra in ballo tramite il suo rappresentante. E si può anche intuire che questo rappresentante sarà anche il parafulmine delle ire del committente, in caso il prodotto sw non sarà adatto.
Il sistema RD funziona meglio di Consultative Design nel caso in cui il committente e lo sviluppatore siano dipartimenti diversi della stessa azienda. Perché? BOH!
Questo è un tipo di design che si presta bene allo sviluppo di software di cui viene venduta la licenza d'uso.
In questo caso, infatti, non c'è un committente direttamente interessato al sw, ma c'è un mercato composto da potenziali utenti finali. Lo sviluppatore ha tutto l'interesse di sentire i pareri di questi utenti finali per regolare le fasi di sviluppo del suo software. La relazione tra sviluppatore ed utente è quindi indiretta.
E' però anche possibile realizzare dei focus group, ovvero raccogliere in una stanza un certo numero di persone interessate al mio sw e rappresentativi della potenziale utenza, e farli parlare per sentire i loro pareri. Si tratterà di un'iniziativa una tantum, perché chiaramente l'utente finale non può distaccarsi e vivere presso la sw house per supervisionare lo sviluppo...
Il sistema generale comunque consiste nel rilascio di versioni beta, più o meno fasulle, ad un gruppo più o meno ristretto di utenti. Dopodiché, gli sviluppatori passano in rassegna i forum, i blog e i siti specializzati (messi spesso a disposizione da loro stessi) che hanno recensito la loro beta, e si fanno un'idea dell'umore degli utenti.
Se stiamo adottando un prcesso software di tipo non-waterfall (ad esempio quello iterativo o il RUP) è vitale che i requisiti siano sempre tenuti aggiornati, quale che sia la nostra tecnica per raccoglierli. Ad ogni iterazioni del ciclo di vita del nostro prodotto si produce una RFC, ovvero request for change, che è un documento che raggruppa tutte le modifiche ai requisiti che le ultime analisi hanno scoperto essere necessarie. In particolare, le RFC parlano di variazioni correttive, ma possono anche rendersi necessarie variazioni aggiuntive.
Questo Sommerville è un amico del professor Damiani e si occupa di software engineering. Ha scritto libroni sull'ingegneria dei requisiti, ed è potenzialmente uno di quelli che vengono pagati per raccontare favole alle conferenze, che poi nessuno metterà in pratica (vedi questo individuo).
Ma ha comunque detto cose interessanti, visto che poi saranno chieste all'esame:D
Introduciamo subito un termine nuovo: elicitation, che indica le fasi di interviste agli utenti secondo le tre tecniche viste sopra.
Lo studio di fattibilità dà un'idicazione strategica sul perché un'azienda troverebbe utile sviluppare un certo software. Diciamo subito che non sempre si fa. Quando viene fatto, serve per rispondere a queste domande:
Questo documento appartiene alla categoria dei business document, ovvero un documento realizzato non dal dipartimento IT, ma dalla sezione marketing o da chi per essi.
Lo studio di fattibilità rende più facile la fase di elicitation and analisys, ovvero l'andare in giro a sentire gli utenti che cosa vogliono (leggi interviste agli stakeholder). Se non c'è lo studio di fattibilità, l'elicitation and analisys si fa lo stesso.
Abbiamo già detto in diverse occasioni che una qualsiasi fase di processo può essere a sua volta divisa in sottofasi; quelle della elicitation sono:
Una cosa interessante consiste nel raggruppare gli stakeholder in categorie, e creare così dei viewpoint, ovvero una raccolta dei loro punti di vista sulle funzionalità che il sistema dovrà avere. In questo modo ci si può fare un'idea di quello che le categorie di stakeholder vogliono, ed analizzarne con più agio gli eventuali conflitti.
I conflitti non ci sono solo tra viewpoint differenti, ma anche tra stakeholder appartenenti allo stesso viewpoint. Ma in caso di conflitto, che si fa?
Ecco qui le tre categorie principali in cui gli stakeholder vengono divisi:
Facciamo un esempio: un impianto di gestione dello skilift.
No, non ci sono solo i requisiti. Ci sono anche altre tecniche utilizzabili per capire come deve essere fatto un sw. Qui ne vediamo un paio.
Uno scenario è la descrizione di "un giorno qualunque nella vita dell'utente". Questi si alza, accende il computer, apre il nostro sw, usa questa funzione, poi arriva quell'altro cliente, usa quell'altra funzione e così via.
Attraverso lo scenario si riesce a capire in modo cronologico quello che il nostro sistema deve fare.
Inoltre, lo scenario è anche utile per presentare un progetto al cliente. Infatti, la maggior parte della gente farebbe fatica a capire qualcosa da dei documenti cartacei: magari annuisce e poi si lamenta perché non è quello che voleva. Mettere tutto sotto forma di scenario aiuta tutti a capire meglio quello che succede rispetto a quello che si vuole.
Ricapitolando, lo scenario rappresenta una filiera di tipo cronologico: descrizione della situazione di partenza, flusso delle operazioni normali, cosa succede in caso di malfunzionamenti o imprevisti (eventi eccezionali).
Una mock-up è una finta interfaccia del programma, che viene presentata agli stakeholder. In questo modo loro vedono con mano (?) che aspetto avrà il programma, e quindi molti loro dubbi e perplessità riusciranno a trovare una forma per essere espressi. Capita spesso infatti che il committente che ha approvato la lista dei requisiti il giorno dopo guarda il mock-up e cambia idea inorridito.