Ölçümbilim (metroloji) bazılarının bildiği gibi bir şeyi nasıl doğru biliriz üzerine kurulu koca bir bilim dalı. Ölçüm çok önemli çünkü ölçemediğiniz şey üzerinde net fikir yürütemiyorsunuz. Net fikir yürütemediğiniz şey hakkında da karar alamıyorsunuz.

Yazılım projeleri de bundan muaf değil. Eğer bir yazılım projenizin nasıl gittiğini sorarlarsa ve iyi derseniz arkasından size neden bu yanıtı verdin diye sorabilirler. Bunun bir ölçümü olması gerekli. Elbette ki nihai ölçüm memnun müşterilerdir ama acaba aynı memnun müşterileri elde etmenin daha iyi bir yolu olamaz mı? İşte sayısal değerleri kullanarak proje yönetmek yada projelerin giderek daha iyi yürümesi için süreç iyileştirme yapmak gibi amaçlarınız olunca siz de eliniz mahkum bir şeyleri ölçmek durumundasınız.

Bu açıdan bakınca yazılım ölçümünü (İng. software metric) bir yazılımın yada yazılım projesinin ölçebildiğimiz herhangi bir özelliği olarak tanımlayabiliriz. Örneğin ben yazılımcıların stres seviyesini ölçmek istesem - ki bu aslında uyku seviyesi, kandaki adrenalin, kan basıncı, nabız gibi tıbbi ölçümlerden çıkartabilecek bir şey - buna da "yumurta kapı indeksi" desem bu da bir ölçüm olacaktır.

Tabii yumurta kapı indeksini almak ne fayda sağlayacak sorusu ortaya çıkacak. Demek ki, bir ölçüm ancak bir şeye yararlı olacaksa alınmalı. Yani neyi ölçeceğimi düşünmekten önce neden ölçeceğimi düşünmek gerekli. Eğer yumurta kapı indeksine dayanarak bir karar alacaksak ve bu projeye yararlı bir işe yarayacaksa o zaman yumurta kapı indeksini ölçmek anlamlıdır.

Peki insanlar ne gibi şeyleri ölçmeyi anlamlı bulmuşlar? İlk akla gelen ölçümler şu türde ölçümler

• Yazılan satır sayısı bir projenin büyüklüğü için geçerli bir ölçüm. Elbette bunu elma ile armutu karşılaştırmadan yapmak gerekli. Çünkü özellikle bileşen tabanlı çalışılan araçlarda, bir bileşenin nasıl kullanılacağını belirlemek, onun çevresi ile olan etkileşimini ayarlamak gibi işlemler çok fazla satır üretmese dahi çok fazla zaman alabiliyor. Bu nedenle bir Python projesinin satır sayısı ile bir diğer Python projesini karşılaştırmak anlamlı. Benzeri biçimde bir iş yazılımı bir diğer iş yazılımı, bir gömülü yazılım da bir başka gömülü yazılım ile karşılaştırılabilir. Bu ön kabulü yapmadan, satır sayısı (line of code - LOC) ölçümünü temel alan diğer ölçümleri tartışmak anlamını yitiriyor.
• Satır sayısından sonra en çok tartışılan ama en çok referans alınan ikinci ölçüm de kodun karmaşıklığı üzerine. Kodun karmaşıklığı (İng. cyclomatic complexity) o kodun bakımının ne kadar zor olduğunu ortaya koyduğu için önemli. Karmaşıklığı yüksek kod parçalarını tespit edip daha sonra bunları daha anlaşılır ve daha kolay bakım yapılır kodlarla değiştirmek de önemli. Bu karmaşıklık oldukça karmaşık bir matematiksel teknik ile hesaplanıyor. Ancak bize çok basit bir sonuç veriyor. Bir kod parçasını test etmek için biribirinden bağımsız en az kaç test durumu (İng. test case) yazmamız gerektiğini bu karmaşıklık ölçümünden öğrenebiliriz. Elbette hiç bir ölçüm bize bu testlerin hangileri olduğunu söylemez yada iki testin bağımlılığını nasıl saptayacağımızı belirtmez. Ama en azından bir sayıyı elde etmiş oluruz.
• Satır sayısından elde ettiğimiz bir diğer türetilmiş ölçüm de her bin satır (KLOC) başına düşen hata (bug) sayısıdır. Örneğin 100 KLOC uzunluğunda ve her KLOC başına tespit edilen 1.2 hata düşen bir projede 120 tane hata olduğunu anlamış oluruz. Burada önemli bir şey de bu sayının bir yerden sonra kestirilebilir olduğudur. Örneğin 80 KLOC uzunluğu için 1.2 hata bölü KLOC metriğini elde etmiş isek, ve projenin 120 KLOC'a büyüyeceğini de (başka bir şekilde) tahmin ediyorsak, o zaman geri kalan zamanda 120 - 96 = 24 tane daha hata olacağını tahmin edebiliriz. Bu da bizi bir anlamda hazır kılar.
• Hazır hata demişken. Bir hata tespit edildiğinde onu düzeltmenin ne kadar zaman aldığı da önemli bir ölçüm olabilir. Buradaki zaman harcanan zaman değil, hatanın tespitinden kapatıldığının test edilerek onaylandığı zamana kadar geçen süreyi kast ediyoruz. Yani belki bir hatayı düzeltmek için yapılan iş 1 saat almıştır ama o 1 saatin gelmesi için 2 ay beklenmiş olabilir. Bu durumda hata 2 ay açık kaldığına göre, ortalama çıkartılırken de bu 2 ay göze alınmalıdır. Bu tür bir ölçümün o hatadan etkilenen insan sayısı, hatanın önemi gibi sayılarla çarpılarak ağırlıklandırılmış biçimde kullanılması da mümkün olabilir. Ama benim gördüğüm hata takip sistemleri düz zaman ortalamasını veriyor.
• Hatanın kapatıldığının onaylanması demişken test sözcüğünü kullandım. Madem test yapıyoruz, acaba testler toplam geliştirme zamanının ne kadarını alıyor? Bunu ölçebilir miyiz? Örneğin bir sistemin entegrasyon ve kabul testlerini işletmek 12 saat alıyorsa ve bu süre pek de inecek gibi değilse o zaman bizim için günlük inşa almak anlamlı olmaz. Çünkü işin felsefesi gereği günlük inşa, her gün alınır ve kabul testinden geçer. O zaman haftalık inşa almaya karar verebiliriz. Bakın bir ölçümü kullanarak bir karar verdik.

