「软件开发PQA」质量保证指南(项目质量保证过程评审人员)

PQA人员的主要工作目标是保证活动过程的质量，而最终产品的质量则由项目经理负责，软件质量保证人员不对其负责。

组织为了有效地开展质量保证工作，必须明确质量保证人员与项目经理应当不存在任何行政隶属关系，项目经理也不应当对质量保证人员进行任何的考核与评价，质量保证人员不能承担本项目中除质量保证外的其他任何工作，以此来确保质量保证人员完全站在第三方的立场独立的开展质量保证工作。

质量保证的目的是给管理者提供项目可视性，如果质量保证活动存在过多的主观因素，那么管理者看到的将不是项目过程的真实情况，所以客观的评价对质量保证工作来讲是至关重要的。

质量保证人员针对每项活动与工作产品都要制定相应的质量保证检查表，并且根据检查表来判断当前的活动是否存在偏离以及工作产品是否符合要求。

评价活动是否有所偏离，主要审核活动的进入准则是否达到，输入是否正确，执行任务是否符合要求，活动结束是否符合完成准则以及是否具有合乎要求的输出。

在审计工作产品时，质量保证人员主要审计工作产品是否符合规程、标准等要求，一般不考虑技术问题。

另外，所有开发人员都应当接受过质量保证方面的培训，了解质量保证的目的、工作方式以及其他相关内容，充分认识质量保证工作的意义。

1) 质量保证人员对产品质量负责

质量保证人员一般只对活动过程的质量负责，其价值主要体现在过程质量上而不是最终产品质量上。
如果一个项目按照既定的过程完成，没有发生偏离，那么软件质量保证人员就算尽到了职责。

2) 质量保证人员对工作产品的审计包括发现其中的技术问题

质量保证人员对工作产品的审计主要是针对过程，例如是否采用过程所规定的模板，所有必要的内容是否都已具备等，而不是关注技术问题。

3) 质量保证人员要负责解决所发现的质量问题

质量保证的最大作用是发现问题，提供可视性，而不是解决问题。
质量保证人员发现问题后，必须及时提交给相关责任人，由相关责任人给出解决方法并予以解决。
质量保证人员则负责跟踪问题直至得到解决。
如果在相关责任人处无法得到解决，则将问题提交给项目经理。
如果仍然无法解决，则提交给高层经理。
决策人员对最终的处理结论是解决问题还是暂时搁置问题负责。

4) 质量保证人员是专门监督项目组成员的

质量保证人员从第三方、客观的角度对项目过程进行评价并将评价结论反映给管理者，从而让管理者及时了解项目实际进展与既定过程之间存在的偏差。
质量保证人员帮助项目组提高开发和管理活动的规范化、标准化，所以质量保证人员与项目组成员之间的关系并非纯粹的对立和监督的关系。

不符合项是指那些相对于项目规范、计划、标准及规程等存在的显著或明显的偏离。

PQA工程师在审核发现不符合项时，应当优先报告给不符合项的直接责任人或项目经理，尽可能在项目组内部解决不符合项问题。

对于项目组不能解决的问题，应当逐级向高层经理报告直至问题得到落实。
此外，对于影响重大的问题，PQA工程师在报告项目经理的同时，还可以将其抄送给高层经理以便尽早解决问题，降低项目风险。

“项目组不能解决”的定义：

1) PQA工程师认为是问题但项目组认为不是问题。

2) 项目经理明确表示无法解决的问题。

3) PQA工程师提交问题5个工作日后，项目组仍然未开始解决的问题。

4) 超过问题解决期限5个工作日后仍未解决的问题。

在完成过程或工作产品（服务）的评价之后，PQA工程师应及时将评价结论及不符合问题反馈给活动或工作产品（服务）的相关负责人。

PQA工程师应当记录PQA每周的工作完成情况，包括质量保证活动工作量、完成检查数、实际审计时间以及发现不符合问题等，并以报告的方式通知相关人员。

1) PQA工程师应当根据项目过程裁剪、项目计划制定《质量保证计划》，并按照质量保证计划开展PQA审计工作。

2) PQA针对组织级过程应当每季度审计一次，包括组织过程改进与维护过程（PAD/PCM）、组织级培训过程（OT），审计活动一般安排在月底进行。

3) 定期每半年或一年邀请外部QA专家对公司内PQA工作进行审计。

项目阶段

项目过程

过程审核要点

工作产品审核要点

项目计划阶段

项目策划过程

1) 项目目标与范围明确；

2) 选择了适合项目的生命周期模型；

3) 制定计划前进行了估算，估算合理；

4) 制订了项目计划和时间进度表；

5) 制订了配置管理计划及质量保证计划；

6) 进行了风险识别与评估；

7) 项目组成员都清楚自己的职责与任务；

8) 项目计划制定过程与相关干系人进行了充分的沟通；

9) 项目计划阶段的文档通过了评审，相关干系人参加了评审。

1) 选择了合适的生命周期模型并进行了合理的项目估算；

