このシナリオでは、この手法における標準的な Rational® Change と DCM のワークフローについて説明します。
開発データベースから主要製品管理データベースにタスクを複製し戻すことが必要な場合もあります。 この操作によりレポートを作成でき、製品マネージャーにタスクの進行状況が継続的に通知されます。 場合によっては、完了済み タスクの詳細で十分なことがあり、転送セットで未完了タスクが除外される可能性があります。 さらに別のケースでは、開発データベースから主要製品管理データベースにタスクを転送することが不要な場合もあります。
選択的な複製が必要な場合、通常、変更依頼クエリーは製品名または製品サブシステム (場合によっては、さらに変更依頼の状況) に基づいて行われます。 このようなケースでは、インポートされたオブジェクトを転送セットで除外してはなりません。これを守らない場合、インポートされたオブジェクトを再び主要製品管理データベースにハンドオーバーする操作が行われません。
サンプル手法 2 を使用する場合、特殊な処理が必要になることがあります。
Rational Change を使用して割り当て済み の変更依頼を据え置くと、関連する割り当て済み タスクも据え置かれます。変更依頼を再割り当てすると、据え置かれた関連タスクは再び割り当て済み となります。
このシナリオでは、割り当て済み で、開発データベースで処理されている変更依頼が、据え置かれ、主要製品管理データベースに返される場合があります。 その変更依頼は、後で再割り当てされる可能性があります。 ただし、関連タスクは主要製品管理データベースに存在しない場合が考えられます。 存在していた場合でも、そこでは修正できません。
この状況に対処するために、Rational Change Distributed は受信操作中に変更依頼を検査します。この例では、Rational Change Distributed は開発データベースで受信される割り当て済み 状態の変更依頼を検索します。 Rational Change Distributed は据え置かれた関連タスクがあるかを確認し、それらを再割り当てします。 自動的に遷移したタスクの詳細は DCM の E メール通知に含まれます。
デフォルトの Rational Change Distributed モデル・パラメーターは、以下のいずれか、または両方を実施する場合、ほとんどのケースで十分です。
デフォルトでは、オブジェクトを受信すると、そのオブジェクトと他のオブジェクトとの関係は受信側データベースで再現されます。 さらに、受信側データベース内に存在していても、転送されたデータには含まれないその他の該当する関係はすべて削除されます。
図に示すように、Rational Change の主な関係は次のとおりです。
図に示すオブジェクト関係により、一部のタスクのみが主要製品管理データベースに複製し戻されると問題が生じます。変更依頼が開発データベースに複製される場合、その変更依頼は該当するタスクの一部のみ (ただし、全部ではない) に関連付けられます。 デフォルトでは、DCM 受信操作中に、他のタスクは変更依頼との関連付けを解除されます。
この問題を回避するために、Rational Change ライフサイクルに関連付けられた正しい DCM ワークフローを使用してください。すべての関連タスクが変更依頼オブジェクトが存在するデータベース内にあることを確認するか、変更依頼の受信時にイメージ処理を使用不可にしてください。 この操作により、指定された実装上のすべての制限が削除されます。ただし、タスクの削除または関係の削除は複製されません。