第六章 项目的质量管理

6.1 软件质量的度量6.2 软件的确认6.3 软件的验证

6.4 软件质量保证过程6.5 软件质量保证体系

第六章 • 目录

6.1 软件质量的度量6.2 软件的确认6.3 软件的验证

6.4 软件质量保证过程6.5 软件质量保证体系6.6 测试方法与工具介绍

第六章 • 目录

软件系统功能齐全是不是就是质量好？ 用户界面友好是不是就是软件的质量好？ 没有 BUG 是不是就是软件的质量好？ 什么是用户满意的软件项目？ 软件测试是不是软件质量的全部？ 那么，什么是软件的质量？

什么是软件项目的质量？

软件项目管理中的质量管理与软件工程的测试管理，有什么不同？ 项目经理与项目 QA 经理有什么不同？ 什么是软件项目的质量管理？ 项目经理在保证项目的质量方面，要做什么工作？ 我们就来回答这些问题！

什么是软件项目的质量管理？

6.16.1 软件质量的度量软件质量的度量6.1.1 6.1.1 软件的质量要素软件的质量要素6.1.2 6.1.2 软件质量评价的准则软件质量评价的准则6.1.3 6.1.3 软件质量的度量软件质量的度量6.1.4 6.1.4 软件质量度量的实施软件质量度量的实施

6.1.1 软件的质量要素什么是软件的质量？什么是软件的质量？• ISO9000ISO9000 的质量定义：的质量定义：•质量的定义：反映实体满足明确和隐含需质量的定义：反映实体满足明确和隐含需要能力的特性综合要能力的特性综合•定义的说明：定义的说明：

– 明确需要：指合同中用户明确提出的要求与需要明确需要：指合同中用户明确提出的要求与需要– 隐含需要：指由生产企业通过市场调研进行识别与隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要探明的要求或需要

质量与等级的关系 等级的含义是：对功能用途相同、但技术特性不同的实体的一种分类或排序 例如：高质量——无错误、可读性强的用户手册 低等级——有限的功能 低质量——错误百出、编排混乱的用户手册 高等级——大量功能 PMBOK 强调质量的核心是产品、服务的适用性 什么是适用性？

质量的要素 讨论软件的质量定义，一般地从 4 个角度来看，即用户的角度、开发商的角度、产品的角度和价值的角度。 美国的 B.W. Ｂ oehm 和 R.Brown 先后提出了三层次的评价度量模型：软件质量要素、准则、度量。 随后 G.Mruine 提出了自己的软件质量度量 SQM 技术，波音公司在软件开发过程中采用了 SQM 技术，日本的

NEC 公司也提出了自己的 SQM 工具，即 SQMAT ，并且在成本控制和进度安排方面取得了良好的效果。 IEEE 标准 1061-1998 以表格的形式，定义了有关确认和收集与软件质量需求有关一个模型，或称为一个框架。

6.1.2 IEEE定义的软件质量度量框架软件产品质量

特性

直接度量

特性

直接度量

特性

直接度量

子特性

度量

子特性子特性

度量 度量

度量框架 一种用来组织、选择、沟通、评价软件系统要求的质量属性的辅助决策法。它逐层分解为特性、子特性和度量质量特性 一个与质量有关的面向管理的软件属性质量子特性 质量特性分解出来的技术组件直接度量 一种不依赖与任何其他属性测量的度量预计度量 一种试用于开发阶段的度量，它用来预计软件质量特性的值软 件 质 量 度量 一个函数、它的输入是软件数据，输出是一个单一数值。它可解释为给定的软件属性对其质量的影响程度过程质量 一种用来测量在软件系统开发、实现和维护过程中使用的方法、技术和工具特性的度量产品度量 一种用来测量软件开发过程中任何中间或最终产品特性的度量 

IEEE定义的软件质量度量框架

质量需求 在四层模型的第一层，软件产品质量层，是产品必须满足的质量需求。它是用用户术语描述的，主要有四点：（ 1）产品将在用户所在组织当前使用的平台和操作系统上运行。（2） 产品将是可靠的并能防止数据丢失的机制。（3） 产品将提供完成某些任务所必需的功能。（4） 产品将易于使用。 质量特性在模型的第二层，表示与整个质量需求有关的特殊质量特性，它代表了用户的质量需求。它采用从用户角度考虑的立场，把软件质量分解成四类质量特性，这四个质量特性是软件的基本特征。IEEE 的四个质量特性是：可移植性、可靠性、功能性、可使用性。

四层模型质量需求 质量特性 质量子特性 直接度量 度量描述（例子）

产 品将在多平台和当前用 户正在使用 的操作 系统上运行

可 移 植性 硬件独立性 硬件依赖性 计算硬件的依赖性软件独立性 软件依赖性 计算软件的依赖性易安装性 安装时间 测量安装时间可重用性 能够用于其他应用软件中

计算能够或已经应用于其他软件系统的模块数量产 品将是 可靠的 并 能 提供防止数据丢失的机制

可靠性 无缺陷性 测试覆盖 测量测试覆盖度审查覆盖 计算已做过的代码审查模块

容错性 数据完整性 统计用户数据被破坏情况数据恢复 测量恢复被破坏的数据的能力

可用性 软件可用的百分比 软件可用时间除以总的软件使用时间

产品将提供完成某些任务所必需的功能功能性 完备性 测试覆盖 计算调用或分支测量覆盖

正确性 缺陷密度 计算每一版本发布前的缺陷安全性

数据安全性 统计用户数据被破坏的情况用户安全性 没有被阻止的非法用户入侵数

兼容性 环境变化 软件安装后必须修改的环境变量数量互操作性 混 合应用环境下软 件 的可操作性混合应用环境下可正确运行的数量

产品将易于使用 可使用性 易理解性 学习所用时间 新用户学习软件特性所花费的时间易学性 学习所用时间 新用户学会操作软件提供的基本功能所花费的时间易操作性 人的因素 新用户基于人类工程学对软件消极方面的评价数量沟通性 人的因素 新用户基于人类工程学对软件消极方面的评价数量

质量需求 质量特性 质量子特性 直接度量 度量描述（例子）

6.1.3 软件质量评价准则McCall选择的软件质量要素评价准则共21 种，它们是：（ 1）可审查性 (auditability)。检查软件需求、规格说明、标准、过程、指令、代码与合同是否一致的难易程度。（ 2 ）准确性 (accuracy)。计算和控制的精度，是对无误差程序的一种定量估计。最好表示成相对误差的函数。值越大表示精度越高。（ 3 ）通信通用性 (communication commonality)。使用标准接口、协议、规范的程序。（ 4）完全性 (completeness)。所需功能完全实现的程度。 （ 5）简明性 (conciseness)。程序源代码的紧凑与简洁性。（ 6）一致性 (consistency)。设计文档与系统实现的一致性。（ 7）数据通用性 (data 　 commonality)。在程序中使用标准的数据结构和类型。（ 8）容错性 (error-tolerance)。系统在各种异常条件下提供继续操作的能力。（ 9）执行效率 (execution Efficiency)。程序运行效率。（ 10）可扩充性 (expandability)。能够对结构设计、数据设计和过程设计进行扩充的程度。

6.1.3 软件质量评价准则（ 11）通用性 (generality)。程序部件潜在的应用范围的广泛性，即部件可重用。（ 12 ）硬件独立性 (hardware independence)。软件同支持他运行的硬件系统不相关的程度。（ 13 ）检测性 (instrumentation)。监视程序的运行，一旦发生错误时，能明确地标识错误的程度。（ 14）模块化 (modularity)。程序部件的功能独立性。（ 15）可操作性 (operability)。操作一个软件的难易程度。（ 16）安全性 (security)。控制或保护程序和数据不受破坏的机制，以防止程序和数据受到意外的或蓄意的存取、使用、修改、毁坏或泄密。（ 17）自文档化 (sdlf-documentation)。源代码提供有意义文档的程度。（ 18）简单性 (simplicity)。理解程序的难易程度。（ 19）软件系统独立性 (software system independence)。程序与非标准的程序设计语言特征、操作系统特征以及其他环境约束无关的程度。（ 20）可追踪性 (reacebility)。从设计表示或实际程序构件，追踪到需求的能力。（ 21）易培训性 (training)。软件支持新用户使用该系统的能力。

