ISO/IEC 26550:2015

Software and systems engineering - Reference model for product line engineering and management

ISO/IEC 26550:2015 is the entry point of the whole suite of International Standards for software and systems product line engineering and management. The scope of this International Standard is to ? provide the terms and definitions specific to software and systems product line engineering and management, ? define a reference model for the overall structure and processes of software and systems product line engineering and management and describe how the components of the product line reference model fit together, and ? define interrelationships between the components of the product line reference model. ISO/IEC 26550:2015 does not describe any methods and tools associated with software and systems product line engineering and management. Descriptions of such methods and tools will appear in the consecutive International Standards (ISO/IEC 26551[1] to ISO/IEC 26556[2]). This International Standard does not deal with terms and definitions addressed by ISO/IEC/IEEE 24765:2010 that provides a common vocabulary applicable to all systems and software engineering work. Whenever this International Standard refers to "products", it means "system-level products" consisting of software systems or both hardware and software systems. It may be useful for the engineering and management of product lines that consist of only hardware systems but it has not been explicitly created to support such hardware product lines. This International Standard is not intended to help the engineering, production, warehousing, logistics, and management of physical items that, possibly combined with software, comprise the products. These processes belong to other disciplines (e.g. mechanics, electronics). NOTE Annex A provides further information on products. ISO/IEC 26550:2015, including the product line reference model and the terms and definitions, has been produced starting from References [6], [7], and [8] which finally resulted in a broad consensus from National Member Bodies at the time of publication. In addition to this background process, structures from ISO/IEC 12207:2008, ISO/IEC/IEEE 15288:2015, ISO/IEC 15940:2006 and ISO/IEC 14102:2008 have been used as a baseline. [1] Second edition to be published. [2] Under development.

Ingénierie du logiciel et des systèmes - Modèle de référence pour l'ingénierie et la gestion de lignes de produits

General Information

• Status: Published
• Publication Date: 18-Nov-2015
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7/WG 4 - Tools and environment
• Current Stage: 9093 - International Standard confirmed
• Start Date: 24-May-2022
• Completion Date: 30-Oct-2025

Relations

• Revises: ISO/IEC 26550:2013 - Software and systems engineering - Reference model for product line engineering and management
• Effective Date: 05-Nov-2015

Overview

ISO/IEC 26550:2015 - "Software and systems engineering - Reference model for product line engineering and management" is the entry-point standard for the suite of International Standards on software and systems product line engineering and management. It establishes a high-level reference model and the domain-specific terms and definitions used across the product-line family (SSPL). The standard describes how the components of product line engineering fit together, and the interrelationships between them, but intentionally does not prescribe specific methods or tools.

Key technical topics and requirements

• Scope and purpose
  • Provide standardized terms and definitions for product line engineering and management.
  • Define a reference model for the overall structure and processes of software and systems product line engineering.
  • Specify interrelationships between components of the product line reference model.
• Two lifecycle viewpoints
  • Domain engineering (product-line scoping, domain requirements, domain design, domain realization, domain verification & validation).
  • Application engineering (application requirements, design, realization, verification & validation).
• Process and management groups
  • Organizational management (product line planning, enabling, and management).
  • Technical management (process management, variability management, asset management, support management).
• Variability and assets
  • Emphasis on explicit variability definition and management so domain assets can be reused and configured for member products.
  • Definition and lifecycle considerations for domain assets and application assets.
• Limitations
  • Does not describe specific methods, tools, or logistics for physical items; it focuses on system-level products (software or hardware+software).
  • Does not duplicate vocabulary covered by ISO/IEC/IEEE 24765:2010.

Practical applications

• Use ISO/IEC 26550 to:
  • Design and govern a product line strategy that reduces cost, shortens time-to-market, and improves quality.
  • Create a consistent framework for variability modeling, asset repositories, and reuse policies.
  • Align organizational processes (planning, enabling, measurement) with product-line lifecycle needs.
• Typical outcomes: clearer scoping of product families, traceable domain/application relationships, and an actionable model to guide implementation standards.

Who should use this standard

