Cyclomatic complexity and the year 2000

The year 2000 problem is omnipresent, fast approaching, and will present us with something we're not used to: a deadline that can't slip. It will also confront us with two problems, one technical, the other managerial. My cyclomatic complexity measure, implemented using my company's tools, can address both of these concerns directly. The technical problem is that most of the programs using a date or time function have abbreviated the year field to two digits. Thus, as the rest of society progresses into the 21st century, our software will think it's the year 00. The managerial problem is that date references in software are everywhere; every line of code in every program in every system will have to be examined and made date compliant. In this article, I elaborate on an adaptation of the cyclomatic complexity measure to quantify and derive the specific tests for date conversion. I originated the use of cyclomatic complexity as a software metric. The specified data-complexity metric is calculated by first removing all control constructs that do not interact with the referenced data elements in the specified set, and then computing cyclomatic complexity. Specifying all global data elements gives an external coupling measure that determines encapsulation. Specifying all the date elements would quantify the effort for a year-2000 upgrade. This effort will vary depending on the quality of the code that must be changed     

Complexity measures for assembly language programs

This paper presents the results of a study of the software complexity characteristics of a large real-time signal processing system for which there is a 6-yr maintenance history. The objective of the study was to compare values generated by software metrics to the maintenance history in order to determine which software complexity metrics would be most useful for estimating maintenance effort. The metrics that were analyzed were program size measures, software science measures, and control flow measures. During the course of the study two new software metrics were defined. The new metrics, maximum knot depth and knots per jump ratio, are both extensions of the knot count metric. When comparing the metrics to the maintenance data the control flow measures showed the strongest positive correlation.     

Producing maintainable software

The increasing cost of software maintenance has resulted in greater emphasis on the production of maintainable software. One method used to enhance the development of maintainable software is to employ complexity metrics as a technique for controlling software complexity. In order to control complexity, it is imperative to plan for increases in complexity levels from code generation to code implementation. This paper presents a study of complexity increases during the testing and debugging phases of the software life cycle. The metrics used to measure complexity are lines of code, unique operators, unique operands, data difficulty, Halstead's effort and cyclomatic complexity.     

A study of several metrics for programming effort

As the cost of programming becomes a major component of the cost of computer systems, it becomes imperative that program development and maintenance be better managed. One measurement a manager could use is programming complexity. Such a measure can be very useful if the manager is confident that the higher the complexity measure is for a programming project, the more effort it takes to complete the project and perhaps to maintain it. Until recently most measures of complexity were based only on intuition and experience. In the past 3 years two objective metrics have been introduced, McCabe's cyclomatic number v(G) and Halstead's effort measure E. This paper reports an empirical study designed to compare these two metrics with a classic size measure, lines of code. A fourth metric based on a model of programming is introduced and shown to be better than the previously known metrics for some experimental data.     

A synthesis of software science measures and the cyclomatic number

A solution is obtained to the problem of defining a software measure or a family of measures which simultaneously detect those aspects of software complexity that are detected by the software science measures and the cyclomatic number. The authors present a family of measures, called weighted measures that is built on the software science measures by adding weights to certain operators and operands; the size of the weights is determined by a theorem which relates nesting levels and the cyclomatic number. Thus, by construction the weighted measures synthesize the software science measures and the cyclomatic number. Further, by applying the weighted measures, the software science measures, and the cyclomatic number to sample programs, it is shown that the weighted measures also synthesize in practice the software science measures and the cyclomatic number     

Computing Cyclomatic Complexity with Cubic Flowgraphs

Two new methods for the computation of cyclomatic complexity especially for decomposable representations are introduced. Building software by integration is a developing paradigm, especially enabled by the emerging component technologies. Decomposition of the design for a top-down approach is a prerequisite for this paradigm. Cubic flowgraphs are instrumental in providing formalisms for decomposition and integration. Cyclomatic complexity analysis of a design representation that is decomposable is the goal of this research. In addition to introducing cyclomatic complexity computation using cubic flowgraphs, preservation of cyclomatic complexity in the decomposition of the cubic flowgraph is also presented.     

