【うぉーたーふぉーるもでる】
ウォーターフォールモデル とは?
最終更新:
💡 工程の成果を確認し、段階を追って開発する
要件定義・設計・実装・テストなどの工程を段階的に進めるソフトウェア開発モデル。各工程の成果を確認して次へ進む形を基本とし、後で変更が生じた場合は前の成果への影響も見直す。
📌 このページのポイント
どんな順番で開発するの?
要件定義で何を作るかを決め、設計・実装・テストを経て運用へ進む、という流れが代表例だよ。工程の名前や区切り方はプロジェクトで異なるけれど、段階ごとの成果を確認して進むのが基本なんだ。
計画は立てやすいの?
成果物や工程の節目を決めて、作業の範囲や進捗を説明しやすい面があるよ。ただし最初の要件が曖昧なら、予定どおりに進むとは限らない。計画を作ることと、納期や費用を保証できることは別だね。
途中で問題が見つかっても戻れない?
戻ることはあるよ。設計を変えるなら要件や実装、テストへの影響を確認する。1970年のRoyceの論文も、隣の工程へのフィードバックや、遅い段階で大きな設計変更が必要になるリスクを説明しているんだ。
テストの工程まで確認しなくていい?
最後にまとめて実際の動作を確かめるだけだと、根本的な問題に気付くのが遅くなる。要求や設計をレビューし、不確かなところは試作などで早く確かめよう。段階的に進めることを、早い確認を省く理由にはしないでね。
アジャイルとどちらを選べばいい?
必要な成果物や確認の節目、要件が変わる見込み、利用者からの反応を得る方法を考えよう。段階ごとの管理と、小さく作って学ぶ反復にはそれぞれ役割がある。規模や業界名だけで、一方が常に適切とは決められないんだ。
まとめ:ざっくりこれだけ覚えればOK!
「ウォーターフォール」って出てきたら「工程を段階ごとに進める開発モデル」と思えばだいたいOK!
📖 おまけ:英語の意味
「Waterfall Model」 = 滝型モデル
💬 工程が滝のように段階を追って進むイメージだよ。図の下向きの流れだけを見て、見直しやフィードバックが一切ないと考えないようにしよう。