Progettazione e realizzazione di un sistema per la ricostruzione ed individuazione dei requisiti software attraverso tecniche di software repository mining

 In secondo luogo l’aumento della produttività e lo sfruttamento sempre più efficiente delle 
risorse a disposizione ha aumentato la richiesta di applicativi sempre più elaborati e con 
numerose funzionalità, rendendo quindi spesso difficoltosa la loro progettazione. 
L’insieme di questi due bisogni ha portato alla necessità di definire una metodologia 
formale e rigorosa per lo sviluppo software, dalla semplice idea iniziale fino alla consegna 
al cliente dell’applicazione. È su questo campo che si è sviluppata la disciplina 
dell’ingegneria del software, che è volta alla schematizzazione dell’intero processo di 
sviluppo ed alla produzione di una dettagliata documentazione in ogni fase del ciclo di vita 
del prodotto software. 
 
1.2 I requisiti software 
 
Secondo i canoni dell’ingegneria del software, prima di poter pensare alla progettazione di 
un’applicazione bisogna attraversare una fase molto delicata di reperimento delle 
informazioni necessarie alla corretta e completa comprensione del problema che la 
soluzione software deve affrontare. Tale raccolta può rivelarsi molto ardua da condurre in 
quanto bisogna afferrare tutti gli aspetti del particolare dominio in questione, con il quale 
molto spesso l’ingegnere del software non ha familiarità; bisogna quindi quasi sempre 
avvalersi del supporto di esperti del settore, con i quali possono comunque esservi dei 
problemi di comunicazione per via dei diversi linguaggi tecnici utilizzati e dei punti di 
vista non sempre convergenti. 
L’insieme delle necessità emerse dall’analisi del dominio applicativo viene 
opportunamente formalizzato dando vita ai cosiddetti requisiti software, dettagliate 
descrizioni formali dal punto di vista del progettista software delle funzionalità che 
 2
 l’applicazione dovrebbe fornire. Il tutto viene solitamente riportato in un documento 
ufficiale chiamato SRS (Software Requirements Specification). 
La fase di individuazione di requisiti precisi e completi riguarda potenzialmente tutto il 
ciclo di vita dell’applicazione ed è così importante all’interno dell’ingegneria del software 
che ha portato alla creazione di una disciplina propria: l’ingegneria dei requisiti. 
Tipicamente, il processo dell’ingegneria dei requisiti attraversa le fasi seguenti (Figura 
1.1): 
 
 
Figura 1.1 Processo dell’ingegneria dei requisiti 
 
in cui le operazioni fondamentali sono quattro: 
1. Studio di fattibilità: consiste nel valutare se le necessità attuali del cliente possono 
essere soddisfatte con la tecnologia ed il budget disponibile; 
2. Analisi dei requisiti: consiste nella comprensione, con l’aiuto di esperti nel settore, 
dei requisiti del sistema; 
3. Definizione dei requisiti: consiste nella definizione dei requisiti in una forma 
comprensibile dal cliente; 
 3
 4. Specifica dei requisiti: consiste nella definizione in dettaglio dei requisiti dal punto 
di vista dell’ingegnere del software. 
 
1.3 Problematiche nell’ingegneria dei requisiti 
 
Tanti sono i problemi legati allo sviluppo ed alla risoluzione dei requisiti software, ma due 
li sintetizzano in maniera significativa. 
Da una parte, la crescente richiesta di applicazioni sempre più sofisticate e mirate 
all’implementazione di uno spettro sempre più ampio di funzionalità ha determinato una 
crescita del numero di requisiti da trattare e soddisfare, con un relativo aumento di 
complessità nelle definizioni degli stessi e nella stesura del SRS. Soprattutto a causa della 
crescente affermazione di metodologie di progettazione software open-source, che non 
seguono un rigido schema operativo tipico di una struttura aziendale, risulta sempre più 
difficile verificare se i requisiti software sono stati effettivamente affrontati dalla versione 
attuale dell’applicazione, e in caso affermativo se sono stati affrontati in maniera adeguata. 
Dall’altra parte, l’evoluzione dei requisiti non consente neppure di definire e specificare in 
maniera definitiva il loro numero e la loro forma. Dalla Figura 1.1 si nota subito che, 
superata la fase dello studio di fattibilità, le altre tre fasi possono richiamarsi l’una con 
l’altra diverse volte. Ciò accade molto spesso proprio per via della cattiva comunicazione 
tra l’ingegnere del software ed il cliente come detto nel paragrafo precedente, il che 
comporta una revisione nell’espressione e/o nel contenuto dei requisiti, ma può essere 
attribuibile anche ad un cambiamento della conoscenza. Non è raro infatti che tanto il 
committente quanto l’ingegnere del software possano rendersi conto di non aver preso in 
considerazione degli aspetti del dominio, o di non averli considerati adeguatamente, e 
 4
 debbano rivedere il documento dei requisiti per modificare, aggiungere od eliminare alcuni 
