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. Re-

printed here with permission, it offers some interest-

ing 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 combina-

tion 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 hard-

core 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 sys-

tem 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 appar-

ent 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