Empirical software engineering research needs research guidelines to improve the research and reporting processes. We propose a preliminary set of research guidelines aimed at stimulating discussion among software researchers. They are based on a review of research guidelines developed for medical researchers and on our own experience in doing and reviewing software engineering research. The guidelines are intended to assist researchers, reviewers, and meta-analysts in designing, conducting, and evaluating empirical studies. Editorial boards of software engineering journals may wish to use our recommendations as a basis for developing guidelines for reviewers and for framing policies for dealing with the design, data collection, and analysis and reporting of empirical studies.

/pdf/preliminary-guidelines-for-empirical-research-in-software-17mchb417s.pdf

Preliminary guidelines for empirical research in software engineering

We survey the literature available on the topic of domain-specific languages as used for the construction and maintenance of software systems. We list a selection of 75 key publications in the area, and provide a summary for each of the papers. Moreover, we discuss terminology, risks and benefits, example domain-specific languages, design methodologies, and implementation techniques.

https://people.cis.ksu.edu/~schmidt/505f14/Lectures/DSLbib.pdf

Domain-specific languages: an annotated bibliography

Feature modeling is an important approach to capture the commonalities and variabilities in system families and product lines. Cardinality-based feature modeling integrates a number of existing extensions of the original feature-modeling notation from Feature-Oriented Domain Analysis. Staged configuration is a process that allows the incremental configuration of cardinality-based feature models. It can be achieved by performing a step-wise specialization of the feature model. In this article, we argue that cardinality-based feature models can be interpreted as a special class of context-free grammars. We make this precise by specifying a translation from a feature model into a context-free grammar. Consequently, we provide a semantic interpretation for cardinality-based feature models by assigning an appropriate semantics to the language recognized by the corresponding grammar. Finally, we give an account on how feature model specialization can be formalized as transformations on the grammar equivalent of feature models. Copyright © 2005 John Wiley & Sons, Ltd.

/pdf/formalizing-cardinality-based-feature-models-and-their-6zf3v3d7z9.pdf

Formalizing cardinality‐based feature models and their specialization

Feature modeling is an important approach to capturing commonalities and variabilities in system families and product lines. In this paper, we propose a cardinality-based notation for feature modeling, which integrates a number of existing extensions of previous approaches. We then introduce and motivate the novel concept of staged configuration. Staged configuration can be achieved by the stepwise specialization of feature models. This is important because in a realistic development process, different groups and different people eliminate product variability in different stages. We also indicate how cardinality-based feature models and their specialization can be given a precise formal semantics.

/pdf/staged-configuration-using-feature-models-2s5yxm6pee.pdf

Staged Configuration Using Feature Models

Feature modeling is a key technique for capturing commonalities and variabilities in system families and product lines. In this article, we propose a cardinality-based notation for feature modeling, which integrates a number of existing extensions of previous approaches. We then introduce and motivate the novel concept of staged configuration. Staged configuration can be achieved by the stepwise specialization of feature models or by multilevel configuration, where the configuration choices available in each stage are defined by separate feature models. Staged configuration is important because, in a realistic development process, different groups and different people make product configuration choices in different stages. Finally, we also discuss how multilevel configuration avoids a breakdown between the different abstraction levels of individual features. This problem, sometimes referred to as 'analysis paralysis', easily occurs in feature modeling because features can denote entities at arbitrary levels of abstraction within a system family. Copyright © 2005 John Wiley & Sons, Ltd.

/pdf/staged-configuration-through-specialization-and-multilevel-42kt6bpgod.pdf

Staged configuration through specialization and multilevel configuration of feature models

