Hata raportörünün itibarının hesaplanması ve itibarın hata çözüm süresine etkisi

Measuring bug reporter's reputation and its effect on bug resolution time

PDF İndir

Tez No: 758305
Yazar: MUHAMMED KADİR YÜCEL
Danışmanlar: DR. ÖĞR. ÜYESİ AYŞE TOSUN KÜHN
Tez Türü: Yüksek Lisans
Konular: Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrol, Computer Engineering and Computer Science and Control
Anahtar Kelimeler: Belirtilmemiş.
Yıl: 2022
Dil: Türkçe
Üniversite: İstanbul Teknik Üniversitesi
Enstitü: Lisansüstü Eğitim Enstitüsü
Ana Bilim Dalı: Bilgisayar Mühendisliği Ana Bilim Dalı
Bilim Dalı: Bilgisayar Mühendisliği Bilim Dalı
Sayfa Sayısı: 75

Özet

Yazılım hataları, yazılım geliştirme süreçlerinin işletilmesi sırasında yapılan hataların, teslim edilen yazılım ürününde sebep olduğu beklenmeyen davranışlardır. Yazılım geliştirme sürecinin herhangi bir adımında meydana gelebilecek hatalar, geliştirme sürecinde tespit edilip düzeltilebilir veya ürünün teslimi sonrasında da tespit edilebilir. Yazılım hataları tespit edildikten sonra, hata raporu ismi verilen dokümanlar aracılığıyla hata takip sistemlerine işlenir ve yazılım geliştirme ekibinin analizine sunulur. Yazılım geliştirme ekibi raporu analiz eder, hatanın geçerliliğini kontrol ettikten sonra hataya sebep olan kısmı tespit edip düzeltmek için üzerinde çalışır. Hatanın düzeltilmesi sonrasında, hata raporu kapatılır ve gerekli testlerin ardından ürün güncellenir. Yazılım hatalarının bu yaşam döngüleri, hata raporlarına işlenir ve hata raporu takip sistemleri aracılığıyla incelenebilir. Bir yaşam döngüsüne sahip olan hatalar, bu döngüleri boyunca yazılım geliştirme ekibinin eforunu ve zamanını gerektirirler. Bu durum yazılımın geliştirme plan takvimini etkileyebileceği için, hata raporlarının analizi ile geliştirici ekibin durumu, projenin durumu ve takvimi hakkında yöneticilere faydalı bilgiler sağlanabilir. Hata raporları, hatayı tanımlamak için nitelik bilgilerinin sağlanmasını gerektirir. Bu nitelik bilgileri hatanın yaşam döngüsü boyunca güncellenerek, hatanın durumu rapor üzerinden takip edilebilir. Hata raporları ilk oluşturulduklarında hata raportörü tarafından sağlanan hatanın bir özetini ve hata hakkında detay bilgileri içerirler. Hata raporunun analizi, hatanın tespiti ve çözümü sırasında geliştirici ekip düşüncelerini ve tartışmalarını, hata raporuna yorumlar ekleyerek işlerler. Hatanın özeti, açıklaması ve hata üzerine geliştirici ekibin yorumları, hata raporları içerisindeki metin verisi olarak değerlendirilir. Hata raporu takip sistemleri üzerinden yazılım geliştirme ekiplerine ve yöneticilere faydalı analizler sunmak için literatürde birçok çalışma bulunmaktadır. Hata raporlarının nitelik özelliklerini kullanan, hata raporları içerisindeki metin verisi üzerine doğal dil işleme teknikleri uygulayan literatür çalışmaları mevcuttur. Bu çalışmalar hata raporlarını analiz ederek, geliştirme ekibinin yazılım hataları üzerine eforunu en aza indirmeyi amaçlayan çözümler sunmaktadır. Çalışmalardan bazıları doğal dil işleme çözümleriyle, aynı hatayı tekrar açıklayan raporları tespit ederek ekibin analiz eforunu en aza indirmeyi sağlayan çözümler sunmaktadır. Literatür çalışmalarında bir hatanın yaşam döngüsünün süresinin tahmini yapılarak, proje yönetimine ve geliştirici ekibe projenin planlanmasında yardımcı olacak çözümler sunulmaktadır. Bir hata raporunun açılmasıyla, hatanın yaşam döngüsü başlar ve hata raporunun kapanmasıyla hatanın yaşam döngüsü tamamlanır. Raporun kapanması ve açılması arasında geçen süre hatanın çözüm süresi olarak değerlendirilir. Hata raporlarının nitelik kısımları ve metin verileri kullanılarak hatanın çözüm süresinin tahminini yapan literatür çalışmaları bulunmaktadır. Bu çalışmalarda, çözüm süresi tahmini bir sınıflandırma problemi olarak değerlendirilmekte ve eşik değer olarak belirlenen gün sayısından kısa süren hata raporları hızlı, uzun süren hata raporları ise yavaş olarak sınıflandırılmaktadır. Sınıflandırmada kullanılan kategori sayısı çalışmalarda farklılık gösterebilmektedir, fakat yapılan çalışmalarda en iyi performansın iki kategori ile alındığı bahsedilmektedir. Literatürde kNN ve SVM gibi temel makine öğrenmesi sınıflandırma modelleri kullanılarak hata raporlarının çözüm süreleri tahmin edilmektedir. Güncel çalışmalarda, derin öğrenme metodları da bu problemin çözümü için önerilmektedir. Fakat bu çalışmalarda önerilen karmaşık derin öğrenme modellerinin daha temel makine öğrenme modellerine göre performans sonuçlarında ciddi iyileşme olmamıştır. Fakat derin öğrenme modellerinden LSTM modeli sayesinde, hata raporlarının zaman içerisindeki değişim adımları değerlendirilebilmektedir. Temel makine öğrenme modellerinde hata raporlarının yalnızca son hali modelde girdi olarak kullanılabilmektedir. Literatür çalışmalarında hata raporu süresinin tahmininde en etkili rapor niteliğinin hata raportörü olduğu belirtilmektedir. Hata raportörü bir kullanıcı profili bilgisidir, bu bilginin anonimleştirilmesi ve hesaplamalara katılabilmesi için literatür çalışmaları bir itibar skoru hesaplama yöntemiyle bu niteliği modellerine girdi olarak sağlamaktadır. Bu tez çalışmasında hatanın çözüm süresi tahminini yapan bir model ve yeni bir itibar skoru hesaplama yöntemi önerilmektedir ve hata raportörünün itibarının hesaplanma yönteminin tahmin başarısına etkisi incelenmektedir. Bu kapsamda literatürde yer alan itibar hesaplama yöntemleri ile çalışma kapsamında önerilen yeni itibar hesaplama yöntemi karşılaştırmalı olarak sınıflandırma modeline girdi olarak sağlanmıştır ve itibar hesabı yönteminin etkisi analiz edilmiştir. Çalışma kapsamında, hata çözüm süresi tahmini problemi iki kategorili bir sınıflandırma problemi olarak değerlendirilmiştir. SGD ve XGB olarak iki farklı sınıflandırma modeli çalışma kapsamında analiz edilmiş ve sonuçları sunulmuştur. Hata raporlarının metin verisi Doc2Vec modeli kullanılarak vektörel gösterime çevrilmiştir ve sınıflandırma modellerine girdi olarak sağlanmıştır. Bu kapsamda yalnızca metin verisi ile sınıflandırma yapan temel bir model kurulmuştur. İtibar hesaplama yöntemleri için bu temel model üzerine ayrıca modeller kurulmuştur ve hesaplama yönteminin etkisi bu modellerin performansları analiz edilerek incelenmiştir. Tez çalışması kapsamında Google'ın Chromium ve WebRTC açık kaynak projelerinin hata raporları toplanmış ve önişleme adımlarından sonra veri kümesi haline getirilmiştir. Toplamda 408,504 hata raporu toplanmış ve 130,208 hata raportörünün itibar skoru hesaplaması yapılmıştır. Önişleme adımlarından sonra efektif veri kümesinde 264,692 hata raporu modele girdi olarak kullanılmıştır. Veri kümesinin hata çözüm süresi dağılımı incelenmiş ve HIZLI ve YAVAŞ kategorilerinin eşik değeri 8 gün olarak belirlenmiştir. Bu durumda 140,388 hata raporu HIZLI kategorisinde, 124,306 hata raporu YAVAŞ kategorisinde yer almıştır. Çalışma kapsamında, sınıflandırma modeli ve raportör itibarı hesaplama yöntemi parametreleri değiştirilerek toplamda 16 model eğitilmiş ve sonuçları analiz edilmiştir. Veri kümesi, K katlamalı çapraz doğrulama yöntemiyle model eğitimi ve testinde kullanılmıştır. Model performansları; doğruluk, duyarlılık ve F-skoru metrikleri kullanılarak analiz edilmiştir. SGD sınıflandırma yönteminin kullanıldığı modellerde sınıflandırma başarısının çok düşük olduğu tespit edilmiştir, HIZLI kategorisi için yapılan tahminler başarısızdır. XGB sınıflandırma yönteminde ise iki kategorili sınıflandırmada daha başarılı sonuçlar elde edilmiştir. Sınıflandırma performansında Chroimum projesi için, HIZLI ve YAVAŞ kategorileri için sırasıyla 55% ve 72% F-skorları elde edilmiştir ve WebRTC projesi için 55% ve 60% F-skorları elde edilmiştir. En etkili nitelik olan hata raportörünün itibarının, hesaplanma yönteminin farklarının sınıflandırma performansına etkisi düşük seviyede kalmıştır. Fakat çalışma sonucunda, literatür çalışmalarında önerildiği gibi raportör itibarı sınıflandırmada en etkili nitelik olarak belirlenmiştir. Yazılım projesinin yapısı, geliştirme ekibinin yapısı ve projenin hata raporlama yöntemlerinin, hata çözüm süresinin tahmini modellerinin performansını etkilediği farkedilmiştir. Bu durum, modellerin farklı yapıda bir projenin veri kümesinde uygulanması durumunda farklı performans sonuçlarına ulaşılabileceğini göstermektedir.

