Waterfall Modeli: Royce 1970'te Gerçekte Ne Dedi?

Sürüm notu: Bu yazı Winston W. Royce'un Ağustos 1970'te yayımlanan "Managing the Development of Large Software Systems" makalesinin özgün metnini esas alır; alıntılar yerine kendi anlatımımızı kullanıyoruz.

Önce Tahmin Et

Bir mülakatta sana şu soru soruluyor: "Waterfall modelini kim, hangi yıl önerdi?" Büyük ihtimalle cevabın "Winston Royce, 1970" olur ve çoğu ders kitabı da sana hak verir. Şimdi ikinci soru: Royce o makalede, adım adım ve tek geçişte ilerleyen modeli önerdi mi, yoksa eleştirdi mi? Ve makalede "waterfall" kelimesi kaç kez geçer?

İkinci sorunun cevabı sıfır. Birinci sorunun cevabı ise yazının konusu: Royce'un tek geçişli modeli çizip hemen ardından onun riskli olduğunu söylediği, sonra beş düzeltme önerdiği bir metin, elli yıl boyunca tam tersini savunuyormuş gibi anlatıldı.

Makalenin Bağlamı

Royce, TRW (Thompson Ramo Wooldridge) şirketinde uzay görevleri için yazılım geliştiren ekipleri yönetmiş bir mühendis. Makale IEEE (Institute of Electrical and Electronics Engineers) WESCON (Western Electronic Show and Convention) bildirileri arasında yayımlandı. Konusu büyük yazılım sistemlerinin nasıl yönetileceği; yani bugünkü bir web uygulamasından çok, donanımı sabit, bellek ve zamanlama bütçesi sıkı, müşterisi devlet olan sistemler.

Royce önce küçük programlar için yalnız iki adımın yeterli olduğunu söylüyor: analiz ve kodlama. Büyük sistemlerde ise bu iki adıma requirements, tasarım ve test adımları ekleniyor ve ortaya bugün herkesin "Waterfall" diye tanıdığı yedi basamaklı diyagram çıkıyor: system requirements, software requirements, analysis, program design, coding, testing, operations.

Royce Tek Geçişli Modele Neden "Riskli" Dedi?

Diyagramı çizdikten hemen sonra Royce bu uygulamanın "riskli ve başarısızlığa davetiye" olduğunu yazıyor. Gerekçesi bugün de geçerli: zamanlama, bellek kullanımı ve giriş-çıkış gibi davranışlar analizle tahmin edilir, ama gerçekten ilk kez test aşamasında deneyimlenir. Test bu davranışların beklenenden farklı olduğunu gösterirse, düzeltme genellikle küçük bir kod değişikliğiyle bitmez. Ya requirements değişmeli ya da tasarımda büyük bir değişiklik gerekir. Royce'a göre bu durumda süreç fiilen başa döner ve takvimde ya da maliyette yüzde yüze varan aşım beklenebilir.

Bu cümledeki asıl fikir, riskin en geç keşfedildiği yerin en pahalı yer olduğu. Bir tasarım kararının yanlışlığını ne kadar geç öğrenirsen, o karara dayanan iş o kadar büyür. Bu fikir, ileride Spiral modelin risk odaklı yaklaşımına, oradan da Agile'ın kısa geri bildirim döngülerine uzanacak.

Royce'un Beş Önerisi

Makalenin büyük kısmı bu riski azaltmak için önerilen beş adıma ayrılmış. Kısaca:

Birincisi, program design önce gelir. Analiz tamamlanmadan önce, program tasarımcıları bellek, zamanlama ve veri akışı için kaba bir ön tasarım yapar. Amaç, analizi gerçekçi sınırlar içinde tutmak. Bugünkü karşılığı, mimari açıdan riskli kararları erken ve küçük bir deneyle sınamak.

İkincisi, tasarımı belgele. Royce bu konuda çok net: dokümantasyon miktarı az değil, oldukça fazla olmalı. Gerekçesi de pratik: belge, tasarımın gerçekte var olduğunun kanıtı, testçiler ve operasyon ekibi için tek bilgi kaynağı ve ekip değiştiğinde bilginin kaybolmamasının yolu. Bugün bu öneriyi ölçüsüz bir doküman yığını gibi okumak yanlış olur; Royce'un dünyasında koda bakarak sistemi anlamanın araçları çok sınırlıydı.

Üçüncüsü, iki kez yap. Müşteriye teslim edilen sürüm, kritik kısımlar açısından aslında ikinci sürüm olmalı. Önce sıkıştırılmış bir takvimle bir pilot model geliştirilir; Royce'un örneğinde 30 aylık bir proje için yaklaşık 10 aylık bir pilot. Pilotun amacı, bilinmeyenleri gerçek proje başlamadan ortaya çıkarmak. Bu, bugün prototyping ve spike dediğimiz şeyin erken bir tarifi.

