Frank A Smith wrote ...
This is a blatant request for help to produce a new approach to
pricing my programming services ....
-----------
In the past our group has been pressured into providing # lines of
code to management so they know how big an app is, its complexity, etc.
We have always resisted because lines of code mean nothing unless
you are comparing apps written in the same language and you use the
same formatting (look/feel) rules in the source code and you use
the same set of system/language libraries, and ...
Well, you get the picture.
This last year we started a different method of sizing apps. It
is called Function Point Analysis (dreamed up by Productivity
Management Group, 178 Foxhunt Lane, East Amherst, NY 14051
716-689-7724 or a Calif # 805-298-5522.)
The method of analysing complexity has nothing to do with how it
is written (language, libraries, 3gl, 4gl, 5gl, etc). It has to do
with HOW THE USER VIEWS the app. In theory, this means if the same
app is written in Cobol in 1981, and rewritten in a 5gl in 1993 on a
diferent operating system and has the
same functionality, both versions should have the
same number of function points.
If a developer reuses code (i.e. extensive use of inhouse libaries), it
means they have LESS code that supports MORE function points. You get
credit for Function Points (not how much code you write today).
I do not have any $$ numbers per function point -- although I might
be able to find some.
If you do this correctly, then management can determine $$ to support
a function point, ## of bugs per function point (i.e. quality), etc,
blah, blah, blah. You can generate all kinds of pretty charts to
hang on walls for management.
Yes, this is not a perfect method of analysing cost for software, but I
do think that if you must do so, this is the fairest procedure I have seen.
If there is enough interest in this forum, I could put together
a bit more involved summary....
Or send me a note privately and I will see what I can do for oyu.
Elbert
|
