PREPARING FOR PRODUCT DERIVATION

Activities and Issues

Padraig O’Leary, Ita Richardson

Lero, The Irish Software Engineering Research Centre, University of Limerick, Ireland

Fergal McCaffery

Dundalk Institute of Technology, Dundalk, Ireland

Steffen Thiel

Department of Computer Science, Furtwangen University of Applied Sciences, Germany

Keywords: Software Product Lines, Product Derivation, Process Engineering.

Abstract: Software product lines (SPL) advocates the development of applications by reusing shared software assets

across a set of related products. Current approaches to the derivation of products from a product line focuses

on handling the commonalities and variabilities of the shared software asseas. These approaches have failed

to consider the early phases of product derivation. In this paper we report on how we compared both

industrial and academic approaches to the establishment of a product derivation project. Based on this

research and our experiences, we have identified key activities and important issues that should be

considered when establishing a product derivation project.

1 INTRODUCTION

1.1 Software Product Lines

“A Software Product Line (SPL) is a set of software-

intensive systems that share a common, managed set

of features satisfying the specific needs of a

particular market segment or mission and that are

developed from a common set of core assets in a

prescribed way” (Kurmann 2006). The SPL

approach makes a distinction between domain

engineering, where a common platform for an

arbitrary number of products is designed and

implemented, and application engineering, where a

product is derived based on the platform components

(Trinidad, Benavides et al. 2006). The separation of

SPL into domain engineering and application

engineering allows the development of software

artefacts which are shared among all the products

within that domain. These shared artefacts become

separate entities in their own right, subscribing to

providing shared functionality across multiple

products.

During application engineering, individual

products are constructed from the product line to

fulfil the requirements of a particular customer or

market. The products are built (re-)using a number

of shared software artefacts – often called core

assets – created during domain engineering. The

process of creating these individual products using

the platform artefacts is known as product

derivation.

1.2 Product Derivation

Product Derivation is the process of constructing a

product from a Software Product Line (SPL)

(Deelstra, Sinnema et al. 2005). The underlying

assumption of product derivation is that “the

investments required for building the reusable assets

during domain engineering are outweighed by the

benefits of rapid derivation of individual

products” (Deelstra, Sinnema et al. 2005). This

assumption might not hold if inefficient derivation

practices diminish the expected gains.

A number of publications discuss the difficulties

121

O’Leary P., Richardson I., McCaffery F. and Thiel S. (2009).

PREPARING FOR PRODUCT DERIVATION - Activities and Issues.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 121-126

DOI: 10.5220/0002241301210126

 SciTePress

associated with product derivation. Hotz et al. (Hotz,

Gunter et al. 2003) describe the process as “slow and

error prone even if no new development is

involved”. Griss (Griss 2000) identifies the inherent

complexity and the coordination required in the

derivation process by stating that “…as a product is

defined by selecting a group of features, a carefully

coordinated and complicated mixture of parts of

different components are involved”. Therefore, as

Deelstra et al. (Deelstra, Sinnema et al. 2005) point

out: the derivation of individual products from

shared software assets is still a time-consuming and

expensive activity in many organisations. The

authors state that “there is a lack of methodological

support for application engineering and,

consequently, organizations fail to exploit the full

benefits of software product families.” “Guidance

and support are needed to increase efficiency and to

deal with the complexity of product derivation”

(Rabiser, Grünbacher et al. 2007). As a means of

addressing this imbalance, we are investigating the

practices and issues surrounding the initial stage of

the product derivation process, a stage we refer to as

pre-derivation.

1.3 Contribution

Comparing existing product derivation approaches

that consider pre-derivation allows the definition of

important issues to be addressed and key activities

that should be supported. The observations, which

are reported in this paper, should be of interest to

both researchers and industry practitioners alike.

The remainder of this paper is organised as

follows: Section 2 discusses related work. Section 3,

describes our research approach. In Section 4, based

on our experiences we define key activities for

product derivation preparation. In Section 5 we

present important issues to be considered when

initiating a product derivation project. We conclude

the paper with a summary and an outlook on future

work in Section 6.

2 BACKGROUND

Several approaches with pre-derivation facets have

been proposed. Deelstra et al. (Deelstra, Sinnema et

al. 2005) present a product derivation approach

developed based on two industrial case studies. This

work presents a framework of terminology and

concepts for product derivation. The framework

focuses on product configuration and is a high level

attempt at providing the methodological support that

Deelstra et al. (Deelstra, Sinnema et al. 2004) agree

is required for product derivation. Deelstra’s

approach suggests that requirements which cannot

be accommodated by existing assets are handled by

product-specific adaptation or reactive evolution.

Parts of the derivation framework have been

implemented in a research tool called COVAMOF

