工作量估算

anderolujun

于 2024-08-23 14:06:27 发布

阅读量425

点赞数 15

分类专栏：项目管理 # 项目度量文章标签：软件工程产品经理

本文链接：https://blog.csdn.net/anderolujun/article/details/140926808

版权

项目度量同时被 2 个专栏收录

9 篇文章 0 订阅

订阅专栏

项目管理

1 篇文章 0 订阅

订阅专栏

一、工作量概述

工作量定义为完成某个项目或系统开发所需的全部人力资源的成本总和，包括项目从立项到项目验收交付为止的整个过程中的需求分析、设计开发、集成、测试、试运行及项目管理、配置管理、质量保证等所有活动。工作量通常是以人天、人月或人年等单位来衡量。
工作量估算是由软件规模和与其他相关的因素决定的。规模估算源于功能需求，需求决定了规模:根据规模，再结合其他的项目因素如业务类型、团队的技术和能力、所使用的语言和平台、软件的复用程度、团队的稳定性、项目的自动化水平等，即可估算出软件的工作量，进而估算出软件成本。工作量估算一般在规模估算的基础上开展，若项目未开展规模估算，也可直接启动工作量估算工作。

二、工作量估算方法

用于估算软件开发工作量的方法有许多，常用的有类推法、类比法、WBS、专家经验估算法、方程法等。一般情况下，估算工作量都是以规模估算的结果作为基础，然后使用方程法进行估算。

1.类推法

属于以“估”为主的方法。将待评估项目与过去的一个或多个项目进行比较推算，确定特别相似或不同的地方，最后基于这种差异对实际工作量进行调整。当需求非常模糊时，甚至预估算法估算规模都比较吃力。如果此时有高度类似的历史项目，可直接选择类推法。

采用类推法时应注意，所选择的历史项目与待评估项目一定是高度相似的，历史数据尽量选择本组织内的数据，并且一定要对差异之处进行调整。虽然类推法是迄今为止理论上最可靠的估算方法，但是，由于它是以“估”为主，脱离不了评估人员的主观性，所以估算结果也是经常产生极大偏差。

1.1 使用说明
- 要选择与历史项目在某些方面高度相似的项目，比如业务类型、项目类型、应用领域、质量要求、复杂性等。
- 项目估算的精确度取决于历史项目数据的完整性和准确度。如若没有类似的历史项目，切不可使用该方法。
1.2 示例

借用官方的示例：

项目描述:为政府部门甲新开发一办公自动化(OA)系统，以支持其网上办公、文档流转等电子政务需求。

历史项目情况:为政府部门乙开发过类似系统，部门甲、乙对功能要求有所差别，但项目规模、难度、质量要求等差异不大。

参考项目数据如下:开发总工期为4.92个月，总工作量为4625人时。其中，项目策划阶段的工作量为78人时，需求阶段的工作量为555人时，设计阶段的工作量为694人时，构建阶段的工作量为1619人时，测试阶段的工作量为922人时，移交阶段的工作量为757人时。

估算工作量:考虑到该项目可将为部门乙开发的系统作为原型了解客户需求，假设需求分析阶段可减少约1/3工作量，则预计项目工作量=78+555x2/3+694+1619+922+757=4440(人时)。

2.类比法

属于以“算”为主的方法。当待评估项目与已完成项目在某些项目属性上(如应用领域、系统规模、复杂性程度、开发团队经验等)相类似时，可使用类比法。它是基于大量历史项目样本数据来确定目标项目预测值的。

2.1 使用说明
首先要基于主要的项目属性对基准数据进行筛选，常用的比较因子包括应用领域、系统规模、接口数、团队经验等等。
类比法比对的项目数量不可过少。如果过少，要考虑不同项目属性分别筛选比对，综合考虑工作量的估算结果。
如果参照的基准数据是行业级数据库，一般筛选后项目数量不少于20个，则具有较高的可信度；数量介于7～20个，具有一定的可信度；项目数量少于7个，可信度较低。
如果参照的基准数据是企业级数据库，一般筛选后项目数量不少于7个，则具有较高的可信度；数量介于2～7个，具有一定的可信度；项目数量少于2个，则可信度较低。
如果筛选后项目数量过少，可以选择单一属性分别筛选对比，然后采用多次属性筛选后平均值作为估算结果。

