軟件項目管理(五)：軟件項目成本管理

一、定義

（一）軟件項目的成本管理，就是為了確保項目在既定預算內按時、按質、經濟、高效地實現項目目標所開展的一種項目管理過程。
（二）項目的成本管理包括成本估算、成本預算和成本控制。

二、軟件項目成本管理概述

* 軟件項目規模一般是指所開發軟件的規模大小，它的度量方法一般有兩種：
　　 LOC(Lines of Code)：源代碼程序長度的測量
　　 FP(Function Point)：系統功能數量的測量

* 軟件項目工作量是指為了提供軟件的功能而必須完成的軟件工程任務量。其度量單位為：
　　 人月、人天、人年：人在單位時間內完成的任務量
　　 為了確定工作量度量單位，可設定一個“標准程序員”，例如具有15~18個月開發經驗的程序員。

* 工作量與規模緊密相關，此外還與項目和產品特性（如團隊的技術和能力、所使用的語言和平台、團隊的穩定性、項目中的自動化程度、產品復雜性等）相關。

* 在不會引起混淆的情況下，工作量和規模這兩個概念可不做區別。

（一）軟件項目成本

• 完成軟件項目工作量相應付出的代價，即待開發軟件項目所需要的資金。
• 人的勞動消耗所需要的代價是軟件開發的主要成本。
• 成本一般采用貨幣單位來計算，如人民幣、美元等。

（二）工作量和成本的關系

• 工作量是項目成本的主要考慮因素，完成項目工作量所消耗的成本是項目成本最主要的部分。因此，項目的工作量估算和成本估算常常同時進行。
• 如果確定了單位工作量所消耗的成本，則可根據項目工作量直接計算出完成項目工作量所消耗的成本。

　　　　例如：如果一個軟件項目的工作量是20人月，而企業的人力成本參數是2萬元/人月，則完成項目工作量所需的成本是40萬元。

（三）軟件項目成本的構成

• 軟件項目通常是技術密集型項目，其成本構成與一般的建設項目有很大區別，其中最主要的成本是在項目開發過程中所花費的工作量及相應的代價，它不包括原材料及能源的消耗，主要是人的勞動消耗。
• 一般來講，軟件項目的成本構成主要包括以下幾種：

　　（1）軟硬件購置成本：這部分費用雖然可以作為企業的固定資產，但因技術折舊太快，需要在項目開發中分攤一部分費用。
　　（2）人工成本（軟件開發、系統集成費用）：主要是指開發人員、操作人員、管理人員的工資福利費等。在軟件項目中人工費用總是占有相當大的份額，有的可以占到項目總成本的80％以上。
　　（3）維護成本： 維護成本是在項目交付使用之后，承諾給客戶的后續服務所必需的開支。可以說，軟件業屬於服務行業，其項目的后期服務是項目必不可少的重要實施內容。所以，維護成本在項目生命周期成本中，占有相當大的比例。
　　（4）培訓費：培訓費是項目完畢后對使用方進行具體操作的培訓所花的費用。
　　（5）業務費、差旅費：軟件項目常以招投標的方式進行，並且會經過多次的談判協商才能最終達成協議，在進行業務洽談過程中所發生的各項費用比如業務宣傳費、會議費、招待費、招投標費等必須以合理的方式計入項目的總成本費用中去。此外，對異地客戶的服務需要一定的差旅費用。
　　（6）管理及服務費：這部分費用是指項目應分攤的公司管理層、財務及辦公等服務人員的費用。
　　（7）其他費用：包括：基本建設費用，如新建、擴建機房、購置計算機機台、機櫃等的費用；材料費，如打印紙、磁盤等購置費；水、電、氣費；資料、固定資產折舊費及咨詢費等等。

• 從財務角度看，可將項目成本構成按性質划分為兩種：

　　（1）直接成本。與具體項目的開發直接相關的成本。如人員的工資、外包外購成本等。又可細分為開發成本、管理成本、質量成本等。
　　（2）間接成本。不歸屬於一個具體的項目，是企業的運營成本，分攤到各個項目中。如房租、水電、保安、稅收、福利、培訓，等等。

（四）軟件項目成本管理的內容和目標

