Software Product Lines


Software product lines refers to engineering techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production. Producing a set of related products as a product line has allowed organizations to achieve increased quality and significant reductions in cost and time to market. But adopting a product line approach to software is both a technical and a business decision that involves many challenges.


Mass production – the ability to efficiently create many copies of the same product – represented a big advance in the manufacturing world, though creating many copies of a software product is trivial. On the other hand, mass customization – the ability to efficiently create many variations of a product – is a big advance in both manufacturing and software engineering.
Some example organizational benefits according to the SEI:

  • Improved productivity by as much as 10x
  • Increased quality by as much as 10x
  • Decreased cost by as much as 60%
  • Decreased labor needs by as much as 87%
  • Decreased time to market (to field, to launch) by as much as 98%
  • Ability to move into new markets in months, not years

Obstacles and Economics of Product Lines

But along with the gains come risks. Using a product line approach constitutes a new technical strategy for the organization. Organizational and management issues constitute obstacles that are critical to overcome and often add more risk, because they are less obvious. Building a software product line and bringing it to market requires a blend of skillful engineering as well as both technical and organizational management. Acquiring a software product line also requires this same blend of skills to position the supplier organizations, so they can effectively exploit the commonality of the incoming products, as well as lend sound technical oversight and monitoring to the development effort. These skills are necessary to overcome the pitfalls that may bring failure to an unsophisticated organization.

A number of other considerations must be considered in order to implement a software product line, and an overhead is created. This will be reflected as an initial cost, which will discourage the implementation of the software product line for small projects. Consequently, a number of products (payoff point), along with a minimum complexity would be necessary before taking into consideration product lines.

Economics Of Product Lines

Key concepts

Software product lines can be described in terms of four simple concepts, as illustrated in the figure below:


Key Software Product Line Concepts

Key Software Product Line Concepts

  • Software asset inputs: a collection of software assets – such as requirements, source code components, test cases, architecture, and documentation – that can be configured and composed in different ways to create all of the products in a product line. Each of the assets has a well defined role within a common architecture for the product line. To accommodate variation among the products, some of the assets may be optional and some of the assets may have internalvariation points that can be configured in different ways to provide different behavior.
  • Decision model and product decisions: The decision model describes optional and variable features for the products in the product line. Each product in the product line is uniquely defined by its product decisions – choices for each of the optional and variable features in the decision model.
  • Production mechanism and process: the means for composing and configuring products from the software asset inputs. Product decisions are used during production to determine which software asset inputs to use and how to configure the variation points within those assets.
  • Software product outputs: the collection of all products that can be produced for the product line. The scope of the product line is determined by the set of software product outputs that can be produced from the software assets and decision model.

Each product is formed by taking applicable components from the base of common assets, tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance, adding any new components that may be necessary, and assembling the collection according to the rules of a common, product-line-wide architecture. Building a new product (system) becomes more a matter of assembly or generation than one of creation; the predominant activity is integration rather than programming. For each software product line there is a predefined guide or plan that specifies the exact product-building approach.

What Software Product Lines Are Not

  • Clone and own: single-system development with reuse: only modifying code as necessary for the single system
  • Fortuitous small-grained reuse: reuse libraries containing algorithms, modules, objects, or component
  • Just component-based or service-based development: selecting components or services from an in-house library, the marketplace, or the Web with no architecture focus
  • Just versions of a single product: rather, simultaneous release and support of multiple products
  • Just a configurable architecture: a good start, but only part of the reuse potential
  • Just a set of technical standards: constraining choices without an architecture-based reuse strategy
Software Engineering Institute: Software Product Lines
Clements, P. and Northrop, L. Software Product Lines: Practices and Patterns. 2001. Addison-Wesley
  1. Tweets that mention Software Product Lines via #SPL -- - pingback on December 27, 2010 at 1:40 pm

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Trackbacks and Pingbacks: