=Paper= {{Paper |id=Vol-1980/UYMS17_paper_66 |storemode=property |title=Yazilim Hatalarinin Atanmasi: Bir Sistematik Literatur Haritalamasi(Assignment of Software Bugs: A Systematic Literature Mapping Study) |pdfUrl=https://ceur-ws.org/Vol-1980/UYMS17_paper_66.pdf |volume=Vol-1980 |authors=Bahar Gezici,Nurseda Ozdemir,Vahid Garousi |dblpUrl=https://dblp.org/rec/conf/uyms/GeziciOG17 }} ==Yazilim Hatalarinin Atanmasi: Bir Sistematik Literatur Haritalamasi(Assignment of Software Bugs: A Systematic Literature Mapping Study)== https://ceur-ws.org/Vol-1980/UYMS17_paper_66.pdf
Yazılım hatalarının atanması: bir sistematik literatür
                    haritalaması

         Bahar GEZİCİ1, Nurseda ÖZDEMİR1, Vahid GAROUSİ2,1
                   1Yazılım Mühendisliği Araştırma Grubu

    Bilgisayar Mühendisliği Bölümü, Hacettepe Üniversitesi, Ankara, Türkiye
                     2Wageningen Üniversitesi, Hollanda


1{bhrgezici,    nursedaozdemr}@gmail.com, 2vahid.garousi@wur.nl

  Özet. Büyük ölçekli yazılım projelerinde yazılım hata raporunu ilgili takıma
  veya ilgili yazılım geliştiriciye atama sürecini yönetmek zorlu ve zaman alan bir
  süreçtir. Hata atama süresini azaltmak ve doğru karar verme başarısını artırmak
  için çeşitli yazılım hata ataması yöntemleri geliştirilmiştir. Hata atama sürecin-
  de otomatik karar vermeyi desteklemek için araştırmacılar ve uygulayıcılar çe-
  şitli yöntem, araç ve süreçler sunmuşlardır. Yazılım hata ataması hakkında ya-
  pılan akademik ve teknik araştırma sayısı artmaktadır ve bu durum, mevcut ça-
  lışmaları ve uygulamaları sistematik olarak kategorize etme ve genel bir bakış
  açısı sunma ihtiyacını beraberinde getirmiştir. Mevcut çalışmalara genel bir ba-
  kış sunmak amacıyla yazılım hata ataması konusunda bu sistematik haritalama
  çalışması yapılmıştır. Bu çalışmada akademik literatürü taramak amacıyla çeşit-
  li arama motorları (Google Scholar ve Scopus gibi) kullanılmıştır. Bu SH ve
  sonuçları; konferanslarda yayınlanmış makaleler (45 tane), dergilerde yayın-
  lanmış makaleler (24 tane), sempozyum makaleleri (12 tane), çalıştay makalele-
  ri (4 tane), tezler (3 tane) ve diğerlerinden (5 tane) oluşan 93 birincil kaynağa
  dayanmaktadır. Sonuç olarak, birincil çalışmaların yaklaşık olarak %46’sı güçlü
  deneysel çalışma, olup %40’ı Bayes İstatistiği makine öğrenme yöntemini kul-
  lanmıştır.

  Anahtar sözcükler: Yazılım hatası; Hata atanması; Sistematik literatür harita-
  laması


Assignment of software bugs: a systematic literature
                  mapping study
  Abstract. Managing the assignment of bug report to related team or related
  developer is challenging and time consuming issue in large-scale software
  projects. In order to reduce the assignment time and to increase success of
  right decision making automated bug assignment approaches presented. To
  support automated decision making on bug assignment, researchers and prac-
  titioners propound various methods, tools and processes. Number of academic
  and technical sources have increased and this has brought the need to systema-
  tically categorize the current studies and practices and to provide an overview.
  In order to give an overview of current studies, we performed a systematic




                                                                                       466
       mapping study in the area of bug assignment. We searched the academic lite-
       rature using several search engines (e.g., Scopus, and Google Scholar). The
       SM and its results are based on 93 primary studies, which were published so-
       urces like conferences (45), journals (24), symposiums (12), workshops (4)
       and theses (3) and others (5). As a result, approximately 46% of the primary
       syudies are emprical studies, and 40% used Bayesian statistics as machine le-
       arning method.

       Keywords: Bug; Bug assignment; Systematic mapping; Systematic li-
       terature mapping


1      Giriş

Değişim ve hata izleme sistemleri, yazılım projelerini yönetmek için vazgeçilmez
unsurlardır. Hata izleme sistemleri, problem raporları ve gözlenen başarısızlıklarla
ilgili ayrıntılı açıklamalara sahip olan hata raporlarını saklar. Projelerin her aşamasın-
da, bildirilen hataların büyüklüğü doğal olarak artmaktadır. Hata raporlarının sayısın-
daki artışla başa çıkabilmek için her bir hata raporu analiz edilmelidir. Hata atama
(triaging), hata durumunun belirlenmesi, hata önceliğinin belirlenmesi, yeni bildirilen
bir hatanın daha önce rapor edilip edilmediğinin belirlenmesi, hata raporunun uygun
takıma veya geliştiriciye atanması gibi çeşitli adımları içerir. Hata ayıklama odaklı
sorunlarından biri de hata atamasıdır. Bildirilen hatayı çözmek için hata dağıtıcısı
(triager) bu hata için en uygun geliştiriciye karar vermelidir. Hatayı uygun geliştirici-
ye (özellikle proje yöneticisi veya ekip lideri) atamaktan sorumlu kişi (bug triager),
geliştiricilerin uzmanlık seviyesi, geliştiricilerin mevcut iş yükü ve geliştiricinin üret-
kenliği hakkında bilgi sahibi olması nedeniyle manuel karar verme sürecinde çok
zaman harcamaktadır. Bu atama kararları, proje takviminde önemli bir role sahiptir.
Çünkü atama saatler veya günler sürebilir (zaman alıcı görev) ve yeni hatalara neden
olan yanlış kararlarla veya atama (yeniden atama işlemi) olayıyla sonlanabilir. Ma-
nuel hata atamasının çeşitli sebeplere dayanmasından dolayı araştırmacılar, hataların
hangi geliştiricilere atanması gerektiği konusunda yarı ve tam otomatik yaklaşımlara
odaklanmışlardır. Bununla beraber, birçok araştırmacı ve uygulayıcı hata atama süre-
cindeki zorlukları analiz etmiş ve bu alanda çeşitli yöntem, teknik, araç ve ölçütler
önermişlerdir.
    Bu çalışmada, hata atama konusuyla ilgili güncel çalışmaların sistematik olarak sı-
nıflandırılması ve haritalandırılması ile ilgili genel bir bakış açısı yakalamaya çalış-
maktayız. Çalışmalarımızın katkısı şöyledir: Hataların atanması konusunda çevrimiçi
makale deposunda var olan birincil çalışmaları sistematik haritalama. Bu çalışmanın
geri kalan kısmı ise aşağıdaki şekilde düzenlenmiştir. Bölüm 2’de, hata raporu ve hata
ataması hakkında kısa bir özet verilmiştir. Bölüm 3, genel sistematik haritalama (SH)
süreci, bu çalışmada izlenen hedef ve araştırma soruları da dâhil olmak üzere araştır-
ma yöntemimizi tanımlamaktadır. Bölüm 4 ile makale seçim sürecini tartışmaktayız.
5. bölüm, haritanın yinelemeli gelişimini analiz etmektedir. Sistematik haritalamanın
sonuçları Bölüm 6’da sunulmaktadır. Bölüm 7 ile SH sonuçlarının araştırmacılar ve
uygulayıcılar üzerindeki etkileri özetlenip çalışmamızın geçerliliğini tehdit edecek




                                                                                              467
olası unsurlar tartışılmaktadır. Son olarak, Bölüm 8, bu haritalamanın sonuçlarını ve
gelecekte yapılması planlanan çalışmaları belirtir.


2      Alan özeti ve ilgili çalışmalar

Yazılım projelerinde, eğer sistem beklenmedik sonuçlar veriyorsa veya yanlış davra-
nış gösteriyorsa, bu uygunsuzluğun nedeni hata olarak adlandırılır. Bu hatayı bulan
kişi (test mühendisi gibi) hatanın çözümleyicisi (geliştirici gibi) hakkında bilgi verme-
lidir. Bu bilgi değişiminin resmi yolu hatayı hata raporuyla belgelemektir. Geliştirici-
lere hata hakkında ayrıntılı bilgi vermek için, hata raporlarının önceden tanımlanmış
birtakım alanları olmalıdır. Örneğin, bazı hatalar önemsizdir ve kullanıcının etkinliği-
ni bloke etmemektedir; bu nedenle bu hatalar derhal çözülmesi gereken önceliğe sahip
olmamalıdır (öncelik) veya kullanıcının her eyleminden sonra bazı hatalar sık sık
tekrar ederken bazı hatalarla karşılaşma olasılığı daha düşüktür (ağırlık). Hata raporu-
nun bir diğer alanı da hatanın o anki durumunu gösteren durum alanıdır. Örneğin, bir
hata ilk rapor edildiğinde, hata atayıcısı (bug triager) hatanın varlığını ve benzersizli-
ğini doğrulamadıkça, bu hata UNCONFIRMED (onaylanmamış-doğrulanmamış)
olarak işaretlenir. Eğer hata atayıcısı tarafından hatanın varlığı onaylanırsa, rapor
YENİ olarak işaretlenecektir. Daha sonra bu yeni rapor, ağırlık(severity), önce-
lik(priority), ürün (product) ya da serbest bırakma (release) olarak sınıflandırılır. Hata
atayıcısı bu hatayı kimin düzeltmesi gerektiğine karar verirken, raporun durumu
ASSIGNED (atanmış) olarak değiştirilir. Bir hatanın geliştirici tarafından Çözülmüş
(Resolved), Doğrulanmış (Verified) ya da Kapanmış (Closed) olarak işaretlenmesi,
hatanın birtakım çözümlere sahip olduğunu gösterir. En olası çözüm türleri arasında
Onarılmış (Fixed), Kopya (Duplicate), Worksforme (Hata tekrarlanamadı), Geçersiz
(Invalid) türleri yer almaktadır. [1]
   Büyük sayıdaki hata raporlarını toplamak, düzenlemek ve analiz etmek için hata iz-
leme sistemleri kullanılır. En popüler hata izleme sistemlerinden biri 1998'de piyasaya
sürülen Bugzilla'dır. Bugzilla'da sadece Firefox hataları değil, aynı zamanda Eclipse
ve diğer açık kaynak projelerinin hatalarını içeren çok sayıda hata raporu bulunmak-
tadır. Birçok araştırmacının Bugzilla’yı çalışmalarında kullanmasının nedeni, Bugzil-
la’nın açık kaynak erişiminin olması ve çok sayıda projeyi içermesidir. Bugzilla’da
çeşitli hata raporları ve bu hata raporlarında hatalarla ilgili çeşitli tanımlamalar mev-
cuttur. Bu hataların kime atanacağı konusunda hata atayıcısının nasıl karar vereceği
önemli konulardan biridir. Hata raporlarının bir geliştiriciye atanması için hata hak-
kında ve geliştiriciler hakkında bilgi sahibi olunması gerekmektedir. Hata raporunun
projenin hangi takımıyla ilgili olduğu değerlendirildikten sonra geliştiricilerin iş yükü,
bilgi birikimi, deneyimi vb. birçok faktör göz önüne alınarak hata atamasının yapıl-
ması gerekmektedir. Bu işlemin elle yapılması hata raporlarının sayıca az olduğu
projelerde mümkündür ancak proje büyüklüğü ve hata raporu sayısı arttıkça bu işlem
çok zaman alan, hatalı atama yapmaya eğimli ve yönetilemez hal almaya başlayabilir.
Bunun için hata atama işleminin manuel olarak değil otomatik olarak yapılması ge-
rekliliği doğmuştur. Bunun için çeşitli araştırmacılar makine öğrenmesi, metin ma-




                                                                                             468
denciliği vb. teknikleri kullanarak hata ataması işlemini otomatikleştirmeyi ve hata
atama işleminde yapılan hataları en aza indirmeyi amaçlamışlardır.

3      Araştırma yöntemi

Bu bölümde araştırma yöntemine genel bir bakış, amaç ve haritalama soruları ele
alınmaktadır.

3.1    Amaç ve haritalama soruları
Bu araştırmada kullanılan araştırma yaklaşımı Hedef-Soru-Metrik (Goal-Question-
Metric (GQM)) metodolojisidir. Bu çalışmanın amacı, zorlukları gidermek ve araş-
tırmacılar ve uygulayıcıların perspektiflerinden gelecekteki araştırmalar için alterna-
tifleri belirlemektir. Bunun için bu alandaki mevcut yaklaşımları ve eğilimleri bulmak
amacıyla hata atama konusundaki literatür sistematik olarak haritalanmış ve gözden
geçirilmiştir. Bu amaca dayalı olarak aşağıdaki haritalama soruları (HS) oluşturul-
muştur:

• HS1: Çalışmaların araştırmaya katkı tipleri: Hata atama konusundaki makalelerden
  kaç tanesi metot/yöntem, teknik, araç, metrik vb. sunmaktadır? Peterson'un yazılım
  mühendisliği sistematik haritalama araştırmalarına göre, katkı tipi yaygın olarak
  kullanılan bir uygulamadır. Bu sorunun cevabını vermek, hata tayininde mevcut
  araştırmaların odaklandığı alanın eğilimini anlamamıza yardımcı olacaktır. (Yeni
  teknik, yeni araç, yeni metrik vb. üzerine odaklanılmıştır.)
• HS2: Araştırma yöntemi tipleri: Makalelerde hangi araştırma tipleri kullanılmıştır?
  Peterson ve ark. [2] ayrıca çalışmaların araştırma yaklaşımlarını sınıflandırmak için
  kılavuz ilkeler getirmiş ve bu ilkeler bu soruya cevap bulmak için kullanılmıştır.
  HS 2’yi cevaplamak için birincil çalışmalar 7 farklı araştırma yöntemine göre, her
  çalışma sadece bir araştırma yöntemi türüne dâhil olacak şekilde sınıflandırılmıştır.
• HS3: Makine öğrenme yöntemi tipleri: Hata atama konusundaki makalelerde hangi
  öğrenme yöntemleri kullanılmıştır? Bu sorunun cevabı, hata tayininde kullanılan
  mevcut öğrenme ve sınıflandırma algoritmalarının eğilimini anlamaya yardımcı
  olacaktır.
• HS4: Teste tabi tutulan projelerin isim ve sayıları: Test edilen sistemde kullanılan
  projelerin isim ve sayıları nelerdir? Bu sorunun cevabı, hata tayininde hedeflenen
  katkıyı gerçekleştirebilmek için kullanılan projelerin isim ve sayıları ile ilgili ista-
  tistik sunacaktır.
3.2    Sürece genel bir bakış
Önceki bölümlerde bahsedildiği üzere, bu sistematik haritalandırma çalışması Peter-
son ve arkadaşları [2, 3] tarafından sağlanan kılavuzlara dayalı olarak yürütülmekte-
dir. Bu SH için metodolojiyi tasarlarken, [4] gibi çeşitli SH’lardan yöntemler de dâhil
edilmiştir. Bu SH in temelinde yatan süreç Şekil 1'de özetlenmekte olup, bu süreç üç
aşamadan oluşmaktadır:
• Makale seçimi (Bölüm 4)




                                                                                             469
• Sistematik haritalamanın gelişimi (Bölüm 5)
• Sistematik haritalamanın sonuçları (Bölüm 6)




               Şekil 1. Sistematik haritalama çalışmasında kullanılan protokol

4      Makale seçimi
Sistematik haritalama çalışmamızın ilk aşaması makale seçimi aşamasıdır. Bu aşama-
da aşağıdaki adımlar sırasıyla uygulanmıştır:

• Kaynak seçimi ve anahtar kelimeleri arama (Bölüm 4.1)
• Dâhil etme/Hariç tutma kriterleri (Bölüm 4.2)
• Makale havuzunun tamamlanması (Bölüm 4.3)
4.1    Kaynak seçimi ve arama anahtarları
Peterson'un sistematik haritalama kurallarına [2, 3] dayanarak, ilgili çalışmaları bul-
mak için aşağıdaki yedi büyük dijital kütüphane araştırılmıştır: (1) IEEE Xplore, (2)
ACM Digital Library, (3) Compendex, (4) Science Direct, (5) Scopus, and (6) Sprin-
ger (7) Google Scholar. Aramalara “bug assignment” arama anahtarı ile başlandı.
Araştırmacılardan biri 1., 2. ve 3. veritabanlarında aramayı gerçekleştirirken, diğer
araştırmacı 4., 5., 6. Ve 7. veritabanlarında arama gerçekleştirdi. Bu arama sonucun-
da başlangıç havuzumuzda toplamda 172 makale elde ettik. Bu işlemden sonra iki
araştırmacı elde ettikleri makaleleri birleştirildi ve benzer makaleler havuzdan çıkarıl-
dı. Bu işlem sonucunda 116 birincil makale elde edildi. Bu anahtar kelimeyle elde
edilen makalelerin araştırılıp ilgili makalelerin özet ve giriş bölümleri incelendikten




                                                                                            470
sonra yeni bir arama anahtarı olarak “bug triaging” arama anahtarı çıkarıldı. Yinele-
meli ve tekrarlı bir işlemden sonra bu yeni arama anahtarı ile 115 farklı birincil çalış-
ma elde edildi. Bu 115 makale sadece Google Scholar veritabanında yapılan arama ile
elde edilmiştir. Final havuzumuzda son olarak 231 birincil çalışma elde edildi. Olası
makalelerin gözden kaçmasına engel olabilmek amacıyla son olarak bug and {(assign
or assignment) or (triage or triaging)} arama anahtarı ile yeni bir arama gerçekleştiril-
di. Buna ek olarak, ilgili çalışmaların gözden kaçma riskini azaltabilmek amacıyla
incelenen makalelerin referans verdiği bazı makaleler manüel olarak aratıldı. Makale
havuzunda olmayıp da konuyla ilgili olmaya aday makaleler de havuza dâhil edildi.
4.2    Dâhil etme/hariç tutma kriterleri
Bu çalışmada göz önünde bulundurulan dâhil etme kriterleri şunlardır: (1) Her çalış-
manın konusunun hata atama bağlamıyla ilgisi, (2) Çalışmada takip edilen kapsamlı-
lık ve değerlendirme ve geçerlilik düzeyi. Yalnızca İngilizce olarak yazılan ve yalnız-
ca elektronik olarak erişilebilen çalışmalar dâhil edilmiştir. Kapsamla ilgili ancak
geçerli kanıta sahip olmayan makaleler hariç tutuldu. Kapsamla ilişkili ancak içeriği-
ne ücretsiz olarak erişilemeyen makaleler de hariç tutulmuştur.
    İlk havuza dâhil etme / dışlama kriterlerini uygulamak için, makalenin yazarları ilk
havuzdaki çalışmaları değerlendirerek her çalışmaya “1” ve “0” olarak oy vermiştir;
"1", bir çalışmanın dâhil edilmesi yönünde bir görüş belirttiğini, "0" ise çalışmanın
hariç tutulması yönünde bir görüş belirttiğini gösterir. İncelenen makalenin dışlanma-
sına ilişkin karar için 3 puanlık bir eşik kullanmaya karar verilmiştir, i.e. toplamdaki
oylarla 3 puanın altındaki araştırmalar hariç tutulmuştur. Her bir çalışmayı oylamak
için makalenin başlığı, özeti ve anahtar kelimeleri gözden geçirilmiştir. Bu kaynaklar-
la yeterli bilgi bulunamazsa, daha derinlemesine bir değerlendirme gerçekleştirilmiş-
tir. İki araştırmacının yapmış olduğu ortak oylama sonucunda, son havuz 231’den
93’e düşürülmüştür.
4.3    Son makale havuzu ve online depo
Okuyucular 93 birincil çalışmanın tam referans listesi için e-tabloya
(https://goo.gl/AgrL6m) başvurabilirler. Seçilen çalışmaların son havuzu, Google
Dokümanlar sistemini kullanarak çevrimiçi bir depoda yayınlanmıştır. Seçilen her
yayının Bölüm 5'de tanımlanan sınıflandırma şemasına göre sınıflandırılması çevri-
miçi depoda da mevcuttur.
   Hata atamasının yıllık yayın hacmi Şek.2'de gösterilmektedir. Yayın aralığının baş-
lama yılı açısından, hata atama makalelerinin 2004 yılında ortaya çıkmaya başladığı
ve 2016 yılına kadar bu kapsamda artan bir çalışma yoğunluğu olduğu görülmektedir.
2016 yılında hata atamayla ilgili 17 makale yayınlanmıştır.




                                                                                            471
                         Şekil 2. Yıllara göre makalelerin dağılımı

5      Sistematik haritanın geliştirilmesi (sınıflandırma şeması)
Tablo 1, yukarıda açıklanan işlemlerin uygulandıktan sonra geliştirilen nihai sınıflan-
dırma şemasını göstermektedir. Tabloda, sütun 1, HS listesidir, sütun 2, ilgili öznitelik
/ özelliktir. Sütun 3, özellik için olası tüm değerler kümesidir. Son olarak, sütun 4,
birden fazla seçimin uygulanıp uygulanamayacağı konusunda bir öznitelik belirtir.
Örneğin, RQ 1 (Katkı tipi) için, son sütundaki ilgili değer 'Ç' (Çoklu) 'dur. Bir çalış-
manın birden fazla seçenek türüne (ör. Yöntem, araç vb.) katkıda bulunabileceğini
belirtir.

                    Tablo 1. Çalışmada geliştirip kullanılan sistematik harita

 HS    Öznitelik / Özellik     Kategoriler                                       (Ç)oklu/
                                                                                 (T)ekil
 1     Katkı tipi         {Metot (teknik), Tool, Metrik, Model, Süreç,           Ç
                          Deneysel çalışma, diğer}
 2     Araştırma türü     {Çözüm önerisi, Doğrulama Araştırması, Değer-          T
                          lendirme Araştırması, Deneyim çalışması,
                          Felsefe Araştırmaları, Görüş Çalışmaları, diğer}
 3     Makine     öğrenme {Sinir Ağları, Kümeleme (kNN etc.), Bayes              Ç
       metodu             (NaïveBayes vb.), Karar Ağaçları, Genetik Algo-
       türleri            ritmalar, Destek vektör makinaları}


6      Sonuçlar

Bu bölümde sistematik haritalama çalışmasında sorulan haritalama soruları kapsa-
mında elde edilen sonuçlardan bahsedilmektedir.




                                                                                            472
6.1    HS1-Çalışmaların araştırmaya katkı tipleri
Birinci araştırma sorusunun amacı, kaç tane makalenin hata atama yöntemi / teknikle-
ri, araçları, modelleri, metrikleri ve süreçleri ile literatüre katkı sunduğunu bulmaktır.
Bu katkı türleri belirlenirken Petersen ve arkadaşlarının önerdiği katkı türlerinden
yararlanılmıştır. Çalışmaya dâhil olan tüm 93 makale için Şekil 3, araştırmaların katkı
türünün dağılımını göstermektedir.
    Şek.3 çok sayıda makalenin deneysel (vaka) çalışma önerdiğini göstermektedir.
(86 makale). Ayrıca 84 makalenin yeni metot / tekniklerle katkıda bulunduğu veya
var olan bir tekniği / metodu geliştirdiği tespit edilmiştir. Yeni bir model sunan 29
makale, metrik ile katkıda bulunan 18 makale, yeni araç ile katkıda bulunan 14 maka-
le ve yeni bir sürece odaklanan 3 makale tespit edilmiştir. Katkılarına göre bir makale
birden fazla sınıflandırmaya dâhil olabilmektedir. Örneğin birincil çalışmaların bu-
lunduğu çevrimiçi referans listesinden erişim sağlanabilen makalelerden “A Hybrid
Bug Triage Algorithm for Developer Recommendation” makalesinde ‘activity factor’
adında yeni bir metrik ortaya çıkarılırken bu metrik kullanılarak makalede yeni
bir modele katkıda bulunulmuştur. “Automated Change Request Triage using Alpha
Frequency Matrix” makalesinde yeni bir hata raporu için uygun geliştiriciyi önermek
üzere ‘alphabet frequency matrix’ (AFM) adında yeni bir teknik geliştirilmiştir.
“Cost-aware triage ranking algorithms for bug reporting systems” makalesin-
de‘costriage’ adında yeni bir araç (tool) önerilmiştir. “Automated Bug Triaging in an
Industrial Context” makalesinde hata izleme verilerden tahmini sonuçlara doğru yeni
bir veri analiz süreci (process) geliştirmişlerdir.




                                  Şekil 3. Katkı Tipleri


6.2    HS2-Araştırma yöntemi tipleri

Bu araştırma sorusu ile makalelerde ne tür araştırma yöntemleri kullanıldığının tespit
edilmesi amaçlanmıştır. Şek.4, araştırma tipi yönünden makalelerin dağılımını gös-
termektedir.




                                                                                             473
   Haritalama çalışmasına dâhil edilen 93 bildirinin bulunduğu havuzda, Şek. 4, en
fazla kullanılan araştırma yönteminin güçlü deneysel (vaka) çalışma olduğunu gös-
termektedir. Sonuçlar, 46 makalenin araştırma soruları veya hipotez kullandığını ve
ayrıca bu bildirilerde geçerliliğe tehdit oluşturan unsurların belirtildiğini göstermekte-
dir. Ancak, hiçbir araştırma sorusu olmamasına rağmen, geniş bir vaka çalışması ya-
pan ve geçerliliğe yönelik tehdit unsurları belirtilmiş makaleleri güçlü deneysel (vaka)
çalışması olarak kategorize edilmiştir. Hiçbir hipotez veya araştırma sorusu bulunma-
yan makaleler zayıf deneysel çalışma (42 makale) olarak sınıflandırılmıştır. Sadece
bir makale çözüm önerisi araştırma yöntemine dâhil olurken, bir makale deneyimsel
araştırma yöntemine dâhil edilmiştir. 'Diğer' kategorisinde, herhangi bir araştırma
metodu içermeyen makaleler sınıflandırılmış ve bu kategoriye yalnızca bir adet araş-
tırma anketi dâhil edilmiştir.




                           Şekil 4. Araştırma Yöntemi Tipleri


6.3    HS3- Makine öğrenme yöntemi tipleri

Hata atama makalelerinde hangi öğrenme yöntemlerinin kullanıldığını incelemek için,
makaleler öğrenme tekniklerine göre sınıflandırılmıştır. Şek 5, incelenen 93 makale-
nin tamamında kullanılan öğrenme tiplerinin dağılımını göstermektedir.




                           Şekil 5. Öğrenme Yöntemi Tipleri




                                                                                             474
38 makalede öğrenme yöntemi olarak Bayes istatistikleri kullanılmıştır. En çok kulla-
nılan ikinci öğrenme metodu ise 29 makale ile destek vektör makinesi (SVM) 'dır.
Ayrıca, 19 makalenin C4.5, J48, vb. gibi karar ağacı yöntemlerini kullandığı gözlem-
lenmiştir. Makalelerin çoğunda karşılaştırma amaçlı olarak birden fazla öğrenme
yöntemi kullanılmıştır. Örneğin, “A Decision Support Platform for Guiding a Bug
Triager for Resolver Recommendation Using Textual and Non-Textual Features”
makalesinde iki öğrenme yöntemi kullanılmıştır. Sonuç olarak otomatik hata atama
görevi için karar ağacı ve Naive Bayes tekniklerinin en çok kullanılan yöntemler ol-
duğu tespit edilmiştir.
6.4    HS4- Teste tabi tutulan projelerin isim ve sayıları
Şek. 6, test edilen sistemlerde kullanılan her projenin sayısını göstermektedir. Yapı-
lan analizlere göre, deneylerde en çok kullanılan projenin Eclipse olduğu görülmüş-
tür. 54 makale Eclipse'i kullanırken, çalışmalarında Mozilla Firefox kullanan 46
makale vardır. Diğer projeler aşağıda gösterilmiştir: NetBeans, Apache, GCC,
GitHub vb.




                          Şekil 6. Test edilen projelerin dağılımı

7      Geçerliliği tehdit eden unsurlar
Çalışmayı yapan araştırmacılar, seçilen veri tabanları, oluşturulan arama anahtar ke-
limeleri, seçilen zaman kısıtlamaları ve birincil çalışmaların havuzu gibi farklı faktör-
ler, sistematik haritalama araştırmasının sonuçlarını etkileyebilmektedir.
   İçsel Geçerlilik: Bu çalışma kapsamında olabildiğince eksiksiz bir birincil çalış-
ma havuzu oluşturulmaya çalışılmış, farklı anahtar sözcükler ve bunların birleşimi
ile bir araştırma sözcük kümesi belirlenip ilgili çalışmalar toplanmıştır. Dâhil etme
ve hariç tutma kriterleri belirlenmiştir. Araştırmacıların kişisel değerlendirmelerinin
etkilerini minimize etmek amacıyla çalışmayı yürüten araştırmacılar ile oylama
mekanizması kullanılmıştır; bağımsız çalışan ve belirli günlerde incelemelerin üze-
rinden ortak gözden geçirme yapan iki araştırmacı tarafından ilgili makalelerin se-
çimi gerçekleştirilmiştir. Bazı ilgili makalelerin araştırmacılar tarafından farklı oy-
lanması sonucunda dahil edilmemeleri mümkün olabilmektedir. Bununla birlikte,




                                                                                            475
incelemelerin sonuçları, her iki araştırmacının da yüksek düzeyde bir mutabakata
sahip olduklarını göstermektedir.
   Dışsal Geçerlilik: Bir çalışmanın sonuçlarının ne ölçüde genelleştirilebileceği ile
ilgilenir. Sistematik haritalama çalışmasının sonuçları, hata atama alanı kapsamında
ve yazılım mühendisliği perspektifine göre değerlendirilmiştir. Bu nedenle, sunulan
hariç tutma yöntemlerinin, verilerin ve çizelgelerin sonuçlarının yalnızca verilen
bağlamda (hata ataması) geçerli olduğu düşünülmelidir. Bu sonuçlar, bu alandaki
araştırmacılar ve uygulayıcılar için bir başlangıç noktası oluşturabilir.

8      Sonuçlar
Bu makalede hata atama alanını karakterize etmek için sistematik bir haritalama ça-
lışması yapılmıştır. Toplam 231 birincil çalışma analiz edilmiş ve dâhil etme ve hariç
tutma kriterleriyle filtrelendikten sonra son havuzda 93 makale kalmıştır. Ardından,
çalışma kapsamı çerçevesinde araştırma soruları oluşturulmuştur. Araştırma soruları-
na cevap olarak, sorularla ilişkili çizelgeler analiz edilmiştir. Makalelerin çoğunun
vaka analizlerinde akademiden katkı sağlayan kişiler olduğu ve bu makalelerde ge-
nelde açık kaynak projelerin kullanıldığı görülmüştür. Ayrıca, Eclipse ve Mozilla
Firefox’un, test edilen sistemde en çok kullanılan projeler olduğu gözlenmiştir. Hata
atama yaklaşımlarını analiz etmek için birçok farklı teknik kullanılmıştır. Sonuç ola-
rak makine öğrenme tekniklerinden SVM ve Naive bayes in en çok kullanılan öğren-
me metotları olduğu görülmüştür. Elde edilen bulgulara göre, 2004 yılından 2016
yılına kadar, hata ataması konusunda kayda değer bir eğilim olduğu görülmüştür.
   Gelecekteki çalışmalar olarak, bu çalışmaya dayanarak, bu çalışmayı farklı açılar-
dan genişleterek hata ataması alanında bir sistematik literatür değerlendirme (Syste-
matic Literature Review, SLR) çalışması yapmak planlanmaktadır.


9      Referanslar
 1. Laplante, P., Ahmad, N.: Pavlov's Bugs: Matching Repair Policies with Rewards. IT Pro-
    fessional. 11, 45-51 (2009).
 2. Petersen, K., Feldt, R., Mujtaba, S., & Mattsson, M.: Systematic Mapping Studies in Soft-
    ware Engineering. EASE . 8, 68-77 (2008).
 3. B. Kitchenham, S. Charters.: Guidelines for performing Systematic Literature Reviews in
    Software Engineering . EBSE. (2007).
 4. Amannejad, Y., Garousi,V., et al.: A Search-Based Approach for Cost-Effective Software
    Test Automation Decision Support and an Industrial Case Study. 2014 IEEE Seventh In-
    ternational Conference on Software Testing, Verification and Validation Workshops. 302-
    311 (2014).




                                                                                                476