Search

From our experience with several organizations that employ software product families, we have learned that deriving individual products from shared software artifacts is a time-consuming and expensive activity. In the research community, product derivation methodologies are rather scarce, however. By studying product derivation, we believe we will be better able to provide and validate industrially practicable solutions for application engineering. In this paper, we present a framework of terminology and concepts regarding product derivation that serves as basis for further discussion. We exemplify this framework with two industrial case studies, i.e. Thales Nederland B.V. and Robert Bosch GmbH.

This paper proposes a 4-dimensional software product family engineering evaluation model. The 4 dimensions relate to the software engineering concerns of business, architecture, organisation and process. The evaluation model is meant to be used within organisations to determine the status of their own software family engineering. Evaluation results may be used for bench-marking or improvement plans.

In a product family context, software architects anticipate product diversification and design architectures that support variants in both space (multiple contexts) and time (changing contexts). Product diversification is based on the concept of variability: a single architecture and a set of components support a family of products. Software product families need to support increasing amounts of variability, leading to a situation where variability dependencies become of primary concern. This paper discusses (1) a taxonomy of variability dependencies and (2) a case study in designing a program monitor and exception handler for a legacy system. The study shows that the types of variability dependencies in a system depend on how the system is designed and architected.

Software product lines (or system families) have achieved considerable adoption by the software industry. A software product line captures the commonalities between a set of products while providing for the differences. Differences are managed by delaying design decisions, thereby introducing variation points. The whole of variation points is typically referred to as the variability of the software product line. Variability management is, however, not a trivial activity and several issues exist, both in general as well as specific to individual phases in the lifecycle. This paper identifies and describes several variability issues based on practical experiences and theoretical understanding of the problem domain.