甲方如何采用量化机制管理软件项目

  摘要:随着中国经济近年来的快速增长，软件业也以前所未有的步伐飞速增长。但是在软件业快速增长的过程中，甲方管理软件项目存在着明显不足，尤为突出的是缺乏量化的项目管理机制。本文根据项目执行过程的先后顺序介绍了不同的项目量化估计和分析方法，包括功能点分析方法（Function Point Analysis）、国际软件标杆组织（International Software Benchmarking Standard Group）标杆分析方法和挣值分析（Earned Value）方法。
  
  1.　背景　
  
  随着中国经济的快速崛起，软件行业也以前所未有的步伐快速增长。但是在增长的过程中也存在很多隐患，其中最为明显的就是软件项目管理方面的问题。与其他行业相比对，中国软件行业最薄弱的环节在于缺乏量化管理机制。“如果不能度量，就无从有效管理”，软件项目管理的核心问题在于是否能将项目的状态用数据描述清楚。
  
  绝大多数来自于政府机构的项目和行业客户的项目现在都采用招投标的方式来选择自己的供应商，客户必需在不同的供应商中间选择能够满意交付项目的开发商。不幸的是，真正让客户感到满意的项目少之又少。究其原因，是因为客户也好、开发商也好，往往不能在项目招投标期间设定合理的、可行的项目目标（包括项目的边界、周期、成本和质量）。 从项目最终所有权来看，项目当然是甲方的项目。所以甲方应在项目建设的过程中积极承担项目管理的职责，而不是采用简单的合同约束方式，将项目成功的期望完全寄托在乙方身上。
  
  在很多情形下，甲方缺乏有效管理软件项目的基本技能。具体表现为以下两个方面
  
  客户在项目前期缺乏客观的方法去定义和评价项目的范围、时间、成本和质量，只是根据不同开发商所提供的方案进行比对，自己缺乏主见
  
  客户在项目执行过程中不能及时有效的监督项目的执行状态，而只是单纯的关注于项目的最终结果。不幸的是，这种结果导向型的方式往往伴随着高风险
  
  本文通过项目实例描述了如何在项目的初期和中期采用量化管理机制来分析和管理项目。招投标阶段侧重于介绍FPA和ISBSG标杆分析方法的用、项目执行阶段则侧重于EV方法的应用。
  

  2. FPA 方法在招投标阶段的应用
  
  越来越多的政府客户和行业客户倾向于通过公开招标的方式来选取开发商，而他们所面临的一个首要的难题就是如何以客观的方式确定项目的标的和工期。现行的做法通常是对投标方所提供的不同方案进行比较后选取期望的供应商，很多客户往往会倾向于最低价中标，也有的客户会选择最接近中间值的供应商。但不管哪种方法都仍然存在风险，主要的原因在于客户自己没有足够的能力去判断到底应该需要多少预算和工期。为了解决这个难题，首先采用FPA方法对所需完成的项目规模进行估算。下面的例子对于功能点的主要步骤进行描述，如图一。详细的操作步骤参见相关文献[1]。
  
  使用FPA方法估算项目规模时，首先对于要完成的系统功能进行分解，正如采用工作分解结构的方式对于项目的任务分解一样。不同的是，因为FPA是一个标准方法，所以对于分解的最细粒度有一致的规定[1]。首先根据功能的层次将应用分解为子系统，在子系统的基础上进一步拆分为功能模块，功能模块是否需要再行拆分则要考虑是否已经满足了功能点的细分要求。拆分后的功能参见表一。然后计算所有功能点的总和，对功能点求和：
  
  然后再计算系统特征值（General System Characteristic）和调整系数（Value Adjusted Factor）：　
  
  最终，通过计算得到功能点的值（Function Point Counting）
  
  绝大多数的政府客户和行业客户在发包软件项目时，会签订固定总价合同，这是因为客户的预算往往基于年度预算。如果对于硬件类型的项目，当发生设备增加，客户会追加相应的费用。但是对于软件项目的变更因为缺乏与成本的直接关联关系，所以很难说服客户的上级（客户项目预算批准人）追加相应的成本。所以如果在项目执行的过程中发生客户需求变更时（通常是需求增加与修改）会给开发方带来额外的附加成本。所以应在发包时就充分考虑此因素。试想，开发方在项目做到一半时就发现是个亏损的项目，会对项目的最终结果造成什么样的影响呢？
  
  所以在得到FPC后，还要再考虑一个能够反映需求膨胀因素的调整系数。综合客户的组织特征、业务的稳定性与连续性、最终用户的类型、技术解决方案以及项目周期等方面的影响，在示例项目中设定需求膨胀系数为......More↓↓↓