This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Functional Reactive Programming and have Stephen Blackheath and Anthony Jones on-line!
See this thread for details.
Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Metrics

 
mo sayed
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What part of "meaningless drivel" don't you understand?

Seriously, I like #tests passed as a quick and dirty measure.
 
Svend Rost
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like using the number of lines of code deleted.
 
Paul Clapham
Sheriff
Posts: 21416
33
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Intuition? That's too complicated for me. The rule I use is, it's 90% complete.
 
mo sayed
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>> 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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seriously, the Process forum is the place for this topic, so I'm moving it now...
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34973
379
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
mo sayed
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic