1 什么叫软件项目估计

　　众所周知，软件项目估计是软件项目开发活动的重要环节，但是，目前国内外还没有一个对软件项目定义的统一概念。大家都知道，软件项目估计包括对软件项目的规模、工作量和成本和BUG数等估计。但一些更细的问题还值得我们去深思和考虑，如

◇　估计的对象是什么，

◇ 什么时间进行估计，

◇ 什么时候对估计的监视和跟踪，

◇ 估计的准确性标准是什么，什么是有效的估计，

◇ 哪些工作算估计的工作量，

◇ 如何选择估计的方法和工具，

◇ 估计应遵守的原则和态度是什么，什么叫真诚估计，

◇ 什么人才能做估计人员，要有些什么知识和经验，为什么要做软件项目估计，

◇ 更深层次的问题，什么是估计文化，她包含哪些内容等（在英文中评估和估计是同一个词estimations，但从汉角度理解，评估可以是对现有对象预测，如房产评估，整体资产评估，而估计偏向于对未成形的客观事务的预测，如企业产品市场占有率估计等）。

　　软件项目估计的对象是整个软件项目呢？还是项目的工作产品。根据SEI的SW_CMM模型定义，软件工作产品和软件产品不同，软件工作产品是指在软件项目开发过程中产生的各种工作产品，它包括需求分析说明书、设计说明书，源代码等工程产品也包括项目管理的工作产品如周报，配置管理报告等。而软件产品是指交付给客户的软件工作产品，它是软件工作产品的一个子集，如执行代码，用户手册和维护手册等。我们认为，软件项目估计是一个课题，估计对象必须是客观的，具体来说估计对象可以是需求分析说明书，执行代码和测试用例和最终提交给客户的软件系统或者它的一个子系统等，当然，一般概念的软件项目估计是指提交给客户的软件系统的规模、完成它所需要的工作量和成本估计。软件系统规模可以用功能点，特征点和对象点以及执行程序代码行等数据和单位来度量，需求分析说明书的规模也可以用系统功能点，特征点和对象点等来度量，但也有用需求说明书文档的大小和页数来度量的。同样，设计说明书，测试用例等都可以用系统的功能点，特征点和对象点来度量，也可以用文档的大小和页数来衡量。只是各种度量方法之间要有一个很好的可兑换性。换句话，从理论上讲，需求分析说明书上的规模和最终提交给客户的软件系统的规模是一致的。但BUG数、工作量和成本的估计就不一样， 软件系统的BUG数、所需的工作量和成本，不是需求分析说明书、设计说明书、源代码等对象的估计值 ，而是需求分析说明书、设计说明书、源代码等对象的BUG数、工作量和成本的估计总和。

　　什么时候进行软件项目的估计？什么时候对估计的监视和跟踪?一般认为，软件项目估计只是在项目启动前的工作，其实不是这样，在整个软件开发和维护都有估计活动。如图1所示。当然，具体估计时间随着估计的方法和估计的对象不同会有区别。因为不同的度量方法要求具备的软件项目资料准确度不一样。

　　我们认为软件规模估计和软件规模度量不同，软件规模估计是在软件工作产品没有完成之间对软件工程产品的估计，而度量活动应在软件工作产品完成之后。当然，大部分软件度量方法也可以用来进行软件规模估计。同时，软件规模估计和软件规模度量一样可以在软件生命周期的每一个阶段进行。作为估计活动，软件规模估计也应该有计划和跟踪过程。

　　　　　　　　　　　　　图1 软件项目估计时间示意图

　　图例说明：
　　　　1＝初步估计
　　　　2＝可信赖的估计（它是软件项目管理如计划的基础）
　　　　3...7＝估计新对象和对以前估计的跟踪
　　　　7＝以文档的方式总结以前的估计
　　　　8＝维护期的估计，如对客户新需求的估计