di essi sulla base delle nuove conoscenze. 
In genere, i requisiti influenzati da questi aspetti ricadono nelle seguenti tipologie: 
 ξ  requisiti duplicati: requisiti trattanti in realtà lo stesso argomento, o i cui argomenti 
sono coperti da un insieme di altri requisiti; 
 ξ  requisiti instabili: requisiti che cambiano a causa dell’ambiente del sistema; 
 ξ  requisiti emergenti: requisiti che nascono quando aumenta la comprensione del 
problema; 
 ξ  requisiti indotti: requisiti che nascono dall’introduzione del sistema software; 
 ξ  requisiti di compatibilità: requisiti che dipendono da altri sistemi o processi 
organizzativi. 
 ξ  requisiti impliciti: requisiti che sono specifici del dominio e per questo non 
completamente o tempestivamente esplicitati e quindi formalizzati. 
Tra questi, rivestono particolare importanza i requisiti emergenti, perché sono quelli che 
permettono l’evoluzione del sistema con l’aggiunta di nuove funzionalità o proprietà molto 
spesso direttamente riscontrabili anche dal cliente. 
Il lavoro oggetto della presente tesi affronta le due importanti problematiche appena 
esposte. Fermo restando che il processo di manutenzione dei requisiti deve essere condotto 
dagli ingegneri del software, si è cercato di creare uno strumento che possa affiancarli ed 
essere loro di supporto fornendo innanzitutto una stima su quanto i requisiti attuali sono 
stati affrontati, e offrendo linee guida per individuare più facilmente eventuali requisiti 
duplicati ed emergenti. 
In particolare, nella trattazione sarà dapprima illustrato lo stato dell’arte nel campo della 
tracciabilità dei requisiti ed in quello della ricerca e recupero delle informazioni (Capitolo 
2); successivamente si vedrà il metodo utilizzato per affrontare le problematiche viste 
 5
 (Capitolo 3), seguito da una dettagliata analisi del tool che lo implementa (Capitolo 4). 
Infine si darà una valutazione della qualità di quest’ultimo, provandolo su un caso reale 
(Capitolo 5). 
 6
 Capitolo 2 – Stato dell’arte 
 
 
 
2.1 Introduzione 
 
Come visto nel capitolo precedente, l’ambito in cui si colloca l’oggetto della presente tesi è 
piuttosto vasto e copre diversi aspetti inerenti l’ingegneria del software. Quello 
sicuramente più importante, solo accennato nel Capitolo 1, è legato al problema della 
tracciabilità dei requisiti, consistente nella ricerca di una tecnica usata per fornire una 
relazione tra i requisiti, il progetto e l’implementazione finale del sistema. Queste relazioni 
permettono ai progettisti di mostrare il motivo ed il modo in cui il progetto soddisfa i 
requisiti dei vari committenti e aiutano nell’individuazione precoce di quelli che invece 
non sono ancora soddisfatti. 
Inoltre, un ambito che nel corso degli anni ha fornito spunti per l’individuazione di 
tecniche a supporto della tracciabilità dei requisiti è l’information retrieval: è proprio in 
quest’ultimo campo che si è mossa la ricerca e lo sviluppo del metodo per la risoluzione 
delle problematiche presentate, ed è anche questo il campo in cui sono stati condotti 
numerosi interessanti studi e sviluppate metodologie basate su diversi principi. 
Nel seguito si approfondiranno le conoscenze attuali in questi settori. 
 7
 2.2 Tracciabilità dei requisiti 
 