• 軟件項目成本管理的內容包括成本估算、成本預算、成本控制。
• 現實中，軟件項目經常成本超支，這是因為：項目需求含糊，經常會由於客戶不斷變化的實際要求而變更計划；項目成本結構復雜，成本核算方法和實施難度大；成本的估算不合理，行業標准不明確，尤其是間接成本的估算沒有標准成熟的方法和科學依據；項目涉及新的技術或商業過程，有很大的內在風險。
• 結合IT項目的成本特點，應用恰當的項目成本管理技術和方法可以很有效地改變成本超支狀況。
• 成本管理的主要目的就是將項目的運作成本控制在預算的范圍內，或者控制在可以接受的范圍內。

三、軟件規模度量

* 軟件的規模是影響軟件項目成本和工作量的主要因素。
* 最常用的度量軟件規模的方法是代碼行（Lines of Code，LOC）和功能點（Function Point，FP），分別利用代碼行數和功能點數來表示軟件系統的規模。

（一）代碼行（LOC）

• 從軟件程序量的角度定義項目規模。

1、要求功能分解足夠詳細。
2、一般是根據經驗數據估計實現每個功能模塊所需的源程序行數，然后把源程序行數累加起來，得到軟件的整體規模。
3、有一定的經驗數據（類比和經驗方法）。
4、與具體的編程語言有關。

• 優點：

直觀、准確（在有代碼的情況下）、易於計算（可使用代碼行統計工具）。

• 缺點：

1、對代碼行度量沒有公認的標准定義。
2、代碼行數量依賴於所用的編程語言和個人的編程風格。
3、在項目早期,需求不穩定、設計不成熟、實現不確定的情況下很難准確地估算代碼量。

（二）功能點（FP）

1、用系統的功能數量來測量其規模，與實現產品所使用的語言沒有關系。
2、對系統的外部功能和內部功能進行計數。
3、根據技術復雜度因子（權）對它們進行調整，產生產品規模的度量結果。

   （1）功能點計算公式

FP =UFC*TCF
    UFC(Unadjusted Function Point Count)未調整功能點計數
    TCF(Technical Complexity Factor) 技術復雜度因子

   （2）UFC的計算方法

• 首先計算功能計數項，對以下五類元素計數：

1、用戶輸入：由用戶輸入的面向應用的數據項。
2、用戶輸出：向用戶提供的輸出數據項。
3、用戶查詢：要求系統回答的交互式輸入。
4、外部接口文件：與其它系統的接口數據文件。
5、內部文件：系統使用的內部固定文件。

• 然后對各功能計數項加權並求和，得到UFC。

        

•    案例分析

某學院安裝了一個工資系統，人事處要求創建一個子系統來分析每門課程的人力資源成本。要求該子系統提供查詢每門課程人力資源成本的功能。
每名教師所得工資的細節可以通過工資系統中的文件得到，教師花在教每門課上的小時數可通過一個基於計算機的計時表系統中的文件得到。
該子系統將計算結果存放到由總會計系統讀取的一個文件中，並產生一個報告，來顯示每名教師每門課的課時數及這些課時數相應的成本。

　　問題：計算該子系統的UFC。（子系統產生的報告復雜度為高，其它所有元素的復雜度均為中等）

　　答案：UFC=1*7+1*4+3*7=32

   （3）TCF的計算方法

• 技術復雜度影響因素

• 每個技術復雜度影響因素的取值范圍：

• TCF=0.65+0.01(sum(Fi))： Fi:0-5,TCF:0.65~1.35

• 該子系統的功能點為：  FP=UFC*TCF=32*0.87=27.8

（4）功能點度量的優缺點

• 優點：

1、軟件系統的功能與實現該軟件系統的語言無關；
2、在軟件開發的早期階段（如需求分析）就可通過對用戶需求的理解獲得軟件系統的功能點數目，因而該方法可以較好地克服基於代碼行的軟件項目規模表示方法的不足。

• 缺點：

1、功能點計算主要靠經驗公式，主觀因素比較多；
2、沒有直接涉及算法的復雜度，不適合算法比較復雜的軟件系統；
3、計算功能點所需的數據不好采集。

（三）功能點與代碼行的轉換

四、成本估算

（一）引言

* 成本估算是對完成項目所需費用的估計，它是項目成本管理的核心。
* 成本估算可以有一些誤差。估算結果可用一個范圍表示，例如$10000±$1000。
* 由於影響軟件成本的因素太多（人、技術、環境等），成本估算仍然是很不成熟的技術，大多數時候需要經驗。
  目前沒有一個估算方法或者成本估算模型可以適用於所有軟件類型和開發環境。

