What is a Feature?

A Qualitative Study of Features

in Industrial Software Product Lines

Thorsten Berger1 , Daniela Lettner2 , Julia Rubin3 , Paul Grünbacher2 , Adeline Silva4 ,
Martin Becker4 , Marsha Chechik5 , Krzysztof Czarnecki1
1
University of Waterloo, 2 Johannes Kepler University Linz, CD Lab MEVSS, 3 Massachusetts Institute of Technology,
4
Fraunhofer IESE, 5 University of Toronto

ABSTRACT concept (system, component, etc.) that is relevant to some

The notion of features is commonly used to describe the stakeholder of the concept” [9]. In fact, many additional
functional and non-functional characteristics of a system. In definitions of the term feature can be found in the literature [1,
software product line engineering, features often become the 17, 32, 15, 25, 18, 23, 20, 8, 31].
prime entities of software reuse and are used to distinguish the Yet, companies still face difficulties in deciding when to
individual products of a product line. Properly decomposing introduce a feature, determining the right level of granularity
a product line into features, and correctly using features in for a feature, and defining the aspects that should be taken
all engineering phases, is core to the immediate and long- into consideration when engineering features. Without this
term success of such a system. Yet, although more than ten knowledge, using SPLE concepts and the numerous existing
different definitions of the term feature exist, it is still a very tools for managing product line features is problematic. In
abstract concept. Definitions lack concrete guidelines on how fact, all authors of this paper—when presenting feature-
to use the notion of features in practice. related engineering or analysis techniques—are commonly
To address this gap, we present a qualitative empirical faced with the question: “What is a feature?”
study on actual feature usage in industry. Our study cov- In this paper, we aim to address this issue by empirically
ers three large companies and an in-depth, contextualized investigating the experiences of three successful industrial
analysis of 23 features, perceived by the interviewees as companies that develop software product lines (SPLs) and
typical, atypical (outlier), good, or bad representatives of explicitly manage features. We conducted a qualitative study
features. Using structured interviews, we investigated the to elicit, understand, and describe features managed by the
rationales that lead to a feature’s perception, and identified companies. We also describe the companies’ perspective on
and analyzed core characteristics (facets) of these features. their successes and failures in managing features.
Among others, we found that good features precisely describe Our main goal is to improve the empirical understanding
customer-relevant functionality, while bad features primarily of the notion of features in industry, by providing insights
arise from rashly executed processes. Outlier features, serv- into the range of real-world feature definitions and usages.
ing unusual purposes, are necessary, but do not require the We rely on semi-structured interviews, whose design and
full engineering process of typical features. analysis was guided by two main research questions:
RQ1: What reasons cause companies to perceive a fea-
ture as typical, atypical, good or bad? We studied concrete
1. INTRODUCTION examples of features by asking our interviewees for typical,
Software Product Line Engineering (SPLE) approaches rely atypical (outlier), good, and bad exemplars, and by diving
on identifying and explicitly managing commonalities and into the reasons for such classification. Our intention was
variabilities of a product portfolio. These commonalities and to be as open as possible, trying to disambiguate existing
variabilities are often captured in an abstract manner using perceptions of features among our interviewees.
entities called features. The use of features is motivated RQ2: What are important characteristics of features?
by the fact that customers and engineers often speak of When discussing each feature, we asked the interviewees
product characteristics in terms of features a product has to describe its different facets: intrinsic qualities of a feature,
or delivers. A feature is usually defined as “a logical unit of such as its purpose within the software lifecycle or its binding
behavior specified by a set of functional and non-functional time. Using feature facets as the basic terminology allowed
requirements” [7] or “a distinguishable characteristic of a us to structure the discussion, to compare the features across
companies, and to organize our findings.
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
We present first-hand opinions of industrial practitioners
for profit or commercial advantage and that copies bear this notice and the full citation on practices contributing to the development of features that
on the first page. Copyrights for components of this work owned by others than the are perceived as typical, successful or failing. In addition
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission
to narrative descriptions of features and their classification
and/or a fee. Request permissions from [email protected]. rationales, we provide an in-depth cross-case analysis of
SPLC 2015, July 20 - 24, 2015, Nashville, TN, USA all the features. In summary, we contribute: (i) a set of
c 2015 Copyright held by the owner/author(s). Publication rights licensed to ACM. facets that can be used as a terminology for describing and
ISBN 978-1-4503-3613-0/15/07. . . $15.00 comparing features (Table 2); (ii) reasons (rationales) for
DOI: http://dx.doi.org/10.1145/2791060.2791108
 Table 1: Interview participants by consulting the existing literature [19, 7, 8, 10], and then
part.1 role exp.2 features
further refined based on our previous collaborations with the
A developer 12 LINMovement, Oscilloscope, Euromap, studied companies. More specifically, three of the authors
SilentMode
B product 19 ProfiNetSlave, Wizard, created within-case writeups of the general architecture and
Keba

manager ManualConfiguration, UserGuidance the organizational structure of each company, which were
C developer 3 LanguageTranslation,
ProductionOverview, DataManager, then used to guide the definition of the facets. The resulting
HeatUpOptimization set of facets, along with their description and clarifying
Opel

D team lead/ 5 LaneKeeping, ParkAssist, examples, are given in Table 2.

architect EmergencyBraking
Interview Process. We started the interview with ques-
E architect 4 Torque, CascadeController, ProductG,
tions about our interviewees themselves, including (i) their
Danfoss

