Abstract: Strategic reuse forms the foundation for designing, building, and fielding software product lines. Product lines are groups of similar systems, built using common assets, that address directed segments of the market. Companies who successfully manage to bring product lines to the market are enjoying great improvements in productivity, time to market, product flexibility, and market coverage. Yet more is involved than just reuse. This paper argues that technical, enterprise management, and technical management practices are all essential for the successful construction of a software product line.

Keyword list: product line, product line practice, strategic (planned) reuse

My goals for workshop: To gain insights into what other organizations are building product lines, their success factors, and any stumbling blocks they have encountered.

Working groups of interest: Any related to product lines.

Software product lines are emerging as a new and important software development paradigm. The Software Engineering Institute had launched an initiative to codify and record essential practices for successful product line development. The result will be a product line practice framework that will help organizations understand what areas of technical, managerial, and enterprise strategic competence they must master to build a product line of software-intensive systems. I am the co-leader of the product line practice framework effort at the SEI.

A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission. Companies are finding that the practice of building sets of related systems together can yield remarkable quantitative improvements in productivity, time to market, product quality, and customer satisfaction. But along with the gains come risks. Although the technical issues in product lines are formidable, they are but one part of the entire picture. Organizational and management issues constitute obstacles that are at least as critical to overcome, and may in fact be more dangerous because they are less obvious.

There are universal essential elements and practices that emerge. These elements are common to organizations that have achieved the ability to construct new products from a set of common assets while working under the constraints of various organizational contexts and starting points. These elements and practices are those in which an organization be competent before it can expect to successfully field a software product line. A product line epitomizes strategic reuse. Common assets from which individual products are built extend far beyond mere code reuse. Analysis, requirements, design, testing, planning, scheduling, budgeting, performance engineering, architecture, documentation, and a host of other activities and artifacts can be reused with each subsequent member of the product line.

At its essence, fielding a product line involves core asset development or acquisition, and product development or acquisition using those core assets. These two activities can occur in either order, or (most commonly) in concert with each other. Core asset development has been traditionally referred to as domain engineering. Product development from core assets is often called application engineering. The entire process is staffed, orchestrated, tracked, and coordinated by management.

The goal of the core asset development activity is to produce or to acquire three things:

• Product List: A description of the initial products that will constitute the product line. This description will typically be cast in terms of the things that the products will all have in common, and the specific ways in which they vary from one another (as opposed to an enumerated list of specific product names). This output, which is a description of the space of products that the product line will be capable of including, expresses the product line’s scope, which will be discussed below. Of course, the product list evolves as market conditions change, as the organization’s plans change, or as new opportunities arise. Evolving the product list is the starting point for evolving the product line to keep it current.
• Core Assets: These are the core assets that will be the basis for production of products in the product line. It will almost certainly include an architecture that the products in the product line will share, as well as software components that will be designed (or reengineered from existing systems) for systematic reuse across the product line. Software components also bring with them test plans, test cases, integration plans, and all manner of design documentation. Other assets, as mentioned previously, also will populate this set. Commercial off-the-shelf (COTS) components, if adopted, also constitute core assets.
• Production Plan: This describes how the products will be produced from the core assets.

These three outputs feed the product development or acquisition activity, which turns out products that serve a particular customer or market niche. The products are built with the core assets using the production plan.

Inputs to the development and acquisition of core assets are:

Practice areas (described in the framework, but not in this paper due to space restrictions) relevant to producing the core assets include:

• Acquisition Strategy
• Architecture Exploration and Definition
• Architecture Evaluation
• Component Development
• Configuration Management
• COTS Utilization
• Data Collection, Metrics, and Tracking
• Domain Analysis
• Incremental Development
• Make/Buy/Mine Outsource Analysis and Execution
• Market Analysis
• Mining Existing Assets
• Operations
• Planning
• Process Modeling and Implementation
• Product Line Scoping
• Requirements Management
• Risk Management
• Testing

A product line is, fundamentally, a set of related products. Each product is produced by a group we will call the product group. There may be one product group for several products, or one product group per product. If separate, they may fall under the same organizational structure or be distributed widely across an enterprise. Sometimes a product line is commissioned (that is, one organization pays another organization to develop the core assets and one or more resulting products). The commissioning organization may or may not develop products itself once the core assets are in place. If it does, and the core asset organization also develops products, then the product groups may be distributed across entirely separate enterprises.

Inputs for product production include the core assets, the production plan, and the requirements for any particular product, often expressed as a delta or variation from some generic product description contained in the product list (such a generic description is itself a core asset)

Relevant practice areas include

• Requirements Management
• Architecture Evaluation
• Program Acquisition Management
• Configuration Management
• Data Collection, Metrics, and Tracking
• Software System Integration
• Testing

Management plays a critical role in the successful fielding of a product line. Activities must be given resources, coordinated, and supervised. Organizational management must set in place the right organizational structure that makes sense for the particular enterprise, and make sure that the organizational units receive the right resources (e.g., well-trained personnel) in sufficient amount. Organizational management is the authority that is responsible for the ultimate success or failure of the product line effort. If the product line is being commissioned, then the acquiring organization must also have an organizational management function that holds the responsibility for the success or failure of the product line acquisition effort. It must bear the responsibility for the meeting or failure to meet the enterprise goals of the product line itself.

Organizational management also contributes to the core asset list, by making available for reuse those management artifacts (especially schedules and budgets) for producing products in the product line.

Another kind of management that is required is the management of the organization’s external interfaces. Product lines tend to engender different relationships with an organization’s customers and suppliers, and these new relationships must be introduced, nurtured, and strengthened.

One of the most important things that management must do is create an adoption plan that describes the state of the organization once it routinely produces products in the product lines, and a strategy for achieving that state. The adoption plan should lay out phase-in activities for various organizational units, prescribe training and skill development that will be necessary, launch a measurement program to gauge progress and success, and describe the eventual organizational structure that will be adopted.

In the area of management, relevant practice areas include

• Planning
• Achieving the Right Organizational Structure
• Funding
• Building and Communicating a Business Case
• Training
• Risk Management
• Operations
• Developing and Communicating an Acquisition Strategy
• Pro-active Management
• Customer and Supplier Interface Management

Paul C. Clements is a Senior Member of the Technical Staff at Carnegie Mellon University's Software Engineering Institute. He is the author of over three dozen papers in sofware engineering in the areas of software architecture and design, real-time systems, and program families. From 1980-1994 he worked at the Naval Research Laboratory in Washington, where he was a senior software engineer. He holds a B.S. degree in Mathematical Sciences and an M.S degree in Computer Science, both from the University of North Carolina at Chapel Hill, and a Ph.D. in Computer Sciences from the University of Texas at Austin. He recently authored "Software Architecture in Practice" (Addison Wesley, 1998) with Len Bass and Rick Kazman.