• 成本估算的依據

1. WBS：根據WBS，可將整體成本分解到各工作包中，使成本的估算能夠分項進行，各個工作包的成本估算能夠做到盡量的准確合理。
2. 資源要求：是進行成本估算的基礎，用來說明所需資源的類型和數量以及分配情況。
3. 資源消耗率，即資源單價。必須知道每種資源單價（例如每小時人員費用等）以計算項目成本。如果實際單價不知道，則必須估計資源單價本身。
4. 進度規划：進度計划中的活動持續時間估計會影響項目成本估計。
5. 歷史項目數據：以往項目的數據，包括規模、進度、成本等，是項目估算的主要參考。一個成熟的軟件企業應該建立完善的項目檔案。

• 成本估算的輸出

1. 估算文件：包括項目需要的資源、資源的數量、質量標准、估算成本等信息，估算成本單位一般是貨幣單位，也可以是規模單位，然后轉換為貨幣單位。
2. 估算說明：包括工作范圍的描述（這通常可由WBS獲得）；說明估算的基礎和依據，即確認估算是合理的，說明估算是怎樣產生的；確認為成本估算所做的任何假設的合理性以及估算的誤差變動等。

（二） 成本估算方法

 （1）類比估算法

• 也稱為基於案例的推理，估算人員根據以往完成的類似項目（源案例）所消耗的成本（或工作量），來推算將要開發的軟件（目標案例）的成本（或工作量）。
• 需提取項目的一些特性作為比較因子，如項目類型（MIS系統、實時系統等）、編程語言、項目規模、開發人員數量、軟件開發方法等。利用這些比較因子來確定源案例與目標案例之間的匹配程度。
• 在新項目與以往項目只有局部相似時，可行的方法是“分而治之”，即對新項目適當地進行分解，以得到更小的任務、工作包或單元作為類比估算的對象。
• 通過這些項目單元與已有項目的類似單元對比后進行類比估算。
• 最后，將各單元的估算結果匯總得出總的估計值。
• 在項目初期信息不足時（例如市場招標和合同簽訂），且有以往類似項目的數據時，適於采用類比估算法。
• 該方法簡單易行，花費少，但具有一定的局限性，准確性差。

 （2）自下而上估算法

• 首先對單個工作包或活動的成本進行最具體、細致的估算，然后把這些細節性成本向上匯總到更高的層次。
• 該方法通常在項目開始以后的詳細規划階段，或者WBS已經確定的階段，需要進行准確估算的時候采用。
• 優點：因為每項工作的執行者負責對該項工作進行成本估算，比起高層管理人員來講，這些直接參與項目建設的人員更清楚項目涉及活動所需要的資源量，估算的專業性和准確性都較高。
• 缺點：花費時間長，工作代價高。
• 自下而上---舉例

 （3）參數估算法

  使用項目特性參數建立經驗估算模型來估算成本。
  經驗估算模型是通過對大量的項目歷史數據進行統計分析（如回歸分析）而導出的。
  經驗估算模型提供對項目工作量的直接估計。
  該方法簡單，而且比較准確，但如果模型選擇不當或提供的參數不准確，也會產生較大的偏差。

• 經驗估算模型

　　　　1、模型形式：E=A+B*SC
　　　　　　E:以人月表示的工作量
　　　　　　A,B,C:經驗導出的系數
　　　　　　S:主要的輸入參數(通常是LOC,FP等)
　　　　2、面向LOC的：
　　　　　　Walston-Felix(IBM)模型 E= 5.2*(KLOC)^0.91
　　　　　　Balley-Basili模型 E=5.5+0.73*(KLOC)^1.16
　　　　　　Boehm簡單模型 E=3.2*(KLOC)^1.05
　　　　　　Doty模型 E=5.288*(KLOC)^1.047
　　　　3、面向FP的：
　　　　　　Albrecht and Gaffney 模型 E=-13.39+0.0545FP
　　　　　　Matson,Barnett E=585.7+15.12FP

•  Walston-Felix(IBM)模型

　　　　1、1977年，IBM的Walston和Felix提出了如下的估算公式：

　　　　　　E ＝ 5.2×L ^0.91 ，L是源代碼行數(以KLOC計)，E是工作量（以PM計）

　　　　　　D ＝ 4.1×L ^ 0.36，D是項目持續時間(以月計)

