 |
|
|
|
|
|
|
||
|
||
|
|
|
by: Charles Symons In software development the emphasis used to be ‘cost reduction’ and ‘productivity improvement’ (more for less cost) now it’s ‘time-to-market’. Time, it appears, has become more important than money. New systems frequently have to be delivered in synch with business re-organisation, or the launch of a new product, or some external deadline like the introduction of the Euro. The chaos and cost caused by not delivering a new system on time may be vastly greater to the client than a small over-run on the software budget needed to meet the target delivery date. All the estimating methods which we know focus on estimating effort and cost. They estimate elapsed time almost as an afterthought. Theories vary widely on the effort/time trade-off relationship. We have recently undertaken three separate, but remarkably similar, consulting projects. All the clients were concerned about failure to deliver software on time. We reviewed both projects and estimates to see what had gone wrong. We examined and quickly sized the requirements or functional specification and applied some simple rules of thumb. These showed that the effort, and especially the elapsed time required, had been seriously under-estimated. So what is the Rule of Thumb for Elapsed Time?We think the rule we used dates from work in IBM in the 70’s, but we have lost the reference! It certainly appears in Boehm's COCOMO estimating model of 1981, and subsequent studies through to findings from the recent COSMIC FFP field trials, all of which produced equations like: Elapsed time = constant x (effort)n where n is about 0.5. Sometimes ‘size’ is substituted for ‘effort’, since the two usually exhibit a fairly linear relationship, at least over limited size ranges.
Precise estimation of elapsed time needs to take into account many more factors. However, this simple equation for the time versus effort relationship is an intriguing one which anyone can test and calibrate more accurately on their own project data. It is astonishing that this still holds true considering how much has changed over the last 30 years. Double the size of the requirements and to a first approximation the effort doubles. It then follows that the elapsed time, other things being equal, must increase by about 40%. Double the cost and you only need 40% more time. While lumping many requirements together into one project may be cheaper, a long schedule is not always acceptable. Small, quick iterations of a few months each are likely to be preferred, despite the diseconomy of (small) scale. It's all a balance of benefits, cost, time, quality, risk and opportunity. |
||||||||||||
|
|
||||||||||||||
|
||||||||||||||
Articles
Services
Training
|
||||||||||||||
|
||||||||||||||
| Software Measurement Services Ltd. | |||
|
|||
