近年來，得益于數字經濟的快速發展，軟件同各類生産、生活場景的結合越來越緊密，各類應用層出不窮，工業軟件發展迅速，我國軟件服務産業規模持續擴大，有關數據顯示2021年，全國軟件和信息技術服務業規模以上企業超4萬家，累計完成軟件業務收入94994億元，同比增長17.7%在軟件行業快速發展的同時，我們也注意到行業發展過程中存在一些有待進一步解決的問題，本文從軟件信息系統項目成本度量的角度來闡明一些想法，我來為大家講解一下關于軟件項目成本估算方法主要有loc法?跟着小編一起來看一看吧!

　　 軟件項目成本估算方法主要有loc法

　　一、行業背景 近年來，得益于數字經濟的快速發展，軟件同各類生産、生活場景的結合越來越緊密，各類應用層出不窮，工業軟件發展迅速，我國軟件服務産業規模持續擴大，有關數據顯示2021年，全國軟件和信息技術服務業規模以上企業超4萬家，累計完成軟件業務收入94994億元，同比增長17.7%。在軟件行業快速發展的同時，我們也注意到行業發展過程中存在一些有待進一步解決的問題，本文從軟件信息系統項目成本度量的角度來闡明一些想法。

　　1．度量意義 項目成本包括采購成本、開發成本、維護成本、培訓成本、财務成本以及管理成本等，其中開發成本也可分為人力成本和非人力成本。人力成本包括直接人力成本和間接人力成本，直接人力成本指參與項目研發的人員的工資、福利、獎金等費用，間接人力成本指部分參與項目研發的人員的費用分攤。非人力成本包括直接非人力成本和間接非人力成本。直接非人力成本指直接服務于項目所産生的設備、培訓、差旅等費用，間接非人力成本指部分服務于某項目的費用分攤，如房租等。

　　從軟件項目實施過程來看，可以把軟件成本劃分軟件研制成本、軟件測試成本、軟件運維成本。我們一般将軟件需求分析、設計、編碼、集成、測試、上線發生的成本歸集為為軟件研制階段成本，軟件第三方測試發生的成本歸集為軟件測試成本，軟件維護發生的成本歸集為軟件運維成本，軟件升級發生的成本按研制成本進行歸集。軟件成本度量一直都是軟件行業的一個痛點問題，涉及投資規劃、采購、系統開發、系統維護、資産管理等各個環節，如果不能有效準備的評估軟件實施的成本，對軟件立項實施各環節都會造成一些影響，比如：

　　①　規劃投資部門無法有效評估項目投資規模；

　　②　采購部門無法有效評估項目投資合理性和開發商生産效率如何評定；

　　③　采購部門和開發部門的商務談判的報價如何評定；

　　④　業務部門軟件需求描述是否足夠清晰；

　　⑤　軟件範圍控制，需求變更和成本增加的平衡；

　　⑥　開發過程中是否存在過度設計，開發過程如何度量；

　　⑦　系統增強開發和維護成本度量；

　　⑧　軟件生命周期管理；

　　⑨　軟件資産核算和資産報廢的問題。

　　2．度量方法 軟件項目規模評估主要依據來自于用戶需求，包括功能需求和非功能需求，評估方法包括：DELPHI專家評估法、代碼行法（LOC）、類比法、故事點（Story Points）、用例點（UCP-UseCasePoints）、IFPUG、NESMA、COSMIC-FFP、UK-MarkII、COCOMOⅡ等，這些評估方法從度量角度大緻可以分為兩類，基于開發視角和業務視角。

　　基于技術視角的方法是從開發人員的角度，方法包括代碼行、數據庫表、函數、接口、服務的數量等等。基于開發視角的方法主要存在于技術人員之間，優勢是實現起來簡單容易，缺點是容易引起分歧，難以在項目初期進行度量，且難以在技術人員之外的其他人員之間得到應用，如公司之間、部門之間、用戶之間等。

　　基于業務視角的方法從用戶角度出發，如：功能點、故事點、用例點、對象點等方法。站在使用者的角度來進行度量，并能夠在項目初期得到應用，彌補技術度量方法的不足。