1985年，国际标准化组织（ ISO ）建议，软件质量度量模型由三层组成。高层称软件质量需求评价准则（ SQRC ），中层称软件质量设计评价准则（ SQDC ），低层称软件质量度量评价准则（ SQMC ）。分别对应McCall等人的要素、评价准则和度量。 ISO 认为应对高层和中层建立国际标准，以便在国际范围内推广应用软件质量管理，而低层可由各使用单位自行制定。 ISO 高层由 8 个要素组成、中层由23个评价准则组成。高层的 8 个要素为左表的行，中层的 23个准则为下表的列。它们之间的关系如左表所示。

软件质量的另一种理解软件质量的另一种理解• ISO/IEC9126-1ISO/IEC9126-1 《产品质量《产品质量 -- 质量模型》的软件质量模质量模型》的软件质量模型型

内部质量 外部质量 使用质量

度量 度量 度量

软件产品质量的三重度量

• 内部质量的定义是：内部质量的定义是：• 反映软件产品在规定条件下使用时，反映软件产品在规定条件下使用时，满足需求的能满足需求的能力的特性力的特性，是软件开发过程中各阶段（需求开发、，是软件开发过程中各阶段（需求开发、软件设计、代码编写等）产生的中间软件产品的质软件设计、代码编写等）产生的中间软件产品的质量。量。• 了解软件产品的内部质量，可以预计最终产品的质了解软件产品的内部质量，可以预计最终产品的质量。量。

• 外部质量的定义是：外部质量的定义是：• 反映软件产品在规定条件下使用时，反映软件产品在规定条件下使用时，满足需求的程满足需求的程度。度。•外部特性反映在预定的系统环境中运行时可达到的外部特性反映在预定的系统环境中运行时可达到的质量水平。质量水平。

• 使用质量的定义是：使用质量的定义是：• 反映软件产品在规定的使用环境下，使特定用户在反映软件产品在规定的使用环境下，使特定用户在达到规定目标方面的能力。达到规定目标方面的能力。• 反映的是从用户角度看到的软件产品在特定系统环反映的是从用户角度看到的软件产品在特定系统环境下满足其需求的满足程度。境下满足其需求的满足程度。

• 对内部和外部质量特性的度量描述包括：对内部和外部质量特性的度量描述包括：• 功能性、可靠性、易用性、效率、可维护性、可移功能性、可靠性、易用性、效率、可维护性、可移植性等；植性等；

• 对使用质量特性的度量描述包括：对使用质量特性的度量描述包括：• 有效性、生产率、安全性、满意程度等有效性、生产率、安全性、满意程度等

6.1.4 软件质量度量的实施 在确定要对一个软件（系统）进行度量之后，一般，采取以下在确定要对一个软件（系统）进行度量之后，一般，采取以下 55 个步个步骤，来实施对该软件的度量：骤，来实施对该软件的度量：（（ 11 ）确定软件质量需求；）确定软件质量需求； 在用户需求中，除功能需求外，还有非功能需求，包括：质量需求、环境需求、设计约束、开发策略等。质量需求是用户比较关心的内容。 但是，我们已经知道，软件的功能需求的确定，存在一定的难度。而非功能需求的确定，则难度更大。这些困难包括：需求如何获取，需求冲突如何协调、需求的确认和变更的授权等。过程： 需求获取：首先，你要理解用户的需求，区分哪些是质量需求，把这些需求记录下来，获得用户的确认。 需求分析：拿到用户确认的需求后，你可以开始把用户的质量需求与我们设定的质量特性联系起来，一直区分到子特性。这种联系，就是把用户语言描述的需求，转变为计算机工程师语言的需求。建立了这种关联后，可以根据分类，分级，确定直接度量。

6.1.4 软件质量度量的实施（2）确定直接度量直接度量就是实际的软件质量测量活动，它的输入是软件或软件过程，输出是一个测量值。它通过执行一系列的任务，获得一个质量值。例如：对一个没有经过培训的用户，让他使用软件系统的某一功能，在界面提示、联机帮助、使用手册的帮助下，他学会掌握该功能所花的时间。而用户需求对此项指标的要求（目标）和现实系统所达到的实际值（比如： 10 个人次测量后统计意义上的）的比较，就是将提交质量评审的质量值。在进行直接度量前，一般应该有以下准备： （ 1）工具：有助于计算度量值的硬件 /软件工具，如：缺陷跟踪工具；（2）应用：描述度量结果的希望值、度量值的意义、作用和对度量结果数据的使用方法；（3）数据：获得度量结果所需的数据、程序、过程等度量对象；（4）计算：度量程序、步骤和方法。（ 5）费用：测试是要花钱（人力、物力、时间等）的。

6.1.4 软件质量度量的实施（ 3）分析度量结果对度量过程进行跟踪和分析，需要时，可能会对度量程序、度量工具、度量方法，甚至原始数据，做出补充和调整。 （ 4）确认质量度量在度量过程中，进行度量结果的确认非常重要。首先，要确认度量过程是否与事实相符，脱离现实真实的度量，与目标再相符的结果也是没有意义的。其次，是确认方法的有效性，例如：在度量中，我们用到很多统计学方法，在这些方法中，我们有一些概率分布假设（例如：某些错误的发生，我们假设符合随机概率分布），当这些假设并不成立时，度量的结果是不真实的。

其他度量• 分析模型的度量（对分析模型的度量以测试系统的大小）分析模型的度量（对分析模型的度量以测试系统的大小）• 设计模型的度量（度量体系结构、数据和系统的复杂度）设计模型的度量（度量体系结构、数据和系统的复杂度）• 源代码的度量（度量程序的长度、层次、开发量、时间源代码的度量（度量程序的长度、层次、开发量、时间等）等）• 对测试的度量（度量测试的宽度、深度、错误的级别）对测试的度量（度量测试的宽度、深度、错误的级别）• 对维护的度量（度量软件的稳定性）对维护的度量（度量软件的稳定性）

什么是系统集成项目的质量要素？如何度量和评价？如何管理与控制？

6.1 软件质量的度量6.2 软件的确认6.3 软件的验证

6.4 软件质量保证过程6.5 软件质量保证体系6.6 测试方法与工具介绍

第六章 • 目录

6.2 6.2 软件确认软件确认6.2.1 6.2.1 测试阶段测试阶段6.2.2 6.2.2 测试方法测试方法6.2.3 6.2.3 测试类型测试类型6.2.4 6.2.4 测试计划测试计划

软件确认与验证的概念 软件的确认（ Validation ）与验证（ Verification ）简称为 V＆ V 或 V2，是软件产品质量度量的具体方法。 确认是这样一个过程，它评价“在软件开发过程期间（针对单元）或结束（针对系统）时，单元或系统是否满足用户特定的需求”。换句话说，是开发结束期间确认，我们的产品符合用户要求吗？ 因此，确认的产品质量。确认活动围绕三个基本过程来开展，测试、度量和软件可靠性增长 而验证是这样一个过程，它评价“在一个给定的开发阶段中，单元或系统是否满足在此阶段开始时确定的条件”。因此，它的意思是，我们正在制作的产品符合用户要求吗？ 因此，验证的是产品开发过程质量——工作质量。验证活动也是围绕三个基本过程来进行，审查、度量和配置管理。

6.2.1 测试阶段 根据不同的软件生命周期定义，测试的阶段、方法和类型构成一个层次结构，如下图：

测试结构

测试类型功能、算法、正向反向、可用性、边界

测试方法白盒、黑盒、自顶向下、自底向上、模拟用户操作

测试阶段验收测试、确认测试集成测试、单元测试

V模型中的过程从左到右，描述了基本 的 开 发 过 程 和 测试 行为 。 V 模型 的价 值 在于它非常明确 地 标 明 了 测 试 过程 中存在 的 不 同 级别 ， 并 且清楚地描述了 这 些 测 试阶段和 开 发 过 程期间各阶段的对应关系。

测试的 V 模式

单元测试 单元测试的内容主要是： 算法逻辑、数据定义的理解和使用、接口、各种CASE路径、边界条件、错误处理等。 单元测试的目的通常是 : 在开发环境中，程序设计工程师为了检查单元程序模块内部的逻辑、算法和数据处理结果的正确性等。单元测试通常由负责编码的工程师自己在代码完成后测试，也有在项目组内，由工程师相互交叉测试。 调试与测试的最大的不同点是二者的目的和视角的区别： 调试包括查找BUG、定位BUG、修改并最终确认BUG已经被修复的软件故障排除过程。 测试是在一个相对独立的环境下（测试应尽可能地模拟运行环境，调试是在开发环境），运行系统单元，观察和记录运行结果，对结果进行独立评价的过程。