Lo sviluppo e l’uso di tecniche per il tracciamento dei requisiti hanno origine nei primi 
anni settanta per influenzare le caratteristiche di completezza e consistenza dei requisiti di 
un sistema. 
Come accennato in precedenza, la tracciabilità dei requisiti si pone nell’ottica di assicurare 
che il prodotto software soddisfi le aspettative del cliente che lo ha commissionato. Ciò, in 
particolare, conduce ad un lavoro metodico congiunto tra fornitore e committente, nel 
quale è possibile dimostrare progressivamente che gli sviluppatori hanno compreso i 
requisiti, come ogni requisito è stato soddisfatto e viceversa come ogni componente del 
sistema soddisfa un requisito, e che il prodotto non ha bisogno di caratteristiche non 
necessarie. 
La tracciabilità dovrebbe inoltre mostrare come si è arrivati ai requisiti correnti: il 
razionale di progettazione deve identificare non solo le decisioni, ma indicare anche le 
assunzioni e le motivazioni a supporto o a confutazione dietro tali decisioni, esplicitando il 
contesto nel quale esse sono state prese. In questo modo, viene facilitata la comunicazione 
tra coloro che sono coinvolti nel progetto e di conseguenza l’intera gestione dei requisiti. 
Attraverso le informazioni raccolte, i progettisti e i manutentori possono determinare 
facilmente gli effetti dei cambiamenti prima di riprogettare il sistema, in modo da avere 
un’idea dei costi e programmare le attività. Tutto ciò senza dipendere dalla conoscenza di 
ingegneri e programmatori in tutte le aree coinvolte da tali cambiamenti. 
Inoltre, le informazioni di tracciabilità possono essere usate da coloro che sviluppano ed 
eseguono i test per determinare quali di questi effettuare e per modificarli correttamente 
nel caso siano individuati degli errori. 
 8
  
2.2.1 Problema della tracciabilità 
 
Ad oggi, il problema della tracciabilità rimane ancora una questione aperta. Nonostante 
l’aumento sia nella domanda che nell’offerta di tool che includono funzionalità di 
tracciabilità, il loro utilizzo pratico non è tanto diffuso quanto l’importanza della 
tracciabilità richiederebbe. Inoltre, i problemi di tracciabilità sussistono anche lì dove viene 
utilizzata. Studi empirici con professionisti nel settore hanno rilevato che il problema della 
tracciabilità non è percepito come uniforme, a causa della diversità delle definizioni e ad 
un numero di conflitti fondamentali.  
Le definizioni di tracciabilità dei requisiti, utilizzate dagli sviluppatori e presenti in 
letteratura, si possono classificare come: 
 ξ  Purpose-driven (definite in termini di cosa dovrebbe fare) 
"…l‘abilità di aderire alla posizione di business, alla portata del 
progetto e ai requisiti chiave che sono stati sottoscritti" 
 ξ  Solution-driven (definite in termini di come dovrebbe farlo) 
"…l’abilità di avere delle tracce da un’entità a un’altra basandosi 
su relazioni semantiche date" 
 ξ  Information-driven (enfatizza le informazioni di tracciabilità) 
"…l’abilità di collegare insieme funzioni, dati e requisiti alle 
formulazioni testuali che vi si riferiscono" 
 ξ  Direction-driven (enfatizza la direzione della tracciabilità) 
"…l’abilità di collegare uno specifico item all’inizio di una fase del 
ciclo di vita software ad un altro alla fine della stessa fase" 
 9
 Come si può notare, nessuna definizione copre tutti gli aspetti; piuttosto ognuna differisce 
nell’enfasi e delimita un particolare ambito. Questo ha delle ripercussioni nello sviluppo e 
nell’utilizzo di tool che supportano la tracciabilità, in quanto diventa arduo implementarla 
coerentemente e consistentemente dato che ogni individuo ha la sua concezione di cosa 
rappresenta il problema stesso della tracciabilità. 
A queste difficoltà si deve aggiungere anche che ogni sviluppatore ha la sua idea su quale 
sia la causa principale del problema della tracciabilità e che, ogni volta in cui la 
tracciabilità è richiesta, entrano in gioco diversi utenti, progetti, task e requisiti. 
 
2.2.2 Tracciabilità pre/post specifica dei requisiti 
 
Si possono distinguere due tipi di tracciabilità dei requisiti: 
 ξ  Tracciabilità pre-RS (specifica dei requisiti), la quale si riferisce a quegli aspetti 
della vita di un requisito precedentemente alla sua inclusione nella specifica 
(requirements production). 
 ξ  Tracciabilità post-RS, che si riferisce a quegli aspetti della vita di un requisito 
