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

Add conclusion

Browse Source
This commit is contained in:
Raffaele Mignone 2021-06-11 12:55:52 +02:00
parent a2ef42c747
commit d95724831a
Signed by: norangebit
GPG Key ID: F5255658CB220573
2 changed files with 34 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/chapter_3.md
View File

@ -1,6 +1,6 @@
# Analisi # Analisi
## RQ1: come il ML e' distribuito sull'architettura dei progetti? ## RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
In questa prima analisi si è andato a verificare l'esistenza di una differenza nei files e nelle directories modificate in base al tipo di cambiamento. In questa prima analisi si è andato a verificare l'esistenza di una differenza nei files e nelle directories modificate in base al tipo di cambiamento.
Per poter svolgere questa analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \acl{ML}. Per poter svolgere questa analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \acl{ML}.
@ -31,7 +31,7 @@ Dal boxplot riportato in @fig:imports si può notare che, indipendentemente dall
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. 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\%$. Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $25\%$ dei progetti abbia una percentuale di files di \ac{ML} superiore al $45\%$.
## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? ## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
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. 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. 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.
@ -44,7 +44,7 @@ I risultati di questa analisi sono riportati in @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*. 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. 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.
## RQ3: esiste una differenza di entropy tra ML bug e altri bug? ## RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
La successiva analisi avevo lo scopo di verificare l'esistenza di una differenza tra l'entropia del *fix* rispetto alla natura di questi. 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.
@ -86,7 +86,7 @@ In entrambi i casi, l'*effect size* è trascurabile.
: Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy} : Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}
## RQ4: come varia il livello di discussione tra ML bug e altri bug? ## RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues. 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. Poiché un singolo commit può far riferimento a più issues è stato considerato il numero di commenti medi.
@ -130,7 +130,7 @@ Inoltre, per entrambe le metriche, abbiamo un *effect size* medio.
: Risultati dei test statistici per quanto riguarda il livello di discussione {#tbl:test-discussion} : 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? ## RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
In quest'ultima analisi si vuole andare a valutare se c'è differenza nel tempo necessario per eseguire il *fix*. 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. 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.

29
src/chapter_4.md Normal file
View File

@ -0,0 +1,29 @@
# Conclusioni
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à.
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.
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 verso l'alto la metrica.
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 dalla 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.
## Sviluppi futuri
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*.
Per quanto riguarda la valutazione dell'entropia si è scelto come intervallo temporale di riferimento il singolo commit.
Utilizzando questa configurazione non si è riconcentrata 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.