3

我正在考虑在分析开发软件的努力时使用的软件指标。当我考虑为面向对象的软件使用类似功能点的指标时,我遇到了一个有趣的挑战/问题。

考虑一个业务规则引擎。它是一个应用程序,由运行业务规则所需的组件组成,然后将业务规则或公司策略转换为业务规则引擎的配置代码。我的假设是,对于像业务规则引擎这样的应用程序,此配置代码也可能变得相当重要。但是,从实现的角度考虑它时,配置代码本质上是实例化 API 的一部分。

那么,首先,假设编写配置代码的工作量足够大以至于测量它是有意义的,我错了吗?

是否有人对可以测量配置代码的指标(或任何其他指标)之类的功能点有所了解?

4

3 回答 3

1

衡量生成“配置代码”的工作量绝对是有意义的。根据您的应用程序,配置代码甚至可能是大部分工作。

我不知道任何专门为配置代码设计的指标。已经存在许多配置语言,任何人都可以创建新的。您可能应该看到您的配置语言与流行的编程语言有多少相似之处,并采用适用于该编程语言的指标。

于 2011-07-09T03:33:07.323 回答
1

调用 BR 代码“配置”代码不会改变问题。(三条腿的狗叫什么?不管你怎么称呼它,它是一条三条腿的狗)。

忽略相当大的炒作,业务规则引擎只是看起来很有趣的编程语言(通常与系统的“非业务规则部分”具有复杂的接口,而 BR 的东西是无法做到的)。从这个角度来看,BR 的编程与其他语言并没有太大的不同,尤其是如果您购买了功能点模型(仅仅因为您有一个 BR 引擎不会让您停止编写代码来生成报告!)。

BR 人通常试图做的是声称 BR 编程很便宜,因为你可以随心所欲地做。他们没有说的是编写 BR 很困难,因为不预先编写 BR 规则的行为本身就意味着您避免了先进行需求分析,理由是“您可以稍后再编写 BR”。并且无法保证您的 BR 系统或它可以访问的数据真的为您面临的问题做好了准备。(我真正讨厌的想法是“BR 使管理者能够理解……”你见过真正的 BR 规则吗?)

于 2011-07-09T03:38:42.250 回答
0

我完全同意 Ira 和 KC 的观点,这就是为什么我们只将标准脚本语言用于应用程序规则。您可以使用 V8 或 seamonkey 将 JavaScript 解释器嵌入到您的软件中,然后在您的业务规则代码上使用任何理解 JS 的估算器(如 ProjectCodeMeter)。

于 2011-09-25T09:32:46.593 回答