软件工程7-资料教学课件

《现代软件工程》第七部分现代软件工程的质量保证

《现代软件工程》本部分主要参考书《软件验证与确认的最佳管理方法》（美）StevenR.Rakitin著于秀山等译（电子工业出版社）2019《测试流程管理》（美）RexBlack著（北京大学出版社）2019《软件工程与软件测试自动化教程》张克东、庄燕滨（电子工业出版社）《软件工程规范》（美）Watts.S.Humphrey著，傅为、苏俊、许青松译（清华大学出版社）2019《软件配置管理策略与RationalClearCase》（美）BrianA.White著尤克滨等译（人民邮电出版社）2019现代软件工程的质量保证过程-1软件测试的组织与管理-2软件系统的可靠性工程-3配置管理方法与实践-4第七部分现代软件工程的质量保证第一章现代软件工程的质量保证过程

软件的质量要素与度量-1.1软件工程的质量保证过程-1.2软件工程的质量保证活动-1.3软件质量保证体系建设-1.4

第七部分现代软件工程的质量保证如何描述质量用人的健康做类比如何判断人是否健康？体检因素：身高、体重、心跳、血压、血液、体温等如何描述软件的质量软件系统功能齐全是不是就是质量好？用户界面友好是不是就是软件的质量好？没有BUG是不是就是软件的质量好？用户满意？运行正确的软件就是高质量的软件吗？不贪污的官就是好官吗？软件测试是不是软件质量的全部？回答全部是：NO！那么，什么是软件的质量？什么是软件的质量？现代软件工程的质量保证与软件测试有什么不同？技术经理、项目经理与质量经理有什么不同？什么是现代软件工程的质量管理？开发团队在质量保证方面，要做什么工作？我们就来回答这些问题！什么是软件项目的质量管理？软件质量软件质量的定义：ANSI/IEEEStd729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。M.J.Fisher

定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。质量特性及其组合，是软件开发与维护中的重要考虑因素为满足软件的各项精确定义的功能、性能需求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合。如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。软件质量软件质量的因素与度量有关直接度量的因素如单位时间内千行代码中所产生的错误数。间接度量的因素如可用性或可维护性软件质量软件质量的度量模型1976年，Boehm第一次提出了软件质量度量的层次模型。1978年，Walters和McCall等人提出了从软件质量要素、准则到度量的三个层次式的模型。1985年，ISO建议软件质量模型由三层组成：高层：软件质量需求评价准则（SQRC）中层：软件质量设计评价准则（SQDC）低层：软件质量度量评价准则（SQMC）现代软件工程的标准体系ISO/IEC12207应用成果基础产品实用产品需求软件工程项目管理软件配置管理风险管理软件质量保证设计实现测试维护1.1软件质量的要素与度量1.1.1软件的质量要素1.1.2软件质量评价的准则1.1.3软件质量的度量1.1.4软件质量度量的实施1.1.1软件的质量要素什么是软件的质量？ISO9000的质量定义：质量的定义：反映实体满足明确和隐含需要能力的特性综合定义的说明：明确需要：指合同中用户明确提出的要求与需要隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要质量与等级的关系等级的含义是：对功能用途相同、但技术特性不同的存在事务的一种分类或排序例如：高质量——无错误、可读性强的用户手册低等级——有限的功能低质量——错误百出、编排混乱的用户手册高等级——大量功能确定质量和等级标准水平，是项目经理的责任

质量的要素讨论软件的质量定义，一般地从4个角度来看，即用户的角度、开发商的角度、产品的角度和价值的角度。1976年美国的B.W.Boehm和R.Brown先后提出了三层次的评价度量模型：软件质量要素、准则、度量。随后G.Mruine提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。IEEE标准1061-2019以表格的形式，定义了有关确认和收集与软件质量需求有关一个模型，或称为一个框架。可度量的软件的质量要素IEEE定义的软件质量度量框架度量框架一种用来组织、选择、沟通、评价软件系统要求的质量属性的辅助决策法。它逐层分解为特性、子特性和度量质量特性一个与质量有关的面向管理的软件属性质量子特性质量特性分解出来的技术组件直接度量一种不依赖与任何其他属性测量的度量预计度量一种试用于开发阶段的度量，它用来预计软件质量特性的值质量度量一个函数、它的输入是软件数据，输出是一个单一数值。它可解释为给定的软件属性对其质量的影响程度过程质量一种用来测量在软件系统开发、实现和维护过程中使用的方法、技术和工具特性的度量产品度量一种用来测量软件开发过程中任何中间或最终产品特性的度量

IEEE定义的软件质量度量框架第一层次：质量需求在四层模型的第一层，软件产品质量层，是产品必须满足的质量需求。它是用用户术语描述的，主要有四点：（1）产品将在用户所在组织当前使用的平台和操作系统上运行。（2）

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

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

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

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

