2.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ò capire 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 files 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.
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.