変更要求 (CMMI)
このトピックでは、変更要求の作業項目の詳細を設定する方法について学習できます。チームは、変更要求の作業項目を使用して、製品の一部に対して提案された変更を追跡できます。変更制御されている作業生産物に対して変更が提案されるたびに、変更要求を作成できます。詳細については、「変更の管理 (CMMI)」を参照してください。
このタイプの作業項目を作成する方法については、「作業項目とワークフロー (CMMI)」を参照してください。
このトピックの内容 |
関連トピック |
|---|---|
|
プロセス ガイダンス ブック フィールド参照 |
必要なアクセス許可
変更要求を表示するには、読み取りユーザー グループのメンバーであるか、[このノードの作業項目を表示します] が [許可] に設定されている必要があります。変更要求を変更するには、貢献者グループのメンバーであるか、[このノードの作業項目を編集します] のアクセス許可が [許可] に設定されている必要があります。詳細については、「アクセス許可の管理」を参照してください。
変更要求の定義
変更要求の作業項目フォームは、次の図に示すフィールドとタブにデータを保存します。
.png "変更要求の作業項目フォーム")
変更要求を定義する場合は、タイトルを定義する必要があります。他のフィールドは、空白または既定値のままでかまいません。
単一の変更要求を定義するには
作業項目フォームの最上部のセクションで、次のような情報を 1 つ以上指定します。
[タイトル] (必須) に、簡単な説明を入力します。
適切なタイトルを付けると、影響を受ける製品の領域と、どのような影響を受けるかについて理解しやすくなります。変更や、影響を受ける可能性がある領域をより正確に定義できるように、必要に応じてテキストを更新できます。
担当者 の一覧で、変更要求に対応するチーム メンバーの名前を選択します。
[!メモ]
作業項目は、貢献者グループのメンバーにのみ割り当てることができます。
変更要求の担当者を割り当てないままにすると、要件を定義するユーザーが自動的に担当者になります。
[状態] ボックスでは、既定値である提案済みをそのまま使用します。
既定では、[理由] フィールドの値は新規です。このフィールドの詳細とこのフィールドを使用してワークフローを追跡する方法については、このトピックの「変更要求の状態の変更」を参照してください。
優先度 の一覧で、4 ~ 1 の範囲で変更要求の重要度を (最も重要) を選択します (最も重要)。
既定値は 2 です。
トリアージ の一覧で、トリアージのサブ状態を選択します。
このフィールドでは、提案済みの状態にある変更要求に対して決定したトリアージ レベルを指定します。有効な値は [保留] (既定)、[詳細]、[情報取得済み]、および [トリアージ済み] です。
ブロック の一覧で、チームが変更要求を実装できない場合は、問題が防いだら あり を選択します。
区分 と イテレーション の一覧で、適切な区分とイテレーションをクリックします。
[!メモ]
プロジェクト管理者は、区分およびイテレーション ツリー階層を定義することで、チーム メンバーがそれらの指定によって進捗状況を追跡できるようにします。詳細については、「区分およびイテレーションの作成および修正」を参照してください。
details のタブで、チームが何を変更する必要がある説明をできる限り詳細に入力します。
開発者による変更要求の実装、およびテスト担当者による変更要求のテストが確実に行われるようにするためには、変更要求についてできる限り詳細な情報を入力する必要があります。チームはこの情報を使用して、タスクとテスト ケースの作業項目を作成できます。詳細については、「タスク (CMMI)」および「テスト ケース (アジャイル)」を参照してください。
JUSTIFICATION のタブで、変更要求の実装は顧客や製品に値を説明をできる限り詳細に入力します。
ANALYSIS のタブで、各テキスト ボックスを選択し、変更要求に次の領域に対する影響について詳しく入力します。:
アーキテクチャへの影響
ユーザー エクスペリエンスへの影響
テストへの影響
デザインおよび開発への影響
技術発行物への影響
変更を実装することによって生じるコストに加え、影響を受ける特定の領域を示すことができます。
そのほか のタブで、次の情報を指定する:
[最初の見積もり] ボックスに、変更要求の実装にかかると予想される作業時間を数値で入力します。
[!メモ]
通常、次のフィールドは、最初に変更要求を定義するときではなく開発サイクルの後半で定義します。
統合 の一覧で、開発チームによって変更要求が統合されたビルドの名前または番号を選択します。
ALL LINKS のタブで、要件やタスクなどの一つ以上の作業項目に変更要求をリンクします。
ATTACHMENTS のタブで、仕様、イメージは、実装する変更要求に関する詳細を提供する他のファイルを添付できます。
詳細については、このトピックの次のセクションを参照してください。
変更要求の要件、タスク、またはその他の作業項目へのリンク
変更要求への詳細、添付ファイル、またはハイパーリンクの追加
作業項目の保存を選択
.png "保存")
します。[!メモ]
変更要求を保存すると、作業項目ツール バーの下のタイトルに識別子が表示されます。
変更要求の要件、タスク、またはその他の作業項目へのリンク
変更要求とその他の作業項目の間に関係を作成することによって、より効果的なプロジェクトの計画、より正確な依存関係の追跡、より明確な階層構造関係の表示、より迅速な関連情報の検索を実行できます。変更要求の作業項目フォームから、変更要求に自動的にリンクされる作業項目を作成することも、既存の作業項目へのリンクを作成することもできます。
[リンク] タブで、特定の種類の作業項目への特定の種類のリンクを作成できます。詳細については、「Linking Work Items (CMMI)」を参照してください。
タスク、バグ、要件、またはその他の作業項目を作成して変更要求にリンクするには
変更要求の作業項目フォームを開き、すべてのリンク のタブをクリックし、を新規作成を選択
.png "リンクされた新しい作業項目の追加")
します。[リンクされた新しい作業項目の追加] ダイアログ ボックスが開きます。
![[リンクされた新しい作業項目の追加] ダイアログ ボックス](images/ee332480.procguid_cmminewlink(ja-jp,vs.110).png "[リンクされた新しい作業項目の追加] ダイアログ ボックス")
リンクの種類 の一覧で、作成し、リンクされた作業項目の種類に基づいてするリンクの種類を選択します。
タスクまたはバグへのリンクを設定するには、[子] リンクを作成します。
要件、リスク、または懸案事項へのリンクを設定するには、[影響元] リンクを作成します。
テスト ケースへのリンクを設定するには、[テスト担当者] リンクを作成します。
その他の種類の作業項目へのリンクを設定するには、[関連] または追跡する関係を表す別の種類のリンクを作成します。
作業項目の種類 の一覧で、作成する作業項目の種類を選択します。
[タイトル] に、提案される変更要求の説明を具体的かつ簡潔に入力します。
(省略可能) [コメント] に、追加情報を入力します。
[OK] をクリックします。
指定した作業項目の種類の作業項目フォームが開き、入力した情報が表示されます。
次のトピックの説明を参照して、残りのフィールドを設定します。
作業項目の保存を選択
します。
複数の既存の作業項目を変更要求にリンクするには
変更要求の作業項目フォームを開き、すべてのリンク のタブをクリックし、をリンク先を選択
.png "リンクの追加")
します。[変更要求へのリンクの追加] ダイアログ ボックスが表示されます。
![[要件へのリンクの追加] ダイアログ ボックス](images/ee332480.procguid_cmmiaddlink(ja-jp,vs.110).png "[要件へのリンクの追加] ダイアログ ボックス")
リンクの種類 の一覧で、作成し、リンクされた作業項目の種類に基づいてするリンクの種類を選択します。
タスクまたはバグへのリンクを設定するには、[子] リンクを作成します。
要件、リスク、または懸案事項へのリンクを設定するには、[影響元] リンクを作成します。
テスト ケースへのリンクを設定するには、[テスト担当者] リンクを作成します。
その他の種類の作業項目へのリンクを設定するには、[関連] または追跡する関係を表す別の種類のリンクを作成します。
次のどれかの操作を実行します。
[作業項目 ID] に、検索する作業項目の ID を入力します。複数の ID を指定するときは、コンマまたは空白で区切ります。
一覧から作業項目を指定するに 参照 を選択します。
[リンクされた作業項目の選択] ダイアログ ボックスが表示されます。
![[リンクされた作業項目の選択] ダイアログ ボックス](images/dd380700.wit_chooselinked(ja-jp,vs.110).png "[リンクされた作業項目の選択] ダイアログ ボックス")
保存されたクエリ の一覧で、追加する作業項目が含まれているクエリを選択します。たとえば、作業項目を開く、アクティブなバグ、または アクティブ タスクを選択できます。
検索を選択し、変更要求にリンクする選択し、OKを選択します。各作業項目の横にチェック ボックスが。
(省略可能) リンクする項目の説明を入力します。
[OK] をクリックします。
詳細については、「リンクまたはインポートする作業項目の検索」を参照してください。
作業項目の保存を選択
します。[!メモ]
リンクした変更要求と作業項目の両方が更新されます。
変更要求への詳細、添付ファイル、またはハイパーリンクの追加
詳細情報を入手した段階で、次の方法で変更要求に情報を追加できます。
[詳細]、[根拠]、または [分析] タブのテキスト ボックスに情報を入力します。
ファイルを添付します。
たとえば、電子メールのスレッド、文書、イメージ、ログ ファイルなどのさまざまな種類のファイルを添付できます。
サーバーまたは Web サイト上に保存されている Web サイトまたはファイルへのハイパーリンクを追加します。
変更要求に詳細を追加するには
ボックスの 詳細、配置、または 分析 のタブと型情報をクリックします。
情報の書式を設定すると、強調文字や箇条書きリストを使用できます。
[!メモ]
チーム メンバーが作業項目を更新するたびに、履歴には変更日、変更を行ったチーム メンバーの名前、および変更されたフィールドが表示されます。
詳細については、「変更要求フィールド参照 (CMMI)」および「要件フィールド参照 (CMMI)」を参照してください。
作業項目の保存を選択
します。
添付ファイルを変更要求に追加するには
[添付ファイル] タブで、次のいずれかの操作を行います。
ファイルを添付ファイル領域にドラッグします。
CTRL-V を選択
.gif "貼り付け")
するか、コピーするファイルを貼り付けるします。追加
.png "添付ファイルの追加")
を選択し、参照を選択し、添付ファイル のダイアログ ボックスで、添付するファイルの名前を入力するか参照します。(省略可能) [コメント] ボックスには、添付ファイルに関する追加情報を入力します。添付ファイル のダイアログ ボックスを閉じるには、OKを選択します。
作業項目の保存を選択
します。
変更要求にハイパーリンクを追加するには
すべてのリンク のタブで、リンク先を選択
します。.png "ハイパーリンク アドレスの URL の指定")
リンクの種類 の一覧で、ハイパーリンクを選択します。
[アドレス] ボックスで、次のいずれかの操作を行います。
リンク先が Web サイトである場合は、[アドレス] ボックスに URL を入力するか、インターネット ブラウザーから URL をコピーして貼り付けます。
リンク先がサーバーの場所である場合は、UNC アドレスを入力します。
(省略可能) [コメント] ボックスには、ハイパーリンクに関する追加情報を入力します。
[OK] をクリックします。
作業項目の保存を選択
します。
変更要求の状態の変更
トリアージ チームまたは製品計画会議では、これらの作業項目を確認して、提案された変更を分析、承認、または却下します。変更要求が承認された場合、チームはタスクを生成して変更を実装します。チームが変更を実装すると、チームは最終的に変更要求を終了します。
作業項目の状態を追跡するために使用できるデータ フィールドの詳細については、「割り当て、ワークフロー、および計画 (CMMI)」を参照してください。
次の状態を使用して、変更要求の進行状況を追跡できます。
提案済み
アクティブ
解決済み
Closed
変更要求の状態はどのチーム メンバーでも変更できます。
既定では、作業項目を作成したときの変更要求の状態は、提案済みです。チームは、現在のイテレーションの変更要求を受け入れると、作業項目をアクティブの状態にし、変更要求を分析し、実装に関する詳細を確認して、タスクを作成します。タスクが完了し、システム テストによって変更要求が正常に実装されたことが確認されたら、変更要求を解決済みの状態にします。最後に、変更要求の検証が完了したら、チーム メンバーは変更要求を終了の状態にします。
変更要求の状態を変更するには
変更要求を開きます。
状態 の一覧で、アクティブ、解決済み、または 終了を選択します。
状態を提案済みからアクティブに変更すると、[理由] フィールドが自動的に承諾済みに変わります。
状態をアクティブから解決済みに変更すると、[理由] フィールドが自動的にコードの完了およびシステム テストの成功に変わります。
状態を解決済みから終了に変更すると、[理由] フィールドが自動的に [妥当性確認テストに成功] に変わります。
作業項目の保存を選択
します。
通常のワークフローの流れ:
例外的な遷移:
|
変更要求の状態の図 .png "変更要求のワークフロー")
|
.gif "Ee332482.collapse_all(ja-jp,VS.110).gif")
提案済み (新規)
チーム メンバーは、チームがバグを検出した場合、または別のイベントによって、変更制御されている作業生産物に対して変更が必要であると判断された場合、変更要求の作業項目を作成できます。
チーム メンバーが変更要求を作成すると、次のデータ フィールドが自動的にキャプチャされます。
[作成者]: 変更要求を作成したチーム メンバーの名前。
[作成日]: 変更要求が作成された日時 (サーバー クロックで記録された日時)。
提案済みからアクティブへ
変更要求には、製品またはベースラインへの変更が記述されます。変更制御委員会は、チームが提案する各変更を調査して、変更を承認、または却下します。
チーム メンバーは、次の表に示す理由によって、変更要求の状態を提案済みからアクティブに変更できます。
理由 |
使用する状況 |
追加で行う操作 |
|---|---|---|
承諾済み |
変更制御委員会が、現在のイテレーションにおける実装の変更要求を承諾したとき。 |
実装を担当するチーム メンバーに変更要求を割り当てます。 |
調査 |
変更制御委員会が要求を承認する前に、要求による影響を調査する必要があると判断したとき。 |
調査が完了した時点で、変更要求の状態を提案済みに戻します。 |
チーム メンバーが変更要求の状態をアクティブに変更すると、次のデータ フィールドが自動的にキャプチャされます。
[アクティブ化した人]: 変更要求をアクティブ化したチーム メンバーの名前。
[アクティブ化された日]: 変更要求がアクティブ化された日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 変更要求の状態が変更された日時。
提案済みから終了へ
チーム メンバーは、次の表に示す理由によって、提案済みの状態の変更要求を終了できます。
理由 |
使用する状況 |
追加で行う操作 |
|---|---|---|
Rejected (却下) |
変更制御委員会が、チームが要求を実装できない、または顧客が要求を必要としなくなったと判断したとき。 |
なし。 |
チーム メンバーが変更要求を終了すると、次のデータ フィールドがキャプチャされます。
[終了者]: 変更要求を終了したチーム メンバーの名前。
[終了日]: 変更要求が終了した日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 変更要求の状態が変更された日時。
アクティブ
チームは、アクティブ状態の変更要求のみを実装する必要があります。アクティブな変更要求に対し、チーム メンバーはコードの記述、テスト、および文書化を行うためのタスクを作成する必要があります。すべてのタスクが完了すると、チーム メンバーが変更要求の状態を解決済みにします。変更要求が破棄された場合、またはスコープ外にされた場合も、チーム メンバーは変更要求を終了できます。
アクティブから解決済みへ
チーム メンバーは、次の表に示す理由によって、アクティブな変更要求を解決できます。
理由 |
使用する状況 |
追加で行う操作 |
|---|---|---|
コードの完了およびシステム テストの終了 |
変更要求を実装するためのコードがチェックインされ、すべてのシステム テストに合格したとき。 |
テストを担当するチーム メンバーに変更要求を割り当てます。 |
チーム メンバーがアクティブな変更要求を解決すると、次のデータ フィールドが自動的にキャプチャされます。
[解決者]: 変更要求を解決したチーム メンバーの名前。
[解決日]: 変更要求が解決された日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 変更要求の状態が変更された日時。
アクティブから終了へ
チーム メンバーは、次の表に示す理由によって、アクティブな変更要求を終了できます。
理由 |
使用する状況 |
追加で行う操作 |
|---|---|---|
破棄 |
変更要求を実装する必要がなくなったとき。 |
なし。 |
スコープ外 |
現在のイテレーションの変更要求を実装するためのリソースが不十分であるか、進行をブロックする別の懸案事項が見つかったとき。 |
[イテレーション] フィールドを更新して、チームが変更要求を実装する可能性があるイテレーションを指定します。変更要求がソフトウェアの次回リリースまで延期される場合、[イテレーション] フィールドは空白のままにし、延期された理由、および実装する必要がある時期について詳しく記述します。 |
チーム メンバーがアクティブな変更要求を終了すると、次のデータ フィールドが自動的にキャプチャされます。
[終了者]: 変更要求を終了したチーム メンバーの名前。
[終了日]: 変更要求が終了した日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 変更要求の状態が変更された日時。
アクティブから提案済みへ
変更要求が調査としてアクティブ化された場合は、チームが調査を完了した後で状態を提案済みに変更します。アクティブな変更要求の状態を提案済みに変更すると、次のデータ フィールドが自動的にキャプチャされます。
[変更者]: 変更要求の状態を変更したチーム メンバーの名前。
[状態の変更日]: 変更要求の状態が変更された日時。
解決済み
チームが変更要求を実装すると、リード開発者が状態を解決済みに設定し、テストを開始できるようにテスト担当者に変更要求を割り当てます。
解決済みの変更要求は実装済みであり、システム テストに合格します。ただし、顧客の要求に応じて変更要求が実装されたかどうかを確認するため、チームは、解決済みの変更要求を顧客と共に検証する必要があります。妥当性確認テストに合格すると、チームは変更要求を終了します。合格しなかった場合は、さらに作業を行うために再アクティブ化します。
解決済みから終了へ
チーム メンバーは、次の表に示す理由によって、解決済みの変更要求を終了できます。
理由 |
使用する状況 |
追加で行う操作 |
|---|---|---|
妥当性確認テストに成功 |
変更要求がすべての妥当性確認テストに合格したとき。 |
変更要求を製品所有者に割り当てます。 |
チーム メンバーが解決済みの変更要求を終了すると、次のデータ フィールドが自動的にキャプチャされます。
[終了者]: 変更要求を終了したチーム メンバーの名前。
[終了日]: 変更要求が終了した日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 変更要求の状態が変更された日時。
解決済みからアクティブへ
チーム メンバーは、次の表に示す理由によって、解決済みの変更要求を再アクティブ化できます。
理由 |
使用する状況 |
追加で行う操作 |
|---|---|---|
妥当性確認テストに失敗 |
妥当性確認テストで要件が顧客の要求を 1 つ以上満たしていないことが示されたとき。 |
テスト担当者は、テストの失敗に対するバグを作成し、懸案事項への対処方法を決定するリード開発者に変更要求を割り当てます。 |
チーム メンバーが解決済みの変更要求を再アクティブ化すると、次のデータが自動的にキャプチャされます。
[アクティブ化した人]: 変更要求を再アクティブ化したチーム メンバーの名前。
[アクティブ化された日]: 変更要求が再アクティブ化された日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 変更要求の状態が変更された日時。
Closed
チームは、終了済みの変更要求に対して作業を行うことができません。変更要求は、変更制御委員会が変更要求を却下した場合、またはチームが要求を正常に実装、検証、妥当性を確認した場合に終了になります。
チーム メンバー (通常はビジネス アナリストまたはプログラム マネージャー) は、終了したリスクがスコープに戻った場合、その変更要求を再アクティブ化できます。
終了からアクティブへ
チーム メンバーは、次の表に示す理由によって、終了した変更要求を再アクティブ化できます。
理由 |
使用する状況 |
追加で行う操作 |
|---|---|---|
エラーによる終了 |
チーム メンバーが誤って変更要求を終了したとき。 |
実装タスク、テスト ケース、および変更要求の詳細の定義が適切であり、開発をサポートするのに十分であることを確認します。 |
チーム メンバーが終了済みの変更要求を再アクティブ化すると、次のデータが自動的にキャプチャされます。
[アクティブ化した人]: 変更要求を再アクティブ化したチーム メンバーの名前。
[アクティブ化された日]: 変更要求が再アクティブ化された日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 変更要求の状態が変更された日時。
参照
概念
Visual Studio ALM の作業項目フィールド参照