Software Product Line Practice Patterns

More and more organizations today are taking a product line approach to software development and are achieving large-scale productivity gains, reduced time to market, and increased customer satisfaction.

To help organizations with their product line efforts, the SEI developed the Framework for Software Product Line Practice as well as supporting methods and training; sponsors and participates in conferences and workshops;¹  and created the Product Line Technical Probe.²  Now the SEI offers a new aid to help organizations achieve their product line goals: software product line practice patterns.

About Product Line Practice Patterns

The Product Line Practice Framework identifies 29 practice areas whose mastery and application are necessary for success with software product lines. But organizations do not always know how to apply these practice areas or where to begin. SEI authors Paul Clements and Linda Northrop write in their recently published book, Software Product Lines: Practices and Patterns,³   "You need to put the practice areas into play. You aren’t going to attack all of the areas at once. You need to follow a divide-and-conquer strategy that permits you to divide the product line effort into chunks of work to be done."

The first thing an organization needs to do in this divide-and-conquer effort is understand its individual situation. Fortunately, although no two situations are exactly alike, similar situations occur again and again. It is through this similarity that product line practice patterns emerge. Patterns are a way of expressing common contexts and problem/solution pairs; they have been used effectively in many disciplines including architecture, economics, social science, and software design. For software product line practice patterns, the context is the organizational situation. The problem is what part of a software product line effort needs to be accomplished. The solution is the grouping of practice areas and the relations among those practice areas that together address the problem for that context. Clements and Northrop note that "patterns provide a helpful handle for selecting and applying the appropriate practice areas to meet your individual needs."

For product line patterns to succeed, they must be easy for a wide range of stakeholders to understand. They must have sufficient detail so that stakeholders can recognize the pattern context and problem and implement a solution. They must be consistent over the entire pattern set. They also must be able to handle static and dynamic information that will evolve as the product line develops. Following the lead of the "patterns community," the SEI has created a pattern template. It provides a standard way of expressing information:

• Name: A unique and intuitive pattern name and a short summary of the pattern.
• Example: One or more scenarios to help illustrate the context and the problem.
• Context: The organizational situations in which the pattern may apply.
• Problem: What part of a product line effort needs to be accomplished.
• Solution: The basis for the practice area pattern grouping underlying the pattern.
• Static: The grouping that lists the practice areas.
• Dynamics: A table, diagram, and/or scenario describing the relations among the practice areas in each group and/or among the groups if there is more than one.
• Application: Any suggested guidelines for applying the pattern.
• Variants: A brief description of known variants or specializations of the pattern.
• Consequences: The benefits the pattern provides and also any known limitations.

An Example Pattern

One of the early problems that new software product line organizations face is determining what products ought to be in their product line. The What to Build pattern is meant to assist them in this task. Determining what to build requires information related to the product area, technology, and market; the business justification; and the process for describing the set of products to be included in the product line. The following is a typical scenario suggesting the need for application of the What to Build pattern:

A three-year old company develops Web-based registration systems for conferences. The company currently has contracts with three major computing conferences and these systems are in place. It has leads for another six conferences with the possibility for even more. The company is adopting a product line approach for its systems because there is considerable commonality among the three systems that have been fielded and because maintaining them separately has become a configuration nightmare. The company doesn’t want to limit itself to the systems it has already developed, but it isn’t clear what other systems ought to be in the product line. On the other hand, it is a small organization in need of a target niche that is narrow enough to limit the complexity of the assets that need to be built. Because it is unclear what products to build, product line requirements cannot be generated, nor can the development of the other core assets begin. Application of the What to Build pattern focuses on just those five practice areas needed to address the problem at hand—namely, what products should be in the product line. It doesn’t tackle the whole product line approach. The application of other patterns would be necessary to complete the picture. However, the What to Build pattern provides a clear place to start. Using patterns an organization can move to software product lines in a manageable way that builds on the experience of others. The patterns are also now being incorporated into the SEI’s Product Line Technical Probe to assist in individual situations to narrow the probe focus, find the root cause of surfaced weaknesses, classify the results, and package and prioritize a course of action.

To date, the SEI has identified 22 practice area patterns. They are completely described in Software Product Lines: Practices and Patterns, along with a thorough description of the practice areas and multiple product line case studies. There are undoubtedly other product line practice patterns. Practitioners are encouraged to share their experiences and their own pattern creations.

1	Advancing the State of Software Product Line Practice. news@sei 4, 1 (First Quarter 2001).
2	Probing Product Line Practices. News@sei 3, 2 (Spring 2000).
3	Paul Clements and Linda M. Northrop. Software Product Lines: Practices and Patterns. Boston, Ma.: Addison-Wesley, 2001.

For more information, contact—

Customer Relations

Phone
412 / 268-5800

Email
customer-relations@sei.cmu.edu

World Wide Web
http://www.sei.cmu.edu/programs/pls