经过我们培训的学员们在实际的功能规模度量中，遇到一些具体的“疑难”问题，往往无从下手。 

  最近，我在国外杂志上看到了一篇开拓思路的文章，是一位巴西的功能点分析（FPA）专家写的。在这里分享给大家，应该有所帮助。

  先介绍一下背景：在巴西，政府的软件采购必须要进行软件规模的度量，以此来驱动软件的价格、生产率和质量的度量。其中大部分都是在使用“功能点”的方法。

  其中，巴西的国家开发银行（也简称：国开行）近些年在应用一些“新兴技术”，例如：ESB以及BPM。

  对于这些新兴的技术，如何进行功能规模度量呢？

  答案就是——跳出盒子。即：做一些“规则定制”。

当然，这个跳也不能乱跳。

  在整个度量的过程中，肯定还是要遵守IPFUG的CPM（计数操作手册），在这个基础上，再进行规则的定制。但总的前提是，这个扩展、定制，不要破坏整个理论体系。

  作为一种国际标准，功能点分析的理论逻辑是自恰、他恰和续恰的。这是一门科学体系的最重要特点。

第一步，找到“用户”。

  因为功能点方法，一定是要站在“用户视角”。 

  ESB和BPM都是中间件，在两个系统之间发挥着胶水（glue）的作用；这个中间件本身是一个应用系统，而其他的系统就是这个系统的用户（user）。

  第二步，划分边界。

  根据第一步，就可以推导出系统边界。EBS和BPM的边界就是与其它系统的“隔离”，只是限制于“中间件”的功能本身。

  第三步，识别数据功能。

  在ESB中，数据穿越多个应用，并在服务层校验，但是不存储。所以一般是没有ILF。但是，也许会有一个log文件（日志文件），可以被识别为ILF。

  在BPM中，可以识别出有两个ILF，流程的实例——存储着此流程当前的状态；流程配置——存储着用户最新的配置信息。

  要反复强调的就是，这个“流程”的识别，要站在用户角度，而不是技术实现角度。

  第四步，识别事务功能。

  在ESB中，因为没有数据功能，所以就不能识别EI。但是，如果识别了日志文件，相应的EI就可以识别了。

  在BPM中，可以识别出两个EI，分别针对两个ILF。还可以识别一个EQ，给其他系统传递信息。

  此外，巴西国开行还定制了“总则”：

  （1）中间件的规模不要与应用的规模混淆；

  （2）中间件的规模，只能计数一次；即使是被不同的应用所使用。

  后记——不要随便笑话巴西。

  也许有人看到巴西专家将ESB和BPM说成是“新兴技术”，又要笑话了。就像我们很多人笑话他们的奥运会一样。

  但是，就软件度量的规范性而言，同样是所谓的“金砖五国”，一些其他国家的推进力度是不如巴西政府的。

（www.parawork.com）

跳出盒子的软件度量