软件维护性及其度量

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

Using metrics to evaluate software system maintainability

Software metrics have been much criticized in the last few years, sometimes justly but more often unjustly, because critics misunderstand the intent behind the technology. Software complexity metrics, for example, rarely measure the “inherent complexity” embedded in software systems, but they do a very good job of comparing the relative complexity of one portion of a system with another. In essence, they are good modeling tools. Whether they are also good measuring tools depends on how consistently and appropriately they are applied     

产品线成本模型的比较与分析

为给软件产品线决策者应用软件产品线模型提供理论上的参考,综合分析比较了近年来的20种软件产品线模型,在对软件产品线模型的投资循环、重用方式、货币时间价值、经济函数、成本因子和重用成本等方面因素进行细致分析的基础上提出了软件产品线模型的比较框架,在该框架内着重分析了其中5种典型的软件产品线模型,对应用软件产品线开发方式的成本估算和投资分析做了细致分析,并对当前软件产品线模型时存在的问题和发展方向进行了探讨.     

Dynamic decision models for staged software product line configuration

Software product line engineering practices offer desirable characteristics such as rapid product development, reduced time-to-market, and more affordable development costs as a result of systematic representation of the variabilities of a domain of discourse that leads to methodical reuse of software assets. The development lifecycle of a product line consists of two main phases: domain engineering, which deals with the understanding and formally modeling of the target domain, and application engineering that is concerned with the configuration of a product line into one concrete product based on the preferences and requirements of the stakeholders. The work presented in this paper focuses on the application engineering phase and builds both the theoretical and technological tools to assist the stakeholders in (a) understanding the complex interactions of the features of a product line; (b) eliciting the utility of each feature for the stakeholders and hence exposing the stakeholders’ otherwise implicit preferences in a way that they can more easily make decisions; and (c) dynamically building a decision model through interaction with the stakeholders and by considering the structural characteristics of software product line feature models, which will guide the stakeholders through the product configuration process. Initial exploratory empirical experiments that we have performed show that our proposed approach for helping stakeholders understand their feature preferences and its associated staged feature model configuration process is able to positively impact the quality of the end results of the application engineering process within the context of the limited number of participants. In addition, it has been observed that the offered tooling support is able to ease the staged feature model configuration process.     

Assessing software product line potential: an exploratory industrial case study

Corporate organizations sometimes offer similar software products in certain domains due to former company mergers or due to the complexity of the organization. The functional overlap of such products is an opportunity for future systematic reuse to reduce software development and maintenance costs. Therefore, we have tailored existing domain analysis methods to our organization to identify commonalities and variabilities among such products and to assess the potential for software product line (SPL) approaches. As an exploratory case study, we report on our experiences and lessons learned from conducting the domain analysis in four application cases with large-scale software products. We learned that the outcome of a domain analysis was often a smaller integration scenario instead of an SPL and that business case calculations were less relevant for the stakeholders and managers from the business units during this phase. We also learned that architecture reconstruction using a simple block diagram notation aids domain analysis and that large parts of our approach were reusable across application cases.     

Components meet aspects: Assessing design stability of a software product line

Context

It is important for Product Line Architectures (PLA) to remain stable accommodating evolutionary changes of stakeholder’s requirements. Otherwise, architectural modifications may have to be propagated to products of a product line, thereby increasing maintenance costs. A key challenge is that several features are likely to exert a crosscutting impact on the PLA decomposition, thereby making it more difficult to preserve its stability in the presence of changes. Some researchers claim that the use of aspects can ameliorate instabilities caused by changes in crosscutting features. Hence, it is important to understand which aspect-oriented (AO) and non-aspect-oriented techniques better cope with PLA stability through evolution.

Objective

This paper evaluates the positive and negative change impact of component and aspect based design on PLAs. The objective of the evaluation is to assess how aspects and components promote PLA stability in the presence of various types of evolutionary change. To support a broader analysis, we also evaluate the PLA stability of a hybrid approach (i.e. combined use of aspects and components) against the isolated use of component-based, OO, and AO approaches.

Method

An quantitative and qualitative analysis of PLA stability which involved four different implementations of a PLA: (i) an OO implementation, (ii) an AO implementation, (iii) a component-based implementation, and (iv) a hybrid implementation where both components and aspects are employed. Each implementation has eight releases and they are functionally equivalent. We used conventional metrics suites for change impact and modularity to measure the architecture stability evaluation of the 4 implementations.

Results

The combination of aspects and components promotes superior PLA resilience than the other PLAs in most of the circumstances.

Conclusion

It is concluded that the combination of aspects and components supports the design of high cohesive and loosely coupled PLAs. It also contributes to improve modularity by untangling feature implementation.     

Model-based pairwise testing for feature interaction coverage in software product line engineering

