3.8 KiB
Conclusioni
La RQ1 (@sec:rq1) ci ha permesso di inquadrare la natura dei progetti considerati per questo studio.
Attraverso l'analisi degli import si è mostrato come l'utilizzo di librerie di \ac{ML} vari a seconda del progetto.
Da questo dato si può comprendere che i progetti all'interno del dataset sono diversi tra di loro e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
Si è anche visto che la percentuale di progetti con un numero di source file di \ac{ML} superiore al 45\% sia molto limitata.
Inoltre andando ad analizzare la porzione di sistema impattata dai cambiamenti si è visto come anche in questo caso il dato sia caratterizzato da una forte variabilità.
Le RQ3, RQ4 e RQ5 (da @sec:rq3) sono andate a valutare nello specifico le differenze in termini di entropia, discussione e time-to-fix tra gli interventi di issue fixing generici e quelli specifici del \ac{ML}. Da queste analisi si evince che tra i due tipi di interventi ci sono sia similitudini che differenze. Nel caso dell'entropia e della complessità del processo di cambiamento del software non sono emerse differenze rilevanti. Questo ci porta a pensare che il processo di cambiamento non varia in base al tipo di intervento, ma sia costante.
Nel caso del livello di discussione e del time-to-fix sono emerse delle differenze confermate anche dai test statistici effettuati. In entrambi i casi l'essere un fix legato al \ac{ML} ha spinto la metrica verso l'alto. Nel caso dei messaggi scambiati non solo si è riscontrato un numero medio di messaggi più elevato, ma si è visto anche che questi mediamente sono più lunghi. Questo dato potrebbe dipendere sia dal maggiore tempo richiesto per d'individuazione e correzione delle problematiche legate al \ac{ML}, sia da un maggiore interesse per queste problematiche rispetto alle altre.
In sintesi questo lavoro ha fatto emergere sia delle similitudini che delle differenze per quanto riguarda gli interventi di fix all'interno di progetti di \ac{ML}. Le principali differenze sono state riscontrate per quanto riguarda il livello di discussione, decisamente più alto nel caso di issue di \ac{ML}, e il tempo necessario alla correzione dei difetti, anche in questo caso maggiore nel caso del \ac{ML}. Non sono emerse differenze rilevanti invece per quanto riguarda l'entropia generata dai cambiamenti. Infine si è visto come l'impatto delle componenti di \ac{ML} sull'architettura vada a riflettere la natura dei progetti.
Sviluppi futuri
Nella RQ2 sfortunatamente non è stato possibile svolgere un'analisi più approfondita per la carenza di dati. Un possibile sviluppo futuro potrebbe consistere nella realizzazione di un classificatore multi-label in grado di individuare la fase in cui il problema si è manifestato. In questo modo non solo sarebbe possibile conoscere la fase per ogni intervento di fix, ma anche definire delle nuove analisi. Per esempio si potrebbe andare a ricercare differenze in termini di entropia, discussione e time-to-fix in base alla fase in cui si è presentata la issue.
Per quanto riguarda la valutazione dell'entropia si è scelto come intervallo temporale di riferimento il singolo commit. Utilizzando questa configurazione non si è riscontrata nessuna differenza degna di nota. Un possibile sviluppo futuro potrebbe consistere nell'andare a valutare l'entropia considerando dei riferimenti temporali più ampi e verificare in questo caso la presenza di differenze.
Infine un aspetto non considerato in questo lavoro riguarda i contributors. Una prima analisi potrebbe andare a valutare se esiste una sovrapposizione o meno tra chi effettua interventi di fix generici e chi si occupa di quelli legati al \ac{ML}. Inoltre si potrebbero andare a ricercare anche differenze in base al tipo di contributore (interno, esterno).