　　　　　　S ＝ 0.54×E ^ 0.6，S是人員需要量(以人計)

　　　　　　DOC ＝ 49×L ^ 1.01。DOC是文檔數量(以頁計)

　　　　 2、舉例

　　　　　　采用java 完成項目，366功能點，則

　　　　　　L = 366×46 = 16386行 = 16.386KLOC

　　　　　　E ＝ 5.2×L ^ 0.91 ＝ 5.2×16.386 ^ 0.91 ＝ 66人月

　　　　　　DOC ＝ 49×L ^ 1.01 ＝ 49×16.386 ^ 1.01 ＝ 826頁

• COCOMO（Constructive Cost model）

 構造性成本模型，是世界上應用最廣泛的參數型軟件成本估計模型。
 由Barry Boehm利用加利福尼亞的一個咨詢公司的大量項目數據推導出的一個成本模型。該模型於1981年首次發表，於1994年又推出了COCOMO II。

• COCOMO基本原理

　　 1. 將開發所需要的工作量表示為軟件規模和一系列成本因子的函數,基本估算公式:

         

     2. A:可以校准的常量; S為軟件規模; E為規模的指數,說明不同規模軟件具有的相對規模經濟和不經濟性;EM為成本驅動因子,反映某個項目特征對完成項目開發所需工作量的影響程度;n為描述軟件項目特征的成本驅動因子的個數。

• 項目類型

1.有機（Organic）
  各類應用程序，例如數據處理、科學計算等。
  受硬件的約束比較小，接口環境靈活；軟件的規模不是很大。
2.嵌入式（Embeded）
  系統程序，例如實時處理、控制程序等。
  在硬件和軟件的嚴格約束條件下運行，對系統進行變更的代價很高；軟件的規模任意。
3.半相連（Semidetached）
  介於上述兩種系統之間。

• COCOMO81 模型類別

基本COCOMO
靜態單變量模型。

中等COCOMO
在基本模型基礎上考慮各種影響因素（工作量驅動因子），調整模型。

高級COCOMO
中等COCOMO模型基礎上考慮軟件工程中各個步驟的影響。

• 基本COCOMO

E=a*(KLOC)^b
E是項目的工作量（以人月計）
KLOC是軟件產品的代碼行數（以千行計）
a、b是依賴於項目自然屬性的參數

• 基本COCOMO系數表

• 基本COCOMO舉例

一個33.3 KLOC的軟件開發項目，屬於半相連型的項目，采用基本COCOMO進行工作量的估算：
a=3.0，b=1.12
E = 3.0＊L ^1.12 = 3.0＊33.3 ^1.12 = 152 PM

• 中等COCOMO

E=a*(KLOC)b*工作量系數
工作量系數是根據成本驅動因子的打分計算得出，是對公式的校正系數。

• 中等COCOMO系數表

• 成本驅動因子

 

 

• 工作量系數的計算

* 規定每個成本驅動因子的取值范圍，將其取值划分為非常低、低、正常、高、非常高等級別，每個級別對應一個值。例如，軟件組織可以決定使用以下系數來評估分析員能力(ACAP)的影響：
　　非常低（very low） 1.46
　　低（low） 1.19
　　正常（nominal） 1.00
　　高（hign） 0.80
　　非常高（very hign) 0.71
* 當每個成本驅動因子Fi的值選定后，工作量系數的計算如下：
　　工作量系數=F1*F2*…Fi…*Fn

• 中等COCOMO舉例

* 一個33.3 KLOC的軟件開發項目，屬於半相連型的項目，采用中等COCOMO進行工作量的估算：
　　a=3.0，b=1.12
　　工作量系數=0.70*0.85*1……*1.15=1.09
　　E = 3.0＊33.3 ^1.12 ×1.09＝166 PM

• 高級COCOMO

工作量計算公式與中等COCOMO模型一樣，區別主要在於：
(1) 把待估算的軟件項目分解為模塊、子系統、系統3個級別，從而可以在更細的粒度上估算工作量。
(2)考慮了在項目各開發階段中，成本驅動因子所產生的影響。

• COCOMO Ⅱ

COCOMOⅡ給出了三個層次的工作量估算模型，這三個層次的模型在估算工作量時，對軟件細節考慮的詳盡程度逐級增加。
（1）應用組成（application composition）模型。這個模型主要用於估算構建原型的工作量，用於項目規划階段。
（2）早期設計（early design）模型。適用於體系結構設計階段。
（3）后體系結構（post-architecture）模型。適用於完成體系結構設計之后的軟件開發階段。

