F or the past 30 years, I have been playing the numbers game. I have been developing benchmarks to confirm that the estimates I was developing were reasonable and achievable. To win the game, I have had to present the numbers in such a way that people I deal with would use them, not abuse them. Everyone who works in the software business seems to be looking for numbers of one kind or another. I get at least one call a day asking me questions like, " What's the productivity that you've seen across the United States for software within the telecommunications domain? " or " What's the average cost/source line of code for a military system? " My initial reaction is to try to avoid answering these questions. Why? Because I am afraid that whatever I say will be misquoted. Worse, I am afraid that the numbers I supply will be misused. When pressed for an answer, I express the number as a range. I qualify my answer by saying: " The average cost/line for a military system used for command and control varies between one and three hours per source line where an hour is expressed as directly chargeable labor, and a source line of code is defined using the Software Engineering Institute's counting framework as a logical line. Furthermore, the effort associated with this estimate is scoped to include requirements analysis, architectural design, development, and software integration and test tasks. It does not include system or beta testing, but does include support for requirements analysis. " Sounds like a bunch of double-talk doesn't it? Well, it isn't. Nine out of 10 times, no matter what I say, the number is still misquoted or used out of context. Needless to say, I am getting tired of being misquoted. In response, I have decided to write this article to put some of the more important numbers that I use in the public domain. Why? Well, for two reasons. First, I believe the community could use these numbers as benchmarks. They could serve as industry application domain norms against which organizations could compare their results to determine how well (or not so well) they are doing. Second, I want to get the community thinking about discussing and sharing " like " numbers. That is where I believe the real benefits lie. Think about it. When push comes to shove, what …
[1]
Donald J. Reifer.
Making the software business case : improvement by the numbers
,
2002
.
[2]
Jr. Frederick P. Brooks,et al.
The mythical man-month (anniversary ed.)
,
1995
.
[3]
Marcey L. Abate,et al.
Measuring the Software Process
,
2001,
Technometrics.
[4]
Bradford K. Clark.
Quantifying the effects of process improvement on effort
,
2000
.
[5]
S. B. Kiselev,et al.
The capability maturity model: guidelines for improving the software process
,
1995
.
[6]
Walker Royce,et al.
Software Project Management: A Unified Framework
,
1998
.
[7]
Dr. Randall Jensen.
Software Estimating Model Calibration
,
.
[8]
Julie Johnson.
What is the Rational Unified Process ?
,
1999
.
[9]
Bradford K. Clark.
Quantifying the Effects on Effort of Process Improvement
,
2000,
IEEE Softw..
[10]
David S. Christensen,et al.
Calibrating Software Cost Models to Department of Defense DatabasesA Review of Ten Studies
,
1998
.