Simplifying CM: Expanding Possibilities March 2009 SnapshotCM News

An Introduction to Software Product Lines

In last month's column, we introduced the concept of Software Product Lines. This month, we continue introducing Software Product Lines by discussing the benefits that can be realized using software product line concepts, as well as some challenges you are likely to face. Next month, we will discuss some alternatives to a product line. Eventually we plan to let you know what we are doing in this area.

Benefits of an Effective Software Product Line

One key benefit of an effective Software Product Line (SPL) is flexibility to better meet the needs of a variety of customers. By providing a customer the choice of purchasing only the features they need, the value provided is enhanced. An explicit use of SPL concepts provides greater flexibility to provide a wider variety of feature sets than does an individual product approach. Properly implemented and supported, SPL concepts enable development teams to easily tailor the technical aspects of a product to match identified market needs.

A second key benefit follows from the first in that the easier it is to tailor a product's features, the faster one can get that product to market. Time to market is important to react to market changes, and to take advantage of emerging trends.

A third key benefit is more efficient product development. Creating several product models from one base design is simply more efficient than creating those designs from scratch. Likewise, reusing a tested core asset in a new model is more efficient than testing a new asset. And it is not only development and testing that benefit, but also marketing, sales, support, etc.

The most dramatic SPL benefit goes well beyond reuse and derives from recognizing an appropriate SPL situation early in a product definition, so that an explicit SPL approach can be taken. Let me illustrate this point from an example I observed early in my career. The problem was developing language tools for a wide variety of microprocessors. In particular, we needed an assembler for each of 30+ processors. Creating an assembler for one processor is one kind of challenge. But creating assemblers for 30+ processors is another. Yet the fact that the project targetted a large number of processors from the start led to a different design than if just one had been targetted at a time. That is, recognizing the SPL situation early led to greater efficiencies than simple reuse would have allowed. With reuse, the 30+ assemblers could have shared lots of code with the original assembler. But because of the number of targets, a table driven design was used, such that there was just one assembler (100% reuse of core asset), with processor specific tables. That's the kind of effect that SPL thinking can have.

Challenges to Creating an Effective Software Product Line

For every benefit, there is a challenge. Flexibilty in an SPL comes from putting modules together in different ways. But they also have to work in all those ways. If custom "glue" code is need for each configuration, must of the configuration ease and speed of creating new models is not realized. Again, one can design for this if the SPL situation is recognized early. The key point is that it doesn't just happen on its own; one must be intentional to maximize benefits.

Second, source code can be copied with minimal cost, so where does the more efficient production come from? That is, compared with just copying the code for a "shared" module into each product's source tree and then developing separately, how does a product-line approach provide benefit? Copying is simple and easy to understand, but to get efficiency with SPL, we need to understand the true costs of the simple copy approach (such as duplicate work and increased risk in fixing a common defect in each copy). Only in understanding the true benefits and costs can be determine when an SPL approach makes sense.

Third, in many ways, SPL seems much like the more general problem of software reuse. And it is, though more specialized. The assembler example illustrates this. The SPL challenge is recognizing the opportunity early and taking explicit advantage of it.

Another issue is how to organize and manage code for a Software Product Line. In many ways, this is the n x m problem, where you have n products making use of different subsets of the m modules. Applying the concepts to development without tool support can be a challenge.

Software Product Lines have great potential for dramatic efficiencies over non-product line approaches for certain types of problems. We hope you now have a glimpse at the potential and possibilities of using a SPL approach, and have some idea of when it might make sense. For further reading, check out the Software Engineering Institute's web site.