This week's book giveaways are in the iOS and Features new in Java 8 forums. We're giving away four copies each of Barcodes with iOS: Bringing together the digital and physical worlds and Core Java for the Impatient and have the authors on-line! See this thread and this one for details.
Greetings all, Shortly I will be presenting to my graduate course in Object Oriented Systems Development a discussion on metrics (sort of being team taught between the professor and myself) - I have my short list of must have metrics on a project, he has his (mostly the same) - and that is why I am posting - I was hoping for more variance. So any of you that are involved with OOSD would you be kind enough to post what metrics you gather - and what metrics you (or your team) really use. Thanks in advance. -steve
The ones we actually use are unit test coverage percentage, functional test pass/fail, and especially "Unexpected failures". Our functional test framework lets you mark a test as "I know this one doesn't pass yet." Unexpected functional test failures are ones that used to work and are now broken. We used to look at unit test count and line count a lot, earlier in the project, to see how it grew and pat ourselves on the back. We never think about those anymore.
HERE are some metrics we tracked regarding project size (scope), velocity and progress. High visibility tracking and reporting make it hard to cover up progress problems with spin! There's a whole science around defect tracking, when they were introduced, found and corrected. Over a series of releases it gives you a statistical level of confidence that the current release has a low enough number of defects to ship. I had about 1 day exposure to all this in a class - I'll see if I can dig up any references.
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
author and iconoclast
I've worked with the same small development team for quite a few years now, and we're confident in our own and each other's coding ability. I imagine that if we had a larger team, where we were bringing in people to whom we didn't have these ties, then we'd want to use complexity metrics and other code quality measures to make sure overall quality was being kept up.