Mimari borç tanılama için yöntemler: Bir sistematik eşleme çalışması

Mimari Borç Tanılama için Yöntemler: Bir

Sistematik Eşleme Çalışması

Methods for Identifying Architectural Debt: A

Systematic Mapping Study

Yagup Macit HAVELSAN Ankara, Türkiye ymacit@havelsan.com.tr 0000-0001-9159-9423 Görkem Giray Bağımsız Araştırmacı İzmir, Türkiye gorkemgiray@gmail.com 0000-0002-7023-9469 Eray Tüzün Bilkent Üniversitesi Ankara, Türkiye eraytuzun@cs.bilkent.edu.tr 0000-0002-5550-7816

Özet— Teknik borç genel olarak, yazılım profesyonellerinin,

yazılım geliştirme sırasında kısa vadeli hedeflere ulaşmak için uzun vadeli gelecek pahasına aldığı kararları ifade eder. Mimari teknik borç, yazılım uygulayıcılarının yazılımın mimarisiyle ilgili yanlış veya ödün vererek kararlar almaları ile oluşan, teknik borçların bir alt kümesidir. Bu tür mimari teknik borçların belirlenmesi, yazılım geliştirmenin kalitesinde önemli rol oynamaktadır. Son on yılda, literatürde mimari borçları tanımlamak için birçok yöntemler önerilmiştir.

Bu çalışmada, 2011-2020 yılları arasında yayımlanan 28 temel çalışmayı inceleyerek mimari teknik borçları tespit eden yöntemlerin sistematik bir eşleme çalışması gerçekleştirdik. İncelememizin sonuçlarına göre: (1) tasarım kuralı alanı ve izlenebilirlik grafikleri baskın tekniklerdir; (2) mimari borcun tanımlanmasındaki otomatik tekniklerin artışına rağmen, uzman görüşünü kullanan manuel yöntemler hala popülerdir; (3) yaklaşımların çoğu mimari teknik borcu tespit etmek için kod/sürüm tarihçesini kullanmaktadır; (4) bu alan son beş senede giderek daha fazla ilgi çekmektedir.

Anahtar Kelimeler— mimari borç, mimari ögeler, teknik borç, sistematik eşleme çalışması

Abstract— Technical debt in general refers to suboptimal

decisions the practitioners make during software development that achieve short-term goals at the expense of long-term quality concerns. Architecture technical debt is a subset of technical debt, when software practitioners make wrong or sub-optimal decisions related to the architecture of the software. Identifying such architecture technical debt plays a crucial role in software quality. In the last decade, there were several methods proposed to identify architecture debts in the literature.

In this study, we conduct a systematic literature review of methods that identify architecture technical debt by inspecting 28 primary studies published from 2011 to 2020. Based on the outcomes of our review: (1) design rule space and traceability graphs are the dominant techniques; (2) despite the increase of automated techniques in identifying architecture debt, pure manual methods using expert opinion is still popular; (3) majority of the approaches use code/version history to mine archictural technical debt; (4) the field is getting increasingly more attraction in the last five years.

Keywords—architectural debt, architectural components, technical debt, systematic mapping study

I. GİRİŞ

Bugün, yarının dünüdür ve her şey eskir. Bu yaklaşım en çok da yazılım uygulamaları için geçerlidir. Bugün yazılan yeni uygulamalar, yarın kalıt olarak değerlendirilir. Yeni geliştirilen uygulamaları tehdit eden iki zaman durağı vardır. Birinci durak, bugün gerekli olan özellikleri taşımaktır. İkinci durak ise yarının gereklerini karşılayabilecek esneklik ve dayanaıma sahip olmaktır.

Bugünün gereklerini karşılamaya çalışan yazılım uygulamaları, analizden kabule kadar olan yabancılaşma riskleri ve değişen gerekleri yanıtlayabilecek bir potansiyele/birikime sahip olmalıdır. Kabul işleminin sonuna kadar, yabancılaşmaların giderilmesi ve değişikliklerin yansıtılması, birikim üzerinden karşılanmak zorundadır.

Her şey gibi, yazılımlar da yaşam döngüsü içerisinde yaşlanır ve ölür. Kullanıcı açısından bakıldığında, bir yazılım ürününün uzun süreli gereklere kabul edilebilir ek yatırımlar ile yanıt vermesi beklenir. Yazılımın bu yanıtı verebilmesi zamana ve değişen gereklere dayanabilecek sağlam, esnek ve gelişebilen bir mimari ile olanaklıdır.

