软件度量(转贴)
一、软件度量的发展历程
如Lemmerich所言， 测量在科学领域有悠久的历史[116]。相对早在1889年就定义好了度量单位～米的长度测量[116]，温度的度量复杂的多。
Fahrenheit和Celsius分别在1714年和1742年提出了基于某固定点间隔递增等级的温度度量方法。Celsius将100度和0度之间分为100个等份。但问题是一直不能唯一确定50摄氏度。而且长度的测量总是一个比例尺度，但是温度可能用间隔( 摄氏/华氏温度表) 或者比例尺度(开氏温度)来衡量。
今天，计算机在我们生活的每个领域几乎都扮演了非常重要的角色。在计算机上运行的软件也越来越重要。因此，可预测、可重复、准确地控制软件开发过程和软件产品已经非常重要。软件度量就是衡量软件品质的一种手段。
软件度量或者说软件工程度量领域是一个在过去30多年研究非常活跃的软件工程领域。软件度量（software measurement）和软件量度（software metrics）一样非常有名（译者注：为了区分，译者将software measurement和software metrics分别译成软件度量和软件量度，其实他们都可以表示软件度量）。但目前学界还没有明确这两个术语的区别。参照测量理论[159]的相关术语，我们采用软件度量（software measurement）。从文献上看，这两个术语是同义词。量度（metric）在这里不作度量空间理解，它理解为：度量是客观对象到数字对象的同态映射。同态映射包括所有关系和结构映射。用另一句话说，软件品质和软件度量成直对关系。这是度量和软件度量的根本理念。
软件度量研究主要分为两个阵营：一部分认为软件可以度量，一部分认为软件无法通过度量分析。无论如何，研究主流是关心软件的品质和认为软件需要定量化度量。目前有超过上千种软件度量方法被软件研究人员及从业人员提出，并且到今天有超过5000份论文出版发表。
二、简单软件度量流程图
三、软件度量三维度
软件度量能够为项目管理者提供有关项目的各种重要信息，其实质是根据一定规则，将数字或符号赋予系统、构件、过程或者质量等实体的特定属性，即对实体属性的量化表示，从而能够清楚地理解该实体。软件度量贯穿整个软件开发生命周期，是软件开发过程中进行理解、预测、评估、控制和改善的重要载体。软件质量度量建立在度量数学理论基础之上。软件度量包括3个维度，即项目度量、产品度量和过程度量，具体情况如表-1所示。
四、为什么需要软件度量
在软件开发中，软件度量的根本目的是为了管理的需要。利用度量来改进软件过程。人们是无法管理不能度量的事物。在软件开发的历史中，我们可以意识到，在60年代末期的大型软件所面临的软件危机反映了软件开发中管理的重要性。而对于管理层人员来说：没有对软件过程的可见度就无法管理；而没有对见到的事物有适当的度量或适当的准则去判断、评估和决策，也无法进行优秀的管理。我们说软件工程的方法论主要在提供可见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科。这就需要使用度量。度量是一种可用于决策的可比较的对象。度量已知的事物是为了进行跟踪和评估。对于未知的事物，度量则用于预测。本专题将讨论软件度量的一些基本问题。但应认识到软件度量的成果是非常初步的，还需要大量工作才可能真正地做到实用化，但它的实用化成就将对软件的高质量和高速发展有不可估量的影响。那么, 一、什么是度量呢? 1、度量概念：度量存在于左右我们生活的很多系统的核心之中。在经济领域,度量决定着价格和付款的增加;在雷达系统中,度量使我们能透过云层探测到飞机;在医疗系统中,度量使得能够诊断某些特殊疾病;在天气预测系统中,度量是天气预报的基础;没有度量,技术的发展根本无法进行。度量的正式定义是: 度量 是指在现实的世界中,把数字或符号指定给实体的某一属性, 以便以这种方式来根据已明确的规则来描述它们.
因此,度量关注的是获取关于实体属性的信息。一个实体可以是一个实物,如人或房间；或者是一个事件，如旅行；或软件项目的测试阶段。属性是我们所关注的实体的特征或特性,如血压的高度(人)、时间(测试阶段)、范围或颜色(房间)、花销(旅行) 等。因此,说"度量事物"或"度量属性"的说法是不完全正确的;应该说"度量事物的属性"。"度量房间"的说法是模糊的;我们可以说度量它的长度、范围和温度等。同样说"度量温度"的说法也是模糊的,应该说：我们度量的是某一特定地理位置和特定情况下的温度。
2、工程学科需要度量软件工程要的是有模型和理论支持的方法。
如在设计电路的时候我们应用欧姆定律。这个定律描述了电路中电阻、电流和电压三者之间的关系。但是这些理论已超出了一般意义上的科学方法的范畴，在这种范畴里最基本的东西是度量。度量除了在发展一个理论的过程中起作用外，我们使用度量并应用它们。因此设计一个特定电流和电阻的电路时我们就知道需要多大的电压。
如果没有度量，我们很难想象关于电子、机械、及普通工程的定律能得到发展。但事实上现在在软件工程的主流里度量却被忽略了。
现在的情况是：
■当我们在设计和开发软件产品的时候，我们并未能制定出度量的目标。例如：我们保证说我们将使用户界面友好、可靠、易于维护；而并未使用度量的术语来详细说明它们的具体含义。Gilb曾经说过：所谓模糊目标定理，就是没有明确目标的项目将不能明确地达到它的目标。
■我们未能对构成软件项目实际费用的各个不同的部分进行有效的度量。譬如：通常我们并不知道，和测试阶段相比，设计阶段花费时间多大。
■我们并未试图使我们开发的产品的各种质量合格。因此我们未能使用术语（如：在一段时间里使用故障的可能性、把产品安装到新环境中需花费的工作量等）向潜在的用户说明产品的可靠性很高。
■我们总是试图说服自己使用另一种新的革新的开发技术和方法进行软件开发
事实上，我们在软件度量方面做的工作很少很少，而且所作的度量方面的工作也与一般科学意义上的度量相分离。我们经常会看到诸如此类的话："软件的费用有80％花费在维护上。"或"软件每一千行程序中平均有55个Bugs。"。但是这些话并没有告诉我们这样的结果是怎样产生的、试验是怎样设计、执行的、度量的是那个实体、及错误的框架是什么等等。没有这些东西，我们就不能在我们自己的环境中客观地进行反复度量，重现度量的结果以获得与工业标准的真实比较。因此，归因于度量不充分的问题的产生是由于缺乏严格的度量方法造成的。
除了传统的对计算机硬件的性能进行度量外，对算法的复杂性的度量一直是计算机科学的重要组成部分。但是，这种度量方法只适用于小程序，而对大型、复杂的软件来说它却无能为力了。这就属于软件工程的范畴了。如果我们不承认度量将会一个更重要的作用的话，软件危机将在随后的几年里依然存在
五、软件度量工具
随着软件定量方法（如：软件度量）的重要性不断增加，市场上出现了许多度量工具。然而，度量工具目前还是很混乱。因为没有统一的度量标准规范，每种工具发明商家都是按照他们自己的软件度量规范。文献[44]对度量工具做了好的综述。Daich等根据分类学把度量工具分成了以下几种：
● 通用度量工具；
● 小生境度量工具（Niche Metrics Tool）；
● 静态分析；
● 源代码静态分析；
● 规模度量
六、软件度量的目标
软件开发正在经受一场危机。费用超支（特别是在维护阶段的花费太大）、生产率低下、 以及质量不高等问题正困扰着它。简言之，软件开发经常处于失控状态。软件之所以失控是因为没有度量。Tom Demarco曾经说过："没有度量就不能控制。"这种说法是好的，但不完全。并不能说为了获得控制必须进行度量。度量活动必须有明确的目标或目的，而正是这决定着我们选择哪种属性和实体进行度量。这个目标与软件开发、使用时所涉及的人的层次有关。
以下主要从管理者和软件工程师两种角度来考虑，为了达到各种目标所要进行的度量工作。
●对管理者而言：
1.需要度量软件开发过程中的不同阶段的费用。
例如：度量开发整个软件系统的费用（包括从需求分析阶段到发布之后的维护阶段）。必须清楚这个费用以决定在保证一定的利润的情况下的价格。
2.为了决定付给不同的开发小组的费用，需要度量不同小组职员的生产率。
3.为了对不同的项目进行比较、对将来的项目进行预测、建立基线以及设定合理的改进目标等，需要度量开发的产品的质量。
4.需要决定项目的度量目标。例如：应达到多大的测试覆盖率、系统最后的可靠性应有多大等。
5.为了找出是什么因素影响着费用和生产率，需要反复测试某一特定过程和资源的属性。
6.需要度量和估计不同软件工程方法和工具的效用，以便决定是否有必要把它们引入到公司中。
●对软件工程师而言：
1.需要制定过程度量以监视不断演进的系统。这包括设计过程中的改动、在不同的回顾或测试阶段发现的错误等等。
2.需使用严格的度量的术语来指定对软件质量和性能的要求，以便使这些要求是可测试的。例如：系统必须"可靠"，可用如下的更具体 的文字加以描述："平均错误时间必须大于15个CPU时间片。"
3.为了合格需要度量产品和过程的属性。例如：看一个产品是否合格要看产品的一些可度量的特性如"β测试阶段少于20个错误。"，"每个模块的代码行不超过100行。"，和开发过程的一些属性如"单元测试必须覆盖90％以上的用例。"等。
4.需要度量当前已存在的产品和过程的属性以便预测将来的产品。例如：
(1).通过度量软件规格说明书的大小来预测目标? 的大小。
(2).通过度量设计文档的结构特性来预测将来维护的"盲点"。
(3).通过度量测试阶段的软件的可靠性来预测软件今后操作、运行的可靠性。
研究上面我们列出的度量的目标和活动我们可以发现：软件度量的目标可大致 概括为两类。
其一，我们使用度量来进行估计。这使得我们可以同步地跟踪一个特定的软件项目 。
其二，我们应用度量来预测项目的一些重要的特性。但是，值得指出的是我们不能 过分夸大这些预测。因为它们并不是完全正确的。软件度量得到也仅仅是预测而已。有些人甚至认为只要使用合适的模型和工具，所获得的预测可以精确到只需使用极少的其他度量（甚至根本就不用使用度量）。事实上，这种期望是不现实的。
七、软件度量的方法体系
◆ 项目度量
项目度量是针对软件开发项目的特定度量，目的在于度量项目规模、项目成本、项目进度、顾客满意度等，辅助项目管理进行项目控制。
◆ 规模度量
软件开发项目规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。规模度量是软件项目失败的重要原因之一。一个好的规模度量模型可以解决这一问题。有效的软件规模度量是成功项目的核心要素：基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。规模度量的要点在于：由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。
软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。软件规模的估算方法有很多种，如：功能点分析(FPA：function points analysis)、代码行(LOC：lines of code)、德尔菲法(Delphi technique)、COCOMO模型、特征点(feature point)、对象点(object point)、3-D功能点(3-D function points)、Bang度量(DeMarco's bang metric)、模糊逻辑(fuzzy logic)、标准构件法(standard component)等，这些方法不断细化为更多具体的方法。
◆ 成本度量
软件开发成本度量主要指软件开发项目所需的财务性成本的估算。主要方法如下：
类比估算法。类比估算法是通过比较已完成的类似项目系统来估算成本，适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目。其约束条件在于必须存在类似的具有可比性的软件开发系统，估算结果的精确度依赖于历史项目数据的完整性、准确度以及现行项目与历史项目的近似程度。
细分估算法。细分估算法是将整个项目系统分解成若干个小系统，逐个估算成本，然后合计起来作为整个项目的估算成本。细分估算法通过逐渐细化的方式对每个小系统进行详细的估算，可能获得贴近实际的估算成本。其难点在于，难以把握各小系统整合为大系统的整合成本。
周期估算法。周期估算法是按软件开发周期进行划分，估算各个阶段的成本，然后进行汇总合计。周期估算法基于软件工程理论对软件开发的各个阶段进行估算，很适合瀑布型软件开发方法，但是需要估算者对软件工程各个阶段的作业量和相互间的比例具有相当的了解。
◆ 顾客满意度度量
顾客满意是软件开发项目的主要目的之一，而顾客满意目标要得以实现，需要建立顾客满意度度量体系和指标对顾客满意度进行度量。顾客满意度指标(CSI：customer satisfaction index)以顾客满意研究为基础，对顾客满意度加以界定和描述。项目顾客满意度量的要点在于：确定各类信息、数据、资料来源的准确性、客观性、合理性、有效性，并以此建立产品、服务质量的衡量指标和标准。企业顾客满意度度量的标准会因为各企业的经营理念、经营战略、经营重点、价值取向、顾客满意度调查结果等因素而有所不同。比如：NEC于2002年12月开始实施的CSMP 活动的度量尺度包括共感性、诚实性、革新性、确实性和迅速性，其中，将共感性和诚实性作为CS活动的核心姿态，而将革新性、确实性和迅速性作为提供商品和服务中不可或缺的尺度。每个尺度包括两个要素，各要素包括两个项目，共计5大尺度、10个要素和20个项目。例如，共感性这一尺度包括“了解顾客的期待”、“从顾客的立场考虑问题”这两个要素；“了解顾客的期待”这一要素又包括“不仅仅能胜任目前的工作还能意识到为顾客提供价值而专心投入”、“对顾客的期望不是囫囵吞枣而是根据顾客的立场和状况来思考‘顾客到底需要什么’并加以应对”这两个项目。
美国专家斯蒂芬(Stephen H.Kan)在《软件质量工程的度量与模型》(Metrics and Models in Software Quality Engineering)中认为，企业的顾客满意度要素如表7-1所示：
| 顾客满意度要素 | 顾客满意度要素的内容 |
| 技术解决方案 | 质量、可靠性、有效性、易用性、价格、安装、新技术 |
| 支持与维护 | 灵活性、易达性、产品知识 |
| 市场营销 | 解决方案、接触点、信息 |
| 管理 | 购买流程、请求手续、保证期限、注意事项 |
| 交付 | 准时、准确、交付后过程 |
| 企业形象 | 技术领导、财务稳定性、执行印象 |
表7-1 顾客满意度要素及其内容
作为企业的顾客满意度的基本构成单位，项目的顾客满意度会受到项目要素的影响，主要包括：开发的软件产品、开发文档、项目进度以及交期、技术水平、沟通能力、运用维护等等。具体而言，可以细分为如表7-2所示的度量要素，并根据这些要素进行度量。
| 顾客满意度项目 | 顾客满意度度量要素 |
| 软件产品 | 功能性、可靠性、易用性、效率性、可维护性、可移植性 |
| 开发文档 | 文档的构成、质量、外观、图表以及索引、用语 |
| 项目进度以及交期 | 交期的根据、进度迟延情况下的应对、进展报告 |
| 技术水平 | 项目组的技术水平、项目组的提案能力、项目组的问题解决能力 |
| 沟通能力 | 事件记录、式样确认、Q&A |
| 运用维护 | 支持、问题发生时的应对速度、问题解决能力 |
表7-2顾客满意度项目度量要素
◆ 产品度量
软件质量的生命周期及其度量
软件产品度量用于对软件产品进行评价，并在此基础之上推进产品设计、产品制造和产品服务优化。软件产品的度量实质上是软件质量的度量，而软件的质量度量与其质量的周期密切相关，如图7-1所示：
软件质量度量模型
软件产品的度量主要针对作为软件开发成果的软件产品的质量而言，独立于其过程。软件的质量由一系列质量要素组成，每一个质量要素又由一些衡量标准组成，每个衡量标准又由一些量度标准加以定量刻划。质量度量贯穿于软件工程的全过程以及软件交付之后，在软件交付之前的度量主要包括程序复杂性、模块的有效性和总的程序规模，在软件交付之后的度量则主要包括残存的缺陷数和系统的可维护性方面。一般情况下，可以将软件质量特性定义成分层模型。勃姆(Barry W. Boehm)在《软件风险管理》(Software Risk Management)中第一次提出了软件质量度量的层次模型。而麦考尔(McCall)等人将软件质量分解至能够度量的层次，提出FCM 3层模型(参见表5-13)：软件质量要素(factor)、衡量标准(criteria)和量度标准(metrics)，包括11个标准，分为产品操作(product operation)、产品修正(product revision)和产品转移(product transition)。ISO 9126将软件质量总结为6大特性，每个特性包括一系列副特性，其软件质量模型包括3层，即高层：软件质量需求评价准则(SQRC)；中层：软件质量设计评价准则(SQDC)；低层：软件质量度量评价准则(SQMC)。
| 层 级 | 名 称 | 内 容 |
| 第一层 | 质量要素：描述和评价软件质量的一组属性 | 功能性、可靠性、易用性、效率性、可维护性、可移植性等质量特性以及将质量特性细化产生的副特性 |
| 第二层 | 衡量标准： 衡量标准的组合反映某一软件质量要素 | 精确性、稳健性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、文件完备性等 |
| 第三层 | 量度标准： 可由各使用单位自定义 |
根据软件的需求分析、概要设计、详细设计、编码、测试、确认、维护与使用等阶段，针对每一个阶段制定问卷表，以此实现软件开发过程的质量度量 |
表7-3 软件质量度量FCM模型
凯悦(Lawrence E. Hyatt)和罗森贝克(Linda H. Rosenberg)在《识别项目风险以及评价软件质量的软件质量模型与度量》(A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality)中比较了这3种最常用的软件质量模型，其基本情况如表5-14所示。
| 度量标准/目标 | 麦 考 尔 | 勃 姆 | ISO 9126 |
| 正确性(Correctness) | X | X | 可维护性 |
| 可靠性(Reliability) | X | X | X |
| 完整性(Integrity) | X | X | |
| 可用性(Usability) | X | X | X |
| 效率性(Efficiency) | X | X | X |
| 可维护性(Maintainability) | X | X | X |
| 可测试性(Testability) | X | 可维护性 | |
| 互操作性(Interoperability) | X | ||
| 适应性(Flexibility) | X | X | |
| 可重用性(Reusability) | X | X | |
| 可移植性(Portability) | X | X | X |
| 明确性(Clarity) | X | ||
| 可变更性(Modifiability) | X | 可维护性 | |
| 文档化(Documentation) | X | ||
| 恢复力(Resilience) | X | ||
| 易懂性(Understandability) | X | ||
| 有效性(Validity) | X | 可维护性 | |
| 功能性(Functionality) | X | ||
| 普遍性(Generality) | X | ||
| 经济性(Economy) | X |
表7-4 3种软件质量模型之比较
软件质量度量方法
软件质量度量方法比较多，例如：(1)Halstead复杂性度量法，基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。(2)McCabe复杂性度量法，其基本思想是程序的复杂性很大程度上取决于程序控制流的复杂性，单一的顺序程序结构最简单，循环和选择所构成的环路越多，程序就越复杂。
◆ 过程度量
软件过程性能
过程度量是对软件开发过程的各个方面进行度量，目的在于预测过程的未来性能，减少过程结果的偏差，对软件过程的行为进行目标管理，为过程控制、过程评价持续改善提供定量性基础。过程度量与软件开发流程密切相关，具有战略性意义。软件过程质量的好坏会直接影响软件产品质量的好坏，度量并评估过程、提高过程成熟度可以改进产品质量。相反，度量并评估软件产品质量会为提高软件过程质量提供必要的反馈和依据。过程度量与软件过程的成熟度密切相关，其度量模型如图7-2所示：
图7-2 软件过程性能的度量模型
软件过程管理中的过程度量
弗罗哈克(William A.Florac)、帕克(Robert E.Park)和卡尔顿(Anita D.Carleton)在《实用软件度量：过程管理和改善之度量》(Practical Software Measurement：Measuring for Process Management and Improvement)中描述了过程管理和项目管理的关系。认为软件项目团队生产产品基于三大要素：产品需求、项目计划和已定义软件过程。度量数据在项目管理中将被用来：(1)识别和描述需求，(2)准备能够实现目标的计划，(3)执行计划，(4)跟踪基于项目计划目标的工作执行状态和进展。而过程管理也能使用相同的数据和相关度量来控制和改善软件过程本身。这就意味着，软件组织能使用建构和维持度量活动的共同框架来为过程管理和项目管理两大管理功能提供数据。
软件过程管理包括定义过程、计划度量、执行软件过程、应用度量、控制过程和改善过程，其中计划度量和应用度量是软件过程管理中的重要步骤，也是软件过程度量的核心内容。计划度量建立在对已定义软件过程的理解之上，产品、过程、资源的相关事项和属性已经被识别，收集和使用度量以进行过程性能跟踪的规定都被集成到软件过程之中。应用度量通过过程度量将执行软件过程所获得的数据，以及通过产品度量将产品相关数据用来控制和改善软件过程。
软件过程度量的内容
软件过程度量主要包括三大方面的内容，一是成熟度度量(maturity metrics)，主要包括组织度量、资源度量、培训度量、文档标准化度量、数据管理与分析度量、过程质量度量等等；二是管理度量(management metrics)，主要包括项目管理度量(如里程碑管理度量、风险度量、作业流程度量、控制度量、管理数据库度量等)、质量管理度量(如质量审查度量、质量测试度量、质量保证度量等)、配置管理度量(如式样变更控制度量、版本管理控制度量等)；三是生命周期度量(life cycle metrics)，主要包括问题定义度量、需求分析度量、设计度量、制造度量、维护度量等。
软件过程度量流程
软件过程的度量，需要按照已经明确定义的度量流程加以实施，这样能使软件过程度量作业具有可控制性和可跟踪性，从而提高度量的有效性。软件过程度量的一般流程主要包括：确认过程问题；收集过程数据；分析过程数据；解释过程数据；汇报过程分析；提出过程建议；实施过程行动；实施监督和控制。这一度量过程的流程质量能保证软件过程度量获得有关软件过程的数据和问题，并进而对软件过程实施改善。
本来想发一篇关于"功能点"的文章，不过想来想去还是这个比较好 ：）
有需要＂功能点快速参考手册＂的朋友请留下Ｅ－ＭＡＩＬ，我会发给大家的．
