function points, lines of code

[Odile Laffont]

Can anyone tell me if there is any evidence that the correlation
between software functional size (for example as measured in function
points) and software development effort is better or worse than the
correlation between the size of the software implementation (for
example as measured in lines of code) and software development effort.

I would like to know if there is a particular study which demonstrates
that one correlation is better than the other.

[Mon]

It doesn't take a lot of research to point out that, because different
people can provide the same functionality with different code (either badly
designed, different ways of implementing etc.) the correlation for lines of
code is unlikely to be good, whereas, since FPA measures the functionality
delivered, it is consistent in the size for a specific requirement, and can
provide good correlation provided that the development is done using the
same repeatable development process. There will be different productivity
rates for different environments, and languages, but across a portfolio, it
is good at predicting effort v size.
MON
Odile Laffont <odile.laffont@voila.fr> wrote in message
news:eaea5a16.0308110611.348c158a@posting.google.com... Can anyone tell me if there is any evidence that the correlation between software functional size (for example as measured in function points) and software development effort is better or worse than the correlation between the size of the software implementation (for example as measured in lines of code) and software development effort. I would like to know if there is a particular study which demonstrates that one correlation is better than the other.

[Mon]

Odile,
Lots of people have data on FP. But clients don't give permission to publish
it. If you want to get data in a public database, go to the www.isbsg.com
site (international software benchmarking study group), but you will still
have to pay for the data. You could submit a project to ISBSG and get a
comparison of your completed project against the rest, but I don't think
that's what you want. There's no such thing as a free lunch, so unless you
can talk a benchmarking organisation into sharing its data, you will just
have to live with your distrust, or pay up!
MON
Odile Laffont <odile.laffont@voila.fr> wrote in message
news:eaea5a16.0308120050.72a22cf0@posting.google.com... You seem to be saying that the effort to implement software is independent of code size ["with different code (either badly designed, different ways of implementing etc.) the correlation for lines of code is unlikely to be good"], but has a stronger dependency on functionality delivered. I find it hard to believe that the effort required to deliver 1000 function points of software is the same regardless of whether the solution consists of 10,000 lines of well-designed code or 50,000 lines of badly-designed code. In any case I am looking for hard evidence not hearsay. In my experience function points advocates seem to be long on talk and short on numbers. You may be right, but where is the proof? I would like to know if anyone has undertaken a study of several software projects which investigates the correlations between software size measured in function points and development effort, and between the software size measured in lines of code and development effort. Of course for such a study the software projects would have to be similar types of application, developed using the same language, etc. Odile Laffont "Mon" <ms@indigo.net> wrote in message
news:<XrVZa.27002$pK2.42452@news.indigo.ie>... It doesn't take a lot of research to point out that, because different people can provide the same functionality with different code (either
badly designed, different ways of implementing etc.) the correlation for lines
of code is unlikely to be good, whereas, since FPA measures the
functionality delivered, it is consistent in the size for a specific requirement, and
can provide good correlation provided that the development is done using the same repeatable development process. There will be different
productivity rates for different environments, and languages, but across a portfolio,
it is good at predicting effort v size. MON Odile Laffont <odile.laffont@voila.fr> wrote in message news:eaea5a16.0308110611.348c158a@posting.google.com... Can anyone tell me if there is any evidence that the correlation between software functional size (for example as measured in function points) and software development effort is better or worse than the correlation between the size of the software implementation (for example as measured in lines of code) and software development effort. I would like to know if there is a particular study which demonstrates that one correlation is better than the other.

[Alan E Jones]

I agree that public information with hard numbers is
not readily available. Unless one has access to the private
numbers it would appear the FP proponents are all talk.

While this is also not hard numbers, which I would prefer, here is something
interesting.
A large company that develops software, not my employer but
an employer of a friend of mine.
Started measuring productivity by lines of code for both the
individuals and the teams. They rewarded those with higher
"productivity" with higher raises and bonuses.
They found an marked increase in
lines of code month by month, until finally it was 10 times more
lines of code! Yet they were still delivering the same number of
products and the same functionality as they did before.
It would appear that once people know
they are being measured on lines of code, they would write
their code in such a way as to maximize the lines of code.
It is only natural. So it destroys the usefullnes of lines of code
as a productivity measure.


