第 4 章 软件过程和项目的度量

测度对于任何工程学科而言都是基本的，软件工程也不例外。 Lord
Kelvin 曾经说过： 当你能够测度你所说的，并将其用数字表达出来，你就对它有了一些了
解；但当你不能测度，不能用数字表达它时，你对它的了解就很贫乏、很不 令人满意：它可能是知识的开始，但你在思想上还远没有进入科学的阶段。 在过去十年中，软件工程界终于开始认可了 Lord Kelvin 的话。但并非
没有挫折，也不是只有一点点的争论。 软件度量是指计算机软件中范围广泛的测度。测度可以应用于软件过程
中，目的是在一个连续的基础上改进它。测度也可以用于整个软件项目中， 辅助估算、质量控制、生产率评估、及项目控制。最后，软件工程师使用测 度能够帮助评估技术工作产品的质量，且在项目进行中辅助决策。
　　在软件项目管理中，我们主要关心生产率和质量的度量——根据投入的 工作量和时间对软件开发“输出”的测度，对产生的工作产品的“适用性” 的测度。为了达到计划及估算的目的，我们的兴趣主要放在历史上。在过去 的项目中软件开发生产率是怎样的呢？产生的软件的质量是怎样的？如何从 过去的生产率及质量数据推断出现在的状况？过去的信息如何帮助我们更加 准确地计划和估算呢？
在本章中，我们主要探讨用于过程和项目级的软件度量。在后面的几章
中，我们将给出软件工程师在技术环境下使用的度量方法。

4.1 测度、度量和指标


　　虽然术语“measure”(测量)、“measurement”(测度)和“metrics”(度 量)经常被互换地使用，但注意到它们之间的细微差别是很重要的。因为 “measure”(测量)和“Measurement”(测度)即可以作为名词也可以作为动 词，所以它们的定义可能会混淆。在软件工程领域中，“measure”(测量) 对一个产品过程的某个属性的范围、数量、维度、容量或大小提供了一个定 量的指示。“Measurement”(测度)则是确定一个测量的行为。IEEE 的软件 工程术语标准辞典 (IEEE Standard Glossary of Software Engineering Terms)［IEE93］中定义“metric”(度量)为“对一个系统、构件或过程具有 的某个给定属性的度的一个定量测量”。
　　当获取到单个的数据点(如在一个模块的复审中发现的错误数)时，就建 立了一个测量。测度的发生是收集一个或多个数据点的结果(如调研若干个模 块的复审，以收集每一次复审所发现的错误数的测量)。软件度量在某种程度 上与单个的测量相关(如每一次复审所发现的错误的平均数，或复审中每人/ 小时所发现的错误的平均数)。
　　软件工程师收集测量结果并产生度量，这样就可以获得指标 “indicator”。指标是一个度量或度量的组合，它对软件过程、软件项目或 产品本身提供了更深入的了解［RAG95］。指标所提供的更深入的理解，使得 项目管理者或软件工程师能够调整开发过程、项目或产品，这样使事情进行 得更顺利，能被更好地完成。
例如，四个软件小组共同完成一个大型软件项目。每一个小组必须进行

技术复审，但允许其自行选择所采用的复审类型。检查度量结果——每人/ 小时所发现的错误数，项目管理者注意到采用更加正式的复审方法的两个小 组，每人/小时所发现的错误数比起另外两个小组高 40％。假设所有其他参 数都相同，这就给项目管理者提供了一个指标：正式的复审方法比起其他复 审方法在时间投资上能得到更大的回报。他可能会决定建议所有小组都采用 更加正式的方法。度量给管理者提供了更深入的理解，而更深入的理解会产 生更严谨、更正确的决策。

4.2 过程和项目领域中的度量


　　测度在工程界中是常事。我们测量动力消耗、重量、物理体积、温度、 电压、信号—噪音比??不胜枚举。不幸的是，在软件工程界测度还远未普 及。我们对于要测量什么及如何评估收集到的度量结果尚没有达成一致意 见。
　　应该收集度量，以确定过程和产品的指标。过程指标使得软件工程组织 能够洞悉一个已有过程的功效(如范型、软件工程任务、工作产品、及里程 碑)。它们使得管理者和开发者能够评估哪些部分可以运作，哪些部分不行。 过程度量的收集贯穿整个项目之中，并历经很长的时间。它们的目的是提供 能够导致长期的软件过程改善的指标。
项目指标使得软件项目管理者能够(1)评估正在进行的项目的状态；(2)
跟踪潜在的风险；(3)在问题造成不良影响之前发现问题；(4)调整工作流程 或任务；以及(5)评估项目组控制软件工程工作产品的质量的能力。
在某些情况下，可以采用同样的软件度量来确定项目的过程的指标。事
实上，项目组收集到的并被转换成项目度量的测量数据，也可以传送给负责 软件过程改进的人们。因此，很多同样的度量既用于过程领域又用于项目领 域。

4.2.1 过程度量和软件过程改进


　　改进过程的唯一合理的方法是测量过程的特定属性，基于这些属性开发 一组有意义的度量，而后使用这组度量来提供引导改进战略的指标。但是， 在我们讨论软件度量及它们对软件过程改进的影响之前，必须注意到过程仅 是众多“改进软件质量和组织性能的控制因素”中的一种［PAU94］。


　　在图 4－1 中，过程位于三角形的中央，并连接了三个对软件质量和组织 性能有重大影响的因素。人员的技能和激励被认为是对质量和性能最有影响 的因素［BOE81］。产品的复杂性对质量和小组性能产生相当大的影响。过程 中采用的技术(如软件工程方法)也有影响。除此之外，过程三角形存在于环 境条件的圆圈之内，这些条件包括：开发环境(如 CASE 工具)、商业条件(如 交付期限，商业规则)、及用户的特性(如通信的容易程度)。
　　我们间接地测量一个软件过程的功效。即，我们基于从过程中获得的结 果导出一组度量。这些结果包括：在软件发布之前发现的错误数的测量，交 付给最终用户并由最终用户报告的缺陷的测量，交付的工作产品的测量，花 费的工作量的测量，花费的时间的测量，与进度计划是否一致的测量，以及
　　
其他测量。我们还通过测量特定软件工程任务的特性来导出过程度量。例如， 我们可能测量第 2 章中描述的保护性活动及一般软件工程活动所花费的工作 量和时间。
　　Grady［GRA92］认为不同类型的过程数据可以分为“私有的和公用的”。 因为某个软件工程师可能对在其个人基础上收集的度量的使用比较敏感，这 是很自然的，这些数据对此人应该是私有的，并成为仅供此人参考的指标。 我们列举若干私有的度量数据：
·缺陷率(个人的。)
·缺陷率(模块的)。
·开发中发现的错误。
　　“私有过程数据”的观点与 Humphrey［HUM95］所建议的个人软件过程 (Personal SoftwareProcess)方法相一致。Humphrey 这样描述该方法：
　　个人软件过程(PSP)是一个过程描述、测度和方法的结构化集合，能够帮 助工程师改善其个人性能。它提供了表格、脚本和标准，以帮助工程师估算 和计划其工作。它显示了如何定义过程及如何测量其质量和生产率。一个基 本的 PSP 原则是：每个人都是不同的，对于某个工程师有效的方法不一定适 合另一个。这样，PSP 帮助工程师测量和跟踪他们自己的工作，使得他们能 够找到最适合自己的方法。
Humphrey 认识到软件过程改进能够、也应该开始于个人级。私有过程数
据是个体软件工程师改进其工作的重要驱动力。 某些过程度量对软件项目组是私有的，但对所有小组成员是公用的。例
如，主要软件功能(由多个开发人员完成)的缺陷报告、正式技术复审中发现
的错误、以及每个模块和功能的代码行或功能点(参见 4.3.1 和 4.3.2 节中关
于 LOC 及功能点度量的详细讨论)。这些数据可由小组进行复查，以找出能够 改善小组性能的指标。
公用度量一般吸取了原本是个人的或小组的私有信息。项目级的缺陷率
(肯定不能归因于某个个人)、工作量、时间及相关的数据被收集和评估，以 找出能够改善组织的过程性能的指标。
软件过程度量对于一个组织提高其总体的过程成熟度，能够提供很大的
帮助。不过，就像其他所有度量一样，它们也可能被误用，产生比它们解决 的问题更多的问题。Grady［GRA92］提出了一组“软件度量规则”，可用于 管理者建立过程度量计划：
·解释度量数据时使用通用的观念，并考虑组织的感受性。
·对收集测量和度量的个人及小组提供定期的反馈。
·不要使用度量去评价个人。
·与开发者和小组一起设定清晰的目标及达到这些目标的度量。
·不要用度量去威胁个人或小组。
　　·指出某个问题的度量数据不应该被看成是“否定的”含义。这些数据 仅仅是过程改进的指标。
·不要被某个与其他重要度量不符合的度量迷惑。 随着一个组织更加得心应手地收集和使用过程度量，简单的指标获取被
更加精确的方法所替代，该方法称为统计软件过程改进(statistical software process improvement，SSPI)。本质上，SSPI 使用软件故障分析 方法，来收集应用软件、系统或产品的开发及使用中所遇到的所有错误及缺

