當前位置:首頁 » 生產成本 » 軟體項目開發成本分析怎麼寫
擴展閱讀
丹東產品廣告片多少錢 2025-06-10 12:41:01
15米氣球成本多少 2025-06-10 12:41:01

軟體項目開發成本分析怎麼寫

發布時間: 2022-07-18 16:42:47

Ⅰ 軟體項目計劃的成本估算

自頂向下估算方法
估算人員參照以前完成的項目所耗費的總成本,來推算將要開發的軟體的總成本,然後把它們按階段、步驟和工作單元進行 分配,這種方法稱為自頂向下估算方法。
它的優點是對系統級工作的重視,所以估算中不會遺漏系統級的諸如集成、用戶手冊和配置管理之類的事務的成本估算,且估算工作量小、 速度快。它的缺點是往往不清楚低級別上的技術性困難問題,而往往這些困難將會使成本上升。
自底向上估算方法
自底向上估算方法是將待開發的軟體細分,分別估算每一個子任務所需要的開發工作量,然後將它們加起來 ,得到軟體的總開發量。這種方法的優點是對每個部分的估算工作交給負責該部分工作的人來做,所以估算 較為准確。其缺點是其估算往往缺少與軟體開發有關的系統工作級工作量,所以估算往往偏低。
差別估算方法
差別估算是將開發項目與一個或多個已完成的類似項目進行比較,找到與某個相類似項目的若干 不同之處,並估算每個不同之處對成本的影響,導出開發項目的總成本。該方法的優點是可以提高估算的准確度, 缺點是不容易明確「差別」的界限。
其他
除上三種還有:
(1)專家估演算法。
(2)類推估演算法。
(3)算式估演算法。 COCOMO估算模型
機構性成本模型COCOMO(Constructive Cost Mode)是最精確、最易於使用的成本估算方法之一。
該模型分為:基本COCOMO模型,是一個靜態單變數模型,它是對整個軟體系統進行估算;中級COCOMO模型,是一個靜態多變數模型;詳細COCOMO模型,將軟體系統模型分為系統、子系統和模塊三個層次。
①基本COCOMO模型估算公式:
E=ab(KLOC)exp(bb)
D=cb(E)exp(db)
式中E為開發所需的人力(人/月)。D為所需的開發時間(月)。KLOC為估計提交的代碼行。
ab、bb、cb和db是指不同軟體開發方式的值。
②中級COCOMO模型。
其估算公式為:E=ai(KLOC)exp(bi)×乘法因子,ai,bi
Putnam成本估算經驗模型
Putnam估算模型是一種動態多變模型,它是假設在軟體開發的整個生存期中工作量的分布。如下圖:
根據曲線導出關於提交的代碼行數L,人力K(人/年)和時間td(年)之間估算公式:
式中Ck是技術狀況有關的常數,它的典型值如下:
對於差的開發環境 Ck=2500
對於好的開發環境 Ck=10000
對於有的開發環境 Ck=12500
由上述公式可以得到所需開發工作量的公式:

Ⅱ 一個軟體項目如何評估工作量和成本

軟體開發成本估算過程可進一步細分為軟體規模估算工作量估算成本估算確定軟體開發成本等四個過程。

其中成本估算需要對直接人力成本間接人力成本間接非人力成本直接非人力成本分別進行估算。

國家標准《GB/T 36964-2018 軟體工程 軟體開發成本度量規范》中建議的軟體開發成本估算基本流程如下圖所示:

國家准中的四個估算過程,層層遞進,逐步細化,最終達到科學、一致的成本估算。

一、軟體規模估算

通常情況下,規模估算是軟體成本估算過程的起點。

估算規模是後續計算軟體項目的工作量、成本和進度的主要輸入,是項目范圍管理的關鍵,因此,在條件允許的情況下,應首先進行規模估算。

