Bu aralar The Idea Factory içerisinde Bell Labs çalışanlarının etkileyici hikayelerini okurken kalite kontrol süreçlerinin ortaya çıkması ve tarihsel sürecini de kendimce harici okumalar ile araştırıyordum.
Bu sürede Martin Fowler ’ın Is High-Quality Software Worth the Cost? yazısında rastladım. Her zamanki gibi bizleri anlattıklarına ikna eden Sayın Fowler Piyasada aynı işi yarı fiyatına yapanların iyi mi kötü mü yaptığını özetlemiş.
Bell Labs’tan çıkan kalite kontrol kavramının kısa tarihi ve yazılımda kalite konusunda içimden geçen fikirleri içeren bir yazı paylaşmak istedim.
Fizikçiden Çıkan Kalite Kontol Yönteminin Endüstriye Örnek Olması
Kitabı okuyarak AT&T şirketinin o dönemde neler yapmaya çalıştığını daha ayrıntılı öğrenebilirsiniz ama ben konuya giriş yapmak için dönemi sizlere biraz özetlemek istiyorum.
…Birkaç kilometreden iletişim kurmak için ürün geliştirmeye başlayan, önce amerikayı baştan sona daha sonrada dünyayı birbirine bağlayacak bir sistem geliştirmeye çalışılırken ortaya çıkan ürünlerden bir tanesiydi Teletype. Ürün için daha önce geliştirilmiş bir tuşun daha da verimli hale getirilmesi adına bir yağlama mekanizması ve yay üretilmesi gerekiyordu…
İletişim bu dönemde birçok karmaşık problemi barındırmakta olan bir sistem olarak tarif edilmekteydi.
Endüstriyel süreçlere ve ürünlere uygulanan “ kalite kontrol ” temelleri 1924 yıllarında Walter A. Shewhart tarafından bu sistem içerisinde çalışırken atılmıştır.
Ortaya çıkışındaki belirgin sebeplerin başında insanların kaliteli ürüne hasret kalması ve 2. Dünya savaşında askeri alanlarda kaliteli ürünlere ihtiyaç duymasıdır.
Walter A. Shewhart’ın Öğrencisi
Walter A. Steward’ın öğrencilerinden W. Edwards Deming 2. Dünya savaşı sonrasında Japonya’da gerçekleştirdiği işler Japonya’nın endüstirisine örnek teşkil etmiş ve ekonomik olarak Japonya’nın dünya sıralamasına girmesini sağlamıştır.
Deming “ İstatistiksel Ürün Kalite Yönetimi ” adıyla yaptığı konuşma ve gerçekleştirdiği işler ile Japonya’nın savaş sonrası ekonomik kalkınmasının öncülerinden olmuştur. Japonya küllerinden yeniden doğarken Deming’in sözleri yol gösterici olmuştur.
Deming’e göre kalite kapsamında;
Daha iyi ürün tasarımı daha iyi hizmet.
Ürün kalitesinin sürekli olarak mümkün olan en yüksek seviyede tutulması.
Ürün testlerinin iyileştirilmesi
Global pazardan daha çok pay alabilmek.
gibi maddeler yaklaşımının ana başlıkları idi.
Yıllar içerisinde endüstride kullanılacak birçok ürün/hizmet kalitesini ölçmeye ve yükseltmeye yönelik yöntemler bulundu.
Bunların birçoğu ile karşılaşmamış olmak veya süreçlerin içerisinde olmamak ürün geliştiren bir takım için imkansızdır(!)
Şimdi biraz daha, yazılım süreçlerine dahil etmeyi en azından planladığımız ya da hayal ettiğimiz kalite konularından bahsedelim.
Kaliteli Bir Yazılım
Yazılım mühendisliği yaklaşımına göre kalite konusu birbiri ile ilişkili iki farklı kavram ile incelenmektedir.
Bu kavramlardan birisi functional-requirements diğeri non-functional-requirements olarak adlandırılır.
Tam tanımın olmasada kısaca functional-requirement bir ürünün yapmayı amaçladığı işe odaklanırken, diğeri amaçladığı işi yaparkenki yapısal durumuna odaklanmaktadır.
Yani basit bir örnek ile açmak gerekirse;
Müşterimizin bir istatistiksel hesaplama aracı programına ihtiyacı olduğunu varsalayım.
Bu program içerisinde yer alması gereken talep ettiği fonksiyonlar ürünün functional requirement’larını ifade etmektedir.
Kodunuzun sağlamlığı, test edilebilir ve yönetilebilir olması non-functional requirement’ların konusudur.
Martin Fowler’ın Internal ve External Olarak Böldüğü Kalite
Eğer bir yazılımın kalitesi hakkında konuşacak olursam, bunun ne olduğunu açıklamam gerekmektedir.
İlk karmaşa bunun altında yatmaktadır. Yazılım için kalite kriteri olarak sayılabilecek bir çok şey bulunmaktadır.
Yazılım mühendisliği kapsamında işlenen quality metrics konusunda bir yazılım ürününün nasıl ölçülmesi gerektiğini anlatmaya çalışıyoruz fakat kalite kavramına nasıl yaklaşılması gerektiğini anlatırken soyut kalan noktaları quality assurance konusuna kapsamlı olarak girdiğimizde tamamlayabiliyoruz.
Müşterimizin ilgilendiği kısım kendi ihtiyaçları doğrultuğunda problemini çözebiliyor olması veya bir işi daha kolay yapabiliyor olmasıdır.
Bizlerin bu yazılımları üretirken hangi mimari ile geliştirdiğimiz müşterilerimiz tarafından görülmemektedir.
Bu sebep ile kalite özelliklerinin ikiye ayrılabildiğinden bahsetmiştir
external : UI and defects (kullanıcı arayüzü ve kusurlar)
internal : Architecture (mimari)
Internal Quality konusu müşterilerimiz için bir anlam ifade etmesede, müşterilerimiz yeni özelliklerin hızlı bir şekilde almayı gerçekten önemsemekteler.
Müşterilerimize hızlı cevap vermemize engel olan internal quality’nin yetersiz olmasıdır. Buna da sebep olan gereksiz, düzensiz ve tecnical debt oluşturacak kod parçalarının fazla sayıda olmasıdır.
Sonuç
Öncelikle teknoloji tarihi ve yenilikçi düşüncelerin nasıl ortaya çıktığını merak eden ve bu konulara ilgili birisiyseniz bahsettiğim kitabı okumanızı tavsiye ediyorum.
Ayrıca hızlı ürün geliştirme ve kaliteden ödün vermenin detaylarından bahseden Martin Fowler' ın makalesini de orijinalinden okumanızı öneririm.
Bizler biliyoruz ki hem yazılım yönetimi hem kişisel olrak yazılımcılar bu ve bunun gibi bir çok karmaşadan muzdaripler. O kadar hızlı ürün geliştirmemiz gerekiyor ki sonuçlarını hepimiz acı tatlı yaşamışızdır.
Günümüzde bu hızı yakalamaya çalışırken, kalite standartlarına uyan yöntem yada kalite standartlarını kendilerine uyduran bir çok yöntemcik ile sarmalanmış durumdayız.
Soyut ve yönetilmesi zor olan yazılımda kalite konusunda, endüstri devrimi ile gelen kalitesiz ürün bombardımanına maruz kalındığı gibi günümüzde de kaliteden ödün veren bir çok ürün ile uğraşmak durumunda kalabilirsiniz.
Daha kaliteli ürünlerini global marketlere sunabilmek ve rekabet edebilmek için kaliteden ödün vermeyerek kısa ve uzun vadede trade-off’larını etraflıca düşünmeliyiz. Bize örnek olan olaylardan da dersler çıkararak uygulamamız kalite standartlarına uygun olarak geliştirmeye özen göstermeliyiz.
Top comments (0)