Variation Management in Software Product Lines

The potentially complex interactions between configuration management in time and in space can make the design, implementation, and deployment of a software product line configuration management solution a formidable challenge. CM practitioners have historically relied on intuition, ad hoc approaches, and pioneering spirit to establish configuration management strategies and techniques for their product lines. As a result, the associated risks, costs, and time of establishing and maintaining a software product line approach can all be high.

Software product lines has until recently been a topic of researchers, but is now successfully emerging into commercial practice. Companies such as Nokia, HP, Philips, Boeing, Cummins and many more are using the software product lines approach to achieve order-of-magnitude reductions in time-to-market, engineering cost, and defect rates for new products in a product line. Improvement metrics of this magnitude are quite rare in the four decades since high-level languages replaced assembly language programming.

Because the potential benefits of a software product line approach are so high, the subject should be on the short list of topics for every software engineer and configuration management engineer to explore. To this end, this is the first of in a series of articles introducing the general concepts behind software product lines and then to get into the specifics of effective techniques such as configuration management in time and space for software product lines.

Introduction
Software product lines refers to engineering techniques for creating a collection of similar software systems from a shared set of software assets using a common means of production. Manufacturers have long used analogous engineering techniques to create a product line of similar products using a common factory that assembles and configures parts that are designed to be reused across the varying products in the product line. For example, automotive manufacturers can now create tens of thousands of unique variations of one car model using a single pool of carefully architected 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 the software product line field have demonstrated that narrow and strategic application of these concepts can yield order of magnitude improvements in time-to-market, quality, and software engineering cost. The result is often a discontinuous jump in competitive 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 software reuse. Rather than put general software components into a library in hopes that opportunities for reuse will arise, software product lines only call for software artifacts to be created when reuse is predicted in one or more products in a well defined product line.

Mass production - the ability to efficiently create many copies of the same product - represented a big advance in the manufacturing world, though creating many copies of a software product is trivial. On the other hand, mass customization - the ability to efficiently create many variations of a product - is a big advance in both manufacturing and software engineering. The key to mass customization is to capitalize on the commonality and to effectively manage the variation in a 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 that can be configured and assembled 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 requirements 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 requirements in the decision model.
• Production mechanism and process: the means for assembling 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.

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.

Binding Times
The primary distinction between software product line engineering and conventional software engineering is the presence of variation in some of the software assets. In the early stages of a software product line process, software assets contain variation points that represent unbound options about how the software will behave. At some point during the production process, product decisions are utilized to select among the options for each variation point, after which the behavior of the variation point in the final 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 include:

It is possible to utilize multiple binding times in a software product line. This allows some decisions to be bound earlier in the process and other decisions to be deferred until later in the process. For example, some decisions might best be made by a product manager at the company developing 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 instantiated software asset inputs for binding decisions at the next production stage. The figure below illustrates two binding times, though more are possible.

Production
The production operation creates partially or fully instantiated product outputs from software asset inputs, using product decisions to determine how to bind variations in the assets. Production is a key discriminator between different software product line approaches and those differences are described in this section.

Automation. Production can be fully automated, completely manual, or somewhere in between. An example of a fully automated production approach is application generators, where product decisions provide sufficient information to automatically generate the product outputs. An example of a completely manual approach is a textual production plan, where software engineers interpret and follow directions in the plan and the product decisions to tailor, integrate, and provide "glue code" around the software assets in order to create products.

Periodicity. As with conventional software engineering, production of a product is typically not a one-shot activity. Products may need to be periodically reproduced to reflect enhancements to the software assets or decisions. The frequency of periodic production may be measured in terms of hours in an agile approach that utilizes automation or in terms of years in a waterfall and manual production approach.

Roles. Some production approaches define a separate human role for the production activity called application engineering, distinct from the domain engineering role responsible for engineering the software asset inputs. Other approaches do not distinguish between these two roles. Separate roles are common in approaches with manual production while a single role is more common in approaches with fully automated production.

The following subsections provide some detail on the different production artifacts shown in the figure above.

Product Decisions
Representation. The different formats used to represent product decisions range from informal textual descriptions to formal machine-interpreted languages.

Guidance. Some approaches provide guidance when making decisions for a product, ranging from written heuristics, to constraint checking, to expert system guidance. Guidance helps to reduce the time, complexity, and errors in the decision-making process, particularly for large numbers of interdependent decisions.

Role. The decision-making role for product creation may be an engineering role such as an application engineer or a domain engineer, or it may be a non-engineering role such as a product marketer, a sales person, or the customer. The role should be give to the person who can make the best decisions at the best time. This will in turn influence the binding time (or times) for production.

Replayable. For periodic production of products, previously-made decisions for products can be automatically "replayed" rather than manually recreated. This requires stored decision representations and automated replay mechanisms.

Software Asset Inputs
Representation. The software asset inputs can come in many different formats, ranging from immutable binary executables to mutable source code that is manually modified, tailored, or extended during production. Assets are not limited to source code and can include test cases, documentation, requirements, use cases, architecture and design descriptions, and so forth.

