トピック

定義 ページの先頭へ

変更依頼 (CR) - プロジェクトのライフサイクル全体にわたって関連する状態情報と共にすべての利害関係者の要望 (新しい機能、拡張依頼、障害、変更された要求などを含む) を追跡するために使用される正式に登録される成果物。変更の日付、理由と共に状態変更を含め、変更履歴はすべて変更依頼で保守されます。この情報は、反復レビューと最終的な終了のために利用できます。

変更 (または構成) 審査会 (CCB) – 顧客、開発者、ユーザーを含むすべての関係者の代表で構成される変更プロセスを監視する委員会。小規模プロジェクトの場合は、プロジェクト管理者またはソフトウェア アーキテクトなどの 1 人のチーム メンバーが、この役割を果たすこともあります。Rational Unified Process では、これは変更管理責任者の役割によって示されます。

CCB レビュー会合 – この会合の役割は、登録済みの変更依頼をレビューすることです。変更依頼の内容についての初期のレビューは、有効な依頼であるかどうかを判断するこの会合で行われます。その場合、変更が現在のリリースの範囲内であるかどうかの判断は、優先順位、スケジュール、リソース、作業レベル、リスク、重大度、グループによって決定されるほかの関連基準などに基づいて行われます。この会合は通常週に 1 度開かれます。変更依頼のボリュームが非常に大きい場合、またはリリース サイクルの終わり近くになると、会合は毎日のように頻繁に開かれることもあります。通常、CCB レビュー会合のメンバーは、テスト管理者、開発管理者、市場開発のメンバーで構成されます。追加の参加者は、メンバーによって必要かどうか「随時」判断されます。

変更依頼登録フォーム - このフォームは、変更依頼を初めて登録するときに表示されます。登録者が記入する必要のあるフィールドのみが、フォーム上に表示されます。

変更依頼結合フォーム - このフォームは、すでに登録された変更依頼をレビューする場合に表示されます。変更依頼を記述するために必要なフィールドがすべて含まれます。

変更依頼プロセスの次の概要では、プロセス全体を通じた変更依頼の状態とステータス、変更依頼のライフサイクルの中で通知される必要のある人について説明します。」で説明します。

変更依頼管理のサンプル作業 ページの先頭へ

次の例では、ライフサイクル全体にわたって CR (変更依頼) を管理するためにプロジェクトで採用できる作業サンプルを示します (ダイアグラムの中の項目をクリックすると説明が表示されます)。

サンプルの CRM (変更依頼管理) プロセスの作業の説明

作業 説明 責務
CR の登録 プロジェクトの利害関係者は誰でも、CR (変更依頼) を登録することができます。変更依頼が変更追跡システム (たとえば、Rational ClearQuest) にログされ、CCB Review Queue に入れられるようにするには、変更依頼状態を登録済みに設定します。 登録者
CR のレビュー この作業の任務は、登録済みの変更依頼をレビューすることです。変更依頼の内容についての初期のレビューは、有効な依頼であるかどうかを判断する CCB レビュー会合で行われます。その場合、変更が現在のリリースの範囲内であるかどうかの判断は、優先順位、スケジュール、リソース、作業レベル、リスク、重大度、グループによって決定されるほかの関連基準などに基づいて行われます。 CCB
重複または却下の確認 変更依頼が無効な依頼として重複または却下である疑いがある場合 (オペレータ エラー、再現不可能、作業方法など)、CCB の代表者が、その重複または却下の変更依頼を確認し、必要に応じて登録者から追加の情報を収集するよう割り当てられます。 CCB 代表者
CR の更新 変更依頼を評価するためにより多くの情報が必要とされる場合 (要詳細情報)、またはプロセスのいずれかの時点で変更依頼が却下された (複製却下などとして確認された) 場合は、登録者に通知されるので、変更依頼を新しい情報で更新することができます。更新した変更依頼は、新しいデータの審議のために CCB Review Queue に再登録します。 登録者
作業の割り当てとスケジュール 変更依頼がオープンになったら、プロジェクト管理者が、依頼の種類 (拡張依頼、障害、文書変更、テスト障害など) に応じて適切なチーム メンバーに作業を割り当て、プロジェクトのスケジュールへの必要な更新を行います。 プロジェクト管理者
変更を行う 割り当てられたチーム メンバーは、プロセスの適切なセクションの範囲内で定義された作業セットを実行して (要求、分析 / 設計、実装、ユーザー サポート教材の生成、設計テストなど)、要求された変更を行います。これらの作業には、通常の開発プロセスの中で説明されているような通常のレビュー、単体テストなどの作業がすべて含まれます。変更依頼は、解決済みとマークされます。 割り当てられたチーム メンバー
テスト ビルドでの変更の確認 割り当てられたチーム メンバー (分析者、開発者、テスト担当者、テクニカル ライターなど) によって変更が解決済みになった後、その変更はテスト キューに入れられてテスト担当者に割り当てられ、製品のテスト ビルドで検証済みになります。 テスト担当者
リリース ビルドでの変更の確認 解決された変更が製品のテスト ビルドで検証済みになったら、製品のリリース ビルドに対する確認を行うために変更依頼をリリース キューに入れ、リリース ノートの生成などを行って、変更依頼を終了します。 CCB 代表者 (システム統合担当者)