　　以下，我們針對代碼行法和功能點法這兩種表達形式做個比較：

　　1. 代碼行法：SLOC， 側重實施角度，如何做

　　(1) 曆史數據或專家意見（Pert/Delphi）

　　(2) 用于度量程序開發中的智能工作量

　　(3) 規模同語言、設計關系密切，技術視角

　　(4) 多用于實施方内部核算使用

　　2. 功能點法：FP，側重用戶角度，做什麼

　　(1) 基于軟件功能數和獨立的項目因子

　　(2) 基于需求，項目早期可以得到的信息

　　(3) 獨立于軟件開發語言，用于視角反應軟件規模

　　(4) 國際主流測算方法，适合談判溝通

　　二、功能點估算法現狀 功能點方法度量的是軟件的規模，它是主要從邏輯設計的角度出發對提供給客戶的功能進行量化的方法。 功能點分析方法的目标是提供一種與具體實施方法和技術無關的對軟件開發和維護進行度量的手段，度量用戶要求和能夠接收到的功能。該方法是由IBM的工程師Albrecht通過對大量項目生産率進行研究得到的成果，于1979年提出，它可以

　　①　用來從功能角度度量一個采購軟件的規模；‹

　　②　幫助用戶從提供的功能角度判斷一個軟件對他們的好處；‹

　　③　為一個組織判斷自己的質量和生産率提供“分母”；‹

　　④　幫助軟件開發組織從規模出發判斷一個軟件項目的日程、人力和成本；‹

　　⑤　提供對軟件進行橫向比較的基本判斷依據。

　　随後多年不斷完善升級，出現了多種标準和方法，目前已發展為多種有一定代表性的方法：

　　1．IFPUG-FPA （1）簡介

　　IFPUG的功能點分析（FPA）方法是一種目前被廣泛接受的關于軟件規模度量的有效方法，從用戶的角度出發，将系統分為數據功能和交易功能兩大類，分别根據具體的規則來計算功能點，最後結合系統的特征因子來調整功能點數，從而得到最終的系統規模。

　　（2）主要功能元素

　　數據功能：

　　①　ILF – Internal Logical File – 内部邏輯文件

　　②　EIF – External Interface File – 外部接口文件

　　交易功能

　　①　EI – External Input – 外部輸入

　　②　EO – External Output – 外部輸出

　　③　EQ – External Query – 外部查詢

　　（3）适用對象

　　管理信息系統（開發項目，升級項目，在用項目）

　　（4）普及程度

　　高，應用最廣泛

　　（5）優點

　　從用戶角度度量軟件規模，使用人群多，易于交流

　　評估方法成熟，方法比COSMIC細緻

　　（6）缺點

　　操作複雜，功能分解無方法指導，拆分結果和整體評估結果不一緻

　　2．NESMA （1）簡介

　　NESMA（Netherland Software Measurement Association，荷蘭軟件度量協會）功能點估算方法基于IFPUG發展而來。它與IFPUG的概念統一，相對于IFPUG，NESMA顯得更加靈活方便，并且更适合項目早期預算、招投标階段的成本評估，針對IFPUG方法分析過程較複雜、計算工作量大的不足，NESMA方法實現了快速估算。

　　NESMA提供了三種類型的功能點估算方法，分别是：

　　①　指示法：

　　一般用于計劃階段，因為此階段需求文件多不完善，故而隻需關注邏輯文件即可。

　　②　估算法：

　　一般用于執行階段，此時需求文件較為完善，故需要關注邏輯文件和相應的操作；

　　③　詳細法：

　　主要用于事後評估階段，此時功能需求非常詳細，可關注邏輯文件、相應操作和複雜度。

　　在IFPUG的基礎上，NESMA增加了指示法（Indicative）和估算法（Estimated），使得用戶可以在需求不完善的情況下，快速估算軟件規模。

