From ef542687188d93f8824b8e5ebbb6dd56e58b9b0d Mon Sep 17 00:00:00 2001 From: norangebit Date: Mon, 14 Jun 2021 19:47:39 +0200 Subject: [PATCH] Refactor chapter 4 --- src/chapter_4.md | 133 +++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 111 insertions(+), 22 deletions(-) diff --git a/src/chapter_4.md b/src/chapter_4.md index d1348d3..13b9b68 100644 --- a/src/chapter_4.md +++ b/src/chapter_4.md @@ -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}