Showing papers on "Halstead complexity measures published in 2014"

Metrics for evaluating the quality of service-oriented design

Abstract: Service-orientation is a modern approach in building software systems and it has been applied successfully to develop of many domains of software systems. The service-oriented design is the key phase, and assessing the quality at this level is very essential to reduce the cost and effort of the implementation phase and enhance the quality of software applications. In order to assess the quality of service-oriented design many metrics are proposed in the literature but these metrics are constructed based on the characteristic of the previous development approaches such as object-oriented and they do not consider the service that is built from other services. Furthermore, these metrics do not consider the indirect relationships between service-oriented elements. However, a comprehensive quality measurement for service-oriented design is still lacking. A set of metrics is proposed during this study as part of an attempt to evaluate the coupling, cohesion and complexity of service-oriented design and theoretically validated. Moreover, this work can be used as a first step to propose a comprehensive quality measurement model for service-oriented design.

How difficult are novice code writing tasks?: a software metrics approach

Abstract: In this paper we report on an empirical study into the use of software metrics as a way of estimating the difficulty of code writing tasks. Our results indicate that software metrics can provide useful information about the difficulties inherent in code writing in first year programming assessment. We conclude that software metrics may be a useful tool to assist in the design and selection of questions when setting an examination.

An Investigation of Object-Oriented and Code-Size Metrics as Dead Code Predictors

Abstract: In case of biological organisms, death is unambiguous. It is not the same in software engineering, where death assumes a different meaning. For example, this term can be used to indicate source code that can be removed being it unnecessary for a given software system. In this paper, the early achievements of an empirical investigation on software metrics as predictors for dead code methods in object-oriented (OO) source code have been presented. OO design metrics and traditional code-size metrics have been considered. Data on one open source software system implemented in Java have been collected. The results suggest that five of these metrics can be used as indicators for dead code methods in OO software systems.

On Automatically Collectable Metrics for Software Maintainability Evaluation

Abstract: In our work with industry partners as well as with students in seminars we noticed that many people often stick to "aged" metrics when they want to evaluate the maintainability of software. They consider these metrics for this purpose without second thoughts, because the metrics are so present that almost every developer has at least heard the name and has some kind of knowledge about it. This smattering leads to an unreflected usage of theses metrics today without fully understanding them. To find suitable metrics for maintainability evaluation, we did a preliminary study, which indicated that still McCabe, Halstead and some kind of lines of code measurement dominate maintainability evaluation. We will discuss examples that question the ability of those metrics to reliably and automatically evaluate maintainability of software. Instead we will present metrics we consider more suitable to make solid statements about software maintainability. We conclude that our proposed metrics are better evaluators for maintainability because their impact on maintenance is clearer to interpret. Future work on metrics should carefully consider the use of "aged" metrics.

Measuring Maintainability Index of a Software Depending on Line of Code Only

Abstract: Maintainability Index (MI) has been proposed to calculate a single number that expresses the maintainability of a system MI is calculated as a factored formula consisting of Lines of Code (LOC), Cyclomatic Complexity (CC)and Halstead Volume (HV) In this paper, we present a new method to find MI with respect to LOC only To validate the method Measuring Maintainability Index Software (MMIS) is developed, that first finds MI with respect to (LOC, CC, and HV); secondly find MI with respect to LOC only As the result has been compared they were closed but the new method was easy to understand, fast to count, and independent on the program language In addition to many well-known programs, the MMIS was used to test itself and the result demonstrates that the program used to calculate MI value with respect to LOC only tend to be maintainable while the lexical analyzer the major step in calculating MI with regard to (LOC, HV, CC) is difficult to maintain

Instability and Abstractness Metrics Based on Responsibility

