Last week I had the opportunity to participate in a Product Line Engineering (PLE) seminar by Dr. Paul Clements, who is one of the global experts on this subject and author of the book “Software Product Lines: Practices and Patterns” among others. For many years, Paul has been at SEI, the Software Engineering Institute at Carnegie-Mellon University.

Here is Paul’s definition of Product Line Engineering:

“The disciplined engineering of a portfolio of related products using a common set of shared assets and a common means of production.”

Paul adopts the factory paradigm, in which the shared assets are like the items in the factory’s supply chain. A set of features describe capabilities that may vary among products. Then, the assets are configured according to feature profiles, generating concrete products.

Paul’s seminar was naturally focused on Software Product Lines (SPL). Here is the definition of SPL from SEI:

“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.

Software product lines are emerging as a viable and important development paradigm allowing companies to realize order-of-magnitude improvements in time to market, cost, productivity, quality, and other business drivers. Software product line engineering can also enable rapid market entry and flexible response, and provide a capability for mass customization.”

Software Product Lines are not only about the software

For many years I’ve been developing software systems and trying to make them highly configurable, through interchangeable components, well-defined interfaces, low coupling and high cohesion. Using the right Design Patterns, it’s easy to add degrees of freedom to an application, defining relationships between abstract components. That’s the basic idea of plug-ins, which may indeed be used to extend a system and create new variations.

In some of my previous posts I’ve defined my approach of Adaptable Design Up Front (ADUF), which promotes the definition of frameworks or platforms that serve as the basis for a family of products. Such a family can be formed by:

• Several products coexisting at the same point in time.
• Several instances (versions) of a product over a period of time.

In both cases, the several products in the family are the result of an evolutionary process, which in my opinion should be planned as much as possible. Thus, ADUF can be seen as a methodology to create a shared software architecture to support this evolution.

However, Software Product Lines are not only about the software. They are about all the artifacts generated during the software development process, including:

• Requirements
• Design diagrams
• Documentation
• Test cases
• User guides

Clearly, each member in the family will have its own instances for each one of these artifacts, and each artifact should support configuration through the same variation points as the software itself. If the software system is configurable but the other artifacts are not, we cannot really say we have a product line.

I believe every software developer has experienced the difficulty of keeping all artifacts coherent during software evolution. I hope new tools will make this task easier. What has been your personal experience? Please share with us using the comments below.