软件项目估计

1、软件工程估计1什么叫软件工程估计众所周知，软件工程估计是软件工程开发活动的重要环节，但是，目前国内外还没有一个对软件工程定义的统_概 念。大家都知道，软件工程估计包括对软件工程的规模、工 作量和本钱和BUG数等估计。但一些更细的问题还值得我们 去深思和考虑，如O估计的对象是什么，O什么时间进行估计，什么时候对估计的监视和跟踪，O估计的准确性标准是什么，什么是有效的估计，哪些工作算估计的工作量，O如何选择估计的方法和工具，估计应遵守的原那么和态度是什么，什么叫真诚估计，O什么人才能做估计人员，要有些什么知识和经验，为什么 要做软件工程估计，更深层次的问题，什么是估计文化，她包含哪些内容等 （在英

2、文中评估和估计是同一个词estimations,但从汉角度 理解，评估可以是对现有对象预测，如房产评估，整体资产 评估，而估计偏向于对未成形的客观事务的预测，如企业产 品市场占有率估计等）。软件工程估计的对象是整个软件工程呢？还是工程的工 作产品。根据SEI的SW_CMM模型定义，软件工作产品和软件(Predictive Object Points)等未来的开展，功能点方法 是目前最受欢迎和广泛使用的方法，目前被国际标准化组织 纳入国际标准的方法都是功能点方法。自从1979年IBM的Albrecht提出第一个在世界范围内 有影响的功能点方法以来，许多针对原著变革、扩展的可供 选择的方法被提出来

3、。图2以时间顺序显示了包括那些在下 面要详细描述的方法的演变重要阶段。方法之间的箭头表示 各个扩展版本的相互影响。图中显示最近的方法是COSMIC全功能点。功能分析方法度量过程是对软件功能和规模的间 接定量度量，它基于客观的外部应用接口和主观的内部应用 复杂度以及总体的性能特征，它包括三个逻辑局部组成：未 调整的功能点、加权因子和功能点：功能大小(the functional size),通过度量每一个独 立的功能进行计算。这是指未调整的功能点(UFP unadusted function points)的度量过程。这个方面又包括数据流功能 类型度量和事物功能类型度量，包括对外部输入、外部输

4、出、外部查询、内部逻辑文件和外部接口文件的计数。图2功能点方法开展历程加权因子值(VAF the value adjustment factor), 它通过规那么中定义好了 一般系统特征(GSC general systems characteristics )针对软件的总体环境和处理过 程的复杂度计算确定。包括划定系统、输入和输出、应用复 杂度的级别。图3是功能点估计模型。功能点分析方法的结果是指调 整过的功能点，它是用加权因子值值对未调整的功能点(UFP unadusted function points)调整的结果。图3功能点估计模型目前FPA方法主要是指IFPUG方法，它被许多机构广泛

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

6、，在 全面功能点方法之前还有Bang度量、3-D功能点、特 征点等方法被提出。DeMarcos的咨询活动常常使得他面临比MIS系统更加复 杂的软件系统。1982他提出了 Bang度量方法来度量系统和科 学软件的规模17。但是由于方法太繁琐并且没有工具支 持，目前这种方法几乎没有人使用。3-D功能点是波音计算机服务公司1991年开发的一种覆 盖系统软件（包括科学和实时领域）的度量方法。3-D功能点 识别了反映应用程序难题的3维（数据，功能，控制）。数 据难题多是MIS/商业软件的典型，而科学/工程软件是功能 难题多，实时软件是控制难题多18。但目前该方法除了波 音公司使用外，没有其他企业使用。1

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

8、式软件规模度量的主流方法;通过ISO组织有四种方法成为了际标准，他们是全面功能点版本 2.1 (Full Function Points version 2. 1),O IFPUG 功能点(IFPUG Function Points), Mark II 功能点(Mark II Function Points), NESMA功能点;但功能点估计方法也有许多需要克服的问题。Kemerer引用了 Pressmann观点13：功能点估计，像LOC,也有相关的争议反对者说道，这种方法不是完全客观和依靠数 据，而是更多地需要一些基于主观的计算手段；Capers Jones发现，FP计算方法的变量结果可以在