• 后體系結構模型

  

E是工作量（以人月為單位），a是模型系數，KLOC是估計的源代碼行數（以千行為單位），b是模型指數，fi(i=1~17)是成本驅動因子。

• COCOMO 2對成本驅動因子的更新

與COCOMO81相比，COCOMOⅡ對成本驅動因子做了一些改變：
增加了4個成本驅動因子：要求的可重用性、需要的文檔量、人員連續性、多地點開發
略去了COCOMO81模型中的2個成本驅動因子：虛擬機空間、實效編程經驗使用情況
對某些成本驅動因子的取值大小做了調整。

• b值分級模型

COCOMO2對模型中指數b的確定方法進行了改進，采用了5個分級因素Wi(1≤i ≤5)，每個因素都划分成甚低、低、正常、高、甚高、特高6個級別，
其取值分別為5、4、3、2、1、0，然后使用下式計算b的數值：

1.01 ≤b ≤1.26

• b值分級模型中的5個分級因素

(1)項目先例性：指出對於開發組織來說該項目的新穎程度。
(2)開發靈活性：為了實現預先確定的外部接口需求及為了及早開發出產品而需要增加的工作量。
(3)風險排除度：反映了重大風險已被排除的比例。
(4)項目組凝聚力：反映了開發人員在目標和文化背景等方面相一致的程度，以及開發人員組成一個小組工作的經驗。
(5)過程成熟度：反映了按照能力成熟度模型度量出的項目組織的過程成熟度。

• COCOMO模型擴展及其系列

Boehm教授及其研發團隊對COCOMO模型做了許多擴展，用於解決不同領域內的問題，形成了COCOMO模型系列：
COINCOMO(constructive incremental COCOMO)：用於支持增量開發中的成本估算。
DBA COCOMO(database (access) doing business as COCOMO Ⅱ)：基於數據庫實現並支持靈活數據分析。
COQUALMO(constructive quality model)：用於估算軟件產品的遺留缺陷並體現質量方面的投資回報。
iDAVE(information dependability attributed value estimation)：用於估算並跟蹤軟件依賴性方面投資回報。
COPLIMO(constructive product line investment model)：支持對軟件產品線的成本估算及投資回報分析。
COPROMO(constructive productivity improvement model)：通過預測新技術中最成本有效的資源分配來提高生產率。

• 參數估算的適用性

參數估算方法需要大量歷史數據作為支撐，而且數學模型的建立要使用特定的分析技術（如回歸分析），因此具有較強的學術性，在許多實際軟件項目中的可操作性並不好。
所以很多項目管理者更傾向於選擇更為簡單實用的成本估算方法，比如后面將介紹的“分解-累計”方法。

（4）專家估算法

由多位對應用領域和開發環境有豐富經驗的專家進行成本估算。
專家是指具有專門知識和經驗，或經過專業培訓的團體或個人。
為避免單個專家產生偏見，盡量由多位專家進行估算，取得多個估算值，最后得出綜合的估算值。

• 專家估算法-Delphi

1、組織者發給每位專家一份軟件系統的規格說明和一張記錄估算值的表格，請他們估算。
2、專家詳細研究軟件規格說明后，對該軟件提出3個工作量（或成本）的估算值：
　　最小值ai
　　最可能值mi
　　最大值bi
3、組織者對專家的表格中的答復進行整理，計算每位專家的平均估算值Ei=(ai+4mi + bi)/6和總的平均值E=(E1 +E2+…+En)/n (n表示n個專家)。
4、組織專家無記名填表格，比較估算差，並查找原因。
5、如果各個專家的估算差異超出規定的范圍（例如：15%），則需重復上述過程 ，最終可以獲得一個多數專家共識的軟件工作量（或成本）估計值。

• 專家估算法舉例

某管理信息系統-專家估算
  專家1：1，8，9 （1+9+4*8）/6=7（萬元）
  專家2：4，6，8 （4+8+4*6）/6=6（萬元）
  估算結果=（6+7）/2=6.5（萬元）

（5）“分解-累計”估算方法

• 該方法簡單、直觀。
• 首先估算產品規模。步驟如下：

