第六章 项目的质量管理.ppt

1、第六章 项目的质量管理,6.1软件质量的度量 6.2 软件的确认 6.3 软件的验证 6.4 软件质量保证过程 6.5 软件质量保证体系,第六章 目录,6.1软件质量的度量 6.2 软件的确认 6.3 软件的验证 6.4 软件质量保证过程 6.5 软件质量保证体系 6.6 测试方法与工具介绍,第六章 目录,软件系统功能齐全是不是就是质量好？ 用户界面友好是不是就是软件的质量好？ 没有BUG是不是就是软件的质量好？ 什么是用户满意的软件项目？ 软件测试是不是软件质量的全部？那么，什么是软件的质量？,什么是软件项目的质量？,软件项目管理中的质量管理与软件工程的测试管理，有什么不同？ 项目经理与项目

2、QA经理有什么不同？ 什么是软件项目的质量管理？ 项目经理在保证项目的质量方面，要做什么工作？我们就来回答这些问题！,什么是软件项目的质量管理？,6.1软件质量的度量6.1.1 软件的质量要素 6.1.2 软件质量评价的准则 6.1.3 软件质量的度量 6.1.4 软件质量度量的实施,6.1.1 软件的质量要素,什么是软件的质量？ ISO9000的质量定义： 质量的定义：反映实体满足明确和隐含需要能力的特性综合 定义的说明： 明确需要：指合同中用户明确提出的要求与需要 隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要,质量与等级的关系,等级的含义是：对功能用途相同、但技术特性不同的

3、实体的一种分类或排序 例如：高质量无错误、可读性强的用户手册低等级有限的功能低质量错误百出、编排混乱的用户手册高等级大量功能 PMBOK强调质量的核心是产品、服务的适用性 什么是适用性？,质量的要素 讨论软件的质量定义，一般地从4个角度来看，即用户的角度、开发商的角度、产品的角度和价值的角度。美国的B.W.oehm和R.Brown 先后提出了三层次的评价度量模型：软件质量要素、准则、度量。 随后G.Mruine提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。IEE

4、E标准1061-1998以表格的形式，定义了有关确认和收集与软件质量需求有关一个模型，或称为一个框架。,6.1.2 IEEE定义的软件质量度量框架,IEEE定义的软件质量度量框架,质量需求 在四层模型的第一层，软件产品质量层，是产品必须满足的质量需求。它是用用户术语描述的，主要有四点： （1）产品将在用户所在组织当前使用的平台和操作系统上运行。 （2） 产品将是可靠的并能防止数据丢失的机制。 （3） 产品将提供完成某些任务所必需的功能。 （4） 产品将易于使用。 质量特性 在模型的第二层，表示与整个质量需求有关的特殊质量特性，它代表了用户的质量需求。它采用从用户角度考虑的立场，把软件质量分解成

5、四类质量特性，这四个质量特性是软件的基本特征。 IEEE的四个质量特性是： 可移植性、可靠性、功能性、可使用性。,四层模型,6.1.3 软件质量评价准则,McCall选择的软件质量要素评价准则共21种，它们是： （1）可审查性(auditability)。检查软件需求、规格说明、标准、过程、指令、代码与合同是否一致的难易程度。 （2）准确性(accuracy)。计算和控制的精度，是对无误差程序的一种定量估计。最好表示成相对误差的函数。值越大表示精度越高。 （3）通信通用性(communication commonality)。使用标准接口、协议、规范的程序。 （4）完全性 (completen

6、ess)。所需功能完全实现的程度。 （5）简明性(conciseness)。程序源代码的紧凑与简洁性。 （6）一致性(consistency)。设计文档与系统实现的一致性。 （7）数据通用性(data commonality)。在程序中使用标准的数据结构和类型。 （8）容错性(error-tolerance)。系统在各种异常条件下提供继续操作的能力。 （9）执行效率(execution Efficiency)。程序运行效率。 （10）可扩充性(expandability)。能够对结构设计、数据设计和过程设计进行扩充的程度。,6.1.3 软件质量评价准则,（11）通用性(generality)。

