一、软件质量管理起源

1946年，在日本兴起了以Edwards Deming的统计过程控制（SPC）研究为基础的质量改进运动——在工业生产的环境下，通过对生产过程中的各个环节的分解和规定，来改善产品质量。因为每一环节都会产生一个具有规格要求的部件。那么检验这些部件是否合乎规格要求，便可以提高产品的质量。

QC作为质量控制小分队，负责在各个环节检测组件是否在容忍范围之内。比如生产直径5mm长度8mm的螺丝，且误差不大于0.2mm。QC的工作就是测量螺丝的直径是否在(4.8mm - 5.2mm)，长度是否在（7.8mm - 8.2mm）之间。

而QA作为质量保证小分队，不参与制造和检测，但却会审核制造和检测的过程是否遵循了既定的标准和指南，继而为持续改进制造与检测的工作过程提供输入信息。比如螺丝制造按照标准共计10道工序、检测共计3道工序。QA的工作就是检查制造人员是否按要求执行了10道制造工序，QC人员是否按要求执行了3道检测工序。

QA和QC的对质量改进做出的贡献，通过产品本身得到了市场与成本双方面的正向反馈。于是经验证有效的QA与QC质量改进方式便在全球范围内传播开来。既然在工业生产领域QA和QC有如此之作用，人们便开始尝试将这两个已经得到证实的方法运用到软件生产领域。于是SQA和SQC便应运而生，留给人们的课题便是如何将之从有形世界的应用转化到无形世界中，即定义和实现SQA和SQC。

二、定义软件质量

有形世界和无形世界的差异使得软件领域在实践QA和QC时遇到了很多麻烦，比较突出的有以下几点差异：

·   生产制造的产品是对客户需求的物理实现，其功能可以通过物理方式验证。

·   制造的成本，包括返工、维修、召回等，易于分类和表征。

·   产品给客户和用户带来的收益易于分类和表征。

为了突破这些限制并确定软件的成本和收益，人们将软件定义为一系列特性，并开始形成术语、模型和范例，比如McCall、Boehm和FURPS+等。以惠普公司的Robert Grady开发的FURPS+模型为例。其定义的软件特性为以下五点：

功能 Functionality

表示我们期望看到的、所描述的所有系统范围内的功能需求。这些功能需求诠释了产品的主要特性，并回答了“产品将为我们做什么”的问题，而非“它是如何做的”问题。

适用性 Usability

包括查看、捕获和陈述基于用户界面问题的需求。例如可访问性、界面美学和用户界面内的一致性等问题。

可靠性 Reliability

包括可用性（availability）、准确性和可恢复性等方面。例如系统在关闭故障时的可恢复性。

性能 Performance

涉及信息吞吐量、系统响应时长（也与适用性有关）、恢复时长和启动时长等。

可支持性 Supportability

对应软件支持的一般需求。例如可测试性、自适应性、可维护性、兼容性、可配置性、可安装性、可伸缩性、可本地化性等。

+

表示约束的规格。例如设计约束、实现约束、接口约束和物理约束。

SQC根据这样的软件特性体系，便可以测试和测量软件了。而SQA则负责确保每个人在工作过程中都遵循正确的程序和标准。需要特别强调的是，无论SQA还是SQC都不负责将这些特性“放到”软件产品中去。这一步是软件设计和编码人员的工作。

以FURPS+中的“可支持性”特性为例。可支持性可以通过修复缺陷所需的时长来衡量。为了改进这一点，可以实施新的编码规范。在这种情况下，SQC部门将检查代码，以确保新的编码规范得到应用；而SQA部门将确保SQC和开发小组遵循了正确的工作过程和工作标准。SQA部门还将收集和分析修复缺陷的时长数据，以应用于持续过程改进行动中。

如此，人们便可以把工业生产中的QC与QA，以类似的思路和方式应用到软件生产中了。

三、应用软件质量管理

· 需求开发

SQC：

验证需求开发的成果物。其工作方式是通过Inspection的方式检查需求的明确性和完整性。

SQA：

1)   观察和审核明文规定的工作标准、工作过程和程序在需求开发的相关工作中是否得到了遵循。

