A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying 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.
At SoftwareProductsLines.com, Charles Krueger defines them as follows:
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.
The key objectives of software product lines are: to capitalize on commonality and manage variation in order to reduce the time, effort, cost and complexity of creating and maintaining a product line of similar software systems.
- Capitalize on commonality through consolidation and sharing within the software asset inputs, thereby avoiding duplication and divergence.
- Manage variation by clearly defining the variation points and decision model, thereby making the location, rationale, and dependencies for variation explicit.
Closely related to software product lines is the notion of software product families and Product Family Engineering. In many cases the terms product-line and product-family are used interchangeably. Sometimes a product-family is slightly more general in that a product-family may comprise one or more product-lines. The SEI has established a Framework for Software Product-Line Practices that encompasses topics such as architecture, organization, patterns, business-case, and even a section on configuration management for software product-lines.
2 comments:
Hi Brad,
I consult on Software Product Lines and I'm not sure I can agree wholeheartedly with the SEI position. They have done a lot of good work in this area but in my experience don't know a lot about Product Line tooling.
I haven't seen a CM system that has any worthwhile capabilities w.r.t. managing product lines. This is because CM systems don't capture variability between products at a level that can be reasoned about to help manage the product line.
On the other hand it is possible to use just about any CM system in a product line effort in conjunction with a specialist variant management tool. (The pure::variants toolset we sell for example :-) or one of our competitors). Our customers range from CVS users through to Perforce, Clearcase, Dimensions, MKS etc...
You might also be interested in a paper I co-authored on Variant Management (available at http://www.software-acumen.com/articles-and-essays/)
A lot of people think that they can develop successful product lines by using their CM system as the main product line management tool but they come to grief as the product line scales.
YMMV of course.
Mark Dalgarno
Software Acumen
Hi Mark! Thanks for chiming in. I'd be interested in hearing more about exactly which pieces of the "SEI position" you are referring to. When I read their page, it looks like a basic description of CM and of product-line-specific issues for CM and some of their requirements. I don't see it specifying any strategies or positions (much less implementations).
I'd say 95+% of the time that I see feature-specific branches, it has nothing to do with trying to mix-and-match different combinations of feature-sets. I more often see a spaghetti-like morass of conditional compilation code. And feature-specific branches are more commonly used an integration strategy for organizing parallel work (not so much for managing variability).
Most of the reasonably successful approaches I see don't try to depend on the CM system, they try to depend on architecture and design strategies using later binding-time (typically post-build-time) using various design patterns or other design/architecture techniques (such as run-time or install-time configuration, feature-registry, business-rules, etc.).
The most advanced approaches I've seen have involved sophisticated (and usually homegrown) tools stemming from academic research that are specifically designed to do feature-set logic and algebraic manipulations of features and feature-sets (and the changes associated with them).
Another approach I’ve been seeing a bit more lately is applying the notion of "aspects" to features, where the "cut-points" are actually the variation-points for one or more features (rather than the features themselves) and the "advice" provided has to do with the specifically desired parameter values and constraint/tradeoff policies select for a particular instance of a feature in a customized offering of the product.
Anyway, much of the above is actually not strongly related to what I'm ultimately trying to get at, because my primary purpose for introducing product-lines and variability management in the blog at this point in time is to discuss how those some concepts translate into the domain of software process, particularly with the way some large organizations attempt to create standard/common-processes at the enterprise level and then varying degrees of "tailorability" at the organization-specific and project-specific boundaries within the enterprise.
Post a Comment