ソフトウェアが頻繁に変更されることもこれを示唆している。製造業において製造工程（製造ライン）の全面的変更は極めて稀であり、するとしてもそれは作業員の役割ではない。一方ソフトウェア開発ではリファクタリングをはじめとしたソフトウェア内部の変更が推奨され、それはプログラマーの役割である。頻繁な変更が実作業者におこなわれるのは開発/設計段階であり、すなわちコーディング含むソフトウェア開発は製造工程でなく設計工程に属している。
開発工程モデル.
ソフトウェア開発のプロセスモデルが開発工程モデルである。様々なソフトウェアライフサイクルで共通してみられるいくつかのモデルが存在する。それぞれのモデルには特徴があり、実際の開発ではプロジェクトに応じたモデルを含むソフトウェア開発方法論の選択が重要である。
ウォーターフォール・モデル.
ウォーターフォール・モデルでは、開発者は上述の工程（局面、フェーズ）を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し（単体テスト→システムテストの順）、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土台を変更できないというのと同じ考え方である。
ウォーターフォール・モデルでは上流工程での間違いや仕様変更を後から訂正・反映することを考慮していないと考えられがちだが、これは誤解である。これは要求管理に変更制御を含めるかどうかという問題である。
この手法は特に大規模なシステム開発や危険の大きいプロジェクト（軍需関係の契約など）で使われている。各工程ごとに契約・入札が行われる場合もある。
大規模なシステム開発ではサブシステム化も併用し、各サブシステムで時期をずらしてウォーターフォール・モデルを採用する事で、先行するサブシステムで発見した問題を後続のサブシステムでは早い段階の工程で取り入れたり、各工程の要員（設計者・プログラマ・テスターなど）や主要イベント（プロジェクト立ち上げ・レビュー・検収・研修・本番稼動など）の平準化を図る場合も多い。また各工程の内部では後述のスパイラルモデルや反復型開発を組み合わせる場合もある。
反復型.