設計を十分に進めてから実装する場合、利用者が実物を確認できる時期も後ろになります。
その結果、
設計書では問題なさそう
↓
実物を見る
↓
「思っていた画面と違う」という認識差が発覚することがあります。
開発開始時に最適だった要件でも、完成時には利用者ニーズや市場環境が変わっている可能性があります。
そのため、
要件変更が少ない
→ ウォーターフォールと相性がよい
要件変更が頻繁
→ アジャイルなども検討という考え方が重要です。
初心者向け教材では、
前の工程が完全に終了してから次へ進み、前工程には戻らない
と説明されることがあります。
試験の特徴を覚えるための単純化としては分かりやすいのですが、「絶対に戻ってはいけない」という意味ではありません。
重大な仕様漏れを見つけても、
ウォーターフォールだから修正禁止とはなりません。
実際には、
問題発見
↓
影響分析
↓
変更申請
↓
承認
↓
要件・設計を修正
↓
実装
↓
再テストといった変更管理を行います。
重要なのは、
ウォーターフォールは「戻れない」のではなく、「後から戻るほど変更の影響が大きくなりやすいため、前工程を十分確認してから次へ進む」
と理解することです。