Özet. Yazılım kalitesini etkileyen faktörler temel olarak doğrudan ölçülebilenler ve doğrudan ölçülemeyenler olarak ikiye ayrılır. Kamu yazılımlarında süreç ve ürün kalitesi genellikle ihmal edilir ve bu durum maliyeti olumsuz etkiler. Yazılımın test edilmesi ve incelenmesi istendiğinde çoğu zaman projenin sonuna yaklaşılmıştır ve elde sadece yazılım kodu vardır. Bu tür yazılımların kalitesi değerlendirilmek istendiğinde, doğrudan ölçülemeyen kullanılabilirlik, test edilebilirlik, taşınabilirlik gibi kalite faktörlerinin incelenmesi zordur. Diğer taraftan yazılım kodu doğrudan ölçülebilir ve yazılımın kalitesi hakkında ipuçları verebilir. Bu çalışmada, sadece yazılımın koduna bakarak yazılımın kalitesi hakkında elde edilebilecekler araştırılmış ve yazılım kalitesi, yazılım güvenilirliği ve bakım yapılabilirliğini ölçmek amacıyla geliştirilen pratik yazılım kalite modelleri karşılaştırmalı olarak incelenmiştir. Sonuç olarak, yazılımın kalitesini hızlı ve basit bir şekilde ölçmek amacıyla kullanılacak pratik bir model önerilmiştir.
yazılımların kalitesini en az maliyetle ve en kısa sürede nasıl değerlendirebiliriz? (Çok sayıda kamu kurumu)
Taleplerin ve talep edenlerin çeşitliliği; sadece uzmanlar tarafından değil herkes tarafından anlaşılabilen, ekonomik, aynı ürün için her zaman aynı sonucu veren, uygulanabilir iyileştirme önerileri içeren bir kalite değerlendirme raporlamasına ihtiyaç olduğunu göstermektedir.
Ülkemizde başta e-devlet yazılımları olmak üzere kamunun ihtiyacına yönelik geliştirilen yazılımlar, genelde bakım yapılabilirlik ve güvenilirlik sorunları içerir, yeterince test edilmeden onaylanır ve kullanılırken çok sayıda sorun yaşanır. Müşteri, yazılımın şartnameye uygun olarak geliştirildiğinin incelenmesi ve test edilmesi gerektiğini genellikle teslim alırken fark eder. Bu aşamada kendisine sadece yazılımın kodu ile varsa şartnamede belirtilen kısıtlı sayıda dokümantasyon teslim edilir. Kod incelenerek yazılımın kalitesi ve içerdiği hata sayısında öngörüde bulunma başarısı da doğal olarak düşmektedir.
Diğer yandan sadece statik kod analizi ile yazılım hakkında çok önemli bilgiler
edinilebileceği, yazılımın barındırdığı çok sayıda hatanın testlerden önce elimine
edilebileceği araştırma konusu olmuştur. Johns [
Bu çalışmada, yazılımın kalitesinin değerlendirilmesi için sadece kodun sunulduğu
durumlarda, öncelikle incelemeye tabi yazılımın kalitesinin pratik bir şekilde
değerlendirilmesi, ardından da etkin ve uygulanabilir iyileştirme önerilerinin sunulması için
altyapı kurulması amaçlanmıştır. Sadece kod üzerinde inceleme yapılarak, yazılım
kalitesinin ne seviyede olduğunu değerlendirmek için kullanılan modeller incelenmiş
ve bu modellerden günümüz ihtiyaçlarına göre uygulanabilir bir kod kalitesi
değerlendirme modeli oluşturulmuştur. Modeli oluştururken yazılım kalitesine yönelik
ISO/IEC 25010:2011 standardı [
Bütün bu modeller incelendiğinde kod üzerinde karmaşıklık, büyüklük, tasarımsal yaklaşım, birim test miktarı, uygulama açıklık bulguları, tekrarlanmış kod oranı, kodlama stili gibi çok çeşitli faktörün dikkate alındığı ve bunların çeşitli kombinasyonlarla bileşkesinin alınarak modeller oluşturulduğu görülmektedir. Öznel değerlendirmelere yol açabilecek denetim listelerinden kaçınılarak ve herkes tarafından erişilebilir özellikle açık kaynak kodlu araçlar tercih edilerek inceleme yapılabilecek bir model önerilmiştir. İncelenen modellerde uygulanabilirliği tarafımızca mümkün olmayan ya da programlama paradigmalarındaki gelişime ayak uyduramayan bazı kriterler uyarlanarak kullanılmıştır. Önerilen modelin etkinliği, seçilen açık kaynak kodlu yazılımlar üzerinde yapılan analizlerle gösterilmiştir.
Bildirinin ikinci bölümünde adı geçen modeler anlatılacak, üçüncü bölümde modellerin karşılaştırmalı analizi yapılacak, dördüncü bölümde önerilen model açıklanacak ve beşinci bölümde çalışmanın özeti yer alacaktır. 2
Yazılım kalite modelleri yetmişli yıllardan itibaren kullanılmakta ve yazılımın kalitesini bütünlük, esneklik, tekrar kullanılabilirlik gibi çeşitli açılardan incelemektedir. Bu bölümde yazılım kalitesini değerlendirmeyi hedefleyen belli başlı modeller incelenecek ve farklılıkları karşılaştırılacaktır. 2.1
Yazılım kalitesini belirleyen faktörler iki geniş kategoriye ayırılabilir: 1) Doğrudan
ölçülebilenler (örneğin satır sayısı başına düşen hata sayısı) 2) Doğrudan
ölçülemeyenler (kullanılabilirlik ya da bakım yapılabilirlik) Her iki kategori için de ölçmek istenen
yazılım (doküman, program, veri) bazı kıyas noktaları ile karşılaştırılarak kalitenin
seviyesi belirlenmeye çalışılır. Yazılım kalitesini doğrudan ölçmek amacıyla kullanılan
ölçütleri geliştirmek çok zordur ve bazı durumlarda imkansızdır.Yazılım kalitesini
etkileyen faktörlerin belirlenmesi ve kalitenin sayısal bir şekilde ifade edilmesine yönelik
ilk çalışmalardan birisi McCall Kalite Modeli'dir [
McCall modeli modelinde bakım yapılabilik, güvenilirlik, esneklik gibi 11 adet kalite faktörü ve bu faktörleri etkileyen 23 kriteri tanımlamıştır. Bu model kalitenin karakteristikleri ile metrikler arasında bağ kurmuştur. Her faktörün kaliteye etkisini ölçmek için Fq, yazılım kalite faktörü, cn regresyon katsayısı, mn de metrik değeri olmak üzere (1) tanımlanmıştır.
Fq = c1 m1 + c2 m2 + . . . + cn mn (1)
faktörle ilgili sunulan sorulara 0 (düşük) ile 10 (yüksek) skalasında bir not vermesi istenmektedir. Değerlendiricinin yazılımla ilgili rolüne ve kişisel özelliklerine göre farklı sonuçlar çıkması muhtemeldir. Metriklerin nesnelliği tartışmalıdır ve yazılım ürününün işlevselliği doğrudan ele alınmamıştır. 2.2
ISO/IEC 9126 standardı yazılım ürün kalitesini 6 temel karakteristik bileşeni ile ifade
eder [
Yazılım kalitesini ya da kaliteyi oluşturan alt faktörleri değerlendiren çok sayıda
model de kalite faktörlerinin bir denetim listesinde yer alan sorulara cevap verilmesi
dayalı olduğu benzer bir yöntemi izlemiştir. 1992 yılında ortaya çıkan Rome
Laboratuvarı Modeli yazılım güvenilirliği öngörümü (prediction) ve tahminine (estimation)
yönelik kapsamlı bir yaklaşım sunar [
Metrik Grubu
Metrik İsim Ölçüt Uygulama Tipi Metriği İster Metriği Tasarım Metrikleri Gerçekleştirme Metrikleri
A D SA ST SQ SL SX SM SR
Uygulama Tipi (Application) Geliştirme Organizasyonu (Development Organization) Yazılım Anomali Yönetimi (Software Anomaly Management) Yazılım İzlenebilirliği (Software Traceability) Yazılım Kalitesi (Software Quality) Yazılım Dili (Software Language) Yazılım Karmaşıklığı (Software Complexity) Yazılım Modülaritesi (Software Modularity) Yazılım Standartları Değerlendirmesi (Software Standards Review)
Değişik tipte uygulamalar geliştirmenin getirdiği zorluk Geliştirme organizasyonu, proje yönetimi, metodlar, araçlar, teknikler, dokümantasyon Hataya duyarlı tasarımın göstergesi Tasarım ve kodun isterlere olan izlenebilirliği Kodlama standartlarına uyum Hata yoğunluğunun yazılım diline göre normalizasyonu Birim karmaşıklığı Birim büyüklüğü Tasarım kurallarına uyumluluk
En düşük ve en yüksek çarpan değerleri 2-14 (hata/1000 satır) 0.5 - 2.0 0.9 - 1.1 1.0 - 1.1 1.0 - 1.1 1.0 - 1.4 0.8 - 1.5 0.9 - 2.0 0.75 - 1.5
Modelde yazılımın her sürecinde mevcut dokümantasyon ve veri kullanılarak yapılan değerlendirmede, tarihsel ve deneysel verilerden elde edilen çıkarımlarla hesaplanmış katsayılar kullanılır. Denetim listelerine verilebilecek öznel cevaplar sonucu etkileyebilir. Hesaplamalarda günümüzde donanımların güçlenmesi ile artık geçerliliği kalmamış ya da elde edilmesi zor bazı parametreler (örneğin işlemci için milyon saniyede gerçekleştirilen işlem sayısı (MIPS) değerleri, artık kullanılmayan diller) bulunması da modelin revize edilmesi ihtiyacını doğurmaktadır. Kullanılan kodlama standardının kalitesi de modele önemli bir katsayı ile girdi sağlayan kriterdir. Ancak bu modelin getirdiği en büyük katkı, yazılım kodu üzerinde yapılan satır sayısı ve çevrimsel karmaşıklık ölçümlerinin, modele nesnel, ölçülebilir bir girdi sağlamasıdır.
Tablo 1’de yer alan SX metriğinin hesaplanmasında McCabe çevrimsel karmaşıklık metriğinden faydalanılır. SM metriğinin hesaplanmasında ise birim kod büyüklüğüne bakılır.
SX = (1.5a + b + 0.8c) / NM (2) SM = (0.9u + w + 2x) / NM (3) a = çevrimsel karmaşıklığı 20'ye eşit veya daha yüksek olan metodların sayısı b = çevrimsel karmaşıklığı 20'den az ve 6'dan fazla olan metodların sayısı c = çevrimsel karmaşıklığı 6'dan az olan metodların sayısı u = satır sayısı 100'e eşit veya daha düşük olan metodların sayısı w = satır sayısı 100'den fazla veya 500'den az olan metodların sayısı x = satır sayısı 500'den fazla olan metodların sayısı NM = toplam metod sayısı
En eski fakat en çok kullanılan yazılım kalite metriklerinden birisini ortaya koyan
McCabe, çevrimsel karmaşıklık eşiğini 10 olarak belirlemiş olup, Rome Lab.
Modelinde eşik değeri olarak atanan 6 değeri katı bir kriterdir [
Roma Lab. Modeli'nde kriterler doksanlı yıllarda 50'ye yakın projeden elde edilen
verilerle belirlenmiştir. Neufelder Rome Lab. Modeli'ne benzer ve daha kapsamlı bir
model ileri sürmüştür [
Yalnızca kodun incelenmesi ile yazılımın bakım yapılabilirliğini derecelendiren SIG
Bakım Yapılabilirlik Modeli, oldukça pratik ve herkes tarafından anlaşılabilir bir
çözüm sunar [
Seviye 1 2 3 4 5
Yazılım Büyüklüğü
SIG modelinin geliştirilmesinde en önemli motivasyon ISO/IEC 9126, ISO/IEC
25010 gibi standartların yazılım kalitesinde yönelik nesnel, ölçülebilir girdiler
sağlayamayışı ve Oman Bakım Yapılabilirlik İndeksi'nin ayrıştırıcı bir sonuç vermemesi
olmuştur [
Şekil 1. Oman Bakım Yapılabilirlik İndeksi’nin hesaplanması 2.7
Sonar'da kalite değerlendirmeye yönelik entegre edilmiş pratik modeller SIG ile sınırlı değildir. Çok sayıda eklenti arasından Quality Index, Total Quality Plugin ve SQALE eklentileri de kod üzerinden değerlendirme yapmaktadır. Sonar bu eklentilerin genişleştilmiş versiyonlarını ticari sürümüne dahil etmektedir.
Total Quality modeli de SIG modeli gibi farklı açılardan kodu incelemeyi amaçlar. İncelenen diğer modellere göre ilave olarak mimari karmaşıklığın, nesne yönelimli tasarım metriklerinin ve birim test başarı oranının kullanıldığı görülmektedir. Ancak kullanımdan kaldırıldığı için bazı parametreler hakkında belirsizlikler vardır. Total
TQ = 0.25*ARCH + 0.25*DES + 0.25*CODE + 0.25*TS Mimari: İlk defa mimariye yönelik bir metrik tanımlanmış olsa da Tangle Index’in ne olduğu ve nasıl hesaplandığı literatürde bulunmamaktadır.
ARCH = 100 – TI (Karmaşıklık indeksi)
Tasarım: Nesne Yönelimli programlama paradigması ve Chidamber&Kemerer
metriklerinin kullanılması açısından da olumlu bir örnektir [
DES=0.15*NOM+0.15*LCOM+0.25*RFC0.25*CBO+0.20*DIT (6) NOM = (1 - (class_complexity - 12) / (acel * 12)) * 50 + (1 - (method_complexity - 2.5) / (acel * 2.5)) * 50 LCOM = (1 - (lack_of_cohesion_of_method - 1) / (acel * 1)) * 100 RFC = (1 - (response_for_class - 50) / (acel * 50)) * 100 CBO = (1 - (efferent_coupling - 5) / (acel * 5)) * 100 DIT = (1 - (depth_of_inheritance_tree - 5) / (acel * 5)) * 100 Birim Kod Büyüklüğü: Bu metrik yorum satırlarını ve tekrar kod yoğunluğuna baktığı gibi Sonar aracı içerisinden hesaplanacak kural uyumluluğu indeksini de formülasyona ekler.
Code = 0.15*DOC + 0.45*RULES + 0.40*DRYNESS (4) (5) (7) DOC = Belgelenmiş API yoğunluğu (yorum satırları) RULES = Kurallara uygunluk indeksi DRYNESS = 100 – tekrarlanan kod yoğunluğu Birim Test Kapsaması: Burada birim test kapsama oranı %80 etki ettiği gibi ilk defa birim test başarım oranı kullanılmıştır.
Test = 0.80*COV + 0.20*SUC COV = Test kapsama oranı SUC = Birim test başarım oranı 2.8
Sonar Kalite Endeksi Modeli, PMD, CheckStyle gibi açık kaynak kodlu güçlü kalite araçlarından faydalanmaktadır. Bu model statik kod analizi ile uygulama açıklarını değerlendirir, kodlama stili yanlışlıklarını puanlamaya katar. Modelin bileşenleri aşağıdaki gibidir: Uygulama Açıkları Analiz bulguları: PMD aracı ile analiz edilen ve listelenen hataların kritikliğine göre puanlama yapılır ve tekrarlanmış kodları elimine ederek bulduğu geçerli satır sayısı değeri ile puanlama normalize edilir. Blocker türünde bir hata, 10 adet Minor ya da Info türünde hataya eşdeğer Kabul edilmiştir. Statik kod analizinde en büyük sorunlardan birisi “false positive” adı verilen yanlış tespitlerin çokluğudur. Dolayısı ile Info ve Minor türünde yanlış şekilde oluşturulan yüzlerce hata çıkabilir ve sonucu yanlış etkileyebilir. Info ve Minor’un hesaplamaya katılmaması önerilir. Coding = (Blocker * 10 + Critical * 5 + Major * 3 + Minor + Info) / ValidLines
Birim Kod Karmaşıklığı: Karmaşıklığa yaklaşım daha önce incelenen modellerdekine benzemekle birlikte eşik değerlerince ve normalizasyon yaklaşımında farklılık bulunmaktadır.
Complexity = (Complexity>30 * 10 + Complexity>20 * 5 + Complexity>10 * 3 + Complexity>1) / ValidLines (10)
Style = (Errors * 10 + Warnings) / ValidLines * 10 (11)
(8) (9) Coding, Complexity, Coverage ve Style bileşenlerini kullanarak PMD hatalarının en fazla etki ettiği kalite endeksi (10) ve karmaşıklığı 30’dan fazla olan metodların sayısının oranına göre hesaplanan karmaşıklık faktörü (11) adlı iki adet kalite ölçütü üretilir.
Quality Index = 10 - 4.5 * Coding - 2 * Complexity - 2 * Coverage - 1.5 * Style (12) Complexity Factor = (5 * Complexity>30) * 100 / (Complexity>1 + Complexity>10 + Complexity>20 + Complexity>30) (13) Bu model de Sonar'ın sonradan eklediği modeller nedeniyle destek vermeyi bıraktığı eklentiler arasında yer almıştır. 2.9
YKRO, yazılım kalite metrik ölçüm sonuçlarını kullanarak bir her metod ve sınıf için
yazılımın toplam kalitesini ne derece etkilediğini sayısal olarak belirlemeye dayanan
bir modeldir [
Tdj = ∑ (MVij-Thrj) (14) YKROi = ∑ ( (MVij-Thrj) / Tdj * 100) * Cj (15)
Tdj metot ya da sınıfın risk değeri, MVij metrik ölçüm sonucu, Thrj seçilen metriğin eşik değeri ve Cj seçilen metriğe verilen katsayıdır. MVij - Thrj değerinin Thrj´in MVij den büyük olması durumunda 0 olarak kabul edilmesi gereklidir. 3
Bir önceki bölümde incelenen yazılım kalite modellerinin bir kısmının çoğunlukla dolaylı ölçülebilen kriterlere dayandığı, bir kısmının da ticarileşerek maliyetinin arttığı gözlenmektedir. Örneğin; sayılan Sonar eklentilerinin tamamı belli bir süre sonra daha kapsamlı başka bir modelle yer değiştirmiş ve son modellerden olan SQALE modelinin ileri özellikleri ise ücretli olarak sunulmuştur. SQALE’in benzeri bir model olan SQuARE ise ISO/IEC 9126 standardının kalite faktörlerini göze hitap eden bir arayüz paneli ile sunan ücretli bir yazılımdır.
Kamunun ihtiyacı ücretsiz ve pratik bir çözümdür, bazılarının kullanımı için neredeyse uzman olmak gereken bu modelleri anlaşılır şekilde sunmak önemli bir fayda sağlayacaktır. Bu amaçla model incelemesinden elde edilen çıkarımlar kullanılarak, yazılım kodundan elde edilebilen tüm ipuçları çekilecek ve kapsamlı ama pratik bir model önerilecektir. İncelenen modellerin baz aldığı kriterler Tablo 5’de özetlenmiştir. McCall 25010 ROME Full-scale SIG Oman TQI SQI YKRO
DOĞRUDAN ÖLÇÜLEBİLEN KRİTERLER DOLAYLI ü ğ ü l k ü y ü B n ü r Ü X X ü ğ ü l k ü y ü B m ii r B X X X X X i r e ilt k r e m d a e lt s a H X ıılı ğ k ş a m r a K m ii r B X X X X X ı r a l r a r k e T d o K X X ili z a n A okdK lıragu i ttaS luB X a m a s p a k t s e t m ii r B X X X i r e l k r t e m m ı r a s a T X X a m a lod ilit K S X X i r e ilt e s L m it e n e D X X X X 4
Önerilen Model
Pratik kalite modellerinin incelenmesi ve tartışılması ışığında, YTKDL yazılımları
aşağıdaki kriterlere göre değerlendirecek, bir model ve uygulama geliştirmiştir:
Birim metod satır sayısı ve karmaşıklığı ifade etmede SIG bakım yapılabilirlik
metriği oldukça kolay anlaşılmaktadır. Bu nedenle sadece birim satır sayıları geçiş
aralıkları Tablo 6a’daki gibi uyarlanarak aynen kullanılmıştır. SIG modeli,
YTKDL’deki yazılım kalite değerlendirmesi tecrübelerine dayanarak, birim
büyüklüğü karşısında birim karmaşıklığının önemini artıracak şekilde
güncellenmiştir.
İncelenen modellerde tasarıma yönelik bir incelemenin yapıldığı tek model vardır ve
orada da modelin etkinliği kanıtlanmamıştır. Kamu yazılımları için tasarımla ilgili
yeni bir yaklaşım önerilecektir. YTKDL’de kullanılmakta olan türetilmiş metrik
Yazılım Kalite Risk Oranı (YKRO) kullanılacaktır [
Kritiklik seviyesi
Birim Satır Sayısı Yazılımın hata yoğunluğunu öngörmek için Rome Lab. Modeli yaklaşımı yardımcı olmaktadır, ancak metod sayılarına gore değil kod satır sayısına gore yapılan hesaplama daha doğru sonuç verecektir, bu nedenle yöntem ve katsayılar aşağıdaki gibi revize edilmiştir. SX ve SM değerleri 100 ile çarpılarak hata yoğunluğu bulunabilir. Başlangıç hata yoğunluğu 10 hata/1000 satır varsayılırsa 1000 * SX * SM değeri yazılımın barındırdığı öngörülen (predicted) toplam hata sayısını verecektir.
SX = (1.5a + b + 0.8c) / TLOC (16) SM = (0.9u + w + 2x) / TLOC (17) a = çevrimsel karmaşıklığı 20'ye eşit veya daha yüksek olan metodların toplam satır sayısı b = çevrimsel karmaşıklığı 20'den az ve 10'dan fazla olan metodların toplam satır sayısı c = çevrimsel karmaşıklığı 10'dan az olan metodların toplam satır sayısı u = satır sayısı 200'e eşit veya daha düşük olan metodların toplam satır sayısı w = satır sayısı 200'den fazla veya 500'den az olan metodların toplam satır sayısı x = satır sayısı 500'den fazla olan metodların toplam satır sayısı
TLOC = toplam satır sayısı Statik kod analizi ve kodlama stili analizinin kalite modeline etkisini formülize etme çalışmaları devam etmektedir. Doğru kullanımı yanlışmış gibi gösteren (“false positive”) hataların otomatik olarak ayıklanması çözülmesi gereken önemli bir problem olarak durmaktadır. “Minor” ve “Info” gibi hata türlerini hesaplamaya hiç katmamak bir çözüm olabilir.
Mevcut modellere ve önerilen modellere göre yapılan sınıflandırmaları karşılaştırmak için Şekil 2’de bir örnek sunulmaktadır. 8 adet açık kaynak kodlu Java yazılım kalitesi aracının (JUnit, Findbugs, UCDetector, Xradar, Tattletale, Cobertura, JDepend,
Şekil 2. Mevcut ve önerilen modellere gore açık kaynak kodlu yazılımlar üzerinde örnek bir ölçüm karşılaştırması ve yazılımların kalitesine göre sıralanması
Toplamda 5 farklı model aynı yazılımlar üzerinde denenmiştir, UCDetector 4 modele gore en iyi derece olarak 4.lüğe yerleşirken, Oman’da birinci çıkmıştır. Bu durum Oman değerlendirmesinde yorum satır sayısına yüksek puan verilmesinden ve daha sonra kullanılmak üzere yorum satırı haline getirilmiş kodların fazlalığından kaynaklanmaktadır. SIG modelinde “bakım yapılamaz” (1) notu alan yazılımlar bile Oman metriğine gore “bakım yapılabilirlik açısından başarılı” eşiği olan 85’in üzerindedir. Bu durum Oman modelinin bakım yapılabilirlik durumu açısından kullanıcıyı yanılttığını ortaya koymaktadır. Oman modeline gore üretilen puan, kullanıcıya hangi iyileştirmeleri yaparsa kaliteyi artıracağına yönelik ipucu sunmamaktadır. Halbuki SIG modeli ve ondan esinlenerek önerilen modelde yazılımın hangi iyileştirmeleri yaparsa kalitesini artıracağı nettir. SIG ile “mükemmel bakım yapılabilir” çıkan yazılımlar, önerilen bakım yapılabilirlik modelinde, 10 üzerinden 7 puan almıştır. Önerilen modeldeki YKRO Tasarımsal bileşeni ayırdedicilik sağlamıştır. SIG modeline gore 5 alan yazılımlar YKRO modeline gore 2 almıştır. Bu yazılımlardan 3 almaya en yakın olan yazılım JUnit olup, problemlerin yoğunlaştığı ilk 3 metod üzerindeki %2’lik bir iyileştirme notunu 3’e yükseltecektir. En yüksek 3 YKRO değeri toplanarak hesaplanan tasarım kriterinde, yüzdelik aralıkları laboratuvarımızda edinilen tecrübeler ışığında belirlenmiştir. Bu aralık değerleri deneysel çalışmalar ile revize edilecektir. Bu ilk kullanımda 5 üzerinden
QALab ve Findbugs sonuçları Oman modeline gore neredeyse aynı çıkarken SIG modelinde büyük fark (2 basamak) var gözlenmiştir. Önerilen model, QALab ve Findbugs arasındaki farkı 1 basamağa indirmiştir. SIG modeline bakılarak cope atılması beklenen bir yazılımın iyileştirilebileceği yönünde bir sonuç ortaya çıkmıştır. Rome modeline gore en kaliteli ve en kalitesiz yazılım arasında sadece %3.5 güvenilirlik farkı görünmektedir. Halbuki, ilk sıradaki JUnit ile son sıradaki Tattletale arasında çok belirgin farklar tespit edilmiştir. JUnit’te karmaşıklık değeri 20’yi aşan kod oranı %1 bile değil iken, TattleTale’in kodunun neredeyse yarısının karmaşıklığı 20’nin üzerindedir. Önerilen güvenilirlik modeli daha ayrıştırıcı, farkları daha net görmeyi sağlayan sonuçlar vermiştir. JUnit ile TattleTale arasında %29’luk fark (+%28 ile -%1) hesaplanmıştır. Aynı şekilde önerilen bakım yapılabilirlik modeli tasarımla ilgili ölçütleri de hesaba kattığından, Çıkarılabilecek bir sonuç da asıl amacı yazılım kalitesini değerlendirmek olan araçlarda da yazılım kalitesi yönünden sorunlar olduğunun görülmesidir. Önerilen modelde metrik ölçümleri için, laboratuvar imkanları dahilinde McCabe IQ, Understand gibi ticari araçlara ilave olarak Eclipse Metrics eklentisi gibi ücretsiz yazılımlar da kullanılabilmektedir. Sonuç olarak ortaya ücretsiz açık kaynak kodlu yazılımlardan faydalanan ve genel kabul görmüş pratik modellerden uyarlanan, kamu yazılımlarında pratik değerlendirme imkanı sağlayarak ihtiyacı karşılayan bir model ve yazılım geliştirilmiştir. Araçlar tarafından otomatik olarak üretilen ve YTKDL’de üretilen yazılım kalite değerlendirme raporları ilk başlarda çok büyük hacimli ve genelde uygulanması zor öneriler içeren dokümanlar iken, önerilen kalite modeline ait sonuçlar daha anlaşılır ve uygulanabilir maddeler içermektedir. 5
Yazılım kalitesinin, bakım yapılabilirliğinin, güvenilirliğinin kısa sürede değerlendirilmesi, çıkan sonucun da herkes tarafından kolaylıkla ve aynı şekilde anlaşılabilmesi önemli bir ihtiyaç olmuş, bu amaçla birtakım modeller geliştirilmiştir. Bu modeller incelendiğinde, incelenen faktörlerin, ölçütlerin, değerlendirme yöntemlerinin farklılıklar içerdiği görülmektedir. Bu çalışmada, geliştirme süreci bitmiş ya da sonuna yaklaşılmış kamu yazılım projelerinde, hızlı ve anlaşılır bir kalite değerlendirmesinin, mevcut kalite modellerinden faydalanılarak nasıl gerçekleştirilebileceği araştırılmıştır. Sonuç olarak satır sayısı ve karmaşıklık ölçütlerinin uyarlanarak kullanıldığı, tasarım ölçütlerinin yeni bir yaklaşımla ele alındığı, kod tekrarı ve birim test kapsaması ölçütlerinin ise kamu yazılımlarında ayrıştırıcı olmayacağı için kullanılmadığı bir model önerilmektedir. Önerilen model, özellikle, herhangi bir sürece uygun olarak geliştirilmemiş düşük kaliteli yazılımlar için anlık resim çekmekte ve yazılımın geleceği için karar verici olan mercilere faydalı bir girdi sağlamaktadır.