单元测试（模块测试） 实际上，在单元测试级，一般项目组很难做到把调试与测试分开。因为二者的工作内容比较接近，担负人常常是一个人，环境区别并不大或者重新搭建环境在时间、成本和人力上，都比较困难。这些都是一般项目组并没有独立的单元测试的原因。 将单元测试与模块调试合并可能带来的问题是：（1）单元测试没有任何记录和文档。少有笔头勤快的工程师，会把他每天测了什么、改了什么，记录下来。软件工程师要的就是没有BUG的程序，任何中间结果都是垃圾。（2）由于调试的目标是获得没有故障的程序，因此，与功能无关的程序属性往往被忽略，或者要到集成测试、确认测试时才被发现。例如：命名标准、程序形式规范等。 不论怎么说，现实情况，单元测试与模块调试经常是混为一谈的，要想改变，也不太容易。 由于单元测试在项目组中，常常由编码工程师完成，项目经理的管理一般并不深入到单元测试层。

集成测试（子系统测试） 集成测试又称组装测试，它是在单元测试完成后，组装为一个子系统后，对下列只有组装后才能发生和测试到的问题，进行检查：（1）组装后一个模块对一个模块的影响；（2）合并功能是否是预期的；（3）独立的误差在合并后的变化，是扩大还是减小，是否在可接受的范围内；（4）实际的接口测试；包括：模块之间对实际衔接的标准、时序（实时性）、应答响应、容错与错误处理等；（5）模块间的资源竞争等。 集成测试也很重视集成的阶段性。最坏的情况是系统只有一次集成，就是系统全部模块完成后进行集成。实际上，这就像一部汽车，直到要出厂时，才来一次总测试。而当你每天生产一部完全不同规格、型号的汽车时，这个时候的测试，可能是非常要命的。 比较好的办法是通常采用的增量组装法，包括自顶向下或自低向上的增量组装。分阶段的增量组装测试，可以解决一次集成，问题的隔离和区分不易的困难。

确认测试（系统测试） 确认测试的目的是按照与用户确认的软件需求规格说明书的要求，检查系统的需求实现。确认需求的测试依据是需求阶段产生的测试脚本（测试用例）。 国内项目组的现实情况有以下几种：（1）没有确认测试；（2）没有独立的确认测试，测试与设计、编码不分离；（3）有独立的确认测试，但测试用例是设计和编码人员写的，因此，独立测试人员相当于按设计和编码人员的设计思路再测一遍。 上述这些情况，就丧失了确认测试的大部分意义。正确的确认测试是独立的测试组中，具有相应知识的测试设计师，根据需求规格说明书，并依据该软件在用户方面将会是在什么环境下，用户将如何使用该软件，来设计测试方案和测试用例，安排测试人员进行测试。很显然，现实离理想的距离还比较遥远。 确认测试还包括软件经修改后的再测试（回归测试）。回归测试是对已测试并发现故障的部分，修改后进行再测试。回归测试不应修改测试程序、测试内容或测试标准。它与正常测试不同的仅是：它可能并不需要再完整地走一遍所有的确认测试，而是小心地选择部分确认测试程序，选择的标准是不减低原标准的整体要求。

ɑ测试和 ß测试  为了实际检验软件的功能和性能，有时，常邀请特定的用户帮助试用（测试）系统正式发布前的版本，请用户对系统进行评价。这就是通常所说的ɑ测试和ß测试。 ɑ测试是由一个用户在开发者的场所，在开发者指导下进行的测试。开发者记录下问题和错误，是在开发者“控制”下的测试。 ß测试是用户的环境中，开发者可能并不在现场，由用户“活用”系统情况下的测试。用户记录下问题，报告给开发者。 在商用套装软件中，这种情况比较多见，在行业应用系统中，由于现实环境并不允许不成功的软件直接投入使用，用户也没有参与测试义务、时间和资源的投入和配合的积极性，因此，这种测试很少发生。

验收测试 在行业应用软件环境中，验收测试是项目过程非常重要的一环，也是项目经理非常关注的一项工作。 验收测试与确认测试非常相似，所不同的是，确认测试是项目组或组织内部的测试，验收测试是用户主导、现场参与、现场环境下的测试。 验收测试通常由项目组先提出测试大纲，定义测试目的、范围、方法、测试用例、预期结果、验收标准等。经用户同意批准，可能包括用户的修改、增加后，确定测试时间，开始进入验收测试。 用户在完成按测试用例的测试后，在测试记录上逐条确认、签字，最后，在测试报告上签字，完成验收测试。 一般地、验收测试报告是项目初验、终验的依据和主要验收形式。

单元测试与验收测试 单元测试和验收测试没有什么区别？ 单元测试可以类比为一个建筑的质检人员对建筑进行的检测， 他关注的重点是建筑的内部结构、地基、框架以及墙壁是否垂直等。他的检测是要保证建筑的各个部分是正常的、安全的，换句话说，就是要保证施工满足建筑上面的质量标准。 验收测试可以类比为建筑的使用者来对建筑进行的检测。他关心建筑的外观是否美观、各个房间的大小是否合适，窗户的位置是否合适，是否能够满足家庭的需要等。这里，建筑的使用者执行的就是验收测试，他是从用户的角度出发的。 正是这种角度的不同决定了单元测试和验收测试之间的区别。它们是对系统的不同的方面进行的测试，二者是互相补充的。不管我们在系统的构建中使用了多么聪明的方法，不管我们的系统是多么的灵活，但是首先我们的产品必须是可用的，否则我们所做的就是浪费时间，从这一点上来说验收测试要比单元测试显得更加重要。

6.2.2 测试方法 测试所处的阶段不同，方法也不同： 白盒测试在单元测试阶段，由于测试者对被测对象的内部结构、逻辑思路、接口关系等比较熟悉，一般采取白盒测试的方法，它是根据模块的内部逻辑，进行测试设计的方法。有些集成测试也采用白盒方法，关键看集成阶段的划分。 黑盒测试在集成测试以至此后的各阶段，测试设计和测试人员，对被测对象的内部结构不了解也不需要了解，他的目的是按需求功能进行确认。因此，黑盒测试是严格按软件需求进行测试设计的方法。 代码走查

6.2.3 测试类型在不同阶段，测试的类型也不相同，常有的测试类型是：（ 1）功能测试：软件实现的功能是否符合需求规格说明书中定义的功能；（ 2）性能测试：软件在规定配置下的性能是否符合需求规定；（ 3）算法测试：确认实现的算法的正确性；（ 4）正向测试：按照用户正常的理解、操作方式、思维和使用习惯使用软件，得到的结果是否与需求一致。（ 5）逆向测试：如果不按用户正常的理解、操作发生、思维和使用习惯使用软件，软件是否能正确地进行处理。如：无效操作、错误的数据输入处理、非法进入等。（ 6）边界测试：按软件的限制、假设条件的边界输入，进行测试。（ 7）配置测试：对软件环境进行配置变化，软件需求实现，特别是性能实现是否能符合需求规定要求。（ 8）负载测试：在业务处理量、数据负载量、通讯负载量达到何种情况，系统的性能变化和承载能力情况。

6.2.4 测试计划测试估计在拟定测试计划时，首先需要对以下情况，做出估计：（ 1）     完成测试设计所需要的工作量：（2）     完成测试设计所需要的工作时间：（3）     完成测试所需要的时间：根据以上三个部分的结果，我们已经知道了测试的范围、内容、任务分配、时间等，这样，项目经理可以能比较充分地规划资源，制订出一份比较全面和切实的测试工作计划。测试分配测试计划确定了测试的范围、内容和估计时间，根据WBS 方法，测试计划还应说明具体测试任务的分解和测试工作的分配。测试组的成员根据分工，各自完成一部分测试任务。测试组与项目开发组还需要保持一定的同步，使测试与开发、修改在协调的步骤下进行，以节约宝贵的项目总时间。测试确认

测试用例名称 工号权限 被测子系统名 卡 /号资源管理测试用例来源 公司测试组 □ 内部测试抽查参考文档序号 测试用例描述XWYY001 

测试目的 能否正确识别合法的操作员进入应用系统测试步骤 1.启动“卡 /号资源管理”应用程序。 2. 输入系统中不存在的工号 1000 ，再输入密码 12345 ，检查能否进入系统。 3.输入系统中存在的工号 nj001 和正确的密码，检查能否进入系统。 4. 输入系统中存在的工号 yd002和正确的密码，检查能否进入系统。输入数据描述 1 、工号 1000根本不是系统合法的工号。 2、工号 nj001 是前台营业受理的工号，不能进行卡号资源管理系统。 3、工号yd002是卡号资源管理系统的工号。期望的结果 1. 工号 1000 无论如何进入不了系统，系统提示无此员工2. 工号 nj001 也不能进入系统，系统提示该操作员无权执行卡号资源管理系统3．工号 yd002可以进入系统，并能打开所有的功能菜单测试结果描述 相符测试人员 测试日期 2003-03-08复测人员 复测日期 备注

