2014年12月25日下午与26日下午，北京随济科技首席顾问曹济老师接受某软件中心的邀请，作了题为“引入软件功能点，走出CMMI边缘化窘境”的现场报告，该报告在该软件中心激起了强烈反响。因为该报告与CMMI密切相关，而国内软件行业关心CMMI的人数众多，现将根据现场录音整理的节选内容分三次发布，以供那些运行CMMI管理模型和的软件组织作参考之用。下面为第二部分内容。

专题二：引入软件功能点改造软件需求变更管理方法

软件需求变更管理是个大问题，如果不去控制软件需求，软件需求就会不断膨胀。怎么样控制软件需求膨胀呢？有多种方法，我们今天重点和大家谈一谈采用软件功能点方法如何辅助软件需求变更管理。大家先看一下下面的这个软件需求变更信息列表。

相信看完这个表之后，各位对于软件功能点方法如何辅助软件需求变更管理已经心中有数了。首先评估每个需求变更的功能点规模，然后根据历史数据推导每个变更对于工作量、工期、费用的影响，是不是一目了然？原来采用模块法评估为什么客户不接受？因为不透明啊。你说一个模块的工作量为20人天，客户说两人天就够了，他没有验证办法啊。现在采用功能点方法，客户自己单独评估和我们的结果也一样，那就没有话说了。还有一个问题，大家会关心通过这种方式客户会不会给项目真的追加费用吗？照我国软件行业的现状来看，比较难。那我们做这样的分析还有意义吗？有意义，万一客户良心发现，真的要给你加钱，你的依据是什么？这不就有依据了嘛！另外，这样的变更分析对于工作量分析还是有比较重要的参考意义，例如在开发组织内部需要分析变更工作量的累计信息，上面的表格就可派上大用场了。

其实软件功能点最大的特点在于它以透明客观的方式衡量出软件需求规模，因而在此基础上所进行的一系列其他的运算也就具备透明和客观的特点了。反观在CMMI体系中对于软件需求规模度量并无指定特殊的方法，这就给CMMI体系的有效性带来很大的隐患。如果我们在建筑行业中不是以“平米”这样的单位衡量建筑面积，代之以“步长面积”或者“房间数”来衡量建筑面积，会有什么样的结果？那就会产生无穷的争端。所以要保证CMMI体系的有效性，首先要保证基础度量信息的客观性和可信性，就目前来看，没有比软件功能点方法更为客观和可信的方式了，所以我说要用软件功能点方法改造CMMI体系，CMMI才能重新赢得开发人员和管理人员的信任。

问题在于软件功能点的优点如此明显，那为什么它并没有得到大范围的普及应用呢？我想大家在明天一定会提出相关的问题，到时我们再和大家一起分析吧。其实核心就一点，因为软件功能点方法用起来不是那么容易，怎么样不容易，明天再揭分晓。

专题三：应用软件功能点方法为软件需求分析工作提供形式化约束

（略）

专题四：在软件需求评审过程中引入软件功能点方法

（略）

专题五：应用软件功能点度量结果评价测试用例的充分性

（略）

各位下午好！我们接着昨天的话题，看看软件功能点还可以在哪些方面与我们的工作相结合，对现有的CMMI体系提供相应的支持。首先我们来回顾一下昨天和各位交流过的话题，昨天我们都讨论了哪些内容？各位对这些内容有无疑问或者也可以谈谈自己的感想？……，因为时间关系，我们先讨论这么多，我们专门在今天讲座的后半段安排了Q&A时间，到时我们在继续讨论吧。我们今天要和大家介绍另外三个专题的内容，分别是应用软件功能点方法评价软件组织的产出成果、如何建立基于软件功能点的度量体系以及统计控制方法在软件度量领域的局限性。

专题六：应用软件功能点方法评价软件组织产出成果

下面这个专可能会引起软件开发人员的兴趣，但我们中心的张主任、周总等管理层则一定对这个专题很关心。软件行业长期以来使用代码行表示软件系统的规模，例如5万行程序的应用、18万行的交易系统等，但前面和各位交流过，代码行的诸多缺点使得它越来越不能胜任度量软件应用规模这一重大任务。自然地，我们会转向软件功能点方法，如果用软件功能点来描述一个软件组织的产出，情形会有什么不同呢？

例如截止到2014年10月份为止，某股份制银行的软件系统应用规模总计为32万功能点，该组织所运行的18个业务系统其规模并不完全一致，最大的业务系统为11万功能点，而最简单的业务系统则只有1400个功能点。该组织计划在下个财年全新开发2000功能点的贵金属管理系统以及3200功能点的抵押贷款系统；在现有的业务系统基础之上，新增6000个功能点、修改4000功能点（修改后对应的功能规模为4500功能点）、删除过时的功能600个功能点，根据上述的信息，在新的财年内，该组织软件系统的总产出规模为5200+6000+4500+600=16300功能点。要支持这么多产出，那就意味着需要相应人员和资金的投入。假如自有开发人员为90人，此处的90人140团队折合后的结果，因为140人的团队还需要承担维护等开发工作以外的其他内容；假如该组织人员的年产出功能点为100功能点；所以自由开发人员能够承担的工作任务规模大约为9000功能点，那么额外的7300功能点怎么办？一种方法是根据业务需求的必要性和紧迫性，将排序靠后的7300功能点排除出去，但这个比例挺高的，估计业务部门不答应。

第二种方法大家都能想得到，是什么？对喽，通过外包方式完成这7300功能点，又假如每个功能点的外包费用为1500元/人天，所需的外包费用大约为10，950，000元。如果考虑到预算约束，总部对于明年外包预算的费用上限设置为9,000，000元，此时再来考虑不足的95万元费用如何平衡，该费用对应的功能点数量为633功能点。一种方式是与业务部门协商，将那些优先级别较低的项目排除在外，但累计排除的功能点数量不超过630功能点；还有一种方式是与那些承担开发任务较多的供应商进行协商，对其所完成的部分开发工作不予付费，以后再对其进行相应的补偿。

通过我上面的介绍，大家有什么感受吗？应用软件功能点方法可以在我们软件组织的开发任务、人员规模、预算规模之间建立透明、客观的管理和平衡机制，这一点对软件组织的战略资源管理尤其重要。

专题七：如何建立基于软件功能点的度量体系

（略）

专题八：统计控制方法在软件度量领域的局限性

（略）