Menu
Is LOC correct parameter for project estimation?
there are so many scenarios where complexity takes much more time for a single line of code, other than LOC what could be the suggested parameter for project estimation?
As peoples are talking about functional point of program does it mean for use case related information?
i am trying to find out any solid base for full software developement estimation which can consist analysis, design, testcase preparation, and coding, please suggest?
520
“LOC is not a good productivity measure because it penalizes high-level languages: Assembler programmers produce five statements to a COBOL programmer's one.
Specifically, the source lines that are included in the count are the lines that contain executable statements, declarations, and/or compiler directives. Comments, and blank lines are excluded from the count.
As Lines of Code (LOC) only counts the volume of code, you can only use it to compare or estimate projects that use the same language and are coded using the same coding standards. Features : Variations such as “source lines of code”, are used to set out a codebase. LOC is frequently used in some kinds of arguments.
The four project parameters: time, cost, quantity and quality.
Steve McConnell in Rapid Development (Microsoft Press, 1996):
Because different programming languages produce such different bangs for a given number of lines of code, much of the software industry is moving toward a measure called "function points" to estimate program sizes. A function point is a synthetic measure of program size that is based on a weighted sum of the number of inputs, outputs, inquiries, and files. Function points are useful because they allow you to think about program size in a languageindependent way.
Google "Function Point" for more information.
176
Seeing as developers are likely to* spend most of their time trying to test changes, lines-of-code is never a good indicator of size of a problem.
Let's suppose you have an existing large application - changing a single line of code may seem trivial, but the test planning and execution could take weeks.
Likewise, adding a relatively large amount of code in a single limited-scope module which is easily testable might be only a few days.
* they should do, at least. If they're spending more time writing code than testing it, it is probably full of bugs. And I mean BEFORE it reaches your dedicated QA team.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
