Measuring effort / metrics for software configuration code

I was thinking about software metrics to use in the analysis of the effort to develop a piece of software. As I was thinking about using function-point like metrics for object-oriented software, I came across an interesting challenge / question.

Consider a bu开发者_StackOverflow社区siness rules engine. It is an application that consists of the necessary components to run the business rules, and then one has translate business rules or company policies into configuration code for the business rules engine. My assumption is that for applications like a business rules engine, this configuration code could also become quite substantial. However, when considering it from the point of view of the implementation, configuration code essentially instantiates parts of the API.

So, first, am I wrong in assuming that the effort for writing configuration code is substantial enough that measuring it makes sense?

Does anybody have a clue about a function-point like metric (or any other metric) that could measure configuration code?

It definitely makes sense to measure the effort to produce "configuration code". Depending on your application, the configuration code might even be the greater part of the effort.

I don't know of any metrics especially designed for configuration code. There are many configuration languages already existing, and anybody can create a new one. You should probably see how much your configuration language resembles popular programming languages, and adapt a metric that works with that programming language.

Calling BR code "configuration" code doesn't change the problem. (What do you call a dog with 3 legs? It doesn't matter what you call it, its a dog with 3 legs).

Ignoring the considerable hype, business rules engines are just funny-looking programming languages (usually with complicated interfaces to the "non-business rule part" of the system, which the BR stuff is uanble to do). From this point of view, programming BRs isn't a lot different than other langauges, especially if you buy the function-point model (just because you have a BR engine won't get you out of writing code to generate reports!).

What the BR guys typcially try to do is to claim BR programmming is cheap because you can do it as you go. What they don't say is that programming BR is hard, because the very act of not coding the BR rules up front means you've avoided doing the requirements analysis first, on the grounds "you can just code BR later". And there's no guarantee that your BR system or the data it has access to really is ready for the problem you face. (The idea I really detest is "BR makes it possible for managers to understand..." Have you seen real BR rules?)

I totally agree with Ira and KC, that's why we only use standard script languages for in-application rules. You can use V8 or seamonkey to embed a JavaScript interpreter into your software, then use any estimator which understands JS (like ProjectCodeMeter) on your business rules code.