1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
Preface: If you have expertise in metrics and/or formal estimation models
you will no doubt find my comments annoyingly inane. Save the stress on
your cerebral arteries; stop reading now. If however, you are a tadpole of
software engineering, you may find some of these references useful.
Various books and articles I have run across which discuss various software
engineering metrics: (software tools relevant to the area in parenthesis)
For all aspects of software engineering and software engineering metrics:
A1. S.D. Conte, H.E. Dunsmore, V.Y Shen, _Software Engineering
Metrics and Models_, The Benjamin/Cummings Publishing Company, Inc.,
Menlo Park, California, 1986.
[Nicely done. You should have this book if you are interested
in SE metrics/models]
A2. Edward Yourdon, editor, _Classics in Software Engineering_,
YOURDON Press, New York, New York, 1979.
A3. Edward Yourdon, editor, _Writings of the Revolution: Selected
Readings on Software Engineering_, YOURDON Press, New York,
New York, 1982.
[All (well, many) of those landmark articles from the '60s and '70s
that are frequently sited, but unavailable to those of us without
thirty year journal collections are in these two books. I'd
suggest that you buy them if they are still in print.]
A4. Tom DeMarco, _Controlling Software Projects: Management,
Measurement and Estimation_, YOURDON Press, New York, New York,
1982.
[A very good book! Lots of ideas and cheerleading for developing
your own organizational metrics. The algorithm for the halstead
tool I wrote was extracted from an appendix of this book.]
A5. Londeix, Bernard, "Cost Estimation for Software Development",
Addison-Wesley Publishing Company, 1987 (ISBN 0-201-17451-0)
[I've bought it, but haven't had time to read it. Primary
focus is on the Putnam model.]
A6. Zuse, Horst and Bollmann, Peter, "Software Metrics: Using Measurement
Theory to Describe the Properties and Scales of Static Software
Complexity Metrics", ACM SIGPLAN Notices Vol. 24, No. 8 (August 1989)
[Discusses limitations on how various complexity measurements
can be used. Probably applicable to all metrics. Very interesting,
although difficult reading for someone of my limited mental abilities.]
Models based on source lines of code (kdsi - COCOMO) and function points
B1. Barry W. Boehm, _Software Engineering Economics_, Prentice-Hall,
Inc., Englewood Cliffs, NJ, 1981.
[A "must have" book.]
B2. Allan J. Albrecht and John E. Gaffney, Jr., "Software Function,
Source Lines of Code, and Development Effort Prediction: A Software
Science Validation", IEEE Transactions on Software Engineering
Vol. SE-9, No. 6 (November 1983).
B3. Charles A. Behrens, "Measuring the Productivity of Computer
Systems Development Activities with Function Points", IEEE
Transactions on Software Engineering, Vol. SE-9, No. 6 (November
1983).
[Both articles reference: Allen J. Albrecht, "Measuring
application development productivity", Proceedings IBM Applications
Development Symposium Oct 14-17, 1979, GUIDE Int. and SHARE Inc.,
IBM Corp., p. 83; which I do not have.
Conte, Dunsmore and Shen state "... [Allbrecht] obtained a
reasonably smooth fit of his weighted function points to actual
costs. However, the programs he studied were all commercial
applications, in which the function units are more or less clearly
definable and fairly homogeneous. For systems programs, ...
function units are more difficult to define precisely and, in any
case, may differ significantly in size and scope." So, if you are
working with fairly standard commercial applications, you may want
to check this out.]
B4. Chris F. Kemerer, "An Empirical Validation of Software Cost
Estimation Models", Communications of the ACM, Vol 30, No. 5
(May 1987).
[Pretty easy to read. Kemerer, like most writers, found that
different models do better in different environments. He thinks
that function points (Albrecht, see above) may be a better basis
for estimation than lines of code.]
Models based on software science (halstead)
C1. M.H. Halstead, _Elements of Software Science_, Elsevier
North-Holland, Inc., New York, New York, 1977.
[Apparently the seminal statement on software science.
Unfortunately, I don't have the book, so I cannot provide any
commentary on it.]
C2. "Commemorative Issue in Honor of Dr. Maurice H. Halstead", IEEE
Transactions on Software Engineering, Vol. SE-5, No. 2 (March 1979)
[A number of papers on the subject. Some good, some not so
great. Also contains a good article by Parnas.]
C3. Linda M. Ottenstein, "Quantitative Estimates of Debugging
Requirements", IEEE Transactions on Software Engineering, Vol
SE-5, No. 5 (September 1979).
[Ok. Nice example of use of software science model.]
C4. Martin Trachtenberg, "Order and Difficulty of Debugging",
correspondence in IEEE Transactions on Software Engineering, Vol.
SE-9, No. 6 (November 1983).
John E. Gaffney, "Estimating the Number of Faults in Code",
correspondence in IEEE Transactions on Sofware Engineering, Vol.
SE-10, No. 4 (July 1984).
Martin Trachtenberg, "Validating Halstead's Theory with System 3
Data", correspondence in IEEE Transactions on Software
Engineering, Vol. SE-12, No. 4 (April 1986).
Myron Lipow, "Comments on ``Estimating the Number of Faults in
Code'' and Two Corrections to Published Data", correspondence in
IEEE Transactions on Software Engineering, Vol. SE-12, No. 4
(April 1986).
[Various comments on estimating bugs, debugging difficulty.]
C5. R.R. Oldehoeft and Leonard J. Bass, "Dynamic Software Science with
Applications", IEEE Transactions on Software Engineering, Vol SE-5,
No 5 (September 1979)
[Somewhat interesting.]
C6. T.Y. Chen and S.C. Kwan, "An Analysis of Length Equation Using a
Dynamic Approach", ACM SIGPLAN Notices, Vol. 21, No. 4 (April 1986)
[Uhhh, well, to be honest, I didn't really understand what they
were trying to do here. I think it was really just a pointer to a
more comprehensive article which Chen was publishing in Computer
Journal sometime later. Looks interesting though.]
C7. Ann Fitzsimmons and Tom Love, "A Review And Evaluation of Software
Science", ACM Computing Surveys, Vol. 10, No. 1 (March 1978).
[Reasonable overview of early work.]
Models based on cyclomatic complexity (mccabe) and other syntatic
complexity measures:
D1. Thomas J. McCabe, "A Complexity Measure", IEEE Transactions on
Software Engineering, Vol SE-2, No. 4 (December 1976).
[The classic.]
D2. Edward T. Chen, "Program Complexity and Programmer Productivity",
IEEE Transactions on Software Engineering, Vol. SE-4, No. 3 (May
1978).
[An important reworking of some of McCabe's ideas.]
D3. Martin R. Woodward, Michael A. Hennel and David Hedley, "A Measure
of Control Flow Complexity", IEEE Transactions on Software
Engineering, Vol SE-5, No. 1 (January 1979).
[Another view of complexity]
D4. Sallie Henry and Dennis Kafura, "Software Structure Metrics Based
on Information Flow", IEEE Transactions on Software Engineering,
Vol. SE-7, No. 5 (September 1981).
[Develop concept of complexity as function of module
interconnection, apply this complexity measure to the Unix kernel.]
D5. Victor R. Basili and David H. Hutchens, "An Empirical Study of a
Syntactic Complexity Family", IEEE Transactions on Software
Engineering, Vol. SE-9, No. 6 (November 1983).
[A typically well done article from Basili and company. They find
that (no surprise), some programmers handle complexity better than
others. They are not especially thrilled with any particular
complexity measure, but find that statement counts and a hybrid
measure which combines software volume and control organization
seem a little better.]
D6. David H. Hutchens and Victor R. Basili, "System Structure Analysis:
Clustering with Data Bindings", IEEE Transactions on Software
Engineering, Vol. SE-11, No. 8 (August 1985).
[They attempt to use modularization as a complexity measure.
Conclusions are a little weak, but some interesting ideas here.]
D7. Kenneth Magel. "Efficient Calculation of the Scope Program
Complexity Metric", ACM SIGPLAN Notices, Vol. 21, No. 9 (September
1986).
[A complexity measure based on levels of nesting. It has some
intuitive appeal, but no experimental results provided.]
D8. Dennis Kafura and Geereddy R. Reddy, "The Use of Software
Complexity Metrics in Software Maintenance", Vol. SE-13, No. 3
(March 1987).
[Using metrics to guide and control software maintenance.]
D9. H. Dieter Rombach, "A Controlled Experiment on the Impact of
Software Structure on Maintainability", IEEE Transactions on
Software Engineering, Vol. SE-13, No. 3 (March 1987).
[Just like the title says.]
D10. Leslie J. Waguespack, Jr., and Sunil Badlani, "Software Complexity
Assesment: An Introduction and Annotated Bibliography", ACM SIGSOFT
Software Engineering Notes, Vol. 12, No. 4 (October 1987).
[A very complete bibliography, much better than this.]
Articles that discuss more than one estimation method:
E1. Victor R. Basili, Richard W. Selby, Jr., Tsai-Yun Phillips, "Metric
Analysis and Data Validation Across Fortran Projects", IEEE
Transactions on Software Engineering, Vol SE-9, No. 6 (November
1983)
[Basili, et. al. compare software science, cyclomatic complexity
and source lines of code measures and find them all somewhat
lacking as effort estimators.]
|
