From d95724831a5160278d1a935d32c3afb2f14b3ec5 Mon Sep 17 00:00:00 2001 From: norangebit Date: Fri, 11 Jun 2021 12:55:52 +0200 Subject: [PATCH] Add conclusion --- src/chapter_3.md | 10 +++++----- src/chapter_4.md | 29 +++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 5 deletions(-) create mode 100644 src/chapter_4.md diff --git a/src/chapter_3.md b/src/chapter_3.md index c7180fc..c97b3cb 100644 --- a/src/chapter_3.md +++ b/src/chapter_3.md @@ -1,6 +1,6 @@ # 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. 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. 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. 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*. 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. 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} -## 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. 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} -## 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*. 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. diff --git a/src/chapter_4.md b/src/chapter_4.md new file mode 100644 index 0000000..331daf9 --- /dev/null +++ b/src/chapter_4.md @@ -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. +