ウォーターフォールでの開発は、上流から終わらせていく。
各工程で時間を費やし、設計書を作成する。

でも、手戻りが発生すると、とてつもない苦労となる。

画面設計書においては、レイアウトの修正が発生したときは、
　・レイアウトの修正
　・画面項目定義の修正
　・画面動作の修正
のような設計書修正作業が発生する。
この他に
　・プログラムの修正
　・テスト仕様書の修正
　・資産のリリース
が漏れなく付いてくる。

実際には、動いているプログラムだけを直してもシステムとしては正しく動作するのだが、
設計書との整合性が取れていないと、設計書を読む人は間違った理解をしてしまう。

　ならば、いっそうのこと設計書がなければ、こんな問題が起きないのでは？！

でも、設計書が無いと振る舞いが分からないよ〜と言うのであれば
設計書ではなく、テスト仕様書（テストケース）を作成してはどうだろうか。

テスト仕様書には
　・どの項目が
　・どのような動作をして
　・どんなデータを使用して
　・どういう振る舞いをすることで
　・結果どうなるか
が書かれてあれば良いかと。

レイアウトは、現物で。
設計書は、コードを読む。

　最近のフレームワークを使用したプログラムって、コメントとか無くても読めると思うんですよ。
　このクラスの意味、メソッドの振る舞い、プロパティ必要性を理解すれば
　おのずとソースが文字のように見えてくる・・・気がする。
　あ、もちろんそうでは無いプログラムもありますけどね。

[url=http://d.hatena.ne.jp/higayasuo/20080501/1209636051]プログラミングファースト[/url]が良いんでないかな〜。
Agileにいってみよっ。