第六章项目的质量管理

第六章项目的质量管理

第六章 • 目录 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.1软件质量的度量 6.1.1 软件的质量要素 6.1.2 软件质量评价的准则 6.1.3 软件质量的度量 6.1.4 软件质量度量的实施

6.1.1 软件的质量要素 • 什么是软件的质量？ • ISO9000的质量定义： • 质量的定义：反映实体满足明确和隐含需要能力的特性综合 • 定义的说明： • 明确需要：指合同中用户明确提出的要求与需要 • 隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要

质量与等级的关系 • 等级的含义是：对功能用途相同、但技术特性不同的实体的一种分类或排序 • 例如：高质量——无错误、可读性强的用户手册低等级——有限的功能低质量——错误百出、编排混乱的用户手册高等级——大量功能 • 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）数据通用性(datacommonality)。在程序中使用标准的数据结构和类型。（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个评价准则组成。1985年，国际标准化组织（ISO）建议，软件质量度量模型由三层组成。高层称软件质量需求评价准则（SQRC），中层称软件质量设计评价准则（SQDC），低层称软件质量度量评价准则（SQMC）。分别对应McCall等人的要素、评价准则和度量。ISO认为应对高层和中层建立国际标准，以便在国际范围内推广应用软件质量管理，而低层可由各使用单位自行制定。ISO高层由8个要素组成、中层由23个评价准则组成。高层的8个要素为左表的行，中层的23个准则为下表的列。它们之间的关系如左表所示。

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

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

使用质量的定义是： • 反映软件产品在规定的使用环境下，使特定用户在达到规定目标方面的能力。 • 反映的是从用户角度看到的软件产品在特定系统环境下满足其需求的满足程度。 • 对内部和外部质量特性的度量描述包括： • 功能性、可靠性、易用性、效率、可维护性、可移植性等； • 对使用质量特性的度量描述包括： • 有效性、生产率、安全性、满意程度等

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

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

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

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

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

6.2 软件确认 6.2.1 测试阶段 6.2.2 测试方法 6.2.3 测试类型 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.3 软件的验证 6.3.1 审查准备 6.3.2 审查过程 6.3.3 需求审查 6.3.4 设计审查 6.3.5 代码审查 6.3.6 测试审查

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

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

审查类型 被审查项需提交的资料提交审查条件需求软件需求规格说明书软件需求规格说明书及在此之前有关的需求分析文档、需求基线及批准文档确认的需求、已经被分析和形式化描述，需求基线已经被确定设计软件设计说明软件设计文档设计完成编码源代码模块源程序代码、设计文档、组织的编码标准与规范被审查模块已经编译正确并完成独立测试确认测试测试记录测试结果报告、质量和验收标准评审内容及要求，见下表：系统确认及回归测试已经完成

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

第六章 项目的质量管理