"Odile Laffont" <odile.laffont@voila.fr> wrote in message
news:eaea5a16.0308120050.72a22cf0@posting.google.com... You seem to be saying that the effort to implement software is independent of code size ["with different code (either badly designed, different ways of implementing etc.) the correlation for lines of code is unlikely to be good"], but has a stronger dependency on functionality delivered. I find it hard to believe that the effort required to deliver 1000 function points of software is the same regardless of whether the solution consists of 10,000 lines of well-designed code or 50,000 lines of badly-designed code. In any case I am looking for hard evidence not hearsay. In my experience function points advocates seem to be long on talk and short on numbers. You may be right, but where is the proof? I would like to know if anyone has undertaken a study of several software projects which investigates the correlations between software size measured in function points and development effort, and between the software size measured in lines of code and development effort. Of course for such a study the software projects would have to be similar types of application, developed using the same language, etc. Odile Laffont "Mon" <ms@indigo.net> wrote in message
news:<XrVZa.27002$pK2.42452@news.indigo.ie>... It doesn't take a lot of research to point out that, because different people can provide the same functionality with different code (either
badly designed, different ways of implementing etc.) the correlation for lines
of code is unlikely to be good, whereas, since FPA measures the
functionality delivered, it is consistent in the size for a specific requirement, and
can provide good correlation provided that the development is done using the same repeatable development process. There will be different
productivity rates for different environments, and languages, but across a portfolio,
it is good at predicting effort v size. MON Odile Laffont <odile.laffont@voila.fr> wrote in message news:eaea5a16.0308110611.348c158a@posting.google.com... Can anyone tell me if there is any evidence that the correlation between software functional size (for example as measured in function points) and software development effort is better or worse than the correlation between the size of the software implementation (for example as measured in lines of code) and software development effort. I would like to know if there is a particular study which demonstrates that one correlation is better than the other.

[Bud Harper]

None of the responses so far addresses the original question – is
there any hard evidence to show that software development effort
correlates better with function points than with lines of code? (or
vice versa).

Suppose you have a number of software projects, all similar types of
application, and all developed using the same language, etc. etc. And
suppose that for each project you have figures for its size in FP, its
size in lines of code, and its development effort. It's a piece of
high school math to produce the answer required.

Instead we're presented with diversions: "clients don't give
permission to publish it (FP data)", and "you will just have to live
with your distrust". Hey, what is this? Is software measurement a
science or an act of faith?

Let's face it Odile, there is no published evidence. If there were
such evidence, and it was favourable to function points, then we'd all
know about it.

Draw your own conclusions.


"Alan E Jones" <alan.jones@unisys.com> wrote in message news:<bhatrj$1eri$1@si05.rsvl.unisys.com>... I agree that public information with hard numbers is not readily available. Unless one has access to the private numbers it would appear the FP proponents are all talk. While this is also not hard numbers, which I would prefer, here is something interesting. A large company that develops software, not my employer but an employer of a friend of mine. Started measuring productivity by lines of code for both the individuals and the teams. They rewarded those with higher "productivity" with higher raises and bonuses. They found an marked increase in lines of code month by month, until finally it was 10 times more lines of code! Yet they were still delivering the same number of products and the same functionality as they did before. It would appear that once people know they are being measured on lines of code, they would write their code in such a way as to maximize the lines of code. It is only natural. So it destroys the usefullnes of lines of code as a productivity measure. "Odile Laffont" <odile.laffont@voila.fr> wrote in message news:eaea5a16.0308120050.72a22cf0@posting.google.com... You seem to be saying that the effort to implement software is independent of code size ["with different code (either badly designed, different ways of implementing etc.) the correlation for lines of code is unlikely to be good"], but has a stronger dependency on functionality delivered. I find it hard to believe that the effort required to deliver 1000 function points of software is the same regardless of whether the solution consists of 10,000 lines of well-designed code or 50,000 lines of badly-designed code. In any case I am looking for hard evidence not hearsay. In my experience function points advocates seem to be long on talk and short on numbers. You may be right, but where is the proof? I would like to know if anyone has undertaken a study of several software projects which investigates the correlations between software size measured in function points and development effort, and between the software size measured in lines of code and development effort. Of course for such a study the software projects would have to be similar types of application, developed using the same language, etc. Odile Laffont "Mon" <ms@indigo.net> wrote in message news:<XrVZa.27002$pK2.42452@news.indigo.ie>... It doesn't take a lot of research to point out that, because different people can provide the same functionality with different code (either badly designed, different ways of implementing etc.) the correlation for lines of code is unlikely to be good, whereas, since FPA measures the functionality delivered, it is consistent in the size for a specific requirement, and can provide good correlation provided that the development is done using the same repeatable development process. There will be different productivity rates for different environments, and languages, but across a portfolio, it is good at predicting effort v size. MON Odile Laffont <odile.laffont@voila.fr> wrote in message news:eaea5a16.0308110611.348c158a@posting.google.com... > Can anyone tell me if there is any evidence that the correlation > between software functional size (for example as measured in function > points) and software development effort is better or worse than the > correlation between the size of the software implementation (for > example as measured in lines of code) and software development effort. > > I would like to know if there is a particular study which demonstrates > that one correlation is better than the other.

