In today's customer-driven environment, most companies target the needs of their prospective customers by creating a product line – aportfolio of closely related products with variations in features and functions– rather than just a single product. For companies that utilize standalone orembedded software in their products, this product diversity poses a seriousproblem. Tools and techniques for software development tend to focus onindividual products. As a result, developing software for a product line isextremely complex due to multiple intertwined products, features and production deadlines – all aimed at moving target markets.

These tactical software development challenges are big enough to impede the realization of business-critical goals and strategies. Morespecifically, they can greatly hinder a company’s ability to hit marketwindows, provide competitive pricing, maximize product quality, and expand the scale or scope of their product line portfolio.

A new class of software development methods, tools and techniques – collectively referred to as software product line development– is emerging to address this problem, offering improvements in developmenttime-to-market, cost, quality, and portfolio scale and scope. What is mostinteresting is the magnitude of tactical and strategic improvements thatare possible, not measured in percentage points, but more commonly in factors oftwo to ten. These improvements are so large that they impact the fundamentals ofhow companies compete. The following sections provide insight into the emergingpractice of software product line development, its underlying key concepts and primary benefits

The Genesis of Software Product Line Development Methods

Manufacturers have long used analogous engineering techniques to create a product line of similar products using a common factory thatassembles and configures parts designed to be reused across the varying productsin the product line. For example, automotive manufacturers can now createthousands of unique variations of one car model using a single pool of carefullyarchitected parts and one factory specifically designed to configure and assemble those parts.

The idea of manufacturing software from reusable parts has been around for decades, but success has been elusive. Recent advances in thesoftware product line field have demonstrated that narrow and strategicapplication of these concepts can yield order of magnitude improvements insoftware engineering capability. The result is often a discontinuous jump incompetitive business advantage, similar to that seen when manufacturers adopt mass production and mass customization paradigms.

The characteristic that distinguishes software product lines from previous efforts is predictive versus opportunistic softwarereuse. Rather than put general software components into a library in hopes thatopportunities for reuse will arise, software product lines only call forsoftware artifacts to be created when reuse is predicted in one or more products in a well defined product line.

Basic Software Product Line Concepts

Software product lines can be described in terms of four simple concepts, as illustrated in the figure below:

Software asset inputs

: a collection of software assets – such as
requirements, source code components, test cases, architecture, and
documentation – that can be configured and composed in different ways to
create all of the products in a product line. Each of the assets has a well
defined role within a common architecture for the product line. To accommodate
variation among the products, some of the assets may be optional and some of
the assets may have internal variation points that can be configured in
different ways to provide different behavior.

Decision model and product decisions

: The decision model
describes optional and variable features for the products in the product line.
Each product in the product line is uniquely defined by its product
decisions - choices for each of the optional and variable features in the
decision model.

Production mechanism and process

: the means for composing and
configuring products from the software asset inputs. Product decisions are
used during production to determine which software asset inputs to use and how
to configure the variation points within those assets.

Software product outputs

: the collection of all products that can be
produced for the product line. The scope of the product line is
determined by the set of software product outputs that can be produced from
the software assets and decision model.

These concepts illustrate the key objectives of software
product lines: to capitalize on commonality and manage variation in order to
reduce the time, effort, cost and complexity of creating and maintaining a
product line of similar software systems.

Capitalize on commonality

through consolidation and sharing within the
software asset inputs, thereby avoiding duplication and divergence.

Manage variation

by clearly defining the variation points and decision
model, thereby making the location, rationale, and dependencies for variation
explicit.

Software product line development approaches provide a shift in perspective, so that development organizations can engineer their entireportfolio as though it were a single system – the production line – rather than a multitude of products.

Binding Times

The primary distinction between software product line engineering and conventional software engineering is the presence of variationin some or all of the software assets. In the early stages of a software productline lifecycle, software assets contain variation points that representunbound options about how the software will behave. At some point during theproduction process, product decisions are utilized to select among the optionsfor each variation point, after which the behavior of the variation point in thefinal product is fully specified. The time at which the decisions for a variation point are bound is referred to as the binding time.

Examples of different binding times for software product lines include:

Customer customizations. Decisions bound during custom coding at customer site

Install time. Decisions bound during the installation of the software product

Startup time. Decisions bound during system startup

Runtime. Decisions bound when the system is executing

It is possible to utilize multiple binding times in a software product line. This allows some decisions to be bound earlier in thelifecycle and other decisions to be deferred until later in the process. Forexample, some decisions might best be made by a product manager at the companydeveloping the software, while other decisions might best be made by the end customer that will use the software.

With multiple binding times, the software product outputs from binding decisions at one production stage become partially instantiatedsoftware asset inputs for binding decisions at the next production stage. Thefigure below illustrates two binding times, though more are possible.