质量管理计划-Read课件

6.1软件质量的度量6.2软件的确认6.3软件的验证6.4PMBOK的质量管理过程第六章6.1软件质量的度量第六章16.1软件质量的度量6.1.1软件的质量要素6.1.2软件质量评价的准则6.1.3软件质量的度量6.1.4软件质量度量的实施6.1软件质量的度量2质量与等级的关系等级的含义是：对功能用途相同、但技术特性不同的实体的一种分类或排序例如：高质量——无错误、可读性强的用户手册低等级——有限的功能低质量——错误百出、编排混乱的用户手册高等级——大量功能PMBOK强调质量的核心是产品、服务的适用性什么是适用性？质量与等级的关系等级的含义是：对功能用途相同、但技术特性不同36.1.2IEEE定义的软件质量度量框架6.1.2IEEE定义的软件质量度量框架4度量框架一种用来组织、选择、沟通、评价软件系统要求的质量属性的辅助决策法。它逐层分解为特性、子特性和度量质量特性一个与质量有关的面向管理的软件属性质量子特性质量特性分解出来的技术组件直接度量一种不依赖与任何其他属性测量的度量预计度量一种试用于开发阶段的度量，它用来预计软件质量特性的值软件质量度量一个函数、它的输入是软件数据，输出是一个单一数值。它可解释为给定的软件属性对其质量的影响程度过程质量一种用来测量在软件系统开发、实现和维护过程中使用的方法、技术和工具特性的度量产品度量一种用来测量软件开发过程中任何中间或最终产品特性的度量

IEEE定义的软件质量度量框架度量框架一种用来组织、选择、沟通、评价软件系统要求的质量属性5质量需求

在四层模型的第一层，软件产品质量层，是产品必须满足的质量需求。它是用用户术语描述的，主要有四点：

（1）产品将在用户所在组织当前使用的平台和操作系统上运行。

（2）

产品将是可靠的并能防止数据丢失的机制。

（3）

产品将提供完成某些任务所必需的功能。

（4）

产品将易于使用。质量特性

在模型的第二层，表示与整个质量需求有关的特殊质量特性，它代表了用户的质量需求。它采用从用户角度考虑的立场，把软件质量分解成四类质量特性，这四个质量特性是软件的基本特征。

IEEE的四个质量特性是：

可移植性、可靠性、功能性、可使用性。

质量需求

在四层模型的第一层，软件产品质量层，是产品必6软件质量的另一种理解ISO/IEC9126-1《产品质量-质量模型》的软件质量模型软件质量的另一种理解7内部质量的定义是：反映软件产品在规定条件下使用时，满足需求的能力的特性，是软件开发过程中各阶段（需求开发、软件设计、代码编写等）产生的中间软件产品的质量。了解软件产品的内部质量，可以预计最终产品的质量。外部质量的定义是：反映软件产品在规定条件下使用时，满足需求的程度。外部特性反映在预定的系统环境中运行时可达到的质量水平。质量管理计划-Read课件8使用质量的定义是：反映软件产品在规定的使用环境下，使特定用户在达到规定目标方面的能力。反映的是从用户角度看到的软件产品在特定系统环境下满足其需求的满足程度。对内部和外部质量特性的度量描述包括：功能性、可靠性、易用性、效率、可维护性、可移植性等；对使用质量特性的度量描述包括：有效性、生产率、安全性、满意程度等质量管理计划-Read课件96.1.4软件质量度量的实施在确定要对一个软件（系统）进行度量之后，一般，采取以下5个步骤，来实施对该软件的度量：（1）确定软件质量需求；在用户需求中，除功能需求外，还有非功能需求，包括：质量需求、环境需求、设计约束、开发策略等。质量需求是用户比较关心的内容。但是，我们已经知道，软件的功能需求的确定，存在一定的难度。而非功能需求的确定，则难度更大。这些困难包括：需求如何获取，需求冲突如何协调、需求的确认和变更的授权等。过程：需求获取：首先，你要理解用户的需求，区分哪些是质量需求，把这些需求记录下来，获得用户的确认。需求分析：拿到用户确认的需求后，你可以开始把用户的质量需求与我们设定的质量特性联系起来，一直区分到子特性。这种联系，就是把用户语言描述的需求，转变为计算机工程师语言的需求。建立了这种关联后，可以根据分类，分级，确定直接度量。

