一、简介
软件质量保证（SQA-Software Quality Assurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。
二、目标
目标 1: 软件质量保证工作是有计划进行的。
目标 2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。
目标 3: 将软件质量保证工作及结果通知给相关组别和个人。
目标 4: 高级管理层接触到在项目内部不能解决的不符合类问题。
目标 5: 软件质量需要全面的测试工作来保证。
三、执行约定
1）将软件质量保证SQA功能落实到所有软件项目开发的各个阶段。
2）SQA组有一个直接向上级管理部门汇报的渠道，这个渠道独立于：
项目负责人；
项目软件负责人；
项目软件工程组；
软件配置管理组；
文档支持组。
3）建立一种组织结构，它将支持在组织的战略经营目标和经营环境中需要独立性的活动（例如：SQA），这种独立性体现在：
帮助做SQA工作的个人提供组织上的自由度，便于他们向上级管理部门报告情况；
使得做SQA工作的个人，不受外来的影响和干扰；
确保提供给上级管理部门的有关软件项目过程和产品信息的报告是客观的。
4）上级管理部门要定期地评审SQA活动和结果。
四、执行能力
1）必须有一个负责调整和实施项目的SQA组。
建立组时应考虑的因素包括项目的规模、工作内容、范围、活动，以及与其他组织机构的关系。
2）为执行SQA活动提供足够的资源和资金。
指派一名有丰富的SQA知识和有采取适当监控措施权力的高级管理者负责受理软件质量问题；
有支持SQA活动的工具。例如：工作站；数据库管理程序；电子表格程序；审核工具等。
3）培训SQA组的成员，使他们能执行SQA活动。
培训内容包括：
软件工程的一般知识和实践；
软件工程组和其他软件相关组的岗位职责及任务；
用于软件项目的标准，规程和方法；
软件项目的应用领域知识；
SQA的对象、规程和方法；
SQA方法和工具的有效使用；
SQA组参与软件活动的内容和形式；
人与人之间的交流。
4）对参加软件项目的其他成员进行有SQA组的任务、责任、权力和价值等方面的定向培训。
五、执行活动
深蓝色代表开发单位，黄色代表质量保证单位，下面的蓝绿色代表软件使用单位。
从图中可以看出，软件质量保证活动贯穿在整个软件过程的每个环节。即从需求分析阶段直到部署阶段，都需要进行质量保证活动。
在这个KPA中，“审计”和“评审”是活动的核心。
活动1 根据文档化的规程制定软件项目的SQA计划
1）SQA计划在总的项目计划的初期制定，并与总的项目计划并行发展。
2）对SQA计划进行评审，参加人员包括受影响的组和人员。
受影响的组及人员包括：
项目软件负责人；
其他软件负责人；
项目负责人；
用户的SQA代表；
组织中分管SQA活动的高级管理者；
软件工程组SEPG。
在这里首先对比一下QA\QC 及QA\SEPG在这个KPA中的区别与联系
/*对比QC 和QA:
QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；
QA：审计过程的质量，保证过程被正确执行；是过程质量审计者；
注意区别检查和审计的不同
检查：就是我们常说的找茬，是挑毛病的；
审计：来确认项目按照要求进行的证据；仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的；对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。
QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。
在这样的分工原则下， QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。
*/
/*对比SEPG 和QA:
SEPG：制定过程，实施过程改进；
QA：确保过程被正确执行
SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划；从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。
*/
3）SQA计划应受管理和控制。
·受管理和控制意味着在给定时间使用的工作产品的版本均是可查知并受控的，而且以受控的方式进行更动；
·如果需要更高程度的控制，那么可将产品置于软件配置管理的严格控制之下。
个人理解：这个活动的意思是首先要有一个文档化的规程，SQA计划的制定是按照这个文档化规程来进行的。SQA计划在项目的初期就要制定，但不是一次制定好就结束了，而是要根据项目的进展来不断完善、改进，这个过程也是严格受到管理和控制的，这意味着SQA计划不可随意更改且SQA计划中的内容不是胡乱填写而是可查知的，制定包括更改SQA计划也需要相关人员的评审，评审的过程是发现SQA计划中写的不正确或不清晰或遗漏的方面，从而使SQA计划更加清晰完整。
活动2 SQA组按照SQA计划进行活动
SQA计划包括以下内容。
1）SQA组的责任和权力；
2）SQA组需要的资源（包括人员、工具和设施）；
3）项目组活动的日程和经费；
4）SQA组在制定项目软件开发计划、标准和工作规程时的参与行为；
5）SQA组对软件产品和活动的评价活动；
被评价的产品和活动包括：
运行软件和支持软件；
可交付的和不交付的产品；
程序和文档；
产品开发和产品验证活动；
生成产品时所从事的活动。
6）由SQA组进行的审计和评审活动；
/* 评审和审计的区别
评审： 为确定主题事项达到规定目标的适宜性、充分性和有效性所进行的活动。
评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。评审的主要目的是发现产品中的问题，而不是根据产品来评价开发人员的水平。
质量审计是识别改进领域的工具之一。是一种独立的审查,确保项目执行过程符合组织或项目定义的方针政策,标准和程序。从而了解项目和产品基本情况,确定改进目标,制定审计计划。
质量审计是一种独立的结构化审查，用来确定项目活动是否遵循了组织和项目的政策、过程与程序。进行审计的目的是为了确定对已发布标准的遵守程度和提供任何需要的纠正措施。
*/
7）被用作SQA组审查和审核基础的项目的标准和规程；
8）文档化和全程跟踪不一致问题的工作规程。这些工作规程可能作为计划的一部分包含在其中，也可能通过引用包含在其他文档中。
9）SQA组产生的文档。
10）向软件工程组和其他软件相关组提供SQA活动反馈的方法和频度。
个人理解：SQA组人员的活动不是凭个人对软件质量保证的理解来进行，而是要按照SQA计划来进行的。SQA计划的制定是活动1的内容，而这个活动也说明了SQA计划这个文档中需要写什么内容，包括SQA组的责任和权力；SQA组需要的资源（包括人员、工具和设施）；项目组活动的日程和经费；SQA组在制定项目软件开发计划、标准和工作规程时的参与行为；SQA组对软件产品和活动的评价活动；由SQA组进行的审计和评审活动；被用作SQA组审查和审核基础的项目的标准和规程；文档化和全程跟踪不一致问题的工作规程等。
活动3 SQA组参与项目软件开发计划、标准和规程的制定和评审
1）SQA组在以下几个方面对制定计划、标准和规程提供咨询和评审；
与组织制定的政策的一致性；
与外部强加的标准和需求的一致性；
其他适用于项目使用的标准；
在软件开发计划中应该阐述的主题及项目指定的其他方面的问题。
2）SQA组检验计划、标准和规程的合理性及其是否能被用于审查和审核软件项目。
个人理解：SQA组需要制定并评审软件开发在与组织制定的政策一致性、外部强加标准和需求一致性及应该阐述的主题的计划、标准和规程。在这些方面的计划、标准、规程被制定后，还需要对其做进一步的检验，以确定其是否真正可以用来审查和审核软件项目。
活动4 SQA组评审软件工程活动，以验证其一致性
·根据软件开发计划和指定的软件标准和规程进行评价活动；
·对偏差（与计划、标准、规程的不符合性）进行标识并建立文档；
·对纠正结果进行检查验证。
个人理解：评审是SQA这个KPA的一个关键的行为。要想做到软件质量保证，怎么“保证”软件产品和过程的质量就要通过“评审”和“审计”，评审的过程就是上述三个步骤，由SQA组人员来执行。
活动5 SQA组审计指定的软件工作产品，以验证其一致性
·交付给客户之前，评价可交付的软件产品；
·对照指定的软件标准、规程和合同要求，评价软件工作产品；
·对偏差进行标识并建立文档；
·对纠正结果进行检查验证。
个人理解：审计是SQA这个KPA的一个关键的行为。要想做到软件质量保证，怎么“保证”软件产品和过程的质量就要通过“评审”和“审计”，审计的过程就是上述四个步骤，由SQA组人员来执行。
活动6 SQA组定期向软件工程组SEPG报告其活动结果
个人理解：SQA组所做的工作需要定期向SEPG报告，因为SEPG是一个管理整个软件过程的小组，通过SQA的报告SEPG组的成员就会知晓SQA组目前的进度状况，如果发现了SQA在过程中出现的问题，他们要对其软件过程进行维护、改进及指导，这也体现了SEPG对软件过程的监督工作。定期即每隔一小段时间就报告一次，这样做是保证了每做一部分工作就确定一下这部分内容是否正确，是否存在偏差，以便及时修改和完善。
活动7 根据文档化规程，对在软件活动和软件工作产品中找出的偏差建立文档
·将不符合软件开发计划、标准及规程的偏差形成文档，并与有关人员一起进行解决；
·将底层负责人不能解决的偏差形成文档，并将其提交给分管软件质量保证的高级管理者进行处理；（对应了目标4）
·定期审查提交给高级管理者的不一致问题，直到被解决为止；
·管理和控制不一致问题的文档化过程。
个人理解：在项目开发的过程中，偏差是难以避免的。因此，实际开发过程中的活动和产品对比文档化规程的偏差要记录在一个文档中。在活动4和活动5所找到的不一致问题也要记录在文档中。这个偏差的文档也是需要管理和控制的，即不可随意更改，这类似于对SQA文档的要求。这个文档需要底层负责人及时解决，定期把解决的结果交给高级管理者审查这些问题和偏差是否真正解决。
活动8 SQA组将它的SQA活动和发现的偏差，定期地与用户SQA人员进行交流或评审
个人理解：这个活动强调的是在项目执行的过程中，实际的进展可能和SQA计划存在一定的偏差，那么就需要两方人员即SQA组和用户SQA人员定期的交流、评审。定期即每过一小段时间就交流一次，这样做是保证了每做一部分工作就确定一下这部分内容是否正确，是否存在偏差，以便及时修改和完善。
执行活动与目标的对应关系：
目标1：活动1、活动2 分别说明了质量保证活动如何纳入计划及计划内容。
目标2：活动3、活动4、活动5分别说明了如何验证软件产品、软件活动与所采用的标准、规程和需求间的一致性，活动7说明在上述活动找到的偏差要建立文档。
目标3：活动6和活动8保证了受影响的组和个人了解软件质量保证活动和结果目标4：活动7的子活动中提到“项目中无法解决的与意见分歧的事宜，通知高级管理部门解决”。
六、测量和分析
1.制定测量并用来决定SQA活动的成本和进度状态
·以用户需求和开发任务为依据，对质量需求准则，质量设计准则的
质量特性设定质量目标进行评价
·设定适合于待开发软件的评测检查项目
·在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。
2. SQA 活动里程碑的完成情况与计划比较
3. 完成的工作、所用的工作量以及消耗资金与计划比较
4. 产品审计和活动评审的次数与计划比较
七、验证实施
在软件质量保证的实施过程中，应对软件质量保证过程进行定期的检验。软件质量保证的验证实施从以下几方面进行：
1）定期与上级管理部门一起评审SQA活动。
上级管理部门参与评审的主要目的是保证在适当的层次上及时了解和考察软件过程。
评审间隔应满足整个软件开发组织的要求，只要有报告异常情况，每次审查之间的间隔可适当延长。
2）项目负责人定期地和需要审查时审查SQA活动。
3）邀请独立于SQA组的专家定期审查项目SQA组的活动和软件工作产品。