陷的信息①。故障分析采用如下方式：
　　1.根据来源分类所有的错误和缺陷(如，规格说明中的错误，逻辑错误， 与标准不符的错误等)。
2.记录修改每个错误和缺陷的成本。
3.统计每一类错误和缺陷的数目，并按降序排列。
4.计算每一类错误和缺陷的总成本。
5.分析结果数据，找出造成组织最高成本的错误和缺陷类型。
　　6.产生修正过程的计划，目的是消除(或降低其出现的频率)成本最高的 错误和缺陷类型。
由上述的第 1 步和第 2 步，能够得到一个简单的缺陷分布情况(如图 4－
2 所示)［GRA94］。图中的饼图显示了 8 种错误和缺陷的成因及来源(用阴影 表示)。Grady 提出一种鱼骨图的开发［GRA92］以帮助诊断饼图中的出错原 因。图 4－3 中其脊柱(中间那条线)表示要考虑的质量因素(本例中是指占总
数 25％的规约缺陷)。与脊柱相连的每一根肋骨(斜线)表示质量问题的一个 潜在原因(如遗漏了需求，有二义性的规约，不正确的需求，修改了的需求 等)。而后，每一根主要的肋骨上又可以加上新的脊柱和肋骨，以进一步标注 错误产生的原因。图 4－3 中仅给出“不正确的需求”这一项的发展过程。



　　过程度量的收集是创建鱼骨图的前提。通过分析一个完整的鱼骨图，可 以导出使得软件组织能够改进其过程以降低错误和缺陷率的指标。

4.2.2 项目度量


　　软件过程度量主要用于战略的目的。软件项目度量则是战术的。即，项 目管理者和软件项目组经过使用项目度量及从其中导出的指标，可以改进项 目工作流程和技术活动。
大多数软件项目中项目度量的第一个应用是在评估时发生的(第 5 章)。
从过去的项目中收集的度量可用来作为评估现在软件项目的工作量及时间的 基础。随着项目的进展，所花费的工作量及时间的测量可以和预评估值(及项 目进度)进行比较。项目管理者使用这些数据来监督和控制项目的进展。
随着技术工作的开始，其他项目度量也开始有意义了。生产率根据文档
的页数、复审的时间、功能点、及交付的源代码行数来测量。除此之外，对 每一个软件工程任务中所发现的错误也会加以跟踪。软件在从规格说明到设 计的演化中，需要收集技术度量(第 18 章)，以评估设计质量，并提供若干指 标，这些指标会影响代码生成及模块测试和集成测试所采用的方法。
项目度量的目的是双重的。首先，这些度量能够指导进行一些必要的调 整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少。其次， 项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术方 法以改进质量。
随着质量的提高，错误会减到最小，而随着错误数的减少，项目中所需



① 如我们在第 8 章所讨论的，错误是软件工程工作产品或交付物中的某个瑕疵，在该软件交付给最终用户
之前已被软件工程师发现。而缺陷则是交付给最终用户之后所发现的瑕疵。

的修改工作量也会降低。这就导致整个项目成本的降低。 软件项目度量的另一个模型［HET93］建议每个项目都应该测量：
·输入——完成工作所需的资源(如人员，环境)的测量。
·输出——软件工程过程中产生的交付物或工作产品的测量。
·结果——表明交付物的效力的测量。 实际上，这个模型既可以用于过程也可以用于项目。在项目范畴中，该
模型能够在每个框架活动发生时递归地使用。这样，一个活动的输出是下一 个活动的输入。结果度量能够用于提供关于工作产品有用性的指标，当这些 产品从一个框架活动(或任务)流动到下一个时。

4.3 软件测量


　　测量在现实世界中可分为两类：直接测量(如螺钉的长度)和间接测量(如 生产的螺钉的“质量”，由计算其次品率来测量)。软件测量也可以这样分类。 软件工程过程的直接测量，包括花费的成本和工作量。产品的直接测量， 包括产生的代码行(lines of code，LOC)、执行速度、内存大小及某段时间 内报告的缺陷。产品的间接测量，包括功能、质量、复杂性、有效性、可靠
性、可维护性及许多其他在第 18 章中讨论的“能力”。
　　我们已经把软件度量领域划分为过程、项目和产品度量。我们也已经注 意到：对个人私有产品的度量常常被结合起来，以形成对软件项目组公用项 目的度量。之后，项目度量又被联合起来产生对整个软件组织公用过程的度 量。但是，一个组织如何将来自不同个人或项目的度量结合起来呐？
为了说明这个问题，我们看一个简单的例子。分开两个不同项目组的个
人记录，并分类他们在软件工程过程中所发现的所有错误。之后，个人的测 量被结合起来产生项目组的测量。在发布前，项目组 A 在软件工程过程中发 现了 342 个错误，项目组 B 则发现了 184 个错误。所有其他情况都相同，哪 个组在整个过程中能够更加有效地发现错误呢？因为我们不知道项目的规模 或复杂性，所以我们不能回答这个问题。不过，如果度量采用规范化的手段，
就有可能产生能够在更大的组织范围内进行比较的软件度量。

4.3.1 面向规模的度量


　　面向规模的软件度量是通过规范化质量和/或生产率的测量而得到的，这 些测量基于所生产软件的“规模”。如果一个软件组织保持简单的记录，就 会产生一个如图 4－4 所示的面向规模测量的表。该表列出了在过去几年中完 成的每一个软件开发项目及其相关的测量。参考项目 alpha 表项(图 4－4)：
24 个人月的工作量，成本为 168000 美元，产生了 12100 行代码。应该注意 到表中记录的工作量和成本含盖了所有软件工程活动(分析、设计、编码及测 试)，而不仅仅是编码。项目 alpha 的更进一步的信息包括：产生了 365 页的 文档；在软件发布之前，发现了 134 个错误；软件发布给用户之后运行的第 一年中遇到了 29 个缺陷；3 个人参加了项目 alpha 的软件开发工作。

项目 LOC(代码行) 工作量 成本(千美元) 文档页数 错误 缺陷 人员
alpha 12100 24 168 365 134 29 3 beta 27200 62 440 1224 321 86 5 gamma 20200 43 314 1050 256 64 6 · · · · · · · · · · · · · · ·
图 4 － 4 面向规模的度量


　　为了产生可以与其他项目中同类度量相比较的度量，我们选择代码行作 为规范化值。根据表中所包含的基本数据，能够为每个项目产生一组简单的 面向规模度量：
·每千行代码(KLOC)的错误数。
·每千行代码(KLOC)的缺陷数。
·每行代码(LOC)的成本。
·每千行代码(KLOC)的文档页数。 除此之外，还能够计算出其他有意义的度量：
·每人月错误数。
·每人月代码行(LOC)。
·每页文档的成本。 面向规模的度量并不被普遍认为是测量软件开发过程的最好方法
［JON86］。大多数的争议都是围绕着使用代码行(LOC)作为关键的测量是否
合适。LOC 测量的支持者们声称 LOC 是所有软件开发项目的“生成品”，并 且很容易进行计算；许多现有的软件估算模型使用 LOC 或 KLOC 作为关键的输 入，并且已经有大量的文献和数据涉及到 LOC。另一方面，反对者们则认为 LOC 测量依赖于程序设计语言；它们对设计得很好，但较小的程序会产生不 利的评判；它们不适用于非过程语言；而且它们在估算时需要一些可能难以 得到的信息(如，早在分析和设计完成之前，计划者就必须估算出要产生的
LOC)。

4.3.2 面向功能的度量


　　面向功能的软件度量使用软件所提供的功能的测量作为规范化值。因为 “功能”不能直接测量，所以必须通过其他直接的测量来导出。面向功能度 量是由 Albrecht［ALB79］首先提出来的，他建议一种称为功能点的测量。 功能点是基于软件信息领域的可计算的(直接的)测量及软件复杂性的评估而 导出的。
　　功能点是通过完成图 4－5 所示的表计算出来的。其中确定了五个信息域 特性，并在表中合适的位置提供计算。信息域值按下列方式定义：(实际上， 信息域值的定义及计算方式很复杂。有兴趣的读者可以参考文献［IFP94］)。


