软件质量与质量保证

软件工程

第二版

教材配套光盘

杨文龙古天龙谭火彬

电子工业出版社2006-11第6章软件质量与质量保证2内容安排软件质量软件质量保证技术方法和工具的选用正式技术评审的实施多层次的软件测试（放在“软件测试”介绍）标准的执行文挡及其修改(变更)的控制（交付后的维护放在“软件维护”介绍）度量SQA小组的活动案例介绍3软件工程讲义-6.1软件质量意义和定义一,软件质量的意义保证软件质量是软件工程的首要任务必须严格定义软件质量的内涵明确软件质量保证的策略建立一组软件质量的保证活动并付诸实施及不断进行改进和完善4软件工程讲义-

软件质量的定义

二,软件质量的定义1，与明确确定的功能和性能需求的一致性2，与明确成文的开发标准的一致性3，与所有专业开发的软件所期望的隐含的特性的一致性5软件工程讲义-6.2软件质量因素1,可直接度量的因素2,只能间接度量的因素3,度量和量度度量（Measurement）度量是对开发过程进行检测，以提高开发过程的质量和劳动生产率量度（Metrics）量度是度量的结果或度量中一个项的抽象表示，做为评价质量和劳动生产率的基础6软件工程讲义-量度模型－Boehm模型7软件工程讲义-量度模型－McCall模型8软件工程讲义-量度模型－ISO模型9软件工程讲义-各因素间的影响10软件工程讲义-6.3软件质量保证的策略和活动

一、质量保证策略以检测为重点这是最早，也是最基本的策略，即产品制成以后才进行检测。这种检查只能判断产品质量，但不能提高产品质量以过程管理为重点即把质量的保证工作的重点放在过程管理上，对制造过程中的每一道工序都要进行质量控制以新产品开发为重点因为即把质量融进产品的开发设计中。因为许多产品的质量问题不是来自生产线的一道道工序中，而是源于新产品的开发设计阶段。因此，在新产品的开发设计阶段就应采取强有力的措施，来消灭由于设计原因产生的质量隐患11软件工程讲义-二、软件质量保证活动1技术方法和工具的选用2正式技术评审的实施3多层次软件测试4标准的执行5文档及其修改的控制6度量和报告制度7记录和记录保存8SQA小组活动12软件工程讲义-6.4技术方法及工具的选用一、采用或不采用软件工程方法软件工程从1968年提出至今，软件工程中许多技术已变得成熟。软件工程知识体（SWEBOK）已被定义，软件工程多个部分已有ISO标准，软件工程的发展趋势和新技术已初显端貌。问题：是否真正掌握软件工程的实质（运用系统的、规范的和可定量的方法开发、运行和维护软件）？并在实际工作中付诸实施！当然，软件工程也不是包医百病的灵丹妙药！但目前的主要问题是，许多软件企业不遵循软件工程的思想操作。13软件工程讲义-二、开发过程的选用1、瀑布模型2、瀑布模型的改进与延伸（1）原型（2）螺旋模型（3）4GT（4）混合模型3、迭代、增量到统一的软件开发过程4、形式化开发模型5、Web服务14软件工程讲义-瀑布模型瀑布模型是最早提出来的软件工程开发模式。这是一种系统的、分阶段的线性过程这种开发过程最大的问题是要求一开始就是正确的，而且始终不变。显然这是永远做不到的，也是违反自然规律的。另一问题是开发人员相互等待导致开发工作的阻塞现象，尤其在开发的开始和结束阶段尽管如此，它不仅在历史上起过重要作用，而且至今仍占有重要位置。它提供了一个模板，使分析、设计、编码、测试和维护可在该模板指导下应用。所以它仍然是软件工程中应用最广泛的过程模型15软件工程讲义-瀑布模型的改进与延伸-原型原型、螺旋模型、4GT和混合模型都是瀑布模型的改进和延伸原型开发确实是为解决瀑布模型中的不确定和可变性问题而提出来的一种办法。它与瀑布模型的不同之处，其系统开发不是一次完成，而是先给出一个可执行的系统样品，交用户评价和挑剔，然后修改，直到用户满意为止问题是开发者很可能为了快速和亷价地获得一个工作系统，而对系统的质量缺少考虑。这样的原型只能坚决拋弃，并重新设计，代价太大所以有人又提出了演化式原型(高度迭代和高度动态)和增量式原型(在总体设计的基础上逐步完成)，它们在用户用后不被抛弃，使其演化或增量为最终系统抛弃主要用于辅助分析和确定用户需求，以及解决系统任何部位的不确定性问题。演化可以作为一种开发方法。增量可以作为瀑布模型开发的补充16软件工程讲义-瀑布模型的改进与延伸-螺旋模型螺旋模型也是一种演化过程模型。它把瀑布模型的系统的、阶段的和顺序的控制与原型中的迭代和增量开发结合起来，并用风险分析来控制和管理风险这种方法更加真实地反映了现实世界和人类解决复杂问题的思谁方法但这种方法的成败，很大程度上取决于风险分析技术的好坏和成熟程度17软件工程讲义-瀑布模型的改进与延伸-4GT4GT的最大特点是拥有一组工具。每个工具都能使软件开发人员在高层上定义软件的某些特性，并由这些特性自动生成源代码。由此来减少软件开发时间和提高软件开发效率4GT主要问题是，目前只用于事务处理应用程序。另外，4GT在实现产品以后，要进行“彻底”的测试，还要有数据库的支持。而对于一些较大的应用程序，还必须先制定一个系统的设计策略，否则难以完成必须指出，使用4GT也会产生瀑布模型开发中遇到的同样问题将4GT与基于构件的开发方法结合起来，很可能成为软件开发的一种主流方法18软件工程讲义-瀑布模型的改进与延伸-混合模型目前，任何一个软件开发企业都采用混合模型开发软件。混合模型在第二章中已经介绍过，它是把几种软件开发模式组合起来，允许一个项目根据项目的特征和要求及企业自身的开发条件(技术的和管理的)选择一条最有效的路径这种模式的好处是：给企业的管理者和开发摸者提供了一个舞台，使每个模型的长处都得到发挥。但必须认识到，它对企业的管理者和技术人员提出了更高的要求19软件工程讲义-迭代、增量到统一开发过程自从OO技术于20世纪90年代逐步走向实际应用，才真正为迭代和增量到统一的开发过程奠定了坚实的技术和组织基础，也为重用技术和基于构件的开发模式提供了条件现在ISO/IEC(国际标准化组织和国际电工委员会)已制定了统一开发过程的标准：ISO/IEC

