NEWS AT SEI
This article was originally published in News at SEI on: March 1, 2005
Organizations that leverage core assets (software, designs, documentation, test artifacts, budgets and schedules, tools, and more) across the family of systems they produce (instead of building each system separately) are able to dramatically increase quality and reduce cost and time to market. But adopting a product line approach to software is a technical and a business decision that involves many challenges. Over the next few issues, this column will answer some of the most frequently asked questions of organizations considering a product line approach.
"Isn't a product line just the group of products produced by a single business unit or profit/loss center?"
That is what some people mean when they use the term, but it's not what we mean. We define a software product line as a set of software-intensive systems that share a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. A product line is a set of products carefully chosen to take simultaneous advantage of commonality and market opportunities. These opportunities may or may not span what is normally produced by a single business unit. For example, the software for commercial avionics and the software for military avionics could span separate business units in a company but be developed as a single product line by a software group that reports to both. Or, a single business unit may be responsible for developing and fielding more than one software product line. In general, a business unit is formed for organizational or financial reasons and may be responsible for (part of) one or more product lines.
"If a product line is a set of products, does that mean I have to build them all?"
No. While the term "product line" usually brings to mind a specific set of fielded products, you can think of a product line as defining a virtual set of products, each sharing a set of common, managed features and able to be built from the same core asset base. Only those products that satisfy some specific market need are actually built. The others represent untapped production capability that could be built should the opportunity arise.
"What's the difference between a domain and a product line? For instance, there is a telecommunications domain and some companies build a telecommunications product line. What's the difference?"
A domain is a specialized body of knowledge, an area of expertise, or a collection of related functionality. The telecommunications domain is a set of telecommunications problems, which in turn consists of other domains (switching systems, protocols, telephony, networks, etc.). A telecommunications product line is a specific set of systems that addresses some of those problems. People often use the term "domain" incorrectly to refer to a set of systems that employ knowledge in a particular domain, but that's an incorrect use of the term. It's hard to imagine any non-trivial software system that doesn't encompass knowledge from several domains.
"Isn't software product line practice the same as single-system development with reuse?"
No. It differs in three fundamental ways. First, building a software product line is about planning a plurality of products that will exist in the field and be maintained simultaneously, not just one that evolves over time. Second, the reuse that's involved is carefully planned, strategic, and applicable across the entire set. In fact, one of the primary distinguishing characteristics of product line practice is planned reuse rather than ad hoc reuse. Software product line practice encourages choices and options that are optimized from the beginning for more than a single system. And third, single-system development with reuse usually begins by taking the latest version of whatever other systems happen to exist, copying the code, and starting to make product-specific changes to it. The result is that each version of each product launches on its own maintenance and change trajectory, which soon overwhelms the organization trying to keep all of the versions under control and staffing the effort. In a software product line, the core assets follow a single evolution path, and all versions of all products are built from those.
"Vendors and other developers issue subsequent releases of single products all the time, and have been doing so for years. Each release is built in the same way — you would say from the same core asset base. Technically speaking, what's the difference between a software product line and multiple releases of the same product?"
There are some similarities, but the differences are acute enough to matter. The primary difference is that vendors who release subsequent versions try to retire earlier versions as soon as they can. Also, later versions are usually supersets of earlier versions. The latest version is always the one of interest. In a software product line, all versions are of interest, because they provide different functionality and quality attributes, each serving different market segments or missions.
"Isn't product line practice just another name for domain engineering?"
Domain engineering addresses only half of the problem (core asset development and acquisition). Product line practice addresses both domain engineering and product development using the core assets, or what has been called application engineering.
"Isn't product line practice just another name for component-based development?"
Software product lines certainly rely on a form of component-based development. Component-based development as it is typically defined involves the selection of components from a library or the marketplace to build products. Though the products in software product lines certainly are composed of components, these components are all specified by the product line architecture. Moreover, the components are assembled in a prescribed way; the prescription comes both from the architecture and the production plan. Software product lines involve the strategic use of components. Component-based development usually is missing such a strategic and systematic approach.
A Note on Terminology
In this column we use the following terms:
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 and that are developed from a common set of core assets in a prescribed way.
Core assets are those reusable artifacts and resources that form the basis for the software product line. Core assets often include, but are not limited to, the architecture, reusable software components, domain models, requirements statements, documentation and specifications, performance models, schedules, budgets, test plans, test cases, work plans, and process descriptions. The architecture is key among the collection of core assets.
Development is a generic term used to describe how core assets (or products) come to fruition. Software enters an organization in any one of three ways: the organization can build it itself (either from scratch or by mining legacy software), purchase it (buy it, largely unchanged, off the shelf), or commission it (contract with someone else to develop it especially for them). So our use of the term "development" may actually involve building, acquisition, purchase, retrofitting earlier work, or any combination of these options. We recognize and address these options, but we use "development" as the general term.
A domain is a specialized body of knowledge, an area of expertise, or a collection of related functionality. For example, the telecommunications domain is a set of telecommunications functionality, which in turn consists of other domains such as switching, protocols, telephony, and network. A telecommunications software product line is a specific set of software systems that provide some of that functionality.
Software product line practice is the systematic use of core assets to assemble, instantiate, or generate the multiple products that constitute a software product line. The choice of verb depends on the production approach for the product line. Software product line practice involves strategic, large-grained reuse.
Some practitioners use a different set of terms to convey essentially the same meaning. In this alternate terminology, a product line is a profit and loss center concerned with turning out a set of products; it refers to a business unit, not a set of products. The product family is that set of products, which we call the product line. The core asset base is called the platform. Previously, what we call core asset development was often referred to as domain engineering and what we call product development was referred to as application engineering.
The terminology is not as important as the concepts. Readers might encounter different sets of terms in other places and should be able to translate between them.
About the Author
Paul Clements is a senior member of the technical staff at the SEI, where he has worked for 10 years leading or co-leading projects in software product line engineering and software architecture design, documentation, and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998; second edition, 2003), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also written dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a BS in mathematical sciences in 1977 and an MS in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a PhD in computer sciences from the University of Texas at Austin in 1994.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.