首页 > 代码库 > 跳出盒子的软件度量

跳出盒子的软件度量

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

  最近,我在国外杂志上看到了一篇开拓思路的文章,是一位巴西的功能点分析(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)

 

跳出盒子的软件度量