successivamente alla sua inclusione nella specifica (requirements deployment). 
La figura seguente mette in evidenza alcuni aspetti relativi alle definizioni appena fornite 
(Figura 2.1):  
 
 10
 Specifica dei 
Requisiti 
___________
___________
___________
___________
___________
___________
___________
___________
     (S0) 
 
 
 
 
 
 
 
 
 
     (S1)
 
 
 
 
 
 
 
 
 
       (Sn)
 
 
 
Tracciabilità pre-RS  Tracciabilità post-RS 
 
Figura 2.1 Tracciabilità pre-RS e post-RS 
 
È da notare sia come la conoscenza dei requisiti è distribuita e fusa insieme in successive 
rappresentazioni sia la complicazione aggiunta delle iterazioni e della propagazione dei 
cambiamenti. 
La tracciabilità di tipo forward e quella di tipo backward sono entrambe essenziali. In 
questo schema, però, è stata enfatizzata la separazione tra tracciabilità pre-RS e post-RS, 
dato che i problemi relativi alla tracciabilità che sono stati rilevati sono soprattutto 
incentrati sulla mancanza di distinzione in questo punto.  
Le principali differenze tra questi due tipi di tracciabilità coinvolgono le informazioni con 
cui hanno a che fare e i problemi che possono affrontare. La tracciabilità post-RS dipende 
dall’abilità di tracciare i requisiti da e verso la loro specifica, attraverso una successione di 
artefatti nei quali essi sono distribuiti. I cambiamenti alla specifica dei requisiti devono 
essere propagati attraverso questa catena. La tracciabilità pre-RS, invece, dipende 
 11
 dall’abilità di tracciare i requisiti da e verso la loro formulazione originaria, attraverso il 
processo di produzione e raffinamento dei requisiti, nelle quali le formulazioni provenienti 
da diverse sorgenti sono prima o poi integrate in singoli requisiti all’interno della specifica. 
I cambiamenti nel processo devono subire una rilavorazione all’interno della specifica.  
Il supporto esistente fornisce principalmente la tracciabilità post-RS. I problemi da 
risolvere in questo ambito riguardano un artefatto o dei metodi informali di sviluppo. Di 
contro, i problemi da affrontare con la tracciabilità pre-RS non sono né ben compresi né 
pienamente supportati: il supporto alla tracciabilità post-RS in questo caso non è adatto, 
dato che in genere tratta la specifica dei requisiti come una black-box, in cui è messo poco 
in evidenza che in realtà i requisiti sono il prodotto finale di un processo complesso e in 
continua evoluzione. Attenersi rigidamente alle categorie per registrare le informazioni 
rende inoltre difficile rappresentare questo processo a causa della natura dinamica delle 
sorgenti e dell’ambiente dai quali i requisiti vengono elicitati. 
 
2.2.3 Il problema delle sorgenti umane dei requisiti 
 
L’incapacità di rispondere a domande relative alle sorgenti umane dei requisiti è 
determinante nei problemi relativi alla tracciabilità dei requisiti.  
Tranne alcune eccezioni, gli sforzi per migliorare il potenziale della tracciabilità hanno per 
lo più riguardato scoprire e registrare la maggior quantità di informazioni possibile circa il 
processo di ingegneria dei requisiti, collegandola successivamente in svariati modi per la 
determinazione delle tracce. Questo può condurre ad una massa non strutturata e 
inutilizzabile di dati, senza una discriminazione a priori circa il tipo e i propositi delle 
informazioni sui requisiti di cui gli sviluppatori hanno bisogno. 
 12
 Seguendo studi empirici è possibile dimostrare che l’informazione più importante da 