[hammer]

The corollary to the original question is - What are the cost benefits
when projects are planned using estimates based on function points
compared with estimates based on LOC?

The irony is you'll hear plenty of talk from software measurement
people about this, but not many numbers. If measurement is so good
for us, why can't they come up with a few numbers?

My company employs a team of function point counters. What they add
to the bottom line, if anything, is anybody's guess.

down2rio@yahoo.com (Bud Harper) wrote in message news:<89557db.0308121538.4422a370@posting.google.com>... None of the responses so far addresses the original question ? is there any hard evidence to show that software development effort correlates better with function points than with lines of code? (or vice versa). Suppose you have a number of software projects, all similar types of application, and all developed using the same language, etc. etc. And suppose that for each project you have figures for its size in FP, its size in lines of code, and its development effort. It's a piece of high school math to produce the answer required. Instead we're presented with diversions: "clients don't give permission to publish it (FP data)", and "you will just have to live with your distrust". Hey, what is this? Is software measurement a science or an act of faith? Let's face it Odile, there is no published evidence. If there were such evidence, and it was favourable to function points, then we'd all know about it. Draw your own conclusions. "Alan E Jones" <alan.jones@unisys.com> wrote in message news:<bhatrj$1eri$1@si05.rsvl.unisys.com>... I agree that public information with hard numbers is not readily available. Unless one has access to the private numbers it would appear the FP proponents are all talk. While this is also not hard numbers, which I would prefer, here is something interesting. A large company that develops software, not my employer but an employer of a friend of mine. Started measuring productivity by lines of code for both the individuals and the teams. They rewarded those with higher "productivity" with higher raises and bonuses. They found an marked increase in lines of code month by month, until finally it was 10 times more lines of code! Yet they were still delivering the same number of products and the same functionality as they did before. It would appear that once people know they are being measured on lines of code, they would write their code in such a way as to maximize the lines of code. It is only natural. So it destroys the usefullnes of lines of code as a productivity measure. "Odile Laffont" <odile.laffont@voila.fr> wrote in message news:eaea5a16.0308120050.72a22cf0@posting.google.com... You seem to be saying that the effort to implement software is independent of code size ["with different code (either badly designed, different ways of implementing etc.) the correlation for lines of code is unlikely to be good"], but has a stronger dependency on functionality delivered. I find it hard to believe that the effort required to deliver 1000 function points of software is the same regardless of whether the solution consists of 10,000 lines of well-designed code or 50,000 lines of badly-designed code. In any case I am looking for hard evidence not hearsay. In my experience function points advocates seem to be long on talk and short on numbers. You may be right, but where is the proof? I would like to know if anyone has undertaken a study of several software projects which investigates the correlations between software size measured in function points and development effort, and between the software size measured in lines of code and development effort. Of course for such a study the software projects would have to be similar types of application, developed using the same language, etc. Odile Laffont "Mon" <ms@indigo.net> wrote in message news:<XrVZa.27002$pK2.42452@news.indigo.ie>... > It doesn't take a lot of research to point out that, because different > people can provide the same functionality with different code (either badly > designed, different ways of implementing etc.) the correlation for lines of > code is unlikely to be good, whereas, since FPA measures the functionality > delivered, it is consistent in the size for a specific requirement, and can > provide good correlation provided that the development is done using the > same repeatable development process. There will be different productivity > rates for different environments, and languages, but across a portfolio, it > is good at predicting effort v size. > MON > Odile Laffont <odile.laffont@voila.fr> wrote in message > news:eaea5a16.0308110611.348c158a@posting.google.com... > > Can anyone tell me if there is any evidence that the correlation > > between software functional size (for example as measured in function > > points) and software development effort is better or worse than the > > correlation between the size of the software implementation (for > > example as measured in lines of code) and software development effort. > > > > I would like to know if there is a particular study which demonstrates > > that one correlation is better than the other.

[Thomas Dickey]