测试报告： 收集齐上述的所有测试用例，构成了测试报告的基本要件。 测试报告是对所有测试用例测试过程的总结。 在测试报告中，应反映： （ 1）测试中出现问题的统计汇总和分析； （ 2）未解决问题的汇总和解决方案建议； （ 3）回归测试的统计和分析（度量） ； （ 4）对测试计划的总结或修改。关于测试用例的问题讨论： 测试用例由谁设计？ 设计测试用例的目的和依据是什么？

6.2.5 测试过程组织一个独立的测试小组为例，测试过程一般如下：（ 1）测试准备：制定人员、环境、工具、培训和外部支持计划。（ 2）测试计划：确定测试策略、建立测试计划。（ 3）测试用例：建立测试顺序树、确定测试的优先级、详细列出测试程序和测试数据，设计测试用例。（ 4）测试环境：了解需求、搭建环境、安装备份和恢复程序，记录初始环境、测试环境、恢复环境等。（ 5）测试执行：从测试计划复审测试计划进度表、恢复测试执行环境。（ 6）结果分析：执行结果分析、度量。（ 7）测试报告：错误趋势图、测试变动指示、产品检查点建议。

6.1 软件质量的度量6.2 软件的确认6.3 软件的验证

6.4 软件质量保证过程6.5 软件质量保证体系6.6 测试方法与工具介绍

第六章 • 目录

6.3 6.3 软件的验证软件的验证6.3.1 6.3.1 审查准备审查准备6.3.2 6.3.2 审查过程审查过程6.3.3 6.3.3 需求审查需求审查6.3.4 6.3.4 设计审查设计审查6.3.5 6.3.5 代码审查代码审查6.3.6 6.3.6 测试审查测试审查

软件审查的概念回顾：我们在上节介绍软件的确认和验证过程时，已经介绍了软件验证的回顾：我们在上节介绍软件的确认和验证过程时，已经介绍了软件验证的三个过程是：审查、测量和配置管理。同时，我们也谈到，验证与确认的三个过程是：审查、测量和配置管理。同时，我们也谈到，验证与确认的区别是，确认是在整个软件系统完成交付前或某模块完成交付前的检查，区别是，确认是在整个软件系统完成交付前或某模块完成交付前的检查，它的检查点是交付前。而验证贯穿于整个开发过程，是对过程的确认。因它的检查点是交付前。而验证贯穿于整个开发过程，是对过程的确认。因此，验证的范围包括了整个开发过程，它是软件质量保证并持续改进的强此，验证的范围包括了整个开发过程，它是软件质量保证并持续改进的强大工具。大工具。 什么是审查，审查是一个正式的、严格的、具有深度的技术评审过程。什么是审查，审查是一个正式的、严格的、具有深度的技术评审过程。因此，评审的目的是：因此，评审的目的是： （（ 11 ）在软件开发过程中，尽早可能地发现问题，特别是过程性的问题；）在软件开发过程中，尽早可能地发现问题，特别是过程性的问题； （（ 22 ）确保对需求保持一致的意见；）确保对需求保持一致的意见； （（ 33 ）验证任何修改和变更满足预先定义的准则；）验证任何修改和变更满足预先定义的准则； （（ 44 ）为组织提供产品在质量和过程方面是否有效的实际数据；）为组织提供产品在质量和过程方面是否有效的实际数据； （（ 55 ）使团队成员之间在技术上建立相互的了解；）使团队成员之间在技术上建立相互的了解； （（ 66 ）增加软件确认测试的有效性；）增加软件确认测试的有效性； （（ 77 ）提高优秀软件工程师的水准。）提高优秀软件工程师的水准。

6.3.1 软件审查的准备评审人：审查一般由一个审查小组或审查委员会负责进行，审查小组内，评审人：审查一般由一个审查小组或审查委员会负责进行，审查小组内，应有以下角色构成：应有以下角色构成： （（ 11）主持审查活动的主审员；）主持审查活动的主审员； （（ 22）被审查产品的负责人，包括产品经理、技术经理、质量经理等；）被审查产品的负责人，包括产品经理、技术经理、质量经理等； （（ 33）负责对被审查产品进行讲解和解释的主讲人；）负责对被审查产品进行讲解和解释的主讲人； （（ 44）来自各有关部门的审查员；）来自各有关部门的审查员； （（ 55）记录员；）记录员； （（ 66） 项目经理） 项目经理 项目经理应该参与软件的审查过程，关注审查结果，但不一定要参项目经理应该参与软件的审查过程，关注审查结果，但不一定要参加审查会议。这要看审查的级别。如果是组织内的项目级审查，项目经加审查会议。这要看审查的级别。如果是组织内的项目级审查，项目经理作为被审查产品的负责人，应参加审查会议，否则，应该由具体的产理作为被审查产品的负责人，应参加审查会议，否则，应该由具体的产品、技术或质量经理去参加这样的会议。品、技术或质量经理去参加这样的会议。 被审产品的负责人参加这样的会议，不是为了解释审查中发现的缺被审产品的负责人参加这样的会议，不是为了解释审查中发现的缺陷，及其责任，进行辩解，而只是如实地向审查小组介绍产品为什么要陷，及其责任，进行辩解，而只是如实地向审查小组介绍产品为什么要这样做，和做了什么。审查的目的不是为了追究什么人的责任，而是为这样做，和做了什么。审查的目的不是为了追究什么人的责任，而是为了改进过程。如果把评审，引入到人与人之间的斗争中去，则完全丧失了改进过程。如果把评审，引入到人与人之间的斗争中去，则完全丧失了评审，作为过程改进手段的意义。了评审，作为过程改进手段的意义。

评审内容及要求，见下表：评审内容及要求，见下表：审查类型审查类型 被审查项被审查项 需提交的资料需提交的资料 提交审查条件提交审查条件

需求需求 软件需求规格说软件需求规格说明书明书 软件需求规格说明书及软件需求规格说明书及在此之前有关的需求分在此之前有关的需求分析文档、需求基线及批析文档、需求基线及批准文档准文档确认的需求、已确认的需求、已经被分析和形式经被分析和形式化描述，需求基化描述，需求基线已经被确定线已经被确定

设计设计 软件设计说明软件设计说明 软件设计文档软件设计文档 设计完成设计完成

编码编码 源代码模块源代码模块 源程序代码、设计文档、源程序代码、设计文档、组织的编码标准与规范组织的编码标准与规范 被审查模块已经被审查模块已经编译正确并完成编译正确并完成独立测试独立测试确认测试确认测试 测试记录测试记录 测试结果报告、质量和测试结果报告、质量和验收标准 验收标准 系统确认及回归系统确认及回归测试已经完成 测试已经完成

审查员的职责审查员的职责 作为被审查对象的项目组，按照审查组的要求，提交被审查材料，接作为被审查对象的项目组，按照审查组的要求，提交被审查材料，接受审查。受审查。作为审查员，应该做什么准备？作为审查员，应该做什么准备？首先，明确作为审查员的定角色位、职责。首先，明确作为审查员的定角色位、职责。审查员是那些具有相关知识和对被审查产品具有一定熟悉程度的，但不审查员是那些具有相关知识和对被审查产品具有一定熟悉程度的，但不一定就是直接从事相同岗位（有时，还特别需要交叉换位）的人员。在一定就是直接从事相同岗位（有时，还特别需要交叉换位）的人员。在参加审查前，他必须花一定的时间和精力，来了解产品，并能通过阅读参加审查前，他必须花一定的时间和精力，来了解产品，并能通过阅读提交的资料，了解产品与文档、标准和规范之间的差异。提交的资料，了解产品与文档、标准和规范之间的差异。因此，他在审查中的责任是：因此，他在审查中的责任是：（（ 11 ）必须完全熟悉要审查的产品和产品所依据的文档和标准；）必须完全熟悉要审查的产品和产品所依据的文档和标准；（（ 22 ）对照产品和文档，鉴别其中的差异；）对照产品和文档，鉴别其中的差异；（（ 33 ）客观地评价差异，识别是属于实现的程度差别、缺陷，还是错）客观地评价差异，识别是属于实现的程度差别、缺陷，还是错误；误；（（ 44 ）判断差异是实现的个体现象，还是过程问题；）判断差异是实现的个体现象，还是过程问题；（（ 55 ）以对产品而不是对人的态度，对差异进行评估和分析；）以对产品而不是对人的态度，对差异进行评估和分析；（（ 66 ）向主审员报告审查结果和分析意见。）向主审员报告审查结果和分析意见。

