Ingegeneria del software - Appunti del 9 marzo 2009

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.

Coinvolgimento degli utenti

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.

Consultative Design

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.

Representative Design

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:

• Joint Application Design (JAD): il cliente approva anche i diagrammi, e non solo l'analisi dei requisiti
• Quality Functional Deployment (QFD): il cliente entra in gioco in tutte le fasi, compresa la messa in opera (il deployment). "Contrariamente a quanto si possa pensare" (sic) questa tecnica non è poi così rara

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!

Consensus Design

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.

Gestione dei requisiti

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.

Ian Sommerville

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.

Studio di fattibilità

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 sw contribuirà agli obiettivi organizzativi della nostra azienda, ad esempio riduzione delle giacenze in magazzino e così via?
• questo sw è fattibile con la tecnologia attualmente in nostro possesso?
• il costo di questo sw ci sta nel budget?
• questo sw sarà integrabile con gli altri sw già esistenti che già utilizzo?

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:

• requirement discovery: colloqui con gli stakeholder per raccogliere le loro richieste
• requirement classification & organization: raggruppamento e organizzazione dei requisiti in classi concettualmente omogenee
• prioritisation & negotiation: stabilire delle priorità tra i vari gruppi di requisiti e negoziare con gli stakeholder sulle eventuali (ma molto probabili) contraddizioni
• requirements documentation

Raggruppamento dei requisiti

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?

• posso ripetere le interviste, cercando di spiegare meglio il punto oscuro
• posso scegliere di dare retta ad uno stakeholder e non ad un altro, secondo il mio libero arbitrio. Va detto però che nella maggior parte dei casi l'ago della bilancia pende più dalla parte di chi che ci mette i soldi, per ovvie ragioni

Ecco qui le tre categorie principali in cui gli stakeholder vengono divisi:

• interactor viewpoints: si tratta di tutti quelli che avranno a che fare direttamente con il sistema, ovvero gli utenti o altri sistemi che utilizzeranno il nostro programma
• indirect viewpoints: tutti quegli stakeholder che non usano il sistema, ma lo influenzano
• domain viewpoints: tutti gli stakeholder che rappresentano esigenze normative o regolative (ministeri, leggi etc.). Non hanno rapporti né diretti né indiretti, stanno al di sopra di tutto

Facciamo un esempio: un impianto di gestione dello skilift.

• i direct saranno gli sciatori, i cassieri che vendono i biglietti, gli addetti che ci fanno salire sullo skilift
• gli indirect saranno ad esempio il consorzio degli impianti di risalita, perché devo magari poter accedere ad un database generale per eventuali sconti etc.
• i domain saranno ad esempio l'Ente Nazionale per la Protezione Infortuni, le assicurazioni

Tecniche alternative alla raccolta dei requisiti

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.

Lo Scenario

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).

Mock-up

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.

---

Torna alla pagina di Ingegneria del Software