Supporting Product Derivation by Adapting and Augmenting Variability Models

Rick Rabiser Paul Grunbacher Deepak DhunganaChristian Doppler Laboratory for Automated Software Engineering

Johannes Kepler University Linz, Austriarabiser@ase.jku.at

Abstract

Product derivation is the process of constructing prod-ucts from the core assets in a product line. Guidance andsupport are needed to increase efficiency and to deal withthe complexity of product derivation. Research has, how-ever, devoted comparatively little attention to this process.In this paper we describe an approach for supporting prod-uct derivation. We show that variability models need to beprepared for concrete projects before they can be effectivelyutilized in the derivation process. Project-specific informa-tion and sales knowledge should be added and irrelevantvariability should be pruned. We also present tool supportand illustrate the approach using examples from ongoingresearch collaboration.

1. Introduction

Software product line engineering (PLE) comprises do-main engineering, i.e., modeling the commonalities andvariability of the product line’s core assets; and applica-tion engineering, i.e., deriving products from the productline by selecting, configuring, and integrating the core as-sets [22]. Domain engineering models describe the com-monalities and the variability of relevant core assets such asrequirements, features, architectural elements, or solutioncomponents. These variability models can get quite com-plex due to the diversity of core assets and complex interde-pendencies among them. Utilizing them in actual projects isnot as straightforward and intuitive as it may appear at firstglance. This has also been pointed out by Deelstra et al. [8]:”Deriving individual products from shared software assetscan be a time-consuming and expensive activity”. The un-derlying assumption in PLE that ”the investments requiredfor building the reusable assets during domain engineeringare outweighed by the benefits of rapid derivation of indi-vidual products” [7] might not hold if inefficient derivationdiminishes the expected gains.

In our research collaboration with Siemens VAI, the

world’s leader in the domain of engineering and buildingplants for the iron, steel, and aluminum industry, we are de-veloping an approach for supporting the product derivationand sales processes. A focus of our research is on how toeffectively utilize variability models during product deriva-tion. A key observation is that variability models do notcontain all the information necessary for derivation. Forinstance, sales knowledge (e.g., hints or recommendationsuseful in sales processes) and information concerning theroles of people involved in derivation are usually not partof variability models. This can complicate communicatinga system’s variability to sales people and customers duringrequirements elicitation [14]. It can also complicate the evo-lution of product line assets as sales knowledge is vital tomaintain and evolve a product line [8].

In this paper we present an approach that aims at facili-tating product derivation by augmenting and adapting vari-ability models. Irrelevant parts need to be pruned and ad-ditional project-specific information needs to be added tovariability models, as illustrated in Figure 1. A project-specific derivation model is an adapted and augmented ver-sion of the original variability model. For example, pre-defined products significantly reduce the decision space fordecision-takers such as sales people or project managersduring derivation. Variability models can be enriched withhints and recommendations to provide valuable informationguiding stakeholders during decision-taking. Furthermore,when communicating variability to different stakeholdersinvolved in product derivation, irrelevant aspects for a par-ticular stakeholder need to be filtered out. Dependenciesamong decisions and between decisions and assets need tobe visualized to ensure comprehensibility [21]. All theseactivities take place in application engineering. Tool sup-port is crucial for this purpose.

In previous work we have described our approach tovariability modeling [11, 10] and accompanying tool sup-port [9, 12, 26]. Our earlier work also addresses support forthe integration of product configuration and requirementsengineering in product derivation [25]. The contribution ofthis paper is to describe an approach for adapting and aug-

11th International Software Product Line Conference

0-7695-2888-0/07 $25.00 © 2007 IEEEDOI 10.1109/SPLINE.2007.22

141

Figure 1. Project-specific derivation models.

menting variability models in product derivation to improvetheir utilization. The approach thus can be sees as a bridgebetween our research on domain engineering [11] and ap-plication engineering [25].

This paper is structured as follows: In Section 2 we dis-cuss an example scenario from Siemens VAI. Section 3 de-scribes a meta-model for product derivation models and ac-tivities for building and using it. In Section 4 we present in-tegrated tools supporting our approach. Section 5 discussesrelated work in the field. Section 6 rounds out the paperwith a short summary and an outlook on future work.

2. Product Derivation Scenario

