A Software Product Line is a set of products satisfying a set of market needs, sharing a set of features arranged in a reference architecture and components from which each new product is deliberately derived (Figure 1). The decision about what products to include in the product line are informed by several factors including an organisation’s mission and vision statements, its business strategy and plan, industry forecasts, competitor intelligence, technology forecasts, and of course customer feedback.

Many organisations still use a “copy and paste” or “clone and own” approach for product line development. This has its merits for a small number of products, scope and complexity or when the market is volatile and difficult to predict, or when the company does not have the capital or capability to invest in reuse.. The investment required is small, the changes required are modest and manageable, and new products can be developed quickly. However, for products large in number, scope and complexity, and many inter-dependent features changing in their commonality and variability, building and maintaining a product line effectively and efficiently is a major software development challenge, and a more rigorous sophisticated structured approach is required.

Software Product Line Engineering (SPLE) is a strategic systematic approach to build for reuse (Domain Engineering) and build with reuse (Application Engineering). SPLE requires organisational buy-in from the highest authority because it affects all organisational and technical aspects of software development. SPLE is not “clone and own”/”copy-edit” nor is the principal focus just on code libraries containing domain independent algorithms, modules, objects or components that have limited impact on a large system. The motivation for SPLE is grounded in many years’ experience gained across the world from different software development organisations. They came to understand that unsystematic clone and own reuse does not realise the perceived benefits of reuse. Figure 2 shows a general economic investment analysis on the value of SPLE. Today many commentators believe that the revenues generated from at least 3 products will be needed before the strategic investment in SPLE pays off.

For example, Figures 3 and 4 show the considerable benefits gained by Mondragon Sistemas de Información, a Spanish company, from deploying a software product line for developing Programmable Logic Controller programs for metal processing lines1 . Figure 3 shows the average time spent on each new product decreased by 26% in 2006 compared to the 2002/03 baseline. Figure 4 shows that the effort spent on each new product reduced by about 30% in 2006 compared to the 2002/03 baseline.

1Introducing Software Product Line Engineering for Metal Processing Lines in a Small to Medium Enterprise, Sellier, D., Mannion, M., Benguria, G, Urchegui G., Proceedings of 11th International Conference on Software Product Lines (SPLC 2007), Kyoto, Japan, 10-14 Sept 2007

Products in a software product line differ in their portfolio of product features. Each product variation tends to have some features which are in all the products in the product line, and some features that appear in only a subset of the products. Over time product features can also be regarded as in service or obsolete.

The reasons for product variations include:

targeting the needs (functional requirements and/or quality attributes) of different groups of customers

feature enhancements to generate additional revenues and maintain customer loyalty

fixing errors

making quality and performance improvements

needing to run on different hardware and operating systems software

underlying hardware technologies change and improve

some combination of all these.

Product Feature Commonality and Variability

In a software product line, a product feature can have a variability property. The value of this property can be common i.e. common to all products or variable i.e. in some products but not all. At the extreme end of variability, a feature can exist in just one product. In representing variability, we can distinguish between a Variation Point and a Variant.

A Variation Point represents a point of product feature differentiation.

A Variant represents a possible value of a Variation Point.

A Variation Point will have one or more variants.

Each Variation Point is associated with a set of Variants which represents all the possible choices at the variation point. Variants can be categorised as mutually exclusive, a list of alternatives or optional.

Mutually Exclusive: exactly one feature out of a set of features with the same parent feature can be chosen to be in the system if the parent is part of the system e.g. in a mobile phone product-line, a parent feature can be “The mobile phone shall have a Display” and its mutually exclusive child features can be “The mobile phone shall have a Black & White Display.” or “The mobile phone shall have a Colour Display”.

List of Alternatives: one or more than one features with the same parent feature can be chosen to be in the system if the parent is part of the system e.g. a parent feature can be “The mobile phone shall have the ability to make a call” and its list of alternative child features can be “A call shall be made by dialling numeric digits”, “A call shall be made by selecting a number from a phone book” and “A call shall be made by calling back from a call log”.

Optional: an optional feature may or may not be part of a system e.g. in a mobile phone product-line, the feature to have an email facility might be optional. Optional features can have default selection values depending on whether they should be included or excluded by default.

Customer-Perspective on Product Features

“Essentials” i.e. features are that are expected to be included and to be of industry standard quality; their presence has little effect on customer satisfaction, but their absence will cause dissatisfaction e.g an essential feature of a mobile phone is the ability to make a telephone call.

“Differentiators” i.e. features that are value-adding and have a positive effect on customer satisfaction e.g. in the latest release of iPhone products (2019) these are a combination of advanced camera technology, a reduction in purchase price for the top of the range phones, and cheap subscription access to AppleTV.

