Refactor relate works

src/chapter_1.md

@@ -13,21 +13,32 @@ Il seguente lavoro si muove proprio in questo solco e ha lo scopo di studiare co
 
 ## Opere correlate
 
-In questo lavoro[@gonzalez2020statemluniverse10] vengono studiate mediante tecniche di statistica descrittiva, le differenze tra sistemi di \ac{ML}, a loro volta divisi in framework e applicazioni, e sistemi generici.
+In questo lavoro[@gonzalez2020statemluniverse10] sono stati studiati mediante tecniche di statistica descrittiva $9325$ progetti.
-Gli aspetti considerati sono vari, si va dalla distribuzione dei contributi, divisi tra interni ed esterni, fino all'analisi dei linguaggi più utilizzati, passando per un'analisi sulla popolarità dei vari repositories.
+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).
-In altri lavori il focus è stato puntato sulla gestione delle dipendenze dei progetti di \acl{ML}.
+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.
-In particolare lo scopo dello studio[@han2020empiricalstudydependency] era valutare le eventuali differenze che sussistevano in base al framework utilizzato (`TensorFlow`, `PyTorch`, `Theano`).
+Inoltre vengono valutate anche le differenze per quanto riguarda le interazioni collaborative (discussioni, review, ecc.).
-In questo caso gli aspetti considerati sono stati la natura del progetto (tutorial/libri, applicativi, ricerca), il dominio applicativo, la popolarità e la frequenza di aggiornamento delle dipendenze di \ac{ML}.
-In altri[@grichi2020impactmultilanguagedevelopment] casi l'attenzione è stata rivolta alla natura *multi-linguaggio* tipica delle soluzioni di \acl{ML} e all'impatto che ciò ha sul sistema.
-Gli aspetti principalmente presi in considerazione sono stati il tempo necessario ad accettare una modifica e la propensione al manifestarsi di *bug*.
 
-In letteratura sono presenti anche molti lavori che vanno ad analizzare le problematiche e i *bug* riscontrati all'interno di applicazioni di \acl{ML}.
+In altri lavori[@han2020empiricalstudydependency] il focus è stato puntato sulla gestione delle dipendenze dei progetti di \acl{ML}.
-In alcuni casi lo studio[@zhang2018empiricalstudytensorflow] è stato svolto in maniera specifica per un singolo framework.
+In questo caso si va a valutare le eventuali differenze in base al framework utilizzato.
-Mentre in altri casi[@humbatova-2019-taxonomyrealfaults] lo scopo era quello di andare a definire una tassonomia delle problematiche che fosse però generale per tutti i framework e le applicazioni di \ac{ML}.
+Le librerie considerate nello studio sono: `TensorFlow`, `PyTorch` e `Theano`.
-Altre volte ancora l'analisi[@liu2021exploratorystudyintroduction] è stata mirata su alcuni aspetti come l'introduzione e la rimozione di \ac{SATD} all'interno di progetti che fanno uso di \ac{DL}.
+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.
 
-La quasi totalità degli studi precedentemente discussi utilizzava come fonte d'informazione per individuare le problematiche direttamente i progetti e la loro storia.
+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.
-Altri lavori[@bangash2019whatdevelopersknow; @han2020whatprogrammersdiscuss; @alshangiti2019whydevelopingmachine] invece hanno analizzato le discussioni su *StackOverflow* per andare a capire quali sono le fasi più critiche del processo di sviluppo e quali sono gli argomenti che gli sviluppatori discutono più frequentemente.
+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.