表2 严重程度分类
类 别 |
符合度要求 |
代 号 |
分 类 |
严重程度 IM100 |
强制性 |
IM110 |
危急 |
强制性 |
IM120 |
高 | |
强制性 |
IM130 |
中 | |
强制性 |
IM140 |
低 | |
强制性 |
IM150 |
无 |
2、调查
经过缺陷识别阶段后,需要对每个可能的缺陷进行调查。调查阶段主要是用来发现可能存在的其他问题以及相关的解决方案,解决方案包括"不采取任何行动"。缺陷调查阶段的主要活动包括:
记录:在缺陷调查阶段,需要记录相关的数据和信息,对缺陷识别阶段记录的信息进行更新。缺陷调查阶段记录的信息包括缺陷调查者的信息、缺陷调查的计划开始时间、计划结束时间、实际开始时间、实际结束时间、调查工作量等。
分类:在缺陷调查阶段,需要进行分类的属性包括缺陷引起的实际原因、缺陷的来源、缺陷的具体类型等。同时,对缺陷识别阶段中的分类信息,根据需要进行检查和更新。
确定影响:根据缺陷调查阶段的分析结果,对缺陷识别阶段的影响分析进行更新。
表3列举了调查阶段的支持数据。
表3 调查阶段的支持数据表格
接收确认 |
验证 |
接收日期 |
缺陷的来源 |
指定的报告号 |
缺陷识别过程的数据 |
调查员 |
|
姓名 |
|
代号或职能范围 |
|
电子邮件地址 |
|
电话号码 |
|
计划的调查开始日期 |
|
计划的调查结束日期 |
|
实际的调查开始日期 |
|
实际的调查结束日期 |
|
工时 |
|
接收确认的日期 |
|
调查使用的资料 |
|
名称 |
|
ID |
|
版本 |
|
3、改正
根据缺陷调查阶段中得到的结果和信息,就可以采取改正措施解决引起缺陷的错误。采取的行动可能是修复缺陷,也可能是针对开发过程和测试过程的改进建议,以避免在将来的项目中重复出现相似的缺陷。针对每个缺陷的修复,需要进行相关的回归测试和再测试,避免由于缺陷的修复而影响原有的功能。缺陷改正阶段的主要活动包括:
记录:在缺陷改正阶段,需要记录改正缺陷的相关支持数据信息,包括需要修改的条目、需要修改的模块、修改的描述、修改的负责人、计划修改开始的时间、计划修改完成的时间等。
分类:当合适的修改计划或者活动确定以后,需要对下面的信息进行分类:缺陷修复的优先级(例如:是马上修改、延期修改还是不修改)、缺陷的解决方法(如表4所示)、缺陷修复的改正措施等。
确定影响:对在缺陷识别阶段、缺陷调查阶段中得到的影响分析进行合适的检查,并在需要的时候进行更新。
表4 缺陷改正的分类表--解决方法
类 别 |
符合度要求 |
代 号 |
分 类 |
解决方法 AC100 |
强制性 |
AC110 |
即时解决方法 |
AC111 |
修改软件 | ||
AC112 |
更新项目文档 | ||
AC113 |
培训操作员 | ||
AC114 |
修改测试软件 | ||
AC115 |
外部供应商/第三方 | ||
强制性 |
AC120 |
最终解决方案 | |
AC121 |
修改软件 | ||
AC122 |
更新项目文档 | ||
AC123 |
培训操作员 | ||
AC124 |
修改测试软件 | ||
AC125 |
外部供应商/第三方 | ||
强制性 |
AC130 |
延期解决方案 | |
AC131 |
在以后的版本中修改 | ||
AC132 |
申请放弃 |