軟件開發工作量預估

軟件開發的工作量預估是預估軟件開發或維護所需要的工作量（會以人以及工時或是金錢來表示），其參考輸入多半是不完整、不可靠，並且帶有雜訊的資訊。工作量預估可以是專案計劃、迭代計劃、預算、投資分析、定價流程或競標的輸入。

現行實務

有關預估實務的問卷指出，在預估工作量時，仍建議用專家預估為主要的作法。

一般而言，工作量預估往往會過於樂觀，會明顯的過度自信。最後的平均工作量會超過30%，而且不會隨時間而減少。不過，有關預估量誤差的量測有很多的問題，細節可參考預估的準確性評估。 對工作量預估準確的強烈自信可以用以下方式說明：平均而言，若軟件專業人士在評估實際工作量最大值—最小值的區間時，有90%的信心水準，或認為「幾乎一定」準確，「過度自信」的情形，其估計區間符合實際量的比例只有60-70%。

目前「工作量預估」一詞用來表示許多不同的概念，例如最可能的工作量（眾數），準確率（實際工作量小於估計量）為50%的估計量（中位數）、計劃的工作量、對應預算的工作量、或是用來競標或報價的工作量。不同的人有不同的目標，但在溝通時用「工作量預估」表達其不同的需求。

歷史

自從1960年代起，軟件研究者以及軟件實作者就已提出軟件開發專案上，預估工作量的問題，例如Farr和Nelson的研究。

大部份的研究着重在建立型式化的軟件開發工作量預估模型。早期的模型一般是依迴歸分析，或是從其他領域的理論數學推導來的模型。之後已評估了許多模型建立的作法，其基礎理論包括案例推論、分類和決策樹、仿真、類神經網絡、貝葉斯統計、需求規格的詞法分析、遺傳編程、線性規劃、經濟生產模型、軟計算、模糊邏輯建模、統計bootstrapping，或是上述理論的組合。其中最常見的可能是參數化的預估模型：構造性成本模型（COCOMO）、SEER-SEM和SLIM。其預估研究的基礎是在1970年代至1980年代形成，也配合新的校正資料進行更新，最新版的主要更新是2000年的COCOMO II。以機能基礎的大小量測為準進行的預估作法，例如機能點也是依1970年至1980年的研究所產生,不過也依修正後的大小量測方式以及不同計數方式來進行校正，例如1990年代的用例點或物件點。

預估方式

有許多方式可以為預估（估計）方式分類。以下是最頂層的分類：

• 專家估計：量化步驟（產生預估結果的步驟）是以判斷過程為基礎
• 型式化估計模型：量化步驟是以數學過程為基礎，例如用歷史數據推導而成的公式。
• 混合基礎估計：量化步驟的基礎包括判斷，以及來自不同來源的預估值。

以下是各分類中的一些例子。

估計方式	分類	支持此估計方式的例子
類比基礎的估計	型式化估計模型	ANGEL、加權微機能點
工作分解結構（從下往上）估計	專家估計	項目管理軟件、公司特製的活動模版
參數化模型	型式化估計模型	COCOMO、SLIM、SEER-SEM、TruePlanning for Software
大小為基礎的估計模型	型式化估計模型	機能點分析、用例分析、用例點、SSU（軟件大小單位）、敏捷軟件開發中以故事點（Story point）為基礎的估計、物件點
群體估計	專家估計	規劃撲克牌、寬帶德菲法
Mechanical combination	混合基礎估計	將類比基礎以及工作分解結構基礎的估計值進行平均
判斷式合併	混合基礎估計	依參數模型以及群體估計的基礎，再由專家判斷

預估方式的選擇

根據不同預估方式以及模型之間的預估準確度之間差異的資訊，可以得知沒有「最佳方式」，各方式和模型之間互相比較的相對準確度，和其專案情境有強烈的相關性。因此不同的組織會適合不同的預估方式。支持依期望準確度來選擇預估方式的發現包括：

