Chapter 10: Dynamic Software Measurement

10.1 Introduction

Measuring software that is running is a very expensive proposition. The data bandwidth of this process is very large. Unless these data can be filtered in some meaningful way, just the simple task of saving them for future reference can consume a vast number of compute cycles. Data mining on-the-fly will be prohibitively expensive. We must know why we are measuring before we start.

There are a couple of very good reasons to measure systems that are running. First, we can monitor their activity in real-time to ensure that the software is performing in a normal way. If users are forcing a system into some new execution territory, at best they may be inadvertently pushing the system into new and uncertified execution territory and at worst they may be trying to penetrate the security of the system. Second, it is very useful to know what code we have touched during the course of the execution of a specific test. Any observation of code activity, however, must be seen for what it is. The activity that we observe in the code is a reflection of user activity. We will be measuring the code to determine how it is being used. We are not measuring the code for code coverage. That is measurement for measurement's sake. We do not care that all code in a program has been touched in some way during its certification. We do care that the code can do what the user will request of it. Our interest in code measurement will be in what we will learn about the functionality of the program.

By keeping track of the state transitions from module to module and operation to operation we can learn exactly where a system is fragile. This information, coupled with the operational profile, will tell us just how reliable the system will be when we use it as specified. Programs make transitions from module to module as they execute. These transitions can be observed and we can model these transitions as a stochastic process. Ultimately, by developing a mathematical description for the behavior of the software as it transitions from one module to another driven by the operations that it is performing, we can effectively measure what the user is doing with the system.

As a program is exercising any one of its many operations in the normal course of execution of the program, the user will apportion his time across a set of operations. [1] The proportion of execution activity that the user spends in each operation is the operational profile of the program. The proportion of time that a program spends in each of its functionalities is the functional profile of the program. Further, within the functionality, it will apportion its activities across one to many program modules. This distribution of processing activity is represented by the concept of the execution profile. That is, if we have a program structured into n distinct modules, the execution profile for a given functionality will be the proportion of program activity for each program module while the function is being expressed.

[1]Munson, J.C., Software Measurement: Problems and Practice, Annals of Software Engineering, 1(1), 255-285, 1995.



Software Engineering Measurement
Software Engineering Measurement
ISBN: 0849315034
EAN: 2147483647
Year: 2003
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net