在規模估算過程中,需要注意以下情況:

  1. 在規模估算開始前,應根據可行性研究報告或類似文檔明確項目需求及系統邊界。項目需求除包含最基本的業務需求外,還應進行初步的子系統/模塊劃分,並對每一子系統或模塊的基本用戶需求進行說明,以保證可以根據項目需求進行規模預估。

  2. 依據項目特點和需求詳細程度不同,通常估算人員在選擇估算方法時應採用納入國際標準的功能點方法進行功能規模估算,在適用IFPUG或NESMA方法時,可以根據需求的粒度和管理需要,選擇預估功能點方法、估算功能點方法或者詳細功能點方法。

  3. 若當前的項目需求極其模糊或不確定,可不進行規模估算,而直接採用類比法或類推法估算工作量和成本。

二、工作量估算

在完成規模估算後,應當開展工作量估算工作,若當前項目未開展規模估算,也可直接啟動工作量估算工作。

工作量估算時,可採用方程法、類比法、類推法、功能點法:

  • 方程法:即基於基準數據建立參數模型,通過輸入各項參數,確定估算值。

  • 類比法:即將待估算項目的部分屬性與類似的一組基準數據進行比對,進而確定估算值。

  • 類推法:即將待估算項目的部分屬性與高度類似的一個或幾個已完成項目的數據進行比對,並進行適當調整後確定估算值。

  • 功能點法:從用戶視角出發,通過量化系統功能來度量軟體的規模,這種度量主要基於系統的邏輯設計。功能點規模度量方法在國際上的應用已經比較廣泛,並且已經取代代碼行成為最主流的軟體規模度量方法。

在開展工作量估算的過程中,需要注意以下情況:

  1. 當需求極其模糊或不確定時,如果此時具有高度類似的歷史項目,則可直接採用類推法,充分利用歷史項目數據來粗略估算工作量。

  2. 當需求極其模糊或不確定時,如果此時具有與本項目部分屬性類似的一組基準數據,則可直接採用類比法,充分利用基準數據來粗略估算工作量。

  3. 對於規模估算已經開展的項目,可採用方程法,通過輸入各項參數,確定待估算項目的工作量。若客戶或高層對項目的工期有明確的要求時,在採用方程法估算工作量時,工期要求有可能是方程的參數之一。

  4. 為追求估算的准確性,建議在條件允許的情況下,可採用兩種估算方法,對估算結果進行交叉驗證,若估算結果差別不大,可直接使用兩種估算結果的平均值或以某種估算結果為准,若差別較大,需進行差異分析。

  5. 工作量的估算結果宜為一個范圍而不是單一的值。

三、成本估算

在獲得了工作量估算結果後,可採用科學的方法進行成本估算。

在成本估算過程中,應需要注意的情況:

  1. 類比法和類推法,同樣適用於需求極其模糊或不確定時的成本估算;

  2. 間接成本是否與工作量估算結果相關取決於間接成本分攤計算方式。在絕大多數組織,項目周期越長,項目組成員越多,其分攤的間接成本就越高,此時項目的間接成本與工作量估算結果直接相關;

  3. 直接非人力成本通常與工作量估算結果無關,宜單獨分項測算;

  4. 成本估算結果,也通常為一個范圍,而不是單一的值。

四、確定軟體開發成本

在《軟體工程 軟體開發成本度量規范》中,將軟體開發成本分為四類,主要是為便於對成本構成(即哪些成本屬於開發成本,哪些不屬於開發成本)進行清晰界定。

而在實際確定軟體開發成本時,通常並不是分別測定四類成本,加和後獲得總成本,而是通常採用以下兩種方式確定總成本:

  • 根據人力成本費率及工作量估算直接人力成本和間接成本之和,再加上直接非人力成本,獲得總成本;

  • 根據規模綜合單價和軟體規模,測算出直接人力成本和間接成本之和,再加上直接非人力成本,獲得總成本。

