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

Benefits and Costs of a Product Line

Software product line approaches accrue benefits at multiple levels. This section lists the benefits (and some of the costs) from the perspective of the organization as a whole, the individuals within the organization, and the core assets involved in software product line production.

Organizational Benefits

The organizations that we have studied1 have achieved remarkable benefits that are aligned with commonly held business goals including

These benefits give organizations a competitive advantage and are derived from the reuse of the core assets in a strategic and prescribed way. Once the core asset base for the product line is established, there is a direct savings each time a product is built. That savings is associated with each of the following:

A software product line approach provides options to future market opportunities. Even though exact opportunities and their certainty are impossible to predict, by exercising variation points in the core assets, product lines permit low-cost, low-risk experiments to explore opportunities.

Product lines enhance quality. Each new system takes advantage of all the defect elimination in its forebears; developer and customer confidence both rise with each new instantiation. The more complicated the system, the higher the payoff for solving the vexing performance, distribution, reliability, and other engineering issues once for the entire family.

Individual Benefits

The benefits to individuals within an organization depend on their respective roles. The following table shows observed benefits for some of the individual stakeholders in the product line organization.

Product Line Benefits for Individual Stakeholders

Stakeholder Role

Benefits

Chief executive officer (CEO)

Options to quickly develop new products; large productivity gains; greatly improved time to market; sustained growth and market presence; the options and ability to economically capture a market niche

Chief operating officer (COO)

Efficient use of workforce; ability to explore new markets, new technology, and/or new products; fluid personnel pool

Technical manager

Increased predictability; well-established roles and responsibilities; efficient production

Software product developer

Higher morale; greater job satisfaction; can focus on truly unique aspects of products; easier software integration; fewer schedule delays; greater mobility within the organization; more marketable; have time to learn new technology; are part of a team building products with an established quality record and reputation

Architect or core asset developer

Greater challenge; work has more impact; prestige within the organization; become as marketable as the product line

Marketer

Predictable high-quality products; predictable delivery; can sell products with a pedigree

Customer

High-quality products; predictable delivery date; predictable cost; known costs for unique requirements; well-tested training materials and documentation; shared maintenance costs; potential to participate in a user's group

End user

Fewer defects; better training materials and documentation; a network of other users

Benefits Versus Costs

We have established that the strategic reuse of core assets that defines product line practice represents an opportunity for benefits across the board, but the picture is not yet complete. Launching a software product line is a business decision that should not be made randomly. Any organization that launches a product line should have in mind specific and solid business goals that it plans to achieve through product line practice. Moreover, the benefits given above should align carefully with the achievement of those goals, because a software product line requires a start-up investment as well as ongoing costs to maintain the core assets. We have already listed the benefits associated with the reuse of particular core assets. Usually a cost and a caveat are associated with the achievement of each benefit. The following table gives a partial list of core assets with the typical additional costs. We repeat the benefits for the sake of comparison.

Costs and Benefits of Product Lines

Core Asset

Benefit

Additional Costs

Requirements: The requirements are written for the group of systems as a whole, with requirements for individual systems specified by a delta or an increment to the generic set.

Commonality and variation are documented explicitly, which will help lead to an architecture for the product line. New systems in the product line will be much simpler to specify, because the requirements are reused and tailored.

Capturing requirements for a group of systems may require sophisticated analysis and intense negotiation to agree on both common requirements and variation points that are acceptable for all the systems.

Architecture: The architecture for the product line is the blueprint for how each product is assembled from the components in the core asset base.

Architecture represents a significant investment by the organization's most talented engineers. Leveraging this investment across all products in the product line means that for subsequent products, the most important design step is largely completed.

The architecture must support the variation inherent in the product line, which imposes an additional constraint on the architecture and requires greater talent to define.

Software components: The software components that populate the core asset base form the building blocks for each product in the product line. Some will be reused without alteration. Others will be tailored according to prespecified variation mechanisms.

The interfaces for components are reused. For actual components that are reused, the design decisions, data structures, algorithms, documentation, reviews, code, and debugging effort can all be leveraged across multiple products in the product line.

