Eclectic Videos!


My TestPartner

Lines Of Code - KLOC - Issues in Estimation

Posted on 11/26/2009 07:29:00 PM by Abhijeet Bhagat

Lines Of Code - KLOC - Issues in Estimation

We have seen that KLOC being used as a measure to generate good number of Metrics Like Defect Density.

Since the measure is such a popular measure hence I wanted to understand if everyone in the industry has a common definition of LOC or does the definition change with the frame of reference. Astonishingly i found that different people or different organistaions have different meaning  / interpretation fo Lines of Code and this necessarily means  -  Different perspectives, Different Judgements, and less computation.

Less Computation means Lot of gut feel and gut feel means you are introducing errors into the estimate calculations and what a disaster would it be if the tolerence of the error is as good as +-30%.

Do you get me where i am coming from? We have experienced this in our practical life as a testers and quality engineers. If we cannot estimate Size how can the relative metrics be relied upon? that too at a range of +-30% tolerance?

Well then, What could give me a correct measure of size of my module, component, software!!! haan?
I researched  and researched till i came across IFPUG{International Function Point Users Group}  FAQs

Let me quote IFPUG verbatim as below :
  • Why shouldn’t I use lines of code?
  • Lines of code tend to reward profligate design and penalize concise design.
  • There is no industry standards (ISO or otherwise) for lines of code.
  • Lines of code cannot be used for normalizing across platform, language or by organization.
  • Some 4GL don’t even use lines of code.
  • Lines of code can be positively misleading – refer to Capers Jones Productivity Paradox.
  • What about backfiring?
  • Backfiring is based on lines of code, so you run into the same difficulties as using lines of code.
  • It can be used cautiously on legacy systems without much prospect of further work.
  • Backfiring could be useful if accuracy is not an issue. "


 Owing to the ambiguity of the definition we need a definite and computational model to measure the size and not the judgemental measure. I found the answer to be FPs or Function Points.
Function Points and Use Case points are the most effective means to measure the size of something intangible like a piece of software.
Since FPA[Function Point Analysis] relies on fundamentals like breaking the software to its elementary processes and elementary data transactions and then start counting /computing above its more COMPUTATIONAL in nature.
Discussing the entire FPA is beyond the scope of this article though i would like to leave some Start points to the people for whom the above paragraph did not made anysense.
Pointers :
  1. To measure something we need  more computation and not judgement.
  2. Judgement is error prone.
  3. FPA breaks any software into very elementary process and Data Transactions.
    1. For any software there are only five of the following happening...
      1. Input
      2. Output
      3. Query( Different From Output -  i.e here the data is not altered you may call this as a simple SQL Query just to understand )
      4. Internal Data Files modification
      5. External Data Files modification
    2. If we know that any software is mere a compbination of above 5 processes then break down each peice of software in above manner and calculate the FPs
    3. Please note that FP is just like any other unit for e.g. Hours
    4. Hence we can talk of SIZE of software in terms of number of function points
    5. Apart for the Extra bias added to the Numeber of Function Points Function Points is the best measue to calculate the size.
Nonetheless  FPA is very detailed procedure and should be applied only to projects of large size and not to small POC kinds of projects of duration of 1 week to 15 Days.

FPA being very detailed in nature demands time and resources for estimation so for quick estimations our good'ol KLOC seems to be okay.

What to use when is left to users's need or accuracy!.

No Response to "Lines Of Code - KLOC - Issues in Estimation"

Leave A Reply

free hit counter code
Visitors Count