Software product lines have numerous members. Thus, a product line infrastructure must cover various systems. This is the significant difference to usual software systems and the reason for additional requirements on the various assets present during software product line engineering. It is imperative that they support the description of the product line as a whole, as well as its instantiation for the derivation of individual products.Literature has already addressed how to create and instantiate generic product line assets, such as domain models and architectures to generate instance specific ones [1, 2, 3], yet little attention has been given on how to actually deal with this genericity at the code level.This paper addresses the issue of handling product line variability at the code level. To this end various implementation approaches are examined with respect to their use in a product line context.

Implementing product line variabilities

This paper aims at identifying some of the key factors in adopting or running a company-wide software reuse program. Key factors are derived from empirical evidence of reuse practices, as emerged from a survey of projects for the introduction of reuse in European companies: 24 such projects performed from 1994 to 1997 were analyzed using structured interviews. The projects were undertaken in both large and small companies, working in a variety of business domains, and using both object-oriented and procedural development approaches. Most of them produce software with high commonality between applications, and have at least reasonably mature processes. Despite that apparent potential for success, around one-third of the projects failed. Three main causes of failure were not introducing reuse-specific processes, not modifying nonreuse processes, and not considering human factors. The root cause was a lack of commitment by top management, or nonawareness of the importance of those factors, often coupled with the belief that using the object-oriented approach or setting up a repository seamlessly is all that is necessary to achieve success in reuse. Conversely, successes were achieved when, given a potential for reuse because of commonality among applications, management committed to introducing reuse processes, modifying nonreuse processes, and addressing human factors.

Success and failure factors in software reuse

Product derivation in software product families: a case study

Product line models are used to drive the generation of requirements for single systems in the product line. They are difficult to validate because they are large and complex. By modelling variability and dependency between requirements using propositional connectives, a logical expression can be developed for the model. Validation of the selection of requirements from the model can be achieved by satisfying the logical expression. This approach can be used to validate the model as a whole. A detailed worked example is presented, and the computational aspects of the approach are discussed.

Using First-Order Logic for Product Line Model Validation

Traceability of software artefacts has been recognised as an important factor for supporting various activities in the software system development process. In general, the objective of traceability is to improve the quality of software systems. More specifically, traceability information can be used to support the analysis of implications and integration of changes that occur software systems; the maintenance and evolution of software systems; the reuse of software system components by identifying and comparing requirements of new and existing systems; the testing of software system components; and system inspection, by indicating alternatives and compromises made during development. Traceability enables system acceptance by allowing users to better understand the system and contributes to a clear and consistent system documentation. Over the last few years, the software and system engineering communities have developed a large number of approaches and techniques to address various aspects of traceability. Research into software traceability has been mainly concerned with the study and definition of different types of traceability relations; support for the generation of traceability relations; development of architectures, tools, and environments for the representation and maintenance of traceability relations; and empirical investigations into organisational practices regarding the establishment and deployment of traceability relations in the software development life cycle. However, despite its importance and the work resulted from numerous years of research, empirical studies of traceability needs and practices in industrial organisations have indicated that traceability support is not always satisfactory. As a result, traceability is rarely established in existing industrial settings. In this article, we present a roadmap of research and practices related to software traceability and identify issues that are still open for further research. Our roadmap is organised according to the main topics that have been the focus of software traceability research.

Software Traceability : A Roadmap

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

Small and medium-sized enterprises work under heavy constraints: They need to be very flexible and fast in their reaction to customer requests, thus limiting their possibility for long-term planning. In a partially publicly funded project, the authors have started to apply their Product Line Software Engineering method developed at Fraunhofer IESE, in six small and medium-sized companies addressing six different domains. The article presents first experience and lessons learned from 24 months of project work; including first results within the companies.

/pdf/applying-product-line-concepts-in-small-and-medium-sized-55lbp5i8xo.pdf

Applying Product Line Concepts in Small and Medium-Sized Companies

Reusing assets during application engineering promises to improve the efficiency of systems development. However in order to benefit from reusable assets, application engineering processes must incorporate when and how to use the reusable assets during single system development. However, when and how to use a reusable asset depends on what types of reusable assets have been created. Product line engineering approaches produce a reusable infrastructure for a set of products. In this paper, we present the application engineering process associated with the PuLSE product line software engineering method-PuLSE-I. PuLSE-I details how single systems can be built efficiently from the reusable product line infrastructure built during the other PuLSE activities.

/pdf/pulse-i-deriving-instances-from-a-product-line-4010vr8xvt.pdf

PuLSE-I: Deriving instances from a product line infrastructure

Generative and Component-Based Software Engineering are approaches to reuse. Within both approaches the scope of reuse can vary between general purpose and application specific. We argue for scoping the reusable assets based on a product line.

Domain analysis methods provide processes for determining the common and varying requirements for a product line. However, we experienced that existing methods have problems concerning applicability and instantiation support. Therefore, we have developed the Customizable Domain Analysis (CDA) method.

CDA is customizable to the project context where it will be applied. This ensures that the method and workproducts used for modeling are appropriate for the specific needs. CDA also provides full instantiation support for specifying systems in the product line.

Customizable Domain Analysis

Traceability is a key supporting technology for product line engineering It is necessary to develop a product line infrastructure that covers a complete product family and to maintain such an infrastructure consistently In this paper, we describe how traceability support can be added to an existing product line method and give an example of the application of the resulting method

Tanya Widen

Papers

PuLSE: a methodology to develop software product lines

Applying Product Line Concepts in Small and Medium-Sized Companies

PuLSE-I: Deriving instances from a product line infrastructure

Customizable Domain Analysis

Introducing Traceability to Product Lines