7、程序部件潜在的应用范围的广泛性，即部件可重用。 （12）硬件独立性(hardware independence)。软件同支持他运行的硬件系统不相关的程度。 （13）检测性(instrumentation)。监视程序的运行，一旦发生错误时，能明确地标识错误的程度。 （14）模块化(modularity)。程序部件的功能独立性。 （15）可操作性(operability)。操作一个软件的难易程度。 （16）安全性(security)。控制或保护程序和数据不受破坏的机制，以防止程序和数据受到意外的或蓄意的存取、使用、修改、毁坏或泄密。 （17）自文档化(sdlf-documentation)。源代码

8、提供有意义文档的程度。 （18）简单性(simplicity)。理解程序的难易程度。 （19）软件系统独立性(software system independence)。程序与非标准的程序设计语言特征、操作系统特征以及其他环境约束无关的程度。 （20）可追踪性(reacebility)。从设计表示或实际程序构件，追踪到需求的能力。 （21）易培训性(training)。软件支持新用户使用该系统的能力。,1985年，国际标准化组织（ISO）建议，软件质量度量模型由三层组成。高层称软件质量需求评价准则（SQRC），中层称软件质量设计评价准则（SQDC），低层称软件质量度量评价准则（SQMC）。分别

9、对应McCall等人的要素、评价准则和度量。ISO认为应对高层和中层建立国际标准，以便在国际范围内推广应用软件质量管理，而低层可由各使用单位自行制定。ISO高层由8个要素组成、中层由23个评价准则组成。 高层的8个要素为左表的行，中层的23个准则为下表的列。它们之间的关系如左表所示。,软件质量的另一种理解 ISO/IEC9126-1产品质量-质量模型的软件质量模型,内部质量的定义是： 反映软件产品在规定条件下使用时，满足需求的能力的特性，是软件开发过程中各阶段（需求开发、软件设计、代码编写等）产生的中间软件产品的质量。 了解软件产品的内部质量，可以预计最终产品的质量。 外部质量的定义是： 反映

10、软件产品在规定条件下使用时，满足需求的程度。 外部特性反映在预定的系统环境中运行时可达到的质量水平。,使用质量的定义是： 反映软件产品在规定的使用环境下，使特定用户在达到规定目标方面的能力。 反映的是从用户角度看到的软件产品在特定系统环境下满足其需求的满足程度。 对内部和外部质量特性的度量描述包括： 功能性、可靠性、易用性、效率、可维护性、可移植性等； 对使用质量特性的度量描述包括： 有效性、生产率、安全性、满意程度等,6.1.4 软件质量度量的实施,在确定要对一个软件（系统）进行度量之后，一般，采取以下5个步骤，来实施对该软件的度量： （1）确定软件质量需求； 在用户需求中，除功能需求外，还

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

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

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

14、，当这些假设并不成立时，度量的结果是不真实的。,其他度量,分析模型的度量（对分析模型的度量以测试系统的大小） 设计模型的度量（度量体系结构、数据和系统的复杂度） 源代码的度量（度量程序的长度、层次、开发量、时间等） 对测试的度量（度量测试的宽度、深度、错误的级别） 对维护的度量（度量软件的稳定性）,什么是系统集成项目的质量要素？ 如何度量和评价？ 如何管理与控制？,6.1软件质量的度量 6.2 软件的确认 6.3 软件的验证 6.4 软件质量保证过程 6.5 软件质量保证体系 6.6 测试方法与工具介绍,第六章 目录,6.2 软件确认6.2.1 测试阶段 6.2.2 测试方法 6.2.3 测试

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

16、发过程质量工作质量。验证活动也是围绕三个基本过程来进行，审查、度量和配置管理。,6.2.1 测试阶段,根据不同的软件生命周期定义，测试的阶段、方法和类型构成一个层次结构，如下图：,V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。,测试的V模式,单元测试,单元测试的内容主要是：算法逻辑、数据定义的理解和使用、接口、各种CASE路径、边界条件、错误处理等。单元测试的目的通常是:在开发环境中，程序设计工程师为了检查单元程序模块内部的逻辑、算法和数据处理结果的正确性等。单元测

