软件项目质量控制和管理规范.docx

软件项目质量控制和管理规范.docx

《软件项目质量控制和管理规范.docx》由会员分享，可在线阅读，更多相关《软件项目质量控制和管理规范.docx（18页珍藏版）》请在冰豆网上搜索。

软件项目质量控制和管理规范

软件项目质量控制和管理

规范

项目编号

文件编号

GLGF-RJ上IX

记录号

[2010]-公文001号

文件版本

V1.0

总页数

24页

正文

22页

附录

密级

机秘

编制

2010年1月15曰

审核

年月曰

2010年2月15日

1需求阶段质量控制

需求阶段的质量控制最重要的手段是要规范填写质量控制文档并进行评审。

需求人员完成需求文档以后，填写需求《预审问题表》：

预审问题表

文档编号：

文件类型：

编写：

审核：

文件状态：

受控

受控范围：

公司

项目名称

项目编号

评审时间

评审性质

预审

评审类别

［］计划W］需求［］设计［］测试□验收

［］总结

评审任务

预审问题

No.

问题描述

需求编写者

评审员

预审问题表》提交给每个评审人员，进行需求文档评审。

然后，质管人员

根据评审结果，填写《需求分析过程检查表》：

检查内容

实施情况

评价

（10分制）

是否对项目的需求分析

□是

□项目开发计划书/项目开发计划表

和管理活动分配任务和

□否（说明原因）：

□需求分析活动描述

进度？

□责任人

是否对用户的需求进行

□是

□项目需求调研

收集？

□否（原因说明）:

□项目功能清单

□可选

□其他用户文档

是否对用户需求进行检

查并与用户的一致？

□是

□项目需求调研评审

□用户代表确认/签字

□项目经理确认/签字

□其他人员确认

□否（原因说明）：

□可选

系统分析人员是否接收

过相关培训？

□是

□已具备能力

□正式培训

□小组培训

□自学

□否（原因说明）：

系统分析结果是否形成

文档

□需求规格说明书/

需求表

□评审问题清单（可选）

□评审通知和确认表（可选）

□项目评审表

□项目评审问题追踪表

□评审人员签字

□批准人确认/签字

□评审时间

□验证人签

□SQA人员验证

□系统功能清单

□否（原因说明）：

文档格式是否正确？

□是

□文件编号

□否（说明原因）：

□配置项编号

□项目版本号

□审核人

□审核时间

□批准人

□批准时间

□符合模板

需求规格说明书是否按

计划完成？

□是

□按计划完成：

□提前完成并评审

□按计划完成并评审

□按计划完成，评审延迟。

□未按计划完成，延迟

□采取纠正措施

天

□否（说明原因）：

需求是否被标识、管理、

度、跟踪和关闭？

□是

□需求跟踪矩阵表：

□需求被唯一标识

□需求状态被描述

□统计需求个数

□否（说明原因）:

□没有变更

作为潜在问题的需求，

□是

□潜在问题被描述

□潜在问题被追踪至关闭

□其他说明：

□否（原因说明）：

在需求说明书中是否被

标识？

□不适用

配置人员是否管理项目

□是

□管理需求基线

的配置情况？

□否（说明原因）：

□SCM基线报告（频率

）

□配置报告分发给相关人员

SQA是否定期检查项

□是

□软件过程审计报告（频率

）

目的需求分析活动，标

□否（说明原因）：

□审计报告分发给相关人员

识偏离项目计划或组织

结构的内容？

在需求文档评审后，质管人员要进行问题跟踪，填写需求《评审问题跟踪表》，直到需求文档满足评审为止。

评审问题跟踪表

文件类型:

文档编号:

编写者：

项目名称

项目编号

评审时间

评审性质

评审

评审类别

［］计划［V］需求［］设计［］测试［］验收［］总结

跟踪问题

No.

问题描述

缺陷级别

文件状态:

受控

受控范围:

公司

记录员签名