在進行軟體的規模、工作量、成本估算時應遵循以下原則:

  1. 在規模估算時,應根據項目特點和需求的詳細程度選擇合適的估算方法;

  2. 充分利用基準數據,採用方程法、類比法或類推法,對工作量和成本進行估算;

  3. 工作量和成本的估算結果宜為一個范圍值;

  4. 在進行成本估算時,如有明確的工期要求,應充分考慮工期對項目成本的影響,可以根據項目實際情況以及工期對項目的影響程度,對成本的估算結果進行調整;

  5. 成本估算過程中宜採用不同的方法分別估算並進行交叉驗證。如果不同方法的估算結果產生較大差異,可採用專家評審方法確定估算結果,也可使用較簡單的加權平均方法;

  6. 在軟體項目的不同場景下(如預算、招投標、項目計劃和變更管理等)採用國家標准時,相關要求見國家標准中附錄A。

除了上述主要原則外,我們還需注意在使用基準數據時:

  • 對於委託方和第三方,建議使用或參考軟體行業基準數據進行估算。估算模型的調整因子的增減或取值有可能隨著行業基準數據的變化而變化。

  • 對於開發方,在引入行業基準數據的基礎上,可逐步建立組織級基準資料庫,以提高估算精度。組織級基準數據定義應與行業基準數據定義保持一致,以便於與行業基準數據進行比對分析,並持續提升組織能力。

Ⅲ 成本分析報告怎麼寫

樓主你好!拙見
要正確進行成本分析,關鍵是定量分析。下面我簡要介紹一下定量分析的方法。
首先貴單位應制定對各種產品分別制定標准成本,該標准成本應當是通過努力可以實現的,略低於平時生產的平均成本,這樣做是為了明確一個努力方向,該標准應保持相對的穩定性。該標准成本分別按直接材料、直接人工、變動製造費用、固定製造費用四個項目制定,每一項都分解成二、三個因素標准來分別進行考核。
有了標准成本,月末就可以對成本差異進行因素分析了,方法如下:
1、直接材料成本差異分為價格差異和數量差異。
價格差異=實際數量*(實際價格-標准價格)
數量差異=(實際數量-標准數量)*標准價格
兩者相加就是直接材料成本差異。
2、直接人工成本差異分為工資率差異和人工效率差異。
工資率差異=實際工時*(實際工資率-標准工資率)
人工效率差異=(實際工時-標准工時)*標准工資率
兩者相加就是直接人工成本差異。
3、變動製造費用差異分為耗費差異和效率差異。
耗費差異=實際工時*(變動製造費用實際分配率-變動製造費用標准分配率)
效率差異=(實際工時-標准工時)*變動製造費用標准分配率
兩者相加就是變動製造費用差異。
4、固定製造費用差異分為耗費差異、閑置能量差異、效率差異。
耗費差異=固定製造費用實際數-固定製造費用標准分配率*生產能量
閑置能量差異=固定製造費用預算數-實際工時*固定製造費用標准分配率
效率差異=實際工時*固定製造費用標准分配率-標准工時*固定製造費用標准分配率
三者相加就是固定製造費用差異。

Ⅳ 成本分析報告怎麼寫啊,主要寫哪些內容啊。

成本分析報告一般包括以下內容:
1)當期成本項目數據及其比例;
2)當期成本數據與歷史平均(或上期)成本數據的變動;
3)成本數據變動率及其原因分析。
以上個人觀點,供參考。

Ⅳ 軟體成本評估都包含哪些內容

完整的軟體造價評估應該包含哪些?

1 估算基礎

  • 對估算對象(需求、任務等)的拆分顆粒度定義了上限與下限,以提升估算的准確度。

  • 完備識別了估算對象,沒有遺漏的需求或任務。

  • 估算人員經過了估算方法的系統培訓。

  • 定義了組織級的估算方法。

2 規模估算

  • 從不估算規模或經驗估算規模升級為客觀度量規模,比如採用國際標準的功能點方法或自定義的規模度量方法,無論是哪種方法,規模與工作量之間應該是強相關的才是合理的。

  • 如果對本公司的項目而言,規模與工作量不強相關,也可以是復雜度等其他因子,對這些因子應該也與工作量做了相關性分析,與工作量應該強相關才是合理的。

