Complexity Metrics and Software Maintenance - a Systematic Literature Review

Complexity Metrics and Software Maintenance: A Systematic Literature Review

ABSTRACT

Over the last few decades, software and software develop-ment practices have evolved immensely. The size of the soft-ware has grown signi cantly and so has the maintenance ef-fort. Software metrics quantify the complexity of the system and provide relevant information about productivity, code quality, and project economics. We analyse recent studies which provide evidence of how useful the software metrics really are and if one fares better than the other. We take a look at some practices which are being followed in the indus-try today and try to determine why the metrics being used are inadequate to capture the various aspects of software development life cycle. Our investigation led us to intro-duce some research questions which we attempt to answer towards the end of this report.

Categories and Subject Descriptors

D.2.8 [Software Engineering]: Metrics|complexity mea-sures, performance measures

Keywords

Commenting, Complexity Metrics, Halstead's E, Software Maintainence, LOC, Software Science

1. INTRODUCTION

An appropriate analogy to understand the importance of several phases in the development life cycle of a software system is that of a car. It takes a relatively smaller period of time to actually build it but after that, while it is in use, maintenance is of utmost importance. Software maintenance is the most expensive activity in the life cycle of a system. In [4], Robert L. Glass introduces the \60/60 rule" about software. He argues that software maintenance accounts for 40% to 80% of the total cost incurred to develop a system and use it over a period of time. A popular misconception about software maintenance is that it is only limited to cor-recting the errors that were made during the development

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00.

phase. [4] argues that enhancement is responsible for 60% of the entire maintenance cost (hence the \60/60 rule") while only 17% of the cost is allocated for error correction.

The need for software maintenance and the e ects of such maintenance on the actual product can be summarized by the rst two laws of software evolution as proposed by Lehman and Belady in [2]. Many of the 8 laws that were laid down in the last revision made to the original laws have not yet been validated by several studies. For open source software, few of the laws stand invalidated. However, almost all the studies validate the rst and the second law namely Law of Continuing Change and Law of Increasing Complexity. The rst law states that a system must continually adapt (en-hancements made over a period of time) or it becomes less satisfactory to use over time. This captures why software maintenance is such an essential part of the development lifecycle. The second law states that every change that is made increases the complexity of the system.

The complexity of a software system plays an important role in determining the maintenance costs. Over time soft-ware systems have grown in size. The software for the Apollo project of the 60's had 600,000 lines of code. Today, widely used software products like Windows 7 or 8 comprise of close to 40 to 50 million lines of code. The importance of measuring the inherent complexity of a software system is best re ected in this statement by Bill Hewlett of Hewlett-Packard, \You cannot manage what you do not measure." The complexity of a software is an undesirable property and represents the e ort required to read and understand the software. Higher the complexity, more challenging it is to change the system. Product and project metrics do pro-vide some information about the inherent complexity of a software system but since they are based on the external behavior of the system, the software system is considered as a black box in the sense that the actual design and code of the system are not studied in detail. In contrast, complex-ity metrics are the tools that capture the complexity of the source code of a software.

Through this work, we aim to provide a comprehensive literature review of the research carried out with the aim of evaluating the e ectiveness of various complexity met-rics for measuring various parameters such as code quality, programmer productivity, ease of change among other im-portant characteristics. We start by providing background information about the various code metrics that are widely employed both in the industry and academic research. It is followed by discussion about the levels of detail of a soft-ware project that these metrics are able to capture and their

correlation to one another. We focus our attention on LOC and cyclomatic complexity metrics since these are the most widely used software metrics. We then discuss in detail how LOC, a complexity metric conceived in the 1960's, captures certain aspects of software development. We attempt to nd if there are metrics apart from code metrics which give sim-ilar results if not better. Through the discussion of various works related to complexity metrics we aim to answer a few questions-

RQ1) Do all code metrics re ect the inherent complexity in a system to the same extent or does a particular metric outperform the others?

RQ2) Are there metrics which can predict software de-fects better compared to code metrics?

RQ3) Are software metrics good evaluators of software quality? Are there any alternatives to it?

1. BACKGROUND

2.1        Complexity Metrics

Complexity metrics capture the complexity of executable code. Certain metrics are de ned at the le level while other are de ned at the level of procedures. So these metrics cap-ture the internal complexity of a single procedure as well as any larger entity that said procedure might be a part of with data owing in and out of the procedure.