Quality management metrics for software development

It can be argued that the quality of software management has an effect on the degree of success or failure of a software development program. We have developed a metric for measuring the quality of software management along four dimensions: requirements management, estimation/planning management, people management, and risk management. The quality management metric (QMM) for a software development program manager is a composite score obtained using a questionnaire administered to both the program manager and a sample of his or her peers. The QMM is intended to both characterize the quality of software management and serve as a template for improving software management performance. We administered the questionnaire to measure the performance of managers responsible for large software development programs within the US Department of Defense (DOD). Informal verification and validation of the metric compared the QMM score to an overall program-success score for the entire program; this resulted in a positive correlation.     

软件适应性度量方法研究*

为了能够通过软件的源代码度量面向对象软件的适应性,提出了一个包含七个具体度量指标的软件适应性度量模型,并开发了在Java软件中提取各度量指标的支持工具FlexTool;为了避免通过手动调整大量软件源代码的方式度量软件适应性,使研究人员能够在不太了解软件实现细节的情况下对适应性进行度量,提出了将该适应性模型应用于软件版本的演化从而度量软件适应性的方法,并通过著名开源软件Ant的版本演化对该方法的合理性进行了验证。     

Semantic metrics for software products

Like all engineering disciplines, software engineering relies on quantitative analysis to support rationalized decision making. Software engineering researchers and practitioners have traditionally relied on software metrics to quantify attributes of software products and processes. Whereas traditional software metrics are typically based on a syntactic analysis of software products, we introduce and discuss metrics that are based on a semantic analysis: our metrics do not reflect the form or structure of software products, but rather the properties of their function. At a time when software systems grow increasingly large and complex, the focus on diagnosing, identifying and removing every fault in the software product ought to relinquish the stage to a more measured, more balanced, and more realistic approach, which emphasizes failure avoidance, in addition to fault avoidance and fault removal. Semantic metrics are a good fit for this purpose, reflecting as they do a system’s ability to avoid failure rather than its proneness to being free of faults.     

Semantic metrics for software testability

Software faults that infrequently affect output cause problems in most software and are dangerous in safety-critical systems. When a software fault causes frequent software failures, testing is likely to reveal the fault before the software is released; when the fault “hides” from testing, the hidden fault can cause disaster after the software is installed. During the design of safety-critical software, we can isolate certain subfunctions of the software that tend to hide faults. A simple metric, derivable from semantic information found in software specifications, indicates software subfunctions that tend to hide faults. The metric is the domain/range ratio (DRR): the ratio of the cardinality of the possible inputs to the cardinality of the possible outputs. By isolating modules that implement a high DRR function during design, we can produce programs that are less likely to hide faults during testing. The DRR is available early in the software lifecycle; when code has been produced, the potential for hidden faults can be further explored using empirical methods. Using the DRR during design and empirical methods during execution, we can better plan and implement strategies for enhancing testability. For certain specifications, testability considerations can help produce modules that require less additional testing when assumptions change about the distribution of inputs. Such modules are good candidates for software reuse.     

Methodology for validating software metrics

A comprehensive metrics validation methodology is proposed that has six validity criteria, which support the quality functions assessment, control, and prediction, where quality functions are activities conducted by software organizations for the purpose of achieving project quality goals. Six criteria are defined and illustrated: association, consistency, discriminative power, tracking, predictability, and repeatability. The author shows that nonparametric statistical methods such as contingency tables play an important role in evaluating metrics against the validity criteria. Examples emphasizing the discriminative power validity criterion are presented. A metrics validation process is defined that integrates quality factors, metrics, and quality functions     

An experimental investigation of software metrics and theirrelationship to software development effort

The results are reported of an experimental study of software metrics for a fairly large software system used in a real-time application. A number of issues are examined, including the mutual relationship between various software metrics and, more importantly, the relationship between metrics and the development effort. Some interesting connections are reported between metrics and the software development effort     

Entropy metrics for software design evaluation

Several metrics for the quality assessment of a software system design are discussed. The metrics are based on the entropy function of communication information theory. The design of software systems is viewed as a trade-off between the information contained within a subsystem and the information shared among the subsystems of a given system. Since information can be shared in different ways by different system designs, we can compute the excess entropy and thereby rank different design alternatives. Consequently, the quality improvement due to reconfigurations can be determined by calculating the excess entropies for each reconfiguration.     

A case study of tracking software development using quality metrics

This paper presents a case history of Mentor Graphics using a set of quality metrics to track development progress for a recent major software release. It provides background on how Mentor Graphics originally began using software metrics to measure product quality, how this became accepted, and how these metrics later fell out of favour. To restore these metrics to effective use, process changes were required for setting quality and metric targets, and for the way the metrics are used for tracking development progress. With these process changes in place, and the addition of a new metric, the case history demonstrates that the metric set could be used effectively to indicate problems in this release and help manage changes to the plan for completion of the release. The lessons learned in this case history are presented, along with subsequent data that further validates these metrics.     

Successfully applying software metrics

The word success is very powerful. It creates strong, but widely varied, images that may range from the final seconds of an athletic contest to a graduation ceremony to the loss of 10 pounds. Success makes us feel good; it's cause for celebration. All these examples of success are marked by a measurable end point, whether externally or self-created. Most of us who create software approach projects with some similar idea of success. Our feelings from project start to end are often strongly influenced by whether we spent any early time describing this success and how we might measure progress. Software metrics measure specific attributes of a software product or a software development process. In other words, they are measures of success. It's convenient to group the ways that we apply metrics to measure success into four areas. What do you need to measure and analyze to make your project a success? We show examples from many projects and Hewlett Packard divisions which may help you chart your course     