Bud Harper <down2rio@yahoo.com> wrote:
Let's face it Odile, there is no published evidence. If there were such evidence, and it was favourable to function points, then we'd all know about it.

not only that, but what little information _is_ published confirms that
the numbers vary from one measurer to another.
Draw your own conclusions.

( I have been watching this act for 20 years ;-)

--
Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com
ftp://dickey.his.com

[Mon]

feeling threatened, by any chance?
Yes there is data to demonstrate that functional size measurement, done
correctly, can be used to provide consistent estimates of effort if the
other variables remain the same (environment, team, experience etc.). There
are issues with software in different layers of abstraction, but the
COSMIC-FFP method of functional size measurement has been developed to
address this problem and is in use worldwide.
Now, if you want to hear something interesting on the subject, e.g.
experience of people who put the effort in, why don't you attend a
measurement conference and hear them? In the UK, UKSMA is running one in
September, and in Canada there is another (IWSM) - both on towards the end
of September.
MON.
hammer <breeze99@lovemail.co.uk> wrote in message
news:50f6dbb8.0308130042.1d2a5e0c@posting.google.com... The corollary to the original question is - What are the cost benefits when projects are planned using estimates based on function points compared with estimates based on LOC? The irony is you'll hear plenty of talk from software measurement people about this, but not many numbers. If measurement is so good for us, why can't they come up with a few numbers? My company employs a team of function point counters. What they add to the bottom line, if anything, is anybody's guess. down2rio@yahoo.com (Bud Harper) wrote in message
news:<89557db.0308121538.4422a370@posting.google.com>... None of the responses so far addresses the original question ? is there any hard evidence to show that software development effort correlates better with function points than with lines of code? (or vice versa). Suppose you have a number of software projects, all similar types of application, and all developed using the same language, etc. etc. And suppose that for each project you have figures for its size in FP, its size in lines of code, and its development effort. It's a piece of high school math to produce the answer required. Instead we're presented with diversions: "clients don't give permission to publish it (FP data)", and "you will just have to live with your distrust". Hey, what is this? Is software measurement a science or an act of faith? Let's face it Odile, there is no published evidence. If there were such evidence, and it was favourable to function points, then we'd all know about it. Draw your own conclusions. "Alan E Jones" <alan.jones@unisys.com> wrote in message
news:<bhatrj$1eri$1@si05.rsvl.unisys.com>... I agree that public information with hard numbers is not readily available. Unless one has access to the private numbers it would appear the FP proponents are all talk. While this is also not hard numbers, which I would prefer, here is
something interesting. A large company that develops software, not my employer but an employer of a friend of mine. Started measuring productivity by lines of code for both the individuals and the teams. They rewarded those with higher "productivity" with higher raises and bonuses. They found an marked increase in lines of code month by month, until finally it was 10 times more lines of code! Yet they were still delivering the same number of products and the same functionality as they did before. It would appear that once people know they are being measured on lines of code, they would write their code in such a way as to maximize the lines of code. It is only natural. So it destroys the usefullnes of lines of code as a productivity measure. "Odile Laffont" <odile.laffont@voila.fr> wrote in message news:eaea5a16.0308120050.72a22cf0@posting.google.com... > You seem to be saying that the effort to implement software is > independent of code size ["with different code (either badly
designed, > different ways of implementing etc.) the correlation for lines of
code > is unlikely to be good"], but has a stronger dependency on > functionality delivered. I find it hard to believe that the effort > required to deliver 1000 function points of software is the same > regardless of whether the solution consists of 10,000 lines of > well-designed code or 50,000 lines of badly-designed code. > > In any case I am looking for hard evidence not hearsay. In my > experience function points advocates seem to be long on talk and
short > on numbers. You may be right, but where is the proof? > > I would like to know if anyone has undertaken a study of several > software projects which investigates the correlations between
software > size measured in function points and development effort, and between > the software size measured in lines of code and development effort. > Of course for such a study the software projects would have to be > similar types of application, developed using the same language,
etc. > > Odile Laffont > > "Mon" <ms@indigo.net> wrote in message news:<XrVZa.27002$pK2.42452@news.indigo.ie>... > > It doesn't take a lot of research to point out that, because
different > > people can provide the same functionality with different code
(either badly > > designed, different ways of implementing etc.) the correlation for
lines of > > code is unlikely to be good, whereas, since FPA measures the functionality > > delivered, it is consistent in the size for a specific
requirement, and can > > provide good correlation provided that the development is done
using the > > same repeatable development process. There will be different productivity > > rates for different environments, and languages, but across a
portfolio, it > > is good at predicting effort v size. > > MON > > Odile Laffont <odile.laffont@voila.fr> wrote in message > > news:eaea5a16.0308110611.348c158a@posting.google.com... > > > Can anyone tell me if there is any evidence that the correlation > > > between software functional size (for example as measured in
function > > > points) and software development effort is better or worse than
the > > > correlation between the size of the software implementation (for > > > example as measured in lines of code) and software development
effort. > > > > > > I would like to know if there is a particular study which
demonstrates > > > that one correlation is better than the other.

