5
The LA Fox Developer Newsletter
March 1995
Software Metrics
by Harold Chattaway

[Ed. Note: The following article was originally part of BCNN #8, pulled down from CompuServe. Reprinted here with permission, it offers some interesting insight into something all of us, as developers and programmers, have to deal with.)

“The Mets have a record of 10 wins and only I loss so far this year for games on Tuesday night... but they have won 4 out of 25 games where they were behind in the eighth inning.” (TV announcer Ralph Kiner, commenting on the Mets-Expos game on Tuesday, June 25, 1991.)

What does the above statement have to do with Foxpro development? I hope it highlights a serious shortcoming in many software development projects. That is, the total lack of any hard numbers as to what is going on! Baseball, the American pastime, a game, is a game of statistics. Almost any combination of statistics you can think of, baseball has a stat for:

*
* How many hits in a night game by a left hander.
*
Shortstop fielding percentage against right
handed hitters.
*
Batting average of any player during any time
period.

Can similar questions be asked of our software projects? For example:
* Where are the most defects in our software
occurring?
* What type of error is occurring most frequently?
*
How many defects are occurring on a daily
basis?
*
How many times is a particular function being
called?
* Are we getting sufficient test coverage of our
application?

While these kind of stats can be vitally important to the success of an application, they are usually missing from the equation. There is one important reason for capturing these numbers, and that is the desire to improve what you are doing. Without hardcore numbers to back up our assertions, we really do not know how our software is performing. When
simple error handling and program usage toots are in place, we are able to zero in on the areas of our application that are in need of fixing. On one of my last assignments, I installed the error tracking system that I will present in this article in a rather large on-line sales order system. After the course of about week, I was able to see the patterns in the errors. I could clearly see what modules where causing the most problems. Once fixed, the apparent stability of the application greatly improved. I was able to query the error log and determine what modules where causing the most trouble. When the most frequently occurring errors are removed, the system behaves in an almost zero-defect mode.

Installing an error tracking system is actually quite simple. Basically what needs to be done is to use the ON ERROR event trapper to call our tracking system in the event of an error. This switches out Foxpro's native error handler in favor of the one presented here. The line simply reads:

ON ERROR DO errhand with errorO, messageO,; message(1), lineno()

This line states: “When an error occurs, call errhand.prg and pass to it the error number, the error message, the source code that caused the error, and the line number on which it occurred.”

The following are variables that I set up in the main program. “GNSTART” captures the starting time of the application. This is used to track how long the user had been running the app when the error took place.

“GNAPPNAME” is used by the error tracking system to log in the name of the application causing the error. application caused the error. A variable is used for this purpose because this error tracking system resides in a common tools library and can be used on any numbers of projects.

•— Start time of APP...
*_ Time between start and failure. gnstart = seconds()

— Application name... gcappname = “BILLING”

The structure of ERRHAND.DBF, which stores all the errors, is as follows:
(Con?, page 6)
Page 5

5