Our industry partner Siemens VAI maintains the CL2software product line for the level 2 automation of contin-uous casting in steel plants [13]. The product line providessophisticated capabilities for optimizing and supervising thecasting process. It is based on a state-of-the-art component-based architecture offering a high degree of variability. Thesize of the code base is about 1.3 Million lines of Java code.

The typical product derivation process of Siemens VAIillustrates the need for adapting and augmenting variabilitymodels. The duration of typical customer projects is be-tween a few months up to more than a year and involvesnumerous meetings between sales people and customers.Customers often wish to upgrade existing steel plants in or-der to improve steel quality by deploying Siemens VAI’smost recent casting technologies. In this case the CL2 solu-tion needs to interoperate with diverse legacy software andhardware systems of the customer. Other customers requirea complete plant solution. Such greenfield projects signif-icantly simplify the CL2 customization. The following en-visaged scenario illustrates a typical product derivation:

1. A customer contacts Siemens VAI and provides initial

documents with fundamental data about the existing plantsuch as the type of the plant or the number of strands forthe caster. Information about level 1 (=underlying machine-oriented automation) and level 3 (=enterprise resource andproduction planning) of the existing plant is also provided.This gives a first overview about legacy software and hard-ware components and available COTS software systemsthat need to be integrated.

2. The Siemens VAI sales manager reviews the variabil-ity model for recent changes by checking out the latest ver-sion from the repository. When reviewing the change log,the sales manager determines that new features for handlingsteel grade have been recently added by the engineeringgroup. The sales manager also notices that the componentSystemObserver providing monitoring capabilities for sys-tem operators now offers a greater degree of variability foradding customer-specific elements to the user interface.

3. Initial sales talks are held to determine the cus-tomer’s high-level requirements. Such high-level require-ments are for example, the desired mechanism for handlingsteel grade, the preferred planning strategy, or the appropri-ate steel cooling mechanism. These high-level requirementsalready significantly constrain the decision space providedby the variability model.

4. The sales manager matches course-grained featuresfrom the variability model with the customers’ high-levelrequirements. This includes for instance features for theintegration of legacy level 1 and level 3 systems. It alsoincludes features for the most appropriate cooling strat-egy for the customer. As the customer is planning to pro-duce steel of extremely high quality the sales manager se-lects DYNACS and does not consider alternative coolingmechanisms such as DynaSpeed and DynaGAP. This meansthat significant portions can be pruned from the variabilitymodel.

5. The project manager deletes further irrelevant deci-sions for this project from the variability model. The knownlevel 1 hardware characteristics of the plant exclude certainfeatures and software components beforehand (e.g., if nomarking machine will be available in the plant, componentsand features regarding marking are not relevant). Also, it isdetermined that a customer’s level 3 legacy system is inca-pable to react to particular CL2 messages due to an archi-tectural mismatch.

6. The sales manager reviews existing sales recommen-dations and hints from past projects and adapts them for thecurrent project where necessary. She adds new hints andrecommendations to customization decisions. For instance,the sales manager provides a video showing benefits of DY-NACS to explain why this cooling approach has been cho-sen. She also takes notes that a new SystemObserver GUIfeature is available as shown in step 2.

7. Together with the project manager, the sales man-

142

ager assigns several sales people to the customization pro-cess and defines their rights and responsibilities. This isdone in parallel to developing a project plan. Furthermore,the lead software architect, the technical project manager,and subsystem owners are defined as decision-takers in thederivation process.

8. The actual customization process starts and severalmeetings of sales people and customers take place to elicitand negotiate concrete requirements and to take the remain-ing configuration decisions.

3. Approach

We have been developing the tool-supported ap-proach DOPLER1 to support the scenario describedin Section 2. The approach consists of integrated capa-bilities for domain engineering and application engineering:

DOPLERVM [9] supports variability modeling andmanagement based on orthogonal variability modeling asapplied by Schmid and John [27] in their approach. Ourmodel-driven approach provides meta-modeling featuresfor defining domain-specific meta-models that can then beused to create domain-specific variability models [10]. Themain modeling elements are assets and decisions. Assetscapture the variability of core assets in the product line.Decisions represent the variation points. Dependenciesbetween assets and decisions are explicitly modeledvia inclusion conditions establishing trace links [11, 10].

DOPLERUCon [26] is a tool-supported approach forproduct configuration with capabilities for adapting andaugmenting variability models to guide sales people and ap-plication engineers through product derivation as shown inthe scenario. A particular emphasis lies on support for re-quirements acquisition and management in application en-gineering [25].

3.1. Preparation for Product Derivation

Product derivation goes beyond pure utilization of vari-ability models by taking configuration decisions. Our sce-nario showed that variability models need to be adaptedand augmented before configuration decisions can be taken.More specifically, several important activities need to becarried out:

Review of current variability model. Sales and projectmanagers review recent changes in the variability model.This is necessary because variability models frequentlychange due to technical evolution or business considera-tions.

1Decision-Oriented Product Line Engineering for effective Reuse.

Definition of roles and responsibilities. Diverse roles areinvolved in product derivation: the customer in need of asolution satisfying his/her specific needs, a sales or projectmanager in charge of pre-configuring high-level decisions,sales people responsible for taking finer-grained decisionsfor a customer, and engineers involved in more technicalconfiguration tasks. These roles need to be planned and as-signed to different stakeholders to define their rights andresponsibilities of viewing, modifying, or taking decisions.

Selection of pre-defined products. A pre-defined prod-uct constitutes an existing product configuration. It couldhave been created for a customer in the past or defined onthe basis of marketing considerations. Product configura-tions can be created by assigning default values to certaindecisions. Often, pre-configured products already closelymatch the requirements of a new customer and can therebyexpedite the derivation process. With proper tool support itis even possible to use such initial configurations to start upsimulators and give the customer an idea how the final sys-tem will look like (thereby taking into account the ”I knowit, when I see it” phenomenon) [25].

Adaptation of the variability model. Certain parts of thevariability model can become irrelevant for a project be-cause of high-level customer requirements. E.g., if no userinterface is requested by the customer parts of the variabilitymodel regarding the HMI (human-machine interface) be-come irrelevant for the project and can be left out. Droppingor hiding decisions for affected stakeholders is important tofine-tune the variability model. Another important aspectis to change the way in which decisions are presented todecision-takers. For example, it can be useful to reformulatethe decisions by taking domain-specific use of languagesinto account. It can furthermore be necessary to constrainthe technically feasible variability for a particular productderivation. For instance, components that are variable inone project may be mandatory in another project. We sup-port such restrictions by a locking mechanism for decisions.Locked decisions are still included in the model but cannotnot be changed during the derivation process. This can helpto avoid costly configuration errors.

Review and adapt sales knowledge. As sales peopleare confronted with a large number of decisions, providingguidance for answering them is desirable. Decision-supportcan be provided in many ways. Hints added to decisions ex-plain the consequences of answering in more detail than justdisplaying the underlying constraints. Multi-media objectssuch as photos or audio recordings help visualizing featuresor explain modeled dependencies and restrictions. Further-more, recommendations can be provided that show addi-tional selling opportunities and remind sales people to em-phasize certain features when interacting with customers.

143

3.2. A Meta-model for Derivation Models

Our discussion explored a number of elements that areimportant for product derivation and typically not containedin variability models . Here we present a meta-model forderivation models that extends our existing orthogonal vari-ability meta-model [11, 9]. The meta-model in Figure 2consists of the following elements:

A decision represents a user intervention needed for theselection of assets required for a concrete product duringproduct derivation. Decisions are abstract representationsof variation points in the asset model. Decisions have tobe taken for all relevant variation points to derive a prod-uct from the available core assets [11]. Logical dependen-cies between decisions describe the known consequencesof taking a decision on other decisions. Hierarchical depen-dencies describe conditions under which a certain decisionneeds to be taken. Decisions can have several states includ-ing created (open to be answered), taken, locked (visible butnot changeable), or hidden for defined stakeholders.

An asset describes an artifact in the product line, e.g., afeature, an architectural element, a solution component, or aresource. Assets are connected with decisions via an inclu-sion condition, i.e., a logical expression determining if anasset will be part of the final product. An asset can be con-nected with an arbitrary number of decisions. A functionaldependency among assets denotes that one asset requiresanother asset (e.g., a component relies on another compo-nent). Structural dependencies are modeled when an assetis part of another asset or contributes in some way to itsexistence (e.g., a component contributes to a subsystem).

Roles are used to describe the responsibilities of projectstakeholders involved in product derivation. Different rightsand responsibilities are assigned to roles, on the basis ofwhich different stakeholders can be presented with a differ-ent view of the variability model. A role can be responsiblefor one or more decisions. For example, a sales person isresponsible for taking high-level decisions while subsystemowners are responsible for decisions regarding their respec-tive subsystem.