　　在软件企业，特别是我国的软件企业，估计人员往往迫于领导要求尽快估计的压力，草率地完成估计，导致错误的估计，影响项目的开发。事实上，估计人员应根据估计对象的具体情况，制定不同的估计计划，计划内容可以包括估计的对象说明，估计人员的角色和职责，估计的方法和估计，估计的风险识别，估计的工作量估计，估计活动进度安排（如收集估计的所需的信息安排，包括软件需求，历史数据等，进行估计，估计结果确定等）。大的估计活动还需要取得参与估计人员对估计计划的承诺，交给机构高级管理者审阅后执行估计活动，确保估计活动顺利进行。

　　软件项目应在周例会或里程碑会议跟踪项目估计情况。并随着软件开发活动不断深入，在软件开发后阶段要对前一阶段的估计进行跟踪修正。随着软件开发不断进行，开发人员或估计人员对软件项目的具体细节越来越清楚，做出的估计结果也应该越来越精确（当然，软件估计结果首先要求是准确的，而后才追求精确）。

　　机构应收集这些估计数据（如图1中?所列活动），包括估计活动本身的数据如估计工作量和估计结果，为以后估计活动提供指导。

　　可以这样理解，软件项目估计是指以准确的调查资料和项目信息（如人员和设备信息）为依据，从估计对象的历史、现状和及其规律性出发，运用科学的方法，对估计对象的规模，所需工作量和成本进行的测定。那些临时凭个人经验一时凭灵感或感觉对软件项目规模和工作量的估计不是真正软件项目估计。软件项目估计是项目决策科学化的工具，是项目组编制计划、预见计划执行情况、加强计划指导的定量依据，也是企业改善经营管理的有效手段之一。同时，软件项目估计在软件贸易估价活动中起到重要的作用。

　　2 软件项目估计发展现状

　　目前，国际上已有许多软件规模估计方法，如功能点（Function Point ）、特征点（Feature Point）、对象点（Object Point）、德尔菲（Delphi）、模糊逻辑（Fuzzy Logic）、标准构件法（Standard Component ）等，这些方法随着各国研究者的不断研究细化又有许多具体的方法，如国际功能点用户协会（IFPUG The International Function Point Users' Group）提出的IFPUG方法、英国软件度量协会（UKSMA United Kingdom Software Metrics Association ）提出的Mk II FPA方法、荷兰功能点用户协会(NEFPUG Netherlands Function Point Users Group)提出的NESMA 方法以及软件度量共同协会(COSMIC the COmmon Software Metrics Consortium)提出的COSMIC-FFP方法，这些方法都属于Albrecht 功能点（Function Point ）方法的发展和细化。

　　目前大部分软件估计方法有工具支持（如表1所示）。国际上目前已经有一些组织吸收和积累世界各地软件企业的软件估计和度量数据，建立了被广泛使用的历史数据库，如在功能规模度量领域，有一个ISBSG（国际软件基准组织International Software Benchmarking Standards Group）数据库。另外，COCOMO II Estimating Model也有丰富的估计和度量数据提供。

表1 部分软件度量方法及其支持工具
方法 支持的工具
数据点（Data Points PCCALC, SoftCalc
对象点（Object Points） SoftCalc
特征点（Feature Points） Checkpoint/KnowledgePlan
IFPUG Checkpoint/KnowledgePlan,
PCCALC, ISBSG-Venturi,
Function Points Workbench
Mark II FPA MK II Function Points Analyzer
FFPv1 HierarchyMaster FFP, FPCAnalyzer
FFPv2 HierarchyMaster FFP (supportfor FFPv2 in development)

　　有些软件规模估计方法被国际标准化组织（ISO）纳入国际标准。如上面提到的IFPUG、Mk II FPA、NESMA和COSMIC-FFP方法。其中COSMIC-FFP是今年被国际标准化组织（ISO）正式批准纳入国际标准的，其标准号是ISO/IEC 19761:2003。软件度量共同协会COSMIC(the COmmon Software Metrics Consortium)是由澳大利亚、加拿大、芬兰、爱尔兰、意大利、日本、荷兰和英国的软件度量专家于1998年底自愿组成的，它的领导人是Alain Abran和Charles Symons。根据这些标准，国际上已有部分软件产品价格估计公司，专门从事软件价格的估计，软件规模的估计是他们工作的基础。但随着面向对象、组件重用以及极限编程等新的软件开发方法出现，不断有学者提出新的软件规模方法，如如构件点（Construction Points）、预测性对象点（Predictive Object Points）。软件规模估计已成为了软件工程研究领域的一个重要方向。