IEEE定义的软件质量度量框架四层模型质量需求质量特性质量子特性直接度量度量描述（例子）产品将在多平台和当前用户正在使用的操作系统上运行可移植性硬件独立性硬件依赖性计算硬件的依赖性软件独立性软件依赖性计算软件的依赖性易安装性安装时间测量安装时间可重用性能够用于其他软件中计算能够或已经应用于其他软件系统的模块数量产品将是可靠的并能提供防止数据丢失的机制可靠性无缺陷性测试覆盖测量测试覆盖度审查覆盖计算已做过的代码审查模块容错性数据完整性统计用户数据被破坏情况数据恢复测量恢复被破坏的数据的能力可用性软件可用的百分比软件可用时间除以总的软件使用时间产品将提供完成某些任务所必需的功能功能性完备性测试覆盖计算调用或分支测量覆盖正确性缺陷密度计算每一版本发布前的缺陷安全性

数据安全性统计用户数据被破坏的情况用户安全性

没有被阻止的非法用户入侵数兼容性

环境变化

软件安装后必须修改的环境变量数量互操作性混合应用环境下软件的可操作性混合应用环境下可正确运行的数量产品将易于使用可使用性易理解性学习所用时间新用户学习软件特性所花费的时间易学性学习所用时间新用户学会操作软件提供的基本功能所花费的时间易操作性人的因素新用户基于人类工程学对软件消极方面的评价数量沟通性人的因素新用户基于人类工程学对软件消极方面的评价数量质量需求质量特性质量子特性直接度量度量描述（例子）1978年，Walters和McCall等人提出了从软件质量要素、准则到度量的三个层次式的模型。McCall选择的软件质量要素评价准则共21种，它们是：（1）可审查性(auditability)。检查软件需求、规格说明、标准、过程、指令、代码与合同是否一致的难易程度。（2）准确性(accuracy)。计算和控制的精度，是对无误差程序的一种定量估计。最好表示成相对误差的函数。值越大表示精度越高。（3）通信通用性(communicationcommonality)。使用标准接口、协议、规范的程序。（4）完全性(completeness)。所需功能完全实现的程度。

（5）简明性(conciseness)。程序源代码的紧凑与简洁性。（6）一致性(consistency)。设计文档与系统实现的一致性。（7）数据通用性(datacommonality)。在程序中使用标准的数据结构和类型。（8）容错性(error-tolerance)。系统在各种异常条件下提供继续操作的能力。（9）执行效率(executionEfficiency)。程序运行效率。（10）可扩充性(expandability)。能够对结构设计、数据设计和过程设计进行扩充的程度。1.1.2软件质量评价的准则（11）通用性(generality)。程序部件潜在的应用范围的广泛性，即部件可重用。（12）硬件独立性(hardwareindependence)。软件同支持他运行的硬件系统不相关的程度。（13）检测性(instrumentation)。监视程序的运行，一旦发生错误时，能明确地标识错误的程度。（14）模块化(modularity)。程序部件的功能独立性。（15）可操作性(operability)。操作一个软件的难易程度。（16）安全性(security)。控制或保护程序和数据不受破坏的机制，以防止程序和数据受到意外的或蓄意的存取、使用、修改、毁坏或泄密。（17）自文档化(sdlf-documentation)。源代码提供有意义文档的程度。（18）简单性(simplicity)。理解程序的难易程度。（19）软件系统独立性(softwaresystemindependence)。程序与非标准的程序设计语言特征、操作系统特征以及其他环境约束无关的程度。（20）可追踪性(reacebility)。从设计表示或实际程序构件，追踪到需求的能力。（21）易培训性(training)。软件支持新用户使用该系统的能力。McCall的软件质量评价准则软件质量评价准则

1、正确性正确性是指软件按照需求正确执行任务的能力。“正确性”的语义涵盖了“精确性”。正确性无疑是第一重要的软件质量属性。技术评审和测试的第一关都是检查工作成果的正确性。机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。2、健壮性

健壮性是指在异常情况下，软件能够正常运行的能力。正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。开发者往往把异常情况当成正常情况而不作处理，结果降低了健壮性。用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。所以提高软件的健壮性也是开发者的义务。健壮性有两层含义：一是容错能力，二是恢复能力。3、可靠性可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。可靠性本来是硬件领域的术语。比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。

软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”问题、“误差累积”问题等等。

时隐时现的错误一般都属于可靠性问题，纠错的代价很高。软件质量评价准则

4、性能性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。人们总希望软件的运行速度高些，并且占用资源少些。性能优化的关键工作是找出限制性能的“瓶颈”可以通过优化数据结构、算法和代码来提高软件的性能。

5、易用性易用性是指用户使用软件的容易程度。现代人的生活节奏快，图方便。所以把易用性作为重要的质量属性对待无可非议。

导致软件易用性差的根本原因：教育缺陷：没有开设人机工程学、美学、心理学这些必修课，大部分开发人员不知道如何设计易用的软件产品。开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也就会满意。

软件的易用性要让用户来评价。当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“界面友好”等词来评价软件产品。

软件质量评价准则

6、清晰性清晰意味者所有的工作成果易读、易理解，可以提高团队开发效率，降低维护代价。开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。可理解的东西通常是简洁的。一个原始问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。如果软件系统臃肿不堪，它迟早会出问题。所以简洁是人们对工作“精益求精”的结果，而不是潦草应付的结果。千万不要把在学校里“造文章”的手法用于开发产品！7、安全性