　　從應用角度而言，IFPUG和NESMA标準是國際上最主要的标準，國際基準比對組織中超過90%的數據采用IFPUG/NESMA方法，國内的行業數據百分百采用IFPUG/NESMA方法，由于IFPUG方法和NESMA方法被認為是基本等效的，所以近幾年，這兩種方法被各行業大量采用。但如想在早期（如預算）階段進行度量，NESMA是更好的選擇。

　　（2）主要功能元素

　　數據功能：

　　③　ILF – Internal Logical File – 内部邏輯文件

　　④　EIF – External Interface File – 外部接口文件

　　交易功能

　　④　EI – External Input – 外部輸入

　　⑤　EO – External Output – 外部輸出

　　⑥　EQ – External Query – 外部查詢

　　（3）适用對象

　　管理信息系統

　　（4）普及程度

　　較為普及

　　（5）優點

　　從用戶角度度量軟件規模，使用人群多，易于交流

　　評估方法成熟，更适合早期測算

　　（6）缺點

　　操作複雜，功能分解無方法指導，拆分結果和整體評估結果不一緻

　　3．COSMIC-FFP （1）簡介

　　通用軟件度量國際協會（Common Software Measurement International Consortium ，COSMIC)提出的全功能點分析方法，COSMIC-FFP不僅适合于信息系統的規模度量，還适合于實時系統和多層系統的規模度量，已經被ISO接受為國際标準。該方法可以在軟件開發生命周期的各個階段使用，從用戶功能的視角入手，起源于客戶可以理解的術語，不需要調整因子，簡單易行。COSMIC-FFP 通過入口(Entry)、出口(Exit)、讀取(Read)和寫入(Write)4 種數據流類型來确定軟件系統功能的規模。先将軟件的功能分解為功能處理、數據組、數據屬性，然後将功能處理分解為數據移動，根據數據移動來計算軟件規模。

　　（2）主要功能元素

　　數據移動，入口(Entry)、出口(Exit)、讀取(Read)和寫入(Write)

　　（3）适用對象

　　銀行、财務、保險等領域管理信息系統，非複雜計算系統

　　實時系統，如電話交換系統，嵌入式控制軟件等，飛機定票系統等。

　　（4）普及程度

　　較普及，第二代功能點方法，部分人認為是趨勢

　　（5）優點

　　計算規則簡單、直接，不需要調整因子，理解後易于操作，可重複性高，支持實時系統

　　（6）缺點

　　普遍認為理解比較困難，不考慮數據計算，無法應用于分析性系統

　　4．UK-MKII （1）簡介

　　英國軟件度量協會提出的Mark II 功能點法（主要在英國、香港等地使用），隻測量邏輯和業務需求，不依賴于具體實現方式，從邏輯事務的角度出發，識别輸入、處理、輸出的過程，計算數據元類型的數量，計算功能規模。

　　（2）主要功能元素

　　輸入Ni、輸出No，處理Ne

　　（3）适用對象

　　管理信息系統或者嵌入式系統

　　（4）普及程度

　　香港、英國部分的确使用

　　（5）優點

　　比IFPUG簡單，易于理解，系統整體度量和部分度量總和一緻

　　（6）缺點

　　使用不廣泛，獲取資料難；

　　19項調整因子，增加主觀性，調整因子主觀性強，不易操作

　　5．COCOMOⅡ （1）簡介

　　COCOMO(Constructive Cost Model，構造型成本模型)。Barry Boehm研究大量項目數據後，推導出的一個成本模型，在實際應用中取得了較好的效果，很好的匹配了采用瀑布模型的軟件項目。做了調整和改進，提出了一個新的版本-COCOMOII型中使用三個螺旋式的過程模型：應用組裝模型，早期設計模型和後體系結構模型。

　　① 應用組裝模型(Application Composition)

　　應用組裝模型是基于對象點的度量模型，它通過計算屏幕、報表、第三代語言(3GL)模塊等對象點的數量來确定基本的規模，每個對象點都有權重，由一個三級的複雜性因子表示，将各個對象點的權值累加起來得到一個總體規模，然後再針對複用進行調整。

