功能點與代碼行，作為兩種度量方法已經(jīng)長期并存又競爭，他們的支持者已進行了大量的爭論，如今這種爭論仍未停息。人們似乎想看到：功能點與代碼行，到底誰將最后勝出？
眾所周知，用“平方米”可以衡量住房大小，用“臺”可以表示汽車數(shù)量，然而，長久以來，軟件產(chǎn)品的規(guī)模（Size）度量卻是個爭論不休的問題。
不論是對軟件開發(fā)企業(yè)、還是對軟件用戶，軟件規(guī)模度量的重要性都是不容置疑的。因為它極大影響著甲方對發(fā)包產(chǎn)品的成本估算、乙方對自身開發(fā)成本的預(yù)測、乙方對開發(fā)過程的量化管理等諸多方面。
比如，A軟件項目的規(guī)模是100功能點，我們根據(jù)行業(yè)基準(zhǔn)（Benchmarking）知道平均成本是5000元/功能點，那么本項目的成本預(yù)測就是50萬元；我們又根據(jù)行業(yè)基準(zhǔn)知道平均生產(chǎn)率為1功能點/人天，則計算得到項目需要投入100個人天的工作量，這些計算的結(jié)果將成為簽定合同的依據(jù)和軟件項目管理的基礎(chǔ)。
功能點與代碼行，作為兩種度量方法已經(jīng)長期并存又競爭，他們的支持者已進行了大量的爭論，如今這種爭論仍未停息。
人們似乎想看到：功能點與代碼行，到底誰將最后勝出？
國際軟件工程權(quán)威專家Roger S. Pressman在2001年曾經(jīng)對LOC和FP的辯論結(jié)果進行總結(jié)[1]：
代碼行的支持者認為，LOC是所有軟件開發(fā)項目的生成品，并且很容易進行計算；許多現(xiàn)有的軟件估算模型使用LOC作為輸入，并且關(guān)于LOC已經(jīng)有大量的文獻數(shù)據(jù)。
代碼行的反對者認為，LOC測量依賴于程序設(shè)計語言；它們對設(shè)計的很好但較小的程序會產(chǎn)生不利的評判；它們不適合于非過程語言；它們在估算時需要一些可能難以得到的信息（例如，在分析和設(shè)計之前，計劃者就必須估算要產(chǎn)生的LOC）。
功能點（及其擴展）的支持者認為：FP和程序設(shè)計語言無關(guān)，使得它既適合于傳統(tǒng)的語言，也可用于非過程語言；它是基于項目開發(fā)初期就可能得到的數(shù)據(jù)。
反對者聲稱：該方法需要某種“人的技巧”，因為計算是基于主觀的而非客觀的數(shù)據(jù)；信息域（及其它維）的計算可能難以搜集事后信息；FP沒有直接的物理含義— 它僅僅是個數(shù)據(jù)而已。
究竟如何看待這些爭論？筆者認為應(yīng)該用發(fā)展的眼光來判斷，特別是考慮近年來軟件開發(fā)技術(shù)的迅猛發(fā)展以及國際軟件產(chǎn)業(yè)商業(yè)模式的變革趨勢。
最近的技術(shù)發(fā)展包括諸如可視化編程工作的大量采用，以及摸板庫、類庫的廣泛采用，在程序的結(jié)果中有大量的自動生成的代碼、復(fù)雜的自動配置腳本或資源文件設(shè)置，在采用這些工具的項目中，用LOC分析方法得到的數(shù)據(jù)的意義已經(jīng)大大降低了[2]。
從產(chǎn)業(yè)商業(yè)模式來看，由于軟件系統(tǒng)已經(jīng)變的的更大和更復(fù)雜，軟件工程化分工加劇，專門從事軟件下游業(yè)務(wù)的商業(yè)組織大量涌現(xiàn)，特別是隨著國際產(chǎn)業(yè)轉(zhuǎn)移帶來的服務(wù)外包的巨大發(fā)展，需求和架構(gòu)設(shè)計等上游工程與詳細設(shè)計、編碼、測試、信息錄入和處理等下游工程分別在不同的組織中實現(xiàn)。上下游組織之間在業(yè)務(wù)管理和開發(fā)技術(shù)方面的的溝通需要更加標(biāo)準(zhǔn)化的度量語言。而實際上，LOC從來沒有在滿足客戶需求方面有什么重大意義，代碼行數(shù)對客戶來說沒有什么實際意義，客戶關(guān)心的是“功能”。
有研究者[2]認為，LOC在幫助管理者開展項目管理方面也差強人意，LOC只是對技術(shù)人員有一定意義。
實際上，LOC帶來的誤導(dǎo)越來越嚴重，以至于的軟件度量專家，美國軟件生產(chǎn)率研究所的首席科學(xué)家Capers，Jones指出，“使用代碼行數(shù)進行涉及多種語言和生命周期活動的生產(chǎn)率研究，應(yīng)該被認為是一種職業(yè)的不良實踐?！?BR>
眾所周知，用“平方米”可以衡量住房大小，用“臺”可以表示汽車數(shù)量，然而，長久以來，軟件產(chǎn)品的規(guī)模（Size）度量卻是個爭論不休的問題。
不論是對軟件開發(fā)企業(yè)、還是對軟件用戶，軟件規(guī)模度量的重要性都是不容置疑的。因為它極大影響著甲方對發(fā)包產(chǎn)品的成本估算、乙方對自身開發(fā)成本的預(yù)測、乙方對開發(fā)過程的量化管理等諸多方面。
比如，A軟件項目的規(guī)模是100功能點，我們根據(jù)行業(yè)基準(zhǔn)（Benchmarking）知道平均成本是5000元/功能點，那么本項目的成本預(yù)測就是50萬元；我們又根據(jù)行業(yè)基準(zhǔn)知道平均生產(chǎn)率為1功能點/人天，則計算得到項目需要投入100個人天的工作量，這些計算的結(jié)果將成為簽定合同的依據(jù)和軟件項目管理的基礎(chǔ)。
功能點與代碼行，作為兩種度量方法已經(jīng)長期并存又競爭，他們的支持者已進行了大量的爭論，如今這種爭論仍未停息。
人們似乎想看到：功能點與代碼行，到底誰將最后勝出？
國際軟件工程權(quán)威專家Roger S. Pressman在2001年曾經(jīng)對LOC和FP的辯論結(jié)果進行總結(jié)[1]：
代碼行的支持者認為，LOC是所有軟件開發(fā)項目的生成品，并且很容易進行計算；許多現(xiàn)有的軟件估算模型使用LOC作為輸入，并且關(guān)于LOC已經(jīng)有大量的文獻數(shù)據(jù)。
代碼行的反對者認為，LOC測量依賴于程序設(shè)計語言；它們對設(shè)計的很好但較小的程序會產(chǎn)生不利的評判；它們不適合于非過程語言；它們在估算時需要一些可能難以得到的信息（例如，在分析和設(shè)計之前，計劃者就必須估算要產(chǎn)生的LOC）。
功能點（及其擴展）的支持者認為：FP和程序設(shè)計語言無關(guān)，使得它既適合于傳統(tǒng)的語言，也可用于非過程語言；它是基于項目開發(fā)初期就可能得到的數(shù)據(jù)。
反對者聲稱：該方法需要某種“人的技巧”，因為計算是基于主觀的而非客觀的數(shù)據(jù)；信息域（及其它維）的計算可能難以搜集事后信息；FP沒有直接的物理含義— 它僅僅是個數(shù)據(jù)而已。
究竟如何看待這些爭論？筆者認為應(yīng)該用發(fā)展的眼光來判斷，特別是考慮近年來軟件開發(fā)技術(shù)的迅猛發(fā)展以及國際軟件產(chǎn)業(yè)商業(yè)模式的變革趨勢。
最近的技術(shù)發(fā)展包括諸如可視化編程工作的大量采用，以及摸板庫、類庫的廣泛采用，在程序的結(jié)果中有大量的自動生成的代碼、復(fù)雜的自動配置腳本或資源文件設(shè)置，在采用這些工具的項目中，用LOC分析方法得到的數(shù)據(jù)的意義已經(jīng)大大降低了[2]。
從產(chǎn)業(yè)商業(yè)模式來看，由于軟件系統(tǒng)已經(jīng)變的的更大和更復(fù)雜，軟件工程化分工加劇，專門從事軟件下游業(yè)務(wù)的商業(yè)組織大量涌現(xiàn)，特別是隨著國際產(chǎn)業(yè)轉(zhuǎn)移帶來的服務(wù)外包的巨大發(fā)展，需求和架構(gòu)設(shè)計等上游工程與詳細設(shè)計、編碼、測試、信息錄入和處理等下游工程分別在不同的組織中實現(xiàn)。上下游組織之間在業(yè)務(wù)管理和開發(fā)技術(shù)方面的的溝通需要更加標(biāo)準(zhǔn)化的度量語言。而實際上，LOC從來沒有在滿足客戶需求方面有什么重大意義，代碼行數(shù)對客戶來說沒有什么實際意義，客戶關(guān)心的是“功能”。
有研究者[2]認為，LOC在幫助管理者開展項目管理方面也差強人意，LOC只是對技術(shù)人員有一定意義。
實際上，LOC帶來的誤導(dǎo)越來越嚴重，以至于的軟件度量專家，美國軟件生產(chǎn)率研究所的首席科學(xué)家Capers，Jones指出，“使用代碼行數(shù)進行涉及多種語言和生命周期活動的生產(chǎn)率研究，應(yīng)該被認為是一種職業(yè)的不良實踐?！?BR>