㈠ 軟體項目的成本如何估算
定製軟體開發是軟體開發的一個領域，開發定製的數字技術解決方案以滿足特定業務組織的特定需求。話雖如此，任何投資於定製軟體開發的組織都必須有適當的計劃和預算。定製軟體開發項目有兩個非常重要的限制需要考慮：時間和成本。（准確估算軟體開發項目的成本是保障其整體成功的關鍵）。
在為某個定製軟體開發項目制定計劃時，組織或個人會問兩個問題。
「多少錢？」
「多長時間？」
一、確定定製軟體開發的基礎工作
要確定和估算某個軟體開發項目的成本，必須了解定製軟體開發的基礎知識。更具體地說，您必須知道問題的答案：
「定製軟體開發是如何執行的？」
為了最簡單、最全面地回答這個問題，需要討論以下幾點，它們是定製軟體開發的基礎。
確定需求——它有助於更好地估算成本，還可以正確開發和執行開發任務。
計劃整個過程並設定目標——為整個軟體項目開發周期制定適當的計劃可以在時間和成本管理方面大有幫助。
詳細文檔——必須記錄項目計劃、實施計劃、測試計劃、范圍說明書和培訓計劃中的所有內容。
為定製軟體尋找合適的專業團隊——能夠高效工作並且能夠同時處理多項任務，為整個過程提升效益。
二、確定影響定製軟體開發成本的因素
在下面這一部分，討論影響自定義軟體開發項目的關鍵因素。確定軟體開發項目的成本需要組織或個人考慮並考慮這些因素。
軟體的規模和類型：軟體的規模和類型是決定開發成本的兩個關鍵因素。
例如，移動應用程序或電子商務商店將比銀行或醫院 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。
四、估算軟體項目開發成本
得出功能點數後，結合當地人力成本成本費率和項目非人力成本支出可以估算出軟體項目開發成本。
㈡ 所有軟體的成本評估都適合用功能點方法嗎哪些軟體適合使用功能點方法進行成本度量，哪些軟體不適合
功能點規模計數方法適合以數據和交互處理為中心，以功能多少為主要造價制約因素的系統。例如，電子政務，銀行、電信的用戶和業務管理系統，辦公自動化、ERP、信息管理系統等。
不適合用於估算包含大量復雜演算法的軟體，或創意型軟體，或以非功能性需求為主的系統。例如，視頻和圖像處理軟體、殺毒軟體、網路游戲、性能優化任務。
㈢ 功能點估演算法的規模估算
1. 識別功能點的類型。
2. 識別待估算應用程序的邊界和范圍。
3. 計算數據類型功能點所提供的未調整的功能點數量。
4. 計算人機交互功能所提供的未調整的功能點數量。
5. 確定調整因子。
6. 計算調整後的功能點數量。 通過對需求說明書的分析，我們可以使用「功能點」來對軟體產品所提供給用戶的功能加以度量。程序長度和復雜性都是對程序的事後分析，軟體功能性卻可在軟體開發的初期進行分析，這對我們預測項目規模，規劃項目時間表非常有幫助。
Albrecht的度量方式是先按需求描述對功能點計數，得到未調整功能點，再按系統涉及到的技術功能點對該數值進行修正。
按照軟體表示技術，一項需求可描述為若干外部輸入、外部輸出、外部請求、外部文件、內部文件的集合。對集合中每一子項進行計數，並按其復雜性指派相應的權重，可得未調整功能點UFC：
n
UFC = ∑ (項目i的權重*權重i)
i=1
任何需求的實現，總與一定的技術有關。Albrecht定義了14項技術特性，對應每一特性有一個從0到5的關聯值Fi（0說明此項技術特性與功能實現毫無關系，5說明此項技術特性是系統建立必不可少的組成部分）。一項需求的技術復雜性特性值TCF即由這些評分合成，公式如下：
14
TCF = 0.65 + 0.01 ∑ Fi
i=1
最後，功能點的度量值FP，為以上二者的乘積：
FP = UFC * TCF
㈣ 一個軟體項目如何評估工作量和成本
軟體開發成本估算過程可進一步細分為軟體規模估算、工作量估算、成本估算和確定軟體開發成本等四個過程。
其中成本估算需要對直接人力成本、間接人力成本、間接非人力成本及直接非人力成本分別進行估算。
國家標准《GB/T 36964-2018 軟體工程 軟體開發成本度量規范》中建議的軟體開發成本估算基本流程如下圖所示：
國家准中的四個估算過程，層層遞進，逐步細化，最終達到科學、一致的成本估算。
一、軟體規模估算
通常情況下，規模估算是軟體成本估算過程的起點。
估算規模是後續計算軟體項目的工作量、成本和進度的主要輸入，是項目范圍管理的關鍵，因此，在條件允許的情況下，應首先進行規模估算。
在規模估算過程中，需要注意以下情況：
在規模估算開始前，應根據可行性研究報告或類似文檔明確項目需求及系統邊界。項目需求除包含最基本的業務需求外，還應進行初步的子系統/模塊劃分，並對每一子系統或模塊的基本用戶需求進行說明，以保證可以根據項目需求進行規模預估。
依據項目特點和需求詳細程度不同，通常估算人員在選擇估算方法時應採用納入國際標準的功能點方法進行功能規模估算，在適用IFPUG或NESMA方法時，可以根據需求的粒度和管理需要，選擇預估功能點方法、估算功能點方法或者詳細功能點方法。
若當前的項目需求極其模糊或不確定，可不進行規模估算，而直接採用類比法或類推法估算工作量和成本。
二、工作量估算
在完成規模估算後，應當開展工作量估算工作，若當前項目未開展規模估算，也可直接啟動工作量估算工作。
工作量估算時，可採用方程法、類比法、類推法、功能點法：
方程法：即基於基準數據建立參數模型，通過輸入各項參數，確定估算值。
類比法：即將待估算項目的部分屬性與類似的一組基準數據進行比對，進而確定估算值。
類推法：即將待估算項目的部分屬性與高度類似的一個或幾個已完成項目的數據進行比對，並進行適當調整後確定估算值。
功能點法：從用戶視角出發，通過量化系統功能來度量軟體的規模，這種度量主要基於系統的邏輯設計。功能點規模度量方法在國際上的應用已經比較廣泛，並且已經取代代碼行成為最主流的軟體規模度量方法。
在開展工作量估算的過程中，需要注意以下情況：
當需求極其模糊或不確定時，如果此時具有高度類似的歷史項目，則可直接採用類推法，充分利用歷史項目數據來粗略估算工作量。
當需求極其模糊或不確定時，如果此時具有與本項目部分屬性類似的一組基準數據，則可直接採用類比法，充分利用基準數據來粗略估算工作量。
對於規模估算已經開展的項目，可採用方程法，通過輸入各項參數，確定待估算項目的工作量。若客戶或高層對項目的工期有明確的要求時，在採用方程法估算工作量時，工期要求有可能是方程的參數之一。
為追求估算的准確性，建議在條件允許的情況下，可採用兩種估算方法，對估算結果進行交叉驗證，若估算結果差別不大，可直接使用兩種估算結果的平均值或以某種估算結果為准，若差別較大，需進行差異分析。
工作量的估算結果宜為一個范圍而不是單一的值。
三、成本估算
在獲得了工作量估算結果後，可採用科學的方法進行成本估算。
在成本估算過程中，應需要注意的情況：
類比法和類推法，同樣適用於需求極其模糊或不確定時的成本估算；
間接成本是否與工作量估算結果相關取決於間接成本分攤計算方式。在絕大多數組織，項目周期越長，項目組成員越多，其分攤的間接成本就越高，此時項目的間接成本與工作量估算結果直接相關；
直接非人力成本通常與工作量估算結果無關，宜單獨分項測算；
成本估算結果，也通常為一個范圍，而不是單一的值。
四、確定軟體開發成本
在《軟體工程 軟體開發成本度量規范》中，將軟體開發成本分為四類，主要是為便於對成本構成（即哪些成本屬於開發成本，哪些不屬於開發成本）進行清晰界定。
而在實際確定軟體開發成本時，通常並不是分別測定四類成本，加和後獲得總成本，而是通常採用以下兩種方式確定總成本：
根據人力成本費率及工作量估算直接人力成本和間接成本之和，再加上直接非人力成本，獲得總成本；
根據規模綜合單價和軟體規模，測算出直接人力成本和間接成本之和，再加上直接非人力成本，獲得總成本。
在進行軟體的規模、工作量、成本估算時應遵循以下原則：
在規模估算時,應根據項目特點和需求的詳細程度選擇合適的估算方法；
充分利用基準數據,採用方程法、類比法或類推法,對工作量和成本進行估算；
工作量和成本的估算結果宜為一個范圍值；
在進行成本估算時,如有明確的工期要求,應充分考慮工期對項目成本的影響,可以根據項目實際情況以及工期對項目的影響程度,對成本的估算結果進行調整；
成本估算過程中宜採用不同的方法分別估算並進行交叉驗證。如果不同方法的估算結果產生較大差異,可採用專家評審方法確定估算結果,也可使用較簡單的加權平均方法；
在軟體項目的不同場景下(如預算、招投標、項目計劃和變更管理等)採用國家標准時,相關要求見國家標准中附錄A。
除了上述主要原則外，我們還需注意在使用基準數據時：
對於委託方和第三方，建議使用或參考軟體行業基準數據進行估算。估算模型的調整因子的增減或取值有可能隨著行業基準數據的變化而變化。
對於開發方，在引入行業基準數據的基礎上，可逐步建立組織級基準資料庫，以提高估算精度。組織級基準數據定義應與行業基準數據定義保持一致，以便於與行業基準數據進行比對分析，並持續提升組織能力。
㈤ 功能點估演算法的估算過程
估算的過程主要包括規模估算、規模調整、估算工作量、估算工期和確定預算。上一部分主要講解了估算規模和規模調整這兩部分。
根據調整後軟體規模，估算工作量，公式如下：AE=(PDR*S)*SWF*RDF
估算工期可根據工作量-工期模型計算，公式如下：D=1.277*(AE/HM 1 )0.404，當期望工期短於估算工期的下限時，應對項目需求進行分析並適當調整。通常，壓縮工期會增加項目工作量，及導致生產效率降低。
在獲得了工作量估算結果後，可採用以下公式估算項目預算：P=AE/HM 2 *F 2 +DNC
審批預算時應考慮以下因素：預算的合理性；可用於本項目的資金情況；概算或年初總預算額；其他預算項目可行性及投資收益率對比和平衡。（以上內容均摘自行標《軟體研發成本度量規范》）
㈥ 項目成本估算方法的面向功能點(FP)的度量
面向功能點法是由Albrecht最先提出的，並且在1983年由Albrecht和Gaffney進行了改進。功能點可由以下4個參數計算出來：
● 外部輸入和輸出數
● 外部介面數
● 用戶交互數
● 系統要用的文件數
每個參數都可以根據復雜性進行評估，一般它們的權理為3~15.功能點是通過完成如圖所示的功能點度量計算出來的。其中，FP計數等於數量與加權因子之積，加權因子根據功能點的復雜程度取不同的值。
功能點法是通過建立一個標准來確定某個特定的測量參數(簡單、平均或復雜)的功能點數，但權重的確定多少帶有一定的主觀性。
一般，可以採用下面的方工計算功能點：
FP = 總計數值*[0.65+0.01*SUM(Fi)]
其中總計數值是上表中所得到的所有條目的總和。Fi(i=1,2,3,...14)是對以下14個問題回答的結果而得出的權重調整值(0~5)。等式中的常數和參數的加權因子是根據經驗確定的。
序號 問題
1 系統是否需要可靠的備份和恢復
2 是否需要數據通信
3 是否有分布處理功能
4 系統是否很關鍵
5 系統是否在一個已有的、很實用的操作環境中運行
6 系統是否需要聯機處理
7 聯機數據項是否需要在多屏幕或多操作之間切換以完成操作
8 是否需要聯機更新主文件
9 輸入、輸出及文件查詢是否很復雜
10 內部處理是否復雜
11 代碼是否需要設計成可復用的
12 設計中是否需要包括轉換及安裝
13 系統的設計是否支持不同組織的多次安裝
14 應用的設計是否方便用戶修改及使用
問題的答案及相應權重如下表所示 Fi的取值 0 1 2 3 4 5 沒有影響 偶有影響 輕微影響 平均影響 較大影響 嚴重影響 一旦計算出功能點，就可以採用類似面向規模的方法來使用，以便規范軟體生產率、質量及其他屬性的測量：
● 每個功能點(FP)的錯誤數。
● 每個功能點(FP)的缺陷數。
● 每個功能點(FP)的成本。
● 每個功能點(FP)的文檔頁數。
● 每人月完成的功能點(FP)數。
面向功能點(FP)和面向規模(LOC)兩種度量方法之間的關系為：LOC=AVC*功能點的數量，其中AVC是指該語言在實現一個功能點時所要用的平均代碼行數。
㈦ 軟體開發成本估算方法有哪幾種
開發一個軟體項目，成本如何估算？對此業內已經形成了較為通用的做法，估算步驟主要是這樣的：A.軟體項目需求溝通-》B.軟體項目需求拆分-》C.每個需求點的人天評估-》D.項目人天匯總-》E.商務報價定稿，下面我給大家逐一分解：
A節點主要是將客戶需要做什麼弄清楚；
B節點則將需求按模塊拆分成需求點；
C節點則是根據企業開發實力和過往經驗判斷每個功能點多少人多少天完成（這個點需要較為資深的銷售經理或項目經理來評估）；
D節點則是把項目所有人天及價格進行匯總，這個匯總不是簡單的相加，因為前面步驟得出的人天僅僅是開發部分的工作量，但是軟體開發還包括需求調研、系統設計、系統測試、UAT、上線和運維等等，這部分一般通過一定系數進行測算得出；
E節點就是考慮商務層面而非技術層面的因素對最終價格進行修訂，比如甲方是一個大企業那麼可能第一次合作吃虧也得進去先，比如說甲方不差錢那報價可以適度提升以防後續有需求變更等等；
為了讓大家有個清晰的認知，我把工作中接觸過的一個評估模板（只到D節點哈）復制上來給大家參考：
軟體開發成本估算模型
以上是我從知乎大神處借鑒來的軟體開發成本估算方法之一，也有一些其他辦法，比如拿著同一份需求找不同廠商報價，看報價分布區間就能知道大概成本，另外對於資深的項目經理或開發人員，他們憑借感覺也是能估算的出來的......其他的歡迎其他同仁積極發表意見，畢竟藉助科學的評估流程、工具及經驗做好軟體項目成本估算，從而更好的保障項目盈利是非常有必要的。
㈧ 了解成本估算方法有哪些
成本估算方法，就方法論而言，有兩種基本的成本估算方法：自頂向下和自底向上。
1、自頂向下法是對整個工程項目的總開發時間和總工作量做出估算，然後將它們按階段、步驟和任務進行分配。
2、自底向上法則正好相反，先分別估算各個任務所需要的工作量和開發時間，再相加，從而得到總的工作量和總的開發時間。
這兩種方法都要求採用某種方法做出估算。有許多估算方法可以利用，大致劃分為四類：專家估演算法、類推估演算法 、算式估演算法、差別估演算法。
1、專家估演算法
依靠一個或多個專家對項目做出估算，其精度主要取決於專家對估算項目的定性參數的了解和他們的經驗。
2、類推估演算法
在自頂向下法中，類推估演算法將估算項目的總體參數與類似項目進行直接比較得到結果；在自底向上法中，類推是在兩個具有相似條件的工作單元之間進行。
3、算式估演算法
前兩種估演算法的缺點在於它們依靠的是帶有主觀猜測和盲目性的估算方法。算式估演算法則是企圖避免主觀因素影響的一種方法。算式估演算法有兩種基本類型：由理論導出的演算法和由經驗得出的演算法。
4、差別估演算法
差別估算是與一個或多個已完成的類似項目進行比較，找出與某個相似項目的若干 不同之處，並估算每個不同之處對成本的影響，導出軟體項目的總成本。 優點：該方法可以提高估算的准確度。缺點：不容易明確差別的界限。
㈨ 做軟體開發的成本究竟如何估算
軟體成本評估的6個步驟：
1、軟體規模評估：
軟體規模評估是軟體成本評估的基礎，是為了保證軟體成本評估結果的客觀性和透明性，軟體規模信息必不可少。
在軟體規模評估過程中，如果能夠以軟體功能點方法作為主要的軟體規模評估方法，同時輔以其他的非標准評估方法，例如代碼行方法、用例數方法等，應用不同的軟體規模評估方法對規模評估結果進行真實性交叉檢驗，一方面可以提高軟體規模評估結果的可信度；另一方面，也可以對不同類型的項目干係人也會具有更強的說服力。
在實際的軟體規模評估過程中，軟體組織或者個人也可以根據自身的特點採用有別於上述評估方法的其他方法。但要注意的是，不管採用哪種軟體規模評估方法，都要盡可能的保證這個方法所評估結果的一致性和客觀性。
2、軟體工作量評估
如果說我們能夠算出開發軟體、維護軟體所投入的人員工作量，那麼我們也就相當於得到了相應的軟體成本。在軟體行業中的絕大多數項目裡面，影響軟體工作量的最主要因素還是軟體規模因素，當軟體規模越來越大時，也就意味著我們需要投入的工作量越多，這兩者之間是存在著正相關的關系。
在軟體工作量的評估中，還包含了五個小步驟，也就是收集歷史工作量數據、分析歷史工作量數據、建立工作量評估模型、評估工作量、工作量模型的標定和更新。通過這些步驟可以積累更多關於軟體組織開發工作量和維護工作量的數據，在此基礎之上，建立相應的工作量評估模型，從而為後續的工作量評估任務提供支持方法。
3、軟體階段工作量評估
在這個步驟中，軟體成本評估團隊應該充分考慮軟體項目的工期因素，對軟體項目總工作量安排和各個階段工作量安排進行優化分析，將軟體項目的總工作量以合理可行的方式分解為各個階段的工作量。
不僅如此，還要考慮軟體項目工期所面臨的各種工期約束條件，例如一些來自客戶的強制工期要求、市場競爭性、可用的人力資源、項目各階段人力資源分配的合理比例等約束條件，都在這個步驟中明確介紹了一系列階段工作量安排的改進和優化方法，包括階段工作量匯總法、資源平滑法、快速跟蹤法、趕工法以及軟體階段工作量的可行性評估方法等。
這些方法的主要目的就是在於將軟體工作總量以合理、可行的方式分配到軟體項目的各個階段，確保在不超出工作總量的前提下，盡可能降低人員成本、優化人力資源配置，為軟體預算、軟體開發計劃制定等管理活動提供充分的決策支持信息。
4、軟體人員成本評估
在這個步驟裡面，我們將會詳細說明如何在軟體開發和維護所需的工作量轉換為對應的費用信息，以便為相關的項目外部干係人提供更直接的決策依據。在軟體人員成本評估中，也包含有單一人員成本評估法、分類人員成本評估法和行業人員成本評估法。
5、軟體風險評估
在軟體開發的過程中，許多軟體組織明確認識到軟體行業的開發人員已經默認和接受了無償加班這一行業事實，這樣一來，就算沒有識別相應的風險信息，但也沒有嚴重後果，也就是說，如果風險發生了，那就加班。
這個步驟中通過應用不同的風險評價方法，將軟體項目的風險信息轉換為項目的成本信息，從而建立軟體項目的風險預算。
6、軟體成本報告與更新
軟體項目在開發過程中時，經常容易發生各種軟體需求變更、人員變更、工期變更等多種類型的變更，這些變更無一例外地將對軟體成本產生明顯的影響。
在這個步驟中，可以分析軟體成本更新面臨的困難，有哪些典型的軟體成本更新的信息來源，從機制設計的角度確保盡可能全面獲取軟體成本變更信息。最後遵循軟體組織所建立的軟體成本更新過程，將軟體成本變更信息反映到更新後的軟體成本評估結果中。