我正在考虑在分析开发软件的工作量时使用的软件指标。当我考虑为面向对象软件使用类似功能点的指标时，我遇到了一个有趣的挑战/问题。
考虑一个业务规则引擎。它是一个应用程序，由运行业务规则所需的组件组成，然后将业务规则或公司策略转换为业务规则引擎的配置代码。我的假设是，对于像业务规则引擎这样的应用程序，此配置代码也可能变得相当重要。但是，从实现的角度来看，配置代码本质上是对 API 的一部分进行实例化。
那么，首先，我假设编写配置代码的工作量足够大以至于衡量它是有意义的，这是不是错了？
有没有人知道可以测量配置代码的功能点（如指标（或任何其他指标））？
【问题讨论】：
标签： metrics measurement function-points
衡量生成“配置代码”的工作量绝对是有意义的。根据您的应用程序，配置代码甚至可能是大部分工作。
我不知道任何专门为配置代码设计的指标。已经存在许多配置语言，任何人都可以创建新的。您可能应该看到您的配置语言与流行的编程语言有多少相似之处，并采用适用于该编程语言的指标。
【讨论】：
调用 BR 代码“配置”代码不会改变问题。 （3条腿的狗叫什么？不管叫什么，都是3条腿的狗）。
忽略相当大的炒作，业务规则引擎只是看起来很有趣的编程语言（通常与系统的“非业务规则部分”具有复杂的接口，而 BR 的东西是无法做到的）。从这个角度来看，BR 的编程与其他语言并没有太大的不同，尤其是如果您购买了功能点模型（仅仅因为您有一个 BR 引擎不会让您停止编写代码来生成报告！）。
BR 人通常试图做的是声称 BR 编程很便宜，因为您可以随时进行。他们没有说的是编写 BR 很困难，因为不预先编写 BR 规则的行为本身就意味着您避免了先进行需求分析，理由是“您可以稍后再编写 BR”。并且无法保证您的 BR 系统或它可以访问的数据真的为您面临的问题做好了准备。 （我真正讨厌的想法是“BR 让管理者能够理解……”你见过真正的 BR 规则吗？）
【讨论】：
我完全同意 Ira 和 KC 的观点，这就是我们仅将标准脚本语言用于应用程序内规则的原因。您可以使用 V8 或 seamonkey 将 JavaScript 解释器嵌入到您的软件中，然后在您的业务规则代码上使用任何理解 JS 的估算器（如 ProjectCodeMeter）。
【讨论】：