3 工作量估算

  • 建立了從規模的客觀度量用定量模型推算出項目總工作量。

  • 建立了工作量分布百分比的性能基線,可以從總工作量推算各階段或各類任務的工作量。比如開發的工作量、測試的工作量。

  • 能夠用PPB或PPM推算出各種關鍵活動的最少投入工作量,比如需求評審的工作量、代碼評審的工作量、系統測試的工作量等。

  • 工作量的估算結果應該是一個區間,而不是單點值。如,總工作量不超過100人月。

4 成本估算

  • 從工作量到成本有定量的計算方法。

  • 成本的估算結果應該也是一個區間,而不是單點值。比如不超過30萬,或者在25到30萬之間等。

5 工期估算

  • 識別了項目的關鍵路徑與關鍵鏈。

  • 對項目的工期進行了模擬,得到滿足項目工期要求的概率有多大。如果概率太低,對關鍵路鏈上的任務、投入的資源與需要完成的需求進行了優化。

6 評審與修訂估算

  • 保存了估算記錄,估算結果經過了評審。

  • 隨著需求和任務的明確,在開發過程中修訂了估算結果。

7 持續改進估算過程

  • 對比了估算結果與實際結果,對估算偏差率建立了過程性能基線或過程性能模型。

  • 總結了估算有關的經驗教訓。

  • 對估算方法和過程進行了持續優化。

  • 跟蹤檢查了估算方法與過程在組織級的落地實施情況。

Ⅵ 項目成本估算方法的IT項目開發成本的估算方法

項目成本估算方法的IT項目開發成本的估算方法

如今,不少企業都想擁有屬於自己企業或產品的手機APP,但其中最困擾企業主的問題就是:開發一款手機APP到底需要多少錢?

簡單點來說,要視手機APP的需求及質量而言,價位一般在幾千到十幾萬左右,更高端的價格更高。

四、APP開發公司的所在地

需要注意的是,同樣實力的APP開發公司,在不同的城市也會導致APP的成本費用高一些

Ⅶ 軟體項目的成本如何估算

定製軟體開發是軟體開發的一個領域,開發定製的數字技術解決方案以滿足特定業務組織的特定需求。話雖如此,任何投資於定製軟體開發的組織都必須有適當的計劃和預算。定製軟體開發項目有兩個非常重要的限制需要考慮:時間和成本。(准確估算軟體開發項目的成本是保障其整體成功的關鍵)。

在為某個定製軟體開發項目制定計劃時,組織或個人會問兩個問題。

「多少錢?」

「多長時間?」


一、確定定製軟體開發的基礎工作

要確定和估算某個軟體開發項目的成本,必須了解定製軟體開發的基礎知識。更具體地說,您必須知道問題的答案:

「定製軟體開發是如何執行的?」

為了最簡單、最全面地回答這個問題,需要討論以下幾點,它們是定製軟體開發的基礎。

  • 確定需求——它有助於更好地估算成本,還可以正確開發和執行開發任務。

  • 計劃整個過程並設定目標——為整個軟體項目開發周期制定適當的計劃可以在時間和成本管理方面大有幫助。

  • 詳細文檔——必須記錄項目計劃、實施計劃、測試計劃、范圍說明書和培訓計劃中的所有內容。

  • 為定製軟體尋找合適的專業團隊——能夠高效工作並且能夠同時處理多項任務,為整個過程提升效益。


二、確定影響定製軟體開發成本的因素

在下面這一部分,討論影響自定義軟體開發項目的關鍵因素。確定軟體開發項目的成本需要組織或個人考慮並考慮這些因素。

  • 軟體的規模和類型:軟體的規模和類型是決定開發成本的兩個關鍵因素。