12207(Standardforinformationtechnology-softwarelifecycleprocess)和ISO/IECTR15504informationtechnology-softwareprocessassessment)。它们对开发组织、购买者、获取者、管理者和评估者都有了应遵循的依据20软件工程讲义-开发过程的选用小结软件过程的采用决定于要开发产品的类型、性质和特点。不同的产品应有不同的过程，不能只从技术角度来评价它们的优劣。如一个科学和工程计算系统可用瀑布模型或形式化开发方法；一个事务处理系统可用原型；而一个Web站点可用演化模型这部分门内容极为重要。因为开发过程的不同，不仅对软件开发和维护的质量和劳动生产率有重大影响，而实现时所采用的方法、语言和工具也不完全相同21软件工程讲义-Web服务Web服务模式的本质是“出租”，软件开发模式的本质是“开发”。它们是完全不同性质的事物，没有可比性。所以，不在这里讨论如果一个系统不采用自主开发，而是通过Web服多公司租赁系统，那就要了解和掌握这领域的知识。否则，不仅不能与Web服务公司签订好租赁合同，而且也无法用好Web服务公司提供的服务22软件工程讲义-三、开发方法、语言和工具的选用开发方法提供了构造软件的技术语言用以支持软件的分析、设计和实现工具为开发方法和语言提供自动化或半自动化的支持什么样的软件开发过程就有什么样的方法、语言和工具23软件工程讲义-（一）开发方法结构化开发方法面向对象（OO）的开发方法形式化开发方法24软件工程讲义-1、形式化开发方法在软件工程中研究的形式化开发方法，不是计算理论研究中的“符号十抽象公理化”的数学方法，这是由离散数学、逻辑学等课程去解决我们介绍的形式化开发方法则是用于软件系统设计中的数学建模、数学验证和数学程序求精技术形式化开发方法的最大优势它提供了一种机制，能够消除使用非形式化方法中存在的二义性、不完整性和不一致性等问题它不是通过人工的评审，而是通过数学的计算不仅提高了开发质量，还提高了开发效率形式化开发方法的最大问题开发方法本身还不能确保开发出来的软件都正确还不能做到支持生存期各个阶段的形式化对开发机构的开发人员、管理人员和用户的数学素质有很高的要求。目前多数开发机构和用户一时还难以做到25软件工程讲义-2、结构化与OO开发方法Meyer提出的一个设计方法实现模块化能力的五条判断准则：（1）分解性、（2）组合性、（3）可理解性、（4）连续性、（5）保护性从这五条准则出发，Meyer提出了模块结构五条基本设计原则：（1）语言（linguistic）模块单元、（2）少的接口、（3）小的接口（弱的耦合）、（4）明确的接口、（5）信息隐藏这些设计原则适用于任何设计方法。但我们可以看到：OO设计方法比任何其它方法都更能有效地实现这些原则。尽管OO对象中的数据和操作仍以结构化的方法为基础来实现随着时间推移，将会有更多的机构和开发人员使用OO开发方法26软件工程讲义-（二）语言1、规格说明语言2、设计语言3、原型开发语言4、编程语言27软件工程讲义-1、规格说明语言软件规格说明语言（specificationlanguages）记录软件规格说明它是对软件系统或它的一个构件行为的黑盒子描述为复杂的行为提供了一种简单的抽象描述。黑盒子描述：是根据进出黑盒子边界的数据来说明的，它不涉及黑盒子内部的机制在第五章的形式化开发方法中介绍了这种语言（基于代数的和基于逻辑的）。好处是它的精确性和自动化的潜在性。28软件工程讲义-2、设计语言软件设计语言（designlanguages）记录软件设计。它是对软件系统或构件的一种白盒子描述也就是把一个构件分解为一些更低层构件的描述并根据数据和控制来定义它们之间的相互联系设计语言与规格说明语言的区别设计语言用于定义分层的结构和构件间相互联系的描述而规格说明语言用于定又每个构件的接口设计语言与编程语言的区别设计语言的主要目的是文档（描述算法和数据结构，还要描述证明、假设和约定）编程语言则要包含所有的以获得一个有效的可执行系统29软件工程讲义-3、原型开发语言原型开发语言（prototypinglanguages）使用黑盒子和白盒子的描述来定义一个系统的可执行模型但是原型开发语言不要求给出系统各构件的详细算法，只要它是可描述的和可执行的即可原型开发语言与编程语言的区别：编程语言经过优化，能够生成一个时空效率都很高的工作系统原型开发语言可在牺牲执行效率的情况下，能支持简单和抽象系统的描述、信息的局部化、重用和适应性，它应方便地纪录规格说明和设计信息，并以其最终产品必须是可执行的为限制条件原型开发是一种快速构造可执行软件系统模型的方法，这种模型叫做软件快速原型30软件工程讲义-原型开发语言（续）如何解决原型语言的可执行问题一种基于元编程，是把原型开发语言看成是现有软件的改编和相互连接，实际上是一种重用技术另一种为可执行规格说明，它的基本思想是：如果规格说明是形式化的，而且具有操作语义，那么就有可能构造一个能直接执行的系统31软件工程讲义-4、编程语言编程语言（programminglanguages）记录编程编程就是用编程语言把对软件的设计表达式翻译为计算机能够“懂得”的形式这是计算机发展至今使用的最主要的方法，也是大家最熟悉的语言32软件工程讲义-编程语言（续）评价：不算汇编语言，现在已开发出各种用途的高级语言有400-500种，常用的语言近30种1.一般的应用领域2.算法和计算的复杂性3.软件的运行环境4.性能考虑5.数据结构的复杂性6.软件开发人员的知识7.一个好的编译器或交义编译器的可用性。33软件工程讲义-编程语言（续）选择：对于一个专门项目的编程语言的选择必须考虑：工程特性易于把设计翻译为代码、编译器效率高、源代码的可移植性、开发工具的可用性、源代码的可维护性都好心理特性：一致性、无二义性、紧凑性、局域性、线性34软件工程讲义-编程语言（续）实际上，项目的应用领域是语言选择的最重要的准则。因为，每一个应用领域都可以选择标准语言：1.系统软件：C2.实时应用：C、Ada、汇编3.商用语言：Cobol已让位于4GL4.工程和科学领域：Fortran仍然是主要语言5.嵌入式软件：同系统软件和实时软件6.个人计算机：已很少用Basic，主要用C7.人工智能应用：更多采用Lisp、Prolog8.网络软件：Java9.学习语言：Pascal现在市场上使用的不是上述语言，就是上述语言的改进、扩展或变种35软件工程讲义-语言总结应该看到，随着规格说明语言、设计语言和原型开发语言，以及软件科技的发展，传统的编程语言的作用正在被缩小和代替。如果有一天，计算机能够做到对文字、图形、图像和语言的完全识别，那么将会改变我们对整个编程语言的理解。但是，今天我们编程使用的大部分方法，仍然采用传统的编程语言36软件工程讲义-（三）工具任何一种开发模型，如果没有工具与环境的支持，再好的方法和语言也难以做好如何选择一个好的工具和环境？按现代软件工程的要求，一般应考虑以下三个方面：

1.一个工具集

