このトピックでは、ECP の利点、特徴、および一般的な使用法の概要を示します。
ECP プロセスは、次のようになっています。
- 5 つのフェーズ: 提出、分析、解決、評価、および完了
- 深さと幅の両方でステージを拡張可能
- インターロックされた要求変更管理 (オプション)
- 変更依頼解決管理
ECP に関する深い議論については、IBM® Rational® Enterprise Change
Process ホワイト・ペーパーを参照してください (ftp://public.dhe.ibm.com/common/ssi/ecm/en/rad14094usen/RAD14094USEN.PDFにあります)。
利点と特徴
ECP の利点と特徴は以下のとおりです。
- 重要なフェーズにおいてサインオフ権限を提供します。
- リスクの評価と回避に役立ちます。
- フォーム上の属性を、それらが適用されるフェーズの省略可能なセクションにグループ化します。
- CR の状態に基づき、フェーズ・セクションが自動的に展開および省略されます。この機能により、関連するほとんどの詳細情報に素早くアクセスできます。
- 小規模企業または大企業向けの、単純あるいは複雑な変更依頼に対する変更管理ニーズをサポートするようスケール変更できる設計になっています。
- 業界のベスト・プラクティスを念頭に置いて開発されています。プロセスはエンタープライズの多くのチームですぐに使用できます。
- IBM Rational Synergy タスクの表示と作成が可能です。
- CCMI_MatrixReports パッケージと一緒にすぐに使用して、詳細な Capability Maturity
Model Integration (CMMI) および Six Sigma をサポートするレポートを提供できます。
- フェーズ分け有効性
- フェーズ・スクリーニング有効性
- ウェイト付きマトリックス
- ライフサイクルの複数のポイントで E メール通知を送信するように設定されています。これらの通知には、CR の現在の状態に関連した詳細情報が含まれています。
- CR がライフサイクルを遷移する間に、CR ごとの実際の工数および工数見積もりを維持するようユーザーに促します。
- 親子関係をサポートします。子 CR は以下のように振る舞います。
- 異なる所有者間で作業を区分するか、特定の CR フェーズについてきめの細かいトラッキングを提供します。
- 親 CR と同じライフサイクルをサポートし、自身の子を持つことができます。
- Rational DOORS® を使用することで、要求および要求関連資料から変更依頼を直接作成することによる要求駆動型開発をオプションでサポートします。
- IBM Rational DOORS ライフサイクルを取り込むことで、IBM Rational Change for DOORS Interface と容易に統合します (オプション)。
- CR の制御能力を高めるために、追加の権限を提供します。例えば、次のものがあります。
- CRmgr 権限を持つユーザーは、ほぼすべての属性を変更でき、必要に応じて CR を再割り当てできるスーパーユーザーです。
- CRowner 権限を持つユーザーも、同様の能力を持ちますが、能力は自分が所有する CR に限定されます。
一般的な使用法
この使用シナリオには複数のユーザーが関与しています。ユーザーは割り当てられている権限に基づき、特定の状態の CR に対して特定のアクションを実行できます。
この例では、開発チーム・リーダーは割り当て者 権限を持っています。
レビュー委員会メンバーは、CRmgr 権限を持っているため、ライフサイクルの任意のポイントで CR を更新できます。
- 品質管理技術者が不具合を発見し、CR を提出します。CR のライフサイクルが提出 フェーズから開始します。
- レビュー委員会は E メール通知を受信して、提出された CR をレビューします。レビュー委員会は不具合を修正する必要があると判断し、CR を分析 フェーズに遷移します。CR は、レビューおよび分析のために開発チーム・リーダーに割り当てられます。
- 開発チーム・リーダーは E メール通知を受信し、CR をレビューして、不具合の修正に伴うリスクを評価します。
- 開発チーム・リーダーは不具合を修正する必要があると判断し、調査結果を文書化して、CR を分析 フェーズに遷移します。
- 管理者は CR をレビューし、不具合を修正するリスクおよび工数見積もりが現在のスケジュールに収まるかどうかを判断します。1 つの選択肢として、修正を後のリリースまで延期することもあります。ただし、この事例では、リスクおよび工数見積もりが許容されるため、CR は解決 フェーズに遷移します。開発チーム・リーダーが CR 解決者として割り当てられます。
- 次に、CR に割り当てられた開発者は E メール通知を受信します。
Rational Synergy で、開発者は不具合を修正するタスクを作成し、そのタスクを CR に関連付けます。
- 開発者は不具合を修正するために必要な作業を完了し、Rational Synergy 内のタスクを完了します。
次に、Rational Change で、開発者は不具合の修正方法を文書化し、CR を解決 状態に遷移し、実際に要した工数を更新します。
- 開発チーム・リーダーは CR をレビューし、作業を承認し、CR をテストするために評価 フェーズに遷移します。
- 品質管理技術者は修正を検証し、テストの実行方法を文書化し、CR に評価済みのマークを付けます。
- チーム・リーダーはコメントをレビューし、テストが十分であるかを判別し、CR を完了 フェーズに遷移します。