Topic: Souce code Estimation

Message

The notion of estimating source code size can mean lots of different things. For example, you will hear of KLOC which is an application size estimate expressed in thousands of lines of source code. Or you will hear of function points. Let us talk about those for a second.

The most commonly used metric for cost estimation is the number of lines of source code (LOC) in the finished application. Size estimation may involve estimation by something like estimation by ranking the sizes of application components and using a known reference component to estimate the component size, as just one example. One thing to realize, in that context, is that code size estimates are uncertain (generally) because they depend on hardware and software choices, use of a commercial database management system, use of third party add-on solutions, etc. So an alternative was designed: function points. Functions points are more related to the functionality of the application rather than to its (estimated) size.

Function points are usually computed by counting the external inputs and outputs, the user interactions, the external interfaces, and any files that are used by the application overall. Each of these is then individually assessed for complexity and given a weighting value which varies from 3 (for, say, extremely simple external inputs) to 15 (for, say, complex internal files or highly structured algorithms). (Some organizations use different measure scales.) The function point count is computed by multiplying each raw count by the estimated weight and summing all values, then multiplied by the project complexity factors which consider the overall complexity of the project according to a range of factors such as the degree of distributed processing, the amount of reuse, the overall performance, the reliance on closed third-party tools, etc.

Beyond that, there are a lot of metrics you can consider in relation to estimation techniques for source code. For example:

Lines of Code (LOC):

This is the simplest. This is strict lines of code within the application.

Effective Lines of Code (ELOC):

This is more a paring down of all lines of code within an application. Certain characters on a given line may not create a line of code which is representative of actual work performed by the programmer and thus would skew cost and time estimates. So these are effective lines of code from the application point of view.

Logical Lines of Code (LLOC):

Logical lines of code represent a measure for those lines of code which form strict code statements. These are generally the base statements of the language. You have to be careful with this one in looping structures or conditional branches.

Class Count (CC):

The number of classes in a system indicates the degree of object orientation of the application. You can actually use this measure to help determine the average lines of code per class, the maximum LOC per class, and the minimum LOC per class.

Cyclomatic Complexity:

Cyclomatic complexity is the degree of logical branching within a function. Logical branching occurs when a "while", "for", "if", "case" and "goto" keywords appear within the function. Cyclomatic complexity is the count of these constructs.

There are many others and some are combinations of basic metrics. For example, you might have Average LOC per Function Point.

The basis behind this particular example, just to give you a feel for it, is that the average LOC per function indicates how the code meets a given standard for code per function in general. Example: an accepted industry standard of "200 LOC/function" might be desired by your organization as the average LOC per function. So, functions that have a larger number of lines of code per function might be more difficult to maintain or they might indicate that the function could be broken into multiple functions, thereby giving credence to the idea that a function should, in general, be a singularly discrete entity in terms of actions performed. This is just a general example of how organizations might use this kind of metric.

Also, sometimes non-functional lines are broken out of the source code via metrics like comment line percent metrics. Actually, this can feed into the LLOC that I mentioned earlier. Generally the comment percent is given by:

Comment Percent = (Comment Line Count / Logical Line Count) * 100

And then the LLOC is given by:

LLOC = LOC + Comment Lines + Blank Lines.

You can also tie this into white space if you really want to do strict estimation by the following formula:

White Space% = (Number of spaces / Number of spaces and characters) * 100

These can all then go towards refinind your estimates for KLOC or ELOC, for example.

Edited by Anita_buie - 05May2007 at 4:49am

Author	Message
Anita_buie Newbie Joined: 03May2007 Online Status: Offline Posts: 1	Topic: Souce code Estimation Posted: 05May2007 at 4:48am
	The notion of estimating source code size can mean lots of different things. For example, you will hear of KLOC which is an application size estimate expressed in thousands of lines of source code. Or you will hear of function points. Let us talk about those for a second. The most commonly used metric for cost estimation is the number of lines of source code (LOC) in the finished application. Size estimation may involve estimation by something like estimation by ranking the sizes of application components and using a known reference component to estimate the component size, as just one example. One thing to realize, in that context, is that code size estimates are uncertain (generally) because they depend on hardware and software choices, use of a commercial database management system, use of third party add-on solutions, etc. So an alternative was designed: function points. Functions points are more related to the functionality of the application rather than to its (estimated) size. Function points are usually computed by counting the external inputs and outputs, the user interactions, the external interfaces, and any files that are used by the application overall. Each of these is then individually assessed for complexity and given a weighting value which varies from 3 (for, say, extremely simple external inputs) to 15 (for, say, complex internal files or highly structured algorithms). (Some organizations use different measure scales.) The function point count is computed by multiplying each raw count by the estimated weight and summing all values, then multiplied by the project complexity factors which consider the overall complexity of the project according to a range of factors such as the degree of distributed processing, the amount of reuse, the overall performance, the reliance on closed third-party tools, etc. Beyond that, there are a lot of metrics you can consider in relation to estimation techniques for source code. For example: Lines of Code (LOC): This is the simplest. This is strict lines of code within the application. Effective Lines of Code (ELOC): This is more a paring down of all lines of code within an application. Certain characters on a given line may not create a line of code which is representative of actual work performed by the programmer and thus would skew cost and time estimates. So these are effective lines of code from the application point of view. Logical Lines of Code (LLOC): Logical lines of code represent a measure for those lines of code which form strict code statements. These are generally the base statements of the language. You have to be careful with this one in looping structures or conditional branches. Class Count (CC): The number of classes in a system indicates the degree of object orientation of the application. You can actually use this measure to help determine the average lines of code per class, the maximum LOC per class, and the minimum LOC per class. Cyclomatic Complexity: Cyclomatic complexity is the degree of logical branching within a function. Logical branching occurs when a "while", "for", "if", "case" and "goto" keywords appear within the function. Cyclomatic complexity is the count of these constructs. There are many others and some are combinations of basic metrics. For example, you might have Average LOC per Function Point. The basis behind this particular example, just to give you a feel for it, is that the average LOC per function indicates how the code meets a given standard for code per function in general. Example: an accepted industry standard of "200 LOC/function" might be desired by your organization as the average LOC per function. So, functions that have a larger number of lines of code per function might be more difficult to maintain or they might indicate that the function could be broken into multiple functions, thereby giving credence to the idea that a function should, in general, be a singularly discrete entity in terms of actions performed. This is just a general example of how organizations might use this kind of metric. Also, sometimes non-functional lines are broken out of the source code via metrics like comment line percent metrics. Actually, this can feed into the LLOC that I mentioned earlier. Generally the comment percent is given by: Comment Percent = (Comment Line Count / Logical Line Count) * 100 And then the LLOC is given by: LLOC = LOC + Comment Lines + Blank Lines. You can also tie this into white space if you really want to do strict estimation by the following formula: White Space% = (Number of spaces / Number of spaces and characters) * 100 These can all then go towards refinind your estimates for KLOC or ELOC, for example. Edited by Anita_buie - 05May2007 at 4:49am Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Quality Assurance @ OneStopTesting : Estimation and Planning