6.1.4软件质量度量的实施在确定要对一个软件（系统）进行106.1.4软件质量度量的实施

（2）确定直接度量

直接度量就是实际的软件质量测量活动，它的输入是软件或软件过程，输出是一个测量值。它通过执行一系列的任务，获得一个质量值。

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

（3）分析度量结果

对度量过程进行跟踪和分析，需要时，可能会对度量程序、度量工具、度量方法，甚至原始数据，做出补充和调整。（4）确认质量度量

在度量过程中，进行度量结果的确认非常重要。首先，要确认度量过程是否与事实相符，脱离现实真实的度量，与目标再相符的结果也是没有意义的。其次，是确认方法的有效性，例如：在度量中，我们用到很多统计学方法，在这些方法中，我们有一些概率分布假设（例如：某些错误的发生，我们假设符合随机概率分布），当这些假设并不成立时，度量的结果是不真实的。6.1.4软件质量度量的实施 （3）分析度量结果12其他度量分析模型的度量（对分析模型的度量以测试系统的大小）设计模型的度量（度量体系结构、数据和系统的复杂度）源代码的度量（度量程序的长度、层次、开发量、时间等）对测试的度量（度量测试的宽度、深度、错误的级别）对维护的度量（度量软件的稳定性）

其他度量分析模型的度量（对分析模型的度量以测试系统的大小）136.2软件确认6.2.1测试阶段6.2.2测试方法6.2.3测试类型6.2.4测试计划6.2软件确认146.2.1测试阶段根据不同的软件生命周期定义，测试的阶段、方法和类型构成一个层次结构，如下图：6.2.1测试阶段根据不同的软件生命周期定义，测试的阶段、15V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

测试的V模式V模型中的过程从左到右，描述了基本的开发过程和测试行166.2.2测试方法测试所处的阶段不同，方法也不同：白盒测试 在单元测试阶段，由于测试者对被测对象的内部结构、逻辑思路、接口关系等比较熟悉，一般采取白盒测试的方法，它是根据模块的内部逻辑，进行测试设计的方法。有些集成测试也采用白盒方法，关键看集成阶段的划分。黑盒测试 在集成测试以至此后的各阶段，测试设计和测试人员，对被测对象的内部结构不了解也不需要了解，他的目的是按需求功能进行确认。因此，黑盒测试是严格按软件需求进行测试设计的方法。代码走查6.2.2测试方法测试所处的阶段不同，方法也不同：176.2.3测试类型在不同阶段，测试的类型也不相同，常有的测试类型是：（1）功能测试：软件实现的功能是否符合需求规格说明书中定义的功能；（2）性能测试：软件在规定配置下的性能是否符合需求规定；（3）算法测试：确认实现的算法的正确性；（4）正向测试：按照用户正常的理解、操作方式、思维和使用习惯使用软件，得到的结果是否与需求一致。（5）逆向测试：如果不按用户正常的理解、操作发生、思维和使用习惯使用软件，软件是否能正确地进行处理。如：无效操作、错误的数据输入处理、非法进入等。（6）边界测试：按软件的限制、假设条件的边界输入，进行测试。（7）配置测试：对软件环境进行配置变化，软件需求实现，特别是性能实现是否能符合需求规定要求。（8）负载测试：在业务处理量、数据负载量、通讯负载量达到何种情况，系统的性能变化和承载能力情况。6.2.3测试类型在不同阶段，测试的类型也不相同，常有的测186.2.4测试计划测试估计

在拟定测试计划时，首先需要对以下情况，做出估计： （1）

完成测试设计所需要的工作量： （2）

完成测试设计所需要的工作时间： （3）

完成测试所需要的时间：

根据以上三个部分的结果，我们已经知道了测试的范围、内容、任务分配、时间等，这样，项目经理可以能比较充分地规划资源，制订出一份比较全面和切实的测试工作计划。测试分配

