功能點與代碼行，誰將最后勝出？

　　功能點與代碼行，作為兩種度量方法已經長期并存又競爭，他們的支持者已進行了大量的爭論，如今這種爭論仍未停息。人們似乎想看到：功能點與代碼行，到底誰將最后勝出？
  
　　眾所周知，用“平方米”可以衡量住房大小，用“臺”可以表示汽車數量，然而，長久以來，軟件產品的規模（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指出，“使用代碼行數進行涉及多種語言和生命周期活動的生產率研究，應該被認為是一種職業的不良實踐?！?/P>

原文轉自：http://www.kjueaiud.com