La storia dell'industria dello sviluppo software è caratterizzata da diversi cambiamenti rispetto alle applicazioni dominati.
Negli anni ottanta il dominio dominante era quello dei personal computer, puoi 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}.
Gli strumenti e i software che fanno uso di queste tecnologie sono ormai parte della nostra vita quotidiana e pervadono i campi più disparati.
Tra questi sicuramente possiamo annoverare: riconoscimento di immagini, diagnosi di malattie, \ac{NLP}, guida autonoma e riconoscimento vocale.
La crescente produzione di software basato sul \acl{ML} ha generato un forte impulso anche per quanto riguarda la ricerca.
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.
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.
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}.
