1.3 A Note on Terminology
Now that we have covered what we don't mean, the following terms lay out what we do mean:
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. This is the definition we provided in Section 1.1.
Core assets are those assets 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 the organization). 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 provides 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. Figure 1.1 shows the mapping between our terminology and this different set of terms.
Figure 1.1 Alternate Terminology
To us, the terminology is not as important as the concepts. That having been said, you might encounter both sets of terms in other places and should be able to translate between them. You might also use an entirely different set of terms that are equivalent to the ones we use. In that case you will probably want to do your own mapping, akin to that shown in Figure 1.1, before you proceed with the rest of the book. Although we have tried not to invent vocabulary, as you read on you may find other terms we use that you may call by different names, and you may want to expand your map.
The next chapter discusses the benefits (and the risks) of software product lines.