在单个数据库中输入所有变更请求

第二种方法是在一个数据库中输入所有变更请求。此数据库可以是主产品管理数据库,公司通过该数据库控制对大量应用程序的变更。

此场景描述了针对此方法的典型 Rational® Change 和 DCM 工作流程:

  1. 在主产品管理数据库中输入变更请求。
  2. 在该数据库中验证、拒绝变更请求或将其标记为重复。
  3. 将变更请求分配给产品开发小组负责人,然后将其移交给对应的开发数据库。
  4. 在一个开发数据库中输入和分配所有关联的任务。
  5. 完成所有任务后,产品开发小组负责人解决变更请求,并将其移交给主产品管理数据库。
  6. 主产品管理数据库中的结束者结束此变更请求,或者将其发回以在开发数据库中进行返工。

    此外,可能还需要将任务从开发数据库复制回主产品管理数据库。通过此操作,可以创建报告,并使产品经理能够及时了解有关任务进度的信息。在其他情况下,已完成任务的详细信息可能已足够,并且传输集可能会排除不完整的任务。 同样在其他情况下,可能不必将任何任务从开发数据库传输到主产品管理数据库。

如果需要进行选择性复制,那么变更请求查询通常基于产品名称或产品子系统(并且可能还基于变更请求的状态)。在此类情况下,传输集不得排除已导入的对象 - 否则,永远都不会将已导入的对象移交回主产品管理数据库。

特例

如果使用样本方法 2,那么有时需要进行特殊处理。

当 Rational Change 用于推迟已分配的变更请求时,还会推迟所有关联的已分配任务。当重新分配变更请求时,会再次分配所有关联的已推迟任务。

在此场景中,可能会推迟已分配并在开发数据库中进行处理的变更请求,并将其移交回主产品管理数据库。稍后,可能会重新分配此变更请求。但是,主产品管理数据库中可能不存在关联的任务。即使存在,也无法在其中修改这些任务。

为处理这一情况,Rational Change Distributed 会在接收操作期间检查变更请求。在此示例中,Rational Change Distributed 会查找在开发数据库中接收的处于已分配状态的变更请求。Rational Change Distributed 会检查关联的已推迟任务并进行重新分配。自动转变的任务的详细信息包含在 DCM 电子邮件通知中。

在大多数情况下,缺省的 Rational Change Distributed 模型参数就已够用,前提是您使用以下一种或全部两种实施:

以下是 Rational Change 中的主要关系:

显示 Rational Change 中主要关系的图像。

由于图中所示的对象关系,当仅将部分任务复制回主产品管理数据库时会发生问题:如果将变更请求复制到开发数据库,那么此变更请求只和部分(而非全部)相应的任务关联。缺省情况下,在 DCM 接收操作期间,其他任务与变更请求无关联。

要避免此问题,请使用与 Rational Change 生命周期关联的正确 DCM 工作流程。请确保所有关联任务都位于变更请求对象所在的数据库中,或者在接收到变更请求时禁用映像处理。此操作会除去所有指定的实施限制;但是,不会复制任务删除或关系除去操作。

注: 缺省情况下,任务及其关联对象不存在此问题。Rational Change Distributed 的缺省行为是跳过接收在接收数据库中可修改的任务。

反馈