• Product-line managers, systems and software architects, enterprise architects
• Process engineers, quality managers, and technical program managers
• Standards developers and organizations creating product-line tools, variability models, and governance frameworks

Related standards

• Companion series: ISO/IEC 26551–26556 (methods and tools under the product line suite)
• Cross-referenced baselines: ISO/IEC 12207, ISO/IEC/IEEE 15288, ISO/IEC 15940, ISO/IEC 14102
• Vocabulary reference: ISO/IEC/IEEE 24765:2010

Keywords: ISO/IEC 26550:2015, product line engineering, software and systems, reference model, variability management, domain engineering, application engineering, product line management.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 26550
Second edition
2015-12-01
Software and systems engineering —
Reference model for product line
engineering and management
Ingénierie du logiciel et des systèmes - Modèle de référence pour
l’ingénierie et la gestion de lignes de produits
Reference number
©
ISO/IEC 2015
© ISO/IEC 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 From single-system engineering and management toward product line engineering
and management . 6
4.1 Challenges product companies face in the use of single-system engineering
and management . 6
4.2 Variability management . 7
4.3 Key differentiators between single-system engineering and management and
product line engineering and management . 7
5 Reference model for product line engineering and management .9
5.1 General . 9
5.2 Product line reference model .10
6 Two life cycles and two process groups for product line engineering and management .12
6.1 Domain engineering life cycle .12
6.1.1 Product line scoping .12
6.1.2 Domain requirements engineering .12
6.1.3 Domain design .13
6.1.4 Domain realization .14
6.1.5 Domain verification and validation .15
6.2 Application engineering life cycle .16
6.2.1 Application requirements engineering .16
6.2.2 Application design .16
6.2.3 Application realization .17
6.2.4 Application verification and validation .18
6.3 Organizational management process group .19
6.3.1 Organizational-level product line planning .19
6.3.2 Organizational product line-enabling management .21
6.3.3 Organizational product line management .21
6.4 Technical management process group .22
6.4.1 Process management .22
6.4.2 Variability management .23
6.4.3 Asset management .24
6.4.4 Support management .25
7 Relationships within and between domain engineering and application engineering .25
7.1 Interrelations between product line scoping and domain requirements engineering .25
7.2 Interrelations between domain requirements engineering and domain design .26
7.3 Interrelations between domain design and domain realization .26
7.4 Interrelations between domain requirements engineering and domain verification
and validation .27
7.5 Interrelations between domain design and domain verification and validation .27
7.6 Interrelations between domain realization and domain verification and validation .28
7.7 Interrelations between product line scoping and application requirements engineering 28
7.8 Interrelations between domain requirements engineering and application
requirements engineering .29
7.9 Interrelations between domain design and application design .29
7.10 Interrelations between domain realization and application realization .30
7.11 Interrelations between domain verification and validation and application
verification and validation .30
7.12 Interrelations between application requirements engineering and application design .31
© ISO/IEC 2015 – All rights reserved iii

7.13 Interrelations between application design and application realization .31
7.14 Interrelations between application requirements engineering and application
verification and validation .32
7.15 Interrelations between application design and application verification and validation .32
7.16 Interrelations between application realization and application verification
and validation .33
Annex A (informative) Further information on products .34
Bibliography .35
iv © ISO/IEC 2015 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 7, Software and systems engineering.
This second edition cancels and replaces the first edition (ISO/IEC 26550:2013), of which it constitutes
a minor revision.
© ISO/IEC 2015 – All rights reserved v

