AS/400 Metrics

[Greg Della-Croce]

This is my periodic appeal to other AS/400 developers to help
establish a pooling of experience. I have been developing RPG
applications since RPG II on the S/3. But I would like to know how
others do their metrics.

Let me explain. You are faced with a new project. Your cleint/boss
wants to know how long, how many people, and how much money. The
magic 3 factors. You go back and start laying it out? Analysis says
that you have 12 functional areas to work with. Each functional area
needs some number of Database designs, Data management programs (Data
entry and maintenance), some reports, some batch analysis programs,
etc.

Now come the key to project success. The estimate. You have the
tasks in your list by functional area, now you have to assign the
estimated effort, then the assignments of resouces. This in turn
gives you the time line and the estimated cost (based on a long list
of assumetions!). The metrics are the key to consistantly accurate
estimated effort.

I would like to see other peoples mettics. How much effort to you
assign to a program? What factors do you use to deside on the effort.
Lines of code estimates? Number of screens, subfiles, pop-ups? What
do you use and what hours do you assign to each?

I will share all input with those that help set the database up. I
would love to create a spreadsheet that would say here are the factors
and let it work out the hours.

Anyone interested? We will need info on RPG, COBOL, C, and JAVA
projects.

Thanks

[Tony Goodin]

I'm now being asked the same questions, so I did some research.

The good news is that Function Point Analysis ("FPA", see
http://www.ifpug.org/bbs/index.html ) is a well-established method for
estimating the size of an application and applying standard,
language-specific factors to develop effort-hours.

The bad news?
1. It's complicated (although there are numerous software packages to help)
2. It doesn't show up much in AS/400 trade mags, websites and educational
forums.

Consequently, I have been hesitant to pursue it very far.

Is anyone in the 400 world doing FPA, or is it just "ivory tower" stuff?

[John Barron]

Tony Goodin wrote in message <92412794...@news.remarQ.com>...

I've come across FPA, but only in "ivory tower" context. I've not yet
encountered it used in anger in a practical business sense.

Lines-of-code (LOC) is a cruder measure, but easier to apply. I have used
that occasionally. One advantage on the /400 in traditional RPG coding is
that the fixed-column format with one op-code per line does mean that every
LOC is a roughly consistent unit of complexity -- one of the criticisms
levelled at LOC in other languages is that with free-format expressions, one
LOC may be vastly more complex than another. That's starting to become true
of RPG as well with the development of ILE RPG/400.

FPA is finer-grained, and one highly complex LOC may break down into several
function points. Conversely, many simple lines of code may together only
describe a single function point. The downside of FPA is that someone has to
analyse and understand the functionality -- which is a tremendous overhead
to manage, compared to LOC which can be mechanically counted. FPA does have
the advantage that it can be estimated before any code is written, whereas
with LOC it's only possible to apply to existing code.

Whether using FPA or LOC to measure code complexity, the information allows
many uses. One use is to count fault rates (bugs per FPA, or bugs per LOC),
and therefore compare the quality of different projects and set target
standards.

I'd be a bit cautious tryiing to calculate effort-hours, however good your
FPA analysis data was -- that's an even finer distinction than the more
common man-day, and suffers from the basic flaw of that type of project
planning. This is because adding effort to the project does not shorten the
timescale proportionally, or in some cases at all. If you've not come across
it before, look for Fred Brooks definitive treatment of the subject, "The
Mythical Man-Month".

[Greg Della-Croce]

I agree with you that LOC is a better (read that easier) way of
messuring relitive complexity of existing programs. But, that means a
sloppy programmer writes more complex code than a tight programmer. I
do not think this is correct.

Functional points are still way beyond me. I have heard of them, even
read a think or two about them, but "Ivory Tower" is a major
understatement!

What does it take an average programmer to do a given job. Jobs are
batch or interactive, then could be broken down in a Work Break Down
chart.

Greg