# Introduzione

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.