例如,移動應用程序或電子商務商店將比銀行或醫院 ERP 解決方案等其他類型的軟體便宜。自定義軟體、倉庫管理、安全應用程序和 CRM 解決方案的類型通常更加昂貴和耗時。

  • 復雜性:開發的復雜性是影響整體定製軟體開發估算的關鍵因素。

  • 設計結構:設計結構有兩個關鍵領域:創意設計和UI/UX設計。這兩個因素對於項目的總成本都是必不可少的。

  • 集成:第三方集成需要大量的精力和資源。

  • 數據遷移:數據遷移是一個非常具體和准確的過程,需要自定義腳本和多個渠道。

  • 開發時間:開發時間是影響定製軟體開發成本的關鍵因素,人力成本是最大的支出。

  • 功能和平台:盡管聽起來很明顯,軟體運行的平台及其功能對您需要在產品上進行的整體投資有重大影響。

  • 測試:有助於確定軟體的效率和功能,還涉及一些影響項目總成本的支出。

  • 維護:在成本估算時,還必須考慮某種定製軟體產品的維護和支持類型。


三、如何估算定製軟體的規模

快速功能點方法是依據國際標准《ISO/IEC 24570-2005軟體工程NESMA功能尺度測量法2.1版功能點分析應用的定義和計數指南》提出的一種軟體規模度量方法。

該方法適用於軟體項目早期、中期、後期等各個階段的規模估算或測量。

快速功能點方法進行規模估算或測量的基本過程或步驟如下:

  • 確定計數類型

  • 識別系統邊界

  • 識別功能點計數項

  • 計算未調整的功能點數

  • 計算調整後的功能點數。

那麼就讓新星為大家詳細對每個步驟進行剖析:

1、確定計數類型

根據需求或項目的類型確定計數類型。

計數類型分為三種:新開發延續開發已有系統計數

  • 對於新開發需求或項目,對預計(或實際)投產的功能進行計數;

  • 對於延續開發需求或項目,對預計(或實際)新增、修改及刪除的功能均進行計數;

  • 對於已有系統,對實際的功能進行計數。

2、識別系統邊界

在識別系統邊界的時候應注意:

  • 應從用戶視角出發,不受系統實現影響;

  • 主要是為了區分內部邏輯文件(ILF)和外部介面文件(EIF);

  • 事務功能應穿越識別的系統邊界。

3、識別功能點計數項

功能點計數項分為數據功能和交易功能兩類。

  • 數據功能——包括內部邏輯文件(ILF)、外部介面文件(EIF);

  • 交易功能——包括外部輸入(EI)、外部輸出(EO)、外部查詢(EQ)。

數據功能:系統提供給用戶的滿足產品內部和外部數據需求的功能,即本系統管理或使用那些業務數據(業務對象),如「客戶信息」「賬戶交易記錄」等。內部邏輯文件或外部介面文件所指的「文件」不是傳統數據處理意義上的文件,而是指一組客戶可識別的、邏輯上相互關聯的數據或者控制信息。因此,這些文件和物理上的數據集合(如資料庫表)沒有必然的對應關系。

交易功能:系統提供給用戶的處理數據的功能,即本系統如何處理和使用那些業務數據(業務對象),如「轉賬」「修改黑名單生成規則」「查詢交易記錄」等。交易功能又稱為基本過程,是用戶可識別的,業務上的一組原子操作,可能由多個處理邏輯構成。例如,「添加櫃員信息」這個基本過程可能包含「信息校驗」「修改確認」「修改結果反饋」等一系列處理邏輯。

3、計算未調整的功能點數

a.採用預估功能點進行計數,計算公式如下:

FP=35ILF+15EIF

——FP:未調整的功能點數,單位為功能點;

——ILF:內部邏輯文件的數量;

——EIF:外部介面文件的數量。

b.採用估算功能點進行計數,計算公式如下:

FP=10ILF+7EIF+4EI+5EO+4*EQ

——FP:未調整的功能點數,單位為功能點;

——ILF:內部邏輯文件的數量;

——EIF:外部介面文件的數量;

——EI:外部輸入的數量;

——EO:外部輸出的數量;

——EQ:外部查詢的數量。