安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。“道高一尺，魔高一丈”，绝对安全的信息系统几乎不存在。开发商和客户愿意为提高安全性而投入的资金是有限的，他们要考虑值不值得。

软件质量评价准则

8、可扩展性

可扩展性反映软件适应“变化”的能力。在软件开发过程中，“变化”是司空见惯的事情，如需求、设计的变化，算法的改进，程序的变化等等。由于软件是“软”的，是否它天生就容易修改以适应“变化”？关键要看软件的规模和复杂性。现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。可扩展性越来越重要。可扩展性是系统设计阶段重点考虑的质量属性。9、兼容性兼容性是指两个或两个以上的软件相互交换信息的能力。兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。10、可移植性可移植性是指软件运行于不同软硬件环境的能力编程语言越低级，其程序越难移植，反之则容易。软件设计时应该将“设备相关程序”与“设备无关程序”分开，将“功能模块”与“用户界面”分开。软件质量评价准则

1985年，国际标准化组织（ISO）建议，软件质量度量模型由三层组成。高层称软件质量需求评价准则（SQRC），中层称软件质量设计评价准则（SQDC），低层称软件质量度量评价准则（SQMC）。分别对应McCall等人的要素、评价准则和度量。ISO认为应对高层和中层建立国际标准，以便在国际范围内推广应用软件质量管理，而低层可由各使用单位自行制定。ISO高层由8个要素组成、中层由23个评价准则组成。高层的8个要素为左表的列，中层的23个准则为下表的行。它们之间的关系如左表所示。ISO/IEC9126-1《产品质量-质量模型》的软件质量模型软件质量的另一种理解内部质量的定义是：反映软件产品在规定条件下使用时，满足需求的能力的特性，是软件开发过程中各阶段（需求开发、软件设计、代码编写等）产生的中间软件产品的质量。了解软件产品的内部质量，可以预计最终产品的质量。外部质量的定义是：反映软件产品在规定条件下使用时，满足需求的程度。外部特性反映在预定的系统环境中运行时可达到的质量水平。软件质量的另一种理解使用质量的定义是：反映软件产品在规定的使用环境下，使特定用户在达到规定目标方面的能力。反映的是从用户角度看到的软件产品在特定系统环境下满足其需求的满足程度。对内部和外部质量特性的度量描述包括：功能性、可靠性、易用性、效率、可维护性、可移植性等；对使用质量特性的度量描述包括：有效性、生产率、安全性、满意程度等软件质量的另一种理解1.1.3软件质量的度量软件度量：分析模型的度量（对分析模型的度量以测试系统的大小）设计模型的度量（度量体系结构、数据和系统的复杂度）源代码的度量（度量程序的长度、层次、开发量、时间等）对测试的度量（度量测试的宽度、深度、错误的级别）对维护的度量（度量软件的稳定性）

软件质量度量每个软件属性都有一套度量方法，选择度量方法时，必须考虑下列因素。1.与软件属性的相关性相关性分为4个等级：A—度量方法与相应的软件属性始终存在正相关AA—几乎总是存在正相关U—经常存在正相关S—偶尔存在正相关软件质量度量2.度量值的可理解性定量的度量方法所得到的值分为5种情况：AL—通过一个自动算法很容易理解UR—不需要受过专门训练的人员TR—需要受过专门训练的人员ER—需要专家EX—需要执行程序3.开发自动工具的容易性开发度量工具的难易程度分为3种情况E—容易M—存在困难D—很困难软件质量度量4.自动工具的完备性所开发的自动工具是否完全等价于度量方法，有2种情况C—完全等价P—部分等价5.潜在效益潜在效益分为5个级别：5、4、3、2、1软件质量度量软件质量度量两个软件（程序）质量度量方法Halstead的软件科学基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。McCabe复杂性度量法程序的复杂性很大程度上取决于程序控制流的复杂性单一的顺序程序结构最简单，循环和选择所构成的环路越多，程序就越复杂。软件质量的度量和评价软件质量特性度量有两类：预测型和验收型。预测度量是利用定量或定性的方法，估算软件质量的评价值，以得到软件质量的比较精确的估算值。第一种叫做尺度度量，这是一种定量度量。它适用于一些能够直接度量的特性，例如，出错率定义为：错误数／KLOC／单位时间。第二种叫做二元度量，这是一种定性度量。它适用于一些只能间接度量的特性，例如，可使用性、灵活性等等。验收度量是在软件开发各阶段的检查点，对软件的要求质量进行确认性检查的具体评价值，它是对开发过程中的预测进行评价。尺度度量检查表二元度量检查表基于软件配置管理的度量和度量准则SCM提供软件产品的状态统计。统计提供寻找软件开发的瓶颈和解决办法，并据此衡量软件产品的成熟度。度量准则：平均严重程度严重程度级的分布平均关闭时间严重程度的图示各配置项或子系统的图示

