软件项目质量控制和管理规范1【精选文档】

软件项目质量控制和管理

规范

版本V1。0

项目编号 记录号 总页数 编制 200140806—001 正文 22页 文件编号 文件版本 附录 审核 V1.0 密级 年 月 日 机秘 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项目 突发性维护 其他 本周任务量统计 维护类型 预防性维护 日常性维护 维护量统计 备注 目的为了防止某类事情的发生,而产生的维护任务。 每个工作日，必须的执行的周期性的维护任务。 维护事项 维护内容 故障现象 处理结果 维护人员 突发性维护 其他 合计 在非工作日，产生的维护任务. 直接领导： 相关人员要对项目维护报告进行评审，检查系统在运行过程中的缺陷，形成《系统运行问题表》，对于不满足需求的缺陷和运行中存在的其他缺陷进行修改.