它应当是为建立、修改、测试和文档化目标系统构件的工具集2.一个用户界面开发者通过这个界面，可以建立、修改和查询目标系统的构件3.一个数据库管理系统它能够管理所有形成的目标系统的构件37软件工程讲义-6.5正式技术评审的实施软件评审是一个“过滤器”正式技术评审（FormalTechnicalReviews，FTR）有时称为“走查（walkthrough）”38软件工程讲义-一、软件缺陷的费用影响FTR的一个明显好处是：可以早期发现软件缺陷，以便能在软件工程过程的下一步之前得到改正许多研究表明：50-65%的缺陷来自设计，而FTR能够发现设计缺陷中75%的缺陷一些大型系统的相对成本数据说明：如果在设计期间发现并改正一个错误所需的费用为1的话,在测试即将开始时的费用为6.5，在测试期间为15，而在交付使用后达到60-10039软件工程讲义-二、缺陷的扩大和排除缺陷扩大模型40软件工程讲义-无评审的缺陷扩大模型41软件工程讲义-有评审的缺陷扩大模型42软件工程讲义-三、正式技术评审（FTR）FTR的目标：1.发现软件在功能、逻辑和实现上的错误2.验证评审的软件符合需求3.保证软件按照已确定的标准表述4.使软件以统一方式开发5.使项目更易于管理FTR可以作为一个训练基地，使初级工程人员观察到软件分析、设计和实现不同的处理方法。也能促进人们变得更加熟悉43软件工程讲义-

正式技术评审-评审会议

评审会议3~5人参加会前准备，每个人工作量不超过2小时会议时间2小时评审结束时，必须作出决定接受该产品，不再作进一步修改该产品错误严重，拒绝接受（改正后也必须进行另一次评审）暂时接受该产品（小错误已经发现，必须改正，但没有必要进行另外的评审）44软件工程讲义-正式技术评审-评审报告和记录保存评审报告和记录保存报告评审了什么产品？谁评审的？发现了什么？结论是什么？记录：确定该产品中问题的大小成为生产者修改错误时的行动项的校对表还要建立一个跟踪过程，以保证问题列表中的项都被正确的改正了45软件工程讲义-正式技术评审-评审指南评审指南评审产品，不评审生产者建立一个议事日程，并遵循它限制争论和辯驳说明问题大小，不要企图解决所有提出的问题作记录限制参与人数和坚持充分准备为可能评审的产品开发一张检查表为FTR安排资源和时间表对所有的评审人员进行有意义的培训评审你早期的评审46软件工程讲义-6.6标准的执行产品质量是企业的生命，标准是产品质量的基础，没有标准，就无产品质量可言软件工程的标准体系标准的类别、范围和中国在SE中的标准ISO/IEC的软件工程标准体系结构框架ISO/IEC12207和ISO/IECTR15504ISO9000-3（1993）/GB/T19000.3（1994）CMM和CMMI47软件工程讲义-一,标准的类别、标准的范围和中国在SE中的相关标准（一）标准的类别Standard（标准）Specification（规范）Criterion（准则）Guidance（指南）Convention（约定）48软件工程讲义-（二）标准的范围（1）国际：ISO（国际标准化组织）

IEC（国际电子协会）区域：NATO（北大西洋公约组织）

CJK（中、日、韩）国家：GB（中国国家标准）

ANSI（美国国家标准协会）

BS（英国国家标准）

DIN（德国国家标准）

JIS（日本工业标准）49软件工程讲义-（二）标准的范围（2）行业：IEEE（美国电气和电子工程师协会）

FIPS（美国商务部国家标准局联邦信息标准）

ACM（美国计算机协会）

DOD（美国国防部）

MIL-standard（美国军用标准）

EIA（美国电工协会）

HB（中国航空标准）

GJB（中国军用标准）厂标：IBM（国际商业机器公司）

50软件工程讲义-（三）中国与SE有关的国家标准基础：GB/T11457-89（SE术语）开发：GB8566-88（计算机软件开发规范）文档：GB8567-88（计算机软件产品开发文件编制指南）

GB9385-88（计算机软件需求说明文件编制规范）

GB9386-88（计算机软件测试文件编制规范）质量：GB/T12504-90（计算机软件质量保证计划规范）管理：GB/T12605-90（计算机软件配置计划规范）90年以后，国家标准与国际标准从等效原则改为等同原则，均采用双编码。如GB/T19000.3（1994）-ISO9000-3（1993）51软件工程讲义-二、ISO/IEC的软件工程标准体系结构框架（一）基于软件工程功能的标准框架（由过程模型导出）52软件工程讲义-类型和类别软件产品从需求到产品的全过程涉及六种类型的标准：过程、产品、工具、技术、资源和数据按标准的自然属性又可分为四个类别通用、原理、要素、指南和补充53软件工程讲义-类型与类别的关系54软件工程讲义-过程的相关标准55软件工程讲义-相关标准说明PDAM12207/AMD112207的过程结果CD15388系统生存期过程IS12207软件生存期过程FDIS14764软件维护TR15846软件生存期过程软件配置管理DTR16326软件工程项目管理CD15939软件度量过程FD14598-3软件产品评价第三部分：开发者过程FD14598-4软件产品评价第四部分：获取者过程IS14598-5软件产品评价第五部分：评价者过程FDIS15910软件用户文档过程TR15271ISO/IEC12207使用指南ISO9000-3在软件开发、供应和维护中的使用指南TR9294软件文档管理指南ISO/IEC15288计划指南56软件工程讲义-（二）基于软件生存期过程的标准框架57软件工程讲义-三、ISO/IEC12207和ISO/IECTR15504（一）ISO/IEC12207Standardforinformationtechnology-Softwarelifecycleprocesses1995年8月由ISO和IEC联合推出，为开发和管理软件提供了一个公共框架。内容：引言介绍1.范围2.标准的参考文献3.定义4.本标准的应用5.五个主要生存期过程6.八个支持生存期过程7.四个组织生存期过程其框架结构见ISO/IEC的“软件工程标准体系结构框架”中“基于软件生存期过程的标准框架”附件：A.裁剪过程B.裁剪指南C.过程和组织指南D.参考文献58软件工程讲义-软件生存期过程（1）核心部分为5、6、7三部分软件生存期过程又分三个层次：1.高层为基本过程：包括获取、供应、开发、运行和维护2.中层为支持过程：包括文档编制、配置管理、质量保证、验证、确认、联合评审、审计和问题结论3.低（底）层为组织过程：包括管理、基础设施、改进和培训59软件工程讲义-软件生存期过程（2）通过简要介绍：软件从提出开始，要经过若干个过程（过程），每个过程有若干个活动（子过程），而每个活动又由若干个任务（子子过程）组成。所以，软件生存期由一系列的相关过程组成。过程是活动的集合，活动是任务的集合，任务是将输入变换为输出的操作。活动的执行，可以是顺序的、选择的或重复的，也可以是并行或嵌套的60软件工程讲义-过程与组织指南61软件工程讲义-12207的起因和作用（1）ISO/IEC12207标准编写者RaghuSingh的观点是，软件生存期过程国际标准的提出是为建立一个获取、供应、开发、运行和维护软件的国际通用标准。ISO/IEC122071988年提出，1995年发布。它描述了完成软件生存期的主要过程，以及它们之间的相互影响。62软件工程讲义-12207的起因和作用（2）按照参与IEEE和EIA合作开发出替代MIL-STD-498的商业标准的专家Moore和Tada提供资料说明，一个标准产生了两个名字：IEEE试用标准1498；EIA过渡标准640。美国国家标准协会ANSI发布了第三个标准：ANSI联合标准016（J-STD-016-1995）。ISO开发的标准是ISO/IEC12207。尽管J-016只在开发过程方面提供了要求，12207则另外说明了采办、供应、维护和运行。同时包括8个支持过程和4个组织过程。12207虽然用于组织和个人，但它也为供应商和获取方之间在软件的开发、维护和运行之间建立起桥梁关系。63软件工程讲义-12207的起因和作用（3）由于ISO/IEC12207为不同国家软件的获取方与供应商建立了通用的术语和过程框架，而有希望成为国际商业中重要的软件国际标准。许多国家开始采用它作为国家标准。然而，也有不少困难，尤其在美国。因为该标准不能为软件开发记录重要信息和数据，也没有为组织提供一个能够内部实施并符合12207的方法。美国为了更加有效地参与国际软件市场，必须决定如何在ANSIJ-016、IEEE-STD-1074（为IEEE开发的软件生存期过程标准）和ISO12207之间作出拆衷。64软件工程讲义-12207的起因和作用（4）首先是IEEE投票采用12207标准，然后是创建12207的工业实现（在美国）。为了满足美国12207的所有要求，产生了一个为组织提供允许内部使用于软件开发、维护和运行的美国版本。IEEE/EIA12207成为提出以下目标的战略标准：代表最佳的商业实践、适合于国防采办的复杂需求，及与新兴的全球软件市场相符合。这是对国际标准ISO/IEC12207的改编。它为组织采用满足商业和国防项目（服务于国内和国外客户）要求的软件过程提供了基础。65软件工程讲义-12207的起因和作用（5）这样做的好处是：（1）集成系统/软件解决方案（2）项目人员的有效利用（3）改进SEI的过程能力成熟度（4）以更低的成本生产高质量产品（5）组织对过程改进的重视（6）质量管理包括在组织过程中66软件工程讲义-12207的起因和作用（6）IEEE/EIA12207.0-1996Softwarelifecycleprocesses以ISO/IEC12207的原始形式，包含6个附件。IEEE/EIA12207.1-1997Softwarelifecycleprocesses-lifecycledata在记录生存期数据方面提供附加指南。IEEE/EIA12207.2-1997Softwarelifecycleprocesses-implementationconsi-derations

