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 ]
* 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
Joined: Jan 25, 2006
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
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