Product derivation in software product families: a case study

Deelstra, Sybren; Sinnema, Marco; Bosch, Jan

doi:10.1016/j.jss.2003.11.012

Cited by 172 publications

(134 citation statements)

References 20 publications

Supporting

Mentioning

131

Contrasting

Unclassified

Order By: Relevance

“…Some recommendations can be found to manage requirements in the context of SPL, but they always need to be customized [3] [4] [5] [6] [7]. Existing approaches rely on a requirements variability modeling process followed by a requirements selection process to retrieve a requirements collection specifying the single product to build.…”

Section: Fig 1 Requirements Engineering Challenges In a Software Prmentioning

confidence: 99%

See 1 more Smart Citation

RED-PL, a Method for Deriving Product Requirements from a Product Line Requirements Model

Djebbi

Salinesi²

2007

Advanced Information Systems Engineering

View full text Add to dashboard Cite

Abstract. Software product lines (SPL) modeling has proven to be an effective approach to reuse in software development. Several variability approaches were developed to plan requirements reuse, but only little of them actually address the issue of deriving product requirements. Indeed, while the modeling approaches sell on requirements reuse, the associated derivation techniques actually focus on deriving and reusing technical product data. This paper presents a method that intends to support requirements derivation. Its underlying principle is to take advantage of approaches made for reuse PL requirements and to complete them by a requirements development process by reuse for single products. The proposed approach matches users' product requirements with PL requirements models and derives a collection of requirements that is (i) consistent, and (ii) optimal with respect to users' priorities and company's constraints. The proposed methodological process was validated in an industrial setting by considering the requirement engineering phase of a product line of blood analyzers.

show abstract

Section: Fig 1 Requirements Engineering Challenges In a Software Prmentioning

confidence: 99%

“…[35] discusses automating component selection using artificial intelligence techniques. [3] [5] provide a framework of terminology and concepts regarding product derivation as well as a generic software derivation process. It is organized on iterative phases in order to determine the final configuration of the derived product.…”

Section: Related Workmentioning

confidence: 99%

RED-PL, a Method for Deriving Product Requirements from a Product Line Requirements Model

Djebbi

Salinesi²

2007

Advanced Information Systems Engineering

View full text Add to dashboard Cite

show abstract

“…Although the approach described in this section has significant advantages for traditional product families, the broadening product scope of many families creates an increasing need for creating creative configurations [3]. Some typical reasons for creative configurations include:…”

Section: Towards Compositionalitymentioning

confidence: 99%

Software Product Families: Towards Compositionality

Bosch

2007

Fundamental Approaches to Software Engineering

Self Cite

View full text Add to dashboard Cite

Abstract. Software product families have become the most successful approach to intra-organizational reuse. Especially in the embedded systems industry, but also elsewhere, companies are building rich and diverse product portfolios based on software platforms that capture the commonality between products while allowing for their differences. Software product families, however, easily become victims of their own success in that, once successful, there is a tendency to increase the scope of the product family by incorporating a broader and more diverse product portfolio. This requires organizations to change their approach to product families from relying on a pre-integrated platform for product derivation to a compositional approach where platform components are composed in a product-specific configuration.

show abstract

“…When strictly applied, it is possible to use a single top-level configuration file (e.g., a feature model configuration) and automatically generate all the remaining configuration files no matter which format [4]. However, a very common scenario in industry [6] is that a customer actively negotiates the characteristics of the product. This makes application engineering a laborious task requiring implementation of additional modules, but also fine-grained configuration and customization at various locations with subtle, implicit dependencies.…”

Section: Introductionmentioning

confidence: 99%

Consistent Product Line Configuration across File Type and Product Line Boundaries

Elsner

Ulbrich

Lohmann

et al. 2010

Software Product Lines: Going Beyond

View full text Add to dashboard Cite

Abstract. Creating a valid software configuration of a product line can require laborious customizations involving multiple configuration file types, such as feature models, domain-specific languages, or preprocessor defines in C header files. Using configurable off-the-shelf components causes additional complexity. Without checking of constraints across file types boundaries already at configuration time, intricate inconsistencies are likely to be introduced-resulting in product defects, which are costly to discover and resolve later on. Up to now, at best ad-hoc solutions have been applied. To tackle this problem in a general way, we have developed an approach and a corresponding plug-in infrastructure. It allows for convenient definition and checking of constraints across configuration file types and product line boundaries. Internally, all configuration files are converted to models, facilitating the use of model-based constraint languages (e.g., OCL). Converter plug-ins for arbitrary configuration file types may be integrated and hide a large amount of complexity usually associated with modeling. We have validated our approach using a quadrotor helicopter product line comprising three sub-product-lines and four different configuration file formats. The results give evidence that our approach is practically applicable, reduces time and effort for product derivation (by avoiding repeated compiling, testing, and reconfiguration cycles), and prevents faulty software deployment.

show abstract

Product derivation in software product families: a case study

Cited by 172 publications

References 20 publications

RED-PL, a Method for Deriving Product Requirements from a Product Line Requirements Model

RED-PL, a Method for Deriving Product Requirements from a Product Line Requirements Model

Software Product Families: Towards Compositionality

Consistent Product Line Configuration across File Type and Product Line Boundaries

Contact Info

Product

Resources

About