17、试通常由负责编码的工程师自己在代码完成后测试，也有在项目组内，由工程师相互交叉测试。调试与测试的最大的不同点是二者的目的和视角的区别：调试包括查找BUG、定位BUG、修改并最终确认BUG已经被修复的软件故障排除过程。测试是在一个相对独立的环境下（测试应尽可能地模拟运行环境，调试是在开发环境），运行系统单元，观察和记录运行结果，对结果进行独立评价的过程。,单元测试（模块测试）,实际上，在单元测试级，一般项目组很难做到把调试与测试分开。因为二者的工作内容比较接近，担负人常常是一个人，环境区别并不大或者重新搭建环境在时间、成本和人力上，都比较困难。这些都是一般项目组并没有独立的单元测试的原因。将单元

18、测试与模块调试合并可能带来的问题是：（1）单元测试没有任何记录和文档。少有笔头勤快的工程师，会把他每天测了什么、改了什么，记录下来。软件工程师要的就是没有BUG的程序，任何中间结果都是垃圾。（2）由于调试的目标是获得没有故障的程序，因此，与功能无关的程序属性往往被忽略，或者要到集成测试、确认测试时才被发现。例如：命名标准、程序形式规范等。不论怎么说，现实情况，单元测试与模块调试经常是混为一谈的，要想改变，也不太容易。由于单元测试在项目组中，常常由编码工程师完成，项目经理的管理一般并不深入到单元测试层。,集成测试（子系统测试）,集成测试又称组装测试，它是在单元测试完成后，组装为一个子系统后，对下

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

20、组装。分阶段的增量组装测试，可以解决一次集成，问题的隔离和区分不易的困难。,确认测试（系统测试）,确认测试的目的是按照与用户确认的软件需求规格说明书的要求，检查系统的需求实现。确认需求的测试依据是需求阶段产生的测试脚本（测试用例）。国内项目组的现实情况有以下几种：（1）没有确认测试；（2）没有独立的确认测试，测试与设计、编码不分离；（3）有独立的确认测试，但测试用例是设计和编码人员写的，因此，独立测试人员相当于按设计和编码人员的设计思路再测一遍。上述这些情况，就丧失了确认测试的大部分意义。正确的确认测试是独立的测试组中，具有相应知识的测试设计师，根据需求规格说明书，并依据该软件在用户方面将会是

21、在什么环境下，用户将如何使用该软件，来设计测试方案和测试用例，安排测试人员进行测试。很显然，现实离理想的距离还比较遥远。确认测试还包括软件经修改后的再测试（回归测试）。回归测试是对已测试并发现故障的部分，修改后进行再测试。回归测试不应修改测试程序、测试内容或测试标准。它与正常测试不同的仅是：它可能并不需要再完整地走一遍所有的确认测试，而是小心地选择部分确认测试程序，选择的标准是不减低原标准的整体要求。,测试和测试,为了实际检验软件的功能和性能，有时，常邀请特定的用户帮助试用（测试）系统正式发布前的版本，请用户对系统进行评价。这就是通常所说的测试和测试。 测试是由一个用户在开发者的场所，在开发者

22、指导下进行的测试。开发者记录下问题和错误，是在开发者“控制”下的测试。 测试是用户的环境中，开发者可能并不在现场，由用户“活用”系统情况下的测试。用户记录下问题，报告给开发者。 在商用套装软件中，这种情况比较多见，在行业应用系统中，由于现实环境并不允许不成功的软件直接投入使用，用户也没有参与测试义务、时间和资源的投入和配合的积极性，因此，这种测试很少发生。,验收测试,在行业应用软件环境中，验收测试是项目过程非常重要的一环，也是项目经理非常关注的一项工作。 验收测试与确认测试非常相似，所不同的是，确认测试是项目组或组织内部的测试，验收测试是用户主导、现场参与、现场环境下的测试。 验收测试通常由项

