ウオーターフォール‐モデル【waterfall model】
ウォーターフォール・モデル
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/03/20 19:55 UTC 版)
ウォーターフォール・モデルは、ソフトウェア工学における古典的な[1][2]開発モデルであり、開発活動を線形の連続的なフェーズに分割し、各フェーズが前のフェーズの成果物に依存し、タスクの専門化に対応している。[3] このアプローチは、エンジニアリング設計の特定の分野で典型的である。ソフトウェア開発では、[3] 反復が少なく柔軟性の低いアプローチの1つであり、進捗は主に1方向（滝のように「下方向」）に構想、着手、分析、設計、構築、テスト、実装、メンテナンスのフェーズを通って流れる。[4] ウォーターフォールモデルは、ソフトウェア開発で使用された最も初期のSDLCアプローチである。
- ^ “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.
- 1 ウォーターフォール・モデルとは
- 2 ウォーターフォール・モデルの概要
- 3 参考文献
ウォーターフォール・モデル
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/05/16 06:41 UTC 版)
「ソフトウェア開発工程」の記事における「ウォーターフォール・モデル」の解説
詳細は「ウォーターフォール・モデル」を参照 ウォーターフォール・モデルでは、開発者は上述の工程（局面、フェーズ）を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し（単体テスト→システムテストの順）、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土台を変更できないというのと同じ考え方である。 ウォーターフォール・モデルでは上流工程での間違いや仕様変更を後から訂正・反映することを考慮していないと考えられがちだが、これは誤解である。これは要求管理に変更制御を含めるかどうかという問題である。 この手法は特に大規模なシステム開発や危険の大きいプロジェクト（軍需関係の契約など）で使われている。各工程ごとに契約・入札が行われる場合もある。 大規模なシステム開発ではサブシステム化も併用し、各サブシステムで時期をずらしてウォーターフォール・モデルを採用する事で、先行するサブシステムで発見した問題を後続のサブシステムでは早い段階の工程で取り入れたり、各工程の要員（設計者・プログラマ・テスターなど）や主要イベント（プロジェクト立ち上げ・レビュー・検収・研修・本番稼動など）の平準化を図る場合も多い。また各工程の内部では後述のスパイラルモデルや反復型開発を組み合わせる場合もある。 ウォーターフォールの問題は、要求分析と要求管理についての技術的未熟さから生じることが多い。さらに言えば、開発工程の弱点の把握不足と開発者が問題を理解せずにコーディングを開始してしまうことからも問題が生じる。また、しばしば省略されがちな工程として顧客と開発者の間での共同レビューがある。開発者は危険を承知で設計を進めて開発するが、その設計は最終的には Critical Design Review（最終設計審査）というマイルストーンでチェックを受けることになる。この手法への批判はソフトウェア工学者よりも実際の技術者から出てくることが多い。批判者はWISCY（Why Isn't Someone coding yet?）アプローチなどを信奉している。
※この「ウォーターフォール・モデル」の解説は、「ソフトウェア開発工程」の解説の一部です。
「ウォーターフォール・モデル」を含む「ソフトウェア開発工程」の記事については、「ソフトウェア開発工程」の概要を参照ください。
- ウォーターフォール・モデルのページへのリンク