Software product lines have recently been introduced as one of the most promising advances for efficient software development. Yet upon close examination, there are few guidelines or methodologies available to develop and deploy product lines beyond existing domain engineering approaches. The latter have had mixed success within commercial enterprises because of their deployment complexity, lack of customizability, and especially their misplaced focus, that is on domains as opposed to products. To tackle these problems we developed the PuLSETM (Product Line Software Engineering) methodology for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts. This is achieved via product-centric focus throughout the phases of PuLSETM, customizability of its components, incremental introduction capability, maturity scale for structured evolution, and adaptations to a few main product development situations. PuLSETM is the result of a bottom-up effort: the methodology captures and leverages the results (the lessons learned) from our technology transfer activities with our industrial customers. We present in this paper the main ideas behind PuLSETM and illustrate the methodology with a running example taken from our transfer experience.

/pdf/pulse-a-methodology-to-develop-software-product-lines-3jmkvsro3u.pdf

PuLSE: a methodology to develop software product lines

An encompassing life cycle centric survey of software inspection

Product line scoping is a critical activity because it elicits the common realms upon which the different products of a product line can be optimally engineered with respect to economies of scope. This, in turn, upper bounds the overall economic benefits that can be accrued from product line based development. Inherently, product line scoping is difficult because of the complexity of the factors that must be taken into account. Many are not known a priori. Traditional scoping approaches (from domain engineering) have focused on the notion of application domains. However, domains proved difficult to optimally scope and engineer from an enterprise standpoint because a domain captures extraneous elements that are of no interest to an enterprise which must focus on particular products, whether existing, under development, or anticipated. Hence, the domain view provides a flawed economic basis for making a scoping decision. We introduce PuLSE-Eco, a technique especially developed to address the aforementioned issues. Its main characteristics are: a complete product-centric orientation done via product maps, the separation of concerns achieved through the definition and operationalization of strategic business objectives, and last, diverse types of analyses performed upon product maps allowing scoping decisions based on these objectives. We illustrate the technique with a running example.

A systematic approach to derive the scope of software product lines

A successful software system evolves over time, but this evolution often occurs in an ad-hoc fashion. One approach to structure system evolution is the concept of software product lines where a core architecture supports a variety of application contexts. However, in practice, the high cost and high risks of redevelopment as well as the substantial investments made to develop the existing systems most often mandate significant leverage of the legacy assets. Yet, there is little guidance in the literature on how to transition legacy assets into a product line set-up.In this paper, we present RE-PLACE, an approach developed to support the transition of existing software assets towards a product line architecture while taking into account anticipated new system variants. We illustrate this approach with its application in an industrial setting.

Transitioning legacy assets to a product line architecture

Despite dramatic changes in software development in the two decades since the term software engineering was coined, software quality deficiencies and cost overruns continue to afflict the software industry. Inspections, developed at IBM by Fagan in the early 1970s [1], can be used to improve upon these problems because they allow the detection and removal of defects after each phase of the software development process. But, in most published inspection processes, individuals performing defect detection are not systematically supported. There, defect detection depends heavily upon factors like chance or experience. Further, there is an ongoing debate in the literature whether or not defect detection is more effective when performed as a group activity and hence should be conducted in meetings [5],[11],[13],[14]. In this article we introduce Perspective-based Reading (PBR) for code documents, a systematic technique to support individual defect detection. PBR offers guidance to individual inspectors for defect detection. This guidance is embodied within perspective-based algorithmic scenarios which makes individual defect detection independent of experience. To test this assumption, we tailored and introduced PBR in the inspection process at Robert Bosch GmbH. We conducted two training sessions in the form of a 2x3 fractional factorial experiment in which 11 professional software developers reviewed code documents from three different perspectives. The experimental results are, (1) Perspective-based Reading and the type of document have an influence on individual defect detection, (2) multi-individual inspection meetings were not very useful to detect defects, (3) the overlap of detected defects among inspectors using different perspectives is low, (4) there are no significant differences with respect to defect detection between inspectors having experiences in the programming language and/or the application domain and those that do not.

Jean-Marc DeBaud

Papers

PuLSE: a methodology to develop software product lines

An encompassing life cycle centric survey of software inspection

A systematic approach to derive the scope of software product lines

Transitioning legacy assets to a product line architecture

Perspective-based Reading of Code Documents at