Bu yazıda, ürün yada süreç metrikleri olarak ayrılan metrikleri, başka bir biçimde de sınıflandırıp incelemek niyetindeyim. Yeni sınıflandırmamızdaki ayrım yaklaşımdan kaynaklandığı için, siz okurlara aradaki farklar pek net gelmeyebilir diye çekiniyorum. Bu yüzden uzun bir yazı olabilir. Nefesinizi tutun, başlıyoruz…
Metrikler bir şekilde ürün yada süreçlerimizi ölçmek amacıyla kullandığımız kantitatif değerlerdir. Biz kendi üretim sürecimiz içerisinde, neleri ölçmek ihtiyacı hissediyorsak, bu konu ile ilgili metrikleri oluşturur ve sürekli takip ederiz. Kimi ekipler için önemli olan bir metrik, diğer ekipler için önemli olmayabilir. Bu sebeple, metrikler kullanıldıkları ekip içerisinde ve amaçlarıyla anlam kazanırlar.
Metrikleri süreçlerimizi yada ürünümüzü “kontrol etmek” yada “denetlemek” için kullanırız.
“kontrol” ve “denetleme” arasındaki farkı belirtmekte yarar var tabii. Kontrol, bir şeyi sürekli gözetim altında tutmak demektir. Denetleme ise, süreli ve kesikli gözlemler ile bir şeyin durumundaki değişikliklerin gözlemlenmesidir.
Gündelik dilde kullandığımızın aksine, yönetim bilimine baktığımızda, kontrol ve denetleme böylesine keskin bir ayrıma sahip iki farklı kavram olarak karşımıza çıkar. Bir süreci, sistemi yada metayı yönetmek maksadıyla bu yöntemlerden birine başvurulabilir. Yönetim bilimi, genelde sürekli kontrolü lanetlese de, değişim noktalarında kontrol, denetlemenin ötesinde vazgeçilmez bir araç olarak karşımıza çıkmaktadır.
(DEVAM EDIYOR)
“Yazılım testi” dendiğinde herkesin aklına birşeyler gelebilir. Kimileri yeni mezun arkadaşlara yaptırdıkları ve böylece yükümlülüğünden kurtuldukları bir aktivite, kimileri ise yazılım üretiminin artık sonu geldiğini hatırlatan bir “iş” olduğunu düşünebilir. Ben ise bunun dışında şeyler düşünüyorum.
“İyi yazılım testi” kavramını tanımlamadan önce, yazılım testinin bazı amaçlarını sıralamamız gerekiyor.
Kabul etsek de etmesek de test ekiplerinin temel motivasyonu, hata bulmaktır. Evet “hata bulmadan da iyi test yapılabilir, uygulamanın iyi olduğundan emin oluruz” diyenler olduğunu duyuyorum. Gerçek hayatta ne yazık ki kazın ayağı öyle değil. Yazılımda hata bulunamaması, sadece yazılım üretim süreçlerine mahsus olmayan sebeplerle, bazı diğer şeyleri tetikleyecektir. Örneğin testlerin durdurulması gibi. Nedense şöyle birşey söylemek geldi içimden : “Zaten bu yüzden test mühendisleri iyi test yapmak zorunda değil mi?”.
O halde Test Mühendisi nerede hata bulabileceğini bilmelidir! Evet, otomativ sanayiinde, üretim hatalarını ppm (pieces per million) ile ölçüyor olabilirler. Kabul aşamasında ve ekipçe cleanroom ile çalışmış olsak bile, bin test vakası başına bir onda küsur hata gibi bir oranla çalışıyorsak, ”hata bulamamak soru işaretleri oluşturur” demek garip gelmemeli. Bunu tabii ki test mühendisi, bilgi ve deneyim yoluyla ve zaman içerisinde geliştirerek öğrenir. Lütfen diğer yolları unutun! (DEVAM EDIYOR)
Yakın zamanda yazılım üretimi konusunda çeşitli standartların sektörde popülerliğinin arttığını gözlemliyoruz. Özellikle bazı devlet ihaleleri için CMMI L3, kimileri için ISO varyantları talep edildiği için, bir çok firma şu anda harıl harıl denetlemelere hazırlanmaktalar.
Bunun sevindirici bir gelişme olduğu hususunda, okuyucuya katıldığımı belirtmek istiyorum. Lakin uygulamada bazı pratikleri gözlemlemem, temel bazı hataların yapıldığını farketmeme ve akabinde bu çalışmaların kısır kalacağı yönünde bir kaygı geliştirmeme sebep oldu.
Birçok standart, bazı süreçlerin uygulanmasını şiddetle vurgulamakta. Bu vurgunun temeli, bu süreçlerin yazılım geliştirme döngüsünün olmazsa olmaz parçaları olmasından kaynaklanmakta. Yazılım geliştiren firmaların bu vurgulanan süreçlere yaklaşımları, genelde hali hazırdaki geliştirme biçimlerini değiştirmeden ve bu “ek” süreçleri, paralel yürüyen ayrı bir akışa devretmek şeklinde. Örneğin, evet, projenin risk analizi yapılmış durumda. Fakat bu analiz, yazılım geliştirme sürecinden bağımsız olarak, kodlamanın bitimine yakın, paralel bir biçimde ”yapılmış” ve standardın belittiği biçimde dosyalanmış.
Böyle durumlarda başladığım uzun ve sıkıcı konuşmamın bir özetini de buraya bırakmak istiyorum. (DEVAM EDIYOR)
Belkide son beş senedir yazılım mühendisliğinin her alt dalının sertifikasyon programları ile sulandırıldığını iddia ediyordum. Yakın zamanda saflarıma Cem Kaner‘i de kattıktan sonra, bu konudaki sesimi yükseltmeye karar verdim.
Üç sene öncesinde, Türkiye’nin belki de en innovatif ekibinde ArGe yöneticisi olarak görev yapmaktaydım. Söz konusu sertifikasyon sorunları ile sıcak temasım, bu görevim sırasında başladı. Yayınladığımız her iş ilanına çeşitli eğitim kurumlarından konu ile ilgili sertifika almış insanlar başvuruyordu.
Böyle bir pozisyonda, kararınızı verirken şunu aklınızda tutmalısınız. “Bir işletmede işleri kurduğunuz sistem yönetiyor olabilir. Lakin her işletmede işleri insanlar yapar. Bu sebeple işletmeler, en iyiler ile çalışmak zorundadır.”
Böyle bir durumda veri tabanı tasarımızı, 3 ay eğitim görmüş ve 70 soruluk, çoktan seçmeli bir bir sınavda %75 başarı göstermiş birisine yaptırmak, benim pek içime sinen bir durum değildi ne yazık ki. (DEVAM EDIYOR)
Çeşitli yerlerde, birçok kişi ile bir araya gelip sohbetler ediyoruz. Bu sohbetler sırasında, genelde yazılım kalitesi sohbetlerimizin odağını oluşturuyor. Çoğu arkadaşım, kendi yazılım üretim biçimlerine, kalite ile ilgili çözümleri ne şekilde eklemeleri gerektiğini soruyorlar. Zira özellikle test aktiviteleri, diğer yazılım süreçlerine sıkı sıkıya bağlı aktivitelerdir.
Bu tip sorulara genelde yanıt olarak, deneyip gördüğüm ve fikren sayın Spolsky’den aşırdığım bir yanıtı tekrarlıyorum. “İş planı yapın ve güncel tutun. Lakin her koşulda, takvimizdeki işlerin sürelerini saat cinsinden verin. Eğer bir işin alacağı süreyi saat cinsinden veremiyorsanız, daha küçük parçalara bölün.”
Yanıtın bu kadar absürd olmasının sebebi, aslında testin kendi iç dinamiklerinden kaynaklanmakta. Yazılım hataları “Yazılımın tanımlananın dışındaki davranışlarının tümü” olarak tanımlanır. Eğer uygulamanın ne şekilde davranacağını belirlememiş iseniz yada bir şekilde belirlenmemişse, hata bulmanız biraz güçtür. Burada bir şekilde belirlenmiş davranışlardan kastımız, sektör gelenekleri ve hayatın gerçekleri tarafından (bkz: psikoloji) belirlenen “beklenen” davranışlardır. Örneğin kullanılabilirlik ile ilgili birçok hata bu “genel” pratiklere dayandırılır. Bir formun “Gönder” butonunu formun tepesine koyuyorsanız, bu açıkça tanımlanmasa dahi, bir kullanılabilirlik hatasıdır.
Detaylı bir iş takvimi yapılması ve sürekli olarak bu takvimin güncel tutulması, ekibi uygulamayı tasarlamak konusunda zorlayacaktır. İçeriğini ve detaylarını bilmediğiniz bir yazılım için “saatler ile süreleri belirtilmiş görevler” belirleyemezsiniz. Evet dokümante edilmiş bir tasarımınız olmayacaktır ama en azından üzerinde düşünülmüş bir yazılımı üretiyor olursunuz.
Kaliteli yazılım için işte ilk adım budur.
Uzun bir çalışmanın ardından konuşmam için İstanbul Bilişim Kongresi‘ne iki günlük uykusuzluk ile gittim. Hem konuşmakta zorluk çekerim düşüncesiyle yazdığım konuşma metnini okurken hatalar yaptım, hem de sunum ile konuşmamı senkron ilerletemedim. Bu içeriği istediğim şekilde paylaşamadığım için konuşma metnimi(386K) ve sunumumu(8.5MB) buraya koymak istedim.
Şu anda Özay Civelek'in kişisel web logunu okumaktasınız.
Bu sitede büyük oranda yazılım kalitesi, yazılım geliştirme süreçleri, programlama ve birkaç diğer konuda yazarın fikirlerini okuyabilirsiniz.
![Freakonomics [Revised and Expanded]: A Rogue Economist Explores the Hidden Side of Everything](http://ecx.images-amazon.com/images/I/51Z1scnqz1L._SL160_.jpg "Freakonomics [Revised and Expanded]: A Rogue Economist Explores the Hidden Side of Everything")
