Gary Pollice Comments by Email 8/8/05
Philippe and Bob have provided some interesting fodder for the discussion.
COCOMO is certainly one of the best tools we have for predictive metrics, but even so, it is not very reliable. Some estimates show it to be quite variable compared to many other engineering disciplines. This, of course, begs the question as to what software engineering really is, but that's for another discussion. I think Philippe has it right in his last paragraph:
"Not exact science, but allows you to confirm some 'Leroy Roscoe' rule of thumb numbers, like: Are you in the right ballpark, or off by a factor 2 or 3 ..."
Is there an optimal number for any project? Sure, but we probably can't determine that. Besides the cost drivers, you have to consider the type of people, how well or poorly they work together, size of project, etc. There are many people who are quite optimal when working on large projects, but don't do so well on smaller teams. Figuring out the optimal time for a project, given a certain number of "specific" people might be possible with some accuracy as long as you've got enough historical information about how the people have worked together in the past.
If you are using some sort of iterative development, you can get better and better estimates for the next iteration or two by using what has happened before. Optimal estimates for a large project that will take a lot of time - I'm fairly convinced that we're a long way from that. The COCOMO database has a lot of data in it, but it just scratches the surface of what we need to know to get better at believable estimation for large, multi-year projects, IMHO.
Gary
Gary Adds Later
Where relatively quick-hit projects are concerned, this is where I think some of the agile folks have something to say. Quick iterations, continual focus on the most important requirements (determined by the customer) and about all they can guarantee is that they will produce X hours of work a week, but if you select the right pieces, you get the most important X hours worth of value.
This clearly doesn't scale up very well.
Max's Comments
So there you have it! A lot of possibilities for estimating project durations but a lot of things to take into account in practice. The best you can do is to collect data from your own environment and convert it to a form that you can use to predict future project durations. Then, if you want to improve on that, look for the "management obstacles" that retard progress and get them removed!
What are "management obstacles"? Anything that causes stress to the working team resulting in reduced productivity and quality of work. Research indicates that the top five are:[1]
- Constant interruptions
- Unreasonable deadlines
- Poor internal communications
- Lack of support
- Incompetent senior management
By the way, Gary Pollice is Professor of Practice, Computer Science, at Worcester Polytechnic Institute Worcester, MA.
1. Wheatley, R., Taking the Strain, Institute of Management, UK, 2000
|
Philippe Kruchten
Comments by Email 8/8/05
