软件开发工作量预估

软件开发的工作量预估是预估软件开发或维护所需要的工作量（会以人以及工时或是金钱来表示），其参考输入多半是不完整、不可靠，并且带有噪声的资讯。工作量预估可以是专案计划、迭代计划、预算、投资分析、定价流程或竞标的输入。

## 现行实务

有关预估实务的问卷指出，在预估工作量时，仍建议用专家预估为主要的作法。

一般而言，工作量预估往往会过于乐观，会明显的过度自信。最后的平均工作量会超过30%，而且不会随时间而减少。不过，有关预估量误差的量测有很多的问题，细节可参考预估的准确性评估。

对工作量预估准确的强烈自信可以用以下方式说明：平均而言，若软件专业人士在评估实际工作量最大值—最小值的区间时，有90%的信心水准，或认为“几乎一定”准确，“过度自信”的情形，其估计区间符合实际量的比例只有60-70%。

目前“工作量预估”一词用来表示许多不同的概念，例如最可能的工作量（众数），准确率（实际工作量小于估计量）为50%的估计量（中位数）、计划的工作量、对应预算的工作量、或是用来竞标或报价的工作量。不同的人有不同的目标，但在沟通时用“工作量预估”表达其不同的需求。

## 历史

自从1960年代起，软件研究者以及软件实作者就已提出软件开发专案上，预估工作量的问题，例如Farr和Nelson的研究。

大部分的研究着重在建立型式化的软件开发工作量预估模型。早期的模型一般是依回归分析，或是从其他领域的理论数学推导来的模型。之后已评估了许多模型建立的作法，其基础理论包括基于案例的推理、分类和决策树、仿真、类神经网络、贝叶斯统计、需求规格的词法分析、遗传编程、线性规划、经济生产模型、软计算、模糊逻辑建模、统计bootstrapping，或是上述理论的组合。其中最常见的可能是参数化的预估模型：构造性成本模型（COCOMO）、SEER-SEM和SLIM。其预估研究的基础是在1970年代至1980年代形成，也配合新的校正资料进行更新，最新版的主要更新是2000年的COCOMO II。以机能基础的大小量测为准进行的预估作法，例如功能点也是依1970年至1980年的研究所产生，不过也依修正后的大小量测方式以及不同计数方式来进行校正，例如1990年代的用例点或物件点。

## 预估方式

有许多方式可以为预估（估计）方式分类。以下是最顶层的分类：

- 专家估计：量化步骤（产生预估结果的步骤）是以判断过程为基础
- 型式化估计模型：量化步骤是以数学过程为基础，例如用历史数据推导而成的公式。
- 混合基础估计：量化步骤的基础包括判断，以及来自不同来源的预估值。

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

估计方式｜分类｜支持此估计方式的例子

类比基础的估计｜型式化估计模型｜ANGEL、加权微机能点

工作分解结构（从下往上）估计｜专家估计｜项目管理软件、公司特制的活动模版

参数化模型｜型式化估计模型｜COCOMO、Putnam模型、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%的开发时间，剩余的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.

做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。

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.

预估工作量本身是件困难的工作，不适当的增加资源（甚至包括人力）对时程也不一定有帮助。