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