ISO/IEC 26550:2015

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 26550:2015(E)
©
ISO/IEC 2015

---------------------- Page: 1 ----------------------
ISO/IEC 26550:2015(E)

COPYRIGHT PROTECTED DOCUMENT
© 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. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 26550:2015(E)

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

---------------------- Page: 3 ----------------------
ISO/IEC 26550:2015(E)

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

---------------------- Page: 4 ----------------------
ISO/IEC 26550:2015(E)

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

---------------------- Page: 5 ----------------------
ISO/IEC 26550:2015(E)

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

---------------------- Page: 6 ----------------------
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

---------------------- Page: 7 ----------------------
ISO/IEC 26550:2015(E)

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

---------------------- Page: 8 ----------------------
ISO/IEC 26550:2015(E)

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

---------------------- Page: 9 ----------------------
ISO/IEC 26550:2015(E)

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

---------------------- Page: 10 ----------------------
ISO/IEC 26550:2015(E)

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 li
...