Benim için önemli bir ölçüm de ölçüm yapmanın maliyeti ile ölçüm yaparak kazanılanların oranı. Eğer bu oran 1'den küçükse, maliyetin, faydadan az olduğunu görüyoruz. Bu da ölçüm yaparak kazanç elde ettiğimizi gösteriyor. Eğer bu oran 1'den büyükse, bu sefer acaba ölçüm yapmasak ne olurdu sorusunu sormak mümkün.

Hemen kısaca özgür yazılımlara değinecek olursak durum nedir? Sourceforge gibi siteler, aslında özgür yazılım projelerine çeşitli ölçüm becerileri veriyorlar. Ancak bu becerilerin ne derece kullanıldığından emin değilim. Apache projeleri gibi daha sağlam yürütülen projelerde ise ölçüm alınması ve değerlendirilmesi rutin bir iş. Yani bir heterojenlik söz konusu. Öte yandan ticari yazılım projelerine baktığımız zaman da kapalı kapılar ardında kimin ne derece ölçüm yaptığı da tartışılır.

TVQ içinde makul miktarda ölçüm becerileri için iki iterasyon - yani dört ay - süre olacak. İterasyon planına gelmeden önce, gereksinim belirleme aşamasında bu ölçümler hakkında tek tek tartışıp bir sürü fikir üreteceğiz. Ekiptekiler de bloglarından mümkün olduğunca bu fikirleri paylaşacaklar. Bakalım - hayırlısı diyelim.

Yaz ayları içinde TOBB ETÜ'den gelen üç uzun süreli stajyerimiz, Halil'in koordinasyonu altında, TVQ'nun belli bölümleri için çalışıp oldukça güzel çalışan bir görev yönetimi sistemi kurmuştu. Daha sonra da ODTÜ Bilgisayar Mühendisliği'nden gelen stajyerlerimiz bazı grafik öğelerin, örneğin bir Gannt şemasının kurgulanması için uğraşmışlardı.

Halil bir kaç haftadır diğer işlerinin arasında TVQ'nun var olan kodlarını temizledi ve düzenledi. Şu anda örnek bir Struts2 / Hibernate uygulaması olmuş durumda. Önümüzdeki günlerde SVN'deki kopyasını genel erişime açacağız. Böylece küçük de olsa bir özgür yazılım hayata geçmiş olacak.

Bununla birlikte TVQ cephesindeki esas gelişme önümüzdeki 15 ay içinde yaşanacak. Yaz aylarındaki deneyimimizden elde ettiğimiz bilgiler ile çok daha kapsamlı bir geliştirme projesini ölçüp biçerek kestirme şansımız oldu. Toplam 75 adam-ay maliyeti olacağını öngördüğümüz, bir geliştirme projesi olarak TVQ'yu daha kapsamlı bir hale getireceğiz.

TVQ böylece bizim kendi içimizdeki yazılım mühendisliği ve yönetimi girişimimiz için bir bayrak gemisi ürün haline gelirken (böylece kendi içimizde yazılım mühendisliği alıcı bulurken), özgür yazılım ürünleri arasında doğrudan yazılım kalitesine dönük araç eksikliğini de giderecek. Projeye resmi başlangıcı Ekim ayı başında, Ramazan Bayramı dönüşü vereceğiz. Projenin kendi yürütülmesi için kendi iç ağımızdaki araçlara ek olarak, kullanıcılar, katkıcılar ve dışarıdan destek verebilecek olan geliştiriciler için ayrı bir site ve arayüzleri de Ekim - Kasım aylarında devreye alacağız. Aynı arayüzler içinde TVQ'nun periyodik inşalarını da alıp kurmak mümkün olacak. Şimdilik herhalde haftalık inşa alırız. Daha sonra projedeki Maven işleri oturdukça, yavaş yavaş gecelik inşaya kadar ilerleriz.

Bu arada TVQ'nun test edilmesi sırasında oldukça kapsamlı test durumları yazmayı planlıyoruz. Bu durumların test edilmesi için test planlaması ve işletimini de dikkatli yürütmek gerekli. Daha önce kullanmadığımız bir iki Alphaworks ve Tigris projesi kullansak fena olmaz.

TVQ konusunda önümüzdeki aylarda benden, Halil'den ama henüz bloglarını çok da aktif kullanmayan Cansu ve Billur'dan yada Gülşah'dan da çok yazı görebilirsiniz. Bakalım. hayırlısı diyelim.