浅谈软件度量

浅谈软件度量

---

时间：2004-11-17 15:20:43 来源：中国金融电脑杂志社 作者：周 凡 陆 斌  

 

随着金融信息化总体水平的提升，软件工程的各种开发技术被不断引入这个行业。“如何衡量软件技术的有效性？如何评价所采用的软件开发过程模式的合理性？如何确认最终的软件产品是否符合既定的需求和质量标准？”是金融软件项目管理中的常见问题。
 
回答这些问题的是一门新兴的学科——软件度量。通过度量，可以获得软件评估的依据、跟踪软件开发的进展情况、评估程序代码的质量，帮助我们确定最合适的实施方案。

一、为什么要度量
 
Ｌｏｒｄ Ｋａｌｖｉｎ曾说过：“当你能够度量你所谈论的事物，并且用数字把它表达出来，那你对此事物已经有所了解；当你无法度量它，则你的知识并不足以了解它”。
 
人们通常藉由“比较”来了解事物。比如，这个项目规模比那个项目大，这个人工作效率比那个人高。但是，仅仅这样是不够的。我们还要知道，这个项目规模为什么比另一个项目规模大？大多少？优秀程序员和一般程序员到底有多大的差异？于是，我们通过分析“程序行数” 的大小，来判断程序Ａ与程序Ｂ的规模差异；通过分析“每小时发现的错误数”的多少，来衡量测试员的工作效率。
 
度量是经验世界到规范的数学世界的映射。我们用数学表示法来描绘和分析实体与其属性，并使用这些数字符号，来揭露出更多的在直接观察时不易发现的规律和特征。通过计量某一个实体的特征，我们可以更深入地了解和利用它们。软件工程领域也不例外。
 
软件度量就是经过计量软件开发过程、软件产品和所投入资源的特定属性的数值，再通过整理、分析和比较所产生的结果，来预测或评估软件开发项目，进而达到软件工程的主要目标——在预定的时间与资源预算下，开发出合乎用户需求的软件系统。
 
首先，度量有助于我们理解软件开发和维护过程。我们总是通过分析和评价当前情况，确定未来的目标和行为基线。在这种情况下，度量使得过程和产品的各方面变得“可视化”，让我们更好地理解我们所采取的活动和活动对象之间的关系。
 
其次，度量让我们能够加强对项目的管理和控制。在我们深入理解了软件开发中各项活动和产品之间的关系的基础上，我们可以更好地预测项目的进展情况和可能的变更，建立合理的项目计划，调整项目中的活动，以达到项目目标。比如，我们通过监测代码的复杂度，可以判断哪些模块超过了可接受范围，进而对这些模块采取一定的复核措施来确保其正确性。
 
另外，度量鼓励我们改进我们的过程和产品。比如，软件能力成熟度模型（ＣＭＭ）就是这样的一个度量体系。

二、软件度量的几个术语
 
实体（Ｅｎｔｉｔｙ）：在度量过程中抽象出的观察目标，它可以是一个对象（如一个人或者一个程序模块）或者一次事件（如一个软件项目的测试阶段）。
 
属性（Ａｔｔｒｉｂｕｔｅ）：实体的某种特征或性质，我们通过它来描述、区分不同的实体。每个实体的属性又可以分为内部属性和外部属性，其中内部属性可以通过直接度量得到，而外部属性必须通过间接度量得知。对于一段程序而言，代码长度就是它的一项内部属性，而可维护性、可靠度等则是外部属性。
 
度量（Ｍｅａｓｕｒｅｍｅｎｔ）：按照一定的过程定义，给软件实体属性赋值的过程。
 
度量指标（Ｍｅｔｒｉｃ）：已定义的测量方法和测量尺度，软件环境中指定对象的属性的量化表现。
 
度量值（Ｍｅａｓｕｒｅ）：在实体上采集到的数据，是对软件产品、过程的特征量化计数的结果。
 
软件工程的实体分为三大类：
 
①过程（Ｐｒｏｃｅｓｓ）：软件开发中活动的集合。不同的软件开发模式中，所采用的流程和活动也不一样；
 
②产品（Ｐｒｏｄｕｃｔ）：软件过程活动的结果，可以是一个程序、一个软件文档或其他任何交付物；
 
③资源（Ｒｅｓｏｕｒｃｅ）：实施这些活动所需要的对象，可能是人力、设备、时间等。

三、软件度量指标的选取
 
软件度量的目的不是为了收集数据。当我们在软件开发管理过程中进行度量活动时，我们首先需要弄清以下问题：为什么需要度量？什么东西需要度量？谁参与度量活动？什么时候度量？在哪里进行度量？
 
