GeeCON Prague 2014*
The moose likes Agile and Other Processes and the fly likes Metrics Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Metrics" Watch "Metrics" New topic
Author

Metrics

mo sayed
Ranch Hand

Joined: Jan 25, 2006
Posts: 88
Apologies if this is not the right forum.

What metrics are most suitable for measuring progress during
software development?

I'm aware that some people use SLOC (Source Lines of Code);
however this seems to be a very poor measure of progress.
regards,
Mo


<a href="http://moongrails.blogspot.com/" rel="nofollow">grails</a>
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
What part of "meaningless drivel" don't you understand?

Seriously, I like #tests passed as a quick and dirty measure.


There is no emoticon for what I am feeling!
Svend Rost
Ranch Hand

Joined: Oct 23, 2002
Posts: 904
Hmm.. Source Lines of Code, number of passed tests.. that's abit to
complicated for me. I just use my intuition .

/Svend Rost

p.s. The appropriate forum is the Process forum.

edit: added smiley
[ May 23, 2006: Message edited by: Svend Rost ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
I like using the number of lines of code deleted.


"I'm not back." - Bill Harding, Twister
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Intuition? That's too complicated for me. The rule I use is, it's 90% complete.
mo sayed
Ranch Hand

Joined: Jan 25, 2006
Posts: 88
>> Seriously, I like #tests passed as a quick and dirty measure

Presuambly you're talking about unit tests?

Is there any other metric that provides a more accurate and reliable
indicator of progress?

Thanks for answering by the way guys. The response time here is impressivley quick.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Seriously, the Process forum is the place for this topic, so I'm moving it now...
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30586
    
154

Originally posted by mo sayed:
Is there any other metric that provides a more accurate and reliable
indicator of progress?

# of user stories or requirements completed is a decent one. You could combine this with defect rate to make it more accurate.

Nothing is going to be too accurate and reliable, but at least they show progress is being made.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Well, depending on the maturity of your organization you can get many different metrics from the whole software development process.

Now, I am not sure, but you seem to be referring to the coding phase specifically, although the software development process itself implies other prior and subsequent phases.

During the coding phase, the progress is, evidently, measured according to the fulfilment of the requirements. How do you have your requirements defined? That could depend on the methodology that you are using. For instance, you could measure the progress by means of counting the number of implemented use cases or user stories, as another colleague suggested.

However, if you have your requirements defined in a napkin, there will be no difference, the system will not be considered finished until it is compliant with the whole set of requirements.

Whatever the case, the progress is always measured against that you put on your WBS, whether it is use cases, user stories, or a simple to do list extracted from a napkin.

It is more difficult to define what those real requirements are than measuring their completion. If you get to define the real set of requirements that will really satisfy the user expectations, than, measuring their progress should not be an issue Simply track their implementation. Once you can put a check to an item of your list, well, put 100% complete to that task in your WBS, and probably your project tools will tell you the rest of the numbers.

If you really got the requirements, when they are all complete, so will your coding phase.

Unfortunately, the requirements are seldom stable. They change, and new requirements emerge during the process. The requirements management process can also be a source of metrics. How many requirements did you omit during the requirements phase that appeared in other phases? How many new requirements appeared during the coding phase? How many of those requirements where functional and how many were non-functional?

That could tell you how to improve your requirements phase, and at the same time, it could tell you what is the stability factor of the requirements on your organization. That way you can be ready when change comes.

You can extract, another metrics that could improve the coding process. For instance, you can determine how much time is spent in reworking, determine the reasons of this reworking factor, and try to reduce it, to increase the amount of time spend in the creation of new payable software. Or you could determine the number of bugs generated in the last iteration of the development process, and try to reduce that number in future iterations in the process, whether it is preventing the errors or increasing the quality of the process.

Some method suggest to determine the size of the software. For instance, using function points. The size is a measurement independent of the time or the cost of a requirement. It is based in the relative complexity of the requirement. This measurement is important, because you could get the wrong idea from simply counting how many items of a to do list are complete. That is because you can have one simple use case left on your to do list, but this last use case could be the most complex of all. Hence, your last 10% of the project could be the 90% of the time, just to mention an extreme and improbable case.

For this size measurement I have heard of things like function points and lines of code (LOC). But I have to admit I have never been in a organization that have used them successfully.
[ May 23, 2006: Message edited by: Edwin Dalorzo ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
See David Anderson's Impact of Metrics and More Impact of Metrics for some ideas. Ron Jeffries has some neat Big Visible Charts. In The Goal Goldratt suggests:

* Throughput - The rate at which the system generates money through sales.

* Inventory - All the money the system has invested in purchasing things it intends to sell.

* Operational Expense - All the money the system spends to turn inventory into throughput

Any of those sound fun?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
mo sayed
Ranch Hand

Joined: Jan 25, 2006
Posts: 88
Everybody,
Thanks for the input. I'll certainly look up the references.
It's the usual story of a customer requiring a measure of progress.
I don't believe SLOC is a good indicator of this and wanted to
point him the right direction.
regards,
Mo
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Another interesting article by Ron Jeffries is http://www.xprogramming.com/xpmag/jatRtsMetric.htm

You should be very careful with metrics, by the way - they can do serious harm to a team. The problem is that there are often more important factors to the success of a project than what you will or even can measure. If you use a metric to "motivate" people, they will probably actually do more of what you measure, but might in consequence do less of what you don't measure - which in the worst case can make your project fail.

There is a lot of good discussion of this and other effects in the book "Measuring and Managing Performance in Organizations". Highly recommended!


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
 
GeeCON Prague 2014
 
subject: Metrics