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.
## 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 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}.
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.
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}.
