SOFTWARE DEVELOPMENT
Avoiding Disasters
"Prediction is very difficult, especially about the future"
 Horror stories abound
with news of projects that result in software disasters. The statistics are frightening.
Billions of dollars have been wasted on software projects with cost overruns, that
finish late, do not meet user expectations, and are outdated before they commence.
This used to relate only to mainframe projects where the scope was large and the
software complex. With the powerful Servers and PCs that are available today, large
and sophisticated systems are being created. With sophistication comes complexity
� these projects are now just as prone to a software disaster as with a mainframe.
Estimating how long a software development project should take is not an exact science.
It involves personal experience and guesswork. See the numerous articles on Kolmogorov
and the "Large Limits to Software Estimation".
Management requirements
Management, quite rightly, require a definite timetable for development. They need
to be able to determine the costs involved, and the resources that are needed.
As the developer cannot provide any degree of certainty, all estimates need to be
made conservatively. Allowance should be made for the inexact nature of software
predictions. And this needs to be communicated to management.
It is not unknown for management to attempt to extract the most optimistic of estimated
times. Worse still, the phrase "estimated completion date" will somehow be understood
as a "definite completion date". A different approach is needed � one that is not
open to misinterpretation.
Optimistic Estimations
Human beings are optimistic creatures. No matter how bleak reality is, there is
always a bright side, a silver lining, a Pollyanna-esc view to be held. This is
especially true of software estimation. If all goes exactly as predicted, the project
will come in on time. Unfortunately, 95% of the time, unanticipated problems will
cause a delay.
"Oh, it's just a few hours work" - frequently turns into several days' hard labour.
Who has not, ever, been guilty of this? The "few hours work" may have taken into
account all the predictable factors. But then there is the unpredictable - when
a routine just will not work. Is it the network? Or a network card? Or a faulty
network connection? Has the latest service pack been installed? Is the user doing
something silly?
For a small task, the consequences of an underestimate may be trifling. But for
a large project, when the very existence of a company is threatened, much more conservative
estimates are needed. What is required is a contingency factor to be applied to
the initial "most reasonable" time estimate. The contingency factor should, at a
minimum, result in a 50% chance of the project completing on schedule. This means
that half the time the project estimator will be a hero, and half the time a villain.
A more professional choice would be a contingency factor resulting in success 95%
of the time. Of course the estimated completion time would be dramatically increased.
|