　　用户输入数：计算每个用户输入，它们向软件提供面向应用的数据。输 入应该与查询区分开来，分别计算。
　　
　　用户输出数：计算每个用户输出，它们向用户提供面向应用的信息。这 里，输出是指报表、屏幕、出错信息，等等。一个报表中的单个数据项不单 独计算。
　　用户查询数：一个查询被定义为一次联机输入，它导致软件以联机输出 的方式产生实时的响应。每一个不同的查询都要计算。
　　文件数：计算每个逻辑的主文件(如数据的一个逻辑组合，它可能是某 个大型数据库的一部分或是一个独立的文件)。
　　外部接口数：计算所有机器可读的接口(如磁带或磁盘上的数据文件)， 利用这些接口可以将信息从一个系统传送到另一个系统。
　　一旦已经收集到上述数据，就将每个计数与一个复杂度值(加权因子)关 联上。采用功能点方法的组织建立一个标准以确定某个特定的条目是简单 的、平均的还是复杂的。不过，复杂度的确定多少有些主观。
我们采用下面的方式计算功能点：
FP=总计数值×［0.65＋0.01×ΣFi］
其中“总计数值”是从图 4-5 得到的所有条目的总和。
Fi(i=1 到 14)是基于对图 4-6 中问题的回答而得到的“复杂度调整值”
(0 到 5)。等式中的常数和信息域值的加权因子是根据经验确定的。



Fi：
1.系统需要可靠的备份和复原吗？
2.需要数据通信吗？
3.有分布处理功能吗？
4.性能很关键吗？
5.系统是否在一个已有的、很实用的操作环境中运行？
6.系统需要联机数据项吗？
7.联机数据项是否需要在多屏幕或多操作之间切换以完成输入？
8.需要联机更新主文件吗？
9.输入、输出、文件或查询很复杂吗？
10.内部处理复杂吗？
11.代码需要被设计成是可复用的吗？
12.设计中需要包括转换及安装吗？
13.系统的设计支持不同组织的多次安装吗？
14.应用的设计方便用户修改和使用吗？
　　一旦计算出功能点，则该以类似 LOC 的方法来使用它们，以规范软件生 产率、质量及其他属性的测量：
·每个功能点(FP)的错误数。
·每个功能点(FP)的缺陷数。
·每个功能点(FP)的成本。
·每个功能点(FP)的文档页数。
·每人月完成的功能点(FP)数。

4.3.3 扩展的功能点度量

　　功能点度量最初主要是用于商业信息系统应用软件中。为了适应这类应 用软件的需要，数据维(前面讨论的信息域值)强调了排除功能维及行为(控制) 维。因此，功能点度量不适合用于很多工程及嵌入式系统(它们强调了功能及 控制)。为了解决这种情况，又提出了许多对功能点度量的扩展。
　　其中一个功能点扩展，称为特征点［JON91］，是功能点度量的超集，能 够用于系统及工程软件应用程序中。特征点度量适用于算法复杂性较高的应 用程序。实时系统、过程控制软件及嵌入式软件都有较高的算法复杂性，因 此适合用特征点度量。
　　为了计算特征点，还要进行 4.3.2 节所述的信息域值的计算及加权。除 此之外，特征点度量增加了一个新的软件特性，即算法。算法定义为“特定 计算机程序中所包含的一个特定的计算问题”［JON91］。转置矩阵、一个位 解码串、或中断处理都是算法的例子。
　　另一个为实时系统和工程产品的功能点扩展是由 Boeing 提出的。Boeing 的方法是将软件的数据维与功能维及行为维集成起来考虑，以提供一个面向 功能的测量，称为 3D 功能点度量［WHI95］，它适用于强调功能及控制能力 的应用软件。这三个软件维的特性被“计算、定量及变换”成测量值，以提 供软件的功能指标。
数据维的评估基本采用 4.3.2 节描述的方法。计算获得数据(内部的程序
数据结构，如文件)和外部数据(输入、输出、查询、及外部引用)，并与复杂 度测量(加权因子)结合起来，导出数据维的计算。
功能维的测量是考虑“把输入变换成输出数据所需要的内部操作数”
［WHI95］。为计算 3D 功能点，一个“变换”被视为一系列由一组语义表示 的约束的加工步骤。一般情况下，一个变换是由一个算法来完成的，在处理 输入数据，并将其变换成输出数据的过程中，它导致输入数据的根本改变。 仅从一个文件中获取数据并简单地将其放到内存中的加工步骤并不是一个变 换，因为数据本身并没有发生根本的改变。
为每个变换赋复杂度值是加工步骤数及控制加工步骤的语义语句数的一
个函数。表 4-1 给出了在功能维中分配复杂度值的指导原则。
表 4-1 确定 3D 功能点中一个变换的复杂度值



加工步骤

语义语句

1 ～ 5 6 ～ 10 11+

1 ～ 10 低 低 平均 11 ～ 20 低 平均 高 21+ 平均 高 高



控制维的测量是计算状态之间的变迁数(关于行为维的更详细的讨论将
在第 12 章中给出，包括状态及状态变迁)。一个状态代表某种外部可见的行 为模式，一个变迁是某个事件的结果，该事件引起软件或系统改变其行为模 式(即改变状态)。例如，蜂窝电话包含支持自动拨号功能的软件。要从 resting(休眠)状态进入 auto-dial(自动拨号)状态，用户需按下键盘上的 Auto(自动)键。这个事件将产生一个 LCD 显示，提示输入呼叫方的号码。输 入号码并按下 Dial(拨号)键(另一个事件)，蜂窝电话软件就产生一个到 dialing(正拨号)状态的变迁。当计算 3D 功能点时，变迁并不被赋予复杂度

值。
采用下面的方法计算 3D 功能点：
3D 功能点指数=I+O+Q+F+E+T+R
　　其中 I、O、Q、F、E、T 及 R 分别代表前面讨论的元素的复杂度加权值： 输入、输出、查询、内部数据结构、外部文件、变换及变迁。每一个复杂度 加权值采用下面的方法计算：
复杂度加权值=NilWil+NiaWia+NihWih
其中 Nil、Nia 和 Nih 表示元素 i(如输出)在每一个复杂度级别上(低、平
均、高)发生的次数；Wil、Wia 和 Wih 则表示相应的权值。整个 3D 功能点的计
算如图 4-7 所示。


　　应该注意：功能点、特征点及 3D 功能点都代表同一种事物——软件提供 的“功能”或“效用”。事实上，如果仅考虑应用软件的数据维的话，这些 度量都得到同一个结果。对于更为复杂的实时系统，特征点计算的结果一般 比仅仅使用功能点计算得到的结果高出 20％～35％。
　　功能点(及其扩展)，像 LOC 度量一样，也有很大争议。支持者们认为 FP 与程序设计语言无关，使得它既适用于传统的语言，也可用于非过程语言； 它是基于项目开发初期就有可能得到的数据，因此 FP 作为一种估算方法更具 吸引力。反对者们则声称该方法需要某种“人的技巧”，因为计算是基于主 观的而非客观的数据，信息域(及其他维)的计算可能难以收集事后信息，FP 没有直接的物理含义，它仅仅是一个数字而已。

4.4 调和不同的度量方法


　　代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语言 及设计的质量。很多研究试图将 FP 和 LOC 联系起来考虑。引用 Albrecht 和 Gaffney［ALB83］的话说：
本研究的论点是：应用(程序)所提供的功能数能够从所使用的数据的主
要组成部分的详细记录中估算出来，或是直接从记录中得到。更进一步，功 能的估算应该与要开发的 LOC 数及开发所需的工作量关联起来。
表 4-2［ALB83，JON91］给出了在不同的程序设计语言中建造一个功能
点所需的平均代码行数的一个粗略估算：