Özet (Çeviri)

Software engineering is collection of systematic principles to develop a software product. These principles consist from individual steps; such as information collection, requirement analysis, design, implementation, testing and maintenance. The way these steps are exercised can differ according to software project needs and development team structure. There are widely accepted software development methodology practices which organize software development steps, such as Waterfall, V-Model and Agile development. The waterfall methodology orders these development steps linearly in a way that next step cannot be started before a previous step is completed. Every steps outcome is used as input to next step. Software requirements are needed to be defined clearly before start of the design step. Main downside of the waterfall methodology is outcomes of steps are not investigated and tested until all steps are completed, thus problems in early stages cannot be noticed until late stages of the project development. V-model methodology extends waterfall method by adding testing after each step. This ensures that problems occurred during a step is identified before starting the next step. This model improves waterfall model since problems are spotted before it's too late and costly to fix. But this model increases effort of modifications to a software development step since it is also required to modify tests for the modified step. Nowadays, most software development projects and teams prefer agile development methodology. This methodology emphasizes repetitive execution software development steps. Repetitive executions are named as cycles and it is intended to deliver a running software product early in development phases after each cycle. Modifications within planned steps are welcome, thus development teams may need to change their plans regularly. Problems can occur within software development steps and those problems may affect the resulting software product. Software may behave unexpectedly, these behaviors are called as software bugs. Software bugs are inevitable parts of software development tasks. Software bugs are identified and described in documents named as bug reports. Bug reports' format is determined according to project's needs and structure. Bug reports are generally collected and managed within database tools named as issue tracking tools. Bug reports allow development teams and managers to record and track lifecycle of a bug. Each software bug has its own lifecycle. Their lifecycle begin with their initial bug report is being created. Each bug report needs to be analyzed by the team. Some bug reports might be duplicates of previous reports or they might not identify a real software bug. If a bug report describes a real software bug, root cause of the bug need to be identified by the software development team and most suitable team member is needed to be assigned to resolve the problem. Each of these steps can be logged and recorded to the related report of a bug. Bug reports require summary and description of the identified bug from its reporter. There are also categorical fields recorded along with the textual description of a bug, such as assignee, reporter, report date, closed date, state of the bug report and related software component of the bug. Team members can discuss and share their ideas about a bug analysis on the report through comments. Issue tracking systems allow project members to access, manage and query recorded bug reports of a project. There are several popular issue tracking systems, such as Bugzilla, Github, Gitlab, Jira and Monorail. Each tracking system provides its own way of collecting and managing bug reports. Their requirements can be modified according to the project's needs. Fundamentally all issue tracking systems require summary and textual information within bug report, provides a state field and records bug report creation and closing dates. Bug report states can differ between different tracking systems. For example, Bugzilla provides clear state options for different stages of a bug within its lifecycle; but Github only records state of a bug report as open or closed. Github allows team members to provide their label set to tag bug reports according to their needs. Bug reports can be re-opened within their lifecycle. A bug's resolution duration is determined with difference between last close date and initial report creation date. Even issue tracking systems record these dates as timestamps which is in seconds resolution; previous works in literature reduced the resolution to days. Bugs resolved within their reported day are considered as zero day resolutions. Predicting bugs' resolution time allows team members and project managers to better utilization of time and effort of the development team. There are several works in literature which propose solutions to bug resolution time prediction to help out team members to utilize their work effectively and efficiently. This problem is often considered as a classification problem and proposed solutions classify bug reports into two categories as FAST and SLOW. Even there are researches conducted to increase number of categories in classification, two category approach is resulted best in performance. Both textual data, summary, description and comments and categorical fields within bug reports are utilized in proposed models. Most of the works in literature propose models built on top of fundamental machine learning classification models. kNN-based models, SVM models and decision tree models are utilized for classifying bug reports. Recent works utilize deep learning algorithms to build their proposed models. Even deep learning models like LSTM model allows to make use of updates recorded to bug reports within time and handle bug reports comprehensively, classification performance of proposed deep learning models are not differing from fundamental machine learning models. Fundamental classification models can only utilize latest state of a bug report, thus temporal features of bug reports cannot be taken into consideration. Previous work utilize categorical fields and textual information within bug reports for classification. Bug reporter is one of the categorical fields within a bug report and it records an unique identifier assigned to reporter user. This field is utilized within models after anonymization and extracting statistical record of the reporter, which is named as reputation. Previous works state that reporter field of a bug report is the most effective feature for their proposed models. Issue tracking systems stores a database for registered users within the system which may consist of development team members and individual reporters such as users of the software. This database can be utilized for calculating reputation score for individuals by tracing their activity within issue tracking systems. Bug report opening, commenting, field updating, bug fixing activities of a user can be traced within issue tracking systems. Previous work proposes reputation calculation methods to utilize the most effective feature for classification. This work proposes a new reporter reputation calculation method and analyzes effect of the reputation score on predicting bug resolution time. Textual data within bug reports are utilized by representing them with vectors by Doc2Vec models. A basis model is constructed that only uses vector representation of textual data to classify bug reports. Bug reports are classified into two categories as FAST and SLOW and bug resolution time is calculated in days resolution. Two classifier models are used and compared according to their performance, which are SGD and XGB classifier models. Google's Chroimum and WebRTC projects' bug reports are collected and a data set is gathered after collected reports are preprocessed. Total 408,504 number of bug reports are collected from Monorail issue tracking system's, system that is used in Chromium and WebRTC projects, application programming interface. Chroimum project has 130,208 individuals registered in its issue tracking system and a reputation score is calculated for each of the individuals. There is 264,692 bug reports remained after preprocessing. Remaining bug reports' resolution time distribution is analyzed and 8 days is determined as threshold value between FAST and SLOW categories. FAST category includes 140,388 number of bug reports and SLOW category includes 124,306 number of bug reports. Total number of 16 different models are trained by tweaking vector size for textual data representation, type of the classifier model and reporter reputation calculation method and results for analyzed to define reporter reputations' effect on issue resolution time prediction. Models are trained and tested with K-fold cross validation method in which dataset is split into 10 groups. Models' performances are analyzed with precision, recall and F-score calculation metrics. Model results show that reporter reputation is an effective feature for bug resolution time prediction. Models, which utilize SGD classification method performed poorly in a way that, bug reports under FAST category cannot be predicted. XGB classificiation method based models performed better in classification performance. They resulted with 55\% and 72\% F-scores for FAST and SLOW categories respectively for the Chromium project and 55\% and 60\% F-scores for FAST and SLOW categories for the WebRTC project. Vector size of the Doc2Vec model, vector representation of the textual data within bug reports, doesn't affect the classification performance. Even different reputation calculation methods performed similarly in classification performance, this work shows that bug reporter is the most effective feature as previous work. As a conclusion of this work, bug reporter is most effective feature for bug resolution time prediction. This prediction problem can be solved with classification models and two category is enough for most conditions. Effect of the reporter reputation calculation method to the classification performance can be seen with a different project; since team structure, bug reporting practices within the project affects the distribution of reputation scores.