　　（1）項目規划小組先分解產品的功能，制定“產品功能分解與規模估算表”。軟件規模的度量單位可以使用代碼行，也可以使用對象數、頁面數等。
產品功能分解與規模估算表：

        

　　（2）項目規划小組成員獨立填寫產品功能分解與規模估算表。
　　（3）匯總每個成員的表格，進行對比分析。如果各人估計的差額小於20%，則取平均值，如果差額大於20%，則轉向第（2）步，讓各成員重新估計產品的規模，直到各個成員估計的差額小於20%為止。

• 有了項目規模后，就可以估算項目工作量，步驟與產品規模估算相同。
• 先估算開發工作量，再估算管理工作量，填寫下表所示的工作量估算表。

       

• 有了工作量估算值后，就可以計算項目的人力成本了，計算公式如下：

             項目人力成本 = 項目工作量×平均人力資源單價×成本系數

• 平均人力資源單價可由人員的工資確定。
• 之所以要乘以成本系數，是因為人力資源的成本要高於工資，企業除了要為人員支付工資外，還要支付各種保險金、福利、資源消耗等。對軟件企業來說，成本系數大約是1.5至2.0。

（三） 一種實用的軟件成本估算過程

該過程步驟如下：
1.對項目進行任務分解:1,2,…,i,…,n
2.估算每個任務的成本Ci
3.項目的開發成本=C1+C2+……+Ci+……+Cn
4.項目總估算成本= 直接成本+間接成本
5.項目總報價=項目總估算成本+風險利潤

（1）估算每個任務的成本

• 先估計任務的工作量Ei （一般以人月為單位）。
• 然后估算任務成本Ci= Ei*人力成本參數。

（2）直接成本估算

• 直接成本的構成：開發成本、管理成本、質量成本
• 管理和質量成本的簡易估算法：

1. 開發工作量：Effort(Dev)
2. 管理和質量工作量：Effort(Mgn)=a*Effort(Dev)

         a為比例系數，可根據企業的具體情況而定，例如20%--25%。

• 直接成本= Effort(Dev) + a*Effort(Dev)

（3）間接成本估算

• 根據企業具體的成本模型進行計算。
• 簡易估算方法：

1. 間接成本=直接成本*間接成本系數
2. 間接成本系數根據企業的具體情況而定，例如取0.3。

（4）項目總估算成本

• 總估算成本=直接成本+間接成本

　　　　　　　　=直接成本+直接成本*間接成本系數
　　　　　　　　=直接成本(1+間接成本系數)
　　　　　　　　=工作量*人力成本參數*（1+間接成本系數）

• 成本系數=人力成本參數*（1+間接成本系數）
• 總估算成本=工作量*成本系數
• 例如：某項目的工作量是40人月，成本系數為2萬元/人月，則項目的總估算成本為40*2=80萬元。

（5）項目總報價

• 風險利潤包括風險基金、項目稅費和稅后利潤等。
• 風險利潤=項目總估算成本*a%

　　　a是利潤系數，根據企業、項目的不同而不同。

• 項目總報價=項目總估算成本+項目總估算成本*a%

　　　　　　　　=項目總估算成本（1+a%）

（四） 成本估算的准確度

 

（1）估算不准確的原因

• 基礎數據不足
• 估算對需求的敏感性
• 軟件項目存在許多變更和不確定因素
• 缺乏有經驗的估算人員
• 簽約前后的不連貫

（2）避免低劣的估算

• 留出估算的時間，並做好計划
• 注意積累項目數據，以開發人員提供的經驗數據為基礎進行估算
• 分類法估算
• 進行詳細的較低層次上的估算
• 使用估算工具
• 使用幾種不同估算技術，並比較它們的結果

（3）估算的表達方式

• 加減限定表示

　　  6個人月的工作量可表示為6+3、6-1人月。

• 范圍表示

　　  6個人月的工作量可表示為5~9人月。

• 風險量化

      

五、 成本預算

• 成本預算是將批准的項目總成本估算按照進度分配到項目各項具體工作中，進而確定成本基准。
• 成本基准是按時間段分配的預算，用於與實際成本支出結果進行比較，從而對成本實施情況進行監控。
• 所以成本預算又稱為制定成本計划。
• 成本預算的依據之一是項目進度計划。項目進度計划包括項目活動、里程碑和工作包的計划開始和完成時間，可根據這些信息，把計划成本分配到相應的日歷時段中。
• 成本基准的表示方式有兩種。第一種是根據單位時間（例如每個月）內完成的工作量或投入的人力、物力和財力，計算單位時間的成本，然后以立方圖的形式繪制出來。
• 第二種是計算時間t的累計成本，然后繪制成時間-成本累計曲線。

        