PowerUpFastFuncs
F team lead 8.5 Wobbler, FieldBus, ResetFix, professional background, (ii) how long they have been work-
BoardSupportPackage
ing in the current profession, (iii) how long they have been
1 2
participant (interviewee) experience with the product line in years involved with the product line, (iv) their role in the product
line, and (v) the number of features they were involved with.
a feature being classified as typical, outlier, good, or bad We then asked each interviewee to describe three to four
(Table 4); (iii) a range of values for different facets of concrete features, providing guidance in the selection process. We
features engineered in industry (Sec. 6); and (iv) a set of core asked for one typical, one outlier, one good, and one bad
observations from the cross-case analysis that have practical feature. Our goal was to be as open as possible, leaving
impact on engineering features for SPLs. it to our interviewees’ judgment which criteria to use for
We proceed by outlining our research methodology in Sec. 2. selecting a feature for each type. Yet, to provide some
We then introduce the subject companies and their product guidance, we gave some hints, for instance, that a good
lines in Sec. 3. We address RQ1 in Sec. 4 and 5, where we feature could be one that is well-received and popular with
present features and their classification rationales. In Sec. 6, customers, commercially successful, or on time, on budget,
we address RQ2 with the cross-case analysis of the feature easily reusable, or has a low defect count. For a bad feature,
facets. Finally, we discuss threats to validity in Sec. 7 and we said it could be one that is problematic, troublesome,
related work in Sec. 8, and conclude in Sec. 9. difficult to develop, confusing, buggy, or one that destroyed
user confidence, damaged the brand, or showed unexpected
2. RESEARCH METHODOLOGY behavior. An outlier is a feature whose properties are rarely
observed in other features. Finally, a typical feature is neither
We describe how we selected the companies for our study
especially good nor bad, and not an outlier in any sense.
and present our approach to designing and conducting the
For each feature described by the interviewees, we asked
interviews and analyzing the results.
about the reasons why they considered it to be typical, good,
2.1 Company Selection bad, or outlier. We then asked to discuss the feature from the
perspective of each facet. When interviewees had difficulties
To conduct our study, we focused on companies that (i) de-
answering our questions, we used a “by example” strategy,
velop SPLs; (ii) explicitly record, track, and manage features—
providing possible answers to our facet questions, as described
both common and variable ones; and (iii) maintain an active
in Table 2. In the case of surprising responses, we dug deeper
collaboration with at least one of the authors of this paper.
by asking specific questions, trying to elicit the underlying
Our selection criteria ensured that we consider “meaningful”
reasons for such responses.
examples that are of general interest to the SPL community,
and that allowed us to reliably interpret the findings based 2.3 Data Collection and Analysis
on our understanding of the companies’ product lines and
Each of the conducted interviews was fully recorded, with
their organizational context.
the obtained recordings lasting between 68 and 117 min-
We selected the three companies Keba, Opel, and Dan-
utes. In addition to these, core answers to our facet-related
foss from the domains of industrial automation, automotive,
questions were summarized by the interviewer during the
and power electronics. For each company, we selected up to
interview itself. These summaries were further cross-checked
three interviewees, covering a range of roles, such as product
against the recording by an author who did not participate in
manager, architect, and developer. For Opel, we interviewed
the corresponding interview. Such reviews were used to verify
a single person. Overall, we collected data about 23 fea-
the summaries and to augment them when needed. The ob-
tures: twelve from Keba, three from Opel, and eight from
tained information was used to describe the company-specific
Danfoss. Table 1 summarizes our interviewees, their roles,
features in terms of their facets in Sec. 6.
their experience with the product line, and the features they
Moreover, we created full transcripts for parts of the inter-
described.
views that discuss the rationale behind considering a feature
2.2 Interview Design as good, bad, typical, or outlier. We applied open coding [2]
to identify the main concepts related to this classification,
Feature Facets. The goal of our study was to collect
which are discussed and exemplified in Sec. 4 and 5.
examples of features developed in industrial practice, and
to outline the reasons for specific features being considered
good, bad, typical, or outliers. To gain insights into these 3. SUBJECT COMPANIES
questions, we conducted a set of semi-structured interviews We now provide background information about our subject
with employees of the studied companies. companies and the product lines they develop.
We structured our interviews around feature facets—quali-
ties of features that we aimed at exploring, such as lifecycle 3.1 Keba: Industrial-Automation Provider
purpose and binding time. These facets were initially defined Keba AG is a medium-scale company producing injection
 Table 2: Variety of feature facets elicited in interviews
facet question examples
Rationale Why does the feature exist? Business reasons (e.g., customer request, market demand), regulatory needs (e.g., export
restriction, country codes), aspects of the technical environment (e.g., platform, OS, library,
installation environment) or social aspects (e.g., usage context, user needs)
Level At what organizational level does the feature exist? Customer-facing features (e.g., those managed by product managers) or technical features
(e.g., logical and physical architecture, or implementation-level features)
Nature What is the nature of the feature? Primarily a unit of functionality (e.g., to characterize system capabilities, behavior, or data),
a unit of variability (e.g., an optional functionality) or a configuration/calibration parameter
Scope What is the scope of the feature? Local to one component of a system or cross-cutting (i.e., scattered across architectural
components)
Architectural What is the architectural responsibility of the feature? Addresses user-interface requirements, encapsulates some application logic, or
responsibility infrastructure-level tasks
Lifecycle Does the feature have a purpose for the lifecycle of a Testing, debugging, build, optimization, packaging, deployment, simulation, or monitoring
system?
Definition and approval How has the feature been defined and approved? Feature elicitation workshops with customers, systematic studies of similar system, or
market analyses
Representation Which artifacts/tools are used to define the feature? Feature models, configuration tools, code-level configuration options, product maps, or
spreadsheets
Use In what ways is the feature used in the organization? Defining a product line’s scope, explaining a system to a customer, changing behavior at
runtime, or supporting software composition
Dependencies What are the dependencies to other features? Dependencies between features (e.g., require or exclude), dependencies across levels (e.g.,
to logical and physical components)
Implementation and Which languages and technologies have been used to Programming languages used, build-time integration of libraries, feature deployment in app
deployment implement and deploy the feature? stores
Inclusion/Exclusion Which mechanisms are used for including or Configuration tool, configuration file, user preferences at runtime
excluding the feature?
Binding time At what stage is the feature included into the product? Compile, build, load, or run time
Responsibility Which people, roles, or teams are in charge of the Application engineers developing customer-specific features, platform engineers
feature? developing core functionality
Position in hierarchy What are the features above (if any) and the features Concrete feature names or not applicable
below (if any)?
Testing Which methods and tools are used for testing the Automated component test suites or manual system integration tests
feature?
Evolution How did the feature change over time? Changed frequently (e.g., daily, weekly or monthly), mostly stable, rolled out, or retired
Metrics Which metrics are used to characterize the feature? Number of products in which a feature exists, number of feature instances per product
Quality and performance Which non-functional characteristics are important Reaction time, power consumption, or efficiency of a feature implementation
for the feature?

