Metrikler yazılımın ya da işlemlerin verilen özniteliklerin
hangilerine sahip olduklarını gösteren nümerik ölçülerdir. Metriklere örnek
olarak; “her bin satır koddaki hata sayısı”, “ortalama yazılım modülü boyutu”,
verilebilir. Metrikler yazılım yaşam süreci boyunca toplanır ve analiz
edilirler ve bize aşağıda verilen konularda yardımcı olurlar;
- Yazılım kalite seviyesinin belirlenmesi
- Proje
zamanlama kestirimi(tahmin)
- Zaman
ilerlemesinin izlenmesi
- Yazılım boyutu ve
karmaşıklığının hesaplanması
- Proje maliyetinin
belirlenmesi
- Süreçlerin iyileştirilmesi
Yazılım kalite
seviyesi ve proje maliyeti gibi amaçlar yeterince açıklanmadığı zaman, farklı
yorumlara konu olabilir. Bu farklılıklar da karışıklığa ve çatışmaya sebep
olabilirler. Örneğin, “uygulama çok nadiren çökmeli” şeklinde yapılan bir
tanımlama yeterince belirli değildir. Burada “çok nadiren” kelimesini nasıl
ölçeceksiniz? Bir günde bir mi?, hafta da bir mi? Ya da yılda bir mi?... Daha
kesin bir amaç, “Uygulama yılda 3 defadan fazla çökmemelidir” şeklinde
verilebilir. Bu şekilde belirtildikçe, amaç farklı yorumlara sebep olmaz ve daha
ölçülebilir olur. Bir projeye görünürlük sağlamak için ölçülebilir, nesnel
ölçütler olmadan projenin ilerlemesini ölçmek zordur; zamanında olup
olmadığını, kalite hedeflerini karşılayıp karşılamadığını, müşteriye sevke
hazır olup olmadığını… Ek olarak, “ölçemediğini geliştiremezsin”.
Devamı olarak, bir
organizasyonun süreçlerinin veya bir yazılımın geliştirilmesi, metriklerin
toplanmasına ve nicel geliştirme amaçlarının belirlenmesine bağlıdır. Başarılı
bir değerlendirme için, metrik toplama projenin başlangıcında başlamalı ve tüm
yazılım yaşam döngüsü süresince, bakıma kadar devam etmelidir. Metriklerin
toplanması ve analizi, önemli miktarda yönetimsel ve mühendislik çabası
gerektirmektedir ancak ödemeler de buna değer durumdadır.
Kalite ise hangi yazılımın gereksinimlerini karşıladığının bir ölçüsü
olduğundan dolayı, uyum derecesini ölçmemiz gerekmektedir. Yazılım
kalite metriklerinin bir kümesini oluşturmakta yarar vardır. Bunlar proje
için toplanan metrikler olup, tüm metriklerin bir alt kümesi olacaktır. Bu
metrikler özel olarak yaşam döngüsü boyunca kullanılan yazılım kalite
karakteristiklerine odaklanmışlardır.
Yazılım kalite metriklerinden en önemlileri aşağıda sıralandığı gibidir;
1.Hata yoğunluğu
Hata yoğunluğu, yazılımın boyutuyla ilişkili olarak hataların sayısını
ifade eder. Boyut tipik olarak binlerce satır kod (KLOC) şeklinde ifade
edilir, dolayısıyla hata yoğunluğu hatasayısı/KLOC olarak ifade
edilebilecektir. Hatanın kullanıcı gereksinimlerinden herhangi bir sapma
olduğunu hatırlayınız. Bu yüzden hata yoğunluğu kalite ölçümü için
kullanılan en önemli metriklerden biridir. Genel olarak yüksek hata
yoğunluğu, düşük kalite demektir. Şirketler tipik olarak hataları türüne
göre ve şiddetine göre karakterize ederler ki göreceli olarak önemlerine
göre ayırt edilebilsin.
Aşağıdaki örnek yüksek şiddette bir hatanın nasıl
tanımlanabileceğini ve kalite amacını tanımlamaktadır:
Bir sınıf bir hata, yazılım gereksinim şartnamesinin üçüncü bölümüne
göre memnuniyeti karşılamak için başarısızdır. Uygulama 5 sınıftan
oluşabilmekte ve ilk ayda her 1000 kullanıcı için 1 hata raporundan başka
işlem yapamamaktadır.
2.Sistem Güvenilirliği
Güvenilirlik sistemin uygunluğu ya da belirlenen bir peryotta sistem
çökmesinin sıkılığıdır. Tipik olarak bu durum sistem çökmesi için ortalama
zaman(MTTF) olarak kullanılır ve sistem çökmeleri arasındaki geçen zaman
miktarıdır. MTTF emniyetle ilgili sıklıkla kullanılan bir metriktir(havayolu
trafik kontrol sistemi, havacılık elektroniği ve silahlar).
Örneğin U.S hükumeti hava yolu trafik kontrol sistemini yıllık bazda üç
saniyeden daha fazla erişilmez olmamasını görev kabul eder. Bir başka örnek
hücresel ağlarda kullanılan iletişim anahtarlarında görülebilir. Büyük network
sağlayıcılar, bu cihazların yılda %99.999 oranında erişilebilir olmasını görev
sayar. Bu yılda 5 dakika 15 saniye kesinti anlamına gelmektedir. Okuyucu MTTF
için neden %100 değil diye sorabilir. Cevap genel olarak bu oranın elde
edilebilir olmadığıdır.
3.Müşteri problemleri
Müşteri problemleri, müşterinin ürünü kullanırken aldığı
tüm problemlerin sayısıdır. Problemlerden bazıları yazılımdaki geçerli
hatalardan kaynaklanabilir. Diğer bazıları hata kaynaklı olmayabilir, kafa
karıştırıcı kullanıcı ara yüzü, zayıf hazırlanmış dökümantasyon veya hataları
çoğaltmak(yinelenen)(çoktan rapor edilmiş ve çözülmüş ama raporlama biriminin
bilmediği hata) gibi sebeplerden dolayı olabilir. Yinelenen hatalar bir hatanın
ne kadar yaygın olduğunun en iyi göstergesi olabilir.
Bunlar farklı
kullanıcılar tarafından karşılaşılan aynı hatalardır. Tüm bu durumlarda,
problem bir hatadan kaynaklı olsun veya olmasın, müşteriler kullanışlılık
problemi olarak algılanan sorunlarla karşılaşıyorlar ve sonuç olarak yazılımdan
memnun olmuyorlar. Bu da müşteri problemlerini en önemli kalite göstergesi
yapmaktadır. Bu metrik tipik olarak problem/kullanıcı/aylar ile ifade edilir.
Bu ve diğer metrikler yazılım ürünü teslim edildikten sonra bölüm 7 de
tartışıldığı gibi test ve bakım aşamasında toplanabilir.
3.Uyumluluk (Cohesion)
Bunge
benzerliği σ(), iki varlık arasındaki özellik kümesinin kesişimi olarak
adlandırılmaktadır. Benzerliğin bu genel tanımından yola çıkarak metotlar
arasındaki benzerliğin derecesi, bu iki metot tarafından kullanılan nitelik
değişkenleri kümesinin kesişimi olarak tanımlanmaktadır. Elbette metodun
kullandığı nitelik değişkenleri metodun özellikleri değildir ama nesnenin
metotları, kullandığı nitelik değişkenlerine oldukça bağlıdır.σ(M1,M2), M1 ve
M2 metotlarının benzerliği, {Ii} = Mi metodu tarafından kullanılan nitelik
değişkenleri olmak üzere σ(M1,M2) = {I1} n {I2}’dir.Metotların benzerlik
derecesi, hem geleneksel yazılım mühendisliğindeki uyumluluk kavramı ile hem de
kapsülleme ile ilişkilidir.
Metotların
benzerlik derecesi, nesne sınıfının uyumluluğunun başlıca göstergesi olarak
kabul görülebilir. Uyumluluk bir sınıftaki metot ve niteliklerin birbirleriyle
ilgili olmasının ölçüsüdür. Bir sınıftaki metot parametrelerindeki ve nitelik
tiplerindeki güçlü örtüşme iyi uyumluluğun göstergesidir. Eğer bir sınıf aynı
nitelik değişkenleri kümesi üzerinde farklı işlemler yapan farklı metotlara
sahipse, uyumlu bir sınıftır. Eğer bir sınıf birbiri ile ilgili olmayan işler
yapıyorsa, birbirleriyle ilgili olmayan nitelik değişkenleri barındırıyorsa
veya çok fazla iş yapıyorsa sınıfın uyumluluğu düşüktür.
4.İşlevsellik
Yazılımın
ihtiyaçları karşılama becerisi olarak tanımlanmaktadır. Uygunluk, doğruluk,
birlikte çalışılabilirlik ve güvenlik konuları bu sınıf altında
incelenmektedir.
5.Karmaşıklık (Complexity)
Karmaşıklık,
sınıfların iç ve dış yapısını, sınıflar arası ilişkileri kavramadaki zorluğun
derecesidir. “Bir nesnenin karmaşıklığı bileşiminin çokluğudur. Buna göre
karmaşık bir nesne çok özelliğe sahip olur. Tanımdan hareketle (x, p(x))
nesnesinin karmaşıklığı özellik kümesinin kardinalitesi yani |p(x)| olur.
6. Code
Coverage
Yazılan
testlerin kodun ne kadarını kapsadığını ölçer. Code Coverage için %80 gibi bir
oran oldukça iyi gibi görünse de aslında az sayıda basit test yazarak dahi bu
orana ulaşılabilmesi bir hayli kolaydır. Bu sebepten Code Coverage oranının
%100 olması beklenmektedir.
7.Güvenilirlik
Yazılımın
düzgün çalışma halini muhafaza edebilme becerisi olarak tanımlanmaktadır.
Olgunluk, hata toleransı ve geri kurtarma konuları bu sınıf altında
incelenmektedir.
8.Kullanılabilirlik
Yazılımın
kullanım kolaylığı sağlayan yetenekleri olarak tanımlanmaktadır. Öğrenebilme,
anlaşılabilirlik, işletilebilirlik ve kullanıcı etkileşimi konuları bu sınıf
altında incelenmektedir.
9.Verimlilik
Yazılımın
ihtiyaç duyulan ölçüde yeterli performansla çalışabilme becerisi olarak
tanımlanmaktadır. Zaman ve kaynak kullanımı konuları bu sınıf altında
incelenmektedir.
10.Bakılabilirlik
Yazılımın
değişiklik veya düzeltme isteklerine adaptasyon yeteneği olarak
tanımlanmaktadır. Değiştirilebilirlik, test edilebilirlik, analiz edilebilirlik
ve bağışıklık konuları bu sınıf altında incelenmektedir.
11.Taşınabilirlik
Yazılımın
çalıştığı ortam değişikliklerine uyum sağlayabilme yeteneği olarak
tanımlanmaktadır. Adaptasyon yeteneği, yüklenebilirlik özellikleri, ortam
değiştirme imkânı ve diğer yazılımlarla uyum konuları bu sınıf altında
incelenmektedir.
12. Müşteri Memnuniyeti
Müşteri memnuniyeti
metrikleri yaygın olarak müşteri memnuniyeti anketleri sayesinde toplanırlar.
Cisco System gibi şirketler [5] müşterilerinden memnuniyet ölçüsü olarak 5
üzerinden bir geri besleme alırlar (5=çok memnun, 1=çok memnuniyetsiz).
IBM CUPRIMDSO
kategorilerini kullanır (Yetenek/fonksiyonellik, kolay kullanım, başarım,
güvenilirlik, bakım kolaylığı, yüklenebilirlik, dökümantasyon, servis,
ayrıntılı tasarım). Hewlett-Packard FURPS(Fonksiyonellik, Kolay kullanım,
güvenilirlik, başarım ve servis) metriğini kullanır [4]. Bu anketlerin sonucu
ilgili şirketlerin kendi önceliklerini geliştirmeleri için yönlendirici olarak
kullanılır.
13.Nesne
Sınıfları Arasındaki Bağımlılık (Coupling Between Object Classes – CBO)
Sınıfın
bağımlı olduğu sınıf sayısıdır. Bu metrikte, bir sınıf içinde nitelik ya da
metotlar diğer bir sınıfta kullanılıyorsa, iki sınıf arasında bağımlılık olduğu
kabul edilmiştir. Sınıflar arasındaki aşırı bağımlılık modüler tasarıma zarar
verir ve tekrar kullanılabilirliği azaltır. Bir sınıf ne kadar bağımsızsa başka
uygulamalarda o kadar kolaylıkla yeniden kullanılabilir. Bağımlılıktaki artış,
değişime duyarlılığı arttıracağından, yazılımın bakımını zorlaştırır.
Bağımlılık aynı zamanda tasarımın farklı parçalarının ne kadar karmaşık test
edileceği hakkında fikir verir. Bağımlılık fazla ise testlerin daha özenli
yapılması gerektiğinden test maliyetleri artacaktır.
14.Sınıfın
Ağırlıklı Metot Sayısı (Weighted Methods per Class – WMC)
Bir sınıfın
tüm metotlarının karmaşıklığının toplamıdır. Tüm metotların karmaşıklığı 1
kabul edilirse, sınıfın metot sayısı olur. Sınıfın metotlarının sayısı ve
metotlarının karmaşıklığı, sınıfın geliştirilmesine ve bakımına ne kadar zaman
harcanacağı hakkında fikir verebilir. Metot sayısı çok olan taban sınıflar,
çocuk düğümlerde daha çok etki bırakırlar; çünkü tanımlanan tüm metotlar
türetilen sınıflarda da yer alacaktır. Metot sayısı çok olan sınıfların
uygulamaya özgü olma ihtimali yüksektir. Bu nedenle tekrar kullanılabilirliği
düşürürler.
15.Metotların
Uyumluluğu (Lack of Cohesion in Methods – LCOM)
Bu metriğin
birden çok tanımı olmakla birlikte ilk kez kullanılanı şu şekildedir: C1
sınıfının M1, M2, …, Mn metotları olduğunu ve {li} kümesinin de Mi metodunda
kullanılan nitelik değişkenleri kümesi olduğunu kabul edelim. Bu durumda LCOM
bu n kümenin kesişiminden oluşan ayrık kümelerin sayısıdır. Daha sonra bu tanım
yenilenerek şu şekle getirilmiştir: P hiçbir ortak nitelik değişkeni
paylaşmayan metot çiftlerinin kümesi, Q en az bir ortak nitelik değişkeni paylaşan
metot çiftlerinin kümesi olsun. Bu durumda LCOM, |P| > |Q| ise |P|-|Q|, aksi
halde 0 olur. Bunlarla birlikte literatürde farklı tanımlar da mevcuttur.
Sınıfın uyumluluğunun düşük olması, sınıfın iki veya daha fazla alt parçaya
bölünmesi gerektiğini gösterir. Düşük uyumluluk karmaşıklığı arttırır, bu
nedenle geliştirme aşamasında hata yapma ihtimali yükselir. Ayrıca metotlar
arasındaki ilişkisizliklerin ölçüsü sınıfların tasarımındaki kusurların
belirlenmesinde de yardımcı olur.
16.Specialization Index (SIX)
Kod karmaşıklığını ve bakım
maliyetlerini arttırmasından dolayı overload edilmiş fonksiyon sayısının mümkün
olduğunca az olması istenir.
Bundan dolayı SIX = (Overload
Edilmiş
Metot Sayısı * DIT) / NOM şeklinde
hesaplanır. 1.2 (veya %120)'ye kadar
normal kabul edilir.
Nesne Yönelimli Metrikler
Alt Sınıf Sayısı ( Number of
Children - NOC)
NOC metriği sınıftan türemiş alt
sınıflarının sayısını verir.
- Alt sınıf sayısı çoğaldıkça
kalıtım özelliğine bağlı olarak yeniden kullanımın arttığı anlaşılır.
- ·Alt sınıf sayısının çokluğu
sınıfın hatalı soyutlama yapıldığını , belki de hatalı bir hiyerarşi
kurulduğunu gösterebilir.
- NOC sınıfın nüfus alanı
hakkında bir fikir verir.NOC metriği yüksek sınıflar gözden geçirme , test
gibi süreçlerin daha dikkatli ve uzun tutulması gereken yerlerdir.
17.Kod Büyüklüğü (Lines Of Code LOC)
Geleneksel olarak yazılımın boyutu
satır
sayısı ile ölçülür. Satır büyüklüğü
çeşitli şekillerde ölçülür :Satır Sayısı ( Lines Of Code – LOC ) ölçümü
programın tüm satırlarının sayılmasıdır.
Yorum ve boşluk içermeyen
(Non-comment Non-blank NCNB veya Source Lines Of Code SLOC ) programın yorum
satırları ve boş satırlardan arındırılmış halidir.
Çalıştırılabilir yordam sayısı
(Executable Statements EXEC) program içinde yer alan yordam sayısıdır.
Yorum Oranı (Comment Percentage -
CP)
Yorum oranı (Comment Percentage CP)
programın için hazırlanmış yorum satırlarının (kod ile birlikte ya da dışarıda)
, toplam programın yorum ve boşluk içermeyen satır sayısına (SLOC) bölümü ile
bulunur.Yüksek yorum oranı programların anlaşılabiliğini arttıran ve bakımını
kolaylaştıran bir faktördür. Yorum oranının %20 ila %30 arası olması tavsiye
edilen bir durumdur.
Kaynaklar
1. U.
Erdemir, U.Tekin, F.Buzluca, “Nesneye Dayalı Yazılım Metrikleri ve Yazılım
Kalitesi” Yazılım Kalitesi ve Yazılım Geliştirme Araçları
Sempozyumu (YKGS08), İstanbul, 2008.
2. Doç Dr.
Feza Buzluca, İTÜ, BLG468E Object-Oriented Modeling and Design ders
notları http://ninova.itu.edu.tr/tr/dersler/bilgisayar-bilisim-fakultesi/2097/blg-468e/ekkaynaklar/
Hiç yorum yok:
Yorum Gönder