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     

Software complexity and software maintenance: A survey of empirical research

A number of empirical studies have pointed to a link between software complexity and software maintenance performance. The primary purpose of this paper is to document what is known about this relationship, and to suggest some possible future avenues of research. In particular, a survey of the empirical literature in this area shows two broad areas of study: complexity metrics and comprehension. Much of the complexity metrics research has focused on modularity and structure metrics. The articles surveyed are summarized as to major differences and similarities in a set of detailed tables. The text is used to highlight major findings and differences, and a concluding remarks section provides a series of recommendations for future research.     

Managing software productivity and reuse

Your organization can choose from three main strategies for improving its software productivity. You can work faster, using tools that automate or speed up previously labor-intensive tasks. You can work smarter, primarily through process improvements that avoid or reduce non-value-adding tasks. Or you can avoid unnecessary work by reusing software artifacts instead of custom developing each project. Which strategy will produce the highest payoff? The author performed an extensive analysis that addressed this question for the US Department of Defense. The result of this analysis showed that work avoidance via software reuse produced the highest improvement in software productivity. The article gives advice on how to manage software reuse and the pitfalls to avoid     

Evaluating software complexity measures

A set of properties of syntactic software complexity measures is proposed to serve as a basis for the evaluation of such measures. Four known complexity measures are evaluated and compared using these criteria. This formalized evaluation clarifies the strengths and weaknesses of the examined complexity measures, which include the statement count, cyclomatic number, effort measure, and data flow complexity measures. None of these measures possesses all nine properties, and several are found to fail to possess particularly fundamental properties; this failure calls into question their usefulness in measuring synthetic complexity     

Benchmarking software development productivity

The article examines a statistical analysis of a productivity variation, involving a unique database containing 206 business software projects from 26 Finnish companies. The authors examine differences in the factors, explaining productivity in the banking, insurance, manufacturing, wholesale/retail, and public administration sectors. The authors provide productivity benchmarking equations that are useful both for estimating expected productivity at the start of a new project and for benchmarking a completed project for each business sector     

Mental models and software maintenance

Understanding how a program is constructed and how it functions are significant components of the task of maintaining or enhancing a computer program. We have analyzed vidoetaped protocols of experienced programmers as they enhanced a personnel data base program. Our analysis suggests that there are two strategies for program understanding, the systematic strategy and the as-needed strategy. The programmer using the systematic strategy traces data flow through the program in order to understand global program behavior. The programmer using the as-needed strategy focuses on local program behavior in order to localize study of the program. Our empirical data show that there is a strong relationship between using a systematic approach to acquire knowledge about the program and modifying the program successfully. Programmers who used the systematic approach to study the program constructed successful modifications; programmers who used the as-needed approach failed to construct successful modifications. Programmers who used the systematic strategy gathered knowledge about the causal interactions of the program's functional components. Programmers who used the as-needed strategy did not gather such causal knowledge and therefore failed to detect interactions among components of the program.     

Logic programming and software maintenance

The main objective of this short paper is to describe the relationship between software maintenance and logic programming (both declarative and procedural), and to show how ideas and methods from logic programming (in particular, methods invented by M. Gelfond) can be used in software maintenance. The material presented in this paper partly appeared in (Luqi and Cooke, 1995). The main difference is that (Luqi and Cooke, 1995) is aimed mainly at software engineers, so it only briefly touches on the software engineering problems, while describing in great detail the basics of logic programming. In contrast, in this paper, we assume that the corresponding logic programming notions are well known, but describe the corresponding software engineering applications in greater detail. This revised version was published online in June 2006 with corrections to the Cover Date.     

Paradox in software maintenance

Software complexity can either raise or lower the costs of the software maintenance process. In attempting to explain this paradox, the article suggests a matrix of situations relating complexity to the need among programmers and systems staff for stimulating work, and suggests that managers of the software maintenance process should try to match assignments and people.     

An entropy-based measure of software complexity

It is proposed that the complexity of a program is inversely proportional to the average information content of its operators. An empirical probability distribution of the operators occurring in a program is constructed, and the classical entropy calculation is applied. The performance of the resulting metric is assessed in the analysis of two commercial applications totaling well over 130000 lines of code. The results indicate that the new metric does a good job of associating modules with their error spans (averaging number of tokens between error occurrences)     

Predicting (individual) software productivity