“Don’t Need – Don’t Care” i.e. features whose presence or absence has no effect on customer satisfaction e.g. on a mobile phone, the pre-loaded apps which a customer will not use

“Don’t Need – Don’t Want” i.e. features whose presence causes dissatisfaction e.g. significant changes to a user interface from previous product versions such that a user cannot find how to do something they used to do with ease.

An Essential feature needs to be fulfilled for a product to compete in a single market segment. Often, omitting a single essential feature affects whether a product will successfully compete in its market segment. A product that satisfies only essential features is a market-entry, base product or commodity in which price becomes the sole basis for its competitiveness in its market segment (which from a development perspective relies on keeping costs low through product development efficiencies). Therefore, whilst a product needs to have the right set of essential features, this set is not enough for uniquely positioning the product in a selected market segment e.g. an essential feature of a mobile phone is the ability to make a telephone call.

A Differentiator is a feature that helps to make a product distinctive from other products in its market segment. Often this is a functional feature e.g. a TV feature in a mobile phone. Sometimes it is property of a feature e.g. its cost, quality, brand name. For example, luxury brand mobile phones often have fewer functional features than top of the range mobile phones but are differentiated by packaging and casing.

A Don’t Need – Don’t Care feature arises when suppliers find it more cost efficient to provide customers with features even if they do not need them because the features are so inter-dependent with other Qualifiers or Differentiators that they do need. If these features do not reduce some preferred aspect of quality below a desired threshold e.g. security, performance, customers are often not concerned if these features are included.

A Don’t Need – Don’t Want feature arises when suppliers provide a Don’t Need feature that either does reduce a preferred aspect of quality below a desired threshold or there is a perception that it will do so, to the extent it leads to unwanted customer dissatisfaction.

Supplier Perspective on Product Features

From a Supplier’s perspective, a significant challenge for a supplier is to determine the appropriate variability property value for each feature as the product line evolves so that products satisfy most customers’ needs to generate revenues. In addition to common, variable and unique features, some features will no longer be supplied, and it can be useful to denote these features as Obsolete for the purposes of keeping a trace history. It is not possible to satisfy every customer’s needs for every feature. Suppliers must also factor in the costs of making features common or variable within the context of their business and engineering strategy.

In Figure 5, the problem domain scope represents a Customer’s perspective and the solution domain scope represents a Supplier’s perspective. The green dots in the problem domain scope are what the customer wants. The green dots in the solution domain scope are what the supplier provides. Given that supplier is trying to satisfy many customers, for a specific customer and a specific product, some features a customer wants are provided, some features a customer wants are not provided, and some features that a customer does not want are provided.

Product Line Evolution

As market segments and product needs change, there is an evolving tension between what a market wants (customer-led changes) and the efficiency and effectiveness with which the supplier can respond (supplier-led changes). Some changes are gradual and can be predicted, others are disruptive and cannot. Poor change management can affect performance, brand identity and reputation which in turn affects market brand positioning, pricing models, and hence sales and profits.

Customer-led changes evolve continually for different reasons e.g. new owners or executives change strategy, new legislation, competition, economic buying power, attitudinal changes in society, different cultures. For example, after a long period in which video-cameras were available only in high end mobile phones, general public increases in economic buying power combined with an emotional desire to take moving pictures, led to a demand by mobile phone customers (retailers) for mobile phone suppliers (manufacturers) to supply video-cameras as a standard feature in mid-range mobile phones. The video-camera feature moved from being a Differentiator to being Essential.

Supplier-led changes also evolve for different reasons e.g. new owners or executives change strategy, new legislation, performance improvements are made to the assets in the product line architecture, new engineering tools and technologies emerge that engineering staff choose to deploy, product managers make changes because their performance pay is weighted towards reuse, technical staff expertise changes, people change jobs and different ideas are introduced. For example, as demand for video-cameras in mid-range mobile phones increased, video cameras themselves were being reduced in physical size whilst offering the same quality and costing less, so it became commercially viable for mobile phone manufacturers to include them even in low-end mobile phone markets which were less demand-driven for that feature. Fortunately, in this example supply and demand were reasonably well aligned. This is not always the case.

As the diversity in a product line evolves over time, the value of a product feature’s variability property may change, making variability management much more difficult. Some features move from being variable to common, some from being common to variable. For example, when creating multiple products for one market segment, some features are typically introduced only into high end products e.g. a camera was originally only in high end mobile phones. Later in time these features often become common to all products in the product line e.g. all mobile phones today have a camera. Then the variability property of the mobile phone camera feature moves from variable to common. In this example, the mobile phone product portfolio planners probably knew this would happen but were uncertain how many months/years it would take. In general, there can be different motivations for changing the value of a feature’s variability property e.g. the market is demanding the feature, or because it is cheaper to put a feature in all products rather than some.