registrare per la risoluzione a lungo termine di problemi riguardanti la tracciabilità, è quella 
identificata dalle sorgenti umane delle informazioni. Si è capito che quelli che si ritengono 
essere problemi relativi alla tracciabilità dei requisiti tendono a emergere quando gli 
sviluppatori non sono capaci di rispondere a domande circa il personale coinvolto nella 
produzione e nel raffinamento dei requisiti. Questo dipende dal fatto che le persone sono 
spesso considerate l’ultima soluzione quando i requisiti hanno bisogno di essere 
riesaminati o necessitano di una rilavorazione. 
Ciò riflette il fatto che le persone sono spesso l’autorità finale dei requisiti e, in quanto tali, 
sono frequentemente capaci di prevenire i potenziali problemi di tracciabilità. Nondimeno, 
l’abilità di collocare individui e gruppi appropriati è nella pratica estremamente difficile. 
L’incapacità di collocare le sorgenti umane dei requisiti reali, le informazioni ed il lavoro 
legati ai requisiti (e quindi di accedervi) è uno dei punti cruciali del problema 
multisfaccettato della tracciabilità. Da qui, è stato proposto di rendere espliciti, e quindi 
tracciabili, i dettagli delle impostazioni sociali che danno risalto agli artefatti prodotti 
nell’ingegneria dei requisiti. 
 13
 2.2.4 Modelli di riferimento per la tracciabilità 
 
Molti standard che richiedono la tracciabilità dei requisiti non forniscono un modello 
completo di come l’informazione debba essere catturata e utilizzata come parte di uno 
schema di tracciabilità, in modo da assicurare che questa sia mantenuta durante tutte le fasi 
del processo di sviluppo, a partire dalla contrattazione con il cliente fino al testing e oltre. 
Nel corso degli ultimi anni sono stati proposti diversi modelli, per lo più basati su 
considerazioni teoriche o su analisi effettuate dalla letteratura esistente. In questa sede ci si 
concentrerà sui risultati del lavoro di Ramesh. A differenza degli altri modelli, Ramesh ha 
seguito un approccio empirico per sintetizzare alcuni modelli di riferimento, validati 
successivamente con dei casi di studio e inclusi in diversi tool per la tracciabilità. Questi 
modelli comprendono i più importanti tipi di collegamenti di tracciabilità tra i diversi task 
del processo di sviluppo software. 
I modelli di riferimento in generale sono modelli prototipali di alcuni domini applicativi. 
Lo scopo dei modelli di riferimento è ridurre in maniera significativa la creazione di 
modelli e sistemi per un dominio applicativo: l’utente seleziona parti rilevanti del modello 
di riferimento, le adatta al problema in questione e configura la soluzione generale a partire 
da queste parti adattate. È stato stimato che, dal momento che l’analisi di un dominio può 
richiedere uno sforzo enorme quando parte dal nulla, l’uso di modelli di riferimento 
permette di risparmiare fino all’80% dei costi di sviluppo per sistemi in domini 
standardizzati. 
Naturalmente non tutti i domini applicativi sono sufficientemente standardizzati da 
permettere la definizione di un modello orientato al prodotto finale; d’altra parte è 
possibile vedere i modelli come modi per riutilizzare l’esperienza legata ai processi di 
 14
 sviluppo, e non come un insieme di regole stabilite. È in quest’ottica che si pone l’uso di 
modelli per la tracciabilità dei requisiti. 
Nei suoi studi Ramesh ha diviso gli utenti in due gruppi distinti rispetto alle loro pratiche 
di tracciabilità dei requisiti: 
 ξ  low-end traceability user: sono utenti che hanno pochi anni di esperienza nel 
campo della tracciabilità e la vedono semplicemente come un obbligo imposto dai 
sostenitori del progetto o dagli standard in uso. 
 ξ  high-end traceability user: sono utenti che hanno diversi anni di esperienza nella 
tracciabilità dei requisiti e la vedono come una componente fondamentale del 
processo ingegneristico per sistemi di qualità; per loro rappresenta una maggiore 
opportunità per raggiungere la soddisfazione del cliente e per la creazione di 
conoscenza durante tutto il ciclo di vita del sistema. 
I modelli di riferimento considerati assumono un’implementazione basata su repository 
delle tracce (manuali o digitali), i quali devono comprendere almeno tre livelli: 
1. il meta-modello che definisce il linguaggio in cui i modelli della tracciabilità 
possono essere definiti; 
2. un insieme di modelli di tracciabilità di riferimento che possono essere 
personalizzati all’interno dell’ambito definito dal meta-modello; 
3. un database (possibilmente distribuito) delle tracce attuali, registrate sotto i modelli 
scelti. 
Gli aspetti fondamentali della tracciabilità possono essere catturati con un meta-modello 
molto semplice, come quello mostrato in Figura 2.2, il quale quindi fornisce le primitive 
base per catalogare e descrivere i modelli della tracciabilità con maggior dettaglio: 
 15