Introduction
Software and Systems Product Line (SSPL) engineering and management creates, exploits, and manages
a common platform to develop a family of products (e.g. software products, systems architectures) at
lower cost, reduced time to market, and with better quality. As a result, it has gained increasing global
attention since 1990s.
This International Standard provides a reference model consisting of an abstract representation of the
key processes of software and systems product line engineering and management and the relationships
between the processes. Two key characteristics, the need for both domain and application engineering
lifecycle processes and the need for the explicit variability definition, differentiate product line
engineering from single-system engineering. The goal of domain engineering is to define and implement
domain assets commonly used by member products within a product line, while the goal of application
engineering is to develop applications by exploiting the domain assets including common and variable
assets. Domain engineering explicitly defines product line variability which reflects the specific needs of
different markets and market segments. Variability may be embedded in domain assets. During application
engineering, the domain assets are deployed in accordance with the defined variability models.
The reference model for SSPL engineering and management can be used in subsequent standardization
efforts to create standards having a high level of abstraction (e.g. product management, scoping,
requirements engineering, design, realization, verification and validation, and organizational and
technical management), a medium level of abstraction (e.g. configuration management, variability
modeling, risk management, quality assurance, measurement, evaluation, asset repository), or a
detailed level of abstraction (e.g. texture, configuration mechanism, asset mining) for software and
systems product line engineering.
vi © ISO/IEC 2015 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 26550:2015(E)
Software and systems engineering — Reference model for
product line engineering and management
1 Scope
This International Standard is the entry point of the whole suite of International Standards for software
and systems product line engineering and management.
The scope of this International Standard is to
— provide the terms and definitions specific to software and systems product line engineering
and management,
— define a reference model for the overall structure and processes of software and systems product
line engineering and management and describe how the components of the product line reference
model fit together, and
— define interrelationships between the components of the product line reference model.
This International Standard does not describe any methods and tools associated with software and
systems product line engineering and management. Descriptions of such methods and tools will appear
1) 2)
in the consecutive International Standards (ISO/IEC 26551 to ISO/IEC 26556 ). This International
Standard does not deal with terms and definitions addressed by ISO/IEC/IEEE 24765:2010 that
provides a common vocabulary applicable to all systems and software engineering work.
Whenever this International Standard refers to “products”, it means “system-level products” consisting
of software systems or both hardware and software systems. It may be useful for the engineering
and management of product lines that consist of only hardware systems but it has not been explicitly
created to support such hardware product lines. This International Standard is not intended to help
the engineering, production, warehousing, logistics, and management of physical items that, possibly
combined with software, comprise the products. These processes belong to other disciplines (e.g.
mechanics, electronics).
NOTE Annex A provides further information on products.
This International Standard, including the product line reference model and the terms and definitions,
has been produced starting from References [6], [7], and [8] which finally resulted in a broad
consensus from National Member Bodies at the time of publication. In addition to this background
process, structures from ISO/IEC 12207:2008, ISO/IEC/IEEE 15288:2015, ISO/IEC 15940:2006 and
ISO/IEC 14102:2008 have been used as a baseline.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
There are no normative references cited in this document.
1) Second edition to be published.
2) Under development.
© ISO/IEC 2015 – All rights reserved 1

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
application architecture
architecture including the architectural structure and rules (e.g. common rules and constraints) that
constrains a specific member product within a product line
Note 1 to entry: The application architecture captures the high-level design of a specific member product of a
product line. An application architecture of the member products included in the product line reuses (possibly
with modifications) the common parts and binds variable parts of the domain architecture. In most cases, an
application architecture of the member products needs to develop application-specific variability.
3.2
application asset
output of a specific application engineering process (e.g. application realization) that may be exploited
in other lifecycle processes of application engineering and may be adapted as a domain asset based on
a product management decision
Note 1 to entry: Application asset encompasses requirements, an architectural design, components, and tests. In
contrast to domain assets that need to support the mass-customization of multiple applications within the product
line, most application assets do not contain variability. However, applications may possess variability (e.g. end-
users may be enabled to mass-customize the applications they are using by binding application variability during
run time). Application Assets may thus possess variability as well, but the variability of an application asset only
serves the purposes of the particular application, for which the application asset has been created. As a result, the
scope of application asset variability is typically much narrower than the scope of domain asset variability.
Note 2 to entry: Application assets are not physical products available off-the-shelf and ready for commissioning.
Physical products (e.g. mechanical parts, electronic components, harnesses, optic lenses) are stored and
managed according to the best practices of their respective disciplines. Application assets have their own life
cycles; ISO/IEC/IEEE 15288 may be used to manage a life cycle.
3.3
application design
process of application engineering where a single application architecture conforming to the domain
architecture is derived
3.4
application engineering
life cycle consisting of a set of processes in which the application assets and member products of the
product line are implemented and managed by reusing domain assets in conformance to the domain
architecture and by binding the variability of the platform
Note 1 to entry: Application engineering in the traditional sense means the development of single products
without the strategic reuse of domain assets and without explicit variability modeling and binding.
3.5
application realization
process of application engineering that develops application assets, some of which may be derived from
domain assets, and member products based on the application architecture and the sets of application
assets and domain assets
3.6
asset base
reusable assets produced from both domain and application engineering
2 © ISO/IEC 2015 – All rights reserved

