Analizzare i processi di risoluzione dei bug nel software di rete

I bug sono un problema comune nello sviluppo software. Quando questi bug vengono segnalati in repository pubblici, si aiuta a migliorare la trasparenza e la fiducia nel software. Questo articolo esplora come raccogliere informazioni dal sistema di tracciamento dei problemi Jira. Introduce anche un modo per prevedere quanto tempo ci vorrà per correggere i nuovi bug. La ricerca si concentra su un progetto di rete chiamato ONAP, che si occupa delle esigenze degli operatori di rete e dei produttori. Attraverso questo studio, vogliamo far luce su quanto tempo ci vuole per risolvere i bug e altri fattori importanti nei progetti software di rete.

#Cos'è la Softwarizzazione della Rete?

La softwarizzazione della rete significa sostituire l'hardware specializzato usato per compiti specifici con software programmabile. Questo cambiamento porta diversi vantaggi, tra cui una manutenzione più semplice, maggiore flessibilità e costi più bassi sia in fase di sviluppo che di operazione. Esempi di questa tendenza includono il Software Defined Networking (SDN) e la Network Function Virtualization (NFV). I produttori usano spesso soluzioni open-source per aggiungere funzionalità mentre si assicurano di rispettare standard stabiliti.

Nonostante questi vantaggi, gli operatori di rete sono spesso riluttanti ad adottare queste soluzioni software. Questo è principalmente dovuto al fatto che il software può essere complesso e soggetto a bug. Inoltre, l'affidabilità del codice può essere discutibile poiché è aperta a vari sviluppatori con abilità e esperienze differenti.

Per migliorare la trasparenza nell'affidabilità del software, tutti i bug trovati durante il funzionamento del software vengono segnalati in repository pubblici. Questi repository forniscono informazioni preziose sui bug segnalati, i loro stati e altro, che possono essere cruciali per valutare l'affidabilità del software. Ogni progetto software ha un processo definito per risolvere i bug, che tutti gli sviluppatori sono tenuti a seguire.

#Obiettivi dello Studio

I principali obiettivi di questo studio sono due. Primo, vogliamo dare una panoramica dei tipi di informazioni che possono essere estratte dai repository di segnalazione dei bug. Mentre alcuni dati possono essere raccolti direttamente, altri necessiteranno di elaborazione. Secondo, proponiamo un metodo per stimare il tempo necessario per risolvere nuovi bug. La nostra metodologia è stata applicata a diversi progetti legati alla rete, tra cui ONOS e ONAP. Riconosciamo che gli operatori di rete e i produttori che utilizzano progetti open-source sono preoccupati per quanto tempo ci vuole per risolvere i bug.

#Contributi Chiave

1. Una strategia per raccogliere i bug segnalati e i necessari processi di filtraggio.
2. Analisi dei dati di base per identificare comuni modelli di lavoro, transizioni tra diversi stati e distribuzione del tempo di risoluzione dei bug.
3. Analisi avanzata dei dati, incluso l'impatto di fattori come priorità e Reporter sul tempo di debug.
4. Indagine sulle probabilità di diversi stati del bug nel tempo.
5. Un confronto del tempo di risoluzione dei bug usando varie strategie.
6. Predire il tempo esatto di risoluzione dei bug usando modelli di rete neurale.

#Background sull'Analisi dei Dati dei Bug

In questa sezione, discuteremo lavori precedenti relativi all'analisi dei bug e alla comprensione dei processi coinvolti nella risoluzione dei bug.

I ricercatori hanno estratto dati dai sistemi di tracciamento dei problemi e creato set di dati da vari progetti. In uno studio notevole, sono stati analizzati i dati di 55 progetti Apache. Questi progetti sono stati classificati in nove gruppi, come big data e sicurezza. I ricercatori hanno esaminato come i campi relativi alla segnalazione dei bug possano cambiare nel tempo e hanno definito il tempo necessario per risolvere un bug come il periodo che intercorre tra la sua creazione e la sua chiusura. Hanno anche studiato come le priorità e gli assegnatari influenzino questi tempi.

