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

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

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

文档编号：

文件类型：

编写：

审核：

文件状态：

受控

受控范围：

公司

项目名称

评审时间

评审性质

预审

评审类别

[]计划[√]需求[]设计[]测试[]验收[]总结

评审任务

预审问题

No.

问题描述

需求编写者

评审员

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

然后，质管人员根据评审结果，填写《需求分析过程检查表》：

检查内容

实施情况

评价

（10分制）

是否对项目的需求分析和管理活动分配任务和进度？

□是

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

□需求分析活动描述

□责任人

□否（说明原因）：

是否对用户的需求进行收集？

□项目需求调研

□项目功能清单

□其他用户文档

□否（原因说明）：

□可选

是否对用户需求进行检查并与用户的一致？

□项目需求调研评审

□用户代表确认/签字

□项目经理确认/签字

□其他人员确认

系统分析人员是否接收过相关培训？

□已具备能力

□正式培训

□小组培训

□自学

系统分析结果是否形成文档

□需求规格说明书/需求表

□评审问题清单（可选）

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

□项目评审表

□项目评审问题追踪表

□评审人员签字

□批准人确认/签字

□评审时间

□验证人签

□SQA人员验证

□系统功能清单

文档格式是否正确？

□是

□文件编号

□配置项编号

□项目版本号

□审核人

□审核时间

□批准人

□批准时间

□符合模板

需求规格说明书是否按计划完成？

□按计划完成：

□提前完成并评审

□按计划完成并评审

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

□未按计划完成，延迟天

□采取纠正措施

需求是否被标识、管理、度、跟踪和关闭？

□需求跟踪矩阵表：

□需求被唯一标识

□需求状态被描述

□统计需求个数

□没有变更

作为潜在问题的需求，在需求说明书中是否被标识？

□潜在问题被描述

□潜在问题被追踪至关闭

□其他说明：

；

□不适用

配置人员是否管理项目的配置情况？

□管理需求基线

□SCM基线报告（频率）

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

SQA是否定期检查项目的需求分析活动，标识偏离项目计划或组织结构的内容？

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

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

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

评审问题跟踪表

编写者：

评审

跟踪问题

缺陷级别

记录员签名

项目经理确认

问题修改

问题修改后描述

是否解决

作者签名

2设计阶段质量控制

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

项目设计人员完成设计文档后，填写设计《预审问题表》，设计《预审问题表》提交给每个评审人员，进行设计文档评审，然后质管人员根据评审结果填写《设计分析过程检查表》：

是否形成概要设计说明书？

□批准人签字

□验证人签字

是否形成详细设计说明书？

概要设计说明书是否按计划完成？

详细设计说明书是否按计划完成？

□管理设计基线

□SCM基线变更状态报告

（频率）

SQA是否定期检查项目的需求管理活动，标识偏离项目计划或组织结构的内容？

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

3开发阶段质量控制

3.1编码规范

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

详见《编码规范》

3.2编码过程检查

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

是否进行代码走查？

□频率和形式：

□走查问题被跟踪和解决

□重大缺陷和问题被记录

□其他情况：

编码是否按形成文档的准则执行？

□编码方法经过批准

□采用文档和编程规范

□自定义规范

源代码是否进行配置管理？

□采用配置工具：

□配置库管理：

代码的变更是否被标识，检查和关闭？

□变更记录

□变更批准

□修改说明

□修改人和修改时间记录

□变更被检查和关闭

单元测试是否进行？

□和规程要求一致

□单元测试用例

□单元测试分析报告

□BUG统计

□无记录要求；

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

3.3开发问题跟踪

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

4测试阶段质量控制

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

是否有测试计划？

□系统

□集成

□其他情况

是否有测试用例？

测试计划是否按计划完成？

□未按计划完成，延迟天

□否（说明原因）

测试用例是否按计划完成？

是否量化测试进程，测试是否按计划执行？

□测试进度安排

□测试人员安排

□监督测试进度

测试变更是否遵守变更流程？

□变更请求

□修改描述

□变更通知

□新版本发布

是否形成测试需求与功能需求的追溯表？

□需求跟踪矩阵表

测试缺陷和结果是否形成记录？

生成缺陷和测试覆盖率的总结报告？

□测试分析报告

□测试问题报告

更新的缺陷是否经过回归测试，确认正确，结果形成记录？

□取用版本正确

□验证人

□缺陷描述

测试中是否采用测试工具或测试程序？

□测试工具

□测试工具版本

□测试程序说明

□纳入配置受控库

是否定义了评估测试结果的标准？

□测试完成标准说明

测试完成后，是否进行测试的技术检查？

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

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

□项目验收评审

□验收运行程序

□管理测试基线

SQA是否定期检查项目的测试活动，标识偏离项目计划或组织结构的内容？

□软件过程审计报告

最后要跟踪问题，直到全部的BUG解决，满足需求；

存在的问题需要填写《评审问题跟踪表》。

5维护阶段质量控制

系统上线以后，由维护人员来保证系统的正常运行，对于维护阶段的质量控制，维护人员要提交《项目维护报告》：

项目维护周报

部门名称：

本周时间：

年月日—月日

维护内容

XX项目

维护类型

维护事项

故障现象

处理结果

维护人员

预防性维护

日常性维护

突发性维护

其他

本周任务量统计

维护量统计

备注

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

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

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

合计

直接领导：

相关人员要对项目维护报告进行评审，检查系统在运行过程中的缺陷，形成《系统运行问题表》，对于不满足需求的缺陷和运行中存在的其他缺陷进行修改。