23、目组先提出测试大纲，定义测试目的、范围、方法、测试用例、预期结果、验收标准等。经用户同意批准，可能包括用户的修改、增加后，确定测试时间，开始进入验收测试。 用户在完成按测试用例的测试后，在测试记录上逐条确认、签字，最后，在测试报告上签字，完成验收测试。 一般地、验收测试报告是项目初验、终验的依据和主要验收形式。,单元测试与验收测试,单元测试和验收测试没有什么区别？ 单元测试可以类比为一个建筑的质检人员对建筑进行的检测， 他关注的重点是建筑的内部结构、地基、框架以及墙壁是否垂直等。他的检测是要保证建筑的各个部分是正常的、安全的，换句话说，就是要保证施工满足建筑上面的质量标准。 验收测试可以类比为

24、建筑的使用者来对建筑进行的检测。他关心建筑的外观是否美观、各个房间的大小是否合适，窗户的位置是否合适，是否能够满足家庭的需要等。这里，建筑的使用者执行的就是验收测试，他是从用户的角度出发的。 正是这种角度的不同决定了单元测试和验收测试之间的区别。它们是对系统的不同的方面进行的测试，二者是互相补充的。不管我们在系统的构建中使用了多么聪明的方法，不管我们的系统是多么的灵活，但是首先我们的产品必须是可用的，否则我们所做的就是浪费时间，从这一点上来说验收测试要比单元测试显得更加重要。,6.2.2 测试方法,测试所处的阶段不同，方法也不同： 白盒测试在单元测试阶段，由于测试者对被测对象的内部结构、逻辑思

25、路、接口关系等比较熟悉，一般采取白盒测试的方法，它是根据模块的内部逻辑，进行测试设计的方法。有些集成测试也采用白盒方法，关键看集成阶段的划分。 黑盒测试在集成测试以至此后的各阶段，测试设计和测试人员，对被测对象的内部结构不了解也不需要了解，他的目的是按需求功能进行确认。因此，黑盒测试是严格按软件需求进行测试设计的方法。 代码走查,6.2.3 测试类型,在不同阶段，测试的类型也不相同，常有的测试类型是： （1）功能测试：软件实现的功能是否符合需求规格说明书中定义的功能； （2）性能测试：软件在规定配置下的性能是否符合需求规定； （3）算法测试：确认实现的算法的正确性； （4）正向测试：按照用户正

26、常的理解、操作方式、思维和使用习惯使用软件，得到的结果是否与需求一致。 （5）逆向测试：如果不按用户正常的理解、操作发生、思维和使用习惯使用软件，软件是否能正确地进行处理。如：无效操作、错误的数据输入处理、非法进入等。 （6）边界测试：按软件的限制、假设条件的边界输入，进行测试。 （7）配置测试：对软件环境进行配置变化，软件需求实现，特别是性能实现是否能符合需求规定要求。 （8）负载测试：在业务处理量、数据负载量、通讯负载量达到何种情况，系统的性能变化和承载能力情况。,6.2.4 测试计划,测试估计在拟定测试计划时，首先需要对以下情况，做出估计：（1） 完成测试设计所需要的工作量：（2） 完成

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

28、告中，应反映：（1）测试中出现问题的统计汇总和分析；（2）未解决问题的汇总和解决方案建议；（3）回归测试的统计和分析（度量） ；（4）对测试计划的总结或修改。,关于测试用例的问题讨论：测试用例由谁设计？设计测试用例的目的和依据是什么？,6.2.5 测试过程组织,一个独立的测试小组为例，测试过程一般如下： （1）测试准备：制定人员、环境、工具、培训和外部支持计划。 （2）测试计划：确定测试策略、建立测试计划。 （3）测试用例：建立测试顺序树、确定测试的优先级、详细列出测试程序和测试数据，设计测试用例。 （4）测试环境：了解需求、搭建环境、安装备份和恢复程序，记录初始环境、测试环境、恢复环境等。

