- What Is a Software Product Line?
- 2 What Software Product Lines Are Not
- 3 A Note on Terminology
- 4 Discussion Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 What Software Product Lines Are Not
There are many approaches that at first blush could be confused with software product lines. In fact, you might be asking: "Isn't software product line just a new name for x?" Though we certainly want you to build on previous knowledge and experience, we want to ensure from the outset that you don't erroneously equate software product lines with something they are not. Describing what you don't mean is often as instructive as describing what do you mean. When we speak of software product lines, we don't mean any of the following:
1.2.1 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? 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.
1.2.2 Single-System Development with Reuse
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. 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. You need to maintain two systems as entirely separate entities. 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 core assets. 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.
1.2.3 Just Component-Based Development
Software product lines rely on a form of component-based development, but much more is involved. The typical definition of component-based development involves the selection of components from an in-house library or the marketplace to build products. Although the products in software product lines certainly are composed of components, these components are all specified by the product line architecture. Moreover, the components are assembled in a prescribed way, which includes exercising built-in variability 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 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 alone also lacks the technical and organizational management aspects that are so important to the success of a software product.
1.2.4 Just a Reconfigurable Architecture
Reference architectures and object-oriented 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, and so making it reconfigurable makes sense. But the product line architecture is just one asset, albeit an important one, in the product line's asset base.
1.2.5 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, in a product line there are 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. 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.
1.2.6 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 at architecture and design reviews to ensure that the standards are being followed. For example, the developer might be able to select between two 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 to decrease the cost associated with 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 inputted to the software product line, no more.