工件:
|
![]() |
变更请求 用于记录和跟踪变更产品的请求。这提供了决策的记录,并(在有适当评价流程的情况下)确保请求的变更影响得以考虑。 |
---|---|
角色: | 变更控制管理员 |
可选/发生: | 必需。按需要的次数进行。 |
模板和报告: |
|
示例: |
|
UML 表示: | 不适用。 |
更多信息: |
活动的输入: | 活动的输出: |
在软件系统初创期间系统发展时和随后在实时环境中的日常操作中使用与维护系统时,进行变更一直是开发软件系统工作所必需的。变更请求 还被冠以多种名称,如 CR、缺陷、错误、故障和扩展请求。适当地获取和管理这些请求可确保对系统的变更是受控制的,这样就可预测变更对系统的影响。某些导入类型的 变更请求 包括:
扩展请求由各种涉众用来请求他们希望包括在产品中的未来功能。这种涉众请求获取并综合对涉众需要的理解。
缺陷报告所提供的作品的异常或故障。缺陷包括在生命周期早期阶段发现的诸如遗漏和不完善等情况,或是需要在软件中隔离和更正的故障症状。缺陷也可能包括不符合软件合理行为的现象(如可用性问题)。
缺陷用于表明问题的详细信息,启用更正性操作和决定并跟踪这些操作的进行。以下人员的 CR 用途:
项目:
变更请求编号:
变更请求类型:(问题或扩展)
标题:
提交日期:
发起者:
变更请求优先级:
当前问题描述:
关键故障:
损害:
扩展:
新的需求:
观察到问题时所处的情况:
当前环境:硬件
操作系统
编译器
当前问题的根源:
当前问题的成本或节约影响:
所提议变更的描述:
实施所提议的变更的估计成本:
操作:
已批准:
未批准:
已延迟:
所提议变更的描述:
受影响的配置项:
类别:
错误修正:
扩展:
新的特性:
其它:
实施所提议的变更的估计成本:
实施者:
实施变更的实际时间:
分析:
实施:
测试:
记录:
受影响的代码行数:
测试方法:
检查
分析
演示
测试:
测试平台:
测试用例:
已批准和已接受的变更:
以下属性在决定任何已提交的 CR 时都是有用的:
变更的大小
- 有多少现有的工作将必须变更?
- 将需要添加多少新工作?
可选方案
- 有吗?
复杂性
- 所提议的变更容易实施吗?
- 进行此变更可能有什么后果?
严重性
- 不实施此请求有什么影响?
- 是否丢失了相关的工作或数据?
- 这是扩展请求吗?
- 这是小麻烦吗?
调度
- 何时需要变更?
- 可行吗?
影响
- 进行变更会有什么后果?
- 不进行变更会有什么后果?
成本
- 进行此变更所节约的成本是多少?
与其它变更的关系
- 其它变更将取代该变更、使该变更无效还是该变更依赖于其它变更?
测试
- 需要进行任何特殊测试以验证变更成功吗?
变更管理准则通常是在项目生命周期的早期制订或建立的。同样,CR 对于变更流程是不可或缺的,可以在项目进行期间随时提出。
缺陷的主要来源是由于执行了集成、系统和性能测试。但是,缺陷可能在软件开发生命周期内随时出现,并包括确定缺少的或不完整的用例、测试用例或文档。
任何项目成员均应能够提出变更请求。但是,需要以适合软件项目环境的方式针对相关的决定工作来复审和批准这些变更。对于较大的团队或更正式的文化习惯,通常由变更请求提出者的主管作出批准。在许多情况下,变更请求的最终仲裁由诸如变更控制委员会(CCB)之类的复审小组作出。
变更控制管理员 角色负责 变更请求 的完整性,确保:
而 变更控制管理员 角色通常负责管理这些请求,就扩展请求来说,变更控制管理员 通常与系统分析人员和体系结构角色协作评价变更。
精确标识、描述和跟踪缺陷所必需的实际字段和数据是变化的,并依赖于所实施的标准、指导方针和变更控制系统。
将变更请求存储在数据库或变更请求管理系统中通常是更有效的,这样就更容易管理变更请求(例如,按优先级排序、跟踪分配和完整状态等等)。对于小型项目,一个电子表格可能就足够了。
对于小型项目,您可以将缺陷作为简单列表进行管理(例如,使用您偏爱的电子表格),对于您需要跟踪变更请求的每个属性使用单独一列。这仅用于管理小型系统,当所涉及人员的数量和缺陷数量增加时,将需要开始使用更灵活的缺陷跟踪系统。
Rational Unified Process
|