SCM的度量和度量准则软件产品成熟度数据要求：软件变更（问题）数量描述计算机软件配置项标识（CSCI）

严重程度级打开变更的日期（或发现问题）关闭变更（问题）和实施日期

软件变更统计

SCM的度量和度量准则图表分析软件剩余问题剩余变更和错误密度1.1.4软件质量度量的实施在确定要对一个软件（系统）进行度量之后，一般，采取以下5个步骤，来实施对该软件的度量：

（1）确定软件质量需求；

在用户需求中，除功能需求外，还有非功能需求，包括：质量需求、环境需求、设计约束、开发策略等。质量需求是用户比较关心的内容。

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

1.1.4软件质量度量的实施（2）确定直接度量

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

（3）分析度量结果对度量过程进行跟踪和分析，需要时，可能会对度量程序、度量工具、度量方法，甚至原始数据，做出补充和调整。（4）确认质量度量在度量过程中，进行度量结果的确认非常重要。首先，要确认度量过程是否与事实相符，脱离现实真实的度量，与目标再相符的结果也是没有意义的。其次，是确认方法的有效性，例如：在度量中，我们用到很多统计学方法，在这些方法中，我们有一些概率分布假设（例如：某些错误的发生，我们假设符合随机概率分布），当这些假设并不成立时，度量的结果是不真实的。一个系统集成项目的质量特性与度量可交付成果的质量采购的主机/存储/网络硬件/软件运输/安装/检验/调试/测试培训/服务/技术支持/维护/响应资料文档（手册）提供项目实施过程的质量项目的计划性组织准备的充分与周到性沟通与协调性操作与行为的规范性案例分析1、你已经确认的，你的项目的质量需求（质量特性）是什么？2、这些质量需求的（面向度量）的子特性是什么？3、如何进行这些子特性的度量（方法设计）？4、度量结果（度量值）的评价标准是什么？问题1：1.2.1确认过程1.2.2验证过程1.2软件工程的质量保证过程软件质量保证什么是质量保证它是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。什么是软件的质量保证就是向用户及社会提供满意的高质量的产品。软件的质量保证活动也和一般的质量保证活动一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动。即为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。现代软件工程的质量保证过程，主要包括软件确认与验证二个过程软件的确认（Validation）与验证（Verification）简称为V＆V或V2，也是软件产品质量度量的具体方法。软件确认的概念确认是这样一个过程，它评价“在软件开发过程期间（针对单元）或结束（针对系统）时，单元或系统是否满足用户特定的需求”。换句话说，是开发结束期间确认，我们的产品符合用户要求吗？因此，确认的产品质量。确认活动围绕三个基本过程来开展，测试、度量和软件可靠性增长软件验证的概念而验证是这样一个过程，它评价“在一个给定的开发阶段中，单元或系统是否满足在此阶段开始时确定的条件”。因此，它的意思是，我们正在制作的产品符合用户要求吗？因此，验证的是产品开发过程质量——工作质量。验证活动也是围绕三个基本过程来进行，审查、度量和配置管理。软件工程的质量保证过程软件质量保证传统的软件质量保证的活动技术方法的应用正式技术评审的实施软件测试标准的执行修改的控制度量记录和记录保存现代方法基于架构的迭代和增量开发配置管理软件确认过程1：测试根据不同的软件生命周期定义，测试的阶段、方法和类型构成一个层次结构，如下图：V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

测试与开发阶段的对应——V模式单元测试

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

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

由于单元测试在项目组中，常常由编码工程师完成，项目经理的管理一般并不深入到单元测试层。

集成测试（子系统测试）集成测试又称组装测试，它是在单元测试完成后，组装为一个子系统后，对下列只有组装后才能发生和测试到的问题，进行检查：（1）组装后一个模块对一个模块的影响； （2）合并功能是否是预期的； （3）独立的误差在合并后的变化，是扩大还是减小，是否在可接受的范围内； （4）实际的接口测试；包括：模块之间对实际衔接的标准、时序（实时性）、应答响应、容错与错误处理等； （5）模块间的资源竞争等。

集成测试也很重视集成的阶段性。最坏的情况是系统只有一次集成，就是系统全部模块完成后进行集成。实际上，这就像一部汽车，直到要出厂时，才来一次总测试。而当你每天生产一部完全不同规格、型号的汽车时，这个时候的测试，可能是非常要命的。

比较好的办法是通常采用的增量组装法，包括自顶向下或自低向上的增量组装。分阶段的增量组装测试，可以解决一次集成，问题的隔离和区分不易的困难。

确认测试（系统测试）

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

ɑ测试和ß测试

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

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

单元测试与验收测试单元测试和验收测试没有什么区别？单元测试可以类比为一个建筑的质检人员对建筑进行的检测，

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

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

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

在拟定测试计划时，首先需要对以下情况，做出估计： （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可以进入系统，并能打开所有的功能菜单测试结果描述相符测试人员

测试日期2019-03-08复测人员

复测日期

备注

