Cyclomatic complexity density and software maintenance productivity

A study of the relationship between the cyclomatic complexity metric (T. McCabe, 1976) and software maintenance productivity, given that a metric that measures complexity should prove to be a useful predictor of maintenance costs, is reported. The cyclomatic complexity metric is a measure of the maximum number of linearly independent circuits in a program control graph. The current research validates previously raised concerns about the metric on a new data set. However, a simple transformation of the metric is investigated whereby the cyclomatic complexity is divided by the size of the system in source statements. thereby determining a complexity density ratio. This complexity density ratio is demonstrated to be a useful predictor of software maintenance productivity on a small pilot sample of maintenance projects     

Activity Based Costing for Component-Based Software Development

Component-based software development is a promising set of technologies designed to move software creation from its current, labor-intensive, craft-like approach to a more modern, reuse-centered style. However, a lesson learned from previous radical software process innovations is that a strong technology alone is generally insufficient for successful adoption. In order for gains to be realized from such technologies the management practices surrounding the implementation of the new technology must also change. It is with this view that we propose the adoption of a complementary management approach called activity based costing (ABC) to allow organizations to properly account for and recognize the gains from a component-based approach. ABC enables a management environment where appropriate incentives are created for the development and reuse of software components. Data from a large software vendor who has experience with ABC in a traditional software development environment are presented, along with a chart of accounts for a modern, component-based model.     

Comments on “a metrics suite for object orienteddesign”

A suite of object oriented software metrics has recently been proposed by S.R. Chidamber and C.F. Kemerer (see ibid., vol. 20, p. 476-94, 1994). While the authors have taken care to ensure their metrics have a sound measurement theoretical basis, we argue that is premature to begin applying such metrics while there remains uncertainty about the precise definitions of many of the quantities to be observed and their impact upon subsequent indirect metrics. In particular, we show some of the ambiguities associated with the seemingly simple concept of the number of methods per class. The usefulness of the proposed metrics, and others, would be greatly enhanced if clearer guidance concerning their application to specific languages were to be provided. Such empirical considerations are as important as the theoretical issues raised by the authors     

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.     

Object-oriented and conventional analysis and design methodologies

Three object-oriented analysis methodologies and three object-oriented design methodologies are reviewed and compared to one another. The authors' intent is to answer the question of whether emerging object-oriented analysis and design methodologies require incremental or radical changes on the part of prospective adopters. The evolution of conventional development methodologies is discussed, and three areas-system partitioning, end-to-end process modeling, and harvesting reuse-that appear to be strong candidates for further development work are presented     

An empirical approach to studying software evolution

With the approach of the new millennium, a primary focus in software engineering involves issues relating to upgrading, migrating, and evolving existing software systems. In this environment, the role of careful empirical studies as the basis for improving software maintenance processes, methods, and tools is highlighted. One of the most important processes that merits empirical evaluation is software evolution. Software evolution refers to the dynamic behaviour of software systems as they are maintained and enhanced over their lifetimes. Software evolution is particularly important as systems in organizations become longer-lived. However, evolution is challenging to study due to the longitudinal nature of the phenomenon in addition to the usual difficulties in collecting empirical data. We describe a set of methods and techniques that we have developed and adapted to empirically study software evolution. Our longitudinal empirical study involves collecting, coding, and analyzing more than 25000 change events to 23 commercial software systems over a 20-year period. Using data from two of the systems, we illustrate the efficacy of flexible phase mapping and gamma sequence analytic methods, originally developed in social psychology to examine group problem solving processes. We have adapted these techniques in the context of our study to identify and understand the phases through which a software system travels as it evolves over time. We contrast this approach with time series analysis. Our work demonstrates the advantages of applying methods and techniques from other domains to software engineering and illustrates how, despite difficulties, software evolution can be empirically studied     

Trade-offs between productivity and quality in selecting software development practices

The authors report detailed data and analyses on productivity and quality from 29 Hewlett-Packard projects. While some software development models' characteristics affect performance negatively when considered alone, their impact disappears when considered in combination with other attributes. So, processes should be thought of as coherent systems of activities rather than as a series of individual practices that can be implemented piecemeal.     

Empirical Studies of Evolving Systems

This paper describes the results of the working group investigating the issues of empirical studies for evolving systems. The groups found that there were many issues that were central to successful evolution and this concluded that this is a very important area within software engineering. Finally nine main areas were selected for consideration. For each of these areas the central issues were identified as well as success factors. In some cases success stories were also described and the critical factors accounting for the success analysed. In some cases it was later found that a number of areas were so tightly coupled that it was important to discuss them together.     

The structural complexity of software an experimental test

This research examines the structural complexity of software and, specifically, the potential interaction of the two dominant dimensions of structural complexity, coupling and cohesion. Analysis based on an information processing view of developer cognition results in a theoretically driven model with cohesion as a moderator for a main effect of coupling on effort. An empirical test of the model was devised in a software maintenance context utilizing both procedural and object-oriented tasks, with professional software engineers as participants. The results support the model in that there was a significant interaction effect between coupling and cohesion on effort, even though there was no main effect for either coupling or cohesion. The implication of this result is that, when designing, implementing, and maintaining software to control complexity, both coupling and cohesion should be considered jointly, instead of independently. By providing guidance on structuring software for software professionals and researchers, these results enable software to continue as the solution of choice for a wider range of richer, more complex problems.