Yazılımların, hata düzenlemelerine ve yeni özellik kazanımlarına yanıt vermesi her zaman kolay olmamaktadır. Zorluğun en önemli nedeni biriken teknik borçlar olarak görülmektedir [1]. Yazılımın mimarisine yönelik ilke ve kuralların ihlali ile ortaya çıkan borçlar, teknik borcun mimari boyutunu oluşturmaktadır [2][3]. Bu çalışmada, mimari borcun hangi kaynaklar değerlendirilerek nasıl tanılandığını sistematik haritalama yöntemi kullanılarak araştırılmıştır.

Çalışmanın ikinci bölümünde, teknik ve mimari borç ile ilgili çalışmalar, üçüncü bölümde araştırma yönetimi, dördüncü bölümde elde edilen bulgular, son bölümde ise sonuçlar ve gelecek çalışmalar anlatılmaktadır.

II. ARKA PLAN VE İLGİLİ ÇALIŞMALAR A. Teknik ve Mimari Borç

Dünyayı, çocuklardan ödünç aldık derken çevrenin kötü kullanımı nedeniyle çocuklarımıza borçlu olduğumuzu ve onlara sürdürülebilir bir çevre bırakmamız gerektiğini, anlatmaya çalışırız. Ödünç alma kavramı, borçlanma ve geri ödeme eyleminin bilinçli ve açık olduğunu yani kazara olmadığını tanımlar. Finans dünyasına ait olan borç kavramı, bugünün ihtiyacı için geleceğinin bir bölümünün ödünç alınması yani ipotek ettirilmesi şeklinde değerlendirebilir.

Yazılım endüstrisi, tasarım ve kodlama konuları için tıpkı finans sektöründe olduğu gibi borçlar oluştuğunu açıklamış ve “teknik borç” metaforu ortaya çıkmıştır [1].

Teknik borca, tekrarlı kod parçaları örnek olarak gösterilebilir. Yazılım geliştiricileri yeni bir özellik geliştirirken çoğu zaman takvim baskısı ile özellikleri benzer bir modülden başka bir modülden kopyala/yapıştır ile geliştirme yapabilir. Böyle bir durumda kopyala/yapıştır yapıldığı anda proje için geçici bir zaman kazancı gerçekleşmiş olmasına karşı, bu işlemin sonucu ortaya çıkan tekrarlı kod parçaları ürünün ilerleyen yaşamında, bu kodun bakımı için tekrarlı bakım çalışmalar gerektireceği için teknik borç olarak geri dönecektir.

Çevik yazılım geliştirme ile birlikte teknik borcun kasıtlı ve kasıtsız ortaya çıkabileceği değerlendirilmiştir [4]. Ancak, bilinçli bir karar almadan, sorumsuz ve dağınık bir çalışma ile ortaya çıkan durumun teknik borç olmayacağı ve geri ödenemeyeceği vurgulanmıştır [5]. Teknik borç metaforu ile birlikte yazılım geliştirme faaliyetlerinde ortaya çıkan bilinçli, bilinçsiz hata ve eksiklerin değerlendirilmesi ve haritalaması yapılarak Şekil 1’de görülen teknik borç kadranı üretilmiştir [6]. Teknik borç kadranı; dağınıklığı, bilinci ve ödünç alma kavramını harita üzerine açık olarak yerleştirmiştir.

“Yazılımı şimdi teslim etmek zorundayız ve bunun sonuçlarıyla başa çıkmalıyız” “Tasarım için zamanımız yok” “Şimdi nasıl yapmış olmamız gerektiğini biliyoruz” “Katmanlama nedir?” Umursamaz Öngörülü Ka sı tl ı Ka sı ts ız

Şekil 1. Teknik borç kadranı [6]

Borç kadranı; çevik yazılım geliştirme için kullanılan iş yığını (backlog) yönetimi açısından zemin olarak kullanılmış ve teknik borç ile ilgili iş yığını maddelerinin Şekil 2’deki gibi sınıflandırılması önerilmiştir [7]. Böylece, mimarinin düzenlenmesine ve kodun yeniden yapılandırılmasına dönük iş yığını ögeleri açık bir şekilde planlamaya dahil edilmiştir.

Mimari, yapısal özellikler Yeni özellikler Eklenen işlevler Teknik borç Hatalar Görünür Görünmez Po zi ti f De ğer Ne g at if De ğer

Şekil 2 Teknik borç iş yığını maddelerinin türleri [7]

Farkındalık ve bilinçli alınan kararlar sonucunda ortaya çıkan borçlar daha çok mimari borç olarak değerlendirilirken farkında olmadan veya dağınıklık sonucu ortaya çıkan durum daha çok kod bozulması şeklinde değerlendirilmektedir. Mimarinin, teknik borçların oluşmasını engelleyen ve geri ödemeyi kolaylaştıran bir öncül olduğu hipotezi, henüz kanıtlanamayan hipotez olarak varlığını sürdürmektedir [8].

