1、第13章 软件度量,13.1 软件度量13.2 面向规模的度量 13.3 面向功能的度量13.4 软件质量的度量 13.5 在软件过程中集成度量数据 13.6 小结,13.1 软 件 度 量,图13.1 软件度量,在软件工程中，度量的方式分直接度量和间接度量两种：(1) 直接度量：对过程的直接度量包括度量投入的成本、完成的工作量等等；对产品的直接度量包括产生的代码行数LOC、文档的页数、缺陷数/千代码行、软件执行速度等等。,(2) 间接度量：软件的正确性、效率、可靠性、可维护性、可用性等难以直接度量。一般通过对其他项目直接度量的结果进行分析，获取对本项目的间接度量结果。软件度量的内涵及其种类可
2、以参见图13.1。生产率度量主要集中在软件工程过程的输出；产品质量度量反映产品满足用户需求的程度；技术度量主要集中在软件的一些技术特性上(如复杂度、聚合度、耦合度等等)。从另一个方面看，面向规模的度量用以收集与直接度量有关的软件工程输出的信息和质量信息；面向功能的度量提供直接度量的尺度；面向个人的度量收集个人工作方式与效率方面的信息。,13.2 面向规模的度量,表13.1 面向规模的度量数据样例,可以根据面向规模的基本度量数据作一些简单的计算分析，进行面向规模的生产率、质量和单位成本的间接度量，例如： 生产率 = KLOC/人月 质量 = 错误数/KLOC 单位成本 = 成本数 / KLOC,
3、坚持进行度量并记录度量结果，可以积累组织的历史数据财富。利用这样的历史数据，能够更科学地把握自己的工程能力，对以后的工程项目作出更为精确的估算。以KLOC为基本度量单位的面向规模的度量曾经发挥过很好的作用，但是也一直存在着争议。争议的焦点是千代码行KLOC作为关键度量准则的合理性。使用KLOC作为关键度量准则已经有大量的案例，并且许多著名的度量模型也直接以KLOC作为输入；但是，这种方法明显地不适应采用非过程化语言进行开发的实践，对于项目估算也存在一定的不便，因为在项目开发初期，也没有现成的KLOC数据可用。随着面向对象方法的应用，也有人提出了以系统的对象数作为基本度量单位进行规模度量的方法。
4、,13.3 面向功能的度量,面向功能的度量是对软件和软件开发过程的一种间接度量方法。这种方法并不把注意力集中在生产结果(KLOC)上，而是以未来软件应当满足的“功能性”、“实用性”作为度量的原始依据。因为“功能”不能直接度量，所以，必须通过其他直接的度量来导出。实用性要求在度量过程中被用作计算权值。面向功能的度量基本单位是“功能点”(FP)。计算方法参见图13.2，计算过程中的各参数解释如下：,(1) 用户输入数(EI)：每个EI应当是面向不同应用的输入数据。输入数据有别于查询数据，它们应当分别计数。(2) 用户输出数(EO)：各个EO应当是为用户提供的面向应用的输出数据。这里的输出是指报表、
5、屏幕信息、错误提示等等，报表中的各个数据项不再分别计数。(3) 用户查询(EQ)：EQ是一种联机输入，它引发软件以联机方式产生某种即时响应。每一种不同的查询都要计数。,(4) 内部逻辑文件(ILF)：每一个逻辑主文件都应当计数。所谓的逻辑主文件，是指逻辑上的一组数据组合。它们可以是数据库的一部分，也可以是一个单独的文件。(5) 外部接口(EIF)：对所有用来将信息传送到另一个系统中或从另一系统接收数据的接口均应计数。,图13.2 功能点度量的计算,通过对软件需求的分析，不难搜集到上述五类数据。之后就可以按照下式计算软件的功能点总数： FP = 总计数值 0.65+0.01Fi 其中，“总计数值
6、”是根据图13.2所计算出来的原始功能点数；Fi 是按照表13.2计算出来的系统难度系数。i的取值从114。SUM( )是求和函数。求得了FP值之后，就可以以它为基础，通过简单的计算，结合一些历史数据，间接地度量出软件的生产率、质量和其他一些属性。例如：,(1) 软件质量：每个功能点(FP)的缺陷数。 (2) 平均成本：每个功能点(FP)的成本。 (3) 文档规模：每个功能点(FP)的文档页数。 (4) 生产率：每个人月完成的功能点(FP)数。,表13.2 计算项目功能点数的难度校正系数值,表13.2 计算项目功能点数的难度校正系数值,功能点度量方法最适合于数据处理类软件的度量。它充分考虑了“
7、数据域”需求对功能点的影响，但是对“功能域”、“控制域”需求对功能点的影响没有考虑。不过，对它进行扩充之后，也可以应用于嵌入式软件、复杂计算软件和实时控制类软件的功能度量。“特征点”(FPs，Feature Points)度量方法就是一种扩充的功能点度量方法，适用于针对复杂计算软件进行功能度量。,在计算特征点的时候，首先按照上面计算功能点的方法对数据域度量参数进行加权计数。此外，特征点还要对软件的“算法”(一个特定计算机程序中包含的有界的计算问题)特征进行计数。计算特征点的方法如图13.3所示。从图13.3中可见，特征点度量的计算增加了“算法数”这一度量参数。具体的计算公式和功能点方法完全相同
8、。,图13.3 特征点度量的计算,Boeing提出了另一个专门用来对实时系统和工程产品进行功能度量的功能点扩展方法。它的特点是把数据域、功能域、行为域集成起来考虑，因此被称为3D功能点度量。这三个域的特性参数被计算、定量并被变换成度量值，以提供软件的功能指标。关于3D功能点度量的具体算法，可参考有关资料。LOC和FP都可以用作软件度量的基本单位，很多研究者试图将FP和LOC联系起来考虑。代码行和功能点度量之间的关系依赖于设计的质量和实现软件所用的程序设计语言。根据统计数据，表13.3列举出了在不同的程序设计语言中建造一个功能点平均所需要的代码行数的一个粗略估算。,表13.3 代码行-FP粗算,
9、13.4 软件质量的度量,软件的质量定义为“与软件产品满足规定的和隐含的需求能力有关的特征或特性的全体”(ANSI / IEEE Std 729-1983)。软件的质量特性可以定义为一种层次模型。ISO9000标准，中国国家软件产品标准中都对软件的质量及其度量要素进行了规定和描述。开发高质量的软件是所有开发者的共同愿望。如何评价、度量、控制软件质量是软件工程领域中极端重要的问题。软件质量包括软件过程质量(即过程能力)和软件产品质量两个范畴。这里主要讨论软件产品质量的度量。,软件产品的质量度量是一种保护性活动，贯穿于软件工程过程的始终。产品交付之前的质量度量为评价设计、编码、测试工作的好坏提供了
10、一个量化的根据。这一阶段的质量度量包括程序复杂性度量、模块有效性度量等等；软件交付之后，在运行维护阶段进行的度量主要关注软件中残存的差错数(反映可靠性)和系统的可维护性方面。,13.4.1 影响软件质量的因素软件质量是一个多因素的复杂混合，这些因素随着不同的应用和需要它们的用户而变化。概括地说，可以从三个方面来评估软件质量，即产品的运行(使用)、产品的修正(变更)和产品的转移(移植)，如图13.4所示。人们往往采用分层的结构来定义软件的质量模型(如图13.5所示)。顶层定义基本质量特征，比如正确性、可靠性等等；这些特征分别由下一层的子特性来定义和度量；子特性在必要时又可以由它的下级子特性描述和
11、度量。,图13.4 基于McCall模型的软件质量因素,图13.5 McCall质量度量模型框架,按照ISO/TC97/SC7/WG3/1985-1-30/N382，软件质量模型也由三层结构组成：高层(Top Level)：软件质量需求评价准则(SQRC)；中层(Mid Level)：软件质量设计评价准则(SQDC)；低层(Low Level)：软件质量度量评价准则(SQMC)。ISO组织认为，应对质量模型的高层建立国际标准，以便于在国际范围内推行软件质量管理(SQM)技术。中层的21项质量属性只作为推荐，不作为标准；而低层可由使用者自行确定。具体数据如下：,SQRC：功能性、可靠性、可维护性
12、、效率、可使用性、可移植性。SQDC：适合性、准确性、互用性、依从性、安全性、成熟性、容错性、可恢复性、可理解性、可学习性、可操作性、时间特性、资源特 性、可分析性、可变更性、稳定性、可测试性、适 应性、可安装性、一致性、可替换性。SQMC：软件开发组织根据自己的需要自行定义。,13.4.2 软件质量度量从软件质量的定义中就可以看出，度量软件质量的标准是用户对软件的需求，不符合需求的软件就不具备质量。在标准的软件工程过程中，定义了一系列的开发准则，用来指导软件人员用工程化的方法来开发软件，如果不遵循这些准则，软件质量就得不到保证。质量定义中所提到的“需求”，既包括已经明确定义了的需求，又包括隐
13、含的需求。因此，软件的可扩充性、可维护性就成了支持实现隐含需求的、十分重要的质量指标。度量软件产品的质量，除了要严格度量最终产品的质量之外，还应当包含对需求分析产品、设计产品、编码产品、测试产品等所有软件工作产品的全面度量。,软件质量的定性、定量度量，可以在开发过程中，结合针对各项技术产品的度量来进行。比如对需求分析产品的完备性，设计产品对需求项的覆盖程度，编码产品对设计的实现情况，测试用例对需求项的覆盖情况，体系结构设计的合理性，模块的聚合度、耦合度情况的度量，都可以作为间接的质量度量方法。在产品交付之后，也可以对产品质量进行事后评估。这时主要度量对象是通过搜集用户反馈信息得到的产品中残存的
14、缺陷数。在许多软件质量度量方法中，使用最广泛的是事后度量或验收度量，它包括对产品的正确性、可维护性、完整性和可用性的度量。Cilb提出了这些质量指标的定义和度量方法。,(1) 正确性：软件是否能正确地执行所要求的功能。可以用缺陷数/KLOC来度量；在产品交付后，根据标准的时间周期(一般为一年)，按照反馈的用户报告中的缺陷数进行度量。(2) 可维护性：利用平均变更时间MTTC(Mean Time To Change)间接度量软件的可维护性。,(3) 完整性：这个属性反映软件系统抗拒针对它的安全攻击(事故或人为)的能力。 完整性 = (1危险性(1安全性) 其中，危险性指一定时间内特定攻击发生的概
15、率，安全性是排除特定类型攻击的概率。两者都可以从估算或历史数据中得出。(4) 可用性：即“用户友好性”。可以从四个角度度量：学习应用软件所花费的代价；为达到有效使用软件所花费的时间；使用软件带来的生产率净增值；通过问卷调查得到的用户的主观评价。,13.5 在软件过程中集成度量数据,通过对软件生产率和软件质量的度量，管理者能够建立改进软件工程过程的目标。改进软件工程过程将对整个开发组织的工作产生直接的影响。从另一个角度来看，只有充分地了解工作能力的现状，才有可能确立正确的改进目标。因此，为了持续发展，必须通过对能力、效率、质量的度量进行度量数据的收集、计算与分析，并且将历史度量数据、当前度量数据
16、进行集成，建立工程过程的“度量基线”，利用基线来评估各类改进工作的效用，估算新项目的规模、工作量、预测成本、质量指标。,13.5.1 建立基线软件项目的管理者经常要考虑解决诸如进行有意义的项目估算、生产高质量的软件、保证按时交付产品之类的问题。这时他们当然需要了解“以前类似项目的估算结果是什么？”、“影响软件质量的主要问题在哪里？”和“本组织的实际生产效率究竟有多高？”等情况。如果他们在软件工程中使用了度量，搜集了以前的度量数据，对这些数据进行集成整合，建立了项目的“度量基线”数据库，就能够为解决上述问题起到积极的作用。度量数据的收集使得一个软件开发组织能够调整自身的软件工程过程，以排除那些对
17、软件开发有重大影响的错误产生的根源。,在项目级和技术级，软件度量能够提供立竿见影的好处。软件设计完成之后，大多数开发人员都希望能够了解哪些用户需求可能会变更？系统中哪些模块可能会容易出错？对每一个模块的测试要进行到什么程度？在测试开始时能够预计到将会出现多少特定类型的错误？如果在以前的工作实践中收集到了相关的度量数据并把它们当作估算的指南来使用，就能够确定这些问题的答案。度量基线由以往的软件开发项目收集到的度量数据构成。有人将其称之为“数字化的经验”。为了有助于估算、计划和质量控制，纳入基线的数据应当具有如下的属性：,(1) 数据必须是精确的、合理的。(2) 数据应当来自尽可能多的项目。(3)
18、 对于所有称为数据搜集对象的项目，对“代码行”、“功能点”等基本度量单位的解释都应当是一致的。(4) 在应用基线数据时，必须保证类型的匹配。比如，来自批处理项目的基线数据就不能用来指导针对实时项目的估算。建立基线，实际上就是集成了已有的度量数据。,13.5.2 度量数据的收集、计算和评价,图13.6 度量收集的过程,表13.4 面向规模的度量生产率和成本的度量数据项,表13.5 面向规模的度量质量的度量数据项,表13.6 面向功能的度量,13.6 小 结,本章介绍了软件度量的必要性、度量模式、度量方法、度量对象以及如何通过集成软件度量数据形成度量基线。度量使得管理者和开发者能够改善软件过程；辅
19、助制定软件项目的计划，对软件项目进行跟踪与监督控制，并能够评估产品质量。通过对过程、项目及产品的特定属性的度量结果进行分析，能够产生指导管理和技术行为的指标。,面向规模的度量和面向功能的度量是当前最常使用的两种度量方式。面向规模的度量是一种直接度量方式，采用千代码行KLOC作为其他度量的规范化因子。功能点度量方法是一种基于对信息域的间接度量和在对复杂度的主观评估中导出的算法。质量度量涵盖过程质量和产品质量两方面。就产品质量来说，用户需求是衡量它的惟一准则。要执行度量，则数据收集、度量计算和度量评价是必须执行的三个步骤。通过创建度量基线，工程师和管理者能够更好地了解他们所做的工作以及所开发的产品。,需要强调的是，必须善用度量数据。度量的目的是为了提升软件工程过程和软件产品的质量。不应当用一个项目组的生产率和另一个组的生产率数据进行对比，更不能以此来评价两个小组的绩效和个人的表现。因为影响生产率的因素很多，包括人的因素、问题因素、过程因素、产品因素、资源因素等等。简单地根据生产率度量数据对比来评定人员绩效是不公平的，这样做不但可能严重影响工程师的工作热情，还很可能会影响到今后度量数据的真实性。,