项目经理确认

问题修改

问题修改后描述

是否解决

作者签名

项目经理确认

2设计阶段质量控制

设计阶段的质量控制手段是要规范填写质量控制文档并进行设计文档的评

审。

项目设计人员完成设计文档后，填写设计《预审问题表》，设计《预审问题

表》提交给每个评审人员，进行设计文档评审，然后质管人员根据评审结果填写

设计分析过程检查表》：

检查内容

实施情况

评价

（10分制）

是否形成概要设计说明

书？

□是

□评审问题清单（可选）

□评审通知和确认表（可选）

□项目评审表

□项目评审问题追踪表

□评审人员签字

□批准人签字

□评审时间

□验证人签字

□SQA人员验证

□否（说明原因）：

是否形成详细设计说明

书？

□是

□评审问题清单（可选）

□评审通知和确认表（可选）

□项目评审表

□项目评审问题追踪表

□评审人员签字

□批准人签字

□评审时间

□验证人签字

□SQA人员验证

□否（说明原因）:

□可选

文档格式是否正确？

□是

□文件编号

□配置项编号

□项目版本号

□审核人

□审核时间

□批准人

□批准时间

□符合模板

□否（说明原因）：

概要设计说明书是否按

计划完成？

□是

n按计划完成:

□提前完成并评审

□按计划完成并评审

□按计划完成，评审延迟。

□未按计划完成，延迟天

□采取纠正措施

□否（说明原因）：

详细设计说明书是否按

计划完成？

□是

n按计划完成:

□提前完成并评审

□按计划完成并评审

□按计划完成，评审延迟。

□未按计划完成，延迟天

□否（说明原因）：

配置人员是否管理项目

□是

□管理设计基线

的配置情况？

□否（说明原因）：

□SCM基线报告（频率

□SCM基线变更状态报告

（频率）

□配置报告分发给相关人员

）

□是

□软件过程审计报告（频率

）

SQA是否定期检查项目的需

□否（说明原因）：

□审计报告分发给相关人员

求管理活动，标识偏离项目计

划或组织结构的内容？

在设计文档评审后，质管人员要填写设计《评审问题跟踪表》，直到设计文档满足评审。

3开发阶段质量控制

3.1编码规范

对于开发阶段，编码规范非常重要，每个人都要遵循编码规范。

详见《编码

规范》

3.2编码过程检查

系统的每个模块完成以后，要根据情况进行编码过程检查，来确认编码过程

是否遵守规范。

检查内容

实施情况

评价

（10分制）

是否进行代码走查？

□是

□频率和形式：

□走查问题被跟踪和解决

□重大缺陷和问题被记录

□否（说明原因）：

□其他情况：

编码是否按形成文档的

准则执行？

□是

□编码方法经过批准

□采用文档和编程规范

□自定义规范

□否（说明原因）：

源代码是否进行配置管

理？

□是

□采用配置工具：

□配置库管理：

□否（说明原因）：

代码的变更是否被标识，

检查和关闭？

□是

□变更记录

□变更批准

□修改说明

□修改人和修改时间记录

□变更被检查和关闭

□否（说明原因）：

单元测试是否进行？

□是

□和规程要求一致

□单元测试用例

□单元测试分析报告

□BUG统计

□无记录要求；

□否（说明原因）：

SQA是否定期检查项目的编码过程活动，标识偏离项目管理或组织结构的内容？

□是

□软件过程审计报告（频率）

□审计报告分发给相关人员

3.3开发|可题跟踪

开发过程中，每个模块根据《编码过程检查表》上没有满足的项，质管人员填写开发《评审问题

跟踪表》。

4测试阶段质量控制

测试阶段的质量控制手段是使用bug管理工具进行缺陷管理和跟踪，直到系统满足测试退出标准或用户需求，测试人员提交系统《测试报告》，对于《测试报告》，根据需求来评审测试情况，首先要填写测试《预审问题表》，根据评审结果再填写《软件测试检查表》：