　　目前，我国从事软件规模估计方法研究的人员较少，田俊国等人曾在软件工程网的介绍德尔菲（Delphi）和功能点（Function Point ）法。中南大学的李建华、费耀平等人参考德尔菲（Delphi）法，提出了一种叫两两比较（Paired-comparisons）的估计方法。 北京计算机应用和仿真技术研究所汤铭端、吴际等人在《软件学报》上发表一种?quot;扩展功能点（EFP）"的软件规模估计方法,我国有部分人员研制了对象点度量方法的支持工具，如合肥大学的Li Xinke等人曾开发过一种用于面向对象软件度量的工具。

　　如上所叙，软件规模估计包括对许多不同的软件工作产品的估计，如"需求文档"、"设计文档"、"源代码"、"测试用例"等。随着估计对象不同，度量规模的单位也不同，就软件规模来说，衡量规模的单位有代码行、功能点个数、平均继承深度等。代码行LOC常用于源代码的规模估计，常使用的单位有SLOC（ Single Line of Code）、KLOC（Thousand Lines of Code）、LLOC（Logical Line of Code）、PLOC（Physical Line of Code）、(N)CLOC （ (Non) Commented Line of Code）、DSI（Delivered Source Instruction）。功能点可以用于"需求文档"、"设计文档"、"源代码"、"测试用例"度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。平均继承深度（Depth in Inheritance Tree）是对象点（Object Point）中一个度量方法。目前，国际上有部分学者（如德国的马歌德保大学的Mathias Lother等人）正在研究各种度量方法和单位之间的兑换性，并呼吁从事软件度量和估计工程和研究人员，在提出一种新的度量方法时候一定要考虑和其他方法之间的可兑换性。

　　西方国家和印度的企业实际应用软件项目度量和估计较多，有些企业还针对自己的行业特点开发适用于自己的软件项目估计工具如波音公司开发一种叫3-D功能点估计方法，3-D功能点识别了反映应用程序难题的3维（数据，功能，控制）。数据难题多是MIS／商业软件的典型，而科学／工程软件是功能难题多，实时软件是控制难题多。而波音软件正是集这三个方面于一身，所以，3-D功能点适合于波音软件的度量和估计。

　　我国大陆有部分企业也正在进行科学的软件规模估计和度量，但数量不多。Wu Simon在一次案例研究中调查过500家香港商业公司，发现进行过真正意义上的软件项目估计的企业有79％，还有21％的企业没有进行过科学的软件项目估计。

　　3 软件项目估计的基本准则

　　在软件项目估计活动过程中，一些软件从业人员往往会说，"软件项目估计有什么用，我们估计的时候可能有456个功能点，可到交付的时候却有600多个，根本就牛头不对马嘴"。是的，应用一些软件度量方法进行软件项目估计往往会给出一个精确的结果，如IFPUG功能点等，但是，我们认为，软件项目估计首先要求结果是准确的，也就是正确的，而后再进一步要求精确的。错误的估计将影响项目管理人员决策，影响项目的开发。正是因为这样，有些软件项目估计方法不给出精确的结果，如有些模糊逻辑法，而是给一个范围，如前面的例子，如果估计的时候说规模400～700个功能点，虽然和456个功能点比不够精确，但是准确的。

　　这并不是说软件项目估计就是主观想象，不可捉摸。在实际估计过程中可以借鉴一些实用的经验观点或者说行为准则来帮助减少估计的错误。如：

◇ 估计时间越早，错误越大

◇ 任何一个估计都比没有估计好

◇ 估计文档化做得越好，获得估计经验的机会越大

◇ 用于估计的资料数据越多，估计的结果越好

◇ 有关估计的对象的信息越准确，估计就越可能准确

◇ 估计的对象最好是比较小且工作单元是独立的

◇ 在估计过程中，大部分通讯因素往往会被忽略

◇ 虽然有各种估计方法和公式，没有1:1的转换公式