[Mon]

You may have been watching for 20 years, but if so, you will be aware that
qualified (passed the exams) measurement people can achieve +/- 10% accuracy
on size. When have you achieved that with lines of code? How do you estimate
with lines of code anyway - you don't have them until its too late, but you
can estimate the size in FP as soon as you have a statement of requirements.
MON
Thomas Dickey <dickey@saltmine.radix.net> wrote in message
news:bhd3au$nr7$1@news1.radix.net... Bud Harper <down2rio@yahoo.com> wrote: Let's face it Odile, there is no published evidence. If there were such evidence, and it was favourable to function points, then we'd all know about it. not only that, but what little information _is_ published confirms that the numbers vary from one measurer to another. Draw your own conclusions. ( I have been watching this act for 20 years ;-) -- Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com> http://dickey.his.com ftp://dickey.his.com

[hammer]

"Yes there is data to demonstrate ..."

Ha, ha, ha.

OK, so where is this data?

All you have demonstrated so far is that function points involves
many, many words but very few numbers.


"Mon" <ms@indigo.net> wrote in message news:<1Mz_a.27291$pK2.42992@news.indigo.ie>... feeling threatened, by any chance? Yes there is data to demonstrate that functional size measurement, done correctly, can be used to provide consistent estimates of effort if the other variables remain the same (environment, team, experience etc.). There are issues with software in different layers of abstraction, but the COSMIC-FFP method of functional size measurement has been developed to address this problem and is in use worldwide. Now, if you want to hear something interesting on the subject, e.g. experience of people who put the effort in, why don't you attend a measurement conference and hear them? In the UK, UKSMA is running one in September, and in Canada there is another (IWSM) - both on towards the end of September. MON. hammer <breeze99@lovemail.co.uk> wrote in message news:50f6dbb8.0308130042.1d2a5e0c@posting.google.com... The corollary to the original question is - What are the cost benefits when projects are planned using estimates based on function points compared with estimates based on LOC? The irony is you'll hear plenty of talk from software measurement people about this, but not many numbers. If measurement is so good for us, why can't they come up with a few numbers? My company employs a team of function point counters. What they add to the bottom line, if anything, is anybody's guess. down2rio@yahoo.com (Bud Harper) wrote in message news:<89557db.0308121538.4422a370@posting.google.com>... None of the responses so far addresses the original question ? is there any hard evidence to show that software development effort correlates better with function points than with lines of code? (or vice versa). Suppose you have a number of software projects, all similar types of application, and all developed using the same language, etc. etc. And suppose that for each project you have figures for its size in FP, its size in lines of code, and its development effort. It's a piece of high school math to produce the answer required. Instead we're presented with diversions: "clients don't give permission to publish it (FP data)", and "you will just have to live with your distrust". Hey, what is this? Is software measurement a science or an act of faith? Let's face it Odile, there is no published evidence. If there were such evidence, and it was favourable to function points, then we'd all know about it. Draw your own conclusions. "Alan E Jones" <alan.jones@unisys.com> wrote in message news:<bhatrj$1eri$1@si05.rsvl.unisys.com>... > I agree that public information with hard numbers is > not readily available. Unless one has access to the private > numbers it would appear the FP proponents are all talk. > > While this is also not hard numbers, which I would prefer, here is something > interesting. > A large company that develops software, not my employer but > an employer of a friend of mine. > Started measuring productivity by lines of code for both the > individuals and the teams. They rewarded those with higher > "productivity" with higher raises and bonuses. > They found an marked increase in > lines of code month by month, until finally it was 10 times more > lines of code! Yet they were still delivering the same number of > products and the same functionality as they did before. > It would appear that once people know > they are being measured on lines of code, they would write > their code in such a way as to maximize the lines of code. > It is only natural. So it destroys the usefullnes of lines of code > as a productivity measure. > > > "Odile Laffont" <odile.laffont@voila.fr> wrote in message > news:eaea5a16.0308120050.72a22cf0@posting.google.com... > > You seem to be saying that the effort to implement software is > > independent of code size ["with different code (either badly designed, > > different ways of implementing etc.) the correlation for lines of code > > is unlikely to be good"], but has a stronger dependency on > > functionality delivered. I find it hard to believe that the effort > > required to deliver 1000 function points of software is the same > > regardless of whether the solution consists of 10,000 lines of > > well-designed code or 50,000 lines of badly-designed code. > > > > In any case I am looking for hard evidence not hearsay. In my > > experience function points advocates seem to be long on talk and short > > on numbers. You may be right, but where is the proof? > > > > I would like to know if anyone has undertaken a study of several > > software projects which investigates the correlations between software > > size measured in function points and development effort, and between > > the software size measured in lines of code and development effort. > > Of course for such a study the software projects would have to be > > similar types of application, developed using the same language, etc. > > > > Odile Laffont > > > > "Mon" <ms@indigo.net> wrote in message news:<XrVZa.27002$pK2.42452@news.indigo.ie>... > > > It doesn't take a lot of research to point out that, because different > > > people can provide the same functionality with different code (either badly > > > designed, different ways of implementing etc.) the correlation for lines of > > > code is unlikely to be good, whereas, since FPA measures the functionality > > > delivered, it is consistent in the size for a specific requirement, and can > > > provide good correlation provided that the development is done using the > > > same repeatable development process. There will be different productivity > > > rates for different environments, and languages, but across a portfolio, it > > > is good at predicting effort v size. > > > MON > > > Odile Laffont <odile.laffont@voila.fr> wrote in message > > > news:eaea5a16.0308110611.348c158a@posting.google.com... > > > > Can anyone tell me if there is any evidence that the correlation > > > > between software functional size (for example as measured in function > > > > points) and software development effort is better or worse than the > > > > correlation between the size of the software implementation (for > > > > example as measured in lines of code) and software development effort. > > > > > > > > I would like to know if there is a particular study which demonstrates > > > > that one correlation is better than the other.

