本来、「ソフトウェア・ライフサイクル」という言葉は、ソフトウェアの開発プロセスでは、開発計画の立案の意味で使ってきた。しかし、徐々に別の意味をもつようになる。最初は軽い気持ちで使ったが、間もなく、「ソフトウェア・ライフサイクル」は宗教的な雰囲気を帯びだした。プロセス改善に熱心な連中が、プログラムを正しく開発するステップで必要なことや順番を厳密に定義したのだ。このガチガチに定義したソフトウェア・ライフサイクルを「ウォーターフォール・ライフサイクル」と呼ぶ。ウォーターフォールは、水の流れのように、ライフサイクルのあるステップから次へ一方向に流れるプロセスである。ウォーターフォール・モデルを核にしていろいろな開発方法論が現れる。ウォーターフォール・モデルがソフトウェア開発で幅をきかすにつれて、弊害が出はじめた。 ウォーターフォール・モデルの弊害とは、複雑なプロセスを深く考えずに単純化しすぎたことだ。プログラムの作り方を熟知しているベテラン・エンジニアは、「自分がしていることをきちんと認識しているまともな技術者は、押し付けられた順番通りに開発ステップを進めるわけがない」と考えているはずである。ステップ自体はよいのだが、順番が問題なのだ。 （中略）ウォーターフォール・モデルの問題点に戻る。同モデルを支持する人は、この順番どおりに進めれば、プログラムを開発できると言い切る。仕様を完全に定義できた場合、設計ステップへ移る。設計が完全に終了したらコーディングへ進む。テストはコーディングが完成した場合に開始する。そして、テストが100％完了しないと何が起きてもプログラムは製品として外へ出て行かず、保守にも入れない。 いかにも正しく聞こえるが、現場のベテラン技術者は、昔から、「少し作って少しテスト（build-a-little, test-a-little）的なアプローチを取ってきた。開発するソフトウェアが具体化するに従い、仕様は目まぐるしく変わる。設計段階では、概念的な設計モデルが実現可能かどうかチェックするため、ソースコードのセグメントのレベルで確認する必要がある。もちろん、実験的に作ったこのセグメントが仕様通りに動作するか、テストしなければならない。経験を積んだエンジニアは、ウォーターフォール・モデルを完全に実施することは不可能と考えている。管理者連中が、ウォーターフォール・モデルを制度化するため、やっきになっている間、ベテラン・プログラマは、いつも通りの自分の方法でプログラムを作ってきた（上層部の管理者はウォーターフォールを好む。これは、本当の開発プロセスは複雑怪奇だが、ウォーターフォール・モデルは単純に表現しているので、簡単に管理できる気がするためだ）。 『ソフトウェア開発55の真実と10のウソ』(2004,ロバート・L・グラス)

こさぼのページ