(Sinnema, Deelstra et al. 2006), a variability

modelling framework which purports to solve the

product derivation problems associated with

dependencies.

McGregor (Chastek and McGregor 2002)

introduces the production plan, which prescribes

how products are produced from platform assets.

The product plan facilitates the passing of

knowledge between the platform developers and the

product developers. McGregor (McGregor 2005)

also provides an overview of technologies and

approaches to automate product derivation.

Rabiser et al. (Rabiser, Grünbacher et al. 2007)

present an approach for supporting product

derivation using feature specifications. The approach

emphasises supporting the requirements acquisition

and management mechanism through the use of

variability models.

However, despite the above approaches,

comparably few publications focus on the early

stages of product derivation such as requirements

management and project initiation. Clements and

Northrop (Clements and Northrop 2001) describe

the role of requirements engineering when deriving a

product. Halmans and Pohl (Halmans and Pohl

2003; Pohl, Böckle et al. 2005) describe a use-case-

driven method to communicate the variability to the

customers and to capture requirements.

These different approaches have been developed

with different goals, for different purposes, and in

different domains. Some are intended to provide a

(process) framework for product derivation (Kang ,

Cohen et al. 1990; Czarnecki, Helson et al. 2004;

Deelstra, Sinnema et al. 2005), and others focus on

tool-support (Sinnema, Deelstra et al. 2006). Our

research into pre-derivation has been influenced by

these existing approaches. The key activities and

important issues we derive in Section 4 and 5

therefore also partly reflect this previous work.

3 RESEARCH APPROACH

The preparatory stage of this research involved

reviewing existing SPL whitepapers, product

derivation papers and software process improvement

(SPI) practices. The research aimed to identify the

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

122

fundamental practices of pre-derivation, including

available empirical evidence on the topic – scientific

as well as anecdotal. The initial results were further

developed and assessed through a series of iterative

workshops over a four month period. Evidence and

feedback from SPL practitioners and researchers

was collected from these organised workshops.

For the case study, we collected data on the

product derivation practices of a major supplier of

automotive systems. The systems produced consist

of both hardware (such as processors, sensors,

connectors, and housing) and software. Prior to an

on-site visit of the case study company, we had

access to internal company documentation. These

documents included information on product

derivation practices within a particular business unit,

organisational structure of the company’s teams and

information on various derivation techniques applied

within the company.

For the onsite visit to the company, we organised

a two day workshop. During the workshop we

presented our preliminary findings on the company’s

derivation practices and used these initial findings to

drive the workshop discussion. In total three

researchers facilitated the running of the workshop.

Our research was further developed through a six

month visit to LASSY (Laboratory of Advanced

Software Systems, University of Luxembourg);

where our model of product derivation activities and

FIDJI (Perrouin, Klein et al. 2008) were mapped.

FIDJI is a flexible product derivation process which

forms part of a model-driven SPL development

methodology. Mapping our research to FIDJI

provided academic validation.

We conducted a collaboration project with

Doppler Laboratory (Christian Doppler Lab.

Johannes Kepler University) where we investigated

the application of their DOPLER

UCon

(Rabiser,

Grünbacher et al. 2007) approach to product

derivation which was developed in conjunction with

Siemens VAI. We investigated the issues and

activities observed within Siemens VAI and our

research to date. This paper builds on the results

from that collaboration (O’Leary, Rabiser et al.

2009) by detailing the tasks and issues related to pre-

derivation phase of product derivation.

4 PRE-DERIVATION: KEY

ACTIVITIES

From our research, we have identified that the

following preparatory steps need to be conducted in

a product derivation project:

 Requirements Management

 Identify Starting Point for Derivation

 Map Customer Requirements to Platform

Features

 Customer Negotiation

 Create Product Specific Requirements

 Identify Role and Task Structures

4.1 Requirements Management

We identified the need for a more sophisticated

requirements management process when dealing

with large distributed SPL teams, particularly within

the case study company. Customer requirements are

translated into the internal organizational language.

This prevents terminology confusion and customer-

specific description of assets. This has to be done in

close collaboration with the customer. These

requirements are processed and augmented through

various tasks where requirements are analysed for

reuse potential and then assigned to responsible

disciplines.

4.2 Identify Starting Point for

Derivation

A “base configuration” may be chosen as a starting

point for derivation, i.e., from a set of previous

product configurations. Similar customers often

have comparable requirements and experiences from

past projects are captured in these product

configurations. Reusing previous product

configurations can speed up the derivation process.

If an existing product configuration can not be used

for the “base configuration”, a new one is derived

from a subset of the overall platform architecture.

4.3 Customer Negotiation

Customer requirements are mapped to the base

configuration. Requirements which cannot be

satisfied by existing assets have to be negotiated