◇ 实事求是的估计人员越多，估计的结果越客观

◇ 估计的目的是用来做决策，而是估计完了就完了。

　　一个有效的软件项目估计应满足以下特点或要求

● 软件项目估计结果要能再现

　　如上所说，具有越多的项目准确信息，估计的结果越准确。这并不是说后面的估计可以和前面的估计完全不同，两者风马牛不相干。有效估计是这样，后面进行的估计在相同条件下，即拥有项目资料的相等的情况，不同的估计人员应用相同的估计方法，两者的结果是一样的。这就是项目估计结果的可再现性。当然，随着项目不断深入，估计人员应该会获得更多，更详细的项目资料，那么估计的结果应该也更加准确和精确。这种对估计过程进行比较可以为以后的估计积累更多的经验。事实上，对估计活动连续的跟踪可以建立一种机制，这种机制可以清楚的显示项目需求等变更情况。（有人在连续进行软件项目估计的企业做过调查，他们发现，在项目的过程中，一般每月会有1～3％需求蔓延）

● 应用了多种估计方法

采用多种估计方法可以从不同的角度比较估计结果，减少估计的错误和保证安全

● 估计结果要经过事实求实地推敲和质疑

● 估计过程是可管理和控制的

● 估计过程是文档化

　　4 软件项目估计方法

　　大部分估计方法主要是提供一个对估计对象的规模的度量，在此基础上，可以算出相关的工作量和成本。如果是对整个项目进行估计，得到的总体的成本可以根据一个百分比分配到软件开发的每一个阶段。现在有许多不同的著名估计方法。Wide-band Delphi其实是估计过程向导，模糊逻辑法的目的是借助模糊逻辑理论，拟定量计算估计项目和参考项目的相似度，从而根据历史项目（参考项目）的历史数据计算估计项目的规模，这要求机构有历史数据并且收集的历史数据是有效的。代码行、功能点和对象点等方法是根据软件项目（或产品）的特征提出的软件估计方法。从文献来看，功能点方法是一种目前最受拥戴的方法，Cocomo模型也广泛地被使用。在原理上，功能点方法和Cocomo模型都是基于客户需求或软件规模估计工作量。

　　代码行的缺点是要等到项目的最后阶段才能得到，而且编码一般只占10％左右系统开发工作量。如前文所叙，功能点方法的优势可以从目前有许多不同的功能点方法这个方面体现出来。 功能点方法的缺点是在项目的早期阶段如需求分析阶段得不到项目足够的准确信息，可能估计的结果不过准确和足够精确。但无论如何，不考虑目前提出的一些新的估计方法如构件点（Construction Points）、预测性对象点（Predictive Object Points）等未来的发展，功能点方法是目前最受欢迎和广泛使用的方法，目前被国际标准化组织纳入国际标准的方法都是功能点方法。

　　自从1979年IBM的Albrecht提出第一个在世界范围内有影响的功能点方法以来，许多针对原著变革、扩展的可供选择的方法被提出来。图2以时间顺序显示了包括那些在下面要详细描述的方法的演变重要阶段。方法之间的箭头表示各个扩展版本的相互影响。图中显示最近的方法是COSMIC全面功能点。功能分析方法度量过程是对软件功能和规模的间接定量度量，它基于客观的外部应用接口和主观的内部应用复杂度以及总体的性能特征，它包括三个逻辑部分组成：未调整的功能点、加权因子和功能点：

　　功能大小（the functional size），通过度量每一个独立的功能进行计算。这是指未调整的功能点（UFP unadusted function points）的度量过程。这个方面又包括数据流功能类型度量和事物功能类型度量，包括对外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件的计数。

图2功能点方法发展历程

　　 加权因子值（VAF the value adjustment factor），它通过规则中定义好了一般系统特征（ GSC general systems characteristics ）针对软件的总体环境和处理过程的复杂度计算确定。包括划定系统、输入和输出、应用复杂度的级别。

　　图3是功能点估计模型。功能点分析方法的结果是指调整过的功能点，它是用加权因子值值对未调整的功能点（UFP unadusted function points）调整的结果。

图3 功能点估计模型