2.2 示例

借用官方示例说明，

项目描述:为政府部门甲新开发一个OA系统，以支持其网上办公、文档流转等电子政务需求。

主要属性识别:可以识别出项目的3个主要属性是开发类型、业务领域和应用类型，分别为“新开发”、“政府”、“OA”。

筛选比对:假设查询行业基准数据库后发现，同时符合3个筛选条件的项目只有2个，数量过少。因此，选择单一属性分别比对，获得如下表所示的工作量数据查询结果。

属性	项目数量	P10	P25	P50	P75	P90
新开发	105	1005	1983	5892	12406	98727
政府	52	892	2416	4713	9319	43658
OA	34	576	2025	5128	7144	21990

估算工作量:该项目所需工作量的最可能值为(5892+4713+5128)/3，即5244人时。工作量估算的合理范围大致为2141~9623人时(上、下限值分别采用P25 和 P75的值进行计算)。
3.WBS

WBS(Work Breakdown Structure)是项目管理中的一种基本方法，是一个在项目全范围内分解和定义各层次工作包的方法。按照项目的发展规律，可以进行系统化的、相互关联和协调的层次分解。

3.1.使用说明
- 按照开发过程和功能特点可以将软件项目分解为几个层次部分。注意，分解时不能仅仅关注与功能相关的部分，还要考虑项目管理、配置管理等活动。切记不要遗漏跟客户约定的交付物。
- 对工作进行细分之后将任务分配到人，每个人对自己承担的任务工作量进行估算，然后累加即可获得估算结果。这样的估算准确度相对比较高。当然，进行WBS的前提是需求清晰完整。
- 如果功能需求模块比较难以估算，也可以与专家经验法结合起来进行估算。专家经验法在后面说明。
- 项目管理工作量的估算。对于小型项目，一般建议项目管理工作量占软件开发工作量的10%～15%；中大型项目占开发工作量的15%～25%；大型或复杂的项目占比都在25%以上。以个人的经验，考虑到项目的复杂度、实际规模及具体环境等多个因素，一般都在15%的基础上增减。另外，在我们国内的很多项目中都存在一种观念，项目管理的工作可以由相关的业务或技术负责人兼任。从个人的经验来看，对于小型项目都无可厚非。如果项目组成人员超过10人以上，会给项目管理复杂度带来指数级的增加，这时最好要专设一个项目经理进行专门的项目管理工作。
- 测试工作量的估算。测试一般包括集成测试、系统测试、性能测试等,一般情况下测试工作量占开发的30%左右，如果是敏捷项目，占开发工作量的占比相应提升。
5.专家经验法

属于“直觉”占重要地位的一种估算方法，主要依赖参与估算的相关专家的经验和对项目的理解对项目进行估算。Delphi法是目前最流行的专家估算方法，该方法可以较有效的减少专家对项目的理解程度所带来的偏差。它以工作任务拆分后形成的任务表为基础进行的，要求有多种相关经验人的参与。强调由多人进行估算，以避免个人估算的局限性和片面性，使估算结果尽可能更接近实际。

5.1 实施过程
- 首先，由各个专家匿名填写估算表，每位专家提出3个估计值:乐观值a、最大可能值m和悲观值b，各个专家之间不能相互讨论，有问题可以找主持人协调。
- 主持人整理出专家们的估算结果，计算每位专家的期望值 $E_{i}=(a_{i}+4m_{i}+b_{i})/6$ ，平均值 $E = (E_{1}+E_{2}+...+E_{i})/n$ 。利用三点估算法计算出每个专家估算的工作量期望值，然后求得所有专家工作量期望的平均值。
- 主持人召集小组会，讨论较大的估算偏差，找出原因。如果估计总结的偏差值大于所设定的偏差值标准，则由估计值较大的专家和估计值较小的专家分别介绍各自的估计原因。偏差值可以自己讨论设定计算公式，这里：偏差值=(最大值-最小值)/平均值，偏差值设30%左右即可。如果专家估算的结果偏差值超过设定的百分比，估计值较大和较小的专家就要分析原因。
- 分析了偏差出现的原因之后，各专家重新进行估计。该步骤要适当地重复多次，直到最后估计结果收敛在预先设定的偏差标准内为止。
- 进行多轮次的估算、讨论、汇总等，当估算任务满足条件时结束。
5.2 使用说明
- 专家组的人数要求最少3人，一般5～10人。
- 专家经验法评估的前提是需求明确清晰，并且已经进行了WBS的任务分解。分解的粒度不易把握尺度，一般建议每个分解后的功能模块所需的工作量为20～40人天。
- 上面设置的偏差值为30%，对于工作量评估而言，30%是一个比较严格的要求。工作量评估前，专家小组可以讨论偏差值能否接受，少部分情况下也可以将偏差值的范围放大至40%。
- 专家经验法在缺少量化、历史数据的情况下被经常使用，但该方法要求估算专家的高素质，参与者们需要具备丰富的相关项目开发经验；对项目的开发、应用领域以及成本预算等都非常清楚。
5.2 示例
- 专家评估过程