测试用例：测试用例由谁设计？设计测试用例的依据是什么？测试设计的重点是什么？测试报告：收集齐上述的所有测试用例，构成了测试报告的基本要件。测试报告是对所有测试用例测试过程的总结。在测试报告中，应反映：（1）测试中出现问题的统计汇总和分析；（2）未解决问题的汇总和解决方案建议；（3）回归测试的统计和分析（度量）；（4）对测试计划的总结或修改。测试过程组织一个独立的测试小组为例，测试过程一般如下：（1）测试准备：制定人员、环境、工具、培训和外部支持计划。（2）测试计划：确定测试策略、建立测试计划。（3）测试用例：建立测试顺序树、确定测试的优先级、详细列出测试程序和测试数据，设计测试用例。（4）测试环境：了解需求、搭建环境、安装备份和恢复程序，记录初始环境、测试环境、恢复环境等。（5）测试执行：从测试计划复审测试计划进度表、恢复测试执行环境。（6）结果分析：执行结果分析、度量。（7）测试报告：错误趋势图、测试变动指示、产品检查点建议。软件审查的概念回顾：我们在上节介绍软件的确认和验证过程时，已经介绍了软件验证的三个过程是：审查、测量和配置管理。同时，我们也谈到，验证与确认的区别是，确认是在整个软件系统完成交付前或某模块完成交付前的检查，它的检查点是交付前。而验证贯穿于整个开发过程，是对过程的确认。因此，验证的范围包括了整个开发过程，它是软件质量保证并持续改进的强大工具。什么是审查，审查是一个正式的、严格的、具有深度的技术评审过程。因此，评审的目的是：（1）在软件开发过程中，尽早可能地发现问题，特别是过程性的问题；（2）确保对需求保持一致的意见；（3）验证任何修改和变更满足预先定义的准则；（4）为组织提供产品在质量和过程方面是否有效的实际数据；（5）使团队成员之间在技术上建立相互的了解；（6）增加软件确认测试的有效性；（7）提高优秀软件工程师的水准。软件评审软件评审在软件开发的各个阶段，都要采用评审的方法，以便及早发现软件的缺陷。软件评审的必要性1.从技术角度进行的审查是保证软件质量的重要措施由于人的认识不可能百分之百地符合客观实际，因此生命周期每个阶段的工作中都可能发生错误。由于前一阶段的成果是后一阶段工作的基础，前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会积累起来，如下图所示。原始要求正确的规格说明错误的规格说明需求分析设计正确的设计错误的设计对错误说明的设计编码正确编码错误编码对错误设计的编码对错误说明的编码测试正确功能可改正的错误不可改正的错误潜伏的错误不完善的软件产品软件评审2.技术审查也是降低成本的一个重要举措由于再后期改正一个错误比在早期改正同一个错误需要付出的代价高二至三个数量级，所以越在早期发现的错误越容易改正，代价越低。3.在技术审查合格之后，再进行管理复审，可以使管理人员专心从管理角度对开发工作进行审查，而不必顾及技术问题软件评审软件评审的办法成立评审小组，组员包括：组长、作者、评审员1.组长组长是小组的核心，最后由技术水平较高且没有直接参与这项工程的人担任。组长的任务是组织和领导技术审查的全过程，如安排会议日程，分发必要的文档资料，主持审查会议，确保审查全面、公正。2.作者作者是被审查文档或程序的编写者。如果开发小组由一个小组集体完成，通常由技术小组负责人代表小组参加审查小组。作者的责任是回答技术上的问题3.评审员评审员也应由技术专家担任。通常一个是前一阶段的技术骨干，另一个是后一阶段的骨干。评审员的任务是分别从各自的角度，公正客观地评价被审查的软件产品。软件评审软件评审的步骤准备简要介绍情况阅读被评审的文档（如检查表）开评审会返工复审软件开发的各个阶段，其检查表的内容不一样。6.3.1软件审查的准备评审人：审查一般由一个审查小组或审查委员会负责进行，审查小组内，应有以下角色构成：（1）主持审查活动的主审员；（2）被审查产品负责人，包括产品经理、技术经理、质量经理等；（3）负责对被审查产品进行讲解和解释的主讲人；（4）来自各有关部门的审查员；（5）记录员；（6）项目经理项目经理应该参与软件的审查过程，关注审查结果，但不一定要参加审查会议。这要看审查的级别。如果是组织内的项目级审查，项目经理作为被审查产品的负责人，应参加审查会议，否则，应该由具体的产品、技术或质量经理去参加这样的会议。被审产品的负责人参加这样的会议，不是为了解释审查中发现的缺陷，及其责任，进行辩解，而只是如实地向审查小组介绍产品为什么要这样做，和做了什么。审查的目的不是为了追究什么人的责任，而是为了改进过程。如果把评审，引入到人与人之间的斗争中去，则完全丧失了评审，作为过程改进手段的意义。

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

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

系统确认及回归测试已经完成审查内容作为被审查对象的项目组，按照审查组的要求，提交被审查材料，接受审查。

作为审查员，应该做什么准备？首先，明确作为审查员的定角色位、职责。审查员是那些具有相关知识和对被审查产品具有一定熟悉程度的，但不一定就是直接从事相同岗位（有时，还特别需要交叉换位）的人员。在参加审查前，他必须花一定的时间和精力，来了解产品，并能通过阅读提交的资料，了解产品与文档、标准和规范之间的差异。因此，他在审查中的责任是：（1）必须完全熟悉要审查的产品和产品所依据的文档和标准；（2）对照产品和文档，鉴别其中的差异；（3）客观地评价差异，识别是属于实现程度差别、缺陷，还是错误；（4）判断差异是实现的个体现象，还是过程问题；（5）以对产品而不是对人的态度，对差异进行评估和分析；（6）向主审员报告审查结果和分析意见。审查员的职责软件审查的过程在审查开始之前，审查组与被审查项目的有关人员，产品经理、技术经理、质量经理和项目经理们开一个“审查开工会”，主审员向被审查对象的有关人员介绍本次审查的目的、对象、范围和内容，有必要的话，花一点时间介绍一下审查方法，使得审查员和被审查项目的有关人员，在审查过程中易于沟通和理解。当被审查有关人员知道（不是同意）审查的主要内容后，主审员把审查工作，按分工，分配给各审查员，并请项目组指定有关的配合人员。会议约定好完成分组审查的时间，即召开审查汇报会的时间。获得审查资料的审查员，可以开始从看资料如手，进入审查阶段。如果需要实际测试和运行检查，项目组要配合安排机器时间、软件演示等与操作有关的环境。审查员经过一段时间的工作，已经对所分工的部分，通过阅读资料、实际查看等，获得了必要的信息，有关的疑问，通过向项目组实际询问，解释了不清楚的地方。审查员对差异，已经做好了记录。主审员按时间和进度，可以招集审查汇报会。在审查汇报会上，审查员汇报分组审查中发现的潜在的（还没有定论）的错误、缺陷和差异。审查小组对每一个问题进行讨论，并争取获得一致的意见。必要时，可以请项目组再做解释。记录员此时应详细记录讨论的过程和各自的意见，并确保这些记录的完整性、正确性和真实性。如果一次会议不能解决争论的问题，或者需要再扩大参加人员的范围，或者需要再做测试，那就那样去做。或者审查组发现问题已经非常严重，已经超出了软件评审的范围，那么，应立即停止评审，向有关上级报告问题，以便上级做出重大改进的措施。审查结果的发布是一个非技术的敏感问题。什么性质的结果可以发布，在多大范围内发布。审查结果如果比较满意，它的发布将对项目组是一个正向的激励，是相关人员能力的象征。负面的审查结果可能引来更大的争议和动荡。因此，审查小组和项目经理，要充分沟通，从积极的方面，使用审查结果。任何审查结果都不是针对个人的，但是任何工作都是由具体个人来负责和承担相应责任的。因此，审查结果的难处，就在这句话的二面性。软件审查的过程需求审查需求文档与需求属性（第二章已经介绍）

需求审查表（问题清单）

（1）

需求是否定义了要向用户展示的全部信息？（2）

需求是否论述了系统对用户错误操作的反映？（3）

每一需求项的描述是否清楚、简洁和没有二意性？（4）

每一项需求是否都是可测试的？（5）

需求是否有隐含或暗示的功能理解？（6）

需求项之间是否有自相矛盾的地方？（7）

需求是否有应该论述但没有提及的地方？（8）

需求对实时性、精确度、负载能力等有没有定义？（9）

需求是否包括了性能需求、质量需求等非功能需求？（10）

如果需求涉及复杂的关联关系、复杂的算法、复杂的决策机制，用户能完全理解吗？（11）

需求对软件升级、版本变更是否有明确的承诺？（12）

需求文档是否含有不必要的设计细节？（13）

是否可以根据需求，开发出适当的和完整的测试用例集？（14）

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

追踪与改正审查的目的是监督项目组对软件的品质，保持良好的状态和不断地改进。因此，审查小组有责任跟踪项目组对审查结果的利用情况。关注项目组的改进，是项目经理比关注审查结果更重要的事情。设计审查概要设计审查表（问题清单）详细设计审查表（问题清单）