The components must be designed to be robust and extensible so that they are applicable across a range of product contexts. Variation points must be built in or at least anticipated. Often, components must be designed to be more general without loss of performance.

Performance modeling and analysis: For products that must meet real-time constraints (and some that have soft real-time constraints), analysis must be performed to show that the system's performance will be adequate.

A new product can be fielded with high confidence that real-time and distributed-systems problems have already been worked out, because the analysis and modeling can be reused from product to product. Process scheduling, network traffic loads, deadlock elimination, data consistency problems, and the like will all have been modeled and analyzed.

Reusing the analysis may impose constraints on moving processes among processors, creating new processes, or synchronizing existing processes.

Business case, market analysis, marketing collateral, and cost and schedule estimates: These are the up-front business necessities involved in any product. Generic versions are built that support the entire product line.

All the business and management artifacts involved in turning out the product line already exist at least in a generic form and can be reused.

All these artifacts must be generic or be made extensible to accommodate product variations.

Tools and processes for software development and making changes: The infrastructure for turning out a software product requires specific product line processes and appropriate tool support.

Configuration control boards, configuration management tools and procedures, management processes, and the overall software development process are all in place and have been used before. Tools and environments purchased for one product can be amortized across the entire product line.

The boards, process definitions, tools, and procedures must be more robust to account for unique product line needs and the differences between managing a product line and managing a single product.

Test cases, test plans, and test data: There are generic testing artifacts for the entire set of products in the product line with variation points to accommodate product variation.

Test plans, test cases, test scripts, and test data have already been developed and reviewed for the components that are reused. Testing artifacts represent a substantial organizational investment. Any saving in this area is a benefit.

All the testing artifacts must be more robust, because they will support more than one product. In addition, they must be extensible to accommodate variation among the products.

People, skills, and training: In a product line organization, even though members of the development staff may work on a single product at a time, they are, in reality, working on the entire product line. The product line is a single entity that embraces multiple products.

Because of the commonality of the products and the production process, personnel can be more easily transferred among product projects as required. Staff expertise is usually applicable across the entire product line. Their productivity, when measured by the number of products to which their work applies, rises dramatically. Resources spent on training developers to use processes, tools, and system components are expended only once.

Personnel must be trained beyond general software engineering and corporate procedures to ensure that they understand software product line practices and can use the core assets and procedures associated with the product line. New personnel must be much more specifically trained for the product line. Training materials must be created that address the product line. As product lines mature, the skills required in an organization tend to change, away from programming and toward relevant domain expertise and technology forecasting. This transition must be managed.

For each of these core assets, the investment cost is usually much less than the value of the benefit. Also, most of the costs are up-front costs associated with establishing the product line. The benefits, on the other hand, accrue with each new product release. Once the approach is established, the organization's productivity accelerates rapidly, and the benefits far outweigh the costs. However, an organization that attempts to institute a product line without being aware of the costs is likely to abandon the product line concept before seeing it through.

It takes a certain degree of maturity in the developing organization to field a product line successfully. Technology change is not the only barrier to successful product line adoption. Changes in management and organizational practices are also involved. Successful adoption of software product line practice is a careful blend of technological, process, organizational, and business improvements.

Organizations of all stripes have enjoyed quantitative benefits from their product lines. Product line practitioners have also shared with us examples of the costs, such as

Certainly not every organization must undergo such dramatic measures to adopt the software product line approach. And the companies that bore these costs and made the successful transition to product line practice all agree that the payoff more than compensated for the effort. However, these costs underscore the point that product line practice is often uncharted territory and may not be the right path for every organization.

Next Section Table of Contents Previous Section

 

1 The SEI has published several detailed case studies of successful product line organizations and the benefits they enjoyed. You can find these case studies in the book Software Product Lines: Practices and Patterns [Clements 2002c] and on the Web at http://www.sei.cmu.edu/library/abstracts/books/0201703327.cfm. You can also find references to product line efforts at http://splc.net/fame.html and http://www.sei.cmu.edu/productlines/casestudies/.