软件工程中文讲义9

质量的度量。例如，可以根据表9.1对所有的项目计算出平均值：

生产率 ＝ KLOC／PM（人月） 成本 ＝ 元／LOC 质量 ＝ 错误数／KLOC 文档 ＝ 文档页数／KLOC (3) 面向功能的度量

面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量的关注点在于程序的“功能性”和“实用性”，而不是对LOC计数。一种典型的生产率度量法叫做功能点度量，该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能点FPs（Function Points）。

功能点通过填写表9.2所示的表格来计算。首先确定五个信息域的特征，并在表格中相应位置给出计数。信息域的值以如下方式定义：

? 用户输入数：各个用户输入是面向不同应用的输入数据，对它们都要进行计数。输入数据应有别于查询数据，它们应分别计数。

? 用户输出数：各个用户输出是为用户提供的面向应用的输出信息，它们均应计数。这里的输出是指报告，屏幕信息，错误信息等，在报告中的各数据项不应再分别计数。 ? 用户查询数：查询是一种联机输入，它导致软件以联机输出的方式生成某种即时的响应。每一个不同的查询都要计数。

? 文件数：每一个逻辑主文件都应计数。这里的逻辑主文件，是指逻辑上的一组数据，它们可以是一个大的数据库的一部分，也可以是一个单独的文件

? 外部接口数：对所有被用来将信息传送到另一个系统中的机器可读写的接口(即磁带或磁盘上的数据文件)均应计数。

表9.2 功能点度量的计算

信息域参数 用户输入数 用户输出数 用户查询数 文 件 数 外部接口数 总 计 数

计数 □□□ □□□ □□□ □□□ □□□

加 权 因 数

简单 3 4 3 7 5 中间 4 5 4 10 7

复杂 6 7 6 15 10

= = = = =

加权计数 □□□ □□□ □□□ □□□ □□□ □□□

? ? ? ? ?

一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值。使用功能点方法的机构要自行拟定一些准则以确定一个特定项是简单的、平均的还是复杂的。

计算功能点，使用如下的关系式：

FP ＝ 总计数×〔0.65＋0.01×SUM（Fi）〕 （9.1） 其中，总计数是由表9.2所得到的所有加权计数项的和；Fi（i = 1到14）是复杂性校正值，它们应通过逐一回答表9.3所提问题来确定。SUM（Fi）是求和函数。上述等式中的常数和应用于信息域计数的加权因数可经验地确定。

一旦计算出功能点，就可以仿照LOC的方式度量软件的生产率、质量和其它属性：

生产率 ＝ FP／PM（人月） 质量 ＝ 错误数／FP

表9.3 计算功能点的校正值

评定每个校正因素的尺度是0―5

成本 ＝ 元／FP

文档 ＝ 文档页数／FP

5

Fi 1 2 3 4 5 6 7 8 9 10 11 12 13 14

0 1 2 3 4 5

没有影响 偶然的 适中的 普通的 重要的 极重要的

系统是否需要可靠的备份和恢复？ 是否需要数据通信？ 是否有分布式处理的功能？ 性能是否是关键？

系统是否将运行在现有的高度实用化的操作环境中？ 系统是否要求联机数据项？

联机数据项是否要求建立在多重窗口显示或操作上的输入事务？ 是否联机地更新主文件？

输入、输出、文件、查询是否复杂？ 内部处理过程是否复杂？

程序代码是否要设计成可复用的？ 设计中是否包含变换和安装？

系统是否要设计成多种安装形式以安装在不同的机构中？ 应用系统是否要设计成便于修改和易于用户使用？

功能点度量是为了商用信息系统应用而设计的。Jones将其扩充，使这种度量可以被用于系统和工程软件应用，称之为特征点FPs（Feature Points）。特征点度量适合于算法复杂性高的应用。实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，适于特征点度量。 为了计算特征点，可以象上面描述的那样，对信息域值进行计数和加权。此外，需要对一个新的软件特征“算法”进行计数。可定义算法为“在一个特定计算机程序内所包含的一个有界的计算问题。”如矩阵求逆、二进位串转换为十进制数、处理一个中断等都是算法。计算特征点可使用如表9.4所示的表格。 对于每一个度量参数只使用一个权值，并且使用等式（9.1）来计算总的特征点值。

表9.4 特征点度量的计算

信息域参数 用户输入数 用户输出数 用户查询数 文 件 数 外部接口数 算 法 总 计 数 计数 □□□ □□□ □□□ □□□ □□□ □□□ ? ? ? ? ? ? 权值 4 5 4 7 7 3 = = = = = = 加权计数 □□□ □□□ □□□ □□□ □□□ □□□ □□□

必须注意，特征点与功能点表示的是同一件事：由软件提供的“功能性”或“实用性”。事实上，对于传统的工程计算或信息系统应用，两种度量会得出相同的FP值。在较复杂的实时系统中，特征点计数常常比只用功能点确定的计数高出20％到35％。

(4) 软件质量的度量

质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。在软件交付之前得到的度量提供了一个定量的根据，以做出设计和测试质量好坏的判断。这一类度量包括程序复杂性、有效的模块性和总的程序规模。在软件交付之后的度量则把注意力集中于还未发现的

6

差错数和系统的可维护性方面。特别要强调的是，软件质量的售后度量可向管理者和技术人员表明软件工程过程的有效性达到什么程度。

虽然已经有许多软件质量的度量方法，但事后度量使用得最广泛。它包括正确性、可维护性、完整性和可使用性。Gilb提出了它们的定义和度量。

