目的
  • この作業の目的は、変更依頼 (CR) を受け入れるか、却下のフラグを付けるかを決定することである。変更依頼を受け入れる場合は、優先順位、作業、スケジュールなどを評価して、その変更が現在のリリースの開発範囲内にあるかどうかを判定する。
ステップ
入力とする成果物:    結果となる成果物:   
頻度:  構成項目がベースライン化され、構成管理システムに入力されると、それを変更するためのすべての依頼は、正式な変更依頼管理プロセスを通す必要がある。 
役割:  変更管理責任者  
ツール メンター:   

ワークフローの詳細:   

変更審査会レビュー会合のスケジュール作成 ページの先頭へ

変更審査会 (Change Control Board。以下、CCB) は、顧客、開発者、ユーザーを含むすべての関係者の代表者から構成される、変更プロセスを監督する委員会です (変更審査会は「構成審査会 (Configuration Control Board)」と呼ばれる場合もあります)。小規模なプロジェクトでは、プロジェクト管理者やソフトウェア アーキテクトなど、1 人の代表者がこの役割を担うことがあります。Rational Unified Process では、この役割は変更管理責任者の役割によって示されます。

この会合の目的は、登録済みの変更依頼をレビューすることです。変更依頼の内容の初期レビューは、依頼が有効かどうかを決定する会合で行われます。要求が有効である場合、優先順位、スケジュール、リソース、作業レベル、リスク、厳密度、グループによって決定されたその他の関連基準に基づき、変更が現在のリリースの開発範囲内であるかどうかが判定されます。この会合は通常、週に 1 度行われます。変更依頼の量が著しく増加した場合や、リリース サイクルが終わりに近づくにしたがって、会合は毎日のように行われる場合があります。CCB レビュー会合のメンバーは、一般的に、テスト管理者、開発管理者、マーケティング部門のメンバーです。「必要に応じて」、メンバーの判断で出席者が加えられることがあります。

レビューする変更依頼の取得 ページの先頭へ

変更依頼フォームは正式に登録された成果物で、すべての依頼 (新機能、拡張依頼、障害、変更された要求など) を、関連するステータス情報と共に、プロジェクトのライフサイクルを通じて追跡するために使用します。すべての変更履歴は、すべての状態の変更、変更の日付と理由を含む変更依頼と共に保持されます。この情報は、反復レビューやプロジェクトの終了で利用されます。変更依頼フォームの例は、成果物: 変更依頼に用意されています。

登録済み変更依頼のレビュー ページの先頭へ

この作業の目的は、登録済みの変更依頼をレビューすることです。この状態は、1) 新しい変更依頼の登録、2) 既存の変更依頼の更新、3) 新しいリリース サイクルについて保留された変更依頼の検討による結果として発生します。変更依頼は、CCB レビューのキューに入れられます。このアクションの結果として所有者がアサインされることはありません。

変更依頼の内容の初期レビューは、依頼が有効であるかどうかを決定する CCB レビュー会合で行われます。要求が有効である場合、優先順位、スケジュール、リソース、作業レベル、リスク、厳密度、グループによって決定されたその他の関連基準に基づき、変更が現在のリリースの開発範囲内であるかどうかが判定されます。

変更依頼が有効であっても、現在のリリースの「開発範囲外」と判定されると、変更依頼は保留の状態に置かれ、将来のリリースのために保持され、再検討されます。変更依頼を登録して、CCB レビューのキューに再度入れる場合のタイムフレームを示すために、対象リリースがアサインされることがあります。

変更依頼が既に登録済みの別の変更依頼と重複すると思われる場合は、CCB レビュー管理者またはそのチーム メンバーにアサインされて解決されます。変更依頼が重複状態に置かれると、重複する変更依頼番号は (ClearQuest 内の [解決] タブに) 記録されます。登録者は、変更依頼を登録する前に、変更依頼データベースで変更依頼の重複がないかを問い合わせる必要があります。それにより、レビュー プロセスのいくつかのステップを省略でき、大きな時間の節約になります。重複する変更依頼の登録者は、将来、解決について通知されるように、元の変更依頼の通知リストに追加される必要があります。

CCB レビュー会合や担当のチーム メンバーによって、変更依頼が無効であると決定されたり、登録者からさらに詳細な情報が必要であると判断されたりすることがあります。変更依頼が既に割り当てられている場合 (オープン)、その変更依頼は解決キューから削除され、再度レビューされます。CCB 任命の権限をもつ担当者がアサインされ、これを確認します。必要と判断されない限り、登録者からのアクションは必要ありません。その場合、変更依頼の状態は要詳細情報に変更されます。新しい情報が入手されると、CCB レビュー会合でこれを検討し、変更依頼をレビューし直します。変更依頼が無効である判断された場合は、CCB によって作業終了状態にされ、登録者に通知されます。

変更依頼が現在のリリースの「開発範囲内」であると判定された場合は、オープン状態が割り当てられ、解決を待ちます。解決は次の対象マイルストーンの前に予定されています。これは「割り当てキュー」内にあると定義されます。会合のメンバーは、変更依頼を開始して解決キューに入れる権限を持つ唯一の存在です。優先順位が 2 位以上の変更依頼が見つかった場合は、直ちに品質エンジニア (QE) またはプロジェクト管理者に通知します。この時点で、CCB の緊急レビュー会合を招集するか、単に変更依頼を直ちに開始して解決キューに入れるかを決定します。

その場合は、プロジェクト管理者が、変更依頼の種類に基づいてオープン状態の変更依頼に作業の割り当てを行い、適宜スケジュールを更新します。

変更依頼が通過する一般的な状態は、概念: 変更依頼管理に示されています。



Rational Unified Process   2003.06.15