6
scopo, ecc.).
2) definito come è stato condotto l’esperimento (pianificazione).
3) dopo aver accuratamente progettato e pianificato l’esperimento, lo si è eseguito per poter
raccogliere i dati.
4) sono analizzati i dati e tratte conclusioni al fine di interpretarli e generalizzare i risultati
ottenuti (analisi e interpretazione).
5) preparato tutta la documentazione (presentazione) sui risultati ricavati dall’esperimento e
sulla sua esecuzione in modo che l’esperimento possa essere ripetuto da altri con i dati
rielaborati.
¾ Effettuare una panoramica su fault, bug tracker, processo d’analisi dei bug e definire una
tassonomia (schema di classificazione) di fault.
L’esperimento svolto nella nostra tesi è stato ripetuto più volte in diverse tesi in diverse facoltà,
come Politecnico di Torino, Università degli studi di Genova e Università degli studi di Trento (il cui
lavoro è presentato in questa tesi).
L’esperimento viene condotto da studenti universitari del profilo informatico e ognuno di loro lavora
sul proprio insieme di bug (reali). Lo studente del Politecnico di Torino ha lavorato sulla
classificazione dei bug per alcune categorie di software tipo: posta elettronica, editor di pagine web
e strumenti di gestione database. Lo studente dell’Università degli studi di Genova ha lavorato
sugli stessi applicativi scelti dallo studente di Torino, scegliendo però nuovi bug da classificare e
inoltre aggiungendo una nuova categoria di software di tipo “gioco a scacchi”. Lo studente
dell’Università degli studi di Trento ha lavorato sugli stessi applicativi scelti dallo studente di
Genova, scegliendo però nuovi bug da classificare e inoltre aggiungendo anche il lavoro sulla
classificazione dei bug per una nuova categoria di software di tipo “strumenti di gestione
finanziaria”. In totale, lo studente di Trento ha effettuato la classificazione dei bug di cinque coppie
d’applicativi (4 coppie di software da 35 bug ognuna più una coppia di software da 60 bug ognuna
con un totale di 400 bug).
Nell’esperimento si è osservato che, in media ci si può aspettare che un applicativo web-based
abbia circa il 12% di bug relativi alla sua Interfaccia in più rispetto ad un corrispettivo applicativo
tradizionale client/server.
Il lavoro presentato in questa tesi è parte di una pubblicazione scientifica[10]:
“Defect location in Traditional vs. Web applications – an empirical investigation”
che verrà presentata in “11
th
IEEE International Symposium on Web Systems Evolution (WSE
2009)” il 25-26 Settembre 2009 (Edmonton, Canada).
7
La tesi è organizzata come segue: Il primo e secondo capitolo presentano nozioni di background e
introducono il contesto di lavoro. Nel dettaglio, nel primo capitolo si introduce il concetto di studio
empirico nell’ingegneria del software e come viene applicato questo concetto nel nostro caso di
studio. Nel secondo capitolo si porta una descrizione generale degli applicativi web-based e
un’analisi dettagliata dell’architettura a tre livelli insieme alle sue proprietà.
Nel terzo capitolo si descrivono i concetti di fault e bug tracker, e vengono illustrati con esempi
concreti, tutti del nostro esperimento. Si introduce la tassonomia di fault usata nell’esperimento per
classificare i bug e si spiega il ciclo di vita del bug. In questo capitolo inoltre si presenta
l’esperimento.
Nel quarto capitolo si presenta un’analisi dettagliata di due bug tracker (OpenProjectmanager e
CodeTrack). Tutti i due bug tracker sono stati installati, provati con esempi di bug concreti e
confrontati fra di loro. Per entrambi i software è stato “ricostruito” lo schema della gestione del ciclo
di vita del bug.
Il quinto capitolo è il più importante perché presenta i dati raccolti e riporta le tecniche e i risultati
delle analisi effettuate, sviluppando in conclusione alcune riflessioni e osservazioni sull’esperienza
fatto. In altre parole, si presenta la classificazione dei bug di tutte le cinque coppie di software
seguendo la tassonomia implementata in precedenza, si spiega il metodo usato per la raccolta dei
dati e si tirano i risultati finali delle analisi.
8
CAPITOLO 1
1. Studi Empirici nell’ingegneria del software e l’applicazione nel nostro
caso di studio
Nell’ingegneria del software non è sufficiente proporre nuove idee e nuove metodologie solo sulla
base di un’opinione. Nasce cosi, il bisogno dello studio empirico, che permette di basarsi sulla
prova e su una analisi statistica dei dati/risultati. L’opportunità di estrarre risultati statisticamente
significativi riguardo alla comprensione, previsione e il miglioramento dello sviluppo del software è
la ragione più importante per cui si ha bisogno degli studi empirici.
E’ difficile giudicare se uno strumento, una tecnica e un metodo sono utili o meno in un
determinato contesto senza un’accurata analisi empirica. Gli studi empirici sono un importante
input per la “decision-making” (in italiano, prendere decisioni) di un organizzazione.
Con l’ingegneria del software empirica non si vuole soltanto determinare l’utilità di una
tecnica/metodo/strumento ma anche le circostanze nella quale può essere usata con successo.
1.1. Difficoltà nella realizzazione di uno studio empirico
Ci sono alcuni osservazioni da fare riguardo agli studi empirici nel campo dell’ingegneria del
software:
1- Bisogna dire che per problemi di costo e riservatezza, tanti studi empirici sono condotti con
studenti piuttosto che con professionisti. Questo aspetto può portare a “non realistiche”
riproduzioni in laboratorio.
2- Bisogna ricordarsi che si sta lavorando con esseri umani, e quindi sono da considerare molte
variabili. Per questo è necessario considerare un’ampia porzione di popolazione e non solo
una piccola parte.
3- La discriminazione dei risultati negativi, spesso determinata da preconcetti personali. Non
presentare i risultati negativi di una determinata tecnica determina una scarsa conoscenza a
livello di pubblico utilizzo che può portare a fallimenti di progetti.
4- Dobbiamo saper utilizzare il metodo d’analisi dei dati più adeguato al particolare caso di studio
(cosa non sempre facile da determinare).
9
1.2. Come condurre uno studio empirico
Lo studio empirico nasce con l’idea di provare a rispondere a delle domande generiche o
specifiche (Research Questions) ed è pianificato determinando alcune fasi. Per prima cosa,
occorre trasformare la nostra idea in domanda. Dopo questa fase iniziale è possibile progettare il
design dell’esperimento che successivamente verrà realizzato.
Il progetto va pianificato seguendo alcuni criteri importanti, ad esempio: 1)determinare il numero
delle persone che eseguiranno lo studio; 2)preparale allo studio; 3)dividere le persone in gruppi;
4)selezionare il materiale disponibile; 5)determinare il tempo dell’esperimento, ecc.
Conclusa la fase di design, l’esperimento viene realizzato. Dopo l’esecuzione dell’esperimento
vengono raccolti i dati ed interpretati i risultati con i metodi statistici.
Infine, è possibile:
o Preparare delle rappresentazioni grafiche dei risultati (istogrammi, diagrammi a torte, ecc.).
o Determinare se i risultati ottenuti sono statisticamente significativi (usando i test statistici).
1.3. Sperimentazione di applicazioni web-based vs applicazioni
tradizionali client/server
Le applicazioni web-based si pongono come valida alternativa alle tradizionali applicazioni
client/server e sono molto diffuse grazie: alla loro facilità di distribuzione e aggiornamento,
all’accesso multipiattaforma, al limitato costo di gestione e scalabilità. Ma dall’altra parte risultano
più complesse rispetto alle applicazioni tradizionali client/server perché la realizzazione,
comprensione e manutenzione sono operazioni estremamente critiche. Un’applicazione web-
based si basa su un’architettura complessa che comprende diversi componenti: un interfaccia
client, uno o più programmi server, controlli ActiveX, servlet Java, scripts, DBMS, una struttura di
navigazione ecc. Altre nozioni da tenere presenti e che complicano ulteriormente le cose sono: la
sicurezza, la sessione e l’autenticazione.
L’utilizzo diffuso delle applicazioni web-based ha determinato la ricerca di tecniche e metodologie
per migliorare la qualità di queste applicazioni. In particolare sono state proposte diverse tecniche
di test da parte di ricercatori[1, 11, 12, 13], sebbene la specifica natura dei bug delle applicazioni
web-based, non è mai stata esplicitamente studiata e confrontata con quella delle applicazioni
tradizionali client/server. In quest’ottica, la tesi ha come scopo lo studio della distribuzione dei bug
all’interno di una tipica architettura a tre livelli. In particolare mira a confrontare tale distribuzione in
applicazioni web-based e in applicazioni tradizionali client/server.
10
1.3.1. Lo svolgimento del nostro esperimento
La sperimentazione prevede di mettere a confronto la distribuzione dei bug in applicazioni web-
based con la distribuzione dei bug in applicazioni tradizionali client/server. L’obbiettivo
dell’esperimento è quello di confermare o rifiutare l’ipotesi che l’interfaccia utente delle applicazioni
web-based, in quanto più complessa, risulta essere anche maggiormente difettosa. Quindi la
“Research Question” principale del nostro esperimento è la seguente:
RQ1: l’interfaccia utente delle applicazioni web-based è più difettosa rispetto alla interfaccia
utente delle applicazioni tradizionali client/server ?
Lo svolgimento dell’esperimento viene secondo lo schema sottostante:
La definizione generica e/o specifica delle varie fasi e sottofasi che compongono il processo
dell’esperimento, verranno portate in seguito.
1.3.1.1. Definition
Nella fase “Definition” (la definizione) si specifica il motivo per cui l’esperimento viene svolto. In
questa fase si deve definire:
o L’oggetto dello studio: è l’entità che viene studiato nel esperimento.
Nel nostro caso le entità studiate nell’esperimento sono: tutti i campi principali nella
segnalazione del bug, il codice e i commenti degli utenti del software o sviluppatori.
o Lo scopo: rappresenta l’intenzione dell’esperimento. Si valuta l’ipotesi che l’interfaccia
utente delle applicazioni web-based è maggiormente difettosa in confronto con le
applicazioni tradizionali client/server.
o Il focus sulla qualità: è l’effetto sotto studio nell’esperimento.
11
Nel nostro caso ci concentriamo sull’affidabilità e la trasparenza della classificazione svolta
dagli studenti universitari di Genova, Torino e Trento.
o La prospettiva: è la viewpoint (visione) dalla quale i risultati dell’esperimento sono
interpretati. Lo studente universitario valuta i risultati tratti dal proprio insieme di bug tirando
fuori le conclusioni della sua analisi dei bug. Il docente universitario lavora sui risultati tratti
da tutti gli studenti che hanno partecipato nell’esperimento. Al docente universitario spetta
l’ultima parola riguardo all’esito dell’esperimento.
Lo sviluppatore del software valuta i risultati/conclusioni tratte dal docente universitario e
concentra i suoi sforzi nel miglioramento di quel particolare livello di architettura software
dove sono stati verificati i problemi.
o Il contesto: è l’ambiente in cui l’esperimento viene eseguito. Esso definisce i soggetti e gli
oggetti che vengono usati nell’esperimento.
Nel nostro caso (esperimento), i soggetti sono i tre studenti universitari che partecipano
nell’esperimento. Gli oggetti sono tutti gli applicativi presi in considerazione nel nostro
esperimento (TinyMCE, Kompozer, phpMyAdmin, Openbravo ERP ecc.).
1.3.1.2. Planning
Nella fase “Planning” (pianifica) si definisce come viene condotto l’esperimento, è una attività molto
importante. Bisogna impostare in modo chiaro: il contesto, i soggetti, le variabili, i metrics, il design
dell’esperimento ecc. Il risultato dell’esperimento dipende tanto dalla fase di “Planning” perché può
essere “deviato”/disturbato o addirittura non valido se l’esperimento è pianificato in modo
improprio.
Nello schema sottostante vengono riportate tutte le fasi che compongono il “planning”
dell’esperimento:
12
Iniziamo a chiarire le varie sottofasi che compongono il “planning” dell’esperimento.
¾ Context selection (il contesto): Nel nostro esperimento abbiamo le seguenti dimensioni:
studenti vs. professionali, segnalazioni di bug inesistenti o non riproducibili vs. segnalazioni di
bug reali/confermati dagli sviluppatori, un contesto specifico (per esempio, SquirrelMail vs
Phoenix Mail) vs. un contesto generico (client di posta elettronica).
¾ Hypothesis formulation (le ipotesi): Le ipotesi in un esperimento sono impostate in modo
formale, includendo un’ipotesi “null” (null hypothesis = H
0
) ed un’ipotesi alternativa (H
1
).
Le ipotesi nel nostro esperimento sono:
H
0
: l’interfaccia utente delle applicazioni web-based, in quanto più complessa, non è più
difettosa rispetto alla interfaccia utente delle applicazioni tradizionali client/server.
H
1
: l’interfaccia utente delle applicazioni web-based, in quanto più complessa, è più difettosa
rispetto alla interfaccia utente delle applicazioni tradizionali client/server.
¾ Variable selection (la selezione di variabili): determina le variabili indipendenti (gli input) e le
variabili dipendenti (gli output).
Le variabili indipendenti sono le variabili che possono essere controllate e cambiate
nell’esperimento. In questa fase si descrivono i trattamenti (treatments) e rappresentano le
variabili per le quali gli effetti devono essere valutati.
Nel nostro esperimento, il “Factor” (il fattore) viene rappresentato dal tipo di interfaccia
(interfaccia web-based o client/server tradizionale) e le variabili indipendenti sono:
1) le interfacce utenti delle applicazioni web-based.
2) le interfacce utenti delle applicazioni tradizionali client/server.
Le variabili dipendenti sono le variabili di risposta che descrivono gli effetti del trattamento
descritto dalle variabili indipendenti. Una semplice rappresentazione grafica di quello che
abbiamo detto viene riportato nella schema sotto:
In generale, esiste solo una variabile dipendente che deriva direttamente dalle ipotesi. Nel nostro
esperimento la variabile dipendente è il numero di bugs trovato per ogni tipo di interfaccia utente.
tipo di UI nr. di bug
UI -
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
