测量软件配置代码的工作量/度量

Question

我在考虑在分析开发一款软件的过程中使用的软件度量。当我考虑在面向对象的软件中使用类似功能点的度量时，我遇到了一个有趣的挑战/问题。

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

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

有谁知道像度量(或其他度量)这样的功能点可以度量配置代码的线索吗？

Answer 1

衡量产生“配置代码”的努力绝对是有意义的。根据您的应用程序的不同，配置代码甚至可能是工作的主要部分。

我不知道有什么指标是专门为配置代码设计的。已经存在许多配置语言，任何人都可以创建一种新的。您可能应该了解您的配置语言与流行的编程语言有多相似，并调整适用于该编程语言的度量标准。

Answer 2

调用BR代码“配置”代码并不能改变问题。(你怎么称呼三条腿的狗？不管你叫它什么，它是一只有三条腿的狗)。

忽略了大量的炒作，业务规则引擎只是看起来很滑稽的编程语言(通常具有到系统的“非业务规则部分”的复杂接口，而BR的东西很难做到)。从这个角度来看，编程BR与其他语言没有太大不同，特别是如果您购买了功能点模型(仅仅因为您有BR引擎，就不会让您不必编写代码来生成报告！)。

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

Answer 3

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