设计审查的目标：概要设计重点审查以下几个方面（概要设计针对需求）（1）概要设计对需求的完整实现；（2）概要设计与需求的一致性；（3）概要设计向需求的反向可追踪；（4）概要设计中，对系统结构设计的逻辑性、合理性和可扩展性；由于概要设计是直接衔接需求的，因此，概要设计审查更多地是把设计与需求相衔接。在详细设计中，应重点审查以下方面（详细设计针对实现）（1）设计应符合组织即定的标准；（2）设计结果对下一阶段的编码是可用的。由于详细设计直接提供编码实现，因此，在组织内，应对详细设计的“粒度”做出规定。这样，即明确详细设计与代码实现的界面，同时，也是编码标准化的工作基础。在这方面，应结合实际，进行研究。代码审查代码的审查与具体实现工具有关，而且与具体实现工具的版本有关，因此，我们在这里就不具体讨论代码审查的内容。有不少文章具体讨论代码的标准化和设计技巧，可以作为审查的范本（如果必要的话）。代码审查的一个办法是走查。就是由审查人员“读”工程师写的代码，然后对照“标准”进行检查，是对软件文档的一种书面检查。它通过人工模拟执行源程序的过程，检查软件设计的正确性。人工模拟也像计算机执行那样，可以仔细推敲、校验和核实每一步的执行结果，进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性。走查是一件非常艰苦的工作，同时是需要非常大的毅力和记忆力的工作。因为一个系统程序量之大，组织的规则和要求之多。审查员要做的是N的N次方的核对。现在也有一些计算机程序，按一定的规则，帮助审查员“读”程序，并挑出（有的可以做简单的修改）毛病，VisualBasic就有这样的程序。如果没有计算机程序的帮助，审查员会“疯”掉的。测试审查测试审查是对测试结果进行审查，它审查的内容包括：（1）对测试用例的审查：测试用例的哪些要素（用例名、测试日期、预期测试结果等）是否齐备？（宽度）（2）在概要设计和详细设计中确定的关键点或特殊需求是否都测试到了？（深度）（3）测试过程（步骤、环境、用户模拟等）的设计是否正确、恰当？（4）预期值与结果值的差异统计；（5）测试目的是否达到？1、你的测试设计（单元、集成、系统）2、你的设计组织（过程）3、你的测试覆盖（宽度、深度）4、你的测试评审问题2：1.4.1现代质量管理回顾1.4.2ISO9000质量管理体系1.4.3PMBOK的质量管理1.4.4CMM2的质量保证1.4软件工程与相关质量保证体系1.4.2ISO9000质量管理体系

什么叫ISO

ISO是国际标准化组织InternationalOrganizationforStandardization的英文首尾字母的缩写词,翻译成中文就是“国际标准化组织”。

什么是ISO9000？

ISO制定出来的国际标准除了有规范的名称之外，还有编号，编号的格式是：ISO+标准号+[杠+分标准号]+冒号+发布年号（方括号中的内容可有可无），例如：ISO8402：1987、ISO9000-1：1994等，分别是某一个标准的编号。但是，“ISO9000”不是指一个标准，而是一族标准的统称。根据ISO9000-1：1994的定义：“'ISO9000族'是由ISO/TC176制定的所有国际标准。”

ISO9000质量管理体系

什么是质量认证

质量认证也叫合格评定，是国际上通行的管理产质量的有效方法。质量认证按认证的对象分为产质量认证和质量体系认证两类；按认证的作用可分为安全认证和合格认证。什么是产品质量认证

产品质量认证是指依据产品标准和相应技术要求，经认证机构确认并通过颁发认证证书和认证标志来证明某一产品符合相应标准和相应技术要求的活动。什么是质量体系认证质量体系认证的对象是企业的质量体系，或者说是企业的质量保证能力。

ISO9000质量管理体系软件企业为什么要建立ISO9000质量管理体系？

（1）软件本身的特点和目前软件开发模式使隐藏在软件内部的质量缺陷不可能完全避免（2）从技术上解决软件质量问题的效果十分有限。（3）技术人员和管理人员在软件开发工作中仍有一些不正确的认识需要纠正，这需要在企业建立和实施质量体系的过程中加以解决。（4）目前多数软件企业的质量管理尚未得到应有的重视，他们需要认真总结教训，并将其渗入质量体系形成制度化的规定。（5）软件开发必须靠加强管理来实现工程化，质量管理要体现在建立和实施开发规范中，保证软件工程的各个步骤和各个岗位的工作都符合要求，并且即使产品在使用中出现了问题，也能及时的发现，及时妥善解决。ISO9000质量管理体系质量体系文件的层次第一层：质量手册第二层：程序文件第三层：作业指导书管理性第三层文件（如：车间管理办法、仓库管理办法、文件和资料编写导则、产品标识细则等）技术性第三层文件（如：产品标准、原材料标准、技术图纸、工序作业指导书、工艺卡、设备操作规程、抽样标准、检验规程等）第四层表格与（质量）记录。质量体系文件的作用1.质量体系文件确定了职责的分配和活动的程序，是企业内部的“法规”。2.质量体系文件是企业开展内部培训的依据。3.质量体系文件是质量审核的依据。4.质量体系文件使质量改进有章可循。ISO9000质量管理体系ISO9000质量管理的8项原则：原则1：以顾客为中心

原则2：领导作用原则3：全员参与

原则4：过程方法

原则5：管理的系统方法

原则6：持续改进原则7：基于事实的决策方法原则8：互利的供方关系