5、計算調整後的功能點數

根據不同的規模測算階段,需要考慮隱含需求及需求變更對規模的影響,因此,需要根據規模計數時機進行規模調整。

調整後的功能點數(AFP),計算公式如下:

AFP=FP*CF

——AFP:調整後的功能點數,單位為功能點;

——FP:未調整的功能點數,單位為功能點;

——CF:規模變更調整因子,依據行業數據,項目估算早期(如概預算階段)通常取值為1.5;項目估算中期(如招投評標、項目立項、技術方案階段)通常取值為1.26;項目估算中後期(如需求分析完成及後評價)通常取值為1.0。


四、估算軟體項目開發成本

得出功能點數後,結合當地人力成本成本費率和項目非人力成本支出可以估算出軟體項目開發成本。

Ⅷ 做軟體開發的成本究竟如何估算

軟體成本評估的6個步驟:

1、軟體規模評估:

軟體規模評估是軟體成本評估的基礎,是為了保證軟體成本評估結果的客觀性和透明性,軟體規模信息必不可少。

在軟體規模評估過程中,如果能夠以軟體功能點方法作為主要的軟體規模評估方法,同時輔以其他的非標准評估方法,例如代碼行方法、用例數方法等,應用不同的軟體規模評估方法對規模評估結果進行真實性交叉檢驗,一方面可以提高軟體規模評估結果的可信度;另一方面,也可以對不同類型的項目干係人也會具有更強的說服力。

在實際的軟體規模評估過程中,軟體組織或者個人也可以根據自身的特點採用有別於上述評估方法的其他方法。但要注意的是,不管採用哪種軟體規模評估方法,都要盡可能的保證這個方法所評估結果的一致性和客觀性。

2、軟體工作量評估

如果說我們能夠算出開發軟體、維護軟體所投入的人員工作量,那麼我們也就相當於得到了相應的軟體成本。在軟體行業中的絕大多數項目裡面,影響軟體工作量的最主要因素還是軟體規模因素,當軟體規模越來越大時,也就意味著我們需要投入的工作量越多,這兩者之間是存在著正相關的關系。

在軟體工作量的評估中,還包含了五個小步驟,也就是收集歷史工作量數據、分析歷史工作量數據、建立工作量評估模型、評估工作量、工作量模型的標定和更新。通過這些步驟可以積累更多關於軟體組織開發工作量和維護工作量的數據,在此基礎之上,建立相應的工作量評估模型,從而為後續的工作量評估任務提供支持方法。

3、軟體階段工作量評估

在這個步驟中,軟體成本評估團隊應該充分考慮軟體項目的工期因素,對軟體項目總工作量安排和各個階段工作量安排進行優化分析,將軟體項目的總工作量以合理可行的方式分解為各個階段的工作量。

不僅如此,還要考慮軟體項目工期所面臨的各種工期約束條件,例如一些來自客戶的強制工期要求、市場競爭性、可用的人力資源、項目各階段人力資源分配的合理比例等約束條件,都在這個步驟中明確介紹了一系列階段工作量安排的改進和優化方法,包括階段工作量匯總法、資源平滑法、快速跟蹤法、趕工法以及軟體階段工作量的可行性評估方法等。

這些方法的主要目的就是在於將軟體工作總量以合理、可行的方式分配到軟體項目的各個階段,確保在不超出工作總量的前提下,盡可能降低人員成本、優化人力資源配置,為軟體預算、軟體開發計劃制定等管理活動提供充分的決策支持信息。

4、軟體人員成本評估

在這個步驟裡面,我們將會詳細說明如何在軟體開發和維護所需的工作量轉換為對應的費用信息,以便為相關的項目外部干係人提供更直接的決策依據。在軟體人員成本評估中,也包含有單一人員成本評估法、分類人員成本評估法和行業人員成本評估法。

5、軟體風險評估

在軟體開發的過程中,許多軟體組織明確認識到軟體行業的開發人員已經默認和接受了無償加班這一行業事實,這樣一來,就算沒有識別相應的風險信息,但也沒有嚴重後果,也就是說,如果風險發生了,那就加班。