在审查开始之前，审查组与被审查项目的有关人员，产品经理、技在审查开始之前，审查组与被审查项目的有关人员，产品经理、技术经理、质量经理和项目经理们开一个“审查开工会”，主审员向被审术经理、质量经理和项目经理们开一个“审查开工会”，主审员向被审查对象的有关人员介绍本次审查的目的、对象、范围和内容，有必要的查对象的有关人员介绍本次审查的目的、对象、范围和内容，有必要的话，花一点时间介绍一下审查方法，使得审查员和被审查项目的有关人话，花一点时间介绍一下审查方法，使得审查员和被审查项目的有关人员，在审查过程中易于沟通和理解。当被审查有关人员知道（不是同员，在审查过程中易于沟通和理解。当被审查有关人员知道（不是同意）审查的主要内容后，主审员把审查工作，按分工，分配给各审查员，意）审查的主要内容后，主审员把审查工作，按分工，分配给各审查员，并请项目组指定有关的配合人员。会议约定好完成分组审查的时间，即并请项目组指定有关的配合人员。会议约定好完成分组审查的时间，即召开审查汇报会的时间。召开审查汇报会的时间。 获得审查资料的审查员，可以开始从看资料如手，进入审查阶段。获得审查资料的审查员，可以开始从看资料如手，进入审查阶段。如果需要实际测试和运行检查，项目组要配合安排机器时间、软件演示如果需要实际测试和运行检查，项目组要配合安排机器时间、软件演示等与操作有关的环境。等与操作有关的环境。 审查员经过一段时间的工作，已经对所分工的部分，通过阅读资料、审查员经过一段时间的工作，已经对所分工的部分，通过阅读资料、实际查看等，获得了必要的信息，有关的疑问，通过向项目组实际询问，实际查看等，获得了必要的信息，有关的疑问，通过向项目组实际询问，解释了不清楚的地方。审查员对差异，已经做好了记录。主审员按时间解释了不清楚的地方。审查员对差异，已经做好了记录。主审员按时间和进度，可以招集审查汇报会。和进度，可以招集审查汇报会。

6.3.2 软件审查的过程

在审查汇报会上，审查员汇报分组审查中发现的潜在的（还没有定论）在审查汇报会上，审查员汇报分组审查中发现的潜在的（还没有定论）的错误、缺陷和差异。审查小组对每一个问题进行讨论，并争取获得一致的错误、缺陷和差异。审查小组对每一个问题进行讨论，并争取获得一致的意见。必要时，可以请项目组再做解释。记录员此时应详细记录讨论的的意见。必要时，可以请项目组再做解释。记录员此时应详细记录讨论的过程和各自的意见，并确保这些记录的完整性、正确性和真实性。过程和各自的意见，并确保这些记录的完整性、正确性和真实性。 如果一次会议不能解决争论的问题，或者需要再扩大参加人员的范围，如果一次会议不能解决争论的问题，或者需要再扩大参加人员的范围，或者需要再做测试，那就那样去做。或者审查组发现问题已经非常严重，或者需要再做测试，那就那样去做。或者审查组发现问题已经非常严重，已经超出了软件评审的范围，那么，应立即停止评审，向有关上级报告问已经超出了软件评审的范围，那么，应立即停止评审，向有关上级报告问题，以便上级做出重大改进的措施。题，以便上级做出重大改进的措施。 审查结果的发布是一个非技术的敏感问题。什么性质的结果可以发布，审查结果的发布是一个非技术的敏感问题。什么性质的结果可以发布，在多大范围内发布。审查结果如果比较满意，它的发布将对项目组是一个在多大范围内发布。审查结果如果比较满意，它的发布将对项目组是一个正向的激励，是相关人员能力的象征。负面的审查结果可能引来更大的争正向的激励，是相关人员能力的象征。负面的审查结果可能引来更大的争议和动荡。因此，审查小组和项目经理，要充分沟通，从积极的方面，使议和动荡。因此，审查小组和项目经理，要充分沟通，从积极的方面，使用审查结果。用审查结果。 任何审查结果都不是针对个人的，但是任何工作都是由具体个人来负责任何审查结果都不是针对个人的，但是任何工作都是由具体个人来负责和承担相应责任的。因此，审查结果的难处，就在这句话的二面性。和承担相应责任的。因此，审查结果的难处，就在这句话的二面性。

6.3.3 需求审查需求审查表（问题清单）需求审查表（问题清单） （（ 11 ） 需求是否定义了要向用户展示的全部信息？） 需求是否定义了要向用户展示的全部信息？（（ 22 ） 需求是否论述了系统对用户错误操作的反映？） 需求是否论述了系统对用户错误操作的反映？（（ 33 ） 每一需求项的描述是否清楚、简洁和没有二意性？） 每一需求项的描述是否清楚、简洁和没有二意性？（（ 44 ） 每一项需求是否都是可测试的？） 每一项需求是否都是可测试的？（（ 55 ） 需求是否有隐含或暗示的功能理解？） 需求是否有隐含或暗示的功能理解？（（ 66 ） 需求项之间是否有自相矛盾的地方？） 需求项之间是否有自相矛盾的地方？（（ 77 ） 需求是否有应该论述但没有提及的地方？） 需求是否有应该论述但没有提及的地方？（（ 88 ） 需求对实时性、精确度、负载能力等有没有定义？） 需求对实时性、精确度、负载能力等有没有定义？（（ 99 ） 需求是否包括了性能需求、质量需求等非功能需求？） 需求是否包括了性能需求、质量需求等非功能需求？（（ 1010 ） 如果需求涉及复杂的关联关系、复杂的算法、复杂的决策） 如果需求涉及复杂的关联关系、复杂的算法、复杂的决策机制，用户能完全理解吗？机制，用户能完全理解吗？（（ 1111 ） 需求对软件升级、版本变更是否有明确的承诺？） 需求对软件升级、版本变更是否有明确的承诺？（（ 1212 ） 需求文档是否含有不必要的设计细节？） 需求文档是否含有不必要的设计细节？（（ 1313 ） 是否可以根据需求，开发出适当的和完整的测试用例集？） 是否可以根据需求，开发出适当的和完整的测试用例集？（（ 1414 ） 需求的假设和限制条件是否明确？） 需求的假设和限制条件是否明确？

6.3.3 需求审查需求审查过程需求审查过程 我们在上一节，已经一般地讨论过审查的过程。需求审查也遵循这我们在上一节，已经一般地讨论过审查的过程。需求审查也遵循这样的过程：组织审查组；收集项目组提交的被审查资料；确定审查日样的过程：组织审查组；收集项目组提交的被审查资料；确定审查日期；审查员在获得审查任务分配和开始工作，包括：对资料的阅读和期；审查员在获得审查任务分配和开始工作，包括：对资料的阅读和评审、做实地的检查、调查和询问、记录并报告；参加评审会议并报评审、做实地的检查、调查和询问、记录并报告；参加评审会议并报告自己的发现和分析。告自己的发现和分析。 审查小组首先检查审查活动是否充分和没有偏差、疏漏。审查员对审查小组首先检查审查活动是否充分和没有偏差、疏漏。审查员对问题的认识有没有片面和主观。主审员根据自己的经验，可能会对年问题的认识有没有片面和主观。主审员根据自己的经验，可能会对年轻的审查员要求做出补充调查。通过讨论，审查小组争取对问题取得轻的审查员要求做出补充调查。通过讨论，审查小组争取对问题取得一致的意见，并形成审查报告。一致的意见，并形成审查报告。 追踪与改正追踪与改正 审查的目的是监督项目组对软件的品质，保持良好的状态和不断地审查的目的是监督项目组对软件的品质，保持良好的状态和不断地改进。因此，审查小组有责任跟踪项目组对审查结果的利用情况。改进。因此，审查小组有责任跟踪项目组对审查结果的利用情况。 关注项目组的改进，是项目经理比关注审查结果更重要的事情。关注项目组的改进，是项目经理比关注审查结果更重要的事情。

