Complexity Metrics

Empirical work supporting the hypothesis that simple size metrics and complexity metrics are good predictors of fault-prone modules have been published in the past. Some studies have also shown that contrary to common belief complexity measures are not always better predictors than simple size metrics. All of these studies share one characteristic – they measure size, complexity and number of faults at the granularity of at least modules. In this work we compare the relative ability to predict the number of faults and fault-proneness of simple size metrics, such as Lines of Code (LOC), and complexity metrics. The caveat of our empirical investigation is that we seek evidences to compare the metrics on a level of granularity smaller than modules; we do it for segments of code that implement a particular software testing requirement. Our data show that complexity measures are better predictors of the number of faults than simple size metrics at that granularity level.

Information overload is a new challenge in e-commerce sites. The problem refers to the fast growing of information that lead following the information flow in real world be impossible. Recommender systems, as the most successful application of information filtering, help users to find items of their interest from huge datasets. Collaborative filtering, as the most successful technique for recommendation, utilises social behaviours of users to detect their interests. Traditional challenges of Collaborative filtering, such as cold start, sparcity problem, accuracy and malicious attacks, derived researchers to use new metadata to improve accuracy of recommenders and solve the traditional problems. Trust based recommender systems focus on trustworthy value on relation among users to make more reliable and accurate recommends. In this paper our focus is on trust based approach and discuss about the process of making recommendation in these method. Furthermore, we review different proposed trust metrics, as the most important step in this process.

Summary Business Process Models (BPMs), often created using a modeling language such as UML activity diagrams, Event- Driven Process Chains Markup Language (EPML) and Yet Another Workflow Language (YAWL), serve as a base for communication between the stakeholders in the software development process. In order to fulfill this purpose, they should be easy to understand and easy to maintain. For

Viewshed calculation can play an important role in urban and natural resource planning. However, difficulties exist in incorporating built structures in viewshed computation. These features are rarely reflected in available elevation maps and adding them can be complicated as their locations, shapes, and heights are often uncertain. This study examined the impact of generalizing building locations and heights on viewshed properties. We used a geographic information system and high resolution data to assess how viewsheds, generated with actual building footprints and heights, differ from viewsheds generated from generalized building locations and uniform heights. We measured differences among viewsheds created with different approaches in terms of area and landscape complexity. Viewsheds generated using uniform heights and actual footprints differed significantly from the most accurate viewsheds in their areal extents and in the areas of some land use classes. Viewsheds produced using estimated locations combined with both realistic and uniform heights differed significantly from viewsheds created with accurate data in their areal extents and areas most land use types. Viewsheds produced using estimated locations also differed significantly from more accurate viewsheds in both complexity metrics assessed. Viewsheds produced using accurate locations and uniform heights differed significantly in one complexity metric, richness, but not in a second, diversity. Therefore, it may be feasible to generalize building heights when diversity and the areas of some specific land use classes are central to viewshed analysis, but generalizing building locations is less advisable. When viewshed areal extents are critical, location or height generalization may be ill-advised.

The problem of cost estimation in software engineering has been addressed by several researchers. Research shows that among many factors that affect the development cost, size of the product plays an important role. In addition to the size, product properties like complexity, cohesion and coupling are also mentioned as cost factors. We focus on the relationship between complexity of a

Empirical work supporting the hypothesis that simple size metrics and complexity metrics are good predictors of fault-prone modules have been pub- lished in the past. Some studies have also shown that contrary to common belief complexity measures are not always better predictors than simple size metrics. All of these studies share one characteristic ñ they measure size, complexity and number of faults at the granularity of at least modules. In this work we compare the relative ability to predict the number of faults and fault-proneness of simple size metrics, such as Lines of Code (LOC), and complexity metrics. The caveat of our empirical investigation is that we seek evidences to compare the metrics on a level of granularity smaller than modules; we do it for segments of code that im- plement a particular software testing requirement. Our data show that complexity measures are better predictors of the number of faults than simple size metrics at

Three software complexity measures (Halstead's E, McCabe's u(G), and the length as measured by number of statements) were compared to programmer performance on two software maintenance tasks. In an experiment on understanding, length and u(G) correlated with the percent of statements correctly recalled. In an experiment on modification, most significant correlations were obtained with metrics computed on modified rather than

A large number of real networks are characterized by two fundamental properties: they are small world and scale-free. A recent paper demonstrated that the structure of many complex networks is also self-similar under a length-scale transformation, and calculated their fractal dimension using the “box counting” method. We studied nine large object-oriented software systems, finding that the graphs associated to these networks are self-similar. We also studied the time evolution of the fractal dimension during system growth, finding a significant correlation between the fractal dimension and object-oriented complexity metrics known to be correlated with software fault-proneness. Thus, in software systems the fractal dimension could be considered as a measure of internal complexity, and consequently of the system quality.

Cascading style sheets (CSS) is a Web-based style sheet language that is used for the presentation of Web documents. CSS has advanced from CSS1 to CSS3.and extensions to CSS known as CSS pre-processors have also emerged in the last few years. As is the case with regular software, CSS have inherent complexity that keeps on increasing with age which is undesirable, and metrics are needed to measure with the aim of controlling it. Although several Web metrics have been proposed in the literature, the area of stylesheets is still lagging. Findings show that few CSS-related metrics exist, and there is no evidence of proof for their mathematical soundness through the popularly known frameworks such as Briand framework and Weyuker's properties. In addition, they have not been empirically validated. In order to address this gap, future studies should focus on defining and validating new metrics for CSS and its pre-processors.

Complexity metrics play an important role in software development; they are reducing the costs during almost the whole development process. There is a growing demand for measuring the complexity of large systems with keeping the consistency of the results regardless of the diversity of the programming languages. In this article we present a general software measurement process on .NET basis

It is widely accepted that sizing or predicting the volumes of various kinds of software deliverable items is one of the first and most dominant aspects of software cost estimating. Most of the cost estimation model or techniques usually assume that software size or structural complexity is the integral factor that influences software development effort. Although sizing and complexity measure

Abstract Functional validation of System Level Models, such as those modeled with SystemC, is an important and complex problem. One of the problems in their functional validation is the test case generation with good coverage and higher potential to find faults in the design. We propose a coverage-directed test generation framework for system level design validation by combining the synchronous language ESTEREL, and its advanced verification capability, with C++ based system level language SystemC. The main ...

Mixed model manufacturing systems are increasingly used to meet global competition by providing a broad variety of products to customers. The increase of product variety adds more complexity to production processes, thus, leading to a negative effect on the performance of production processes. Therefore, it is of great interest to effectively measure such complexity and to quantify its effect on manufacturing system performance. In this paper, a set of complexity metrics are proposed for measuring the complexity of different elements in a manufacturing system. These metrics were defined by constructing a linkage with the communication system's framework. Different from those existing complexity measures defined in the literature, this paper considers production quality into the measure of the process capability on handling the complexity induced by the input demand variety. Examples are given in the paper to discuss different properties of the defined metrics and their potential applications.

Maintainers face the daunting task of wading through a collection of both new and old revisions, trying to ferret out revisions which warrant personal inspection. One can rank revisions by size/lines of code (LOC), but often, due to the distribution of the size of changes, revisions will be of similar size. If we can't rank revisions by LOC perhaps we can rank by Halstead's and McCabe's complexity metrics? However, these metrics are problematic when applied to code fragments (revisions) written in multiple languages: special parsers are ...