diff --git a/src/chapter_1.md b/src/chapter_1.md index 3ed58ab..b47dec3 100644 --- a/src/chapter_1.md +++ b/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. -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. -In altri lavori il focus è stato puntato sulla gestione delle dipendenze dei progetti di \acl{ML}. -In particolare lo scopo dello studio[@han2020empiricalstudydependency] era valutare le eventuali differenze che sussistevano in base al framework utilizzato (`TensorFlow`, `PyTorch`, `Theano`). -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 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 letteratura sono presenti anche molti lavori che vanno ad analizzare le problematiche e i *bug* riscontrati all'interno di applicazioni di \acl{ML}. -In alcuni casi lo studio[@zhang2018empiricalstudytensorflow] è stato svolto in maniera specifica per un singolo framework. -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}. -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}. +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. -La quasi totalità degli studi precedentemente discussi utilizzava come fonte d'informazione per individuare le problematiche direttamente i progetti e la loro storia. -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 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.