Update draft
This commit is contained in:
parent
6811642d58
commit
d05ab73303
GPG Key ID:
F5255658CB220573
|
|
@ -1,6 +1,6 @@
|
|||
# Introduzione
|
||||
|
||||
La storia dell'industria dello sviluppo software è caratterizzata da diversi cambiamenti rispetto alle applicazioni dominanti.
|
||||
Lo sviluppo del software è stato caratterizzato da diversi cambiamenti rispetto alle applicazioni dominanti.
|
||||
Negli anni ottanta il paradigma dominante era quello dei personal computer, poi abbiamo avuto Internet a cui è seguita la nascita del Web al \ac{CERN}.
|
||||
Nel 2007 con l'annuncio del primo iPhone è inizia l'era del *mobile computing* a cui è seguita quella del *cloud computing*.
|
||||
Negli ultimi anni l'industria non è stata a guardare, ma ha dato vita a sempre più prodotti che fanno uso di \ac{AI} e \ac{ML}.
|
||||
|
|
@ -20,16 +20,16 @@ In questo caso però la ricerca di differenze è legata agli interventi di *issu
|
|||
|
||||
## Obiettivi della tesi {#sec:goals}
|
||||
|
||||
Questo studio vuole verificare la presenza di differenze, all'interno di progetti di \ac{ML}, rispetto a come sono trattate le *issues* legate a tematiche di \ac{ML} e quelle generiche.
|
||||
In particolare si vuole capire come la risoluzione di queste problematiche va ad impattare sull'architettura, sia in termini di moduli modificati sia in termini di entropia generata.
|
||||
Questo studio vuole verificare la presenza di differenze, all'interno di progetti di \ac{ML}, rispetto a come sono trattate le *issue* legate a tematiche di \ac{ML} e quelle generiche.
|
||||
In particolare si vuole investigare come la risoluzione di queste problematiche va ad impattare sull'architettura, sia in termini di moduli modificati sia in termini di entropia generata.
|
||||
Si vuole anche scoprire se sono presenti delle fasi del processo di sviluppo che sono più critiche di altre.
|
||||
Infine si vuole capire se le *issues* sono trattate tutte allo stesso modo per quanto riguarda il livello di discussione e il tempo necessario alla loro risoluzione.
|
||||
Infine si vuole comprendere se le *issue* sono trattate tutte allo stesso modo per quanto riguarda il livello di discussione e il tempo necessario alla loro risoluzione.
|
||||
|
||||
## Struttura della tesi
|
||||
|
||||
Nella sezione [-@sec:related-works] viene svolta una panoramica sullo stato dell'arte.
|
||||
Nella sezione [-@sec:methodology] vengono presentate le \ac{RQ}, viene descritta la procedura utilizzata per la raccolta dei commit e delle issues e come queste sono state classificate.
|
||||
Nel capitolo [-@sec:related-works] viene svolta una panoramica sullo stato dell'arte.
|
||||
Nel capitolo [-@sec:methodology] vengono presentate le \ac{RQ}, viene descritta la procedura utilizzata per la raccolta dei commit e delle issue e come queste sono state classificate.
|
||||
Inoltre viene illustrata la metodologia di analisi impiegata per lo studio di ogni *\ac{RQ}*.
|
||||
I risultati delle analisi e una discussione qualitativa su alcuni *casi estremi* sono riportati nella sezione [-@sec:results].
|
||||
Infine la sezione [-@sec:conclusions] chiude questa tesi.
|
||||
I risultati delle analisi e una discussione qualitativa su alcuni *casi estremi* sono riportati nel capitolo [-@sec:results].
|
||||
Infine il capitolo [-@sec:conclusions] chiude questa tesi.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@ In alcuni casi l'attenzione principale è rivolta alle difficoltà e alle proble
|
|||
In altri casi viene svolto un confronto tra progetti di \ac{ML} e progetti generici o tra progetti che fanno uso di diversi framework di \ac{ML}.
|
||||
Infine viene anche presentato un lavoro sulla complessità del processo di cambiamento del software e su i suoi effetti sull'introduzione di difetti.
|
||||
|
||||
## Confronto tra progetti di machine learning e progetti generici
|
||||
\section[Confronto tra progetti di ML e progetti generici]{Confronto tra progetti di machine learning e progetti generici}
|
||||
|
||||
Nello studio di Gonzalez *et al.* [@gonzalez2020statemluniverse10] ci vengono presentate le principali differenze tra i repository di \ac{ML} e i progetti classici.
|
||||
Nello studio di Gonzalez *et al.* [@gonzalez2020statemluniverse10] vengono presentate le principali differenze tra i repository di \ac{ML} e i progetti classici.
|
||||
I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposizione di GitHub attraverso la quale è stato possible collezionare i dati associati a 9325 progetti open source così raggruppati:
|
||||
|
||||
- 5224 progetti legati all'\ac{AI} e al \ac{ML} divisi a loro volta in:
|
||||
|
|
@ -17,19 +17,19 @@ I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposi
|
|||
- 4101 progetti generici
|
||||
|
||||
Gli aspetti considerati dallo studio sono molteplici e di varia natura.
|
||||
Una prima analisi è stata condotta rispetto alla nascita dei vari repositories.
|
||||
In questo modo è stato possibile individuare nel 2017 l'anno del *boom* dei repositori di \ac{AI} & \ac{ML}.
|
||||
Una prima analisi è stata condotta rispetto alla nascita dei vari repository.
|
||||
In questo modo è stato possibile individuare nel 2017 l'anno della forte crescita dei repository di \ac{AI} & \ac{ML}.
|
||||
Infatti questo è stato il primo anno in cui sono stati creati più progetti legati al \ac{ML} rispetto a quelli generici.
|
||||
|
||||
Una seconda analisi ha permesso di capire come varia la partecipazione ai vari progetti.
|
||||
Una seconda analisi ha permesso di comprendere come varia la partecipazione ai vari progetti.
|
||||
Per poter svolgere questa analisi i contributori sono stati divisi in:
|
||||
|
||||
- *esterni*: i loro contributi sono limitati ad aprire *issues* e commentare le discussioni.
|
||||
- *interni*: oltre a svolgere i compiti precedentemente elencati devono anche aver chiuso delle issues o eseguito dei commit sul progetto.
|
||||
- *esterni*: i loro contributi sono limitati ad aprire *issue* e commentare le discussioni.
|
||||
- *interni*: oltre a svolgere i compiti precedentemente elencati devono anche aver chiuso delle issue o eseguito dei commit sul progetto.
|
||||
|
||||
In base a questa divisione si è visto come i tools di \ac{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici.
|
||||
Quest'ultimi però hanno una maggiore partecipazione esterna.
|
||||
Se invece l'analisi viene svolta considerando unicamente gli autori dei commit si scopre che i progetti generici mediamente hanno più *contributors*, ma i top 4 repositories con più committer sono tutti legati al mondo del \ac{ML}.
|
||||
Se invece l'analisi viene svolta considerando unicamente gli autori dei commit si scopre che i progetti generici mediamente hanno più *contributors*, ma i top 4 repository con più committer sono tutti legati al mondo del \ac{ML}.
|
||||
|
||||
Un'ulteriore analisi è stata svolta anche per quanto riguarda il linguaggio con cui sono stati realizzati i vari progetti.
|
||||
Sia nel caso delle applicazioni che nei tools di \ac{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia.
|
||||
|
|
@ -51,7 +51,7 @@ Come obiettivi dei progetti sono stati considerati:
|
|||
- *Competitions*: progetti realizzati per la partecipazione a delle competizioni o sfide.
|
||||
- *Learning & Teaching*: progetti realizzati per libri e/o tutorial o per esercitarsi.
|
||||
- *Paper Experiments*: progetti realizzati al fine di ricerca.
|
||||
- *Software Development*: comprende librerie, plug-in, tools ecc.a
|
||||
- *Software Development*: comprende librerie, plug-in, tools ecc.
|
||||
- *Other*
|
||||
|
||||
La classifica delle librerie più utilizzate è rimasta sostanzialmente invariata per tutte le categorie; il primo posto è occupato da `TensorFlow` seguito da `PyTorch` e `Theano`.
|
||||
|
|
@ -60,7 +60,7 @@ In questo caso `TensorFlow` e `PyTorch` sono in posizioni invertite.
|
|||
Anche per quanto riguarda la classificazione rispetto al dominio applicativo la situazione è costante.
|
||||
Infatti, indipendentemente dalla libreria utilizzata, i progetti più frequenti sono quelli che hanno a che fare con video e immagini e con il \ac{NLP}.
|
||||
|
||||
Un'ulteriore \ac{RQ} è andata a valutare il tipo di dipendenza, facendo distinzione tra dipendenze dirette e indirette.
|
||||
Un'ulteriore \ac{RQ} ha valutato il tipo di dipendenza, facendo distinzione tra dipendenze dirette e indirette.
|
||||
Per tutte è tre le librerie si è visto che è più probabile avere una dipendenza diretta che indiretta.
|
||||
`PyTorch` è la libreria che più frequentemente è importata direttamente, mentre `Theano` ha una probabilità di essere importata direttamente quasi uguale a quella di essere importata indirettamente.
|
||||
|
||||
|
|
@ -70,7 +70,7 @@ Mentre il tasso di downgrade è sostanzialmente equivalente.
|
|||
Nel caso dei progetti che dipendono da `TensorFlow` la maggior parte dei downgrade viene spiegata dalla volontà di non utilizzare la nuova \ac{API} introdotta nella versione 2.0 della libreria.
|
||||
Sempre analizzando la versione della libreria utilizzata si è visto che i progetti basati su `Theano` sono quelli che utilizzano più frequentemente l'ultima versione disponibile della libreria.
|
||||
|
||||
In un altro lavoro di Han *et al.* [@han2020whatprogrammersdiscuss] il focus si sposta sugli argomenti di discussione e su come questi variano in base al framework utilizzato.
|
||||
In un altro lavoro, Han *et al.* [@han2020whatprogrammersdiscuss] hanno spostato il focus sugli argomenti di discussione e su come questi variano in base al framework utilizzato.
|
||||
In questo caso all'interno dei dataset non sono rientrati unicamente i dati recuperati da GitHub, ma anche le discussioni su \ac{SO}.
|
||||
|
||||
Questo studio ha permesso di evidenziare differenze e similitudini per quanto riguarda le discussioni che si generano intorno ai tre framework di interesse.
|
||||
|
|
@ -84,11 +84,11 @@ Da questi due studi si evince una forte somiglianza per quanto riguarda `TensorF
|
|||
La principale differenza viene riscontrata per quanto riguarda i campi di applicazione, con `TensorFlow` che viene generalmente preferito fatti salvi gli ambiti di ricerca.
|
||||
Mentre `Theano` presenta molte diversità sia per quanto riguarda gli impieghi che le discussioni.
|
||||
|
||||
## Analisi dei progetti di machine learning multi-linguaggio
|
||||
\section[Analisi dei progetti di ML multi-linguaggio]{Analisi dei progetti di machine learning multi-linguaggio}
|
||||
|
||||
Lo studio di Grichi *et al.* [@grichi2020impactmultilanguagedevelopment] si concentra sui sistemi *multi-linguaggio*.
|
||||
In questo caso si vuole capire se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi.
|
||||
Inoltre analizzando le \ac{PR} realizzate in più linguaggi si vuole capire se queste sono accettate con la stessa frequenza di quelle *mono-linguaggio* e se la presenza di difetti è equivalente.
|
||||
In questo caso si vuole comprendere se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi.
|
||||
Inoltre analizzando le \ac{PR} realizzate in più linguaggi si vuole investigare se queste sono accettate con la stessa frequenza di quelle *mono-linguaggio* e se la presenza di difetti è equivalente.
|
||||
|
||||
L'analisi è stata svolta su 27 progetti open source hostati su GitHub.
|
||||
I progetti sono poi stati classificati in tre categorie:
|
||||
|
|
@ -98,7 +98,7 @@ I progetti sono poi stati classificati in tre categorie:
|
|||
- Cat III: include 7 sistemi di \ac{ML} *mono-linguaggio*.
|
||||
|
||||
Successivamente sono state scaricate le \ac{PR} di ogni progetto considerato.
|
||||
Le \ac{PR}s sono state categorizzate per individuare quelle accettate e quelle rifiutate.
|
||||
Le \ac{PR} sono state categorizzate per individuare quelle accettate e quelle rifiutate.
|
||||
Inoltre le \ac{PR} sono state categorizzate anche il base al numero di linguaggi utilizzati.
|
||||
In questo modo è stato possibile individuare le \ac{PR} *mono-linguaggio* e quelle *multi-linguaggio*.
|
||||
Infine per ogni \ac{PR} è stato individuato il tempo necessario alla sua accettazione o chiusura e i difetti introdotti dalla \ac{PR}.
|
||||
|
|
@ -107,14 +107,14 @@ Per quanto riguarda la percentuale di linguaggi di programmazione utilizzati i p
|
|||
La principale differenza riguarda i tipi di linguaggi utilizzati.
|
||||
Nel caso dei progetti *multi-linguaggio* di \ac{ML} l'accoppiata più comune è Python e C/C++.
|
||||
Mentre nel caso dei progetti generici la coppia più comune è data da Java e C/C++.
|
||||
I progetti della categoria I e II sono paragonabili anche rispetto al numero di \ac{PR}s e \ac{PR}s *multi-linguaggio*.
|
||||
I progetti della categoria I e II sono paragonabili anche rispetto al numero di \ac{PR} e \ac{PR} *multi-linguaggio*.
|
||||
|
||||
Lo studio ha evidenziato come all'interno dei progetti di \ac{ML} le \ac{PR} *mono-linguaggio* sono accettate molto più facilmente rispetto a quelle *multi-linguaggio*.
|
||||
Inoltre anche nel caso in cui queste vengano accettate, il tempo necessario alla loro accettazione è maggiore.
|
||||
Infine si è visto anche che rispetto alle \ac{PR}s *multi-linguaggio* non esistono differenze in base all'introduzione di *bug* tra i progetti della categoria I e II.
|
||||
Infine si è visto anche che rispetto alle \ac{PR} *multi-linguaggio* non esistono differenze in base all'introduzione di *bug* tra i progetti della categoria I e II.
|
||||
Mentre le \ac{PR} che includono un singolo linguaggio sembrano essere più affette da *bug* nel caso dei sistemi di \ac{ML}.
|
||||
|
||||
## Problematiche caratteristiche del machine learning
|
||||
\section[Problematiche caratteristiche del ML]{Problematiche caratteristiche del machine learning}
|
||||
|
||||
In letteratura sono presenti anche lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \ac{ML}.
|
||||
Nello studio di Zhang *et al.* [@zhang2018empiricalstudytensorflow] l'attenzione è rivolta unicamente alle problematiche correlate a `TensorFlow`.
|
||||
|
|
@ -160,11 +160,11 @@ Tra le categorie di primo livello ci sono:
|
|||
|
||||
Come si può notare, fatta salva la specificità del primo lavoro, esiste una forte similitudine tra le categorie di problemi individuate dai due studi.
|
||||
|
||||
## Studio di discussioni Stack Overflow riguardanti il ML
|
||||
\section[Studio di discussioni Stack Overflow riguardanti il ML]{Studio di discussioni Stack Overflow riguardanti il machine learning}
|
||||
|
||||
Nello studio di Bangash *et al.* [@bangash2019whatdevelopersknow] viene svolta un'analisi degli argomenti di \ac{ML} discussi più frequentemente dagli sviluppatori.
|
||||
In questo caso, a differenza dello studio di Han *et al.* [@han2020whatprogrammersdiscuss] discusso precedentemente, non viene svolta alcuna distinzione in base alla libreria utilizzata.
|
||||
Inoltre questo studio utilizza unicamente informazioni recuperate da \ac{SO}, mentre l'altro lavoro univa le domande di \ac{SO} alla discussione generata all'interno dei repositories di GitHub.
|
||||
Inoltre questo studio utilizza unicamente informazioni recuperate da \ac{SO}, mentre l'altro lavoro univa le domande di \ac{SO} alla discussione generata all'interno dei repository di GitHub.
|
||||
|
||||
In questo caso il topic più frequentemente discusso riguarda la presenza di errori all'interno del codice.
|
||||
Seguono discussioni rispetto agli algoritmi di apprendimento e al training dei dati.
|
||||
|
|
@ -201,7 +201,7 @@ Infine lo studio ha mostrato come, nonostante la vasta adozione, molti utenti ri
|
|||
|
||||
## Entropia di un cambiamento {#sec:entropy}
|
||||
|
||||
Nello studio di Hassan [@hassan2009predictingfaultsusing] si vuole capire in che modo la complessità del processo del cambiamento del software vada ad impattare sull'introduzione di difetti all'interno della codebase.
|
||||
Nello studio di Hassan [@hassan2009predictingfaultsusing] si vuole investigare in che modo la complessità del processo del cambiamento del software vada ad impattare sull'introduzione di difetti all'interno della codebase.
|
||||
Per valutare la complessità del processo di cambiamento è stato *preso in prestito* il concetto di entropia [@shannon1948mathematicaltheorycommunication] utilizzato nella teoria della comunicazione.
|
||||
|
||||
Lo studio è stato condotto su sei progetti open source di grandi dimensioni.
|
||||
|
|
|
|||
124
src/chapter_3.md
124
src/chapter_3.md
|
|
@ -2,29 +2,29 @@
|
|||
|
||||
L'obiettivo di questa tesi è verificare la presenza di differenza all'interno di progetti di \ac{ML} rispetto a come sono trattati gli interventi di *issue fixing* legati al \ac{ML} e quelli generici.
|
||||
L'attenzione è rivolta all'impatto degli interventi sull'architettura del sistema, alle tempistiche necessarie alla risoluzione e al livello di discussione di questi difetti.
|
||||
Inoltre si vuole anche capire se esistono delle fasi del processo di sviluppo che sono più critiche di altre.
|
||||
Inoltre si vuole anche comprendere se esistono delle fasi del processo di sviluppo che sono più critiche di altre.
|
||||
|
||||
## Research Questions
|
||||
|
||||
Gli obiettivi di questa tesi sono stati racchiusi in cinque \ac{RQ} di seguito elencate.
|
||||
|
||||
- **RQ1**: *come il \ac{ML} e' distribuito sull'architettura dei progetti?*
|
||||
- **RQ1**: *come il machine learning e' distribuito sull'architettura dei progetti?*
|
||||
|
||||
In questa *\ac{RQ}* si vuole investigare l'architettura dei progetti.
|
||||
In particolare l'attenzione viene concentrata sui files e sulle directories modificate durante interventi di *issues fixing*.
|
||||
Obiettivo di questa domanda è anche individuare la percentuale di files che utilizzano import riconducibili a librerie e framework di \ac{ML}.
|
||||
- **RQ2**: *come sono distribuiti i bug sulle diverse fasi di \ac{ML}?*
|
||||
In particolare l'attenzione viene concentrata sui file e sulle directory modificate durante interventi di *issue fixing*.
|
||||
Obiettivo di questa domanda è anche individuare la percentuale di file che utilizzano import riconducibili a librerie e framework di \ac{ML}.
|
||||
- **RQ2**: *come sono distribuiti i bug sulle diverse fasi di machine learning?*
|
||||
|
||||
Il workflow tipico per lo sviluppo di un'applicazione di \ac{ML} si compone di più fasi.
|
||||
L'obiettivo di questa *\ac{RQ}* è quello di individuare le fasi più critiche per quanto riguarda l'introduzione di difetti all'interno del prodotto software.
|
||||
- **RQ3**: *esiste una differenza di entropy tra \ac{ML} bug e altri bug?*
|
||||
- **RQ3**: *esiste una differenza di entropia del cambiamento tra machine learning bug e altri bug?*
|
||||
|
||||
A partire dai lavori precedenti svolti sull'entropia di un cambiamento, si vuole capire se esiste una differenza in termini di entropia generata tra le correzioni dei difetti ascrivibili al \ac{ML} e gli altri difetti.
|
||||
- **RQ4**: *come varia il livello di discussione tra \ac{ML} bug e altri bug?*
|
||||
A partire dai lavori precedenti svolti sull'entropia di un cambiamento, si vuole investigare se esiste una differenza in termini di entropia generata tra le correzioni dei difetti ascrivibili al \ac{ML} e gli altri difetti.
|
||||
- **RQ4**: *come varia il livello di discussione tra machine learning bug e altri bug?*
|
||||
|
||||
Questa *\ac{RQ}* riguarda il livello di discussione dei *bug*.
|
||||
In particolare si vuole capire se, all'interno dei progetti di \ac{ML}, i bug generici sono discussi con lo stesso livello di approfondimento di quelli specifici del \ac{ML}.
|
||||
- **RQ5**: *come varia il time-to-fix tra \ac{ML} bug e altri bug?*
|
||||
In particolare si vuole comprendere se, all'interno dei progetti di \ac{ML}, i bug generici sono discussi con lo stesso livello di approfondimento di quelli specifici del \ac{ML}.
|
||||
- **RQ5**: *come varia il time-to-fix tra machine learning bug e altri bug?*
|
||||
|
||||
Un altro aspetto caratteristico di un *fix* è il tempo necessario per poter essere attuato.
|
||||
Questa *\ac{RQ}* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \ac{ML}.
|
||||
|
|
@ -37,37 +37,37 @@ In questo modo è stato possibile ottenere una lista di $26758$ repository che
|
|||
|
||||
L'operazione di filtraggio è avvenuta attraverso due fasi; una prima automatica e una seconda manuale.
|
||||
La prima fase ha avuto l'obiettivo di selezionare unicamente i repository *popolari*.
|
||||
Nella maggior parte dei casi viene utilizzato il numero di stelle come indice della popolarità di un progetto [@borges2016understandingfactorsthat], ma per questo lavoro si è preferito dare maggiore rilevanza ad altri aspetti, come il numero di fork, il numero di *contributors* e il numero di issues chiuse.
|
||||
Nella maggior parte dei casi viene utilizzato il numero di stelle come indice della popolarità di un progetto [@borges2016understandingfactorsthat], ma per questo lavoro si è preferito dare maggiore rilevanza ad altri aspetti, come il numero di fork, il numero di *contributors* e il numero di issue chiuse.
|
||||
Questa scelta è stata dettata dall'esigenza di selezionare non solo repository popolari, ma anche caratterizzati da una forte partecipazione della community.
|
||||
|
||||
I progetti che hanno superato questa prima selezione dovevano:
|
||||
|
||||
- essere lavori originali, per cui sono stati esclusi tutti i fork.
|
||||
- avere almeno cento issues chiuse.
|
||||
- avere almeno cento issue chiuse.
|
||||
- avere almeno dieci contributors.
|
||||
- avere almeno venticinque fork.
|
||||
|
||||
Alla fine di questa prima selezione il numero di repository si è ridotto a sessantasei e sono stati analizzati manualmente per rimuovere listati associati a libri e/o tutorial, progetti non in lingua inglese e librerie.
|
||||
Alla fine di questa seconda fase il numero di progetti è sceso a trenta.
|
||||
|
||||
## Fetch di issues e commit
|
||||
## Fetch di issue e commit
|
||||
|
||||
Una volta individuati i progetti da analizzare si è reso necessario recuperare l'intera storia dei progetti e le issues ad essi associate.
|
||||
Una volta individuati i progetti da analizzare si è reso necessario recuperare l'intera storia dei progetti e le issue ad essi associate.
|
||||
Per entrambe le operazioni è stato utilizzato il tool *perceval* [@duenas2018percevalsoftwareproject].
|
||||
Nel caso delle issues, essendo queste informazioni non direttamente contenute all'interno del repository `git`, è stato necessario utilizzare nuovamente l'\ac{API} di GitHub.
|
||||
Nel caso delle issue, essendo queste informazioni non direttamente contenute all'interno del repository `git`, è stato necessario utilizzare nuovamente l'\ac{API} di GitHub.
|
||||
Poiché le chiamate associate ad un singolo *token* sono limitate nel tempo si è scelto di configurare *perseval* in modo tale da introdurre in automatico un ritardo ogni qualvolta veniva raggiunto il limite.
|
||||
Inoltre il codice è stato dispiegato su un \ac{VPS} in modo da poter eseguire il fetch senza che fosse necessario mantenere attiva una macchina fisica.
|
||||
|
||||
Con il processo precedentemente illustrato è stato possibile recuperare:
|
||||
|
||||
- $34180$ commit.
|
||||
- $15267$ tra issues e pull request.
|
||||
- $15267$ tra issue e pull request.
|
||||
|
||||
## Classificazione dei dati
|
||||
|
||||
### Classificazione delle issues {#sec:classificazione-issues}
|
||||
### Classificazione delle issue {#sec:classificazione-issues}
|
||||
|
||||
Al fine di poter eseguire un confronto tra i *fix* di \ac{ML} e quelli *generici* è stato necessario classificare sia le issues che i commit.
|
||||
Al fine di poter eseguire un confronto tra i *fix* di \ac{ML} e quelli *generici* è stato necessario classificare sia le issue che i commit.
|
||||
Il numero elevato di elementi non rende praticabile una classificazione manuale per cui si è optato per una classificazione automatica.
|
||||
Per quanto riguarda i primi si è scelto di attuare una classificazione basata sul testo, in particolare considerando il titolo e il corpo della issue, ma escludendo i commenti di risposta in modo da non rendere i dati troppo rumorosi.
|
||||
A tal fine sono stati implementati ed analizzati due classificatori, uno supervisionato e uno non supervisionato.
|
||||
|
|
@ -79,11 +79,11 @@ I due modelli considerati sono:
|
|||
|
||||
La classificazione mediante il classificatore statico non necessita di un *labeling* manuale dei dati, ma richiede la definizione dei vocaboli tipici del \ac{ML}.
|
||||
La lista dei termini caratteristici del \ac{ML} non è stata costruita da zero, ma è basata sul lavoro di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults].
|
||||
In questo modo tutte le issues che utilizzavano almeno un vocabolo tipico del \ac{ML} sono state classificate come issues di \ac{ML}.
|
||||
In questo modo tutte le issue che utilizzavano almeno un vocabolo tipico del \ac{ML} sono state classificate come issue di \ac{ML}.
|
||||
|
||||
Nel caso del modello *naïve Bayes*, essendo questo un algoritmo di apprendimento supervisionato, si è resa necessaria una classificazione manuale delle issues.
|
||||
A tal scopo è stato eseguito un campionamento stratificato in base al progetto di provenienza di $376$ issues che sono state divise tra due lettori e labellate.
|
||||
La label delle *issues* è stata determinata andando ad analizzare il titolo, il corpo e i commenti associati alla *issue*.
|
||||
Nel caso del modello *naïve Bayes*, essendo questo un algoritmo di apprendimento supervisionato, si è resa necessaria una classificazione manuale delle issue.
|
||||
A tal scopo è stato eseguito un campionamento stratificato in base al progetto di provenienza di $376$ issue che sono state divise tra due lettori e labellate.
|
||||
La label delle *issue* è stata determinata andando ad analizzare il titolo, il corpo e i commenti associati alla *issue*.
|
||||
Durante il labeling si è scelto di classificare ulteriormente le issue di \ac{ML} al fine di individuare anche la fase in cui il problema si è palesato.
|
||||
La definizione delle varie fasi è avvenuta partendo dal lavoro di Amershi *et al.* [@amershi-2019-softwareengineeringmachine] realizzato nei laboratori di *Microsoft*.
|
||||
|
||||
|
|
@ -106,32 +106,32 @@ A partire dal dataset *labellato* è stato possibile costruire un training e un
|
|||
Mentre le performance del primo modello sono state valutate sull'intero dataset.
|
||||
|
||||
\begin{figure}[!ht]
|
||||
\subfloat[Numero di issues rispetto al tipo\label{fig:labeling-type}]{%
|
||||
\subfloat[Numero di issue rispetto al tipo\label{fig:labeling-type}]{%
|
||||
\includegraphics[width=0.45\textwidth]{src/figures/count-type.pdf}
|
||||
}
|
||||
\hfill
|
||||
\subfloat[Numero di issues rispetto alla fase\label{fig:labeling-phases}]{%
|
||||
\subfloat[Numero di issue rispetto alla fase\label{fig:labeling-phases}]{%
|
||||
\includegraphics[width=0.45\textwidth]{src/figures/count-phases.pdf}
|
||||
}
|
||||
\caption{Risultati della classificazione manuale delle issues}
|
||||
\caption{Risultati della classificazione manuale delle issue}
|
||||
\label{fig:labeling}
|
||||
\end{figure}
|
||||
|
||||
Al fine di poter confrontare i due modelli sono state utilizzate le metriche di *precision* e *recall*.
|
||||
Com'è possibile notare dai valori riportati in @tbl:confronto-modelli-classificazione-issues, il modello basato sulla lista di vocaboli è leggermente più preciso del modello bayesiano, ma presenta una *recall* decisamente più bassa.
|
||||
Dalla @fig:labeling-type si evince la natura minoritaria delle issues di \ac{ML} rispetto alle issues generiche, per questo motivo si è preferito il modello naïve Bayes in modo da perdere quante meno istanze possibili anche a costo di sacrificare leggermente la precisione.
|
||||
Dalla @fig:labeling-type si evince la natura minoritaria delle issue di \ac{ML} rispetto alle issue generiche, per questo motivo si è preferito il modello naïve Bayes in modo da perdere quante meno istanze possibili anche a costo di sacrificare leggermente la precisione.
|
||||
|
||||
| | Classificatore statico | naïve Bayes |
|
||||
|-----------|------------------------|-------------|
|
||||
| precision | 0.46 | 0.41 |
|
||||
| recall | 0.74 | 0.94 |
|
||||
|
||||
: Confronto dei due modelli per la classificazione delle issues. {#tbl:confronto-modelli-classificazione-issues}
|
||||
: Confronto dei due modelli per la classificazione delle issue. {#tbl:confronto-modelli-classificazione-issues}
|
||||
|
||||
### Classificazione dei commit {#sec:classificazione-commit}
|
||||
|
||||
Prima di poter classificare i commit si è reso necessaria un'ulteriore fase di filtraggio in modo da poter separare i commit di *issue fixing* da quelli generici.
|
||||
Sono stati considerati come commit di *fix* tutti quei commit al cui interno veniva fatto riferimento a delle *issues* attraverso la notazione *"#"*.
|
||||
Sono stati considerati come commit di *fix* tutti quei commit al cui interno veniva fatto riferimento a delle *issue* attraverso la notazione *"#"*.
|
||||
Questa operazione ha ridotto il dataset dei commit a $3321$ unità la cui distribuzione in base al tipo è riportata in @fig:count-commit.
|
||||
|
||||
Da ogni commit sono state estratte le informazioni rilevanti per le analisi.
|
||||
|
|
@ -141,23 +141,23 @@ In particolare è stato conservato:
|
|||
- L'hash del commit.
|
||||
- La data del commit.
|
||||
- L'autore del commit.
|
||||
- La lista dei files modificati.
|
||||
- La lista dei file modificati.
|
||||
- Le linee modificate.
|
||||
- La lista delle *issues* citate.
|
||||
|
||||
A questo punto è stato possibile separare i *fix* di \ac{ML} da quelli generici.
|
||||
La classificazione è avvenuta attraverso la lista delle issues citate all'interno del *commit message* e sono stati considerati come commit di \ac{ML} tutti quei commit che facevano riferimento ad almeno una issue di \ac{ML}.
|
||||
|
||||
{#fig:count-commit width=80%}
|
||||
- La lista delle *issue* citate.
|
||||
|
||||
\newpage
|
||||
|
||||
A questo punto è stato possibile separare i *fix* di \ac{ML} da quelli generici.
|
||||
La classificazione è avvenuta attraverso la lista delle issue citate all'interno del *commit message* e sono stati considerati come commit di \ac{ML} tutti quei commit che facevano riferimento ad almeno una issue di \ac{ML}.
|
||||
|
||||
{#fig:count-commit width=80%}
|
||||
|
||||
## Metodologia
|
||||
|
||||
### RQ1: come il ML e' distribuito sull'architettura dei progetti?
|
||||
### RQ1: come il machine learning 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 \ac{ML}.
|
||||
Inoltre si vuole anche comprendere quanti file importano librerie tipiche del \ac{ML}.
|
||||
|
||||
Per poter svolgere la prima analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \ac{ML}.
|
||||
A tal fine i commit sono stati raggruppati rispetto al progetto e al tipo di cambiamento (\ac{ML}, no \ac{ML}).
|
||||
|
|
@ -168,15 +168,15 @@ Come output di questa fase si è ottenuto per ogni progetto:
|
|||
- l'insieme dei file modificati per *fix* di \ac{ML}
|
||||
- l'insieme dei file modificati per fix generici
|
||||
|
||||
Infine eseguendo l'union set tra questi due insiemi si è ottenuto l'insieme totale dei files modificati durante i *fix*.
|
||||
Infine eseguendo l'union set tra questi due insiemi si è ottenuto l'insieme totale dei file modificati durante i *fix*.
|
||||
A questo punto per ogni progetto si è calcolata la percentuale di file modificati durante interventi di *fix* di \ac{ML} (`ml_file_ratio`) e la percentuale di file modificati durante *fix* generici (`no_ml_file_ratio`).
|
||||
|
||||
Attraverso la funzione di libreria Python `os.path.dirname` sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directories.
|
||||
E in modo analogo si è calcolata la percentuale di directories modificate durante interventi di \ac{ML} (`ml_dirs_ratio`) e interventi generici (`no_ml_dirs_ratio`).
|
||||
Attraverso la funzione di libreria Python `os.path.dirname` sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directory.
|
||||
E in modo analogo si è calcolata la percentuale di directory modificate durante interventi di \ac{ML} (`ml_dirs_ratio`) e interventi generici (`no_ml_dirs_ratio`).
|
||||
Queste distribuzioni sono state analizzate graficamente attraverso l'ausilio di boxplot.
|
||||
|
||||
Per la seconda analisi si è reso necessario conoscere per ogni file la lista degli import utilizzati.
|
||||
Questa informazione è stata recuperata attraverso uno script, che dato in input un progetto restituisce la lista dei files affiancati dalla lista degli import utilizzati all'interno del file stesso.
|
||||
Questa informazione è stata recuperata attraverso uno script, che dato in input un progetto restituisce la lista dei file affiancati dalla lista degli import utilizzati all'interno del file stesso.
|
||||
L'individuazione dei file di \ac{ML} è avvenuta mediante la definizione di due gruppi di librerie tipiche del \ac{ML}.
|
||||
|
||||
- Gruppo 1: librerie specifiche del \ac{ML} come ad esempio `keras`, `TensorFlow` e `Pytorch`.
|
||||
|
|
@ -189,33 +189,33 @@ Mentre nel secondo caso, indicato con *wo_pandas_numpy_scipy*, era necessario im
|
|||
Per entrambe le classificazioni si è andato a valutare a quanto ammontava la percentuale di file di \ac{ML} appartenenti ad ogni progetto.
|
||||
Anche in questo caso le distribuzioni sono state analizzate attraverso l'ausilio di un boxplot.
|
||||
|
||||
### RQ2: come sono distribuiti i bug sulle diverse fasi di ML?
|
||||
### RQ2: come sono distribuiti i bug sulle diverse fasi di machine learning?
|
||||
|
||||
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.
|
||||
Come detto precedentemente, nel caso delle *issues* classificate a mano, oltre all'individuazione della tipologia (\ac{ML}, non \ac{ML}) è stata individuata anche la fase in cui il problema si palesava (si veda @sec:classificazione-issues).
|
||||
Come illustrato nella @sec:classificazione-commit per poter determinare la natura di un *issue fix* si è fatto ricorso alla classificazione delle *issue* ad esso associate.
|
||||
La maggior parte delle *issue* è stata classificata automaticamente, ma è stato comunque necessario classificarne una porzione in modo manuale per poter avere un train/test set.
|
||||
Come detto precedentemente, nel caso delle *issue* classificate a mano, oltre all'individuazione della tipologia (\ac{ML}, non \ac{ML}) è stata individuata anche la fase in cui il problema si palesava (si veda @sec:classificazione-issues).
|
||||
In questa *\ac{RQ}* si vuole andare a valutare come questo dato aggiuntivo sulle fasi viene *proiettato* sui commit di *fix*.
|
||||
|
||||
Per poter svolgere questa analisi è necessario incrociare i dati sui commit di *fix* con la classificazione delle *issues*.
|
||||
A partire dal dataset delle *issues* è stato creato per ogni progetto un dizionario *issue* $\rightarrow$ fase.
|
||||
Per poter svolgere questa analisi è necessario incrociare i dati sui commit di *fix* con la classificazione delle *issue*.
|
||||
A partire dal dataset delle *issue* è stato creato per ogni progetto un dizionario *issue* $\rightarrow$ fase.
|
||||
Quindi per ogni commit si è individuata la fase attraverso questo dizionario ausiliario.
|
||||
|
||||
In particolare un commit poteva citare:
|
||||
|
||||
- nessuna *issues* inclusa nel dizionario. In questo caso non è possibile individuare la fase del commit.
|
||||
- una *issues* presente nel dizionario. In questo caso al commit viene assegnata la fase della *issue*.
|
||||
- più di una *issues* presente nel dizionario. In questo caso al commit venivano associate più fasi[^multi-phases].
|
||||
- nessuna *issue* inclusa nel dizionario. In questo caso non è possibile individuare la fase del commit.
|
||||
- una *issue* presente nel dizionario. In questo caso al commit viene assegnata la fase della *issue*.
|
||||
- più di una *issue* presente nel dizionario. In questo caso al commit venivano associate più fasi[^multi-phases].
|
||||
|
||||
[^multi-phases]: Nessun commit di *fix* presente nel dataset utilizzato è rientrato in questa categoria.
|
||||
|
||||
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?
|
||||
### RQ3: esiste una differenza di entropia del cambiamento tra machine learning bug e altri bug?
|
||||
|
||||
La successiva analisi aveva lo scopo di verificare l'esistenza di una differenza tra l'entropia del *fix* rispetto alla natura di questi.
|
||||
Il lavoro di questa analisi è basato sul modello *BCC* discusso nella @sec:entropy.
|
||||
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 (si veda @sec:classificazione-commit), mentre il numero di file modificati può essere ricavato dalla lista dei files modificati nel commit.
|
||||
Il dato rispetto alle linee modificate è già presente nel dataset di partenza (si veda @sec:classificazione-commit), mentre il numero di file modificati può essere ricavato dalla lista dei file modificati nel commit.
|
||||
|
||||
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].
|
||||
|
|
@ -226,27 +226,27 @@ 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.
|
||||
|
||||
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.
|
||||
Inoltre sono stati svolti dei test statistici (*Wilcoxon 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?
|
||||
### RQ4: come varia il livello di discussione tra machine learning bug e altri bug?
|
||||
|
||||
Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues.
|
||||
Questo dato non è presente nel dataset dei commit generato inizialmente (si veda @sec:classificazione-commit), ma può essere ricavato a partire dalla lista delle *issues* citate.
|
||||
Dato un commit si è considerata la lista delle *issues* citate, e per ogni *issue* citata si è calcolato il numero di commenti.
|
||||
Poiché un singolo commit può far riferimento a più *issues* è stato necessario anche calcolare il numero di commenti medi.
|
||||
Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issue.
|
||||
Questo dato non è presente nel dataset dei commit generato inizialmente (si veda @sec:classificazione-commit), ma può essere ricavato a partire dalla lista delle *issue* citate.
|
||||
Dato un commit si è considerata la lista delle *issue* citate, e per ogni *issue* citata si è calcolato il numero di commenti.
|
||||
Poiché un singolo commit può far riferimento a più *issue* è stato necessario anche calcolare il numero di commenti medi.
|
||||
|
||||
Il livello della discussione non viene determinato solo dal numero di commenti, ma anche dalla lunghezza di questi.
|
||||
Quindi per ogni *issue* è stato calcolato anche il numero medio di parole presenti all'interno di un commento.
|
||||
|
||||
I dati per entrambe le distribuzioni sono stati valutati graficamente attraverso l'ausilio di un boxplot e attraverso i test statistici illustrati precedentemente.
|
||||
|
||||
### RQ5: come varia il time-to-fix tra ML bug e altri bug?
|
||||
### RQ5: come varia il time-to-fix tra machine learning bug e altri bug?
|
||||
|
||||
In quest'ultima analisi si vuole andare a valutare se c'è differenza nel tempo necessario per eseguire il *fix*.
|
||||
Anche in questo caso, per poter rispondere alla domanda, è necessario incrociare i dati dei commit con quelli delle *issues* attraverso la lista delle *issues* citate.
|
||||
Anche in questo caso, per poter rispondere alla domanda, è necessario incrociare i dati dei commit con quelli delle *issue* attraverso la lista delle *issue* citate.
|
||||
Dato una *issue* sono stati individuate la data di apertura e di chiusura.
|
||||
Nel caso in cui ad un commit sono associate più *issues* è stata presa come data di apertura il minimo tra tutte le date di apertura delle *issues* e, in modo analogo, si è proceduto anche per la data di chiusura con la differenza che i dati sono stati aggregati attraverso la funzione `max`.
|
||||
Nel caso in cui ad un commit sono associate più *issue* è stata presa come data di apertura il minimo tra tutte le date di apertura delle *issue* e, in modo analogo, si è proceduto anche per la data di chiusura con la differenza che i dati sono stati aggregati attraverso la funzione `max`.
|
||||
|
||||
Una volta noto il momento di apertura e di chiusura della problematica è stato possibile calcolare il numero di giorni intercorsi tra questi due istanti temporali.
|
||||
Le distribuzioni così ottenute sono state analizzate ancora una volta mediante un *boxplot*, il test *ranksum* e il test *Cliff's delta*.
|
||||
Le distribuzioni così ottenute sono state analizzate ancora una volta mediante un *boxplot*, il test *Wilcoxon ranksum* e il test *Cliff's delta*.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,17 @@
|
|||
# Risultati {#sec:results}
|
||||
|
||||
## RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
|
||||
\hypertarget{sec:rq1}{%
|
||||
\section[RQ1: come il ML e' distribuito sull'architettura dei progetti?]{RQ1: come il machine learning e' distribuito sull'architettura dei progetti?}\label{sec:rq1}}
|
||||
|
||||
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.
|
||||
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 file che di directory.
|
||||
Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \ac{ML} è caratterizzato da una maggiore varianza.
|
||||
|
||||
{#fig:files-directories width=100%}
|
||||
{#fig:files-directories width=100%}
|
||||
|
||||
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 dal livello di analisi, la percentuale di file che utilizzano librerie di \ac{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\%$.
|
||||
Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $25\%$ dei progetti abbia una percentuale di file di \ac{ML} superiore al $45\%$.
|
||||
|
||||
{#fig:imports width=80%}
|
||||
|
||||
|
|
@ -35,16 +36,18 @@ Questo vuol dire che la diversa natura dei progetti considerati nello studio gen
|
|||
|
||||
\newpage
|
||||
|
||||
## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
|
||||
\hypertarget{sec:rq2}{%
|
||||
\section[RQ2: come sono distribuiti i bug sulle diverse fasi di ML?]{RQ2: come sono distribuiti i bug sulle diverse fasi di machine learning?}\label{sec:rq2}}
|
||||
|
||||
Andando a confrontare la distribuzione delle fasi sui commit (@fig:count-fix-phases) rispetto alla distribuzione sulle issues (@fig:labeling-phases) è possibile notare la scomparsa della fase *data collection*.
|
||||
Andando a confrontare la distribuzione delle fasi sui commit (@fig:count-fix-phases) rispetto alla distribuzione sulle issue (@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.
|
||||
|
||||
{#fig:count-fix-phases width=70%}
|
||||
|
||||
## RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
|
||||
\hypertarget{sec:rq3}{%
|
||||
\section[RQ3: esiste una differenza di entropia del cambiamento tra ML bug e altri bug?]{RQ3: esiste una differenza di entropia del cambiamento tra machine learning bug e altri bug?}\label{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.
|
||||
|
|
@ -52,7 +55,7 @@ Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-e
|
|||
[^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}]{%
|
||||
\subfloat[Entropia calcolata sui file\label{fig:files-entropy}]{%
|
||||
\includegraphics[width=0.45\textwidth]{src/figures/files-entropy.pdf}
|
||||
}
|
||||
\hfill
|
||||
|
|
@ -63,28 +66,29 @@ Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-e
|
|||
\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.
|
||||
Per verificare la rilevanza statistica di questa diversità sono stati svolti il *Wilcoxon ranksum* test e il *Cliff's delta* i cui risultati sono riportati nella @tbl:test-entropy.
|
||||
Nel caso dell'entropia del cambiamento calcolata 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 segno che la complessità dell'intervento non varia in base al tipo di intervento.
|
||||
|
||||
| | ranksum p-values | Cliff's delta |
|
||||
|--------------|:----------------:|:-------------:|
|
||||
| file entropy | 0.059 | 0.044 |
|
||||
| line entropy | 5.932e-06 | 0.105 |
|
||||
| | Wilcoxon ranksum p-values | Cliff's delta |
|
||||
|------|:----------------:|:-------------:|
|
||||
| file | 0.059 | 0.044 |
|
||||
| line | 5.932e-06 | 0.105 |
|
||||
|
||||
: Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}
|
||||
: Risultati dei test statistici per quanto riguarda l'entropia del cambiamento {#tbl:test-entropy}
|
||||
|
||||
\begin{tcolorbox}[colback=white, boxrule=0.3mm]
|
||||
Non sono emerse differenze statisticamente rilevanti per quanto riguarda la complessità del processo di cambiamento.
|
||||
\end{tcolorbox}
|
||||
|
||||
## RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
|
||||
\hypertarget{sec:rq4}{%
|
||||
\section[RQ4: come varia la discussione tra ML bug e altri bug?]{RQ4: come varia il livello di discussione tra machine learning bug e altri bug?}\label{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 \ac{ML} è compreso tra uno e cinque, quindi nel $50\%$ interno tutte le issues hanno almeno un commento di risposta.
|
||||
Ciò vuol dire che il $50\%$ interno delle issue o non presenta commenti o ne presenta uno solo.
|
||||
Mentre la differenza interquartile dei *fix* di \ac{ML} è compreso tra uno e cinque, quindi nel $50\%$ interno tutte le issue hanno almeno un commento di risposta.
|
||||
|
||||
[^boxplot-discussion]: In questo caso il limite superiore è pari al $97$-$esimo$ quantile.
|
||||
|
||||
|
|
@ -110,7 +114,7 @@ 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 |
|
||||
| | Wilcoxon ranksum p-values | Cliff's delta |
|
||||
|---------------------|:----------------:|:-------------:|
|
||||
| commenti medi | 9.053e-75 | 0.425 |
|
||||
| parole per commento | 2.889e-59 | 0.377 |
|
||||
|
|
@ -122,22 +126,23 @@ Nel caso della issue numero 96 del progetto *BrikerMan/Kashgari* la problematica
|
|||
All'interno dei commenti, diversi *contributors* del progetto, si scambiano possibili architetture, *snippet* di codice e metriche per confrontare i diversi modelli generati.
|
||||
In questo caso l'ampiezza della discussione è sicuramente dovuta alla difficoltà di individuare la problematica.
|
||||
|
||||
La issue numero 27 del progetto *pyswarms/issues* è una richiesta di aiuto da parte dell'autore per migliorare l'implementazione della ricerca per il tuning degli hyperparametri.
|
||||
La issue numero 27 del progetto *ljvmiranda921/pyswarms* è una richiesta di aiuto da parte dell'autore per migliorare l'implementazione della ricerca per il tuning degli hyperparametri.
|
||||
In questo caso la discussione si protrae per oltre trenta commenti ed è incentrata sui requisiti dell'implementazione e come implementarla nel rispetto delle linee guida del progetto.
|
||||
Quest'intervento di modifica è stato il primo contributo dell'utente non solo su questo progetto, ma sull'intera community di GitHub.
|
||||
Questa inesperienza può aver contribuito ad ampliare la discussione.
|
||||
|
||||
La stessa analisi è stata svolta anche per le issues che presentano un alto numero di parole medie per commento.
|
||||
La stessa analisi è stata svolta anche per le issue che presentano un alto numero di parole medie per commento.
|
||||
In questo caso un valore molto elevato della metrica è spesso riconducibile alla condivisione di blocchi di codice.
|
||||
Ne sono un esempio la issue tratta precedentemente nel caso dei commenti, ma anche la issue 125 sempre del progetto *BrikerMan/Kashgari*.
|
||||
Altri fattori che contribuiscono a spiegare questo dato sono la presenza di blocchi di errori (*mittagessen/kraken/206*) o messaggi di log utili ad inquadrare l'origine del problema (*robertmartin8/PyPortfolioOpt/177*).
|
||||
|
||||
\begin{tcolorbox}[colback=white, boxrule=0.3mm]
|
||||
Le \emph{issues} di \ac{ML} sono caratterizzata da una maggiore discussione.
|
||||
Le \emph{issue} di \ac{ML} sono caratterizzata da una maggiore discussione.
|
||||
Un valore molto elevato di parole per commento può indicare uno scambio massiccio all'interno della discussione di \emph{snippet} di codice, di log d'errore e configurazioni dell'ambiente.
|
||||
\end{tcolorbox}
|
||||
|
||||
## RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
|
||||
\hypertarget{sec:rq5}{%
|
||||
\section[RQ5: come varia il time-to-fix tra ML bug e altri bug?]{RQ5: come varia il time-to-fix tra machine learning bug e altri bug?}\label{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 \ac{ML} necessitano, mediamente, di maggior tempo per essere risolti e sono caratterizzati da una varianza maggiore.
|
||||
|
|
@ -157,7 +162,7 @@ Per quanto riguarda i *fix* che hanno richiesto un tempo estremamente lungo la c
|
|||
Nel caso del progetto *CamDavidsonPilon/lifelines* la *issue* numero 507 segnala una problematica di *overflow* durante le operazioni sul dataset.
|
||||
Per stessa ammissione dell'autore del progetto la problematica è banale da risolvere, ma è stato comunque necessario attendere un paio di mesi affinché la correzione venisse portata sul branch principale.
|
||||
|
||||
Altre issues invece hanno necessitato di molto tempo per essere risolte in quanto venivano considerate a bassa priorità.
|
||||
Altre issue invece hanno necessitato di molto tempo per essere risolte in quanto venivano considerate a bassa priorità.
|
||||
In questi casi generalmente viene fornito un *work around* che permette di tamponare la problematica.
|
||||
La presenza di questo *work around* probabilmente riduce ulteriormente la priorità data alla *issue* il che dilata ulteriormente i tempi.
|
||||
Un esempio di questo comportamento ci viene dato dalla *issue* 135 del progetto *robertmartin8/PyPortfolioOpt* che ha richiesto circa sette mesi per essere risolta o dalla *issue* 98 del progetto *mittagessen/kraken* che invece ha necessitato di quasi due anni.
|
||||
|
|
@ -166,7 +171,7 @@ Anche per quest'ultima *RQ* sono stati svolti i test statistici illustrati prece
|
|||
Dai risultati riportati in @tbl:test-time-to-fix è possibile notare un *p-value* inferiore a $0.05$ e un *effect size* medio.
|
||||
Questi risultati non solo confermano la differenza osservata nel boxplot, ma ci confermano che l'impatto sulla metrica non è trascurabile.
|
||||
|
||||
| | ranksum p-values | Cliff's delta |
|
||||
| | Wilcoxon ranksum p-values | Cliff's delta |
|
||||
|------------|:----------------:|:-------------:|
|
||||
| day-to-fix | 7.354e-53 | 0.355 |
|
||||
|
||||
|
|
@ -179,10 +184,10 @@ La bassa priorità di una \emph{issue} e la presenza di \emph{work around} sono
|
|||
|
||||
## Threats to validity
|
||||
|
||||
La *threats to validity* più critica per il lavoro svolto è di tipo *construct* e riguarda la classificazione delle *issues*.
|
||||
La *threats to validity* più critica per il lavoro svolto è di tipo *construct* e riguarda la classificazione delle *issue*.
|
||||
La classificazione è avvenuta in modo automatico attraverso un modello *naïve Bayes*.
|
||||
Il classificatore, sebbene sia caratterizzato da una *recall* molto elevata, presenta una *precision* discreta per cui è molto probabile che all'interno tra le *issues* di \ac{ML} siano state incluse anche *issues* generiche.
|
||||
Inoltre, poiché la classificazione degli interventi di *issue fixing* dipende dalla classificazione degli *issues*, gli eventi di *misclassification* sono stati propagati anche su questa seconda classificazione.
|
||||
Il classificatore, sebbene sia caratterizzato da una *recall* molto elevata, presenta una *precision* discreta per cui è molto probabile che all'interno tra le *issue* di \ac{ML} siano state incluse anche *issue* generiche.
|
||||
Inoltre, poiché la classificazione degli interventi di *issue fixing* dipende dalla classificazione degli *issue*, gli eventi di *misclassification* sono stati propagati anche su questa seconda classificazione.
|
||||
|
||||
Per quanto riguarda le *threat to validity* interne bisogna segnalare l'interpretazione data al *time-to-fix*.
|
||||
Infatti in questo lavoro il dato del *time-to-fix* è stato calcolato come la differenza tra l'istante di chiusura e di apertura della *issue*.
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
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 \ac{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 \ac{ML} superiore al $45\%$ sia molto limitata.
|
||||
Da questo dato si può comprendere 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 file* di \ac{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 \ac{ML}.
|
||||
|
|
@ -17,7 +17,7 @@ Nel caso dei messaggi scambiati non solo si è riscontrato un numero medio di me
|
|||
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.
|
||||
|
||||
In sintesi questo lavoro ha fatto emergere sia delle similitudini che delle differenze per quanto riguarda gli interventi di *fix* all'interno di progetti di \ac{ML}.
|
||||
Le principali differenze sono state riscontrate per quanto riguarda il livello di discussione, decisamente più alto nel caso di *issues* di \ac{ML}, e il tempo necessario alla correzione dei difetti, anche in questo caso maggiore nel caso del \ac{ML}.
|
||||
Le principali differenze sono state riscontrate per quanto riguarda il livello di discussione, decisamente più alto nel caso di *issue* di \ac{ML}, e il tempo necessario alla correzione dei difetti, anche in questo caso maggiore nel caso del \ac{ML}.
|
||||
Non sono emerse differenze rilevanti invece per quanto riguarda l'entropia generata dai cambiamenti.
|
||||
Infine si è visto come l'impatto delle componenti di \ac{ML} sull'architettura vada a riflettere la natura dei progetti.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue