软件项目工作量评估方法

工作量评估 概述

我们仔细研读了软件需求文档和设计文档，对软件功能进行了归纳和整理。根据以往的经验，对每个功能模块所需的编码工作量进行了估算，并以此为依据，推算出整个软件生命周期的工作量。接着，我们组织了主要项目干系人和相关专家进行工作量评审。

常见的估算方法

Ad-hoc方法

这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。

开发时间的百分比法

这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。通常预留项目的总花费时间的35%给测试。5-7%给组件和集成测试,18-20%给系统测试。10%给接收测试（或回归测试等）

类比法

根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：在设计和实现阶段花费的时间，测试工作的规模，例如用户需求的数量，页面数，功能点，数据样式，例如实体，字段的数量,屏幕或字段数量,测试对象的规模，例如KLOC

WBS估算法

将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。

Delphi法

Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。

Delphi法是一种软件项目评估方法，其步骤包括：协调人向各专家提供项目规格和估计表格；召集小组会讨论与规模相关的因素；各专家匿名填写迭代表格；协调人整理出一个估计总结，以迭代表的形式返回专家；召集小组会讨论较大的估计差异；专家复查估计总结并在迭代表上提交另一个匿名估计；重复4-6，直到达到一个最低和最高估计的一致。

PERT估计法对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计来得到一个产品期望规模和标准偏差的Pert统计估计。Pert估计可得到代码行的期望值E和标准偏差SD。

在估算前的准备阶段，我们综合了多种评估方法，总结出了适合我们公司的评估方法。这包括对工作进行WBS分解，尽量将任务分配到半天为工作单位的粒度，分解时需要考虑deadline、技术难点、需求变更风险等等因素；寻找和本项目相近项目做参考，参考历史相近项目的实际工作量和项目进度情况；邀请有历史经验或者对项目熟悉的专家，参与项目工作量的评估，以提高工作量评估的有效性；整理工作任务的关系和客户需求的优先级，寻找项目任务的关键路径，以保证项目周期的合理性和周期最短；确定项目评估工作的基线，以一名2年工作经验的开发人员为评估对象，选择了一个有10个字段的比较有代表性的业务表单，从开始到结束，精确统计了每个步骤需要的消耗的工时数，采用四舍五入法最终制作了工时估算表；确定技能系数，由于标准工时是按2年经验的工程师能力为基准，所以需要设置工程师能力系数，工作3到6年的

工程师，每增加1年工作经验则工时=标准工时*(1-0.1)，6年以上一般按6年算。

WBS分解原则包括：对工作进行WBS分解，尽量将任务分配到半天为工作单位的粒度，分解时需要考虑deadline、技术难点、需求变更风险等等因素。

WBS元素是WBS结构中的节点，类似于组织机构图中的方框。它们代表独立的可交付成果，具有隶属关系或汇总关系。WBS结构必须与项目目标相关，面向最终产品或可交付成果。因此，WBS元素适合描述输出产品的名词组成。只有抓住最核心的可交付结果，才能最有效地控制和管理项目。同时，只有识别出可交付结果，才能识别内部和外部组织完成此工作所使用的方法、程序和资源。工作包是最底层的WBS元素。

WBS字典是一种工具，用于描述和定义WBS元素中的工作文档。它相当于对某一WBS元素的规范，包括必须完成的工作、工作成果的描述和相应规范标准、元素上下级关系以及元素成果输入输出关系等。WBS字典对于清晰定义项目范围有着巨大的规范作用，使得XXX易于理解和被组织以外的参

与者接受。在建筑业，工程量清单规范就是典型的工作包级别的WBS字典。

WBS有多种用途。它是一个描述思路的规划和设计工具，帮助项目经理和团队确定和有效地管理项目的工作。WBS清晰地表示各项目工作之间的相互联系的结构设计工具，展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。XXX防止遗漏项目的可交付成果，帮助项目经理关注项目目标和澄清职责，建立可视化的项目可交付成果，以便估算工作量和分配工作，帮助改进时间、成本和资源估计的准确度，帮助项目团队的建立和获得项目人员的承诺，为绩效测量和项目控制定义一个基准，辅助沟通清晰的工作责任，为其他项目计划的制定建立框架，帮助分析项目的最初风险。

创建WBS的方法包括确定项目目标和可交付成果、分解可交付成果、组织WBS元素和编制WBS字典。这些步骤需要项目经理和团队的共同努力，以确保WBS结构清晰、完整和可行。

分配资源和监控工作进展。

将XXX提交给项目团队成员进行审查和确认，确保XXX的一致性和准确性。

在XXX中标识出关键路径和关键工作包，以便在项目执行过程中进行重点监控和控制。

在XXX中记录下与每个工作包相关的风险和机会，以便在项目管理过程中进行风险管理和机会利用。

