35 lines
4.4 KiB
Markdown
35 lines
4.4 KiB
Markdown
|
# 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.
|
||
|
|
|