软件质量保证[编辑]

概述

软件质量保证（SQA-Software Quality Assurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

一、简介

软件质量保证（SQA-Software Quality Assurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。

二、基本目标

目标 1: 软件质量保证工作是有计划进行的。
目标 2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。
目标 3: 将软件质量保证工作及结果通知给相关组别和个人。
目标 4: 高级管理层接触到在项目内部不能解决的不符合类问题。
目标 5: 软件质量需要全面的测试工作来保证。

三、由来

我们知道，国外很多的大公司，QA的职责就是测试（主要是系统测试），比如IBM、CA、PeopleSoft等。其实在最初，几乎所有的公司都是这样的。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少（注：我以前做的一个项目，项目经理就明确告诉我系统测试就1天，没得商量）。另外，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，事先预防的QA职能就应运而生。事先预防其实是借鉴了TQM的思想，而且也符合软件工程“缺陷越早发现越早修改越经济”的原则。这些思想的渊源还可以追溯到中国古代的典故中，比如曲突徙薪、扁鹊论医术等。

四、现状

实施CMM的企业越来越多了，CMM模型就要求建立QA角色。这里的QA类似于过程警察，主要职责是，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。在这些企业中，一般还要求QA独立于项目组，以保障评价的客观性。从国内来看，多数的QA没有技术背景，检查出的偏差多为鸡毛蒜皮，再加上自己没有令人信服的背景，领导也不支持，当然做起来就很困难了。
缺乏信任和支持只是一个方面，QA工作本身就很具挑战性。它要求QA具有软件工程的知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理的知识等等。
我们常常遇到这样的问题，改进到一定程度就很难突破，感觉心有余而力不足了，就开始郁闷了。后来通过学习、培训、交流，思想和技能得到升华，又发现了木桶中最短的那块，然后又开始改进，然后又遇到了玻璃天花板，然后……就这样处于郁闷的循环中。
假使我们掌握了所有的知识，能突破所有的玻璃天花板，那是不是QA就可以一帆风顺了。答案是否定的。QA角色定义本身就有很大的局限性。QA充当的是过程警察的角色，无论是否有意义，都专横地强制过程的执行，容易在项目组中造成敌对的关系，受到排挤，而且这种警察的姿态也破坏了团队精神。如此一来，QA工作还需要的是人际关系技能，就如我以前写的《质量平衡》和《QA应该独立于项目组吗？》一样，艺术化地处理这种关系。

五、未来

从某种程度上说，独立的QA审查机制是瀑布模型的产物。随着现代软件开发技术的演变，螺旋模型和迭代模型的兴起，QA机制正在悄然发生变化。这种变化就是从独立专职的QA向贯穿过程的兼职QA演变。在CMMI模型中，这种兼职的QA也是被允许的。为什么会发生这种改变呢？无论是XP、RUP还是其它先进的方法论，都是先产生架构，然后再增量开发，直到完成。这种模式中，需求和设计缺陷在各个迭代周期被所尽早发现和修复，质量也内建于架构和过程中，项目的成本和进度也得到保障。
到那时，是不是独立的QA就不复存在了呢？有些成熟度较低的企业还是需要的，主要是保证过程执行的有效性和评价的客观性。

六、工作内容

计划

针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：
有重点：依据企业目标以及项目情况确定审计的重点
明确审计内容：明确审计哪些活动，那些产品
明确审计方式：确定怎样进行审计
明确审计结果报告的规则：审计的结果报告给谁

审计/证实

据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。
注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。
审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

问题跟踪

对审计中发现的问题，要求项目组改进，并跟进直到解决。

七、活动

软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含：
⒈一种质量管理方法
⒉有效的软件工程技术（方法和工具）
⒊在整个软件过程中采用的正式技术评审
⒋一种多层次的测试策略
⒌对软件文档及其修改的控制
⒍保证软件遵从软件开发标准
⒎度量和报告机制
SQA与两种不同的参与者相关 —— 做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组。
软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动。
SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SQA小组完成：
⑴为项目准备SQA计划。该计划在制定项目规定项目计划时确定，由所有感兴趣的相关部门评审。
·需要进行的审计和评审；
·项目可采用的标准；
·错误报告和跟踪的规程；
·由SQA小组产生的文档；
·向软件项目组提供的反馈数量。
⑵参与开发项目的软件过程描述。评审过程描述以保证该过程与组织政策，内部软件标准，外界标准以及项目计划的其他部分相符。
⑶评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。记录、跟踪与过程的偏差。
⑷审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。对产品进行评审，识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。
⑸确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。
⑹记录所有不符合的部分并报告给高级领导者。

八、质量保证

IES 规约不完整或规格说明错误
MCC ；未理解用户意图
IDS 故意偏离规格说明
VPS 违背编程标准
EDR 数据表示有错
ICI ；构件接口不一致
EDL 设计逻辑有错
IET ；测试不完全或有错
ⅡD ；不准确或不完整的文档
PLT ；设计的程序设计语言翻译错
HCI ；不清晰或不一致的人机界面
MIS ；杂项错误
按严重，一般和微小级别统计各类错误的次数所占百分比，以及所有错误的数量及百分比。例如，建立一张类似如下的表格。
然后考虑“重要少数”的错误指标，提出改进意见。
根据软件过程中的每个步骤计算错误指标
Ei = 第i发现的错误总数
Si = 严重错误数
Mi = 一般错误数
Ti = 微小错误数
PS = 第i步的产品规模(LOC，设计陈述，文档页数)
Ws，Wm，Wt分别是严重，一般，微小错误的加权因子，推荐取值，Ws=10，Wm=3，Wt=1
软件工程在过程的每一步中，计算各阶段的阶段指标
PIi = Ws（Si / Ei）+Wm（Mi / Ei）+Wt（Ti / Ei）
错误指标
Ei= ∑（i×PIi）/ PS
=（PI1 + 2PI2 + 3PI3 + … + i*PIi）/ PS
错误指标与上面表格中收集的信息相结合可以得出软件质量整体改进指标。七、质量保证与检验
确保每个开发过程的质量，防止把软件差错传播到下一个过程，因此，检验的目的有两个：
⒈切实搞好开发阶段的管理，检查各开发阶段的质量保证。
2．预先防止软件差错给用户造成损失。
检验的类型有：
⒈供货检验：对委托外单位承担开发作业，而后买进或转让的构成软件产品的部件，规格说明，半成品或产品的检查。
⒉中间检验 / 阶段评审
目的是为了判断是否可进入下阶段进行后续开发，避免将差错传播到后续工作中。
⒊验收检验：
确认产品是否已达到可以进行产品检验的质量要求。
⒋产品检验：
判定向用户提供的软件产品是否达到令人满意的程度。

参考资料： http://baike.baidu.com/link?url=pFXYgplXP8Zd1kpbkZPZUcC8yxHYz1nQjOTy7veBcazGr1LU85_g6JWOx2MyyInNyekyVtkSeK9MJKnpWVYuha

扩展阅读：