Benzer Tezler

Tez No
774502
Ceza hukukunda hukuka uygunluk nedenlerinin maddi unsurlarında hata
Mistake in the material elements of justified defences in criminal law
HASAN İBA
Doktora
Türkçe
2022
Hukuk Erzincan Binali Yıldırım Üniversitesi
Kamu Hukuku Ana Bilim Dalı
DR. ÖĞR. ÜYESİ BURHAN CANER HACIOĞLU
Tez No
792592
Hata yönetim kültürünün ürün yeniliği ve süreç yeniliği üzerine etkileri
The effects of eror management culture on product innovation and process innovation
MURAT AKAN
Doktora
Türkçe
2022
İşletme Yaşar Üniversitesi
İşletme Ana Bilim Dalı
PROF. DR. ÇAĞRI BULUT
Tez No
794229
Bosna Hersek'te geçiş dönemlerinde yaşayan âdet, inanış ve uygulamalar
Customs, beliefs and practices during the transition periods in Bosnia and Herzegovina
HATA TRAKO HARŞIT
Yüksek Lisans
Türkçe
2023
Türk Dili ve Edebiyatı Ondokuz Mayıs Üniversitesi
Türk Dili ve Edebiyatı Ana Bilim Dalı
DOÇ. DR. CAFER ÖZDEMİR
Tez No
352110
Paralel hata ayıklama
Parallel debugging
SİNAN KUL
Yüksek Lisans
Türkçe
2014
Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrol Atatürk Üniversitesi
Bilgisayar Mühendisliği Ana Bilim Dalı
YRD. DOÇ. DR. DENİZ DAL
Tez No
352443
Bulanık mantık ve gri teori esaslı htea ile otomotiv endüstrisi imalatında hata önceliklendirme
Risk prioritization in the production part of automotive industry with fmea using fuzzy evidential reasoning approach and grey theory
MEHMET TURGUT
Yüksek Lisans
Türkçe
2013
Endüstri ve Endüstri Mühendisliği İstanbul Teknik Üniversitesi
Endüstri Mühendisliği Ana Bilim Dalı
DOÇ. DR. ALP ÜSTÜNDAĞ

Geri Dön