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

精品word文档 值得下载 值得拥有----------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------

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

版本V1.0

项目编号

文件编号

记录号
200140806-001
文件版本
V1.0
总页数

正文
22页
附录

密级
机秘
编制
2014年 8月 6 日
审核
年 月 日

2014年8月6日

1 需求阶段质量控制
需求阶段的质量控制最重要的手段是要规范填写质量控制文档并进行评审。需求人员完成需求文档以后，填写需求《预审问题表》：
预审问题表

文档编号：

文件类型：

编 写：

审核：

文件状态：
受控

受控范围：
公司
项目名称

项目编号

评审时间

评审性质
预审
评审类别
[ ]计划 [√]需求 [ ]设计 [ ]测试 [ ]验收 [ ]总结
评审任务

预审问题
No.
问题描述
需求编写者
评审员

《预审问题表》提交给每个评审人员，进行需求文档评审。然后，产品经理根据评审结果，填写《评审问题跟踪表》：

评审问题跟踪表

文档编号：

文件类型：

编 写 者：

文件状态：
受控

受控范围：
公司
项目名称

项目编号

评审时间

评审性质
评审
评审类别
[ ]计划 [√]需求 [ ]设计 [ ]测试 [ ]验收 [ ]总结
跟踪问题
No.
问题描述
缺陷级别

记录员签名

项目经理确认

问题修改

问题修改后描述
是否解决

作者签名

项目经理确认

2 设计阶段质量控制
设计阶段的质量控制手段是要规范填写质量控制文档并进行设计文档的评审。项目设计人员完成设计文档后，填写设计《预审问题表》，设计《预审问题表》提交给每个评审人员，进行设计文档评审，然后质管人员根据评审结果填写《评审问题跟踪表》：
3 开发阶段质量控制
3.1 编码规范
对于开发阶段，编码规范非常重要，每个人都要遵循编码规范。详见《编码规范》
3.2 编码过程检查
系统的每个模块完成以后，要根据情况进行编码过程检查，来确认编码过程是否遵守规范。
检查内容
实施情况
评价
（10分制）
是否进行代码走查？
□ 是
□ 频率和形式：
□ 走查问题被跟踪和解决
□ 重大缺陷和问题被记录

□ 否（说明原因）：
□其他情况：
编码是否按形成文档的准则执行？
□ 是
□ 编码方法经过批准
□ 采用文档和编程规范
□ 自定义规范

□ 否（说明原因）：
源代码是否进行配置管理？
□ 是
□ 采用配置工具：
□ 配置库管理：

□ 否（说明原因）：
代码的变更是否被标识，检查和关闭？
□ 是
□ 变更记录
□ 变更批准
□ 修改说明
□ 修改人和修改时间记录
□ 变更被检查和关闭

□ 否（说明原因）：
单元测试是否进行？
□ 是
□ 和规程要求一致
□ 单元测试用例
□ 单元测试分析报告
□ BUG统计
□ 无记录要求；

□ 否（说明原因）：
SQA是否定期检查项目的编码过程活动，标识偏离项目管理或组织结构的内容？
□ 是
□ 软件过程审计报告(频率 )
□ 审计报告分发给相关人员

3.3 开发问题跟踪
开发过程中，每个模块根据《编码过程检查表》上没有满足的项，技术总监填写开发《评审问题跟踪表》。
4 测试阶段质量控制
测试阶段的质量控制手段是使用bug管理工具进行缺陷管理和跟踪，直到系统满足测试退出标准或用户需求，测试人员提交系统《测试报告》，对于《测试报告》，根据需求来评审测试情况，首先要填写测试《预审问题表》，根据评审结果再填写《软件测试检查表》：
检查内容
实施情况
评价
（10分制）
是否有测试计划？
□ 系统
□ 评审问题清单（可选）
□ 评审通知和确认表（可选）
□ 项目评审表
□ 项目评审问题追踪表
□ 评审人员签字
□ 批准人签字
□ 评审时间
□ 验证人签字
□ SQA人员验证

□ 集成
□ 其他情况
是否有测试用例？
□ 系统
□ 评审问题清单（可选）
□ 评审通知和确认表 （可选）
□ 项目评审表
□ 项目评审问题追踪表
□ 评审人员签字
□ 批准人签字
□ 评审时间
□ 验证人签字
□ SQA人员验证

□ 集成
□ 其他情况

文档格式是否正确？
□ 是
□ 文件编号
□ 配置项编号
□ 项目版本号
□ 审核人
□ 审核时间
□ 批准人
□ 批准时间
□ 符合模板

□ 否（说明原因）：
测试计划是否按计划完成？
□ 是
□ 按计划完成：
□ 提前完成并评审
□ 按计划完成并评审
□ 按计划完成，评审延迟。
□ 未按计划完成，延迟 天
□ 采取纠正措施

□ 否（说明原因）
测试用例是否按计划完成？
□ 是
□ 按计划完成：
□ 提前完成并评审
□ 按计划完成并评审
□ 按计划完成，评审延迟。
□ 未按计划完成，延迟 天
□ 采取纠正措施

□ 否（说明原因）
是否量化测试进程，测试是否按计划执行？
□ 是
□ 测试进度安排
□ 测试人员安排
□ 监督测试进度

□ 否（说明原因）：
测试变更是否遵守变更流程？
□ 是
□ 变更请求
□ 修改描述
□ 变更批准
□ 变更通知
□ 新版本发布

□ 否（说明原因）：
是否形成测试需求与功能需求的追溯表？
□ 是
□ 需求跟踪矩阵表

□ 否（说明原因）：
测试缺陷和结果是否形成记录？生成缺陷和测试覆盖率的总结报告？
□ 是
□ 测试分析报告
□ 测试问题报告

□ 否（说明原因）：
更新的缺陷是否经过回归测试，确认正确，结果形成记录？
□ 是
□ 取用版本正确
□ 测试问题报告
□ 验证人
□ 缺陷描述

□ 否（说明原因）：
测试中是否采用测试工具或测试程序？
□ 是
□ 测试工具
□ 测试工具版本
□ 测试程序说明
□ 纳入配置受控库

□ 否 （说明原因）：
是否定义了评估测试结果的标准？
□ 是
□ 测试完成标准说明

□ 否（说明原因）
测试完成后，是否进行测试的技术检查？测试验收后的产品是否可集成为验收测试版本？
□ 是
□ 项目组成员或相关人员确认
□ 项目验收评审
□ 验收运行程序
□ 测试分析报告

□ 否（说明原因）：
配置人员是否管理项目的配置情况？
□ 是
□ 管理测试基线
□ SCM基线报告 (频率 )
□ SCM基线变更状态报告
(频率 )
□ 配置报告分发给相关人员

□ 否（说明原因）：
SQA是否定期检查项目的测试活动，标识偏离项目计划或组织结构的内容？
□ 是
□ 软件过程审计报告
□ 审计报告分发给相关人员

最后要跟踪问题，直到全部的BUG解决，满足需求；存在的问题需要填写《评审问题跟踪表》。
5 维护阶段质量控制
系统上线以后，由维护人员来保证系统的正常运行，对于维护阶段的质量控制，维护人员要提交《项目维护报告》：
项目维护周报

部门名称： 本周时间：年 月 日— 月 日
项目名称
维护内容
XX项目
维护类型
维护事项
故障现象
处理结果
维护人员
预防性维护

日常性维护

突发性维护

其他

本周任务量统计
维护类型
维护量统计
备注
预防性维护

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

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

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

合计

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