1.4.3CMM2的质量保证过程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/DIS9001CMM管理体系强调完整的组织体系，可以用来建立符合ISO9000管理的组织管理本身对管理体系没有明确要求，默认组织体系是有效的、健全的。管理上的侧重组织管理过程管理项目管理技术管理过程的控制以KPA的形式来强调各环节的管理，但缺乏整个过程的管理管理职责强调宏观上的管理职责强调项目管理中不同角色的职责文件体系分为组织层（规范）文件和项目层文件，并将文件体系化分为质量手册、程序文件和作业指导书，层次清楚所有文件同等对待数据分析加强了数据分析、测量在定量过程管理（KPA）中强调适用范围所有行业，但对软件行业的适用性不够强，对企业规模无要求大型软件企业（500人以上），对于500人以下的中小型企业需要进行裁剪ISO9000与CMM的比较比较内容2000版ISO/DIS9001CMM管理理念以顾客满意为目标评价承包商的软件成熟能力配置管理弱强需求管理强调了合同评审，但对需求的管理很弱对需求管理有很强的控制，但没有对合同评审进行控制评审有较强的管理评审，但对技术评审管理较弱有较强的技术评审，但对管理评审的控制较弱内部沟通强调内部沟通强调内部沟通，并通过组际协调（KPA）来实现。外部沟通强调内部沟通强调内部沟通，并通过组际协调（KPA）来实现。变更管理弱强（有专门的KPA进行控制，包括技术变更和过程变更）1.4.4PMBOK的质量管理过程

项目的质量的二层含义从项目作为一项最终产品来看，项目质量体现在其性能或者使用价值上，也即项目的产品质量。从项目作为一次性的活动来看，项目管理质量体现在由WBS反映出的项目范围内所有的阶段、子项目、项目工作单元的质量所构成，也即项目的工作质量；项目是应业主的要求进行的,不同的业主有着不同的产品质量要求，其意图已反映在项目合同中。因此，项目合同是进行项目产品质量管理的主要依据。PMBOK的项目质量管理域包含一些程序，它要求保证该项目能够兑现它的关于满足各种需求的承诺。它包括“在质量体系中，与决定质量工作的策略、目标和责任的全部管理功能有关的各种活动，并通过诸如质量计划、质量保证和质量提高等手段来完成这些活动”。PMBOK的质量管理过程PMBOK的项目质量管理域包含一些程序，它要求保证该项目能够兑现它的关于满足各种需求的承诺。它包括“在质量体系中，与决定质量工作的策略、目标和责任的全部管理功能有关的各种活动，并通过诸如质量计划、质量保证和质量提高等手段来完成这些活动”。PMBOK的质量管理过程是：1、质量计划--确定哪些质量标准适用于该项目，并决定如何达标。2、质量保证--在常规基础上对整个项目执行情况作评估，以提供信用，保证该项目将能够达到有关质量标准。3、质量控制--监控特定项目的执行结果，以确定它们是否符合有关的质量标准，并确定适当方式消除导致项目绩效令人不满意的原因。这些工作程序互有影响，并且与其它知识领域中的程序之间也存在相互影响。依据项目的需要，每道程序都可能包含一个或更多的个人或由团队的努力。在每个项目阶段中，每道程序通常都会至少经历一次。

PMBOK的项目质量管理过程一——质量计划质量计划的目的主要是确保项目的质量标准能够得以满意的实现，其关键是在项目的计划期内确保项目按期完成，同时要处理与其他项目计划之间的关系。①

质量计划的依据质量方针：质量方针是对项目的质量目标和方向所作出的一个指导性文件，因此项目管理工作组应制定自己的质量工作方针，同时项目的质量方针应与项目的投资者完全共享。范围陈述：项目的范围陈述说明了投资者的需求以及项目的主要要求和目标，因此范围陈述是项目质量计划确定的主要依据和基础。产品描述：尽管产品描述的相关要素可能在范围描述中予以强调，然而产品的描述通常包含更加详细的技术要求和其它的内容，它对于项目质量计划的制定非常有用。标准和规则：项目质量计划的制定必须考虑到任何实际应用领域的特殊的标准和规则，这些都将影响项目质量计划的制定。其它工作的输出：除了上述范围陈述、产品描述之外，其他方面的工作输出也会对项目计划的制定产生影响，比如说采购计划就要说明承包人的质量要求从而影响到项目质量管理的计划。质量成本：质量成本是指为了达到产品/服务的质量标准而进行的全部工作所发生的所有成本。包括正常工作成本和改进工作成本，后者又包括预防、鉴定和故障成本。②质量计划制定的方法和技术利益/成本分析：质量计划必须综合考虑利益/成本的交换，满足质量需求的主要利益是减少重复性工作，这就意味着高的产出、低的支出及增加投资者的满意度。满足质量要求的基本费用是辅助项目质量管理活动的付出，其基本原则是利益与成本之比尽可能的大。基准：基准主要是通过比较实际或计划项目的实施与其它同类项目的实施过程，为改进项目实施过程提供思路和提供一个实施的标准。流程图：流程图是一个由任何箭线联系的若干因素关系图，流程图在质量管理中的应用主要包括如下几个方面：——原因结果（鱼刺）图：主要用来分析和说明各种因素和原因如何导致或者产生各种各种潜在的问题和后果。——系统流程图:主要用来说明系统各种要素之间存在的相互关系，通过流程图可以帮助项目组提出解决所遇质量问题的相关方法。试验设计：试验设计对于分析辨明对整个项目输出结果最有影响的因素是很为有效的，但该方法的应用存在着费用进度交换的问题。③

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

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