　　目前FPA方法主要是指IFPUG方法，它被许多机构广泛使用。但它有许多缺陷，其中之一就是他很难适用于MIS以外的软件。1996年，加拿大人Alain Abran等人提出了全面功能点方法（Full Function Points），它扩展IFPUG方法，可以用于实时和嵌入式软件。成立于1998年，以Alain Abran和Charles Symons（Mk II FPA 提出人）为首的软件度量共同协会COSMIC集中了八个国家40多位的软件度量专家，综合考虑了IFPUG，MarkII,NESMA和FFP1.O版的优缺点，通过了大量项目实践，于1999年11发布了COSMIC-FFP2.0版。其实，在探索系统和实时软件规模的道路上，在全面功能点方法之前还有"Bang 度量"、"3-D功能点" 、"特征点"等方法被提出。

　　DeMarco's的咨询活动常常使得他面临比MIS系统更加复杂的软件系统。1982他提出了Bang度量方法来度量系统和科学软件的规模[17]。但是由于方法太繁琐并且没有工具支持，目前这种方法几乎没有人使用。

　　3-D功能点是波音计算机服务公司1991年开发的一种覆盖系统软件（包括科学和实时领域）的度量方法。3-D功能点识别了反映应用程序难题的3维（数据，功能，控制）。数据难题多是MIS／商业软件的典型，而科学／工程软件是功能难题多，实时软件是控制难题多[18]。 但目前该方法除了波音公司使用外，没有其他企业使用。

　　1998美国Artemis国际咨询公司控股的软件生产力研究有限责任公司（Software Productivity Research, Inc）开发了基于功能点一种实践模型～特征点规模估计模型。特征点是IFPUG功能点4.0版的扩展，它加入一个运算法则的参数。据SPR介绍特征点规模估计方法更加适合于系统和实时软件的度量，但也能用于MIS系统。对于MIS应用程序，特征点和IFPUG功能点的度量结果几乎一样。但没有充分的数据显示它能够稳定地进行使用，它具有很好的可再现性和可重复性。目前SPR也停止了该方法的支持。

　　功能点估计方法有很多，它的优点是它已经作为一种广泛使用的方法被接受，目前正式软件规模度量的主流方法；通过ISO组织有四种方法成为了国际标准，他们是

◇ 全面功能点版本2.1（Full Function Points version 2.1），

◇ IFPUG 功能点（IFPUG Function Points），

◇ Mark II功能点（ Mark II Function Points），

◇ NESMA 功能点；

　　但功能点估计方法也有许多需要克服的问题。Kemerer 引用了Pressmann观点[13]："功能点估计，像 LOC，也有相关的争议…反对者说道，这种方法不是完全客观和依靠数据，而是更多地需要一些基于主观的计算手段…"；Capers Jones 发现，FP计算方法的变量结果可以在超过+/- 50％范围内变化。还有G. Low 和D.R. Jeffery 也发表过声明，"在组织内，功能点计算变化的范围大约平均在30％之内…"。由此可见，可再现性和客观性是功能规模度量方法的核心问题。此外，点度量方法作为一种传统的度量方法，如何解决新技术所带来的问题也是研究者们必须思考的问题，如面向对象系统的规模度量，组件重用带来的实际开发功能规模和交付给客户的功能规模不同的问题等等。这就是我们为什么说目前有许多软件项目估计的公式，但还没有一个1:1的转换公式。

　　5 结束语

　　软件项目估计是指以准确的调查资料和项目信息（如人员和设备信息）为依据，从估计对象的历史、现状和及其规律性出发，运用科学的方法，对估计对象的规模，所需工作量和成本进行的测定。它是企业项目管理的有效手段之一，也是软件贸易活动中价格估计的重要手段。目前国际上有许多软件项目估计的方法和工具，有的已经成为国际标准。软件项目估计应该是可重复和再现的，这是软件项目估计准确与否可以实践的检查标准。

　　目前国内外已经有许多软件项目估计方法，有的方法已经被国际标准化组织纳入国际标准。 软件项目估计将是软件开发过程中一个重要过程，一个具有非常意义的工程活动。