B. İlgili Çalışmalar

Yazılım mühendiliği alanındaki kanıta dayalı çalışmalar sağlık alanından devşirilerek geliştirilmiştir [9]. Yazılım mühendisliği alanında yapılan sistematik eşelem çalışmaları, genel bir çerçeve oluşturulması için kanıta dayalı yaklaşım ile ortak bir çatı altında toplanarak özetlenmiştir [10]. Bu özetleme sonucu ortaya çıkan yöntem, Sistematik Eşleme Çalışması (Systematic Mapping Study - SMS) ve Sistematik Literatür Taraması (Systematic Literature Review- SLR) için kanıta dayalı etkinlik sağlamaktadır. Önerilen yöntem ile, çalıştığı konuda yeni bir gelişme sağlayan veya farklılık yaratan yayınlar birincil çalışma olarak toplanmakta ve bu çalışmalardan elde edilen kanıtlar çözümlenerek raporlanmaktadır.

Teknik borçlar için 2015 yılında yapılan sistematik eşleme çalışması ile 47 adet yayın incelenmiş ve borçların; yıllarına, araştırma çevrelerine, etkinlik alanları ve borç türlerine göre dağılımları gösterilmiştir [11]. Teknik borçların, maliyet etkileri ve paydaşlar açısından karar verme mekanizmaları, 2016 yılında 63 yayın üzerinden incelenmiştir [12]. Aynı yıl, teknik borçların türleri, tanılama ve yönetim staratejileri 100 yayın üzerinden incelenmiş ve 30 adet mimari borç çalışması tespit edilmiştir [13].

Mimari borç odaklı, 2018 yılında yapılan çalışma ile 42 yayın; çözümleme yöntemi, mimari etkiler, kod yeniden düzenlemeleri, kategoriler ve kalite açısından incelenmiş ve mimari borç için kullanılabilecek, birleştirilmiş bir model önerilmiştir [3]. Mimari kokulara (architecture smells) odaklanan 2018 tarihli çalışma ile, 395 yayının ~%10’luk bölümü üzerinde mimari kokulara dönük alt sınıflandırma yapılmıştır [14]. Son olarak, mimari borçların tanısında kullanılan 12 kriter ve bu kriterlerin bir veya daha fazlasını, kod ve mimari gibi geliştirme üretileri üzerinde kontrol eden 9 araç için eşleme çalışması, 2019 yılında gerçekleştirilmiştir [15].

İncelenen mimari borç sistematik eşleme çalışmaları; borç türleri, borç maliyetleri ve borçların yönetiminde kullanılan araçlar üzerinde yoğunlaşmıştır. İlgili çalışmalarda, mimari borcun tanılama kaynakları ve yöntemleri odaklanma dışında kalmıştır.

Bu çalışma ile 28 yayın üzerinden, mimari borçların tanılamasında kullanılan üretiler, yöntemler ve araçlar incelenmiştir.

III. ARAŞTIRMA YÖNTEMİ

Araştırma yöntemi olarak Petersen ve arkadaşlarının tanımladığı sistematik eşleme çalışması adımları takip edilmiştir [10]. Bu bölümde her adımda yapılanlar kısaca anlatılmaktadır.

A. Araştırma Soruları

Bu çalışma kapsamında öncelikle mimari borç tanılama problemi için bir yöntem ya da teknik öneren çalışmaların yıllara göre sayıları, bu çalışmaların nerelerde yayımlandığı ve bu konudaki akademi-endüstri işbirliği hakkında inceleme yapılmıştır. Bunun yanında aşağıdaki araştırma sorularına (AS) akademik yazında bulunan çalışmalar doğrultusunda cevaplar bulunmaya çalışılmıştır.

• AS1: Mimari borç tanılama için hangi yazılım üretileri (artifact/work product) kullanılmıştır?

• AS2: Mimari borç tanılama için hangi yöntemler ve/veya teknikler kullanılmıştır?

• AS3: Hangi yazılım iş ürünleri, hangi yöntem ve/veya tekniklerle işlenerek mimari borç tanılama yapılmaktadır?

• AS4: Mimari borç tanılama için hangi araçlar kullanılmaktadır?

B. Arama Yöntemi ve Sorgu Cümleleri

Yazılım mühendisliği alanında akademik yayınlar içeren beş elektronik veritabanında (IEEE, ACM, Springer, ScienceDirect ve Web of Science) arama yapılmıştır. Sorgu cümlesini oluşturmak için mimari borç kavramına karşılık akademik yazında yoğun olarak kullanılan İngilizce kelime öbekleri kullanılmıştır. Veritabanlarında kullanılan sorgu

