成本管理：項目管理之軟件項目成本估算

申請免費試用、咨詢電話：400-8352-114

項目管理之軟件項目成本估算

　　一、軟件成本估算貫穿于整個軟件生命周期

　　項目初期粗略的成本估算是必要的，它往往用于確定項目的可行性分析。在項目計劃階段還需對項目進行詳細的成本估算，設定項目工作分解表中每項任務可能的成本，作為項目執(zhí)行階段進行成本控制的基準。并且，在項目執(zhí)行階段，當項目實際成本與計劃成本出現(xiàn)差異時，還需對項目后期的成本重新進行必要的估算。因此，項目成本估算在項目的管理和控制中占據(jù)著非常重要的地位。而在軟件項目中，由于在人員、開發(fā)周期、項目范圍及技術難度等方面與其它項目相比具有更大的不確定性，故準確估算其成本就顯得特別困難。因而合理估算軟件項目成本就尤其重要。

　　二、軟件項目中的成本估算模型

　　現(xiàn)有的大多數(shù)軟件成本估算模型適于預算、權衡分析、計劃、控制和投資分析等范疇。成本估算模型技術多采用經(jīng)驗公式對軟件項目進行成本估算。在大多數(shù)估算模型中，軟件規(guī)模是決定成本的主要因素。有兩種衡量軟件規(guī)模的常規(guī)方法：基于代碼行的估算方法和基于功能點的估算方法。許多成本估算模型中將代碼行或功能點數(shù)作為主要的輸入?yún)?shù)。

　　1.面向代碼行的成本估算模型

　　代碼行(lines of code，LOC)是衡量源代碼長度的最常用的方法。NCLOC(non-comments source lines ofcode縮寫)用于表達不含注解的源代碼行數(shù)。NCLOC也常常被當作為有效的代碼行數(shù)(effective lines of code，ELOC)。在很多情況下，為了日后更清楚地閱讀和理解程序，提高系統(tǒng)的可維護性，在程序開發(fā)中往往要求在程序中附上詳細的注解，在這種情況下，包含注解的源代碼行數(shù)也是一個有效的度量標準。CLOC(commented source line of code縮寫)用于表達含注解的源代碼行數(shù)。綜上所述，我們給出代碼行的定義如公式1所示：總長度(LOC)=NCLOC+CLOC(1)

　　2.面向功能點的成本估算模型

　　面向功能點(Function points，F(xiàn)P)的成本估算模型是用系統(tǒng)的功能數(shù)量來測量軟件規(guī)模的。該方法先評估產(chǎn)品所需功能，然后根據(jù)技術復雜度因子(權)對其成本進行量化和修正，估算出最終的軟件成本。

　　其基本步驟是：

　　(1)計算未調整的功能點(UFC)數(shù)目這里所談的功能點數(shù)并非最終軟件中實際的功能數(shù)量，最終軟件實際功能模塊的個數(shù)在軟件開發(fā)之前是不可能精確估算的。在此，我們首先將軟件的所有功能分為外部輸入、外部輸出、外部查詢、外部文件及內部文件五大類，并估算每類功能的數(shù)量(FPi)，然后依據(jù)待開發(fā)軟件的特點評估各類功能的復雜度權重(Wi)，在依據(jù)公式2可得未調整的功能點數(shù)(UFC)。UFC=SUM(FPi*Wi)

　　(2)外部輸入由用戶提供的、描述面向應用的數(shù)據(jù)外部輸出系統(tǒng)向用戶提供的、面向用戶的數(shù)據(jù)外部查詢要求回答的交互式輸入外部文件對其他系統(tǒng)可讀的文件內部文件系統(tǒng)里的邏輯主文件權重因素(Wi)項簡單一般復雜外部輸入3 4 6外部輸出4 5 7外部查詢3 4 6外部文件7 10 15內部文件5 7 10(2)計算調整后的功能點數(shù)考慮到用戶對系統(tǒng)性能的不同要求，我們還需從表3中反映的14個方面對UFC作進一步的調整，從而計算出待開發(fā)系統(tǒng)的技術復雜度因子(technical complexity factor，TCF)。表3技術復雜度因子第12期舒小仙：軟件項目管理的成本估算81F1可靠的備份和恢復F2數(shù)據(jù)通信F3分布式處理F4性能F5大量使用的配置F6聯(lián)機數(shù)據(jù)輸入F7操作簡便性F8在線升級F9界面的復雜性F10數(shù)據(jù)處理的復雜性F11代碼的復用性F12安裝的簡易性F12多重站點F14易修改性表3中的因子Fi(其中：i=1，2，……14)取值范圍在0-5之間[1]，值0表示該因子對系統(tǒng)無影響，值5表示該因子是對系統(tǒng)有強大的影響。技術復雜度因子的計算公式如公式3所示：TCF=0.65+0.01(SUM(Fi))(3)由UFC乘以技術復雜度因子(technical complexityfactor，TCF)得到調整后的功能點數(shù)FP，參見公式4。FP=UFC×TCF(4)