　　② 早期設計模型(early design)

　　在項目開始後的一個階段或者螺旋周期通常包括探索體系結構的可供選擇方案或增量開放測量。為支持這一活動，COCOMOII提出了一個早期設計模型，這一模型使用功能點和等價代碼行估算規模。

　　③ 後體系結構模型(post architecture)

　　一旦項目進入開放階段，就必然确定一個具體的生命周期體系結構，此時項目就能夠為估算提供更多更準确的信息。

　　首先采用軟件規模估算方法對項目的規模進行估算。再應用五個比例因子，通過相關計算，将規模轉化為工作量，并通過十七個成本驅動因子對工作量進行調整。最後，采用進度計算公式，計算出開發該項目所需要的進度以及人數。

　　（2）主要功能元素

　　DSI（ 源指令條數 ） ，定義為代碼行數，包括除注釋行以外的全部代碼；MM（ 度量單位為人月 ） 表示開發工作量；TDEV（ 度量單位為月 ） 表示開發進度，由工作量決定。

　　（3）适用對象

　　相對較小、較簡單的項目和同硬件結合緊密的嵌入性的項目

　　（4）普及程度

　　（5）優點

　　計算精确

　　（6）缺點

　　受因子影響巨大，項目前期不容易評估代碼行數；缺乏實施指導性文件

　　6．主要問題 功能點方法是面向業務視角的軟件規模估算方法，估算工程師隻需要了解業務需求，不需要理解功能的具體開發和實現過程，不考慮編程語言、技術框架、運行平台等信息。作為一種從用戶功能角度進行軟件規模評估的方式，主要适用于以功能為主的軟件系統，如：各種管理信息系統、OA系統、ERP系統等。功能點評估法作為一種軟件規模的評估方法也有其局限性，以下是部分問題：

　　①　評估的過程較為複雜，有一定的學習曲線；

　　②　對需求的清晰度要求較高，項目早期信息清晰度不夠；

　　③　功能點估算法對系統内部複雜性考慮不足；

　　④　功能複雜度等級劃分比較武斷，隻有高中低；

　　⑤　通用系統調整因子比較陳舊，應根據最新數據做出調整；

　　⑥　對一些比較複雜的功能，統計誤差較大；

　　⑦　未考慮系統集成帶來的額外開銷；

　　⑧　對複雜系統的可靠性、擴展性、穩定性以及維護性考慮不夠；

　　⑨　對軟件過程規範性管理考慮不足，如；各階段的文檔産出等；

　　⑩　導緻不能針對計算複雜性等非技術要求較高的系統并不能準确做出評估。

　　以下類型的系統不太适合使用功能點估算法做規模度量：

　　①　互聯網在線交易平台；

　　②　對于包含大量算法的産品：視頻系統、圖像處理系統、殺毒軟件、網絡遊戲等；

　　③　數據處理類的平台：數據倉庫，數據庫、數據實時處理等；

　　④　後台優化類項目：數據庫優化、界面優化、性能優化類項目、分布式并發項目等；

　　⑤　硬件産品研發等。

　　三、軟件成本度量的主要标準和實施過程1．國際标準（1）ISO 14143系列标準 ①　ISO14143-1：概念定義，對本系列标準中使用的術語進行解釋；

　　②　ISO14143-2：一緻性評價，給出如何檢驗功能點評估是否符合ISO14143系列标準的評價過程。

　　③　ISO14143-3：驗證，在需要時對功能點評估操作進行驗證。

　　④　ISO14143-4：參考模型，給出功能點評估的方法模型以及需要度量的内容。

　　⑤　ISO14143-5：應用領域确定，确定功能點評估所适用的應用領域。

　　⑥　ISO14143-6：使用指南，對功能點評估提出建議和指導。

　　2．國内标準（1）行業标準 ①　SJ/T 11463-2013《軟件研發成本度量規範》

　　（2）地方标準 ①　DB13/T 2106-2014 《軟件開發項目造價評估規範》 河北省質量技術監督局

