Defect Density

[karthik]

Hello Lava's,

In text based programming languages, Defect Density is generally measured as number of Major Defects found in thousand lines of code(i.e.Defect Density (at any stage) <= 1 Major/KLOC ).Is there a yard stick to measure Defect Density in LabVIEW?Can anybody please through some light on this standards? Karthik SP

[Ton Plomp]

QUOTE(karthik @ Aug 8 2007, 07:21 AM)

Hello Lava's,

In text based programming languages, Defect Density is generally measured as number of Major Defects found in thousand lines of code(i.e.Defect Density (at any stage) <= 1 Major/KLOC ).Is there a yard stick to measure Defect Density in LabVIEW?Can anybody please through some light on this standards? Karthik SP

This is:

A) a cross post it is considered good manner to inform people of cross-posting

B) Posted in the Hardware forum while it is a software question

I don't have a good answer but I think VIEngineering of Crelf might have some good ideas they have some toolkits for KLOC

Ton

[karthik]

Hello LAVA's,

In text based programming languages, Defect Density is generally measured as number of Major Defects found in thousand lines of code(i.e.Defect Density (at any stage) <= 1 Major/KLOC ).Is there a yard stick to measure Defect Density in LabVIEW?Can anybody please through some light on this standards? Karthik SP

Note : I have also poste same question in NI Discussion Forum and by mistake I have posted it in Hardware insted of LabVIEW General in LAVA forum.I am sorry for the same.

[silmaril]

ZITAT(karthik @ Aug 8 2007, 11:14 AM)

In text based programming languages, Defect Density is generally measured as number of Major Defects found in thousand lines of code(i.e.Defect Density (at any stage) <= 1 Major/KLOC ).Is there a yard stick to measure Defect Density in LabVIEW?Can anybody please through some light on this standards? Karthik SP

I think for all those "measurements", lines of source code can easily be replace by number of nodes in LabVIEW.

Just open this dialog: Tools >> Profile >> VI metrics

and see if that helps you further.

The more interesting question is: How do you define a "Major Defect"?

[Sergey Kolbunov]

QUOTE(silmaril @ Aug 8 2007, 09:24 AM)

I think for all those "measurements", lines of source code can easily be replace by number of nodes in LabVIEW.

Just open this dialog: Tools >> Profile >> VI metrics

and see if that helps you further.

The more interesting question is: How do you define a "Major Defect"?

Oh, this is a philosophic question.

I suppose that "Major Defect" is a defect what affects an application functionality or interface the way it is undesirable to a customer.

[Louis Manfredi]

QUOTE(skof @ Aug 9 2007, 09:44 AM)

Oh, this is a philosophic question.

I suppose that "Major Defect" is a defect what affects an application functionality or interface the way it is undesirable to a customer.

But in that case, what is a minor defect?

Best Regards, Louis

[Gary Rubin]

QUOTE(skof @ Aug 9 2007, 09:44 AM)

Oh, this is a philosophic question.

I suppose that "Major Defect" is a defect what affects an application functionality or interface the way it is undesirable to a customer.

Maybe this a reflection of my ignorance of Software Engineering principles, but isn't that more a function of the programmer than the programming environment?

Edit: Nevermind - misconstrued the original post; he's not asking what the Defect Density is in Labview code, but how to measure it.

[Sergey Kolbunov]

QUOTE(Louis Manfredi @ Aug 9 2007, 08:52 AM)

But in that case, what is a minor defect?

Best Regards, Louis

Minor defect is a kind of defect that customer can live with. Another name for minor defect is enhancement. Again, I'm talking only about an interface and functionality visible by the customer, not about a coding style or architecture. Problems in these areas are Internal Defects and Enhancements with their own criteria of "majority".

[Grampa_of_Oliva_n_Eden]

QUOTE(skof @ Aug 9 2007, 10:40 AM)

Minor defect is a kind of defect that customer can live with. Another name for minor defect is enhancement. Again, I'm talking only about an interface and functionality visible by the customer, not about a coding style or architecture. Problems in these areas are Internal Defects and Enhancements with their own criteria of "majority".

CRELF invented GOBs if that helps.

http://forums.lavag.org/Node-count-versus-SLOC-t3632.html&pid=14612&mode=threaded#entry14612' target="_blank">http://forums.lavag.org/Node-count-versus-...aded#entry14612

Ben

[Sergey Kolbunov]

QUOTE(Gary Rubin @ Aug 9 2007, 09:14 AM)

Maybe this a reflection of my ignorance of Software Engineering principles, but isn't that more a function of the programmer than the programming environment?

Edit: Nevermind - misconstrued the original post; he's not asking what the Defect Density is in Labview code, but how to measure it.

Sure, this is a function of the development and testing teams to define what are Major Defects. Programming environment can just give you a "number of nodes" value to calculate Defect Density.

[crelf]

QUOTE(skof @ Aug 9 2007, 11:44 PM)

I suppose that "Major Defect" is a defect what affects an application functionality or interface the way it is undesirable to a customer.

I'd disagree with that one - I think what you've described isn't a major defect - you're use of the word "undesirable" means IMHO that it's not quite what we wanted, but it'll do. To me, the word "defect" isn't the one we should be concentrating one - it should be "requirement non-compliance". A defect is completely subjective, whereas a requirement compliance is traceable.

QUOTE(Ben @ Aug 10 2007, 12:43 AM)

CRELF invented GOBs if that helps.

I'd love to claim that one as my own, but it was a colaborative effort between several engineers at VI Engineering, Inc, lead by David Hoadley. I've since taken over from David, so I'm working on the case studies to improve and validate GOBs (amongst other metrics) and I'm the lead VISTA Tools Architect (no, not the VISTA that you're thinking of ), but I didn't invent it.

QUOTE(skof @ Aug 10 2007, 12:52 AM)

Sure, this is a function of the development and testing teams to define what are Major Defects. Programming environment can just give you a "number of nodes" value to calculate Defect Density.

It can also give you cyclomatic complexity, which can be used as an indicator to code completeness, as well as (as the name suggests) how complex a code chunk is - and this can often be translated to the highest probablity of defects (I'm speaking very loosley here).

[Sergey Kolbunov]

QUOTE(crelf @ Aug 9 2007, 10:04 AM)

I'd disagree with that one - I think what you've described isn't a major defect - you're use of the word "undesirable" means IMHO that it's not quite what we wanted, but it'll do. To me, the word "defect" isn't the one we should be concentrating one - it should be "requirement non-compliance". A defect is completely subjective, whereas a requirement compliance is traceable.

Heh, I agree that everithing should start from requrements and a requirement compliance is traceble while defect is subjective. You are right, "requirement non-compliance" metric should only be used for the defect density calculations. Then a "Major Defects" term in karthik post is not accurate and should be replaced by "Defects" aka "requirement non-compliances".

But I told about a measure of "majority" of a defect. Saying "undesirable to a customer" I assume that requirements were developed by the customer specifications. How can you measure "majority" of "requirement non-compliance"? It can comply or not comply. In other word, what defect is critical and must be fixed immediately and what one is not critical and can be postponed or deffered? In my experience I don't remember any complex project where ALL found defects have been fixed in the next build.