Winston Royce & Waterfall & Çeviklik
Bu makalede Winston Royce & Waterfall & Çeviklik konularına değineceğim. Geleneksel yazılım geliştirme metodunun babası Winston W. Royce, yazılım geliştirme alanında öncü olarak kabul edilir. California Institute of Technology’de Fizik Bölümü’nde lisans öğrenimini tamamladıktan sonra yine aynı enstitüde Havacılık Mühendisliği üzerine yüksek lisans yapmıştır. Julian David Cole’un gözetiminde yine Havacılık Mühendisliği alanında doktorasını tamamlamıştır. 1961 yılında ise ünlü otomotiv şirketi TRW’de çalışmaya başlamıştır. TRW, Türkiye’de otomotiv alanında bilinsede aslında havacılık üzerine de çalışmaları bulunmaktadır. Royce, TRW şirketinin havacılık ile ilgili geliştirmeler yapılan bölümünde proje yöneticisi olarak çalışmıştır. Bu dönemde yazılım projelerinin nasıl daha kolay, daha kaliteli ve daha ucuz geliştirilebileceğine dair çalışmalar yürütmüştür. Bu çalışmaları yürütürken akademik yaklaşımını sergilemiş ve yaptığı çalışmaları anlattığı “Managing The Development Of Large Software Systems” adlı makaleyi 1970 yılında yayınlamıştır. Royce’un makalesi yazılım ürünlerinin geliştirilmesi süreçlerine tarihteki en büyük etkiyi yapmıştır ve bu etki günümüzde de devam etmektedir.
Basit Metot
Winston Royce makalesinde açıkladığı yaklaşımlara herhangi bir isim vermemiştir. Bugün Waterfall dediğimiz metoda “basit” diyordu. 1976 yılında Bell ve Thayer adında iki TRW çalışanı “Software Requirements : Are They Really A Problem?” adında yayınladıkları makalelerinde Waterfall terimini ilk defa kullanmışlardır.
Royce’un makalesi incelendiğinde görülür ki sadece Waterfall -Royce’un deyimiyle basit– olarak bilinen modelden bahsetmez aynı zamanda artımlı ve modelleme yaklaşımlarını da anlatır. Sanırım artımlı ve modelleme yaklaşımlarını Waterfall’ın altında anlatması ve Waterfall’ın bunlara nazaran daha kolay bir sürece ve bakıldığında daha anlaşılır bir şekle sahip olması Waterfall’ın benimsenmesini kolaylaştırmış ve günümüze kadar gelmesini sağlamıştır.
Artımlı Yaklaşımlar
Artımlı ve modelleme yaklaşımlarını anlatırken Waterfall modeliyle ilgili problemlerin çözümünü aradığını görürüz. Bu amaçla modelleme yaklaşımında analiz aşamasından önce adına “Preliminary Program Design” dediği bir aşama koymuş ve burada projenin bir modelinin yapılması gerektiğini söylemiştir. Artımlı yaklaşımda ise yine Preliminary Program Design aşamasını koymuş ve bundan sonra gelen her aşamada aslında sürecin tekrarlanmasını savunmuştur. Bu yaklaşım günümüzdeki iterasyon bazlı geliştirme yaklaşımının temeli olmuştur.
Makalenin bir başka bölümünde ise aşağıdaki ifadeleri kullanmıştır.
“I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4.”
Bu konsepte inanıyorum fakat yukarıda bahsedilen implemantasyon riskli ve hatalara davetiye çıkarır. Problem Şekil 4’te gösterilir.
Royce’un yazısının devamında “basit” dediği model için şunu ekler; “sürenin ve/veya maliyetin belirleneni aşacağı beklenir” der.
Makalesinin son bölümünde sorunların çözümü için yaptığı önerilerinde günümüzdeki Çevik Pratikler’den biri olan Eşli Programlama (Pair Programming)’yı önerir. Yapılan her analizin ve geliştirilen her kodun ikinci bir kişi tarafından gözden geçirilmesi gerektiğini söyler. Ayrıca bu tarz işlemler için bilgisayarın kullanılmaması gerektiğini, bunun çok pahalı bir işlem olduğundan bahseder. Günümüzdeyse bu sorun ortadan kalkmıştır. Artık bilgisayarlar insanlardan çok daha ucuza ve doğru bir şekilde test işlemini gerçekleştirebilmektedir, bunun için otomatize edilmiş testleri kullanabiliriz.
5 Adım
Makalesinin “Özet” bölümündeyse “5 adım” dediği adımların arzu edilen ürünün elde edilmesi için kullanılmasının gereklilik olduğunu söyler. Şu şekilde devam eder; “Şunun altını çizmek isterim her biri -5 adım- ek maliyetlere neden olacaktır. Buna rağmen benim deneyimlerimde, büyük yazılım geliştirme çalışmalarında basit metot asla başarılı olmadı ve basit metot ile geliştirilen projelerin düzeltilmesi için harcanan maliyet 5 adımın kullanıldığı projelerden çok daha fazlasına mal oldu.”
Sanırım buradaki ek maliyetler ifadesi cimri patronlar arasında çok büyük bir etki yarattı. Bu arada cimri olmayan bir patron hiç görmedim. Bu etki cimri patronların yazılım projelerine harcanması gerekenden daha fazla para harcamalarına neden oldu.
Aslında Royce’un bu cümlesi derinlemesine irdelenmelidir. Bugün Çeviklik olarak bildiğimiz ve herkesin 2001 yılında 17 yazılım gurusunun bir araya gelerek oluşturduğunu söylediği yaklaşımın temelini Royce 46 yıl önce anlatmıştır. Peki, 46 yıl önce Royce’un gördüğü bu doğruyu nasıl olurda biz ancak 2001 yılında görebildik, bazılarımız ise hala görememeye devam ediyor.
Makalenin ilerleyen bölümlerindeyse farklı adımlar arasındaki iterative yaklaşımın başarılı sonuçlar elde ettiğini söyler.
Involve the customer, the involvement should be formal, in-depth, and continuing… Müşterinin sürece dahil edilmesi gerektiğinden bahseder.
Dokümantasyonun Önemi
Royce, dokümantasyona gereğinden fazla önem verir. Bunu şu cümlesiyle vurgular; “5 milyon dolarlık bir donanım için 30 sayfalık bir doküman beklerim, 5 milyon dolarlık bir yazılım ürünü için 1500 sayfalık bir doküman beklerim.”
Belki o günün şartlarında kapsamlı bir dokümantasyon yapılması gerçekten faydalı bir aktiviteydi. Belki o günün şartlarında projenin geliştirilmesi açısından gerçekten hayati bir önem taşıyordu fakat günümüzde yazılım çok daha karmaşık bir hal aldı. Dolayısıyla dokümantasyonun hayati önemi gittikçe azaldı. Yazılım projelerinin geliştirilmesindeki en büyük kolaylık doğru şekilde yazılım geliştirmek oldu. Dokümantasyonu oluşturmak ve bakımı yapmak, gereğinden fazla emek ve para harcamak başlı başına bir israf oldu.
Royce’un yazılım geliştirme işine yaptığı etki tartışılamaz. Keşke onu takip edenler gerçekten anlatmak istediklerini anlayabilselerdi. Belki şimdi çok daha farklı bir dünyada yaşıyor olabilirdik.