　　②　DB37/T 2791-2016 《軟件測試成本度量基本方法》 山東省質量技術監督局

　　③　DB15/T 1394-2018 《軟件開發項目造價評估規範》 内蒙古自治區質量技術監督局

　　④　DB52/T 1653-2022 《軟件開發費用測算規範》 貴州省大數據發展管理局

　　⑤　DB11/T 1010-2019 《信息化項目軟件開發費用測算規範》 北京市經濟和信息化局

　　⑥　DB11/T 1425-2017《信息技術 軟件項目測量元》北京市質量技術監督局

　　⑦　DB11/T 1424-2017 《信息化項目軟件運維費用測算規範》 北京市經濟和信息化委員會

　　（3）國家标準 ①　GB/T 18491.1-2001 《信息技術 軟件測量 功能規模測量 第 1 部分：概念定義》

　　②　GB/T 18491.2-2010《信息技術 軟件測量 功能規模測量 第 2 部分：軟件規模測量方法與 GB/T 18491.1-2001 的符合性評價》

　　③　GB/T 18491.3-2010《信息技術 軟件測量 功能規模測量 第 3 部分：功能規模測量方法的驗證》

　　④　GB/T 18491.4-2010 《信息技術 軟件測量 功能規模測量 第 4 部分：基準模型》

　　⑤　GB/T 18491.5-2010《信息技術 軟件測量 功能規模測量 第 5 部分：功能規模測量的功能域确定》

　　⑥　GB/T 18491.6-2010《信息技術 軟件測量 功能規模測量 第 6 部分：GB/T 18491 系列标準和相關标準的使用指南》

　　⑦　20151553-T-469 《軟件度量-軟件研發成本度量規範》由行業标準升級而來

　　⑧　GB/T 36964-2018《軟件工程 軟件開發成本度量規範》

　　⑨　GB/T 32911-2016《軟件測試成本度量規範》

　　⑩　201941487-T-469《信息技術服務 運行維護 第7部分 成本度量規範》 完成立項

　　⑪　GB/T 37735-2019《信息技術 雲計算 雲服務計量指标》

　　（4）部分在研國家标準 ①　20194201-T-469 《系統與軟件工程 功能規模測量 COSMIC 方法》

　　②　20194189-T-469 《系統與軟件工程 功能規模測量 IFPUG 方法》

　　③　20194199-T-469 《系統與軟件工程 功能規模測量 Mk II 功能點分析方法》

　　④　20194198-T-469 《系統與軟件工程 功能規模測量 NESMA 方法》

　　⑤　20194202-T-469 《系統與軟件工程 功能規模測量 FiSMA1.1 方法》

　　3．實施過程（以IFPUG為例） 功能點估算大緻可以分為7個步驟或階段，分别是：

　　(1) 确定分析類型

　　功能點的分析既可以應用在項目上也可以應用在應用上。三種功能點分析的類 型：

　　①　開發項目

　　②　升級項目

　　③　應用。

　　(2) 确定分析範圍和應用邊界

　　應用邊界表示所度量的軟件和用戶之間的邊界以及應用之間的邊界。

　　(3) 确定用戶功能需求

　　用戶功能需求是用戶需求子集，表示軟件應實現的用戶業務活動和過程。

　　(4) 分解功能需求

　　① 數據功能，以文件文單位，識别内部邏輯文件(Internal Logical File -- ILF)和外部接口文件(External Interface File-- EIF)。識别ILF和EIF對應的數據元素類型（DET）和記錄元素類型（RET），并根據識别結果計算其複雜度，确定其功能點數。

　　② 交易功能，識别交易功能外部輸入（EI）、 外部輸出（EO）和外部查詢（EQ），分别根據其引用文件類型（FTR）和數據元素類型（DET）計算交易功能複雜度，确定其功能點數。

　　(5) 計算未調整功能點數

　　加權求和計算未調整功能點數（UFPC）。

　　(6) 确定調整因子

　　調整系數(VAF)是建立在 14 個用來評價被分析的應用的功能的通用系統特性的基礎之上的。每一個特性都有一些規則來進行評分，對這 14 個通用系統特性進行總結，計算出調整因子 VAF。