表 4-2 程序设计语言代码行粗算
程序设计语言 LOC/P(平均值) 程序设计语言 LOC/FP(平均值) 汇编语言 320 面向对象语言 30 C 128 第四代语言(4GLs) 20 Cobol 105 代码生成器 15 Fortran 105 电子表格 6 Pascal 90 图形语言(图标) 4 Ada 70
　　查看上表可知，Ada 的一个 LOC 所提供的“功能性”大约是 Fortran 的 一个 LOC 的 1.4 倍(平均讲)。而 4GL 的一个 LOC 所提供的“功能性”大约是 传统程序设计语言的一个 LOC 的 3 到 5 倍。FP 与 LOC 之间关系的更详细的数 据可以参见文献［JON91］，且这些数据可以用来从已有的程序中“逆向”确
定 FP 度量(即，在已经知道交付的 LOC 数时来计算功能点数)。
　　LOC 和 FP 度量常常用于导出生产率度量。这就引起关于这类数据使用的 争论。是否应该将某个组的 LOC/人月(或 FP/人月)与另一个组的同类数据进 行比较？管理者是否应该根据这些度量来评价个人的表现？这些问题的答案 毫无疑问是一个“不”字。这个回答的理由在于很多因素都会影响生产率， 进行“苹果与桔子”的比较(不能比较)很容易产生曲解。
Basili 和 Zelkowitz［BAS78］定义了五个影响软件生产率的重要因素： 人因素：开发组织的规模和专业技能。 问题因素：待解决问题的复杂性及设计约束或需求的改变次数。 过程因素：使用的分析及设计技术，可用的语言及 CASEE 工具，以及复
审技术。 产品因素：基于计算机系统的可靠性及性能。
资源因素：CASE 工具、硬件及软件资源的可用性。 对于一个给定项目，如果其中任何一个生产率因素高于平均值(有利
的)，则软件开发生产率将明显高于该因素低于平均值的情况。

4.5 软件质量度量


　　软件工程的最高目标就是产生高质量的系统、应用软件或产品。为了达 到这个目标，软件工程师必须掌握在成熟的软件过程背景下有效的方法及现 代化的工具的应用。除此之外，一个优秀的软件工程师(及优秀的软件工程管 理者)必须评估是否能够达到高质量的目标。
一个系统、应用软件或产品的质量依赖于问题需求的描述、解决方案的
建模设计、可执行程序的编码的产生、以及为发现错误而运行软件的测试。 一个优秀的软件工程师使用度量来评估软件开发过程中产生的分析及设计模 型、源代码和测试用例的质量。为了实现这种实时的质量评估，工程师们必 须采用技术度量(第 18 章和 23 章)来客观地评估质量，而不能采用主观的方 法进行评估。
在项目进展过程中，项目管理者也必须评估质量。个体软件工程师所收
集的私有度量可用于项目级信息的提供。虽然可以收集到很多质量测量，在 项目级最主要的还是错误和缺陷测量。从这些测量中导出的度量能够提供一 个关于个人及小组的软件质量保证指标及控制活动效率的指标。
　　复审中每小时所发现的错误及测试中每小时所发现的错误，使我们能够 洞悉度量所指的那些活动的功效。错误数据也能够用于计算每个过程框架活 动的缺陷排除效率(DRE，DRE 也能够用于评估在整个过程中质量保证活动的 影响)。DRE 将在 4.5.3 节讨论。

4.5.1 概述影响质量的因素

二十多年前，McCall 和 Cavano［MCC78］定义了一组质量因素，这是走

向用软件质量度量开发的第一步。这些因素从三个不同的视点来评估软件： (1)产品的操作(使用它)，(2)产品的修改(改变它)，及(3)产品的转换(修改 它使之能够用于另一个环境，即“移植”它)。在他们的工作中，作者给出了 这些质量因素(他们称之为“框架”)与软件工程过程其他一些方面之间的关 系：
　　首先，框架为项目管理者提供了一个机制，以标识哪些质量因素最重要。 除了软件功能的正确性和性能之外，这些质量因素也都是软件的属性，在生 命周期中有重要意义。一些因素，诸如可维护性及可移植性，近年来已显示 出对整个生命周期的成本有重要影响。
　　其次，框架提供了定量评估相对于已建立的质量目标而进行的，开发进 展得如何的方法。
　　再者，框架在整个开发工作中，提供了更多的 QA(质量保证)人员之间的 交互。
　　最后，质量保证人员能够利用低质量的指标去帮助确定将来要增强的更 好的标准。
　　对 McCall 和 Cavano 提出的框架的更详细的讨论，以及其他质量因素， 将在第 18 章给出。有趣的是，自从 McCall 和 Cavano 在 1978 年完成他们的 最初工作之后，几乎关于计算的每一个方面都发生了根本的改变，但提供软 件质量指标的属性仍然没有改变。
这意味着什么呢？如果一个软件组织采用一组质量因素作为评估软件质
量的一个“清单”，那么就有可能今天建造的软件一直到 21 世纪的头几十年 仍展现出良好的质量。即使计算的体系结构发生了根本的改变(事实上也肯定 会)，在操作、修改和转换上表现出高质量的软件仍会继续给用户提供很好的 服务。

4.5.2 测量质量


　　虽然有很多软件质量的测量方法，但对软件进行正确性、可维护性、完 整性、及可用性的测量为项目组提供了有用的技术指标。Gilb［GIL88］给出 了这些属性的定义及测量。
正确性：一个程序必须能够正确操作，否则对于用户就没有价值了。正
确性是软件完成所需的功能的程度。关于正确性的最常用的测量是每千行 (KLOC)的缺陷数，这里缺陷定义为验证出的与需求不符的地方。
　　可维护性：软件维护所占的工作量比任何其他软件工程活动都大。可维 护性是指遇到错误时程序能被修改的容易程度；环境发生变化时程序能够适 应的容易程度，用户希望改变需求时程序能被增强的容易程度。可维护性无 法直接测量；因此，我们必须采用间接测量。一个简单的面向时间的度量是 平均修改时间(mean-time-to-change，MTTC)，即分析改变的需求设计合适的 修改方案实现修改测试，并将修改后的结果发布给用户所花的时间。一般情 况下，可维护的程序与不可维护的程序相比，有较低的 MTTC(相对于同类修 改而言)。
Hitachi［TAJ81］使用一种面向成本的可维护性度量，称为“损坏度”
——在软件发布给其最 终用户之后修改所遇到的缺陷的成本。如果用损坏度 与整个项目成本(对于许多项目)的比作为时间的函数，管理者就能够据此来

确定一个软件开发组织所产生的软件的总体可维护性是否有所改进。而后管 理者便可以根据这个信息采取相应的行动。
　　完整性：在黑客及病毒横行的现在，软件完整性已变得日益重要。这个 属性测量系统在安全方面的抗攻击(包括偶然的和蓄意的)能力。攻击可能发 生在软件的三个主要成分上：程序、数据及文档。
　　为了测量完整性，必须定义两个附加的属性：威胁和安全性。威胁是某 个特定类型的攻击在给定时间内发生的可能性(能够根据经验估算或推断出 来)。安全性是某个特定类型的攻击将被击退的可能性(也能够根据经验估算 或推断出来)。一个系统的完整性可以定义为：
完整性=Σ［1—威胁×(1—安全性)］ 这是威胁及安全性针对每种类型的攻击求和。 可用性：在对软件产品的讨论中，“用户友好性”这个词已经是普遍存
在的。如果一个程序不是“用户友好的”，那么它是注定会失败的，即使它 所完成的功能很有价值。可用性试图量化“用户友好性”，并根据四个特性 来测量：(1)学会一个系统所需的体力的和/或智力的投入；(2)在系统的使用 上达到中等效率所需的时间；(3)当系统由某个具有中等效率的人使用时，测 量到的生产率的净增长(与被该系统替代的老系统相比)；以及(4)用户对系统 的态度的一个主观评估(有时可以通过调查表获得)。关于本话题的更详细的 探讨参见第 14 章。
上述的四个因素仅仅是被建议作为软件质量测量的众多因素中的一个样
板。第 18 章将给出更多的信息。

4.5.3 缺陷排除效率


　　缺陷排除效率(DRE)在项目级和过程级都能提供有益的质量度量。本质 上，DRE 是对质量保证及控制活动的过滤能力的一个测量，这些活动贯穿于 整个过程框架活动。
当把一个项目作为一个整体来考虑时，DRE 按如下方式定义：
DRE=E/(E＋D)
其中 E=软件交付给最终用户之前所发现的错误数 D=软件交付之后所发现的缺陷数
最理想的 DRE 值是 1，即软件中没有发现缺陷。现实中，D 会大于 0，但
随着 E 值的增加，DRE 的值仍能接近 1。事实上，随着 E 的增加，D 的最终值 可能会降低(错误在变成缺陷之前已经被过滤了)。如果 DRE 作为一个度量， 提供关于质量控制和保证活动的过滤能力的衡量指标，则 DRE 鼓励软件项目 组采用先进技术，以便在交付之前发现尽可能多的错误。
　　DRE 也能够用来在项目中评估一个小组发现错误的能力，在这些错误传 递到下一个框架活动或软件工程任务之前。例如，需求分析任务产生了一个 分析模型，可以复审该模型以发现和改正错误。在对分析模型的复审中未被 发现的错误会传递给设计任务(在这里它们有可能被发现，也有可能没被发 现)。在这种情况下，我们定义 DRE 为：
DREi=Eil(Ei＋Ei＋1)
其中 Ei=在软件工程活动 i 中所发现的错误数

