此场景描述了针对此方法的典型 Rational® Change 和 DCM 工作流程:
此外,可能还需要将任务从开发数据库复制回主产品管理数据库。通过此操作,可以创建报告,并使产品经理能够及时了解有关任务进度的信息。在其他情况下,已完成任务的详细信息可能已足够,并且传输集可能会排除不完整的任务。 同样在其他情况下,可能不必将任何任务从开发数据库传输到主产品管理数据库。
如果需要进行选择性复制,那么变更请求查询通常基于产品名称或产品子系统(并且可能还基于变更请求的状态)。在此类情况下,传输集不得排除已导入的对象 - 否则,永远都不会将已导入的对象移交回主产品管理数据库。
如果使用样本方法 2,那么有时需要进行特殊处理。
当 Rational Change 用于推迟已分配的变更请求时,还会推迟所有关联的已分配任务。当重新分配变更请求时,会再次分配所有关联的已推迟任务。
在此场景中,可能会推迟已分配并在开发数据库中进行处理的变更请求,并将其移交回主产品管理数据库。稍后,可能会重新分配此变更请求。但是,主产品管理数据库中可能不存在关联的任务。即使存在,也无法在其中修改这些任务。
为处理这一情况,Rational Change Distributed 会在接收操作期间检查变更请求。在此示例中,Rational Change Distributed 会查找在开发数据库中接收的处于已分配状态的变更请求。Rational Change Distributed 会检查关联的已推迟任务并进行重新分配。自动转变的任务的详细信息包含在 DCM 电子邮件通知中。
在大多数情况下,缺省的 Rational Change Distributed 模型参数就已够用,前提是您使用以下一种或全部两种实施:
缺省情况下,当接收到对象时,在接收数据库中会复制从该对象到其他对象的所有关系。此外,会删除接收数据库中存在但传输的数据中不存在的所有其他相应关系。
以下是 Rational Change 中的主要关系:
由于图中所示的对象关系,当仅将部分任务复制回主产品管理数据库时会发生问题:如果将变更请求复制到开发数据库,那么此变更请求只和部分(而非全部)相应的任务关联。缺省情况下,在 DCM 接收操作期间,其他任务与变更请求无关联。
要避免此问题,请使用与 Rational Change 生命周期关联的正确 DCM 工作流程。请确保所有关联任务都位于变更请求对象所在的数据库中,或者在接收到变更请求时禁用映像处理。此操作会除去所有指定的实施限制;但是,不会复制任务删除或关系除去操作。