Cell Phone Software Forum
| View previous topic :: View next topic |
| Author |
Message |
Adam Sandler
Guest
|
 Posted: Mon May 21, 2007 9:22 pm Post subject: Object Oriented Metrics |
 |
|
Hello,
The pointy-haired boss is asking for source lines of code metrics on
our object oriented project. I've tried to explain that SLOC is
metric based upon functional decomposition and therefore not relevant
to object-oriented code.
What is some more ammunition I could present to keep this guy from
counting lines of code the classes?
Thanks! |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
xpyttl
Guest
|
| Posted: Mon May 21, 2007 10:25 pm Post subject: Re: Object Oriented Metrics |
|
|
SLOC is actualy a pretty good metric, if easily misused. Over a large
enough sample, SLOC is pretty well related to functionality, and to cost.
Also, there is a lot of data in the literature and through various services
relating SLOC to cost, at various levels of competence of an organization.
As long as he is looking at the larger picture, SLOC is an important metric
for the pointy-hair. There are other metrics that might be better, but few
are as cheap to provide as SLOC. Certainly, when the scope is narrow, SLOC
can be very misleading. But over a large enough code base, it is an
extremely useful metric. I might go so far as to suggest that any software
manager that doesn't understand the size of the code base he is managing is
incompetent.
Conversely, if I were a boss, and faced with an organization that strongly
resisted providing meaningful metrics, I would immediately replace that
group with someone who could prove to me that they were doing the job at
least as well as the nearest outsource supplier.
...
"Adam Sandler" <corn29@excite.com> wrote in message
news:1179768130.192055.132160@x35g2000prf.googlegroups.com...
| Quote: |
Hello,
The pointy-haired boss is asking for source lines of code metrics on
our object oriented project. I've tried to explain that SLOC is
metric based upon functional decomposition and therefore not relevant
to object-oriented code.
What is some more ammunition I could present to keep this guy from
counting lines of code the classes?
Thanks!
|
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wayne Woodruff
Guest
|
| Posted: Tue May 22, 2007 2:18 pm Post subject: Re: Object Oriented Metrics |
|
|
| Quote: |
Hello,
The pointy-haired boss is asking for source lines of code metrics on
our object oriented project. I've tried to explain that SLOC is
metric based upon functional decomposition and therefore not relevant
to object-oriented code.
What is some more ammunition I could present to keep this guy from
counting lines of code the classes?
Thanks!
|
Why not ask the PHB what he wants to use the SLOC metric for? If he
wants volume of code, it works fine. If he wants to compare
productivity of Dilbert and Dogbert, you are in trouble.
I find that engaging in a discussion to understand what the person is
trying to do will help define a measurement (and when dialoging with
the clueless, it may enlighten them to the pitfalls of their request).
You know, define the problem before the solution.
Once we have those discussions, I write an Operational Definition to
document the measurement and calculations (basically to document the
design of the metric). I will prototype the measurement while writing
the OD to flush out any implementation details. I get the customer to
inspect/review the OD and get their approval.
Once that is complete, I go into production and put the OD and any
scripts or tools under CM control. Modifications require a CR.
At the end, the customer is satisfied, I have a document that defines
the measurement and changes to the measurement are under CM control.
If only design and code were this simple ;-)
Wayne Woodruff
http://www.2zars.com |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Tue May 22, 2007 7:29 pm Post subject: Re: Object Oriented Metrics |
|
|
Responding to Sandler...
| Quote: |
The pointy-haired boss is asking for source lines of code metrics on
our object oriented project. I've tried to explain that SLOC is
metric based upon functional decomposition and therefore not relevant
to object-oriented code.
|
SLOC is a valid measure of code size. One just has to be careful about
interpreting it. Thus comparing C++ SLOC to PROLOG SLOC is probably
dangerous (though conversion factors exist if one is not too picky about
precision).
For a shop doing the same sort of software in the same 3GL, SLOC can be
very useful for things like monitoring productivity from project to
project. It is also much easier to work with for predictive models of
reliability. Counting SLOC is also easy to automate.
In the end, though, it depends on why one needs the size in the first
place. If one is interested in estimation, then function points are
probably be better measure because they measure requirements size rather
than code size so they are largely independent of the development
environment.
Also, in an OO shop object counts from an initial object blitz can be
very accurate estimators if the shop has collected good data on effort
in the past. [Where I worked before retiring they were so accurate that
we moved the preliminary object blitz into Project Planning. We
consistently got -5/+15% accuracy on 10+ ey projects.]
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei Polkhanov
Guest
|
| Posted: Wed May 23, 2007 12:19 am Post subject: Re: Object Oriented Metrics |
|
|
| Quote: |
What is some more ammunition I could present to keep this guy from
counting lines of code the classes?
|
Here is the list of OO metrics produced by one of tools I use time to
time - Understand for C++/Ada/.... I am taking the list from their
website with few changes: Of course this list is far from being
complete but here we have most common metrics and most of them
implemented in various commercial and free software metric tools.
Number of classes.
Maximum depth of class in inheritance tree. [DIT]
Number of other classes coupled to. [CBO, Coupling between Object
classes]
Number of immediate subclasses. [NOC, Number Of Children]
Number of instance methods. [NIM]
Number of local methods. [WMC, Weighted Methods per Class]
Number of methods, including inherited ones. [RFC, Response For Class]
Number of local friend methods. [NFM]
Number of local public methods. [NPM]
Number of local private methods. [NPRM]
Number of instance variables. [NIV]
Number of inputs used (parameters, global variables). [FANIN]
Number of immediate base classes. [IFANIN]
Number of outputs used (parameters, global variables). [FANOUT]
Lack of Cohesion - 100% minus average cohesion for class data members.
[LOCM or LCOM]
Counting lines of code (I presume it is not done by hands) requires
set of conventions
for normalization. For example code:
if (i != 0) {
printf("%d"", i);
}
and
if (i!=0) { printf("%d"", i); }
and
if (i!=0)
{
printf("%d"", i);
}
should all produce same LOC count.
There are set of complexity metrics which although important are not
strictly "OO" metrics because they can be applied to regular functions
as well as to member functions in classes:
Cyclomatic complexity.
Modified cyclomatic complexity.
Strict cyclomatic complexity.
Average cyclomatic complexity for all nested functions or methods.
Average modified cyclomatic complexity for all nested functions or
methods.
Average strict cyclomatic complexity for all nested functions or
methods.
Maximum cyclomatic complexity of all nested functions or methods.
Maximum modified cyclomatic complexity of all nested functions or
methods.
Maximum strict cyclomatic complexity of all nested functions or
methods.
Maximum nesting level of control constructs.
and size metrics:
Number of files.
Number of functions.
Number of statements. [STMT]
Number of declarative statements.
Number of executable statements.
Number of all lines. [NL]
Number of blank lines. [BLOC]
Number of lines containing source code. [LOC]
Number of lines containing declarative source code.
Number of lines containing executable source code.
Number of lines containing comment. [CLOC]
Number of comment lines divided by code lines, times 100.
Average number of lines for all nested functions or methods.
Average number of blank for all nested functions or methods.
Average number of lines containing source code for all nested
functions or methods.
Average number of lines containing comment for all nested functions or
methods.
This it helps,
Alexei. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Adam Sandler
Guest
|
| Posted: Wed May 23, 2007 6:32 am Post subject: Re: Object Oriented Metrics |
|
|
On May 22, 9:29 am, "H. S. Lahman" <h.lah...@verizon.net> wrote:
| Quote: |
SLOC is a valid measure of code size.
|
In an OO environment? Absolutely NOT. SLOC is based upon functional
decomposition... which does not lend itself to OO in the least. If
folks think it does, then they're coding a mix of procedural and OO
methodologies. Which leads to cohesion and encapsulation suffering
very quickly (and why SLOC increases; because the folks trying to
hammer the procedural peg square in the OO round hole have to go back
and either brute force or faith-based their way through the problems).
I'm worried about SLOC being used as a pure indicator of productivity.
If the classes and interfaces are well defined (often easier said than
done), any new work should not necessarily show a corresponding
increase in SLOC count. Folks who only deal in numbers would look at
a slight increase in count, versus the large one they were expecting,
and make an assumption the team isn't performing as well as it can. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wayne Woodruff
Guest
|
| Posted: Wed May 23, 2007 2:06 pm Post subject: Re: Object Oriented Metrics |
|
|
| Quote: |
SLOC is a valid measure of code size.
In an OO environment? Absolutely NOT. SLOC is based upon functional
decomposition... which does not lend itself to OO in the least. If
folks think it does, then they're coding a mix of procedural and OO
methodologies. Which leads to cohesion and encapsulation suffering
very quickly (and why SLOC increases; because the folks trying to
hammer the procedural peg square in the OO round hole have to go back
and either brute force or faith-based their way through the problems).
|
A wise man once asked me a very good question.
"What action should be taken as a consequence of a measurement?"
In other words, if you are measuring SLOC, what is actionable from
that measurement?
It gets back to my prior post. Understand why the boss wants SLOC
before you measure it. He may really want to know the average time it
takes for a kumquat to mature. He may want to know because one of his
buddies asked him. Who knows?
Before you shoot the measurement, understand what it is being used
for.
Wayne Woodruff
http://www.2zars.com |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Adam Sandler
Guest
|
| Posted: Wed May 23, 2007 5:27 pm Post subject: Re: Object Oriented Metrics |
|
|
On May 23, 4:06 am, Wayne Woodruff <w...@2zars.com> wrote:
| Quote: |
A wise man once asked me a very good question.
"What action should be taken as a consequence of a measurement?"
In other words, if you are measuring SLOC, what is actionable from
that measurement?
It gets back to my prior post. Understand why the boss wants SLOC
before you measure it. He may really want to know the average time it
takes for a kumquat to mature. He may want to know because one of his
buddies asked him. Who knows?
Before you shoot the measurement, understand what it is being used
for.
Wayne Woodruffhttp://www.2zars.com
|
I do understand what the measurement is being used for... that is why
I thought I'd ask the question I did to some in the community. It's
my opinion the boss needs a helping hand on this issue and I wanted to
get others' perspective. I'm shooting the measurement because I
understand what the boss wants to use the measurement for and it's not
a valid measurement for those purposes. The question in the very
first post was intended to talk about valid object oriented metrics,
not try to debate what the boss is thinking -- I've got the later part
covered on my end. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
223 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