Dördüncüsü, testi planla, kontrol et ve izle. Testi asıl tasarımcılardan bağımsız uzmanlar planlar; kodun ve analizin her parçası ikinci bir göz tarafından gözden geçirilir; programdaki her mantıksal yol en az bir kez sayısal olarak kontrol edilir. Code review ve coverage tartışmalarının 1970'teki hâli.

Beşincisi, müşteriyi sürece dahil et. Royce, müşterinin yalnız başta ve sonda değil, süreç boyunca resmî ve derin biçimde dahil olmasını istiyor; ön tasarım gözden geçirmesi, kritik tasarım gözden geçirmeleri ve son kabul gözden geçirmesi gibi noktalarda. Requirements'ın yanlış anlaşılma riskini, müşteri ile düzenli temas azaltıyor.

Figürün sağ tarafı bu önerilerin şeklini gösteriyor: her adım bir öncekiyle geri bildirim döngüsüne bağlı, testte çıkan bir tasarım sorunu açıkça program design'a geri dönüyor. Bu, tek geçişli bir şelale değil; kontrollü geri dönüşleri olan bir süreç.

"Waterfall" Adı ve Kurumsallaşma

Royce'un makalesinde "waterfall" kelimesi geçmiyor. Bu adın yazılım bağlamında bilinen en eski kullanımlarından biri 1976 tarihli Bell ve Thayer makalesi olarak gösterilir; ama bunun gerçekten ilk kullanım olup olmadığı kaynaklarda kesin değil. Royce'un çizdiği diyagram ise basamaklı görünümü yüzünden bu adla anılmaya başladı.

Modeli asıl kurumsallaştıran şey sözleşmeler oldu. ABD Savunma Bakanlığı (DOD, Department of Defense) 1985'te yüklenicileriyle yazılım geliştirme için DOD-STD-2167 standardını yayımladı. Standart, aşamaların sırayla ilerlediği ve her aşamanın sonunda resmî bir belge ve gözden geçirme beklendiği bir yapı tarif ediyordu. Devlet sözleşmeleri ödemeleri bu belgelere ve gözden geçirmelere bağladığı için model geniş bir ekosisteme yayıldı. 1994'te yayımlanan yeni askerî standart (MIL-STD-498) ise bu çizgiden uzaklaşıp evrimsel ve iterative geliştirmeye açık bir dil benimsedi.

Yani "Waterfall" büyük ölçüde Royce'un önerisinden değil, Royce'un riskli bulduğu diyagramın sözleşme ve denetim ihtiyaçlarına uyan basitliğinden doğdu. Belge sonu ödeme yapan bir müşteri için tek geçişli model, yönetmesi kolay bir modeldir.

Bookstore'da Aynı Feature'ın Waterfall Planı

Serinin ilk yazısındaki iade feature'ını, Bookstore'un büyük bir kurumsal müşterisi için sabit kapsamlı bir sözleşmeyle geliştirdiğimizi düşünelim. Plan, Gantt diyagramıyla şöyle görünüyor:

Phase                    Mar   Apr   May   Jun   Jul   Aug
Requirements             ████
Analysis and design            ████  ██
Coding                               ████  ████
Integration and testing                          ████
Deployment                                             ██

Mart'ta requirements dokümanı imzalanıyor. Dokümanda kargo firmasının teslim event'inin bir tarih alanı içerdiği yazıyor; bu bilgi firmanın bir yıl önceki dokümanından alınmış. Nisan ve Mayıs'ta tasarım, Mayıs'tan Temmuz'a kodlama yapılıyor. Ekip kargo firmasının gerçek sistemine ilk kez Temmuz'daki entegrasyon testinde bağlanıyor.

Temmuz'da üç şey birden ortaya çıkıyor. Teslim event'i artık tarih değil, saat dilimi içermeyen bir zaman damgası gönderiyor ve 14 günlük hesap bazı müşterilerde bir gün kayıyor. Para iadesini yapan ödeme sağlayıcısı, aynı iadenin iki kez yapılmasını önlemek için her istekte bir idempotency key istiyor; tasarımda böyle bir alan yok. Testçiler de kısmi iadenin, yani beş kitaplık bir siparişten iki kitabın iadesinin, requirements'ta hiç tanımlanmadığını fark ediyor.

Üçü de Royce'un tarif ettiği durum: sorun test aşamasında görünüyor ama kökü requirements ve tasarımda. Düzeltme, Mart'ta imzalanan dokümanın değiştirilmesini, yani sözleşmede bir değişiklik talebini gerektiriyor. Ağustos'taki deployment Ekim'e kayıyor. Kimse tembellik etmedi; plan, riskin en geç görüldüğü yere göre kurulmuştu.

