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.