Testing software product lines (SPLs) is very challenging due to a high degree of variability leading to an enormous number of possible products. The vast majority of today??s testing approaches for SPLs validate products individually using different kinds of reuse techniques for testing. Because of their reusability and adaptability capabilities, model-based approaches are suitable to describe variability and are therefore frequently used for implementation and testing purposes of SPLs. Due to the enormous number of possible products, individual product testing becomes more and more infeasible. Pairwise testing offers one possibility to test a subset of all possible products. However, according to the best of our knowledge, there is no contribution discussing and rating this approach in the SPL context. In this contribution, we provide a mapping between feature models describing the common and variable parts of an SPL and a reusable test model in the form of statecharts. Thereby, we interrelate feature model-based coverage criteria and test model-based coverage criteria such as control and data flow coverage and are therefore able to discuss the potentials and limitations of pairwise testing. We pay particular attention to test requirements for feature interactions constituting a major challenge in SPL engineering. We give a concise definition of feature dependencies and feature interactions from a testing point of view, and we discuss adequacy criteria for SPL coverage under pairwise feature interaction testing and give a generalization to the T-wise case. The concept and implementation of our approach are evaluated by means of a case study from the automotive domain.     

SEI's software product line tenets

Software product lines are emerging as a viable, important software development paradigm. Based on the Software Engineering Institute's research and experience, the concepts, activities, and practices described here can lead to successful product line development. How-to's, success stories, and lessons learned expand on the approach.     

Emerald: software metrics and models on the desktop

As software becomes more and more sophisticated, industry has begun to place a premium on software reliability. The telecommunications industry is no exception. Consequently software reliability is a strategic business weapon in an increasingly competitive marketplace. In response to these concerns, BNR, Nortel, and Bell Canada developed the Enhanced Measurement for Early Risk Assessment of Latent Defects (Emerald), a decision support system designed to improve telecommunications software reliability. Emerald efficiently integrates software measurements, quality models, and delivery of results to the desktop of software developers. We have found that Emerald not only improves software reliability, but also facilitates the accurate correction of field problems. Our experiences developing Emerald have also taught us some valuable lessons about the implementation and adoption of this type of software tool     

Flexible feature binding in software product lines

A software product line (SPL) is a family of programs that share assets from a common code base. The programs of an SPL can be distinguished in terms of features, which represent units of program functionality that satisfy stakeholders’ requirements. The features of an SPL can be bound either statically at program compile time or dynamically at run time. Both binding times are used in SPL development and have different advantages. For example, dynamic binding provides high flexibility whereas static binding supports fine-grained customizability without any impact on performance (e.g., for use on embedded systems). However, contemporary techniques for implementing SPLs force a programmer to choose the binding time already when designing an SPL and to mix different implementation techniques when multiple binding times are needed. We present an approach that integrates static and dynamic feature binding seamlessly. It allows a programmer to implement an SPL once and to decide per feature at deployment time whether it should be bound statically or dynamically. Dynamic binding usually introduces an overhead regarding resource consumption and performance. We reduce this overhead by statically merging features that are used together into dynamic binding units. A program can be configured at run time by composing binding units on demand. We use feature models to ensure that only valid feature combinations can be selected at compile and at run time. We provide a compiler and evaluate our approach on the basis of two non-trivial SPLs.     

Debugging effort estimation using software metrics

Measurements of 23 style characteristics, and the program metrics LOC, V(g), VARS, and PARS were collected from student Cobol programs by a program analyzer. These measurements, together with debugging time (syntax and logic) data, were analyzed using several statistical procedures of SAS (statistical analysis system), including linear, quadratic, and multiple regressions. Some of the characteristics shown to correlate significantly with debug time are GOTO usage, structuring of the IF-ELSE construct, level 88 item usage, paragraph invocation pattern, and data name length. Among the observed characteristic measures which are associated with lowest debug times are: 17% blank lines in the data division, 12% blank lines in the procedure division, and 13-character-long data items. A debugging effort estimator, DEST, was developed to estimate debug times     

On the relationship of concern metrics and requirements maintainability

Context

Maintainability has become one of the most essential attributes of software quality, as software maintenance has shown to be one of the most costly and time-consuming tasks of software development. Many studies reveal that maintainability is not often a major consideration in requirements and design stages, and software maintenance costs may be reduced by a more controlled design early in the software life cycle. Several problem factors have been identified as harmful for software maintainability, such as lack of upfront consideration of proper modularity choices. In that sense, the presence of crosscutting concerns is one of such modularity anomalies that possibly exert negative effects on software maintainability. However, to the date there is little or no knowledge about how characteristics of crosscutting concerns, observable in early artefacts, are correlated with maintainability.

Objective

In this setting, this paper introduces an empirical analysis where the correlation between crosscutting properties and two ISO/IEC 9126 maintainability attributes, namely changeability and stability, is presented.

Method

This correlation is based on the utilization of a set of concern metrics that allows the quantification of crosscutting, scattering and tangling.

Results

Our study confirms that a change in a crosscutting concern is more difficult to be accomplished and that artefacts addressing crosscutting concerns are found to be less stable later as the system evolves. Moreover, our empirical analysis reveals that crosscutting properties introduce non-syntactic dependencies between software artefacts, thereby decreasing the quality of software in terms of changeability and stability as well. These subtle dependencies cannot be easily detected without the use of concern metrics.