Properties are used to customize and preset decisions.Such properties form the basis for adapting variability mod-els. For example, a property can set a default answer for adecision and lock it.

Products describe a non-empty set of properties and canbe used to customize decisions which can be handled as oneentity. This allows the rapid creation of initial configura-tions by defining a set of taken decisions in advance.

Guidance is provided using hints and recommendationsgiving valuable information such as sales knowledge forstakeholders in the derivation process. Augmentation ofvariability models is realized through such guidance ele-ments. Guidance is always provided for one particular deci-

Figure 2. Meta-model for derivation mod-els. The upper half depicts elements of ourhigh-level meta-model for variability model-ing. The lower half augments the meta-modelwith elements essential in product derivation.

sion. For example, a video added to a decision explains itsconsequences and dependencies on other decisions.

4. Tool Support

The approach is supported by a set of integratedtools [12] we have been developing to support the differ-ent activities. The tools were developed for three differ-ent groups of users: product line engineers use Decision-King [9] to create and evolve variability models, projectand sales managers use ProjectKing to prepare and guideproduct derivation projects, whereas sales people and engi-neers use the ConfigurationWizard [25] to derive a product.Figure 3 gives an overview. We briefly describe the roleof the tools in the tool suite and then focus our discussionon the ProjectKing tool which supports sales and projectknowledge definition based on the meta-model discussed inSection 3.2.

4.1. Tool Suite

Our tool suite provides seamless support for variabilitymodeling, project definition, and product configuration (seeFigure 3):

DecisionKing is a variability modeling and managementtool providing a high degree of flexibility and extensibilityvia its plug-in architecture. The tool can be parameterizedto allow the creation of domain-specific variability modelsand has additional capabilities like multi-team modeling,

144

Figure 3. The DOPLER tool suite.

model differencing, and model merging. See [9] and [10]for a detailed description.

ProjectKing guides and supports product derivation andsales processes. It takes variability models created with De-cisionKing as input and produces derivation models accord-ing to the meta-model in Figure 2.

ConfigurationWizard provides capabilities for productcustomization, configuration generation, and requirementsmanagement. It presents the decisions according to thederivation model to its users. Assets that need to be includedin the final product are displayed continuously upon takingdecisions [26]. The tool visualizes dependencies betweendecisions and assets graphically as well as in a tree-basedmanner. Users can generate initial product configurations,i.e., files containing the assets’ names and locations in a de-finable format and property files for the parameterization ofassets. Users can capture new requirements, which have notyet been covered by the product line and generate project-specific requirements specifications in several formats [25].

The activities ”product development” and ”product de-ployment” (cf. Figure 3) are currently not tool-supported as

different companies use different development tools and de-ployment mechanisms. For example, Siemens VAI uses theEclipse platform with diverse plug-ins for product develop-ment as well as Spring-XML and property files to initial-ize and parameterize their software components for deploy-ment. The plug-in architecture of the ConfigurationWizardallows adding generators for product configurations and re-quirement specifications easily to adapt the tool to particularneeds of a domain. The activity ”product line evolution” ispartly supported by all of our tools. We will report on thisin future publications.

4.2. The ProjectKing Tool

We have been developing a tool prototype called Project-King for the creation of derivation models by adapting andpruning variability models. ProjectKing is implemented asan Eclipse plug-in and implements the meta-model (see Fig-ure 2) for creating derivation models. The tool providestwo views: the ProjectKing editor and the model viewer(cf. Figure 4). The ProjectKing editor allows the modifi-cation and adaptation of variability models created by De-cisionKing. The model viewer displays an overview of thecurrent derivation model. After creating a new or loadingan existing project, users can enter administrative details ofthe project such as name, description, or customer infor-mation. They then select an existing variability model onwhich the project will be based or update the adapted vari-ability model currently included in the derivation model.ProjectKing allows conducting the activities described inSection 3.1. Users of the ProjectKing can review the currentvariability model using a graphical or a tree-based modeloverview which visualizes the dependencies among deci-sions and assets in the variability model. The tree-basedmodel overview displays the decisions and their possibleanswers based on their hierarchical dependencies. The con-sequences of taking a decision and pre-conditions for thedecision to become active are also displayed when desiredin a separate view. The Model Viewer displays every ele-ment in the derivation model including the elements of theunderlying variability model. On a separate tab the userof ProjectKing can plan and define the roles and respon-sibilities of product derivation stakeholders by setting per-missions of stakeholders to view certain decisions and assettypes.