对ISO/IEC12207的生存期过程在美国的实践提供了附加的可选择的内容和说明。以上三个IEEE/EIA12207标准已于1998年5月被美国DOD采用，以替代MIL-STD-498。67软件工程讲义-MIL-STD-498（1）DOD于1994年发布了MIL-STD-498软件开发和文档化标准。它是在DOD-STD-2617A（国防系统软件开发）与MIL-STD-7935（信息系统）标准的结合产生的一个生存期标准，并纠正了2617A标准中所关注的一些问题，包括：（1）对瀑布开发模型的偏爱，（2）与增量和演化式开发模型的兼容性，（3）对正式评审和审计的依赖性，（4）与Ada和OO方法的兼容性，（5）需求和设计的区别，（6）对文档准备的强调，（7）CASE工具的使用。68软件工程讲义-MIL-STD-498（2）为什么要在商业标准中讨论498？这是因为498对软件质量保证产生了两个重要作用：（1）对软件质量要求和标准的整体集成，而不是单独的标准。（2）商业标准的采纳是通过对498的一个跨越来实现的。因此，许多学习和比较都是在498的基础上进行的。DOD在软件采办的合同中，商业标准是非常有效的和不可缺少的标准之一。DOD要求可以用商业标准，除非存在不能满足用户要求情况下。所以，DOD要求开发出能替代498的商业标准也是顺理成章的。69软件工程讲义-（二）ISO/IECTR15504ISO/IECTR15504InformationTechnology-SoftwareProcessAssessment这是ISO/IEC联合推出ISO/IEC12207之后于1998年推出与之相对应的ISO/IECTR15504本标准提供了一个包含整个软件生存期过程的框架：该框架的过程参考模型范围与ISO/IEC12207紧密映射不仅进一步肯定了12207对软件工程实践的重要意义，还保证了软件生存期过程在世界范围内进行评价和对比时有了统一的标准，也体现了抓源头的思想对软件开发组织、软件供应商、购买者、获取者、管理者和评价者都有了依据这在国际软件工程界，与12207一样也是第一次。70软件工程讲义-ISO/IECTR15504的组成71软件工程讲义-过程与过程能力参考模型参考模型由过程量度和能力量度组成：过程度量能力度量72软件工程讲义-过程度量按过程所从事的活动不同把过程分为五个类别：用户-供应商过程类（CUS）工程过程类（ENG）支持过程类（SUP）管理过程类（MAN）组织过程类（ORG）每个过程类都包含有许多过程。这种分类及过程的工作通常由从事获取、供应、开发、维护和实施的企业严格遵循12207中关于软件生存期过程的有关规定进行。每个过程的定义都应包含两个部分：一是对过程目标的描述；二是包括一条或多条关于描述的更进一步的说明。73软件工程讲义-能力度量15504中把过程能力分为六个等级0级：不完善的（Incomplete）过程1级：已实施的（Performed）过程2级：已管理的（Managed）过程3级：已建立的（Established）过程4级：可预测的（Predictable）过程5级：优化的（Optimizing）过程74软件工程讲义-能力度量（续）每个等级中又包含有九个过程属性：过程实施（processperformance）实施管理（performancemanagement）工作产品管理（workproductmanagement）过程定义（processdefinition）过程资源（processresource）过程度量（processmeasurement）过程控制（processcontrol）过程变更（processchange）持续改进（continuousimprovement）这些属性代表了上述所定义过程的可度量特征。75软件工程讲义-能力度量（续）过程属性达到的能力又可划分为四个级别：N（Notachieved）：未达到

P（Partiallyachieved）：部分达到

L（Largelyachieved）：大部分达到F（Fullyachieved）：全部达到