Conclusion

The correlation provides evidence that the presence of certain crosscutting properties negatively affects to changeability and stability. The whole analysis is performed using as target cases three software product lines, where maintainability properties are of upmost importance not only for individual products but also for the core architecture of the product line.     

The evaluation of software systems' structure using quantitative software metrics

The design and analysis of the structure of software systems has typically been based on purely qualitative grounds. In this paper we report on our positive experience with a set of quantitative measures of software structure. These metrics, based on the number of possible paths of information flow through a given component, were used to evaluate the design and implementation of a software system (the UNIX operating system kernel) which exhibits the interconnectivity of components typical of large-scale software systems. Several examples are presented which show the power of this technique in locating a variety of both design and implementation defects. Suggested repairs, which agree with the commonly accepted principles of structured design and programming, are presented. The effect of these alterations on the structure of the system and the quantitative measurements of that structure lead to a convincing validation of the utility of information flow metrics.     

An empirical study on predictability of software maintainability using imbalanced data

Software Quality Journal - In software engineering predictive modeling, early prediction of software modules or classes that possess high maintainability effort is a challenging task. Many...     

Comprehensibility of UML-based software product line specifications

Software Product Line Engineering (SPLE) deals with developing artifacts that capture the common and variable aspects of software product families. Domain models are one kind of such artifacts. Being developed in early stages, domain models need to specify commonality and variability and guide the reuse of the artifacts in particular software products. Although different modeling methods have been proposed to manage and support these activities, the assessment of these methods is still in an inceptive stage. In this work, we examined the comprehensibility of domain models specified in ADOM, a UML-based SPLE method. In particular, we conducted a controlled experiment in which 116 undergraduate students were required to answer comprehension questions regarding a domain model that was equipped with explicit reuse guidance and/or variability specification. We found that explicit specification of reuse guidance within the domain model helped understand the model, whereas explicit specification of variability increased comprehensibility only to a limited extent. Explicit specification of both reuse guidance and variability often provided intermediate results, namely, results that were better than specification of variability without reuse guidance, but worse than specification of reuse guidance without variability. All these results were perceived in different UML diagram types, namely, use case, class, and sequence diagrams and for different commonality-, variability-, and reuse-related aspects.     

面向方面的软件产品线需求建模

为了将软件产品线的横切关注点在开发的早期阶段分离出来,完成系统分析向设计阶段的顺利过渡,提出了一种面向方面的软件产品线需求分析模型,并给出该模型需求分析的基本步骤.通过冷库管理系统的实例,给出了识别和描述功能需求、非功能需求和横切关注点的方法,利用UML类图完成方面和功能整合,在此基础上介绍了用关系矩阵和合并非功能需求集合的方法来描述非功能需求.实验结果表明,该方法能够有效简化软件产品线需求建模的复杂性.     

基于软件产品线的需求分析研究

软件产品线方法是一种面向特定领域的、大规模、大粒度的软件复用技术.在软件产品线的开发过程中,产品线需求分析是软件产品线开发的关键活动之一,软件产品线需求分析奠定了产品线构架的基础.通过分析软件产品线开发过程和软件产品线需求分析的特点,阐述了软件产品线需求分析方法以及软件产品线需求分析的实践风险.以领域分析和建模为切入点,对软件产品线的领域分析、需求建模和用例建模等关键方法和技术进行了重点的研究.     

Requirements engineering in software product line engineering

Many attempts have been made to increase the productivity and quality of software products based on software reuse. Software product line practice is one such approach, one that focuses on developing a family of products which have a majority of features in common. Hence, there are numerous requirements that are common across the family, but others are unique to individual products. Traditional requirements engineering methods were conceived to deal with single product requirements and are usually not flexible enough to address the needs arising from reusing requirements for a family of products. There is also the additional burden of correctly identifying and engineering both product-line-wide requirements and product-specific requirements as well as evolving them. Therefore, in this special issue, we want to highlight the importance and the role of requirements engineering for product line development as well as to provide insights into the state of the art in the field.     

Reasoning about software using metrics and expert opinion

When comparing software programs on the basis of more than one metric a difficulty arises when the metrics are contradictory or if there are no standard acceptance thresholds. An appealing solution in such cases is to incorporate expert opinion to resolve the inconsistencies. A rigorous framework, however, is essential when fusing metrics and expert opinion in this decision-making process. Fortunately, the analytical hierarchy process (AHP) can be used to facilitate rigorous decision-making in this particular problem. In this work a combination of expert opinion and tool-collected measures are used to reason about software programs using AHP. The methodology employed can be adapted to other decision-making problems in software engineering when both metrics data and expert opinion are available, some of which are described. This paper is an extended version of Norita Ahmad and Phillip A. Laplante, “Employing Expert Opinion and Software Metrics for Reasoning About Software,” Third IEEE International Symposium on Dependable, Autonomic and Secure Computing (DASC 2007), September 2007, Columbia, Maryland, USA.