6.3.4 设计审查概要设计审查表（问题清单）概要设计审查表（问题清单） 详细设计审查表（问题清单）详细设计审查表（问题清单） 设计审查的目标：设计审查的目标： 概要设计重点审查以下几个方面（概要设计针对需求）概要设计重点审查以下几个方面（概要设计针对需求） （（ 11）概要设计对需求的完整实现； ）概要设计对需求的完整实现； （（ 22）概要设计与需求的一致性；）概要设计与需求的一致性； （（ 33）概要设计向需求的反向可追踪；）概要设计向需求的反向可追踪； （（ 44）概要设计中，对系统结构设计的逻辑性、合理性）概要设计中，对系统结构设计的逻辑性、合理性和可扩展性；和可扩展性； 由于概要设计是直接衔接需求的，因此，概要设计审查由于概要设计是直接衔接需求的，因此，概要设计审查更多地是把设计与需求相衔接。更多地是把设计与需求相衔接。

在在详细设计中，应重点审查以下方面（详细设计针对实详细设计中，应重点审查以下方面（详细设计针对实现）现） （（ 11）设计应符合组织即定的标准；）设计应符合组织即定的标准； （（ 22 ）设计结果对下一阶段的编码是可用的。）设计结果对下一阶段的编码是可用的。 由于详细设计直接提供编码实现，因此，在组织内，由于详细设计直接提供编码实现，因此，在组织内，应对详细设计的“粒度”做出规定。这样，即明确详细应对详细设计的“粒度”做出规定。这样，即明确详细设计与代码实现的界面，同时，也是编码标准化的工作设计与代码实现的界面，同时，也是编码标准化的工作基础。在这方面，应结合实际，进行研究。基础。在这方面，应结合实际，进行研究。

6.3.4 设计审查

6.3.5 代码审查代码的审查与具体实现工具有关，而且与具体实现工具的版本有关，代码的审查与具体实现工具有关，而且与具体实现工具的版本有关，因此，我们在这里就不具体讨论代码审查的内容。有不少文章具体讨因此，我们在这里就不具体讨论代码审查的内容。有不少文章具体讨论代码的标准化和设计技巧，可以作为审查的范本（如果必要的话）。论代码的标准化和设计技巧，可以作为审查的范本（如果必要的话）。 代码审查的一个办法是走查。就是由审查人员“读”工程师写的代码审查的一个办法是走查。就是由审查人员“读”工程师写的代码，然后对照“标准”进行检查，是对软件文档的一种书面检查。代码，然后对照“标准”进行检查，是对软件文档的一种书面检查。它通过人工模拟执行源程序的过程，检查软件设计的正确性。人工模它通过人工模拟执行源程序的过程，检查软件设计的正确性。人工模拟也像计算机执行那样，可以仔细推敲、校验和核实每一步的执行结拟也像计算机执行那样，可以仔细推敲、校验和核实每一步的执行结果，进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确果，进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性。性。 走查是一件非常艰苦的工作，同时是需要非常大的毅力和记忆力走查是一件非常艰苦的工作，同时是需要非常大的毅力和记忆力的工作。因为一个系统程序量之大，组织的规则和要求之多。审查员的工作。因为一个系统程序量之大，组织的规则和要求之多。审查员要做的是要做的是 NN 的的 NN 次方的核对。现在也有一些计算机程序，按一定的次方的核对。现在也有一些计算机程序，按一定的规则，帮助审查员“读”程序，并挑出（有的可以做简单的修改）毛规则，帮助审查员“读”程序，并挑出（有的可以做简单的修改）毛病，病， VBVB 就有这样的程序。如果没有计算机程序的帮助，审查员会就有这样的程序。如果没有计算机程序的帮助，审查员会“疯”掉的。“疯”掉的。

6.3.6 测试审查测试审查是对测试结果进行审查，它审查的内容包括测试审查是对测试结果进行审查，它审查的内容包括 （（ 11）对测试用例的审查：测试用例的哪些要素（用）对测试用例的审查：测试用例的哪些要素（用例名、测试日期、预期测试结果等）是否齐备？（宽例名、测试日期、预期测试结果等）是否齐备？（宽度）度） （（ 22）在概要设计和详细设计中确定的关键点或特殊）在概要设计和详细设计中确定的关键点或特殊需求是否都测试到了？（深度）需求是否都测试到了？（深度） （（ 33）测试过程（步骤、环境、用户模拟等）的设计）测试过程（步骤、环境、用户模拟等）的设计是否正确、恰当？是否正确、恰当？ （（ 44）预期值与结果值的差异统计；）预期值与结果值的差异统计； （（ 55）测试目的是否达到？）测试目的是否达到？

6.1 软件质量的度量6.2 软件的确认6.3 软件的验证

6.4 软件质量保证过程6.5 软件质量保证体系6.6 测试方法与工具介绍

第六章 • 目录

6.4 6.4 软件质量保证过程软件质量保证过程6.4.1 6.4.1 现代质量管理回顾现代质量管理回顾6.4.2 ISO90006.4.2 ISO9000 质量管理体系质量管理体系6.4.3 PMBOK6.4.3 PMBOK 的质量管理的质量管理6.4.4 CMM26.4.4 CMM2 的质量保证的质量保证

6.4.1 现代质量管理回顾 现代质量管理是对项目管理的补充 现代质量管理在以下方面，做出更多的强调： （ 1）     以客户满意为质量目标； （2）     比注重结果更多地注重过程； （3）     管理层对质量负有责任。 这些观点，是以下这些质量管理大师和前辈，在逐步总结质量管理经验的基础上，建立起来的。

ISO9000质量管理体系  什么是质量认证 质量认证也叫合格评定，是国际上通行的管理产质量的有效方法。质量认证按认证的对象分为产质量认证和质量体系认证两类；按认证的作用可分为安全认证和合格认证。 什么是产品质量认证 产品质量认证是指依据产品标准和相应技术要求，经认证机构确认并通过颁发认证证书和认证标志来证明某一产品符合相应标准和相应技术要求的活动。 什么是质量体系认证 质量体系认证的对象是企业的质量体系，或者说是企业的质量保证能力。

ISO9000质量管理体系 质量体系文件的层次

第一层：质量手册 第二层：程序文件 第三层：作业指导书

管理性第三层文件（如：车间管理办法、仓库管理办法、文件和资料编写导则、产品标识细则等） 技术性第三层文件（如：产品标准、原材料标准、技术图纸、工序作业指导书、工艺卡、设备操作规程、抽样标准、检验规程等）

第四层 表格与（质量）记录。

ISO9000质量管理体系 质量体系文件的作用1. 质量体系文件确定了职责的分配和活动的程序，是企业内部的“法规”。 2. 质量体系文件是企业开展内部培训的依据。 3. 质量体系文件是质量审核的依据。4. 质量体系文件使质量改进有章可循。ISO9000 质量管理的 8 项原则：

原则 1 ： 以顾客为中心  原则 2： 领导作用 原则 3： 全员参与  原则 4： 过程方法  原则 5 ： 管理的系统方法  原则 6 ： 持续改进 原则 7： 基于事实的决策方法 原则 8 ： 互利的供方关系 

ISO9000质量管理体系 ISO9000-94与 ISO9000-2000版之间的主要区别（ 1）在管理思想上的发展：

（2）在体系文件管理上变化： （3）更强调内部沟通：（4）更加强调有效的持续改进： （ 5）增加了一条“允许的裁剪”： （ 6）数据分析和处理：

6.4.3 CMM2的质量保证过程 CMM2质量保证（ SQA）的目标 CMM2对 SQA确定了 4个目标，它们是： 目标 1 ：对软件质量保证活动做到有计划； 目标 2：客观地验证软件产品及其活动是否遵守应用的 标准、规程和需求； 目标 3：将软件质量保证活动及其结果及时通知相关小 组和个人； 目标 4 ：由上级管理部门及时处理软件项目内部解决不 了的不一致性问题。

CMM2的质量保证过程 CMM2的质量保证活动 CMM2对 SQA定义了 8 项活动，它们是：活动1 ：与项目总体计划同步地制订SQA计划；活动2： SQA组按SQA计划进行活动；活动3： SQA组要参与制订和评审项目的软件开发计划、标准 和规程；活动4： SQA小组要评审软件工程活动，验证其一致性；活动5 ： SQA小组要审核软件产品，验证其一致性；活动6 ： SQA小组要定期向软件工程组报告活动结果；活动7：依据规定，归档和处理软件活动和产品中的偏差；活动8 ：合适时，与用户的 SQA人员定期对 SQA组的活动和结 果，进行评审。