我们可以用很多不同的方式来对目标进行度量。比如度量软件规模时，我们可以计算程序行数，也可以计算功能点数，或者计算对象和方法数。不同的处理方式，得到的答案也不一样。因此，必须针对特殊的目标和问题来选择合适的度量指标。
 
类似于软件过程，我们把软件度量活动的集合叫做软件度量过程，它可能由这样一些具体内容构成：定义度量目标；制定度量计划；进行度量；收集数据；分析数据并整理经验。在整个过程中，为保证度量活动的有效性，可以遵循以下步骤（ＧＱＭ方法）选取度量指标。
 
第一，确定目标（Ｇｏａｌ）。合理的目标通常是一项活动能否成功的关键。软件度量活动也需要明确的目标，包括：研究对象、研究意图、关注目标，以及出发立场及相关环境；
 
第二，提出问题（Ｑｕｅｓｔｉｏｎ）。针对既定的研究目标，提出一系列问题，这些问题描绘出达到目标所需要关注的各个方面；
 
第三，定义度量指标（Ｍｅｔｒｉｃ）。根据问题，选择相应的度量指标。
 
例如，如果我们关注的目标是“从项目管理者的角度出发，改进变更请求的处理过程”，那么可能提出这样的相关问题“当前的变更处理速度是多少？”、“处理过程改进了没有？”，进而采用“平均周转时间”以及“标准偏差”等度量指标来回答第一个问题，采用“当前平均周转时间/上年平均周转时间”来回答第二个问题。

四、常用软件产品度量技术和指标
 
任何度量活动都需要遵循一定的程序和规则，规则有助于度量的一致性，同时也为度量所取得的数据的分析提供一致的准则。一些经典的软件度量技术，对于我们在应用软件开发过程中实施量化管理有着非常重要的参考价值和借鉴意义。
 
这里，让我们来看看对软件产品内部属性的度量。
 
每一个软件产品都是一个物理实体，因此，也可以使用“尺寸”进行描述和衡量。软件的“尺寸”由３个特征体现：长度、复杂度、功能性。
 
１．长度
 
软件长度是软件的物理属性。当我们面对诸如“我们开发的最大/最小/平均项目是哪一个？我们的最大/最小/平均模块长度是多少？我们的软件开发生长率如何？模块长度是否和程序缺陷数量有关？”问题的时候，作为一个最基本的参照系，“长度”是分析解答问题的必要依据。
 
（１）代码行数（ＬＯＣ）
 
度量程序长度，最直接、应用最普遍的度量指标就是ＬＯＣ。通过对程序行简单的计数，我们可以得到代码行数的度量值。它衡量的是软件的物理规模——长度，此项指标与所采用的程序设计语言类型无关。不过，对计数对象的选择和如何计数必须给予充分的重视，因为对空行、注释行、数据定义和变量申明等情况的不同处理方式，度量结果可能出现５倍的差异。
 
（２）Ｈａｌｓｔｅａｄ方法
 
Ｈａｌｓｔｅａｄ度量方法不仅仅度量了程序长度，还描述了程序的最小实现和实际实现之间的关系，并据此阐释程序语言的等级高低。它以程序中出现的操作符和操作数为计数对象，以它们的出现次数作为计数目标来测算程序容量和工作量。
 
任意程序Ｐ，总是由操作符和操作数通过有限次的组合连缀而成。Ｐ的符号表词汇量η＝η１＋η２（η１：惟一操作数数量，η２：惟一操作符数量）。设Ｎ１是Ｐ中出现的所有操作数，Ｎ２是程序中出现的所有操作符。度量指标如下：
 
程序长度Ｎ＝Ｎ１＋Ｎ２
 
程序容量Ｖ＝Ｎ×ｌｏｇ２η
 
当我们编写程序的时候，代码体积会因实现方式和编写者的习惯有所差异，还会因所采用的程序语言（比如保留字的数量，语句的结构等）而有所不同。因此，又有如下标准：
 
程序语言等级Ｌ＝Ｖ/Ｖ（Ｖ是程序实现时可能的最小代码容量）
 
编写程序的效率Ｅ＝Ｖ/Ｌ
 
Ｈａｌｓｔｅａｄ的度量分析指出，在软件开发中，把系统划分为单独的模块所带来的实质性利益，在于短代码的难度要比长代码低。
 
２．复杂度
 
２０世纪７０年代开始，软件系统被认为已经变得极其复杂。经验告诉我们，出现错误的可能性随着软件复杂程度的增加而增加，越复杂的软件就越难于理解和维护。
 