XXX的创建是将复杂的项目分解为一系列明确定义的项目工作，以作为随后计划活动的指导文档。常见的创建方法有类比方法和自上而下的方法。创建WBS时需要满足一些基本要求，如某项任务只应在WBS中出现一次，WBS必须与实际工作中的执行方式一致等。同时，每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。XXX的表示方式可以由树形的层次结构图或者行首缩进的表格表示。在实际应用中，表格形式的WBS应用比较普遍。WBS的分解方式可以按产品的物理结构分解、按产品或项目的功能分解或按照实施过程分解。项目组内创建WBS的过程非常重要，需要得到范围说明书或工作说明书，并召集有关人员集体讨论所有主要项目工作，确定项目工作分解的方式。在创建过程中，应该尽

量利用现成的模板，并将主要项目可交付成果细分为更小的、易于管理的组分或工作包。XXX的审查和确认需要提交给项目团队成员进行，以确保XXX的一致性和准确性。在WBS中标识出关键路径和关键工作包，并记录下与每个工作包相关的风险和机会，以便在项目管理过程中进行风险管理和机会利用。

分解任务并分配负责人或组织单位。验证WBS的正确性，并对较低层次的项进行修改。建立一个编号系统，随着其他计划活动的进行，不断地更新或修正WBS，直到覆盖所有工作。

要检验WBS是否定义完全，项目的所有任务是否都被完全分解，主要依据以下标准：每个任务的状态和完成情况是可以量化的；明确定义了每个任务的开始和结束；每个任务都有一个可交付成果；工期易于估算且在可接受期限内；容易估算成本；各项任务是独立的。

对于WBS，需要建立WBS词典来描述各个工作部分，包括工作包描述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。当WBS与OBS综合使用时，要建立账目编码，用

于确定项目工作分解结构每一个单元的编码系统，成本和资源被分配到这一编码结构中。

XXX的实践经验表明，最多使用20个层次，多于20层是过度的。对于一些较小的项目，4-6层一般就足够了。WBS中的支路没有必要全都分解到同一层次，即不必把结构强制做成对称的。在任意支路，当达到一个层次时，可以作出所要求准确性的估算，就可以停止了。

在企业对外宣传方面，Web网站是一个重要的平台。企业可以通过网站让更多的用户和浏览者了解和认识企业，以便达到更好的宣传。Web网站主要面向客户、业界人士或者普通浏览者，以介绍企业的基本资料、帮助树立企业形象为主；也可以适当提供行业内的新闻或者知识信息。这种类型网站通常也被形象的比喻为企业的\"WEB Catalog\"，是每一个外贸公司对外贸易不可缺少的形象代言。

新技术的出现或者设计人员提出新的设计方案或实现手段，以及建设单位的业务变化或机构重组等原因，都可能导致项目中出现变更需求。然而，如果处理不当，就会出现一系列问题。例如，开发人员直接修改系统软件，没有书面记录用户的变更

需求，没有评估变更需求是否合理，也没有与其他项目相关成员进行沟通。因此，为了有效控制项目变更，建议建立一套正规的程序，包括识别变更、评价变更影响、设计备选方案、提出变更申请、征求项目干系人意见、批准或否决变更以及追踪变更实施情况等步骤。

关键路径在项目管理中非常重要，它是指网络终端元素的序列，具有最长的总工期并决定了整个项目的最短完成时间。任何关键路径上的终端元素的延迟都会直接影响项目的预期完成时间，因为关键路径上没有浮动时间。因此，寻找项目关键路径非常关键。

制定项目进度计划的基础是活动定义、活动排序、资源和历时估算的结果。项目进度计划不仅回答每个活动的进度安排，更重要的是提供项目整体的进度信息。常用的工具和方法有甘特图、关键路径分析和PERT估计。甘特图是一种用日历形式列出项目活动及其活动起止时间的图示方法，横道的起点和终点代表任务的起止时间，长度表示持续时间。里程碑是具有零历时的重要事件，用菱形符号代表。依赖关系指任务之间存在的关系，如结束-开始、开始-开始、结束-结束、开始-结束关系。概要任务是指一些任务集合成一个更大的任务，通常代表

任务的不同层级。甘特图简单明了，是目前应用最广泛的项目进度表示方法。

关键路径分析是一种用来预测总体项目历时的项目网络分析技术，也称为关键路径法。关键路径是指在项目网络图中存在的从项目启动到项目结束之间的路径中，其上所有活动的时间之和是完成项目的最短历时，路径上任何活动的延误都会导致项目时间的延长。如果想缩短项目历时，就必须缩短这条路径上活动的历时。关键路径是项目网络图中历时最长的路径，是一系列决定项目最早完成时间的活动。在关键路径上的活动直接决定了项目的进度，每个活动都只有最少的浮动时间或时差，即在不耽误后续活动或项目完成日期的条件下可以拖延的时间长度。

现在，项目管理软件工具都能够寻找项目的关键路径，这是最基本的功能之一。关键路径是通过正推法和倒推法计算得出的，这些方法可以输出项目的总历时和每个活动关于进度的“关键”信息。虽然手工计算项目的关键路径已经很少用到，但是深入了解这些算法可以更好地理解所得到的信息的意义。下面我们将介绍如何使用正推法和倒推法来计算项目的关键路径。