cümlesi olarak (“architectural debt” OR

“architecture debt” OR “architecture technical

debt” OR “architectural technical debt”)

kullanılmıştır. Arama işlemleri 2020 yılının Mayıs ayında yapılmıştır ve arama yapılırken herhangi bir tarih kısıtı kullanılmamıştır. Yapılan aramalar sonucunda IEEE, ACM, Springer, ScienceDirect ve Web of Science veritabanlarından sırasıyla 51, 87, 44, 50 ve 49 olmak üzere toplam 281 çalışma elde edilmiştir.

C. Çalışma Seçim Kriterleri

Elde edilen çalışmaların başlıkları, anahtar kelimeleri, ve özetleri bir Google Sheets belgesinde birleştirilmiştir. Sonrasında aşağıda listelenen eleme kriterleri doğrultusunda kapsama alınacak çalışmalar belirlenmiştir.

• İngilizce dilinden başka bir dilde yazılmış yayın • Farklı kaynaklardaki aramalardan elde edilen aynı yayın • Mimari borcun tanılanması ile ilgili olmayan yayın • Kısa bildiri, özet bildiri, literatür taraması türünde yayın

Yayınların önemli bir bölümünün, mimari boç dışında başka bir alana odaklanmış olmasına rağmen mimari borç sözcüklerini yaygın şekilde kullanımı, yayın sayısının önemli oranda daralmasına yol açmıştır.

Sonuç olarak, eleme kriterleri uygulanarak oluşturulan kapsamda mimari borcun tanılanması problemini irdeleyen 28 yayın elde edilmiştir.

D. Veri Çıkarımı

Kapsamda bulunan 28 yayının tam metinleri araştırma sorularına cevap vermek için incelenmiştir. Araştırma soruları için yayınlarda bulunan cevaplar yazarlar tarafından çıkarılarak bir Google Sheets listesine işlenmiştir. Veri çıkarımları sırasında iki toplantı yapılarak sorulara verilen cevaplar için nasıl veri çıkarıldığı konusunda yazarlar fikir alışverişinde bulunmuşlardır. Veri çıkarımı tamamlandıktan sonra yapılan bir toplantıda elde edilen cevaplar topluca değerlendirilmiş ve her bir sorunun cevabı için birer sistematik harita çıkarılmıştır. Bu sistematik haritalar doğrultusunda elde edilen veriler bütünleştirilmiştir. Bu bütünleştirilmiş verilerden elde edilen bulgular bir sonraki bölümde paylaşılmaktadır.

IV. BULGULAR

Değerlendirmesi yapılan 28 çalışmanın yayın yıllarına göre seyri Şekil 3’te verilmiştir. Yıllara göre dağılım

incelendiğinde genel bir yükseliş eğimi gözlemlenmektedir. Genel eğilime uymayan yıllarda, hem sorgu sonucu elde edilen hem de kapsama giren yayın sayısında dönemsel bir azalma olduğu gözlemlenmiştir.

Şekil 3. Yayınların yıllara göre dağılımı

Kapsamdaki 28 çalışmanın 23’ü konferans kitapçıklarında, beş tanesi ise dergilerde yayımlanmıştır. 28 çalışmanın 12’si üç konferansta sunulmuştur. “International Conference on Software Engineering” konferansında dört yayın, 2010-2017 yılları boyunca düzenenen “International Workshop on Managing Technical Debt (MTD)” çalıştayında dört yayın ve 2018 yılında MTD’den evrilen “International Conference on Technical Debt” konferansında dört yayın sunulmuştur. Özellikle, “Technical Debt” konulu ve Software Engineering Institute (SEI) kaynaklı çalıştay ve devamındaki konferanslarda yayınların %29’u sunulmuştur.

Şekil 4’te görüldüğü gibi, 28 çalışmanın 17’si akademik araştırmacılar, bir çalışma ise endüstri araştırmacıları tarafından yapılmıştır. On çalışmada ise akademideki ve endüstrideki araştırmacılar işbirliği yapmışlardır. Bu dağılama göre mimari borç konusu halen akademik bir çalışma alanı olarak değerlendirilmektedir.

Şekil 4. Yayınların yıllara göre dağılımı

A. Mimari borç tanılama için kullanılan yazılım üretileri

Yazılım geliştirme çalışmalarında, bilinçli alınan kararlar ve yapılan işlemler, teknik borç olarak değerlendirmesine rağmen, mimari borç tanılama için bilinçli veya bilinçsiz oluşturulan faklı kaynaklar karşımıza çıkmaktadır [4]. AS1 için mimari borç tanılama kaynağını oluşturan yazılım geliştirme üretileri Şekil 5’te verilmiştir. Değerlendirilen 28 çalışma için toplam 39 ve ortalama 1,39 tanı kaynağı kullanıldığı gözlemlenmiştir.

