概念:
|
作業 | 説明 | 責務 |
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
|