• 專家預估大致上至少和以模型為基礎旳工作量預估一樣準確。特別有些情境下，存在不穩定的關係以及高重要性的資訊，模型中不會包括這些資訊。此情形下建議使用專家預估。前提是假定有相關經驗的專家可以諮詢。
• 型式化預估若沒有針對特定組織的情境來調整，其結果可能會相當的不準確。若無法確定預估模型中的核心關係（型式參數）是否是依類似情境的專案所產生，使用自身的歷史資料就格外的重要了。
• 型式化預估若已針對特定組織的情境來調整（不論是用歷史資料，或是依類似的專案或情境所推導的模型），這類的模型會格外的有幫助，而且專家預估常常會有太過一廂情願的問題出現。

在許多預估領域中，最可靠的發現是整合來自各獨立來源，應用不同預估方式，所得的結果，平均來說這可以提昇預估的準確性。

很重要的是知道軟件開發生產力傳統度量方式的限制。

此外，在選擇方式的階段，也需要考量其他因素，例如方式的結果是否容易理解和進行溝通、方式使用上的難易度、以及導入預估方式的成本等。

預估的準確性評估

最常見平均預估準確度的測量方式是MMRE（相對誤差量值的平均），其中每一個估計量的MRE（相對誤差量值）是：

MRE = ${\frac {|{\text{actual effort}}-{\text{estimated effort}}|}{\text{actual effort}}}$

此測量方式有受到一些人的質疑，也有一些其他的測量方式，例如更對稱的測量方式、相對誤差的四分位數加權平均值（Weighted Mean of Quartiles of relative errors、WMQ） 及估測不平均變異（Mean Variation from Estimate、MVFE）。

若個別資料有歪斜特性，MRE就不可靠了。此時比較會用到PRED(25)來用測量預估準確度。PRED(25)測量預測值在實際值25%誤差範圍內的比例。

高預估誤差不能自動解釋為低預估能力的指標。替代、競爭、互補的原因包括專案的低成本控制、開發工作的高複雜性、或是實際交付的機能比一開始規劃時要多。也有一些框架可以改善預估誤差量測的使用及改善。

心理因素

在預估軟件開發工作量時，過於樂觀的情形，可能有許多的心理層面因素，若要增加預估的準確性，需要處理這些層面的議題。這些因素是本質性的，就算是用型式化預估的方式，因為其輸入是依判斷而決定的，仍會受心理因素的影響。重要的心理因素包括：一廂情願、錨定效應、計劃謬誤及認知失調。Jørgensen和Grimstad的著作中有相關議題的探討：

• 人們知道的事務，很容易預估。
• 人們確定自己不知道的事務，不容易預估（已知的未知）。
• 人們不知道自己不知道的事務，非常不容易預估（未知的未知）。

相關的「定律」

有關開發工作量時常被低估的諷刺性情形，因此出現了一些常見的諷刺性的說法，例如將一些任務視為「軟件開發上的小事」（認為需要投入的心力不多），以下則是一些有關工作量低估的定律：

• 90-90法則：

“ （開發軟件時）前90%的代碼要花費90%的開發時間，剩餘的10%的代碼要再花費90%的開發時間。

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

” ——Tom Cargill，貝爾實驗室

• 侯世達定律：

“ 做事所花費的時間總是比你預期的要長，即使你的預期中考慮了侯世達定律。

It always takes longer than you expect, even when you take into account Hofstadter's Law.

” ——侯世達，《哥德爾、埃舍爾、巴赫》

• 布魯克斯法則：

“ 一個工程師花一個月可以完成的工作，二個工程師需要花上二個月的時間。

What one programmer can do in one month, two programmers can do in two months.

” ——佛瑞德·布魯克斯

預估工作量本身是件困難的工作，不適當的增加資源（甚至包括人力）對時程也不一定有幫助。

相關條目

• 不定度錐
• 軟件工程的成本預估
• 成本預估模型
• 成本超支
• 機能點
• 計劃謬誤
• Putnam模型
• 軟件度量
• 軟件參數模型