29、（5）测试执行：从测试计划复审测试计划进度表、恢复测试执行环境。 （6）结果分析：执行结果分析、度量。 （7）测试报告：错误趋势图、测试变动指示、产品检查点建议。,6.1软件质量的度量 6.2 软件的确认 6.3 软件的验证 6.4 软件质量保证过程 6.5 软件质量保证体系 6.6 测试方法与工具介绍,第六章 目录,6.3 软件的验证6.3.1 审查准备 6.3.2 审查过程 6.3.3 需求审查 6.3.4 设计审查 6.3.5 代码审查 6.3.6 测试审查,软件审查的概念,回顾：我们在上节介绍软件的确认和验证过程时，已经介绍了软件验证的三个过程是：审查、测量和配置管理。同时，我们也谈到

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

31、,6.3.1 软件审查的准备,评审人：审查一般由一个审查小组或审查委员会负责进行，审查小组内，应有以下角色构成：（1）主持审查活动的主审员；（2）被审查产品的负责人，包括产品经理、技术经理、质量经理等；（3）负责对被审查产品进行讲解和解释的主讲人；（4）来自各有关部门的审查员；（5）记录员；（6） 项目经理项目经理应该参与软件的审查过程，关注审查结果，但不一定要参加审查会议。这要看审查的级别。如果是组织内的项目级审查，项目经理作为被审查产品的负责人，应参加审查会议，否则，应该由具体的产品、技术或质量经理去参加这样的会议。被审产品的负责人参加这样的会议，不是为了解释审查中发现的缺陷，及其责任，进

32、行辩解，而只是如实地向审查小组介绍产品为什么要这样做，和做了什么。审查的目的不是为了追究什么人的责任，而是为了改进过程。如果把评审，引入到人与人之间的斗争中去，则完全丧失了评审，作为过程改进手段的意义。,评审内容及要求，见下表：,系统确认及回归测试已经完成,审查员的职责作为被审查对象的项目组，按照审查组的要求，提交被审查材料，接受审查。 作为审查员，应该做什么准备？ 首先，明确作为审查员的定角色位、职责。 审查员是那些具有相关知识和对被审查产品具有一定熟悉程度的，但不一定就是直接从事相同岗位（有时，还特别需要交叉换位）的人员。在参加审查前，他必须花一定的时间和精力，来了解产品，并能通过阅读提交

33、的资料，了解产品与文档、标准和规范之间的差异。 因此，他在审查中的责任是： （1）必须完全熟悉要审查的产品和产品所依据的文档和标准； （2）对照产品和文档，鉴别其中的差异； （3）客观地评价差异，识别是属于实现的程度差别、缺陷，还是错误； （4）判断差异是实现的个体现象，还是过程问题； （5）以对产品而不是对人的态度，对差异进行评估和分析； （6）向主审员报告审查结果和分析意见。,在审查开始之前，审查组与被审查项目的有关人员，产品经理、技术经理、质量经理和项目经理们开一个“审查开工会”，主审员向被审查对象的有关人员介绍本次审查的目的、对象、范围和内容，有必要的话，花一点时间介绍一下审查方法，使

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

35、2 软件审查的过程,在审查汇报会上，审查员汇报分组审查中发现的潜在的（还没有定论）的错误、缺陷和差异。审查小组对每一个问题进行讨论，并争取获得一致的意见。必要时，可以请项目组再做解释。记录员此时应详细记录讨论的过程和各自的意见，并确保这些记录的完整性、正确性和真实性。如果一次会议不能解决争论的问题，或者需要再扩大参加人员的范围，或者需要再做测试，那就那样去做。或者审查组发现问题已经非常严重，已经超出了软件评审的范围，那么，应立即停止评审，向有关上级报告问题，以便上级做出重大改进的措施。审查结果的发布是一个非技术的敏感问题。什么性质的结果可以发布，在多大范围内发布。审查结果如果比较满意，它的发布

36、将对项目组是一个正向的激励，是相关人员能力的象征。负面的审查结果可能引来更大的争议和动荡。因此，审查小组和项目经理，要充分沟通，从积极的方面，使用审查结果。任何审查结果都不是针对个人的，但是任何工作都是由具体个人来负责和承担相应责任的。因此，审查结果的难处，就在这句话的二面性。,6.3.3 需求审查,需求审查表（问题清单） （1） 需求是否定义了要向用户展示的全部信息？ （2） 需求是否论述了系统对用户错误操作的反映？ （3） 每一需求项的描述是否清楚、简洁和没有二意性？ （4） 每一项需求是否都是可测试的？ （5） 需求是否有隐含或暗示的功能理解？ （6） 需求项之间是否有自相矛盾的地方？

