ソフトウェアプロジェクト管理
要求管理は、要求を同定し、顧客から聞き出し、文書化し、分析し、追跡し、優先順位づけし、顧客と合意する過程であり、要求の変更を制御する過程であり、また利害関係者 (ステイクホルダ) とコミュニケーションする過程である。新しく構築するコンピュータシステムもしくは代替するコンピュータシステムの、要求分析工程を含む要求管理は、ソフトウェア開発では重要な作業である。実際には、ビジネスアナリストもしくはソフトウェア開発者が顧客のニーズや要求を同定する。彼らはこうして要求を同定し、そして解決方法 (ソリューション) を設計する。
変更管理は、プロジェクトのスコープに対する変更を同定し、文書化し、分析し、優先順位づけし、顧客と合意する過程であり、変更を制御する過程であり、また利害関係者とコミュニケーションする過程である。新しいスコープもしくは代替スコープの変更波及分析は、変更部分の要求分析を含む。変更波及分析は、ソフトウェア開発では重要な作業である。実際には、ビジネスアナリストもしくはソフトウェア開発者が顧客のニーズや要求を同定する。彼らはこうして要求を同定し、そして解決方法 (ソリューション) を再設計もしくは変更する。理論的には、個々の変更はソフトウェアプロジェクトの予定と経費に影響する。そのため当然に、変更に対してはその承認前に管理の一環としてリスク便益分析が行われる。
ソフトウェア構成管理は、プロジェクトのスコープそれ自身、すなわち現に存在するソフトウェア製品を同定し文書化する過程である。付随するすべての製品とすべての変更の管理も含まれる。それにより、製品と変更について利害関係者とのコミュニケーションができるようになる。
一般的には、バージョン管理、命名規約の過程を含む。
リリース管理は、ソフトウェアのリリースについて同定し、文書化し、優先順位づけし、顧客と合意する過程であり、リリーススケジュールを制御する過程であり、リリースについて利害関係者とコミュニケーションする過程である。多くのソフトウェアプロジェクトでは、ソフトウェアをリリースするために、3つのソフトウェア環境を利用する。すなわち開発環境、テスト環境、および本稼働環境 (プロダクション環境) である。非常に大規模なプロジェクトでは、地理的に分散したチームが、利用者へリリースする前に、自分たちの成果物を統合する必要がある。単体テスト、システムテストおよび統合テストなどと呼ばれるテストのための環境が別途に用意され、そして利用者受け入れテスト向けにリリースされる。 リリース管理のサブセットとして、データ管理が注目されつつある。利用者になじみのあるデータに基づくテストができるのは、明らかに利用者だけである。そして「現実の」データは本稼働環境 (プロダクション環境) と呼ばれる環境にのみ存在する。そのためプログラマたちが自分たちの成果物をテストするためには、多くの場合「ダミーデータ」や「データスタブ」を作る必要がある。慣習的に、この目的には以前のバージョンの本稼働環境のシステムが使われてきた。しかし企業がソフトウェア開発のための外部の協力者を信頼しすぎているとの理由から、本稼働環境のデータを開発チームに渡さないこともある。複合的な環境では、全体的なソフトウェアリリーススケジュールと同様に、テストリリーススケジュールにしたがってテスト環境間で移行されるデータが作られることがある。