Un altro studio ha esaminato come le caratteristiche dei bug come il reporter e la priorità influenzino il tempo necessario per risolvere i bug. I ricercatori hanno utilizzato un algoritmo K-nearest neighbor per prevedere quanto tempo ci vorrebbe per risolvere i bug in base a queste caratteristiche. Anche se i loro risultati indicavano che l'identità del reporter o dell'assegnatario fosse importante, il loro approccio si concentrava su risultati binari (veloce o lento) piuttosto che su previsioni numeriche precise.

Ulteriori ricerche hanno utilizzato un approccio basato su Markov per stimare quanti bug potessero essere risolti in un determinato periodo e un metodo di Monte Carlo per prevedere il tempo totale necessario per risolvere un certo numero di bug. Tuttavia, questo metodo non considerava i singoli bug come entità separate.

#Comprendere i Sistemi di Tracciamento dei Problemi

I sistemi di tracciamento dei problemi sono strumenti usati per gestire lo sviluppo, la manutenzione e i processi di debug del software. Questi sistemi usano "problemi" per descrivere bug, richieste di funzionalità, scadenze e altri compiti in base alle esigenze del progetto. Servono anche come repository per la storia dei problemi segnalati e risolti, rendendoli preziosi per comprendere l'evoluzione dei progetti software.

Jira è uno dei sistemi di tracciamento dei problemi più utilizzati, presente in molti progetti open-source. In Jira, i tipi di problemi vanno oltre il semplice "Bug", includendo "Task", "Story" e altro. Ogni problema è memorizzato nel repository Jira per il rispettivo progetto. Questo rende Jira una fonte ricca di informazioni sulla storia di sviluppo del progetto.

Jira ha un workflow definito che delinea le fasi che un problema può attraversare, da quando viene creato (etichettato "Open") a quando è risolto (etichettato "Closed"). Mentre Jira fornisce questo workflow iniziale, può essere personalizzato in base ai requisiti specifici di ciascun progetto.

#Progetti di Esempio

Questo studio considera due progetti open-source: Open Network Operating System (ONOS) e Open Network Automation Platform (ONAP). ONOS, creato dalla Open Network Foundation, è progettato per la rete definita dal software (SDN) e segue un workflow standard. ONAP, sviluppato dalla Linux Network Foundation, è un framework di gestione e orchestrazione per la Virtualizzazione delle Funzioni di Rete (NFV). La comunità di ONAP ha personalizzato il workflow di Jira per allinearsi alla loro strategia di risoluzione dei bug, aggiungendo uno stato "Submitted".

#Dati sui Bug in Jira

In questo lavoro, ci concentriamo sul tempo di risoluzione dei bug, filtrando i problemi che non sono classificati come bug. Jira raccoglie dati sui bug segnalati, inclusi dettagli su ciascun bug e il processo di risoluzione. Le informazioni rilevanti includono:

• Livello di Priorità: Indica quanto è importante il bug, con diversi livelli usati da diversi progetti.
• Reporter: La persona che segnala il bug.
• Assegnatario: L'individuo responsabile della risoluzione del bug.
• Data di Segnalazione: La data e l'ora in cui è stato segnalato il bug.
• Stato: L'attuale fase del bug nel workflow.
• Progresso della Risoluzione: Indica se il bug è ancora irrisolto o è stato affrontato.

Altri attributi raccolti possono includere descrizioni dei bug, progetti secondari correlati, commenti durante la risoluzione e informazioni sulla versione.

#Processo di Risoluzione dei Bug

I bug in Jira seguono un workflow specifico. Quando un bug viene segnalato per la prima volta, entra nello stato "Open". Quando uno sviluppatore inizia a lavorarci, lo stato cambia in "In Progress". Una volta risolto, passa allo stato "Resolved", in attesa dell'approvazione da un altro membro del team. Dopo l'approvazione, il bug viene contrassegnato come "Closed". A volte, i bug possono essere riaperti per ulteriori lavori, tornando allo stato "Reopen".

#Raccolta e Analisi dei Bug

È stato sviluppato uno script Python per raccogliere e analizzare i bug. I bug per ONAP e ONOS sono stati raccolti direttamente da Jira, mentre i bug per Apache sono stati ottenuti da un dataset esterno. La ricerca si è concentrata principalmente sui bug di alta priorità (priorità 1 e 2).

#Filtro dei Dati Raccolti