9、超过+/- 50%范围内变化。还有G Low和D.R. Jeffery也发表过声明，在组织内，功能点计算变化的范围大约平均在30%之内， 由此可见，可再现性和客观性是功能规模度量方法的核心问 题。此外，点度量方法作为一种传统的度量方法，如何解决 新技术所带来的问题也是研究者们必须思考的问题，如面向 对象系统的规模度量，组件重用带来的实际开发功能规模和 交付给客户的功能规模不同的问题等等。这就是我们为什么 说目前有许多软件工程估计的公式，但还没有一个L1的转 换公式。5结束语软件估算是指以准确的调查数据和工程信息（如人员和设 备信息）为基础，从估算对象的历史、现状和规律性出发，用 科学的方法对估

10、算对象的规模、工作量和本钱进行度量。它 是企业工程管理的有效手段之一，也是软件贸易活动中价格 估算的重要手段。目前，国际上有许多软件工程估算的方法 和工具，其中一些已经成为国际标准。软件工程估算应该是 可重复和可再现的，这是检验软件工程估算准确性的一个实 用标准。目前,内外有很多软件工程估算方法，其中一些已被际标准化组织纳入国际标准。软件评估将是软件开发过程中 的一个重要过程，也是一项非常重要的工程活动。产品不同，软件工作产品是指在软件工程开发过程中产生的 各种工作产品，它包括需求分析说明书、设计说明书，源代 码等工程产品也包括工程管理的工作产品如周报，配置管理 报告等。而软件产品是指交付给客

11、户的软件工作产品，它是 软件工作产品的一个子集，如执行代码，用户手册和维护手 册等。我们认为，软件工程估计是一个课题，估计对象必须 是客观的，具体来说估计对象可以是需求分析说明书，执行 代码和测试用例和最终提交给客户的软件系统或者它的一个 子系统等，当然，一般概念的软件工程估计是指提交给客户 的软件系统的规模、完成它所需要的工作量和本钱估计。软 件系统规模可以用功能点，特征点和对象点以及执行程序代 码行等数据和单位来度量，需求分析说明书的规模也可以用 系统功能点，特征点和对象点等来度量，但也有用需求说明 书文档的大小和页数来度量的。同样，设计说明书，测试用 例等都可以用系统的功能点，特征点和对

12、象点来度量，也可 以用文档的大小和页数来衡量。只是各种度量方法之间要有 一个很好的可兑换性。换句话，从理论上讲，需求分析说明 书上的规模和最终提交给客户的软件系统的规模是一致的。但BUG数、工作量和本钱的估计就不一样，软件系统的BUG 数、所需的工作量和本钱，不是需求分析说明书、设计说明 书、源代码等对象的估计值，而是需求分析说明书、设计说 明书、源代码等对象的BUG数、工作量和本钱的估计总和。什么时候进行软件工程的估计？什么时候对估计的监视 和跟踪?一般认为，软件工程估计只是在工程启动前的工作， 其实不是这样，在整个软件开发和维护都有估计活动。如图1 所示。当然，具体估计时间随着估计的方法和

13、估计的对象不 同会有区别。因为不同的度量方法要求具备的软件工程资料 准确度不一样。我们认为软件规模估计不同于软件规模度量。软件规模估 算是在软件工作产品完成之前对软件工程产品的估算，而度量活动应该在软件工作产品完成之后。当然，大多数软件度 量方法也可以用来估计软件规模。同时，软件规模估计和软 件规模度量可以在软件生命周期的每个阶段进行。作为一项 估算活动，软件规模估算也应该有一个计划和跟踪过程。图1软件工程估计时间示意图图例说明:图例说明:1 =初步估计2 =可信赖的估计（它是软件工程管理如计划的基础）3. 7=估计新对象和对以前估计的跟踪7=以文档的方式总结以前的估计8 =维护期的估计，如对

14、客户新需求的估计在软件企业中，尤其是在我国，估算人员往往迫于领导的 压力，不得不尽快进行估算，仓促完成估算，导致估算错 误，影响工程的开展。实际上，估算者应该根据估算对象的 具体情况，制定不同的估算方案。计划的内容可以包括对估才厂人、 IM -TV /、八八IIM 7r 八 gl 7 TZV、估算风险的识别、估算工作量的估算以及估算活动的时间表 （例如，收集估算所需的信息，包括软件需求、历史数据等。 进行估计并确定估计结果等。）.对于大型估算活动，还需要 获得估算人员对估算计划的承诺，并在实施估算活动之前提 交给组织的高级管理人员进行审查，以确保估算活动的顺利 进行。软件应该在每周或里程碑会议

