作者：曹济

摘要:随着中国经济近年来的快速增长，软件业也以前所未有的步伐飞速增长。但是在软件业快速增长的过程中，甲方管理软件项目存在着明显不足，尤为突出的是缺乏量化的项目管理机制。本文根据项目执行过程的先后顺序介绍了不同的项目量化估计和分析方法，包括功能点分析方法（Function Point Analysis）、国际软件标杆组织（International Software Benchmarking Standard Group）标杆分析方法和挣值分析（Earned Value）方法。

1.  背景 

随着中国经济的快速崛起，软件行业也以前所未有的步伐快速增长。但是在增长的过程中也存在很多隐患，其中最为明显的就是软件项目管理方面的问题。与其他行业相比对，中国软件行业最薄弱的环节在于缺乏量化管理机制。“如果不能度量，就无从有效管理”，软件项目管理的核心问题在于是否能将项目的状态用数据描述清楚。

绝大多数来自于政府机构的项目和行业客户的项目现在都采用招投标的方式来选择自己的供应商，客户必需在不同的供应商中间选择能够满意交付项目的开发商。不幸的是，真正让客户感到满意的项目少之又少。究其原因，是因为客户也好、开发商也好，往往不能在项目招投标期间设定合理的、可行的项目目标（包括项目的边界、周期、成本和质量）。 从项目最终所有权来看，项目当然是甲方的项目。所以甲方应在项目建设的过程中积极承担项目管理的职责，而不是采用简单的合同约束方式，将项目成功的期望完全寄托在乙方身上。

在很多情形下，甲方缺乏有效管理软件项目的基本技能。具体表现为以下两个方面

客户在项目前期缺乏客观的方法去定义和评价项目的范围、时间、成本和质量，只是根据不同开发商所提供的方案进行比对，自己缺乏主见

客户在项目执行过程中不能及时有效的监督项目的执行状态，而只是单纯的关注于项目的最终结果。不幸的是，这种结果导向型的方式往往伴随着高风险

本文通过项目实例描述了如何在项目的初期和中期采用量化管理机制来分析和管理项目。招投标阶段侧重于介绍FPA和ISBSG标杆分析方法的用、项目执行阶段则侧重于EV方法的应用。

2. FPA 方法在招投标阶段的应用

越来越多的政府客户和行业客户倾向于通过公开招标的方式来选取开发商，而他们所面临的一个首要的难题就是如何以客观的方式确定项目的标的和工期。现行的做法通常是对投标方所提供的不同方案进行比较后选取期望的供应商，很多客户往往会倾向于最低价中标，也有的客户会选择最接近中间值的供应商。但不管哪种方法都仍然存在风险，主要的原因在于客户自己没有足够的能力去判断到底应该需要多少预算和工期。为了解决这个难题，首先采用FPA方法对所需完成的项目规模进行估算。下面的例子对于功能点的主要步骤进行描述，如图一。详细的操作步骤参见相关文献[1]。

使用FPA方法估算项目规模时，首先对于要完成的系统功能进行分解，正如采用工作分解结构的方式对于项目的任务分解一样。不同的是，因为FPA是一个标准方法，所以对于分解的最细粒度有一致的规定[1]。首先根据功能的层次将应用分解为子系统，在子系统的基础上进一步拆分为功能模块，功能模块是否需要再行拆分则要考虑是否已经满足了功能点的细分要求。拆分后的功能参见表一。然后计算所有功能点的总和，对功能点求和：

（1）

然后再计算系统特征值（General System Characteristic）和调整系数（Value Adjusted Factor）： 

（2）

（3）

最终，通过计算得到功能点的值（Function Point Counting）

（4）

表一：基于FPA方法的功能点分解表

绝大多数的政府客户和行业客户在发包软件项目时，会签订固定总价合同，这是因为客户的预算往往基于年度预算。如果对于硬件类型的项目，当发生设备增加，客户会追加相应的费用。但是对于软件项目的变更因为缺乏与成本的直接关联关系，所以很难说服客户的上级（客户项目预算批准人）追加相应的成本。所以如果在项目执行的过程中发生客户需求变更时（通常是需求增加与修改）会给开发方带来额外的附加成本。所以应在发包时就充分考虑此因素。试想，开发方在项目做到一半时就发现是个亏损的项目，会对项目的最终结果造成什么样的影响呢？

所以在得到FPC后，还要再考虑一个能够反映需求膨胀因素的调整系数。综合客户的组织特征、业务的稳定性与连续性、最终用户的类型、技术解决方案以及项目周期等方面的影响，在示例项目中设定需求膨胀系数为30%。所以最终的项目规模为

根据上面的步骤，客户完全可以从自己的业务角度判断出项目的规模，然后再根据行业数据推导出项目所需的工作量和工期。再结合潜在供应商的人员特点以及薪酬水平可以测算项目的成本与工期。下面基于ISBSG的行业数据来计算项目所需的成本与工期，为招标项目设立相对客观的费用与工期参考基准。

3. ISBSG 标杆数据分析

3.1. 检查功能点分布模式

根据ISBSG的数据[2], 对于业务需求的功能点类型存在一定的分布模式。从行业的角度来看，存在如图二所示的分布规律，而该项目实例的分布规律则如图三所示。可以判断出两幅图的功能点类型还是非常接近的，除了图三中缺乏EIF类型的功能点（因为应用中没有访问外部应用数据）。因而能够判断出项目实例中的业务需求基本上是完整的。
所以，应用功能点分析方法可在项目招标之前判断客户需求的完整性，避免客户需求定义有较大的疏漏。

3.2. 根据平均生产率计算项目工作量

根据功能点类型检查需求的完整性之后，再根据功能点规模计算项目的工期和预算。设定示例项目的主要开发语言为Java 和 JavaScript ，开发平台为PC，根据ISBSG数据库可得到开发团队的中值生产率为9.7 hours/FP [2]，所以得到项目的工作量为9.7´1284 = 12455 Staff-Hours，将其转换为人月单位12455/(22´8)=71 Staff-Month。考虑到在很多组织中存在超时工作的情形，设定每天的工作时间为10小时（工作日的加班时间以及周末的额外工作时间分摊到五个工作日），所以调整后的工作量为(71´8)/10=56.8 Staff-Month。

3.3. 根据比对工具计算项目工作量和工期

通常情况下会采取不同的估算方法对同一组参数进行估计，以确保估算数据的一致性与有意义，也即常说的“多头凑”。此处采用ISBSG工具应用标杆分析法对工期和工作量估算，估算结果如图四所示。根据数据库中的数据，工作量的上四分位数、最可能值以及下四分位数分别是4756、 6256 和9953人时。而上节计算的工作量为12455人时，比下四分位数的9953还要多25%（而假定的生产率为中值生产率），看起来似乎自相矛盾。其实产生差异的根源来自抽样的数据：上一节估算方法约束只有两个匹配条件；而此处的匹配条件则多达十多项。正是因为比对的样本项目与示例项目更接近，所以会看到数据偏小。对于工期可以看到它的分布范围是4.6月到8.6月，最可能的值为7.1个月。

图四 ：根据ISBSG工具导出项目工期与工作量

3.4. 根据模拟公式计算项目工作量与工期

再采用ISBSG提供的模拟公式计算项目的生产率、项目的工作量与工期[2]。首先根据公式六计算项目的生产率

       (6)

根据项目特征（查表细节此处从略）设定 C=8.156, Size=1284, E1=-0.221, MxTeam=6, E2=0.662，由此可计算项目的生产率为5.49人时/FP。然后再根据公式（7）计算项目的工作量

      (7)

根据项目特征设定 C=8.156, Size=1284, E1=0.779, MxTeam=6, E2=0.662，计算项目的工作量为7050人时。最后再根据公式（8）计算项目的工期

    (8)

根据项目特征设定 C=0.677, Size=1284, E1=0.776, MxTeam=6, E2=-0.115，所以得到项目的工期为9.02个月。此处得到的数值与工具中得到的值又不一样，这是因为我们假定在不同的项目中存在相同的交付速率。