A method for projecting software productivity with reasonable accuracy which uses the statistical techniques of time series analysis is described. The measure of productivity is the development time required per line of code. In making productivity projections, the key issue is the need to achieve a balance between forecasting stability and responsiveness to changing conditions. An integrated moving average process of order one, using exponential smoothing of all the previous observations, is judged appropriate for software productivity analysis, particularly where there are limited data available or where conditions are sufficiently varied to make much of the available data inapplicable. Empirical evidence suggests that most commonly encountered time series can be reasonably well described by such methods. The methods for computing the weights used for exponential smoothing are described, as are the means for determining prediction intervals, or measures of forecast uncertainty. This data analytic approach uses historical data alone, unlike structural methods where learning curves as well as prior data are used to define the predictive process     

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     

Identifying factors affecting software development cost and productivity

Software systems of today are often complex, making development costs difficult to estimate. This paper uses data from 50 projects performed at one of the largest banks in Sweden to identify factors that have an impact on software development cost. Correlation analysis of the relationship between factor states and project costs was assessed using ANOVA and regression analysis. Ten out of the original 31 factors turned out to have an impact on software development project cost at the Swedish bank including the: number of function points, involved risk, number of budget revisions, primary platform, project priority, commissioning body’s unit, commissioning body, number of project participants, project duration, and number of consultants. In order to be able to compare projects of different size and complexity, this study also considers the software development productivity defined as the amount of function points per working hour in a project. The study at the bank indicates that the productivity is affected by factors such as performance of estimation and prognosis efforts, project type, number of budget revisions, existence of testing conductor, presentation interface, and number of project participants. A discussion addressing how the productivity factors relate to cost estimation models and their factors is presented. Some of the factors found to have an impact on cost are already included in estimation models such as COCOMO II, TEAMATe, and SEER-SEM, for instance function points and software platform. Thus, this paper validates these well-known factors for cost estimation. However, several of the factors found in this study are not included in established models for software development cost estimation. Thus, this paper also provides indications for possible extensions of these models.     

Search-based refactoring for software maintenance

The high cost of software maintenance could be reduced by automatically improving the design of object-oriented programs without altering their behaviour. We have constructed a software tool capable of refactoring object-oriented programs to conform more closely to a given design quality model, by formulating the task as a search problem in the space of alternative designs. This novel approach is validated by two case studies, where programs are automatically refactored to increase flexibility, reusability and understandability as defined by a contemporary quality model. Both local and simulated annealing searches were found to be effective in this task.     

Managing risk in software maintenance

Software risk management in maintenance differs in major ways from risk management in development. Risk opportunities are more frequent, risks come from more diverse sources, and projects have less freedom to act on them. The authors describe how they dealt with these differences in a large US Navy software maintenance organization     

Ground rules for software maintenance

U.S. Congressman Joe Knollenberg (R-Mich.) has introduced a bill to let third-party computer-service companies provide maintenance to licensed software. The bill is under consideration in the Subcommittee on Courts and Intellectual Property, part of the House Judiciary Committee. This article explains the steps one should take before servicing software: (1) examine user rights; (2) determine the type of agreement; and (3) identify specific restrictions     

Aspect-oriented programming takes aim at software complexity

As global digitalization and the size of applications expand at an exponential rate, software engineering's complexities are also growing. One feature of this complexity is the repetition of functionality throughout an application. An example of the problems this complexity causes occurs when programmers must change an oft-repeated feature for an updated or new version of an application. It is often difficult for programmers to find every instance of such a feature in millions of lines of code. Failing to do so, however, can introduce bugs. To address this issue, software researchers are developing methodologies based on a new programming element: the aspect. An aspect is a piece of code that describes a recurring property of a program. Applications can, of course, have multiple aspects. Aspects provide cross-cutting modularity. In other words, programmers can use aspects to create software modules for issues that cut across various parts of an application. Aspects have the potential to make programmers' work easier, less time-consuming and less error-prone. Proponents say aspects could also lead to less expensive applications, shorter upgrade cycles and software that is flexible and more customizable. A number of companies and universities are working on aspects or aspect-like concepts     

On Weyuker's axioms for software complexity measures

Properties for software complexity measures are discussed. It is shown that a collection of nine properties suggested by E.J. Weyuker is inadequate for determining the quality of a software complexity measure. (see ibid., vol.14, p.1357-65, 1988). A complexity measure which satisfies all nine of the properties, but which has absolutely no practical utility in measuring the complexity of a program is presented. It is concluded that satisfying all of the nine properties is a necessary, but not sufficient, condition for a good complexity measure