Pre-defined products are presented in a table togetherwith properties (cf. Section 3.2) allowing the user to fine-tune the variability model by setting default answers on de-cisions as depicted in Figure 4. The user can select a pre-defined product and relate it to arbitrary properties. Pre-defined products allow the rapid creation of initial config-urations. Only properties and products that do not contra-dict each other can be active at the same time. We have

145

Figure 4. ProjectKing: Creating derivation models by modeling pre-defined products and addingsales knowledge in form of hints and recommendations. The example shows selected examplesfrom Siemens VAI’s CL2 system.

implemented a consistency checker which proves whetherproducts or properties are contradicting. Inconsistencies aremarked visually. Creating products and properties also al-lows the definition of derivation constraints, i.e., by lockingthe decision a property is modeled upon or by locking alldecisions affected by a pre-defined product. These featuresallow the adaptation of the variability model.

Hints and recommendations can be added to a prop-erty and thereby be attached to a decision. This feature iscurrently based on simply embedding HTML code in themodel to refer to multi-media objects stored outside themodel. We are experimenting with this feature to reviewand adapt sales knowledge in projects. Users can for exam-ple insert arbitrary image files, embed audio and video files,and create hyperlinks. The knowledge captured for a spe-cific project can be reused in future projects. The adaptedand augmented variability model contained in the project-specific derivation model can be updated with a new vari-ability model without losing all the captured information.

As soon as these tasks are finished, ProjectKing allowsthe generation of configuration applications based on thedeveloped derivation model. A ConfigurationWizard is

generated as a stand-alone Eclipse Rich-Client applicationwhich can be distributed to stakeholders who take config-uration decisions (e.g., sales people or engineers). Usershave to log in to ConfigurationWizard which performs useradministration and management of user rights based on theroles defined in derivation models.

Figure 5 depicts a ConfigurationWizard displaying a hintmodeled with ProjectKing on the decision ”Shall the 3Dthermal tracking model be used?” (cf. Figure 4). The firsttime a user selects a decision for which a hint is modeled, apop-up window displays the recommendation in a separatedialog. The user can view the hint later whenever she likes.Figure 5 also shows that two decisions, i.e., ”Is the stan-dard CL2 HMI provided?” and ”Shall a Push-Button Panelbe provided in OS1?”, have already been answered as a re-sult of the pre-defined product HMI modeled in the deriva-tion model (cf. Figure 4). The decision ”Is the standardCL2 HMI provided?” can not be changed as it is locked. Ifthe user clicks on the decision a hint modeled in the Projec-tKing before explains the reason for the lock. Some otherdecisions have also been answered automatically by prop-erties in the derivation model (cf. Figure 4), i.e., ”What is

146

Figure 5. ConfigurationWizard generated by ProjectKing displaying a hint.

the scope of the product to be delivered?”, ”Which Dyna-gap strategies shall be used?”, and ”Which models shallbe delivered?”. They can be changed because they arenot locked. If the user attempts to change a decision sheis warned that she is about to overwrite settings of a pre-defined product or property.

As the ConfigurationWizard is based on the same meta-model as ProjectKing it is possible to export the model dur-ing a running project and edit it with ProjectKing, e.g., tochange the locked state of a decision or to model additionalhints. This is very important in the case of Siemens VAI astypical projects can take several months or even longer (cf.Section 2). In such long-running projects it is likely that theunderlying variability model evolves over time. In this casethe derivation model’s underlying variability model can bechanged. Pre-defined products and properties or hints andrecommendations that point to decisions which no longerexist can either be dropped or mapped to other decisions.Changes on element’s dependencies or newly created ele-ments need to be taken into account. This way, derivation

models from previous projects can also be reused as a basisfor future projects.

5. Related Work

We focus the discussion of related work on papers pre-senting problems and issues of product derivation and onwork regarding guidance for product derivation that had aninfluence on our research. We also summarize capabilitiesof existing tools with respect to guidance and support forproduct derivation.