3.5. 折衷结果

综合上述不同的估计方法，最终设定示例项目的各个参数为6500人时（工作量）、8个月（工期）。这是通过在不同的方法之间以及专家经验的基础之上最终得到的折衷值。

4. 挣值方法在项目执行中的应用

前面的估算方法可帮助客户在项目前期确定项目的标的，并在此基础上对不同的供应商进行评价。但是往往随着项目的进行，开发商的主要活动表现为技术类型的活动，例如需求建模、架构设计、编码、测试等工作。因为甲方往往不具备技术背景，所以很难在这些时间段监督开发方的工作绩效。为了克服技术壁垒，甲方可借助于挣值分析法（Earned Value Management ）来有效监督开发方的工作[3]。

假定示例项目处于设计阶段而该阶段的持续时间为8周。所以首先得到和计划的工作量相关的第一个参数：计划值（Planned Value），如表二中的第二行（Planned (effort)）所示。这个参数描述了在指定的时间段内应该完成的工作内容，为项目设置了阶段目标，只不过这个目标值用实现该目标而需要投入的成本来表示（此种做法的必要性在于可以统一用货币值描述项目的状态）。第二个参数：挣值（Earned Value），如表二中的第四行（Planned (effort)）所示。这个参数描述了在指定的时间段内实际完成的工作内容，描述项目目前已经完成的工作内容的多少。第三个参数：实际值（Actual Value）。这个参数描述了完成对应的工作内容（EV）实际投入或消耗的成本是多少。根据挣值分析方法，监督三个参数之间的关系就可以监督项目的状态。因为前一阶段的工作的情况通常对后续阶段也会造成影响，所以采用跟踪三个参数累计值的方式描述项目的持续状态，如图五所示。

表二：基于工作量数据的挣值分析法

挣值分析方法有两类分析指标，分别是进度状态指标和成本状态指标。而这两类指标主要由上面描述的三个参数所决定，即PV,EV和AC。理想状况下，代表三类参数的累积曲线应完全重合，说明的进度和成本执行状况完全与计划重合。但在真实的项目中则很少会出现这样的情形，更多的体现为三条曲线之间的差异。下面介绍用于评价项目状态的不同公式。

如果公式（9）中的SV为正数，说明项目的进度提前，这是因为实际完成的工作内容（EV）大于计划完成的工作内容（PV）；反之，如果SV为负数，则说明项目的进度滞后。类似地可以对CV进行判断，如果CV为正，说明实际完成工作所对应的价值大于实际发生的成本，因而节省了预算；如果CV为负，则说明实际成本超出所完成工作内容对应的预算，因而成本超支。
所以使用挣值分析方法可以直观、快速判断项目的状态，例如图六，客户无需知道太多与项目相关的业务和技术细节，即能把握项目进展的状况 。

根据挣值分析对项目状态进行客观判断的前提是项目的计划具备合理性与可操作性，例如具备足够的细化程度，如果项目计划每项活动的持续时间都为一两周以上，则即使用挣值分析也不能客观反映软件项目进展的实际状况

5. 结论

为了改善甲方在软件项目管理中的“局外人”状况，除了商务合同的约束之外，甲方还应该逐渐采用和推行量化管理方法对开发方的工作进行有效监督与管理。甲方在招投标与合同签署阶段可以采用FPA、历史数据与行业数据等量化分析方法，而在项目执行阶段则可以借鉴挣值分析方法。除了本文所介绍的量化方法之外，甲方还可结合传统的量化管理方法（例如WBS与LOC估算方法以及其他基于特定行业的单元估算方法）对于项目的状态进行更为全面和准确的估算，从而对项目进行持续有效的监督与管理。

6.  参考文献

[1] 国际功能点用户组 (IFPUG), “Function Point Counting Practices Manual  release 4.2.1”, Jan, 2005
[2] 国际软件标杆组织 (ISBSG), “The Software Metrics Compendium” , Jan, 2005
[3] 项目管理协会 (PMI), “Exposure Draft Practice Standard For EVM 4-04”