norangebit/master-thesis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Refactor RQ3

Browse Source
This commit is contained in:
Raffaele Mignone 2021-06-14 18:41:05 +02:00
parent 9eebbe7d7d
commit 8f94bd7731
Signed by: norangebit
GPG Key ID: F5255658CB220573
1 changed files with 11 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/chapter_3.md
View File

@ -148,7 +148,7 @@ La classificazione è avvenuta attraverso la lista delle issues citate all'inter
## Metodologia
### RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
### RQ1: come il ML e' distribuito sull'architettura dei progetti?
In questa prima domanda si vuole andare a capire quant'è ampia la *superficie* del progetto che viene modificata durante gli interventi di *fix*, facendo distinzione tra le correzioni che riguardano il \ac{ML} e quelle generiche.
Inoltre si vuole anche capire quanti file importano librerie tipiche del \acl{ML}.
@ -183,7 +183,7 @@ Mentre nel caso di severità *strict* era necessario importare almeno una librer
Per entrambe le classificazioni si è andato a valutare a quanto ammontava la percentuale di file di \ac{ML} appartenenti ad un progetto.
Anche i questo caso le distribuzioni sono state analizzate attraverso l'ausilio di un boxplot.
### RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
### RQ2: come sono distribuiti i bug sulle diverse fasi di ML?
Come illustrato nella @sec:classificazione-commit per poter determinare la natura di un *issue fix* si è fatto ricorso alla classificazione delle *issues* ad esso associate.
La maggior parte delle *issues* è stata classificata automaticamente, ma è stato comunque necessario classificarne una porzione in modo manuale per poter avere un train/test set.
@ -204,12 +204,13 @@ In particolare un commit poteva citare:
L'analisi quantitativa è avvenuta attraverso un barplot in cui venivano riportati unicamente i commit a cui è stato possibile assegnare almeno una fase.
### RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
### RQ3: esiste una differenza di entropy tra ML bug e altri bug?
La successiva analisi avevo lo scopo di verificare l'esistenza di una differenza tra l'entropia del *fix* rispetto alla natura di questi.
L'analisi è stata svolta sia a livello di file, sia a livello di linee, quindi per ogni commit del dataset è stato necessario individuare sia il numero di file che hanno subito delle modifiche, sia il numero di linee alterate, considerando in questo modo sia le aggiunte che le rimozioni.
L'analisi è stata svolta sia a livello di file, sia a livello di linee quindi per ogni commit del dataset è stato necessario individuare sia il numero di file che hanno subito delle modifiche, sia il numero di linee alterate, considerando in questo modo sia le aggiunte che le rimozioni.
Il dato rispetto alle linee modificate è già presente nel dataset di partenza, mentre il numero di file modificati può essere ricavato dalla lista dei files modificati nel commit.
Inoltre per poter valutare l'entità del cambiamento è stato necessario conoscere anche il numero totale di file e di linee di ogni progetto.
Inoltre per poter calcolare la probabilità di un cambiamento è stato necessario conoscere anche il numero totale di file e di linee di ogni progetto.
Questi valori sono stati calcolati attraverso la storia `git` del branch `master`[^branch-master].
Per ogni commit sono stati individuati i file aggiunti ($+1$) e rimossi ($-1$) in modo tale da poter calcolare il delta-cambiamento del commit.
Eseguendo la somma di questo delta su tutti i commit si è ottenuto il numero totale di file del progetto.
@ -217,7 +218,10 @@ In modo analogo si è proceduto anche per quanto riguarda le linee.
[^branch-master]: Oltre al branch `master` è stato considerato anche il branch `main` diventato molto comune dopo le proteste del movimento Black Lives Matter e il branch `master-V2` unico branch utilizzato da un progetto.
### RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
Le due distribuzioni sono state valutate graficamente attraverso un boxplot.
Inoltre sono stati svolti dei test statistici (*ranksum* e *Cliff's delta*) per verificare la rilevanza di queste differenze.
### RQ4: come varia il livello di discussione tra ML bug e altri bug?
Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues.
Poiché un singolo commit può far riferimento a più issues è stato considerato il numero di commenti medi.
@ -226,7 +230,7 @@ A questo punto si è cercato di capire se al maggior numero di commenti è assoc
Per svolgere questa analisi si è partiti dal presupposto che la quantità di informazioni scambiate sia proporzionale al numero di parole utilizzate nel commento.
Quindi per ogni *issue* è stato calcolato il numero medio di parole presenti all'interno di un commento.
### RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
### RQ5: come varia il time-to-fix tra ML bug e altri bug?
In quest'ultima analisi si vuole andare a valutare se c'è differenza nel tempo necessario per eseguire il *fix*.
Per valutare questo parametro è stato necessario estrarre da ogni *issue* la data di apertura e di chiusura e calcolare i giorni che intercorrono tra queste.