2) 合理地确定了待开发的工作产品；

3) 有合理的时间进度表；

4) 对识别出的风险分析了其发生概率和影响程度，并对风险进行了优先级排序。

需求阶段

需求开发过程

1) 完成了需求调研并形成《用户需求调研报告》；

2) 完成了《产品需求规格说明书》；

3) 《产品需求规格说明书》经过评审，评审的组织工作符合过程的要求；

4) 建立《需求跟踪矩阵》确保需求的双向可跟踪性；

5) 需求的相关文档已经纳入配置管理并已基线化；

6) 确保相关干系人介入了需求开发活动；

7) 如果需求发生了变更，明确进行了记录。

1) 产品需求规格说明书包括了所有的系统需求；

2) 每个需求都在项目的范围内；

3) 简明、无二义性地表达了每个需求；

4) 每个需求都没有内容上和语法上的错误；

5) 每个需求都是可验证、可跟踪的。

设计阶段

设计过程

1) 对每个可选的解决方案进行了评估；

2) 编写了详细设计说明书；

3) 详细设计说明书通过了评审；

4) 详细设计文档已经纳入配置管理并已基线化；

5) 明确记录设计变更。

1) 符合模板的要求，内容完整；

2) 详细设计与软件需求规格说明书的要求一致；

3) 描述了各子系统的功能模块结构；

4) 各功能模块功能点的设计内容完整、准确、易于理解。

实现阶段

编码过程

1) 在编码工作开始前统一了编码的规范性要求；

2) 形成了代码走读报告或代码审查报告。

1) 在每个源文件的头部、每个函数或过程的前面有必要的注释信息；

2) 当代码比较长，特别是有多重嵌套时，在一些段落的结束处加注释；

3) 变量、函数的命名规范。

系统测试阶段

系统测试过程

1) 编写了测试计划；

2) 编写了测试用例；

3) 针对所有的测试用例均进行了测试；

4) 测试过程中发现的BUG均已提交；

5) 有明确的责任人对BUG的修复进行跟踪；

6) 形成了测试报告并通过了评审。

1) 测试计划中描述的测试范围；和测试目标清晰、明确；

2) 测试用例与需求/设计对应；

3) 测试用例中的步骤描述可行；

4) 测试报告对问题进行了分类统计和分析；

5) 测试报告结论清晰明确。

交付阶段

项目交付过程

（实施、交付）

1) 制订了实施计划；

2) 填写了培训记录表；

3) 安装、试运行中发现的问题进行了记录；

4) 提交了安装、试运行中发现的问题并对问题的解决情况进行了跟踪；

5) 形成系统试运行报告。

1) 实施计划可行；

2) 培训记录表完整；

3) 安装、试运行问题记录中包括的问题完整；

4) 系统试运行报告中的各类状态问题的统计准确；

5) 系统试运行报告中有甲乙双方的签字。

结项阶段

项目总结过程

1) 进行了全面的项目总结；

2) 项目组成员均参与了项目总结工作；

3) 形成了项目总结报告和质量保证总结报告；

4) 项目成果及资料纳入公司过程财富库。

1) 项目总结报告中对进度、工作量、规模、成本等方面实际与计划出现的偏差进行了分析；

2) 项目总结报告中对好的经验的总结充分、具体并值得推广；

3) 质量保证总结报告的内容客观、全面、准确。

整个生命周期

项目跟踪过程

1) 根据软件项目计划中的项目跟踪计划开展了项目跟踪活动；

2) 及时填写了软件项目跟踪表；

3) 定期举行项目会议，并按时提交项目周报；

4) 中型及以上规模的项目的每个里程碑处对项目的进度、成本、工作量、缺陷等情况进行了全面的检核；

5) 相关干系人能够及时了解到项目的进展情况。

1) 项目跟踪表填写完整；

2) 项目跟踪表中的数据准确；

3) 项目周报中的内容填写完整；

4) 项目里程碑报告中的内容填写完整。

评审过程

1) 及时发出了评审通知并提出了明确的预审要求；

2) 评审人员在正式评审前进行了预审，填写了个人评审记录并反馈给了评审主持人；

3) 及时形成了评审报告；

4) 评审报告发给了所有参加评审的人员。

1) 评审通知中提出了明确的预审要求；

2) 个人评审记录中填写了符合预审要求的评审意见；

3) 评审报告的内容完整，评审报告中有明确的评审结论并有评审组长的签字；

4) 评审报告中的每个缺陷均明确了责任人和解决期限。

配置管理过程

1) 依据配置管理计划建立了配置库，权限分配符合要求；

2) 项目文档的名称符合文档命名规范；

3) 按照配置管理计划的要求及时创建了基线；

4) 定期填写配置项状态报告；

5) 对每个经SCCB批准的变更进行了记录和跟踪。

1) 配置库的结构完整、正确；

2) 配置库基线的内容完整、正确；

3) 配置项的版本正确；

4) 配置项状态报告的内容完整，与配置项的实际状态保持一致；

5) 需求变更跟踪表填写完整。