3.7
asset scoping
process of identifying the potential domain assets and estimating the returns of investments in the assets
Note 1 to entry: Information produced during asset scoping, together with the information produced by product
scoping and domain scoping, can be used to determine whether to introduce a product line into an organization.
Asset scoping takes place after domain scoping.
3.8
binding
task to make a decision on relevant variants, which will be application assets, from domain assets using
the domain variability model and from application assets using the application variability model
Note 1 to entry: Performing the binding is a task to apply the binding definition to generate new application from
domain and application assets using the domain and application variability models.
3.9
commonality
set of functional and non-functional characteristics that is shared by all applications belonging to
the product line
3.10
domain architecture
reference architecture
product line architecture
core architecture that captures the high-level design of a software and systems product line including
the architectural structure and texture (e.g. common rules and constraints) that constrains all member
products within a software and systems product line
Note 1 to entry: Application architectures of the member products included in the product line reuse (possibly
with modifications) the common parts and bind variable parts of the domain architecture. Application
architectures of the member products may (but do not need to) provide variability.
3.11
domain asset
core asset
output of domain engineering life cycle processes and can be reused in producing products during
application engineering
Note 1 to entry: Domain assets may include domain features, domain models, domain requirements specifications,
domain architectures, domain components, domain test cases, domain process descriptions, and other assets.
Note 2 to entry: In systems engineering, domain assets may be subsystems or components to be reused in further
system designs. Domain assets are considered through their original requirements and technical characteristics.
Domain assets include but are not limited to use cases, logical principles, environmental behavioral data, and
risks or opportunities learnt from previous projects. Domain assets are not physical products available off-the-
shelf and ready for commissioning. Physical products (e.g. mechanical parts, electronic components, harnesses,
optic lenses) are stored and managed according to the best practices of their respective disciplines. Domain
assets have their own life cycles. ISO/IEC/IEEE 15288 may be used to manage a life cycle.
3.12
domain engineering
life cycle consisting of a set of processes for specifying and managing the commonality and variability
of a product line
Note 1 to entry: Domain assets are developed and managed in domain engineering processes and are reused in
application engineering processes.
Note 2 to entry: Depending on the type of the domain asset, that is, a system domain asset or a software domain
asset, the engineering processes to be used may be determined by the relevant discipline.
© ISO/IEC 2015 – All rights reserved 3

Note 3 to entry: IEEE 1517-2010, Clause 3 defines domain engineering as a reuse-based approach to defining the
scope (i.e., domain definition), specifying the structure (i.e., domain architecture), and building the assets (e.g.
requirements, designs, software code, documentation) for a class of systems, subsystems, or member products.
3.13
domain scoping
subprocess for identifying and bounding the functional domains that are important to an envisioned
product line and provide sufficient reuse potential to justify the product line creation
3.14
feature
abstract functional characteristic of a system of interest that end-users and other stakeholders can
understand
Note 1 to entry: In systems engineering, features are syntheses of the needs of stakeholders. These features will
be used, amongst others, to build the technical requirement baselines.
3.15
member product
application
product belonging to the product line
3.16
product line
product family
set of products and/or services sharing explicitly defined and managed common and variable features
and relying on the same domain architecture to meet the common and variable needs of specific markets
3.17
product line architecture
synonym of domain architecture
3.18
product line platform
product line architecture, a configuration management plan, and domain assets enabling application
engineering to effectively reuse and produce a set of derivative products
Note 1 to entry: Platforms have their own life cycles. ISO/IEC/IEEE 15288 may be used to manage a life cycle.
3.19
product line reference model
abstract representation of the domain and application engineering life cycle processes, the roles
and relationships of the processes, and the assets produced, managed, and used during product line
engineering and management
3.20
product line scoping
process for defining the member products that will be produced within a product line and the major
common and variable features among the products, analyzes the products from an economic point
of view, and controls and schedules the development, production, and marketing of the product line
and its products
Note 1 to entry: Product management is primarily responsible for product line scoping.
3.21
product scoping
subprocess of product line scoping that determines the product roadmap, that is (1) the targeted
markets; (2) the product categories that the product line organization should be developing, producing,
marketing, and selling; (3) the common and variable features that the products should provide in
order to reach the long and short term business objectives of the product line organization, and (4) the
schedule for introducing products to markets
4 © ISO/IEC 2015 – All rights reserved