选定5位专家来评估办公门户项目的工作量，专家在评估过程中不可协商，有问题要通过主持人协调。系统包括已办、待办、签报、议题、用印管理、台账等模块，5位专家分别对各个模块进行评估，评估结束后反馈给主持人进行汇总，汇总结果可参考如下表格。

汇总评估结果后，识别出每个专家估算结果的最大、最小值，然后按照5.1计算公式求得每位专家估算结果的平均值和期望（即加权平均值）。然后判断偏差是否超出目标偏差30%，偏差计算公式：偏差值=(最大值-最小值)/平均值。如果某个模块第一轮评估的偏差超过30%，先分析原因，然后继续下一轮评估，直到偏差值在30%以内为止。如上表所示，所列模块的评估都超过1轮，签报模块评估了3轮才符合要求。

- 专家评估报告

如果所有模块的评估结果都在偏差范围以内，主持人汇总统计结果，即可宣布评估结束。然后填写专家评估报告，报告内容如下：

如报告所示，依据加权工作量，最终的评估结果为285人天。

6.方程法
6.1 使用说明

方程法就是通过数学算法来计算工作量。这里，工作量被看作一个由规模、产品特性以及开发环境因子等诸多变量构成的方程。所以，软件规模是采用方程法估算工作量的一个准入条件，如果没有规模估算，也无法实施方程法估算这一步。因此，具备软件的规模、并且是准确的规模非常重要。

采用方程法估算工作量时，首先根据本公司的实际情况进行回归分析，建立回归方程。方程法也成为参数模型法，因其重点集中在影响工作的因素上。它将软件因素、开发因素等所有影响因子都考虑在内建立多元方程，也可以先根据部分影响因子算出初步结果，再对结果进行调整。如果没有公司级的基准数据，也可以先使用行业级的基准数据进行估算。行业级模型示例如下。

行业级模型: AE=(SxPDR)xSWFxRDF 式中，

AE调整后工作量，单位为人时；

S--软件功能规模，单位为功能点；

PDR--生产率，单位为人时/功能点；

SWF--软件因素调整因子；

RDF--开发因素调整因子。

6.2 示例
方程法的示例可以参考之前的快速功能点估算示例
三、小结

从上面的介绍中可以看到，不同估算方法都有其优势和劣势，没有任何一种估算方法能适用所有类型的开发，选择合适的估算方法尤其重要。同时，也要意识到软件开发方法和技术的快速更新，给估算方法也提出新的挑战，在估算方法方面也要与时俱进。

1. 工作量估算方法的选择

对于已经进行规模估算的项目，可以采用方程法
对于没有进行规模估算、有基准数据参考的项目，可以采用类比法
对于没有进行规模估算、有类似历史项目参考，可以采用类推法
没有规模估算、没有历史项目参考，采用专家经验法估算

2. 工作量估算方法汇总

估算方法	方法描述	优点	缺点
类比法	与属性类似的历史项目比较，并根据项目历史数据确定工作量估算值	类比法基于历史数据和经验，可以提高类似项目估算的准确性。相比其他方法，过程更简单、效率更高。	只适用于类似项目，如果项目差异较大就不适用；可能会忽略项目间的细节差异，而导致工作量估算偏差；历史项目的数据如果不准确，就会影响估算的准确度
专家经验法	基于专家判断的估算方法，通过多个专家的估算以避免个人估算的局限性	基本不需要历史数据的支持，对没有历史数据积累或新业务领域的项目适用	对专家的业务领域知识、技术能力等有较高的要求，如果相关经验不足，会影响估算准确度；主观性较强，很容易发生个体之间的意见不一致；专家估算经常要经过多轮估算，比较耗费时间；
方程法	通过算法模型和各种项目因素来估算工作量	估算模型可以根据历史数据调整，以适应不同的开发环境和产品特性	参数模型同样依赖于历史数据的准确度;估算带有一定的主观性，不同人员对参数的估算会造成比较大的估算偏差；参数模型需要不断更和调整，这需要大量的资源