测试计划确定了测试的范围、内容和估计时间，根据WBS方法，测试计划还应说明具体测试任务的分解和测试工作的分配。测试组的成员根据分工，各自完成一部分测试任务。测试组与项目开发组还需要保持一定的同步，使测试与开发、修改在协调的步骤下进行，以节约宝贵的项目总时间。测试确认

6.2.4测试计划测试估计19测试报告：收集齐上述的所有测试用例，构成了测试报告的基本要件。测试报告是对所有测试用例测试过程的总结。在测试报告中，应反映：（1）测试中出现问题的统计汇总和分析；（2）未解决问题的汇总和解决方案建议；（3）回归测试的统计和分析（度量）；（4）对测试计划的总结或修改。关于测试用例的问题讨论：测试用例由谁设计？设计测试用例的目的和依据是什么？测试报告：关于测试用例的问题讨论：206.3软件的验证6.3.1审查准备6.3.2审查过程6.3.3需求审查6.3.4设计审查6.3.5代码审查6.3.6测试审查6.3软件的验证21软件审查的概念验证与确认的区别是，确认是在整个软件系统完成交付前或某模块完成交付前的检查，它的检查点是交付前。而验证贯穿于整个开发过程，是对过程的确认。因此，验证的范围包括了整个开发过程，它是软件质量保证并持续改进的强大工具。审查是一个正式的、严格的、具有深度的技术评审过程。因此，评审的目的是：（1）在软件开发过程中，尽早可能地发现问题，特别是过程性的问题；（2）确保对需求保持一致的意见；（3）验证任何修改和变更满足预先定义的准则；（4）为组织提供产品在质量和过程方面是否有效的实际数据；（5）使团队成员之间在技术上建立相互的了解；（6）增加软件确认测试的有效性；（7）提高优秀软件工程师的水准。 软件审查的概念验证与确认的区别是，确认是在整个软件系统完成交22

评审内容及要求，见下表：审查类型被审查项需提交的资料提交审查条件需求软件需求规格说明书软件需求规格说明书及在此之前有关的需求分析文档、需求基线及批准文档确认的需求、已经被分析和形式化描述，需求基线已经被确定

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

系统确认及回归测试已经完成6.3.1软件审查的准备 评审内容及要求，见下表：审查类型被审查项需提交的资料提交审23

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

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

在审查汇报会上，审查员汇报分组审查中发现的潜在的256.3.3需求审查需求审查表（问题清单）

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

266.3.3需求审查需求审查过程我们在上一节，已经一般地讨论过审查的过程。需求审查也遵循这样的过程：组织审查组；收集项目组提交的被审查资料；确定审查日期；审查员在获得审查任务分配和开始工作，包括：对资料的阅读和评审、做实地的检查、调查和询问、记录并报告；参加评审会议并报告自己的发现和分析。审查小组首先检查审查活动是否充分和没有偏差、疏漏。审查员对问题的认识有没有片面和主观。主审员根据自己的经验，可能会对年轻的审查员要求做出补充调查。通过讨论，审查小组争取对问题取得一致的意见，并形成审查报告。

追踪与改正审查的目的是监督项目组对软件的品质，保持良好的状态和不断地改进。因此，审查小组有责任跟踪项目组对审查结果的利用情况。关注项目组的改进，是项目经理比关注审查结果更重要的事情。6.3.3需求审查需求审查过程276.4PMBOK的质量管理过程

