February 25, 2012 at 11:36 pm #154275
Travis K. AndersonParticipant
- the construction of a new home uses square feet
- instructional system design uses instructor led lecture hours
What is the standard unit of measure for software development?
I am a bean counter looking for a way to extract a means to measure the performance of a gov’t software development project during the implementation, test, and integration phases. It is my hope to convert from “Effort Orientated” to “Success Orientated” units of measure for capturing earned value.
Should I use requirements, testable requirements, features, function points, requirements verified, etc….
Any links, references, and advice would be appreciated.
February 26, 2012 at 2:50 am #154287
Function points are a decent way to go, but there’s a level of maturity you need to build an organization up to before being ready for that I think. Resource: http://www.dpo.it/resources/papers/1999-fesma-fpestmet-en.pdf
Personally my teams and I generally start with planning poker on our teams’ deliverable features/functionality. These may be in the form of user stories too, but I haven’t been successful at doing it with user stories within a waterfall project. There are too many cultural differences and it’s too hard to translate the lean/agile language back up into waterfall-speak.
With planning poker, it’s decks of cards with the Fibbonacci sequence. Mine are from Mountain Goat Software, and are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Because we are working in a waterfall world, we’ve defaulted back to using hour estimates because again, it was just too much work to try and translate these two different world views.
If I could do it any way I wanted, I’d start with user stories and use planning poker for estimating relative story points with the team, and just use the team’s velocity to project completion dates. We wouldn’t ever think in terms of hours of effort or duration, only in terms of story points and velocity.
February 29, 2012 at 1:11 pm #154285
This is a good classic blog posting on the topic – http://martinfowler.com/bliki/CannotMeasureProductivity.html
Having said that, I think your best approach is develop a measure based on features delivered. The whole point of software development is to create an application that does something whether it be word processing or creating spreadsheets. Thus, a measure based on how well the software development fulfills the customer’s needs would seem the best way to measure productivity.
February 29, 2012 at 5:21 pm #154283
I like that post Bill, hadn’t seen that one before.
I think the best proxy we have is user stories or features completed, provided and assuming they are valid. It’s really just as valid a measure as any other arena like construction…you have assumptions that requirements were elicited properly and you are actually building what the customer wants.
February 29, 2012 at 10:47 pm #154281
Travis K. AndersonParticipant
Thanks Josh and Bill. Great comments and reference links. I will dig in and continue to experiment with my software leads in developing best approached for encompassing earned value.
March 9, 2012 at 9:17 am #154279
Please, find herewith some useful links for technical papers relating to your raised topics:
The SWEBOK 2004 Edition:
The new SWEBOK V3 edition will be issued this year: http://www.computer.org/portal/web/swebok
March 15, 2012 at 12:10 am #154277
If you are employing agile software development methodologies, there are emerging techniques (e.g., business velocity) for measuring success / value delivered at any point during the project.
There are even some whitepapers floating around on how to apply EVM to agile software dev projects. For ex: http://www.agilekiwi.com/EarnedValueForAgileProjects.pdf.
Dig around a bit and see what you come up with. Happy to elaborate more on points above, if need be.
You must be logged in to reply to this topic.