由于观察的出发点不同，对复杂度的分析涉及若干方面：问题的复杂度、认知的复杂度、算法的复杂度以及程序结构的复杂度。其中，程序复杂度度量的是软件的内部属性，可通过ＭｃＣｕｂｅ方法度量。
 
ＭｃＣｕｂｅ的度量方法是基于对程序拓扑结构复杂度的分析。在软件工程活动中，广泛使用于几个方面：作为程序设计和管理指南；作为测试的辅助工具；作为网络复杂性的一种度量方法。
 
ＭｃＣｕｂｅ方法包括若干项度量指标。常用的有如下几项：
 
（１）圈复杂度（Ｃｙｃｌｏｍａｔｉｃ Ｃｏｍｐｌｅｘｉｔｙ）
 
圈复杂度是用来衡量一个模块判定结构的复杂程度。
 
在程序控制流程图中，节点是程序中代码的最小单元，边代表节点间的程序流。一个有ｅ条边和ｎ个节点的流程图Ｆ，其圈复杂度为
 
ＶＦ＝ｅ－ｎ＋２。
 
圈复杂度越高，程序中的控制路径越复杂。ＭｃＣｕｂｅ指出，典型的程序模块的圈复杂度为１０。
 
（２）基本复杂度（Ｅｓｓｅｎｔｉａｌ Ｃｏｍｐｌｅｘｉｔｙ）
 
基本复杂度是用来衡量程序结构化程度的。
 
如果流程图Ｇ中的结构化子图的数量是ｍ，则其基本复杂度为
 
ＥＶＦ＝ＶＦ－ｍ
 
当基本复杂度为１，这个模块是充分结构化的；当基本复杂度大于１而小于循环复杂度，这个模块是部分结构化的；当基本复杂度等于循环复杂度时，这个模块是完全非结构化的。
 
（３）模块设计复杂度（Ｍｏｄｕｌｅ Ｄｅｓｉｇｎ Ｃｏｍｐｌｅｘｉｔｙ）
 
模块设计复杂度用来衡量模块判定结构，即衡量模块与模块的调用关系。
 
从模块流程图中移取那些不包含调用子模块的判定和循环结构时求得的循环复杂度就是模块设计复杂度。
 
３．功能性
 
通过对需求说明书的分析，我们可以使用“功能点”来对软件产品提供给用户的功能加以度量。程序长度和复杂性都是对程序的事后分析，软件功能性却可在软件开发的初期进行分析，这对我们预测项目规模，规划项目时间表非常有帮助。软件功能性特征可使用Ａｌｂｒｅｃｈｔ方法度量。

Ａｌｂｒｅｃｈｔ的度量方式是先按需求描述对功能点计数，得到未调整功能点，再按系统涉及的技术功能点对该数值进行修正。
 
按照软件表示技术，一项需求可描述为若干外部输入、外部输出、外部请求、外部文件、内部文件的集合。对集合中每一子项进行计数，并按其复杂性指派相应的权重，可得未调整功能点ＵＦＣ：
         
  
任何需求的实现，都与一定的技术有关。Ａｌｂｒｅｃｈｔ定义了１４项技术特性，对应每一特性有一个从０到５的关联值Ｆｉ（０说明此项技术特性与功能实现毫无关系，５说明此项技术特性是系统建立必不可少的组成部分）。一项需求的技术复杂性特性值ＴＣＦ即由这些评分合成，公式如下：
              
ＴＣＦ＝０．６５＋０．０１Ｆｉ
 
最后，功能点的度量值ＦＰ，为以上二者的乘积：
              
ＥＰ＝ＵＦＣ×ＴＣＦ
 
Ｆｒｅｄ Ｓ．Ｒｏｂｅｒｔｓ说过：“高度发展的学科和发展较慢的学科，造成重要差异的原因之一就在于事务可以被度量的程度。”
 
日益规范的项目管理活动中，我们需要精确的数字来支持我们的决策，软件度量就是这样一个破除软件开发过程“混沌”状态的利器。它告诉我们项目的成败（项目是否在指定的时间和开支范围内完成）；过程的效率（附加的评审活动在多大程度上改善了产品质量）；资源的充分程度（有经验的程序员与普通程序员的工作效率有多少差距）。引入量化管理，强化量化管理，可以使项目管理知识体系发挥更大的作用。
 
我们应该记住软件度量领域的经典语句：“我们不重视我们不度量的东西，我们对不度量的东西不能有所作为。”