项目的质量的二层含义从项目作为一项最终产品来看，项目质量体现在其性能或者使用价值上，也即项目的产品质量。从项目作为一次性的活动来看，项目管理质量体现在由WBS反映出的项目范围内所有的阶段、子项目、项目工作单元的质量所构成，也即项目的工作质量；项目是应业主的要求进行的,不同的业主有着不同的产品质量要求，其意图已反映在项目合同中。因此，项目合同是进行项目产品质量管理的主要依据。PMBOK的项目质量管理是：在质量体系中，决定质量工作的策略、目标和责任的全部管理功能有关的所有活动，并通过诸如质量计划、质量保证和质量提高等手段来完成这些活动。6.4PMBOK的质量管理过程项目的质量的二层含义28PMBOK的质量管理过程PMBOK的质量管理过程是：质量计划--确定哪些质量标准适用于该项目，并决定如何达标。质量保证--在常规基础上对整个项目执行情况作评估，以提供信用，保证该项目将能够达到有关质量标准。质量控制--监控特定项目的执行结果，以确定它们是否符合有关的质量标准，并确定适当方式消除导致项目绩效令人不满意的原因。这些工作程序互有影响，并且与其它知识领域中的程序之间也存在相互影响。依据项目的需要，每道程序都可能包含一个或更多的个人或由团队的努力。在每个项目阶段中，每道程序通常都会至少经历一次。PMBOK的质量管理过程PMBOK的质量管理过程是：29PMBOK的项目质量管理过程一——质量计划质量计划的目的是：确定哪些质量标准与项目有关及如何达到这些质量标准质量计划回答：质量管理的目标要素是什么？如何产生和确定这些要素的？如何度量、评价这些要素，并证实已经达到了这些要素的要求衡量质量的二个重要指标：可靠性、可维护性对产品和服务进行细致的质量计划，可提高产品或服务的可靠性与可维护性PMBOK的项目质量管理过程一——质量计划质量计划的目的是：30质量计划过程的输入质量方针：质量方针是对项目的质量目标和方向所作出的一个指导性文件，因此项目管理工作组应制定自己的质量工作方针，同时项目的质量方针应与项目的投资者完全共享。范围陈述：项目的范围陈述说明了投资者的需求以及项目的主要要求和目标，因此范围陈述是项目质量计划确定的主要依据和基础。产品描述：尽管产品描述的相关要素可能在范围描述中予以强调，然而产品的描述通常包含更加详细的技术要求和其它的内容，它对于项目质量计划的制定非常有用。标准和规则：项目质量计划的制定必须考虑到任何实际应用领域的特殊的标准和规则，这些都将影响项目质量计划的制定。其它工作的输出：除了上述范围陈述、产品描述之外，其他方面的工作输出也会对项目计划的制定产生影响，比如说采购计划就要说明承包人的质量要求从而影响到项目质量管理的计划。质量成本：质量成本是指为了达到产品/服务的质量标准而进行的全部工作所发生的所有成本。包括一致成本和不一致成本，后者又包括预防、鉴定和故障成本。质量计划过程的输入质量方针：质量方针是对项目的质量目标和方向31质量成本质量成本包括：一致成本：计划编制、培训辅导、过程控制、实地测量、设计确认、过程确认、测量评价、质量审计、维护校准不一致成本：废料、返工、加速处理、额外材料或存货、现场维修、保修服务、投诉处理、责任判定、产品取消、改正措施质量成本又可以分为：P成本、A、F成本，如下表：预防成本（P-成本Preventive）培训、过程能力研究、卖主/供应商调查评估成本（A成本-Appraisal）检查和测试、检查和测试设备维护、处理并报告检查数据的成本、设计审查、内部设计审查、走查、费用审查缺陷成本（F成本-Failure）内部缺陷成本废料与返工、与推迟付款有关的费用、缺陷存货成本、工程变动成本、设计错误纠正、纠正文档外部缺陷成本担保费用、现场服务人员培训、产品责任诉讼、投诉处理、未来经营损失质量成本质量成本包括：预防成本（P-成本Preventiv32质量计划制定的方法和技术