Comments, with reply, on `Predicting source-code complexity at thedesign state' by S. Henry and C. Selig

The commenter objects to the claim made by the authors of the above-mentioned article (see ibid., vol.7, no.2, p.36-44, 1990) that Halstead's E (effort) metric has been extensively validated and to a lack of precise definition for units of `elementary mental discrimination.' With regard to the first point, S. Henry points out that since E seems to give an indication of error-prone software, it must be measuring some aspect of the source code, and that many studies have shown high correlations between effort and lines of code and McCabe's cyclomatic complexity. She agrees with the commenter's second point     

Metric Analysis and Data Validation Across Fortran Projects

The desire to predict the effort in developing or explain the quality of software has led to the proposal of several metrics in the literature. As a step toward validating these metrics, the Software Engineering Laboratory has analyzed the Software Science metrics, cyclomatic complexity, and various standard program measures for their relation to 1) effort (including design through acceptance testing), 2) development errors (both discrete and weighted according to the amount of time to locate and frix), and 3) one another. The data investigated are collected from a production Fortran environment and examined across several projects at once, within individual projects and by individual programmers across projects, with three effort reporting accuracy checks demonstrating the need to validate a database. When the data come from individual programmers or certain validated projects, the metrics' correlations with actual effort seem to be strongest. For modules developed entirely by individual programmers, the validity ratios induce a statistically significant ordering of several of the metrics' correlations. When comparing the strongest correlations, neither Software Science's E metric, cyclomatic complexity nor source lines of code appears to relate convincingly better with effort than the others     

A Measure of Control Flow Complexity in Program Text

This paper discusses the need for measures of complexity and unstructuredness of programs. A simple language independent concept is put forward as a measure of control flow complexity in program text and is then developed for use as a measure of unstructuredness. The proposed metric is compared with other metrics, the most notable of which is the cyclomatic complexity measure. Some experience with automatic tools for obtaining these metrics is reported.     

A statistical study of the relevance of lines of code measures in software projects

Lines of code metrics are routinely used as measures of software system complexity, programmer productivity, and defect density, and are used to predict both effort and cost. The guidelines for using a direct metric, such as lines of code, as a proxy for a quality factor such as complexity or defect density, or in derived metrics such as cost and effort are clear. Amongst other criteria, the direct metric must be linearly related to, and accurately predict, the quality factor and these must be validated through statistical analysis following a rigorous validation methodology. In this paper, we conduct such an analysis to determine the validity and utility of lines of code as a measure using the ISBGS-10 data set. We find that it fails to meet the specified validity tests and, therefore, has limited utility in derived measures.     

Software development productivity of European space, military, andindustrial applications

The identification, combination, and interaction of the many factors which influence software development productivity makes the measurement, estimation, comparison and tracking of productivity rates very difficult. Through the analysis of a European Space Agency database consisting of 99 software development projects from 37 companies in a European countries, the paper seeks to provide significant and useful Information about the major factors which influence the productivity of European space, military, and industrial applications, as well as to determine the best metric for measuring the productivity of these projects. Several key findings emerge from the study. The results indicate that some organizations are obtaining significantly higher productivity than others. Some of this variation is due to the differences in the application category and programming language of projects in each company; however, some differences must also be due to the ways in which these companies manage their software development projects. The use of tools and modern programming practices were found to be major controllable factors in productivity improvement. Finally, the lines-of-code productivity metric is shown to be superior to the process productivity metric for projects in the authors' database     

Experience with logical code analysis in software maintenance

Formal program specification and logical analysis are often used for program derivation and proofs of correctness. The basic tools include the logic of predicate calculus and Dijkstra's weakest precondition calculations. Recent work has shown that these tools are also very useful in the maintenance phase of the software life-cycle. This paper reports experience working with software maintenance teams to apply formal methods. Formal logical analysis is invaluable for isolating defects, determining code corrections, eliminating side-effects, and code re-engineering. Logical analysis works well in software maintenance because many defects can be isolated to small segments of code. These small segments can then be analyzed manually or with code analysis tools. The result is lowered software maintenance costs due to the benefits of defect prevention, reduction of code complexity metrics, productivity improvements, and better specifications and documentation. It would be beneficial to use logical code analysis in the earlier phases of the software life-cycle, such as quality assurance and inspection.     