　　Ei＋1=在软件工程活动 i＋1 中所发现的错误数，这些错误来源于软件工 程活动 i 中未能发现的错误。
一个软件项目组(或单个软件工程师)的质量目标是使 DREi 接近 1。即，
错误应该在传递到下一个活动之前被过滤掉。

4.6 在软件过程中集成度量


　　大多数软件开发者仍然没有进行测量，更可悲的是，他们中大多数根本 没有开始测量的愿望。正如我们在本章开始所说的，这是文化的问题。试图 收集过去从来没有人收集的测量常常会遇到阻力。迷惑不解的项目管理者问 “为什么我们要做这个？”。工作过度的开发者抱怨“我看不出这样做有什 么用”。
　　为什么测量软件工程过程及其产生的产品(软件)如此重要？答案其实很 明显。如果我们不进行测量，就没法确定我们是否在改进。如果我们没有改 进，那就等于失败了。
　　测量是可以帮助解决第 1 章中所述的“软件苦恼”的若干“良药”中的 一种。它能够提供战略级、项目级及技术级上的利益。
通过请求和评估生产率及质量的测量，高级管理者能够建立有意义的目
标来改进软件工程过程。在第 1 章，我们注意到软件对于许多公司而言是一 个战略性的商业事务。如果开发软件的过程能够有所改进，就会对基层产生 直接的影响。但要建立改进的目标，必须了解软件开发的当前状态。因此， 用测量建立一个过程的基线，并基于此来评估改进的效用。
软件项目工作的日益繁重使得几乎没有时间去进行战略性的思考。软件
项目管理者更关心现实的问题(当然这也同样重要)：有意义的项目估算；高 质量系统的产生；产品按时交付等。通过使用测量来建立项目基线，使得这 些问题更加容易管理。我们已经知道基线是估算的基础，此外，质量度量的 收集使得一个组织能够“调整”其软件工程过程，以排除引起对软件开发有 重大影响的缺陷的“致命”原因，(这些想法已被归纳为一个方法，称为统计 软件质量保证，将在第 8 章详细讨论)。
在项目级和技术级，软件度量能够提供立即可见的好处。软件设计完成
后，大多数开发者都急于知道以下问题的答案：
·哪些用户需求最有可能发生改变？
·本系统中哪些模块最易于出错？
·对于每一个模块需要设计多少测试？
·当测试开始时，预计会有多少错误(特定类型的)？ 如果度量已经被收集并被用作一项技术指南，这些问题的答案就能够确
定了。在后面的章节中我们还要讨论这是如何做到的。
　　建立基线的过程如图 4-8 所示(度量的基线是由从以前的软件开发项目 中收集的数据所组成的，这些数据可以像图 4-4 给出的表那么简单，也可以 是复杂的综合数据库，其中包含几十个项目测量及从其导出的度量)。理想情 况下，建立基线所需的数据是以一种渐进的方式收集的。但遗憾的是，很少 能做到这样。因此，数据收集需要对以前的项目进行历史的调查，以重建所 需的数据。一旦收集好了测量(无疑这是最困难的第一步)，就有可能进行度 量计算。依据所收集的测量的广度，度量可以跨越 LOC 或 FP 度量及其他面向
　　
质量和项目的度量。最后，度量必须在估算、技术工作、项目控制及过程改 善中加以评估和使用。度量评估主要是分析产生所得到的结果的原因，并生 成一组指导项目或过程的指标。



4.7 小结


　　测量使得管理者和开发者能够改善软件过程；辅助软件项目的计划、跟 踪及控制；评估产生的产品(软件)的质量。对过程、项目及产品的特定属性 的测量被用于计算软件度量。分析这些度量可产生指导管理及技术行为的指 标。
　　过程度量使得一个组织能够从战略级洞悉一个软件过程的功效。项目度 量是战术的，使得项目管理者能够以实时的方式改进项目的工作流程及技术 方法。
　　产业界普遍使用面向规模和面向功能的度量。面向规模的度量使用代码 行作为其他测量，如人月或缺陷的规范化因子。功能点则是从信息域的测量 及对问题复杂度的主观评估中导出的。
软件质量度量，如生产率度量，集中于过程、项目及产品上。通过建立
和分析质量的度量基线，一个组织能够采取行动来纠正引起软件缺陷的那些 软件过程区域。本章中讨论了四个质量度量——正确性、可维护性、完整性 及可用性。其他的质量度量将在本书后面的章节中探讨。
测量导致文化的改变。如果打算开始进行度量，则数据收集、度量计算
及度量评估是必须执行的三个步骤。通过创建一个度量基线(一个包含过程及 产品测量的数据库)软件工程师及管理者能够更好地了解他们所做的工作及 所开发的产品。



思考题

4.1 给出可以用以评估一辆汽车的三个测量、三个度量及相应的指标。
　　4.2 给出可以用以评估一个汽车经销商的服务部门的三个测量、三个度 量及相应的指标。
4.3 用自己的话描述过程和项目度量之间的不同。
　　4.4 为什么某些软件度量是“私有的”？给出三个私有度量的例子，并 给出三个公用度量的例子。
4.5 阅读［HUM95］，并写出一个 1 到 2 页的总结简述 PSP 方法。
　　4.6 Grady 提出了一组“软件度量规则”。你能够在 4.2.1 节所列的规 则中再增加三个吗？
　　4.7 试着完成图 4-3 所示的鱼骨图。即，按照“不正确的”规格说明所 使用的方法，为“遗漏的”需求，“有二义性的”规格说明，及“改变的” 需求提供类似的信息。
4.8 什么是间接测量？为什么在软件度量工作中经常用到这类测量？
4.9 产品交付之前，小组 A 在软件工程过程中发现了 342 个错误。小组
B 发现了 184 个错误。对于项目 A 和 B 还需要做哪些额外的测量，才能确定

哪个小组能够更有效地排除错误？你建议采用什么度量来帮助做决定？哪些 历史数据可能有用？
　　4.10 给出一个反对代码行作为软件生产率度量的论据。当考虑几十个或 是几百个项目时，你说的情况还成立吗？
4.11 根据下面的信息域特性值，计算项目的功能点值： 用户输入数：32
用户输出数：60 用户查询数：24 文件数：8 外部接口数：2
　　假设所有的复杂度调整值都是“平均”。假设共有 14 个算法，计算特征 点值。
4.12 计算一个嵌入式系统的 3D 功能点值，它具有下面的特性值： 内部数据结构：6
外部数据结构：3 用户输入数：12 用户输出数：60 用户查询数：9 外部接口数：3 变换：36 变迁：24
假设以上计数的复杂度平均分布为低、平均和高。
　　4.13 用于控制先进的影印机的软件需要 32，000 行 C 语言代码和 4200 行类 4GL 描述语言。估算该影印机软件的功能点数。
4.14 McCall 和 Cavano(见 4.5.1 节)为软件质量定义了一个“框架”。
根据本书及其他书籍中提供的信息，分别将三个主要的“视点”展开为一组 质量因素及度量。
4.15 为正确性、可维护性、完整性、及可用性建立你自己的度量(不要
使用本章给出的度量)。确定它们能够转换成定量的值。
4.16 当每千行缺陷数降低时，“损坏度”有可能提高吗？为什么？
4.17 当使用第四代语言时，LOC 测量还有意义吗？为什么？
　　4.18 写一篇文章概述软件生产率研究的结果(参见推荐文献)。这些结果 之间有共同之处吗？
　　4.19 收集 2 到 5 个你参加的项目的软件度量。基本的信息应该包括：成 本，LOC 或功能点，工作量(人月)，复杂度指标(从 1 到 10)，及完成时间。 将你的数据与其他同学或同事的信息结合起来，建立并检查班级的度量基 线。
　　4.20 收集能够用于向管理部门证明测量是有价值的活动的资料，写出一 份报告，注意使用定量的论据，并将在班上报告结果。

推荐阅读文献及其他信息源