利益/成本分析：质量计划必须综合考虑利益/成本的交换，满足质量需求的主要利益是减少重复性工作，这就意味着高的产出、低的支出及增加投资者的满意度。满足质量要求的基本费用是辅助项目质量管理活动的付出，其基本原则是利益与成本之比尽可能的大。基准：基准主要是通过比较实际或计划项目的实施与其它同类项目的实施过程，为改进项目实施过程提供思路和提供一个实施的标准。流程图： ——原因结果（鱼刺）图： ——系统流程图:试验设计：试验设计对于分析辨明对整个项目输出结果最有影响的因素是很为有效的，但该方法的应用存在着费用进度交换的问题。质量计划制定的方法和技术利益/成本分析：质量计划必须综合考33因果（鱼刺）图：主要用来分析和说明各种因素和原因是如何导致或者产生主要问题和后果的。特点：用图表形式表示各因素之间的关系是头脑风暴、过程考察等分析活动的常用工具有利于刺激思考、、组织思路因果（鱼刺）图：34系统流程图系统流程图:主要用来说明系统各种要素之间存在的相互关系，通过流程图可以帮助项目组提出解决质量问题的相关方法。系统流程图系统流程图:35质量计划过程的输出质量管理计划：质量管理计划主要描述项目管理组应该如何实施它的质量方针。具体操作说明：对于一些特殊条款需要附加的操作说明，包括对他们的解释及在质量控制过程中如何度量的问题。比如说满足项目进度日期不能足以说是对项目管理质量的度量，项目管理组还必须指出每一项工作是否按时开始或者按时结束，各个独立的工作是否被度量或者仅是做了一定的说明等类似情况。检查表格：检查表格是一种用于对项目执行情况进行分析的工具，其可能是简单的也可能是复杂的，通常的描述包括命令和询问两种形式。许多组织已经形成了标准的确保频繁执行的工作顺利执行的体系。其它过程的输入：质量计划过程也有助于对其它领域工作的开展。质量计划过程的输出质量管理计划：质量管理计划主要描述项目管理36PMBOK的项目质量管理过程二——质量保证

质量保证是在质量体系中实施的全部有计划、有系统的活动，它用来树立满足项目相关标准的信心。质量保证是所有计划和系统工作实施达到质量计划要求的基础，为项目质量系统的正常运转提供可靠的保证，它应该贯穿于项目实施的全过程之中。在ISO9000系列实施之前，质量保证通常被描述在质量计划之中。检查表质量保证通常是由质量保证部门或者类似的组织单元提供，但是不必总是如此。质量保证通常提供给项目管理组以及实施组织（内部质量保证）或者提供给客户或项目工作涉及的其它活动（外部质量保证）。PMBOK的项目质量管理过程二——质量保证质量保证是在质量37质量保证过程的输入质量管理计划质量控制度量的结果：质量控制度量是为了比较和分析所作的质量控制测试的记录和度量。操作说明质量保证过程的输入质量管理计划38质量保证的工具和方法质量计划编制的工具和技术（计划编制中已经介绍）质量审核：质量审核是确定质量活动及其有关结果是否符合计划安排，以及这些安排是否有效贯彻。通过审核： ——保证项目质量符合规定要求； ——保证设计、实施与组织过程符合规定要求； ——保证质量体系有效运行并不断完善，提高质量管理水平。质量审核的分类包括: ——质量体系审核 ——项目质量审核 ——过程（工序）质量审核——监督审核 ——内部质量审核——外部质量审核质量审核可以是有计划的，也可以是随机的，它可以由专门的审计员或者是第三方质量系统注册组织审核。质量保证的工具和方法质量计划编制的工具和技术（计划编制中已经39质量保证过程的输出质量改进：质量改进包括达到以下目的的各种行动：增加项目有效性和效率以提高项目投资者的利益。在大多数情况下，质量改进将要求改变不正确的行动以及克服这种不正确行动的过程。质量保证过程的输出质量改进：40PMBOK项目质量管理过程三——项目质量控制质量控制主要是监督项目的实施结果，将项目的结果与事先制定的质量标准进行比较，找出其存在的差距，并分析形成这一差距的原因，质量控制同样贯穿于项目实施的全过程。项目的结果包括产品结果（如交付）以及管理结果（如实施的费用和进度）。质量控制通常是由质量控制部门或类似的质量组织单元实施，但是也并非总是如此。项目管理组应该具有统计质量控制的工作知识，特别是抽样检查和概率方面的知识，以便帮助他们评价质量控制的输出。他们应该清楚以下几个方面的不同： ——预防和检查——特征样本和随机样本 ——特殊原因和随机原因——偏差和控制线PMBOK项目质量管理过程三——项目质量控制质量控制主要是监41质量控制过程的输入工作结果：包括实施结果和产品结果质量管理计划操作规范检查表格质量控制过程的输入工作结果：包括