Tanı kaynağı olarak ilk sırada odaklanmış olan kaynak kod, bilinçli ve bilinçsiz üretilen kod yapısını ve değişiklik içeriğini barındırmaktadır. Benzer şekilde ikinci sırada görülen hata ve işlem kayıtları da yaygın olarak bilinçsiz yapılan çalışmaların ürünleri olarak değerlendirilebilir. Daha sonra gelen; tasarım modeli, iletişim kayıtları, kod yorum

satırları ve değişiklik talebi gibi üretiler, geliştirme çalışmaları esnasında bilinçli üretilmiş kaynaklardır.

Şekil 5. Mimari borç tanılama için kullanılan yazılım üretileri B. Mimari borç için kullanılan yöntemler ve teknikler

Mimari borç tanılama için kullanılan yöntem ve yaklaşımlar Şekil 6’da listelenmiştir.

En yaygın tanı yöntemi olarak ilk sırada , herhangi bir üreti incelemesi içermeyen ve deterministik olmayan uzman görüşüne dayalı tanı yöntemi karşımıza çıkmaktadır. İkinci sırada, kaynak kod yapısı ve içsel referansların, nesne yönelimli programlama kuralları çerçevesinde çözümlenmesine dayanan tasarım kural uzayı/yapı matrisi gelmektedir [16]. Yine kaynak kod üzerinden referansları çözümlenerek oluşturulan bağımlılık çizgesi üçüncü sırada yer almaktadır. Dördüncü sırada görülen, yapay zeka çalışma alanının bir alt dalı olan doğal dil işleme ise doğal dil ifadeleri içeren yazılım üretileri üzerinden tanılama yapmak için kullanılmaktadır.

Borçların tanısında kullanılan yöntem ve yaklaşımlar açısından belirgin bir gelişim ve odaklanma gözlemlenememiştir.

C. Mimari borç tanılama için kullanılan yazılım üretileriyle kullanılan yöntemler/teknikler arasındaki ilişkiler

Mimari borç tanılama kaynakları ile yöntemleri arasındaki bağlantılar AS3 kapsamında araştırılmıştır. Çalışmaların, tanılama için bir veya daha fazla kaynağı, bir veya daha fazla yöntem ile kullandığı, gözlemlenmiştir. Gözlem sonucu, Şekil 7’de verilmiştir.

Değerlendirilen 28 çalışma için toplam 53 ve ortalama 1,89 kaynak-yöntem kesişimi gözlemlemiştir. Bir kaynak birden fazla yöntemle, bir yöntem de birden fazla kaynakla kullanılabildiği için Şekil 6’daki toplam sayılar Şekil 4’teki ve 5’teki toplamlarla örtüşmeyebilmektedir.

Tanılama kaynağı ve yöntemi arasındaki en yüksek kesişim, kaynak kod ve tasarım kural uzayı/yapı matrisi arasında 7 olarak gözlemlenmiştir. İkinci sırada yine kaynak kod ile ilişki/bağımlılık çizgesi arasında 6 olarak gözlemlenmiştir. Kaynak kod, 28 çalışmada, 12 yöntem tarafından, toplamda 33 ve ortalama 1,18 kere kullanılmıştır.

Şekil 6. Mimari borç tanılamak için kullanılan yöntem ve yaklaşımlar

Şekil 7. Tanılama kaynakları ve yöntemleri

D. Mimari borç tanılama için kullanılan araçlar

Mimari borç tanılamada araç kullanma durumu ve hangi araçların kullanılıdığı AS4 yanıtı olarak araştırılmıştır. Araştırma sonucu görsel olarak Şekil 8’de verilmiştir.

Araçların 11 adedi genel erişime, 3 adedi özel erişime açık iken 14 adedi için erişim olanağı tespit edilememiştir. Ayrıca 4 aracın kaynak kodu erişilebilir durumda, diğer araçların kaynak kod bilgisi elde edilememiştir.

Şekil 8. Mimari borç tanılama araçları

Verilen küme içerisinde, 10 değeri ile ilk sırayı alan yok/belirtilmemiş seçeneği, yöntemler arasında ilk sırayı alan uzman görüşünün değerini desteklemektedir. Prototip olarak geliştirilmiş araçlar dikkate alınmaz ise en çok kullanım, 3 kereyle Arcan ve Titan/DV8 adlı araçlarda gözlemlenmiştir.

Tanılama araçları, yoğun olarak kaynak kodu temel alarak çalışmaktadır. Mimari üretiler ve proje faaliyet üretileri üzerinden mimari borç tanılaması yapan araçların üretimi ve kullanımı etkin değildir.

