Software Product Lines
Framework Home
Introduction
Purpose
What is a Software Product Line
What Software Product Lines
Are Not
Benefits and Costs of a
Product Line
A Note on Terminology
Starting Versus Running a
Product Line
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Organizational Management
Practice Areas
Frequently Asked Questions
Glossary
Bibliography

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

What Software Product Lines Are Not

Many approaches can, at first blush, be confused with software product lines. Describing what you don't mean is often as instructive as describing what you do mean. When we speak of software product lines, we don't mean

These approaches are described further below.

Fortuitous, Small-Grained Reuse

Reuse, as a software strategy for decreasing development costs and improving quality, is not a new idea, and software product lines definitely involve reuse–reuse, in fact, of the highest order. So what's the difference? Many past reuse agendas have focused on the reuse of relatively small pieces of code–that is, small-grained reuse. Organizations have built reuse libraries containing algorithms, modules, objects, or components. Almost anything a software developer writes goes into the library. Other developers are then urged (and sometimes required) to use what the library provides instead of creating their own versions. Unfortunately, it often takes longer to locate these small pieces and integrate them into a system than it would take to build them anew. Documentation, if it exists at all, might explain the situation for which the piece was created but not how it can be generalized or adapted to other situations. The benefits of small-grained reuse depend on the predisposition of the software engineer to use what is in the library, the suitability of what is in the library for the engineer's particular needs, and the successful adaptation and integration of the library units into the rest of the system. If reuse occurs at all under these conditions, it is fortuitous, and the payoff is usually nonexistent.

In a software product line approach, the reuse is planned, enabled, and enforced–the opposite of opportunistic. The asset base includes those artifacts in software development that are most costly to develop from scratch–namely, the requirements, domain models, software architecture, performance models, test cases, and components. All of the assets are designed to be reused and are optimized for use in more than a single system. The reuse with software product lines is comprehensive, planned, and profitable.

Single-System Development with Reuse

Suppose you are developing a new system that seems very similar to one you have built before. You borrow what you can from your previous effort, modify it as necessary, add whatever it takes, and field the product, which then assumes its own maintenance trajectory separate from that of the first product. What you have done is what is called "clone and own." You certainly have taken economic advantage of previous work; you have reused a part of another system. But now you have two entirely different systems, not two systems built from the same base. This is again ad hoc reuse.

There are two major differences between this approach and a software product line approach. First, software product lines reuse assets that were designed explicitly for reuse. Second, the product line is treated as a whole, not as multiple products that are viewed and maintained separately. In mature product line organizations, the concept of multiple products disappears. Each product is simply a tailoring of the common assets that constitute the core of each product, plus perhaps a small collection of additional artifacts unique to that product. It is the core assets that are designed carefully and evolved over time. It is the core assets that are the organization's premiere intellectual property.

Just Component-Based or Service-Based Development

Software product lines rely on a form of component-based (or service-based) development, but much more is involved. The typical definition of such development involves either the selection of in-house components (services) from in-house or the marketplace to build products. Although the products in software product lines certainly are composed of components–some of which may be Web services–these components are all specified by the product line architecture. Moreover, the components are assembled in a prescribed way, which includes exercising built-in variation mechanisms in the components to put them to use in specific products. The prescription comes from both the architecture and the production plan and is missing from standard component-based development. In a product line, the generic form of the component is evolved and maintained in the core asset base. In component-based development, if any variation is involved, it is usually accomplished by writing code, and the variants are most likely maintained separately. Component-based development also lacks the technical and organizational management aspects that are so important to the success of a software product.

Just a Reconfigurable Architecture

Reference architectures and application frameworks are designed to be reused in multiple systems and to be reconfigured as necessary. Reusing architectural structures is a good idea because the architecture is a pivotal part of any system and a costly one to construct. A product line architecture is designed to support the variation needed by the products in the product line, so making it reconfigurable makes sense. However, the product line architecture is just one asset, albeit an important one, in the product line's core asset base.

Releases and Versions of Single Products

Organizations routinely produce new releases and versions of products. Each of these new versions and releases is typically constructed using the architecture, components, test plans, and other features of the prior releases. Why are software product lines different? First, a product line has multiple simultaneous products, all of which are going through their own cycles of release and versioning simultaneously. Thus, the evolution of a single product must be considered within a broader context–namely, the evolution of the product line as a whole. Second, in a single-product context, once a product is updated, there's often no looking back–whatever went into the production of earlier products is no longer considered to be of any value, or at best, is retired as soon as practicable. But in a product line, an early version of a product that is still considered to have market potential can easily be kept as a viable member of the family: it is, after all, an instantiation of the core assets, just like other versions of other products.

Just a Set of Technical Standards

Many organizations set up technical standards to limit the choices their software engineers can make regarding the kinds and sources of components to incorporate in systems. They audit for compliance at architecture and design reviews to ensure that the standards are being followed. For example, the developer might be able to select between three identified database choices and two identified Web browsers but must use a specific middleware or spreadsheet product, if either is necessary. Technical standards are constraints to promote interoperability and decrease the cost associated with the maintenance and support of commercial components. An organization that undertakes a product line effort may have such technical standards, in which case the product line architecture and components will need to conform to those standards. However, the standards are simply constraints that are input to the software product line, no more.

Next Section Table of Contents Previous Section