Winston-Royce

inspect&adapt a devam

Cok degil daha 10 yil oncesine kadar yazilim projeleri bir insaat projesi gibi ele aliniyordu. Fizibilite yap, ona gore tasarla ve implement et. Degisimin buyuk risk oldugu bir sistemden bahsediyoruz burada. Bir insaatin ortasinda birileri gelip binanin 5 kat daha yuksek olmasi gerektigini soylerse temele kadar inilip, neredeyse projenin bastan yapilmasi gerekir. Bircok konsepti insaattan aldigimizi yazilimda kullandigimiz jargon dan da anlayabiliyoruz. Build, deploy, install… Bu bakis acisina bir de Henry Ford'un uretim bandi ve Taylor'in gorevler paylasimini ekledigimizde iste ortaya “cig kofteli susili mercimek corbasi” cikiyor. 

Degisimin risk, sorumsuzluk duygusunun yuksek oldugu, kaliteden, TCO(Total Cost of Ownership) dan bahsedilemeyen dahasi ihtiyaci karsilamakta zorlanan basarisiz projeler. Ama bu yaklasimi acimasizca elestirmemek de gerekiyor cunku bilgisayar daha cok yeni bir kavram. 60 senelik mazisi olan bir konu. Dolayisiyla buyuk proje ihityaclari ortaya ciktiginda ilk akla gelen sey, Winston Royce'un da aklina gelmis olan, Waterfall, su anki yeni adiyla da Waterfail. Neden mi? Cunku o donem icin(70 ler), eldeki tek isleyen cok kisiyle proje gelistirilen muhendislik calismalari insaat ve otomotiv gibi sektorlerde yapiliyor.

Artik yazilim isinin Waterfall ile yonetilemeyecek kadar duz islemedigi, karmasayi kontrol edecek bir yontemle yonetilmesi gerektigi biliniyor. En azindan simdilik bu sonuca varilmis durumda. Buna karsi cikanlar tabiki var ve bu da degisimin dogasi zaten, %30 her zaman sert sekilde karsi koyacak. Ancak bu kadar yeni bir sektorde, tipki Waterfall'un baslangicinda oldugu gibi,  1 developerin ortalama haftada 1000 satir calisir kod uretigi Quatropro for Windows projesinin Agile yontemlerin dogusuna zemin hazirladigini da unutmamak gerekir. Bunun da yerini baska basarilarin alacagini da tahmin edebiliyoruz. Bu noktada degisimin icinde olarak hizli degisen sektorumuzde olup bitenin takip edilmesinin sektoru cok daha hizli ilerletecegini dusunuyorum. Inspect&adap'a simdilik devam..

後に「ウォーターフォール」と名付けられたこのモデルは、Winston Royceが1970年に発表した、「Managing the development of large software systems」(大規模ソフトウェアシステムの開発管理)という論文の中で示されたのが最初です。この論文を通読して、モデルの趣旨を全体的に把握することをお勧めします。ほとんどの人は、このモデルが別の文献で引用されている部分だけを読んで、当時最善のものとして提示されたと捉えているのではないでしょうか。ところが実際は、論文の著者であるRoyce自身も、このモデルで開発プロセスの最後にテストを実施する点は大きな問題だと認識し、以下のように指摘していました。

このモデルの概念自体は正しいと確信している。ただし、上記のモデルを実践に移すことにはリスクがあり、失敗を招く恐れもある。(中略)開発サイクルの最後に実施するテストフェーズで初めて、机上の分析結果を実際のシステムの動作として、例えば処理実行タイミングの同期、ストレージの使用、データの入出力などの形で体験することになる。(中略)仕様変更の要求に応じると、壊滅的な結果になる場合が少なくない。設計のよりどころであり、システム全体の理論的根拠でもあるソフトウェア要件にほころびが生じるからだ。システム要件の変更を余儀なくされるか、仕様を抜本的に変更しなければならなくなるかのどちらかになる。事実上、開発プロセスが振り出しに戻り、開発スケジュールや費用は、予定の2倍にまで膨れ上がることもある。