76软件工程讲义-能力度量（续）77软件工程讲义-15504的实施（1）（1）建立指导小组（2）设立实施的目的和目标（3）确定待实施的过程（4）确定过程的目标能力（5）建立过程小组（6）提供资源和时间（7）分析每个目标过程的当前的成熟度（8）制定每个过程的改进计划78软件工程讲义-15504的实施（2）（9）追踪每个过程每个季度的改进状态（10）向指导小组报告改进进度（11）提供所需的额外资源（12）组织正式的评估来验证目标能力级别（13）建立新的实施目的和目标每个组织的情况都不相同，不同组织的最初过程集合也不尽相同。因此，15504的实施所采用的步骤也应该不同。79软件工程讲义-15504的出现15504又名SPICE（软件过程改进和能力鉴定）（1998）是源于对多种模型的改进和软件过程的评估：（1）ISO9000（1987、1994）（2）EUESPRIT项目中开发的Bootstrap：Trillium（1993）（3）加拿大开发的电信业待定评估模型（4）CMU/SEI：CMM（1993）80软件工程讲义-15504开发的目的目的是提出一个软件过程评估的国际标准。人们期望这个标准能给出使用不同的评估模型和方法的结果可比性。1990年开始着手，1995年发行了第一版，1996年又发行了第二版，ISO15504的二类技术报告（作为一种国际标准验收，但还没有就报告中标准的最终定义完全达成一致）则是1998年发行的。Bootstrap和CMM模型都进行了修正，符合现在的15504标准。81软件工程讲义-三、ISO9000-3（1993）-GB/T19000.3（1994）质量管理和质量保证标准-在软件开发、供应和维护中的使用指南ISO9000系列标准原为硬件制造业制定的标准，不能直接用于软件业的生产曾试图用改编的9001用于软件业的生产由于软件与硬件的性质截然不同，软件为人工智能产品，实践结果说明不行，于是以ISO9000系列标准的追加形式，专门制定了ISO9000-3。82软件工程讲义-（一）标准的目的和范围本标准作为ISO9000/GB/T19000系列标准之一，旨在生产满足需求的软件而建议采用的控制手段和方法，即为从事软件开发、供应和维护的组织建立质量管理体系提供指南本标准适用于软件产品的整个生存期阶段和任何生存期模型，也适用于合同提出特殊要求的产品83软件工程讲义-（二）标准的主要内容本标准在给出软件质量管理体系要素时，没有按照ISO9001/GB/T19991的形式给出，而是按下列三部分给出：1.质量体系-框架2.质量体系-生存期话动3.质量体系-支持活动84软件工程讲义-质量体系－框架这部分主要从管理上描述了构成了质量体系的组织机构、管理职责、质量体系的基本要求及构成质量体系的框架（1）领导的职责、作用和采用的手段（2）质量体系

GB/T6583-ISO8402给质量体系定义为：为实施质量管理所具有的组织机构、职责、程序、过程和资源。这一定义给出了质量体系的五个要素，同时明确了质量管理的核心是建立适合企业实际的质量体系。质量体系应以深入细致的质量体系文件为基础，应用系统的有序的方法将质量体系要素、需求和预防措施清楚地写入文件质量体系是贯穿产品整个生存期的一个综合过程，它强调的是在开发过程中的质量保证，以预防为主，而不是在问题发生后依靠纠正措施来解决问题。因此，应按质量体系要求制定并执行质量活动计划85软件工程讲义-质量体系－生存期话动1.合同评审2.需方需求规格说明3.开发策划4.质量计划5.设计与实现6.测试与验证7.验收8.复制、交付和安装9.维护86软件工程讲义-质量体系-支持活动1.配置管理2.文档控制3.质量记录4.度量5.规则和惯例6.工具和方法7.采购8.配套的软件产品9.培训87软件工程讲义-ISO9000系列标准的制定与发布国际标准化组织质量管理和质量保证技术委员会（ISO/TC176），在多年协调努力的基础上，总结了各国的质量管理和质量保证经验，经过各国质量管理专家近10年的努力工作，于1986年6月正式发布ISO8402<质量-术语>标准、1987年2月正式发布ISO9000~9004系列标准。88软件工程讲义-ISO9000~9004系列标准ISO8402-1986质量-术语ISO9000-1987质量管理和质量保证标准-选择和使用指南ISO9001-1987质量体系-设计/开发、安装和服务的质量保证模式ISO9002-1987质量体系-生产和安装的质量保证模式（9001的子集）ISO9003-1987质量体系-最终检验和试验的质量保证模式（9002的子集）ISO9004-1987质量管理和质量体系要素指南（质量管理基础标准）89软件工程讲义-ISO9000标准制定的初衷源于组织需要评估他们的转包商的能力或成熟度。一旦有了可用的国际标准，组织就可以使用满足ISO9000标准作为对转包商的最低要求，从而可以预测转包商最低限度的质量标准，也可由此而变成客户选择承包商或第一承包商选择转包商的一个鉴别器ISO9000可以应用于各类行业，包括制造业、软件业和服务业90软件工程讲义-ISO9000-1994版1994版是1987版的修订版。它最初是为进行产品设计、开发和生产的制造公司所编写的，并被服务公司和软件公司的采用ISO9001是9002和9003的一个扩展集，它涵盖了整个产品生存期9002包含生产、安装和维护标准；9003包含最终审查和测试标准ISO9000-1994由一组标准和如何应用这些标准的原则组成91软件工程讲义-1994版相关的全部标准的集合ISO8402质量管理/保证词汇表ISO9000-1达了选择和使用9000的指导方针ISO9000-2应用9001/2/3的指导方针ISO9000-3在软件中应用9001的指导方针ISO9000-4对资源进行规划、组织和控制，以生产可靠产品的指导方针ISO9001用于产品/服务的设计、开发、测试、安装和维护的标准ISO9002用于生产、安装和维护的标准(9001的一个子集)ISO9003用于最终审查和测试的标准(9001的一个子集)ISO9004-1实施质量体系的指针方针ISO9004-2持续改进的指导方针92软件工程讲义-1994版中20项条款（1）ISO9000认证过的组织必须能够证明它已满足相关的条款：（1）管理人员的职责（2）质量体系（3）合同审查（4）设计控制（5）文档控制（6）采购（7）买方提供的产品（8）产品标识和可追踪性93软件工程讲义-1994版中20项条款（2）（9）过程控制（10）审查和测试（11）审查度量和测试装置（12）审查和测试状态（13）不合格产品的控制（14）纠正措施（15）搬运、存储、包装和交付（16）质量记录（17）内部质量审核（ISO10011）（18）培训（19）服务（20）统计技术94软件工程讲义-ISO9000-2000版2000版比1994版的标准要简单，它只有3个标准：（1）ISO9000-2000（2）ISO9001-2000（3）ISO9004-2000标准包括质量管理体系的基本原则和词汇表。新标准中的文本比旧标准更友好，更具逻辑性。旧9001、9002和9003标准被合并成一个标准。新标准中只有5项条款，与旧标准中的20项条款比较更以客户为关注点。2000版为性能改进提供了一个指南，这有助于标准的实施。它还包括一个简单的自我评估方法95软件工程讲义-2000版标准的5项条款（1）质量管理体系-质量管理体系的文件和实施（2）资源管理-涉及的是实施质量管理体系所需的资源供应（3）产品或服务的实现-实现产品或服务的过程供应（4）管理职责-管理人员在质量管理体系的实施中的担负的职责（5）度量、分析和改进-建立度量程序，以度量质量管理体系的性能，从而确定改进新标准的目标是：获得用户需求，开发出满足需求和符合甚至超过客户期望的软件，并持续地改进以更好地为客户服务96软件工程讲义-2000版的实施实施2000版的目标是改进质量和客户满意度实施过程的步骤：（1）认知培训（2）成立一个小组（3）建立ISO9000状态（4）准备行动计划（5）追踪行动计划（6）呈交行动计划的状态（7）ISO9000就绪评估（8）联系注册人（团体）（9）正式ISO9000审核（10）持续改进97软件工程讲义-

