ウオーターフォール‐モデル【waterfall model】
ウォーターフォール・モデル
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/04/14 07:38 UTC 版)
ウォーターフォール・モデル（Waterfall Model）は、ソフトウェア工学における古典的な[1][2]開発モデルであり、開発活動を線形の連続的なフェーズに分割し、各フェーズが前のフェーズの成果物に依存し、タスクの専門化に対応している[3]。 このアプローチは、エンジニアリング設計の特定の分野で典型的である。ソフトウェア開発では[3]、反復が少なく柔軟性の低いアプローチの1つであり、進捗は主に1方向（滝のように「下方向」）に構想、着手、分析、設計、構築、テスト、実装、メンテナンスのフェーズを通って流れる[4]。 ウォーターフォールモデルは、ソフトウェア開発で使用された最も初期のSDLCアプローチである。
ウォーターフォール開発モデルは、製造業と建設業で生まれたものであり、高度に構造化された物理的環境では、開発プロセスのかなり早い段階で設計変更が非常に高価になることを意味していた。ソフトウェア開発に最初に採用されたとき、知識ベースのクリエイティブな作業に認められた代替案はなかった[5]。
概要
プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、主として以下のような工程で行われる。
上記のように作業工程（局面、フェーズ）にトップダウンで分割する。線表（ガントチャート）を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする。原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を段階的に確保し、前工程への後戻り（手戻り）を最小限にする。ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。
ウォーターフォール・モデルの例には、IBMによるADSG（Application Development Standardization Guide、アプリケーション開発標準化ガイド）などがある。
なお「ウォーターフォール・モデルは古く、スパイラルモデルは新しい」と単純化して語られる場合もあるが、大規模開発ではスパイラルモデルだけでは収束せず破綻するケースが大半のため、現在でもウォーターフォール・モデルとスパイラルモデル等は、組み合わされて使用されている[要出典]。
ウォーターフォール・モデルが採用される裏には、次のようなスパイラルモデルの問題が解決できないという理由もある。
- 要件を変更したときの見積もりや契約の方法が確立されていない
- 各工程の頻繁なリリースによるバージョン管理が難しい
- テストの自動化に関するノウハウが蓄積されていない
歴史
1968年、NATO後援の国際会議にて、ソフトウェア開発を職人芸的な作成方法から工業製品としての作成方法に変える方法として、製品製造過程のように開発をいくつかの工程に分け、各工程の終了を意味する文書を作成することで進捗を管理し、早いうちから品質の作りこみをしようとするウォーターフォール・モデルの原形が提唱された。[6]
「ウォーターフォール・モデル」という用語は、文字通り「滝」を意味し、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」においてウォーターフォールモデルのオリジナルはロイスだと述べている。
問題点
ウォーターフォール・モデルに対する批判には、次のようなものがある。
- 「ウォーターフォールモデルは間違っており有害である。私たちはこのモデルから脱却しなければならない」[7]
- 「ウォーターフォール・アプローチは，危険かつ問題をはらんだ，企業における風土病」[8]
- 「秩序正しく、予測が可能で、説明が付きやすく、測定可能なプロセスであり、文書を中心とした単純なマイルストーンが存在するという幻想をウォーターフォールがあたえた」[9]
ウォーターフォール・モデルの問題点は、『前工程に間違いがない』ことを前提または期待していることである。
古くから（現代においても）、要求を事前に詳細に定義することは困難であると言われている。要求をユーザーに徹底的に確認したにもかかわらず、下流工程になって見え始めたシステムを見たユーザーから修正要望が出ることがある。この要望に応えるには、前工程に戻って進捗度を戻さざるをえなくなる。（要望に応えなければ戻さずに済む。）
ウォーターフォール開発プロジェクトが成功するためには、過去に同じようなプロジェクトで一度失敗している必要があると言われている。これは、システム開発の名著『人月の神話』においても批判されていることである。
前工程への後戻りはスケジュールの遅延の原因であると評価されるため、前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、後戻りが発生する場合は変更管理によって公式に決定し、後戻りや横展開を確実にフォローすることが求められる。
また大規模開発では、全システムを同じスケジュール（1時点では全システムの設計、1時点では全システムのプログラミング、など）とすると、管理可能な範囲を超える、似たような問題が各所で同時発生する、リソースの平準化がなされないなどの問題があるため、業務上またはシステム的に分割容易な適切なサブシステム単位に分割し、それぞれで局面化する事が一般的である。この場合は共通する仕様の問題は、先行するサブシステムで発見されるため、後続のサブシステムではより早い工程で変更できる。
要求の修正要望が出ないようにするために、「プロトタイプ」と呼ばれる試作プログラムや画面デモ用プログラムを作成することがある。この試作プログラムの開発を要求定義工程とみなせば前工程が完了しないと次工程に進まない原則とつじづまが合うが、開発工程とみなせば原則に違反したとしてプロトタイプを作成しないよう指示されてしまうことが考えられる。テスト駆動開発は着実に進捗を進めることを可能にする開発方法であると言われてるが、これも前工程が完了しないと次工程に進まない原則に違反する。また、テストの自動化に関するノウハウが必要になる。
脚注
- ^ “From Waterfall to Agile software: Development models in the IT sector, 2006 to 2018. Impacts on company management”. Journal of International Studies (Fundacja Centrum Badań Socjologicznych) 11 (2): 315–325. (2018). ISSN 2071-8330 2023年9月28日閲覧。.
- ^ Adenowo, Adetokunbo; Adenowo, Basirat A (2020-09-10). “(PDF) Software Engineering Methodologies: A Review of the Waterfall Model and Object- Oriented Approach”. International Journal of Scientific and Engineering Research (IJSER Publishing) 4 (7): 427–434. ISSN 2229-5518 2023年9月28日閲覧。.
- ^ a b Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). “The Waterfall Model in Large-Scale Development”. In Bomarius, Frank; Oivo, Markku; Jaring, Päivi et al. (英語). Product-Focused Software Process Improvement. Lecture Notes in Business Information Processing. 32. Berlin, Heidelberg: Springer. pp. 386–400. Bibcode: 2009pfsp.book..386P. doi:10.1007/978-3-642-02152-7_29. ISBN 978-3-642-02152-7
- ^ “The Traditional Waterfall Approach”. www.umsl.edu. 2022年2月23日閲覧。
- ^ Benington, Herbert D. (1 October 1983). “Production of Large Computer Programs”. IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102 2011年3月21日閲覧。. Archived July 18, 2011, at the Wayback Machine.
- ^ 菅野孝男 1996, p. 34.
- ^ Frederick P. Brooks Jr. 2010, p. 34.
- ^ McBreen,P. 2002, p. 125.
- ^ Larman,C. 2004, pp. 129–132.
参考文献
- 菅野孝男『改訂 ソフトウェア開発のマネージメント』新紀元社、1996年。 ISBN 978-4883170371。
- Frederick P. Brooks Jr. 著、松田晃一・小沼千絵 訳『デザインのためのデザイン』ピアソン桐原、2010年。 ISBN 978-4864010047。
- McBreen,P. 著、村上雅章 訳『ソフトウェア職人気質：人を育て，システム開発を成功へと導くための重要キーワード』ピアソン・エデュケーション、2002年。 ISBN 978-4894714410。
- Larman,C. 著、高慎治郎・松田直樹・越智典子 訳『初めてのアジャイル開発』日経BP社、2004年。 ISBN 978-4822281915。
関連項目
- Vモデル
- SSADM
- スパイラルモデル
- プロトタイプモデル : システムの試作品を作成し、ユーザーの確認を得ながら開発を進める開発モデル。
- アジャイルソフトウェア開発
- テスト駆動開発
- ソフトウェア開発工程
- ステージゲート法 (手法)
外部リンク
 |