[Bud Harper]

Digging a bit further, I realise I can go one better than my last
post. I have used data from COBOL only projects from the 1983 paper
"Software Function, Source Lines of Code, and Development Effort
Prediction: A Software Science Validation" by Albrecht and Gaffney:

(A) (B) (C) (D)
ID FP KSLOC Kmh
1 1750 130 102.4
2 1902 318 105.2
3 428 20 11.1
5 431 62 28.8
6 283 28 10.0
7 205 35 8.0
8 289 30 4.9
9 680 48 12.9
10 79 93 19.0
11 512 57 10.8
12 224 22 2.9
13 417 24 7.5
15 209 40 4.1
16 512 96 15.8
18 400 52 8.9
19 1235 94 38.1
21 500 15 3.6
22 260 29 6.1

(Kmh = 1000 man-hours)

For this data we have these correlations:

Between B and D (Fps and Effort) = 0.931
Between C amd D (SLOC and Effort) = 0.864

At this point the FP enthusiasts will start cheering. But hold on a
minute. What matters is not the absolute value of the correlation
coefficient, but whether or not its difference from the other is
statistically significant.

For this we test the null hypothesis that there is no difference
between the correlation coefficients.

To do this we need to calculate: z =
(0.5*ln((1+r1)/(1-r1))–0.5*ln((1+r2)/(1-r2)))/(1/(n1-3)+1/(n2-3))^0.5
[z is approximately normal with mean 0 and variance 1]

For the above data z = 0.983, and the probability of this result
occurring at random is 0.326 which is far too large to be considered
statistically significant. (Typically we would want a value here as
low as 0.05, the 5% level).

The conclusion must be that, on the basis of Albrecht and Gaffney's
COBOL data, there is no evidence of any better (or worse) correlation
between FPs and effort than between lines of code and effort.

Add to this the unsupported assertion earlier in this thread that
function point counts vary by +/- 10%, and it's small wonder that
function points have to be shored up by a lot of hype.

Of course, if you wish, you can go hunting for a different set of data
which yields a result that suits your own purpose.