37、（7） 需求是否有应该论述但没有提及的地方？ （8） 需求对实时性、精确度、负载能力等有没有定义？ （9） 需求是否包括了性能需求、质量需求等非功能需求？ （10） 如果需求涉及复杂的关联关系、复杂的算法、复杂的决策 机制，用户能完全理解吗？ （11） 需求对软件升级、版本变更是否有明确的承诺？ （12） 需求文档是否含有不必要的设计细节？ （13） 是否可以根据需求，开发出适当的和完整的测试用例集？ （14） 需求的假设和限制条件是否明确？,6.3.3 需求审查,需求审查过程我们在上一节，已经一般地讨论过审查的过程。需求审查也遵循这样的过程：组织审查组；收集项目组提交的被审查资料；确定审查日

38、期；审查员在获得审查任务分配和开始工作，包括：对资料的阅读和评审、做实地的检查、调查和询问、记录并报告；参加评审会议并报告自己的发现和分析。审查小组首先检查审查活动是否充分和没有偏差、疏漏。审查员对问题的认识有没有片面和主观。主审员根据自己的经验，可能会对年轻的审查员要求做出补充调查。通过讨论，审查小组争取对问题取得一致的意见，并形成审查报告。追踪与改正审查的目的是监督项目组对软件的品质，保持良好的状态和不断地改进。因此，审查小组有责任跟踪项目组对审查结果的利用情况。关注项目组的改进，是项目经理比关注审查结果更重要的事情。,6.3.4 设计审查,概要设计审查表（问题清单）详细设计审查表（问题清

39、单）设计审查的目标：概要设计重点审查以下几个方面（概要设计针对需求）（1）概要设计对需求的完整实现； （2）概要设计与需求的一致性；（3）概要设计向需求的反向可追踪；（4）概要设计中，对系统结构设计的逻辑性、合理性和可扩展性；由于概要设计是直接衔接需求的，因此，概要设计审查更多地是把设计与需求相衔接。,在详细设计中，应重点审查以下方面（详细设计针对实现）（1）设计应符合组织即定的标准；（2）设计结果对下一阶段的编码是可用的。由于详细设计直接提供编码实现，因此，在组织内，应对详细设计的“粒度”做出规定。这样，即明确详细设计与代码实现的界面，同时，也是编码标准化的工作基础。在这方面，应结合实际，进

40、行研究。,6.3.4 设计审查,6.3.5 代码审查,代码的审查与具体实现工具有关，而且与具体实现工具的版本有关，因此，我们在这里就不具体讨论代码审查的内容。有不少文章具体讨论代码的标准化和设计技巧，可以作为审查的范本（如果必要的话）。代码审查的一个办法是走查。就是由审查人员“读”工程师写的代码，然后对照“标准”进行检查，是对软件文档的一种书面检查。它通过人工模拟执行源程序的过程，检查软件设计的正确性。人工模拟也像计算机执行那样，可以仔细推敲、校验和核实每一步的执行结果，进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性。走查是一件非常艰苦的工作，同时是需要非常大的毅力和记忆力的工作。

41、因为一个系统程序量之大，组织的规则和要求之多。审查员要做的是N的N次方的核对。现在也有一些计算机程序，按一定的规则，帮助审查员“读”程序，并挑出（有的可以做简单的修改）毛病，VB就有这样的程序。如果没有计算机程序的帮助，审查员会“疯”掉的。,6.3.6 测试审查,测试审查是对测试结果进行审查，它审查的内容包括（1）对测试用例的审查：测试用例的哪些要素（用例名、测试日期、预期测试结果等）是否齐备？（宽度）（2）在概要设计和详细设计中确定的关键点或特殊需求是否都测试到了？（深度）（3）测试过程（步骤、环境、用户模拟等）的设计是否正确、恰当？（4）预期值与结果值的差异统计；（5）测试目的是否达到？,

