Yazılım mühendisliğinin yegane amacı yüksek kalitede bir uygulama üretmek olagelmiştir. Bunu başarabilmek için test edilip onaylanmış bir metod, yüksek kaliteli uygulama geliştirme araçları ile birleştirilerek yazılım süreçlerinde kullanılmalıdır. Günümüzde yazılım araçlarının çok ilerlediği bir gerçek; demek kaliteyi yakalamak için metodu doğru ve yerinde kullanmamız gerekiyor. Ayrıca metoda ne kadar sadık kalındığı ve tam olarak kullanılıp kullanılmadığı da bir etken olarak karşımıza çıkıyor.
Soru 1: Çalıştığınız yerde hangi metodun kullanıldığını biliyor musunuz?
Projelerin bir harala gürele ile başladığı ve Allah ne verdiyse kod yazmaya girişildiği bir yerde mi çalışıyorsunuz? Yoksa belli bir düzende müşteri gereksinimlerine bağlı kalınarak, dökümantasyon ve sürüm yönetiminin kullanıldığı bir ortamınız mı var? Çalıştığınız yerdeki yazılım geliştirme metodunu iyice öğrenip, işlerin nasıl dağıtıldığını, nasıl test yapıldığını, kod yazarken nelere dikkat edildiğini öğrenin. Belli bir düzen yok mu? O zaman siz bir düzen getirin. Metodun gerekliliklerini öğrenip uygulayın. Bu durumda hataların en çok hangi aşamada oluştuğunu bililmsel olarak ortaya koyabilirsiniz.
İstenen kalitenin elde edildiğini anlamak için proje boyunca oluşan hatalara göz atılabilir. Örneğin Use Case (Senaryo) kullanarak analiz yapıyorsunuz diyelim. Senaryolar bir kez onaylandıktan sonra gerekecek her türlü değişiklik bir hata demektir. Yada Yazılım Gereksinimleri Tanımlama belgesinde onaydan sonra oluşacak her değişiklik te hata statüsüne girer. Testler sırasında kodda yakalanan hatalar da bu durumdadır. Hata projenin her aşamasında ortaya çıkar; sadece kod üzerine odaklanmayın.
Her senaryo başına kaç hata düştüğünü, testler sırasında 1 saatte ne kadar hata yakalandığını ölçüp projenin kalitesi hakkında bir fikre sahip olabilirsiniz. Ayrıca Hata Düzeltme Hızı (HDH) her senaryo için ölçüldüğünde senaryoların boyutları ve içerdikleri zorluk seviyesi ortaya çıkartılabilir. Eğer bir senaryo için HDH zamanı uzunsa, kompleks bir senaryo ile uğraşıyoruz demektir (yada çok basit olduğu için analizcilere angarya gibi gelen bir iştir). Proje planında bu senaryo ve bağlı olduğu fonksiyonlar için daha fazla zaman ayırmanız yada senaryoyu düzeltmesi için analizcileri dürtmek gerekir. Projelerin kompleks kısımlarını anlamak için maliyet analizi de yapabilirsiniz. Modül yada senaryo başına maliyet analizi en fazla kullanılan tekniktir.
Proje maliyetlerinin çoğu son iki aşamada ortaya çıkar. Bunlar
- Ürün müşteride kullanılmaya başlamasından sonra destek aşamasında ve
- Ürünün farklı müşterilere ve sistemlere uydurulmaya çalışılması sırasında
Bu aşamalarda ortaya çıkacak hatalar da düzeltilmesi en maliyetli ve zor hatalardandır. Zaten kompleks ve zorlu olan bu iki aşama, ortaya çıkan hatalar ve uzun süren HDH zamanları ile içinden çıkılmaz bir hal alır. Bu sebepten dolayı zaten çoğu proje yöneticisi bu iki aşamayı proje planlarına dahil bile etmezler. Böylece kaliteyi yükseltmiş gibi gözükürler ama aslında projenin en önemli kısmını es geçmişlerdir.
Soru 2: Ürünün doğruluğu hakkında ne biliyorsunuz?
Bir program doğru olarak çalışmalıdır. Peki doğruluğunu nasıl anlayacağız. Şöyle; müşteri gereksinimlerine göre doğru çalışıyor mu test ederek (basit değil mi? Tabii müşteri ne istediğini biliyorsa). Bu testler sırasında ortaya çıkan toplam hata rakamı diyelim ki 3000 olsun. Proje başından beri yazılan kodun da 150,000 satır olduğunu düşünelim. Bu durumda 150,000*X=3000*1000 formülünden her 1000 satır için 20 hata olduğu ortaya çıkar. Tabii bu hataların hepsi ürün müşteri tarafında kullanılmaya başladıktan sonra müşteri tarafından girilen hatalardır. Kalite ölçümü için bellli bir zaman sürecinde bu hatalar toplanır, örneğin 1 sene gibi. Ürün müşteride kullanılmaya başladıktan sonra her 1000 satır için hata seviyesinin %1,5 ile %2 arasında olması gerekir ki ürünü kaliteli bir ürün olarak farzedebilelim. Eğer hata sayısı üst limitlerde geziyorsa ki örneğimizde öyle, hata sayısını alt limitlere çekmek için çalışma yapılmalıdır.
Ayrıca modül başına düşen hata sayısı ve modüllerin boyutu göz önüne alınarak, kompleks fonksiyonlara daha fazla zaman ayrılmasının sağlanması gerekir.
Soru 3: Ürünün ilk sürümünden sonra gelen istekleri ve hataları ne kadar zamanda düzeltiyorsunuz?
Ürün müşteriye sunulur ama proje bununla bitmez. Bir destek ekibi 7/24 problem çözmek için didinir durur. Bu aşamada oluşan hata, istek ve entegrasyon problemlerine cevap verme hızı ürünün kalitesini belirler. Madde halinde sıralarsak:
- Ürün müşteriye sunulduktan sonra çıkan hataların düzeltme hızı
- İstenen değişikliklerin analizi, uygulanması, testi ve müşteriye sunulması sırasında geçen zaman ve
- Ürünün farklı sistemlere entegre edilmesi veya değişen ana sistemle birlikte ürünün de buna ayak uydurması için yapılacak değişikliklerin uygulanma hızı.
Genel bir ölçüm birimi olmasa da bu zamanların ölçülüp grafik haline getirilmesi ileride çıkacak hata, istek ve entegrasyon istekleri için tahmin edilecek zamanların daha gerçekçi olmasını sağlayacaktır. Projenin boyutuna ve yoğunluğuna, müşteri sayısına ve hizmet veren programcı, testçi, analizci vb gibi proje sahiplerine bağlı olarak her proje için farklı bir gösterge ortaya çıkması doğaldır.
Soru 4: Ürün ne kadar güvenli?
Ürünün korsan saldırılarına karşı ne kadar güvenli olduğu da bir kalite göstergesidir. Korsan saldırıları direk programa, veritabanına veya belgelere yapılabilir. Bu üç öğenin kendini koruyabilmesi ve saldırılardan yara almadan kurtulması ürünün gevenliliğini gösterir. Kod ve Rol seviyesinde güvenlik mekanizmalarının kurulması, şifreli bilgi alışverişi için ortamın ayarlanması, sistemlere ulaşan kişilerin izlenmesi ve kayıt edilmesi gerekir. Ürünün çalıştığı sistem yöneticiler tarafından göz altında tutulmalı ve şüpheli durumlarda otomatik uyarıcı modüller eklenmelidir. Örneğin her isteyen cumhurbaşkanının vergi kayıtlarını görmemelidir.
Güvenlik tam olarak ölçülecek bir birim değildir ama günde 10 kere saldırıya uğrayan bir sistemin her seferinde yara almadan kurtulduğunu bilmek müşteri için rahatlatıcı bir unsurdur.
Soru 5: Ürünün kullanılabilirliği hakkında ne biliyorsunuz?
Her yeni yazılım ürünü yada eklenen özellik beraberinde belli bir öğrenme süreci getirir. Bu öğrenme sürecinin uzunluğu:
- Kullanıcının entellektüel bilgi seviyesine
- Ürün ile yararlı bir şeyler yapacak seviyeye gelmek için geçen zamana
- Yararlı bir şeyler yapacak seviyeye gelmekten tam üretken olacak zamana kadar geçen süreye bağlıdır.
Kullanılabilirlik tamamı ile müşteriden müşteriye değişecek bir etkendir. Fakat ürünün arayüz tasarımı, komutlara karşı verdiği cevaplar, tahmin edilebilirliği, hata durumlarında verdiği yanıtlar ve bir çökme durumunda üzerinde çalıştığı veriyi bozmadan bir önceki haline geri dönebilmesi kullanılabilirliği arttıran unsurlardır.
Müşteri genelde ürünü hataları ile beraber öğrenir ve bu hatalara karşı defans geliştirir. Yani program müşteriyi yönetmiş olur fakat verinin bütünlüğü veya sistemin güvenliği tehlike altına girer. Bu tür durumlara yer vermemek amacı ile kullanılabilirlik testlerinin bağımsız kişiler tarafından yapılması gerekir.
Yazılım süreçlerinde bu metriklerin yerleştirilmesi ve kullanılması oldukça güç bir iştir. Hele ki firmada geçmişte herhangi bir metrik tutulmadıysa daha da zor olacaktır. Fakat şunu düşününki eğer ölçüm yapmazsak ilerlediğimizi anlayamayız. Ben örneğin her body building salonuna gidişimde bir defter ve bir kalem bulunduruyorum ve kaldırdığım ağırlığı not ediyorum. Örneğin 1 aylık Türkiye tatilinden sonra eski performansıma kavuşmam bir ay gibi bir zaman aldı. Ağırlıkları yazmasaydım bunu bilemeyecektim. Öte yandan limitlerini bilmek ve biraz daha sınırları zorlamak için de tuttuğum kayıtları kullanıyorum. Örneğin uzunca bir süre aynı kiloda biceps yapıyorsam bir daha ki antrenmanda 1 kilo arttırıyorum ve aldığım tepkilere dikkat ediyorum.
Proje zaman çizelgelerinde bu şekilde kompres yoluna gidilebilir ama mutlaka bir önceki metrik ölçümler göz önünde bulundurulmalıdır. Yoksa yapılan kompres anlamsız olacaktır. 5 gün sürecek bir işi 2 günde bitirebilmek için yapılan kompres eğer metod olarak önceki metriklere dayanmıyorsa pek bir anlam ifade etmez.
Sonuç
Bir firma içinde yazılım süreci boyunca her proje için belli metriklerin tutulması gerekir. Bu kayıt tutma alışkanlığı ileride alınacak projelere ve zaman çizelgeleri için tahmin edilecek sürelere bir ışık tutar. Proje bazında kaliteyi ölçmek için belli rakamlar almamızı sağlar. Bu metrikler sayesinde elle tutulur bir kalite anlayışına sahip oluruz ve daha da arttırmak için neler yapmamız gerektiğini daha açık görebiliriz. Yoksa yazılım sürecimiz bir kör dövüşüne döner ki piyasada uzun süre kalmayı düşünen bir firma için hiçte iyi bir şey değil. Uzun süreden kastım öyle 15 yada 20 yıl değil. 100 yada 150 sene ortamın değişikliklerine ayak uydurabilmiş ve ürünü ile sürekli devinim içinde gelişmiş ve kaliteyi de ön planda tutmuş bir firmadan bahsediyorum.
Gene hiç resimsiz bir yazı oldu ama idare edin.
