Node count versus SLOC

[bfieldi]

NI has suggested that for the purpose of node count/SLOC comparisons that 1 node = 1 line of code. What are some of you using in the workplace to provide metrics on your LabView code?

[crelf]

NI has suggested that for the purpose of node count/SLOC comparisons that 1 node = 1 line of code. What are some of you using in the workplace to provide metrics on your LabView code?

Where is that written? I've heard NI suggest that node count and SLOC are comparable, but certainly not 1 to 1.

[Grampa_of_Oliva_n_Eden]

but certainly not 1 to 1.

Agreed.

I think it was JPD who was using a signature that said that a "single VI is word a 1000 lines of code."

But then again, I'd love to be working under that type of project estimating (provided someone funds it).

I have been using "VI" s where the VI is waht can be developed in an hour.

I am curious abou this subject as well,

Ben

[crelf]

I'm writing a paper on LabVIEW code metrics at the moment, and although I'm nowhere near finished it, here's a snippet:

Traditionally, software source code is benchmarked by source lines of code (SLOC) - a simple method of determining a project's complexity and size by counting either the physical (every line of code in a project is counted) or logical (a weighted count is performed that gives varying scores depending on a line's importance) lines of text in the project's source code. Whilst an inexperienced programmer with a verbose programming style may create a portion of source code with a particular SLOC, a more experienced programmer may create a portion of code with exactly the same functionality, but with a much smaller SLOC. The physical SLOC metric will vary largely when these functionally identical code portions are compared, whereas an accurate logical SLOC process will return their metrics are equal.

LabVIEW source code is purely graphical - it is therefore impossible to count SLOC, and hence use a SLOC approach to validate the size and/or effort estimate of a project using the LabVIEW development environment. A comparable metric must be defined, and a tool created to realize its measurement.

Nodes

One existing method of measuring LabVIEW source code size is the native VI Metrics Tool, which counts and reports the number of nodes within a project. A node is an individual object on a LabVIEW block diagram (i.e. source code), including, but not limited to :

• functions
  
• subVIs
  
• structures
  
• front panel object terminals
  
• constants
  
• global and local variables
  
• property nodes
  

Using the VI Metrics Tool is akin to a physical SLOC count

[Grampa_of_Oliva_n_Eden]

I'm writing a paper on LabVIEW code metrics at the moment, and although I'm nowhere near finished it, here's a snippet:

I'm really excited about the GOB metric as it's the closest thing to a logical SLOC that I've seen in the LabVIEW world.

Nice Chris!

Leave it to VIE to do this first...

Ben

[crelf]

Nice Chris!

Thanks Ben - we've actually been researching it for a number of years and have several large project clients using it. I'm really hoping for its acceptance to grow even further as the userbase increases.

Leave it to VIE...

That's why I flew half way around the world to work here

[LAVA 1.0 Content]

the the total VI count, GOBs count, and actual/estimated hours for the complete project

Now I can actually measure the the gobs(1) of LabVIEW code I've written over the years!

[Denise]

NI has suggested that for the purpose of node count/SLOC comparisons that 1 node = 1 line of code. What are some of you using in the workplace to provide metrics on your LabView code?

I am bfieldi co-worker, she is out on vacation this week. Here is the link (from National Instruments web-site):

http://zone.ni.com/devzone%5Cconceptd.nsf/...de=dz00000_us#3

Look under "Converting LabVIEW Nodes to SLOC"

[crelf]

Although NI reports "...roughly a one-to-one relationship between LabVIEW nodes and SLOC..." (and in bold too!), they then go on to list why it's not necesarily an accurate comparison. Node count is more about quantity, not complexity, hence it's relation to physical SLOC and not logical SLOC - there's usually a big difference.

[Denise]

Although NI reports "...roughly a one-to-one relationship between LabVIEW nodes and SLOC..." (and in bold too!), they then go on to list why it's not necesarily an accurate comparison. Node count is more about quantity, not complexity, hence it's relation to physical SLOC and not logical SLOC - there's usually a big difference.

I understand what you are saying about "physical" vs "logical", but our company (a defense contractor) must use a certain tool and that tool must have SLOC, so we are stuck trying to figure out the "physical" and put in factors that may try to make the comparisons accurate. The tool requires things like "Do you have experts working on the project or novices" and "Have you used the same hardware in the past" and "Are your development tools highly automated"...

I am going to try and get our Cost Engineer involved in this discussion if it gets interesting, she has lots more insight than I do about our tool.

-

[crelf]

...but our company (a defense contractor) must use a certain tool and that tool must have SLOC, so we are stuck trying to figure out the "physical" and put in factors that may try to make the comparisons accurate....

We've done the work for you: that's exactly what a GOB is. We have also done studies with several projects related to defense-related software metrics, including the LabVIEW/SLOC comparison, amongst others. Please feel free to send a message to me directly and I can have one of our experts contact you to talk through your available options.

[Grampa_of_Oliva_n_Eden]

We've done the work for you: that's exactly what a GOB is. We have also done studies with several projects related to defense-related software metrics, including the LabVIEW/SLOC comparison, amongst others. Please feel free to send a message to me directly and I can have one of our experts contact you to talk through your available options.

We can count on you to keep us updated on the results of that off-line conversation, can't we?

Ben

[crelf]

We can count on you to keep us updated on the results of that off-line conversation, can't we?

Ben

That depends on where it goes and whether the discussions are confidential If you'd like someone to talk to you directly about the SLOC and GOBs metrics, drop me a PM and I'll put you in touch with the right people...