Variation points. There are many approaches for representing points of variation in the software assets as well as mechanisms to instantiate them. The best choice is influenced by the desired binding time and the degree of production automation desired. For example, a variation point for development-time binding without automation could be an empty block of source code that an application developer fills in. Variation points for runtime binding with full automation might be a programming language if-then-else statement whose behavior is determined by user preferences settings made by the customer.

Product Outputs
Representation. The product outputs can take on many different formats, such as binary versus source and mutable versus immutable.

Partial instantiation. If the product outputs are partially instantiated in one stage of variation binding, the unbound variations become the variation points in software asset inputs for the next stage.

Evolution and Configuration Management
As with conventional software engineering, the software artifacts in a software product line (the assets, decisions, and products) are subject to maintenance and evolution. That variation over time, due to evolution, is distinct from the variation found in the variation points in the software assets, due to the variation among products in the product line space. This distinction is characterized as variation in time versus variation in space.

Conventional configuration management can manage some of the issues of variation in time for a software product line. However, the problem is complicated by dependencies among the different software artifacts in the production process. As illustrated in the following figure, evolutionary changes to an artifact may require that those changes be propagated to interdependent downstream or upstream artifacts in the production workflow.

Scope
The scope of a single software product is defined by the bounds of the capabilities provided in that product. Similarly, the scope of a software product line is determined by the bounds of the capabilities provided by the collection of products in the product line.

According to Joseph Pine in his book Mass Customization, the scope of the products in any product line can be characterized in terms of six dimensions in product usage scenarios: who, what, when, where, how, and why. Multiplicity along these dimensions leads to multiple products in a product line.

There are two primary approaches to managing the scope of a software product line, proactive and reactive. In the case of a pure proactive approach, all of the products needed on the foreseeable horizon are supported by the product line. In the case of a pure reactive approach, only the products needed in the immediate term are supported by the product line and new products are incrementally added as the needs change. There is, of course, a continuum between the two.

The reactive approach requires less up-front effort than the proactive approach since the initial scope coverage is smaller. To implement the same scope coverage, the reactive approach incrementally defers the cost and effort over longer period of time compared to the proactive approach. With the proactive approach, the up-front investment for implementing a broader scope is amortized over time when new products within the scope are deployed with little or no effort.

It is possible for early stage artifacts in a software product line, such as the architecture, to have a more proactive scope than later stage artifacts, such as the source code. However, the overall scope of the product line is defined by the scope of the product collection that can be produced, tested, and deployed.

Transition to a Software Product Line Approach
There are a variety of approaches for transitioning to, or adopting, a new software product line approach. Some case studies have reported transition efforts of 5 years while others have reported making the transition in as little as 2 months. This section outlines some of the characteristics that influence this surprising diversity in transition profiles.

Source of Software Asset Inputs
The software asset inputs for a software product line might come from a variety of sources, including reusable artifacts from an existing library, wrapped or re-engineered artifacts from an existing product, or artifacts developed from scratch. Considerable time and effort can be saved if assets can be reused or extracted from existing products, existing repositories, commercial libraries, and so forth, rather than creating the software assets from scratch.

New versus Enhancement
Another distinguishing characteristic in the transition to a software product line approach is whether it is a brand new product line or whether it is a transition from an existing product line to a more effective approach. Note that if the initial state has multiple products, managed with even the most primitive, ad hoc, conventional techniques such as clone-and-own or IFDEFs, it is still a product line. Existing products, assets (including requirements, architecture, source, and so forth), decision models, and production mechanisms can often be reused and re-engineered when enhancing a software product line approach in order to save time and effort.

Lightweight Approaches
Early case studies of software product line transitions reported typical adoption times of 2 to 5 years. For most organizations, this time and effort represents a significant barrier to adopting a product line approach, regardless of the potential benefits. Recently, advances have been made in lightweight approaches that lower the required transition effort, with some case studies reporting adoption efforts as low as 2 months. Lightweight techniques employed include:

• minimize differences between single-system and product line engineering in order to minimize impact on organization, processes, software, and infrastructure
• offer off-the-shelf software product line tools and technology
• use reactive approaches to defer product development and deployment efforts
• structure production to minimize the need for complex and costly merging, feedback, and product-specific configuration management overhead

Summary
The emerging practice of software product line engineering offers strategic business and competitive advantage through large tactical improvements in the way that software development, testing, configuration management, and build teams go about creating, maintaining, and deploying software. Order-of-magnitude reductions in time-to-market, cost, defect rates, and the total number of supported products are not uncommon.

This article summarizes the foundational concepts in software product line engineering. Future articles will provide additional details about effective software product line techniques, including issues in creating the build, configuration management, and variation management infrastructure for a software product line.

Until then, feel free to join the CM Crossroads Discussion Forum on Software Product Lines , contact the author directly, or utilize the resources referenced in the bio below.