42、6.1软件质量的度量 6.2 软件的确认 6.3 软件的验证 6.4 软件质量保证过程 6.5 软件质量保证体系 6.6 测试方法与工具介绍,第六章 目录,6.4 软件质量保证过程6.4.1 现代质量管理回顾 6.4.2 ISO9000质量管理体系 6.4.3 PMBOK的质量管理 6.4.4 CMM2的质量保证,6.4.1 现代质量管理回顾,现代质量管理是对项目管理的补充 现代质量管理在以下方面，做出更多的强调：（1） 以客户满意为质量目标；（2） 比注重结果更多地注重过程；（3） 管理层对质量负有责任。这些观点，是以下这些质量管理大师和前辈，在逐步总结质量管理经验的基础上，建立起来的。,I

43、SO9000质量管理体系,什么是质量认证 质量认证也叫合格评定，是国际上通行的管理产质量的有效方法。质量认证按认证的对象分为产质量认证和质量体系认证两类；按认证的作用可分为安全认证和合格认证。 什么是产品质量认证 产品质量认证是指依据产品标准和相应技术要求，经认证机构确认并通过颁发认证证书和认证标志来证明某一产品符合相应标准和相应技术要求的活动。 什么是质量体系认证 质量体系认证的对象是企业的质量体系，或者说是企业的质量保证能力。,ISO9000质量管理体系,质量体系文件的层次 第一层：质量手册 第二层：程序文件 第三层：作业指导书 管理性第三层文件（如：车间管理办法、仓库管理办法、文件和资料

44、编写导则、产品标识细则等） 技术性第三层文件（如：产品标准、原材料标准、技术图纸、工序作业指导书、工艺卡、设备操作规程、抽样标准、检验规程等）第四层 表格与（质量）记录。,ISO9000质量管理体系,质量体系文件的作用 1. 质量体系文件确定了职责的分配和活动的程序，是企业内部的“法规”。2. 质量体系文件是企业开展内部培训的依据。3. 质量体系文件是质量审核的依据。 4. 质量体系文件使质量改进有章可循。ISO9000质量管理的8项原则： 原则1： 以顾客为中心 原则2： 领导作用 原则3： 全员参与 原则4： 过程方法 原则5： 管理的系统方法 原则6： 持续改进 原则7： 基于事实的决策

45、方法 原则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：由上级管理部门及时处理软件项目内部

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

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

48、者使用价值上，也即项目的产品质量。 从项目作为一次性的活动来看，项目管理质量体现在由WBS反映出的项目范围内所有的阶段、子项目、项目工作单元的质量所构成，也即项目的工作质量；项目是应业主的要求进行的,不同的业主有着不同的产品质量要求，其意图已反映在项目合同中。因此，项目合同是进行项目产品质量管理的主要依据。 PMBOK的项目质量管理是： 在质量体系中，决定质量工作的策略、目标和责任的全部管理功能有关的所有活动，并通过诸如质量计划、质量保证和质量提高等手段来完成这些活动。,PMBOK的质量管理过程,PMBOK的质量管理过程是： 质量计划-确定哪些质量标准适用于该项目，并决定如何达标。 质量保证-

49、在常规基础上对整个项目执行情况作评估，以提供信用，保证该项目将能够达到有关质量标准。 质量控制-监控特定项目的执行结果，以确定它们是否符合有关的质量标准，并确定适当方式消除导致项目绩效令人不满意的原因。 这些工作程序互有影响，并且与其它知识领域中的程序之间也存在相互影响。依据项目的需要，每道程序都可能包含一个或更多的个人或由团队的努力。在每个项目阶段中，每道程序通常都会至少经历一次。,PMBOK的项目质量管理过程一质量计划,质量计划的目的是： 确定哪些质量标准与项目有关 及如何达到这些质量标准 质量计划回答： 质量管理的目标要素是什么？如何产生和确定这些要素的？ 如何度量、评价这些要素，并证实

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