3.23
variability
characteristics that may differ among members of the product line
Note 1 to entry: The differences between members may be captured from multiple viewpoints such as
functionality, quality attributes, environments in which the members are used, users, constraints, and internal
mechanisms that realize functionality and quality attributes.
Note 2 to entry: It is important to distinguish between the concepts of system and software variability and
product line variability. Any system partially or fully composed of software can be considered to possess
software variability because software systems are inherently malleable, extendable, or configurable for specific
use contexts. Product line variability is concerned with the variability that is explicitly defined by product
management. This International Standard is primarily concerned with product line variability.
3.24
variability constraint
constraint relationships between a variant and a variation point, between two variants, and between
two variation points
3.25
variability dependency
relationship between a variation point and a set of variants, which indicates that the variation point
implies a decision about the variants
Note 1 to entry: Two kinds of variability dependencies are possible: (1) the optional variability dependency states
that the variant optionally dependent on a variation point can be a part of a member product of a product line; (2)
the mandatory variability dependency defines that a variant dependent on a variation point must be selected for
a member product if the variation point is selected for the member product.
3.26
variability management
managerial tasks relate to variability and has two dimensions: variability dimension and asset dimension
Note 1 to entry: Variability management in the variability dimension consists of tasks for overseeing variability
in the level of the entire product line, creating and maintaining variability models, ensuring consistencies
between variability models, managing all variability and constraint dependencies across the product line, and
managing the traceability links between a variability model and associated domain and application assets
(e.g. requirements models, design models). Variability management in the asset dimension consists of tasks
for managing the impacts of variability within each domain and application asset, that is, in which location of
an asset a particular variability occurs and which alternative shapes the asset can take in that location. The
dimensions are complementary in nature, that is, both are needed for successful variability management.
3.27
variability model
explicit definition for product line variability
Note 1 to entry: It introduces variation points, types of variation for the variation points, variants offered by the
variation points, variability dependencies, and variability constraints. Variability models may be orthogonal to
or integrated in other models such as requirements or design models. There are two types of variability models:
application variability models and domain variability models.
3.28
variant
one alternative that may be used to realize particular variation points
Note 1 to entry: One or more variants must correspond to each variation point. Each variant has to be associated
with one or more variation points. Selection and binding of variants for a specific product determine the
characteristics of the particular variability for the product.
© ISO/IEC 2015 – All rights reserved 5