CMM2的质量保证过程 CMM2 的测量分析 CMM2对 SQA活动的成本消耗和进度情况，进行测量和分析，例如： SQA活动的里程碑完成情况，与计划相比较进行分析；SQA活动已完成的工作所花费的工作量和成本与计划的比较分析；产品审核和活动评审的次数与计划的比较分析等。 CMM2的验证执行 验证活动主要包括二个方面，一是上级管理部门要实施定期地对 SQA活动的评审，适当地、及时地掌握软件过程活动。二是项目负责人要定期和根据实际需要，随时地评审 SQA 的活动，实行对软件活动的跟踪和监督。

ISO9000 与 CMM的比较比较内容 2000版 ISO/DIS9001 CMM

管理体系 强调完整的组织体系，可以用来建立符合 ISO9000 管理的组织管理本身对管理体系没有明确要求，默认组织体系是有效的、健全的。

管理侧重 组织管理过程管理 项目管理技术管理过程的控制以KPA的形式来强调各环节的管理，但缺乏整个过程的管理。管理职责 强调宏观上的管理职责 强调项目管理中不同角色职责文件体系 分为组织层（规范）文件和项目层文件，并将文件体系化分为质量手册、程序文件和作业指导书，层次清楚

所有文件同等对待

数据分析 加强了数据分析、测量 在定量过程管理（ KPA）中强调适用范围 所有行业，但对软件行业的适用性不够强，对企业规模无要求

大型软件企业（ 500人以上），对于 500人以下的中小型企业需要进行裁剪

ISO9000 与 CMM的比较管理理念 以顾客满意为目标 评价承包商的软件成熟能力配置管理 弱 强需求管理 强调了合同评审，但对需求的管理很弱 对需求管理有很强的控制，但没有对合同评审进行控制评审 有较强的管理评审，但对技术评审管理较弱 有较强的技术评审，但对管理评审的控制较弱内部沟通 强调内部沟通 强调内部沟通，并通过组际协调（ KPA）来实现。外部沟通 强调内部沟通 强调内部沟通，并通过组际协调（ KPA）来实现。变更管理 弱 强（有专门的 KPA进行控制，包括技术变更和过程变更）

比较内容 2000版 ISO/DIS9001 CMM

6.4.4 PMBOK的质量管理过程 项目的质量的二层含义项目的质量的二层含义

从项目作为一项最终产品来看，项目质量体现在其性从项目作为一项最终产品来看，项目质量体现在其性能或者使用价值上，也即能或者使用价值上，也即项目的产品质量项目的产品质量。。从项目作为一次性的活动来看，项目管理质量体现在从项目作为一次性的活动来看，项目管理质量体现在由由 WBSWBS 反映出的项目范围内所有的阶段、子项目、项反映出的项目范围内所有的阶段、子项目、项目工作单元的质量所构成，也即目工作单元的质量所构成，也即项目的工作质量项目的工作质量；；

项目是应业主的要求进行的项目是应业主的要求进行的 ,,不同的业主有着不同的产品不同的业主有着不同的产品质量要求，其意图已反映在项目合同中。因此，质量要求，其意图已反映在项目合同中。因此，项目合同项目合同是进行项目产品质量管理的主要依据是进行项目产品质量管理的主要依据。。 PMBOKPMBOK 的项目质量管理是：的项目质量管理是：

在质量体系中，决定质量工作的策略、目标和责任的在质量体系中，决定质量工作的策略、目标和责任的全部管理功能有关的所有活动，并通过诸如质量计划、全部管理功能有关的所有活动，并通过诸如质量计划、质量保证和质量提高等手段来完成这些活动。质量保证和质量提高等手段来完成这些活动。

PMBOK的质量管理过程PMBOKPMBOK 的质量管理过程是：的质量管理过程是：

质量计划质量计划 ---- 确定哪些质量标准适用于该项目，并决定确定哪些质量标准适用于该项目，并决定如何达标。如何达标。质量保证质量保证 ---- 在常规基础上对整个项目执行情况作评估，在常规基础上对整个项目执行情况作评估，以提供信用，保证该项目将能够达到有关质量标准。以提供信用，保证该项目将能够达到有关质量标准。质量控制质量控制 ---- 监控特定项目的执行结果，以确定它们是监控特定项目的执行结果，以确定它们是否符合有关的质量标准，并确定适当方式消除导致项否符合有关的质量标准，并确定适当方式消除导致项目绩效令人不满意的原因。目绩效令人不满意的原因。

这些工作程序互有影响，并且与其它知识领域中的程序之这些工作程序互有影响，并且与其它知识领域中的程序之间也存在相互影响。依据项目的需要，每道程序都可能包间也存在相互影响。依据项目的需要，每道程序都可能包含一个或更多的个人或由团队的努力。在每个项目阶段中，含一个或更多的个人或由团队的努力。在每个项目阶段中，每道程序通常都会至少经历一次。每道程序通常都会至少经历一次。

PMBOK 的项目质量管理过程一——质量计划 质量计划的目的是：

确定哪些质量标准与项目有关及如何达到这些质量标准

质量计划回答： 质量管理的目标要素是什么？如何产生和确定这些要素的？ 如何度量、评价这些要素，并证实已经达到了这些要素的要求衡量质量的二个重要指标：

可靠性、可维护性 对产品和服务进行细致的质量计划，可提高产品或服务的可靠性与可维护性

质量计划过程的输入 质量方针：质量方针是对项目的质量目标和方向所作出的一个指导性文件，因此项目管理工作组应制定自己的质量工作方针，同时项目的质量方针应与项目的投资者完全共享。 范围陈述：项目的范围陈述说明了投资者的需求以及项目的主要要求和目标，因此范围陈述是项目质量计划确定的主要依据和基础。 产品描述：尽管产品描述的相关要素可能在范围描述中予以强调，然而产品的描述通常包含更加详细的技术要求和其它的内容，它对于项目质量计划的制定非常有用。 标准和规则：项目质量计划的制定必须考虑到任何实际应用领域的特殊的标准和规则，这些都将影响项目质量计划的制定。 其它工作的输出：除了上述范围陈述、产品描述之外，其他方面的工作输出也会对项目计划的制定产生影响，比如说采购计划就要说明承包人的质量要求从而影响到项目质量管理的计划。 质量成本：质量成本是指为了达到产品 / 服务的质量标准而进行的全部工作所发生的所有成本。包括一致成本和不一致成本，后者又包括预防、鉴定和故障成本。

质量成本 质量成本包括：

一致成本：计划编制、培训辅导、过程控制、实地测量、设计确认、过程确认、测量评价、质量审计、维护校准 不一致成本：废料、返工、加速处理、额外材料或存货、现场维修、保修服务、投诉处理、责任判定、产品取消、改正措施 质量成本又可以分为： P 成本、 A 、 F 成本，如下表：

预防成本（ P- 成本Preventive ） 培训、过程能力研究、卖主 /供应商调查

评估成本（ A成本 -Appraisal） 检查和测试、检查和测试设备维护、处理并报告检查数据的成本、设计审查、内部设计审查、走查、费用审查

缺陷成本（ F成本 -Failure）

内部缺陷成本 废料与返工、与推迟付款有关的费用、缺陷存货成本、工程变动成本、设计错误纠正、纠正文档外部缺陷成本 担保费用、现场服务人员培训、产品责任诉讼、投诉处理、未来经营损失

质量计划制定的方法和技术  利益 / 成本分析：质量计划必须综合考虑利益 / 成本的交换，满足质量需求的主要利益是减少重复性工作，这就意味着高的产出、低的支出及增加投资者的满意度。满足质量要求的基本费用是辅助项目质量管理活动的付出，其基本原则是利益与成本之比尽可能的大。 基准：基准主要是通过比较实际或计划项目的实施与其它同类项目的实施过程，为改进项目实施过程提供思路和提供一个实施的标准。 流程图：

——原因结果（鱼刺）图：—— 系统流程图 :

试验设计：试验设计对于分析辨明对整个项目输出结果最有影响的因素是很为有效的，但该方法的应用存在着费用进度交换的问题。

因果（鱼刺）图：主要用来分析和说明各种因素和原因是如何导致或者产生主要问题和后果的。

特点：用图表形式表示各因素之间的关系是头脑风暴、过程考察等分析活动的常用工具有利于刺激思考、、组织思路

系统流程图

系统流程图 :主要用来说明系统各种要素之间存在的相互关系，通过流程图可以帮助项目组提出解决质量问题的相关方法。