• 用直方圖表示的按月編制的成本基准

       

• 用時間-成本累計曲線表示的成本基准

（一）降低項目成本預算的方法

• 降低資源的費率
• 減少任務的工時
• 減少加班
• 替換資源
• 刪除任務
• 降低資源的費率

          降低人力資源的費率往往會打擊工作人員的積極性，但可以通過降低其他資源的費率來實現，比如降低能源消耗、設備費用、耗材費用等。

• 減少任務的工時

           使任務高效率地執行，避免浪費時間，從而適當減少任務的工時，可以降低任務的費用。

• 減少加班

          加班需要支付加班費率，這通常要高於正常情況下的人力資源費率，所以減少加班可以有效的減少項目成本。

• 替換資源

          用廉價的資源替換比較高價的資源，但有一個前提，那就是替換的資源同樣能勝任這項任務。

• 刪除任務

          確認刪除該任務對項目沒有影響或影響在可控制范圍內才可采用。

（二）重視維護階段的成本預算

• 加強客戶對軟件維護在軟件應用中重要性的認識。在簽訂軟件合同時，應增加對軟件維護的成本預算。
• 軟件市場中對軟件維護的規范性要有一個統一科學的認識和約束，要形成規范的軟件服務市場。
• 堅持有償服務的原則。
• 加強軟件開發中的軟件測試、軟件復用，組件化，標准化、泛性模式的運用。

六、成本控制

• 成本控制是指監督項目成本的支出情況，發現實際成本和成本預算的偏差，並找出偏差的原因，以便采取糾正措施，並阻止不正確、不合理和未經批准的成本變更。
• 成本控制的依據是成本基線、項目進度計划、項目工作范圍等。

          

（一）項目成本控制過程

（1）掙值分析法

• 掙值分析法(Earned Value Analysis)也稱為已獲取價值分析法、盈余分析法，是利用成本會計的概念對項目的進度和成本狀況進行績效評估的一種有效方法。
• 該方法依賴於被稱為“已獲取價值”的一種主要測量。

（2）掙值分析法中的基本概念

• BCWS(Budgeted cost of work scheduled)，計划工作預算成本：到目前為止計划完成工作的總預算成本，它表示“到該日期為止本應該完成的工作是多少”。
• ACWP(Actual cost of work performed)，已完成工作實際成本：到目前為止已完成工作所消耗的實際成本，它表示“到該日期為止實際花了多少錢”。
• BCWP(Budgeted cost of work performed)，已完成工作預算成本，也稱已獲取價值(Earned Value)：到目前為止已完成工作的預算成本，它表示“到該日期為止已完成了多少工作”。
• BAC(Budgeted At Completion),工作完成的預算成本：即項目完成的預計總成本。

（3）掙值分析的導出度量

• 成本偏差(Cost Variance, CV): CV=BCWP-ACWP

　　=0：按照預算進行
　　>0：低於預算
　　<0：超出預算

• 進度偏差(Schedule Variance, SV): SV=BCWP-BCWS

　　=0：按照進度進行
　　>0：進度超前
　　<0：進度落后

（4）舉例一

• 項目原來預計2009年10月10日完成1000元的工作，但是到該日期時只完成了其中850元的工作，而為了完成這些工作實際花費了900元，問在2009年10月10日項目的成本偏差和進度偏差各是多少？

　　　　BCWS=1000，BCWP=850，ACWP=900
　　　　CV=BCWP-ACWP=850-900= -50元
　　　　SV=BCWP-BCWS=850-1000= -150元

• 成本效能指數(Cost Performance Index, CPI): CPI=BCWP/ACWP 表示成本的支出速度

　　　　=1：按照預算進行
　　　　>1：低於預算
　　　　<1：超出預算

• 進度效能指數(Schedule Performance Index, SPI): SPI=BCWP/BCWS 表示已完成工作的百分比

　　　　=1：按照進度進行
　　　　>1：超前於進度
　　　　<1：落后於進度

（5）舉例二

