オフショアソフトウェア開発におけるウォーターフォールプロセス

ウォーターフォールプロセスとは？

ウォーターフォールプロセスは、最も初期でシンプルなソフトウェア開発プロセスの一つでした。フェーズの順序から「ウォーターフォール」と呼ばれています。

ウォーターフォールプロセスの各ステップは滝の段差のように次のステップへ流れていきます。前のフェーズが完了するまで次のフェーズは始まらず、各フェーズの完了は最終的なものです。フェーズを再訪する唯一の方法は、フェーズ1からやり直すことです。

つまり、ウォーターフォール管理手法は、いくつかの明確に区切られたフェーズからなる連続的で線形のプロジェクト管理プロセスです。

ウォーターフォールプロセスの目的は、システム全体を一度に納品することです。この方法は主に大企業や政府システムに適していました。しかし、扱う範囲が大きいため、ウォーターフォールプロセスは遅く、管理が難しく、変化に対してあまり柔軟ではありませんでした。

ウォーターフォールモデルのフェーズ

ウォーターフォールプロセスは通常、厳密な線形順序で進む5〜7のフェーズで構成されます。フェーズの具体的な名称は異なりますが、元々は発明者のWinston W. Royceによって以下のように定義されました：

• 要件定義：プロジェクト開始時にすべての顧客要件を収集し、以降のフェーズは追加のやり取りなしに計画されます。プロジェクトの要件は全チームメンバーに明確であるべきです。
• 設計：設計フェーズは通常、論理設計と物理設計の2つのサブフェーズに分かれます。論理設計は可能な解決策を検討する段階で、物理設計はそれらの理論的アイデアやスキーマを具体的な仕様に落とし込みます。このフェーズではコーディングは行いませんが、プログラミング言語やハードウェア要件などの仕様を決定します。
• 実装：実装フェーズはコーディングが行われる段階です。プログラマーは前のフェーズでの要件や仕様をもとに実際のコードを作成します。通常、小さな単位でコードを実装し、このフェーズの終わりか次のフェーズの開始時に統合します。
• 検証：このフェーズでは顧客が製品をレビューし、要件を満たしているか確認します。テスターはテスト過程で発生した問題を体系的に発見し報告します。重大な問題が発生した場合、プロジェクトはフェーズ1に戻って再評価が必要になることがあります。このフェーズを通過すれば、完成品は顧客にリリースされます。
• 保守：保守フェーズでは顧客が製品を定期的に使用し、バグや不十分な機能、その他の生産中に発生したエラーを発見します。問題が発生した場合、開発チームはそれらを解決するためのパッチやアップデートを作成する必要があります。重大な問題はプロセス全体をフェーズ1からやり直すことを要求するかもしれません。

ウォーターフォールプロセスモデルを使うべき時は？

この分野の専門家であるPatrick Rockwellは、ウォーターフォールプロセスが有効な状況について次のように述べています：

「最近ではあまり一般的ではありませんが、最終製品の要件が固定されているが変動する時間と予算の場合、この方法を選択してください。

私は大企業のために研究を行う科学者を想像します—試行錯誤を通じて、彼は望ましい最終結果を得るために何度も異なる段階でプロセス全体を再スタートするでしょう。

ウォーターフォールプロジェクト管理では、この行動が予期され、むしろ推奨されます！これによりメンバーは何度もアプローチを調整し再考することが可能になります。」

Patrickが述べているように、ウォーターフォールプロセスはプロジェクトの要件が完全に明確でない場合には問題が生じやすいです。変化に対応できないため、ウォーターフォール手法は明確な要件を持つ短期プロジェクトに最適です。

要件が常に変わらず環境が安定しているなら、ウォーターフォールは理想的な選択肢です。したがって、技術やツールが安定している場合にもウォーターフォールプロセスは適しています。

まとめ

これがウォーターフォールソフトウェア開発手法の基本的な紹介です。まとめると、ウォーターフォール手法は、詳細な要件と仕様を備えた完全に計画されたプロジェクトスケジュールがある場合に、プロジェクトのコスト、リソース、期限を正確に見積もるのに役立ちます。