Joe's Jottings
Jottings Number 10, by Joe Podolsky:
From: uunet!opnmail3.corp.hp.com!PODOLSKY_JOE/HP0000_02
Date: Thu, 1 Dec 94 16:10:00 -0800
Jeff Kemp, support manager in PGIS, had an excellent comment in response to the observations about self-managing data elements in Jottings #9. Jeff noted that it would help the support folks a lot if developers built metrics right into the systems. For example, the system could report usage frequency by transaction type, by record-type accessed, etc. And, for sure, the application programs should track and report how often the system went through various error routines, both big ones like aborts and smaller ones like edit warnings. Then the support teams and the users could use the data to prioritize maintenance efforts. It's a great idea. Is anyone out there doing anything like that? Do you know of any packages that do this? Speaking of metrics and data, Capers Jones had some interesting observations in his "Software Challenges" column in the September 1994 issue of IEEE Computer. He says that three common software metrics aren't useful for various reasons: lines of code volume metrics, software science (Halstead time estimation) metrics, and the cost-per-defect metric. However, Jones says that complexity metrics (like the McCabe cyclomatic measure) and function point code volume metrics can be useful when used in consistent ways under standard conditions. Software tools are available that simplify the collection of these metrics. Using a single tool has the added value, of course, of creating the consistent methodology we need. Jones notes, "One very important software domain - the data or information associated with software - lacks any metrics whatsoever. As of 1994, there are no known metrics for quantifying or normalizing the volume of data contained in a database or repository or used by a corporation. There are no metrics for dealing with the costs of creating, using, or removing data. There is no way to explore the volume of active data versus archival data, nor the costs of moving data back and forth between active and inactive status. There are no metrics for measuring data quality, although everyone who has ever worked with a database realizes that poor data quality is a critical problem." Sounds a lot like what we were talking about in Jottings #9. Maybe HSM will help focus some attention on all this. Once upon a time in the Quality Information Systems world, we had a Data Quality Task Force looking at some of these issues, and we did come up with some local fixes, but I don't know if those analyses are still in place. Jones continues, "Another domain with a severe shortage of useful metrics is that of hybrid applications that include hardware, microcode, and software. There are no metrics that cross the hardware/software boundary and allow unified economic analysis at the complete systems level." What do you think of all this? Do any of you know of any work going on in this area, perhaps in one of our product labs if not in IT? Joe