Click here to view the complete list of archived articles

This article was originally published in the Fall 2006 issue of Methods & Tools

---

Introduction to the Emerging Practice of Software Product Line Development

Charles W. Krueger, http://www.biglever.com/

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:

• Source reuse time. Decisions bound when reusing a configurable source artifact
• Development time. Decisions bound during architecture, design, and coding
• Static code instantiation time. Decisions bound during assembly of code just prior to a build
• Build time. Decisions bound during compilation or related processing
• Package time. Decisions bound while assembling binary & executable collections
• 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.

Page 2   Back to the archive list