　　(7) 計算交付功能點數

　　将未調整功能點數（UFP）和調整因子（VAF）相乘得到功能點數。

　　計算公式：PF=UFP*VAF

　　一、可用于軟件成本度量過程數據 根據軟件項目周期，我們通常将項目分成規劃、需求、設計、開發、測試、上線、線上運維等7個階段，以下簡要說明各階段可能産生的可作為度量依據的産出。

　　1．規劃階段 ①　項目策劃：項目實施範圍、目标可以為規模度量提供總體依據

　　②　可行性分析： 項目範圍、目标、實施路徑進一步量化明确

　　③　成本收益報告：

　　④　項目啟動報告：項目範圍，組織結構清晰化，可用作規模前期度量依據

　　⑤　工時記錄：用于驗證前期各類度量指标，作為曆史數據為後續類似項目評估提供依據

　　2．需求階段 ①　系統分析

　　②　需求規格說明書

　　1) 系統用例、功能說明、業務流程、業務場景等都可以用作功能點分析的依據

　　2) 系統非功能需求，也可用作技術實現評估的依據。

　　③　需求規格的評審&返工

　　④　業務、應用架構設計/規格說明

　　1) 系統的結構劃分、邊界、子系統之間的交互

　　2) 技術實施方案等都可作為度量的依據。

　　⑤　架構設計說明評審&返工

　　⑥　工時記錄：用于驗證前期各類度量指标，作為曆史數據為後續類似項目評估提供依據

　　3．設計階段 ①　功能設計/界面交互設計

　　1) 詳細設計、交互的設計，直接用于工作量評估

　　②　創建物理/内部設計

　　1) 系統内部邏輯，實現方式直接用于度量修正、校準

　　③　總體技術路線選擇、架構設計、集成設計 進一步為開發工作度量提供明确依據

　　④　部署方案設計、網絡、服務器、容器、安全、監控等方案明确， 為技術實現和後期運維提供度量依據。

　　⑤　設計評審&返工

　　⑥　工時記錄：用于驗證前期各類度量指标，作為曆史數據為後續類似項目評估提供依據

　　4．開發階段 ①　技術詳細設計、細化設計等等

　　②　軟件包選擇

　　③　開發代碼

　　④　代碼評審&返工

　　⑤　軟件定制/接口

　　⑥　單元測試

　　⑦　軟件集成

　　軟件實現過程中的細化設計、方案調整、實施用時，細化、驗證前期評估的結果。

　　工時記錄：用于驗證前期各類度量指标，作為曆史數據為後續類似項目評估提供依據

　　5．測試階段 ①　測試計劃， 用作測試工作量的評估

　　②　測試用例， 測試工作量的細化、評估、驗證、進一步的校準

　　③　系統測試， 測試工作量的細化、評估、驗證、進一步的校準

　　④　性能測試， 測試工作量的細化、評估、驗證、進一步的校準

　　⑤　集成測試， 測試工作量的細化、評估、驗證、進一步的校準

　　⑥　驗收測試， 測試工作量的細化、評估、驗證、進一步的校準

　　⑦　工時記錄：用于驗證前期各類度量指标，作為曆史數據為後續類似項目評估提供依據

　　6．上線階段 ①　交付上線準備，計劃準備，上線工作量度量

　　②　用戶文檔

　　③　用戶培訓

　　④　實施上線

　　⑤　用戶支持

　　⑥　工時記錄：用于驗證前期各類度量指标，作為曆史數據為後續類似項目評估提供依據

　　7．運維階段 ①　運維計劃， 日常工作量的度量

　　②　軟件運維， 日常工作量的度量

　　③　網絡服務器運維， 日常工作量的度量

　　④　重大活動保障， 重大活動、突發事情工作量的度量

　　⑤　安全運維， 日常工作量的度量

　　⑥　工時記錄：用于驗證前期各類度量指标，作為曆史數據為後續類似項目評估提供依據

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!