ワークフローの詳細:
|
このワークフローの詳細の目的は、プロジェクトへの変更の影響を十分に検討し、プロジェクトの中で一貫した方法で承認された変更が行われるようにすることです。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
標準の文書化された変更管理プロセスを採用することで確実に、プロジェクトの中で一貫した方法で変更が行われ、適切な利害関係者に製品の状態、変更内容、変更がコストとスケジュールに及ぼす影響などが通知されるようにすることができます。
このワークフローの詳細に関連する追加情報へのリンクを提供します。
この作業は方向づけから始まり、ライフサイクル全体にわたって継続しますが、ライフサイクルが進むにつれ重要度が増す傾向があります。通常は、この作業は方向づけフェーズよりも移行フェーズでより公式に管理されます。
この作業はオプションとみなされません。ただし、プロジェクトのカルチャーにより、この作業は、非公式であまり考慮の必要のないものから公式で多大な努力を要するものまでさまざまになると予想されます。一部の CM 環境では、ツール内にルールを確立できるプロセスの自動化を通じて CCB 機能がサポートされるようにすることができます。これは、分散されたチームにまたがり CCB 機能を管理する必要がある場合に特に役立ちます。
変更プロセスを監視する変更 (または構成) 審査会 (CCB) は、RUP でさまざまな役割を果たす代表者で構成されます。通常は、管理者、利害関係者 (顧客、エンドユーザー)、開発者、テスト担当者が含まれます。小規模なプロジェクトでは、プロジェクト管理者またはソフトウェア アーキテクトのような 1 人の人が、CCB の唯一の代表者である場合もあります。Rational Unified Process では、この主要な CCB の役割が変更管理責任者になります。
この作業の実行に役立つ補足ガイダンスについては、「関連情報」を参照してください。
この概念の詳細、提案される作業、変更依頼の状態については、「概念: 変更依頼管理」を参照してください。
Rational Unified Process
|