软件产品的规模度量-功能点与代码行.doc

软件产品的规模度量 -功能点与代码行 功能点与代码行，谁将最后胜出？作者：肖鹤 功能点与代码行，作为两种度量方法已经长期并存又竞争，他们的支持者已进行了大量的争论，如今这种争论仍未停息。人们似乎想看到：功能点与代码行，到底谁将最后胜出？ 众所周知，用“平方米”可以衡量住房大小，用“台”可以表示汽车数量，然而，长久以来，软件产品的规模（ Size）度量却是个争论不休的问题。不论是对软件开发企业、还是对软件用户，软件规模度量的重要性都是不容置疑的。因为它极大影响着甲方对发包产品的成本估算、乙方对自身开发成本的预测、乙方对开发过程的量化管理等诸多方面。比如， A 软件项目的规模是 100 功能点，我们根据行业基准（ Benchmarking）知道平均成本是 5000 元 /功能点，那么本项目的成本预测就是50 万元；我们又根据行业基准知道平均生产率为 1 功能点 /人天， 则计算得到项目需要投入 100 个人天的工作量，这些计算的结果将成为签定合同的依据和软件项目管理的基础。功能点与代码行，作为两种度量方法已经长期并存又竞争，他们的支持者已进行了大量的争论，如今这种争论仍未停息。人们似乎想看到：功能点与代码行，到底谁将最后胜出？国际软件工程权威专家 Roger S. Pressman在 2001 年曾经对 LOC 和 FP 的辩论结果进行总结 [1]：代码行的支持者认为， LOC是所有软件开发项目的生成品，并且很容易进行计算；许多现有的软件估算模型使用 LOC作为输入，并且关于 LOC已经有大量的文献 数据。代码行的反对者认为，LOC 测量依赖于程序设计语言；它们对设计的很好但较小的程序会产生不利的评判；它们不适合于非过程语言；它们在估算时需要一些可能难以得到的信息（例如，在分析和设计之前，计划者就必须估算要产生的 LOC）。功能点（及其扩展）的支持者认为： FP 和程序设计语言无关，使得它既适合于传统的语言，也可用于非过程语言；它是基于项目开发初期就可能得到的数据。反对者声称：该方法需要某种“人的技巧”，因为计算是基于主观的而非客观的数据；信息域（及其它维）的计算可能难以搜集事后信息； FP 没有直接的物理含义 — 它仅仅是个数据而已。 究竟如何看待这些争论？笔者认为应该用发展的眼光来判断，特别是考虑近年来软件开发技术的迅猛发展以及国际软件产业商业模式的变革趋势。最近的