Kalite#2 — Yazılımda kalite nedir?

mehmet baran
Bilişim Hareketi
Published in
3 min readJul 15, 2018

Daha önce de bir yazı yazmıştım yazılım kalitesi ile alakalı. Bu yazıda ise yazılım kalitesi konusunu daha ayrıntılı bir biçimde inceleyeceğiz. İşe öncelikle kalite kavramı ile başlayabiliriz.

Kalite aslında çok geniş bir kavram olup tarih boyunca defalarca tanımlanmaya çalışılmıştır. Ürün veya hizmete bağlı olarak tanımı değişebilir. Fakat en genel tabiri ile müşteri isteklerini önceden tahmin ederek, müşteri beklentilerini karşılamak ve ötesine geçmek, ürünün doğal yaşamı boyunca müşteriyi memnun etmek olarak tanımlanmaktadır(1).

Herhangi bir üründe olduğu gibi bir yazılım içinde kalitenin ölçüsü müşterilerin üründen memnuniyetidir. Müşteri denince akla genelde yazılımı kullanan veya satın alan müşteriler anlaşılır. Fakat biz müşterileri 3 gruba ayırıp, buna göre beklentilerini ve taleplerini inceleyeceğiz.

Birinci grup, dış müşteriler diyebileceğimiz ürünü doğrudan kullanan tüketicilerdir. Yani bir bankanın internet veya mobil şubesini kullanan bankacılık müşterisi, bir e-ticaret sitesinin sepetine ürün ekleyen müşteri, Whatsapp-Facebook-Twitter kullanıcıları bu gruba girer.

İkinci grup ise yazılımın iç kullanıcılara bakan kısımlarını kullanan iç müşterilerdir. Gişede çalışan bankacı, sipariş şikayetlerine yanıt veren operatör birer iç müşteridir.

Bu iki grubun yazılımdan beklentileri yazılımsal anlamda neredeyse aynıdır. Yazılımın kullanışlı, kolay, anlaşılır olmasının yanısıra performanslı ve sorunsuz çalışması çoğu kullanıcıyı memnun edecektir. Odak noktamız yazılım mimarisi olduğu için bu iki müşteri grubu üzerinde daha fazla durmayacağım.

Bizim için asıl önemli müşteriler, yazılım mimarimizi kullanarak üst seviye uygulamalar geliştiren yazılım geliştirme ekipleri ve bu süreçlerin tamamında maliyetlere katlanan yatırımcılardır.

1. Taleplerin karşılanması

Yazılımın kod kalitesinden daha önemli birşey var ise o da kesinlikle müşterinin taleplerinin karşılanmasıdır. Aksi durumda hiçbir işe yaramayan mükemmele yakın bir yazılım mimarimiz olsa bile karşılığı olmaz.

Geliştirdiğimiz ürün müşterinin ihtiyaçlarının tamamını eksiksiz gidermelidir. Bazen yazılımcılardan şunu duyarız: “Bu özelliği destekleyemeyiz”. Yani ben bir yazılım yaptım bunu değiştiremem fakat siz işi buna uydurabilir misiniz? Bu şekilde olmaz tabiki.

Özetlemek gerekirse müşterinin iş ihtiyacına uygun bir gereksinim analizi yapıldıktan sonra bu taleplerin tamamının eksiksiz bir şekilde karşılanması gerekir.

2. Geliştirilebilirlik

Yazılım bir defa satılan ve sonsuza kadar müşteriyi mutlu eden birşey değildir. Zaman içerisinde yazılımda ortaya çıkan hatalar, müşterinin yeni fark ettiği ihtiyaçları, iş süreçlerinin zaman içerisinde değişmesi, yasal düzenlemelerden kaynaklanan değişim ihtiyaçları gibi birçok sebepten dolayı yazılım üzerinde değişimler gerekecektir.

Bu değişimler bazen çok kolay olabilirken bazen ise tabiri caizse en alttaki taşın çekilmesi anlamına gelmektedir. Bu zor senaryolara yakalanmamak için yazılım mimarisinin baştan uygun kurulmuş olması gerekir.

İşte yazılım kalitesini gösteren en önemli detay burada gizlidir. Yazılım geliştirilmeye uygun olmalıdır. Her an hiç ummadığımız yerlerden değişiklik talepleri gelebilir.

Daha sonra işleyeceğiz ama Open-Closed Prinsiple aslında bu konu ile ilgilidir. Ben OCP’yi çok daha geniş bir bağlamda ele alıyorum. Yani desenlere sıkıştırmak istemiyorum. Yazılım prensipleri arasında en geneli bu prensip olabilir. OCP kodlarınızı değişime kapatıp geliştirmeye açık tutmanızı söyler kısaca. Bunu birçok yazılım deseni ile sağlayabiliriz. Bunları daha sonra detaylı olarak işleyeceğiz.

Kısaca; yazılımımız geliştirilebilir olmalıdır. Müşteri talepleri bizi stresli günlere-gecelere soksun istemiyorsak bu konuya azami özen göstermemiz gerekiyor.

3. Maliyet

Bir diğer husus ise yatırımcıların yani patronun memnun edilmesidir. Maliyetleri kontrol altında tutabilmek gerekir. Birçok yazılımcı geniş zaman aralıklarında iş yapmak ister. En azından eğilimi bu yöndedir. Patronlar ise minimum maliyet prensibi ile düşünürler. Burada ortak bir noktada buluşmak gerekiyor.

Proje yöneticilerinin projelere zaman ayırırken zamanın bir noktaya kadar kalite ile doğrudan orantılı olduğunu unutmamaları gerekir.

Sonuç

Kalite asla tesadüf değildir. Ancak bilinçli bir çabanın sonucudur. John Ruskin

Prensipler, desenler gibi teknik konulara girmeden önce bu konulara nerelerden geldiğimizi kısaca açıklamak istedim. Çok kısa olmasa da umarım keyifle okumuşsunuzdur. Varsa önerileriniz lütfen paylaşın.

--

--