Figure 6 shows a product line of three products, A, B and C at three different points in time.

Software Product Line Engineering (Figure 7) consists of:

Product Line Scoping that identifies the products and features to be included in a product line

Domain Engineering or Platform Development consists of the processes of Requirements Engineering, Domain Design, Domain Realisation, and Domain Verification and Validation; it delivers an Asset Base i.e. reusable product line models and artefacts

Application Engineering or Product Development consists of the processes of Application Requirements, Application Design, Application Realisation, Application Verification and Validation; it delivers products that are derivable from the Asset Base

Organisational Management that establishes staffing structures and reward and recognition systems to support development for and with reuse – we will not discuss this further in this chapter

Technical Management that establishes development methods, tools and quality assurance mechanisms to support development for and with reuse - we will not discuss this further in this chapter.

Table 1 shows three principal strategic approaches to SPLE.

Table 1: Different strategic approaches to SPLE

Proactive Develop the core assets first.	Develop the scope first and use it as a “mission” statement Products come to market quickly with minimum code writing. Requires upfront investment and predictive knowledge
Reactive Start with one or more products	Generate the product line core assets and then future products; then scope evolves more dramatically. Much lower cost of entry The architecture and other core assets must be robust, extensible, and appropriate to future product line needs
Incremental In reactive or proactive approach, develop core asset base in stages, while planning from the beginning to develop a product line.	Develop part of the core asset base, including the architecture and some of the components Develop one or more products Develop part of the rest of the core asset base. Develop more products. Evolve more of the core asset base.

The challenge of SPLE is to adapt what we know about good software engineering practices and factor in the additional complexity of incorporating variability. A second challenge occurs when the software is embedded in hardware e.g. mobile phones, swipe card systems, flexible manufacturing systems, washing machines, on-board spacecraft navigation (See Sidebar on Internet of Things). Some feature changes required in software may not be realisable using a current installation of one or more hardware devices. Some new hardware devices may prohibit or at least constrain existing features from working as they have done. Hardware constrains software and hardware and software lifecycles move at different paces. Changes to physical hardware shape, size, materials, and programmable interfaces, not to mention cost, constrain memory sizes, processor clock speeds, network transmission speeds and available software functionality.

Product Line Scoping

Product Line Scoping2 is defined as the process of identifying and bounding capabilities (products, features) and areas (subdomains, existing assets) of the product line where investment into reuse is economically useful and beneficial to product development. The results are captured by a scope definition. Three levels of scoping are identified, and different scoping methods normally place an emphasis on one of these three levels:

product portfolio scoping: determining which products should be included in the product line and what features they should provide.

domain scoping: identifying and bounding the domains (i.e., areas of functionality) that are important to the product line and provide enough reuse potential to justify the investment in reuse

asset scoping: determining specific assets to be developed for reuse - the collection of assets forms the reuse infrastructure.

Whilst scoping is normally considered to be an activity undertaken at the start of product line development it is equally important to undertake it as a product line evolves. As new products are added to the product line, software producers recognize that a significant problem is striking a balance between development efficiency through increasing platform commonality and customer dissatisfaction from products with additional undesirable features and properties. One solution is to break the existing product line and develop multiple product lines (MPLs), hence the need for more product line scoping. For example, Nokia established the multiple product lines Series 30, Series 40 and Series 60.

Domain Engineering

In Domain Engineering a set of reusable assets are developed that satisfy both commonalities and variants and which can be adapted quickly in response to changes and evolutions. During each phase the set of products in a product line is often captured by integrating variability into traditional software development notations and modelling techniques such as use cases, feature models, sequence diagrams, class diagrams. For example, a feature model contains all the features of all products and is represented in forests of parent-child relationships. Each feature is identified as common or variable. The exact structure and content of feature models varies. Often when feature models become complex, they are partitioned e.g. to allow the connection of various layers of feature refinements, to distinguish external variability (visible to customers) from internal variability (hidden from customers).

A typical product line has hundreds of Variation Points and Variants, so it is difficult to understand and manage variability (i.e. tracing, changing and so on) just using the integrated modelling approach. Another useful complementary approach is to define the variability in a separate orthogonal variability model (Figure 8) to show the relationship between models across the lifecycle.

Reference Architectures & Platforms

One of the reusable artefacts from Domain Engineering is a Domain-specific Architecture or Reference Architecture or Platform. A Reference Architecture is a set of principal design decisions that are simultaneously applicable to multiple related products, typically within an application domain, with explicitly defined points of variation. The technical challenge is to build a reference architecture that includes:

variability points to allow for known and anticipated differences

a component framework and library that can be used to configure the architecture and build new products to fit the needs of customers

some form of application or product configuration method.

Since business models vary, the purpose, structure and content of Platforms can vary. Many product companies build platforms to increase the efficiency with which their products can be developed. It requires a disciplined rigorous approach to managing commonality and variability so that different products can be created and targeted at different market segments.

For other companies, the platform itself is the product being sold e.g. Oracle, Microsoft offer enterprise resource planning software (ERP) platforms. These platforms come with a set of generic components e.g. human resource management system, a customer order system, and a sales management system (see Sidebar on ERP Products) that can be configured to meet a customer’s needs.

In another example, Apple’s AppStore and Samsung’s PlayStore are platforms, effectively offer “empty shells” that allow third parties to develop and run independent application service components.

Modelling Variability

Variation points often increase as the development cycle proceeds. For example, a Variation Point appearing in a feature model for a mobile phone, may lead to additional variation points during the detailed design for the Principal Component for the camera, concerned with a list of alternatives for memory size and processing power. A significant challenge is how much change to plan for and how much variability to include.

Figure 10 shows different terms being used to express different levels of confidence in planning for variability. For example, if we were designing the authentication component for a mobile phone we know there must be variability in the ability to authenticate the use of the phone using a pin number or a fingerprint marker. We can be reasonably confident that the technologies for supporting facial recognition, iris scanning and voice recognition are becoming more mature to warrant different combinations being used in commonly use mobile phones (extendability). We can also anticipate that there might be other combinations in the future, but we can only speculate what these might be e.g. a DNA marker, a unique chip implanted into someone’s hand (flexibility). Planning for and designing for variability cost money and take time. It is usually a commercial judgement about how much to effort to spend on them.

During design and implementation, variation can be modelled using a variety of modelling techniques e.g. inheritance, parameterisation, aggregation hierarchy, generalization and specialization hierarchy, IF…Then..Elses, and conditional compilation directives. In Chapter 4 we saw examples of variability being modelled using the Factory, Strategy, and Composite patterns. We can also postpone variability realisation until runtime using dynamic libraries.

Application Engineering

During each phase of Application Engineering, new products are derived from the platform of reusable assets by making selection decisions at variation points. Doing this effectively and efficiently is difficult and the source of much ongoing research. Apart from modelling all the variation points and variants, another problem is modelling a difficult outstanding problem is how to identify, represent and manage all their inter-dependencies. The selection of a VP or a variant can constrain other selections of a VP or a variant. Such restrictions are called constraint dependency. Constraint dependency includes the following types:

requires: a variation point or a variant requires another selection of a variation point or a variant;

excludes: a variation point or a variant should not be selected when a variation point or a variant is selected.

Feature selection, during application engineering, requires a selection decision model, constructed during domain engineering, that represents the decisions that must be made, a strategy for ordering those decisions, and a means of recording what decisions were made, when, why and by whom. When a new product cannot be wholly generated from the reusable assets this information must be fed back to domain engineers to make a judgement on whether to update the product line.

Figure 11 shows a feature model for a simplified set of features for a mobile phone product line constructed during Domain Engineering. The feature model is arranged as a forest of trees, in which the features are related to each other in parent-child relationships where the children elaborate the detail of a parent feature.

One variation-point selection algorithm we can use for traversing this forest of trees is to traverse left to right depth first. The first feature we come to is “There shall be an address book facility”. Since this is to be a common feature, all the features in its sub-tree are selected (i.e. add, search, delete). The next feature we came to is Camera. Since this is to be a common feature with a front and back camera, both variants are selected. The next feature we come to is “the mobile phone shall have a display”. Since the variants of this feature are Mutually Exclusive, we must make a choice between black & white or colour. The next feature we come to is Email Facility. This is an Option, we can select it or not. If we do select Email then we must choose an email protocol from a List of Alternatives. Let’s suppose we just choose IMAP and POP3 since they are the most commonly used.

The last feature we come to is “There shall be the facility to make a phone call”. The variants are a List of Alternatives from which at least one must be chosen. Suppose we just choose “Dial number”, “Video” and “Voice activated”. In choosing Video we note that it requires a front camera which has already been selected. Clearly if we had set up the camera to be an Option and we had not selected it, we may have found ourselves choosing a Video call feature without having a camera which would be an invalid set of combinations. This is a small simple example, normally feature models are much larger, yet it is helpful in highlighting the importance and complexities of setting up interdependences in feature models, and the need for automated techniques to detect when inconsistent selections have been made.