Problems and issues of product derivation. Deelstra etal. [7, 8] identify two core issues faced by organizationsin product derivation: complexity and implicit properties.Complexity emerges from a typically large number of vari-ation points and variants defined in the variability model.This makes the selection of variants very difficult, espe-cially for an individual stakeholder. We believe that supportfor adapting, pruning, and filtering large variability modelsto a project context as provided by our approach can help

147

in coping with this problem. Implicit properties are a resultof undocumented or unknown dependencies between vari-ants. As a consequence product derivation strongly dependson expert involvement. Providing explicit support for doc-umenting dependencies and their rationale is therefore veryimportant. Our approach supports this with hints and rec-ommendations. Visualization of dependencies can also helpand is provided in the ProjectKing as well as in the Config-urationWizard.

Other researchers have identified similar issues: For ex-ample, Halmans and Pohl [14] emphasize the difficultyof communicating the variability of a product line to cus-tomers. Hunt [16] focuses on improving the organization oflarge asset bases for product derivation. Nestor et al. [21]emphasize the idea of using existing software visualiza-tion techniques to support the management of industrial-size product lines. They agree that product derivation can betime-consuming and expensive and lacks appropriate sup-port. They also identify the underlying complexity andinherent dependencies of variants described in variabilitymodels as a major cause of derivation problems.

Guidance in product derivation. Product derivation istypically guided and supported by production plans pro-duced in domain engineering. A production plan ”describeshow the products are produced from the core assets (. . . )it is, in effect, the reuser’s guide to product developmentwithin the product line” [5]. Chastek and McGregor haveproposed guidelines for creating, using, and evaluating suchproduction plans [4]. Chastek et al. [3] report on a studyon how product line organizations typically create products.Attendees of the first and second Software Product LinesConferences were asked to complete a questionnaire aboutproduct production in PLE. The results indicate that differ-ent organizations pursue very different approaches to prod-uct production. While [4, 3] focus on the process and man-agement aspects of production planning, Lee et al. [20] em-phasize technical aspects and propose a feature-based ap-proach for product line production planning. Form and con-tents of production plans vary from organization to organi-zation and also depend on the concrete PLE approach. Suchplans are a good means to describe the process – that is theinputs, activities, roles, and outputs – of deriving productsfrom a product line. However, production plans are usuallyjust a document with a rather informal description on how toderive products from the core asset base. Production plansare necessary but cannot replace explicit guidance and tool-support for product derivation. They are also not meant tobe used in capturing project-specific sales knowledge. Pro-duction plans can, however, provide valuable input for ourapproach.

The specialization of variability models as proposed byCzarnecki et al. [6] in their paper on staged configurationusing feature models also provides ideas on how to adapt

variability models. Our work also emphasizes that in a real-istic development process variability is resolved by differentgroups and people in different stages. The ConIPF Method-ology [15] proposed by Hotz et al. also offers interestingconcepts for product derivation by combining product lineengineering and knowledge-based configuration.

Derivation support in product line tools. Several com-mercial and research tools support different aspects of prod-uct line derivation. Current tools do provide rather weaksupport for non-technicians such as sales experts using vari-ability models in product customization [24, 26]. Present-ing the entire variability of the system using feature- [18] orUML-based models [2] often overwhelms non-technicians.Large variability models have to be pruned and guidance forproduct derivation needs to be provided.

Existing tools such as pure::variants [23], Gears [19],FeaturePlugin [1], or RequiLine [28] consider planning andsupport for the derivation process as outside their scope.Also, technical product configuration (or derivation) pro-cesses are rather weakly integrated with sales processes.This neglects that in real-world projects derivation deci-sions are often taken during sales talks. Existing tools donot provide sufficient guidance for product derivation andsales processes. Tools from the area of customer relation-ship management (CRM) are capable to manage customerinformation to guide people from sales, marketing, and sup-port divisions in their interaction with customers. However,CRM capabilities are currently not integrated with existingproduct line tools.

6. Conclusions and Future Work

In this paper we emphasized that a direct utilization ofdomain variability models in product derivation is hardlypossible. Instead, an intermediate derivation model isneeded that contains valuable information for people in thederivation process (e.g., sales people). We have describedkey ingredients of such derivation models. We believe thatsuch models help narrowing the gap between domain andapplication engineering and expedite the derivation process.Using examples from our industrial partner Siemens VAIwe illustrated our idea of how sales and project managerscan adapt a variability model to produce derivation models.We have shown tool support for this task and presented theprototype ProjectKing capable of capturing the knowledgenecessary for such adaptation tasks.