這個步驟中通過應用不同的風險評價方法,將軟體項目的風險信息轉換為項目的成本信息,從而建立軟體項目的風險預算。

6、軟體成本報告與更新

軟體項目在開發過程中時,經常容易發生各種軟體需求變更、人員變更、工期變更等多種類型的變更,這些變更無一例外地將對軟體成本產生明顯的影響。

在這個步驟中,可以分析軟體成本更新面臨的困難,有哪些典型的軟體成本更新的信息來源,從機制設計的角度確保盡可能全面獲取軟體成本變更信息。最後遵循軟體組織所建立的軟體成本更新過程,將軟體成本變更信息反映到更新後的軟體成本評估結果中。

Ⅸ 軟體開發的成本

軟體開發成本主要指軟體開發過程中所花費的工作量及相應的代價。

在對一個軟體項目進行開發成本估算時,應該包括從項目立項直至項目研發活動結束所花費的資源總和,並且可以按階段進行估算或測量。

軟體開成本估算的過程可分為:估算規模、估算工作量、估算工期和估算成本這4個過程,最終確定軟體成本。其中成本估算需要對直接人力成本、間接人力成本、間接非人力成本及直接非人力成本分別進行估算。

開發平台

軟體開發平台源於繁瑣的實踐開發過程中。開發人員在實踐中將常用的函數、類、抽象、介面等進行總結、封裝,成為了可以重復使用的「中間件」,而隨著「中間件」的成熟和通用,功能更強大、更能滿足企業級客戶需求的——軟體開發平台應運而生。

平台是一段時間內科研成果的匯聚,也是階段性平台期的標志,為行業進入新的研發領域提供了基礎。由於平台對企業核心競爭力的提升非常明顯,國內的管理軟體市場,軟體開發平台的應用已經成為一種趨勢。

以上內容參考:網路-軟體開發

Ⅹ 如何確定軟體的開發成本價

軟體開發成本估算過程可進一步細分為軟體規模估算、工作量估算、成本估算和確定軟體開發成本等四個過程。

其中成本估算需要對直接人力成本、間接人力成本、間接非人力成本及直接非人力成本分別進行估算。

國家標准《GB/T 36964-2018 軟體工程 軟體開發成本度量規范》中建議的軟體開發成本估算基本流程如下圖所示:

國家准中的四個估算過程,層層遞進,逐步細化,最終達到科學、一致的成本估算。

一、軟體規模估算

通常情況下,規模估算是軟體成本估算過程的起點。

估算規模是後續計算軟體項目的工作量、成本和進度的主要輸入,是項目范圍管理的關鍵,因此,在條件允許的情況下,應首先進行規模估算。

在規模估算過程中,需要注意以下情況:

1.在規模估算開始前,應根據可行性研究報告或類似文檔明確項目需求及系統邊界。項目需求除包含最基本的業務需求外,還應進行初步的子系統/模塊劃分,並對每一子系統或模塊的基本用戶需求進行說明,以保證可以根據項目需求進行規模預估。

2.依據項目特點和需求詳細程度不同,通常估算人員在選擇估算方法時應採用納入國際標準的功能點方法進行功能規模估算,在適用IFPUG或NESMA方法時,可以根據需求的粒度和管理需要,選擇預估功能點方法、估算功能點方法或者詳細功能點方法。

3.若當前的項目需求極其模糊或不確定,可不進行規模估算,而直接採用類比法或類推法估算工作量和成本。

二、工作量估算

在完成規模估算後,應當開展工作量估算工作,若當前項目未開展規模估算,也可直接啟動工作量估算工作。

工作量估算時,可採用方程法、類比法、類推法、功能點法:

方程法:即基於基準數據建立參數模型,通過輸入各項參數,確定估算值。

類比法:即將待估算項目的部分屬性與類似的一組基準數據進行比對,進而確定估算值。