2)   建立针对需求开发这一工作过程是否有效的度量。衡量需求开发过程是否有效的一个常见指标是在系统测试阶段发现的需求不正确或不清晰的数量（说明：在这一过程中，SQC执行的是实际的系统测试，而SQA则将收集的数据用于监控和持续改进）。

SQA可以通过抽样的方式检查，而SQC则需要参与所有需求的验证。

CMMI需求开发过程域描述了三种类型的需求：用户需求、产品需求、产品组件需求。SQC和SQA对待上述三种类型的需求的方式都是相同的。

· 需求管理

CMMI需求管理过程域的目的是管理产品和产品组件的需求，并识别这些需求与项目计划和工作产品之间的不一致。该过程涉及需求的版本控制以及需求与其他工作产品之间的关联性管理。需求管理使用到的工具之一是需求跟踪矩阵。它是一个交叉引用的表格，记录了从需求到代码到测试用例的一系列关联关系。

SQC：

与其在需求开发中的一样。SQC负责检查需求跟踪矩阵及其他这一工作过程的交付物，并验证所有需求都已关联到了程序或代码。

SQA：

1)   观察和审核明文规定的工作标准、过程和程序在需求管理相关工作中是否得到遵循。

2)   制定度量标准，以衡量需求管理工作过程的有效性。

衡量需求管理工作过程有效性的常见指标有：

1)   引用错误版本的次数

2)   因需求跟踪矩阵不完整导致上市产品中发现缺陷

· 技术解决方案

CMMI技术解决方案的目的是设计、开发和实施针对需求的解决方案，主要指设计和编码过程。

SQC：

在这一过程中的主要工作是测试（参见确认和验证），设计评审和代码评审也是SQC要参与的。评审的目的是验证是否遵循了标准（例如设计规范和代码规范），或寻找潜在的可支持性方面的问题。

SQA：

1)   观察和审核明文规定的工作标准、过程和程序在设计和编码相关工作中是否得到遵循。

2)   制定度量标准，以衡量该过程的有效性。

缺陷数量是这一阶段的一个常用度量项。这个度量项通常会被进一步量化为一定范围内的缺陷数，如每100行代码的缺陷数或每一个函数的缺陷数。值得一提的是，缺陷是SQC在执行测试的过程中发现的；而SQA统计缺陷数量和分布来衡量设计和编码过程的有效性。

· 产品集成

产品集成的目的是从产品组件组装产品，确保集成后的产品功能正常，并交付产品。

请注意，CMMI中的产品集成指的是最终集成、“转生产”或产品交付（不涉及任何编码）。对于大型软件来说（如SAP、Oracle Financials等），其组装过程非常庞大。因此，出错的可能性也很高。

SQC：

系统的集成测试（SIT）由SQC进行。在此过程中还将进行安装能力测试。

SQA：

1)   观察和审核明文规定的工作标准、过程和程序在集成相关工作中是否得到遵循。

2)   制定度量标准，以衡量该过程的有效性。

其度量项可以是由产品需求中的接口规范所导致的缺陷。对应的潜在改进措施是找到其他不那么模棱两可的方法来明确接口。

· 验证与确认

术语“验证”和“确认”看似相同，但却有其不同的着眼点。对此CMMI做出了一个简单的解释：

验证是检查工作产品是否正确地反映了规格要求；而确认是检查当工作产品放置在预期环境中时，是否能满足其预期的用途。

软件工程中的所有验证活动都是且仅由SQC执行。但验证工作本身是否遵循了标准、过程和程序是SQA的检查项。

与验证一样，确认主要也是SQC的范畴。“验收测试”就是一种确认活动。大多数情况下，验收测试是由隶属于SQC的不同团队执行的。如果开发的软件是内部使用的，那么最终用户或业务代表将执行验收测试。无论是谁，验收测试本质上都是一项SQC活动。

与验证一样，在确认活动中，SQA要做的是确保这些过程符合标准、过程和程序。确认过程本身也需要借助SQA的审计不断地被度量和改进。

以上是站在软件开发生命周期的宏观角度上阐述的SQC与SQA。尽管没有很具体，但是我们已经可以清晰地看到：

在所有情况下，SQA和SQC都不参与任何产品的构建（设计和编码）。SQC仅参与验证和确认。而SQA完全不参与软件工程的任何环节，他们主要提供审计人员，收集工作过程有效性的度量数据，以便实施持续的工作过程改进。