Click here to view the complete list of archived articles

This article was originally published in the Fall 2006 issue of Methods & Tools

Introduction to the Emerging Practice of Software Product Line Development - Part 3

Charles W. Krueger, http://www.biglever.com/

Transition to a Software Product Line Approach

There are a variety of approaches for transitioning to, or adopting, a new software product line approach. Some case studies have reportedtransition efforts of 5 years while others have reported making the transitionin as little as 2 months. This section outlines some of the characteristics that influence this surprising diversity in transition profiles.

Source of Software Asset Inputs

The software asset inputs for a software product line might come from a variety of sources, including reusable artifacts from an existinglibrary, wrapped or re-engineered artifacts from an existing product, orartifacts developed from scratch. Considerable time and effort can be saved ifassets can be reused or extracted from existing products, existing repositories,commercial libraries, and so forth, rather than creating the software assets from scratch.

New versus Enhancement

Another distinguishing characteristic in the transition approach for software product lines is whether it is a brand new product line orwhether it is a transition from an existing product line to a more effectiveapproach. Note that if the initial state has multiple products, managed witheven the most primitive, ad hoc, conventional techniques such as clone-and-ownor language preprocessor conditionals such as the C language #ifdefs,it is still a product line. "Clone-and-own" refers to the practice ofcreating a new product by "cloning" a copy of the source code ofanother product and then modifying it, thereby taking ownership of the newlycloned product which now has a development and maintenance lifecycle of its own.Existing products, assets (including requirements, architecture, source, and soforth), decision models, and production mechanisms can often be reused andre-engineered when enhancing a software product line approach in order to save time and effort.

Lightweight Approaches

Early case studies of software product line transitions reported typical adoption times of 2 to 5 years. For most organizations, thistime and effort represents a significant barrier to adopting a product lineapproach, regardless of the potential benefits. Recently, advances have beenmade in lightweight approaches that lower the required transition effort,with some case studies reporting adoption efforts as low as 2 months. Lightweight techniques employed include:

• minimize differences between single-system and product line engineering in order to minimize impact on organization, processes, software, and infrastructure
• utilize an incremental adoption strategy to initially transition a small subset of assets, products, subsystems or people
• offer off-the-shelf software product line tools and technology
• use reactive approaches to defer product development and deployment efforts
• structure production to minimize the need for complex and costly merging, feedback, and product-specific configuration management overhead

The benefits of the software product line approach come in the form of tactical improvements in software engineering -- deploying software products faster, cheaper, and better. However, what is most interesting is that these tactical improvements are often large enough to have an impact well beyond the borders of the engineering department, offering strategic competitive benefits to the way that a company conducts its business.

The following tactical engineering benefits can be gained from software product lines. Some organizations have reported improvements ranging from factors of 3 to factors of 50.

• reduction in the average time to create and deploy a new product
• reduction in the average number of defects per product
• reduction in the average engineering effort to deploy and maintain a product, and therefore reduction in the average engineering cost per product
• increase in the total number of products that can be effectively deployed and managed

These tactical engineering benefits translate into a very powerful set of strategic business benefits:

• reduced time-to-market and time-to-revenue for new products
• improved competitive product value
• higher profit margins
• improved ability to hit market windows
• better product quality and improved company reputation for quality
• improved scalability of business model in terms of products and markets
• increased agility to expand into new markets
• reduced risk in product deployments

The order-of-magnitude benefits offered by software product lines can be attributed to strategic software reuse. Software product line techniques explicitly consolidate and capitalize on commonality throughout the product line. They formally manage and control the variations among the products in the product line. They aggressively eliminate all duplication of effort in the engineering processes. As a result, the only unique engineering effort required for any product in the product line is for the product variations that are truly unique to the product.

The remaining sections in this chapter provide additional details and descriptions on the tactical and strategic benefits of software product lines.

If new products in a software product line can be engineered and brought to market faster, the following strategic business benefits result:

• shorter time to revenue
• improved ability to hit critical market windows
• increased bandwidth to pursue more markets and thus generate more revenue
• greater agility to survive in turbulent market conditions

Companies with software product line success stories have reported decreasing their time-to-market for new products by factors of 2 to 50when compared to the conventional techniques they were using before.

Some of the tactical pains experienced by engineering organizations that might be able to benefit from the time-to-market improvementsof software product lines include:

• contentious relationship between marketing and engineering teams due to engineering's inability to accommodate business requests for more product variations
• complex and time consuming coordination of multiple parallel development efforts that share common software (for example, diverging and merging code bases or bushy configuration management branch structures)
• brittle source code that is difficult and error-prone to extend with new product variations

Software product line approaches improve time-to-market by enabling delta engineering. Delta engineering means that the only newsoftware development required for a new product instance is for new variationpoints in the software assets to accommodate capabilities that are truly uniqueto the new product (that is, capabilities that don't already exist for otherproducts). Beyond that, the new product instance can be created from the stablecollection of existing common assets, variation points, the decision model, and the production mechanism.

Quality Benefits of Software Product Lines

Quality benefits of software product lines can be measured in two ways. The first is how well each product matches the needs of each customer.The mass customization capabilities of software product lines directly addressthis measure of quality. The second is the rate of defects found in each of theproducts in the product line, which can also be significantly improved bysoftware product line techniques. Companies have reported reductions in defect rates as high as 96%.

Higher product quality with software product lines has both strategic business and tactical engineering impact:

• satisfied customers provide a continuing revenue stream and provide positive recommendations to other potential customers
• fewer product defects means lower overhead throughout the software lifecycle
• fewer support calls and thus a smaller support organization
• fewer failure/find/fix/retest cycles in the test organization leads to shorter test cycles and smaller test teams
• fewer debug/fix activities means that developers can focus more time on developing new products and new product capabilities

The quality benefits - in terms of defect reduction - can be directly attributed to the commonality in a software product line. By optimizingthe reuse of software assets across the product line and throughout the life ofa product line, very high quality assets emerge. Finding and fixing a singledefect in a common software asset will impact all of the products using that asset, even if the defect was only observed in one of the products.

The following graph illustrates the downward trend of defects found when testing a collection of products in a software product line, both ina single release of products and across multiple releases of the products. Eachcolored curve represents a sequence of product tests for a simultaneous releaseof products in a product line. Each downward-sloping curve shows that defectsfound in early product tests (e.g., Product A) reduce the number of defectsfound in subsequent product tests (e.g., Product B). The downward trend ofoverall defects from Release 1 to Release 2 to Release 3 illustrates that highquality software assets are emerging due to high levels of commonality and carefully managed variations from release to release.

Page 2   Page 4    Back to the archive list