類推法:即將待估算項目的部分屬性與高度類似的一個或幾個已完成項目的數據進行比對,並進行適當調整後確定估算值。

功能點法:從用戶視角出發,通過量化系統功能來度量軟體的規模,這種度量主要基於系統的邏輯設計。功能點規模度量方法在國際上的應用已經比較廣泛,並且已經取代代碼行成為最主流的軟體規模度量方法。

在開展工作量估算的過程中,需要注意以下情況:

1.當需求極其模糊或不確定時,如果此時具有高度類似的歷史項目,則可直接採用類推法,充分利用歷史項目數據來粗略估算工作量。

2.當需求極其模糊或不確定時,如果此時具有與本項目部分屬性類似的一組基準數據,則可直接採用類比法,充分利用基準數據來粗略估算工作量。

3.對於規模估算已經開展的項目,可採用方程法,通過輸入各項參數,確定待估算項目的工作量。若客戶或高層對項目的工期有明確的要求時,在採用方程法估算工作量時,工期要求有可能是方程的參數之一。

4.為追求估算的准確性,建議在條件允許的情況下,可採用兩種估算方法,對估算結果進行交叉驗證,若估算結果差別不大,可直接使用兩種估算結果的平均值或以某種估算結果為准,若差別較大,需進行差異分析。

5.工作量的估算結果宜為一個范圍而不是單一的值。

三、成本估算

在獲得了工作量估算結果後,可採用科學的方法進行成本估算。

在成本估算過程中,應需要注意的情況:

1.類比法和類推法,同樣適用於需求極其模糊或不確定時的成本估算;

2.間接成本是否與工作量估算結果相關取決於間接成本分攤計算方式。在絕大多數組織,項目周期越長,項目組成員越多,其分攤的間接成本就越高,此時項目的間接成本與工作量估算結果直接相關;

3.直接非人力成本通常與工作量估算結果無關,宜單獨分項測算;

4. 成本估算結果,也通常為一個范圍,而不是單一的值。

四、確定軟體開發成本

在《軟體工程 軟體開發成本度量規范》中,將軟體開發成本分為四類,主要是為便於對成本構成(即哪些成本屬於開發成本,哪些不屬於開發成本)進行清晰界定。

而在實際確定軟體開發成本時,通常並不是分別測定四類成本,加和後獲得總成本,而是通常採用以下兩種方式確定總成本:

1.根據人力成本費率及工作量估算直接人力成本和間接成本之和,再加上直接非人力成本,獲得總成本;

2.根據規模綜合單價和軟體規模,測算出直接人力成本和間接成本之和,再加上直接非人力成本,獲得總成本。

在進行軟體的規模、工作量、成本估算時應遵循以下原則:

1.在規模估算時,應根據項目特點和需求的詳細程度選擇合適的估算方法;

2.充分利用基準數據,採用方程法、類比法或類推法,對工作量和成本進行估算;

3.工作量和成本的估算結果宜為一個范圍值;

4.在進行成本估算時,如有明確的工期要求,應充分考慮工期對項目成本的影響,可以根據項目實際情況以及工期對項目的影響程度,對成本的估算結果進行調整;

5.成本估算過程中宜採用不同的方法分別估算並進行交叉驗證。如果不同方法的估算結果產生較大差異,可採用專家評審方法確定估算結果,也可使用較簡單的加權平均方法;

6.在軟體項目的不同場景下(如預算、招投標、項目計劃和變更管理等)採用國家標准時,相關要求見國家標准中附錄A。

除了上述主要原則外,我們還需注意在使用基準數據時:

1. 對於委託方和第三方,建議使用或參考軟體行業基準數據進行估算。估算模型的調整因子的增減或取值有可能隨著行業基準數據的變化而變化。

2.對於開發方,在引入行業基準數據的基礎上,可逐步建立組織級基準資料庫,以提高估算精度。組織級基準數據定義應與行業基準數據定義保持一致,以便於與行業基準數據進行比對分析,並持續提升組織能力。