15、上跟踪工程评估。随着软件 开发活动的深入，前一阶段的估算应在软件开发的后期进行 跟踪和修正。随着软件的不断开展，开发人员或估算人员对 软件工程的具体细节越来越清楚，估算的结果也应该越来越 准确（当然软件的估算结果应该是先准确，再准确）。机构应收集这些估计数据(如图1中？所列活动)，包括 估计活动本身的数据如估计工作量和估计结果，为以后估计 活动提供指导。可以这样理解，软件工程估算是指基于准确的调查数据和 工程信息(如人员和设备信息)，从估算对象的历史、现状和 规律性出发，运用科学的方法，对估算对象的规模、所需工 作量和本钱进行度量。那些暂时基于个人经验、灵感或感觉 的软件工程规模和工作量的估算

16、，并不是真正的软件工程估 算。软件估算是工程决策的科学工具，是工程组制定计划、 预见计划实施和加强计划指导的定量依据，也是企业提高管 理水平的有效手段之一。同时，软件工程评估在软件行业评 估中起着重要的作用。2软件工程估计开展现状目前，国际上已有许多软件规模估计方法，如功能点(Function Point )、特征点(Feature Point)、对象点(Object Point)、德尔菲(Delphi)、模糊逻辑(Fuzzy Logic)、标准构件法(Standard Component )等，这些方法随着各国研究者的不断研究细化又有许多具体的方法，如际功能点用户协会(IFPUG The I

17、nternational FunctionPoint Users* Group)提出的IFPUG方法、英国软件度量协 会(UKSMA United Kingdom Software MetricsAssociation )提出的Mk II FPA方法、荷兰功能点用户协会(NEFPUG Netherlands Function Point Users Group)提出 的NESMA方法以及软件度量共同协会(COSMIC the COmmon Software Metrics Consortium)提出的 COSMIC-FFP 方法，这 些方法都属于Albrecht功能点(Function Poi

18、nt )方法的 开展和细化。目前大局部软件估计方法有工具支持（如表1所示）。际上目前已经有一些组织吸收和积累世界各地软件企业的 软件估计和度量数据，建立了被广泛使用的历史数据库，如 在功能规模度量领域，有一个ISBSG （国际软件基准组织International Software Benchmarking Standards Group) 数据库。另外，COCOMO II Estimating Model也有丰富的估 计和度量数据提供。表1局部软件度量方法及其支持工具方法支持的工具数据 点(Data Points PCCALC, SoftCalc 对象点(Object Points) Sof

19、tCalc 特征点(Feature Points) Checkpoint/KnowledgePlan IFPUG Checkpoint/KnowledgePlan, PCCALC, ISBSG-Venturi, Function Points Workbench Mark II FPA MK II Function Points Analyzer FFPvl HierarchyMaster FFP, FPCAnalyzer FFPv2 HierarchyMaster FFP (supportfor FFPv2 in development)有些软件规模估计方法被国际标准化组织（ISO）纳入国际

20、标准。如上面提到的IFPUG、Mk II FPA、NESMA和COSMIC-FFP方法。其中COSMIC-FFP是今年被国际标准化组织（ISO）正式批准纳入国际标准的，其标准号是ISO/IEC19761 ：20XXo 软件度量共同协会 COSMIC （the COmmonSoftware Metrics Consortium）是由澳大利亚、加拿大、芬 兰、爱尔兰、意大利、日本、荷兰和英国的软件度量专家于1998年底自愿组成的，它的领导人是Alain Abran和Charles Symonso根据这些标准,际上已有局部软件产品价格估计公司，专门从事软件价格的估计，软件规模的估计 是他们工作的基础

21、。但随着面向对象、组件重用以及极限编 程等新的软件开发方法出现，不断有学者提出新的软件规模 方法,如如构件点（Construction Points）、预测性对象点(Predictive Object Points)。软件规模估计已成为了软 件工程研究领域的一个重要方向。目前，我国从事软件规模估计方法研究的人员较少，田俊国等人曾在软件工程网的介绍德尔菲(Delphi)和功能点(Function Point )法。中南大学的李建华、费耀平等人参考德尔菲(Delphi)法，提出了一种叫两两比拟(Paired-parisons) 的估计方法。北京计算机应用和仿真技术研究所 汤铭端、吴际等人在软件学报

22、上发表一种?quot;扩展功 能点(EFP) ”的软件规模估计方法，我国有局部人员研制了对 象点度量方法的支持工具，如合肥大学的Li Xinke等人曾开发过一种用于面向对象软件度量的工具。如上所叙，软件规模估计包括对许多不同的软件工作产 品的估计，如需求文档、设计文档、源代码、测试用 例”等。随着估计对象不同，度量规模的单位也不同，就软件 规模来说，衡量规模的单位有代码行、功能点个数、平均继 承深度等。代码行LOC常用于源代码的规模估计，常使用的 单位有 SLOC ( Single Line of Code)、KLOC (Thousand Lines of Code) 、 LLOC (Logi

23、cal Line of Code) 、 PLOC(Physical Line of Code) 、 (N)CLOC ( (Non) Commented Line of Code) 、 DSI (Delivered Source Instruction) o 功能点可以用于需求文档、设计文档、源代码、测试 用例”度量，根据具体方法和编程语言的不同，功能点可以转 换为代码行。平均继承深度(Depth in Inheritance Tree) 是对象点(Object Point)中一个度量方法。目前，国际上 有局部学者(如德国的马歇德保大学的Mathias Lother等 人)正在研究各种度量方法和

24、单位之间的兑换性，并呼吁从 事软件度量和估计工程和研究人员，在提出一种新的度量方 法时候一定要考虑和其他方法之间的可兑换性。西方国家和印度的企业实际应用软件工程度量和估计较 多，有些企业还针对自己的行业特点开发适用于自己的软件 工程估计工具如波音公司开发一种叫3-D功能点估计方法， 3-D功能点识别了反映应用程序难题的3维（数据，功能，控 制）。数据难题多是MIS/商业软件的典型，而科学/工程软 件是功能难题多，实时软件是控制难题多。而波音软件正是 集这三个方面于一身，所以，3-D功能点适合于波音软件的度 量和估计。我国大陆有局部企业也正在进行科学的软件规模估计和度量，但数量不多。Wu Sim

25、on在一次案例研究中调查过500家香港商业公司，发现进行过真正意义上的软件工程估计的 企业有79%,还有21%的企业没有进行过科学的软件工程估 计。3软件工程估计的基本准那么在软件工程估计活动过程中，一些软件从业人员往往会 说，软件工程估计有什么用，我们估计的时候可能有456个 功能点，可到交付的时候却有600多个，根本就牛头不对马 嘴。是的，应用一些软件度量方法进行软件工程估计往往会 给出一个精确的结果，如IFPUG功能点等，但是，我们认 为，软件工程估计首先要求结果是准确的，也就是正确的， 而后再进一步要求精确的。错误的估计将影响工程管理人员 决策，影响工程的开发。正是因为这样，有些软件工

26、程估计 方法不给出精确的结果，如有些模糊逻辑法，而是给一个范 围，如前面的例子，如果估计的时候说规模400700个功能 点，虽然和456个功能点比不够精确，但是准确的。这并不意味着软件工程估算是主观想象和不可预测的。在 实际估算过程中，可以借鉴一些实用的经验观点或行为准 那么，帮助减少估算误差。例如：O估计时间越早，错误越大任何一个估计都比没有估计好O估计文档化做得越好，获得估计经验的机会越大O用于估计的资料数据越多，估计的结果越好O有关估计的对象的信息越准确，估计就越可能准确估计的对象最好是比拟小且工作单元是独立的在估计过程中，大局部通讯因素往往会被忽略O虽然有各种估计方法和公式，没有L1的转换公式O实事求是的估计人员越多，估计的结果越客观估计的目的是用来做决策，而是估计完了就完了。一个有效的软件工程估计应满足以下特点或要求软件工程估计结果要能再现 确。这并不是说后面的估计可以和前面的估计完全不同，两 者风马牛不相干。有效估计是这样，后面进行的估计在相同 条件下，即拥有工程资料的相等