Software Product Line

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. [1]

ExtremeProgramming translation: Obey DontRepeatYourself, over a suite of target markets, so the same codebase supports all of them, and so a kit using MetaData can easily produce a new product line. All tests cover all product lines at all times.

Using the ProductLineApproach, members in a SoftwareProductLine can be constructed (sometimes integrated) from a common set of CoreAssets, using a common ProductLineArchitecture.

[1] See http://www.sei.cmu.edu/plp/frame_report/glossary.htm, Which has these definitions:

ProductLine A group of products sharing a common, managed set of features that satisfy specific needs of a selected market or mission area.

ProductLineApproach A system of software production that uses reusable software-related assets to modify, assemble, instantiate, or generate a line of software or software-intensive products.

ProductLineArchitecture Description of the structural properties for building a group of related systems (i.e., product line), typically the components and their interrelationships. The inherent guidelines about the use of components must capture the means for handling required variability among the systems. (Sometimes called a reference architecture.)

Software Product Lines are an initiative by PaulClements? & LindaNorthrop? of the SoftwareEngineeringInstitute to specify how to specify a single CodeBase that supports an arbitrary number of different configurations for different customers.

For example, MicrosoftOffice supports MacIntosh, home use (yuck!), small business use, and (of course) Enterprise Use.

Another example is the firmware in the computer in your car's engine. Car manufacturers do not reprogram their computers once per make and model. They apply OnceAndOnlyOnce against BusinessValue needs, to generate a core set of code. Then they publish this core set, and instructions for how to deploy it, to each product line. Each of those is the configuration set and unique code required to generate one product.

A near-example is the GnuLinux kernel, with its mighty make menuconfig command. Such wide configurability tests the same code in many twisted ways. But this is not a perfect example because technology alone drives that menu of options. In an SPL scenario, the various distros would project their high-level UserStories down into sets of configuration options. These uber-configurations exist, of course, but distributed among the Linux distributors.