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

Question

我在思考用于分析软件开发工作量的软件度量标准。当我在考虑用于面向对象软件的功能点类似的度量标准时，我遇到了一个有趣的挑战/问题。

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

那么，首先，我是否错误地认为编写配置代码的工作量足够大，以至于测量它是有意义的呢？

有人知道能够测量配置代码的功能点类似的度量标准（或任何其他度量标准）吗？

- spydadome

Answer 1

测量“配置代码”的生产力绝对是有意义的。根据您的应用程序，配置代码甚至可能占据了大部分工作量。

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

- kc2001

Answer 2

调用BR代码“配置”代码并不改变问题。(你怎么称呼一只三条腿的狗？无论你如何称呼它，它都是一只三条腿的狗。)

尽管被吹嘘得很大，业务规则引擎只是看起来有些奇怪的编程语言（通常具有复杂的界面，用于系统的“非业务规则部分”，而BR部分无法完成）。从这个角度来看，与其他语言相比，编写BR并没有太大区别，特别是如果您购买了功能点模型（仅仅因为您拥有BR引擎并不能让您免于编写生成报告的代码！）。

BR团队通常试图做的是声称BR编程很便宜，因为您可以在进行编码时同时完成。但他们没有说的是，BR编程很难，因为不预先编写BR规则的行为本身意味着您已经避免了首先进行需求分析的过程，“您可以稍后编写BR”。而且，您的BR系统或其访问的数据是否真正准备好应对所面临的问题也没有保证。（我真正厌恶的想法是“BR使得管理人员理解可能性更大...”您见过真正的BR规则吗？）

- Ira Baxter

---

从你的回答中，我得出结论：在编写BR时投入了相当大的努力，值得进行衡量。 - spydadome

是的，我认为如此。功能点仍然适用，但您必须在开始之前计算出FP估算。 - Ira Baxter

Answer 3

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

- Brian McKinley