変更依頼の状態と移行のサンプル ページの先頭へ

以下のダイアグラムは、サンプル状態と CR (変更依頼) のライフサイクル全体にわたって通知する必要のある人を示したものです [ダイアグラムの中の項目をクリックすると、説明が表示されます]。

サンプルの CRM (変更依頼管理) の状態の説明

状態 定義 アクセス制御
登録済み この状態は、1) 新しい変更依頼の登録、2) 既存の変更依頼の更新、または 3) 新しいリリース サイクルのために保留の変更依頼の審議の結果として発生します。変更依頼は、CCB Review Queue に入れられます。このアクションの結果として所有者割り当ては行われません。 すべてのユーザー
保留 変更依頼は有効と決定されましたが、現在のリリースの「範囲外」です。保留状態の変更依頼は、将来のリリースのために保持され再検討されます。CCB Review Queue に再入力するために変更依頼を登録できるタイムフレームを示すために対象リリースを割り当てることができます。 管理者

プロジェクト管理者

重複 この状態の変更依頼は、既に登録されている別の変更依頼の重複であるとみられます。変更依頼をこの状態に入れることができるのは、CCB レビュー管理者か、その変更を解決するよう割り当てられたチーム メンバーです。変更依頼が重複の状態に入れられている場合、それが重複している変更依頼の番号が (ClearQuest の [添付s] タブに) 記録されます。登録者は、変更依頼を登録する前に重複がないかどうか変更依頼のデータベースを照会する必要があります。これによってレビュー プロセスのいくつかの手順を回避できるので、時間を節約することができます。重複の変更依頼の登録者は、解決についての今後の通知のために、元の変更依頼の通知リストに追加される必要があります。 管理者

プロジェクト管理者

QE 管理者

開発

却下 この状態の変更依頼は、CCB レビュー会合で、または割り当てられたチーム メンバーによって、無効な依頼である、または登録者からの追加情報が必要であると判断されました。既に割り当てられている (オープン) 場合、変更依頼は解決の待ち行列から削除され、もう 1 度レビューされます。CCB の指定された管理者が、確認するよう割り当てられます。必要と判断されないかぎり、登録者からのアクションは必要とされません。その場合、変更依頼の状態は要詳細情報に変更されます。変更依頼は CCB レビュー会合で再度レビューされ、新しい情報について審議されます。無効が確認された場合、変更依頼は CCB によって作業終了にされ、登録者に通知されます。 管理者

プロジェクト管理者

開発管理者

テスト管理者

要詳細情報 却下または重複の変更依頼の有効性を確認するためのデータが不十分です。所有者は、詳細データを提供するよう通知された登録者に自動的に変更されます。 管理者
オープン この状態の変更依頼は、現在のリリースの「範囲内」であると決定され、解決を待っています。次回の目標のマイルストーンの前に解決されることになっています。「割り当ての待ち行列」に入っていると定義されます。会合のメンバーだけが、変更依頼を開いて解決の待ち行列に入れる権限を持ちます。優先順位が 2 番目以上の変更依頼を見つけた場合は、QE または開発管理者にただちに知らせる必要があります。その時点で、QE または開発管理者は緊急の CCB レビュー会合を召集するか、即座に変更依頼を開いて解決の待ち行列に入れるかを決定することができます。 管理者

プロジェクト管理者

開発管理者

QE 部門

割り当て済み オープンの変更依頼は、プロジェクト管理者が、変更依頼の種類に基づいて作業を割り当て、必要に応じてスケジュールを更新します。 プロジェクト管理者
解決済み この変更依頼の解決は完了し、検証の準備ができていることを示します。登録者が QE 部門のメンバーである場合、所有者は自動的にその登録する QE メンバーに変更されます。それ以外の場合は、手動で QE 管理者に変更します。 管理者

プロジェクト管理者

開発管理者

QE 管理者

開発部門

テスト失格 テスト ビルドまたはリリース ビルドのいずれかでテストに失格した変更依頼は、この状態に入れられます。所有者は、変更依頼を解決したチーム メンバーに自動的に変更されます。 管理者

QE 部門

検証済み この状態の変更依頼は、テスト ビルドで検証済みであり、リリースに含める準備ができています。 管理者

QE 部門

作業終了 変更依頼はもはや注意を必要としません。これは、変更依頼を割り当てることができる最終状態です。CCB レビュー管理者のみが、変更依頼を終了する権限を持ちます。変更依頼が作業終了になると、登録者は変更依頼の最終処理に関する電子メールによる通知を受け取ります。変更依頼は、次のような場合に作業終了にすることができます。1) リリース ビルドで検証済みの解決が正当であると認められた後、2) 却下状態が確認されたとき、3) 既存の変更依頼の重複として確認されたとき。後者のケースでは、登録者は、重複の変更依頼について通知され、今後の通知のためにその変更依頼に追加されます (詳しくは、「却下」と「重複」の状態の定義を参照してください)。登録者が作業終了に異義を唱える場合、変更依頼を更新し、CCB レビューを受けるために再登録する必要があります。 管理者

状態の「タグ」は、変更依頼の (経時、分散、傾向などの) 統計データをレポートするための基盤を提供します。

CM Cube のコンテキストにおける変更依頼の状態



Rational Unified Process   2003.06.15