V. SONUÇ VE GELECEK ÇALIŞMALAR

Bu çalışmada, mimari borcu tanılamada kullanılan kaynaklar, yöntemler ve araçlar incelenmiştir.

Yazılım mühendisliğinde teknik borç farkındalığı 1992 yılında başlamış olmasına rağmen, mimari borç gibi bir teknik borç kırılımının, tanımı ve tanılamasında henüz bir olgunluk seviyesine gelinemediği gözlemlenmiştir. Özellikle son beş yıl için yayınlarda bir artış eğilimi görülmüştür. Bu artışın ana kaynağı olarak “Technical Debt” konulu çalıştay ve konferans serisinin öne çıktığı gözlemlenmiştir.

Mimari borç çalışmalarında, endüstri çevreleri katılımcı bir profil sergilerken, akademi çevreleri sürükleyici bir rol oynamaktadır.

Mimari borç tanılamasının yaygın olarak kaynak kod üzerinden yapıldığı gözlemlenmiştir. Bu durum; mimari model, kararlar, değişiklik isteği ve diğer geliştirme üretilerinin yetersiz olduğunu göstermektedir. Ayrıca, tanı kaynağı olarak gereksinimlerle bağlantılı hiçbir üretinin kullanılmadığı gözlemlenmiştir.

Tanılama için kullanılan kaynak ve yöntemlerde henüz bir olgunlaşma sağlanamadığı için çalışmalarda birden fazla kaynak ve birden fazla yöntem kullanıldığı görülmüştür. Bu durum, genel kullanıma uygun ve sistematik bir yöntemin henüz ortaya konulamadığını göstermektedir.

Gelecek çalışma olarak, mimari borç tanılamasında kullanılan yöntemlerin soyağacının çıkartılması planlanmaktadır.

VI. KAYNAKÇA

[1] W. Cunningham, “Experience Report - The Wycash Portfolio Management System,” in Addendum to the proceedings on OOPSLA, 92.

[2] N. Brown, Y. Cai, Y. Guo, R. Kazman, M. Kim, P. Kruchten, E. Lim, A. MacCormack, R. L. Nord, I. Ozkaya, R. S. Sangwan, C. B. Seaman, K. J. Sullivan and N. Zazworka, “Managing Technical Debt in Software-Reliant Systems,” FoSER10: FSE/SDP workshop on Future of software engineering research, 2010.

[3] T. Besker, A. Martini and J. Bosch, “Managing architectural technical debt: A unified model and systematic literature review,” The Journal of Systems and Software, vol. 135, pp. 1-16, 2018.

[4] S. McConnell, “Managing Technical Debt,” 2008. [Online]. Available: http://www.construx.com/uploadedfiles/resources/whitepapers/Manag ing Technical Debt.pdf. [Accessed 2020].

[5] U. Bob, “Technical Debt,” 2009. [Online]. Available: https://www.productplan.com/glossary/technical-debt. [Accessed 2020].

[6] M. Fowler, “Technical Debt Quadrant,” 2009. [Online]. Available: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html. [Accessed 2020].

[7] P. Kruchten, R. L. North and İ. Özkaya, “Technical Debt: From Metaphor to Theory and Practice,” IEEE Software, vol. 29, no. 6, pp. 18-21, 2012.

[8] M. Fowler, “Design Stamina Hypothesis,” 2007. [Online]. Available: https://martinfowler.com/bliki/DesignStaminaHypothesis.html. [Accessed 2020].

[9] B. A. Kitchenham, T. Dybå and M. Jørgensen, “Evidence-based Software Engineering,” in 26th International Conference on Software Engineering, 2004.

[10] K. Petersen, R. Feldt, S. Mujtaba and M. Mattsson, “Systematic mapping studies in software engineering,” in 12th International Conference on Evaluation and Assessment in Software Engineering (EASE), 2008.

[11] Z. Li, P. Avgeriou and P. Liang, “A systematic mapping study on technical debt and its management,” Journal of Systems and Software, cilt 101, pp. 193-220., 2015.

[12] C. Fernández-Sánchez, J. Garbajosa, A. Yagüe and J. Perez, “Identification and analysis of the elements required to manage technical debt by means of a systematic mapping study,” Journal of Systems and Software, vol. 124, pp. 22-38, 2017.

[13] N. S. Alves, T. S. Mendes, M. G. Mendonça, R. O. Spínola, F. J. Shull and C. Seaman, “Identification and management of technical debt: A systematic mapping study,” Information and Software Technology, vol. 70, pp. 100-121, 2016.

[14] K. Alkharabsheh, Y. Crespo, E. Manso and J. A. Taboada, “Software Design Smell Detection: a systematic mapping study,” Software Quality Journal, vol. 27, pp. 1069-1148, 2018.