with the customer. Effort estimation issues can make

customer negotiation difficult. The trade-off here is

to meet as many of the customer’s needs as possible

while retaining the profitability of the platform

assets for the whole product line.

In the case study we observed how, through

coverage analysis, the project manager identifies

which requirements are covered by the platform. If

specific requirements cannot be completely satisfied,

they are broken into smaller requirements and then

mapped to specific components.

PREPARING FOR PRODUCT DERIVATION - Activities and Issues

123

4.4 Create the Product Specific

Requirements

The satisfied customer requirements and the

negotiated customer requirements are merged to

form the product specific requirements. This could

also include the restructuring of the customer

requirements specification into the internal

organisation format.

We observed how forming the Product Specific

Requirements can also include allocating

requirements to relevant disciplines. The

requirements allocation is often held in separate

requirements documents, such as the platform

software requirements specification and the

customer hardware requirements specification.

4.5 Identify Role and Task Structures

The role and task structures for the product

derivation project have to be defined. Through

allocating role and task structures, responsibility for

resolving any remaining variability in product

derivation to fulfill the product requirements is

defined. This is very important as it provides

different views on variability for different people

involved in product derivation and helps to lower the

complexity of large decision spaces (c.f. Section

5.2).

4.6 Plan the Project

We observed two types of project planning. Manual

non-tool supported product derivation projects

tended to have ‘big bang’ releases after substantial

development periods. Automated approaches

appeared to be more iterative in nature, as each new

version of the product required less effort then the

manual approaches.

4.7 Provide Guidance for Decision

Makers

Preparing for derivation also means to create

guidance for decision-makers. Remaining variability

must be explained to deal with complexity issues in

representing product line variability. Guidance is

essential, especially for sales people, who are

confronted with many – often technical – decisions

(Rabiser, Dhungana et al. 2007).

5 PRE-DERIVATION ISSUES

From our research, we have identified that the

following preparatory steps need to be conducted in

a product derivation project:

 Customer Relationship

 Mapping Customer Requirements

 Use of Documentation

 Introduction of Iterative Development

5.1 Customer Relationship

Customer involvement in product derivation is

typically portrayed as a combative relationship

involving negotiation between separate parties with

contrasting motivations. This is in contrast to

customer relationship approaches we have observed.

The customer can play a very active and positive

role in the derivation process. It can be a

collaborative role, where the customer makes design

decisions alongside the derivation team. Good

communication where the limitations and

opportunities provided by the product line feature set

are clearly explained, can nurture a collaborative

relationship with the customer.

5.2 Mapping Customer Requirements

The specification of incompatible customer

requirements and undocumented dependencies can

be costly at a later stage in the product derivation

process. The size and complexity of variability

models for large-scale product lines exasperates the

issue, as difficulties in communicating the variability

provided by the product line may lead to unrealistic

customer requirements.

In industrial contexts, where there are hundreds

or even thousands of requirements, the cognitive

complexity makes mapping customer requirements

to platform features difficult. As a result, situations

can develop where the product team cannot

distinguish between requirements which are mapped

or not. To compensate, product teams perform

extensive verification which is expensive and time-

consuming.

5.3 Use of Documentation

Different organizations have different attitudes

towards documentation. Organizations with a

documentation culture tend to use it in response to

other problems. For instance, in communicating

information across large distributed teams, such

organizations tend to be overly-reliant on

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

124

documentation. An organization’s documentation

often becomes bloated as teams attempt to capture

too much. Such overly detailed documentation

decreases traceability of relevant information and

results in failure to correctly identify artefacts for

reuse especially in team sizes where the transfer of

tacit knowledge is prohibitive.

Alternatively, organizations may rely on tacit

knowledge and do not have practices of knowledge

externalization. For instance, during product

assembly, product teams often remark that the

selected components are incompatible. This is due to

the fact that all compatibility aspects between these

components are not externalized.

5.4 Project Planning: Iterative

Development

The identification of product derivation iterations is

a key aspect of deriving high quality, customer

satisfying products. According to Carbon et al.

(Carbon, Lindvall et al. 2006) with a SPL, an

organisation is capable of producing a first version

of a product for a specific customer, including the

core functionality, quicker than other software

development methods. Because of the approved

quality of the reusable assets, the customer can get a

high quality product that can be used and evaluated

to give feedback

During the course of this research we observed

that for iteration management, product teams could

benefit from applying the planning game practice

from the XP methodology for gathering and

negotiating product specific requirements. In the

planning game, a customer priorities the

requirements and the developers estimate the effort

required to satisfy those requirements. The end dates

of iterations are specified and requirements are

allocated to specific iterations based on their priority

(Carbon, Lindvall et al. 2006).

6 CONCLUSIONS AND FUTURE

WORK

