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

Refactor chapter 4

Browse Source
This commit is contained in:
Raffaele Mignone 2021-06-14 19:47:39 +02:00
parent 5a101736e6
commit ef54268718
Signed by: norangebit
GPG Key ID: F5255658CB220573
1 changed files with 111 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

133
src/chapter_4.md
View File

@ -1,29 +1,118 @@
# Conclusioni
# Risultati {#sec:results}
La *RQ1* (@sec:rq1) ci ha permesso di inquadrare la natura dei progetti considerati per questo studio.
Attraverso l'analisi degli import si è mostrato come l'utilizzo di librerie di \acl{ML} vari a seconda del progetto.
Da questo dato si può capire che i progetti all'interno del dataset sono diversi tra di loro e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
Si è anche visto che la percentuale di progetti con un numero di *source files* di \acl{ML} superiore al $45\%$ sia molto limitata.
Inoltre andando ad analizzare la porzione di sistema impattata dai cambiamenti si è visto come anche in questo caso il dato sia caratterizzato da una forte variabilità.
## RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
Le *RQ3*, *RQ4* e *RQ5* (da @sec:rq3) sono andate a valutare nello specifico le differenze in termini di entropia, discussione e *time-to-fix* tra gli interventi di *issue fixing* generici e quelli specifici del \acl{ML}.
Da queste analisi si evince che tra i due tipi di interventi ci sono sia similitudini che differenze.
Nel caso dell'entropia e della complessità del processo di cambiamento del software non sono emerse differenze rilevanti.
Questo ci porta a pensare che il processo di cambiamento non varia in base al tipo di intervento, ma sia costante.
Dalla @fig:files-directories si può notare che i cambiamenti generici vanno ad impattare su una superficie maggiore del sistema, sia che l'analisi sia svolta al livello di files che di directories.
Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \acl{ML} è caratterizzato da una maggiore varianza.
Nel caso del livello di discussione e del *time-to-fix* sono emerse delle differenze confermate anche dai test statistici effettuati.
In entrambi i casi l'essere un *fix* legato al \acl{ML} ha spinto la metrica verso l'alto.
Nel caso dei messaggi scambiati non solo si è riscontrato un numero medio di messaggi più elevato, ma si è visto anche che questi mediamente sono più lunghi.
Questo dato potrebbe dipendere sia dal maggiore tempo richiesto per d'individuazione e correzione delle problematiche legate al \ac{ML}, sia da un maggiore interesse per queste problematiche rispetto alle altre.
![Percentuale di files e directories modificate in base al tipo di cambiamento](figures/files-and-directories.pdf){#fig:files-directories width=80%}
## Sviluppi futuri
Nel boxplot in @fig:imports sono invece riportati i risultati per quanto riguarda l'utilizzo di import di \ac{ML}.
Si può notare che, indipendentemente dalla severità dell'analisi, la percentuale di file che utilizzano librerie di \acl{ML} è caratterizzata da una forte varianza.
Ciò indica che i progetti inclusi all'interno dello studio sono di varia natura e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $25\%$ dei progetti abbia una percentuale di files di \ac{ML} superiore al $45\%$.
Nella *RQ2* sfortunatamente non è stato possibile svolgere un'analisi più approfondita per la carenza di dati.
Un possibile sviluppo futuro potrebbe consistere nella realizzazione di un classificatore *multi-label* in grado di individuare la fase in cui il problema si è manifestato.
In questo modo non solo sarebbe possibile conoscere la fase per ogni intervento di *fix*, ma anche definire delle nuove analisi.
Per esempio si potrebbe andare a ricercare differenze in termini di entropia, discussione e *time-to-fix* in base alla fase in cui si è presentata la *issue*.
![Percentuale di file che utilizzano librerie di ML](figures/imports.pdf){#fig:imports width=70%}
Per quanto riguarda la valutazione dell'entropia si è scelto come intervallo temporale di riferimento il singolo commit.
Utilizzando questa configurazione non si è riscontrata nessuna differenza degna di nota.
Un possibile sviluppo futuro potrebbe consistere nell'andare a valutare l'entropia considerando dei riferimenti temporali più ampi e verificare in questo caso la presenza di differenze.
## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
Andando a confrontare la distribuzioni della fasi sui commit (@fig:count-fix-phases) rispetto alla distribuzione sulle issues (@fig:labeling-phases) è possibile notare la scomparsa della fase *data collection*.
Inoltre è evidente anche la riduzione delle occorrenze di *model training* e una crescita d'importanza per quanto riguarda le fasi di *model requirements* e *model deployment*.
Sfortunatamente i dati disponibili per questa analisi sono molto limitati (è stato possibile ricavare la fase solo per quaranta *fix*), per cui non è stato possibile effettuare delle analisi più approfondite.
![Istanze dei fix in base alla fase](figures/count-fix-phases.pdf){#fig:count-fix-phases width=70%}
## RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
Dal boxplot[^boxplot-entropy] in @fig:files-entropy è possibile notare una distribuzione equivalente per le due tipologie di fix.
Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-entropy) anche se in questo caso è possibile notare che i valori di entropia associati ai fix di \ac{ML} sono shiftati leggermente verso l'alto.
[^boxplot-entropy]: Per ragioni di visualizzazione è stato scelto il $95$-$esimo$ quantile come limite superiore di entrambi i grafici.
\begin{figure}[!ht]
\subfloat[Entropia calcolata sui files\label{fig:files-entropy}]{%
\includegraphics[width=0.45\textwidth]{src/figures/files-entropy.pdf}
}
\hfill
\subfloat[Entropia calcolata sulle linee\label{fig:lines-entropy}]{%
\includegraphics[width=0.45\textwidth]{src/figures/lines-entropy.pdf}
}
\caption{Entropia in base al tipo di fix}
\label{fig:entropy}
\end{figure}
Per verificare la rilevanza statistica di questa diversità sono stati svolti il *ranksum* test e il *Cliff's delta* i cui risultati sono riportati nella @tbl:test-entropy.
Nel caso dell'entropia sui file possiamo dire che la differenza è marginale poiché il *p-value* è prossimo a $0.05$, mentre nel caso dell'entropia calcolato sulle linee la differenza viene confermata dal test.
In entrambi i casi, però, l'*effect size* è trascurabile.
| | ranksum p-values | Cliff's delta |
|--------------|:----------------:|:-------------:|
| file entropy | 0.059 | 0.044 |
| line entropy | 5.932e-06 | 0.105 |
: Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}
\newpage
## RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
Osservando invece il boxplot[^boxplot-discussion] in @fig:discussion-comments si evince una differenza molto più marcata tra le due distribuzioni.
In particolare è possibile notare che le *issue fix* di \ac{ML} presentano una maggiore discussione e anche una maggiore varianza.
Se consideriamo la differenza interquartile, in modo da escludere completamente eventuali outlier, possiamo osservare che nei *fix* generici questa varia tra zero e uno.
Ciò vuol dire che il $50\%$ interno delle issues o non presenta commenti o ne presenta uno solo.
Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e cinque quindi nel $50\%$ interno tutte le issues hanno almeno un commento di risposta.
[^boxplot-discussion]: In questo caso il limite superiore è pari al $97$-$esimo$ quantile.
\begin{figure}[!ht]
\subfloat[Numero di commenti medi\label{fig:discussion-comments}]{%
\includegraphics[width=0.45\textwidth]{src/figures/comments.pdf}
}
\hfill
\subfloat[Numero di parole medie per commento\label{fig:discussion-words}]{%
\includegraphics[width=0.45\textwidth]{src/figures/words.pdf}
}
\caption{Livello di discussione in base al tipo}
\label{fig:discussion}
\end{figure}
I risultati di dell'analisi rispetto alle parole medie contenute in un commento sono riportati in @fig:discussion-words.
Anche in questo caso si può vedere che nel caso di \ac{ML} *fix* la distribuzione presenta valori più elevati e maggiore varianza.
Per cui non solo nei *fix* di \acl{ML} c'è maggiore discussione, ma la discussione è anche più *densa*.
Anche in questo caso sono stati svolti i test statistici.
In @tbl:test-discussion è possibile vedere come per entrambe le metriche considerate il *p-value* sia abbondantemente inferiore alla soglia di $0.05$ quindi abbiamo una conferma della diversità delle due distribuzioni riscontrata dal boxplot.
Inoltre, per entrambe le metriche, abbiamo un *effect size* medio.
| | ranksum p-values | Cliff's delta |
|---------------------|:----------------:|:-------------:|
| commenti medi | 9.053e-75 | 0.425 |
| parole per commento | 2.889e-59 | 0.377 |
: Risultati dei test statistici per quanto riguarda il livello di discussione {#tbl:test-discussion}
## RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
Anche in questo caso, osservando la @fig:day-to-fix, è possibile notare una netta differenza tra i *fix* di \ac{ML} e gli altri.
In particolare i bug di \acl{ML} necessitano, mediamente, di maggior tempo per essere risolti e sono caratterizzati da una varianza maggiore.
Inoltre è possibile vedere come la mediana non sia centrata, bensì spostata verso il basso.
Questo vuol dire che il $50\%$ basso dei *bug* di \ac{ML} viene comunque risolto in tempi brevi (due giorni circa), mentre l'altro $50\%$ può richiedere una quantità di tempo decisamente superiore.
![Giorni necessari per il fix](figures/day-to-fix.pdf){#fig:day-to-fix width=70%}
Un'ulteriore testimonianza del maggior tempo necessario per risolvere le problematiche legate al \ac{ML} ci viene data dagli outlier.
Nel caso di un problema generico, questo, viene considerato come *anomalo* se per essere risolto necessita di un tempo superiore ai cinque giorni.
Mentre nel caso dei *fix* di \acl{ML} per essere considerato outlier un *issue*, necessaria di un *time-to-fix* superiore ai trentacinque giorni.
Il maggior tempo necessario ad attuare la correzione indica che i *bug* di \ac{ML} sono più difficili da individuare e correggere rispetto a quelli generici.
Inoltre questo risultato contribuisce a spiegare il dato emerso dalla sezione precedente, in quanto per individuare la fonte del problema sembrerebbe essere necessaria una discussione più approfondita.
Anche per quest'ultima *RQ* sono stati svolti i test statistici illustrati precedentemente.
Dai risultati riportati in @tbl:test-time-to-fix è possibile notare un *p-value* inferiore a $0.05$ e un *effect size* medio.
| | ranksum p-values | Cliff's delta |
|------------|:----------------:|:-------------:|
| day-to-fix | 7.354e-53 | 0.355 |
: Risultati dei test statistici per quanto riguarda il time-to-fix {#tbl:test-time-to-fix}