Multiple-parameter coupling metrics for layered component-based software

Coupling represents the degree of interdependence between two software components. Understanding software dependency is directly related to improving software understandability, maintainability, and reusability. In this paper, we analyze the difference between component coupling and component dependency, introduce a two-parameter component coupling metric and a three-parameter component dependency metric. An important parameter in both these metrics is coupling distance, which represents the relevance of two coupled components. These metrics are applicable to layered component-based software. These metrics can be used to represent the dependencies induced by all types of software coupling. We show how to determine coupling and dependency of all scales of software components using these metrics. These metrics are then applied to Apache HTTP, an open-source web server. The study shows that coupling distance is related to the number of modifications of a component, which is an important indicator of component fault rate, stability and subsequently, component complexity.

软件度量在基于TSP模型开发过程中的应用研究

介绍了基于TSP的软件质量开发平台SQCP的系统结构,以及软件度量在SQCP平台中的应用。在规模评定中,软件度量将问题进行分解为一组小的更易管理的问题,利用3点或期望值对规模进行估算;在风险问题分析和管理中,根据风险的类型和优先级对风险进行排序,并根据中止线划分可忽略的风险和重要的风险;在错误缺陷跟踪以及进度跟踪中,通过缺陷率和任务指标来跟踪项目的进展。以SQCP第一个模块“小组启动”模块为度量对象给出了3种度量应用的实例数据和效果分析。     

SPDW+: a seamless approach for capturing quality metrics in software development environments

Among the key factors for the success of a metrics program are the regularity of metrics collection, a seamless and efficient data collection methodology, and the presence of non-intrusive automated data collection tools. This paper presents the software process data warehousing architecture SPDW+ as a solution to the frequent, seamless, and automated capturing of software quality metrics, and their integration in a central repository for a full range of analyses. The striking features of the SPDW+ ETL (data extraction, transformation, and loading) approach are that it addresses heterogeneity issues related to the software development context, it is automatable and non-intrusive, and it allows different capturing frequency and latency strategies, hence allowing both analysis and monitoring of software metrics. The paper also provides a reference framework that details three orthogonal dimensions for considering ETL issues in the software development process context, used to develop SPDW+ ETL. The advantages of SPDW+ are: (1) flexibility to meet the requirements of the frequent changes in SDP environments; (2) support for monitoring, which implies the execution of frequent and incremental loads; (3) automation of the complex and time-consuming task of capturing metrics, making it seamless; (4) freedom of choice regarding management models and support tools used in projects; and (5) cohesion and consistency of the information stored in the metrics repository which will be used to compare data of different projects. The paper presents the reference framework, illustrates the key role played by the metrics capturing process in a metrics program using a case study, and presents the striking features of SPDW+ and its ETL approach, as well as an evaluation based on a prototype implementation.     

软件维护性及其度量

维护性是软件的重要质量特性。介绍了Martin和McClure、Gilb、Kurt D.Walker、IEEE std 982.1_1998及ISO/IEC9126_2000标准等提出的软件维护性度量方法，指出了今后研究的发展方向，对进行软件维护性的分析与设计工作具有指导意义。     

量化迭代和增量软件过程的一组UML度量

迭代和增量把软件开发分成可以重复的不同活动的流程,是现代软件开发过程的基本特征。迭代地执行每个流程就相应地增加软件产品,直至完成产品的开发。为定量地指导和管理迭代式增量软件开发,提出了基于UML模型的一组软件度量。这组度量针对UML的可视化以及一致地应用在多个软件开发活动的特性,对UML各种图所表达的信息量、可视化大小以及复杂性三个方面度量软件制品,进而度量迭代的增量。分析并通过案例讨论了这组度量的有效性及其在软件项目管理中的应用。     

Implementing effective software metrics programs

Increasingly organisations are foregoing an ad hoc approach to metrics in favor of complete metrics programs. The authors identify consensus requirements for metric program success and examine how programs in two organisations measured up     

Getting started on software metrics

The principles on which the Software Management Metrics system is based are discussed. The system collects metrics at regular intervals and represents current estimates of the work to be done, the work accomplished, the resources used, and the status of products being generated. The lessons learned in the eight years since Software Management Metrics were first imposed on the US Air Force's software contractors are reviewed     

Statistical methods for the analysis of software metrics data

The authors present case study applications of statistical methods for the analysis of software metrics data which recognize the discrete nature of such data. A procedure is also described which allows a component of complexity independent of size to be extracted from the usual Halstead's metrics and McCabe's cyclomatic number. The methods described are different from the usual regression and non-parametric methods previously applied to software metrics. With the software quality practitioner in mind, the paper explores how these new methods are helpful in understanding the relationships between software metrics.     

Evaluating design metrics on large-scale software

Design-quality metrics that are being developed for predicting the potential quality and complexity of the system being developed are discussed. The goal of the metrics is to provide timely design information that can guide a developer in producing a higher quality product. The metrics were tested on projects developed in a university setting with client partners in industry. To further validate the metrics, they were applied to professionally developed systems to test their predictive qualities. The results of applying two design metrics and a composite metric to data from a large-scale industrial project are presented