质量计划过程的输出 质量管理计划：质量管理计划主要描述项目管理组应该如何实施它的质量方针。 具体操作说明：对于一些特殊条款需要附加的操作说明，包括对他们的解释及在质量控制过程中如何度量的问题。比如说满足项目进度日期不能足以说是对项目管理质量的度量，项目管理组还必须指出每一项工作是否按时开始或者按时结束，各个独立的工作是否被度量或者仅是做了一定的说明等类似情况。 检查表格：检查表格是一种用于对项目执行情况进行分析的工具，其可能是简单的也可能是复杂的，通常的描述包括命令和询问两种形式。许多组织已经形成了标准的确保频繁执行的工作顺利执行的体系。 其它过程的输入：质量计划过程也有助于对其它领域工作的开展。

PMBOK的项目质量管理过程二——质量保证  质量保证是在质量体系中实施的全部有计划、有系统的活动，它用来树立满足项目相关标准的信心。 质量保证是所有计划和系统工作实施达到质量计划要求的基础，为项目质量系统的正常运转提供可靠的保证，它应该贯穿于项目实施的全过程之中。在 ISO9000 系列实施之前，质量保证通常被描述在质量计划之中。 检查表 质量保证通常是由质量保证部门或者类似的组织单元提供，但是不必总是如此。质量保证通常提供给项目管理组以及实施组织（内部质量保证）或者提供给客户或项目工作涉及的其它活动（外部质量保证）。

质量保证过程的输入

质量管理计划质量控制度量的结果：质量控制度量是为了比较和分析所作的质量控制测试的记录和度量。操作说明

质量保证的工具和方法 质量计划编制的工具和技术（计划编制中已经介绍） 质量审核：质量审核是确定质量活动及其有关结果是否符合计划安排，以及这些安排是否有效贯彻。通过审核：

—— 保证项目质量符合规定要求；—— 保证设计、实施与组织过程符合规定要求；—— 保证质量体系有效运行并不断完善，提高质量管理水平。

质量审核的分类包括 :—— 质量体系审核 ——项目质量审核—— 过程（工序）质量审核 ——监督审核——内部质量审核 ——外部质量审核

质量审核可以是有计划的，也可以是随机的，它可以由专门的审计员或者是第三方质量系统注册组织审核。

质量保证过程的输出 质量改进： 质量改进包括达到以下目的的各种行动：

增加项目有效性和效率以提高项目投资者的利益。 在大多数情况下，质量改进将要求改变不正确的行动以及克服这种不正确行动的过程。

PMBOK项目质量管理过程三——项目质量控制 质量控制主要是监督项目的实施结果，将项目的结果与事先制定的质量标准进行比较，找出其存在的差距，并分析形成这一差距的原因，质量控制同样贯穿于项目实施的全过程。项目的结果包括产品结果（如交付）以及管理结果（如实施的费用和进度）。质量控制通常是由质量控制部门或类似的质量组织单元实施，但是也并非总是如此。 项目管理组应该具有统计质量控制的工作知识，特别是抽样检查和概率方面的知识，以便帮助他们评价质量控制的输出。他们应该清楚以下几个方面的不同：—— 预防和检查 ——特征样本和随机样本—— 特殊原因和随机原因 ——偏差和控制线

质量控制过程的输入 工作结果：包括实施结果和产品结果 质量管理计划操作规范检查表格

质量控制的方法和技术  检查：包括度量、考察和测试 控制图： 帕累托图： 抽样调查统计： 流程图：质量控制中运用流程图有助于分析问题是如何发生的。 趋势分析：趋势分析是应用数学的技术根据历史的数据预测项目未来的发展，趋势分析通常被用来监控：—— 技术参数：多少错误或缺点已被识别和纠正，多少错误仍然未被校正——费用和进度参数：多少工作在规定的时间内被按期完成

! !

控制图可以用来监控任何形式的输出变量，它用的最为频繁，可用于监控进度和费用的变化，范围变化的量度和频率，项目说明中的错误，以及其它管理结果。

质量控制的工具

当点位于控制线内时，我们说质量是处在正常的或期望的偏差范围之内，或处于控制之中，点在界限之外时，过程失去控制七点原则：当有七个点连续的落在中线的同一侧，虽然没有超过控制线，但这也表明可能存在变动趋势，已经不属于随机因素，可能是特殊因素（故障、问题等）出现的征兆，应加以分析。

排列图（帕累托图）示例

帕累托（排列图）是一种直方图，由缺陷发生的频率组织而成，用以显示故障后果与故障原因类型之间的比例关系。项目团队应首先采取措施，查找并解决导致最多缺陷的问题。排列图是帕累特法则（ 2/8 定律）的实例，帕累特法则认为：大量（ 80%）的问题或缺陷，是由相应的少数（ 20%）原因所导致的。

质量控制的工具

抽样统计：包括抽取总体中的一个部分进行检验，适当的抽样调查往往能降低质量控制成本。与抽样有关的概念：

属性与变量抽样：属性：可被划分为与要求相符合与不符合，从而决定继续还是停止的质量属性变量：可以用计量单位测量的质量属性，如：长度、重量等。属性抽样：通过抽取属性进行检测，建立总体的置信水平。属性抽样可以是变量，也可以不是，关键是检验的结果是“是—继续”还是“不是—停止”。测试简单，但需要多样本。变量抽样：可以连续测试，只需要少量样本

标准差（ SD西格玛）：在正态分布均值两侧占总体 68.3%（ 1 个 SD）的偏差。2SD=95.5% ， 3SD=99.7%

质量控制的工具

质量控制过程的输出 质量改进措施 验收决定：每一项目都有接受和拒绝的可能，不被接受的工作需要重新进行 返工：不被接受的工作需要重新执行，项目组的目标是使得返工的工作最少。 完成的检查表：当检查结束的时候，应该完成对项目质量的记录，及完成检查表格。 过程调整：过程调整包括对质量控制度量结果的纠正以及预防工作。

提高质量的途径

目标

1

诊断分析2

行动计划3

改进4

后续措施5

定期审查6

再实现

提高质量的途径的 6 个步骤1 - 建立目标2 - 建立诊断分析方法3 - 建立行动计划4 – 改进5 - 行动计划的后续措施6 - 定期审查和更新

提高质量的途径——风险控制

风险控制故障 = 未达到预期的结果 故障

任务2

故障故障

故障

任务1

任务3

任务4

任务5

过程控制保证质量1 - 风险控制2 - 过程评估3 - 10 个标准4 - 预防5 - 监督

临界状态

原因 原因

结果故障

结果结果

原因

客户 风险控制（找到临界点）

提高质量的途径过程评估：两个领域

控制错误（外部）：确定客户需求的风险在真正需求和参与者理解的需求之间的偏差或倾向

理解的需求真正需求

控制错误（内部）：实现过程中的风险在理解的需求和产品之间的偏差或倾向

产品理解的需求

提高质量的途径10 个标准

1 过程被确定，已知其界限，它的所有者、参与者和客户都被确定2 客户的需求被详细说明，并且确定了主要特点3 有具体方法用于测定需求的满意度4 评估了故障的风险，以最少的成本控制它们的起因 (预防措施 )

5 尽早地进行检查和检测，以补救残留的风险6 实施文件中叙述了实施过程及其程序和指令7 证据（记录）已经备案并可用于增强客户的信任8 参与者了解并应用过程及其程序和指令 9 对观察的故障采取补救和改进措施，所有的修改都由预防措施所补救 10 确定并使用监督系统 

提高质量的途径过程评估过程是按 10 个标准评估的

未达到的标准使用质量管理方法和工具，按照未达到的标准进行调整注意：恰当地使用工具

1 2 3 4 5 6 7 8 9 10

提高质量的途径质量保证的工具

团队工作一个团队的效率  > 个人效率之和

供应者－客户的关系各机构考虑其直接客户的需要

统计过程控制 (SPC) 和检查卡此工具可监督一个过程的能力

本章小结与学习要点 质量、软件质量、质量管理的概念 质量成本的相关概念（ PMI比较强调的特点） PMBOK质量管理的过程：质量计划编制、质量保证和质量控制 工具和方法：     鱼刺图：帮助发现问题的根本原因     帕累托图：帮助确认引发大多数质量问题的最重要的几个因素     统计抽样：帮助确定在总体分析时的实际样本数     控制图：通过对非随机数据的及时显示来保持过程在控制中     具体技术：属性与抽样、总体与标准差、控制图、基准等

PMP考试要点 PMBOK可能与 ISO9000不相一致 质量 -镀金 /适用性 质量管理的 3个过程（计划：确定标准和如何满足；保证：通过评价项目的整体绩效，建立对质量的信心；控制确定结果是否相符确定消除不满意结果的方法） 责任：项目经理、项目组成员、管理层 质量成本 质量控制的具体技术和方法（抽样、概率、控制图、帕累托图、因果分析图等）

谢谢！ Keep Connecting In The Future