このワークフローの詳細の目的は、プロジェクトへの変更の影響を十分に検討し、プロジェクトの中で一貫した方法で承認された変更が行われるようにすることです。


トピック


      変更依頼
変更依頼
  反復計画書
反復計画書
変更依頼
変更依頼
 
         
 
変更管理責任者
変更管理責任者
 

 
重複、または却下された変更依頼の確認
重複、または却下された変更依頼の確認

 
変更依頼のレビュー
変更依頼のレビュー

 
         
      変更依頼
変更依頼
  変更依頼
変更依頼
 

      反復計画書
反復計画書
ソフトウェア開発計画書
ソフトウェア開発計画書
 
       
 
プロジェクト管理者
プロジェクト管理者
 

 
作業のスケジュール作成と割り当て
作業のスケジュール作成と割り当て

 
       
      反復計画書
反復計画書
ソフトウェア開発計画書
ソフトウェア開発計画書
 
      作業指示書
作業指示書
 

         
 
任意の役割
任意の役割
 

 
変更依頼の登録
変更依頼の登録

 
       
      変更依頼
変更依頼
 


説明 ページの先頭へ

標準の文書化された変更管理プロセスを採用することで確実に、プロジェクトの中で一貫した方法で変更が行われ、適切な利害関係者に製品の状態、変更内容、変更がコストとスケジュールに及ぼす影響などが通知されるようにすることができます。

関連情報 ページの先頭へ

このワークフローの詳細に関連する追加情報へのリンクを提供します。

タイミング ページの先頭へ

この作業は方向づけから始まり、ライフサイクル全体にわたって継続しますが、ライフサイクルが進むにつれ重要度が増す傾向があります。通常は、この作業は方向づけフェーズよりも移行フェーズでより公式に管理されます。

オプション度 ページの先頭へ

この作業はオプションとみなされません。ただし、プロジェクトのカルチャーにより、この作業は、非公式であまり考慮の必要のないものから公式で多大な努力を要するものまでさまざまになると予想されます。一部の CM 環境では、ツール内にルールを確立できるプロセスの自動化を通じて CCB 機能がサポートされるようにすることができます。これは、分散されたチームにまたがり CCB 機能を管理する必要がある場合に特に役立ちます。

要員配置方法 ページの先頭へ

変更プロセスを監視する変更 (または構成) 審査会 (CCB) は、RUP でさまざまな役割を果たす代表者で構成されます。通常は、管理者、利害関係者 (顧客、エンドユーザー)、開発者、テスト担当者が含まれます。小規模なプロジェクトでは、プロジェクト管理者またはソフトウェア アーキテクトのような 1 人の人が、CCB の唯一の代表者である場合もあります。Rational Unified Process では、この主要な CCB の役割が変更管理責任者になります。

作業ガイドライン ページの先頭へ

この作業の実行に役立つ補足ガイダンスについては、「関連情報」を参照してください。

この概念の詳細、提案される作業、変更依頼の状態については、「概念: 変更依頼管理」を参照してください。



Rational Unified Process   2003.06.15