molding machines, energy appliances, and robotics solutions cific I/O-ports; by modifying parameters to influence program
used for industrial automation [22]. Around 700 people are behavior; by adapting configuration files to change system
employed at the head office in the company’s home coun- behavior and performance as well as by pre-processing code
try Austria, while a branch in China exists for the Chinese to integrate specific product variants during compilation.
market. Keba’s industrial-automation solutions include hard- Organizational Structure. Dedicated teams maintain
ware, software, and tools. We focus on the software product the automation platform and the domain-solution platforms.
lines for injection-molding and robotics solutions. Keba ships Project teams then work with customers on individual prod-
about 7,000 injection-molding solutions to 25 customers per ucts. There are also external developers contributing code—
year. Four resellers are available for the injection-molding for example, domain engineers working for OEMs, and appli-
branch. Furthermore, Keba sells about 1,800 robotics so- cation engineers working for resellers. This has a significant
lutions to about 30 customers per year and works with six impact on Keba’s development process, challenging platform
resellers related to the robotics branch. evolution in particular. Domain-solution engineers regularly
Architecture. Layered technological platforms exist in review and prioritize features for upcoming releases.
diverse variants to meet requirements in different market
segments. Keba’s automation platform is organized as a
product line, and different variants are derived to develop
3.2 Opel: Car Manufacturer
domain solutions for injection molding, robotics, and energy Opel is a German subsidiary of GM—a large car manu-
automation. The platform for injection-molding machines facturer operating across 157 countries, comprising 202,000
provides an application framework, while the robotics plat- employees, and having sold 9 million vehicles in 2011.
form uses a DSL-based approach for programming robots. Opel has software product lines aligned with the mechani-
The different layers and their interfaces strongly influence the cal product lines and the engineering culture of cars. The
development process: multiple system platforms are derived product lines discussed in this paper are part of an initiative
from a system platform architecture to support multiple at GM called Next Generation Tools (NGT) [14], created
runtime systems. Domain solutions are built on top of each to handle the complexity introduced as a by-product of new
system platform, by exploiting the interfaces of the platform. technologies, such as hybrid and alternative-fuel engines.
Products are defined by adding new functionality on top of SPLE plays a major role in the NGT and is implemented
the domain solutions using cloning. Products are fine-tuned following the Second Generation PLE (2GPLE) approach, in
using configuration parameters during installation and setup. which features are treated as first-class citizens. Vehicles can
Keba uses a wide range of variability mechanisms to sup- now be described in terms of a bill-of-features, which facili-
port product derivation: Platform and product variants are tates the communication between business, marketing, and
created by exploiting interfaces to hook in new functionality; engineering units. The tool used for modeling the features
by adding, exchanging or reloading modules; by defining spe- is BigLever GEARS. The development process is organized
in five different levels covering feature model, requirements,
logical architecture, technical architecture, and deployment. tended to other artifacts, such as requirements and test
Development activities correspond to the “V-Model”: The cases [30]—enabling the derivation of variants of these arti-
process starts with defining requirements and architecture facts by configuration and improving traceability.
for the future vehicle, and at the bottom of the V-Model Organizational Structure. A dedicated team involving
is the creation of hardware and software components that software architects from all development sites supports and
correspond to the requirements specification. maintains the platform. Application-engineering teams con-
Architecture. Opel uses a system-of-systems architec- tribute new functionality of the drives. However, there is
ture managed as a hierarchical product line of product lines. no real split between application and domain engineering.
It covers domains, subsystems, functions, functional elements, The platform team is also responsible for the feature-model
and components (being aggregations of functional elements). development, and each feature is assigned to a feature owner.
The software components are as general as possible to allow From the product perspective, there are product managers
flexibility with respect to variations. The manufacturing who determine which features will go into a product. When
process is driven by the selection of features and part num- there is a change request for a particular feature, the product
bers of physical car components that determine which ECUs manager has to contact the feature owner.
(electronic control units) are in the car. The ECUs contain
the feature implementation, and their presence determines 4. TYPICAL AND OUTLIER FEATURES
whether a feature is available. The software components are
We now introduce concrete examples of the features we
specifically configured for every produced vehicle. In this
studied, beginning with typical and atypical (outlier) features.
calibration process, the Vehicle Option Codes—parameters
We discuss the rationales behind our interviewees’ classifica-
determining the startup of optional software components
tion, complementing them with quotations. Table 3 shows
installed by ECUs in the car—are saved to a flash database.
all features with their ID and the respective classification-
Organizational Structure. There are different teams,
rationale codes. These codes—indicated by special for-
including individual teams for each product line; they are
matting in the following descriptions—are further explained
referred to as a body of knowledge—the teams have special-
in Table 4.
ized knowledge about the instantiation of their product line.
There is also the concept of a feature owner, referring to the 4.1 What is a Typical Feature?
main technical contact person in charge of a feature. The
Most interviewees argued that typical features represent
feature owner also models the feature in GEARS.
core functionality of the domain and are, thus, a prime prereq-
uisite for a company’s business. The feature Danfoss.Wobbler
3.3 Danfoss: Component Producer is an example: It was not explicitly requested by a customer,
Danfoss is a large producer of electronic and mechanical but is regarded essential in the textile industry domain as it
components for industrial and consumer applications. It has allows frequency converters to operate properly without pro-
23,000 employees globally, distributed across 56 factories in ducing waves. Another feature providing core functionality
18 countries. We focus on Danfoss Drives, a subdivision is Keba.ProfiNetSlave, implementing inter-machine communi-
producing frequency converters (drives), which are used in a cation based on the Industrial Ethernet standard Profinet.
wide range of applications, such as for HVAC or for winding Other typical features are either generally demanded by
machines in the textile industry. Consequently, the drive the market or requested by a specific customer. For instance,
firmware has a high degree of variability, as the motors the feature Opel.LaneKeeping satisfies a very common mar-
to be controlled vary significantly. While the variability ket demand expressed nowadays by car buyers. Customer
had initially been handled using a clone&own approach [12], requests are also considered as common examples, such
Danfoss later adopted an SPLE approach by migrating the as expressed by interviewee E: A typical feature is one re-
cloned products into an integrated platform [16]. quested by a customer, a new motor control for example. It’s
Architecture. Danfoss has multiple product lines, each a functional one. He refers to Danfoss.Torque, which extends
realized with a typical embedded-platform architecture and existing motor-control functionality.
a codebase of a few million lines of C/C++ code. Our focus, Keba.LanguageTranslation is another example of a typical
the frequency-converter product line, consists of a platform, feature, as it was realized following a management decision
which realizes 14 main products, complemented with addi- (internal standard) to offer certain system localizations by
tional repositories of 30 extensions (“sub-products”). The default to support customers in specific regions. It was also
platform’s variability is realized using the C/C++ preproces- marked as typical since it represents ubiquitous functional-
sor by referencing static features in conditional-compilation ity affecting not only the EasyNet control-station program
directives (e.g., #IFDEF); by generating build files; and by for which it was initially conceived, but now almost all parts
using dynamic parameters that influence the run-time of a of the product line.
concrete product.
Features are defined in a feature model and mapped to 4.2 What is an Outlier Feature?
source files using the commercial tool pure::variants from Not surprisingly, there is less agreement in what constitutes
pure::systems. Upon creating a configuration (i.e., a selection an outlier feature, with almost everyone giving different
of features), pure::variants generates the build files and the reasons. Neither did we observe any overlap in the rationales
set of parameters belonging to the product-specific configura- between classifying a feature as typical or as an outlier.
tion. Not all parameters are present in all products, and the For instance, the feature Keba.SilentMode enables instal-
configuration of these parameters (e.g., limits and default lations without user interaction. It is realized as a hidden
values) varies considerably across products. command-line option of the setup program and only used
Initially, only variability in source code was managed. Fol- internally for testing; it does not provide a core functionality
lowing positive experience, variability management was ex- for customers (deployment).
 Table 3: Features and their classification rationales
company feature ID feature description classification rationale
Keba LINMovement linear movement command of a robot domain
Keba ProfiNetSlave implementation of the PROFINET standard for the fieldbus communication stack domain, market demand
typical

Keba LanguageTranslation translation of the EasyNet control-station program into several languages ubiquitous, market demand, internal
standard
Opel LaneKeeping driver assistance to keep the lane, including active steering domain, market demand
Danfoss Torque enables high starting-torque for permanent-magnet machines customer request
Danfoss Wobbler smooths the movement of electric motors (to avoid waves) in the textile industry domain
Keba SilentMode non-interactive (“silent”) installation procedure deployment
Keba UserGuidance user guidance for device configuration placeholder, usability
outlier

Keba HeatUpOptimization optimizes heat-up procedures of multiple machines by distributing power peaks optimization, startup
Danfoss PowerUpFastFuncs moves the execution of some functions from the flash drive to the RAM optimization, build
Danfoss BoardSupportPackage new Hardware Abstraction Layer (HAL) to improve board support evolvability, maintainability
Keba Oscilloscope software oscilloscope for recording signals error-free
Keba Wizard wizard-based configuration support for the initial robot setup popular with customers
Keba ProductionOverview historical overview on the production process (operation modes and “shots”) popular with customers, popular
good

with developers
Opel ParkAssist automated steering in parking situation well modularized
Danfoss CascadeController enables control of multi-drive (pump) setup to manage pressure or level well implemented, well modularized
Danfoss FieldBus enables the fieldbus communication stack for frequency converters distinct functionality, well
modularized, thoroughly tested
Keba Euromap enables the Euromap protocol support in the fieldbus communication stack test challenges, frequent changes
Keba ManualConfiguration manual configuration of EncoderBox market demand, rushed development,
customer complaints
bad

Keba DataManager export/import of low-level machine data rushed development, workaround,

variability
Opel EmergencyBraking autonomous emergency braking highly cross-cutting
Danfoss ProductG implements product-specific features for one particular customer highly cross-cutting
Danfoss ResetFix fixes a defect in another feature (Reset Counter) defect fix, frequent changes

Another interesting example is the feature Keba.UserGui- 5. GOOD AND BAD FEATURES
dance, which serves as a placeholder for product managers We also studied features perceived as good or as bad by
to plan future usability improvements regarding device- our interviewees. Similar to the discussion above, we now
configuration support. Specifically, users requested better introduce examples of such features, describe the underlying
dependency resolution and choice propagation in the con- classification rationales, and provide illustrative quotations.
figurator to catch misconfigurations early, which otherwise
could only be discovered at system startup. Our interviewee 5.1 What is a Good Feature?
also classified this as a bad feature since it is too vague (ex-
plained shortly in Sec. 5.2) and needs refinement. B: We In two cases, our interviewees mentioned customer satis-
didn’t really know how to improve it. That’s why we are using faction (popular with customers) as their prime rationale
it as a placeholder for projects where one needs to improve for considering a feature as good. For instance, the feature
something. [...] Basically, it’s an accumulative feature. Keba.Wizard allows performing the initial robot setup and
Two of the outlier features—Keba.HeatUpOptimization and installation within a few minutes by avoiding error-prone
Danfoss.PowerUpFastFuncs—were only introduced for the manual configuration. Keba.ProductionOverview provides
optimization of non-functional aspects as explained by an monitoring capabilities for injection molding machines, in-
interviewee: E: Outliers are technical features for tuning and cluding an overview of operation modes and the history of
tweaking performance. It’s not really a feature from the drive production sequences. In particular, customers like the pos-
perspective, but we can configure a drive to be faster or slower. sibility to inspect variables during system operation. The
We can tweak the product to indirectly fulfill the customer feature is also highly valued by Keba developers who use it
requirements. Furthermore, these two outliers only have a for diagnoses (popular with developers).
specific lifecycle purpose—they control the startup or the Features also need to provide a distinct functionality
build process of the system. For instance, Danfoss.PowerUp- to the product line. On the other hand, ambiguous features
FastFuncs improves system performance by moving functions not meeting this criterion are considered as bad features
from flash to RAM using a dedicated compiler macro. (explained shortly in Sec. 5.2). Recall the outlier feature
Finally, Danfoss introduced the mandatory feature Board- Keba.UserGuidance, which was only vaguely understood by
SupportPackage, a more intelligent hardware abstraction layer customers and the management.
(HAL), to reduce the number of variants. Third-party board Features have also been rated as good if they are perceived
vendors urge Danfoss to update the boards by increasing the as well implemented and error-free. For instance, the
price for old boards. The more robust abstractions provided feature Keba.Oscilloscope provides signal charts and two-
by this feature account for improved maintainability and dimensional plots for monitoring and diagnosing robotics
evolvability to quickly support new boards. This feature is solutions. According to our interviewee A: it just always
not visible to the customer and only exists at the architecture worked. General statements about the implementation aspect
and development level. However, it needed to be approved further emphasize the absence of surprising feature interac-
by the product management and other engineering teams tions and adherence to architectural rules: E: A good feature
to verify that it does not negatively affect existing business fulfills the requirements, but does not introduce any bugs on
logic. In this light, considering this new HAL as a feature the way or impact existing features of the product line. [...]
makes it a unit of maintenance, which various teams can use It has to follow the architecture rules and the coding style.
for communication and management can use for planning. Features are also considered as good if they are well
modularized, not cross-cutting multiple components. For
 Table 4: Expressed feature-classification rationales we will discuss in Sec. 6.2.
Interestingly, the necessity to make a feature optional
rationale description occ.1 (variability) has also led to issues. The feature Keba.Data-
domain core domain functionality 4 Manager supports copying mold and protocol data between an
ubiquitous common feature affecting many assets 1
typical

market demand required to be competitive in the market 4 injection molding machine and a PC, allowing modification of
internal standard management decision for an internal 1 the machine cycle. Due to safety concerns of a key customer,
standard
customer request requested by a specific customer 1 the feature had to be made optional, resulting in high effort.
deployment only supports system deployment 1 We also observed features that originated from defects
placeholder placeholder for future improvements 1 (defect fix). This happened for the feature Danfoss.Reset-
usability improves usability for customers 1
Fix, where a bug fix for a reset functionality of counters
outlier

optimization optimizes a non-functional aspect (e.g., 2

power consumption, performance) was defined as a new feature. It fixes an unintended feature
startup controls or affects system startup 1
build controls or supports build process 1 interaction between a counter feature and a feature providing
evolvability improves future system evolvability 1 a reset functionality for the counter, resulting in incorrect
maintainability improves system maintainability 1
counting. In general, defining bug fixes as features helped
popular w/customers positive customer feedback 2 Danfoss to support customers who were used to the incorrect
well modularized feature implementation limited to module 3
popular w/developers supports system diagnosis 1 behavior and did not wish a mandatory bug fix.
good

error-free no or very few defects since inception 1 Finally, both duplicate and superfluous features were re-
well implemented implementation adheres to architecture 1
rules and coding styles ported as bad features. Danfoss reported that the same
distinct funct. graspable concept that is easily understood 1 functionality—for instance, the feature ResetFix from above—
thoroughly tested high confidence in correctness 1
was implemented twice due to a lack of coordination between
rushed development implemented under pressure 2
workaround compromise during implementation 1 the application-engineering teams. Superfluous features are
customer complaints bad feedback from the market 1 those that were developed but never used, effectively wasting
implementation modified frequently 2
bad

frequent changes
highly cross-cutting scattered feature implementation 2 development effort. None of our studied features belongs to
test challenges difficult or laborious to test 1 this category, but Danfoss reported such features: E: The
variability need to make a feature optional 1
defect fix defects that became features 1 worst case scenario is a feature which has been implemented
1
but not used at all. It happens.
number of occurrence of the rationale in interviews

instance, the feature Opel.ParkAssist is not scattered across 6. CROSS-CASE ANALYSIS

multiple components, therefore significantly limiting coordi- In our study, we also conducted a cross-case analysis by
nation effort between the suppliers, who commonly imple- investigating the various facets (cf. Table 2) of all 23 features.
ment the components. We now discuss the results of this analysis and explicitly
formulate the core observations.
5.2 What is a Bad Feature?
Among our interviewees, bad features are usually the re-
6.1 Rationale, Level, and Nature
sult of time pressure and rushed development as well as Rationale. In all subjects, typical, good, and bad features
compromises made during implementation (workaround). were mainly introduced for business-related reasons, such as
For instance, the features Keba.ManualConfiguration and general market demand and customer requests. However, the
Keba.DataManager were implemented too hastily, resulting introduction of certain operational modes (e.g., Keba.Oscillo-
in low implementation quality. The feature Keba.Manual- scope, a feature adding logging and monitoring support) or
Configuration, supporting the configuration of an encoder box regulatory requirements (e.g., ECE-R 79 requirements on
to reduce wiring costs, was developed under time pressure steering interventions and automatically commanded steering
and released prematurely to selected customers. However, for Opel.ParkAssist) were mentioned as well.
this led to negative market feedback (customer complaints) Outlier features were often the result of a technical concern
as expressed by interviewee B: There was an extreme pres- that had to be addressed. Indirectly, these features also
sure from the customer side to support this feature. [...] realize customer requirements. Their prime rationale was
We sensed that customers would not agree with [the compli- the support for dedicated Lifecycle tasks of a system, such
cated configuration], but due to pressure we realized it. [...] as deployment, debugging, monitoring, configuration, system
Would have been better to realize the feature with complete startup, or usability improvements.
tool support before release. Level. We observed that the notion of features is used
A related problem are highly volatile features (frequent at all organizational levels. For almost all of our features,
changes), such as the feature Opel.EmergencyBraking, which traces exist at all levels. For Keba, these levels comprise
required continuous improvements and extensions to support product management, architecture, and development. Opel
an increasing number of deceleration profiles and object types has similar levels, ranging from the feature-definition level
recognized on the road. at the top via the requirements, the logical and physical
Scattered and highly cross-cutting feature implemen- architecture, down to the deployment level. Similarly, for
tations led to a bad perception of two features: Danfoss.Pro- Danfoss, nearly every feature is identifiable at the business
ductG realizes a request for one specific customer, requiring level down to all other levels.
many little tweaks to the code. Opel.EmergencyBraking is We also found that most of the features were leaf fea-
also considered as a highly crosscutting feature. It is also tures, which were very concrete and easy to describe, and
more complex than the typical feature Opel.LaneKeeping due top-level features defined in product maps. Intermediate
to different deceleration profiles and object types as well as features were fuzzier and more abstract, making it difficult
more sub-variants and parameters for calibration. However, for the practitioners to talk about them. Two interviewees
cross-cutting features are not necessarily considered bad, as explicitly stated this point, for instance, F: Product features
on a top-level are good features, which describe a specific characteristics of parameters are different. Parameters do
functionality [...] Yet, intermediate features are frequently not have a process attached to them like features do, have no
used, both for grouping purposes (Danfoss) or for defining architectural responsibility and no dedicated responsible role
functionalities with different variants (Keba and Opel). (usually the feature owner is also responsible for parameters).
Observation 1: Outlier features. Features do not only ad-
dress functional or non-functional concerns that end up in a 6.2 Scope and Architecture
product. Features are also used for atypical purposes, such Scope. Not surprisingly, we observe both localized and cross-
as supporting a system’s lifecycle. cutting features, scattered over large parts of the product line.
Half of Keba’s and Danfoss’ studied features are cross-cutting.
Outlier features are an important part of the development
For instance, Keba.Oscilloscope introduces logging and a
process. Yet, they do not need to be developed according to
global monitoring mode for operating the system, affecting
the full feature development process. In other words, they do
many parts of the codebase. In Opel’s active safety domain,
not exist on all levels. For instance, Keba.UserGuidance solely
almost all features are cross-cutting, with implementations
exists at the product-management level and is used internally.
being scattered over many components and ECUs. Among
Keba.SilentMode exists only at the development level; it is a
the three Opel features, only one (ParkAssist) is well localized
hidden command-line option used only by service engineers
in its current implementation. Another highly cross-cutting
during setup. Also, Danfoss.PowerUpFastFuncs exists only at
feature, spanning many domains, is Danfoss.ProductG. It is
the architecture and development levels.
the result of one customer request whose realization needed
Thus, outlier features are coordinated or implemented only
many tweaks throughout the codebase.
by a subset of the typical roles involved (e.g., developers,
Yet, while some features are bad features due to their
architects, or product managers) and are in most cases not
highly cross-cutting nature, the scope of a feature is not
visible to the customer (Keba.HeatUpOptimization is an ex-
a differentiator between good and bad features. As one
ception). Surprisingly, according to our interviewee, only
interviewee explicitly explained, F: If a feature is cross-
Opel has no such outlier features. For the domain under
cutting, that itself is not bad. There can be good reasons for
consideration, all features currently represent functionality.
a scattered feature implementation.
However, due to its long engineering history, Opel has addi-
tional co-existing entities (e.g., basic software components) Observation 3: Cross-cutting features. Scattered feature
that might be used for this purpose. Investigating these implementations do not necessarily lead to problematic fea-
entities and their relation to features is valuable future work. tures.
Architectural responsibility. The majority of the stud-
Nature. The features we investigated were treated primar-
ied features across all companies contributes core business
ily as a unit of functionality to define system capabilities,
logic. At Keba, all of the features discussed affect the user
behavior or data. This is often the case for mandatory fea-
interface (UI). At Opel, all three discussed features affect
tures covering core functionality. Only as a secondary aspect
both substantial business logic and the UI. At Danfoss, most
are features also a unit of variability—when the function-
of the features (except the outliers) handle business logic,
ality should be optional. Recall Keba.DataManager, where
whereas only one feature (Danfoss.Wobbler) also contributes
an allegedly mandatory addition (a new feature) had to be
to the UI. This small number is not surprising given the
made optional, causing substantial development effort. In
small display panels built into frequency converters.
both cases, features do not only provide a unit of functional-
The outliers, and other features to a lesser extent, al-
ity, but can immediately serve as a unit of variability when
most always affect the product-line infrastructure for a spe-
necessary—without the need to introduce a new feature, but
cific lifecycle purpose. However, recall the outlier feature
potentially with significant implementation effort.
Danfoss.BoardSupportPackage, which only contributes a new
Only one of our features (Danfoss.CascadeController) pri-
architecture (and some business logic). Defining this new
marily offered parametrization to other existing features or
architecture as a feature allowed internal communication and
functionality. Interestingly, Keba decided to consider the sup-
approval (explained shortly in Sec. 6.4), but also booking
port for the configuration of other features as features them-
developers’ time on realizing the feature. This was also ex-
selves: Keba.UserGuidance, Keba.Wizard, and Keba.Man-
plained by a Keba interviewee: B: There are internal features
ualConfiguration. Yet, recall that the first one was just a
[...] [used] for project controlling [...] [to communicate] how
placeholder for future plans to improve the usability of the
much of our time we invest into them.
device configuration.
Finally, almost every feature came with further configura-
tion (a.k.a. calibration) parameters to fine-tune it. Danfoss
6.3 Process and Representation
and Opel manage large parameter databases. For instance, at Definition and approval. While a deep study of processes
Danfoss, the feature model has about 1,000 features, whereas is beyond the scope of our work, we observed a diversity
the parameter model has about 2,800 parameters. Parame- of processes. At Keba, the features we studied are defined
ters are either directly assigned to and controlled by features by an internal project team, or existing specifications are
or can be stand-alone, as in the case of Danfoss. The latter used in case the feature implements an existing standard
arose for historical reasons—the parameter database existed (e.g., for Industrial Ethernet). Sometimes, capabilities found
before features and a software product line were adopted. in similar systems are also studied. Usually, no dedicated
approval is necessary—none of the studied features required
Observation 2: Features vs. parameters. Parameters are this. Opel follows the typical V-shaped software-engineering
not treated in the same way as features. process: New features are defined in a so-called Advanced
Parameters are important entities managed by our com- Technology Work project, comprising the elicitation of re-
panies in addition to features. Yet, the handling and the quirements and the building of a prototype vehicle. There is
special focus on safety-critical aspects; for instance, possible C#, Java, .NET, IEC 61131-3) and a home-grown domain-
feature interactions are investigated. Features are commonly specific language (TeachTalk), in which high-level robot-
redefined based on customer clinics and field experience. At movement commands are declared. Danfoss’ features are
Danfoss, a feature is typically created based on input from implemented in C and C++, partly also using home-grown
customers and goes through a regular development process DSLs. For deployment, Keba and Danfoss exploit binary
(requirements, analysis, etc.). Before going into a product, it and properties files; Keba also uses OSGi bundles and the
has to be approved by the product owner. Danfoss’ outliers TeachTalk scripts.
are created without customer involvement. For the domain under consideration, Opel’s features are
It was surprising that the actual process was not a differ- mostly developed in C and typically deployed as AUTOSAR
entiator between good and bad features. However, as briefly components. All of the studied features are implemented and
discussed above (Sec. 5.2), our feature sample shows that validated by the ECU suppliers, who receive a specification
time pressure is a clear indicator. defining the calibration parameters the component needs to
Observation 4: Immature features. A rushed development support (for instance, to realize other cross-cutting features
process causes problematic features. affecting this component). The resulting AUTOSAR compo-
nents are integrated and validated on the vehicle level and
Danfoss reported on bad experiences with an experiment deployed to the ECUs. Given that most components real-
called “time-boxing”: E: Because of the time pressure, we izing features are developed by ECU suppliers, most of the
are told not to think, just to implement. [With time-boxing] development and integration effort is spent on calibration.
there was a limited amount of time to do some things. It was
OK to implement the code, but not to do any documentation. Inclusion/Exclusion. The mechanisms for including or
excluding optional features are very diverse. At Keba, for in-
Representation. While Opel and Danfoss represent features stance, dedicated robot commands (e.g., Keba.LINMovement)
in dedicated feature-modeling tools, the situation at Keba is are activated at startup time by TeachTalk scripts, which
more diverse. Keba defines high-level product features and also allow fine-grained customization of the movement logic.
their descriptions in product maps—matrices that allow com- Other features are selected in the home-grown configuration
paring related products across numerous features—using the tool or activated via a command-line option, a preferences
Polarion requirements management system and spreadsheets. menu in the UI, or a dedicated description file. The lat-
Feature requests are also managed in an issue-tracking sys- ter can either be a file delivered only to certain customers
tem, used by application engineers to communicate with to activate a feature (e.g., Keba.ManualConfiguration) or a
domain engineers about future platform features. Keba also hardware-description file activating a feature when a certain
has a home-grown configuration tool that, relying on select- kind of hardware is present. Opel’s mechanisms are driven
ing and customizing features by developers, allows quickly by the calibration parameters, whose values determine the
cloning a product variant based on the domain platform. De- startup of the feature’s components, or by the presence of
velopers further use configuration files to define lower-level hardware (if not present, the respective ECU and component
features and parameters associated with features. are not included). Danfoss uses the tool chain provided by
Opel uses GEARS for features and DOORS for require- pure::variants, comprising feature selection and a subsequent
ments. Surprisingly, safety-critical dependencies are currently build process driven by the C preprocessor as well as the
modeled in the requirements, not in the feature model. At family model of pure::variants for determining the respective
Danfoss, every feature is represented in one central feature source files to include. For the outlier Danfoss.PowerUp-
model managed via pure::variants (with current modulariza- FastFuncs, compile macros are used to instruct the linker to
tion attempts). Features are cross-linked to the parameter move functions from flash memory to RAM.
database and requirements are managed in CaliberRM.
6.5 Quality Assurance and Evolution
6.4 Use, Implementation and Deployment, and
Testing. For Keba, manual system tests are more important
Product Derivation than automated test procedures, which are primarily used at
Use. Most frequently, interviewees reported that features are the levels of components. Opel’s procedures follow the typical
used for explaining a system to a customer and for internal levels outlined in the “V” development process: component
communication. B: On the one hand it is the communication testing, integration testing, and vehicle testing. The software
to the customers—which features we have. [...] On the other is tested in an environment; integration testing is usually
hand, it’s also for communication with the development. done on a bench or on a hardware-in-the-loop platform.
Features were also frequently used for other closely related Afterwards, the software is validated in the vehicle. Danfoss
activities such as scoping to create awareness for feature conducts integration and regression tests for a fixed set of
reuse. B: When planning a project, we say that we can do a products that are actually sold. Features are not tested via
project with those features. [Then] someone comes and says component tests.
[...] we can realize automated tests with the existing features. We noticed that cross-cutting features are problematic in
Configuration was another common use of features. Some cases where they involve manual testing processes. Such
of Keba’s and Danfoss’ features also contribute a config- features can usually only be tested at integration time, po-
uration interface, allowing a feature’s parametrization by tentially also requiring hardware, making them high risk.
customers during setup or run-time. All of Opel’s features
also contribute a large variety of calibration parameters used Observation 5: Testing and feature scattering. Scattered
for feature customization during manufacturing. features that have to be tested manually are problematic.
Implementation and deployment. We observed a large va- Evolution. The features at Keba were characterized as stable
riety of implementation techniques. To implement features, with core functionality remaining unchanged. Customiza-
Keba uses multiple programming languages (e.g., C, C++, tions, refinements or refactorings are made upon request.
For instance, the feature Keba.Oscilloscope was extended to methods also cover the identification of features in product
support additional chart types, and the feature Keba.Silent- lines, but guidance is typically very specific in this regard.
Mode was recently refactored and re-implemented using a While feature identification is not the primary aim of our
different programming language. At Opel, features in the work, the presented facets of 23 real-world features can be
active-safety domain are very dynamic. Therefore, a major useful for organizations in their scoping activities.
part of the evolution effort is spent on calibration, minor Variability Modeling. Variability modeling is essential
adjustments of features, and code refactorings. For the fast- for defining and managing the commonalities and variabili-
evolving feature Opel.EmergencyBraking, engineers gradually ties in software product lines. A wide range of variability-
added support for recognizing additional objects to trigger modeling approaches has been proposed, including feature
the automatic brake (e.g., stationary vehicle, pedestrian, or modeling [17], decision modeling [28], and orthogonal vari-
bicycle in front). ability modeling [23]. Empirical studies report on experiences
of applying variability modeling [6, 5]. Survey papers [8, 29,
3, 28, 10] compare variability-modeling approaches from dif-
7. THREATS TO VALIDITY ferent perspectives, which influenced the definition of feature
External Validity. As with any case-study research, it facets in our study. For instance, a survey paper comparing
might not be possible to generalize the results of our work feature models and decision models [10] uses ten dimensions
beyond the considered cases. Thus, we carefully avoided to characterize the different techniques. Although the focus of
making any generalizations, but rather presented an in-depth our study was not on variability modeling, some dimensions
analysis of the selected cases. We also focused on large, described in this survey supported the definition of feature
influential companies, which we selected using well-defined facets (e.g., applications, dependencies, binding time).
criteria (cf. Sec. 2.1), and sought to obtain a diverse sample Feature-Oriented Engineering Methods. Feature-
of features. This sampling approach is commonly known as oriented software development (FOSD) is a programming
theoretic sampling [13]. To get a broader perspective, we concept for managing the construction, customization, and
selected interviewees covering a range of roles in the studied synthesis of software systems based on features as first-class
companies. We thus believe that the observations reported citizens [1]. FOSD primarily addresses implementation-level
in this paper are of value to the wider SPL community. aspects of features, whereas our aim was to empirically investi-
Internal Validity. We see two main threats to internal gate a wider range of feature facets in different organizations.
validity. First, we might have phrased our interview questions Empirical Studies. Many experience reports about suc-
in a way that affected the participants’ answers, especially in cessful industrial product lines are provided by van der Lin-
cases where specific examples were given. We attempted to den et al. [31] and the SPL community’s ’Hall of Fame’.
mitigate this threat by performing a pilot study and refining While these provide valuable insights into economic, orga-
our interview guide when we observed that our questions nizational, and process aspects of real-world product lines,
raised confusion. We also avoided providing examples of only few details are given on the characteristics of individual
possible answers unless the participants experienced diffi- features. Some experience papers provide more details about
culties in addressing a raised question. Second, we might features at different levels of product lines. For instance,
have misinterpreted the participants’ answers and derived Lee et al. [21] report detailed experiences from developing
incorrect conclusions, threatening the reliability of our study. an elevator control software product line comprising 490 fea-
To mitigate this threat, all interviews were recorded and tures. Berger et al. [4] provide an analysis of features in 128
their summaries were cross-checked by one co-author who variability models, including metrics about feature types and
did not attend the interview. Unclear cases were discussed feature dependencies. While these results helped us identify
and some were further verified with the interviewees. important facets of features, our aim was to complement
existing empirical studies by conducting a qualitative study
8. RELATED WORK in companies and providing details about selected features.
Feature Definitions. Many definitions of the term fea-
ture exist [1, 17, 32, 15, 25, 18, 23, 20, 8, 31], each of which em- 9. CONCLUSION
phasizes certain feature characteristics. For instance, Kang We presented a qualitative study on the practical use of
et al. [19] provide a definition covering implementation, test- features in three large companies. The study provides a con-
ing, deployment, and maintenance of a feature. Bosch men- textualized and in-depth analysis of 23 features in real-world
tions functional and quality requirements specifying logical settings—in organizations that manage features and explic-
units of behavior [7]. Further definitions focus on features itly track them. We reported insights into successful and
as user-visible aspects [17] or features as aspects that are failed practices of feature usage together with the respective
valuable to a customer [24]. However, existing approaches conditions (RQ1) as well as a cross-case analysis on the range
do not combine multiple feature characteristics, nor do they of feature definitions and usages in practice (RQ2).
describe relations among them. The feature facets presented What is a Feature? The notion of what a feature is
in this paper can be useful as a terminology for describing dif- varied widely across the three companies we studied. Yet,
ferent properties of features. Our observations also indicate we observed a surprising consistency regarding what makes
possible dependencies between such properties. features good or bad. We also found that one of the most
Feature Identification. Scoping methods propose a top- important characteristics of a feature is that it needs to repre-
down approach to determining the boundaries of a product sent a distinct and well-understood aspect of the system. We
line and are an important planning activity that may deter- found that good features need to precisely describe customer-
mine the success or failure of a product line effort [26]. Some relevant functionality, that bad features primarily arise from
scoping techniques ground the identification of the product rashly executed processes, and that cross-cutting features
line scope based on business objectives [11, 27]. Scoping scattered over the codebase are not necessarily bad. We also
observed that outliers are necessary, but do not require the [12] Y. Dubinsky, J. Rubin, T. Berger, S. Duszynski,
full engineering process of typical features. We hope that our M. Becker, and K. Czarnecki. An Exploratory Study of
results on the actual feature usage and on issues arising from Cloning in Industrial Software Product Lines. In Proc.
it will be interesting for both practitioners and researchers. CSMR, 2013.
Future Work. We plan to trace and study the lifecycles [13] K. M. Eisenhardt and M. E. Graebner. Theory
of features in more detail. Specifically, the insights we gained Building from Cases: Opportunities and Challenges.
into the feature definition and approval process suggest that Academy of Management J., 50(1):25–32, 2007.
an in-depth study in this area would be highly valuable. Such [14] R. Flores, C. Krueger, and P. Clements. Mega-Scale
a study should also capture the coordination among roles Product Line Engineering at General Motors. In Proc.
and teams required to engineer and evolve features. The SPLC, 2012.
paper used a set of facets for describing and communicating [15] I. Jacobson, M. Griss, and P. Jonsson. Software Reuse:
important characteristics of features. We plan to refine the Architecture, Process and Organization for Business
facets as a basis for developing a language for describing Success. 1997.
features. Finally, we reported initial observations relating [16] H. P. Jepsen, J. G. Dall, and D. Beuche. Minimally
feature characteristics and their success. Further work should Invasive Migration to Software Product Lines. In Proc.
investigate the development of approaches that can help to SPLC, 2007.
predict when a feature is going to be good or bad.
[17] K. Kang, S. Cohen, J. Hess, W. Nowak, and
S. Peterson. Feature-Oriented Domain Analysis
Acknowledgments (FODA) Feasibility Study. Tech. Rep., 1990.
We thank the companies, all our interviewees, and Manfred [18] K. Kang, J. Lee, and P. Donohoe. Feature-Oriented
Schölzke for participating in our study. This work was par- Product Line Engineering. IEEE Software, 19(4), 2002.
tially supported by Keba AG and the Christian Doppler [19] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and
Forschungsgesellschaft Austria, the Artemis Joint Undertak- M. Huh. FORM: A Feature-Oriented Reuse Method
ing (grant 332830/2012-1), and the Ontario Research Fund. with Domain-Specific Reference Architectures. Ann.
Softw. Eng., 5:143–168, Jan. 1998.
10. REFERENCES [20] J. Lee and D. Muthig. Feature-oriented Variability
Management in Product Line Engineering. Commun.
[1] S. Apel and C. Kästner. An Overview of Feature-
ACM, 49(12):55–59, Dec. 2006.
Oriented Software Development. J. Object Techn.,
8(5):49–84, 2009. [21] K. Lee, K. C. Kang, E. Koh, W. Chae, B. Kim, and
B. W. Choi. Domain-Oriented Engineering of Elevator
[2] E. R. Babbie. The Practice of Social Research. Cengage
Control Software: A Product Line Practice. In Proc.
Learning, 13th edition, 2012.
SPLC, 2000.
[3] D. Benavides, S. Segura, and A. R. Cortés. Automated
[22] D. Lettner, F. Angerer, H. Prähofer, and
Analysis of Feature Models 20 Years Later: A
P. Grünbacher. A Case Study on Software Ecosystem
Literature Review. J. Information Systems, 35(6), 2010.
Characteristics in Industrial Automation Software. In
[4] T. Berger, D. Nair, R. Rublack, J. M. Atlee,
Proc. ICSSP, 2014.
K. Czarnecki, and A. Wasowski.
, Three Cases of
[23] K. Pohl, G. Böckle, and F. van der Linden. Software
Feature-Based Variability Modeling in Industry. In
Product Line Engineering: Foundations, Principles,
Proc. MODELS, 2014.
and Techniques. Springer-Verlag, 2005.
[5] T. Berger, R. Rublack, D. Nair, J. M. Atlee, M. Becker,
[24] M. Riebisch. Towards a More Precise Definition of
K. Czarnecki, and A. Wasowski.
, A Survey of Variability
Feature Models. In Modelling Variability for OO
Modeling in Industrial Practice. In Proc. VaMoS, 2013.
Product Lines. 2003.
[6] T. Berger, S. She, R. Lotufo, A. Wasowski,
, and
[25] J. Savolainen and J. Kuusela. Volatility Analysis
K. Czarnecki. A Study of Variability Models and
Framework for Product Lines. In Proc. ISSR, 2001.
Languages in the Systems Software Domain. IEEE
Trans. on Soft. Eng., 39(12), 2013. [26] K. Schmid. Scoping Software Product Lines: An
Analysis of an Emerging Technology. In SPLC, 2000.
[7] J. Bosch. Design and Use of Software Architectures –
Adopting and Evolving a Product-line Approach. ACM [27] K. Schmid, I. John, R. Kolb, and G. Meier. Introducing
Press, 2000. the PuLSE Approach to an Embedded System
Population at Testo AG. In Proc. ICSE, 2005.
[8] A. Classen, P. Heymans, and P.-Y. Schobbens. What’s
in a Feature: A Requirements Engineering Perspective. [28] K. Schmid, R. Rabiser, and P. Grünbacher. A
In Proc. FASE, 2008. Comparison of Decision Modeling Approaches in
Product Lines. In Proc. VaMoS, 2011.
[9] K. Czarnecki and U. W. Eisenecker. Generative Pro-
gramming: Methods, Tools, and Applications. Addison- [29] P.-Y. Schobbens, P. Heymans, J.-C. Trigaux, and
Wesley, 2000. Y. Bontemps. Feature Diagrams: A Survey and a
Formal Semantics. In Proc. RE, 2006.
[10] K. Czarnecki, P. Grünbacher, R. Rabiser, K. Schmid,
and A. Wasowski. Cool Features and Tough Decisions: [30] K. Sierszecki, M. Steffens, H. H. Hojrup, J. Savolainen,
, and D. Beuche. Extending Variability Management to
A Comparison of Variability Modeling Approaches. In
Proc. VAMOS, 2012. the Next Level. In Proc. SPLC, 2014.
[11] J.-M. DeBaud and K. Schmid. A Systematic Approach [31] F. J. van der Linden, K. Schmid, and E. Rommes.
to Derive the Scope of Software Product Lines. In Proc. Software Product Lines in Action. 2007.
ICSE, 1999. [32] P. Zave. FAQ Sheet on Feature Interactions. Available
at http://www.research.att.com/˜pamela/faq.html, 2004.