ISO发布了两个与ISO9000并立的两个应该关注的标准1.ISO14000环境管理体系标准（1993开始，1996发布）2.ISO18000职业安全卫生管理体系标准（1996讨论，--1999我国制定试行本）乃98软件工程讲义-四、CMMCMM（TheCapabilityMaturityModel）不是国际标准，是CMU/SEI于1986年在Mitre公司的协助下，用于帮助机构改进其软件过程和联邦政府要求能提供一种用来评价软件承制方软件能力的方法，开始工作经过五年的努力，于1991/1992公开发布了基线版1.0之后，1992/19931.1版、1997/19982.0版，2000推出了CMMI1.0版，它除了沿用CMM分级的形式外，还吸收了ISO/IECTR15504的一些特点99软件工程讲义-CMM（续）CMM是一个概念模型，它给出了一个软件机构如何开发和维护高质量软件产品的思路CMM也是一个描述模型，它描述了一个具有某个级别的软件机构所具有的主要特征CMM又是一个系统框架，它为一个软件机构改进其软件过程能提供一种改进的途径100软件工程讲义-CMM结构101软件工程讲义-CMM结构－成熟度级别CMM的顶层为成熟度级别（五级）1级：初始级（TheInitialLevel）2级：可重复级（TheRepeatableLevel）3级：已定义级（TheDefinedLevel）4级：已管理级（TheManaged）5级：优化级（TheOptimizingLevel）102软件工程讲义-CMM结构－关键过程域（1）关键过程域除1级外，每个成熟度级都包含几个关键过程域（KeyProcessAreas）它们确定了要实现一个成熟度级别所必须解决的问题和目标处于级别3的软件机构一定要解决级别2和级别3中所有关键域中的问题；4、5级类推共有十八个关键过程域103软件工程讲义-CMM结构－关键过程域（2）2级：需求管理软件项目计划软件项目跟踪和监督软件分包合同管理软件质量保证软件配置管理3级：机构过程焦点机构过程定义培训大纲综合软件管理软件产品工程组间协调同行评审4级：定量过程管理软件质量管理5级：缺陷预防技术更新管理过程变更管理104软件工程讲义-CMM结构－共同特性每个关键过程由五部分组成，称为共同特性（CommonFeatures）执行约定（如建立机构策略和领导关系等）执行能力（如资源、机构结构和培训等）执行活动（如制定计划和规程、执行和跟踪及必要时采取的纠正措施等）度量和分析（如可采用的度量实例等）验证实现（如管理部门和质量保证小组实施的评审和审核等）105软件工程讲义-CMM结构－关键实践在共同特性中的实践，描述了要建立一个过程能力所必须完成的活动，即每一个关键过程都要用关键实践的概念进行描述CMM有316个关键实践（KeyPractices）关键实践只描述“做什么？”不规定“怎么做？”如不指定生存期模型、不规定产品实现所采用的开发方法和工具，从而可以让各个机构可以选择自己的方法。但必须合理地说明关键实践，以判断是否有效地实现了关键过程域的目标106软件工程讲义-CMM应用-软件过程评价与软件能力估价（1）1,软件过程评价（processassessment）和软件能力估价（capabilityevaluation）的方法基本相同。但由于评价和估价的动机、目的、输出和结果归属不同，使得在会谈或采访目的、访问范围所采集的信息和结果的表示方式，可能存在重要差别。所以，所采用的的详细规程不同，培训要求也不同2,评价是在开放、合作环境中进行的，目的在于暴露问题和帮助管理人员和技术人员改进他们所在机构的过程。所以，评价能否成功取决于他们对机构改进的支持。但更重要的是要通过各种座谈会了解机杓构的软件过程。评价的结果除了能确定机构所面临的软件过程问题外，最有价值的是明确机构改进软件过程的途径，促进制定进一步的行动计划，使整个机构关注软件过程的改进，提高整个机构改进行动计划的动力和热情107软件工程讲义-CMM应用-软件过程评价与软件能力估价（2）3,软件能力估价是在更为面向审计的环境中进行。估价的目的与金钱有关，因为估价组的推荐意见将影响挑选承制方或投放资金的多少。估价过程的重点在评审巳文档化的审计记录上，这些记录能揭示机构实际执行的软件过程4,必须指出的是：评价和估价的结果不是不可比的。因为它们都是基于CMM的，其不同之处也是可以解释的108软件工程讲义-CMM应用－评价方法评价方法选择评价小组填写成熟度问卷进行响应分析现场访问、会议和文档评审提供基于CMM的调查结果清单制作关键过程域的剖面图，以显示该机构哪些区域巳满足，哪些区域尚未满足关键过程域的目标等109软件工程讲义-CMMICMMI为CMM的集成项目CMMI的目标1,在一个模型中集成多层CMM成熟度级别,以简化过程的改进和评估2,要符合15504的要求CMMI有两种发行版本110软件工程讲义-CMMI的分级版本分级版本为CMM界所熟悉，分级模型使用成熟度级别。分级版本的优势在于使用的机构对其非常熟悉。过程的改进从基本管理实践开始，经过连续成熟度等级路径获得进展，其中每层成熟度等级为下一层级别提供了坚实的基础。111软件工程讲义-CMMI的连续版本连续版本为15504界熟悉，连续模型使用能力级别。允许机构集中在最符合机构业务目标的过程改进上，同时也可以与其它机构进行对比。但对比的焦点在过程域与过程的域的比较。CMMI的连续模型与15504类似112软件工程讲义-CMMI两个版本的异同两种版本的表述都使用过程域、特定目标和一般目标、特定实践和一般实践，而且两种表述使用同样的过程域。连续版本有6个能力级别，这些能力级别是应用于每个过程域的成熟度分级，这6个能力级别从0到5的编号，每个能力级别有一系列特定目标和一般目标。连续模型的能力级别为过程域的过程改进提供了路经。组织要把它的过程域映射到CMMI过程域中，如同15504中的那样。113软件工程讲义-CMM与ISO标准比较CMM与ISO9000-3的设计思路不同，虽然都是着眼于软件质量管理和软件过程管理，它们最大的不同是：CMM强调的是持续的过程改进；ISO9000-3涉及的是可接受的质量体系最低标准还要指出的是：CMM中关于能力等级是针对每个软件机构的；而ISO/IECTR15504中的能力等级是针对每个过程的114软件工程讲义-小结自从20世纪70年代以来，软件质量要求的标准化方面已经下做了大量的工作。这里重点介绍了20世纪90年代以来的商业标准以及它们的统一，希望大家对这些标准以及它们的现状能够有所了解。大量事实表明：建立在全面质量管理（TQM）或持续过程改进基础上的系统开发本质是一样的。许多跨国公司，如美国波音，以军用标准为基础，开发了内部标准，同时在进一步的软件开发过程中对其标准不断进行改进，建立在这些企业内部标准和商业标准基础上的软件开发系统，经过多年的改进之后，证明是有效的系统。115软件工程讲义-6.6文档及其修改的控制在生产软件时，修改（Change）是不可避免的，而不修改则是不正常的如果修改中有任何疏忽或处理不当，就非常容易把一个开发得很好的软件带入混乱！所以，只有当每个软件修改可以被说明、分析、跟踪和控制，而且所有需要知道的人都被通知到时，这样才能保证软件修改的质量软件配置管理（SoftwareConfigurationManagement,SCM）就是用来对软件文档及其修改控制的116软件工程讲义-一、软件配置管理软件生存期各个阶段的交付项（包括描述程序的文档、和程序（源代码或可执行代码），以及包含在程序内部或外部的数据）组成整体软件配置软件配置管理就是对这些交付项修改的管理，因此，不难看出：一个开发组可以生产出几百或上千种独立的交付项，所有这些交付项形成一个相互依赖的层次网在开发和维护的各个步骤中需要不断地再加工、修改和提高，因此任何交付项都可能有很多不同的版本，而且某一项的任何一种版本都与其它交付项的特定版本有关要防止相关交付项上下左右不一致引起的错误，是配置管理要具体解决的问题当然，解决这个问题的机制非常多，以至于需要一个独立的配置管理计划作为质量管理计划的补充，而且应让全体人员都知道，应该怎样完成和控制他们它们的工作质量117软件工程讲义-二、基线基线（baseline）按IEEE1990的定义为：巳经通过正式技术评审和批准的规格说明或软件产品，它因此可以作进一步开发的基础，并只能通过正式修改控制规程才能被修改在开发的整个过程中和交付以后，因为发现错误和修正错误、或推翻原设计，以及改变系统的需求等，系统将受到某种变更的影响，这些“干扰”自然会引起所有交付项存在多种版本所以必须从所有交付项中确定一个一致的子集作为软件配置基线（SoftwareConfigurationBaseline），如系统分析、软件项目计划、软件需求分析、软件设计、编码、测试和维护等基线不应把基线看着是“快照”，也不是特定瞬间存在的时间脉冲，而是在各交付项版本中选定的一个。这些版本一般产生在不同时间，但具有在开发的某一特定步骤上相互一致的性质，这是同一状态的一致118软件工程讲义-基线的用途1.可以作为一个检查点2.可以作为区分两个或多个分叉开发路径的起始点3.对于开发组和用户，内部一致的基线是理想的正式评审目标4.包含测试系统的基线可以正式发行，用作评价或培训，或其它相关系统的辅助测试119软件工程讲义-取得基线和修改基线的路径120软件工程讲义-三、标识标识（Identification）：为了控制和管理软件交付项，每个交付项必须被独立命名，然后用面向对象的方法组织1.基本对象：如数据模型、构件A2.聚合对象：如软件设计规格说明是一个聚合对象，它由数据设计、体系结构设计、过程设计和界面设计组成。在概念上它是一个被命名的指针表，指向基本对象每个对象都具有一组唯一的标识它的特征1.名字：一个无二义性的字符串2.描述：一个数据项列表。它们标识：交付项类型（文档、程序、数据）、项目标识符、修改/版本信息3.资源：由对象提供：处理、引用或需求的实体（数据类型、特定函数）4.实现：一个指针。基本对象指向“文本单元”，聚合对象指向null121软件工程讲义-标识（续）对象的标识还必须考虑存在于命名对象间的关系。如：E-Rdiagram1.4<part-of>datamodeldatamodel<partof>designspecification