• 項目原來預計2009年10月10日完成1000元的工作，但到該日期時只完成了其中850元的工作，而為了完成這些工作實際花費了900元，問在2009年10月10日項目的成本效能指數和進度效能指數各是多少？

　　　　BCWS=1000，BCWP=850，ACWP=900
　　　　CPI=BCWP/ACWP=850/900= 0.94
　　　　SPI=BCWP/BCWS=850/1000= 0.85

• 項目完成的預測成本（Estimate At Completion, EAC）：EAC = BAC/CPI
• 項目完成的成本差異（Variance At Completion, VAC）：VAC = BAC – EAC
• 項目完成的預測時間（Schedule At Completion, SAC）：SAC = 計划完成時間/SPI

（6）掙值分析法的基本原理

       

• 在項目的實際執行過程中，最理想的狀態是BCWP、BCWS、ACWP三條曲線緊密相靠，平穩上升，這表示項目的實際情況和期望的走勢差不多，向着良好的方向發展。
• 若三條曲線偏離很大，則表示項目實施過程有重大問題隱患，或已經發生了嚴重問題，應對項目重新評估和安排。

（二）怎樣確定未完成工作的已獲取價值

• 應用一些規則，避免對工作的進展情況主觀估計所產生的問題。

　　　　1. 50/50規則：當一項工作開始時，假定已經獲得一半的價值，工作完成時獲得全部價值。
　　　　　使用本規則的前提是任務分解足夠詳細。

　　　　    例如：工作包的工作量<1人1周的工作量

　　　　2. 0/100規則：當一項工作沒有完成時，不產生任何價值，直到完成后才獲得全部的價值。

　　　　3. 其它經驗加權規則，如20/80規則等。

•  示例

       

七、課堂練習題

  （一）例題一

• 你被指定負責一個軟件項目，其中有４部分，項目總預算為53000, A任務為26000, B任務為12000, C任務為10000, D任務為5000, 截止到5月31日，A任務已經全部完成，B任務過半，C任務剛開始，D任務還沒有開始。下表顯示了截止到5月31日的計划成本和實際花費，采用50/50規則計算截止到5月31日的CV，SV，CPI，SPI,EAC？

         

• 練習題-答案

         

　　  截止到5月31日：
　　  BCWS = 39800元，ACWP = 35000元，
　　  BCWP = 37000元
　　  CV= BCWP – ACWP =2000元
　　  SV = BCWP – BCWS = -2800元
　　  SPI = BCWP/BCWS = 0.93
　　  CPI = BCWP/ACWP = 1.06
　　  EAC = BAC/CPI = 53000/1.06 = 50000元

（二）例題二

• 項目的階段計划

       

• 軟件設計的細化計划

      

 

     

• 第三周的BCWP

　　　　分析結果（第三周的項目性能分析：假設實際的工作量9人天）
　　　　ACWP=9（人天）
　　　　BCWS=7（人天）
　　　　BCWP=6.5（人天）
　　　　BAC=31（人天)
　　　　SV=BCWP-BCWS=-0.5（人天），進度落后0.5人天工作量
　　　　SPI=BCWP/BCWS=92.8％，以計划進度的92.8%效能在工作。
　　　　CV=BCWP-ACWP=-2.5（人天），超出預算2.5人天
　　　　CPI=BCWP/ACWP=72.2%，以超預算27.8%的狀態在工作
　　　　EAC=BAC/CPI=43（人天），按目前的工作性能，項目總預算為43人天。
　　　　VAC=BAC-EAC=-12（人天），超出預算12人天的工作量
　　　　SAC=10/SPI=10.8（周）按目前的進度，完工時間是10.8周

• 總結：這個項目將推遲0.8周（4個工作日）左右，超出預算27.8%，完成預算比較困難。

　　　　　　此時應仔細研究原因，然后解決問題，如果是計划做得不合理，就要修正計划。

（三）案例分析

• “軟件缺陷管理和度量系統”項目成本估算

八、本章小結

• 基本概念
• 理解軟件項目規模、工作量、成本的概念
• 軟件規模度量
• 理解代碼行和功能點及其特征
• 成本估算
• 了解類比估算法、自下而上估算法、專家估算法，理解參數估算法、分解-累計估算法
• 成本預算
• 掌握成本預算的目的、成本基准的表示方法，了解降低成本預算的方法
• 成本控制
• 理解掙值分析法

 

 

原文鏈接：https://blog.csdn.net/yongchaocsdn/article/details/80877118