3.29
variation point
representation corresponding to particular variable characteristics of products, domain assets, and
application assets in the context of a product line
Note 1 to entry: Variation points show what of the product line varies. Each variation point should have at
least one variant.
4 From single-system engineering and management toward product line
engineering and management
Single-system engineering and management is the dominant way of conceptualizing and developing
software and systems products. This Clause first outlines some of the main challenges software and
systems product companies face in using single-system engineering and management approaches. It
identifies variability management as the most challenging area. Variability management is discussed
in 4.1. The clause concludes by explaining major differences between single-system engineering and
management and product line engineering and management. Understanding these differences is a key
for successful organizational transitioning from single-system engineering and management toward
product line engineering and management.
4.1 Challenges product companies face in the use of single-system engineering and
management
The excessive use of single-system engineering and management in environments where the
assumptions no longer hold contributes to a variety of issues encountered by customers, end-users,
and providers. For example, customers may feel their needs are unique and acquire and sustain
expensive tailored systems while commoditized, inexpensive products might be completely adequate.
End-users may experience that the functionality they really need is difficult to find and/or use because
the software systems are too complex and provide too much functionality. Finally, a provider may sell
several interrelated products, which look and feel completely different and do not interoperate, even to
the same customers.
Providers of single products typically encounter at least some of the following issues when using
single-system engineering: work efforts and costs are underestimated, productivity is overestimated,
must-have features are missing, product schedules and/or quality goals are not met, and/or customer
satisfaction remains lower than expected. Work efforts may be underestimated and productivity
overestimated because the organization has never before created a similar product or if it has, the
organizational unit who created the similar product may not want to share its experiences and other
possibly reusable assets due to rivalry between organizational units. Inaccurate estimates together
with typically fixed budgets result in schedule fluctuations, missing features, and/or quality issues.
Quality issues may also result from the lack of a reuse culture because the software developed from
scratch typically has much higher defect density than the software reusing well-tested components.
The accommodation of adequate variability is typically the most significant problem faced by
the providers of single products. In this context, the variability needs typically emerge over time
from interactions with various customers. Providers commonly use one or more seemingly simple
but ineffective tactics to deal with emerging variability. For example, a provider may incorporate
variability into a single product by introducing more and more (partly end-user-visible) parameters in
the product and more and more if-then-else-statements in the source code text of the product to deal
with the parameters during run time. As a result, the number of source code lines grows, the source
code becomes increasingly complex to understand and maintain, and the testability (and often also
the performance) of the software deteriorates. Alternatively, a provider with an existing product may
deal with the variable requirements of a new customer by branching a new product from the existing
product, modifying the source code of the new product, merging the modified source code back to the
main line when there is time and other resources available, and finally deleting the branch. Branching
and merging is very expensive and error prone and the source code of the main line will typically become
very complex after a few branches and merges, requiring expensive periodical refactoring to utilize
the tactic on a long term basis. In the worst case, the provider may end up with many partially cloned
6 © ISO/IEC 2015 – All rights reserved

products and no main line of source code to maintain. Such ineffective tactics for managing variability
also make the jobs of software developers tedious and are likely to increase employee turnover.
In sum, product companies utilizing single-system engineering and management approaches may end
up with highly complex and low-quality products, low productivity, high employee turnover, and less
than expected customer satisfaction.
Product line engineering and management is a possible way of dealing with such problems. However, it
is no panacea. If it is understood and implemented poorly, significant investments may result without
the materialization of expected benefits. Therefore, the following clauses of this International Standard
outline what product line engineering and management is and how providers can leverage it to establish
and manage variability; reduce costs and product complexity; increase productivity and product
quality through strategic, prescribed creation and use of domain assets; shorten time to market; and
increase customer satisfaction through mass-customization of products and more accurate estimation
of schedules and costs.
4.2 Variability management
In single-system engineering and management, reuse of knowledge is important. However, product line
engineering and management fundamentally differs from single-system engineering and management.
Product line engineering and management has to take explicitly into account multiple products
and the variations within and between them. Some variability needs can still emerge (e.g. based on
unexpected offerings of competitors) because perfect upfront planning of variability is impossible but
most variability needs should be based on the careful analysis of target markets, available technologies,
offerings of competitors, and other factors. Distinction between common and variable parts of members
of the product line affects product line engineering and management in many ways. Some examples are
provided next.
— Developing the domain architecture: Common and variable parts of products in the product line
must be clearly distinguished in the domain architecture of the product line.
— Ensuring traceability: Variability within and between members of the product line is located in
various domain and application assets, including variability models. Domain and application assets
must be traced, respectively, throughout the domain and application engineering life cycles. Because
application assets may reuse domain assets as they are or after modifications, application assets
must also be bidirectionally traceable to domain assets. As a result, traceability is also necessary
across the domain and application engineering life cycles.
Variability is thus a key differentiator between single-system engineering and management and product
line engineering and management. Variability must be defined, modeled, implemented, versioned,
verified and validated. It must also be traced within and across domain and application engineering
life cycles. The discipline for managing variability is called variability management. The most central
concepts of product line engineering and management, discussed in 4.3, are strongly related to
variability management.
4.3 Key differentiators between single-system engineering and management and
product line engineering and management
The identification and analysis of key differentiators between single-system engineering and
management and product line engineering and management will help organizations to understand the
product line reference model (5.2) and to formulate a strategy for successful implementation of product
line engineering and management. Product line organizations should thus design their structures and
processes to address these differentiators.
— Application engineering: A process life cycle in which application assets and member products of a
product line are implemented and managed by reusing domain assets in conformance to the domain
architecture and by binding the variability of the product line. Thus, the existence of two life cycle
processes, that is, domain engineering and application engineering, distinguishes product line
engineering from single-system engineering.
© ISO/IEC 2015 – All rights reserved 7