Prediction of Run-Time Failures Using Static Product Quality Metrics

A study is presented in which it is determined whether software product metrics gathered statically from designs or source code may be helpful in predicting the number of run-time faults that will be encountered during execution. Metrics examined include intermodule metrics such as fan-in and fan-out, as well as intramodule metrics such as cyclomatic complexity and size. Our study indicates that it may be possible, with certain classes of software products, to predict the run-time behaviour using well-known static intermodule metrics.     

An Experiment in Software Error Data Collection and Analysis

The propensity to make programming errors and the rates of error detection and correction are dependent on program complexity. Knowledge of these relationships can be used to avoid errorprone structures in software design and to devise a testing strategy which is based on anticipated difficulty of error detection and correction. An experiment in software error data collection and analysis was conducted in order to study these relationships under conditions where the error data could be carefully defined and collected. Several complexity measures which can be defined in terms of the directed graph representation of a program, such as cyclomatic number, were analyzed with respect to the following error characteristics: errors found, time between error detections, and error correction time. Signifiant relationships were found between complexity measures and error charateristics. The meaning of directed grph structural properties in terms of the complexity of the programming and testing tasks was examined.     

Complexity measurement of a graphical programming language

For many years the software engineering community has been attacking the software reliability problem on two fronts. First via design methodologies, languages and tools as a pre-check on complexity and secondly by measuring the complexity of produced software as a post-check. This research attempts to unify the approach to creating reliable software by providing the ability to measure the complexity of a design prior to its implementation. We have successfully defined and applied software metrics to graphical designs in an effort to predict software complexity early in the software life cycle. Metric values from the graphical design are input to predictor equations, provided in this paper, to give metric values for the resultant source code.     

Statistical methods for the analysis of software metrics data

The authors present case study applications of statistical methods for the analysis of software metrics data which recognize the discrete nature of such data. A procedure is also described which allows a component of complexity independent of size to be extracted from the usual Halstead's metrics and McCabe's cyclomatic number. The methods described are different from the usual regression and non-parametric methods previously applied to software metrics. With the software quality practitioner in mind, the paper explores how these new methods are helpful in understanding the relationships between software metrics.     

Software complexity and its impact on software reliability

To produce reliable software, its complexity must be controlled by suitably decomposing the software system into smaller subsystems. A software complexity metric is developed that includes both the internal and external complexity of a module. This allows analysis of a software system during its development and provides a guide to system decomposition. The basis of this complexity metric is in the development of an external complexity measure that characterizes module interaction     

A Comparison of Measures of Control Flow Complexity

In attempting to describe the quality of computer software, one of the more frequently mentioned measurable attributes is complexity of the flow of control. During the past several years, there have been many attempts to quantify this aspect of computer programs, approaching the problem from such diverse points of view as graph theory and software science. Most notable measures in these areas are McCabe's cyclomatic complexity and Halstead's software effort. More recently, Woodward et al. proposed a complexity measure based on the number of crossings, or "knots," of arcs in a linearization of the flowgraph.     

A measure of logical complexity of programs

The research in software science has so far been concentrated on three measures of program complexity: (a) software effort; (b) cyclomatic complexity; and (c) program knots. In this paper we propose a measure of the logical complexity of programs in terms of the variable dependency of sequence of computations, inductive effort in writing loops and complexity of data structures.

The proposed complexity mensure is described with the aid of a graph which exhibits diagrammatically the dependence of a computation at a node upon the computation of other (earlier) nodes.

Complexity measures of several example programs have been computed and the related issues have been discussed. The paper also describes the role played by data structures in deciding the program complexity.