We are still working on improving our approach and ac-companying tools and especially plan to focus on the fol-lowing issues in our future work:

Business decision-making in PLE. We plan to better sup-port economic aspects of PLE with our approach. For ex-ample, cost-benefit analyses and trade-off estimations forproduct derivation projects should be supported. We are

148

currently investigating existing product line cost estimationmodels, as for example proposed by In et al. [17], for thispurpose.

Product line maintenance and evolution. We are cur-rently also working on improving support for evolution. Itis already possible to match a new variability model’s de-cisions with the decisions in the existing derivation modelby name. DecisionKing provides model merging and differ-encing capabilities (cf. [9]) that we plan to adapt for provid-ing such capabilities in the ProjectKing too. Further mech-anisms, for example, support for reusing sales knowledgemodeled in past projects by making it available in the prod-uct line’s variability model, also need to be considered.

A key to the success of the approach is that beyond thetechnical aspects of tool integration a company succeedsin integrating people. Diverse people from different disci-plines have to contribute to and support such an integratedderivation process. We will report experiences on this in thefuture.

7. Acknowledgements

This work has been conducted in cooperation withSiemens VAI and has been supported by the ChristianDoppler Forschungsgesellschaft, Austria. We would liketo express our sincere gratitude to Klaus Lehner, ChristianFederspiel, and Hubert Preissl from Siemens VAI for theirsupport and for sharing valuable insights. We also want tothank Iris Groher for valuable comments on earlier drafts ofthis paper.

References

[1] M. Antkiewicz and K. Czarnecki. FeaturePlugin: Featuremodeling plug-in for eclipse. In OOPSLA’04 Eclipse Tech-nology eXchange (ETX) Workshop, pages 1–6, Vancouver,Canada, 2004.

[2] C. Atkinson, J. Bayer, C. Bunse, E. Kamsties, O. Lait-enberger, R. Laqua, D. Muthig, B. Paech, J. Wust, andJ. Zettel. Component-Based Product Line Engineering withUML. Addison-Wesley, 2002.

[3] G. Chastek, P. Donohoe, and J. McGregor. A study of prod-uct production in software product lines. Technical report,CMU/SEI-2004-TN-012, 2004.

[4] G. Chastek and J. McGregor. Guidelines for developing aproduct line production plan. Technical report, TechnicalReport CMU/SEI-2002-TR-006 ESC-TR-2002-006, 2002.

[5] P. Clements and L. Northrop. Software Product Lines: Prac-tices and Patterns. SEI Series in Software Engineering,Addison-Wesley, 2001.

[6] K. Czarnecki, S. Helson, and U. Eisenecker. Staged con-figuration using feature models. In R. Nord, editor, LectureNotes in Computer Science: Software Product Lines, Third

International Conference (SPLC 2004), Proceedings, vol-ume LNCS 3154, pages 266–283. Springer Berlin / Heidel-berg, 2004.

[7] S. Deelstra, M. Sinnema, and J. Bosch. Experiences in soft-ware product families: Problems and issues during productderivation. In R. Nord, editor, Lecture Notes in ComputerScience: Software Product Lines, Third International Con-ference (SPLC 2004), Proceedings, volume LNCS 3154,pages 165–182. Springer Berlin / Heidelberg, 2004.

[8] S. Deelstra, M. Sinnema, and J. Bosch. Product derivation insoftware product families: a case study. Journal of Systemsand Software, 74(2):173–194, 2005.

[9] D. Dhungana, P. Grunbacher, and R. Rabiser. DecisionKing:A flexible and extensible tool for integrated variability mod-eling. In K. Pohl, P. Heymans, K.-C. Kang, and A. Metzger,editors, First International Workshop on Variability Mod-elling of Software-intensive Systems - Proceedings, pages119–128. Lero - Technical Report 2007-01, Limerick, Ire-land, 2007.

[10] D. Dhungana, P. Grunbacher, and R. Rabiser. Domain-specific adaptations of product line variability modeling. InIFIP WG 8.1 Working Conference on Situational MethodEngineering: Fundamentals and Experiences, Geneva,Switzerland, September 12-14, 2007.

[11] D. Dhungana, R. Rabiser, and P. Grunbacher. Decision-oriented modeling of product line architectures. In SixthWorking IEEE/IFIP Conference on Software Architecture,pages 22–25, Mumbai, India, 2007. IEEE Computer Soci-ety.

