David A. Gustafson

A philosophy for software measurement

Abstract We as a group—called the Grubstake Group—are convinced that software measures are essential for “controlling” software. Thus, we are dedicated to producing an environment in which software measures can be confidently used by software managers and programmers. However, we are also convinced that such an environment can only be created if there exists a formal and rigorous foundation for software measurement. This foundation will not have to be understood by the users of the software measures, but it will have to be understood by those who define, validate, and provide tool support for the measures. It is this foundation that we are introducing in this article.

Shotgun correlations in software measures

Many software measures have been forwarded on the simple basis of a high linear correlation coefficient with some measurable quantities. The linear correlation coefficient is an unreliable statistic for deciding whether an observed correlation indicates significant association. Several published software measure experiments collected more than 20 different measurements, or have 14 or fewer observations. With considerable data from small samples, the probability of ‘discovering’ a ‘significant’ correlation is high. We present a computer simulation experiment where the correlation between sets of randomly generated numbers is calculated. We also look at randomly generated numbers in the ranges that would be expected in Halsteads Software Science [1] measures. Our results show that the average maximum linear correlation for randomly generated numbers is 0.70 or higher if the sample size is low compared to the number of variables. Alternative statistical approaches to obtaining meaningful significant results are presented.

A standard representation of imperative language programs for data collection and software measures specification

Abstract Software measures and software tools are often defined in terms of a particular, limited programming language. For example, a number of software measures are defined only for structured programs. Several approaches to program testing and debugging are defined using a specific simple language. As a result, implementing tools and measures so that they can be applied to “real” programs in “real” programming languages is difficult. Further, independent evaluation and comparison of measures and tools is difficult. We propose a standard representation of imperative language programs that is independent of the syntax of any particular programming language, and that supports the definition of a wide range of tools and measures. Additionally, the standard representation masks the actual program semantics. Thus the standard representation provides a vehicle by which large volumes of industrial software can be made available to researchers while protecting the proprietary nature of the programs.

Classifying software maintenance

A revision is presented of E.B. Swansons classification scheme for software maintenance (1976). The proposed classification system can be objectively determined from the changes that occur between versions of the software. The system was developed by analyzing the changes that occur between different versions of COBOL programs that were produced in commercial environments.<<ETX>>

Vision-Based Obstacle Avoidance Using SIFT Features

This paper presents a vision-based collision detection algorithm. Our approach is similar to optic flow-based approaches, except that we are working at a feature level instead of a pixel level. The algorithm analyzes a pair of images taken from a moving camera at different times. Then, it recognizes imminent collisions by analyzing the change in scale and location of SIFT features in the pair of images. We have evaluated the performance of this algorithm and present our experimental results.

A factor analysis of software complexity measures

Abstract Factor analysis has been used to analyse software measures and is useful to identify the important factors that influence variability in measures. Some previous results indicate that many measures are actually measuring the same thing. This article reports on a series of experiments analyzing relationships among some of the commonly used software complexity measures. Identifying relationships is important in selecting the most significant measure(s) to collect. A set of PASCAL programs was analyzed for number of decisions, number of procedures, maximum level of nesting, number of I/O statements, the Halstead count, and number of lines of code. Factor analysis showed several interesting conclusions. First, the program should be normalized to avoid high correlation between program size and everything else. Second, dividing by lines of code appears to be the best normalization. Third, an inverse relationship exists between the normalized number of decisions and both the normalized unique operand counts and the number of decisions. Finally, small programs ( 100 lines).

A software re-engineering process model

A descriptive process model of software re-engineering is presented. The overall structure of the process model is defined by the re-engineering approach. Three re-engineering approaches are described: lump sum, incremental, and evolutionary. The focus is on the breadth of possible tasks.<<ETX>>

NgViz: detecting DNS tunnels through n-gram visualization and quantitative analysis

This paper introduced NgViz, a tool that examines DNS traffic and shows anomalies in n-gram frequencies. This is accomplished by comparing input files against a fingerprint of legitimate traffic. Both quantitative analysis and visual aids are provided that allow the user to make determinations about the legitimacy of the DNS traffic.

Using robotics to teach software engineering

Since most computer science graduates take jobs developing software in team environments, one goal of our computer science program is to provide a realistic experience in developing good quality software as part of a software development team. Our Software Engineering Projects course is a required, two-semester sequence at the senior undergraduate level that fulfills this need. The course uses two Nomad200 robots that were funded in part with a grant in 1991 from NSF under the Division of Undergraduate Educations ILI Program. The purpose of the grant was to develop a lab to give computer science students experience in programming a device that had actual motion and had real-time characteristics. Writing software to control the robots has been very challenging for the students. The students have done very well at this challenge. Two groups of students who have used the robots in this class have participated in national robotics contests.

Taxonomy of cooperative robotic systems

The use of multiple robots to accomplish tasks has been common for many years. The term, cooperative, is used to designate the nature of the interactions among a team of robots. However, there are many differences in how these robots interact. Some groups of robots appear, on the surface, to cooperate but are not actually aware of the other robots. Other groups share goals and objectives. Our research investigated a diverse collection of multiple-robot systems. This paper highlights eight examples. The variations of interaction that we found were used to create a robotic-interaction taxonomy. Each robotic team is measured against three dimensions for placement into the taxonomy. Terminology for different types of cooperation is suggested.