[15] U. Azadi, F. A. Fontana and D. Taibi, “Architectural Smells Detected by Tools: a Catalogue Proposal,” in IEEE/ACM International Conference on Technical Debt (TechDebt), 2019.

[16] L. Xiao, Y. Cai and R. Kazman, “Design rule spaces: a new form of architecture insight,” in 36th International Conference on Software Engineering-ICSE, 2014.

VII. EK –A:KAPSAMDAKİ YAYINLAR Yayın

Kodu Yayın Referansı

Ç1 Nico Zazworka, Michele A. Shaw, Forrest Shull, and Carolyn Seaman. 2011. Investigating the impact of design debt on software quality. In Proceedings of the 2nd Workshop on Managing Technical Debt (MTD ’11). Association for Computing Machinery, New York, NY, USA, 17–23. DOI:https://doi.org/10.1145/1985362.1985366

Ç2 J. Brondum and L. Zhu, "Visualising architectural dependencies," 2012 Third International Workshop on Managing Technical Debt (MTD), Zurich, 2012, pp. 7-14, doi: 10.1109/MTD.2012.6226003

Ç3 R. Mo, J. Garcia, Y. Cai and N. Medvidovic, "Mapping architectural decay instances to dependency models," 2013 4th International Workshop on Managing Technical Debt (MTD), San Francisco, CA, 2013, pp. 39-46, doi: 10.1109/MTD.2013.6608677.

Ç4 R. Schwanke, L. Xiao and Y. Cai, "Measuring architecture quality by structure plus history analysis," 2013 35th International Conference on Software Engineering (ICSE), San Francisco, CA, 2013, pp. 891-900, doi: 10.1109/ICSE.2013.6606638.

Ç5 Zengyang Li, Peng Liang, Paris Avgeriou, Nicolas Guelfi, and Apostolos Ampatzoglou. 2014. An empirical investigation of modularity metrics for indicating architectural technical debt. In Proceedings of the 10th international ACM Sigsoft conference on Quality of software architectures (QoSA ’14). Association for Computing Machinery, New York, NY, USA, 119–128. DOI:https://doi.org/10.1145/2602576.2602581

Ç6 R. Kazman et al., "A Case Study in Locating the Architectural Roots of Technical Debt," 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Florence, 2015, pp. 179-188, doi: 10.1109/ICSE.2015.146.

Ç7 Z. Li, P. Liang and P. Avgeriou, "Architectural Technical Debt Identification Based on Architecture Decisions and Change Scenarios," 2015 12th Working IEEE/IFIP Conference on Software Architecture, Montreal, QC, 2015, pp. 65-74, doi: 10.1109/WICSA.2015.19.

Ç8 U. Eliasson, A. Martini, R. Kaufmann and S. Odeh, "Identifying and visualizing Architectural Debt and its efficiency interest in the automotive domain: A case study," 2015 IEEE 7th International Workshop on Managing Technical Debt (MTD), Bremen, 2015, pp. 33-40, doi: 10.1109/MTD.2015.7332622. Ç9 Lu Xiao. 2015. Quantifying architectural debts. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015).

Association for Computing Machinery, New York, NY, USA, 1030–1033. DOI:https://doi.org/10.1145/2786805.2803194

Ç10 Jesse Yli-Huumo, Andrey Maglyas, and Kari Smolander. 2016. How do software development teams manage technical debt? - An empirical study Journal of Systems and Software 120, C (October 2016), 195–218. DOI:https://doi.org/10.1016/j.jss.2016.05.018

Ç11 L. Xiao, Y. Cai, R. Kazman, R. Mo and Q. Feng, "Identifying and Quantifying Architectural Debt," 2016 IEEE/ACM 38th International Conference on Software Engineering (ICSE), Austin, TX, 2016, pp. 488-498, doi: 10.1145/2884781.2884822.

Ç12 Y. Cai and R. Kazman, "Software Architecture Health Monitor," 2016 IEEE/ACM 1st International Workshop on Bringing Architectural Design Thinking Into Developers' Daily Activities (BRIDGE), Austin, TX, 2016, pp. 18-21, doi: 10.1109/Bridge.2016.013.

Ç13 A. MacCormack and D. J. Sturtevant, “Technical debt and system architecture: The impact of coupling on defect-related activity,” J. Syst. Softw., vol. 120, no. 10, pp. 170–182, 2016

Ç14 B. Vogel-Heuser and E.-M. Neumann, “Adapting the concept of technical debt to software of automated Production Systems focusing on fault handling, modes of operation, and safety aspects,” in Proceedings of the 20th World Congress of the International Federation of Automatic Control (IFAC), 2017, pp. 5887-5894.

