軟體開發工作量預估

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

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

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

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

大部份的研究著重在建立型式化的軟體開發工作量預估模型。早期的模型一般是依迴歸分析，或是從其他領域的理論數學推導來的模型。之後已評估了許多模型建立的作法，其基礎理論包括案例推论、分類和决策树、仿真、類神經網路、贝叶斯统计、需求規格的词法分析、遗传编程、线性规划、經濟生產模型、软计算、模糊逻辑建模、統計bootstrapping（英语：bootstrapping），或是上述理論的組合。其中最常見的可能是參數化的預估模型：构造性成本模型（COCOMO）、SEER-SEM（英语：SEER-SEM）和SLIM。其預估研究的基礎是在1970年代至1980年代形成，也配合新的校正資料進行更新，最新版的主要更新是2000年的COCOMO II。以機能基礎的大小量測為準進行的預估作法，例如機能點（英语：function points）也是依1970年至1980年的研究所產生,不過也依修正後的大小量測方式以及不同計數方式來進行校正，例如1990年代的用例點（英语：Use Case Points）^[11]或物件點（英语：object point）。

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

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

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

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

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

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

很重要的是知道軟體開發生產力傳統度量方式的限制^[22]。

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

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

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

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

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

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

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

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

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

• 90-90法则：

• 侯世达定律：

• 布魯克斯法則：

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

• 不定度錐（英语：Cone of uncertainty）
• 軟體工程的成本預估（英语：Cost estimation in software engineering）
• 成本預估模型（英语：Cost estimation models）
• 成本超支（英语：Cost overrun）
• 機能點（英语：Function points）
• 計畫謬誤（英语：Planning fallacy）
• Putnam模型（英语：Putnam model）
• 軟體度量
• 軟體參數模型（英语：Software parametric models）