Add roadmap

src/chapter_1.md

@@ -11,60 +11,11 @@ La crescente produzione di software basato sul \acl{ML} ha generato un forte imp
 L'attenzione non è stata puntata unicamente sullo studio di nuovi modelli e architetture, ma anche sul processo di sviluppo di questi prodotti per andare a valutare i vari problemi da un punto di vista ingegneristico.
 Il seguente lavoro si muove proprio in questo solco e ha lo scopo di studiare come le componenti di \ac{ML} sono distribuite sull'architettura dei sistemi, ma anche di capire se esistono delle differenze tra gli interventi di *issue fixing* doviti a problematiche di \acl{ML} e quelli generici.
 
-## Opere correlate
+## Struttura della tesi
 
-In questo lavoro[@gonzalez2020statemluniverse10] sono stati studiati mediante tecniche di statistica descrittiva $9325$ progetti.
-I progetti sono stati distinti tra sistemi di \ac{ML}, a loro volta suddivisi in framework ($700$ elementi) e applicazioni ($4524$ elementi), e sistemi generici ($4101$ elementi).
-Gli aspetti considerati per l'analisi sono vari, si va dalla distribuzione dei contributi, a loro volta divisi tra interni ed esterni, fino all'analisi dei linguaggi più utilizzati, passando per un'analisi sulla popolarità dei vari repositories.
-Inoltre vengono valutate anche le differenze per quanto riguarda le interazioni collaborative (discussioni, review, ecc.).
-
-In altri lavori[@han2020empiricalstudydependency] il focus è stato puntato sulla gestione delle dipendenze dei progetti di \acl{ML}.
-In questo caso si va a valutare le eventuali differenze in base al framework utilizzato.
-Le librerie considerate nello studio sono: `TensorFlow`, `PyTorch` e `Theano`.
-Mentre eventuali differenze sono state ricercate rispetto agli obbiettivi del progetto (tutorial/libri, applicativi, ricerca), il dominio applicativo, la popolarità, la frequenza di aggiornamento delle dipendenze e i motivi degli aggiornamenti.
-
-In altri casi[@grichi2020impactmultilanguagedevelopment] ancora l'attenzione è stata rivolta alla natura *multi-linguaggio* tipica delle soluzioni di \acl{ML} e all'impatto che ciò ha sul sistema.
-In questo caso sono stati considerati, tra progetti mono-linguaggio e multi-linguaggio, $27$ repository open source.
-Per quanto riguarda l'analisi sono stati presi in considerazione la percentuale di pull request accettate, il tempo necessario per accettare una pull request e la propensione nell'introdurre i *bug* all'interno delle pull request.
-
-In letteratura sono presenti anche molti lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \acl{ML}.
-In alcuni casi lo studio[@zhang2018empiricalstudytensorflow] è stato svolto in maniera specifica per una singola libreria.
-Nello specifico sono state considerate $87$ domande postate su *StackOverflow* in relazione a bug di `TensorFlow` e $82$ commit, selezionati da $11$ progetti su *GitHub*.
-Lo studio aveva l'obiettivo di individuare i sintomi e le cause scatenati di questi difetti e individuare le sfide per l'individuazione e la localizzazione di questi.
-
-In altri casi[@humbatova-2019-taxonomyrealfaults] l'attenzione non è stata rivolta ad una libreria specifica, ma si è cercato di definire una tassonomia delle problematiche che fosse però generale per tutti i framework e le applicazioni di \ac{ML}.
-Anche in questo caso i dati per lo studio sono stati recuperati sia da *GitHub* che da *StackOverflow*.
-Altre volte ancora l'analisi[@liu2021exploratorystudyintroduction] è stata mirata su alcuni aspetti specifici come l'introduzione e la rimozione di \ac{SATD} all'interno di progetti che fanno uso di \ac{DL}.
-
-Noi lavori precedentemente discussi l'analisi è stata svolta su dati recuperati dalla storia dei repositories e in alcuni casi recuperando informazioni aggiuntive da piattaforme di discussione online.
-Altri lavori[@bangash2019whatdevelopersknow; @han2020whatprogrammersdiscuss; @alshangiti2019whydevelopingmachine] invece hanno analizzato unicamente le discussioni su *StackOverflow* per andare a capirne il contenuto.
-Lo scopo di questi studi è quello di individuare le fasi più critiche del processo di sviluppo e capire quali sono gli argomenti che gli sviluppatori discutono più frequentemente.
-
-Altri studi[@hassan2009predictingfaultsusing] ancora hanno traslando il concetto di entropia[@shannon1948mathematicaltheorycommunication] utilizzato nella teoria della comunicazione per andare a valutare la complessità del processo di cambiamento del software.
-Andando, inoltre, ad evidenziare come la complessità del processo possa essere utilizzata per predire i *faults* all'interno dei prodotti software con risultati migliori rispetto alle metriche di complessità del software.
-
-## Research Questions
-
-Questo studio ha l'obiettivo di dare una risposta a queste cinque domande:
-
-- **RQ1**: *come il \ac{ML} e' distribuito sull'architettura dei progetti?*
-
-  In questa *RQ* si vuole investigare l'architettura dei progetti.
-  In particolare l'attenzione viene concentratala sui files e sulle directories modificate durante interventi di *issues fixing*.
-  Obbiettivo di questa domanda è anche individuare la percentuale di files che utilizzano import riconducibili a librerie e framework di \acl{ML}.
-- **RQ2**: *come sono distribuiti i bug sulle diverse fasi di \ac{ML}?* 
-
-  Il workflow tipico per lo sviluppo di un'applicazione di \acl{ML} si compone di più fasi.
-  L'obiettivo di questa *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?*
-
-  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 \acl{ML} e gli altri difetti.
-- **RQ4**: *come varia il livello di discussione tra \ac{ML} bug e altri bug?*
-
-  Questa *RQ* riguarda il livello di discussione dei *bug*.
-  In particolare si vuole capire se, all'interno dei progetti di \acl{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?*
-
-  Un altro aspetto caratteristico di un *fix* è il tempo necessario per poter essere attuato.
-  Questa *RQ* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \acl{ML}.
+Nella @sec:related-works viene svolta una panoramica sui lavori correlati.
+Nella @sec:methodology vengono presentate le *research question*, viene descritta la procedura utilizzata per la raccolta dei commit e delle issues 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 @sec:results.
+Infine la @sec:conclusions chiude questa tesi.