　　3.基于回歸分析的成本模型

　　成本模型提供工作量的直接估算，通常有一個主要的成本因素和若干個次要的調整因素。該模型是利用過去軟件項目中收集的數(shù)據(jù)進行回歸分析導出待開發(fā)軟件的成本模型[1]。其整體結構如公式5所示：E=A+B×SC(5)ABC為經(jīng)驗性的導出常數(shù)，E為每個月的投入，S為主要輸入(常用源代碼行數(shù)LOC或功能點數(shù)FP)[1]。以LOG為主要輸入?yún)?shù)來計算的成本模型的例子：E=5.2×(KLOC)0.91 Walston-Felix模型E=3.2×(KLOC)1.05 COCOMO基礎模型以FP為主要輸入?yún)?shù)來計算的成本模型的例子：E=-12.39+0.0545FP Albrecht and Gdffney模型E=585.7+15.12FP Matson，Barnett，和Mellichamp模型

　　4.各類模型存在的問題分析

　　當一個模型有75%的準確性時，我們認為是可以接受。但目前大多數(shù)的模型無法達到這個標準[1]。從前面模型中不難看出，無論是模型結構、復雜度或軟件項目規(guī)模，都是靠開發(fā)者的經(jīng)驗估計出來的，而這些參數(shù)在開發(fā)的早期很難預測。大多數(shù)模型在當初導出它們的工作范圍內工作的很好，但應用于普通情況時表現(xiàn)很差。軟件需求是復雜的，有差異的。雖許多模型包含解決差異的調整因素，評估員可依靠調整因素去解決當前問題的任何變動，然而這種方法常常是不適當?shù)?。實際上，許多因素會相互影響，有時會導致過度忽略了某個因素的重要性。同時，這些方法也非常具有主觀性，常常帶有開發(fā)者的個人傾向。另外，調整因素的計算過程也過于復雜，不是一個容易確定的值。一般模型要求對軟件規(guī)模進行估算，但項目初期很難預測。對規(guī)模的估計結果也很主觀，并要求模型的規(guī)模度量與用于實際中的規(guī)模度量相同，否則不能給出準確的結果。

　　三、軟件項目成本管理中的直覺思維

　　直覺思維是指不受某種固定的邏輯規(guī)則約束而直接領悟事物本質的一種思維形式。許多項目管理人憑借直覺對項目成本的進行估算。項目管理人利用多年的經(jīng)驗和能力預測項目成本，有時這種估算很準確。同時這種以真實經(jīng)驗為基礎的人為的判斷也有利于對特殊情況的調整。項目管理人員在成本估算時常會借鑒以往的相似的項目經(jīng)驗，但項目管理人員很少考慮到相似項目的風險，如先前項目的成本是什么?先前項目所用的專有技術是什么?先前項目是否按計劃完成?先前項目有哪些地方出過錯誤?項目管理人員在進行成本估算時傾向于“軟性”的經(jīng)驗，而忽視先前項目執(zhí)行時的“硬性”證據(jù)。管理人員傾向依據(jù)少量的——大多數(shù)情況下僅一兩次——以往經(jīng)驗作出決定。缺乏足夠的經(jīng)驗，作出的估算是不可信的。另一個問題是傾向于依靠項目“專家”的定性闡述。項目管理者經(jīng)常會過度樂觀地看待項目的進展，會給出與事實偏離的現(xiàn)狀報告，這很容易造成錯誤的分配或浪費掉不可缺少的資源。研究證明，大多情況下主觀的判斷甚至不如最簡單的統(tǒng)計模型。這也表現(xiàn)出直覺思維的局限性——非邏輯思維是非必然的。試驗表明系統(tǒng)的分析整合工具和項目管理技術能夠改善項目的開發(fā)和管理。項目管理者不相信統(tǒng)計的結果是正常的，當統(tǒng)計分析的結果明顯低于項目總成本時，項目管理人常常調高估算，這是一種對成本估算的有效調整措施。所以，關鍵是如何將項目管理者主觀估算的能力和利用模型系統(tǒng)估算成本有機地結合起來。

　　四、結論

　　項目管理中的成本估算是非常困難的，它受很多因素的影響。用數(shù)學模型去估算成本時，有時不總是有效。許多項目管理人依靠自己的直覺去作出最佳估測，這種方法簡單易行，但它也存在很大的差異性。因此將數(shù)學模型與直觀判定結合使用構造合理估算，可同時具備各技術的優(yōu)點，是一種較好的方法。在軟件項目成本估算中，我們可以使用數(shù)學模型做初步估算，然后運用項目管理人的直覺調整結果。另外，在項目執(zhí)行和控制中也可以對特殊情況進行人為的判斷調整?，F(xiàn)在將兩種或多種技術結合來估算成本的合成技術估算方法應用較為廣泛。