功能点与代码行，谁将最后胜出？一

　　功能点与代码行，作为两种度量方法已经长期并存又竞争，他们的支持者已进行了大量的争论，如今这种争论仍未停息。人们似乎想看到：功能点与代码行，到底谁将最后胜出？
　　众所周知，用"平方米"可以衡量住房大小，用"台"可以表示汽车数量，然而，长久以来，软件产品的规模（Size）度量却是个争论不休的问题。
　　不论是对软件开发企业、还是对软件用户，软件规模度量的重要性都是不容置疑的。因为它极大影响着甲方对发包产品的成本估算、乙方对自身开发成本的预测、乙方对开发过程的量化管理等诸多方面。
　　比如，A软件项目的规模是100功能点，我们根据行业基准（Benchmarking）知道平均成本是5000元/功能点，那么本项目的成本预测就是50万元；我们又根据行业基准知道平均生产率为1功能点/人天，则计算得到项目需要投入100个人天的工作量，这些计算的结果将成为签定合同的依据和软件项目管理的基础。
　　功能点与代码行，作为两种度量方法已经长期并存又竞争，他们的支持者已进行了大量的争论，如今这种争论仍未停息。
　　人们似乎想看到：功能点与代码行，到底谁将最后胜出？
　　国际软件工程权威专家Roger S. Pressman在2001年曾经对LOC和FP的辩论结果进行总结[1]：
　　
　　代码行的支持者认为，LOC是所有软件开发项目的生成品，并且很容易进行计算；许多现有的软件估算模型使用LOC作为输入，并且关于LOC已经有大量的文献数据。

　　代码行的反对者认为，LOC测量依赖于程序设计语言；它们对设计的很好但较小的程序会产生不利的评判；它们不适合于非过程语言；它们在估算时需要一些可能难以得到的信息（例如，在分析和设计之前，计划者就必须估算要产生的LOC）。

　　功能点（及其扩展）的支持者认为：FP和程序设计语言无关，使得它既适合于传统的语言，也可用于非过程语言；它是基于项目开发初期就可能得到的数据。

　　反对者声称：该方法需要某种"人的技巧"，因为计算是基于主观的而非客观的数据；信息域（及其它维）的计算可能难以搜集事后信息；FP没有直接的物理含义- 它仅仅是个数据而已。
最近的技术发展包括诸如可视化编程工作的大量采用，以及摸板库、类库的广泛采用，在程序的结果中有大量的自动生成的代码、复杂的自动配置脚本或资源文件设置，在采用这些工具的项目中，用LOC分析方法得到的数据的意义已经大大降低了。
有研究者认为，LOC在帮助管理者开展项目管理方面也差强人意，LOC只是对技术人员有一定意义。