Abstract: Over the last few decades, a lot of research has been done to measure software quality including using high-level design metrics to measure the quality of the design. R. C. Martin's metrics are some of the best-known software package metrics. Martin began with a set of object oriented design principles and designed his metrics based on these principles. In this paper we begin with Martin's principles and use them to modify his instability and abstractness metrics which were defined to identify poorly designed packages which are hard to maintain and reuse. We modify Martin's metrics based on the concept of responsibility, our motivation is that packages with different levels of responsibility should have different weights with respect to the instability and abstraction metrics. We present a case study to validate the modified metrics, the comparative study shows the differences between the proposed metrics and Martin's metrics. We found that the proposed instability and abstractness metrics are very promising and lead to improved results.

Evaluating the impact of software metrics on defects prediction. Part 2

Abstract: Software metrics are used as indicators of the quality of the developed software. Metrics can be collected from any software part such as: code, design, or requirements. In this paper, we evaluated several examples of design coupling metrics. Analysis and experiments follow hereinafter to demonstrate the use and value of those metrics. This is the second part for a paper we published in Computer Science Journal of Moldova (CSJM), V.21, N.2(62), 2013 [19]. We proposed and evaluated several design and code coupling metrics. In this part, we collected source code from Scarab open source project. This open source is selected due to the availability of bug reports. We used bug reports for further analysis and association where bugs are used to form a class for classiflcation and prediction purposes. Metrics are collected and analyzed automatically through the developed tool. Statistical and data mining methods are then used to generalize some flndings related to the collected metrics. In addition classiflcation and prediction algorithms are used to correlate collected metrics with high level quality attributes such as maintainability and defects prediction.

Software defect prediction using machine learning on test and source code metrics

Abstract: Context. Software testing is the process of finding faults in software while executing it. The results of the testing are used to find and correct faults. Software defect prediction estimates where faults are likely to occur in source code. The results from the defect prediction can be used to opti- mize testing and ultimately improve software quality. Machine learning, that concerns computer programs learning from data, is used to build pre- diction models which then can be used to classify data. Objectives. In this study we, in collaboration with Ericsson, investigated whether software metrics from source code files combined with metrics from their respective tests predicts faults with better prediction perfor- mance compared to using only metrics from the source code files. Methods. A literature review was conducted to identify inputs for an ex- periment. The experiment was applied on one repository from Ericsson to identify the best performing set of metrics. Results. The prediction performance results of three metric sets are pre- sented and compared with each other. Wilcoxon’s signed rank tests are performed on four different performance measures for each metric set and each machine learning algorithm to demonstrate significant differences of the results. Conclusions. We conclude that metrics from tests can be used to predict faults. However, the combination of source code metrics and test metrics do not outperform using only source code metrics. Moreover, we conclude that models built with metrics from the test metric set with minimal infor- mation of the source code can in fact predict faults in the source code.

An Effective Implementation of Improved Halstead Metrics for Software Parameters Analysis

Abstract: The software metrics area has a lack of reports about metrics usage and real applicability of those metrics. In this sense, the main goal of this section is briefing review research in software metrics regarding source code in order to guide the research in software quality measurement. The metrics review is organized in two ages: before 1991, where the main focus was on metrics based on the complexity of the code and after 1992, where the main focus was on metrics based on the concepts of Object Oriented (OO) systems. This paper focus on the specific improvements or enhancements in the halstead metrics in terms of object oriented paradigm.

Detection of Software Anomalies Using Object-oriented Metrics

Abstract: The development of quality software has always been the aim of many studies in past years, in which the focus was on seeking for better software production with high effectiveness and quality. In order to evaluate software quality, software metrics were proposed, providing an effective tool to analyze important features such as maintainability, reusability and testability. The Chidamber and Kemerer metrics (CK metrics) are frequently applied to analyze Object-Oriented Programming (OOP) features related to structure, inheritance and message calls. The main purpose of this article is to gather results from studies that used the CK metrics for source code evaluation, and based on the CK metrics, perform a review related to software metrics and the values obtained. Results on the mean and standard deviation obtained in all the studied papers is presented, both for Java and C++ projects. Therefore, software anomalies are identified comparing the results of software metrics described in those studies. This article contributes by suggesting values for software metrics that, according to the literature, can present high probabilities of failures. Another contribution is to analyze which CK metrics are successfully used (or not) in some activities such as to predict proneness error, analyze the impact of refactoring on metrics and examine the facility of white-box reuse based on metrics. We discovered that, in most of the studied articles, CBO, RFC and WMC are often useful and hierarchical metrics as DIT and NOC are not useful in the implementation of such activities. The results of this paper can be used to guide software development, helping to manage the development and preventing future problems.