[12] D. Dhungana, R. Rabiser, P. Grunbacher, K. Lehner, andC. Federspiel. DOPLER: an adaptable tool suite for prod-uct line engineering. In 11th International Software ProductLine Conference (SPLC 2007), Kyoto, Japan, September 10-14, 2007.

[13] C. Federspiel, J. Bogner, N. Hubner, R. Leitner,W. Oberaigner, K. Konig, and L. Lindenberger. Next genera-tion level2 systems for continuous casting. In 5th EuropeanContinuous Casting Conference (ECCC), pages x–y, Nice,France, 2005. IOM Communications Ltd.

[14] G. Halmans and K. Pohl. Communicating the variabilityof a software-product family to customers. Informatik -Forschung und Entwicklung, 18(3-4):113–131, 2004.

[15] L. Hotz, K. Wolter, T. Krebs, S. Deelstra, M. Sinnema, J. Ni-jhuis, and J. MacGregor. Configuration in Industrial Prod-uct Families - The ConIPF Methodology. IOS Press, 2006.

[16] J. Hunt. Organizing the asset base for product derivation.In L. O’Brian, editor, Proceedings of the 10th InternationalSoftware Product Line Conference (SPLC 2006), pages 65–74. IEEE Computer Society, 2006.

[17] H. In, J. Baik, S. Kim, Y. Yang, and B. Boehm. A quality-based cost estimation model for the product line life cycle.Communications of the ACM, 49(12):85–88, 2006.

[18] K. Kang, J. Lee, and P. Donohoe. Feature-oriented productline engineering. IEEE Software, 19(4):58–65, 2002.

[19] C. Krueger. Software mass customization. Technical report,BigLever Software, Inc., 2001.

[20] J. Lee, K. Kang, and S. Kim. A feature-based approach toproduct line production planning. In R. E. Nord, editor, Lec-ture Notes in Computer Science: Software Product Lines,

149

Third International Conference (SPLC 2004), Proceedings,volume LNCS 3154, pages 183–196. Springer, 2004.

[21] D. Nestor, L. O’Malley, A. Quigley, E. Sikora, and S. Thiel.Visualisation of variability in software product line engi-neering. In K. Pohl, P. Heymans, K.-C. Kang, and A. Met-zger, editors, First International Workshop on Variabil-ity Modelling of Software-intensive Systems, Proceedings,pages 71–78. Lero - Technical Report 2007-01, Limerick,Ireland, 2007.

[22] K. Pohl, G. Bockle, and F. van der Linden. Software ProductLine Engineering: Foundations, Principles, and Techniques.Springer, 2005.

[23] pure systems GmbH. Variant management withpure::variants, technical whitepaper, http://www.pure-systems.com/fileadmin/downloads/pv-whitepaper-en-04.pdf, 2006.

[24] R. Rabiser. Facilitating the involvement of non-techniciansin product configuration. In I. John, L. Bass, and G. Lami,editors, Proceedings of the Software Product Lines DoctoralSymposium, In conjunction with the 10th Software Prod-uct Lines International Conference (SPLC), pages 13–22.Fraunhofer IESE (IESE-Report No. 104.06/E), 2006.

[25] R. Rabiser and D. Dhungana. Integrated support for prod-uct configuration and requirements engineering in productderivation. In 33rd EUROMICRO Conference on SoftwareEngineering and Advanced Applications (EUROMICRO-SEAA 2007), Lubeck, Germany, August 27-31, 2007.

[26] R. Rabiser, D. Dhungana, P. Grunbacher, K. Lehner, andC. Federspiel. Product configuration support for nontech-nicians: Customer-centered software product-line engineer-ing. IEEE Intelligent Systems, 22(1):85–87, 2007.

[27] K. Schmid and I. John. A customizable approach to full-life cycle variability management. Journal of the Science ofComputer Programming, Special Issue on Variability Man-agement, 53(3):259–284, 2004.

[28] T. von der Maßen and H. Lichter. Requiline: A requirementsengineering tool for software product lines. In F. van derLinden, editor, Lecture Notes in Computer Science: Soft-ware Product-Family Engineering 5th International Work-shop, PFE 2003, volume LNCS 3014, pages 168–180.Springer Berlin / Heidelberg, 2004.

150