① 正确性：一个程序必须正确地运行，而且还要为它的用户提供某些输出。正确性要求软件执行所要求的功能。对于正确性，最一般的度量是每千代码行(KLOC)的差错数，其中将差错定义为已被证实是不符合需求的缺陷。差错在程序交付用户普遍使用后由程序的用户报告，按标准的时间周期(典型情况是1年)进行计数。

② 可维护性：包括当程序中发现错误时，要能够很容易地修正它；当程序的环境发生变化时，要能够很容易地适应之；当用户希望变更需求时，要能够很容易地增强它。还没有一种方法可以直接度量可维护性，因此必须采取间接度量。有一种简单的面向时间的度量，叫做平均变更等待时间MTTC（Mean Time To Change)。 这个时间包括开始分析变更要求、设计合适的修改、实现变更并测试它、以及把这种变更发送给所有的用户。一般地，一个可维护的程序与那些不可维护的程序相比，应有较低的MTTC（对于相同类型的变更)。 ③ 完整性：这个属性度量一个系统抗拒对它的安全性攻击(事故的和人为的)的能力。软件的所有三个成分：程序、数据和文档都会遭到攻击。

为了度量完整性，需要定义两个附加的属性：危险性和安全性。危险性是特定类型的攻击将在一给定时间内发生的概率，它可以被估计或从经验数据中导出。安全性是排除特定类型攻击的概率，它也可以被估计或从经验数据中导出。一个系统的完整性可定义为：

完整性 ＝ ∑（1－危险性×（1－安全性）） 其中，对每一个攻击的危险性和安全性都进行累加。

④ 可使用性：即用户友好性。如果一个程序不具有“用户友好性”，即使它所执行的功能很有价值，也常常会失败。可使用性力图量化“用户友好性”，并依据以下四个特征进行度量：

? 为学习系统所需要的体力上的和智力上的技能；

? 为达到适度有效使用系统所需要的时间；

? 当软件被某些人适度有效地使用时所度量的在生产率方面的净增值； ? 用户角度对系统的主观评价(可以通过问题调查表得到)。

4、软件项目的估算

在做软件估算时往往存在某些不确定性，这将使得软件项目管理人员无法正常进行管理。因为估算是所有其它项目计划活动的基石，且项目计划又为软件工程过程提供了工作方向，所以我们不能没有计划就开始着手开发，否则将会陷入盲目性。 (1) 估算

估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。估算本身带有风险。增加风险的各种因素如图9.6所示。图中的轴线表示被估算项目的特征。

7

图9.6 估算与风险

项目的复杂性对于增加软件估算的不确定性影响很大。复杂性越高，估算的风险就越高。但是，复杂性是相对度量，它与项目参加人员的经验有关。例如，一个实时系统的开发，对于过去仅做过批处理应用项目的软件开发组来说是非常复杂的，但对于一个过去开发过许多高速过程控制软件的软件小组来说可能就是很容易的了。此外，这种度量一般用在设计或编码级，而在软件计划时(设计和代码存在之前)使用就很困难。因此，可以在计划过程的早期建立其它较为主观的复杂性评估，如功能点复杂性校正因素。

项目的规模对于软件估算的精确性和功效影响也比较大。因为随着软件规模的扩大，软件元素之间的相互依赖、相互影响程度迅速增加，因而估算的一个重要方法──问题分解会变得更加困难。由此可知，项目的规模越大，开发工作量越大，估算的风险越高。

项目的结构化程度也影响项目估算的风险。所谓结构性是指功能分解的简便性和处理信息的层次性。结构化程度的提高，进行精确估算的能力就能提高，而风险将减少。

历史信息的有效性也影响估算的风险。回顾过去，就能够仿效做过的事，且改进出现问题的地方。在对过去的项目进行综合的软件度量之后，就可以借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。

风险靠对不确定性程度定量地进行估算来度量，此外，如果对软件项目的作用范围还不十分清楚，或者用户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频频变动，增加估算的风险。计划人员应当要求在软件系统的规格说明中给出完备的功能、性能、接口的定义。更重要的是，计划人员和用户都应认识到经常改变软件需求意味着在成本和进度上的不稳定性。

(2) 软件的范围

软件项目计划第一项活动就是确定软件的范围。应当从管理角度和技术角度出发，确定明确的和可理解的项目范围，明确地给出定量的数据(如同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等)，指明约束条件和限制(如存储容量)。此外还要叙述某些质量因素(如给出的算法是否容易理解、是否使用高级语言等)。

软件范围包括功能、性能、限制、接口和可靠性。在估算开始之前，应对软件的功能进行评价，并对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常常采用某种程度的功能分解。性能的考虑包括处理和响应时间的需求。约束条件则标识外部硬件、可用存储或其它现有系统对软件的限制。

功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。功能、性能和约束是密切联系在一起的。

软件与其它系统元素是相互作用的。计划人员要考虑每个接口的性质和复杂性，以确定对开发资源、成本和进度的影响。接口的概念可解释为：

? 运行软件的硬件(如处理机与外设)及间接受软件控制的设备(如机器、显示器)； ? 必须与新软件链接的现有的软件(如数据库存取例程、子程序包、操作系统)； ? 通过终端或其它输入／输出设备使用该软件的人； ? 该软件运行前后的一系列操作过程。

对于每一种情况，都必须清楚地了解通过接口的信息转换。

软件范围最不明确的方面就是可靠性的讨论。软件可靠性的度量已经存在，但它们在项目的这个阶段难得用上。因此，可以按照软件的一般性质规定一些具体的要求以保证它的可靠性。

(3) 软件开发中的资源

软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。图9.7把软件开

8