四、注意事项
1. 工作量估算结果要使用范围

工作量受到的影响因素很多，很难得到一个精确的值。工作量估算结果一般都以范围的形式呈现，包括工作量的最可能值，以及合理的范围。

2. 估算结果要交叉验证

为提高估算的准确性，工作量估算宜采用不同的方法分别进行交叉验证。如果估算结果差异较大，可以采用专家经验法确定估算结果，也可以使用简单的加权平均法出差异情况进一步处理。

例如，某项目运用参数模型法（方程法）估算所得工作量PMc，运用WBS法所得工作量PMw，对两者进行比较、分析，主要计算两种估算方法的差异系数，来检查两种方法所得结果差异的大小。差异系数公式如下：
$\delta _{1}=\frac{\left | PMc-PMw \right |}{PMc+PMw}$ x100%

上述公式不难推导。根据差异系数定义描述，2个数的差异系数是标准差和平均值的比值。所以，即可得到如下公式。其中，2个数的标准差用SD表示、平均值用MN表示。

$\delta _{1}=\frac{CD}{MN}$ $\times$ 100%

$MN =\frac{PMc+PMw}{2}$

$CD=\sqrt{\frac{(PMc-MN)^{2}+(PMw-MN)^{2}}{2}}$

所以经过化简即可推得下式， $\delta _{1}=\frac{\sqrt{\frac{(PMc-MN)^{2}+(PMw-MN))^{2}}{2}}}{\frac{PMc+PMw}{2}}=\frac{\left | PMc-PMw \right |}{PMc+PMw}$
差异系数设定为10%。分析 $\delta _{1}$ ，如果计算所得 $\delta _{1}$ >10%，就说明两种方法所得结果偏差过大，需要对两种估算方法分别进行检查、分析，寻找漏洞，再次计算差异系数 $\delta _{1}$ ，直到差异系数符合设定的目标值区间。
另外，还应该与软件项目期望工作量进行比较，软件期望工作量指根据项目开发经验对项目最可能的工作量进行估算的值PMq，观察差异系数，若 $\delta _{2}$ >20%，则很可能估算过程有问题，需要进行检查。

$\delta _{2}=\frac{PMc-PMw }{2PMq}$

经过多次分析和模型修改后，对新估算所得工作量重新计算 $\delta _{1}$ 和 $\delta _{2}$ ，通常情况下,当 $\delta _{1}$ <5%且 $\delta _{2}$ <5%时是可以接受的,当然这个可以接受的差异系数也可以根据各组织具体需要进行修改。
对于经过多次对两种估算方法有效性的检查和差异系数的分析取得令人满意的估算结果之后，可计算项目的最终的工作量:
$PM=\frac{1}{2}(PMc+PMw)$
估算交叉验证通过对两种估算方法和结果的比较及过程的比较，分析两种方法估算过程中存在的问题，不断修正估算，多次循环，最终得到可以接受的较符合实际的工作量估算结果。估算交叉验证力求得出较为满意的估算结果，避免了只用一种方法的片面性。

anderolujun

关注

15
点赞
踩
14

收藏

觉得还不错? 一键收藏
0
评论
工作量估算

工作量定义为完成某个项目或系统开发所需的全部人力资源的成本总和，包括项目从立项到项目验收交付为止的整个过程中的需求分析、设计开发、集成、测试、试运行及项目管理、配置管理、质量保证等所有活动。工作量通常是以人天、人月或人年等单位来衡量。工作量估算是由软件规模和与其他相关的因素决定的。规模估算源于功能需求，需求决定了规模:根据规模，再结合其他的项目因素如业务类型、团队的技术和能力、所使用的语言和平台、软件的复用程度、团队的稳定性、项目的自动化水平等，即可估算出软件的工作量，进而估算出软件成本。
复制链接

扫一扫