Ç15 Clemente Izurieta, David Rice, Kali Kimball, and Tessa Valentien. 2018. A position study to investigate technical debt associated with security weaknesses. In Proceedings of the 2018 International Conference on Technical Debt (TechDebt ’18). Association for Computing Machinery, New York, NY, USA, 138–142. DOI:https://doi.org/10.1145/3194164.3194167

Ç16 Antonio Martini, Erik Sikander, and Niel Madlani. 2018. A semi-automated framework for the identification and estimation of Architectural Technical Debt. Inf. Softw. Technol. 93, C (January 2018), 264–279. DOI:https://doi.org/10.1016/j.infsof.2017.08.005

Ç17 A. Biaggi, F. Arcelli Fontana and R. Roveda, "An Architectural Smells Detection Tool for C and C++ Projects," 2018 44th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Prague, 2018, pp. 417-420, doi: 10.1109/SEAA.2018.00074.

Ç18 Ran Mo, Yuanfang Cai, Rick Kazman, and Qiong Feng. 2018. Assessing an architecture’s ability to support feature evolution. In Proceedings of the 26th Conference on Program Comprehension (ICPC ’18). Association for Computing Machinery, New York, NY, USA, 297–307. DOI:https://doi.org/10.1145/3196321.3196346

Ç19 Martini A., Fontana F.A., Biaggi A., Roveda R. (2018) Identifying and Prioritizing Architectural Debt Through Architectural Smells: A Case Study in a Large Software Company. In: Cuesta C., Garlan D., Pérez J. (eds) Software Architecture. ECSA 2018. Lecture Notes in Computer Science, vol 11048. Springer Ç20 Wu, Wensheng & Cai, Yuanfang & Kazman, Rick & Mo, Ran & Liu, Zhipeng & Chen, Rongbiao & Ge, Yingan & Liu, Weicai & Zhang, Junhui. (2018).

Software Architecture Measurement—Experiences from a Multinational Company: 12th European Conference on Software Architecture, ECSA 2018, Madrid, Spain, September 24–28, 2018, Proceedings. 10.1007/978-3-030-00761-4_20.

Ç21 R. Roveda, F. Arcelli Fontana, I. Pigazzini and M. Zanoni, "Towards an Architectural Debt Index," 2018 44th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Prague, 2018, pp. 408-416, doi: 10.1109/SEAA.2018.00073.

Ç22 Maleknaz Nayebi, Yuanfang Cai, Rick Kazman, Guenther Ruhe, Qiong Feng, Chris Carlson, and Francis Chew. 2019. A longitudinal study of identifying and paying down architecture debt. In Proceedings of the 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP ’19). IEEE Press, 171–180. DOI:https://doi.org/10.1109/ICSE-SEIP.2019.00026

Ç23 B. Perez, D. Correal and H. Astudillo, "A Proposed Model-Driven Approach to Manage Architectural Technical Debt Life Cycle," 2019 IEEE/ACM International Conference on Technical Debt (TechDebt), Montreal, QC, Canada, 2019, pp. 73-77, doi: 10.1109/TechDebt.2019.00025.

Ç24 Q. Feng, Y. Cai, R. Kazman, D. Cui, T. Liu and H. Fang, "Active Hotspot: An Issue-Oriented Model to Monitor Software Evolution and Degradation," 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE), San Diego, CA, USA, 2019, pp. 986-997, doi: 10.1109/ASE.2019.00095.

Ç25 S. Soares de Toledo, A. Martini, A. Przybyszewska and D. I. K. Sjøberg, "Architectural Technical Debt in Microservices: A Case Study in a Large Company," 2019 IEEE/ACM International Conference on Technical Debt (TechDebt), Montreal, QC, Canada, 2019, pp. 78-87, doi: 10.1109/TechDebt.2019.00026. Ç26 G. K. Hanssen, G. Brataas and A. Martini, "Identifying Scalability Debt in Open Systems," 2019 IEEE/ACM International Conference on Technical Debt

(TechDebt), Montreal, QC, Canada, 2019, pp. 48-52, doi: 10.1109/TechDebt.2019.00014.

Ç27 Mendes, T., Gomes, F., Gonçalves, D. et al. VisminerTD: a tool for automatic identification and interactive monitoring of the evolution of technical debt items. J Braz Comput Soc 25, 2 (2019). https://doi.org/10.1186/s13173-018-0083-1

Ç28 Mário André de Freitas Farias, Manoel Gomes de Mendonça Neto, Marcos Kalinowski, Rodrigo Oliveira Spínola,Identifying self-admitted technical debt through code comment analysis with a contextualized vocabulary, Information and Software Technology, Volume 121, 2020