Application Of Software Metrics Research Articles

Exploring the Use of Software Metrics in Saudi Enterprises

This study was aimed to evaluate the application of software metrics used by the software enterprises present in Saudi Arabia. Extensive literature reviews were conducted to comprehend the current body of knowledge on the use of software metrics in Saudi enterprises. These literature review and studies elapsed approximately two decades. Based on the drawbacks, shortcomings, and fallacies of the existing studies a series of interview questionnaires were developed. Interviews were conducted for collection of real-time and actual data. Around seven Saudi enterprises were selected, and each enterprise was considered and regarded as a unit, and the manager of the enterprise was acting as a unit for our case study. 40 managers were interviewed, and their responses were analyzed. Respondents' responses indicate that the software is useful enough to support business processes. In an attempt to assess the complexity of implementing this software, effective feedback was received, suggesting that there is a lack of communication between the developers and managements’ intent. Moreover, the findings of this study showed that the organization need to give more attention to quality and productivity management. In addition, the results indicate that when agile development is undertaken through software effectiveness, the enterprise's services are implemented appropriately.

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

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

Lessons Learnt from Gauging Software Metrics of Cabin Software in a Commercial Airliner

In order to achieve high safety standards, avionic software needs to be developed with very high requirements regarding safety, reliability, and determinism as well as real-time constraints, which are often in conflict with the development of maintainable software systems. Nevertheless, the ability to change the software of an airplane is of increasing importance, since it consists of a multitude of partially hardware-specific subsystems which may need replacement during a plane’s lifespan of typically numerous decades. Thus, as a first step towards optimizing maintainability of avionic software we have benchmarked the cabin software of a commercial airliner with common software metrics. Such a benchmarking of avionic software contributes valuable insights into the current practice of developing critical software and the application of software metrics in this context. We conclude from the obtained results that it is important to pay more attention to long-term maintainability of aviation software. Additionally we have derived some initial recommendations for the development of future avionic software systems.

Aspects of software metrics database design

There exists a lot of methodology hints, software inspection and review handbooks and metrics tools to support the efficient application of software metrics. The analysis of the different evaluation, counting and measurement results should be supported by database techniques to keep control of the software process. This paper describes the different sources of metrics data and addresses the issue of an effective handling of these data in a unified data model. A first approach is presented for a sample of measurement tasks and applications. It reflects ongoing research in identifying fundamental principles of software metrics database design. Copyright © 1998 John Wiley & Sons Ltd

Development and Application of an Automated Source Code Maintainability Index

When software maintenance results in changing the source code, the change frequently occurs in an undisciplined manner that results in source code that is inherently more difficult to maintain. The long-term effect may be thought of as a downward spiral that culminates in virtually ‘unmaintainable’ code where it is more cost effective to just start again. Too often, software personnel and managers, aware that the code is becoming less maintainable, have been unable to estimate with useful accuracy the degree to which maintainability has diminished. The result is that they either continue to waste time and money maintaining code which is effectively unmaintainable, or they opt to live with what seems to be bad code, not touching it for fear of breaking it. To avoid this state of affairs, software developers need to be able to quanitify both the current level of software maintainability and the impact on it of any given change. This paper discusses the application of software metrics as a tool for quantifying code maintainability and, by extension, for making decisions. The first part of the discussion focuses on deriving a minimal set of easily calculated metrics which, when taken together, can produce a single-valued quantification (or index) of code maintainability. Case studies are then presented which serve to illustrate not only the degree to which software can degrade over time, but how this ‘maintainability index’ (MI) can be used to quantify maintainability and aid decision making. Finally, a methodology for making metric assessments readily available to software personnel is presented so that they can now easily integrate maintainability metrics into maintenance (and development) processes. As a result, the downward spiral of code degradation becomes at least recognizable, hopefully less precipitous, and perhaps avoidable entirely. © 1997 by John Wiley & Sons, Ltd.

Avoiding metric monsters: A design metrics approach

Metric monsters are stumbling blocks that prevent software metrics-guided methodologies from attaining product and process improvement. Metric monsters can occur during the identification, collection or application of software metrics. In our research, we have developed and tested our design metrics over a five-year period and have found them to be excellent predictors of error-prone modules. Based on this research, we will identify some of the monsters that occur in the quantitative analyses of software and its development processes, and present our approach in formulating a design metrics model that avoids these monsters. This model consists of software tools, guidelines and actions for the application of software design metrics.

Software metrics for the Boeing 777: a case study

This article describes rapid, midstream introduction of elementary software metrics into a large engineering-development programme. It is presented as a case study for use by organizations considering deployment of software metrics. The 777 airplane, under development by The Boeing Company, will contain over two million lines of newly-developed source code. The 777 marks the first time The Boeing Company has applied software metrics uniformly across a new commercial-airplane programme. This was done to ensure simple, consistent communication of information pertinent to software schedules among Boeing, its software suppliers, and its customers-at all engineering and management levels. In the short term, uniform application of software metrics has resulted in improved visibility and reduced risk for 777 on-board software. Looking to the longer term, the metric information collected provides a basis for analysis of internal and supplier processes, and it will serve as a baseline for future commercial airplane programmes of The Boeing Company.

Software metrics: A critical evaluation and an application to Pascal

This paper is made up of two parts. The first is critical assessment of current models for software metrics, namely Halstead's and McCabe's. The two approaches are deeply and critically examined in order to point out their weakness, both in the underlying theory and in their experimental validation. The second part describes an application of software metrics to Pascal, and proposes four different counting strategies. Finally, experimental results are given. The best counting strategy is chosen depending on the length of the program analyzed and a possible correlation between the main models is checked.

Software Science Applied to APL

Previous attempts to apply Halstead's software metrics to APL have led to inconsistent and counter-intuitive results. This work is a further investigation into the application of software metrics to APL to try to resolve some of the inconsistency. The effect of variations in the counting rules on values calculated for the software metrics was studied. These rules were used to analyze a set of programs from a previous study. In addition, a large number of APL programs from a university environment were analyzed. Evidence is presented that verifies that APL has a higher language level than any other common programming language previously studied. Counting monadic and dyadic uses of the same APL symbol as an instance of a different operator was found to have a significant effect on the language level calculated for APL. However, decomposing derived APL functions into separate operators did not seem to have a significant effect on language level.