一个对象层次中，对象间的关系都沿着层次树的路径是不现实的、在许多情况下，对象跨越对象层次的分支相互关联。如：datamodel<interrelated>dataflowmodeldatamodel<interrelated>testcaseclassm122软件工程讲义-标识（续）对象的标识在整个软件开发过程中不断在演化。一个对象在被确定基线前，它巳经被修改多次；而在作为基线后，修改仍经常发生，修改可以对任何版本进行。因此，开发者如何引用版本？销售者如何知道当前用户使用哪些版本？我们如何确定某个版本的源代码修改巳经反映在对应的文档中？等等。所有这些问题的回答：关键在版本的标识123软件工程讲义-四、修改控制无控制的修改必将导致混乱。修改控制过程：124软件工程讲义-修改过程125软件工程讲义-五、配置审计如何保证修改控制的正确实现，除了进行正式的技术评审（FTR）以外，还要进行软件配置审计。通常检查下列问题：（1）被批准的修改报告中修改巳经完成了吗？（2）是否巳经进行了正式的技术评审？并表明技术的正确吗？（3）软件过程是否遵循了软件工程标准？（4）修改是否在交付项中被完全实现？配置对象的属性是否反映了该修改？（5）是否给出了修改者的姓名和修改的日期？（6）是否遵照了标识修改、记录修改和报告修改的软件配置管理规程？（7）所有的相关交付项都被更新了吗？在有些情况下，配置审计作为正式技术评审的一部分。审计一般都由质量保证小组进行126软件工程讲义-六、状态报告软件配置状态报告是软件配置管理的一项任务。它必须回答以下问题：（1）发生了什么事？（2）谁做了此事？（3）此事是什么时候发生的？（4）将影响到什么？配置状态报告可存储在一个联机的数据库中，使得软件开发者和维护者可以通过关键词分类访问修改信息，管理者也可获得与管理相关的信息127软件工程讲义-6.8度量与量度度量的主要目的：（1）更好的理解产品的质量（2）评价过程的效率（3）改进项目层完成工作的质量讨论的重点放在产品质量的量度上。（1）传统（结构化）软件的量度（2）面向对象软件的量度128软件工程讲义-一、传统软件的量度（一）软件复杂性（二）软件可靠性（三）软件可用性（四）软件安全性129软件工程讲义-（一）软件复杂性软件复杂性（complexity）是指程序的结构、模块、简明、简洁和可理解的程度1.代码行复杂性量度2.Halstead软件科学量度（1977）3.McCabe复杂性量度（1976）4.功能点复杂性量度130软件工程讲义-1.代码行复杂性量度就是用程序代码行（codeline）的多少来衡量程序的复杂性。这是早期，也是最简单的计算程序复杂性的量度<100行语句的程序呈线性关系；>100行语句的程序，其出错率以非线性方式增长。所以这种方法十分粗糙131软件工程讲义-2.Halstead软件科学计算（1977）这种方法是根据程序中可执行代码行的操作符（如逻辑、算术运算符等）和操作数（如变量名、常数等）的数量来计算程序的复杂性程序的操作符是有限的，其最大数目不会超过关键字的数目。而操作数的数目却随程序的规模的增大而增加。一般地说：操作符和操作数的量越大，程序结构就越复杂这种方法采用了一组原始度量，它们可以在代码生成后给出，也可在设计完成后估出设：n1：程序中出现的不同的操作符的数目n2：程序中出现的不同的操作数（或操作对象）的数目N1：程序中操作符出现的总数N2：程序中操作数出现的总数132软件工程讲义-Halstead算式Halstead用这些原始度量定义了以下算式：（1）程序长度N=n1log2n1+n2log2n2（2）程序容量V=Nlog2（n1+n2）（V为信息位的容量）（3）语言级别L=（2×n2）/（n1×n2）（4）程序工作量E=V/L（5）程序编写时间T=E/S（S为Stroud数，即人判断所需时间。一个清醒的人，每秒可进行5-20次的最基本判断）（6）程序潜在错误的数量B=Nlog2（n1+n2）/3000133软件工程讲义-3.McCabe复杂性量度（1976）McCabe认为程序的复杂性很大程度上取决于程序流的复杂性。单一的顺序程序结构最简单，循环和选择结构所构成的环路越多，程序就越复杂这种方法以图论为工具，先画出程序图，然后用该图的环路数作为该程序复杂性的量度值。对于具有强连通图的环路数V（G）可由下式给出：V（G）=e-n+2p其中：e图中的边数n图中的结点数p图中的联结成分的个数134软件工程讲义-McCabe复杂性量度（续）例：由上述计算方法可算得：V（G）=9-6+2=5这里选择的五个线性无关环路为（abefa）、（aeb）、（abea）、（acfa）、（adcfa）其它任何环路都是这五个环路的线性组合135软件工程讲义-McCabe复杂性量度（续）V（G）还可以用另外两种方法求得：（1）通过计算程序图中所有有界区域和无界区域数R来得到，所以V（G）为5（2）用判定语句的总数再加1来计算。这类复杂性是可加的，如单元A的复杂性为7（6个判定），单元B的复杂性为9（8个判定）。则单元A和单元B的复杂性为16。关于判定的个数计算，对多路分支语句（分情况语句）有如下约定：规定其判定个数为分支数减1，即一个具有5路分支的分情况语句只有4个判定。这样，上例中两个分情况语句可按4个判定来计算。所以，V（G）也为4+1=5McCabe建议：如果把具有多个分情况语句结构作为例外，在一个程序结构内，V（G）一般应控制在10以内，3-9的范围，则被认为是良好的结枸和恰当的复杂性。136软件工程讲义-4.功能点复杂性量度面向功能的度量是Albrecht，A.J1979年首先提出来的，使用软件所提供的功能作为规范值。因为，功能不能直接度量，必须通过其它直接的度量来间接地导出他建议的一种为功能点（functionpoint）的量度是基于软件信息域的可计算的（直接的）量度和软件复杂性的评估而给出的137软件工程讲义-功能点复杂度量度（续）功能点如何计算？根据国际功能点用户集团（InternationalFunctionPointUser’sGroup，IFPUG）制定的详细规则进行（图）。一般程序中有五个软件信息域特征。138软件工程讲义-功能点复杂度量度（续）（1）用户输入计算用户每个输入。它们向软件提供不同的面向应用的数据。输入应与查询分别计算（2）用户输出计算用户每个输出。软件向用户提供不同的面向应用的信息。这里是指报表、屏幕和出错信息等。一个报表中的单个数据项不单独计算。（3）交互查询