In this paper, we have presented the results of our

research into the early stages of product derivation.

We compared both industrial and academic

approaches to the establishment of a product

derivation project. For academia, our results provide

structure to an important phase of product

derivation. Our work points to areas of uncertainty

and helps to identify remaining challenges in

preparing for derivation. Such a roadmap encourages

the insertion of those pieces that may be missing, or

the extra detail that may be needed.

For industry, it is envisaged that our results will

help the advancement of product derivation

practices. It will assist organisations by specifying

the activities to be supported when initiating product

derivation and highlight key issues to be considered.

In future work, we plan to continue case study

research for further elaboration on activities and

issues to be considered. Based on these results, we

will define a framework of activities for pre-

derivation.

ACKNOWLEDGEMENTS

This work is partially funded by IRCSET under

grant no. RS/06/167 and by Science Foundation

Ireland under grant no. 03/CE2/I303_1.

REFERENCES

Carbon, R., M. Lindvall, et al. (2006). Integrating Product

Line Engineering and Agile Methods: Flexible Design

Up-front vs. Incremental Design. 1st International

Workshop on Agile Product Line Engineering

(APLE'06), Maryland, USA.

Chastek, G. and J. D. McGregor (2002). Guidelines for

Developing a Product Line Production Plan. Product

Line Practice Initiative. Pittsburgh, PA, Software

Engineering Institute.

Clements, P. and L. Northrop (2001). Software Product

Lines: Practices and Patterns. Boston, MA, USA,

Addison-Wesley Longman Publishing Co., Inc.

Czarnecki, K., S. Helson, et al. (2004). Staged

configuration using feature models. Proc. of the 3rd

International Software Product Line Conference

(SPLC 2004), Boston, MA, USA, Springer Berlin

Heidelberg.

Deelstra, S., M. Sinnema, et al. (2004). Experiences in

Software Product Families: Problems and Issues

During Product Derivation. Software Product Lines,

Third International Conference. Boston, MA, USA,

Springer.

Deelstra, S., M. Sinnema, et al. (2005). Product Derivation

in Software Product Families: A Case Study. J. Syst.

Softw. New York, NY, USA, Elsevier Science Inc. 74:

173-194.

Griss, M. L. (2000). Implementing Product-Line Features

with Component Reuse. London, UK, Springer-

Verlag.

Halmans, G. and K. Pohl (2003). "Communicating the

Variability of a Software-Product Family to

Customers." Informatik - Forschung und Entwicklung

18(3-4): 113-131.

Hotz, L., A. Gunter, et al. (2003). A Knowledge-based

Product Derivation Process and some Ideas how to

PREPARING FOR PRODUCT DERIVATION - Activities and Issues

125

Integrate Product Development. Proc. of Software

Variability Management Workshop. Groningen, The

Netherlands.

Kang , K. C., S. G. Cohen, et al. (1990). Feature-Oriented

Domain Analysis (FODA) Feasibility Study.

Pittsburgh, PA, USA Carnegie-Mellon University

Software Engineering Institute.

Kurmann, R. (2006). Agile SPL-SCM Agile Software

Product Line Configuration and Release Management.

1st International Workshop on Agile Product Line

Engineering (APLE'06). Maryland, USA.

McGregor, J. D. (2005). Preparing for Automated

Derivation of Products in a Software Product Line,

Software Engineering Institute,.

O’Leary, P., R. Rabiser, et al. (2009). Important Issues and

Key Activities in Product Derivation: Experiences

from Two Independent Research Projects. Software

Product Line Conference. San Francisco, CA, USA.

Perrouin, G., J. Klein, et al. (2008). Reconciling

Automation and Flexibility in Product Derivation.

Software Product Line Conference, 2008. SPLC '08.

12th International.

Pohl, K., G. Böckle, et al. (2005). Software Product Line

Engineering: Foundations, Principles, and Techniques.

Heidelberg, Springer.

Rabiser, R., D. Dhungana, et al. (2007). "Product

configuration support for nontechnicians: Customer-

centered software product-line engineering." IEEE

Intelligent Systems 22(1): 85-87.

Rabiser, R., P. Grünbacher, et al. (2007). Supporting

Product Derivation by Adapting and Augmenting

Variability Models. 11th International Software

Product Line Conference. Kyoto, Japan.

Sinnema, M., S. Deelstra, et al. (2006). Modeling

Dependencies in Product Families with COVAMOF.

13th Annual IEEE International Conference and

Workshop on the Engineering of Computer Based

Systems (ECBS 2006). Potsdam, Germany.

Trinidad, P., D. Benavides, et al. (2006). Explanations for

Agile Feature Models. 1st International Workshop on

Agile Product Line Engineering (APLE'06), Maryland,

USA.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

126