Waterfall Nerede Gerçekten Uyar?

Bu, Waterfall'ın hiçbir yerde işe yaramadığı anlamına gelmiyor. Sıralı bir model, değişimin pahalı ve requirements'ın gerçekten sabit olduğu yerde makul bir seçim olabilir. Bir cihazın içine gömülen ve sahada güncellenmesi zor olan firmware buna örnek. Denetleyici kurumun her aşamanın belgesini ayrı ayrı onayladığı regüle bir süreç de öyle; orada belge, sürecin kendisinin bir çıktısı. Kapsamı hukuken dondurulmuş bir sözleşme ya da ekibin daha önce defalarca yaptığı aynı tipte bir entegrasyon da sıralı planlamaya uygun düşebilir.

Uymadığı yerler de bellidir: requirements'ın belirsiz olduğu ürün geliştirme, dış sistemlerle entegrasyonun sona bırakıldığı projeler ve tüm testin tek bir büyük blok halinde, en sonda yapıldığı big-bang test yaklaşımı. Bu üç durumda tek geçişli plan, riski ertelemekten başka bir şey yapmaz. Hangi modelin ne zaman seçileceğini serinin son yazısında karar faktörleriyle ele alacağız.

Üretimde Dikkat

Sözleşme ya da denetim seni sıralı bir plana zorluyorsa, Royce'un kendi önerileri hâlâ işe yarar. Entegrasyon riskini ilk aya çek: kargo firmasının gerçek test ortamına ilk haftada bağlanan küçük bir spike, Temmuz'daki üç sürprizden ikisini Mart'ta yakalardı. Kritik kısımları iki kez yap: idempotency ve kısmi iade gibi belirsiz noktalar için kısa bir pilot, sözleşmenin requirements bölümünü daha gerçekçi yapar. Test planını requirements aşamasında yaz: acceptance testlerin requirements'la birlikte tasarlandığı bu fikir, bir sonraki yazının konusu olan V-Model'in temelidir. Müşteriyi her ay bir demoyla sürece dahil et; imzalı doküman, çalışan bir ekranın yerini tutmaz.

Bir de değişiklik maliyetini görünür kıl. Sıralı bir planda geç gelen her değişiklik talebi, etkilediği aşamalarla birlikte kaydedilirse, hangi kararların erken netleşmesi gerektiği bir sonraki projede veriyle konuşulabilir.

Sık Düşülen Tuzaklar

Royce'u Waterfall'ın savunucusu sanmak en yaygın tuzak. Makale, tek geçişli modeli bir başlangıç noktası olarak çizip ardından onu düzeltmeye çalışan bir metin.

İkinci tuzak, Waterfall'ı her durumda kötü saymak. Değişim maliyetinin gerçekten yüksek olduğu ve requirements'ın gerçekten sabit olduğu bir bağlamda sıralı plan dürüst bir seçim olabilir. Sorun model değil, modelin uymadığı bir probleme uygulanması.

Üçüncüsü, Royce'un dokümantasyon vurgusunu bugüne aynen taşımak. 1970'te koddan sistemi anlamanın araçları çok kısıtlıydı; bugün test, tip sistemi, OpenAPI dokümanı ve ADR (Architecture Decision Record) gibi daha hafif araçlar aynı amaca hizmet edebilir. Amaç belge değil, bilginin kaybolmaması.

Dördüncüsü, "iki kez yap" önerisini unutup pilotu doğrudan production koduna çevirmek. Pilotun değeri öğrettiğinde, kodunda değil. Bu tuzağa serinin dördüncü yazısında prototyping'i anlatırken döneceğiz.

Küçük Bir Deneme

★☆☆ Royce'un makalesini kendin oku; kısa ve ücretsiz erişilebilir. Figürlerin sırasına dikkat et: tek geçişli diyagram kaçıncı figür, geri bildirimli diyagramlar kaçıncı?

★★☆ Ekibinin son büyük projesinde ilk kez test aşamasında ortaya çıkan üç sorunu listele. Her biri için, hangi aşamada ve hangi küçük deneyle daha erken yakalanabilirdi?

★★★ Yukarıdaki Gantt planını, Royce'un beş önerisini uygulayarak yeniden çiz: pilot nereye girer, entegrasyon ne zaman başlar, müşteri gözden geçirmeleri nerede olur? Yeni planın toplam süresi kısaldı mı, yoksa sadece risk öne mi çekildi?

Royce'un dördüncü önerisi, testin en sona bırakılmayıp planlanmasıydı. Bir sonraki yazıda bu fikri modelin merkezine koyan V-Model'e bakıyoruz: her geliştirme adımının bir test seviyesiyle eşleştiği ve test tasarımının sol kolda başladığı bir model.