一个查询被定义为一次联机输入，它导致软件以联杌输出方式产生实时响应。每一个不同查询都要计算。（4）内部逻辑文件这里是指软件需要使用系统内部的逻辑文件。如数据库中部分数据或一个独立的文件。（5）外部逻辑文件这里是指机器的可读接口，利用这些接口可将信息从一个系统传送到另一个系统139软件工程讲义-功能点复杂度量度（续）有了上述五个特征的计算值，就可把每个计数与复杂性加权因子（按IFPUG制定的规则分高、中、低）相乘就可获得小计和总计。这样就可以得功能点总数按照IFPUG的规定：上面求出的功能点总数还要乘以一个根据整个系统复杂性而确定的因素影响值，对巳求出的功能点总数进行上调或下调，这样才能得到最终的功能点数140软件工程讲义-功能点复杂度量度（续）上、下调一般由下列十四个因素决定：（1）系统需要可靠的备份和恢复吗？（2）需要数据通信吗？（3）有分布处理功能吗？（4）性能很关键吗？（5）系统是否在一个现成的、重负的操作环境中运行？（6）系统需要联机数据登录吗？（7）联机数据登录是否需要在多屏幕或多操作之间切换以完成输入？（8）需要联机更新主文件吗？（9）输入、输出、文件或查询很复杂吗？（10）内部处理复杂吗？（11）代码需要被设为可重用的吗？（12）设计中需要包括转换和安装吗？（13）系统的设计需要支持不同组织的多次安装吗？（14）应用设计方便用户使用和修改吗？每个问题的回答可使用从0（不重要的）到5（绝对重要的）来确定，这样就可算出最终的功能点数。141软件工程讲义-功能点复杂度量度（续）最后，有了功能点的最终数，就可以计算出许多有用数据。这些数据是根据生产实际大量的统计数据，用最小二乘法拟合给出的估算公式：质量：必须纠正错误的数目=X1.25（个）人力资源：开发所需各类技术人员的总数=X/150（人）开发周期：完成任务所需的周期=X0.4（月）其中X为功能点的最终数。142软件工程讲义-功能点复杂度量度（续）例：一个检查英文单词拼写有否错误的程序输入文件：文件名称（检查拼写是否正确的文件）输出文件：三个输出：检查单词的总数；找出拼写的错误数；列出有错单词的表交互查询：用户可通过交互式询问，得到目前为止的处理单词的总数一个内部文件：词典。一个外部文件：需要检查的文件。这样程序共有1+3+1+1+1=7个特征。其二，根据每个特征的复杂性（低、中、高）而赋予不同的权重。根据IFPUG制定的详细规则，如果本例7个特征的复杂性均为中等，则其功能点加权和为40第三，总的功能点得数，根据软件系统复杂性而确定的因素，对功能点总数进行上下调后才能给出143软件工程讲义-功能点复杂度量度（续）从上可见，功能点量度的主要问题是如何计算一个要开发系统的功能点。它的好处是：如果一开始就确定了功能点，那么开发机构在未着手开始工作时，甚至一行代码都没有写出，就可以计算出我们所有感兴趣的有用数据。特别是这种方法可以定量计算从一些报导：一个字处理程序（435000行代码），约3500个功能点；一个日常事务处理程序（包括字处理、表处理、数据库应用、统计工具和其它专用程序等），其功能点超过25000个；一个一般的操作系统，其功能点多过10万个广心144软件工程讲义-（二）软件可靠性软件可靠性（Softwarer