I dati raccolti includono tutti i bug segnalati dall'inizio di ogni progetto fino alla data di raccolta. Tuttavia, non tutti i bug sono risolti; alcuni possono essere etichettati come chiusi per altri motivi. Solo gli stati "Done" e "Fixed" sono stati inclusi per ONAP e ONOS, che sono le risoluzioni più comunemente segnalate.

Ci sono state anche istanze in cui i bug hanno trascorso periodi di tempo molto brevi in uno stato specifico, che sono stati filtrati per migliorare l'accuratezza.

#Analisi dei Tempi di Risoluzione dei Bug

Abbiamo analizzato i tempi di risoluzione per i bug di priorità 1 nel progetto ONAP, dove sono stati identificati 906 bug di questo tipo. Osservando i percorsi comuni seguiti per risolvere questi bug, abbiamo notato tendenze: molti bug seguivano sequenze simili attraverso il workflow.

#Impatto delle Proprietà dei Bug

Diverse proprietà dei bug, come priorità, assegnatario e reporter, possono influenzare notevolmente i tempi di risoluzione. Abbiamo esaminato specificamente come queste caratteristiche influenzassero il tempo necessario per risolvere i bug nei nostri progetti scelti.

#Ruolo del Reporter

La persona che segnala un bug può influenzare significativamente il tempo di risoluzione. Una descrizione chiara e accurata aiuta l'assegnatario a risolvere il problema più rapidamente. La nostra ricerca indica che le differenze nei tempi di risoluzione possono essere ampie a seconda dell'esperienza del reporter.

#Ruolo dell'Assegnatario

L'individuo assegnato a risolvere il bug gioca anche un ruolo cruciale. Ogni assegnatario porta abilità e disponibilità uniche, influenzando la velocità con cui un bug può essere risolto. Abbiamo scoperto che alcuni assegnatari risolvevano costantemente i bug di alta priorità più rapidamente di altri.

#Effetti dell'Auto-assegnazione

A volte, un reporter può anche assumere il ruolo di assegnatario per il proprio bug. Questo doppio ruolo può accelerare il processo di risoluzione poiché il reporter guida la correzione senza dover comunicare dettagli separatamente. I nostri risultati suggeriscono che risolvere un bug è molto più veloce quando i ruoli si allineano.

#Distribuzione dello Stato dei Bug nel Tempo

In seguito, abbiamo esaminato come gli stati dei bug cambiano nel tempo. Quando un bug viene segnalato per la prima volta, inizia nello stato "Open". Con il passare del tempo, transita attraverso vari stati, raggiungendo infine "Closed". La nostra analisi di tre progetti-ONAP, ONOS e Apache-ha mostrato tendenze diverse su quanto rapidamente venivano chiusi i bug.

#Previsione del Tempo di Risoluzione dei Bug

Nonostante un'analisi accurata, alcuni bug possono ancora essere filtrati. Tra i motivi per il filtraggio ci sono bug che mostrano durate estreme. Abbiamo esplorato opzioni per rimuovere questi outliers ed esaminato come diverse strategie di filtraggio influenzassero le nostre previsioni.

Abbiamo utilizzato reti neurali per prevedere il tempo di risoluzione dei bug. I risultati sono stati confrontati con altri algoritmi come Naive Bayesian e K-nearest Neighbor. Anche se le reti neurali non erano progettate per previsioni binarie, si sono comportate meglio in molti casi. L'accuratezza di queste previsioni variava in base al metodo di filtraggio scelto.

#Conclusione

Questo studio evidenzia l'importanza di comprendere vari fattori che influenzano la velocità di risoluzione dei bug. Abbiamo notato che assegnare il reporter al bug aveva un impatto significativo sulla risoluzione del problema. Abbiamo anche discusso di come diversi workflow influenzino il processo di risoluzione dei bug. La ricerca ha dimostrato il potenziale di utilizzare reti neurali per prevedere i tempi di risoluzione dei bug, il che può aiutare i team di sviluppo a allocare le loro risorse in modo più efficace. I lavori futuri potrebbero coinvolgere l'uso di ulteriori tecniche di machine learning per migliorare l'accuratezza delle previsioni per progetti piccoli e nuovi.