down2rio@yahoo.com (Bud Harper) wrote in message news:<89557db.0308140107.6dedf77e@posting.google.com>... Although this does not answer the original question, to add some substance to this debate I have selected 9 similar "scientific", "organic mode" software projects all developed in Fortran taken from Barry Boehm's COCOMO study as detailed in his book "Software Engineering Economics" see pages 496 - 497: (A) (B) (C) (D) ID man-months kdsi FP 37 47 34 not known 39 8 6.2 not known 41 6 5.3 not known 42 45 19.5 not known 43 83 28 not known 44 87 30 not known 45 106 32 not known 46 126 57 not known 47 36 23 not known I calculate that the product moment correlation coefficient (r) for the data in columns B and C is 0.887 And using Student's t-test on the t statistic = r sqrt(N-2)/sqrt(1-r^2) , where N is the number of data points, I find that t = 5.07 , which with 7 degrees of freedom is significant at the 0.14% level. Clearly a very strong correlation between size of the implementation and development effort. Of course, this is only half the story because for the comparison requested in Odile's original message we need to do the SAME calculation for the SAME projects but using columns B and D. But it was all done with Excel in under 3 minutes. And there you are - acknowledged data source, hard numbers, clear conclusion, and no unsubstantiated claims. So why is it so difficult for function point advocates to do something as easy and as straightforward as this? (I think we all know the answer to this by now) wgarnison@lycos.com (William G. Arnison) wrote in message news:<5b254243.0308132124.207faa57@posting.google.com>... Again, this has absolutely no relevance to the original question ? does software development effort correlate better with software size measured in FP or LOC. And is there a study to prove it. Evidently, as with politicians, when you ask function point enthusiasts one question, they will answer another. "Mon" <ms@indigo.net> wrote in message news:<pOz_a.27292$pK2.43081@news.indigo.ie>... You may have been watching for 20 years, but if so, you will be aware that qualified (passed the exams) measurement people can achieve +/- 10% accuracy on size. When have you achieved that with lines of code? How do you estimate with lines of code anyway - you don't have them until its too late, but you can estimate the size in FP as soon as you have a statement of requirements. MON Thomas Dickey <dickey@saltmine.radix.net> wrote in message news:bhd3au$nr7$1@news1.radix.net... > Bud Harper <down2rio@yahoo.com> wrote: > > > Let's face it Odile, there is no published evidence. If there were > > such evidence, and it was favourable to function points, then we'd all > > know about it. > > not only that, but what little information _is_ published confirms that > the numbers vary from one measurer to another. > > > Draw your own conclusions. > > ( I have been watching this act for 20 years ;-) > > -- > Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com> > http://dickey.his.com > ftp://dickey.his.com

[Thomas Dickey]

Mon <ms@indigo.net> wrote:

a lot of words indicating that he was paying no attention to his keyboard..

--
Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com
ftp://dickey.his.com

[Thomas Dickey]

Bud Harper <down2rio@yahoo.com> wrote: Digging a bit further, I realise I can go one better than my last post. I have used data from COBOL only projects from the 1983 paper "Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation" by Albrecht and Gaffney:

I did some work in the late 70's (a smaller experiment - only about 5Ksloc),
and Halstead's model ("software science") didn't produce much different
result from LOC's. So I'd tend to agree with this. Too bad FP's don't
publish usable results.

--
Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com
ftp://dickey.his.com

[hammer]

Bud,

Thank you for your detailed and helpful analysis.

It is disappointing to see that in some quarters software measurement
is so devoid of rigour and substance that it reduces to a verbose
sales pitch. And from your analysis it's clear why fans of function
points have to depend on lots of rhetoric to put across their case.

But it isn't a one-sided story. It seems intuitively correct that
analysis and design effort, and perhaps testing and integration
effort, should correlate well with software size measured in function
points. In addition it seems probable that coding effort should
correlate better with software size measured in lines of code than
with function points.

But in the field of software measurement there is no place for either
intuition or the blind faith of many function points supporters. I
think it is important for the credibility of software measurement that
when specific questions are asked, answers are supplied which are more
than just word of mouth. And hiding behind suggestions that no
figures are available because companies keep data confidential is
ridiculous. No wonder software measurement is sometimes perceived as
witchcraft rather than a structured technical discipline.

Further, it is expensive to carry out software measurement. And the
return on that investment should be questioned. But this is something
which is seldom publicised by software measurement people. While I
have seen excellent reports from studies undertaken by measurement
specialists, I have seen some which were almost worthless.

In conclusion, when software measurement people make an assertion it
must be supported by numbers not empty talk, not extraneous
references, and not excuses.


