軟件項目的規模、工做量和成本是如何進行估算的

1. 基於代碼行和功能點的估算

軟件項目的規模是影響軟件項目成本和工做量的主要因素。在基於代碼行(loc，line of code)和功能點(function point)的估算方法中，利用代碼行和功能點來表示軟件系統的規模，並經過對軟件項目規模的估算進而來估算軟件項目的成本和工做量。

顯然,一個軟件項目的代碼行數目越多，它的規模也就越大。軟件代碼行的數目易於度量，許多軟件開發組織和項目組都保留有以往軟件項目代碼行數目的記錄，這有助於在以往相似軟件項目代碼行記錄的基礎上對當前軟件項目的規模進行估算。

用代碼行的數目來表示軟件項目的規模簡單易行，天然、直觀且易於度量。可是其缺點也很是明顯。在軟件開發初期很難估算出最終軟件系統的代碼行數;軟件項目代碼行的數目一般依賴於程序設計語言的功能和表達能力;採用代碼行的估算方法會對那些設計精巧的軟件項目產生不利的影響;該方法只適合於過程式程序設計語言，不適合於非過程式程序設計語言(如函數式或者邏輯語言)。

針對上述問題，人們提出用軟件系統的功能數目來表示軟件系統的規模。1979年ibm的albrecht提出了計算功能點的方法。該方法須要對軟件系統的二個方面進行評估，即評估軟件系統所需的內部基本功能和外部基本功能，而後根據技術複雜度因子對這二個方面的評估結果進行加權量化，產生軟件系統功能點數目的具體計算值。具體的，如下是軟件系統功能點的計算公式。

fp = ct× (0.65 + 0.01×sfi) (i=1..14)

其中，ct是5個信息量的「加權和」，fi是14個因素的「複雜性調節值」(i =1..14)，0.65和0.01是經驗常數。

ct的計算方法如表 3所示，ct =(簡單用戶輸入數×3 +通常用戶輸入數×4+複雜用戶輸入數×6)+(簡單用戶輸出數×4+通常用戶輸出數×5+複雜用戶輸出數×7)+(簡單用戶查詢數×3+通常用戶查詢數×4+複雜用戶查詢數×6)+(簡單文件數×7+通常文件數×10+複雜文件數×15)+(簡單外部界面數×5+通常外部界面數×7+複雜外部界面數×10)。其中，用戶輸入數是指由用戶提供的、用來輸入的應用數據項的數目;用戶輸出數是指軟件系統爲用戶提供的、向用戶輸出的應用數據項的數目;用戶查詢數是指要求回答的交互式輸入的項;文件數是指系統中主文件的數目;外部界面數是指機器可讀的文件數目(如磁盤或者磁帶中的數據文件)。

例如，假設項目組要開發一個軟件項目a。根據用戶的需求描述，該軟件項目的ct取值如表 5所示。進一步的，假設該軟件項目的14個複雜性調節值所有取平均程度。那麼根據表 5可知，該軟件項目的ct=341，14個複雜性調節因素的累加值sfi=42，於是根據公式fp = ct× (0.65 + 0.01×sfi) (i=1..14)可知，該軟件項目的功能點fp=341× (0.65 + 0.01×42) = 364.87，即該項目的功能點數目大體爲364。

用功能點來表示軟件項目規模的好處是：軟件系統的功能與實現該軟件系統的語言和技術無關，並且在軟件開發的早期階段(如需求分析)就可經過對用戶需求的理解得到軟件系統的功能點數目，於是該方法能夠較好地克服基於代碼行軟件項目規模表示方法的不足。其不足主要體如今：該方法沒有直接涉及算法的複雜度，不適合算法比較複雜的軟件系統;功能點計算主要靠經驗公式，主觀因素比較多;此外計算功能點所需的數據很差採集。

大量的實踐代表：針對特定的程序設計語言，軟件系統的功能點和代碼行兩者之間存在某種對應關係(如表 6所示)。根據該表的數據，一個功能點若是用匯編語言來實現大約須要320行代碼，若是用c語言來實現大約須要150行代碼，若是用smalltalk語言來實現大約須要21行代碼。從另外一個角度上看，該表反映了不一樣程序設計語言的描述能力是不同的。

假設用l表示軟件系統的規模(或者用loc表示，或者用fp來表示)。針對一個具體的軟件項目，能夠採用自頂向下或者自底向上等多種方式來估算出軟件項目規模的樂觀值a、悲觀值b和通常值m，而後根據如下公式估算出軟件項目規模的指望值e：

e = (a + 4′m + b)/6

根據軟件項目規模的指望值e以及下列公式，就能夠估算出軟件項目的成本和工做量。

生產率

pm = l / e

其中，l表示軟件項目的規模(單位：loc或者fp)，e表示軟件工做量(單位：人月)，pm表示單我的月可以生產的功能點或者代碼行數。

平均成本

ckl = s / l

其中，s爲軟件項目總開銷，l表示軟件項目的規模(單位：loc或者fp)， ckl表示每行代碼或者每一個功能點的平均成本。