この項目は、ソフトウェアに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |
ウォーターフォール・モデル
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/05/16 06:41 UTC 版)
「ソフトウェア開発工程」の記事における「ウォーターフォール・モデル」の解説
詳細は「ウォーターフォール・モデル」を参照 ウォーターフォール・モデルでは、開発者は上述の工程（局面、フェーズ）を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し（単体テスト→システムテストの順）、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土台を変更できないというのと同じ考え方である。 ウォーターフォール・モデルでは上流工程での間違いや仕様変更を後から訂正・反映することを考慮していないと考えられがちだが、これは誤解である。これは要求管理に変更制御を含めるかどうかという問題である。 この手法は特に大規模なシステム開発や危険の大きいプロジェクト（軍需関係の契約など）で使われている。各工程ごとに契約・入札が行われる場合もある。 大規模なシステム開発ではサブシステム化も併用し、各サブシステムで時期をずらしてウォーターフォール・モデルを採用する事で、先行するサブシステムで発見した問題を後続のサブシステムでは早い段階の工程で取り入れたり、各工程の要員（設計者・プログラマ・テスターなど）や主要イベント（プロジェクト立ち上げ・レビュー・検収・研修・本番稼動など）の平準化を図る場合も多い。また各工程の内部では後述のスパイラルモデルや反復型開発を組み合わせる場合もある。 ウォーターフォールの問題は、要求分析と要求管理についての技術的未熟さから生じることが多い。さらに言えば、開発工程の弱点の把握不足と開発者が問題を理解せずにコーディングを開始してしまうことからも問題が生じる。また、しばしば省略されがちな工程として顧客と開発者の間での共同レビューがある。開発者は危険を承知で設計を進めて開発するが、その設計は最終的には Critical Design Review（最終設計審査）というマイルストーンでチェックを受けることになる。この手法への批判はソフトウェア工学者よりも実際の技術者から出てくることが多い。批判者はWISCY（Why Isn't Someone coding yet?）アプローチなどを信奉している。
※この「ウォーターフォール・モデル」の解説は、「ソフトウェア開発工程」の解説の一部です。
「ウォーターフォール・モデル」を含む「ソフトウェア開発工程」の記事については、「ソフトウェア開発工程」の概要を参照ください。
- ウォーターフォール・モデルのページへのリンク