正推法和倒推法主要用于计算项目活动的以下四个参数： 最早开始时间（Early Start，简称ES），在满足条件的情况下，该活动可以开始进行的最早时间；

最早结束时间（Early Finish，简称EF），在满足条件的情况下，该活动可以完成的最早时间；

最晚开始时间（Late Start，简称LS），在不拖延项目进度的情况下，该活动可以开始进行的最晚时间；

最晚结束时间（Late Finish，简称LF），在不拖延项目进度的情况下，该活动可以完成的最晚时间。

如下图所示，对于每个项目活动，这四个参数都是一个时间点。

图-3 正推法和倒推法的活动参数

正推法从项目的第一个活动开始，跟踪所有活动的先后关系，计算每个活动的最早开始时间（ES）和最早结束时间（EF）。

倒推法从最后一个活动开始向前追溯到第一个活动，计算每个活动的最晚开始时间（LS）和最晚结束时间（LF）。

正推法的计算过程包括以下四步：

步骤一：将项目的第一个活动的最早开始时间设定为第一天，如图所示：

图-4 关键路径正推法的步骤一

步骤二：计算第一个活动的最早结束时间，可以使用第一个活动的最早开始时间加上该活动的历时减1得出：EF = ES + 历时 - 1，如图所示：

图-5 关键路径正推法的步骤二

步骤三：计算该活动的所有后续活动的最早开始时间（ES）：

后续活动的ES = 前导活动的EF + 1 XXX所示：

图-6 关键路径正推法的步骤三

步骤四：重复步骤二和三，为项目中的每个活动计算最早开始时间（ES）和结束时间（EF），如图所示：

EF = ES + 历时 - 1 ES = 前导活动EF + 1 图-7 关键路径正推法的步骤四

活动D最早开始时间为第31天，由于延误10天，结束时间为第60天。然而，这不会影响项目的结束时间。

假设活动C能在第21天开始，并在第40天完成，那么项目进度不会受到影响。但如果活动C延误，将导致活动D的资源短缺，从而导致活动D延误，最终导致项目延误。

总时差和自由时差是关键路径分析中的重要概念。总时差是指活动可以推迟的时间，而自由时差是指在不影响紧后活动最早开始的情况下，活动可以推迟的时间。

计算ES、EF、LS和LF的方法有正推法和逆推法。关键路径上的活动持续时间决定了项目工期，而关键活动是所有总时差为零或为负的活动。

进度压缩的方法包括增加人手、加班、并行、重新估算工期、加强沟通和控制，以及外包。

加强沟通，先完成关键需求，如果需要增加资源，有时可能会压缩工期。如果时间不允许，可以降低要求或减少项目的范围。

在本次评估中，我们对《IAS网络优化系统》进行了工作量估算。为了更准确地估算软件的工作量，我们为每个软件功能模块提供了三个估计值：悲观工作量、正常工作量和乐观工作量。针对每个功能模块，我们使用以下公式计算最终的工作量估算值：Ei =（Epi + 4×Eni + Esi）/ 6.

表1显示了对IAS网络优化系统终端的编码阶段的工作量估算，表2显示了对IAS网络优化系统平台端的编码阶段的工作量估算。请注意，这些估算值是根据程序员技能和对业务的理解程度等因素进行计算的。

投诉信息管理回复模板自动生成，无线参数设置，合计工作量为20人小时和30人小时。

平台工作量清单如下表所示，共29个功能，其中包括登录、项目进度统计、站点数据管理、测试记录管理、测试报告管理、测试LOG管理、GIS地图管理、log回放软件、系统日志管理、用户管理、合作单位系统对接模块、楼宇数据管理、天线工参数据管理、单位管理、测试数据管理、系统设置、地图浏览、工单流程管理、工单计时提醒、测试结果查看和测试日志下载回。其中，乐观工作量为8人小时，悲观工作量为16人小时，正常工作量为15.33人小时。

需要剔除格式错误和明显有问题的段落。

上述两个项目的编码阶段工作量合计为1783.33人小时，根据瀑布模型，我们可以将整个软件生命周期划分为六个阶段：

计划与需求、产品设计、详细设计、编码与单元测试、集成与测试、移交。其中，编码与单元测试阶段仅占全部工作量的24%。因此，根据表3，我们可以得出《X软赠券电脑发放管理系统》和《X软联销资源管理系统》的工作量估算值为7430.4人小时。

考虑到我国的实际情况，每周休息2天，每年还包括三个长假，我们假定每个月的工作日为20天，每个工作日工作8小时。根据这个假定，上述工作量换算成人月数应为46.44人月。

工作量估算出来后，项目经理会组成相关干系人和专家对工作量进行评审。评审会上，会对工作量的各项评审进行逐一评估，包括WBS编制、工作包的层次是否合理、是否对每个工作包都估算了工作量、预算和进度等等。同时，也会评估项目组织结构是否可行，职责分工是否明晰，人力资源人员配置是否合理，项目需要的资源是否确认可获等等。最后，还会评估项目整体工作量是否符合项目整体计划，项目关键路径是否合理，关键里程碑的设置是否合理，工作量难点分析是否详尽等等。