Correlations and Weights of Maintainability Index (MI) of Open source Linux Kernel Modules

Abstract: Software development and usage become very important in many aspects of our lives, so that the application of software metrics becomes more important. Software metrics are used to give valuable information for the development of software. This paper focus on the study of the maintainability of an open source operating system “Linux”. Computing the relative weight of each maintainability parameter. The research was conducted on Linux Kernel modules (V.3.9.2). The research performed on 837 functions from selected modules to compute a maintainability index “MI” for each function and module. Also calculate the correlation between each parameter for Maintainability Index (MI) with the other parameters and with the MI itself. The parameters of MI are Line of Code (LOC), Cyclomatic Complexity (CC), and Halstead Volume (HV). Practically approved that, first the Line of Code and Cyclomatic Complexity values are distributed normally; but Halstead Volume is distributed uniformly. Secondly, there is an interconnection between Line of Code, Cyclomatic Complexity, Halstead Volume and Maintainability Index. Finally the most important parameter which affects maintainability index is Line of Code, then Cyclomatic Complexity and lastly the Halstead Volume. General Terms Software Quality

Integration of Metric Tools for Software Testing

Abstract: Software metric is a mathematical definition mapping the entities of a software system to numeric metrics values. Furthermore, we understand a software metrics tool as a program which implements a set of software metrics definitions. There are number of software metric tools available, use different methods to assess metric based software systems and hence project different results. The results are thus tool dependent and are in question for validation. Here an attempt is made to integrate four different object oriented free metric tools. A study has been done to calculate the metrics values using the same set of standard metrics for a software projects. The results have been presented and discussed here for showing the variations in results from different tools for same metrics. Measurements show that, for the same software system and metrics, the metrics values are tool depended. This paper will include two metrics which were not measured while integrating metrics tools. For this we will focus and study on integration of Vizz Analyzer and OOMeter metric tools with other metrics tools.

Pragmatic Approach to Component Based Software Metrics Based On Static Methods

Abstract: Component-Based Software Engineering (CBSE) is an emerging technique for reuse of software. This paper presents the component based software metrics by investigating the improved measurement techniques. Two types of metrics are used: static metrics and dynamic metrics. This research work presents the measured metric value for Complexity metrics and Criticality metric. The static metrics applied to the E-healthcare application which is developed with the reusable software components. The value of each metric is analyzed with the application. The metric measured value is the evidence for the reusability, good maintainability of component based software systems.

An Axiomatic Evaluation of Software Complexity Metrics for Prototype based Object Oriented Systems

Abstract: Traditional Software metrics are both tangible such as LOC and intangible such as Amount of Effort and Software Engineering experience etc. For contextual and intangible metrics, it is generally assumed that these metrics can be generalized over a universal set of domains. In our opinion, the intuitive nature of intangible and intrinsically intuitive metrics warrant a revisit of theoretical foundations on which such metrics are based. This is especially true in case of Prototype based software modeling, which being a class-less system has entirely different theoretical foundations. Also the sizes of the project on which such metrics are applied have a bearing on complexity. In this paper we have proposed an axiomatic approach towards evaluation of Software Complexity metrics. These axioms are based on Measurement theory and provide us with theoretical underpinnings based upon which, metrics suitable for class based and class-less Object Oriented approaches can be defined. Also introduced in this paper is the notion of a viewpoint which helps us to resolve the problems introduced because of intuitive contextual nature of complexity. (Syed Ahsan. An Axiomatic Evaluation of Software Complexity Metrics for Prototype based Object Oriented Systems. Life Sci J 2014;11(3s):196-201). (ISSN:1097-8135). http://www.lifesciencesite.com . 29