ウォーターフォール・モデル

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
ウォーターフォール・モデルの一例

ウォーターフォール・モデルは、ソフトウェア工学では非常に古くからある、もっともポピュラーな開発モデル。

概要[編集]

プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、「要求定義」「外部設計(概要設計)」「内部設計(詳細設計)」「開発(プログラミング)」「テスト」「運用」などの作業工程(局面、フェーズ)に分割し、原則として前工程が完了しないと次工程に進まない(設計中にプログラミングを開始するなどの並行作業は行わない)事で、前工程の成果物の品質を確保し、前工程への後戻り(手戻り)を最小限にする。通常は「線表(ガントチャート)」を使用してスケジューリングする。

「ウォーターフォール・モデル」という用語は、文字通り「滝」を意味し、W. W.ロイスによって1970年に発表された論文「Managing the Development of Large Software Systems」の内容が元になったとされる。しかしこの論文には「ウォーターフォール・モデル」という記述は無く、また、前工程への後戻り(見直し)も提唱されており、元の論文の内容とは異なっている。

初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」であり、B.W.Boehamが1981年に出版した本「Software Engineering Economics」においてウォーターフォールモデルのオリジナルはRoyceだと述べ、ウォーターフォール・モデルの起源がRoyceであるという誤解を広めた。

ウォーターフォール・モデルの例には、IBMによるADSG(Application Development Standardization Guide、アプリケーション開発標準化ガイド)などがある。

詳細[編集]

ウォーターフォール・モデルの問題点は、『前工程に間違いがない』ことを前提または期待していることである。

経験のないプロジェクトであるならば、設計段階になって前工程の要求定義の不備不足が発覚するのは、むしろ当たり前であるはずなのに、ウォーターフォール開発においては、それが見越されていないことが多い。そのため、ウォーターフォール開発プロジェクトが成功するためには、過去に同じようなプロジェクトで一度失敗している必要があると言われている。これは、システム開発の名著『人月の神話』においても批判されていることである。

このため現実のウォーターフォール・モデルの開発プロジェクトでは、前工程の完了要件(要件定義局面であれば、要件定義書などの成果物の完成)を徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、後戻りが発生する場合は変更管理によって公式に決定し、後戻りや横展開を確実にフォローする。

また大規模開発では、全システムを同じスケジュール(1時点では全システムの設計、1時点では全システムのプログラミング、など)とすると、管理可能な範囲を超える、似たような問題が各所で同時発生する、リソースの平準化がなされないなどの問題があるため、業務上またはシステム的に分割容易な適切なサブシステム単位に分割し、それぞれで局面化する事が一般的である。この場合は共通する仕様の問題は、先行するサブシステムで発見されるため、後続のサブシステムではより早い工程で変更できる。

なお「ウォーターフォール・モデルは古く、スパイラルモデルは新しい」と単純化して語られる場合もあるが、大規模開発ではスパイラルモデルだけでは収束せず破綻するケースが大半のため、現在でもウォーターフォール・モデルとスパイラルモデル等は、組み合わされて使用されている。

関連項目[編集]

外部リンク[編集]