プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、主として以下のような工程で行われる。上記のように作業工程(局面、フェーズ)にトップダウンで分割する。線表(ガントチャート)を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする。原則として前工程が完了しないと次工程に進まない(設計中にプログラミングを開始するなどの並行作業は行わない)事で、前工程の成果物の品質を段階的に確保し、前工程への後戻り(手戻り)を最小限にする。ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。また、工程を分けることによりスキル別に分業化が進み、結果として低スキル者でも開発に関わりやすくなっている。なお「ウォーターフォール・モデルは古く、スパイラルモデルは新しい」と単純化して語られる場合もあるが、大規模開発ではスパイラルモデルだけでは収束せず破綻するケースが大半のため、現在でもウォーターフォール・モデルとスパイラルモデル等は、組み合わされて使用されている。ウォーターフォール・モデルが採用される裏には、次のようなスパイラルモデルの問題が解決できないという理由もある。歴史.問題点.ウォーターフォール・モデルに対する批判には、次のようなものがある。ウォーターフォール・モデルの問題点は、『前工程に間違いがない』ことを前提または期待していることである。古くから(現代においても)、要求を事前に詳細に定義することは困難であると言われている。要求をユーザーに徹底的に確認したにもかかわらず、下流工程になって見え始めたシステムを見たユーザーから修正要望が出ることがある。この要望に応えるには、前工程に戻って進捗度を戻さざるをえなくなる。(要望に応えなければ戻さずに済む。)ウォーターフォール開発プロジェクトが成功するためには、過去に同じようなプロジェクトで一度失敗している必要があると言われている。これは、システム開発の名著『人月の神話』においても批判されていることである。