— Binding: A decision making task that distinguishes product line engineering from single-system
engineering. It resolves a variety of optional or alternative behaviors provided by domain assets
and application assets and represented by variability models to create application assets or member
products. Binding should be considered during domain engineering at a time when the variants
are introduced, as well as during and after application engineering at the time when the variants
are bound. Static binding of variability during application engineering takes place before run time.
Dynamic binding of variability can be used during run time. It enables a system (1) to self-adapt its
behavior based on pre-specified rules and (2) to be adapted by its users (e.g. when they decide to
bind additional variants to use enhanced features).
— Collaboration: Because there are two parallel life cycles in product line engineering, people
responsible for domain engineering processes need to collaborate within domain engineering and
also with people in related application engineering processes.
— Configuration management: Configurations of a product line are multidimensional in time and
space. Application and domain assets, platform releases, and member products have versions. Each
of these versions has a configuration. Versions of member products depend on asset versions and
platform release versions. Platform release versions depend on domain asset versions. For example,
changes in domain assets may impact numerous member products. Each member product can exist
in multiple configurations at any given time. The possible configurations of a member product
can change over time. The dimensions need to be managed. While configuration management is
necessary for all systems incorporating software, it is thus of paramount importance to product
line engineering and management.
— Domain architecture: It captures the high-level design of a product line, including the variability
defined by domain engineering. It is used as a blueprint for designing the architecture and texture
of all product line members. The need for domain architectures (or reference architectures)
distinguishes product line engineering from single-system engineering.
— Domain asset: The existence of domain assets in software and systems product lines is another
differentiator between product line engineering and single-system engineering.
— Domain engineering: It defines, realizes, verifies and validates the domain assets. Domain variability
model of the product line is structured throughout this process life cycle. It distinguishes product
line engineering from single-system engineering. For each relevant process within the life cycle, the
required subprocesses, roles, and procedures should be described.
— Enabling technology support: Technologies needed to enable product line engineering and
management should be available for the successful product line implementation. Knowledge
management infrastructure is especially crucial because software product line engineering and
management is more knowledge intensive than single-system engineering. For example, product
lines typically consist of more assets, more different types of assets, and more dependencies
between assets than individual systems. Managing knowledge about valid asset configurations is
thus more challenging in product line engineering than in single-system engineering.
— Measurement and tracking: The measurement involved in product line engineering and management
is multidimensional. Data collection, measures, and tracking need to support the domain engineering
and application engineering life cycles, as well as organizational and technical management of product
lines, in a balanced way. For example, inadequate or biased measurement of the organizational units
responsible for application engineering and domain engineering is likely to lead to disputes and
misallocations of funding and other resources between the organizational units. Such disputes may
deteriorate the funding of domain engineering because most, if not all, organizational revenue is
typically obtained from the sales of member products and related services, not from the sales of
domain assets. The lack of a fair funding model and supporting measurement and tracking systems
may hamper or even destroy the organizational implementation and institutionalization of product
line engineering and management.
— Platform: Product line engineering is platform-based. Mass-customization of products is practically
impossible without effective platforms. Platforms thus distinguish product line engineering from
8 © ISO/IEC 2015 – All rights reserved

single-system engineering and are of strategic importance for product line organizations. The
introduction and elimination of entire platforms influence product line organizations significantly.
— Product management: It is responsible for the economic and business concern
...