COCOMO - The return of
Well apparently this old chestnut is still alive and kicking. I decided to attend a session on estimation using COCOMO-II just as a refresher and two things are pretty obvious :
- The somnolent qualities of Coco(a) in all its forms have a reputation well deserved.
- As an estimation methodology for projects - this is doomed to eternal irrelevance.
There are many things not quite right about COCOMO in estimating today's projects but the glaring reason for its inapplicability is this - these days most IT projects that really need estimating ( or put it another way - where the opportunity cost of a bad estimate is high), have to do with integration. And at no stage does COCOMO concern itself with the complexities of multi system integration, interface incompatibility and risk, parallel paths and differing confidence levels in different projects etc. With an increasing trend in service oriented architecture, message based integration and EAI projects, this is unfortunately the real world landscape where most of us have to estimate these days. Whilst COCOMO-II is a laudable attempt to come to terms with the iterative nature of modern projects and address some of the deficiencies in the original 1981 model ( which assumes a waterfall approach), the overwhelming trend towards more integration based software construction has been missed somewhere ( at least to my knowledge). I think that severely limits the effectiveness of the method.
As a means of getting a second opinion it's no worse than anything else out there but is the overhead really worth it ? It reminds me of some parallels in Finance theory. The anecdote of someone beating the market by making decisions by throwing darts at a copy of the wall street journal is well known - that approach has been shown to beat the best academics using complex mathematical models on historical data to predict the market. Elements of a modern software project are not very different from the dynamics of a marketplace with conflicts of interest, zero sum situations and people and projects with diametrically opposite views vying for individual gain. I suspect a simple , multi expert assesment based triangulation technique ( i.e ask 3 reasonable people who know the landscape for estimates based on a firmed out requirements and then triangulate towards a solution) will beat any COCOMO estimate. Obviously this is gut feel more than anything else.
- The somnolent qualities of Coco(a) in all its forms have a reputation well deserved.
- As an estimation methodology for projects - this is doomed to eternal irrelevance.
There are many things not quite right about COCOMO in estimating today's projects but the glaring reason for its inapplicability is this - these days most IT projects that really need estimating ( or put it another way - where the opportunity cost of a bad estimate is high), have to do with integration. And at no stage does COCOMO concern itself with the complexities of multi system integration, interface incompatibility and risk, parallel paths and differing confidence levels in different projects etc. With an increasing trend in service oriented architecture, message based integration and EAI projects, this is unfortunately the real world landscape where most of us have to estimate these days. Whilst COCOMO-II is a laudable attempt to come to terms with the iterative nature of modern projects and address some of the deficiencies in the original 1981 model ( which assumes a waterfall approach), the overwhelming trend towards more integration based software construction has been missed somewhere ( at least to my knowledge). I think that severely limits the effectiveness of the method.
As a means of getting a second opinion it's no worse than anything else out there but is the overhead really worth it ? It reminds me of some parallels in Finance theory. The anecdote of someone beating the market by making decisions by throwing darts at a copy of the wall street journal is well known - that approach has been shown to beat the best academics using complex mathematical models on historical data to predict the market. Elements of a modern software project are not very different from the dynamics of a marketplace with conflicts of interest, zero sum situations and people and projects with diametrically opposite views vying for individual gain. I suspect a simple , multi expert assesment based triangulation technique ( i.e ask 3 reasonable people who know the landscape for estimates based on a firmed out requirements and then triangulate towards a solution) will beat any COCOMO estimate. Obviously this is gut feel more than anything else.
posted by Piyush Pant | 7:40 AM
0 Comments:
Post a Comment
<< Home