　　软件过程改进近年来得到极大关注。Humphrey［HUM95］、Yeh(软件过程 控制，SoftwareProcess Control，McGraw-Hill，1993)，Hetzel［HET93］，
　　
以及 Grady［GRA92］的著作都探讨了如何使用软件度量来提供必要的指标， 以改善软件过程。 Putnam 和 Myers(Executive Briefing：Controlling Software Development，IEEE Computer Society，1996)，以及 Pulford 和 其同事们 (AQuantitative Approach to Software Management，Addison- Wesley，1996)则从管理的视点探讨了过程度量及其使用。
　　Weinberg(Quality Software Management ， Volume 2： First Order Measurement，Dorset House，1993)提出了一个有用的模型，能够观察软件 项目，确定观察结果的含义，并决定其对战略及战术决策的重要性。Garmus
和 Herron(Measuring the Software Process，Prentice-Hall，1996)讨论 了过程度量，重点放在功能点分析上。软件生产力协会，(The Software Measurement Guidebook，Thomson Computer Press，1995)对于如何建立有 效的度量方法提出了有用的建议。
　　在过去十年中，国防部及政府/企业的研究中心出版了很多企业的报告及 度量指南。主要包括：
Andres，D.，Software Project Management Using Effective Process
Metrics：The CCPDS-R Experience，TRW-TS-89-01，TRW Systems Engineering
＆ Development Division，November 1989.
　　Carleton，A.D.et al.， Software Measurement for DoD Systems： Recommendations for Initial Core Measures ， CUM/SEI-92-TR-19 ， Carnegie-Mellon University ， Software Engineering Institute ， September 1992.
Florac ， W.A.,Software Quality Measurement ： A Framework for
Counting Problems and Defects ，CMU/SEI-92-TR-22， Carnegie-Mellon
University，Software Engineering Institute， September 1992.
Metrics Reporting Guidebook，Version 1.1，Defense Information
Systems Agency， prepared by Mitre Corp.，May 1994.
Metrics Starter Kit and Guidelines，Software Technology Support
Center，Hill AFB，UT，1994.
　　在 Internet 上，关于软件度量的报告及信息索引可在软件工程实验室 (Software EngineeringLaboratory)的网站上找到：
http：//fdd.gsfc.nasa.gov/seltext.html
　　美国军方的软件度量系统网站(Software Metrics System Web)上包含很 多关于过程度量的信息：
http：//www.army.mil/optec-pg/homepage.htm 关于过程度量的大量教科书及文章的目录可在下面的网址上找到： http：//www.rai.com/soft-eng/sme.html
　　已经建立了一个 Listserv 邮件列表，能够获得功能点度量的信息。如果 想订阅，发 mail 给：cim＠crim.ca
SUBJECT：“”(这个域必须是空的)
CONTENT：SUB FUNCTION.POINT.LIST“你的名字” 一个最新的关于软件过程度量的 WWW 参考目录可在下面的网址上找到：
http：//www.rspa.com

第 5 章 软件项目计划


　　软件项目管理过程从一组被称为项目计划的活动开始。这些活动中的第 一个是估算。无论何时进行估算，我们都是在预测未来，并会接受某种程度 的不确定性。引用 Frederish Brooks［BRO75］的话来说：
　　我们的估算技术发展缓慢。更为严重的是，它们隐含了一个很不正确的 假设，即“一切都会好的”??；因为我们对自己的估算没有把握，软件管 理者常常缺少让人们得到一个好产品的信心。
　　虽然估算是一门科学，但它更是一门艺术，可这个重要的活动不能以随 意的方式来进行。对时间及工作量进行评估的有用技术确实存在。而且因为 估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件 工程的行车图，因此，没有它我们就会搭错车。

5.1 对估算的观察


