変更の例
以下の例では、コンフィギュレーションレベルの変更管理プロセスについて説明します。
変更の例 1: 基本的なコンフィギュレーションレベルの変更管理プロセス
次の例では、コンフィギュレーションアイテム (CI-53) を含む製品構造設計を使用します。このコンフィギュレーションアイテムは、単純なドアです。このコンフィギュレーションアイテムに対して、次の 2 つの設計解決策が実装されています。
• DS-1: シリアル番号 001 – 499 に対して有効です。
• DS-2: シリアル番号 500 – 999 に対して有効です。
製品構造に対して必要な変更が識別されました。この変更は、シリアル番号 400-600 の範囲に対して窓を要求することで、ドアのコンフィギュレーションアイテムに影響を与えます。次の変更プロセスによって、この変更に対処します。
1. ユーザーは、ドアのコンフィギュレーションアイテムに影響を与える変更ディレクティブを作成します。新しい変更ディレクティブでは、シリアル番号 400-600 の範囲の製品に対して、ドアに窓を含めることをリクエストします。
この変更ディレクティブは、既存の設計解決策である DS-1 と DS-2 の両方のエフェクティビティの範囲のセクションに影響を与えます。
2. ユーザーが「変更作業を生成」操作を選択すると、変更ディレクティブに対処するために次の 2 つの変更作業が生成されます。
◦ 変更作業 1 - シリアル番号 400-499 の製品に対して、窓付きの木製ドアを実装するための新しい設計解決策が必要であることを示します。
◦ 変更作業 2 - シリアル番号 500-600 の製品に対して、窓付きの金属製ドアを実装するための新しい設計解決策が必要であることを示します。
3. 既存の設計解決策 DS-1 および DS-2 に対して、エフェクティビティに関する警告が表示されます。
◦ DS-1 に対する警告は、シリアル番号 400-499 が適用外になる可能性があることを示します。
◦ DS-2 に対する警告は、シリアル番号 500-600 が適用外になる可能性があることを示します。
4. 影響を受けるコンフィギュレーションアイテム (CI-53) を担当するユーザーは、システムが生成する変更作業に対処するために 2 つの設計解決策を作成します。
◦ DS-3 - 窓付きの木製ドア
◦ DS-4 - 窓付きの金属製ドア
 | 設計解決策は、コンフィギュレーションアイテムの「設計解決策」テーブルから追加します。その結果、設計解決策はそのコンフィギュレーションアイテムに関連付けられ、関連する変更作業を実行できるようになります。 |
5. ユーザーは、新しい設計解決策を使用して変更作業を実行することで、変更作業を解決します。
◦ DS-3 が変更作業 1 を実行する
◦ DS-4 が変更作業 2 を実行する
6. 変更作業を実行する新しい設計解決策のエフェクティビティの範囲が設定されます。
◦ DS-3 のエフェクティビティが 400-499 に設定される
◦ DS-4 のエフェクティビティが 500-600 に設定される
7. 既存の設計解決策に対するエフェクティビティ警告が除去され、エフェクティビティの範囲が調整されます。
◦ DS-1 のエフェクティビティが 001-399 に調整される
◦ DS-2 のエフェクティビティが 601-999 に調整される
| | 変更ディレクティブと、それらから生成される変更作業は、重複するエフェクティビティの範囲に影響を与えることがあります。このような場合、変更作業を実行した設計解決策のエフェクティビティの範囲を修正する必要がある場合があります (上記の例の DS-1 と DS-2 など)。変更ディレクティブと変更作業のこのスタックの履歴が「修正スタック」テーブルに表示されます。詳細については、修正スタックテーブルについてを参照してください。 |
変更の例 2: 変更作業のための複数の設計解決策
変更作業を実行できる設計解決策は 1 つだけですが、複数の設計解決策を変更作業に関連付けることができます。これらの代替の設計解決策を候補と呼びます。これは、変更作業を実行するための候補として検討された設計解決策の履歴を保持するのに役立ちます。さらに、変更作業に関連付けられている任意の設計解決策を、候補の設計解決策から変更作業を実行する設計解決策に変更することもできます。
シナリオ 1: 設計解決策の複数の候補から 1 つを選択する
次の例では、引き続き単純なドア設計を使用して、いくつかの設計解決策が使用可能な候補として検討されている変更プロセスを示します。分析の後、1 つの設計解決策のみが、変更作業を実行する設計解決策として選択されます。システムは、分析プロセスで検討された設計解決策の候補を記録として保持します。
1. ユーザーは、変更作業 (変更作業 1) の設計解決策の候補として、2 つの設計解決策 (DS-3a と DS-3b) を作成します。各設計解決策の段階は、「候補」です。
2. ユーザーは、設計解決策の候補を分析し、「変更作業を実行」操作を実行した後、目的の設計解決策 (DS-3a) を選択します。変更作業の対象となるエフェクティビティの範囲 (400-499) で、設計解決策が更新されます。選択された設計解決策 (DS-3a) は「実行済み」段階に進み、変更作業が更新されて「解決」ステータスになります。もう一方の設計解決策の候補 (DS-3b) は、「候補」段階のままです。
シナリオ 2: 「変更作業の実行を元に戻す」を実行して別の設計解決策を選択する
変更作業のステータスが「スタディ予定」から「解決」に移行すると、設計解決策の候補を変更作業に追加したり、変更作業から除去したりできなくなります。
後日、新しい設計解決策が候補になり、変更作業を実行する既存の設計解決策を置き換える必要が生じた場合は、「変更作業の実行を元に戻す」操作を実行する必要があります。
1. 該当する変更作業 (変更作業 1) に対して、ユーザーが「変更作業の実行を元に戻す」操作を選択します。
変更作業のステータスが「解決」から「スタディ予定」に移行します。以前に変更作業を解決するために使用された設計解決策 (DS-3) が「実行済み」から「候補」に戻ります。
2. ユーザーは、必要に応じて設計解決策の候補を追加または除去します。この例では、設計解決策 DS-3a が追加されています。
3. ユーザーは、「変更作業を実行」操作を実行し、目的の設計解決策 (DS-3a) を選択します。
変更作業のステータスが「スタディ予定」から「解決」に変わります。以前の設計解決策 (DS-3) は「候補」段階のままで、新しい設計解決策 (DS-3a) は「実行済み」に変わります。変更作業の対象となるエフェクティビティの範囲で、選択された設計解決策 (DS-3a) が更新されます。