软件开发的工作量预估是预估软件开发或维护所需要的工作量（会以人以及工时或是金钱来表示），其参考输入多半是不完整、不可靠，并且带有噪声的资讯。工作量预估可以是专案计划、迭代计划、预算、投资分析、定价流程或竞标的输入。
有关预估实务的问卷指出，在预估工作量时，仍建议用专家预估为主要的作法。
一般而言，工作量预估往往会过于乐观，会明显的过度自信。最后的平均工作量会超过30%，而且不会随时间而减少。不过，有关预估量误差的量测有很多的问题，细节可参考预估的准确性评估。对工作量预估准确的强烈自信可以用以下方式说明：平均而言，若软件专业人士在评估实际工作量最大值—最小值的区间时，有90%的信心水准，或认为“几乎一定”准确，“过度自信”的情形，其估计区间符合实际量的比例只有60-70%。
目前“工作量预估”一词用来表示许多不同的概念，例如最可能的工作量（众数），准确率（实际工作量小于估计量）为50%的估计量（中位数）、计划的工作量、对应预算的工作量、或是用来竞标或报价的工作量。不同的人有不同的目标，但在沟通时用“工作量预估”表达其不同的需求。
自从1960年代起，软件研究者以及软件实作者就已提出软件开发专案上，预估工作量的问题，例如Farr和Nelson的研究。
大部分的研究着重在建立型式化的软件开发工作量预估模型。早期的模型一般是依回归分析，或是从其他领域的理论数学推导来的模型。之后已评估了许多模型建立的作法，其基础理论包括案例推论、分类和决策树、仿真、类神经网络、贝叶斯统计、需求规格的词法分析、遗传编程、线性规划、经济生产模型、软计算、模糊逻辑建模、统计bootstrapping（英语：bootstrapping），或是上述理论的组合。其中最常见的可能是参数化的预估模型：构造性成本模型（COCOMO）、SEER-SEM（英语：SEER-SEM）和SLIM。其预估研究的基础是在1970年代至1980年代形成，也配合新的校正资料进行更新，最新版的主要更新是2000年的COCOMO II。以机能基础的大小量测为准进行的预估作法，例如机能点（英语：function points）也是依1970年至1980年的研究所产生,不过也依修正后的大小量测方式以及不同计数方式来进行校正，例如1990年代的用例点（英语：Use Case Points）或物件点（英语：object point）。
有许多方式可以为预估（估计）方式分类。以下是最顶层的分类：
以下是各分类中的一些例子。
根据不同预估方式以及模型之间的预估准确度之间差异的资讯，可以得知没有“最佳方式”，各方式和模型之间互相比较的相对准确度，和其专案情境有强烈的相关性。因此不同的组织会适合不同的预估方式。支持依期望准确度来选择预估方式的发现包括：
在许多预估领域中，最可靠的发现是整合来自各独立来源，应用不同预估方式，所得的结果，平均来说这可以提升预估的准确性。
很重要的是知道软件开发生产力传统度量方式的限制。
此外，在选择方式的阶段，也需要考量其他因素，例如方式的结果是否容易理解和进行沟通、方式使用上的难易度、以及导入预估方式的成本等。
最常见平均预估准确度的测量方式是MMRE（相对误差量值的平均），其中每一个估计量的MRE（相对误差量值）是：
=
此测量方式有受到一些人的质疑，也有一些其他的测量方式，例如更对称的测量方式、相对误差的四分位数加权平均值（Weighted Mean of Quartiles of relative errors、WMQ）及估测不平均变异（Mean Variation from Estimate、MVFE）。
若个别资料有歪斜特性，MRE就不可靠了。此时比较会用到PRED(25)来用测量预估准确度。PRED(25)测量预测值在实际值25%误差范围内的比例。
高预估误差不能自动解释为低预估能力的指标。替代、竞争、互补的原因包括专案的低成本控制、开发工作的高复杂性、或是实际交付的机能比一开始规划时要多。也有一些框架可以改善预估误差量测的使用及改善。
在预估软件开发工作量时，过于乐观的情形，可能有许多的心理层面因素，若要增加预估的准确性，需要处理这些层面的议题。这些因素是本质性的，就算是用型式化预估的方式，因为其输入是依判断而决定的，仍会受心理因素的影响。重要的心理因素包括：一厢情愿、锚定效应、计划谬误（英语：planning fallacy）及认知失调。Jørgensen和Grimstad的著作中有相关议题的探讨：
有关开发工作量时常被低估的讽刺性情形，因此出现了一些常见的讽刺性的说法，例如将一些任务视为“软件开发上的小事（英语：small matter of programming）”（认为需要投入的心力不多），以下则是一些有关工作量低估的定律：
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.
预估工作量本身是件困难的工作，不适当的增加资源（甚至包括人力）对时程也不一定有帮助。
