变更流程说明.xls

变更流程说明 Assigned Closed Duplicate Opened Postponed Reject Resolved Submitted Verified 变更请求管理 (CRM) 流程活动示例的说明： 活动 说明 角色 提交变更请求 (CR) 项目的任何涉众均可提交变更请求 (CR)。通过将变更请求状态设置为已提交，变更请求被记录到变更请求追踪系统中（例如 ClearQuest）并放置到 CCB 复审队列中。 提交者 复审变更请求 (CR) 此活动的作用是复审已提交的变更请求。在 CCB 复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。 CCB 确认重复或拒绝 如果怀疑某个变更请求为重复的请求或已拒绝的无效请求（例如，由于操作符错误、无法重现、工作方式等），将指定一个 CCB 代表来确认重复或已拒绝的变更请求。如果需要的话，该代表还从提交者处收集更多信息。 CCB 代表 更新变更请求 (CR) 如果评估变更请求时需要更多的信息（详细信息），或者如果变更请求在流程中的某个时刻遭到拒绝（例如，被确认为是重复、已拒绝等），那么将通知提交者，并用新信息更新变更请求。然后将已更新的变更请求重新提交给 CCB 复审队列，以考虑新的数据。 安排和分配工作 一旦变更请求被置为已打开，项目经理就将根据请求的类型（例如，扩展请求、缺陷、文档变更、测试缺陷等）把工作分配给合适的角色，并对项目时间表做必要的更新。 项目经理 进行变更 指定的角色执行在流程的有关部分中指定的活动集（例如，需求、分析设计、实施、制作用户支持材料、设计测试等），以进行所请求的变更。 这些活动将包括常规开发流程中所述的所有常规复审活动和单元测试活动。然后，变更请求将标记为已解决。 指定的角色 核实测试工作版本中的变更 指定的角色（分析员、开发人员、测试员、技术文档编写员等）解决变更后，变更将放置在要分配给测试员的测试队列中，并在产品工作版本中加以核实。 测试员 核实发布工作版本中的变更 已确定的变更一旦在产品的测试工作版本中得到了核实，就将变更请求放置在发布队列中，以便在产品的发布工作版本予以核实、生成发布说明等，然后关闭该变更请求。 CCB 代表（系统集成员） 变更请求管理 (CRM) 状态示例的说明： 状态 定义 访问控制 已提交 出现此状态的原因为：1) 提交新的变更请求；2) 更新现有的变更请求；或 3) 考虑在新的发布周期中使用已推迟的变更请求。变更请求放置在 CCB 复审队列中。 本操作的结果不会指定拥有者。 所有用户 已推迟 变更请确定为有效，但对于当前发布版来说属于“超出范围”。处于已推迟状态的变更请求将得以保留，并在以后的发布版中被重新考虑并加以使用。可以指定一个目标发布版，以表明可以提交变更请求（以重新进入 CCB 复审队列）的时间范围。 管理员 重复 处于此状态的变更请求被视作对已提交的另一个变更请求的重复。变更请求可由 CCB 复审管理员或被指定解决它的角色置于该状态中。将变更请求置于重复状态中时，将（在 ClearQuest 的“附件”选项卡上）记录它所重复的那个变更请求的编号。在提交变更请求之前，提交者应首先查询变更请求数据库，看是否已有与之相重复的变更请求。这将省去复审流程中的若干步骤，从而节省大量的时间。 应将重复变更请求的提交者添加到原始变更请求的通知列表中，以便以后将有关解决事宜通知他们。 QE 经理 开发 已拒绝 CCB 复审会议或指定的角色确定此状态中的变更请求为无效请求，或者需要提交者提供更为详细的信息。如果已经指定（提出）变更请求，则它将从解决队列中删除并重新复审。这将由 CCB 所指定的权威来予以确认。除非有必要，否则提交者无需进行任何操作。在此情况下变更请求状态将变为详细信息。考虑到可能会有新的信息，在 CCB 复审会议中将重新复审该变更请求。如果变更请求确认为无效，将被 CCB 关闭并且通知提交者。 开发经理 测试经理 详细信息 数据不足以确认已拒绝或重复的变更请求是否有效。拥有者自动变成提交者，将通知提交者提供更多数据。 已打开 对于当前发布版来说，处于此状态的变更请求已被确定为属于“范围之内”，并且亟待解决。它已定于在即将来临的目标里程碑之前得以解决。它被确定在“指定队列”中。与会者是提出变更请求并将其放入解决队列中的唯一权威。如果发现优先级为第二或更高的变更请求，应立即通知 QE 经理或开发经理。此时，他们可以决定召开紧急 CCB 复审会议，或立即打开变更请求以将其放入解决队列中。 QE 部门 已指定 然后由项目经理负责已打开的变更请求，他应根据变更