對於一個特定的軟件開發組織或者項目組而言，其軟件生產率和平均成本在不一樣的軟件項目實施中多是比較穩定的。若是有以往軟件項目的歷史信息，能夠很容易地得到關於軟件開發組織或者項目組的pm和ckl值。所以，一旦估算出了軟件項目的規模，得到了軟件開發組織或者項目組的pm和ckl的值，就可根據公式ckl = s / l計算出軟件項目的成本s = ckl′ l，也可根據公式pm = l / e計算出軟件項目的工做量e= l / pm。

例如，假設項目組要開發一個軟件項目a，通過估算該項目的規模是364個功能點。進一步的，根據以往的歷史數據，該項目組軟件開發的生產率是8fp/人月，每一個功能點的平均成本爲12000元人民幣，那麼該軟件項目的開發成本s = 6800元人民幣′ 364 = 247，5200元人民幣，工做量爲e= 364/ 8 = 45.5人月。

基於經驗模型的估算

基於經驗模型的估算根據以往軟件項目實施的經驗數據(如成本、工做量和進度等)創建相應的估算模型，並以此爲基礎對軟件項目開發的有關屬性進行估算。構造性成本模型cocomo(constructive cost model)是目前應用最爲普遍的經驗模型之一。

在二十世紀七十年代後期，boehm對多達63個軟件項目的經驗數據進行了分析和研究，在此基礎上於1981年提出了cocomo模型用於對軟件項目的規模、成本、進度等方面進行估算。boehm把cocomo模型分爲基本、中間和詳細三個層次，分別支持軟件開發的三個不一樣階段。基本cocomo模型用於估算整個軟件系統開發所需的工做量和開發時間，適合於軟件系統開發的初期。中間層次的cocomo模型用於估算各個子系統的工做量和開發時間，適合在得到各個子系統信息以後對軟件項目的估算。詳細層次的cocomo模型用於估算獨立的軟構件，適合在得到各個軟構件信息以後對軟件項目的估算。因爲篇幅限制，本書僅介紹基本cocomo模型，其模型形式描述以下。

e = a * (kloc)b 。其中e是軟件系統的工做量(單位：人月) ，a和b是經驗常數，其取值見表 7，kloc是軟件系統的規模(單位：千行代碼)。該公式描述了軟件系統的規模與工做量之間的關係。

d = c * ed。其中d是開發時間(單位：月)，c和d是經驗常數，其取值見表 7。該公式描述了軟件系統的開發時間與工做量之間的關係。

cocomo模型是一個綜合經驗模型，它考慮了諸多因素，於是是一個比較全面的估算模型。cocomo模型有許多參數，其取值來至於經驗值。該估算模型比較實用、易於操做，在歐盟國家應用較爲普遍。

例如，針對上面所述的軟件項目a，若是已估算出該項目的軟件規模是33.3kloc，並且該項目屬於半獨立型，即cocomo模型中的參數a、b、c、d的取值分別是3.0、1.十二、2.五、0.35，那麼根據模型公式e =a * (kloc)b能夠估算出該項目的工做量是3.0*(33.3)1.12，即152人月;而後根據公式d = c * ed能夠估算出該項目的開發時間是2.5*(152)0.35，即14.5月。

2. 其它估算方法

其它估算方法包括：專家估算、類比估算等等。

專家估算方法是由一組專家來對軟件項目所需的成本、工做量和進度等進行估算。通常地，這些專傢俱備應用領域或者開發環境方面的知識、參與了以往相似軟件項目的開發。爲了不專家估算的片面性，專家估算方法通常要求每位專家給出估算的最小值a、可能值m和最大值b，而後計算出每位專家估算的平均值esti =(a+4m+b)/6，最後根據各位專家的估算狀況計算出最終的估算值est=(est1+est2+est3+……+estn)/n。若是軟件開發組織或者項目組擁有一批經驗豐富的專家，能夠考慮採用該方法。專家估算方法具備人爲因素多、主觀因素大的特色，通常應用於軟件開發的初期階段，此時軟件項目組每每難以得到估算軟件項目所需的各類數據和信息。

類比估算方法是指估算人員根據以往相似軟件項目實施所積累下來的數據，經過分析待開發軟件項目和以往軟件項目兩者之間的類似性，估算出軟件項目的開發工做量、成本和進度等。使用該方法的前提是：待估算的軟件項目和以往的軟件項目必須具備必定的類似性(如它們均屬於一樣的應用領域)，而且擁有以往相似軟件項目的開發數據(如工做量、週期、參與的人數、規模和成本等)。

軟件估算髮生在事前，於是估算的結果與實際的結果有所誤差是不可避免的。可是，若是估算的誤差過大，那麼估算的結果將會對軟件項目的實施和管理產生消極的影響，甚至可能致使軟件項目的失敗。所以，在對軟件項目的規模、成本和工做量等進行估算的過程當中，要避免低劣的估算，儘量地得到合理和準確的估算數據。

 

做者：irenbest 來源：希賽網 發佈於 2016-4-19