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

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

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

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

　　反对者声称：该方法需要某种“人的技巧”，因为计算是基于主观的而非客观的数据；信息域（及其它维）的计算可能难以搜集事后信息；FP没有直接的物理含义— 它仅仅是个数据而已。
 
　　究竟如何看待这些争论？笔者认为应该用发展的眼光来判断，特别是考虑近年来软件开发技术的迅猛发展以及国际软件产业商业模式的变革趋势。
 
　　最近的技术发展包括诸如可视化编程工作的大量采用，以及摸板库、类库的广泛采用，在程序的结果中有大量的自动生成的代码、复杂的自动配置脚本或 资源文件设置，在采用这些工具的项目中，用LOC分析方法得到的数据的意义已经大大降低了[2]。
 
　　从产业商业模式来看，由于软件系统已经变的的更大和更复杂，软件工程化分工加剧，专门从事软件下游业务的商业组织大量涌现，特别是随着国际产业转移带来的服务外包的巨大发展，需求和架构设计等上游工程与详细设计、编码、测试、信息录入和处理等下游工程分别在不同的组织中实现。上下游组织之间在业务管理和开发技术方面的的 沟通需要更加 标准化的度量语言。而实际上，LOC从来没有在满足客户需求方面有什么重大意义，代码行数对客户来说没有什么实际意义，客户关心的是“功能”。
 
　　有研究者[2]认为，LOC在帮助管理者开展项目管理方面也差强人意，LOC只是对技术人员有一定意义。
 
　　实际上，LOC带来的误导越来越严重，以至于著名的软件度量专家，美国软件生产率研究所的首席科学家Capers，Jones指出，“使用代码行数进行涉及多种语言和生命周期活动的生产率研究，应该被认为是一种职业的不良实践。”

原文转自：http://www.ltesting.net