down2rio@yahoo.com (Bud Harper) wrote in message news:<89557db.0308140505.7b314a85@posting.google.com>... Digging a bit further, I realise I can go one better than my last post. I have used data from COBOL only projects from the 1983 paper "Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation" by Albrecht and Gaffney: (A) (B) (C) (D) ID FP KSLOC Kmh 1 1750 130 102.4 2 1902 318 105.2 3 428 20 11.1 5 431 62 28.8 6 283 28 10.0 7 205 35 8.0 8 289 30 4.9 9 680 48 12.9 10 79 93 19.0 11 512 57 10.8 12 224 22 2.9 13 417 24 7.5 15 209 40 4.1 16 512 96 15.8 18 400 52 8.9 19 1235 94 38.1 21 500 15 3.6 22 260 29 6.1 (Kmh = 1000 man-hours) For this data we have these correlations: Between B and D (Fps and Effort) = 0.931 Between C amd D (SLOC and Effort) = 0.864 At this point the FP enthusiasts will start cheering. But hold on a minute. What matters is not the absolute value of the correlation coefficient, but whether or not its difference from the other is statistically significant. For this we test the null hypothesis that there is no difference between the correlation coefficients. To do this we need to calculate: z = (0.5*ln((1+r1)/(1-r1))?0.5*ln((1+r2)/(1-r2)))/(1/(n1-3)+1/(n2-3))^0.5 [z is approximately normal with mean 0 and variance 1] For the above data z = 0.983, and the probability of this result occurring at random is 0.326 which is far too large to be considered statistically significant. (Typically we would want a value here as low as 0.05, the 5% level). The conclusion must be that, on the basis of Albrecht and Gaffney's COBOL data, there is no evidence of any better (or worse) correlation between FPs and effort than between lines of code and effort. Add to this the unsupported assertion earlier in this thread that function point counts vary by +/- 10%, and it's small wonder that function points have to be shored up by a lot of hype. Of course, if you wish, you can go hunting for a different set of data which yields a result that suits your own purpose. down2rio@yahoo.com (Bud Harper) wrote in message news:<89557db.0308140107.6dedf77e@posting.google.com>... Although this does not answer the original question, to add some substance to this debate I have selected 9 similar "scientific", "organic mode" software projects all developed in Fortran taken from Barry Boehm's COCOMO study as detailed in his book "Software Engineering Economics" see pages 496 - 497: (A) (B) (C) (D) ID man-months kdsi FP 37 47 34 not known 39 8 6.2 not known 41 6 5.3 not known 42 45 19.5 not known 43 83 28 not known 44 87 30 not known 45 106 32 not known 46 126 57 not known 47 36 23 not known I calculate that the product moment correlation coefficient (r) for the data in columns B and C is 0.887 And using Student's t-test on the t statistic = r sqrt(N-2)/sqrt(1-r^2) , where N is the number of data points, I find that t = 5.07 , which with 7 degrees of freedom is significant at the 0.14% level. Clearly a very strong correlation between size of the implementation and development effort. Of course, this is only half the story because for the comparison requested in Odile's original message we need to do the SAME calculation for the SAME projects but using columns B and D. But it was all done with Excel in under 3 minutes. And there you are - acknowledged data source, hard numbers, clear conclusion, and no unsubstantiated claims. So why is it so difficult for function point advocates to do something as easy and as straightforward as this? (I think we all know the answer to this by now) wgarnison@lycos.com (William G. Arnison) wrote in message news:<5b254243.0308132124.207faa57@posting.google.com>... Again, this has absolutely no relevance to the original question ? does software development effort correlate better with software size measured in FP or LOC. And is there a study to prove it. Evidently, as with politicians, when you ask function point enthusiasts one question, they will answer another. "Mon" <ms@indigo.net> wrote in message news:<pOz_a.27292$pK2.43081@news.indigo.ie>... > You may have been watching for 20 years, but if so, you will be aware that > qualified (passed the exams) measurement people can achieve +/- 10% accuracy > on size. When have you achieved that with lines of code? How do you estimate > with lines of code anyway - you don't have them until its too late, but you > can estimate the size in FP as soon as you have a statement of requirements. > MON > Thomas Dickey <dickey@saltmine.radix.net> wrote in message > news:bhd3au$nr7$1@news1.radix.net... > > Bud Harper <down2rio@yahoo.com> wrote: > > > > > Let's face it Odile, there is no published evidence. If there were > > > such evidence, and it was favourable to function points, then we'd all > > > know about it. > > > > not only that, but what little information _is_ published confirms that > > the numbers vary from one measurer to another. > > > > > Draw your own conclusions. > > > > ( I have been watching this act for 20 years ;-) > > > > -- > > Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com> > > http://dickey.his.com > > ftp://dickey.his.com