SIMPLIFIED READABILITY METRICS

This paper describes a new approach to measuring the complexity of software systems with considering their readability. Readability Metrics were first proposed by Chung and Yung 181 in 1990. Software industry uses software metrics to measure the complexity of software systems for software cost estimation, software development control, software assurance, software testing, and software maintenance [3], [71, [9], 151, [18]. Most of the software metrics measure the software complexity by one or more of the software attributes. We usually class@ the software attributes that software metrics use for measuring complexity into three categories: size, control flow, and data flow [5], f71. All the three categories concern with the physical activities of software development. Readability Metrics have been outstanding among the existing software complexity metrics for taking nonphysical software attributes, like readability, into considerations [8]. The applications of Readability Metrics are good in indicating the additional efforts required for less readable software systems, and help in keeping the software systems maintainable. However, the numerous metrics and the complicated formulas in the family usually make it tedious to apply Readability Metrics to large scale software systems. In this paper, we propose a simplified approach to Readability Metrics. We reduce the number of required measures and keep the considerations on software readability. We introduce our Readability model in a more formal way. The Readability Metrics preprocesses algorithm is developed with compilers front-end techniques. The experiment results show that this simplified approach has good predictive power in measuring software complexity with software readability, in addition to its ease of applying. The applications of Readability Metrics indicate the readability of software systems and help in keeping the source code readable and maintainable.Information Systems Working Papers Serie

Evaluation the Quality of Software Design by Call Graph based Metrics

The prediction of software defects was introduced to support development and maintenance activities to improve the software quality by finding errors early in the software development. It facilitates maintenance in terms of effort, time and more importantly the cost prediction for software evolution and maintenance activities. In this paper, we evaluate the quality related attributes in developed software products. The software call graph model is also used for several applications in order to represent and reflect the degree of their complexity in terms of understandability, testability and maintainability efforts. The extracted metrics are investigated for the evaluated applications in correlation with bugs collected from customers bug reports. Those software related bugs are compiled into datasets files to use as an input to a data miner for classification, prediction and association analysis. Finally, the analysis results is evaluated in terms of finding the correlation between software products bugs and call graph based metrics. We find that call graph based metrics are appropriate to detect and predict software defects so that the activities of testing and maintenance stages become easier to estimate or assess after the product delivery

Component Integration Metrics and Their Evaluation

Software Engineering (SE) has been described as the discipline devoted to the design, development, and use of computer software, covering not only the technical aspects of building software systems, but also management issues develops highly complex software. The crisis in SE, due to the lack of well-defined formal processes, has led to poorly designed products with high maintenance costs and whose behavior becomes unpredictable. Component Based Software Engineering (CBSE) is currently a preferred approach to system design to overcome the crisis of SE, since it promotes software re-use, facilitates adaptability and faster system development. A component provides a function or a set of related functions, which forms a reusable program building block that can be combined with other components to form an application. A component with qualities such as, reusability, testability, modularity, complexity, proper to communicate and stability reduces maintenance costs. The components thus integrated, should be able to interoperate so that an operational application that results in reduced maintenance costs can be composed with minimal effort. Metrics are used to measure a component\u27s quality factor and there are no good metrics available to validate their effectiveness, when components are integrated. Currently, the success of projects based on the CBSE methodology relies on experts who assess software components; however, their evaluation process involves parameters that may not be measured in practice. Existing traditional metrics are inappropriate since CBSE is aimed at improving interoperability and re-usability. Size metrics based on lines of code are not applicable as component sizes may not be known a priori. Furthermore, complexities that arise due to varying nature of facets and interfaces are not addressed by traditional metrics. This thesis addresses the evaluation of a series of metrics based on complexity, criticality and dynamic behavior, in order that component integration performance can be assessed. Three suites of metrics defined by various authors have been considered for evaluation so that one could choose the best metrics to measure an integrated environment. A suite of metrics proposed by Narasimhan and Hendradjaya are classified based on the attributes of: complexity, criticality and dynamic aspects. These metrics use graph-based connectivity to represent a system of integrated components. While the complexity metrics consider the packing density of integrated components and the interaction density among the components, criticality metrics reveal the extent of binding within each component in the system. Dynamic metrics have also been collected during the execution of an application and aid the process involved in testing and maintenance. Metric related data sets have been from several benchmark programs using instrumentation programs and key inferences have been obtained; these inferences include a systematic evaluation of quality of the various metrics. Two new metrics have also been provided towards assessing the stability of the application: one metric, namely CRIT instability, calculates the instability of each component, while the second new metric, namely CRIT inheritance,counts the number of components whose children exceeds a threshold value. Both these metrics are useful to assess the stability of the application and, in addition, to determine the components in a given application that needs to be redesigned. Future work will focus on the development of a metric evaluation suite to assess the system\u27s stability as a whole, considering the role of each component in an application

Change decision support:extraction and analysis of late architecture changes using change characterization and software metrics

Software maintenance is one of the most crucial aspects of software development. Software engineering researchers must develop practical solutions to handle the challenges presented in maintaining mature software systems. Research that addresses practical means of mitigating the risks involved when changing software, reducing the complexity of mature software systems, and eliminating the introduction of preventable bugs is paramount to today’s software engineering discipline. Giving software developers the information that they need to make quality decisions about changes that will negatively affect their software systems is a key aspect to mitigating those risks. This dissertation presents work performed to assist developers to collect and process data that plays a role in change decision-making during the maintenance phase. To address these problems, developers need a way to better understand the effects of a change prior to making the change. This research addresses the problems associated with increasing architectural complexity caused by software change using a twoold approach. The first approach is to characterize software changes to assess their architectural impact prior to their implementation. The second approach is to identify a set of architecture metrics that correlate to system quality and maintainability and to use these metrics to determine the level of difficulty involved in making a change. The two approaches have been combined and the results presented provide developers with a beneficial analysis framework that offers insight into the change process

SIMPLIFIED READABILITY METRICS

This paper describes a new approach to measuring the complexity of software systems with considering their readability. Readability Metrics were first proposed by Chung and Yung 181 in 1990. Software industry uses software metrics to measure the complexity of software systems for software cost estimation, software development control, software assurance, software testing, and software maintenance [3], [71, [9], 151, [18]. Most of the software metrics measure the software complexity by one or more of the software attributes. We usually class@ the software attributes that software metrics use for measuring complexity into three categories: size, control flow, and data flow [5], f71. All the three categories concern with the physical activities of software development. Readability Metrics have been outstanding among the existing software complexity metrics for taking nonphysical software attributes, like readability, into considerations [8]. The applications of Readability Metrics are good in indicating the additional efforts required for less readable software systems, and help in keeping the software systems maintainable. However, the numerous metrics and the complicated formulas in the family usually make it tedious to apply Readability Metrics to large scale software systems. In this paper, we propose a simplified approach to Readability Metrics. We reduce the number of required measures and keep the considerations on software readability. We introduce our Readability model in a more formal way. The Readability Metrics preprocesses algorithm is developed with compilers front-end techniques. The experiment results show that this simplified approach has good predictive power in measuring software complexity with software readability, in addition to its ease of applying. The applications of Readability Metrics indicate the readability of software systems and help in keeping the source code readable and maintainable.Information Systems Working Papers Serie

A software complexity analysis tool

The project (partially) described in this paper was the result of an attempt by the Navy to use software complexity metrics to assess the complexity of Naval avionics software. In particular, the project consisted of computing a variety of software complexity metrics for CMS-2M and AYK-14 assembler source code and then analyzing the values gathered for these metrics. There are many reasons why we want to be able to measure software complexity. Managers would like to be able to estimate the time needed to perform an enhancement or the amount of resources to allocate to testing a particular piece of code or the time required to implement a given design, etc. Software metrics can be used to determine whether to modify a piece of code or rewrite it altogether. Thus, software metrics can be useful for managers as well as programmers. The Navy, being a very large organization, produces and maintains many thousands of lines of code. The ability to measure the complexity of code would lead to more effective production and maintenance of the Navy's large code base. My part in this project consisted of writing a software tool which performed analysis on source code and computed a series of software complexity metrics. The tool was designed to analyze software systems written in CMS-2M with embedded AYK-14 assembler. Because CMS-2M and AYK-14 are older and not commonly used programming languages, no commercial tool was available. This paper consists of a brief survey of software complexity metrics, a discussion of the reasons for our choices of metrics, a description and user's guide for out analysis tool, the results of the project; and conclusions

An Exploratory Investigation on the Invasiveness of Environmental Modeling Frameworks

Environmental modeling frameworks provide an array of useful features that model developers can harness when implementing models. Each framework differs in how it provides features to a model developer via its Application Programming Interface (API). Environmental modelers harness framework features by calling and interfacing with the framework API. As modelers write model code, they make framework-specific function calls and use framework specific data types for achieving the functionality of the model. As a result of this development approach, model code becomes coupled with and dependent on a specific modeling framework. Coupling to a specific framework makes migration to other frameworks and reuse of the code outside the original framework more difficult. This complicates collaboration between model developers wishing to share model code that ma y have been developed in a variety of languages and frameworks. This paper provides initial results of an exploratory investigation on the invasiveness of environmental modeling frameworks. Invasiveness is defined as th e coupling between application (i.e., model) and framework code used to implement the model. By comparing the implementation of an environmental model across several modeling frameworks, we aim to better understand the consequences of framework design. How frameworks present functionality to modelers through APIs can lead to consequences with respect to model development, model maintenance, reuse of model code, and ultimately collaboration among model developers. By measuring framework invasiveness, we hope to provide environmental modeling framework developers and environmental modelers with valuable in formation to assist in future development efforts. Eight implementations (six framework-based) of Thornthwaite, a simple water balance model, were made in a variety of environmental modeling frameworks and languages. A set of software metrics were proposed and applied to measure invasiveness between model implementation code and framework code. The metrics produced a rank ordering of invasiveness for the framework-based implementations of Thornthwaite. We compared model invasiveness results with several popular software metrics including size in lines of code (LOC), cyclomatic complexity, and object oriented coupling. To investigate software quality implications of framework invasiveness we checked for relationships between the Chidamber and Kemerer (1994) object oriented software metrics and our framework invasiveness measures. For the six framework-based implementations of Thornthwaite we found a five-fold variation in code size (LOC). We observed up to a seven-fold variation in total cyclomatic complexity, and a two to three-fold variation in object oriented coupling. For the model implementations we found that total size, total complexity, and total coupling all had a significant positive correlation. The raw count version of our invasiveness measures correlated with application size (LOC), total cyclomatic complexity, total efferent coupling (fan out) and total afferent coupling (fan in). Large size, complexity, and high levels of coupling between units (classes, modules) in a software system are often cited in software engineering as causes of high maintenance costs due to poor understandability and flexibility of the code. This study provides initial results but further investigation is desired to evaluate the utility of our invasiveness measurement approach as well as the software quality implications of framework invasiveness

Managerial Issues in Developing a Quality Metrics Program

Software quality metrics are used to determine error prone code due to excessive complexity. These results can be used to guide testing efforts and predict future maintenance needs. However, implementing a quality metrics program involves many subtle issues which complicate the development and use of a metrics methodology. Many of theses issues are managerial in nature. This paper examines some managerial elements of designing and implementing a quality metrics program. Previous studies which incorporate a metrics methodology into two different commercial environments are used to demonstrate the difficulties in implementation and approach

A method for maintaining new software

This thesis describes a novel method for perfective maintenance of software which has been developed from specifications using formal transformations. The list of applied transformations provides a suitable derivation history to use when changes are made to the software. The method uses transformations which have been implemented in a tool called the Maintainer's Assistant for the purposes of restructuring code. The method uses these transformations for refinement. Comparisons are made between sequential transformations, refinement calculi and standard proof based refinement techniques for providing a suitable derivation history to use when changes are made in the requirements of a system. Two case studies are presented upon which these comparisons are based and on which the method is tested. Criteria such as saleability, speed, ease, design improvements and software quality is used to argue that transformations are a more favourable basis of refinement. Metrics are used to evaluate the complexity of the code developed using the method. Conclusions of how to develop different types of specifications into code and on how best to apply various changes are presented. An approach which is recommended is to use transformations for splitting the specification so that original refinement paths can still be used. Using transformations for refining a specification and recording this path produces software of a better structure and of higher maintainability. Having such a path improves the speed and ease of future alterations to the system. This is more cost effective than redeveloping the software from a new specification