　　一位总经理曾经被问到：在选择一个项目管理者时，什么特质是最重要 的。他的回答是：“具有在错误真正发生之前就能知道它的能力”。我们还 可以加上：“在未来还是一团迷雾的时候就有勇气进行估算”。
估算一个软件开发工作的资源、成本及进度需要经验、需要了解以前的
有用信息、以及当仅存在定性的数据时进行定量测量的勇气。估算具有与生 俱来的风险(风险分析技术在第 6 章讨论)，而正是这种风险导致了不确定 性。
项目复杂性对计划中固有的不确定性产生重大影响。不过，复杂性是一
个受到对以前工作的熟悉程度影响的相对的测量。实时应用对于一个以前仅 仅开发过批处理应用的软件项目组而言，可能被认为是“非常复杂的”。同 样的实时应用对于一个经常开发高速处理控制的软件项目组而言，则可能被 认为是“小菜一碟”。目前已经有一些定量的软件复杂性测量(第 18 章和 23 章)。这类测量主要用于设计级及代码级，因此难以在软件计划中(它在设计 及编码之前)使用。不过，关于复杂性的其他一些更为主观的评估(如，第 4 章描述的功能点复杂度调整因子)可以在早期的计划过程中建立。
项目规模是另一个影响估算准确性的因素。随着规模的增长，软件中各
个元素之间的相互依赖性也迅速增加(项目规模的增长会对项目的成本及进 度产生几何级数级的影响［MAH96］。估算中采用的重要方法——问题分解， 也因为分解出来的元素仍然很大而变得更为困难。改写 Murphy 定律：“所有 可能出错的地方都会出错”——如果有更多的部分可能失败，那就会有更多 的部分失败。
　　结构不确定性的程度也会对估算的风险产生影响。在这里，结构是指： 需求能被确定的程度，功能能被分解的容易程度，以及必须要加工的信息的 层次性。
　　历史信息的可用程度也决定了估算的风险。Santayana 曾经说过：“不 记得过去的人必将重蹈覆辙”。通过回顾过去，我们能够效法好的地方，且 避免再出现同样的问题。当存在大量可用的关于过去项目的软件度量时(第 4 章)，估算就会有更大的保证；能够建立进度计划，以避免以前遇到过的困难； 总体风险也会降低。
　　
　　风险是由为资源、成本及进度建立的定量估算中存在的不确定性来测量 的。如果对项目范围理解很差或项目需求不断变化，不确定性及风险就会很 高。软件计划者应该要求功能、性能及接口定义(包含在系统说明中)的完备 性。计划者，尤其是用户，应该认识到软件需求的变化意味着成本及进度的 不稳定。
　　作为对估算的最后一个观察，我们引用亚里斯多德(公元前 330 年)的 话：
　　记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时， 不要去寻求绝对的准确??
　　项目管理者不应该被估算所困扰。现代软件工程方法(如，演化软件过程 模型)支持开发的迭代视图。在这类方法中，当用户改变需求时，有可能会重 新审查估算(在知道更多信息后)并修改之。①

5.2 项目计划目标


　　软件项目计划的目标是提供一个框架，使得管理者能够对资源、成本及 进度进行合理的估算。这些估算是软件项目开始时在一个限定的时间框架内 所做的，并且随着项目的进展不断更新。此外，估算应该定义“最好的情况” 及“最坏的情况”，使得项目的结果能够限制在一定范围内。
项目计划的目标是通过一个信息发现的过程实现的，该过程最终导致能
够进行合理的估算。在以下各节中，我们讨论了与软件项目计划相关的每一 个活动。

5.3 软件范围


　　软件项目计划的第一个活动是确定软件范围。在系统工程阶段(第 10 章) 应该对分配给软件的功能及性能加以评估，以建立一个项目范围，该范围在 管理级及技术级均是无二义性的和可理解的。
软件范围描述了功能、性能、约束条件、接口及可靠性。在范围说明中
给出的功能被评估，并在某些情况下被进一步精化，以便在估算开始之前提 供更多的细节。因为成本及进度估算都是面向功能的，所以某种程度上的分 解常常是很有用的。性能方面要考虑包括加工及响应时间在内的要求。约束 条件标识了外部硬件、可用内存或其他已有系统等对软件的限制。

5.3.1 获取定义软件范围所需的信息


　　在软件项目开始时，事情总是有某种程度的模糊不清。已经定义了要求， 并确立了基本的目标及目的，但定义软件范围所需的信息(这是估算的前提) 却还没有被定义。
在用户和开发者之间建立通信的桥梁，并使通信过程顺利开始的最常用 的技术是进行一个初步的会议或访谈。软件工程师(分析员)和用户之间的第



① 这并不意味着修改最初的估算一定是要发生的。一个成熟的软件组织及其管理者会认识到不是可以随意
修改计划的。许多用户要求（这是不正确的）一旦做了一个估算就必须一直维持它，而忽略了环境的变化。

一次会议可能就像青年男女的第一次约会那么尴尬。两方都不知道说什么或 问什么；两方都担心他们所说的话会被误解；两方都在想会有什么结果(有可 能他们的期望完全不同)；两方都希望事情赶快结束；但同时，两方都希望能 够成功。
　　不管怎样，通信必须要开始。Gause 和 Weinberg［GAU89］建议分析员开 始时可以问一些与项目无关的问题。即，一组使你对总体情况有一个基本了 解的问题，如，需要解决方案的人，所期望的解决方案的性质，以及对第一 次见面的效果的评价等。
　　第一组与项目无关的问题主要集中于用户、总体目标及利益上。例如， 分析员可能会问：
·谁提出了关于这项工作的要求？
·谁将会使用这个解决方案？
·成功的解决方案将获得什么利益？
·是否有其他的解决方案？ 下一组问题使得分析员能够对问题有一个更好的理解，使得用户能够谈
出他或她对于解决方案的想法：
　　·你(用户)认为一个成功的解决方案所产生的“好的”输出应该具有什 么特征？
·这个解决方案针对什么问题？
·你能给我演示(或描述)一下该解决方案将被使用的环境吗？
·是否有什么特殊的性能问题或约束会影响该解决方案被实现的方式？ 最后一组问题主要集中于会议的效果。Gause 和 Weinbers 称这些为“元
问题”，并推荐了下面的问题列表(简略的)：
·你是回答这些问题的最合适的人选吗？你的回答是否是“正式的”？
·我提的问题与你要解决的问题相关吗？
·我是否问了太多的问题？
·是否还有其他人能够提供更多的信息？
·是否还有其他我应该问你的问题？ 这些问题(及其他问题)能够帮助“打破僵局”，并开始了建立项目范围
所必须的通信活动。但这种问答会议的形式并不是一定会成功的。事实上，Q
＆A(问答)形式仅应该用于第一次会面，之后应该被问题解决、协商及规约等 多种方式相结合的会议形式所取代。
有很多独立调查者提出了一种收集需求的面向小组方法，能够帮助建立
项目的范围(应该注意，这些技术经常被视为是需求分析的第一步，在第 11 章将给出更详细的讨论)。一种被称为便利的应用规约技术(facilitated application specification techniques，FAST)的方法鼓励建立由用户及开 发者共同组成的联合小组在一起工作，来标识问题、建议解决方案、商议不 同的方法、并说明初步的所有需求。

5.3.2 一个范围定义的例子


　　与用户的通信使得我们可以定义数据、功能、必须实现的行为、性能、 界定系统的约束、及相关的信息。举一个例子，假定要开发驱动一个传送带 分类系统(a convey line sorting system，CLSS)的软件。对 CLSS 的范围说
　　
明如下： 传送带分类系统(CLSS)将沿传送带移动的盒子进行分类。每一个盒子由
一个包含零件号的条形码来标识，并在传送带末端分送到六个箱子中的一 个。这些盒子要通过一个由条形码阅读器及一台 PC 所组成的分类站。分类站
的 PC 连接到一个分流器上，它把盒子分送到不同的箱子中。盒子以随机的顺 序通过，且其间的距离相同。传送带以每分钟 5 英尺的速度移动。CLSS 如图
5-1 所示。
　　CLSS 软件以和传送带速度一致的时间间隔接受来自条形码阅读器的信 息。条形码数据被解码成盒子的标识格式。软件将在最多可容纳 1000 个条目 的零件号数据库中进行检索，以确定当前在阅读器(分类站)位置的盒子应该 放到哪个箱子中。该箱子的信息被传送到分流器，以把盒子放进合适的箱子 中。每一个盒子所放进的箱子的记录均被保存起来，以供以后提取及报告。 CLSS 软件同时也接受来自脉冲流速计的输入，用于使控制信号与分流器同 步。根据分类站和分流器之间产生的脉冲数，软件将产生一个控制信号给分 流器，以适当地定位盒子。


　　项目计划者检查范围说明，并提炼出所有重要的软件功能，这个过程， 称为分解，曾在第 3 章讨论过，它将产生如下功能(实际上，功能分解在系统 工程阶段进行，见第 10 章，计划者利用从系统规约中得到的信息来定义软件 功能)：
·读条形码作为输入。
·读脉冲流速计。
·解零件编码数据。
·检索数据库。
·确定合适的箱子。
·产生分流器的控制信号。
·保存盒子目的地的记录。 在本例中，性能取决于传送带的速度。对于每个盒子的处理必须在下一
个盒子到达条形码阅读器之前完成。CLSS 软件受以下条件约束：必须使用的
硬件(条形码阅读器、分流器、PC)，可用的内存，以及整个传送带的结构(等 距离的盒子)。
功能、性能及约束必须放在一起评估。在不同的性能约束下，相同的功
能可能在开发工作量上有数量级的巨大差别。因此，如果保持功能相同(如， 将盒子放进箱子中)而改变性能，开发 CLSS 软件所需的工作量及成本会产生 戏剧性的变化。例如，如果传送带的平均速度增长 10 倍，且盒子不再是等距 的(一个约束)，软件就会复杂得多，因此需要更多的工作量。功能、性能及 约束是紧密相关的。
　　软件会与基于计算机系统的其他组成成分之间进行交互。计划者考虑每 一个接口的性质及复杂性，以确定它们对开发资源、成本及进度的影响。接 口的概念是指(1)运行软件的硬件(如处理器、外设)及不直接由软件控制的设 备(如机器、显示器)；(2)已有的且必须与新软件连接的软件(如数据库访问 例程、可复用软件构件、操作系统)；(3)通过键盘或其他 I/O 设备使用软件 的人；以及(4)在软件之前或之后共同作为一个顺序操作系列的程序，在每种 情况下，通过接口传送的信息必须能被清楚地理解。
　　
　　关于软件范围的最不精确的方面是对可靠性的讨论。软件可靠性测量确 实已经存在(第 8 章)，但它们很少在项目的这一阶段中使用。典型的硬件可 靠性特性如平均失败间隔时间(mean-time-between-failure，MTBF)难以转换 到软件领域使用。不过，软件的一般性质可能引发某些特殊的考虑来保证“可 靠性”。例如，航空交通控制系统或穿梭号宇宙飞船(两个都是关系到人类生 命安全的系统)的软件一定不能失败，否则就会出人命。而一个库存控制系统 或字处理软件原则上也不应该失败，但如果失败，其影响要小得多。虽然我 们不可能在范围说明中精确地量化软件可靠性，但我们可以利用项目的性质 来辅助工作量及成本的估算，以保证可靠性。
　　如果已经适当地建立了系统规约(见第 10 章)，那么，在软件项目计划开 始之前，描述软件范围所需的几乎所有信息已经存在，且文档化了。如果还 没有建立系统规约，计划者就必须担当系统分析员的角色，以确定影响估算 工作的属性及约束。

5.4 资源


　　软件计划的第二个任务是估算完成软件开发工作所需的资源。图 5-2 将 开发资源表示成一个金字塔。开发环境——硬件及软件工具——处于资源金 字塔的底层，提供支持开发工作的基础。再高一层是可复用软件构件——软 件建筑块，能够极大地降低开发成本，并提早交付时间。在金字塔的顶端是 主要的资源——人员。每一类资源都由四个特征来说明：资源描述、可用性 说明、需要该资源的时间、及该资源被使用的持续时间。后两个特征可以看 成是时间窗口。对于一个特定的窗口而言，资源的可用性必须在开发的最初 期就建立起来。



5.4.1 人力资源


　　计划者在开始评估范围及选择完成开发所需的技术。对于组织的职位(如 管理者、高级软件工程师，等等)及专业技能(如，电讯、数据库、客户机/ 服务器)等都要加以描述。对于相对比较小的项目(六个人月或更少)，一个人 就可以完成所有软件工程步骤，如果需要的话可以咨询专家。
一个软件项目所需的人员数目在完成了开发工作量的估算之后就能够确
定。估算工作量的技术将在本章后面加以探讨。

5.4.2 可复用软件资源


　　如果没有对可复用性的认识，任何关于软件资源的讨论都将是不完整 的，可复用性是指软件建筑块的创建及复用［HOO91］。这类建筑块必须被分 类，才能方便查找；被标准化才能方便应用；被确认，才能方便集成。
　　Bennatan［BEN92］建议了在计划进行过程中应该考虑的四种软件资源分 类是：
　　可直接使用的构件：已有的，能够从第三方厂商获得或已经在以前的项 目中开发过的软件。这些构件已经经过验证及确认且可以直接用在当前的项
　　
目中。
　　具有完全经验的构件 ：已有的为以前类似于当前要开发的项目建立的 规约、设计、代码、或测试数据。当前软件项目组的成员在这些构件所代表 的应用领域中具有丰富的经验。因此，对于这类构件进行所需的修改其风险 相对较小。
　　具有部分经验的构件 ：已有的为以前与当前要开发的项目相关的项目 建立的规约、设计、代码、或测试数据，但需做实质上的修改。当前软件项 目组的成员在这些构件所代表的应用领域中仅有有限的经验，因此，对于这 类构件进行所需的修改会有相当程度的风险。
　　新构件：软件项目组为满足当前项目的特定需要而必须专门开发的软件 构件。
　　当可复用构件作为一种资源时，以下的指导原则是软件计划者应该考虑 的：
　　1.如果可直接使用的构件能够满足项目的需求，就采用它。获得和集成 可直接使用的构件所花的成本一般情况下总是低于开发同样的软件所花的成 本(当在项目中使用已有的软件构件时，总体成本可能会急剧降低。事实上， 产业数据表明：成本、上市时间以及缺陷数均会降低)。此外，风险也相对较
小。
　　2.如果具有完全经验的构件可以使用，一般情况下，修改和集成的风险 是可以接受的。项目计划中应该反映出这些构件的使用。
3.如果具有部分经验的构件可以使用，则必须详细分析它们在当前项目
中的使用。如果这些构件在与软件中其他成分适当集成之前需要做大量修 改，就必须小心行事。修改具有部分经验的构件所需的成本有时可能会超过 开发新构件的成本。
具有讽刺意味的是，可复用软件构件的使用在计划阶段经常被忽视，仅
在软件过程的开发阶段才变成最主要的关心对象。最好能够尽早说明软件资 源需求。这样才能进行可选方案的技术评估，并及时获得所需的构件。

5.4.3 环境资源


　　支持软件项目的环境，通常被称为软件工程环境(software engineering environment，SEE)，集成了硬件及软件两大部分。硬件提供了一个支持工具 (软件)平台，这些工具是产生通过良好的软件工程实践而得到的工作产品所 必需的(其他硬件——目标环境——是软件已经交付给最终用户之后将要在 其上运行的计算机)。因为大多数软件组织中均有多个小组需要使用 SEE，因 此，项目计划者必须规定硬件及软件所需的时间窗口，并验证这些资源是否 可用。
　　当要开发一个计算机系统(集成特定的硬件及软件)时，软件项目组可能 需要用到由其他工程小组开发的硬件成分。例如，在某一类机械工具上使用 的数控(numerical control，NC)软件可能需要某个特定的机械工具(如数控 机床)来作为测试步骤确认的一部分；自动排版的软件项目可能在开发过程中 的某个阶段需要用到照片排版机。软件项目计划者必须说明需要的每一个硬 件成分。
　　
5.5 软件项目估算


　　在计算机发展的早期，软件成本在整个计算机系统的成本中仅占很小的 百分比。软件成本估算中即使出现了数量级的误差也几乎没有什么影响。今 天，在大多数计算机系统中，软件已经变成开销最大的成分。一个大的成本 估算误差会造成营利及亏损间的巨大差别。而超支对于开发者而言是一场灾 难。
　　软件成本及工作量估算永远不会是一门精确的科学。太多的变化——人 员、技术、环境、策略——影响了软件的最终成本及开发所需的工作量。不 过，软件项目估算可以从神秘的技巧向一系列系统化的步骤的转变的过程 中，估算出可接受的风险。
为了可靠地估算成本及工作量，有以下几种选择可以考虑：
　　1.将估算拖延到项目的最后阶段(显然，如果在项目完成之后进行估算， 我们能够赢得百分之百的准确率)。
2.基于已经完成的类似的项目进行估算。
3.使用简单的“分解技术”来进行项目成本及工作量的估算。
4.使用一个或多个经验模型进行软件成本及工作量的估算。 不幸的是，第一个选择，不管它有多吸引人，是不现实的。成本估算必
须“预先”提出。然而，我们应该认识到我们等的越久，知道的越多，而我
们知道的越多，就越可能在估算中不会产生严重错误。 如果当前项目与以前的工作非常相似，且其他的项目影响因素(如用户的
特性、商业条件、SEE、及交付期限等)也相同，第二个选择能够运作得很好。
不幸的是，过去的经验并不总是未来结果的好的指示器。 其余的两个选择是软件项目估算的可用方法。理想情况下，这两种选择
技术可以同时使用，互相进行交叉检查。分解技术采用“分而治之”的策略
进行软件项目估算。将项目分解成若干主要的功能及相关的软件工程活动， 通过逐步求精的方式进行成本及工作量估算。经验估算模型可用于补充分解 技术，并提供一种潜在有价值的估算方法。该模型是基于经验(历史数据)来 进行的，可以用下面的公式表示：
d=f(vi)
其中 d 是要估算的值(如工作量、成本、项目持续时间)，Vi 是选择出来
的独立参数(如被估算的 LOC 或 FP)。 自动估算工具实现一种或多种分解技术或经验模型。如果与交互式人机
界面结合起来，在进行估算的时候自动工具将是一种很有吸引力的选择。在 这类系统中，要描述开发组织的特性(如经验、环境)及待开发软件的性质。 成本及工作量估算可由这些数据导出。
　　每一个选择来估算可用软件成本的参量取决于用于估算的历史数据。如 果没有历史数据存在，成本估算也就建立在一个很不稳定的基础之上。在第
4 章中，我们已经考察了一些软件度量的特性，它们为如何提供历史估算数 据奠定了基础。

5.6 分解技术

软件项目估算是一种解决问题的形式。在大多数情况下，如果将待解决

的问题(即，为软件项目建立一个成本及工作量估算)作为一个整体来考虑则 太过复杂了。因此，我们要分解问题，把问题重新划分成一组较小的(也更易 管理的)问题。
　　在第 3 章中，从两个不同的视点讨论了分解方法：问题分解及过程分解。 估算可以利用其中一种或两种划分形式。但在进行估算之前，项目计划者必 须了解待建造软件的范围，并对其“规模”有相应的估算。

5.6.1 软件规模估算


　　软件项目估算的准确性取决于若干因素：(1)计划者适当地估算待建造产 品的规模的程度；(2)把规模估算转换成人的工作量、时间、及成本的能力(一 个来自以前项目的可靠软件度量的可用性函数)；(3)项目计划反映软件项目 组能力的程度；以及(4)产品需求的稳定性及支持软件工程工作的环境。
　　在本节中，我们考虑软件规模估算的问题。因为项目估算的好坏取决于 要完成的工作的规模估算，因此，规模估算是项目计划者面临的第一个挑战。 在项目计划中，规模是指软件项目的可量化的结果。如果采用直接的方法， 规模可以用 LOC(代码行)来测量。如果选择间接的方法，规模可以用 FP(功能 点)来表示。
Putnam 和 Myers［PUT92］建议了四种估算问题规模的方法：
　　“模糊逻辑”法 ：这个方法使用了模糊逻辑基础的近似推理技术。要使 用这个方法，计划者必须说明应用软件的类型，建立其定性的规模估算，之 后在最初的范围内精化该估算。虽然可以利用个人的经验，但计划者也应该 访问项目的历史数据库(见 5.9 节，简单地讨论了支持模糊逻辑规模估算及本 节中讨论的其他技术的工具)，使得估算能够与实际的经验加以比较。
功能点法：计划者对第 4 章讨论过的信息域特性进行估算。
　　标准构件法：软件由若干不同的“标准构件”组成，这些构件对于一个 特定的应用领域而言是通用的。例如，一个信息系统的标准构件是子系统、 模块、屏幕、报表、交互程序、批程序、文件、LOC、以及对象级的指令。项 目计划者估算每一个标准构件的出现次数，然后使用历史项目数据来确定每 个标准构件交付时的大小。为了说明这点，让我们以一个信息系统为例。计 划者估算将产生 18 个报表，历史数据表明每一个报表需要 967 行 Cobol
［PUT92］代码。这使得计划者估算出报表构件需要 17000LOC。对于其他标
准构件也可以进行类似的估算及计算，将它们合起来就得到最终的规模值(以 统计方式调整)。
　　修改法：该方法主要用于这种情况：一个项目中包含对已有软件的使 用，但该软件必须做某种程度的修改才能作为该项目的一部分。计划者要估 算必须完成的要修改的数目及类型(如，复用、增加代码、修改代码、删除代 码)。对于每一类修改使用“工作比率”，即可估算出修改的规模。
　　Putnam 和 Myers 建议：上述每种估算规模的方法所产生的结果可以在统 计上进行结合，以产生一个三点或期望值估算。这可以通过下述方式实现： 建立关于规模的乐观、可能、及悲观值，并使用将在下一节描述的等式(5.1) 将它们结合起来。