检查内容

实施情况

评价

（10分制）

是否有测试计划？

□系统

□评审问题清单（可选）

□评审通知和确认表（可选）

□项目评审表

□项目评审问题追踪表

□评审人员签字

□批准人签字

□评审时间

□验证人签字

□SQA人员验证

□集成

□其他情况

是否有测试用例？

□系统

□评审问题清单（可选）

□集成

□评审通知和确认表（可选）

□项目评审表

□项目评审问题追踪表

□评审人员签字

□批准人签字

□评审时间

□验证人签字

□SQA人员验证

□其他情况

文档格式是否正确？

□是

□文件编号

□配置项编号□项目版本号

□审核人

□审核时间

□批准人

□批准时间

□符合模板

□否（说明原因）：

测试计划是否按计划完

成？

□是

□按计划完成：

n提前完成并评审

n按计划完成并评审

□按计划完成，评审延迟。

□未按计划完成，延迟天

□采取纠正措施

□否（说明原因）

测试用例是否按计划完

成？

□是

□按计划完成：

n提前完成并评审

n按计划完成并评审

□按计划完成，评审延迟。

□未按计划完成，延迟天

□采取纠正措施

□否（说明原因）

是否量化测试进程’测试

是否按计划执行？

□是

□测试进度安排

□测试人员安排

□监督测试进度

□否（说明原因）：

测试变更是否遵守变更

流程？

□是

□变更请求

□修改描述

□变更批准

□变更通知

□新版本发布

□否（说明原因）：

是否形成测试需求与功

能需求的追溯表？

□是

□需求跟踪矩阵表

□否（说明原因）：

测试缺陷和结果是否形

成记录？

生成缺陷和测

试覆盖率的总结报告？

□是

□测试分析报告

□测试问题报告

□否（说明原因）：

更新的缺陷是否经过回

□是

□取用版本正确

归测试，确认正确.结果

形成记录？

□否（说明原因）：

□测试问题报告

□验证人

□缺陷描述

测试中是否采用测试工

具或测试程序？

□是

□测试工具

□测试工具版本

□测试程序说明

□纳入配置受控库

□否（说明原因）：

是否定义了评估测试结

果的标准？

□是

□测试完成标准说明

□否（说明原因）：

测试完成后，是否进行测

试的技术检查？

测试验收后的产品是否可集成为验收测试版本？

□是

□项目组成员或相关人员确认

□项目验收评审

□验收运行程序

□测试分析报告

□否（说明原因）：

配置人员是否管理项目

的配置情况？

□是

□管理测试基线

□SCM基线报告（频率）

□SCM基线变更状态报告

（频率）

□配置报告分发给相关人员

□否（说明原因）：

SQA是否定期检查项目的测试活动，标识偏离项

目计划或组织结构的内

容？

□是

□软件过程审计报告

□审计报告分发给相关人员

最后要跟踪冋题，直到全部的BUG解决，满足需求；存在的冋题需要填写

评审问题跟踪表》

5维护阶段质量控制

系统上线以后，由维护人员来保证系统的正常运行，对于维护阶段的质量控

制，维护人员要提交《项目维护报告》：

项目维护周报

项目名称

维护内容

XX项目

维护类型

维护事项

故障现象

处理结果

维护人员

预防性维护

曰常性维护

突发性维护

其他

本周任务量统计

维护类型

维护量统计

备注

预防性维护

目的为了防止某类事情的发生，而产生的维护任务。

部门名称

本周时间：

年

月日一

月日

曰常性维护

每个工作曰，必须的执行的周期性的维护任务。

突发性维护

在非工作曰，产生的维护任务。

其他

合计

直接领导：

相关人员要对项目维护报告进行评审，检查系统在运行过程中的缺陷，形成《系

统运行问题表》，对于不满足需求的缺陷和运行中存在的其他缺陷进行修改。