Yazılım Hataları ile ˙Ili¸
skili Olmayan Olay
Kayıtlarının Analizi ve Sınıflandırılması: Bir
Vaka C
¸ alı¸
sması
Ethem Utku Akta¸s1,2, Mehtap ¨Ozaltın Eri¸s1, Haluk Altunel1, and Cemal
Yılmaz2
1
Softtech A.S¸., Arge Merkezi, 34947 ˙Istanbul, T¨urkiye {utku.aktas, mehtap.ozaltin, haluk.altunel}@softtech.com.tr
2 M¨uhendislik ve Do˘ga Bilimleri Fak¨ultesi, Sabancı ¨Universitesi, 34956 ˙Istanbul,
T¨urkiye
cyilmaz@sabanciuniv.edu
¨
Ozet. Yazılım olay kayıtları veya yazılım hata raporları m¨u¸sterilerin veya test¸cilerin bir yazılım ¨ur¨un¨un¨u kullanırken kar¸sıla¸stıkları sorunları raporladıkları kayıtlardır. Olay kaydı y¨onetim sistemleri aracılı˘gıyla kul-lanıcılar kolay ve hızlı bir ¸sekilde kayıt olu¸sturabilmekte, yazılımcıların da kısa bir s¨ure i¸cerisinde bu kayıtlara ¸c¨oz¨um ¨uretmesi beklenmektedir. Bu sistemler sayesinde yazılım ¨ur¨un¨un¨un kalitesinin artırılması ve m¨u¸steri memnuniyetinin sa˘glanması hedeflenmektedir. Ancak kullanıcıların ko-lay bir ¸sekilde kayıt a¸cabiliyor olması, geli¸stirme talebi, operasyonel talep veya bilgi eksikli˘gi kaynaklı, aslında yazılım hatası olmayan konularda da kayıt a¸cılmasına neden olmakta, bu durumlar da yazılımcıların ilgili kaydı iade etmesi ile sonu¸clanmaktadır. Bu t¨ur kayıtlara yazılımcıların zaman harcıyor olması verimliliklerini d¨u¸s¨urmekte, aynı zamanda yazılım olay kaydı s¨ure¸clerinin y¨onetimini de zorla¸stırmaktadır. Bu ¸calı¸smayla, end¨ustriyel bir vakaya ait olay kaydı adetlerindeki artı¸s e˘gilimi analiz edilmi¸s ve kayıtlar kapatılırken se¸cilen sebep kategorileri incelenerek yazı-lım hatası olan ve olmayan kayıtlar ayrı¸stırılmı¸stır. Sonrasında kayıtların yazılım hatasından kaynaklanıp kaynaklanmadı˘gı tahmin edilmi¸s ve yazı-lım hatasından kaynaklanmayan kayıtların % 77 f-skor ile tahminlenebil-di˘gi g¨or¨ulm¨u¸st¨ur. Bu ilk ¸calı¸sma sonucunda, kullanıcılara veya yazılımcı-lara bir olay kaydının yazılım hatasından kaynaklanıp kaynaklanmadı˘gına dair otomatik olarak uyarı verecek bir sistemin m¨umk¨un oldu˘gu g¨or¨ulm¨ u¸s-t¨ur.
Anahtar Kelimeler: Yazılım Hata Kayıtları, Bilgi C¸ ıkarımı, Veri Ana-lizi, Veri Madencili˘gi.
Analysis and Classification of Issue Reports Not
Related to Software Bugs: A Case Study
Ethem Utku Akta¸s1,2, Mehtap ¨Ozaltın Eri¸s1, Haluk Altunel1, and Cemal
Yılmaz2
1 Softtech Inc., Research and Development Center, 34947 Istanbul, Turkey
{utku.aktas, mehtap.ozaltin, haluk.altunel}@softtech.com.tr
2
Faculty of Engineering and Natural Sciences, Sabanci University, 34956 Istanbul, Turkey
cyilmaz@sabanciuniv.edu
Abstract. Software issue records or bug reports are records where cus-tomers or testers report problems encountered while using a software product. Users can create issue reports easily and quickly through bug report management systems, and software developers are expected to solve these records in a limited amount of time. With these systems, it is aimed to increase the quality of the software product and to ensure customer satisfaction. However, since the users can easily create these records, software development requests, operational requests or issues arising from lack of information can also be reported such that there is no software error or failure in the case. In such cases, software developers return the records without any action. The fact that software developers spend time on such records reduces their efficiency and makes it difficult to manage bug repositories. In this study, the increase in the amount of issue records for an industrial case was analysed and by categorizing the issue reports as bugs or non-bugs according to the reason option selected during the closure of the report, a classification study is conducted. The results show that 77 % f-score can be reached for the categorization of issue records as non-bugs. As a result of this initial work, it appears that a system that automatically alerts users or software developers whether an issue record is caused by a software bug, is possible.
Keywords: Bug Reports, Information Retrieval, Data Analysis, Data Mining.
1
Giri¸
s
Yazılım sistemlerinin kalitesini artırmak i¸cin, kullanıcıların ve test¸cilerin kar¸sıla¸s-tıkları yazılım hatalarını raporlayabilmeleri i¸cin ¸ce¸sitli yazılım hata izleme sis-temleri kullanılmaktadır. Ancak b¨uy¨uk yazılım sistemlerinde her g¨un y¨uzlerce kayıt a¸cılabilmektedir. Anvik ve arkada¸sları Mozilla uygulamasında her g¨un 300 kadar yeni hata kaydı a¸cıldı˘gını, bu kadar ¸cok kaydın yazılımcıların ¸c¨ozebilecekleri sayıların ¸cok ¨ust¨unde oldu˘gunu raporlamı¸slardır [1].
Yazılımcılara yardımcı olması amacıyla hata kayıtlarının otomatik olarak sınıflandırılması konusunda ¸ce¸sitli deneysel ¸calı¸smalar yapılmı¸stır. Hata kayıtları-nın kim tarafından ¸c¨oz¨ulmesi gerekti˘gi [2], ne kadar s¨urede ¸c¨oz¨ulebilece˘gi [3], ge¸cerli olup olmadıkları [4], ¸siddeti [5], m¨ukerrer olup olmadıkları [6] gibi konu-larda otomatik olarak tahminleme yapılması denenmi¸s ve elde edilen sonu¸clar raporlanmı¸stır. Bu ¸calı¸smalarda geleneksel yakla¸sım, hata kayıtlarında yer alan ¨
ozet ve a¸cıklama alanlarında ge¸cen metin verisi kullanılarak, ilgili veri i¸cinde ge¸cen terimlerin tf-idf endeksi ile g¨osterimi ve makine ¨o˘grenmesi teknikleri ile otomatik olarak sınıflandırılmasıdır.
Softtech 1000 ki¸sinin ¨uzerinde nitelikli i¸s g¨uc¨u ile, 2 Teknokent ofisi ve 2 Ar-Ge merkezi olmak ¨uzere toplam 7 farklı yerle¸skede, yenilik¸ci projeler ¨ureten bir Ar-Ge ¸sirketidir. Ana faaliyet alanı finans ve bankacılık olmakla birlikte, ¸ce¸sitli yelpazede ¨ur¨unler sunmaktadır. Softtech de ¨uretim ortamında olu¸san hata kayıtlarını y¨onetmek i¸cin hata kaydı izleme sistemlerini kullanmakta ve bu s¨ure¸cte yazılımcıların hayatlarını kolayla¸stıracak ¸ce¸sitli yakla¸sımlara ihtiya¸c duymak-tadır.
Bu ¸calı¸smada Softtech’in ¨uretim ortamında ¸c¨oz¨umledi˘gi olay kaydı veri seti kullanılmı¸stır. ¨Uretim ortamında her g¨un 400 civarı kayıt a¸cılmakta ancak son za-manlarda bu kayıt sayılarında artı¸s e˘gilimi oldu˘gu g¨ozlenmektedir. C¸ alı¸smadaki amacımız bu artı¸s e˘gilimini analiz etmek ve aslında yazılım hatası olmayan olay kayıtları otomatik olarak tahminleyebilen veya ¨oneride bulunabilecek bir sis-temin m¨umk¨un olup olmadı˘gını ortaya koymaktır. Dolayısıyla ¸calı¸sma ile a¸sa˘gıdaki ara¸stırma sonu¸clarına yanıt aranmı¸stır:
- End¨ustriyel vakaya ait olay kayıtlarının i¸cinde yazılım hatası olmadı˘gı y¨on¨unde de˘gerlendirilebilecek kayıtların oranı nedir?
- ˙Ilgili kayıtları otomatik olarak ba¸sarılı bir ¸sekilde sınıflandırabilir miyiz? Bildirinin geri kalan kısmı ¸su ¸sekilde organize edilmi¸stir: B¨ol¨um 2’de ilgili ¸
calı¸smalar aktarılmaktadır, B¨ol¨um 3’te analiz ve sınıflandırma konusunda uygu-ladı˘gımız y¨ontem sunulmaktadır, B¨ol¨um 4’te yapılan deneyler ve elde edilen sonu¸clar tartı¸sılmaktadır, B¨ol¨um 5’te yapılan deneysel ¸calı¸smanın ge¸cerlili˘gine dair tehditler irdelenmektedir ve B¨ol¨um 6’da sonu¸cların ¨ozeti sunulmakta ve gelecek olası ¸calı¸smalar hakkında bilgi verilmektedir.
2
˙Ilgili C
¸ alı¸
smalar
Antoniol ve arkada¸slarının ¸calı¸smaları [4], bir olay kaydının yazılım hatası kay-naklı olup olmadı˘gının sınıflandırılması y¨on¨unde yapılan ilk ¸calı¸smalardandır. Bu ¸
calı¸smada Mozilla, Eclipse ve JBoss projelerinden elde ettikleri 1800 adet olay kaydını el ile yazılım hatası kaynaklı olan ve olmayan olarak sınıflandırmı¸slardır. Karar A˘gacı, Naive Bayes ve Lojistik Regresyon algoritmalarını kullanarak %82-’ye varan bir do˘grulukla otomatik olarak sınıflandırma yapabilmi¸slerdir. Bu ¸ calı¸s-mada aynı zamanda, hata kayıtlarındaki ¸ce¸sitli ¨ozniteliklerin sınıflandırma per-formansına etkisini ara¸stırmı¸slardır. Zhou ve arkada¸sları [10] aynı verisetini
kullanarak metin madencili˘gi ve veri madencili˘gi tekniklerini birle¸stirerek daha iyi sonu¸clar elde edebildiklerini ortaya koymu¸slardır.
Herzig ve arkada¸sları ise olay kaydı takip sistemlerinde tutulan kayıtların hatalı sınıflandırılmasından kaynaklanan maliyeti detaylı bir ¸sekilde ¸calı¸smı¸slardır [11]. Be¸s farklı a¸cık kaynak olay kaydı takip sisteminden elde ettikleri 7401 ka-palı kaydın g¨ozden ge¸cirilmesinin 90 g¨un s¨urd¨u˘g¨un¨u ve bu kayıtların ¨u¸cte birinin aslında yazılım kaynaklı olmadı˘gını, dolayısıyla hatalı sınıflandırıldı˘gını rapor-lamı¸slardır.
Pandey ve arkada¸sları da [12] ¨u¸c farklı a¸cık kaynak olay kaydı takip siste-minden elde ettikleri kayıtlarla benzer bir ¸calı¸sma yapmı¸s ve kayıtları yazılım kaynaklı olan ve olmayan ¸seklinde sınıflandırmı¸slardır. RF (Random Forest) ve DVM (Destek Vekt¨or Makinesi) gibi algoritmalarla projeye ba˘glı olarak %75-83 do˘gruluk oranlarına ula¸sabildiklerini g¨orm¨u¸slerdir. C¸ alı¸smada kayıtları ¨on i¸slemden ge¸cirirken ilgili sınıflarda en sık ge¸cen terimleri se¸cmi¸slerdir.
3
Y¨
ontem
¨
Onerilen y¨ontemin amacı; vakaya ait kayıtların nedenlerini ortaya koyarak yazılım hatası kaynaklı olup olmadıklarını tespit etmek, sonrasında ise bu kayıtları ba¸sarılı bir ¸sekilde sınıflandırmanın m¨umk¨un olup olmadı˘gını ortaya koymaktır. Y¨ontem b¨ol¨um¨unde ¨oncelikle kayıtların yazılım hatasından kaynaklandı˘gını ne ¸sekilde ortaya koydu˘gumuz, sonrasında ise do˘gal dilde yazılmı¸s olay kayıtlarının s¨ozc¨uk ¸
cantası modeli ile temsili ve sınıflandırılması anlatılmı¸stır.
3.1 Veri Seti
C¸ alı¸smada 2019 yılının ilk be¸s ayındaki “Tamamlandı” ve “˙Iade Edildi” stat¨us¨ un-deki olay kayıtları kullanılmı¸stır. Bu kayıtların ¨uzerinde olay kaydı olup ol-madıklarına dair bir alan bulunmamaktadır. Ancak yazılımcılar kayıtları “Tamam-landı” veya “˙Iade Edildi” se¸cene˘gi ile kapatırken, sebep kategorisi alanını, kendi-lerine sunulan se¸ceneklerden birisini se¸cerek doldurmaktadır. Bu alandaki bilgi kullanılarak kayıtlar, yazılım kaynaklı olan veya olmayan olarak sınıflandırılmı¸stır.
¨
O˘grenme a¸samasında Ocak-Nisan ayları arasında a¸cılan kayıtlar, test a¸samasında ise Mayıs ayında a¸cılan kayıtlar kullanılmı¸stır.
3.2 Yazılım Hatasından Kaynaklanmayan Olay Kayıtlarının Tespiti Olay kayıtları yazılımcılar tarafından kapatılırken sebep kategorilerinden birisi se¸cilmektedir. Kayıt i¸slem yapılarak kapatılıyorsa, “Tamamlandı” stat¨us¨une ge-tirilmekte, i¸slem yapılmadan iade ediliyorsa “˙Iade Edildi” stat¨us¨une getirilmek-tedir. Her iki durumda da olası sebep kategorilerinden birisinin se¸cilmesi gerek-mektedir.
¨
Oncelikle, olay kaydı adetleri, ilgili sebep kategorileri ve olu¸sturuldukları ay bilgisine g¨ore ¸cıkarılmı¸s ve hangilerinde aylık bazda artı¸s e˘gilimi oldu˘gu ortaya konmu¸stur. Sonrasında, kapalı olan kayıtlardan sebep kategorisi “Kullanıcı bilgi
eksikli˘gi”, “Olay olarak nitelendirilmemelidir”, “Operasyonel talep”, “Geli¸stirme talebi” vb. olanlar (1) “Yazılım Hatası Kaynaklı Olmayan”, kalan di˘ger kayıtlar da (2) “Yazılım Hatası Kaynaklı” olarak gruplandırılmı¸stır. Sınıflandırma ¸ calı¸sma-sında olay kaydının bu iki sınıftan hangisine ait oldu˘gu tahminlenmi¸stir.
3.3 Olay Kayıtlarının Sınıflandırması
Yazılım hata raporlarının sınıflandırılması i¸cin hatanın anlatıldı˘gı ¨ozet ve a¸cıklama alanlarındaki metin verisi girdi olarak kullanılır. Metin verisinde istatistiksel olarak anlam ifade eden terimlerin tespiti i¸cin ¨oncelikle metinler kelimelere b¨ol¨un¨ur (tokenization) ve durak kelimeler (stop words) ayıklanır. Daha ¨onceki ¸calı¸smalarda yazılım hata sınıflandırmasında kelime k¨oklerine inmenin etkisinin d¨u¸s¨uk oldu˘gu raporlandı˘gından [7] bu ¸calı¸smada da k¨ok bulma i¸slemi yapılmamı¸stır.
Elde edilen kelimeler kullanılarak n-gramlar hesaplanır. Bu ¸calı¸smada 2-gram kullanılmı¸stır, 2-gram art arda gelen 1’li ve 2’li kelime dizinleridir. Sonu¸c olarak elde edilen her bir kelime veya kelime dizini terim olarak adlandırılmaktadır. ˙Ilgili terimlerin her bir yazılım hata kaydı i¸cin ne kadar anlam ifade etti˘ginin anla¸sılması i¸cin tf-idf endeksi kullanılır; tf terim frekansını, idf ise ters dok¨uman frekansını ifade eder [8]. Bir hata kaydında ge¸cen her bir terim i¸cin tf-idf de˘geri a¸sa˘gıdaki ¸sekilde hesaplanır:
tf (t, o) = t teriminin o olay kaydında g¨or¨ulme sayısı
o olay kaydındaki toplam terim sayısı (1) idf (t, O) = log(O havuzundaki toplam olay kaydı sayısı
t terimini i¸ceren olay kaydı sayısı ) (2) tf − idf (t, o, O) = tf (t, o) × idf (t, O) (3) Destek Vekt¨or Makineleri (DVM) metin madencili˘ginde sıklıkla kullanılan ve ba¸sarılı sonu¸clar veren bir algoritmadır. DVM algoritması ile, farklı iki sınıf arasında maksimum marj bırakan bir d¨uzlem olu¸sturularak sınıflandırma hataları en aza indirgenmeye ¸calı¸sılır. Marj, iki sınıfın d¨uzleme en yakın noktalarından d¨uzleme olan uzaklıklarının toplamıdır [9]. C¸ alı¸smada amacımız farklı algorit-maları kıyaslamak olmayıp bilinen bir algoritma ile ba¸sarılı sonu¸clar elde edip edemedi˘gimizi ortaya koymaktır. Bu nedenle Pandey ve arkada¸slarının yakın zamanda yaptıkları ¸calı¸sma sonucunda ba¸sarılı sonu¸clar elde ettiklerini rapor-ladıkları DVM algoritması se¸cilmi¸stir [12]. C¸ alı¸smamızda ¨o˘grenme a¸samasında 10-kat ¸capraz do˘grulama y¨ontemi kullanılarak model olu¸sturulmu¸stır.
Sonu¸cları de˘gerlendirmek i¸cin kesinlik, duyarlılık ve f-skor metrikleri kul-lanılmı¸stır. Kesinlik (precision), bir sınıf i¸cin do˘gru tahmin edilmi¸s kayıt sayısı, o sınıf i¸cin yapılan toplam tahmin sayısına b¨ol¨unerek bulunmaktadır. Duyarlılık (recall) ise bir sınıf i¸cin do˘gru tahmin edilmi¸s kayıt sayısı, o sınıfa ait ger¸cek kayıt sayısına b¨ol¨unerek bulunmaktadır. F-skor, kesinlik ve duyarlılı˘gın harmonik or-talamasıdır. Metriklerin hesaplanma y¨ontemleri a¸sa˘gıda verilmi¸stir [8].
kesinlik(s) = s sınıfı i¸cin do˘gru yapılan tahmin adedi
duyarlılık(s) =s sınıfı i¸cin do˘gru yapılan tahmin adedi
veri setinde s sınıfına ait kayıt adedi (5)
f − skor(s) = 2 × kesinlik(s) × duyarlılık(s)
kesinlik(s) + duyarlılık(s) (6)
4
Vaka C
¸ alı¸
sması Sonu¸
cları
Bu b¨ol¨umde ¨oncelikle sebep kategorilerine g¨ore kayıt adetleri aylık bazda tespit edilerek, toplam adetlerin artı¸sında etkili olan konular ortaya konulmu¸stur. Son-rasında ise ilgili kayıtlar ve bu kayıtların i¸cerdi˘gi metin bilgisi kullanılarak, yazılım hatası kaynaklı olmayan kayıtlar i¸cin tahminleme ¸calı¸sması yapılmı¸s ve sonu¸clar aktarılmı¸stır.
4.1 Sebep Kategorilerine g¨ore Kayıt Adetleri
S¸ekil 1’de “Tamamlandı” stat¨us¨undeki kayıtların sebeplerine g¨ore (“Kullanıcı bilgi eksikli˘gi”, “Operasyonel Talep” vb.) aylık bazda da˘gılımları, S¸ekil 2’de ise “˙Iade Edildi” stat¨us¨undeki kayıtların sebeplerine g¨ore (“Kullanıcı bilgi eksikli˘gi”, “Operasyonel Talep” vb.) da˘gılımları yine aylık bazda verilmi¸stir. (S¸ekillerde ilgili ¸cizgilerin hangi sebep kategorisine ait oldukları firmaya ait ¨ozel bilgi oldu˘gu i¸cin belirtilmemi¸stir.)
“Tamamlandı” stat¨us¨undeki kayıtlar i¸cin 2018 Kasım ayından itibaren artı¸s e˘giliminde olan ve en fazla adede sahip kayıtlar, “Kullanıcı bilgi eksikli˘gi/talebi” sebep kategorisi se¸cene˘gi ile kapatılmı¸s kayıtlardır. “˙Iade Edildi” stat¨us¨undeki kayıtlar i¸cinse di˘ger t¨um kayıt tiplerinden ¸cok daha fazla adede sahip kayıtlar, “Olay kaydı olarak nitelendirilmemelidir” se¸cene˘gi ile kapatılan kayıtlar olup, son d¨onemde bu tipteki kayıt adetlerinde de artı¸s g¨ozlenmektedir.
Her iki sebep kategorisi de aslında yazılım kaynaklı olmayan kayıtlarda son d¨onemde artı¸s oldu˘gunu i¸saret etmektedir. Bu durum, olay kayıtlarının kay-nak nedeninin otomatik olarak tespit edilebilmesinin ¨onemini ortaya koymak-tadır. Yazılımsal kaynaklı olmayan kayıtların otomatik olarak tespit edilebilmesi ve kullanıcılara bilgi ama¸clı olarak g¨osterilmesinin, yazılımcıların verimlili˘ginin artırılmasında ve genel olarak olay kaydı y¨onetim s¨urecinin iyile¸stirilmesinde olumlu katkısı olaca˘gı ¨ong¨or¨ulm¨u¸st¨ur.
4.2 Yazılım Hatası Kaynaklı Olmayan Kayıtların Tahminlenmesi C¸ alı¸sma i¸cin 2019 yılında a¸cılan kayıtlardan stat¨us¨u “Tamamlandı” veya “˙Iade Edildi” olanlar kullanılmı¸stır. B¨ol¨um 2.1’de anlatıldı˘gı ¸sekilde, sebep kategorisi alanına bakılarak, kayıtlar “Yazılım Hatası Kaynaklı” ve “Yazılım Hatası Kay-naklı De˘gil” olarak iki sınıfa ayrılacak ¸sekilde i¸saretlenmi¸stir. Veriye ait ¨ozet bilgi Tablo 1’de verilmi¸stir. Yazılım hatasından kaynaklanmayan kayıtların adedinin toplam kayıt adedine oranının olduk¸ca y¨uksek oldu˘gu g¨or¨ulmektedir (% 44).
0 500 1000 1500 2000 2500 3000 20 18 -01 20 18 -02 20 18 -03 20 18 -04 20 18 -05 20 18 -06 20 18 -07 20 18 -08 20 18 -09 20 18 -10 20 18 -11 20 18 -12 20 19 -01 20 19 -02 20 19 -03 20 19 -04 Adet Zaman
S¸ekil 1. “Tamamlandı” stat¨us¨undeki kayıtların sebep kategorilerine g¨ore aylık adetleri.
0 200 400 600 800 1000 1200 1400 1600 20 18 -01 20 18 -02 20 18 -03 20 18 -04 20 18 -05 20 18 -06 20 18 -07 20 18 -08 20 18 -09 20 18 -10 20 18 -11 20 18 -12 20 19 -01 20 19 -02 20 19 -03 20 19 -04 Adet Zaman
Tablo 1. Elde edilen veriye ait ¨ozet bilgi.
Zaman aralı˘gı Toplam Adet Yazılım hatasından kaynaklanmayan kayıt adedi Ocak 2019 - Mayıs 2019 41.930 18.385
DVM algoritması ile yapılan tahminleme ¸calı¸sması sonucunda Tablo 2’de ver-ilen kesinlik, duyarlılık ve f-skor de˘gerlerine ula¸sılmı¸stır. Sonu¸clar, bu end¨ustriyel vakada, geleneksel bir yakla¸sım kullanılarak dahi, y¨uksek ba¸sarı ile yazılım hatasın-dan kaynaklanmayan kayıtların tahminlenebildi˘gini g¨ostermi¸stir.
Tablo 2. Tahminleme ¸calı¸sması sonu¸cları.
Sınıf Kesinlik Duyarlılık F-Skor
Yazılım hatasından kaynaklanan 0,88 0,78 0,83 Yazılım hatasından kaynaklanmayan 0,72 0,84 0,77
5
Ge¸
cerlili˘
ge Tehditler
C¸ alı¸sma y¨ur¨ut¨ul¨urken yazılımcıların sebep kategorisi alanını doldurdukları bil-ginin ge¸cerli oldu˘gu, hatalı bir se¸cim yapmadıkları varsayılmı¸stır. Olay kaydının yazılım hatasından kaynaklanıp kaynaklanmadı˘gı bilgisine, yazılımcıların yaptık-ları bu se¸cimden yola ¸cıkılarak ula¸sılmı¸stır.
C¸ alı¸sma end¨ustriyel vakaya ait tek bir veri seti ile y¨ur¨ut¨ulm¨u¸st¨ur. Ba¸ska vaka ¸
calı¸smalarında farklı sonu¸cların elde edilmesi m¨umk¨und¨ur. C¸ alı¸smada amacımız olay kaydı sistemlerinde aslında yazılım hatası kaynaklı olmayan kayıtların ¸ coklu-˘
gunu ve bilinen bir teknik ile ba¸sarılı tahminleme sonu¸cları elde edilebildi˘gini ortaya koymaktır, bu nedenle metin madencili˘gi konusunda iyi sonu¸clar verdi˘gi bilinen DVM algoritması se¸cilmi¸stir. C¸ alı¸sma yapılırken algoritmanın parame-treleri ayarlanmamı¸s, varsayılan parametre de˘gerleri ile sonu¸clar elde edilmi¸stir.
6
Sonu¸
c ve Gelecek C
¸ alı¸
smalar
Bu ¸calı¸sma ile ¨oncelikle olay kaydı adetlerinde artı¸sa neden olan kayıtların kay-nak nedenleri tespit edilmi¸stir. Bu artı¸sta yazılımcılar tarafından, kullanıcı bilgi eksikli˘gi veya olay olarak nitelendirilmemesi gerekti˘gi d¨u¸s¨un¨ulen kayıtların etk-ili oldu˘gu g¨or¨ulm¨u¸st¨ur. Yazılımcılar tarafından se¸cilen kayıt nedenleri grupla-narak incelendi˘ginde, yazılım hatasından kaynaklanmayan kayıtların olduk¸ca y¨uksek adetlere ula¸stı˘gı g¨or¨ulm¨u¸st¨ur. Yapılan tahminleme ¸calı¸smasında yazılım hatası kaynaklı olmayan kayıtların ba¸sarılı bir ¸sekilde tahminlenebildi˘gi ortaya konmu¸stur. Gelecek ¸calı¸smalarda bu tip kayıtların ¨on¨une ge¸cebilmek i¸cin alınabi-lecek aksiyonların ve sistemde yapılabialınabi-lecek otomasyonların de˘gerlendirilmesi d¨u¸s¨un¨ulmektedir.
Kaynak¸
ca
1. Anvik, J., Hiew, L., Murphy, G. C. (2005). Coping with an open bug repository. In Proceedings of the 2005 OOPSLA workshop on Eclipse technology eXchange (pp. 35-39). ACM.
2. Anvik, J., Hiew, L., Murphy, G. C. (2006). Who should fix this bug?. In Proceedings of the 28th international conference on Software engineering (pp. 361-370). ACM. 3. Weiss, C., Premraj, R., Zimmermann, T., Zeller, A. (2007). How long will it take to
fix this bug?. In Fourth International Workshop on Mining Software Repositories (MSR’07: ICSE Workshops 2007) (pp. 1-1). IEEE.
4. Antoniol, G., Ayari, K., Di Penta, M., Khomh, F., Gu´eh´eneuc, Y. G. (2008). Is it a bug or an enhancement?: a text-based approach to classify change requests. In CASCON (Vol. 8, pp. 304-318).
5. Menzies, T., Marcus, A. (2008). Automated severity assessment of software defect reports. In 2008 IEEE International Conference on Software Maintenance (pp. 346-355). IEEE.
6. Bettenburg, N., Premraj, R., Zimmermann, T., Kim, S. (2008). Duplicate bug re-ports considered harmful. . . really?. In 2008 IEEE International Conference on Soft-ware Maintenance (pp. 337-345). IEEE.
7. Murphy, G., Cubranic, D. (2004). Automatic bug triage using text categorization. In Proceedings of the Sixteenth International Conference on Software Engineering and Knowledge Engineering.
8. Manning, C., Raghavan, P., Sch¨utze, H. (2010). Introduction to information re-trieval. Natural Language Engineering, 16(1), 100-103.
9. Joachims, T. (1998). Text categorization with support vector machines: Learning with many relevant features. In European conference on machine learning (pp. 137-142). Springer, Berlin, Heidelberg.
10. Zhou, Y., Tong, Y., Gu, R., Gall, H. (2016). Combining text mining and data mining for bug report classification. Journal of Software: Evolution and Process, 28(3), 150-176.
11. Herzig, K., Just, S., Zeller, A. (2013). It’s not a bug, it’s a feature: how misclassifi-cation impacts bug prediction. In Proceedings of the 2013 international conference on software engineering (pp. 392-401). IEEE Press.
12. Pandey, N., Sanyal, D. K., Hudait, A., Sen, A. (2017). Automated classification of software issue reports using machine learning techniques: an empirical study. Innovations in Systems and Software Engineering, 13(4), 279-297.
